Software Project

Management Plan
Caracterización de la comunidad

29/06/2012
Fabián García
Ariel López
 PAGINA DE FIRMAS

ALEX LINARES
CLIENTE

FABIÁN GARCÍA

ARIEL LÓPEZ LESMES

 HISTORIAL DEL CAMBIOS

Versión Fecha Sección del Descripción del Responsable

documento cambio
1.0.0 19-06-2012 1-4 Creación de la Ariel López
sección
1.1.0 25-06-2012 7 Creación de la Ariel López
sección
1.2.0 26-06-2012 5,6 Creación de la Fabián García
sección
2.0.0 27-06-2012 Todo el Revisión del Ariel López
documento documento Fabián García
Tabla 1: Historial de cambios
 PREFACIO

Este documento presenta el Plan de Administración de Proyecto de Software (SPMP por sus
siglas en ingles) que describe la organización del equipo de trabajo, los diferentes planes
técnicos y administrativos, así como otra serie de documentos que servirán como base para el
desarrollo de un sistema de información de consulta y edición de los datos correspondientes a
la situación socioeconómica y cultural de las 17 familias PROSOFI.

Este plan está desarrollado según la plantilla SPMP de IRONWORK [1] [2] [3], con ligeras
adaptaciones. Este documento estará dirigido al Ing. Alex Linares representante de PROSOFI
[24] donde se desarrolla el proyecto de caracterización de la comunidad.
Contenido
1 VISIÓN GENERAL DEL PROYECTO ............................................................................................... 9
1.1 RESUMEN DEL PROYECTO ................................................................................................... 9
1.1.1 Propósito ...................................................................................................................... 9
1.1.2 Alcance ......................................................................................................................... 9
1.1.3 Objetivos ...................................................................................................................... 9
1.1.4 Suposiciones y restricciones......................................................................................... 9
1.1.5 Entregables del proyecto ........................................................................................... 10
1.1.6 Resumen de calendarización y presupuesto. ............................................................. 10
1.2 EVOLUCIÓN DEL PLAN ....................................................................................................... 11
2 REFERENCIAS ............................................................................................................................ 11
3 DEFINICIONES Y ACRÓNIMOS .................................................................................................. 12
3.1 DEFINICIONES .................................................................................................................... 12
3.2 ACRÓNIMOS ...................................................................................................................... 12
4. ORGANIZACIÓN DEL PROYECTO .............................................................................................. 13
4.1 INTERFACES EXTERNAS ..................................................................................................... 13
4.2 ESTRUCTURA INTERNA ...................................................................................................... 13
4.3 ROLES Y RESPONSABILIDADES........................................................................................... 14
5. PLAN DE PROCESOS DE GESTIÓN ............................................................................................ 16
5.1 PLAN DE ARRANQUE ......................................................................................................... 16
5.1.1 Plan de Estimación ..................................................................................................... 16
5.1.2 Plan de Personal ......................................................................................................... 16
5.1.3 Plan de Entrenamiento de Personal........................................................................... 17
5.2 PLAN DE TRABAJO ............................................................................................................. 17
5.2.1 Actividades de Trabajo ............................................................................................... 18
5.2.2 Cronograma ................................................................................................................ 21
5.2.3 Asignación De Recursos.............................................................................................. 21
5.2.4 Asignación De Presupuesto ........................................................................................ 21
5.3 PLAN DE CONTROL ........................................................................................................ 22
5.3.1 Plan de Control de requerimientos ............................................................................ 22
5.3.2 Plan de Control de cronograma ................................................................................. 22
5.3.3 Plan de Control de Presupuesto ................................................................................. 25
5.3.4 Plan de Control de Calidad ......................................................................................... 25
5.4 Plan de administración de riesgos..................................................................................... 27
 5.4.1 Objetivos .................................................................................................................... 27
5.4.2 Ejecución del plan....................................................................................................... 27
5.4.3 Tipificación de los riesgos........................................................................................... 27
5.4.4 Priorización de los riesgos .......................................................................................... 29
5.4.5 Riesgos........................................................................................................................ 31
5.5 Plan de cierre..................................................................................................................... 31
5.5.1 Objetivos ............................................................................................................. 31
5.5.2 Actividades .......................................................................................................... 31
6 PLAN DE PROCESOS TÉCNICOS................................................................................................. 32
6.1 MODELO DE CICLO DE VIDA DEL PROCESO ....................................................................... 32
6.2 METODOS, HERRAMIENTAS Y TÉCNICAS .......................................................................... 33
6.2.1 Herramientas.............................................................................................................. 33
6.2.2 licencias ...................................................................................................................... 33
6.4 PLAN DE ACEPTACION DEL PRODUCTO ............................................................................ 33
6.4.2 Objetivo ...................................................................................................................... 33
6.4.3 Alcance ....................................................................................................................... 33
6.4.4 Responsabilidades ...................................................................................................... 34
6.4.5 Actividades de aceptación de producto ..................................................................... 34
6.4.6 Cronograma ................................................................................................................ 35
6.4.9 Entorno de aceptación de producto .......................................................................... 35
7 PLAN DE PROCESOS DE SOPORTE ............................................................................................ 35
7.1 PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN ....................................................... 35
7.1.1 Introducción ............................................................................................................... 35
7.1.2 Objetivo ...................................................................................................................... 35
7.1.3 Alcance ....................................................................................................................... 35
7.1.4 Administración de la configuración............................................................................ 36
7.1.5 Control de cambios .................................................................................................... 36
7.1.6 Contabilidad del estado ............................................................................................. 36
7.2 PLAN DE VERIFICACIÓN Y VALIDACIÓN ............................................................................. 37
7.2.1 Introducción ............................................................................................................... 37
7.2.2 Objetivos .................................................................................................................... 37
7.2.3 Actividades del plan de verificación y validación ....................................................... 37
7.2.4 Riesgos........................................................................................................................ 37
7.3 PLAN DE DOCUMENTACIÓN .............................................................................................. 38
 7.3.1 Introducción ............................................................................................................... 38
7.3.2 Objetivos .................................................................................................................... 38
7.3.3 Definición de plantillas y estándares.......................................................................... 38
7.3.4 Definición de documentos entregables y responsables ............................................ 38
7.3.5 Riesgos........................................................................................................................ 39
7.4 PLAN DE ASEGURAMIENTO DE CALIDAD .......................................................................... 39
7.4.1 Objetivos .................................................................................................................... 39
7.4.2 Responsables .............................................................................................................. 40
7.4.3 Plan de Pruebas .......................................................................................................... 40
 ÍNDICE DE ILUSTRACIONES

Ilustración 1: Interfaces externas ................................................................................................ 13

Ilustración 2; Control del cronograma ........................................................................................ 24
Ilustración 3: Avance del proyecto .............................................................................................. 24
Ilustración 4: Plantillas y estandares ........................................................................................... 38
Ilustración 5: Entregables ............................................................................................................ 39
 ÍNDICE DE TABLAS

Tabla 1: Historial de cambios ........................................................................................................ 2

Tabla 2: Cronograma general ...................................................................................................... 10
Tabla 3: Definiciones ................................................................................................................... 12
Tabla 4: Acrónimos ...................................................................................................................... 13
Tabla 5: Rol Administrador del proyecto .................................................................................... 14
Tabla 6: Rol Director de desarrollo ............................................................................................. 14
Tabla 7:Rol Arquitecto y diseñador ............................................................................................. 15
Tabla 8: Rol Director de calidad y manejo de riesgos ................................................................. 15
Tabla 9: Responsabilidades ......................................................................................................... 17
Tabla 10: Trabajo ......................................................................................................................... 18
Tabla 11: Reglas de grupo ........................................................................................................... 18
Tabla 12: Desarrollo SPMP .......................................................................................................... 19
Tabla 13: Desarrollo IPA1 ........................................................................................................... 19
Tabla 14: Digitación de encuestas ............................................................................................... 19
Tabla 15: Creación base de datos ............................................................................................... 19
Tabla 16: Desarrollo IPA2 ........................................................................................................... 20
Tabla 17: implementación de la aplicación ................................................................................. 20
Tabla 18: Desarrollo IPA 3 ........................................................................................................... 20
Tabla 19: Personal ....................................................................................................................... 21
Tabla 20: Recursos ...................................................................................................................... 22
Tabla 21: Riesgos y tipos de riesgos ........................................................................................... 29
Tabla 22: Matriz de riesgos ......................................................................................................... 30
Tabla 23: Análisis de riesgos........................................................................................................ 30
1 VISIÓN GENERAL DEL PROYECTO

1.1 RESUMEN DEL PROYECTO

1.1.1 Propósito

El propósito de este proyecto es digitalizar la información recolectada sobre la situación

socioeconómica y cultural de las 17 familias PROSOFI y desarrollar una base de datos que
almacene dicha información. Esta base de datos se validará a través de una aplicación que
permita hacer consultas y modificaciones sobre la información almacenada en la base de datos.

El proyecto se desarrollará teniendo como base la metodología de desarrollo de software

“Extreme Programing” [4]

1.1.2 Alcance

El alcance de este proyecto es desarrollar un archivo que contenga la información de las

encuestas sobre la situación socioeconómica y cultural de las 17 familias PROSOFI, que pueda
ser utilizado para alimentar una base de datos relacional.

Además se desarrollará una base de datos que se alimente de dicha información y una
aplicación web que permita hacer consultas y modificaciones sobre la información en la base
de datos. La base de datos será creada según el modelo de datos que fue facilitado por el
cliente.

1.1.3 Objetivos

1. Digitalizar la información de las encuestas sobre la situación socioeconómica y cultural

de las 17 familias PROSOFI.
2. Desarrollar una base de datos siguiendo el diccionario de datos entregado por el
cliente.
3. Desarrollar una aplicación web que permita validar el funcionamiento de la base de
datos.

1.1.4 Suposiciones y restricciones

Para el desarrollo de este proyecto las siguientes suposiciones y restricciones están definidas:

• El cliente proporcionara el diccionario de datos según el cual se debe desarrollar la

base de datos.
• El cliente proporcionara las encuestas físicas aplicadas a las 17 familias PROSOFI.
• La fecha de entrega del proyecto es el viernes 13 de julio de 2012.
 • Las herramientas escogidas para la realización de las aplicaciones, son de software
libre, luego su licencia permite su libre uso y distribución.
• Los recursos económicos del equipo son limitados por lo que no se harán grandes
inversiones de dinero en este proyecto.

1.1.5 Entregables del proyecto

Este proyecto tendrá los siguientes entregables para el cliente:

1. Software Project Management Plan.

2. Software Requirement Specification
3. Software Design Document
4. Base de datos, aplicación web y documentación.

1.1.6 Resumen de calendarización y presupuesto.

Debido a que el presente proyecto se desarrolla en marco del curso de Proyecto Social
Universitario ofrecido por el Departamento de Ingeniería de Sistemas, Facultad de Ingeniería
de la Pontificia Universidad Javeriana, no se cuenta con un presupuesto para su desarrollo, sin
embargo se hice el ejercicio de calcular algunos gastos en los que se incurrirá ver sección 5.3.3
plan de control de presupuesto. Los integrantes del grupo desarrollarán el proyecto sin esperar
ningún tipo de retribución económica, y no se usará ningún recurso más que los computadores
personales de los integrantes del grupo.

Se ha estimado un total de 58 horas de trabajo para cada uno de los integrantes del grupo,
distribuidas de la siguiente forma:

Actividad Descripción Tiempo Estimado

1. Diagnostico
2. Construcción SPMP
3. Construcción SRS
4. Construcción SDD
5. Digitalización
encuestas
6. Desarrollo
Reunión con el cliente para 2 horas
determinar las necesidades y
expectativas.
Desarrollo del SPMP para el 12 horas
proyecto.
Desarrollo del SDD para el 6 horas
proyecto.
Desarrollo del SAD para el 6 horas
proyecto.
Desarrollo del archivo digital 20 horas
que contenga la información
de las encuestas
Desarrollo de la aplicación 22 horas
web y base de datos.
Tabla 2: Cronograma general
1.2 EVOLUCIÓN DEL PLAN

La evolución del plan hace referencia a la manera cómo vamos a mantener consistentes sus
productos de trabajo y el avance del proyecto.

Todos los documentos generados en este proyecto se basarán en las plantillas de IRONWORK
[1] [2] [3] Se debe tener en cuenta que estas plantillas serán modificadas, reducidas, según sea
necesario. El desarrollo de los artefactos definidos en el proyecto se realizara según los
parámetros establecidos en este documento.

2 REFERENCIAS

[1] IronWorks, Plantilla SPMP, Pontificia Universidad Javeriana ed., 2008.

[2] IronWorks, SDD Linea Base.: Pontificia Universidad Javeriana, 2008.

[3] IronWorks, SRS Linea Base., 2008.

[4] William Wake, Extreme Programming Explored.: Addison-Wesley, 2002.

[5] Roy K. Clemmons, Project estimation with use case points., 2006.

[6] IEEE, Software Engineering Body of Knowledge SWEBOK., 2004.

[7] ISO 9001:2000, "Quality Management Systems — Requirements, ISO," 2000.

[8] IBM. (2011) Rational Unified Process (RUP). [Online]. "http://www-

01.ibm.com/software/awdtools/rup/" http://www-
01.ibm.com/software/awdtools/rup/

[9] RUP. (2011) Configuration Management Plan. [Online].

"http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_cmpln.htm"
http://www.ts.mah.se/RUP/RationalUnifiedProcess/process/artifact/ar_cmpln.htm

[10] Dropbox. (2011) Dropbox. [Online]. "https://www.dropbox.com/"

https://www.dropbox.com/

[12] Google. (2011) Google Project. [Online].

"https://plus.google.com/up/start/?et=sw&type=st"
https://plus.google.com/up/start/?et=sw&type=st

[13] tigris. (2012) subclipse. [Online]. "http://subclipse.tigris.org/"

http://subclipse.tigris.org/

[14] Ian Sommerville, Ingenieria de Software, Pearson, Ed., 2005.

[15] IEEE, Project Management Body of Knowledge (PMBOK), Project Management
Institute, Inc, 3rd ed., 2004.

[16] E. Tello. (Diciembre 2008). Monitorización y Control del Proyecto [En Línea].
Disponible:http://www.slideshare.net/sagu559/monitorizacion-y-control-del-proyecto

[17] J. A. Pavlich and A. López, “SARE: Security Assurance for Roundtrip Engineering.”
[Online]. Available: http://code.google.com/p/sare/. [Accessed: 02-May-2012].

[18] Sun Microsystems, “The Java EE 5 Tutorial”, Available:

http://java.sun.com/javaee/5/docs/tutorial/doc. [Accessed: 18-May-2012].

[19] JBoss Seam Group, “Reference manuals of JBoss Seam”, Available:

http://seamframework.org [Accessed: 18-May-2012].

[20] IEEE SOFTWARE, What’s Good Software, Anyway? Hakan Erdogmus., 2007.

[21] Sparx Systems, Enterprise Architect [Online].

http://www.sparxsystems.com.au/products/ea/index.html [Accessed: 18-Jun-2012].

[22] PostgreSQL [Online] http://www.postgresql.org/ [Accessed: 18-Jun-2012].

[23] B Bruegge, Ingeniería de Software Orientado a Objetos.: Prentice Hall, 2002

[24] Prosofi – Programa Social Facultad de Ingenieria. http://puj-

portal.javeriana.edu.co/portal/page/portal/Facultad%20de%20Ingenieria/plt_facultad/Prosofi

3 DEFINICIONES Y ACRÓNIMOS

3.1 DEFINICIONES

Término Definición
Encuesta Documento entregado por el cliente al grupo, en el cual se
plasma cierta información recolectada de las familias PROSOFI
PROSOFI Programa social de la facultad de ingeniería
Entrega Se entiende por entrega el momento en que se presentan los
avances del proyecto al cliente, con fin de recibir
retroalimentación en el proceso de desarrollo
Caso de uso Descripción de los pasos y actividades que se deben realizar
Tabla 3: Definiciones

3.2 ACRÓNIMOS

Acrónimo Definición
 SPMP Software proiect management plan
SRS Software Requirements document
SDD Software Design Document
XP Extreme programing
RUP Rational Unified Process
SVN Subversion
IEEE Institute of Electrical and Electronics Engineers
Tabla 4: Acrónimos

4. ORGANIZACIÓN DEL PROYECTO

4.1 INTERFACES EXTERNAS

Ing. Alex Linares Ing. Blanca Perez Ing. Blanca Oviedo

Ilustración 1: Interfaces externas

• El Ing. Alex Linares Bautista tiene el rol del cliente, dado que es la persona que nos brindará
los lineamientos que debemos seguir para ciertos aspectos técnicos y para el desarrollo del
proyecto. Sera quien nos entregue los requerimientos y restricciones para el desarrollo del
proyecto.

• La Ing. Blanca Elvira Oviedo también tiene el rol del cliente, debido a que es aquella persona
que establece los lineamientos y reglas que se deben seguir para el desarrollo de la Asignatura
de Proyecto Social Universitario para Ingeniería de Sistemas dentro de la Pontificia Universidad
Javeriana.

•La profesora Blanca Cecilia Pérez, nos brinda información acerca de la comunidad desde el
punto de vista de la Pontificia Universidad Javeriana y nos establece de manera clara y concisa
el alcance que debe tener la práctica social.

4.2 ESTRUCTURA INTERNA

El proyecto será desarrollado siguiendo la metodología XP [4] con esto esperamos asignar la
mismo cantidad de responsabilidad sobre cada integrante. Cada integrante se encargara en
general de ciertas áreas del proceso de desarrollo, pero el otro estudiante no será ajeno a
dichas actividades. Esto hace que los dos integrantes realicen un trabajo colaborativo a lo largo
de todo el proyecto

4.3 ROLES Y RESPONSABILIDADES

Los integrantes del grupo se distribuirán de la siguiente manera los roles en el proyecto:

Rol Responsabilidades
Administrador del proyecto 1. Llevar estricto control sobre el desarrollo de las
actividades según los cronogramas propuestos.
2. Proveer soluciones a los problemas que se
presenten.
3. Verificar la implementación de las soluciones.
4. Coordinar el trabajo del grupo a lo largo de todo
el proyecto.
5. Asignación de tareas a los demás integrantes

Responsable Ariel López

Tabla 5: Rol Administrador del proyecto

Rol Responsabilidades
Director de desarrollo 1. Definir las tecnologías que se van a usar para el
desarrollo del proyecto, lenguajes componentes
etc.
2. Participar en el proceso d documentación del
producto.
3. Implementación de prototipos parciales y finales
4. Ser parte activa de equipo de diseño del producto
5. Participar en el proceso de recolección y
especificación de requerimientos.
6. Solucionar los problemas de algoritmos,
tecnologías y componentes usados.
7. Garantizar la correcta implementación del
proyecto
Responsable Fabian Garcia
Tabla 6: Rol Director de desarrollo

Rol Responsabilidades
Arquitecto y diseñador 1. Asegurar que la construcción del sistema se haga
de acuerdo a lo pactado con el cliente y según los
lineamientos del proyecto.
2. Desarrollar el diseño del sistema a partir de los
requerimientos.
 3. Elección de las herramientas de modelado y
diseño del sistema.
4. Desarrollo del diseño de arquitectura del sistema
5. Participar en la recolección y especificación de
requerimientos
6. Definir los alcances de la implementación del
sistema
7. Garantizar que los prototipos sean entregados a
tiempo en correcto funcionamiento y con la
totalidad de las funcionalidades implementadas
8. Trabajar de la mano del director de desarrollo
9. Reportar al director de calidad y riesgos cualquier
riesgo que perciba que puede retrasar o dificultar
el desarrollo del sistema
Responsable Ariel López
Tabla 7: Rol Arquitecto y diseñador

Rol Responsabilidades
Director de calidad y 1. Encaminar las acciones de los integrantes de
manejo de riesgos acuerdo con el desarrollo de un plan de calidad
2. Asegurar la calidad de los documentos terminados
y recomendar ajuste y correcciones a las entregas
parciales de estos.
3. Crear y documentar el uso de formatos de revisión
de actividades.
4. Desarrollar un plan estratégico que integre
calidad y riesgos.
5. Detectar, describir, analizar, evaluar y prevenir
riesgos.
6. Estar siempre atento a la presencia o aparición de
riesgos, implementando políticas de control de
mitigación y resolución de los mismos.
7. Desarrollar planes de acción alternos en caso de
no poder manjar un caso de riesgo particular.
8. Supervisar en términos de calidad a la sección de
arquitectura y diseño, a la sección de desarrollo y
la documentación.

Responsable Fabian Garcia

Tabla 8: Rol Director de calidad y manejo de riesgos

Al adoptar la práctica de “Collective Code Ownership” descrita en XP [4], la cual establece que
todos los integrantes del grupo pueden modificar cualquier parte del código según lo necesiten,
se garantiza una mayor rapidez en el desarrollo. Como los integrantes tiene el mismo
conocimiento técnico sobre el desarrollo y el proyecto es relativamente pequeño, no se
incurren en riesgos significativos. Esta práctica hace que las tareas de administración de
configuración serán propias de los dos integrantes del grupo.

5. PLAN DE PROCESOS DE GESTIÓN

5.1 PLAN DE ARRANQUE

Cuando un proyecto se establece, es muy importante saber, por adelantado, la cantidad de

recursos necesarios para que el producto sea completado [5], contar con esta estimación
permite a la administración del proyecto designar los recursos necesarios para el desarrollo de
cada actividad, al final de cada actividad evaluar la cantidad de recursos que se necesitó para
su desarrollo y si está o no de acuerdo con la estimación inicial para así poder llevar el debido
control y hacer los ajustes necesarios al proceso.

5.1.1 Plan de Estimación

Para la realización del plan de estimación el equipo de trabajo realizara un documento en

Microsoft Project el cual se encontrara el cronograma de desarrollo del proyecto, enunciando,
las tareas, hitos de cada tarea y para estos la estimación de tiempo de duración de cada hito y
recursos de personas por tarea.

5.1.2 Plan de Personal

El plan de personal se desarrolla a partir de los roles asignados a cada uno de los integrantes
del equipo de trabajo, dependiendo de sus habilidades para llevar a cabo cada una de las
actividades que involucran el rol asignado.

Para conocer mejor los roles y las habilidades relacionadas, ver sección 4.3 Roles y las
Responsabilidades.

5.1.2.1 Objetivos
• Definir responsabilidades de cada integrante de acuerdo al rol asignado.

5.1.2.2 Actividades del plan de personal

A continuación se indican los miembros y las relaciones con cada área del proyecto utilizando
los siguientes acrónimos:

R: Responsable, I: Está involucrado, N: No está involucrado

 Área de trabajo

Ariel Fabián
López García
Planeación R I
Documentación I R
Manejo de versionesR I
Desarrollo R R
Calidad N R
Arquitectura R I
Tabla 9: Responsabilidades

5.1.2.3 Riesgos
Los riesgos se encuentran en la sección definidos en la sección 5.4 Plan de administración de
riesgos.

5.1.3 Plan de Entrenamiento de Personal

Para el cumplimiento de los objetivos, propósito y alcance del proyecto, no se realizará ningún
proceso de entrenamiento de personal, cada uno de los integrantes del equipo tiene
experiencia en el uso de las herramientas y lenguajes de programación necesarios para la
ejecución del proyecto.

5.2 PLAN DE TRABAJO

Los proyectos de software tienen un grado alto de complejidad, no pueden ser desarrollados
sin tener una planeación bien definida la cual ayude a determinar el alcance, duración,
obstáculos, recursos, costos y eficiencia en el ciclo de vida de este.

Dichos proyectos se pueden ver como un sistema general, que se divide en varios subsistemas
hasta lograr un fin específico; para el desarrollo de este proyecto se han planteado tres
grandes “subsistemas” como los son los procesos, las actividades y las tareas, como se muestra
en la siguiente gráfica.
 Tarea

Actividad

Proyecto

Tabla 10: Trabajo

5.2.1 Actividades de Trabajo

En las siguientes tablas se puede ver la distribución por cada proceso de las actividades con sus
principales tareas, básicamente cada tabla consta de unos recursos, entregables, riesgos, y los
responsables de las mismas.

ACTIVIDAD: DEFINICIÓN DE REGLAS DE EQUIPO

Tarea Recursos Entregables Riesgos Responsables
Reunión para Integrantes Ninguno Desacuerdo con las Integrantes
definir las reglas del equipo de decisiones tomadas del equipo de
de equipo trabajo trabajo.
(convivencia,
comunicación,
etc.)
Tabla 11: Reglas de grupo

ACTIVIDAD: DESARROLLO SPMP

Tarea Recursos Entregables Riesgos Responsables
División SPMP Correo Ninguno. Dejar partes de la Administrador
electrónico. plantilla SPMP sin del proyecto.
asignar
No tener claro qué
se debe hacer.
Elaboración Cronograma Documento Falta de información Integrantes del
SPMP SPMP SPMP- para hacer cada equipo de
Microsoft sección trabajo.
Word 2010 No tener claro el
cronograma SPMP
Retraso en la
calendarización
Auditoria de Trabajo de Ninguno Los trabajos estén Director de
calidad cada persona mal hechos calidad.
Que no hayan
trabajos

ACTIVIDAD: DESARROLLO IPA1

Tarea Recursos Entregables Riesgos Responsables
Reunión para Equipo de Ninguno. No tener en cuenta Integrantes
discutir las trabajo algún evento del equipo de
observaciones importante. trabajo.
que se
registraran en el
documento.
Realizar el Microsoft Documento No registrar algún Integrantes
documento IPA 1. Excel. IPA 1. evento importante del equipo de
en el documento trabajo.
IPA 1.
Tabla 13: Desarrollo IPA1

Tabla 12: Desarrollo SPMP

ACTIVIDAD: DIGITACION DE LAS ENCUESTAS

Tarea Recursos Entregables Riesgos Responsables
División de las Equipo de Ninguno. Alguna de las Administrador
encuestas trabajo. encuestas quede del proyecto.
fuera de la
repartición.
Digitación de las Microsoft Documento Errores de Integrantes
encuestas. Excel. Excel. digitación. del equipo de
trabajo.
Tabla 14: Digitación de encuestas

ACTIVIDAD: CREACION DE LA BASE DE DATOS

Tarea Recursos Entregables Riesgos Responsables
Creación de la Motor de Base de Ninguno. Diseñador.
base de datos en base de datos datos SQL
SQL Postgres. SQL Postgres. Postgres.
Creación de las Motor de Script SQL Errores de Integrantes
sentencias DML base de datos con las digitación. del equipo de
(Data SQL Postgres. sentencias trabajo.
Manipulation DML.
Language) para
insertar las tuplas
en la base de
datos.
Tabla 15: Creación base de datos
ACTIVIDAD: DESARROLLO IPA2
Tarea Recursos Entregables Riesgos Responsables
Reunión para Equipo de Ninguno. No tener en cuenta Integrantes
discutir las trabajo algún evento del equipo de
observaciones importante. trabajo.
que se
registraran en el
documento.
Realizar el Microsoft Documento No registrar algún Integrantes
documento IPA 2. Excel. IPA 2. evento importante del equipo de
en el documento. trabajo.
Tabla 16: Desarrollo IPA2

ACTIVIDAD: IMPLEMENTACION APLICACIÓN JAVA EE

Tarea Recursos Entregables Riesgos Responsables
Definir la Enterprise Diagrama Contemplar una Arquitecto de
Arquitectura de Architect. Arquitectura. arquitectura Software.
la aplicación. inadecuada para la
aplicación.
Implementación Ecplipse Aplicación Errores en la Director de
Ganymade. Java EE. implementación de desarrollo.
la presentación o
lógica de negocio.
Tabla 17: implementación de la aplicación

ACTIVIDAD: DESARROLLO IPA3

Tarea Recursos Entregables Riesgos Responsables
Reunión para Equipo de Ninguno. No tener en cuenta Integrantes
discutir las trabajo algún evento del equipo de
observaciones importante. trabajo.
que se
registraran en el
documento.
Realizar el Microsoft Documento No registrar algún Integrantes
documento IPA 3. Excel. IPA 3. evento importante del equipo de
en el documento. trabajo.
Tabla 18: Desarrollo IPA 3
5.2.2 Cronograma

Teniendo ya planeadas y organizadas las diferentes actividades que se necesita realizar para
cada una de las diferentes tareas del proyecto, (ver Sección 5.2.1 Actividades de Trabajo) es
pertinente tener una ayuda visual para el seguimiento de dichas tareas y actividades, es por
esto que se les definió una fecha de inicio y una de fin con unos recursos asociados.

5.2.3 Asignación De Recursos

Para el desarrollo del proyecto se hace necesario contar con diferentes recursos: personas,
computadores,, la presentación del trabajo, libros que sirvan como soporte al desarrollo del
proyecto, servicios como internet, entre otros, que ayudan a mejorar el conocimiento del
problema.

Para el desarrollo del presente proyecto se tendrán en cuenta los siguientes recursos:

Personas:

• Fabián García: Candidato a grado Ingeniería de sistemas en septiembre de 2012.

• Ariel López: Estudiante de último semestre de ingeniería de sistemas.

Equipo Descripción Dueño

Equipo 1 Nombre: DELL Inspiron 1440 Fabian Garcia.
Procesador: Intel core 2 duo
Memoria: 4Gb
Disco duro: 350 Gb

Equipo 2 Mac Book Pro Ariel Lopez

Procesador: : Intel core 2 duo
Memoria: 4 Gb
Disco duro: 320 Gb
Tabla 19: Personal

Documentos, libros, proyectos y tecnologías:

Se usarán varias fuentes de referencia para el proyecto, que servirán como recursos de apoyo
y consulta, tales como libros, manuales, páginas de internet y tecnologías de desarrollo de
software y herramientas de ofimática.

5.2.4 Asignación De Presupuesto

Para el desarrollo del proyecto se hace necesario contar con diferentes recursos, (ver sección
5.2.3 Asignación de recursos) que sirvan como soporte para el desarrollo del proyecto. Al
utilizar estos recursos, se generan gastos variables de acuerdo a la cantidad de uso de dicho
recurso en el proyecto, surgiendo la necesidad de asignar un presupuesto viable para lograr los
objetivos planteados en este documento.

La siguiente tabla muestra los costos de los principales recursos:

ID Recurso Valor (pesos colombianos)

recurso
1 Valor hora ingeniero de sistemas no graduado 14.000.00
2 Valor hora de computador 130.00
3 Valor hora de internet 200.00
4 Valor de la asignatura por persona 666.000
Tabla 20: Recursos

5.3 PLAN DE CONTROL

5.3.1 Plan de Control de requerimientos

Ya que el levantamiento y especificación de los requerimientos fue realizado previamente por

estudiantes de ingeniería de sistemas que cursaron la asignatura proyecto social universitario
en semestres anteriores, no se detallara nada en la presente subsección.

5.3.2 Plan de Control de cronograma

Existe la posibilidad de que las actividades a realizar no vayan acorde con el cronograma
planeado y se presenten demoras, trabajos incompletos y demás irregularidades. Por ello se
debe plantear una estrategia para responder a eventos como esos, y así poder actualizar el
cronograma de acuerdo a las soluciones planteadas, y hacerlo de manera que no afecte
profundamente el desempeño del equipo en el proyecto y en las tareas que han o están siendo
realizadas.

5.3.2.1 Objetivo

Establecer una metodología que pueda generar una estrategia para lidiar con los conflictos
entre el desarrollo de las actividades y las fechas del cronograma.

5.3.2.2 Desarrollo

Las estrategias para la recolección y análisis de datos se dividirán en tres fases [16]:
1. Datos de entrada: Son los primeros datos de información que luego serán base para el
análisis de rendimiento, entre ellos estarán el cronograma inicial, reportes iniciales de
rendimiento y el plan de gestión del cronograma.

2. Análisis: A partir de la información inicial, es necesario hacer una medición del rendimiento
de los grupos, y compararlo con el progreso propuesto en el cronograma. Para hacerlo se
diligencia primero una matriz de chequeo donde se muestre cómo va el avance de las tareas,
donde se verificar cuales se han iniciado, cuales se han terminado y cuales están atrasadas.
Después de hacer eso se puede realizar una tabla comparativa para evaluar el progreso, dicha
tabla se construye a partir de la cantidad de tareas completas contra las tareas por completar,
de acuerdo al proceso que se esté realizando (la agrupación por actividades solo se incluye
para una mejor organización de la tabla) y ese cálculo se define de la siguiente manera:

# 𝑇𝑎𝑟𝑒𝑎𝑠 𝑡𝑒𝑟𝑚𝑖𝑛𝑎𝑑𝑎𝑠
% 𝑑𝑒 𝑃𝑟𝑜𝑐𝑒𝑠𝑜 = ∗ 100%
#𝑇𝑎𝑟𝑒𝑎𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠

Y se aproxima al número entero divisible entre 10 más cercano, sea ya mayor o menor al
calculado.
Ilustración 2; Control del cronograma

Ilustración 3: Avance del proyecto

Con ayuda de la matriz se pueden priorizar los trabajos que no están cumpliendo con el
cronograma original. Una vez que se reconocen los que están afectando el ritmo del desarrollo
es necesario pedirle un reporte al grupo encargado de la actividad en el cual deben
especificarse las causas. Al final se deben proponer nuevas soluciones u otras alternativas en el
caso que la fecha límite esté muy cerca.

3. Salida: Una vez que se terminan de analizar las causas y proponer nuevas soluciones se debe
desarrollar una nueva versión del cronograma con las fechas actualizadas.

5.3.3 Plan de Control de Presupuesto

Se han definido los siguientes mecanismos para garantizar que el presupuesto asignado sea
suficiente para el óptimo desarrollo del proyecto.

• Personal: se ha establecido que cada integrante va a participar activamente en el

desarrollo del proyecto, cumpliendo a cabalidad con sus responsabilidades asignadas
según su rol, de esta forma se evita entrar en gastos adicionales de personal.
• Hardware y software: Cada integrante pondrá a disposición del proyecto su
computador personal con el fin de evitar gastos en equipos nuevos y aprovechar los
recursos existentes. Cada uno de los computadores personales tiene instaladas las
herramientas de software necesarias para la correcta realización del proyecto.
• Otros costos: Sólo por consenso de todos los integrantes se aprobará la compra de
algún artículo que sea de vital importancia para el desarrollo del proyecto.

5.3.4 Plan de Control de Calidad

El plan de Control de Calidad es el plan que contiene los lineamientos con los que se va a
gestionar todo tipo de elementos que estén ligados al ciclo de vida del proyecto (documentos,
reportes, código, etc.).

5.3.4.1 Objetivos

• “Supervisar los resultados específicos del proyecto, para determinar si cumplen con las
normas de calidad relevantes e identificar modos de eliminar las causas de un
rendimiento insatisfactorio”[6].
• Establecer las normas bajo las cuales se va a regir cada elemento.
• Definir las herramientas de calidad (estándares) que se usarán para cumplir estas
normas.
 • Establecer los responsables que se encargarán del control para que esto se cumpla.

5.3.4.2 Ejecución del Plan

Para la correcta ejecución y puesta en marcha de este plan se decidió dividir su funcionalidad
en dos grandes áreas las cuales corresponden a documentos y código.

5.3.4.2.1 Plan de control de calidad de documentos

Se tendrán en cuenta los siguientes aspectos para el aseguramiento de la calidad y el control

respectivo en los documentos:

Uso adecuado de referencias bibliográficas.

• •Ortografía.
• Coherencia en el texto.
• Legibilidad.
• Presentación de los documentos (uso adecuado de títulos, tablas, numeración, gráficos,
elementos SmartArt, etc.)
• Uso adecuado de formatos y/o plantillas determinados para el tipo de documento.
• Revisiones oportunas de todos los factores mencionados anteriormente.

5.3.4.2.2 Plan de control de calidad del código

El software debería ser escrito de acuerdo a un estándar de código [5], es por eso que el plan
de control de calidad del código es de gran importancia para indicar cuáles son los requisitos
necesarios para generar un software de calidad; identificando las características que se
tendrán en cuenta para hacer una respectiva verificación y validación del código, tomadas de
“Coding Techniques and Programming Practices” [7], tales como:

• Darle formato correctamente al código fuente: es necesario que el código sea legible
para poder identificar y corregir fácilmente cualquier error.
• Documentación clara, concisa y relevante: documentar la clase de forma general para
dar una idea de su funcionalidad atributos y métodos, y documentar de forma
específica los métodos más importantes.
• Debe ser eficaz: cumplir con la funcionalidad deseada.
• Debe ser eficiente: no desperdicio de recursos.
• Debe ser compatible con los demás componentes del sistema.
• Debe estar acorde con el diseño del sistema.
• Usar nombres significativos para los métodos, atributos y clases.

5.3.4.3 Riesgos
Los riesgos se encuentran en la sección definidos en la sección 5.4 Plan de administración de
riesgos.
5.4 Plan de administración de riesgos

El plan de administración de riesgos consiste en el análisis de riesgos que se pueden presentar

durante el proyecto y que deben ser tenidos en cuenta para asignarles un nivel de prioridad y
crear un plan de contingencia.

El administrador de calidad y control de riesgos es el encargado de documentar estos riesgos y

darles en análisis correspondiente en este documento, asimismo planteando el plan de
contingencia ayudado por la persona que reportó el riesgo.

5.4.1 Objetivos
 El objetivo principal del Plan de Administración de Riesgos es definir la metodología
para la identificación, evaluación, análisis y control de riesgos que se presenten
durante el ciclo de vida del proyecto.
 La idea en cuanto a esta administración es encontrar la importancia y el nivel de cada
riesgo presentado. Se debe hacer un plan previo de contingencia para evitar que
mayores problemas se presenten en el futuro.

5.4.2 Ejecución del plan

Primero se deben identificar y clasificar los riesgos según el área en la cual se deben gestionar
o se pueden presentar. Posteriormente se hace tanto el análisis cualitativo como el
cuantitativo para definir el plan de contingencia de cada riesgo.

5.4.3 Tipificación de los riesgos

Para la administración de todos los riesgos, se usarán las tablas propuestas por Bruegge [23].
La siguiente tabla muestra los riesgos y para cada uno de estos la categoría asociada.

CATEGORÍA ID RIESGO DESCRIPCIÓN DEL RIESGO

Fallas en el framework de generación y/o en la plataforma de

RS - 01
programación.

Tecnológico

Las requerimientos mínimos para el funcionamiento del

programa son muy altos para los sistemas donde se está
RS - 02
ejecutando (componentes gráficos, poder de procesamiento,
tamaño de memoria, etc.).
 Uno o más miembros del equipo renuncian en alguna fase
RS - 03 crítica de la planeación, desarrollo o presentación del
proyecto.

Uno o más miembros del proyecto tiene algún impedimento

de fuerza mayor (enfermedad, eventos familiares de gravedad,
RS - 04
etc.) y no puede presentarse en fases críticas de la planeación,
Personal desarrollo o presentación del proyecto.

Uno o más miembros no poseen las capacidades mínimas para

RS - 05
desempeñarse en su rol y, por consecuencia, en sus tareas.

Se generaran conflictos de índole personal entre los

RS - 06
integrantes del grupo de trabajo.

Los roles de los integrantes se cambian causando la

RS - 07
restructuración de la organización.

La organización carece de visión, objetivo y misión definidos

RS - 08
claramente.

OrganizacionalFuente
No hay comunicación organizada entre los miembros del
especificada no RS - 9
equipo de trabajo.
válida.

No existen estrategias para el desarrollo, planeación o

RS - 10
presentación del proyecto.

No existe un control de la cantidad de tiempo asignado para el

RS - 11
desarrollo de tareas del proyecto.
 El líder de la organización carece de las capacidades,
RS - 12
motivación o interés para desempeñarse en su papel.

Las herramientas CASE no poseen alguna herramienta

Herramientas RS - 13 necesaria para trabajar en alguna fase del desarrollo o
planeación del proyecto.

Suceden cambios en los requerimientos de tal magnitud que

RS - 14
se requiere una nueva planeación de todo el proyecto.

Los requerimientos no poseen las especificaciones necesarias

RS - 15 para que todos los integrantes no tengan dificultad en
Requerimientos
entenderlos y atacarlos.

El cliente no tiene en consideración la gravedad de modificar,

RS - 16 eliminar o agregar un requerimiento durante fases avanzadas
del desarrollo del proyecto.

La proyección del tiempo esperado para el desarrollo de

Estimación RS - 17 alguna tarea del proyecto no es relevante con base a las
capacidades de los integrantes responsables.

Tabla 21: Riesgos y tipos de riesgos

5.4.4 Priorización de los riesgos

La clasificación a continuación se da de acuerdo a las probabilidades que un riesgo se presente,

diligenciada de acuerdo a las siguientes proporciones (oportunidad de que se presente el
riesgo).

1. Muy Bajo: El riesgo es menor al 10%.

2. Bajo: Entre 10 y 25%.
3. Moderado: Entre 25 y 50%.
4. Alto: 50 y 75%.
 5. Muy Alto: Mayor de 75%

También se toma en cuenta el efecto que puede tener dentro del proyecto, teniendo en
cuenta los siguientes niveles

1. Catastrófico.
2. Serio.
3. Tolerable.
4. Marginal
5. Insignificante

A continuación la tabla muestra la relación efecto –probabilidad [1].

Probabilidad
/ Impacto Muy Bajo Bajo Medio Alto Muy Alto
Insignificante
Marginal Cero Tolerancia
Tolerable Poca Tolerancia
Serio Alta Tolerancia
Catastrófico
Tabla 22: Matriz de riesgos

La siguiente tabla muestra la relación de la probabilidad de que un riesgo ocurra asociado con
el impacto que podría causar.

RIESGO PROBABILIDAD IMPACTO

RS - 01 Baja Catastrófico
RS - 02 Baja Tolerable
RS - 03 Moderada Serio
RS - 04 Moderada Tolerable
RS - 05 Baja Serio
RS - 06 Baja Insignificante
RS - 07 Moderada Insignificante
RS – 08 Baja Catastrófica
RS – 09 Alto Tolerable
RS – 10 Moderada Serio
RS – 11 Muy Alto Serio
RS – 12 Alto Tolerable
RS – 13 Moderada Insignificante
RS – 14 Bajo Catastrófico
RS – 15 Alto Serio
RS – 16 Bajo Serio
RS - 17 Moderado Serio
Tabla 23: Análisis de riesgos
5.4.5 Riesgos.
 Pasar por alto el análisis o peor aún, la existencia de algún riesgo y al momento de
presentarse no tener un plan de contingencia para controlarlo.
 No hacer adecuadamente el análisis de un riesgo y ejecutar planes indebidamente.

5.5 Plan de cierre

Una vez finalizado el proyecto es necesario encargarse de que la experiencia obtenida durante
el desarrollo del proyecto pueda ser documentada, analizada y almacenada. De este modo el
grupo puede tener una idea de que como fue el desarrollo paso a paso del proyecto y ganar
como experiencia las enseñanzas que dejó para poder ser aplicadas a futuro.

5.5.1 Objetivos
o Evaluar qué tan acertadas fueron las asignaciones de los roles al inicio del proyecto.
¿Fue cada integrante competente frente a sus responsabilidades según su rol?
o Hacer revisión en el cumplimiento adecuado del Plan de Control de Calidad.
o Determinar los niveles de calidad definidos en los planes de control de calidad y
aseguramiento de calidad se cumplieron.

5.5.2 Actividades
o Evaluación del plan de control de calidad.
Para la evaluación del Plan de Control de Calidad, se usará el plan de aseguramiento de
calidad en el cual se define el proceso a seguir para el respectivo aseguramiento.

o Evaluación de roles.
Para la evaluación de los roles se evaluaran los desempeños de los roles de cada
miembro del equipo de trabajo, y se consideran los siguientes tópicos:

 Los roles que sí fueron efectivos.

 Los roles que presentaron fallas.
 Los roles, y su áreas, que necesitan ser improvisados.
 Los objetivos que pueden ser relevantes para un mejor funcionamiento de
los roles.

o Evaluación de debilidades y fortalezas.

En la realización de esta evaluación, cada integrante del equipo de trabajo debe hacer
un análisis sobre cómo se sintió desarrollando las diferentes tareas que le fueron
asignadas durante el proyecto; teniendo en cuenta el tiempo estimado y el tiempo real
que tomó realizar cada una de las tareas.
En base a este análisis, se reconsiderara la asignación de roles a futuro, y/o la
asignación de tareas en las que los integrantes del equipo de trabajo son más
eficientes y se sienten más a gusto trabajando.
 o Análisis de riesgos.
Para el análisis de riesgos a medida que evolucione el proyecto, se verá reflejada su
efectividad, en el plan de cierre el objetivo es encontrar qué problemas hubo al aplicar
los planes de contingencia, qué riesgos a los que se les entregó mayor prioridad nunca
se pudieron haber presentado y se gastaron recursos para prevenirlos, para en futuros
momentos del proyecto, tener en cuenta y saber a cuáles prestarles mayor atención y
a cuáles no.

6 PLAN DE PROCESOS TÉCNICOS

6.1 MODELO DE CICLO DE VIDA DEL PROCESO

Debido a que el proyecto es relativamente pequeño y se cuenta con algo menos de 3 semanas
para desarrollarlo, se decidió usar la metodología de desarrollo de software será XP.se
adoptaran las siguientes prácticas en el proceso de desarrollo según esta metodología:

• Programación: programación incremental basado en pruebas. Cada código nuevo debe

ser justificado mediante las pruebas pertinentes.
• Prácticas de equipo: Programación en parejas, esto hace que el código escrito sea de
mayor calidad ya que los dos integrantes están revisando constantemente cada una de
las líneas de código.
• XP como proceso: se realizarán tres iteraciones en las que habrá gran comunicación
con el cliente. Para determinar:
 Primera reunión: diagnóstico y recolección de requerimientos.
 Segunda reunión: validación de requerimientos a través de un prototipo
funcional.
 Entrega final al cliente.: se realizarán los ajustes pertinentes.

Para cada una de las iteraciones se pretende entregar ciertos entregables como se describe a
continuación:

• Primera iteración: SPMP,IPA1, SRS y primera versión de SDD

• Segunda iteración: Ajuste del SRS y SDD final con primer prototipo funcional.
• Tercera iteración: Aplicación Completa y su respectiva documentación.
6.2 METODOS, HERRAMIENTAS Y TÉCNICAS

6.2.1 Herramientas

EL proyecto se desarrollará usando el paradigma de programación orientada a objetos, usando

el lenguaje de programación orientado a objetos JAVA. Se usará la edición JAVA EMPRESARIAL
5 (JEE5) [18] complementada por SEAM 2 Framework [19] y la tecnología JSF. Se usará una
base de datos PostgresSQL 9 [22] y el entorno de desarrollo Eclipse. La aplicación será
ejecutada un servidor de aplicaciones JBOSS 5.1 GA .

Entrerprise Achitect [21] será la herramienta usada para modelar la arquitectura del sistema.

Se usará SVN como mecanismo de control de versiones a través del plug–in subclise de Eclipse.
Se usará SARE ModelToTextGenerator [17] como herramienta de generación de código. Para
control de versiones de documentos se usara Dropbox.

Se usará MIcrosft Word [20 ] como herramienta de documentación.

Se usara Microsoft Excel [20] para digitalizar las encuestas.

Como herramientas de comunicación interna y externa se usará correo electrónico.

6.2.2 licencias
Todas las herramientas mencionadas anteriormente son de libre uso, aparadas bajo una
licencia de libre uso y distribución, a excepción de las herramientas de Microsoft, las cuales los
integrantes tienen las licencias pertinentes.

6.4 PLAN DE ACEPTACION DEL PRODUCTO

6.4.2 Objetivo
Definir los mecanismos, actividades, recursos y responsables necesarios para lograr los niveles
de calidad y el cumplimiento de los requerimientos definidos y así lograr la aceptación del
producto por parte del cliente.

6.4.3 Alcance

Este plan describe el proceso que garantizará el cumplimiento de los estándares mínimos en
cuanto a calidad, funcionalidad y presentación definidos por el cliente para que el producto
sea aceptable. Dada la naturaleza del plan, este se verá íntimamente relacionado con otros
planes como el plan de control de calidad (ver sección 5.3.4 plan de control de calidad), plan
de recolección de métricas (ver sección 5.3.6 plan de recolección de métricas), el cronograma
de actividades (ver sección Cronograma) y el plan de verificación y validación (ver sección 7.2
plan de verificación y validación)

6.4.4 Responsabilidades

6.4.4.1 Responsabilidades del cliente

• Definir claramente las funcionalidades esperadas del producto.
• Definir las restricciones en el proceso de desarrollo del producto.
• Dar retroalimentación al grupo de cada entrega que se realice.

6.4.4.2 Responsabilidades del grupo

• Crear los mecanismos de comunicación con el cliente que permitan un dialogo abierto
y constructivo sobre el proceso de desarrollo del producto.
• Cumplir con fechas, características y funcionalidades esperadas en cada entrega.
• Dar la importancia que corresponde a las retroalimentaciones realizadas por el cliente
y plasmar dichas retroalimentación en el proceso de desarrollo.
• Cumplir con los procedimientos establecidos en este plan y en todo el documento.

6.4.5 Actividades de aceptación de producto

6.4.5.1 Criterios de aceptación de producto

Los criterios de aceptación de basaran en el cumplimiento del diccionario de datos entregado
por el cliente y los requerimientos pactados.

6.4.5.2 Auditoria de configuración física

Los artefactos que serán enviados y aceptados por el cliente producto del trabajo de este
proyecto son los siguientes:

• SPMP: Plan de administración de proyecto software

• SRS: Software Requirements Specification
• Prototipo #1.
• SDD: Software Design Document
• Aplicación final.

6.4.5.3 Auditoria de configuración funcional

Los métodos de evaluación y el nivel de formalidad para cada uno de los artefactos
identificados en la sección anterior son:

• SPMP: Plan de administración de proyecto software: Bajo nivel de formalidad, debe

tener como base algún estándar e incluir todas las secciones especificadas en este con
adiciones o modificaciones, a criterio del grupo, de otros estándares o referencias.
• SRS: Especificación de requerimientos de software: Especificación altamente detallada
y formal de los requerimientos que debe presentar el sistema. Se seguirá el estándar
propuesto por IEEE.
• Prototipo #1. El prototipo número uno debe presentar al menos el 80 de las tablas de
la base de datos y la aplicación que realice al menos consultas sobre dicha base de
datos.
 • SDD: Documento de diseño de software: Especificación del diseño del sistema tan
detallado como sea considerado por el grupo y aceptado por el cliente.
• Aplicación final: la aplicación final debe presentar completa funcionalidad según el
alcance definido.

6.4.6 Cronograma

Para garantizar la aceptación de cada hito del proyecto se describe el siguiente proceso de
actividades:

• Planeación de la iteración
• Desarrollo de la iteración
• Revisión y corrección de artefactos
• Presentación de artefactos al cliente
• Corrección de artefactos

6.4.9 Entorno de aceptación de producto

La aplicación será entregada en un CD al cliente y será instalada en la maquina que este
disponga.

7 PLAN DE PROCESOS DE SOPORTE

7.1 PLAN DE ADMINISTRACIÓN DE LA CONFIGURACIÓN

7.1.1 Introducción

Se seguirá el plan de administración de la configuración propuesto por Rational Unified

Process (RUP) [9]en su sección Configuration Management Plan [9].

7.1.2 Objetivo

El propósito de este documento es definir los procedimientos y actividades de administración

de la configuración que serán seguidos en el desarrollo este proyecto.

7.1.3 Alcance

Este plan se aplica a todo tipo de elemento generado en el proceso de desarrollo del proyecto
y se encargará de definir los procesos necesarios para asegurar la administración de la
configuración de dichos elemento.
7.1.4 Administración de la configuración

7.1.4.1 Organización, Responsables e interfaces

Los responsables de efectuar este plan serán los dos integrantes del grupo.

7.1.4.2 Entorno, herramientas e infraestructura

Se usará la herramienta DropBox [10] para almacenamiento de los artículos de configuración
correspondientes a documentación. Se usará la herramienta SVN [11] como manejo del
repositorio encargado de manejar los artículos de configuración correspondientes a código
fuente. El código fuente será almacenado en un repositorio de Google Project [12].

7.1.4.3 Identificación de la configuración

Los artículos de configuración comprenden: SPMP [1] y documentación asociada, SRS [2] y
documentación asociada, SDD [2] y documentación asociada, código fuete de prototipos y del
sistemas final, código ejecutable y manuales de usuarios.

7.1.4.4 Métodos de identificación

Se usara para los documentos una identificación de las versiones de 3 dígitos
( nombre1.0.0.doc), para el código fuente se tendrá en cuenta el número de actualización en el
repositorio provisto por SVN. Se debe documentar en cada actualización o cambio de código
su correspondiente explicación a través de SVN.

7.1.4.5 Líneas base

Las líneas base serán creadas al final de cada iteración, revisión o entrega al cliente, después
de sus correspondiente retroalimentación, su alteración será realizada por común acuerdo de
los dos integrantes y/o alguna de las interfaces externas.

7.1.5 Control de cambios

No existirán peticiones formales de cambios ni un comité de control de cambio, el proceso de
cambios será realizado en común acuerdo por los dos integrantes de grupo y registrado en la
actualización del código fuente en SVN. Para documentos se llevará el registro en la tabla de
historial de cambios al inicio de cada documento.

7.1.6 Contabilidad del estado

Los ítems de configuración serán almacenados y compartidos a todos sus integrantes a través
de Dropbox y Google Project donde se ubicará el repositorio para administrar los ítems de
configuración a ser controlados con SVN a través del plug-in subclipse de Eclipse [13]. Además
de estas herramientas cada integrante tendrá almacenados en sus equipos personales los
ítems de configuración de los cuales sean responsables.
7.2 PLAN DE VERIFICACIÓN Y VALIDACIÓN
7.2.1 Introducción

Este plan pretende establecer las acciones para garantizar que el producto cumple con las
especificaciones iniciales, y de no hacerlo, establecer las acciones a tomar corregir esta
situación.

7.2.2 Objetivos
• Comprobar que el sistema desarrollado cumple con las especificaciones iniciales.
• Comprobar que se satisfacen los requerimientos funcionales y no funcionales del
sistema

7.2.3 Actividades del plan de verificación y validación

Las actividades de verificación serán desarrolladas por los dos integrantes del grupo en una
reunión donde se analizarán los artefactos correspondientes para cada actividad. Las
actividades y los artefactos se las mencionadas a continuación:

• Verificación de la arquitectura del sistema (diagrama de clases, de despliegue y de

componentes).
• Verificación del modelo de datos (Tablas de la base de datos), verificar que el
diccionario de datos proporcionado se cumple en la base de datos que se desarrolle.
• Verificación de integración entre los componen del sistema. (datos, lógica y
presentación).
• Verificación de la información digitalizada. Se hará una comparación de la información
en físico y la versión digital para detectar errores y hacer correcciones.
• Validación de la aplicación. Se harán consultas sobre la base de datos, ingreso de
información al sistema, verificación de que la información que se ingresa queda
almacenada en la base de datos y modificación de dicha información.

7.2.4 Riesgos
Los riesgos se encuentran en la sección definidos en la sección 5.4 Plan de administración de
riesgos.
7.3 PLAN DE DOCUMENTACIÓN
7.3.1 Introducción
En este plan se establecen todos los documentos, plantillas y estándares que se utilizarán a lo
largo del proyecto.

7.3.2 Objetivos
1. Definir los estándares y plantillas a utilizar en este proyecto.
2. Definir los documentos entregables al cliente en el proceso de desarrollo.
3. Definir los responsables de modificar y validar cada uno de los documentos
entregables.

7.3.3 Definición de plantillas y estándares

PLANTILLAS ESTÁNDARES
SPMP: RUP
SPMP: Línea base IRONWORKS

SPMP: IEEE 1058-1998 (Standard for

Software Project Management Plans).

SRS: Línea base IRONWORKS SRS: IEEE 830-1998 (Recommended

Practice for Software Requirements
Specifications)

SDD: IEEE 1016-1998 (Recommended

Practice for Software Design Descriptions)
SDD: Línea base IRONWORKS

MANUAL USUARIO: IEEE 1063-2001

(Standard for Software User
Documentation)
MANUALES DE USUARIO E INSTALACIÓN:
Manual de usuario IRONWORKS TODOS LOS DOCUMENTOS: IEEE CITATION
REFERENCE

Ilustración 4: Plantillas y estándares

7.3.4 Definición de documentos entregables y responsables

Los siguientes documentos son los entregables de este proyecto.
 SPMP
• Documento de especificación y definición de la
planeación del proyecto.
• Responsables: Ariel López y Fabián García

SRS

• Documento de especificación de requerimientos.

• Responsables: Ariel López y Fabián García

SDD

• Documento de especificacion de diseño del

software.
• Responsables: Ariel López y Fabián García

MANUAL DE USUARIO E INSTALACIÓN

• Documento de especificación del proceso de

instalación y uso del producto.
• Responsables: Ariel López y Fabián García

Ilustración 5: Entregables

7.3.5 Riesgos
Los riesgos se encuentran en la sección definidos en la sección 5.4 Plan de administración de
riesgos.

7.4 PLAN DE ASEGURAMIENTO DE CALIDAD

El aseguramiento de calidad para el proyecto se basará en usar adecuadamente el Plan de

Control de Calidad y un Plan de Pruebas, explicado en este documento. El plan de
aseguramiento de calidad será el único medio de control de calidad, revisión y auditoria que se
hará en el proyecto, esto debido a que los dos integrantes tiene bastante experiencia en la el
desarrollo de aplicaciones como la que se pretende desarrollar en este proyecto.

7.4.1 Objetivos
 • Definir el proceso que se seguirá para asegurar la calidad en los artefactos realizados
durante el proyecto.

7.4.2 Responsables

Los dos integrantes del grupo serán responsables de asegurar la calidad tanto de los artefactos
creado por cada uno como por los del otro, esto implica que debe haber una constante
revisión de artefactos tanto propios como del otro integrante. Al trabajar en reuniones junto
este proceso puede ser rápido y efectivo.

7.4.3 Plan de Pruebas

El plan de pruebas se enfocará en hacer revisiones del código, sin embargo se define el
procedimiento para los demás artefactos. Las principales características que se miden en el
Plan de Pruebas son:

• El software satisface los requerimientos exigidos por el cliente.

• Encontrar errores o anomalías en el funcionamiento o la interfaz gráfica del software.
• El proceso para asegurar la calidad de los documentos es así:
• Informar que el documento está listo para revisión
• El otro integrante lee el documento y propone mejoras o esta de acuerdo.
• Se realizan las mejoras y se aprueba el documento.

Las pruebas que se ejecutarán durante el desarrollo serán las siguientes:

• Pruebas Unitarias: dada una entrada A se espera una salida B. Estas pruebas consisten
en demostrar que la anterior proposición se cumple. La idea es comprobar el
funcionamiento correcto de un caso de uso implementado.
• Pruebas de validación y verificación: estas pruebas consisten en asegurarse de que el
software cumpla con los requerimientos exigidos por el cliente.