CASO DE ESTUDIO 2

Los antecedentes

El caso de estudio se trata de una pequeña empresa en la que se ha aplicado CMM durante 12
meses. La empresa tiene cuatro unidades, o áreas:
a) un área de software (AS),
b) un área comercial (AC),
c) un área de hardware (AH), y
d) un área financiera (FS).

El área de software era un micro equipo con menos de 10 personas, con recursos muy cortos,
y claramente estaban en el primer nivel de madurez, el nivel inicial.
La misión del área de software es desarrollar y suministrar productos y servicios de software de
alta calidad empresarial. Los clientes utilizan el software que el área suministra y
adicionalmente el área realiza también labores de soporte técnico a los clientes. A cambio, los
clientes pagan una cuota mensual.

El área de software era muy caótica, cuando el caso de estudio comenzó. No había un
liderazgo efectivo, y la motivación era muy baja. A pesar de una importante experiencia
acumulada en los últimos años, no había coordinación ni internas ni externas. Las habilidades y
prácticas técnicas tenían pobre sofisticación.
A nivel técnico, la calidad era baja. No se llevaban a cabo gestión de análisis o de
requerimientos, el control de versiones era pobre, no existía preocupación acerca de la
reutilización de código, y no se trató de mejorar la calidad. El desarrollo de aplicaciones no
estaba planeado y ni tenía seguimiento, y los recursos para el desarrollo se utilizaban casi
exclusivamente para el mantenimiento de las aplicaciones existentes. Nadie sabía exactamente
lo que las demás personas estaban trabajando.

Desde el lado del cliente, la falta de satisfacción fue también claramente visible. En efecto:

a) algunas de las aplicaciones no llevaban a cabo todas las tareas previstas,

b) otras aplicaciones completaban las tareas deseadas, pero frecuentemente de manera
inconsistente, y
c) los servicios de apoyo no eran eficaces o eficientes.

Las demás áreas de la empresa también tenían sus propios problemas. En particular, las
negociaciones y venta de contratos de servicios de software del área comercial estaban
basadas en el conocimiento insuficiente sobre los productos y servicios correspondientes. A
menudo, esto originaba cambios y adaptaciones de última hora que no habían sido planeadas
ni gestionadas. El área de hardware no seguía los procedimientos adecuados de garantía de
calidad respecto a las máquinas y los servicios que suministraba, lo que a menudo resultaba en
quejas de los clientes que culpaban finalmente al área de software. Como era de esperar, la
situación financiera de la empresa era muy frágil.

Todos estos factores contribuyeron a aumentar la inestabilidad y confusión en el área de

software. En otras palabras, el software era desarrollado, pero no existía un proceso claro para
hacerlo. Y como no había un proceso de identificación, la repetición podía existir. Esto ponía
claramente el funcionamiento del área de software en el nivel 1 de CMM, el Nivel Inicial.

Los cambios descritos en el presente caso comenzaron cuando un nuevo liderazgo fue
nombrado por el área de software. El objetivo principal fue conocer cómo CMM se podría
aplicar, utilizar y adaptar a un equipo para que el proceso fuera claramente mejorable. Los
objetivos específicos fueron:

a) crear un proceso repetitivo de software,

b) Administrar el equipo a fin de mantener altos niveles de motivación y de rendimiento;
c) preparar el área de software para la evolución tecnológica, y
d) pensar constantemente en todos los ítems para que el proceso pueda evolucionar
continuamente.

Para lograr estos objetivos, el plan de acción para el primer año incluía:
a) El estudio detallado de las áreas claves de proceso de nivel 2, y el claro entendimiento de
sus objetivos, seguido de la adaptación y aplicación al área de software,
b) el mantenimiento y corrección de las aplicaciones existentes y el apoyo a los clientes que las
tenían,
c) la creación de nuevas aplicaciones, desarrolladas con una tecnología más avanzada, con el
fin de inducir el análisis y gestión de requisitos, la reutilización de código, control de versiones,
y otras buenas prácticas;
d) la búsqueda de nuevos mercados, y
e) la revisión permanente del plan de acción.

Para poner este plan en práctica, en el área de recursos humanos necesitó:

a) Capacitar al recurso humano,
b) Actualizar las máquinas y software de desarrollo, y
c) Conceder el acceso a la información técnica y a Internet

El enfoque

La aplicación de CMM al área de software se llevó a cabo en tres fases. La primera fase se
dedicó a una evaluación de la madurez del proceso de software. Como se describió
anteriormente, se descubrió pronto que el proceso de software estaba claramente en el nivel 1
de la escala de madurez. También se constató que la única área clave de proceso de nivel 2
que no era necesaria intervenir era el área clave de proceso 4 (Administración de Software
subcontratado), simplemente porque el área de software no acudió a la subcontratación de
software. Todas las otras cinco áreas claves de procesos pedían una intervención seria, y
pronto se hizo claro que no era práctico intervenir simultáneamente todas ellas.

La segunda fase de aplicación de CMM al área de software se concentró en las áreas claves
de proceso 1, 3 y 6. De esta manera, no sólo los requisitos y la configuración de los productos
de software podrían ser controlados, pero los datos también pueden ser recogidos para
describir el comportamiento del área de software a través de respuestas a preguntas como
"¿Cuánto tiempo se tardó en desarrollar el programa X y cuánto costó? " o "¿Cuál es la
productividad del programador Y?".

Después de la obtención de los datos que aclararon el tiempo y costos asociados a cada
conjunto de aplicaciones fue posible empezar a establecer los planes de desarrollo. Por lo
tanto, la tercera fase podría iniciarse.

Desde la aplicación detallada de las áreas claves de procesos al área de software, la cual es
descrita a continuación algunos aspectos metodológicos deben ser mencionados aquí:

Los roles establecidos en CMM se simplificaron, debido a la dimensión del equipo;

Las normas y procedimientos no se escribieron, en su lugar fueron transmitidos e interiorizados

por el grupo en los momentos adecuados.

Todos los elementos del área de software participaron activamente en la solución de algunos
problemas y fueron determinantes en la dirección del área de software, tanto a nivel técnico
como administrativo.

Las áreas claves de procesos y sus prácticas se evaluaron teniendo en mente la necesidad de
aplicar CMM de una manera pragmática:

a) debido a que el equipo era pequeño, y

b) porque los recursos eran muy escasos.

Dada su particular importancia para el éxito, hay que destacar algunos aspectos específicos de
la aplicación de CMM al área de software:

Los requisitos de software y sus cambios estaban escritos siempre y eran el resultado de un
proceso de análisis;
Los tiempos y costos asociados a las diversas actividades se han medido y registrado. Cada
elemento del equipo llenaba diariamente una hoja con las tareas realizadas de acuerdo con
una tabla predefinida, registrando a su vez los tiempos de inicio y de finalización. Esas tareas
podrían ser meramente técnicas, como "programar", en cuyo caso se asociaban a una
aplicación, o podían ser tareas administrativas, tales como "apoyo técnico", en cuyo caso se
asociaban a una aplicación y un cliente. Después de algún tiempo de "ajuste", se desarrolló
una aplicación para registrar a los elementos de forma automática;

El uso sistemático de indicadores permitió, después de algún tiempo, la creación de la

confianza para el desarrollo de los proyectos. Este proceso inicial de "confianza administrativa"
pronto se convirtió en un proceso más riguroso de:

a) Estimación del tamaño de las soluciones de software,

b) La estimación de los costos involucrados, y
c) La estimación y el seguimiento del cronograma para cada proyecto.

El seguimiento y la supervisión se convirtieron en tareas sistemáticas del líder del equipo, quien
aseguraba que los cambios y mejoras se acordaran siempre con las personas involucradas y
se dieran a conocer a todo el equipo.

Los planes de desarrollo para cada proyecto de software comenzaron a establecerse, aunque
no totalmente por escrito. Cada proyecto era discutido regularmente con los elementos del área
de software antes de distribuir las tareas y de asignar los recursos a las mismas. El líder del
equipo era responsable de obtener los recursos necesarios en negociación con los demás
sectores de la empresa.

El área de software aceptó el compromiso de buscar permanente la calidad, y como el pequeño

tamaño del equipo de trabajo hacía imposible establecer un grupo de aseguramiento de
calidad, en su lugar se comenzó a seguir algunas de las buenas prácticas generales de CMM.
Por ejemplo, la revisión sistemática de un producto o subproducto, se llevó a cabo por las
personas que no estaban involucrados en el desarrollo de estos. De esta manera, la totalidad
de las áreas de software se hizo cargo de los procesos de calidad. Aunque esto no concedía
total independencia al proceso de gestión de calidad, se constató que el compromiso era
factible y aceptable.

El área de software reconoció la necesidad de un control riguroso de todas las versiones y se

desarrollaron aplicaciones y utilidades para crear un repositorio digital de algunos de los
elementos y para gestionar el ciclo del alojamiento y la vida de aquellos que no estaban
disponibles en formato digital.
Después del primer año de aplicación de CMM algunos resultados pueden ser recopilados y
organizados. Los más significativos se muestran a continuación:
Resultados de tiempo
Es evidente que a lo largo del período de análisis el tiempo dedicado a la producción de
software (que corresponde al desarrollo de nuevas aplicaciones y el mantenimiento de las
existentes) se incrementó. Por el contrario, el tiempo dedicado a otras actividades, que se
describen como actividades no relacionadas con la producción, disminuyó. En esta categoría,
la actividad con mayor peso fue el soporte técnico a los clientes. La Figura 1 muestra que:

a) El porcentaje mensual de tiempo dedicado a la producción de software ha aumentado

durante los 12 meses, y
b) El porcentaje mensual de tiempo dedicado a actividades no relacionadas con la producción
ha bajado de su valor inicial.

Estos resultados se ven reforzados por la comparación entre el tiempo dedicado al

mantenimiento de las aplicaciones existentes y el tiempo dedicado a desarrollo de nuevas
aplicaciones. Como puede verse en la figura2, el porcentaje de tiempo mensual dedicado al
mantenimiento de las aplicaciones existentes se ha reducido, mientras que el tiempo dedicado
a la producción de nuevas aplicaciones se ha incrementado.
Resultados de cliente

De la figura 3, podemos ver que el número de intervenciones mensuales para responder las
llamadas del cliente se ha reducido. Durante el periodo de análisis el número de clientes
aumentó ligeramente, pero no significativamente. Se han perdido algunos clientes durante los
primeros meses

Resultados financieros
Para expresar los resultados financieros que siguen se utiliza un sistema a escala en lugar de
valores reales. El costo total para el primer mes se expresa en cientos y todos los demás se
comparan con este.
De la figura 4 podemos ver que:
a) Los gastos mensuales se redujeron,
b) los beneficios mensuales aumentaron y
c) La diferencia entre beneficios y costos se ha reducido tendiendo a cero lo cual sugiere una
tendencia hacia valores positivos.
La figura 5 ilustra los costos mensuales discriminando actividades de producción y actividades
de no-producción. Esto demuestra que:
a) El costo mensual de las actividades de producción ha aumentado durante los 12 meses;
b) El costo mensual de actividades no relacionadas con la producción se ha reducido, y
c) Los resultados son consistentes con los presentado en la figura1
Conclusiones
Los resultados que se han presentado son globalmente consistentes entre ellos. El área de
software tiene un alto grado de autonomía, y durante los 12 meses del caso de estudio no ha
sido sujeto a nuevas variables. Por lo tanto, los resultados sugieren que la aplicación de CMM
al área de software ha contribuido significativamente a la mejora de procesos.

Pueden surgir algunas dudas en cuanto a la interpretación de la información financiera de la

figura 4, ya que la tendencia en la reducción de costos es mucho más evidente que el aumento
de los beneficios. Creemos que esto se debió a el rigor y la disciplina que el uso de CMM ha
impuesto dentro del área de software. Por otro lado, el aumento de beneficios ha dependido
fuertemente del desarrollo de nuevas aplicaciones, lo cual tomo un buen tiempo, y de la
rentabilidad subsecuente. Creemos que, como pasa el tiempo, la línea de tendencia de los
costos tenderá a estabilizarse, o incluso crecer, pero la línea de beneficios tenderá a crecer
más rápidamente.

La aplicación de CMM al área de software no fue fácil en lo absoluto. Dado el pequeño tamaño
del equipo y su falta de recursos, muchas simplificaciones del método tenían que ser
implementadas, y sólo las prácticas claves que eran realmente importantes para el proceso se
han conservado. Podríamos decir entonces que CMM se ha aplicado de una manera muy
pragmática
El intento de pasar de nivel 1 al nivel 2 de la escala de madurez no se ha completado. En la
actualidad, la madurez del área de software se establece sobre el nivel 1, pero por debajo del
nivel 2.
En general, podemos concluir que:
La aplicación pragmática de CMM al área de software ha dado lugar a mejoras significativas
que ponen a su proceso de software por encima del nivel 1;
El proceso del software está por debajo del nivel 2, pero es demostrable que este nivel se
puede alcanzar.
La aplicación de CMM a los micro equipos es posible y contribuye a la mejora de sus procesos
de software, sin embargo, la simplificación de los métodos son necesarios, es decir, en la
estructura de las funciones y en el formalismo de los procedimientos y normas, los costos de
intentar aplicar completamente CMM a los micro equipos como se ha descrito serían
demasiado altos;
Los resultados obtenidos son globalmente positivos y coherentes entre ellos, lo que sugiere
que son consecuencia de la aplicación pragmática de CMM
La aplicación pragmática de CMM conduce a mayores niveles de calidad del software
resultante;

A CMM le concierne exclusivamente el proceso de desarrollo de software.

La aplicación de CMM a un micro equipo ha demostrado que otro factor crítico debe ser tenido
en cuenta, además del cuidado del proceso de software: el factor de los recursos humanos del
equipo y su administración. Esto ha demostrado ser especialmente sensible, debido a que:
a) el nivel de madurez del área de software fue inicialmente muy baja, y
b) la pequeña dimensión del área de software no facilitaba un cambio de cultural global, a
menos que se realizara directamente a través de cada miembro.

En resumen, la aplicación de CMM a un micro equipo debe llevarse a cabo con un criterio de
permanente adaptación al entorno del equipo, utilizando sólo las practicas clave que son
realmente importantes para el proceso, y teniendo en cuenta que la gestión del equipo es tan
importante como la gestión de procesos.

La relevancia de los factores relativos a los recursos humanos ha sido reconocida por otros
autores [11], e incluso por el SEI en su publicación de CMM V.1.1: "CMM también puede llegar
a ser multi-dimensional para hacer frente a la tecnología y los recursos humanos" [ 8]. Esto dio
como resultado, en 1995, la publicación de la P-CMM – Modelo de Capacidad de la Madurez
de Personas [12]. También en 1995, la dimensión tecnológica ha sido abordada en la SE-CMM
- Modelo de Capacidad de la Madurez de Ingeniería de Sistemas [13].
http://www.iscn.at/select_newspaper/assessments/iscaa.html