Modelo de calidad CMMI (página 2)

Modelos de Madurez de
Capacidades

Las dimensiones críticas de una empresa son: la
gente, los procedimientos y métodos, y las herramientas y
equipo.  Los procesos son los encargados de unir tales
dimensiones con el propósito de alcanzar los objetivos del
negocio. El enfoque en los procesos ayuda a construir una
plataforma de mejora continua, ya que se está de acuerdo
en que la gente y la tecnología cambian y son sólo
los procesos los que transcienden en el tiempo,
adaptándose a nuevas personas y
tecnologías. 

           
El Software Engineering Institute (SEI) de la Carnegie Mellon
University de los Estados Unidos, creador del modelo CMMI y de la
mayoría de sus predecesores, ha elaborado sus modelos bajo
la premisa que la calidad de un producto o servicio está
altamente influenciada por la calidad de los procesos que los
producen y los mantienen [Chr06].  Es por ello que la mejora
continua de los procesos debiese ir paulatinamente incrementando
el nivel de capacidad y madurez de una organización. Los
procesos en conjunto transitan desde procesos no definidos, es
decir, procesos cuya organización cuenta con poca
capacidad y con inmadurez para realizarlos, a procesos
disciplinados cuya organización cuenta con la capacidad y
madurez suficiente para desarrollarlos con calidad probada. Luego
una organización es capaz de definir su calidad total por
medio del nivel de madurez de capacidades en que se encuentre de
acuerdo a sus procesos.

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

Administración de
Requerimientos

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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