Essential unified process

De WikiCE


Essential unified process
Autores Miguel A. Vera Márquez
Antonio Balderas Alberico

Contenido

Introducción

Essential Unified Process for software development (noviembre, 2005), o EssUP, fue creado por Ivar Jacobson como una mejora sobre Rational Unified Process (RUP). EssUP consiste en 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 con capacidades o características: estructura, la agilidad y la mejora de procesos.

EssUP identifica prácticas, como desarrollo en base a casos de uso, desarrollo iterativo, architecture driven development, prácticas para el equipo y prácticas para los procesos, que son tomados de RUP, CMMI y desarrollo ágil. La idea es usar aquellas prácticas que sean aplicables a la situación concreta e integrarlas con los procesos existentes. EssUP 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.

Para su aplicación EssUP se ayuda de una "baraja" de cartas donde cada una de ellas describe una práctica. Este formato fue elegido por el creador ya que piensa que la gente compra sus libros pero no los lee.

EssUP está soportado por Microsoft Visual Studio Team System, y Eclipse.

Essential Unified Process for software development

EssUP es una colección de prácticas que permite abordar por completo el ciclo de vida de desarrollo 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.

La metodología denomina Essential Practices al conjunto de prácticas y están divididas en 4 prácticas transversales y 6 prácticas técnicas:

  • Prácticas tranversales
    • Process Essentials: Asegura una mejora continua de los procesos y ayuda a adoptar y afianzar las nuevas formas de trabajar.
    • Team Essentials: Enfocada a conseguir un equipo de trabajo colaborativo más efectivo.
    • Modeling Essentials: Modelado ágil adoptando un apropiado nivel de detalle, aumento de la comunicación y reducción de los riesgos del proyecto.
    • Unified Process Lifecycle Essentials: Ofrece un conjunto de fases e hitos que ayudan a planificar y monitorizar proyectos iterativos.
  • Prácticas técnicas:
    • Architecture Essentials: Basado en architecture driven development permite asegurar que la arquitectura elegida para el proyecto es adecuada a su propósito.
    • Iterative Essentials: Adopción de un desarrollo iterativo mediante timeboxing para administrar y monitorizar el proyecto y sus riesgos.
    • Use-Case Essentials: Usados para la captura de requisitos y conducir el desarrollo y testing de la solución.
    • Component Essentials: Desarrollo del software de forma simple, escalable y aplicando test-driven.
    • Product Essentials: Ayuda en el ámbito de la administración del producto software de manera que derive en una relación más estrecha con el cliente y nos ayuda a identificar las versiones principales del producto.
    • Bussiness Use Case Essentials: Destinado a que el equipo fortalezca su conocimiento acerca de las necesidades de negocio relacionado con el proyecto y su evolución hacia las necesidades subyacentes de la organización.

Se pueden adoptar todas las prácticas o simplemente usar las que se necesiten o incluso partes de ella así como adaptarlas a la organización o extenderlas para establecer una metodología adaptada.

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:

Common Milestones

El patrón aplica estos tres hitos para cada ciclo de lanzamiento de productos/versiones de la siguiente manera:

  • 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.

Lyfecycle Phases

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
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
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
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
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
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
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.

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. Esta práctica permite a los equipos:

  • Identificar de forma efectiva los riesgos técnicos del proyecto.
  • Consensuar la 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
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
Qué hay que hacer
  1. Identificar y clarificar los requisitos relevantes para la arquitectura para establecer los objetivos de la misma.
  2. Determinar la arquitectura a implementar y especificar el conjunto de pruebas que se usarán para verificar y probar la implementación.
  3. Producir un sistema básico verificado y probado para cumplir los requisitos.
  4. Entrenar al equipo para usarlo.
  5. A partir de aquí la arquitectura evoluciona en función de nuevos reuisitos y resultados de las pruebas. Todos los sistemas construidos están sujetos al cumplimientos 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 miniproyectos, 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
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
Qué hay que hacer
  1. La práctica comienza adaptando los planes del proyecto existentes para integrar las iteraciones al ámbito del proyecto.
  2. Los objetivos, criterios de evaluación y trabajo para la primera iteración son aceptados.
  3. 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.
  4. 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.
  5. 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 nuestras 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
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
Qué hay que hacer
  1. La práctica comienza identificando los actores y los casos de uso, y eligiendo y priorizando los casos de uso a ser desarrollados.
  2. Sigue especificando los casos de uso y sus pruebas, e implementando el software que hallará las pruebas.
  3. 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:

Qué produce
  • 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
Qué hay que hacer
  1. 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.
  2. Se sigue definiendo los componentes, incluyendo sus interfaces y unidades de prueba, y desarrollando los componentes para implementar las interfaces y pasar estas pruebas.
  3. 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
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
Qué hay que hacer
  1. Esta práctica comienza iniciando el proyecto y estableciendo el caso de negocio de producto.
  2. Continua especificando y planificando las versiones del producto
  3. 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 nuestra 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.




Enlaces

Herramientas personales