Programación Extrema

[PROGAMACIÓN EXTREMA] EXTREMA] 14 de septiembre de 2011

INTRODUCCIÓN

En la actualidad, la necesidad de la creación de mecanismos para la automatización de procesos dentro de las áreas productivas , ha llevado al desarrollo de metodologías que ayuden a líderes de de proyecto proyecto y programadores, a adoptar reglas o estándares estándares aplicables para minimizar costos, tiempos y errores dentro del proceso, y así eficientar al al máximo los recursos disponibles ,uno de estos estándares o metodologías es lo que llamamos la Programación extrema la cual abordaremos para mostrar todas las bondades, ventajas y desventajas que nos ofrece este estilo de desarrollo de software, que ha dado a la Ingeniería de Software una herramienta poderosa para cumplir los objetivos que el cliente requiere.

Instituto Tecnológico Superior de Poza Rica |Maestría en ciencias de la computación 1

[PROGAMACIÓN EXTREMA] 14 de septiembre de 2011

DEFINICIÓN Es una metodología de desarrollo ligera basada en una serie de valores y una docena de prácticas que propician un aumento en la productividad a la hora de generar software. La programación extrema o XP se sitúa en una posición diferente a los ciclos de vida tradicionales. Ya no se trata de requisitos que se cierran en etapas tempranas del desarrollo y que constituyen el contrato de lo que posteriormente se va a desarrollar (y que los usuarios no ven hasta mucho después) sino de requisitos que están vivos y que son modificables a lo largo del ciclo de vida. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software . Los puntos esenciales de esta metodología son:      

Metodología para un ágil desarrollo de software. Programación basada en los deseos del cliente. La meta real es entregar el software requerido a tiempo. Permite controlar los problemas de riesgo en los proyectos. El equipo lo conforman los jefes de proyecto, desarrolladores y el cliente. Se rige por valores y principios. $$ Enfoque Tradicional Programación Extrema t

Requerimientos Análisis

Diseño

Implementación

Prueba

Producción

Enfoque tradicional vs Programación extrema

Instituto Tecnológico Superior de Poza Rica | Maestría en ciencias de la computación 2


ORIGEN Las raíces de la XP yacen en la comunidad de Smalltalk, y en particular la colaboración cercana de Kent Beck y Ward Cunningham a finales de los 1980s. Ambos refinaron sus prácticas en numerosos proyectos a principios de los 90s, extendiendo sus ideas de un desarrollo de software adaptable y orientado a la gente. El paso crucial de la práctica informal a una metodología ocurrió en la primavera de 1996. A Kent se le pidió revisar el progreso del proyecto de nómina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compañía contratista, y estaba en problemas. Debido a la baja calidad de la base del código, Kent recomendó tirar la base del código en su totalidad y empezar desde el principio. El proyecto entonces reinició bajo su dirección y subsecuentemente se volvió el buque insignia temprano y el campo de entrenamiento de la XP. La primera fase del C3 fue muy exitosa y comenzó a principios de 1997. El proyecto continuó desde entonces y después se encontró con dificultades, lo que resultó en la cancelación del desarrollo en 1999. (Lo cual prueba, si ninguna otra cosa, que la XP no es garantía de éxito.) Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una entrevista que ésta le hizo el año 1999. En ésta decía que él estaba convencido que la mejor metodología era un proceso:    

Que enfatizase la comunicación del equipo. Que la implementación fuera sencilla. Que el usuario tenía que estar muy informado e implicado. Que la toma de decisiones tenía que ser muy rápida y efectiva.

Los autores de la Programación Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en cada página que, poco o mucho hablara de temas de programación.

Portland Pattern Repository.

Kent Beck, fundador.



VALORES En la nueva versión, la programación extrema se basa en cinco valores, los elementos básicos que Beck considera realmente importantes para desarrollar software exitosamente. Estos valores son la guía para el desarrollo en sí mismo y la inspiración de toda la metodología. Cuatro de ellos son los mismos que en XP original, y se agrega el respeto como el quinto valor.

Comunicación La comunicación se realiza de diferentes formas. 







Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que características tienen prioridad y siempre debe estar disponible para solucionar dudas.

Sim licidad La simplicidad es la base de la programación extrema. 

Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente.  Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece.  También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, métodos y clases. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo.



Retroalimentación  



Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código.

Valentía 







Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. Esto evita empantanarse en el diseño y requerir demasiado tiempo y trabajo. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo. Otro ejemplo de valentía es saber cuándo desechar un código: valentía para remover código fuente obsoleto, sin importar cuánto esfuerzo y tiempo se invirtió en crear ese código. Valentía significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un día entero, y luego lo resolverá rápidamente al día siguiente, solo si es persistente.

Res eto 

Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código.



Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros, sino orientándolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de producción en el equipo.



FASES DE LA METODOLOGÍA Diseño simple Historias del usuario

Soluciones pico

Cartas CRC

prototipos

valores Criterios de las pruebas de iteración

Plan de iteración

Ñ O D I S E C I O N A C I I F P LA N

recodificación

C I O N A C I F I C O D

Programación en pareja

E BA P R U Prueba de unidad Lanzamiento Incremento de software Velocidad calculada del proyecto

Integración continua

Pruebas de aceptación

Planificación Historias de usuario: Constan de 3 ó 4 líneas escritas por el cliente en un lenguaje no técnico sin hacer mucho hincapié en los detalles. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha historia. Plan de entregas: Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en inglés "Release plan", donde se indiquen las historias de usuario que se crearán para cada versión del programa y las fechas en las que se publicarán estas versiones. Iteraciones: Todo proyecto se ha de dividir en iteraciones. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que serán implementadas.



Diseño Diseños simples: Sugiere que hay que conseguir diseños simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseño fácilmente entendible e impleméntable que a la larga costará menos tiempo y esfuerzo desarrollar. Funcionalidad extra: 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. Tarjetas C.R.C. El uso de las tarjetas C.R.C (Class, Responsabilities and Collaboration) permiten al programador centrarse y apreciar el desarrollo orientado a objetos olvidándose de los malos hábitos de la programación procedural clásica.

Desarrollo Reciclaje: Es mejorar y modificar la estructura y codificación de códigos ya creados sin alterar su funcionalidad. Supone revisar de nuevo estos códigos para procurar optimizar su funcionamiento. Programación en pareja: incrementa la productividad y la calidad del software desarrollado. Involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica, el otro analiza si ese método o función es adecuado y está bien diseñado. Integración: Los cambios se integran en el código base varias veces por día. Todos los casos de prueba se deben pasar antes y después de la integración, se dispone de una máquina para la integración y se realizan test funcionales en donde participa el cliente.

Prueba Unidad de pruebas: Crear test que prueben el funcionamiento de los distintos códigos implementados nos ayudará a desarrollar dicho código. Crear estos test antes nos ayuda a saber qué es exactamente lo que tiene que hacer el código a implementar y sabremos que si pasa dichos test sin problemas, ya que dicho código ha sido diseñado para ese fin. Pruebas de aceptación: Sirven para evaluar las distintas tareas en las que ha sido dividida una historia de usuario. Para asegurar el funcionamiento final de una determinada historia de usuario se deben crear "Test de aceptación"; estos test son creados y usados por los clientes para comprobar que las distintas historias de usuario cumplen su cometido.



ROLES

Cliente Programador Encargado de pruebas (Tester) Encargado de seguimiento (Tracker) Entrenador (Coach) Gestor Cliente 

Escribe “Historias de Usuario” y especifica Pruebas Funcionales.



Establece prioridades, explica las Historias Puede ser o no un usuario final Tiene autoridad para decidir cuestiones relativas a las Historias.

 

Programador   

Hace estimaciones sobre las Historias Define Tareas a partir de las Historias y hace estimaciones Implementa las Historias y las Pruebas Unitarias

Encargado de Pruebas (Tester)  

Implementa y corre las Pruebas Funcionales (no Pruebas Unitarias) Presenta gráficas de los resultados y se asegura de que la gente conoce cuándo los resultados empiezan a decaer.

Encargado de seguimiento (Tracker) Instituto Tecnológico Superior de Poza Rica | Maestría en ciencias de la computación 8


 

Monitoriza el progreso de los programadores, toma acción si las cosas tienden a salirse de su senda. Las acciones incluyen reuniones con el Cliente, solicitar ayuda al Tutor u otro Programador.

Entrenador (Coach)   

Observa todo, identifica señales de peligro, se asegura que el proyecto se mantiene en curso Ayuda en todo Da avisos cuando se necesita.

Gestor 

Planifica las reuniones (por ej., plan de iteraciones, plan de lanzamientos releases), se asegura que el proceso de las reuniones se sigue, anota los resultados de la reunión para futuros informes y los pasa al Perseguidor.



Posiblemente responsable ante el “Propietario de Oro”



Asiste a las reuniones, aporta información útil anterior.

FLUJO DE UN PROYECTO Instituto Tecnológico Superior de Poza Rica |Maestría en ciencias de la computación 9


OBJETIVOS 

El objetivo principal de la XP es la satisfacción del cliente.



Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rápidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto.



Como metodología Ágil que es, se pueden producir modificaciones de los requisitos del proyecto a lo largo de su desarrollo, sin que esto produzca un buen dolor de cabeza.



Otro de los objetivos es el trabajo en grupo. Tanto los jefes del proyecto, clientes y desarrolladores forman parte del equipo y deben estar involucrados en el desarrollo.

VENTAJAS Y DESVENTAJAS Instituto Tecnológico Superior de Poza Rica | Maestría en ciencias de la computación 10

[PROGAMACIÓN EXTREMA] 14 de septiembre de 2011 

La calidad de los sistemas basados en XP tiende a ser un poco mejor, en particular si se utilizan patrones de diseño.



Obviamente, ningún método es perfecto. El problema que más se menciona con los proyectos de XP es que es difícil predecir costo y tiempo de desarrollo.



Programación organizada.



Por otra parte, el desarrollo de software con XP es más flexible, y como el sistema comienza a crecer orgánicamente, es más sencillo remover funciones para cumplir con el tiempo de desarrollo sin poner en riesgo el resto del sistema.



Menor taza de errores.



Otro problema del método XP es que, si se utilizan diagramas UML, éstos tienden a estar poco actualizados, debido a la constante refactorización.



Es recomendable emplearlo solo en proyectos a corto plazo.

CONCLUSIONES



Como hemos visto la programación extrema tiende a ser una forma flexible, agradable y muy dinámica de crear software, en el cual el cliente al formar parte del equipo de desarrollo, va estableciendo los caminos por donde el proyecto debe de ir, así minimizando las desviaciones del mismo. A su vez el hecho de ir realizando pruebas al código que se va generando nos da una mejor certidumbre de que el software cumplirá con los objetivos y necesidades que el cliente requiere. Cabe mencionar que el hecho de utilizar esta metodología no asegura que el proyecto tendrá éxito, si disminuye en gran medida la probabilidad de fracaso. Otro aspecto importante recae en el hecho de que el utilizar o no esta metodología va a depender mucho del tipo de proyecto que se desee realizar, recayendo esta decisión en los lideres de proyecto para el mejor cumplimiento de los objetivos y necesidades que se requieran. La frase “Divide y vencerás” es muy aplicable en esta metodología, ya que a diferencia de las tradicionales en donde se analiza todo el problema para darle una solución, la programación extrema divide en tareas más pequeñas aplicando los mismos pasos de análisis, agregando elementos importantes tales como la comunicación con el cliente y las pruebas.

BIBLIOGRAFIA Instituto Tecnológico Superior de Poza Rica | Maestría en ciencias de la computación 12


1.- Renzo Warton “PX Programación extrema”

Maestría en ingeniería de sistemas con mención en tecnología de la información, Lima, Perú 13 de Julio del 2007 Consulta: septiembre 12, 2011 2.-Daniel Sanchez Torrico “Extreme Programming”

Universidad mayor de San Simón,Cochabamba ,Bolivia 10 de noviembre del 2008 Consulta: septiembre 13, 2011 3.-Aline Guerrero “Programación ágil SCRUM y XP”

Universidad mayor, facultad de ingeniería, Santiago, Chile 16 de diciembre del 2005 Consulta: septiembre 12, 2011 4.-Alberto Borrel García “Programación extrema XP”

Instituto Tecnológico superior de monterrey, Estado de Mexico 10 de noviembre del 2006 Consulta: septiembre 12, 2011 5.-David Martinez “Programación extrema-Introducción” <> Consulta: septiembre 14, 2011 6.- Castillo Oswaldo, Figueroa Daniel, Sevilla Hector “Programación extrema”

<< http://programacionextrema.tripod.com/>> Consulta: septiembre 13, 2011 7.-David Valverde “Introducción a la programación extrema”

<< http://www.davidvalverde.com/blog/introduccion-a-la-programacionextrema-xp/>> Bandajoz, España 06 de Septiembre del 2007 Consulta: septiembre 13, 2011 8.- Blog de desarrollo de software JUMMP “Desarrollo de software. Programación extrema (eXtreme Programming: XP” Instituto Tecnológico Superior de Poza Rica |Maestría en ciencias de la computación 13


<< http://jummp.wordpress.com/2011/04/27/desarrollo-de-softwareprogramacion-extrema-extreme-programming-xp-ii/>> 27 de abril del 2011 Consulta: septiembre 12, 2011


Programación Extrema

Recommend Documents