Definitions used in this thesis

La fase de elaboración el proyecto se apoya en la aplicación del modelo de referencia propuesto en OpenUP para la gestión del proyecto y el desarrollo de piezas de Software ya que este método es el que más se ajusta al propósito del análisis y diseño arquitectural de la solución, la estrategia es producir estimaciones aproximadas del tamaño de cada iteración y pruebas al final de cada fase para verificar que el hito se ha cumplido, de lo contrario se debe proponer la entrada de un control de cambios documentando un nuevo alcance de los entregables y su respectivo impacto en recursos y cronograma, la documentación del proyecto así como los demás artefactos de cada iteración también serán sometidos a revisión garantizando que se cumpla con los objetivos y estándares de calidad planteados en el proyecto.

4.3.1 OpenUP. El Proceso Unificado Abierto o OpenUP por sus siglas en ingles es un método incremental iterativo bajo un marco de código abierto para el desarrollo de software que se puede describir como mínimo y suficiente (OpenUP, 2014), esto significa que solo el contenido fundamental y necesario es incluido por lo tanto no provee lineamientos para todos los elementos que se manejan dentro de un proyecto sino los componentes básicos que pueden servir de soporte a procesos específicos, esto a diferencia de otros modelos más robustos y amplios como Rational Unified Process (RUP) OpenUP ofrece un método ágil para la gestión del ciclo de vida de una implementación en la pretensión del éxito. La mayoría de los elementos de OpenUP fomentan el intercambio de información entre los equipos de desarrollo y mantienen un entendimiento compartido del proyecto, objetivos, alcance y avances.

Entre algunas de las características de OpenUP se incluye el desarrollo iterativo, documentos de casos de uso y escenarios de desarrollo, gestión de riesgos y el enfoque centrado en la arquitectura, como resultado se obtiene un proceso mucho más simple sin embargo conserva aún algunos lineamientos con los principios RUP.

4.3.1.1 Elementos Básicos en OpenUP. Los elementos básicos de un proceso OpenUP son:

 Workproduct: lo que se produce.  Task: cómo realizar el trabajo.  Role: quien realiza el trabajo.

 Process: se utiliza para definir el flujo de trabajo o la interrupción del mismo.

4.3.1.2 Desarrollo Iterativo. El objetivo de las iteraciones es la entrega de valor al cliente de forma incremental en un lapso muy corto (días o semanas) representado por la entrega de funcionalidades completamente probadas o un componente empaquetable que pertenece al incremento de un producto. Esto crea

44

un enfoque saludable para asegurar que el esfuerzo realizado en el desarrollo sea de valor para las partes involucradas. En este enfoque la toma de decisiones sucede de forma más rápida que en un proceso formal debido a que no hay ni el tiempo ni la intensión para el debate extenso reduciendo el riesgo de caer en el inconveniente del análisis-parálisis con mecanismos de retroalimentación que permiten corregir el rumbo del desarrollo en cada momento que sea necesario. (OpenUP, 2014)

En el ciclo de vida de cada iteración se consideran 4 fases fundamentales:  Iniciación (Concepción y/o análisis). En esta fase se debe:

o Entender qué construir, determinando una visión global que incluyendo el alcance del sistema y de sus límites.

o Identificar los grupos de interés respondiendo a las preguntas ¿Quién está interesado en este sistema y cuáles son sus criterios de éxito?

o Identificar la funcionalidad clave del sistema. decidiendo qué requerimientos son los más críticos.

o Determinar al menos una posible solución evaluando si la visión es técnicamente factible, esto puede implicar la identificación de una arquitectura de alto nivel candidata, elaboración de prototipos técnicos o ambos.

o Elaborar una estimación de alto nivel para los costos, cronograma y los riesgos asociados con el proyecto.

 Elaboración. El objetivo de esta fase contempla:

o Obtener una comprensión más detallada de los requisitos con el propósito de crear un plan más detallado y realista para conseguir la aceptación de los interesados.

o Diseñar, implementar, validar y establecer la línea de base para la arquitectura. Diseñar, implementar y probar una estructura del esqueleto del sistema. Aunque la funcionalidad aún no está completo, la mayoría de las interfaces entre los bloques de construcción están implementados y probados. Esto se conoce como una arquitectura ejecutable.

o Mitigar los riesgos esenciales, y producir programación y costos estimados precisos. Muchos riesgos técnicos se tratan como resultado de detallar los requisitos y de diseñar, implementar y probar la arquitectura.

 Construcción. Esta fase debe considerar:

o Desarrollar un producto completo de forma Iterativa y que esté listo para la transición al grupo de usuarios. describiendo los requisitos restantes, completar los detalles de diseño, completar la aplicación y probar el software. Suelte la primera versión operativa (beta) del sistema y determinar si los usuarios están listos para que la aplicación se desplegará. o Minimizar los costes de desarrollo y lograr un cierto grado de paralelismo. Optimizar los recursos y el desarrollo de apalancamiento paralelismo entre los desarrolladores o equipos de desarrolladores, por ejemplo, la asignación

45

de los componentes que se pueden desarrollar de forma independiente el uno del otro.

 Transición. En esta fase se debe realizar:

o Pruebas para validar el cumplimiento de las expectativas del usuario, por lo general requiere realizar algunas actividades de ajuste como corrección de errores y mejoras de rendimiento y usabilidad.

o Lograr la concurrencia de las partes interesadas para que el despliegue se ha completado, esto puede implica varios niveles de pruebas para la aceptación del producto, incluyendo pruebas formales e informales.

o Documentar y retroalimentar las lecciones aprendidas en términos del rendimiento del proyecto para futuras implementaciones contemplando lecciones aprendidas, mejoramiento del entorno o una solución para la gestión y seguimiento del proyecto.

Figura 10. Ciclo de vida de una iteración

Fuente (OpenUP, 2014)

4.3.1.3 Componentes y relaciones. OpenUP está organizado en dos dimensiones diferentes pero interrelacionadas: el método y el proceso. El contenido del método es donde los elementos del método (roles, tareas, artefactos y lineamientos) son definidos, sin tener en cuenta como son utilizados en el ciclo de vida del proyecto.

El proceso es donde los elementos del método son aplicados de forma ordenada en el tiempo por el equipo de trabajo el cual es conformado por pocos miembros que trabajan bajo la figura de la autogestión, esto significa que toman sus propias decisiones acerca de lo que necesitan para trabajar, cuáles son las prioridades y la mejor forma de atender las necesidades de las partes interesadas. El compromiso de la parte administrativa es apoyar al equipo.

OpenUP se centra en reducir significativamente el riesgo desde fases tempranas del ciclo de vida del proyecto lo que requiere múltiples reuniones de revisión de riesgos regulares y la aplicación rigurosa de estrategias de mitigación.

Los casos de uso se utilizan para obtener y describir los requisitos, por lo tanto una habilidad fundamental en los miembros del equipo tienen que ser el desarrollo

46

de casos de uso de forma eficiente involucrando a los interesados quienes en última instancia son responsables de revisar y certificar que los requisitos se hayan cumplido.

Los requerimientos funcionales arquitecturales más significativos y de valor deben ser identificados y detallados en la fase de elaboración de manera que una arquitectura robusta se debe crear como núcleo del sistema. El modelo iterativo incremental permite un ajuste o cambio en un requisito arquitectural significativo que incluso puede ser tratado en la fase del desarrollo.

Por ultimo las pruebas se realizan múltiples veces por iteración por recomendación del marco cada vez que el valor de la solución se incrementa con el desarrollo de un producto, estas pruebas se producen después que los desarrolladores han desarrollado la solución y la integran en la base de código. Estas pruebas ayudan a garantizar que se crea una versión estable y siempre disponible como avanza el desarrollo. En la siguiente figura se representa la interacción entre las relaciones en el ciclo de vida del proyecto y su comportamiento

Figura 11. Relaciones en el Ciclo de vida de un proyecto y comportamiento.

Fuente (OpenUP, 2014)

4.3.1.4 Artefactos OpenUP para la gestión del proyecto.

Debido a que uno de los objetivos principales del método es centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo OpenUP es el método de referencia ideal para el proyecto que se está abordando, en ese orden de ideas se seleccionaron los siguientes documentos para la gestión del proyecto:

 Vision  Project Plan

47  Architecture Notebook

 Risk List

 Documentos de especificación de casos de uso  Documentos de especificación de casos de Prueba.

Estos documentos están basados en las plantillas que se encuentran en el sitio oficial de OpenUP. (HTTP://EPF.ECLIPSE.ORG/WIKIS/OPENUP/)

48