Modelo CMMI (página 2)

• Modelos
  Previos

Uno de los propósitos de CMMI fue unir en forma
coherente varios modelos que
eran utilizados en conjunto dentro de una organización y que generaban
repetición de contenido provocando que el proceso de
mejora llevado a cabo en la
organización fuera más difícil y
costoso. Estos modelos integrados por CMMI, que serán
descritos a continuación y que se ilustran en la Figura 1,
eran modelos enfocados en el desarrollo de
sistemas software (SW-CMM), en la
ingeniería de sistemas (SECM) y en el
desarrollo de productos
integrados (IPD-CMM).

Figura 2: Modelos Previos a
CMMI

• CMM para
  Software

Tras su creación en 1984 el SEI comenzó la
investigación para desarrollar un marco de
mejora y evaluación
de la calidad de las
empresas
desarrolladoras de software que prestaban servicios al
Departamento de Defensa de los Estados Unidos.
El resultado de la investigación se denominó
"Capability Maturity Model for Software" (SW-CMM), cuya
versión 1.0 se publicó en Agosto de 1991 [Pal06].
Posteriormente, como resultado de la retroalimentación generada por parte de la
comunidad de
software [Pau93], se desarrollaron las versiones 1.1 publicada en
1993 y 2.0 la cual agregaba y modificaba una serie de elementos
al vigente CMM v1.1, principalmente que tienen relación
con alcanzar la institucionalización en la
organización. Esta versión se completó en
1997 y se denominó "Software CMM, Version 2.0 (Draft C)",
pero nunca fue publicada [SEI97]. SW-CMM es un modelo de
madurez de capacidades desarrollado para los procesos
relativos a la producción y mantenimiento
de sistemas software. De esta forma el SW-CMM puede emplearse con
dos finalidades [Pal06]:

1. Guía para mejorar procesos relativos a la
producción y mantenimiento del software.

2. Criterio para determinar el nivel de madurez de una
organización que produce y mantiene software.

Las organizaciones
que usan SW-CMMI transitan por cinco niveles de madurez de
capacidades donde se pueden encontrar al evaluar sus procesos.
Estos niveles son: Inicial, donde no hay procesos; Repetible, en
el cual los procesos relacionados a la gestión
de proyectos y
gestión de requerimientos son manejados de alguna manera
para su repetición en proyectos distintos; definido,
cuando los procesos están totalmente definidos y
disponibles para todos los miembros de una organización;
gestionado, donde se pueden medir los procesos cuantitativamente;
y optimizado, en donde los procesos son mejorados continuamente
según una serie de métricas definidas.

• SECM

SECM corresponde al esfuerzo conjunto de INCOSE –
International Council on System Engineering (Consejo
Internacional sobre Ingeniería de sistemas) – y EPIC
Group – Enterprise Process Improvement Collaboration Group
(Grupo de
colaboración de mejora de procesos en la empresa)
– para integrar sus dos modelos (SECAM y SE-CMM,
respectivamente) en el denominado System Engineering Capability
Model (SECM) o también llamado EIA/IS 731, que fue
liberado en su versión 1.0 en 1998.

SECM (Modelo de Capacidades de Ingeniería de
Sistemas) fue elaborado con el objetivo de
proveer una guía para efectuar, manejar y mejorar la
ingeniería
de sistemas [Sec07a]. El modelo describe un conjunto
mínimo de actividades críticas para realizar
ingeniería de sistemas o manejar tareas, tal como derivar
y asignar requerimientos o manejar riesgos. El
modelo también captura las actividades genéricas
relacionadas a manejar o mejorar como una tarea específica
es realizada [Sec07a]. Estas actividades son especificadas en
cinco niveles secuenciales e incrementales (niveles de
capacidad), los cuales proveen al usuario un método
estructurado para lograr una mejora continua [Sec07a]. Los
niveles fueron obtenidos sobre prácticas probadas
experimentalmente y ellos son: Habilidad para desarrollar
ingeniería de sistemas, Obteniendo control local,
Compartiendo conocimiento a
través de la organización, Medida cuantitativa de
lo que se hace, y Mejora usando las medidas cuantitativas y
objetivos
organizacionales.

El primer predecesor de SECM descrito es SECAM (Systems
Engineering Capability Assessment Model), traducido como Modelo
de Evaluación de Capacidades de Ingeniería de
Sistemas. Fue elaborado por CAWG – Capability Assessment
Working Group on Systems Engineering (Grupo de trabajo de
evaluación de capacidades en Ingeniería de
sistemas) – y aprobado por INCOSE para ser liberado en 1996
[Inc96]. SECAM junto son su método de evaluación
fue utilizado evaluar la capacidad de los procesos relacionados a
la ingeniería de sistemas en una organización y
trataba de determinar áreas de potencial mejora. El
segundo predecesor es SE-CMM v1.1 – System Engineering
Capability Maturity Model (Modelo de Madurez de Capacidad para
Sistema de
Ingeniería) – que fue creado por el SEI en el
año 1995 y describe los elementos esenciales que deben
existir para que los procesos de ingeniería de sistemas de
una organización aseguren una buena ingeniería de
sistemas [Bat95]. Junto con su método de evaluación
tienen el objetivo de mejorar y evaluar los procesos asociados a
la ingeniería de sistemas.

• IPD CMM

IPD CMM – Integrated Product Development
Capability Maturity Model (Modelo de madurez de capacidad para el
desarrollo de productos integrados) – fue el elaborado y
liberado en 1997 por el SEI. El modelo describe los elementos
esenciales para el desarrollo de un producto
integrado; una guía para el proceso de mejora del
desarrollo del producto integrado; y una metodología de evaluación del
proceso de desarrollo del producto integrado que es hecho por una
organización [Sec07b].

IPD CMM puede ser aplicado a cualquier tipo disciplina y
abarca casi todo el ciclo de vida
de un producto desde la selección
de oportunidades de negocio hasta el retiro del producto del
mercado,
marginando la etapa de desarrollo del plan
estratégico [Sec07b]. Fue diseñado con la idea
de eliminar la duplicación de actividades del SW-CMM y el
SE-CMM, los cuales al ser aplicados en una organización se
traslapaban entre sí, y consta de 5 niveles de madurez de
capacidad semejantes en su descripción a los niveles de SW-CMM y
SE-CMM [Sec07b].

• CMMI Versión
  1.2

Capability Maturity Model® Integration (CMMI) es un
modelo de aseguramiento de la calidad que busca la mejora
continua de las organizaciones mediante el análisis y re-diseño
de los procesos que subyacen en la organización. Fue
creado por el SEI (Software Engineering Institute) de la Universidad de
Carnegie-Mellon y patrocinado por el Ministerio de Defensa de los
Estados Unidos. Con el propósito de lograr la mejora de
los procesos, CMMI provee:

• Una forma de integrar los elementos funcionales
de una organización [SEI07b].

• Un conjunto de mejores prácticas basadas
en casos de éxito
probado de organizaciones experimentadas en la mejora de
procesos.

• Ayuda para identificar objetivos y prioridades
para mejorar los procesos de la organización [SEI07b],
dependiendo de las fortalezas y debilidades de la
organización que son obtenidas mediante un método
de evaluación.

• Un apoyo para que las empresas complejas en
actividades productivas puedan coordinar sus actividades en la
mejora de los procesos.

• Un punto de referencia para evaluar los procesos
actuales de la organización [SEI07b].

CMMI v1.2 corresponde a la tercera versión
entregable del modelo CMMI, posterior a las versiones 1.02
(primera versión año 2000) y 1.1 (año 2002)
[Chr06]. Las versiones previas sirvieron como
retroalimentación para que los propios usuarios,
evaluadores y evaluados hicieran acotaciones sobre posibles
mejoras, las cuales fueron estudiadas, refinadas y algunas
incluidas en la versión 1.2. CMMI v1.2 para desarrollo,
que corresponde a una de tres constelaciones de prácticas,
es una guía que ayuda a manejar, medir y monitorear
procesos [SEI07a] utilizados en el desarrollo de productos y
servicios de una organización, y contiene prácticas
ligadas a la administración
de proyectos, administración de procesos,
ingeniería y soporte. Las otras dos constelaciones son
CMMI para Adquisición que provee una guía para
liderar la adquisición informada y decisiva [SEI07a], y
CMMI para Servicios que proporciona una guía para la
entrega de servicios a clientes internos
y externos de la organización [SEI07a]. Ambas
constelaciones se encuentran aún en desarrollo.

Junto con CMMI se desarrolló y publicó el
método de evaluación "Assessment Requirements for
CMMI (ARC)" [SEI00] en el año 2000, el cual define los
requerimientos considerados esenciales para realizar una
evaluación de CMMI en una organización y "Standard
CMMI Appraisal Method for Process Improvement", (SCAMPI) [SEI01],
manual seguido
por los evaluadores para medir el nivel de madurez de una
organización. Estos dos documentos
también se han actualizado como consecuencia de la
retroalimentación de la comunidad involucrada en CMMI,
generando la última versión 1.2 de SCAMPI [SEI06a]
y ARC [SEI06b] ambas publicadas el año 2006.

• Representaciones

La representación usada en CMMI entrega una
guía para efectuar las actividades de mejora de los
procesos y es utilizada en el método de evaluación.
Según el modelo se tienen dos formas para mejorar. Una
forma es mejorar un proceso específico o un conjunto de
ellos usando la Representación Continua (Continuous
Representation) y la otra es la mejora de la organización
completa según los procesos definidos y ocupados usando la
Representación Escalonada o por Etapas (Staged
Representation). En la Tabla 1 se muestran los niveles para estos
dos tipos de representaciones.

Representación Continua

La representación continua se focaliza en la
mejora de un proceso o un conjunto de ellos relacionado(s)
estrechamente a un área de proceso en que una
organización desea mejorar, por lo tanto una
organización puede ser certificada para un área de
proceso en cierto nivel de capacidad. Existen seis niveles de
capacidad por donde transitan los procesos asociados a un
área de proceso y cada nivel es construido sobre el nivel
anterior, es decir para que un proceso alcance un nivel de
capacidad necesariamente debe haber alcanzado el nivel
anterior.

Tabla 1: Niveles de
Representación continua y escalonada
[Chr06].

Los niveles de capacidad son:

Nivel 0 – Incompleto: Un proceso es denominado "proceso
incompleto" cuando una o más objetivos específicos
del área de proceso no son satisfechos.

Nivel 1 – Realizado: Un proceso es denominado
"proceso realizado" cuando satisface todos los objetivos
específicos del área de proceso. Soporta y permite
el trabajo
necesario para producir artefactos [Chr06].

Nivel 2 – Manejado: Un proceso es denominado como
"proceso manejado" cuando tiene la infraestructura base para
apoyar el proceso. El proceso es planeado y ejecutado en
concordancia con la política, emplea
gente calificada los cuales tienen recursos
adecuados para producir salidas controladas; involucra partes
interesadas; es monitoreado, controlado y revisado; y es evaluado
según la descripción del proceso
[Chr06].

Nivel 3 – Definido: Un proceso denominado "proceso
definido" es adaptado desde el conjunto de procesos
estándares de la organización de acuerdo a las
guías de adaptación de la organización, y
aporta artefactos, medidas, y otra información de mejora a los activos
organizacionales [Chr06].

Nivel 4 – Manejado cuantitativamente: Un proceso
denominado "proceso manejado cuantitativamente" es controlado
usando técnicas
estadísticas y otras técnicas
cuantitativas. Objetivos cuantitativos para la calidad y
realización del proceso son establecidos y usados como
criterios para manejar el proceso [Chr06].

Nivel 5 – Optimización: Un proceso
denominado "proceso optimización es mejorado basado en el
entendimiento de causas comunes de variación del proceso.
Un proceso en optimización se focaliza en la mejora
continua del proceso realizado a través de mejoras
incrementales y usando innovación
tecnológica [Chr06].

Para más información consultar [Kul03] y
[Chr06].

Representación Escalonada

En la representación escalonada o por etapas se
ofrece un método estructurado y sistemático de
mejoramiento de procesos, que implica mejorar por etapas o
niveles. Al alcanzar un nivel, la organización se asegura
de contar con una infraestructura robusta en términos de
procesos para optar a alcanzar el nivel siguiente. Por lo tanto
es una organización la que puede ser certificada bajo un
nivel, en este caso llamado nivel de madurez. Según esta
representación un nivel de madurez está compuesto
por áreas de procesos (ver Tabla 2) en donde los objetivos
asociados a ese nivel deben ser cumplidos para que la
organización pueda certificarse en aquel nivel de madurez.
Hay cinco niveles de madurez, los que son descritos a
continuación:

Nivel 1: Iniciado

En el nivel de madurez 1, la mayoría de los
procesos son "ad-hoc" y caóticos. La organización
usualmente no provee un ambiente
estable para soportar los procesos. Éxitos en estas
organizaciones se debe a la competencia y
esfuerzos heroicos de la gente dentro de la organización y
no al uso de procesos probados. A pesar de este caos,
organizaciones pertenecientes al nivel de madurez 1 con
frecuencia producen productos y servicios que funcionan; sin
embargo, ellos frecuentemente exceden sus presupuestos y
no cumplen sus planes. Estas organizaciones son caracterizadas
por la tendencia a no cumplir sus compromisos, al abandono de
procesos durante tiempos de crisis, y a la
incapacidad para repetir sus éxitos [Chr06]. El Nivel 1
está caracterizado además por la realización
de trabajo redundante, por personas que no comparten sus métodos de
trabajo a lo largo de la organización y cuando una
persona clave
en un área de negocio específica dentro de la
organización se marcha, su conocimiento se va con ella y
se pierde para la organización. Es claro que el Nivel 1 es
uno donde ninguna organización quiere estar y donde por lo
general la mayoría que no tiene sus procesos definidos se
encuentra.

Nivel 2: Manejado

En el nivel de madurez 2 se ordena el caos. En el nivel
2 las organizaciones se enfocan en tareas cotidianas referentes a
la
administración. Cada proyecto de la
organización cuenta con una serie de procesos para
llevarlo a cabo, los cuales son planeados y ejecutados de acuerdo
con políticas
establecidas; los proyectos utilizan gente capacitada quienes
disponen de recursos para producir salidas controladas; se
involucran a las partes interesadas; son monitoreados,
controlados y revisados; y son evaluados según la
descripción del proceso. La disciplina del proceso
reflejada por el nivel de madurez 2 ayuda a asegurar que existen
prácticas y los proyectos son realizados y manejados de
acuerdo a los planes documentados. En el nivel de madurez 2
el estado de
los artefactos y la entrega de los servicios siguen planes
definidos. Acuerdos son establecidos entre partes interesadas y
son revisados cuando sea necesario [Chr06]. Los artefactos y
servicios son apropiadamente controlados. Estos además
satisfacen sus descripciones especificadas, estándares, y
procedimientos
[Chr06].

Nivel 3: Definido

En el nivel de madurez 3, procesos son caracterizados y
entendidos de buena forma, y son descritos en estándares,
procedimientos, herramientas,
y métodos. El conjunto de procesos estándares de la
organización, los cuales son la base para el nivel de
madurez 3, es establecido y mejorado continuamente. Estos
procesos estándares son usados para establecer
consistencia a través de la organización. Los
proyectos establecen sus procesos adaptando el conjunto de
procesos estándares de la organización de acuerdo a
guías de adaptación [Chr06].

Una diferencia importante entre el nivel 2 y 3 es el
alcance de los estándares: la descripción de
procesos y los procedimientos. En el nivel de madurez 2, los
estándares pueden ser un poco diferentes en cada instancia
específica del proceso (por ejemplo sobre un proyecto
particular). En el nivel de madurez 3, los estándares,
descripción de procesos y procedimientos para un proyecto,
son adaptados desde un conjunto de procesos estándares de
la organización a un particular proyecto o unidad
organizacional y así son más consistentes [Chr06].
Otra distinción crítica
es que el nivel de madurez 3, los procesos son típicamente
descritos más rigurosamente que en el nivel 2. Un proceso
definido claramente plantea el propósito, entradas,
criterios de entrada, actividades, roles, medidas, pasos de
verificación, salidas y criterios de salida. En el nivel
de madurez 3, procesos son manejados más proactivamente
entendiendo las interrelaciones de las actividades y medidas
detalladas del proceso, sus artefactos y sus servicios
[Chr06].

Nivel 4: Manejado cuantitativamente

En el nivel de madurez 4, la organización y
proyectos establecen objetivos cuantitativos para medir la
calidad y realización de los procesos y los usa como
criterios en el manejo de ellos. Los bjetivos cuantitativos son
definidos en base a las necesidades de clientes, usuarios
finales, organización, y actores de los procesos. La
calidad y realización de procesos son entendidos en
términos estadísticos y son manejados durante todo
el ciclo de vida del proceso [Chr06]. Para subprocesos
seleccionados, se recolectan y analizan estadísticamente
medidas sobre la realización de procesos. Estas
métricas son incorporadas en el repositorio de
métricas de la organización para apoyar la toma de
decisiones. Causas especiales de variación de procesos
son identificadas y, cuando sea necesario, las fuentes de
estas causas son corregidas para prevenir futuras
ocurrencias.

Una diferencia importante entre los niveles 3 y 4 es la
capacidad de predicción de la realización del
proceso. En el nivel de madurez 4, la realización de
procesos es controlada usando técnicas estadísticas
y cuantitativas, y el proceso es cuantitativamente predecible, en
cambio en el
nivel de madurez 3 la realización del proceso es
sólo predecible cualitativamente [Chr06].

Nivel 5: Optimizado

En el nivel de madurez 5, una organización mejora
continuamente sus procesos basándose en el
conocimiento de las causas comunes de variación
inherente en los procesos. El nivel de madurez 5 se focaliza
sobre la mejora continua de los procesos a través de
mejoras continuas, incrementales y tecnológicas. Los
objetivos de mejora cuantitativa de procesos para la
organización son establecidos, continuamente revisados
para reflejar cambios en los objetivos del negocio y usados como
criterio en la mejora de procesos. Los efectos del empleo de las
mejoras de procesos son medidos y evaluados contra los objetivos
de mejora cuantitativa del proceso.

Una diferencia importante entre el nivel de madurez 4 y
5 es el enfoque de la variación de los procesos. En el
nivel de madurez 4, la organización está orientada
a encontrar causas especiales de variación y proveer una
predicción estadística de los resultados. Sin embargo,
los resultados pueden ser insuficientes para alcanzar los
objetivos establecidos. En el nivel de madurez 5 la
organización está enfocada en las causas comunes de
variación de procesos y modificar los procesos afectados
para mejorar la realización de ellos y alcanzar los
objetivos cuantitativos de mejora de procesos [Chr06].

Dado a que la organización con que se
trabajará quiere certificarse en forma organizacional en
Nivel de madurez 3, en adelante sólo se detallará
el modelo según la Representación
Escalonada.

• Estructura del
  CMMI

Un área de proceso es un conjunto de
prácticas relacionadas que cuando son implementadas
colectivamente, satisfacen un conjunto objetivos considerados
importantes para mejorar esa área de proceso [Chr06]. Las
áreas de proceso del modelo son 22. En la Tabla 2 se
indica los nombres de las áreas de proceso junto con su
abreviación. Cada una de ellas es implementada para
alcanzar el nivel de madurez correspondiente y se agrupan de
acuerdo a cuatro categorías: Administración de Procesos,
Administración de Proyectos, Ingeniería y Soporte.
Este agrupamiento es realizado para mostrar cómo se
relaciona cada área de proceso dentro de una
categoría. Sin embargo, áreas de procesos de
distintas categorías pueden encontrarse relacionadas, pero
dado que en este documento se desarrollarán sólo
áreas de procesos de una misma categoría
(Ingeniería) estas relaciones se desprecian.

Tabla 2: Áreas de
Proceso

Componentes

Aunque los componentes son independientes de la
representación elegida, se definirán de acuerdo al
esquema propuesto por la Representación Escalonada que es
la requerida por ORDEN Integración.

Como se puede apreciar en Figura 3 un área de
proceso está asociado a un nivel de madurez dentro de
CMMI; tiene además un conjunto de objetivos
específicos y uno o varios objetivos genéricos
asociados, dependiendo del nivel de madurez al cual pertenece el
área de proceso; los objetivos específicos y
genéricos cuentan con un conjunto de prácticas
específicas y genéricas respectivamente. CMMI
define componentes requeridos, esperados e informativos. Los
Componentes informativos, que se representadas por elipses en la
Figura 3, no son referenciados ni descritos en este documento
pues no son de interés
para ORDEN Integración y sólo son una ayuda
propuesta por el modelo para entender de mejor manera las
componentes requeridas y esperadas.

Componentes Requeridas

Son las componentes que obligatoriamente deben ser
satisfechas y visiblemente implementadas para poder cumplir
con un área de proceso. Una componente requerida es usada
en las evaluaciones para ayudar a determinar si un área de
proceso es satisfecho [Chr06]. Existen dos componentes
requeridas:

– Objetivo Específico (SG): Es un enunciado que
describe la única característica que deber estar
presente para satisfacer el área de proceso a la cual
pertenece [Chr06]. Las SG son parte de un área de
proceso.

– Objetivo Genérico (GG): Es un enunciado que
describe una característica que debe ser satisfechas por
un conjunto de áreas de proceso según sea el caso.
Las GG tienen el objetivo de institucionalizar los procesos que
implementan un área de proceso y son comunes a un conjunto
de áreas de proceso [Chr06].

Figura 3: Componentes del CMMI –
Representación Escalonada

Componentes esperadas

Son las componentes que pueden ser utilizadas para
alcanzar una componente requerida, es decir se podrían
implementar estas componentes o modificaciones válidas de
ellas con el objetivo de alcanzar los objetivos genéricos
o específicos. Las componentes esperadas pueden ser
utilizadas como guías de mejora y de evaluación de
procesos [Chr06]. Existen dos tipos de componentes
esperadas:

• Prácticas Específicas (SP): Una
práctica específica es un enunciado que describe
una actividad que es importante o esperada para alcanzar un
objetivo específico de cierta área de proceso
[Chr06].

• Prácticas Genéricas (GP): Una
práctica genérica es un enunciado que describe una
actividad que es importante o esperada para alcanzar un objetivo
genérico [Chr06].

• Descripción de las
  Áreas de Proceso

A continuación se hará una breve
descripción de cada área de proceso nombrada en
Tabla 2. Explícitamente se nombra a productos pero
también se puede aplicar las mismas definiciones a
servicios.

– Análisis y Resolución Causales (CAR):
Identifica la causa de defectos u otros problemas.
Luego de ellos toma acciones
correctivas para prevenir la ocurrencia de tales defectos o
problemas en el futuro.

– Análisis y Resolución de Decisiones
(DAR): Proporciona un proceso estructurado de toma de decisiones
que asegura que las alternativas se comparan con criterios
establecidos y objetivos para así tomar la mejor
decisión posible.

– Aseguramiento de Calidad de Procesos y Productos
(PPQA): Proporciona un conjunto de prácticas con el
objetivo de evaluar productos, servicios, procesos y sus
artefactos relacionados.

– Definición de Procesos Organizacionales (OPD):
Establece y mantiene un conjunto de estándares tanto en
procesos organizacionales como en ambientes de
trabajo.

– Desarrollo de Requerimientos (RD): Recopila las
necesidades del cliente para
convertirlas en requerimientos del producto esperado.

– Entrenamiento
Organizacional (OT): Permite a la gente de la organización
obtener habilidades y conocimientos necesarios para que el
trabajo realizado por ellos sea efectivo y eficiente.

– Administración Cuantitativa de Proyectos (QPM):
Maneja métricas cuantitativas de los procesos con el
objetivo de alcanzar los objetivos de calidad establecidos.
Además mediante el análisis de estos datos permite
identificar oportunidades de mejora para los procesos.

– Administración de Acuerdos con Proveedores
(SAM): Gestiona la adquisición de productos de proveedores
con los cuales exista un acuerdo formal [Rig06].

– Administración de Requerimientos (REQM):
Gestiona los requerimientos del producto durante todo el ciclo de
vida de él, identificando inconsistencias con los
artefactos y planes de proyecto.

– Administración de Riesgos (RSKM): Identifica
riesgos del proyecto para evaluarlos, priorizarlos y gestionarlos
para prevenir su futura ocurrencia.

– Administración de la Configuración (CM):
Establece y mantiene la integridad y consistencia de los
artefactos [Rig06].

– Administración Integral de Proyecto (IPM):
Adapta el conjunto de procesos estándares de la
organización a procesos llevados a cabo para un proyecto
en particular. Además maneja a las partes interesadas
involucradas en el proyecto.

– Innovación y Despliegue Organizacional
(OID): Selecciona y despliega mejoras incrementales e innovadoras
que mejoran en forma medida los procesos de la
organización y tecnologías, para alcanzar los
objetivos de calidad organizacional y de realización de
procesos derivados de los objetivos de negocio de la
organización [Chr06].

– Integración de Producto (PI): Ensambla las
componentes del producto para producir un producto más
complejo manteniendo el cumplimiento de los requerimientos
establecidos.

– Medición y Análisis (MA): Establece
métricas con el objetivo de entregar resultados objetivos
que sirvan como base para tomar decisiones informadas y
correctivas.

– Monitoreo y Control de proyecto (PMC): Analiza el
proyecto con el objetivo de establecer un control y
evaluación según lo planes establecidos, tomando
acciones correctivas cuando es necesario.

– Planificación de Proyecto (PP): Desarrolla
y mantiene planes del proyecto, compromisos adquiridos por parte
de los participantes del proyecto y gestiona las partes
interesadas del proyecto.

– Procesos Orientados a la Organización (OPF):
Ayuda a mantener un entendimiento de los procesos por parte de
los miembros de la organización. También ayuda a
identificar posibles mejoras de los procesos, que son evaluadas y
eventualmente implementadas.

– Rendimiento de Procesos Organizacionales (OPP): Deriva
objetivos cuantitativos de calidad y ejecución de lo
procesos desde el conjunto de objetivos de negocio de la
organización [Rig06].

– Solución Técnica (TS): Diseña,
desarrollo e implementa soluciones
para los requerimientos del producto establecido.

– Validación (VAL): Demuestra que el producto,
componentes del producto y artefactos corresponden a lo esperado
para su uso.

– Verificación (VER): Demuestra que el producto,
componentes del producto y artefactos cumplen con los
requerimientos establecidos.

• Evaluaciones

Una evaluación de CMMI corresponde al estudio y
análisis de uno o más procesos realizado por un
equipo capacitado de profesionales, utilizando un modelo de
referencia de evaluación como base para determinar, a lo
menos, fortalezas y debilidades dentro de una
organización. Un método de evaluación puede
ser aplicado para distintos propósitos, incluyendo
evaluaciones internas para mejora de los procesos, evaluaciones
de capacidad de selección de proveedores, evaluaciones de
monitoreo de procesos, entre otros enfoques.

El SEI ha publicado dos documentos guías que
actualmente son utilizados para realizar una evaluación de
CMMI:

• Appraisal Requirements for CMMI (ARC)
[SEI06b]

• Standard CMMI Appraisal Method for Process
Improvement (SCAMPI) [SEI06a].

ARC define un conjunto de requerimientos considerados
esenciales para realizar una evaluación CMMI mientras que
SCAMPI es la referencia para la evaluación. Se definen en
ARC tres clases de evaluaciones: clase A, clase
B y clase C. Las clases definen los requerimientos que debe
cumplir una evaluación de cierta complejidad.

La clase A de ARC corresponde al método de
evaluación que satisface el 100% de los requerimientos que
el documento define y es la única evaluación que se
considera oficial para otorgar un nivel de certificación
de CMMI en una organización. Se denomina SCAMPI clase A.
Este método permite comprender de mejor forma las
capacidades de la organización, identificando fortalezas y
debilidades en sus procesos y relacionar estas fortalezas y
debilidades con el modelo de referencia CMMI. El método
permite además enfocar la organización en el
mejoramiento continuo de procesos y priorizar los planes de
mejora; finalmente permite evaluar con una nota el nivel de
madurez en el cual se encuentra una organización. SCAMPI
clase A consta de tres fases: planificar y preparar la
evaluación, llevar a cabo la evaluación y reportar
resultados de la evaluación. Dentro de estas fases se
ejecutan una serie de procesos. Algunos de ellos incluyen asignar
responsabilidades, documentar el proceso, entrevistar a personas
de la organización, agrupar los datos que se
utilizarán, verificar y validar los procesos con el
estándar, asignar notas o ratings, crear reportes. Se
espera contar con un equipo evaluador de cómo
mínimo requerido cuatro personas y un máximo
recomendado de nueve, incluyendo al evaluador líder
certificado en CMMI por el SEI.

Las evaluación clase B está basada en la
evaluación clase A. La evaluación clase B ayuda a
una organización a comprender, con relativamente alto
grado de confianza, el estado de los
procesos relativos a CMMI. Generalmente se ejecuta una
evaluación clase B cuando la organización necesita
auto-evaluar sus procesos, con miras a una evaluación
clase A para lograr el objetivo de la certificación. Esta
clase de evaluación debe ser ejecutada por dos personas,
incluyendo a un líder de CMMI y requiere mucho menos
información que la evaluación clase A.

Menos formal aún, de menor duración y con
menos información requerida es la evaluación clase
C que además es realizada por sólo una persona y
tiene por objetivo evaluar pequeños aspectos de la
organización que quieren apoyarse.

• Relaciones entre las
  áreas de proceso

Hay cuatro grupos o
categorías de áreas de procesos que ayudan a guiar
el proceso de mejora de la organización. Estos grupos
están formados por áreas de proceso que se
interrelacionan fuertemente y tienen características
comunes asociadas a objetivos de negocio tradicionales. Estas
categorías son las indicadas en la Tabla 2 para cada
área de proceso: Administración de procesos,
Administración de proyectos, Soporte e Ingeniería.
A Continuación se describen brevemente las tres primeras
categorías, para luego enfocarse en una descripción
detallada de la categoría de Ingeniería que es la
de interés en este documento.

Administración de procesos: Contiene
áreas de proceso relacionadas con definir, planear,
desplegar, implementar, monitorear, controlar, evaluar, medir y
mejorar procesos [Chr06].

Administración de proyectos: Contiene
áreas de proceso relacionadas con planeación, monitoreo y control de
proyectos [Chr06].

Soporte: Contiene áreas de proceso
relacionadas con actividades que apoyan el desarrollo y
mantenimiento del producto, y que están dirigidas a los
procesos que son usados en el contexto del desarrollo de procesos
pertenecientes a otras áreas [Chr06].

Ingeniería: Cubre actividades relacionadas
al desarrollo y mantenimiento que son compartidas por toda la
organización. Cualquier disciplina técnica
involucrada en desarrollo de productos o servicios puede ocupar
esta categoría para enfocar el proceso de
mejora.

Áreas de
Proceso de Ingeniería

Las áreas de proceso de Ingeniería pueden
integrar los procesos asociados con diferentes disciplinas de
ingeniería cuando el producto final es consecuencia de
ellas, dando así un soporte para estrategias
organizacionales orientas en el producto. Las áreas de
proceso pertenecientes a la categoría de Ingeniería
están indicadas en la Tabla 2 y ellas son:

• Desarrollo de Requerimientos (RD).

• Gestión de Requerimientos
(REQM).

• Solución Técnica (TS).

• Integración de Productos (PI).

• Verificación (VER).

• Validación (VAL).

La Figura 4 muestra las
relaciones existentes entre las distintas áreas de proceso
de la categoría señalada.

Figura 4: Relación entre
Áreas de Proceso de Ingeniería

RD identifica las necesidades de un cliente y las
transforma en "requerimientos del producto". Luego, estos son
analizados para producir "requerimientos de las componentes del
producto", "requerimientos de interfaz de las componentes" y un
modelo conceptual de alto nivel de la solución
[Chr06].

Los distintos requerimientos son suministrados a TS que
produce una arquitectura del
producto, un diseño del producto en componentes y
diseño de las propias componentes. Además, TS
desarrolla cada componente las cuales son suministradas a PI –
donde las componentes son integradas verificando el cumplimiento
de las interfaces que fueron definidas. TS utiliza a VER para
realizar la verificación del diseño.

REQM mantiene los requerimientos – describiendo
actividades para obtener y controlar los cambios – y la
trazabilidad de las necesidades del cliente al producto. Como
REQM controla los cambios a los requerimientos que pueden tener
como fuente todas las otras áreas de proceso de
Ingeniería, esta área de proceso es recursiva,
dinámica y transversal a la
categoría.

El área de proceso VER asegura que los artefactos
satisfacen los requerimientos especificados. VER es un
área incremental, pues comienza con la verificación
de las componentes del producto para terminar con la
verificación del producto completo.

VAL es un área de proceso incremental que valida
el producto, las componentes del producto, los artefactos
intermedios y los procesos con respecto a las necesidades de los
clientes. Los conflictos que
son descubiertos son usualmente resueltos en RD y TS.

PI es el responsable de generar la mejor secuencia de
integración de componentes posible, integrarlas y dar la
aprobación para la entrega del producto al cliente. PI usa
prácticas específicas de VER y VAL para implementar
el proceso de integración del producto.

A continuación se detalla cada una de las
áreas de proceso de la categoría de
Ingeniería del modelo CMMI. Esta información fue
obtenida de la referencia del modelo, CMMI para Desarrollo v1.2
(ver [Chr06]).

1. Administración de
   Requerimientos

2. El área de proceso Administración de
   Requerimientos (REQM) se encarga de administrar todos los
   requerimientos recibidos o generados por el proyecto,
   incluyendo tanto los técnicos y no-técnicos
   como los impuestos por
   la organización. Cuando un proyecto recibe
   requerimientos, estos son revisados con un proveedor para
   resolver inconsistencias y malentendidos antes de ser
   ingresados a los planes del proyecto. El jefe de proyecto
   administra los cambios en los requerimientos a medida que el
   proyecto avanza e identifica inconsistencias que ocurren
   entre planes, productos de trabajo y
   requerimientos.

   SG 1: Administrar
   Requerimientos

   Objetivo: "Los requerimientos deben ser
   administrados y las inconsistencias con el plan de
   proyecto y artefactos son identificadas"

   Los proyectos deben mantener actualizados y
   aprobados el conjunto de requerimientos durante el transcurso
   del proyecto para realizar lo siguiente:

   – Administrar todos los cambios en los
   requerimientos.

   – Mantener las relaciones entre los requerimientos,
   el plan del proyecto y los productos de trabajo.

   – Identificar las inconsistencias entre los
   requerimientos, el plan del proyecto y los productos de
   trabajo.

   – Tomar las acciones correctivas.

   • SP 1 Obtener una comprensión de los
     requerimientos

   Práctica: "Desarrollar entendimiento
   común con los responsables de entregar los
   requerimientos sobre el significado y alcance de cada uno de
   ellos"

   A medida que el proyecto avanza y los requerimientos
   son derivados, todas las actividades o disciplinas
   recibirán requerimientos. Para evitar un flujo
   descontrolado de requerimientos, se establecen criterios para
   señalar las fuentes oficiales de las cuales
   recibirlos. Se debe asegurar un entendimiento compatible y
   compartido con los proveedores de requerimientos sobre el
   significado de cada uno de ellos. El resultado de este
   análisis y diálogo es un conjunto de
   requerimientos consensuado.

   • SP 2 Obtener compromiso con los
     requerimientos

   Práctica: "Obtener compromiso de
   requerimientos por parte del los participantes del
   proyecto"

   Mientras la práctica específica
   anterior se ocupa de alcanzar entendimiento con los
   proveedores de requerimientos, esta práctica
   específica se refiere a los acuerdos y compromisos de
   quienes tienen que cumplir con las actividades necesarias
   para implementar los requerimientos, es decir, el equipo de
   proyecto.

   A medida que los requerimientos evolucionan, esta
   práctica específica asegura que los
   participantes del proyecto se comprometan con los
   requerimientos aprobados y con los cambios resultantes en
   planes, actividades y artefactos.

   • SP 3 Administrar cambios a los
     requerimientos

   Práctica: "Manejar cambios de
   requerimientos a medida que estos se desarrollan durante el
   proyecto"

   Durante el proyecto, los requerimientos cambian por
   distintas razones. A medida que las necesidades cambian y el
   trabajo avanza, se obtienen requerimientos adicionales y
   puede ser necesario modificar los existentes. Es esencial
   administrar estos requerimientos nuevos y modificados en
   forma efectiva y eficiente. Para analizar el impacto de los
   cambios de forma efectiva, es necesario que la fuente de cada
   requerimiento sea conocida y que el fundamento del cambio sea
   documentado. El Jefe de Proyecto puede, sin embargo,
   verificar métricas apropiadas de volatilidad de
   requerimientos para juzgar si se requieren nuevos controles o
   modificar los actuales.

   • SP 4 Mantener trazabilidad bidireccional de los
     requerimientos

   Práctica: "Mantener trazabilidad
   bidireccional entre requerimientos y
   artefactos".

   El propósito de esta SP es mantener la
   trazabilidad bidireccional por cada nivel de
   descomposición del producto final.

   Cuando los requerimientos son bien administrados, la
   trazabilidad puede ser establecida desde la fuente del
   requerimiento a su nivel más bajo, y desde el nivel
   más bajo volver a sus orígenes. Dicha
   trazabilidad bidireccional ayuda a determinar que todos los
   requerimientos fuente han sido completamente abordados y que
   todos los requerimientos de más bajo nivel puedan ser
   relacionados con una fuente válida. La trazabilidad
   puede también cubrir relaciones horizontales, tales
   como interfaces y es particularmente necesaria al evaluar el
   impacto de cambios a requerimientos en los planes,
   actividades y productos de trabajo del proyecto.

   • SP 5: Identificar inconsistencias entre
     artefactos del proyecto y los requerimientos

   Práctica: "Identificar inconsistencias
   entre los planes de proyecto y artefactos y los
   requerimientos"

   Esta práctica específica detecta las
   inconsistencias entre requerimientos y los planes de proyecto
   y artefactos, e inicia las acciones correctivas para
   solucionarlas.

   Desarrollo de
   Requerimientos

   El área de proceso de Desarrollo de
   Requerimientos (RD) se encarga de identificar las necesidades
   de los clientes y traducirlas en requerimientos. El conjunto
   de requerimientos de un proyecto es analizado para producir
   una solución conceptual de alto nivel. Estos
   requerimientos se destinan a ciertos componentes del producto
   final y son los que describen su rendimiento,
   características de diseño, su
   verificación, etc. para comprensión y
   utilización futura por parte de
   desarrolladores.

   SG 1: Desarrollar requerimientos del
   cliente

   Objetivo: "Necesidades de las partes interesadas,
   expectaciones, restricciones, e interfaces son recogidas y
   traducidas en requerimientos del cliente".

   Las necesidades de las partes interesadas (clientes,
   usuarios finales, proveedores, desarrolladores y encargados
   de prueba) son la base para determinar los requerimientos del
   cliente. Estas necesidades, expectativas, restricciones,
   interfaces, conceptos operacionales y conceptos de productos
   son analizados, matizados, refinados y elaborados para
   traducirlos en un conjunto de requerimientos del cliente.
   Frecuentemente estas son mal identificadas o contradictorias.
   Ya que las necesidades de actores, expectativas,
   restricciones y limitaciones deben ser claramente
   identificadas y entendidas, un proceso iterativo es usado
   durante todo el proyecto para conseguir este objetivo. Para
   facilitar la interacción requerida, un sustituto del
   usuario final o cliente es frecuentemente involucrado para
   representar las necesidades de éste y ayudar a
   resolver conflictos. Restricciones de ambiente, legales y
   otras debieran ser consideradas cuando se crea o resuelve el
   conjunto de requerimientos del cliente.

   • SP 1: Obtener necesidades

   Práctica: "Identificar y recoger las
   necesidades, expectativas, restricciones e interfaces de las
   partes interesadas para todas las fases del ciclo de vida del
   producto".

   La obtención va más allá de
   recopilar requerimientos, ya que implica buscar activamente
   la identificación de requerimientos que no hayan sido
   provistos explícitamente por el cliente. Los
   requerimientos adicionales debiesen abordar las diversas
   actividades del ciclo de vida del producto y su impacto en
   él.

   • SP 2: Desarrollar los requerimientos del
     cliente

   Práctica: "Transformar las necesidades de
   las partes interesadas, expectativas, restricciones e
   interfaces en requerimientos del cliente".

   Las distintas entradas de las partes interesadas
   deben ser consolidadas, la información faltante debe
   ser obtenida y los conflictos deben ser resueltos al
   documentar el conjunto de requerimientos reconocidos por el
   cliente. Los requerimientos del cliente pueden incluir
   necesidades, expectativas y restricciones con respecto a
   verificación y validación.

   En algunas situaciones, el cliente provee un
   conjunto de requerimientos al proyecto, o los requerimientos
   existen como una salida de actividades anteriores del
   proyecto. En estos casos, los requerimientos del cliente
   podrían contradecir las necesidades, expectativas,
   restricciones e interfaces de las partes interesadas y
   deberán ser transformadas en un conjunto de
   requerimientos reconocidos por el cliente, luego de resolver
   los conflictos adecuadamente.

   Las partes interesadas que forman parte de todas las
   etapas del ciclo de vida del producto debieran incluir
   funciones
   técnicas y de negocios.
   De esta manera, los conceptos de todos los procesos
   relacionados con el ciclo de vida del producto son
   considerados junto con el concepto del
   producto.

   SG 2: Desarrollar requerimientos de
   productos

   Objetivo: "Requerimientos del cliente son
   refinadas y elaboradas para desarrollar requerimientos del
   producto y componentes del producto".

   Los requerimientos del cliente son analizados en
   conjunto con el desarrollo del concepto operacional para
   obtener un conjunto de requerimientos más detallado y
   preciso y se le llama requerimientos del producto y de
   componentes del producto. Los requerimientos del producto y
   de componentes del producto abordan las necesidades asociadas
   con cada fase del ciclo de vida del producto. De los
   requerimientos obtenidos surgen de las restricciones,
   consideraciones de temas no explícitamente indicados
   en la línea base de requerimientos del cliente y
   factores introducidos por la arquitectura seleccionada, el
   diseño y las consideraciones específicas de
   negocio del desarrollador. Los requerimientos son revisados
   con nivel anterior de conjunto de requerimientos y
   arquitectura funcional, y el concepto preferido del producto
   es refinado.

   Los requerimientos son asociados a funciones y
   componentes del producto incluyendo objetos, personas y
   procesos. La trazabilidad de los requerimientos a funciones,
   objetos, pruebas,
   problemas u otras entidades es documentada. Los
   requerimientos asociados y las funciones son la base de la
   síntesis de la solución
   técnica. A medida que los componentes internos son
   desarrollados se definen interfaces adicionales y establecen
   los requerimientos de interfaz.

   • SP 1: Establecer requerimientos del producto y de
     componentes del producto

   Práctica: "Establecer y mantener
   requerimientos del producto y componentes del producto, los
   cuales son basados en los requerimientos del
   cliente".

   Los requerimientos del cliente pueden ser expresados
   en los términos del cliente y pueden ser descripciones
   no técnicas. Los requerimientos del producto son la
   expresión de estos requerimientos en términos
   técnicos que pueden ser usados para decisiones de
   diseño.

   Requerimientos del producto y de componentes del
   producto abordan la satisfacción del cliente, los
   negocios, los objetivos del proyecto y los atributos
   asociados, tales como eficacia y
   economía. También abordan el
   costo y
   rendimiento de otras fases del ciclo de vida.

   La modificación de requerimientos debido a la
   aprobación de cambios en estos es cubierta por
   funciones de mantenimiento de esta área de proceso;
   mientras que la administración de cambios de
   requerimientos es cubierta por el área de proceso de
   Administración de Requerimientos.

   • SP 2: Destinar requerimientos de componentes del
     producto

   Práctica: "Destinar los requerimientos por
   cada componente del producto".

   Los requerimientos de componentes del producto
   incluyen el destino de éstos al comportamiento del producto final, el
   diseño de restricciones y el ajuste, formación
   y creación de funciones para satisfacer los
   requerimientos y facilitar la producción. En los casos
   donde los requerimientos de alto nivel especifiquen
   comportamiento que será responsabilidad de dos o más
   componentes del producto, este comportamiento debe ser
   dividido para ser asociado a cada componente de producto como
   requerimiento derivado.

   • SP 3: Identificar requerimientos de
     interfaz

   Práctica: "Identificar requerimientos de
   interfaz".

   Interfaces entre funciones (o entre objetos) son
   identificadas. Interfaces funcionales pueden impulsar el
   desarrollo de soluciones alternativas. Los requerimientos de
   interfaces entre productos o entre componentes del producto
   identificados en la arquitectura del producto son definidos.
   Estos son controlados como parte de la integración del
   producto y componentes del producto y son parte integral de
   la definición de la arquitectura.

   SG 3: Analizar y validar
   requerimientos

   Objetivo: "Los requerimientos son analizados y
   validados, y una definición de la funcionalidad
   requerida es desarrollada".

   Las prácticas específicas de este
   objetivo específico apoyan el desarrollo de los
   requerimientos en los objetivos específicos 1 y 2. Las
   prácticas específicas asociadas con este
   objetivo cubren el análisis y validación de
   requerimientos con respecto al ambiente previsto por el
   usuario.

   Los análisis son desarrollados para
   determinar que impacto tendrá el ambiente operacional
   previsto en la habilidad para satisfacer las necesidades de
   las partes interesadas, sus expectativas, restricciones e
   interfaces. Aspectos como viabilidad, necesidades de misión
   corporativa, restricciones de costos,
   tamaño de potencial de mercado y estrategia
   de adquisición deben ser tomados en
   consideración dependiendo del contexto del
   producto.

   Los objetivos de los análisis son determinar
   requerimientos candidatos para conceptos de productos que van
   a satisfacer las necesidades, expectativas y restricciones de
   las partes interesadas y luego traducir estos conceptos a
   requerimientos. En paralelo con esta actividad, los
   parámetros que serán usados para evaluar la
   eficacia del producto son determinados basados en la
   información del cliente y el concepto preliminar del
   producto.

   Los requerimientos son validados para aumentar la
   probabilidad
   de que el producto resultante funcionará como se
   espera en el ambiente de producción.

   • SP 1: Establecer conceptos operacionales y
     escenarios

   Práctica: "Establecer y mantener conceptos
   operacionales y escenarios asociados".

   Un escenario es típicamente una secuencia de
   eventos que
   pueden ocurrir en la utilización del producto, el cual
   es usado para hacer explicitas algunas de las necesidades de
   las partes interesadas. En contraste, un concepto operacional
   para un producto usualmente depende de la solución de
   diseño y del escenario. Ya que las soluciones
   alternativas no son usualmente definidas cuando se definen
   los conceptos operacionales iniciales, las soluciones
   conceptuales son desarrolladas para usarse cuando se analizan
   los requerimientos. Los conceptos operacionales son refinados
   a medida que las decisiones sobre la solución son
   tomadas y requerimientos de más bajo nivel detallados
   son desarrollados.

   Así como una decisión de diseño
   para un producto puede convertirse en un requerimiento para
   componentes del producto, el concepto operacional puede
   convertirse en escenarios (requerimientos) para componentes
   del producto. Los conceptos operacionales y escenarios son
   desarrollados para facilitar la selección de
   soluciones para componentes del producto que podrán,
   cuando se implementen, satisfacer el uso esperado del
   producto. Los conceptos operacionales y escenarios documentan
   la interacción de los componentes del producto con el
   ambiente, los usuarios y otros componentes del producto
   independiente de la disciplina de ingeniería. Los
   escenarios pueden incluir secuencias operacionales, si
   éstas son una expresión de los requerimientos
   del cliente más que conceptos
   operacionales.

   • SP 2: Establecer una definición de la
     funcionalidad requerida

   Práctica: "Establecer y mantener una
   definición de la funcionalidad
   requerida".

   La definición de funcionalidad,
   también referida como "análisis funcional", es
   la descripción de lo que se pretende que el producto
   haga. La definición de funcionalidad puede incluir
   acciones, secuencias, entradas, salidas u otra
   información que dé a conocer la manera en la
   cual el producto va a ser usado.

   El análisis funcional no es lo mismo que el
   análisis estructurado en Desarrollo de Software y no
   supone un diseño de software orientado a la
   funcionalidad. En el diseño de software orientado al
   objeto, se relaciona con definir los denominados "servicios"
   o "métodos". La definición de funciones, sus
   agrupaciones lógicas y sus asociaciones con
   requerimientos es referido como arquitectura
   funcional.

   • SP 3: Analizar requerimientos

   Práctica: "Analizar requerimientos para
   asegurar que ellos son necesarios y
   suficientes".

   A la luz del
   concepto operacional y los escenarios, los requerimientos
   para un nivel de la jerarquía del producto son
   analizados para determinar si ellos son necesarios y
   suficientes para alcanzar los objetivos de niveles más
   altos de la jerarquía del producto. Los requerimientos
   analizados proveen la base para requerimientos más
   detallados y precisos en niveles inferiores de la
   jerarquía de productos.

   Mientras los requerimientos son definidos, sus
   relaciones con requerimientos y la funcionalidad definida de
   más alto nivel deben ser entendidas. Otra de las
   acciones es la determinación de cuáles
   requerimientos claves serán usados para medir el
   avance. Por ejemplo, el peso de un producto o el
   tamaño de un software pueden ser monitoreados durante
   su desarrollo basándose en sus riesgos.

   • SP 4: Analizar requerimientos para lograr
     balance

   Práctica: "Analizar requerimientos para
   balacear necesidades y restricciones de los
   Stakeholders".

   Necesidades y restricciones pueden abordar costos,
   cronogramas, funcionalidades, componentes reutilizables,
   mantenimiento o riesgos.

   • SP 5: Validar requerimientos

   Práctica: "Los requerimientos se validan
   para asegurar que el producto resultante operará como
   está previsto en el ambiente del
   usuario"

   La validación de requerimientos es realizada
   tempranamente con los usuarios para obtener certeza de que
   los requerimientos permitirán guiar el desarrollo que
   resulte en una validación final exitosa. Las
   organizaciones maduras típicamente realizarán
   validación de requerimientos de una manera más
   sofisticada aplicando diversas técnicas y
   ampliarán la base de la validación para incluir
   necesidades y expectativas de otras partes
   interesadas.

   1. Solución
      Técnica

   El PA de Solución Técnica (TS) tiene
   como propósito diseñar, desarrollar e
   implementar soluciones a requerimientos. Es aplicable a
   cualquier nivel de la arquitectura del producto y a cada
   producto, componente de producto y proceso relacionado con el
   ciclo de vida del producto. Estos procesos relacionados con
   el ciclo de vida del producto son desarrollados conjuntamente
   con el producto y los componentes del producto. Dicho
   desarrollo puede incluir la selección o
   adaptación de procesos existentes (procesos
   estándares) o el desarrollo de nuevos
   procesos.

   SG 1: Seleccionar soluciones para componentes
   del producto

   Objetivo: "Soluciones de producto o de
   componentes del producto son seleccionadas a partir de
   alternativas de solución".

   Las soluciones alternativas y sus ventajas relativas
   son consideradas antes de seleccionar una solución.
   Los requerimientos claves, los temas de diseño y las
   restricciones son establecidos para ser utilizados en el
   análisis de soluciones alternativas. Las
   características de la arquitectura que proveen una
   base para la mejora y evolución del producto son
   consideradas. El uso de componentes de producto tipo COTS
   (Commercial Off The Shelf) es considerado en relación
   con costos, cronograma, rendimiento y riesgos. Las
   alternativas tipo COTS pueden ser utilizadas con o sin
   adaptaciones. En ocasiones, dichos elementos requieren
   modificaciones en aspectos tales como interfaces o
   personalización de alguna de sus
   características para cumplir en mejor forma con los
   requerimientos del producto.

   Un indicador de buen proceso de diseño es que
   el diseño fue escogido después de compararlo y
   evaluarlo con soluciones alternativas. Las decisiones de
   arquitectura deben ser tomadas. Algunas de estas decisiones
   pueden requerir un proceso formal de toma de
   decisiones.

   En general las soluciones son definidas como un
   conjunto. Esto significa que al definir la siguiente capa de
   componentes, la solución para cada uno de los
   componentes del conjunto es definida. Las soluciones
   alternativas no son sólo formas distintas de abordar
   los mismos requerimientos, sino también reflejan un
   destino diferente de requerimientos entre los componentes del
   producto que componen el conjunto solución. El
   objetivo es optimizar el conjunto de requerimientos como un
   todo y no sus partes.

   • SP 1: Desarrollar soluciones alternativas y
     criterios de selección

   Práctica: "Desarrollar alternativas de
   solución y criterios de
   selección".

   Las alternativas de solución deben ser
   identificadas y analizadas para poder seleccionar una
   solución equilibrada a través del ciclo de vida
   del producto en términos de costos, cronograma y
   rendimiento. Estas soluciones se basan en arquitecturas de
   producto propuestas que abordan características
   críticas del producto y abarcan un conjunto de
   soluciones factibles.

   Las alternativas de soluciones frecuentemente
   comprenden asociaciones alternativas de requerimientos a
   diferentes componentes del producto. Dichas alternativas
   pueden incluir el uso de soluciones COTS en la arquitectura
   del producto.

   Las alternativas de soluciones cubren el rango
   aceptable de costo, cronograma y rendimiento. Los
   requerimientos de componentes del producto son recibidos y
   utilizados junto con problemas de diseño,
   restricciones, y criterios para desarrollar soluciones
   alternativas. Los criterios de selección
   abordarán típicamente costos (tiempo,
   recursos
   humanos y otros gastos) y
   riesgos (técnicos, de costo y cronograma). Las
   consideraciones para alternativas de soluciones y criterios
   de selección incluyen lo siguiente:

   – Costo de desarrollo, construcción, adquisición,
   mantenimiento, soporte, etc.

   – Rendimiento.

   – Complejidad de componentes del producto y de
   procesos relacionados con su ciclo de vida.

   – Robustez del producto en operación y
   condiciones de uso, modos de operación, ambientes y
   variaciones de los procesos relacionados con el ciclo de vida
   del producto.

   – Expansión y crecimiento del
   producto.

   – Limitantes de la tecnología.

   – Sensibilidad a los métodos y materiales
   de construcción.

   – Riesgos.

   – Evolución de requerimientos y
   tecnología.

   – Dada de baja (eliminación) del
   producto.

   – Capacidades y limitantes de usuarios finales y
   operadores.

   – Características de productos tipo
   COTS.

   La anterior es una lista básica de
   consideraciones. Las organizaciones debieran hacer
   proyecciones para acortar la lista de alternativas que sean
   consistentes con sus objetivos de negocio. Los costos de
   ciclo de vida del producto pueden estar fuera del control de
   las organizaciones de desarrollo aunque sea un
   parámetro atractivo para minimizar costos. Un cliente
   puede no estar dispuesto a pagar por funciones que cuestan
   más en el corto plazo pero que en última
   instancia disminuyen el costo durante la vida útil del
   producto. En tales casos, los clientes debieran al menos
   estar informados de las posibilidades de reducir los costos
   durante la vida útil de un producto. Los criterios
   utilizados para seleccionar las soluciones finales debieran
   proveer un enfoque equilibrado de costos, beneficios y
   riesgos.

   • SP 2: Seleccionar soluciones para componentes del
     producto

   Práctica: "Seleccionar las componentes del
   producto que mejor satisfacen los criterios
   establecidos".

   Seleccionar soluciones para componentes del producto
   que mejor satisfagan los criterios establecidos.
   Requerimientos de más bajo nivel son generados a
   partir de la alternativa seleccionada y utilizados para
   desarrollar el diseño de los componentes de producto.
   Los requerimientos de interfaz entre componentes de producto
   son funcionalmente descritos al inicio. Las descripciones de
   interfaz física son
   incluidas en la documentación de interfaces hacia
   elementos y actividades externas al producto.

   La descripción de soluciones y los
   fundamentos de la selección son documentadas. La
   documentación evoluciona a medida que las soluciones y
   los diseños son detallados, desarrollados e
   implementados. El mantenimiento de un registro de
   fundamentos es crítico para la toma de
   decisiones.

   SG 2: Desarrollar el diseño

   Objetivo: "Diseños del producto y
   componentes del producto son desarrolladas"

   Diseños de productos o componentes de
   productos deben proveer el contenido apropiado no sólo
   para la implementación, sino también para otras
   fases del ciclo de vida del producto tales como
   modificación, adquisición, mantenimiento e
   instalación. La documentación de diseño
   provee una referencia para apoyar el entendimiento mutuo del
   diseño por parte de las partes interesadas y
   así apoyar futuros cambios al diseño ya sea
   durante el desarrollo como en las fases siguientes del ciclo
   de vida del producto. Una descripción completa del
   diseño es documentada incluyendo una completa gama de
   características y parámetros incluyendo forma,
   ajuste, función, interfaz,
   características del proceso de construcción y
   otros parámetros. Estándares establecidos de
   diseño de proyecto u organizacionales (listas,
   plantillas, estructura
   de objetos) forman la base para alcanzar un alto grado de
   definición y completitud en la documentación
   del diseño.

   • SP 1: Diseñar el producto o los
     componentes del producto

   Práctica: "Desarrollar un diseño
   para el producto o componente del producto".

   El diseño del producto consiste en dos
   extensas fases que pueden superponerse en ejecución:
   diseño preliminar y diseño detallado. El
   diseño preliminar establece las capacidades y la
   arquitectura del producto, incluyendo divisiones del
   producto, identificación de los componentes del
   producto, estados de sistemas y modos, interfaces principales
   e interfaces externas del producto. El diseño
   detallado define completamente la estructura y las
   capacidades de los componentes del producto.

   La definición de la arquitectura es guiada a
   partir de un conjunto de requerimientos de arquitectura.
   Estos requerimientos expresan los elementos de calidad y
   rendimiento que son críticos para el éxito del
   producto. La arquitectura define los elementos estructurales
   y los mecanismos de coordinación que directamente
   satisfacen los requerimientos o apoyan su realización
   a medida que se establecen los detalles del diseño del
   producto. Las arquitecturas pueden incluir estándares
   y reglas de diseño que dirigen el desarrollo de los
   componentes del producto y sus interfaces, así como
   una guía para ayudar a sus desarrolladores.

   Los arquitectos postulan y desarrollan un modelo del
   producto, haciendo juicios sobre la asociación de
   requerimientos con los componentes del producto, incluyendo
   hardware y
   software. Múltiples arquitecturas que apoyan las
   soluciones alternativas pueden ser desarrolladas y analizadas
   para determinar las ventajas y desventajas en el contexto de
   los requerimientos de arquitectura.

   Los conceptos operacionales y escenarios son usados
   para generar casos de uso y escenarios de calidad que se usan
   para refinar la arquitectura. También son usados como
   un medio para evaluar qué tan apropiada es la
   arquitectura para el propósito previsto durante las
   evaluaciones, las cuales son realizadas periódicamente
   durante todo el diseño del producto.

   Durante el diseño detallado, los detalles de
   la arquitectura del producto son finalizados, los componentes
   del producto son definidos completamente y las interfaces son
   descritas en su totalidad. Los diseños de los
   componentes de productos pueden ser optimizados para ciertas
   características de rendimiento o calidad. A medida que
   el diseño madura, los requerimientos asignados a
   componentes de productos de más bajo nivel son
   monitoreados para asegurar que esos requerimientos son
   satisfechos.

   • SP 2: Establecer un paquete de datos
     técnicos

   Práctica: "Establecer y mantener un
   paquete de datos técnicos".

   Un paquete de datos técnicos provee al
   desarrollador una descripción exhaustiva del producto
   o de sus componentes a medida que es desarrollado. Dicho
   paquete también provee flexibilidad de adquisiciones
   en diversas circunstancias, tales como "Performance-Based
   Contracting" (PBC) o "Build To Print".

   El diseño es registrado en un paquete de
   datos técnicos creado durante el diseño
   preliminar para documentar la definición de la
   arquitectura. Este paquete de datos técnicos es
   mantenido durante toda la vida del producto para registrar
   detalles esenciales del diseño del producto. El
   paquete de datos técnicos provee la descripción
   del producto y sus componentes que apoyan la estrategia de
   adquisición, o la implementación,
   producción, ingeniería y fases de soporte
   logístico del ciclo de vida del producto. La
   descripción incluye la definición de la
   configuración requerida del diseño y
   procedimientos para asegurar el comportamiento adecuado del
   producto o de sus componentes. Esto incluye todos los datos
   técnicos aplicables como dibujos,
   listas asociadas, especificaciones, descripciones de
   diseño, bases de
   datos de diseño, estándares, requerimientos
   de rendimiento, provisiones de aseguramiento de calidad y
   detalles de empaquetamiento. El paquete de datos
   técnicos incluye una descripción de la
   solución alternativa seleccionada a ser
   implementada.

   Un paquete de datos técnicos debería
   incluir lo siguiente, si dicha información es
   apropiada para el tipo de producto y componentes del
   producto:

   – Descripción de arquitectura de
   producto.

   – Requerimientos asignados.

   – Descripción de componentes del
   producto.

   – Descripción de los procesos relacionados
   con el ciclo de vida del producto, si no es descrito como
   componentes de productos separados.

   – Características de productos
   claves.

   – Características físicas requeridas y
   restricciones.

   – Requerimientos de interfaz.

   – Requerimientos de materiales.

   – Fabricación y requerimientos de manufactura.

   – Criterios de verificación usados para
   asegurar que los requerimientos han sido
   satisfechos.

   – Condiciones de uso (ambientes) y escenarios de uso
   / operación, modos y estados de operación,
   soporte, capacitación, manufactura,
   eliminación del producto y verificaciones a los largo
   de la vida útil del producto.

   – Fundamentos de decisiones y características
   (requerimientos, asignación de requerimientos y
   opciones de diseño).

   Debido a que las descripciones de diseño
   pueden contener una gran cantidad de información y
   pueden ser cruciales para el desarrollo exitoso de los
   componentes del producto, es aconsejable establecer criterios
   para organizar y seleccionar la información. Es
   particularmente útil utilizar la arquitectura del
   producto como una manera de organizar la información y
   elaborar vistas claras y relevantes para un tema o
   característica de interés. Estas vistas
   incluyen lo siguiente:

   – Clientes.

   – Requerimientos.

   – El ambiente.

   – Funcionalidad.

   – Lógica.

   – Seguridad.

   – Datos.

   – Estados / modos.

   – Construcción.

   – Administración

   Estas vistas son documentadas en el paquete de datos
   técnicos.

   • SP 3: Diseñar interfaces utilizando
     criterios

   Práctica: "Diseñar interfaces de
   componentes del producto utilizando los criterios
   establecidos".

   Estos diseños de interfaces incluyen lo
   siguiente:

   – Orígenes.

   – Destino.

   – Estímulos y características de datos
   para el software

   – Características eléctricas,
   mecánicas y funcionales para hardware

   – Líneas de comunicación.

   El criterio para interfaces frecuentemente refleja
   parámetros críticos que deben ser definidos, o
   al menos investigados, para asegurar su aplicabilidad. Estos
   parámetros son a menudo característicos de un
   cierto tipo de producto (software, mecánico,
   eléctrico, de servicio)
   y son a menudo asociados con seguridad, durabilidad y
   características de la misión
   crítica.