Gestión Ágil de Proyectos mediante la Integración de Blue-WATCH y SCRUM

Transcripción

1 Gestión Ágil de Proyectos mediante la Integración de Blue-WATCH y SCRUM Judith Barrios y Jonás Montilva Grupo GIDyC, Departamento de Computación, Escuela de Ingeniería de Sistemas, Universidad de Los Andes Mérida - Venezuela {ijudith, jonas}@ula.ve Abstract. En este Capítulo se presenta la integración de dos marcos metodológicos utilizados para guiar el desarrollo de productos de software: el Blue- WATCH y el SCRUM. El marco metodológico Blue-WATCH, reconocido por la descripción precisa de los procesos técnicos de desarrollo, se combina con conceptos de gestión de proyectos provenientes de SCRUM, que se reconoce como un marco de trabajo exitoso en la gestión ágil de proyectos de software. El Capítulo presenta la estrategia de integración utilizada, haciendo especial énfasis en el marco de desarrollo de software resultante de dicha integración. Este marco provee un conjunto de conceptos y procesos más completo, que compone procesos ágiles de gestión de proyectos con procesos técnicos y de soporte propios del desarrollo de software. Desde el punto de vista de los procesos de gestión de proyectos y de equipos de trabajo ágiles, se pretende que el marco integrado tenga una mayor posibilidad técnica de producir resultados funcionales y operativos rápidamente, respondiendo de manera más oportuna y apropiada a las demandas cambiantes que tienen los productos de software en las organizaciones de hoy. Actualmente, el marco metodológico integrado se valida por medio de su instanciación en dos proyectos piloto de desarrollo de software empresarial. Keywords: Integración de métodos, Marcos metodológicos de desarrollo de software, Ingeniería de Métodos. 1 Introducción La ejecución exitosa de un proyecto de desarrollo de software es, generalmente, el resultado de la selección, adaptación y agrupamiento de un conjunto de actividades, que atienden a ciertos criterios o lineamientos técnicos y gerenciales. Estos criterios van desde el tipo o categoría del producto de software, la tecnología requerida y disponible y el presupuesto asignado, hasta considerar la disponibilidad y experiencia de los miembros del equipo de trabajo. Es decir, las actividades de desarrollo se ejecutan al adecuar el proceso de desarrollo a situaciones particulares asociadas con el contex- adfa, p. 1, Springer-Verlag Berlin Heidelberg 2011

2 to específico de un proyecto; entre algunos de los factores situacionales están la cultura organizacional, la infraestructura tecnológica instalada, el tiempo disponible, la gestión de imprevistos, etc. Desde el punto de vista técnico y gerencial, existen algunos métodos, técnicas, prácticas y herramientas, que se pueden ajustar o adaptar a las características particulares de un proyecto de software; entre las más conocidas están: RUP [1], XP [2], MSF [3], ICONIX [4], TDD [5] y SCRUM [6]. En la práctica, se destaca, además, que el tiempo requerido para hacer estas adaptaciones es proporcional a la experiencia del líder de proyecto y a su conocimiento del dominio del proyecto. Es por ello que, con esta gran proliferación de métodos, técnicas y herramientas, sólo se pudo alcanzar parcialmente el éxito esperado; pues, el elemento clave del éxito es la capitalización del conocimiento del dominio y la experiencia técnica del líder del proyecto, las cuales no se transmiten o expresan en los métodos conocidos [7]. Un trabajo previo del grupo de investigación GIDyC, se concentra en la definición de un conjunto de variantes o escenarios de desarrollo de software que surgen de la especialización de un conjunto de conceptos contenidos y estructurados dentro de un marco metodológico general, denominado WATCH [8], a partir del cual se elaboró una suite de métodos de desarrollo de software. Cada variante de esta suite, considera un conjunto anticipado de características contextuales y de proyecto que se pueden luego adaptar a proyectos de desarrollo similares. Así, se reduce el conjunto de opciones y el esfuerzo que requiere el líder del proyecto, tanto para seleccionar un método apropiado para un dominio y una categoría de proyecto, como para adaptarlo al escenario particular del proyecto en cuestión. En este Capítulo se entiende que un marco metodológico se puede especializar para producir variantes de método ajustadas a ciertos contextos o escenarios de desarrollo de software. Por ello, el marco integrado presentado aquí se podrá adaptar e instanciar para responder acertadamente a factores situacionales de proyectos de desarrollo de software empresarial. Es importante resaltar que el contexto actual de utilización de las tecnologías de información y de comunicación (TIC), implica que éstas y, más específicamente, los sistemas de software respondan oportunamente a las demandas de las estrategias gerenciales que buscan aprovecharlas al máximo, no sólo para lograr mejores índices de rendimiento, productividad y ganancia, sino para lograr satisfacer en mayor grado a sus clientes, por medio de la oferta de servicios y de productos de calidad superior [9]. En este espacio, las organizaciones y equipos de desarrollo de software requieren con mayor énfasis herramientas metodológicas que los apoyen en la organización, ejecución y reajuste técnico de sus proyectos, propiciando una respuesta pronta y acertada a las exigencias de evolución y cambio en los sistemas y las tecnologías; es decir, las organizaciones y equipos de desarrollo de software buscan agilizar el proceso de desarrollo de productos sin detrimento de la calidad del producto y del proceso de desarrollo mismo. Por lo tanto, se proyecta que el marco metodológico que se presenta en este Capítulo, puede contribuir favorablemente a la satisfacción de las demandas de agilización de proyectos que tienen estas organizaciones hoy día. El Blue-WATCH es un marco metodológico balanceado, entre agilidad y disciplina, que hace especial énfasis en la organización y ejecución de los procesos de desarrollo de software, buscando garantizar la calidad del producto vía la calidad de su proceso de producción. No obstante, la gestión de proyectos de software prevista en el

3 Blue-WATCH es pesada y disciplinada, dado que se inspira en las prescripciones del PMBOK (Project Management Body of Knowledge) [10]. Por otra parte, SCRUM se despliega como un marco de trabajo especializado en la gestión ágil de proyectos, dejando desamparados y poco atendidos los conceptos técnicos y de soporte correspondientes con la producción y mantenimiento de productos de software con calidad esperada. La idea central de este Capítulo es la inclusión, en el Blue-WATCH, de aquellos conceptos ágiles relacionados con la gestión de proyectos de SCRUM, buscando completar un marco de desarrollo de software equilibrado, que permita producir resultados más rápidamente, sin detrimento de las especificaciones técnicas que garantizan la calidad esperada del producto que se desarrolla. El resto de este Capítulo se estructura como sigue: la Sección 2 detalla los marcos metodológicos Blue-WATCH y SCRUM; la Sección 3 presenta la estrategia de integración; se describen los conceptos de la Ingeniería de Métodos sobre los cuales se fundamenta dicho proceso y se presenta la perspectiva intencional de integración de los marcos metodológicos; se describe, también, la ejecución del proceso de integración, ilustrando los resultados parciales de las principales intenciones y estrategias seleccionadas; la Sección 4 describe los tres componentes principales del marco que resultan de la integración: el modelo de productos, el modelo de actores y el modelo de procesos; se finaliza la sección con la especificación de la manera de instanciar el marco metodológico integrado; finalmente, la Sección 5 concluye el trabajo, señalando los aportes de la propuesta y esbozando el trabajo futuro. 2 Los Marcos Metodológicos Base de la Integración 2.1 La Suite WATCH, sus variantes y el Blue-WATCH WATCH es un marco metodológico para el desarrollo de productos de software, ajustado al contexto venezolano. Este marco se determina con un conjunto de variantes de método, denominadas Gray-WATCH [15], Blue-WATCH [16-17], White- WATCH [18] y Yellow-WATCH [19]. Con estas variantes de método, se pretende guiar de manera más precisa la selección, adaptación y ejecución de proyectos de software que consideren expresamente ciertas características del producto/proyecto que se desea ejecutar [8]. La variante Gray se enfoca en el desarrollo de aplicaciones empresariales, generalmente complejas y con un grupo de desarrollo grande (10 o más personas). Esta variante es la más pesada y disciplinada de la suite [15]. La variante White es la más ligera y simple del grupo, y sirve para guiar el desarrollo de productos de software pequeños, sencillos y con un equipo de trabajo de una o dos personas. Se centra en el desarrollo basado en reutilización de componentes de software [18]. La variante Yellow se basa completamente en el desarrollo de software basado en servicios y facilita, por lo tanto, la interoperabilidad de las aplicaciones de negocios [19]. La variante Cyan, se define específicamente para desarrollar aplicaciones de ambientes virtuales y aún está en fase de verificación y validación. La variante Blue balancea agilidad y disciplina e incluye las mejores prácticas de la Ingeniería de Software para desarrollar proyectos de mediana complejidad y en grupos no mayores de 10 personas [17]. La variante Blue, en su segunda versión [18], trata conceptos complejos, espe-

4 cializables e instanciables, por lo que se describe al nivel más alto de abstracción (metamodelado), como un marco metodológico sobre el cual se pueden definir nuevas variantes de desarrollo de software. Esta versión se usa como marco metodológico para la integración descrita en este Capítulo. Tanto el marco metodológico WATCH como cada una de sus variantes, se compone de tres elementos básicos: modelo de producto, modelo de proceso y modelo de actores, atendiendo a los niveles de abstracción y a los principios de Ingeniería de Métodos que se describen en la próxima Sección. El Modelo de Producto identifica, clasifica y describe los diferentes productos del desarrollo de una aplicación empresarial. Estos productos se clasifican en dos categorías: productos entregables y productos intermedios. El principal producto entregable es la aplicación empresarial. El marco recomienda elaborar durante la ejecución de los procesos técnicos, de gestión y de soporte un conjunto de productos intermedios, que se producen usando las técnicas y herramientas recomendadas y sugeridas dentro de cada proceso técnico, de gestión o de soporte. La Tabla 1 muestra el modelo de productos del marco Blue-WATCH. El Modelo de Procesos se especifica empleando los procesos técnicos: Modelado de Negocios, Desarrollo de Requisitos, Diseño Arquitectónico y Desarrollo de Versiones; estos procesos se apoyan en los procesos gerenciales y de soporte: Gestión de Proyectos, Gestión de Requisitos, Verificación & Validación, Aseguramiento de la Calidad, Gestión de Riesgos y Gestión de la Configuración de Software (SW). Estos procesos se realizan cíclicamente permitiendo el desarrollo iterativo de versiones de la aplicación de software. Este modelo se representa en la Figura 1. Tabla 1. Modelo de Productos del Marco Metodológico Blue-WATCH Productos Técnicos Productos de Gestión Productos de Soporte Modelo del Negocio Visión del Producto Proceso y estándares de desarrollo Documento de Requisitos Plan del Proyecto Plan de Validación Documento de Diseño Planes de Iteraciones y Entregas Plan de Gestión de la Configuración Especificaciones de Pruebas Plan de Pruebas Plan de Riesgos El Ciclo de la Aplicación DV Desarrollo de Versiones MN Modelado del Negocio V i V n Gestión del Proyecto Aseguramiento de la Calidad Gestión de Riesgos Gestión de la Configuración Gestión de Requisitos DR Desarrollo de Requisitos V 1 DA Diseño Arquitectónico Cada versión se produce entre 1 3 meses Fig. 1. Modelo de Procesos del Marco Metodológico Blue-WATCH

5 El Modelo de Actores, representado en la Figura 2, considera los actores y sus roles dentro de un grupo de trabajo. Entre los principales actores y roles se tienen: Líder del Proyecto, Analista, Arquitecto de SW, Programador, Experto en Pruebas, Gestor de Soporte y Representante de Usuarios. «actor» Grupo de Desarrollo 1 «actor,rol» Líder del Proyecto 1..* «actor,rol» Analista 1..* «actor,rol» Arquitecto de SW 1..* «actor,rol» Programador 1..* «actor» Experto en Pruebas 1..* «actor,rol» Gestor de Soporte 1..* «actor,rol» Representante de Usuarios Fig. 2. Modelo de Actores del Marco Metodológico Blue-WATCH 2.2 El marco metodológico SCRUM SCRUM es un marco de trabajo para la gestión del desarrollo ágil de software. Describe una manera efectiva de gestionar proyectos de software usando un conjunto de principios y prácticas ampliamente conocidas en la industria del software. Se inspira en la manera de reiniciar el juego en un partido de Rugby (una especie de fútbol) conocida como scrum y, en la cual, los jugadores de un equipo se agrupan en filas circulares que se oponen y empujan al equipo contrario en un intento por tomar posesión de la pelota, la cual uno de los jugadores introduce en el círculo. SCRUM es un marco metodológico que explica cómo se debe gestionar el desarrollo de proyectos de software de manera incremental e iterativa. Se basa en cuatro principios que son coherentes con los enunciados básicos del Manifiesto para Desarrollo Ágil de Software: individuos e interacciones por encima de procesos y herramientas, software que funcione, colaboración con el cliente y respuesta al cambio [20]. SCRUM emplea los siguientes elementos metodológicos: Tres roles: Maestro SCRUM (ScrumMaster), Dueño del Producto (Product Owner) y Equipo (Team). Cuatro ceremonias: Planificación del Sprint, SCRUM Diario, Revisiones del Sprint y Retrospectiva del Sprint. Tres artefactos: Pila del Producto (Product Backlog), Pila del Sprint e Incremento del Producto. La Fig. 3 muestra los artefactos, roles y eventos principales de SCRUM. A diferencia de otros métodos ágiles, tales como XP, AUP y FDD, SCRUM no prescribe prácticas de ingeniería específicas, tales como: programación por pares, refactorización, diseño simple, etc. Ello no significa que no permita o recomiende su uso, sino que no se ata a ellas. SCRUM tampoco describe los procesos técnicos del desarrollo; pues, es un marco de trabajo para gestión de proyectos y, por lo tanto, no incluye los procesos técnicos requeridos para analizar, diseñar, programar y probar software.

6 Fig. 3. El marco metodológico SCRUM (tomado de [6] bajo licencia Creative Commons). 3 EL Proceso Conceptual de Integración 3.1 Enfoque de Ingeniería de Métodos La Ingeniería de Métodos (IM) se define como la disciplina que permite concebir, construir y adaptar métodos, técnicas y herramientas para el desarrollo de sistemas de información. Se fundamenta en los principios de metamodelado, reutilización, modularidad y flexibilidad. En este contexto, un método aporta los conceptos para describir el producto a elaborar, las reglas de conducción metodológica para realizar aquellas actividades que conllevan a construir un producto [11, 12]. Considerando que personal técnico y gerencial ejecuta las actividades de elaboración, por enmarcarse en un proyecto de ingeniería, se agrega el componente personal, responsable de la ejecución de dichas actividades. Se prevé que la conjunción de estos tres elementos asegure la calidad del producto y del proceso que lo construye, permitiendo la consecución exitosa de los objetivos del proyecto de desarrollo de software [13]. El marco metodológico WATCH se compone de tres metamodelos: producto, proceso y actores. Esta conjunción de modelos se explica entendiendo un producto de software como la composición de un conjunto de subproductos que se representan en un Modelo de Productos y entendiendo que para producir cada uno de estos (sub)productos, los actores, miembros del equipo de trabajo, representados en un Modelo de Actores, ejecutan un conjunto de actividades y tareas previstas en un Modelo de Procesos. Es importante destacar que los conceptos contenidos en un modelo son el resultado de la especialización de los conceptos contenidos en un metamodelo (nivel superior). Esto se explica, más precisamente, desde el punto de vista de los niveles de abstracción de la IM [11-12, 14]. La Figura 4 muestra los niveles de abstracción referidos a la concepción, especialización, instanciación y/o adaptación del marco metodológico WATCH y sirve de base para entender el trabajo presentado en este Capítulo. La definición y utilización de un marco metodológico o de una variante de método (nivel intermedio modelos) se concibe con su posición en un agregado de niveles de abs-

7 tracción como se muestra en la Figura 4. Cada nivel presenta un grupo de conceptos que sirven de base para la definición de otros conceptos en el nivel inmediatamente inferior. Así, un método (conjunto de modelos) ubicado en el nivel intermedio de abstracción, se define a partir de una adaptación y/o especialización del conjunto de conceptos del metamodelo (nivel superior); en el nivel inferior, se tiene la ejecución del método según las características particulares de un proyecto, es decir el conjunto de modelos ajustados al escenario del proyecto en actual ejecución. Factores predefinidos de contexto, producto y proyecto Ingeniero de Métodos Caracteristicas de producto y proyecto actual Diseño de una variante de método Meta-Modelos Producto- Proceso- Actores Marco -Metodológico Instanciación /Especialización Modelos Producto-Proceso-Actores Gray, Blue, White, Yellow. Variantes de Watch Nivel de abstracción para la integración de marcos metodológicos Lider de Proyecto (1) Selección de una variante de método (2) Adaptaciónde la variante seleccionada Instanciación/Adaptación Modelos Adaptados Producto-Proceso-Actores Escenario de Proyecto actual Escenario de Proyecto Execution Fig. 4. Niveles de abstracción y perspectivas de uso de la IM Perspectivas de Uso del Marco Metodológico. El aprovechamiento de un marco metodológico se estudia desde dos perspectivas complementarias: la del Ingeniero de Métodos y la del Ingeniero de Aplicación o del Líder del Proyecto [7]. La primera perspectiva utiliza el marco metodológico para definir un nuevo marco, método o una variante de método que responda a una categoría de producto/proyecto de software, no contemplada en ninguna de las variantes disponibles; la segunda perspectiva considera la instanciación y/o la adaptación de alguna de las variantes de método disponibles, para llevar a cabo un proyecto particular atendiendo a la categoría de producto/proyecto correspondiente a la variante seleccionada. En la Fig. 4, se muestran las dos perspectivas de utilización del marco WATCH. En este Capítulo, se enfatiza el rol del Ingeniero de Métodos como el encargado de realizar la integración de dos marcos metodológicos para producir uno nuevo. Todos los marcos metodológicos, tanto los de base como el resultante, se ubican en el nivel más alto de abstracción; pues, se utilizan como metamodelos que servirán luego de base para producir nuevos modelos de desarrollo o variantes de método. 3.2 Modelo Intencional de Integración Con el objeto de representar y reutilizar el conocimiento involucrado en el proceso de integración de los marcos metodológicos, se utiliza el concepto de mapa de rutas

8 [21, 22], que permite describir múltiples maneras de realizar un proceso complejo como es el de la integración de marcos metodológicos, representando un modelo de procesos a nivel intencional y obviando la especificación de un orden predeterminado de ejecución del proceso representado. Un mapa intencional se simboliza como un grafo dirigido cuyos nodos representan intenciones (en este caso, las intenciones de integración) y en cuyos arcos se definen estrategias para la ejecución de las intenciones. Una estrategia es una manera o enfoque previsto para alcanzar o cumplir con una intención; también, para indicar la manera de avanzar de una intención a otra. La decisión sobre qué estrategia ejecutar o hacia cuál intención avanzar, se toma considerando la situación actual en la que se encuentra el proceso y según el conocimiento de dominio, implícito o explicito, con el que se realiza el proceso de integración. El mapa de rutas de la integración La Fig. 5 muestra el mapa de rutas del proceso de integración de los marcos metodológicos. Es importante señalar que, por ahora, este mapa de rutas sólo contiene una ruta validada, y es precisamente la seguida en este Capítulo. No obstante, un Ingeniero de Métodos puede seguir esta ruta para producir un nuevo marco metodológico que se puede especializar. También, se puede seguir para integrar alguno de los marcos metodológicos disponibles con otro marco metodológico de dominio. Las estrategias en líneas oscuras son las ejecutadas y describen la ruta de integración seguida. Las estrategias en gris son estrategias previstas y factibles, que se pueden utilizar, pero que no pertenecen a la ruta de integración de este Capítulo. Tal es el caso de las estrategias E7, E5 y E6. Los nodos de inicio y de fin indican que el proceso de integración empieza y termina de modo intencional. Así, la intención I1, es el resultado de la aplicación de la estrategia E1, a partir de la intención de Inicio. Luego, el nodo de Fin del proceso se alcanza una vez se logra la integración y se ejecuta la estrategia E8 de Terminación del proceso. Inicio E1: Uniformidad E2: Modelizacion de Componentes I1: Nivelar Marcos Metodologicos E3: Comparación E4: Combinación E7: IntegraciónDirecta E5: Transferencia I2: Integrar Marcos Metodologicos E6: extensión E8: Terminación Fin Fig. 5. Mapa Intencional de Rutas del Proceso de Integración de Marcos Metodológicos

9 Intenciones principales I1: Nivelar Marcos Metodológicos: esta intención busca colocar los marcos que se van a integrar en un formato y notación similar que facilite su análisis y posterior composición. La nivelación se realiza inicialmente con la estrategia de Uniformidad de Representación (E1), donde se analizan y describen los conceptos implicados en ambos marcos utilizando una notación equivalente que permita comprender exactamente los conceptos manejados y las relaciones entre dichos conceptos, para cada marco metodológico. La estrategia de Modelado de Componentes (E2) del método se ejecuta para completar aquellos modelos (producto, proceso y/o actores) requeridos para la integración y que pueden no estar disponibles en las representaciones de alguno de los marcos. I2: Integrar Marcos Metodológicos: esta intención conlleva a realizar la composición, propiamente dicha, de los conceptos presentes en los modelos de cada marco. Inicialmente, la estrategia Comparación (E3) permite cotejar los modelos, permitiendo balancear sus elementos y esclarecer cuales están presentes en ambos marcos y cuáles no; del mismo modo, la estrategia permite eliminar la ambigüedad, si hubieran sinónimos u homónimos en sus representaciones. La estrategia de Combinación (E4) se ejecuta para definir el marco integrado como una combinación (o unión) de modelos y conceptos. El detalle de la aplicación de las estrategias para cumplir con las intenciones y los resultados parciales se presentan a continuación. Resultados de la nivelación Para nivelar los marcos metodológicos se aplicaron dos estrategias de integración complementarias: E1: Uniformidad de representación de los marcos metodológicos: La comparación de los marcos se simplifica si ambos son representados de una manera uniforme. Esta representación uniforme amerita el uso de un lenguaje de modelado apropiado. Se seleccionó la extensión de negocios del lenguaje de modelado unificado UML [23] debido a su capacidad semántica, la cual posibilita una representación gráfica homogénea de conceptos y elementos metodológicos, tales como: objetivos, productos, procesos, actividades, actores y eventos. La representación de estos elementos se organizó en los tres modelos fundamentales que caracterizan a todo método: Modelo de Productos: Identifica, clasifica y describe todos los productos intermedios y finales que se elaboran durante el desarrollo de software. Modelo de Procesos: Identifica, organiza y describe los procesos y actividades (flujos de trabajo) de desarrollo de software, que se deben ejecutar para elaborar los productos establecidos en el modelo de productos. Modelo de Actores: Identifica, organiza y describe los roles requeridos para ejecutar los procesos de desarrollo de software indicados en el modelo de procesos. A modo de ejemplo, se ilustra en la Figura 6 uno de los diagramas UML contenidos en el modelo de procesos del marco metodológico Blue WATCH. E3: Comparación de las representaciones de los marcos metodológicos: A partir de las representaciones uniformes de ambos marcos se hace factible una mejor comparación de los conceptos y elementos metodológicos. Las tablas 2-5 resumen las similitudes encontradas entre ambos marcos metodológicos, en función de los conceptos fundamentales y los modelos de productos, procesos y actores. La relación de simili-

10 tud no expresa equivalencia o igualdad; simplemente, indica que los elementos comparados son conceptuales parecidos o se utilizan con un propósito similar. Modelado del Negocio Desarrollo de Requisitos Diseño Arquitectónico Desarrollo de Versiones Gestión del Proyecto Gestión de Requisitos Verificación & Validación (V&V) Gestión de la Configuración del Software (GCS) Gestión de Riesgos Aseguramiento de la Calidad del Software (ACS) Fig. 6. Ejemplo de representación de un proceso del marco metodológico Blue-WATCH Como se puede apreciar en la Tabla 2, ambos marcos son incrementales e iterativos. La principal diferencia entre ambos estriba en la manera de realizar las iteraciones. SCRUM desarrolla productos de software mediante un conjunto de iteraciones de duración fija, llamadas Sprint. Blue-WATCH usa dos tipos de ciclos o iteraciones anidadas y de duración variable. Los ciclos externos permiten desarrollar una aplicación empresarial, en varias versiones consecutivas; mientras que, los ciclos internos desarrollan cada versión en incrementos predefinidos. Tabla 2. Similudes entre los conceptos principales de los marcos metodológicos Blue-WATCH y SCRUM Blue WATCH Marco metodológico Ciclo o Iteración Versión - Incremento Proceso Actividad Producto Actor-Rol Requisito Aplicación Empresarial Interesado SCRUM Marco de trabajo Sprint Incremento Ceremonia Tarea Artefacto Rol Ítem o elemento Producto Interesado El número de productos que se generan usando Blue-WATCH es mucho mayor que en SCRUM (véase la Tabla 3). Ello se debe a dos razones: SCRUM es un marco de trabajo ágil, en el cual se le da poca importancia a la documentación; mientras que Blue-WATCH es un marco balanceado (ágilmente

11 disciplinado), en el cual la documentación, aunque mínima, es importante para garantizar un apropiado mantenimiento. SCRUM se orienta a los procesos de gestión del proyecto y no hace referencia explícita a los procesos técnicos de análisis, diseño, programación y pruebas. Con la excepción de los procesos de Revisión y Retrospectiva del Sprint, SCRUM no considera otros procesos de soporte, tales como Gestión de la Configuración y Gestión de Requisitos. Por su parte, Blue-WATCH hace una clara identificación y clasificación de los procesos de desarrollo de software, dividiéndolos en: (1) procesos técnicos: Modelado del Negocio, Desarrollo de Requisitos, Diseño Arquitectónico, Desarrollo de Versiones, Desarrollo de Incrementos, etc.; (2) procesos de gestión del proyecto: Inicio, Planificación, Dirección, Seguimiento & Control y Cierre del Proyecto; y (3) procesos de soporte: Gestión de Requisitos, Verificación & Validación (V&V), Gestión de la Configuración y Gestión de Riesgos. En relación con los actores que participan en el desarrollo de software, ambos marcos difieren significativamente (véase la Tabla 4). SCRUM establece sólo tres roles: Dueño del Producto, Scrum Master y Equipo. El Dueño del Producto representa a los usuarios de la aplicación y define los aspectos funcionales de la aplicación. El Scrum Master actúa como un guía, coach o facilitador del proyecto. En SCRUM, los equipos se auto-organizan; no hay roles técnicos predefinidos y no existe la figura de líder o gerente del proyecto. Blue WATCH, por su parte, establece roles en función de los procesos técnicos, de gestión y de soporte. Aunque, Blue-WATCH no impone una estructura organizativa particular, la figura del Líder del Proyecto es vital, pues es el responsable de los procesos de gestión del proyecto y representa al Equipo de Desarrollo ante la gerencia o un Comité Técnico del proyecto. El rol de Representante de Usuarios, en Blue WATCH, es muy similar al de Dueño del Producto, en SCRUM. Tabla 3. Similtudes entre los elementos de los modelos de productos de los marcos metodológicos WATCH y SCRUM WATCH Producto: Técnico, de Gestión o de Soporte Modelo del Negocio - Documento de Requisitos Documento de Diseño - Aplicación Empresarial Especificaciones de Pruebas - Plan del Proyecto Plan de la Versión Plan del Incremento SCRUM Artefacto Pila del Producto y del Sprint Aplicación o Producto Pila del Producto Pila de Entregas Pila del Sprint - Gráficas de Trabajo Restante - Pila de Impedimentos Plan de V&V - Plan de Gestión de Riesgos - Plan de Gestión de Configuración -

12 Tabla 4. Similtudes entre los elementos de los modelos de Actores de los marcos metodológicos Blue-WATCH y SCRUM Blue WATCH Comité Técnico - Líder del Proyecto - SCRUM - ScrumMaster Analista Arquitecto de SW Diseñador Programador Experto en Pruebas Gestor de Soporte: Configuración y Calidad Representante de Usuarios Equipo Equipo Equipo Equipo Equipo Equipo Dueño del Producto Tal como se evidencia en la Tabla 5, la principal diferencia entre los dos marcos se encuentra en sus modelos de procesos. SCRUM se centra en procesos de gestión del proyecto y da por entendido a los procesos técnicos y de soporte. Por esta razón, SCRUM se puede aplicar en proyectos ajenos al desarrollo de software. Blue WATCH, por el contrario, clasifica, relaciona y describe los procesos de gestión y los procesos técnicos y de soporte, propios del desarrollo de software. Table 5. Similitudes entre los elementos de los modelos de procesos de los marcos metodológicos Blue-WATCH y SCRUM Blue WATCH Modelado de Negocios - SCRUM Desarrollo de Requisitos Parte del Sprint 0 Diseño Arquitectónico Parte del Sprint 0 Desarrollo de Versiones - Desarrollo de Incrementos Programación & Integración - Pruebas - Entrega de la Aplicación Sprints Entrega del Producto Planificación del Proyecto Parte del Sprint 0 Planificación de la Versión Planificación del Incremento Seguimiento y Control del Proyecto - Gestión de Requisitos - Verificación y Validación Gestión de la Configuración - Gestión de Riesgos Planificación de Entregas Planificación del Sprint Revisión del Sprint - Retrospectiva - SCRUM Diario

13 Una diferencia importante en los dos marcos es la manera en que las iteraciones se llevan a cabo. En SCRUM, todas las actividades técnicas se ejecutan como parte de un sprint. Así, por ejemplo, en la práctica, las actividades iniciales de planificación del proyecto, especificación de requisitos y diseño arquitectónico se ejecutan durante una iteración inicial denominada Sprint Cero [24]. Las iteraciones, en Blue WATCH, difieren de SCRUM en dos sentidos. Primero, Blue- WATCH maneja dos tipos de iteraciones anidadas: ciclos de versión y ciclos de incremento. Segundo, el ciclo de versión organiza secuencialmente los procesos técnicos de Modelado del Negocio, Desarrollo de Requisitos y Diseño Arquitectónico y, seguidamente, inicia los ciclos de desarrollo de los incrementos de la versión. En cada ciclo de desarrollo de incrementos, se refina el modelo de negocios, el documento de requisitos y el diseño arquitectónico, antes de iniciar el desarrollo propiamente dicho del incremento. 4 El Marco Metodológico Integrado En esta sección se describe el resultado del proceso de integración de los marcos metodológicos Blue-WATCH y SCRUM. Para integrar estos marcos, se aplicó la estrategia de integración por combinación (estrategia E4 de la Fig. 5), descrita en la Sección previa. Se obtuvo como resultado un nuevo marco metodológico que combina e integra los aspectos de gestión de SCRUM con los aspectos técnicos y de soporte de Blue WATCH. 4.1 La estructura de procesos del Marco Metodológico Integrado La Figura 7 presenta la cadena de valor del marco de desarrollo integrado. Esta cadena contiene los procesos principales y los de soporte y los clasifica en tres grupos de procesos: técnicos, de gestión y de soporte. Los procesos técnicos se ubican en el tope de la cadena porque son los principales, los de gestión en el medio y los de soporte en la parte inferior. Modelado del Problema Desarrollo Inicial de Requisitos Diseño Inicial de la Aplicación Desarrollo de Incrementos Entrega Final de la Aplicación Gestión del Proyecto de Desarrollo de SW Gestión de Requisitos Verificación y/o Validación (V&V) de Productos Gestión de la Configuración del Software Gestión de Riesgos Fig. 7. La cadena de valor del marco integrado

14 La cadena de valor no establece el orden de ejecución de los procesos, pues sólo identifica los procesos y los relaciona. El orden en que estos procesos se deben ejecutar durante el desarrollo de una aplicación se indica en la Figura 8. Como es de esperar, un proyecto tiene siempre un inicio y se planifica antes de comenzar cualquier actividad técnica. Una vez se planifica, se emprende el Modelado del Negocio; así como, los procesos de Dirección, Seguimiento y Control del Proyecto y los procesos de soporte; los cuales se ejecutan en paralelo con los procesos técnicos y se mantienen activos a lo largo de todo el proyecto. Procesos Técnicos Modelado del Problema Desarrollo Inicial de Requisitos Diseño Inicial de la Aplicación Desarrollo de Incrementos Entrega Final de la Aplicación Procesos de Soporte Procesos de Gestión del Proyecto Inicio del Proyecto Inicio Planificación Inicial Planificación de Entregas Dirección del Proyecto Seguimiento y Control del Proyecto Gestión de Requisitos Verificación y/o Validación (V&V) de Productos Gestión de la Configuración del Software Gestión de Riesgos Cierre del Proyecto Fin Fig. 8. Orden de ejecución y relaciones entre los procesos del marco integrado Los tipos de productos, los roles requeridos y los detalles de los procesos del marco integrado se describen en las siguientes Secciones. 4.2 El Modelo de Productos El marco integrado clasifica los productos del desarrollo de software en dos grandes grupos (véase la Figura 9): Productos técnicos. Son todos aquellos productos intermedios y/o finales que se producen o deben producirse durante la ejecución de los procesos técnicos. Este grupo se considera el conjunto mínimo de productos que se deben elaborar durante el desarrollo de una aplicación, con la intención de alcanzar los objetivos siguientes: Garantizar que la aplicación tenga una calidad técnica aceptable y cumpla con todos los requisitos que se especifican durante el proceso de desarrollo. Garantizar una efectiva comunicación de ideas, diseños y descripciones de productos entre los diferentes miembros del Equipo de Desarrollo de la aplicación. Facilitar el mantenimiento de la aplicación mediante la entrega de productos debidamente documentados y actualizados.

15 Producto del Desarrollo de SW Producto Técnico Producto de Gestión y Soporte «informe_técnico» Descripción del Problema «informe_técnico» Documento de Requisitos «informe_técnico» Documento de Diseño «informe_técnico» Especificaciones de Pruebas «software» Prototipo de la Aplicación «software» Aplicación Visión del Producto Plan del Proyecto Solicitudes e Informes Fig. 9. Clasificación de los productos que el marco integrado recomienda Productos de gestión y soporte. En este grupo se ubican todos aquellos productos intermedios que son necesarios para una adecuada gestión del proyecto de desarrollo de software. Estos productos son necesarios para garantizar una gestión del proyecto efectiva. Su utilidad y propósito, por consiguiente, se asocia con la consecución de los objetivos siguientes: Garantizar que la aplicación se entregue a tiempo. Garantizar que su costo no exceda el presupuesto aprobado. Garantizar que cumpla con la calidad especificada. Garantizar que su alcance esté dentro de lo establecido al inicio del proyecto. Cada uno de los productos indicados en la Figura 9 tiene una estructura modular claramente definida con unos componentes que se agregan en función del tamaño del proyecto y la complejidad de la aplicación que se esté desarrollando. La Figura 10 muestra, a modo de ejemplo, la estructura que debe tener el producto de gestión denominado Plan del Proyecto. Este documento, al igual que los demás, contiene secciones que se elaboran mediante el agregado de modelos, diagramas, listas, tablas, etc., acompañados de su debida descripción textual. El uso de herramientas CASE simplifica la elaboración de la documentación técnica, pues la mayoría de ellas genera de modo automático documentos que organizan los modelos que se producen como parte de las actividades del desarrollo de software. El marco integrado promueve el uso de este tipo de herramientas, así como la elaboración y transformación automática de modelos mediante lenguajes estandarizados, tales como: UML y BPMN.

16 Plan del Proyecto * 0..* Plan Inicial del Proyecto Plan de Entregas Plan de Iteración «informe_soporte» Plan Suplementario «cronograma» Plan de Gestión del Alcance Cronograma del Proyecto «tabla» Presupuesto de Costos Plan de Gestión de RRHH Enunciado del Alcance del 1 Proyecto 1 «organigrama» Estructura Organizacional del Proyecto «modelo» Estructura de Desglose del 1 Trabajo (EDT) Fig. 10. Ejemplo de la estructura de uno de los productos del marco integrado 4.3 El Modelo de Actores El marco integrado promueve la especialización del equipo de desarrollo por medio de la definición de un conjunto de roles técnicos y de gestión que garantizan una distribución más conveniente y pertinente de las tareas entre los miembros del Equipo de Desarrollo. Estos roles se clasifican en tres grupos, tal como se muestra en la Figura 11. El primer grupo incluye aquellos interesados que promueven, impulsan o demanda el desarrollo de la aplicación. Los desarrolladores integran el segundo grupo, los cuales se especializan en función de las actividades técnicas y de gestión que un proyecto de desarrollo de software exige. Los usuarios constituyen el último grupo; un subgrupo de ellos conforma el rol de Representante de Usuarios que actúa de una manera similar al rol de Dueño del Producto que emplea SCRUM. El rol de Líder de Proyecto difiere del rol de Scrum Master que se usa en SCRUM. En todo proyecto mediano o grande, la figura de un líder o gerente de proyecto es esencial, pues representa al Equipo de Desarrollo, coordina sus actividades y tiene la responsabilidad de ejecutar procesos que son claves para garantizar el éxito del proyecto, tales como: la planificación, la dirección, el seguimiento y control del proyecto y la gestión de riesgos y de requisitos. 4.4 El Modelo de Procesos Los procesos y actividades del marco integrado se clasifican en tres grupos: Procesos técnicos. En esta categoría se agrupan todos los procesos y actividades relacionadas con el análisis, diseño, programación, pruebas y entrega de las aplicaciones. Procesos de gestión. Este grupo incluye todas aquellas actividades propias la gestión del proyecto, tales como: inicio, planificación, dirección, seguimiento, control y cierre del proyecto. El objetivo de este grupo de procesos es garantizar que la aplicación se

17 entregue a tiempo, bajo el presupuesto aprobado, con la calidad especificada y con el alcance establecido al inicio del proyecto. Interesado (Stakeholder) Promotor o Cliente Desarrollador Usuario Líder del Proyecto Analista Arquitecto - Diseñador Programador Experto en Pruebas Gestor de Soporte Representante de Usuarios Fig. 11. Clasificación de los actores (roles) requeridos Procesos de soporte. Esta categoría contiene procesos y actividades que apoyan la gestión del proyecto, en aquellos aspectos relacionado con el cambio y seguimiento de requisitos, el aseguramiento de la calidad del software, la verificación y validación de productos, la gestión de la configuración del software y la gestión de riesgos que puedan afectar el proyecto. Tal como se presenta en la Figura 12, el orden de ejecución de estos procesos es el resultado de la combinación de los modelos de procesos de Blue-WATCH y SCRUM. Diseño Detallado del Incremento Diseño de Pruebas del Incremento Refinamiento de Requisitos Codificación y Pruebas del Incremento Planificación de la Iteración [NO] Revisión del Incremento i > n? Inicio Inicio del Proyecto Planificación Inicial Modelado del Negocio Desarrollo Inicial de Requisitos Diseño Inicial de la Aplicación Planificación de Entregas i = 1 [SI] Entrega Final de la Aplicación Cierre del Proyecto Fin Fig. 12. Orden de ejecución de los procesos del marco integrado Este orden se puede apreciar mejor dividiendo los procesos en tres conjuntos: Conjunto inicial de procesos. Un proyecto se inicia con un conjunto secuencial de actividades de gestión (Inicio y Planificación Inicial); continua con actividades técnicas de carácter preliminar (Modelado del Negocio, Desarrollo Inicial de Requisitos y

18 Diseño Inicial de la Aplicación, que incluye el diseño de la arquitectura de la aplicación). El último proceso de este conjunto, denominado Planificación de Entregas, se encarga de determinar y definir las entregas, incrementos e iteraciones del siguiente conjunto de procesos. Conjunto de procesos iterativos. Estos procesos, ubicados en la parte superior de la Figura 12, se ejecutan repetidas veces, en un número que depende de la arquitectura de la aplicación y de su división funcional en incrementos. Un incremento de la aplicación se puede producir en una o más iteraciones con una duración fija (entre 1 y 6 semanas). Cada iteración se inicia con la planificación de sus actividades; continúa con el refinamiento de los requisitos y el diseño detallado del incremento; sigue con el diseño de las pruebas, la codificación de los programas del Incremento y su respectiva prueba; y culmina con una revisión técnica del incremento o de la porción de él que se produce durante la iteración. Cada incremento es un subconjunto funcional de la aplicación que, a discreción del usuario, se puede utilizar parcialmente. Conjunto final de procesos. El último incremento que se produce el conjunto de procesos iterativos es la aplicación misma, por lo que se procede a su entrega final y al cierre del proyecto. Los procesos del marco integrado se describen usando la notación de negocios del lenguaje UML [23] y el Método de Modelado de Negocios [25]. Cada proceso se descompone en un conjunto de procesos de menor nivel de abstracción Por ejemplo, el proceso de Planificación del Proyecto se descompone en los subprocesos: Planificación inicial (todo el proyecto), Planificación de Entregas (n entregas previstas y funcionales) y Planificación de la Iteración i (atendiendo a las n entregas); esta descomposición se representa en notación UML como se ilustra en la Figura 13. Planificación del Proyecto Planificación Inicial Planificación de Entregas (n entregas) Planificación de la Iteración i (i=1..n) Fig. 13. Descomposición de un proceso del marco integrado Cada proceso de bajo nivel, en la jerarquía de procesos resultantes de la descomposición, se describe como una caja negra que muestra las entradas, salidas, controles y recursos que el proceso requiere. En la Figura 14 se muestra un ejemplo de la descripción del proceso Planificación de la Iteración i. Este proceso tiene como objetivo Programar las actividades de desarrollo del incremento de la aplicación correspondiente a la iteración i. Para lograrlo requiere como entradas tres elementos que entregan los procesos previos: el Plan del Proyecto, la Pila de Historias del usuario y el Plan de Entregas. Además, produce como salidas: el Plan de Iteración, la Pila de historias Actualizada y el Plan del Proyecto Actualizado. El Equipo de Desarrollo ejecuta las actividades de este proceso, las cuales el Líder del Proyecto supervisa y contro-

19 la. Finalmente, se indican las normativas que regulan la actividad, las prácticas previstas y las herramientas de soporte que apoyan la ejecución de tales actividades. «regla del negocio» Plan del Proyecto, Planes Suplementarios, Normativ a de Desarrollo de SW «objetivo» Programar las activ idades de desarrollo del incremento de la aplicación correspondiente a la iteración i Líder del Proyecto «regula» «controla» «persigue» :Plan de Entregas Planificación de la Iteración i (i=1..n) Plan de la Iteración i «lista enumerada» :Pila de Historias de Usuario «lista enumerada» actualizada :Pila de Historias de Usuario :Plan del Proyecto actualizado :Plan del Proyecto «ejecuta» «apoya» «apoya» Equipo de Desarrollo «recurso» :Métodos, técnicas y prácticas de gestión de proyectos «recurso» :Herramientas para gestión de proyectos Fig. 14. Descripción de un proceso del marco integrado 4.5 Instanciación del marco integrado Teniendo en cuenta los niveles de abstracción presentados en la Sección 3, un marco metodológico difiere de un método en el nivel de detalle y en el grado de especialización u orientación hacia tipos particulares de aplicaciones. El principal uso de un marco metodológico es servir de base para la creación de familias o suites de métodos que comparten una base conceptual y metodológica común. El proceso de creación de un método, a partir de un marco metodológico dado, se denomina instanciación o especialización (véase la Figura 4). La instanciación del marco integrado, que se presenta en esta Sección, conlleva un conjunto de actividades que involucran el refinamiento, la adaptación, la ampliación o la modificación de los componentes o elementos que integran el marco. Este proceso se describe en detalle en [7] y se resume a continuación: Definición de los objetivos del nuevo método. Caracterización del tipo de aplicaciones que se desarrollarán usando el método. Definición de los requisitos del método. Especialización del Modelo de Productos del marco integrado. Especialización del Modelo de Actores del marco integrado. Especialización del Modelo de Procesos del marco integrado. Verificación técnica del método resultante. Validación del método por medio de un proyecto piloto. Es importante aclarar que la exposición en detalle y la ilustración del proceso de instanciación del marco integrado descrito, escapan al alcance de este Capítulo.

20 5 Conclusiones y Trabajo Futuro En este Capítulo se presentó un marco metodológico integrado resultante de la composición coherente y complementaria de conceptos provenientes de dos marcos metodológicos ampliamente utilizados para guiar el desarrollo de productos de software: Blue-WATCH y SCRUM. El proceso de integración se realiza teniendo en cuenta los conceptos básicos de la ingeniería de métodos, mediante la especificación de niveles de abstracción y la ubicación de los marcos metodológicos en dichos niveles. Así, se destaca que el marco integrado resultante se puede adaptar para definir nuevas variantes de método que se ajusten a productos/proyectos particulares en organizaciones donde se desea establecer procesos de desarrollo balanceados; considerando los niveles de abstracción explicados en la Sección 3 de este Capítulo. El proceso de integración se especificó con mapas intencionales de rutas, permitiendo su fácil utilización y reutilización para integrar éste con otros marcos metodológicos de desarrollo de software. Los aportes de este trabajo se resumen en: (1) la propuesta de un marco metodológico de desarrollo de software menos pesado y más ajustado a la realidad de las empresas latinoamericanas, donde la agilidad y la documentación mínima son fundamentales para garantizar la productividad del personal y la facilidad de mantenimiento de los productos de software desarrollados; (2) la especificación intencional del proceso de integración de marcos metodológicos, que organizaciones de software particulares pueden repetir, instanciar y/o adaptar para producir otros marcos metodológicos que atiendan requisitos de producto/proyecto específicos. Como un potencial y futuro aporte de este trabajo, el marco metodológico, mediante sus modelos de producto, proceso y actores, servirá de base para definir nuevas variantes de método caracterizadas según contextos particulares de desarrollo empresariales. Estas variantes son vistas como especializaciones de cada uno de los correspondientes conjuntos de conceptos provistos en el marco. Actualmente, los componentes del marco integrado presentado en este Capítulo se instancian y especializan en dos proyectos pilotos que realizan empresas venezolanas, para elaborar métodos de desarrollo de software adaptados a las características particulares de sus respectivas organizaciones, tales como: cultura organizacional, tipos de aplicaciones que producen, tamaño promedio de los equipos de desarrollo y de las aplicaciones, entre otras. Los resultados de esta instanciación se evaluarán y reportarán como parte del trabajo de investigación futuro, el cual se concentrará en la evaluación del marco como referencia y punto de partida para definir métodos de desarrollo de software balanceados y disciplinados, ajustados a los requisitos de las empresas de software en el contexto venezolano y latinoamericano. Igualmente, se contempla como trabajo futuro, la validación y extensión del mapa intencional de integración con otras estrategias de composición e integración de conceptos de desarrollo al más alto nivel de abstracción. Agradecimientos El Fondo Nacional de Investigaciones Científicas y Tecnológicas (FONACIT) de Venezuela y la empresa BIOSOFT C.A. ( financian este trabajo bajo el número G