Implementando CMMI: ¿Por dónde empezar?
La implementación del nivel 3 del modelo CMMI nos demoró 8 meses a diferencia de los 9 meses que nos
demoró implementar el nivel 2, aunque en realidad la implementación del nivel 2 fue muchísimo mayor si
contamos el primer esfuerzo que se realizó en TeamSoft, en donde se definieron varios procesos, formatos,
plantillas, entre otros documentos, trabajados todos bajo las prácticas del modelo en su versión 1.1. En este
primer esfuerzo se cometió el error de considerar las áreas de proceso del modelo como procesos de la
empresa. Bueno este y otros inconvenientes se solucionaron cuando se creó formalmente un proyecto
interno en TeamSoft para implementar el nivel 2 del modelo, que para ese entonces ya se encontraba en su
versión 1.2.
Resalto el echo de la duración porque el nivel 3 significa en número de prácticas tres veces más que la
cantidad de prácticas contenidas en el nivel 2. Entonces la pregunta es, ¿cómo pudimos implementarlo más
rápido si contábamos con la misma cantidad de personas en el equipo?, en todo caso ¿qué hicimos bien?.
En realidad en ambos proyectos, el de la implementación del nivel 3 y el del nivel 2 (en su segundo intento),
utilizamos una metodología basada en el modelo IDEAL (modelo publicado por el Software Engineering
Institute).
Modelo IDEAL publicado por el SEI
Este modelo se llamada IDEAL por las iniciales de las cinco fases que lo describen: Iniciación, Diagnóstico,
Establecimiento, Acción y Aprendizaje (“Learning”) y que en resumen es una guía para implementar
acciones de mejoras organizacionales en general.
En TeamSoft creamos una metodología de trabajo basado en este modelo y consideramos la implementación
del modelo CMMI como una gran acción de mejora, que dado su esfuerzo y tiempo lo denominamos proyecto
de mejora.
A continuación les detallaré los 8 puntos más resaltantes que realizamos al iniciar la implementación del
modelo CMMI:
Obtener el involucramiento de la Gerencia o tener un Sponsor de “peso”. La implementación del modelo
CMMI en TeamSoft se consideró como un proyecto más que se unía a la cartera de proyectos en marcha
que eran monitoreados directamente por la Gerencia en las reuniones quincenales donde cada Jefe de
Proyecto debía informar su avance, problemas, riesgos, entre otros temas relacionados con su
proyecto.
Recibir una capacitación en el modelo. Nosotros nos preparamos en talleres, conferencias y diplomados.
Adicionalmente recibimos asesorías externas que nos ayudo a acelerar el entendimiento de las
prácticas, ya que en muchas ocasiones necesitamos de ejemplos o maneras distintas de implementar las
prácticas o de clarificar conceptos, entre otros. Contar con esta clase de asesoría nos permitío además
estar alineados con lo que se esperaba de la evaluación SCAMPI A (tipo de evaluación que otorga como
resultado la valorización en el nivel obtenido, es decir si nos certificamos o no). Definir el objetivo de mejora. Este punto es muy importante ya que nos permitió comparar la situación
actual versus la que tuvimos luego de implementar el modelo CMMI, así pudimos medir si llegamos al
objetivo trazado o también nos permitió costear los beneficios conseguidos. Por ejemplo nuestro objetivo
de mejora fue reducir la densidad de errores. Por otro lado contar con un objetivo de mejora medible y
alcanzable, nos permitió darle sostenibilidad al esfuerzo incurrido en la implementación del modelo.
Analizar la situación actual. Aparentemente puede tomarse como un retraso o como una actividad
innecesaria, pero en realidad para empezar cualquier emprendimiento es necesario conocer de dónde y
en que condiciones partimos. En TeamSoft, cuando analizamos la situación de partida comprobamos
que algunas de las prácticas del modelo ya las estábamos cumpliendo de alguna manera.
Formar un grupo de trabajo. El éxito y la mejor aceptación de lo definido resulta cuando se establece un
grupo de trabajo incluyendo a los mismos ejecutores y expertos, es decir Analistas Funcionales, Jefes de
Proyectos, entre otros roles afectados por la implementación, quienes conjuntamente con los
integrantes del Área de Mejora de Procesos crean y definen los documentos necesarios o idean la mejor
forma de implementar la práctica buscando siempre el valor agregado al Cliente o a la Empresa.
Tener un plan de trabajo. No tengo mucho que comentar al respecto, sólo hacerles recordar que contar
con un plan de trabajo nos ayuda a no perder de vista el objetivo.
Contar con una metodología. Por ejemplo el modelo IDEAL, del cual ya hablamos al inicio.
Mapeo de las prácticas versus lo implementado. Esta actividad será obligatoria realizar cuando
abordemos una evaluación SCAMPI A, pero no por ello la debemos restarle importancia. Para mí este
mapeo es muy útil cuando realicemos una adecuación en el proceso o en la plantilla y necesitemos
evaluar si está referenciada o es evidencia directa de una práctica.
En el siguiente post les escribiré sobre la estrategia que adoptamos en el plan de trabajo para implementar
el nivel 3 del modelo CMMI o si desean podemos conversar más a detalle de cada uno de los puntos
descritos anteriormente. Hasta pronto y no se olviden de dejar sus comentarios.
Procesos cmmi en cada proceso se entregan sus respectivos documentos.
Desarrollo de Requerimientos
Validación
Proceso de desarrollo de software de orden integración
Artefactos
Actores Participantes
Procesos de Apoyo
Pruebas de Software
Gestión de requisitos para cmmi.
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óhttp://www.teamsoft.com.pe/blog/implementando-cmmi-por-donde-empezar/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.
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.
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).Áreas de proceso….
Hay 22 áreas de proceso, las cuáles se presentan a continuación en 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 integrad del proyecto +IPPD (IPM + IPPD)*.
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)*.
Enfoque en procesos 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).
http://www.codejobs.biz/es/blog/2012/09/04/las-areas-de-proceso-decmmi#sthash.dT34WNIy.v2h7kTwp.dpuf
https://docs.google.com/document/d/1e49q5eo0G65sUvQsvWctJp1Uh4YtmFLjhMCh3B9_6tk/edit?usp=sharing
