HOJA DE PRÁCTICA-OXJ

Facultad De Ing. De Sistemas E Ing. Civil

Universidad Nacional De Ucayali

Ing. Mg Freddy Elar Ferrari Fernandez

Nombre 09 De 2020

Integrantes

Shesira Ushiñahua Ochavano (LIDER)

Juan Nicanor Marín Rengifo (ANALISTA)
Danny Gabryel Pastor Mantary (ARQUITECTO)
Jeferson Vásquez Merino (DESARROLLADOR)
Jhon Kevin Ordoñez Ríos (PRUEBAS)

Pucallpa -Ucayali
Contenido
METODOLOGÍA RUP Y VERSION “SOFTWARE”...............................................................3

Datos Técnicos:....................................................................................................................................4
Descripción:...........................................................................................................................................4
REQUERIMIENTOS FUNCIONALES Y NO FUNCIONES....................................................5

Requerimientos funcionales:...............................................................................................................5
Requerimientos no funcionales:......................................................................................................6
INDICAR DE CADA FASE QUE DIAGRAMA ES RELEVANTE PARA LA SOLUCIÓN

SEGÚN CORRESPONDE - JUSTIFICAR SU ELECCIÓN................................................................6

INICIO......................................................................................................................................................7
ELABORACION.........................................................................................................................................7
CONSTRUCCION.......................................................................................................................................8
ELABORAR EL DIAGRAMA DE CASOS DE USO “ESPECIFICAR EL

COMPORTAMIENTO DEL SISTEMA”...............................................................................................10

ELABORAR EL DIAGRAMA DE CLASES...........................................................................11

ELABORAR EL DIAGRAMA DE SECUENCIA....................................................................12

ELABORAR EL DIAGRAMA DE ACTIVIDAD......................................................................17

ELABORAR EL DIAGRAMA DE ESTADOS........................................................................18

ELABORAR EL MODELO DE DATOS (SHEMAS) Y PLANTEE LA SOLUCIÓN

CORRESPONDIENTE...........................................................................................................................23

DESARROLLAR EL SOFTWARE EN CONCORDANCIA AL ANÁLISIS

PREVIAMENTE PLANTEADO.............................................................................................................24

MANUAL DE USUARIO...........................................................................................................25

CONCLUCION...........................................................................................................................38
HERRAMIENTAS DE APOYO

METODOLOGIA DE RUP Y VERSION “SOFTWARE”

RUP es aplicable tanto a pequeños proyectos como el del presente trabajo, así como

para grandes proyectos de varios años de duración. Por el conocimiento que tenemos

de la metodología, ya que es la que más manejamos. Es un proceso que define de

manera ordenada las tareas, es una guía para utilizar UML. La versión del software que

utilizamos es IBM Rational Rose Enterprise Edition 7.0.0.

VERSION “SOFTWARE”

IBM Rational Rose Enterprise Edition 7.0.0

Datos Técnicos:

 Idioma: inglés 
 Licencia Incluido  
 473 MB 
 32-Bit & 64-Bit
 Windows XP/Vista/7/8/8.1/10

Descripción:

Rational Rose Enterprise es el producto más completo de la familia Rational Rose.

Todos los productos Rational Rose incluyen soporte Unified Modeling Language (UML).

Es la mejor elección para el ambiente de modelado que soporte la generación de

código a partir de modelos en Ada, ANSI C++, C++, CORBA, Java/J2EE, Visual C++ y

Visual Basic. Como todos los demás productos Rational Rose, proporciona un lenguaje

común de modelado para el equipo que facilita la creación de software de calidad más

rápidamente.
REQUERIMIENTOS FUNCIONALES Y NO FUNCIONES

Requerimientos funcionales:

 Un usuario quiere alquilar películas en la empresa OJX PERU, para eso se

solicita un software para un cajero automático.

 En caso de que el usuario no cuente con una tarjeta OJX PERU, este podrá

gestionarlo en el cajero automático de forma rápida rellenando un formulario, si

el software encuentra el mismo DNI en la base de datos se le avisara de que hay

una tarjeta a su nombre, y tendrá la opción de recuperarlo. Y se le enviara un

mensaje a su correo electrónico con el id de su tarjeta.

 Cuando el usuario ingrese su tarjeta, el software evaluara si tiene saldo o no en

su tarjeta, en caso que no tenga saldo solo tendrá la opción de RECARGAR

TARJETA (Para recargar la tarjeta el usuario marca la cantidad deseada e

introduce el dinero), en caso tenga vuelto el software calculara y entregara.

 Si el usuario tiene saldo en su tarjeta le aparecerá un menú de dos opciones

(alquilar hasta un máximo de tres películas o recargar la tarjeta).

 El usuario ALQUILARA hasta un máximo de tres películas, al escoger sus

películas el software calculara fecha limite a entregar, y el precio del alquiler. El

software preguntara si el usuario quiere confirmar el pedido mostrándole las

opciones elegidas (nombre de las películas, descripción, fecha límite de entrega,

precio por película, el importe o sanción y monto total).

 Se le imprimirá un Boucher con la siguiente información, que se le entregara al

empleado para que se disponga a hacer la entrega de los DVD.

TITUL DESCRIPCIO Fecha de Precio IMPORT IMPORT TOTA

O N devolució de E E L
n alquile X
r DAÑOS
Conjur Terror 5/11/2020 50 37.5 25(50%) 112.5
o
Titanic Drama 5/11/2020 50 37.5 25(50%) 112.5

Total 225
final

 IMPORTE (el importe actúa como garantía) se cobrara previamente un importe

que será el mismo precio que el precio de alquiler, se devolverá a la tarjeta al

momento de devolver las películas. Y cambiara el ESTADO DEL CLIENTE.

EJEMPLO:

FECHA ACTUAL: 01/11/2020

FECHA DE DEVOLUCION: 08/11/2020

FECHA QUE IMPORTE % ESTADO DE

DEVOLVIO CLIENTE
9/11/2020 S/ 0.0 0% PERFECTO
10/11/2020 (alquiler de 20% MOROSO
(Un día después) película *0.20)
11/11/2020 (alquiler de 50% MOROSO
(2 días después) película *0.50)
Pasado de 3 días (alquiler de 75% PELIGROSO
película *0.75)

 El empleado registrara el inventario de las películas que ofrece.

 TITULO DESCRIPCION CANTIDAD DISPONIBILIDAD PRECIO

TITANIC DRAMA 5 DISPONIBLE 50

CONJURO TERROR 0 AGOTADO 50

 El usuario hará DEVOLUCION de los DVD alquilados al empleado a cargo, para

asegurar la entrega en óptimas condiciones, el empleado hará el registro de

entrega de las películas utilizando sus datos de su tarjeta, el software calculara

el importe según la fecha de entrega. Y se devolverá la diferencia o en caso de

ser un importe de 100% de cobrar la garantía.

 El software debe manejar los colores de la empresa OJXPERU, adjunto la tarjeta

oficial de OJXPERU.
Requerimientos no funcionales:

 El sistema se desarrollará utilizando herramientas: como el lenguaje de

programación Java utilizando como herramienta el NetBeans 8.2, el manejador

de Base de Datos MYSQL installer-community8.0.21.0.

 Definir políticas de seguridad

 Registrar niveles de seguridad.

 El tiempo de respuesta por consulta se realice en tiempo real.

 Instalar el Sistema operativo Windows 10.

INDICAR DE CADA FASE QUE DIAGRAMA ES RELEVANTE PARA LA SOLUCIÓN
SEGÚN CORRESPONDE - JUSTIFICAR SU ELECCIÓN

Tras a ver hecho un análisis previo, se llegó, que para el desarrollo de software se

utilizara la metodología RUP, ya que provee un entorno de desarrollo flexible basado

en estándares que se adapta a las necesidades del desarrollador o de la empresa.

INICIO

Documento Visión: recoger, analizar y definir las necesidades de alto nivel y las

características del manejo de información de la empresa

Especificación de Requerimientos: Determinar las expectativas y necesidades

para satisfacer a los Interesados, todo través de un documento que sustente las

decisiones y finalmente, administrarlas a lo largo del proyecto para cumplir los

objetivos. 

Desde nuestro punto de vista creemos que ambos son importantes para el

desarrollo del proyecto pero si tenemos que elegir uno seria ESPECIFICACION

DE REQUERIMIENTOS porque constituye la base para la definición del Alcance

del proyecto y por nuestra experiencia como estudiante en cada proyecto

siempre hablamos sobre definir bien nuestros requerimientos funcionales y no

funcionales.

ELABORACION

Diagramas de caso de uso: sirven para especificar la comunicación y el

comportamiento de un sistema mediante su interacción con los usuarios y/u

otros sistemas.
Creemos que los casos de uso son importantes en nuestro proceso de análisis y

diseño porque es lo que nos permite crear la base de nuestro proyecto y hace

que nos centremos en las necesidades del usuario, qué espera éste lograr al

utilizar el sistema.

CONSTRUCCION

Documento Arquitectura que trabaja con las siguientes vistas:

VISTA LOGICA:

 Diagrama de clases

 Modelo E-R (Si el sistema así lo requiere)

VISTA DE IMPLEMENTACION:

 Diagrama de Secuencia

 Diagrama de estados

 Diagrama de Colaboración

VISTA CONCEPTUAL

 Modelo de dominio

 Vista física

 Mapa de comportamiento a nivel de hardware.

 Diseño y desarrollo de casos de uso, o flujos de casos de uso

arquitectónicos.
  Pruebas de los casos de uso desarrollados, que demuestran que la

arquitectura documentada responde adecuadamente a requerimientos

funcionales y no funcionales.

Creemos que la vista lógica es el más relevante porque nos permite plantear

el diagrama de clases y el modelo entidad relación nos ayuda a  proporciona

la base para comprender la estructura y la organización del diseño del

sistema e ilustra las realizaciones de uso clave, subsistemas, paquetes y

clases que abarcan el comportamiento significativo arquitectónicamente.

TRANSICION

 Pruebas finales de aceptación

 Puesta en producción

 Estabilización

Para nosotros las pruebas finales de aceptación es más importante por que

realizamos la verificación de la versión actual del sistema y si de pruebas encuentra

errores se hace las correcciones necesarias, generando la versión “final” del sistema.
ELABORAR EL DIAGRAMA DE CASOS DE USO “ESPECIFICAR EL
COMPORTAMIENTO DEL SISTEMA”
ELABORAR EL DIAGRAMA DE CLASES
ELABORAR EL DIAGRAMA DE SECUENCIA

D.S. ACCESO

INTERFAZ INTERFAZ DE CONTROLADOR DE ENTIDAD

PRINCIPAL ACCESO ACCESO USUARIO
: Usuario

Hacer clic en "Ingresar tarjeta"

Introducir los datos

Realizando acceso

Buscar usuario

Verificacion de usuario

Acceso al sistema

Hacer clic en "Ingresar"

D.S. REGISTRO

INTERFAZ INTERFAZ CONTROLADOR ENTIDAD ENTIDAD

PRINCIPAL REGISTRAR GENERAR REGISTRO USUARIO TARJETA

: Usuario
Seleccionar "Registrar tarj...

Carga intefaz

Ingresar datos del usu...

Hacer clic "Generar tarjeta"

Genera numero de tarjeta

Ingresar "contraseña y saldo"

Hacer clic "Registrar"

Generar registro

Registrar usuario

Registrar tarjeta
D.S RECARGAS

INTERFAZ INTERFAZ CONTROLADOR ENTIDAD

: Usuario PRINCIPAL REGISTRAR GENERAR REGISTRO RECARGAS

Seleccionar "Recargar tarjeta"

Carga interfaz

Introducir monto a recargar

Hacer clic "Recargar"

Generar registro

Registrar recarga
D.S Alquiler

INTERFAZ INTERFAZ REGISTRAR CONTROLADOR GENERAR ENTIDAD ENTIDAD

PRINCIPAL ALQUILER REGISTRAR ALQUILER PELICULAS ALQUILER
: Usuario

Seleccionar "Alquilar pelicula"

Carga interfaz

Buscar pelicula

Realizar busqueda

Buscar pelicula

Verificar pelicula

Pelicula encontrado

Buscar pelicula por genero

Busqueda realizada

Seleccionar peliculas

Hacer clic en "Agregar"

Generar registro

Registrar alquiler
D.S DEVOLUCION
 INTERFAZ INTERFAZ CONTROLADOR GENERAR ENTIDAD DEVOLVER
: Usuario PRINCIPAL DEVOLVER PELICUA DEVOLUCION PELICULA

Seleccionar "Devolver pelicula"

Carga interfaz

Generar devolucion

Registra devolucion
ELABORAR EL DIAGRAMA DE ACTIVIDAD

D.A ACCESO

Pedir usuario y
contras eña

[ no ]

¿Son los datos correctos?

[ si ]

Permitir acces o
D.A. REGISTRO (USUARIO/TARJETA)

Seleccionar
"Registrar tarjeta"

[ NO ]
Ingresa datos
del usuario

[ SI ]
Preciona en
"Generar tarjeta"
¿Campos de datos competos?

Se genera
numero tarjeta

Ingresa contraseña y
s aldo

Seleccionamos
"Registrar"

Tarjeta registrado
con exito
D.A RECARGAS

Seleccionar
"Recargar tarjeta"

[ NO ]
Ingresar monto
a recargar

[ SI ]
Preciona en
"Recargar"
¿Campos de datos com petos?

Recarga registrado
con exito
D.A ALQUILER

Selecciona
"Alquilar pelicula"

Se m uestra interfaz de
registro de alquiler

Selecciona buscar
peliculas

Busqueda de
peliculas

[ SI ]
Muestra pelicula
disponible

[ NO ]

Muestra mensaje Seleccionar

"Pelicula no disponible" pelicula

Seleccionamos Alquiler de peliculas

"Agregar" registrado con exito
D.A DEVOLUCION
ELABORAR EL DIAGRAMA DE ESTADOS

D.E ACCESO

ingresando usuario ingresado ingresando contraeña ingresado

usuario contraseña
D.E REGISTRO
D.E RECARGAS

D.E ALQUILAR
D.E D.E DEVOLUCION
ELABORAR EL DIAGRAMA DE COMPONENTES DEL SOFTWARE
ELABORAR EL DIAGRAMA DE COMPONENTES DEL SOFTWARE
 ELABORAR EL MODELO DE DATOS (SHEMAS) Y PLANTEE LA SOLUCIÓN

CORRESPONDIENTE.

PLAN DE PRUEBAS
Documento Plan de Pruebas
IDENTIFICACIÓN DEL DOCUMENTO

SISTEMA DE
Sistema de asesoramiento de rutas verdes para el MTC del Perú 2020
INFORMACIÓN
FECHA VERSIÓN RESPONSABLES DESCRIPCIÓN

18/10/2020 1.0 Jhon Kevin Ordoñez Rios

ALCANCE: Este documento de PLAN DE PRUEBAS, se convierte en una guía para

desarrollar de una forma organizada las diferentes actividades que se realizarán en el proceso

del plan de pruebas en el desarrollo del proyecto SARVMP. La metodología de pruebas y este

documento de plan de pruebas permitirán al equipo evaluar aspectos como: la funcionalidad, la

seguridad, la usabilidad, y realizar un seguimiento de las pruebas realizadas, así como el

control de los resultados.

DEFINICIONES Y SIGLAS:

El plan de prueba: describe todos los métodos que se utilizarán para verificar que el

software satisface la especificación del producto y las necesidades del cliente. Incluye los

objetivos de calidad, necesidades de recursos, asignaciones, métodos, etc.

Casos de prueba: lista los ítems específicos que serán probados y describe los pasos

detallados que serán seguidos para verificar el software.

Reporte de pruebas: describen los problemas encontrados al ejecutar los casos de

prueba.

SARVMP: Sistema de asesoramiento de rutas verdes para el MTC del Perú 2020
 PALABRA / SIGLA DEFINICIÓN
Describe todos los métodos que se utilizarán para

verificar que el software satisface la especificación del producto y

El plan de prueba: las necesidades del cliente. Incluye los objetivos de calidad,

necesidades de recursos, cronograma, asignaciones, métodos,

etc.
Lista los ítems específicos que serán probados y describe

los pasos detallados que serán seguidos para verificar el

Casos de prueba
software.

Describen los problemas encontrados al ejecutar los

Reporte de
casos de prueba.
pruebas:

Herramientas de

pruebas y Documentación de las herramientas empleadas en el

automatización proceso de pruebas.

Sistema de asesoramiento de rutas verdes para el MTC
SARVMP
del Perú 2020
 PLAN DE PRUEBAS

Tipos De Prueba:

Tipo de
PRUEBAS UNITARIAS
prueba:
Validar las piezas individuales del software como una unidad
Objetivo:
independiente.
Técnica: Caja negra
Precondicio

nes:
Criterios de
Ausencia de error
éxito:

Tipo de
PRUEBAS DE INTEGRACIÓN
prueba:
Validar la integración entre los diferentes módulos que

Objetivo: componen la solución con el fin de garantizar que su operación

integrada es correcta
Técnica: Pruebas de Integración Incremental Ascendente
Precondicio

nes:
Criterios de
Ausencia de error
éxito:

Tipo de PRUEBAS DE OPTIMIZACIÓN DE CÓDIGO

prueba:
Controlar en forma automatizada la calidad del código

Objetivo: desarrollado, en base a una serie de reglas predefinidas, de forma a

optimizar las tareas de control de calidad manual

Examinar el código del proyecto con la herramienta definida,

para cuantificar los errores debidamente tipificados.

Técnica:
El desarrollador se ocupará de examinar su código, de modo a

que se integre al proyecto, libre de errores.

Precondicio

nes:
Criterios de
Cantidad de errores minimizados, según los criterios definidos.
éxito:

Tipo de PRUEBAS DE INTEGRIDAD DE LOS DATOS Y LA BASE DE

prueba: DATOS
Verificar la base de datos y la integridad de los datos cargados

Objetivo: desde la aplicación, así como asegurar que la estructura sea la

correcta, según el modelo.

Examinar la base de datos para asegurar que los datos han

sido actualizados según lo previsto, todos los acontecimientos de la

Técnica: base de datos ocurridos correctamente, o repase los datos devueltos

para asegurarse de que los datos correctos fueron recuperados por

las razones correctas

Precondicio

nes:
Criterios de Todos los métodos y procesos de acceso de base de datos
éxito: funcionan según lo diseñado y sin ninguna corrupción de los datos.

Tipo de
PRUEBAS FUNCIONALES
prueba:
Asegurar el trabajo apropiado de los requisitos funcionales,

tomando como objetos de prueba cada uno de los casos de uso.

Objetivo:
Incluyendo la navegación, entrada de datos, edición, el borrado,

procesamiento y obtención de resultados.

Validación y ejecución de Set de Pruebas y escenarios

definidos, teniendo en cuenta flujo normal y flujos alternativos, usando

datos validos e inválidos para verificar lo siguiente:

•Los resultados esperados ocurren cuando se usan datos

Técnica:
válidos.

•Se despliegan mensajes de error cuando se usan datos

inválidos.

• Cada regla de negocio es propiamente aplicada.

Precondicio

nes:
Criterios de
Ausencia de errores
éxito:

Tipo de
PRUEBAS DE INTERFAZ DE USUARIO
prueba:
Objetivo: El objetivo de la prueba de UI es asegurarse de que la interfaz

del usuario provee al usuario el acceso y la navegación apropiados

 con las funciones del objetivo de prueba.
Precondicio

nes:
Evaluaciones iteradas que permita concluir que el sistema está
Criterios de
listo para producción como ser:
éxito:
- Ausencia de incidencias de errores por parte del usuario

Tipo de
PRUEBAS DE SEGURIDAD Y AUDITORÍA
prueba:
· Seguridad a nivel aplicación:

Verifique que un actor pueda tener acceso solamente a esas

funciones o datos para los cuales su tipo de usuario tenga permisos

Objetivo: proporcionados.

· Seguridad a nivel sistema:

Verifique que solamente permitan a esos actores el acceso al

sistema y a las aplicaciones que estén permitidos para cada rol.

· Seguridad a nivel aplicación:

- Identifique y enumere cada tipo de usuario y los permisos -

Técnica:
Crear las pruebas para cada tipo del usuario y verificar

comportamiento según los permisos definidos para ese rol

Criterios de
Comportamiento correcto acorde a roles y permisos
éxito:

Casos De Prueba:
Identificador: CP001
Probador: Jhon Kevin Ordoñez Rios
Fecha
19/10/20
Planeación:
Módulo Gestión de acceso
Funcionalid
Acceso del administrador al sistema
ad a probar:
Objetivo de Verificar que el login muestre mensajes de errores al introducir

la funcionalidad: datos erróneos o dejar las cajas de texto en blanco.

Precondicio
Los campos deben estar vacíos
nes:
Resultado El sistema mostrara un mensaje de alerta si los datos son

esperado: erróneos
Secuencia

de

pasos para

la 1) Ir a la opción INICIAR SESION

2) Introducir los datos requeridos
3) Clic en el botón INGRESAR
ejecución

de la

prueba:
Resultado
No se muestra ningún tipo de mensaje de alerta. Se genera un error.
obtenido:
Fecha ejecución: 19/10/20
Observaciones: Fallo

Identificador: CP002
Probador: Jhon Kevin Ordoñez Rios
 Fecha
19/10/20
Planeación:
Módulo Gestión de registro de rutas verdes
Funcionalid
Registrar las rutas verdes
ad a probar: Validación de campos

Objetivo de
Registro de los datos sean correctos en la base de datos
la funcionalidad:
1) Para registrar una ruta verde el administrador debe haber
Precondicio
iniciado sesión
2) Los campos del registro deben estar vacíos.
nes:

Se registran correctamente los datos de las rutas verdes en la

Resultado base de datos

esperado: El sistema mostrara un mensaje de alerta si los datos son

erróneos
Secuencia

de

pasos para 1) Hacer clic en menú despegable REGISTRAR

2) Después en la opción RUTAS VERDES
la 3) Se envía el formulario con campos vacíos o con valores
incorrectos
4) Se registra una ruta nueva
ejecución
5) Clic en AÑADIR
de la

prueba:
Se registra correctamente
Resultado
El sistema muestra el mensaje y carga nuevamente el formulario de
obtenido:
registro
Fecha ejecución: 19/10/20
Observaciones: Aprobó

Identificador: CP003
Probador: Jhon Kevin Ordoñez Rios
 Fecha
19/10/20
Planeación:
Módulo Gestión de registro de la meteorología
Funcionalid
Registrar la meteorología
ad a probar: Validación de campos

Objetivo de
Registro de los datos sean correctos en la base de datos
la funcionalidad:
1) Para registrar una meteorología el administrador debe haber
Precondicio
iniciado sesión
2) Los campos del registro deben estar vacíos.
nes:

Se registran correctamente los datos de la meteorología en la

Resultado base de datos

esperado: El sistema mostrara un mensaje de alerta si los datos son

erróneos
Secuencia

de

pasos para 1) Hacer clic en menú despegable REGISTRAR

3) Después en la opción SENAMHI
la 4) Se envía el formulario con campos vacíos o con valores
incorrectos
5) Se registra la meteorología con todos sus datos
ejecución
6) Clic en REGISTRAR CLIMA
de la

prueba:
Se registra correctamente
Resultado
El sistema muestra el mensaje y carga nuevamente el formulario de
obtenido:
registro
Fecha ejecución: 19/10/20
Observaciones: Aprobó
Identificador: CP004
Probador: Jhon Kevin Ordoñez Rios
Fecha
19/10/20
Planeación:
Módulo Gestión de registro de estación de tren
Funcionalid
Registrar las estaciones de tren
ad a probar: Validación de campos

Objetivo de
Registro de los datos sean correctos en la base de datos
la funcionalidad:
1) Para registrar una estación de tren el administrador debe haber
Precondicio
iniciado sesión
2) Los campos del registro deben estar vacíos.
nes:

Se registran correctamente los datos las estaciones en la base

Resultado de datos

esperado: El sistema mostrara un mensaje de alerta si los datos son

erróneos
Secuencia

de

1) Hacer clic en menú despegable REGISTRAR

pasos para 2) Después en la opción PERU RAIL
3) Se muestra las ciudades con todos sus datos
la 4) Hacer clic en el botón rojo de ACCION
5) Se envía el formulario con campos vacíos o con valores
incorrectos
ejecución
6) Se registra una ruta nueva
7) Clic en REGISTRAR RUTA
de la

prueba:
Se registra correctamente
Resultado
El sistema muestra el mensaje y carga nuevamente el formulario de
obtenido:
registro
Fecha ejecución: 19/10/20
Observaciones: Aprobó
Identificador: CP005
Probador: Jhon Kevin Ordoñez Rios
Fecha
19/10/20
Planeación:
Módulo Solicitud e recomendación de rutas verdes
Funcionalid
Recomendación de las rutas verdes
ad a probar: Validación de campos

Objetivo de
Que se muestren los datos esperados de la recomendación
la funcionalidad:

Precondicio Los campos del registro deben estar vacíos.

nes:

Se muestre la recomendación de rutas verdes al cliente de

Resultado acuerdo a sus preferencias

esperado: El sistema mostrara un mensaje de alerta si los datos son

erróneos
Secuencia

de

pasos para 1) Hacer clic en INICIO

2) Se envía el formulario con campos vacíos
la 3) Se selecciona una ciudad y se introduce las preferencias del
cliente
4) Se realiza la consulta
ejecución
5) Clic en BUSCAR
de la

prueba:
Se realiza correctamente la búsqueda de la recomendación
Resultado
El sistema muestra el mensaje y carga nuevamente el formulario de
obtenido:
registro
Fecha ejecución: 19/10/20
Observaciones: Aprobó
Criterios de aceptación o rechazo

Criterios de aceptación o rechazo

 No existen errores sin solucionar de Gravedad

 Todos los casos de prueba del entorno de laboratorio de prueba se han
completado satisfactoriamente.

Entregables

Entregables

 Documento de plan de pruebas

 Casos de pruebas
DESARROLLAR EL SOFTWARE EN CONCORDANCIA AL ANÁLISIS
PREVIAMENTE PLANTEADO
SOFTWARE SERA PRESENTADO EL DIA LUNES 19 DE OCTUBRE DEL 2020
 MANUAL DE USUARIO

SISTEMA DE ASESORAMIENTO

DE RUTAS VERDES PARA EL

MTC DEL PERU 2020

MANUAL DE

USUARIO

2020
 1. INTRODUCCION

El sistema desarrollado es una herramienta que permite al MTC asesorar a sus

clientes acerca de “rutas verdes” para hacer a pie a partir de sus estaciones de tren. El

objetivo de este presente manual es dar a conocer a los usuarios finales las

características y las formas de funcionamiento del software.

CONCLUCION

- Shesira Ushiñahua Ochavano (LIDER)

Durante el desarrollo del caso OXJ PERU, me di cuenta lo importante que es la
comunicación entre nosotros para el desarrollo del software pero por fuerzas mayores
no podíamos estar con los integrantes completos en una reunión. No tengo nada que
reprochar a mi grupo, porque sé que hicieron malabares con los materiales a su
alcance. Le deseo muchos éxitos a cada uno de los integrantes de mi grupo porque veo
sus cualidades.
- Juan Nicanor Marín Rengifo (ANALISTA)
Me toco husmear en otras empresas, como BLOCK BUSTER ya que es una empresa
reconocida en alquiler de películas, nuestro desarrollador tuvo algunas dificultades, pero
de tantas investigaciones se pudo hacer el software, cada uno de mis compañeros
tuvieron un cargo y cada uno de ellos estuvo trabajando con lo que le corresponden, en
mi caso me toco ser el analista y tuve que resolver el problema que nos pedía como sus
requerimientos, sus casos de uso y sus diagramas. El software está bien hecho cumple
todas sus funciones y es muy amigable, es así como pudimos terminar a tiempo el
software.
- Danny Gabryel Pastor Mantary (ARQUITECTO)
Desde mi rol como arquitecto en el desarrollo del proyecto OXJPERU, amplié mis
conocimientos y mis habilidades como investigador. Mas sin embargo no puedo negar
que hubiera cumplido mi rol como arquitecto de una forma más eficiente sino tuviéramos
problemas de conexión de internet para poder tener una mejor comunicación entre los
integrantes del grupo. Pero tenemos fe de que el proyecto saldrá bien y cumpliremos
con las expectativas.
- Jeferson Vásquez Merino (DESARROLLADOR)

Al momento de comenzar a desarrollar el software tuve que primero prepararme y

basarme en los requerimientos, converse con el analista y el arquitecto para estar en
una misma sintonía y cumplir con el pedido del cliente. Implementando un sistema de
control por software, dando la categorización de sistema de control por sus condiciones
de operación, con la flexibilidad para personalizar, propio de los sistemas de software.
El modelo considera aspectos de gestión de proyectos, análisis, diseño del software,
gestión de riesgos, control de calidad, entre otros.

- Jhon Kevin Ordoñez Ríos (PRUEBAS)

Esperamos cumplir con el proyecto a tiempo ya que las dificultades de conexión a

internet no nos dejó tener una idea planteada pero igual manejamos los recursos
escaso que teníamos e hicimos lo mejor posible, bueno durante el desarrollo de este
caso se obtuvieron resultados positivos en cuanto al cumplimiento de los
requerimientos, aunque en el transcurso del desarrollo hubo algunos errores en el
código del programa que se lograron corregir a tiempo. En general se logró cumplir con
el caso OXJ PERU.