Essential Unified Process
| ||||||||||||
Essential Unified Process. Creado por Ivar Jacobson, como una mejora sobre el Rational Unified Process(RUP) y mucho mas "liviana" que Microsoft Solution Framework (MSF). Esta basada en MSF y será incluida como parte del Team System. Consiste en la integración de prácticas eficaces entre los tres principales campos de procesos: el proceso unificado, los métodos ágiles y el proceso de madurez. Cada uno de estos procesos contribuye con diferentes capacidades o características como son: la estructura, la agilidad y la mejora de procesos.
Sumario
Definición
EssUP esta basado en casos de uso, CMMI y desarrollo ágil. Se considera una mejora sobre RUP ya que en este último todas las prácticas están relacionadas y no pueden ser usadas de forma aislada. EssUP está soportado por Microsoft Visual Studio Team System, y Eclipse.
El proceso esencial Unificado (EssUP) es un conjunto de prácticas que en conjunto forman el conocimiento esencial de un ciclo de vida de desarrollo de software. Las prácticas integran principios que se han mostrado efectivos en los campos del proceso unificado, del desarrollo ágil y la madurez de los procesos, haciendo énfasis en las capacidades que ofrecen: estructura, agilidad y mejora de procesos.
Características
Ess UP identifica prácticas como desarrollo en base a casos de uso, desarrollo iterativo, architecture driven development, practicas para el equipo y practicas para los procesos, que son tomados de RUP, CMMI, y desarrollo ágil.
La metodología denomina Essential Practicess al conjunto de prácticas, las cuales esta divididas en 6 prácticas técnicas y 4 prácticas transversales.
Creador
Ivar Hjalmar Jacobson 2 de septiembre de 1939, ingeniero sueco en Ciencias de la computación. Inventó el diagrama de secuencia y desarrolló los diagramas de colaboración. También impuso el uso de diagramas de estado de transición para describir los flujos de mensajes entre los componentes. Fue uno de los desarrolladores originales del SDL (lenguaje de especificación), que se convirtió en estándar en 1967.
En noviembre de 2005, Jacobson anunció la Essential Unified Process (EssUP), una nueva "práctica" centrada en el proceso de desarrollo de software. Se trata de un nuevo comienzo a la integración de prácticas eficaces de entre los tres principales campos de proceso: el proceso unificado, los métodos ágiles y el proceso de madurez. Cada uno de ellos contribuye diferentes capacidades: estructura, la agilidad y la mejora de procesos.
Jacobson ha descrito a EssUP como un "súper ligeros y ágiles". RUP y la IJC han integrado EssUP en Microsoft Visual Studio Team System, y Eclipse.
Prácticas Técnicas
Architecture Essentials
Esta práctica está destinada a obtener una base firme para el desarrollo de sistemas de alta calidad y robustos. Permite a los equipos:
- Identificar de forma efectiva los riesgos técnicos del proyecto.
- Consensuar las decisiones principales sobre la estructura y organización del sistema implementado.
- Verificar que el sistema integra las características clave esperadas por el cliente.
- Probar de forma objetiva que el sistema elegido es adecuado a su propósito.
Qué produce
- Documentación acerca de la arquitectura.
- Casos de prueba sobre la arquitectura.
- Vistas de la arquitectura.
- Verificación de la arquitectura de forma incremental. Se testea cada vez que se produce una nueva versión del sistema.
Qué hay que hacer
- Identificar y clarificar los requisitos relevantes para la arquitectura para establecer los objetivos de la misma.
- Determinar la arquitectura a implementar y especificar el conjunto de pruebas que se usarán para verificar y probar la implementación.
- Producir un sistema básico verificado y probado para cumplir los requisitos.
- Entrenar al equipo para usarlo.
A partir de aquí la arquitectura evoluciona en función de nuevos requisitos y resultados de las pruebas. Todos los sistemas construidos están sujetos al cumplimiento de los test para asegurar la validez de la implementación de la arquitectura.
Iterative Essentials
Esta práctica reduce el riesgo del proyecto mediante el desarrollo incremental del sistema sobre un número de iteraciones. El proyecto se descompone en trozos más pequeños o mini proyectos, independientes y limitados en el tiempo. Esta práctica permite al equipo:
- Planear de forma colaborativa y objetiva, ejecutar y seguir el proyecto.
- Una gestión del tiempo más eficaz y de más calidad.
- Demostrar la importancia de trabajar desde un primer momento en el software contando con los feedbacks de clientes y usuarios.
- Ser ágiles en respuesta a los cambios.
- Entregar más alta calidad, soluciones más apropiadas, más frecuentemente.
- Tener un sistema operacional disponible desde bien pronto en el proyecto, que incrementalmente crezca para convertirse finalmente en un sistema completo.
Qué produce
Esta práctica implica la producción de un conjunto de elementos relacionados con la administración:
- El backlog (trabajo atrasado) se llena de cambios, cosas que no funcionan correctamente o fallos, y otras tareas que representan el trabajo por ser realizado.
- El plan de proyecto identifica el número y tipo de las iteraciones que serán llevadas a cabo.
- La planificación y las iteraciones son necesarias por los riesgos que implica el proyecto.
- La iteración de los planes y los ajustes son necesarias para conocer el propósito y el resultado de cada iteración.
Qué hay que hacer
- La práctica comienza adaptando los planes del proyecto existentes para integrar las iteraciones al ámbito del proyecto.
- Los objetivos, criterios de evaluación y trabajo para la primera iteración son aceptados.
- La práctica guía entonces al equipo a través de la iteración dónde tienen que aplicar otras prácticas para conseguir los objetivos de la iteración.
- Al final del periodo establecido para la iteración sus resultados serán evaluados y utilizados para ayudar a adaptar los planes a la realidad del proyecto y establecer la siguiente iteración.
- Esta secuencia se sigue para cada iteración de trabajo del proyecto hasta que, tras los resultados de la iteración final sean evaluados y el proyecto concluya.
Use-Case Essentials
Una forma ágil, sencilla de controlar y de seguir el desarrollo del proyecto software. Esta práctica permite al equipo:
- Trabajar con los clientes para capturar los requerimientos verdaderamente esenciales.
- Trabajar juntos más eficientemente para desarrollar rápidamente una solución utilizable.
- Identificar y entregar el valor esperados del sistema.
- Establecer el nivel correcto de detalle de los requisitos para satisfacer las necesidades y la de los clientes.
- Priorizar e identificar subconjuntos de requisitos de una solución mínima para usarla en el desarrollo iterativo.
- Utilizar un acercamiento sistemático al correcto diseño, implementación y verificación de requisitos.
Qué produce
Esta práctica implica la producción de un conjunto de requisitos, así como el diseño y prueba de elementos:
- Un caso de uso basado en la especificación de los requisitos, escenarios y casos de prueba.
- La realización del caso de uso conduce al desarrollo del software.
- La generación de pruebas y los resultados de las pruebas sirven para probar el sistema y grabar los resultados de las pruebas.
Qué hay que hacer
- La práctica comienza identificando los actores y los casos de uso, y eligiendo y priorizando los casos de uso a ser desarrollados.
- Sigue especificando los casos de uso y sus pruebas, e implementando el software que hallará las pruebas.
- Finaliza ejecutando las pruebas y siguiendo el progreso en términos de verificado.
Component Essentials
Esta práctica se utiliza para desarrollar complejos sistemas formados de componentes más pequeños y más simples. Esta práctica permite al equipo:
- Gestionar la complejidad asociada con el desarrollo del sistema software.
- Desarrollar complejos sistemas de una forma extensible y mantenible.
- Desarrollar y verificar las partes separadas de un sistema independientemente y en paralelo.
- Identificar oportunidades para la reutilización y aprovechamiento de componentes reutilizables.
- Utilizar la tercera parte de los frameworks y los componentes de biblioteca.
Qué produce
Esta práctica implica la producción de un número de implementaciones y elementos de prueba:
- Un diseño modelado del sistema a implementar, identificando el conjunto de componentes requeridos.
- Una descripción de cada componente, incluyendo su comportamiento e interfaces.
- Código fuente y unidades de prueba para componente.
- Construcciones integradas del sistema del componente y las pruebas y los resultados para verificar las construcciones.
Qué hay que hacer
- La práctica comienza identificando el conjunto de componentes que son necesarios para hallar los requisitos del sistema, y plasmar esta práctica en la especificación del sistema. Esto incluye identificar un adecuado conjunto de pruebas para verificar el sistema.
- Se sigue definiendo los componentes, incluyendo sus interfaces y unidades de prueba, y desarrollando los componentes para implementar las interfaces y pasar estas pruebas.
- Finalizamos integrando el sistema, ejecutando las pruebas para verificar el sistema producido y entonces fomentando la utilización tal y cómo los componentes han sido concebidos.
Product Essentials
Administrando versiones del producto Esta práctica se utiliza para administrar el desarrollo de sucesivas evoluciones de un sistema software como una serie de versiones del producto. Esta práctica permite al equipo:
- Planear el proyecto como una serie de versiones de un producto superior estando cada entrega real en pos del beneficio empresarial.
- Involucrar a los stakeholders en la decisión de fabricación del proceso.
- Asegurar que el producto realizado cubrirá las necesidades reales de los stakeholders.
- Gestionar la evolución del software de forma controlada y enfocada al negocio.
Qué produce
Esta práctica implica la producción de un conjunto de elementos de negocio, de planeamientos y de requisitos:
- El caso de negocio para establecer el valor del producto.
- El análisis de los stakeholders para asegurar que ellos comprenden y están involucrados en el proyecto.
- La lista de capacidades, glosario y descripción de cada versión para definir el producto y sus versiones.
- El plan de proyecto para extraer cómo las series de versiones serán producidas.
Qué hay que hacer
- Esta práctica comienza iniciando el proyecto y estableciendo el caso de negocio de producto.
- Continúa especificando y planificando las versiones del producto
- Concluye con el empaquetado de la versión y su aceptación por parte del cliente.
Bussiness Use Case Essentials
Caso de uso de negocio: gestionando tus requisitos de negocio. Podremos captar y redefinir tal y como requieren tus procesos de negocio para que se llegue a una solución software más eficaz y que mejore las prestaciones y el valor que te aportará. Con la práctica de caso de uso de negocio esencial, tu equipo se enriquecerá al comprender las necesidades del negocio, y cómo involucrar al negocio para lograr cubrir las necesidades de la organización.
Qué produce
El caso de uso de negocio esencial te permitirá:
- Adaptar una solución tecnológica a los requisitos con las necesidades del negocio.
- Maximizar los beneficios generados por la introducción de soluciones automatizadas.
- Comprender el impacto de las soluciones propuestas al negocio.
- Incrementar el beneficio realizado por el software a partir del desarrollo de proyectos software.
Prácticas Transversales
Unified Process Lifecycle Essentials
Esta práctica se utiliza para establecer un control sobre el ciclo de vida de un proyecto de desarrollo iterativo y permite a los equipos:
- Establecer un ciclo de vida del proyecto.
- Compartir un conjunto de hitos (milestones) comunes con otros proyectos y equipos.
- Identificar los objetivos a corto plazo para reducir los niveles de riesgo que se presentan.
- Estructurar los planes en una secuencia de fases bien comprendidas.
- Aprovechar al máximo los beneficios del desarrollo iterativo.
Patrones de ciclo de vida Está práctica presenta un conjunto de "Patrones de ciclo de vida" que al ser aplicados en el proyecto permiten al equipo:
- Entender en que estado está el proyecto y como de correcta se está llevando a cabo la gestión de los riesgos.
- Adoptar un marco de control estándar para guiarlos en el establecimiento apropiado de objetivos y de hitos.
- Iterar de una manera controlada.
- Observar la evolución de la arquitectura y los requisitos junto con el desarrollo de una solución de software de alta calidad.
The Common Milestones
Este patrón define un conjunto de hitos o puntos de paso, apropiado para la planificación y el seguimiento de todas las variantes de desarrollo iterativo e incremental de los proyectos software. Los tres principales hitos se muestran a continuación:
- Objetivos del Ciclo de Vida (Lifecycle Objectives) - Se toman las decisiones clave sobre lo que será y no será en el producto/versión. Los requisitos operativos del software son acordados.
- Arquitectura del ciclo de vida (Lifecycle Architecture) - Se establece la arquitectura del software y se establece el plan para los riesgos principales asociados.
- Capacidad operativa inicial (Initial Operational Capability) - El software es totalmente funcional y se realizan los preparativos para la transición del software al cliente y/o el entorno de producción.
The Lifecycle Phases
Esta práctica perfecciona el patrón Common Milestones mediante la definición de cuatro fases para el adecuado progreso del proyecto hacia el éxito a través de los tres milestones anteriores. El proyecto o ciclo de lanzamiento del producto/versión se divide en cuatro fases secuenciales, cada una de las cuales tiene objetivos bien definidos:
- Inicio (Inception) - Confirmación del alcance y objetivos y control de los riesgos asociados al negocio.
- Elaboración (Elaboration) - Concreción de los planes y control de los riesgos arquitectónicos y técnicos.
- Construcción (Construction) - Construcción del producto y control de los riesgos asociados a la ejecución del proyecto.
- Transición (Transition) - Entrega del producto y control de los riesgos de despliegue.
Estas cuatro fases son tomadas de RUP por lo que en dicha metodología se puede encontrar información ampliada y actividades concretas a realizar en cada fase.
Team Essentials
Esta práctica es utilizada para reunir un equipo de proyecto y establecer un ambiente de trabajo efectivo. Para ello el equipo debe:
- Adoptar las medidas de liderazgo y de organización.
- Establecer y adquirir las competencias necesarias para tener éxito.
- Desarrollar formas efectivas de colaborar y organizar su trabajo.
- Crear una ambiente en el que todos los miembros del equipo sean capaces de contribuir al máximo de su capacidad durante todo el proyecto.
Qué produce
El objetivo es la creación de trabajo en equipo eficaz y la producción de elementos relacionados:
- En la carta del equipo se refleja la estructura del equipo y las responsabilidades.
- Los miembros integrados en el equipo deben evolucionar hacia maneras efectivas de colaborar.
Qué hay que hacer
- La práctica comienza con la formación del equipo inicial del proyecto como parte de la puesta en marcha del mismo.
- A lo largo del desarrollo, los planes de proyecto se adaptan para reflejar la dotación de personal y la eficacia del equipo, el equipo del proyecto está orientado a mejorar el trabajo del equipo y eliminar los obstáculos que impiden que el trabajo efectivo del equipo.
Process Essentials
Está práctica permite mejorar y adaptar la forma de trabajo del equipo, en concreto, permite al equipo:
- Identificar, preparar y reunir un conjunto de prácticas y herramientas adecuadas para conseguir los objetivos del proyecto.
- Introducir nuevas prácticas individual y gradualmente según sea necesario.
- Comparar e integrar prácticas estándar y particulares preservando los aspectos que el equipo ejecuta correctamente y señalando aquellos que no.
- Evolucionar las prácticas en base a la experiencia y las lecciones aprendidas.
Qué produce
El objetivo es el establecimiento de una forma efectiva de trabajo y la producción de una serie de prácticas y herramientas:
- La forma de trabajar está compuesta de un número de prácticas. Cada práctica debe describirse en formato de cartas y guidelines.
- La forma de trabajar está soportada por un número de herramientas. Cada herramienta puede suministrar una descripción referente a la configuración así como realizar ciertas actividades definidas por las prácticas.
- La forma de trabajar se resume en el documento de aproximación.
Qué hay que hacer
- La práctica comienza estableciendo y lanzando un conjunto inicial de prácticas y herramientas como parte del lanzamiento del proyecto.
- Las mejoras fundamentalmente provienen de peticiones de cambio o por la adopción de nuevas prácticas y herramientas. El equipo es entrenado al inicio y vuelve a serlo con las nuevas prácticas y las mejoras. El resultado del uso de estás prácticas debe ser evaluado, uno de los indicadores son las peticiones de cambio.
- El ciclo de mejora, entrenamiento y evaluación posibilita una mejora continua de los procesos. Se pueden añadir tantas prácticas y herramientas como sean necesarias para hacer frente a los riesgos del proyecto. Aquellas prácticas que demuestren ser no efectivas pueden ser mejoradas o eliminadas.
Modeling Essentials
Esta práctica se utiliza para establecer un estilo y tipo apropiados para guiar las actividades de desarrollo. Con los modelos podremos:
- Comunicar los requisitos, estructura y comportamiento del sistema.
- Ver diferentes perspectivas del sistema y entender cómo se relacionan entre sí.
- Emplear los modelos adecuados que mejor se adaptan a cada necesidad.
- Ser ágil en la forma de abordar el modelado y documentación.
- Concentrarse en lo esencial para evitar la producción de documentación innecesaria.
Qué produce
La clave para un modelado efectivo es establecer un conjunto ligero de Guías de Modelado detallando como los modelos se relacionan y como deberían ser usados. Estas guías influirán y tendrán en cuenta los distintos modelos introducidos en el proyecto por otras prácticas.
Qué hay que hacer
El soporte al equipo en las actividades de modelado se inicia cuando se establece el proyecto y debe permanecer durante todo el desarrollo del mismo. El equipo recibe entrenamiento en la aplicación de los modelos y estándares seleccionados. Los resultados del trabajo de modelado se evalúan y las formas de trabajar con modelos son mejoradas continuamente.
