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.