Capítulo 2. Ciclo de Vida del Proceso de Desarollo
Anuncio
Índice de contenido 2. EL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS...............................2 2.1. Fases del Proceso de Desarrollo ...................................................................................................3 2.1.1. Fase de Inicio..............................................................................................................................3 2.1.2. Fase de Elaboración....................................................................................................................6 2.1.3. Fase de Construcción .................................................................................................................9 2.1.4. Fase de Transición....................................................................................................................10 2.2.SUBPROCESOS DEL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS ............................................................................................................................................................11 2.2.1. Subproceso de Gestión del proyecto .......................................................................................14 2.2.2. Subproceso de Gestión de Riesgos...........................................................................................14 2.2.3. Subproceso de Requerimientos y Requisitos ..........................................................................15 2.2.4. Subproceso de Arquitectura .....................................................................................................16 2.2.5. Subproceso de Diseño..............................................................................................................16 2.2.6. Subproceso de Desarrollo ........................................................................................................16 2.2.7. Subproceso de Gestión de Pruebas...........................................................................................17 2.2.8. Subproceso de Gestión de Cambios.........................................................................................18 2.2.9. Subproceso de Implantación....................................................................................................18 2.2.10. Subproceso de Gestión Documental.......................................................................................19 2.2.11. Gestión de Platofoma Tecnologica........................................................................................20 2.2.12. Gestión de Auditorias ............................................................................................................21 2.2.13. Subproceso de Mejora del Proceso de Desarrollo ................................................................22 1 2. EL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS El proceso OpenUP/OAS define un ciclo de vida completo para el desarrollo de sistemas de software. El OpenUP/OAS está diseñado para soportar y hacer seguimiento a las actividades diarias de pequeños equipos de trabajo (no superiores a 10 personas). El OpenUP/OAs es un proceso iterativo cuyas direferentes iteraciones se distribuyen a través de cuatro fases: Inicio, Elaboración, Construcción y Transición. En las cuales se desarrollan transversalmente una serie de subprocesos entendiendose estos ultimos como un conjunto de actividades (Procedimientos), personas (Roles), prácticas (Guias) y productos de trabajo (Artefactos) que guían el proceso de desarrollo de software a través de las cuatro fases. 2 Cada fase puede tener tantas iteraciones (Iter) como se requiera, dependiendo del grado de complejidad y desconocimiento del dominio, la tecnología a ser usada, la complejidad arquitectónica y el tamaño del proyecto, para nombrar algunos factores. El OpenUP/OAS ofrece un conjunto de plantillas de los productos de trabajo para crear una estructura de desglose de trabajo, que sirven para que los equipos de trabajo rápidamente planifiquen sus iteraciones. Las iteraciones pueden tener diferentes longitudes de tiempo, dependiendo de las características del proyecto, Iteraciones de un (1) mes son recomendadas de tal forma que los informes de gestión del personal asociado coincida con los fines de iteración de tal forma que: • En este tiempo se muestre un incremento en la funcionalidad. • Se utilice como mecanismo de retroalimentación por parte de los usuarios. • Se administre de forma rápida y proactiva los riesgos y problemas presentados en el proyecto. El OpenUP/OAS se plantea para ofrecer una guía a equipos pequeños y medianos, no mayores a 20 personas, al interior de la Universidad Distrital Francisco José de Caldas. 2.1. Fases del Proceso de Desarrollo 2.1.1. Fase de Inicio Esta es la primera fase del proceso, donde los interesados (stakeholders) y los integrantes del equipo de desarrollo colaboran para determinar el ámbito del proyecto, su objetivos y determinar si el proyecto es viable. El propósito en esta fase es lograr concurrencia entre todos los interesados sobre los objetivos del ciclo de vida para el proyecto. Hay cuatro objetivos para la fase de Inicio que clarifican el alcance, los objetivos del proyecto y la viabilidad de la solución proyectada: 1. Entender qué construir. Determine la Visión, el alcance del sistema y sus límites, e identifique quién está interesado en este sistema y por qué. 2. Identifique la funcionalidad clave del sistema. Decida qué requerimientos son los más críticos. 3. Determine al menos una posible solución. Identifique al menos una arquitectura candidata y su viabilidad. 4. Entienda el costo, el cronograma y los riesgos asociados al proyecto. 3 Los proyectos podrían tener una o más iteraciones en la fase de inicio. Entre otras razones, para tener múltiples iteraciones en la fase de inicio, usted encontrará: • El proyecto es grande y es difícil definir su alcance. • Sistemas sin precedentes. • Muchos itneresados con necesidades encontradas y relaciones complejas. • Mayores riesgos técnicos que demandan la creación de un prototipo o prueba de conceptos. Actividades en la Fase de Inicio A. Iniciar el Proyecto Lanzar el proyecto y obtener un acuerdo con los grupos de interesados acerca del ámbito, alcance y plan inicial. Esta actividad engloba tareas que se requiere para definir la visión y crear un plan de proyecto. Esta actividad tiene lugar al inicio de la primera iteración, cuando el proyecto inicia. El objetivo de esta actividad es establecer la visión del proyecto y el plan de proyecto a un alto nivel de granularidad. Las personas que cumplen los siguientes roles deben contribuir en el desarrollo de la actividad: • Los roles de Analista e Interesado trabajan juntos para definir la Visión para el proyecto, capturando las necesidades de los usuarios y las características del sistema en desarrollo. Las necesidades y características son capturadas para alcanzar acuerdos (contratos) acerca del ámbito del proyecto. • El líder o guía del proyecto, colaborando y alcanzado acuerdos con el equipo de desarrollo y los interesados, propone un Plan General de Trabajo de alto nivel que incluye los hitos para las cuatro fases y un listado de iteraciones de cada fase, con espacios de tiempo asociados. Este plan, junto con la asignación de personal para el proyecto, evoluciona durante las fases y marca el ritmo del proyecto. B. Planear y gestionar la Iteración Iniciar la iteración y permitir a los integrantes del equipo inscribirse para el desarrollo de tareas. Hacer seguimiento y comunicar el estado del proyecto a los interesados externos. Identificar y manejar excepciones y problemas. Esta actividad se realiza a través del ciclo de vida del proyecto. El objetivo de esta actividad es identificar riesgos y factores con suficiente anticipación como para poder ser mitigados, para establecer los logros de la iteración y apoyar al equipo de trabajo en el alcance de sus metas. 4 El lider del proyecto y el equipo lanza la iteración. La priorización del trabajo para una iteración dada toma lugar. El lider del proyecto, los interesados y los miembros del equipo acuerdan lo que se supone será desarrollado durante esa iteración. Los miembros del equipo de trabajo registran los ítems de trabajo que desarrollarán en esa iteración. Cada miembro del equipo divide los ítems del trabajo en tareas de desarrollo y estima el esfuerzo que requieren. Así se provee una estimación más precisa de la cantidad de tiempo que será empleada y de lo que puede ser alcanzado en forma realista en una iteración dada. Al finalizar la ejecución de la iteración, el equipo se reúne regularmente para reportar el estado del trabajo adelantado, las siguientes tareas a realizar y los elementos que interfieren con el avance. En algunos proyectos, este chequeo del estado se efectúa cada día, lo que permite un entendimiento más preciso de cómo el trabajo progresa en una iteración. Si es necesario el equipo hace correcciones para alcanzar lo planeado. La idea general es que los riesgos y factores se identifiquen y manejen a través de toda la iteración, y que cada uno conozca el estado del proyecto de una manera oportuna. Durante los hitos de la iteración, el criterio clave de éxito se define demostrando que la funcionalidad planeada se ha implementado. Las lecciones aprendidas se retienen a fin de modificar el proyecto y mejorar el proceso. Si el final de la iteración coincide con el final de la fase, constate que los objetivos de la fase se hayan alcanzado. C. Identificar y refinar Requerimientos Esta actividad describe las tareas que se deben efectuar para lograr especificar, analizar y validar un subconjunto de requerimientos del interesado frente al sistema antes de su implementación y verificación. Lo anterior no implica que todos los requerimientos estén detallados antes del inicio de la implementación. Es más, usted ejecuta esta actividad a través de todo el ciclo de vida con los interesados y todo el equipo de desarrollo colaborando para asegurar que un claro, consistente, correcto, verificable y alcanzable conjunto de requerimientos este disponible, tal como se requiere, para dar lugar a la implementación y verificación. Durante el Inicio, el foco se orienta a ganar acuerdo sobre el problema a resolver, captando las necesidades de los interesados y capturando las características de alto nivel del sistema. Durante la Elaboración, el foco sigue a la definición de la solución. Lo cual consiste en encontrar aquellos requerimientos que tienen mayor valor para los interesados, que son particularmente retos o riesgos, o que son significativos para la arquitectura . Luego usted ya puede describir los requerimientos, los cuales que se han priorizado a través de las Listas de Unidades de Trabajo, para la implementación durante las primeras iteraciones, con suficiente detalle para validar el entendimiento por parte del equipo de desarrollo, para asegurar coincidencia con los interesados, y permitir que el desarrollo del software comience. Por cada uno de estos requerimientos, defina casos de prueba asociados para asegurar que son verificables y para proveer la guía necesaria para la verificación y validación. 5 Durante la Construcción, el foco se deslaza hacia el refinamiento de la definición del sistema. Este consiste en detallar los requerimientos faltantes y asociados a los casos de prueba tan necesarios para impulsar la implementación y verificación, y al manejo de los cambios de requerimientos. D. Llegar a un acuerdo sobre el enfoque técnico La meta de esta actividad es definir el enfoque técnico para el sistema, que soporte los requerimientos del proyecto entre las restricciones colocadas en el sistema y el equipo de desarrollo. El arquitecto deberá hacer lo siguiente: • Trabajar con el equipo para crear un esquema inicial del enfoque técnico para el sistema propuesto. • Asegurarse de que las decisiones técnicas se capturen y comuniquen adecuadamente. • Asegurarse de que el equipo tiene la suficiente información para entender el enfoque que usted está tomando. El trabajo hecho hasta aquí no busca producir una especificación técnica completa y detallada. Por el contrario se deberá definir todo el enfoque a un alto nivel técnico. Usted se debe centrar en proveer la arquitectura con el software trabajando. Si la solución es similar a la solución previamente producida, o es un dominio de solución bien conocido, entonces, seguramente, será suficiente con referenciar ese ejemplo como evidencia de la viabilidad de ese enfoque. En algunos casos puede ser necesario desarrollar uno o más prototipos para validar algunas de las decisiones o clarificar algunos de los requerimientos. La conclusión de este trabajo deberá producir justo la suficiente información para comunicar la arquitectura al equipo y para demostrar su viabilidad al usuario. Esto le permite al proyecto avanzar, habilitándolo a usted para refinar y delinear la arquitectura. 2.1.2. Fase de Elaboración Esta es la segunda fase dentro del ciclo de vida del proyecto. En ella los riesgos arquitectónicamente significativos se identifican y consideran. Hay objetivos para la fase de Elaboración que le ayudan a direccionar los riesgos asociados con los requisitos, la arquitectura, los costos y el cronograma: • Obtenga un entendimiento más detallado de los requisitos. Tenga un buen entendimiento de la mayoría de requisitos que le permitan crear un plan más detallado y obtener ganancia de los interesados. Asegúrese de ganar profundidad en el entendimiento de los requisitos más críticos que serán validados por la arquitectura. • Diseñar, implementar, validar y establecer la línea base para la arquitectura. Diseñe, implemente y pruebe un esqueleto estructural del sistema. Aunque la funcionalidad no sea 6 completa aún, muchas de las interfaces entre los bloques de construcción se implementan y prueban. Esto se refiere a una arquitectura ejecutable. • Mitigar los riesgos esenciales y producir un cronograma exacto y estimar los costos. Muchos riesgos técnicos se gestionan como resultado de detallar los requisitos y diseñar, implementar y probar la arquitectura. Refine y detalle el plan de proyecto de alto nivel. El número de iteraciones en la fase de Elaboración depende de los requerimientos de los interesados, pero no se limita a, factores tales como desarrollos de campo versus ciclo de mantenimiento, sistemas sin precedentes versus un buen conocimiento de la tecnología y la arquitectura, y así sucesivamente. Típicamente, sobre la primera iteración usted debería diseñar, implementar y probar un pequeño número de escenarios críticos para identificar qué tipo de arquitectura y mecanismos arquitectónicos necesita, que usted pueda mitigar los riegos más cruciales. También detalle los requisitos de alto riesgo que tienen que ser gestionados tempranamente en el proyecto. Pruebe bastante para validar que los riesgos de la arquitectura se mitigan. En las siguientes iteraciones, usted programa y arregla lo incorrecto que haya quedado de la iteración previa. Usted diseña, implementa y prueba los escenarios restantes arquitectónicamente significativos, asegurándose de chequear todas las áreas importantes del sistema (cobertura arquitectónica), así los riesgos ocultos potenciales se hacen visibles lo más rápido posible. Actividades en la Fase de Elaboración A. Planificación y gestión de la iteración B. Identificación y refinamiento de los requisitos C. Desarrollo de la Arquitectura D. Desarrollar los requisitos arquitecturalmente significativos y priorizados para esta iteración. Esta actividad refina la arquitectura inicial de alto nivel en software de trabajo. El objetivo es producir software estable que maneje adecuadamente los riesgos técnicos en perspectiva. Los arquitectos y desarrolladores trabajan juntos para: • Refinar el esquema inicial de la arquitectura en elementos de diseño concretos • Asegurar que las decisiones de arquitectura se capturan y comunican adecuadamente • Asegurar que el equipo tiene suficiente información para habilitar el software a ser desarrollado. • Asegurar que los requerimientos que fueron priorizados para la iteración actual se manejan adecuadamente en el software. En un proyecto iterativo, el equipo no debe intentar desarrollar la arquitectura para todo el proyecto en un solo paso. Preferiblemente, ellos deben centrarse en encontrar los requerimientos en la 7 perspectiva de la actual iteración, mientras toma decisiones en el contexto de todo el proyecto. E. Desarrollar un incremento de solución Diseñar, implementar, probar e integrar la solución a un requisito dentro de un contexto dado. Aquí los desarrolladores crean una solución para el ítem de trabajo del cual se han hecho responsables, de manera que la administración del proyecto obtiene un camino base para el éxito en una fase del avance del proyecto. Ejecutar esta actividad es una forma de realizar la planeación y ejecución basada en metas. El trabajo tomado por los desarrolladores, y su progreso, se supervisa con base en los logros alcanzados utilizando el diseño, las pruebas del desarrollo y la integración del código fuente. Cuando un requerimiento se asigna para desarrollar puede ser especificado un contexto, así se determina que tan ampliamente un requerimiento dado se va a desarrollar en una iteración. El desarrollo puede enfocarse en una capa, tal como la interfaz de usuario, lógica del negocio, o acceso a base de datos, un componente u otra. Siempre que se especifique o no un contexto, la responsabilidad del desarrollador es crear un diseño e implementación para ese requerimiento. El desarrollador también escribe y corre las pruebas de desarrollo contra la implementación para asegurar que trabaja según el diseño, tanto independientemente, como integrado al código base. Los cambios requieren algún esfuerzo en el diseño de la solución antes de pasar a la implementación, aún si es solamente un ejercicio mental que resulta en una unidad de trabajo de corto tiempo. El diseño para cambios triviales en la implementación existente, por ejemplo, soportar algunos requerimientos, puede ser evidente por sí mismo en el contexto de la arquitectura y diseño existente. Una vez que la organización de la solución técnica es clara, defina las pruebas de desarrollo que verificarán la implementación. Este enfoque impulsado por pruebas asegura que las consideraciones de diseño sean tomadas en cuenta antes que la solución sea codificada. Las pruebas se corren, y si fallan, claramente definen el criterio para determinar si la implementación trabaja como se deseaba. Los errores en las pruebas conducen a la implementación de la solución, por esto, hasta su finalización se ejecutan nuevamente los ensayos. Este bucle más interno de la implementación y pruebas de desarrollado se repite hasta que se aprueben las pruebas. Pasar las pruebas no necesariamente significa que la solución sea de alta calidad o que sea apropiada. Es conveniente volver a visitar el diseño en este punto. Esta ruta nos lleva de regreso a través del proceso, ya que algunos cambios en el diseño podrían afectar las pruebas de desarrollo y la implementación. Una vez aprobadas las pruebas y el diseño de la solución es apropiado, existe todavía la posibilidad de una retroalimentación adicional. Lo mejor es mantener el modelo “test­driven ” evolucionando en ciclos internos tanto como sea posible. Avanzando con varios diseños de solución a pequeña escala para una parte del ítem del trabajo, defina una prueba o dos para la implementación de una parte de la solución, y al aprobarla, verifique la calidad, y entonces, continúe como en la primera prueba hasta que esta parte del diseño esté trabajando. Luego, en el 8 ciclo más avanzado de la actividad, regrese al ítem de trabajo y diseñe otra parte para acercarse más a su finalización F. Probar la solución Desde la perspectiva del sistema, probar y evaluar los requisitos de desarrollo. Desarrollar y ejecutar scripts de prueba para validar que el sistema cumple con los requisitos. Esta actividad se repite a todo lo largo del ciclo de vida del proyecto. El objetivo principal de esta actividad es validar que la actual construcción del sistema satisface los requerimientos definidos para ella. A través de las iteraciones, lo que se busca es validar que los requerimientos implementados reflejen una arquitectura robusta y que los requerimientos adicionales se implementen consistentemente en la cima de la arquitectura. Tan pronto como los desarrolladores implementan la solución para los requerimientos de la iteración dada, se integra el código fuente a la unidad de prueba. Entonces, el especialista de pruebas conduce las pruebas a nivel de sistema en paralelo con el desarrollo para asegurar que la solución, la cual está siendo integrada continuamente, satisface el requerimiento especificado en los casos de prueba. El responsable de las pruebas define qué técnicas utilizar, cuáles datos de entrada y qué conjunto de pruebas crear. Cuando las pruebas corren, los defectos se identifican y añaden ítems a las listas de trabajo, así es como éstos pueden priorizarse como parte del trabajo que usted realizará durante las iteraciones. 2.1.3. Fase de Construcción Esta es la tercera fase del proceso que se enfoca en detallar los requisitos, diseñar, implementar y probar el grueso del software. El propósito de esta fase es completar el desarrollo del sistema basado en la arquitectura. Hay objetivos para la fase de Construcción que nos ayudan a tener un desarrollo costo­eficiente de un producto completo, una versión operativa del sistema, que pueda ser entregada a la comunidad de usuarios: 1. Desarrolle iterativamente un producto completo que esté listo para hacer transición a su comunidad de usuarios. Describa los requisitos restantes, complete en detalles los diseños, complete la implementación y prueba del software. Libere la primera versión operativa del software (beta) del sistema y determine si los usuarios están listos para que la aplicación sea desplegada. 2. Minimice el costo de desarrollo y alcance algún grado de paralelismo. Optimice los recursos y promueva el paralelismo de desarrollo entre desarrolladores o equipos de desarrolladores, por por ejemplo, asignar componentes que puedan ser desarrollados independientemente uno del otro. Típicamente, la fase de Construcción tiene más iteraciones, dos o cuatro, que las otras fases, 9 dependiendo del tipo de proyecto: • Proyecto Simple: Una iteración para construir el producto (a una liberación beta) • Proyectos más considerables: Una iteración para exponer un sistema parcial y una para madurar este a un beta testing • Proyectos grandes: Tres o más iteraciones, dado el tamaño del proyecto (número de requisitos a implementar para una liberación beta) Actividades de la Fase de Construcción 1. Planificación y gestión de la iteración 2. Identificar y refinar requisitos 3. Desarrollar un incremento de solución 4. Probar la solución 2.1.4. Fase de Transición Es la cuarta fase del proceso. Se enfoca en la transición del producto de software a la plataforma tecnológica del cliente logrando que los interesados convengan que el desarrollo del producto cumple con los requisitos planteados. El propósito de esta fase es asegurar que el producto de software está listo para ser distribuido a los usuarios. Hay objetivos para la fase de Transición que le ayudan a afinar elegantemente la funcionalidad, el desempeño y la calidad total de la versión beta del producto desde el final de la fase previa: 1. La prueba beta valida que las expectativas del usuario sean satisfechas. Esto típicamente requiere algunas actividades de afinamiento, tales como depuración de errores y mejora del desempeño y la usabilidad. 2. Lograr el consentimiento de los interesados en que el desarrollo está completo. Esto puede involucrar varios niveles de pruebas para la aceptación del producto, incluyendo pruebas formales e informales y pruebas beta. 3. Mejorar el desempeño en futuros proyectos a través de lecciones aprendidas. Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las Herramientas para el proyecto. Consideraciones Claves La fase de transición puede incluir ejecutar sistemas nuevos y viejos en paralelo, migrar datos, entrenar los usuarios y ajustar los procesos del negocio. El número de iteraciones en la fase de transición varía desde una iteración para un sistema 10 simple, requiriendo, principalmente, menor depuración de errores, a muchas iteraciones para un sistema complejo, involucrando adición de características y desarrollo de actividades para hacer la transición del negocio desde usar el viejo sistema a usar el nuevo sistema. Cuando se alcanzan los objetivos de la fase de Transición, el proyecto puede finalizar. Para muchos productos, el final del actual ciclo de vida del proyecto puede coincidir con el inicio del siguiente ciclo de vida, llevando a la siguiente generación del mismo producto. Actividades de la Fase de Transición 1. 2. 3. 4. Planificación y gestión de la iteración Identificar y refinar requisitos Desarrollar un incremento de solución Probar la solución 5. Tareas adicionales 2.2.SUBPROCESOS DEL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS Como se habia señalado anteriormente un subproceso es un conjunto de actividades referenciadas con procedimientos especificos, desarrolladas por personas con unos roles detereminados, las cuales se guian por medio de una serie de prácticas o guias para obtener unos productos de trabajo denominados Artefactos y que permiten cumplir direccionar las fases y actividades propuestas en las cuatro fases del proceso de desarrollo de software openup/oas. Estos subprocesos se relacionan entre si, siendo unos entradas o insumos iniciales para que otros subprocecesos se puedan desarrollar. Los subprocesos que se trabajan en el ciclo de vida del proceso de desarrollo openup/oas son: Subproceso Objetivo Concebir un nuevo proyecto Concebir y definir un proyecto de software, con el fin de evaluar su viabilidad técnica, tecnológica, organizacional, ambiental y financiera. Requerimientos y Requisitos Recolectar, analizar, aprobar y seguir la evolución de los requerimientos funcionales del Cliente o interesado y los requisitos del software a través de la vida del producto y/o servicio. Gestión del Proyecto Planear, ejecutar , controlar y socializar las actividades y resultados de un proyecto de software. Gestión del Riesgo Identificación, valoración, relevancia, prevención, mitigación, control y respuesta a posibles riesgos que se generen en un proyecto de software. Arquitectura Transformar los requerimientos y requisitos significativos en una arquitectura que describa su estructura e identifique los componentes 11 del software. Diseño Proporcionar un diseño que implemente el software y pueda ser verificado contra los requerimientos y los requisitos definidos. Desarrollo Implementar una solución técnica que cumpla con la arquitectura definida y soporte los requerimientos de los grupos interesados. Gestión de Pruebas Diseñar, implementar, ejecutar y evaluar pruebas en cada uno de los componentes desarrollados. Gestión de Cambios Registrar, revisar y llevar a cabo solicitudes de cambios generadas en un proceso de desarrollo de software. Implantación Planificar y llevar a cabo la producción de una solución de software mediante el alineamiento de las necesidades de capacitación de los usuarios y el desarrollo de pruebas de funcionamiento. Gestión Documental Planificar, elaborar, aprobar, organizar y controlar la documentación requerida en un proceso de desarrollo de software. Gestión de Auditorias Planificar y ejecutar auditorias internas a proyectos de software con el fin de encaminarlos a una mejora continua Gestión de Plataforma Tecnólogica Explorar, adaptar, acoger, evaluar y mejorar de manera incremental e Proceso de Desarrollo iterativa los lineamientos y directrices propios del proceso de desarrollo unificado OPENUP/OAS A continuación se presenta el mapa de suprocesos del proceso de desarrollo OPENUP/OAS agrupados en cuatro tipos de suprocesos (Gestión, Principales, Apoyo y Mejoramiento Continuo). 12 Subprocesos de Gestión 2.2.1. Subproceso de Gestión del proyecto Este subproceso explica como entrenar, sincronizar y apoyar el equipo de desarrollo, ayudándolo a manejar los obstáculos encontrados cuando se desarrolla software, identificando, estableciendo, coordinando y supervisando las actividades, tareas y recursos necesarios para que un proyecto pueda producir un producto y/o servicio en el contexto de los requerimientos del proyecto y sus restricciones. Los propósitos que persigue este subproceso son: • Fomentar el consenso entre el grupo de interés para priorizar las unidades de trabajo. • Estimular la colaboración en el equipo creando planes de corto y largo plazo para el proyecto. • Enfocar el equipo en la liberación continua de software probado y listo para la evaluación por parte del grupo de interés. • Ayudar a crear un ambiente de trabajo efectivo para maximizar la productividad del equipo. • Mantener al grupo de interés y al equipo informado acerca del progreso del proyecto. • Evaluar la viabilidad de lograr las metas del proyecto con los recursos disponibles y las restricciones. El subproceso Gestión de Proyecto cubre y es afectado por todas los demás subprocesos. Las actividades de este subproceso adicionan valor al proyecto al crear ambientes de trabajo de alto desempeño donde: • • Los grupos de interés confian en las habilidades del equipo para distribuir exitosamente soluciones y entender las capacidades de la plataforma tecnológica. Los integrantes del equipo de trabajo entienden las intenciones del grupo objetivo y confirman dicho entendimiento construyendo productos de software con calidad. 2.2.2. Subproceso de Gestión de Riesgos Este subproceso brinda una herramienta de administración de riesgos basada en los postulados de la “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información de las Administraciones públicas” ­ MAGERIT , que guié la identificación, valoración, relevancia, prevención, mitigación, control y respuesta a posibles riesgos que se generen en el proceso de desarrollo de un proyecto de software. Los Objetivos específicos de este subproceso son: • Concientización del equipo de desarrollo (Usuarios, analistas, arquitectos, desarrolladores y 14 • • • gestores) de la existencia de los Riesgos y la necesidad de manejarlos oportunamente. Definir un método sistemático y practico que permita valorar y analizar los riesgos que se identifiquen a lo largo del proyecto. Guiar la definición de las medidas de seguimiento, mitigación y control de los riesgos críticos que afectan la consecución de los objetivos de un proyecto de desarrollo de software. 15 Subprocesos Principales 2.2.3. Subproceso de Requerimientos y Requisitos Este subproceso explica como identificar, analizar, especificar, validar y administrar los requerimientos y requisitos que debe cumplir el sistema o software. Los propósito de este subproceso son: • Entender el problema que debe resolverse • Entender las necesidades del grupo de interés, lo que el usuario necesita • Definir los requerimientosy requisitos que debe cumplir la solución, lo que le sistema debe hacer • Definir las fronteras que determinan el ámbito del sistema • Identificar las interfaces externas del sistema • Identificar las restricciones técnicas que tiene la solución • Proveer las bases para la planificación de las iteraciones • Proveer las bases para la estimación de costos y el cronograma Para alcanzar estas metas es importante entender tanto la definición como el ámbito del problema que se trata de resolver e identificar los grupos de interés. Luego que se tiene un consenso sobre el problema que debe ser solucionado, los requerimientos y requisitos para el sistema son identificados, organizados, analizados, validados y especificados. A través del ciclo de vida del proyecto, se deben administrar los cambios ocurridos en el modelo de requerimientos y requisitos. El subproceso de Requerimientos y Requisitos está relacionada con los otros subprocesos en la siguiente forma: • Con el subproceso de Arquitectura y Desarrollo para las cuales las entradas vienen del subproceso de Requerimientos y Requisitos. • El subproceso de Gestión de Pruebas que valida el sistema contra lo especificado en el subproceso de requisitos. • El subproceso de Gestión de Cambios provee mecanismos para administrar los cambios en los requerimiento y requisitos. • El subproceso de Gestión del Proyecto planifica el proyecto y asigna los requerimiento y requisitos a cada iteración a partir del análisis de los requerimientos y requisitos priorizados y la asignación de unidades de trabajo. 16 2.2.4. Subproceso de Arquitectura Este subproceso explica como crear una arquitectura a partir de los requisitos "estructuralmente" significativos. La arquitectura se construye en el subproceso de Desarrollo. El propósito de este subproceso es crear incremental y evolutivamente una arquitectura robusta del sistema. El subproceso Arquitectura está relacionada con otros subprocesos de la siguiente manera: • • • • El subproceso de Requerimientos y Requisitos proporciona los requisitos arquitectónicamente significativos. El subproceso Desarrollo diseña e implementa la arquitectura. El subproceso de Gestión de Pruebas verifica la estabilidad y precisión de la arquitectura. El subproceso de Gestión del Proyecto planifica el proyecto para que ciertos componentes de la arquitectura se desarrollen en cada iteración. 2.2.5. Subproceso de Diseño Este subproceso explica como diseñar una solución técnica que cumple con la arquitectura y soporta los requerimientos de los grupos interesados. El propósito de este subproceso es: • Transformar los requisitos en un diseño de sistema. • Adaptar el diseño para que se acople al ambiente de implementación. Este subproceso está relacionada con otros subprocesos de la siguiente forma: • • • El Subproceso de Requerimientos y Requisitos define los que será diseñado El Subproceso de Arquitectura organiza y restringe el diseño. El subproceso de Gestión del Proyecto planifica qué funcionalidad será diseñada en cada iteración. 17 2.2.6. Subproceso de Desarrollo Este subproceso explica como implementar una solución técnica que cumple con la arquitectura y soporta los requerimientos de los grupos de interesados. El propósito de este subproceso es: • Construir el sistema incrementalmente. • Verificar que las unidades técnicas usadas para crear el sistema, trabajan según lo especificado. Con cada iteración, las tareas en el subproceso evolucionarán para tener una Construcción estable, con mayor capacidad funcional. Cuando el Desarrollador trabaja en el sistema usa y se restringe a lo especificado en la arquitectura. Este subproceso está relacionada con otros subprocesos de la siguiente forma: • • • • • El Subproceso de Diseño define los que será implementado. El Subproceso de Arquitectura organiza y restringe la implementación. El subproceso de Gestión de Pruebas valida que la construcción del sistema cumple con lo requisitos. El subproceso de Gestión de Cambios provee los mecanismos para administrar los cambios en la construcción. El subproceso de Gestión del Proyecto planifica qué funcionalidad será implementada en cada iteración. 2.2.7. Subproceso de Gestión de Pruebas Este subproceso explica cómo proveer retroalimentación al equipo de desarrollo acerca de la evolución del sistema a través del diseño, implementación, ejecución y evaluación de pruebas en cada uno de los componentes desarrollados. El propósito de este subproceso es: • Proveer retroalimentación temprana y constante de que el sistema cumple o no con los requisitos y requerimientos definidos. • Medir objetivamente el progreso del sistema basado en microincrementos. • Identificar problemas en la solución • Proveer seguridad en cuanto a que los cambios en el sistema no introducen nuevos defectos. • Aumentar la velocidad en el desarrollo facilitando el descubrimiento de problemas en los requisitos, diseños e implementaciones tan pronto como sea posible. 18 El subproceso de Pruebas es iterativa e incremental. Se aplican pruebas Iniciales y pruebas frecuentes con el fin de mitigar los riesgos en lo posible en una fase temprana del ciclo de vida del proyecto. Las pruebas se efectuan en cada iteración del ciclo de vida, siendo la primera la que guía las posteriores. De hecho, es común para una iteración tener muchos ciclos de prueba, dependiendo de la frecuencia de los nuevos desarrollos. Se pone en prueba preguntas tales como: "¿Qué funciones debe llevar a cabo la nueva aplicación para que se pueda considerar que cumple con los requerimientos establecidos? Este subproceso pone a prueba la hipótesis, riesgos e incertidumbres inherentes al desarrollo y aborda estas preocupaciones mediante demostración concreta e imparcial. El subproceso de Pruebas se relaciona con los demas subprocesos de la siguiente manera: Subproceso de Requerimientos y Requisitos: Identifica el propósito del sistema. Se efectuan pruebas si el sistema contempla en detalle los requerimientos definidos previamente. • Subproceso de Desarrollo: El sistema se desarrolla incrementalmente basado en la evaluación de las pruebas que se aplican en esta subproceso. En cada iteración las pruebas proporcionan una retroalimentación objetiva. Una prueba eficaz permite a los desarrolladores centrarse en la aplicación de nuevas funcionalidades y mejorar el desempeño del sistema. • Subproceso de Gestión del Proyecto: el subproceso de pruebas proporciona una medida objetiva de progreso, permitiendo una planificación adaptativa. • El subproceso de Gestión de Cambios. El subproceso de pruebas verifica el esfuerzo que cada cambio en la solución. 2.2.8. Subproceso de Gestión de Cambios Este subproceso explica el control de cambios en los artefactos, asegurando una evolución sincronizada del conjunto de productos de trabajo que componen el sistema de software. Los propósitos que se persiguen en este subproceso son: • Mantener un conjunto de productos de trabajo consistentes a la medida que estos evolucionan • Mantener construcciones o incrementos consistentes del software. • Proveer un mecanismo eficiente para adaptarse al cambio y a los problemas modificando el plan de acuerdo a ello. • Proveer datos para poder medir el progreso del proyecto. La Gestión del Cambio se refiere al proceso de gestión de los cambios de la versión controlada por los artefactos, y hace frente a los dos últimos objetivos enumerados anteriormente. 19 Aunque es importante mantener al día las versiones y configuraciones de todos los productos de trabajo, esta es la principal preocupación de los artefactos en la fase de Construcción. Este subproceso abarca la totalidad del ciclo de vida. La gestión del cambio la realizan todos los miembros del equipo de desarrollo, y debido a la importancia y generalización de este subproceso, la gestión del cambio de orientación se asocia con las tareas y trabajos en todos los productos de otros subprocesos. 2.2.9. Subproceso de Implantación Este subproceso tiene como objetivo la puesta en marcha de una o varias funcionalidades especificas del sistema , asegurando la disponibilidad del producto para los interesados Los propositos de este subproceso son: • Formar a los usuarios y al cuerpo encargado de distribuir el sistema. • Puesta en marcha del software . • Probar el producto en su entorno de ejecución final. • Proveer asistencia y ayuda a los usuarios. Las actividades propias de este subproceso se lleva a cabo con mayor intensidad en la fase de transición, debido a que su propósito es asegurar una aprobación y adaptación sin que existan dificultades del software por parte del usuario. Este subproceso debe iniciar en fases anteriores, para preparar el camino, sobre todo con actividades relacionadas a la planificación, pero también con la elaboración del manual de usuario y tutoriales. Subprocesos de Apoyo 2.2.10. Subproceso de Gestión Documental Este subproceso representa un gran soporte para otros subprocesos en la medida que permite gestionar la información que se genera a lo largo del ciclo de vida del proceso de desarrollo openup/oas, conviertiendose en un insumo de trabajo de vital importancia para registrar y dejar evidencia de las acciones y resultados alcanzados en cada uno de subprocesos definidos en esta guia. Para llevar a cabo este subproceso se deben desarrollar un conjunto de actividades que asegura de manera sistemática la creación, organización, gestión, conservación y eliminación de documentos digitales e impresos generados al interior de los proyectos. 20 El proposito del subproceso de la gestión documental es elaborar y mantener los documentos necesarios para los lideres, interesados o cualquier otro rol que haga parte del proceso de desarrollo openup/oas en el momento oportuno y justo, de tal manera que guie y apoyen sus labores y de todos aquellos que se integren en cualquier momento al proyecto. Estos son algunos ejemplos de la documentación que se puede gestionar en este subproceso: • Los procedimientos y guias definidos para gestionar la documentación generada a lo largo del ciclo de vida del proceso de desarrollo openup/oas. • Los documentos de trabajos propios de los demás subprocesos como diseño, desarrollo, arquitectectura entre otros , tales como diagrama entidad relacion. • La documentación que soporta la revisión de procedimientos propios del proceso de desarrollo openup/oas a traves de Auditorias. • La documentación elaborada para el usuario final, los cuales describen la funcionalidad del software o sistema desarrollado. Los propositos del Subproceso de Gestión Documental son: ­Definir las politicas, estrategias y directrices para gestionar los documentos que se generan al interior de un proyecto de software ya sea en medio digital o fisico (Identifación, control de versiones, almacenamiento , entre otros). ­ Determinar los requerimientos de documentación del proceso de desarrollo openup/oas por medio de plantillas que guian y definen los elementos constitutivos como :Titulo, proposito, audiencia y resumen del contenido entre otros. ­ Elaborar la documentación acorde a los requerimientos preestablecidos en las plantillas guias. ­ Verificar el grado de correspondancia entre los elementos y directrices definidos en las plantillas y los docuementos elaborados. ­ Distribuir el documento elaborado ya sea en medio digital o fisico a las partes interesadas para su respectiva evaluacion y aprobación. – Actualización y mantenimiento de la documentación generada de acuerdo a las directrices definidas previamente. 21 2.2.11. Gestión de Platofoma Tecnólogica El propósito del subproceso es mantener una infraestructura (hardware, software, bases de datos, herramientas e instalaciones) estable y confiable, que permita cubrir las necesidades y requerimientos de cualquier otro subproceso. Los objetivos de este subproceso son: – – – – Definir los requerimientos de infraestructura para apoyar los otros subprocesos en un proyecto especifico ( Considerar aspectos de funcionalidad, prestaciones, seguridad física y de acceso, disponibilidad, requerimientos de espacio, equipos, costos , limitaciones de tiempo. entre otros) Gestionar la adquisición de la infraestructura tecnologica cuando sea necesario Implementación de la Infraestructura tecnologica ( Planificar y documentar la configuración de la infraestructura Mantenimiento de una infraestructura estable y fiable. (Mantenimiento, seguimiento y modificación de la infraestructura según sea necesario para asegurar que continúa satisfaciendo los requerimientos del subproceso o proyecto al cual soporta). Subprocesos de Mejoramiento Continuo 2.2.12. Gestión de Auditorias El subproceso de Gestión de Auditoria cumple un papel fundamental en el ciclo de vida del proceso de desarrollo, dentro de sus propositos esta la revisión de la aplicabilidad de los postulados y directrices del openup/oas, asi como la evaluación de la funcionalidad, confiabilidad, disponibilidad e intergridad de la información que administra el producto, módulo o función de software que se ha generando. El objetivo de este subproceso es mantener un entendimiento común con los interesados de los avances del proyecto y llevar a cabo un seguimiento a los avances de los objetivos definidos en el proyecto definiendo las acciones que deben llevarsen a cabo para el mejoramiento continuo del proyecto y del producto que satisfaga al cliente logrando asi un adecuado control interno encaminado a la eficiencia y la eficacia. El subproceso de auditoría es un proceso para determinar el cumplimiento con los requerimientos, planes o directrices según aplique. 22 El trabajo de este subproceso se logra a través de diferentes tipos de auditorías y revisiones. Los propositos de la Gestión de Auditorias son: • Proporcionar a los interesados o usuarios finales un producto de software que satisfaga sus necesidades y requerimientos. • Es un subproceso que contribuye al mejoramiento continuo del proceso y del producto. • El proyecto auditado mantiene al día las actividades propias del equipo de desarrollo (procesos, producto, documentación etc...) debido a las exigencia que esta demanda. • Mejoramiento continuo de las directrices del proceso de desarrollo openup/oas y la calidad del producto de software. Se deberán llevar a cabo auditorías para asegurar que: – Los productos software reflejan efectivamente los requerimientos y requisitos definidos previamente. – Existe documentación y registros que evidencia el cumplimiento de las directrices del proceso de desarrollo openup – Se evidencian pruebas funcionales y tecnicas que apunta e evaluar la calidad del producto de software. – Los productos software han sido adecuadamente probados y cumplen sus especificaciones. 2.2.13. Subproceso de Mejora del Proceso de Desarrollo Este subproceso esta encaminado a establecer, autoevaluar, evaluar, controlar y mejorar continuamente los lineamientos, directrices, practicas, guias, procedimientos o plantillas propias del proceso de desarrollo openup/oas. Los objetivos o propositos de este subproceso son: • Establecer , definir y caracterizar los subprocesos del ciclo de vida del proceso de desarrollo openup/oas tomando encuenta la normatividad y experiencia propia y externa a nivel local, nacional e internacional de modelos o metodos relacionados con la gestión de procesos de desarrollo de software que permitan un incremento de valor del mismo. • Llevar a cabo un seguimiento, control y evaluación continua y periodica de la aplicación de las directrices definidas en el proceso de desarrollo openup/oas en los proyectos de software con el fin de adaptarla, ajustarla y mejorarla. • Adaptar, ajustar y mejorar los lineamientos del proceso de desarrollo OPENUP/OAS de acuerdo a las necesidades y requerimientos que surgan en los proyectos de software en la Universidad Distrital, de tal manera que sea mas efectivo y eficaz 23
