Modelo de calidad CMMI (página 4)

            La lista de Requerimientos originales ofrecidos permanece invariable como registro del límite comprometido del sistema. Finalmente se genera una lista definitiva con todos los Requerimientos del Sistema, los cuales deben estar relacionados por lo menos con uno de los requerimientos ofrecidos. Lo que se debe lograr es identificar y acotar los límites de cada requerimiento y los actores involucrados. Los Requerimientos de Sistema deben además estar relacionados con aquellos Procesos de Negocio que van a sistematizar y con aquellos Conceptos de Dominio con los que tendrán que lidiar. Cualquier proceso y concepto que quede sin relacionar con algún requerimiento de sistema se considerará fuera del dominio del sistema y debe quedar apropiadamente registrado.

            Como prueba final se debe comprobar que cada uno de los Requerimientos originales ofrecidos que se pretenden implementar esté siendo realizado por un Requerimiento de Sistema y que el 100% de los Requerimientos de Sistema estén dando cumplimiento a por lo menos uno de los Requerimientos originales ofrecidos. Los Requerimientos de Sistema que no estén cumpliendo requerimientos ofrecidos dan cuenta de cambios en el tamaño del sistema que se piensa desarrollar en relación al que se ofreció. Requerimientos originales que no estén siendo realizados por Requerimientos de Sistema dan cuenta de posibles omisiones de funcionalidad comprometida en el sistema a ser desarrollado y que luego podrían ser objetadas por los clientes.

Nombre: Realizar Análisis y Diseño de la Solución

Artefactos de Entrada: Descripción de la solución, Visión del Sistema, Requerimiento de Sistema

Artefactos de Salida: Planteamiento de Arquitectura Inicial

Actores Involucrados: Arquitecto

Descripción:

En función de los requerimientos identificados el arquitecto del proyecto construye un Planteamiento de Arquitectura Inicial, identificando módulos y componentes principales y las soluciones tecnológicas asociadas a cada uno. Se debe determinar además cuáles componentes de la arquitectura son aquellos que tienen mayor riesgo de desarrollo.

Nombre: Desarrollar Solución Sistémica

Artefactos de Entrada: Planteamiento de Arquitectura Inicial

Artefactos de Salida: Prueba de Concepto

Actores Involucrados: Desarrollador

Descripción:

Con el Planteamiento de Arquitectura Inicial ya realizado se debe determinar si hay aspectos del sistema que requieran una prueba de concepto de la solución planteada para asegurar la factibilidad de la misma. Si se determina que son necesarias una o más pruebas de concepto, estas se desarrollan de acuerdo a la importancia de cada una.

Nombre: Asegurar Correctitud y Funcionalidad de la Solución

Artefactos de Entrada: Requerimiento original ofrecido, Visión del Sistema, Prueba de Concepto

Artefactos de Salida: N.A.

Actores Involucrados: Jefe de Proyecto, Arquitecto.

Descripción:

Verificar que las Pruebas de Concepto se ajusten a lo ofrecido y que concuerde con la Visión del Sistema que tiene el cliente. Esta verificación generalmente involucra una revisión de pares con otro arquitecto con el fin de examinar la solución planteada por el arquitecto del proyecto y proponer cambios o mejoras a ésta.

Nombre: Desplegar Solución

Artefactos de Entrada: Prueba de Concepto

Artefactos de Salida:

Actores Involucrados: Jefe de proyecto, Arquitecto, Stakeholders

Descripción:

De ser necesario se pueden desplegar en un ambiente temporal algunas de las pruebas de concepto verificadas para ser mostradas a los Stakeholders interesados y demostrar su correctitud y funcionalidad ante ellos.

Nombre: Describir el Problema de Negocio

Artefactos de Entrada: Visión del Sistema, Concepto de Dominio, Proceso de Negocio

Artefactos de Salida: N. A.

Actores Involucrados: Analista

Descripción:

Se revisan los documentos de Visión del Sistema, Procesos de Negocio y Concepto de Dominio en términos de los requerimientos que se quieren atacar. Se pueden realizar correcciones menores a estos documentos cuando corresponda, en función del análisis que se realiza en esta etapa de vida del proyecto.

Nombre: Especificar Requerimientos de la solución

Artefactos de Entrada: Planteamiento de Arquitectura Inicial, Requerimiento de Sistema, Arquitectura del Sistema

Artefactos de Salida: Criterios de Aceptación, Requerimiento de Sistema, Prototipo de Sistema, Mecanismos de Diseño (Patrones)

Actores Involucrados: Analistas, Arquitecto, Stakeholders, Jefe de Proyecto

Descripción (ver Figura 8):

La diferencia entre las fases de Elaboración y Construcción radica que durante la Elaboración se atacan los requerimientos de arquitectura más importantes, que darán como resultado la mayor parte de los mecanismos de diseño del sistema.

Sobre el conjunto de Requerimientos de Sistema que se quieren atacar se deben detallar por completo los antecedentes necesarios para comprender y acotar qué es lo que debe hacer cada parte del sistema, indicando los escenarios principales, secundarios y las restricciones. Esto incluye la realización de prototipos no funcionales, que sirvan tanto para mostrar al cliente una vista previa del sistema como para la fase de diseño donde la interfaz se debe diseñar completamente.

Se debe determinar que los Requerimientos de Sistema estén cumpliendo con los requerimientos ofrecidos y que no se requiere más de lo originalmente ofrecido del sistema. Cualquier desviación de estas líneas debe ser debidamente controlada. También se deben revisar los Criterios de Aceptación de los requerimientos con el cliente con los analistas encargados y con analistas que no sean parte del proyecto por medio de una revisión de pares y si existe una modificación en los requerimientos también se debe modificar este documento con la debida aprobación del cliente. Luego el arquitecto debe determinar si los mecanismos de diseño definidos alcanzan para cubrir estos requerimientos si se deben generar nuevos mecanismos o si se deben adaptar los antiguos. Esto debiese darse solo en la fase de la Elaboración ya que durante la Construcción todos los problemas deben haber sido previamente atacados y por tanto no debiese surgir la necesidad de crear nuevos mecanismos para los mismos problemas.

Nombre: Realizar Análisis y Diseño de la Solución

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.

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.

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.

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.

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

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.