Planificación y organización de proyectos dirigidos por la arquitectura
Anuncio
Planificación y Organización de Proyectos dirigidas por la Arquitectura M.C. Mariel Feder Laboratorio de Ingeniería de Software. Universidad ORT Uruguay. Dirección postal: Universidad ORT Uruguay Facultad de Ingeniería ORT Software Factory Cuareim 1451 11100 Montevideo, Uruguay. Teléfono +598 +2 9021505 Dirección electrónica: [email protected] Resumen Gestionar un proyecto de software, consiste en asegurar que se entregará un producto que cumpla con las especificaciones dentro del plazo y costo acordados, con el nivel de calidad pactado. Factores clave para lograrlo son la planificación y organización adecuadas del proyecto. Por otra parte, la definición de la arquitectura del producto a desarrollar tiene un impacto muy importante no sólamente en el producto final del que es base, sino que también debería influir en la forma en que el proyecto se enfoca desde el punto de vista de su gestión, facilitando así la integración de las disciplinas técnicas y gerenciales que deben interactuar en todo proyecto exitoso. El objetivo del presente trabajo es analizar la fase de planificación y organización del proyecto y ver cómo la misma se ve afectada por la arquitectura, o mejor dicho, se ve pautada por ésta en forma natural, en lo que se podría denominar “planificación y organización dirigidas por la arquitectura”. Palabras claves Ingeniería de Software, Gestión de Proyectos, Arquitectura de Software, Planificación, Organización. 1. INTRODUCCIÓN 1.1. Qué es la Gestión de Proyectos Gestionar un proyecto consiste en asegurar que se entregará un producto que cumpla con las especificaciones dentro del plazo y costo acordados, con el nivel de calidad pactadoi. Generalmente, los proyectos de software se desarrollan en un mundo de naturaleza cambiante, lo que implica un nivel importante de incertidumbre relacionada a aspectos tales como recursos humanos, tecnología o de negocio. Las actividades involucradas en la gestión de un proyecto van variando a lo largo del proceso de desarrollo del ciclo de vida del proyecto1 en relación directa con el proceso de desarrollo utilizado.ii Más allá de las particularidades de los proyectos individuales, en su gran mayoría los proyectos evolucionan según el siguiente ciclo de vida: Inicialización: Es el momento en que se reconoce que un proyecto puede comenzar y se consiguen los compromisos para hacerlo. Las principales actividades de esta fase son: - Análisis de las consecuencias de realizar (o no realizar) el proyecto. - Definición de las magnitudes necesarias para completarlo.2 - Análisis de alternativas - Análisis técnicos tales como análisis de viabilidad, materiales disponibles, recursos geotécnicos, urbanísticos, de impacto ambiental, etc., dependiendo de la naturaleza del proyecto. - Análisis de la inversión, volumen, valor presente, rentabilidad futura. - Análisis costo/beneficio, incluyendo costos sociales, beneficios no monetarios, etc. - Análisis de riesgo, con la información de que se dispone hasta el momento.3 Planificación y Organización: Confeccionar y mantener un esquema de trabajo que permita alcanzar el objetivo. Es en esta etapa en la que se identifican las tareas, se estiman tiempos y costos, se conforman los equipos, se asignan los recursos (humanos y otros) y se elabora el plan de trabajo. Debe señalarse que este no es el único momento del proyecto en que se realizan tareas de organización y planificación. Generalmente, la organización y planificación iniciales del proyecto se realizan con un alto nivel de abstracción, por lo que luego se repite la actividad para definir estos elementos con un nivel mayor de detalle a medida que se va avanzando en el proyecto. Producción o Implementación: Durante esta fase se realizan tres grandes actividades: Administración: coordinación de personas y recursos para llevar adelante el plan Ejecución: la propia realización de las tareas que generan el producto Control: Controles para asegurar que los objetivos del proyecto son alcanzados, mediante monitoreo y medición de avance, tomando las acciones correctivas que correspondan. Este seguimiento permite retroalimentar la planificación, por lo que se vuelve un proceso abierto y cíclico. Estas mediciones se realizan tanto del proyecto como de las características del producto que se va generando. Cierre: Formalización de la aceptación del proyecto y realización del fin de actividades en forma ordenada. Se da por concluido el proyecto y se obtiene el producto final. La información obtenida se almacena y se evalúan los resultados. 1 Me refiero al Ciclo de Vida del proyecto a diferencia del Ciclo de vida del desarrollo del producto que se explicará más adelante. 2 Nótese el uso del término magnitud en lugar de valor, ya que en este momento se pretende una aproximación que refleje el orden de magnitud de los elementos a estimar. 3 Volveré sobre este tema más adelante. Planificación general Planificación específica Administración Retroalimentación Ejecución Inicio Planificación Control Producción Etapas en la gestión de un proyecto 1.2. Qué es la Arquitectura del Software La arquitectura de software es una disciplina relativamente joven, por lo que no existe aún una definición del término única y ampliamente aceptada. No es el objetivo del presente trabajo adentrarnos en este tipo de discusión filosófica, ya que si bien las distintas definiciones formales aún pugnan entre sí en el mundo académico, el concepto que está detrás es básicamente similar entre todas ellas. Tomaré como definición la propuesta por Bass, Clements y Kazman: La arquitectura de un programa o sistema de computación es la estructura o estructuras del sistema, que comprenden sus componentes de software, las propiedades externas de los componentes, y la relación entre ellosiii, que coincide con la propuesta por Soni, Nord y Hofmeisteriv 1.3. Ciclo de vida del desarrollo del producto El ciclo de vida es una vista del orden de las actividades que ocurren durante el desarrollo. Así, el software progresa desde una idea inicial a través de su implementación, uso y eventualmente su muertev. Un ciclo de vida describe las principales fases del desarrollo y las principales actividades que se espera se realicen durante estas fases. Ayuda a los gerentes a realizar el seguimiento del proyecto y provee de un marco para la definición del proceso de desarrollo detallado. Cascada El primer ciclo de vida, la cascada fue definido por Winston Roycevi en los comienzos de los años 70. Desde entonces, muchos equipos de desarrollo han seguido este modelo. En los últimos 10 o 15 años la cascada ha sido muy criticada por ser considerada muy rígida para el desarrollo de los proyectos de software modernos. El modelo es muy simple, y considera al desarrollo como una secuencia de fases que no se repite. Cada fase tiene un conjunto definido de objetivos, y las actividades de una fase se realizan para la consecución de los mismos. Las normas de la cascada son básicas: Requerimientos Requerimientos Arquitectura Arquitectura Diseño Diseño Codificación y testing unitario Integración Ciclo de vida en Cascada Operación y Mantenminiento Diseño Codificación y testing unitario Integración Operación Codificación y testing unitario Integración Operació Ciclo de vida de desarrollo incremental • • • • • Planificar el proyecto antes de comenzar Definir el comportamiento externo esperado del sistema antes de definir su funcionamiento interno. Documentar los resultados de cada actividad Diseñar el sistema antes de codificarlo Testear el sistema una vez que está construido. Desarrollo incremental Los riesgos asociados con sistemas grandes y complejos son muy altos. Una forma de reducir el riesgo es construyendo solamente una parte del sistema y reservar el resto para sucesivas liberaciones. El desarrollo incrementalvii plantea la construcción de partes del sistema en forma secuencial, de forma de ir liberando y probando versiones en forma paulatina. Generalmente, se parte de la lista de requerimientos de todo el sistema y de una definición de la arquitectura de alto nivel que contempla todos estos requerimientos, y luego se divide la funcionalidad en grupos que se van diseñando, implementado, testeando e integrando uno a uno. Modelo Evolutivo Como el desarrollo incremental, el modelo evolutivoviii construye una serie sucesiva de versiones incluyendo en cada una de ellas más funcionalidad que en la anterior, hasta completar el sistema. La diferencia es que no se conocen a priori todos los requerimientos, sino que los mismos se van descubriendo en cada una de las evoluciones. Por lo tanto, tampoco existe una arquitectura de alto nivel definida desde el principio, sino que la misma va evolucionando hacia la arquitectura final. En este modelo, los requerimientos son analizados, y sólamente se implementan aquellos que se entienden completamente. El sistema es implantado, los usuarios lo utilizan y retroalimentan al equipo de desarrollo. En base a esta retroalimentación se actualizan los requerimientos y comienza el desarrollo de la versión siguiente y así sucesivamente. Requerimientos Requerimientos Diseño Diseño Codificación y testing unitario Codificación y testing unitario Integración Operación Integración Operación Ciclo de Vida Evolutivo Otros modelos El modelo de prototipaciónix de requerimientos implica la creación de una implementación parcial del sistema con el propósito de aprender sobre los requerimientos. El prototipo se construye lo más rápido posible y luego los usuarios o quien corresponda experimenta con el prototipo y retroalimenta al equipo que puede así especificar correctamente los requerimientos. Este modelo puede combinarse con cualquiera de los anteriores, incluyendo la tarea de prototipación y validación del prototipo como parte de las fases de requerimientos. La prototipación se utilizó mucho en los años 90 porque la especificación de requerimientos de sistemas complejos suele ser difícil de entender, y es más fácil para quien debe validar los requerimientos manipular un prototipo en lugar de leer un documento tedioso y potencialmente ambiguo. El modelo de espiral de Boehmx, es un meta ciclo de vida. En este modelo, el esfuerzo del desarrollo es iterativo y guiado por el riesgo. Antes de cada vuelta en la espiral, se realiza un análisis de riesgo y se analizan las alternativas. Es adecuado para proyectos de alto riesgo. Sin embargo, dentro de la espiral puede incluirse cualquiera de los ciclos de vida anteriores, y según el que se elija para esto, se configurarán las diferentes tareas de cada vuelta de la espiral. El modelo concurrente también es una meta descripción del proceso. Provee un mecanismo para mostrar las actividades concurrentes. También puede combinarse con cualquiera de los ciclos de vida mencionados. 2. CICLO DE VIDA PARA LA GESTIÓN DIRIGIDA POR LA ARQUITECTURA Algunos autoresxi sostienen que en los últimos 10 años ha habido una concientización general sobre la importancia de describir la arquitectura del software antes de implementar el producto. Si bien existen otras alternativas, como el modelo evolutivo, a mi criterio igualmente válidas en determinadas circunstancias, este requerimiento es necesario, si se desea realizar la gestión del proyecto basada en la arquitectura. En los casos donde se utilizan los ciclos de vida en los que se define la arquitectura de alto nivel al comienzo (cascada o desarrollo incremental), es posible aplicar estos principios de gestión en forma completa, mientras que en los modelos evolutivos es posible hacerlo en forma parcial, aplicando los conceptos a cada una de las evoluciones. 3. PLANIFICACIÓN DEL PROYECTO Los proyectos bien gestionados generalmente comienzan como proyectos bien planificados. En la gestión de proyectos dirigida por la arquitectura, el momento de realizar la planificación y organización del proyecto es en paralelo con la definición de la arquitectura de alto nivel, no antes. Se debe resistir la presión externa de divulgar estimaciones y planificaciones no confiables para no comprometerse a metas que luego no podrán cumplirse. Es bien sabido que las estimaciones de esfuerzo y cronograma realizadas en etapas muy tempranas del proceso de desarrollo de software suelen ser muy imprecisas. xii xiii Es muy difícil confeccionar un cronograma viable, identificar metas intermedias y puntos de control antes de contar con una arquitectura de alto nivel. Una vez que la arquitectura está completa, es posible crear un plan de proyecto, un cronograma, organizar el staff y los equipos, todos factores que dependen de la arquitectura delineada. 3.1 Estimación Paulishxiv sugiere el siguiente proceso: Comenzar el proyecto con un pequeño equipo de diseñadores que crearán la arquitectura de alto nivel. En paralelo, utilizar mecanismos de estimación top-down para estimar el total del proyecto tales como Puntos Función de Albrecht, Cocomo de Boehm, SLIM, PRICE-S, etc., siendo el gerente de proyecto el responsable de esta tarea. Los componentes identificados en la arquitectura de software se convierten en las unidades para la estimación bottom-up. Estos componentes se deben identificar en el diseño lógico del sistema, donde se identifican los subsistemas o componentes de alto nivel de abstracción, en la vista lógica propuesta en el modelo 4+1 de Krutchenxv o su equivalente si se usa otro modelo para representar la arquitectura. El arquitecto o los líderes del equipo de diseño deben ser los responsables de la estimación bottomup ya que son quienes conocen la naturaleza y complejidad de cada una de las unidades. Luego el gerente de proyecto debe integrar ambas estimaciones, comparando la suma de la estimación de las unidades contra la estimación top-down y tratar de encontrar el punto de equilibrio. En general, la estimación bottom-up es más precisa en relación a cada uno de los componentes, pero suelen olvidarse otras actividades que no forman parte del desarrollo de las unidades aisladas, tales como las actividades de aseguramiento de la calidad (SQA), de integración, test del sistema, documentación de usuarios, comunicación, etc. Estos elementos sí suelen estar incorporados en las estimaciones top-down Si bien es posible que existan diferencias entre ambas estimaciones debido a estos factores, ambas deberían ser razonablemente compatible. De lo contrario debería revisarse el proceso de estimación. En general lo que no debe hacerse es aceptar estimaciones top-down menores que la suma de las unidades, ya que esta última incluye más actividades y no menos. Considerando estos aspectos, y una vez obtenidas dos estimaciones compatibles, sugiero como mecanismo de integración, considerar el total de la estimación top-down, y las proporciones entre las unidades que surgen de la estimación bottom-up. 3.2 Análisis de Riesgo Como manifesté al comienzo, los proyectos de software suelen ir acompañados de niveles importantes de incertidumbre. Esta incertidumbre se traduce en riesgos, que son probables efectos adversos o problemas que se pueden encontrar durante el desarrollo del proyecto. La gestión del riesgo es una tarea propia del gerente del proyecto y se define como la función ejecutiva que se encarga de mantener bajo control los factores negativos mencionados de forma que estos no hipotequen el éxito del proyecto. 3.2.1 Proceso de gestión de riesgos La gestión del riesgo se realiza siguiendo un proceso bien definido que implica xvi xvii: Identificación: Existen diferentes mecanismos para la identificación y ponderación de los riesgos tales como check lists, taxonomías (conocimientos transmitidos por terceros, ej. Karolak xviii), analogía con casos conocidos, aplicación del sentido común, resultados de experimentos entre otras. Análisis: Una vez identificados, es necesario ponderarlos en lo que refiere a su probabilidad de ocurrencia y su impacto en el proyecto, de forma de encontrar los más importantes y gestionar sólamente aquellos que puedan llegar a afectar significativamente el proyecto. Este es el momento de decidir no continuar con el proyecto si el mismo es demasiado riesgoso, dependiendo de la cultura de riesgo de la organización. Planificación: Frente a los riesgos identificados, se puede decidir asumirlos, es decir, no tomar ninguna acción para evitar que sucedan o que afecten al proyecto o mitigarlos. Mitigar un riesgo significa realizar acciones para disminuir su probabilidad o su impacto, denominadas acciones preventivas. Las acciones preventivas se transforman en tareas a realizar que deben ser incluidas en el cronograma y en la planificación del proyecto (ejemplo: realizar prototipo de comunicación de las plataformas); o en decisiones de gestión o de negocio (ejemplo: incrementar en un 20% el precio de la propuesta para cubrir posibles pérdidas identificadas). Los riesgos asumidos siempre pueden materializarse. Debe tenerse en cuenta que también pueden hacerlo aquellos que trataron de mitigarse, si las acciones preventivas no fueron exitosas, o quizás hacerlo con un impacto menor. En ambos casos, debe planificarse un conjunto de acciones correctivas o planes de contingencia en los que se establece cómo reaccionar frente al problema previsto si este sucede. Ejemplos interesantes de planes de contingencia se vieron en muchas organizaciones durante el cambio de siglo. Seguimiento: Periódicamente se realiza un seguimiento de la evolución de los riesgos en base a indicadores definidos y una evaluación de las actividades de prevención realizadas. Además, debe monitorearse constantemente la aparición de nuevos riesgos que surgen durante el desarrollo del proyecto. Evaluación: Al fin del proyecto se realiza una evaluación de la gestión de riesgos y sus resultados de forma de extrapolar la experiencia obtenida a otros proyectos. En caso de haberla, es el momento de alimentar la base de datos de conocimiento de la organización. Identificación Análisis Planificación Seguimiento Ciclo de gestión de Riesgo Evaluación 3.2.2 Análisis de riesgo y arquitectura del Software La arquitectura de software es una entrada muy importante para el proceso de análisis de riesgo. Los riesgos técnicosxix suelen ser un porcentaje importante en los riesgos inherentes al desarrollo de productos de software y la fuente para identificarlos es el documento de arquitectura, ya que es allí donde se especifican las decisiones técnicas tomadas y los paquetes que deben desarrollarse. Por lo tanto, el documento de arquitectura debe ser un origen que no se puede pasar por alto en la fase de identificación de los riesgos. Recomiendo no dejar de analizar los siguientes factores, aunque lo que se presenta no es una lista exhaustiva: • Experiencia de los equipos de desarrollo en las plataformas, lenguajes y herramientas seleccionadas • Estabilidad de las herramientas y plataformas • Disponibilidad de las herramientas y plataformas • Integrabilidad de las plataformas seleccionadas • Interoperabilidad entre los componentes diseñados • Nivel de complejidad, testeabilidad y acoplamiento de los componentes • Identificación de los componentes críticos ya sea por su importancia para el funcionamiento del producto o por su complejidad. • Atributos de calidad requeridos que resulten críticos para el producto (ej.: performance, seguridad, amigabilidad, etc.) y que la arquitectura debe garantizar xx xxi xxii xxiii. Del análisis de la arquitectura del software propuesto surgen entonces una serie de riesgos que deben ser incluidos en el análisis de riesgo. Por supuesto que esta identificación no puede ser realizada por el gerente de proyecto solamente sino que deberá hacerlo en conjunto con el arquitecto. Los riesgos que se identifiquen a partir de la arquitectura, también deben ser ponderados y planificados al igual que los riesgos que surgen de otras fuentes. En algunos casos, se transformarán en actividades preventivas simples (ejemplo: capacitación en alguna herramienta, prototipación de algún componente), en otros casos impactarán en las decisiones de gestión o del propio proceso de desarrollo (ejemplo: incorporación de una fase de beta testing), pueden influir en el cronograma en lo que respecta a la secuencia en que los paquetes o componentes serán desarrollados4, o incluso pueden transformase en decisiones que modifiquen la arquitectura planteada inicialmente (ejemplo: cambio de plataforma), por lo que es necesario volver a analizar los riesgos que la nueva arquitectura plantea, transformándose el proceso en un ciclo. 3.3 Plan de Versiones En general, y más especialmente para los proyectos de mayor porte, no es posible ni razonable desarrollar todos los componentes y funcionalidades simultáneamente. Existen por lo tanto, desarrollos en paralelo pero también en secuencia, independientemente del ciclo de vida elegido, ya que lo afirmado es cierto incluso para los ciclos de vida en cascada. Se vuelve entonces importante identificar los componentes o paquetes que deben ser desarrollados para luego determinar el orden en que se hará. En estas secuencias, se suelen definir puntos intermedios de control, que permitan subdividir el proyecto, dando la posibilidad de establecer objetivos a corto plazo. Esto es necesario para darle al gerente puntos visibles donde medir el avance del proyecto y poder tomar acciones en caso de desviaciones. En particular, para los proyectos que evolucionan en versiones (ciclos de vida iterativos o evolutivos), en estos hitos se suele incluir una versión del sistema con el desarrollo completo de un grupo funcional que compone una versión del sistema, de donde surge el nombre de “plan de versiones”. En estos planes se identifican versiones pre-release, que son internas al proyecto, y versiones release o liberaciones, que son las versiones que se van entregando al cliente durante el desarrollo del producto. Para el caso del ciclo de vida en cascada, existirá una sola versión release al final del desarrollo. El documento de arquitectura y el análisis de riesgo, además de los acuerdos con el cliente o las necesidades del mercado, deben ser las entradas a considerar para la confección del plan de versiones. Suelo identificar los siguientes criterios utilizados para establecer el orden y contenido de las versiones: Dirigido por el riesgo: Se desarrollan primero los componentes o funciones de mayor riesgo, para encontrar las dificultades lo antes posible, y evitar así sorpresas luego de haber realizado una inversión mayor en el proyecto o de haber tomado una serie de decisiones sobre las que ya se ha recorrido un buen trecho. Dirigido por las necesidades del usuario/mercado: Se incluyen primero las funcionalidades más urgentes según el criterio del usuario o cliente, y es este quien fija las prioridades que luego pautan la definición de las versiones a liberar. Secuencia lógica: Se realizan primero las funciones o componentes necesarios para el funcionamiento de otras funciones o componentes, es decir las funciones o componentes invocados por otras funciones o componentes de más alto nivel, evitando así el uso de stubs5 que exigen un mayor esfuerzo de testing cuando se sustituyen por los verdaderos componentes. Dirigido por la capacitación: En algunos casos donde los desarrolladores no están familiarizados con las herramientas a utilizar, se suelen desarrollar primero las funciones o componentes más sencillos para ir aprendiendo el uso de la herramienta e ir progresivamente enfrentando opciones más complejas. 4 5 Ver capítulo Plan de Versiones Stubs: Funciones o rutinas vacías, que únicamente implementan la interfase y generalmente devuelven valores fijos, para que se puedan compilar y probar las funciones o rutinas que las invocan mientras no se hayan desarrollado las verdaderas funciones o rutinas a invocar. Los stubs son temporales y luego se reemplazan por las verdaderas funciones cuando estas son implementadas. Combinación: Como en tantos otros aspectos, en general no se utiliza solo uno de los criterios sino que es posible utilizar opciones híbridas para distintos momentos en diferentes partes del producto. La arquitectura del software es una entrada fundamental a la hora de confeccionar el plan de versiones. En primer lugar, identifica los componentes que habrán de ser distribuidos a lo largo de las versiones e identifica qué funcionalidad o requerimiento del usuario dicho componente implementa (o colabora en su implementación). De esta forma, es posible identificar qué paquetes o componentes es necesario desarrollar para poder incluir cierta funcionalidad en una versión, y aplicar el criterio dirigido por el usuario. Por otra parte, también es de la arquitectura desde donde se identifican los componentes más críticos, los más complejos y los más importantes para el sistema en caso de utilizar el criterio dirigido por el riesgo, o el nivel de prestación de servicios entre componentes para aplicar el criterio de secuencia lógica. Como la arquitectura es el documento donde es posible identificar los componentes más críticos o complejos del software, ésta no sólo debe utilizarse para la confección del plan de versiones, sino también para la definición de las estrategias de pruebas e integración. 3.4 Recursos Humanos Una actividad crucial para el éxito de un proyecto de desarrollo de software es el reclutamiento, capacitación y organización en equipos de los recursos humanos. No está dentro del alcance del presente trabajo analizar las estrategias de reclutamiento o capacitación, ni la necesidad de trabajar en equipos en el desarrollo de software, concepto que ya está arraigado en la industria xxiv xxv. En cuanto al reclutamiento, la arquitectura permite ver claramente los distintos perfiles que serán necesarios en el proyecto, así como los diferentes conocimientos técnicos que se requerirán. Por ejemplo, en un sistema que utiliza fuertemente bases de datos, se puede deducir la necesidad de contar con un equipo con conocimiento de diseño y administración de base de datos. Lo mismo aplica para las distintas plataformas, lenguajes o herramientas que se identifican. De la arquitectura por lo tanto, surgen los distintos perfiles técnicos con los que se habrá de contar para el desarrollo del producto, criterios que deben marcar el reclutamiento de nuevo personal o plasmarse en planes de capacitación para el personal existente. Una vez seleccionados los perfiles, es necesario organizar los equipos. La arquitectura puede ser la base para la organización de los equipos, destacándose dos alternativas: en forma vertical y horizontal. 3.4.1 Organización horizontal Para los sistemas diseñados en capas o para aquellos con componentes funcionales claramente diferenciados, es posible tener equipos asignados a cada uno de estas capas o paquetes. Por ejemplo, para un sistema en capas (interfase de usuario, dominio y persistencia), podría existir un equipo para cada una de ellas. O en un sistema de operación de una red compuesta por paquetes para la representación geográfica de la red en forma visual, paquetes para la manipulación de los nodos de la red y paquetes para interacción con dispositivos de telecontrol, cada equipo podría especializarse en uno de estos paquetes. La ventaja de esta organización es que cada uno de los equipos se vuelve un experto en el paquete o capa en la que está trabajando. Además, como sólo un equipo trabaja en una capa o componente, el mismo es diseñado e implementado siguiendo siempre el mismo criterio, con lo que se logra que sea más uniforme y estandarizado. Como desventajas, es necesario tener varios equipos trabajando simultáneamente para realizar las porciones de todas las capas o paquetes necesarios para implementar una versión. Además, los equipos tienen una vista parcial del sistema y es más difícil encontrar luego desarrolladores con una visión general del sistema para las fases de mantenimiento, en caso de que se desee reducir los equipos que participarán en esta etapa Capa/componente 3 Equipo 3 Equipo 1 Equipo 2 Equipo 3 Capa/componente 3 Equipo 2 Capa/componente 2 Capa/componente 2 Equipo 1 Capa/componente 1 Organización de equipos horizontal Capa/componente 1 Organización de equipos vertical 3.4.2 Organización vertical La organización vertical implica la división del sistema en grupos funcionales o subsistemas que atraviesan varias capas o componentes. Se forman equipos para cada uno de estos subsistemas o grupos funcionales, que trabajarán en todas las capas o componentes necesarios. Una de las ventajas es que es posible llegar a desarrollar las sucesivas versiones de un producto con un solo equipo trabajando, simplemente serializando los grupos funcionales o subsistemas en varias versiones (condicionado por el tamaño del proyecto). Otra ventaja es que se evitan los problemas de comunicación entre los equipos de distintos paquetes o capas que deben comunicarse o prestarse servicios mutuamente. Si bien esto puede representar una ventaja, también puede incorporar un problema colateral si al conocer el equipo el funcionamiento interno de la capa que provee los servicios, viola el encapsulamiento y accede directamente a las capas subyacentes, lo que no es tan probable que suceda cuando esta fue desarrollada por otro equipo y no se conocen sus detalles de diseño o implementación. En tercer lugar, los desarrolladores de los distintos grupos funcionales tienen una visión más completa de la funcionalidad en la que están trabajando, ya que participaron del diseño y la implementación de todos los componentes involucrados, en contraposición con la otra posibilidad. Como desventaja, si varios equipos trabajan en una misma capa o componente, puede que los mismos no resulten lo cohesivos que debieran ser, que exista redundancia (funciones implementadas varias veces), o que no se apliquen los mismos criterios frente a alternativas similares. En mi opinión, en proyectos de cierta magnitud donde se dispone del personal suficiente para armar los equipos necesarios, es preferible la organización horizontal, ya que se logran paquetes más cohesivos y optimizados y menos acoplados. Además, debido a la no duplicación de esfuerzo para desarrollar funcionalidades o servicios similares, se disminuye el esfuerzo de desarrollo. Por otra parte al tener un equipo responsable de cada componente en particular, en caso de algún problema o falla, es fácilmente identificable cuál es el equipo que tiene un conocimiento integral del paquete para localizarla y solucionarla. En proyectos de gran porte, es posible utilizar combinaciones de ambos enfoques donde corresponda, definiendo equipos verticales y sub-equipos horizontales o viceversa, según surja de la arquitectura definida. A la hora de configurar los equipos, es importante que en cada equipo se incluya alguno de los participantes del diseño de la arquitectura, generalmente estos suelen ocupar el rol de jefe de equipo. Ellos tienen un conocimiento más profundo de la arquitectura que ayudaron a definir y de los motivos por los que se tomaron las decisiones, por lo que su visión no se concentra en el paquete a desarrollar, visión que pueden transmitir al resto del equipo. Además, están en mejores condiciones de tomar decisiones con respecto a un componente en particular, pues conocen mejor sus repercusiones en el resto del sistema. Por otro lado, participaron en el proceso de estimación bottom-up de los componentes, por lo que se encuentran comprometidos con esta planificación, compromiso que deben cumplir como jefes de equipo por el que son responsables. 3.5 Cronograma Las herramientas para representar cronogramas que se utilizan hoy en día, generalmente permiten agrupar y desagrupar las tareas en distintos niveles de abstracción, por lo que ofician también de WBS (Work Breakdown Structure).6 Por lo tanto, se mencionarán en forma indistinta las formas de organizar el cronograma y la WBS, ya que ambas se representan en forma conjunta. Las alternativas a la hora de organizar una WBS o un cronograma siguen diferentes criterios xxvi: Orientada a la fase: Permiten identificar las fases del desarrollo. Se divide el sistema primero en grandes fases, luego dentro de las fases se detallan las tareas particulares. Orientadas al producto: Permiten identificar los componentes. Se descompone el producto en partes y luego se representan las tareas para realizar cada una de las partes del producto. Orientadas a la función: Se organizan según los distintos actores del sistema Existen alternativas híbridas que permiten mezclar los dos criterios para distintas partes o diferentes momentos en el desarrollo del producto. La forma más útil de representar el cronograma es que el mismo se parezca lo más posible al ciclo de vida. Por ejemplo para los ciclos de vida iterativos o evolutivos, resulta muy conveniente que el mismo refleje directamente el plan de versiones. De esta forma, se contarán con grandes tareas que representan cada una de las versiones, que a su vez se descompondrán en tareas concretas para alcanzar estas metas. De esta forma, es posible acceder al nivel de detalle de la fase o tarea del ciclo de vida que se está ejecutando en este momento (por ejemplo, la iteración que genera la versión X del producto), y manejar el resto del proyecto con un nivel de abstracción mayor. Por otra parte, los hitos o mojones que marcan el fin de cada una de las fases identificadas en el ciclo de vida, se corresponden con el fin de las tareas de mayor nivel de abstracción del cronograma, que son a su vez el primer nivel de la WBS asociada. Una vez definida la estructura del cronograma deben planificarse las distintas iteraciones y dentro de cada una de ellas deben identificarse los componentes sobre los que se va a trabajar y los recursos que se asignarán a dichas tareas xxvii. 6 WBS= Work Breakdown Structure: Representación gráfica en forma de árbol donde se subdividen grandes tareas en tareas más concretas en forma recursiva, de forma de obtener unidades más manejables que puedan ser estimadas y asignadas a los responsables de ejecutarlas. Permite acceder a representaciones de distinto nivel de agregación para obtener vistas con distinto nivel de abstracción. Id 1 Nombre de tarea Ing. 'Requerimient os 2 Arquitectura 3 Version pre-release 1 4 Componente 1 5 Componente 2 6 Integración 7 Fin 8 Version release 2 9 Componente 4 10 Componente 5 11 Componente 6 12 Componente 7 13 Integración 14 15 Fin F enero P M F f ebrero P M F marzo P M F abril P M F may o P M F junio P M F julio P M F agosto P M F septiembre P M F octubre P M F nov iembre P M F diciembre P M F enero P M 26/06 30/08 Version pre-release 3 Para esto deben considerarse factores como: • Estimación del esfuerzo necesario para cada uno de los componentes. • Cantidad de recursos humanos disponibles y sus perfiles para definir qué tareas se pueden realizar en paralelo y asignarlos a las tareas. • Secuencia de desarrollo según el plan de versiones. Comienzan a jugar aquí otras restricciones tales como el tiempo máximo de desarrollo, el presupuesto disponible, el flujo de caja, etc. Esto puede implicar que sea necesario redimensionar algunos de los equipos o paralelizar/serializar algunas de las actividades Por ejemplo, es posible que sea necesario aumentar el tamaño de algún equipo para acortar la duración de alguna iteración, o que sea necesario serializar tareas que lógicamente podrían realizarse en paralelo debido a la cantidad de recursos humanos disponibles, etc. Esto además debe compatibilizarse con una gran cantidad de otros factores externos que puedan tener algún grado de influencia. 3.6 Proceso Como conclusión, el proceso que planteo para la planificación y gestión de un proyecto dirigido por la arquitectura es el siguiente (ver figura final): • • • • • • • • A partir de los requerimientos funcionales y no funcionales se diseña la arquitectura del producto mientras en paralelo se realiza la estimación top-down del proyecto. A partir de la arquitectura se realiza una estimación bottom-up de cada uno de los componentes identificados. Se integran ambas estimaciones en la que se utilizará para la planificación del proyecto. Se realiza un nuevo análisis de riesgo, incorporando a la arquitectura como fuente de posibles riesgos que pueden afectar al proyecto. Algunos de los riesgos identificados pueden ocasionar la toma de decisiones que afecten la arquitectura con lo que se repite el ciclo. A partir de la arquitectura, los requerimientos o necesidades del usuario y del análisis de riesgo, se confecciona el plan de versiones. A partir de la arquitectura, se organizan los equipos que participarán en el proyecto. A partir del plan de versiones, del resultado del proceso de estimación, de las tareas de prevención y de las decisiones tomadas a partir del análisis de riesgo, y de los equipos previstos se confecciona el cronograma. Algunas consideraciones en el momento de confeccionar el cronograma para tener en cuenta todas las restricciones del proyecto pueden afectar la organización de los equipos, con lo que se vuelve a iterar el ciclo hasta encontrar el punto de equilibro. Una vez definidos el plan de versiones y el cronograma, comienza la construcción del producto, el cual se gestionará para mantenerlo dentro de lo previsto en los documentos obtenidos como resultado del proceso descripto xxviii. Ing. de Requerimientos Proceso de planificación y organización del proyecto basado en la arquitectura Integración de estimaciones Estimación TopDown Arquitectura Estimación BottomUp Plan de Versiones Confección del cronograma Ejecución Análisis de Riesgo Organización de los equipos i A guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute Humphrey, W.S, Managing the software process iii Bass, Clements y Kazman 1998. Software Architecture in Practice. Massachusetts, USA. Addison Wesley. iv Soni D, Nord R y Hofmeister C, Software Architecture in Industrial Applications, en Proceedings of the 17th International Conference on Software Engineering, New York: ACM Press, 1995. v Davis Alan M., Software Life Cycle Models. Software Engineering project management, editado por Richard H Thayer, 2ª edición. IEEE Computer Society Press, 1988 vi Royce W.W., Managing the Development of Large Software Systems: Concepts and Techniques, Proc. 1970 WESCON Technical Papers, Vol. 14, 1970 vii Hirsch E., Evolutionary Acquisition of Command and Control Systems, Program Manager, Nov. 1985. viii Giddings R.V, Accommodating Uncertainty in Software Design, Comm ACM, Vol 27, N° 5, May 1984. ix Gomaa H y Scott D, Prototyping as a Tool in the Specification of User Requirements, Proc. 5th IEEE International Conference on Software Engineering, IEEE CS Press, Los Alamitos, California, 1981. x Boehm B.W. A Spiral Model of Software Development and Enhancement, Computer, May 1988. xi Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon, Software Engineering Institute, 2002. xii Boehm B, Software Engineering Economics, E Englewood Cliffs, NJ, Prentice Hall 1981. xiii Boehm B. et al, Software Cost Estimation with Cocomo II, Upper Saddel River, NJ, Prentice Hall, 2000. xiv Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon, Software Engineering Institute, 2002. xv KRUTCHEN Philippe. Noviembre 1995. The 4+1 View Model of Architecture. IEEE Software, 12(6). xvi Higuera R.P, Software Risk Management, CMU/SEI-96-TR-012 ESC-TR-96-012, Software Engineering Institute (SEI), www.sei.cmu.edu xvii Grey S, Practical Risk Assessment for Project Management, John Wiley & Sons xviii Karolak D.W, Software Engineering Risk Management, IEEE Computer Society Press xix Michaels J.V, Technical Risk Management, Prentice Hall xx BASS L. et al. Quality Attribute Design Primitives. Technical Note CMU/SEI-2000-TN-017. Dic. 2000 xxi BASS L., et al. Quality Attribute Design Primitives and the Attribute Drive Design Method. SEI, Carnegie Mellon University, Pittsburgh. xxii MOUSQUES G. 2002. Transp. Curso de Arquitectura. Ing. de Sistemas, Universidad ORT, Uruguay. xxiii KAZMAN R. et al. Oct. 1999. Attribute Based Architectural Styles. Techn. Report CMU/SEI-99-TR022. xxiv Thayer R, Software Engineering Project Management xxv Rees F, Equipos de trabajo, Prentice Hall 1997 xxvi Simons, Lucarelli, Work Breakdown Structures xxvii Gido, Clements, Network Planning and Scheduling xxviii Pinto J, Project Management Handbook, PMI ii
