5.programacion Extrema.pdf

“Año de la Consolidación del Mar de Grau”

Universidad Científica del Perú I Escuela profesional de ingeniería de sistemas de información

Trabajo Monográfico TEMA PROGRAMACIÓN EXTREMA (XP) Integrantes :

:

 Lomas Laulate Alian Aldair  Manihuari Robalino Ingrid Danitza  Medina Panduro Lucero Priscilla  Pérez Murrieta Jheyvin Romero  Salinas Fatama Jhonatan  Trigoso Vásquez José Martin  Vargas Jara Inés Karina  Ingeniería De Software

: Ing. Michael Sibina Alvan VI 08-02-2016

San Juan Bautista, Febrero del 2016

PROGRAMACIÓN EXTREMA

DEDICATORIA Dedicamos este trabajo a Dios por habernos dado la vida, y a nuestros padres, porque ellos siempre nos apoyan en todas las cosas que nosotros hagamos, dándonos ejemplos dignos de superación y entrega, están constantemente impulsándome en los momentos más difíciles de nuestra carrera. Va para ustedes, por lo que valen, porque admiramos su fortaleza y por lo que están haciendo de nosotros.

INGENIERIA DE SISTEMAS

2

PROGRAMACIÓN EXTREMA

AGRADECIMIENTO Queremos expresar nuestros más profundos agradecimientos en primer lugar a DIOS porque siempre está con nosotros, Él es quién nos acompaña, guía y protege en cada paso de nuestras vidas. A nuestras familias, quienes comprenden nuestro anhelo de realizar el presente trabajo de investigación y nos dieron el espacio necesario para lograr nuestra aspiración, a ellos les consagramos el esfuerzo y cariño de toda la vida. Así también queremos extender nuestros agradecimientos al Ing. Michael Sibina Alvan, que con su esfuerzo y dedicación nos está encaminando en el desarrollo de este curso y en la formación de nuestra carrera profesional.

INGENIERIA DE SISTEMAS

3

PROGRAMACIÓN EXTREMA

INDICE 1. Introducción-------------------------------------------------------------------6 1.1. Objetivos de la Investigación---------------------------------------------7 Objetivo General Objetivos Específicos 1.2. Justificación de la Investigación-----------------------------------------7 2. Marco Teórico-----------------------------------------------------------------8 2.1. Programación Extrema(xp)-----------------------------------------------8 2.2. Definición--------------------------------------------------------------9 2.3. Valores xp-------------------------------------------------------------10 3. Fases de la Programación Extrema------------------------------------------12 3.1. Planificación del Proyecto-----------------------------------------------12 3.2. Diseño-----------------------------------------------------------------15 3.3. Codificación-----------------------------------------------------------17 3.4. Pruebas----------------------------------------------------------------18 4. Ciclo de Vida del Programador-----------------------------------------------20 5. Características de la xp -----------------------------------------------------22 6. Objetivos de la Programación Extrema XP ---------------------------------22 7. Ventajas y Desventajas -----------------------------------------------------23 8. Roles de Personas en XP ----------------------------------------------------24 9. Herramientas de la XP ------------------------------------------------------26 10. Actividades Básicas de XP --------------------------------------------------26 11. Ciclo de Vida de XP ----------------------------------------------------------28 11.1. Exploración-----------------------------------------------------------28 11.2. Planificación de Entrega---------------------------------------------28 11.3. Iteraciones-----------------------------------------------------------30 11.4. Producción-------------------------------------------------------------31 11.5. Mantenimiento--------------------------------------------------------31 11.6. Muerte del Proyecto-------------------------------------------------32 12. Aplicación de la Programación Extrema XP---------------------------------33 Conclusión Bibliografía

INGENIERIA DE SISTEMAS

4

PROGRAMACIÓN EXTREMA

1.

INTRODUCCION

Actualmente la mayoría de los programadores no pensamos en una metodología de desarrollo a la hora de crear algún software, o sea tenemos cierta tendencia en envolvernos en cuestiones técnicas, hablar de lenguajes de programación, de técnicas de programación, de entornos de desarrollo o de editores de recursos. No hay metodología que funcione de manera universal, de hecho cada vez más las metodologías se conciben como Marco Metodológico que son necesario ajustar para cada organización y tipo de Proyecto. Realizar este ajuste es algo que requiere de una experiencia y un conocimiento previo. El problema con la implantación de una metodología es que no se suele tener una segunda oportunidad. La programación extrema, o Extreme Programming (XP), es una metodología de desarrollo ágil, una de las más exitosas en tiempo reciente. Así, la XP se puede definir como un conjunto de pasos de diversas metodologías, acopladas de manera que sean pasos flexibles a seguir utilizadas con el uso común, para realizar

un

desarrollo

más

agradable

y

sencillo.

Esta metodología tiene como base la simplicidad y como objetivo principal la satisfacción del cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales: Comunicación Es muy importante que haya una comunicación constante con el cliente y dentro de todo el equipo de trabajo, de esto dependerá que el desarrollo se lleve a cabo de una manera sencilla, entendible y que se entregue al cliente lo que necesita.

INGENIERIA DE SISTEMAS

5

PROGRAMACIÓN EXTREMA

Simplicidad En la XP se refiere que ante todo y sin importar qué funcionalidad requiera el usuario en su sistema, éste debe ser fácil. El diseño debe ser sencillo y amigable al usuario, el código debe ser simple y entendible, programando sólo lo necesario y lo que se utilizará. Retroalimentación Es la comunicación constante entre el desarrollador y el usuario. Coraje Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con tanto esfuerzo; el desarrollador debe saber cuándo el código que desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado.

INGENIERIA DE SISTEMAS

6

PROGRAMACIÓN EXTREMA

1.1 OBJETIVOS DE LA INVESTIGACIÓN Objetivo General Realizar

un

análisis

comparativo

entre

los

postulados

planteados por la Metodología XP y el proceso de elaboración de un determinado sistema informático para la satisfacción del cliente. .

Objetivos Específicos Los objetivos principales de la programación extrema son: 

Hacer llegar a entender una información clara, precisa y veraz acerca de la Metodología XP.



Plantear ventajas y desventajas de la metodología.



Desglosar el proceso del ejemplo práctico elegido a fin de realizar un análisis comparativo entre lo que se hizo en el caso práctico y lo que establece la Metodología XP.

1.2.

JUSTIFICACIÓN DE LA INVESTIGACIÓN

Este trabajo de investigación tiene como fin el poner en práctica los conocimientos obtenidos en la investigación y además poder analizar de manera adecuada ventajas y desventajas que resulten al aplicar la metodología de Programación Extrema. En este trabajo lo que se busca es en promover en el estudiante de Ingeniería de Sistemas el carácter investigativo y la habilidad de analizar metodologías de uso habitual en muchos sistemas informáticos de la actualidad.

INGENIERIA DE SISTEMAS

7

PROGRAMACIÓN EXTREMA

2.

MARCO TEÓRICO 2.1 Programación Extrema (XP) La programación extrema que en inglés es Extreme Programming más conocido como (XP), es una metodología de desarrollo muy ágil, donde es una de las más exitosas ahora en este tiempo más reciente. Al ser una metodología muy ágil se refiere al desarrollo ligero donde está basada en una serie de valores y de prácticas de buenas maneras que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. La (XP) es un enfoque de la Ingeniería de Software formulado por el famoso autor Kent Beck, quién desarrolló el primer libro con respecto al tema, donde este famoso libro fue publicado como Extreme Programming Explained en el año de 1999; fue el más destacado de los procesos ágiles de desarrollo de software.

Kent Beck, su autor, es un programador que ha trabajado en múltiples empresas y que actualmente trabaja como Programador en

la

conocida empresa automovilística

DaimlerChrysler. Se sabe que Kent Beck; fué quien eligió algunas características de otras metodologías y las relacionó de forma que cada uno tenga un complemento con la otra.

INGENIERIA DE SISTEMAS

8

PROGRAMACIÓN EXTREMA

2.2

Definición La XP se define como un conjunto de

pasos

de

diversas

metodologías, en la cual están acopladas de manera que sean pasos flexibles, con el fin de ser utilizadas para un desarrollo más agradable y sencillo. La programación extrema se basa en la simplicidad, la comunicación y el reciclado continuo de código, para algunos no es más que aplicar una pura lógica. La XP va dirigido especialmente para proyectos con requisitos muy cambiantes. En la Programación Extrema se realiza el software que el cliente solicita y necesita, en el momento que lo precisa, alentando a los programadores a responder a los requerimientos cambiantes que plantea el cliente en cualquier momento. También la XP da prioridad a los trabajos que dan un resultado directo y en los cuales se reduce la burocracia mejor dicho reducir los trámites de gestión para poder resolver un asunto; que pueda existir en el entorno de trabajo.

INGENIERIA DE SISTEMAS

9

PROGRAMACIÓN EXTREMA

2.3

VALORES XP Para que se pueda implementar las prácticas en el XP se tienen en cuenta los valores principales. Estos valores son: 

comunicación

La comunicación con el cliente es de vital importancia en XP y es por este motivo que el cliente es integrado al equipo. Además, se planifica con el cliente y este puede estar al tanto del avance de algún proyecto. Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de comunicación. 

simplicidad

La programación XP no utiliza sus recursos para la realización de actividades, sólo se desarrolla lo que el cliente demanda, de la forma más sencilla. La XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación es mejor hacer algo simple.

INGENIERIA DE SISTEMAS

10

PROGRAMACIÓN EXTREMA



Retroalimentación (feedback)

La retroalimentación concreta y frecuentación del cliente, del equipo y de los usuarios finales dando una mayor oportunidad de dirigir el esfuerzo eficazmente. Un FEEDBACK correcto y preciso hace que se pueda mantener una buena comunicación y conocer el estado actual del proyecto. Ésta se presenta dos sentidos:  Por parte del equipo de trabajo hacia el cliente: De esta manera, el cliente está al tanto del avance del proyecto.  Desde el cliente hacia el equipo de trabajo: Es cuando un cliente escribe sus historias y los programadores realizan la estimación de cada una de ellas y el cliente puede obtener inmediatamente el Feedback mejor dicho la retroalimentación cuando reincorpora todo lo aprendido en una nueva actividad.



Coraje Se refiere a la valentía que se debe tener al modificar o eliminar el código que se realizó con tanto esfuerzo; el desarrollador debe saber cuándo el código que desarrolló no es útil en el sistema y, por lo mismo, debe ser eliminado. También se refiere a tener la persistencia para resolver los errores en la programación. Si no hay coraje en un proyecto

no

se

puede

clasificar como extremo y es necesario que los otros tres valores estén presentes.

INGENIERIA DE SISTEMAS

11

PROGRAMACIÓN EXTREMA

3.

FASES DE LA PROGRAMACIÓN EXTREMA 3.1. Planificación del proyecto: En este punto se comienza a interactuar con el cliente y el resto del grupo de desarrollo para descubrir los requerimientos del sistema. En esta etapa se tendrán en cuenta ocho elementos, que son los siguientes: Historias de usuario: el primer paso de cualquier proyecto que siga la metodología XP es definir las historias de usuario. Las historias de usuario son utilizadas como herramienta para dar a conocer los requerimientos desarrollo.

del

sistema

al

equipo

de

Son pequeños textos escritas por el

cliente, también son utilizadas para estimar el tiempo que el equipo de desarrollo tomará para realizar las entregas. En una entrega se puede desarrollar una o varias historias de usuario, esto depende del tiempo que demore la implementación de cada una de las mismas. 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. El tiempo de desarrollo ideal para una historia de usuario es entre 1 y 3 semanas. Release plannig: Después de tener ya definidas las historias de usuario es necesario crear un plan de publicaciones, 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. Un "Release plan" es una planificación donde los desarrolladores y clientes establecen los INGENIERIA DE SISTEMAS

12

PROGRAMACIÓN EXTREMA

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. Iteraciones: todo proyecto que siga la metodología XP

se

ha

de

dividir

en

iteraciones

de

aproximadamente 3 semanas. Al comienzo de cada iteración los clientes deben seleccionar las historias de usuario definidas en el "Release planning" que serán implementadas. También se seleccionan las historias de usuario que no pasaron el test de aceptación que se realizó al terminar la iteración anterior. Al final de la iteración se obtiene como resultado la entrega del módulo correspondiente, el cual debe haber superado las pruebas de aceptación que establece el cliente para la verificar el cumplimiento de los requisitos. Velocidad del proyecto: es una

medida que

representa la rapidez con la que se desarrolla el proyecto. Esta medida se calcula totalizando el número de historias de usuario realizadas en una iteración.

Usando la velocidad del proyecto

controlaremos que todas las tareas se puedan desarrollar en el tiempo del que dispone la iteración. Es conveniente reevaluar esta medida cada 3 ó 4 iteraciones y si se aprecia que no es adecuada hay que negociar con el cliente un nuevo "Release Plan". Entregas pequeñas: como se había mencionado la duración de una iteración varía entre una y tres semanas, al final de la cual habrá una entrega de los INGENIERIA DE SISTEMAS

13

PROGRAMACIÓN EXTREMA

avances del producto, los cuales deberán ser completamente funcionales. Estas entregas deben caracterizarse por ser frecuentes. Reuniones: El planeamiento es esencial para cualquier tipo de metodología, es por ello que es necesario

que

los

desarrolladores

se

reúnan

diariamente y expongan sus problemas, soluciones e ideas de forma conjunta. Roles en XP El jefe de proyecto tiene como responsabilidad la dirección y organización de las reuniones que se realizan durante el proyecto. El usuario o cliente determina qué se va a construir en el sistema, además de decidir el orden en que se entregarán cada segmento del proyecto. En el grupo de los programadores se encuentran además los diseñadores y los analistas. Los programadores son quienes construyen el sistema y realizan las pruebas correspondientes a cada módulo o unidad de código. El tester o quien realiza las pruebas, colabora en la realización de las pruebas de aceptación y es quien muestra los resultados de las mismas. El rastreador (tracker) tiene como tarea observar la realización del sistema. Varias veces por

semana

cuestiona

a

los

integrantes del equipo para anotar sus INGENIERIA DE SISTEMAS

14

PROGRAMACIÓN EXTREMA

logros y avances. Programación en pareja: la programación en parejas incrementa la productividad y la calidad del software desarrollado. El trabajo en pareja involucra a dos programadores trabajando en el mismo equipo; mientras uno codifica haciendo hincapié en la calidad de la función o método que está implementando, el otro analiza si ese método o función es adecuado y está bien diseñado. De esta forma se consigue un código y diseño con gran calidad. Traslado del personal: Al mover el personal se evitan problemas relacionados con la pérdida de conocimiento y cuellos de botella. En la medida que todos los programadores entienden todas las partes del programa se evita que unos tengan una carga de trabajo muy alta mientras que otros no tengan mucho trabajo por hacer. La programación en parejas se convierte en una herramienta muy importante para lograr el objetivo del traslado de personal sin que se pierda el rendimiento.

3.2.

Diseño: En XP solo se diseñan aquellas historias de usuario que el cliente ha seleccionado para la iteración actual por dos motivos: por un lado se considera que no es posible tener un diseño completo del sistema y sin errores desde el principio. El segundo motivo es que dada la naturaleza cambiante del proyecto, el hacer un diseño muy extenso en las fases iniciales el proyecto para luego modificarlo, se considera un desperdicio de tiempo.

INGENIERIA DE SISTEMAS

15

PROGRAMACIÓN EXTREMA

Se tendrá en cuenta los siguientes aspectos: Diseños simples: La metodología X.P 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 implementable que a la larga costará menos tiempo y esfuerzo desarrollar. La idea es que se haga el diseño más sencillo que cumpla con los requerimientos de las historias de usuario. Metáfora del sistema: Es muy importante dentro del desarrollo de la metáfora darle nombres adecuados a todos los

elementos

del

sistema

constantemente, y que estos correspondan a un sistema de nombres consistente. Esto será de mucha utilidad en fases posteriores del desarrollo para identificar aspectos importantes del sistema. Tarjetas de clase, responsabilidad, colaboración (CRC): 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. Soluciones puntuales (Spike Solution): Se trata de una

pequeña

aplicación

completamente

desconectada del proyecto con la cual se intenta explorar el problema y propone una solución potencial. Puede ser burda y simple, siempre que brinde la información suficiente para enfrentar el problema encontrado. Funcionalidad

extra:

Nunca

se

debe añadir

funcionalidad extra al programa aunque se piense INGENIERIA DE SISTEMAS

16

PROGRAMACIÓN EXTREMA

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. Refactorización

(Refactoring): 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. En cada inspección que se encuentre alguna redundancia, funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa sección de código con el fin de lograr las metas de sencillez tanto en el código

en sí mismo

como en la

lectura y

mantenimiento. 3.3. Codificación Cliente siempre presente: el cliente es una parte más del equipo de desarrollo; su presencia es indispensable en las distintas fases de X.P. A la hora de codificar una historia de usuario su presencia es aún más necesaria. No olvidemos que los clientes son los que crean las historias de usuario y negocian los tiempos en los que serán implementadas. En este sentido el cliente se convierte en gran ayuda al solucionar todas las dudas que puedan surgir, especialmente cara a cara, para garantizar que lo implementado cubre con las necesidades planteadas en las historias de usuario.

INGENIERIA DE SISTEMAS

17

PROGRAMACIÓN EXTREMA

Codificar primero la prueba: Una de las ventajas de crear una prueba antes que el código es que permite identificar los requerimientos

de

dicho

código. En otras palabras, al escribir primero las pruebas se encuentran de una forma más sencilla y con mayor claridad todos los casos especiales que debe considerar el código a implementar. Integración

Secuencial: Uno de los mayores

inconvenientes presentados en proyectos de software tiene que ver con la integración, sobre todo si todos los programadores son dueños de todo el código. Para saldar este problema han surgido muchos mecanismos,

como

darle

propiedad

de

determinadas clases a algunos desarrolladores, los cuales

son

los

responsables

de mantenerlas

actualizadas y consistentes. Sin embargo, sumado al hecho que esto va en contra de la propiedad colectiva del código no se solucionan los problemas presentados por la comunicación entre clases. Integraciones

Frecuentes: Se

deben

hacer

integraciones cada pocas horas y siempre que sea posible no debe transcurrir más un día entre una integración y otra. De esta forma se garantiza surjan problemas como que un programador trabaje sobre versiones obsoletas de alguna clase.

3.4.

Pruebas: el buen uso de las pruebas depende el éxito de otras prácticas, tales como la propiedad colectiva del código y la refactorización. INGENIERIA DE SISTEMAS

18

PROGRAMACIÓN EXTREMA

Pruebas Unitarias: Estas pruebas se aplican a todos los métodos no triviales de todas las clases del proyecto con la condición que no se liberará ninguna clase que no tenga asociada su correspondiente paquete de pruebas. Uno de los elementos más importantes en estas es que idealmente deben ser construidas

antes

que

los

métodos

mismos,

permitiéndole al programador tener máxima claridad sobre lo que va a programar antes de hacerlo, así como conocer cada uno de los casos de prueba que deberá pasar, lo que optimizará su trabajo y su código será de mejor calidad. Pruebas de Aceptación: Las pruebas de aceptación, también

llamadas

pruebas

funcionales

son

supervisadas por el cliente basándose en los requerimientos tomados de las historias de usuario. Las pruebas de aceptación son pruebas de caja negra, que representan un resultado esperado de determinada transacción con el sistema. Cuando se Encuentra un Error: Al momento de encontrar un error debe escribirse una prueba antes de intentar corregirlo. De esta forma tanto el cliente logrará tener completamente claro cuál fue y dónde se encontraba el mismo como el equipo de desarrollo podrá enfocar mejor sus esfuerzos para solucionarlo. Por otro lado se logrará evitar volver a cometerlo.

INGENIERIA DE SISTEMAS

19

PROGRAMACIÓN EXTREMA

4.

CICLO DE VIDA DEL PROGRAMADOR Este ciclo de vida indica cómo trabajan los programadores para poder codificar. A continuación se detallan cada una de las actividades:  Elección de pares 

Toda la producción se realiza en pares.



El encargado de escribir piensa tácticamente, su pareja piensa estratégicamente.



Se rotan los roles periódicamente.

 Testing 

Se escriben los Testing unitarios.



Se verifica que los test fallen antes de codificar.



Se testea todo lo que posiblemente puede fallar.

 Codificación 

“Hacer algo que funcione de la manera más sencilla”



Implementar lo suficiente para hacer que el test pase.



Seguir el estándar de codificación.

 Refactoring 

Quitar toda porción de código que no parezcan estar bien y luego verificar si el código aún pasa los test unitarios.



El código debe ser claro, no tener partes duplicadas y tener la menor cantidad de clases y métodos posibles.



Realizar cambios pequeños y luego realizar los test unitarios.

INGENIERIA DE SISTEMAS

20

PROGRAMACIÓN EXTREMA

 Q&A 

El cliente puede proveer rápidamente cualquier respuesta.



Muchas preguntas requieren decisiones y el cliente debe estar preparado para poder hacerlas.



El cliente suele escribir una story o un test de aceptación que captura sus preguntas.

 Integración 

Llevar el código a la máquina donde se realiza la integración, unir el sistema y correr todos los test.



Arreglar todos los errores para que pasen todos los test unitarios.



Si no es fácil la integración es mejor tirar todo y comenzar nuevamente al día siguiente.

 Retornar al inicio 

Si resta tiempo, se puede elegir otra pareja o cambiar de roles y comenzar con otra actividad.

INGENIERIA DE SISTEMAS

21

PROGRAMACIÓN EXTREMA

5.

CARACTERÍSTICAS DE LA XP 

Las características de XP es que es una metodología liviana que es muy utilizado en diversos casos.



La XP tiene un ciclo de vida es por eso que es considerado a su vez un proceso.



La tendencia de entregar software en lapsos cada vez en menor tiempo con costos reducidos y en alta calidad.

6.

OBJETIVOS DE LA PROGRAMACIÓN EXTREMA (XP)

 Obtención del producto de software.  Satisfacción del cliente.  Potenciar el trabajo en grupo donde todos están involucrados en el desarrollo del software  Minimización del riesgo actuando sobre: Variables del proyecto: o Coste o Tiempo o Calidad o Alcance

INGENIERIA DE SISTEMAS

22

PROGRAMACIÓN EXTREMA

7.

VENTAJAS Y DESVENTAJAS

A continuación ventajas y desventajas de la PROGRAMACIÓN EXTREMA (XP): Ventajas Programación organizada. Menor taza de errores. Satisfacción del programador. Solución de errores de programas. Versiones nuevas. Implementa una forma de trabajo donde se adapte fácilmente a las circunstancias. Desventajas Es recomendable emplearlo solo en proyectos a corto plazo. Altas comisiones en caso de fallar. Imposible prever todo antes de programar. Demasiado costoso e innecesario.

INGENIERIA DE SISTEMAS

23

PROGRAMACIÓN EXTREMA

8.

Roles de personas en (XP) 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 (pair-programming) Acepta críticas (código colectivo) Cliente Pieza básica en desarrollos XP Define especificaciones (User Stories) Influye sin controlar Confía en el grupo de desarrollo Define pruebas funcionales Encargado de Pruebas Apoya al cliente en la preparación/realización de las pruebas funcionales. Ejecuta las pruebas funcionales y publica los resultados. Encargado de Seguimiento(Tracker) Recoge, analiza y publica información sobre la marcha del proyecto sin afectar demasiado el proceso. Supervisa el cumplimiento de las 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 pruebas añadidas por los errores encontrados.

INGENIERIA DE SISTEMAS

24

PROGRAMACIÓN EXTREMA

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

Consultor Apoya al equipo XP en cuestiones puntuales Jefe del Proyecto 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.

INGENIERIA DE SISTEMAS

25

PROGRAMACIÓN EXTREMA

9.

HERRAMIENTAS DE LA XP Historias de usuarios, Son tarjetas físicas en las cuales se anota una descripción de una funcionalidad del sistema, en una oración, se le da un número y un título para ser identificada. Casos de prueba de aceptación; Son tarjetas que se elaboran para realizar las pruebas de cada historia de usuario. Tarea de ingeniería; son tarjetas que se elaboran para ayudar y simplificar la programación de una historia de usuario. Tarjetas CRC; Describen las clases utilizadas en la programación de una historia.

10. ACTIVIDADES BASICAS DE XP Codificar: esta actividad es muy importante, sin código fuente no hay programa. Aunque algunos dicen que existe software en la que no se utiliza código fuente, pero es necesario codificar y plasmar nuestras ideas a través del código. En una programación en PX en pareja el código expresa tu interpretación del problema, así podemos utilizarlo 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 dan la oportunidad de saber si lo implementado es lo que en realidad se tenía en mente.

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. Las pruebas reducen los 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 INGENIERIA DE SISTEMAS

26

PROGRAMACIÓN EXTREMA

a fondo el sistema, esos agujeros que vamos dejando nos esperan para cuando pasemos de nuevo por allí y volveremos a caer dentro. Escuchar: Si vamos a hacer pruebas tenemos que preguntar si lo obtenido es lo deseado, y tenemos que preguntar a quién 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, lo apropiado es dividirla en varias. Si hay fallos en el diseño o malos diseños, estos deben de ser corregidos cuanto antes.

INGENIERIA DE SISTEMAS

27

PROGRAMACIÓN EXTREMA

11. CICLO DE VIDA DE XP 11.1. Exploración: en esta primera fase los clientes plantean las historias de usuario que son de interés para la primera entrega del producto. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologías y prácticas que se utilizarán en el proyecto. Se prueba la tecnología y se exploran las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de exploración toma de pocas semanas a pocos meses, dependiendo del tamaño y familiaridad que tengan los programadores con la tecnología.

11.2. Planificación de entrega: en esta fase el cliente establece la prioridad de cada historia de usuario y se acuerda el alcance del reléase. Los programadores estiman cuanto esfuerzo requiere cada historia y a partir de ello se toman INGENIERIA DE SISTEMAS

28

PROGRAMACIÓN EXTREMA

acuerdos sobre el contenido de la primera entrega y se determina un cronograma en conjunto con el cliente. La duración del cronograma del primer release no excede normalmente tres meses. Esta fase dura unos pocos días. . Las estimaciones de esfuerzo asociado a la implementación de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programación. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la “velocidad” de desarrollo, establecida en puntos por iteración, basándose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la última iteración. La planificación se puede realizar basándose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuántas historias se pueden implementar antes de una fecha determinada o cuánto tiempo tomará implementar un conjunto de historias. Al planificar por tiempo, se multiplica el número de iteraciones por la velocidad del proyecto, determinándose cuántos puntos se pueden completar. Al planificar según alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el número de iteraciones necesarias para su implementación.

INGENIERIA DE SISTEMAS

29

PROGRAMACIÓN EXTREMA

11.3. Iteraciones: Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega está compuesto por iteraciones de no más de tres semanas. En la primera iteración se puede intentar establecer una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creación de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qué historias se implementarán en cada iteración (para maximizar el valor de negocio). Al final de la última iteración el sistema estará listo para entrar en producción. Los elementos que deben tomarse en cuenta durante la elaboración del Plan de la Iteración son: historias de usuario no

abordadas,

velocidad

del

proyecto,

pruebas

INGENIERIA DE SISTEMAS

de

30

PROGRAMACIÓN EXTREMA

aceptación no superadas en la iteración anterior y tareas no terminadas en la iteración anterior.

11.4. Producción: La fase de producción requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusión de nuevas características a la versión actual, debido a cambios durante esta fase. Es posible que se rebaje el tiempo que toma cada iteración, de tres a una semana. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementación. 11.5. Mantenimiento: Mientras la primera versión se encuentra en producción, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones. Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar después de la puesta del sistema en producción. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura.

INGENIERIA DE SISTEMAS

31

PROGRAMACIÓN EXTREMA

11.6. Muerte del Proyecto: en esta última fase se acerca cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios en la arquitectura. La muerte del proyecto también ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo.

INGENIERIA DE SISTEMAS

32

PROGRAMACIÓN EXTREMA

12. APLICACIÓN DE LA PROGRAMACIÓN EXTREMA XP Ejemplo de una tienda de ropas utilizando la XP Descripción del proyecto En un proyecto lo que consiste es en construir un software para una tienda de ropa femenina, como es XP es aplicable para este proyecto porque la tienda es mediana. Su objetivo del proyecto es diseñar e implementar un software para la tienda, para una eficiente y rápida realización de atención al cliente, así mismo como una mejor administración de la esta. Para que se lleve a cabo se trabaja con el cliente, a la cual se ayuda para que diga que exactamente quiere que realice el software. Para ello es necesario la ayuda de los siguientes artefactos: Historia de usuario Historia de Usuario Número: 1

Usuario: Administrador y vendedor/cajero

Nombre historia: Registro de clientes Prioridad en negocio:

Riesgo en desarrollo:

Alta

Alta

Puntos estimados: 2

Iteración asignada: 1

Programador responsable: Equipo XP

Descripción: Se mostrará por pantalla una interfaz donde permitirá al administrador ingresar los datos de los clientes.

INGENIERIA DE SISTEMAS

33

PROGRAMACIÓN EXTREMA

PRUEBAS DE ACEPTACIÓN CLIENTES Casos de Prueba Código: 1

Historia de usuario: 1 registrar clientes

Nombre: Registro de Clientes Descripción: Este permitirá ingresar los datos de los clientes y almacenarlos en la base de datos. Condiciones de ejecución: Este se llevará a cabo si el cliente a registrar al menos a comprado un producto de la tienda. Entrada/ Pasos de ejecución: Tenemos como parámetros de entrada: -

Nombre del cliente

-

Apellidos del cliente

-

RUC

-

DNI

-

Teléfono

-

Dirección

Pasos de ejecución: En primer lugar tenemos que ingresar al sistema Luego ingresar los datos, enviarlos a la base de datos y por último guardarlos. Resultado esperado: Los datos ingresaron con éxito Evaluación de la prueba: Después de hacer las pruebas, nos dimos cuenta que tenemos que hacer una actualización cada vez que ingresamos un nuevo registro.

INGENIERIA DE SISTEMAS

34

PROGRAMACIÓN EXTREMA

TARJETAS CRC Registrar clientes:

REGISTRAR CLIENTES -

-

-

Obtener los datos de los

Para el registro de clientes

clientes.

se necesitaría de los datos

Conectar con la base de

de los clientes.

datos.

-

La clase cliente.

Ingresar los datos de clientes

-

La clase login.

en la base de datos. -

Confirmar los datos.

INGENIERIA DE SISTEMAS

35

PROGRAMACIÓN EXTREMA

CONCLUSIONES Permite corregir errores en las ideas del cliente, por ejemplo encontrando resultados que el cliente espera encontrar en la implementación. Permite identificar historias adicionales que no fueran obvias para el cliente o en las que cliente no hubiese pensado de no enfrentarse a dicha situación. Garantiza la cobertura de la funcionalidad de las pruebas de aceptación, garantizando que no se deja ningún punto importante de la funcionalidad de una historia de uso sin probar.

INGENIERIA DE SISTEMAS

36

PROGRAMACIÓN EXTREMA

Bibliografía modulopoo.wordpress.com/unidad-iv/ http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP) http://ingenieriadesoftware.mex.tl/52753_XP---ExtremePrograming.html http://oness.sourceforge.net/proyecto/html/ch05s02.html http://www.ecured.cu/Programaci%C3%B3n_Extrema_(XP) http://oness.sourceforge.net/proyecto/html/ch05s02.html www.codejobs.biz/es/blog/2013/01/09/que-es-la-programacionextrema-xp http://tech.groups.yahoo.com/group/xpspanish/

INGENIERIA DE SISTEMAS

37