UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

FACULTAD DE INGENIERÍA DE MINAS, GEOLOGÍA Y CIVIL
ESCUELA DE FORMACIÓN PROFESIONAL DE INGENIERÍA DE SISTEMAS

“SISTEMA WEB PARA EL DEPARTAMENTO ACADEMICO DE OBSTETRICIA”
ASIGNATURA

: SISTEMAS DE INFORMACION II

DOCENTE

: Msc. Ing. Efraín Elías Porras Flores

INTEGRANTES

: AQUINO YUPARI, Rhoy Clinton

100%

DE LA CRUZ BAUTISTA, Ruth

100%

PRADO VASQUEZ, Luis Miguel

100%

SANCHEZ QUISPE, Zoraida Jesusa 100%
TRISTAN QUISPE, Ricardo
AYACUCHO - PERÚ

Contenido

100%

..........................1 REQUISITOS FUNCIONALES................18 1.......2 REQUISITOS NO FUNCIONALES...........4 GLOSARIO DE TERMINOS......................................3 ANALISIS DE REQUISITOS.......9 DESCRIPCION DEL PRIMER BORRADOR DE CASOS DE USO...........9 DIAGRAMA Y PAQUETES DE CASOS DE USO..................................................................3 1...............................CAPITULO I.....3 CASOS DE PRUEBA DE ACEPTACION...............6 PROTOTIPO DE INTERFAZ BASICA...........4 1.....16 1............5 1...........7 1.......7 1....................................8 LISTA DE CASOS DE USO.......................................................7 MATRIZ DE RELACION ENTRE REQUISITOS Y CASOS DE USO...............................................18 1..........................................................................................5 MODELO DE DOMINIO INICIAL...........................3 1........................................................6 1...................21 ......

. El sistema debe permitir utilizar la información de las asignaturas que se han almacenado. El sistema debe permitir ingresar la cantidad de alumnos que llevaran el curso. El sistema permitirá dos modos de acceso. Req07. Req06. El sistema debe permitir asignar docentes con respecto a cada grupo.CAPITULO I ANALISIS DE REQUISITOS 1. El sistema debe permitir guardar la información ingresada por el usuario y los cambios efectuados. 8. 3. 5. Req11. las horas de teoría. 2. REQUISITOS FUNCIONALES 1. número de grupos.1 REQUISITOS FUNCIONALES Nº Req. el número de créditos. Req04. horas totales y la escuela de formación profesional a la cual pertenece la asignatura. 10. Req01. El sistema debe permitir asignar las asignaturas de acuerdo a la serie y el semestre. uno en modo administrador. El sistema permitirá dos modos de acceso. uno en modo usuario. Req03. 9. 4. la asignatura (la sigla. El sistema debe permitir generar reportes para los docentes. Req05. 7. número de alumnos. 6. Req10. Req09. especificando 11. práctica y laboratorio). El sistema debe permitir generar la cantidad de grupo por curso de acuerdo a la cantidad de alumnos. Req08. Req02. El sistema debe permitir al usuario usar la información de los docentes que se han almacenado. El sistema debe permitir generar la cantidad de grupo por curso de acuerdo a la cantidad de alumnos.

Req17. 18. 2. El sistema debe permitir al docente generar el promedio del alumno de una determinada asignatura. Tabla 1. Req16. Req13.2 Req12. 17. Req14 El sistema debe permitir registrar la asistencia de los docentes a las sesiones de departamento. El Sistema usara el gestor de base de datos ORACLE. El sistema debe mostrar ayudas al usuario para su correcta navegabilidad.1: Requisitos Funcionales. Req19. El sistema debe permitir al docente ingresar y actualizar las notas por curso. 4. REQUISITOS NO FUNCIONALES 1. Req15.12. El sistema debe ser amigable y de fácil uso para el administrador y usuario. El sistema debe realizarse usando estándares de calidad que permita una adecuada operación y mantenimiento. El sistema web debe ser capaz de ejecutarse en cualquier sistema operativo garantizando su portabilidad. El sistema debe permitir actualizar la distribución de carga académica. El sistema debe permitir cargar el syllabus de las asignaturas y actualizarlos. El sistema debe permitir realizar un reporte de asistencia de los docentes a las sesiones de departamento. El sistema debe permitir imprimir los reportes generados. El sistema debe permitir al usuario registrar la asistencia del docente y la determinada asignatura que enseñara. REQUISITOS NO FUNCIONALES Nº Req. 14. 1. 15. 5. . 19. Req18. 3. 16. 13.

El sistema se implementara utilizando el lenguaje de programación JAVA.6. P 1 01 Comprobar que el sistema muestra todos los requisitos. 4 04 Verificar que la solicitud y los requisitos sean enviadas correctamente 5 05 Comprobar que el usuario inicie sesión 6 06 Verificar que la lista de las solicitudes se muestre en pantalla correctamente. Tabla Nº 1. 8. 1. 7. 2 02 Comprobar que los todos los requisitos necesarios para la rectificación sean adjuntados 3 03 Verificar que la solicitud sea generada correctamente con los datos llenados en la plantilla de solicitud.3 CASOS DE PRUEBA DE ACEPTACION Nº Nº C. Req. El sistema se desarrollara con la metodología ICONIX.2: Requisitos no Funcionales. 07 Verificar que se pueda abrir cada archivo de la lista de procesos nuevos con los datos correctos del solicitante. 7 8 9 CASOS DE PRUEBA DE ACEPTACIÓN 08 Verificar que la escritura pública se genere correctamente . El sistema debe ser compatible con todos los navegadores.

4 cliente GLOSARIO DE TERMINOS Requisitos Proceso de rectificación Partida de nacimiento Partida de matrimonio .con los datos correctos del usuario. 15 16 17 16 Comprobar que los reportes generados contengan datos especificados Tabla Nº 1. 10 10 Comprobar que el código de proceso asignado sea válido permita el acceso a la consulta.3: Casos de Prueba de Aceptación. 10 09 Verificar que la respuesta del usuario llegue al especificado. 13 14 14 15 Verificar que la escritura pública generada contenga los datos correctos del cliente. 1. 11 12 13 Verificar que el edicto generado contenga tenga los datos correctos del cliente. Verificar que la constancia generada posea un número de kardex único. 11 Comprobar que la validación del pago sea correcto 12 Verificar que la constancia generada tenga los datos correctos del cliente. 16 Comprobar y validar la creación de la cuenta de los usuarios 17 Verificar que los datos de la cuenta creada sean guardados correctamente.

Partida de defunción Cliente Solicitud Cuenta Consultor Especialista Tarifa Kardex Edicto Notarial Notario Usuario Constancia Partida .

1: Modelo de Dominio Inicial class Modelo de domi.5 MODELO DE DOMINIO INICIAL Figura Nº 1..1.. tiene Cuenta Usuario (from actores) Consultor Especialista (from actores) verifica evalua revisa Solicitud Notario (from actores) revisa Proceso de rectificacion Requisito elabora (from actores) elabora Edicto notarial Escritura publica rectifica envia envia consulta Partida Constancia obtiene Partida de nacimiento Partida de matrimonio Partida de defuncion Cliente (from actores) Kardex Tarifa .