El CMM o CMMI puede ser el estándar de calidad más prominente para el software. CMM/CMMI va más allá del alcance de estándares como ISO para definir los criterios de buenos procesos de software, lo cual hace que el estándar sea atractivo para las organizaciones con departamentos de TI. CMM/CMMI tiene la intención de gobernar los procesos de toda la organización de TI y el ciclo de vida completo de las aplicaciones de software, por lo que debe incluir los procesos utilizados para gobernar el desarrollo del software. La influencia de CMM/CMMI en los procesos que gobiernan el desarrollo de software significa que también influye en la forma en que se gestionan los proyectos de desarrollo de software. El PMBOK (Project Management Body of Knowledge) del PMI es reconocido en todo el mundo como la biblia de las mejores prácticas de gestión de proyectos. Estas se aplican a la gestión de proyectos en cualquier industria, incluida la industria de TI, por lo que las mejores prácticas del PMBOK se verán influenciadas por el estándar CMM/CMMI en cualquier organización que desee aplicar los dos estándares. Hasta donde yo sé, nadie ha intentado crear un estándar CMM o CMMI adaptado al PMBOK y nadie ha personalizado el PMBOK para acomodar CMM o CMMI. Este artículo es mi intento de ofrecer orientación al director de proyecto que tiene la responsabilidad de gestionar un proyecto de software en una organización certificada en un nivel CMM/CMMI de 2 o superior. Afortunadamente, estos dos estándares de ninguna manera son mutuamente excluyentes; sin embargo, se influyen mutuamente, por lo que se debe tener cuidado con los procesos utilizados para el proyecto. La mejor manera de abordar las relaciones es a través de las Áreas Clave de Proceso (KPA), que se alinean bastante bien con las Áreas de Conocimiento descritas en el PMBOK. Este no es un manual para lograr la certificación CMM o CMMI, ni es un manual para implementar las mejores prácticas del PMBOK, simplemente estoy señalando formas de alinear los dos estándares. Dado que el público objetivo de este artículo son principalmente los directores de proyecto, comenzaré proporcionando algunos antecedentes sobre CMM/CMMI.

Antecedentes

CMM significa Modelo de Madurez de la Capacidad. CMMI significa Modelo Integrado de Madurez de la Capacidad y evolucionó a partir de CMM. CMM fue desarrollado para el gobierno federal de los Estados Unidos por el Instituto de Ingeniería de Software (SEI), que está asociado con la Universidad Carnegie Mellon (CMU), con el propósito de medir la calidad de los procesos de un contratista de defensa. CMM evolucionó para convertirse en una hoja de ruta para la mejora continua del software a través de 5 etapas: Inicial, Repetible, Definida, Gestionada y Optimizada, y luego se refinó aún más para abordar problemas con la integración de los procesos CMM en toda la organización. La forma en que el SEI se propuso hacer esto fue identificar diferentes áreas de proceso, definir los procesos críticos para cada área de proceso y definir los criterios que los procesos deben cumplir. Los procesos en cada una de las Áreas Clave de Proceso (KPA) evolucionan a través de cada uno de los niveles de madurez hasta que alcanzan el nivel 5. El modelo no pretende avanzar los procesos de cada practicante al nivel 5. El nivel 5 está destinado a organizaciones como la NASA que tienen la necesidad de ese nivel de madurez de proceso. El nivel 1 es la etapa inicial del modelo y, de hecho, cualquier organización que crea software se define en el nivel 1. El nivel 2 requiere que se establezcan procesos de gestión de proyectos para rastrear el costo, el cronograma y la funcionalidad. Esta es la etapa en la que se encontrará cualquier proyecto que implemente las mejores prácticas del PMBOK y no requiere ninguna racionalización entre el PMBOK y CMM. El nivel 3 requiere que los procesos de software tanto de gestión como de ingeniería se documenten, estandaricen e implementen en toda la organización en todos los proyectos. Este es el nivel que requiere un grado de coordinación entre la gestión de proyectos y CMM. El nivel 2 de CMM requiere procesos en las siguientes áreas: gestión de requisitos, planificación de proyectos de software, seguimiento y supervisión de proyectos de software, gestión de subcontratos de software, aseguramiento de calidad de software y gestión de configuración de software. Todas estas áreas, con la excepción de la gestión de configuración de software, se describen en detalle en el PMBOK. La gestión de configuración de software no está cubierta y normalmente se considera uno de los activos de proceso que el proyecto heredará de la organización que realiza el proyecto. La gestión de subcontratos de software no se aplica a todos los proyectos, por lo que si su proyecto no requiere la adquisición de productos o servicios externos, esta área se puede ignorar. CMM se centra en comprender las necesidades del cliente del proyecto de software, traducir esas necesidades en requisitos y documentar esos requisitos. El objetivo buscado en esta área es una comprensión común de cuáles son esos requisitos y una documentación adecuada de los requisitos para que puedan utilizarse para realizar y rastrear las actividades del proyecto. La planificación del proyecto se centra en el desarrollo de estimaciones realistas para el trabajo que debe realizarse y en obtener los compromisos para realizar el trabajo. La planificación también incluye la identificación de los objetivos, la estimación del esfuerzo, la estimación de los requisitos de recursos, la programación del trabajo y la identificación de los riesgos del plan. El seguimiento y supervisión del proyecto requiere que el director del proyecto establezca suficiente visibilidad sobre el rendimiento del proyecto para detectar y corregir desviaciones del plan. Las correcciones pueden incluir replanificar el trabajo o tomar acciones que permitan al equipo cumplir con el plan existente. La gestión de subcontratos gobierna cómo se seleccionan y gestionan los subcontratistas calificados. El propósito del aseguramiento de calidad es proporcionar visibilidad sobre los procesos utilizados y los productos construidos mediante la revisión de productos y procesos para garantizar el cumplimiento de los estándares establecidos. La gestión de configuración de software establece y mantiene la integridad de los productos y componentes a lo largo del proceso de construcción y durante todo el ciclo de vida del software. Esta integridad se establece controlando los cambios en la configuración del producto mediante una biblioteca de líneas base. Los cambios en las líneas base están controlados por procesos de control de cambios. El nivel 3 se centra en problemas de proyectos y organizacionales que formalizan procesos efectivos de ingeniería y gestión de software en todos los proyectos. El objetivo es mejorar los procesos de la organización. El director del proyecto no puede ser responsable de los estándares organizacionales, pero puede asegurarse de que el proyecto que está gestionando respalde los procesos en el nivel 3. Las áreas que comprenden el nivel 3 son: enfoque en los procesos de la organización (el enfoque se aplica al nivel en general), definición de procesos de la organización, programa de capacitación, gestión de software integrada, ingeniería de productos de software, coordinación entre grupos, revisiones entre pares. El consejo contenido en este artículo se basa en la experiencia personal y las mejores prácticas promovidas por el PMI. El PMI (Project Management Institute) tiene una certificación reconocida en todo el mundo que identifica a los directores de proyectos profesionales: el PMP (Project Management Professional). Para obtener más información sobre el proceso de certificación, visite el sitio web de Three O Project Solutions en: http://threeo.ca/pmpcertifications29.php. Dave es un principal de Three O Project Solutions, los proveedores de AceIt©. Dave también fue el arquitecto clave responsable de la creación del producto. AceIt© ha preparado a directores de proyectos de todo el mundo para aprobar sus exámenes de PMP®. Puede encontrar testimonios de algunos de sus clientes en el sitio web de Three O (http://www.threeo.ca/).