El libro rojo de la mejora de procesos

El libro rojo de la mejora de procesos es una recopilación de los artículos publicados durante el año sobre temas que abarcan modelos y procesos de mejora, técnicas y consejos para la implementación, así como evaluaciones y resultados obtenidos. En conjunto le darán una visión práctica y con un enfoque aplicativo e informativo sobre este tema que es la base de nuestro trabajo. Ponemos en sus manos este documento que constituye un valioso material de consulta y apoyo para su proyecto de mejora. Es nuestro interés que esta información le sea útil y lo ayuden a entender y aplicar mejor estos conceptos, sobre la base de nuestra experiencia, resultados e investigación. Esperamos que así sea y que disfrute su lectura. 
Las formas en las que se puede copiar y distribuir este libro están registradas en Safe Creative y se pueden consultar en el enlace http://www.safecreative.org/work/0912285216543 o en http://www.safecreative.org/work con el código de registro 0912285216543

¡Feliz año y los mejores deseos para el 2010!

Doce uvas en la mejora de procesos

Al final de cada año se evalúan los resultados alcanzados, los logros personales, los sueños realizados. Es una época para replantearse metas y objetivos y buscar nuevos propósitos en el nuevo año. En el caso de la mejora de procesos hay metas y propósitos que podemos trabajar y que resumimos aquí como necesidades de las empresas en sus proyectos de desarrollo.

1. Mejor definición de requerimientos. Los problemas y fallas en los productos por una mala definición de requerimientos representan alrededor del 60% de los defectos presentes en el producto, representan entre 10 y 200 veces más de costo corregirlo en producción y entre un 40% y 80% de re-trabajo. Definir adecuadamente las necesidades y expectativas y validarlo con los clientes o usuarios finales puede ayudar a disminuir esa incidencia.
2. Gestionar la configuración de los componentes del producto. Los problemas asociados con la calidad y re-trabajo asociados con la integración y liberación de productos que no consideran los componentes adecuados o las versiones correctas, provocan desmotivación y pérdida de recursos. Una adecuada identificación y control de versiones de los componentes pueden cambiar los resultados.
3. Mejorar la precisión en la estimación. La mala estimación de los proyectos conllevan re-trabajos, pérdidas económicas y clientes insatisfechos. Atender esta situación puede marcar la diferencia en los proyectos y lograr algo que los clientes esperan, más que entregar rápido desean saber cuándo se le va a entregar y tener certeza de ello.
4. Gestionar los compromisos del proyecto. Una buena estimación es un elemento deseado en el proyecto, pero si no es controlada y monitoreada la ejecución, no podemos garantizar que se cumplan los resultados que se esperan o que se tomen acciones correctivas de manera oportuna.
5. Establecer indicadores efectivos. La recolección de métricas es costoso para un proyecto y cuando estas no son utilizadas o no reflejan el comportamiento como base para la toma de decisiones, entonces es dinero perdido. Es importante establecer indicadores efectivos que permitan mejorar la toma de decisiones y optimizar los recursos destinados a la recolección de información.
6. Garantizar el cumplimiento de políticas y estándares definidos. Cualquier esfuerzo de mejora requiere establecer normas y comportamientos esperados en el proyecto y producto. Si no se establecen mecanismos de control y revisión de que se cumplan, entonces no logramos implantar los cambios que se esperan.
7. Eliminar de forma temprana los defectos en el producto. El costo y esfuerzo asociado a la detección y corrección de un defecto se incrementa de manera exponencial mientras más lejos esté del momento en que es introducido o generado. Una detección temprana de los defectos puede disminuir hasta en 100 veces ese costo y re-trabajo, además de incrementar la calidad del producto y la satisfacción del cliente.
8. Demostrar compromiso con el cambio. El patrocinio es importante para garantizar el cambio, pero es insuficiente. El compromiso hacia el cambio debe demostrarse con el comportamiento, no tiene sentido “haz lo que digo, no lo que hago”.
9. Mejorar la satisfacción del cliente. Un negocio exitoso requiere de clientes satisfechos. Un cambio en la dinámica del negocio que no resulte en un incremento de la satisfacción del cliente, no va a dar los resultados que se esperan. No pierda de vista lo que es importante para el cliente y lleva al negocio a alcanzar ese objetivo de la manera más eficiente posible.
10. Establecer mecanismos efectivos de comunicación. Cuando todo está dicho, aún falta mucho por decir. La comunicación es un sistema dinámico y lo que en un momento fue efectivo, en otro deja de serlo. Es importante mantener una comunicación abierta, incluyente, influyente y efectiva para el proceso de mejora.
11. Lograr el crecimiento del negocio. El objetivo final de un negocio es crecer y obtener ingresos, independiente de los medios para lograr esto si no se alcanza este resultado no puede ser exitoso.
12. Mejorar la satisfacción personal. El motor de la organización es su personal, y su valor se da como resultado de la combinación de: trabajo, actitud y motivación. El equilibrio entre los tres es importante, pero muchas veces el último es el que menos en cuenta se toma. Enfocarse en el beneficio del cambio hacia las personas puede lograr la motivación adicional y acelerar la transformación.

Los deseos no quedan a la buena suerte, fortuna y buenas intenciones. Hay que ponerse a trabajar y enfocarse en los resultados que se esperan. Al final queda la satisfacción y el reconocimiento por los frutos alcanzados.

PCMM: Un modelo de mejora de la capacidad del personal

People Capability Maturity Model es una guía de prácticas que permiten mejorar la capacidad del personal de la organización. Permite atraer, desarrollar, organizar, motivar y retener al personal que permitirá crear productos y proveer los servicios. 
Es un modelo de excelencia para el negocio en general, que permite organizar las actividades de administración de las personas, con prácticas de administración del cambio, para mejorar la capacidad del personal y la efectividad de la organización. Como resultado la Organización será reconocida como un empleador deseado y su personal contará con las competencias necesarias para cubrir los objetivos del negocio. 

Información actualizada sobre los cambios para CMMI v1.3

El Software Engineering Institute (SEI) está trabajando la actualización del modelo CMMI y espera publicar la versión 1.3 del modelo. En artículos anteriores se comentaron algunos cambios que están considerando y algunas actualizaciones sobre el estado del proyecto. En esta ocasión le compartimos información actualizada del CMMI Workshop, realizado el pasado mes de octubre. El proyecto de actualización inició en enero del 2009 y debe extenderse hasta noviembre del 2010. Para finales de mes de julio del 2010 deben estar disponibles los documentos para revisión y aprobación, así como completados los resultados de los pilotos que deben aplicar evaluaciones que integren múltiples constelaciones además de probar el nuevo enfoque para la capacitación en el modelo. Los cambios en la versión 1.3 surgen de solicitudes de cambio recibidas y estarán orientados principalmente a cubrir aspectos relacionados con: alta madurez, eficiencia en las evaluaciones, consistencia entre las constelaciones y simplificación de las prácticas genéricas. Entre los cambios para homologar las constelaciones esta considerar las áreas de proceso del modelo base en tres categorías de proceso: Gestión de Procesos, Gestión de Proyectos y Soporte. Las propias de una constelación deberán ubicarse dentro de la categoría de Ingeniería, Adquisición o Establecimiento y Entrega del Servicio, según corresponda. En este escenario Requirement Management (REQM) debe entonces formar parte de la categoría de Gestión de Proyectos. En cuanto a la estructura del modelo, se eliminaría la repetición de las metas y prácticas genéricas como parte de cada área de proceso y solamente se presentará al inicio de la Parte 2 del modelo. Resumiendo los “elaborations” para cada área de proceso, como se presenta actualmente en el modelo CMMI SVC. La información en el modelo base debe ser común para todas las constelaciones. Como parte de los cambios se deberá revisar que la información en el modelo base es realmente común a todas las constelaciones, en caso contrario no debe ser parte del modelo base. El uso de Integrated Process and Product Development (IPPD) en CMMI DEV, como elemento adicional al modelo, es diferente a la forma en que se maneja para CMMI SVC y CMMI ACQ. Este elemento dejará de existir como adicional y se integrará para CMMI DEV como práctica específica en Organizational Process Definition (OPD) e Integrated Project Management (IPM). Con esto los elementos adicionales ya no formarán parte de la estructura del modelo. El glosario será revisado y ajustado para que los términos sean usados en el mismo sentido por todas las constelaciones. De igual manera las referencias entre áreas de proceso serán revisadas para facilitar el uso del material que es referenciado. En la nueva versión se hará mayor énfasis en la satisfacción del cliente, como parte del material informativo. En el área de proceso de Supplier Agreement Management (SAM) las actuales SP2.2 y SP2.3 se integrarán como parte de la SP2.1 y clarifica la aplicación del área de proceso para la adquisición de componentes comerciales, fuentes internas y propiedad del cliente. Otras áreas de proceso que tendrán adecuaciones menores son PI, CM, DAR, OT, OPD, RSKM, IPM, TS y PPQA. En los niveles altos de madurez los cambios estarán orientados a mejorar la claridad de las prácticas y separar adecuadamente los elementos requeridos, en las metas, y los sugeridos, en las prácticas, para facilitar un entendimiento e interpretación común, tanto para la implementación como para la evaluación. Con respecto a la evaluación SCAMPI se realizarán ajustes para eliminar posibles barreras de terminología en las constelaciones, corregir errores en la documentación, clarificar las cuestiones de alcance en cuanto a las instancias y prerrequisitos para los miembros del equipo de evaluación. En general se debe obtener un método más eficiente. En términos generales los cambios estarán orientados a eliminar inconsistencias entre los elementos de las diferentes constelaciones y depurar la información de las áreas de proceso de alta madurez.

Representación staged vs. continuous

Las áreas de proceso en el modelo CMMI se organizan, muestran y utilizan dos tipos de representaciones: Staged (Escalonada o por etapas) o Continuous (Continua). Una representación no es más que una vista diferente de la información contenida en el modelo y esencialmente proporciona la misma información. La representación escalonada utiliza un conjunto predefinido de áreas de proceso para definir una ruta hacia la mejora en la organización y que se caracteriza por el logro de los diferentes niveles de madurez. De manera que cada nivel de madurez proporciona un conjunto de áreas de proceso que determinan el comportamiento de la organización. Están organizadas por niveles de madurez y agrupadas como se muestra en las filas de la imagen. En la representación continua, por su parte, la organización puede seleccionar un área (o conjunto de áreas) de proceso y mejorar los procesos relacionados con ésta. En este caso se caracteriza por niveles de capacidad de cada área de proceso. Están organizadas por categorias de proceso y agrupadas como se muestra en las columnas de la imagen. La representación escalonada es más sistemática y estructurada. El logro de un nivel de madurez establece las bases para alcanzar el siguiente nivel y permite comparar las organizaciones con resultados demostrados por otras organizaciones en más de 10 años de aplicación. La representación continua ofrece mayor flexibilidad tanto en la selección de las áreas de proceso como el nivel de capacidad al que se quiere llegar en cada una. Aunque esta flexibilidad está limitada por las dependencias que pueden existir en el orden de implementación de las áreas de proceso. Permite mayor visibilidad del avance en cada área de proceso de manera individual. Al final el uso de una representación u otra tiene ciertas ventajas dependiendo de la organización, pero el resultado al que se llega es el mismo con ambas representaciones debido a que contienen las mismas prácticas pero organizadas de manera diferente. De cierta forma son complementarias y puede terminar utilizando un poco de las dos. El uso de una representación u otra, responde más a una necesidad del negocio y cultura en la implantación de procesos. Al final cuando se toma la representación escalonada, el uso de la representación continua permite evaluar a mejor detalle la implementación de las prácticas. En el caso de utilizar la representación continua, el entendimiento del orden de implementación de la representación escalonada facilita la selección de las áreas de proceso más adecuadas.

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Revisar

En el modelo CMMI existen elementos que necesitan ser revisados. Estos elementos van a ser examinados, inspeccionados, repasados, evaluados o analizados; no necesariamente requieren ser actualizados. En muchas ocasiones es para determinar si son correctos, si requieren algún tipo de modificación o si pueden ser aprobados. En muchas ocasiones son elementos que necesitan ser presentados a una contra parte para llegar a un acuerdo o estar sobre el mismo entendido. En muchas ocasiones se refieren a planes, acuerdos, compromisos, reportes o criterios que se deben usar por las partes que intervienen en el desarrollo de los productos y servicios. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Actualizar

En el modelo CMMI existen elementos que deben ser actualizados ("revised"). Esto es que pueden estar sujetos a cambios, mejoras, correcciones, alteraciones, replanteamientos, modificaciones o actualizaciones durante el ciclo de desarrollo del producto o servicio. Es importante identificar estos elementos porque de alguna manera se requiere demostrar que son analizados y evaluados en caso de requerirse algún tipo de actualización y garantizar que son útiles y pueden continuar siendo utilizados como parte del proceso. En términos generales los elementos que debemos mantener actualizados consideran cuestiones relacionadas con la estructura y estado de los componentes de configuración, el proceso definido del proyecto, los planes de mejora, difusión y utilización de los activos del proceso, las métricas, objetivos de calidad y desempeño, lineas base de desempeño y modelos de desempeño, los planes de capacitación, la estrategia de integración, los riesgos del proyecto, los compromisos y planes con el proveedor y la documentación del producto. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Administrar y controlar

En el modelo CMMI existen prácticas relacionadas con la administración y control que requieren determinados elementos para el proceso de creación de los productos y servicios. Los elementos que requieren ser administrados y controlados necesitan un monitoreo y seguimiento periódico; como resultado de esa revisión se identifican desviaciones y en caso de requerirse se toman acciones correctivas y se verifica su cierre. Lo ideal para llevar este control es elaborar una bitácora de issues donde se pueda determinar, al menos, la fecha en que se detectó la desviación, a que elemento se asocia, quién es responsable de su atención, la fecha compromiso y el estado en que se encuentra. Necesitamos detectar desviaciones respecto a los: requerimientos, desempeño del proyecto con relación al plan, cambios a la configuración y desempeño del subproceso con relación al cumplimiento de los objetivos de calidad y desempeño del proyecto. Adicionalmente se debe controlar el desempeño de las acciones de mejora, información de métricas, cambios en interfaces, implementación y utilización de los activos del proceso, participación de los stakeholders y estado de los riesgos identificados. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Establish and maintain

En el modelo CMMI encontramos a nivel de metas y prácticas la frase "establish and maintain", esto se relaciona con la documentación y uso e implica que un elemento debe ser definido, documentado y utilizado. En algunos casos que aparece a nivel de metas se vuelven elementos obligatorios, mientras que en otras situaciones se encuentran a nivel de prácticas y se pueden considerar como sugeridos. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Matrices

En el modelo CMMI se presentan diferentes prácticas que permiten matear elementos relacionados entre si en diferentes áreas de proceso. La matriz de traceabilidad o rastreabilidad en Requirements Management (REQM) permite establecer la traza entre los requerimientos originales a los de bajo nivel en ambos sentidos, de manera que se pueda determinar que todos los requerimientos originales han sido considerados y que los de bajo nivel corresponden a un requerimiento original válido. Puede eventualmente cubrir la relación hacia otras entidades durante el ciclo de desarrollo. Es una herramienta muy útil para evaluar el impacto de los cambios a requerimientos en las actividades y productos del proyecto. La matriz de interfaces requerida por Product Integration (PI) puede estar relacionada con la rastreabilidad horizontal entre componentes, donde se identifican las interfaces entre los componentes. Esta matriz permite administrar adecuadamente las interfaces para garantizar que son completas y compatibles, para facilitar el proceso de integración. La matriz de validación de referencias cruzadas en Validation (VAL) permite comprobar que todos los requerimientos han sido probados y demostrados que pueden ser usados por el usuario. La matriz de habilidades en Organizational Training (OT) permite llevar el registro de la formación que han recibido los individuos en la organización y de las habilidades que han desarrollado. La matriz de stakeholders en Project Planning (PP) permite identificar los diferentes stakeholders del proyecto y las actividades en las que participan de manera que la planeación pueda ser efectiva. Se identifican los individuos afectados y los que tienen experiencia, en que actividades es critica su participación y la forma en que interactúan. La matriz de procesos a estándares en Organizational Process Definition (OPD) permite demostrar el cumplimiento de los procesos con los estándares y modelos que aplican, además que facilita mucho el entendimiento del mapeo de las prácticas para el momento de una evaluación. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Planes

Existen diferentes planes a considerar en el modelo CMMI que pueden estar considerados a nivel de prácticas en los Typical Work Products o en las notas, así tenemos que desarrollar o utilizar:

• Plan de mejora en Organizational Process Focus (OPF) y Organizational Process Definition (OPD)
• Plan de evaluación y de acción en OPF
• Plan del proyecto en Project Planning (PP), Integrated Project Management (IPM) y Project Monitoring and Control (PMC)
• Plan de acciones correctivas en PMC
• Plan de administración de la informacion en PP
• Plan de asignación o contratación en PP
• Plan de participación de los involucrados en PP y en Risk Management (RSKM)
• Plan de administración de riesgos en RSKM
• Plan de mitigación y contingencia de riesgos en RSKM
• Plan de difusión en Organizational Innovation and Deployment (OID) y OPF
• Plan de la Organización y Piloto en OID
• Planes de transición en Supplier Agreement Management (SAM)
• Plan táctico y estratégico en Organizational Training (OT)
• Plan de administración de la configuración
• Plan de aseguramiento de calidad

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Compromiso

Compromisos es una forma de comunicación en ambos sentidos, donde las partes tienen la confianza de que se pueden alcanzar los objetivos dentro de las restricciones de tiempo, costo y desempeño. En el modelo CMMI los compromisos inician en Requirements Management (REQM) en SP1.2 donde se obtiene el compromiso con los requerimientos. Luego en Project Planning (PP) en SP 3.3 se obtiene el compromiso con el plan de proyecto entre los diferentes involucrados y en Project Monitoring and Control (PMC) en SP1.2 se debe monitorear que esos compromisos se están cumpliendo. Estos mismos compromisos se establecen y monitorean como parte de Integrated Project Management (IPM). Adicionalmente existen otras áreas de proceso donde deben establecerse compromisos.

• Compromisos entre los equipos integrados en Organizational Process Definition (OPD)
• Compromisos del proyecto de mejora en Organizational Process Focus (OPF)
• Compromisos relacionados con la formación en Organizational Training (OT)
• Compromisos con proveedores en Supplier Agreement Management (SAM)
• Compromisos sobre la estrategia y acciones para controlar los riesgos en Risk Management (RSKM)

Los compromisos deben quedar documentados de alguna manera. Un compromiso que no esté por escrito es un compromiso que no se cumplirá. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Proceso planeado vs. definido

El modelo CMMI establece a nivel de prácticas genéricas en todas las áreas de proceso la necesidad de planear el proceso (GP 2.2) y establecer el proceso definido (GP 3.1) dependiendo del nivel de implementación que se quiera alcanzar.

Un proceso, para efectos de CMMI, es el conjunto de actividades que se realizan en la Organización para implantar las prácticas descritas en el modelo. Este proceso es administrado cuando genera los productos de salida del proceso de manera planeada y ejecutado de acuerdo con políticas definidas, con recursos adecuados, involucra stakeholders, es monitoreado, controlado y revisado y evaluado para cumplimiento con el proceso. Para cubrir este nivel de proceso es suficiente cumplir con las prácticas genéricas descritas por las metas genéricas 1 y 2, pero en particular en la práctica genérica 2 (GP2.2 Documentar el plan del proceso) se establecen los elementos para realizar las demás prácticas. Para documentar el plan del proceso requiere considerar:

• actividades (proceso)
• estándares y requerimiento producto
• objetivos y dependencias
• recursos, responsables y autoridad, capacitación, productos a controlar, medición, stakeholders, monitoreo y control, evaluación, revisión dirección (En esta parte se cubre la planeación de las prácticas genéricas de la 2.3 a la 2.10)

El proceso administrado es definido cuando es ajustado del conjunto de procesos estándar de la organización de acuerdo con las guías de ajuste, tiene una descripción del proceso actualizada y contribuye a los activos del proceso de la organización. Para llegar a este nivel de proceso se requiere adicionalmente cubrir las prácticas de la meta genérica 3 y en particular la GP3.1 Documentar un proceso definido. De tal manera que el proceso descrito en el plan del proceso (GP2.2) ahora no es particular del proyecto sino que es una especialización de un proceso general descrito en la Organización, por lo que todos los proyectos utilizan elementos comunes contenidos en el proceso estándar.

Establecer un proceso definido esta asociado con Integrated Project Management (IPM). La administración del projecto utilizando el plan y el proceso definido (SP1.5) es afectada por los planes de mejora definidos en la Organización y que se establecen por Organizational Process Focus (OPF). En este sentido OPF SP3.2 debe considerar como parte de la difusión del proceso estandar de la Organización en los proyectos, el apoyo que requieren para realizar los ajustes de acuerdo con las necesidades de cada proyecto y mantener actualizados sus procesos definidos en caso de cambios en el proceso estándar.

Es importante considerar como apoyo para la definición del proceso estándar de la Organización la creación de una matriz de cumplimiento de procesos contra estándares y modelos como parte del cumplimiento de las práctica SP1.1 en Organizational Process Definition (OPD)

M. en C. Carlos J. Pérez Escobar
SEI Authorized CMMI Instructor

Verificación y validación

Las área de proceso de Verification (VER) y Validation (VAL) son muy similares pero con enfoques diferentes. Mientras que VER revisa que los productos y productos de trabajo del proceso cumplen con los requerimientos mientras que VAL revisa que los productos y componentes del producto que recibe el usuario pueden ser usados por este último. En Requirements Development (RD, SP3.3) el análisis de los requerimientos se realiza utilizando técnicas de verificación mientras que RD, SP3.5 obliga a la validación de los requerimientos para garantizar que el producto puede ser utilizado. Por otra parte Process and Product Quality Assurance (PPQA) puede verse como una especie de verificación y debe cuidarse que no se traslapen. PPQA debe revisar que se cumpla el proceso y sus prácticas permiten identificar inconsistencias en el proceso, mientras que VER identifica defectos en los productos y productos de trabajo. En el caso de VER se requiere realizar peer reviews(SG2) independiente de otros tipos de verificaciones que se puedan considerar. PPQA, SP1.2 que indica la evaluación objetiva de productos de trabajo se puede cubrir en cierta forma con peer reviews si en este caso se considera como elemento de revisión el cumplimiento del proceso. Son funciones que se pueden hacer en conjunto pero cuidando ambos enfoques. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Auditorías

Una auditoría en el modelo CMMI es una revisión objetiva de un producto de trabajo o conjunto de productos de trabajo contra un criterio establecido. Únicamente se menciona directamente en Configuration Management (CM, SP 3.2) en la realización de las auditorías a la configuración, en este caso orientadas a revisar que funcionalmente y físicamente la integridad del producto puede ser garantizada. A diferencia de la función de aseguramiento de calidad que se menciona en Process and Product Quality Assurance (PPQA) donde se menciona la ejecución de las auditorías como una forma de evaluación objetiva para aseguramiento de calidad donde lo importante es la objetividad más que la independencia de la función de auditoría. Otras áreas de proceso donde se menciona la ejecución de auditorías es en:

• Organizational Process Focus (OPF) como auditorías de cumplimiento del proceso para monitorear la implementación de los procesos
• Supplier Agreement Management (SAM) como auditorías a la configuración a los productos proporcionados por el proveedor
• Verification (VER) como ejemplo de método para realizar la verificación

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Toma de decisiones

El área de proceso de Decision Analysis and Resolution (DAR) establece la necesidad de utilizar un proceso formal de evaluación típicamente en casos de evaluación de riesgos, cambios a componentes de configuración, decisiones que provocan retrasos en tiempo, decisiones que afectan los objetivos del proyecto o cuando existan compromisos legales. Es importante establecer las situaciones o casos en los que se requiere el uso del proceso para la toma de decisiones en los proyectos y en la Organización. Independientemente de estas situaciones el proceso es referenciado por otras áreas de proceso para en el caso de:

• Organizational Innovation and Deployment (OID) - evaluación de propuesta de mejora e innovación
• Organizational Process Definition (OPD+IPPD, SP2.1) - toma de decisiones asociadas a cuestiones de equipos integrados
• Organizational Training (OT) - determinación de enfoque para capacitación
• OT,SP1.4 - desarrollo de materiales de capacitación
• Product Integration (PI, SP1.1) - selección de secuencia de integración, decisión de desarrollar o comprar ambientes de integración
• Risk Management (RSKM) – evaluar alternativas de selección y mitigación de riesgos identificados
• Supplier Agreement Management (SAM, SP1.2) - selección de proveedores y selección de alternativas de solución,
• Technical Solution (TS, SP1.1) - definición de criterios de selección
• TS, SP2.3 - identificar alternativas para interfaces
• TS, SP2.4 - decisión de comprar o desarrollar la solución

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Interfaces

Una interfaz es la frontera por la cual se comunican dos sistemas. Puede ser un conector utilizado para conectar otro dispositivo o puede ser un acuerdo utilizado para permitir la comunicación entre dos aplicaciones. Frecuentemente existe un componente intermedio entre los sistemas que permite conectar sus interfaces. En el modelo CMMI el área de proceso de Product Integration (PI) se encarga de administrar las interfaces del producto durante el proyecto. En particular la meta específica SG2 se encarga de Asegurar la compatibilidad de interfaz y SG3 permite Confirmar que el producto cumple con las interfaces establecidas, que puede ser ensamblado y que funciona adecuadamente. Las interfaces deben considerar tanto las interfaces de los componentes del producto como las interfaces con los diferentes ambientes que se requieren para verificación, validación, operación y soporte. En el área de proceso de Requeriments Development (RD, SP2.3) se establecen los requerimientos de interfaz, que serán diseñadas como interfaz para la solución a los requerimientos como parte de Technical Solution (TS, SP2.3). Las prácticas de Verification (VER) permite revisar la interfaz de los productos o componentes. Otras área de proceso que consideran el manejo de elementos relacionados con la interfaz son:

• Configuration Management (CM) Descripción de la interfaz
• Integrated Project Management (IPM) Interfaz entre grupos y riesgos de interfaz entre grupos
• Organizational Innovation and Deployment (OID) Estándares de interfaz
• Organizational Process Definition (OPD) Definición de interfaz del proceso
• Risk Management (RSKM) Administración de riesgos de interfaz
• Project Planning (PP) Complejidad de la interfaz para la estimación y compromisos de interfaz
• Requirements Management (REQM) Rastreabilidad de requerimientos de interfaz
• Supplier Agreement Management (SAM) Interfaz con proveedores
• VER y Validation (VAL) Ambientes de verificación y validación

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Requerimientos

Los requerimientos, según el glosario de CMMI, es la condición o capacidad necesaria por un usuario para resolver un problema o alcanzar un objetivo. También se define como la condición o capacidad que se debe cumplir o cubrir por un producto o componente para satisfacer un contrato, estándar, especificación, u otro documento formal. Es la representación documentada de la condición o capacidad para cubrir los puntos anteriores. Deben considerar que todos los proyectos tienen requerimientos, sino no tendrían sentido de existir. El área de proceso de Requirements Management (REQM) administra los requerimientos del proyecto, tanto técnicos como no técnicos (aquí podemos considerar costo y calendario). Las prácticas definidas aquí no están orientadas a desarrollar los requerimientos, más bien garantizan que todos en el proyecto trabajen con requerimientos autorizados. Por su parte Requirements Development (RD) genera los requerimientos del cliente, producto y componentes y Technical Solution (TS) implementa las soluciones a los requerimientos. Para lograr controlar la interrelación entre todos es imprescindible contar con una matriz de rastreabilidad, la que es un elemento crítico para RD y TS y que es mantenida con las prácticas de REQM. Necesitamos la matriz para cubrir con:

• REQM SP 1.1 Acordar que los requerimientos son de una fuente adecuada y que son los acordados
• RD SP3.3 Analizar los requerimientos para determinar si son necesarios y suficientes. Esta práctica contribuye a REQM SP1.1
• REQM SP1.4 Mantener la rastreabilidad bidireccional de los requerimientos y productos de trabajo. Esto contribuye a determinar si satisface los requerimientos a nivel superior RD SP3.3

La rastreabilidad bidireccional, requerida por REQM SP1.4, es la capacidad de rastrear los requerimientos hacia los productos finales y en sentido inverso. La idea es poder determinar que todos los requerimientos han sido cubiertos y que los productos corresponden a un requerimiento válido. Esto se conoce como rastreabilidad vertical y es suficiente para cubrir la rastreabilidad direccional. Existe otra traceabilidad horizontal que se da entre componentes o grupos de trabajo con el propósito de evitar conflictos potenciales entre las interfaces y que es fundamental para cubrir las prácticas de Product Integration (PI), en particular las prácticas específicas relacionadas con SG2. Las interfaces, internas y externas, de los componentes del producto son compatibles. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Referencias entre áreas de proceso

En el modelo como parte del material informativo se realizan referencias entre áreas de proceso (PA) de manera que un área de proceso complementa sus prácticas con información establecida por otras áreas de proceso. Las PA más referenciadas por otras son Project Planning(PP), Project Monitoring Control(PMC) y Measurement and Analysis (MA), le siguen Risk Management (RSKM) y Verification (VER) y finalmente Organizational Process Definition(OPD) y Requirements Development (RD). Las que menos se referencian son Causal Analysis and Resolution(CAR) y Process and Product Quality Assurance (PPQA), seguida por Organizational Process Performance (OPP). Si consideramos únicamente las referencias en las notas introductorias, la lista cambia. La más referenciada es PP, le sigue RD y finalmente PMC. La que menos se referencia es PPQA que no es referenciada por ninguna otra PA. Las PA que más referencias utilizan son Integrated Project Management (IPM), Product Integration (PI), Quantitative Project Management (QPM) y Supplier Agreement Management (SAM), le siguen Organizational Innovation and Deployment (OID), RD y Technical Solution (TS) y luego MA, PP. Las que menos referencias hacen son Configuration Management (CM) y PPQA. Considerando únicamente las referencias en las notas introductorias, la que más referencias utiliza es PI, le siguen MA, OID, QPM y RD y luego REQM. Las que menos referencias hacen son OPD y Organizational Process Focus (OPF). ¿PPQA es un área muy independiente?¿PP requiere de todos y utiliza a todos? Necesitamos revisar las notas a nivel de prácticas para tener una visión completa de las interrelaciones entre áreas, no sólo podemos quedarnos con las referencias en notas introductorias. En el caso de las practicas genéricas se hace referencia principalmente a PP, PMC e IPM. Las que menos se referencian son las PA de la categoría de ingeniería, además de RSKM, Decision Analysis and Resolution (DAR) y SAM. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Números en CMMI

Capability Maturity Model Integration (CMMI) es un modelo de madurez para la mejora de procesos en el desarrollo de productos y servicios. Consiste de mejores prácticas orientadas a actividades de desarrollo y mantenimiento de software que cubren el ciclo de vida desde la concepción, liberación hasta el mantenimiento. De esta manera inicia el documento que contiene la información del modelo donde en 560 páginas, se revisan 22 áreas de proceso, conteniendo 50 metas específicas con 173 prácticas específicas y 5 metas genéricas con 17 prácticas genéricas, que asociadas a las 22 áreas de procesos, se convierten en 110 metas genéricas con 374 prácticas genéricas a considerar. En resumen la aplicación del modelo requiere cubrir 160 metas a través de la implantación de 547 prácticas que suman 707. Considerando la persistencia del 7 en todos estos números y considerando que su significado esta asociado al éxito, la verdad y la justicia no es de extrañar por qué las empresas que lo adoptan empiezan a obtener el éxito en el logro de sus objetivos, visualizando beneficios verdaderos. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Nuevo proceso, viejos problemas: El proceso para la toma de decisiones

La toma de decisiones es una actividad que tiene efectos en todas las acciones que realizamos diariamente. Algunas de esas decisiones tienen mayores implicaciones que otras y por tanto requieren un proceso formal para que la solución sea la más efectiva posible. 


No es lo mismo tomar la decisión sobre qué platillo vamos a escoger de un menú durante una comida a seleccionar un coche o una casa que ocuparemos por varios años. En el peor de los casos si no nos gusta el platillo lo desechamos, pero de la casa o el coche no sería tan sencillo deshacernos. 


En los proyectos que realizamos muchas veces las decisiones que tomamos afectan la capacidad de alcanzar los objetivos del proyecto o están relacionados con riesgos que se pudieran presentar, por lo que un adecuado proceso para seleccionar y documentar la mejor decisión es crucial en estos casos. 


En los proyectos de ingeniería son diversas las situaciones en la cuales se requiere evaluar varias alternativas considerando diferentes criterios de decisión. Pero, en qué situaciones realmente se requiere un proceso formal para toma de decisiones, qué métodos son más efectivos en cada caso, cómo identificar las diferentes alternativas de solución, qué criterios utilizar para evaluar esas alternativas y cómo documentar adecuadamente los resultados obtenidos. Precisamente a estas interrogantes da respuesta el modelo CMMI® cuando establece el área de procesos “Decision analysis and resolution (DAR)”. 


El propósito de DAR es analizar posibles decisiones utilizando un proceso formal para seleccionar entre las alternativas identificadas utilizando los criterios establecidos. Finalmente se busca una nueva solución con un nuevo proceso para un problema existente desde siempre. ¿Será también una cuestión de decisión si realmente debiéramos evaluar cuando se debe o no aplicar el proceso de toma de decisiones? 


Es importante identificar los elementos del proceso de toma decisiones y las situaciones en las cuales se beneficiaría al utilizarlo. Como resultado podríamos reducir la subjetividad en las decisiones que se tomen e incrementar la probabilidad de seleccionar la solución que mejor pueda cumplir con sus necesidades. 


Existen diversas implicaciones en el proceso de decisión, desde el momento que se identifica la situación sobre la cual se debe tomar una decisión hasta la implementación de la solución seleccionada. Este proceso puede implicar menor o mayor tiempo invertido y valor obtenido, dependiendo del enfoque que se utilice. Así una decisión que se toma como orden o directiva es la forma más rápida mientras que la considera llegar a un consenso de los participantes es la que más tiempo consume aunque por otra parte es mucho más aceptada. 


Considerando la parte del proceso que considera la identificación y decisión de la mejor solución es importante tomar en cuenta los elementos establecidos en el área de proceso DAR del modelo CMMI®. Estos elementos deben ser analizados e implantados adecuadamente para contribuir a establecer e institucionalizar la práctica. Así como revisar los puntos específicos en los cuales se requiere el uso del proceso en relación a las demás áreas de proceso, así como los elementos generales para definir el procedimiento para la toma de decisiones. 


Existen diversas técnicas que pueden contribuir a tomar la mejor decisión, dependiendo de las necesidades que se tengan. En términos generales podemos considerar técnicas de apoyo para la creación o realización de lluvias de ideas, comparación de pares, árboles de decisión, matrices de decisión y estudios de costo/beneficio. 


Estas técnicas tienen características diferentes para su aplicación. El correcto uso de las mismas nos puede ayudar a mejorar las decisiones que se tomen. En la práctica es suficiente con conocer y aplicar dos o tres de esas técnicas para obtener los resultados que esperamos. Una página que considero muy útil por la información que maneja es MindTools en particular en la pestaña de Decision Making. 


La aplicación en la vida real del proceso es ampliamente requerida pero pocas veces utilizada a conciencia. Una adecuada implantación contribuye a que finalmente sus decisiones sean más efectivas y no se tome una mala decisión. Es su decisión utilizar o no estas prácticas. 


M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Six Sigma y CMMI

En un artículo de la revista CrossTalk de febrero del 2007 "Connecting Software Industry Standars and Best Practices: Lean Six Sigma and CMMI" de Gack, Gary A. y Karl D. Williams se habla sobre los beneficios de combinar las herramientas y métodos de Six Sigma con las prácticas identificadas en las áreas de proceso de CMMI. El autor parte de un comentario que escuchó en una conferencia donde se presentaban los principios de Demming y Juran. A una pregunta sobre que enfoque debían utilizar, Demming respondió "Selecciona cualquiera... sólo haz algo". Cada modelo finalmente tiene un objetivo y cubre cierto propósito, lo importante es identificar el que nos acomoda para las necesidades que se tienen y aplicarlo en la organización. Normalmente las organizaciones que inician la utilización del modelo CMMI en un proyecto de mejora no consideran la aplicación de las técnicas de Six Sigma. Pero cuando se toman en cuenta permiten robustecer la definición del área de proceso de Measurement and Analysis (MA) en CMMI y facilitar la aplicación de las áreas de procesos de alta madurez. De acuerdo con los resultados presentados en tres empresas en las que se realizó una evaluación inicial SCAMPI C de nivel 2, se evidenció el impacto de la aplicación de Six Sigma en conjunto con CMMI.

• Todas las áreas de proceso aplicadas consideran mediciones, análisis de causa y seguimiento a la mejora continua.
• Los resultados de las organizaciones superan los requerimientos que utiliza el SEI para efectos de comparación.
• Todos los niveles de gestión y operación utilizan las métricas en sus actividades diarias.

Six Sigma requiere la aplicación de:

• DMAIC (Disegn, Measure, Analyze, Improve, Control) Es una herramienta de Six Sigma para la mejora de procesos y productos. Establece una secuencia de pasos para la implantación robusta de Measurement and Analysis en CMMI
• DfLSS (Design for Lean Six Sigma) frecuentemente descrito por DMAIV (Disegn, Measure, Analyze; Design-Build, Verify) Es una herramienta de Six Sigma para la creación de nuevos procesos y productos. Está más relacionada con las áreas de proceso de ingeniería en CMMI (Requirements Development, Requirements Management, Technical Solution, Product Integration, Verification, Validation)
• Estrategia para difusión para la implantación de las herramientas y roles (Champions, Black Belts, Green Belts) con capacitación y certificación específica que puedan apoyar la estrategia.

Como aprendizaje de estos resultados se obtiene que:

• CMMI le da un valor adicional al uso de las técnicas de Six Sigma
• Las organizaciones que usan Six Sigma en conjunto con CMMI le dan un beneficio adicional a las áreas de proceso de niveles inferiores.
• La aplicación de Six Sigma reduce el tiempo para llegar a niveles altos de madurez de CMMI. (Uno de los casos que se muestra alcanzó el nivel 5 seis meses despues de evaluarse a nivel 3)
• Six Sigma mejora la calidad y los tiempos de desarrollo, reduce los defectos e incrementa la satisfacción del cliente lo que típicamente son motivadores para los procesos en CMMI.
• El mejor enfoque para aplicar CMMI y Six Sigma es una combinación de los dos, finalmente CMMI es un modelo para identificar qué prácticas necesitamos considerar y Six Sigma es un método que establece cómo aplicar ciertas prácticas de un modo específico.

En el sitio del SEI podemos encontrar información útil para la adopción de Six Sigma como complemento a CMMI. “Using Six Sigma to Accelerate the Adoption of CMMI for Optimal Results” y otras referencias interesantes pueden ser consultadas. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Administración de la configuración

Administración de la configuración (Configuration management CM) es el conjunto de actividades relacionadas con la administración de la evolución de los productos durante todo su ciclo de vida. Para ello es necesario identificar, organizar y controlar las modificaciones al producto con el objetivo de maximizar la productividad a la vez que se minimizan los errores. Es el control que se tiene sobre cada uno de los componentes de configuración de un producto con el fin de que todos los cambios que se realicen a estos componentes, una vez que han sido aprobados, se hagan de forma controlada y que en todo momento se conozca cuál es la versión vigente de cada uno. Facilita la identificación e integración de los componentes de configuración que conforman los entregables del proyecto. Es el proceso de identificar la configuración del producto para controlar sistemáticamente los cambios a la misma y mantener su integridad a lo largo de todo el ciclo de vida del proyecto. Algunos problemas comunes que conllevan a la adopción de CM son:

• No se encuentra la última versión del código fuente
• Errores corregidos en versiones previas aparecen nuevamente
• No se conoce qué módulos comprende el sistema entregado al cliente
• La integración del sistema toma demasiado tiempo
• Los programadores están trabajando en una versión incorrecta del código
• Versiones incorrectas del código son probadas
• No existe seguimiento de los requerimientos, documentos y códigos

Las actividades que se requieren para implementar un proceso de CM incluyen: Identificación de la configuración: Identificar de forma unívoca la estructura del software y los elementos que lo forman y ponerlo a disposición del personal que lo requiera. El objetivo es tener la capacidad de identificar los componentes del software a lo largo de su ciclo de vida y facilitar su seguimiento. Actividades

1. Seleccionar los elementos que estarán bajo control de configuración
2. Establecer la estructura jerárquica del producto
3. Crear e identificar el esquema que refleja la estructura del producto
4. Identificar unívocamente cada uno de los componentes del producto
5. Definir las relaciones e interfaces entre los productos

Nota: Es importante almacenar y registrar toda la información del ambiente y las herramientas de apoyo utilizadas durante el ciclo de vida del software para asegurar que el mismo puede ser reproducido, en cualquier momento. Control del cambio a la configuración: Controlar los cambios y la liberación de los productos durante el ciclo de vida para establecer un mecanismo que asegure la creación de un producto de calidad. Actividades

1. Definir el proceso de cambio
2. Establecer las políticas y procedimientos de control de cambios
3. Mantenimiento de las líneas base
4. Incorporar los cambios
5. Desarrollar la forma de reportes de cambio
6. Controlar la liberación del producto

Reporte del estado de la configuración: Registrar y reportar los cambios a los componentes de configuración. Con ello se puede mantener un registro del estado de todos los elementos en una línea base, para posibilitar el seguimiento de todos los cambios a las líneas base durante el ciclo de vida. Actividades

1. Determinar el tipo de reporte requerido
2. Dar seguimiento al estado de los componentes de configuración
3. Dar seguimiento al estado de los cambios al sistema
4. Generar reportes de estado
5. Registrar y reportar las actividades de CM

Auditoría a la configuración: Verificar que el producto integrado satisface los requerimientos, estándares o acuerdos contractuales y que los componentes que se integran corresponden con las versiones vigentes. Verificar que todos los componentes han sido producidos, descritos e identificados correctamente y que todas las solicitudes de cambio han sido procesadas. Actividades

1. Definir el esquema y procedimientos de auditoría
2. Desarrollar auditorías en las líneas base establecidas
3. Generar los reportes de auditoría

M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

IDEAL

El modelo IDEAL fue inicialmente creado como un modelo de ciclo de vida para la mejora de procesos basado en el CMM pero su aplicación es mucho más amplia. Fue dado a conocer por el SEI en 1996 como un manual con el código CMU/SEI-96-HB-001. 

Está compuesto de cinco fases que permiten administrar el programa de mejora y establecer las bases para la estrategia de mejora a largo plazo. 

CMMI en Español

El Instituto Nacional de Tecnologías de la Comunicación (INTECO) presentó el pasado 5 de junio la versión traducida al español del CMMI DEV v1.2. La presentación tuvo lugar en la ciudad de León, España en una jornada especial en la que participó, entre otros, Mike Phillips líder del proyecto CMMI en el SEI. En el esfuerzo de traducción colaboraron además de INTECO, la Universidad Politécnica de Madrid (UPM), Accenture y Everis. La guía ha sido editada por la editorial Pearson Educación. Actualmente el SEI tiene autorizadas las traducciones al francés, japonés y mandarín. Para este proceso el SEI preferentemente trabaja con entidades de gobierno u organizaciones sin fines de lucro que puedan cubrir los gastos de traducción y revisión, además de cubrir el pago de derechos por uso del material del SEI. Se tiene previsto que para el mes de octubre se haga un lanzamiento similar en México. En estos momentos el documento no está disponible en el SEI. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

Tipos y medios de capacitación

La formación profesional es fundamental para garantizar el desempeño efectivo de los roles y responsabilidades que tienen los individuos en la organización. 


En el modelo CMMI existe el área de proceso Organizational Training (OT) que tiene como propósito desarrollar las habilidades y conocimientos de la gente para que puedan desempeñar sus roles de manera efectiva. Adicionalmente a las prácticas descritas en esta área de proceso es importante, para garantizar la institucionalización de las prácticas descritas en el modelo, la consideración de la práctica genérica 2.5 contenida en todas las áreas de proceso que implica la formación del persona que ejecuta o apoya al proceso, según se requiera.

CMMI ACQ

En el mes de noviembre del 2007 el SEI (Software Engineering Institute) publicó el modelo CMMI ACQ (CMMI for Acquisition) como resultado del trabajo conjunto entre el SEI, GM IS&S (General Motors' Information Systems and Services), HP, Capgemini y el Gobierno de EEUU. Se espera que el modelo revolucione la forma en que los gobiernos y organizaciones en el mundo adquieren o subcontratan los sistemas y servicios de software. Los principales objetivos del modelo son:

• Evitar o eliminar barreras y problemas en el proceso de adquisición mediante mejoras en la eficiencia operativa
• Iniciar y administrar un proceso para la adquisición de productos y servicios que incluye la solicitud, fuentes de suministro, desarrollo y reconocimiento de los acuerdos con proveedores y administración de la capacidad de los proveedores
• Utilizar un lenguaje común tanto para proveedores como compradores para generar soluciones de calidad más rápido, con un menor costo y con la tecnología más apropiada

CMMI ACQ proporciona guías para la aplicación de las mejores prácticas de CMMI por el contratante o comprador para el inicio y administración de la adquisición de productos y servicios que cumplan con las necesidades del cliente. Aunque pueden considerar artefactos por parte del proveedor el enfoque del modelo está hacia la parte del comprador El modelo contiene 22 áreas de proceso, de las cuales 16 corresponden al CMMI Model Foundation (CMF) en las categorías de administración de procesos, administración de proyectos y soporte. Las 6 restantes integran la categoría de adquisición:

• Acquisition Management (AM) (Nivel 2)
• Acquisition Requirements Development (ARD) (Nivel 2)
• Acquisition Technical Management (ATM) (Nivel 3)
• Acquisition Validation (AVAL) (Nivel 3)
• Acquisition Verification (AVER) (Nivel 3)
• Solicitation and Supplier Agreement Development (SSAD) (Nivel 2)

El modelo cubre la necesidad en la industria de contar con un estándar para adquisiciones tomando las mejores prácticas consideradas en CMMI for Development que actualmente es el estándar de facto para las organizaciones de desarrollo de software a nivel mundial. El modelo beneficia otros sectores fuera del terreno automotriz como es aeroespaciales, bancos, telecomunicaciones y gobierno que pueden integrar en sus procesos de mejora las prácticas del modelo. El modelo está disponible en la página www.sei.cmu.edu como reporte técnico y adicionalmente se imparte el curso CMMI for Acquisition Supplement for Introduction to CMMI Version 1.2. Las organizaciones interesadas pueden realizar evaluaciones SCAMPI A guiadas por un SCAMPI Lead Appraiser o SCAMPI B y C lidereadas por un SCAMPI Team Leader para evaluar el estado de implantación. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor

ATLAS 17

Pat O'Toole es un reconocido Lead Appraiser e Instructor del curso Intro CMMI que ha creado un foro de discusión de temas relacionados con el modelo CMMI y cuestiones de implementación para la mejora de procesos. 


ATLAS (Ask The Lead AppraiserS) en su publicación número 17 presenta un cuestionamiento relacionado con la reducción del número de Prácticas Genéricas (GP) relacionadas con la Meta Genérica 2 (GG2)- Institucionaliza un Proceso Administrado, esto con el propósito de que los SCAMPI (Standard CMMI Appraisal Method for Process Improvement) sean más efectivos en tiempo y costo. La retroalimentación se obtiene tanto de individuos autorizados (SCAMPI Lead Appraisers e Instructores) como de individuos no autorizados relacionados con la mejora de procesos. 


Las practicas genéricas se pueden resumir como:

• GP2.1 Establecer políticas para ejecutar el proceso
• GP2.2 Establecer planes para el proceso
• GP2.3 Proporcionar recursos adecuados para ejecutar el proceso
• GP2.4 Asignar responsabilidades y autoridad para ejecutar el proceso
• GP2.5 Formar al personal que ejecuta o apoya el proceso
• GP2.6 Ubicar los productos de trabajo identificados bajo control
• GP2.7 Identificar los involucrados en el proceso
• GP2.8 Monitorear y controlar el proceso
• GP2.9 Evaluar objetivamente el cumplimiento del proceso
• GP2.10 Revisar las actividades con la alta gerencia

En el primer cuestionamiento se propone una reducción mayor de las GP, dejando únicamente la GP2.1, 2.2 y 2.8. En este caso los individuos autorizados están en contra en un 45% mientras que los individuos no autorizados están de acuerdo en un 33%. La posición dividida puede ser porque para los individuos autorizados esto tiene un beneficio para efectos de la evaluación y no para la implantación, mientras que para los no autorizados son elementos que de cierta manera ya están contenidos en las demás prácticas. 


En el segundo cuestionamiento se propone una reducción menor de las GP eliminando la GP 2.3, 2.4, 2.7 y 2.10. En este caso la posición es más parecida, los individuos autorizados están un 29% a favor y un 31% a favor de los individuos no autorizados. En este resultado hay mayor coincidencia porque posiblemente esas prácticas están contenidas en las demás prácticas y hay mayor consenso en este sentido, aunque hay cuestionamientos de no quitar la práctica 2.10. 


En el último caso la pregunta es dejar las prácticas como están. Aquí los individuos autorizados están a favor en un 26% mientras que los no autorizados están en contra en un 36%. Nuevamente se coincide con la tendencia que se refleja para los implementadores de procesos de reducir el número de prácticas genéricas que deben considerar. 


Otras sugerencias que se mencionan están relacionadas con: mejorar las herramientas de apoyo que se utilizan en la ejecución del SCAMPI, permitir la caracterización de prácticas como "no aplicables" o eliminar los artefactos indirectos, entre otras propuestas. 


Mayor información sobre esta discusión se puede encontrar en la página de ATLAS, así como otras discusiones anteriores. M. en C. Carlos J. Pérez Escobar SEI Authorized CMMI Instructor