Informe Final Algoritmos1

UNIVERSIDAD NACIONAL HERMILIO
VALDIZÁN
E.A.P. INGENIERIA DE SISTEMAS
APLICACIÓN DE LA TEORIA DE GRAFOS EN EL DISEÑO DE

RUTAS DE TRANSPORTE DESDE LAS ZONAS DE PRODUCCION
ALGORITMO Y ESTRUCTURA DE DATOS
HASTA LOS CENTROS DE VENTAS.
GRUPO:
GRAFOS
DOCENTE:
ING. JIMMY GROVER FLORES VIDAL
INTEGRANTES – FASES DEL PROYECTO :
- PROYECTO INICIAL
. CALIXTO TARAZONA VANEZA
. CAMPOS CABELLO KATY
. LEANDRO BAZAN CINTIA
- ANALISIS
. MEZA ALONZO PAVEL
. MISHAHUAMAN GRANDEZ XIBELLY
. VILLADEZA ROMERO KAREN
- DISEÑO
. CADILLO VILLANUEVA DENYS
. GONZALES RETIS FRANKILN
. GRANIZO VILLOGAS NIMROD
. POZO ESTRADA ANGEL
- CODIGO
. ACOSTA JARA DIEGO
. CHAGUA RAMOS OMAR
. FLORES MARTINEZ JOY
- PROYECTO FINAL
. NAUPAY PICON PERCY
. VALDIVIA ESCOBAR JONATHAN
. DIAZ SANCHEZ CESAR
INDICE
INTRODUCCIÓN .......................................................................................................................... 5
PROYECTO ................................................................................................................................... 6
1.1. TÍTULO ............................................................................................................................... 7
1.2. OBJETIVOS ...................................................................................................................... 7
a) OBJETIVO GENERAL..................................................................................................... 7
b) OBJETIVOS ESPECÍFICOS........................................................................................... 7
1.3. JUSTIFICACIÓN ............................................................................................................... 7
1.4. MARCO TEÓRICO ........................................................................................................... 7
1.4.1. GRAFOS .................................................................................................................... 7
1.4.2. ELEMENTOS DE UN GRAFO................................................................................ 8
1.4.3 TEORÍA DE GRAFOS ............................................................................................. 9
1.4.4. GRAFOS DIRIGIDOS ............................................................................................ 10
1.4.5. GRAFOS NO DIRIGIDOS ..................................................................................... 10
1.4.6. REPRESENTACIÓN DE UN GRAFO ................................................................. 11
1.4.7. RECORRIDO DE UN GRAFO .............................................................................. 12
1.5. HERRAMIENTAS ........................................................................................................... 13
1.5.1. MICROSOFT WORD .................................................................................................. 13
1.5.2. ENTREVISTA .......................................................................................................... 13
1.5.3. RATIONAL ROSE .................................................................................................. 14
1.5.4. JAVA ......................................................................................................................... 15
1.5.5. PYTHON ................................................................................................................... 15
ANALISIS ..................................................................................................................................... 18
2.1. INTRODUCCIÓN................................................................................................................. 19
2.1.1. PROPÓSITO ............................................................................................................ 19
2.1.2. ALCANCE ................................................................................................................ 19
2.1.3. PERSONAL INVOLUCRADO .............................................................................. 20
2.1.4. DEFINICIONES, ACRÓNIMOS Y ABREVIATURA .......................................... 24
2.1.5. REFERENCIAS ....................................................................................................... 24
2.1.6. RESUMEN ............................................................................................................... 24
2.2. DESCRIPCIÓN GENERAL ........................................................................................... 25
2
2.2.1. PERSPECTIVA DEL PRODUCTO ...................................................................... 25
2.2.2. FUNCIONALIDAD DEL PRODUCTO ................................................................. 25
2.2.3. CARACTERÍSTICAS DE LOS USUARIOS ....................................................... 25
2.2.4. PERFIL DE USUARIO ........................................................................................... 26
2.2.5. JERARQUÍA DE USUARIOS ............................................................................... 26
2.3. REQUISITOS ESPECÍFICOS ....................................................................................... 27
2.3.1. REQUERIMIENTOS FUNCIONALES ................................................................. 31
2.3.2. REQUERIMIENTOS NO FUNCIONALES. ......................................................... 32
IDEF0 ............................................................................................................................................ 34
CUADRO PICTÓRICO............................................................................................................... 35
DISEÑO ........................................................................................................................................ 36
3.1. IDENTIFICACIÓN DE ENTRADAS: ................................................................................ 37
3.2. IDENTIFICACIÓN DEL CONTROL: ................................................................................ 37
3.3. IDENTIFICACIÓN DE LAS HERRAMIENTAS: ......................................................... 37
3.4. IDENTIFICACIÓN DE LAS SALIDA: .......................................................................... 37
3.5. SUBSISTEMAS............................................................................................................... 38
3.5.1. DISEÑAR RUTA. .................................................................................................... 38
3.5.2. ASIGNAR RUTA. .................................................................................................... 38
3.5.3. MOSTRAR RUTA. .................................................................................................. 39
3.6. CASO DE USO DEL NEGOCIO .................................................................................. 39
3.6.1. ACTORES DEL NEGOCIO ................................................................................... 39
3.6.2. DIAGRAMAS DE CASOS DE USO .................................................................... 40
3.7. CASO DE USO DEL SISTEMA ................................................................................... 40
3.7.1. INTERACCIÓN DEL ADMINISTRADOR Y EL SISTEMA. .............................. 41
3.7.2. INTERACCIÓN DEL CONDUCTOR Y EL SISTEMA. ...................................... 42
3.7.3. CASO DE USO DEL GENERAL DEL SISTEMA .............................................. 43
3.8. DIAGRAMA DE ACTIVIDADES ................................................................................... 50
3.8.1. COMPONENTES BASICOS ................................................................................. 50
3.8.2. DIAGRAMA DE ACTIVIDADES DEL PROYECTO .......................................... 51
a) ACCEDER AL SISTEMA .......................................................................................... 51
b) REGISTRAR PUNTOS DE ENTREGA ................................................................... 52
c) ASIGNAR ZONA......................................................................................................... 53
d) SOLICITAR LA RUTA OPTIMA............................................................................... 54
e) MODIFICAR RUTA OPTIMA .................................................................................... 55
3
CODIFICACIÓN .......................................................................................................................... 56
4.1. CONSTRUCCIÓN DEL ALGORITMO ........................................................................ 57
4.1.1. EL ALGORITMO DE PRIM ................................................................................... 57
4.1.2. EL ALGORITMO DE DJKASTRA ....................................................................... 58
4.2. CAMINO MAS CORTO .................................................................................................. 58
4.3. RUTAS ALTERNAS ....................................................................................................... 60
PRUEBAS .................................................................................................................................... 64
5.1. ALCANCE DE LAS PRUEBAS ........................................................................................ 65
5.1.2. ELEMENTOS DE PRUEBAS .................................................................................... 65
5.1.3. NUEVAS FUNCIONALIDADES A PROBAR ........................................................ 65
5.1.4. OBJETOS QUE SE VAN A EVALUAR ................................................................... 65
5.1.5. ÁMBITO DE LAS PRUEBAS .................................................................................... 66
A) DENTRO DEL ÁMBITO ..................................................................................................... 66
5.1.6. LISTA DE IDEAS DE LAS PRUEBAS .................................................................... 66
5.1.7. ENFOQUE DE PRUEBAS (ESTRATEGIA) ............................................................ 67
5.1.8. PRUEBAS DE REGRESIÓN ..................................................................................... 73
5.1.9. FUNCIONALIDADES A NO PROBAR .................................................................... 74
5.1.10. ENFOQUE DE PRUEBAS (ESTRATEGIA).......................................................... 74
5.2. CRITERIOS DE ACEPTACIÓN O RECHAZO ................................................................ 75
5.2.1. CRITERIOS DE SUSPENSIÓN................................................................................. 77
5.2.2. CRITERIOS DE REANUDACIÓN ............................................................................. 77
5.3. ENTREGABLES ................................................................................................................. 77
5.4. RECURSOS ......................................................................................................................... 78
5.4.1. REQUERIMIENTOS DE ENTORNOS – HARDWARE ......................................... 78
5.4.2. REQUERIMIENTOS DE ENTORNOS – SOFTWARE .......................................... 78
5.4.3. HERRAMIENTAS DE PRUEBAS REQUERIDAS ................................................. 78
5.4.4. PERSONAL .................................................................................................................. 79
5.4.5. ENTRENAMIENTO ..................................................................................................... 79
5.5. PLANIFICACIÓN Y ORGANIZACIÓN ............................................................................ 79
5.5.1. PROCEDIMIENTOS PARA LAS PRUEBAS .......................................................... 79
5.6.1. MATRIZ DE RESPONSABILIDADES...................................................................... 81
4
INTRODUCCIÓN
El presente trabajo presenta una aplicación de la teoría de grafos en la

optimización del sistema de transporte y la reducción de costos en la
operación logística en una empresa de producción. Las empresas que
operan en la ciudad de Huánuco como Felix, Backus, Pacan, Cachigaga,
etc. Tuvieron notables crecimientos en el área de ventas, repartiendo sus
productos a distintos lugares alrededor de la ciudad de Huánuco y fuera de
esta. Uno de los problemas que se ha identificado es que el costo para
trasladarse hasta los centros de venta afronta tres problemas principales:
el primero que las llegadas no son en horarios regulares, existiendo
retrasos de hasta dos días en el cumplimiento del programa semanal, el
segundo es que se usaba unidades de transporte sin medir la capacidad
contrastado con la cantidad de los productos por el operador(agricultor, jefe
de producción) y tercero que el recorrido por cada operador no estaba
establecido. Partiendo del programa semanal de producción se ha
agrupado en “clusters” esto nos ha permitido asignar la unidad de
transporte con capacidades de acuerdo a la producción, de distribución, el
procedimiento se ajusta “agrupar primero y rutar después”, luego hicimos
el ruteo con la ayuda de la teoría de Grafos teniendo como restricciones la
capacidad del vehículo y la oferta de materia prima de cada operador
productivo, cabe resaltar que esto cambia de semana en semana de
acuerdo a los “clusters” formados, finalmente se realizó el programa de la
flota de vehículos.
5
1
PROYECTO
6
1.1. TÍTULO
Aplicación de la teoría de grafos en el diseño de rutas de transporte desde

las zonas de producción hasta los centros de ventas.
1.2. OBJETIVOS
a) OBJETIVO GENERAL
Desarrollar un software que analice las rutas de transporte más

accesibles para el abastecimiento de productos hacia los puntos de
venta.
b) OBJETIVOS ESPECÍFICOS
 Desarrollar rutas de transporte a los puntos de venta.

 Proponer rutas de transporte a los puntos de venta.
 Optimizar los costos de transporte hacia los puntos de venta.
1.3. JUSTIFICACIÓN
La aplicación de la teoría de grafos es de mucha utilidad si la empleamos

correctamente en distintos campos como en nuestro caso en el área de
producción ya que desde nuestra perspectiva se ha considerado como uno
de los errores más graves de transporte del producto hasta los puntos de
venta en la ciudad de Huánuco. El medio de transporte o la ruta que siguen
los vehículos no son las adecuadas ya que a veces toman rutas donde el
tráfico es muy deficiente. Mediante la teoría de grafos diseñaremos y elegir
rutas para mejoras los costos y reducir los gastos en traslados de
productos.
1.4. MARCO TEÓRICO
1.4.1. GRAFOS
El grafo se considera como la estructura más general dentro de la

clasificación tradicional de datos, ya que es la generalización de una
7
estructura jerárquica, la cual a su vez resulta la generalización de la
estructura lineal.
Cada elemento del grafo mantiene una relación N:M con respecto a
los demás elementos.
De otra manera se define a un grafo como una estructura de datos

que permite representar diferentes tipos de relaciones entre objetos.
En un grafo se distinguen esencialmente dos elementos: los vértices
y las aristas, que conectan un vértice con otro.
1.4.2. ELEMENTOS DE UN GRAFO
 Vértices, Son los puntos o nodos con los que está conformado
un grafo.
 Aristas, son las líneas con las que se unen las aristas de un grafo
y con la que se construyen también caminos.
8
1.4.3 TEORÍA DE GRAFOS
Se presentan algunos de los conceptos básicos relacionados a la

teoría de grafos:
 Grado de un vértice, el grado de un vértice v, escrito como grado

(v), denota el número de aristas que contienen a v. Si grado (v)
= 0 entonces v es un nodo aislado.
 Bucle, un bucle es una arista que conecta a un vértice consigo
mismo, a = (u, u).
 Camino cerrado, el camino P es cerrado si el primer y último
vértice son iguales, es decir v0 = vn.
 Camino simple, el camino es simple si todos sus vértices son
distintos, con excepción del primero y del último, que pueden ser
iguales. Es decir, P es simple si v0, v1,..., vn-1 son distintos.
 Camino Hamiltoniano, un camino P de longitud n desde un
vértice v a un vértice w se define como la secuencia de n vértices
que se debe de recorrer para llegar del vértice origen al vértice
destino pasando por cada vértice una sola vez, P = (v1,..., vn).
De tal modo que v = v1; v1 es adyacente a vi+1 para i = 1, 2,...,
n-1; y w = vn.
 Circuito, un circuito es un camino cerrado simple de longitud 3 o
mayor. Un circuito de longitud k se llama k-circuito.
 Circuito Hamiltoniano, es un camino Hamiltoniano que comienza
y termina en el mismo vértice, es decir que v1 = vn.
 Grafo conexo, un grafo es conexo si existe un camino simple
entres dos de sus nodos cualesquiera.
 Grafo árbol, un grafo G es de tipo árbol, si G es un grafo conexo
sin circuitos.
 Grafo completo, se dice que un grafo es completo si cada vértice
v de G es adyacente a todos los demás vértices de G. Un grafo
completo de n vértices tendrá n(n - 1)/2 aristas.
 Grafo ponderado, se dice que un grafo G está ponderado si sus
aristas tienen asignado un valor. Si cada arista a tiene un valor
9
numérico no negativo u(a), llamado peso o longitud de a, se dice
que G tiene peso. En este caso, cada camino P de G tendrá
asociado un peso o longitud que será la suma de las aristas que
forman el camino P.
 Subgrafo, dado el grafo G = (V, A), G’ = (V’, A’) se denomina
subgrafo de G si V’ V’ V y A’ A, donde cada arista de
A’ es incidente con vértices de V’.
1.4.4. GRAFOS DIRIGIDOS
Los grafos dirigidos, a menudo llamados dígrafos, se caracterizan

porque sus aristas tienen asociada una dirección. Los vértices se
utilizan para representar información, mientras que las aristas
representan una relación de jerarquía o dirección entre los vértices.
Formalmente, un grafo dirigido G, también llamado dígrafo, se
caracteriza porque cada arista a tiene una dirección asignada y se
expresa como a = u → v .
1.4.5. GRAFOS NO DIRIGIDOS
Un grafo no dirigido tiene como principal característica que sus

aristas son pares no ordenados de vértices; es decir, si se puede
viajar del vértice u al v, entonces se puede hacer el mismo recorrido
en sentido contrario. Un grafo no dirigido G = (V, A) consta de un
conjunto finito de vértices V y de un conjunto de aristas A. Se
diferencia de un grafo en que cada arista en A es un par no ordenado
de vértices. Si (u, v) entonces (u, v) = (v, u).
10
1.4.6. REPRESENTACIÓN DE UN GRAFO
Hay diferentes maneras de representar un grafo, entre ellas están:
 Matriz de adyacencias, consiste básicamente en un arreglo

bidimensional n × n, donde n es la cantidad de vértices en el
grafo. Cada casilla de la matriz será llenada con verdadero o
falso, según exista o no un arco que conecte los dos nodos
involucrados. Para un grafo no dirigido, la matriz será simétrica.
Para el caso de un grafo ponderado, las casillas pueden llenarse
con los pesos de las aristas. La desventaja de esta forma de
representación es que una matriz simétrica implica un gran
desperdicio de memoria, ya que, al ser simétrica, la información
esta duplicada.
11
 Lista de adyacencias, consiste en definir una lista ligada de
vértices y, para cada uno de ellos, asociar una lista con sus
vértices adyacentes. La idea es similar a la de una matriz. Esta
representación es recomendada para grafos dirigidos, donde la
cantidad de arcos es menor a la de un grafo no dirigido.
 Lista de arcos. Se mantiene una lista de vértices (al igual que en

la lista) pero, en lugar de almacenar los nodos vecinos, se
mantiene una lista de arcos para cada nodo, en la que se tiene
la información necesaria para determinar cuál vértice es el origen
y cuál es destino. En esta representación se minimiza el
desperdicio de memoria; sin embargo su complejidad aumenta
proporcionalmente.
1.4.7. RECORRIDO DE UN GRAFO
Los grafos requieren de algoritmos especializados para buscar la

información contenida en ellos. Existen dos algoritmos básicos para
el recorrido de grafos, denominados primero en anchura (breadth
first) y primero en profundidad (depth first).
12
 Primero en anchura, se expanden los vértices en el orden en que
han sido generados. Es decir, se comprueban todos los vértices
en el mismo nivel antes de generar y analizar un nivel más
profundo. El método trabaja con dos listas auxiliares, una
llamada abierta y la otra cerrada. La primera de ellas es utilizada
para almacenar los vértices que se van a expandir, mientras que
la segunda almacena los vértices que ya han sido expandidos.
 Primero en profundidad, a diferencia de primero en anchura, se
expande el vértice más recientemente generado, es decir, se
explora cada camino posible hasta el final antes de intentar otro.
La profundidad del vértice inicial es cero y la profundidad de un
vértice que no es inicial es igual a uno más la profundidad de su
padre.
1.5. HERRAMIENTAS
1.5.1. MICROSOFT WORD

Es una herramienta ofimática que está integrada dentro del paquete
Office de Microsoft desde 1997 y su función es la del procesamiento
de textos. Sirve por tanto para escribir textos con cualquier finalidad:
académica, profesional, creativa, etc.
Cuenta con un completo paquete de herramientas que permite

aplicar y modificar el formato de un escrito. Estas permiten modificar
desde el tipo o tamaño de la fuente al diseño de la página, pasando
por la inclusión de elementos gráficos como imágenes o tablas.
Permite añadir archivos multimedia de vídeo y sonido pero no es de
gran utilidad si la finalidad del documento es imprimirlo.
1.5.2. ENTREVISTA
Entrevista a todos los usuarios propuestos y actuales para

determinar la utilización del sistema actual, deficiencias del sistema
actual y requisitos nuevos del sistema
13
Se va a documentar la descripción del sistema actual y deficiencias
del sistema actual.
1.5.3. RATIONAL ROSE
Rational Rose es una herramienta para “modelado visual”, que forma

parte de un conjunto más amplio de herramientas que juntas cubren
todo el ciclo de vida del desarrollo de software.
Rational Rose permite completar una gran parte de las disciplinas

(flujos fundamentales) del proceso unificado de Rational (RUP), en
concreto:
 Modelado del negocio

 Captura de requisitos (parcial)
 Análisis y diseño (completo)
 Implementación (como ayuda)
 Control de cambios y gestión de configuración (parte)
 INTERFAZ DE RATIONAL ROSE
La interfaz de Rational Rose está formada por:
 Browser o navegador, permite navegar rápidamente a través de

distintas vistas del modelo.
 Ventana de documentación, sirve para manejar los documentos
del ítem seleccionado en cualquiera de los diagramas.
 Barra de herramientas, sirve para acceder rápidamente a las
acciones comunes a ejecutar para cada uno de los diagramas
de modelo.
 Barra de herramientas de diagrama, muestra el conjunto de
herramientas disponibles para el diagrama activo.
 Ventana de diagrama, permite desplegar y editar cualquiera de
los diagramas UML.
 Ventana de registro o Log, registra todas las órdenes ejecutadas
y los errores que se producen durante su ejecución.
14
 Barra de estado, muestra el programa de la carga del modelo, el
estado de lectura/ escritura del elemento seleccionado, y otros
datos de utilidad.
1.5.4. JAVA
Java es un lenguaje de programación y una plataforma informática
comercializada por primera vez en 1995 por Sun Microsystems. Java
es rápido, seguro y fiable. Desde portátiles hasta centros de datos,
desde consolas para juegos hasta súper computadoras, desde
teléfonos móviles hasta Internet, Java está en todas partes.
Como todo lenguaje de programación, Java se utiliza para crear

aplicaciones y procesos que funcionen en multitud de dispositivos.
La versión estándar de Java es responsable de varias aplicaciones
muy conocidas como jDownloader, Vuze o Minecraft.
Las aplicaciones Java se comunican con la máquina virtual Java, y

no con el sistema operativo, lo cual permite a los programadores
desentenderse de la compatibilidad con el hardware: esta es tarea
para la máquina virtual de Java.
Los applets Java no son más que pequeñas aplicaciones que se

ejecutan en navegador web, y requieren tener instalado el plugin
Java correspondiente (este se incluye en la instalación estándar de
Java). Estos applets, incrustados en páginas web, permitían hacer
cosas entonces imposibles para HTML, como usar la videocámara,
realizar operaciones complejas con imágenes o crear complejos
sistemas de chat.
1.5.5. PYTHON
Python es un lenguaje de programación poderoso y fácil de

aprender. Cuenta con estructuras de datos eficientes y de alto nivel
y un enfoque simple pero efectivo a la programación orientada a
objetos. La elegante sintaxis de Python y su tipado dinámico, junto
con su naturaleza interpretada, hacen de éste un lenguaje ideal para
15
scripting y desarrollo rápido de aplicaciones en diversas áreas y
sobre la mayoría de las plataformas.
El intérprete de Python y la extensa biblioteca estándar están a libre

disposición en forma binaria y de código fuente para las principales
plataformas desde el sitio web de Python, http://www.python.org/, y
puede distribuirse libremente. El mismo sitio contiene también
distribuciones y enlaces de muchos módulos libres de Python de
terceros, programas y herramientas, y documentación adicional.
El intérprete de Python puede extenderse fácilmente con nuevas

funcionalidades y tipos de datos implementados en C o C++ (u otros
lenguajes accesibles desde C). Python también puede usarse como
un lenguaje de extensiones para aplicaciones personalizables.
16
1.6. CRONOGRAMA DE ACTIVIDADES
CRONOGRAMA DE ACTIVIDADES
SEMANA 1 SEMANA 2 SEMANA 3 SEMANA 4 SEMANA 5
FASES RESPONSABLES ACTIVIDAD
1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
PROYETO INICIAL X
OBJETIVOS X
PROYECTO INICIAL
.CALIXTO
TARAZONA, VANEZA JUSTIFICACION X
.CAMPOS CABELLO MARCO TEORICO X
KATY HERRAMIENTAS X
.LEANDRO BAZAN
CRONOGRAMA DE
CINTIA X
ACTIVIDADES
EXPOSICION X
CAPTURA DE REQUISITOS X
.VILLADEZA
ROMERO, KAREN ESPECIFICACION DEL SISTEMA X X
ANALISIS
.MISHAHUAMANGR CUADRO PICTORICO X

ANDES XIBELLY DIAGRAMA DE CONTEXTO X
. MEZA ALONZO
IDEF0 X
PAVEL
EXPOSICION X
IDEF1 X
DIAGRAMA DE CASOS DE USO X
.GONZÁLES RETIS, DIAGRAMA DE CLASES
X X
Franklin
-CADILLO
DIAGRAMA DE
X
DISEÑO
VILLANUEVA, Denys COLABORACION

-POZO ESTRADA, DIAGRAMA DE SECUENCIA X
Angel DIAGRAMA DE ACTIVIDADES X
-GRANIZO
VILLOGAS, Nimrod
DIAGRAM DE COMPONENTES X
DIAGRAMA DE DISTRIBUCION X
EXPOSICION X
ELECCION DEL LENGUAJE DE
X
PROGRAMACION
DISEÑO DE LA INTERFACE
X
GRAFICA
.CHAGUA
CODIFICACION Y
RAMOS, Omar X X X
DOCUMENTACION
-FLORES
CODIGO
COMPILACION Y PRIMERA
MARTINEZ, Joy X X
PUESTA EN MARCHA
-ACOSTA JARA,
ANALIZAR EL PERFIL DE
Diego X X
USUARIO
APLICAR ESTANDARES Y/O
X X
BUENAS PRACTICAS
VERIFICACION DE SOFTWARE X X X X
EXPOSICION X
PRUEBAS UNITARIAS X
. NAUPAY PICON
PRUEBAS DE INTEGRACION X
PROYECTO FINAL
PERCY
PRUEBAS DE SISTEMA X
. VALDIVIA
DESARROLLO X X X X
ESCOBAR
CONCLUCIONES X
JONATHAN
RECOMENDACIONES X
.DIAZ SANCHEZ
CESAR ANEXOS X
EXPOSICION FNAL X
17
2
ANALISIS
18
2.1. INTRODUCCIÓN
Este documento es una Especificación de Requisitos Software (ERS) para el

Sistema de información para el reconocimiento de rutas más optimas desde
las zonas de producción hasta los centros de ventas. Esta especificación se
ha estructurado basándose en las directrices dadas por el estándar IEEE.
Practica recomendada para Especificaciones de Requisitos ANSI/IEEE 830,
1998.
2.1.1. PROPÓSITO
El presente documento tiene como propósito plasmar de forma clara y

concisa todos los requerimientos funcionales y no funcionales del sistema
que se realizara, para la implementación de un sistema en empresas a la
hora de distribuir sus productos a las diferentes tiendas.
El documento está dirigido al cliente y al equipo de desarrollo.

Adicionalmente también puede ser usado por los usuarios que utilizarán el
software y que necesiten definir nuevos requerimientos. Este sistema dará
apoyo a los siguientes procesos dentro de las empresas:
- Logística
- Distribución de productos
2.1.2. ALCANCE
Esta especificación de requisitos está dirigida al usuario del sistema, para

continuar con el desarrollo de aplicaciones educativas sobre la institución
y para profundizar en la automatización de ésta.
19
2.1.3. PERSONAL INVOLUCRADO
Nombre Calixto Tarazona, Vanesa

Rol Analista
Categoría Ingeniero de Sistemas
profesional
Responsabilidades Captura de información
Aprobación Aprobado
Nombre Campos Cabello, Katty

Rol Analista
profesional
Nombre Leandro Bazan, Cinthya

Rol Programador
profesional
Nombre Villadeza Romero, Karen Lucila

Rol Analista
profesional
Responsabilidades Realizar el análisis del sistema
20
Nombre Meza Alonso, Pavel
Rol Analista

profesional
Información de Estudiante
contacto
Nombre Mishahuaman Grandez, Xibelli

Xiomy
Rol Analista
profesional
Nombre Gonzales Retis, Franklin

Rol Analista
profesional
Responsabilidades Realizar el diseño del sistema
Nombre Cadillo Villanueva, Denis
Rol Programador
profesional
21
Nombre Pozo Estrada, Angel
Rol Analista
profesional
Nombre Granizo Villogas, Nimrod

Rol Analista
profesional
Nombre Chagua Ramos, Omar

Rol Programador
profesional
Responsabilidades Codificación del sistema
Nombre Flores Martinez, Joy

Rol Programador
profesional
Nombre Acosta Jara, Diego

Rol Programador
22
profesional
Nombre Naupay Picon, Percy

Rol Analista
profesional
Responsabilidades Realizar las pruebas del
sistema
Nombre Diaz Sanchez, Cesar

Rol Analista
profesional
sistema
Nombre Valdivia Escobar, Jonatan

Rol Analista
profesional
sistema
23
2.1.4. DEFINICIONES, ACRÓNIMOS Y ABREVIATURA
NOMBRE DESCRIPCIÓN
USUARIOS Persona que usara el sistema
ERS Especificación de Requisitos de Software
RF Requerimiento Funcional
RNF Requerimiento no Funcional
2.1.5. REFERENCIAS
Título del documento Referencia

Standard IEEE 830 - 1998 IEEE
2.1.6. RESUMEN
Este documento consta de tres secciones. En la primera sección se realiza

una introducción al mismo y se proporciona una visión general de la
especificación de recursos del sistema.
24
En la segunda sección del documento se realiza una descripción
general del sistema, con el fin de conocer las principales funciones que
éste debe realizar, los datos asociados y los factores, restricciones,
supuestos y dependencias que afectan al desarrollo, sin entrar en
excesivos detalles.
Por último, la tercera sección del documento es aquella en la que se

definen detalladamente los requisitos que debe satisfacer el sistema.
2.2. DESCRIPCIÓN GENERAL
2.2.1. PERSPECTIVA DEL PRODUCTO
En este sistema lo que hará es analizar las rutas de transportes más

accesibles para el abastecimiento de productos hacia los puntos de ventas
(tiendas comerciales) con el menor costo posible para la empresa que lo
emplee.
2.2.2. FUNCIONALIDAD DEL PRODUCTO
Generar las rutas de transporte más óptimas en horas puntas hacia su

destino final (tiendas comerciales)
2.2.3. CARACTERÍSTICAS DE LOS USUARIOS
El sistema cuenta con un usuario final que vendría hacer el conductor el

conductor, persona con nivel escolar promedio de preparatoria, deben
tener conocimientos básicos de computación.
25
2.2.4. PERFIL DE USUARIO
El dueño: Persona encargada de establecer las nuevas rutas a los

centros de distribución que el empleado seguirá para llegar.
Empleado/Conductor: Su rol es de seguir las rutas obtenidas por el

software, si tiene un percance el mismo introducirá el punto de inicio y su
destino final para que sea trazado una nueva ruta que va a conducir.
Administrador del sistema: Usuario con gran conocimiento en el manejo

del sistema con una previa capacitación por parte de la entidad.
Encargado de manejar el sistema con gran responsabilidad sobre los
criterios de permisos sobre los usuarios.
2.2.5. JERARQUÍA DE USUARIOS
ADMINISTRADOR DEL SISTEMA
26
DUEÑO EMPLEADO/ CONDUCTOR
2.3. REQUISITOS ESPECÍFICOS
 Interfaz de usuario
Número de requisito 1
Nombre de requisito Campo de Ingreso al Sistema
Tipo Restricción
Fuente del requisito Interfaz de escritorio
Prioridad del requisito Alta/Esencial
Descripción El sistema contiene una accesible para
los usuarios para consultar las diferentes
posibilidades que ofrece el sistema
 Interfaz de software
Nombre de requisito Menú de aplicación
Tipo Restricción
27
Descripción La debe contener un menú de todas las
posibilidades del usuario una vez este
último accede a su cuenta
Nombre de requisito Campo de Relleno del Archivo
Tipo Restricción
La aplicación debe tener una interfaz para
Descripción permitir a los usuarios de rellenar los
campos del archivo (puede ingresar
nuevas aristas, ver el mapa de la ruta,
crear nuevo proyecto)
28
Nombre de requisito Campo de Eliminar
Tipo Restricción
La aplicación debe tener una interfaz para
Descripción permitir a los usuarios de eliminar nodo,
arista y todas las aristas.
29
Nombre de requisito Mostrar grafo
Tipo Restricción
Permitirá ver la dirección, camino más corto y los
Descripción nodos
 INTERFAZ DE HARDWARE
Será necesario disponer de equipos de cómputos en perfecto estado

con las siguientes características:
 Adaptadores de red.
 Procesador de 1 gigahercio (GHz) o más rápido de 32 bits
(x86) o de 64 bits (x64)
 1 GB de RAM (32 bits) o 2 GB de RAM (64 bits)
30
 16 GB de espacio disponible en el disco duro (32 bits) o 20 GB
(64 bits)
 Mouse.
 Teclado.
 INTERFAZ DE COMUNICACIÓN
Protocolos que se usará TCP/IP.
2.3.1. REQUERIMIENTOS FUNCIONALES

1. RF01
 El sistema permitirá rellenar rutas y distancias en los
campos de registro.
2. RF02
 El sistema llevara un control de rutas optimas de costos
bajos.
3. RF03
 El sistema guardará un registro de rutas comunes, optimas.
4. RF04
 El sistema proporcionara el costo de ruta.
5. RF05
 El sistema permitirá verificar la existencia de rutas.
6. RF06
 El sistema permitirá listar rutas alternativas.
7. RF07
 El sistema podrá ser consultado por cualquier usuario
dependiendo a la modalidad de la empresa.
8. RF08
 El sistema actualizará las rutas según convenga.
9. RF09
31
 El sistema permitirá registrar los puntos de inicio y de final
de las rutas.
10. RF10
 El sistema podrá hacer reportes estadísticos de las rutas
más comunes.
11. RF11
 El sistema podrá reiniciar los puntos de inicio y final si en
caso hay averías en el recorrido.
2.3.2. REQUERIMIENTOS NO FUNCIONALES.

a. Requisitos de rendimiento
 El resultado de las rutas óptimas debe de realizarse en

menos de 15 a 20 segundos, para que los usuarios no deban
de esperar demasiado.
 Los cálculos de las rutas óptimas deberán de ser en un
tiempo eficiente y rápido.
 El tiempo de respuesta debe de ser lo más rápido posible.
 El sistema siempre debe de estar conectado a una red de
internet si es posible.
 El sistema debe de sincronizar las peticiones de los usuarios,
es decir, estar aptos para interactuar en tiempo real.
b. Seguridad
 Para prevenir de una caída del sistema y/o pérdidas de
información, el sistema tendrá una opción de hacer copias de
seguridad para no perder los datos.
 Por ello, el número mayor de datos que podemos perder es
el de los guardados desde la última copia de seguridad de
nuestra base de datos.
32
c. Fiabilidad
 El sistema debe tener un grado alto de fiabilidad y robustez.
 Se debe prevenir y tratar cualquier error, mostrando un
mensaje de información acerca de lo ocurrido, es decir,
garantizamos la correcta captura excepciones.
 El sistema deberá advertir ante posibles operaciones o
acciones inválidas o erróneas que puedan provocar errores.
d. Disponibilidad
 El sistema se ejecuta directamente, así que estará
disponible en cualquier momento.
 La base de datos debe ser instalada y configurada para su
uso por parte del sistema en el local.
e. Mantenibilidad
 El sistema tendrá la posibilidad de dejarse en marcha una
larga duración de tiempo, para el mantenimiento cuando lo
requiera.
 Para la evaluación de estadísticas se implementará el
GOOGE ANALYTICS.
f. Portabilidad
 La portabilidad es amplia estará disponible tanto en S.O
Windows 32 /24 bits y Linux amd64 de cualquier “DISTRO”.
 Deberá ser fácilmente actualizable. Las tareas de
mantenimiento, tales como actualizaciones a nuevos
entornos hardware, serán resueltas por los programadores
 El gestor de la base de datos debe ser compatible con estos
equipos.
33
IDEF0
34
CUADRO PICTÓRICO
3
DISEÑO
3.1. IDENTIFICACIÓN DE ENTRADAS:
 Ruta
 Distancia
3.2. IDENTIFICACIÓN DEL CONTROL:

 Costo de ruta.
 Dirección.
3.3. IDENTIFICACIÓN DE LAS HERRAMIENTAS:
 Vehículo.
 Mapa de ruta
3.4. IDENTIFICACIÓN DE LAS SALIDA:
 Ruta optima.
37
Luego de tener una vista general de lo que hara el sistema pasamos a explotar.
Lo que va hacer los subsistemas en este caso para nosostros es.
3.5. SUBSISTEMAS
3.5.1. DISEÑAR RUTA.
ENTRADA.
 Ruta.
CONTROL:
 Direccion.
HERRAMIENTAS:
 Vehiculo.
 Mapa
3.5.2. ASIGNAR RUTA.
ENTRADA:
 Diseño
CONTROL:
 costo de ruta.
HERRAMIENTA:
 mapa
38
3.5.3. MOSTRAR RUTA.
3.6. CASO DE USO DEL NEGOCIO
El proceso inicia cuando el conductor y el sistema interactúan para hacer

el proceso de: registrar ruta, luego el administrador conjuntamente con el
sistema interactúan en el proceso de: registrar pedido, registrar costo,
programar conductor, y el administrador verifica que todo este proceso se
realiza correctamente.
3.6.1. ACTORES DEL NEGOCIO

 Conductor
 Administrador
 Sistema
39
3.6.2. DIAGRAMAS DE CASOS DE USO
3.7. CASO DE USO DEL SISTEMA
Los casos de uso son una técnica para especificar el comportamiento de un sistema:
“Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo
que usa alguno de sus servicios.”
40
Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de
servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un
sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los
sistemas son usados no sólo por personas, sino también por otros sistemas de
hardware y software.
3.7.1. INTERACCIÓN DEL ADMINISTRADOR Y EL SISTEMA.
41
3.7.2. INTERACCIÓN DEL CONDUCTOR Y EL SISTEMA.
42
3.7.3. CASO DE USO DEL GENERAL DEL SISTEMA
CREAR CONDUCTOR
CASO DE USO Registrar conductor
Autores Administrador, sistema
Descripción El Administrador registra conductor.
Precondición El Administrador verifica en el sistema los datos correspondientes al

conductor.
43
Secuencia Paso Acción
Normal 1 Si el conductor está registrado. El Administrador deberá

actualizar los datos en el sistema.
2 El Administrador, registra un nuevo conductor en el sistema,

siempre y en cuando este no se encuentra registrado.
Postcondición El Administrador registra al conductor
Excepciones Paso Acción
1 Si los datos del conductor son incorrectas el Administrador

cancela la operación.
2 Si en caso el conductor, se encuentra registrado el

Administrador cancela la operación.
Rendimiento Paso Cota de tiempo
1 4 minutos
CONSULTAR CONDUCTOR
CASO DE USO Consultar conductor
Autores Administrador, sistema
Descripción El Administrador consulta conductor.
Precondición El Administrador verifica en el sistema los datos existentes del

conductor.
Secuencia Normal Paso Acción
1 El Administrador deberá verificar los datos del conductor en

el sistema.
44
2 Si el conductor es existente en el registro está apto para ser
programado a una zona de entrega.
Postcondición El Administrador ingresa al sistema para verificar los datos

correctos del conductor
1 Si los datos del conductor son incorrectas el Administrador

modificara los datos correctamente.
2 Si los datos del conductor son correctos, el Administrador

guardara los cambios en el sistema.
1 4 minutos
PROGRAMAR CONDUCTOR
CASO DE USO Programar conductor
Autores Administrador, Sistema
Descripción El Administrador programa un conductor disponible.
Precondición El Administrador no puede programar un conductor sin antes

verificar la existencia en el sistema.
1 El Administrador deberá verificar en el sistema el estado del

conductor (registrado, no registrado).
2 Si el conductor se encuentra registrado, el Administrador

procederá a programar al conductor.
Postconpostcondición El Administrador programa un conductor.
45
1 Si el conductor no se encuentra registrado, el Administrador
dará por cancelado la programación del conductor.
2 Si el conductor se encuentra registrado correctamente en el

sistema, se realiza la programación del conductor.
1 5 minutos
Comentarios A la hora de programar un conductor esta debe estar registrado,

caso contrario se elegirá otro conductor.
PROGRAMAR VEHÍCULO
CASO DE USO Registrar vehículo
Descripción El Administrador programa un conductor disponible.
Precondición El Administrador verifica en el sistema el estado y características

correspondientes del vehículo.
1 Si el vehículo está registrado. El Administrador deberá

actualizar los datos en el sistema.
2 El Administrador registra un nuevo vehículo en el sistema,

siempre y en cuando este no se encuentra registrado.
PostconPost-condición El Administrador programa un conductor.
1 Si los datos del vehículo son incorrectas el Administrador

cancela la operación.
46
2 Si en caso el vehículo, se encuentra registrado el
Administrador cancela la operación.
1 5 minutos
Comentarios El Administrador verifica en el sistema el estado correspondiente del

vehículo.
ASIGNAR RUTA
CASO DE USO Asignar ruta óptima
Descripción El Sistema asignara la ruta óptima.
Precondición El sistema verifica varias alternativas para luego elegir la ruta más
óptima
1 El sistema recolecta información acerca de las rutas mas

optimas
2 Si el sistema obtiene información de la ruta más óptima,

asignara su aprobación.
postcondición El Sistema asignara la ruta
1 Si la ruta asignada es inaccesible, el sistema asignara otra

ruta alternativa
47
1 18 segundos
Comentarios El sistema diagnostica varias rutas incluyendo rutas alternativas.
SOLICITAR RUTA OPTIMA
CASO DE USO Solicitar ruta optima y puntos de entrega
Autores Conductor
Descripción El conductor solicita la ruta óptima y los puntos de entrega.
Precondición El conductor no puede tomar una ruta sin antes haber

consultado al sistema cual es la ruta más óptima.
Secuencia Paso Acción
Normal 1 El conductor verifica en el sistema los puntos de

entrega y la ruta más óptima.
2 El conductor verifica la aprobación de los puntos de

entrega y de la ruta más óptima.
Postcondición El conductor verifica en es el sistema la ruta optima
1 Si la ruta más óptima es inaccesible se cancelara, y

recurrirá a tomar otra ruta alternativa.
2 El conductor toma la ruta alternativa más óptima.
1 1 minutos
Comentarios El sistema calculara un punto de inicio y un punto final

incluyendo rutas alternativas.
48
Una vez salido el conductor luego de un punto de entrega la
ruta es inaccesible, el conductor se comunicara con el
administrador por cualquier medio (celular, correo, redes
sociales, etc.) para tomar otra ruta alternativa.
REGISTRAR PUNTOS DE ENTREGA
CASO DE USO Registrar puntos de entrega
Descripción El Administrador registra puntos de entrega
Precondición El Administrador verifica en el sistema los datos

correspondientes de los puntos de pedido.
1 Si los puntos de entrega está registrado. El

Administrador deberá actualizar los detalles en el
sistema.
2 El Administrador, registra un nuevo punto de entrega

en el sistema, siempre y en cuando este no se
encuentra registrado.
Postcondición El Administrador registra los puntos de entrega
1 Si los datos de los puntos de entrega son incorrectas

el Administrador cancela la operación.
2 Si en caso que el punto de entrega se encuentra

registrado el Administrador cancela la operación.
49
1 1 minutos
Comentarios El administrador verifica en el sistema los puntos de entrega

para ser asignado a cada zona.
3.8. DIAGRAMA DE ACTIVIDADES
Un Diagrama de Actividades no es más que un caso especial de un diagrama de

estados, en el que todos los estados (o la gran mayoría) son actividades. Un
Diagrama de Actividades muestra el flujo de control entre una serie de tareas o
actividades. Los Diagramas de Actividades son usados (entre otras cosas) para
elaborar modelos de flujos de trabajo de un sistema. En general, un Diagrama de
Actividades muestra una serie de acciones o tareas que se ejecutan en cierto
orden (y otros elementos adicionales). Un flujo de trabajo se puede ver como una
serie de tareas (acciones) que son ejecutadas o realizadas por ciertos actores en
cierto orden preestablecido.
A cada actividad se le representa con un rectángulo de esquinas redondeadas. El

procesamiento dentro de una actividad se lleva a cabo y, al realizarse, se continúa
con la siguiente actividad. Una flecha representa la transición de una actividad a
otra. El punto inicial del diagrama se representa con un círculo relleno y uno final
representado por una diana.
3.8.1. COMPONENTES BASICOS

Actividad: Es la especificación de un comportamiento que puede ser
parametrizado y que define la secuenciación coordinada de unidades
subordinadas denominadas acciones.
Acción:
Una acción es la unidad fundamental de especificación de comportamiento. Una
acción es generalmente atómica, es decir, indivisible
Transiciones:
Representan el paso de una acción a otra
50
3.8.2. DIAGRAMA DE ACTIVIDADES DEL PROYECTO
 Acceder Al Sistema
 Registrar Puntos de Entrega
 Asignar Zona
 Solicitar La Ruta Optima
 Modificar La Ruta Optima
a) ACCEDER AL SISTEMA
51
b) REGISTRAR PUNTOS DE ENTREGA
52
c) ASIGNAR ZONA
53
d) SOLICITAR LA RUTA OPTIMA
54
e) MODIFICAR RUTA OPTIMA
55
4
CODIFICACIÓN
56
4.1. CONSTRUCCIÓN DEL ALGORITMO
4.1.1. EL ALGORITMO DE PRIM
Es un algoritmo perteneciente a la teoría de los grafos para encontrar un

árbol recubridor mínimo en un grafo conexo, no dirigido y cuyas aristas
están etiquetadas.
En otras palabras, el algoritmo encuentra un subconjunto de aristas que

forman un árbol con todos los vértices, donde el peso total de todas las
aristas en el árbol es el mínimo posible. Si el grafo no es conexo, entonces
el algoritmo encontrará el árbol recubridor mínimo para uno de los
componentes conexos que forman dicho grafo no conexo.
El algoritmo fue diseñado en 1930 por el matemático Vojtech Jarnik y luego

de manera independiente por el científico computacional Robert C. Prim en
1957 y redescubierto por Dijkstra en 1959. Por esta razón, el algoritmo es
también conocido como algoritmo DJP o algoritmo de Jarnik.
En resumen el AP consiste en encontrar el árbol de expansión mínimo que

tiene un grafo que debe ser conexo, no dirigido, vértices etiquetados,
ponderar las aristas
57
4.1.2. EL ALGORITMO DE DJKASTRA
También llamado algoritmo de caminos mínimos, es un algoritmo para la
determinación del camino más corto dado un vértice origen al resto de los
vértices en un grafo con pesos en cada arista. Su nombre se refiere a
Edsger Dijkstra, quien lo describió por primera vez en 1959.
La idea subyacente en este algoritmo consiste en ir explorando todos los
caminos más cortos que parten del vértice origen y que llevan a todos los
demás vértices; cuando se obtiene el camino más corto desde el vértice
origen, al resto de vértices que componen el grafo, el algoritmo se detiene.
El algoritmo es una especialización de la búsqueda de costo uniforme, y
como tal, no funciona en grafos con aristas de coste negativo (al elegir
siempre el nodo con distancia menor, pueden quedar excluidos de la
búsqueda nodos que en próximas iteraciones bajarían el costo general del
camino al pasar por una arista con costo negativo).
Una de sus aplicaciones más importantes reside en el campo de la
telemática, gracias a él, podemos resolver grafos con muchos nodos, los
cuales serían muy complicados de hacer sin dicho algoritmo, encontrando
así las rutas más cortas entre un origen y todos los destinos en una red.
4.2. CAMINO MAS CORTO

En base al algoritmo Dijkstra obtendremos el camino más corto y según los
pesos de Aristas en el siguiente código vemos que con el método
getAcumulado() obtendremos todos los pesos comenzando un cliclo for
desde el nodo inicia al nodo final previamente seleccionado.
do {
nodo[permanente].setEtiqueta(true);
for (int j = 0; j < tope; j++) {
if (posi.getmAdyacencia(j, permanente) == 1) {
subAcomulado = nodo[permanente].getAcumulado() +
posi.getmCoeficiente(j, permanente);
if (subAcomulado <= nodo[j].getAcumulado() &&
nodo[j].isVisitado() == true && nodo[j].isEtiqueta() == false) {
58
nodo[j].setAcumulado(subAcomulado);
nodo[j].setVisitado(true);
nodo[j].setNombre(j);
nodo[j].setPredecesor(nodo[permanente]);
} else if (nodo[j].isVisitado() == false) {
nodo[j].setAcumulado(subAcomulado);
nodo[j].setVisitado(true);
nodo[j].setNombre(j);
nodo[j].setPredecesor(nodo[permanente]);
}
En la siguiente interfaz podemos ver que se muestra el camino más corto

desde dos puntos determinado, mediante este ciclo for haremos que la
suma acumulado se vaya guardando en una variable permanente según se
vaya recorriendo los nodos.
for (int i = 0; i < tope; i++) {

if (nodo[i].isVisitado() == true && nodo[i].isEtiqueta() == false){
if (nodo[i].getAcumulado() <= auxAcumulado) {
permanente = nodo[i].getNombre();
auxAcumulado = nodo[i].getAcumulado();
}
59
}
}
subTope++;
} while (subTope < tope + 1);
4.3. RUTAS ALTERNAS

Dado a nuestra problemática nos hemos planteado rutas alternar en caso
una ruta optima no esté disponible por alguna dificultad. Nuestra aplicación
tendrá la funcionalidad de eliminar la arista que en este caso presentaría alguna
dificultad, dado esto se volvería generar la ruta óptima.
En la siguiente interfaz mostramos la funcionalidad de las rutas alternas

que recibe los nodos involucrados en la arista a eliminar siempre en cuando el
grafos generado tenga al menos 2 nodos, se utilizara el método
EliminarAristas()
60
if (tope >= 2) {
this.setEnabled(false);
new EliminarAristas(pintar, arboles, tope,
this).setVisible(true);
} else {
JOptionPane.showMessageDialog(null, "No Hay
Nodos Enlazados... ");
}
61
En esta parte del código se expresa forma en cómo se eliminará la arista y
los mensajes de validación en caso el usuario no ingrese campos correctos.
if (ax==1) {
JOptionPane.showMessageDialog(null, "VUELVA A INDICAR
LOS NODOS DE INICIO Y FIN "
+ "\n(TAMBIEN USAR EL CLICK DERECHO PARA
SELECCIONAR "
+ "\nEL NODO INICIO Y EL NODO FINAL)");
}
int x;
int y;
if (n1.getText().length() < 1 || n2.getText().length() < 1) {

JOptionPane.showMessageDialog(null, "Error.. Faltan datos : ");
} else {
x = Integer.parseInt(n1.getText());
y = Integer.parseInt(n2.getText());
if (x == y) {
JOptionPane.showMessageDialog(null, "Error.. Debe digitar
un nodo diferente a : " + y);
} else if (x < 0 || x >= i || y < 0 || y >= i) {
JOptionPane.showMessageDialog(null, "Error.. Nodos No
validos ");
} else {
arboles.setmAdyacencia(x, y, 0);
arboles.setmAdyacencia(y, x, 0);
arboles.setmCoeficiente(x, y, 0);
arboles.setmCoeficiente(y, x, 0);
n1.setText(null);
n2.setText(null);
62
VentanaPrincipal.jPanel1.paint(VentanaPrincipal.jPanel1.getGr
aphics());
}
}
63
5
PRUEBAS
64
5.1. ALCANCE DE LAS PRUEBAS
Teniendo en cuenta los documentos hechos anteriormente, el grupo de trabajo
pretende realizar las pruebas, de manera incremental, por módulo, la cual se
adaptará dependiendo del artefacto que es un producto tangible resultante del
proceso de desarrollo de software a probar, según la categoría de pruebas.
 Conectividad/Performance: Para chequear los tiempos de respuesta y de

acceso al sistema de acuerdo con la arquitectura del sistema.
 Correctitud: Para verificar que el producto se comporta de acuerdo con las
especificaciones funcionales que debería proveer. Es una propiedad
absoluta: cualquier desviación implica un software no−correcto.
 Confiabilidad: Para medir la probabilidad de ocurrencia de fallas, esta es
una medida relativa: ya que un software puede ser confiable si la
consecuencia de un error no es seria; o si la cantidad de errores por unidad
de tiempo no es alta.
 Escalabilidad: Un software es escalable si permite cambios que lo hacen
capaz de satisfacer nuevos requerimientos. Esta cualidad se logra
mediante un buena popularización.
 Funcionalidad: Para asegurar que el sistema realiza sus funciones
normales de manera correcta.
 Seguridad: Acceso remoto y local al sistema haciendo uso de nombre de
usuario y contraseña.
5.1.2. ELEMENTOS DE PRUEBAS
Listado de todos los módulos, componentes o elementos que se van a probar. Si

es de alto nivel, se listan las áreas funcionales (módulos o procesos que cubre el
Testing), por otro lado, si es de un nivel detallado se listan los programas,
unidades o módulos.
 Requerimientos: Si los requerimientos son lógicos y si es que se pueden

adecuar al software determinado en el tiempo establecido.
 Análisis: Si es que los casos de uso del software están bien establecidos
conforme a los requerimientos.
 Diseño: Si los diagramas lógicos cumplen con los casos de uso del sistema
y tienen una secuencia lógica.
 Programación: Si es que se adecua a todo lo mencionado anteriormente y
a la funcionabilidad de todos los módulos establecidos.
5.1.3. NUEVAS FUNCIONALIDADES A PROBAR

Es un listado de lo que se va a probar “desde el punto de vista del usuario”. No es una
descripción técnica del software sino sus características y funcionalidades. Se incluyen
tanto las que son nuevas como las que se están modificando.
5.1.4. OBJETOS QUE SE VAN A EVALUAR

Los componentes del software que serán evaluados son los siguientes:
 TextBox
 Labels
65
 Combobox
 Botones
 Base de datos.
5.1.5. ÁMBITO DE LAS PRUEBAS
El conjunto de tareas necesarias para conseguir el objetivo del proyecto son el

verificar uno por uno cada uno de los componentes del sistema, se revisarán
desde el primer TextBox hasta el último, también se revisarán las ubicaciones de
cada uno de los componentes; en cuanto a los Labels se refiere se realizará una
revisión exhaustiva con respecto a la ortografía en la redacción al igual que con
los ComboBox y que los botones cumplan con las especificaciones para las cuales
fueron diseñados. No se considera importante la revisión de la forma en que se
muestran los resultados ya que se buscó la mejor alternativa para que éstos fueran
presentados al cliente.
A) DENTRO DEL ÁMBITO
La estructura de pruebas que está en uso en la iteración actual se podrá utilizar

para probar la implementación de la solución en su entorno, es decir, las que
prueban que verdaderamente el sistema cumple con lo que se estableció como
elemental o prioritario, es decir, la satisfacción del cliente. Estas pruebas se
describen más adelante para mayor entendimiento. Las características que
evaluar son:
 Revisión de TextBox
 Revisión de Labels (Hacer énfasis en ortografía)
 Revisión de Botones
 Revisión de Base de datos (Que los datos se guarden correctamente).
5.1.6. LISTA DE IDEAS DE LAS PRUEBAS
Las pruebas serán identificadas siguiendo la técnica de generación de casos de

prueba a través de los casos de uso, detallando los siguientes pasos:
 Para cada caso de uso, se identifican los posibles caminos, estableciendo
los escenarios.
 Para cada uno de los caminos, se identifican los conjuntos de valores de
entrada y precondiciones, al igual que el resultado esperado.
 Se hace, a través de una tabla, un resumen por cada caso de uso que
muestre los distintos caminos posibles con sus entradas y salidas.
Los recursos utilizados para la identificación de las pruebas se mencionan a

continuación:
66
 El documento de especificación de requerimientos del software.
 El documento de arquitectura de software.
 Generación de pruebas de sistema a partir de la especificación funcional.
 Mejora de la calidad de los requisitos mediante la generación de pruebas.
 Especificación e implementación de casos de prueba.
5.1.7. ENFOQUE DE PRUEBAS (ESTRATEGIA)
Los tipos de pruebas que se realizarán al software son:

 Pruebas de Función
 Pruebas de confiabilidad
 Pruebas de usabilidad
 Pruebas de eficiencia
 Pruebas de capacidad de mantenimiento
 Pruebas de portabilidad
 Pruebas de calidad de uso
 T-01: Pruebas de función.
Objetivo: El objetivo principal de esta prueba es que el programa

realice las funciones especificadas.
Descripción: En esta prueba se probará que cada elemento realice la

función específica para la cual fue diseñado.
Técnicas: Se probará cada uno de los elementos a prueba y error

usando un usuario que no tenga conocimiento absoluto
sobre lo que es el sistema.
Fases: 1.Fase de revisión de cajas de texto
2. Fase de revisión de botones
3. Fase de revisión de ComboBox
4.Fase de revisión de Base de base de datos
Entorno de Se realizará una prueba que verifique que cada caja de

prueba: texto envíe los datos al lugar que le fue asignado en la Base
de Datos, que cada una de las etiquetas concuerde con la
caja de texto que se le asigno en el diseño, se revisará que
al dar click al botón Guardar imagen inserte el registro
correspondiente en la Base de Datos, al presionar el botón
67
realice las funciones especificadas.
Nuevo proyecto podamos crear un nuevo proyecto o ruta
trazar, al oprimir Google maps muestre un mapa y el lugar
donde te encuentres, al dar click en cargar mapa nos
permita seleccionar la dirección donde deseamos guardar
en nuestro computador, al presionar Ruta alterna nos cree
una ruta alterna a la que tenemos, y al dar click en el menú
archivos muestre camino más corto y demás funciones y
dar click en salir para que cierre la aplicación.
Hardware: El programa se puede ejecutar perfectamente en una

computadora que contenga un procesador celeron o
equivalente a 2.6 Ghz y 256 MB en RAM.
Software: En este caso solo se requiere que para la prueba se cuente

con Netbeans en cualquiera de sus distintas versiones.
Criterios de Los botones funcionarán adecuadamente si cada uno

Éxito: cumple con el propósito establecido en el diseño, pero las
rutas trazadas aparecen en diagonales sin seguir la ruta de
las calles.
 T-02: Prueba de confiabilidad
Objetivo: El objetivo principal de esta prueba es que el programa no

tenga fallas de rendimiento ni bajo ciertas condiciones.
Descripción: En esta prueba se probará que el programa no tenga fallas

al crear o modificar las rutas y que si sufre algún cierre
inesperado los datos puedan recuperarse.
Técnicas: Se probará crear rutas y que podamos abrir una vez

guardadas, cerrar intencionalmente cuando aún no se han
guardado los datos.
Fases: 1. Fase de revisión de datos guardados.
2. Fase de revisión de datos no guardados.
Entorno de Se realizará una prueba que verifique que los datos guarden
prueba: correctamente en la base de datos y en nuestro
68
Objetivo: El objetivo principal de esta prueba es que el programa no
tenga fallas de rendimiento ni bajo ciertas condiciones.
computador, que no se congele el programa, cuando no se
pudo guardar los datos se puedan recuperar.


Criterios de Éxito:
 T-03: Prueba de usabilidad:
Objetivo: El objetivo principal de esta prueba es que el programa sea

fácil de usar y aprender.
Descripción: En esta prueba se probará que cualquier usuario que no

sepa el funcionamiento de programa pueda utilizarlo y
pueda aprenden para que sirve.
Técnicas: Se probará cada uno de los elementos a prueba y error,

usando un usuario que no tenga conocimiento absoluto
sobre lo que es el sistema.
Fases: 1. Fase de revisión de Login.
2. Fase de revisión Interface.
3. Fase de revisión de operatividad.
4. Fase de revisión de atracción.
Entorno de Se realizará una prueba que verifique que el usuario puede

prueba: logearse, que este bien diseñada la interface, sea
interactiva, entendible y sea de buen agrado para el cliente.

69
fácil de usar y aprender.

 T-04: Prueba de eficiencia

tenga un tiempo de respuesta rápido y los recursos que usa.
Descripción: En esta prueba se probará que el tiempo de respuesta sea

la recomendada y los recursos como tiempo sea el óptimo.
Técnicas: Se probará que sea rápido y minimalista en cuanto a uso de

recursos, bajo ciertas condiciones en el programa.
Fases: 1. Fase de revisión de tiempo de respuesta.
Entorno de Se realizará una prueba que verifique el tiempo de

prueba: respuesta y que el uso la RAM del computador sea el
mínimo.


 T-05: Prueba de capacidad de mantenimiento
70
fácil de modificar y adaptarlo.
Descripción: En esta prueba se probará que el programa pueda tener

actualizaciones o modificaciones para nuevas funciones y
sea fácil adaptar estas mismas y todos los elementos sigan
funcionando correctamente.
Técnicas: Se probará cada uno de los elementos que al ser

actualizados no cambian en su entendimiento y fácil uso de
los usuarios.
Fases: 1. Nueva actualización
2. Fase de revisión de cajas de texto
3. Fase de revisión de botones
4. Fase de revisión de ComboBox
5.Fase de revisión de Base de base de datos
Entorno de Se realizará una prueba que verifique las nuevas funciones

prueba: y que cada caja de texto envíe los datos al lugar que le fue
asignado en la Base de Datos, que cada una de las
etiquetas concuerde con la caja de texto que se le asigno
en el diseño, se revisará que al dar click en los botones y
todos los elementos sigan funcionando correctamente.


 T-06: Pruebas de portabilidad
71
pueda relacionarse con otros programas y su fácil
instalación en cualquier computador.
Descripción: En esta prueba se probará que sea fácil compartir los datos
y su instalación.
Técnicas: Se probará al instalarlo en diferentes computadores y

relacionándolo con otros programas.
Fases: 1. Fase de revisión de instalación.
2. Fase de revisión relación.
Entorno de Se realizará una prueba que verifique que la instalación sea

prueba: muy fácil y sea más fácil al usarlo en lugar de otro software.


con el C# en cualquiera de sus distintas versiones.
 T-06: Pruebas de calidad de uso
Objetivo: El objetivo de la prueba de desempeño es proporcionar el

rendimiento del sistema, y verificar que éste sea bueno.
Descripción: Esta prueba nos indica si el rendimiento de la aplicación es

el óptimo, para no dejar duda alguna en el cliente a la hora
que éste lo pruebe.
72
Objetivo: El objetivo de la prueba de desempeño es proporcionar el
rendimiento del sistema, y verificar que éste sea bueno.
Técnicas: Se revisará el desempeño del sistema en una computadora

con procesador celeron o equivalente a 2.6 Ghz
Fases: 1. Se realizará dentro de la empresa, en la máquina

asignada por la alta gerencia, y se comparará el resultado
de la prueba contra el que se da por óptimo.
Entorno de Se realizará una prueba que verifique que cada caja de

prueba: texto envíe los datos al lugar que le fue asignado en la Base
de Datos, que cada una de las etiquetas concuerde con la
caja de texto que se le asigno en el diseño, se revisará que
al dar click al botón AddNew inserte el registro
correspondiente en la Base de Datos, al presionar el botón
Edit podamos modificar el registro que tenemos
seleccionado, al oprimir Delete elimine el registro
sellecionado, al dar click en Save nos guarde los cambios,
al presionar Cancel no guarde cambio alguno, y al dar click
en el botón click cierre la aplicación.


con el C# en cualquiera de sus distintas versiones.
Criterios de Éxito: Los botones funcionarán adecuadamente si cada uno

cumple con el propósito establecido en el diseño.
5.1.8. PRUEBAS DE REGRESIÓN

Pruebas de regresión son pruebas de un programa previamente probado que ha
sufrido modificaciones, para asegurarse que no se han introducido o descubierto
defectos en áreas del software que no han sido modificadas como resultado de
los cambios realizados. Se realiza cuando el software o su entorno han sido
modificados.
El punto crítico del sistema a pruebas, es la búsqueda del camino mas corto,
optimizando de esa forma el costo de la ruta en una determinada zona
73
5.1.9. FUNCIONALIDADES A NO PROBAR
Listado de las funcionalidades que no se van a probar. Debe incluir información
de las razones por las cuales no se van a probar y los riesgos que se están
asumiendo.
5.1.10. ENFOQUE DE PRUEBAS (ESTRATEGIA)

La estrategia de pruebas puede definirse como un documento por separado, o
puede ser incluido dentro del plan de pruebas según su extensión. Aquí pueden
definirse los tipos de pruebas a realizar (funcionales, de desempeño, de
interfaces, no funcionales, etc.), requerimientos especiales de las pruebas,
configuraciones a probar, subconjuntos de datos a considerar, nivel de pruebas
de regresión, entre otros aspectos.
74
5.2. CRITERIOS DE ACEPTACIÓN O RECHAZO
TABLA – PREGUNTAS GENERALES.
CARACTERÍS PREGUNTA CRITERIO PREGUNTA
TICA
Funcionalidad ¿Las funciones y ADECUACION ¿Tiene el conjunto de funciones apropiadas para las tareas
Propiedades especificadas?
satisfacen las EXACTITUD ¿Hace lo que fue acordado en forma esperada y correcta
necesidades
Explícitas e INTEROPERABILIDAD ¿Interactúa con otros sistemas especificados?
implícitas? CONFORMIDAD ¿Está de acuerdo con las leyes o normas y estándares, u otras
prescripciones?
Confiabilidad ¿Puede mantener MADUREZ ¿Con qué frecuencia presenta fallas por defectos o errores?
el nivel de TOLERANCIA A ERRORES ¿Si suceden fallas, como se comporta en cuanto a la performancia
rendimiento, bajo especificada?
ciertas condiciones RECUPERABILIDAD ¿Es capaz de recuperar datos en caso de fallas?
y por cierto tiempo?
Usabilidad ¿El software, es ENTENDIMIENTO ¿Es fácil de entender y reconocer la estructura y la lógica y su
fácil de usar y de aplicabilidad?
aprender? APRENDIZAJE ¿Es fácil de aprender a usar?
OPERABILIDAD ¿Es fácil de operar y controlar?
ATRACCIÓN ¿Es atractivo el diseño del software?
Eficiencia ¿Es rápido y COMPORTAMINETO DE ¿Cuál es el tiempo de respuesta y performancia en la ejecución de
minimalista en TIEMPOS la función?
cuanto a uso de UTILIZACION DE RECURSOS ¿Cuántos recursos usa y durante cuánto tiempo?
recursos, bajo
ciertas
condiciones?
Capacidad de ¿Es fácil de CAPACIDAD DE SER ¿Es fácil diagnosticar una falla o identificar partes a modificar?
mantenimiento modificar y testear? ANALAIZADO
CAMBIALIDAD ¿Es fácil de modificar y adaptar?
ESTABILIDAD ¿Hay riesgos o efectos inesperados cuando se realizan cambios?
FACILIDAD DE PRUEBA ¿Son fáciles de validar las modificaciones?
Portabilidad ¿Es fácil de ADAPTABILIDAD ¿Es fácil de adaptar a otros entornos con lo provisto?
transferir de un FACILIDAD DE INSTALACION ¿Es fácil de instalar en el ambiente especificado
ambiente a otro? REMPLAZABILIDAD ¿Es fácil de usarlo en lugar de otro software para ese ambiente?
COEXISTENCIA ¿Comparte sin dificulta recursos con otro software o dispositivo?
Calidad de uso ¿Muestra el usuario EFICACIA ¿La eficaz el software cuando el usuario final realiza los procesos?
final aceptación y PRODUCTIVIDAD ¿Muestra el usuario final rendimiento en sus tareas cotidianas del
seguridad del proceso específico?
software? SEGURIDAD ¿El software tiene niveles de Riesgo que causan daño al usuario
final?
76
5.2.1. CRITERIOS DE SUSPENSIÓN
Haremos mención a los siguientes:
 Fallas en las primeras versiones del programa

 Demasiadas fallas en la última versión del programa
 Falla del hardware que está realizando las pruebas del proyecto
 Mal estado de salud del personal de pruebas
5.2.2. CRITERIOS DE REANUDACIÓN
Considerando los criterios de suspensión se tomará en cuenta lo siguiente:

 Corrección de las fallas del programa y la base de datos
 Reducción o eliminación de fallas de la versión final del proyecto
 Hacer uso de otro hardware que soporte el programa y/o arreglar el que ya
se tiene
 Recuperación de estado de salud del personal o reemplazo por otro que
esté capacitado en el tema.
5.3. ENTREGABLES
Se establece que documentos se van a generar, durante el desarrollo del plan
de pruebas, las cuales servirán para ver el correcto avance de los parámetros,
metodologías utilizadas a lo largo de este proceso, de las cuales se hará un
listado:
Documento nro. Nombre de Entregable

1 Plan de pruebas del sistema
2 Informe de los resultados de las pruebas
3 Descripción de las pruebas, el resultado esperado,
resultado obtenido y acciones a tomar para corregir las
desviaciones
4 Resultados de las pruebas a la documentación
La descripción de los casos de prueba, serán una herramienta fundamental para

las descripciones de cada una de las funcionalidades más relevantes a probar, a
continuación, se da una breve descripción de la documentación
CASOS DE PRUEBAS:
La forma de verificar las diversas funcionalidades de un producto de software,

descritas en el formato de casos de uso, son el punto de partida para la
preparación de casos de prueba y, en ocasiones, de procedimientos de prueba.
Formato de casos de Prueba

Objetivo del caso de Prueba
Identificador
Nombre del caso
Precondiciones
Pasos Resultado Esperado
OBSERVACIONES
CALIFICACION
Reporte de errores: Este artefacto es de características técnicas y describirá

todos los errores, fallas y defectos encontrados en los productos testeados, ya
sean de código abierto, o cerrado.
Desarrollarlo es responsabilidad del Analista de Sistemas, y lo hace basándose
en los
Documentos de Casos de Pruebas ejecutados por los testers. Está dirigido al
equipo de implementación para la posterior depuración de los mismos.
Informe de Resultados Obtenidos: Este artefacto organiza y muestra un

análisis de los resultados de las pruebas, puede contener un enunciado general
de la calidad relativa al sistema que se está probando y ofrecer recomendaciones
para futuros procesos de prueba. Este informe se desarrolla tanto en sistemas de
código abierto como de código cerrado. El responsable de generar este artefacto
es el Líder de Proyecto.
5.4. RECURSOS
5.4.1. REQUERIMIENTOS DE ENTORNOS – HARDWARE
 Procesador.
 RAM.
 Disco externo.
 Disco interno.
 Unidades de almacenamiento.
 Monitor.
 Red.
 Mouse.
 Laptop.
 Teclado.
.
5.4.2. REQUERIMIENTOS DE ENTORNOS – SOFTWARE
 Base de datos.
 Sistema operativo.
 Componentes de Windows.
 Netbeans.
 Xampp.
5.4.3. HERRAMIENTAS DE PRUEBAS REQUERIDAS

 Test Studio – Una herramienta para pruebas de rendimiento, carga,
pruebas automáticas, gestión de pruebas y test exploratorio.
78
5.4.4. PERSONAL
Nombre del Recurso Responsables

Analistas de Requerimientos Katy.
Vanesa.
Cinthia.
Equipo de Análisis Karen.
Xibelly.
Pavel.
Equipo de Diseño Franklin.

Denis.
Ángel.
Nimrod.
Equipo de Programación Omar.

Joy.
Diego.
Equipo de Pruebas Percy.

Jonathan.
Cesar.
5.4.5. ENTRENAMIENTO
Necesidades de entrenamiento en el sistema o aplicación, así como en las
herramientas de prueba a utilizar.
5.5. PLANIFICACIÓN Y ORGANIZACIÓN
5.5.1. PROCEDIMIENTOS PARA LAS PRUEBAS

Especifica los procedimientos o metodología de pruebas a emplear durante la
ejecución del plan de pruebas de software.
 Pruebas de integridad a los Datos y a la Base de Datos.
 Pruebas de Funcionamiento
La prueba es parte integral del ciclo de diseño y por tanto debe chequearse la
corrección del programa cuando éste se está desarrollando.
Forma gráfica de Procedimiento para las Pruebas
79
Cuando el sistema encuentra una falla, la reconoce, y la maneja de tal forma que
el procesamiento normal puede continuar, se dice que ocurre un error.
-Se tiene una excepción cuando el sistema encuentra una falla, la reconoce, pero
no la puede manejar de forma que el procesamiento normal pueda continuar.
-Existe un comportamiento erróneo cuando el sistema no detecta la falla y ésta no
causa una violación observable de sus especificaciones.
-Se tiene un fracaso cuando el sistema no detecta una falla y ésta causa una
violación de las especificaciones. Un intento de encontrar defectos ejecutando un
programa en un ambiente de prueba (simulado) se denomina verificación. Un
intento de encontrar defectos ejecutando un programa en un ambiente real se
denomina validación.
5.6. INFORMACION FUNDAMENTAL
Debido a la gran complejidad de los programas de computador, ha sido imposible

hasta el momento presentar una técnica estandarizada y razonable que permita
dar a las aplicaciones un buen nivel de corrección. Por tal razón es necesario
utilizar una técnica "negativa" de prueba, la cual no asegura que el programa sea
correcto sino
Condiciones Los procedimientos de prueba que aquí se presentan asumen ciertas

condiciones sobre los programas que van a probarse. Estas son:
a. Se asume que el programa tiene una estructura jerárquica con módulos

particionados funcionalmente y los módulos que no estén incluidos en ella deben
aparecer claramente como primitivos.
80
b. El programa debe diseñarse, implementarse y probarse en la forma
TOPDOWN. La implementación de cada módulo debe seguir las técnicas
estructuradas en el uso de estructuras de control. Los módulos no deben exceder
en longitud, una página de listado de codificación.
c. El programa debe diseñarse de tal forma que los parámetros explícitos se usen
para pasar información entre módulos donde quiera sea posible, las variables
globales sean modificadas solamente por un módulo (típicamente un primitivo) y
la estructura de los datos debe ser presentada con el mayor nivel de detalle
posible.
5.6.1. MATRIZ DE RESPONSABILIDADES
Actividad/Recurso Percy Cesar Jhonathan

Responsable de evaluar las A
condiciones de término para el
proceso de pruebas junto al Jefe de
Proyectos.
Responsable de la resolución de las A

incidencias de certificación para los
módulos de Proyectos, Revisión y
Aprobación
Evaluar las condiciones de término A

para el proceso de pruebas junto al
Arquitecto de Producto.
Testing de Solución, responsable de la A A A

generación del plan de pruebas.
A: Significa Asignado
5. CONCLUCIONES
81

Informe Final Algoritmos1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe Final Algoritmos1

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL HERMILIO

APLICACIÓN DE LA TEORIA DE GRAFOS EN EL DISEÑO DE

HASTA LOS CENTROS DE VENTAS.

ING. JIMMY GROVER FLORES VIDAL

INTEGRANTES – FASES DEL PROYECTO :

El presente trabajo presenta una aplicación de la teoría de grafos en la

Aplicación de la teoría de grafos en el diseño de rutas de transporte desde

Desarrollar un software que analice las rutas de transporte más

 Desarrollar rutas de transporte a los puntos de venta.

La aplicación de la teoría de grafos es de mucha utilidad si la empleamos

1.4. MARCO TEÓRICO

El grafo se considera como la estructura más general dentro de la

De otra manera se define a un grafo como una estructura de datos

1.4.2. ELEMENTOS DE UN GRAFO

Se presentan algunos de los conceptos básicos relacionados a la

 Grado de un vértice, el grado de un vértice v, escrito como grado

1.4.4. GRAFOS DIRIGIDOS

Los grafos dirigidos, a menudo llamados dígrafos, se caracterizan

1.4.5. GRAFOS NO DIRIGIDOS

Un grafo no dirigido tiene como principal característica que sus

 Matriz de adyacencias, consiste básicamente en un arreglo

 Lista de arcos. Se mantiene una lista de vértices (al igual que en

1.4.7. RECORRIDO DE UN GRAFO

Los grafos requieren de algoritmos especializados para buscar la

1.5.1. MICROSOFT WORD

Cuenta con un completo paquete de herramientas que permite

Entrevista a todos los usuarios propuestos y actuales para

1.5.3. RATIONAL ROSE

Rational Rose es una herramienta para “modelado visual”, que forma

Rational Rose permite completar una gran parte de las disciplinas

 Modelado del negocio

La interfaz de Rational Rose está formada por:

 Browser o navegador, permite navegar rápidamente a través de

Como todo lenguaje de programación, Java se utiliza para crear

Las aplicaciones Java se comunican con la máquina virtual Java, y

Los applets Java no son más que pequeñas aplicaciones que se

Python es un lenguaje de programación poderoso y fácil de

El intérprete de Python y la extensa biblioteca estándar están a libre

El intérprete de Python puede extenderse fácilmente con nuevas

.MISHAHUAMANGR CUADRO PICTORICO X

VILLANUEVA, Denys COLABORACION

Este documento es una Especificación de Requisitos Software (ERS) para el

El presente documento tiene como propósito plasmar de forma clara y

El documento está dirigido al cliente y al equipo de desarrollo.

Esta especificación de requisitos está dirigida al usuario del sistema, para

Nombre Calixto Tarazona, Vanesa

Nombre Campos Cabello, Katty

Nombre Leandro Bazan, Cinthya

Nombre Villadeza Romero, Karen Lucila

Categoría Ingeniero de Sistemas

Nombre Mishahuaman Grandez, Xibelli

Nombre Gonzales Retis, Franklin

Nombre Cadillo Villanueva, Denis

Nombre Granizo Villogas, Nimrod

Nombre Chagua Ramos, Omar

Nombre Flores Martinez, Joy

Nombre Acosta Jara, Diego

Nombre Naupay Picon, Percy

Nombre Diaz Sanchez, Cesar

Nombre Valdivia Escobar, Jonatan

Título del documento Referencia

Este documento consta de tres secciones. En la primera sección se realiza

Por último, la tercera sección del documento es aquella en la que se

2.2. DESCRIPCIÓN GENERAL