Actualmente los departamentos de I+D de muchas organizaciones tecnológicas comienzan a valorar la necesidad de contar con unos estándares de calidad regulados por procesos consistentes que aseguren la calidad del producto final. En la I+D, especialmente en las Pequeñas y Medianas Empresas, tradicionalmente se ha priorizado la inversión en investigación sobre la calidad del producto desarrollado, un problema que afecta a la difusión y a la rentabilidad de los resultados. CMMI propone una serie de prácticas que ayudan a establecer un modelo de mejora de los procesos de calidad de la organización, pero muchos departamentos de I+D, debido al formato de los proyectos que desarrollan, encuentran difícil aprovechar sus características para impulsar la mejora. Este artículo trata de enfocar a las PYMEs dedicadas al I+D hacia la implementación de CMMI salvando estos obstáculos.
Implementar CMMI en el departamento de I+D+i de una organización de pequeño tamaño es una tarea compleja. Durante el proceso realizado los esfuerzos invertidos han ido en la línea de crear un conjunto sólido de prácticas agrupadas en áreas que conjuntasen todas las acciones que se venían realizando de forma previa al Modelo CMMI y que ya cubrían ciertos aspectos exigidos por el Modelo y que incluyeran nuevas prácticas que completasen las necesidades a cumplir para alcanzar el Nivel de CMMI2 en una representación escalonada.
Los proyectos de I+D+i realizados en cooperación con otras entidades nacionales o europeas y bajo distintos tipos de ayuda económica que brindan organismos públicos, adoptan un ciclo de vida considerado estándar para este tipo de actuaciones.
Este ciclo de vida común a casi todos los proyectos supone la adopción de un modelo distribuido en fases secuenciales muy diferenciadas entre si y que ofrecen una imagen algo rígida de la evolución del proyecto dedicando a cada actividad del proyecto un periodo de tiempo determinado y alejándose de lo que los modelos actuales de Ingeniería de Software aconsejan como planificaciones iterativas o modelos en cascadas.
De esta forma un proyecto de I+D+i se divide en Paquetes de trabajo, que se ordenan de forma secuencial de modo que el finalizar uno siempre comienza otro nuevo sin la posibilidad de revisar el anterior.
En la Figura 1 se observa cómo se dedica inicialmente el tiempo a la captura de requisitos. Después se realiza el diseño y la arquitectura de los diferente módulos que compondrán el sistema. En el siguiente Paquete se desarrollan estos módulos
atendiendo al diseño del Paquete anterior. Después se procede a la Integración de todos y cada uno de los módulos para, por fin, realizar las pruebas y validación. Además existen dos Paquetes de trabajo transversales a todos los anteriores, el de Gestión y el de divulgación y explotación de resultados, vivos desde el comienzo hasta el fin del ciclo de vida del proyecto.
Es habitual la obligatoriedad de volver atrás en las fases de vida de un proyecto, (aquí denominadas Paquetes de Trabajo), para realizar modificaciones que pueden provenir, en el caso que nos ocupa (I+D+i), de un cambio en el estado del arte del campo tecnológico en investigación o en la peor situación, que el equipo de investigación descubra que la línea de investigación que mantiene no es la correcta para la consecución de los objetivos del proyecto. En cualquier caso, ambas situaciones obligan a un cambio, a una vuelta atrás en el desarrollo del proyecto, que hará necesariia una nueva captura de requisitos, un nuevo rediseño y por consiguiente nuevos desarrollos. Una planificación que contemple esta posibilidad de cambio, que asuma la falibilidad del equipo de desarrollo permite reaccionar a tiempo y evaluar y medir las consecuencias del cambio con agilidad. Sin embargo en el modelo estático y rígido de los proyectos I+D+i se convierte en misión imposible ya que es obligado justificar horas y esfuerzos de trabajo a los distintos paquetes de trabajo según el calendario propuesto y no es asumible ante un proceso de justificación de horas que se dediquen horas a tareas no planificadas en la propuesta inicial del proyecto.
En los apartados siguientes se muestra un enfoque simple y que ha resultado eficaz para adaptar las áreas de proceso de CMMI en su nivel 2 escalonado al Departamento de I+D+i de una Pyme. El exigente proceso de evaluación (SCAMPI), que ha sido superado con éxito es una prueba de la validez del Modelo y de su adecuación para adaptarse a otras empresas dedicadas a la I+D+i.
En lo que se refiere a la Gestión de Requisitos, CMMI provee un marco bastante flexible, sobre todo en lo relativo al nivel 2 -área de proceso REQM [2]-, al menos en relación con otras áreas. Las prácticas que propone son bastante simples y casi se podría decir que intuitivas, hasta el punto de que pueden quedarse cortas para organizaciones con larga experiencia en lo referente al tratamiento de las necesidades del cliente. En cualquier caso, un buen documento de requisitos es una herramienta sencilla de usar y supone un primer paso que facilita el cumplimiento de las prácticas. Este documento funcionará como un catálogo que mostrará los requisitos de manera estructurada, dotando a cada uno de ellos de su correspondiente ficha, de manera que los requisitos no estén distribuidos en diferentes soportes y con diversas estructuras, facilitando de esta manera su tratamiento. El formato de estas fichas podría ser el que muestra el Cuadro I.
Una ficha estructurada de esta manera permite al analista encargado de transformar los requisitos de usuario, generalmente desestructurados y con una sintaxis poco clara, en un conjunto de elementos no ambiguos y sencillos de comprender y aplicar (práctica SP1.1) y que mantienen perfecta trazabilidad con sus fuentes así como con sus requisitos y productos de trabajo relacionados (práctica SP1.4).
Estableciendo un catálogo con este formato, sería sencillo asegurar la práctica SP1.2, que exige la obtención del compromiso de los implicados, mediante el envío y confirmación del documento por parte de los participantes, tanto desarrolladores del proyecto como clientes.
Para la práctica SP1.3 (Gestionar los cambios en los requisitos), lo primero es comprender la esencia de lo que CMMI, y en general todas las metodologías tanto ágiles como de procesos, pretenden con esta práctica. Es conveniente asimilar que los cambios en los requisitos son propuestas que añaden valor al producto y que por lo tanto incrementan la satisfacción final del cliente. Esto no significa que sea adecuado aceptar todos los cambios propuestos. La aceptación o el rechazo de un cambio debe realizarse tras el conveniente análisis del impacto del mismo en conjunto con los implicados en el proyecto. Un apartado en el catálogo de requisitos que recoja el historial de cambios con su correspondiente impacto es una herramienta útil y necesaria, pero rara vez suficiente. Conviene emplear también un catálogo de Peticiones de Cambio, estructurado igualmente en fichas y sometido a revisiones periódicas, de manera que las peticiones se gestionen correctamente y se asegure la realización de los cambios.
Por último, para garantizar el cumplimiento de la práctica SP1.5, que exige asegurar que los productos de trabajo generados cumplen con los requisitos provistos, una forma sencilla y útil es realizar auditorías periódicas que garanticen la adecuación de lo generado con lo solicitado. Estas auditorías no deben confundirse con las pruebas: son auditorías funcionales, normalmente realizadas poco tiempo antes de cada hito, en las que un evaluador detecta y documenta inconsistencias con la especificación para que se apliquen las correspondientes acciones correctivas.
En lo que se refiere a la Planificación del Proyecto, CMMI aporta una serie de prácticas principalmente orientadas a la realización de una estimación fundamentada, el desarrollo del plan propiamente dicho y la adecuación de todos los recursos participantes en el proyecto con todos los demás proyectos de la organización. De esta manera el área de proceso PP se divide en las siguientes tres metas específicas:
Para las prácticas correspondientes a la consecución de la primera meta, SG1, se ha optado por el establecimiento de un método de estimación propio, documentado en una guía, que divide las tareas y los demás atributos a estimar en dos tipos: aquellas tareas comunes a todos los proyectos que por su carácter tienden a finalizar con una duración similar independientemente del contexto en el cual se ubiquen -es decir, del proyecto dentro del cual se realicen- y, por otro lado, todo lo demás, esto es, tareas y otros parámetros particulares de un proyecto que por sus características especiales poseen magnitudes fuertemente dependientes del contexto.
Para las del primer tipo se ha establecido un histórico que identifica y cataloga las tareas según su área de aplicación. El jefe de proyecto es responsable de actualizar el histórico con las tareas correspondientes al término de cada reunión de seguimiento (ver sección C). De esta forma, a la hora de planificar un proyecto, se tiene una estimación objetiva fundamentada en la experiencia de la duración de las tareas más habituales, como pueden ser: elaboración del plan de proyecto, gestión de riesgos, especificación de requisitos, reunión de seguimiento, auditoría de calidad, etc. Para los parámetros del otro tipo, aquellos que son muy dependientes del proyecto y difícilmente exportables, se establece un método de estimación basado en el popular método Delphi [10]. Se establece un juicio de expertos tras una discusión basada en el citado método y las diferentes visiones se ponen en común y se realiza un cálculo del parámetro deseado mediante la fórmula PERT (ver fórmula 1).
siendo:
De esta manera se asegura el cumplimiento de las prácticas SP1.2 y SP1.4. Para la práctica SP1.1, se propone la elaboración de un sencillo diagrama de paquetes del proyecto que muestre de un vistazo las divisiones globales del mismo y, en aquellos casos en los que se participe en un proyecto llevado a cabo por múltiples socios, los paquetes y tareas concretas en los que participa nuestra organización dentro del consorcio, modelo tan habitual en las organizaciones enfocadas al I+D.
La definición del ciclo de vida, correspondiente a la práctica SP1.3, debe venir detallada en el plan de proyecto. Nuestra organización ha desarrollado un marco basado en la elaboración de prototipos que divide el proyecto en fases e iteraciones, al final de cada cual tiene lugar una entrega o hito. Dicho ciclo de vida está basado en el proceso Unificado [8], modelo de desarrollo iterativo fundamentado en la sucesiva mejora del producto.
En lo que concierne a las prácticas SP2.1, SP2.4, SP2.5, SP2.6 y SP2.7, para su implementación se ha optado por incluir apartados relativos a las mismas dentro del documento del Plan del Proyecto. Por ejemplo, para la parte de planificar la formación requerida por el proyecto (SP2.5), se incluye un apartado detallando los paradigmas concretos sobre los que se requiere formación y las fechas límites en los que ésta debe estar asegurada, de forma que el jefe de proyecto adecúe el plan a las necesidades, creando las correspondientes tareas de formación.
La práctica SP2.3, referente a la gestión de los datos en los proyectos, requiere la composición de una política general para toda la organización, si bien luego cada proyecto pueda adherirse en mayor o menor medida siempre que quede convenientemente espècificado en la guía particular de cada proyecto. Un buen método para gestionar de datos es el uso de un entorno wiki que incorpore una página por proyecto, permitiendo el acceso mediante contraseña a los participantes y la edición y versionado de los documentos del proyecto.
Para la SP2.2, Identificación de los Riesgos del Proyecto, se ha optado por generar un documento independiente del plan. Es muy posible que el nivel 2 de CMMI se quede corto en lo relativo a la Gestión de Riesgos para muchos profesionales experimentados en el desarrollo de software, debido a que no exige mitigación de los riesgos, sino simplemente su identificación. Sin embargo, y dado que el nivel 3 de CMMI sí que propone la mitigación, la elaboración de un documento concreto de riesgos puede ser un buen punto de partida para iniciar a la organización en el área de proceso RSKM, que en nuestra opinión resulta de gran utilidad. Cada riesgo dispondrá de su propia ficha en el documento, que aparte de su nombre y descripción, muestra su localización temporal a través de la fecha en la que fue documentado y las fases en las que el riesgo es susceptible de dispararse. Sin embargo, el punto más importante es su criticidad, valor que permite la importante función de priorizar los riesgos y que se establece en función de otros dos parámetros, estimados por juicio de expertos, como son la probabilidad y el impacto, según se muestra en el Cuadro II.
Para la obtención de los compromisos con el proyecto - objetivo SG3- se recomienda el uso de calendarios comunes a toda la organización en la que los participantes anoten sus principales compromisos, ausencias, vacaciones, etc. y de esta forma los jefes de proyecto puedan equilibrar los recursos disponibles en función de los requerimientos de otros jefes de proyecto. De esta manera se satisfarían las prácticas SP3.1 y SP3.2. Para evidenciar la práctica SP3.3, se ha optado por la inclusión dentro del documento del plan de una tabla que debe ser rellenada por todos los participantes en el proyecto en la cual se confirma el acuerdo con el plan y la disponibilidad con las tareas asignadas.
Dentro de cualquier organización, el proceso que vigila la evolución del trabajo y verifica que se realiza en plazos y costes es fundamental. Pero en muchas ocasiones, motivadas por la urgencia en plazos o por incidencias inesperadas esta tarea de Seguimiento y Control se ve relegada a un segundo plano. Quizás es la primera tarea, junto con alguna buena práctica como documentar el código fuente, y tareas relacionadas como Medición y Análisis, que se sacrifica buscando una mayor rapidez para alcanzar un plazo de entrega.
El Seguimiento y Control es una de las 7 áreas de procesos que CMMI incluye para alcanzar el nivel de Madurez 2 en su representación escalonada.
Existen multitud de herramientas que permiten realizar un seguimiento de tareas y esfuerzos en la consecución de proyectos, sin embargo cada una de ellas propone su metodología particular a la hora de aplicar este área de proceso y en la mayoría de los casos presentan soluciones parciales que no cubren la totalidad de las prácticas del área de proceso definido en CMMI [2]. Una de las principales carencias a la hora de implementar esta Área de Proceso es que el Seguimiento y Control debe realizar una vigilancia de todas y cada una de las áreas de proceso que se estén implementando en el ciclo de vida del proyecto. Si solo medimos tareas, grado de avance y horas invertidas estaremos realizando un Seguimiento y Control del área de proceso de Planificación, pero estaremos dejando fuera el resto de áreas de proceso por lo que no cumpliremos con la práctica genérica GP2.8 Monitoriza y Controla los Procesos. Para solucionar este problema deberemos planificar todas las áreas de proceso entendiéndolas como una colección de tareas panificables que deben estar contempladas en el cronograma del proyecto y que por lo tanto son susceptibles de ser controladas.
Sin embargo el concepto de Seguimiento abarca mucho más que una revisión a las horas gastadas y al cronograma. Como hemos podido ver en el Cuadro I, existen varios atributos por cada área de Proceso que pueden cambiar de valor durante el ciclo de vida del proyecto. Por ejemplo la importancia de un Requisito o su Urgencia, o la criticidad de un Riesgo. Es necesario durante la celebración de la reunión de Seguimiento y Control permitir un espacio de tiempo dedicado a revisar el estado de estos atributos y su adecuación o no ante la realidad actual del proyecto. También deberán ser revisadas las No conformidades y su estado por lo que será de obligatoria la presencia en la reunión de Seguimiento de los responsables de dichas No conformidades hasta el momento de su cierre. Además, debe quedar constancia de que estamos realizando este proceso de revisión de todos los atributos susceptibles de variar en cualquier momento del ciclo de vida del proyecto. Para ello es conveniente realizar un acta de convocatoria por parte del Jefe de proyecto, en el que queden claros los temas a tratar y su duración estimada y además un acta de cierre de reunión, donde quede constancia de las decisiones tomadas ante los temas tratados y los responsables de cada nueva tarea.
Visto todo lo anterior la mejor forma, tanto en rapidez de implementación, como en simplicidad de trabajo es adoptar una solución basada en Plantillas de documentos y hojas de cálculo.
El proceso de captura de datos para el Seguimiento y Control debe hacerse de forma periódica y en periodos de tiempo pequeños para obtener mayor detalle en los resultados y tomar las acciones pertinentes de forma rápida y eficaz. Asumiendo esta idea cada persona involucrada en el proyecto con tareas activas rellena a diario su hoja de horas donde se detalla para cada tarea y proyecto las horas invertidas y el grado de avance. Toda esta información es centralizada
por el jefe de proyecto, responsable de todas las tareas de gestión. Una vez asimilados los datos es imprescindible dejar constancia de ellos y presentarlos al resto de miembros del equipo de desarrollo y en conjunto, tomar las decisiones oportunas antes problemas detectados. Este tipo de reuniones es necesario planificarlas y también establecer un periodo máximo de tiempo entre reunión y reunión, dejando constancia de ello en la Guía de Políticas del proyecto. Basándonos en la experiencia un periodo adecuando sería de 1 semana para proyectos cortos (1 año o menos aprox.) y de 2 semanas máximo cuando el proyecto es de larga duración (varios años). Sin embargo es difícil generalizar, ya que la duración de las tareas a controlar es la que marcará la periodicidad y frecuencia de las reuniones de Seguimiento y Control. Finalmente se debe generar un acta de estas reuniones donde quede reflejado quien asume la responsabilidad de las acciones que se derivan de dicha reunión.
El Aseguramiento de la Calidad es quizás, junto a la Medición y Análisis, el área de proceso en el que los profesionales que inician la implantación del nivel 2 de CMMI están menos familiarizados. A pesar de ello el área cuenta únicamente con cuatro prácticas a cumplir y resulta una de las más sencillas conceptualmente de implementar, si bien una de las más tediosas para los desarrolladores poco acostumbrados a la gestión documental. Para el Aseguramiento de Calidad se elaboraron una lista de preguntas, relacionadas con todas las prácticas del nivel 2 de CMMI, que el evaluador debe contestar afirmativamente o negativamente y, en su caso, levantar una no conformidad. El evaluador dispondrá de una lista por cada área de proceso y además, de una lista por cada tipo de producto de trabajo que se deba auditar. Ejemplos de productos de trabajo son: especificación de requisitos, especificaciones de análisis y diseño, código, etc. Con la realización periódica de auditorías de este tipo por parte de un miembro de la organización externo al proyecto y con la apertura y seguimiento de no conformidades por parte del evaluador en colaboración con el jefe de proyecto, se aseguran las prácticas SP1.1, SP1.2 y SP1.3. Para cumplir la práctica SP1.4, simplemente hay que almacenar y gestionar correctamente el versionado de estas listas, tal y como se estableció en la gestión de datos vista en la sección B.
Aunque CMMI presenta esta área de proceso como independiente y autónoma, a la hora de implementar el modelo es muy sencillo verla como parte necesaria e importante del área de proceso de Seguimiento y Control. Sin pretenderlo, al realizar un buen Seguimiento y Control del proyecto hemos tenido obligatoriamente que medir la información y analizarla dándole sentido a través de métricas y umbrales preestablecidos en la Guía de Políticas del Proyecto Por ello la forma más eficaz de abordar la implementación de este área de proceso es "fusionándola.en cierto modo con la de Seguimiento y Control. Sin embargo no quiere decir esto que pierda su identidad, ya que como se puede concluir del manual de CMMI [2] existen prácticas específicas que deben ser satisfechas para cumplir con esta área de proceso.
Al igual que pasaba con el Seguimiento y Control existen herramientas gratuitas y de pago que realizan esta labor de Medición y permiten establecer los análisis necesarios a la organización. Pero, al igual que ocurre con el Seguimiento y Control, esta herramientas ofrecen una versión parcial e incompleta de las prácticas que exige el modelo CMMI por lo que para buscar un cumplimiento óptimo de todas ellas sería necesario adoptar varias de estas herramientas y con ello se disgrega la información y se pierde toda la eficacia que en esencia busca este área de proceso.
Si la organización no cuenta con un método ya establecido y depurado de Medición y Análisis lo más eficaz para empezar a trabajar desde el primer momento son las Hojas de cálculo.
El jefe de Proyecto es el responsable de realizar las mediciones con la periodicidad indicada en la guía de Políticas del proyecto, pero siempre siendo obligatorio que se realicen antes de que tenga lugar la Reunión de Seguimiento y Control, ya que parte de las mediciones serán necesarias para las dos áreas de proceso y además el Jefe de Proyecto debe acudir a la reunión de Seguimiento y Control con todos los datos actualizados, para tomar las decisiones oportunas y compartirlas con el equipo de desarrollo.
Es necesario que la organización realice un proceso interno de estudio de cuáles son los objetivos de medición a distintos niveles (Dirección económica, Dirección Técnica, Jefe de Proyecto), ya que estos niveles demandan distintos tipos de indicadores y todos ellos deben ser satisfechos para que cualquier desviación sea rápidamente detectada a través de la Medición y eficazmente gestionada a través del Análisis.
Un objetivo típico a nivel de Dirección económica suele ser Mejorar la rentabilidad de los proyectos, que se puede calcular de forma simple (sin costes indirectos que compliquen la fórmula y que dependen de la organización) en base a la medición de las horas invertidas por Rol en el proyecto frente a las horas planificadas inicialmente.
Un objetivo muy común para la dirección técnica es el de mejorar la productividad de los recursos, que puede calcularse como el desvío negativo de horas de trabajo frente a las horas estimadas en la planificación de todos los proyectos. El Jefe de proyecto puede tener objetivos más simples y muy relacionados con el desarrollo del proyecto del que es responsable. Por ejemplo el número de No Conformidades sin cerrar en el proyecto. O el número de horas trabajadas (para evaluar la situación de avance frente a las horas gastadas).
En cualquier caso además de las necesidades de información de todos estos niveles derivados de los objetivos de cada uno CMMI impone la obligación de realizar una medición de cada una de las áreas de proceso. Lo más conveniente por facilidad de implementación es medir la desviación de las tareas relativas a cada área de proceso con lo que obtenemos una visión de lo asimiladas que están estas tareas para el resto de la organización. Esto es así ya que una desviación grande a la hora de realizar estas tareas indica que es necesario un esfuerzo formativo en dicha tarea para que su responsable acometa su desarrollo de forma más eficiente la próxima vez. Puede verse un ejemplo de todo esto en la Figura 2.
Además, medir el número de No conformidades abiertas para cada área de proceso nos conduce a un resultado parecido ya que indicará como de bien se está realizando este área de proceso y si es necesario o no mayor formación en la misma para realizarla de forma más correcta. Aplicando esta dos simples mediciones y su análisis posterior estamos cubriendo esta práctica genérica de CMMI: GP2.8 Monitoriza y Controla los Procesos, y además tenemos un indicador fiable de como de bien se han asimilado las tareas propias de Modelo en la organización.
Este área de Proceso cobra mucha importancia en ambientes donde la I+D+i es la filosofía reinante ya que la adaptación a cambios externos y la validación del trabajo realizado frente a los objetivos iniciales son dos situaciones que se suceden con cierta frecuencia. Cambios debidos a que la propia naturalezade la I+D supone no tener muy claros los objetivos específicos iniciales del proyecto sino que lo que se persigue es un objetivo general sin vislumbrar la mejor manera de alcanzarlo. Además es necesaria una validación continua para tener la seguridad de que los esfuerzos de desarrollo no se desvían de ese objetivo general.
Debido al Modelo Iterativo de Desarrollo adoptado que representa muy eficazmente la adaptación a cambios y la continua validación, la mejor opción posible para definir líneas Base es asumir que cada Hito y toda la documentación y productos derivados del trabajo que son entregados en ese Hito definen en sí mismos una línea Base.
Para asegurar la integridad de las líneas base y del contenido de las mismas se deben realizar diferentes tipos de auditorías. Estas auditorías pueden estar hechas por cualquier componente del equipo de desarrollo ya que su único objetivo es validar de forma objetiva los Productos de trabajo de la línea Base (Hito). Para ello se establecen 2 auditorías. La primera de ellas, la de configuración se descompone en dos partes. La auditoría Funcional, que comprueba que los Productos de trabajo cumplen con los Requisitos que los definen, y la auditoría Física, que asegura que los Productos de trabajo cumplen con los documentos de diseño que los definen. La segunda Auditoria es la de Integridad, que sólo comprueba que toda documentación y productos de trabajo planificados a entregar en ese Hito (línea Base) han sido entregados.
Ambas auditorías se deben realizar antes de que llegue la fecha de cierre de la iteración, y por lo tanto antes de que tenga lugar el cierre del hito. Esto es debido, lógicamente, a que debe quedar algo de tiempo preparado por si fuera necesario realizar alguna tarea excepcional fruto de alguna No conformidad detectada durante cualquier de las dos auditorías comentadas anteriormente.
Además del control de los Productos de trabajo y su establecimiento en Líneas Base se debe realizar un control a mayor detalle de todos los Productos de trabajo. Asumiendo que podremos tener dos tipos de productos de trabajo en una organización dedicada al desarrollo del software, que son Documentación y Código Fuente, será necesario realizar un control de versiones de estos documentos y almacenar un historial de cambios realizados sobre ellos y quien es responsable de dichos cambios. En el caso del código fuente existen multitud de herramientas que son plenamente compatibles con esta tarea (Subversion, Servidores CVS). Para el caso de controlar la versión del resto de la documentación podemos realizarlo a través del mantenimiento de la siguiente tabla, donde se contemplan toda la información necesaria para un seguimiento de la evolución del ocumento en el ciclo de vida del proyecto. Puede verse un ejemplo del control de Versiones en el Cuadro IV.
Relacionado con el control de versiones de la documentación o el código es necesario también gestionar las Peticiones de Cambio. Son imprescindibles para mantener un completo hilo documental de lo ocurrido en el proyecto gestionar las peticiones de cambio, y para cada una de ellas cuál es su origen, quién la produce, y que coste puede tener para el progreso planificado del proyecto. Las Peticiones de cambio entran dentro de los indicadores a medir por el Área de proceso de Medición y Análisis y deben ser monitorizadas por el Seguimiento y Control para verificar el estado de dicha petición y sus atributos variables.
La Gestión de Proveedores, Supplier Agreement Management, queda fuera del alcance de este estudio.
Las prácticas genéricas son si cabe más importantes que las metas particulares de cada área, a pesar de ser a menudo menospreciadas por los responsables de implementar y organizar los procesos en las organizaciones. Lejos de ser un agregado al modelo que carece de una utilidad real, lo cierto es que las prácticas genéricas son la argamasa que da consistencia a los procesos relacionando las áreas entre sí y aportando sentido a todo el modelo.
Para el nivel 2 de CMMI se deben cumplir diez prácticas genéricas. Se irán detallando una a una las medidas que se han tomado para implementarlas en el caso de estudio que nos ocupa:
GP2.1: Para el establecimiento de las políticas se ha elaborado una serie de guías que explican los procesos llevados a cabo en la organización así como una serie de plantillas que ayudan a implementar los procesos. Esto ayuda a encauzar más fácilmente el aprendizaje por parte de los nuevos desarrolladores. En el caso de que una determinada política deba ser modificada para un proyecto concreto, debe quedar indicado en la guía de políticas particulares del proyecto. Además de existir una guía de políticas por cada área de procesos, existe una guía general que muestra el proceso a alto nivel y las relaciones entre las diferentes prácticas.
GP2.2: El plan de todas las áreas se ha integrado en un único documento, el Plan del Proyecto. Para que esta opción sea válida deben estar planificadas las tareas relativas a todas las áreas de procesos. Esto quiere decir que se deben instanciar tareas para todas las actividades de gestión del proyecto y deben quedar bien reflejadas en el plan. Por ejemplo se deben contar con tareas relativas a la Medición y Análisis, las Auditorías de Configuración previas a los hitos, la elaboración del propio plan del proyecto, las reuniones de seguimiento, etc.
GP2.3: Se refiere a la disponibilidad de herramientas adecuadas para la realización de las tareas de cada una de las áreas de proceso. Esto se puede garantizar bien mediante las guías y plantillas que soportan la implementación o bien mediante herramientas de software concretas. Por lo general no suele tratarse de una única herramienta conjunta para todas las áreas.
GP2.4: Si en el plan referido anteriormente para exponer la implementación de la práctica GP2.2, además expresamos los recursos humanos o de otro tipo asignados a la realización de cada tarea, se estará evidenciando la provisión de recursos para la implementación de cada área.
GP2.5: En la sección B se habló de planificar las necesidades de formación adecuadas para los proyectos, lo cual queda evidenciado dentro de un apartado concreto en el documento del plan. Este apartado es igualmente útil para planificar la formación necesaria para llevar a cabo las tareas de las distintas áreas de proceso, en el supuesto de que nos encontremos en un proyecto en el que los recursos no están convenientemente formados para realizar las tareas que se les ha asignado.
GP2.6: En lo que se refiere a la gestión documental de las áreas, la herramienta wiki previamente explicada es un buen punto de partida, a bajo coste, para la implementación de esta práctica. Permite almacenar, guardar un histórico y hacer accesibles a los participantes en el proyecto bajo ciertas condiciones de seguridad todos los productos de trabajo generados por cada una de las áreas. Por otro lado, dentro de cada documento, se especifica el histórico de versiones, cambios ocurridos entre las mismas, alcance y ámbito del documento, etc. Todas estas características tienen como fin gestionar adecuadamente la configuración de las áreas de proceso y que estas prácticas, más ampliamente explicadas en la sección F, queden totalmente satisfechas.
GP2.7: La identificación de los participantes y demás afectados por el proyecto es conveniente realizarla al principio del plan del proyecto, en una de sus primeras secciones. Es éste además un buen lugar para que queden fijadas y documentadas las aceptaciones de compromisos y acuerdos, tal y como se especificó en la sección B.
GP2.8: Además de las reuniones de seguimiento correspondientes al área de proceso de Seguimiento y Control (ver sección C), es necesaria una monitorización diaria de la marcha de las tareas de todas las áreas de proceso. No es estrictamente necesario que estas tareas y las posibles desviaciones y no conformidades que surjan deriven en nuevas versiones del plan del proyecto al completo, pero sí es altamente recomendable llevar una cuenta diaria de la imputación de horas individuales por tarea y del grado de avance de las mismas mediante la misma herramienta usada para el diseño del plan y el diagrama de Gantt.
GP2.9: La adherencia del proyecto a los procesos diseñados en la organización se lleva a cabo mediante las auditorías explicadas en la sección D. Es importante volver a recalcar que la evaluación debe ser objetiva, y por lo tanto ningún miembro del proyecto debe evaluar la adherencia de su propio proyecto. En organizaciones pequeñas, en las que es difícil soportar un departamento de calidad, suele llevarse a cabo esta práctica formando a diversos responsables de calidad para que auditen únicamente los proyectos en los que no participan.
GP2.10: Para la revisión del estado con la dirección, no es necesaria la revisión de la más alta dirección, error en el que caen muchas PYMEs en los primeros contactos con CMMI. Es suficiente con que el Director del departamento o el responsable de la subdivisión de la organización que corresponda al proyecto acuda a las reuniones de seguimiento de forma más o menos periódica, y sea informado del estado de todas las áreas según índices y parámetros especificados y medidos previamente, y que estén acordes con las necesidades de información de la organización. La revisión global de las áreas de proceso de la organización -no de los proyectos individuales-, se puede hacer mediante reuniones periódicas a más largo plazo, por ejemplo tres meses. A esta reunión deben acudir, además de la dirección, todos los jefes de proyecto con las conclusiones, anotaciones y medidas relativas a las áreas de proceso de manera que se pueda extraer información para realimentar y mejorar los procesos.
El Modelo CMMI propone una serie de prácticas agrupadas en varias áreas de proceso. A su vez marca dos caminos distintos para alcanzar la madurez en una organización. En nuestro caso hemos adoptado la representación escalonada que impone por nivel una serie de áreas de proceso a cumplir de forma íntegra.
Hemos repasado a través de todos los apartados anteriores las diferentes áreas de proceso y el enfoque particular que se ha adoptado para nuestro caso concreto. Este ejemplo puede servir de guía para organizaciones similares que se enfrente al problema de implementar CMMI en su departamento de I+D+i.
En la actualidad el Modelo de Desarrollo de Software es soportado por Guías y Plantillas Word y Excel, aunque se está trabajando en herramientas web propias que implementen el comportamiento de todas las prácticas que contiene el Modelo. Al ser un Modelo en constante cambio y evolución, las herramientas web también deben ser fáciles de actualizar pudiendo cambiar formularios y tablas de bases de datos de la forma más simple posible.
Sin duda, implementar un Modelo, o una Norma supone un esfuerzo para cualquier organización y por ello es necesario valorar previamente si los beneficios esperables de su implementación y aplicación, compensarán dicho esfuerzo. Es muy probable que muchas prácticas que impone CMMI ya se estén cumpliendo en una organización sin un Modelo estable, por lo que parte del esfuerzo no será necesario aplicarlo a rehacer dichas prácticas sino a introducirlas de formas coherente en un Modelo Global que incluya también el resto de prácticas exigidas por CMMI y que no se cumplen en la actualidad.
El objetivo final de cualquier metodología es la definición formal e institucionalización de procesos y prácticas y un método de mejora continua de estos procesos, de modo que formalizar las actividades cotidianas de una empresa, enriqueciéndolas con experiencias valiosas de su área de negocio y sometiéndolas a un proceso constante de evaluación y mejora suponen un claro beneficio del que se enriquecen las Organizaciones que invierten en ello frente a las que no lo hacen.
[1] Chrissis, M. B., Konrad, M. and Shrum, S., CMMI : Guidelines for Process Integration and Product Improvement. Addison-Wesley Professional, 2003.
[2] CMMI Product Team, CMMI for Development, Version 1.3. Carnegie Mellon University: Software Engineering Institute, 2010.
[3] Díaz, Y., Estudio sobre la correspondencia entre prácticas CMMI y prácticas ágiles y su aplicación en PYMES. Facultad de Informática de la Universidad Politécnica de Madrid, 2009.
[4] Fritzsche, M. and Keil, P., Agile Methods and CMMI: Compatibility or Conflict?. Software Engineering Journal, 1 (1), 9–26, 2007.
[5] Glazer, H., Dalton, J. et al., CMMI or Agile: Why Not Embrace Both!. Carnegie Mellon University: Software Engineering Institute, 2008.
[6] Grupo de trabajo del Comité de la Calidad en los Sistemas y las Tecnologías de la Información y las Comunicaciones de la AEC, Guía para la gestión de proyectos pequeños basados en CMMI. Asociación Española para la Calidad, 2009.
[7] Jackelen, G., CMMI Level 2 Within Six Months? No Way!. CROSSTALK, The Journal of Defense Software Engineering, 2007.
[8] Jacobson, I., Booch, G. and Rumbaugh, J., The Unified Software Development Process. Addison-Wesley Professional, 1999.
[9] Kähkönen, T., Achieving CMMI Level 2 with Enhanced Extreme Programming Approach. Profes Conference, 2004.
[10] Linstone, H. A. and Turoff, M., The Delphi Method: Techniques and Applications. New Jersey Institute of Technology, 2002.
[11] Miluk, G., McHale, J. and Chick, T. A., Guide for SCAMPI Appraisals: Accelerated Improvement Method (AIM). Carnegie Mellon University: Software Engineering Institute, 2010.
[12] Navarro, J. M. y Garzás, J., Experiencia en la implantación de CMMIDEV v1.2 en una micropyme con metodologías ágiles y software libre. Revista Española de Innovación, Calidad e Ingeniería del Software, Vol.6, No. 1, 2010.
[13] Phillips, M. and Shrum, S., Process Improvement for All: What to Expect from CMMI Version 1.3. CROSSTALK, The Journal of Defense Software Engineering, 2010.
[14] Pikkarainen, M. and Mäntyniemi, A. An approach Using CMMI in Agile Software Development Assessments: Experiences from Three Case Studies. Proceedings of the SPICE, 2006.
[15] Pikkarainen, M., Towards a Framework for Improving Software Development Process Mediated with CMMI Goals and Agile Practices. VTT Publications, 2008.
[16] Vriens, C., Certifying for CMM Level 2 and ISO9001 with XP@Scrum.. Agile Development Conference, 2003.