You are on page 1of 24

UNIVERSIDAD NACIONAL DE

HUANCAVELICA FALCULTAD DE

DEDICATORIA
A mis padres por el esfuerzo que signific por su apoyo incondicional, a mi familia que
siempre me apoya y en especial a una ta muy especial. Finalmente a Dios que lo hizo
posible.
A mis padres, a mi hermano y a mis amigos por todo el apoyo y confianza que han
depositado en
m.
Aldo Vargas

VELNEO

H.

ALUMNO: VARGAS HUAYAHURIMA ALDO


DOCENTE: ING. CRISTOBAL LARA ROLY
Ciclo: VIII

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

AGRADECIMIENTOS
Todos los xitos conseguidos hasta ahora y los que se obtendrn en el futuro tendrn
como primer responsable a la Universidad quin nos proporcion las herramientas para
desempearnos adecuadamente en nuestra profesin, para ella son los primeros
agradecimientos.
Mi familia quien me apoya en mi formacin universitario en todos los sentidos. Sin su
apoyo no habra sido posible el logro de una meta tan importante como lo es formarme
profesionalmente, a ellos un sincero agradecimiento por su esfuerzo y dedicacin.
Finalmente a mi docente que me impulsa en toda mi formacin acadmica.

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

OBJETIVOS
OBJETIVO GENERAL.
Realizar una aplicacin prctica con la metodologa gil XP a travs del desarrollo de
un software orientado a una universidad.
OBJETIVOS ESPECFICOS

Consultar acerca de la metodologa XP para el desarrollo del software.


Disear en compaa del cliente las iteraciones.
Desarrollar las tareas planteadas en cada una de las iteraciones.
Realizar la documentacin del proyecto segn la gua XP.
Concluir sobre la conveniencia de la utilizacin de la metodologa XP en este
proyecto basndose en los resultados obtenidos.

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

JUSTIFICACIN
Al ser recientes las metodologas giles (aos 90s), no han sido estudiadas
suficientemente por la comunidad acadmica, generando desconocimiento de sus
bondades. La Escuela Profesional de Ingeniera de Sistemas de la Universidad
nacional de Huancavelica no ha sido ajena a este fenmeno en el sentido que no ha
realizado muchos estudios sobre el tema y menos aplicaciones prcticas que
involucren el paradigma de las metodologas giles. Por tal motivo se plantea la
necesidad de explorar a mayor profundidad dicho campo a travs de ejercicios
prcticos debidamente documentados. En este orden de ideas es necesario analizar
aspectos puntuales tales como las caractersticas de los clientes, detalles tcnicos de
las soluciones y prestar especial atencin a la naturaleza cambiante de los
requerimientos.

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

INTRODUCCIN
Las metodologas giles tienen un origen reciente en el entorno de la ingeniera de
software comparada con las metodologas pesadas. Su origen est ligado a los
constantes inconvenientes que se presentaban en proyectos con algunas
caractersticas, en los cuales la utilizacin de las metodologas pesadas era motivo de
fracaso.
En la dcada de los 90, surge eXtreme Programming, mejor conocida como XP, una
nueva metodologa catalogada entre las giles por sus aportes al manifiesto gil. Su
creador, Kent Beck se convirti en el padre de la programacin extrema.
En Per, la programacin extrema no se ha profundizado debido a su reciente
aparicin. Tambin cabe sealar la escasez de documentacin referente a la misma y
de los trabajos realizados emplendola.
El presente documento es la exposicin de una experiencia prctica en la cual se
emple
Extreme Programming. Debido al entorno acadmicas que rodearon al proyecto se
presentaron circunstancias especiales las cuales son detalladas en el cuerpo del
documento, por lo cual la metodologa debi ser ajustada.
Es importante aclarar que en ningn momento se pretende hacer una evaluacin o
juicio de la metodologa empleada debido que no es posible tener conclusiones
generales a partir de un solo caso de estudio. Solo se hacen comentarios sobre la
experiencia en particular y la forma como fue aplicada la metodologa.

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

PROCESO DE DESARROLLO EN XP
Todo proyecto de software en XP inicia con una o varias reuniones con el cliente,
en las cuales se da claridad a la necesidad puntual del mismo a travs de las
historias de usuario.
Estas tambin sirven de base para crear una metfora del sistema con el cual
todo el equipo de trabajo tendr una idea general de la aplicacin a implementar.
Con base en las historias de usuario se crean las pruebas de aceptacin las
cuales deben ser diseadas antes de iniciar la codificacin.

1. PLANEACIN
A continuacin se describe la experiencia obtenida en la realizacin del proyecto.
Inicialmente se comenta sobre cada uno de los aspectos que XP propone para
etapa de planeacin. Para cada uno de los elementos se enuncia lo que la teora
sobre XP recomienda contrastndola con la experiencia real en la realizacin del
proyecto. Entre los elementos a discutir para esta parte se encuentran las
historias de usuario, el plan de entregas, lo relacionado con las iteraciones como
las modificaciones que se aplicaron a XP para hacerla ms adecuada para el
proyecto.
En esta parte se encontrar la misma estructura de la seccin de planeacin del
marco terico. Para cada apartado se ver una serie de ideas que resumen la
teora contrastada con la interpretacin, aplicacin y resultados en la prctica.
1.1 HISTORIAS DE USUARIO
Lo que dice XP
o Escritas por el usuario.
o Terminologa del cliente.
ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

o Bajo nivel de detalle


o Sirve de base para estimar los tiempos de implementacin

Experiencia

Si bien el cliente no fue quien escribi personalmente las historias de


usuario, fue l quien dise su contenido y dirigi la redaccin de las
mismas, debido a que no tena los conocimientos necesarios en formato
para elaborarlas. A pesar de lo anterior, el propsito de las mismas no se
vio alterado de alguna forma, manteniendo no solamente la terminologa
del cliente al punto en que este fuera autosuficiente en la comprensin de
su contenido, sino tambin su oficio como punto de partida en la
planificacin del proyecto.
Desde el punto de vista del nivel de detalle, se sigui la directiva en el
sentido de no profundizar ni en descripciones ni en procesos,
mantenindolas de esta forma breve y clara. Sin embargo se logr abstraer
la informacin suficiente de ellas para realizar su implementacin sin
requerir demasiadas aclaraciones por parte del cliente, siendo factor
fundamental para no ocasionar retrasos motivados por falta de claridad en
los requerimientos.
1.2 VELOCIDAD DEL PROYECTO

Lo que dice XP
o Nmero de historias de usuario o tareas de programacin
realizadas por iteracin.
o Sirve de ayuda para estimar la cantidad de historias de usuario a
implementar en una determinada iteracin
Experiencia
El nmero de historias de usuario realizadas por iteracin no fue una
buena medida de la velocidad del proyecto debido que no todas tenan el
mismo nivel de dificultad y por tanto el mismo requerimiento de horas de
desarrollo. Por esto se encontr que mientras en la segunda iteracin se
trabajaron menos horas semanales en comparacin con las dems.

1.3 ENTREGAS PEQUEAS

Lo que dice XP
o Entregas funcionales del proyecto frecuentemente

Experiencia
Debido a que las iteraciones tenan unas duraciones largas, fue al
trmino de este plazo que se realizaron entregas, las cuales siempre
ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

fueron funcionales, lo que quiere decir que al momento de la entrega


estaban en condiciones de ser puestas en funcionamiento en las
instalaciones del cliente. Esto represent un xito en el desarrollo del
proyecto ya que mantena el inters del cliente en continuarlo debido a
que estaba viendo resultados en el corto plazo.
Para las entregas se fijaron las siguientes fechas:
Iteracin
Primera

Fecha
01 24 de diciembre

Duracin
24 das

2. DISEO
A diferencia de las metodologas pesadas, el diseo se realiza durante todo el
tiempo de vida del proyecto, siendo constantemente revisado y muy
probablemente modificado debido a cambios presentados durante el desarrollo.
En esta parte se muestra una estructura similar a la anterior donde se observar
para cada uno de los elementos constitutivos de dicha etapa.
2.1 SIMPLICIDAD

Lo que dice XP
o El diseo debe ser sencillo.
o Slo se crearn diagramas tiles.
Experiencia
En lo que respecta a la sencillez del diseo, se acogi la recomendacin
de XP, slo invirtiendo el tiempo exclusivamente necesario en elaboracin
de diagramas y diseo de interfaz grfica. A consecuencia de esta
decisin se debieron hacer algunos sacrificios. Al no haber hecho muchos
diagramas, la orientacin a objetos no fue tan completa, sacrificando de
esta forma escalabilidad, versatilidad y elegancia del diseo, lo que fue
considerado un precio justo a cambio del cumplimiento de los plazos.
Desde el punto de vista de las interfaces, tampoco se invirti mucho
tiempo en su diseo, sin embargo se prest mucha atencin a ubicar los
elementos tal y como el cliente las haba solicitado y presentndolos en
una forma elegante pero sencilla.

2.2 METFORA DEL SISTEMA

Lo que dice XP
o Plasmar la arquitectura del sistema en una historia.
ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

o Convencin de nombres para los objetos del sistema


Experiencia
Debido que el programa es una aplicacin sencilla y de fcil comprensin
tanto para el desarrollador como para el cliente, no se requiri del empleo
de una metfora, manteniendo todos los nombres en contexto con una
aplicacin.
El poseer una metfora que incluya una convencin de nombres clara
facilita enormemente el logro del objetivo de la propiedad colectiva del
cdigo ya que con solo ver el nombre de un objeto o de un mtodo se
puede tener una claridad bastante amplia sobre la funcin que este
desempea y el lugar que ocupa dentro de todo el sistema.

2.3 TARJETAS CRC

Lo que dice XP
Su principal utilidad es dejar el enfoque procedimental y entrar al modelo
orientado a objetos. Todo el
desempeo y participacin en su
elaboracin.

Experiencia
Una de las principales piezas de diseo empleada en el proyecto fueron
las tarjetas CRC que no slo sirvieron como columna vertebral de este,
sino que tambin fueron la base del modelo Entidad Relacin, elaborado
para modelar la base de datos. Cada Tarjeta CRC se convirti en un
objeto, sus responsabilidades en mtodos pblicos y sus colaboradores
en llamados a otras clases.
En el proceso de elaboracin de las tarjetas CRC el miembro del equipo
estuvo presente manipulndolas, de modo tal que tanto el diseo fue
producto de la participacin del desarrollador, como el resultado del
mismo fue ampliamente asimilado, favoreciendo la propiedad colectiva del
cdigo.
3. CODIFICACION

En metodologas pesadas, la codificacin es un proceso al cual solo se llega


despus de largas fases de anlisis y diseo de las que queda una gran
cantidad de documentacin a partir de la cual el proceso de codificacin es
relativamente sencillo. En XP el proceso es muy diferente. Prcticamente desde
un principio se inicia con la codificacin, favoreciendo el logro del objetivo de
estar haciendo entregas frecuentemente al cliente.

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Algunos de los elementos ms importantes en cuanto a la codificacin son que,


el cliente siempre debe estar presente en esta, se debe trabajar en parejas y
debe haber una propiedad colectiva del cdigo.
3.1 CLIENTE SIEMPRE PRESENTE

Lo que dice XP
o El cliente debe estar disponible en el sitio de trabajo
o El cliente es fundamental para solucionar dudas cara a cara
Experiencia
La idea de tener al cliente, un representante de ste o a un usuario no es
fcil de asimilar si se consideran los costos que esto representa. En el
caso de este proyecto, el cliente no poda desplazarse a ninguno de los
lugares de trabajo del desarrollador dado que deba estar al de su cargo.

3.2 CODIFICAR PRIMERO LA PRUEBA


Lo que dice XP
o Escribir primero la prueba que el cdigo.
o El tiempo de escribir una prueba y luego el cdigo del programa
para dicha prueba es menor que solo escribir el cdigo.
o Escribir pruebas primero permite identificar los casos especiales
que deber pasar el cdigo.
Experiencia
Todos los elementos presentan obstculos en el desarrollo de las
pruebas, y plantearon una inquietud importante sobre el alcance del
concepto codificar primero las pruebas. Se trata de codificar SIEMPRE
una prueba antes que el cdigo, o solo aquellas clases encargadas de
realizar la lgica del negocio? Debido que XP no tiene una respuesta clara
a esta inquietud el grupo de desarrollo opt por probar solo aquellas
clases que ejecutan la lgica del negocio, que en definitiva son las ms
importantes y de las cuales se debe tener garanta de estar muy bien
construidas.
3.3 TODA LA PRODUCCIN DE CDIGO DEBE SER HECHA EN
PAREJAS

Lo que dice XP
o Toda la produccin de cdigo debe ser hecha en parejas sentadas
frente a un nico computador.
o Al trabajar en parejas se tiene un diseo de mejor calidad y un
cdigo ms organizado.
o Al trabajar en parejas se solucionan los problemas ms fcilmente.
ALUMNO: VARGAS HUAYAHURIMA ALDO

1
0

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Experiencia

El no contar con una permanente comunicacin complico seriamente el


cumplimiento del objetivo de programar en parejas. Por otro lado al solo haber
una pareja de programadores se haca completamente imposible cumplir con el
objetivo de tener varias parejas de programadores trabajando uniformemente.

4. PRUEBAS
XP enfatiza en la realizacin de un sin nmero de pruebas a lo largo del
proyecto, con el fin de asegurar en todo momento la realizacin de lo planteado
en el diseo. En este proceso no slo participa el equipo de desarrollo, tambin
es importante los aportes del cliente, sobre todo en las pruebas de aceptacin.
Esta parte se divide en partes que corresponden a las pruebas unitarias, de
aceptacin y qu hacer cuando se encuentra un error.
4.1 PRUEBAS UNITARIAS

Lo que dice XP
o Las pruebas deben ser escritas antes que los mtodos.
o Su implementacin y ejecucin deben consumir el menor tiempo
posible.

Experiencia
La creacin de pruebas fue una experiencia nueva para el desarrollador
al ser una de las reglas de la metodologa XP que no se haba llegado a
utilizar en proyectos anteriores. Debido a esto, la realizacin de pruebas al
principio del proyecto fue traumtica y demand ms tiempo de lo
planeado, lo cual no fue conveniente ya que la metodologa intenta
disminuir los cuellos de botella, no aumentarlos.
Segn XP, se deben crear todas las pruebas de una clase antes de
comenzar a desarrollar los mtodos. En la experiencia fue conveniente
realizar las pruebas individualmente, debido a que se producan errores al
ejecutar todas las pruebas en un solo llamado. Se descubri que este
inconveniente estaba relacionado con la base de datos y no con los
mtodos, lo que al principio del proyecto aplic dificultad al evaluar si un
mtodo haba pasado o no la prueba. Una vez que se descubri este error
se empez a ejecutar las pruebas por grupos en lugar de ejecutarlas
todas de una vez. De esta forma no haba problemas de comunicacin
con la BD y se garantizaba que si una prueba fallaba era solo por errores
de lgica.
ALUMNO: VARGAS HUAYAHURIMA ALDO

1
1

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

4.2 Pruebas de aceptacin

Lo que dice XP.


o Se deben disear las pruebas de aceptacin con base en las
historias de usuario
Experiencia.
Tres elementos permitieron al grupo de desarrollo disear las pruebas de
aceptacin. En primer lugar el tipo de sistema implementado era
suficientemente sencillo y conocido por el desarrollador, principalmente
porque el desarrollador tiene contacto permanente con el cliente. En
segundo lugar las reuniones de las cuales se obtuvieron las historias de
usuario fueron plasmadas con lo cual fue posible la reconstruccin de las
pruebas de aceptacin por parte del desarrollador sin toda la intervencin
del cliente. En tercer lugar el cliente acept el delegar esta funcin de
diseo de las pruebas debido que su disponibilidad de tiempo, como ya es
mencionada en otros apartados del documento, se lo impidi.

4.3 Cuando se encuentra un error

Lo que dice XP
o Al encontrar un error debe escribirse primero la prueba antes que
corregirlo.

Experiencia
Como se mencion antes, no se crearon unidades de prueba para los
errores de las interfaces grficas, estos tipos de inconvenientes fueron
solucionados mediante pruebas manuales, es decir, sin la ayuda de la
herramienta JUnit debido que el API no soporta este tipo de pruebas.
Estas pruebas manuales consistan en cajas negras donde se verificaba
la solucin del problema mediante la ejecucin del programa.

ALUMNO: VARGAS HUAYAHURIMA ALDO

1
2

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

CONCLUSIONES
La experiencia del desarrollo del proyecto result satisfactoria. La eleccin y aplicacin
de dicha metodologa dadas las caractersticas del problema arroj resultados positivos
en trminos de satisfaccin del cliente, cumplimiento de los plazos y buen ambiente de
trabajo. Se encontr que la metodologa se ajust muy bien no solo al tipo de cliente y
a las caractersticas del problema, tambin result adecuada para el entorno de trabajo
y las caractersticas del desarrollador.

ALUMNO: VARGAS HUAYAHURIMA ALDO

1
3

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

ANEXOS
ALUMNO: VARGAS HUAYAHURIMA ALDO

1
4

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

HISTORIAS DE USUARIO
Tabla 1.1 Historia de Usuario Registro docentes.

Historia de Usuario
Nmero: 1
Usuario: Administrador
Nombre historia: Registro de los datos de docentes.
Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 1

Iteracin asignada: 1

Programador responsable: Aldo Vargas


Descripcin: Permitir insertar los datos de docentes en la aplicacin.
Observaciones: La informacin de nombre es como rasgo nico de
autentificacin del personal docente.

Tabla 1.2 Historia de Usuario bsqueda del docente.

Historia de Usuario
Nmero: 2
Usuario: Administrador
Nombre historia: Bsqueda de los datos personales de docentes.
Prioridad en negocio: Media

Riesgo en desarrollo: Media

Puntos estimados: 0,2

Iteracin asignada: 1

Programador responsable: Aldo Vargas

ALUMNO: VARGAS HUAYAHURIMA ALDO

1
5

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Descripcin: Permitir realizar la bsqueda de los datos de docentes en la


aplicacin.
Observaciones:
Tabla 1.3 Historia de Usuario registro de alumnos.

Historia de Usuario
Nmero: 3
Usuario: Administrador
Nombre historia: Registro de datos de alumnos.
Prioridad en negocio: Alta
Riesgo en desarrollo: Alta
Puntos estimados: 0.5

Iteracin asignada: 1

Programador responsable: Aldo Vargas


Descripcin: Podr autentificarse en el sistema mediante el cdigo de
barras de carnet o DNI registrando la hora de entrada y salida.
Observaciones: Solo podr llevar cursos el estudiante previo
almacenamiento en la base de datos de la aplicacin.
Tabla 1.4 Historia de Usuario bsqueda de alumnos.

Historia de Usuario
Nmero: 4
Usuario: Administrador.
Nombre historia: Bsqueda de los datos personales de alumnos.
Prioridad en negocio: Alta
Riesgo en desarrollo: Alta
Puntos estimados: 0.3

Iteracin asignada: 1

Programador responsable: Aldo Vargas


Descripcin: Permitir realizar la bsqueda de los datos de alumnos en la
aplicacin
Observaciones:

Tabla 1.5 Historia de Usuario registro de cursos

Historia de Usuario
Nmero: 5
Usuario: Administrador
Nombre historia: Registro de datos de los cursos.
Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 0.1

Iteracin asignada: 1

Programador responsable: Aldo Vargas


Descripcin: se registra los cursos depende al plan de estudios.
Observaciones:
Tabla 1.6 Historia de Usuario bsqueda de cursos

ALUMNO: VARGAS HUAYAHURIMA ALDO

1
6

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Historia de Usuario
Nmero: 6
Usuario: Administrador.
Nombre historia: Bsqueda de cursos.
Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 0.4

Iteracin asignada: 1

Programador responsable: Aldo Vargas


Descripcin: Permitir realizar la bsqueda de los datos de los cursos en la
aplicacin
Observaciones:

Tabla 1.7 Historia de Usuario registro de ciclos.

Nmero: 7

Historia de Usuario
Usuario: Administrador.

Nombre historia: Registro de ciclos.


Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 0.2

Iteracin asignada: 1

Programador responsable: Aldo Vargas


Descripcin: se registra los ciclos de I hasta el X.
Observaciones:
Tabla 1.8 Historia de Usuario bsqueda de ciclos.

Historia de Usuario
Nmero: 8
Usuario: Administrador.
Nombre historia: Bsqueda de ciclos
Prioridad en negocio: Alta
Riesgo en desarrollo: Alta
Puntos estimados: 1
Iteracin asignada: 1
Programador responsable: Aldo Vargas
Descripcin: Permitir realizar la bsqueda de los ciclos en la aplicacin
Observaciones: Los datos correspondientes a los ciclos solo sern de I a X.

Iteraciones
ALUMNO: VARGAS HUAYAHURIMA ALDO

1
7

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Una vez identificadas las historias de usuarios del sistema y estimado el esfuerzo
dedicado a la realizacin de cada una de estas se procede a la planificacin de la
etapa de implementacin del proyecto. De acuerdo a lo mencionado anteriormente
se decidi realizar dicha planificacin en una sola iteracin:
Tareas
Tabla 1.9 Tarea Registro de los datos de docentes

Tarea
Nmero Tarea: 1
Nmero Historia: 1
Nombre Tarea: Registro de los datos de docentes y estudiantes.
Tipo de Tarea: Desarrollo
Puntos Estimados: 0.4
Fecha Inicio: 01/12/15

Fecha Fin: 02 /12/ 15

Programador Responsable: Aldo Vargas


Descripcin: Se disear la interfaz para insertar los datos de docentes
donde se muestren todos los datos que se almacenan en la aplicacin.

Tabla 1.10 Tarea Registro de los datos de docentes

Tarea
Nmero Tarea: 2
Nmero Historia: 1
Nombre Tarea: Registro de los datos de docentes.
Tipo de Tarea: Desarrollo
Puntos Estimados: 0.3
Fecha Inicio: 03/12/15
Fecha Fin: 04 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar el insertar de los datos de docentes y se
almacenar en la aplicacin.
Tabla 1.11 Tarea bsqueda de docente

Tarea
Nmero Tarea: 2
Nmero Historia: 2
Nombre Tarea: Bsqueda de los datos de docentes.
Tipo de Tarea: Desarrollo
Puntos Estimados: 0.3
Fecha Inicio: 05/12/15
Fecha Fin: 06 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar la bsqueda de datos de docente almacenada
en la aplicacin.
Tabla 1.12 Tarea registro de alumnos

Tarea
Nmero Tarea: 4
Nmero Historia: 3
Nombre Tarea: Registro de datos de alumnos.
ALUMNO: VARGAS HUAYAHURIMA ALDO

1
8

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Tipo de Tarea: Desarrollo

Puntos Estimados: 0.3

Fecha Inicio: 07/12/15


Fecha Fin: 08 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se disear la interfaz para insertar los datos de alumnos
donde se muestren todos los datos que se almacenan en la aplicacin.

Tabla 1.13 Tarea registro de alumnos

Tarea
Nmero Tarea: 5
Nmero Historia: 3
Nombre Tarea: Registro de datos de alumnos.
Tipo de Tarea: Desarrollo
Puntos Estimados: 0.2
Fecha Inicio: 09/12/15
Fecha Fin: 10 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar el insertar de los datos de alumnos y se
almacenar en la aplicacin.
Tabla 1.14 Tarea bsqueda de alumnos

Tarea
Nmero Tarea: 6
Nmero Historia: 4
Nombre Tarea: Bsqueda de los datos de alumnos.
Tipo de Tarea: Desarrollo
Puntos Estimados: 0.3
Fecha Inicio: 11/12/15
Fecha Fin: 12 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar la bsqueda de datos de alumnos almacenada
en la aplicacin.
Tabla 1.15 Tarea Registro de cursos

Tarea
Nmero Tarea: 7
Nmero Historia: 5
Nombre Tarea: Registro de cursos.
Tipo de Tarea: Desarrollo.
Puntos Estimados: 0.1
Fecha Inicio: 13/10/11
Fecha Fin: 14 /10/ 11
Programador Responsable: Aldo Vargas
Descripcin: Se disear la interfaz para insertar los datos de los cursos
donde se muestren todos los datos que se almacenan en la aplicacin.

Tabla 1.16 Tarea Registro de cursos

ALUMNO: VARGAS HUAYAHURIMA ALDO

1
9

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Tarea
Nmero Tarea: 8
Nmero Historia: 5
Nombre Tarea: Registro de cursos.
Tipo de Tarea: Desarrollo.
Puntos Estimados: 0.1
Fecha Inicio: 15/12/15
Fecha Fin: 16/12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar el insertar de los datos de cursos y se
almacenar en la aplicacin.
Tabla 1.17 Tarea bsqueda de cursos

Tarea
Nmero Tarea: 9
Nmero Historia: 6
Nombre Tarea: Bsqueda de los datos de cursos.
Tipo de Tarea: Desarrollo
Puntos Estimados: 0.3
Fecha Inicio: 17/12/15
Fecha Fin: 18 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar la bsqueda de datos de los cursos almacenada
en la aplicacin.
Tabla 1.18 Tarea Registro de ciclos

Tarea
Nmero Tarea: 10
Nombre Tarea: Registro de ciclos.

Nmero Historia: 7

Tipo de Tarea: Desarrollo


Puntos Estimados: 0.3
Fecha Inicio: 19/12/15
Fecha Fin: 20 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se disear la interfaz para insertar los datos de los ciclos
donde se muestren todos los datos que se almacenan en la aplicacin.
Tabla 1.19 Tarea Registro de ciclos

Tarea
Nmero Tarea: 11
Nombre Tarea: Registro de ciclos.

Nmero Historia: 7

Tipo de Tarea: Desarrollo


Puntos Estimados: 0.3
Fecha Inicio: 21/12/15
Fecha Fin: 22/12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar el insertar de los datos de cursos y se
almacenar en la aplicacin.
Tabla 1.20 Tarea bsqueda de ciclos

Tarea
Nmero Tarea: 12
Nmero Historia: 8
Nombre Tarea: Bsqueda de los datos de ciclos.
ALUMNO: VARGAS HUAYAHURIMA ALDO

2
0

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Tipo de Tarea: Desarrollo


Puntos Estimados: 0.3
Fecha Inicio: 23/12/15
Fecha Fin: 24 /12/ 15
Programador Responsable: Aldo Vargas
Descripcin: Se programar la bsqueda de datos de los ciclos almacenada
en la aplicacin.

Plan de Duracin de las Iteraciones


Como parte del ciclo de vida de un proyecto utilizando la metodologa XP se crea el
plan de duracin de las iteraciones, segn los equipos de desarrollo con que se
cuente, en este caso se hace para el nico equipo de desarrollo que se tiene. Este
plan se encarga de mostrar las historias de usuarios que sern implementadas en
cada una de las iteraciones, as como la duracin estimada de cada una y el orden
en que se implementarn.

MODELO RELACIONAL
MODELO ENTIDAD-RELACIN FINAL

Docentes
IdDocente
NumAlumnos

Ciclos
IdCiclo
Nombre

Cursos
idCursos
NumAlumnos
Alumnos
IdAlumno
nombre
nombreCurso
nombreDocente
ciclo
condicion
descripcion
foto

INTERFACES DE LA APLICACIN
Interfaz de inicio

ALUMNO: VARGAS HUAYAHURIMA ALDO

2
1

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Mantenimiento de Docentes

Bsqueda de docentes

Mantenimiento de Alumnos

ALUMNO: VARGAS HUAYAHURIMA ALDO

2
2

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

Bsqueda de Alumnos

Mantenimiento de Cursos

Bsqueda de docentes
ALUMNO: VARGAS HUAYAHURIMA ALDO

2
3

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA


Y SISTEMAS-EAP DE SISTEMAS

ALUMNO: VARGAS HUAYAHURIMA ALDO

2
4