REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD NACIONAL

EXPERIMENTAL DE GUAYANA INGENIERÍA EN INFORMÁTICA

NÚCLEO: CIUDAD GUAYANA
ASIGNATURA: INGENIERÍA DEL SOFTWARE II

ENTREGA I
DESARROLLO DE UN SISTEMA DE CREACIÓN Y GESTIÓN DE EVENTOS
BAJO LA FILOSOFIA DE SOFTWARE LIBRE PARA EL REGISTRO E
INSCRIPCIÓN DE PERSONAS NATURALES QUE EVITE COLISIÓN DE
HORARIO SEGÚN LA PROGRAMACIÓN DE LAS ACTIVIDADES.

Profesor: Presentado por:

Alejandro Marcus Sección 01

Ciudad Guayana, enero 2017

 Índice

Presentación ................................................................................................................ 5

Objetivo General y específicos ................................................................................... 6

Objetivo general ...................................................................................................... 6

Objetivos específicos .............................................................................................. 6

Restricciones funcionales y no funcionales ................................................................ 7

Requerimientos funcionales.................................................................................... 7

Requerimientos no funcionales............................................................................... 8

Metodología de implementación: Programación Extrema (XP)............................... 13

Razones por las cuales usar estos procesos de trabajo para desarrollar el software:
.......................................................................................................................................... 13

Mayor productividad. ....................................................................................... 13

Es flexible. ........................................................................................................ 13

Optimizar el tiempo. ......................................................................................... 13

Un equipo motivado. ........................................................................................ 14

Hacer feliz al cliente. ........................................................................................ 14

Una metodología ágil tiene varios principios para llevarse a cabo, entre los más
importantes tenemos: ........................................................................................................ 14

Para entender mejor el ciclo de desarrollo de XP en el que se utilizan estos

principios, es necesario conocer las 4 fases que componen su ciclo de vida: .................. 14

Planeación. ........................................................................................................ 14

Diseño. .............................................................................................................. 15

Codificación. ..................................................................................................... 16

Pruebas. ............................................................................................................. 17
 Plan de trabajo ...................................................................................................... 17

Planificación de la iteración.................................................................................. 18

Definir las historias de usuarios con el cliente. ................................................ 18

Definir el Release planning. ............................................................................. 18

Planificar la iteración. ....................................................................................... 19

Velocidad de la iteración. ................................................................................. 19

Ejecución de la iteración. .................................................................................. 19

Inspección y adaptación ........................................................................................ 20

Herramientas de la Metodología Programación Extrema XP ............................... 20

Historia de Usuario. .......................................................................................... 20

Tareas de Ingenierías (Task Card). ................................................................... 21

Pruebas de Aceptación. ..................................................................................... 23

Participantes en el proyecto .................................................................................. 24

Programador. .................................................................................................... 24

Cliente. .............................................................................................................. 25

Encargado de pruebas (tester). .......................................................................... 25

Encargado de seguimiento (tracker). ................................................................ 25

Entrenador (coach). ........................................................................................... 25

Consultor........................................................................................................... 25

Gestor (big boss). .............................................................................................. 25

Plan de trabajo .......................................................................................................... 26

Iteración 1 ............................................................................................................. 26

Iteración 2 ............................................................................................................. 27

Iteración 3 ............................................................................................................. 29

Hitos .......................................................................................................................... 30
Departamentos del proyecto ..................................................................................... 32

Departamento de oficina de proyecto ................................................................... 32

Departamento de diseño grafico ........................................................................... 32

Departamento de desarrollo .................................................................................. 33

Departamento SQA ............................................................................................... 33

 Presentación

El siguiente informe describe el proceso de desarrollo de un software que

brinde organización a cualquier evento. Entre las características resaltantes debe registrar
a personas naturales e inscribirlas según su preferencia en las actividades a las que puede
asistir. Esto quiere decir, que debe contar con la programación previamente cargada en el
sistema para que pueda brindar el servicio de fijar un cronograma sin colisión.
También, el participante puede acceder a la información acerca de las
actividades que ha seleccionado en su horario y solicitar un certificado de asistencia y
participación. Además, cuenta con un procedimiento para la evaluación de ponencias.
Estas son a grandes rasgos los principales requerimientos.
Aunque, se debe indagar a fondo para que el sistema sea más completo y
cumpla con los estándares de calidad al final del proceso de desarrollo. Significa que no
solo hay que tomar en cuenta las especificaciones directas del cliente sino, ir más allá y
cubrir otros aspectos.
Esto implica primero el análisis de la problemática por medio de entrevistas,
encuestas, e investigación. De esta manera se ataca el problema desglosando las
necesidades que se deben cubrir. Así, junto con las especificaciones del cliente se
establece la funcionalidad del sistema.
Una vez determinados los puntos clave que se van a tratar, se puede hacer un
primer diseño del sistema, tomando en cuenta todas las características para tener una
visión clara de lo que se espera en sus etapas finales. Pero, para hacer el diseño es
necesario hacer la planificación primero, es decir, distribuir el tiempo y recursos para que
se adapten a la solicitud del cliente.
Por lo que, por medio de un análisis sobre la situación, se establecen las partes
del software que se van a trabajar en un plazo de 1 a 3 semanas. Para que el cliente pueda
ver los avances del proyecto de manera continua y se mantenga acorde con sus
expectativas. Así, la planificación ayuda a que el desarrollo sea rápido y dinámico.
Entonces, el equipo trabaja bajo la metodología de programación extrema, que
describe un plan de acción que sigue las etapas descritas, continuando con la fase de
codificación. De esta manera, los programadores se dividen las tareas en parejas para
 cumplir con lo necesario al final de cada iteración. En primer lugar, se implementa una
arquitectura básica del sistema para que sea modificado de acuerdo al plan de acción hasta
obtener el producto final.
Finalmente, cabe resaltar que las pruebas del sistema son muy importantes al
finalizar cada iteración, porque las tareas de la siguiente incluirán aquellas que no fueron
cumplidas en la fase anterior. Esto da una mayor probabilidad de garantizar que los
estándares serán cumplidos al culminar el proyecto.

Objetivo General y específicos

Objetivo general
Desarrollar un sistema de gestión de eventos que permita el registro de los
participantes e inscripción en las actividades, donde se organice el horario de asistencia
según la programación, evitando colisión y brindando facilidad de acceso a la
información, referente a las presentaciones, certificados y evaluación de ponencias.

Objetivos específicos
1. Diagnosticar la situación actual de la gestión de eventos por medio de software, y su
efectividad en cuanto a la organización.
2. Recolectar información acerca de la problemática, mediante encuestas y entrevistas
con el cliente.
3. Determinar la funcionalidad del sistema según el análisis sobre la información
recopilada.
4. Establecer el diseño del sistema de acuerdo a los requerimientos funcionales y no
funcionales.
5. Implementar el prototipo del sistema de gestión de eventos bajo la filosofía de
software libre.
6. Elaborar pruebas del sistema para que se ajuste a los estándares señalados para el
producto final.
7. Modificar el sistema según los resultados de las pruebas para que se ajuste a los
estándares del producto final.
 Restricciones funcionales y no funcionales

Requerimientos funcionales

1. Desarrollo de sistema de servicio con dos fases.

1.1. Fase de registro.
1.1.1. Es necesario que los participantes indiquen sus datos personales.
1.1.2. El asistente tendrá la oportunidad de decidir en qué actividades desea
participar.
1.1.3. Existe la opción que los participantes den su opinión, adjuntando propuestas.
1.2.Fase de inscripción de actividades.
1.2.1. Los asistentes deben ser capaces de elaborar su propio horario de
actividades, dentro de los diferentes espacios del congreso.
1.2.2. Toda aquella persona que desea participar, debe ser persona natural.
1.2.3. El sistema, no debe permitir por ningún motivo el solapamiento de horarios.
1.2.4. Todo evento que haya sido creado debe estar precargado en el sistema,
ayudando así a que cada usuario señale las actividades en las que participará.
1.2.5. Toda persona natural tiene la posibilidad de inscribirse en la actividad que
desee.
1.2.6. Cada participante tiene el derecho a obtener un horario de acuerdo a sus
actividades, el cual podrá ser impreso y tendrá la opción de ser visualizado
en línea.
1.2.7. El sistema debe ser capaz de aceptar la solicitud de cualquier persona que
desee hacer una presentación oral o posters digital.
1.2.7.1.Los autores de una actividad deben poder subir un resumen del material
a presentar.
1.2.7.2.Los resúmenes que se encuentren en el sistema, podrán ser visualizados
por los diferentes usuarios.
1.2.7.3.Debe estar establecido en el sistema un horario de presentaciones con su
respectivo nombre del autor y título.
 1.2.8. Debe existir un método que sea capaz de evaluar las ponencias orales y
digitales.
1.2.8.1.La evaluación de los ponentes, solo podrá ser realizada por jurados
designados.
1.2.8.2.Se debe contar con un panel de jurados, de máximo tres (3) personas.
1.2.8.3.El sistema debe ser capaz de arrojar listas de aprobados, según varios
porcentajes de la calificación obtenida.
2. Sistema de chequeo de registros.
2.1.La comprobación de asistencia debe realizarse mediante la cédula.
3. Sistema de emisión y consulta de certificados.
3.1.Para que un certificado sea válido, debe contar con varios atributos específicos,
como lo son: imagenología del evento, nombre del ponente y la ponencia, fecha y
lugar, nombre de las autoridades del evento, así como un código de verificación
generado por el sistema.
4. La aplicación web deberá mostrar los trabajos de investigación más populares (los
desarrolladores decidirán la mejor forma de mostrar dicha información)
5. Al finalizar la presentación se habilitará una opción en el sistema Web para descargar el
trabajo de investigación, siempre y cuando el usuario acepte los términos y condiciones
antes de descargar el documento.
6. Al finalizar la presentación el sistema Web habilitará la opción de votación, para
calificar al ponente según la presentación que realizó
7. El sistema debe tener una opción que le permita al usuario, ver un listado de los eventos
a los que ha asistido.

Requerimientos no funcionales

1. La aplicación web debe ser desarrollada con software libre

1.1 El sistema debe manejar la base de datos con postgresql.
1.2 Se debe desarrollar el sistema web; utilizando PHP 5 bajo el framework laravel.
2. El diseño de la aplicación web debe ser “Responsive” a fin de garantizar la adecuada
visualización en; computadoras, tabletas y teléfonos inteligentes.
3. El diseño de la aplicación web debe ser sencilla y de fácil acceso para el usuario
4. El contenido de la aplicación web debe estar ordenada y bien redactada.
5. La aplicación web debe ser usada en diferentes navegadores web, siendo los más usados:
• Opera
• Chrome
• Mozilla
6. Se debe tener en cuenta la correcta combinación de los colores, logrando así la
comodidad del usuario mientras esté usando la aplicación web.
 Metodología de implementación: Programación Extrema (XP)

La programación extrema es un enfoque de la ingeniería de software formulado por

Kent Beck como una metodología de desarrollo ágil que tiene como principal objetivo
aumentar la productividad a la hora de desarrollar un proyecto software, es muy exitosa en
tiempos recientes. Se enfoca en dar prioridad a los trabajos que dan un resultado directo y en
los cuales se reduce la burocracia que pueda existir en el entorno de trabajo

Razones por las cuales usar estos procesos de trabajo para desarrollar el software:

Mayor productividad.
Al optar por este método ágil utilizamos estrategias que le ahorraran a nuestro equipo
pasos innecesarios que no aportan al proyecto en sí, evitaremos concentrarnos en hacer
documentaciones extensas o en códigos muy densos que puedan entorpecer la forma en la
que el equipo se desenvuelve en el proyecto.

Es flexible.
Incentivaremos la flexibilidad al establecer una relación entre el equipo de desarrollo
y el cliente para que pueda aportar ideas a su propio proyecto y los cambios que se realicen
sean los deseados, además de ir haciendo los cambios necesarios conforme el proyecto vaya
evolucionando, sin necesidad de cambiarlo todo de inicio a fin.

Optimizar el tiempo.
Esta es, sin duda, una de las principales razones para seleccionar este proceso de
trabajo ágil, ya que XP optimiza el tiempo por medio de la comunicación entre los miembros
del equipo de desarrollo web, de manera que las ideas puedan intercambiarse en reuniones
periódicas, en estas reuniones se mejora el proyecto y se eliminan los posibles obstáculos,
además todo el equipo se mantiene trabajando constantemente mientras el proyecto va siendo
utilizable desde su inicio, gracias a que existen varias entregas, en lugar de una sola al final.
 Un equipo motivado.
Este es un requisito indispensable que provee XP para tener al equipo satisfecho por
medio de reuniones para dar solución a problemas, a fin de generar una estrategia de
desarrollo exitosa, ya que según Hernández y Prieto (2002) explican que la motivación se
entiende como “Una fuerza que impulsa al individuo a actuar y a perseguir metas específicas;
de modo que es un proceso que puede provocar o modificar un determinado
comportamiento”. Es decir, un equipo motivado trabaja mucho mejor que uno frustrado, la
presión debe ser un reto y terminar debe ser una meta.

Hacer feliz al cliente.

La programación extrema provoca un equipo motivado que se mantendrá trabajando
constantemente para optimizar el tiempo y así tener mayor flexibilidad ante los cambios y
sea más productivo el proceso de desarrollo. De esta forma los desarrolladores cumplirán así
con todos los objetivos y el cliente estará satisfecho con el resultado exitoso que tendrá con
el trabajo del equipo.

Una metodología ágil tiene varios principios para llevarse a cabo, entre los más
importantes tenemos:

 Los individuos y sus interacciones son más importantes que los procesos y las
herramientas.
 El software que funciona es más importante que la documentación exhaustiva.
 Colaboración con el cliente en lugar de negociación de contratos.
 No hay que seguir un plan cerrado, sino adaptarse al cambio.

Para entender mejor el ciclo de desarrollo de XP en el que se utilizan estos principios,

es necesario conocer las 4 fases que componen su ciclo de vida:

Planeación.
En XP la planificación es un diálogo continuo entre las partes involucradas en el
proyecto, incluyendo al cliente, a los programadores y a los coordinadores, donde el proyecto
comienza recopilando las historias de usuarios, las que constituyen a los tradicionales casos
de uso, los cuales los programadores evalúan rápidamente el tiempo de desarrollo de cada
una. Los Conceptos básicos de la planificación son:
Las Historias de Usuarios. Representan una breve descripción del
comportamiento del sistema, se realizan por cada característica principal del sistema y son
utilizadas para cumplir estimaciones de tiempo y el plan de lanzamientos, así mismo
reemplazan un gran documento de requisitos y presiden la creación de las pruebas de
aceptación, cada historia de usuario debe ser lo suficientemente comprensible y delimitada
para que los programadores puedan implementarlas en unas semanas.
El Plan de Entregas (Release Plan). Es el cronograma resultado de una reunión
entre todos los actores del proyecto, después de escuchar las historias del usuario.
Plan de Iteraciones (Iteration Plan). Las historias de usuarios seleccionadas
para cada entrega son desarrolladas y probadas en un ciclo de iteración.
Reuniones Diarias de Seguimiento (Stand – Up Meeting). Para que el equipo se
mantenga en contacto, a fines de compartir problemas y soluciones, se ha optado por hacer
uso de medios de comunicación. La decisión es basada en el recurso del tiempo y
comodidad para los miembros del equipo, tomando en cuenta el traslado, la disponibilidad
de cada uno y el espacio dispuesto para la reunión. Además, la información queda
registrada y puede ser revisada las veces que sea necesario por todos los integrantes. Esto
garantiza la fluidez de la información. Entonces, Slack es una red dispuesta para el
desarrollo de proyectos, que brinda la facilidad de encuestas, mensajes directos,
organización de actividades, y cabe resaltar que facilita el contacto con los miembros a
cualquier hora que se requiera. A través de este medio los líderes y demás miembros del
equipo se comunican constantemente. Asimismo, los líderes empleando otra red
mantienen conferencias diarias. Por medio de Skype, las discusiones acerca de los tópicos
importantes del proyecto se realizan y luego son compartidas con el resto del equipo.

Diseño.
En XP los diseños son simples y claros. Los conceptos más importantes de diseño en esta
metodología son los siguientes:
Simplicidad. XP propone implementar el diseño más simple posible que funcione.
 Soluciones “Spike”. Son pequeños programas de prueba para explorar diferentes
soluciones.
Recodificación “Refactoring”. Las metodologías de XP sugieren recodificar cada
vez que sea necesario.
Metáforas. XP sugiere utilizar este concepto como una manera sencilla de explicar el
propósito del proyecto, así como guiar la estructura del mismo.

Codificación.
Es una actividad imprescindible para el desarrollo del software, para XP esta actividad
incluye:
Disponibilidad del Cliente. En XP el cliente está disponible durante todo el proyecto,
no solamente como apoyo a los desarrolladores, sino formando parte del grupo. El cliente
proporciona las historias de usuarios que no contienen los detalles necesarios para realizar el
desarrollo del código, por lo cual deben ser discutidos con el cliente y los desarrolladores
durante la etapa de desarrollo.
Uso de Estándares. Todo debe ser fácilmente entendible por todo el equipo para
facilitar la recodificación.
Programación Dirigida por las Pruebas (“Test-Driven Programming”). En la
metodología XP primero se escriben los test que el sistema debe pasar, luego el desarrollo
debe ser el mínimo necesario para pasar las pruebas previamente definidas.
Programación en Pares. XP propone que se desarrolle en pareja, ambos
programadores trabajando juntos en un mismo ordenador ya que, al trabajar en pares se
minimizan los errores y se logran mejores diseños, compensando la inversión en horas,
obteniendo un producto que por lo general es de mejor calidad que cuando el desarrollo se
realiza por programadores individuales.
Integraciones Permanentes: Los desarrolladores necesitan trabajar siempre con la
“última versión” es por eso que XP promueve publicar lo antes posible las nuevas versiones,
aunque no sean las últimas, siempre que estén libres de errores.
Propiedad Colectiva del Código. En un proyecto XP, todo el equipo puede contribuir
con nuevas ideas que apliquen a cualquier parte del proyecto.
 Ritmo Sostenido. XP indica que debe llevarse un ritmo sostenido de trabajo, es decir,
un ritmo constante y razonable sin sobrecargar de trabajo al equipo.

Pruebas.
Las características del software que no pueden ser demostradas mediante pruebas
simplemente no existen, en toda metodología de desarrollo del software son necesarias las
pruebas que dan oportunidad de saber si lo que se implementó es lo que en realidad lo que se
pensaba que se había implementado. Para esta fase XP propone tres técnicas a seguir:
Pruebas Unitarias. Todos los módulos deben de pasar las pruebas unitarias antes de
ser liberados o publicados.
Detección y Corrección de Errores. Si se encuentra un error éste debe ser corregido
inmediatamente, y se deben tener precauciones para que errores similares no vuelvan a
ocurrir.
Pruebas de Aceptación. Son creadas en base a las historias de usuarios, en cada ciclo
de la iteración del desarrollo. El Cliente debe especificar uno o diversos escenarios para
comprobar que una historia de usuario ha sido correctamente implementada.

Planificación Diseño Codificación Pruebas

Procesos XP. Fases de la metodología seleccionada.

Plan de trabajo
En un proyecto elaborado con XP al igual que para desarrollar en las otras
metodologías se necesita entender lo que el cliente necesita, estimar el esfuerzo, crear la
solución y entregar el producto final al cliente. Sin embargo, XP propone un ciclo de vida
dinámico, donde se admite expresamente que, en muchos casos, los clientes no son capaces
de especificar sus requerimientos al comienzo de un proyecto.
Por esto, en el plan de trabajo se debe realizar ciclos de desarrollo cortos (llamados
iteraciones), con entregables funcionales donde al finalizar cada ciclo se realizan entregas
parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor
del proyecto.
Este tipo de desarrollo se puede utilizar para proyectos en entornos complejos, donde
se necesita obtener resultados pronto (el cual es nuestro caso), donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la
productividad son fundamentales.
El plan de desarrollo debe definir las iteraciones necesarias para llevar a cabo el
proyecto, donde en cada iteración se proporciona un resultado completo y un incremento del
producto final, en cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo
y pruebas, pero utilizando un conjunto de reglas y prácticas que caracterizan a XP,
típicamente un proyecto con XP lleva 10 a 15 ciclos o iteraciones con duraciones de
aproximadamente 3 semanas cada una.

Planificación de la iteración

Definir las historias de usuarios con el cliente.

El cliente y los desarrolladores se reúnen para concretar y detallar de manera no
técnica lo que espera de la aplicación. Entonces, en conjunto se definen las historias y la
prioridad que tiene cada una de ellas para el cliente. De este modo, las iteraciones tratan
por orden de prioridad las historias. Así, el equipo de desarrollo cuenta con un plazo de 1
a 3 semanas para lograr una historia o las historias que se hayan estimado para la iteración.

Definir el Release planning.

Después de tener ya definidas las historias de usuario es necesario crear un plan de
publicaciones, donde se indiquen las historias que se crearán para cada versión del
programa y las fechas en las que se publicarán estas versiones.
 Después de un "Release planning" tienen que estar claros estos cuatro factores: los
objetivos que se deben cumplir (que son principalmente las historias que se deben
desarrollar en cada versión), el tiempo que tardarán en desarrollarse y publicarse las
versiones del programa, el número de personas que trabajarán en el desarrollo y cómo se
evaluará la calidad del trabajo realizado.

Planificar la iteración.
El proyecto se divide en iteraciones de menos de 3 semanas de duración, cada
iteración está compuesta de las historias de usuario definidas en el "Release planning"
para ser implementadas. Estas historias son divididas en tareas de entre 1 y 3 días de
duración que se asignarán a los programadores. En las primeras iteraciones se busca la
definición de una arquitectura base que se pueda presentar y que se vaya desarrollando a
lo largo de las iteraciones de manera incremental. En la última iteración ya debe de
cumplir con todos los requerimientos y entregarse como producto final. Es importante
tomar en cuenta que las iteraciones se siguen secuencialmente, es decir, una lleva a la otra,
y por lo tanto los objetivos no alcanzados le corresponden a la siguiente, tanto los que
hayan quedado incompletos como los que no funcionen como deberían.

Velocidad de la iteración.
Estimarla es muy sencillo, basta con contar el número de historias de usuario que
se pueden implementar en una iteración; de esta forma, se sabrá el cupo de historias que
se pueden desarrollar en las distintas iteraciones, en XP es necesario controlar que todas
las tareas se puedan desarrollar en el tiempo del que dispone la iteración, por lo cual es
conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada
hay que negociar con el cliente un nuevo "Release Plan".

Ejecución de la iteración.
Existe un plan de iteraciones donde las historias de usuarios seleccionadas para
cada entrega son desarrolladas y probadas en un ciclo de iteración, de acuerdo al orden
preestablecido.
 Cabe destacar que durante toda la iteración se realizan reuniones diarias de
seguimiento (para nuestro caso reuniones vía Skype por cuestiones de tiempo, distancia y
comodidad) con el objetivo de mantener la comunicación entre el equipo y compartir
problemas y soluciones.

Inspección y adaptación

En la metodología XP se usan test para comprobar el funcionamiento de los

códigos que se vayan implementando. El uso de los test en X.P es el siguiente:
1- Se desarrollan las aplicaciones que realizarán los test con un entorno de desarrollo
específico para test, es de destacar que en XP el test se crea antes de implementar el
código a fines de evitar que el test dependa del código que en un futuro se evaluará.
2- Se suben los test al repositorio de código acompañados del código que verifican.
Ningún código puede ser publicado en el repositorio sin que haya pasado su test de
funcionamiento, de esta forma, aseguramos el uso colectivo del código.
3- Se crean los test de aceptación: Estos test son creados y usados por los clientes para
comprobar que las distintas historias de usuario cumplen su cometido.

Herramientas de la Metodología Programación Extrema XP

Una de las grandes ventajas que tiene XP es ser una metodología de desarrollo del
software muy organizada, donde cada nueva iteración es planificada y se lleva registro de
cada tarea a realizar por medio de las siguientes herramientas que provee XP:

Historia de Usuario.
Compone toda la información relevante obtenida de la reunión del cliente y el
equipo.
Tabla 1
Planilla para las historias de usuarios
Atributo De La Historia De Usuario Descripción del atributo
Número Permite identificar a una historia de usuario

Usuario Persona que utilizará la funcionalidad del

sistema descrita en la historia de usuario

Nombre historia Describe de manera general a una historia

de usuario

Prioridad en negocio Grado de importancia que el cliente asigna

a una historia de usuario

Riesgo en Desarrollo Valor de complejidad que una historia de

usuario representa al equipo de desarrollo

Puntos Estimados Número de semanas que se necesitará para

el desarrollo de una historia de usuario

Iteración Asignada Número de iteración en que el cliente desea

que se implemente una historia de usuario

Programador Responsable Persona encargada de programar cada

historia de usuario

Descripción Información detallada de una historia de

usuario

Observaciones Campo opcional utilizado para aclarar, si es

necesario, el requerimiento descrito de una

historia de usuario.

Tareas de Ingenierías (Task Card).

Luego de llenar la planilla de historias de usuario se descompone en varias tareas
de ingeniería, las cuales describen las actividades que se realizarán en cada historia de
 usuario, así mismo las tareas de ingeniería se vinculan más al desarrollador, ya que permite
tener un acercamiento con el código.
Tabla 2
Planilla para tareas de ingeniería
Atributo De La Tarea De Ingeniería Descripción del atributo

Número de Tarea Permite identificar a una tarea de ingeniería

Número de Historia Número asignado de la historia

correspondiente

Nombre de Tarea Describe de manera general a una tarea de

ingeniería

Tipo de Tarea Tipo al que corresponde la tarea de

ingeniería

Puntos Estimados Número de días que se necesitará para el

desarrollo de una tarea de ingeniería

Fecha Inicio Fecha inicial de la creación de la tarea de

ingeniería

Fecha Fin Final concluida de la tarea de ingeniería

Programador Responsable Persona encargada de programar la tarea de

ingeniería

Descripción Información detallada de la tarea de

ingeniería
 Pruebas de Aceptación.
Son de vital importancia para el éxito de una iteración y el comienzo de la
siguiente, con lo cual el cliente puede conocer el avance en el desarrollo del sistema y a
los programadores lo que les resta por hacer. Además, permite una retroalimentación para
el desarrollo de las próximas historias de usuarios a ser entregadas, son comúnmente
llamadas pruebas del cliente, por lo que son realizadas por el encargado de verificar si las
historias de usuarios de cada iteración cumplen con la funcionalidad esperada.
Tabla 3
Planilla para las pruebas de aceptación
Atributo De La Prueba Aceptación Descripción del atributo

Código Único, permite identificar la prueba de

aceptación

Nº Historia de Usuario Número único que identifica a la historia de

usuario

Historia de Usuario Nombre que indica de manera general la

descripción de la historia de usuario

Condiciones de Ejecución Condiciones previas que deben cumplirse

para realizar la prueba de aceptación

Entrada/Pasos de Ejecución Pasos que siguen los usuarios para probar la

funcionalidad de la historia de usuario

Resultado Esperado Respuesta del sistema que el cliente espera,

después de haber ejecutado una

funcionalidad
 Evaluación de la Prueba: Nivel de satisfacción del cliente sobre la

respuesta del sistema. Los niveles son:

Aprobada y No Aprobada.

Tarjetas CRC (Clases – Responsabilidades – Colaboración).

Permiten conocer que clases componen el sistema y cuales interactúan entre sí. Se
dividen en tres secciones: Nombre de la Clase, Responsabilidades y Colaboradores.
Tabla 4
Planilla para las tarjetas CRC
Atributo De La Tarjeta CRC Descripción del atributo
Nombre de la Clase Nombre de la clase al cual hace referencia
la tarjeta
Responsabilidades Atributos y operaciones de la clase
Colaboradores Clases que colaboran con la clase citada en
la tarjeta

Participantes en el proyecto

El equipo de trabajo estará conformado por diferentes personas con determinados

cargos y responsabilidades, los cuales son:

Programador.
Es el Responsable de implementar las historias de usuario por el cliente, además,
estima el tiempo de desarrollo de cada historia de usuario para que el cliente pueda
asignarle prioridad dentro de la iteración y de diseñar y ejecutar los test de unidad del
código que ha implementado o modificado.
 Cliente.
Determina la funcionalidad que se pretende en cada iteración y define las
prioridades de implementación según el valor de negocio que aporta cada historia, además
es el responsable de diseñar y ejecutar los test de aceptación.

Encargado de pruebas (tester).

Es el encargado de ejecutar las pruebas regularmente, difunde los resultados dentro
del equipo y es también el responsable de las herramientas de soporte para pruebas.

Encargado de seguimiento (tracker).

Su función principal consiste en seguir la evolución de las estimaciones realizadas
por los programadores y compararlas con el tiempo real de desarrollo para poder brindar
información estadística en lo que refiere a la calidad de las estimaciones para que puedan
ser mejoradas.

Entrenador (coach).
Es el encargado de iniciar y de guiar a las personas del equipo en poner en marcha
cada una de las prácticas de la metodología XP.

Consultor.
Es un miembro externo del equipo con un conocimiento específico en algún tema
necesario para el proyecto, nos guiará para resolver un problema en específico.

Gestor (big boss).

Es el vínculo entre el cliente y programadores, el mismo debe ser experto en
tecnología y labores de gestión. Entre sus principales funciones están la de coordinar,
obtener recursos necesarios, manejar los problemas que se generen y administrar las
reuniones.
 Plan de trabajo

Iteración 1
Nombre de tarea Duración Comienzo Fin
lun jue
Iteración 1 14 días
16/01/17 02/02/17
lun sáb
Planificación 5 días
16/01/17 21/01/17
Definición de la metodología a lun mié
3 días
trabajar 16/01/17 18/01/17
lun mar
Definición de los objetivos 2 días
16/01/17 17/01/17
Definición de las limitaciones lun mar
2 días
del proyecto 16/01/17 17/01/17
Análisis de los requerimientos mar jue
3 días
funcionales y no funcionales 17/01/17 19/01/17
Definición de los resultados del mar mar
1 día
proyecto 17/01/17 17/01/17
Planificación y adquisición de jue vie
2 días
recursos 19/01/17 20/01/17
Planeación de la calidad y los vie sáb
2 días
riesgos 20/01/17 21/01/17
Planeación de la comunicación y vie sáb
2 días
seguridad 20/01/17 21/01/17
mié vie
Diseño 3 días
18/01/17 20/01/17
Descripción de la arquitectura mié vie
3 días
general del software 18/01/17 20/01/17
 Identificación de sus
mié mié
componentes y su organización y 1 día
18/01/17 18/01/17
relaciones en el sistema.
Definición y estructura de los mié mié
1 día
componentes y datos. 18/01/17 18/01/17
Definición de la arquitectura de mié vie
3 días
la base de datos 18/01/17 20/01/17
Definición de la fase de login y mié vie
3 días
registro 18/01/17 20/01/17
jue mar
Codificación 9 días
19/01/17 31/01/17
Creación de la base de datos jue lun
3 días
general del software 19/01/17 23/01/17
Creación de la vista de la fase jue lun
3 días
del login 19/01/17 23/01/17
Creación de la vista de la fase jue lun
3 días
del registro del usuario 19/01/17 23/01/17
Codificación de la fase del lun lun
6 días
registro del usuario 23/01/17 30/01/17
Codificación de la fase del login mié mar
5 días
del usuario 25/01/17 31/01/17
lun jue
Pruebas 4 días
30/01/17 02/02/17
lun mié
Realizar pruebas unitarias 3 días
30/01/17 01/02/17
mar jue
Ajuste y adecuaciones 3 días
31/01/17 02/02/17

Iteración 2
Nombre de tarea Duración Comienzo Fin
 jue mié
Iteración 2 15 días
02/02/17 22/02/17
jue mar
Planificación 4 días
02/02/17 07/02/17
Análisis de los requerimientos jue vie
2 días
funcionales y no funcionales 02/02/17 03/02/17
Planificación y adquisición de sáb lun
2 días
recursos 04/02/17 06/02/17
Planeación de la calidad y los vie mar
3 días
riesgos 03/02/17 07/02/17
Planeación de la comunicación y vie mar
3 días
seguridad 03/02/17 07/02/17
sáb mié
Diseño 3 días
04/02/17 08/02/17
Definición de la creación y sáb mié
4 días
gestión de eventos 04/02/17 08/02/17
Definición de los registro de sáb mié
4 días
actividades de los usuarios 04/02/17 08/02/17
Definición de la generación de sáb mié
4 días
horarios 04/02/17 08/02/17
Definición de los registro de sáb mié
4 días
ponentes 04/02/17 08/02/17
mar lun
Codificación 10 días
07/02/17 20/02/17
Creación de las vistas de la mar jue
3 días
creación y gestión de eventos 07/02/17 09/02/17
Creación de las vistas del
mar jue
registro de actividades de los 3 días
07/02/17 09/02/17
usuarios
 Creación de las vistas del mar jue
3 días
registro de ponentes 07/02/17 09/02/17
Codificación de la creación y jue mar
4 días
gestión de eventos 09/02/17 14/02/17
Codificación del registro de mar lun
5 días
actividades de los usuarios 14/02/17 20/02/17
Codificación de la generación de lun lun
6 días
horarios 13/02/17 20/02/17
Codificación del registro de lun lun
6 días
ponentes 13/02/17 20/02/17
jue mié
Pruebas 5 días
16/02/17 22/02/17
jue mar
Realizar pruebas unitarias 4 días
16/02/17 21/02/17
vie mié
Ajuste y adecuaciones 4 días
17/02/17 22/02/17

Iteración 3
Nombre de tarea Duración Comienzo Fin
mié mar
Iteración 3 15 días
22/02/17 14/03/17
mié vie
Planificación 3 días
22/02/17 24/02/17
Analisis de los requerimientos mié jue
2 días
funcionales y no funcionales 22/02/17 23/02/17
Planificación y adquisición de jue jue
1 día
recursos 23/02/17 23/02/17
Planeación de la calidad y los jue vie
2 días
riesgos 23/02/17 24/02/17
 Planeación de la comunicaión y jue vie
2 días
seguridad 23/02/17 24/02/17
jue lun
Diseño 3 días
23/02/17 27/02/17
Definición para generar jue lun
3 días
certificados en PDF 23/02/17 27/02/17
Definción para hacer consultas jue lun
3 días
de los certificados 23/02/17 27/02/17
Definición para gestionar jue lun
3 días
asistencia de los usuarios 23/02/17 27/02/17
sáb mié
Codificación 9 días
25/02/17 08/03/17
Creación de las vistas para hacer sáb mar
3 días
consultas de los certificados 25/02/17 28/02/17
Codificación de la generación de mié mié
6 días
certificados en PDF 01/03/17 08/03/17
Codificación para las consultas mar mié
7 días
de los certificados 28/02/17 08/03/17
Codificación para la gestión de
mié mié
asistencia de los usuarios a los 6 días
01/03/17 08/03/17
eventos
mié mar
Pruebas 5 días
08/03/17 14/03/17
mié lun
Realizar pruebas unitarias 4 días
08/03/17 13/03/17
jue mar
Ajuste y adecuaciones 4 días
09/03/17 14/03/17

Hitos
 Actividad
 Inicio del Proyecto
 Inicio de la Fase dePlanificación
 Entrega y Aprobacion de la metodologia
 Entrega y Aprobacion de los Objetivos
 Entrega y aprovacion de las limitaciones del proyecto
 Entrega y aprovacion de lagestion de riesgos
 Entrega y Finalizacion de la fase de Planeación
 Primera entrega del proyecto
 Inicio Fase de Diseño
 Entrega de la selección de herramienta de desarrollo
 Entrega y Aprobacion de la arquitectura del software planteada
 Aprobacion de la descrpción de la arquitectura planteda para el software
(componentes, organización y relacion en el sistema)
 Aprobacion del diseño detallado del softwatre
 Aprovacion del modelaje de datos
 Aprobacion de los componentes y datos a utilizar en el proyecto
 Aprobacion de la interface plateada para el software
 Finalizacion de la fase de Diseño
 Inicio fase de Codificación
 Aprobacion de la base de datos a utilizar
 Aprovacion codigo empleao para la face de registo
 Aprovacion del codigo empleado para la face de Inscrpción
 Aprovacioncodigo empleado para el chequeo de registro
 Aprovacion del codigo empleado para el sistema de emisión y consulta
 Finalizacios de la fase de Codificación
 Inicio de la fase de Pruebas
 Aprovacion de los ajustes realizados
 Finalizacion de la fase de Pruebas
 Entrega Final del proyecto
 Departamentos del proyecto

El equipo de trabajo estará conformado por diversos proyectos con distintos cargos
y/o responsabilidades, los cuales son:

Departamento de oficina de proyecto

El departamento de oficina de proyecto posee como principal función la
planeación, organización, dirección y control de un proyecto con la finalidad de poder
sacar el máximo aprovechamiento de los recursos disponibles y su utilización de manera
eficiente.
Este departamento está encargado de decidir el qué, quién, cómo, cuándo y por
qué se hará el proyecto, determinar los recursos que se necesitarán, revisar y ajustar el
plan de acuerdo con los resultados de control y coordinar durante todo el proceso de
planeación. Es importante resaltar otras de sus funciones como lo es poder identificar,
definir y dividir el trabajo a realizar, se agrupan y definen los puestos, se proporcionan los
recursos necesarios y se asignan los grados de autoridad.
Entre otras actividades que realizan oficina u administración de proyecto es definir
metodología a trabajar, establecer los objetivos generales y específicos, llevar a cabo la
planificación, definir hitos, la finalización de las fases de planeación.

Departamento de diseño grafico

Diseño gráfico tiene la responsabilidad de definir el enfoque estratégico, de
precisar el planteamiento táctico y operativo del diseño del sistema, y de definir la ventaja
competitiva para el proyecto gracias a las aportaciones del diseño. Además se basa en
poder captar las ideas verbales de los clientes y desarrollarlas de una manera creativa e
intuitiva para de esta forma lograr captar tanto la información y la emoción que el cliente
está tratando de mostrar, las definición de las interfaces que posee el proyecto y en el
trabajo visual enriqueciendo la forma de la construcción de archivos en el proyecto, su
principal aportación es la conceptualización y el desarrollo del componente gráfico.
Departamento de desarrollo
Este departamento posee la responsabilidad de poder llevar a cabo la realización y
automatización de los requerimientos de información solicitados por el usuario para poder
desarrollar y lograr la implementación del software mediante la codificación.
Internamente el departamento se encuentra conformado en dos áreas principales las cuales
son arquitectura y manejo de base de datos.
El área de arquitectura posee como finalidad definir, seleccionar y diseñar
partiendo de los requerimientos y restricciones. Los requerimientos son aquellos
prefijados para el sistema, estos competen de tipo funcional y a su vez también otros
objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción son
importantes. Las restricciones poseen limitaciones derivadas de las tecnologías
disponibles para implementar en el software.
El área de manejo de base de datos tiene como función poder definir y organizar
el contenido, las relaciones y la estructura de los datos necesarios para poder construir e
implementar una base de datos. Esto implica la utilización de un sistema de administración
de base de datos para llevar a cabo el desarrollo de consultas, formularios, reportes
necesarios en la implementación de nuestro software. Además garantiza la correcta
implementación del sistema de base de datos y su integración en el software eso
permitiendo poder aumentar la eficacia, lograr que las tareas puedan llevarse a cabo con
mayor rapidez y agilidad debido a la simplificación de los mismos, mejorar la seguridad
de los datos que serán almacenados y con todos estos factores, maximizar los tiempos y
poder llevar a cabo una mejora en la productividad.

Departamento SQA
El departamento de gestión de calidad también conocido como SQA, es el
encargado de poder asegurar la calidad del proyecto y del proceso utilizado en su
desarrollo. Para asegurar la calidad, este departamento trabaja en conjunto con todos los
demás evaluando y a la vez siendo independiente y manteniendo una postura objetiva
debido que es el encargado de revisar la calidad de los entregables de planificación del
proyecto y los entregables de valoración del proyecto. Además evalúa el nivel de apego o
fidelidad al modelo de proceso de desarrollo de software y a los planes de Verificación,
Gestión de Proyecto y Gestión de Calidad, documentando y establecidos.
Esta encargado de poder verificar y evaluar la calidad en los procesos, el diseño
implementado, en la codificación, documentación, soporte, mantenimiento, seguridad y el
proyecto finalizado en general que cumpla con todos los estándares establecidos
anteriormente. En la realización de sus actividades es importante la realización de pruebas
o testing con la finalidad de poder determinar y detectar a tiempo los defectos en el
proyecto contrastando los resultados esperados de un programa informático con los
resultados reales de un conjunto dado de entradas.