Monografias.com > Sin categoría
Descargar Imprimir Comentar Ver trabajos relacionados

Modelo CMMI (página 2)



Partes: 1, 2, 3, 4, 5

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

 

Representación
Continua

Representación
Escalonada

Nivel de Capacidad

Nivel de Madurez

Nivel 0

Incompleto

Nivel 1

Realizado

Inicial

Nivel 2

Manejado

Manejado

Nivel 3

Definido

Definido

Nivel 4

Manejado
cuantitativamente

Manejado
cuantitativamente

Nivel 5

Optimizando

Optimizando

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.

Área de proceso

Categoría

Nivel de Madurez

Análisis y Resolución Causales
(CAR)

Soporte

5

Análisis y Resolución de Decisiones
(DAR)

Soporte

3

Aseguramiento de la Calidad de Procesos y
Productos (PPQA)

Soporte

2

Definición de Procesos Organizacionales
+IPPD(OPD +IPPD)

Gestión de procesos

3

Desarrollo de Requerimientos (RD)

Ingeniería

3

Entrenamiento Organizacional (OT)

Gestión de procesos

3

Administración Cuantitativa de Proyectos
(QPM)

Gestión de proyectos

3

Administración de Acuerdos con Proveedores (SAM)

Ingeniería

2

Administración de Requerimientos
(REQM)

Gestión de proyectos

3

Administración de Riesgos (RSKM)

Soporte

2

Administración de la Configuración
(CM)

Gestión de proyectos

3

Administración Integral de Proyecto + IPD
(IPM+IPPD) 1

Gestión de proyectos

3

Innovación y Despliegue Organizacional
(OID)

Gestión de procesos

5

Integración de Producto (PI)

Ingeniería

3

Medición y Análisis (MA)

Soporte

2

Monitoreo y Control de Proyecto (PMC)

Gestión de proyectos

2

Planificación de Proyecto (PP)

Gestión de proyectos

2

Procesos Orientados a la Organizacionales
(OPF)

Gestión de procesos

3

Rendimiento de Procesos Organizacionales
(OPP)

Gestión de procesos

4

Solución Técnica (TS)

Ingeniería

3

Validación (VAL)

Ingeniería

3

Verificación (VER)

Ingeniería

3

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.

Partes: 1, 2, 3, 4, 5
 Página anterior Volver al principio del trabajoPágina siguiente 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

Categorias
Newsletter