Modelo CMMI (página 4)

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