CLASE 29/10/2015 LEGAJO:17755 ROSA MAVEL OIRTIZ

Clase 29/10/2015

LA CONSIGNA DE LA CLASE ES LA SIGUIENTE:

A) INVESTIGUE SOBRE METODOLOGIAS DE DESARROLLO DE SOFTWARE

HAGA UNA MATRIZ COMPARATIVA , ENTRE TRES METODOLOGIAS : RUP, SCRUM, OTRA A ELECCION.

LOS ITEMS A COMPARAR

- ETAPAS Y ACTIVIDADES 

- DURACION

- PARA QUE CASOS SE APLICA-

- VENTAJAS

-DESVENTAJAS

 METODOLOGIAS PARA DESARROLLO DE SOFTWARE

 METODOLOGÍAS PARA DESARROLLO

Un proceso de detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” parae referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso .

A continuación se revisan brevemente cada una de estas categorías de metodologías:

 

METODOLOGÍAS ESTRUCTURADAS

 

Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación.

 

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering.

 

METODOLOGÍAS ORIENTADAS A OBJETOS

 

Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación Orientada a Objetos más popular en la actualidad.

Algunas metodologías orientadas a objetos que utilizan la notación UML son:

 

·         Rational Unified Process (RUP),

·         OPEN,

·         MÉTRICA (que también soporta la notación estructurada).

 

METODOLOGÍAS TRADICIONALES

 

Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil.

 

METODOLOGÍAS ÁGILES

 

Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento).

Entre las metodologías ágiles identificadas son:

·         Extreme Programming

·         Scrum

·         Familia de Metodologías Crystal

·         Feature Driven Development

·         Proceso Unificado Rational, una configuración ágil

·         Dynamic Systems Development Method

·         Adaptive Development

·         Open SourceDevelopmen

SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGÍAS PARA DESARROLLO DE 

·         Rational Unified Process (RUP)

·         Extreme Programming (XP)

·         SCRUM

Consiste en un ciclo de desarrollo corto basado en 3 fases (diseño-requisitos-construcción) con un plazo de entrega ideal de 90 a 120 días como máximo.

Metodología Scrum

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

 Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades. 

 Beneficios

·         Cumplimento de expectativas: El cliente establece sus expectativas indicando el valor que le aporta cada requisito /historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos de Sprint el Product Owner comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.

·         Flexibilidad a cambios: Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.

·         Reducción del Time to Market: El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.

·         Mayor calidad del software: La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.

·         Mayor productividad: Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.

·         Maximiza el retorno de la inversión (ROI): Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.

·         Predicciones de tiempos: Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.

·         Reducción de riesgos: El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada. 

Ventajas y desventajas de SCRUM (I)

Si estás considerando SCRUM como método de trabajo pero no sabes muy bien de qué va todo esto. Has oído a un montón de gente hablándote de las bondades de este sistema pero ¿cuántas tecnologías y técnicas no han aparecido rápidamente y desaparecido a mayor velocidad aún? Todas prometían ser revolucionarias así que cuando oímos tanto bombo sobre alguna arqueamos una ceja en actitud crítica.

Hace algunas semanas publiqué un prezi en el que explicaba las ventajas y inconvenientes de implantar SCRUM en una organización. Las comentaré ahora en esta entrada, esta vez con palabras en lugar de imágenes, comenzando por sus inconvenientes (trataré de ser parcial, pero no lo prometo)

El equipo puede estar tentado de tomar el camino más corto

Cuando cada dos semanas hay cosas que entregar, en las últimas entregas no se completaron todas las funcionalidades previstas y la velocidad del equipo no predice que vayamos a terminar en plazo tenemos un problema: puede surgir la tentación de resolver las tareas pendientes de cualquier manera y dejar 'deudas' técnicas en el trabajo. Aparentemente todo va bien, más funcionalidades hechas, empezamos otras nuevas y el cliente está contento porque se están cumpliendo los plazos.

Pero siempre que se deja un borrón ahí atrás puedo asegurarte que volverás a tropezar con él. Si nuevas cosas han sido construidas sobre este borrón, la 'deuda' comenzará a multiplicarse. Antes o después tendrás que parar todo y devolver la deuda comprometida (con intereses de demora) El proyecto no termina de cerrarse cuando parecía que ya quedaba poco por acabar: la gráfica burndown parece tener una asíntota horizontal en 0 (lo siento, deformación profesional/educacional, Cálculo I)

¿Necesitas con mucha antelación fechas exactas de entrega?

Esta es una de las críticas más habituales a SCRUM. En cierta forma es lógico, al inicio del proyecto no puedes predecir cuando lo vas a acabar si estás facilitando que lo que se va a construir cambie y varíe en el tiempo. ¿Se prefiere un producto que se sabe con certeza que va a finalizar en 10 meses pero que está construido sobre las ideas y opiniones que se tenían cuando se comenzó? Quizás se prefiera un producto que podría acabar en el plazo similar pero que hemos podido evolucionar hacia nuestras necesidades reales y que hemos podido usar y probar antes de la entrega final.

¡Stress!

No nos podemos pasar la vida esprintando. Hacemos una entrega y ya nos comprometemos para la siguiente que está solo a un par de semanas vista. Luego otra y otra. Si tenemos que recorrer muchos kilómetros así comenzaremos con un rápido sprint para llegar a la primera meta pero llegaremos caminando a la última, eso con suerte.

¿El equipo es autoorganizado?

Una de los principios de SCRUM es que el equipo debe tomar sus propias decisiones y autogestionarse. Además, se requiere que no haya miembros especializados en tareas concretas como análisis, tests, diseño, documentación, etc. sino que todos los integrantes del equipo sepan hacer de todo y puedan intercambiarse entre sí. ¿Siempre contamos con un equipo así? ¿Qué pasa si no lo tenemos?

Desde luego es un problema pero ¿no lo sería también con cualquier otra forma de trabajo? ¿Hay alguna que permita llevar proyectos a buen puerto con equipos con poca experiencia?

En otra entrada hablaré sobre las ventajas de SCRUM (seguro que no es tan popular)

Si te interesa saber más sobre la certificación Professional Scrum Master I, estimaciones, ventajas y desventajas de Scrum o cómo gestionar proyectos de forma ágil quizás te interese mi libro: Gestión práctica de proyectos con Scrum.

METODOLOGÍA RUP.

Es una metodología cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de la organización.

Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP es un conjunto de metodologías adaptables al contexto y necesidades de cada organización.
Describe como aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos para su realización.
Se centra en la producción y mantenimiento de modelos del sistema.

Principales características

·         Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)

·         Pretende implementar las mejores prácticas en Ingeniería de Software

·         Desarrollo iterativo

·         Administración de requisitos

·         Uso de arquitectura basada en componentes

·         Control de cambios

·         Modelado visual del software

·         Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

CICLO DE VIDA

Esfuerzo en actividades según fase del proyecto
El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades.

Fases del ciclo de vida del RUP:

1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.

2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.

3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

4. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.


La metodología RUP tiene 6 principios clave:

1. Adaptación del proceso: El proceso debe adaptarse a las características de la organización para la que se está desarrollando el software.

2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto.

3. Colaboración entre equipos: Debe haber una comunicación fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En cada iteración se evaluará la calidad y estabilidad del producto y analizará la opinión y sugerencias de los inversores.

5. Elevar el nivel de abstracción: Motivar el uso de de conceptos reutilizables.

6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la producción.

Disciplina de desarrollo de RUP

Determina las etapas a realizar durante el proyecto de creación del software.

·         Ingeniería o modelado del negocio: Analizar y entender las necesidades del negocio para el cual se está desarrollando el software.

·         Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.

·         Análisis y diseño: Trasladar los requisitos analizados anteriormente a un sistema automatizado y desarrollar una arquitectura para el sistema.

·         Implementación: Crear software que se ajuste a la arquitectura diseñada y que tenga el comportamiento deseado.

·         Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado está presente.

·         Despliegue: Producir distribuciones del producto y distribuirlo a los usuariosDisciplina de soporte RUP
Determina la documentación que es necesaria realizar durante el proyecto.

·         Configuración y administración del cambio: Guardar todas las versiones del proyecto.

·         Administración del proyecto: Administrar los horarios y recursos que se deben de emplear.

·         Ambiente: Administrar el ambiente de desarrollo del software.

·         Distribución: Hacer todo lo necesario para la salida del proyecto..

¿Cuáles son las ventajas y desventajas?

Ventajas

·                     Requiere conocimientos del proceso y de UML.

·                     Progreso visible en las etapas tempranas.

·                     El uso de iteraciones (actividades).

·                     Facilita la reutilizacion del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual ademas permite que se aprecien oportunidades de mejoras en el diseño. 

Desventajas

·                     Por el grado de complejidad puede no resultar muy adecuado.

·                     RUP es generalmente mal aplicado en el estilo cascada.

METODOLOGIA XP

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

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 cómo 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. 

PROCESO DE DESARROLLO 

La programación extrema parte del caso habitual de una compañía que desarrolla software normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validación posterior al mismo. 

1. Interacción con el cliente.
En este tipo de programación el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificación. Tiene un papel importante de interacción con el equipo de programadores, sobre todo después de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus sensaciones... En este tipo de programación existirán pruebas de aceptación de la programación que ayudarán a que su labor sea lo más provechosa posible. 
Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. 
En XP aparece un nuevo concepto llamado “Historia de usuario”. Se trata de una lista de características que el cliente necesita que existan en el producto final. Estas constan de dos fases: 
o En la primera fase, el cliente describe con sus propias palabras las características y, es el responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto de historias y las ordena en función de la prioridad que tienen pera él. De esta manera ya es posible definir unas fechas aproximadas para ellos. 
o En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de desarrolladores, esto dará como resultado una planificación más exacta. Este método se repetirá para cada historia. 

A diferencia de otras técnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. 
En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y asignarles una duración. La norma es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programación. Las que requieran menos tiempo serán agrupadas, y las que necesiten más serán modificadas o divididas. 
Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, así como el trabajo de los programadores que podrán catalogarlas correctamente. Este formato también es muy útil en el momento de las pruebas de aceptación. 

PLANIFICACIÓN DEL PROYECTO 

En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada. 
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial, menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más posibilidades de detectarse rápidamente. 
Una de las máximas a aplicar es, los cambios, no han de suponer más horas de programación para el programador, ya que el que no se termina en un día, se deja para el día siguiente. 
Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificación. 
Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa, en la que se anotarán las historias de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las que se escribirán los trabajos que durarán entre uno y tres días. 
Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no han estado programados. 
Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una práctica que no existía en la programación tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos. 

DISEÑO, DESARROLLO Y PRUEBAS 

El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones y en dirección correcta. 
También es muy importante el diseño, y se establecen los mecanismos, para que éste sea revisado y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo funcionalidades al mismo. 
La clave del proceso de desarrollar XP es la comunicación. La mayoría de los problemas en los proyectos son por falta de comunicación en el equipo. 
En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar la comunicación entre todos los integrantes del equipo, al crear una visión global y común de lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollará con alguna cosa de la vida real. 
Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: 
Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y se continúa. En XP hay una máxima que dice "Todo el código que puede fallar tiene que tener una prueba". 
Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por esto es importante pasar las pruebas al 100%. 
Respecto a la integración del soft, en XP se ha de hacer una integración continua, es decir, cada vez se tienen que ir integrando pequeños fragmentos de código, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final. En todo buen proyecto de XP, tendría que existir una versión al día integrada, de manera que los cambios siempre se realicen en esta última versión. 
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa. 
De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integración diaria. 
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programación en parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarán con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el ratón. El principio fundamental de este hecho es realizar de manera continua y sin parar el desarrollo de código. Las parejas tienen que ir cambiando de manera periódica, para hacer que el conocimiento se difunda en el grupo. Está demostrado que de esta manera el trabajo es más eficaz y también se consigue más y mejor código.

PROGRAMACION EXTREMA XP 

HISTORIA 

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

INTRODUCCION

 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. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

VENTAJAS Y DESVENTAJAS

Ventajas: 

Programación organizada.

Menor taza de errores.

Satisfacción del programador.

Desventajas: 

Es recomendable emplearlo solo en proyectos a corto plazo.

Altas comisiones en caso de fallar.

   

COMPARACION ENTRE XP Y RUP

Comparación entre RU


Comparación entre RUP y SCRUM:

RUP

1.            ¿Que es RUP?

Forma disciplinada o metodología de asignar tareas y responsabilidades en  una empresa de desarrollo (quién hace qué, cuándo y cómo). Esta metodología, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software: 

o        ·        Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.

o        ·        Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.

o        ·    Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.

o        ·         Transmisión, El objetivo es llegar a obtener el release del proyecto.

2.            DISCIPLINA DE DESARROLLO

La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software: 

o        ·       Inicio, El Objetivo en esta etapa es determinar la visión del proyecto.

o        ·       Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima.

o        ·    Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial.

o        ·        Transmisión, El objetivo es llegar a obtener el release del proyecto.

Metodología de Desarrollo de Software, María A. Sánchez Mendoza (Junio 7, 2003)

                                                           

3.            DISCIPLINA DE SOPORTE

·         Configuración y administración del cambio: Guardando todas las versiones del proyecto.

·         Administrando el proyecto: Administrando horarios y recursos.

·         Ambiente: Administrando el ambiente de desarrollo.

·         Distribución: Hacer todo lo necesario para la salida del proyecto

4.  

5.            ELEMENTOS DE RUP

·         Actividades, Son los procesos que se llegan a determinar en cada iteración.

·         Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.

·    Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.

1.             

2.             

3.            ¿QUE ES XP?

La Programación Extrema es una metodología ligera de desarrollo de  software que se basa en la simplicidad, la comunicación y la  realimentación o reutilización del código desarrollado. Se requiere un grupo pequeño de programadores para  trabajar con esta metodología entre 2 – 15 personas y  estas irán aumentando conforme sea necesario.

Metodologia Extreme Programing

4.            CARACTERÍSTICAS XP

·         Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal   manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de las fallas que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.

·         Refabricación: se basa en la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más flexible al cambio.

·        Programación en pares: una particularidad de esta metodología es que propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento. Es como el chofer y el copiloto: mientras uno conduce, el otro consulta el mapa.

5.            ¿QUE ES LO QUE PROPONE XP?

·         Empieza en pequeño y añade funcionalidad con retroalimentación continua

·         El manejo del cambio se convierte en parte sustantiva del proceso

·         El costo del cambio no depende de la fase o etapa

·         No introduce funcionalidades antes que sean necesarias

·         El cliente o el usuario se convierte en miembro

SCRUM

1.            ¿QUE ES?

Es una metodología ágil y flexible para gestionar el desarrollo de software. Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de  inspección continua, adaptación, auto-gestión e innovación.

2.            CARACTERÍSTICAS

 ·      Solo abarca practicas de gestión sin entrar en las practicas de desarrollo como puede  hacer XP

·         Delega completamente en el equipo la responsabilidad de decidir la mejor manera de trabajar para ser lo más productivo posibles y, le dan gran protagonismo a las reuniones que realicen a lo largo del proyecto.

·         Sus raíces teóricas están en las teorías de la auto-organización.

3.            ROLES

        I.            Prorduct Owner (Dueño del producto)

·         Representa a todos los interesados en el producto final.

·         Marca las prioridades del producto.

·         Lleva el control de las estimaciones.

·         Retorno de Inversión (ROI.)

      II.            Scrum Master

·         Responsables del proceso de Scrum

·         Incorporación de Scrum en la cultura de la organización.

·         Asegura el cumplimiento de los roles y responsabilidades

·         Formación y entrenamiento en el proceso.

    III.            Scrum Team

·      Debe trasformar las tareas del Sprint Backlog en un incremento de funcionalidad en el software.

·         Desarrollar el producto con calidad

·         Auto-gestionado

·         Auto-organizado

·         Multi-funcional

·         No mayor a ocho elementos

Scrum hace una clara diferencia entre gallinas y cerdos, para garantizar quienes tienen la responsabilidad, la autoridad necesaria para poder lograr el éxito del proceso y que quienes no la tienen y no puedan o producen interferencias innecesarias.

4. METODOLOGÍA DE TRABAJO

·       Equipos de 6 y 10 personas revisan los requisitos, tecnología disponible y otras funciones   para determinar cómo incrementar la funcionalidad.

·        Reuniones diarias, antes de empezar a trabajar, con una duración máxima de 4 horas.

·       En cada reunión las preguntas claves a contestar son: ¿Qué es lo que hizo desde la última  reunión?, ¿Qué es lo que se va a hacer hasta la siguiente reunión? y ¿Cómo se va a llevar a cabo?

Proceso ágil de desarrollo iterativo e incremental. Origen: articulo "Ther New New Product Develepment Game" (Takeuchi y Nonaka, 1986)