Proceso unificado Proceso Unificado de Desarrollo de Software

 Proceso unificado

Proceso Unificado de Desarrollo de Software

La metodología de UP ([1], [4]) es un método iterativo de diseño de software que describe cómo desarrollar software de forma eficaz, utilizando técnicas probadas en la industria.

 El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura, enfocado en el riesgo, y por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. Es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos; los flujos y productos de trabajo de UP no incluyen la administración del proyecto. UP es una versiónlibre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh [1].

UP divide el trabajo de desarrollo de software en cuatro fases: inicio, elaboración, construcción y transición, las cuales se describen a continuación.

Fase de Inicio en UP

En esta fase corresponde definir el negocio. Es la etapa donde se define la factibilidad del proyecto a realizar, se representa el modelo de negocio, visión y metas del proyecto, se identifican actores, conceptos de dominio y deseos de usuario. Adicionalmente se complementa con la definición de la arquitectura preliminar, y estimaciones (imprecisas, preliminares) de plazos y costos. También se define la viabilidad del proyecto.

 Fase de Elaboración en UP

En la fase de elaboración se obtiene la visión refinada del proyecto a realizar, la implementación iterativa del núcleo central de la aplicación, la resolución de los riesgos más altos, la identificación de nuevos requisitos y nuevos alcances, y estimaciones más ajustadas. A esta altura existe la posibilidad de detener el proyecto por complejidad técnica.

Fase de Construcción en UP

La fase de construcción es la implementación iterativa del resto de los requisitos de menor riesgo y elementos más sencillos. Es la evolución hasta convertirse en un producto listo, incluyendo todos los requisitos (100%), para entregarse al Cliente. Al final de esta fase el sistema contiene todos los casos de uso que el cliente y la dirección del proyecto han acordado. La mayoría de los casos de uso que no se desarrollaron en la fase anterior se desarrollan en iteraciones, en grupos de requisitos o casos de uso durante esta fase.

 Fase de Transición en UP

Es el periodo donde el producto es completamente entregado al cliente para ser testeado y desplegado (instalado).

Organización de Disciplinas según UP

El cuadro siguiente representa cada una de las disciplinas utilizadas en el proceso de desarrollo de software y su nivel de participación en cada una de las fases definidas de UP [4].

Las disciplinas identificadas son modelado de: negocios, requisitos, análisis, diseño, implementación y pruebas, como también se identifican las disciplinas de apoyo, tales como: configuración y manejo de proyectos. Todas estas disciplinas son representadas con su correspondiente esfuerzo estimado para cada una de las fases definidas por UP.

Conceptos Claves en UP

Interactivo e Incremental

El desarrollo de software interactivo e incremental corresponde a mantener permanentemente un enfoque de cambio en los proyectos de desarrollo. Los llamados ciclos por fases intentan poner en manos del usuario un sistema con prestaciones parciales, que se va completando con nuevas prestaciones en fases sucesivas. Así, el usuario tiene en producción algunas funcionalidades mientras se van desarrollando las otras. Por lo tanto, existen entonces al menos dos sistemas funcionando en paralelo:

1) El sistema operacional o sistema en producción, en uso por el cliente. Puede ser una implementación parcial, una implementación anterior con funcionalidades nuevas o sustituidas, una implementación nueva con partes de la anterior u otra variante coherente.

2) El sistema en desarrollo (la siguiente versión) que está siendo preparada para reemplazar la versión en producción, que puede aún conservar partes de implementaciones anteriores o faltarle funcionalidades.

La representación de un proceso iterativo e incremental se realiza en la siguiente ilustración.

Representación Proceso Iterativo e Incremental

Por consiguiente, el proceso de desarrollo incremental genera versiones comenzando con un subsistema funcional pequeño, al cual se le va agregando funcionalidad con cada versión. Sin embargo, el desarrollo iterativo entrega un sistema completo desde el principio, y luego cambia la funcionalidad de algún subsistema en cada nueva versión. Ambos enfoques pueden combinarse en un desarrollo iterativo e incremental.

También se considera que el desarrollo iterativo es un método de construcción de productos cuyo ciclo de vida está compuesto por un conjunto de iteraciones, las cuales tienen como objetivo entregar versiones del software.

Cada iteración se considera un proyecto que genera productos de software y no sólo documentación, permitiendo al usuario tener puntos de verificación y control más rápidos e induciendo un proceso continuo de pruebas y de integración desde las primeras iteraciones.

Algunas características a enunciar según UP son:

1.    Los proyectos se organización en una serie de mini-proyectos cortos de duración (2 a 6 semanas), llamados iteraciones, que incluyen un conjunto reducido de requerimientos a implementar.

                                                         

2.    El resultado de cada iteración es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto con calidad de producción final.

3.    Rápida retroalimentación y asimilación de los cambios, posibilitada por el tamaño limitado de lo realizado en cada iteración.

4.    Se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alto riesgo.

¿Por qué UP es un buen Punto de Partida?

UP es un buen punto de partida por tratarse de una metodología de desarrollo de software orientada a conducir el proceso de desarrollo de forma eficaz basado en un conjunto de buenas prácticas probadas en la industria del software y muchas de las cuales son conocidas dentro de FIDCOM, disminuyendo el costo de adopción. UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh [1]. En otras palabras, es perfectamente posible definir el proceso de ingeniería de una organización sobre la base del UP, sin tener que pagar derechos.

 ¿Por qué No usar UP tal cual?

Por tratarse de un meta modelo, un proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes, por tratarse de un marco de trabajo extensible de metodología de desarrollo de software que debe ser adaptado a organizaciones o proyectos específicos no es apropiado utilizar UP tal cual.

 UP es una metodología orientada a conducir el proceso de desarrollo de software en sus aspectos técnicos. Los flujos y productos de trabajo de UP no incluyen la administración del proyecto. Por lo tanto, se requiere también que los proyectos se encuentren en un dominio acotado y se requiere flexibilidad, la cual se obtiene con el tiempo.

Algunas prácticas y consideraciones en el proceso de desarrollo de software para soluciones de punto de venta son:

1.    Se genera sólo un entregable a la tienda piloto (similar al planteamiento desarrollo en “cascad”).

No aplica el entregar por porciones al usuario final (según planteamiento UP), dado que una vez que se libera el software a la tienda piloto, recién en ese momento es utilizado por los usuarios reales. Sin embargo, se generan entregables parciales (iteraciones de porciones de software) a las áreas de sistemas para efectos de certificar las funcionalidades en ambientes de laboratorio (simulaciones).

2. Las implantaciones de software y servicios se realizan en locales, almacenes o tiendas que atienden a público general. Esto limita los horarios de trabajo y el usuario final es un cajero y/o cliente.

3. Los periodos de seguimiento de una tienda piloto son cortos (1 a 2 semanas). Esto dificulta las posibilidades de identificar hallazgos.

4. La implantación en todas las tiendas son amplios y riesgosos. Todos los accesos son remotos y las coberturas regionales.

5. El "time to market" es crítico, generalmente, es un esfuerzo grande el implantar las tiendas, dado que se requiere de procesos de certificaciones internas y externas; capacitaciones de cajeros, operadores, administrativos, entre otros.