Metodología AUP (Agile Unified Process – Proceso Unificado Agil) para Implementación del ERP ADempiere - Parte 2

4.- Fases e Hitos:

Fase: Inception (Concepción):

Suele ser la fase más corta del desarrollo, y no debería alargarse demasiado en el tiempo. En caso contrario, podríamos encontrarnos en una situación de excesiva especificación inicial, yendo en contra del enfoque relativamente ágil del Proceso Unificado. Los clientes deben participar activamente del modelado en alto nivel de los requerimientos ya que este determina el alcance inicial del proyecto. El objetivo es identificar una arquitectura viable.

• Explorar la utilización del producto escribiendo casos de uso.
• Identificar los procesos de negocio mediante la realización de diagramas de flujo de datos.
• Identificar principales entidades del negocio y sus relaciones. Esto se puede hacer trabajando en un dominio reducido del negocio.
• Identificar las principales reglas de negocio y los principales requerimientos técnicos.
• Comenzar la realización de un glosario que contenga los principales términos técnicos y del negocio.

Fase: Elaboración:

Durante esta fase deberían capturarse la mayoría de requisitos del sistema, aunque los objetivos principales son tratar los riesgos ya identificados y establecer y validar la base de la arquitectura del sistema. Esta base se llevará a cabo a través de varias iteraciones, y servirá de punto de partida para la fase de construcción. La fase de elaboración termina, por tanto, al alcanzar el hito de la arquitectura del sistema.

• Identificar riesgos técnicos. Los artefactos de requerimientos, en particular los casos de uso o los requerimientos técnicos pueden revelar potenciales riesgos del proyecto.
• Modelado de la arquitectura. Al construir el modelado de la arquitectura puede resultar útil hacer model storming para resolver alguna de las partes de la arquitectura.
• Realizar un prototipo de la interfaz de usuario. En paralelo con el modelado de la arquitectura debiera realizarse un prototipo de la interfaz que contenga las pantallas principales. No se necesita hacer mucho prototipado en esta fase porque los requerimientos seguramente van a cambiar y entonces el trabajo será descartado. El objetivo debería ser entender las principales pantallas de la interfaz e identificar el “look and feel” básico de la aplicación.

Fase: Construcción:

Es la fase más larga del proyecto, y completa la implementación del sistema tomando como base la arquitectura obtenida durante la fase de elaboración. A partir de ella, las distintas funcionalidades son incluidas en distintas iteraciones, al final de cada una de las cuales se obtendrá una nueva versión ejecutable del producto.

Por tanto, esta fase concluye con el hito de obtención de una funcionalidad completa, que capacite al producto para funcionar en un entorno de producción. También en esta fase es necesario trabajar al lado del cliente para identificar sus necesidades paso a paso.

• Participación activa del cliente y modelado inclusivo. La idea es que los clientes participen del modelado. Para esto se utilizan herramientas y técnicas sencillas, cuanto más sencillas mejor.
• Mostrar los detalles de casos de uso. Para ello se sugiere usar diagramas de actividad UML en lugar de descripciones textuales.
• Explorar reglas de negocios y requerimientos técnicos con la misma profundidad.
• Aplicar model storming para el diseño. En las iteraciones de construcción se debe realizar el modelado suficiente para resolver un único requerimiento antes de implementarlo.
• Puede resultar útil realizar diagramas de secuencia UML, modelo de deployment, diagramas de clase UML, modelo de seguridad frente a amenazas, modelo de datos físicos. No es necesario utilizar todas las técnicas, la utilidad o no de ellas depende del proyecto.
• Documentar las decisiones de diseño críticas. Se recomienda documentar aquellas decisiones que no resulten obvias y a aquellas que puedan resultar interesantes para alguien en el futuro. Estas decisiones documentadas pueden considerarse como un comienzo para el documento general del sistema que se finaliza en la fase de transición.

Fase: Transición:

En la fase final del proyecto se lleva a cabo el despliegue del producto en el entorno de los usuarios, lo que incluye la formación de éstos.

• Aplicar model stroming para intentar comprender la causa de defectos detectados.
• Finalizar la documentación general del sistema. El mejor momento para terminar la documentación general del sistema es en esta fase donde el alcance del sistema está verdaderamente estabilizado.
• Comprende tests del sistema, de los usuarios e instalación del sistema.
• Entre sus objetivos busca la aceptación de los stakeholders del negocio, de operaciones, soporte y de costos estimados.

5.- Disciplinas:

Las disciplinas se llevan a cabo de manera sistemática, a la definición de las actividades que realizan los miembros del equipo de implementación a fin de desarrollar, validar, y entregar el software de trabajo que responda a las necesidades de sus interlocutores. Las disciplinas son:

a.- Modelo: El objetivo de esta disciplina es entender el negocio de la organización, el problema de dominio que se abordan en el proyecto, y determinar una solución viable para resolver el problema de dominio.

b.- Aplicación: El objetivo de esta disciplina es transformar su modelo (s) en código ejecutable y realizar un nivel básico de las pruebas, en particular, la unidad de pruebas.

c.- Prueba: El objetivo de esta disciplina consiste en realizar una evaluación objetiva para garantizar la calidad. Esto incluye la búsqueda de defectos, validar que el sistema funciona tal como está establecido, y verificando que se cumplan los requisitos.

d.- Despliegue: El objetivo de esta disciplina es la prestación y ejecución del sistema y que el mismo este a disposición de los usuarios finales.

e.- Gestión de Configuración: El objetivo de esta disciplina es la gestión de acceso a herramientas de su proyecto. Esto incluye no sólo el seguimiento de las versiones con el tiempo, sino también el control y gestión del cambio para ellos.

f.- Gestión de Proyectos: El objetivo de esta disciplina es dirigir las actividades que se lleva a cabo en el proyecto. Esto incluye la gestión de riesgos, la dirección de personas (la asignación de tareas, el seguimiento de los progresos, etc), coordinación con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto.

g.- Entorno: El objetivo de esta disciplina es apoyar el resto de los esfuerzos por garantizar que el proceso sea el adecuado, la orientación (normas y directrices), y herramientas (hardware, software, etc.) estén disponibles para el equipo según sea necesario.

Recomendaciones:

• No es necesario invertir mucho tiempo en detallar el modelado y la documentación en las fases de inicio y elaboración. Sólo deberían llevar unos días el Modelado Inicial de Requerimientos y el Modelado Inicial de la Arquitectura.
• Model storming se realiza cuando se precisa y sólo para obtener los detalles estrictamente necesarios. Típicamente esto se hace en la fase de construcción y no debería llevar más de unos minutos.
• El objetivo es crear modelos con la profundidad necesaria para lo que se está haciendo y no tratar de ir más allá. Hay que tener presente que en cualquier momento se puede volver atrás y explicitar más detalles si se necesita.
• La mayor parte de los modelos se descarta (sólo una pequeña parte de ellos se mantiene) Los modelos deberían hacerse empleando técnicas simples, tomando en cuenta que una vez que los requerimientos estén bien especificados serán descartados.
• Siempre hay que tener en cuenta oportunidades de re-uso. Esto no refiere sólo al código.
• La participación activa del cliente se considera fundamental para el éxito del proyecto.
• Se recomienda emplear arquitectura en capas.

6.- Entregables:

Entre los diagramas UML recomendados por el sitio web ambysoft (Ambysoft, 2010) aplicables para AUP tenemos:

• Diagramas de Casos de uso.
• Especificación de Casos de Uso.
• Diagrama de Clases.
• Diagramas de Secuencia
• Diagramas de Estado.
• Interfaces Graficas de Usuario.
• Diagrama de Componentes
• Diagrama de Despliegue

7.- Consejos

• Mantener los entregables tan simples y concisos como se pueda.
• Se necesita mucha menos documentación de la que se piensa.
• Trabajar conjuntamente con la gente que crea los entregables, para producir sólo lo necesario.
• Documentos ágiles son justo lo suficientemente buenos.
• Producir documentos es la peor manera de comunicar la información.
• Utilizar pizarrones, papel y Wikis para modelar y capturar la documentación.

8.- Conclusión para la Metodología AUP:

Si deseamos un método ágil entre XP y RUP tradicionales, que incluya explícitamente las actividades y las herramientas que están acostumbrados, entonces la más aconsejable es la AUP. XP no muestra explícitamente cómo crear algunos de las herramientas que la administración quiere ver. En el otro extremo del espectro está RUP, que es el gestor más utilizado de los desarrolladores, pero presenta una gran cantidad de herramientas. La AUP en comparación entre los dos, es la adopción de muchas de las técnicas ágiles de XP y otros procesos ágiles que mantiene de las RUP.

En relación al XP, el AUP resulta ser un proceso muy pesado y en relación al RUP resulta ser un proceso muy simplificado, entonces, los desarrolladores o implementadores deberán decidir en: si desea buscar una forma de trabajo ligero esta XP y si desea trabajar con un proceso más detallado esta RUP.

Sin lugar a dudas, las personas son y seguirán siendo el "ingrediente original" necesarias para tener éxito. Sin embargo, con una mejor comprensión de agilidad, individuos, equipos y organizaciones están más facultados no sólo para hacer simplemente al cambio y complejidad, sino aprovechar el cambio y la complejidad para lograr una ventaja competitiva. Además, es experiencia, experimentación y aplicación de agilidad que permitirá obtener sus beneficios.

Fuente: Investigación Propia