Versión Final UNIVERSIDAD TECNOLÓGICA NACIONAL REGIONAL SANTA FE DOCTORADO EN INGENIERÍA MENCIÓN SISTEMAS. Tesis de Doctorado:

Transcripción

1 UNIVERSIDAD TECNOLÓGICA NACIONAL REGIONAL SANTA FE DOCTORADO EN INGENIERÍA MENCIÓN SISTEMAS Tesis de Doctorado: Gestión de Mejoras en Procesos en Ingeniería de Software con el soporte de modelos sistémicos. Aplicación al sector de desarrollo de software de Argentina Autor: Pedro E. Colla Director: Dr. Jorge Marcelo Montagna Copia impresa 11/2/ :59 Revision 11 Versión Final

2 1-2

3 Siempre imaginé que el paraíso sería algún tipo de biblioteca Jorge Luis Borges 1-3

4 Agradecimientos En el camino para construir esta tesis obtuve muchos aprendizajes; aquellos que tiene que ver con la ciencia están distribuidos en los capítulos que siguen, los que tienen que ver con el espíritu están en estas líneas. He aprendido que, contra lo que podría suponerse, una tesis no es un trabajo individual. Es un trabajo de un gran equipo de gente que lo hace posible. Estas líneas son para, mínimamente, darles el crédito que se merecen. Este trabajo hubiera sido imposible sin el esfuerzo, consejo, colaboración, guía y aliento de mi director de tesis, el Dr. Jorge Marcelo Montagna; gracias Marcelo! No tuve otra cosa que apoyo de toda la gente en UTN-FRSF, empezando por el Dr. Horacio Leone quien como el entonces responsable del doctorado creyó que esta tesis era posible y del Dr. Omar Chiotti quien como responsable actual lo hizo posible. Mi vida hubiera sido muy difícil sin la coordinación que la Ing. Rosana Portillo hizo de todas mis clases en la vecina Santa Fe desde mi lugar de residencia en la mediterránea Córdoba. A lo largo del esfuerzo del doctorado el Dr. Luis Olsina y el Dr. Ernesto Martinez me aportaron valiosas contribuciones y puntos de vista desafiantes, algunos de ellos definieron como abordé algunos problemas y los resultados están reflejados en este trabajo. En el exterior, el Dr. Warren Harrison y el Dr. David Raffo de la Portland State University y el Dr. Dennis Goldenson junto con el Dr. Michael Konrad del SEI me compartieron consejos y revisiones cruciales a lo largo del trabajo de investigación; fue con ellos que comprendí lo que había que comprender para hacer este trabajo posible. El Dr. Tore Dyba me ayudó con claves para robustecer esta tesis y estar seguro que lo esencial estaba bien cubierto. De todos ellos son los buenos consejos, los errores son solo míos. Mis compañeros docentes en el Instituto Universitario Aeronáutico, mi casa académica, y en especial el decano de la Facultad de Ingeniería el Brig. Ing. (RE) Fernando Alvarez, el Mg. Héctor Riso y la Ing. Sandra Harperath fueron los que hicieron posible el marco académico en el cual desarrollé buena parte de este trabajo de investigación. No hubiera ido mucho más allá del marco teórico de mi tesis sin haber contado con la cooperación del CESSI para obtener la evidencia empírica necesaria, mi especial agradecimiento a la Ing. Emilce Chiricola y el Lic. Mario Sosa quienes cooperaron conmigo en hacer realidad los trabajos de campo así como las autoridades el Dr. Miguel A. Calello y la Lic. Vanessa Lucchesi por autorizar el soporte institucional de CESSI en el esfuerzo. Los datos fueron gracias a la CESSI, el uso y conclusiones extraídos de éstos son de mi única responsabilidad. 1-4

5 Mis compañeros de trabajo, en Motorola primero y en HP posteriormente me han proporcionado enormes dosis de aliento y comprensión. La gerencia senior de HP me ayudó en incontables ocasiones, material y espiritualmente, para hacer posible este trabajo; Mr. Hormuzd Karkaria primero, Mr. Keith Kerrison actualmente y en especial mi jefe, el Ing. Diego Schargorodsky, me permitieron llegar hasta aquí. Dudo que hubiera podido sin su soporte. Mi viejo no puede ver este momento, partió hace algún tiempo, pero mi vieja por suerte si lo puede ver; espero que ambos estén orgullosos; ellos construyeron los cimientos para que este trabajo fuera posible y por eso el logro es también de ellos. Mi suegra Luz, mis hijos, Pedro (el primer doctor en la familia), Claudia Alejandra Inés, (quien aplicó su lógica de médica a un trabajo de ingeniería para ayudarme a la edición de esta tesis) y Marcelo (quien se hizo dueño de los detalles para en esta tesis fuera consistente en ellos) fueron fuente de insustituible soporte, contención, paciencia y comprensión. Finalmente a mi compañera de toda la vida, María, no encuentro palabras para expresar lo importante que es; le tomo prestado a Juan Luis Guerra un párrafo de su canción para expresarlo, si tu no bailas conmigo, yo ya no quiero bailar. 1-5

6 ÍNDICE GENERAL Agradecimientos 1-4 ÍNDICE DE FIGURAS 1-13 ÍNDICE DE TABLAS 1-15 Capítulo 1 Introducción Antecedentes Problemas en desarrollo de software Gestión de calidad en software Estado del arte Fuentes de mejora Definición del problema Contribuciones de esta investigación Metodología de investigación Esquema de la tesis Capítulo 2 Mejoras en procesos de software Introducción Proceso de software Modelos de proceso Infraestructura de proceso Medición del proceso Evaluación de procesos de software Modelos de referencia Otros modelos de calidad Factores de éxito en evaluación de procesos Despliegue de mejoras de los proceso de software (SPI) Factores de éxito en mejora de procesos Innovación de procesos de software Mejoras de proceso vs. Innovación Modelo de madurez SEI-CMMI Representación Conceptos Áreas de proceso Evaluación de madurez Enfoques para implementar SPI

7 Marco Organizacional Contexto nacional Modelos Organizacionales Evaluación de la inversión Métodos para evaluar la inversión Evaluación económica de inversiones Evaluación financiera de inversiones Evaluación de inversiones como opciones Evaluaciones basadas en intangibles económicos Valor presente neto en proyectos SPI Erogaciones Beneficios Mejora en los ingresos Mejora en la performance Mejoras en la valuación de activos subyacentes Otros enfoques para implementar SPI Otros beneficios Gestión del esfuerzo de mejora Variaciones por geografía Pequeñas y medianas empresas SPI en PyMEs Las PyMEs necesitan de las iniciativas SPI Las PyMEs son reticentes a desplegar iniciativas SPI Las PyMEs reconocen el valor de SPI Tensión SEI CMMI vs. metodologías ágiles Resumen Capítulo 3 Modelos en ingeniería de software Introducción Modelos dinámicos Formulación de modelos dinámicos Recolección de datos Distribución de probabilidades de las variables aleatorias Estructurar la teoría Desarrollo del modelo Definición del problema

8 Creación del modelo conceptual Implementación del modelo Simulación Evaluación Métodos para verificación y validación de modelos Proceso de validación Técnicas de validación Validez de los datos Validación del modelo conceptual Verificación de implementación Validez operativa Comparación gráfica de resultados Intervalos de confianza Test de hipótesis Mejores prácticas de validación Modelos dinámicos en SPI Resumen Capítulo 4 Modelo de inversión en SPI Introducción Tipos de flujos de fondos Flujos de fondos tangibles Flujos de fondos intangibles Beneficios contingentes Riesgos contingentes Definición del problema a modelar Egresos por SPI Esfuerzo de despliegue Esfuerzo de entrenamiento Costo total de implementación Costo de evaluación Costo de mantenimiento Expresión financiera del costo de SPI Ingresos por SPI Mejoras de performance Corrección por riesgo de evaluación

9 Corrección por tamaño de organización Ingresos adicionales Menor incertidumbre en los resultados Beneficios intangibles Ingresos totales por SPI Costo de oportunidad Horizonte de inversión Variables independientes Parámetros Variables dependientes Modelo conceptual Resumen Capítulo 5 Perfiles SPI en organizaciones de Argentina Introducción Metodología de Investigación Propósito del estudio Método de construcción Dimensión cuantitativa Análisis de correlaciones Tipos de variables Tipos de diseño Objetivo del estudio Fuentes de datos Marco del análisis Demografía de la encuesta Conclusiones reportadas por CESSI Análisis de resultados Dependencia con el tamaño de la organización Dependencias con Variables Independientes y Parámetros Amenazas a la validez Resumen Capítulo 6 Relevamiento de perfiles SPI en Argentina Introducción Estrategia de Investigación Creación de la Encuesta

10 Objetivos de Investigación Audiencia Diseño del Plan de Muestreo Definiciones operativas Diseño del Cuestionario Distribución del Cuestionario Marco del análisis Esfuerzo y tiempo para implementar Tamaño de la organización Esfuerzo y tiempo de implementación vs. Tamaño Preferencias de horizonte de inversión Impactos en costo y plazos de entrega Productividad, ingresos y entregas Otras mejoras organizacionales Amenazas a la Validez Resumen Capítulo 7 Implementación y validación del modelo Introducción Diagrama causal Modelo estocástico Ejecución del modelo Modelo ejecutable (nivel superior) Subsistema SPI (nivel inferior) Modelado del costo de implementación (C sepg ) Modelado del ingreso por performance (I prod ) Modelado del costo de evaluación (C a ) Modelado del ingreso por menor incertidumbre en los resultados (ΔI) Modelado de mayores ingresos (I g ) Valor presente de la inversión en SPI (VPN spi ) Ejecución del modelo Verificación del modelo ejecutable Verificación de la estructura interna Verificación de comportamiento Validación del modelo ejecutable

11 Validación estadística Validación por expertos Resumen Capítulo 8 Evaluación de Escenarios Introducción Ejecución del modelo Sensibilidad al tamaño de la organización Sensibilidad al horizonte de inversión Sensibilidad al costo de evaluación Sensibilidad al costo por ingeniero Sensibilidad al costo de oportunidad Variación de la tasa libre de riesgo (r f ) Variación del factor de reducción de riesgo Mejora en incertidumbre de activos subyacentes (I FV ) Sensibilidad a la probabilidad de éxito (ξ) Variación de crecimiento de organización (g) Estudio de estrategias de inversión SPI Estrategia de crecimiento Decisión entre SEI-CMMI Nivel 2 o Nivel Estrategias de implementación Requerimientos de recursos en inversiones exitosas Resumen Capítulo 9 Conclusiones Introducción Preguntas de investigación Contribuciones originales Limitaciones y amenazas a la validez Trabajo Futuro Consolidar la estructura del trabajo Instrumentos adicionales Reflexiones finales Referencias Bibliográficas Glosario Apéndice A Factor de reducción de riesgo (λ) A-293 A.1 Uso de SEI SW-CMM y la performance de las organizaciones. A-293 A.2 Análisis de datos A

12 A.3 Reducción de Incertidumbre (λ) A-297 A.4 Estimación de λ por reducción de retrasos A-297 A.5 Resumen y amenazas a la validez A-300 Apéndice B Probabilidad de éxito (ξ) B-301 Apéndice C Encuesta nacional de perfiles SPI en Argentina. C-303 Apéndice D Componentes utilizados en GoldSim. D-304 Apéndice E Correlación de Performance con SEI SW-CMM E-306 Apéndice F Mapa Encuesta CESSI 2007 F-307 Apéndice G Encuesta Nacional 2008 G-308 G.1 Instrucciones de llenado: G-308 G.2 Cuestionario G-310 G.3 Glosario G-311 Apéndice H Análisis de rigor metodológico y relevancia. H

13 ÍNDICE DE FIGURAS Figura 1-1 Foco del modelo de madurez de capacidades integrado (Fuente: Figura 1-2 Distribución de organizaciones que adoptaron CMMI por tamaño [SEI2006] Figura 1-3 Niveles de madurez del modelo SEI-CMMI(TM) [SEI2009] Figura 1-4 Método esquemático de investigación Figura 2-1 Cambios de performance de proceso con mejora e innovación Figura 2-2 Relación entre factores internos y externos con el resultado de uso de proceso de software Figura 2-3 Estructura jerárquica de GQM [Basili1984] Figura 2-4 Contexto de la evaluación de procesos de software [ISO/IEC 15504] Figura 2-5 El ciclo de mejora de Shewart [Deming1986] Figura 2-6 Propuesta de mejora de procesos integrada con innovación [Dyba2001] Figura 2-8 Elementos del enfoque sistémico para la mejora de procesos [Colla-Montagna2005] Figura 2-9 Visión Sistémica de los impactos organizacionales derivados de esfuerzos en SPI [Walden2002] Figura 2-10 Despliegue SPI bajo condiciones de restricción de recursos Figura 2-11 Costo de Calidad como proporción del costo total para SEI SW-CMM [Knox1993] Figura 2-12 Mejoras de Esfuerzo con nivel SEI SW-CMM [Clark2000] Figura 2-13 Ejemplo hipotético de flujo de gastos e ingresos de fondos de proyecto de desarrollo Figura 2-14 Distribución de tiempos de implementación por nivel para SEI SW-CMM [SEI2009] Figura 3-1 Relaciones causales entre corrimientos de calendario y staff [Brooks1975] Figura 3-2 Revisión del ciclo de desarrollo de un modelo Figura 3-3 Generación de modelo Figura 3-4 Ciclo hermenéutico para la creación de modelos dinámicos [Madachy1999] Figura 3-5 Etapas del modelado y principales objetivos [Madachy1999] Figura 3-6 Relación entre confianza y costo de validación [Sargent1998] Figura 3-7 Metodología de modelado de proceso simplificado [Sargent1998] Figura 4-1 Modelo conceptual de inversión en SPI Figura 4-2 Factores relevantes en el modelo conceptual de inversión en SPI Figura 5-1 Probabilidades de errores Tipo I y Tipo II en un test de hipótesis [Dyba2001] Figura 5-2 Resumen de Análisis Estadístico de la Encuesta [resultado de ejecución con Minitab v1.42] Figura 5-3 Distribución de Frecuencias SEI-CMMI(TM) e ISO-9000 respecto al tamaño [CESSI2007] Figura 7-1 Diagrama causal preliminar [usando VenSim v5.8d PLE] Figura 7-2 Evolución del VPN spi con el tiempo durante esfuerzo SPI [ejecución VenSim] Figura 7-3 Modelo de nivel superior [Goldsim 9.6] Figura 7-4 Modelo integrado de inversión SPI Figura 7-5 Esfuerzo de implementación SPI Figura 7-6 Tiempo de implementación de iniciativa SPI Figura 7-7 Distribución de mejoras de productividad por nivel SEI SW-CMM [Clark2000] Figura 7-8 Distribución de Costos de Evaluación

14 Figura 7-9 Evolución en el tiempo del VPN en una ejecución de simulación típica [Goldsim v9.6] Figura 7-10 Distribución de probabilidad del VPN en una corrida de simulación típica [Goldsim v0.6] Figura 7-11 Sensibilidad del VPN a los factores organizacionales [Goldsim v9.6] Figura 7-12 Sensibilidad el VPN a la variación de factores organizacionales [GoldSim v9.6] Figura 7-13 Resultados comparativos entre la Encuesta CESSI 2007 y la ejecución del modelo Figura 8-1 Relación entre Valor Presente Neto de Inversión y Tamaño de la Organización Figura 8-2 Relación entre tamaño de organización y resultado de SPI para distintos niveles de productividad Figura 8-3 Relación entre VPN de la inversión en SPI y el horizonte de planeamiento (CMMI Nivel 3) Figura 8-4 Relación entre Valor Presente Neto y Horizonte de Planeamiento (CMMI Nivel 5) Figura 8-5 Relación entre VPN y costo de evaluación Figura 8-6 Incremento de costo de evaluación con evaluaciones sucesivas Figura 8-7 Relación entre el VPN y el costo de evaluaciones futuras sucesivas Figura 8-8 Relación entre Valor Presente Neto y Costo por Ingeniero Figura 8-9 Relación entre VPN y costo de oportunidad Figura 8-10 Relación entre Valor Presente Neto y Factor de Incertidumbre Figura 8-11 Relación entre VPN y mejora financiera en rendimiento de activos subyacentes Figura 8-12 Relación entre VPN y probabilidad de éxito en la evaluación Figura 8-13 Relación de VPN con crecimiento futuro Figura 8-14 Relación entre VPN vs. Crecimiento futuro Figura 8-15 Estrategias de crecimiento para distintos tamaños organizacionales Figura 8-16 Decisión de hoja de ruta para acceder a SEI-CMMI nivel Figura 8-17 Variación del VPN con la reducción del esfuerzo de implementación Figura 8-18 Evolución del VPN por mejoras en la relación esfuerzo/tiempo de implementación Figura 8-19 Esfuerzo de implementación de inversión SPI vs. Tamaño de la organización Figura. A-1 Perfil estadístico de CPI para organizaciones [Lawlis1995]...A-295 Figura. A-2 Distribución de CPI por Nivel de Madurez SEI SW-CMM [Lawlis1995]...A-296 Figura. A-3 Fidelidad de Calendario por Nivel de Madurez SEI CMMI [Paulisch 2008]...A

15 ÍNDICE DE TABLAS Tabla 1-1 Mejora de Performance aplicando SEI-CMMI [SEI 2005] Tabla 2-1 Factores que promueven y dificultan iniciativas SPI [Goldenson1995] Tabla 2-2 áreas de proceso para cada nivel de madurez del modelo SEI-CMMI [SEI2009] Tabla 2-3 Retornos de inversión típicos para SPI basados en SEI-CMMI(TM) [Jones1996] Tabla 2-4 Elementos de Costo de SPI a considerar [Walden2002] Tabla 2-5 Performance en Motorola [Diaz1997,Diaz2002] Tabla 2-6 Cantidad de Evaluaciones SEI-CMMI a nivel global [Fuente SEI 2005] Tabla 3-1 Clasificación de validez operacional [Sargent1998] Tabla 4-1 Áreas de Proceso por nivel de madurez SEI-CMMI [SEI2009] Tabla 4-2 Resumen de hipótesis de investigación Tabla 5-1 Frecuencia de Adopción de SEI-CMMI e ISO-9000 por organizaciones en Argentina [CESSI2007] Tabla 5-2 Dependencia de SEI-CMMI e ISO-9000 de parámetros Tabla 5-3 Relación entre SEI-CMMI e ISO-9000 con variables supuestas independientes Tabla 5-4 Análisis GLM para SEI-CMMI (ejecución MiniTab v1.2) Tabla 5-5 Análisis GLM para ISO-9000 (ejecución MiniTab v1.2) Tabla 6-1 Niveles de confianza para una variable aleatoria Z exhibiendo distribución normal Tabla 6-3 Esfuerzo y Tiempo de implementación por nivel SEI-CMMI(TM) Tabla 6-4 Distribución del tamaño de organización Tabla 6-5 Resultados de horizonte de inversión en la población encuestada Tabla 6-6 Resultados de Costo y Plazos de Entrega Tabla 6-7 Respuestas sobre productividad, ingresos y resultados de entrega Tabla 6-8 Mejoras efectivas usando el test de Wilcoxon de 1 prueba Tabla 6-9 Otras mejoras organizacionales Tabla 6-10 Relación con alta madurez Tabla 6-11 Concordancia entre factores ordinales Tabla 7-1 Variables independientes implementadas en modelo de nivel superior Tabla 7-2 Riesgo de evaluación (ξ) y factor de reducción de riesgo (λ) para distintos niveles SEI-CMMI Tabla 7-3 Frecuencia de organizaciones adoptando SEI-CMMI(TM) vs. pronostico de modelo Tabla. A-1 Media y Desvio Standard en Poblaciones por Grupo de Madurez (Resultado MiniTab v1.2)...a-297 Tabla. A-2 Resultados de Simulación de Reducción de Incertidumbre [Paulisch2008]...A-299 Tabla. B-1 Resultados de Evaluaciones SEI SW-CMM (Hayes 1995)...B-301 Tabla. C-1 Datos de encuesta de perfiles SPI realizada junto con CESSI en Argentina...C-303 Tabla. E-1 Datos de Campo Dra. P.Lawlis [Lawlis1995] Correlación entre Performance y SEI SW-CMM...E-306 Tabla. F-1 Resumen de Mapa de Extracción de Datos (Survey CESSI 2007)... F-307 Tabla. H-1 Criterios de Kitchenham para evaluación de robustez de la investigación [Kitchenham2002]...H-316 Tabla. H-2 Criterio de Benbasat para la evaluación de relevancia de la investigación [Benbasat1999]...H

16

17 Hay dos errores que se pueden cometer en el camino a la verdad no llegar al final de la ruta y no comenzar. Buda (Príncipe Gautama Siddharta, fundador del Budismo, A.C.) Capítulo 1 Introducción Este capítulo presenta los antecedentes y fundamentos de la investigación realizada sobre las mejoras en los procesos de producción de software y las características de las inversiones necesarias para realizarlos. Se describen además los objetivos generales y particulares perseguidos por este trabajo y las contribuciones originales propuestas. Finalmente se anticipa la estructura temática y metodología de trabajo a utilizar en la tesis Antecedentes El software se ha constituido en la infraestructura de la sociedad moderna y es, por consiguiente, crítico tanto para las actividades públicas como para las privadas, sosteniendo un espectro de usos altamente sensitivos para el desarrollo económico, científico y social. Al mismo tiempo existe la percepción creciente que la calidad del software y las fallas que pueden ocasionar son un aspecto débil en la cadena de su uso, al punto que eventualmente pueden ponerse en riesgo vidas y negocios. La industria abunda en ejemplos de esfuerzos de desarrollo que son entregados más tarde que lo previsto, a costos mayores, con funcionalidades inferiores a las esperadas, que experimentan fallas significativas o proveen resultados incorrectos. Más allá de avances tecnológicos sustantivos, las demandas siempre crecientes, la complejidad de los problemas resueltos y las escalas de esfuerzo involucradas en el desarrollo de software moderno parecen superar la capacidad de las organizaciones para evitar impactos en su calidad. Es claro que aplicaciones más grandes, más complejas y con mayor dificultad de ser testeadas sólo aumentan el riesgo de encontrar errores de funcionamiento, excepto que al mismo tiempo se reduzcan los defectos introducidos en el software en el momento de su creación o mantenimiento, es decir que se mejore la calidad del desarrollo Problemas en desarrollo de software. El término ingeniería de software fue introducido por primera vez en 1968 durante la conferencia de la OTAN en Garmisch-Partenkirchen [Naur1969], de donde emergió el consenso que existen problemas profundos en la creación y mantenimiento de software. Estos problemas Capítulo

18 fueron discutidos con un enfoque sistémico, entre otros, por Brooks [Brooks1975] en su clásico libro The Mythical Man-Month, donde el término crisis de software fue utilizado para describir los problemas inherentes al desarrollo de software. Brooks distinguió, quizás por primera vez, los principales problemas del desarrollo, que consisten en dificultades inherentes a la naturaleza misma del software como creación intelectual y no sólo accidentes que eventualmente pueden ser resueltos por un proceso de corrección sistemático. Se han realizado numerosos intentos para abordar la mejora de calidad en software a partir de la aplicación de métodos de prueba matemática [Hoare1984], bajo la promesa de lograr desarrollos prácticamente libres de errores mediante la remoción sistemática de todas aquellas partes que no superen una verificación formal y rigurosa. Desafortunadamente, este enfoque sólo ha sido fructífero en dominios de aplicación demasiado estrechos como para causar un impacto significativo en la industria. Sin embargo, la aplicación de las prácticas de ingeniería como enfoque sistemático a la creación de software fue impulsada por Lehman [Lehman1989] y más recientemente por Basili [Basili1996] quienes insisten en considerar la ingeniería de software como una disciplina susceptible de recibir prácticas consistentes con un enfoque científico a los problemas bajo estudio. La aplicación de un enfoque ingenieril a la creación de software invita a desplegar principios y prácticas que la ingeniería utiliza para abordar los problemas esenciales en una variedad de otros dominios tecnológicos. Esta aproximación lleva directamente a tratar la secuencia de tareas involucradas en la creación de software como una red estructurada de actividades repetitivas donde se pueden desplegar criterios de optimización y mejoras. Esta secuencia de actividades recibe el nombre de proceso de desarrollo de software (software development process) y las mejoras que se aplican sobre éste reciben el nombre de mejora de procesos de desarrollo de software (software process improvement o en adelante SPI). Humphrey [Humphrey1989a] fue el primero que postuló que los problemas esenciales al desarrollo de software tienden a ser de gestión y no tecnológicos. Partiendo de esa premisa desarrolló un marco estructurado para la gestión y mejora del proceso de software que luego fue conocido como el modelo de madurez de capacidades para software (capability maturity model for software o SW-CMM) [Paulik1995]. Este marco, patrocinado formalmente por el Software Engineering Institute (SEI) de la Universidad Carnegie-Mellon, utiliza un modelo de referencia con cinco niveles de madurez. La premisa sobre la cual es construido es que la calidad del software es mayormente gobernada por la calidad del proceso utilizado para su desarrollo y mantenimiento [Bamberger1997, Diaz2002, Eickelmann2003, Hefner2001]. El SEI publicó las bases de este modelo inicial, el cual fue mejorado por el Modelo de Capítulo

19 Madurez de Capacidades Integrado (Capability Maturity Model Integrated o CMMI) en el año 2000 [Miller2002]. Este modelo posteriormente evolucionó a la versión 1.1 y luego, en el año 2007, a su versión corriente 1.2, sentando las bases para la puesta en marcha de sistemas de calidad apropiados para la gestión de ambientes de ingeniería de software [Paulik1995]. El SEI ha anunciado la disponibilidad de la versión 1.3 para el año 2010 [SEI2009]. El modelo SEI-CMMI está entonces fundado en la tradición ingenieril de enfatizar la predictibilidad, repetibilidad y la posibilidad de utilizar técnicas estadísticas para los esfuerzos de mejora sistemática en el dominio tecnológico del desarrollo de software. Humphrey [Humphrey1989b] sentó las bases para considerar que si el proceso no está bajo control estadístico no es posible realizar mejora continua sobre él hasta que lo esté. El enfoque de Humphrey está alineado con las tradiciones racionalistas de la ingeniería y, de hecho, sus conceptos pueden verse como derivados de modelos industriales tradicionales Gestión de calidad en software Se piensa a menudo que la búsqueda de calidad es una iniciativa relativamente moderna cuando en realidad es un movimiento milenario. El concepto de la especificación y la necesidad de una razonable uniformidad en la producción de ciertos artefactos pueden encontrarse, mediante técnicas arqueológicas modernas, en nodos de civilización tales como la China imperial, Babilonia, Egipto Antiguo y el Imperio Romano [Abdel-Hamid1990, Li2001, Lawlis1995]. En forma mucho más reciente, en Francia hacia los siglos XVII y XVIII, las más modernas técnicas de ingeniería se aplicaban a la industria naviera de entonces, donde empezaron a utilizarse conceptos como la selección de proveedores basados en costo, capacidad de entrega y habilidad para ajustarse a las especificaciones. Pero no fue hasta mediados del siglo XX cuando las bases fundamentales de la gestión de calidad, tal como se las conoce hoy, fueron establecidas desde el ámbito académico a partir del trabajo de W. Edwards Deming y J.M. Juran. Sus conceptos fueron mayormente tratados como una rareza teórica hasta que en la década de los sesenta Iwau Wanabe implementó en Japón el primer círculo de calidad en NTT Corp, encendiendo una revolución que llevaría a la adopción masiva de estos conceptos primero en Japón y luego en el resto del mundo [Juran1990, Juran1995]. Fue a partir del liderazgo adoptado por Japón que en las postrimerías de la década de los setenta y comienzos de la de los ochenta, la gestión de calidad (o también llamados conceptos de calidad total ) alcanzó su madurez utilizando metodologías, herramientas y conceptos sistémicos a partir de los cuales dejó definitivamente el ámbito académico y se propagó al ámbito industrial. La necesidad de identificar claramente el mecanismo de implementación de la gestión de Capítulo

20 calidad llevó, hacia fines de la década de los ochenta y principios de la de los noventa, a la creación de sistemas de calidad que dieran un marco formal, apropiado y riguroso a la utilización de tecnologías de gestión de calidad, entre otros, el ahora sumamente difundido modelo ISO-9000, modelos derivados, relacionados y similares [Clouse2008]. Sin embargo, las normas ISO-9000 proveen un marco de referencia demasiado general para las particularidades de la industria del desarrollo de software y por lo tanto es necesaria la utilización de modelos derivados a partir de conceptos de ingeniería de software [McGuire2001]. El modelo conceptual representado en la Figura 1-1 muestra que los proyectos de software pueden entenderse como un sistema en equilibrio entre tecnología, recursos y procesos. Los modelos de madurez en general, y el SEI-CMMI en particular, parten de la premisa que la mejor forma de gestionar este sistema es a partir del uso de mejores técnicas de gestión sustentadas en la mejora de procesos [Boehm1981, Butler1995, Card2002]. Figura 1-1 Foco del modelo de madurez de capacidades integrado (Fuente: Inicialmente, las agencias del Gobierno de Estados Unidos de América adoptaron el modelo provisto por estas metodologías como un medio para evaluar durante la fase de adquisición de contratos las capacidades de desarrollo de los oferentes, con la esperanza de lograr de esa forma controlar los riesgos históricamente asociados con proyectos de desarrollo de software tales como incumplimiento de plazos, excesos de costo y defectos entregados, todos ellos endémicos en este ámbito. Con el correr del tiempo, no sólo agencias gubernamentales de Estados Unidos sino la industria en general, han visto crecientemente la evaluación a partir del modelo SEI-CMMI como un requisito necesario para realizar negocios, en particular en instancias de proyectos de gran envergadura o de alto riesgo. Las pequeñas empresas proveedoras de software que desean tener roles protagónicos en este contexto, se ven entonces en la poco envidiable posición de tener que invertir en procesos de mejora de software percibidos a menudo como costosos [Basili1978, Herbsleb1996, Brodman1995, Capítulo