Title: Diapositiva 1
11
CONTENIDO
Introducción
Características
Presentado por Choque Rengel Maribel Anze
Carrasco Jakeline Ayala Rospilloso Eduardo
Sahdaljksdhkajds Sdadsadsasdasd dasdasd
sdasdasd agosto de 2006
Ventajas
Desventajas
22
Extreme Programming (XP) Es una metodología
ágil donde se busca involucrar al cliente a
manera de construir software que de verdad se
ajuste a las verdaderas necesidades del cliente.
XP no es una metodología de diseño, ni una
técnica de codificación, La Programación Extrema
define un proceso de desarrollo, un conjunto de
normas y recomendaciones encaminadas a producir
software de calidad. XP es una disciplina de
equipo .XP es una disciplina para trabajo con el
cliente. La planificación del trabajo y la
actividad diaria están dirigidas a las
necesidades actuales del cliente y controladas
por él en persona.
32
- La programación extrema da por supuesto que es
imposible prever todo antes de comenzar a
programar es imposible o si lo fuera es
demasiado costoso e innecesario, ya que muchas
veces se gasta demasiado tiempo y recursos en
cambiar la documentación de la planificación para
que se parezca al código. Para evitar esto, XP
intenta implementar una forma de trabajo donde se
adapte fácilmente a las circunstancias.Básicamen
te consiste en trabajar estrechamente con el
cliente, haciendo pequeñas iteraciones
(mini-entregas), cada cierto tiempo, donde no
existe mas documentación que el código en si
cada versión contiene las modificaciones
necesarias según el cliente vaya retroalimentando
el sistema (por eso es necesaria la
disponibilidad del cliente durante todo el
desarrollo).. - .
U.M.R.P.S.F.X.CH. FACULTAD DE
TECNOLOGÍA
SIS-325 INGENIERIA DEL
SOFTWARE II
4- Para suplir la falta de requisitos, casos de uso,
y demás herramientas XP utiliza historias de
usuarios, la historia de usuario es una frase
corta que representa alguna función que realizara
el sistema. Son pequeñas frases escritas por el
cliente en las que se describen aspectos
específicos de la funcionalidad que se desea. - Es requisito para XP definir un estándar en el
tipo de codificación, esto hace que los
programadores tengan definido ya el estilo de
programación y no que cada uno programe a su
estilo. - Desarrollo iterativo e incremental pequeñas
mejoras, unas tras otras. - Pruebas unitarias continuas, frecuentemente
repetidas y automatizadas, incluyendo pruebas de
regresión. Se aconseja escribir el código de la
prueba antes de la codificación.
5- Programación por parejas se recomienda que las
tareas de desarrollo se lleven a cabo por dos
personas en un mismo puesto. Se supone que la
mayor calidad del código escrito de esta manera
(el código es revisado y discutido mientras se
escribe) es más importante que la posible pérdida
de productividad inmediata. - Frecuente interacción del equipo de programación
con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo
de desarrollo. - El testing en cada iteración es más que
importante de eso se trata este paradigma de
programación, corregir mientras se programa. De
esta forma se van cubriendo todos los baches que
cada versión padezca.
6- Cada dos semanas se entrega una versión al
cliente, que lo verifica, realiza el feedback y
se continúa el desarrollo este ciclo continua
hasta que el sistema cumpla con las expectativas
del cliente, acto que concluirá el proyecto. - Corrección de todos los errores antes de añadir
nueva funcionalidad. Hacer entregas frecuentes. - Refactorización del código, es decir, reescribir
ciertas partes del código para aumentar su
legibilidad y mantenibilidad pero sin modificar
su comportamiento. Las pruebas han de garantizar
que en la refactorización no se ha introducido
ningún fallo.
7- Propiedad del código compartida en vez de
dividir la responsabilidad en el desarrollo de
cada módulo en grupos de trabajo distintos, este
método promueve el que todo el personal pueda
corregir y extender cualquier parte del proyecto.
Las frecuentes pruebas de regresión garantizan
que los posibles errores serán detectados. - Simplicidad en el código es la mejor manera de
que las cosas funcionen. Cuando todo funcione se
podrá añadir funcionalidad si es necesario. - No existe documentación del proyecto lo que mas
se acerca a la documentación son las historias de
usuario, pero al concluir el proyecto se
descartan. Inclusive se recomienda hacer dos
secciones, una con todas las historias de usuario
que faltan desarrollar, y otra donde se archiven
las concluidas, esto aproximara el estado de
avance del proyecto.
8- Vemos una comparativa gráfica entre el modelo en
cascada, el modelo en espiral y XP
9(No Transcript)
10(No Transcript)
11(No Transcript)