Programación Extrema

[PROGAMACIN EXTREMA] 14 de septiembre de 2011

INTRODUCCIN

En la actualidad, la necesidad de la creacin de mecanismos para la automatizacin de procesos dentro de las reas productivas , ha llevado al desarrollo de metodologas que ayuden a lderes de proyecto y programadores, a adoptar reglas o estndares aplicables para minimizar costos, tiempos y errores dentro del proceso, y as eficientar al mximo los recursos disponibles ,uno de estos estndares o metodologas es lo que llamamos la Programacin 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 Ingeniera de Software una herramienta poderosa para cumplir los objetivos que el cliente requiere.

Instituto Tecnolgico Superior de Poza Rica |Maestra en ciencias de la computacin

1


DEFINICINEs una metodologa de desarrollo ligera basada en una serie de valores y una docena de prcticas que propician un aumento en la productividad a la hora de generar software. La programacin extrema o XP se sita en una posicin 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 despus) sino de requisitos que estn 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 aproximacin mejor y ms realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos. Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software. Los puntos esenciales de esta metodologa son: Metodologa para un gil desarrollo de software. Programacin 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 Programacin Extrema t

Requerimientos Anlisis

Diseo

Implementacin

Prueba

Produccin

Enfoque tradicional vs Programacin extrema

Instituto Tecnolgico Superior de Poza Rica | Maestra en ciencias de la computacin

2


ORIGENLas races de la XP yacen en la comunidad de Smalltalk, y en particular la colaboracin cercana de Kent Beck y Ward Cunningham a finales de los 1980s. Ambos refinaron sus prcticas 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 prctica informal a una metodologa ocurri en la primavera de 1996. A Kent se le pidi revisar el progreso del proyecto de nmina C3 para Chrysler. El proyecto estaba siendo llevado en Smalltalk por una compaa contratista, y estaba en problemas. Debido a la baja calidad de la base del cdigo, Kent recomend tirar la base del cdigo en su totalidad y empezar desde el principio. El proyecto entonces reinici bajo su direccin 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 despus se encontr con dificultades, lo que result en la cancelacin del desarrollo en 1999. (Lo cual prueba, si ninguna otra cosa, que la XP no es garanta de xito.) Las ideas primordiales de su sistema las comunic en la revista C++ Magazine en una entrevista que sta le hizo el ao 1999. En sta deca que l estaba convencido que la mejor metodologa era un proceso: Que enfatizase la comunicacin del equipo. Que la implementacin fuera sencilla. Que el usuario tena que estar muy informado e implicado. Que la toma de decisiones tena que ser muy rpida y efectiva.

Los autores de la Programacin Extrema, crearon el sitio web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cmo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasin que tenan y en cada pgina que, poco o mucho hablara de temas de programacin.

Portland Pattern Repository.

Kent Beck, fundador.


3


VALORESEn la nueva versin, la programacin extrema se basa en cinco valores, los elementos bsicos que Beck considera realmente importantes para desarrollar software exitosamente. Estos valores son la gua para el desarrollo en s mismo y la inspiracin de toda la metodologa. Cuatro de ellos son los mismos que en XP original, y se agrega el respeto como el quinto valor.

ComunicacinLa comunicacin se realiza de diferentes formas. Para los programadores el cdigo comunica mejor cuanto ms simple sea. Si el cdigo es complejo hay que esforzarse para hacerlo inteligible. Las pruebas unitarias son otra forma de comunicacin ya que describen el diseo de las clases y los mtodos al mostrar ejemplos concretos de cmo utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programacin por parejas. La comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide que caractersticas tienen prioridad y siempre debe estar disponible para solucionar dudas.

SimplicidadLa simplicidad es la base de la programacin extrema.

Se simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Undiseo complejo del cdigo junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorizacin del cdigo, sta es la manera de mantener el cdigo simple a medida que crece. Tambin se aplica la simplicidad en la documentacin, de esta manera el cdigo debe comentarse en su justa medida, intentando eso s que el cdigo est autodocumentado. Para ello se deben elegir adecuadamente los nombres de las variables, mtodos y clases. Aplicando la simplicidad junto con la autora colectiva del cdigo y la programacin por parejas se asegura que cuanto ms grande se haga el proyecto, todo el equipo conocer ms y mejor el sistema completo.


4


Retroalimentacin Al estar el cliente integrado en el proyecto, su opinin sobre el estado del proyectose 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 ms importante. Considrense los problemas que derivan de tener ciclos muy largos. Las pruebas unitarias informan sobre el estado de salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el cdigo.

Valenta Muchas de las prcticas implican valenta. Una de ellas es siempre disear y programar para hoy y no para maana. Esto evita empantanarse en el diseo y requerir demasiado tiempo y trabajo. La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema existente y modificarlo. Otro ejemplo de valenta es saber cundo desechar un cdigo: valenta para remover cdigo fuente obsoleto, sin importar cunto esfuerzo y tiempo se invirti en crear ese cdigo. Valenta significa persistencia: un programador puede permanecer sin avanzar en un problema complejo por un da entero, y luego lo resolver rpidamente al da siguiente, solo si es persistente.

Respeto Los miembros respetan su trabajo porque siempre estn luchando por la altacalidad en el producto y buscando el diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin del cdigo.

Los miembros del equipo respetan el trabajo del resto no haciendo menos a otros,sino orientndolos a realizarlo mejor, obteniendo como resultado una mejor autoestima en el equipo y elevando el ritmo de produccin en el equipo.


5


FASES DE LA METODOLOGADiseo simple Historias del usuario valores Criterios de las pruebas de iteracin Plan de iteracin Cartas CRC Soluciones pico prototipos

DISE ION

O

C IFICA LAN P

recodificacin

C IFICA COD

ION

Programacin en pareja

PR

A U EBPrueba de unidad

Lanzamiento Incremento de software Velocidad calculada del proyecto

Integracin continua

Pruebas de aceptacin

PlanificacinHistorias de usuario: Constan de 3 4 lneas escritas por el cliente en un lenguaje no tcnico sin hacer mucho hincapi en los detalles. Cuando llega la hora de implementar una historia de usuario, el cliente y los desarrolladores se renen para concretar y detallar lo que tiene que hacer dicha historia. Plan de entregas: Despus de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, en ingls "Release plan", donde se indiquen las historias de usuario que se crearn para cada versin del programa y las fechas en las que se publicarn estas versiones. Iteraciones: Todo proyecto se ha de dividir en iteraciones. Al comienzo de cada iteracin los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que sern implementadas.


6


DiseoDiseos simples: Sugiere que hay que conseguir diseos simples y sencillos. Hay que procurar hacerlo todo lo menos complicado posible para conseguir un diseo fcilmente entendible e implemntable que a la larga costar menos tiempo y esfuerzo desarrollar. Funcionalidad extra: Nunca se debe aadir funcionalidad extra al programa aunque se piense que en un futuro ser utilizada. Slo 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 olvidndose de los malos hbitos de la programacin procedural clsica.

DesarrolloReciclaje: Es mejorar y modificar la estructura y codificacin de cdigos ya creados sin alterar su funcionalidad. Supone revisar de nuevo estos cdigos para procurar optimizar su funcionamiento. Programacin 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 mtodo o funcin es adecuado y est bien diseado. Integracin: Los cambios se integran en el cdigo base varias veces por da. Todos los casos de prueba se deben pasar antes y despus de la integracin, se dispone de una mquina para la integracin y se realizan test funcionales en donde participa el cliente.

PruebaUnidad de pruebas: Crear test que prueben el funcionamiento de los distintos cdigos implementados nos ayudar a desarrollar dicho cdigo. Crear estos test antes nos ayuda a saber qu es exactamente lo que tiene que hacer el cdigo a implementar y sabremos que si pasa dichos test sin problemas, ya que dicho cdigo ha sido diseado para ese fin. Pruebas de aceptacin: 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 aceptacin"; estos test son creados y usados por los clientes para comprobar que las distintas historias de usuario cumplen su cometido.


7


ROLES

Cliente Programador Encargado de pruebas (Tester) Encargado de seguimiento (Tracker) Entrenador (Coach) GestorCliente 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 grficas de los resultados y se asegura de que la gente conoce cundo los resultados empiezan a decaer.

Encargado de seguimiento (Tracker)Instituto Tecnolgico Superior de Poza Rica | Maestra en ciencias de la computacin 8


Monitoriza el progreso de los programadores, toma accin 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 seales 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 reunin para futuros informes y los pasa al Perseguidor. Posiblemente responsable ante el Propietario de Oro Asiste a las reuniones, aporta informacin til anterior.

FLUJO DE UN PROYECTOInstituto Tecnolgico Superior de Poza Rica |Maestra en ciencias de la computacin 9


OBJETIVOS El objetivo principal de la XP es la satisfaccin del cliente. Se le trata de dar al cliente lo que quiere y cuando quiere. Por tanto, se debe responder rpidamente a las necesidades del cliente, aunque realice cambios en fases avanzadas del proyecto. Como metodologa 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 DESVENTAJASInstituto Tecnolgico Superior de Poza Rica | Maestra en ciencias de la computacin 10

[PROGAMACIN 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 diseo. Obviamente, ningn mtodo es perfecto. El problema que ms se menciona con los proyectos de XP es que es difcil predecir costo y tiempo de desarrollo. Programacin organizada. Por otra parte, el desarrollo de software con XP es ms flexible, y como el sistema comienza a crecer orgnicamente, es ms 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 mtodo XP es que, si se utilizan diagramas UML, stos tienden a estar poco actualizados, debido a la constante refactorizacin. Es recomendable emplearlo solo en proyectos a corto plazo.

CONCLUSIONES


11


Como hemos visto la programacin extrema tiende a ser una forma flexible, agradable y muy dinmica 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 cdigo 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 metodologa 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 metodologa va a depender mucho del tipo de proyecto que se desee realizar, recayendo esta decisin en los lideres de proyecto para el mejor cumplimiento de los objetivos y necesidades que se requieran. La frase Divide y vencers es muy aplicable en esta metodologa, ya que a diferencia de las tradicionales en donde se analiza todo el problema para darle una solucin, la programacin extrema divide en tareas ms pequeas aplicando los mismos pasos de anlisis, agregando elementos importantes tales como la comunicacin con el cliente y las pruebas.

BIBLIOGRAFIAInstituto Tecnolgico Superior de Poza Rica | Maestra en ciencias de la computacin 12


1.- Renzo Warton PX Programacin extrema Maestra en ingeniera de sistemas con mencin en tecnologa de la informacin, Lima, Per 13 de Julio del 2007 Consulta: septiembre 12, 2011 2.-Daniel Sanchez Torrico Extreme Programming Universidad mayor de San Simn,Cochabamba ,Bolivia 10 de noviembre del 2008 Consulta: septiembre 13, 2011 3.-Aline Guerrero Programacin gil SCRUM y XP Universidad mayor, facultad de ingeniera, Santiago, Chile 16 de diciembre del 2005 Consulta: septiembre 12, 2011 4.-Alberto Borrel Garca Programacin extrema XP Instituto Tecnolgico superior de monterrey, Estado de Mexico 10 de noviembre del 2006 Consulta: septiembre 12, 2011 5.-David Martinez Programacin extrema-Introduccin Consulta: septiembre 14, 2011 6.- Castillo Oswaldo, Figueroa Daniel, Sevilla Hector Programacin extrema > Consulta: septiembre 13, 2011 7.-David Valverde Introduccin a la programacin extrema > Bandajoz, Espaa 06 de Septiembre del 2007 Consulta: septiembre 13, 2011 8.- Blog de desarrollo de software JUMMP Desarrollo de software. Programacin extrema (eXtreme Programming: XPInstituto Tecnolgico Superior de Poza Rica |Maestra en ciencias de la computacin 13


> 27 de abril del 2011 Consulta: septiembre 12, 2011


14

Programación Extrema

Documents

Transcript of Programación Extrema