You are on page 1of 17

ITBA REPORTES TECNICOS CAPIS

CALIDAD DEL SOFTWARE
CMM - CAPABILITY MATURITY MODEL

Maestrando: Lic. Eduardo Diez

INTRODUCCION

El objetivo del presente artículo es brindar un análisis sobre la utilidad de aplicar los
lineamientos del Capability Maturity Model (CMM) en la obtención de productos de
software de calidad.

Con tal motivo, se desarrollarán brevemente, y sólo a modo de introducción, los
siguientes temas:

• Contexto y aspectos generales relativos a la ingeniería de software
• El paradigma de la calidad y sus principales elementos

Posteriormente, se brindará información específica del Capability Maturity Model,
tales como:

• Una breve descripción del CMM
• Estadísticas sobre la aplicación del CMM
• Críticas que se le suelen hacer al CMM

Finalmente, se presentarán:

• Un caso de aplicación con las experiencias y lecciones aprendidas
• Conclusiones finales

CONTEXTO

Antes de comenzar a tratar el tema de la calidad de software, es necesario situarse
en el contexto actual de la ingeniería de software. Este contexto se analizará desde
dos puntos de vista: La crisis del software y la realidad del software.

Crisis del software

En la década del 60 se reconoció que la ingeniería de software estaba en crisis. La
crisis perdura hasta nuestros días, siendo las principales características de la misma
las siguientes:

• El software no cubre todos los requisitos
• El software falla muy a menudo
1

por seres humanos. algunos de ellos son los siguientes: • Existe una necesidad de software cada vez más complejo y crítico • La producción de software es una actividad creativa e intelectual realizada. existe una recurrencia de la crisis del software con respecto a: • Plazos • Costos • Expectativas • Calidad A modo de ejemplo.ITBA REPORTES TECNICOS CAPIS • El software debe ser modificado frecuentemente • Los proyectos se retrasan o incluso se abandonan • Los proyectos exceden los costos previstos Por lo tanto. cualquiera sea la solución que se busque a la crisis del software. que no se puede delegar a máquinas • Las técnicas de ingeniería de software deben ser acompañadas por: • Sentido común • Competencia • Experiencia • Aceptación del principio de “No silver bullet” De lo anterior se desprende que. principalmente. un reporte sobre contratos de desarrollo de software. existen hechos innegables relacionados con la ingeniería de software. única ni prescindirá de la participación humana. realizado en 1979 por el General Accounting Office (USA) revelaba los siguientes datos: 29% Pagado y nunca 4% entregado Usado como se entregó 22% 45% Modificado o rehecho No pudo para poder usarse ser usado Realidad del software Por otro lado. ésta no será mágica. 2 .

Apaga incendios • Requerimientos no controlados • La ausencia de mediciones provoca la falta de base para predecir atributos del proceso o del producto • Excesos en plazos y presupuestos previstos • Sacrificio de calidad y funcionalidad Proceso maduro Por su parte. tendrá las siguientes características: • Improvisación • Falta de rigurosidad • Organización reactiva . las especificaciones funcionales en especificaciones de diseño. consistente y actualizado • Roles y responsabilidades definidas • Monitoreo gerencial • Las mediciones rigurosas generan una base objetiva para predecir y juzgar atributos del proceso y del producto • Realismo de cronogramas y presupuestos • Se alcanzan los resultados esperados 3 . Proceso de software A continuación se dan dos definiciones de proceso de software: • Es el proceso a través del cual los requerimientos de usuario son traducidos en especificaciones funcionales. tendrá las siguientes características: • Administración de requerimientos y del proceso • Proceso comunicado.) Ahora bien. el cual es testeado. métodos y prácticas que usamos para producir un producto de software (Humphrey W. el proceso de software en cualquier organización puede ser inmaduro o maduro. las especificaciones de diseño en código. se tratará brevemente el concepto de proceso de software. documentado y liberado para ser usado por el usuario (IEEE) • Es el conjunto de herramientas. un proceso de software maduro. Proceso inmaduro Un proceso de software inmaduro.ITBA REPORTES TECNICOS CAPIS ASPECTOS GENERALES Además del contexto ya presentado. usable. ya que el artículo girará alrededor del mismo.

se priorizarán distintos atributos: Usuario: Atributos externos del producto Ingeniero de software: Gerente de proyecto: Atributos internos Atributos del proceso del producto 4 .ITBA REPORTES TECNICOS CAPIS PARADIGMA DE LA CALIDAD El paradigma de calidad es aplicable a todas las actividades que se llevan a cabo en una organización. análisis y comparación de datos • Focalización en el cliente: La obtención de la satisfacción del cliente es el objetivo final de todo proceso • Eliminación de defectos: Priorización de técnicas de prevención de defectos sobre técnicas de detección y corrección • Gestión para la calidad: La adopción del paradigma requiere del compromiso de la alta dirección Aplicación en ingeniería de software En la ingeniería de software. en el artículo se tratarán los principios generales y su aplicabilidad a la ingeniería de software. la visión de la calidad no es única. dependiendo del punto de vista desde el cual se la analice. más que a la adecuación a estándares o a especificaciones • La perspectiva del proceso: Focalización en el proceso más que en el producto • Orientado a datos: Basado en la recolección. Principales elementos Veamos cuales son los principales elementos del paradigma: • La naturaleza de la calidad: Orientación a los aspectos o características de un producto o servicio que influyan en su capacidad para satisfacer necesidades dadas.

Su principal objetivo era calificar a proveedores de software del Departamento de Defensa (DoD) de USA. y las consideraciones son muy generales e imprecisas. ITBA REPORTES TECNICOS CAPIS Por otro lado.CAPABILITY MATURITY MODEL Orígenes y evolución Fue concebido en el año 1987 por el Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon (CMU). Este desconcierto se puede sintetizar en los siguientes interrogantes: • ¿Por dónde se empieza? • ¿Se debe priorizar un punto de vista? • ¿Qué punto de vista se prioriza? • ¿La mejora debe ser gradual? • ¿Cómo se estructura la mejora? • ¿Cuánto se tarda en mejorar? • ¿Cuánto cuesta mejorar? • ¿Vale la pena? Algunas de las organizaciones.SPICE: Software Process Improvement and Capability Determination • IEEE: Institute of Electrical and Electronics Engineering • ESA: European Software Agency • SEI . ya que los principios son casi siempre vagos y abstractos. pero que no suelen integrarse correctamente. el profesional de ingeniería de software cuenta con una batería de conceptos y actividades relacionadas con la calidad.CMM: Capability Maturity Model CMM . modelos y normas que intentan dar respuestas a éstos interrogantes son los siguientes: • ISO . aplicar el paradigma no es tarea fácil en la ingeniería de software. 5 . tales como: • Testing • Revisiones • Verificaciones • Auditorías • SQA De lo anterior se concluye que es lógico que exista un gran desconcierto por parte de los profesionales de ingeniería de software al encarar un proyecto de mejora de calidad del software. pero el modelo fue incorporado paulatinamente por numerosas empresas. Adicionalmente.

Usos El CMM soporta los siguientes usos: • Comprender las actividades necesarias para planear e implementar un programa de mejora del proceso de software (SPI) • Definir y mejorar el proceso de software • Identificar fortalezas y debilidades en las organizaciones • Identificar los riesgos de seleccionar entre diferentes proveedores de software Fundamentos Los siguientes son los fundamentos del modelo: • La madurez recorre diferentes etapas • La clave del crecimiento es entender dónde se está y a dónde se quiere llegar • El proceso se mejora evolucionando a partir de lo preexistente • El progreso requiere concentrar los esfuerzos en pocas áreas Generalidades A modo de introducción a temas que se desarrollarán a lo largo del artículo. se mencionan las siguientes características del CMM: • El modelo incorpora los principales elementos del paradigma de la calidad • El modelo identifica: • 5 niveles de madurez • Mejoras claves requeridas por cada nivel • Un orden de prioridades para escalar a niveles superiores • El SEI proporciona: • Servicio de apreciaciones (Assessments) del proceso de software (SPA) • Programa de evaluación de la capacidad del software (SCE) Estructura La estructura completa del modelo se representa en el siguiente gráfico: 6 . ITBA REPORTES TECNICOS CAPIS Es actualmente un esquema que representa un camino de mejoramiento recomendado para organizaciones que quieren incrementar la capacidad de su proceso de software.

ITBA REPORTES TECNICOS CAPIS Niveles de Contiene madurez Indica Areas clave Organizado por de proceso Capacidad del Alcanza Aspectos Contiene proceso comunes Encara Practicas Metas clave Implement. Infraestructura o actividades A continuación se describen brevemente cada uno de los componentes de la estructura. e Describe Institucional. Niveles de madurez Los niveles de madurez se representan en el siguiente gráfico: Proceso en Nivel 5 mejora continua Optimizado Proceso Nivel 4 predecible Administrado Proceso Nivel 3 estándar consistente Definido Proceso Nivel 2 disciplinado Repetible Nivel 1 Inicial 7 .

cronogramas y funcionalidad establecidos • La disciplina del proceso permite la repetición de éxitos anteriores en proyectos similares • La fuerza de la organización está dada por la existencia de experiencia en desarrollo de procesos similares pero existen riesgos al presentarse nuevos desafíos • Una representación gráfica del nivel podría ser la siguiente: NIVEL 3 .DEFINIDO • El proceso para gerentes e ingenieros está documentado e integrado en un proceso estándar para la organización • Todos los proyectos usan una versión aprobada y adaptada del proceso estándar de la organización • Un grupo de proceso de ingeniería de software (SEPG) ha sido establecido para focalizar y liderar esfuerzos de mejora • Una representación gráfica del nivel podría ser la siguiente: 8 .ITBA REPORTES TECNICOS CAPIS Características por nivel NIVEL 1 .REPETIBLE • Procesos básicos de gestión para manejar costos.INICIAL • Proceso ad-hoc y a veces caótico • La organización generalmente opera sin procesos formalizados. estimaciones de costo o planes de proyecto • Aunque existan algunos procesos formalizados. no existen mecanismos que permitan asegurar que se cumplan • El éxito depende del esfuerzo individual • Una representación gráfica del nivel podría ser la siguiente: NIVEL 2 .

ITBA REPORTES TECNICOS CAPIS NIVEL 4 . para acceder al siguiente: NIVEL 2 .OPTIMIZADO • La organización busca identificar aquellos elementos más débiles del proceso y optimizarlos sobre la base de un análisis defecto-causa y prevención de defectos • Existen datos que justifican la aplicación de nuevas ideas o tecnologías a determinadas tareas críticas y la evidencia cuantitativa permite conocer el grado de eficacia alcanzado al implementarlas en proyectos piloto • Una representación gráfica del nivel podría ser la siguiente: Areas clave de proceso Son las mejoras claves requeridas por cada nivel.ADMINISTRADO • Existen mediciones detalladas del proceso y calidad del producto • El producto y el proceso son cuantitativamente conocidos y controlados • Una representación gráfica del nivel podría ser la siguiente: NIVEL 5 .REPETIBLE Se concentran en establecer controles básicos de gestión de proyectos: • Administración de requerimientos • Planificación de proyectos de software • Control y supervisión de proyectos • Supervisión de subcontratos de software • Afirmación de calidad del software • Supervisión de la configuración del software 9 .

lo que establece una infraestructura que institucionaliza procesos de ingeniería de software y gestión. a lo largo de todos los proyectos: • Focalización orgánica en el proceso • Definición de proceso organizacional • Programa de entrenamiento • Administración integrada del software • Ingeniería de producto • Coordinación intergrupal • Revisiones por pares NIVEL 4 . repetible y perdurable.ADMINISTRADO Se concentran en establecer una comprensión cuantitativa y cualitativa del proceso y de los productos: • Administración cuantitativa del proceso • Administración de la calidad del software NIVEL 5 . por ejemplo: • Compromisos para la ejecución • Habilidad para ejecutar • Actividades a ejecutar • Mediciones y análisis • Verificación de implementación 10 .ITBA REPORTES TECNICOS CAPIS NIVEL 3 .DEFINIDO Direccionan aspectos organizacionales y del proyecto.OPTIMIZADO Cubren los aspectos de la organización y de los proyectos que deben atenderse para implementar una mejora continua y medible del proceso de software: • Prevención de defectos • Administración del cambio del proceso • Administración del cambio tecnológico Aspectos comunes Son atributos que permiten que la implementación o institucionalización de un área clave de proceso sea efectiva.

en conjunto con personal de la organización. la evaluación tiene como objetivo determinar y evaluar la capacidad y madurez del proceso de software de una organización. Se asemeja a una auditoría externa. Evaluación del proceso Finalmente.3% 1.5% 0.0% 11. ESTADISTICAS SOBRE LA APLICACION DEL CMM A continuación se presenta una serie de estadísticas y observaciones relativas a la aplicación del modelo: El nivel de madurez de las organizaciones. • Evaluación de la capacidad del software (SCE): Realizado por agentes gubernamentales a contratistas o proveedores de software.8% 18. por Si o por No. realizado en Marzo de 1996 sobre un total de 477 organizaciones. según un estudio del Software Engineering Measurement and Analisys Team del SEI. a un cuestionario y en la aplicación de un algoritmo sobre las mismas. Se asemeja a contratar una consultoría. 83% de las cuales corresponden a USA.ITBA REPORTES TECNICOS CAPIS Practicas clave Describen una infraestructura o actividades necesarias para implementar o institucionalizar un área clave de proceso. es el siguiente: 70% 60% 50% 40% 30% 20% 10% 0% Nivel 1 Nivel 2 Nivel 3 Nivel 4 Nivel 5 68. y ubicarlo en un nivel del CMM. Ambas evaluaciones se basan en las respuestas.4% 11 . Existen dos tipos de evaluaciones: • Apreciación (Assessment) del proceso de software (SPA): Realizada por profesionales del SEI o autorizados o independientes.

realizado en Marzo de 1996 sobre un total de 28 re-apreciaciones. es el siguiente: 11% Bajó el nivel 18% 71% Permaneció Elevó el nivel igual Algunos datos promedio de un estudio realizado sobre los primeros 3 niveles (Estudio de Junio de 1997 .Fuente: [1]) son los siguientes: • Tiempo requerido para pasar del nivel 1 al 2: 26 meses • Tiempo requerido para pasar del nivel 2 al 3: 24 meses • Inversión aproximada requerida: 1400 U$S por año por ingeniero de software • Reducción de defectos post-release alcanzada: 39% por año • Productividad ganada: 35% por año • Relación costo/beneficio lograda: 1 a 5 Algunas observaciones del estudio realizado sobre los primeros 3 niveles (Estudio de Junio de 1997 . según un estudio del Software Engineering Measurement and Analisys Team del SEI. ITBA REPORTES TECNICOS CAPIS Los cambios en el nivel de madurez de las organizaciones. lo que no permite registrar los matices de la realidad • El modelo es sólo aplicable a grandes organizaciones que desarrollan grandes proyectos 12 . sino solamente mencionarlas: • El algoritmo utilizado para calificar el proceso de software de una organización no es el adecuado y las preguntas clave no son correctas ni suficientes • Las preguntas utilizadas en la evaluación son binarias (Si .No).Fuente: [1]) son las siguientes: • Mejora en la capacidad para alcanzar: • Cronogramas y presupuestos previstos • Calidad del producto requerida • Mejora de la moral del equipo de desarrollo • Baja la satisfacción del cliente en nivel 2 y sube considerablemente en el nivel 3 CRITICAS USUALES A continuación se presentan las principales críticas que se le suelen hacer al CMM. El objetivo del presente artículo no es analizar cada una de las críticas.

burocrática y menos capaz de encontrar soluciones creativas a problemas técnicos • El nivel 1 es una “bolsa” en la que se ubican organizaciones con niveles de madurez muy diferentes • Los niveles de madurez no garantizan el éxito. y proyectos interdepartamentales. Existen proyectos exitosos en el nivel 1 y fracasos en niveles superiores • Algunas de las prácticas de medición recomendadas por el SEI han demostrado no funcionar (por ej. Los logros obtenidos a la fecha. con el objeto de mejorar el proceso de software. con integrantes de cada uno de los departamentos.ITBA REPORTES TECNICOS CAPIS • El modelo permite comparar procesos de software de grandes organizaciones con los de pequeñas organizaciones. reuniendo todas sus características. La situación al iniciar el proyecto era la típica de toda organización de nivel 1. Luego de una etapa de desconcierto en la cual el equipo no sabía como encarar el tema. favoreciendo a las primeras • La aplicación del modelo requiere una inversión importante • La aplicación del modelo vuelve a una organización rígida. Adicionalmente existían distintos departamentos de desarrollo. Se siguen entonces los lineamientos del CMM. se decidió iniciar un proyecto de mejora de calidad del proceso software. como consecuencia del proyecto emprendido son los siguientes: • Establecimiento de un lenguaje común entre departamentos • Establecimiento de una forma común de administrar proyectos • Se contrató una consultora para apoyar el proceso • Se creó la función de SQA • Se está definiendo un ciclo de vida estándar Lecciones aprendidas 13 . se accedió a material bibliográfico referente al CMM. Al poco tiempo se determinan las principales falencias y se establecen objetivos inmediatos. Se conforma un Equipo de Ingeniería de Software. cada uno de ellos con características y operatorias propias. adaptándolos a las características y problemática de la organización. los basados en líneas de código) APLICACION DEL CAPABILITY MATURITY MODEL Experiencia En la Gerencia de Sistemas de una compañía administradora de redes de cajeros automáticos.

el soporte de los distintos niveles jerárquicos y el involucramiento de los equipos de desarrollo • El proceso de mejora debe ser planeado. • Un buen profesional debe determinar objetivamente cuál es el modelo que más conviene aplicar en una organización dadas las características de la misma. • El proceso de mejora no debe ser abandonado. gestionado y se le deben asignar suficientes recursos • El proceso de mejora requiere un cambio cultural en toda la organización. • El CMM es un modelo efectivo para mejorar el proceso de software y por ende la calidad de sus productos. suspendido o disminuido a causa de otros eventos.ITBA REPORTES TECNICOS CAPIS Se han aprendido las siguientes lecciones como consecuencia de la aplicación del modelo: • El proceso de mejora requiere el compromiso visible de la dirección de la organización. pero no es el único. el esfuerzo y el interés • No es serio plantear objetivos de mejora sin plazos de concreción. • Es válido que una organización adecue y adapte un determinado modelo a sus propias características. • Es conveniente contar con soporte adicional de profesionales con experiencia en mejoras de procesos de software CONCLUSIONES De lo expuesto se pueden extraer las siguientes conclusiones: • El paradigma de la calidad es aplicable a la ingeniería de software por medio de modelos de mejora. • Es negativo que existan en la organización experiencias previas de procesos de mejora no exitosos. • El SEPG debe ser integrado por personas altamente reconocidas profesionalmente. es por ello que debe ser coordinado con todas las áreas • Es importante conseguir resultados rápidamente para mantener la motivación. 14 .

1989 15 . 1995 • Humphrey W. Reading. Reading. GLOSARIO • CMM: Capability Maturity Model • CMU: Carnegie Mellon University • DoD: Department of Defense • ESA: European Software Agency • IEEE: Institute of Electrican and Electronics Engineering • ISO: International Standard Organization • SCE: Software Capability Evaluation • SEI: Software Engineering Institute • SEPG: Software Engineering Process Group • SPA: Software Process Assessment • SPI: Software Process Improvement • SPICE: Software Process Improvement and Capability Determination • SQA: Software Quality Assurance BIBLIOGRAFIA Libros • Software Engineering Institute The Capability Maturity Model: Guidelines for Improving the Software Process Addison-Wesley. el proceso de mejora requiere compromiso. A Discipline of Software Engineering Addison-Wesley. Reading. 1995 • Humphrey W. Pa. Pa. Managing the Software Process Addison-Wesley. Pa.ITBA REPORTES TECNICOS CAPIS • Cualquiera sea el modelo seleccionado. inversión y constancia.

1996 Update SEI .McGowan C.Vol.Zubrow D. 40 .Marzo 1995 • Bollinger T. Software Quality and the Capability Maturity Model Communications of the ACM .Goldenson D.ITBA REPORTES TECNICOS CAPIS Artículos • Fox C.Paulk M. Model Flaws: Gaps in SEI Programs Software Development .Frakes W.Julio 1991 16 .Hayes W. 6 • [2] Software Engineering Measurement and Analisys Team Process Maturity Profile of the Software Community . .Nro. .Junio 1997 .Junio 1997 . .Vol. . .Nro. A Critical Look at Software Capability Evaluations IEEE Software . 40 .CMU . The Quality Approach: Is it Delivering? Communications of the ACM .Abril 1996 • Jones C. 6 • [1] Herbleb J. .

ITBA REPORTES TECNICOS CAPIS 17 .