Este documento describe la metodología de desarrollo de software conocida como Programación Extrema (XP). XP se centra en la comunicación, la simplicidad y la retroalimentación. El documento explica los orígenes de XP, sus valores, prácticas y roles. También cubre las fases de planificación, diseño, desarrollo, pruebas y las ventajas e inconvenientes de esta metodología ágil.
En muchos casos esta metodología se considera como un método independiente, este método pertenece a los modelos de desarrollo evolutivo.
Prototipo es una representación o modelo del sistema a desarrollar que, a diferencia de un modelo de simulación, incorpora componentes del producto real, este será una representación del sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas.
Un prototipo tiene un funcionamiento limitado en cuanta a capacidades, confiabilidad o eficiencia.
En la utilización de este método se inicia con la definición de los objetivos globales para el software para luego pasar a identificar los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado
Una serie de pasos predecibles que ayude a crear un resultado de alta calidad y a tiempo.
Es un conjunto estructurado de actividades para: Especificar, diseñar, implementar y probar software.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Este trabajo fue presentado como parte del curso Ingeniería y calidad del Software ofrecido como parte de la Especialización en Informática y Ciencias de la Computación en la Fundación Universitaria Konrad Lorenz
En muchos casos esta metodología se considera como un método independiente, este método pertenece a los modelos de desarrollo evolutivo.
Prototipo es una representación o modelo del sistema a desarrollar que, a diferencia de un modelo de simulación, incorpora componentes del producto real, este será una representación del sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas.
Un prototipo tiene un funcionamiento limitado en cuanta a capacidades, confiabilidad o eficiencia.
En la utilización de este método se inicia con la definición de los objetivos globales para el software para luego pasar a identificar los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado
Una serie de pasos predecibles que ayude a crear un resultado de alta calidad y a tiempo.
Es un conjunto estructurado de actividades para: Especificar, diseñar, implementar y probar software.
Las Pruebas de Software son todavía una de las áreas más desatendidas del desarrollo y espliegue de los productos de software. Las Pruebas de Software son predominantemente vistas como una actividad periférica, casi una formalidad, antes del espliegue del software. Un cambio de actitud y un buen programa de estudios como fundamento hacia las Pruebas de Software pueden reducir tremendamente los problemas normalmente asociados con el lanzamiento del nuevo software y minimizar el riesgo implicado. El programa de estudio del ISTQB (International Software Testing Qualifications Board) Probador Certificado (Certified Tester) ofrece el mejor
entrenamiento estandarizado del mundo para los probadores de software.
Este libro le proporcionará el conocimiento esencial para ser un profesional en Pruebas, que incluye:
Fundamentos de Pruebas
Pruebas a través del Ciclo de Vida de Software
Técnicas Estáticas
Técnicas de Diseño de Pruebas
Gestión de Pruebas
Soporte de las Herramientas de Pruebas
Adquisición de Herramientas y Software en General en una Organización
Más de 200 preguntas de examen de muestra con soluciones
Ejercicios prácticos y soluciones por cada tema cubierto
Caso real, resuelto, como ejemplo a lo largo de los temas
Dos exámenes de simulación del examen real
Estándares de Pruebas
Excelente Bibliografía
Cabe señalar que este libro no es sólo para los probadores sino también para quienes están encargados de la adquisición de software en general, gerentes de tecnología, gerentes del Aseguramiento de la Calidad/Control de la Calidad (QA/QC), gerentes de sistemas, jefes de proyectos de software, analistas, arquitectos, desarrolladores, estudiantes y profesores de TI.
Asimismo este libro está diseñado para el autoestudio. El contenido comprende el programa de estudios necesario para aprobar el examen de certificación nivel básico definido por el ISTQB versión 2011 (Syllabus 2011).
Este trabajo fue presentado como parte del curso Ingeniería y calidad del Software ofrecido como parte de la Especialización en Informática y Ciencias de la Computación en la Fundación Universitaria Konrad Lorenz
1. METODOLOGIAS
AGILES
METODOLOGIA XP
CARLOS CORTES
VANESSA MOLINA
LISETH PATERNINA
OSCAR VARGAS
2. ¿METODOLOGIAS AGILES?
Surge ante la necesidad
de ofrecer una
alternativa a la
metodologías
tradicionales,
caracterizados por ser
rígidos y dirigidos por
la documentación que se
genera en cada una de
las actividades
desarrolladas.
6. ¿Programación Extrema o XP?
La Programación Extrema es una
metodología ligera de desarrollo de
software que se basa en la
simplicidad, la comunicación y la
realimentación o reutilización del
código desarrollado.
Centrada en potenciar las
relaciones interpersonales como
clave para el éxito en el desarrollo
de software.
Su objetivo es aumentar la
productividad al desarrollar
software.
7. ORIGEN DE LA METODOLOGIA
XP
Nace de la mano de Kent Beck en
el verano de 1996, cuando
trabajaba para Chrysler
Corporation.
El tenía varias ideas de
metodologías para la realización
de programas que eran cruciales
para el buen desarrollo de
cualquier sistema.
Las ideas primordiales de su
sistema las comunicó en la revista
C++ Magazine en una entrevista
que ésta le hizo el año 1999.
8. OBJETIVOS DE XP
La satisfacción del cliente.
Potenciar el trabajo en grupo.
Minimizar el riesgo actuando sobre
las variables del proyecto:
- Coste
- Tiempo
- Calidad
- Alcance
9. VALORES QUE INSPIRAN XP
Comunicación
Sencillez
Retroalimentación
Valentía
15. Prácticas de Codificación
• Simplicidad de código y de diseño para producir software
fácil de modificar.
• Reingeniería continua para lograr que el código tenga un
diseño óptimo.
• Desarrollar estándares de codificación, para comunicar ideas
con claridad a través del código.
• Desarrollar un vocabulario común, para comunicar las ideas
sobre el código con claridad.
16. Prácticas de Desarrollo
• Adoptar un método de desarrollo basado en las pruebas
para asegurar que el código se comporta según lo esperado.
• Programación por parejas, para incrementar el
conocimiento, la experiencia y las ideas.
• Asumir la propiedad colectiva del código, para que todo el
equipo sea responsable de él.
• Integración continua, para reducir el impacto de la
incorporación de nuevas funcionalidades.
17. Prácticas de Negocios
• Integración de un representante del cliente en el equipo,
para encauzar las cuestiones de negocio del sistema de
forma directa, sin retrasos o pérdidas por intermediación.
• Adoptar el juego de la planificación para centrar en la
agenda el trabajo más importante.
• Entregas regulares y frecuentes para satisfacer la inversión
del cliente.
• Ritmo de trabajo sostenible, para terminar la jornada
cansado pero no agotado.
20. Fases de la Metodología XP (planificación)
A) HISTORIAS DEL USUARIO
• Las historias de usuario tienen el mismo propósito que los casos de uso.
• Las escriben los propios clientes, tal y como en ellos las necesidades del
sistema.
• Las historias de usuario son similares al empleo de escenarios, con la
excepción de que no se limitan a la descripción de la interfaz de usuario.
También conducirán el proceso de creación de los test de
aceptación(empleados para verificar que las historias de usuario han sido
implementadas correctamente).
• Existen diferencias entre estas y la tradicional especificación de requisitos.
La principal diferencia es el nivel de detalle. Las historias de usuario
solamente proporcionaran los detalles sobre la estimación del riesgo y
cuánto tiempo conllevará la implementación de dicha historia de usuario.
21. Fases de la Metodología XP (planificación)
A) HISTORIAS DEL USUARIO
22. Fases de la Metodología XP (planificación)
A) HISTORIAS DEL USUARIO
23. Fases de la Metodología XP (planificación)
A) HISTORIAS DEL USUARIO
24. Fases de la Metodología XP (planificación)
A) HISTORIAS DEL USUARIO
25. Fases de la Metodología XP (planificación)
B) RELEASE PLANNING
es una planificación donde los desarrolladores y clientes establecen los tiempos de
implementación ideales de las historias de usuario, la prioridad con la que serán
implementadas y las historias que serán implementadas en cada versión del
programa.
26. Fases de la Metodología XP (planificación)
C) PLAN DE ITERACION
Así puede verse un plan de iteración: Iteración y planes de iteración_
27. Fases de la Metodología XP
(planificación)
• La rotaciones evitarán que las personas se conviertan en si mismas en un cuello de
botella. Las rotaciones permitirán que todo el mundo conozca cómo funciona el
sistema.
• Reuniones de seguimiento diarias
• Deberemos corregir el proceso cuando éste falle.
• Todo el mundo debe estar al corriente de los cambios.
• Para que esto funcione correctamente hay que crear unidades de prueba de cada
módulo que se desarrolle.
29. Fases de la Metodología XP (Diseño)
X.P sugiere que hay que conseguir diseños simples y sencillos
Usar glosarios de
términos y un correcta especificación de los nombres de métodos y clases ayudará a
comprender el diseño y facilitará sus posteriores ampliaciones y la reutilización del
código.
Si surgen problemas potenciales durante el diseño, X.P sugiere utilizar
una pareja de desarrolladores para que investiguen y reduzcan al máximo el riesgo que
supone ese problema. SPIKE(programa simple que explora una posible solución a un
problema)
Nunca se debe añadir funcionalidad extra al
programa aunque se piense que en un futuro será utilizada. Sólo el 10% de la misma es
utilizada, lo que implica que el desarrollo de funcionalidad extra es un desperdicio de
tiempo y recursos.
30. Fases de la Metodología XP (Diseño)
• Refactorizar es mejorar y modificar la estructura y codificación de códigos ya
creados sin alterar su funcionalidad. Refactorizar supone revisar de nuevo
estos códigos para procurar optimizar su funcionamiento.
• representan objetos; la clase a la que pertenece el objeto se puede escribir en la
parte de arriba de la tarjeta, en una columna a la izquierda se pueden escribir las
responsabilidades u objetivos que debe cumplir el objeto y a la derecha, las clases
que colaboran con cada responsabilidad.
31. Fases de la Metodología XP (Diseño)
TARJETAS CRC
33. Fases de la Metodología XP
(DESARROLLO)
• Disponibilidad del CLIENTE
• Unidades de prueba o test
• Programación pareja
• Integración del código
• Frecuencia en la integración del código
• El código es propiedad de todos:
• Dejar la optimizaciones para el final
• No a las horas extras: 40 horas semanales
35. Fases de la Metodología XP
(PRUEBAS)
Unidades de test o pruebas: Pilar básico
Implantación: El código será implantado cuando supere sus correspondientes
unidades de test.
Protección contra fallos: Solución, un test
Pruebas de aceptación: Evaluación del cliente
37. 1. PROGRAMADOR
Pieza básica en desarrollos XP
Más responsabilidad que en otros modos de desarrollo
Responsable sobre el código
Responsable sobre el diseño (refactorización, simplicidad)
Responsable sobre la integridad del sistema (pruebas)
Capacidad de comunicación
Acepta críticas (código colectivo)
38. 2. CLIENTE
Pieza básica en desarrollos XP
Define especificaciones
Influye sin controlar
Confía en el grupo de desarrollo
Define pruebas funcionales
39. 3. Encargado de pruebas (Tester)
Apoya al cliente en la preparación/realización de las pruebas
funcionales
Ejecuta las pruebas funcionales y publica los resultados
40. 4. Encargado de seguimiento
(Tracker)
Recoge, analiza y publica información sobre la marcha del proyecto sin
afectar demasiado el proceso
Supervisa el cumplimiento de la estimaciones en cada iteración
Informa sobre la marcha de la iteración en curso
Controla la marcha de las pruebas funcionales, de los errores reportados,
de las responsabilidades aceptadas y de las prueba añadidas por los
errores encontrados
41. 5. Entrenador (Coach)
Experto en XP
Responsable del proceso en su conjunto
Identifica las desviaciones y reclama atención sobre las
mismas
Guía al grupo de forma indirecta (sin dañar su seguridad ni
confianza)
Interviene directamente si es necesario
Atajar rápidamente el problema
42. 6. Gestor (Big boss)
Favorece la relación entre usuarios y desarrolladores
Confía en el equipo XP
Cubre las necesidades del equipo XP
Asegura que alcanza sus objetivos
43. VENTAJAS Y DESVENTAJAS DE XP
Programación organizada.
Menor taza de errores.
Satisfacción del programador.
Es recomendable emplearlo solo en proyectos a
corto plazo.
Altas comisiones en caso de fallar.
44. REFERENCIAS BIBLIOGRAFICAS
Archivo .pdf de la Universidad Politécnica de Valencia con una amplia explicación sobre
metodologías ágiles y la programación extrema (XP). Recuperado el 20 de Febrero de 2013.
http://www.willydev.net/descargas/prev/TodoAgil.pdf
CALERO SOLÍS, Manuel. Una explicación de la programación extrema (XP). V Encuentro usuarios
xBase 2003 MADRID. Recuperado el 20 de Febrero de 2013.
http://www.willydev.net/descargas/prev/ExplicaXP.pdf
ACOSTA QUIROZ, César Augusto. Recuperado el 20 de Febrero de 2013.
http://www.slideshare.net/cesar_acosta/programacin-extrema-extream-programming-xp
Isaías Carrillo Pérez, Rodrigo Pérez González, Aureliano David Rodríguez Martín. Recuperado el 20
de Febrero de 2013.
http://es.scribd.com/doc/54060274/Metodologias-de-desarrollo