Universidad César Vallejo L
I
M
A
N
O
R
T
E
INGENIERÍA DE SISTEMAS “ESTRUCTURA DE DATOS”
Informe sobre “PROGRAMACIÓN EXTREMA” Profesor del Área Ing. Jhonny Valverde Pardavé.
Alumno: Urbina López Diego Alejandro 204 – TARDE 2009
METODOLOGÍA DEL DESARROLLO DE SOFTWARE PROMACIÓN EXTREMA (XP)
1. INTRODUCCIÓN: Las metodologías ágiles forman parte del movimiento de desarrollo ágil de software, que se basan en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito en el desarrollo de problemas; ya sea para la empresa, o como para el diseño particular de un SW. Este nuevo método metodológico empezó a crecer desde el año 2001.
2. DEFINICIÓN ¿Qué es la XP y como surge? La programación extrema es una metodología de ingeniería de software para el desarrollo del mismo, que hace énfasis en los siguientes aspectos: satisfacción del cliente y trabajo en equipo. Se considera: • •
La programación extrema es una metodología de desarrollo ligera (o ágil). Se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo
La XP, (de Siglas: Xtreme Programming) nace como disciplina hace 6 años, teniendo como autor al estadounidense Kent Beck, y como también a uno de los mejores frameworks Erich Gamma. Kent, es un programador que ha trabajado en múltiples empresas y que actualmente lo hace como programador en la conocida empresa automovilística DaimlerChrysler. Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en como se refuerzan re fuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software. “El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común.”
3. OBJETIVOS DE LA XP Se considera 2 objetivos específicos: •
•
Los objetivos de XP son muy simples: la satisfacción del cliente. Esta metodología trata de dar al cliente el software que él necesita y cuando lo necesita. Por tanto, debemos responder muy rápido a las necesidades del cliente, incluso cuando los cambios sean al final de ciclo de la programación. El segundo objetivo es potenciar al máximo el trabajo en grupo. Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software. “XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito”
4. FUNCIONAMIENTO Y PRINCIPIOS La Programación Extrema se basa en 12 principios básicos agrupados en cuatro categorías los cuales determina el funcionamiento especial que se debe emplear al momento de programar.
• Retroalimentación a escala fina 1. El principio de pruebas : se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra) negra) donde se definirán las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). Un buen ejemplo de un ambiente de prueba es el JUnit para Java (Otros ambientes de pruebas para otros lenguajes como C, C++, JavaScript, XML y servicios Web) 2. Proceso de planificación: en esta fase, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación, Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones periódicas durante esta fase de planificación. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos a los que se les ha de dar más importancia por su dificultad o por su punto crítico.
3. El cliente en el sitio : se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento. Este representante del cliente estará con el equipo de trabajo durante toda la realización del proyecto.
4. Programación en parejas: uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. De acuerdo con los experimentos, este principio puede producir aplicaciones más buenas, de manera consistente, a iguales o menores costes. Aunque el pair-programming puede no ser para todo el e l mundo, la evidencia anecdótica de muestra todo un éxito.
• Proceso continuo en lugar de por lotes 1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día. Esto reduce los problemas de integración comunes en proye ctos largos y estilo cascada
2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimización del código duplicado y/o ineficiente.
3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo.
• Entendimiento compartido 1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla.
2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de como funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified ( Unified Modeling Language). Language ). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en la programación orientada a objetos y define sus responsabilidades (lo que h a de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas).
3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán.
4. Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona.
• Bienestar del programador 1. La semana de 40 horas : la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad. Como dice Beck , está bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas.
5. UTILIDAD ¿Cuándo se debe usar la XP?
La programación extrema fue creada pensando en las siguientes circunstancias: circunstancias: •
•
•
Proyectos en los que los requisitos tienen altas probabilidades de cambiar con el tiempo (por ejemplo, porque el cliente no tiene claro lo que quiere, o porque el cambio de requisitos está ligado al dominio del problema a resolver). Proyectos con alto riesgo (por ejemplo, proyectos con una fecha de entrega que es indispensable cumplir, o proyectos totalmente novedosos para la industria). Proyectos con un grupo pequeño de programadores (entre 2 y 12), aunque el equipo completo sea bastante más extenso (incluye a jefes de equipo y representantes de clientes).
6. METODOLOGÍA DE LA XP Para llevar a cabo una exitosa programación extrema, se debe tomar en cuenta la metodología empleada considerando 2 enfoques: Valores y Actividades Básicas Una de las cosas que a los programadores nos tiene que quedar muy claro es que en el ciclo de vida del desarrollo de un proyecto software los cambios van a aparecer, cambiarán los requisitos, las reglas de negocio, el personal, la tecnología, todo va a cambiar. Por tanto el problema no es el cambio en si, ya que este va a suceder sino la incapacidad de enfrentarnos a estos cambios. Como en otra cualquier actividad humana necesitamos valores para desarrollar nuestro trabajo y conseguir los planteamientos iniciales. Estos cuatro valores son: ·Comunicación ·Sencillez ·Retroalimentación ·Valentía
•
Comunicación
Cuantas veces hemos tenido problema en nuestro equipo de desarrollo por falta de comunicación, por no comentar un cambio crítico en el diseño, por no preguntar lo que pensamos al cliente. La mala comunicación no surge por casualidad y hay circunstancias que conducen a la ruptura de la comunicación, como aquel jefe de proyecto que abronca al programador cuando éste lo comunica que hay un fallo en el diseño. XP ayuda mediante sus prácticas a fomentar la comunicación.
•
Sencillez
Siempre debemos hacernos esta pregunta ¿Qué es lo más simple que pueda funcionar? Lograr la sencillez no es fácil. Tenemos cierta tendencia a pensar en qué programaremos mañana, la próxima semana y el próximo mes. Cuantos de nosotros no hacemos a veces mas de lo que debemos: “Ya “ Ya que estoy tocando esta clase voy a añadirle dos métodos mas para visualizar los mensajes en colores ”, cuando eso no está entre los requisitos, “es “es que mañana puede que lo necesite ”, si mañana esta entre los requisitos, hazlo entonces. XP nos enseña a apostar, apuesta por hacer una cosa sencilla hoy y pagar un poco mas para mañana, si es necesario, que hacer una cosa complicada hoy y no utilizarla después. La sencillez y la comunicación se complementan, cuanto mas simple es tu sistema menos tienes que comunicar de el.
•
Retroalimentación
“No me preguntes a mi, pregúntale al sistema”, es la primera clave de la retroalimentación, por medio de pruebas funcionales a nuestro software este nos mantendrá informado del grado de fiabilidad de nuestro sistema, esta información realmente no tiene precio. Los clientes y las personas que escriben pruebas tienen una retroalimentación real de su sistema. La retroalimentación actúa junto con la sencillez y la comunicación, cuanto mayor retroalimentación más fácil es la comunicación. Cuanto mas simple un sistema mas fácil de probar. Escribir pruebas nos orienta como simplificar un sistema, hasta que las pruebas funcionen, cuando las pruebas funcionen tendrá mucho echo.
•
Valentía
Asumir retos, ser valientes antes los problemas y afrontarlos. Si nuestro código es engorroso, no terminemos odiándolo y odiando al sistema, esto trae como consecuencia, una entropía positiva. Al contrario, debemos pensar, “¿Cuántos problemas podré solucionar en base a este código?”. Nuestro enfoque debe ser constante y perseverante.
“Ahora que tenemos nuestros cuatro valores estamos preparados para construir una disciplina de desarrollo de software. ¿Qué tareas debemos de llevar a cabo para desarrollar un buen software?”
Aquí se muestran las 4 actividades básicas que forman parte del proceso metodológico de un buen programador extremo.
•
Codificar
Es la única actividad de la que no podremos prescindir. Sin código fuente no hay programa, aunque hay gente que cuenta que existe software en producción del que se perdió el código fuente. Por tanto necesitamos codificar y plasmar nuestras ideas a través del código. En una programación en XP en pareja el código expresa tu interpretación del problema, así podemos utilizar el código para comunicar, para hacer mías tus ideas, y por tanto para aprender y mejorar.
•
Hacer pruebas
Las características del software que no pueden ser demostradas mediante pruebas simplemente no existen. Las pruebas me dan la oportunidad de saber si lo que implementé es lo que en realidad yo pensaba que había implementado. Las pruebas nos indican que nuestro trabajo funciona, cuando no podemos pensar en ninguna prueba que pudiese originar un fallo en nuestro sistema entonces has acabado por completo. No debemos de escribir tan solo una prueba ver que funciona y salir corriendo, debemos de pensar en todas las posibles pruebas para nuestro código, con el tiempo llegaras a conclusiones sobre las pruebas y podrás pensar que si dos de tus pruebas ya funcionan la tercera prueba no será necesaria escribirla, sin caer en demasiada confianza. Programar y probar es mas rápido que sólo programar. Puedes ganar media hora de productividad sin hacer pruebas, pero perderás mucho tiempo en la depuración. Tendrás menos errores, tendrás que volver menos veces sobre el código, te costará menos localizar los errores, perderás menos tiempo escuchado como tus clientes te dicen que no funciona. Las pruebas deben de ser sensatas y valientes. No podemos hacer pruebecillas que no testen a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro.
•
Escuchar
Los programadores no lo conocemos todo, y sobre todo muchas cosas que las personas de negocios piensan que son interesantes. Si ellos pudieran programarse su propio software ¿para que nos querrían? Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quien necesita la información. Tenemos que escuchar a nuestros clientes cuales son los problemas de su negocio, debemos de tener una escucha activa explicando lo que es fácil y difícil de obtener, y la realimentación entre ambos nos ayudan a todos a entender los problemas.
•
Diseñar
El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite que el sistema crezca con cambios en un solo lugar. Los diseños deben de ser sencillos, si alguna parte del sistema es de desarrollo complejo, divídela en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes. Tenemos que codificar porque sin código no hay programas, tenemos que hacer pruebas por que sin pruebas no sabemos si hemos acabado de codificar, tenemos que escuchar, porque si no escuchamos no sabemos que codificar ni probar, y tenemos que diseñar para poder codificar, probar y escuchar indefinidamente.
7. SOPORTE Navegando en la web, se localizó una home web page acerca de la XP y sus principales movimientos mundiales.
http://www.xprogramming.com/ http://www.extremeprogramming.org/ http://www.programacionextrema.org/
A sí mismo, se ubicó el soporte de programación extrema para el uso y manejo del Java. (Por clases: JUnit).
http://www.junit.org/
8. CASOS DE ÉXITO Las empresas más destacadas por el uso de la XP en sus programadores son por ejemplo: • • • • • •
Empresa Chrysler, Empresa IBM Empresa Symantec Empresa Española BelNature Microsoft Apple
9. CONCLUSIONES
“Diversos estudios han demostrado los beneficios de introducir las metodologías ágiles ágiles en las aulas, no sólo por la conveniencia de enseñar métodos que han sido exitosos en la industria, sino porque aportan valores didácticos que incrementan las habilidades del estudiante en su desempeño académico y profesional. Esto no implica desechar las teorías convencionales. convencionales. Por el contrario, se complementan y es preciso saber en qué casos usar una u otra.”
10.ESQUEMAS 10.ESQUEMAS CONCEPTUALES “ESQUEMA COCEPTUAL, DONDE SE OBSERVA LA METODOLOGÍA DE LA XP”
“DIFERENCIAS DE ENFOQUES”
11.BIBLIOGRAFÍA 11.BIBLIOGRAFÍA •
ADDISON Wesley. Wesley. “Requirements Architecture Extreme Programming Design Patterns” E.E.U.U 2002
•
ADDISON Wesley. “Teach “Teach Yourself Extreme Programming In 24 Hours “E.E.U.U 2002
•
ADDISON Wesley, BECK Kent, FOWLER Martin. “Planning Extreme Programming” E.E.U.U 2002
•
Manuel. “Una explicación de la programación extrema (XP)” CALERO SOLIS Manuel. MADRID 2003
•
ARTÍCULO/www.ilkebenson.com/articulos/xp.pdf
WEBGRAFÍA: http://www.taringa.net/posts/info/824446/Programacion-Extrema-%5BEditado%5D.html http://es.wikipedia.org/wiki/Programaci%C3%B3n_extrema http://www.cristalab.com/blog/introduccion-a-la-programacion-extrema-c44013l/ http://www.chuidiang.com/ood/metodologia/extrema.php
