ARTÍCULOS
Metodología para implantar el Modelo Integrado de Capacidad de Madurez en grupos pequeños y emergentes*
Methodology for achieving the Capability Maturity Model Integrated in smalland emerging groups
Metodologia para implementar o Modelo Integrado de Capacidade de Maturidade em grupos pequenos e emergentes
]]> Hugo Arboledaa, Andrés Pazb, Rubby Casallasc
aDirector de la Maestría en Gestión de Informática y Telecomunicaciones, Profesor asociado, Universidad Icesi, Cali, Colombia.
Autor para correspondencia: Universidad Icesi, Calle 18 No. 122-135, Pance, Cali, Colombia. hfarboleda@icesi.edu.co.
bInvestigador y docente, Universidad Icesi, Cali, Colombia.
cProfesora, Universidad de los Andes, Bogotá, Colombia.
Historia del artículo:
Recibido el 21 de noviembre de 2011
Aceptado el 30 de mayo de 2013
On-line el 14 de septiembre de 2013
Resumen
En este artículo se presenta QualDev-Software Process Improvement (SPI), una metodología para ayudar a la gerencia de empresas o departamentos de software pequeños y emergentes a implantar el Capability Maturity Model Integration (CMMI). El objetivo de esta metodología es aumentar la competitividad de estos grupos para que ofrezcan mayor calidad en sus productos y tengan mejores indicadores de productividad. QualDev-SPI se basa en 3 principios: a) pequeños pasos para el mejoramiento alineados con los proyectos de desarrollo; b) procesos livianos apoyados en herramientas, y c) visibilidad a corto plazo de los beneficios. La metodología incluye un modelo de mejoramiento organizacional, una matriz de grados de logro de las prácticas y un mapa de ruta que contiene una definición estandarizada de procesos y de las herramientas de apoyo que facilitan su puesta en marcha.
Palabras clave: Mejoramiento de procesos de software, Modelo Integrado de Capacidad de Madurez, Grupos emergentes, Grupos pequeños.
Códigos JEL: M13. M15. O31.
Abstract
This article presents QualDev-Software Process Improvement (SPI), a specific methodology to help managers of small and emerging business or internal software development departments to implement the Capability Maturity Model Integration (CMMI). The aim of this methodology is to increase competitiveness of these groups by letting them offer more quality in their products, and have better productivity. QualDev-SPI is based on three principles: (i) small steps for improvement aligned with the development projects; (ii) lightweight processes supported by tools, and (iii) short term view of the benefits. The methodology includes an organizational improvement model, a matrix of levels of achievement of practices, and a road map with a standardized definition of processes and support tools to facilitate its implementation.
Keywords: Software process improvement, Capability Maturity Model Integrated, Emerging groups, Small groups.
JEL classification: M13. M15. O31.
Resumo
]]> Neste artigo apresenta-se QualDev-Software Process Improvement (SPI), uma metodologia para ajudar a gestão de empresas ou departamentos de software pequenos e emergentes a implementar o Capability Maturity Model Integration (CMMI). O objectivo desta metodologia é aumentar a competitividade destes grupos para que ofereçam maior qualidade nos produtos e tenham melhores indicadores de produtividade. QualDev-SPI baseia-se em 3 princípios: a) pequenos passos para a melhoria alienados com os projectos de desenvolvimento; b) processos levianos apoiados em ferramentas, e c) visibilidade a curto prazo dos benefícios. A metodologia inclui um modelo de melhoria organizacional, uma matriz de graus de concretização das práticas e um mapa de rota que contém uma definição padronizada de processos e das ferramentas de apoio que facilitam a sua entrada em funcionamento.Palavras chave: Melhoria de processos de software, Modelo Integrado de Capacidade de Maturidade, Grupos emergentes, Grupos pequenos.
Classificações JEL: M13, M15, O31.
1. Introducción
El elevado nivel de competencia que se presenta en el sector informático a nivel mundial y el requerimiento cada vez más sentido de aplicaciones para el soporte del negocio hacen necesario el aumento de la productividad y de la competitividad de los equipos de desarrollo. A través del mejoramiento de los procesos de desarrollo de software se busca reducir los costos, incrementar la productividad y aumentar la calidad de los productos y servicios resultantes de la ejecución de los procesos. Además de estos objetivos, con el mejoramiento de los procesos las organizaciones buscan alinearse con referentes de la industria como ISO 9001 (ISO, 2000) o el Capability Maturity Model Integration (CMMI) (SEI, 2010), para poder competir en los mercados globalizados donde, en muchos casos, son requeridas certificaciones y/o evaluaciones.
El modelo CMMI for Development (CMMI-DEV) reúne un conjunto de buenas prácticas de ingeniería de software que facilitan el mejoramiento gradual de los procesos de gestión de proyectos, gestión de procesos, ingeniería y soporte. El modelo CMMI ayuda a resolver problemas típicos de las organizaciones, tales como productos y servicios que no satisfacen los requerimientos del cliente, demoras y baja rentabilidad en los proyectos, altos costos operacionales, baja productividad, bajos niveles de innovación y desmotivación del personal, todo lo cual trae como consecuencia vulnerabilidad estratégica y poca competitividad en el mercado.
Diferentes iniciativas para implantar CMMI en grupos de desarrollo pequeños han surgido desde que se liberó la primera versión del modelo en 1991 (Garcia et al., 2004, Garcia-Miller et al., 2005, Ginsberg y Quinn, 1995, Johnson y Brodman, 1997, Laryd y Orci, 2000, Miluk, 2006, Paulk, 1998). La clasificación de un grupo de desarrollo pequeño se ha hecho tradicionalmente tomando como referente el número de integrantes del grupo. Por otro lado, la clasificación de acuerdo con el número de integrantes ignora características relevantes que deben ser tomadas en cuenta al momento de proponer un proyecto de mejoramiento de procesos de software. Consecuentemente, la mayoría de enfoques presentados en la literatura para implantar el modelo CMMI en grupos pequeños carece de la adaptación necesaria a muchos contextos con características específicas pero recurrentes (Niazi et al., 2005).
Se definen como grupos emergentes aquellos que nacen de iniciativas spin-off, start-up cafés, los conformados por estudiantes entusiastas, recién graduados y con poca experiencia, o practicantes de la programación sin experiencia y con básica formación en procesos (Tobola, 2012, Ruokolainen, 2007, Bassett, 2007). La metodología QualDev-Software Process Improvement (SPI), del grupo QualDev, que se propone para el mejoramiento de los procesos de estos grupos se fundamenta en los siguientes 3 principios: 1) pequeños pasos para el mejoramiento alineados con los proyectos de desarrollo; 2) procesos livianos apoyados en herramientas open source, y 3) visibilidad a corto plazo de los beneficios. La metodología incluye: a) la definición de un modelo de mejoramiento organizacional; b) una matriz de grados de logro de las prácticas específicas de CMMI, y c) un mapa de ruta que incluye una definición estandarizada de procesos y de las herramientas de apoyo que facilitan su puesta en marcha.
]]> El modelo de mejoramiento organizacional sobre el cual se basa la propuesta es IDEAL (Initiating, Diagnosing, Establishing, Acting and Learning) (SEI, 1996, Blanco y Casallas, 2007). Este modelo es de naturaleza iterativa e incremental, es decir, cada vez que es seguido se completa un ciclo de mejoramiento. Esta característica ayuda a que su ejecución permanente garantice el mejoramiento continuo de la organización en la cual se implemente. CMMI está compuesto por un conjunto de áreas de proceso, y a su vez cada una está definida en términos de prácticas específicas que la organización debe satisfacer.La matriz de grados de logro propuesta para las áreas de proceso de CMMI tiene como objetivo facilitar la determinación del orden en el cual cada área de proceso debe ir implementándose en los grupos de desarrollo (Blanco y Casallas, 2007). La matriz desglosa cada práctica en actividades parciales que incrementalmente van complementándose hasta satisfacer la práctica completa. En particular, en este artículo se presenta como ejemplo un subconjunto de la matriz de grados de logro para las áreas de proceso específicas de Planeación de Proyectos (PP), Monitoreo y Control de Proyectos (PMC) y Medición y Análisis (MA), así como el mapa de ruta para institucionalizar estas áreas. Finalmente, como parte del mapa de ruta se incluyen 3 procesos que satisfacen cada uno un conjunto de prácticas específicas de las 3 áreas de proceso en un determinado grado de logro y unas herramientas que facilitan la puesta en marcha de las prácticas y su institucionalización.
El artículo está organizado de la siguiente manera: la sección 2 presenta el contexto de mejoramiento de procesos de software en empresas pequeñas, así como un contraste con trabajos relacionados. La sección 3 introduce los principios para lograr el mejoramiento de procesos en empresas pequeñas. Para eso, se caracteriza el contexto al cual va dirigido esta propuesta y se incluye un consenso de condiciones comunes para el éxito de iniciativas de mejoramiento de procesos. La sección 4 presenta la adaptación del modelo IDEAL para lograr un modelo de mejoramiento organizacional ajustado al tipo de grupos de desarrollo sobre el cual se enfoca esta propuesta. La sección 5 presenta la matriz de grados de logro. La sección 6 presenta el mapa de ruta para implantar las prácticas específicas introducidas en la sección 5. Finalmente, la sección 7 presenta las conclusiones del presente trabajo.
2. Mejoramiento de procesos de software en empresas pequeñas
En abril de 2008, el CMMI NDIA Working Group (NDIA, 2008) fue creado por el Software Engineering Institute (SEI) y la Asociación Industrial de Defensa Nacional (NDIA, por sus siglas en inglés) con el fin de investigar acerca de la aplicabilidad de CMMI en pequeños negocios.
Entre las razones comúnmente argumentadas para no motivar el estudio de la aplicabilidad de CMMI en empresas pequeñas se encuentran los costos fijos para establecer una adecuada infraestructura, el gran número de roles tradicionalmente sugeridos y la cantidad de información a procesar para quienes no conocen o no han seguido antes el modelo (NDIA, 2010a). CMMI es un modelo de referencia de procesos de software que fue inicialmente diseñado por y para equipos grandes (Habra et al., 1999, Johnson y Brodman, 1997). CMMI-DEV, por ejemplo en su versión 1.2 (SEI, 2006) de representación escalonada, consta de 20 áreas de proceso, cada una con un conjunto de prácticas específicas, lo cual lo hace un modelo extenso. Esta característica, junto con el costo de contratar personal externo e invertir tiempo del personal de la compañía, de acuerdo con (Mitt-Meehan, 2009) y el (NDIA, 2010b), es por lo general el principal obstáculo que enfrentan las organizaciones pequeñas cuando intentan implementar un modelo de capacidad y madurez robusto. Por otra parte, las prácticas del modelo describen qué debe hacerse pero no presentan el cómo (Niazi et al., 2005). Además, las prácticas de las distintas áreas se encuentran interrelacionadas a través de dependencias que no son intuitivamente comprensibles. Algunas de estas prácticas se presentan en un lenguaje especializado y no contienen suficiente ilustración sobre su significado, lo que las hace de difícil interpretación y, por consiguiente, de difícil implantación (Software-Quality-Assurance, 2012, Gallagher, 2002).
Desde los años noventa, diferentes autores han reportado propuestas para adaptar modelos de mejoramiento de procesos de software (en adelante SPI, por sus siglas en inglés) a empresas pequeñas (Pino et al., 2008). Trabajos como los desarrollados por (Ginsberg y Quinn, 1995), (Paulk, 1998), (Johnson y Brodman, 1997) y (Laryd y Orci, 2000) son ejemplos de algunos de ellos. Más recientemente, y haciendo referencia al modelo CMMI v1.1-v1.2, diferentes autores han presentado propuestas para implantar CMMI en empresas denominadas pequeñas.
Uno de los trabajos con mayor envergadura dirigido por el SEI (Garcia et al., 2004) plantea buenas prácticas de implantación en empresas pequeñas, además de un detallado seguimiento del proyecto. La experiencia allí documentada no solo reporta los resultados que se obtuvieron sino que recoge un conjunto de activos y procesos reutilizables para hacer que CMMI responda a las condiciones de las empresas pequeñas. El principal resultado obtenido es la confirmación de la viabilidad técnica de las pequeñas y medianas empresas para adoptar CMMI y de los beneficios que se derivan.
Las metodologías ágiles, el Modelo de Procesos para la Industria de Software (MoProSoft), ISO, Quality Function Deployment (QFD) y Team Software Process (TSP) no solo muestran que es posible implementar mejora de procesos en entornos pequeños, sino que estos se benefician en gran medida por pequeños cambios en sus procesos que han sido introducidos correctamente y de manera incremental.
]]> (Miluk, 2006) presentó una investigación exploratoria con el objetivo de recoger y analizar datos que permitieran indicar si métodos de desarrollo disciplinados y el CMMI para pymes (CMMI-SME) se ajusta tanto a las necesidades del negocio de las pymes como a sus culturas y entornos. El autor divide su investigación en 3 categorías, a las que denomina necesidad, viabilidad técnica y compatibilidad organizacional. Sus datos indican que las pymes presentan problemas en la entrega, calidad y costo de sus productos, así que estas necesitan de métodos disciplinados. También revelan que las condiciones que describen las pymes no son viables técnicamente para implementar CMMI en su forma actual. Por último, señalan que el enfoque preferido para implementar mejoras rápidas y pequeñas en las áreas con problemas no es compatible con CMMI.El común denominador de estas propuestas es que están orientadas a empresas o grupos que si bien son pequeños en términos de número de personas, ignoran algunas características recurrentes del contexto que requieren ser revisadas como motivadoras del éxito o fracaso de una iniciativa de mejoramiento de procesos. En particular para el enfoque metodológico de QualDev-SPI interesan los grupos pequeños con la característica de ser grupos emergentes como organizaciones que necesitan ser económicamente sostenibles.
Por su parte, (Garcia, 2005) proporciona algunos aspectos generales de la adopción de CMMI en lo que denomina entornos pequeños, es decir, en organizaciones y proyectos pequeños. Su estrategia se basa en mitigar los 3 elementos de mayor inversión en CMMI: evaluación, definición/infraestructura y despliegue. Sin embargo, resalta una ventaja particular sobre la complejidad y el costo del despliegue que los entornos pequeños tienen sobre los grandes, y que se debe gracias a su menor tamaño. Esta estrategia se basa en una serie de recomendaciones que las pymes pueden aplicar, pero no cuenta con un modelo de implantación iterativo e incremental que indique las actividades que deban realizarse en cada área de proceso y garantice un mejoramiento continuo en las empresas.
(Alexandre et al., 2006) proponen un marco de trabajo gradual que permita a las pequeñas y medianas empresas iniciar SPI de una forma muy enfocada. Con este se puede alcanzar un nivel aceptable en modelos como el Capability Maturity Model (CMM) y el Software Process Improvement and Capability Determination (SPICE) manteniendo un presupuesto limitado y logrando un progreso rápido. Sin embargo, se enfoca en los niveles de madurez más bajos y en el entrenamiento, en vez de la documentación y la formalización.
Las metodologías ágiles han sido ampliamente acogidas en las pymes con el objetivo de responder rápidamente a las demandas de los negocios. Sin embargo, estas no ofrecen una guía adecuada para el desarrollo de software de calidad (Sutherland et al., 2008). Algunos autores han propuesto que el valor real de estas metodologías solo es alcanzable con su uso disciplinado. (Sutherland et al., 2008) mostraron que Scrum y CMMI, implementados en conjunto, pueden proporcionar a los procesos de software un grado de adaptabilidad y predictibilidad mayor que cualquiera de los 2 por separado. Su propuesta sugiere que CMMI es la forma para proporcionar la disciplina que requieren las metodologías ágiles. Recomiendan usar las prácticas genéricas de CMMI de nivel 3 para extender los beneficios de las metodologías ágiles. Esta estrategia tampoco cuenta con un modelo de implantación iterativo e incremental para el mejoramiento con prácticas específicas para las áreas de proceso.
3. Principios para lograr mejoramiento de procesos exitosos en empresas pequeñas y emergentes
3.1. Caracterización
Para esta propuesta metodológica se ha caracterizado el contexto de aplicabilidad de la siguiente manera:
1. Empresas en periodo de conformación: iniciativas spin-off o start-up.
]]> 2. Grupos o proyectos pequeños, con no más de 10 integrantes.3. Compromiso con la calidad como estrategia competitiva.
4. Conocimiento y práctica mínima de principios: Personal Software Process (PSP) y Team Software Process (TSP).
Las empresas de reciente creación pueden realizar buenas prácticas desde su inicio en el mercado, aun cuando esto implique una inclusión gradual de prácticas. Los grupos de 10 personas o menos en empresas en formación pueden ser monitoreados con más facilidad, de manera que se puedan ejecutar acciones correctivas a tiempo desde el inicio de los proyectos. El compromiso con la calidad asegura un compromiso general, alineado con la estrategia competitiva del negocio. Finalmente, el conocimiento mínimo de prácticas PSP y TSP facilitan la adopción del modelo; esto ha sido ratificado por diferentes autores (Cedillo y Montes de Oca, 2005, Over, 2009, SEI, 2009, Wall et al., 2005).
3.2. Condiciones para el éxito y principios de mejoramiento
(Riley, 2011) presenta un listado ordenado de las condiciones comunes para el éxito de iniciativas de mejoramiento de procesos, y es representativo para diferentes contextos:
1. Compromiso de la alta gerencia.
2. Liderazgo operacional.
3. Comunicación.
4. Entrenamiento de los líderes.
]]> 5. Entrenamiento de los empleados.6. Medición del progreso.
7. Manejo de la iniciativa como un proyecto.
8. Alineamiento de la iniciativa con la estrategia global.
9. Uso de herramientas de soporte.
10. Articulación de beneficios.
11. Mejoramiento incremental.
12. Involucramiento de los empleados.
13. Cambio del sistema de administración de la productividad.
]]> QualDev-SPI se fundamenta en 3 grandes principios que sintetizan estas condiciones de éxito.
• Pequeños pasos de mejoramiento alineados con proyectos de desarrollo: en el contexto de trabajo. Este principio toma en cuenta, entre otras, las consideraciones de éxito 1, 2, 3, 6, 7, 8, 10 y 12. Toda estrategia de mejoramiento de procesos debe permitir que las actividades de mejoramiento se desarrollen de manera paralela a las actividades de desarrollo de software (Ambler, 2012). Así, se deben definir proyectos de mejoramiento de procesos con actividades asignadas a los mismos integrantes del equipo que llevan a cabo actividades de desarrollo del producto de software. Esto evita que se pueda generar resistencia y una sensación de carga adicional de trabajo no alineada con el objetivo de desarrollar software.
• Proyectos de mejoramiento liviano, iterativo e incremental, apoyados en herramientas: en el contexto de trabajo, este principio toma en cuenta, entre otras, las consideraciones de éxito 6, 8, 9, 10, 11 y 12. El mejoramiento de procesos debe incluir incrementalmente prácticas específicas de desarrollo basadas en CMMI. Las prácticas específicas incluidas deben apoyarse en herramientas de soporte que los equipos puedan adoptar fácilmente y a bajo o ningún costo. La experiencia del grupo de investigación con herramientas open source permite resaltar el buen estado de avance en el que se encuentran algunas herramientas de libre acceso y modificación para el soporte de procesos de desarrollo.
• Visibilidad de los beneficios de mejoramiento a corto plazo: en el contexto de trabajo, este principio toma en cuenta, entre otras, las consideraciones de éxito 3, 6, 8, 11, 12. Toda nueva práctica específica, incluida o mejorada como parte del proceso de mejoramiento, debe hacer visible para todos los integrantes las evidencias objetivamente verificables de beneficio para el equipo de desarrollo. Estas evidencias deben ser recogidas y socializadas, y ser visibles en el corto plazo.
4. Modelo organizacional
Como parte de QualDev-SPI, se definió un modelo organizacional (Blanco y Casallas, 2007) para el mejoramiento de procesos tomando como base las características de empresas caracterizadas en la sección 3.1 y los principios definidos en la sección 3.2 que guiarán el mejoramiento en este tipo de grupos.
De acuerdo con estos principios, es necesario que las iniciativas de mejoramiento se encuentren alineadas con las actividades relacionadas con el quehacer de las compañías, es decir, el mejoramiento no debe verse como una actividad separada de los proyectos de desarrollo. Para esto, el modelo organizacional definido en QualDev-SPI integra y adapta ideas de la propuesta de IDEAL y del proceso propuesto por el Team Software Process (TSP) (Humphrey, 2000), lo cual tiene varias ventajas. Por un lado, basarse en este modelo permite definir y ejecutar planes de mejoramiento a partir del desempeño actual de los procesos organizacionales, ya que su objetivo es ''brindar un camino de acciones para desarrollar un proyecto de SPI y establecer las bases para que las organizaciones puedan adaptar el modelo a sus necesidades'' (SEI, 1996, p. 8). Por otro lado, el TSP provee una estructura de desarrollo de procesos de software basada en principios de mejoramiento de calidad de software.
Dado que ambos referentes (IDEAL y TSP) proponen el desarrollo de ciclos iterativos e incrementales donde luego de un ciclo se tienen resultados visibles completos, la propuesta de integración cumple requerimientos del segundo y tercer principio detallados en la sección 3: proyectos de mejoramiento livianos, iterativos e incrementales y visibilidad de los beneficios de mejoramiento a corto plazo. La Figura 1 presenta el esquema general del modelo organizacional para el mejoramiento de procesos de software en empresas pequeñas y emergentes.
]]>En la Figura 1, las fases de Establecimiento Organizacional, Acción y Postmortem Organizacional son organizadas en una estructura cíclica. A los ciclos que conforman estas 3 fases se les llama ciclos de mejoramiento organizacional. A su vez, la fase de Acción está compuesta por un conjunto de subfases en una estructura cíclica. Los ciclos que conforman las subfases de la fase de Acción se llaman ciclos de desarrollo. En los ciclos de mejoramiento organizacional se desarrollan solamente actividades de mejoramiento de procesos. En los ciclos de desarrollo se ejecutan tanto actividades de desarrollo del producto como actividades de mejoramiento de procesos.
En la fase de Establecimiento Organizacional se monta la infraestructura del programa de mejoramiento de procesos, se lleva a cabo un diagnóstico inicial que servirá como punto de partida para las actividades que se emprendan en el mejoramiento del equipo y se define un plan general de mejoramiento que incluye el orden de implantación de las prácticas a mejorar y la toma de decisiones respecto al número de ciclos de desarrollo que se llevarán a cabo. Aun en el contexto de empresas pequeñas y emergentes, es necesario precisar e identificar el estado de implantación de cada una de las prácticas de las áreas de proceso que se deseen mejorar. Esta valoración de las prácticas debe encontrarse apoyada en evidencia objetivamente verificable, es decir, en artefactos resultantes de la ejecución de los procesos que confirmen la realización de dichas prácticas (Reitzig et al., 2002). Como parte del establecimiento de la infraestructura, se definen roles y responsabilidades de quienes guiarán el proceso de mejoramiento a nivel organizacional (Waina, 2004). Para el caso de empresas pequeñas y emergentes es importante definir al menos el rol de una persona que guiará el proceso de mejoramiento. Este rol debe ser rotado periódicamente.
En la fase de Acción se llevan a cabo las actividades de mejoramiento partiendo de los resultados de la fase de Inicio Organizacional. Esta fase está alineada con los ciclos de desarrollo del producto, de manera que en cada una de las subfases se desarrollan tanto actividades de desarrollo de software como actividades de mejoramiento de procesos.
En la subfase de Lanzamiento se lleva a cabo el establecimiento de los objetivos del proyecto. Además de esto se definen objetivos puntuales de mejoramiento de procesos para el ciclo. Aquí se definen roles tanto para las actividades de desarrollo del producto como para las actividades de mejoramiento de procesos. En la subfase de Estrategia se define el alcance del ciclo de desarrollo en términos de funcionalidades para construir en el producto de software y las prácticas específicas del proceso a mejorar. En la subfase de Planeación y Seguimiento se construyen cronogramas de trabajo detallados y se realiza de forma continua su seguimiento a medida que se avanza en la construcción del producto. En la subfase de Ingeniería se llevan a cabo actividades propias de desarrollo del producto (análisis, diseño, construcción y pruebas), al tiempo que se desarrollan actividades relacionadas con el mejoramiento, como el establecimiento o la mejora de procesos, la adopción de nuevas herramientas de hardware o software, la generación de plantillas, la especificación de políticas, etc. En la subfase de Postmortem se analizan los resultados de las actividades de desarrollo de producto y de mejoramiento de procesos para el ciclo de desarrollo que termina, de manera que se pueda definir y establecer acciones de mejora para el siguiente ciclo.
En la fase de Postmortem Organizacional se analizan los resultados del ciclo de mejoramiento organizacional y se toman acciones correctivas apropiadas respecto al cumplimiento de los objetivos relacionados con el mejoramiento a nivel organizacional para iniciar un nuevo ciclo completo de mejoramiento.
5. Matriz de grados de logro
Las prácticas específicas del modelo CMMI describen las actividades consideradas importantes para satisfacer un área de proceso, y están asociadas a los objetivos del área y describen qué hacer para satisfacerlos. El modelo CMMI ofrece algunas sugerencias sobre cómo implementar las prácticas, a manera de sub-prácticas, e indica los productos de trabajo que típicamente deberían producirse al cumplirlas.
Adicionalmente, y de acuerdo con la metodología propuesta, se ha dividido cada una de las prácticas específicas en lo que (Blanco y Casallas, 2007) y (Rodríguez y Casallas, 2007) desarrollaron como grados de logro. Estos últimos están asociados a la evolución o refinamiento de las prácticas específicas. Así, para cada práctica se propone definir un conjunto de grados de logro, los cuales están asociados al conjunto de actividades que deben desarrollarse para satisfacer la práctica. Así, cuanto mayor sea el grado de logro de una práctica específica, más completo es el conjunto de actividades que satisfacen la práctica. Se ha propuesto manejar 3 grados de logro: A) básico; B) intermedio, y C) completo. A continuación se presenta un ejemplo para ilustrar la definición de los grados de logro para una práctica específica.
]]> La práctica específica 1.1 del área de proceso de Planeación de Proyectos (PP SP 1.1: Establecer el alcance del proyecto) puede iniciar su implantación identificando los principales entregables del proyecto, tales como módulos de un sistema de información y aplicaciones, entre otros. Posteriormente, dichos entregables pueden ser desagregados en componentes más pequeños, tales como artefactos de análisis y de diseño, procedimientos, ventanas y documentación, entre otros. Esta descomposición a un nivel mayor de granularidad ayuda a hacer más precisa la estimación de tiempos para un proyecto, ya que permite hacer la estimación a un mayor nivel de detalle. Finalmente, esta práctica específica se puede refinar a través de la asociación de los requerimientos a las tareas específicas que se precisan para la conformación de cada uno de los componentes identificados.Así, para este caso, la identificación de los principales entregables de un proyecto se encontraría en el grado de logro básico, la desagregación de estos en componentes se encontraría en el grado de logro intermedio y la asignación de requerimientos a tareas se encontraría en el grado de logro completo.
Se han definido de la siguiente manera los grados de logro para todas las prácticas:
• Grado de logro básico (A): las actividades de la práctica se realizan de forma básica, a través de la ejecución de procesos definidos. Estos deben estar establecidos, aunque todavía no necesariamente documentados.
• Grado de logro intermedio (B): las actividades de la práctica se realizan con un nivel de detalle mayor que el especificado en el grado de logro anterior y de una forma estructurada y metodológica. Los procesos están establecidos y documentados.
• Grado de logro completo (C): las actividades satisfacen completamente la práctica y se realizan de una forma más adecuada que en el nivel de logro anterior.
En particular, en este artículo se presenta un subconjunto de la matriz de grados de logro para las prácticas específicas de Planeación de Proyectos (PP), Monitoreo y Control de Proyectos (PMC) y Medición y Análisis (MA). La Tabla 1 presenta un subconjunto de la matriz de grados de logro para estas prácticas específicas.
Como se observa en la Tabla 1, algunas prácticas, tales como Monitorear los riesgos del proyecto (PMC SP 1.3), solamente tienen un grado de logro, es decir, únicamente cuentan con la descripción del grado de logro A. Esto significa que al cumplir lo establecido en este grado de logro se desarrollan el conjunto de actividades suficientes para cumplir la práctica de manera satisfactoria.
5.1. Relaciones entre las prácticas
]]> Una vez que se ha desagregado un conjunto de prácticas específicas de una o varias áreas de proceso en sus diferentes grados de logro, es posible hacer un análisis para identificar las dependencias entre ellas. Estas dependencias se pueden establecer no solo entre prácticas de una misma área de procesos, sino entre prácticas de áreas de proceso distintas e incluso entre prácticas de áreas de proceso que no se encuentren en el mismo nivel de madurez. Esto es posible ya que el modelo CMMI es de mejoramiento incremental y algunas áreas de proceso pueden verse como la evolución de áreas de proceso de niveles de madurez anteriores. Un ejemplo es el área de procesos de Administración Integrada de Proveedores, la cual es de nivel de madurez 3 y enriquece las prácticas incluidas en el área de procesos de Administración de Acuerdos con Proveedores, que pertenece al nivel de madurez 2 del modelo, en su representación escalonada.Para la identificación y expresión de las dependencias entre prácticas específicas se usa lo que se ha denominado una Tabla de Dependencias. El diseño está basado en lo propuesto en Test Process Improvement (TPI) de (Koomen y Pol, 1999). Ellos proponen que para mejorar un proceso existente se deben ir alcanzando, incrementalmente, ciertos grados de logro en cada una de las áreas del proceso. Sin embargo, existen dependencias entre estas áreas que establecen el orden en el que se deben alcanzar los grados de logro. Para representar estas dependencias se utiliza una Tabla de Dependencias, que define una serie de puntos de control (checkpoints) para establecer las dependencias del alcance de un grado de logro determinado para cada área del proceso.
En particular, en este artículo se presenta un subconjunto de la Tabla de Dependencias para las prácticas específicas de Planeación de Proyectos (PP), Monitoreo y Control de Proyectos (PMC) y Medición y Análisis (MA), desarrollada por (Blanco y Casallas, 2007) (Tabla 2).
La Tabla 2 muestra una primera idea del orden en el cual una organización debe implantar nuevas prácticas de proceso. Para construir la Tabla de Dependencias entre prácticas específicas de diferentes áreas de proceso se tiene en cuenta la incidencia que las prácticas de cada una de ellas tienen sobre las prácticas de las demás áreas de proceso. Por ejemplo, en la Tabla 2 se puede ver que el grado de logro A de la práctica de PP SP 1.1 Estimar el alcance del proyecto se debe alcanzar primero que el grado de logro A de la práctica de PP SP 1.2 Establecer estimados de atributos de productos de trabajo y tareas. Esta relación es identificable, ya que no es posible realizar estimaciones sin haber identificado por lo menos los principales elementos que compondrán la solución por desarrollar. De la misma forma, se deben establecer relaciones entre prácticas de diferentes áreas de proceso. Por ejemplo, se puede identificar que el grado de logro A de la práctica específica 2.1 de MA es requisito para la implantación del grado de logro C de la práctica específica 1.2 de PP.
Las columnas de la Tabla de Dependencia sirven como referente para la selección de prácticas específicas, en un determinado grado de logro, que se quieren implantar en un ciclo de desarrollo. Así, por ejemplo, es posible decidir implantar las prácticas específicas, en un determinado grado de logro, que incluyan las primeras ''n'' columnas.
Con base en la Tabla de Dependencias y con el resultado del diagnóstico que se realiza en la fase de Establecimiento Organizacional del Modelo Organizacional para el Mejoramiento de Procesos, se puede definir un mapa de ruta para satisfacer las prácticas específicas que se decide implantar.
6. Mapa de ruta
El modelo CMMI no ofrece una guía respecto al orden de implantación de las áreas de proceso, ni respecto a los procesos específicos para satisfacer las prácticas. Es por esto que existe la necesidad de crear estrategias más precisas para facilitar la implantación de las prácticas específicas propuestas. Actualmente existen algunas propuestas de orden de implantación de prácticas específicas de CMMI. Estas propuestas se presentan ante resultados de proyectos de mejoramiento adelantados por diferentes empresas. (Laryd y Orci, 2000) sugieren que el orden de implantación de las áreas de proceso del modelo CMM debe basarse en las características particulares de cada organización; por ejemplo, si la compañía se encuentra enfrentando problemas relacionados con el área de procesos de Gestión de la Configuración (CM, por sus siglas en inglés), el área de procesos de CM deberá ser tratada de forma primordial; si los requerimientos son muy volátiles, será necesario dar prioridad al área de procesos de Gestión de Requerimientos (RM, por sus siglas en inglés).
QualDev-SPI incluye la definición de un mapa de ruta como parte de la estrategia para ayudar a las empresas pequeñas a implantar CMMI. El mapa de ruta define qué prácticas se van a implantar en cada uno de sus grados de logro en un determinado ciclo de mejoramiento organizacional y mediante qué procesos y herramientas se logrará dicha implantación.
]]> La planeación de los ciclos de mejoramiento organizacional, en la fase de Establecimiento del Modelo Organizacional para el Mejoramiento de Procesos, permite definir qué prácticas se van a implantar, en cada uno de sus grados de logro, en un determinado ciclo de mejoramiento.Se ha propuesto que para cada ciclo de mejoramiento organizacional se defina un proceso que relacione las prácticas específicas en los grados de logro que se van a implantar. Así, para cada ciclo de mejoramiento se implanta un proceso definido que incluye actividades que pueden estar relacionadas con diferentes prácticas específicas. A continuación se presenta el mapa de ruta para implantar las prácticas específicas de Planeación de Proyectos (PP), Monitoreo y Control de Proyectos (PMC) y Medición y Análisis (MA).
6.1. Mapa de ruta para la implantación de las prácticas específicas de Planeación de Proyectos, Monitoreo y Control de Proyectos y Medición y Análisis
La razón para escoger estas áreas de proceso para mejorar son las características de las empresas para las cuales está dirigida esta propuesta. Como se introdujo antes, está orientada a empresas pequeñas que satisfagan un conjunto de condiciones definidas. Entre estas condiciones está que: a) tengan un avance significativo en la definición y puesta en práctica de procesos de ingeniería como el proceso de solución técnica, y b) presenten inmadurez en la ejecución de los procesos de gestión de los proyectos.
El mapa de ruta que se ha definido para implantar estas áreas de proceso sugiere el desarrollo de 3 ciclos de mejoramiento organizacional. Para cada ciclo de mejoramiento se creó un proceso que incluye un conjunto de prácticas específicas en un determinado grado de logro. Los 3 procesos son llamados básico, intermedio y completo. El proceso asociado a cada ciclo de mejoramiento organizacional incluye las actividades del proceso asociado al anterior ciclo. Así, gradualmente se incluyen actividades hasta lograr satisfacer todas las prácticas específicas en todos sus grados de logro.
Es importante que cada proceso se implante en orden en la organización. Es decir, solo hasta cuando el proceso básico funciona correctamente se inicia el siguiente ciclo de mejoramiento organizacional.
Para la institucionalización de cada proceso, una empresa puede desarrollar varios ciclos de desarrollo dentro de cada ciclo de mejoramiento organizacional. En términos generales, en el proceso básico se espera que se empiece a generar la cultura de registro de los tiempos de ejecución de tareas. Esto permite que posteriormente se tenga información histórica suficiente para determinar estimaciones confiables y el ejercicio de estimación arroje resultados más precisos. En el proceso intermedio se espera que la ejecución de las prácticas permita una mayor visibilidad en cuanto al nivel de avance de los proyectos. Esta visibilidad se logra a través del análisis de la información que se va obteniendo a través del registro de los tiempos. Finalmente, en el proceso completo se espera la realización de actividades de planeación y control basadas en datos históricos recopilados durante la ejecución de los proyectos, la determinación de estimados de planeación que obedecen a patrones definidos por el desempeño en proyectos anteriores y el control del proyecto realizado sobre una base cuantitativa proporcionada por los indicadores de los proyectos.
En las siguientes secciones se presenta cada uno de estos procesos. En la página del proyecto se presentan el detalle y la descripción de los procesos y la interacción con las herramientas que se desarrollaron para dar soporte al proceso.
6.2. Proceso básico para Planeación de Proyectos, Monitoreo y Control de Proyectos y Medición y Análisis
El proceso básico es el proceso más liviano, contiene pocas actividades y busca ser de fácil implantación en cualquier empresa pequeña. Con el proceso básico se espera que sean utilizadas por primera vez las herramientas de soporte a los procesos. La Figura 2 presenta el proceso básico. La notación utilizada para representarlo es Business Process Model Notation (BPMN)1.
]]>
El proceso comienza con la actividad de Lanzamiento. Esta actividad se lleva a cabo para satisfacer la práctica específica 1.1 del área de proceso de Medición y Análisis de CMMI en su grado de logro A (MA SP 1.1 A). Es importante que para cada uno de los objetivos se definan métricas (MA SP 1.2 A), procedimientos de recolección y almacenamiento de datos (MA SP 1.3 A) y procedimientos de análisis (MA SP 1.4 A). En la actividad de Estrategia se hace la estimación del alcance del ciclo (PP SP 1.1 A) y, de igual forma, se hace la estimación de productos y tareas (PP SP 1.2 A). La actividad de Planeación Semanal busca construir, de manera gradual, el presupuesto y el cronograma del ciclo (PP SP 2.1 A). En la actividad de Revisión Semanal se monitorean los parámetros de planeación del ciclo (PMC SP 1.1 A) y los compromisos (PMC SP 1.2 A). En el Postmortem se analizan y comunican los resultados del ciclo en busca de oportunidades de mejora tanto de las actividades de mejoramiento como de las actividades propias del desarrollo del producto (MA SP 2.4 A).
6.3. Proceso intermedio para Planeación de Proyectos, Monitoreo y Control de Proyectos y Medición y Análisis
El proceso intermedio es una extensión del proceso básico; para dar inicio a este es necesario que este último se encuentre plenamente definido e institucionalizado. En este se aumenta el número de prácticas por satisfacer, lo que conlleva la creación de nuevas actividades y la actualización de otras. Estas actualizaciones impactan los formatos, el uso de herramientas y demás productos relacionados con la ejecución de los procesos. Como parte del objetivo de este proceso se espera que las herramientas de soporte se usen en su totalidad. La Figura 3 presenta el proceso intermedio.
En la actividad de Estrategia se hacen cambios de manera que se satisfaga el grado de logro B de la práctica PP SP 1.1. El objetivo de la actividad de Definición de Riesgos es que todos los integrantes del grupo, bajo la guía del líder, identifiquen los riesgos más importantes del proyecto y/o del ciclo (PP SP 2.2 A). El monitoreo y control de los riesgos (PMC SP 1.3 A) es fundamental para tomar acciones correctivas a tiempo. En cuanto a la actividad de Planeación Global, se elaboran planes completos para cada ciclo, incluyendo la identificación concreta de hitos. Esta identificación de hitos ayuda a satisfacer la práctica de establecer el presupuesto y el cronograma (PP SP 2.1 A). Esta actividad también ayuda a satisfacer la práctica de establecer el presupuesto y el cronograma (PP SP 1.4 A). En la actividad de Seguimiento, se hace el seguimiento de hitos (PMC SP 1.7 A) y, en general, del progreso del proyecto (PMC SP 1.6 A).
6.4. Proceso completo para Planeación de Proyectos, Monitoreo y Control de Proyectos y Medición y Análisis
El proceso completo es una extensión del proceso intermedio. En este se completan las prácticas que en el nivel anterior hacían falta por satisfacer de acuerdo con el modelo referente de procesos. Para la ejecución de este proceso es importante tener plenamente institucionalizados los 2 procesos anteriores. Las actualizaciones al proceso intermedio para crear el proceso completo se ven particularmente en las prácticas relacionadas con MA, ya que estas prácticas son las que apoyan a los integrantes del grupo a tomar decisiones y seguir las acciones correctivas necesarias durante el ciclo. La Figura 4 presenta el proceso completo.
]]>
En la actividad de Lanzamiento, la definición de métricas avanza al siguiente grado de logro (MA SP 1.2 B). En el proceso completo el seguimiento es continuo. Es por esto que los procedimientos de análisis incrementan su grado de logro (MA SP 1.4 B). En cuanto a la actividad de Estrategia, la estimación del alcance del ciclo satisface el grado de logro C de la práctica PP SP 1.1. En cuanto a la estimación del trabajo, en este proceso se aumenta el grado de logro al C (PP SP 1.2 C). En cuanto a la actividad de Planeación Global, se identifican las dependencias entre las tareas. De esta forma se avanza el grado de logro del establecimiento de cronograma y presupuesto (PP SP 2.1 B).
En el proceso completo, los riesgos son claramente clasificados en 3 grupos: del equipo, del producto y del proceso. Los criterios de evaluación de cada riesgo tienen en cuenta la probabilidad de ocurrencia (alta, media, baja) y el impacto, si el riesgo llegara a convertirse en un problema (alto, medio, bajo). Para determinar a qué riesgos se les hace seguimiento, se propone construir una matriz en donde se clasifican según los 2 criterios mencionados anteriormente y de esta forma se visualizan los más críticos. Así se avanza a (PP SP 2.2 B).
En el proceso completo se incluye la actividad de seguimiento de los objetivos y metas del ciclo. De esta forma se tiene el control de estos a medida que se avanza en el ciclo y se toman acciones correctivas sustentadas sobre datos cuantitativamente verificables. Estas acciones ayudan a satisfacer otras prácticas de MA.
7. Conclusiones
En este artículo se ha presentado una metodología para ayudar a las empresas pequeñas a implantar CMMI. Como parte de esta metodología se exponen 3 principios fundamentales para lograr el mejoramiento de procesos en este tipo de empresas. De igual forma se ha definido un modelo de mejoramiento organizacional de procesos y un mapa de ruta concreto para mejorar 3 áreas de proceso de CMMI.
Los principios presentados son la base para la definición tanto del modelo organizacional de mejoramiento, como para la definición del mapa de ruta. Se puede concluir que los pequeños pasos para el mejoramiento alineados con los proyectos de desarrollo buscan ser una estrategia que motive el mejoramiento del grupo, apoyado a la vez por los procesos livianos que no demandan dedicación exclusiva en el mejoramiento y la visibilidad a corto plazo de los beneficios del mejoramiento.
Como parte de las contribuciones logradas con esta propuesta está la construcción de las herramientas Planning Tool, SPCC y ChangeSet (QualDev, 2008) para el soporte al proceso de desarrollo. La última de ellas apoya el proceso de Administración de Configuración. Estas herramientas han sido construidas a medida que se ha refinado el modelo organizacional de mejoramiento y al tiempo que se refina la definición y documentación de los procesos de desarrollo seguidos. En el grupo se han especificado los requerimientos que satisfacen las herramientas, de manera que cumplen el modelo de referencia de procesos seguido, para el caso propio con CMMI.
]]> De acuerdo con los principios definidos, es necesario que las iniciativas de mejoramiento se encuentren alineadas con las actividades de desarrollo. Por esto, el modelo organizacional de mejoramiento integra el modelo IDEAL y el proceso TSP. Así se logra que los equipos de desarrollo realicen ciclos cortos e incrementales que incluyen actividades de desarrollo y de mejoramiento de procesos, logrando visibilidad de resultados a corto plazo.Debido al gran tamaño y a la complejidad del modelo CMMI, se hace necesaria la generación de estrategias que ayuden a su implantación, especialmente en las organizaciones que no cuentan con los recursos requeridos para este fin. En el caso del grupo de desarrollo e investigación, se encuentra que la definición de un mapa de ruta como estrategia para implantar CMMI requiere la integración de actividades relacionadas con diferentes prácticas específicas en diferentes grados de logro. Así se pueden crear procesos complementarios que permiten integrar de manera natural prácticas de proceso que se presentan separadas en el modelo CMMI.
La identificación de grados de logro para cada una de las prácticas que constituyen las diferentes áreas de proceso es un ejercicio importante para la comprensión del modelo, ya que de esta forma es posible determinar el nivel de complejidad que acarrea la implementación de cada una de ellas y la forma de abordar dicha complejidad de manera gradual. Igualmente, la identificación de las relaciones entre las prácticas y sus niveles de logro permite priorizar el orden en que estos deben ser implantados.
Como trabajo futuro, se plantea la validación y la retroalimentación de esta propuesta por parte de las empresas pequeñas en las cuales se ha puesto en marcha QualDev-SPI. Allí se expondrá en detalle la caracterización de estas empresas con las que se ha trabajado y los resultados obtenidos en las implementaciones de la metodología propuesta en este artículo. También se presentarán las lecciones aprendidas durante este proceso. De igual forma se hace necesaria la definición de diferentes mapas de ruta y herramientas para implantar prácticas específicas de otras áreas de proceso que se integren con los procesos presentados en esta propuesta.
Conflicto de intereses
Los autores declaran no tener ningún conflicto de intereses.
Notas
* Los autores agradecen a todo el grupo QualDev, de manera especial a Sergio Rodríguez y Mónica Blanco, quienes desarrollaron sus tesis de Maestría alrededor del tema aquí presentado y de las cuales se reportan algunos de los resultados obtenidos. También al grupo Lidie y a las personas de las empresas Ubiquando, Aplicaciones Ltda. e Icono, por su ayuda e interés en la implementación de esta propuesta y la utilización de las herramientas.
]]> 1 http://www.omg.org/spec/BPMN/.
Bibliografía
1. Alexandre S, Renault A, Habra N. OWPL: A Gradual Approach for Software Process Improvement in SMEs. 32nd EUROMICRO Conference on Software Engineering and Advanced Applications (EUROMICRO-SEAA'06). IEEE Computer Society. 2006. [ Links ]
2. Ambler SW. Software Process Improvement (SPI). Best Practices. Ambysoft; 2012. Disponible en: http://www.ambysoft.com/essays/spiTips.html [consultado 14 Oct 2012] [ Links ].
3. Bassett RK. To the Digital Age: Research Labs, Start-up Companies, and the Rise of MOS Technology (Johns Hopkins Studies in the History of Technology). Baltimore: The Johns Hopkins University Press; 2007. [ Links ]
4. Blanco M, Casallas R. Propuesta estratégica para el mejoramiento de procesos en organizaciones pequeñas de desarrollo de software: caso Qualdev Group [tesis de Maestría]. Bogotá: Universidad de los Andes, Maestría en Ingeniería de Sistemas; 2007. [ Links ]
5. Cedillo K, Montes de Oca C. Accelerating CMMI implementation with PSP and TSP in a small organization. Software Engineering Process Group. QuarkSoft, S.C. and Center for Mathematical Research (CIMAT); 2005. Disponible en: http://www.sei.cmu.edu/library/abstracts/presentations/Cedillo-SEPG2005.cfm [consultado 14 Oct 2012] [ Links ].
6. Gallagher BP. Interpreting Capability Maturity Model Integration (CMMI) for Operational Organizations. Software Engineering Institute. Carnegie Mellon University; 2002. Disponible en: http://www.sei.cmu.edu/library/abstracts/reports/02tn006.cfm [consultado 14 Oct 2012] [ Links ].
7. Garcia S. Thoughts on Applying CMMI in Small Settings. Pittsburg: Carnegie Mellon University, Software Engineering Institute; 2005. Disponible en: http://www.sei.cmu.edu/library/assets/garcia-thoughts1.pdf [consultado 14 Oct 2012] [ Links ].
8. Garcia S, Cepeda S, Miluk G, Staley MJ. CMMI in Small Settings Toolkit Repository. Pittsburg: Carnegie Mellon University, Software Engineering Institute; 2004. Disponible en: http://seir.sei.cmu.edu/toolkit/ [consultado 14 Oct 2012] [ Links ].
9. Garcia-Miller S, Graettinger CP, Kost K. Improving, Processes in Small Settings (IPSS) International Process Research Consortium (IPRC). Software Engineering Institute; 2005. Disponible en: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C3ED03336A31C5EB18723B1D2A862196?doi=10.1.1.138.1846rep=rep1type=pdf [consultado 14 Oct 2012] [ Links ].
10. Ginsberg M, Quinn L. Process Tailoring and the Software Capability Maturity Model (CMU/SEI-94-TR-024). Software Engineering Institute; 1995. Disponible en: http://www.sei.cmu.edu/library/abstracts/reports/94tr024.cfm [consultado 14 Oct 2012] [ Links ].
11. Habra, N., Niyitugabira, E., Lamblin, A.C., Renault, A. (1999). Software Process Improvement in Small Organizations Using Gradual Evaluation Schema. Product Focused Software Process Improvement. Oulu. Disponible en: http://www.info.fundp.ac.be/~nha/Monsite/PubsPdf/Profes99.pdf [consultado 14 Oct 2012] [ Links ].
12. Humphrey WS. Introduction to Team Software Process. Reading: Addison Wesley Logman Inc; 2000. [ Links ]
13. International Standards Organization - ISO. (2000). ISO 9001:2000. Disponible en: http://www.iso.org/iso/catalogue_detail?csnumber=21823[consultado 14 Oct 2012] [ Links ].
14. Johnson D, Brodman J (1997). Tailoring the CMM for Small Business, Small Organizations, and Small Projects. Software Process Newsletter (8). IEEE. [ Links ]
15. Koomen T, Pol M. Test Process Improvement: A Practical Step-by-Step Guide to Structured Test. New York: Addison-Wesley; 1999. [ Links ]
16. Laryd, A., Orci, T. (2000). Dynamic CMM for Small Organizations. First Argentine Symposium on Software Engineering (ASSE 2000). Disponible en: http://www.uml.org.cn/cmm/pdf/1116/laryd00dynamic.pdf [consultado 14 Oct 2012] [ Links ].
17. Miluk G. An exploratory study investigating the organizational and technical impacts of applying disciplined system development processes (CMMITM in small to medium sized enterprises. Pepperdine University; 2006. [ Links ]
18. Mitt-Meehan A (2009). CMMI for Small Organizations: A Study of its Suitability [Master's Thesis]. Dublin: Dublin City University. [ Links ]
19. NDIA CMMInull Working Group. NDIA CMMI® Working Group Charter. National Defense Industrial Association (NDIA); 2008. Disponible en: http://www.dtic.mil/ndia/2008systems/7422Draper.pdf [consultado 14 Oct 2012] [ Links ].
20. NDIA. CMMInull Working Group. Using CMMI® Effectively for Small Business. Denver, CO: NDIA - SEI; 2010. Disponible en: http://www.dtic.mil/ndia/2010CMMI/TuesdayTrack2_10970PanelCMMIsmall.pdf [consultado 14 Oct 2012] [ Links ].
21. NDIA Systems Engineering Division, CMMI Working Group. Task Report: CMMI® for Small Business in the Defense Industry. National Defense Industrial Association; 2010. Disponible en: http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Documents/Studies/TaskReport_CMMI4SmallBusiness-final_2010l.pdf [consultado 14 Oct 2012] [ Links ].
22. Niazi M, Wilson D, Zowghi D. A maturity model for the implementation of software process improvement: an empirical study. Journal of Systems and Software. 2005; 74(2):155-72. [ Links ]
23. Over J. Using TSP to implement CMMI. Pittsburg: Software Engineering Institute, Carnegie Mellon University; 2009. [ Links ]
24. Paulk M. Using the Software CMM in Small Organizations. Carnegie Mellon University. Software Engineering Institute; 1998. Disponible en: http://repository.cmu.edu/cgi/viewcontent.cgi?article=1010context=isr [consultado 14 Oct 2012] [ Links ].
25. Pino FJ, García F, Piattini M. Software process improvement in small and medium software enterprises: A systematic review. Software Quality Journal. 2008; 16(2):237-61. [ Links ]
26. QualDev (2008). QualDev Projects. Disponible en: http://sistemas.uniandes.edu.co/~qualdev/wikiMain/doku.php?id=topics:softwareprocesses:projects [consultado 14 Oct 2012] [ Links ].
27. Reitzig RW, Miller JB, West D, Kile RL. Achieving Capability Maturity Model Integration (CMMI) Maturity Level 2 Using IBM Rational Software's Solutions. IBM Rational Software; 2002. Disponible en: http://www.cognence.com/pdfs/CMMI_ProcessAndRequirementsManagement_WhitePaper%20v1.0.pdf [consultado 14 Oct 2012] [ Links ].
28. Riley L. A Mixed Method Analysis to Refine an Organizational Change Model for Technology Organizations (Chapter 7). En: Lentz C.A., Riley L., Dues P., Salas-Amaro A., Land D., Fisher-Blando J., et-al, editors. The Refractive Thinker (Vol II): Research Methodology, second edition. Las Vegas: The Refractive Thinker Press; 2011. [ Links ]
29. Rodríguez SR, Casallas R. Qualdev SPI: mapa de ruta para implantar planeación de proyectos, monitoreo y control de proyectos y medición análisis en el nivel 2 de CMMI en empresas pequeñas [tesis de Maestría]. Bogotá: Universidad de los Andes, Maestría en Ingeniería de Sistemas; 2007. [ Links ]
30. Ruokolainen J. Constructing a market domain model for start-up software technology companies: A case study. Journal of Engineering and Technology Management. 2007; 24(3):186-202. [ Links ]
31. Software Engineering Institute - SEI. CMMI® for Development. Version 1.2. Pittsburg: Carnegie Mellon University; 2006. Disponible en: http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm [consultado 14 Oct 2012] [ Links ].
32. Software Engineering Institute - SEI. Implementing CMMI for High-Performance. London: Carnegie Mellon University; 2009. Disponible en: http://www.cmminews.com/2009/pdfs-sessions/73.pdf [consultado 14 Oct 2012] [ Links ].
33. Software Engineering Institute - SEI. Capability Maturity Model Integration (CMMISM) Version 1.2. Pittsburg: Carnegie Mellon University; 2010. Disponible en: http://www.sei.cmu.edu/library/assets/cmmi-overview071.pdf [consultado 14 Oct 2012] [ Links ].
34. Software Engineering Institute - SEI. IDEALSM: A User's Guide for Software Process Improvement. Pittsburg: Carnegie Mellon University; 1996. Disponible en: http://www.sei.cmu.edu/reports/96hb001.pdf [consultado 14 Oct 2012] [ Links ].
35. Software-Quality-Assurance (2012). The CMMi easy button. Software Quality Assurance. Disponible en: http://www.software-quality-assurance.org [consultado 14 Oct 2012] [ Links ].
36. Sutherland J, Jakobsen CR, Johnson K. Scrum and CMMI Level 5: The Magic Potion for Code Warriors. 41st Hawaii International Conference on System Sciences. IEEE. 2008. Disponible en: http://systematic.com/media/282221/scrum_and_cmmi_level_5___the_magic_potion_for_code_warriors.pdf [consultado 14 Oct 2012] [ Links ].
37. Tobola J. How to build an IT spin-off company. Proceedings of the 6th IFIP WG 6.6 international autonomous infrastructure, management, and security conference on Dependable Networks and Services (AIMS-12). Berlin: Springer-Verlag; 2012. [ Links ]
38. Waina, R.B. (2004). How do I implement the CMMI? The Department of the Navy's Information Technology Magazine. Disponible en: http://www.doncio.navy.mil/chips/ArticleDetails.aspx?ID=3362 [consultado 14 Oct 2012] [ Links ].
39. Wall DS, McHale J, Pomeroy-Huff M. Case Study: Accelerating Process Improvement by Integrating the TSP and CMMI. Software Engineering Institute - SEI. Carnegie Mellon University; 2005. Disponible en: http://www.sei.cmu.edu/library/abstracts/reports/07tr013.cfm [consultado 14 Oct 2012] [ Links ].
]]>