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
ITBA
CAPIS
REPORTES TECNICOS
• El software debe ser modificado frecuentemente • Los proyectos se retrasan o incluso se abandonan • Los proyectos exceden los costos previstos Por lo tanto, existe una recurrencia de la crisis del software con respecto a: • • • •
Plazos Costos Expectativas Calidad
A modo de ejemplo, un reporte sobre contratos de desarrollo de software, 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, existen hechos innegables relacionados con la ingeniería de software, 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, principalmente, por seres humanos, 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, cualquiera sea la solución que se busque a la crisis del software, ésta no será mágica, única ni prescindirá de la participación humana. 2
ITBA
REPORTES TECNICOS
CAPIS
ASPECTOS GENERALES Además del contexto ya presentado, se tratará brevemente el concepto de proceso de software, ya que el artículo girará alrededor del mismo. 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, las especificaciones funcionales en especificaciones de diseño, las especificaciones de diseño en código, el cual es testeado, documentado y liberado para ser usado por el usuario (IEEE) • Es el conjunto de herramientas, métodos y prácticas que usamos para producir un producto de software (Humphrey W.) Ahora bien, el proceso de software en cualquier organización puede ser inmaduro o maduro. Proceso inmaduro Un proceso de software inmaduro, tendrá las siguientes características: • • • • •
Improvisación Falta de rigurosidad Organización reactiva - 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, un proceso de software maduro, tendrá las siguientes características: • • • • •
Administración de requerimientos y del proceso Proceso comunicado, usable, 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
ITBA
CAPIS
REPORTES TECNICOS
PARADIGMA DE LA CALIDAD El paradigma de calidad es aplicable a todas las actividades que se llevan a cabo en una organización, en el artículo se tratarán los principios generales y su aplicabilidad a la ingeniería de software. 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, 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, 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, la visión de la calidad no es única, dependiendo del punto de vista desde el cual se la analice, se priorizarán distintos atributos: Usuario: Atributos externos del producto
Ingeniero de software:
Gerente de proyecto:
Atributos internos
Atributos del proceso
del producto
4
CAPIS ITBA REPORTES TECNICOS Por otro lado, aplicar el paradigma no es tarea fácil en la ingeniería de software, ya que los principios son casi siempre vagos y abstractos, y las consideraciones son muy generales e imprecisas. Adicionalmente, el profesional de ingeniería de software cuenta con una batería de conceptos y actividades relacionadas con la calidad, pero que no suelen integrarse correctamente, 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. 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, modelos y normas que intentan dar respuestas a éstos interrogantes son los siguientes: • • • •
ISO - SPICE: Software Process Improvement and Capability Determination IEEE: Institute of Electrical and Electronics Engineering ESA: European Software Agency SEI - CMM: Capability Maturity Model
CMM - 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). Su principal objetivo era calificar a proveedores de software del Departamento de Defensa (DoD) de USA, pero el modelo fue incorporado paulatinamente por numerosas empresas. 5
CAPIS ITBA REPORTES TECNICOS Es actualmente un esquema que representa un camino de mejoramiento recomendado para organizaciones que quieren incrementar la capacidad de su proceso de software. 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
CAPIS
REPORTES TECNICOS
Niveles de
Contiene
madurez Indica
Areas clave de proceso
Capacidad del proceso
Organizado por
Contiene
Aspectos comunes
Alcanza
Encara
Metas
Practicas clave
Implement. e Institucional.
Describe
Infraestructura o actividades
A continuaciรณn se describen brevemente cada uno de los componentes de la estructura. Niveles de madurez Los niveles de madurez se representan en el siguiente grรกfico:
Proceso en mejora continua Proceso predecible Proceso estรกndar consistente Proceso disciplinado
Nivel 3 Definido
Nivel 2 Repetible
Nivel 1 Inicial
7
Nivel 4 Administrado
Nivel 5 Optimizado
ITBA
REPORTES TECNICOS
CAPIS
Características por nivel NIVEL 1 - 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 - REPETIBLE • Procesos básicos de gestión para manejar costos, 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
NIVEL 4 - 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 - 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, para acceder al siguiente: NIVEL 2 - 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
ITBA
REPORTES TECNICOS
CAPIS
NIVEL 3 - DEFINIDO Direccionan aspectos organizacionales y del proyecto, 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 - 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 - 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, repetible y perdurable, por ejemplo: • • • • •
Compromisos para la ejecución Habilidad para ejecutar Actividades a ejecutar Mediciones y análisis Verificación de implementación 10
ITBA
CAPIS
REPORTES TECNICOS
Practicas clave Describen una infraestructura o actividades necesarias para implementar o institucionalizar un área clave de proceso. Evaluación del proceso Finalmente, la evaluación tiene como objetivo determinar y evaluar la capacidad y madurez del proceso de software de una organización, y ubicarlo en un nivel del CMM. Existen dos tipos de evaluaciones: • Apreciación (Assessment) del proceso de software (SPA): Realizada por profesionales del SEI o autorizados o independientes, en conjunto con personal de la organización. Se asemeja a contratar una consultoría. • Evaluación de la capacidad del software (SCE): Realizado por agentes gubernamentales a contratistas o proveedores de software. Se asemeja a una auditoría externa. Ambas evaluaciones se basan en las respuestas, por Si o por No, a un cuestionario y en la aplicación de un algoritmo sobre las mismas. 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, según un estudio del Software Engineering Measurement and Analisys Team del SEI, realizado en Marzo de 1996 sobre un total de 477 organizaciones, 83% de las cuales corresponden a USA, es el siguiente: 70% 60% 50% 40% 30% 20% 10% 0% Nivel 1
Nivel 2
Nivel 3
Nivel 4
Nivel 5
68.8%
18.0%
11.3%
1.5%
0.4%
11
CAPIS ITBA REPORTES TECNICOS Los cambios en el nivel de madurez de las organizaciones, según un estudio del Software Engineering Measurement and Analisys Team del SEI, realizado en Marzo de 1996 sobre un total de 28 re-apreciaciones, es el siguiente: 11% Bajó el nivel 18% Permaneció igual
71% Elevó el nivel
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 - 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, 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), lo que no permite registrar los matices de la realidad • El modelo es sólo aplicable a grandes organizaciones que desarrollan grandes proyectos 12
ITBA
REPORTES TECNICOS
CAPIS
• El modelo permite comparar procesos de software de grandes organizaciones con los de pequeñas organizaciones, 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, 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. 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 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, se decidió iniciar un proyecto de mejora de calidad del proceso software. La situación al iniciar el proyecto era la típica de toda organización de nivel 1, reuniendo todas sus características. Adicionalmente existían distintos departamentos de desarrollo, cada uno de ellos con características y operatorias propias, y proyectos interdepartamentales. Se conforma un Equipo de Ingeniería de Software, con integrantes de cada uno de los departamentos, con el objeto de mejorar el proceso de software. Luego de una etapa de desconcierto en la cual el equipo no sabía como encarar el tema, se accedió a material bibliográfico referente al CMM. Se siguen entonces los lineamientos del CMM, adaptándolos a las características y problemática de la organización. Al poco tiempo se determinan las principales falencias y se establecen objetivos inmediatos. Los logros obtenidos a la fecha, 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
ITBA
CAPIS
REPORTES TECNICOS
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, el soporte de los distintos niveles jerárquicos y el involucramiento de los equipos de desarrollo • El proceso de mejora debe ser planeado, gestionado suficientes recursos
y se le deben asignar
• El proceso de mejora requiere un cambio cultural en toda la organización, es por ello que debe ser coordinado con todas las áreas • Es importante conseguir resultados rápidamente para mantener la motivación, el esfuerzo y el interés • No es serio plantear objetivos de mejora sin plazos de concreción. • Es negativo que existan en la organización experiencias previas de procesos de mejora no exitosos. • El proceso de mejora no debe ser abandonado, suspendido o disminuido a causa de otros eventos. • El SEPG debe profesionalmente.
ser
integrado
por
personas
altamente
reconocidas
• 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. • El CMM es un modelo efectivo para mejorar el proceso de software y por ende la calidad de sus productos, pero no es el único. • 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. • Es válido que una organización adecue y adapte un determinado modelo a sus propias características. 14
ITBA
REPORTES TECNICOS
CAPIS
• Cualquiera sea el modelo seleccionado, el proceso de mejora requiere compromiso, inversión y constancia.
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, Reading, Pa. 1995 • Humphrey W. A Discipline of Software Engineering Addison-Wesley, Reading, Pa. 1995 • Humphrey W. Managing the Software Process Addison-Wesley, Reading, Pa. 1989
15
ITBA
REPORTES TECNICOS
Artículos • Fox C. - Frakes W. The Quality Approach: Is it Delivering? Communications of the ACM - Junio 1997 - Vol. 40 - Nro. 6 • [1] Herbleb J. - Zubrow D. - Goldenson D. - Hayes W. - Paulk M. Software Quality and the Capability Maturity Model Communications of the ACM - Junio 1997 - Vol. 40 - Nro. 6 • [2] Software Engineering Measurement and Analisys Team Process Maturity Profile of the Software Community - 1996 Update SEI - CMU - Abril 1996 • Jones C. Model Flaws: Gaps in SEI Programs Software Development - Marzo 1995 • Bollinger T. - McGowan C. A Critical Look at Software Capability Evaluations IEEE Software - Julio 1991
16
CAPIS
ITBA
REPORTES TECNICOS
17
CAPIS