You are on page 1of 45

Los Apartados.

Rocoto-Waze































Documento de Especificacin de Requerimientos
Y
Documento de Arquitectura del Software
Versin 2.0

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

2

Historial de Revisin











Fecha Versin Descripcin
03/06/14 1.0 Elaboracin del Documento de Especificacin
de Requisitos
03/06/14 1.0 Elaboracin de Documento de Arquitectura
del Software
12/06/14 1.0 Elaboracin del Documento de Especificacin
de Requisitos(correccin)
12/06/14 1.0 Elaboracin de Documento de Arquitectura
del Software(correccin)
17/06/14 1.0 Elaboracin de Documento de Arquitectura
del Software(correccin v2)
07/07/14 2.0 Elaboracin del Documento de Especificacin
de Requisitos
07/07/14 2.0 Elaboracin de Documento de Arquitectura
del Software
24/07/14 3.0 Elaboracin del Documento de Especificacin
de Requisitos
24/07/14 3.0 Elaboracin de Documento de Arquitectura
del Software
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

3

Tabla de Contenidos

1. Documento de Especificacin de Requisitos
1.1 Introduccin
1.2 Objetivos del proyecto
1.2.1 Objetivos generales
1.2.2 Objetivos especficos

1.3 Especificacin de requerimientos
1.3.1 Requerimientos funcionales
1.3.2 Requerimientos no funcionales
2. Documento de Arquitectura del Software
Introduccin
Propsito
Alcance
Definiciones, Acrnimos y Abreviaciones
Objetivos y Restricciones de la Arquitectura
Vista de Casos de Uso
Diagrama de Casos de Uso
Casos de uso
Vista Lgica
Vision General
Diagrama de Clases de Diseo(Modelo de Dominio)
Vista de Implementacin
Vista General
Diagrama de despliegue
Diseo de capas
Calidad

3. Integrantes del Proyecto



Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

4

1. Documento de especificacin de requerimientos

1.1. Introduccin
Con el avance de la tecnologa y las necesidades de los usuarios surge la
necesidad de generar una aplicacin web que ayude a todos los conductores a
llegar a su destino rpidamente sin tener complicaciones en la trayectoria.
1.2. Objetivos del proyecto
1.2.1. Objetivos generales
El objetivo general del proyecto es el disear, desarrollar e implementar un sitio
web, que nos ayude a encontrar la ruta ms adecuada para dirigirnos a un lugar
determinado tomando en cuenta diversos factores.
1.2.2. Objetivos especficos
Brindarles a los usuarios del sistema mediante la utilizacin de un mapa
interactivo, informacin acerca del estado de las vas como el trfico, vas cerradas
por obras de mantenimiento, incendios, etc.

Ayudar de alguna manera a que el usuario pueda llegar a su destino lo ms rpido
posible sin tener ningn inconveniente, ya que con esta aplicacin web el usuario
podr saber la mejor ruta.
1.3. Especificacin de requerimiento
1.3.1. Requerimientos funcionales
Referencia Funcin
RF-01 El sistema deber permitir a un usuario iniciar sesin usando nicamente su
cuenta de g-mail.
RF-02 Solo una vez iniciado sesin el sistema le permitir ingresar a la pgina
principal.
RF-03 La pgina principal mostrar automticamente la parte centro de Arequipa.

RF-04 En la pgina principal de la aplicacin el usuario podr escoger su posicin-
origen con la ayuda de un marcador al igual que su ruta-destino o de lo
contrario tambin podr hacerlo escogiendo su posicin en el mapa.

RF-05 En la pgina se deber mostrar disponibilidad de cambio de su ruta
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

5

generando nuevos marcadores para su posicin-origen y la ruta de destino
tambin podr hacerlo directamente en el mapa.

RF-06 La pgina principal deber mostrar la mejor ruta y 2 rutas opcionales desde el
punto de inicio hasta la ruta-destino indicado por el usuario y una gua de
instrucciones de como dirigirse a la ruta.

RF-07 Mientras el usuario se dirige a la ruta especificada, el sistema deber permitir
al usuario seleccionar los tipos de incidentes definidos y si desea podr
realizar un comentario con un lmite de palabras.

RF-08 El usuario podr seleccionar los tipos de incidentes solo en las avenidas.
RF-09 Cada usuario que recorre la misma ruta que otro anteriormente podr realizar
cambios al estado del incidente y si desea podr realizar un comentario con
un lmite de palabras.
RF-10 En la pgina el usuario podr ver todos los comentarios hechos por los
usuarios que han recorrido la misma ruta anteriormente.

RF-11 El sistema debe permitir ingresar los siguientes tipos de incidentes:
accidentes, semforo daado, congestin vehicular, marchas y vas
clausuradas.
RF-12 Asociado al tipo de incidente deber ir ligado el respectivo icono
representativo, el cual se mostrara en el mapa de acuerdo a la zona indicada
por el usuario.

RF-13 Al momento que el usuario cambia el estado del incidente el icono
representativo se tendr que eliminar automticamente.
RF-14 Pasado cierto tiempo los incidentes reportados se tendrn que eliminar
automticamente esto se realizara en caso de que un usuario no haya
cambiado el estado del incidente anteriormente. Los tiempos establecidos
son: accidentes, 5 horas, semforo daado, 12 horas, congestin vehicular,
5 horas, marchas, 8 horas, y vas clausuradas, 24 horas.
RF-15 Segn el nmero de reportes que se registren de un mismo incidente en una
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

6

misma direccin, el color de la zona afectada del incidente deber cambiar
as: de uno a dos incidentes reportados su color deber ser amarillo, de tres
a cuatro naranja y ms de cinco su color ser rojo.


1.3.2 Requisitos No Funcionales
Referencia Funcin
RNF-01 El Sistema deber visualizarse y funcionar correctamente en un solo
navegador (Google Chrome).
RNF-02 El sistema no debe tener tardar ms de 10 segundos en buscar la ruta hacia
el destino al cual se quiere ir.
RNF-03 El Sistema al momento de ubicar al usuario, no debe tener un margen de
error en localizacin por ms de los 10 m.
RNF-04 La pgina debe estar disponible las 24 horas del da, los 7 das de la
semana.


2 Documento de la Arquitectura del Software

2.1 Introduccin
2.1.1 Propsito
El propsito del presente documento tiene como finalidad presentar una
visin inicial para los distintos aspectos que conforman la arquitectura de la
aplicacin web Rocoto-Waze. De esta manera, se busca capturar y asentar
las bases de la arquitectura del software, con el fin de facilitar las actividades
de anlisis y toma de decisiones que sern tomadas en el desarrollo de la
aplicacin.
2.1.2 Alcance
El alcance de este documento es presentar la base de la arquitectura
del sistema para la implementacin de la aplicacin.
2.1.3 Definiciones, Siglas, y Abreviaciones
A continuacin presentamos las abreviaturas y definiciones de los trminos
de mayor importancia que se encuentran en el documento.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

7

SOFTWARE: conjunto de programas, instrucciones y reglas informticas que
permiten ejecutar distintas tareas en una computadora. Se considera que el
software es el equipamiento lgico e intangible de una computadora.
SISTEMA: conjunto de entidades caracterizadas por ciertos atributos, que
tienen relaciones entre s y estn localizadas en un cierto ambiente, de
acuerdo con un cierto objetivo.
INTERNET: Infraestructura de redes a escala mundial que se conecta a la vez
a todo tipo de computadores. Desarrollado originariamente para los militares
de Estados Unidos, despus se utiliz para el gobierno, la investigacin
acadmica y comercial y para comunicaciones.
VISTAS: es una representacin de un rea de inters o perspectiva del
sistema en alto nivel.
STAKEHOLDER: Individuo, equipo u organizacin con intereses relativos al
sistema.
MVC: Modelo Vista Controlador. Estilo de arquitectura de software,
frecuentemente visto en aplicaciones Web, que divide los procesos en tres
capas.



2.2 Objetivos y restricciones de la arquitectura

El software a desarrollar tiene los siguientes objetivos:
Rendimiento: El desempeo de la aplicacin debe ser muy eficiente de tal
manera el usuario inmediato y todos los dems observen lo ms rpidamente
posible los cambios realizados en un momento determinado.
Expansibilidad: Mantendr la expansibilidad necesaria para facilitar ese
proceso de desarrollar versiones posteriores.
Usabilidad: El diseo debe ser orientado por y para la comodidad del usuario,
de manera que la interfaz sea intuitiva y fcil de manejar, al mismo tiempo que
se fomente altamente la interaccin entre ambos.
Reutilizacin: Puede transferirse de un sistema a otro.

2.3 Vista de Casos de Uso
2.3.1 Diagramas de Casos de Uso

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

8


2.4 Casos de uso
Cdigo UC-01
Nombre Iniciar Sesin
Actores Usuario
Descripcin En esta parte del sistema el usuario acceder al sitio a travs
de su cuenta g-mail.
Flujo Principal Actor Sistema
Iniciar sesin Se mostrar un mensaje en
la cual se le pide una
autorizacin para acceder su
cuenta de g-mail

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

9

Flujo Alternativo En caso que el usuario quiera usar otra cuenta.
Actor Sistema
Iniciar Sesin El sistema le da la facilidad de poder
cambiar a otra cuenta.

Pos condicin El usuario podr visualizar la pgina principal.
Referencia RF-01,RF-02,RF-03

Cdigo UC-02
Nombre Elegir posicin-origen
Actores Usuario Registrado
Descripcin En este parte el usuario podr elegir su
posicin-origen con la ayuda de un
marcador o escogiendo su posicin en el
mapa.
Flujo Principal Actor Sistema
Elegir la posicin-
origen
Se mostrara un
marcador el cual
simboliza su
posicin-origen o de
lo contrario tambin
se puede hacerlo
directamente en el
mapa.

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

10

Flujo Alternativo En caso que no muestre el
marcador.
Actor Sistema
Elegir la
posicin-
origen
El sistema
tiene la
posibilidad de
reiniciar
nuevamente
la pgina
principal.

Pos condicin El usuario podr ver el marcador que
simboliza su posicin-origen.
Referencia RF-04


Cdigo UC-03
Nombre Elegir una ruta-destino
Actores Usuario Registrado
Descripcin En este parte el usuario podr elegir la
ruta-destino con la ayuda de un marcador
o de lo contrario tambin se puede hacerlo
directamente en el mapa.
Flujo Principal Actor Sistema
Elegir una ruta-
destino
Se mostrar las
mejores rutas, para
que el usuario
llegue sin retrasos
a su destino.

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

11

Flujo Alternativo En caso que no muestre
ninguna ruta.
Actor Sistema
Elegir una
ruta-destino
El sistema
tiene la
posibilidad de
reiniciar
nuevamente
la pgina
principal.

Pos condicin El usuario podr ver las mejores rutas para
llegar a su destino.
Referencia RF-04-RF-05,RF-06

Cdigo UC-04
Nombre Modificar destino
Actores Usuario Registrado
Descripcin En este parte el usuario podr cambiar su
destino generando nuevos marcadores,
eligiendo as su nueva posicin-origen y
ruta-destino.
Flujo Principal Actor Sistema
Nueva ruta Se mostrar la
mejor ruta, para
que el usuario
llegue sin retrasos
a su nuevo destino.

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

12

Flujo Alternativo En caso que no muestre
ninguna ruta.
Actor Sistema
Cambiar la
ruta-destino
El sistema
tiene la
posibilidad de
reiniciar
nuevamente
la pgina
principal.

Pos condicin El usuario podr ver las mejores rutas para
llegar a su nuevo destino.
Referencia RF-05, RF-06



Cdigo UC-05
Nombre Seleccionar incidentes
Actores Usuario Registrado
Descripcin En esta parte el usuario despus de haber
elegido la ruta que desee, podr
seleccionar algn incidente predefinido
mientras se dirige por la ruta, tambin
podr realizar algn comentario o poner
una foto de lugar.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

13

Flujo Principal Actor Sistema
Seleccionar
incidentes
El sistema mostrara
una interfaz
mediante la cual el
usuario podr
escoger el tipo de
incidente
predefinido que ha
observado mientras
pasaba por la ruta.
Los tipos de
incidentes son:
semforo daado,
congestin
vehicular, marchas
y vas clausuradas.
Adems tambin
podr realizar un
comentario o
colocar una foto del
lugar(opcional)

Flujo Alternativo En caso de tener problemas
con la interfaz
Actor Sistema
Seleccionar
incidentes
En caso que
existan
muchas
equivocaciones
al realizar este
procedimiento
el sistema
mostrara
advertencias
sobre dicho
problema.

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

14

Pos condicin En el mapa se mostrar un icono
representativo del incidente seleccionado.
Referencia RF-07,RF-08,RF-11,RF-12

Cdigo UC-06
Nombre Cambiar estado de incidentes
Actores Usuario Registrado
Descripcin En esta parte el usuario despus de haber
elegido la ruta que desee, podr cambiar
el estado de un incidente mientras se
dirige por la ruta, tambin podr realizar
algn comentario o poner una foto de
lugar.
Flujo Principal Actor Sistema
Cambiar estado
de incidentes
El sistema mostrara
una interfaz
mediante la cual el
usuario podr
cambiar el estado
del incidente
mientras se dirige
por la ruta.
Adems tambin
podr realizar un
comentario o
colocar una foto del
lugar(opcional)

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

15

Flujo Alternativo En caso de tener problemas
con la interfaz
Actor Sistema
Cambiar
estado de
incidentes
En caso que
existan
muchas
equivocaciones
al realizar este
procedimiento
el sistema
mostrara
advertencias
sobre dicho
problema.

Pos condicin En el mapa ya no aparecer un icono
representativo del incidente.
Referencia RF-9,RF-11,RF-13


2.5 Vista Lgica
2.5.1 Visin general
2.5.1.1 Diagrama de Clases de Diseo (Modelo de Dominio)
A continuacin se propone un Modelo Conceptual (diagrama de Modelo
de Dominio) para demostrar cuales son los conceptos ms relevantes y
sus asociaciones para la aplicacin web.





Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

16












Diagrama de Modelo del Dominio

2.6 Vista de Implementacin
2.6.1 Vista General
El Sistema SCTT se desarrollar bajo el patrn conocido como MVC, el cual
dividir nuestro software en tres capas principales. Con el uso de dicho
patrn se contar con un mejor entendimiento del sistema y facilitar las
labores de desarrollo y mantenimiento de la aplicacin.
El Modelo (tambin conocida como la capa de datos) es la capa en donde
reside la informacin que maneja el sistema. Estar conformado por un
gestor de bases de datos (en nuestro caso,) para realizar el almacenamiento
de datos. Esta capa deber responder a las peticiones de informacin de
estado de parte de la capa de Vista y a las instrucciones de modificacin de
estado, provenientes de la capa de Controlador.
La Vista (tambin conocida como la capa de aplicacin) es la capa que se
encarga de presentar la interfaz con el usuario. Contiene todo el cdigo para
generar la interfaz con el usuario, en lenguaje (HTML), y se encarga tanto de
mostrar la informacin del sistema como capturar los datos ingresados por
los usuarios. Esta es la nica capa que el usuario final llega a ver del sistema.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

17

El Controlador (tambin conocida como la capa lgica) es la capa que se
encarga de interactuar entre la capa de Vista y la capa de Modelo. Esta capa
recibe peticiones del usuario a travs de la capa de Vista y las transmite a la
capa de Modelo. Luego, recibe los datos generados por la capa Modelo y se
los hace llegar a la capa de Vista para que puedan ser mostradas la usuario.
Este ciclo se repite tantas veces como el usuario genere peticiones (o
acciones) en el sistema. Por ltimo, esta capa es de suma importancia puesto
que contiene toda la lgica del negocio y es quien se encarga de procesar los
datos de entrada ingresados por los usuarios.
Las categoras existentes son las tres definidas en el modelo MVC (modelo,
vista y controlador) ms una cuarta denominada infraestructura. Esta cuarta
categora es provista por el entorno App Engine e implementa los servicios de
base que permitan desarrollar una aplicacin dentro de la arquitectura.
Algunos de los servicios dentro de la categora son:
Persistencia de entidades.
Acceso a archivos del sistema operativo.
Motor de plantillas para representacin de pgina web dinmicas.
Autenticacin de usuarios


Diagrama de Componentes del patrn MVC




Controlador
Vista Modelo
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

18

Aplicacin del Usuario
<<process>>
navegador web(google crhome)
App Engine
<<server>>
Google Maps
obtencin de rutas
Vista
Aplicacin web(JAVA)
Cloud Storage
capa de datos(no SQL)
Internet
Aplicaciones
procesamiento de posiciones
procesamiento de alertas
procesamiento de mensajes

2.6.2 Diagrama de despliegue

2.6.3 Diagrama de actividades

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

19


2.6.4 Diseo de Capas
Capa de Aplicacin Interna
En la siguiente figura podemos observar la distribucin de los
paquetes en cada una de las capas del sistema.
a) Capa Interfaz de Usuario
Esta capa contiene el paquete Interfaz de Usuario, el cual almacena
todas las clases con las cuales el usuario puede interactuar como lo
son las ventanas.
b) Capa Lgica del Negocio
Esta capa contiene los paquetes de Servicios de Negocio y
Entidades de Negocio. Contiene la lgica para el manejo de las
operaciones del negocio.
c) Capa Persistencia
Esta capa contiene el paquete de Objetos de Acceso de Datos, que
brinda una interfaz transparente para la interaccin con el
Framework (Google App Engine) el cual enviar al Driver el conjunto
de sentencias para interactuar con la Base de Datos.

2.7 Calidad

A continuacin se detallan los siguientes objetivos, relacionados a la calidad, que
se persiguen con el desarrollo de este software:
Operabilidad:
Las necesidades a largo plazo de los administradores del sistema son
apoyadas confiablemente, ya que es fcil de instalar y la actualizacin no
genera perdida de datos.
Capacidad de Mantenimiento:
El sistema est diseado de la manera ms comprensible, de manera que al
desarrollar una nueva versin o mejora del sistema el mismo facilita la
incorporacin en el diseo.

Usabilidad:
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

20

El sistema genera una interaccin muy sencilla entre el usuario y el, debido a
lo familiar y comprensible que ha sido diseado, siendo visibles para el usuario
las herramientas que requiere para cumplir sus tareas en dicho sistema.
3 Integrantes del Proyecto
Nombres
Flor Fernndez Zamora
Sal Gutirrez
Vidal Soncco Merma
Nicols Gutirrez Castilla
Orlando Prez Paredes
Jos Torres Lima
Alexis Mamani Vilca














Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

21






HISTORIAL DE CAMBIOS
FECHA VERSIN DESCRIPCIN RESPONSABLE
30-06-14 1.0 Plantilla de
pruebas v1
-
24-07-14 2.0 Plantilla de
pruebas v2

















Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

22







Tabla 1: Historial de cambios
TABLA DE CONTENIDO
HISTORIAL DE CAMBIOS ............................................................................... 21
TABLA DE CONTENIDO.................................................................................. 22
NDICE DE TABLAS ........................................................................................ 23
1 INTRODUCCIN ............................................................................................ 24
1.1. Objetivos ............................................................................................ 24
1.2. Estrategia de Pruebas ...................................................................... 24
1.3. Alcance .............................................................................................. 25
1.4. Referencias ........................................................................................ 26
1.5. Definiciones, abreviaciones y acrnimos ....................................... 27
2 ARTEFACTOS DE PRUEBA ......................................................................... 28
2.1 Mdulos del Programa ..................................................................... 28
2.2 Procedimientos de Usuario ................................................................... 29
3 CARACTERISTICAS A SER PROBADAS .................................................... 30
4 CARACTERSTICAS QUE NO SERAN PROBADAS.................................... 31
5 APROXIMACION ........................................................................................... 32
5.1 Pruebas Unitarias .............................................................................. 32
5.2 Pruebas de Frontera ......................................................................... 32
5.3 Pruebas de Integracin .................................................................... 33
5.4 Pruebas de Sistema .......................................................................... 34
6 PROCESO DE PRUEBAS ............................................................................. 35
7 ANEXO ........................................................................................................... 22
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

23

7.1 Anexo 1: Reportes de Pruebas ........................................................ 22

NDICE DE TABLAS
TABLA 1: HISTORIAL DE CAMBIOS .............................................................................. 22
TABLA 2: DEFINICIONES, ACRNIMOS Y ABREVIACIONES .............................................. 27
TABLA 3: MDULOS A PROBAR EN EL SISTEMA ............................................................ 29
TABLA 4. CARACTERSTICAS A SER PROBADAS ........................................................... 30
TABLA 5. CARACTERSTICAS QUE NO SERN PROBADAS. ............................................. 31
TABLA 6. PRUEBAS UNITARIAS. ................................................................................. 32
TABLA 7. PRUEBAS DE FRONTERA ............................................................................. 32
TABLA 8. ENTREGABLE DE LA PRUEBA. ...................................................................... 33
TABLA 9. PRUEBA DE INTEGRACIN. .......................................................................... 33
TABLA 10. RESULTADOS PRUEBA INTEGRACIN ......................................................... 34
TABLA 11. PRUEBAS DE SISTEMA .............................................................................. 34
TABLA 12. RESULTADOS PRUEBAS DE SISTEMA. ........................................................ 34
TABLA 13: CASO DE PRUEBA 1 .................................. ERROR! BOOKMARK NOT DEFINED.
TABLA 14: CASO DE PRUEBA 2................................................................................. 18
TABLA 15: CASO DE PRUEBA 3................................................................................. 19
TABLA 16: CASO DE PRUEBA 4................................................................................. 19
TABLA 17: CASO DE PRUEBA 5.................................. ERROR! BOOKMARK NOT DEFINED.
TABLA 18: CASO DE PRUEBA 6.................................. ERROR! BOOKMARK NOT DEFINED.
TABLA 19: CASO DE PRUEBA 7.................................. ERROR! BOOKMARK NOT DEFINED.
TABLA 20: CASO DE PRUEBA 8.................................. ERROR! BOOKMARK NOT DEFINED.
TABLA 21: CASO DE PRUEBA 9 .................................. ERROR! BOOKMARK NOT DEFINED.
TABLA 22: CASO DE PRUEBA 10................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 23: CASO DE PRUEBA 11................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 24: CASO DE PRUEBA 12................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 25: CASO DE PRUEBA 13................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 26: CASO DE PRUEBA 14................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 27: CASO DE PRUEBA 15................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 28: CASO DE PRUEBA 16................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 29: CASO DE PRUEBA 17................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 30: CASO DE PRUEBA 18................................ ERROR! BOOKMARK NOT DEFINED.
TABLA 31: CASO DE PRUEBA 19................................ ERROR! BOOKMARK NOT DEFINED.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

24

1 INTRODUCCIN
1.1. Objetivos
EL plan de pruebas de Software se elabora con el fin de especificar qu elementos
o componentes se van a probar para que el grupo de trabajo pueda realizar el
proceso de Validacin y Verificacin de los requerimientos funcionales y no
funcionales de la herramienta Rocoto-Waze. Adems, a travs del plan de
pruebas se puede continuar con la trazabilidad de los requerimientos, con lo cual
el grupo de trabajo, identifica el porcentaje de avance que se ha logrado hasta
cierto momento.
Al desarrollar el plan de pruebas, se puede obtener informacin sobre los errores,
defectos o fallas que tiene el prototipo, as se realizan las correcciones
pertinentes, segn el caso. El plan de pruebas se aplica sobre el cdigo fuente de
la herramienta web, los resultados de las pruebas son registrados en un formato
que se encuentra en el Anexo 1: Reportes de Pruebas. Las pruebas a implementar
son bsicas, esto incluye las pruebas unitarias y de integracin que son vitales
para la validacin del proyecto.
1.2. Estrategia de Pruebas
A travs de los diferentes documentos que se han realizado, se pretende retomar
informacin directamente relacionada con las pruebas. Adems le permite al
responsable de las pruebas saber exactamente los criterios que se deben tener en
cuenta para probar cada elemento del sistema. A continuacin se explica
brevemente el aporte de cada documento con respecto al plan de pruebas.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

25


Ilustracin 1: Estrategia del plan de pruebas
Con esta estrategia se asegura llevar el seguimiento de la trazabilidad que se ha
manejado desde la especificacin de requerimientos, adems de mantener la
consistencia entre la aplicacin y su respectiva documentacin.
1.3. Alcance
Teniendo en cuenta los documentos hechos anteriormente, el grupo de trabajo
pretende realizar las pruebas, de manera incremental, por mdulo. Para una mejor
comprensin, ver la Ilustracin 2: Alcance del plan de pruebas, la cual muestra el
alcance y el orden en que se realizaran.
Priorizacin: se escogen los requerimientos de mayor priorizacin
para poder aplicar las pruebas correspondientes. Ver documento
de Requerimientos seccin 1.3
especificacin de requerimientos.
Documento de Especificacin
de Requerimientos
Diagrama de Componentes: La separacin del sistema por
componentes permite la clasificacin de las pruebas segn la
funcionalidad del mdulo. Ver documento de Arquitectura seccin
2.3 VISTA DE CASOS DE USO y seccin 2.6 VISTA DE
IMPLEMENTACION.
Vista Fsica: Prueba de los componentes de Hardware que tiene la
aplicacin, seccin 2.3 VISTA DE IMPLEMENTACIN.
Documento de Diseo
Arquietectnico
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

26


Ilustracin 2: Alcance del plan de pruebas
Las pruebas unitarias se realizaran inmediatamente despus de haber
implementado la aplicacin, esto quiere decir, que el orden corresponde al descrito
en la prioridad de requerimientos construidos desde el documento de
Requerimientos seccin 1.3 ESPECIFICACIN DE REQUERIMIENTOS.
1.4. Referencias
[1]. IEEE Computer Society, IEEE Standard For Software Test Documentation,
Disponible en: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=573169.
[2]. Sommerville I, INGENIERA DE SOFTWARE. Novena Edicin. Naucalpan
de Jurez. Mxico: Pearson Educacin; 2011.








Pruebas
unitarias
Pruebas de
Integracion
Pruebas de
Sistema
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

27

1.5. Definiciones, abreviaciones y acrnimos
CONCEPTO DESCRIPCIN

AS Arquitectura de Software
ANS Asignacin Numrica Simple (Mtodo de Priorizacin)
IS Ingeniera de Software
STP Software Tester Plan
DAO Data Access Object
Tabla 2: Definiciones, acrnimos y abreviaciones
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

28

2 ARTEFACTOS DE PRUEBA
2.1 Mdulos del Programa
En esta seccin se muestran los mdulos que se pretenden probar, adems de las
especificaciones de las pruebas a realizar en cada uno. Cabe notar, que cada
mdulo representa un componente del sistema. Los tems a manejar en la tabla
son los siguientes:

Ilustracin 3: Mdulos del programa
Modulo Pruebas Descripcin
GUI



Facilidad de uso La facilidad de uso consiste en que
siempre tengan el conocimiento sobre
qu pueden o qu deberan hacer los
usuarios en cada momento y cmo
hacerlo.
Look & feel Look & feel es la apariencia que se
proporciona al usuario
Lgica de
Negocio
Funcionalidad El sistema debe poder realizar todo los
requerimientos establecidos con el
usuario, este mdulo ser guiado por
los diferentes tipos de requerimientos
que se han manejado durante el
proyecto
DAO Persistencia El sistema debe ser capaz de guardar
Mdulo
Es un conjunto de
elementos, el
cual tienen en
comn la
finalidad.
Pruebas
Tipo de pruebas
que sern
utilizadas dentro
del componente.
Descripcion
Breve explicacin
sobre la prueba a
realizar.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

29

datos para ser usados en otra consulta,
adems de tener acceso a ellos sin
tener ningn problema de consistencia e
integridad.
NO funcionales No funcionales El sistema debe cumplir con los
requerimientos no funcionales que se
han especificado en el documento de
Requerimientos teniendo en cuenta el
diseo.
Tabla 3: Mdulos a probar en el sistema
2.2 Procedimientos de Usuario
Para utilizar la herramienta de manera adecuada se necesitan guas o manuales
que sean claros, correctos, completos y coherentes, para que el usuario pueda
manejar la herramienta de forma correcta y pueda comprender los conceptos tras
la funcionalidad. A continuacin se muestran los diferentes atributos de calidad de
estos procedimientos:
Clara: Las instrucciones proporcionadas en el documento, deben ser lo
suficientemente explicitas para que el usuario pueda desenvolverse dentro
del entorno de la herramienta.
Correcta: No existen errores semnticos, sintcticos, ortogrficos ni de
enlace dentro de la documentacin proporcionada al usuario.
Completa: La informacin debe estar completa, desde la parte tcnica
hasta la parte funcional.
Coherente: No existen ambigedades, ni incongruencias dentro del
documento que puedan confundir al usuario.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

30

3 CARACTERISTICAS A SER PROBADAS
En esta seccin se encuentran las caractersticas de la herramienta a ser
probadas con un caso de estudio especfico.
Caracterstica Descripcin Mdulo
Requerimientos
Funcionales
Se debe tener en cuenta
el criterio de aceptacin y
dependencias, para
realizar pruebas en los
mdulos. Adems se
debe utilizar el
documento de casos de
uso para tener claro los
casos de xito y fallo, y si
la herramienta cumple
con ellos.
Los mdulos donde se
puede probar esta
caracterstica son:
Lgica de Negocio
DAO
Requerimientos No
Funcionales
Se debe tener en cuenta
el criterio de aceptacin y
lo que exige el
requerimiento para su
cumplimiento,
especificado en el
documento de
Rerquerimientos.
El mdulo donde se
puede probar esta
caracterstica es:
No funcionales
Tabla 4. Caractersticas a ser Probadas


Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

31

4 CARACTERSTICAS QUE NO SERAN PROBADAS
En esta seccin se encuentran las caractersticas de la herramienta a no ser
probadas con un caso de estudio especfico.

Caracterstica Descripcin Mdulo
Procedimientos
de Usuario
No sern probados, debido a que
no se cuenta con el tiempo
suficiente para probar los
diferentes criterios, relacionados
con los procedimientos, ya que se
necesitan usuarios con
conocimiento en las reas de
Ingeniera de software y que
conozca el proceso que se aplica
en la asignatura.
Procedimientos de
Usuario
GUI Debido a que el tiempo es
insuficiente, y no est dentro del
alcance del proyecto, las pruebas
de ste mdulo no se realizaran.
El mdulo donde se
puede probar esta
caracterstica son:
GUI
Tabla 5. Caractersticas que no sern probadas.

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

32

5 APROXIMACION
En esta seccin se exponen los tipos de pruebas a utilizar para la herramienta
Rocoto-Waze, cada una de ellas presenta un formato, el cual se va registrar los
resultados.
5.1 Pruebas Unitarias
Pruebas por cada unidad, en este caso una unidad es equivalente a un
requerimiento. El requerimiento es aprobado y aprobado si este cumple con lo que
est escrito en la especificacin de requerimientos.
NOMBRE Pruebas Unitarias
ACTIVIDADES Anlisis de requerimientos del sistema
TIEMPO
ESTIMADO
10-20 minutos por unidad
MTODOS O
HERRAMIENTAS
Eclipse Google Chrome
ENTREGABLES Lista de chequeo sobre el cumplimiento del requerimiento,
realiza lo que el requerimiento describe?
Tabla 6. Pruebas Unitarias.
5.2 Pruebas de Frontera
Pruebas frontera, son las que toman en cuenta valores lmite, para verificar el
comportamiento de la herramienta en esos casos.
NOMBRE Pruebas de Frontera
ACTIVIDADES Se realizaran las distintas pruebas con los valores lmites y
mnimos que debe recibir el programa.
TIEMPO
ESTIMADO
15 minutos por prueba
MTODOS O
HERRAMIENTAS
Eclipse Google Chrome
Tabla 7. Pruebas de Frontera


Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

33


En cuanto a los entregables de esta prueba se llenara la siguiente tabla:


Nombre Identificador T01
Valor
mximo
Valor
mnimo

Resultado esperado
Resultados obtenidos
Estado Funciona: No funciona:
Comentarios
Tabla 8. Entregable de la prueba.
5.3 Pruebas de Integracin
Las pruebas de integracin, como su nombre lo indica, son pruebas hechas a un
conjunto de requerimientos, en este caso se distribuyen en los tipos de
requerimientos que se definieron en el documento de Requerimientos.
NOMBRE Pruebas de Integracin IDENTIFICADOR IT01
ACTIVIDADES Validacin de requerimientos

TIEMPO
ESTIMADO
15 minutos por pruebas
MTODOS O
HERRAMIENTAS
Eclipse Google Chrome
ENTREGABLES Informe generado en donde se indica si se tiene un correcto
funcionamiento o no.
Tabla 9. Prueba de Integracin.
ID GRUPO DE
REQUERIMIENTOS
RESULTADOS DE LA
PRUEBA
Grupo de requerimientos
que estn relacionados
dentro del grafo de
Resultado de la prueba.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

34

dependencias
Tabla 10. Resultados Prueba Integracin
5.4 Pruebas de Sistema
Las pruebas de sistema son pruebas realizadas a la herramienta como un
conjunto, que casos de uso cumple a cabalidad, con rutas de xito y fallo, que han
sido definidas en el documento de Casos de Uso.
NOMBRE Pruebas sistemas
ACTIVIDADES Se realizaran pruebas funcionales y No funcionales
TIEMPO
ESTIMADO
15 minutos por prueba
MTODOS O
HERRAMIENTAS
Eclipse Google Chrome
ENTREGABLES Informe generado por el responsable de esta prueba el cual
informara si se tiene un correcto funcionamiento o no.
Tabla 11. Pruebas de Sistema


ID CASO DE USO RESULTADOS DE LA
PRUEBA
Grupo de requerimientos
que estn relacionados
dentro del grafo de
dependencias
Resultado de la prueba.
Tabla 12. Resultados Pruebas de Sistema.


Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

35

6 PROCESO DE PRUEBAS
En esta seccin se presentan los casos de pruebas generales para usarlos con la
herramienta Rocoto-Waze. Cada cuadro est asociado a un caso de Uso, desde
ah se desglosa en los diferentes mdulos involucrados para el funcionamiento y
se evala el resultado obtenido. En las siguientes tablas, se muestran los casos de
pruebas a realizar:
Nombre Iniciar
Sesin
Identificador T-01
Valor mximo 50 Valor mnimo
Resultado esperado Usuario acceda exitosamente a la aplicacin con una cuenta de g-
mail.
Resultados obtenidos El usuario puede iniciar sesin con normalidad
Estado
Funciona x
No funciona
Comentarios Solo es vlido para cuentas con g-mail

Nombre Elegir
posicin-
origen
Identificador T-02
Valor mximo Valor mnimo
Resultado esperado Marcador ubicado en su posicin-origen escogido por el usuario.
Resultados obtenidos Comportamiento esperado, un marcador se posiciona en la
posicin-origen dada.
Estado Funciona X No funciona
Comentarios



Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

36

Nombre Elegir una
ruta-
destino
Identificador T-03
Valor mximo Valor mnimo
Resultado esperado Marcador ubicado en su ruta-destino escogido por el usuario y
mostrar la mejor ruta.
Resultados obtenidos Comportamiento esperado, un indicador se posiciona en la ruta-
destino dada. Colorea una ruta desde la posicin-origen hasta la
ruta-destino junto con 2 adicionales, mas no muestra la mejor
ruta.
Estado Funciona No funciona X
Comentarios Falta implementacin


Nombre MODIFICAR
DESTINO
Identificador T-04
Valor mximo Valor mnimo
Resultado esperado Mostrar la mejor ruta a partir de la posicin-origen y ruta-destino
segn como hayan sido modificados.
Resultados obtenidos La posicin-origen cambia junto con la ruta-destino, mas no
muestra la mejor ruta.
Estado Funciona No funciona X
Comentarios Falta implementacin

Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

37

7 ANEXO
7.1 Anexo 1: Reportes de Pruebas
VER DOCUMENTO DE EXCEL Reporte de Pruebas.xlsx



















Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

38


NDICE GENERAL

PANORAMA GENERAL
VISIN GENERAL
A. Instalacin de la plataforma y de Google App Engine
B. Antes de comenzar
C. Importando el Proyecto a la Plataforma Eclipse
D. Cargar el proyecto a Google App Engine




















Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

39




PANORAMA GENERAL

La aplicacin Rocoto Waze, permite encontrar la mejor ruta hacia un destino evitando el
trfico y los incidentes indeseables, ya que en l se pueden tomar un rol ms activo compartiendo
reportes viales ayudando a dar aviso a otros usuarios sobre lo que viene, as como actualizar los
avisos como sea posible.
Por consiguiente, el usuario obtendr informacin valiosa para la bsqueda de rutas y poder
controlar el trfico para llegar hacia el destino deseado.
Entre las bondades que ofrece Rocoto Waze, se pueden citar las siguientes:
Es amigable y de fcil manejo, ya que queda a conveniencia del usuario utilizar el Mouse
o el Teclado.
Facilita la gestin de manejo y control de rutas, a travs de los procesos del App Engine
de Google Maps.
Contiene una barra de men similar a otras aplicaciones web, lo que permite que el
usuario se habite ms rpido al Sistema.













Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

40






VISIN GENERAL

A. Instalacin de la plataforma y de Google App Engine

En esta parte se describirn los primeros pasos que seguimos para desarrollar nuestra aplicacin y
as en cierta forma dejar documentado el proceso y los puntos claves a tener en cuenta en esta
aproximacin con este ambiente de desarrollo y publicacin de aplicaciones web.
1. El IDE de Eclipse est disponible en varios paquetes. El paquete "Eclipse IDE para Java EE
Desarrolladores" incluye todos los componentes que se necesitan para el desarrollo de
aplicaciones web.


2. Adems del complemento de Google para Eclipse, se recomienda los plugins Eclipse Web
Tools Platform (WTP) para el desarrollo web. Entre otras cosas, la DAP ofrece modos de
edicin para archivos JSP y HTML.
http://eclipse.org/webtools/
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

41


3. Para utilizar el plugin debe estar ejecutando la versin de Java 7
(https://www.java.com/en/download/) y una versin reciente de Eclipse . Puede instalar el
plugin de Google para Eclipse mediante la funcin de actualizacin de software de Eclipse.
Asegrese de utilizar el plugin correspondiente a su versin de Eclipse.
Versin de Eclipse Instrucciones de instalacin Enlace directo al Plugin
Eclipse 4.3 (Kepler) Plugin para Eclipse 4.3 (Kepler) http://dl.google.com/eclipse/plugin/4.3
Eclipse 3.8/4.2 (Juno) Plugin para Eclipse 3.8/4.2 (Juno) https://dl.google.com/eclipse/plugin/4.2

B. Antes de comenzar

1. Usted necesita una cuenta de Google con el fin de crear un proyecto en la consola de las API
de Google. Usted tambin puede querer una cuenta de Google distinta para propsitos de
prueba.


2. Para utilizar la API de Google Maps Engine, debes tener una cuenta de Google Maps Engine
activo. Si usted no tiene uno ya, por favor pngase en contacto con ventas o registrarse para
obtener una cuenta gratuita.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

42



3. Antes de enviar solicitudes a la API de Google Maps Engine, usted necesita decirle a Google
acerca de su cliente y activar el acceso a la API. Esto se hace mediante el uso de la consola de
las API de Google para crear un proyecto. Para crear un proyecto:
3.1. Vaya a la consola de las API. Si an no est registrado, introduzca sus datos de cuenta
Google.
3.2. Si ves un prominente botn Crear Proyecto, haga clic en l para crear un nuevo proyecto.
Si en lugar de ese botn vez la consola de las API, entonces usted ya tiene un proyecto.
Usted puede utilizar el proyecto desplegable situado cerca de la parte superior izquierda
de la ventana para seleccionar o crear un proyecto diferente.


4. Para activar la API de Google Maps Engine:
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

43

4.1. Haga clic en Servicios.
4.2. Desplcese hacia abajo a la entrada API de Google Maps Engine y haga clic en el
interruptor en On para activar el API.

5. Cada solicitud a la API de Google Maps Engine debe contener una clave de parmetro, cuyo
valor es la clave de API de consola para su proyecto. Si su solicitud no pasa un token de
autorizacin, entonces una clave es necesaria. Para obtener su clave de API:
5.1. Vaya a la Consola de las API. Si an no est registrado, introduzca sus datos de cuenta
Google.
5.2. Seleccione su proyecto desde el men desplegable debajo del logo de la API de Google.
5.3. Haga clic en Acceso a la API.
5.4. Su clave aparece en la seccin Acceso a la API Simple. Si no aparece ninguna clave, haga
clic en Crear nueva clave.

C. Importando el Proyecto a la Plataforma Eclipse

1. Copiar la carpeta del Proyecto en su WorkSpace de Eclipse.
2. Haz click sobre la pestaa de File, en la parte superior del entorno de desarrollo Eclipse.
3. Seleccionar la opcin de import.
4. Dar click en General --> Existing proyects into workspace.
5. Se mostrar la ventana Import Proyects, seguido del cuadro Select root directory, dar click en
el botn browse.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

44



6. Seleccionar el espacio de trabajo (workspace) en donde se encuentra el proyecto a importar.
7. Una vez seleccionado el proyecto, se mostrar la ruta especfica donde se encuentra el
proyecto.
8. Haz click en finalizar para que se muestre el proyecto importado.


D. Cargar el proyecto a Google App Engine

Dfasf
1. Antes de cargar su aplicacin por primera vez, debe registrar un ID de aplicacin con App
Engine utilizando la consola de administracin. Registre un ID de aplicacin, a continuacin,
edite el archivo appengine-web.xml y cambie el elemento <application>... </ application> que
contenga el nuevo ID.
2. Haga clic en el botn de Google en la barra de herramientas de Eclipse, y seleccione
"Deploy to App Engine." Eclipse puede solicitarle su nombre de usuario cuenta de
administrador (su direccin de correo electrnico) y contrasea. Introduzca su informacin de
cuenta y haga clic en el botn Deploy para completar la carga.
Nombre Rocoto-Waze
Versin: 3.0
Documento de especificacin de requerimientos y Arquitectura del
Software
Fecha: 24/07/14

45



3. Pruebe la aplicacin en App Engine visitando su URL:
http://your_app_id.appspot.com/guestbook