CMMI Modelo de Capacidad de Madurez Integrado

Bienvenidos al curso de introduccin a CMMI, o Modelo de Capacidad de Madurez Integrado, cuya definicin veremos a
continuacin.
Este curso tiene el objetivo de presentar la estructura del modelo de CMMI de manera que la audiencia comprenda su importancia
y tenga el conocimiento necesario para aplicarlo entendiendo sus conceptos, estructuras y prcticas. Adems de conocer los
productos que le permitirn cubrir cada una de estas prcticas para mejorar el nivel de calidad de los procesos y productos de un
proyecto.
El modelo CMM-Capability Maturity Model (antecesor del CMMI) o Modelo de Capacidad de Madurez, surgi como respuesta a una
iniciativa de la fuerza area de Estados Unidos, que estaba ya frustrada con su proceso de adquisicin de software en los 80s. La
universidad de Carnegie Mellon gan la propuesta en 1984 para crear y operar una organizacin de investigacin y desarrollo con
fondos federales. Esta organizacin: el Instituto de Ingeniera de Software (SEI por sus siglas Software Engineering Institute) cre un
modelo que contena un compendio de best practices o mejores prcticas, recomendadas para asegurar proyectos exitosos, el
cual pudieran utilizar para realizar evaluaciones objetivas de sus proveedores de software y que fue publicado en 1989.
Posteriormente el modelo de CMM evolucion al modelo de CMMI, actualmente en su versin 1.2
Agenda:

Los temas que se cubrirn son: definicin de CMMI, cuales son los sntomas que nos indican que es necesario implementar el
modelo.
Los diferentes modelos; sus representaciones y estructura que consiste de niveles de madurez, reas de proceso o PAs, objetivos
especficos, objetivos genricos, prcticas genricas, algunos ejemplos de la aplicacin de las prcticas genricas, prcticas y
productos con las cuales la metodologa de Softtek cubre las reas de proceso del modelo y los beneficios de implementarlo.
Este material revisar el modelo de CMMI en su versin 1.2 para permitir a la audiencia entenderlo, as como sus conceptos y
prcticas de forma que puedan visualizar el nivel de CMMI de sus proyectos, lo que permitir al estudiante identificar reas de
oportunidad e implementar las recomendaciones y prcticas adecuadas disminuyendo as el nivel de riesgo de un proyecto.
Aqui tenemos algunos conceptos que es conveniente presentar para unificar criterios al revisar el material de este curso.
Stakeholder Es todo aquel individuo o grupo de individuos que de alguna forma son afectados por, o depende el resultado de un
proyecto o una tarea.
Verificacin Confirma que los productos de trabajo reflejan de manera apropiada los requerimientos especificados para ellos, la
verificacin se asegura de que lo hicimos correctamente. Un ejemplo de verificacin son los Peer Reviews ( que es cuando una
prctica donde una persona ajena al autor revisa un entregable para detectar defectos).
Validacin Confirma que el producto, al momento de entrega, va a satisfacer su intencin de uso. En otras palabras se asegura de
que hicimos lo correcto. Es decir que entendimos bien los requerimientos y estamos ofreciendo lo que el cliente espera.
Goal Significa Objetivo, y es un componente requerido a cubrir por CMMI que puede ser genrico o especfico.
IPPD Por sus siglas en ingls referentes a: Integrated Product and Process Development y se refiere a un enfoque sistemtico
aplicado en el desarrollo de productos, el cual consiste en aplicar las disciplinas necesarias durante el ciclo de vida del proyecto para
aumentar el nivel de satisfaccin del cliente.
Que significa CMMI
- Las siglas CMMI significan Capability Maturity Model Integration o Integracin de CMM. Que es el modelo de Capacidad de
Madurez. Y es el resultado de integrar varios Modelos de CMM, como el de Software Engineering y el de Integrated Product
Development.
Para algunas organizaciones era difcil implementar ms de un modelo de CMM a la vez, ya que entre ellos difieren un poco en su
estructura y el integrarlos facilit esta tarea.
- CMMI es un modelo que describe las prcticas de desarrollo de software que son reconocidas como crticas para el xito de los
esfuerzos de desarrollo de software dentro de organizaciones con las mejores prcticas.
- CMMI describe que actividades son necesarias para el xito. (es descriptivo)
- CMMI no describe como se deben realizar las actividades. (no es prescriptivo)
- El enfoque de la versin 1.2 est en mejorar la calidad de los productos de CMMi y la consistencia en como son aplicados.
Esto permite a las organizaciones definir la forma en que implementarn cada una de las prcticas y definir un estndar. En el caso
de Softtek, la herramienta estndar para implementar las evidencias de la mayora de las prcticas es PPM ITG (IT Governance
Center). Que es un sistema en el que estn definidos los flujos de la mayora de los procesos de Softtek de manera que siempre se
siga el mismo proceso, por ejemplo para registrar juntas, o los requerimientos de los clientes.
Porque implementar CMMI?
Las razones para implementar CMMI son muy variadas y pueden ir desde el querer tener la certificacin porque es requisito de
nuestros clientes, hasta querer mejorar y garantizar la calidad de los productos que estamos entregando. Adems existen algunos
sntomas que pueden ser indicativos de la necesidad de implementar algunas prcticas del modelo CMMI para minimizar el riesgo de
fracaso de los proyectos:
-Cuando no se cumplen los compromisos, es decir que no se estn haciendo entregas a tiempo, la gente tiene que trabajar horas
extras de ltimo momento, los costos estn fluctuando mucho.
-Cuando no hay una adecuada visibilidad en la administracin de un proyecto.
-Continuamente aparecen sorpresas o sucesos inesperados a los que hay que darle solucin.
-Cuando hay problemas de calidad y se est invirtiendo mucho tiempo en re trabajos, o hay quejas por parte del cliente.
-Cuando hay una moral baja, la gente est frustrada y no hay un control adecuado de la gente.
El que se presente algunos de estos sntomas no quiere decir que se debern implementar las prcticas de CMMI, pero s es una
herramienta adecuada si se busca una mejora.
Modelo CMMI
Modelo Constelacin
Los componentes del modelo de CMMi en su versin 1.2 estn organizados en 3 grupos llamados constelaciones; las cuales facilitan
la construccin de modelos aprobados.
Estas 3 constelaciones son:
CMMI-DEV CMMi para desarrollo que proporciona la gua para medir, monitorear, y administrar los procesos de desarrollo.
CMMI-SVC - CMMi para servicios que proporciona la gua para aquellos que prestan servicios dentro de las mismas organizaciones y
a clientes externos.
CMMi-ACQ CMMi para adquisiciones, proporciona una gua para permitir un liderazgo de adquisiciones informado y decisivo.
Estas tres constelaciones conforman el marco de trabajo de CMMi v1.2. y las 3 comparten 16 reas de proceso (que sern
presentadas ms adelante).
Representacin del Modelo
Existen dos maneras de implementar el modelo de CMMI: la representacin continua y la representacin por etapas o niveles.
-La representacin continua est orientada a un enfoque de mejora en la capacidad de las reas de proceso o PAs (que explicaremos
ms adelante). Es decir que se utiliza cuando una organizacin quiere enfocar su esfuerzo en un rea especfica en la cual ha
detectado que tiene oportunidades de mejora, sin importarle obtener un nivel de madurez general.
-La representacin por etapas est diseada de manera que apoye el enfoque de mejoras de madurez organizacional. Es decir que
se definen 5 niveles de madurez en los que estn distribuidas las reas de proceso. Estos niveles van dando gua a las mejoras de
procesos.
Softtek como organizacin ha implementado el modelo de niveles el cual estaremos presentando durante este curso.
Slo como observacin, existe un set de 16 reas de proceso que estn compartidas entre las tres constelaciones, las cuales sern
explicadas ampliamente ms adelante.



CMMI Structure
Pasamos a la estructura de CMMI.
En esta grfica podemos observar los dos tipos de estructura que se explicaron en el slide anterior. La representacin por ni veles,
etapas o Staged y Continuous.
En la estructura por etapas o niveles existen 5 niveles de madurez, en donde cada nivel tiene sus propias reas de proceso o PAs
(Process areas), y slo se alcanza cuando se cubren en su totalidad sus reas de proceso.
Como podemos ver en el diagrama, un rea de proceso tiene objetivos especficos o specific goals que identificaremos como SG y
objetivos genricos o generic goals que identificaremos como GG, los objetivos especficos tienen prcticas que indican de manera
particular cuales actividades se deben realizar para cumplir cada objetivo. Los objetivos genricos estn agrupados de manera
diferente. Cada objetivo genrico consta prcticas genricas que sirven de apoyo a las prcticas especficas.
A continuacin nos vamos a enfocar en analizar los niveles de madurez y cada una de sus reas de proceso. Ms adelante se
revisarn los objetivos especficos y genricos.


Qu son los niveles de madurez?
Por definicin el nivel de madurez es una plataforma de evolucin definida para los procesos de mejora.
En cada nivel de madurez se estabiliza una parte importante de los procesos de la organizacin.
Los 5 niveles de madurez estn numerados del 1 al 5. No existe el nivel 0.
Como se mencion anteriormente, cada nivel de madurez est compuesto de un grupo predefinido de reas de Proceso o Pas.
En la tabla se pueden observar los 5 niveles y la palabra que mejor los describe por el grado de madurez que representa cada uno.
- Inicial
- Administrado
- Definido
- Administrado cuantitativamente
- Optimizado

A continuacin vamos a revisar cada uno de los niveles de CMMI y sus principales caractersticas de manera grfica para faci litar su
comprensin.
El nivel 1 que se identifica como el INICIAL. Es el punto de partida para utilizar un nuevo proceso. El primer nivel podemos
visualizarlo como una especie de actividad que slo tiene un inicio y un final.
Cuando una organizacin (o proyecto) se encuentra en nivel 1, significa que no cuenta con un ambiente estable y que el xito o
fracaso depender bsicamente de la competencia y capacidad de la gente en la organizacin, ms no en el uso de procesos que ya
estn probados; y aunque las organizaciones de nivel 1 pueden generar productos y servicios que si satisfagan al cliente,
generalmente exceden su presupuesto o rebasan el tiempo en sus proyectos; es muy difcil que puedan repetir los xitos pasados
porque no tienen una base para saber cuales fueron las actividades que les llevaron a ese xito.
El nivel 2 se caracteriza por tener procesos ADMINISTRADOS. Bsicamente es cuando un proceso es utilizado repetidamente. En el
diagrama podemos ver que consta de varias fases a las cuales se les da seguimiento.
En este nivel, las organizaciones se aseguran de que sus requerimientos, procesos, entregables y todos los servicios sean
documentados, y ya se cuenta con planes de trabajo a los que se les da seguimiento y que son medidos y controlados. Es decir que al
menos se tienen bien definidas y planeadas las actividades que se realizarn.


El nivel 3 se caracteriza por ser DEFINIDO. Se cuenta con un proceso definido como el proceso estndar de la organizacin. Como
pueden ver en el diagrama, el mismo proceso es utilizado de manera consistente.
Aqu los procesos estn bien caracterizados o comprendidos. Ya se cuenta con estndares, procedimientos, herramientas, y
mtodos.
Los procesos estndar que existen en el nivel 3 nos permiten que haya una consistencia en la organizacin y que los proyectos que
se generen tomen como base estos procedimientos, para despus aplicarle lo que se llama tailoring o ajuste de acuerdo a las
necesidades particulares de cada proyecto, observando algunos lineamientos ya definidos.
En el caso de Softtek, se tienen metodologas definidas para los distintos tipos de proyectos (AMS, Testing y Desarrollo entre otras)
que se toman como base para despus aplicarle los ajustes necesarios de acuerdo a las restricciones, caractersticas y limitaciones
de cada cliente o proyecto.
La principal diferencia que existe entre nivel 2 y nivel 3, es que en el nivel 2 los estndares, las descripciones de los procesos y los
procedimientos pueden ser muy diferentes entre un proyecto y otro porque no tienen el mismo origen. En el nivel 3 estamos
partiendo de una metodologa estndar.


En el nivel 4, se caracteriza por ser cuantitativamente administrado, adems de las mediciones, se tiene un proceso de
administracin y control adicional.
En el diagrama se observa como los resultados son comparados con las metas establecidas.
Se selecciona un grupo de procesos o subprocesos de los cuales depende en gran parte el desempeo de un proyecto y se trata de
controlarlos utilizando tcnicas estadsticas. Aqu se definen objetivos cuantitativos para la calidad y el desempeo de los procesos
de acuerdo a las necesidades del cliente y la organizacin.
Ser nivel 4 implica que para estos procesos, se va a recolectar y analizar informacin de manera estadstica, as que se real izan
mediciones de desempeo o performance y cuando se detecta que hay una inconsistencia o brecha entre los objetivos establecidos
y los resultados, se definirn las causas que las estn generando y se implementarn acciones correctivas para que esto ya no
suceda. Todas estas mtricas que se estn analizando van a estar incorporadas en un repositorio de la organizacin lo cual nos va a
servir de base para tomar futuras decisiones.
La diferencia principal entre el nivel 3 y el nivel 4 - porque en el nivel 3 tambin se toman mediciones - es que en el nivel 4 el proceso
est siendo controlado y es predecible de manera cuantitativa.

Finalmente el nivel 5 es el nivel caracterizado por la optimizacin. La administracin de procesos incluye la optimizacin y mejora
deliberada de procesos. El diagrama representa una parte de un proceso que ha sido optimizado. Aunque no debe entenderse por
optimizacin el reducir actividades, en algunos casos el incluir un nuevo control en el proceso generar una mejora.
En este nivel, los procesos son mejorados continuamente tomando como base una comprensin cuantitativa de las causas de
variacin ms comunes que existen. Es decir, que aqu habr un enfoque en el proceso que se tiene y su desviacin. Se establecen
objetivos de mejora de procesos cuantitativos y una vez que se definen las mejoras, son analizadas y evaluadas para saber que
efectos han tenido al implementar estos cambios.
La diferencia entre el nivel 4 y 5, es que en el nivel 4 buscamos causas especiales de variaciones que hay en los procesos, aunque se
pueden predecir los resultados, estos pueden no ayudarnos a alcanzar los objetivos cuantitativos que nos estamos planteando. Ya
en el nivel 5 se buscan las causas comunes para las variaciones para poder cambiar el proceso, mejorar el desempeo y as alcanzar
los objetivos.
A fin de cuentas cada uno de estos niveles de CMMI nos va proporcionando la base del siguiente nivel.
Repasando: en el nivel 1, no tenemos un plan definido. En el 2 ya estamos haciendo una planeacin. En el nivel 3 ya tenemos un
proceso definido a nivel organizacin y a partir de ah generamos la planeacin de los proyectos. En el nivel 4 estamos tomando
mediciones tratando de controlar el proceso y una vez que est controlado el proceso, en el nivel 5 nos vamos a enfocar en
optimizarlo.

Proceso Areas
Las reas de proceso identifican un grupo de actividades relacionadas que cuando son realizadas de manera colectiva, logran un
grupo de objetivos que son considerados importantes.
Todas las reas de proceso de CMMI estn presentes tanto en la representacin continua como la representacin por niveles o
etapas. En la representacin por niveles, las reas de proceso estn organizadas o agrupadas en niveles de madurez.
Es importante observar que para que un proyecto u organizacin alcance un nivel especfico debe cumplir con todas las PAs de ese
nivel. Es decir, que si un proyecto falla en alguna prctica de un PA de nivel 3, el nivel que corresponde a ese proyecto es 2, porque
es el nico que cubre en su totalidad (aunque quizs tenga las prcticas necesarias para cubrir totalmente el nivel 4).

Comenzaremos por conocer las reas de proceso de cada uno de los niveles de madurez. Los niveles que tienen ms PAs son el 2 y 3.
En el nivel 2 se tienen 7 reas de proceso:
Requirements management o administracin de requerimientos
Project Planning que es planeacin de proyectos
Project monitoring and control monitoreo y control de proyectos
Process and Product Quality Assurance aseguramiento de calidad de procesos y productos
Configuration management administracin de la configuracin
Measurement and Anlisis - Medicin y anlisis
Como se puede observar, todas estas reas estn relacionadas con la planeacin en las fases iniciales del proyecto y el seguimiento a
estos planes. Ms adelante se revisarn cada una de las PAs por separado.
En el nivel 3, que es el ms extenso se tienen 11 reas de proceso:
Organizational Process Focus Enfoque en proceso organizacional
Organizational Process Definition Definicin de Proceso organizacional
Organizational Training Entrenamiento organizacional
Integrated Project Management Administracin integrada de proyecto
Risk Management Administracin de riesgos
Requirements development Desarrollo de requerimientos
Technical Solution Solucin tcnica
Product Integration Integracin de producto
Validation - Validacin
Verification - Verificacin
Decision Analysis and Resolution Anlisis de decisiones y resolucin
En general, la mayora de estos PAs estn relacionados con el diseo, desarrollo e implementacin de los entregables; adems de la
administracin de riesgos y de la toma de decisiones.

El nivel 4 de CMMI consta solamente de 2 PAs.
Quantitative Project Management (que si recuerdan es prcticamente como se le identifica a este nivel).
Organizacional Process Performance.
El nivel 4 se apoya de PAs que permiten evaluar el desempeo de los proyectos y el proceso organizacional.
En el nivel 5 se encuentran las ltimas 2 Pas:
Cause Analysis and Resolution
Organizational Innovation and Deployment
A continuacin veremos la definicin de los Objetivos Especficos o Specific Goals para comenzar a analizarlos dentro de cada una de
sus respectivas Pas.

Los objetivos especficos se aplican solamente a un rea de proceso y mencionan las caractersticas nicas que describen lo que
debe implementarse para satisfacer el propsito del rea de proceso; en otras palabras, un objetivo especfico representa un grupo
de prcticas de implementacin.
Un rea de proceso puede tener hasta 3 objetivos especficos.

Las actividades especficas o SPs, son el componente importante para lograr el objetivo especfico al que estn asociadas.
Adems describen las actividades que se espera den como resultado el alcanzar un objetivo especfico de un rea de proceso o PA.
A continuacin veremos un ejemplo de una PA, con su objetivo especfico y sus actividades especficas.

Para este PA que es Requirements Management, se tiene solamente un Objetivo Especfico que es Administrar los requerimientos;
y este a su vez tiene 5 actividades especficas, es decir que para cumplir con el objetivo y por lo tanto con el rea de Proceso se
necesita cubrir lo siguiente:
-Obtener un entendimiento de los requerimientos
-Obtener un compromiso a los requerimientos
-Administrar los cambios a los requerimientos
-Mantener una trazabilidad bidireccional de los requerimientos
-Identificar inconsistencias entre el trabajo del proyecto y los requerimientos
Cmo podemos traducir esto a la operacin en nuestros proyectos y organizacin?
PPM ITG nos permite llevar este seguimiento y cubrir con el PA de administracin de requerimientos, ya que tenemos un anlisis del
requerimiento que se nos est solicitando, se realiza una estimacin para definir una fecha o esfuerzo compromiso, no permite
documentar cualquier cambio de alcance de un requerimiento, podemos registrar cuales son los componentes afectados y luego
analizar la informacin almacenada para detectar desviaciones entre lo estimado y lo real y generar mtricas.
Debido a que el tiempo para este curso es limitado, no se presentarn todas las prcticas especficas de cada uno de los PAs, pero si
se pretende dejar clara la relacin de estas prcticas con sus objetivos especficos y su importancia.
Adems como nota adicional, cada prctica especfica consta a su vez de sub-prcticas que detallan todava ms las actividades que
deben realizarse.
En las siguientes filminas se presentarn las reas de Proceso con sus Objetivos Especficos y la descripcin de cada una de ellas,
como nota explicativa se intentar hacer una referencia a las prcticas que se realizan en Softtek y que cubren dichos objetivos.

La PA de Administracin de Requerimientos (REQM) ya fue explicada.
Para la PA de Project Planning se tienen 3 objetivos especficos:
Establecer estimados, donde se establecen y mantienen los parmetros de la planeacin de proyectos que fueron definidos..
Desarrollar un plan de trabajo Se establece y mantiene un plan de proyecto como base para administrar el proyecto.
Obtener compromiso al plan Se establecen y mantienen los compromisos para el plan de proyecto.
Ejemplos de productos que cubren este PA, son: la herramienta de estimacin, el plan de trabajo digitalizado en PPM workbench, el
PDP (o Project Develpment Plan que es un documento que se genera en la fase inicial de los proyectos) donde se definen e
identifican actividades, entregables, estimaciones, recursos para el proyecto y habilidades necesarias, ciclo de vida y riesgos entre
otras cosas.

La PA de Project Monitoring and Control consta de dos objetivos especficos:
Monitorear el proyecto contra el plan
Administrar actividades correctivas hasta su conclusin.

Como su nombre lo dice, para cubrir esta PA necesitamos no solamente haber definido un plan, sino ir dndole seguimiento para
verificar que el proyecto est bajo control. Una falta de seguimiento puede resultar en proyectos barridos que para los que no se
tomaron acciones correctivas a tiempo.
Ejemplo de productos: Portlets en PPM que nos permiten ver el avance del Project plan en PPM ITG, y mtricas que comparan el
avance con el baseline inicial para indicar cualquier desfase. Adems que por medio de Action tems (requerimiento en PPM para
asignar tareas) se le puede dar un seguimiento a las acciones tomadas para eliminar esas diferencias con lo planeado.
El siguiente PA de nivel 2 es el SAM, Administracin de acuerdos con Proveedores, que consiste en definir claramente los acuerdos
con proveedores y cumplirlos.
En el caso de Softtek, este PA no aplica.

El PA de aseguramiento de calidad de procesos y productos tiene 2 objetivos especficos:
Evaluar de manera objetiva los productos y los procesos, donde se evala el seguimiento de descripciones de procesos, estndares y
procedimientos en los procesos realizados y los servicios y productos de trabajo asociados.
Proporcionar una retroalimentacin objetiva Los puntos de quiebre son objetivamente comunicados, se les da seguimiento y se
asegura su resolucin.
Ejemplo de procesos que se implementan para cubrir este PA son las auditoras de CMMI a los proyectos, donde por medio de
checklists se asegura que se estn implementando los procesos estndares definidos por la organizacin; y por medio de findi ngs
registrados en PPM ITG se le da seguimiento a las faltas que necesitan corregirse. Adems estos resultados son informados a
diferentes niveles de organizacin peridicamente.
El siguiente PA de nivel 2 es el de Administracin de la configuracin o Configuration Management. Los 3 objetivos especficos
sugieren que se establezcan baselines o situacin inicial del repositorio. Se d seguimiento y control a los cambios y se establezca la
integridad del baseline.
Definitivamente es de suma importancia contar con un repositorio donde se encuentren los documentos y entregables de un
proyecto, adems de que cuando se genera cdigo o se manejan releases es crucial tener un manejador de versiones para llevar
control sobre los componentes que se modifican. Este repositorio debe tener respaldos para evitar la prdida de informacin en
caso de algn problema.
Para cumplir con este PA, las auditoras de CMMI verifican que se cuente con un repositorio y peridicamente se estn realizando
auditoras de configuracin para asegurar que el repositorio mantenga la estructura y nomenclatura especificada en un plan de
configuracin que se encuentra en el PDP y se defini al inicio del proyecto.
En este plan se especfica en donde est el repositorio, que herramienta se va a utilizar para el manejo y control de versiones, como
se van a llamar los documentos que vamos a estar generando, cual es la estructura de directorios, quienes van a tener acceso, que
tipo de acceso hay y como se realizan los respaldos por mencionar algunos puntos.

El ultimo de los PAs de nivel 2 que revisaremos es medicin y anlisis. Este PA cuenta con dos objetivos especficos: Alinear las
actividades de mtricas y anlisis; y proporcionar resultados de mediciones.
Aqu los objetivos y actividades de medicin se alinean con las necesidades de informacin y objetivos del proyecto. Adems que se
proveen los resultados de las mtricas realizadas.
Una parte importante del proceso de inicio de un proyecto en la organizacin es el ISP (Initialize Software Project) y una de las
actividades de este proceso es la definicin de CTQs (Critical to Quality) que son los factores crticos para la medicin del proyecto;
de igual forma se definen la forma en que se calculan, de donde se toma la informacin, con que frecuencia, quien es el responsable
y los lmites de cada mtrica , es decir los valores que espera el cliente para considerar que se ha cumplido con sus requerimientos.
Esta informacin se encuentra documentada en el PDP (Project Development Plan).

Pasamos a los PAs de nivel 3. Y comenzaremos con los PAs organizacionales.
El primer PA es Organizational Process Focus, o enfoque de proceso organizacional y tiene como propsito planear, implementar y
poner en prctica mejoras a procesos organizacionales tomando en cuenta sus fortalezas y debilidades.
Este PA consta de un solo objetivo especfico, el establecer los artefactos para describir, mejorar e implementar los procesos
organizacionales.
Una herramienta que claramente nos permite cubrir este PA es PPM ITG.
El siguiente PA es Organizacional Process Definition, cuyo objetivo es establecer y mantener un set de procesos organizacionales y
estndares que sean aplicados.
El primer objetivo especfico es Determinar las oportunidades de mejora de los procesos, aqu se identifican las fortalezas,
debilidades y oportunidades de mejora de los procesos organizacionales de manera peridica. Y el segundo la planeacin e
implementacin de las actividades relacionadas con la mejora.
En otras palabras, es necesario estar evaluando nuestros procesos para detectar en que podemos mejorarlos. Ejemplos de estos
procesos son las metodologas estndar de AMS. Desarrollo y Testing. Estas metodologas o procesos han ido evolucionando con el
tiempo para ajustarse a los cambios en la demanda, la tecnologa y el mercado de IT.

Otro PA organizacional es Organizational Training, cuyo objetivo es desarrollar las habilidades y los conocimientos de la gente para
que puedan realizar sus roles de manera efectiva y eficiente.
Los objetivos especficos indican que se debe definir la capacidad de entrenamiento de la organizacin y que se debe proporcionar el
entrenamiento necesario.
En nuestra organizacin se cuenta con los planes de carrera que indican los bloques de cursos que debe tomar un colaborador
dependiendo del rol que desempea. Adems existe una herramienta llamada Softtek University que permite darle seguimiento a
todo lo relacionado con los cursos para los entrenamientos (material, exmenes, calificaciones, reportes).
El siguiente PA es Integrated Project Management o Administracin integrada de proyectos, y su propsito es establecer y
administrar el proyecto involucrando a todas las personas relevantes de acuerdo a un proceso definido e integrado que ha sido
tomado del set de procesos y estndares organizacionales.
Los dos objetivos especficos indican que se debe utilizar el proceso definido por la organizacin y que se deben coordinar las
actividades con todos los involucrados.
Todo proyecto que inicia debe partir de un proceso organizacional, ya sea la metodologa de AMS, Desarrollo o Testing. Esta
metodologa es entonces adecuada a las necesidades particulares del proyecto y el cliente, dejando justificadas las desviaciones que
se han aplicado en el PDP (Project Development Plan).
Un ejemplo de un producto para este PA son los planes de proyecto y las estimaciones

El propsito de la PA de Risk Management o Administracin de riesgos es identificar problemas potenciales antes de que ocurran
para que las actividades de mitigacin o contingencia sean planeadas y llevadas a cabo.
Los 3 objetivos especficos para esta PA sugieren prepararse para la administracin de riesgos; identificar y analizar los riesgos para
ver su importancia (ya que en algunos casos hay riesgos que no son crticos y el identificarlos nos permite prestarle ms atencin a
aquellos que tienen mayor impacto) y por ltimo una vez que se identifican y se definen prioridades, se planean las acciones
necesarias para mitigarlos o reducir su impacto.
Para cubrir con los objetivos de este PA, en PPM ITG se cuenta con un tipo de requerimiento que se llama Risk Management
Request, el cual permite registrar los riesgos que son identificados, de manera que se les d seguimiento. Para avanzar es necesario
definir un plan de mitigacin o plan de contingencia que generar actividades para disminuir o eliminar el riesgo en cuestin.

El objetivo del PA de desarrollo de los requerimientos es producir y analizar los requerimientos del cliente, productos y
componentes de productos y consta de 3 objetivos especficos.
Desarrollo de los requerimientos del cliente. Aqu vamos a traducir las necesidades, expectativas, restricciones y todas las interfases
del cliente, en requerimientos.
Como segundo objetivo tenemos que redefinir y elaborar los requerimientos del cliente para desarrollar los requerimientos de los
productos o de los componentes de los productos.
En el ltimo objetivo los requerimientos son analizados y validados y se define en este punto la funcionalidad requerida.
Ejemplos de productos que cubren con este PA son aquellos documentos donde se define el anlisis de los requerimientos,
interfases, restricciones, escenarios, funcionalidad requerida, etc.

El siguiente PA es Technical Solution o solucin tcnica y su propsito es disear, desarrollar e implementar las soluciones a los
requerimientos, como lo indican sus tres objetivos especficos.
Una parte importante de este PA es el hecho de que aqu se evalan las diferentes opciones para la solucin tcnica y de acuerdo a
un criterio especfico se selecciona aquella que sea la ms adecuada.
Para la parte de la evaluacin de opciones algunos productos que se pueden generar como evidencia son las opciones
documentadas, un anlisis objetivo de esas opciones (que ms adelante veremos se apoya en el PA para toma de decisiones DAR), y
la documentacin de cmo ser implementada.
Para la parte de la generacin e implementacin del diseo, los productos tpicos para cubrir con este PA son: documento de
arquitectura, diseo de componentes, especificaciones de diseo de interfase, criterio para diseo o reuso de componentes, di seo
implementado y la documentacin de usuario.

El PA de verificacin asegura que los productos seleccionados cumplen con las especificaciones de sus requerimientos.
El PA hace referencia especficamente a los peer reviews (o revisiones por compaeros), que es una prctica comn para el
aseguramiento de calidad.
Los 3 objetivos especficos son:
Prepararse para la verificacin
Realizar los peer reviews
Verificar los productos seleccionados
Las herramientas con las que contamos para cubrir estos PAs son los peer review request en PMM para los proyectos que llevan
un plan de trabajo, o la parte de peer review que se encuentra en el flujo de los requerimientos para proyectos de AMS o
mantenimiento. Los proyectos de testing pueden utilizar cualquiera de estas dos modalidades.
Ejemplos de productos para cubrir esta PA son:
Listas de productos a los que se les aplicarn los Peer Reviews (se encuentra en el PDP en la seccin del Plan de Calidad)
Checklists de verificacin que permiten seguir un criterio o procedimiento para la revisin (se encuentran especificados en el mismo
plan de Calidad)
Resultados de los peer reviews - se documentan en las hojas de defectos en los requerimientos. (Peer review defect sheet).

El siguiente PA de nivel 3 que presentamos es el de Validacin, cuyo propsito es demostrar que un producto o componente se
puede utilizar como fue especificado en el ambiente especificado.
Este PA cuenta con dos objetivos especficos: Prepararse para la validacin y Validar el producto o componente.
El checklist tambin es una herramienta para implementar este PA., un ejemplo de esto es el checklist de recepcin. Este tipo de
checklist pueden ayudar a descubrir funcionalidades que faltan de implementar.
Ejemplos de productos para cubrir esta PA son:
Listas de productos a los que se les aplicar la validacin
Checklists de validacin que permiten seguir un criterio o procedimiento para la revisin (se encuentran especificados en el mismo
plan de Calidad)
Resultados de la validacin - se documentan en el checklist.
El ltimo PA de nivel 3 es Anlisis y Resolucin de Decisiones. Su objetivo especfico es evaluar las alternativas, con el propsito de
analizar posibles decisiones utilizando un proceso formal de evaluacin que analiza las alternativas identificadas contra los criterios
establecidos.
Una herramienta que cubre la implementacin de este PA y que ha sido definida como estndar en softtek para evaluar alternati vas
es la Matriz de Pugh. Al documentar las diferentes alternativas y los criterios utilizados para evaluarlas se tiene un resultado que
apoya la decisin de la alternativa mas adecuada.
Este PA puede apoyar al PA de Technical solution para evaluar y seleccionar las alternativas de diseo o implementacin posibles.

Estos dos PAs son los nicos para el nivel 4.
Quantitative Project Management - que tiene el propsito de administrar cuantitativamente el proceso definido de un proyecto
para lograr los objetivos de calidad y performance establecidos.
Para cubrir esta PA se registran requerimientos de Metric Reviews (o revisiones de mtricas) de manera peridica en los que se
documenta el desempeo de un proyecto para un perodo especfico de tiempo y los lmites esperados que estn definidos en la
matriz de control de un proyecto en la parte del plan de calidad del PDP (las mtricas definidas organizacionalmente son On time
Delivery (entrega a tiempo), First time right (porcentaje de entregas correctas a la primera), SPAN y Costo de Calidad (que es la
relacin del tiempo dedicado a revisiones o peer reviews y correcciones de defectos entre el esfuerzo total invertido en un perodo).
En la matriz de control estn los factores crticos que se estarn midiendo y cuales son sus lmites y metas. Si el performance de un
proyecto est fuera de los lmites, el requerimiento se marca fuera de control y se analizan las causas origen por medio de RCAs
(anlisis de causa raz) para despus definir acciones correctivas.
El PA de Organizational Process Performance tiene como objetivo establecer y mantener un entendimiento cuantitativo del
desempeo de un grupo de procesos estndares de la organizacin para apoyar los objetivos de calidad y performance y para
proporcionar un punto de referencia y modelos para administrar cuantitativamente la organizacin.
Este PA se cubre cuando se tienen metas y objetivos para los diferentes procesos organizacionales (como desarrollos, AMS, Testing
,etc). Estos objetivos estn documentados en la matriz de control del template estndar del PDP.

En el nivel 5, vemos el penltimo de los PAs que es la Innovacin Organizacional y su Implementacin.
Aqu los dos objetivos especficos se enfocan en seleccionar e implementar las mejoras de proceso y de tecnologa que contribuyan a
alcanzar los objetivos de calidad y de desempeo de proceso, de manera que puedan ser medibles para verificar su impacto.
Algunos productos que pueden cubrir este PA son:
Propuestas con anlisis de mejoras
Reportes de evaluacin de pilotos
Mejoras seleccionadas para implementacin
Plan de implementacin de la mejoras
Resultados documentados de la implementacin
Los objetivos de este ltimo PA, se enfocan en determinar las causas de los defectos y otros problemas que se presentan y tomar las
acciones para prevenir que ocurran en el futuro.
Es muy importante que una vez que se encuentra la causa raz de un defecto o problema, se le d seguimiento al plan de accin
definido para asegurar su correcta implementacin y efectividad.
Herramientas que se pueden utilizar para los RCAs (root cause anlisis o anlisis de causa raz en espaol) son el diagrama de
pescado y la herramientas de los 5 porqus (five whys); y se pueden aplicar cuando se detecta un patrn de defectos, se presenta
algn issue o durante los metric reviews cuando las mtricas de un proyecto estn fuera de los lmites establecidos.
Hasta aqu hemos visto las reas de proceso de los 5 niveles de CMMI y algunos de sus objetivos especficos. Ahora vamos a ver la
definicin y aplicacin de los objetivos genricos.

Revisando de nuevo nuestro esquema de la estructura del modelo CMMI, podemos ver que los objetivos genricos se encuentran
apoyando a las reas de proceso, pero cul es la funcin de los objetivos genricos?
Estos contribuyen a la institucionalizacin de los procesos y cada uno aplica a ms de un rea de proceso.

El cumplir con estos objetivos en relacin a una PA significa:
Que se tiene un control mejorado en la implementacin del proceso.
Que se permite la institucionalizacin de un proceso que asegurar que es repetible y perdurable.
Existen 2 objetivos genricos :
El que aplica a los PAs a partir del nivel 2 - institucionalizar un proceso administrado
El que aplica a los PAs a partir del nivel 3 institucionalizar un proceso definido
Si observan, el objetivo genrico de nivel 2 hace referencia a un proceso ADMINISTRADO, que es la misma palabra con la que
identificamos el nivel 2 , y el objetivo genrico del nivel 3 a un proceso definido.

La siguiente parte de la estructura que veremos son las prcticas genricas, que tambin contribuyen a la institucionalizacin de los
procesos y son actividades que aseguran que los procesos asociados con las PAs sern efectivos, repetibles y perdurables.
Estas prcticas tienen 2 caractersticas: que son similares en todas las reas de proceso y que existe un grupo de prcticas genricas
para cada objetivo genrico.

En la siguiente tabla tenemos algunos productos y procesos de la metodologa SSDP que ya hemos mencionado al explicar cada uno
de los PAs, y cual de esos PAs cubren o ayudan a implementar.
Por ejemplo la Pugh Matrix se puede observar que apoya el PA de DAR (decisin anlisis and resolution), o el request de
administracin de riesgos en PPM, que cubre PMC (monitoreo y control del proyecto) y RSKM (administracin de riesgos).
Existen algunos productos que cubren una gran variedad de PAs como el PDP (project development plan) o un solo PA como la pugh
matrix.

Los beneficios de aplicar el modelo de CMMI son muy variados, entre ellos podemos mencionar:
Costos reducidos ya que al tener control sobre el plan de proyecto no se extiende la fecha de terminacin, adems que no se
incurrirn en costos extras por las horas trabajadas de ms.
Jornadas ms cortas
Mayor productividad Las actividades de aseguramiento de calidad evitan el tener que dedicar tiempo a retrabajos para corregir
defectos y todos los miembros del equipo tienen bien definidas sus actividades a realizar adems que cuentan con las habilidades
necesarias.
Mayor Calidad Por medio de las actividades de aseguramiento de calidad, validacin y verificacin, se previenen y detectan
defectos que de otra forma llegaran al cliente.
Aumento de la satisfaccin del cliente entregas a tiempo (porque se hizo una estimacin adecuada y se llev el control de las
actividades), sin defectos y con calidad dan como resultado un cliente satisfecho.
En algunos casos, el tener cierto nivel de CMMI es necesario para una organizacin ya que algunos clientes lo exigen como requisito
para hacer negocios y asegurar la calidad de sus proveedores de servicios.
Aplicar el modelo en un proyecto u organizacin asegura que no se realizan compromisos sin un anlisis de impacto previo, o se
tiene un mayor control ya que se lleva un seguimiento de los riesgos y mas que implementar acciones reactivas, se manejan planes
de accin proactivos. Y por ltimo, la comunicacin no es simplemente un paso ms en el proceso, sino una parte vital de ellos.



Si ests interesado en obtener ms informacin relacionada con el modelo de CMMI, puedes recurrir a las publicaciones o el website
del SEI (Software Engineering Institute).
Aqu presentamos dos opciones de libros y tres fuentes electrnicas.

Pues bien, esperamos que despus de haber visto este material, encuentres que todas las actividades que realizas y el cmo las
realizas son parte vital del nivel de madurez que puede alcanzar la organizacin y que existe una estrecha relacin entre los
componentes, entregables, productos y procesos que realizan y las prcticas recomendadas por este modelo.

Si ests interesado en obtener ms informacin relacionada con el modelo de CMMI, puedes recurrir a las publicaciones o el website
del SEI (Software Engineering Institute).
Aqu presentamos dos opciones de libros y tres fuentes electrnicas.