Informe Final de la Primera Práctica Pre Profesional I

UNIVERSIDAD NACIONAL DE UCAYALI
FACULTAD DE INGENIERIA DE SISTEMASY DE INGENIERIA CIVIL
ESCUELA PROFESIONAL DE INGENIERIA DE SISTEMAS
INFORME FINAL DE LA I PRACTICA PRE PROFESIONAL
“SISTEMA DE INFORMACIÓN PARA LA GESTION ACADEMICA DE LA
ESCUELA DE POSTGRADO EN LA OFICINA DE COORDINACION Y
SERVICIOS ACADEMICOS DE LA UNIVERSIDAD NACIONAL DE UCAYALI”
Alumno : Marlon David Terán Maca.
Asesor : Ing.Luis Alberto Rivera Echegaray
Pucallpa - Perú
2013

2
Revisado por:
________________________________________
Ing. Luis Alberto Rivera Echegaray.
Asesor de Práctica Pre-Profesional I

3
CONTENIDO
1. INTRODUCCION........................................................................................................................... 8
2. MEMORIA DESCRIPTIVA DE LA INSTITUCION............................................................................ 10
2.1. Ubicación Geográfica ........................................................................................10
2.2. Memoria Descriptiva..........................................................................................10
2.3. Estructura Orgánica...........................................................................................11
2.4. Misión................................................................................................................12
2.5. Visión.................................................................................................................12
2.6. Manual de Organizaciones y funciones .............................................................13
2.6.1. Oficina General de Coordinación y Servicios Académicos – OGCySA...................... 13
3. OBJETIVOS DE LA PRÁCTICA...................................................................................................... 18
3.1. Objetivo General................................................................................................18
3.2. Objetivos Específicos ........................................................................................18
4. DESCRIPCION DEL DESARROLLO DEL TEMA, MATERIA DE LA PRÁCTICA................................ 19
4.1. CAPÍTULO 1: Generalidades.............................................................................19
4.1.1. Definición del Problema........................................................................................... 19
4.1.2. Marco Conceptual.................................................................................................... 21
4.1.2.1. Sistema de Información..................................................................................... 21
4.1.2.2. Asp.Net.............................................................................................................. 21
4.1.2.3. Proceso.............................................................................................................. 21
4.1.2.4. Tecnología ......................................................................................................... 22
4.1.2.5. UML ................................................................................................................... 22
4.1.3. Planificación del Proyecto ........................................................................................ 22
4.1.4. Plan de Respuesta ante Riesgos del Proyecto.......................................................... 26
4.2. CAPITULO 2: Análisis .......................................................................................27
4.2.1. Definición de la Metodología de Solución ............................................................... 27
4.2.2. Fase de Iniciación ..................................................................................................... 28
4.2.3. Fase de Elaboración.................................................................................................. 28
4.2.4. Catálogo de Requerimientos.................................................................................... 29
4.2.4.1. Requerimientos................................................................................................. 31
4.2.4.2. Consideraciones sobre el sistema ..................................................................... 47

4
4.2.5. Análisis de la Solución .............................................................................................. 48
4.2.5.1. Identificación de las Necesidades del Usuario.................................................. 49
4.2.5.2. Viabilidad Técnica y Económica ........................................................................ 51
4.2.5.3. Análisis Costo – Beneficio.................................................................................. 53
4.2.5.4. Asignación de Funciones a Hardware y Software ............................................. 54
4.2.5.5. Definición del Sistema....................................................................................... 56
4.3. CAPITULO 3: Diseño.........................................................................................57
4.3.1. Arquitectura de la Solución...................................................................................... 57
4.3.1.1. Representación de la arquitectura.................................................................... 58
4.3.1.2. Diseño de la arquitectura de la solución........................................................... 59
4.3.1.3. Vista Lógica........................................................................................................ 64
4.3.1.4. Vista de despliegue ........................................................................................... 65
4.3.1.5. Diagrama de Clases de Diseño ......................................................................... 66
4.3.1.6. Diagrama de Base de Datos............................................................................... 67
5. ANALISIS CRÍTICO Y APORTE A LA EMPRESA............................................................................. 68
5.1. Análisis Crítico...................................................................................................68
5.2. Aporte Técnico ..................................................................................................68
6. CONCLUSIONES ......................................................................................................................... 69
7. RECOMENDACIONES................................................................................................................. 70
8. BIBLIOGRAFIA............................................................................................................................ 71
9. ANEXOS ..................................................................................................................................... 72

5
Figuras
Figura: Organigrama Estructural de la Universidad Nacional de Ucayali.......................................... 11
Figura: Organigrama Oficina General de Coordinación y Servicios Académicos .............................. 12
Figura: Estructura de Descomposición del Trabajo de la Practica I ................................................. 24
Figura: Diagrama de Casos de Uso de Negocio................................................................................. 50
Figura: Diagrama de Paquetes .......................................................................................................... 57
Figura: Diagrama de componentes de la arquitectura ..................................................................... 61
Figura: Vista lógica del sistema ......................................................................................................... 65
Figura. Diagrama de despliegue........................................................................................................ 66
Figura: Diagrama de Paquetes2 ....................................................................................................... 82
Figura: Diagrama de Casos de Usos del Paquete de Mantenimientos ............................................. 83
Figura: Diagrama de Casos de Usos del Paquete de Plan de Estudios............................................. 84
Figura: Diagrama de Casos de Usos del Paquete Carga Académica ................................................. 85
Figura: Diagrama de Casos de Usos del Paquete de Apertura Académica ...................................... 85
Figura: Diagrama de Casos de Usos del paquete de Proceso de Matricula...................................... 87
Figura: Diagrama de Casos de Usos del Paquete de Proceso de Notas............................................ 89
Figura: Diagrama de Casos de Usos del Paquete Gestionar Cierre Periodo Académico y Reportes 91
Figura: Diagrama de Secuencia Registrar Modalidad ..................................................................... 145
Figura: Diagrama de Secuencia Registrar Mención ........................................................................ 146
Figura: Diagrama de Secuencia Registrar Alumno.......................................................................... 147
Figura: Diagrama de secuencia Generar Avance Curricular............................................................ 148
Figura: Diagrama de secuencia Generar Ficha de Matricula .......................................................... 149
Figura: Diagrama de secuencia Reinscripción de Cursos ................................................................ 150
Figura: Diagrama de secuencia Retiro Parcial................................................................................. 151
Figura: Diagrama de secuencia Generar Actas Notas ..................................................................... 152
Figura: Diagrama de secuencia Registrar Notas Actas.................................................................... 153
Figura: Diagrama de Secuencia Cierre Horario Académico ............................................................ 154
Figura: Diagrama de Secuencia Cierre de Matricula....................................................................... 155
Figura: Diagrama de Secuencia Cierre de Registro de Notas.......................................................... 156
Figura: Diagrama de Secuencia Actualizar Avance Curricular......................................................... 157

6
Figura: Diagrama de secuencia Imprimir Avance Curricular Masivo .............................................. 158
Figura: Diagrama de Secuencia Imprimir Record Académico Masivo ............................................ 159
Figura: Diagrama de Secuencia Realizar Matricula......................................................................... 160
Figura: Diagrama de Clases ............................................................................................................. 161
Figura: Modelo Físico Base de Datos Parte 1.................................................................................. 162
Figura: Modelo Físico Base de Datos Tablas Históricas.................................................................. 164
Figura: Base de datos “SistPostGradoInt”...................................................................................... 164
Figura: Base de datos 26 primeras tablas ...................................................................................... 164
Figura: Base de datos 8 tablas restantes........................................................................................ 164
Figura: Stored Procedures.............................................................................................................. 165
Figura: Scalar -Values Functions...................................................................................................... 166

7
Tablas
1. Tabla: Digrama de gantt............................................................................................................ 25
2. Tabla: Patrón de codificación de requerimientos..................................................................... 29
3. Tabla: Requerimientos de diseño vs. Solución arquitectónica ................................................. 62
4. Tabla: Lista de Riesgos............................................................................................................... 76

8
1. INTRODUCCION
Este proyecto de Primera Práctica Pre profesional tiene por finalidad
presentar el análisis y diseño de una solución informática dirigida a la
problemática presente en el proceso de matrícula, que se da en la escuela
de Postgrado de la Universidad Nacional de Ucayali. Dicha solución
posibilitará la administración de información vinculada a los alumnos, que
se encuentran matriculados al menos en alguna mención dictada por parte
de la escuela de Postgrado que facilitara el llenado de las notas y dar el
seguimiento académico a los alumnos pertenecientes en alguna mención.
A Corto plazo el objetivo esperado con este proyecto es implementarlo,
para después proponer a la oficina de Coordinación y Servicios
Académicos, un adecuado sistema de información que facilite e integre sus
procesos con unaherramienta apta para gestionar el registro de notas y el
proceso de matrícula de los alumnos.
En el segundo capítulo se describe de forma general los aspectos de la
institución donde se realiza la práctica Pre Profesional.
En el tercer capítulo se detalla los objetivos de la práctica, tanto objetivos
generales como objetivos específicos.
En el cuarto capítulo es la descripción del desarrollo del tema, aquí
haremos el uso de la metodología seleccionada y empezar con el ciclo de
vida del desarrollo del software.

9
El Quinto capítulo trata del análisis crítico y aporte a la empresa, ahí se
detallara las cosas que se pueden mejorar y de cómo se encontró
anteriormente la oficina de Coordinación y Servicios Académicos.

10
2. MEMORIA DESCRIPTIVA DE LA INSTITUCION
2.1. Ubicación Geográfica
Carretera Federico Basadre Km 6.200 al margen Derecho desde Lima –
Pucallpa.
Pertenece al:
Distrito de Manantay
Región de Ucayali.
Ciudad de Pucallpa.
2.2. Memoria Descriptiva
La Oficina General de Coordinación y Servicios Académicoses un órgano
de apoyo de la Universidad Nacional de Ucayali y tiene como objetivo
mantener el Archivo y Registro Central de la parte académica, así como de
apoyar a las Facultades.
Es un Órgano de apoyo que forma parte de La Universidad Nacional de
Ucayali, que fue creada mediante Decreto Ley N° 22804, del 18 de
diciembre de 1979;con el nombre de Universidad Nacional de Pucallpa
durante el gobierno militar del general Francisco Morales Bermúdez Cerruti,
atendiendo a la sentida necesidad y aspiración de los pobladores de la
región Ucayali de contar con una institución que apoye el desarrollo
socioeconómico, cultural y humanístico de esta región como resultado de

11
las gestas heroicas del Pueblo Ucayalino expresados en las épicas
jornadas denominadas ―Los Grandes Pucallpazos‖ de 1978 y 1979.
Por Ley N° 23261 del 16 de julio de 1981, el gobierno democrático del Arq.
Fernando Belaúnde Terry ratificó la creación de la Universidad Nacional de
Pucallpa.
2.3. Estructura Orgánica
Figura: Organigrama Estructural de la Universidad Nacional de Ucayali

12
Figura: Organigrama Oficina General de Coordinación y Servicios
Académicos
2.4. Misión
La Oficina general de coordinación y servicios Académicos de la UNU, tiene
como misión captar, procesar, actualizar y sistematizar toda la información
académica de las Facultades y de los Programas Académicos
(Capacitación y Perfeccionamiento Magisterial, Maestría, Doctorado,
Actualización y Titulación Profesional), a partir de una mejora continua.
2.5. Visión
La Oficina general de coordinación y servicios Académicos de la UNU, tiene
como visión el reconocimiento por parte de la comunidad estudiantil,
mantener la fluidez y la conformidad documentaria que se requiera.
OFICINA GENERAL DE
COORDINACION Y SERVICIOS
ACADEMICOS
OFICINA EJECUTIVA DE
REGISTRO CENTRAL
BIBLIOTECA
CENTRAL

13
2.6. Manual de Organizaciones y funciones
El Reglamento de Organización y Funciones de la Universidad Nacional de
Ucayali es un documento Técnico Normativo que contiene disposiciones
Técnico- Administrativas que completan, regulan y fija la estructura orgánica
de la entidad, con sujeción a su naturaleza, fines, y funciones establecidas
en su ley de creación No 22804, la ley Universitaria No 23733, el Estatuto
de la Universidad Nacional de Ucayali Reformado mediante Resolución N°
009 – 2006—AU-R-UNU, modificado según Resolución No 009-2007-AU-R-
UNU, 004-2008-AU-R-UNU, y ampliado según Resoluciones No 009-2008-
AU-R-UNU y demás normas complementarias que precisan las funciones,
atribuciones y relaciones de las unidades orgánicas consignadas en las
mencionadas normas y disposiciones. Además, esta estructura será
perfeccionada en la medida que la Universidad Nacional de Ucayali se
modernice acorde con los cambios del entorno y las exigencias de la región.
Se debe dar énfasis a aquellas que hagan versátil el trabajo y una mayor
precisión desde el punto de vista técnico, especialmente el informático.
2.6.1. Oficina General de Coordinación y Servicios Académicos – OGCySA
Artículo 88°.Son funciones de la Oficina General de Coordinación y
Servicios Académico:
a. Procesar la información del rendimiento académico de los estudiantes de
la UNU, manteniendo los registros de matrícula y actas de calificaciones.
b. Expedir documentos oficiales de carácter académico.

14
c. Preservar el archivo y registro académico mediante copias en discos
magnéticos y guardarlos en instituciones de seguridad
d. Mantener actualizada la información académica en la página Web de la
UNU.
e. Brindar información actualizada para elaborar estados de cuenta de los
estudiantes.
f. Brindar servicio Bibliotecario, de información y documentación.
g. Coordinar las actividades académicas que realizan los centros de
formación profesional con que cuenta la UNU.
h. Centralizar la información relacionada al aspecto académico
i. Formular, diseñar y uniformizar las especies valoradas (Certificados,
Constancias etc.) que expide la institución como parte del servicio
educativo.
j. Establecer un sistema de información de apoyo académico a las
diferentes facultades.
k. Establecer sistemas y procedimientos a fin de mantener actualizado el
registro de matrícula, registro y archivo del historial académico de los
alumnos y facultades de la Universidad Nacional de Ucayali.
l. Prestar apoyo a las facultades en materia de impresiones, elaboración de
documentos auxiliares para el servicio académico.

15
m. Procesar y expedir constancias de naturaleza académica, de
documentos que se encuentran en su custodia.
Artículo 89°.La Oficina General de Coordinación y Servicios Académicos
para el mejor cumplimiento de sus funciones cuenta con las siguientes
dependencias:
- Oficina Ejecutiva de Registro Central
- Oficina Ejecutiva de Biblioteca Central y Publicaciones.
Artículo 90°.La Oficina Ejecutiva de Registro Central es la Oficina
encargada de centralizar el registro de toda la información Académica de
los estudiantes, coordinar la formulación de procedimientos de carácter
administrativo para el mejor cumplimiento del servicio educativo que brinda
la institución, informa el cumplimiento de las metas educativas en cuanto a
formación profesional de las diferentes carreras que brinda la UNU, apoya
en el proceso de ingreso de estudiantes a la UNU.
Artículo 91°.Son funciones de la Oficina Ejecutiva de Registro Central:
a. Apoyar la formulación y elaboración de Reglamentos Académicos en
coordinación con las facultades.
b. Formular los procedimientos de carácter administrativo en apoyo del
servicio educativo.

16
c. Formular, diseñar y uniformizar en coordinación con las facultades los
formularios de carácter académico (Registros Auxiliares, Acta de Notas,
Registro de Asistencia Docente y Avance Temático, etc.)
d. Informar sobre el cumplimiento de las políticas, el logro de los objetivos y
metas educativas en la institución.
e. Formular, diseñar y uniformizar los formatos de especies valoradas
(Certificados, Constancias) que expide la Institución como parte del servicio
educativo.
f. Coordinar la aplicación de normas y procedimientos académicos comunes
para todas las facultades.
g. Apoyar a la Comisión de Admisión en los procesos para el ingreso de
estudiantes a la UNU en las diferentes formas y modalidades.
h. Mantener actualizado y velar por la seguridad de todos los registros
documentales, y magnéticos referidos a la información académica de los
alumnos de la UNU, así como asegurar la actualización y operatividad el
software y hardware utilizados en la oficina para los registros académicos.
i. Proponer normas y manuales técnicos que orienten y rijan el proceso de
matrícula.
j. Formular y proponer criterios técnicos, formas de evaluación, tipos de
exámenes para el proceso de evaluación de los alumnos de la universidad.

17
j. Realizar investigaciones que permitan establecer nuevas técnicas de
admisión acordes con el adelanto científico y tecnológico.
k. Coordinar con el Centro Pre – Universitario de la UNU aspectos
relacionados a los criterios de selección, evaluación de vacantes y
estudiantes del Centro Pre Universitario.
Artículo 92°.La Oficina Ejecutiva de Registro Central depende de la Oficina
General de Coordinación y Servicios Académicos, está a cargo de un
profesional de carrera, no docente.
Artículo 93°.La Oficina Ejecutiva de Biblioteca Central y Publicaciones es el
órgano de apoyo encargado de conservar el patrimonio bibliográfico
asignado a la UNU, para lo cual administra las publicaciones científicas,
técnicas, literarias y otras, ejecuta las acciones y procedimientos de
catalogación, restauración y reprografía conducentes a la prestación de
servicios en condiciones óptimas y oportunas, depende de Oficina General
de Coordinación Servicios Académicos, está a cargo de un servidor de
carrera no docente.

18
3. OBJETIVOS DE LA PRÁCTICA
3.1. Objetivo General
Análisis y diseño de un Sistema de Información orientado a la gestión
académica de la escuela de Postgrado en la Oficina General de
Coordinación y Servicios Académicos de la Universidad Nacional de
Ucayali.
3.2. Objetivos Específicos
-Identificar los procesos que se presentan en la gestión académica de la
escuela de Postgrado en la Oficina General de Coordinación y Servicios
Académicos de la Universidad Nacional de Ucayali.
-Conocer lo efectivo que es la tecnología .NET en los procesos que se
presentan en la gestión académica de la escuela de Postgrado en la Oficina
General de Coordinación y Servicios Académicos de la Universidad
Nacional de Ucayali.
-Aplicar Prácticas del desarrollo Ágil y UML para elaborar el análisis y
diseño del Sistema de Información para la gestión académica de la escuela
de Postgrado en la oficina general de Coordinación y Servicios Académicos
de la Universidad Nacional de Ucayali.

19
4. DESCRIPCION DEL DESARROLLO DEL TEMA, MATERIA DE LA
PRÁCTICA
4.1. CAPÍTULO 1: Generalidades
En este capítulo se presentan el contexto y marco conceptual de la
problemática. Asimismo se presentan la planificación de tareas y
actividades a ser realizadas.
4.1.1. Definición del Problema
Con la aparición de nuevas y mejores herramientas en tecnologías de
información orientadas a la automatización de los procesos y el
cumplimiento de los objetivos en las organizaciones, actualmente éstas se
consideran en todo ámbito un factor de cambio determinante para el
mejoramiento y desarrollo de las actividades de toda organización o
Empresa.
Teniendo estos antecedentes y que en la actualidad, la oficina general de
coordinación y servicios académicos cuya misión es captar, procesar,
actualizar y sistematizar toda la información académica de las Facultades y
escuela de Postgrado,se encuentra un problema muy grave y fundamental
para el seguimiento académico de los alumnos pertenecientes a la escuela
de postgrado, este problema es la de no contar con un sistema que
contemple los registros de notas enviados desde la escuela de postgrado
de la Universidad Nacional de Ucayali.

20
La oficina de coordinación y servicios académicos no cuenta con un
sistema de información que agilice el proceso de registro de notas.
Convocando a practicantes de la escuela de ingeniería de sistemas para
poder resolver este problema.
Los registros de notas de los alumnos llegan en formatos de Excel a la
oficina general de coordinación y servicios académicos, cuyos registros son
revisados para su posterior aprobación y por ultimo archivándolo en
Expedientes, corriendo el riesgo de poder ser deteriorados por las
condiciones climatológicas y otros riegos.
En cada fólder se ubican los expedientes del estudiante según la
modalidad, mención y el periodo de ingreso.
Observando toda esta problemática, además de conocer que la escuela de
postgrado es una entidad reciente en la Universidad Nacional de Ucayali y
que no cuenta con un sistema de información que facilite los procesos de la
gestión académica. Se propuso a la oficina general de coordinación y
servicios académicos el análisis y diseño de un sistema de información.
Por tanto, en este proyecto de la primera práctica pre profesional se
propone el análisis y diseño de un sistema de información orientado a la
gestión académica de la escuela de Postgrado en la oficina de coordinación
y servicios académicos en la Universidad Nacional de Ucayali.

21
4.1.2. Marco Conceptual
En esta sección se amplía el marco teórico base para el desarrollo y
comprensión de la temática de este proyecto como primera practica pre
profesional de la carrera.
4.1.2.1. Sistema de Información
Señala que Un sistema de información como todo sistema, es el
conjunto de partes interrelacionadas, hardware, software y de
Recurso Humano (humanware). Un sistema de información típico
emplea una computadora que usa dispositivos programables para
capturar, almacenar y procesar datos. La computadora personal o
PC, junto con la persona que lo maneja y los periféricos que los
envuelven, resultan de por sí un ejemplo de un sistema de
información (Gámez Martín & Puerta Callejón , 1998).
4.1.2.2. Asp.Net
Es el nombre con que se conoce la parte de la plataforma.NET que
permite el desarrollo y ejecución de aplicaciones web como servicios
web. (Fernando Berzal, 2003)
4.1.2.3. Proceso
Señala que Un proceso se define como un conjunto de tareas,
actividades o acciones interrelacionadas entre sí que, a partir de una
o varias entradas de información, materiales o de salidas de otros

22
procesos, dan lugar a una o varias salidas también de materiales
(productos) o información con un valor añadido (Blazquez, 2000).
4.1.2.4. Tecnología
Señala que la Tecnología se define como el conjunto de
conocimientos y técnicas que, aplicados de forma lógica y ordenada,
permiten al ser humano modificar su entorno material o virtual para
satisfacer sus necesidades, esto es, un proceso combinado de
pensamiento y acción con la finalidad de crear soluciones útiles
(Ordoñez, 2001).
4.1.2.5. UML
Es un modelo para la construcción de software orientado a objetos
que ha sido propuesto como estándar de ISO por OMG (Falgueras,
2003).
4.1.3. Planificación del Proyecto
Se presentan a continuación los siguientes diagramas con la planificación
delproyecto para los próximos meses:
- Diagrama EDT.
- Diagrama de Gantt.

23
Como fecha de entrega del análisis y diseño del sistema de información
junto con el documento del Informe final de la Primera Práctica Pre
Profesional con anexos actualizados, está pactada para el mes de mayo del
año 2013. La prolongación del tiempo de entrega del proyecto obedece a
razones de índole laboral y académica.

24
Figura: Estructura de Descomposición del Trabajo de la Practica I
Sistema de Infomación para la gestion académica de la escuela de Postgrado en la Oficina
General de Coordinaicon y Servicios Académicos de la Universidad Nacional de Ucayali
Incepción
levantamiento de
información
identificación de caso
de usos
Elaboración
identificación de
clases y entidades
identificación de
entidades realcionales
identificación de clases de
diseño
definición de estandáres
identificación de casos de
prueba
Construción
Iteración I
version I. del sistema
implementación y prueba
del Módulo
Mantenedores
ejecución de pruebas
integrales
diagrama de secuencias
Iteración II
vesion II. del sistema
implementación y
pruebas del modulo
Gestión de plan de
estudios
ejecucion de pruebas
integrales
diagrama de secuncias
Iteración III
versión III del sistema
implementación y
pruebas del modulo
Carga Académica
ejecución de pruebas
integrales
entrega version III
Iteración IV
Versión IV del
sistema
Implementación y
pruebas del
módulo Apertura
Académica
- Entrega versión IV
Ejecución de pruebas
integrales
Iteración V
Versión V del sistema
Implementación y
pruebas del módulo
Proceso de Matricula
diagrama de secuencias -
Entrega versión V
integrales
Iteración VI
Versión VI del
sistema
Implementación y
pruebas del módulo
Proceso de notas
diagrama de secuencia -
entrega version VI
integrales
Iteración VII
Versión final del
sistema
Implementación y
pruebas de Reportes y
cierre del Periodo
Académico
Digrama de secuencia
- ENtrega Version VII
integrales

25
1. Tabla: Digrama de gantt
Sistema de Información para la gestión académica de la escuela de Postgrado en la Oficina General
de Coordinación y Servicios Académicos de la Universidad Nacional de Ucayali
días De hasta
Gestión de
proyecto
Planificación 20 días 05/01/13 25/01/13
Plan de proyecto días
Documento work brakdown structure WBS días
Diagrama de Gantt días
Control de Riesgos días
Documentación de Gestión de Riegos días
Incepción 40 días 26/01/13 07/03/13
Levantamiento de Información días
Catálogo de Requerimientos días
Identificación de casos de Uso días
Especificación de requisitos de software días
Elaboración 60 días 08/03/13 07/05/13
Identificación de clases y entidades días
Documentación de análisis del sistema días
Identificación/ selección de
arquitectura
días
Documento de arquitectura del sistema días
Identificación de clases de diseño días
Documento del diseño del sistema días
Identificación de entidades
relacionales
días
Documento de diseño de base de datos días
Definición de estándares días
Documento de estándares de programación días
Identificación de casos de prueba días

26
4.1.4. Plan de Respuesta ante Riesgos del Proyecto
Se presentará a continuación una selección de medidas comprendidas en el
Anexo A: Plan de gestión de riesgos. Estas acciones están orientadas a
velar por una correcta dirección del proyecto respecto al manejo y control
de riesgos para minimizar o atenuar los efectos negativos al proyecto en
caso se presenten.
En la etapa de Planificación se invertirá el tiempo razonable en capturar y
formalizar correctamente los requerimientos del producto y contrastando las
soluciones con opinión de expertos y profesionales quienes conjuntamente
con los usuarios finales avalen el proceso automatizado. Bajo este juicio de
expertos los requerimientos no presentarán mayores variantes durante el
proceso.
Consolidada esta etapa es importante especificar las actividades y tareas a
efectuar en el proyecto asegurando la adjudicación de tiempos razonables
en función a la naturaleza del riesgo, junto con las acciones a seguir.

27
4.2. CAPITULO 2: Análisis
El desarrollo del capítulo abarca la presentación de conceptos vinculados a
la metodología de desarrollo de software aplicada junto con los
requerimientos y restricciones identificados del producto. Continuando con
el acápite de análisis de la solución se presentan las evaluaciones de
viabilidad técnica y económica, la asignación de funciones a los elementos
del producto y la definición del sistema.
4.2.1. Definición de la Metodología de Solución
La metodología de desarrollo seleccionada para el presente proyecto es
Agile Unified Process por las razones expuestas a continuación:
El enfoque AUP ofrece un amplio marco de buenas prácticas en la fase de
análisis, diseño y construcción de software en búsqueda de la optimización
promoviendo medidas como la ejecución de pruebas en paralelo con la
programación así como el manejo de unidades de prueba. Del mismo modo
por sus principios derivados de RUP, se constituye como una de las
metodologías más aplicadas para el análisis, implementación y
documentación de sistemas orientados a objetos.
AUP cuenta con actividades de carácter iterativo e incremental y tomando
en cuenta las propuestas del paradigma XP (como el tratamiento de
solicitudes de cambios del producto en paralelo con la codificación)
favorecen al logro de un producto software en menor tiempo y bajo una
comunicación horizontal en el tratamiento de cambios (el equipo de

28
desarrolladores reunido directamente con el cliente para conocer sus
necesidades) en lugar de una comunicación vertical (la solicitud de cambio
transmitida a través de una serie de revisiones, usuarios y analistas).
Como RUP prioriza a un grado mayor la documentación se opta por un
paradigma de trabajo con entregables esenciales y específicos para el
entendimiento de la solución final.
4.2.2. Fase de Iniciación
El objetivo en esta fase es asimilar los requerimientos esperados de la
solución y plasmarlos en la definición y especificación de los casos de uso.
Asimismo, como apoyo a los procesos de gestión, se presenta la
programación definitiva de las actividades y tareas conforme a la
planificación del proyecto (diagrama de Gantt y WBS) junto con la relación
de riesgos identificados. Los documentos como el catálogo de
requerimientos, las especificaciones de requisitos de software, el
cronograma del proyecto, el plan de proyecto y enunciado de alcance se
encuentran en observación durante esta fase.
4.2.3. Fase de Elaboración
En esta fase el objetivo es construir y probar la arquitectura descrita en el
documento de arquitectura del sistema.
Entre los entregables requeridos durante esta fase conviene citar el
documento de análisis (junto con el diagrama de clases de análisis) y el

29
documento de diseño (acompañado del diagrama de clases de diseño).
Otras actividades involucradas en esta fase son:
4.2.4. Catálogo de Requerimientos
Los requerimientos funcionales y no funcionales fueron recopilados durante
las entrevistas con especialistas y personal de coordinación académica.
2. Tabla: Patrón de codificación de requerimientos
Patrón de codificación de requerimientos
Patrón Codificación:
Módulo
Valor asignado
Gestionar Mantenedores A
Gestionar Plan de Estudios B
Gestionar Carga Académica C
Gestionar Apertura
Académica
D
Gestionar Proceso Matricula E
Gestionar Proceso Nota F
Gestionar Cierre Periodo
Académico
G
Gestionar Reportes H
Codificación
Elaboración del documento de diseño de base de datos.
Elaboración de estándares de programación e interfaz gráfica.
Establecimiento de las iteraciones así como de las especificaciones del
plan de pruebas de software.

30
 001- 008 – Numero Consecutivo
 R – Requerimiento
 A,B,C,D,E,F,G,H – Valor Asignado a los Módulos
002RB
001RA
003RC
004RD
008RH
007RG
005RE
006RF

31
4.2.4.1. Requerimientos
Correlat.Req.
Cód.Req.
Requerimiento
CanalAutoriz.
(iniciales)
Fecha
Analista(iniciales)
Atributos
R+Cód.Módulo
N°Req-Mód
Prioridad
Dificultad
Visibilidad
Riesgo
Dependencia
FUNCIONALES
001 RA Módulo 1: GESTIONAR MANTENEDORES
RA 1
 MANTENER MODALIDAD
Es de prioridad alta, aquí gestionaremos todos los
datos necesarios relacionado con MODALIDAD, se
podrá crear, buscar, modificar; de acuerdo a los
requerimientos generados por director de la Oficina
General de Coordinación y servicios Académicos.
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJO -
RA 2
 MANTENER MENCIÓN
datos necesarios relacionado con MENCIÓN, se
podrá crear por primera vez una MENCION si
previamente exista un registro de MODALIDAD,
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJO RA1

32
donde será asignado la nueva MENCION, buscar,
modificar; de acuerdo a los requerimientos
generados por director de la Oficina General de
Coordinación y servicios Académicos.
RA 3
 MANTENERALUMNO
datos necesarios relacionado con el ALUMNO, se
podrá crear por primera vez una ALUMNO si
previamente exista un registro de MENCION, donde
será asignado el nuevo ALUNMO, buscar, modificar;
de acuerdo a los requerimientos generados por el
ALUMNO.
RA 4
 MANTENERDOCENTE
datos necesarios relacionado con el DOCENTE, se
podrá crear a un DOCENTE por primera vez, buscar,
modificar; de acuerdo a los requerimientos

33
generados por el DOCENTE y por el director de la
Oficina General de Coordinación y servicios
Académicos.
RA 5
 MANTENERPERIODO
datos necesarios relacionado con el PERIODO
ACADEMICO, se podrá crear a un PERIODO por
primera vez, buscar, modificar, activar; de acuerdo a
los requerimientos generados por el director de la
Académicos.
RA 6
 MANTENERCURSO
datos necesarios relacionado con los CURSO, se
podrá crear un CURSO si previamente exista un
registro de MENCION, donde será asignado el nuevo
CURSO, buscar, modificar; de acuerdo a los

34
requerimientos generados por el director de la Oficina
RA 7
 MANTENERSECCION
datos necesarios relacionados con un GRUPO o
SECCION, se podrá crear un GRUPO si previamente
exista un registro de MENCION, donde será
asignado el nuevo GRUPO, buscar, modificar; de
acuerdo a los requerimientos generados por el
director de la Oficina General de Coordinación y
servicios Académicos.
RA 8
 MANTENERPABELLÓN
datos necesarios relacionados con un PABELLÓN,
se podrá crear un PABELLÓN si previamente exista
un registro de MENCION, donde será asignado el
nuevo PABELLÓN, buscar, modificar; de acuerdo a

35
Académicos.
RA 9
 MANTENERAULA
datos necesarios relacionados con AULA, se podrá
crear una AULA si previamente exista un registro de
MENCION y PABELLÓN, donde será asignada la
nueva AULA, buscar, modificar; de acuerdo a los
RA 10
 MANTENERTIPO PROCESO
datos necesarios relacionados con TIPO DE
PROCESO para el periodo académico, se podrá
crear una TIPO DE PROCESO por primera vez,
buscar, modificar; de acuerdo a los requerimientos
generados por el director de la Oficina General de
Coordinación y servicios Académicos.

36
002 RB Módulo 2: GESTIONAR PLAN DE ESTUDIOS
RB 1
 REGISTRAR PLAN DE ESTUDIOS
datos necesarios relacionados con PLAN DE
ESTUDIO, se podrá crear un PLAN DE ESTUDIO, si
previamente exista un registro de MENCION, donde
se podrá buscar, modificar; de acuerdo a los
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA RA1
RB 2
 ASIGNAR CURSOS
Es de prioridad alta, aquí asignaremos cursos al
nuevo plan de estudio que fue previamente
registrado, se podrá asignar prerrequisito, buscar
curso y cambiar el estado el curso, de acuerdo a los
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA RB1
RB 3
 CAMBIAR ESTADO DEL PLAN DE ESTUDIO
Es de prioridad alta, aquí se podrá cambiar el estado
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA RB1

37
de inactivo a activo o viceversa del plan de estudios
que dependerá de la existencia del plan de estudio y
a los requerimientos generados por el director de la
Académicos.
003 RC MODULO 3: GESTIONAR CARGA ACADEMICA
RC 1
 REGISTRAR CURSO GRUPO
Es de prioridad alta, aquí gestionaremos el registro
de curso grupo, que incluye verificar el curso para
poder asignar un grupo al curso, de acuerdo a los
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA -
RC 2
 REGISTRAR HORARIO
del horario para el curso, que incluye verificar el curso
con su respectivo grupo para poder asignar un horario
al curso, de acuerdo a los requerimientos generados
por el director de la Oficina General de Coordinación
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA RC1

38
y servicios Académicos.
004 RD MODULO 4: GESTIONAR APERTURA ACADEMICA
RD 1
 REGISTRAR PERIODO PROCESO
de los procesos para el periodo actual, que incluye
buscar el periodo, buscar el proceso, de acuerdo a
Académicos.
RD 2
 REGISTRAR PROCESO MENCION
de los procesos para cada mención, que incluye
buscar el proceso, buscar el mención, de acuerdo a
Académicos.
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA RD1

39
005 RE MODULO 5: GESTIONAR PROCESO MATRICULA
RE 1
 GENERAR AVANCE CURRICULAR
Es de prioridad alta, aquí se podrá generar avances
curriculares, que incluye buscar modalidad, buscar
mención, buscar plan de estudio que de acuerdo a
Académicos se podrá realizar el proceso.
RE 2
 GENERAR FICHA DE MATRICULA
Es de prioridad alta, aquí se podrá generar FICHAS
DE MATRICULA, que incluye buscar modalidad,
buscar mención, verificar el periodo actual que de
servicios Académicos se podrá realizar el proceso.
RE 3
 REALIZAR MATRICULA DE INGRESANTES
Es de prioridad alta, aquí se podrá realizar
MATRICULA DE INGRESANTES, que incluye buscar
FAFM 01/05/2013 FFMMTM ALTA MEDIA V BAJA
RE1-
RE2

40
modalidad, buscar mención, buscar plan de estudio y
verificar los cursos, que de acuerdo a los
General de Coordinación y servicios Académicos se
podrá realizar el proceso.
RE 4
 REALIZAR MATRICULA NORMAL
Es de prioridad alta, aquí se podrá realizar una
MATRICULA NORMAL, que incluye buscar
modalidad, buscar mención, buscar Alumno y verificar
periodo, que de acuerdo a los requerimientos
Coordinación y servicios Académicos, además del
alumno se podrá realizar el proceso.
FAFM 01/05/2013 FFMMTM ALTA MEDIA V BAJA RE2
006 RF MODULO 6: GESTIONAR PROCESO DE NOTAS
RF 1
 GENERAR ACTAS NOTAS
Es de prioridad alta, aquí se podrá GENERAR
ACTAS NOTAS, que incluye buscar modalidad,
buscar mención, buscar periodo y buscar concepto de

41
actas, que de acuerdo a los requerimientos
Coordinación y servicios Académicos se podrá
realizar el proceso.
RF 2
 REGISTRAR NOTAS
Es de prioridad alta, aquí se podrá registras notas de
los cursos matriculado por los alumnos, que incluye
buscar modalidad, buscar mención, verificar periodo
actual y cargar alumnos, que de acuerdo a los
podrá registrar las notas.
FAFM 01/05/2013 FFMMTM ALTA BAJA V BAJA RF1
007 RG MODULO 7: GESTIONAR CIERRE DE PERIODO ACADEMICO Y REPORTES
RG 1
 APLICAR CIERRE DE HORARIO
Es de prioridad alta, aquí se podrá APLICAR EL
CIERRE DE HORARIO DEL PERIODO ACTUAL, que
incluye buscar modalidad, buscar mención, verificar
periodo actual, que de acuerdo a los requerimientos

42
Coordinación y servicios Académicos se podrá aplicar
el cierre.
RG 2
 APLICAR CIERRE DE NOTAS
CIERRE DE REGISTRO DE NOTAS DEL PERIODO
ACTUAL, que incluye buscar modalidad, buscar
mención, verificar periodo actual, que de acuerdo a
Académicos se podrá aplicar el cierre.
RG 3
 APLICAR CIERRE DE MATRICULA
CIERRE DE MATRICULA DEL PERIODO ACTUAL,
que incluye buscar modalidad, buscar mención,
verificar periodo actual, que de acuerdo a los
podrá aplicar el cierre.

43
RG 4
 ACTUALIZAR AVANCE CURRICULAR
Es de prioridad alta, aquí se podrá ACTUALIZAR
AVANCE CURRICULAR, que incluye buscar
modalidad, buscar mención, buscar plan de estudios,
seleccionar todos los alumno, verificar periodo actual,
que de acuerdo a los requerimientos generados por
el director de la Oficina General de Coordinación y
servicios Académicos se podrá actualizar avances
curriculares.
RG 5
 IMPRIMIR AVANCE CURRICULAR EN
GRUPO
Es de prioridad alta, aquí se podrá IMPRIMIR
AVANCE CURRICULAR EN GRUPO, que incluye
buscar modalidad, buscar mención, buscar plan de
estudios, seleccionar todos los alumno, verificar
periodo actual, que de acuerdo a los requerimientos
Coordinación y servicios Académicos se podrá
imprimir en grupo.

44
RG 6
 IMPRIMIR RECORD ACADEMICO
RECORD ACADEMICO, que incluye buscar
buscar alumno, verificar periodo actual, que de
servicios Académicos se podrá imprimir el record
académico.
RG 7
 IMPRIMIR AVANCE CURRICULAR
INDIVIDUAL
AVANCE CURRICULAR, que incluye buscar
buscar alumno, verificar periodo actual, que de
servicios Académicos se podrá imprimir avance.

45
NO FUNCIONALES
 El usuario interactuará con el sistema
utilizando el teclado y mouse.
FAFM 01/05/2013 FFMMTM MEDIA BAJA V BAJA -
 El sistema será desarrollado con una interfaz
gráfica de usuario basada en controles web. FAFM 01/05/2013 FFMMTM MEDIA BAJA V BAJA -
 El sistema estará disponible vía intranet en
horarios de oficina. FAFM 01/05/2013 FFMMTM MEDIA BAJA V BAJA -
 El sistema será accesible desde cualquier
equipo de trabajo con navegador web
Microsoft Internet Explore 9.0, Google Chrome
(17.0 o superior) y Mozilla Firefox (2.0 o
superior).
 El sistema se ejecutará sobre un servidor de
aplicaciones web con sistema operativo
Windows Server 2008 en adelante.

46
 El sistema trabajara con el administrador de
base de datos Sql Server 2008.
 El sistema contará con manuales de usuario
para su entendimiento y capacitación en la
herramienta.

47
4.2.4.2. Consideraciones sobre el sistema
Como alcance de la propuesta quedan excluidas las
automatizaciones de los procesos en contabilidad, logística, gestión
de planillas, recursos humanos, Convalidación de Planes de Estudio,
Sistema de correo, importación y exportación de archivos en formato
Excel. En contraparte, se respetarán las siguientes restricciones:
Validación: La información ingresada por teclado es verificada como
medida preventiva ante posibles errores en el proceso.
Seguridad: Acceso al sistema a personas mediante cuentas de
usuario y contraseña. En función a los perfiles y accesos se
controlará el nivel de visibilidad de la información.
Escalabilidad: La arquitectura posibilitará la incorporación de nuevas
funcionalidades y módulos flexiblemente sin procedimientos drásticos
para el desarrollador.
Usabilidad: Para la familiarización del usuario con el software se
requiere una interfaz gráfica ligera e intuitiva sumada a una correcta
emisión de avisos de error y advertencia. El usuario iniciará todas las
operaciones requeridas.
Performance: Garantiza un tiempo de acceso no mayor a siete (7)
segundos.

48
Como consecuencia de las entrevistas efectuadas y según los
requerimientos analizados a partir de la lista de exigencias, se
presenta a continuación la descripción de los actores participantes
del sistema:
4.2.5. Análisis de la Solución
Se presenta a continuación el trabajo llevado a cabo durante el análisis de
la solución tomando como base las recomendaciones establecidas por
Roger Pressman, desde la relación de funcionalidades deseadas e
Usuario: Toda persona con una cuenta y accesos autorizados al
sistema.
Administrador: Realiza funciones tales como administrar cuentas,
perfiles de usuario y monitorear el funcionamiento del sistema. La
notificación de errores a presentarse con la plataforma es
competencia exclusiva de este actor.
Coordinador: Cumple el rol de dirigir y llevar a cabo los
programas, así como ejecutar los procesos de registro de la
evaluación de la notas finales, además de los mantenimientos y
los procesos cotidianos de matrícula.
Alumno: Alumno perteneciente al menos en una mención de la
escuela de Postgrado de la Universidad Nacional de Ucayali,
actor que proporciona de datos para su posterior administración.

49
identificadas por los usuarios de la Oficina General de Coordinación y
servicios Académicos, la viabilidad técnica y económica, el análisis costo –
beneficio del proyecto, la asignación de funciones a los elementos del
sistema hasta el establecimiento de restricciones en costo y tiempo y la
definición del producto.
4.2.5.1. Identificación de las Necesidades del Usuario
Como principales necesidades establecidas por los Usuarios:
A partir de la lista de exigencias y habiendo identificado las
necesidades de los usuarios es factible construir el diagrama de
casos de uso y actores.
La especificación del caso de uso que se muestra en el
siguienteDiagramase encuentra en el Anexo B: Especificación de
Disponibilidad de información del avance curricular de los
alumnos o seguimiento académico.
Acceso a tiempo completo de la información y documentación
académica.
Establecimiento de un mecanismo de verificación de las notas de
los alumnos.
Registro de la evaluación académica de los alumnos.
Evaluación de los programas o menciones dictadas en un periodo
académico.

50
requisitos de software. La propuesta de solución contará con siete
módulos funcionales destinados a solucionar los problemas de
Registro de Notas.
Figura: Diagrama de Casos de Uso de Negocio
System
Gestionar Mantenedores
Gestionar Apertura Academica
Gestionar Carga Academica
Gestionar Proceso Matricula
COORDINADOR
ADMINISTRADOR
ALUMNO
Dir. POSTGRADO
Gestionar Proceso nota
Gestionar Plan de Estudio
Gestionar Cierre Periodo A cademico y Reportes
DOCENTE

51
4.2.5.2. Viabilidad Técnica y Económica
Para la viabilidad técnica se presentan las restricciones en hardware
y software, las restricciones técnicas identificadas son las siguientes:
(1) Disponibilidad del equipo de cómputo/servidor para albergar a la
base de datos.
(2) Disponibilidad del equipo de cómputo/servidor para su utilización
como servidor de aplicaciones Web.
(3) Disponibilidad del equipo de cómputo para las labores de análisis
y diseño.
(4) Herramientas CASE de libre distribución para el modelamiento
UML y construcción de la base de datos de la solución.
(5) Sistema administrador de base de datos de libre distribución con
capacidad para soportar múltiples conexiones.
(6) Librerías DLL con capacidad de transmisión de datos entre
aplicaciones en .NET y servidor de base de datos Sql server 2008. A
su vez, compatible con las operaciones de persistencia de datos en
ADO.NET Entity Framework (EF4).
(7) El lenguaje de programación y sus características para la
construcción bajo el paradigma orientado a objetos.

52
Este proyecto es técnicamente viable porque se cuenta con todos los
requisitos citados. Bajo una adecuada planificación de recursos y con
miras a maximizar las capacidades logísticas existentes, se
adoptarán las siguientes medidas:
Los requerimientos (1) y (2) quedan cubiertos empleando una
computadora con procesador Intel de séptima generación y memoria
RAM de 4GB, dadas las exigencias del servidor de base de datos y
sistema operativo. El requerimiento (3) está constituido por un equipo
portátil Core Duo de 2GHz y 3GB de memoria RAM ofreciendo así un
rendimiento superior para las fases de análisis y diseño.
Para el requisito (4) existen productos como Visual Paradigm CE,
ArgoUML y StarUML sujetos a las exigencias técnicas propias de la
documentación con RUP y además son de libre distribución. En el
proyecto se hará uso del software StarUML.
El requerimiento (5) se encuentran cubiertos con la incorporación de
las herramientas IDE Microsoft Visual Web Developer 2010 Express
(una versión gratuita y liviana para el desarrollo Web con ASP.NET) y
del administrador de base de datos Sql server 2008.
Npgsql es un proveedor de datos gratuito para bases de datos
PostgreSQL en la plataforma Microsoft .NET Framework. Esta
librería DLL a partir de su versión 2.0 soporta operaciones con

53
ADO.NET Entity Framework (EF4). Se elige este manejador para el
cumplimiento del requisito (7).
4.2.5.3. Análisis Costo – Beneficio
En este análisis se presentan las razones y criterios tomados como
justificación para el desarrollo del proyecto y la inversión económica.
Una vez expuestos los detalles del costo y gastos a incurrir en el
proyecto, arroja como conclusión la no existencia de una fuerte
inversión en hardware y software gracias al empleo de herramientas
informáticas de código abierto como de licencia gratuita y bajo la
condición de aprovisionamiento del hardware por parte de la Oficina
General de Coordinación y Servicios Académicos.
Si se introduce en este análisis la curva de experiencia profesional en
proyectos académicos y laborales (así como en el uso de
herramientas CASE e IDE) la reducción del margen de horas en cada
perfil es altamente probable. El costo en función al tiempo (llevando
este tratamiento a una escala horaria) queda sustentado pues las
estimaciones elaboradas se alinean a las actividades fijadas en el
cronograma de proyecto.
En ese sentido, tras el análisis efectuado, la solución presenta
mayores beneficios a futuro para todos los participantes en esta
institución. En otras palabras, es viable dadas las ventajas y mejoras

54
ofrecidas en la automatización de los procesos para la gestión
académica.
4.2.5.4. Asignación de Funciones a Hardware y Software
Las funciones asignadas al hardware durante el proyecto son:
Las funciones asignadas al software durante el proyecto son:
En cuanto al producto software, como principales funciones
comprometidas se tienen:
Como servidor Web, cumplir con el almacenamiento físico de la
aplicación Web.
Como servidor de base de datos, cumplir con el almacenamiento
físico del servidor de base de datos.
Albergar aplicaciones ofimáticas y herramientas CASE e IDE
requeridas para labores de análisis y diseño.
Asistir en las actividades de diagramación, modelamiento y
documentación durante las fases de análisis y diseño.
Permitir la codificación óptima y eficiente de los módulos,
componentes y funcionalidades de la solución.

55
Las funciones asignadas a nivel de base de datos a lo largo del
proyecto son:
Las funciones asignadas a los usuarios durante el transcurso del
proyecto son:
Interactuar con los servidores y el computador cliente desde el
cual se conecta el usuario.
Cumplir con la ejecución de los procesos de matrícula y el registro
de notas finales obtenidos a partir de la lista de exigencias de la
solución.
Almacenar una base de datos única para las operaciones de
lectura y escritura.
Permitir el almacenamiento y recuperación de la información
necesaria.
De ser necesario, admitir las configuraciones de conexión con la
base de datos realizadas dentro o fuera del motor de base de
datos.

56
4.2.5.5. Definición del Sistema
Se presenta la definición del sistema a partir del diagrama de clases
de análisis involucrando a las entidades principales en el
modelamiento del escenario de negocio. Este análisis favorecerá al
establecimiento y definición de la arquitectura final junto con las
clases de diseño necesarias para su construcción. La solución cubre
los requerimientos revisado en la sección2.2 a través de siete
paquetes representados en el diagrama de paquetes (ver Diagrama
04).
Colaborar con el levantamiento de información de los
requerimientos.
Ingresar los datos apropiados de acuerdo con los propósitos de
cada módulo incorporado a la solución.
Cumplir con las pruebas de software necesarias

57
Figura: Diagrama de Paquetes
4.3. CAPITULO 3: Diseño
En este capítulo se describe el diseño de la solución propuesta. La primera
parte comprende el diseño en alto nivel de la arquitectura justificando la
elección de un patrón arquitectónico. Respecto a la interfaz gráfica, se
mencionan los patrones y estándares adoptados para uniformizar el
aspecto visual y la interacción con el usuario.
4.3.1. Arquitectura de la Solución
En esta sección se explica el diseño a alto nivel y los paradigmas
arquitectónicos evaluados para posteriormente presentar la arquitectura
final. Para mayores referencias, revisar el Anexo C: Documento de diseño
del sistema y Anexo D: Documento de arquitectura del sistema.
GESTION_MANTENEDORES
GESTION_PLAN_ESTUDIOS
GESTIONAR_CARGA_ACADEMICA
GESTIONAR_APERTURA_ACADEMICA
GESTIONAR_PROCESO_MATRICULA
GESTIONAR_PROCESO_NOTA
GESTIONAR_CIERRE_REPORTES

58
4.3.1.1. Representación de la arquitectura
De acuerdo con capítulos anteriores la arquitectura está orientada a
entornos Web.
Bajo este diseño las tareas se ejecutan por el lado del servidor,
evitando delegar tales responsabilidades hacia las máquinas clientes
desde sus navegadores.
Es así como el diseño debe garantizar un óptimo aprovechamiento
de las capacidades propias de los sistemas Web satisfaciendo
adecuadamente los requisitos no funcionales del producto. La
arquitectura respetará el paradigma de programación orientado a
objetos.
Esta característica si bien depende del lenguaje de programación
utilizado, la propuesta de diseño debe asegurar la manipulación de
los datos y operaciones de manera encapsulada a través de clases y
objetos interrelacionados entre sí por invocaciones a los métodos
respectivos. El manejo de cambios en el producto se logra
modificando las características de un número determinado de
componentes sin comprometer el funcionamiento del resto de
módulos.
Para la lógica de negocio la arquitectura trabajará bajo el patrón
Modelo de Dominio. Este patrón consta de un conjunto de objetos de

59
negocio representando las entidades en un dominio y sus relaciones
entre ellos.
El modelo representa en forma abstracta el negocio real
encapsulando las reglas de negocio y recreando así un flujo de
trabajo habitual. Bajo este patrón no se tiene conocimiento del
mecanismo de persistencia de los datos, delegando esta
responsabilidad a otro ámbito.
La arquitectura, para el manejo de la capa de datos, adoptará el
patrón de Repositorio. Un repositorio encapsula un conjunto de
objetos ―persistidos‖ en una base de datos junto con sus operaciones
de lectura y escritura. Este esquema provee una visión más
orientada a objetos en la capa de persistencia logrando dos metas:
brindar una clara separación y dependencia en un solo sentido entre
el modelo de dominio y el mapeo de datos colocando una ―fachada‖
sobre el nivel de persistencia, eximiendo así a la capa de lógica de
negocio de la responsabilidad del funcionamiento del mecanismo de
persistencia de datos.
4.3.1.2. Diseño de la arquitectura de la solución
Para la implementación de esta solución se aplicará la arquitectura
en N-Capas, debido a su diseño altamente escalable ante la
incorporación de nuevos módulos y funcionalidades a futuro. Además
posibilita la distribución de componentes (capas) entre varios niveles

60
de hardware, obteniendo mayor seguridad y rendimiento ante
numerosas peticiones al servidor Web. Esta arquitectura orientada a
objetos no presenta obstáculos para adaptar tanto el patrón de
modelo de dominio en la capa de lógica de negocio como el patrón
de repositorio en la capa de acceso a datos, cumpliendo así con los
lineamientos base de diseño indicados a comienzos del capítulo. La
arquitectura queda dividida en cuatro capas descritas a continuación
(ver Diagrama: componentes de la arquitectura):
Capa de Presentación: Esta capa integra los elementos de la
interfaz gráfica y las clases con la lógica del comportamiento de las
páginas para su interacción con el usuario. Involucra librerías CSS,
JavaScript, Ajax, ASPX y HTML. Esta capa actúa de forma similar a
la Vista en el patrón MVC.
Capa de Aplicación: Esta capa tiene como función delegar las
solicitudes de usuario provenientes de la capa previa hacia los
módulos y clases correspondientes de la Capa de Lógica de
Negocio, sin involucrar la implementación en líneas de código de
dicha solicitud. Asimismo actúa como fachada para futuras
implementaciones de integración con otros dispositivos, plataformas
y sistemas a través de aplicaciones como servicios Web.
Capa de Lógica: Esta capa sigue la línea de trabajo de la entidad
Modelo del patrón MVC. Conformada por clases cuyas funciones

61
recaen en la implementación de la lógica de negocio atendiendo el
requerimiento de usuario.
Interactúa con la capa de base de datos de acuerdo con el
tratamiento deseado de la información intercambiada. La codificación
de la lógica de negocio sigue el patrón modelo de dominio.
Capa de Acceso a Datos: En esta capa se ubicarán las clases DAO
y librerías de conexión encargadas de administrar las operaciones
CRUD (Create – Read – Update – Delete) y sentencias SQL a nivel
de base de datos. La codificación de esta capa sigue el patrón
repositorio.
Figura: Diagrama de componentes de la arquitectura
Interfaz Gráfica
Aplicación
Logica
DAO
Objeto de Negocio
Sql Server 2008

62
Para el intercambio de información entre las capas tratadas, se hace
uso de un conjunto de entidades de negocio, cuyas clases
representan el escenario real del negocio. La arquitectura propuesta
satisface los requerimientos no funcionales de diseño definidos en el
capítulo anterior. La siguiente tablarefleja cómo esta elección
satisface los requerimientos de diseño.
3. Tabla: Requerimientos de diseño vs. Solución arquitectónica
Requerimiento no funcional Solución propuesta
El sistema será desarrollado con
una interfaz gráfica de usuario
basada en controles Web.
La codificación de la Capa de
Presentación no será controlada por la
Capa de Lógica, otorgando mayor libertad
para incorporar los elementos gráficos y
HTML adecuados.
El sistema será accesible desde
cualquier equipo de trabajo con
navegadores Web Microsoft
Internet Explorer (9.0 o superior) y
Mozilla Firefox (2.0 o superior).
La lógica de la Capa de presentación
residirá en el servidor de aplicaciones
Web y por el lado del cliente sólo
observará código HTML compatible con
los navegadores Web. En caso se
requiera ejecutar lógica por el lado del
cliente las librerías AJAX de igual forma
simplifican esta labor conservando la

63
compatibilidad.
El sistema se ejecutará sobre un
servidor de aplicaciones Web con
sistema operativo Windows Server
2003 en adelante.
El sistema será albergado en el servidor
IIS Express de libre distribución.
El sistema trabajará con el
administrador de base de datos
sql server 2008
En la Capa de Acceso a Datos se ubicará
el componente de conexión a la base de
datos deseada, independiente del resto
de la aplicación.
Entre los objetivos y restricciones aplicables a esta arquitectura destacan:
Validación de información: Para la validación de los datos de
entrada y salida se contará con controles desarrollados bajo las
librerías Ajax (ubicadas en la Capa de Presentación) y con las reglas
impuestas en la Capa de Lógica.
Performance: Para fines de implantación la arquitectura es afín al
establecimiento de diferentes niveles físicos (o de hardware) por
capa mejorando el rendimiento. Respecto a los clientes navegadores

64
Web, la arquitectura soporta la ejecución de múltiples transacciones
desde otras conexiones en simultáneo.
Protección: La autenticación y validación de acciones al usuario
queda a cargo del módulo Seguridad en la Capa de Lógica.
Unicidad: La arquitectura en su Capa de acceso a datos permite la
interacción con una base de datos a la vez, canalizando todas las
operaciones de lectura y escritura hacia ésta.
4.3.1.3. Vista Lógica
La siguiente figura representa la vista lógica del software con las
cuatro capas descritas, así como los principales componentes
encargados de su funcionamiento.

65
Figura: Vista lógica del sistema
4.3.1.4. Vista de despliegue
A continuación la Figura5 grafica la representación de las relaciones
entre losnodos físicos y su localización junto con los componentes en
hardware y software.
CAPADE
PRESENTACIÓN
Componentes GUI(ASPX,CSS,AJAX,JSP,JSCRIPT)
Componentes de
configuración (.config)
Componentes Error
Handler (Elmah)
Componentes de Lógica de Presentación (CS, HTML)
CAPADE
APLICACIÓN Componentes de Aplicación
Componentes de Lógica de Presentación (CS, HTML)
CAPADE
LOGICA
Componentes de Lógica de Negocio
Implementación de Lógica de Negocio
CAPADEACCESO
ADATOS
Implementación
DAO
Componentes
ADO.NET
Componentes Sql
ENTIDAD DE
NEGOCIO
Componentes BE
CSDL, MSL, SSDL

66
Figura. Diagrama de despliegue
Los nodos indicados en la Figura se describen a continuación
4.3.1.5. Diagrama de Clases de Diseño
La explicación del diagrama de clases de diseño y los diagramas de
secuencias se detalla en el Anexo C: Documento de diseño del
sistema.
Servidor Web y de Aplicación Estación Cliente
DAO
Interfaz GUI
Aplicación
Logica
Objeto de Negocio
Navegador Web
Servidor de Base de Datos
Motor Sql Server
Estación cliente: Este nodo representa al navegador Web de la
máquina cliente, desde el cual se realiza la conexión al sistema.
Servidor Web y de Aplicación: En este nodo residen los archivos del
código fuente con la lógica de negocio estructurada en capas.
Servidor de Base de datos: Este nodo contiene el sistema
administrador de base de datos. Interactúa con el nodo de servidor
Web en su capa de acceso a datos (DAO).

67
4.3.1.6. Diagrama de Base de Datos
El diagrama de base de datos para las operaciones del sistema y el
diccionario de datos se encuentra en el Anexo C: Documento de
diseño del sistema.

68
5. ANALISIS CRÍTICO Y APORTE A LA EMPRESA
5.1. Análisis Crítico
La Oficina General de Coordinación y Servicios Académicos no cuenta con
un sistema que le permita automatizar los procesos de la gestión
académica. Los documentos con la información de los estudiantes llegan a
la oficina de Coordinación por parte de la escuela de Post Grado y estos
son archivados en folder según la modalidad, mención y año en que
empezó a estudiar el alumno.
Con respecto a las notas o calificaciones de los diferentes cursos que llevan
los alumnos, éstas son guardadas en Excel, de manera que es inadecuado
el proceso de registro de notas y todo lo demás mencionado anteriormente.
5.2. Aporte Técnico
El presente trabajo fue el análisis y diseño de un sistema de información
para que así se pueda tener un mayor control de los procesos en la gestión
académica de la escuela de Postgrado en la Oficina General de
Coordinación y Servicios Académicos.

69
6. CONCLUSIONES
Se Identificó los procesos que se presentan en la gestión académica de la
escuela de Postgrado en la oficina general de Coordinación y Servicios
Se aplicó Prácticas del desarrollo Ágil y UML para elaborar el análisis y
diseño de un Sistema de Información para la gestión académica de la
escuela de Postgrado en la oficina general de Coordinación y Servicios
Un sistema de información es un conjunto de componentes
interrelacionados que reúne (u obtiene), procesa, almacena y distribuye
información, de esta manera automatizará los procesos para la gestión
académica.

70
7. RECOMENDACIONES
Como trabajos a futuro en este campo, se recomienda incorporar los
procesosautomatizados de la gestión de convalidaciones de plan y la
importación de archivos a Excel. Con lo anterior el análisis de se realizó
para esta solución prácticamente abarcaríatodas las operaciones y
actividades de dichas instituciones. Respecto al módulo

71
8. BIBLIOGRAFIA
AMBYSOFT. (02 DE JUNIO 2011). THE AGIL UNIFED PROCESS (AUP).
DEAN, L. (2011). AGIL SOFTWARE REQUIREMENTS.
JULY, M. (2003). ENTERPRICE SOLUTION PATTERNS USING MICROSOFT .NET VERSION 2.0.
MICROSOFT. (2009). NET APPLICATIOIN ARCHITECTURE GUIDE.SEGUNDA EDICION.
NETWORK, M. D. ( 2007). THE REPOSITORY PATTERN, MATERIAL DE CONSULTA.
PRESSMAN, R. (2002). INGENIERIA DE SOFTWARE: UN ENFOQUE PRACTICO . MEXICO: QUINTA
EDICION.
SERVICES, L. (s.f.). IEPWRITER - ONLINE SPECIAL EDUCATION DATA MANAGEMENT .

73
ANEXO A.
POSTGRADO SYSTEM
Plan de Gestión de Riesgos
Versión 1.0
ELABORADO POR : Terán Maca, Marlon David.
REVISADO POR : Ing. Amílcar Figueroa
Pucallpa - Perú
2013

74
Historial de Revisiones
Historial de revisiones
Ítem Fecha Versión Descripción Equipo
1 10/04/2013 1.0 Lista de Exigencias PRACTICANTES

75
1. Introducción
1.1. Objetivo
El objetivo de este documento es definir y prevenir los riesgos que corre el
proyecto Postgrado System.
1.2. Alcance
El presente documento describe los riesgos identificados durante todo el
proyecto.
1.3. Definiciones, acrónimos y abreviaturas
Ninguna.
1.4. Referencias
Las referencias aplicables son:
Lista de Exigencias.
Plan de Proyecto
Ninguna
 Internas:
 Externas:

76
2. Lista de Riesgos
4. Tabla: Lista de Riesgos
° Descripción del riesgo Consecuencias Prob. Impacto Responsable Estrategia de Mitigación Estado
Planificación
1
La lista de Exigencias tomada
del usuario es poco clara y no
define bien el alcance del
proyecto
Avanzar con
documentos con el
alcance poco claro
y tener dificultades
al crearlos.
Media Medio
Analista/Programador
Funcional
Estar en comunicación con el
Usuario al momento de captar
los requerimientos y tener
preguntas concisas y claras.
OK
2
Usuario no cumple con el
plazo de revisión
Atraso en el
cronograma
Media Alto
Funcional
Comunicarse semanalmente
con el usuario
OK
3
Enfermedad crítica o
Accidente que le pasa a
alguno de los Miembros del
Equipo.
El alcance del
proyecto será
reducido.
Baja Alto Equipo practicantes
El equipo compensará la
ausencia de cualquier recurso.
PEN
4
Cambiar la fecha de entrega
de las tareas designadas
para la fecha establecida
Atraso el plan de
proyecto y recarga
de tareas para la
próxima entrega Baja Alto
Jefe de Proyecto y
Compensar los tiempos
designados dedicándole mayor
esfuerzo al trabajo y tratar de
adelantarse en la entrega de
los documentos acordados OK
Organización y Gestión
6
Confusión de Versiones de
documentos
Pérdida de días de
trabajo y esfuerzo
realizado
Media Medio
Funcional
Cada miembro del equipo
deberá actualizar las versiones
utilizadas cada vez que
modifique algún documento o
parte del software
OK
8
Falta de tiempo para
reuniones generales por un
miembro del equipo
No todo el equipo
se llega a enterar
de los acuerdos y
realizan tareas no
indicadas o no
realizan lo que
tienen pendiente
Media Medio Equipo practicantes
Conversar con todos los
miembros del equipo
OK
10
Problemas de Impresión de
documentos del software
Dificultades al
momento de
entregar el avance
documentado al
usuario.
Baja Bajo Jefe de Proyecto
Tener siempre una versión
electrónica de respaldo del
documento a presentar impreso
OK
Cliente

77
11
Surgimiento de nuevos
requisitos por parte del
cliente
Cambios
inesperados en el
cronograma y
negociación con el
cliente.
Baja Medio
Jefe de Proyecto y
Tener siempre presente los
documentos iniciales y de
contrato con el cliente para
prevalecer con lo acordado
OK

78
ANEXO B
POSTGRADO SYSTEM
Especificación de Requisitos del Software
Versión 2.3
ELABORADO POR : Terán Maca Marlon David.
REVISADO POR : Ing. Amílcar Figueroa
Pucallpa - Perú
2013

79
Historial de Revisiones
Historial de revisiones
Ítem Fecha Versión Descripción Equipo
1 02/03/2013 1.0 Versión Preliminar ERS. PRACTICANTES
2 05/03/2013 1.1 Versión Preliminar ERS Finalizada. PRACTICANTES
3 09/03/2013 1.2 Modificación ERS. PRACTICANTES
6 23/03/2013 2.2 Revisión del alcance del sistema. PRACTICANTES
7 24/03/2013 2.3 Revisión de casos de uso PRACTICANTES

80
1. INTRODUCCIÓN
El presente documento es una Especificación de Requisitos (ERS) del sistema
POSTGRADO SYSTEM el cual brinda la especificación de los diferentes
escenarios presentes en el desarrollo del diseño, especificando la descripción de
los casos de uso y la funcionalidad de cada uno de los módulos donde se
desenvuelven. Esta especificación se ha realizado tomando como base al
estándar ―IEEE Recommended Practice for Software Requirements Specification
IEEE Std 830-1998‖
1.1. Propósito
El propósito principal del documento que a continuación se presenta es
minimizar los problemas relacionados al desarrollo del software; esto se
lograra mediante una definición clara y concisa de cuál es el alcance de
este basándose en los requerimientos recogidos de los diferentes usuarios.
1.2. Ámbito del Sistema
La razón del desarrollo de este sistema es el poder brindar un soporte
técnico especializado y así brindar una solución óptima que gestione el
registro de notas y proceso de matrícula de los alumnos, para de esta
manera mejorar el desarrollo de los procesos de la institución.
1.3. Definiciones, Acrónimos y Abreviaturas
1.3.1. Definiciones
Actividades
Partes en las que se descomponen los diferentes
procesos.
Tareas
Partes en las que se ha descompuesto cada una
de las actividades

81
Subtareas
Partes en las que se ha descompuesto cada una
de las tareas
Paquetes
Agrupaciones de casos de uso y actores por
funcionalidad que proveerá el sistema.
1.3.2. Acrónimos
ERS Especificación de Requisitos de Software
1.4. Referencias
IEEE Recommended Practice for Software Requirements Specification
IEEE Std 830-1998
Lista de exigencias del sistema Postgrado System v2.0
1.5. Visión General de la ERS
Este documento consta de tres secciones. La sección 1 es la introducción y
proporciona una visión general de la ERS. En la sección 2 se da una
descripción general del sistema, con el fin de conocer las principales
funciones que debe realizar, los datos asociados y los factores, supuestos y
dependencias que afectan al desarrollo, sin entrar en excesivos detalles. En
la sección 3 se definen detalladamente los requisitos que debe satisfacer el
sistema.

82
2. Descripción General
En esta sección se presenta una descripción a alto nivel del sistema. Se
presentará el modelo de casos de uso (modelo que muestra la funcionalidad del
sistema).
2.1. Modelo de Casos de Uso
En esta sección se presentan los diagramas de casos de uso del sistema
obtenidos durante el proceso de especificación de requisitos, los cuales
permiten mostrar un alto nivel de funcionalidad que el sistema realizará.
2.1.1. Diagrama de Paquetes
Figura: Diagrama de Paquetes2
2.1.1.1. Paquete de Mantenimiento
Contiene los casos de uso que corresponden al mantenimiento (registrar,
modificar y buscar) de todo lo que interviene en el llenado de notas finales
de los alumnos y el proceso de matrícula, como son los modalidad,
mención, alumno, docente,periodo, curso, sección, aula, pabellón, proceso.
GESTION_MANTENEDORES
GESTION_PLAN_ESTUDIOS
GESTIONAR_CARGA_ACADEMICA
GESTIONAR_APERTURA_ACADEMICA
GESTIONAR_PROCESO_MATRICULA
GESTIONAR_PROCESO_NOTA
GESTIONAR_CIERRE_REPORTES

83
Figura: Diagrama de Casos de Usos del Paquete de Mantenimientos
System
COORDINADOR
ALUMNO
ADMINISTRADOR
DOCENTE
gestionar modalidad
registrar mencion
registrar alumno
registrar docente
registrar periodo
registrar curso
registrar seccion
registrar pabellon
registrar aula
registrar proceso
registrar modalidad
OGCySA
gestion de mantenedores
<<include>>
gestionar mencion
<<include>>
establecer los requerimientos generales
buscar modalidad
buscar mencion
gestionar alumno
buscar alumno
<<include>>
gestionar docente
<<include>>
buscar docente
gestionar periodo
buscar periodo
activar periodo
<<include>>
getionar curso
buscar curso
gestionar seccion
buscar seccion
gestionar pabellon
buscar pabellon
getionar aula
buscar aula
<<include>>
<<include>>
<<include>>
<<include>>
gestionar procesos
<<include>>
<<include>>
<<include>>
<<include>> <<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>><<include>>
<<include>>
<<include>>

84
2.1.1.2. Paquete Plan de Estudios
Contiene los casos de uso encargados de la gestión de plan de estudio
(Registrar, buscar, cambiar estado al plan de estudio, asignar curso,
asignar prerrequisito y cambiar estado del curso).
Figura: Diagrama de Casos de Usos del Paquete de Plan de Estudios
2.1.1.3. Paquete Carga Académica
Contiene los casos de uso encargados de la gestión de carga académica
(buscar grupo, asignar grupo, registrar grupo curso, asignar docente,
asignar horario curso).
COORDINADOR
ADMINISTRADOR
OGCySA
gestion plan de estudios PE
buscar PE
registrar PE
cambiar estado PE
asignar cursos PE
<<include>>
<<include>>
<<include>>
buscar modalidad
buscar mencion
<<include>>
<<include>>
<<include>>
buscar curso
<<include>>
asignar prerequisito
cambiar estado curso
<<include>>
<<include>>

85
Figura: Diagrama de Casos de Usos del Paquete Carga Académica
2.1.1.4. Paquetede Apertura Académica
Contiene los casos de uso encargados de la gestión de Apertura
académica (registrar periodo proceso, buscar proceso, registrar periodo
mención, buscar mención, buscar proceso).
Figura: Diagrama de Casos de Usos del Paquete de Apertura Académica
COORDINADOR
ADMINISTRADOR
OGCySA
Gestionar Carga Academica
verificar curso asignar grupo
buscar grupobuscar curso
registrar curso grupo
<<include>>
<<include>>
registrar curso horario
<<include>>
verificar curso grupo asignar horario
<<include>>
buscar docente
<<include>>
<<include>>
<<include>>
COORDINADOR
ADMINISTRADOR
OGCySA
establecer los requerimientos generalesGestionar Apertura Academica
registrar periodo proceso
registrar proceso mencion
buscar periodo
buscar proceso
<<include>>
<<include>>
<<include>>
<<include>>
buscar_mencion
<<include>>
<<include>>

86
2.1.1.5. Paquete de Proceso de Matricula
Contiene los casos de uso encargados de la gestión de Proceso de
matrícula (registrar matricula normal, verificar periodo, buscar alumno,
verificar cursos, realizar matrícula de ingresantes buscar plan de estudios,
generar ficha de matrícula, generar avance curricular, retiro total,
reinscripción y retiro total).

87
Figura: Diagrama de Casos de Usos del paquete de Proceso de Matricula
COORDINADORADMINISTRADOR
ALUMNO
OGCySA
Gestionar Proceso Matricula
generar avance curriculargestionar matricula generar ficha matricula
buscar mencion
buscar plan de estudio
buscar modalidad
verificar periodo
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
realizar matricular normal realizar matricula ingresantes
<<include>>
verificar cursos
<<include>>
buscar alumno
<<include>>
<<include>>
<<include>>
establecer los requerimientos
reinscripcion
retiro total
retiro parcial
<<extend>>
<<extend>>
<<extend>>

88
2.1.1.6. Paquete de Proceso de Notas
Contiene los casos de uso encargados de la gestión de Proceso de notas o
registros finales (generar actas de notas, registrar notas, verificar cursos,
cargar alumnos).

89
Figura: Diagrama de Casos de Usos del Paquete de Proceso de Notas
COORDINADORADMINISTRADOR
OGCySA
gestionar proceso de notas
generar actas notas registrar nota
buscar modalidad buscar mencion buscar periodo
<<include>>
<<include>>
buscar concepto actas
<<include>>
verificar periodo
<<include>>
<<include>>
verificar curso
<<include>>
cargar alumnos
<<include>>

90
2.1.1.7. Paquete de Cierre de Periodo Académico y Reportes
Contiene los casos de uso encargados de la gestión de cierre de periodo
académico y reportes finales (aplicar cierre de matrícula, aplicar cierre de
notas, aplicar cierre horario).

91
Figura: Diagrama de Casos de Usos del Paquete Gestionar Cierre Periodo Académico y Reportes
COORDINADOR ADMINISTRADOR
ALUMNO
Gestionar Reportes
imprimir avance curricular
buscar modalidad
buscar mencion
buscar plan de estudio
verificar periodo buscar alumno
imprimir record academico
imprimir todos los avances
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
actualizar avance curricular
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
seleccionar todos los alumnos

92
3. Requisitos Específicos
Esta sección contiene a nivel detallado la funcionalidad y restricciones del sistema.
El detalle de la funcionalidad se determina con la especificación de casos de uso.
3.1. Especificación de Casos de Uso
Se detallaran las especificaciones de casos de uso más resaltantes
Lista de casos de uso del sistema: “Gestionar Mantenedores”
Código CUS: Nombre de Caso de Uso
CUS-GMO-001 Gestionar Modalidad
CUS-GME-002 Gestionar Mención
CUS-GAL-003 Gestionar Alumno
CUS-GDO-004 Gestionar Docente
CUS-GPE-005 Gestionar Periodo
CUS-GCU-006 Gestionar Curso
CUS-GSE-007 Gestionar Sección
CUS-GPA-008 Gestionar Pabellón
CUS-GAU-009 Gestionar Aula
CUS-GTP-010 Gestionar Tipo de Procesos

93
ESPECIFICACIÓN DE CU SISTEMA
GESTIONAR MODALIDAD
Código : CUS-GMO-001
Caso de uso: Gestionar Modalidad
Actor(es): - Coordinador.
- Administrador del sistema.
Propósito / Objetivo: Gestionar modalidad tiene como objetivo el registro de modalidades que
conformaran los distintos flujos de trabajo.
Resumen: El caso de uso se inicia cuando el administrador del sistema o coordinador
se dispone a registrar una nueva modalidad, para ello ingresa la información
solicitada por el sistema, como el código de la modalidad, el nombre, la
fecha de creación, la abreviatura, entre otros. El caso de uso termina
cuando se ha registrado la modalidad y esta se visualiza en el listado inicial.
Si hubo algún error al momento de ingresar la información para registrar la
nueva modalidad, esta se puede modificar.
Tipo: Real y Expandido.
Precondiciones: El administrador o coordinador ingreso correctamente al sistema y ha
seleccionado el módulo de MANTENIMIENTO.
Requerimientos
Asociados:
---
ESPECIFICACIÓN
1. Flujo Normal de Eventos
Acción del Actor Respuesta del Sistema
1. El Administrador o Coordinador selecciona la
opción en el menú/ MANTENIMIENTO ->
GESTIONAR MODALIDAD (Pantalla: Selección
de Opción en el Menú)

94
Listado de Modalidad
2. El sistema muestra la pantalla:
LISTARMODALIDAD, con las siguientes
opciones:
- (A) Nueva Modalidad: Ver sección:
Agregar una Modalidad.
- (B) Modificar una Modalidad
seleccionada: Ver sección: Editar la
Modalidad Seleccionada.
Listar de Modalidad
Sección: “Agregar una Modalidad”
3. El actor selecciona la opción (A) en la pantalla
LISTAR MODALIDAD.
4. El sistema muestra la pantalla: REGISTRAR
MODALIDAD.
A
B

95
REGISTRAR MODALIDAD
5. El actor ingresa los datos generales de la
modalidad: Código de la Modalidad, Nombre,
Fecha de Creación, Resolución,
Especialización y Abreviatura.
El actor hace clic en Cancelar
REGISTRAR MODALIDAD
7. El actor hace clic en Guardar 8. El sistema muestra la pantalla:

96
REGISTRAR MODALIDAD
Sección: “ Editar la Modalidad Seleccionada ”
9. El actor selecciona la opción (B) en la pantalla
LISTAR MODALIDAD.
10. El sistema muestra la pantalla: MODIFICAR
MODALIDAD.
MODIFICAR MODALIDAD

97
GESTIONAR ALUMNO
Código : CUS-GAL-003
Caso de uso: Gestionar Alumno
Actor(es): - Coordinador.
- Administrador del sistema.
- Alumno
Propósito / Objetivo: Gestionar Alumno tiene como objetivo el registro de alumnos que
conformaran en las distintas menciones.
se dispone a registrar un nuevo alumno, para ello ingresa la información
solicitada por el sistema, como por ejemplo a que modalidad y mención va a
pertenecer el alumno a registrar, documento de identidad, el nombre,
apellido paterno y materno entre otros. El caso de uso termina cuando se ha
registrado al alumno y esta se visualiza en el listado según la modalidad y
mención seleccionada. Si hubo algún error al momento de ingresar la
información para el registro del nuevo alumno, este se puede modificar.
seleccionado el módulo de MANTENIMIENTO.
Requerimientos
Asociados:
CUS-GMO-001; CUS-GME-002
ESPECIFICACIÓN
1. El Administrador o Coordinador selecciona la
opción en el menú/ MANTENIMIENTO ->
GESTIONAR ALUMNO (Pantalla: Selección de
Opción en el Menú)

98
Lista de Alumnos
2. El sistema muestra la pantalla(una vez
seleccionada la modalidad y Mención):
LISTA DE ALUMNOS, con las siguientes
opciones:
- (A) Nuevo Alumno: Ver sección:
Registrar Alumno.
- (B) Modificar Alumno seleccionado: Ver
sección: Editar Alumno Seleccionado
- (C). Búsqueda Avanzada: Ver Sección:
Buscar Por Nombre Y Apellido.
LISTA DE ALUMNOS
Sección: “Registrar Alumno”
3. El actor selecciona la opción (A) en la pantalla
LISTA DE ALUMNOS y se propone a llenar el
formulario, al momento de dar clic en el boton
Guardar falta algunos campos por llenar.
A
B
C

99
REGISTRAR ALUMNO
5. Cuando el actor llena los campos obligatorios
para el sistema, recién se dirá que el alumno
fue registrado correctamente.
Sección: “Editar Alumno Seleccionado”
6. El actor selecciona la opción (B) en la pantalla
LISTA DE ALUMNOS.
7. El sistema muestra la pantalla: MODIFICAR
REGISTROALUMNO.
MODIFICAR REGISTRO ALUMNO
Sección: “Buscar Por Nombre Y Apellido ”
8. El actor selecciona la opción (C) en la pantalla
LISTA DE ALUMNOS.
En el buscador digita el nombre o apellido del
alumno que desea buscar y da clic en el
botón Buscar.

100
Lista de casos de uso del sistema: “Gestionar Plan de Estudio”
CUS-GPE-011 Gestionar Plan de Estudio
LISTA DE ALUMNOS

101
GESTIONAR PLAN DE ESTUDIO
Código : CUS-GPE-011
Caso de uso: Gestionar Plan de Estudio
Actor(es): -Coordinador.
-Administrador del sistema.
Propósito / Objetivo: Gestionar Plan de Estudio tiene como objetivo registrar Planes de Estudio
para las diferentes menciones y así poder asignar los cursos que
anteriormente fueron creados en el módulo de Gestionar Mantenedores a
estos planes que conformaran en los distintos flujos de trabajo.
se dispone a registrar un nuevo plan de estudio y así asignar cursos a éste.
Los usuario podrán cambiar la condición de cada curso de dictado a no
dictado según el periodo que se esté dictando en ese momento. El caso de
uso termina cuando se ha registrado el plan de estudio y este se visualiza
en el listado inicial dependiendo de la modalidad y mención a la que
pertenecen. Si hubo algún error al momento de ingresar la información para
el registro del nuevo plan de estudio, este se puede modificar.
seleccionado el módulo de PLAN DE ESTUDIO.
Requerimientos
Asociados:
CUS-GMO-001; CUS-GME-002; CUS-GCU-006
ESPECIFICACIÓN
1. El Administrador o Coordinador selecciona
la opción en el menú/ PLAN DE ESTUDIO ->
GESTIONAR PLAN DE ESTUDIO (Pantalla:
Selección de Opción en el Menú)

102
Listados de Plan de Estudio
LISTADOS DE PLAN DE ESTUDIO (una
vez seleccionada la modalidad y
mención), con las siguientes opciones:
- (A) Nuevo Plan de Estudio: Ver sección:
Agregar Plan de Estudio.
- (B) Modificar Plan de Estudio: Ver
sección: Editar Plan de Estudio
Seleccionado.
- (C) Ver Cursos: Ver sección: Ver Cursos
del Plan de Estudio Seleccionado
LISTADOS DE PLAN DE ESTUDIO
Sección: “Agregar Plan de Estudio”
3. El actor selecciona la opción (A) en la
pantalla LISTADOS DE PLAN DE
ESTUDIO.
A
B
C

103
REGISTRARPLAN DE ESTUDIO
Sección: “Editar Plan de Estudio Seleccionado”
5. El actor selecciona la opción (B) en la
ESTUDIO y al igual que en los procesos
anteriores este se puede modificar.
Sección: “Ver Cursos del Plan de Estudio Seleccionado”
6. El actor selecciona la opción (C) en la
ESTUDIO
7. El sistema muestra la pantalla con las
siguientes opciones:
- (1) Asignar Cursos: Ver sección: Agregar
Cursos.
- (2) Editar Cursos: Ver sección: Editar
Curso Seleccionado.
- (3) Asignar Requisitos: Ver sección:
Asignar Requisitos al Curso
Seleccionado.

104
LISTADO DE CURSOS
Sección: “Agregar Cursos”
8. El actor selecciona la opción (1) en la
pantalla LISTADO DE CURSOS .
ASIGNAR CURSOS AL PLAN
10. El actor hace clic en el combo de curso
(circulo de la imagen superior) y se desplega
una lista de cursos (dependiendo la
mencion) que se registraron anteriormente
en el modulo de MANTENIMIENTO.
11. El sistema muestra la pantalla
1
3
2

105
Sección: “Editar Curso Seleccionado”
pantalla LISTADO DE CURSOS
LISTADO DE CURSOS
14. Si el actor hace clic en Actualizar se
actualizan los campos editados y si hace
clic en Cancelar no se edita ningun campo
(circulo de la imagen superior).

106
Sección: “Asignar Requisitos al Curso Seleccionado”
pantalla LISTADO DE CURSOS.
Y despliega la lista que solo muestra cursos
de ciclos inferiores del curso seleccionado.
17. Una vez que el actor selecciona el curso
que sera Pre-Requisito para el curso
seleccionado hace clic en el boton Guardar

107
19. El actor hace clic en Aceptar (en el mensaje
de la figura superior).
21. El actor hace clic en ―X‖ (imagen superior
donde se encuentra un circulo) para regresar
al Listado de Cursos.
LISTADO DE CURSOS

108
23. El actor hace clic en el icono de forma de
flecha (imagen inferior) para regresar a la
interfaz principal.
LISTADO DE CURSOS
24. Al hacer clic en el icono de forma de
flecha el sistema muestra la pantalla:
LISTADO DE PLAN DE ESTUDIO

109
Lista de casos de uso del Sistema: “Gestionar carga Académica”
CUS-GCG-012 Gestionar Curso Grupo

110
GESTIONAR CURSO GRUPO
Código : CUS-GCG-012
Caso de uso: Gestionar Curso Grupo
Actor(es): -Coordinador.
-Administrador del sistema.
Propósito / Objetivo: Gestionar Curso Grupo tiene como objetivo asignar un grupo a cada curso
y aquellos cursos que ya tienen un grupo se les asigna al docente con su
respectivo horario.
se dispone a asignar cada curso a un grupo, para que posteriormente ese
mismo curso se le asigne al docente con su respectivo horario que va a ser
el responsable de dictar dicho curso. El caso de uso termina cuando se
asignó el curso al docente. Si hubo algún error al momento de asignar los
horarios al curso, este se puede modificar.
seleccionado el módulo CARGA ACADEMICA.
Requerimientos
Asociados:
CUS-GMO-001; CUS-GME-002; CUS-GPE-011
ESPECIFICACIÓN
1. El Administrador o Coordinador selecciona
la opción en el menú/ CARGA ACADEMICA ->
GESTIONAR CURSO GRUPO (Pantalla:
Selección de Opción en el Menú)

111
Listar Curso Grupo
2. El sistema muestra la pantalla: LISTAR
CURSO GRUPO (una vez seleccionada
la modalidad, mención y Plan de Estudio),
con las siguientes opciones:
- (A) Asignar Grupo: Ver sección: Asignar
Grupo al Curso Seleccionado.
- (B) Asignar Horario: Ver sección: Asignar
Horario al Curso Seleccionado
LISTAR CURSO GRUPO
Sección: “Asignar Grupo al Curso Seleccionado”
3. El actor selecciona la opción (A) en la
pantalla LISTAR CURSO GRUPO
A
B

112
ASIGNAR GRUPO SECCION
5. El actor llena los campos que pide el
sistema y hace clic en el icono Añadir
(imagen en la parte superior en donde se
encuentra un circulo).
ASIGNAR GRUPO SECCION
7. El actor hace clic en el botón Guardar y
seguidamente en aceptar.

Informe Final de la Primera Práctica Pre Profesional I

Informe Final de la Primera Práctica Pre Profesional I

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (14)

Destacado

Destacado (20)

Similar a Informe Final de la Primera Práctica Pre Profesional I

Similar a Informe Final de la Primera Práctica Pre Profesional I (20)

Último

Último (16)

Informe Final de la Primera Práctica Pre Profesional I