Aporte del Ing: Roberto Martínez Hernández
Alumno: Antonio Emmanuel Blanco Vidal
1)
Mencione cuales son los principios en los
que se basa el CCMI
Integración de modelos de
madurez de capacidades o Capability maturity model integration (CMMI) es
un modelo para la mejora y evaluación de procesos para el desarrollo,
mantenimiento y operación de sistemas de software. Las mejores prácticas CMMI se publican en los
documentos llamados modelos. En la actualidad hay tres áreas de interés cubiertas
por los modelos de CMMI: Desarrollo,
Adquisición y Servicios. La versión actual de CMMI es la versión 1.3 la
cual corresponde a CMMI-SVC, liberada el 1 de noviembre de 2010. Hay tres
constelaciones de la versión 1.2 disponible:
- CMMI para el Desarrollo
(CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de
2006. En él se tratan procesos de desarrollo de productos y servicios.
- CMMI para la adquisición
(CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre
de 2007. En él se tratan la gestión de la cadena de suministro,
adquisición y contratación externa en los procesos del gobierno y la
industria.
- CMMI para servicios
(CMMI-SVC o CMMI for Services), está diseñado para cubrir todas las
actividades que requieren gestionar, establecer y entregar Servicios.
Dentro
de la constelación CMMI-DEV, existen dos modelos:
- CMMI-DEV
- CMMI-DEV + IPPD
(Integrated Product and Process Development)
Independientemente
de la constelación\modelo que opta una organización, las prácticas CMMI deben
adaptarse a cada organización en función de sus objetivos de negocio. Las
organizaciones no pueden ser certificadas CMMI.
En conclusión: Se Constituye
una forma de medir el grado de madurez de las organizaciones, con el
objetivo de establecer una guía que les permita mejorar sus procesos y su
habilidad para organizar, desarrollar, adquirir y mantener productos y
servicios informáticos.
2)
Desde su
punto de vista ¿Cuáles son las ventajas que se obtiene con el CCMI?
La gran ventaja de CMMI
es que ha demostrado ser una metodología de gran eficacia, que ha permitido
mejoras de gran impacto en procesos de desarrollo de productos de software,
tales como reducción del coste de desarrollo, localización y resolución de defectos;
mejora en la fiabilidad de la planificación, en términos de dedicación y de
calendario; aumento de productividad, reducción de los trabajos derivados de
correcciones tras las faces de pruebas, aumento de la efectividad sobre la planificación
realizada, mejora en la calidad de producto, reducción del numero de defectos,
y detección en las faces tempranas de su ciclo de vida y mejora de la imagen de Marca,
entre otras.
3) Liste
cuales son las mejoras mas recientes que se le han hecho al CMMI.
Modelos
CMMI
Las mejores prácticas CMMI se
publican en los documentos llamados modelos. En la actualidad hay tres áreas de
interés cubiertas por los modelos de CMMI: Desarrollo, Adquisición y Servicios.
La versión actual de CMMI es
la versión 1.3 la cual corresponde a CMMI-SVC, liberada el 1 de noviembre de
2010. Hay tres constelaciones de la versión 1.2 disponible:
- CMMI para el Desarrollo (CMMI-DEV o CMMI
for Development), Versión 1.2 fue liberado en agosto de 2006. En él se
tratan procesos de desarrollo de productos y servicios.
- CMMI para la adquisición (CMMI-ACQ o CMMI
for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se
tratan la gestión de la cadena de suministro, adquisición y contratación
externa en los procesos del gobierno y la industria.
- CMMI para servicios (CMMI-SVC o CMMI for
Services), está diseñado para cubrir todas las actividades que requieren
gestionar, establecer y entregar Servicios.
Dentro de la constelación
CMMI-DEV, existen dos modelos:
- CMMI-DEV
- CMMI-DEV + IPPD (Integrated Product and
Process Development)
Independientemente de la
constelación\modelo que opta una organización, las prácticas CMMI deben
adaptarse a cada organización en función de sus objetivos de negocio.
Las organizaciones no pueden
ser certificadas CMMI. Por el contrario, una organización es evaluada (por
ejemplo, usando un método de evaluación como SCAMPI y recibe una calificación
de nivel 1-5 si sigue los niveles de Madurez (si bien se comienza con el nivel
2). En caso de que quiera la organización, puede coger áreas de proceso y en
vez de por niveles de madurez puede obtener los niveles de capacidad en cada
una de las Áreas de Proceso, obteniendo el "Perfil de Capacidad" de
la Organización.
Evaluación
(Appraisal)
Muchas organizaciones valoran
el medir su progreso llevando a cabo una evaluación (appraisal) y ganando una
clasificación del nivel de madurez o de un nivel de capacidad de logro. Este
tipo de evaluaciones son realizadas normalmente por una o más de las siguientes
razones:
- Para determinar que también los procesos de
la organización se comparan con las mejores prácticas CMMI y determinar
qué mejoras se pueden hacer.
- Para informar a los clientes externos y
proveedores acerca de que también los procesos de la organización se
comparan con las mejores prácticas CMMI.
- Para cumplir los requisitos contractuales
de uno o más clientes.
Las valoraciones de las
organizaciones utilizando un modelo CMMI deben ajustarse a los requisitos
definidos en el documento "Appraisal Requirements for CMMI" (ARC). La
evaluación se enfoca en identificar oportunidades de mejora, y comparar los
procesos de la organización con las mejores prácticas CMMI. Los equipos de
evaluación usan el modelo CMMI y un método conforme a ARC para guiar su
evaluación y reporte de conclusiones. Los resultados de la evaluación son
usados para planear mejoras en la organización. Hay tres clases de evaluación:
Clase A,B,C. El Standard CMMI Appraisal Method for Process Improvement (SCAMPI)
es un Método de evaluación que cumple todos los requerimientos ARC. Una
evaluación de clase A es más formal y es la única que puede resultar en una
clasificación de nivel.
El Standard CMMI Appraisal
Method for Process Improvement (SCAMPI) es el método oficial SEI para proveer
puntos de referencia de sistemas de calificación en relación con los modelos
CMMI. SCAMPI se usa para identificar fortalezas y debilidades de los procesos,
revelar riesgos de desarrollo/adquisición, y determinar niveles de capacidad y
madurez. Se utilizan ya sea como parte de un proceso o programa de mejoramiento,
o para la calificación de posibles proveedores. El método define el proceso de
evaluación constando de preparación; las actividades sobre el terreno;
observaciones preliminares, conclusiones y valoraciones; presentación de
informes y actividades de seguimiento.
4) Realice un
cuadro comparativo del CCMI y el ISO12007.
|
CMMI
|
ISO12007
|
|
El propósito del modelo es
evaluar la madurez de los procesos de una organización y proporcionar una
orientación referente a cómo mejorar los procesos que darán lugar a mejores
productos. Cuando se habla directamente con personas del Software Engineering
Institute, es posible que digan que CMMI es un modelo para la administración
de riesgos y que indica la capacidad de una organización para administrar los
riesgos.
|
Aquí el software es una parte esencial de sistemas convencionales y de
tecnologías de la información, tales como sistemas de transporte, militares,
médicos y financieros. Hay una proliferación de normas, procedimientos,
métodos, herramientas y entornos para desarrollar y gestionar software.
|
|
El modelo se ha diseñado para
que se use como base de las iniciativas enfocadas a mejorar los procesos y,
en el ámbito de la evaluación, únicamente como ayuda para medir las
mejoras.Este enfoque ha dado lugar a resultados mixtos.Resulta demasiado
fácil confundir el modelo con una definición de proceso e intentar seguirlo
en lugar de considerarlo como un mapa que identifica las lagunas en los
procesos existentes que habría que rellenar.
|
En la ISO/IEC 12207:1995 se
utiliza el termino “cumplimiento” en el apartado 1.4; sin embargo, de acuerdo
con la guía 2 ISO/IEC, Estandarizacion
y Actividades Relacionandas Vocabulario General, “conformidad” es el termino
apropiado para este apartado. La conformidad es el cumplimiento para un
producto, proceso o servicio de requerimientos especificados
|
CMMI
El modelo se ha diseñado
para que se use como base de las iniciativas enfocadas a mejorar los procesos
y, en el ámbito de la evaluación, únicamente como ayuda para medir las
mejoras.Este enfoque ha dado lugar a resultados mixtos.Resulta demasiado fácil
confundir el modelo con una definición de proceso e intentar seguirlo en lugar
de considerarlo como un mapa que identifica las lagunas en los procesos existentes
que habría que rellenar.
La conclusión de estos trabajos es
que resulta necesario complementar este modelo con otros que contengan los
aspectos mencionados. Los analistas coinciden en afirmar que el paradigma del
modelo se basa en una visión racional y mecanisista de las organizaciones. El
modelo CMM tiene como objetivo el logro de procesos óptimos repetibles en el
desarrollo de software. Esto implica un cambio en la forma de pensar y trabajar
en el trabajo diario de los desarrolladores. Por esta razón es necesario
incorporar en estos procesos aspectos de la cultura de la organización donde se
implementará, basados en la idea de que “la cultura de una organización
determina lo que se podrá y no se podrá realizar cuando se plantean cambios”.
ISO12007
Al igual que la CMMI, esta norma contiene 5 procesos a
los cuales debe cumplir para dar el servicio a las partes principales durante
el ciclo de vida del software. Una parte principal es aquella que inicia o
lleva a cabo el desarrollo, operación, o mantenimiento de los productos
software.
Estas partes principales son el adquiriente, el
proveedor, el desarrollador, el operador y el responsable de mantenimiento de
productos software. Los procesos principales son:
1.-
Proceso de adquisición: Define las actividades del adquiere un sistema, producto
software o servicio software.
2.-
Proceso de suministro: Define las actividades del proveedor, organización que
proporciona un sistema, producto software o servicio software al adquiriente.
3.-
proceso de desarrollo: Define las actividades del desarrollador, organización
que define y desarrolla el producto software.
4.-
Proceso de operación: Define las actividades del operador, organización que
proporciona el servicio de operar un sistema informático en su entorno real,
para sus usuarios.
5.-
Proceso de mantenimiento: Define las actividades del responsable de mantenimiento,
organización que proporciona el servicio de mantenimiento del producto
software; esto es, la gestión de las modificaciones al producto software para
mantenerlo, actualizado y operativo. Este proceso incluye la migración y
retirada del producto software.
5) ¿Qué normas
soportan al CCMI?
La Norma ISO que tiene la misma finalidad que el modelo CMMI
(evaluar la capacidad de los procesos de la organizacin para desarrollo y
mantenimiento de software, y servir de gua de mejora) es la ISO/IEC STD 15504.
Hasta hace un año
no era estandar (STD) estaba an como instrucciẳn tecnica (ISO/IEC TR 15504), y
anteriormente fue lo que se llamaba SPICE, que era el nombre con el que ISO
bautiz al proyecto del que surgio.
La norma equivalente es por tanto la "ISO 15504".
La norma equivalente es por tanto la "ISO 15504".
6) ¿Qué tiene
en Común CCMI y Six-Sigma?
CMMI y Seis
Sigma.
El Modelo Integrado de Madurez
y Capacidad (CMMI) y Seis Sigma aparecen cada vez con mayor frecuencia en las
mismas conversaciones.
Aunque
no comparten una herencia común (uno viene del mundo de la Ingeniería de
software y el otro del de la fabricación) comparten raíces comunes desde los
principios de Crosby, Deming y otros. Las organizaciones que se han esforzado
para aplicar ambos han gestionado, presupuestado y asignado recursos a las dos
iniciativas por separado. Esto condujo no sólo a una integración mínima de
ambas iniciativas, sino también a la competitividad entre ellas.
Investigaciones
recientes, sin embargo, han demostrado que estas iniciativas pueden ser
explotadas conjuntamente para acelerar su puesta en práctica y lograr el éxito
de la misión 2.
Seis
Sigma es un acercamiento holístico o global la mejora del negocio, que incluye
una filosofía, medidas de funcionamiento, marcos de mejora y un conjunto de
herramientas, todo concebido para complementar y para perfeccionar los procesos
de ingeniería, de servicio y de fabricación existentes. Debido a sus numerosas
dimensiones,
Seis
Sigma puede servir a la vez como un modelo de gobierno de la empresa y un motor
de mejora táctica 3.
Seis
Sigma se originó en la industria de la fabricación. Ofrece un modo claro de
identificar variaciones aceptables en la producción de materiales. También
podría asociarse con la identificación de la capacidad para medir la variación
o la tolerancia sobre el uso de ese producto o del funcionamiento real del
producto en sí. Así, Seis Sigma se convirtió en el motor de la calidad en
materia de fabricación. Aunque Seis Sigma no garantiza la calidad en sí,
proporciona expectativas sobre el funcionamiento de programas que pueden
relacionarse con la satisfacción del cliente, mejorando implícitamente la
calidad.
CMMI
es una aproximación integrada del desarrollo de procesos y productos. Durante
varios años se han desarrollado numerosos CMM (Capability Maturity Models). La
ingeniería del software, la ingeniería de sistemas, los equipos integrados, la
gestión de riesgos y la adquisición tenían cada uno su propio modelo. La industria
y el gobierno han colaborado para establecer un modelo dotado de una
terminología, de métodos de evaluación y de disciplinas comunes. CMMI, aunque
constituido por una colección de modelos múltiples, está estrechamente asociado
a los modelos de ingeniería de sistemas y de ingeniería del software. Por lo
tanto, ha sido adoptado primordialmente por organizaciones que desarrollan
software. El modelo no es preceptivo, pero constituye un conjunto de mejores
prácticas que, cuando son interpretadas en una organización específica,
implican un producto de calidad. Como para Seis Sigma, no hay ninguna garantía
de calidad, sino una expectativa de calidad del producto y su funcionamiento. No
hay duda que estas dos aproximaciones se centran en la calidad. Son metodologías
diferentes pero no disjuntas. Cuando están integradas, estas dos metodologías
pueden aportar muchas más ventajas para la organización que si fueran
utilizadas aisladamente.
7) En que es basado el desarrollo CMMI.
La guía definitiva del modelo
Capability Maturity Model Integration (CMMI) for Development está publicada por
el Instituto de ingeniería de software como "CMMI: Guidelines for Process
Integration and Product Improvement". Este libro describe específicamente
CMMI para Development (CMMI-DEV) version 1.2, que es uno de los modelos del
conjunto actual del producto CMMI cuando se escribió este tema.Este modelo es
muy estable y seguramente seguirá siendo el modelo de referencia mucho más allá
de 2010."CMMI Distilled: A Practical Introduction to Integrated Process
Improvement" también es un libro útil y accesible sobre este tema. El
modelo CMMI vio la luz en 1987 como Capability Maturity Model (CMM), un
proyecto del Software Engineering Institute, que es un centro de investigación
de la Universidad Carnegie-Mellon.Este centro lo fundó y lo financia el
Departamento de Defensa de los Estados Unidos.En 1991, se publicó por primera
vez el modelo CMM for Software, que está basado en una lista de comprobación de
los principales factores de éxito de los proyectos de desarrollo de software
realizados a finales de los años setenta y principios de los años ochenta.El
modelo también se fundamenta en las investigaciones realizadas por
International Business Machines (IBM) Corporation y por Philip Crosby y W.Edwards
Deming, destacados representantes del ámbito de control de calidad del siglo
XX.Tanto el nombre, Capability Maturity Model, como los cinco niveles de la
representación por etapas (que se abordará más adelante en este tema) están
inspirados en el modelo de madurez Manufacturing Maturity Model de
Crosby.Aplicado principalmente a programas de defensa, el modelo CMM ha logrado
una aceptación considerable y se ha sometido a varias revisiones e
iteraciones.Su éxito condujo al desarrollo de modelos CMM para diversos ámbitos
más allá del ámbito de software.La proliferación de nuevos modelos dio lugar a
confusión, por lo que el gobierno financió un proyecto de dos años en el que
participaban más de 200 expertos del mundo industrial y académico a fin de
crear un solo marco extensible para la ingeniería de sistemas, la ingeniería de
software y el desarrollo de productos. El resultado fue CMMI. El propósito del modelo es evaluar la madurez de
los procesos de una organización y proporcionar una orientación referente a cómo
mejorar los procesos que darán lugar a mejores productos. Cuando se habla
directamente con personas del Software Engineering Institute, es posible que
digan que CMMI es un modelo para la administración de riesgos y que indica la
capacidad de una organización para administrar los riesgos. Esta indicación es
un indicio de la probabilidad con la que una organización puede cumplir sus
promesas o proporcionar productos de alta calidad que sean atractivos para el
mercado. Otro enfoque es que el modelo proporciona un buen indicador de cómo
actuará una organización en situaciones de estrés. Una organización de gran
madurez y altas capacidades afrontará con calma las situaciones inesperadas y
de estrés, reaccionará, realizará cambios y seguirá adelante. Una organización
con un reducido nivel de madurez y pocas capacidades tenderá a dejarse llevar
por el pánico en situaciones de estrés, seguirá a ciegas los procedimientos
obviados, o bien, desbaratará todos los procesos y volverá al chaos. El modelo
CMMI no es un buen indicador del rendimiento económico de una organización.Si
bien las organizaciones de gran madurez pueden administrar mejor el riesgo y
ser más predecibles, está demostrada la aversión de estas organizaciones hacia
el riesgo. Esta aversión puede conducir a una falta de innovación o un mayor
grado de burocracia que da lugar a plazos de producción significativos y una
falta de competitividad. Las empresas con un reducido nivel de madurez suelen
ser más innovadoras y creativas pero caóticas e impredecibles.Cuando se logran
resultados, suelen ser el fruto del esfuerzo heroico de algunas personas
individuales.
8) Describa
los 5 niveles de madurez para clasificar a las organizaciones de acuerdo a CMMI.
Modelos
de madurez en CMMI
CMMI
propone 5 distintos modelos de madurez de las organizaciones:
- Inicial -
Estado inicial donde el desarrollo se basa en la heroicidad y
responsabilidad de los individuos.
- Los
procedimientos son inexistentes o localizados a áreas concretas.
- No existen
plantillas definidas a nivel corporativo.
- Gestionado -
Se normalizan las buenas prácticas en el desarrollo de proyectos (en base
a la experiencia y al método).
- En este nivel
consolidado, las buenas prácticas se mantienen en los momentos de estrés.
- Están
definidos los productos a realizar.
- Se definen
hitos para la revisión de los productos.
- Definido - La
organización entera participa en el proceso eficiente de proyecto
software.
- Se conoce de
antemano los procesos de construcción de software.
- Existen
métodos y plantillas bien definidas y documentados.
- Los procesos
no solo afectan a los equipos de desarrollo sino a toda la organización
relacionada.
- Los proyectos
se pueden definir cualitativamente.
- Cuantitativamente
Gestionado
- Se puede
seguir con indicadores numéricos (estadísticos) la evolución de los
proyectos.
- Las
estadísticas son almacenadas para aprovechar su aportación en siguientes
proyectos.
- Los proyectos
se pueden pedir cuantitativamente.
- Optimizado
- En base a
criterios cuantitativos se pueden determinar las desviaciones más comunes
y optimizar procesos.
- En los
siguientes proyectos se produce una reducción de costes gracias a la
anticipación de problemas y la continua revisión de procesos
conflictivos.
9) En liste y
describa los niveles definidos por CMMI para medir la capacidad de los
procesos.
La
adhesión a este principio se encuentra en el seno de los movimientos de calidad
de todo el mundo, como lo muestra la ISO/IEC
(International Organization for Standardization/International Electrotechnical
Comission) en su conjunto de estándares. Aunque estos modelos han probado
ser útiles para muchas organizaciones en el seno de diferentes industrias, el
uso de múltiples modelos ha sido problemático. Muchas organizaciones quisieran
extender sus esfuerzos de mejora a diversos grupos en sus organizaciones. Sin
embargo, las diferencias entre los modelos de disciplinas específicas
utilizados por cada grupo, incluyendo su arquitectura, contenido y
aproximación, han limitado las capacidades de estas organizaciones para
generalizar con éxito sus mejoras. Además, la aplicación de múltiples modelos
no integrados en y a través de una
organización es costosa en términos de formación, de evaluaciones y de
actividades de mejora. El proyecto de integración de CMM ha sido realizado
para regular el problema de utilizar múltiples CMM. La misión inicial del
equipo del producto CMMI (CMMI Product Team) fue combinar tres modelos
fuente:
1. SW-CMM (Capability Maturity Model for
Software), version v2.0 draft C [SEI 1997b]
2. SECM ( Systems Engineering Capability
Model) [EIA 1998]1
3. IPD-CMM (Integrated Product Development
Capability Maturity
Model),
version v0.98 [SEI 1997a]
La
combinación de estos modelos en un único marco de mejora fue pensada para
permitir a las organizaciones utilizar éste en su búsqueda de la mejora de
procesos en toda la empresa. Estos tres modelos fuente fueron seleccionados
debido a su extensa adopción por las comunidades de desarrollo de sistemas y de
software y también porque proponen diversos acercamientos a la mejora de procesos
en el seno de una organización. Apoyarse en estos modelos populares y
largamente apreciados ha permitido al equipo de producto del CMMI crear un
conjunto coherente de modelos integrados, que pueden adoptarse tanto por
aquellos que usan actualmente los modelos fuente como por aquellos nuevos al
concepto de CMM. Así, el CMMI resulta directamente de la evolución de los
modelos SW-CMM, SECM e IPD-CMM. Desarrollar un conjunto de modelos integrados
implicó más que una simple combinación de los modelos existentes. Utilizando
aquellos procesos que fomentan el consenso, el equipo de producto del CMMI
construyó una estructura que concilia múltiples disciplinas de manera lo
suficientemente flexible como para integrar las diversas aproximaciones de los
modelos fuente [Ahern 2003].
Desde
la publicación del CMMI v1.1, hemos visto que este marco de mejora se puede
aplicar a otros dominios de interés [SEI 2002a, SEI 2002b]. Para hacer esto, el
CMMI agrupa las mejores prácticas en lo que llamamos “constelaciones”. Una constelación es una colección de
componentes CMMI que se utilizan para construir los modelos, los materiales de
formación y los documentos de evaluación. Recientemente, la arquitectura de
los modelos CMMI fue mejorada para soportar múltiples constelaciones y
compartir las mejores prácticas entre las constelaciones y sus modelos miembro.
El trabajo ha comenzado sobre dos nuevas constelaciones: una para los servicios
(CMMI for Services) y la otra para
la adquisición (CMMI for Acquisition).
Aunque el CMMI for Development incorpora el desarrollo de los servicios,
incluyendo la combinación de componentes, consumibles y personas respondiendo a
las exigencias de los servicios que se centra explícitamente en la entrega de
servicios, a diferencia del CMMI for Services (CMMI-SVC). Los modelos del CMMI
disponibles en la comunidad antes de 2006 ahora se consideran parte de la
constelación CMMI for Development.
CMMI para el desarrollo
La
constelación del CMMI para desarrollo consiste en dos modelos:
CMMI para desarrollo + IPPD y CMMI
para desarrollo (sin IPPD). Ambos modelos comparten mucho de sus
materiales y son idénticos en las áreas compartidas. Sin embargo, CMMI para
desarrollo + IPPD contiene objetivos y prácticas adicionales que cubren IPPD.
Actualmente, se publica solamente un modelo, puesto que el CMMI para desarrollo
+ IPPD contiene el complemento completo de las prácticas disponibles para esta
constelación, y es posible Obtener el otro modelo (sin IPPD) de este material.
Si no está utilizando IPPD, no haga caso de la información marcada “adición
IPPD”, y así estará utilizando el modelo CMMI para desarrollo. Si surge la
necesidad o se amplía la constelación de desarrollo, la arquitectura permitirá
que se generen y publiquen otros modelos.El CMMI para desarrollo es el sucesor
designado de los tres modelos fuente. El SEI ha retirado Software CMM e
IPD-CMM. El EIA ha retirado el SECM. Los tres modelos son sustituidos por el
CMMI para desarrollo. Las mejores prácticas de los modelos CMMI han pasado por
un vasto proceso de revisión. El CMMI versión 0.2 fue revisado públicamente y
utilizado en actividades piloto. El equipo de producto del CMMI evaluó más de
3.000 peticiones de cambio para crear la versión 1.0 de CMMI. Poco después, se
lanzó la versión 1.02, incorporando varias mejoras de menor importancia. La
versión 1.1 incorporó mejoras sacadas de los retornos de experiencia de la
primera utilización, con más de 1.500 peticiones de cambio emitidas desde la
revisión pública, y de centenares de comentarios provenientes del proceso de
control de cambios. La versión 1.2 del CMMI ha sido desarrollada para responder
a casi 2.000 peticiones de cambio emitidas por los usuarios de CMMI. Más de 750
de esas peticiones fueron dirigidas al contenido del modelo CMMI. Como se puede
constatar, el CMMI no sólo está adoptado extensamente, sino que se mejora
gracias a la realimentación recibida de
la comunidad.
El
alcance del CMMI para el desarrollo
CMMI para desarrollo es un modelo de
referencia que cubre las actividades del desarrollo y del mantenimiento
aplicadas tanto a los productos como a los servicios.
Las organizaciones de numerosas industrias, incluyendo la aeroespacial, los
bancos, la construcción de ordenadores, el software, la defensa, la fabricación
del automóvil y las telecomunicaciones, utilizan el CMMI para desarrollo. Los
modelos de la constelación del CMMI para desarrollo contienen prácticas que
cubren la gestión de proyectos, la gestión de procesos, la ingeniería de
sistemas, la ingeniería del hardware, la ingeniería de software y otros
procesos de soporte utilizados en el desarrollo y el mantenimiento. El modelo
CMMI para desarrollo + IPPD cubre también la utilización de equipos integrados
que están implicados en las actividades de desarrollo y mantenimiento (IPPD).
El
grupo de adiciones IPPD
En
el CMMI, las “adiciones” sirven para
integrar el material específico que puede ser de interés a utilizadores
particulares. En la constelación del CMMI para desarrollo, se ha añadido
material para generar la integración del proceso y del desarrollo de producto
(IPPD). El grupo de adiciones IPPD cubre una aproximación que comprende las
prácticas que ayudan a las organizaciones a colaborar en tiempo útil con las
partes interesadas a lo largo de la vida del producto, para satisfacer las necesidades,
las expectativas y las exigencias de los clientes. Al utilizar los procesos que
se apoyan sobre una aproximación IPPD, se deberán integrar estos procesos con
los restantes procesos de la organización. Para dar soporte a aquellos que
utilizan procesos relativos a IPPD, la constelación CMMI para desarrollo
permite que las organizaciones seleccionen si así lo desean el grupo de
adiciones IPPD.
Cuando
se selecciona CMMI para desarrollo + IPPD, se seleccionará el modelo CMMI para
desarrollo más todas las adiciones de IPPD. Cuando se selecciona únicamente
CMMI para desarrollo, se seleccionará el modelo sin las adiciones IPPD. En el
texto de la primera parte de este libro emplearemos, por brevedad, el término
de “CMMI para desarrollo” para
referirnos a cualquiera de estos modelos.
Las diferentes aproximaciones de los CMM
La definición de un CMM permite que la
comunidad desarrolle modelos que soporten diversas aproximaciones a la mejora
de procesos. Con tal que un modelo contenga los
elementos esenciales de los procesos eficaces para una o más disciplinas y
describa una trayectoria evolutiva de mejora, permitiendo transformar desde
procesos ad hoc y no maduros a procesos disciplinados y maduros con calidad y
eficacia mejorada, se considera un CMM. El
CMMI le permite aproximarse a la mejora de procesos y a las evaluaciones usando
dos representaciones diferentes: continua y por etapas. La representación
continua permite a una organización seleccionar un área de proceso (o un grupo
de áreas de proceso) y mejorar los procesos relacionados con ésta. Esta
representación utiliza unos niveles de capacidad para caracterizar la mejora
concerniente a un área de proceso individual. La representación por etapas
utiliza conjuntos predefinidos de áreas de proceso para definir un camino de
mejora para una organización. Este camino de mejora se caracteriza por diversos
niveles de madurez. Cada nivel de madurez proporciona un conjunto de áreas de
proceso que caracterizan diferentes comportamientos organizativos.
Elegir
una representación
Si
es nuevo en la mejora de procesos y no está al corriente de la representación
por etapas o continua, no puede equivocarse si elige una representación o la
otra. Hay muchas razones válidas para seleccionar cualquier representación. Si
ha estado utilizando un CMM y está al corriente de una representación
particular, sugerimos que continúe utilizando esa representación porque ello
hará la transición a CMMI más fácil. Una vez que esté totalmente cómodo con
CMMI, podría entonces decidirse a utilizar la otra representación. Debido a que
cada representación tiene ventajas sobre la otra, algunas organizaciones
utilizan ambas representaciones para responder a unas necesidades particulares
en diferentes momentos de sus programas de mejora. En las secciones siguientes,
presentamos las ventajas y los inconvenientes de cada representación, para
ayudarle a decidir qué representación es la mejor para su organización.
La
representación continúa
La representación continua ofrece la
máxima flexibilidad cuando se utiliza un modelo CMMI para la mejora de
procesos. Una
organización puede elegir mejorar el rendimiento de un punto problemático
relacionado con un solo proceso, o puede trabajar en varios dominios que están
fuertemente alineados con sus objetivos estratégicos. La representación
continua también permite que una organización mejore diferentes procesos a
diferentes niveles. Las dependencias que existen entre algunas áreas de proceso
pueden, sin embargo, limitar un poco las elecciones. Si sabe de antemano qué
procesos necesitan ser mejorados en su organización y conoce las dependencias
existentes entre las áreas de proceso descritas en el CMMI, la representación
continua constituye entonces la elección pertinente.
La
representación por etapas
La representación por etapas ofrece
una manera sistemática y estructurada de aproximarse a la mejora de procesos
basada en el modelo etapa a etapa. El logro de
cada etapa asegura que una infraestructura de proceso adecuada se ha
establecido como fundamento para la etapa siguiente. Las áreas de proceso están
organizadas por niveles de madurez, los cuales eliminan interpretaciones a la
mejora de los procesos. La representación por etapas prescribe un orden para
implementar las áreas de proceso según unos niveles de madurez, que determinan
el camino seguido por una organización para pasar del nivel inicial al nivel
“en optimización”. Alcanzar cada nivel
de madurez asegura que se ha establecido un fundamento adecuado para el
siguiente nivel de madurez, lo que permite una mejora incremental y duradera. Si
no sabe por dónde comenzar ni qué procesos elegir para mejorar, la
representación por etapas es la opción designada. Esta ofrece un conjunto
específico de procesos para mejorar en cada etapa, conjunto que se ha
determinado a través de más de una década de investigación y de experimentación
sobre la mejora de procesos.
Comparación
de las representaciones continua y por etapas
La
Tabla 1.1 compara las ventajas de cada representación y puede ayudar a
determinar qué representación conviene a cada organización.
Factores
de decisión
Tres
categorías de factores que pueden influenciar su decisión al seleccionar una
representación son el negocio, la cultura, y la herencia.
Factores de negocio
Una organización con conocimiento
maduro de sus propios objetivos estratégicos es probable que tenga establecido
una correspondencia precisa entre estos y sus procesos.
Dicha organización puede encontrar la representación continua útil para evaluar
sus procesos y determinar si los procesos de la organización soportan y
satisfacen sus objetivos estratégicos de una manera adecuada. Una organización
guiada en base a línea de productos que decide mejorar sus procesos para toda
la organización, podría ser mejor servida por una representación por etapas. La
representación por etapas ayudará a una organización a seleccionar los procesos
capitales sobre los cuales concentrar la mejora. La misma organización puede
optar por mejorar procesos por línea de producto. En ese caso, sería preferible
que seleccionase la representación continua: se pueden alcanzar diferentes
valores de capacidad para cada línea de producto. Ambas aproximaciones son
válidas. La consideración más importante radica en los objetivos estratégicos
que se desea desarrollar en su programa de mejora de procesos y cómo estos
objetivos pueden alinearse con las dos representaciones.
Factores culturales
Los factores culturales a considerar
cuando se selecciona una representación están relacionados con la capacidad de
una organización para desplegar un programa de mejora de procesos.
Por ejemplo, una organización podría seleccionar la representación continua si
la cultura corporativa está orientada al proceso, está experimentada en la
mejora de procesos o posee un proceso específico que necesite ser mejorado
rápidamente. Una organización que tiene poca experiencia en la mejora de
procesos puede elegir la representación por etapas, la cual proporcionaría una
ayuda adicional sobre el orden en el cual se deben producir los cambios.
Herencia
Si una organización tiene experiencia
con otro modelo que tenga una representación por etapas, puede resultar
inteligente continuar con la representación por etapas al usar CMMI,
especialmente si se han invertido recursos y desplegado procesos a través de la
organización que están asociados con una representación por etapas.
Lo mismo es válido para la representación continua.
¿Por
qué no ambas representaciones?
Usadas
tanto para la mejora de procesos como para las evaluaciones, ambas
representaciones están diseñadas para ofrecer esencialmente resultados
equivalentes. Casi todo el contenido del modelo CMMI es común a ambas
representaciones. Por lo tanto, una organización no necesita seleccionar una
representación sobre otra. De hecho, una organización puede encontrar utilidad
en ambas representaciones. Es raro que una organización implemente una u otra
representación exactamente según lo prescrito. Las organizaciones que tienen
éxito en la mejora de procesos generalmente definen un plan de mejora que se
centra en las necesidades propias de esa organización y por lo tanto utilizan
los principios de ambas representaciones: por etapas y continua.
COMPONENTES DEL ÁREA DE PROCESO
Componentes
requeridos, esperados e informativos
Los
componentes del modelo se agrupan en tres categorías—requerido, esperado e
informativo— que indican cómo interpretarlos.
Componentes
requeridos
Los
componentes requeridos describen lo que una organización debe realizar para
satisfacer un área de proceso. Este logro se debe implementar de forma visible en
los procesos de una organización. Los componentes requeridos en CMMI son las
metas específicas y los objetivos genéricos. La satisfacción de objetivos se
utiliza en las evaluaciones como base para determinar si un área de proceso ha
sido realizada y satisfecha.
Componentes
esperados
Los componentes esperados describen lo
que una organización puede Implementar
para lograr un componente requerido. Los componentes esperados guían a los que
implementan mejoras o realizan evaluaciones.
Los
componentes esperados incluyen las prácticas específicas y las prácticas
genéricas. Antes de que los objetivos puedan considerarse satisfechos, las
prácticas tal como se describen o prácticas aceptables alternativas a ellas,
deberán estar presentes en los procesos planificados e implementados de la
organización.
Componentes
informativos
Los componentes informativos
proporcionan detalles que ayudan a las organizaciones a comenzar a pensar en
cómo aproximarse a los componentes requeridos y esperados.
Las sub-prácticas, los productos de trabajo típicos, las ampliaciones, las
elaboraciones de las prácticas genéricas, los títulos de metas y prácticas, las
notas de metas y prácticas, y las referencias son ejemplos de componentes
informativos del modelo. El glosario de términos del CMMI no es un componente
requerido ni esperado ni tampoco informativo de los modelos del CMMI. Usted
debería interpretar los términos del glosario en el contexto del componente del
modelo en el que aparecen.
Componentes
asociados con la Parte Dos
Los
componentes del modelo presentados en la Parte Dos, así como la relación entre
ellos, se pueden presentar en forma esquemática como se muestra en la Figura
2.1. Las siguientes secciones proporcionan descripciones detalladas de los
componentes del modelo.
Áreas
de proceso
Un área de proceso es un grupo de
prácticas relacionadas en un área que, cuando se
implementan de forma conjunta, satisfacen un grupo de objetivos considerados
importantes para la mejora en esta área. Hay 22 áreas de proceso, las cuales se
presentan aquí por orden alfabético de sus acrónimos en inglés.
•
Análisis causal y resolución (CAR).
• Gestión de configuración (CM).
• Análisis de decisiones y resolución
(DAR).
• Gestión integrada del proyecto +
IPPD (IPM + IPPD)1.
• Medición y análisis (MA).
• Innovación y despliegue en la
organización (OID).
•
Definición de procesos de la
organización + IPPD (OPD + IPPD)1.
• Enfoque en procesos de la
organización (OPF).
• Rendimiento del proceso de la
organización (OPP).
• Formación organizativa (OT).
• Integración de producto (PI).
• Monitorización y control del
proyecto (PMC).
• Planificación de proyecto (PP).
• Aseguramiento de la calidad de
proceso y de producto (PPQA).
• Gestión cuantitativa de proyecto
(QPM).
• Desarrollo de requerimientos (RD).
• Gestión de requerimientos (REQM).
• Gestión de riesgos (RSKM).
• Gestión de acuerdos con proveedores
(SAM).
• Solución técnica (TS).
• Validación (VAL).
• Verificación (VER).
Declaraciones
de propósitos
La “declaración de propósitos”
describe la finalidad del área de proceso y es un componente informativo. Por
ejemplo, la declaración de propósitos del área de proceso Definición de
procesos de la organización es “El propósito de la Definición de procesos de la
organización (OPD) es establecer y mantener un conjunto utilizable de activos
de proceso de la organización y de estándares del entorno de trabajo”.
Áreas
de proceso relacionadas
La sección de “áreas de proceso
relacionadas” lista las referencias a áreas de proceso que están en relación y
refleja las relaciones de alto nivel entre las áreas de proceso.
Es un componente informativo. Un ejemplo de una referencia encontrada en la
sección de áreas de proceso relacionadas del área de proceso de Planificación
de proyecto es “Para más información sobre la identificación y la gestión de
riesgos, se remite al área de proceso de Gestión de riesgos”.
Metas
específicas
Una meta específica describe las
características únicas que deben estar presentes para satisfacer el área de
proceso. Una meta específica es un componente
requerido del modelo que se utiliza en las evaluaciones para ayudar a
determinar si se satisface un área de proceso. Por ejemplo, una meta específica
del área de proceso Gestión de configuración es “Se establece y se mantiene la
integridad de las líneas base”. Solamente es un componente requerido del modelo
la declaración de meta específica. El título de una meta específica (precedido
por el número del objetivo) y todas las notas asociadas a la meta se consideran
componentes informativos del modelo.
Metas
genéricas
Las metas genéricas se denominan
“genéricas” porque la misma declaración de la meta se aplica a múltiples áreas
de proceso. Una meta genérica describe las características que deben estar presentes
para institucionalizar los procesos que implementan un área de proceso. Una
meta genérica es un componente requerido del modelo y se utiliza en las
evaluaciones para determinar si se satisface un área de proceso. (Para una
descripción más detallada de los objetivos genéricos se remite a la sección
“Metas genéricas y prácticas genéricas”.
Resúmenes de Metas específicas y prácticas específicas
El resumen de metas
específicas y prácticas específicas proporciona un resumen de alto nivel de las
metas específicas, que son componentes requeridos, y de las prácticas
específicas, que son componentes esperados.
El resumen de metas específicas y prácticas específicas es un componente
informativo.
Prácticas específicas
Una práctica específica es
la descripción de una actividad que se considera importante para alcanzar la
meta específica asociada. Las prácticas específicas describen las actividades que se espera que
produzcan la consecución de las metas específicas de un área de proceso.
Una práctica específica es un componente esperado del modelo. Un ejemplo de una
práctica específica del área de proceso de Monitorización y control de proyecto
es “Monitorizar los compromisos contraídos frente a los identificados en el
plan del proyecto”. Solamente es un componente esperado del modelo la
declaración de la práctica específica. El título de la práctica específica
(precedido por el número de la práctica) y todas las notas asociadas con la
práctica específica se consideran componentes informativos del modelo.
Productos de trabajo típicos
La sección de “productos
de trabajo típicos” lista muestras de resultados de una práctica específica.
Estos ejemplos se denominan productos de trabajo típicos porque a menudo hay
otros productos de trabajo que son igual de eficaces pero no están en la lista. Un producto de trabajo típico es un componente informativo del
modelo. Por ejemplo, un producto de trabajo típico de la práctica específica
“Monitorizar los valores reales de los parámetros de planificación del proyecto
frente al plan del proyecto” en el área de proceso de Monitorización y control
de proyecto es “Registros de desviaciones significativas”.
Subprácticas
Una subpráctica es una
descripción detallada que proporciona una guía para interpretar e implantar una
práctica específica o genérica. Las
subprácticas pueden tomar un carácter prescriptivo, pero realmente son un
componente informativo indicado sólo para proporcionar ideas que puedan ser
útiles para la mejora de proceso. Por ejemplo, una subpráctica de la práctica
específica “Realizar acciones correctivas para los problemas identificados” en
el área de proceso de Monitorización y control de proyecto es “Determinar y
documentar las acciones apropiadas necesarias para tratar los problemas
identificados”.
Prácticas
genéricas
Las prácticas genéricas se denominan
“genéricas” porque la misma práctica se aplica a múltiples áreas de proceso.
Una práctica genérica es la descripción de una actividad que se considera
importante para el logro de la meta genérica asociada. Una práctica genérica es
un componente esperado del modelo. Por ejemplo, una práctica genérica de la
meta genérica “El proceso se institucionaliza como un proceso gestionado” es
“Proporcionar recursos adecuados para llevar a cabo el proceso, para
desarrollar los productos de trabajo y para proporcionar los servicios del
proceso”.
Elaboraciones
de las prácticas genéricas
Una elaboración de práctica genérica
aparece después de una práctica genérica en un área de proceso, para
proporcionar una guía sobre cómo la práctica genérica debería aplicarse de
forma exclusiva al área de proceso. Una elaboración
de práctica genérica es un componente informativo del modelo. Por ejemplo, una
elaboración de la práctica genérica después de la práctica genérica “Establecer
y mantener una política organizativa para planificar y ejecutar el proceso de
planificación del proyecto” en el área de proceso de Planificación de proyecto
es “Esta política establece expectativas de la organización para estimar los
parámetros de planificación, para hacer compromisos externos e internos y para
desarrollar el plan de gestión del proyecto”.
Componentes
informativos de soporte
En
muchos sitios, se necesita más información para describir un concepto.
Este
material informativo se presenta como uno de los siguientes componentes:
•
Notas
•
Ejemplos
•
Ampliaciones
•
Referencias
Ejemplos
Un
ejemplo es un componente que comprende texto y, a menudo, una lista de
elementos, por lo general en una caja, que puede acompañar a casi cualquier
otro componente y proporciona uno o más ejemplos para clarificar un concepto o
una actividad descrita. Un ejemplo es un
componente informativo del modelo. El siguiente es un ejemplo que acompaña
a la sub-práctica “Documentar las no conformidades cuando no se pueden resolver
dentro del proyecto” bajo la práctica específica “Comunicar problemas de
calidad y asegurar la resolución de las no conformidades con el personal y
gerentes” en el área de proceso de Aseguramiento de la calidad de proceso y de
producto.
Ampliaciones
Una ampliación es una nota o un
ejemplo que es relevante para una disciplina particular.
Las disciplinas cubiertas en este modelo son ingeniería del hardware,
ingeniería de sistemas e ingeniería del software. Cada ampliación se etiqueta
con una cabecera que indica la disciplina a la que se aplica. Por ejemplo, una
ampliación para ingeniería del software se etiqueta “Para ingeniería del software”. Una ampliaciónes un
componente informativo del modelo. Un ejemplo de una ampliación es la que
acompaña a la práctica específica “Establecer y mantener el contenido general
del plan del proyecto” del área de proceso de Planificación de proyecto. La
ampliación establece “Para ingeniería del hardware: Para hardware, el documento
de planificación a menudo se denomina plan de desarrollo de Ejemplos de formas
para resolver las no conformidades dentro del proyecto incluyen los siguientes:
•
Corregir la no conformidad.
•
Cambiar las descripciones del proceso, los estándares o los procedimientos que
fueron infringidos.
•
Obtener una dispensa para cubrir la cuestión de no conformidad.
Esquema
de numeración
Las metas específicas y genéricas se
numeran secuencialmente. Cada meta específica empieza con el prefijo SG (p. ej.
SG 1). Cada meta genérica empieza con el prefijo GG
(p. ej. GG 2). Cada práctica específica empieza con el prefijo SP, seguido por
un número en la forma x.y (p. ej. SP 1.1). La x es el mismo número de la meta a
la que pertenece la práctica específica. La y es el número de secuencia de la
práctica específica para la meta específica correspondiente. Un ejemplo de
numeración de práctica específica está en el área de proceso de Planificación
de proyecto. La numeración de la primera práctica específica es SP 1.1 y la
segunda SP 1.2. Cada práctica genérica empieza con el prefijo GP, seguido por
un número en la forma x.y (p.ej. GP 1.1). La x corresponde al número de la meta
genérica. La y es el número de secuencia de la práctica genérica para la meta
genérica correspondiente. Por ejemplo, la primera práctica genérica asociada
con GG 2 se numera GP 2.1 y la segunda GP 2.2.
Convenciones
tipográficas
Las convenciones tipográficas
utilizadas en este modelo se han diseñado para permitirle seleccionar lo que
usted necesita y utilizarlo de forma efectiva.
Presentamos los componentes del modelo en formatos que le permitan encontrarlos
rápidamente en la página. Las Figuras 2.2 a 2.4 son páginas de ejemplo traídas
de las áreas de proceso de la Parte Dos; en ellas se muestran los distintos
componen Representación – Contenido específico. En la Parte Dos, notará
que algunos componentes en la sección de prácticas y objetivos genéricos de
cada área de proceso están sombreados y etiquetados “Sólo por etapas”, “Sólo
continua” o “Continua/Niveles de madurez 3-5”. A veces, estas etiquetas están
abreviadas, en función del espacio disponible. Los componentes que no están
marcados se aplican a las dos representaciones. Los componentes marcados “Sólo
por etapas” se aplican sólo si se utiliza la representación por etapas. Los
componentes marcados “Sólo continua” se aplican sólo si se utiliza la
representación continua (véase la Figura 2.4 como ejemplo). Los componentes
marcados “Continuo/Niveles de madurez 3-5” se aplican si está utilizando la
representación continua o si está utilizando la representación por etapas y
está persiguiendo los niveles de madurez 3, 4 ó 5. Sin embargo, estos
componentes no se aplican si está persiguiendo el nivel de madurez 2 de la
representación por etapas.
Extensiones
Una extensión puede ser un material
informativo, una práctica específica, una meta específica o un área de proceso
que amplía el alcance de un modelo o hace hincapié en un aspecto particular de
su utilización. En este documento, todas las
adiciones se aplican a IPPD. Un ejemplo de una adición es la que concierne al
área de proceso “Formación organizativa” que aparece después de la meta
específica 1, “Establecer una capacidad de formación de la organización”. La
extensión establece que “los miembros de un equipo integrado necesitan una
formación inter funcional, una formación en liderazgo, una formación en
habilidades interpersonales y una formación en las habilidades necesarias para
integrar apropiadamente las funciones de negocio y las funciones técnicas.
Comentarios
Publicar un comentario