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....................................................................................................................! 2.1.3. Fase de Cons"r#cci n .................................................................................................................$ 2.1.%. Fase de &ransici n....................................................................................................................1' 2.2.SU(PROCESOS DEL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS ............................................................................................................................................................11 2.2.1. S#b)roceso de *es"i n del )ro+ec"o .......................................................................................1% 2.2.2. S#b)roceso de *es"i n de Ries,os...........................................................................................1% 2.2.3. S#b)roceso de Re-#eri.ien"os + Re-#isi"os ..........................................................................1/ 2.2.%. S#b)roceso de Ar-#i"ec"#ra .....................................................................................................1! 2.2./. S#b)roceso de Dise0o..............................................................................................................1! 2.2.!. S#b)roceso de Desarrollo ........................................................................................................1! 2.2.1. S#b)roceso de *es"i n de Pr#ebas...........................................................................................11 2.2.2. S#b)roceso de *es"i n de Ca.bios.........................................................................................12 2.2.$. S#b)roceso de I.)lan"aci n....................................................................................................12 2.2.1'. S#b)roceso de *es"i n Doc#.en"al.......................................................................................1$ 2.2.11. *es"i n de Pla"o3o.a &ecnolo,ica........................................................................................2' 2.2.12. *es"i n de A#di"orias ............................................................................................................21 2.2.13. S#b)roceso de 4e5ora del Proceso de Desarrollo ................................................................22

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 diseado para soportar y hacer seguimiento a las actividades diarias de pequeos equipos de trabajo (no superiores a 10 personas). El OpenUP/OAs es un proceso iterativo cuyas direferentes iteraciones se distribuyen a travs de cuatro fases: Inicio, Elaboracin, Construccin y Transicin. En las cuales se desarrollan transversalmente una serie de subprocesos entendiendose estos ultimos como un conjunto de actividades (Procedimientos), personas (Roles), prcticas (Guias) y productos de trabajo (Artefactos) que guan el proceso de desarrollo de software a travs de las cuatro fases.

Cada fase puede tener tantas iteraciones (Iter) como se requiera, dependiendo del grado de complejidad y desconocimiento del dominio, la tecnologa a ser usada, la complejidad arquitectnica y el tamao 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 rpidamente planifiquen sus iteraciones. Las iteraciones pueden tener diferentes longitudes de tiempo, dependiendo de las caractersticas del proyecto, Iteraciones de un (1) mes son recomendadas de tal forma que los informes de gestin del personal asociado coincida con los fines de iteracin de tal forma que: En este tiempo se muestre un incremento en la funcionalidad. Se utilice como mecanismo de retroalimentacin por parte de los usuarios. Se administre de forma rpida y proactiva los riesgos y problemas presentados en el proyecto. El OpenUP/OAS se plantea para ofrecer una gua a equipos pequeos 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 propsito 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 solucin proyectada:

1. Entender qu construir. Determine la Visin, el alcance del sistema y sus lmites, e

identifique quin est interesado en este sistema y por qu.

2. Identifique la funcionalidad clave del sistema. Decida qu requerimientos son los ms

crticos.

3. Determine al menos una posible solucin. Identifique al menos una arquitectura

candidata y su viabilidad.

%. Entienda el costo, el cronograma y los riesgos asociados al proyecto.

Los proyectos podran tener una o ms iteraciones en la fase de inicio. Entre otras razones, para tener mltiples iteraciones en la fase de inicio, usted encontrar: El proyecto es grande y es difcil definir su alcance. Sistemas sin precedentes. Muchos itneresados con necesidades encontradas y relaciones complejas. Mayores riesgos tcnicos que demandan la creacin 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 visin y crear un plan de proyecto. Esta actividad tiene lugar al inicio de la primera iteracin, cuando el proyecto inicia. El objetivo de esta actividad es establecer la visin 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 Visin para el proyecto, capturando las necesidades de los usuarios y las caractersticas del sistema en desarrollo. Las necesidades y caractersticas son capturadas para alcanzar acuerdos (contratos) acerca del mbito del proyecto.

El lder o gua 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 asignacin de personal para el proyecto, evoluciona durante las fases y marca el ritmo del proyecto.

B. Planear y gestionar la Iteracin Iniciar la iteracin 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 travs del ciclo de vida del proyecto. El objetivo de esta actividad es identificar riesgos y factores con suficiente anticipacin como para poder ser mitigados, para establecer los logros de la iteracin y apoyar al equipo de trabajo en el alcance de sus metas.

El lider del proyecto y el equipo lanza la iteracin. La priorizacin del trabajo para una iteracin dada toma lugar. El lider del proyecto, los interesados y los miembros del equipo acuerdan lo que se supone ser desarrollado durante esa iteracin. Los miembros del equipo de trabajo registran los tems de trabajo que desarrollarn en esa iteracin. Cada miembro del equipo divide los tems del trabajo en tareas de desarrollo y estima el esfuerzo que requieren. As se provee una estimacin ms precisa de la cantidad de tiempo que ser empleada y de lo que puede ser alcanzado en forma realista en una iteracin dada. Al finalizar la ejecucin de la iteracin, el equipo se rene 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 efecta cada da, lo que permite un entendimiento ms preciso de cmo el trabajo progresa en una iteracin. 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 travs de toda la iteracin, y que cada uno conozca el estado del proyecto de una manera oportuna. Durante los hitos de la iteracin, 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 iteracin 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 implementacin y verificacin. Lo anterior no implica que todos los requerimientos estn detallados antes del inicio de la implementacin. Es ms, usted ejecuta esta actividad a travs 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 implementacin y verificacin. Durante el Inicio, el foco se orienta a ganar acuerdo sobre el problema a resolver, captando las necesidades de los interesados y capturando las caractersticas de alto nivel del sistema. Durante la Elaboracin, el foco sigue a la definicin de la solucin. 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 travs de las Listas de Unidades de Trabajo, para la implementacin 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 gua necesaria para la verificacin y validacin.

Durante la Construccin, el foco se deslaza hacia el refinamiento de la definicin del sistema. Este consiste en detallar los requerimientos faltantes y asociados a los casos de prueba tan necesarios para impulsar la implementacin y verificacin, y al manejo de los cambios de requerimientos. D. Llegar a un acuerdo sobre el enfoque tcnico La meta de esta actividad es definir el enfoque tcnico 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 tcnico para el sistema propuesto. Asegurarse de que las decisiones tcnicas se capturen y comuniquen adecuadamente. Asegurarse de que el equipo tiene la suficiente informacin para entender el enfoque que usted est tomando.

El trabajo hecho hasta aqu no busca producir una especificacin tcnica completa y detallada. Por el contrario se deber definir todo el enfoque a un alto nivel tcnico. Usted se debe centrar en proveer la arquitectura con el software trabajando. Si la solucin es similar a la solucin previamente producida, o es un dominio de solucin 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 ms prototipos para validar algunas de las decisiones o clarificar algunos de los requerimientos. La conclusin de este trabajo deber producir justo la suficiente informacin para comunicar la arquitectura al equipo y para demostrar su viabilidad al usuario. Esto le permite al proyecto avanzar, habilitndolo a usted para refinar y delinear la arquitectura.

2.1.2. Fase de Elaboracin

Esta es la segunda fase dentro del ciclo de vida del proyecto. En ella los riesgos arquitectnicamente significativos se identifican y consideran. Hay objetivos para la fase de Elaboracin que le ayudan a direccionar los riesgos asociados con los requisitos, la arquitectura, los costos y el cronograma:

Obtenga un entendimiento ms detallado de los requisitos. Tenga un buen

entendimiento de la mayora de requisitos que le permitan crear un plan ms detallado y obtener ganancia de los interesados. Asegrese de ganar profundidad en el entendimiento de los requisitos ms crticos que sern validados por la arquitectura.

Disear, implementar, validar y establecer la lnea base para la arquitectura . Disee,

implemente y pruebe un esqueleto estructural del sistema. Aunque la funcionalidad no sea

completa an, muchas de las interfaces entre los bloques de construccin 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 tcnicos se gestionan como resultado de detallar los requisitos y disear, implementar y probar la arquitectura. Refine y detalle el plan de proyecto de alto nivel.

El nmero de iteraciones en la fase de Elaboracin 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 tecnologa y la arquitectura, y as sucesivamente. Tpicamente, sobre la primera iteracin usted debera disear, implementar y probar un pequeo nmero de escenarios crticos para identificar qu tipo de arquitectura y mecanismos arquitectnicos necesita, que usted pueda mitigar los riegos ms cruciales. Tambin 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 iteracin previa. Usted disea, implementa y prueba los escenarios restantes arquitectnicamente significativos, asegurndose de chequear todas las reas importantes del sistema (cobertura arquitectnica), as los riesgos ocultos potenciales se hacen visibles lo ms rpido posible.

Actividades en la Fase de Elaboracin A. Planificacin y gestin de la iteracin

B. Identificacin y refinamiento de los requisitos C. Desarrollo de la Arquitectura D. Desarrollar los requisitos arquitecturalmente significativos y priorizados para esta iteracin. Esta actividad refina la arquitectura inicial de alto nivel en software de trabajo. El objetivo es producir software estable que maneje adecuadamente los riesgos tcnicos en perspectiva. Los arquitectos y desarrolladores trabajan juntos para: Refinar el esquema inicial de la arquitectura en elementos de diseo concretos Asegurar que las decisiones de arquitectura se capturan y comunican adecuadamente Asegurar que el equipo tiene suficiente informacin para habilitar el software a ser desarrollado. Asegurar que los requerimientos que fueron priorizados para la iteracin 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

perspectiva de la actual iteracin, mientras toma decisiones en el contexto de todo el proyecto. E. Desarrollar un incremento de solucin Disear, implementar, probar e integrar la solucin a un requisito dentro de un contexto dado. Aqu los desarrolladores crean una solucin para el tem de trabajo del cual se han hecho responsables, de manera que la administracin 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 planeacin y ejecucin basada en metas. El trabajo tomado por los desarrolladores, y su progreso, se supervisa con base en los logros alcanzados utilizando el diseo, las pruebas del desarrollo y la integracin del cdigo 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 iteracin. El desarrollo puede enfocarse en una capa, tal como la interfaz de usuario, lgica 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 diseo e implementacin para ese requerimiento. El desarrollador tambin escribe y corre las pruebas de desarrollo contra la implementacin para asegurar que trabaja segn el diseo, tanto independientemente, como integrado al cdigo base. Los cambios requieren algn esfuerzo en el diseo de la solucin antes de pasar a la implementacin, an si es solamente un ejercicio mental que resulta en una unidad de trabajo de corto tiempo. El diseo para cambios triviales en la implementacin existente, por ejemplo, soportar algunos requerimientos, puede ser evidente por s mismo en el contexto de la arquitectura y diseo existente. Una vez que la organizacin de la solucin tcnica es clara, defina las pruebas de desarrollo que verificarn la implementacin. Este enfoque impulsado por pruebas asegura que las consideraciones de diseo sean tomadas en cuenta antes que la solucin sea codificada. Las pruebas se corren, y si fallan, claramente definen el criterio para determinar si la implementacin trabaja como se deseaba. Los errores en las pruebas conducen a la implementacin de la solucin, por esto, hasta su finalizacin se ejecutan nuevamente los ensayos. Este bucle ms interno de la implementacin y pruebas de desarrollado se repite hasta que se aprueben las pruebas. Pasar las pruebas no necesariamente significa que la solucin sea de alta calidad o que sea apropiada. Es conveniente volver a visitar el diseo en este punto. Esta ruta nos lleva de regreso a travs del proceso, ya que algunos cambios en el diseo podran afectar las pruebas de desarrollo y la implementacin. Una vez aprobadas las pruebas y el diseo de la solucin es apropiado, existe todava la posibilidad de una retroalimentacin adicional. Lo mejor es mantener el modelo test-driven evolucionando en ciclos internos tanto como sea posible. Avanzando con varios diseos de solucin a pequea escala para una parte del tem del trabajo, defina una prueba o dos para la implementacin de una parte de la solucin, y al aprobarla, verifique la calidad, y entonces, contine como en la primera prueba hasta que esta parte del diseo est trabajando. Luego, en el

ciclo ms avanzado de la actividad, regrese al tem de trabajo y disee otra parte para acercarse ms a su finalizacin F. Probar la solucin 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 construccin del sistema satisface los requerimientos definidos para ella. A travs 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 solucin para los requerimientos de la iteracin dada, se integra el cdigo 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 solucin, la cual est siendo integrada continuamente, satisface el requerimiento especificado en los casos de prueba. El responsable de las pruebas define qu tcnicas utilizar, cules datos de entrada y qu conjunto de pruebas crear. Cuando las pruebas corren, los defectos se identifican y aaden 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 Construccin

Esta es la tercera fase del proceso que se enfoca en detallar los requisitos, disear, implementar y probar el grueso del software. El propsito de esta fase es completar el desarrollo del sistema basado en la arquitectura. Hay objetivos para la fase de Construccin que nos ayudan a tener un desarrollo costo-eficiente de un producto completo, una versin operativa del sistema, que pueda ser entregada a la comunidad de usuarios: 1. Desarrolle iterativamente un producto completo que est listo para hacer transicin a su comunidad de usuarios. Describa los requisitos restantes, complete en detalles los diseos, complete la implementacin y prueba del software. Libere la primera versin operativa del software (beta) del sistema y determine si los usuarios estn listos para que la aplicacin sea desplegada. 2. Minimice el costo de desarrollo y alcance algn 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. Tpicamente, la fase de Construccin tiene ms iteraciones, dos o cuatro, que las otras fases,

dependiendo del tipo de proyecto: Proyecto Simple: Una iteracin para construir el producto (a una liberacin beta) Proyectos ms considerables: Una iteracin para exponer un sistema parcial y una para madurar este a un beta testing Proyectos grandes: Tres o ms iteraciones, dado el tamao del proyecto (nmero de requisitos a implementar para una liberacin beta)

Actividades de la Fase de Construccin

1. Planificacin y gestin de la iteracin 2. Identificar y refinar requisitos 3. Desarrollar un incremento de solucin 4. Probar la solucin

2.1.4. Fase de Transicin

Es la cuarta fase del proceso. Se enfoca en la transicin del producto de software a la plataforma tecnolgica del cliente logrando que los interesados convengan que el desarrollo del producto cumple con los requisitos planteados. El propsito de esta fase es asegurar que el producto de software est listo para ser distribuido a los usuarios. Hay objetivos para la fase de Transicin que le ayudan a afinar elegantemente la funcionalidad, el desempeo y la calidad total de la versin beta del producto desde el final de la fase previa:

1. La prueba beta valida que las expectativas del usuario sean satisfechas. Esto
tpicamente requiere algunas actividades de afinamiento, tales como depuracin de errores y mejora del desempeo 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 aceptacin del producto, incluyendo pruebas formales e informales y pruebas beta.

3. Mejorar el desempeo en futuros proyectos a travs 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 transicin puede incluir ejecutar sistemas nuevos y viejos en paralelo, migrar datos, entrenar los usuarios y ajustar los procesos del negocio. El nmero de iteraciones en la fase de transicin vara desde una iteracin para un sistema

10

simple, requiriendo, principalmente, menor depuracin de errores, a muchas iteraciones para un sistema complejo, involucrando adicin de caractersticas y desarrollo de actividades para hacer la transicin del negocio desde usar el viejo sistema a usar el nuevo sistema. Cuando se alcanzan los objetivos de la fase de Transicin, 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 generacin del mismo producto. Actividades de la Fase de Transicin 1. 2. 3. 4. Planificacin y gestin de la iteracin Identificar y refinar requisitos Desarrollar un incremento de solucin Probar la solucin 5. Tareas adicionales

2.2.SUBPROCESOS DEL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS

Como se habia sealado 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 prcticas 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 Concebir un nuevo proyecto Requerimientos y Requisitos Gestin del Proyecto Gestin del Riesgo Arquitectura

Objetivo Concebir y definir un proyecto de software, con el fin de evaluar su viabilidad tcnica, tecnolgica, organizacional, ambiental y financiera. Recolectar, analizar, aprobar y seguir la evolucin de los requerimientos funcionales del Cliente o interesado y los requisitos del software a travs de la vida del producto y/o servicio. Planear, ejecutar , controlar y socializar las actividades y resultados de un proyecto de software. Identificacin, valoracin, relevancia, prevencin, mitigacin, control y respuesta a posibles riesgos que se generen en un proyecto de software. Transformar los requerimientos y requisitos significativos en una arquitectura que describa su estructura e identifique los componentes

11

del software. Diseo Desarrollo Gestin de Pruebas Gestin de Cambios Implantacin Gestin Documental Gestin de Auditorias Gestin de Plataforma Tecnlogica 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 Proporcionar un diseo que implemente el software y pueda ser verificado contra los requerimientos y los requisitos definidos. Implementar una solucin tcnica que cumpla con la arquitectura definida y soporte los requerimientos de los grupos interesados. Disear, implementar, ejecutar y evaluar pruebas en cada uno de los componentes desarrollados. Registrar, revisar y llevar a cabo solicitudes de cambios generadas en un proceso de desarrollo de software. Planificar y llevar a cabo la produccin de una solucin de software mediante el alineamiento de las necesidades de capacitacin de los usuarios y el desarrollo de pruebas de funcionamiento. Planificar, elaborar, aprobar, organizar y controlar la documentacin requerida en un proceso de desarrollo de software. Planificar y ejecutar auditorias internas a proyectos de software con el fin de encaminarlos a una mejora continua

A continuacin se presenta el mapa de suprocesos del proceso de desarrollo OPENUP/OAS agrupados en cuatro tipos de suprocesos (Gestin, Principales, Apoyo y Mejoramiento Continuo).

12

Subprocesos de Gestin

2.2.1. Subproceso de Gestin del proyecto

Este subproceso explica como entrenar, sincronizar y apoyar el equipo de desarrollo, ayudndolo a manejar los obstculos 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 propsitos que persigue este subproceso son: Fomentar el consenso entre el grupo de inters para priorizar las unidades de trabajo. Estimular la colaboracin en el equipo creando planes de corto y largo plazo para el proyecto. Enfocar el equipo en la liberacin continua de software probado y listo para la evaluacin por parte del grupo de inters. Ayudar a crear un ambiente de trabajo efectivo para maximizar la productividad del equipo. Mantener al grupo de inters 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 Gestin de Proyecto cubre y es afectado por todas los dems subprocesos. Las actividades de este subproceso adicionan valor al proyecto al crear ambientes de trabajo de alto desempeo donde: Los grupos de inters confian en las habilidades del equipo para distribuir exitosamente soluciones y entender las capacidades de la plataforma tecnolgica. 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 Gestin de Riesgos

Este subproceso brinda una herramienta de administracin de riesgos basada en los postulados de la Metodologa de Anlisis y Gestin de Riesgos de los Sistemas de Informacin de las Administraciones pblicas - MAGERIT , que gui la identificacin, valoracin, relevancia, prevencin, mitigacin, control y respuesta a posibles riesgos que se generen en el proceso de desarrollo de un proyecto de software. Los Objetivos especficos de este subproceso son: Concientizacin del equipo de desarrollo (Usuarios, analistas, arquitectos, desarrolladores y

1%

gestores) de la existencia de los Riesgos y la necesidad de manejarlos oportunamente. Definir un mtodo sistemtico y practico que permita valorar y analizar los riesgos que se identifiquen a lo largo del proyecto. Guiar la definicin de las medidas de seguimiento, mitigacin y control de los riesgos crticos que afectan la consecucin de los objetivos de un proyecto de desarrollo de software.

1/

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 propsito de este subproceso son: Entender el problema que debe resolverse Entender las necesidades del grupo de inters, lo que el usuario necesita Definir los requerimientosy requisitos que debe cumplir la solucin, lo que le sistema debe hacer Definir las fronteras que determinan el mbito del sistema Identificar las interfaces externas del sistema Identificar las restricciones tcnicas que tiene la solucin Proveer las bases para la planificacin de las iteraciones Proveer las bases para la estimacin de costos y el cronograma Para alcanzar estas metas es importante entender tanto la definicin como el mbito del problema que se trata de resolver e identificar los grupos de inters. 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 travs 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 Gestin de Pruebas que valida el sistema contra lo especificado en el subproceso de requisitos. El subproceso de Gestin de Cambios provee mecanismos para administrar los cambios en los requerimiento y requisitos.

El subproceso de Gestin del Proyecto planifica el proyecto y asigna los requerimiento y

requisitos a cada iteracin a partir del anlisis de los requerimientos y requisitos priorizados y la asignacin de unidades de trabajo.

1!

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 propsito 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 arquitectnicamente significativos. El subproceso Desarrollo disea e implementa la arquitectura. El subproceso de Gestin de Pruebas verifica la estabilidad y precisin de la arquitectura. El subproceso de Gestin del Proyecto planifica el proyecto para que ciertos componentes de la arquitectura se desarrollen en cada iteracin.

2.2.5. Subproceso de Diseo

Este subproceso explica como disear una solucin tcnica que cumple con la arquitectura y soporta los requerimientos de los grupos interesados. El propsito de este subproceso es: Transformar los requisitos en un diseo de sistema. Adaptar el diseo para que se acople al ambiente de implementacin. Este subproceso est relacionada con otros subprocesos de la siguiente forma:

El Subproceso de Requerimientos y Requisitos define los que ser diseado El Subproceso de Arquitectura organiza y restringe el diseo. El subproceso de Gestin del Proyecto planifica qu funcionalidad ser diseada en cada iteracin.

11

2.2.6. Subproceso de Desarrollo

Este subproceso explica como implementar una solucin tcnica que cumple con la arquitectura y soporta los requerimientos de los grupos de interesados. El propsito de este subproceso es: Construir el sistema incrementalmente. Verificar que las unidades tcnicas usadas para crear el sistema, trabajan segn lo especificado. Con cada iteracin, las tareas en el subproceso evolucionarn para tener una Construccin 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 Diseo define los que ser implementado. El Subproceso de Arquitectura organiza y restringe la implementacin. El subproceso de Gestin de Pruebas valida que la construccin del sistema cumple con lo requisitos. El subproceso de Gestin de Cambios provee los mecanismos para administrar los cambios en la construccin. El subproceso de Gestin del Proyecto planifica qu funcionalidad ser implementada en cada iteracin.

2.2.7. Subproceso de Gestin de Pruebas

Este subproceso explica cmo proveer retroalimentacin al equipo de desarrollo acerca de la evolucin del sistema a travs del diseo, implementacin, ejecucin y evaluacin de pruebas en cada uno de los componentes desarrollados. El propsito de este subproceso es: Proveer retroalimentacin 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 solucin 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, diseos e implementaciones tan pronto como sea posible.

12

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 iteracin del ciclo de vida, siendo la primera la que gua las posteriores. De hecho, es comn para una iteracin 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 aplicacin para que se pueda considerar que cumple con los requerimientos establecidos? Este subproceso pone a prueba la hiptesis, riesgos e incertidumbres inherentes al desarrollo y aborda estas preocupaciones mediante demostracin concreta e imparcial. El subproceso de Pruebas se relaciona con los demas subprocesos de la siguiente manera: Subproceso de Requerimientos y Requisitos: Identifica el propsito 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 evaluacin de las pruebas que se aplican en esta subproceso. En cada iteracin las pruebas proporcionan una retroalimentacin objetiva. Una prueba eficaz permite a los desarrolladores centrarse en la aplicacin de nuevas funcionalidades y mejorar el desempeo del sistema. Subproceso de Gestin del Proyecto: el subproceso de pruebas proporciona una medida objetiva de progreso, permitiendo una planificacin adaptativa. El subproceso de Gestin de Cambios. El subproceso de pruebas verifica el esfuerzo que cada cambio en la solucin.

2.2.8. Subproceso de Gestin de Cambios

Este subproceso explica el control de cambios en los artefactos, asegurando una evolucin sincronizada del conjunto de productos de trabajo que componen el sistema de software. Los propsitos 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 Gestin del Cambio se refiere al proceso de gestin de los cambios de la versin controlada por los artefactos, y hace frente a los dos ltimos objetivos enumerados anteriormente.

1$

Aunque es importante mantener al da las versiones y configuraciones de todos los productos de trabajo, esta es la principal preocupacin de los artefactos en la fase de Construccin. Este subproceso abarca la totalidad del ciclo de vida. La gestin del cambio la realizan todos los miembros del equipo de desarrollo, y debido a la importancia y generalizacin de este subproceso, la gestin del cambio de orientacin se asocia con las tareas y trabajos en todos los productos de otros subprocesos.

2.2.9. Subproceso de Implantacin

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 ejecucin 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 transicin, debido a que su propsito es asegurar una aprobacin y adaptacin 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 planificacin, pero tambin con la elaboracin del manual de usuario y tutoriales.

Subprocesos de Apoyo

2.2.10. Subproceso de Gestin Documental

Este subproceso representa un gran soporte para otros subprocesos en la medida que permite gestionar la informacin 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 sistemtica la creacin, organizacin, gestin, conservacin y eliminacin de documentos digitales e impresos generados al interior de los proyectos.

2'

El proposito del subproceso de la gestin 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 documentacin que se puede gestionar en este subproceso: Los procedimientos y guias definidos para gestionar la documentacin generada a lo largo del ciclo de vida del proceso de desarrollo openup/oas. Los documentos de trabajos propios de los dems subprocesos como diseo, desarrollo, arquitectectura entre otros , tales como diagrama entidad relacion. La documentacin que soporta la revisin de procedimientos propios del proceso de desarrollo openup/oas a traves de Auditorias. La documentacin elaborada para el usuario final, los cuales describen la funcionalidad del software o sistema desarrollado.

Los propositos del Subproceso de Gestin 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 (Identifacin, control de versiones, almacenamiento , entre otros). - Determinar los requerimientos de documentacin 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 documentacin 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 aprobacin. Actualizacin y mantenimiento de la documentacin generada de acuerdo a las directrices definidas previamente.

21

2.2.11. Gestin de Platofoma Tecnlogica

El propsito 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 fsica y de acceso, disponibilidad, requerimientos de espacio, equipos, costos , limitaciones de tiempo. entre otros) Gestionar la adquisicin de la infraestructura tecnologica cuando sea necesario Implementacin de la Infraestructura tecnologica ( Planificar y documentar la configuracin de la infraestructura Mantenimiento de una infraestructura estable y fiable. (Mantenimiento, seguimiento y modificacin de la infraestructura segn sea necesario para asegurar que contina satisfaciendo los requerimientos del subproceso o proyecto al cual soporta).

Subprocesos de Mejoramiento Continuo

2.2.12. Gestin de Auditorias

El subproceso de Gestin de Auditoria cumple un papel fundamental en el ciclo de vida del proceso de desarrollo, dentro de sus propositos esta la revisin de la aplicabilidad de los postulados y directrices del openup/oas, asi como la evaluacin de la funcionalidad, confiabilidad, disponibilidad e intergridad de la informacin que administra el producto, mdulo o funcin de software que se ha generando. El objetivo de este subproceso es mantener un entendimiento comn 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 auditora es un proceso para determinar el cumplimiento con los requerimientos, planes o directrices segn aplique.

22

El trabajo de este subproceso se logra a travs de diferentes tipos de auditoras y revisiones. Los propositos de la Gestin 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 da las actividades propias del equipo de desarrollo
(procesos, producto, documentacin etc...) debido a las exigencia que esta demanda. producto de software. Se debern llevar a cabo auditoras para asegurar que: Los productos software reflejan efectivamente los requerimientos y requisitos definidos previamente. Existe documentacin 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.

Mejoramiento continuo de las directrices del proceso de desarrollo openup/oas y la calidad del

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 gestin de procesos de desarrollo de software que permitan un incremento de valor del mismo. Llevar a cabo un seguimiento, control y evaluacin continua y periodica de la aplicacin 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