Todos los esfuerzos están vinculados por un universo elegante que llamamos realidad en donde las dos dimensiones de tiempo y espacio establecen el panorama para la danza entre las dos fuerzas naturales del cambio y la complejidad. Es en este ámbito en el que convergen los ingredientes claves que son las personas, las mejores prácticas de contextuales y automatización como puente para el abismo entre la visión y la realidad. Sin embargo, a lo largo de nuestros esfuerzos a través de dominios (y con independencia de cualquier dominio particular), cambian más y la complejidad que uno intenta abordar es mas cambiante y la complejidad en si misma se torna como un círculo vicioso, plagado de riesgos y oportunidades.
Dentro de los negocios, la industria de sistemas y tecnología de la información, hay diversos medios para hacer frente a estas fuerzas y, en última instancia, aprovechar oportunidades, incluyendo el proceso unificado (UP) y enfoques ágiles. Este documento se centra en la definición de agilidad en el análisis de procesos, explorando la definición relativa a la UP y enfoques ágiles y describir el Agile Unified Process (AUP).
1.- El Proceso Unificado (UP) y Proceso Unificado Relacional (RUP):
El Proceso Unificado (UP) es un producto de software marco de ingeniería de procesos (un caso de uso impulsada por la arquitectura centrada en el riesgo, iterativo e incremental, en paralelo, la lucha, orientado a objetos, y el componente de enfoque). También es conocido como el Proceso Unificado de Desarrollo de Software (USDP). Ha sido desarrollado por Grady Booch, James Rumbaugh, e Ivar Jacobson (los Tres Amigos). La UP ofrece una infraestructura para la ejecución de proyectos de software de ingeniería de productos, un marco integrado de los hitos principales y secundarias y de disciplinas.
El Rational Unified Process (RUP) es un producto de proceso desarrollado y comercializado por IBM Rational Software. El RUP proporciona los detalles necesarios para la ejecución de proyectos de uso de la UP, incluyendo directrices, plantillas y asistencia de la herramienta.
La UP surgió como la unificación de Rational Rational Software Corporation enfoque y el proceso de Objectory AB, cuando Rational Software Corporation adquirió Objectory AB en 1995. El Rational Software Corporation, desarrolló el enfoque racional como resultado de diversas experiencias de los clientes. Ivar Jacobson creó el proceso de Objectory principalmente como resultado de su experiencia con Ericsson en Suecia. Rational Software Corporation fue adquirida por IBM a finales de 2002.
2.- El Proceso Unificado Ágil (AUP):
La UP es un software producto ingeniería marco de proceso que puede abordarse mediante tres perspectivas, incluyendo colaboraciones, contexto y las interacciones que se centran en un ciclo de vida de compuesto por fases, disciplinas y iteraciones.
En la siguiente figura se muestra una vista conceptual de los elementos esenciales que constituyen la UP y AUP.
Figura: AUP vs RUP
Una colaboración implica una interacción dentro de un contexto. En la UP, una colaboración captura quién hace qué actividades (cómo) sobre lo que funcionan los productos. Por lo tanto, establece los elementos de un proyecto. Colaboraciones implican a trabajadores (funciones), actividades y productos (artefactos) de trabajo. En el AUP, colaboraciones se centrarán en colaboradores (colaboradores y confirmantes), metas y objetivos y resultados. Un contexto se hace hincapié en el aspecto estructural o estático de una colaboración, los elementos que colaboran y su conglomerado o las relaciones espaciales. En la UP, un contexto captura cuando y donde estas actividades deben ser hechas, trabajo, productos (artefactos) producidos y consumidos. Por lo tanto, establece el marco para un proyecto. Contextos implican ciclos de desarrollo y fases, iteraciones y disciplinas. Las fases de la UP incluyen principio, diseño, construcción y transición. Disciplinas de la UP incluyen Business Modeling, requisitos, análisis y diseño, prueba, implementación, configuración y administración de cambios, gestión de proyectos y medio ambiente. En el AUP, contextos centrarán en objetivos.
Una interacción enfatiza el aspecto de comportamiento o dinámica de una colaboración, los elementos que colaboran y en su cooperación o la comunicación temporal. En la UP, una interacción captura cuándo y por qué esas actividades se debe hacer y los productos de trabajo (artefactos) producidos y consumidos. Así, establece la ejecución de un proyecto. Interacciones implican requisitos o casos de uso, un sistema y su arquitectura, iteraciones, y el riesgo. En el AUP, las interacciones se centran en los objetivos.
Figura: AUP
El AUP define metas y objetivos donde las colaboraciones se utilizan para lograr resultados. Una colaboración puede ser el trabajo realizado por una persona que puede interactuar con otros usuarios. Una colaboración puede ser un taller en el que participaron varios individuos que interactúan entre sí y pueden interactuar con otros fuera del taller. Objetivos son similares a UP fases en las que se utilizan como puertas que implican las partes interesadas y los usuarios. Objetivos son similares a UP iteraciones en caja el tiempo que implican a los usuarios y dar como resultado un producto de la versión.
El objetivo de iniciar (Concepción) es establecer el producto visión, plan de proyecto, negocios y justificación tecnológica e identificar los riesgos y las oportunidades. Puede haber uno o más objetivos que deben lograrse en alcanzar este objetivo.
- Las partes interesadas se centran en el problema, solución y restricciones (equipo de trabajo visionario).
- Los usuarios se centrarán en sus necesidades y las características de los productos de alto nivel (análisis de requerimientos por parte del equipo de trabajo).
- Las partes interesadas y los usuarios se centrarán en el establecimiento de la justificación del negocio para el producto y el proyecto.
- Los usuarios y el equipo de desarrollo de software se centrarán en el establecimiento de la justificación de tecnología para el producto y el proyecto.
- El equipo (equipo de desarrollo de software, las partes interesadas y los usuarios) se centran en dar prioridad a los riesgos y las oportunidades (labor de planificación por parte del equipo de trabajo).
- El equipo se centra sobre las características de los productos Execute (innovación) metas y objetivos en el plan de trabajo del proyecto (labor de planificación por parte del equipo de trabajo).
- El equipo establece la infraestructura de desarrollo.
- Estrategias (Definir).
- El equipo considera posibles cambios en el producto y el proyecto y sus ramificaciones, decide aceptar o rechazar los posibles cambios y incorpora los cambios aceptados en el producto y el proyecto (equipo de trabajo y los cambios - consideraciones).
- Las partes interesadas y los usuarios se centran en evolucionar la visión (equipo de trabajo visión y requisitos).
- El equipo se centra en la evolución de los negocios y la justificación de la tecnología para el producto y el proyecto.
- El equipo se centra en la evolución de los riesgos y oportunidades y plan de proyecto (labor de planificación del equipo de trabajo).
- El equipo se centra en la adopción de un pulso del producto y el proyecto en metas y objetivos (talleres de pulso).
- Ejecutar (arquitectos, desarrollar (implementación y pruebas), implementar).
- El equipo se centra en aprovechar oportunidades mientras que enfrentan riesgos en diseñar, desarrollar (aplicación y pruebas) y desplegar (integración, creación y liberación) el producto (talleres de desarrollo de productos).
- El equipo aborda cuestiones (talleres de resolución de problemas El equipo aborda cuestiones (talleres de resolución de problemas).
- El equipo identifica posibles cambios en el producto y el proyecto.
El objetivo de ejecutar (innovación) es evolucionar el visión de producto, plan de proyecto y justificación de negocio y tecnología; identificar y hacer frente a riesgos; identificar y aprovechar oportunidades mientras diseñar, desarrollar (aplicación y pruebas) y desplegar (integración, construcción y libertad) el producto. Normalmente hay muchos objetivos y metas, cada una resultante de la implementación del producto.
El objetivo de cerrar (dejar) es retirar el producto y cerrar el proyecto (talleres de cierre). Puede haber uno o mas objetivos que debe lograrse en alcanzar este objetivo.
La visión provee dirección y un enfoque general, esta guía provee dirección específica a través de las metas y las misiones a través de los objetivos, y las colaboraciones establecen intuición, confianza, unidad, y cohesión.
3.- Justificación del Uso del Proceso Unificado Ágil como Modelo de Desarrollo:Un modelo de ciclo de vida de software es una vista de las actividades que se llevan a cabo durante el desarrollo de éste, e intenta determinar el orden de las etapas involucradas y proporcionar unos criterios para avanzar de unas a otras. Por tanto, definir un ciclo de vida permite llevar un mayor control sobre las tareas, evitando que estas se vayan eligiendo y realizando de manera desordenada, según parezca que van surgiendo necesidades, que podrían ser puntuales y fácilmente evitables.
A.- Uso del Proceso Unificado de Desarrollo
Debido al carácter relativamente investigador de este proyecto, y a la necesidad de modificar los requisitos que surgirían según se fueran evaluando y probando las distintas posibilidades con las que se cuenta para desarrollarlo, un modelo pesado no se ajusta de manera adecuada.
Sin embargo, un modelo puramente ágil necesita de un equipo de desarrollo con experiencia para ser llevado a cabo de manera satisfactoria, por lo que éste tampoco es el caso más adecuado para su aplicación. Es por ello que se ha optado por un modelo que combina características de ambas orientaciones, proporcionando un enfoque iterativo e incremental: el Proceso Unificado de Desarrollo propuesto por Rumbaugh, Booch y Jacobson.
B.- Características del Proceso Unificado de Desarrollo
Al igual que con cualquier otro modelo de desarrollo, del Proceso Unificado también se pueden destacar ciertas características.
B.1.- Iterativo e incremental:
El Proceso Unificado es un marco de desarrollo compuesto de cuatro fases:
o Inicio
o Elaboración
o Construcción
o Transición
Cada una de ellas es, a su vez, dividida en una serie de iteraciones que ofrecen como resultado un incremento del producto desarrollado, que añade o mejora las funcionalidades del sistema en desarrollo. Es decir, un “incremento” no implica necesariamente una ampliación de dicho sistema.
Durante cada una de estas iteraciones se realizarán a su vez las actividades definidas en el ciclo de vida clásico: requisitos, análisis, diseño, implementación, prueba e implantación. Aunque todas las iteraciones suelen incluir trabajo en casi todas estas actividades, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Por ejemplo, en la fase de inicio se centrarán más en la definición de requisitos y en el análisis, y durante la de construcción quedarán relegadas en favor de la implementación y las pruebas.
Si una iteración cumple sus metas, publicando una nueva versión del producto que implemente ciertos casos de uso, el desarrollo continúa con la siguiente. Cuando no las cumple, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.
B.2.- Dirigido por los casos de uso:
Un sistema software se crea para servir a sus usuarios por lo que, para construir un sistema exitoso, se debe conocer qué es lo que quieren y necesitan. El término “usuario” no se refiere solamente a los usuarios humanos sino también a otros sistemas, es decir, representa a algo o alguien que interactúa con el sistema a desarrollar.
En el Proceso Unificado, los casos de uso se utilizan para capturar los requisitos funcionales y para definir los objetivos de las iteraciones. En cada una, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso.
B.3.- Centrado en la arquitectura:
El concepto de arquitectura del software involucra los aspectos estáticos y dinámicos más significativos del sistema, y actúa como vista del diseño, dando una perspectiva completa y describiendo los elementos más importantes. La arquitectura surge de los propios casos de uso, sin embargo, también está influenciada por muchos otros factores, como la plataforma en la que se ejecutará, el uso de estándares, la existencia de sistemas heredados (aunque éste no sea el caso que nos ocupa) o los requisitos no funcionales.
Puesto que la arquitectura y los casos de uso están relacionados, por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura, y ésta debe ser lo bastante flexible para realizar todos los casos de uso, hoy y en el futuro. De palabras de los propios creados del Proceso Unificado, es un problema semejante al del “huevo y la gallina”. En la realidad, arquitectura y casos de uso deben evolucionar en paralelo.
B.4.- Enfocado en los riesgos:
Para disminuir la posibilidad de fallo en las iteraciones o incluso la de cancelación del proyecto, se deben llevar a cabo sucesivos análisis de riesgos durante todo el desarrollo. Por supuesto, los riesgos principales deben ser identificados en una etapa temprana del ciclo de vida, y además, los resultados de cada iteración deben seleccionarse en un orden que asegure que estos son considerados primero.
B.5.- Ciclo de Vida del Proceso Unificado de Desarrollo:
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Al final de cada uno de ellos se obtiene una versión final del producto, que no sólo satisface ciertos casos de uso, sino que está lista para ser entregada y puesta en producción. En caso de que fuese necesario publicar otra versión, deberían repetirse los mismos pasos a lo largo de otro ciclo.
Como se es sabido cada ciclo se compone de varias fases, y dentro de cada una de ellas, los directores o los desarrolladores pueden descomponer adicionalmente el trabajo en iteraciones, con sus incrementos resultantes. Cada fase termina con un hito, determinado por la disponibilidad de un conjunto de artefactos, modelos o documentos. Las iteraciones de cada fase se desarrollan a través de las actividades de identificación de requisitos, análisis, diseño, implementación, pruebas e integración.
Figura: Fases AUP
Continúa…
1 comentarios:
bakan
Publicar un comentario