InforLas metodologías ágiles tienen un origen reciente en el entorno de la ingeniería de software comparada con las metodologías pesadas. Su origen está ligado a los constantes inconvenientes que se presentaban en proyectos con algunas características, en los cuales la utilización de las metodologías pesadas era motivo de fracaso.me

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.

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.

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.

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.

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.

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

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.

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.

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.
1
0

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.
1
1

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.
1
2

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.
1
3

ANEXOS
1
4

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
Nombre historia: Bsqueda de los datos personales de docentes.
Prioridad en negocio: Media
Riesgo en desarrollo: Media
Puntos estimados: 0,2
1
5

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
Nombre historia: Registro de datos de alumnos.
Puntos estimados: 0.5

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.

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
Nombre historia: Registro de datos de los cursos.

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

Historia de Usuario
Nmero: 6
Nombre historia: Bsqueda de cursos.

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
Nombre historia: Registro de ciclos.


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
Nombre historia: Bsqueda de ciclos
Puntos estimados: 1
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
1
7

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.
Fecha Fin: 04 /12/ 15
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.
Fecha Fin: 06 /12/ 15
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.
1
8


Fecha Fin: 08 /12/ 15
Descripcin: Se disear la interfaz para insertar los datos de alumnos
Tabla 1.13 Tarea registro de alumnos
Tarea
Nmero Tarea: 5
Nmero Historia: 3
Nombre Tarea: Registro de datos de alumnos.
Fecha Fin: 10 /12/ 15
Descripcin: Se programar el insertar de los datos de alumnos y se
Tabla 1.14 Tarea bsqueda de alumnos
Tarea
Nmero Tarea: 6
Nmero Historia: 4
Nombre Tarea: Bsqueda de los datos de alumnos.
Fecha Fin: 12 /12/ 15
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.
Fecha Fin: 14 /10/ 11
Descripcin: Se disear la interfaz para insertar los datos de los cursos
Tabla 1.16 Tarea Registro de cursos
1
9

Tarea
Nmero Tarea: 8
Nmero Historia: 5
Nombre Tarea: Registro de cursos.
Tipo de Tarea: Desarrollo.
Fecha Fin: 16/12/ 15
Descripcin: Se programar el insertar de los datos de cursos y se
Tabla 1.17 Tarea bsqueda de cursos
Tarea
Nmero Tarea: 9
Nmero Historia: 6
Nombre Tarea: Bsqueda de los datos de cursos.
Fecha Fin: 18 /12/ 15
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

Fecha Fin: 20 /12/ 15
Descripcin: Se disear la interfaz para insertar los datos de los ciclos
Tabla 1.19 Tarea Registro de ciclos
Tarea
Nmero Tarea: 11
Nombre Tarea: Registro de ciclos.
Nmero Historia: 7

Fecha Fin: 22/12/ 15
Descripcin: Se programar el insertar de los datos de cursos y se
Tabla 1.20 Tarea bsqueda de ciclos
Tarea
Nmero Tarea: 12
Nmero Historia: 8
Nombre Tarea: Bsqueda de los datos de ciclos.
2
0


Fecha Fin: 24 /12/ 15
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
2
1

Mantenimiento de Docentes
Bsqueda de docentes
Mantenimiento de Alumnos
2
2

Bsqueda de Alumnos
Mantenimiento de Cursos
Bsqueda de docentes
2
3

2
4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL DE

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

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

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

o Bajo nivel de detalle

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

1.3 ENTREGAS PEQUEAS

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

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

2.2 METFORA DEL SISTEMA

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

o Convencin de nombres para los objetos del sistema

2.3 TARJETAS CRC

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

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

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

3.2 CODIFICAR PRIMERO LA PRUEBA

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

El no contar con una permanente comunicacin complico seriamente el

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

4.2 Pruebas de aceptacin

Lo que dice XP.

4.3 Cuando se encuentra un error

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

Riesgo en desarrollo: Alta

Programador responsable: Aldo Vargas

Tabla 1.2 Historia de Usuario bsqueda del docente.

Riesgo en desarrollo: Media

Puntos estimados: 0,2

Programador responsable: Aldo Vargas

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

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

Programador responsable: Aldo Vargas

Programador responsable: Aldo Vargas

Tabla 1.5 Historia de Usuario registro de cursos

Riesgo en desarrollo: Alta

Puntos estimados: 0.1

Programador responsable: Aldo Vargas

ALUMNO: VARGAS HUAYAHURIMA ALDO

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

Riesgo en desarrollo: Alta

Puntos estimados: 0.4

Programador responsable: Aldo Vargas

Tabla 1.7 Historia de Usuario registro de ciclos.

Nombre historia: Registro de ciclos.

Riesgo en desarrollo: Alta

Puntos estimados: 0.2

Programador responsable: Aldo Vargas

UNIVERSIDAD NACIONAL DE HUANCAVELICA FALCULTAD DE INGENIERIA DE ELECTRONICA

Fecha Fin: 02 /12/ 15

Programador Responsable: Aldo Vargas