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

Universidad César Vallejo

L I M A N O R T E

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 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) 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, 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 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 proyectos 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 Modeling 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 ha 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:

• 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 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 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 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. Por el contrario, se complementan y es preciso saber en

qué casos usar una u otra.” 10. ESQUEMAS CONCEPTUALES

“ESQUEMA COCEPTUAL, DONDE SE OBSERVA LA METODOLOGÍA DE LA XP”

“DIFERENCIAS DE ENFOQUES”

11. BIBLIOGRAFÍA

• ADDISON Wesley. “Requirements Architecture Extreme Programming Design Patterns”

E.E.U.U 2002

• ADDISON Wesley. “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

• CALERO SOLIS Manuel. “Una explicación de la programación extrema (XP)”

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