CMMI

4.1. Introducción

A mediados de los añ os 80 del siglo pasado el Departamento de Defensa (DoD)

de Estados Unidos decide crear el Instituto de Ingenierıa de Software o Software
Engineering Institute (SEI). El SEI se constituye como un centro de investigación
dentro de la Universidad Carnegie Mellon, en Pittsburgh. Entre las á reas de com-
petencia del SEI, el Departamento de Defensa marca como prioritaria la búsqueda
de un modelo que permita evaluar las capacidades de los contratistas software del
ejército americano.
Los trabajos llevados a cabo en el SEI dieron lugar al Software Capability
Maturity Model o Modelo de Capacidad y Madurez (CMM) [50] [51]. Este modelo
ha sido una aportación fundamental a la ingenier´ıa de software en general y a la
forma en la que se realiza la mejora de los procesos software de una organización.
CMM fue tan solo el comienzo, y tras é l , han surgido otros modelos de ma-
durez, como el People Capability Maturity Model (PCMM) [52] que se centra en
la capacidad y continua mejora de la gestión y desarrollo de los activos humanos,
o el Systems Engineering Capability Model [53] que se centra en capacidad de los
sistemas.
Otras organizaciones igualmente han desarrollado marcos de trabajo para la
mejora de procesos similares. Un ejemplo es el enfoque SPICE [54], un modelo de
capacitación m á s flexible que el modelo CMM del SEI.
Otro ejemplo de modelo de madurez fue el “Bootstrap Project” [55], impulsado
desde las instituciones europeas y que fue usando por la Agencia Espacial Europea
para evaluar la calidad de sus procesos a lo largo y ancho de la organización.
A finales de los 90, el amplio abanico de modelos de madurez y capacitación
existentes hizo que desde el SEI se plantease la necesidad de disponer de un nuevo
modelo que recogiese la experiencia acumulada por todos ellos y crear as´ı un nuevo
estándar. De esta forma nace el marco de trabajo CMMI [56] [57] [58] [59] [4] como
sucesor del CMM.
El modelo CMMI surge con la idea de ser aplicado a la mejora de procesos en
un amplio espectro de organizaciones. El modelo es lo suficientemente complejo,

1
consta de m á s de 1000 páginas, para que se pueda ajustar a las necesidades de
organizaciones de muy diversa naturaleza.

4.2. Mejora basada en procesos

La mejora basada en procesos o Model-Based Process Improvement, consiste en
la utilización de un modelo que gu´ıe la mejora de los procesos de una organización.
Entederemos por proceso software la secuencia de actividades que, cuando
se ejecutan, producen como resultado un sistema software.
La mejora de procesos nace a partir de los trabajos de la gestión de calidad de
autores como Demming [60], Crosby [61] y Juran [62] y está dirigido al aumento
de la capacidad de trabajo de los procesos. La capacidad de un proceso es la
habilidad de un proceso para producir un resultado dentro de los l´ımites fijados
en las especificaciones. Si la capacidad de un proceso aumenta lo suficiente, este
se convierte en predecible y por tanto medible, y las causas m á s significantes de
mala calidad pueden ser eliminadas o controladas. El aumento de las capaciones
de los procesos empleados dentro de una organización hace que la madurez de
la misma aumente. Conseguir altos niveles de madurez implica un fuerte compro-
miso por parte de la dirección de la organización y una visión estratégica a largo
plazo, además de cambios en la manera de actuar y proceder en todos los niveles
organizativos.
En los trabajos intelectuales, y el software es uno de ellos, la calidad resultante
depende de su diseñ o. Existen cuatro factores importantes que afectan a la calidad:

calidad de procesos

calidad del personal

coste y plazos

tecnolog´ıa de desarrollo

La influencia de cada uno de estos cuatro factores depende del tamañ o del
proyecto. Para sistemas muy grandes que incluyen a su vez otros subsistemas m á s
pequeños, desarrollados en ocasiones por equipos externos en diferentes locali-
zaciones, el principal factor que afecta a la calidad es el proceso software. Los
principales factores en grandes proyectos software son la integración, la gestión
del proyecto y la comunicación. Normalmente existe una mezcla de habilidades y
experiencia entre los miembros del proyecto, y dado que el proceso de desarrollo se
lleva a cabo durante añ os, existe una alta rotación entre los miembros del equipo
de desarrollo. Incluso el equipo podr´ıa cambiar por completo entre el inicio y el
final.
En proyectos m á s pequeños, donde solo existe un nú mero reducido de desarro-
lladores, la calidad del equipo es fundamental. Además, en este tipo de proyectos,
el tiempo de desarrollo (programación) consume la mayor parte del tiempo de

2
proyecto, por lo que una buena tecnolog´ıa de desarrollo afecta notablemente a la
calidad resultante.
Independientemente del tamañ o si un proyecto está mal dimensionado en coste
y/o plazos la calidad resultante se ve rá afectada de alguna forma.

4.2.1. El proceso de mejora de procesos

Los procesos software son observables en cualquier organización que produzca

software, independientemente de su tamaño. Estos procesos son de muy diferen-
tes tipos dependiendo del grado de formalidad del proceso, del tipo de producto
desarrollado, del tamañ o de la organización, etc. No existe un estándar o proceso
software ideal. Cada individuo, compa ñı́a u organización puede desarrollar el suyo
propio acorde a sus necesidades, conocimientos, tamaño, experiencia, clientes, tipo
de software desarrollado, mercado al que se dirige o cultura empresarial.
La mejora de procesos, por tanto, no implica adoptar una determinada forma
de trabajo, uso de una herramienta, o el seguimiento de unas reglas dadas. Aunque
existan organizaciones con necesidades software similares, pensemos por ejemplo,
en administraciones públicas desarrollando una plataforma para el pago de tri-
butos, todas ellas tendrán particularidades locales que las afectan, por ejemplo
diferentes regulaciones a las que se ven sometidas. Por tanto, rara vez una mejo-
ra de procesos en una determinada organización es exportable a otra. Se deben
considerar los factores locales a la organización a la hora de mejorar sus procesos.
Por otra parte, se debe considerar los atributos de los procesos que se deseen
mejorar. Si el objetivo es mejorar la estimación de plazos de los proyectos soft-
ware se podr´ıan por ejemplo introducir nuevas actividades o herramientas que
modifiquen los pasos a seguir para una estimación m á s exacta. En la tabla ?? se
presentan algunos ejemplos de atributos de procesos que pueden ser susceptibles
de mejora. Estos atributos suelen estar relacionados, as´ı, si un proceso tiene gran
“visibilidad” es probable que sea de fácil “comprensión”: un observador externo
podr´ıa inferir las actividades llevadas a cabo con solamente ver las salidas del
proceso. En cambio, un proceso con poca “visibilidad” podr´ıa estar inversamente
relacionado con la “rapidez”. Hacer el proceso visible implica que los involucrados
generen información sobre el mismo, lo que afecta directamente al tiempo que se
necesita para finalizarlo.
El proceso de mejora de procesos es c´ıclico e implica tres subprocesos tal y
como se muestra en la figura 4.1:

Medición del proceso. El objetivo es medir atributos de forma que se

puedan establecer objetivos de mejora cuantitativos.

Análisis del proceso. El proceso se audita, identificando sus puntos débi-

les y los posibles cuellos de botella. En ese punto se pueden desarrollar los
modelos del proceso (también conocidos como mapas del proceso). El análi-
sis puede estar enfocado a una serie de atributos como la “robustez” o la
“comprensión” del proceso.

3
 Caracterı́stica del proceso Aspectos clave
Comprensión ¿Hasta que punto el procesa esta definido y
cómo de fácil es comprender la definición del
proceso?
Estandarización ¿Hasta que punto el proceso esta basado en
un proceso genérico? ¿Esta siendo utilizado
en otros partes de la organización?
Visibilidad ¿Las actividades del proceso culminan en un
resultado clave de forma que este sea visible?
Medible ¿Existen atributos en el proceso que le hagan
susceptible de ser medido?
Robustez En caso de adversidades de algú n tipo ¿se
puede continuar con el proceso? ¿en q ué si-
tuaciones no se puede?
Mantenimiento ¿Puedo el proceso evolucionar y reflejar cam-
bios requeridos por la organización?
Rapidez ¿Cuánto tiempo es necesario para completar
el proceso desde q ué se especifica su misión?

Cuadro 4.1: Atributos genéricos de procesos

Cambios en el proceso. Por último, se deben de elaborar propuestas de

cambios que mitiguen las debilidades y cuellos de botella detectados.

La mejora de procesos es una tarea de largo plazo que puede llevar semanas,
meses o incluso añ os dependiendo del tamañ o del proyecto y la organización. Es
también una tarea continua, sin fin, y que evoluciona de acuerdo con los cambios
y necesidades que aparecen en las organizaciones.

4.2.2. Medición de Procesos

La medición de procesos permite analizar de manera cuantitativa un proceso,

por ejemplo, midiendo el tiempo necesario para generar y realizar las pruebas de
validación software.
Se pueden establecer tres tipos de métricas de procesos:

1. Tiempo para completar un proceso. Este puede ser el tiempo total

necesario para completar un proceso. Pueden existir variantes del mismo
como el tiempo necesario para completar el proceso en función de los recursos
empleados, el tiempo que emplean un determinado grupo de ingenieros en
el proceso, etc.

2. Recursos empleados. Los recursos pueden ser expresados en nú mero de

personas por d´ıa necesarios, la capacidad de computación utilizada, etc.

3. Número de ocurrencias de eventos. Representa el nú mero de veces que

4
 Figura 4.1: Ciclo de mejor de procesos

un evento es observado durante en el proceso. Por ejemplo, el nú mero de

pruebas software fallidas en el transcurso del proceso de validación.

Las dos primeras métricas pueden ser utilizadas para averiguar si los cambios
introducidos en un proceso han mejorado su eficiencia. En cambio, la última métri-
ca no tiene una traducción directa, si el cambio en el proceso permite descubrir
un mayor nú mero de defectos software no tiene porqué traducirse en un aumento
de la calidad, deberán ser posteriores medidas las que corroboren o descarten el
beneficio del cambio introducido.

Goal-Question-Metric

Saber q ué información recopilar para llevar a cabo la mejora de procesos no es

una tarea trivial. Basili et al. [63][64] propusieron a finales de los añ o s ochenta el
paradigma objetivo-pregunta-métrica, en inglés goal-question-metric, abreviado co-
mo “GQM”. El paradigma GQM (figura 4.2) se utiliza como medio para responder
tres preguntas cruciales en la mejora de procesos.

1. ¿Por q ué se necesita la mejora de procesos?

2. ¿Qué información se necesita para identificar y evaluar las mejoras?

3. ¿Qué medidas se requieren tomar para facilitar esta información?

Estas preguntas se relacionan directamente con las abstracciones (objetivos,

preguntas, métricas) en el paradigma GQM.

1. Objetivo. El objetivo es aquello que la organización persigue. No tiene por

q ué estar relacionado directamente con el proceso, pero si a como el proceso

5
 Metas por lograr

Preguntas por responder

Cosas por medir M1 M2 M3 M4 M5

Figura 4.2: Paradigma GQM

afecta a la organización. Por ejemplo, si la organización se plantea eliminar el

uso del papel en favor del soporte electrónico aquellos procesos que generen
documentación deberán hacerlo en el nuevo soporte y se deberá definir cómo
ser hará (tipo y codificación del archivo, lugar de almacenamiento, copias de
seguridad, etc.).

2. Preguntas. Es el paso siguiente al objetivo. Buscan aflorar las zonas de in-

certidumbre relacionadas con el objetivo marcado. Normalmente, un objetivo
se relacionará con un conjunto de preguntas a responder. Si el objetivo fija-
do es reducir el tiempo de un proceso cabr´ıan preguntarse entonces ¿dónde
están los cuellos de botella? ¿existen demasiadas reuniones? ¿son efectivas
descubriendo defectos todas las pruebas realizadas?

3. Métricas. Constituyen las medidas que se deben recopilar para dar res-
puesta a las preguntas planteadas y para confirmar si una vez aplicadas las
mejoras estas han surtido efecto. Algunas métricas útiles para responder a
las preguntas planteas anteriormente podr´ıan ser: porcentaje del tiempo que
los desarrolladores se pasan en reuniones, nú mero de casos de prueba que
nunca detectan fallos, etc.

La ventaja de utilizar el paradigma GQM en la mejora de procesos es que

permite separar las directrices organizativas (objetivos) de las propias del proceso
(preguntas). Además, proporciona una base para decidir q ué información recopilar
y sugiere c ómo se debe de tratar para dar respuesta a las preguntas planteadas.
La aproximación GQM ha sido desarrollada y combinada junto con los mo-
delos de capacidad de madurez del Instituto de Ingenier´ıa de Software [50] en la
metodologı́a AMI (Analyze, Measure, Improve) de mejora de procesos software.
AMI propone un modelo por fases para llevar a cabo la mejora de procesos, donde
las mediciones comienzas después de que la organización introduzca un estándar o
norma a sus procesos. Pulford et al. [65] proporcionan una seria de gu´ıas a seguir
para llevar a cabo una aplicación práctica del método AMI.

6
4.2.3. Análisis de Procesos

El análisis de procesos es el estudio de los procesos que permite comprender

sus caracter´ısticas clave y cómo esos procesos son llevados a cabo por las personas
involucradas. El análisis est á relacionado con la medida de los procesos en cuanto
a que para poder recopilar información y luego realizar las medidas es necesario
comprender q ué se está midiendo e inevitablemente se debe entender cuál es el rol
del atributo en cuestión dentro del proceso. Los objetivos que se persiguen en el
análisis de proyectos son:

Comprender las actividades involucradas en el proceso, y las relaciones que

se establecen entre estas actividades.
Comprender las relaciones entre las actividades del proceso y las medidas
que se han hecho
Relacionar el proceso bajo análisis y compararlo con el resto de procesos que
se llevan a cabo en la organización o con la realización ideal del mismo.

Durante el análisis se persigue alcanzar una compresión de lo que sucede en

el proceso y se buscan las posibles ineficiencias y problemas que puedan existir.
También es interesante averiguar hasta q ué punto el proceso es usado, cómo de
importante o cr´ıtico resulta, cómo influye en el resto de procesos y cóm o los requi-
sitos y restricciones organizacionales le influyen a é l . En la tabla 4.2 se detallan
algunos aspectos a tener en cuenta a la hora de realizar el análisis de procesos.
Para realizar el análisis es habitual el empleo de las siguientes técnicas:

1. Cuestionarios y entrevistas. Se busca recopilar información de primera

mano entrevistando a los ingenieros, jefes y directores involucrados en el pro-
ceso. Las respuestas al cuestionario formal son refinadas con una entrevista
personal.
2. Estudios etnográficos. Se centran en los participantes del proceso, buscan
entender el proceso de desarrollo como un proceso humano. Estos análisis
revelan sutilezas y detalles imposibles de detectar mediante cuestionarios y
entrevistas. Existen diversos trabajos sobre cómo llevar a cabo este tipo de
estudios [66] [67] [68].

Cada uno de estos dos enfoques presenta ventajas e inconvenientes. El análisis

basado en cuestionarios puede ser llevado a cabo razonablemente rápido si se
identifican correctamente las preguntas adecuadas. Sin embargo, si las preguntas
estas mal planteadas o son inapropiadas, el resultado puede ser una compresión
incorrecta o poco aproximada a la realidad del proceso. Además, se corre el riesgo
de que los entrevistados perciban el cuestionario como una evalución a su trabajo
y sus respuestas estén enfocadas hac´ıa lo que creen que sus superiores desean
escuchar.
Las entrevistas permiten un marco m á s abierto, se parte de un guión esta-
blecido, pero el transcurso de la conversación puede derivar hacia aspectos no

7
Aspecto Preguntas
Adopción y estandarización ¿El proceso esta estandarizado y documentado a lo lar-
go de la organización? Si no lo esta, ¿significa esto que
cualquier medición realizada solo es aplicada al proce-
so bajo análisis? Si el proceso no esta estandarizado,
entonces los cambios puede no se aplicables a procesos
similares en otros puntos de la organización.
Buenas prácticas ¿Existe alguna buena práctica de ingenier´ıa de software
no incluida en el proceso? ¿Por q ué no lo esta? ¿La ca-
rencia de estas prácticas impacta en la calidad final del
proyecto?
Restricciones organizacionales ¿Cuáles son loas limitaciones organizacionales que afec-
tan al diseñ o y ejecución del proceso? Por ejemplo, si el
proceso necesita manejar información clasificada o con-
fidencial, existirán actividades que verifiquen esta infor-
mación no sea incluida en informes que puedan salir de
la organización.
Comunicación ¿Cómo se comunica la información en el proceso? Fallos
en la comunicación son normalmente fuentes de proble-
mas y cuellos de botella comunes en los procesos.
Introspección ¿Son los actores del proceso conscientes del mismo?
¿Pueden estos actores proponer cambios?
Aprendizaje ¿Cómo aprenden los nuevos integrantes los procesos en
los que son participantes activos? ¿Tiene la organización
algú n programa estandarizado de aprendizaje?
Soporte de herramientas ¿ Qué aspectos del proceso están apoyados por herra-
mientas y cuáles no? ¿existen mejores herramientas dis-
ponibles?

Cuadro 4.2: Algunos aspectos del análisis de procesos.

8
contemplados en un primer momento. Normalmente este tipo de enfoques permite
a los involucrados en el proceso expresarse mejor y de forma m á s abierta y natural
que en el caso de los cuestionarios.
En casi todos los procesos, la gente involucrada tiende a realizar pequeñ os
cambios locales para adaptar los procesos a circunstancias concretas. El análisis
etnográfico persigue detectar estos cambios, y en general es m á s efectivo que cues-
tionarios y entrevistas a la hora de hacer esta detección. Sin embargo, es una tarea
que requiere de un largo tiempo para llevarse a cabo y que puede extenderse me-
ses. Se fundamenta en un análisis externo, sin interactuar en é l , simplemente una
observación detallada de todos sus fases y propiedades. Para realizar un análisis
completo, se requiere observar todas las fases, por lo que en grandes proyectos esto
podr´ıa conllevar un análisis de añ os, lo que lo hace en impracticable en muchas
situaciones. A pesar de todo, este tipo de análisis suele ser ú til cuando se desea
profundizar no en la totalidad del proceso sino en una parte concreta del mismo.
Normalmente, el análisis comienza a partir del modelo del proceso, donde se
define las actividades que lo componen con las entradas y salidas de dichas activi-
dades. El modelo puede incluir también información acerca de los actores involu-
crados (el personal, los roles responsables de realizar las actividades, y los entre-
gables cr´ıticos que se deben respetar). Pueden utilizarse diferentes herramientas
para realizar el modelo, desde una notación informal hasta otra m á s formal co-
mo diagramas de actividad UML [25] o el modelo desde notación de procesos de
negocio BPMN (Business Process Model and Notation) [69].
El modelo del proceso es una buena forma de centrar la atención en las acti-
vidades involucradas y en la información transferida entre ambas. Es importante
tener en cuenta que el modelo no tiene porqué ser completo ni formal, su cometido
es servir de base de discusión.
Al finalizar el análisis del proceso se deben tener un conocimiento profundo del
proceso y una idea del potencial de mejora existente para el futuro junto con las
limitaciones existentes a esas mejoras.

4.2.4. Proceso de cambio

El proceso de cambio supone introducir cambios y modificaciones al proceso

existente. Los cambios pueden ser de muy diversos tipos: nuevas prácticas, méto-
dos, herramientas, cambios en el orden de procesos y actividades, introducción o
eliminación de entregables, nuevas formas de comunicación, introducción de nue-
vos roles y responsabilidades, etc.
Los cambios deben ser motivados y dirigidos por objetivos de mejora tales
como “aumentar la cobertura de las pruebas software al 90 %”. Una vez que estos
cambios necesarios se implementen, el proceso debe ser reevaluado y medido para
comprobar la efectividad de los cambios.
Existen cinco etapas claves en el proceso de cambio de un proceso, tal y como
se muestra en la figura 4.3.

Identificación de mejoras. Esta etapa utiliza los resultados del proceso

9
 mejoras mejoras al proceso

ingenieros

Modelar Modelo de proceso

proceso capacitaci´on revisado

Figura 4.3: Proceso de cambio de procesos

de análisis para identificar maneras de atajar problemas de calidad, cuellos

de botella en la planificación o ineficiencias en los costes. Se pueden pro-
poner nuevos procesos, métodos y herramientas que afronten los problemas
identificados. Por ejemplo, si una empresa detecta que tiene problemas en la
identificación de requisitos podr´ıa introducir nuevas prácticas de recopilación
de requisitos software o establecer algú n método existente [70].
Priorización de las mejoras. Cuando se detectan múltiples puntos de me-
jora, en ocasiones, resulta imposible implementarlos todos al mismo tiempo.
Esta etapa busca ordenarlos de acuerdo al potencial impacto y coste que
supondr´ıa implantar cada uno de ellos.
Introducción del cambio. Etapa en la que se pone en funcionamiento
los nuevos procedimientos, métodos y herramientas y se integra con las ya
existentes.
Entrenamiento. Esta etapa es clave para el éxito del cambio introducido,
si no se entrena a los involucrados en el proceso cómo deben modificar su
flujo de trabajo para adaptarse al cambio o no lo entienden el resultado del
cambio puede no ser el esperado.
Ajuste. Habitualmente el cambio introducido necesita ser alterado de uno
u otra forma para minimizar pequeñ os problemas que suelen aparecer una
vez implantado. Esta etapa puede durar varias semanas o meses.

No es recomendable introducir muchos cambios al mismo tiempo. Obviando

el coste de formación de los cambios, introducir muchos cambios supone que la
evaluación del resultado sea compleja o imposible. Si dos cambios tienen efectos
opuestos, uno por ejemplo permite reducir a la mitad el tiempo en el que se realizan
las pruebas software y el otro multiplica por dos ese tiempo, no se percibirá mejora
alguna en el proceso resultante, y no se detectará cual es el proceso que realmente
aporta una mejora real.
Además de la dificultad en la evaluación de la efectividad de los cambios in-
troducidos, existen otros dos factos m á s a tener en cuenta.

1. Resistencia al cambio. No es raro encontrarse con reticencias a la hora

de implantar un cambio por parte de las personas afectadas. En un primero

10
 momento es normal recibir todo tipo de razonamientos acerca de porqué el
cambio no funcionará o por q ué no tiene sentido.

2. Persistencia del cambio. Aunque un cambio se introduzca con éxito en

un principio no es extrañ o que pasado un tiempo este sea reconsiderado y
descartado, regresando al punto de partida.

La resistencia al cambio puede proceder tanto de los directores y jefes de pro-

yecto como del resto del personal. Directores y jefes de proyecto suelen resistirse a
cambios en el proceso pues cualquier cambio conlleva consigo un riesgo asociado.
Por otro lado, si el cambio necesita de un periodo largo de implantación para ata-
jar una ineficiencia, el coste total a asumir puede no compensar el esfuerzo y por
tanto ser descartado. El análisis entre el riesgo a asumir y el beneficio potencial
del cambio es la principal razón por la que un director o jefe de proyecto rechace
la implantación de un cambio en un proceso.
Los ingenieros y resto del personal tienden a rechazar cambios que afecten a
sus competencias o perciban que menoscaban sus funciones y que en último caso
les hagan prescindibles.
La tarea del director de proyecto debe ser la de velar por facilitar que todo
el mundo implicado en el proyecto perciba los cambios en el proceso como algo
natural y beneficioso, despejando dudas e involucrando a todos los miembros del
proyecto afectados.
En ciertas ocasiones los cambios en los procesos vienen motivados gracias al
impulso personal de algú n miembro de la organización, lo que se conoce como
“evangelizador”. Este “evangelizador” es un firme convencido del cambio y hace
todo lo posible para que el cambio llegue a introducirse. Sin embargo, cuando este
“evangelizador” abandona el proyecto o la organización es frecuente que el cambio
introducido sea sometido a reconsideración y la situación anterior reinstaurada.
Esto es particularmente cierto cuando el cambio no ha sido establecido a lo largo de
la organización y se percibe como una extravagancia de un determinado proyecto.
El problema de la persistencia del cambio es uno de los puntos en los que
el marco CMMI pone toda su atención como veremos en las próximas secciones.
La institucionalización de los cambios se presenta como una forma de conseguir
que los cambios persistan m á s allá de un proyecto concreto o de una unidad de
producción en particular.

4.3. Qué es CMMI

CMMI es una aproximación a la mejora de procesos a través del empleo de
un conjunto de buenas prácticas utilizadas en la industria. Implementar CMMI
puede ayudar a afrontar situaciones no deseadas por las organizaciones tales como,
baja productividad, bajo rendimiento, costes no controlados, empeoramiento de
la calidad y de la satisfacción del cliente.
El modelo CMMI describe aquello que la organización deber´ıa hacer, pero no el
cómo lo deber´ıa hacer. El contexto empresarial de la organización debe ser quien

11
establezca como se implementan las prácticas propuestas. CMMI es un modelo
de mejora no de conformidad al que las organizaciones deban adherirse. CMMI
y sus métodos de evaluación permiten establecer una foto fija de la organización
que refleje el estado de los procesos existentes. A partir de esta foto fija el marco
de trabajo CMMI permite establecer una hoja de ruta para la mejora de estos
procesos que reduzca las diferencias en el desempeño de los procesos entre la
realidad medida y la ideal fijada por el modelo.
Es importante tener en cuenta q ué no es CMMI para evitar un uso incorrecto
del mismo:

No es un estándar o norma preceptiva que deba cumplirse.

No implica un trabajo extra dentro de la organización. Todas las organiza-

ciones se gu´ıan por procesos para la realización de proyectos, fabricación de
productos, la prestación de servicios o la realización de tareas diversas. La
preocupación principal de CMMI es que estos procesos se hagan de manera
formal de acuerdo a normas internas dentro de la organización que garanticen
su repetitividad.

No es una colección de procedimientos o procesos, sino que permite establecer

procesos repetitivos y efectivos dentro de la organización.

No es una “solución mágica” que pueda garantizar un aumento de la eficien-

cia en cualquier situación.

Es importante tener en cuenta que ningún modelo general podrá ser óptimo
para todas las organizaciones. CMMI simplemente pretende ser un modelo que gu´ıe
a la organización a establecer un proceso o conjunto de procesos lo m á s óptimos
posibles.

4.4. Modelo de Trabajo CMMI

CMMI fue desarrollado a partir del modelo CMM de mejorar de procesos por el
Instituto de Ingenier´ıa de Software conocido en inglés como Software Engineering
Institute y abreviado por SEI, ubicado en la Universidad Carnegie Mellon. El
SEI desarrolló un producto que contiene el modelo de mejora, los métodos de
entrenamiento asociados al modelo y los métodos de evaluación.
Inicialmente CMMI se compon´ıa de un ú nico modelo. Con el tiempo y gracias
al éxito y dado que ciertas disciplinas ten´ıan procesos únicos o con caracter´ısticas
singulares se desarrollaron tres modelos diferentes:

CMMI-DEV centrado en el desarrollo de proyectos software

CMMI-ACQ centrado en la adquisición o subcontratación de sistemas y

servicios software.

CMMI-SVC. centrado en la mejora de prestación de servicios software.

12
 Estos tres modelos se complementan entre s´ı en términos del público al que se
orientan. Existen varios componentes comunes a los tres modelos, incluyendo 16
á reas de interés denominadas “core process areas”. Cada modelo CMMI también
incluye á reas espec´ıficas a cada modelo.

4.4.1. CMMI-DEV

El modelo CMMI para desarrollo o CMMI-DEV fue el primero en ser desa-

rrollado, y el modelo de interés para este TFM. El objetivo de CMMI-DEV es
el de mejorar los procesos de desarrollo e ingenier´ıa en aquellas organizaciones
dedicadas al desarrollo de productos. Aunque CMMI est á ligado a la industria
software, el modelo CMMI-DEV puede ser usado en cualquier tipo de industria
que produzca cualquier tipo de bien o producto.

4.4.2. CMMI-ACQ

El modelo CMMI para adquisición es utilizado para mejorar los procesos de

gestión de proveedores en organizaciones con múltiples suministradores
El modelo de adquisición ayuda a las organizaciones a desarrollar requisitos,
seleccionar proveedores y obtener servicios y productos.
CMMI-ACQ es ampliamente utilizado por organizaciones gubernamentales en
los procesos de adquisición de productos y servicios y en la industria automotriz
para la selección de proveedores.

4.4.3. CMMI-SVC

El ú ltimo modelo en incorporarse al marco CMMI es CMMI-SVC orientado a

servicios.
El objetivo de CMMI-SVC es el de ser utilizado como mejora de los procesos
de gestión y suministro de servicios en organizaciones que desarrollen, gestionen
o suministren servicios.
CMMI-SVC puede ser utilizado por cualquier organización que preste servicios.
Entre las industrias que m á s han utilizado este modelo están las telecomunicacio-
nes, empresas de suministro de energ´ıa, empresas de IT, call-centers etc.

4.5. Beneficio Potencial de CMMI

Las organizaciones difieren unas de otras en sus objetivos estratégicos, pro-
yectos o servicios. Esto sucede a ú n incluso cuando se trate de organizaciones
pertenecientes al mismo sector. Estas variaciones crean diferencias en como las
organizaciones deben implementar la mejora de procesos mediante CMMI y de
igual forma como deberán medir los resultados y el progreso obtenido durante y
al finalizar la implantación de CMMI.

13
 Categor´ıa Media de mejora
Coste 34 %
Plazos 50 %
Productividad 61 %
Calidad 48 %
Satisfacción de cliente 15 %
Retorno de inversión 4:1

Cuadro 4.3: Mejoras obtenidas por categor´ıas.

Durante el proceso de mejora de procesos las organizaciones incurrirán en cos-

tes. Las inversiones realizadas en este proceso de mejora deben resultar en un
aumento de la capacidad de los procesos y en la madurez de la organización. Estos
beneficios pueden ser observados en el medio y largo plazo en forma de reduc-
ción de costes, plazos, productividad, calidad, satisfacción de usuario y de otras
caracter´ısticas.
El CMMI Institute ha realizado diversos estudios para evaluar el impacto que
tiene la adopción de CMMI en las organizaciones. En la tabla 4.3 se muestran los
datos obtenidos en cuanto a la mejora media obtenida en diferentes categor´ıas.

4.6. Á reas de Proceso CMMI

Las áreas de proceso o process areas (PAs) son un conjunto de prácticas relacio-
nadas en un á rea que, cuando se implementan de manera colectiva, satisfacen un
conjunto de objetivos considerados importantes para hacer mejorar esa área. Las
á reas de procesos tienen una estructura consistente a lo largo de los tres modelos.
Cada una de estas áreas de proceso incluye:

Objetivos considerados importantes para un á rea de negocio. Por ejemplo,

el área de proceso de gestión de requisitos contiene todas las prácticas re-
lacionadas con la gestión de requisitos, el seguimiento de los cambios de
requisitos, y el control de los cambios.
Prácticas.
Material informativo.

En la figura 4.4 se muestra el diagrama con la estructura utilizada por cada

á rea de proceso en CMMI. Cada PA comienza con una breve introducción que
describe su propósito seguida de unas notas introductorias
CMMI incluye dos tipos de objetivos para cada área de proceso, por un lado,
una serie de objetivos genéricos a todas las á reas de proceso y por otro un con-
junto de á reas espec´ıficas a cada una de ellas. Cada objetivo, ya sea genérico o
espec´ıfico, tiene asociado un conjunto de subprácticas con el fin de proveer de una
comprensión m á s profunda de la intención de dicha práctica. En el caso de las
prácticas espec´ıficas, CMMI identifica ejemplos reales de productos o resultados
de las prácticas para guiar mejor el objetivo del PA.

14
 Figura 4.4: Esquema del área de proceso CMMI

Cada área de proceso comienza con estos componentes

Propósito. Es un enunciado breve que resume el objetivo o propósito del

á rea de proceso en cuestión. Debe ser una frase directa que transmita de
forma clara y concisa la idea del PA.

Notas introductorias. Consiste normalmente de varios párrafos que desa-

rrollan la idea tras el propósito expuesto anteriormente. Es una forma de
resumen ejecutivo del PA que describe la intención del PA e incluye ciertas
gu´ıas de las prácticas involucradas den este PA.

Á reas de proceso relacionadas. Es habitual que un PA se relacione con

otras de una forma u otra, por tanto, se incluye una sección que liste aquellas
otras PA que están fuertemente relacionadas. Normalmente no es un listado
exhaustivo y solo se listan las PA con mayor relación.

Objetivo especı́fico y Resumen de prácticas. Cada objetivo y práctica

asociada tienen un t´ıtulo y un enunciado asociado.

4.6.1. Objetivo Especı́fico (SG)

El objetivo espec´ıfico (SGs) es un componente del modelo requerido que des-

cribe las caracter´ısticas ú nicas que deben estar presentes para satisfacer un á rea
de proceso.
Por ejemplo, en el PA “gestión de requisitos” se establece un ú nico objetivo
espec´ıfico: “SG 1: Los requisitos deben ser gestionados y las inconsistencias de
estos con el plan de proyecto identificadas”.

15
 Los objetivos espec´ıficos se identifican mediante el prefijo “SG” seguido por un
nú mero de forma secuencial.

4.6.2. Prácticas Especı́ficas

Las prácticas espec´ıficas (SPs) son actividades consideradas importantes para

conseguir los objetivos espec´ıficos asociados. Por ejemplo, para el caso anterior
de gestión de requisitos: “SP 1.3: Gestionar los cambios de requisitos durante la
ejecucion del proyecto”.
Al igual que con los objetivos las prácticas se identifican mediante el prefijo
“SP” seguidas de dos números separadas por un punto, el primer nú mero hacer
referencia al objetivo que cubre la práctica mientras que el segundo nú mero es el
nú mero de la práctica asignado de manera consecutiva.
Las prácticas espec´ıficas suelen incluir dos tipos de componentes:

Una lista de ejemplos funcionales. Esta lista representa los resultados

que se pueden esperar encontrar en una organización que haya ejecutado
estas prácticas. Los ejemplos no son elementos necesarios y no tienen por
q ué ser aplicables en otras organizaciones, tan solo muestran ejemplos t´ıpicos
e ideas que puedan ayudar a poner en marcha la práctica espec´ıfica a la que
acompañan.

Subprácticas. Proveen un grado de detalle mayor al descrito por la práctica

y pueden contener un listado de pasos t´ıpicos para completar la práctica
espec´ıfica.

4.6.3. PA en los modelos CMMI

En los tres modelos CMMI (CMMI-DEV, CMMI-ACQ y CMMI-SVC) existen

un total de 16 áreas de procesos centrales o core process areas comunes:

Causal Analysis and Resolution (CAR)

Configuration Management (CM)

Decision Analysis and Resolution (DAR)

Integrated Project Management (IPM)

Measurement and Analysis (MA)

Organizational Process Definition (OPD)

Organizational Process Focus (OPF)

Organizational Performance Management (OPM)

Organizational Process Performance (OPP)

16
 Organizational Training (OT)
Project Monitoring and Control (PMC)
Project Planning (PP)
Process and Product Quality Assurance (PPQA)
Quantitative Project Management (QPM)
Requirements Management (REQM)
Risk Management (RSKM)

En CMMI-DEV existen además 5 á reas de procesos espec´ıficas:

Product Integration (PI)

Requirements Development (RD)
Technical Solution (TS)
Validation (VAL)
Verification (VER)

M á s otra á rea de procesa compartida con CMMI-SVC: SAM (Supplier Agree-

ment Management). En CMMI-SVC además de la citada área de procesos com-
partida con CMMI-DEV existen otras 6 áreas de procesos espec´ıficas má s otra
adicional:

Capacity and Availability Management (CAM)

Incident Resolution and Prevention (IRP)
Service Continuity (SCON)
Service Delivery (SD)
Service System Development (SSD)
Service System Transition (SST)
Strategic Service Management (STSM)

Por último, en CMMI-ACQ existen 6 á reas espec´ıficas:

Acquisition Requirements Development (ARD)

Solicitation and Supplier Agreement Development (SSAD)
Agreement Management (AM)
Acquisition Technical Management (ATM)
Acquisition Verification (AVER)
Acquisition Validation (AVAL)

17
4.6.4. Objetivos genéricos (GG)

Los objetivos genéricos describen caracter´ısticas que demuestren la institu-

cionalización del proceso en un á rea de proceso dada. Mientras que los procesos
espec´ıficos aplicaban solo a un área de procesos, los objetivos genéricos aplican a
todas las á reas.
El propósito de los objetivos genéricos es que una vez implementados estos
permitan hacer sostenibles en el tiempo a los objetivos espec´ıficos. Sin la insti-
tucionalización de los objetivos genéricos hay una alta probabilidad de que las
prácticas espec´ıficas se abandonen en momentos de alta exigencia de la organiza-
ción.
Los objetivos genéricos se nombran en la misma forma que los objetivos es-
pec´ıficos, comienzan con el prefijo GG seguido de un número.

4.6.5. Prácticas Genéricas (GPs)

Las prácticas genéricas son las actividades consideradas importantes o necesa-

rias para lograr el objetivo genérico al que se asocian. Su carácter genérico implica
que estas prácticas aparecerán en múltiples áreas de proceso. Un ejemplo de prácti-
ca genérica es: “GP 2.5: Entrenar adecuadamente al personal involucrado en el
proceso”, y que estar´ıa asociada con el á rea de proceso de entrenamiento de la
organización (OT).
Las prácticas genéricas siguen el mismo esquema de numerado. Se emplea
el prefijo GP seguido de dos números separados por un punto, donde el primer
nú mero hacer referencia al objetivo genérico asociado y el segundo nú mero a la
práctica genérica correspondiente.
Las prácticas genéricas están formadas t´ıpicamente por dos componentes:

Elaboraciones de Prácticas Genéricas. Proporcionan una gu´ıa sobre cómo

deben aplicarse la práctica genérica a un á rea de proceso espec´ıfica. Son
ejemplos de aplicación.

Subprácticas.

4.6.6. Información Adicional

Además de proporcionar objetivos y prácticas tanto espec´ıficas como genéricas,

los modelos CMMI también proporcionan otro tipo de información complemen-
tar´ıa.

Ejemplos. Normalmente en forma de lista de hitos, pasos, o elementos a

tener en cuenta o que puede ser utilizados para facilitar la consecución de
un objetivo o llevar a cabo de una práctica o subpráctica.

18
 Referencias. Al comienzo de cada PA se proporciona una lista de otras PA
relacionadas. Esta lista no es exhaustiva, pero muestra las relaciones m á s
importantes.

Notas. Son aclaraciones, muy útiles para comprender mejor y en profundi-

dad el objetivo, la práctica o subpráctica a la que hagan referencia. Suelen
aclarar la intención que es esconde detrás y dar una visión de conjunto dentro
del modelo del elemento al que hacen referencia.

4.7. Descripción Á reas de Proceso

A continuación, pasaremos a describir en detalle cada á rea de proceso perte-
neciente al modelo CMMI-DEV.

4.7.1. Requirements Management (REQM)

El propósito de la gestión de requisitos es identificar, asignar y hacer segui-

miento de los requisitos necesarios para satisfacer los objetivos del proyecto. La
gestión de requisitos es fundamental, una buena gestión de requisitos impacta muy
positivamente en el proyecto ya que facilita el buen desempeño de los procesos y
actividades siguientes. Es importante darse cuenta que las organizaciones no pue-
den gestionar a sus clientes, pero si puede gestionar los requisitos que reciben de
ellos. Además, añ adir rigor al proceso de gestión de requisitos genera una me-
jor compresión de los requisitos, facilita la gestión de los cambios de requisitos, y
permite asegurar que el proyecto permanece consistente a los requisitos del cliente.
Existe un ú nico objetivo espec´ıfico para la gestión de requisitos, ver tabla 4.4.
Existen 5 prácticas espec´ıficas asociadas con el primer objetivo. SP 1.1 estable-
ce que la organización consiga alcanzar un conocimiento profundo de los requisitos
solicitados en el proyecto. Una vez alcanzado este conocimiento, todos los invo-
lucrados deben tomar la responsabilidad de comprometerse con una parte de los
requisitos. Los requisitos evolucionarán a lo largo del proyecto, bien por necesida-
des que irá n surgiendo desde el punto de vista técnico o por necesidades surgidas
por parte del cliente. Cuando los cambios suceden la organización debe asegurar
que estos son gestionados (SP 1.3). Segú n vayan produciéndose cambios, la SP 1.4
se asegura que estos son traceables y que esta trazabilidad se mantenga a lo largo
del proyecto. Los cambios de requisitos provocan a menudo desincronización den-
tro del proyecto, mientras que parte del equipo está trabajando con una versión de
los requisitos (por ejemplo, el equipo de desarrollo) otro equipo puede estar tra-
bajando con versiones anteriores (por ejemplo, el equipo de pruebas) originando
ineficiencias. SP 1.5 se asegura que estas inconsistencias no existen.

4.7.2. Project Planning (PP)

El propósito de PP es “establecer y mantener planes que definan las actividades

del proyecto”. Incluye el desarrollo del plan de proyecto, identificar e involucrar a

19
 Los requisitos son gestionados y las inconsistencias con
el plan de proyecto y los productos de trabajo identifi-
cadas.

Cuadro 4.4: Á rea de proceso: Requirements Management (REQM)

todos los afectados relevantes por el proyecto (stakeholders), obtener compromiso

para llevar a cabo dicho plan, y mantener el plan actualizado cuando este se vea
modificado por cambios en los requisitos.
El plan de proyecto cubre varias actividades de gestión e ingenier´ıa, as´ı como
de otros planes subordinados y compromisos con otros grupos.
Se establecen tres objetivos espec´ıficos para el PP, ver tabla 4.5.
Asociadas a los 3 objetivos espec´ıficos tenemos 4 prácticas asociadas para el
SG 1, 7 para el SG 2 y 3 para el SG 3.
En SP 1.1 se establece la estructura de descomposición de trabajos EDT o
también conocida en inglés como work breakdown structure (WBS) para poder
as´ı estimar el alcance del proyecto. La WBS proporciona una referencia y es uti-
lizada como l´ınea base para planificar, organizar y controlar el trabajo hecho en
el proyecto. La WBS inicial es normalmente un documento de alto nivel que pro-
porciona un marco inicial de trabajo que es completado con m á s detalle en tareas
futuras a medida que el proyecto se desarrolla. SP 1.2 busca determinar cuánto
trabajo debe ser empleado en cada paquete de trabajo identificado en la WBS,
para ello se pueden utilizar diferentes métricas como nú mero de páginas, funcio-
nes, tamañ o o complejidad. La información obtenida en SP 1.2 es empleada en 1.4
para poder estimar los costes en función de la cantidad de trabajo, normalmente
basándose en modelos existentes que tienen en cuenta parámetros históricos como
número de actividades, tamaños, complejidades, etc. En SP 1.3 se definen las fases
del proyecto dependiendo del nú mero de requisitos, las estimaciones y la natura-
leza del proyecto. En proyectos de gran tamañ o es normal que las diferentes fases
del proyecto sean a su vez divididas en sub-fases.
En cuanto al desarrollo del plan de proyecto, SP 2.1 establece el presupuesto
y los plazos de acuerdo a la cantidad de trabajo y la WBS fijados durante el
desarrollo de SG 1. Los riesgos del proyecto son identificados en SP 2.2. En SP
2.3 se desarrolla un plan para la gestión de los datos asociados al proyecto. Los

20
 Establecer estimadores
Se establecen una serie de estimadores de parámetros
de proyecto que se mantendrán a lo largo de la vida del
proyecto

SP 1.1 Estimar el alcance del proyecto

SG1
SP 1.2 Establecer una estimación del trabajo y las
tareas a realizar
SP 1.3 Definir las fases del ciclo de vida del proyecto
SP 1.4 Estimar los costes

Desarrollar plan de proyecto

Se establece un plan de proyecto como base para la ges-
tión del proyecto

SP 2.1 Establecer el calendario y los costes del pro-

yecto
SP 2.2 Identificar los riesgos
SG2 SP 2.3 Planificar la gestión de datos
SP 2.4 Planificar los recursos del proyecto
SP 2.5 Planificar las habilidades y conocimientos ne-
cesarios
SP 2.6 Planificar la participación de los involucrados
SP 2.7 Establecer el plan de proyecto

Obtener compromisos con el plan de proyecto

Los compromisos con el proyecto son establecidos y man-
tenidos durante el ciclo de vida del proyecto

SP 3.1 Revisar los planes que puedan afectar al pro-

SG3 yecto
SP 3.2 Poner de acuerdo el trabajo y los recursos
compartidos
SP 3.3 Obtener compromiso de acuerdo para el plan
de proyecto

Cuadro 4.5: Á r ea de proceso: Project Planning (PP)

21
datos pueden aparecer de muchas maneras y medios. Se deben identificar los datos
y fuentes de información claves para gestionar el proyecto de manera eficiente.
En SP 2.4 se definen los recursos necesarios para llevar a cabo el proyecto. Los
recursos incluyen, personal, herramientas, materiales e instalaciones. En ocasiones
es necesario un conjunto de conocimientos o habilidades especiales para llevar a
cabo el trabajo, SP 2.5 se asegura que estos son incluidos en el plan. En SP 2.6
se asegura que los involucrados son identificados correctamente de acuerdo a su
relevancia en el proyecto, su rol, su necesidad y dónde deben participar. Todos
estos elementos son empleados para crear un plan en SP 2.7, este plan es conocido
como plan de proyecto y será utilizado para llevar a cabo la monitorización y
control del proyecto.
Una vez el plan es documentado, se busca el compromiso de la organización
para llevarlo a cabo. Antes de obtener el compromiso se debe verificar en SP 3.1,
que el plan de proyecto no interfiere en otros planes, por ejemplo, si se el plan
necesita de una instalación y esta debe ser compartida con otro proyecto. En SP
3.2 se establece que los recursos y el trabajo a realizar están equilibrados de forma
realista y por tanto el proyecto es viable desde este punto de vista. Por último,
SP 3.3 obtiene un compromiso por parte de todos los involucrados para llevar a
cabo el proyecto.

4.7.3. Project Monitoring and Control (PMC)

El propósito de la monitorización y control es dotar un conocimiento acerca

del progreso del proyecto de tal forma que se puedan tomar acciones correctivas
en caso de que el proyecto se desv´ıe significativamente del plan inicial.
Se establecen dos objetivos espec´ıficos para llevar a cabo la monitorización y
el control.
Los objetivos espec´ıficos asociadas a ambos objetivos espec´ıficos se detallan en
la tabla 4.6. Las cinco primeras prácticas espec´ıficas del SG 1 hacen referencia a
la monitorización de los elementos definidos en el plan de proyecto. Comienza en
SP 1.1 monitorización el trabajo completado, el esfuerzo gastado, el presupuesto
consumido, los plazos completados y los recursos empleados. SP 1.2 monitoriza
que los compromisos asumidos por el proyecto son alcanzados. SP 1.3 monitoriza
los riesgos. SP 1.4 monitoriza y verifica que el personal tiene acceso a los datos
que necesita en todo momento y estos son gestionados apropiadamente. SP 1.5
se encarga de monitorizar que los compromisos asumidos por cada participante
del proyecto se cumplen. Las dos últimas prácticas SP 1.6 y 1.7 tratan de las
revisiones del proyecto y de los hitos cumplidos. El nú mero y el tipo de estas
revisiones depende enormemente del tipo de negocio y proyecto.
Al mismo tiempo que se monitoriza en el SG 1 el avance del proyecto se detectan
desviaciones respecto al plan original del proyecto. En SG 2 se establecen las
prácticas necesarias para corregir estas desviaciones. En SP 2.1 se analizan los
problemas y se definen las acciones a tomar para corregir estos problemas. Las
acciones correctivas se ponen en práctica en SP 2.2 y son seguidas y gestionadas
hasta su finalización en SP 2.3. Es importante que las acciones correctivas tengan
fechas l´ımites para su finalización y que la monitorización se haga hasta el final.

22
 Se monitoriza y compara el progreso y el del
proyecto real y se compara contra el plan inicial

SP 1.1 Monitorizar los del proyecto o tra-

bajo

Cuadro 4.6: Á rea de proceso: Project Monitoring and Control (PMC)

23
 Los riesgos son identificados y analizados para determi-
nar su importancia

Cuadro 4.7: Á rea de proceso: Risk Management (RSKM)

4.7.4. Risk Management (RSKM)

El objetivo de la gestión de requisitos es identificar problemas potenciales antes

de que lleguen a producirse de forma que se puedan planear acciones y actividades
que minimicen o palien estos riesgos. Existe una diferencia entre riesgos y proble-
mas, un problema es algo que ya ha sucedido y que provoca un dañ o o pérdida,
mientras que un riesgo es algo que potencialmente podr´ıa ocurrir y provocar un
dañ o o pérdida. Las actividades de gestión de riesgos deben abordar aquellas ca-
su´ısticas que puedan poner en peligro la consecución de objetivos cr´ıticos para
lograr el éxito del proyecto. Una buena gestión de riesgos para por tener en cuen-
ta tanto fuentes de riesgos externas e internas a la organización en cualquier eje
importante del proyecto: plazo, coste y calidad. La detección temprana de riesgos
suele ayudar a que, en caso de producirse un dañ o o pérdida motivada por el riesgo
detectado, éste tenga menor impacto en términos de coste o plazo.
Se definen 3 objetivos espec´ıficos para este PA. Este patrón es seguido por otras
PA a lo largo del marco de trabajo de CMMI, el primero objetivo suele establecer
las herramientas y estrategias necesarias para ejecutar la tarea, mientras que las
siguientes son objetivos de tareas.
Las prácticas espec´ıficas para los 3 objetivos se muestran en la tabla 4.7. En SP
1.1 la organización debe identificar fuentes y categor´ıas de riesgos comunes. Esta
lista de riesgos puede facilitar al proyecto un conocimiento ya adquirido de riesgos

24
comunes de forma que pueda servir de base en la evaluación de riesgos del proyecto.
En SP 1.2 se establece una serie de parámetros de riesgo para poder evaluar,
categorizar y priorizar los riesgos. Estos parámetros incluyen la probabilidad de
riesgo, las consecuencias o severidad de los riesgos y los umbrales a los que el riesgo
debe ser gestionado. La estrategia global de riesgos es finalmente definida en SP
1.3. Esta estrategia pasa por los métodos y herramientas utilizadas, las fuentes de
riesgo espec´ıficas al proyecto, y cómo son los riesgos organizados, categorizados y
priorizados.
En SG 2, las fuentes y categor´ıas de SG 1 son empleadas para identificar riesgos
en SP 2.1. Los riesgos deben ser identificados y descritos de forma comprensible
y clara antes de que puedan ser analizados y gestionados adecuadamente. En SP
2.2, los parámetros definidos en SG 1 son utilizados para evaluar, categorizar y
priorizar riesgos. El riesgo puede ser priorizado como alto, medio o bajo
La estrategia definida en SG 1 es utilizada para desarrollar planes de mitigación
de riesgos en SP 3.1. Un componente cr´ıtico en la planificación de mitigación de
riesgos es el desarrollo de caminos alternativos de acción, soluciones temporales o
métodos de respaldo y caminos recomendados de acción para cada riesgo. El plan
de mitigación de riesgos para un riesgo dado incluye técnicas y métodos utilizados
para evitar, reducir y controlar la probabilidad de que el riesgo ocurra. Es impor-
tante tener en cuenta que la mitigación de riesgos aplica a una serie de riesgos
seleccionados, no es viable el desarrollo de un plan de acción para todos los riesgos
posibles. Los planes deben realizarse para aquellos riesgos con mayor probabilidad
de ocurrir o de consecuencias m á s catastróficas. Los riesgos son monitorizados de
manera periódica en SP 3.2 y los planes de mitigación implementados a lo largo
de la vida del proyecto segú n las necesidades.

4.7.5. Supplier Agreement Management (SAM)

Esta PA es compartida por CMMI-DEV y CMMI-SVC y tiene como objetivo

gestionar la adquisición de productos y servicios de un suministrador por parte de
una organización.
El término suministrador se emplea para identificar a una organización externa
al proyecto que desarrolle, produzca, pruebe y de soporte a un producto o servicio
que es entregado a un cliente. El suministrador puede encontrarse dentro de la
organización que patrocina el proyecto, pero ser ajeno al proyecto. Las actividades
con el suministrador deben ser regidas por un acuerdo formal. Los acuerdos con
proveedores podrán tomar forma de contratos, licencias o acuerdos de nivel o
calidad de servicio.
Se definen dos objetivos espec´ıficos, tal y como se muestra en la tabla 4.8.
Los suministradores son seleccionados en el SG 1 y los acuerdos establecidos y
cerrados. En SG 2 el acuerdo se pone en práctica, es importante tener en cuenta
que es un acuerdo de igual a igual y por tanto las exigencias son las mismas en
ambas direcciones.
La tabla 4.8 muestra las prácticas especificas asociadas a SG 1 y SG2. En pri-
mer lugar, en SP 1.1 se determina q ué tipo de adquisición se realizará para adquirir

25
 Se establecen y mantienen acuerdos con proveedores

proveedores

Los acuerdos con proveedores deber ser satisfechos por

ambas partes, el proveedor y quien ejecuta el proyecto

Cuadro 4.8: Á rea de proceso: Supplier Agreement Management (SAM)

productos y servicios. El tipo de adquisición incluye el uso de componentes Com-

mercial off-the-shelf (COTS) o de servicios de proveedores externos o internos. En
SP 1.2 se seleccionan los proveedores de acuerdo a su capacidad para satisfacer los
requisitos especificados para el producto o servicio a adquirir. Tras la selección del
proveedor o proveedores se establecen acuerdos comerciales que establecen como
ser efectúa la revisión, monitorización y los criterios de aceptación de los entrega-
bles del suministrador. Todo aquello no contemplado en el acuerdo comercial no
debe ser contemplado que suceda en un futuro. Es importante incluir en el acuerdo
todo lo necesario para poder gestionar al proveedor y recibir el producto o servicio
esperado.
En la SP 2.1 se ejecutan los acuerdos establecidos en el SP 1.3. En SP 2.2 se
comprueba que el producto o servicio cumple con los requisitos establecidos en el
acuerdo antes de que sea entregado al cliente en el SP 2.3.

4.7.6. Configuration Management (CM)

Tiene como propósito establecer y mantener la integridad de los productos de

trabajo utilizando la identificación de la configuración, el control de configuración,
el registro del estado de configuración y las auditor´ıas de configuración.
Existen tres objetivos espec´ıficos relacionados con CM, el primer objetivo SG
1 establece la l´ınea base y el sistema de gestión de configuración que será utilizado
en SG 2 y SG 3. SG 2 se asegura que los cambios a los productos de trabajo están
controlados mientras que SG 3 requiere que las entradas de gestión de configura-
ción sean guardadas y su integridad conservada.
Asociados a los objetivos tenemos una serie de prácticas espec´ıficas. SP 1.1
identifica los elementos de configuración que serán controlados. Algunos ejemplos

26
 Las l´ıneas base de los productos de trabajo son estable-
cidas.

SP 1.1 Identificar los elementos de

mentos de

figuraci

SG3 criben los elementos de

fi
mantener la integridad de las l´ıneas base de confi-

Cuadro 4.9: Á rea de proceso: Configuration Management (CM)

27
de elementos de configuración a controlar son: documentos de diseñ o, descripción
de servicios, materiales de formación, planes de pruebas, diseñ os técnicos y código
fuente. Una vez los elementos a controlar son identificados, SP 1.2 establece un sis-
tema para gestionar la configuración de esos elementos. Un sistema de gestión de
configuración incluye los medios de almacenaje, procedimientos, y las herramien-
tas para acceder al sistema. El sistema de gestión de configuración es utilizado
para crear las l´ıneas base de los elementos a controlar en SP 1.3. Una l´ınea ba-
se representa una foto fija en el tiempo de la versión de configuración o de un
conjunto de elementos de configuración.
La petición de cambios de configuración es analizada en SP 2.1 para determinar
el impacto del cambio en el trabajo en curso, en los trabajos relacionados, en el
presupuesto y en los plazos. Las peticiones de cambio son priorizadas, asignadas
y seguidas hasta la finalización. SP 2.2 mantiene la l´ınea base de configuración.
Se establecen mecanismos para controlar q ué se está cambiando, quien lo está
cambiando, por q ué se est á cambiando y el estado del cambio.
Los registros de los cambios se establecen y gestionan en SP 3.1. En SP 3.2 se
garantiza la fiabilidad de los registros, su consistencia y completitud.

4.7.7. Process and Product Quality Assurance (PPQA)

El propósito del Aseguramiento de la Calidad de Proceso y Producto es propor-

cionar a los diferentes equipos y a la gerencia una visión objetiva de los procesos y
productos asociados. El objetivo fundamental de PPQA es garantizar que los pro-
cesos definidos están siendo respetados en la organización, as´ı como poder detectar
deficiencias en la forma de trabajar establecida. La objetividad es el elemento cla-
ve de PPQA. Aquellos miembros de la organización involucrados en PPQA deben
separase de quienes se dedican al desarrollo del producto o llevan a cabo el pro-
yecto. Se debe facilitar un medio de comunicación apropiado entre ambas á reas y
los niveles de gestión para que los temas de no conformidad puedan ser tratados.
Existen dos objetivos espec´ıficos asociados con PPQA. SG 1 establece que
tanto los procesos llevados a cabo como los resultados de los mismos deben ser
objetivamente evaluados partiendo de las descripciones de proceso y los estándares
establecidos. SG 2 aborda los temas de no conformidad detectados durante la
validación y verificación del proceso.
Tanto SG 1 como SG 2 tienen asociadas cada uno dos prácticas espec´ıficas. SP
1.1 se concentra en la evaluación objetiva de los procesos llevados a cabo, verifi-
cando que cumplen con las descripciones de proceso asociadas, los procedimientos
establecidos y los estándares utilizados. Esto va m á s allá de la simple inspección
de los resultados obtenidos tras aplicar el proceso, tarea que se realiza en SP 1.2.
SG 2 se centra en la evaluación objetiva de los resultados. En SP 2.1 las no
conformidades detectadas son comunicadas a los niveles adecuados de gestión para
su planificación. Las no conformidades son monitorizadas para asegurar que estas
son resueltas. Tanto las no conformidades como la solución o soluciones aplicadas
se documentan en SP 2.2.

28
 La adherencia de los procesos realizados, y de los pro-
ductos de trabajo asociados a las descripciones de pro-
ceso y procedimientos aplicables es evaluada

Las no conformidades son seguidas y comunicadas obje-

tivamente, y su es asegurada

Cuadro 4.10: Á rea de proceso: Process and Product Quality Assurance (PPQA)

4.7.8. Measurement and Analysis (MA)

Tiene como propósito desarrollar y apoyar la capacidad de medición utiliza-

da para poder dar soporte a las necesidades de información de la gerencia. Los
directores tienen siempre la necesidad de contar con herramientas de medición
que les permitan tomar decisiones en función del estado actual. La calidad de las
mediciones es muy importante. Contar con mediciones inapropiadas puede causar
la toma de decisiones que pongan en riesgo el éxito del proyecto. Las medidas no
proporcionan respuestas en s´ı mismas, pero si pueden ayudar a que los directores
se hagan las preguntas adecuadas acerca del estado y rumbo del proyecto. Estable-
cer mediciones de los procesos permite establecer registros históricos que ayuden
en evaluar la evolución de la madurez de la organización.
MA tiene dos objetivos espec´ıficos. En SG 1 se establecen los objetivos a medir
y la especificación de las medidas y procedimientos a llevar a cabo para recopilar,
almacenar y analizar dichas medidas. SG 2 lleva a cabo las tareas especificadas en
SG 1.
Existen 4 prácticas espec´ıficas asociadas con SG 1. SP 1.1 espera que las nece-
sidades de información establezcan unos objetivos a medir. En SP 1.2 se toman las
medidas para lograr los objetivos especificados. Las medidas deben ser claramente
definidas de forma que todo el mundo reporte el mismo tipo de información. Los
métodos de recopilación de información son especificados en SP 1.3 con el fin de
asegurar que todo el mundo sigue la misma metodolog´ıa de recopilación y los datos
son coherentes entre las diferentes fuentes de información. Por último, se estable-
cen los procedimientos de análisis en SP 1.4 para evitar malinterpretaciones de los
datos o un uso inadecuado de los mismos.
SG 2 cuenta también con 4 prácticas espec´ıficas. SP 2.1 recopila los datos
de acuerdo con los procedimientos establecidos. Una vez recopilados los datos, se

29
 Alinear las actividades de y
Los objetivos de y las actividades son alineadas
con las necesidades y objetivos de identifi-
cados

recopilaci

SP 1.4 Especificar procedimientos de

Se proporcionan los resultados de las medidas llevadas

a cabo de acuerdo a las necesidades y objetivos identifi-
cados previamente

Cuadro 4.11: Á rea de proceso: Measurement and Analysis (MA)

30
 Las decisiones se basan en la de alternativas
utilizando un criterio previamente establecido

an

Cuadro 4.12: Á rea de proceso: Decision Analysis and Resolution (DAR)

analiza en SP 2.2 y se almacena en SP 2.3. Para finalizar, SP 2.4 comunica los

resultados y conclusiones obtenidos tras el análisis a los involucrados apropiados
para poder llevar a cabo tareas de decisión o actividades correctivas.

4.7.9. Decision Analysis and Resolution (DAR)

Tiene como propósito analizar las posibles decisiones utilizando un proceso de

evaluación formal que evalú a alternativas identificadas contra los criterios estable-
cidos. Una evaluación formal de procesos reduce la subjetividad de las decisiones y
conduce a una mayor probabilidad de seleccionar la solución m á s apropiada para
el mayor nú mero de involucrados en el proyecto. La intención de DAR es que sirva
de referente en la toma de las decisiones m á s importantes o cr´ıticas no en todas
las situaciones. Una de las ventajas de DAR es que se deja registro de todas las
decisiones, del q ué y del porqué de la decisión.
Se establece un ú nico objetivo espec´ıfico. SG 1 establece la necesidad de ex-
plorar todas las alternativas posibles, evaluándolas de acuerdo a algú n criterio
previamente establecido.
DAR es una herramienta que puede ser aplicada en multitud de casos y acti-
vidades, incluyendo planificación, presupuestos, arquitectura, diseñ o, selección de
suministradores, planificación de pruebas, log´ıstica y producción.
Las gu´ıas documentadas identifican cuando es necesario un proceso formal de
decisión e incluyen los pasos a seguir en la toma de decisiones. SP 1.1 establece
estas gu´ıas. SP 1.2 establece los criterios de evaluación a utilizar como base para
la evaluación de soluciones alternativas. Estas soluciones alternativas son identi-
ficadas en SP 1.3. SP 1.4 selecciona los métodos a utilizar a ser utilizados en la
evaluación de alternativas de acuerdo a los criterios de decisión. En SP 1.5 las al-
ternativas son comparadas y evaluadas de acuerdo a los criterios y empleando los
métodos de evaluación. Por último, en SP 1.6 se selecciona la solución o soluciones
de acuerdo a las prácticas anteriores.

31
 Las debilidades, fortalezas y oportunidades de mejora
son identificadas de manera o las nece-
sidades.

Las acciones que acometan las mejoras a los procesos de

la son planificadas e implementadas.

Los activos de proceso de la son difundidos

en la organizacion y las experiencias relativas a procesos
son incorporadas en los activos de proceso de la organi-

Cuadro 4.13: Á rea de proceso: Organizational Process Focus (OPF)

4.7.10. Organizational Process Focus (OPF)

Tiene como propósito planificar, implementar y desplegar las mejoras de proce-

sos de la organización, basadas en el entendimiento de las fortalezas y debilidades
actuales de los procesos y de los activos de proceso de la organización. Este proceso
establece la estrategia e infraestructura para el programa de mejora de procesos
de la organización. Los activos de los procesos de la organización son utilizados
para describir, implementar y mejorar los procesos de la organización. La organi-
zación debe asegurarse que las mejoras son puestas en marcha de forma efectiva
y gradual.
Existen tres objetivos espec´ıficos para OPF. El primer objetivo, SG 1, pasa
por identificar las fortalezas y debilidades de los procesos de la organización. Esta
información debe ser utilizada para detectar puntos susceptibles de mejora. SG 2

32
establece un plan y responsabilidades para la mejora de procesos. La implementa-
ción, el despliegue y la monitorización de la mejora de procesos es responsabilidad
de SG 3.
Existen 3 prácticas espec´ıficas relacionadas con SG 1. SP 1.1 requiere que la
organización identifique sus necesidades y objetivos de mejora. Estas necesidades
y objetivos deben establecerse de acuerdo a objetivos de negocio, necesidades
y restricciones. Antes de realizar ninguna tarea de mejora es preciso conocer el
estado de partida de la organización, esta tarea se realiza de forma periódica en
SP 1.2, identificando también fortalezas y á reas de mejora. Las fortalezas deben
ser potenciadas a lo largo de la organización mientras que las debilidades deben
ser corregidas. Las mejoras a los procesos de la organización y a los activos de los
procesos son identificados en SP 1.3.
Respecto al SG 2 se identifican dos prácticas espec´ıficas. En SP 2.1 se establecen
planes de acción para mejorar procesos de forma espec´ıfica, los cuales son aplicados
y monitorizados hasta su conclusión en SP 2.2
Los activos de procesos son creados como parte de los esfuerzos de mejora de
procesos de la organización. Una vez aprobados están listos para ser aplicados e im-
plementados. La organización los desplegará en SP 3.1 en una actividad concreta.
En 3.2 los proyectos y trabajos incorporan los nuevos procedimientos estandari-
zados. Con el tiempo se producirán actualizaciones y modificaciones que deberán
ser también introducidas. La organización se asegura que la institucionalización
y estandarización de los procesos es efectiva en SP 3.3. En SP 3.4 se incorporan
las experiencias relacionadas con el proceso derivadas de la planificación y de la
ejecucion de los procesos, en los activos de proceso de la organización.

4.7.11. Organizational Process Definition (OPD)

El propósito de OPD es establecer y mantener un conjunto de ventajas del

proceso organizacional y estándares de ambiente de trabajo. Una librer´ıa de ven-
tajas del proceso de la organización es una colección de elementos utilizados por
la gente y los proyectos de la organización. Esta colección de elementos incluye
descripciones de proceso y elementos de proceso, descripciones de los modelos del
ciclo de vida, gu´ıa para realizar un proceso, documentación relacionada al proceso
y datos.
Las ventajas del proceso organizacional son utilizadas para realizar la imple-
mentación del proceso definido. Los estándares del ambiente de trabajo son uti-
lizados para crear el ambiente de trabajo del proyecto. Un proceso estándar est á
compuesto de otros procesos o elementos de proceso. Un elemento de proceso es la
principal unidad de definición del proceso y describe las actividades y tareas nece-
sarias para realizar el trabajo. La arquitectura del proceso suministra reglas para
conectar los elementos del proceso pertenecientes a un proceso estándar. El con-
junto de procesos estándares de la organización puede incluir varias arquitecturas
de proceso.
Existe un ú nico objetivo en OPD. SG 1 requiere el establecimiento de un
conjunto de activos de procesos organizacionales.

33
 SP 1.6 Establecer de entorno de trabajo
SP 1.7 Establecer gu´ıas y normas para los equipos de
trabajo

Cuadro 4.14: Á rea de proceso: Organizational Process Definition (OPD)

Relacionados con el SG 1 existen 7 prácticas espec´ıficas. En SP 1.1 se establece

el conjunto de procesos estándar existentes en la organización. Los elementos de
los procesos estándar incluyen roles, estándares aplicables, procedimientos, méto-
dos, herramientas, recursos, criterios de entrada y salida y medidas de proceso.
En SP 1.2 la organización identifica que modelo de ciclo de vida es el m á s ade-
cuado para ser utilizado en cada proceso. En SP 1.3 se recogen gu´ıa de uso para
aquellas excepciones o necesidades particulares que puedan surgir a la hora de
aplicar un procedimiento estandarizado. Existirán dos repositorios principales de
información utilizados por el programa de procesos de la organización. El primero
es el repositorio de medidas establecido en SP 1.4. El segundo es la librer´ıa de
activos de procesos establecido en SP 1.5 que da soporte al aprendizaje de la or-
ganización y a la mejora de procesos facilitando y compartiendo buenas prácticas
y lecciones aprendidas de anteriores proyectos. Elementos que puede formar parte
de esta librer´ıa incluyen: pol´ıticas, descripciones de procesos, procedimientos, pla-
nes, materiales de aprendizaje y lecciones aprendidas. Los estándares del entorno
de trabajo se establecen en SP 1.6 y permiten a la organización, los proyectos
y trabajos beneficiarse de herramientas comunes, aprendizaje, mantenimiento y
ahorros por compras centralizadas y en volumen. Por último, SP 1.7 se establecen
gu´ıas para los equipos de trabajo.

4.7.12. Integrated Project Management (IPM)

El propósito de IPM es establecer y gestionar el proyecto y la involucración

de todos los participantes relevantes dentro de un proceso integrado y definido
ajustado al conjunto de procesos estándares de la organización. Gestionar el pro-
yecto está relacionado con el proceso de definición de proyecto, el cual está hecho
a medida de los procesos estándar de la organización.
Distinguimos dos objetivos dentro de IPM. SG 1 establece que los proyectos

34
 andar.

colab

co

Cuadro 4.15: Á rea de proceso: Integrated Project Management (IPM)

hagan uso de los activos de proceso estandarizados establecidos en la definición de

procesos de la organización. SG 2 implica una aproximación proactiva a la hora
de interactuar con el resto de involucrados en el proyecto.
Existen 7 prácticas espec´ıficas asociadas al primer objetivo. En SP 1.1 el pro-
yecto utiliza un conjunto de procesos estándar de la organización y gu´ıas a medida
para establecer un proceso definido para el proyecto en cuestión. El repositorio de
medidas establecido en la definición de los procesos de la organización contiene
información histórica de proyectos pasados que puede ser utilizado en SP 1.2 para
estimar y dibujar el nuevo plan. A continuación, en SP 1.3 se crea un entorno de
trabajo apropiado al proyecto, este entorno comprende las infraestructuras, herra-
mientas y equipos que el personal necesita para llevar a cabo su trabajo de forma
efectiva. Al igual que en la planificación de proyectos (PP) en donde se evaluaba
como afecta el plan a otros en marcha, en SP 1.4 el proyecto integra otros planes
para establecer un actuación conjunto de cara al resto de involucrados en el pro-
yecto. En SP 1.5 se gestiona el proyecto empleando planes integrados de acuerdo
al proceso definido. En SP 1.6 el proyecto es gestionado utilizando equipos de
acuerdo a las reglas para estructurar, crear, formar y operar equipos. Durante el
transcurso del proyecto, sobre todo en grandes proyectos, se podrán emplear di-

35
ferentes equipos con diferentes organizaciones de acuerdo a las necesidades. Por
último, en SP 1.7 se recopila las experiencias y lecciones aprendidas para su do-
cumentación y almacena en el repositorio de medidas de la organización y en la
librer´ıa de activos de la organización.
Para el SG 2 se identifican 3 prácticas espec´ıficas. SP 2.1 describe una apro-
ximación m á s proactiva a la gestión de la implicación de los involucrados en el
proyecto segú n el plan integrado y el proceso definido. En SP 2.2 se identifican
las dependencias cr´ıticas con los involucrados en el proyecto. Y finalmente en SP
2.3 se resuelven cualquier tipo de problema de coordinación con los involucrados.
Entre los problemas m á s habituales estar´ıan las diferencias en la interpretación de
requisitos y el diseñ o, retrasos, problemas a nivel de producto y la falta de recursos
y personal disponible.
En la figura se han añ adido las áreas espec´ıficas de la OPD para mostrar cómo
se integran con IPM.
Un proceso definido comienza con activos de la organización que incluyen el
conjunto de procesos estándar de la organización, estándares de entornos de tra-
bajo, descripciones del modelo del ciclo de vida y reglas y gu´ıas de equipos. Estos
activos son utilizados por un proyecto junto con las gu´ıas a medida y con la infor-
mación del repositorio de medidas de la organización y la librer´ıa de activos para
desarrollar la definición del proceso. Tras utilizar estos activos del proceso y sus
procesos definidos, los proyectos suministran información de acuerdo a la expe-
riencia acumulada a la librer´ıa de activos de procesos y al repositorio de medidas
de la organización.

4.7.13. Organizational Training (OT)

El propósito de OT es el de desarrollar habilidades y conocimiento en el perso-

nal de manera que puedan llevar a cabo sus tareas de forma m á s eficaz y eficiente.
Este PA trata de proveer de la formación necesaria para apoyar la visión estratégica
de la organización y para cubrir las necesidades comunes en los proyectos realiza-
dos en la organización.
Se establecen dos objetivos para cubrir esta PA. El SG 1 establece la capacidad
de la organización para ser capaz de ofrecer formación a sus integrantes, mientras
que SG 2 es la encargada de llevar a cabo esa formación.
Asociado a SG 1 tenemos 4 prácticas espec´ıficas. SP 1.1 realiza un análisis
de las necesidades de formación a largo plazo. Este análisis cubre t´ıpicamente las
necesidades de formación en los siguientes uno a cinco añ os. En SP 1.2 se establece
que grupo es responsable de q ué formación. SP 1.3 establece el plan de formación
para dotar a los miembros de la organización de conocimientos que les permitan
incrementar su eficiencia y eficacia. Este plan cubre el medio y corto plazo y deber
ser actualizado periódicamente para responder a los cambios que puedan aparecer.
Por último, en SP 1.4 se establecen los métodos de formación, los materiales de
formación, o la necesidad de buscarlos fuera de la organización.
SG 2 hace uso de las capacidades establecidas en SG 1 y cuenta con 3 prácticas
espec´ıficas. SP 2.1 se asegura que la formación impartida se ajusta al plan de

36
 SP 1.1 Establecer necesidades de forma-

de responsabilidad de la

on

on
on

Cuadro 4.16: Á rea de proceso: Organizational Training (OT)

formación. SP 2.2 registra la formación impartida. Por último, SP 2.3 realiza las
medidas oportunas para evaluar y si fuera el caso tomar medidas correctivas de
los beneficios obtenidos de la aplicación de la formación.

4.7.14. Requirements Development (RD)

El propósito de RD es obtener, analizar y establecer requisitos de cliente, pro-

ducto o de componentes de producto. Los requisitos deben también satisfacer las
restricciones ocasionados por la elección de las soluciones de diseñ o.
Se establecen tres objetivos en RD. SG 1 hace referencia a la obtención y
desarrollo de los requisitos de cliente. Estos requisitos de cliente son utilizados
por SG 2 para crear los requisitos de producto y de componentes de producto.
SG 3 analiza los requisitos y se asegura que estos son suficientes, necesarios y que
cubren las necesidades operacionales.
Existen dos prácticas espec´ıficas relacionadas con SG 1. SP 1.1 implica la toma
de forma proactiva de los requisitos del cliente, sus expectativas, restricciones y
las interfaces existentes. Es habitual que los clientes no tengan una visión clara de
lo que realmente necesitan y por tanto se debe colaborar de forma proactiva. Una
aproximación temprana e iterativa de esta práctica conduce a una compresión m á s
profunda y completa de las necesidades del cliente. SP 1.2 toma las necesidades
obtenidas en el punto anterior y las utiliza para priorizar y desarrollar los requisitos
de cliente. Cualquier informacion es relevante, y aquella información que no se
pueda conseguir directamente a través del cliente debe intentar ser conseguido por

37
 Desarrollar requisitos de cliente
Se recopilan las necesidades de todos los involucrados
en el proyecto, las expectativas, las restricciones y las
interfaces.
SG1
SP 1.1 Obtener necesidades
SP 1.2 Transformar las necesidades de los involucra-
dos en requisitos de cliente

Desarrollo de requisitos de producto

Los requisitos de cliente son refinados y elaborados para
desarrollar los requisitos del producto y sus componen-
tes.

SG2 SP 2.1 Establecer requisitos de producto y compo-

nentes de producto
SP 2.2 Identificar requisitos de componentes
SP 2.3 Identificar requisitos de interfaces

Analizar y validar requisitos

Los requisitos son analizados y validados.

SP 3.1 Establecer conceptos y escenarios operaciona-

les

SG3 SP 3.2 Establecer una definición de la funcionalidad

requerida y de los atributos de calidad
SP 3.3 Analizar requisitos
SP 3.4 Analizar requisitos para obtener un equilibrio
SP 3.5 Validar requisitos

Cuadro 4.17: Á rea de proceso: Requirements Development (RD)

38
otros medios. Además, los conflictos e inconsistencias que puedan surgir deben ser
resueltas.
Respecto a SG 2 tenemos 3 prácticas. SP 2.1 parte los requisitos de cliente
de SP 1.2 y los utiliza para crear los requisitos de producto y de componentes de
producto. Mientas que los requisitos de cliente pueden ser de carácter no técnico
los requisitos de producto si lo son y serán utilizados en el proceso de diseñ o. En
SP 2.2 se identifican requisitos de m á s bajo nivel. En proyectos de alta complejidad
es habitual encontrar varias capas de requisitos. Aunque las interfaces no dejan de
ser componentes de cualquier producto, dado que son fuente habitual de procesos,
CMMI establece una práctica independiente, SP 2.3, para su tratamiento.
SG 3 contiene 5 prácticas. SP 3.1 trata de establecer escenarios y conceptos
operativos, son ideas de alto nivel de cómo debe comportarse el producto o servicio
final. En SP 3.2 se establecen los requisitos funcionales y los atributos de calidad
deseados. Esto puede incluir la documentación de la arquitectura funcional. SP 3.3
se asegura que los requisitos son suficientes para cubrir los objetivos del proyecto
teniendo en cuenta los escenarios operaciones y los atributos de calidad estableci-
dos. El cliente introducirá restricciones de diversa ´ındole: coste, plazo, rendimiento
funcionalidad, respuesta a imprevistos, mantenimiento y riesgos. SP 3.4 analiza
los requisitos del cliente y las restricciones para buscar un equilibrio entre ambos.
El ú ltimo punto, SP 3.5, implica trabajar con el cliente para validar los requisitos
para asegura que los trabajos a realizar y el producto final satisfacen todas las
necesidades.

4.7.15. Technical Solution (TS)

El propósito de TS es seleccionar, diseñar e implementar soluciones a los requi-

sitos. Las soluciones, diseñ os e implementaciones abarcan productos, componentes
de producto y productos relacionados con el ciclo de vida de procesos tanto de
forma individual o mediante combinaciones segú n convenga. Cuando nos referimos
a producto también nos referimos a cualquier servicio.
Existen tres objetivos espec´ıficos. SG 1 requiere establecer la aproximación
técnica a utilizar en el diseñ o y desarrollo del producto. SG 2 lleva a cabo el
diseñ o y SG 3 la implementación y el desarrollo.
Relacionado con SG 1 tenemos 2 prácticas espec´ıficas. SP 1.1 establece que se
deben buscar diferentes soluciones al problema y establecer un criterio que ayudar
a seleccionar la m á s adecuada. Las soluciones alternativas son valoradas de acuerdo
al criterio establecido en SP 1.2.
SG 2 abarca 4 prácticas espec´ıficas. En SP 2.1 se lleva a cabo el diseñ o del
producto y de los componentes del producto. El diseñ o es utilizado durante todo
el ciclo de vida del proyecto por los involucrados. Debe de ser de fácil compresión
y permitir acomodar cambios con facilidad. SP 2.2 establece la necesidad de crear
paquetes de datos técnicos. Un paquete técnico le proporciona al desarrollador una
visión clara y comprensible del producto o de un componente del producto. Nor-
malmente incluye la definición de la configuración del diseñ o, toda la información
técnica aplicable, y una descripción de la alternativa técnica seleccionada para la

39
 Las soluciones elegidas son escogidas de entre un grupo
de posibles soluciones alternativas

de

Se desarrollar los del producto y sus componen-

tes.

on ecnica

an on,
construccion

Cuadro 4.18: Á rea de proceso: Technical Solution (TS)

40
implementación. El diseñ o de las interfaces se realiza también de forma separa en
SP 2.3. Por último, se establece que productos o componentes serán adquiridos,
reutilizados o desarrollados desde cero o a partir de otros en SP 2.4.
Una vez el diseñ o es completado se implementa en SP 3.1. Ejemplos de imple-
mentación son: programación software, documentación de información y servicios,
fabricación de partes y construcción de instalaciones. Esta práctica incluye peer re-
views y unit-testing de los componentes del producto. SP 3.2 incluye las tareas de
documentación, a menudo olvidadas, de instalación, operación y mantenimiento.
La documentación debe tratarse como una pieza cr´ıtica de la solución técnica.

4.7.16. Product Integration (PI)

El propósito de PI es armar el producto a partir de los componentes del pro-

ducto, asegurar que el producto armado se comporta adecuadamente y entregar
el producto.
Se identifican 3 objetivos. En SG 1 se prepara la integración, en SG 2 se asegura
la compatibilidad de la integracion y en SG 3 se realiza.
La estrategia de integración se desarrolla en SP 1.1. Esta estrategia cubre la
forma de recibir, ensamblar y evaluar los componentes que forman el producto.
Antes de que la integración pueda comenzar, se debe establecer un entorno, esto se
realiza en SP 1.2. El entorno requerido en cada paso de la integración del producto
puede incluir equipos de pruebas, simuladores y equipos de medición. En SP 1.3
se establecen procedimientos para la integración junto con criterios para validar y
entregar el producto final.
Al igual que en la etapa de diseñ o las interfaces tienen un objetivo propio en la
etapa de integración. SP 2.1 revisa que las interfaces cumplan y cubran todas las
especificaciones. Aplica tanto a las interfaces internas como externas. En SP 2.2
se pide la gestión de las interfaces. Esto incluye el mantenimiento de las interfaces
a lo largo de la vida del proyecto teniendo muy en cuenta cómo pueden afectar
cambios introducidos en la interfaz de un componente al resto.
Las prácticas espec´ıficas del SG 3 se orientan al ensamblado del producto y
su entrega. En SP 3.1 se asegura que las partes a ensamblar cumplen con los
requisitos de calidad y consistencia con las descripciones de las interfaces. El en-
samblado tiene lugar en SP 3.2. La integración se lleva a cabo de acuerdo con
la estrategia de integración, procedimientos y criterios establecidos en SG 1. Tras
el ensamblado de los componentes, el producto es evaluado en SP 3.3. La ú ltima
práctica, SP 3.4, constituye el empaquetado final del producto. Algunos productos
tendrán especificado la forma en la que este empaquetado debe realizarse ante de
ser entregado.

4.7.17. Verification (VER)

El propósito de VER es asegurar que el proyecto o producto cumple con sus

especificaciones. La verificación se lleva a cabo a lo largo del ciclo de vida de desa-
rrollo, comenzando con la verificación de los requisitos, pasando por la verificación

41
 Se lleva a cabo los preparativos para la del
producto.

ducto

Se asegura que las interfaces del producto tanto internas

como externas son compatibles

on

Los componentes verificados del producto son ensam-

blados y el producto integrado, verificado, y validado es
entregado.

on

Cuadro 4.19: Á rea de proceso: Product Integration (PI)

42
 erificaci

on

Se realizan peer-reviews (o revisiones por pares)

on

Se seleccionan productos para verificar los requisitos.

Cuadro 4.20: Á rea de proceso: Verification (VER)

de los productos y terminando con la verificación del producto final. La verificación

en cada nivel del ciclo de vida aumenta las posibilidades de éxito.
Se establecen tres objetivos para la VER. El primero realiza una preparación,
el segundo una revisión del primero y por último el tercero efectúa la verificación.
Además, se establece un objetivo global para garantizar la institucionalización.
Asociados a SG 1 hay 3 practicas espec´ıficas. En SP 1.1 se identifican los
productos de trabajo susceptibles de ser verificados y los métodos a utilizar. Estas
actividades de verificación ocurrirán a lo largo de todo el ciclo de vida del proyecto.
No debe demorarse las actividades de verificación, cuanto antes se detecten fallos
o no conformidades antes podrán ser resueltas y menor impacto se ocasionará en el
coste o el plazo de ejecución. Los productos de trabajo a verificar son seleccionados
de acuerdo a su peso en el proyecto y en los riegos que puedan originar. En SP
1.2 se establece el entorno necesario donde llevar a cabo la verificación. En SP 1.3
se establecen los criterios de verificación.
SG 2 cuenta también con otras tres prácticas espec´ıficas asociadas. En SP 2.1
se preparan las peer-reviews. Esta técnica es muy ú til en los procesos de verifica-
ción. Ofrecen una gran oportunidad para aprender y compartir información. La
preparación de las peer-reviews implica normalmente la identificación de los par-
ticipantes, preparar y actualizar los materiales a utilizar durante la peer-review,
tales como checklists y criterios de revisión y planificar las peer-reviews. En SP
2.2 productos de trabajo concretos son seleccionados y las peer-reviews llevadas a

43
 alidaci

El producto o los componentes del producto son valida-

dos para asegurar que preparados para su uso en
el entorno real previsto.

Cuadro 4.21: Á rea de proceso: Validación (VAL)

cabo sobre ellos. La información obtenida de estas reuniones es analizada en SP

2.3.
SG 3 involucra otras técnicas de verificación. La verificación implica a menudo
probar, sin embargo, puede incluir también análisis, simulación y demostraciones.
En SP 3.1 se emplean estos métodos para llevar a cabo la verificación. Para cada
producto de trabajo sobre el que se realiza verificación SP 3.2 recopila y analiza
la información obtenida.

4.7.18. Validación (VAL)

El propósito de la VAL es demostrar que el producto o los componentes del

producto cumplen con las intenciones de uso cuando se sitú an en su entorno de
uso.
Se diferencia de la verificacion en cuanto a que la validación se centra en el
uso del producto mientras que la verificación se centra en el cumplimiento de los
requisitos.
La validación define dos objetivos espec´ıficos. SG 1 realiza los preparativos de
la validación mientras que SG 2 se encarga de realizar la validación.
Ligado a SG 1 hay tres prácticas espec´ıficas. La validación comienza con la
identificación de los productos a validar en SP 1.1. La selección se realizar en
virtud de su relación con las necesidades del cliente final. En SP 1.2 se establece el
entorno de validación. La validación, la verificación y la integración de producto
pueden realizarse en el mismo entorno y compartir los mismos recursos. En SP
1.3 se seleccionan los criterios y procedimientos de validación que aseguren que el
producto cumple con su objetivo de uso. Tras completar las actividades de SG 1,
se realiza la validación en SP 2.1. Los resultados obtenidos en la validación son

44
analizados en el SP 2.2

4.7.19. Organizational Process Performance (OPP)

Tiene como propósito establecer y mantener una comprensión cuantitativa del

rendimiento de los procesos seleccionados del conjunto de procesos estándar de
la organización en apoyo al logro de los objetivos de calidad y de rendimiento
de procesos, y proporcionar datos, l´ıneas base y modelos de rendimiento de los
procesos para gestionar cuantitativamente los proyectos de la organización.
Algunos términos ampliamente utilizados en OPP y otros PAs que debemos
tener en cuenta son:

Rendimiento de proceso. Es una medida de los resultados logrados al

seguir el proceso. Caracterizado por:

• Las medidas del proceso. Esto es, esfuerzo, tiempo del ciclo, eficiencia,
etc.
• Las medidas del producto o servicio. Por ejemplo, fiabilidad, densidad
de defectos, tiempo de respuesta, etc.

Lı́nea base de rendimiento de proceso. Es una caracterización documen-

tado del rendimiento del proceso y que puede incluir la tendencia central y
su desviación. La l´ınea base del rendimiento del proceso puede ser utilizada
como medida para comprar el progreso actual contra el esperado.

Modelo de rendimiento de proceso. Descripción de las relaciones entre

los atributos medibles de uno o m á s procesos o de los productos de trabajo.
Se desarrolla a partir de información histórica y se emplea para predecir el
rendimiento futuro.

OPP solo tiene un ú nico objetivo. SG 1 se encarga de establecer el modelo y

las l´ıneas base de rendimiento. Existe un paso previo que debe realizarse antes de
establecer el modelo y las l´ıneas base, es la identificación de los procesos suscepti-
bles de ser medidos. La calidad y los objetivos de rendimiento de proceso son las
medidas m á s útiles a la hora de seleccionar e identificar procesos para medir.
Asociado a este ú nico objetivo hay 5 prácticas espec´ıficas asociadas. En SP 1.1
se establecen los objetivos de calidad y de rendimiento de proceso a partir de las
necesidades de negocio. SP 1.2 selecciona los procesos o subprocesos dentro del
conjunto de procesos estándar de la organización que se incluirán en los análisis de
rendimiento de procesos de la organización y manteniendo la trazabilidad con los
objetivos de negocio. SP 1.3 establece y mantiene definiciones de las medidas que
serán incluidas en los análisis de rendimiento de procesos de la organización. SP
1.4 analiza el rendimiento de los procesos seleccionados, establece y mantiene las
l´ıneas base de rendimiento del proceso. Por último, SP 1.5 establece y manteniene
los modelos de rendimiento de los procesos para el conjunto de procesos estándar
de la organización.

45
 Establece y mantiene las l´ıneas base y los modelos, los
cuales caracterizan la expectativa de rendimiento de los
procesos para el conjunto de procesos de la

de proceso

Cuadro 4.22: Á rea de proceso: Organizational Process Performance (OPP

4.7.20. Quantitative Project Management (QPM)

Tiene como propósito gestionar cuantitativamente el proyecto para alcanzar

los objetivos establecidos de calidad y de rendimiento del proceso del proyecto.
QPM evoluciona la gestión de proyectos iniciada con las prácticas de PP y
PMC y ampliadas con el proceso definido en IPM para introducir los conceptos de
gestión estad´ıstica del proceso y la gestión cuantitativa del proceso para alcanzar
los objetivos definidos en el proyecto. Requiere contar con información histórica
suficiente de los indicadores del proceso recolectada por MA y controlada en OPD.
Se establecen dos objetivos para este PA. SG 1 describe cómo se prepara el pro-
yecto para realizar gestión cuantitativa. SG 2 lleva a cabo las actividades definidas
en SG 1.
SG 1 tiene asociadas cuatro prácticas espec´ıficas. En SP 1.1 se establecer y
mantienen los objetivos de calidad y de rendimiento del proceso del proyecto. Es-
tos se basan en los objetivos de calidad de lo organización. En SP 1.2 se utilizan
la estad´ıstica y otras técnicas cuantitativas para componer el proceso definido que
permite al proyecto alcanzar los objetivos de calidad y de rendimiento del proceso.
Componer el proceso es complejo y por ello es habitual descomponer el proceso en
subprocesos. Esta práctica implica identificar alternativas, realizar análisis cuan-
titativo del rendimiento y selecciona las alternativas que mejor encajen con las
necesidades del proyecto. Los subprocesos que sean cr´ıticos para el éxito del pro-
yecto suelen ser buenos candidatos para ser monitorizados y controlados utilizando
técnicas estad´ısticas u otras técnicas cuantitativas. SP 1.3 Selecciona los subpro-
cesos y atributos cr´ıticos para evaluar el rendimiento y que ayudan a alcanzar los
objetivos de calidad y rendimiento del proceso del proyecto. SP 1.4 Selecciona las
medidas y las técnicas anal´ıticas a usarse en la gestión cuantitativa.
Respecto al segundo objetivo se identifican 3 prácticas espec´ıficas. SP 2.1 Mo-
nitoriza el rendimiento de los subprocesos seleccionados utilizando la estad´ıstica

46
 preparaci

SP 1.3 Seleccionar subprocesos y atributos

an

Cuadro 4.23: Á rea de proceso: Quantitative Project Management (QPM)

y otras técnicas cuantitativas. En SP2.2 se gestiona el proyecto utilizando la es-

tad´ıstica y otras técnicas cuantitativas para determinar si los objetivos de calidad y
rendimiento del proceso del proyecto son satisfechos. Por último, SP 2.3 realiza un
análisis de causa ra´ız de los problemas seleccionados para atender las deficiencias
en el logro de los objetivos de calidad y rendimiento del proceso del proyecto.

4.7.21. Causal Analysis and Resolution (CAR)

Tiene como propósito identificar las causas de los resultados seleccionados y

tomar acción para mejorar la realización del proceso.
CAR, al igual que OPM, establece prácticas que permiten optimizar el proceso
a nivel de proyecto o de la organización y requiere un entendimiento cuantitativo
del proceso para poder ser efectivas.
Existen dos objetivos fijados en CAR. SG 1 est á relacionada con la evaluación
de las causas que originan los resultados que provocan variaciones como parte
del proceso. SG 2 establece acciones espec´ıficas para mejorar los resultados y la
capacidad del proceso en términos cuantitativos.
Asociado al objetivo uno tenemos dos prácticas espec´ıficas asociadas. En SP
1.1 se seleccionan los resultados que van a ser analizados. Esta selección implica
recopilar información relevante y determinar q ué resultados serán analizados en
el futuro. Entre los métodos que pueden ser empleados para esta selección están:
el análisis de Pareto, histogramas, diagramas de cajas y análisis de capacidad
de procesos. Posteriormente, en SP 1.2 se realiza un análisis de causa ra´ız para

47
 Las causas ra´ız de los resultados seleccionados son de-
terminadas atica
SG1

sistem

on a

Cuadro 4.24: Á rea de proceso: Causal Analysis and Resolution (CAR)

determinar las causas subyacentes de los resultados seleccionados y de las acciones

necesarias para atajar sus causas. Existen muchas herramientas que pueden ser
utilizadas para este tipo de análisis, incluyendo análisis de causa-efecto, diagramas
de Ishikawa, diagramas de Pareto o los cinco por q ué.
El segundo objetivo tiene asociado tres prácticas espec´ıficas. Las propuestas de
acción son desarrolladas a partir del análisis causa ra´ız en SP 2.1. Las propuestas de
acción describen las tareas necesarias para atajar las causas ra´ız de los resultados
analizados. Solo los cambios que tengan la capacidad de añ adir valor significativo
deben ser considerados para ser implementados de manera global. Una vez que el
cambio en el proceso se implementa en los proyectos, los efectos de este cambio
son evaluados para verificar que se ha mejora el rendimiento de proceso en SP
2.2. Por último, en SP 2.3 se registra toda la información obtenida del análisis.
Este análisis es transmitido al resto de la organización en forma de propuesta de
mejora. La organización analizará la propuesta en el á rea de proceso OPM.

4.7.22. Organizational Process Management (OPM)

El propósito de OPM es gestionar de manera proactiva el desempeñ o de la

organización para alcanzar los objetivos de negocio. OPM analiza iterativamente
información agregada de diversas fuentes con el fin de encontrar diferencias signi-
ficativas entre el rendimiento observado y los objetivos de negocio. Además, busca
seleccionar las mejoras que permitan reducir estas diferencias.
Existen tres objetivos espec´ıficos para mejorar el rendimiento de negocio. La
organización no se centra en mejorar objetivos individuales, sino que persigue una

48
mejora global del rendimiento. La calidad y los objetivos de rendimiento de pro-
ceso se ajustan o se añ aden nuevos objetivos en función de las necesidades de
negocio. SG 1 emplea técnicas estad´ısticas y cuantitativas para identificar á reas
donde el rendimiento cae por debajo de los objetivos de negocio. SG 2 requie-
re que la organización busque de forma proactiva e incremental ideas de mejora
innovadoras. Aquellas ideas que potencialmente tengan un mayor impacto en el
rendimiento son seleccionadas para ser puestas en práctica. SG 3 pone en marcha
aquellos procesos mejorados, métodos y tecnolog´ıas en aquellos proyectos que pue-
dan beneficiarse de las mejoras introducidas. Al mismo tiempo que se implantan
los procesos mejorados se recopila información para asegurarse que los beneficios
del cambio son reales.
Asociada al SG 1 hay 3 prácticas espec´ıficas. En SP 1.1 se utilizan los datos de
rendimiento de la organización para evaluar si los objetivos de negocio son realistas
y están alineados con las estrategias de negocio. Sin un conjunto bien definido de
objetivos, la probabilidad de que las mejoras estén alineadas es menor. SP 1.2
utiliza el análisis de las l´ıneas base de rendimiento de proceso, las simulaciones
de proceso y modelos de rendimiento de proceso para evaluar la habilidad de
la organización para conseguir sus objetivos de negocio. Basado en este último
análisis, SP 1.3 identifica las á reas donde el rendimiento no está alcanzando el
objetivo.
SG 2 cuenta con cuatro practicas espec´ıficas. SP 2.1 se centra en recopilar
mejoras provenientes de diversas fuentes. Las mejoras propuestas son analizadas
en SP 2.2, estas se evalú an teniendo en cuenta su coste y su beneficio potencial.
Basándose en esta evaluación, algunas mejoras son seleccionadas para su valida-
ción, implementación y posterior despliegue a lo largo de la organización. Los
resultados del análisis se documentan en una propuesta de mejora. En SP 2.3 las
mejoras se validan en el entorno de usuario. La validación se lleva a cabo en pro-
yectos seleccionados que cumplan las caracter´ısticas adecuadas en función del tipo
de cambio a introducir. Tras el análisis y validación SP 2.4 selecciona finalmente
las mejoras que serán implantadas en la organización.
Respecto al SG 3 existen tres prácticas espec´ıficas. En SP 3.1 se crea el plan
de despliegue de cada mejora que va a ser implantada. Es necesario llegar a un
compromiso entre estabilidad y cambio, la introducción de cambios con mucha
frecuencia y poco impacto puede ser perjudicial. En SP 3.2 se gestiona el desplie-
gue del plan de acuerdo a lo expuesto en el punto anterior. Los resultados de la
implantación son evaluados en SP 3.3 empleando técnicas estad´ısticas y métodos
cuantitativos.

4.7.23. Objetivos y Prácticas Genéricas (GG/GP)

Las metas genéricas (GG) y prácticas genéricas (GP) ayudan a institucionalizar

en la organización las prácticas establecidas en cada una de las á reas de proceso,
de manera que el proceso puede evolucionar desde un proceso “adhoc” hasta un
proceso institucionalizado dependiendo del nivel que se quiera alcanzar.
Existen tres objetivos genéricos. Ambos objetivos están relacionados de forma
que uno se fundamente en el otro como se muestra en la figura. El nivel de satis-

49
 Gestionar el rendimiento en la organización
El rendimiento del negocio de la organización es gestio-
nado utilizando estad´ıstica y otras técnicas cuantitativas
para comprender las deficiencias de rendimiento de pro-
ceso e identificar á reas de mejora de procesos.
SG1
SP 1.1 Mantener los objetivos de negocio
SP 1.2 Analizar la información del rendimiento del
proceso
SP 1.3 Identificar á reas potenciales de mejora

Gestionar el desempeño del negocio

Las mejoras son identificadas de manera proactiva, eva-
luadas usando técnicas estad´ısticas y otras técnicas
cuantitativas y seleccionadas para su difusión basado en
su contribución al cumplimiento de los objetivos de ca-
lidad y rendimiento del proceso.
SG2
SP 2.1 Obtener y categorizar las mejoras sugeridas
SP 2.2 Analizar las mejoras sugeridas
SP 2.3 Validar las mejoras seleccionadas
SP 2.4 Seleccionar e implementar las mejoras para di-
fusión en la organización

Seleccionar mejoras al proceso

Las mejoras medibles a los procesos y tecnolog´ıas de
la organización son difundidas y evaluadas usando es-
tad´ıstica y otras técnicas cuantitativas.
SG3
SP 3.1 Despliegue del plan
SP 3.2 Gestion de despliegue
SP 3.3 Evaluar los efectos de la mejora

Cuadro 4.25: Á rea de proceso: Organizational Process Management (OPM)

50
facción de los objetivos genéricos muestra el nivel de institucionalización de cada
á rea de proceso CMMI
El GG 1 requiere que la organización lleve a cabo el trabajo necesario para pro-
ducir productos de trabajo, en términos CMMI al proceso de le denomina “per-
formed process”. Se realizan las prácticas espec´ıficas de las á reas de proceso.
Sin embargo, la definición de proceso puede estar incompleta y la infraestructura
necesaria para llevarlo a cabo ser deficiente. Como resultado no existe una garant´ıa
de que el proceso sea implementado consistentemente y duradero en el tiempo.
En GG 2 el proceso es institucionalizado. Se dice que el proceso está gestio-
nado, t´ıpicamente CMMI se refiere a é l como “managed process”, cuando est á
planificado y ejecutado de acuerdo a una pol´ıtica, emplea gente preparada con
recursos suficientes, involucra a todos los afectados, esta monitorizado, controlado
y revisado, y es evaluado de acuerdo a la descripción de su cometido.
GG 3 se fundamenta en el proceso gestionado de GG 2 para obtener un pro-
ceso definido o “defined process”. Para que un proceso sea definido este debe
ajustarse al conjunto de estándares de la organización de acuerdo a una serie de
gu´ıas predefinidas por la misma organización.
Las prácticas genéricas se relacionan con todas las á reas de proceso de CMMI

4.8. Representaciones CMMI

Las áreas de proceso de CMMI se pueden agrupar en torno a dos representa-

ciones. Estas representaciones dan forma a cómo la organización lleva a cabo la
mejora de procesos y las evaluaciones de los procesos. Las dos representaciones
son: por etapas o continua. La motivación de que existan dos tipos de representa-
ciones viene dada por el hecho de que las organizaciones pueden tener diferentes
necesidades o prioridades a la hora de mejorar sus procesos.

4.8.1. Representación Continua

Esta representación ofrece un enfoque m á s flexible al permitir que las organi-

zaciones aborden las á reas de proceso que consideren m á s necesarias. Una orga-
nización puede elegir mejorar una ú nica á rea de proceso o un grupo de á reas de
proceso que sean relevantes para las necesidades de negocio de la organización.
La tabla 4.27 muestra como se agrupan las áreas de proceso por categor´ıas en
el modelo CMMI-DEV.
La representación continua es utilizada para implementar mejoras de proceso
de manera individual, esto es en áreas de proceso seleccionadas. La ventaja es
que la organización elige el orden en el que efectuar las mejoras de acuerdo con
sus necesidades. También permite a las organizaciones realizar las mejoras en
diferentes PA a distinto nivel y ritmo. En la figura se muestran un ejemplo de esto
último, diferentes PA de una organización con diferentes niveles de capacidad.

51
 das

Cuadro 4.26: Procesos y prácticas genéricas (GG/GP)

52
 Categorı́a Á rea de Proceso
Organizational Process Definition
Organizational Process Focus
Gestión de Procesos Organizational Performance Management
Organizational Process Performance
Organizational Training
Integrated Project Management
Project Monitoring and Control
Project Planning
Gestión de Proyecto Quantitative Project Management
Requirements Management
Risk Management
Supplier Agreement Management
Product Integration
Requirements Development
Ingenier´ıa
Technical Solution
ValidationVerification
Causal Analysis and Resolution
Configuration Management
Soporte Decision Analysis and Resolution
Measurement and Analysis
Process and Product Quality Assurance

Cuadro 4.27: Clasificación de áreas de proceso CMMI

53
4.8.2. Representación por Etapas

La representación por etapas ofrece un camino predefinido para llevar a cabo

la mejora de procesos con CMMI. Cada paso en el camino requiere que se hayan
completado los pasos anteriores y por tanto alcanzado un cierto nivel de madurez.
Una ventaja de esta representacion es que ofrece una calificación ú nica de madurez
para todas las áreas de proceso en lugar de múltiples calificaciones para cada PA.
Algunos beneficios de utilizar esta representación son:

Proporciona una secuencia probada de pasos en el camino de la mejora de

procesos. Avanzar de un nivel a otro garantiza que todos los objetivos hasta
un cierto punto han sido alcanzados por la organización.

Permite establecer comparaciones entre diferentes organizaciones en cuanto

a su nivel de madurez de procesos.

Proporciona una calificación ú nica que recoge la evaluación de los resultados

obtenidos de la mejora de procesos

Existen cinco niveles de madurez en esta representación, la tabla 4.28 muestras

las PA afectadas en cada nivel.

4.8.3. Elección de representación CMMI

Las organizaciones que quieran utilizar CMMI como gu´ıa para la mejora de
procesos deben elegir q ué representación utilizar. Para ello deben pensar cóm o
van a implementar las áreas de proceso. Hay que tener en cuenta que el contenido
es el mismo independientemente de la representación empleada. Deben ser las
necesidades de negocio las que establezcan q ué representación utilizar.
Las representaciones son a veces elegidas por las organizaciones en virtud del
tipo de evaluación o “appraisal” que persigan. En una evaluación, las repre-
sentaciones elegidas son utilizadas para monitorizar el progreso y el éxito de la
implantación de las mejoras.
Las organizaciones que utilicen la representación por etapas llevarán a cabo
evaluaciones que determinen si han conseguido cumplir con todas las á reas de
proceso de un conjunto de PA predefinido con el fin de lograr un nivel de madurez.
En la representación continua, las evaluaciones tienen como objetivo determi-
nar el nivel de capacidad de las á reas de proceso de forma individual.

4.9. Niveles CMMI

Los niveles son utilizados en CMMI como un camino que describe la evolución
recomendada para que una organización mejore sus procesos. Los dos tipos de
caminos de mejora que existen en CMMI están asociados a dos tipos de niveles

54
 Nivel Foco Á reas de Proceso
Causal Analysis and Resolution
5 Optimizado Mejora continua de
Organizational Performance Management
procesos
Organizational Process Performance
4 Gestionado cuanti- Gestión cuantitativa
Quantitative Project Management
tativamente
Decision Analysis and Resolution
Integrated Project Management
Organizational Process Definition
Organizational Process Focus
Organizational Training
3 Definido Estandarización de Product Integration
procesos Requirements Development
Risk Management
Technical Solution
Validation
Verification
Configuration Management
Measurement and Analysis
Project Monitoring and Control
2 Gestionado Gestión básica de pro- Project Planning
yectos Process and Product Quality Assurance
Requirements Management
Supplier Agreement Management
1 Inicial

Cuadro 4.28: Á reas de proceso asociadas a cada nivel de madurez del modelo por
etapas CMMI.

55
y que corresponden a su vez a las dos representaciones existentes: continua y por
etapas.
La aproximación por etapas es utilizada en las evaluaciones que determinan si
la implementación de un á rea de proceso logra alcanzar o no un nivel de madurez
predefinido. Los niveles de madurez muestran la evolución en el camino de la
institucionalización y rendimiento de procesos.
La aproximación continua es utilizada en las evaluaciones que evalú an el nivel
de capacidad de á reas de proceso individuales. Los niveles de capacidad muestran
un camino de evolución basado en el grado de institucionalización y aptitud en el
rendimiento de un á rea de proceso individual.
El concepto de nivel es el mismo independientemente de si se utiliza la repre-
sentación continua o por etapas. Alcanzar un cierto nivel puede ser importante
para las organizaciones, ya que es habitual que este constituya un requisito a la
hora de obtener proyecto o de trabajar para otras empresas o instituciones.

4.9.1. Niveles de capacidad

Estan relacionados con á reas de proceso individuales en vez de con un conjunto

de áreas de proceso. El nivel de capacidad de un á rea de proceso se obtiene cuando
se logra cuando se alcanzan hasta un cierto nivel todos los objetivos genéricos. Esto
da una idea de la institucionalización del PA.
Nivel de capacidad

Á rea de Proceso n

Figura 4.5: Niveles de capacidad CMMI

Existen cuatro niveles de capacidad numerados de 0 a 3. Estos niveles son

acumulativos, es decir cuanto mayor es el nivel mayor es el grado de capacidad.
La capacidad se muestra mediante un gráfico de barras por cada á rea de pro-
ceso, como se muestra en la figura 4.5.

4.9.2. Niveles de madurez

El nivel de madurez representa un camino definido de pasos en la capacidad de

los procesos. Permite medir los procesos contra un grupo predefinido de á reas de

56
proceso en el modelo CMMI. Cada nivel conseguido sirve como base para alcanzar
el siguiente nivel, un nivel superior se basa en el inmediatamente anterior, y este
en el anterior, y as´ı de forma recursiva.
La clasificación del nivel de madurez se realiza en virtud de la satisfacción de
todos los objetivos genéricos y espec´ıficos de las á reas de proceso agrupadas en
el nivel correspondiente y en los niveles anteriores. Para conseguir un nivel 3 de
madurez se deben cumplir todos los objetivos espec´ıficos de los niveles 1, 2 y 3.
Cada nivel de madurez sirve como capa y sustrato del nivel siguiente, tal y
como se muestra en la figura 4.6. Los objetivos de cada nivel son:

3. Defined

2. Managed

Figura 4.6: Niveles de madurez CMMI

Nivel 1. El éxito depende del rendimiento de los individuos involucrados en

el proyecto, los procesos son informales, ad-hoc, e impredecibles

Nivel 2. Se realizan tareas básicas de gestión de proyecto y actividades

para realizar un seguimiento y control básico del proyecto. Con esta gestión
básica, la organización puede implementar aquellos elementos exitosos de la
gestión en otros proyectos similares.

Nivel 3. Se centra en la estandarización y despliegue a nivel organizacional

de los procesos. Cada proyecto tiene un proceso de gestión que se adapta a
los requisitos del mismo partiendo de un conjunto de procesos organizativos.
Los activos y medidas de los procesos se deben recopilar y utilizar en futuras
mejores de procesos.

Nivel 4. Existe una metodolog´ıa cuantitativa para controlar los subprocesos,

esto es, las medidas de procesos recopiladas deben ser utilizadas en la gestión
de procesos.

Nivel 5. La organización utiliza las medidas de los procesos para dirigir su

mejora de procesos. Las tendencias se analizan y los procesos modificados y
adaptados a las necesidades de negocio.

57
4.10. Evaluación CMMI
Las evaluaciones o “appraisals” son el mecanismo utilizado para determinar
el nivel de capacidad y madurez de una organización.
La figura muestra la estructura general de evaluación para las dos representa-
ciones disponibles en CMMI.
Para la representación continua, se utiliza la satisfacción de objetivos genéricos
para determinar el nivel de capacidad de las áreas de proceso individuales.
En la representación por etapas, la satisfacción de las á reas de proceso es
empleada para determinar el nivel de madurez de la organización.
En las evaluaciones los componentes de CMMI son considerados de tres formas:

Requerido. Describe lo que la organización debe lograr para satisfacer el

á rea de proceso. Este logro debe ser implementado de manera visible en los
procesos de la organizacion. La satisfacción de objetivos se utiliza en las
evaluaciones como base para decidir si el á rea de proceso está satisfecha o
no.

Esperado. Mientras que los objetivos son considerados como requeridos, las
prácticas se consideran esperables. Las prácticas representan las actividades
que normalmente son esperables cuando la organización trata de satisfacer
un objetivo genérico o espec´ıfico. La manera en la que las organizaciones.

Informativo.

Existen tres clases de evaluaciones estándar en CMMI para la mejora de pro-

cesos, también denominadas SCAMPI.

SCAMPI-A. Es el método m á s riguroso y es el ú nico método que obtiene

como resultado una valoración o “rating”.

SCAMPI-B. Son métodos iniciales e incrementales, se utilizan como auto-

evaluación de los procesos.

SCAMPI-C. Es un método que sirve para realizar una evaluación rápido

y no rigurosa y que suele servir como aproximación a las organizaciones que
deseen aplicar CMMI.

La tabla 4.29 muestra las variaciones entre los tres métodos de evaluación. El
nivel de detalle aumento de C a B y de B a A. Normalmente las organizaciones
emplean SCAMPI-C y SCAMPI-B como preparación para una auditor´ıa basada
en SCAMPI-A que les permite acreditarse con un nivel de madurez o capacidad
CMMI.

58
 Caracterı́stica Clase C Clase B Clase A
Cantidad de evidencias objetivas Bajo Medio Alto
Puntuaciones generadas No No Si
Recursos necesarios Bajo Medio Alto
Tamañ o del equipo Pequeño Mediano Grande

Cuadro 4.29: Comparativa de los métodos de evaluación CMMI SCAMPI.

59
Capı́tulo 5

CMMI Ágil

Los métodos de desarrollo ágiles y las prácticas CMMI son a menudo percibidas
como antagónicas y excluyentes entre s´ı. Sin embargo, esto está lejos de la realidad,
CMMI y los métodos de desarrollo ágiles son compatibles y pueden por tanto
usarse conjuntamente, es más , el correcto uso de ambos puede generar importantes
sinergias que permitan aumentar la tasa de éxito de los proyectos software.

5.1. Percepción del CMMI Á g i l

Si empezamos por analizar por q ué CMMI y lo métodos á giles se perciben
como opuestos podemos dar dos razones que quizá nos ayuden a comprender esta
situación [71]:

1. Los primeros usuarios en adoptar CMMI y los métodos ágiles re-

presentan casos extremos. Por un lado, quienes primero se iniciaron en
CMMI normalmente fueron organizaciones desarrollando sistemas comple-
jos, de carácter cr´ıtico, de tiempo real, de gran tamañ o y con varios niveles
organizativos de gestión. Por otro lado, las metodolog´ıas á giles proliferaron
en proyectos m á s pequeños, con equipos reducidos desarrollando software
con requisitos cambiantes y poco estrictos. Estos dos extremos marcaron
profundamente ambos campos.
2. La información poco precisa sobre CMMI y métodos ágiles, y el
mal uso de ambos resultó en malinterpretaciones en ambos sentidos. Estas
percepciones negativas que posicionaron a CMMI y los métodos á giles como
contrarios surgieron en gran medida a partir de los siguientes factores:
a) Falta de uso o uso incorrecto.
b) Falta de información precisa.
c) Terminolog´ıa confusa.
d) Mejoras en el enfoque Top-Down contra el Bottom-Up

Comentaremos a continuación con un poco m á s de detalle los factores mencio-

nados.

60
5.1.1. Falta de uso y uso incorrecto

Tanto CMM como CMMI son modelos y no estándares para mejorar el ren-
dimiento de los procesos software dentro de las organizaciones. Sin embargo, con
cierta frecuencia las organizaciones han utilizado las evaluaciones CMMI como un
criterio para catalogar el rendimiento del negocio, de esta forma prima m á s la
evaluación CMMI obtenida que los beneficios que se puedan obtener de ella.
Las primeras organizaciones que implantaron CMM y CMMI eran grandes
organizaciones inmersas en grandes proyectos con complejos procesos, muchos de
á mbito militar. Este origen dotó a CMM/CMMI de la fama de ser adecuado para
este tipo de proyectos. Además, mucha de la literatura y libros escritos sobre la
materia abordaban principalmente cómo poner en práctica CMM/CMMI en este
tipo de proyectos y organizaciones.

5.1.2. Falta de información precisa

A pesar de que en los últimos añ os ha aumentado el nú mero de publicaciones

e información disponible acerca del uso de metodolog´ıas ágiles junto con CMMI,
durante mucho tiempo esta información ha sido escasa y en ocasiones imprecisa.
Hasta 2005 no se hab´ıa publicado información sobre experiencias de integración
de metodolog´ıas á giles y CMMI [72] exitosas. Algunos autores [71] señ alan que el
marcado carácter de ambos enfoques contribuyó a que durante mucho tiempo las
experiencias de integración no fueran exitosas.
En 2008, el SEI publica un estado del arte sobre la integración de ambos
enfoques [71]. A partir de entonces la idea del CMMI ágile ha ido cobrando m á s
fuerza y el nú mero de publicaciones y su calidad ha ido aumentando con el paso
del tiempo.

5.1.3. Terminologı́a confusa

Las metodolog´ıas ágiles, CMMI, los métodos de desarrollo tradicionales y los

diferentes marcos de gestión de proyectos tienen todos ellos su propio vocabulario.
Sin embargo, el solapamiento del vocabulario entre ellos resulta un problema a la
hora de comunicar conceptos.
Por ejemplo, technical data package (TDP) es un término empleado por CMMI
para referirse a una colección de documentos que describen el producto que está
siendo desarrollado. Se emplea normalmente en desarrollos posteriores, operacio-
nes, instalaciones, entrenamientos, soporte, resolución de dudas o mantenimiento
del producto. El TDP puede incluir texto, diagramas, planos, diseñ os, especifica-
ciones u otra información. Sin embargo, TDP tiene otro significado en el contexto
en la adquisición de sistemas, donde se refiere a un entregable concreto que incluye
una documentación espec´ıfica.
Otro ejemplo de vocablo que puede inducir a confusiones es predictable o pre-
decible, que tiene significados diferentes en el mundo á gil y el tradicional. Una
de las ideas de la comunidad Agile es que los proyectos software no pueden ser

61
predecidos con precisión y por tanto “la perfección es el enemigo de lo suficien-
temente bueno, es mejor reaccionar y refactorizar a predecir”. En cambio, CMMI
utiliza el término predictable de manera m á s sutil. En el nivel 4 de CMMI, las
predicciones se derivan a partir de la compresión de las variaciones esperadas a
nivel de proceso junto con modelos estad´ısticos y probabil´ısticos que predicen los
rangos de variación del proyecto. La predictibilidad no se consigue a partir de un
plan minucioso que cubra todos los hitos del ciclo de vida del proyecto, ni siquiera
CMMI espera o requiere este tipo de predictibilidad.

5.2. Combinando CMMI y Agile

CMMI y Agile son compatibles. A nivel de proyecto, CMMI se centra en un
plano m á s abstracto, en q ué hace el proyecto, no en que metodolog´ıa de desarrollo
que se emplea, mientras que los métodos Agile se centran en el có m o del desarrollo
del proyecto. Por tanto, no existe ninguna razón que los haga incompatibles, pues
trabajan de manera colaborativa en diferentes planos del proyecto con el fin de
aumentar su tasa de éxito.
La combinación de ambos permite generar sinergias dentro de la gestión del
proyecto. Hoy en d´ıa, existen muchas organizaciones que al tiempo que se adhieren
a CMMI, han adoptado metodolog´ıas ágiles para el desarrollo software. De igual
forma aquellas organizaciones acostumbradas a trabajar con metodolog´ıas ágiles,
pueden adoptar CMMI para mejorar el proceso software.

5.2.1. Retos al usar métodos ágiles

El mayor reto que podemos identificar es el empleo de metodolog´ıas ágiles en

el marco de grandes proyectos. En este tipo de proyectos es complicado mantener
alineados a los diferentes grupos de desarrollo durante la ejecución del proyecto
al mismo tiempo que se mantienen fieles a los valores y principios á giles. Conse-
guir mantener el alineamiento a lo largo de un proyecto distribuido, esto es, un
proyecto con diversos equipos (posiblemente separados geográficamente), requiere
de alguien (o incluso otro equipo) o de un mecanismo encargado de mantener la
coherencia de:

las capacidades del sistema a desarrollar, incluyendo los requisitos no técni-

cos.

alcance, calidad, plazo, costes y riesgos.

arquitectura del producto o servicio.

Si no se logra la coherencia, la falta de alineamiento se puede hacer presente

en diferentes frentes. Por ejemplo, un principio comú n en las metodolog´ıas ágiles,
el refactoring, a menudo no escala bien cuando es necesario involucrar a diferentes
equipos de desarrollo para llevarlo a cabo.

62
 Las metodolog´ıas ágiles han conseguido escalar para poder ser utilizadas en
grandes proyectos a través de diversas formas: release planning, test planning,
integración continua, despliegue continuo, y utilizando nuevas arquitecturas como
microservicios en lugar de componentes.
Desde el punto de vista de la ingenier´ıa de sistemas, los siguientes puntos son
conflictivos en grandes proyectos:

visión global del proyecto.

gestionar las necesidades de cada equipo.
definir y mantener las interfaces y restricciones existentes entre equipos
mantener una estrategia de integración, verificación y validación eficaz para
todo el sistema.
coordinar la gestión de riesgos a lo largo del proyecto.

Estos alineamientos y actividades de coordinación, necesarios en los proyectos

m á s grandes, están descritos en las “prácticas de ingenier´ıa de sistemas” que se
pueden encontrar en CMMI bajo el ep´ıgrafe Engineering, Risk Management, and
Integrated Project Management process areas. De esta forma CMMI provee una
“red de seguridad” para grandes proyectos que ayuda a reducir los riesgos.
Los métodos ágiles son dif´ıciles de aplicar como metodolog´ıa principal de desa-
rrollo en grandes proyectos. Sin embargo, recientemente se ha visto un aumento de
su uso en este tipo de proyectos gracias a la introducción de nuevas formas ágiles.
Una forma muy popular es añ adir una nueva capa de gestión á gil que coordine
al resto de equipos utilizando metodolog´ıas de desarrollo á gil, por ejemplo, una
capa de gestión Scrum para coordinar al resto de equipos empleando Scrum, un
“Scrum de Scrums”. El empleo de metodolog´ıas ágiles en grandes proyectos es una
tendencia que esta ganando terreno a medida que las organizaciones van ganando
conocimiento en la aplicación de la metodolog´ıa á gil.
La falta de gu´ıas y prácticas de uso de los métodos ágiles para su implementa-
ción y soporte a lo largo de una organización es otro problema a abordar. A pesar
de que grandes organizaciones se han embarcado en la adopción de metodolog´ıas
ágiles en todos sus proyectos, el nivel de las gu´ıas disponibles para su adopción
es todav´ıa escasa. Los métodos ágiles necesitan de un mecanismo que los haga
adaptarse al contexto de la organización, a su filosof´ıa y formas de trabajo. Es
necesario introducir mecanismos que permitan medir y evaluar su impacto, y ser-
vir al mismo tiempo de gu´ıa para su mejora. CMMI puede ser ese mecanismo que
permita que la inclusión de las metodolog´ıas á giles en el desarrollo de proyectos
software se convierta en un éxito.
Cabe decir que CMMI no es la ú nica v´ıa para conseguir implantar los métodos
ágiles en grandes organizaciones de forma efectiva. Microsoft [73] ha desarrollado
su propia técnica de mejora de procesos software. Si bien es cierto, que algunas
de las ideas que ha implementado Microsoft son similares a las propuestas por
CMMI, pero particularizadas para el entorno y las particularidades del negocio de
Microsoft.

63
 Otro reto a la hora de combinar CMMI y los métodos ágiles, y que por otra
parte es comú n en casi cualquier actividad, es el factor humano. El factor humano
se puede manifestar de dos formas:

a través de una dirección poco convencida de los beneficios que se puedan

obtener de la implantación de una nueva forma de trabajo.

a través de un rechazo por parte de quienes deben modificar su forma de

trabajo.

CMMI contempla estas situaciones y se ha diseñ ado para que la experiencia de

cambio en los procesos de la organización afronte esta problemática. Por ejemplo,
cuando se introduce un desarrollo ágil, es habitual que la dirección tema perder el
control del proyecto.

5.2.2. Retos al usar CMMI

Al igual que con los métodos ágiles también existen retos a la hora de implantar
CMMI. No existe ninguna aproximación o metodolog´ıa que aborde todos los retos y
situaciones que puedan surgir a lo largo de un proyecto software [74]. Simplemente
por el hecho de que una organización obtenga un determinado nivel de madurez
CMMI, no significa que los proyectos dentro de la organización vayan a ser todos
exitosos. El nivel de madurez de una organización indica que la organización está
preparada para gestionar aquello que puede hacer que un proyecto fracase hasta
un cierto punto.
En ocasiones las organizaciones se ven en la necesidad de alcanzar un deter-
minado nivel de madurez en un tiempo poco realista, bien porque lo necesitan
para optar a conseguir un proyecto o bien por decisión de la dirección. En estas
situaciones el objetivo deja de ser la mejora de procesos para ser el hecho de dis-
poner de una acreditación del nivel de madurez. As´ı, se puede dar el caso de que
se instauren normas, gu´ıas y métodos recogidos en CMMI pero que no sean los
apropiados para la organización. En estos casos, la organización se acredita con
un nivel de madurez, pero sin adoptar los procesos adecuados de acuerdo a sus
necesidades reales. Por ejemplo, una organización de tamañ o medio desarrollando
software web adopta procesos de desarrollo, validación y verificación propios de
una organización de gran tamañ o desarrollando software cr´ıtico de tiempo real.
Las gu´ıas implantadas en una organización pueden no ser los suficientemente
flexibles para un determinado proyecto, o para un proceso concreto del proyecto.
Esta es una de las razones por las que el modelo de desarrollo ha evolucionado
desde el modelo en cascada pasando por el iterativo o de espiral y llegando a los
métodos ágiles. En un mundo tan cambiante como el actual, las organizaciones
que implanten CMMI deben tener esto en cuenta y adaptarse a las situaciones de
su entorno, cambiando si es preciso sus procesos a aquellos que mejor aborden los
retos y problemas a los que se enfrentan.

64
5.3. Á reas de Proceso CMMI y SCRUM
En esta sección veremos c ómo se pueden SCRUM en las á reas de proceso
CMMI. De las 17 á reas de proceso descritas en CMMI-DEV no en todas podremos
aplicar métodos ágiles, ni tampoco será posible aplicar metodolog´ıas de trabajo
á gil a todas las prácticas asociadas a las á reas de proceso.
Se ha elegido SCRUM como metodolog´ıa ágil por su amplia implantación y
popularidad. Otros métodos á giles tendrán otro tipo de relación con CMMI ya
que no todos ellos cubren las mismas etapas del desarrollo.

5.3.1. Project Planning (PP) y SCRUM

Práctica Especı́fica (PP) SCRUM

SP 1.1 Estimar el alcance del Quedar´ıa cubierto en la fase pregame de SCRUM
proyecto. en la que se define el backlog y los sprints. Ambos
permiten realizar estimaciones del alcance.
SP 1.2 Establecer una estimación SCRUM realiza una estimación inicial en el
del trabajo y las tareas a realizar pregame que es refinada posteriormente en las
reuniones de inicio de sprint.
SP 1.3 Definir las fases del ciclo Queda cubierto por el propio ciclo de vida
de vida del proyecto SCRUM
SP 1.4 Estimar los costes Quedan estimados a nivel a nivel de producto en
la reunión pregame y al comienzo de cada sprint.
La estimación se realiza a partir de las historias
de usuario.
SP 2.1 Establecer el calendario y En el pregame se establecen hitos, (sprint goals),
los costes del proyecto un calendario (sprints) y restricciones y presu-
puesto de acuerdo al backlog.
SP 2.2 Identificar los riesgos Los riesgos se identifican mediante los impedi-
mentos y registrados en la “lista de impedimen-
tos”. La identificación no es sistemática. Se hace
de manera continua a lo largo del proyecto en las
reuniones diarias. El ScrumMaster es el respon-
sable de esta tarea.
SP 2.3 Planificar la gestión de No abordado
datos
SP 2.4 Planificar los recursos del De nuevo en la fase de pregame se identifican las
proyecto primeras necesidades del proyecto. En las reunio-
nes diarias nuevas necesidades son identificadas y
puestas en conocimiento del ScrumMaster.
SP 2.5 Planificar las habilidades No abordado
y conocimientos necesarios

65
SP 2.6 Planificar la participación Normalmente participan en las reuniones que se
de los involucrados realizan al comienzo y al finalizar cada sprint.
Esta participación es responsabilidad del Scrum-
Master.
SP 2.7 Establecer el plan de pro- Se podr´ıa decir que la visión de producto y el bac-
yecto klog permiten definir un plan de proyecto, aunque
este plan es ciertamente difuso.
SP 3.1 Revisar los planes que Se llevan a cabo en las reuniones de planificación
puedan afectar al proyecto y en las reuniones retrospectivas.
SP 3.2 Poner de acuerdo el tra- Ocurren durante las reuniones de planificación
bajo y los recursos compartidos dado que el backlog es dinámico y por tanto los
plazos son continuamente reestimados.
SP 3.3 Obtener compromiso de Se obtiene de manera informar con las reuniones
acuerdo para el plan de proyecto que se mantienen entre los involucrados del pro-
yecto.

Cuadro 5.1: Mapeo de SCRUM en á rea de proceso (PP)

5.3.2. Project Monitoring and Control (PMC) y SCRUM

Reuniones diarias y retrospectivas.

Reuniones diarias y retrospectivas

No abordado
Reuniones retrospectivas

revisi

Reuniones de

Revisiones diarias y retrospectivas

Reuniones de

Reuniones retrospectivas

Cuadro 5.2: Mapeo de SCRUM en á rea de proceso (PMC)

66
5.3.3. Requirements Management (REQM) y SCRUM

Práctica Especı́fica (REQM) SCRUM

SP 1.1 Comprender los requisitos Historias de usuario de forma iterative
SP 1.2 Obtener compromisos pa- Reuniones de planificación. Backlogs
ra los requisitos
SP 1.3 Gestionar los cambios de Reuniones de planificación y revisión
requisitos
SP 1.4 Mantener una trazabili- Historias de usuario
dad bidireccional o de los requi-
sitos
SP 1.5 Asegurar alineamiento en- Pregame y reuniones de planificación
tre el trabajo del proyecto y los
requisitos

Cuadro 5.3: Mapeo de SCRUM en á rea de proceso (PMC)

5.4. Ejemplo Práctico de CMMI Á gile

La literatura actual sobre CMMI á gil se centra en diferentes frentes de con-
tacto entre ambos mundos. Tenemos publicaciones que muestran cómo satisfacer
las áreas de proceso de CMMI mediante metodolog´ıas ágiles como SCRUM [75]
[76] [77], o con diversas metodolog´ıas ágiles [78]. Existe también abundante litera-
tura sobre los resultados de aplicar metodolog´ıas ágiles en organizaciones CMMI
[79], o experiencias concretas de sectores diversos como el desarrollo de software
de automoción [80], de defensa [81] o de desarrollo web [82] por citar algunos.
T´ıpicamente se aborda el nivel 2 de madurez CMMI, ya que las metodolog´ıas á gi-
les suelen cubrir las á reas de proceso de este nivel. No obstante, existe literatura
acerca de cómo emplear técnicas ágiles, o modificaciones de metodolog´ıas ágiles,
para conseguir niveles superiores de madurez [83] [84].
En todos estos casos se suele evaluar la mejora en el proceso software a partir de
la implantación del CMMI á gil de acuerdo a una serie de parámetros observables.
Sin embargo, a juicio del autor, no se ha estudiado en profundidad y de manera
detallada cómo llevar a cabo la puesta en marcha del CMMI á gil. En esta sección
se analizará las técnicas concretas necesarias para que una organización implante
un proceso de desarrollo software ágil capaz de satisfacer los requisitos CMMI.

5.4.1. Escenario base

Vamos a considerar el desarrollo de una aplicación compleja en la que es nece-

sario involucrar a diversos equipos de desarrollo responsables de diferentes subsis-
temas que deben colaborar entre s´ı.
En este caso vamos a plantear el desarrollo de un sistema de captura, env´ıo, pro-

67
cesado y almacenamiento de información. Los datos serán capturados por sensores
que se encontrarán ubicados en cualquier punto geográfico reportando medidas a
un servidor central. El servidor central podrá recibir información en cualquier
momento de diferentes sensores, procediendo al procesado de la información, la
toma de decisiones en virtud de los resultados obtenidos tras el procesado y el
almacenamiento de toda la información para posteriores análisis o consultas. Para
implementar el sistema lo descompondremos en subsistemas m á s simples, de tal
forma que diferentes equipos de desarrollo puedan participar en paralelo en la im-
plementación. De esta forma los subsistemas que constituyen la solución completa
son:

Interfaz de usuario. Podr´ıa ser una interfaz de escritorio, web o aplicación

móvil, en este caso hemos seleccionado que sea una aplicación web. Las
aplicaciones web suelen dividirse a su vez en dos partes:

• Frontend. Correspondiente a la parte gráfica.

• Backend. Correspondiente a la parte lógica encargada de interpretar
las acciones del usuario.

Módulo de procesado. Correspondiente a la parte lógica encargada de

interpretar las acciones del usuario

Fuente de datos. Software ubicado en algú n dispositivo remoto que pro-

duce información.

El proceso de desarrollo software se llevará a cabo mediante SCRUM. En este

caso ya que el desarrollo está dividido en diferentes equipos tendremos lo que se
conoce como un SCRUM de SCRUMs. Se llevarán a cabo reuniones periódicas,
entre dos y tres a la semana, con una duración de entre 30 y 60 minutos a las que
acudirá un miembro de cada equipo para tratar aquellos temas que sean comunes.
Normalmente en las reuniones diarias SCRUM no se tratan de buscar soluciones,
sin embargo, en este tipo de reuniones si es que se deben establecer soluciones
concretas a los problemas detectados. Esto es as´ı para que la información fluya
rápidamente entre todos los equipos y poder detectar posibles incompatibilidades
entre subsistemas.

5.4.2. Implementación CMMI y SCRUM: Gestión del pro-

yecto

A la hora de gestionar proyectos se hace indispensable el uso de herramientas

software que permiten al director del proyecto gestionar los diferentes procesos
involucrados. Tradicionalmente, herramientas como Microsoft Project u Oracle
Primavera han sido empleadas para la gestión de todo tipo de proyectos, sin
embargo, en los últimos añ os han aparecido otras herramientas para la gestión de
proyectos ágiles que se adaptan mejor a nuestro escenario. Entre el amplio abanico
de candidatos disponibles, dos herramientas destacan sobre el resto

68
 Asana. Es simple de utilizar y se puede integrar con otras herramientas de
desarrollo software en la nube como GitHub, Slack, Okta, Google Drive, etc.
Atlassian JIRA. Forma parte del conjunto de aplicaciones de Atlassian
(muy centrados en el apoyo al desarrollo de software), que pueden ser utili-
zadas tanto en la nube como en datacenters privados. JIRA es m á s compleja
que Asana y requiere de un mayor esfuerzo tanto por parte del encargado
del proyecto como del resto de participantes.

En nuestro caso, emplearemos JIRA junto con Microsoft Project, buscando de

alguna manera reflejar también a nivel de software las sinergias que aparecen entre
la visión clásica de gestión de proyectos y el enfoque á gil. Microsoft Project nos
permitirá llevar el seguimiento de m á s alto nivel del proyecto, desde las primeras
fases de creación de equipos, definición de objetivos de muy alto nivel, elaboración
del presupuesto, etc, pasando por los principales hitos del desarrollo, hasta el
cierre y entrega del proyecto al cliente. Cada paquete de trabajo de la WBS se
gestionará a través de JIRA de forma ágil. Gracias a la posibilidad de conectar
Project y JIRA podremos de forma automática sintetizar toda la información JIRA
correspondiente a un paquete de trabajo y enviarlo a Project para que actualice el
estado del proyecto. Esta forma de trabajo encajará perfectamente en el equilibrio
que perseguimos entre CMMI y SCRUM.
JIRA gira en torno al concepto de issue. La issue permite modelar diferentes
conceptos sujetos a un ciclo de vida, por ejemplo, una petición de cambio, un
bug, una reunión, un informe, etc. JIRA proporciona una serie de issues por
defecto y permite al mismo tiempo crear nuevas issues con su lógica y ciclo de
vida asociado. De esta forma podremos crear issues para cumplir con las á reas
de proceso de CMMI y con la metodolog´ıa SCRUM. De esta forma definiremos la
siguientes issues:

Story (US). Describirá una historia de usuario que contendrá un requisito

a implementar descrito en unas frases breves empleando un lenguaje no
técnico. Dentro de esta historia de usuario se irán creando sub tareas que
representarán elemento de trabajo necesarios para satisfacer la historia de
usuario.
Epic (EP). Representa una porción de trabajo extensa. Se puede enten-
der como una historia de usuario m á s amplia de la habitual y que podr´ıa
descomponerse en otras m á s simples. Podr´ıa darse el caso de que esta issue
afecte a m á s de un proyecto o que fuesen necesarios m á s de un sprint para
completarla.
Technical Task (TT). Las tareas técnicas son aquellos trabajos necesarios
para el proyecto pero que no se corresponden con ninguna funcionalidad del
producto o servicio sobre el que se e sté trabajando. Un ejemplo podr´ıa ser
la preparación de un entorno de desarrollo, la configuración de los equipos
de red, la instalación de un software determinado, etc.
Change Request (CR). Permite realizar un seguimiento de una petición
de cambio.

69
 Risk (RSK). Esta issue modelará los riesgos potenciales del proyecto y
permitirá hacer seguimiento de los mismos. Un ejemplo de aplicación es
cuando se procede a realizar un merge entre dos ramas de desarrollo del
repositorio de código fuente.

Meeting (MT). Permite realizar el seguimiento de las reuniones, incorporar

un acta y registrar el tiempo empleado en cada una

Bug (BG). Se empleará para realizar el seguimiento de la corrección de

defectos encontrados.

Corrective Action (CA). Cualquier acción correctiva que sea preciso rea-
lizar s erá modelada con esta issue.

Noncomplieance (NC). Las no conformidades detectadas dispondrán de

una issue particular.

5.4.3. Implementación CMMI y SCRUM: Entorno de desa-

rrollo

Una vez visto el entorno software de gestión veremos ahora q ué herramientas y
q ué arquitectura se empleará para que los analistas y programadores lleven a cabo
el trabajo de desarrollo de forma ágil adhiriéndose al mismo tiempo a CMMI.

70
119

Figura 5.1: Entorno de desarrollo CMMI á gil.

 La figura 5.1 resume el entorno de desarrollo propuesto. Veamos a continuación
los pasos que se siguen.

1. Los desarrolladores programarán en sus equipos los requisitos contenidos en

las historias de usuario mediante el empleo de un entorno de desarrollo inte-
grado o IDE. Actualmente los IDE son programas muy potentes que ayudan
al programador en la tarea de programar indicándoles errores potenciales
mientras escribe código, simplificándole tareas repetitivas, formateando el
codigo de acuerdo a gu´ıas de estilo, automatizando procesos como la com-
pilación, la ejecución de tests etc. Es habitual permitir al programador que
elige el IDE que quiera usar siempre y cuando el código que se genere sea
homogéneo y cumpla con la gu´ıa de estilo establecida. La gu´ıa de estilo es
un documento que debe redactarse antes de comenzar la fase de desarrollo
y que estipula q ué convención se debe emplear a la hora de formatear el
codigo, el patrón de nombrado de los ficheros, variables, funciones, clases y
otros elementos, la codificación de los ficheros, la longitud máxima de las
l´ıneas, el espaciado, etc.
2. El código generado es el activo m á s importante dentro de un proyecto soft-
ware y por consiguiente debe ser salvaguardado de la mejor manera posible
para protegerlo frente a posibles pérdidas intencionadas o no sin que, al mis-
mo tiempo, suponga un lastre o un problema para los desarrolladores. Por
esto, se han desarrollado los repositorios de código, que son bases de datos
en las que se almacena el código de manera versionada, es decir, cada cambio
realizado en un fichero y enviado al repositorio es registrado de forma que
es posible recuperar en cualquier momento el fichero en un momento de su
historia. Además, los repositorios permiten que un mismo fichero evolucione
a partir de un mismo punto de dos o m á s formas mediante el concepto de
ramas y llegado el momento pueda volver a fusionarse. El concepto de ramas
se adapta perfectamente a la metodolog´ıa SCRUM, se puede crear una rama
por historia de usuario o por sprint. Existen varias tecnolog´ıas y soluciones
software, a continuación, se citan las m á s relevantes y la elegida en nuestro
caso:
a) Subversion. Es una tecnolog´ıa cliente/servidor, esto quiere decir que
existe un ú nico almacén (servidor) que guarda el código.
b) Git. Por contraposición a la anterior, esta tecnolog´ıa es distribuida, esto
quiere decir que cada usuario guarda toda la información y los cambios
se sincronizan posteriormente. Será nuestra solución elegida ya que se
adapta muy bien a las metodolog´ıas de desarrollo á gil.
c) Mercurial. Es una solución similar en filosof´ıa a git, aunque con menor
cuota de mercado. La descartamos por su bajo nivel de implantación.
El código fuente estará formado por diferentes lenguajes de programación
dependiendo del módulo software. A continuación, enumeramos los lenguajes
elegidos por sistema
a) Interfaz de usuario frontend. Existe prácticamente una opción ma-
yoritaria que es el empleo de Javascript junto con alguno de sus librer´ıas
m á s utilizadas que quedará a elección de los programadores.

120
 b) Interfaz de usuario backend. Existe una amplia variedad de lengua-
jes de programación que podr´ıan ser empleados para este módulo, la
elección se debe hacer en virtud de los programadores disponibles, la
complejidad esperada, el volumen de información a gestionar, la futura
escalabilidad y mantenimiento del sistema, etc. Algunos de los lenguajes
m á s habituales son: Java, PHP, Ruby, Python, Scala, Perl y Javascript.
En nuestro caso vamos a proponer el empleo del lenguaje Python ya
es un lenguaje cada vez m á s popular, lo que nos garantiza encontrar
programadores, permite hacer desarrollos rápidos gracias a su sencillez
y al gran nú mero y calidad de las librer´ıas disponibles y presenta un
rendimiento aceptable.
c) Módulo de procesado. a. El módulo de procesado requiere de un len-
guaje eficiente y con capacidad para comunicarse con bases de datos y
otros subsistemas. Entre los lenguajes que podr´ıamos emplear tenemos
C++, Java o Scala. El primero, C++, es sin duda el m á s eficiente, pero
dispone de pocas librer´ıas disponibles para el procesado de datos. Tanto
Java como Scala son dos opciones muy similares y muy empleadas en
el procesado de datos. Nos decantaremos por Java por la gran cantidad
de programadores disponibles en el mercado.
d) Fuente de datos. Los dispositivos encargados de capturar datos son
aparatos con serias limitaciones en cuanto a procesador y memoria. Es
por esto que un lenguaje como C++ caracterizado por aprovechar al
máximo el hardware disponible se convierte en una solución ideal.

3. Integración continua. El código almacenado en el repositorio se aseme-

ja a una receta de cocina, contiene la descripción y los pasos para llevar
a cabo un plato, pero alguien debe encargarse de realizar ese trabajo. La
tarea de traducir el código en software, entendiendo software no solo como
un ejecutable capaz de realizar una tarea sino como la suma de ejecutables y
documentación asociada, es responsabilidad del módulo de integración con-
tinua. Este módulo se encarga de generar la documentación automática, el
análisis estático de código (responsable de verificar que las gu´ıas de estilo se
cumplen y de detectar errores de programación por observación), compilar
el código fuente en binarios ejecutables, realizar las pruebas unitarias, fun-
cionales y de integración, generar los componentes entregables y desplegar
por último dichos componentes en diferentes entornos y realizar informes con
los resultados de todas las operaciones llevadas a cabo. Este módulo cumple
con muchos objetivos planteados tanto por las metodolog´ıas ágiles como por
parte de CMMI. Existen diferentes soluciones software que podr´ıan satis-
facer nuestros objetivos, destacamos a continuación, las dos soluciones m á s
populares y utilizadas

a) Jenkins. a. Uno de los m á s extendidos y populares. Originalmente

desarrollador por Sun Microsystems (actual Oracle), permite realizar
casi cualquier tarea de integración continua gracias al amplio número de
plugins que le permiten interactuar con diferentes herramientas. Podr´ıa
ser una solución perfectamente válida, es de código abierto y por tanto
no se requiere de licencia.

121
 b) Bamboo. Es el sistema de integración continua de Atlassian, creador de
JIRA. Es similar en prestaciones a Jenkins y al formar parte de la suite
de Atlassian nos permite integrarlo con JIRA con mayor facilidad. A
diferencia de Jenkins es una herramienta de pago. Será nuestra elección
por las facilidades que tendremos para integrarlo con JIRA.

En el módulo de integración continua se llevarán a cabo una serie de prue-

bas software, tanto pruebas unitarias como funcionales y de integración.
Para dar soporte a estas pruebas se emplearán herramientas espec´ıficas que
dependerán del lenguaje de programación empleado. En el cuadro 5.4 se
muestra un resumen de las herramientas por lenguaje a utilizar. Junto con
las pruebas el módulo generará documentación de forma automática a partir
de los comentarios introducidos por los programadores. La documentación
se generar en formato web, de manera que los programadores dispondrán de
un enlace web en el que podrán consultar el cometido de cada clase, fun-
ción o variable documentada. Además, para garantizar la calidad del código
se emplearán herramientas que velarán porque el código cumpla las normas
definidas en las gu´ıas de estilo.

4. Despliegue. El módulo de integración continua genera ejecutables, scripts,

documentación y otros artefactos que deben ser desplegados para poder ser
puestos en marcha. Habitualmente se crea un entorno de desarrollo o prue-
bas en donde se despliegan los componentes para evaluar su comportamiento
o para mostrárselos al cliente antes de llevarlos al entorno real. En cualquier
caso, estos entornos requieren de una infraestructura: sistema operativo, ser-
vidores web, bases de datos, gestores de colas, etc y la configuración asociada
a estos elementos. Para facilitar el despliegue y que este sea automático se
empleará software espec´ıfico. Esto permitirá que las pruebas y entregas de
nuevas versiones se automática y muy rápida. Existen diferentes soluciones:

a) Docker. Es un sistema de contenedores que permite desplegar aplica-

ciones complejas de forma muy sencilla y automática. Los contenedores
simulan un entorno de trabajo independientemente del entorno de la
máquina. Esto garantiza que la aplicación siempre se despliegue de la
misma forma independientemente del sistema sobre el que se ejecute.
Será nuestra opción elegida.
b) Chef/puppet. Es un sistema para orquestar el despliegue de una apli-
cación en base a unas reglas predefinidas.

Lenguaje P. Unitarias P. Funcionales Documentación Guı́a Estilo

C++ Catch Google Test Doxygen CppCheck
Java JUnit Cucumber Javadocs Checkstyle
Python PyTest Selenium Sphinx PEP8
Javascript Karma Selenium JSDoc JSLint

Cuadro 5.4: Herramientas utilizadas en la integración continua por lenguaje.

122
5.4.4. Implementación CMMI y SCRUM: Proceso de desa-
rrollo.

Como ya hemos mencionado la gestión del proyecto tendrá tanto una vertiente
clásica como una m á s ágil. La gestión clásica aborda los aspectos de m á s alto nivel
del proyecto, cómo resultado podremos descomponer las actividades a realizar en
la estructura de descomposición de tareas conocida como WBS, ver figura 5.2.

123
 WBS Proyecto Software

1. Gesti´on 3. Desarrollo 4. Desarrollo

2. Ingenier´ıa 5. Pruebas 6. Documentación 7. Despliegue
de proyecto Software Hardware

2.1 Requisitos de 3.1 Interfaz usuario 4.1 Equipo 5.1 Pruebas 6.1 Documentaci´on 7.1 Gesti´on de
1.1 Planificaci´on
alto nivel frontend captura datos funcionales desarrollo despliegue

1.2 Gesti´on de 2.2 Elementos 3.2 Interfaz usuario 4.2 Equipo 5.2 Pruebas 6.2 Documentaci´on 7.2 Despliegue
plazos y costes Reutilizables backend comunicaciones rendimiento instalaci´on pruebas y QA

1.3 Gesti´on del 2.3 Arquitectura 3.3 M´odulo 5.3 Pruebas 6.3 Manuales 7.3 Despliegue
124

alcance de alto nivel de procesado aceptaci´on de usuario producci´on

1.4 Gesti´on de 3.4 M´odulo 7.4 Formaci´on

recursos humanos captura datos cliente

1.5 Gesti´on de 3.5 Desarrollo 7.5 Entrega y

riesgos de simuladores aceptaci´on

1.6 Gesti´on de
recursos

1.7 Gesti´on de
calidad

Figura 5.2: Ejemplo WBS de un proyecto software.

 El director del proyecto, como responsable del proyecto es quien se encarga de
elaborar la WBS, para ello se apoya en Microsoft Project como herramienta de
gestión. A partir de este punto, aquellos paquetes de trabajo relacionados con el
desarrollo de software, como “Entorno de pruebas”, “Interfaz usuario Frontend”,
“pruebas funcionales”, etc se gestionarán a través de JIRA. Mediante un conector
JIRA/MS Project el director de proyecto podrá disponer de una actualización de
los datos del proyecto en MS Project a partir de los datos introducidos en JIRA.
En este TFM nos centraremos en la parte á gil, por lo que asumiremos que la
parte inicial del proyecto ya se ha llevado a cabo. Asumimos por tanto que antes
de comenzar el proyecto se ha realizado el estudio de lo que el cliente desea hacer,
en virtud de lo cual se hacen estimaciones iniciales de plazos, costes, nú mero de
personal requerido y cualificación del mismo. Nos encontramos por tanto en la
fase de desarrollo de requisitos y software que hemos decidido hacer de manera
á gil mediante SCRUM respetando la filosof´ıa CMMI.

Iteración Inicial

La primera tarea será de la comenzar a profundizar en los requisitos, descom-

poniendo las ideas y requisitos de alto nivel en otros de m á s bajo nivel. Para ello
se realiza un sprint inicial con el objetivo de definir el “Release plan”, es decir,
el nú mero de iteraciones, y el nú mero de elementos de alto nivel que se prevén
entregar en cada una de las interacciones. Durante el transcurso del sprint apare-
cerán preguntas y dudas que se consultarán con el cliente, y al finalizar el sprint se
realizará una reunión con el propio cliente para que este valide los requisitos reco-
pilados, si bien es cierto que este tipo de reuniones se seguirán realizando a lo largo
del proyecto, esta es de vital importancia porque los errores en las etapas iniciales
del proyecto tienen un mayor impacto. Esto permite cubrir los objetivos espec´ıficos
SP1.1 y SP 1.2 del á rea de proceso Requirements Management: “Comprender los
requisitos” y “obtener compromisos para los requisitos”. Las reuniones constantes
con el cliente en este sprint y sucesivos permite satisfacer el punto SP1.5 “asegurar
el alineamiento entre el trabajo y los requisitos”.

Iteración de desarrollo

Nos encontramos ahora en pleno proceso de desarrollo y acabamos de comen-

zar un nuevo sprint SCRUM. Fruto de este sprint elaboraremos una historia de
usuario, la cual tendrá una issue JIRA asociada en la que estimaremos en su crea-
ción el tiempo en horas que esperamos emplear. Las historias de usuarios serán
codificadas para facilitar referirse a ellas.
Una vez definida la historia de usuario el desarrollador creará una subtarea
asociada. Esta subtarea es un trabajo concreto y bien definido necesario para
satisfacer parte de la historia de usuario, por ejemplo, una subtarea podr´ıa consistir
en programar la lógica encargada de procesar un formulario web. JIRA generará
un código asociado a cada subtarea en el momento de su creación.
El siguiente paso es que el desarrollador programe la lógica y las pruebas unita-
rias asociadas. Una vez finalice deberá enviar el nuevo código fuente al repositorio

125
de código, lo que se suele denominar commitear. Todo commit al repositorio va
acompañado de un mensaje. El repositorio (git en nuestro caso) verificará que el
comentario se ajusta a un patrón espec´ıfico: “[CODIGOSUBTASK][REQ-XXXX]
texto”, de esta forma JIRA es capaz de relacionar el código fuente que implemen-
ta una subtask de una historia de usuario concreta. As´ı es como satisfacemos el
SP1.4 “mantener la trazabilidad bidireccional de los requisitos” del á rea de proce-
so REQM. Por último, los cambios de requisitos se verán registrados en el propio
registro de la issue, satisfaciendo el SP 1.3 de REQM.

Corrección de errores y no conformidades

Aunque los errores y no conformidades son conceptos diferentes, ambos son

tratados de la misma forma (cada uno a través de su respectiva issue) en JIRA.
Los dos son programados y planificados en la reunión del sprint. Los cambios
necesarios en el código son commiteados siguiendo el mismo patrón, sin embargo,
estos cambios se realizarán en una rama del código diferente y solo una vez el
equipo de pruebas da por válida la solución los cambios serán llevados a la rama
de desarrollo. Con este mecanismo quedan cubierto el SP 2.2 de PPQA “establecer
registros”.

Integración continua

Cada noche el servidor Bamboo accederá al repositorio y se descargará la

ú ltima versión del código fuente. A continuación, procederá compilarlo, y luego
a realizar las pruebas. Estas pruebas serán las pruebas unitarias desarrolladas
por los programadores y las pruebas funcionales, de integración y rendimiento
diseñadas tanto por los programadores como por parte del equipo de QA. Con esto
se satisface parcialmente la SP1.2 de PPQA “Evaluación objetiva de productos
de trabajo”. También se aplican las herramientas responsables de garantizar que
el código sigue las gu´ıas de estilo y se genera la documentación del código. Como
resultado Bamboo generará un informe con los resultados indicando si algú n paso
no fue satisfactorio. Este informe llegará v´ıa email cada mañ ana a los responsables
del proyecto, de forma que pueda ser discutido en la reunión diaria SCRUM y en
caso de existir algú n problema se adopten las medidas adecuadas. Las medidas a
adoptar se verán reflejadas en algú n tipo de issue. Con esto podremos satisfacer
parcialmente las SP 2.1 y SP 2.2 del área de proceso PPQA: “Comunicar y resolver
no conformidades” y “Establecer registros”.

Despliegue

Si las pruebas son superadas satisfactoriamente Bamboo procederá a desplegar

la aplicación. Antes de realizar el despliegue Bamboo crear los paquetes e imágenes
Docker necesarias y los almacena en un “servidor de versiones”. La idea es tener
tantas versiones del sistema como compilaciones satisfactorias hemos tenido, con
el objetivo de poder realizar análisis de la evolución del sistema. Esto puede ser
muy ú til a la hora de detectar problemas de rendimiento entre versiones, dif´ıciles
de detectar en la etapa de pruebas y que solo aparecen en entornos de pruebas m á s

126
complejos o en producción. Estas versiones serán internas al equipo de desarrollo,
el cliente recibirá las versiones fruto de un sprint completo, las cuales seguirán un
esquema de numerado predefinido.

127
Capı́tulo 6

Conclusiones Finales y Lı́neas de

Futuro

6.1. Conclusiones
En este TFM hemos abordado dos temas de gran importante dentro de la in-
genier´ıa de software. Por un lado, hemos visto en q ué consisten las metodolog´ıas
ágiles de desarrollo y q ué las hace tan diferentes de los métodos de desarrollo tra-
dicionales. Por otra parte, hemos puesto nuestra atención en el proceso software
y hemos visto cómo el marco de trabajo CMMI podr´ıa ser una herramienta ú til
para ayudarnos a conseguir que los proyectos software que lleva a cabo una or-
ganización ganen en capacidad y madurez. Si nos hubiéramos deteniendo en este
punto, el TFM pasar´ıa por ser un mero trabajo descriptivo del estado del arte de
las metodolog´ıas ágiles y CMMI. Sin embargo, hemos visto cómo es posible que al
mismo tiempo que el proceso software se adhiere a la filosof´ıa formal de CMMI,
los trabajos de desarrollo puedan llevarse a cabo mediante el empleo de filosof´ıas
ágiles.

Los proyectos software, a diferencia de otros llevados a cabo en otras ramas

de la ingenier´ıa, poseen una complejidad inherente

La ingenier´ıa de software es una rama de la ingenier´ıa que se enfrente a

proyectos de enorme complejidad, y por tanto no existen soluciones estan-
darizadas, formas de trabajo o buenas prácticas que puedan ser aplicables
independientemente de la naturaleza del proyecto, la organización o el en-
torno.

A la hora de escoger las herramientas m á s adecuadas para llevar a cabo

un proyecto software es importante conocer la dimensión y requisitos del
proyecto. Como hemos señalado a lo largo del TFM, los proyectos de soft-
ware cr´ıtico en tiempo real no pueden ser gestionado de igual forma que un
proyecto de un portal web.

La gestión del proceso software es de capital importancia para aumentar el

éxito del proyecto. Y por éxito debemos entender que el proyecto cumple

128
 con las expectativas del cliente. Sin embargo, a diferencia de otros tipos de
proyectos el software es un producto intelectual por lo que disponer de un
personal lo suficientemente capacitado contribuirá en gran medida a alcanzar
el éxito.

CMMI y las metodolog´ıas á giles si se utilizan correctamente pueden ayudar

a las organizaciones a que sus proyectos alcancen un equilibrio óptimo. Por
un lado, los procesos son controlados, gestionados, medidos y analizados
de forma sistemática e institucionalizada, y por otro, la agilidad permite
reducir trabas burocráticas, formalismos innecesarios y otros impedimentos
que lastran el rendimiento del proyecto.

Combinar CMMI y agile, puede ayudar también a que las organizaciones

sean capaces de responder m á s rápidamente a cambios en su entorno. Los
grandes proyectos software, aquellos que se desarrollan a lo largo de añ os o
que se basan en la evolución de sistemas legados, se pueden beneficiar de la
aplicación de metodolog´ıas ágiles, ya que están suelen generar sistemas m á s
modulares y fáciles de mantener y evolucionar.

Cualquier desarrollo profesional de software involucra un nú mero conside-

rable de procesos a desarrollar y por tanto disponer de un marco probado
de trabajo como CMMI para optimizar estos procesos es una herramienta
que cualquier organización dedicada al desarrollo software deber´ıa plantearse
usar.

6.2. Lı́neas de Futuro

Si existe una rama de la ingenier´ıa en constante evolución, sin duda, es la inge-
nier´ıa de software. Cada a ñ o surgen nuevas ideas y tecnolog´ıas que desfasan a otras,
y en ocasiones, otras abandonadas durante décadas vuelven a tener una segunda
oportunidad, en este trabajo hemos mencionado como los métodos incrementales,
precursores de los ágiles, hab´ıan sido propuesto décadas antes de alcanzar la po-
pularidad y extensión que han tenido en los últimos añ os. No cabe duda que tanto
los métodos á giles como CMMI evolucionarán en los próximos añ os y que durante
el camino aparecerán nuevas oportunidades para mejorar su sinton´ıa.
En este TFM hemos visto cómo abordar la mejora de procesos con CMMI en
combinación con la metodolog´ıa de desarrollo ágil SCRUM en las á reas de proceso
CMMI m á s importantes correspondiente a los niveles de madurez 2 y 3. Quedar´ıa
por explorar c ómo pueden ser usados junto a CMMI otras metodolog´ıas ágiles
como ASD, AUP, XP o DSDM.
Otra posible l´ınea de investigación es cómo afecta a la agilidad del proyecto
la adopción de diferentes niveles de madurez. Los niveles 4 y 5 requieren de un
control estad´ıstico de los procesos y el uso de otras herramientas cuantitativas que
sin duda afectarán de algú n modo a la agilidad.
Por último, mencionar que el nú mero de experiencias de implantación de CMMI
á gil publicadas es todav´ıa escaso. Es cierto que en los últimos añ os su nú mero ha

129
crecido, pero se echa en faltan ciertos aspectos, como cuantificar el impacto que
ha tenido la adopción.

130
Bibliografı́a

[1] Andrew Hunt. The pragmatic programmer. Pearson Education India, 2000.
[2] Project Management Institute. A Guide to the Project Management Body of
Knowledge: PMBOK(R) Guide. 5th. Project Management Institute, 2013.
ISBN: 1935589679, 9781935589679.
[3] EN Iso. ‹9000: 2005 ›. En: Quality management systems-Fundamentals and
vocabulary (ISO 9000: 2005) (2005), pág. 1.
[4] CMMI Product Team. CMMI for Development, Version 1.3 (CMU/SEI-
2010-TR-033). Software Engineering Institute. 2010.
[5] International Project Management Association, Gilles Caupin y col. IPMA
competence baseline: ICB; Version 3.0. Internat. Project Management As-
sociation, 2006.
[6] AN ISO. ‹21500: 2012 ›. En: Guidance on project management (2012).
[7] Edsger W Dijkstra. ‹The humble programmer ›. En: Communications of the
ACM 15.10 (1972), págs. 859-866.
[8] Pierre Bourque, Richard E Fairley y col. Guide to the software engineering
body of knowledge (SWEBOK (R)): Version 3.0. IEEE Computer Society
Press, 2014.
[9] James Johnson y col. ‹The chaos report ›. En: Standishgroup. com (1994).
[10] Magne Jørgensen y Kjetil Moløkken-Østvold. ‹How large are software cost
overruns? A review of the 1994 CHAOS report ›. En: Information and Soft-
ware Technology 48.4 (2006), págs. 297-301.
[11] Kjetil Molokken y Magen Jorgensen. ‹A review of software surveys on soft-
ware effort estimation ›. En: Empirical Software Engineering, 2003. ISESE
2003. Proceedings. 2003 International Symposium on. IEEE. 2003, págs. 223-230.
[12] J Laurenz Eveleens y Chris Verhoef. ‹The rise and fall of the chaos report
figures ›. En: IEEE software 27.1 (2010), págs. 30-36.
[13] Barry W. Boehm. ‹Software Engineering-as It is ›. En: Proceedings of the
4th International Conference on Software Engineering. ICSE ’79. Munich,
Germany: IEEE Press, 1979, págs. 11-21. URL: http : / / dl . acm . org /
citation.cfm?id=800091.802916.
[14] Ian Sommerville. ‹Software Engineering. International computer science se-
ries ›. En: ed: Addison Wesley (2004).
[15] Richard H Thayer, Sidney C Bailin y M Dorfman. Software requirements
engineerings. IEEE Computer Society Press, 1997.

131
[16] Barry Boehm. ‹Software risk management ›. En: ESEC’89 (1989), págs. 1-19.
[17] Vincent Massol y Ted Husted. JUnit in action. Manning Publications Co.,
2003.
[18] Winston W Royce y col. ‹Managing the development of large software sys-
tems ›. En: proceedings of IEEE WESCON. Vol. 26. 8. Los Angeles. 1970,
págs. 1-9.
[19] Herbert D Benington. ‹Production of large computer programs ›. En: Annals
of the History of Computing 5.4 (1983), págs. 350-361.
[20] Thomas E Bell y Thomas A Thayer. ‹Software requirements: Are they really
a problem? › En: Proceedings of the 2nd international conference on Software
engineering. IEEE Computer Society Press. 1976, págs. 61-68.
[21] Gene Kim. ‹DevOps distilled, Part 1: The three underlying principles ›. En:
(2013). URL: https : / / www . ibm . com / developerworks / library / se -
devops/part1/part1-pdf.pdf.
[22] Barry Boehm. ‹A spiral model of software development and enhancement ›.
En: ACM SIGSOFT Software Engineering Notes 11.4 (1986), págs. 14-24.
[23] Barry W. Boehm. ‹A spiral model of software development and enhance-
ment ›. En: Computer 21.5 (1988), págs. 61-72.
[24] Per Kroll y Philippe Kruchten. The rational unified process made easy: a
practitioner’s guide to the RUP. Addison-Wesley Professional, 2003.
[25] UML Revision Taskforce. ‹OMG UML Specification v. 1.4 ›. En: Object Ma-
nagement Group (2001).
[26] Ivar Jacobson y col. The unified software development process. Vol. 1. Addison-
wesley Reading, 1999.
[27] Scott Ambler, John Nalbone y Michael Vizdos. Enterprise unified process,
the: extending the rational unified process. Prentice Hall Press, 2005.
[28] Harlan D Mills, Michael Dyer y Richard C Linger. ‹Cleanroom software
engineering ›. En: IEEE Software 4.5 (1987), pág. 19.
[29] Jane Radatz, Myrna Olson y Stuart Campbell. ‹Mil-std-498 ›. En: Crosstalk,
the Journal of Defense Software Engineering 8.2 (1995), págs. 2-5.
[30] Leanna Rierson. Developing safety-critical software: a practical guide for
aviation software and DO-178C compliance. CRC Press, 2013.
[31] Craig Larman y Victor R Basili. ‹Iterative and incremental developments.
a brief history ›. En: Computer 36.6 (2003), págs. 47-56.
[32] Ernest A Edmonds. ‹A process for the development of software for non-
technical users as an adaptive system ›. En: General Systems 19.215C18
(1974), pág. 8.
[33] Justus D Naumann y A Milton Jenkins. ‹Prototyping: the new paradigm
for systems development ›. En: Mis Quarterly (1982), págs. 29-44.
[34] James Martin. Rapid application development. Macmillan Publishing Co.,
Inc., 1991.
[35] K. Beck y col. The Agile Manifesto. Inf. téc. The Agile Alliance, 2001.

132
[36] A Cockburn y col. ‹The Declaration of Interdependence for Modern Manage-
ment or DOI ›. En: Online: http://alistair. cockburn. us/The+ declaration+
of+ interdependence+ for+ modern+ management+ or+ DOI (2005).
[37] RC Martin y col. ‹Manifesto for software craftsmanship ›. En: Online: http://manifesto.
softwarecraftsmanship. org (10.10. 2015) (2009).
[38] Ken Schwaber y Jeff Sutherland. ‹The scrum guide ›. En: Scrum Alliance
21 (2011).
[39] Scott Ambler. Agile modeling: effective practices for extreme programming
and the unified process. John Wiley & Sons, 2002.
[40] Jim Highsmith. Adaptive software development: a collaborative approach to
managing complex systems. Addison-Wesley, 2013.
[41] Steve R Palmer y Mac Felsing. A practical guide to feature-driven develop-
ment. Pearson Education, 2001.
[42] Kent Beck. Extreme programming explained: embrace change. addison-wesley
professional, 2000.
[43] Mary Poppendieck y Tom Poppendieck. Lean Software Development: An
Agile Toolkit: An Agile Toolkit. Addison-Wesley, 2003.
[44] H Takeuchi e I Nonaka. ‹16 The new new product development game ›. En:
Japanese Business: Part 1, Classics Part 2, Japanese management Vol. 2:
Part 1, Manufacturing and production Part 2, Automotive industry Vol. 3:
Part 1, Banking and finance Part 2, Corporate strategy and inter-organizational
relationships Vol. 4: Part 1, Japanese management overseas Part 2, Inno-
vation and learning 64.1 (1998), p ág. 321.
[45] Ken Schwaber. ‹Scrum development process ›. En: Business Object Design
and Implementation. Springer, 1997, págs. 117-134.
[46] Ken Schwaber y Mike Beedle. Agile software development with Scrum. Vol. 1.
Prentice Hall Upper Saddle River, 2002.
[47] David J Anderson. Kanban: successful evolutionary change for your techno-
logy business. Blue Hole Press, 2010.
[48] David J Anderson y Dragos Dumitriu. ‹From Worst to Best in 9 Months ›.
En: TOC ICO World Conference. 2005.
[49] Corey Ladas. ‹Scrumban ›. En: Lean Software Engineering-Essays on the
Continuous Delivery of High Quality Information Systems (2008).
[50] Mark Paulk. ‹Capability maturity model for software ›. En: Encyclopedia of
Software Engineering (1993).
[51] Mark C Paulk y col. ‹Capability maturity model, version 1.1 ›. En: IEEE
software 10.4 (1993), págs. 18-27.
[52] Bill Curtis, Bill Hefley y Sally Miller. People capability maturity model (P-
CMM) version 2.0. Inf. téc. DTIC Document, 2009.
[53] Roger Bate y col. A systems engineering capability maturity model, Version
1.1. Inf. téc. DTIC Document, 1995.

133
[54] Alec Dorling. ‹SPICE: Software process improvement and capability deter-
mination ›. En: Software Quality Journal 2.4 (1993), págs. 209-224.
[55] Pasi Kuvaja y Adriana Bicego. ‹BOOTSTRAP—a European assessment
methodology ›. En: Software Quality Journal 3.3 (1994), págs. 117-127.
[56] SEI. Capability Maturity Model Integration, version 1.1. Inf. téc. CMU/SEI-
2002-TR-011. Pittsburgh, Carnegie Mellon University: Software Engineering
Institute, 2002. URL: http://www.sei.cmu.edu/cmmi/.
[57] CMMI Product Team. ‹CMMI for Development, version 1.2 ›. En: (2006).
[58] CMMI Product Team. CMMI for Services Version 1.3. Lulu. com, 2011.
[59] CMMI Product Team. CMMI for Acquisition Version 1.3. Lulu. com, 2011.
[60] W Edwards Deming. ‹Out of the crisis, Massachusetts Institute of Tech-
nology ›. En: Center for advanced engineering study, Cambridge, MA 510
(1986).
[61] Philip B Crosby. Quality is free: The art of making quality certain. Signet,
1980.
[62] Joseph M Juran y col. Juran on planning for quality. Free Press New York,
1988.
[63] Victor R Basili y H Dieter Rombach. ‹The TAME project: Towards improvement-
oriented software environments ›. En: IEEE Transactions on software engi-
neering 14.6 (1988), págs. 758-773.
[64] Victor R Basili. Software modeling and measurement: the Goal/Question/Metric
paradigm. Inf. téc. 1992.
[65] Kevin Pulford, Annie Kuntzmann-Combelles y Stephen Shirlaw. A quantita-
tive approach to software management: the AMI handbook. Addison-Wesley
Longman Publishing Co., Inc., 1995.
[66] Stephen Viller y Ian Sommerville. ‹Ethnographically informed analysis for
software engineers ›. En: International Journal of Human-Computer Studies
53.1 (2000), págs. 169-196.
[67] David Martin y col. ‹’Good’organisational reasons for’Bad’software testing:
An ethnographic study of testing in a small software company ›. En: Procee-
dings of the 29th international conference on Software Engineering. IEEE
Computer Society. 2007, pags. 602-611.
[68] John Hughes y col. ‹Moving out from the control room: ethnography in
system design ›. En: Proceedings of the 1994 ACM conference on Computer
supported cooperative work. ACM. 1994, págs. 429-439.
[69] Business Process Model. ‹Notation (BPMN) version 2.0 ›. En: OMG Speci-
fication, Object Management Group (2011).
[70] Ian Sommerville y Pete Sawyer. Requirements engineering: a good practice
guide. John Wiley & Sons, Inc., 1997.
[71] Hillel Glazer y col. ‹CMMI or agile: why not embrace both! › En: (2008).
[72] David J Anderson. ‹Stretching agile to fit CMMI level 3-the story of creating
MSF for CMMI/spl reg/process improvement at Microsoft corporation ›. En:
Agile Conference, 2005. Proceedings. IEEE. 2005, págs. 193-201.

134
[73] Michael A Cusumano y Richard W Selby. Microsoft secrets. 1997.
[74] Joseph P Elm y col. ‹A Survey of Systems Engineering Effectiveness-Initial
Results ›. En: (2008).
[75] Jessica Diaz, Juan Garbajosa y Jose A Calvo-Manzano. ‹Mapping CMMI
level 2 to scrum practices: An experience report ›. En: European Conference
on Software Process Improvement. Springer. 2009, págs. 93-104.
[76] CJ Salinas, Maria J Escalona y Manuel Mejias. ‹A scrum-based approach to
CMMI maturity level 2 in web development environments ›. En: Proceedings
of the 14th International Conference on Information Integration and Web-
based Applications & Services. ACM. 2012, págs. 282-285.
[77] KL- ukasiewicz y J Miler. ‹Improving agility and discipline of software deve-
lopment with the Scrum and CMMI ›. En: IET software 6.5 (2012), págs. 416-422.
[78] Taghi Javdani Gandomani y col. ‹Compatibility of agile software develop-
ment methods and CMMI ›. En: Indian Journal of Science and Technology
6.8 (2013), págs. 5089-5094.
[79] Marco Palomino y col. ‹Agile Practices Adoption in CMMI Organizations:
A Systematic Literature Review ›. En: International Conference on Software
Process Improvement. Springer. 2016, págs. 57-67.
[80] Philipp Diebold, Thomas Zehler y Dominik Richter. ‹How Do Agile Practi-
ces Support Automotive SPICE Compliance? › En: (2017).
[81] Luigi Benedicenti y col. ‹Improved Agile: A Customized Scrum Process for
Project Management in Defense and Security ›. En: Software Project Mana-
gement for Distributed Computing. Springer, 2017, págs. 289-314.
[82] Carlos Joaquin Torrecilla Salinas. ‹A mature agile approach in web enginee-
ring contexts ›. Tesis doct. Universidad de Sevilla, 2017.
[83] Carlos J Torrecilla-Salinas y col. ‹An Agile approach to CMMI-DEV levels
4 and 5 in Web development ›. En: (2016).
[84] Gabriela Arauz Ortiz y col. ‹Integrating Agile Methods into a Level 5
CMMI-DEV Organization: a Case Study ›. En: IEEE Latin America Transac-
tions 14.3 (2016), págs. 1440-1446.

135