Essential Unified Process (EssUP)

1. INTRODUCCION

Essential Unified Process. Creado por Ivar Jacobson, como una

mejora sobre el Rational Unified Process(RUP) y mucho más
"liviana" que Microsoft Solution Framework (MSF). Está 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.

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.
2. DEFINICIÓN

EssUP está 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.

3. CARACTERÍSTICAS

Ess UP 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 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.
3.1. PRÁCTICAS TÉCNICAS

3.1.1. ARCHITECTURE ESSENTIALS (ARQUITECTURA)

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.

3.1.2. ITERATIVE ESSENTIALS (ITERATIVO)

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.

3.1.3. USE-CASE ESSENTIALS (CASO DE USO)

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.

3.1.4. COMPONENT ESSENTIALS (COMPONENTE)

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.

3.1.5. PRODUCT ESSENTIALS (PRODUCTO)

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.

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

3.2. PRÁCTICAS TRANSVERSALES

3.2.1. UNIFIED PROCESS LIFECYCLE ESSENTIALS (PROCESO)

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.

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

3.2.1.2. THE LIFECYCLE PHASES (FASES DE CICLO DE VIDA)

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.

3.2.2. TEAM ESSENTIALS (EQUIPO ÁGIL)

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

3.2.3. PROCESS ESSENTIALS (PROCESO)

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.

3.2.4. MODELING ESSENTIALS (MODELADO)

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.

4. ESSUP VS RUP

Lo bueno de EssUp es que no tienes que usar todas las

prácticas. Puede comenzar fácilmente con uno y agregar más si
lo desea. Con RUP, utiliza todo el proceso, incluso si no
necesita crear todos los artefactos. EssUp difiere en la
presentación ligera de las prácticas y la extensibilidad.