UNFV – Dirección General de Bibliotecas

Tesis Digitales
Restricciones de uso

DERECHOS RESERVADOS ©
PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL

Todo el material contenido en esta tesis está protegido por el Decreto

Legislativo Nº 1092 - Aprueba medidas en frontera para la protección de
los Derechos de Autor y Derechos Conexos. Decreto Supremo N° 003-
2009-EF - Reglamento del Decreto Legislativo Nº 1092 que aprueba
medidas en frontera para la protección de los derechos de autor o derechos
conexos y los derechos de marcas.
El uso de imágenes, fragmentos de videos, y demás material que sea objeto de
protección de los derechos de autor, será exclusivamente para fines educativos e
informativos y deberá citar la fuente donde la obtuvo mencionando el autor o
autores. Cualquier uso distinto como el lucro, reproducción, edición o modificación,
será perseguido y sancionado por el respectivo titular de los Derechos de Autor.
 2

I. DATOS DEL ALUMNO

VITTOR HANZ CARRILLO LORENZO
DNI: 72956053
II. UNIVERSIDAD NACIONAL FEDERICO VILLARREAL
FACULTAD; INGENIERIA DE SISTEMAS
III. JURADO ACADEMICO N° 1
DRA. AMPARO LOPEZ GAONA.
IV. JURADO ACADEMICO N° 2
DRA. HANNA OCTAWA GARCIA
V. JURADO ACADEMICO N° 3
GUSTAVO ARTURO MARQUEZ FLORES
VI. JURADO ACADEMICO N° 4
MARIA GUADALUPE ELENE IBANGUERGOITIA GONZALES
VII. DATOS DE LA TESIS
DESARROLLO DE SOFTWARE GUIADO POR LA NORMA ISO/IEC 29110 Y SCRUM: V.2.0
229P
2014
Agradecimientos

Cuando una persona termina un trabajo tan arduo y complicado como lo es el

desarrollo de una tesis, es inevitable que el egocentrismo lo asalte a uno. Sin embar-
go, un análisis poco profundo permite darse cuenta que este logro jamás habría sido
posible sin el aporte y participación de personas e instituciones quienes han facilitado
las cosas para que este trabajo llegue a un feliz término.
Debo comenzar por agradecer a mis padres VICTOR MANUEL CARRILLO ARAGON Y
SHIRLAY LORENZO JUCA, quienes han sabido formarme con buenos sentimientos, hábitos y
valores, lo cual me ha permitido salir adelante en momentos difícilesy quienes también
depositaron toda su confianza en mi’
A mi hermano que siempre ha estado junto a mí, brindándomesu apoyo, muchas veces
poniéndose en el papel de madre.
A mis abuelas, quienes siempre estuvieron al pendiente de mi andar escolar y mismas
que en alguna ocasión me dijeron que la mejor herencia que me podrı́an dejar serı́a
un titulo.
A mis tios quienes han sido unos segundos padres para mi’ y asus primos quienes
me han brindado apoyo y consejo como si fueran mis hermanos.
A mi familia en general, porque me han dado su confianza y han compartido conmigo
buenos y malos momentos.
En especial debo agradecer a mi asesor Miguel Morales, quien desde que me cono-
ció en la clase de Ingeniería de Software depositó en mí su confianza y me apoyó en
todo momento para culminar esta tesis.

3
 4

A cada uno de mis jurados quienes me apoyaron revisando este trabajo y sus co-
mentarios permitieron obtener un mejor producto final.
A David Velázquez quien me dio todas las facilidades para llevar a cabo este proyecto
y por ser no un jefe sino un amigo.
A René Villeda quien fue un gran apoyo durante mi estancia en la Facultad y de
quien aprendı́ muchas cosas para el mundo laboral y algunas más para la vida.
A la UNFV que me permitió llevar a cabo mis estudios superiores y me permitió co-
nocer y convivir con excelentes personas durante los 5 años de estudios.
A todos los amigos que conocı́ durante mis clases en la Facultad, porque estuvieron
en las buenas y en las malas, porque incluso parte de esta tesis es gracias a su apoyo,
Y a cada una de las personas con las que me he cruzado durante mis diferentes etapas
escolares, cada una influyó con sus lecciones y experiencias en formarme como una
persona de bien y preparada para los retos que pone la vida, a todos y cada uno de
ellos les dedico cada una de estas páginas.

¿Saben cuál es el problema?

Mujeres,alcohol...me ven a mı́ y creen que es fácil, pero no saben todos los años de
trabajo duro y dedicación que me permiten ser como soy.
Charlie Harper
Í́NDICE GENERAL

AGRADECIMIENTOS 3

1. INTRODUCCIÓN 11

2. CONCEPTOS BÁSICOS 13
2.1. Ingenier´ıa de Software .. . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Metodologı́as para el desarrollo de software . . . . . . . . . . . . . . . 16
2.3. Bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3. EL PROCESO UNIFICADO 24
3.1. Lenguaje de Modelado Unificado (UML) . . . . . . . . . . . . . . . . 24
3.2. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3. Etapas del desarrollo del Proceso Unificado . . . . . . . . . . . . . . . 29
3.4. ISO/IEC 29110 y Proceso Unificado . . . . . . . . . . . . . . . . . . . 31

4. PLANTEAMIENTO DEL PROBLEMA 36

4.1. Sidep v.1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2. Análisis a Sidep v.1.0. . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3. Conclusión del análisis a Sidep.v.1.0 . . . . . . . . . . . . . . . . . . . 42

5. PLANEACIÓN DEL PROYECTO 44

5.1. AP.1.1 Revisar el Enunciado de trabajo. . . . . . . . . . . . . . . . . . 47
5.2. AP.1.2 Definir con el cliente las Instrucciones de entrega para cada
uno de los entregables especificados en el Enunciado de trabajo . . . . 47

5
I´ndice general 6

5.3. AP.1.3 Identificar las tareas especı́ficas a realizar para producir los
entregables y sus componentes .................................................................... 51
5.4. AP.1.4 Establecer la Duración estimada para realizar cada tarea. ........... 60
5.5. AP.1.5 Identificar y documentar los recursos requeridos para el desa-
rrollo del proyecto. ....................................................................................... 64
5.6. AP.1.6 Establecer la Estructura del Equipo de Trabajo ............................. 67
5.7. AP.1.7 Asignar la estimacion inicial y las fechas determinadas para
cada tarea. .................................................................................................... 68
5.8. AP.1.8 Calcular y Documentar la Estimación del Esfuerzo y Costo ........ 72
5.9. AP.1.9 Identificar y documentar los riesgos que pueden afectar al pro-
yecto. ............................................................................................................ 73
5.10. AP.1.10 Documentar la Estrategia de Control de Versiones ..................... 75
5.11. AP.1.11 Generar el Plan del Proyecto integrando los elementos pre-
viamente identificados y documentados. ..................................................... 77
5.12. AP.1.12 Incluir la descripción del producto. .............................................. 77
5.13. AP.1.13 Verificación del proyecto / AP.1.14 Revisar y obtener la apro-
bación del Plan del Proyecto ...................................................................... 79
5.14. AP.1.15 Establecer el repositorio del proyecto usando la Estrategia de
Control de Versiones .................................................................................... 80

6. INICIO DE LA IMPLEMENTACIÓN DE SOFTWARE 82

6.1. I.S.1.1 Revisar el Plan del Proyecto / I.S.1.2 Establecer el ambiente
de implementacion. ...................................................................................... 83

7. ANÁLISIS DE REQUERIMIENTOS DE SOFTWARE. 87

7.1. I.S.2.1 Asignar tareas a los miembros del Equipo de Trabajo de acuer-
do a cada rol, basadas en el Plan del Proyecto actual. .............................. 88
7.2. I.S.2.2 Documentar o actualizar la Especificación de Requerimientos. ..... 88
7.3. I.S.2.3 Verificar la Especificación de Requerimientos y proponer una
Solicitud de Cambio. .................................................................................. 100
7.4. I.S.2.4 Validar y obtener la aprobación de la Especificación de Reque-
rimientos............................................................................................. 103
I´ndice general 7
7.5. I.S.2.5 Documentar la versión preliminar del Manual de Usuario o
actualizar la versión existente. .................................................................. 103
7.6. I.S.2.6 Verificar y obtener la aprobacion del Manual de Usuario. ........... 105
7.7. I.S.2.7 Preliminar de Manual de Usuario verificado ................................. 105

8. ARQUITECTURA Y DISEÑO DETALLADO DEL SOFTWARE. 107

8.1. I.S.3.1. Asignar tareas a los miembros del Equipo de Trabajo de acuer-
do a su rol para el Plan del Proyecto Actual ............................................ 108
8.2. I.S.3.2. Comprender la Especificación de Requerimientos. ...................... 108
8.3. I.S.3.3 Documentar o actualizar el Diseño de Software ........................... 110
8.4. I.S.3.4 Verificar y obtener la aprobación del Diseño de Software ........... 129
8.5. I.S.3.5 Establecer los Casos y Procedimientos de Prueba para pruebas
de integración basados en la Especificación de Requerimientos y el
Diseño de Software .................................................................................... 129
8.6. I.S.3.6 Verificar y obtener la aprobacion de los Casos y Procedimientos
de Prueba.................................................................................................... 133
8.7. I.S. 3.7 Actualizar el Registro de Rastreo / I.S.3.8 Incorporar el Diseño
de Software ................................................................................................. 133

9. CONSTRUCCIÓN DEL SOFTWARE 134

9.1. I.S.4.1 Asignar tareas a los miembros del Equipo de Trabajo de acuer-
do al Plan del Proyecto Actual .................................................................. 134
9.2. I.S.4.2 Entender el Diseño de Software .................................................... 135
9.3. I.S.4.3 Construir los Componentes de Software basados en la parte
detallada del Diseño de Software ............................................................. 135
9.4. I.S.4.4 Diseñar o actualizar los casos de pruebas unitarias y aplicarlos
para verificar que los Componentes de Software implementan la parte
detallada del Diseño de Software ............................................................. 136
9.5. I.S.4.5 Corregir los defectos encontrados hasta lograr una prueba exitosa.137
9.6. I.S.4.6 Actualizar el Registro de Rastreo incorporando Componentes
de Software construidos o modificados. .................................................... 137
9.7. I.S.4.7 Incorporar Componentes de Software y Registro de Rastreo ........ 139
I´ndice general 8
10. INTEGRACIÓN Y PRUEBAS DEL SOFTWARE 140
10.1. I.S.5.1 Asignar tareas a los miembros del Equipo de Trabajo. ................ 141
10.2. I.S.5.2 Entender los Casos y Procedimientos de Prueba .......................... 141
10.3. I.S.5.3 Integrar el Software usando los Casos y Procedimientos de
Prueba para las pruebas de integración. .................................................. 142
10.4. I.S.5.4 Realizar pruebas de Software usando Casos y Procedimientos
de Prueba.................................................................................................... 143
10.5. I.S.5.5 Corregir los defectos encontrados. ................................................. 146
10.6. I.S.5.6 Actualizar el Registro de Rastreo en caso de ser necesario. .......... 146
10.7. I.S.5.7 Documentar el Manual de Operación o actualizar el manual
actual, en caso de ser apropiado................................................................ 146
10.8. I.S.5.8 Verificar y obtener la aprobación del Manual de Operación, en
caso de ser necesario. Verificar la consistencia del Manual de Operación
con el Software ........................................................................................... 148
10.9. I.S.5.9 Documentar el Manual de Usuario o actualizar el actual. ........... 148
10.10.I.S.5.10 Verificar y obtener la aprobación del Manual de Usuario .......... 149
10.11.I.S.5.11 Incorporar los Casos y Procedimientos de Prueba, Reporte de
Pruebas, Manual de Operación y Manual de Usuario como parte de
la l´ınea base. .............................................................................................. 149

11. ENTREGA DE PRODUCTOS 150

11.1. I.S.6.1 Asignar tareas a los miembros del equipo de trabajo. .................. 150
11.2. I.S.6.2 Comprender la Configuración de Software ................................... 151
11.3. I.S.6.3 Documentar el Manual de Mantenimiento .................................... 151
11.4. I.S.6.4 Verificar y obtener la aprobación del Manual de Mantenimiento.152
11.5. I.S.6.5 Incorporar el Manual de Mantenimiento a la l´ınea base de la
Configuración de Software ........................................................................ 152
11.6. I.S.6.6 Llevar a cabo la entrega de acuerdo a las Instrucciones de Entrega.152

12. EJECUCIÓN DEL PLAN DE PROYECTO 156

12.1. A.P.2.1 Monitorear la ejecución del Plan del Proyecto y registrar la
información actual en el Reporte de Avance. .......................................... 156
I´ndice general 9
12.2. A.P.2.2 Analizar y evaluar el impacto en costo, tiempo e impacto
técnico de la Solicitud de Cambio ............................................................. 157
12.3. A.P.2.3 Conducir reuniones de revisión con el Equipo de Trabajo. ........ 158
12.4. A.P.2.4 Realizar reuniones con el Cliente. ................................................ 158
12.5. A.P.2.5 Realizar el Respaldo del Repositorio del Proyecto de acuerdo
a la Estrategia de Control de Versiones. ................................................... 160
12.6. A.P.2.6 Realizar la recuperación del Repositorio del Proyecto utilizan-
do el Respaldo del Repositorio del Proyecto. ............................................ 160

13. EVALUACIÓN Y CONTROL DEL PROYECTO 162

13.1. A.P.3.1 Evaluar el progreso del proyecto con respecto al Plan del Pro-
yecto. .......................................................................................................... 162
13.2. A.P.3.2 Establecer acciones para corregir desviaciones o problemas e
identificar riesgos que amenacen el cumplimiento del plan...................... 163
13.3. A.P.3.3 Identificar cambios a requerimientos y/o al Plan del Proyecto. 164

14. CIERRE DEL PROYECTO 165

14.1. A.P.4.1 Formalizar la conclusión del proyecto de acuerdo a las Ins-
trucciones de entrega establecidas en el Plan del Proyecto ..................... 165
14.2. A.P.4.2 Actualizar el Repositorio del Proyecto ......................................... 166

15. RESULTADOS 167

16. CONCLUSIONES 170

A. ADMINISTRACIÓN DEL PROYECTO 171

B. IMPLEMENTACIÓN DEL SOFTWARE 178

C. INFORME DEL ESTADO DE CONFIGURACIÓN 191

C.1. Documento de Aceptación. ....................................................................... 199
C.2. Solicitud de Cambio. .................................................................................. 199
C.3. Registro de Defectos. ................................................................................. 200
C.4. Manual de Mantenimiento. ........................................................................ 200
C.5. Minuta. ........................................................................................................ 201
I´ndice general 10
C.6. Manual de Operación. ............................................................................... 201
C.7. Reporte de Avance. ..................................................................................... 202
C.8. Plan del Proyecto. ...................................................................................... 203
C.9. Repositorio del Proyecto. ............................................................................ 205
C.10.Respaldo del Repositorio del Proyecto. ...................................................... 216
C.11.Especificación de Requerimientos. ............................................................ 216
C.12.Software. ..................................................................................................... 218
C.13.Componente de Software. .......................................................................... 218
C.14.Configuración de Software. ....................................................................... 218
C.15.Diseño de Software. ................................................................................... 219
C.16.Manual de Usuario. ..................................................................................... 220
C.17.Enunciado de Trabajo. ............................................................................... 221
C.18.Casos y Procedimientos de Prueba. ............................................................ 222
C.19.Reporte de Pruebas. ................................................................................... 222
C.20.Rastreo. ....................................................................................................... 223
C.21.Listas de Verificación. ............................................................................... 224
C.22.Listas de Validación .................................................................................. 224

BIBLIOGRAFÍA 228
CAPÍTULO 1

Introducción

La Division de Estudios de Posgrado de la Facultad de Medicina es el área en-

cargada de administrar las Especialidades Médicas y Altas Especialidades Médicas
que forman parte de su plan de estudios. Esta división depende de la Facultad de
Medicina de la Universidad Nacional Federico Villarreal
Actualmente la División cuenta con un sistema de administración especı́fico para los
cursos de Especialidad y Alta Especialidad Médica. Este sistema es conocido como
Sidep v.1.0 y ha sido utilizado por 4 años.
Sidep v.1.0 ha presentado diversos fallos desde su liberación, los más evidentes son
los relacionados a la integridad y consistencia de datos. Estos fallos han causado distintos
inconvenientes entre sus usuarios y administradores, tales como pérdida de
información de profesores en sedes y cursos para un ciclo escolar especı́fico, recaptura
de información que el sistema no almacenó y la necesidad de manipular directamente
la base de datos utilizando sentencias SQL.
Bajo este contexto, el alcance del presente trabajo es analizar los fallos que presenta
Sidep v.1.0 y proponer una solución a éstos, ya sea a través de una actualización
del sistema o bien mediante la creación de un sistema nuevo. El proceso para llevar
a cabo este proyecto se guiará por metodologı́as ágiles y tradicionales, basándose
principalmente en SCRUM y la Norma ISO/IEC 29110 para cada una de las me-
todologı́as correspondientes, generando ası́ un proceso de desarrollo de software que
involucre prácticas de ambos tipos de metodologı́as y permita generar una solución
que atienda las necesidades presentes en la División.

11
Capı́tulo 1. Introducción 12

Este trabajo se organiza de la siguiente manera, en el cap´ıtulo 2 se presentan los

conceptos básicos en los que se fundamenta este proyecto. El capı́tulo 3 presenta el
marco de trabajo utilizado como base para la realización de Sidep v.2.0, en este caso
el Proceso Unificado. El planteamiento del problema se detalla en el cap´ıtulo 4. Pos-
teriormente, se describen las actividades planteadas para dar solución al problema
planteado. Dichas actividades se agruparon en dos procesos: el primero de ellos agru- pa
los capı́tulos 5, 12, 13 y 14 y presenta las actividades relativas a la administración del
proyecto. Mientras que el segundo proceso, referente a la implementación del
sistema, está compuesto por los capı́tulos 6, 7, 8, 9, 10 y 11. Finalmente el capı́tulo
15 presenta los resultados obtenidos y las conclusiones.
CAPÍTULO 2

Conceptos Básicos

Los sistemas de consulta de información han cobrado gran importancia a lo largo

de los años. El beneficio de automatizar el manejo de los datos para desde una pan-
talla realizar inserciones, actualizaciones, borrados y consultas se ha extendido a tal
grado de que el d´ıa de hoy las empresas dependen de ellos para poder llevar a cabo
su trabajo de manera eficiente.
A pesar de ello, la existencia de un sistema para el manejo de la información, no ase-
gura que se tenga un manejo adecuado de ésta. Más aún, es recurrente el encontrarse
con sistemas no documentados, lo que los vuelve poco mantenibles y les augura poca
vida en operación. Además, se puede agregar a esta problemática el hecho de que los
sistemas tengan problemas de diseño, consistencia e integridad de datos.
El fin de documentar un sistema, como lo veremos más adelante, es dejar una refe-
rencia de éste respondiendo a preguntas como:

• ¿Para qué se necesita?.

• ¿Cuáles son las funciones que están implementadas?.

• ¿Por qué se implementó de esa manera?.

El objetivo principal de documentar un sistema será crear una guı́a para enten-
derlo, poder corregir fallas y añadir módulos. Además sirve como una referencia para
el futuro encargado del mantenimiento del sistema ya que le permitirá entender la
forma en que trabaja el mismo.

13
Capı́tulo 2. Conceptos Básicos 14

Si bien es cierto que incluso un sistema bien documentado puede no ser correc- to,
será más simple llevarlo a este punto realizando las modificaciones pertinentes as´ı
como registrando cada uno de los cambios que se lleven a cabo.
Construir, operar, mantener y documentar un sistema de software son algunas de las
actividades realizadas por una disciplina en particular, la Ingenier´ıa de Software. En
la siguiente sección se profundizará sobre esta disciplina.

2.1. INGENIERÍA DE SOFTWARE

Tomando en cuenta las siguientes definiciones de Ingenier´ıa de Software:

• La ingenier´ıa de software es la rama de la ingenier´ıa que aplica principios de

las ciencias de la computación y matemáticas para lograr soluciones rentables
a los problemas de software [9].
• Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desa-
rrollo, operación y mantenimiento de software [12].
• La Ingenier´ıa de Software es la disciplina de la ingenier´ıa que estudia la na-
turaleza, los enfoques y metodologı́as de desarrollo a gran escala del software.
Además de las teorı́as y leyes detrás de las prácticas ingenieriles y el compor-
tamiento del software [14].

Podemos construir nuestra propia definición:

• Llamaremos Ingenierı́a de Software a aquel proceso que involucra métodos,

herramientas y técnias que nos guiarán en el proceso de desarrollo de software
y que tiene como fin la construcción de software correcto.

De manera genérica, todo proceso de Ingenierı́a de Software involucra las siguien-

tes etapas de desarrollo:

• Análisis de requerimientos.
La captura, análisis y especificación de requerimientos es la primer etapa para
la creación de software, se conocen los requerimientos que debe cumplir el
sistema a través de la retroalimentación de parte del cliente y el conocimiento
de las reglas de negocio.
Capı́tulo 2. Conceptos Básicos 15

• Diseño.
Tras pasar el análisis, en esta etapa se proponen los módulos a desarrollar
y se deberán detallar cada uno de ellos. Es en esta fase cuando se definen
aspectos como la arquitectura del sistema, la forma en que se desarrollarán
las aplicaciones, el diseño de la base de datos y aquellas herramientas que se
utilizarán para el desasarrollo, pruebas y liberación.

• Construcción.
Se resume esta etapa en una palabra: codificación, se procede a codificar cada
uno de los módulos planteados en la etapa de diseño, respetando estándares de
codificación y de nombrado. Dentro de esta etapa, el equipo de desarrollo de-
berá probar cada uno de los componentes que conforman el sistema, realizando
pruebas de caja negra y caja blanca.

• Integración.
En esta fase se unen los módulos creados en la etapa de construcción de acuerdo
a las especificaciones obtenidas en la etapa de diseño, en cada integración de
módulos se comienza en parte con la etapa de pruebas, ya que cada integración
conlleva la necesidad de comprobar que en conjunto los módulos funcionan
correctamente.

• Pruebas.
Las pruebas pueden dividirse en dos partes, primeramente el equipo de desarro-
llo deberá verificar que las funcionalidades implementadas trabajan de manera
correcta. Posteriormente, al haberse asegurado del buen funcionamiento del
sistema, se deberán realizar pruebas con usuarios finales del sistema para vali-
dar que éste cumple con los requerimientos que inicialmente se establecieron.
Durante esta fase se recabarán sus comentarios sobre lo que se debe mejorar y
las fallas que se detectaron en el uso del sistema.

• Liberación.
Al concluir la fase de pruebas, el sistema se encuentra listo para su uso. Es
por ello que se entrega junto con la documentación al cliente, misma que ser-
virá de referencia para los usuarios y el equipo encargado de su administración,
operación y mantenimiento.
Capı́tulo 2. Conceptos Básicos 16

2.2. METODOLOGÍAS PARA EL DESARROLLO DE

SOFTWARE
¿Qué es una metodologı́a para el desarrollo de software? Una metodologı́a de
software es un marco de trabajo usado para estructurar, planificar y controlar el proceso
de desarrollo en sistemas de información [10]. Existen varias metodologı́as para el
desarrollo de software, entre ellas podemos destacar:

• Proceso Unificado.
Es un proceso modular o basado en componentes, esto es, la construcción
depende de módulos los cuales se encuentran conectados por interfaces bien
definidas.
Guiado por casos de uso que son documentos que permiten capturar requeri-
mientos funcionales y en los cuales profundizaremos en el cap´ıtulo 3, centrado en
la arquitectura al considerar que afecta al funcionamiento del sistema por factores
como son la plataforma, los componentes reutilizables y los requeri- mientos no
funcionales [8] e interactivo e incremental que permite identificar y especificar los
casos de uso a realizar para poder generar un producto funcional en cada entrega
para ir anexándole funcionalidades en incrementos de manera gradual.
Es la metologı́a que se aplicará durante el desarrollo de este trabajo y se ex-
plicará a detalle en el capı́tulo 3.
• Personal Software Process.
En esta metodologı́a, el programador deberá realizar las tareas definidas en
documentos conocidos como scripts. Estos scripts no sólo definen las tareas a
realizar sino que deben respetarse de manera disciplinada.
Los productos generados de estos scripts generarán una estadı́stica, la cual el
desarrollador de software tomará en cuenta para identificar fortalezas y debi-
lidades de su desarrollo lo que le permitirá realizar un autoanálisis que más
adelante lo llevará a realizar un proceso de autoaprendizaje [5].
• ISO/IEC 29110.
Es un estándar internacional que se ha desarrollado para entidades muy pe-
queñas (VSE - Very Small Entities) encargadas de construir software. Una VSE
se define como una entidad que tiene menos de 25 personas. Esta norma ISO,
Capı́tulo 2. Conceptos Básicos 17

se divide en dos partes:

ø Implementación del Software.

Describe conceptos de procesos, ciclo de vida y estandarización para la
construcción del software.
ø Administración del proyecto.
Describe el desarrollo de software de una sola aplicación por un solo equipo
de proyecto sin riesgos o factores situacionales especiales [7].

• KANBAN.
El sistema Kanban para el software, derivado del Sistema de Producción de
Toyota (TPS), en un enfoque sin iteraciones para organizar el trabajo. En vez de
usar iteraciones de tiempo fijo y reuniones de planificación, el equipo de
desarrollo toma tareas sólo cuando completó su trabajo anterior.
Ligado al uso de de un planeador estructurado por columnas, identifica cada
uno de los estados por los que una tarea puede pasar:

ø Solicitada.
ø Asignada.
ø En desarrollo.
ø En pruebas.
ø Completada.

Además se incluye la medición del tiempo invertido en cada tarea de la siguiente

manera:

ø Fecha y hora de inicio.

ø Fecha y hora de fin.
ø Tiempo real invertido.

Un aspecto fundamental de esta metodologı́a es mantener acotada una tarea

bajo los siguientes dos conceptos:

ø No podemos comenzar una nueva tarea hasta que se haya terminado la

anterior.
Capı́tulo 2. Conceptos Básicos 18

ø El número máximo de trabajo en curso tiene un lı́mite, que es nuestra

capacidad por ciclo o iteración [1].

• SCRUM.
Proceso iterativo e incremental, definido por un conjunto de prácticas y roles
que sirven como base para la planeación del desarrollo del proyecto.
Los roles principales son:

ø Product Owner.
Representa la voz del cliente. Se asegura de que el equipo Scrum trabaje
de forma adecuada desde la perspectiva del negocio.
ø Scrum Master.
Su trabajo primario es eliminar los obstáculos que impiden que el equipo
alcance el objetivo del sprint. El ScrumMaster no es el l´ıder del equipo
(ya que es auto-organizado), sino que actúa como una protección entre el
equipo y cualquier influencia que le distraiga.
ø Stakeholders.
Será la gente que hace posible el proyecto y para quienes el proyecto pro-
ducirá el beneficio acordado que justifica su producción. Sólo participan
directamente durante las revisiones del sprint.
ø Team.
Tiene la responsabilidad de entregar el producto, integrado por 3 a 9
personas con las habilidades para realizar el trabajo (anlisis, diseño, desa-
rrollo, pruebas, documentación, etc).

La manera de trabajar en esta metodologı́a es mediante periodos de tiempo

conocidos como Sprints, tras cada uno de estos periodos el equipo de desarrollo
entrega un producto funcional. Las caracter´ısticas que debe cumplir el entre-
gable se encuentran detalladas en un documento nombrado: Product Backlog,
dicho documento es elaborado durante la reunión de Sprint Planning en la
cual el Product Owner identifica todos los elementos del Product Backlog y se
lo extiende a los miembros del equipo, además existen reuniones diarias Daily
Scrum o Stand-up meeting en las cuales los integrantes del equipo de desarrollo
Capı́tulo 2. Conceptos Básicos 19

hacen del conocimiento del Scrum Master los problemas encontrados o bien
los avances que se van dando en el desarrollo del proyecto, se deben responder
3 preguntas especı́ficas:

ø ¿Qué has hecho desde ayer?.

ø ¿Qué es lo que harás hasta la reunión de mañana?.
ø ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?.

Otra situaciones a considerar para cada una de las Daily Scrum o Stand-up meeting
son:

ø La reunión comienza puntualmente. Se acuerdan multas para quien llegue

tarde.
ø Duración de la reunión de sólo 15 minutos.
ø La reunion debe ocurrir en la misma ubicación y a la misma
hora todos los dı́as.

Además del Daily Scrum, esta metodologı́a define algunas otras reuniones con
distintos objetivos. A continuación se describen brevemente:

ø Scrum de Scrums.
Todos los d´ıas tras la Daily Scrum o Stand-up meeting se reunen una persona
por equipo de trabajo, la reunión se hace en base a las mismas preguntas
que los Daily Scrum o Stand-up meeting además de las siguien- tes 4
preguntas:

⬦ ¿Qué ha hecho tu equipo desde nuestra última reunión?.

⬦ ¿Qué hará tu equipo antes que nos volvamos a reunir?.
⬦ ¿Hay algo que demora o interfiere a tu equipo?.
⬦ ¿Estás a punto de poner algo en el camino del otro equipo?.

ø Sprint Planning Meeting.

Se realizan cada cierto periodo de tiempo definido al inicio del proyecto,
normalmente 2 o 4 semanas, se definen las tareas por hacer identificando
que tareas son posibles de realizar durante la duración del sprint, se detalla
Capı́tulo 2. Conceptos Básicos 20

con el equipo responsable de la tarea el Sprint Backlog en donde se indica

el tiempo que tomará realizar la tarea.
ø Sprint Review Meeting.
Reunión en donde se revisan las tareas completadas y las no completadas,
se presentan los avances funcionales a los Stakeholders.
ø Sprint Retrospective. Los integrantes del equipo de desarrollo realizan una
sesión de intercambio de impresiones sobre el sprint que ha pasado, la idea
es aprender y mejorar en el proceso de desarrollo [11].

En las metodologı́as ágiles, como SCRUM, no se manejan Casos de Uso, el

detalle de las funcionalidades del sistema se hace mediante Historias de Usuario.
De acuerdo con Mike Cohn [2] las Historias de Usuario tienen las siguientes
caracter´ısticas:

ø Independecia.
Las Historias de Usuario deben ser independientes, esto es, deben detallar
una sola funcionalidad del sistema.
ø Negociables.
Las Historias de Usuario son detalles de funcionalidades explicadas en pa-
labras del Usuario, dado que se detallan en lenguage común no se pueden
considerar tan importantes como un contrato, por lo mismo el Equipo de
Desarrollo debe sostener discusiones con el Usuario con el fin de estable-
cer el alcance de la función y se debe dejar de manera explı́cita para la
posterior prueba de validación de la función por parte del Usuario.
ø Valor del Cliente y Usuario.
Los intereses tanto del Cliente como del Usuario tienden a ser siempre
diferentes, por lo cual la Historia de Usuario debe ser importante para
ambos más que para el Equipo de Desarrollo.
ø Estimables.
Tras la definición de la Historia de Usuario por parte de los Clientes
y Usuarios ésta debe ponerse a discusión con el Equipo de Desarrollo
para poder despejar dudas sobre los requerimientos funcionales lo que
permitirá estimar el tiempo total de desarrollo.
Capı́tulo 2. Conceptos Básicos 21

ø Cortas.
Las Historias de Usuario grandes o que abarcan muchas funcionalidades
son difı́ciles de estimar, por lo mismo se pide que cada función del sistema
quede detallada siempre en una Historia de Usuario, as´ı se permite un
desarrollo iterativo-incremental que es más fácil de estimar.
ø Verificables.
Dado que cada Historia de Usuario representa una funcionalidad del sis-
tema generalmente implica que ésta se puede verificar en cada entrega
del sistema, la forma de verficación o validación por parte del usuario se
establece durante las discusiones en que se esclarecen dudas y se estiman
costos.

El manejar la especificación de requerimientos mediante Historias de Usuario

colleva las siguientes ventajas:

ø Al pedir que las realicen los Usuarios, el detalle se describe en lengua casual
por lo que permiten un mejor entendimiento de las funcionalidades
requeridas.
ø Al ser cortas y representar en la mayor´ıa de los casos una sola funcionali-
dad, la implementación se lleva a cabo de manera rápida (dı́as o semanas).
ø Permiten involucrar al Cliente en el desarrollo, manteniendo una relación
cercana con éste.
ø Se puede estimar el esfuerzo requerido de manera simple.

Como principales desventajas, podemos mencionar las siguientes:

ø Al no tener Pruebas de Validación de tipo Caja Negra y Caja Blanca, se

podrı́an fugar errores en la programación y funcionalidad del sistema.
ø Se requiere contacto directo e involucramiento del Cliente y Usuarios en
el desarrollo del proyecto, lo que puede resultar muy complicado.
ø Al ser las Historias de Usuario escritas por los Usuarios, se debe ser muy
cuidadoso con los alcances y estimaciones de esfuerzo del proyecto, ya
que para poder utilizarlas como base de un contrato éstas pueden quedar
abiertas a distintas interpretaciones.
 Capı́tulo 2. Conceptos Básicos 22

2.3. BASES DE DATOS

El d´ıa de hoy las bases de datos se han vuelto una herramienta muy importante,
no sólo por el hecho de permitir el almacenamiento de grandes cantidades de datos,
sino también por que facilitan la obtención de información para la toma de decisiones.
Diremos que una base de datos es un conjunto de datos los cuales mantienen una
relación entre si al pertenecer a un mismo contexto, estos datos son administrados a
través de un Sistema Manejador de Bases de Datos (DBMS por sus siglas en inglés).
Al ser ésta el “almacén” de los datos del sistema, se convierte en el cimiento del
mismo. Es por ello que se debe contar con un buen diseño de la misma para que
sobre ésta se construyan los módulos del software.

• Existen varios tipos de bases de datos, entre los que podemos destacar:

ø Estáticas.
Son bases de datos que se utilizan sólo para lectura, conocidas como “Data
warehouse” o cubos de datos, su función principal es ser la fuente de datos
para la generación de reportes, toma de decisiones, análisis empresariales
y mineria de datos (extracción de conocimiento) [13].
ø Dinámicas.
Son la mayor´ıa de las bases que existen en la actualidad, permiten la
modificación de datos mediante inserciones, actualizaciones y borrados
además de consulta de datos [13].

• Modelos de bases de datos Entre los modelos de bases de datos podemos des-
tacar:

ø Bases de datos jerárquicas.

La estructura de estas bases de datos consiste de un nodo padre el cual
puede tener varios hijos. Optimizadas por ´ındices, este modelo es eficien-
te para el manejo de grandes cantidades de datos, en su contra está la
limitación para eficientar la redundancia de datos [13].
ø Bases de datos transaccionales.
Permiten la consulta y modificacin de datos a gran velocidad, al ser
Capı́tulo 2. Conceptos Básicos 23

transaccionales sus operaciones son atomicas; para comprender más es-

te concepto el ejemplo común es realizar un traspaso de la cuenta A a la
cuenta B, se realizan dos operaciones una que decrementará el saldo en A
y otra que incrementará el saldo en B, de esta manera o bien se llevan a
cabo ambas operaciones o no se lleva a cabo ninguna [13].
ø Bases de datos relacionales.
Los datos son almacenados en entidades las cuales se encuentran relacio-
nadas, las entidades se encuentran compuestas de atributos y almacenan
tuplas las cuales contienen los datos que estamos almacenando. Para ma-
nipular la información se cuenta con un lenguaje formal llamado álgebra
relacional que sienta las bases para construir las consultas las cuales se
realizan en lenguaje estructurado de consultas (SQL por sus siglas en
inglés). Durante el diseño de la base en este modelo se pasa por varias fa-
ses, como son: creación de diagramas entidad-relación, normalización de
relaciones y creacion de diagramas de clases UML [13].

Para este proyecto se ha elegido utilizar una base de datos relacional debido a
la necesidad de representar entidades con múltiples caracterı́sticas. Estas enti-
dades se encuentran relacionadas entre sı́, además de la facilidad para modelar
los supuestos que se obtienen tras el análisis de la lógica que deberá llevar el
sistema.
CAPÍTULO 3

EL PROCESO UNIFICADO

Esta metodologı́a se encuentra dirigida por casos de uso, es iterativa e incre-

mental. Denominado también Proceso Unificado de Rational (RUP por sus siglas
en inglés), desarrollado por la empresa “Rational Software” propiedad de IBM [6] y
siendo “El proceso unificado” es la versión genérica y de dominio público de la meto-
dolog´ıa. Es un proceso basado en componentes, esto es, el software que se encuentra
en construcción está formado por componentes los cuales se encuentran interconec-
tados por intefaces bien definidas, utiliza lenguaje unificado de modelado (UML por
sus siglas en inglés) para detallar todos los esquemas del software a desarrollar.

3.1. Lenguaje de Modelado Unificado (UML)

Es un lenguaje de modelado de sistemas orientado a objetos que permite espe-
cificar, construir, visualizar y documentar los módulos de un software, creado por
Grady Booch y Jim Rumbaugh en 1995 [8]. Se centra en la descripción de méto-
dos y procesos con lo cual permite definir de igual manera las intereacciones que se
llevan a cabo de parte de los programadores y los usuarios con el software que se
está desarrollando, esto se hace a través de diferentes tipos de diagramas:

• De Estructura.

ø Diagrama de clases.
Representan elementos que son estáticos como lo son clases(entidades),

24
Cap´ıtulo 3. El Proceso Unificado 25

las cuales representan un conjunto de objetos que mantienen una estruc-

tura, comportamiento y relaciones con mismas caracter´ısticas; sus con-
tenidos(atributos), los cuales representan las propiedades de un objeto
perteneciente a una clase y las relaciones las cuales se obtienen de la
interacción que existe entre clases.
ø Diagrama de objetos.
Se muestran instancias especı́ficas de clases (objetos) en un momento par-
ticular del sistema. Los diagramas de objetos utilizan un subconjunto de
los elementos de un diagrama de clase.
ø Diagrama de componentes.
Representa cómo un sistema de software es dividido en componentes y
muestra las dependencias entre ellos.
ø Diagrama de paquetes.
Muestra cómo un sistema está dividido en agrupaciones lógicas mostrando
las dependencias entre esas agrupaciones.

• De Comportamiento.

ø Diagrama de estado.
Representan la secuencia de estados por los que un objeto o interacción
pasa durante su ciclo de vida identificando las transiciones que se llevan
a cabo para pasar de un estado a otro.
ø Casos de uso.
Ilustran los requerimientos del sistema, muestran la manera en que reac-
ciona el sistema a eventos que ocurren en el mismo, la relación que existe
entre caso de uso y actor pueden ser:
⬦ Un actor se comunica con un caso de uso.
⬦ Un caso de uso extiende a otro caso de uso.
⬦ Un caso de uso utiliza otro caso de uso.

• De Interacción.

ø Diagrama de secuencia.
Representa el perı́odo durante el que un objeto está desarrollando una
Cap´ıtulo 3. El Proceso Unificado 26

acción directamente o bien a traveés de un método o función, estos objetos

pueden ser creados durante la interacción o bien destruidos en la misma.
ø Diagrama de colaboración.
Muestra interacciones organizadas alrededor de los roles.

3.2. Casos de Uso

Como ya hemos mencionado, los casos de uso regirán la manera en que se desa-
rrollará el software, por esto se vuelven muy importantes para un correcto desarrollo
en busca de un mejor producto. En ellos se especifican los requisitos, condiciones
y caracterı́sticas funcionales que debe cubrir el sistema. Se deberá crear un forma-
to estándar bajo el cual se harán los casos de uso, éste básicamente deberá estar
compuesto por:

• Un identificador único para cada caso de uso.

• Un nombre representativo a la acción que describirá el documento.
• Un fragmento de la funcionalidad del caso de uso descrito.
• Especificar los actores que pueden llevar a cabo dicho caso de uso.
• Se deberán representar los requisitos funcionales del fragmento seleccionado a
manera de precondiciones as´ı como las dependencias de otros casos de uso en
caso de existir.
• Todos los casos de uso juntos describen la funcionalidad completa del sistema.

Tras esto podemos decir que los casos de uso no sólo especificarán los requisi-
tos detallados del sistema, sino que estos nos guiarán en el proceso de desarrollo
de software. Un modelo de casos de uso estará compuesto por: actores, casos de
uso,instancias de caso de uso y relaciones entre estos.

• Actor.
Será todo aquel ente que intereactúe con el sistema (usuarios, clientes, adminis-
tradores, otros sistemas, dispositivos), cada uno de ellos será representado como
un actor; un actor será entonces un tercero externo al sistema que interactúa
con él.
Cap´ıtulo 3. El Proceso Unificado 27

Figura 3.1: Representación de un actor en UML.

• Narrativa.
Cada caracter´ıstica o funcionalidad que los usuarios requieran del sistema será
representada como un caso de uso. Un caso de uso detalla detalla ac- ciones
que el sistema llevará a cabo tras la intereacción con los actores. Estas
interacciones incluyen flujos alternos, los cuales pueden estar descritos en el
mismo caso o bien plasmarse en otro caso de uso, la forma de representar una
acción/caso de uso en UML se muestra en la figura 3.2.

Figura 3.2: Representación de un caso de uso en UML.

• Instancia de un caso de uso.

Será el caso de uso en ejecución , será entonces la interacción que se lleva a
cabo entre actor-caso de uso. Claro está que la interacción puede ser no sólo
de un actor sino de varios con un caso de uso, se deberá detallar la secuencia
de acciones que se llevan a cabo en la interacción. Los pasos que se deberán
detallar son los siguientes:

ø La instancia de caso de uso incia.

ø El caso es invocado por un mensaje de un actor.
ø Se transita entre estados dependiendo del mensaje emitido o la acción
llevada a cabo por el actor, durante esta transicioón se deberá tener en
Cap´ıtulo 3. El Proceso Unificado 28

cuenta los mensajes a desplegar al actor as´ı como las posibles operaciones
internas que implica la transición y las excepciones que puedan ocurrir.
ø Se llega a un estado final el cual implica un cambio de caso de uso o se
llega a un estado de espera el cual podrá verse afectado por una acción
del actor sobre el sistema.

Un ejemplo de formato para un caso de uso instanciado se podrá ver en la

figura 3.3.

Figura 3.3: Ejemplo de una plantilla para instancia de caso de uso.

Cap´ıtulo 3. El Proceso Unificado 29

• Relaciones.
Las relaciones estarán dadas entre actores y casos de uso, esto es, representarán
la interacción de los actores con el sistema o bien la dependencia de casos de
uso que extienden a otros casos de uso.

3.3. Etapas del desarrollo del Proceso Unificado

El desarrollo de software bajo el Proceso Unificado involucra las siguientes etapas:

• Planteamiento del problema.

Es la etapa inicial del proceso de construcción de software. En donde se de-
berá definir de manera clara el problema, resolviendo toda duda que se llegue
a generar entre el equipo de desarrollo y el cliente. Para esta etapa deberán
tenerse varias reuniones con los clientes, preguntando sobre lo que necesitan y
desean que haga el sistema. Se deberá poner atención incluso a como le gustarı́a
al cliente que funcione y luzca el sistema.

• Análisis.
Tras recabar la información necesaria con el cliente y/o usuario, se deberá pro-
ceder a plantear entre el equipo de desarrollo todos los “supuestos” obtenidos
en la fase anterior. Se analiza toda la lógica que deberá implementar el sistema,
ası́ como la manera en que se resolverá el problema planteado.
De esta fase depende la funcionalidad del proyecto ası́ como la aprobación del
sistema final, se realiza una propuesta inicial de interfaz de usuario la cual
deberá ser presentada al cliente/usuario para su aprobación.

• Diseño.
Se realiza el diseño de la base de datos “los cimientos del sistema”, si bien lo
importante es el producto final completo, justo aqu´ı podemos resolver muchos
de los problemas a los que nos enfrentamos en el mantenimiento del sistemas si
aplicamos una correcta abstracción de entidades, atributos y relaciones, además
de una buena normalización de relaciones.
Ası́ pues el diseño de la base de datos se vuelve parte fundamental para el
buen funcionamiento del sistema ası́ como para la creación de un correcto
Cap´ıtulo 3. El Proceso Unificado 30

software. En esta etapa entran los casos de uso, creando casos de uso para
ubicar dependencias e identificar la manera en que se deberán desarrollar los
diferentes módulos diseñados durante esta etapa.

• Codificación.
Consiste en preparar el ambiente de implementación y comenzar con la codi-
ficación de los componentes. Todo esto deberá seguir lo definido en la fase de
diseo.

• Pruebas.
En esta etapa se consideran 2 tipos de pruebas:

ø Pruebas de integración.
Son pruebas que se realizan para cada componente al integrarlo con algún
otro componente creado.
ø Pruebas de sistema.
Son pruebas para verificar que el sistema funciona correctamente como un
sólo módulo. En estas pruebas es deseable incluir las pruebas con usuarios
finales del sistema para su aceptación.

• Liberación.
En algunos casos representa la última fase de desarrollo, se entrega el sistema al
cliente una vez que se ha detectado que éste funciona correctamente. Para ello
se aconseja planear un proceso de transición, el cual involucre la adaptación de
los clientes/usuarios al nuevo sistema.

• Mantenimiento.
En caso de requerirlo, el cliente solicitará que tras la liberación del producto
el mantenimiento al sistema, esto incluye, actualizaciones,creación de nuevos
módulos y administración general del sistema.
Por esta razón cobra gran importancia la documentación creada durante el
desarrollo, ya que para esta etapa se asignará sólo a parte del equipo de desa-
rrollo o en otros casos a personal que no tiene conocimiento alguno del sistema.
Por lo que deberán conocer el sistema completo aún cuando ellos sólo hayan
desarrollado ciertos módulos.
Cap´ıtulo 3. El Proceso Unificado 31

3.4. ISO/IEC 29110 Y PROCESO UNIFICADO

Para este proyecto se ha decidido utilizar la norma ISO/IEC 29110 basándonos

en la metodologı́a del Proceso Unificado y en su estructura de documentación.
De acuerdo con la norma ISO/IEC 29110 se definen dos procesos: el de Administra-
ción del Proyecto y el de Implementación de Software, ver figura 3.4.

Figura 3.4: Procesos guı́a del perfil básico

• El Proceso de Administración del Proyecto (AP).

Tiene como propósito establecer y llevar a cabo de manera sistemática las tareas
de un proyecto de implementación de software, que permitan cumplir con los
objetivos del proyecto en la calidad, tiempo y costos esperados. Está definido
por las siguientes fases [7]:

ø Planeacion de Proyecto.
ø Ejecucion del Plan de Proyecto.
ø Evaluación y Control del Proyecto.
ø Cierre de proyecto.

Ver figura 3.5

Cap´ıtulo 3. El Proceso Unificado 32

Figura 3.5: Diagrama del proceso de Administracin del Proyecto

• El proceso de Implementación de Software (IS).

Tiene como propósito la realización sistemática de las actividades de análisis,
diseño, construcción, de integración y pruebas para productos de software, nue-
vos o modificados, de acuerdo a los requerimientos especificados. Está definido
por las siguientes etapas [7]:

ø Inicio de la Implementación de Software.

ø Análisis de Requerimientos de Software.
ø Arquitectura y Diseño de Detallado del Software.
ø Construcción del Software.
Cap´ıtulo 3. El Proceso Unificado 33

ø Integración y Pruebas de Software.

ø Entrega de Productos.

Ver figura 3.6

Figura 3.6: Diagrama del proceso de Implementación de Software.

• Manuales a entregar:
Cap´ıtulo 3. El Proceso Unificado 34

Un manual es el documento que contiene la descripción de actividades que se

llevaron a cabo durante el desarrollo del proyecto, además incluye los roles que
intervinieron en el desarrollo de las tareas. Para fines de esta tesis se generarán
los siguientes manuales:

ø Manual de Administración del Proyecto.

Contiene de manera detallada la documentación que respalda la forma
en cómo se creo el proyecto, desde definiciones de estándares hasta asig-
naciones de tiempo y tareas a los roles definidos. De acuerdo al Proceso
Unificado, se construye en base a las etapas de desarrollo siguientes:
⬦ Lanzamiento.
⬦ Estrategia.
⬦ Planeación.
⬦ Seguimiento.
⬦ Cierre(Lecciones aprendidas y sugerencias de mejora, Informe de me-
diciones)
ø Manual de Implementación de Software.
Especifica de manera detallada el cómo se construyeron los módulos de
software, esto permitirá a gente ajena al equipo de trabajo mantener o
ampliar el alcance del sistema. Tomando en cuenta lo definido por el Pro-
ceso Unificado, este manual se construye en base a las etapas de desarrollo
siguientes:
⬦ Especificación de requermientos.
⬦ Diseño.
⬦ Construcción.
⬦ Pruebas.
⬦ Cierre
ø Manual de Usuario.
Permitirá conocer el funcionamiento del sistema para que los usuarios se
puedan adaptar a el, se incluyen capturas de pantalla y descripciones de
las actividades que deben seguirse para realizar funciones de los módulos
presentados en el sistema. Puede generarse más de un manual de usuario,
Cap´ıtulo 3. El Proceso Unificado 35

dependerá de la cantidad de Tipos de Usuario que se detecten, creando

un Manual de Usuario para cada uno de ellos.

Para este proyecto seguiremos la norma ISO/IEC 29110, apoyándonos en el Pro-

ceso Unificado para llevarlo a cabo, desarrollando las siguientes actividades en las
fases de cada una de las dos etapas de la norma:

• Etapa AP.
Se analiza el problema planteado por el cliente y su lógica de negocio. Además
se involucra la creación y asignacion de roles para cada uno de los miembros del
equipo de desarrollo, listas de verificación, documentación en minutas, casos
de uso, diagramas de secuencia, diagramas de estado. Para la base de datos
se incluyen diagramas entidad-relación y de clases; se crea un repositorio del
proyecto accesible a todos los miembros del equipo de desarrollo y se esta-
blece un estándar para la creación de respaldos del repositorio del proyecto
administrado mediante un control de versiones.
• Etapa IS.
Basados en el desarrollo iterativo e incremental, las tareas deberán completarse
de manera correcta para poder continuar con el resto de ellas, en caso de
presentar fallas, estas deberán corregirse para poder continuar con el resto
de las tareas; documentación en minutas sobre cambios en los repositorios de
acuerdo a los avances de codificación que se van efectuando; correcciones o
modificaciones se harán sólo bajo la creación de documentos de solicitudes de
cambio; reportes de avances de las tareas indicando estado(sin comenzar, en
proceso, finalizada); juntas semanales para saber el avance de los miembros del
equipo y verificar el avance general; pequeñas entregas de avances semanales
durante las reuniones de equipo.
Ejecución de pruebas de caja blanca y caja negra por parte de los miembros del
equipo de desarrollo y los clientes, todas ellas documentadas; autoevaluación y
evaluación de los integrantes del equipo de desarrollo; creación de documentos
de lecciones aprendidas durante el desarrollo para mejoras futuras.
Finalmente se configurará el software con el cliente liberandose una versión
funcional del sistema.
CAPÍTULO 4

PLANTEAMIENTO DEL PROBLEMA

La Division de Estudios de Posgrado de la Facultad de Medicina [3] es la depen-

dencia de la Universidad Nacional FEDERICO VILLARREAL encargada de la
administra- ción de cursos de especialidad y alta especialidad médica.
Para administrar cada uno de estos cursos, los profesores que los impar- ten, la
División cuenta con el sistema Sidep v.1.0 desde el año 2008. Dicho sistema ha
presentado diferentes fallas desde su liberación, por esta razón, se ha decidido que el
sistema sea analizado para saber si es funcional, si se debe modificar, actualizar o
rehacer por completo.
Los supuestos bajo los que se construyó el sistema y deberı́a manejar de manera
correcta son:

• Despliegue de información de sedes en las que se imparte un curso en especı́fico.

• Despliegue de información sobre los profesores (titulares y adjuntos) asignados

a un curso en una especialidad especı́fica.

• Despliegue de información de reportes como: totales de profesores, cursos ,

profesores que se encuentran en actividad durante un periodo escolar especı́fico.

• Permitir operaciones sobre la información de profesores, cursos como

inserciones, actualizaciones y borrados de registros.

36
Cap´ıtulo 4. Planteamiento del Problema 37

Además, se tienen identificados 3 tipos de usuarios que tienen interacción con el

sistema, uno de ellos “Jefe de Enseñanza” es externo a la división, según la impor-
tancia de los usuarios se dividen en:

• Administrador de sistemas de la División de Estudios de Posgrado de la

Facul- tad de Medicina.
Es el encargado dentro de la División del desarrollo,adminsitración y manteni-
miento de los distintos sistemas y bases de datos con que cuenta la dependencia.
• Administrador de cursos de la Divión de Estudios de Posgrado de la
Facultad de Medicina.
Es el encargado, junto con su personal de apoyo, dentro de la Unidad de Pos- grado
de realizar cambios en la información del sistema,es el único rol que tiene acceso
a todas las funciones del sistema.
• Jefes de enseñanza.
Existe uno por sede, sólo podrán ser jefes de una unidad; podrán realizar
cambios en la asignación de profesores a cursos que se imparten en su sede
únicamente. Además informarán al Administrador de cursos de la Divión de
Estudios de Posgrado de la Facultad de Medicina la baja de cursos o bien la
baja de la sede del padrón.
• Usuarios de consulta.
Sólo podrán entrar a consultar datos, esto es, tendrán acceso a toda la parte
de despliegue de consultas y reportes.

4.1. Sidep v.1.0.

Este sistema tiene 5 años funcionando en la División, se creó como solución al
manejo de la información presentada anteriormente, dicho sistema está creado con
PHP versión 5.2.0, con una base de datos creada en Postgresql versión 8.4 y se en-
cuentra montado en un servidor Apache.
Durante los últimos 3 años ha presentado más errores de los tolerables, entre los prin-
cipales problemas comentados por los usuarios e indentificados por el administrador del
sistema se encuentran:
Cap´ıtulo 4. Planteamiento del Problema 38

• Inconsistencia de datos, desde “pérdida o desaparición” de registros hasta

“creacion” de registros basura.
• Problemas con la consulta de datos.
• Enlaces rotos a páginas de consulta o reportes.
• Cambios en los registros que debe hacer el administrador “a pie” ya que el
sistema no lo permite.

Tras estas observaciones el Jefe del Departamento de Cómputo de la División

solicitó hacer un análisis profundo del sistema Sidep v.1.0 para localizar las fallas y
de acuerdo a éstas definir el futuro del sistema.

4.2. ANÁLISIS A SIDEP V.1.0.

De acuerdo al informe entregado por los usuarios, la mayor parte de los errores se
encuentran en problemas de inconsistencia de datos, además por parte del Jefe del
Departamento de Cómputo se ha solicitado el cambio de interfaz por una que respete
criterios ergonómicos de usabilidad y que les permita explotar de mejor manera los
datos almacenados.

• Análisis de la base de datos Especialidades.

ø La base de datos actual de Sidep se encuentra administrada mediante el

DBMS Postgresql versión 8.4, dicha base consta de 63 tablas. Ver figura
4.1.
ø El modelo de la base de datos pretend´ıa ser una base de datos relacional,
sin embargo, la base no tiene definidas llaves primarias ni foráneas por lo
cual se viola por completo el principio del modelo relacional.
ø Otro aspecto identificado es la existencia de tablas repetidas:
Las tablas repetidas nos provocan redundancia de datos, además de confu-
sión sobre cual es la tabla real en caso de que sólo una se vea afectada con
las transacciones de la base, tenemos que la tabla academicodatospersona-
le y la tabla academicodatospersonales son la misma y están almacenando
Cap´ıtulo 4. Planteamiento del Problema 39

Figura 4.1: Estructura de la base de datos Especialidades del sistema Sidep v.1.0.

justo la misma información, lo mejor aquı́ serı́a sólo dejar una; otro caso
es con la tabla entidad y la tabla catestados, la idea de ambas es almace-
nar la información de los departamentos del Perú por lo cual lo mejor ser´ıa
eliminar alguna de las dos.
ø Tablas inútiles, es decir tablas vacı́as,incompletas o que contienen registros
incongruentes:
⬦ admip: contiene solo la ip del administrador del sistema, dicha tabla esta
compuesta de 5 atributos los cuales almacenan las diferentes partes de
la ip.
⬦ contacto: tabla con 25 atributos, completamente vac´ıa.
⬦ delegacion: tabla que intentó ser un catálogo de delegaciones, sin em-
bargo nunca se utilizó, contiene solo 2 registros.
⬦ entidad : pretendı́a ser un catálogo de estados, es una tabla incompleta
en cuanto a registros, sólo contiene 7 estados y es una tabla repetida
Cap´ıtulo 4. Planteamiento del Problema 40

ya que la base ya cuenta con la tabla catestados que cumple la misma

función.
⬦ ex 3440 2009 sem: tabla con 34 atributos, completamente vac´ıa.
⬦ examen: tabla con 33 atributos, completamente vac´ıa.
⬦ file carpdf : tabla que contiene registros basura, pretend´ıa tener un
atributo cartel que fungir´ıa como id y uno nombre archivo que al-
macenar´ıa la ruta de un archivo pdf, sin embargo se tiene solo la
secuencia de los id’s de carteles y no se tiene ningún registro válido
con información en nombre archivo ya que todos los registros contie-
nen la cadena “ ”.
⬦ impresion sede: tabla con 2 atributos(sedes,sedes baja), registros ba-
sura, ya que existen registros nulos o bien incompletos, no existe re-
gistro alguno con ambos atributos ocupados, pretend´ıa almacenar el
id de la sede que se daba de baja y el motivo por el cual lo hac´ıa.
⬦ impresion sede baja: tabla con un atributo, sólo almacena el id de la
sede.
⬦ jefesxsede: pretendı́a asociar un jefe de enseñanza con la sede asignada
sin embargo es una tabla que sólo contiene 2 registros, dichos registros
asocian dos sedes al mismo jefe lo cual viola la lógica del negocio.
⬦ la agenda: pretend´ıa ser una agenda para contacto con usuarios al
almacenar nombre, correo electróico y teléfono fijo, sin embargo sólo
contiene 2 registros de prueba.
⬦ prueba: tabla con 2 atributos, completamente vac´ıa.
⬦ t nopropuesta: tabla con 4 atributos, pretendı́a mantener la relación
entre curso, sede y un registro default que indicar´ıa que alguno de los
puestos de profesor se encuentra libre, completamente vac´ıa.
⬦ t resumen: tabla con 5 atributos, pretendı́a almacenar la información
de trabajos de alumnos, sin embargo sólo existen registros con el
atributo cuenta ocupado, este atributo fungir´ıa como llave, el resto
de los atributos se encuentran vac´ıos en todos los registros existentes.
⬦ tipo contacto: tabla que pretendı́a ser un catálogo para definir un
tipo de contacto en la tabla la agenda, sin embargo jamás se hace
Cap´ıtulo 4. Planteamiento del Problema 41

referencia a esta tabla.

ø Tablas restantes.
La mayor parte de las tablas de la base de datos tienen errores de consis-
tencia de datos ya que la mayorı́a de los atributos de éstas se encuentran o
vacı́os o con información inconsistente. Esto se debe a que la base de datos
no tiene implementadas restricciones de integridad de datos o bien en la
interfaz de usuario no se maneja ningún tipo de validación, un ejemplo de
este problema lo tenemos en la figura 4.2.
Como ejemplos de atributos innecesarios tenemos:

⬦ Mantener 4 atributos para correos electrónicos distintos, cuando la

mayorı́a de los registros sólo cuentan con un correo elctrónico.
⬦ Manejo de 3 direcciones diferentes, cuando la mayor´ıa de los registros
no tienen dirección alguna registrada.
⬦ Manejo de atributos nulos, esto es, ningún registro cuenta con algún
dato en atributos como comite,direc.

Figura 4.2: Ejemplo de errores de integridad de datos

• Análisis a la interfaz de Sidep.v.1.0 (PHP)

La interfaz como tal no presenta errores graves pero tiene errores de ligas,
Cap´ıtulo 4. Planteamiento del Problema 42

consultas incompletas y validación de datos, lo cual entorpece la realización de

las tareas de los usuarios. Ver figura 4.3

Figura 4.3: Ejemplo de enlace roto en Sidep.v.1.0.

4.3. CONCLUSIÓN DEL ANÁLISIS A SIDEP.V.1.0

• Dada la cantidad de defectos graves encontrados durante la operación del siste-
ma Sidep v.1.0., el Departamento de Cómputo decidió migrar el sistema actual
de PHP a Java. Dicha migración se realizará basándose en la interfaz actual
añadiendo las respectivas validaciones para evitar inconsistencias de datos y
arreglando enlaces rotos, todo esto como un nuevo desarrollo apoyándonos de
las herramientas de Java WEB.

• Del lado de la base de datos se concluye que se necesita una nueva base de
datos, la cual sea relacional y se encuentre normalizada; se mantendrá la inte-
gridad de los datos con validaciones en la interfaz de usuario y con restricciones en
la base de datos.
Además se necesitan optimizar las operaciones que se llevan a cabo en la base
como lo son: inserciones, actualizaciones, recuperación de datos para asociar a
Cap´ıtulo 4. Planteamiento del Problema 43

formularios y consultas, por lo cual se propone añadir procedimientos almace-

nados y vistas dentro del nuevo esquema de base de datos.
CAPÍTULO 5

PLANEACIÓN DEL PROYECTO

Durante este capı́tulo se mostrará la manera en que se planifica el desarrollo de

un proyecto de software, basándose como ya se ha comentado en la norma ISO/IEC
29110 y en las metodologı́as del Proceso Unificado y SCRUM.
De acuerdo a la norma ISO/IEC 29110 durante esta etapa se documentan los deta-
lles de la planeación necesarios para llevar a cabo una adecuada administración del
proyecto.

• La actividad de Planeación del Proyecto proveerá de:

ø El enunciado de trabajo validado y las tareas necesarias para proveer los

entregables acordados para satisfacer los requerimientos del cliente.
ø El ciclo de vida del proyecto, incluyendo dependencias entre tareas y
duración de las mismas.
ø La estrategia de aseguramiento de la calidad del proyecto, a través
de la verificación y validación de los productos/entregables, ası́ como las
revisiones del equipo de desarrollo y del cliente.
ø Los roles y responsabilidades del equipo de desarrollo y del cliente.
ø Los recursos y necesidades de capacitación para el proyecto.
ø La estimación del esfuerzo, costo y tiempo.
ø La identificación de los riesgos del proyecto.
ø Una estrategia para el control de versiones y la l´ınea base del pro-
yecto.

44
Capı́tulo 5. Planeación del Proyecto 45

ø Un repositorio del proyecto para almacenar, administrar y entregar de

manera controlada los productos, versiones de documentos y l´ıneas base
citeISO.

• Los roles definidos para esta actividad son los siguientes:

ø Cliente (CL).
Es aquella persona responsable de llevar a cabo el buen desempeño del
proyecto, por parte de la empresa que contrata el desarrollo. Debe asumir
los deberes de la empresa contratante ante el equipo de desarrollo. De- berá
estar presente en todas las fases de desarrollo del producto y realizar sus
actividades entre las que están las siguientes:
⬦ Servir de conexión entre la empresa solicitante del software y el equipo
de desarrollo.
⬦ Conocer las etapas y roles en la construcción de software.
⬦ Definir y priorizar requerimientos.
⬦ Revisar y aprobar documentos.
⬦ Entregar los recursos necesarios para llevar a cabo el producto.
⬦ Participar en la elaboración del Manual de Usuario.
ø Administrador de Proyecto (AP).
Es aquella persona que administra y controla los recursos asignados(humanos,
económicos, tecnológicos, espacio fı́sico, etc.) a un proyecto con el propósi-
to de que se cumplan correctamente los planes definidos. El foco de una
buena administración debe estar en el control y coordinación de los di-
ferentes eventos y actividades de un proyecto. Los objetivos de un AP son:
⬦ Tener el producto “a tiempo”, “bajo presupuesto” y con los requeri-
mientos de calidad definidos.
⬦ Terminar el proyecto con los recursos asignados logrando el mejor uso
de estos.
⬦ Apoyar a los integrantes de su equipo de desarrollo a cumplir los
objetivos trazados para as´ı poder cumplir el objetivo general.
⬦ Cumlplir con éxito cada una de las fases de un proyecto.
Capı́tulo 5. Planeación del Proyecto 46

⬦ Cumplir con las expectativas del cliente.

ø Lı́der Técnico (LT).
Persona que cuenta con conocimiento y experiencia en el dominio del
proceso de software, deberá elegirse con cuidado correspondiendo su co-
nocimiento con la metodologı́a elegida.
ø Equipo de Trabajo (ET).
Conformado por personal especializado en su área, creación de nuevos
roles que se profundizarán en la etapa de Implementación del Software
como:
⬦ Analista (AN).
⬦ Diseñador (DIS).
⬦ Programador (PR).

• A partir de este cap´ıtulo se mostraran tablas de actividades tomadas de la Nor-

ma ISO/IEC 29110 [7] las cuales estarán coloreadas de acuerdo a la siguiente
especificación:

ø Para las actividades desarrolladas de manera ágil se utilizará el color:

Figura 5.1: Color ágil.

ø Para las actividades desarrolladas de manera tradicional se utilizará el

color:

Figura 5.2: Color tradicional.

ø Para las actividades desarrolladas de manera hı́brida se utilizará el color:

Figura 5.3: Color h´ıbrido.

Capı́tulo 5. Planeación del Proyecto 47

La primer lista de tareas tomada de la norma ISO/IEC 29110 se presenta en las fi-
guras A.2 y A.3 que se pueden encontrar en el Apéndice Administración de Proyecto.

En las siguientes secciones se desarrollarán cada una de las tareas requeridas por
la Planeación del Proyecto. A su vez, en el Apéndice Administración del Proyecto,
se incluyen los productos generados y que conformarán los distintos manuales solici-
tados por la norma. Para facilitar la identificación de los productos de trabajo en el
texto, éstos serán escritos en itálicas.

5.1. AP.1.1 Revisar el Enunciado de trabajo.

Se tomó como producto de entrada el capı́tulo 3 el cual muestra el problema plan-
teado desde el punto de vista del cliente. Por otra parte, el producto de salida que
tendremos será el enunciado de trabajo [revisado] por el equipo de desarrollo, lo que
implica mostrar en palabras del mismo equipo el enunciado de trabajo:
La División de Estudios de Posgrado de la Facultad de Medicina, perteneciente a la
Universidad Nacional Federico Villarreal, a través de su Departamento de Cómpu-
to y Sistemas ha solicitado la creación de un nuevo sistema para la administración
de cursos, sedes y profesores de especialidades y altas especialidades que esta de -
pendencia administra. La solución deberá basarse en el sistema con que se cuenta
actualmente (Sidep.v.1.0) y deberá concentrarse en la correción de los errores que
éste presenta.

5.2. AP.1.2 Definir con el cliente las Instrucciones de

entrega para cada uno de los entregables
especificados en el Enunciado de trabajo
Para poder llevar a cabo la tarea del proyecto es necesario definir un estándar
para nombrar cada uno de los productos que se generen durante el proceso. Se define
el estándar para nombrado y documentación:

• Estándar de nombrado.
Capı́tulo 5. Planeación del Proyecto 48

Todo documento generado durante el proyecto será nombrado de acuerdo a la

especificación de nombrado de la norma ISO/IEC 29110, para los documentos
creados en base al Proceso Unificado se les nombrará de acuerdo a la especifi-
cación de dicha metodologı́a de la siguiente manera:
nombre version.tipo
El estándar para la asignación de versiones se detalla en el siguiente punto; los
tipos se asignarán de la siguiente forma:

ø .docx para versiones entregables pero que NO son finales.

ø .pdf para versiones entregables finales construido apartir del entregable
homónimo pero de tipo .docx.

• Definición del control de versiones.

Dado que el proyecto será dividido en iteraciones o sprints de una semana, se
tomará cada fin de sprint como el punto en el tiempo para establecer la versión
de cada producto de trabajo.

ø Sólo se asignará un control de versión a un entregable, esto es, una tarea

completada.
ø El primer número de versión a asignar siempre será 1.0.
ø De acuerdo a los cambios que se vayan realizando el nuevo número de
versión se asignará de la sigueinte manera:
⬦ El primer número(a la izquierda del punto) se incrementará en 1 en
cada cambio que se realice al entregable.
1 para la primer versión, 2 para la versión que sufrió el primer cam-
bio, etc.
Ej:
enunciadodetrabajo 2.1f.pdf significa que el producto enunciadodetra-
bajo ha sufrido un cambio respecto a su versión inicial.
⬦ El segundo número(a la derecha del punto) indicará el número de la
semana en que se llevó a cabo la modificación del entregable.
Ej:
Retomando el ejemplo del punto anterior enunciadodetrabajo 2.1f.pdf
Capı́tulo 5. Planeación del Proyecto 49

indicará no sólo que es la segunda versión del producto sino que el

cambio se llevó a cabo en la semana número uno del proyecto.
⬦ Para el caso de las versiones finales, se indicará dicha situación añadien-
do una f al después del segundo número (a la derecha del punto),
quedando:
nombre versionf.tipo, considerando el mismo ejemplo de los puntos
anteriores tenemos el ejemplo:
enunciadodetrabajo 2.1f.pdf que indica que la versión generada es la
final.

• Definición del estándar de documentación.

Todo documento que se genere durante el proyecto se deberá respetar el si-
guiente formato de entrega:

ø Deberán ser creados en el editor de textos Word versión 2010.

ø El tamaño definido para todos los documentos será A4, fuente tipo Calibri
y tamaño de la fuente 11 en caso de que no se especifique otro tamaño.
ø Deberá incluir los logotipos de la Universidad Nacional Federico
Villarreal (parte superior izquierda de la hoja) y de la Facultad de Medici-
na(parte superior derecha de la hoja).
ø El nombre del sistema se ubicará entre ambos logos definidos en el punto
anterior (SIDEP v.2.0) en tamaño de fuente 16.
ø Linea de separación en color azul entre la cabecera del documento definida
en los puntos anteriores y el resto del documento.
ø Fecha del documento ubicada en la parte izquierda bajo el logo de la Ui-
versidad Nacional Federico Villarreal y la lı́nea que azul que especifica la
cabecera del documento con el formato:
dia de mes del año
ø Ttulo del documento generado bajo el logo de la Facultad de Medicina y la
l´ınea que azul que especifica la cabecera del documento.
ø Versión del documento, ubicada bajo la fecha del documento.
ø La numeración de páginas se ubicará en la parte inferior del documento
en un c´ırculo color azul y con fuente color blanco.
Capı́tulo 5. Planeación del Proyecto 50

ø Contenido de acuerdo a las plantillas planteadas por la norma 29110, para

el caso de los documentos generados en base al Proceso Unificado se deberá
presentar y aprobar una plantilla para poder crear el documento de
manera correcta.

ø En caso de requerir tablas los bordes serán en color azul, los tı́tulos de
columna de éstas deberán tener fondo azul y fuente color blanco, el con-
tenido deberá estar en fuente color negro.

Siguiendo los lineamientos antes mencionados, en la figura 5.4 se tiene definida

la plantilla general a utilizar en este proyecto.

Figura 5.4: Diseño general de plantilla (encabezado y numeración de páginas).

En base a los puntos definidos anteriormente, podemos mostrar el primer do-

cumento generado, ver figura 5.5
 Capı́tulo 5. Planeación del Proyecto 51

La división de estudios de la Facultad de medicina de la Universidad Nacional Federico Villarroel a través de su

departamento de cómputo y sistemas ha solicitado la creación de un nuevo sistema para la administración de cursos y
profesores de especialidades y altas especialidades que esta dependencia administra. La solución deberá basarse con el
sistema con que cuenta actualmente (idep.v.1.0) deberá concentrarse en la corrección de los errores que presenta el
Sidep.v.1.0)

Figura 5.5: Documento Enunciado de Trabajo.

5.3. AP.1.3 Identificar las tareas especı́ficas a rea-

lizar para producir los entregables y sus com-
ponentes.
Como ya habı́amos mencionado, se tomará la idea de los distintos tipos de reunio-
nes de la metodologı́a SCRUM para el desarrollo de este proyecto. Los elementos
tomados de SCRUM se definen a continuación:

• sprint.
Para este proyecto los sprints tendrán una duración de una semana por lo que
cada lunes se cerrará el sprint con la reunión Revisión del sprint y comenzará el
Capı́tulo 5. Planeación del Proyecto 52

siguiente sprint con el sprint Planning correspondiente.

• Reuniones sprint Planning.

Se planean de acuerdo a la duración de los sprints definidos en el punto anterior,
por lo cual en este proyecto se llevarán a cabo cada dı́a lunes a las 11:00
hrs. en la oficina del Jefe del Departamento de Cómputo de la División de
Estudios de Posgrado de la Facultad de Medicina. Los productos que se definan
como entregables durante esta reunión se encontrarán detallados en el Product
Backlog. El cual deberá cumplir con el estándar de documentación definido
(ver figura 5.6) ademas de los datos mencionados en el encabezado general,
incluirá el número de sprint al que pertenece debajo del nombre del documento.

Sidep.v.1.0

Productos Características de entrega

Producto n° 1 Características que deberá cumplir el producto 1 para su
entrega
Producto n° 2 Características que deberá cumplir el producto 2 para su
entrega
Producto n° 3 Características que deberá cumplir el producto 2 para su
entrega
--------- -------
Producto n Características que deberá cumplir el producto n para su
entrega

Figura 5.6: Plantilla para Product Backlog.

Capı́tulo 5. Planeación del Proyecto 53

• Reuniones sprint Planning Meeting.

Para el proyecto se llevarán a cabo cada 7 dı́as y más que planear los pro-
ductos a efectuar durante un sprint, se plantearán los problemas a los que se
ha enfrentado o bien ha detectado el equipo de trabajo, además de hacer una
revisión general del estado en el que se encuentra el desarrollo del proyecto.
Aquı́ añadieremos un nuevo documento para recabar la información durante la
reunión, ver figura 5.7, se añadirá bajo el nombre del documento el número de
reunión de tipo sprint Planning Meeting que se está realizando.

Sidep.v.1.0

Productos Características de entrega

Producto n° 1 Situación del producto por x 1
Producto n° 2 Situación del producto por x 2
Producto n° 3 Situación del producto por x 3
Producto n° 4 Situación del producto por x 4
----- ---------
------- --------
-------- -------
No. De problema Situación del producto por x n

Figura 5.7: Plantilla para documentar la información recabada en las reuniones sprint
Planning Meeting.
Capı́tulo 5. Planeación del Proyecto 54

• Reuniones Daily Scrum

Debido a que el tamaño del equipo es reducido, se manejarán reuniones tipo
Daily Scrum en las cuales participará el único integrante del equipo de desarro-
llo y el Jefe del Departamento de Cómputo de la División, cuando sea requerido
se contará con la participación del cliente.
• Lista de Tareas
Las tareas como lo especifica SCRUM, son acciones que derivan en funcio-
nalidades del sistema, está compuesta bajo los siguientes requerimientos o
funcionalidades que deberá implementar el sistema:

ø Permitirá el registro de nuevos Profesores y permitirá la actuali-

zación o eliminación de cualquier Profesor existente, ası́ como la
asociación de estos a un curso y sede manteniendo los datos para
consultas posteriores.
ø Permitirá el registro de nuevas sedes y nuevos cursos.
ø Permitirá la baja de sedes eliminando también toda relación con pro-
fesores y cursos que ah´ı se imparte manteniendo los datos para consultas
posteriores.
ø De manera similiar al punto anterior permitirá la baja de cursos elimi-
nando también toda relación con profesores y sedes en las que se encuentra
activo el curso manteniendo los datos para consultas posteriores.
ø Permitirá el registro de nuevos Jefes de Enseñanza en cualquiera
de las sedes disponibles permitiendo la eliminación del Jefe de Enseñan-
za de dicha sede en caso de exisitir manteniendo los datos para consul-
tas posteriores, además de permitir la eliminación o actualización de
cualquier Jefe de Enseñanza exixtentemanteniendo los datos para
consultas posteriores.
ø Permitirá consultar los datos actuales y los de años anteriores, las consul-
tas que debe manejar el sistema son:
⬦ Mostrar todos los Profesores registrados en un ciclo especı́fico.
⬦ Mostrar los Profesores por Curso especı́fico en un ciclo especı́fico.
⬦ Mostrar los Profesores por Sede especı́fica en un ciclo especı́fico.
Capı́tulo 5. Planeación del Proyecto 55

⬦ Mostrar los Profesores por Sede y Curso especı́ficos en un ciclo es-

pecı́fico.
⬦ Mostrar todos los Jefes de Enseñanza en un ciclo especı́fico.
⬦ Mostrar el Jefes de Enseñanza por Sede especı́fica en un ciclo especı́fi-
co.
⬦ Mostrar todos los Cursos disponibles en un ciclo especı́fico.
⬦ Mostrar todas las Sedes disponibles en un ciclo especı́fico.
⬦ Mostrar las Sedes de acuerdo a un Curso especı́fico en un ciclo es-
pecı́fico.
⬦ Mostrar los Cursos de acuerdo a una Sede especı́fica en un ciclo es-
pecı́fico.
Si se diseña y construye un buen sistema no tendremos que preocuparnos
por los errores encontrados en la versión anterior del sistema (Sidep.v.1.0)
ya que el nuevo sistema se construirá bajo los mismos requerimientos.

La plantilla para el detallado de las tareas se muestra en la figura 5.8, en dicha

plantilla deberá especificarse la tarea a realizar, la fecha de inicio y fin de la
tarea, el tiempo estimado deberá ser medido en horas e inmediatamente deberá
especificarse el tiempo invertido(serán las horas reales), por último una columna
para observaciones o dependencia de tareas.

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Tarea 1 Dd/mm/aa Dd/mm/aa Xhrs xhrs Sin
observaciones
Tarea 2 Dd/mm/aa Dd/mm/aa Xhrs xhrs Depende de la
tarea 1
Tarea n Dd/mm/aa Dd/mm/aa Xhrs xhrs Sin
observaciones
Capı́tulo 5. Planeación del Proyecto 56

Figura 5.8: Plantilla para documentar las tareas identificadas a desarrollar.

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Tarea 1 Dd/mm/aa Dd/mm/aa Xhrs xhrs Sin
observaciones
Tarea 2 Dd/mm/aa Dd/mm/aa Xhrs xhrs Depende de la
tarea 1
Tarea n Dd/mm/aa Dd/mm/aa Xhrs xhrs Sin
observaciones
Capı́tulo 5. Planeación del Proyecto 57

De acuerdo a las especificaciones de documentación y requerimientos mencio-

nados y siguiendo la norma ISO/IEC 29110, hasta este punto tendremos las
tareas listadas de manera general, de cierto modo, tendremos bloques de tareas
con un fin en común, ver en las figuras 5.9, 5.10 y 5.11, los colores ayudan a
diferenciar en que etapa se llevará a cabo la actividad.
 Capı́tulo 5. Planeación del Proyecto 58

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Análisis de // //
requerimiento
Prototipo de // //
interfaz
Diseño de base de // //
datos
Codificación de // //
base de datos
Codificación de Módulos de Interfaz, control Y conexión
Codificación de // //
interfases de
secciones
Codificación de // //
interfases de
secciones
Codificación de // //
interfases de
actualizaciones
Codificación de // //
interfases de
consultas
Codificación de // //
clase de control
Codificación de // //
clase de conexión
Codificación de // //
clase de lógica de
interfases de
intersecciones

Figura 5.9: Bloque de tareas identificadas a desarrollar.

 Capı́tulo 5. Planeación del Proyecto 59

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Codificación de clase // //
de lógica de interfases
de actualizaciones
Codificación de clase // //
de lógica de interfases
de consultas

Integración del sistema

Integración de // //
conexión de clases de
control
Integración de // //
conexión de clases de
control con interfases
de intersecciones
Integración de // //
conexión de clases de
control con interfases
de eliminaciones
Integración de // //
conexión de clases de
control con interfases
de actualizaciones
Integración de // //
conexión de clases de
control con interfases
de consulta
Pruebas
Prueba de caja blanca // //
de inserciones
Prueba de caja blanca // //
de eliminaciones
Prueba de caja blanca // //
de actualizaciones

Figura 5.10: Bloque de tareas identificadas a desarrollar.

 Capı́tulo 5. Planeación del Proyecto 60

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Prueba de caja negra // //
de intersecciones
Prueba de caja negra // //
ekiminaciones

Prueba de caja negra I// //

De actualizaciones
Migración De Sidep v.1.0 A idep.v.2.0
Limpieza de base de // //
datos de datos
originales para la
migración
Respaldo de base de // //
datos limpios a base
original
Intersección de datos // //
en nueva base de
datos
Adaptación de // //
usuarios al nuevo
sistema
Entrega del producto Pruebas
final

Figura 5.11: Bloque de tareas identificadas a desarrollar.

Capı́tulo 5. Planeación del Proyecto 61

5.4. AP.1.4 Establecer la Duración estimada para

realizar cada tarea.
De acuerdo a la lista presentada en el punto anterior, estimaremos el tiempo (en
horas) que llevará realizar cada tarea definida, dado que nos apoyamos también en la
metodologı́a SCRUM, una tarea no puede durar más de 16 horas, ası́ que los tiempos
estimados estarán difinidos de acuerdo a la restricción que nos indica la metodologı́a.
Tenemos entonces la nueva lista de tareas presentada en las figuras 5.12, 5.13 y 5.14, los
colores ayudan a diferenciar en que etapa se llevará a cabo la actividad.
 Capı́tulo 5. Planeación del Proyecto 62

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Análisis de // // 12 horas
requerimiento
Prototipo de interfaz // // 16 horas

Diseño de base de I// // 16 horas

datos
Codificación de Modulos de Interfaz, control Y conexión
Codificación de // // 16 horas
interfases de
secciones
Codificación de // // 16 horas
interfases de
secciones
Codificación de // // 16 horas
interfases de
actualizaciones
Codificación de // // 16 horas
interfases de
consultas
Codificación de // // 16 horas
clase de control
Codificación de // // 16 horas
clase de conexión
Codificación de // // 16 horas
clase de lógica de
interfases de
intersecciones

Figura 5.12: Tiempos estimados para los bloques de tareas.

 Capı́tulo 5. Planeación del Proyecto 63

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Codificación de clase // // 16 horas
de lógica de interfases
de actualizaciones
Codificación de clase // // 16 horas
de lógica de interfases
de consultas

Integración del sistema

Integración de // // 16 horas
conexión de clases de
control
Integración de // // 16 horas
conexión de clases de
control con interfases
de intersecciones
Integración de // // 16 horas
conexión de clases de
control con interfases
de eliminaciones
Integración de // // 16 horas
conexión de clases de
control con interfases
de actualizaciones
Integración de // // 16 horas
conexión de clases de
control con interfases
de consulta
Pruebas
Prueba de caja blanca // // 16 horas
de inserciones
Prueba de caja blanca // // 16 horas
de eliminaciones
Prueba de caja blanca // // 16 horas
de actualizaciones

Figura 5.13: Tiempos estimados para los bloques de tareas.

 Capı́tulo 5. Planeación del Proyecto 64

Sidep.v.1.0

TAREA FECHA DE INICIO FECHA FIN TIEMPO ESTIMADO OBSERVACIONES O

DEPENDENCIAS
Prueba de caja negra // // 16 horas
de intersecciones
Prueba de caja negra // // 16 horas
ekiminaciones

Prueba de caja negra I// // 16 horas

De actualizaciones
Migración De Sidep v.1.0 A idep.v.2.0
Limpieza de base de // // 16 horas
datos de datos
originales para la
migración
Respaldo de base de // // 16 horas
datos limpios a base
original
Intersección de datos // // 16 horas
en nueva base de
datos
Adaptación de // // 16 horas
usuarios al nuevo
sistema
Entrega del producto Pruebas 16 horas
final

Figura 5.14: Tiempos estimados para los bloques de tareas.

Capı́tulo 5. Planeación del Proyecto 65

5.5. AP.1.5 Identificar y documentar los recursos

requeridos para el desarrollo del proyecto.
De acuerdo a la norma ISO/IEC 29110, debemos Identificar y documentar los re-
cursos: humanos, materiales, equipo y herramientas, estándares, incluyendo la capa-
citación requerida para que el Equipo de Trabajo pueda realizar el proyecto. Ası́ como
incluir las fechas en el calendario cuando sean requeridos los recursos y la capacita-
ción.
La documentación con estas especificaciones se pueden ver en las figuras 5.15, 5.16,
se debe recordar que durante este capı́tulo se ha definido ya el estándar de documen-
tación y control de versiones.
 Capı́tulo 5. Planeación del Proyecto 66

Sidep.v.1.0

Versión 1.0
El material y herramientas empleados en la elaboración de este proyecto han sido definidas de acuerdo a los
requerimientos del cliente así como las especificaciones de especificaciones planteada por el jefe del Departamento de
cómputo de la división de estudios de Post Grado de la Universidad Nacional Federico Villarreal-
Material herramientas
1. Equipo de escritorio proporcionado  Entorno de desarrollo Neats Beans
por el departamento de Computo de versión 6.1.9
la División de Estudios de Post Grado  Servidor web GlasFish versión 1.1.1
2. Servidor Dell Windows Server 2008  Dreamweaver versión CS5
en el cual se instalará la aplicación  PostgreSQL VERSION 8.4
para su uso por la división de estudios
de Post Grado.

Figura 5.15: Material y herramientas requeridos para el desarrollo del proyecto.

Capı́tulo 5. Planeación del Proyecto 67

Figura 5.16: Estándares para el desarrollo del proyecto.

Capı́tulo 5. Planeación del Proyecto 68

5.6. AP.1.6 Establecer la Estructura del Equipo

de Trabajo

De la norma ISO/IEC 29110 se debe Establecer la Estructura del Equipo de Tra-

bajo, asignando los roles y responsabilidades acordes a los Recursos.
De acuerdo a esto, la composición del Equipo de Trabajo queda definida en el do-
cuento que se muestra en la figura 5.17.

Figura 5.17: Equipo de trabajo para el desarrollo del proyecto.

Capı́tulo 5. Planeación del Proyecto 69

5.7. AP.1.7 Asignar la estimación inicial y las fe-

chas determinadas para cada tarea.
El fin de esta tarea es crear el Calendario de Tareas del Proyecto considerando
los recursos asignados, la secuencia y dependencia de tareas.
Asignaremos rangos de fechas de acuerdo a su tiempo estimado de trabajo, consi-
derando que hay 3 semanas de vacaciones (11 de julio del 2012 al 29 de julio del
2012), ver las figuras 5.18,5.19 y 5.20, además generamos el diagrama de gantt del
proyecto el cual nos permitirá plasmar de manera gráfica la duración de los bloques
de tareas del proyecto, los colores ayudan a diferenciar en que etapa se llevará a
cabo la actividad.
Capı́tulo 5. Planeación del Proyecto 70

Figura 5.18: Fechas especificadas para el desarrollo de las tareas del proyecto.
Capı́tulo 5. Planeación del Proyecto 71

Figura 5.19: Fechas especificadas para el desarrollo de las tareas del proyecto.
Capı́tulo 5. Planeación del Proyecto 72

Figura 5.20: Fechas especificadas para el desarrollo de las tareas del proyecto.
Capı́tulo 5. Planeación del Proyecto 73

5.8. AP.1.8 Calcular y Documentar la Estimación

del Esfuerzo y Costo.

De acuerdo a la proyección que se realizó en la sección anterior, mostramos en la

figura 5.21 el Diagrama de Gantt correspondiente a este proyecto.

Figura 5.21: Diagrama de Gantt de las tareas del proyecto.

Capı́tulo 5. Planeación del Proyecto 74

5.9. AP.1.9 Identificar y documentar los riesgos

que pueden afectar al proyecto.
En la figura 5.22 se especifican los riesgos identificados que podrı́an afectar al
desarrollo del proyecto, indicando el impacto que causar´ıan al desarrollo (bajo, medio,
alto), que tan probable es que ocurra dicho riesgo (bajo, medio, alto) y una estrategia
para el manejo en caso de ocurrir.
Capı́tulo 5. Planeación del Proyecto 75

Figura 5.22: Registro de riesgos posibles.

Capı́tulo 5. Planeación del Proyecto 76

5.10. AP.1.10 Documentar la Estrategia de Con-

trol de Versiones.
Anteriormente se estableció el control de versiones para la documentación. En
esta sección se definirá el control de versiones para los entregables de codificación del
proyecto, generando as´ı el control de versiones para todos los productos a entregar
del proyecto.
Capı́tulo 5. Planeación del Proyecto 77

Figura 5.23: Control de versiones.

Capı́tulo 5. Planeación del Proyecto 78

5.11. AP.1.11 Generar el Plan del Proyecto inte-

grando los elementos previamente identifi-
cados y documentados.
Para generar el Plan del Proyecto se hará un compendio y se ordenarán los
documentos ya creados. El Plan de Proyecto completo puede ser consultado en el
Apéndice A1.

5.12. AP.1.12 Incluir la descripción del producto.

Esta sección incluye el alcance del producto, objetivos del proyecto y del equipo
de desarrollo as´ı como la licencia del software a desarrollar.

• Alcance del producto.

El alcance del producto estará guiado por el Enunciado de Trabajo, ya que el
objetivo de este proyecto es atenderlo totalmente. En la figura 5.24 se muestran
los elementos relacionados u afectados con el proyecto.
Capı́tulo 5. Planeación del Proyecto 79

Figura 5.24: Alcance del Proyecto.

Capı́tulo 5. Planeación del Proyecto 80
Capı́tulo 5. Planeación del Proyecto 81

• Objetivo del Proyecto.

Construir un producto que cumpla de manera correcta con los requerimientos
planteados en el cap´ıtulo anterior de una manera simple e intuitiva para el
usuario. Con esto se prentende una migración y cambio de sistema que impacte
lo menos posible en las actividades diarias de los usuarios del sistema de la
División de Estudios de Posgrado de la Facultad de Medicina.

• Objetivo del Equipo de Desarrollo.

Mantener un buen ambiente de trabajo con el cliente basado en la comunicación
y trabajo cont´ınuo, cumpliendo con las tareas planeadas durante cada uno de
los sprints que tenga de duración el proyecto para ası́ generar un software de
calidad.

• Licencia
El software desarrollado y aquı́ mencionado es propiedad de la División de
Estudios de Posgrado de la Facultad de Medicina de la Universidad Nacional
Federico Villarreal[3] y quedará a resguardo del Jefe de Cómputo de la
División.

5.13. AP.1.13 Verificación del proyecto / AP.1.14

Revisar y obtener la aprobación del Plan del
Proyecto.

De acuerdo a lo presentado en las secciones anteriores, se conformó el Plan del

Proyecto, mismo que fué presentado en la junta del dı́a 8 de junio del 2012 al Jefe del
Departamento de Cómputo de la División de Estudios de Posgrado de la Facultad
de Medicina, quien aprobó el proyecto.
Capı́tulo 5. Planeación del Proyecto 82

5.14. AP.1.15 Establecer el repositorio del proyec-

to usando la Estrategia de Control de Ver-
siones.
El repositorio del proyecto contendrá todos los elementos y componentes genera-
dos, especificando su versión de acuerdo al documento versiones 1.0f.pdf, ver figura
5.25.
Capı́tulo 5. Planeación del Proyecto 83

Figura 5.25: Especificación del Repositorio del Proyecto.

Capı́tulo 6

Inicio de la Implementación de
Software

De acuerdo a la norma ISO/IEC 29110, esta actividad asegura que el Plan del
Proyecto establecido en la actividad Planeación del Proyecto sea llevado a cabo por
el Equipo de Trabajo [7]. Esta actividad provee:

• Una revisión del Plan del Proyecto por parte del Equipo de Trabajo para
determinar la asignación de las tareas.
• Un compromiso por parte del Equipo de Trabajo y del Administrador de Pro-
yecto con el Plan del Proyecto.
• El establecimiento de un ambiente para la implementación[7].

Para ésta y las subsecuentes actividades definimos los roles que estarán involu-
crados y que se sumarán a los ya definidos en la Actividad Planeación del Capı́tulo
4 de acuerdo a la norma ISO/IEC 29110[7]:

• Analista (AN).
Miembro del Equipo de Trabajo que deberá contar con:

ø Conocimiento y experiencia que permita deducir, especificar y analizar los

requerimientos.
ø Conocimiento en diseño de interfaces de usuario y criterios ergonómicos.

82
Capı́tulo 6. Inicio de la Implementación de Software 83

ø Conocimiento de técnicas de revisión.

ø Conocimiento de técnicas de edición.
ø Experiencia en desarrollo y mantenimiento de software.

• Diseñador (DIS).
Miembro del Equipo de Trabajo que deberá contar con:

ø Conocimiento y experiencia en los componentes y diseño de arquitectura.

ø Conocimiento de técnicas de revisión.
ø Conocimiento y experiencia en la planeación y ejecución de pruebas de
integracion.
ø Conocimiento de técnicas de edición.
ø Experiencia en desarrollo y mantenimiento de software.

• Programador (PR).
Miembro del Equipo de Trabajo que deberá contar con:

ø Conocimiento y/o experiencia en programación, integración y pruebas

unitarias.
ø Conocimiento de técnicas de revisión.
ø Conocimiento de técnicas de edición.
ø Experiencia en desarrollo y mantenimiento de software.

La norma ISO/IEC 29110 nos provee la lista de tareas [7] la cual se encuentra en
el Apéndice Implementación del Software en la figura B.2.

6.1. I.S.1.1 Revisar el Plan del Proyecto / I.S.1.2

Establecer el ambiente de implementación.
De acuerdo a lo definido en la tabla de tareas, se generó un Plan del Proyecto
entre Administrador del Proyecto y Equipo de Trabajo el cual incluye juntas diarias
y semanales tomadas de la metodologı́a ágil SCRUM, en ellas se verá el avance del
proyecto de acuerdo a 3 preguntas:
Capı́tulo 6. Inicio de la Implementación de Software 84

• ¿Qué has hecho desde ayer? - ¿Qué has hecho desde la semana pasada?
• ¿Qué es lo que harás hasta la reunión de mañana? - ¿Qué es lo que harás hasta
la reunión de la próxima semana?
• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? [11]

Además el Equipo de Trabajo generó el documento de la figura 6.1 aprobado

por el Cliente y el Administrador del Proyecto que especifica el ambiente con el que
se debe de contar para poder llevar a cabo el proyecto; la asignación de tareas en
nuestro caso serán distribuidas en su totalidad al Equipo de Trabajo sin distinción de
roles internos debido al tamaño reducido del equipo. La lista de tareas se tomará del
documento diagramagantt 1.0f.pdf y el documento final se muestra en la figura 6.2.
Capı́tulo 6. Inicio de la Implementación de Software 85

Figura 6.1: Ambiente establecido de trabajo.

Capı́tulo 6. Inicio de la Implementación de Software 86

Figura 6.2: Tareas asignadas.

Capı́tulo 7

Análisis de Requerimientos de
Software.

De acuerdo a la norma ISO/IEC 29110, esta actividad examina las necesidades del
cliente y establece los requerimientos del proyecto. Esta actividad provee:

• Una revisión del Plan del Proyecto por parte del Equipo de Trabajo para
determinar la asignación de las tareas.

• El análisis y especificación de los requerimientos del cliente.

• Un acuerdo sobre los requerimientos con el cliente.

• Una verificación y validación de los requerimientos.

• Un control de versiones de los requerimientos de producto de software.

En la tabla 16 tomada de la Norma ISO/IEC 29110 [7] y que se encuentra en el

Apéndice Implementación del Software, se listan las tareas de esta actividad y sus
respectivos roles y productos de trabajo las cuales serán una guı́a para el desarrollo
de la etapa.

87
Capı́tulo 7. Análisis de Requerimientos de Software. 88

7.1. I.S.2.1 Asignar tareas a los miembros del Equi-

po de Trabajo de acuerdo a cada rol, basadas
en el Plan del Proyecto actual.
De acuerdo a SCRUM se definen tres roles fundamentales para la Metodologı́a:
Scrum Master, Product Owner y Equipo de Trabajo.
Por otro lado, la norma ISO/IEC 29110 define a: Cliente, Administrador de Proyecto
y varios roles más que conforman al Equipo de Desarrollo.
Debido al tamaño del Equipo de Trabajo, que es una persona, se tomó la decisión
de fusionar los roles de la siguiente manera:

• Producto Owner - Cliente.

Adminsitrador de Cursos de la División de Estudios de Posgrado de la Facultad
de Medicina asignado a Dr. Agiles Avelar Cruz.
• Scrum Master - Administrador de Proyecto.
Jefe del Departamento de Cómputo y Sistemas de la División de Estudios de
Posgrado de la Facultad de Medicina asignado al Fis. David Velázquez Portilla
• Equipo de Desarrollo - Equipo de Trabajo.
Asignado a Erick Orlando Mata Cruz.

7.2. I.S.2.2 Documentar o actualizar la Especifi-

cación de Requerimientos.
El documento que refleja las actualizaciones sobre la Especificación de Reque-
rimientos en forma de lista se puede encontrar en el Apéndice A A.8, además se
modelaron los requerimientos del sistema empleando una documentación hı́brida:
Casos de Uso e Historias de Usuario.
Mediante casos de uso se modelaron las funcionalidades de:

• Ingresar al Sistema.
• Salir del Sistema.
Capı́tulo 7. Análisis de Requerimientos de Software. 89

Mientras que utilizando Historias de Usuario se modelaron las funcionalidades

de:

• Ciclo

ø Alta
ø Eliminación

• Curr´ıcula

ø Alta
ø Actualización
ø Eliminación
ø Consulta

• Curso

ø Alta
ø Actualización
ø Eliminación
ø Consulta

• Jefe de Enseñanza

ø Alta
ø Actualización
ø Eliminación
ø Consulta

• Nombramiento

ø Alta
ø Actualización
ø Eliminación
ø Consulta
Capı́tulo 7. Análisis de Requerimientos de Software. 90

• Profesor

ø Alta

ø Actualización

ø Eliminación

ø Consulta

• Sede

ø Alta

ø Actualización

ø Eliminación

ø Consulta

• Usuario

ø Alta

ø Actualización

ø Eliminación

ø Consulta

En la figura 7.1 se muestra el Diagrama General de Casos de Uso que incluyetodas

las funcionalidades del sistema. En verde se indican aquellas cuyo detalle se obtuvo a
través de Casos de Uso y en azúl aquellas en las que se utilizaron Historias de Usuario.
Capı́tulo 7. Análisis de Requerimientos de Software. 91

Figura 7.1: Diagrama general de Casos de Uso.

En la figuras 7.2 y 7.3 se muestra el detallado del Caso de Uso - Ingresar al

Sistema.
Capı́tulo 7. Análisis de Requerimientos de Software. 92

Figura 7.2: Caso de Uso 1 - Ingresar al Sistema

Capı́tulo 7. Análisis de Requerimientos de Software. 93

Figura 7.3: Caso de Uso 1 - Ingresar al Sistema

En la figura 7.4 se muestra el detallado del Caso de Uso - Salir del Sistema.
Capı́tulo 7. Análisis de Requerimientos de Software. 94

Figura 7.4: Caso de Uso 9 - Salir del Sistema

Capı́tulo 7. Análisis de Requerimientos de Software. 95

A continuación en la figura 7.5 se muestra la Historia de Usuario - Alta de Profe-

sor. Cabe mencionar que dada la naturaleza de las Historias de Usuario, cuyo detalle
se presentó en el capı́tulo 2, se utilizaron entre dos y cuatro Historias por cada Caso
de Uso presentado en la figura 7.1.
Capı́tulo 7. Análisis de Requerimientos de Software. 96

Figura 7.5: Historia de Usuario - Alta de Profesor.

En la figura 7.6 se muestra la Historia de Usuario - Baja de Profesor.

Capı́tulo 7. Análisis de Requerimientos de Software. 97

Figura 7.6: Historia de Usuario - Eliminación de Jefe de Enseñanza.

En la figura 7.7 se muestra la Historia de Usuario - Actualización de Sede.

Capı́tulo 7. Análisis de Requerimientos de Software. 98

Figura 7.7: Historia de Usuario - Actualización de Sede.

En la figura 7.8 se muestra la Historia de Usuario - Consulta de Profesor.

Capı́tulo 7. Análisis de Requerimientos de Software. 99

Figura 7.8: Historia de Usuario - Consulta de Profesores.

Capı́tulo 7. Análisis de Requerimientos de Software. 100

7.3. I.S.2.3 Verificar la Especificación de Reque-

rimientos y proponer una Solicitud de Cam-
bio.
Para asegurar que las funcionalidades identificadas y detalladas anteriormente,
satisfacen plenamente las necesidades del Cliente, se realizaron revisiones para que
éste las validara. Además se generó un formato para que el cliente pudiera solici-
tar cambios a funcionalidades. A continuación se presenta con mayor detalle dicho
elemento.
Capı́tulo 7. Análisis de Requerimientos de Software. 101

• Solicitud de Cambio.
Se utilizará cuando se requeriera modificar alguna funcionalidad que ya ha
sido definida o bien que ya se ha construido pero debe ser modificada. La
plantilla para estas solicitudes se muestra en la figura 7.9, en caso de que el
cambio requiera la modificacin de otra tarea o producto ésta se plasmará en
otra solicitud de cambio y se hará referencia en la solicitud de cambio que
generó dicha modificación.
Capı́tulo 7. Análisis de Requerimientos de Software. 102

Figura 7.9: Plantilla para Solicitar un Cambio durante el desarrollo del Proyecto.
 Capı́tulo 7. Análisis de Requerimientos de Software. 103

7.4. I.S.2.4 Validar y obtener la aprobación de la

Especificación de Requerimientos.
En la junta del dı́a 11 de junio del 2020 se aprobó la Especificacin de Requeri-
mientos por parte del Cliente y Administrador de Proyecto, en la cual estuvo presente
el Equipo de Desarrollo. Al ser un desarrollo ágil, no hubo necesidad de generar un
producto de trabajo como evidencia tangible del hecho.

7.5. I.S.2.5 Documentar la versión preliminar del

Manual de Usuario o actualizar la versión
existente.
El Equipo de Desarrollo propone como versión prelimiar del Manual de Usuario
una tabla de contenido, esto porque si bien se tienen claros los requerimientos, aún
no se tiene un diseño de lo que será el Sistema por lo que hasta este momento no
se puede proponer algo con mayor detalle. La tabla de contenido propuesta para el
Manual de Usuario se puede ver en la figura 7.10.
Capı́tulo 7. Análisis de Requerimientos de Software. 104

Figura 7.10: Índice preliminar del Manual de Usuario que se entregará con el Sistema
Final.
Capı́tulo 7. Análisis de Requerimientos de Software. 105

7.6. I.S.2.6 Verificar y obtener la aprobación del

Manual de Usuario.
De acuerdo al Manual de Usuario preliminar presentado en el punto anterior,
se sostuvo una junta el dı́a 18 de junio del año 2021 en la cual participaron el
Cliente, el Administrador del Proyecto y el Equipo de Desarrollo. En esta reunión
se concluyó que el contenido del manual de usuario debe de ser claro, dividiendo el
contenido en secciones:

• Primera Sección: Usuarios de Consulta.

• Segunda Sección: Jefes de Enseñanza.
• Tercera Sección: Administrador de Cursos de la División de Estudios de Pos-
grado.

De manera que se pueda realizar un Manual de Usuario de manera incremental.

También se solicitó por parte del Cliente que el Manual sea lo más detallado y claro
posible considerando que muchos de los Usuarios tienen conocimientos básicos sobre
el uso de equipos de cómputo.

7.7. I.S.2.7 Preliminar de Manual de Usuario ve-

rificado
El prelimiar de Manual de Usuario aprobado se presenta en la imagen 7.11
Capı́tulo 7. Análisis de Requerimientos de Software. 106

Figura 7.11: Índice preliminar del Manual de Usuario Aprobado que se entregará con
el Sistema Final.
Capı́tulo 8

Arquitectura y Diseño Detallado

del Software.

Durante esta etapa se transforman los requerimientos de software en la Arqui-

tectura del Sistema y en el detallado del software. De acuerdo a la norma ISO/IEC
29110 esta actividad provee de:

• Una revisión por parte de equipo de Trabajo al Plan del Proyecto para deter-
minar la asignación de tareas.
• El diseño de la arquitectura del software, componentes de software y las inter-
faces asociadas.
• El diseño detallado de los componentes de software y sus interfaces.
• Una revisión a la Especificación de Requerimientos por parte del Equipo de
Trabajo.
• Un diseño de software verificado y con defectos corregidos.
• Casos y Procedimientos de Prueba verificados para pruebas de integración.
• Un rastreo de los requerimientos en el diseño de software, casos de prueba y
procedimientos de prueba.
• Productos y documentos de diseño bajo control de versiones [7].

La tabla de tareas se muestra en las figuras B.5 y B.6 contenidas en el Apéndice

Implementacion del Software, las tareas serán detalladas en las siguientes secciones.

107
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 108

8.1. I.S.3.1. Asignar tareas a los miembros del Equi-

po de Trabajo de acuerdo a su rol para el Plan
del Proyecto Actual.
Como ya se comentó en el capı́tulo anterior, el Equipo de Desarrollo está confor-
mado por una sola persona ası́ que todas las tareas recaeran sobre ésta.

8.2. I.S.3.2. Comprender la Especificación de Re-

querimientos.
El Equipo de Desarrollo detalló un documento explicando los requerimientos de
acuerdo a su percepción de los mismos, éste fue presentado ante el Administrador de
Proyecto y el Cliente en la junta del d´ıa 25 de junio del 2012, en base al documento
mostrado a continución fueron detalladas las funcionalidades del sistema para que el
Cliente realizara las Historias de Usuario.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 109

Figura 8.1: Especificación de Requerimientos - Equipo de Desarrollo.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 110

8.3. I.S.3.3 Documentar o actualizar el Diseño de

Software.
Se comenzó definiendo los Paquetes que se utilizarán para la Arquitectura del
Sistema, este diagrama permitirá identificar las agrupaciones lógicas mostrando las
dependencias entre las mismas, dichos paquetes facilitan la asignación de tareas entre
los miembros de un Equipo de Trabajo, el diagrama se puede ver en la figura 8.2.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 111

Figura 8.2: Arquitectura con Diagramas de Paquetes.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 112

También se definió el Diagrama de Distribución el cual nos mostrará las entidades

que existirán en tiempo de ejecución, espercificando los componentes que contiene
cada una de las entidades, podemos ver el diagrama en la figura 8.3.

Figura 8.3: Diagrama de Distribución.

Además el diseño del software estará dividido en dos secciones, la primera será el
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 113

dieseño de la Base de Datos y la segunda el detalle de las Historias de Usuario

presentadas por el Cliente y documentadas en el cap´ıtulo anterior.

• Base de Datos.
Se propone como esquema de Base de Datos un esquema relacional ya que “las
reglas de negocio” que involucra Sidep nos permiten identificar las siguientes
entidades con sus respectivos atributos, además se proponen algunas entidades
a manera de catálogos los cuales almacenarán información estática:

ø Académico.
⬦ Apellido Paterno.
⬦ Apellido Materno (en caso de existir).
⬦ Nombre/s.
⬦ DNI (único).
⬦ RUC (único).
⬦ Teléfono.
⬦ Correo electrónico.
⬦ Género.
Además esta entidad generará un catálogo (cgrado) ya que cada Académi-
co tiene un grado de estudios el cual debe almacenarse. Para respetar
la normalización de Bases de Datos se extraerá el Género de la tabla
Académico para convertirlo en un catálogo (cgenero), ası́ tendremos que
Acadeémico incluirá dos llaves foráneas (nidgrado,nidgenero).
ø cgrado.
⬦ Abreviatura de grado (Dr., Lic., Enf. , etc.).
ø cgenero.
⬦ Abreviatura de género (F, M).
Un Académico puede convertirse en Profesor o bien en Jefe de Enseñanza,
as´ı que se modelaron ambas entidades:
ø Profesor.
⬦ Clave de Académico Propuesto como Profesor (llave foránea hacia
Académico).
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 114

⬦ Categorı́a de Profesor (Titular, Adjunto). El Profesor deberá estar

asignado a un Curso en una Sede en un Ciclo Escolar especı́fico, esto
nos llevará a tener el identificador de dicha relación como llave foránea
en esta entidad, además para seguir normalizando la base de datos,
proponemos extraer la categor´ıa del Profesor como una nueva entidad
en forma de catálogo (ccategoriaprofesor).
ø ccategoriaprofesor
⬦ Categor´ıa (Titular, Adjunto)
ø Jefe de Enseñanza.
⬦ Cargo (detalle de puesto).
⬦ Categorı́a de Jefe de Enseñanza (Institucional, Nacional).
Los Jefes de Enseñanza tienen un detalle especial de acuerdo a la Sede o
Institución a la que pertenecen, este atributo se llenará de manera libre
pero por defecto tendrá el valor Jefe de Enseñanza, al ser la relación Jefe
de Enseñanza - Sede o Jefe de Enseñanza - Institución única, proponemos
que el identificador del Jefe de Enseñanza sea llave foránea en la Sede o en
la Institución según sea el caso. Además para seguir con la normalización
de la Base de Datos creamos un nuevo catálogo con las categorı́as de los
Jefes de Enseñanza (ccategoriajefeensenanza).
ø ccategoriajefeensenanza
⬦ Categor´ıa (Institucional, Nacional).
ø Curso
⬦ Clave (numérica, la ingresa el usuario).
⬦ Nombre.
⬦ Nivel (Especialidades, CPAEM)
Los Cursos pueden ser impartidos en dos niveles, reconociendo que son
tuplas diferentes ya que son contenidos temáticos distintos, ası́ generamos
un nuevo catálogo (cnivel) que además de permitirnos diferenciar el nivel
de los Cursos nos permitirá mantener la normalización de la Base de
Datos.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 115

ø cnivel
⬦ Nombre de nivel (Especialidades, CPAEM).
ø Sede
⬦ Clave (numérica, la ingrea el usuario).
⬦ Nombre.
⬦ Ubicación (dirección completa).
Las Sedes pertenecen a una Institución lo que indica que es posible gene-
rar un nuevo catálogo (cinstitucion), además al Cliente le interesa saber
exactamente en qué estado se encuentra ubicada una Sede ası́ que dicha
información se extraerá para crear un nuevo catálogo (cestado).
ø cinstitucion
⬦ Nombre de Institucin.
ø cestado
⬦ Nombre de Estado.
Para relacionar las Sedes, Cursos y Profesores que los imparten de acuerdo
a un ciclo escolar identificamos una nueva entidad a manera de catálogo
(cciclo) y se propone una que permita relacionar esta información (cse-
deccurso).
ø cciclo
⬦ Ciclo Escolar (ej: 2000-2001).
ø csedeccurso
⬦ Observaciones (campo libre para llenar, valor por defecto: Sin Obser-
vaciones).
⬦ Número de inscritos. Para lograr la relación tendremos como llaves
foráneas los identificadores de Ciclo, Curso y Sede además de que
la llave primaria estará asociada de manera foránea en la entidad
Profesor para saber qué Profesor imparte el curso.
ø Curricula Profesor
⬦ Se creará un atributo por campo del formulario entregado por el Clien-
te.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 116

Para lograr que un Académico tenga una sola curricula se definirá como
llave foránea el identificador del Académico en esta entidad, además de
tener una restricción de tipo única sobre el atributo que relaciona las
entidades Curricula Profesor - Académico.
ø Nombramiento
⬦ Tipo de Nombramiento.
⬦ Nombramiento Actual.
⬦ Otro

Los tipos de nombramiento generarán dos nuevos catálogos, lo que permi-

tirá mantener una Base de Datos normalizada, ası́ los tres atributos pro-
puestos se convierten en llaves foráneas hacia dichas entidades además se
propone una llave foránea que permitirá asociar el nombramiento con un
Académico añadiendo una restricción de tipo única, ya que un Académico
sólo puede tener un registro de nombramiento asociado.
ø ctiponombramiento
⬦ Tipo de Nombramiento (3A, 5A).
ø cdetallenombramiento

⬦ Nombre de Nombramiento (Nombramiento en Pregrado, Nombra-

miento en Posgrado)

ø Sesion
⬦ Nombre (detalle de usuario).
⬦ Usuario (login).
⬦ Contrasea.
⬦ Permisos (Lectura, Lectura - Escritura, Lectura - Escritura - Admi-
nistración).

La entidad Sesión permitirá crear usuarios para la División de Estudios

de Posgrado y para los Jefes de Enseñanza, la manera en que se rela-
cionará esta entidad con la entidad Jefe de Enseñanza será llevando el
identificador de la tupla Sesión como llave foránea en el registro del Jefe
de Enseñanza.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 117

ø Movimiento

⬦ Detalle de movimiento.
⬦ Tipo de movimiento (Alta, Actualización, Baja).

Ya que se desea llevar un registro de todo movimiento que se realice en

la Base de Datos, se propone la entidad Movimiento, la cual tendrá una
llave foránea hacia el usuario que realizó el movimiento, detallando el dı́a
y el registro modificado en el atributo Detalle de movimiento, el tipo de
movimiento se propone como una llave foránea hacia un catálogo cmovi-
miento.

ø cmovimiento

⬦ Tipo de movimiento (Alta, Actualización, Baja).

Adicional a la entidad movimiento se tendrá una entidad bajaprofesor la

cual permitirá al Cliente añadir comentarios a cada Profesor que es dado
de baja.

ø bajaprofesor

⬦ Motivo
⬦ Detalles de Baja

El atributo motivo será llenado de manera libre por el usuario, el atributo

Detalle de Baja deberá ser llenado por el sistema recopilando nombre del
Profesor, Sede y Curso; además se tendrán dos llaves foráneas una hacia
el identificador del ciclo y otra hacia el identificador del Profesor que ha
sido dado de baja.

El esquema de Base de Datos se presenta en las figuras 8.4 y 8.5.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 118

Figura 8.4: Esquema de Base de Datos.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 119

Figura 8.5: Esquema de Base de Datos.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 120

• Historias de Usuario.
Este desarrollo está guiado por una metodologı́a hı́brida, para detallar los re-
querimientos se utilizaron Historias de Usuario y Casos de Uso. Durante la fase
de Diseño se agregaron detalles a cada historia, lo que permitió crear un esbozo
de lo que serı́a la implementación de las funcionalidades y posteriormente el
sistema final. De esta manera el detallado de Historias de Usuario contendrá:

ø Prototipos de Interfaz validados por el Cliente.

ø Detalles de Tecnolog´ıa requerida.

ø Secuencia de solución para atender la funcionalidad que el Cliente ha

detallado, misma que podrá contener la explicación de:

⬦ Las Restricciones sobre atributos en la Base de Datos.

⬦ Detalle de los métodos que se deberán crear para el manejo de datos.
⬦ Detalle de los Procedimientos Almacenados que se utilizarán para
recuperación, inserción, eliminación o actualización de datos.

Se presentan a continuación los Detalles de Diseño de las Historias de Usuario:

ø Alta de Profesor en las figuras 8.6, 8.7, 8.8, 8.9 y 8.10.

ø Actualización de Jefe de Enseñanza en la figura 8.11.

ø Eliminación de Profesor en la figura 8.12.

ø Consulta de Cursos en la figura 8.13.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 121

Figura 8.6: Historia de Usuario Detallada - Alta de Profesor.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 122

Figura 8.7: Historia de Usuario Detallada - Alta de Profesor.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 123

Figura 8.8: Historia de Usuario Detallada - Alta de Profesor.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 124

Figura 8.9: Historia de Usuario Detallada - Alta de Profesor.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 125

Figura 8.10: Historia de Usuario Detallada - Alta de Profesor.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 126

Figura 8.11: Historia de Usuario Detallada Actualización de Jefe de Enseñanza

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 127

Figura 8.12: Historia de Usuario Detallada Elimina Curso

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 128

Figura 8.13: Historia de Usuario Detallada Consulta Cursos

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 129

8.4. I.S.3.4 Verificar y obtener la aprobación del

Diseño de Software.
La documentacion presentada en la sección anterior fue presentada por el Equipo
de Trabajo en la junta del dı́a 6 de Agosto del año 2012 al Cliente y Administrador
del Proyecto los cuales aprobaron el diseño propuesto ası́ como los requerimientos
detallados del sistema.

8.5. I.S.3.5 Establecer los Casos y Procedimien-

tos de Prueba para pruebas de integración
basados en la Especificación de Requerimien-
tos y el Diseño de Software.
De acuerdo al detallado de funcionalidades, los procedimientos de prueba se harán
de dos maneras:

• Para los Casos de Uso.

Se utilizarán Casos de Prueba los cuales en base a una entrada conocida y una
salida esperada definirán si la funcionalidad se lleva a cabo de manera correcta
o no. Los datos de entrada censarán una precondición y los datos de salida una
postcondición. El ejemplo se puede ver en la figura 8.14.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 130

Figura 8.14: Ejemplo:Caso de Prueba - Caso de Uso Ingresar al Sistema.

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 131

• Para las Historias de Usuario.

Se tomará la Historia de Usuario en donde el cliente indicará mediante una
selección (Aprobado, Rechazado) si el módulo cumple con el requerimiento
solicitado en la Historia o no. El ejemplo se puede ver en la figura 8.15.
Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 132

Figura 8.15: Ejemplo: Prueba Historia de Usuario - Consulta Profesores

Capı́tulo 8. Arquitectura y Diseño Detallado del Software. 133

8.6. I.S.3.6 Verificar y obtener la aprobación de

los Casos y Procedimientos de Prueba.
En la junta sostenida el dı́a 30 de julio del año 2012 en la que participarón el
Cliente, el Administrador del Proyecto y el Equipo de Trabajo también se validaron
los Casos y Procedimientos de Prueba presentados en la sección anterior.

8.7. I.S. 3.7 Actualizar el Registro de Rastreo /

I.S.3.8 Incorporar el Diseño de Software
Tras la junta sostenida el dı́a 30 de julio del año 20121, se pudo añadir la docu-
mentación generada y aprobada al Repositorio del Proyecto con lo cual se dió por
concluida la fase de Arquitectura y Diseño Detallado del Software.
Capı́tulo 9

Construcción del Software

De acuerdo a la Norma ISO/IEC 29110 en este capı́tulo se creará el código y los

datos del programa a partir del Diseño de Software. Esta actividad proporciona:

• Una revisión del Plan del Proyecto por parte del Equipo de Trabajo para
determinar las tareas asignadas.

• Una revisión del Diseño de Software para determinar la secuencia de Cons-

trucción de Software.

• Los Componentes de Software para determinar la secuencia de Construcción

de Software.

• Monitoreo entre los Componentes de Software y el Diseño de Software.

9.1. I.S.4.1 Asignar tareas a los miembros del Equi-

po de Trabajo de acuerdo al Plan del Proyec-
to Actual.

Dado que para este desarrollo el Equipo de Trabajo consta de una sola persona
la asignación de tareas es total al único integrante.

134
Capı́tulo 9. Construcción del Software 135

9.2. I.S.4.2 Entender el Diseño de Software.

En la junta llevada a cabo el dı́a 6 de Agosto del año 2012 en la cual participa-
ron el Administrador del Proyecto y el Equipo de Trabajo, éste último detalló de
acuerdo a su visión la forma en que se diseñarı́a el sistema, siendo aprobado por el
Administrador del Proyecto. El entendimiento del Diseño de Software se garantizó al
desarrollar las Historias de Usuario junto con el Cliente. Cualquier duda era atendida
durante las reuniones semanales directamente con el Administrador del Proyecto o,
de ser necesario, se acud´ıa con el Cliente.

9.3. I.S.4.3 Construir los Componentes de Soft-

ware basados en la parte detallada del Di-
seño de Software.
Para la construcción del sistema se utilizaron las tecnologı́as que se detallan a
continuación:

• Postgresql. Es un sistema de gestión de bases de datos objeto-relacional, dis-

tribuido bajo licencia BSD y su código disponible de manera libre. Utiliza un
modelo cliente-servidor. Utiliza multiprocesos lo que garantiza que el fallo en
un proceso no afectará al resto y el sistema continuará funcionando.
• Java Server Pages (JSP). Páginas web basadas en Java que permiten el desa-
rrollo web con contenido dinámico, tienen el aspecto de una página tradicional
HTML pero contienen código Java incrustado. Cuando una página es solicitada
por un usuario el código HTML pasa de manera directa a él, mientras que las
porciones de código Java son ejecutadas por el servidor cuando la solicitud es
recibida.
• AJAX. Acrónimo de Asynchronous JavaScript And XML - JavaScript ası́ncrono
y XML, es una técnica para el desarrollo de aplicaciones interactivas. Las apli-
caciones se ejecutan del lado del Cliente, es decir, en el navegador mientras
que se mantiene una comunicación de manera ası́ncrona con el servidor de
aplicación. AJAX permite realizar cambios sobre páginas web sin necesidad de
Capı́tulo 9. Construcción del Software 136

recargarlas mejorando la experiencia del usuario en interactividad, velocidad y

usabilidad de la aplicacion [4].

• iReport. Diseñador grafico de código abierto. Accede a bases de datos a través

de JDBC (Java Database Connectivity). Genera informes en formato .pdf, .rtf,
.xml, .xls, .csv, .html, .docx, .odt o texto simple.

Para la implementación del software se eligió una arquitectura de tres capas

ya que nos otorga como principal ventaja que, en caso de requerir algún cambio o
bien dar mantenimiento al sistema, sólo se atacará al nivel requerido, facilitando el
mantenimiento del sistema.
Para mantener la integridad de los datos as´ı como la seguridad de la Base de Datos todas
las conexiones que el sistema realizará a la misma serán implementadas con
Procedimientos Almacenados ası́ la capa de datos estará conformada por éstos y
la clase conexion.java. La capa lógica será implementada en Java mientras que la
capa de presentación (interfaz) será implementada con Ajax, esto permitirá realizar
consultas dinámicas las cuales se actualizarán en tiempo real, cabe mencionar que los
métodos y clases requeridas para el funcionamiento de AJAX serán implementados
basados en una arquitectura de 3 capas.

9.4. I.S.4.4 Diseñar o actualizar los casos de prue-

bas unitarias y aplicarlos para verificar que los
Componentes de Software implementan la
parte detallada del Diseño de Software.

El Equipo de Trabajo conformado por un único integrante decidió realizar las

pruebas unitarias en cada terminación de módulo, éstas se realizaban de acuerdo a
la función implementada y si el Equipo de Trabajo decidı́a que el módulo trabajaba
de manera correcta éste se daba por terminado.
Capı́tulo 9. Construcción del Software 137

9.5. I.S.4.5 Corregir los defectos encontrados has-

ta lograr una prueba exitosa.
Ya que el Equipo de Trabajo estuvo integrado por un único miembro, las correc-
ciones se llevaron a cabo al concluir con las Pruebas Unitarias de cada módulo que
se contruı́a. No se permitı́a avanzar en la construcción en caso de que el módulo que
se estaba desarrollando no funcionara de manera correcta.

9.6. I.S.4.6 Actualizar el Registro de Rastreo in-

corporando Componentes de Software cons-
truidos o modificados.
El desarrollo estuvo basado en Historias de Usuario, las cuales fueron utilizadas como
Registro de Rastreo ya que la construcción de los módulos del sistema estuvo basada
completamente en las mismas. Además el Equipo de Desarrollo llevó a cabo las
pruebas unitarias basándose en las Historias de Usuario, la actualización del
Registro de Rastreo se llevó a cabo indicando en cada una de las Historias de Usuario
el módulo en el cual está reflejada dicha historia. A manera de ejemplo, en la figura
9.1, bajo la sección Registro de Rastreo, se indican las dos instancias de la secuencia
en las cuales se encuentra implementada la Historia de Usuario.
Capı́tulo 9. Construcción del Software 138

Figura 9.1: Registro de Rastreo incorporado a una Historia de Usuario.

Capı́tulo 9. Construcción del Software 139

9.7. I.S.4.7 Incorporar Componentes de Software

y Registro de Rastreo.
Las versiones finales de los productos obtenidos en este cap´ıtulo se pueden en-
contrar en el Apéndice B: Implemantación del Software.
Capı́tulo 10

Integración y Pruebas del Software

La actividad de Integración y Pruebas del Software asegura que los componen-

tes de software integrados cumplan los requerimientos del software. Esta actividad
provee:

• Una revisión del Plan del Proyecto para determinar la asignación de tareas.

• Comprensión de los Casos de Prueba y Procedimientos y del ambiente de inte-

gración.

• Los Componenetes de Software integrados, defectos corregidos y resultados

documentados.

• Monitoreo de requerimientos y el diseño para el producto de software integrado.

• Documentación y verificación de los manuales de usuario y de operación.

• El Software verificado integrado a la l´ınea base [7].

Las actividades a desarrollar durante este cap´ıtulo han sido tomadas de la Norma
ISO/IEC 29110, la tabla de tareas se puede ver en el Apéndice B: Implementación
del Software en las figuras B.8 y B.9

140
Capı́tulo 10. Integración y Pruebas del Software 141

10.1. I.S.5.1 Asignar tareas a los miembros del

Equipo de Trabajo.

Dado que para este desarrollo el Equipo de Trabajo consta de una sola persona
la asignación de tareas es total al único integrante.

10.2. I.S.5.2 Entender los Casos y Procedimien-

tos de Prueba.

Los módulos creados en la etapa de Construcción serán probados de manera

hı́brida, de la siguiente manera de acuerdo a como fuerón analizados y diseñados:

• Casos de Uso. Se llevarán a cabo pruebas de caja negra y caja blanca.

• Historias de Usuario. De acuerdo a las Historias de Usuario entregadas por el

Cliente se construyó el sistema, para verificar que el sistema cumplı́a con los
requisitos especificados en las mismas se llevarán a cabo pruebas con el Cliente.
Los Casos de Prueba consistieron en entregar cada una de las Historias de
Usuario generadas al Cliente, solicitándole que especificara en la parte posterior
de la Historia la forma en que ésta se probarı́a. Al tener todas las pruebas
especificadas, se procedió a ejecutarlas sobre cada Historia, primero de manera
interna y posteriormente junto con el Usuario a modo de obtener su validación.

En la junta del dı́a 29 de Octubre del año 2021 se llevó a cabo una reunión en la
División de Estudios de Posgrado de la Facultad de Medicina, participaron el Cliente,
el Administrador del Proyecto y el Equipo de Trabajo. En ella el Equipo de Trabajo
explicó de manera breve, la forma en que debı́an llevarse a cabo las pruebas, ası́ como
el llenado de formatos para el reporte de defectos encontardos en cada Historia de
Usuario.
Capı́tulo 10. Integración y Pruebas del Software 142

10.3. I.S.5.3 Integrar el Software usando los Ca-

sos y Procedimientos de Prueba para las
pruebas de integración.
La integración se llevó a cabo dentro del mismo desarrollo, al ser un Equipo de
Trabajo reducido se decidió que la implementación del Software se harı́a de manera
incremental. Siguiendo el principio ágil de Integración continua, ésta se llevó a cabo
construyendo e integrando los módulos de la siguiente manera:

• index. Fue el primer módulo que se construyó.

• menu ciclos y salir. Se construyeron de manera paralela, el módulo menu ciclos

definirá sobre qué datos se llevarán a cabo las consultas o bien los movimientos,
el módulo salir toma todas las variables de sesión creadas durante la ejecución
del sistema y las finaliza para terminar la sesión del usuario.
• Consultas. Se construyeron de la siguiente manera:

ø Profesores. Las distintas opciones de consulta de Profesores se construye-

ron de la siguiente manera:

⬦ Todos, Titular, Adjunto, No Propuesto (en su versión total).

⬦ Todos, Titular, Adjunto, No Propuesto (Con filtros Sede - Especiali-
dad).
⬦ Todos, Titular, Adjunto, No Propuesto (Con filtros Especialidad -
Sede).

ø Jefes de Enseñanza. El orden de construcción de las consultas para Jefes

de Enseñanza fue: Todos, Institucionales, Nacionales.
ø Cursos. El orden de construcción de las consultas para Cursos fue: Todos,
Por Institución - Sede.
ø Sedes. El orden de construcción de las consultas para Sedes fue: Todas,
Por Curso - Institución, Por Institución - Curso.
ø Nombramientos. El orden de construcción de las consultas para Nombra-
mientos fue: Profesores con, Profesores sin.
 Capı́tulo 10. Integración y Pruebas del Software 143

ø Usuarios. El orden de consutrucción de las consultas de Usuarios fue:

Todos, Jefes de Enseñanza, División.

• Movimientos. Se integraron en el siguiente orden:

ø Profesores.

ø Jefes de Enseñanza.

ø Cursos.

ø Sedes.

ø Nombramientos.

ø Usuarios

Para todos los casos, los módulos integrados fueron Alta y Actualización, en
algunos casos también se integró el módulo Baja.

10.4. I.S.5.4 Realizar pruebas de Software usando

Casos y Procedimientos de Prueba.

Los Casos de Prueba se basaron en las Historias de Usuario, se pidió al Cliente

una redacción de la forma en que probarı́a la Historia ası́ como una seleccion de
aprobación o rechazo del módulo probado, se pueden ver ejemplos en las figuras
10.1 y 10.2. Para los Casos de Uso se realizarón Casos de Prueba especificando los
valores de entrada y la salida que deb´ıa arrojar el sistema, en caso de realizarlo con
éxito el módulo se aprobaba, en caso contrario se revisaba para corregir errores y se
presentaba nuevamente al Cliente.
Capı́tulo 10. Integración y Pruebas del Software 144

Figura 10.1: Detalle de prueba de Historia de Usuario - Alta de Profesor

Capı́tulo 10. Integración y Pruebas del Software 145

Figura 10.2: Detalle de prueba de Historia de Usuario - Eliminación de Profesor

Capı́tulo 10. Integración y Pruebas del Software 146

10.5. I.S.5.5 Corregir los defectos encontrados.

Tras las pruebas llevas a cabo por el Cliente basadas en las Historias de Usuario,
se corrigieron los errores encontrados en ellas. Posteriormente se obtuvo la validación
del Cliente para estas correcciones.

10.6. I.S.5.6 Actualizar el Registro de Rastreo en

caso de ser necesario.

Dado que el desarrollo se llevó a cabo con Historias de Usuario el Registro de

Rastreo se dió a través de ellas, éstas permitieron obtener una traza de los reque-
rimientos del Cliente los cuales fueron especificados en cada Historia de Usuario.
Durante las actividades de Arquitectura y Diseño Detallado del Software se incluye-
ron, en algunos casos, prototipos de interfaz y los procedimientos almacenados que
permitieron implementar la funcionalidad integrándola a la Base de Datos.
En caso de que el sistema liberado requiriese de algún mantenimiento o cambio
posterior, las Historias de Usuario, los comentarios del código y el Manual de Man-
tenimiento serán utilizados para atender dicha necesidad.

10.7. I.S.5.7 Documentar el Manual de Operación

o actualizar el manual actual, en caso de ser
apropiado.

El Manual de Operación sólo estará disponible para los administradores del sis-
tema y estará compuesto, además de lo contenido en el Manual de Usuario, por las
secciones mostradas en la figura 10.3 las cuales permitirán generar la información
necesaria y asociada al nuevo ciclo escolar o bien eliminar todos los datos asociados
a cierto ciclo escolar.
Capı́tulo 10. Integración y Pruebas del Software 147

Figura 10.3: Índice del contenido especial para el Manual de Operación.

Capı́tulo 10. Integración y Pruebas del Software 148

10.8. I.S.5.8 Verificar y obtener la aprobación del

Manual de Operación, en caso de ser nece-
sario. Verificar la consistencia del Manual de
Operación con el Software.
En la junta del dı́a 5 de noviembre del año 2021 Administrador de Proyecto
aprobó el contenido del ı́ndice del punto anterior, contemplando ası́ las funcionali-
dades extras solicitadas para los Administradores del Sistema.

10.9. I.S.5.9 Documentar el Manual de Usuario

o actualizar el actual.
Tras la Construcción del Sistema y realizar las pruebas respectivas de manera
satisfactorı́a, el Equipo de Trabajo actualizó el Manual de Usuario propuesto en el
Capı́tulo 6. Análisis de Requerimientos de Software ya que el Cliente solicitó una
estructura especial para éste. La nueva propuesta esta dividida de acuerdo al tipo
de usuario al que va dirigido, quedando de la siguiente manera:

• De Consulta. En el se encontrarán los detalles para consulta de datos, se ex-

plicará la manera en que se deberán utilizar los filtros para la generación de
datos especı́ficos, además se añadirá la explicación de cómo se podrán generar
reportes para su posterior almacenamiento o bien su impresión.

• Jefe de Enseñanza. En el se explicará la manera en que se podrán administrar

los Profesores de los Cursos que se imparten en la Sede de la cual se es Jefe de
Enseñanza. Además se añadirán las funciones del Usuario de Consulta.

• Administrador de Cursos de la División. En el se detallará la manera en que

se podrán administar los Cursos que se imparten en las Sedes registradas, se
explicará el procedimiento para la administración de Sedes, Cursos, Académi-
cos, Nombramientos, Currı́culas Profesores, Jefes de Enseñanza y Usuarios.
También se añadirán las funciones de Usuario de Consulta.
Capı́tulo 10. Integración y Pruebas del Software 149

El ´ındice de los tres Manuales se puede ver en las figuras B.11, B.12 y B.13 del
Apéndice B: Implementación del Software.

10.10. I.S.5.10 Verificar y obtener la aprobación

del Manual de Usuario.
En la junta del dı́a 12 de noviembre del año 2012, el Equipo de Trabajo mostró los
Índices de los diferentes Manuales de Usuario, los cuales fueron aprobados por el
Cliente y el Adminitrador de Proyecto.

10.11. I.S.5.11 Incorporar los Casos y Procedi-

mientos de Prueba, Reporte de Pruebas,
Manual de Operación y Manual de Usua-
rio como parte de la lı́nea base.
Las versiones finales de los Casos de Prueba de los Casos de Uso, las Historias
de Usuario y los Manuales se encuentran en el Apéndice B: Implementación del
Software.
Capı́tulo 11

Entrega de Productos

De acuerdo a la norma ISO/IEC 29110 esta actividad suministra el producto de

software integrado al Cliente, además nos proporciona:

• Una revisión del Plan del Proyecto por parte del Equipo de Trabajo para
determinar la asignación de tareas.

• Un manual de mantenimiento verificado.

• La entrega del producto de software y la documentación aplicable de acuerdo

con las Instrucciones de Entrega.

La lista de tareas ha sido tomada de la Normal ISO/IEC 29110, la cual se puede

encontrar en la figura B.10 en el Apéndice B: Implementación de Software.

11.1. I.S.6.1 Asignar tareas a los miembros del

equipo de trabajo.

El Equipo de Trabajo se constituyó por un solo integrante, dada esta situación

las tareas fueron asignadas al mismo.

150
Cap´ıtulo 11. Entrega de Productos 151

11.2. I.S.6.2 Comprender la Configuración de Soft-

ware.
El sistema Sidep.v.2.0 es un sistema web el cual requiere para su correcto funcio-
namiento:

• Servidor GlassFish v.3.1.2.2.

• Manejador de Bases de Datos: PostgreSQL.v.9.1.
• Navegaror Web con JavaScript integrado (recomendado: Mozilla v.23).

La información detallada de la instalación y configuración se encuentra en el

Apéndice B: Implementación del Software. en la sección: Manual de Administración
del Sistema.

11.3. I.S.6.3 Documentar el Manual de Manteni-

miento.
El Manual de Mantenimiento estará conformado por las Historias de Usuario,
comentarios en el código del sistema y scripts que generan la base de datos ası́ como
las restricciones y procedimientos almacenados en ella. Además se incluirán las ins-
trucciones de ejecución de los mismos y algunos de los diagramas generados durante
la documentación del proyecto. Ası́ además de la estructura del proyecto generado
por NetBeans y su contenido se añadirán:

• Diagrama de Paquetes.
• Diagrama de Distribución.
• Diagrama de Base de Datos.
• crea esquema.sql
• crea restricciones.sql
• crea sp consulta.sql
• crea sp insercion.sql
 Cap´ıtulo 11. Entrega de Productos 152

• crea sp actualizacion.sql

• crea sp eliminacion.sql

• crea sp general.sql

• datos.sql

El archivo datos.sql contiene los datos hasta el dı́a de la migración de Sidep.v.1.0 a

Sidep.v.2.0.

11.4. I.S.6.4 Verificar y obtener la aprobación del

Manual de Mantenimiento.
En la junta del dı́a 26 de noviembre del año 2012, el Equipo de Trabajo mostró al
Administrador del Proyecto el Manual de Mantenimiento de acuerdo a la estructura
detallada en la seccion anterior, el mismo fue aprobado por el Administrador del
Proyecto.

11.5. I.S.6.5 Incorporar el Manual de Manteni-

miento a la lı́nea base de la Configuración
de Software.
El Manual de Mantenimiento se incorporó al repositorio tal como muestra el in-
forme de Estado de la Configuración en el Apéndice B: Implementación del Software.

11.6. I.S.6.6 Llevar a cabo la entrega de acuerdo

a las Instrucciones de Entrega.
El dı́a 7 de diciembre del año 2012 se llevó a cabo una reunión en la que partici-
paron el Cliente, el Administrador de Proyecto y el Equipo de Trabajo. En la misma
Cap´ıtulo 11. Entrega de Productos 153

se llevó a cabo la entrega del Sistema obteniendose el documento presentado a con-

tinuación en las figuras 11.1 y 11.2 misma que avala el término de manera correcta
del proyecto.
 Cap´ıtulo 11. Entrega de Productos 154

División de estudios de Post Grado de Medicina

De una parte, el Dr. Angles Jesús Abelar administrador de cursos de especialidad de medicina de la División de Estudios
de Post Grado de la Facultad de medicina de la Universidad Nacional Federico Villarreal del Perú en adelante el cliente.
De otra parte, Fis, David Velásquez Portilla Je del Departamento de Computo y Sistemas de la división de Estudios de Post
Grado de la Facultad de Medicina de la Universidad Nacional Federico Villarreal del Perú adelante el Equipo de Trabajo.
En este acto el equipo de trabajo entrega el sistema con todos los documentos.
 Código fuente del software, y sus pruebas arquitectura necesaria para el correcto funcionamiento mostrado en
el Diagrama de Distribución. Entorno de control de versiones y resto de documentaciones.
 Manual del mantenimiento del software que incluye diseño del programa, distribución de la codificación del
software y guías de pruebas que garantizan el correcto funcionamiento del mismo.
 Manual de usuario con la información necesaria para que los usuarios lo utilicen correctamente.
 Guía de instalación, con la información necesaria para la implementación.
 El cliente recibe el software v.2.0 con toda su documentación.
 El equipo de Trabajo, el administrador del proyecto y el cliente dan por realizada la entrega del software pactado.

Figura 11.1: Documento Entrega Final del Software.

Cap´ıtulo 11. Entrega de Productos 155

Figura 11.2: Documento Entrega Final del Software.

Capı́tulo 12

Ejecución del Plan de Proyecto

Las tareas que establece la Norma ISO/IEC 29110 para esta actividad tienen co-
mo finalidad implementar el plan documentado del proyecto. Esta actividad facilita:
• El Reporte de Avance del proyecto actualizado.
• El análisis y evaluacion de los cambios solicitados al plan; y su impacto en
costos, calendario de trabajo y requermientos técnicos.
• La inclusión de los cambios aprobados al plan.
• Las revisiones y los acuerdos con el Equipo de Trabajo y el Cliente.
• El respaldo del Repositorio del Proyecto, el cual es recuperado en caso de ser
necesario [7].
La Lista de Tareas se puede ver en el Apéndice A: Administración del Proyecto
en la figura A.4.

12.1. A.P.2.1 Monitorear la ejecución del Plan del

Proyecto y registrar la información actual en
el Reporte de Avance.
El monitoreo lo llevó a cabo el Administrador del Proyecto en cada una de las
juntas semanales que se ten´ıan, el monitoreo consit´ıa en responder a 3 preguntas
especı́ficas tomadas de SCRUM y modificadas para el proyecto:

156
Capı́tulo 12. Ejecución del Plan de Proyecto 157

• ¿Qué has hecho desde la semana pasada?

• ¿Qué es lo que harás hasta la reunión de la próxima semana?

• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? [11]

Además del monitoreo semanal se implementó un monitoreo diario con las 3

preguntas tomadas de SCRUM:

• ¿Qué has hecho desde ayer?

• ¿Qué es lo que harás hasta la reunión de mañana?

• ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo? [11]

En algunas ocasiones tanto en las reuniones semanales como en las diarias el

Administrador del Proyecto revisaba el avance del sistema pidiendo al Equipo de Trabajo
que ejecutara el sistema para comprobar los avances alcanzados.

12.2. A.P.2.2 Analizar y evaluar el impacto en cos-

to, tiempo e impacto técnico de la Solicitud
de Cambio.

El Equipo de Trabajo acordó con el Cliente y el Administrador del Proyecto que

la Solicitud de Cambio se encontrar´ıa en todo momento disponible para poder solici-
tarlos en caso de ser necesario. Además el Equipo de Trabajo acordó que en caso de
existir el ingreso de una Solicitud de Cambio ésta se analizarı́a con el Administrador
del Proyecto para hacerle saber al Cliente el impacto que tendr´ıa en el desarrollo del
proyecto.
Durante el desarrollo del Proyecto se planteó una única solicitud de cambio la cual se
puede ver en la figura 12.1. En la misma se puede ver el detalle del cambio solicitado
ası́ como el impacto que ésta causó al desarrollo del proyecto.
Capı́tulo 12. Ejecución del Plan de Proyecto 158

12.3. A.P.2.3 Conducir reuniones de revision con

el Equipo de Trabajo.

Estas reuniones permitieron identificar problemas, revisar el estado de los ries-

gos, registrar acuerdos y darles seguimiento hasta su conclusión [7]. Las reuniones
como se comentó anteriormente fueron llevadas a cabo por el Administardor del
Proyecto y el Equipo de Trabajo, en algunas ocasiones también partició el cliente y
fueron reuniones diarias o semanales siguiendo la metodologı́a SCRUM para agilizar
el desarrollo del proyecto y dado el tamaño del Equipo de Trabajo.

12.4. A.P.2.4 Realizar reuniones con el Cliente.

Las reuniones con el Cliente las llevó a cabo el Administrador del Proyecto, se
aprovechó que Equipo de Desarrollo, Administrador del Proyecto y Cliente se en-
contraban en el mismo lugar de trabajo, por lo cual en caso de tener que resolver
dudas o bien generar acuerdos el Equipo de Trabajo acud´ıa con el Administrador
del Proyecto a plantear las mismas. Posteriormente el Administrador del Proyecto
acordaba una reunión breve en la cual se resolvı́an las dudas y tomaban acuerdos
con el Equipo de Trabajo.
Además en las reuniones semanales en las cuales participó el Cliente se buscó apro-
vechar al máximo las mismas para aclarar dudas de manera directa entre el Equipo
de Trabajo y el Cliente.
Capı́tulo 12. Ejecución del Plan de Proyecto 159

Figura 12.1: Solicitud de Cambio CPAEM

Capı́tulo 12. Ejecución del Plan de Proyecto 160

12.5. A.P.2.5 Realizar el Respaldo del Repositorio

del Proyecto de acuerdo a la Estrategia de
Control de Versiones.
El Respaldo del Repositorio del Proyecto se llevaba a cabo después de cada una
de las entregas parciales con el Administrador del Proyecto y el Cliente, esto es, cada
que se ten´ıa una junta semanal en la cual participaban Equipo de Trabajo, Administrador
del Proyecto y Cliente y se revisaban avances del sistema. Si la re- visión era
satisfactoria, se creaba la lı́nea base y se versionaba el Repositorio del Proyecto,
se le añadı́a un README.txt el cual contenı́a una breve descripción de las
funcionalidades cumplidas y el estado de avance del sistema. Posteriormente se
realizaba el Respaldo del Repositorio el cual se almacenaba en tres diferentes medios de
almacenamiento extra´ıbles, dos del Equipo de Trabajo y uno del Administradordel
Proyecto.

12.6. A.P.2.6 Realizar la recuperación del Repo-

sitorio del Proyecto utilizando el Respaldo
del Repositorio del Proyecto.
Afortunadamente durante el desarrollo de este proyecto no se requirió la restau-
ración mediante la utilización del Respaldo del Repositorio del Proyecto, sin embargo
para verficar que el respaldo realmente funcionaba, se hacı́an pruebas tras la creación
de éste. Las pruebas que el Equipo de Trabajo llevó a cabo consistı́an en restaurar el
Respaldo del Repositorio del Proyecto en su equipo portátil personal, la restauración
se hac´ıa en el siguiente orden:

• Esquema de Bases de Datos.

• Restricciones sobre tablas y procedimientos almacenados de la Base de Datos.

• Proyecto en NetBeans.

• Verificación de ejecución del proyecto.

Capı́tulo 12. Ejecución del Plan de Proyecto 161

• Verificación de existencia de la documentación generada hasta el momento del

respaldo.
Capı́tulo 13

Evaluacion y Control del Proyecto

De acuerdo a la Norma ISO/IEC 29110, esta actividad permite evaluar el desem-

peño del plan contra los compromisos previamente documentados. Esta actividad
permite:

• Evaluar el desempeño actual del plan y el progreso contra los objetivos.

• Identificar y evaluar el impacto en costo, calendarización, desviaciones de desem-
peño y problemas.
• Revisar los riesgos del proyecto e identificar nuevos riesgos.
• Documentar solicitudes de cambio, adoptar acciones correctivas determinadas
y monitorear los cambios hasta su cierre [7].

La Lista de Tareas extra´ıda de la Norma ISO/IEEC 29110 se puede ver en la figura

A.5 del Apéndice A: Administración del Proyecto.

13.1. A.P.3.1 Evaluar el progreso del proyecto con

respecto al Plan del Proyecto.
El progreso del proyecto se verificó de manera diaria y de manera semanal en las
juntas que se ten´ıan entre el Administrador del Proyecto y el Equipo de Trabajo,
incluso en algunas de las juntas en que participó el Cliente se verificó el progreso
en el desarrollo. Dicha verificación se llevó a cabo tomando en cuenta el Diagrama

162
Capı́tulo 13. Evaluación y Control del Proyecto 163

de Gantt y la Lista de Tareas con tiempo y fechas especificadas para el desarrollo,

presentadas en el Capı́tulo 4. Planeación del Proyecto, que se pueden ver en las
figuras 5.18, 5.19, 5.20 y 5.21 del mismo.
De acuerdo a las revisiones llevabas a cabo se puede decir que la evaluación del
progreso del proyecto es completamente satisfactoria ya que se cumplió en tiempo y
forma con los productos que se especificaron de acuerdo a las fechas acordadas.

13.2. A.P.3.2 Establecer acciones para corregir des-

viaciones o problemas e identificar riesgos
que amenacen el cumplimiento del plan.
Durante el proyecto fueron detectados pocos problemas o desviaciones que afec-
taran el correcto desarrollo del proyecto, se listan a continuación tanto los problemas
como las desviaciones que ocurrieron durante el desarrollo, además, se anexa la ma-
nera en que fueron enfrentados.

• Ausencia del Cliente.

Se aclaraban las dudas con el Administrador del Desarrollo o bien con la Secre-
tarı́a del Cliente, misma que tiene contacto profundo con la lógica del negocio.
En caso de que fuera necesaria la presencia del Cliente se continuaba con el
desarrollo de algún otro módulo y se esperaba a que el Cliente se presentara
en la División.
Nivel de ocurrencia: Bajo.
• Ausencia del Administrador del Proyecto o del Equipo de Trabajo.
Se posponı́a la reunión y revisión diaria para el dı́a siguiente.
Nivel de ocurrencia: Bajo.
• Problemas de corriente eléctrica en la División.
Se recurr´ıa al trabajo en casa por parte del Equipo de Trabajo.
Nivel de ocurrencia: Bajo.
• Sobre carga de trabajo para el Equipo de Desarrollo.
El Equipo de Desarrollo re organizaba sus tiempos para cumplir con todas sus
Capı́tulo 13. Evaluación y Control del Proyecto 164

tareas asignadas.
Nivel de ocurrencia: Medio.

13.3. A.P.3.3 Identificar cambios a requerimientos

y/o al Plan del Proyecto.
El Equipo de Trabajo, el Administrador de Proyecto y el Cliente acordaron que
para solicitar un cambio se debı́a seguir un protocolo, dicho protocolo involucró la
Solicitud de Cambio, presentada en el Capı́tulo 6. Análisis de Requerimientos de
Software y que se puede ver en la figura 7.9, el proceso de identificación de cambios
fué el siguiente:

• El Cliente llenaba la Solicitud de Cambio y la entregaba al Administrador del

Proyecto.
• El Administrador del Proyecto la entregaba al Equipo de Desarrollo.
• El Equipo de Desarrollo la analizaba y estimaba tiempo.
• El Equipo de Desarrollo se reun´ıa con el Administrador del Proyecto para
hacerle saber el tiempo y costo sobre el Plan del Proyecto.
• En caso de ser necesario se reun´ıan Cliente, Administrador de Proyecto y Equi- po
de Trabajo, en caso contrario el Administrador de Proyecto informaba al
Cliente el costo y tiempo del cambio.

Durante el desarrollo del proyecto sólo se solicitó un cambio, el cual fué sobre
el módulo de Administración del nivel CPAEM, dicho cambio se especificó en la
Solicitud de Cambio que se puede ver en la figura 12.1 del Capı́tulo 11. Ejecución
del Plan de Proyecto.
Capı́tulo 14

Cierre del Proyecto

De acuerdo a la Norma ISO/IEC 29110 en esta actividad se proporciona docu-

mentación y productos del proyecto de acuerdo con los requerimientos del contrato.
Esta actividad nos permite:

• La entrega de productos como fueron especificados en las Instrucciones de

Entrega.
• Contar con un soporte de aceptacion del producto por parte del cliente de
acuerdo a las Instrucciones de Entrega.
• Finalizar el proyecto y firmar el Documento de Aceptación.

La Lista de Tareas extra´ıda de la Norma ISO/IEEC 29110 se puede ver en la figura

A.6 del Apéndice A: Administración del Proyecto.

14.1. A.P.4.1 Formalizar la conclusión del proyec-

to de acuerdo a las Instrucciones de entrega
establecidas en el Plan del Proyecto.
El dı́a 7 de Diciembre del año 2012 se llevó a cabo la reunión final entre el Cliente,
el Administrador del Proyecto y el Equipo de Trabajo en la cual se dió por liberado
el sistema Sidep.v.2.0 y concluido el desarrollo del mismo al entregarse el sistema y
documentación de manera completa.

165
Cap´ıtulo 14. Cierre del Proyecto 166

14.2. A.P.4.2 Actualizar el Repositorio del Pro-

yecto.
Además de la entrega del sistema en la última reunión llevada acabo el dı́a 7 de
Diciembre del año 2012, el Equipo de Trabajo entregó el Repositorio del Proyecto
Actualizado, éste incluye:

• Proyecto de NetBeans con todo el código fuente, comentarios y .war generado.

• Repositorio de Documentación del Proyecto estructurado de acuerdo a la Espe-
cifiación del Repositorio del Proyecto presentada en el Capı́tulo 4. Planeación
del Proyecto y que puede verse en la figura 5.25 del mismo.
• Documentos versionados de acuerdo al Control de Versiones presentado en el
Capı́tulo 4. Planeación del Proyecto y que puede verse en la figura 5.23 del
mismo.
Capı́tulo 15

Resultados

Como resultado del proceso hı́brido que se llevó a cabo durante el desarrollo
de este proyecto se obtuvo el sistema Sidep.v.2.0 que se puede ver en la siguiente
dirección:
http://www.sidep.fmposgrado.unam.mx/sidep.v.2.0
Mismo que tras el análisis que se llevó a cabo de su predecesor Sidep v.1.0, corrige
los errores ah´ı encontrados de la siguiente manera:

• Se creó un esquema relacional de Base de Datos mismo que sustituye a un esque-

ma que intentaba ser relacional pero no contenı́a llaves primarias ni foráneas,
entre otras restricciones de integridad.

• Se creó un esquema de Base de Datos normalizado en Tercera Forma Normal

ya que el esquema anterior redundaba en información, además de tener tablas
y atributos innecesarios que incluso no se utilizaban.

• Se creó una aplicación para el manejo de la información de la base de da-

tos empleando como tecnolog´ıa base de desarrollo JAVA y AJAX, misma que
sustituye al antiguo sistema desarrollado en PHP y en el cual se encontraron
problemas como ligas rotas o formularios perdidos.

En la figura 15.1 se puede ver la pantalla de inicio de sesión del producto generado,
mismo que es compatible con los navegadores Mozilla Firefox v.24, Opera v.17.0,Google
Chrome v.30.0 e Internet Explorer 10.

167
Cap´ıtulo 15. Resultados 168

Figura 15.1: Pantalla principal de Sidep.v.2.0

Sidep.v.2.0 contiene un reporteador que genera documentos en formato PDF

implementado con iReport el cual permite la impresión de consultas de datos, imple-
mentadas con AJAX, o bien el almacenamiento de los reportes generados, un ejemplo
de un reporte generado se puede ver en la figura 15.2.

El módulo de movimientos mantiene la integridad de los datos al permitir reali-

zar altas, bajas y actualizaciones de datos de la entidad seleccionada, ya que al
recuperar los datos de la base de datos los procedimientos almacenados creados en
ésta no permiten movimientos considerados como inválidos para la lógica del negocio.

En cuanto al Desarrollo del Proyecto se puede decir que emplear una metodologı́a
hı́brida permitió obtener un mejor producto al involucrar de manera más directa
al Cliente en el desarrollo del mismo logrando cubrir sus necesidades satisfactoria-
mente. Además se atacó la problemática de tener un Equipo de Trabajo reducido,
permitiendo resolver dudas y mostrar avances de manera diaria al aprovechar que
tanto Cliente, Administrador del Proyecto y Equipo de Trabajo se encontraban en
el mismo lugar.
Cap´ıtulo 15. Resultados 169

CLAVE TOTAL DE TOTAL DE SEDE UBICACIÓN

CURSOS IN0SCRITOS
504 1 0 INCOR 504-7
INO
UBICADA EN JR.
CANGALLO 163
549 1 0 CLINICA SAN AVDA NICOLAS
JUAN DE DIOS ARRIOLA 3230
TELETON
324 2 0 HOSPITAL AVDA GRAU 800
GUILLERMO
ALMENARA
310 2 1 CENTRO AVDA
DERMATOLOGICO REPUBLICA DE
PANAMA 5790

Figura 15.2: Ejemplo de Reporte generado en Sidep.v.2.0

Capı́tulo 16

Conclusiones

Tras el desarrollo de este proyecto se puede reafirmar la importancia que hoy tiene
la Ingenier´ıa de Software para el desarrollo de Software y Sistemas Computacionales,
permitiendo la abstracción de la lógica de un negocio no sólo para un Programador o
Equipo de Trabajo (Métodos Tradicionales) sino que es posible involucrar de manera
directa al Cliente (Métodos Ágiles) con lo cual se puede obtener un producto más
cercano a las necesidades de éste, y en consecuencia maximizando los beneficios para
él.
Además el trabajo permite observar que la aplicación de una metodologı́a hı́brida
permite aprovechar de mejor manera los beneficios de las metodologı́as involucradas,
culminando el proyecto con un producto de mejor calidad ya que se involucra alCliente
en el desarrollo y permite un mejor entendimiento con el Equipo de Trabajo, reflejando
en éste un aprendizaje y satisfacción para los involucrados.
Como Equipo de Trabajo puedo decir que el desarrollo cumplió con el objetivo fi-
jado al principio del proyecto que era la corrección de los errores que afectaban a
Sidep.v.1.0 y que impactaban en el desarrollo de las actividades administrativas y
académicas de la División de Estudios de Posgrado de la Facultad de Medicina.
De manera personal me permitió aprender nuevas tecnologı́as (AJAX, iReport),
además de involucrarme en un ámbito que era completamente ajeno a mı́ como
lo es la medicina, si bien no soy ni seré médico tras el desarrollo de este proyecto, si
conocı́ cosas del sector salud de las cuales no tenı́a idea que existieran. Remarcando
ası́ el amplio campo de aplicación que actualemente tiene mi carrera.

170
Apéndice A

Administración del Proyecto

Aqu´ı se encuentran las Tablas de Tareas extra´ıdas de la Norma ISO/IEC 29110[7]

de los cap´ıtulos:

• Capı́tulo 4. Planeación del Proyecto.

• Capı́tulo 11. Ejecución del Plan de Proyecto.
• Capı́tulo 12. Evaluación y Control del Proyecto.
• Cap´ıtulo 13. Cierre del Proyecto.

Además de documentacion en versiones finales generada en los mismos. La escala

de colores con la cual han sido coloreadas las tablas de acuerdo al tipo de desarrollo
llevado a cabo se presenta en la figura A.1, que indica de izquierda a derecha que el
desarrollo fue ágil, tradicional o hı́brido respectivamente.

Figura A.1: Escala de colores para las Tablas de Tareas.

171
Apéndice A. Administración del Proyecto 172

Figura A.2: Tabla 6 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 4.

Planeaci´n del Proyecto.
Apéndice A. Administración del Proyecto 173

Figura A.3: Tabla 6 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 4.

Planeación del Proyecto.
Apéndice A. Administración del Proyecto 174

Figura A.4: Tabla 7 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 11.
Ejecución del Plan de Proyecto.
Apéndice A. Administración del Proyecto 175

Figura A.5: Tabla 8 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 12.
Evaluación y Control del Proyecto.

Figura A.6: Tabla 9 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 13.
Cierre del Proyecto.
Apéndice A. Administración del Proyecto 176

Figura A.7: Plan del Proyecto.

Apéndice A. Administración del Proyecto 177

Figura A.8: Especificación de Requerimientos del Sistema.

Apéndice B

Implementación del Software

Aqu´ı se encuentran las Tablas de Tareas extra´ıdas de la Norma ISO/IEC 29110[7]

de los cap´ıtulos:

• Capı́tulo 5. Inicio de la Implementación de Software.

• Capı́tulo 6. Análisis de Requerimientos.
• Capı́tulo 7. Arquitectura y Diseño Detallado del Software.
• Capı́tulo 8. Construcción del Software.
• Cap´ıtulo 9. Integracion y Pruebas del Software.
• Cap´ıtulo 10. Entrega de Productos.

Además de documentación en versiones finales generada en los mismos. La escala

de colores con la cual han sido coloreadas las tablas de acuerdo al tipo de desarrollo
llevado a cabo se presenta en la figura B.1, que indica de izquierda a derecha que el
desarrollo fue ágil, tradicional o hı́brido respectivamente.

Figura B.1: Escala de colores para las Tablas de Tareas.

178
Apéndice B. Implementación del Software 179

Figura B.2: Tabla 15 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 5.

Inicio de la Implementación de Software.
Apéndice B. Implementación del Software 180

Figura B.3: Tabla 16 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 6.

Análisis de Requerimientos.
Apéndice B. Implementación del Software 181

Figura B.4: Tabla 16 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 6.

Análisis de Requerimientos.
Apéndice B. Implementación del Software 182

Figura B.5: Tabla 17 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 7.

Arquitectura y Diseño Detallado del Software.
Apéndice B. Implementación del Software 183

Figura B.6: Tabla 17 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 7.

Arquitectura y Diseño Detallado del Software.
Apéndice B. Implementación del Software 184

Figura B.7: Tabla 18 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 8.

Construcción del Software.
Apéndice B. Implementación del Software 185

Figura B.8: Tabla 19 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 9.

Integración y Pruebas del Software.
Apéndice B. Implementación del Software 186

Figura B.9: Tabla 19 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 9.

Integración y Pruebas del Software.
Apéndice B. Implementación del Software 187

Figura B.10: Tabla 20 de la norma ISO/IEC 29110 [7] perteneciente al Captulo 10.
Entrega de Productos.
Apéndice B. Implementación del Software 188

Figura B.11: Índice del contenido del Manual de Usuario de Consulta.

Apéndice B. Implementación del Software 189

Figura B.12: Índice del contenido del Manual de Usuario Jefe de Enseñanza.
Apéndice B. Implementación del Software 190

Figura B.13: Índice del contenido del Manual de Usuario Administrador de Cursos
de la División de Estudios de Posgrado.
Apéndice C

Informe del Estado de

Configuración

Tomando como base la Tabla 23 de la Norma ISO/IEC 29110, que se muestra

en las figuras C.2, C.3, C.4, C.5, C.6, C.7, C.8, la tabla indica una lista de entradas,
salidas y productos internos de los procesos, sus descripciones, estados posibles y la
fuente del producto, dicha tabla se utilizó como base para generar el Informe del
Estado de Configuración que se detallará en este Apéndice. El Informe del Estado
de Configuración permite recopilar la documentación generada durante este trabajo
y que justifica el seguimiento de la Norma ISO/IEC 29110[7].
La escala de colores con la cual han sido coloreadas las tablas de acuerdo al tipo
de desarrollo llevado a cabo se presenta en la figura C.1, que indica de izquierda a
derecha que el desarrollo fue ágil, tradicional o hı́brido respectivamente.

Figura C.1: Escala de colores para las Tablas de Tareas.

191
Apéndice C. Informe del Estado de Configuración 192

Figura C.2: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 193

Figura C.3: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 194

Figura C.4: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 195

Figura C.5: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 196

Figura C.6: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 197

Figura C.7: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 198

Figura C.8: Tabla 23 Descripción de productos de la Normal ISO/IEC 29110.

Apéndice C. Informe del Estado de Configuración 199

C.1. Documento de Aceptación.

Se generó durante la última reunión entre Cliente, Administrador del Proyecto y
Equipo de Trabajo, se puede ver en las figuras 11.1 y 11.2 y en el cual se cumplen las
caracter´ısticas que la Norma ISO/IEC 29110 establece puede tener el documento:
• Regitro de la recepción de la entrega.
• Identificacion de la fecha de recepción.
• Identificación de los elementos entregados.
• Registro de la verificación de los criterios de aceptación definidos por parte del
Cliente.
• Identificacion de cualquier asunto pendiente (en caso de ser aplicable).
• Firma de recibido por parte del Cliente [7].

C.2. Solicitud de Cambio.

Se estableció la forma de llevar a cabo una solicitud de cambio entre el Cliente,
Administrador del Proyecto y Equipo de Trabajo, como ejemplo, la única Solicitud
de Cambio solicitada se presenta en la figura 7.9 del Capı́tulo 6. Análisis de Reque-
rimientos de Software, en ella se puede apreciar que se cumple con la información
que la Norma ISO/IEC 29110 sugiere a continuación:
• Propósito del cambio.
• Estado de la solicitud.
• Información de contacto del solicitante.
• Sistema(s) impactado(s).
• Impacto en la operación de sistemas existentes.
• Impacto en la documentación asociada.
• Criticidad de la solicitud y fecha en que se requiere.
Al final de este Apéndice podrá observarse en las figuras C.9 y C.10 a manera
de ejemplo una Historia de Usuario en la cual se identificarán ésta y algunas de las
tareas especificadas por la Norma ISO/IEC 29110.
Apéndice C. Informe del Estado de Configuración 200

C.3. Registro de Defectos.

De acuerdo a la Norma ISO/IEC 29110 en este producto se asientan los defectos
encontrados, desviaciones o problemas relativos al cumplimiento de un plan para
posteriormente determinar las actividades necesarias para corregirlos. Este registro
puede contener:

• El problema inicial.
• Una solución.
• Las acciones correctivas a tomar.
• Responsable de la conclusión de las acciones definidas.

• Fecha de apertura y fecha de cierre esperada.

• Un indicador de estado.
• Acciones de seguimiento.

Durante el desarrollo del proyecto el Registro de Defectos se llevó a cabo de manera

ágil, los mismos fueron registrados en las Historias de Usuario, en las cuales se
incluyó un espacio para que el Cliente registrara los defectos en caso de encontrarlos
durante la prueba que ejecutó. Al final del Apéndice se podrá observar en las figuras
C.9 y C.10 un ejemplo que justifica el seguimiento de la Norma ISO/IEC 29110.

C.4. Manual de Mantenimiento.

La Norma ISO/IEC 29110 especifica que las caracterı́sticas que éste puede tener
son las siguientes:

• Incluye o se refiere a todos los elementos de la Configuración del Software

desarrollados durante la implementación.
• Identifica el ambiente utilizado para el desarrollo y realización de pruebas.

Estos puntos se cumplen con las figuras 5.15 del Capı́tulo 4. Planeación del Proyecto
y 6.1 del Capı́tulo 5. Inicio de la Implementación de Software.
Apéndice C. Informe del Estado de Configuración 201

C.5. Minuta.
La Norma ISO/IEC 29110 sugiere que el contenido de una Minuta puede contener
la siguiente información:

• Propósito de la reunión.
• Asistentes.
• Fecha y lugar.
• Referencia a minutas previas.
• Qué se logró
• Identifica cuestiones planteadas.
• Cualquier asunto abierto.
• Acuerdos.
• Próxima reunión (en caso necesario).

Dadas las reuniones tomadas de SCRUM que nos guiaron para el desarrollo de este
proyecto y considerando que el lugar de trabajo del Cliente, el Administrador del
Proyecto y el Equipo de Trabajo era el mismo, se decidió no llevar registro fı́sico de
todas y cada una de las reuniones llevadas a cabo durante el desarrollo. Sin embargoen
los casos en que era necesaria la formalización de un acuerdo, éste se plasmarı́a en
un documento que era avalado por las partes involucradas.

C.6. Manual de Operación.

Se entregó estructurado de acuerdo al ı́ndice presentado en la sección 9.5 Caṕitulo
9. Integración y Pruebas del Software y que también contiene lo detallado en la
sección 9.9 del mismo Capı́tulo. Se compone de:

• Secciones del Manual de Usuario (Usuario de Consulta y Usuario Jefe de En-

señanza).
• Secciones del Manual de Administrador de Cursos de la División de Estudios
de Posgrado de la Facultad de Medicina.
Apéndice C. Informe del Estado de Configuración 202

• Sección de Administración de Ciclos Escolares (Alta,Baja).

De acuerdo a esto se puede ver que se cumple con la información que la Norma
ISO/IEC especifica y la cual es:

• Criterios para la operación.

• Una descripción de cómo operar el producto, incluyendo:

ø ambiente operativo requerido.

ø herramientas de apoyo y material requerido (por ejemplo, manuales de
usuario).
ø posibles alertas de seguridad.
ø preparativos para la puesta en marcha y secuencia de pasos.
ø preguntas frecuentes (FAQ).

• Certificación y aprobaciones de seguridad.

• Garant´ıa e instrucciones de reemplazo.
• Debe estar escrito en términos que el personal responsable de la operación
pueda entender.

C.7. Reporte de Avance.

La Norma ISO/IEC 29110 establece que un Reporte de Avance puede contener
la siguiente información:

• Estado real de las tareas contra las tareas planeadas.

• Estado de los resultados reales contra los objetivos/metas establecidos.
• Estado de los recursos asignados reales contra los recursos planeados.
• Estado de los costos reales contra los presupuestos estimados.
• Estado calendario real contra el calendario planeado.
• Estado de los riesgos actuales con respecto a los identificados previamente.
• Registro de cualquier.
Apéndice C. Informe del Estado de Configuración 203

En el desarrollo de este proyecto, los Reportes de Avance se llevaron a cabo en las

juntas diarias o semanales que el Equipo de Trabajo manten´ıa con el Administrador
del Proyecto y en las cuales en algunas ocasiones participó el Cliente. Las juntas
permitieron cumplir con los puntos antes mencionados, ya que al responder las tres
preguntas que SCRUM establece, el avance del proyecto se hac´ıa visible para todos
los participantes.

C.8. Plan del Proyecto.

La Norma ISO/IEC 29110 especifica que un Plan de Proyecto puede contener la
siguiente información:

• Descripción de producto:

ø Propósito.
ø Requerimientos generales del cliente.

• Descripción de alcance respecto a lo incluido y lo no incluido.

• Objetivos del proyecto.
• Entregables lista de productos a entregar al cliente.
• Tareas, incluyendo verificaciones, validaciones y revisiones con el cliente y equi-
po de trabajo que permitan asegurar la calidad de los productos de trabajo. Las
tareas pueden ser representadas como una Estructura de Desglose de Trabajo
(EDT).
• Duración estimada de las tareas
• Recursos (humanos, materiales, estándares, equipos y herramientas), incluyen-
do la capacitación necesaria. Incluye la identificación y programación de los
recursos.
• Composición del equipo de trabajo.
• Calendario de las tareas del proyecto, indicando la fecha de inicio y fecha de
finalización previstas para cada tarea, y las relaciones y dependencias entre
ellas.
Apéndice C. Informe del Estado de Configuración 204

• Esfuerzo y el costo estimado.

• Identificación de los riesgos del proyecto.
• Estrategia para el control de versiones.

• Herramientas de repositorio o mecanismos identificados.

• Localización y mecanismos de acceso para el repositorio especificado.

• Identificación y control de versiones definidos.

• Respaldo y mecanismos de recuperación definidos.

• Mecanismos de almacenamiento, manipulación y entrega especificados (inclu-

yendo archivo y recuperación).
• Instrucciones de entrega.

• Elementos requeridos para la liberación del producto (por ejemplo, hardware,

software, documentación, etc.).

• Requerimientos de entrega.
• Tareas a realizar en orden secuencial.
• Liberaciones aplicables identificadas.

• Información de la versión de todos los componentes de software entregados.

• Procedimientos de respaldo y recuperación necesarios [7].

En el desarrollo del proyecto se decidió cumplir con algunos de los puntos especifi-
cados en la Norma ISO/IEC 29110 con los siguientes documentos:

• Enunciado de Trabajo que se puede ver en la figura 5.5 del Cap´ıtulo 4. Planea-
ción del Proyecto.

• Plan del Proyecto que se puede ver en la figura A.7 del Apéndice A.

• Material y Herramientas que se puede ver en la figura 5.15 del Cap´ıtulo 4.

Planeación del Proyecto.

• Estándar de Codificación que se puede ver en la figura 5.16 del Capı́tulo 4.

Planeación del Proyecto.
Apéndice C. Informe del Estado de Configuración 205

• Definicion del Equipo de Trabajo que se puede ver en la figura 5.17 del Cap´ıtulo
4. Planeación del Proyecto.
• Lista de Tareas que se puede ver en las figuras 5.18, 5.19 y 5.20.
• Diagrama de Gantt que se puede ver en la figuta 5.21.
• Control de versiones especificado en la sección 4.2 del Capı́tulo 4. Planeación
del Proyecto.

Es claro que para varios de los puntos marcados por la norma no existe evidencia
f´ısica que los demuestre, sin embargo gracias a SCRUM se pudieron atender durante las
reuniones diarias o debido a los canales de comunicación cortos y claros, que
existieron a lo largo de todo el desarrollo, entre el Equipo de Trabajo y el Cliente.

C.9. Repositorio del Proyecto.

El repositorio completo generado durante el proyecto se estructuró de acuerdo a
lo especificado en el Capı́tulo 4. Planeación del Software en la figura 5.25, el mismo
ya con los documentos y los fuentes generados finalizó de la siguiente manera:
En el directorio Versiones se encuentran versiones del documento generadas antes de
la final, aqu´ı solo se especifican versiones finales y la existencia de este directorio sin su
contenido.

• Sidep v.2.0

ø Diagramas
⬦ Diagrama de Paquetes.
⬦ Diagrama de Base de Datos.
⬦ Diagrama de Distribución.
⬦ Diagrama de Gantt.
⬦ Diagrama General de Casos de Uso.
ø Documentación - Software
⬦ AP
∗ 1.Planeación del Proyecto.
Apéndice C. Informe del Estado de Configuración 206

◦ plantillageneral 1.0.doc
◦ plantillageneral 1.0f.pdf
◦ enunciadodetrabajo 1.0.doc
◦ enunciadodetrabajo 1.0f.pdf
◦ plantillaproductbacklog 1.0.doc
◦ plantillaproductbacklog 1.0f.pdf
◦ plantillasprintplanningmeeting 1.0.doc
◦ plantillasprintplanningmeeting 1.0f.pdf
◦ plantillalistatareas 1.0.doc
◦ plantillalistatareas 1.0f.pdf
◦ listatareas 1.0.doc
◦ listatareas 1.0f.pdf
◦ listatareastiempo 1.0.doc
◦ listatareastiempo 1.0f.pdf
◦ materialyherramientas 1.0.doc
◦ materialyherramientas 1.0f.pdf
◦ estandarcodificacion 1.0.doc
◦ estandarcodificacion 1.0f.pdf
◦ equipo 1.0.doc
◦ equipo 1.0f.pdf
◦ listatareastiempoyfechas 1.0.doc
◦ listatareastiempoyfechas 1.0f.pdf
◦ riesgos 1.0.doc
◦ riesgos 1.0f.pdf
◦ versiones 1.0.doc
◦ versiones 1.0f.pdf
◦ alcance 1.0.doc
◦ alcance 1.0f.doc
◦ repositorio 1.0.doc
◦ repositorio 1.0f.pdf

∗ 2.Ejecución del Plan de Proyecto.

◦ plantillasolicituddecambio 1.0.doc
 Apéndice C. Informe del Estado de Configuración 207

◦ plantillasolicituddecambio 1.0f.pdf
∗ 3.Evaluación y Control del Proyecto.
◦ Sin documentación
∗ 4.Cierre del Proyecto.
◦ entregadesoftware 1.0.doc
◦ entregadesoftware 1.0f.pdf
⬦ IS
∗ 1.Inicio de la Implementación de Software.
◦ ambiente 1.0.doc
◦ ambiente 1.0f.pdf
◦ tareasasignadas 1.0.doc
◦ tareasasignadas 1.0f.pdf
∗ 2.Análisis de Requerimientos de Software.
◦ Casos de Uso
٨ diagramageneraldecasosdeuso 5.4.doc
٨ diagramageneraldecasosdeuso 5.4f.pdf
٨ 1ingresoalsistema 5.6.doc
٨ 1ingresoalsistema 5.6f.doc
٨ 9salirdelsistema 1.0.doc
٨ 9salirdelsistema 1.0f.pdf
◦ Historias de Usuario
٨ Ciclo
• 22altadeciclo 1.0.doc
• 22altadeciclo 1.0f.pdf
• 23eliminaciondeciclo 1.0.doc
• 23eliminaciondeciclo 1.0f.pdf
• Versiones
٨ Curr´ıcula
• 16altadecurricula 2.7.doc
• 16altadecurricula 2.7f.pdf
• 17actualizaciondecurricula 1.0.doc
Apéndice C. Informe del Estado de Configuración 208

• 17actualizaciondecurricula 1.0f.pdf
• 18eliminaciondecurricula 1.0.doc
• 18eliminaciondecurricula 1.0f.pdf
• 29consultadecurricula 1.0.doc
• 29consultadecurricula 1.0f.pdf
• Versiones
٨ Curso
• 7altadecurso 2.7.doc
• 7altadecurso 2.7f.pdf
• 8actualizaciondecurso 2.7.doc
• 8actualizaciondecurso 2.7f.pdf
• 9eliminaciondecurso 2.7.doc
• 9eliminaciondecurso 2.7f.pdf
• 26consultadecursos 1.0.doc
• 26consultadecursos 1.0f.pdf
• Versiones
٨ Jefe de Enseñanza
• 4altadejefe 1.0.doc
• 4altadejefe 1.0f.pdf
• 5actualizaciondejefe 2.7.doc
• 5actualizaciondejefe 2.7f.pdf
• 6eliminaciondejefe 2.7.doc
• 6eliminaciondejefe 2.7f.pdf
• 25consultadejefes 1.0.doc
• 25consultadejefes 1.0f.pdf
• Versiones
٨ Nombramiento
• 13altadenombramiento 2.7.doc
• 13altadenombramiento 2.7f.pdf
• 14actualizaciondenombramiento 2.7.doc
• 14actualizaciondenombramiento 2.7f.pdf
• 15eliminaciondenombramiento 1.0.doc
Apéndice C. Informe del Estado de Configuración 209

• 15eliminaciondenombramiento 1.0f.pdf
• 28consultadenombramientos 1.0.doc
• 28consultadenombramientos 1.0f.pdf
• Versiones
٨ Profesor
• 1altadeprofesor 2.7.doc
• 1altadeprofesor 2.7f.pdf
• 2actualizaciondeprofesor 2.7.doc
• 2actualizaciondeprofesor 2.7f.pdf
• 3eliminaciondeprofesor 2.7.doc
• 3eliminaciondeprofesor 2.7f.pdf
• 24consultadeprofesores 1.0.doc
• 24consultadeprofesores 1.0f.pdf
• Versiones
٨ Sede
• 10altadesede 1.0.doc
• 10altadesede 1.0f.pdf
• 11actualizaciondesede 1.0.doc
• 11actualizaciondesede 1.0f.pdf
• 12eliminaciondesede 1.0.doc
• 12eliminaciondesede 1.0f.pdf
• 27consultadesedes 1.0.doc
• 27consultadesedes 1.0f.pdf
• Versiones
٨ Usuario
• 19altadeusuario 2.7.doc
• 19altadeusuario 2.7f.pdf
• 20actualizaciondeusuario 1.0.doc
• 20actualizaciondeusuario 1.0f.pdf
• 21eliminaciondeusuario 1.0.doc
• 21eliminaciondeusuario 1.0f.pdf
• 30consultadeusuarios 1.0.doc
Apéndice C. Informe del Estado de Configuración 210

• 30consultadeusuarios 1.0f.pdf
• Versiones
◦ plantillasolicituddecambio 1.0.doc
◦ plantillasolicituddecambio 1.0f.pdf
◦ manualdeusuariopreliminar 1.0.doc
◦ manualdeusuariopreliminar 1.0f.pdf
∗ 3.Arquitectura y Diseño Detallado del Software.
◦ especificacionderequerimientos 1.0.doc
◦ especificacionderequerimientos 1.0f.pdf
◦ diagramadepaquetes 1.0.doc
◦ diagramadepaquetes 1.0f.pdf
◦ diagramadedistribucion 1.0.doc
◦ diagramadedistribucion 1.0f.pdf
◦ basededatos 5.8.doc
◦ basededatos 5.8f.pdf
◦ 1ingresaralsistemaprueba 1.0.doc
◦ 1ingresaralsistemaprueba 1.0f.pdf
◦ Versiones
◦ Historias de Usuario Diseño
Contiene las mismas Historias detalladas en el punto anterior
sólo que éstas incluyen detalles de diseño añadidas por el Equi-
po de Trabajo.
∗ 4.Construcción del Software.
◦ solicituddecambiocpaem 1.0.doc
◦ solicituddecambiocpaem 1.0f.pdf
◦ Versiones
◦ Historias de Usuario Construcción
Contiene las mismas Historias detalladas en el punto anterior
sólo que éstas incluyen detalles de rastreo de construcción de
las mismas añadidas por el Equipo de Trabajo.
∗ 5.Integración y Pruebas del Software.
◦ indicemanualadmincursosfinal 1.0.doc
Apéndice C. Informe del Estado de Configuración 211

◦ indicemanualadmincursosfinal 1.0f.pdf
◦ indicemanualadminsis 1.0.doc
◦ indicemanualadminsis 1.0f.pdf
◦ indicemanualdeusuarioconsulta 1.0.doc
◦ indicemanualdeusuarioconsulta 1.0f.pdf
◦ indicemanualjefefinal 1.0.doc
◦ indicemanualjefefinal 1.0f.pdf
◦ Versiones
◦ Historias de Usuario Construcción
Contiene las mismas Historias detalladas en el punto anterior
sólo que éstas incluyen detalles de las Pruebas llevadas a cabo
por el Cliente y las cuales fueron revisadas por el Equipo de
Trabajo.
∗ 6.Entrega de Productos.
◦ entregafinal 1.0.doc
◦ entregafinal 1.0f.pdf

ø Interfaz

⬦ index.html
⬦ menu ciclos.html
⬦ menu.html
⬦ plantilla consultas.html
⬦ plantilla movimientos.html
⬦ plantilla reportes.jasper

ø NetBeans

⬦ index.jsp
⬦ index proceso.jsp
⬦ menu.jsp
⬦ salir.jsp
⬦ style.css
⬦ AJAX
∗ ajax consuta.js
Apéndice C. Informe del Estado de Configuración 212

∗ ajax masDetalle.js
⬦ ReportesPDF
∗ cursos
◦ curso institucion sede.jasper
◦ curso institucion sede.jrxml
◦ curso institucion.jasper
◦ curso institucion.jrxml
◦ cursos sin filtro.jasper
◦ cursos sin filtro.jrxml
∗ jefes
◦ jefe institucion.jasper
◦ jefe institucion.jrxml
◦ jefe filtro institucion.jasper
◦ jefe filtro institucion.jrxml
◦ jefe filtro institucion sede.jasper
◦ jefe filtro institucion sede.jrxml
◦ jefes sin filtro.jasper
◦ jefes sin filtro.jrxml
∗ nombramientos
◦ profesores con.jasper
◦ profesores con.jrxml
◦ profesores sin.jasper
◦ profesores sin.jrxml
◦ nombramiento de profesor.jasper
◦ nombramiento de profesor.jrxml
∗ profesores
◦ profesores filtro especialidad.jasper
◦ profesores filtro especialidad.jrxml
◦ profesores filtro especialidad sede.jasper
◦ profesores filtro especialidad sede.jrxml
◦ profesores filtro sede.jasper
◦ profesores filtro sede.jrxml
Apéndice C. Informe del Estado de Configuración 213

◦ profesores filtro sede especialidad.jasper

◦ profesores filtro sede especialidad.jrxml
◦ profesores sin filtro.jasper
◦ profesores sin filtro.jrxml
∗ sedes
◦ sedes curso institucion.jasper
◦ sedes curso institucion.jrxml
◦ sedes filtro curso.jasper
◦ sedes filtro curso.jrxml
◦ sedes filtro institucion.jasper
◦ sedes filtro institucion.jrxml
◦ sedes filtro institucion curso.jasper
◦ sedes filtro institucion curso.jrxml
◦ sedes sin filtro.jasper
◦ sedes sin filtro.jrxml
∗ generaPDF.jsp
⬦ WEB-INF
⬦ ciclos
∗ proceso menuciclos.jsp
∗ menuciclos.jsp
∗ menuciclos proceso.jsp
⬦ consultas
∗ cursos
◦ menu consulta Curso.jsp
◦ ajax detalleCurso.jsp
◦ ajax masDetalleCurso.jsp
∗ jefes
◦ menu consulta Jefe.jsp
◦ ajax detalleJefe.jsp
◦ ajax masDetalleJefe.jsp
∗ curriculas
Apéndice C. Informe del Estado de Configuración 214

◦ menu consulta Curricula.jsp

◦ ajax detalleCurricula.jsp
∗ nombramientos
◦ menu consulta Nombramiento.jsp
◦ ajax detalleNombramiento.jsp
∗ profesores
◦ menu consulta Profesor.jsp
◦ ajax detalleProfesor.jsp
◦ ajax masDetalleProfesor.jsp
∗ sedes
◦ menu consulta Sede.jsp
◦ ajax detalleSede.jsp
◦ ajax masDetalleSede.jsp
∗ proceso consultas.jsp
⬦ movimientos
∗ cursos
◦ menu movimiento Curso.jsp
◦ proceso menu movimiento Curso.jsp
◦ menu movimiento Curso proceso.jsp
∗ jefes
◦ menu movimiento Jefe.jsp
◦ proceso menu movimiento Jefe.jsp
◦ menu movimiento Jefe proceso.jsp
∗ curriculas
◦ menu movimiento Curricula.jsp
◦ proceso menu movimiento Curricula.jsp
◦ menu movimiento Curricula proceso.jsp
∗ nombramientos
◦ menu movimiento Nombramiento.jsp
◦ proceso menu movimiento Nombramiento.jsp
◦ menu movimiento Nombramiento proceso.jsp
Apéndice C. Informe del Estado de Configuración 215

∗ profesores
◦ menu movimiento Profesor.jsp
◦ proceso menu movimiento Profesor.jsp
◦ menu movimiento Profesor proceso.jsp
∗ sedes
◦ menu movimiento Sede.jsp
◦ proceso menu movimiento Sede.jsp
◦ menu movimiento Sede proceso.jsp
∗ proceso movimientos.jsp
⬦ scripts
∗ Scripts.js
⬦ Source Packages
∗ ajax.bean
◦ AcademicoBean.java
◦ CursoBean.java
◦ EstadoBean.java
◦ SedeBean.java
◦ detalleBean.java
◦ masDetalleBean.java
◦ detalleAjaxBean.java
∗ ajax.dao
◦ detalleAjaxDao.java
◦ masDetalle.java
◦ filtro.java
∗ ajax.logic
◦ ajaxBo.java
∗ control
◦ Ciclo.java
◦ Control.java
◦ Curso.java
◦ Jefe.java
Apéndice C. Informe del Estado de Configuración 216

◦ Nivel.java
◦ Profesor.java
◦ Sede.java
◦ Nombramiento.java
◦ Curricula.java
∗ datos
◦ Conexion.java
⬦ Libraries
⬦ Configuration Files
∗ MANIFEST.MF

C.10. Respaldo del Repositorio del Proyecto.

La Norma ISO/IEC 29110 nos indica lo siguiente sobre el Respaldo del Reposi-
torio del Proyecto: Repositorio usado para respaldar el Repositorio del Proyecto, y
en caso necesario recuperar la información [7].
Durante el desarrollo del proyecto el respaldo se llevaba a cabo cada que un módulo
era terminado, el Equipo de Trabajo realizaba copias del repositorio del proyecto en
el equipo de trabajo y dos unidades de almacenamiento extraible. En una de ellas, la
perteneciente al Administrador del Proyecto, se añadı́a un archivo nombra- do
README.txt que contenı́a la información del avance del proyecto y la fecha en que
se realizaba el respaldo.

C.11. Especificación de Requerimientos.

La Norma ISO/IEC 29110 especifica que la Especificación de Requerimientos
puede contener la siguiente información:

• Introducción descripción general del software y dentro del ámbito de negocio

del cliente;

• Descripción de requerimientos:
Apéndice C. Informe del Estado de Configuración 217

ø Funcionalidad - necesidades que debe satisfacer el software cuando se usa

en condiciones especı́ficas. La funcionalidad debe ser adecuada, precisa y
segura.
ø Interfaz de usuario - definición de las caractersticas de la interfaz de usua-
rio que permitan comprender y aprender el uso de software fácilmente para
que el usuario sea capaz de realizar sus tareas eficientemente. Incluye la
descripcion del modelo de interfaz.
ø Interfaces externas - definición de las interfaces con otro software o hard-
ware.
ø Fiabilidad - especificación del nivel de ejecucin de software referente a su
madurez, tolerancia a fallas y recuperación.
ø Eficiencia - especificación del nivel de ejecucin del software en relación con
el tiempo y el uso de los recursos.
ø Mantenimiento - descripción de los elementos para facilitar la comprensión
y ejecución de futuras modificaciones del software.
ø Portabilidad - descripción de las caracterı́sticas de software que permiten
transferirlo de un lugar a otro.
ø Diseño y construcción de las limitaciones/restricciones - necesidades im-
puestas por el cliente.
ø Interoperabilidad - Capacidad para usar o intercambiar información entre
dos o más sistemas o componentes de software.
ø Reutilización caracterı́stica de cualquier producto o subproducto o de
alguna de sus partes, para ser utilizado por varios usuarios como un pro-
ducto final, en el desarrollo o ejecución de otros productos de software.
ø Legales y regulativos - necesidades impuestas por las leyes, regulaciones,
etc [7].

A excepción de dos módulos que fueron realizados mediante Casos de Uso (in-
gresar al sistema y salir del sistema), el resto se realizó mediante metodologı́a ágil.
Al final de este Apéndice se añaden las imagenes C.9 y C.10 que permiten ver la
manera en que se cumplió con ésta y otras tareas del desarrollo.
Apéndice C. Informe del Estado de Configuración 218

C.12. Software.
La Norma ISO/IEC 29110 nos indica lo siguiente sobre el Software: Elemento
de software (código fuente y código ejecutable) para un cliente, integrado por un
conjunto de Componentes de Software [7].
De acuerdo a lo indicado por la Norma, el Software se entregó en el Repositorio del
Proyecto (código fuente) y el ejecutable estará alojado en la dirección:
www.sidep.fmposgrado.unam.mx:8080/sidep.v.2.0/

C.13. Componente de Software.

La norma ISO/IEC 29110 describe el Componente de Software como: Conjunto
de unidades de código relacionadas [7]. Para el desarrollo llevado a cabo por el Equipo
de Trabajo y dado que los detalles del sofware fueron especificados mediante Historias
de Usuario, las pruebas unitarias fueron ejecutadas de acuerdo a lo que el Equipo de
Trabajo entendió en cada una de las Historias de Usuario generadas, en caso de que
la prueba fuera exitosa, se liberaba el módulo. Para relacionar las unidades de código,
se añadieron a las Historias de Usuario registros de rastreo por parte del Equipo de
Trabajo, al final del Apéndice se muestran las figuras C.9 y C.10 ejemplificando ésta
y otras secciones del Apéndice.

C.14. Configuración de Software.

De acuerdo a la Norma ISO/IEC 29110, esta sección deberá incluir:

• Especificacion de Requerimientos.
• Diseño de Software.
• Registro de Rastreo.
• Componentes de Software.
• Software.
• Casos y Procedimientos de Prueba.
• Reporte de Pruebas / Resultados de la Pruebas.
Apéndice C. Informe del Estado de Configuración 219

• Manual de Operación.
• Manual de Usuario.
• Manual de Mantenimiento

El Desarrollo cumplió con lo especificado por la Norma de distintas maneras, la Es-

pecificación de Requermientos se llevo a cabo mediante Historias de Usuario, además
el Equipo de Trabajo aprovechó las constantes reuniones con el Administrador del
Proyecto y Cliente para aclarar dudas de la lógica del negocio, estas Historias de
Usuario no sólo permitieron lograr el primero de los puntos que indica la Norma
sino que también sirvieron para el Diseño del Software, Registro de Rastreo, identi-
ficación de los Componentes del Software, ejecución de Casos y Procedimientos de
Prueba, Reportear y mostrar Resultas de las Pruebas, estos puntos llevados a cabo
por el Equipo de Trabajo mediante la agregación de los comentarios respectivos en
las Historias de Usuario. Al final del Apéndice se muestran las figuras C.9 y C.10
ejemplificando ésta y otras secciones del Apéndice.
Los Manuales se pueden ver en las figuras B.11, B.12, B.13 del Apéndice B y en la
figura 10.3 del Capı́tulo 9. Integración y Pruebas del Software que indica la sección
extra que completa el Manual de Operación.

C.15. Diseño de Software.

La Norma ISO/IEC 29110 indica que el contenido del Diseño de Software ser
puede dividir en dos y propone:

• Diseño Arquitectónico del Software (alto nivel) - Describe laestructura global

del Software:

ø Identifica los Componentes de Software requeridos.

ø Identifica las relaciones entre los Componentes de Software.
ø Consideraciones requeridas:
ø caracterı́sticas de desempeño de software.
ø hardware, software e interfaces humanas.
ø caracter´ısticas de seguridad.
Apéndice C. Informe del Estado de Configuración 220

ø requerimientos de diseño de base de datos.

ø manejo de errores y atributos de recuperación.

• Diseño Detallado del Software (bajo nivel) - incluye detalles de los Componen-
tes de Software para facilitar su construcción y prueba dentro del ambiente de
desarrollo:

ø Proporciona detalle del diseño (puede ser representado como un prototipo,

diagrama de flujo, diagrama entidad-relación, pseudo código, etc.)
ø Proporciona el formato de entrada / salida de los datos.
ø Proporciona la especificaciones del almacenamiento de los datos.
ø Establece convenciones de nombrado de los datos.
ø Define el formato de las estructuras de datos.
ø Define los campos de datos y el propósito de cada elemento de los datos.
ø Proporciona las especificaciones de la estructura del programa

De acuerdo a lo que la Norma sugiere y dado que se llevó un diseño basado en

Historias de Usuario que el Cliente generó, al final del Apéndice se muestran las
figuras C.9 y C.10 a manera de ejemplo que justifican el seguimiento de la Norma,
además se pueden observar en la figura 5.23 del Capı́tulo 4. el estándar de codificación
utilizado para este proyecto. Además en la sección 7.3 del Capı́tulo 7. Arquitectura y
Diseño Detallado del Software se tiene una explicación detallada de las caracterı́sticas
del software, con esto se puede asegurar el seguimiento de la Norma.

C.16. Manual de Usuario.

La Norma nos proporciona la siguiente lista de la información que puede contener
el Manual de Usuario:

• - Procedimientos del usuario para realizar tareas especı́ficas utilizando el Soft-

ware.
• Procedimientos de instalación y desinstalación.
• Breve descripción del uso previsto del Software (el concepto de operaciones).
Apéndice C. Informe del Estado de Configuración 221

• Los recursos provistos y requeridos.

• Entorno operacional requerido.

• Facilidad para reportar problemas y asistencia.

• Procedimientos para acceder y salir del Software.

• Relación y explicación de los comandos del Software y de los mensajes del

sistema hacia el usuario.

• Advertencias, precauciones y notas para identificar riesgos y su forma de co-

rrección.

• Incluye procedimientos para solución de problemas y corrección de errores.

El Equipo de Trabajo realizó el Manual de Usuario de acuerdo a las necesidades

especificadas por el Cliente, los ´ındice de los Manuales de Usuario se pueden observar
en la figuras B.11, B.12 y B.13.

C.17. Enunciado de Trabajo.

De acuerdo a la Norma ISO/IEC 29110 éste puede incluir:

• Descripción del producto:

ø Propósito
ø Requerimientos generales del cliente.

• Alcance, que describa que sı́ incluye y qué no.

• Objetivos del proyecto.

• Entregables, lista de productos a entregar al cliente.

Para justificar el seguimiento de la Norma se puede ver el Cap´ıtulo 3. Planteamiento

del Problema en su totalidad, el cual representa todos los puntos además de la figura
5.5 del Capı́tulo 4. Planeación del Proyecto.
Apéndice C. Informe del Estado de Configuración 222

C.18. Casos y Procedimientos de Prueba.

La Norma ISO/IEC 29110 nos indica que los Casos de prueba pueden incluir:

• Identificación del caso de prueba.

• Elementos a probar.
• Especificaciones de entrada.
• Especificaciones de salida.
• Ambiente requerido.
• Requerimientos de procedimientos especiales.
• Dependencias de interfaz.

y que los Procedimientos de Prueba pueden incluir:

• Identificación de: nombre de la prueba, descripción de la prueba y la fecha de

terminación de prueba.
• Identificacin de posibles problemas de aplicación.
• Nombre de la persona que realiza el procedimiento de prueba.
• Identificación de los requerimientos previos.
• Identificación de los pasos del procedimiento, incluyendo el número de paso, la
acción requerida por el probador y los resultados esperados.

En este desarrollo, los Casos y Procedimientos de Prueba fueron llevados a cabo

de manera ágil mediante la prueba de cada una de las Historia de Usuario generadas
por parte del Cliente, las mismas guiaron al Equipo de Trabajo para el diseño y
construcción de cada uno de los módulos del sistema, al final del Apéndice se puede
observar una imagen que detalla la forma en que se llevaron a cabo los Casos y
Procedimientos de Prueba.

C.19. Reporte de Pruebas.

El Cliente probó cada uno de los módulos verificando que se cumpliera lo descrito
en las Historias de Uso especificando los datos de entrada y la salida esperada, en caso
Apéndice C. Informe del Estado de Configuración 223

de encontrar alguna falla o querer dejar un comentario éste era añadido a la Historia
de Usuario en la sección respectiva, permitiendo al Equipo de Trabajo corregir el
error para realizar una segunda prueba y poder liberar el módulo en caso de que
la corrección del módulo fuera exitosa. Al final del Apéndice se pueden observar las
imagenes C.9 y C.10 que muestran la manera en que ésto se llevó a cabo, permitiendo
as´ı cumplir con las sugerencias de la Norma ISO/IEC 29110 las cuales nos indican
que el Reporte de Pruebas puede contener:

• Un resumen de cada defecto.

• Identificación del caso de prueba en cuestión.

• Nombre del probador que encontró cada defecto.

• Severidad de cada defecto.

• Identificacion de la(s) función(es) afectada(s) por cada defecto.

• Fecha en que cada defecto fue originado.

• Fecha en que cada defecto fue resuelto.

• Nombre de la persona quin resolvi cada defecto.

C.20. Rastreo.
La Norma ISO/IEC 29110 nos indica que el Rastreo puede incluir:

• Especificación de los requerimientos por rastrear.

• Proporciona el mapeo (hacia adelante y hacia atrás) de los requerimientos a

los elementos del Diseño de Software, los Componentes de Software, los Casos
de Prueba y los Procedimientos de Prueba.

El Equipo de Trabajo llevó a cabo el Rastreo dentro de las Historias de Usuario,

como se podrá ver al final del Apéndice en las figuras C.9 y C.10, el Rastreo se
añadió a las mismas al final de cada una de las Historias de Usuario.
Apéndice C. Informe del Estado de Configuración 224

C.21. Listas de Verificación.

La Norma ISO/IEC 29110 dice que las Listas de Verificación pueden incluir:

• Participantes.
• Fecha.
• Lugar.
• Duracin.
• Lista de verificacin.
• Elementos aprobados.
• Elementos no aprobados.
• Elementos pendientes de verificar.
• Defectos identificados durante la verificacin.

Al ser un desarrollo guiado por Historias de Usuario, la verificación se llevó a cabo

en las mismas y la realizó el Cliente, al final del Capı́tulo se verá ejemplificado esto
en las figuras C.9 y C.10.

C.22. Listas de Validación

Al igual que las Listas de Verificación la Norma ISO/IEC 29110 nos indica que
las Listas de Validación pueden incluir:

• Participantes.
• Fecha.
• Lugar.
• Duración.
• Lista de verificación.
• Elementos aprobados.
• Elementos no aprobados.
Apéndice C. Informe del Estado de Configuración 225

• Elementos pendientes de validar.

• Defectos identificados durante la validación.

De la misma manera que sucedió con las Listas de Verificación, las Listas de Valida-
ción se llevaron a cabo de manera ágil. Ası́ en el ejemplo siguiente mostrado en las
figuras C.9 y C.10 se puede ver ésta y las secciones mencionadas a ejemplificar con
la Historia de Usuario.
Apéndice C. Informe del Estado de Configuración 226

Figura C.9: Historia de Usuario que ejemplifica las diversas tareas ejecutadas durante
el Desarrollo del Proyecto.
Apéndice C. Informe del Estado de Configuración 227

Figura C.10: Historia de Usuario que ejemplifica las diversas tareas ejecutadas du-
rante el Desarrollo del Proyecto.
Bibliografı́a

[1] David J. Anderson. Kanban: Successful Evolutionary Change for Your Techno-
logy Business. Blue Hole Press, 2010.

[2] Mike Cohn. Agile Estimating and Planning. Prentice Hall, 2006.

[3] División de Estudios de Posgrado de la Facultad de Medicina de la Universidad

Nacional Autónoma de México. División de estudios de posgrado. facultad de
medicina, unam. http://www.fmposgrado.unam.mx, 2013. Visitado: 2013-07-
01.

[4] Jesse James Garrett. Ajax: A new approach to web applications.

http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/,
2005. Visitado: 2013-10-10.

[5] Watts S. Humphrey. PSP: A Self-Improvement Process for Software Engineers.

Pearson, 2005.

[6] IBM. Ibm rational unified process (rup). http://www-

01.ibm.com/software/rational/rup/, 2013. Visitado: 2013-07-01.

[7] ISO/IEC. Software engineering lifecycle profiles for very small entities (vses)
part 5-1-1: Management and engineering guide:generic profile group: Entry pro-
file, 2012. ISO/IEC TR 29110-5-1-1 Technical Report.

[8] Rumbaugh J. Jacobson I., Booch G. El Proceso Unificado de Desarrollo de

Software. Pearson, 2000.

[9] Carnegie Mellon. SEI Report on Undergraduate Software Engineering Educa-

tion. Sofware Engineering Institute, 1990.

228
Bibliograf´ıa 229

[10] Peter Hughes Paul Fisher, James Mc Daniel. System development life cycle
models and methodologies, 2010. Canadian Society for International Health
Certificate Course in Health Information Systems Module 3: System Analysis and
Database Development Part 3: Life Cycle Models and Methodologies.

[11] Ken Schwaber. Agile Project Management with Scrum. Microsoft Press, 2004.

[12] IEEE Computer Society. IEEE Standard Glossary of Software Engineering Ter-
minology. IEEE STD 610.12-1990, 1990.

[13] Jeff Ullman y Jennifer Widom. First Course in Database Systems 3er.Ed. Pren-
tice Hall, 2008.

[14] Wang Y. Software Engineering Foundations: A Software Science Perspective.

Auerbach Publications, 2008.