Cap2CicloVidaProcesoDesarollo

5/27/2018 Cap2CicloVidaProcesoDesarollo

1/23

ndice de contenido2. EL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS...............................2

2.1. Fases del Proceso de Desarrollo ...................................................................................................32.1.1. Fase de Inicio..............................................................................................................................3

2.1.2. Fase de Elaboracin....................................................................................................................!2.1.3. Fase de Cons"r#ccin .................................................................................................................$

2.1.%. Fase de &ransicin....................................................................................................................1'

2.2.SU(PROCESOS DEL CICLO DE VIDA DEL PROCESO DE DESARROLLO OPENUP/OAS............................................................................................................................................................11

2.2.1. S#b)roceso de *es"in del )ro+ec"o .......................................................................................1%2.2.2. S#b)roceso de *es"in de Ries,os...........................................................................................1%

2.2.3. S#b)roceso de Re-#eriien"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.. S#b)roceso de *es"in de Pr#ebas...........................................................................................1

2.2.. S#b)roceso de *es"in de Cabios.........................................................................................1

2.2.$. S#b)roceso de I)lan"acin....................................................................................................1

2.2.1'. S#b)roceso de *es"in Doc#en"al.......................................................................................1$2.2.11. *es"in de Pla"ooa &ecnolo,ica........................................................................................2'2.2.12. *es"in de A#di"orias ............................................................................................................21

2.2.13. S#b)roceso de 4e5ora del Proceso de Desarrollo ................................................................22


2/23

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.


3/23

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 Josde 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 estinteresado en este sistema y por qu.

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

crticos.

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

candidata y su viabilidad.

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


4/23

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.


5/23

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 serdesarrollado 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. Asse provee una estimacin ms precisa de la cantidad de tiempo que

serempleada 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 unentendimiento 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 gu a necesaria

para la verificacin y validacin.


6/23

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 deberhacer 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 esttomando.

El trabajo hecho hasta aquno busca producir una especificacin tcnica completa y detallada.

Por el contrario se deberdefinir 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, sersuficiente 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 deberproducir 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.

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


7/23

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 assucesivamente.

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), aslos 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


8/23

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, asse

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 esttrabajando. Luego, en el


9/23

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 implementadosreflejen 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 qutcnicas utilizar, cules datos de entrada y quconjunto de pruebas crear. Cuando las

pruebas corren, los defectos se identifican y aaden tems a las listas de trabajo, ases como

stos pueden priorizarse como parte del trabajo que usted realizardurante 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 Construcci

n tiene m

s iteraciones, dos o cuatro, que las otras fases,


10/23

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 Construcci

n

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 estlisto 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 betadel 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 estcompleto. 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


11/23

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. Planificacin y gestin de la iteracin

2. Identificar y refinar requisitos

3. Desarrollar un incremento de solucin

4. 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 yactividades 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 tcnica, tecnolgica, organizacional, ambiental y financiera.

Requerimientos y

Requisitos

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.

Gestin del ProyectoPlanear, ejecutar , controlar y socializar las actividades y resultados de

un proyecto de software.

Gestin del Riesgo

Identificacin, valoracin, relevancia, prevencin, mitigacin, 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


12/23

del software.

DiseoProporcionar un diseo que implemente el software y pueda ser

verificado contra los requerimientos y los requisitos definidos.

Desarrollo

Implementar una solucin tcnica que cumpla con la

arquitectura definida y soporte los requerimientos de los grupos

interesados.

Gestin de PruebasDisear, implementar, ejecutar y evaluar pruebas en cada uno de los

componentes desarrollados.

Gestin de Cambios Registrar, revisar y llevar a cabo solicitudes de cambios generadas enun proceso de desarrollo de software.

Implantacin

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.

Gestin DocumentalPlanificar, elaborar, aprobar, organizar y controlar la documentacin

requerida en un proceso de desarrollo de software.

Gestin de AuditoriasPlanificar y ejecutar auditorias internas a proyectos de software con el

fin de encaminarlos a una mejora continua

Gesti

n de PlataformaTecnlogica

Proceso de Desarrollo

Explorar, adaptar, acoger, evaluar y mejorar de manera incremental e

iterativa los lineamientos y directrices propios del proceso de desarrollo

unificado OPENUP/OAS

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).


13/23


14/23

Subprocesos de Gestin

2.2.1. Subproceso de Gestin del proyectoEste 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 dem

s subprocesos. Lasactividades 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 RiesgosEste 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 lasAdministraciones pblicas - MAGERIT , que guila 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%


15/23

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


16/23

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 Pruebasque 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 Proyectoplanifica el proyecto y asigna los requerimiento yrequisitos a cada iteracin a partir del anlisis de los requerimientos y requisitos priorizados y

la asignacin de unidades de trabajo.

1!


17/23

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 estrelacionada con otros subprocesos de la siguiente manera:

El subproceso de Requerimientos y Requisitos proporciona los requisitosarquitectnicamente 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 Proyectoplanifica 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 estrelacionada con otros subprocesos de la siguiente forma:

El Subproceso de Requerimientos y Requisitos define los que serdiseado

El Subproceso de Arquitectura organiza y restringe el diseo.

El subproceso de Gestin del Proyecto planifica qu funcionalidad serdiseada en cada

iteracin.

1


18/23

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.


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 estrelacionada con otros subprocesos de la siguiente forma:

El Subproceso de Diseodefine los que serimplementado.

El Subproceso de Arquitectura organiza y restringe la implementacin.

El subproceso de Gestin de Pruebasvalida que la construccin del sistema cumple con lo

requisitos.

El subproceso deGesti

n 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.


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.

1


19/23

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 gu a 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: "Qufunciones 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 quecada 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$


20/23

Aunque es importante mantener al da las versiones y configuraciones de todos los productos detrabajo, 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 especificasdel 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, parapreparar 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'


21/23

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 desarrolloopenup/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 surespectiva evaluacion y aprobacin.

Actualizacin y mantenimiento de la documentacin generada de acuerdo a las directrices

definidas previamente.

21


22/23

2.2.11. Gesti

n de Platofoma Tecn

logicaEl 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 AuditoriasEl 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 encaminadoa 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


23/23

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.

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

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.

2.2.13. Subproceso de Mejora del Proceso de DesarrolloEste 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 lasdirectrices 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

Cap2CicloVidaProcesoDesarollo

Documents

Transcript of Cap2CicloVidaProcesoDesarollo