Metodología Rational Unified Process (RUP)

Es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo y cómo).

Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus estimaciones originales. Requiere un grupo grande de programadores para trabajar con esta metodología.

Las iteraciones tempranas de proyectos conducidos RUP se enfocan fuertemente sobre arquitectura del software; la puesta en práctica rápida de características se retrasa hasta que se ha identificado y se ha probado una arquitectura firme.

RUP proporciona muchas ventajas sobre XP le da énfasis en los requisitos y el diseño. La ventaja principal de RUP es que se basa todo en las mejores prácticas que se han intentado y se han probado en el campo. (en comparación con XP que se basa en las prácticas inestables que utilizaron juntas se evita que se derribe).

RUP se divide en cuatro fases: Inicio (Define el alcance del proyecto) Elaboración (definición, análisis, diseño) Construcción (implementación) Transición (fin del proyecto y puesta en producción)

Planear las 4 fases incluye: Asignación de tiempo Hitos Principales Iteraciones por Fases Plan de proyecto.

RUP define nueve disciplinas a realizar en cada fase del proyecto:

Modelado del negocio ,Análisis de requisitos ,Análisis y diseño ,Implementación ,Test ,Distribución, Gestión de configuración y cambios ,Gestión del proyecto, y Gestión del entorno.

Iterativo e incremental:

Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de desarrollo completo dando como resultado una entrega de producto ejecutable (interna o externa)

RUP realiza un levantamiento exhaustivo de requerimientos, Busca detectar defectos en las fases iniciales,Intenta reducir al número de cambios tanto como sea posible,Realiza el Análisis y diseño, tan completo como sea posible.

RUP Tiene un Diseño genérico, intenta anticiparse a futuras necesidades.

El cliente interactúa con el equipo de desarrollo mediante reuniones a diferencia de la metodología XP que el cliente es parte del equipo

Metodología Extreme Programming (XP)

Nace en busca de simplificar el desarrollo del software y que se lograra reducir el costo del proyecto.

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 necesarios. Sus programadores pueden ser ordinarios.

Combina las que han demostrado ser las mejores prácticas de desarrollo de software, y las lleva al extremo.

El desarrollo de software es riesgoso y difícil de controlar.

Se rediseñará todo el tiempo (refactoring), dejando el código siempre en el estado más simple posible.

Las iteraciones serán radicalmente más cortas de lo que es usual en otros métodos, esto permite beneficiarse de la retroalimentación tan a menudo como sea posible.

XP define 4 variables para el proyecto de software:

Coste ,Tiempo ,Calidad yAlcance.

XP tiene como valores lo siguiente:

Comunicación ,Simplicidad ,Realimentación ,Coraje.

Este es un conjunto mínimo y consistente de valores que permitirán hacer la vida más fácil del grupo, la gerencia y los clientes. Sirve tanto a los fines humanos como a los comerciales.

XP deriva una docena de Principios Básicos:

Realimentación rápida, Asumir la Simplicidad, El Cambio Incremental, Adherirse (Abrazar) al Cambio, Trabajo de Alta Calidad (desde ‘trabajo excelente’ hasta ‘trabajo increíblemente sobresaliente’).

XP desarrolla 4 actividades que guiarán el desarrollo:

Codificar ,Testear ,Atender ,Diseñar.

Doce practicas de XP:

Jugar el juego de planificación.

Hacer pequeños Releases.

Hacer historias y usar metáforas.

Diseñar simple.

Probar –Testear.

Rearmar – Refactorizar.

Programar por pares.

Propiedad Colectiva.

Integrar Continuamente.

Semanas de 40 horas.

Cliente On-Site.

Usar Standares de Codificación

XP tiene una debilidad cuando se utiliza en dominios de aplicaciones complejas o situaciones difíciles en la organización: el rol del cliente no refleja los diferentes intereses, habilidades y fuerzas a las que enfrentan los programadores durante el desarrollo de proyectos.

XP define UserStories como base del software a desarrollar. Estas historias las escribe el cliente y describen escenarios sobre el funcionamiento del software, que no solo se limitan a la GUI si no también pueden describir el modelo, dominio, etc.

XP se puede ver técnico como caso de RUP, aunque él se parece ser algo diferente en cultura. En el hecho, racional incluso proporciona un XP plugin para su software de RUP.

XP intenta minimizar el riesgo de fallo del proceso por medio de la disposición permanente de un representante competente del cliente a disposición del equipo de desarrollo. Este representante debería estar en condiciones de contestar rápida y correctamente a cualquier pregunta del equipo de desarrollo de forma que no se retrase la toma de decisiones.

Roles XP:

Programador (Programmer) :

Responsable de decisiones técnicas

Responsable de construir el sistema

Sin distinción entre analistas, diseñadores o codificadores

En XP, los programadores diseñan, programan y realizan las pruebas

Jefe de Proyecto (Manager) :

Organiza y guía las reuniones

Asegura condiciones adecuadas para el proyecto

Cliente (Customer) :

Es parte del equipo

Determina qué construir y cuándo

Establece las pruebas funcionales

Encargado de Pruebas (Tester) :

Ayuda al cliente con las pruebas funcionales

Se asegura de que las pruebas funcionales se superan

Rastreador (Tracker):

Observa sin molestar

Conserva datos históricos

Entrenador (Coach) :

Responsable del proceso

Tiende a estar en un segundo plano a medida que el equipo madura

Metodología de Desarrollo rápido de aplicaciones (RAD)

Es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Fases del RAD:

Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

¿Porqué Usar RAD?

Malas razones

Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en manejo de costos).

Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en manejo de tiempo).

Buenas razones

Convergir tempranamente en un diseño aceptable para el cliente y posible para los desarrolladores.

Limitar la exposición del proyecto a las fuerzas de cambio. Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de calidad del producto.

Características de RAD:

Equipos Híbridos

Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo del sistema así como aquellas personas involucradas con los requisitos.

Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

Herramientas Especializadas

Desarrollo "visual" Creación de prototipos falsos (simulación pura) Creación de prototipos funcionales Múltiples lenguajes Calendario grupal Herramientas colaborativas y de trabajo en equipo Componentes reusables Interfaces estándares (API)

"Timeboxing"

Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

Prototipos Iterativos y Evolucionarios.

Reunión JAD (Joint Application Development):o Se reunen los usuarios finales y los desarrolladores.o Lluvia de ideas para obtener un borrador inicial de los requisitos.

Iterar hasta acabar:o Los desarrolladores construyen y depuran el prototipo basado en los requisitos

actuales.

o Los diseñadores revisan el prototipo.o Los clientes prueban el prototipo, depuran los requisitos.o Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los

requisitos y generar solicitudes de cambios.o Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se

eliminan si es necesario para cumplir el calendario.

Ventajas

1. Comprar puede ahorrar dinero en comparación con construir.2. Los entregables pueden ser fácilmente trasladados a otra plataforma.3. El desarrollo se realiza a un nivel de abstracción mayor.4. Visibilidad temprana.5. Mayor flexibilidad.6. Menor codificación manual.7. Mayor involucramiento de los usuarios.8. Posiblemente menos fallas.9. Posiblemente menor costo.10. Ciclos de desarrollo más pequeños.11. Interfaz gráfica estándar.

Desventajas

1. Comprar puede ser más caro que construir.2. Costo de herramientas integradas y equipo necesario.3. Progreso más difícil de medir.4. Menos eficiente.5. Menor precisión científica.6. Riesgo de revertirse a las prácticas sin control de antaño.7. Más fallas (por síndrome de “codificar a lo bestia”).8. Prototipos pueden no escalar, un problema mayúsculo.9. Funciones reducidas (por “timeboxing”).10. Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.

Metodología SCRUM

Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto.

Scrum es una metodología ágil, y como tal:

Es un modo de desarrollo de carácter adaptable más que predictivo. Orientado a las personas más que a los procesos. Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones.

Scrum es adecuado para aquellas empresas en las que el desarrollo de los productos se realiza en entornos que se caracterizan por tener:

1. Incertidumbre : Sobre esta variable se plantea el objetivo que se quiere alcanzar sin proporcionar un plan detallado del producto.Esto genera un reto y da una autonomía que sirve para generar una “tensión” adecuada

para la motivación de los equipos.

2. Auto-organización : Los equipos son capaces de organizarse por sí solos, no necesitan roles para la gestión pero tienen que reunir las siguientes características:

Autonomía: Son los encargados de encontrar la solución usando la estrategia que encuentren adecuada.

Autosuperación: Las soluciones iniciales sufrirán mejoras.

Auto-enriquecimiento: Al ser equipos multidisciplinares se ven enriquecidos de forma mutua, aportando soluciones que puedan complementarse.

3. Control moderado : Se establecerá un control suficiente para evitar descontroles. Se basa en crear un escenario de “autocontrol entre iguales” para no impedir la creatividad y espontaneidad de los miembros del equipo.

4. Transmisión del conocimiento : Todo el mundo aprende de todo el mundo. Las personas pasan de unos proyectos a otros y así comparten sus conocimientos a lo largo de la organización.

Scrum al ser una metodología de desarrollo ágil tiene como base la idea de creación de ciclos breves para el desarrollo, que comúnmente se llaman iteraciones y que en Scrum se llamarán “Sprints”.

Para entender el ciclo de desarrollo de Scrum es necesario conocer las 5 fases que definen el ciclo de desarrollo ágil:

1. Concepto : Se define de forma general las características del producto y se asigna el equipo que se encargará de su desarrollo.

2. Especulación : en esta fase se hacen disposiciones con la información obtenida y se establecen los límites que marcarán el desarrollo del producto, tales como costes y agendas.Se construirá el producto a partir de las ideas principales y se comprueban las partes realizadas y su impacto en el entorno.Esta fase se repite en cada iteración y consiste, en rasgos generales, en:

Desarrollar y revisar los requisitos generales.

Mantener la lista de las funcionalidades que se esperan.

Plan de entrega. Se establecen las fechas de las versiones, hitos e iteraciones.Medirá el esfuerzo realizado en el proyecto.

3. Exploración : Se incrementa el producto en el que se añaden las funcionalidades de la fase

de especulación.

4. Revisión : El equipo revisa todo lo que se ha construido y se contrasta con el objetivo deseado.

5. Cierre : Se entregará en la fecha acordada una versión del producto deseado. Al tratarse de una versión, el cierre no indica que se ha finalizado el proyecto, sino que seguirá habiendo cambios, denominados “mantenimiento”, que hará que el producto final se acerque al producto final deseado.

Scrum gestiona estas iteraciones a través de reuniones diarias, uno de los elementos fundamentales de esta metodología.

Las reuniones:

Scrum se puede dividir de forma general en 3 fases, que podemos entender como reuniones. Las reuniones forman parte de los artefactos de esta metodología junto con los roles y los elementos que lo forman.

1. Planificación del Backlog

Se definirá un documento en el que se reflejarán los requisitos del sistema por prioridades.

En esta fase se definirá también la planificación del Sprint 0, en la que se decidirá cuáles van a ser los objetivos y el trabajo que hay que realizar para esa iteración.

Se obtendrá además en esta reunión un Sprint Backlog, que es la lista de tareas y que es el objetivo más importante del Sprint.

1. Seguimiento del Sprint

En esta fase se hacen reuniones diarias en las que las 3 preguntas principales para evaluar el avance de las tareas serán:

¿Qué trabajo se realizó desde la reunión anterior?

¿Qué trabajo se hará hasta una nueva reunión?

Inconvenientes que han surgido y qué hay que solucionar para poder continuar

2. Revisión del Sprint

Cuando se finaliza el Sprint se realizará una revisión del incremento que se ha generado. Se presentarán los resultados finales y una demo o versión, esto ayudará a mejorar el feedback con el cliente.

Elementos del Scrum:

Los elementos que forman a Scrum son:

Product Backlog: Es el inventario en el que se almacenan todas las funcionalidades o requisitos en forma de lista priorizada. Estos requisitos serán los que tendrá el producto o los que irá adquiriendo en sucesivas iteraciones.

Sprint Backlog: Es la lista de tareas que elabora el equipo durante la planificación de un Sprint. Se asignan las tareas a cada persona y el tiempo que queda para terminarlas.

Incremento: Representa los requisitos que se han completado en una iteración y que son perfectamente operativos. Según los resultados que se obtengan, el cliente puede ir haciendo los cambios necesarios y replanteando el proyecto.

Roles de Scrum:

1. Propietarios de Producto(Product Owner): Determina las prioridades, una sola persona

2. Scrum Manager: Gestiona y facilita la ejecución del proceso de Scrum

3. Equipo: Desarrolla el producto

4. Interesados:Asesoran y observan

“Año de la Promoción de la Industria Responsable y

del Compromiso Climático”

ESCUELA TECNOLOGIA DE LA UNIVERSIDAD NACIONAL DE PIURA

Curso: Ingeniería de Software

Profesor: Juan Carlos Morales Vasquez

Alumna: Villavicencio Ayala Nataly

Tema : Metodologías RUP, XP, RAD, SCRUM

Castilla-Piura

2014