Artefactos de Entrada: Planteamiento de Arquitectura Inicial, Mecanismos de Diseño (Patrones), Prototipo de Sistema, Requerimiento de Sistema, Arquitectura del Sistema
Artefactos de Salida: Arquitectura del Sistema, Mecanismos de Implementación, Especificación de Diseño
Actores Involucrados: Analista, Arquitecto
Descripción (ver Figura 9 ):
El objetivo que se intenta alcanzar es de lograr una definición técnica de cómo debe construirse el sistema. Esta definición debe contemplar todas las decisiones a tomar al momento de construir la solución, incluyendo aspectos de arquitectura, de diseño particular, etc. En este contexto el diseño existe como un facilitador para transformar los requerimientos en código ejecutable, conteniendo las guías necesarias para lograr la fabricación de la aplicación.
Después de realizar el análisis de los requerimientos se deben aplicar los mecanismos de diseño establecidos y junto a los prototipos no funcionales desarrollados en la disciplina anterior se debe producir la Especificaciones de Diseño para cada caso tomando en cuenta la arquitectura planteada para el sistema para poder definir exactamente cómo el sistema va a producir el comportamiento definido. La obtención de la Especificación de Diseño de la aplicación posee las ventajas de que provee una mejor visualización de las dependencias y del uso de los componentes, algo esencial al momento de tener que realizar una modificación; lo mismo trae a su vez la desventaja de que los diseños se deben mantener y esta mantención debe realizarse junto con la del código fuente, si se espera beneficiarse posteriormente de estos planos de diseño.
A medida que se van diseñando los componentes del sistema se debe ir completando la Arquitectura del Sistema con más detalle. Al finalizar la fase de Elaboración se debiera tener un plano completo del sistema, ya que a este punto es posible predecir la cantidad y los tipos de componentes que generará el sistema. También en este punto deben generarse los mecanismos de implementación para cada mecanismo de diseño establecido que aún no tenga definida su forma de implementar.
Figura 9: Realizar Análisis y Diseño de la Solución
Nombre: Desarrollar Solución Sistémica
Artefactos de Entrada: Arquitectura del Sistema, Prototipo de Sistema, Especificación de Diseño, Mecanismos de Implementación
Artefactos de Salida: Pruebas Unitarias, Componente de Software
Actores Involucrados: Desarrollador, Analista
Descripción:
El objetivo principal es producir las piezas de código especificadas de la manera más eficiente y eficaz posible. Los desarrolladores deben tomar las Especificaciones de Diseño y los Prototipos del Sistema y, luego de revisarlos, debe generar los componentes de código que sean necesarios de acuerdo a la especificación y siguiendo los mecanismos de implementación. Junto con la construcción de cada componente se deben generar Pruebas Unitarias para las mismas que aseguren su correcto comportamiento. Para ello estos deben conocer en profundidad la herramienta de desarrollo y estar familiarizados con el lenguaje utilizado en las especificaciones.
Nombre: Asegurar Correctitud y Funcionalidad de la Solución
Artefactos de Entrada: Requerimiento de Sistema, Especificación de Diseño, Prototipo de Sistema, Componente de Software, Criterios de Aceptación
Artefactos de Salida: Pruebas de Funcionalidad, Incidencias
Actores Involucrados: Analista, Desarrollador, Tester
Descripción (ver Figura 10)
Esta disciplina tiene por objetivos asegurar dos cosas: que se está construyendo la pieza adecuada para el trabajo y que dicha pieza está construida de la manera correcta.
En primera instancia se deben elaborar pruebas funcionales para los requerimientos que están siendo desarrollados. Se debe tener en cuenta tanto el Requerimiento de Sistema y su prototipo como la Especificación de Diseño para generar la prueba funcional que esté probando todos los escenarios necesarios para lograr la mayor cobertura posible del código. Al generar la prueba se deben tener en cuenta además los Criterios de Aceptación definidos por el cliente de manera de que las pruebas funcionales aseguren cobertura de estos criterios.
Las pruebas son ejecutadas por un actor no involucrado en el análisis ni desarrollo del componente con el objetivo de generar Incidencias cuando los resultados esperados no concuerdan con los obtenidos, para que estos puedan ser corregidos por los desarrolladores y luego las pruebas ser ejecutadas nuevamente hasta lograr un resultado satisfactorio, es decir, el cumplimiento de los Criterios de Aceptación.
Figura 10: Asegurar Correctitud y Funcionalidad de la Solución
Nombre: Desplegar Solución
Artefactos de Entrada: Arquitectura de Sistema, Componente de Software.
Artefactos de Salida: Versión desplegada del sistema, Documentación de Despliegue.
Actores Involucrados: Arquitecto, Integrador
Descripción:
En el despliegue se debe instalar o asegurar la instalación de los componentes de software desarrollados en los ambientes computacionales que corresponda. Lo relevante en esta etapa es tener una versión funcional del sistema desarrollado y no módulos sueltos que no se puedan probar ni instalar. Es importante además actualizar la documentación con los nuevos componentes desplegados. Se considera útil tener una versión desplegada desde los primeros componentes construidos, ya que para cuando se termine el desarrollo del sistema estos componentes ya habrán estado en producción por un tiempo, reduciendo la cantidad de errores potenciales no encontrados.
La Fase de Transición tiene por finalidad asegurar que el sistema desarrollado esté disponible para los usuarios finales. Esto implica que se lleven a cabo las pruebas de certificación del software en el ambiente de control de calidad y se genere además la documentación final necesaria para su utilización en producción. En el diagrama de la Figura 11 se presenta modelada esta fase.
Figura 11: Fase de Transición
A esta altura todos los procesos se encuentran detallados en la disciplina de Describir el Problema de Negocio, todos los requerimientos ya han sido completamente detallados y analizados en la disciplina de Especificar Requerimientos de la Solución, el diseño completo de la aplicación debe estar completo en la disciplina de Realizar Análisis y Diseño de la Solución y todos los componentes necesarios ya deben haber sido desarrollados en la disciplina Desarrollar Solución Sistémica, por lo que no se entrará en detalle en estas disciplinas para su documentación.
Nombre: Asegurar Correctitud y Funcionalidad de la Solución
Artefactos de Entrada: Pruebas de Aceptación
Artefactos de Salida: Incidencias.
Actores Involucrados: Jefe de Proyecto, Cliente
Descripción:
Acá se deben ejecutar las pruebas de aceptación definidas por el cliente. Cualquier inconformidad genera una incidencia que debe ser revisada. La conformidad de las pruebas de aceptación es un hito importante que debe ser registrado.
Nombre: Desplegar Solución
Artefactos de Entrada: Componente de Software, Versión desplegada del sistema
Artefactos de Salida: Documentación de Despliegue, Versión 1.0.0
Actores Involucrados: Integrador
Descripción:
Se genera la primera versión del sistema, en función de sus componentes de software construidas y probadas y de las versiones desplegables que se han generado del sistema hasta ese momento. Se asocia en esta disciplina la generación de instaladores y de documentación de instalación y operación necesaria para las personas que serán luego las encargadas de mantener el sistema operando dentro de los rangos de rendimiento necesarios. Además se debe realizar el despliegue final sobre el ambiente de producción de la primera versión del sistema y se hace una copia de esta versión para entrega al cliente junto con la documentación final.
Artefactos
Los artefactos generados y utilizados en los diagramas de procesos mostrados anteriormente serán detallados a continuación. Dentro de este detalle se incluyen:
Nombre: Nombre utilizado para referirse al artefacto.
Tipo: Si el artefacto corresponde a un Diagrama de Clase, Diagrama de Casos de Uso, Diagrama de Componentes, Diagrama de Despliegue, Diagrama de Actividades, Documento o Código, Ejecutable.
Actores Responsables: Persona, rol u organización encargada de la producción y mantención del artefacto. Típicamente es quien lo genera.
Descripción: Describe los objetivos y usos del artefacto.
Nombre: Bases de Licitación
Tipo: Documento
Actores Responsables: Cliente
Descripción
Las bases de Licitación deber ser revisadas en busca de requerimientos específicos con respecto a la entrega de productos al cliente.
Nombre: Contrato y Anexos
Tipo: Documento
Actores Responsables: ORDEN Integración y Cliente.
Descripción
El contrato es un acuerdo pactado entre ORDEN Integración y la empresa cliente en el cual se definen una serie de compromisos y responsabilidades entre ambas partes que deben ser cumplidas. Los Anexos son documentos extra como minutas de reuniones con el cliente, entrevistas, etc.
Nombre: Descripción de la Solución
Tipo: Documento
Actores responsables: Equipo de Proyecto
Descripción
Corresponde a una breve descripción de la Solución. Debe contener:
– Planteamiento de la arquitectura: Consiste en un diagrama de subsistemas o componentes estimados a partir de los requerimientos detectados y un diagrama de despliegue que contenga los requerimientos de plataforma, ubicación de componentes y herramientas.
– Decisiones respecto a tecnologías, frameworks, motores de integración u otros componentes de terceros que se haya decidido utilizar.
Nombre: Visión del Sistema
Tipo: Diagrama de Casos de Uso
Actores Responsables: Jefe de Proyecto
Descripción
Se busca concentrar en un solo lugar la visión original que tiene cada uno de los Stakeholders respecto al sistema. Debe contener los objetivos principales y secundarios que el sistema debe cumplir y una descripción lo más detallada posible del problema de negocio que debe resolver. La visión del sistema una vez establecida queda congelada para poder tener en todo momento una referencia a lo que originalmente el sistema buscaba resolver.
Nombre: Concepto de Dominio
Tipo: Diagrama de Clases
Actores Responsables: Jefe de Proyecto y Analista
Descripción
Se expresa en términos de una clase. Incluye la definición del concepto que se quiere representar y sus principales atributos, que a su vez son definidos como atributos de esa clase. Además incluye las relaciones entre los conceptos en forma de asociaciones con sus diversos estereotipos. Al conjunto completo de conceptos con sus relaciones se le llama Diagrama de Dominio ya que representa todos los conceptos involucrados de alguna manera en el ámbito o dominio del problema.
Nombre: Proceso de Negocio
Tipo: Diagrama de Actividades
Actores Responsables: Jefe de Proyecto y Analista de la Fábrica de Software
Descripción
Incluye los procesos junto con los eventos que los gatillan, los trabajadores y objetos involucrados en la organización y los ámbitos en los que se estima que el sistema tenga influencia. Los procesos deben estar debidamente descritos con el nivel de detalle que corresponda; se espera que puedan relacionarse en términos de sus entradas y salidas. Esto para poder a futuro identificar las partes de la aplicación que van a ser sistematizadas. Los conceptos mencionados en los procesos como entradas, salidas, etc. deben estar definidos en los conceptos de dominio, para asegurar un entendimiento de lo que involucra el generar como salida o recibir como entrada el objeto al que se hace referencia.
Nombre: Requerimiento original ofrecido
Tipo: Documento
Actores Responsables: Analista
Descripción
Expresados en la forma original en que fueron ofrecidos al cliente cuando este aceptó el proyecto. Buscan mantener una referencia de lo que se ofreció originalmente y conocer cuál era el tamaño del proyecto al momento de comenzarlo.
Nombre: Requerimiento de Negocio
Tipo: Documento
Actores Responsables: Analista
Descripción
Se especifican en forma de prosa o de forma textual a como aparecen en los documentos originales (sean bases de licitación, documentos de reuniones, etc.). Buscan preservar en un artefacto los deseos y necesidades originales del cliente para con el sistema al momento de proponer una primera solución.
Nombre: Requerimiento de Sistema
Tipo: Diagrama de Casos de Uso
Actores Responsables: Jefe de Proyecto
Descripción
Deben incluir a los actores involucrados en el sistema, los casos de uso con sus descripciones, escenarios, restricciones y finalmente todo aquello que pueda dar una idea completa sobre qué debe hacer el sistema.
Los Requerimientos de Sistema deben estar relacionados con aquellos Procesos de Negocio que deben ser automatizados y con aquellos Conceptos de Negocio con los cuales deben interactuar. Además deben satisfacer al menos uno de los requerimientos ofrecidos, en caso contrario se considerarán como requerimientos nuevos.
Nombre: Criterios de Aceptación
Tipo: Documento
Actores Responsables: Jefe de Proyecto
Descripción
Los criterios definidos por el cliente para dar por satisfecho el cumplimiento de cada requerimiento. Generalmente escritos en prosa. Esto puede variar desde la definición de una prueba hasta unos índices generales de funcionamiento que se deben poder comprobar con la realización de una prueba funcional.
Nombre: Requerimientos Funcionales
Tipo: Documento
Actores Responsables: Jefe de Proyecto
Descripción
Los requerimientos funcionales representan las características fundamentales del producto final; constituyen una expresión del tamaño del proyecto así como la base de toda su planificación posterior. La volatilidad que experimenten durante el transcurso del proyecto debe ser rigurosamente monitoreada por el Jefe de Proyecto, a fin de evitar impacto en el desarrollo normal del trabajo. Es importante vigilar que los requerimientos se encuentren siempre dentro del ámbito definido para el proyecto. En caso contrario, se deberá activar el procedimiento de control de cambios.
Nombre: Requerimientos No Funcionales
Tipo: Documento
Actores Responsables: Jefe de Proyecto
Descripción
Estos requerimientos están asociados generalmente a características cualitativas del producto final, expresadas en términos amplios y sin criterios de aceptación claros. Dichos requerimientos pueden representar una importante fuente de riesgo si no se logra acotar su alcance a un nivel claro y objetivo. Para tal efecto, el Jefe de Proyecto deberá intentar, con la aprobación del cliente, transformar los criterios cualitativos en cuantitativos.
Nombre: Prototipo de Sistema
Tipo: Código
Actores Responsables: Desarrollador, Analista, Arquitecto
Descripción
Los prototipos buscan dar una vista previa de cómo debiera verse el Sistema una vez que esté construido. Por lo general los prototipos no deberían ser funcionales, a menos que el costo/beneficio justifique que se gaste esfuerzo en construirlos funcionales.
Nombre: Planteamiento de Arquitectura Inicial
Tipo: Diagrama de Despliegue / Diagrama de Componentes
Actores Responsables: Arquitecto
Se identifican en primera instancia módulos y componentes principales y las posibles soluciones tecnológicas asociadas a cada uno de ellos, además de determinar cuáles son aquellos componentes más riesgosos.
Nombre: Arquitectura del Sistema
Tipo: Diagrama de Componentes
Actores Responsables: Arquitecto
Descripción
La Arquitectura del Sistema involucra un plano en términos de paquetes, módulos y componentes de cada uno de los elementos del sistema. Esto artefacto se va elaborando a medida que se diseña el sistema, ya que es a medida que se ataca cada problema que aparecen las componentes que los van a resolver. Es posible que al finalizar la fase de Elaboración se pueda lograr un plano teórico de cómo debiera ser la Arquitectura del Sistema con una baja incertidumbre, ya que para esa altura se debiese haber terminado de estereotipar todos los componentes del sistema y ya es posible, en función de los requerimientos de los componentes faltantes, estimar la forma y tamaño que ellos tendrán.
Nombre: Mecanismos de Diseño (Patrones)
Tipo: Documento
Actores Responsables: Arquitecto
Descripción
Los mecanismos de diseño son instrucciones de cómo se debe diseñar cada tipo de problema identificado. Indican en forma de instructivo cuáles son los patrones de diseño que se deben aplicar y cuáles debieran ser los resultados en cada caso.
Nombre: Especificación de Diseño
Tipo: Diagrama de Clases
Actores Responsables: Analista, Arquitecto
Descripción
Las especificaciones de diseño consisten en diagramas de clases donde aparecen claramente estereotipadas los distintos componentes, descritos sus atributos, métodos y las relaciones de dependencia entre ellos. En el caso de los atributos se requiere que se especifique su tipo y las validaciones básicas asociadas al mismo. En el caso de los métodos, se requiere que se especifique la firma y el comportamiento que tiene el mismo; en caso que sea demasiado complejo se debe crear un diagrama de actividades dentro de la clase que describa el comportamiento del mismo y que represente su flujo de actividades. Cada componente debe estar explícitamente realizando al menos uno de los Requerimientos de Sistema.
Nombre: Mecanismos de Implementación
Tipo: Documento / Código
Actores Responsables: Arquietecto
Descripción
En estrecha relación con los Mecanismos de Diseño, ya que se debe establecer para cada uno de ellos la forma de transformar dicha especificación a código.
Nombre: Prueba de Concepto
Tipo: Código
Actores Responsables: Arquitecto, Desarrollador
Descripción:
Corresponde a un pequeño proyecto de desarrollo que busca probar la factibilidad de una solución para un problema en particular que generalmente es innovadora y no existe experiencia previa con esa tecnología o línea de solución en general.
La prueba de concepto se da por concluida cuando queda demostrado, por una aplicación o algún tipo de demostración, que la solución propuesta cumple con necesidades funcionales que se requieren de ella y con las restricciones de escalabilidad, performance, robustez, etc. asociadas con el proyecto.
Nombre: Componente de Software
Tipo: Código
Actores Responsables: Desarrollador
Descripción
Módulo software desarrollado, adquirido o reutilizado que posee una funcionalidad definida y que cumple con al menos un Requerimiento de Sistema.
Nombre: Pruebas Unitarias
Tipo: Código
Actores Responsables: Desarrollador, Analista
Descripción
Pruebas de caja blanca diseñadas para probar un componente de software en particular, generalmente apoyadas por la misma herramienta de desarrollo del componente. Son generadas por los desarrolladores con apoyo de los analistas en aquellos aspectos que no estén indicados en la especificación.
Nombre: Pruebas de Funcionalidad
Tipo: Diagrama de Actividades
Actores Responsables: Tester
Descripción
Estas pruebas están orientadas a probar la funcionalidad de un conjunto de componentes en forma de escenarios de operación para comprobar el correcto funcionamiento del sistema. Las Pruebas de Funcionalidad dependen de la funcionalidad y del sistema que se quiere probar.
Nombre: Pruebas de Aceptación
Tipo: Documento
Actores Responsables: Jefe de Proyecto
Descripción
Es un conjunto de pruebas que una vez ejecutadas aseguran la conformidad del cliente con el producto. Estas pruebas deben estar descritas en el formato de pruebas definido para el proyecto o estar acompañadas de una guía de acción que indique cómo realizarlas.
Las pruebas de aceptación debieran ser ejecutadas por un ente distinto al cliente y al equipo del proyecto, pero típicamente las ejecuta el mismo cliente o el mismo equipo de pruebas del proyecto, previo acuerdo por las dos partes.
Nombre: Incidencias
Tipo: Entidad de Negocio
Actores Responsables: Jefe de Proyecto
Descripción
Una Incidencia es un hecho que no está considerado en la planificación del proyecto, ya sea una necesidad, problema o requerimiento que no estaba considerado como parte del proyecto y que surge en forma inesperada. También puede ser un riesgo que estaba incluido en el Plan de Administración de Riesgos que se ha materializado, en cuyo caso se debe realizar el plan de contingencia allí definido.
Un evento de este tipo puede nacer del mismo proyecto, puede ser un requerimiento de otro proyecto o de otra área de negocios y puede afectar los recursos y el cronograma de actividades del proyecto.
Una incidencia debe entenderse como una orden de servicio que debe ser atendida por la fábrica de software. En la resolución de una incidencia pueden participar más de una persona natural e incluso una incidencia puede llegar a dar origen a un proyecto en sí que debe abordarse en forma separada.
Nombre: Versión 1.0.0
Tipo: Código
Actores Responsables: Integrador
Descripción
Corresponde a la primera versión del sistema completo que ya ha pasado los criterios de aceptación planteados por el cliente.
Nombre: Versión desplegada del sistema
Tipo: Código
Actores Responsables: Integrador
Descripción
Una versión parcial del sistema que es funcional y desplegable, dado un conjunto de requerimientos de plataforma determinados que se encuentran indicados en la documentación de despliegue asociada a esta versión.
Nombre: Documentación de Despliegue
Tipo: Diagrama de Despliegue
Actores Responsables: Integrador
Descripción
Esta documentación debe incluir descripciones de los nodos donde serán desplegadas las componentes del sistema (incluyendo las configuraciones necesarias para asegurar el funcionamiento del sistema), la lista de componentes desplegadas indicando en qué nodo se han desplegado, los procedimientos de respaldo y recuperación (todos los pasos y antecedentes a tener en cuenta en caso de un respaldo o recuperación van juntos por la dependencia que tienen uno del otro) y los procedimientos de mantención necesarios (incluye balanceos de carga, indexación de las bases de datos, etc.).
Actores Participantes
– Cliente: Parte responsable de aceptar el producto o de autorizar el pago de este. Es externo al proyecto pero no necesariamente externo a la organización. Los clientes son parte de los Stakeholders.
– Jefe de Proyecto: Es el responsable ante la gerencia del desarrollo y mantención del proyecto.
– Analista: Incluye a los analistas de requerimientos avocados en un proyecto.
– Arquitecto: Responsable de definir la arquitectura lógica y tecnológica que será usada para el desarrollo, soporte, mantención y operación del Sistema.
– Desarrollador: Corresponde a los programadores del Sistema.
– Tester: Encargados de hacer las pruebas de los componentes del Sistema y del Sistema completo.
– Integrador: Responsable de unir los componentes separados para formar el Sistema completo.
– Stakeholders: Involucra a todas las personas u organizaciones que son afectados por el Sistema. Puede incluir a miembros del proyecto, proveedores, clientes, usuarios finales y otros.
Procesos de Apoyo
El Proceso de Administración de Requerimientos permite establecer y mantener un entendimiento común entre el cliente y el proyecto acerca de los requerimientos que serán abordados y que serán el vínculo coherente y rastreable que une a todo el ciclo de desarrollo. Dicho acuerdo representa la base para estimar, planificar, ejecutar y controlar las actividades del proyecto a través del ciclo de vida.
La Administración de Requerimientos comprende actividades relacionadas con la definición, clasificación, asignación, seguimiento y control de los requerimientos durante todo el ciclo de vida de desarrollo de software. En la Figura 12 se muestra un diagrama que modela el ciclo de actividades de este proceso.
Figura 12: Administración de Requerimientos
El proceso se inicia con Ingresar el Requerimiento, actividad que se modela en la Figura 13.
Figura 13: Ingresar Requerimiento
Actividad: Analizar Antecedentes e historia de los requerimientos del proyecto
Entradas: Bases de Licitación, Términos de Referencia, Propuesta Técnica, Mail, Documentos Adjuntos
Salidas: N. A.
Actores Involucrados: Jefe de Proyecto
Descripción:
Se deben analizar todos los antecedentes y la historia de los requerimientos del proyecto, desde que se realiza la propuesta hasta el momento actual en que este se encuentra. Pueden existir otros artefactos de entrada; en el diagrama por simplicidad se señalan sólo algunos típicamente usados.
Actividad: Determinar tipo de requerimiento
Entradas: N. A.
Salidas: N. A.
Actores Involucrados: Jefe de Proyecto
Descripción:
De esta decisión pueden surgir dos alternativas:
1.- El requerimiento es un Cambio de Requerimiento.
El requerimiento es una modificación, corrección o simplemente la eliminación de un requerimiento que pertenece a la Línea Base vigente y aprobada.
2.- El requerimiento es un Requerimiento Nuevo.
El requerimiento no ha sido analizado antes, por lo tanto es necesario hacer su estudio detallado.
Actividad: Ingresar Información del Proyecto y del requerimiento
Entradas: N. A.
Salidas: Registro de Requerimientos.
Actores Involucrados: Jefe de Proyecto
Descripción:
La información de cada requerimiento incluye:
Fecha: Fecha en que se realiza este plan.
ID Proyecto: Identificación del proyecto.
Nombre Proyecto: Nombre completo del proyecto.
Responsable GR: Nombre de la persona responsable de la Administración de los Requerimientos.
Fase: Número de la fase del mismo proyecto. Se genera un nuevo encabezado por cada fase del mismo proyecto.
ID LB: Identificación de la Línea Base vigente de la fase y el proyecto
Fecha inicio LB: Fecha planificada del comienzo de esta fase, aprobada por CM. Si está en blanco implica que aun no está definida.
Fecha aprobación LB: Fecha de aprobación de LB utilizada cuando hay cambio de LB debido a Control de Cambios, si está en blanco implica que aún no se ha modificado la Línea Base inicial.
Se actualiza además el estado del requerimiento como "Ingresado".
El Registro de Requerimientos se realiza en el software Enterprise Architect.
Actividad: Completar o adaptar requerimientos predefinidos según aplican al proyecto
Entradas: Glosario y Ayuda. 2.7 Forma de llenado del Registro de Requerimientos
Salidas: Registro de Requerimientos
Actores Involucrados: Jefe de Proyecto
Descripción:
En base a la forma de llenado de los requerimientos en el Enterprise Architect se actualiza los datos en el sistema, agregando a su vez mayor detalle a cada uno, dependiendo del proyecto y del requerimiento en sí.
Si existe un control de cambios en algún requerimiento se activa esta actividad, que se modela en la Figura 14
Figura 14: Control de Cambios
- Administración de Requerimientos
- Fase de Transición
| Página siguiente |