XP - Metodología XP PDF

Preview

Summary

Metodología XP...

Description

UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA “La universidad católica de Loja”

TEMA: XP PROGRAMACIÓN EXTREMA

AUTORES: SANCHEZ CAPA LENIN PAUL

COMPONENTE:

FUNDAMENTOS DE INGENIERÍA DE SOFTWARE

DOCENTE:

ING. MARCO PATRICIO ABAD E.

CARRERA:

INGENIERIA EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN

PERIODO ACADEMICO Abr/2020 – Ago/2020

1. METODOLOGÍA Metodología XP o eXtreme Programming, es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia. Es el más destacado de los procesos ágiles de desarrollo de software.

2. AUTORES XP o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia. Es el más destacado de los procesos ágiles de desarrollo de software. Los autores principales que podemos destacar dentro de la metodología XP tenemos:       

Kent Beck Ron Jeffries Martin Fowler Alistair Cockburn Robert C. Martin Giancarlo Succi Bernhard Rumpe

 KENT BECK Kent Beck (nacido el 31 de marzo de 1961) es ingeniero de software estadounidense, uno de los creadores de las metodologías de desarrollo de software de programación extrema (eXtreme Programming o XP) y el desarrollo guiado por pruebas (Test-Driven Development), también llamado metodología ágil. Beck fue uno de los 17 firmantes originales del Manifiesto Ágil en 2001. [1] Beck posee un máster en ciencias en el área de ciencias de la computación de la Universidad de Oregon.

 

 Fue pionero en patrones de diseño de software.  Kent Beck estudió en la Universidad de Oregon entre 1979 y 1998, donde obtuvo una licenciatura y una maestría en Ciencias de la computación. En 1996 fue contratado por Chrysler para trabajar en su sistema de compensación exhaustiva, Kent Beck, a su vez, trajo a trabajar consigo a Ron Jeffries. En marzo de 1996 estimaron que el sistema sería entregado un año después. En 1997, el equipo de desarrollo adoptó una nueva forma de trabajo la cual es conocida hoy en día como Programación Extrema.

 RON JEFFRIES Ron Jeffries (nacido el 26 de diciembre de 1939) es uno de los tres fundadores de la metodología de desarrollo de software Extreme Programming (XP) alrededor de 1996, junto con Kent Beck y Ward Cunningham. Era de 1996, un entrenador de XP en el proyecto del Sistema Integral de Compensación de Chrysler, que fue donde se inventó XP. [2]     

Es autor de Extreme Programming Installed, el segundo libro publicado sobre XP. Es uno de los 17 signatarios originales del Manifiesto Ágil. Ron ha estado involucrado con Scrum, Extreme Programming y Agile durante más de diez años, presentando numerosas charlas y publicando artículos sobre el tema. Ron es el propietario de www.XProgramming.com, una fuente altamente calificada de información sobre desarrollo ágil de software. Ron es un conocido consultor independiente en métodos Scrum, XP y Agile, recientemente se especializó en ayudar a los equipos Scrum a terminar. [3]

 MARTIN FOWLER Martin Fowler (Walsall, Inglaterra 1963) es un ingeniero de software británico, autor y orador internacional sobre desarrollo de software, especializado en análisis y diseño orientado a objetos, UML, patrones de diseño, y metodologías de desarrollo ágil, incluyendo programación extrema. Comenzó a trabajar con software en los inicios de los años 1980. En 1986, una vez terminada la secundaria comenzó a trabajar en desarrollo de software en Coopers & Lybrand hasta 1991. En el año 2000 se convirtió en Chief Scientist (jefe científico) en ThoughtWorks, una compañía de integración de sistemas y consultoría. [4] Fowler ha escrito siete libros sobre el tema Desarrollo de software (ver Publicaciones). Es miembro de Agile Alliance y ayudó a crear el Manifiesto para el desarrollo ágil de software en 2001.  Él mantiene un bliki, una mezcla de blog y wiki.  Él fue uno de los autores del Manifiesto Ágil para el Desarrollo de Software, y ha escrito siete libros premiados acerca de desarrollo de software.  Su principal interés está en entender como diseñar sistemas de software, para maximizar la productividad de equipos de desarrollo.  Se ha enfocado en entender los patrones de buen diseño de software, y los procesos que apoyan el diseño de software.  ALISTAIR COCKBURN  

Alistair Cockburn (nacido el 19 de noviembre de 1963) es un científico de la computación estadounidense, conocido como uno de los iniciadores del ágil movimiento en el desarrollo de software. Firmó el Manifiesto para el desarrollo de software ágil. [5] Cockburn comenzó a estudiar los métodos de desarrollo de software orientado a objetos para IBM. A partir de 1994, formó "Humanos y Tecnología". Obtuvo su título en ciencias de la computación en la Case Western Reserve University. 

 

Es uno de los principales expositores del caso de uso para documentar los procesos comerciales y los requisitos de comportamiento para el software, e inventor de la escala de Cockburn para clasificar los proyectos de software. Cockburn presentó su Arquitectura Hexagonal (2005) como una solución a problemas con, por ejemplo, estratificación, acoplamiento y enredo tradicionales. En 2015, Alistair lanzó el movimiento Heart of Agile, que se presenta como una respuesta al estado excesivamente complejo de la industria Agile.

El Dr. Alistair Cockburn, coautor del Manifiesto Ágil, fue votado entre los "150 héroes informáticos de todos los tiempos" en 2007. Es autor de los libros premiados " Desarrollo de software ágil: el juego cooperativo " y " Uso eficaz de la escritura " Cases”, cofundador del Consorcio Internacional para Agile, y creador del concepto Heart of Agile. 

Con más de 25 años de experiencia, las especialidades de Alistair incluyen psicología organizacional, gestión de proyectos, metodologías ágiles, recolección de requisitos y diseño orientado a objetos.

 ROBERT C. MARTIN Robert Cecil Martin (nacido en 1952) Robert Cecil Martin (coloquialmente conocido como Uncle Bob) es un ingeniero de software y autor estadounidense. Es coautor del Manifiesto Ágil. Ahora dirige una empresa de consultoría llamada Uncle Bob Consulting LLC y Clean Coders (Tío Bob Consulting LLC y codificadores limpios), que aloja videos basados en sus experiencias y libros. [6]

  

Martin operaba una empresa ya desaparecida, Object Mentor, que ofreció cursos de capacitación dirigidos por un instructor sobre metodología de programación extrema. Cinco de los principales principios propugnados por Martin se han conocido colectivamente como los " principios SÓLIDOS" y han recibido una amplia atención en la industria del software. Martin es autor de numerosos libros y artículos de revistas. También es un defensor abierto de la artesanía del software, el desarrollo ágil de software y el desarrollo de software basado en pruebas.

 GIANCARLO SUCCI Profesor de Ingeniería de Software, Universidad de Innopolis DoctorUniversidad de Génova, Italia.Profesor de tiempo completoDecano, Facultad de Informática e Ingeniería de SoftwareJefe de Laboratorio de Producción Industrial de SoftwareInstituto de Desarrollo de Software e IngenieríaEducación: Computación e Ingeniería EléctricaInstituto: Instituto de Desarrollo e Ingeniería de Software [7]

 - -----------

 BERNHARD RUMPE Bernhard Rumpe (nacido en 1967) es un informático alemán, profesor de informática y jefe del Departamento de Ingeniería de Software. Su investigación se centra en "tecnologías, métodos, herramientas necesarias para crear software con la calidad necesaria que sea lo más eficiente y sostenible posible". [8]  

Rumpe dirigió el Instituto de Ingeniería de Sistemas de Software de la Universidad Tecnológica de Braunschweig Rumpe contribuyó a la semántica y al uso de lenguajes de modelado en el desarrollo de software (requisitos, arquitectura, generación de código, configuración del sistema, gestión de calidad).

Sus principales intereses son los métodos y técnicas de desarrollo de software que se benefician de enfoques tanto rigurosos como prácticos. Esto incluye el impacto de las nuevas tecnologías, como la ingeniería de modelos basada en notaciones similares a UML y lenguajes específicos de dominio y métodos evolutivos basados en pruebas, arquitectura de software, así como las implicaciones metódicas y técnicas de su uso en la industria.

3. ORIGEN E IMPORTANCIA. La Programación Extrema, como proceso de creación de software diferente al convencional, nace de la mano de Kent Beck (autor de los libros más influyentes sobre el tema). Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas, pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de 1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal. Beck reconoció que el proceso (o metodología) de creación de software o la carencia de este era la causa de todos los problemas y llegó a la conclusión que para proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o manera de hacer de los programadores, los cuales se tenían que acomodar al cambio a realizar. El tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema. 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 dentro del equipo, que la implementación fuera sencilla, que el usuario tenía que estar muy informado y implicado y que la toma de decisiones tenía que ser muy rápida y efectiva. Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham o Ron Jeffries entre otros) de la Programación Extrema, fueron a la 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. Este hecho, llegó a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programación. Fue tanta esta molestia que nació el fenómeno XP Free Zone (zona libre de XP) en determinadas webs como petición de no hablar de Programación Extrema en ella. La discusión sobre temas de diseño de modelos de programación sobre los cambios recientes se hizo tema difícil porque la mayoría de la actividad fue relacionada con la Programación Extrema. [9] El extreme programming está orientado a las necesidades del cliente. Aunque esto parece obvio, el desarrollo de software clásico solo puede atender a los deseos de los clientes de manera limitada, lo que se vuelve particularmente complicado ciertos requisitos van cambiando continuamente. Además, XP trata de fomentar la creatividad de los desarrolladores y acepta los errores como una parte natural del trabajo. Además, XP, al igual que otros métodos ágiles, parte de los procesos iterativos. XP rompe con la tradición de completar un proyecto durante meses de principio a fin para que al final el resultado no sea el adecuado. En lugar de esto, se hacen comprobaciones, se habla y se publica constantemente en ciclos cortos. De esta forma se pueden determinar y eliminar los fallos rápidamente. [10]

4. FASES, PROCESOS, ARTEFACTOS. XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. Los principios en los que se basa son de sentido común pero llevadas al extremo, de ahí el porqué de su nombre. Algunas de las características esenciales de XP se exponen a continuación: 4.1 Historias de Usuario Las historias de usuario son la técnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las características que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de estas historias es muy dinámico y flexible. Cada historia debe ser lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. [11] Respecto a la información contenida en la historia de usuario, existen varias plantillas sugeridas, pero no existe un consenso al respecto. Usualmente se propone utilizar un nombre y una descripción y quizás una estimación de esfuerzo en días. Las historias de usuario son descompuestas en tareas de programación y asignados a los programadores para ser implementadas posteriormente. 4.2 Roles XP Aunque se suele encontrar información con algunas variaciones, se describirán en este apartado los roles de acuerdo con la propuesta original de Beck 

Programador. El programador se encarga de escribir las pruebas unitarias y produce el código del sistema. Es indispensable una comunicación y coordinación adecuada entre los programadores y los otros miembros del equipo



Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación.



Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas



Encargado de seguimiento (Tracker). Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. También realiza el seguimiento del progreso de cada iteración y evalúa si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes.



Entrenador (Coach). Responsable del proceso global. Encargado de que todos los miembros del equipo sigan el proceso correctamente



Consultor. Miembro externo del equipo con conocimiento específico en algún tema necesario para el proyecto.



Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación

4.3 Proceso XP Un proyecto XP tiene éxito cuando el cliente selecciona el valor de negocio a implementar basado en la habilidad del equipo para medir la funcionalidad que puede entregar a través del tiempo. El ciclo de desarrollo consiste en los siguientes pasos: [11] 1. El cliente define el valor de negocio a implementar 2. El programador estima el esfuerzo necesario 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo 4. El programador construye ese valor de negocio 5. Vuelve al paso 1 No se debe presionar al programador a realizar más trabajo del estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. El ciclo de vida ideal de XP consiste de seis fases [12]: Fase 1: Exploración En esta fase, los clientes plantean a grandes rasgos 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. El tiempo tomado en la fase de exploración depende del tamaño y familiaridad que tengan los programadores con la tecnología. Fase 2: Planificación de la Entrega En esta fase el cliente establece la prioridad de cada historia de usuario, y correspondientemente, los programadores realizan una estimación del esfuerzo necesario de cada una de ellas. Se determina un cronograma en conjunto con el cliente. 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. Fase 3: Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. 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.

Fase 4: Producción Consiste en pruebas y comprobación del funcionamiento del sistema antes de que éste se pueda liberar al cliente. En esta fase, los nuevos cambios pueden todavía ser encontrados y tomar la decisión de si se incluyen o no. Durante esta fase, las iteraciones pueden ser aceleradas de una a tres semanas. Las ideas y sugerencias propuestas se documentan para una puesta en práctica posterior, como en la fase de mantenimiento. Fase 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 pueta del sistema en producción. Fase 6: Muerte del Proyecto Esto sucede cuando el cliente no tiene más historias para ser incluidas en el sistema. Esto requiere que se satisfaga todas las necesidades del cliente en aspectos como rendimiento y confiabilidad del sistema. Se genera la documentación final del sistema y no se realizan más cambios a 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.

5. VENTAJAS Y DESVENTAJAS. Como es común, toda metodología presenta algunas ventajas y desventajas de ser implementadas [13] [14], las cuales se citan a continuación: 5.1 Ventajas  Se adapta al desarrollo de sistemas pequeños y grandes.  Da lugar a una programación sumamente organizada.  Ocasiona eficiencias en el proceso de planificación y pruebas.  Cuenta con una tasa de errores muy pequeña.  Propicia la satisfacción del programador.  Fomenta la comunicación entre los clientes y los desarrolladores.  Facilita los cambios.  Permite ahorrar mucho tiempo y dinero.  Puede ser aplicada a cualquier lenguaje de programación.  El cliente tiene el control sobre las prioridades.  Se hacen pruebas continuas durante el proyecto.  La XP es mejor utilizada en la implementación de nuevas tecnologías.  El código es sencillo y entendible, además de la poca documentación a elaborar para el desarrollo del sistema.

5.2 Desventajas  Es recomendable emplearla solo en proyectos a corto plazo.  En caso de fallar, las comisiones son muy altas.  Requiere de un rígido ajuste a los principios de XP.  Puede no siempre ser más fácil que el desarrollo tradicional.  No se tiene la definición del costo y el tiempo de desarrollo.  El sistema va incorporando nuevas funciones en cada entrega al cliente y nadie puede decir que el cliente no querrá una función más.  Se requiere de la presencia constante del cliente.  Desacuerdo entre los programadores.

6. RECOMENDACIÓN DE USO. Para que esta metodología funcione, la programación extrema se basa en doce “prácticas básicas” que deben seguirse al pie de la letra. [12]  Equipo completo. Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto  Planificación. Se debe planificar en qué orden se dará cumplimiento a las historias de usuario. La planificación se debe revisar continuamente  Cliente in-situ. El cliente, con la ayuda de los programadores, propone sus propias pruebas para validar las mini-versiones  Mini-versiones. Partes del proyecto final que de...