CAPÍTULO I: ENFOQUE GLOBAL A CMMI

1

CAPÍTULO I: ENFOQUE GLOBAL A CMMI

1.1 CONCEPTOS

1.1.1 SISTEMA DE CALIDAD

El sistema de calidad se debe adecuar a los objetivos de la calidad de la empresa. La dirección de la empresa es la responsable de fijar la política de calidad y las decisiones relativas a iniciar, desarrollar, implantar y actualizar el sistema de calidad.

Basados en los principios de la calidad total (TQM) popularizados por autores como Crosby, Deming y Juran, estos modelos proponen un conjunto de prácticas que las organizaciones pueden adoptar para implantar procesos productivos más efectivos.

Son llamados modelos de madurez porque proponen adoptar dichas prácticas en forma gradual: primero deben ponerse en práctica áreas de proceso pertenecientes a un nivel determinado, para luego, sobre esta base, introducir las correspondientes al nivel siguiente.

Los modelos de calidad se dividen en modelos de referencia, que indican cuáles son las prácticas pero no cómo se consiguen, y los modelos de implantación que se enfocan en cómo se consiguen aquellas prácticas. Aunque existe gran variedad de ambos tipos de modelos se destacan por su eficacia probada los modelos de referencia. I

1.1.2. MODELOS PREVIOS

Uno de los propósitos de CMMI fue unir en forma coherente varios modelos que eran utilizados en conjunto dentro de una organización y que generaban repetición de contenido provocando que el proceso de mejora

2

llevado a cabo en la organización fuera más difícil y costoso. Estos modelos integrados por CMMI, que serán descritos a continuación como se puede observar en LA figura No 3, eran modelos enfocados en el desarrollo de sistemas de software (SW-CMM), en la ingeniería de sistemas (SECM) y en el desarrollo de productos integrados (IPD-CMM).

CMM Para Software v1.1 CMM Para Software v2.0 SECAM v1.0 SECM v1.0 System Engineering CMM v1.1 Integrated Product Development CMM v1.1 CMMI Para Desarrollo v1.01 CMMI Para Desarrollo v1.1 CMMI Para Desarrollo v1.2 CMMI Para Adquisición Para v1.2 CMMI Para Servicio Para v1.2 1993 1995 1996 1997 1998 2000 2002 2006 2007 Página 1

Modelos Previos a CMMI

Autor: Juan Carlos Chimborazo

Fig. 3 Modelos Previos a CMMI

1.1.3. CMM PARA SOFTWARE

Tras su creación en 1984 el SEI comenzó la investigación para desarrollar un marco de mejora y evaluación de la calidad de las empresas desarrolladoras de software que prestaban servicios al Departamento de Defensa de los Estados Unidos. El resultado de la investigación se denominó " Modelo de Madurez de capacidad para el Software " (SW-CMM), cuya versión 1.0 se publicó en Agosto de 1991.

3

Posteriormente, como resultado de la retroalimentación generada por parte de la comunidad de software, se desarrollaron las versiones 1.1 publicada en 1993 y 2.0 la cual agregaba y modificaba una serie de elementos al vigente CMM v1.1, principalmente que tienen relación con alcanzar la institucionalización en la organización. Esta versión se completó en 1997 y se denominó “Software CMM, Versión 2.0 (Draft C)”, pero nunca fue publicada. SW-CMM es un modelo de madurez de capacidades desarrollado para los procesos relativos a la producción y mantenimiento de sistemas software. De esta forma el SW-CMM puede emplearse con dos finalidades:

 Guía para mejorar procesos relativos a la producción y mantenimiento del software.

 Criterio para determinar el nivel de madurez de una organización que produce y mantiene software.

Las organizaciones que usan SW-CMMI transitan por cinco niveles de madurez de capacidades donde se pueden encontrar al evaluar sus procesos. Estos niveles son: Inicial, donde no hay procesos; Repetible, en el cual los procesos relacionados a la gestión de proyectos y gestión de requerimientos son manejados de alguna manera para su repetición en proyectos distintos; definido, cuando los procesos están totalmente definidos y disponibles para todos los miembros de una organización; gestionado, donde se pueden medir los procesos cuantitativamente; y optimizado, en donde los procesos son mejorados continuamente según una serie de métricas definidas.

1.1.4. Modelo de Capacidad (SECM)

SECM corresponde al esfuerzo conjunto de INCOSE (Consejo Internacional sobre Ingeniería de sistemas) y EPIC (Grupo de colaboración de mejora de procesos en la empresa) para integrar sus dos

4

modelos (SECAM y SE-CMM, respectivamente) en el denominado Sistema que Diseña a Modelo de Capacidad (SECM) o también llamado EIA/IS 731, que fue liberado en su versión 1.0 en 1998.

SECM (Modelo de Capacidades de Ingeniería de Sistemas) fue elaborado con el objetivo de proveer una guía para efectuar, manejar y mejorar la ingeniería de sistemas. El modelo describe un conjunto mínimo de actividades críticas para realizar ingeniería de sistemas o manejar tareas, tal como derivar y asignar requerimientos o manejar riesgos. El modelo también captura las actividades genéricas relacionadas a manejar o mejorar como una tarea específica es realizada. Estas actividades son especificadas en cinco niveles secuenciales e incrementales (niveles de capacidad), los cuales proveen al usuario un método estructurado para lograr una mejora continua.

Los niveles fueron obtenidos sobre prácticas probadas experimentalmente y ellos son:

 Habilidad para desarrollar ingeniería de sistemas,

 Obteniendo control local,

 Compartiendo conocimiento a través de la organización,

 Medida cuantitativa de lo que se hace, y

 Mejora usando las medidas cuantitativas y objetivas organizacionales.

El primer predecesor de SECM descrito es SECAM (Modelo de Evaluación de Capacidades de Ingeniería de Sistemas). Fue elaborado por CAWG (Grupo de trabajo de evaluación de capacidades en Ingeniería de sistemas) y aprobado por INCOSE para ser liberado en 1996.

SECAM junto son su método de evaluación fue utilizado para evaluar la capacidad de los procesos relacionados a la ingeniería de sistemas en

5

una organización y trataba de determinar áreas de potencial mejora. El segundo predecesor es SE-CMM v1.1 (Modelo de Madurez de Capacidad para Sistema de Ingeniería) que fue creado por el SEI en el año 1995 y describe los elementos esenciales que deben existir para que los procesos de ingeniería de sistemas de una organización aseguren una buena ingeniería de sistemas. Junto con su método de evaluación tienen el objetivo de mejorar y evaluar los procesos asociados a la ingeniería de sistemas.

1.1.5. Modelo de madurez (IPD CMM)

IPD CMM (Modelo de madurez de capacidad para el desarrollo de productos integrados) fue elaborado y liberado en 1997 por el SEI. El modelo describe los elementos esenciales para el desarrollo de un producto integrado; una guía para el proceso de mejora del desarrollo del producto integrado; y una metodología de evaluación del proceso de desarrollo del producto integrado que es hecho por una organización.

IPD CMM puede ser aplicado a cualquier tipo, disciplina y abarca casi todo el ciclo de vida de un producto desde la selección de oportunidades de negocio hasta el retiro del producto del mercado, marginando la etapa de desarrollo del plan estratégico. Fue diseñado con la idea de eliminar la duplicación de actividades del SW-CMM y el SE-CMM, los cuales al ser aplicados en una organización se traslapaban entre sí, y consta de 5 niveles de madurez de capacidad semejantes en su descripción a los niveles de SW-CMM y SE-CMM. II

II Roger Bate, Dorothy Kuhn, Curt Wells, James Armitage, Gloria Clark, Kerinia Cusick, Suzanne Garcia, Mark Hanna, Robert Jones, Peter Malpass, Ilene Minnich, Hal Pierson, Tim Powell, Al Reichner: “A Systems Engineering Capability Maturity Model, Version 1.1”, 1995.

6

1.1.6. MODELO DE MADUREZ Y CAPACIDAD (CMMI)

El CMM - CMMI es un modelo de calidad del software que clasifica las empresas en niveles de madurez. Estos niveles sirven para conocer la madurez de los procesos que se realizan para producir software.

CMMI enseña el camino para alcanzar un nivel de madurez de la organización o un nivel de capacidad de un área de proceso dice que hay que hacer no dice como hay que hacerlos.

Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos eficaces.

El CMMI (Capability Maturity Model Integration), es un marco de referencia que las organizaciones pueden emplear para mejorar sus procesos de desarrollo, adquisición, y mantenimiento de productos y servicios. Nacido en el Software Engineering Institute perteneciente a la Carnegie Mellon University, CMMI es la nueva generación de una línea de modelos de madurez que se inició a principios de los noventa con el famoso CMM-SW (Capability Maturity Model for Software Engineering). Las mejores prácticas CMMI se publican en los documentos llamados modelos. En la actualidad hay dos áreas de interés cubiertas por los modelos de CMMI: Desarrollo y Adquisición.

La versión actual de CMMI es la versión 1.2. Hay tres constelaciones de la versión 1.2 disponible:

 CMMI para el Desarrollo (CMMI-DEV o CMMI for Development), Versión 1.2 fue liberado en agosto de 2006. En él se tratan procesos de desarrollo de productos y servicios.

 CMMI para la adquisición (CMMI-ACQ o CMMI for Acquisition), Versión 1.2 fue liberado en noviembre de 2007. En él se tratan la

7

gestión de la cadena de suministro, adquisición y contratación externa en los procesos del gobierno y la industria.

 CMMI para servicios (CMMI-SVC o CMMI for Services), actualmente un borrador, está diseñado para cubrir todas las actividades que requieren gestionar, establecer y entregar Servicios.

Dentro de la constelación CMMI-DEV, existen dos modelos:

 CMMI-DEV

 CMMI-DEV + IPPD (Integrated Product and Process Development).

Independientemente de la constelación o modelo que opta una organización, las prácticas CMMI deben adaptarse a cada organización en función de sus objetivos de negocio.

Las organizaciones no pueden ser certificadas CMMI. Por el contrario, una organización es evaluada (por ejemplo, usando un método de evaluación como SCAMPI) y recibe una calificación de nivel 1 a 5 si sigue los niveles de Madurez (si bien se comienza con el nivel 2). En caso de que quiera la organización, puede coger áreas de proceso y en vez de por niveles de madurez puede obtener los niveles de capacidad en cada uno de esas Áreas de Proceso, obteniendo en "Perfil de Capacidad" de la Organización.

1.1.7. CMMI VERSIÓN 1.2

Capability Maturity Model Integration (CMMI) es un modelo de aseguramiento de la calidad que busca la mejora continua de las organizaciones mediante el análisis y re-diseño de los procesos que subyacen en la organización. Fue creado por el SEI (Software

8

Engineering Institute) de la Universidad de Carnegie-Mellon y patrocinado por el Ministerio de Defensa de los Estados Unidos.

Con el propósito de lograr la mejora de los procesos, CMMI provee:

 Una forma de integrar los elementos funcionales de una organización.

 Un conjunto de mejores prácticas basadas en casos de éxito probado de organizaciones experimentadas en la mejora de procesos.

 Ayuda para identificar objetivos y prioridades para mejorar los procesos de la organización, dependiendo de las fortalezas y debilidades de la organización que son obtenidas mediante un método de evaluación.

 Un apoyo para que las empresas complejas en actividades productivas puedan coordinar sus actividades en la mejora de los procesos.

 Un punto de referencia para evaluar los procesos actuales de la organización.

CMMI v1.2 corresponde a la tercera versión entregable del modelo CMMI, posterior a las versiones 1.02 (primera versión año 2000) y 1.1 (año 2002). Las versiones previas sirvieron como retroalimentación para que los propios usuarios, evaluadores y evaluados hicieran acotaciones sobre posibles mejoras, las cuales fueron estudiadas, refinadas y algunas incluidas en la versión 1.2.

CMMI v1.2 para desarrollo, que corresponde a una de tres constelaciones de prácticas, es una guía que ayuda a manejar, medir y monitorear procesos utilizados en el desarrollo de productos y servicios de una organización, y contiene prácticas ligadas a la administración de proyectos, administración de procesos, ingeniería y soporte.

9

Las otras dos constelaciones son CMMI para Adquisición que provee una guía para liderar la adquisición informada y decisiva, y CMMI para Servicios que proporciona una guía para la entrega de servicios a clientes internos y externos de la organización. Ambas constelaciones se encuentran aún en desarrollo.

Junto con CMMI se desarrolló y publicó el método de evaluación “Assessment Requirements for CMMI (ARC)” en el año 2000, el cual define los requerimientos considerados esenciales para realizar una evaluación de CMMI en una organización y “Standard CMMI Appraisal Method for Process Improvement”, (SCAMPI), manual seguido por los evaluadores para medir el nivel de madurez de una organización.

Estos dos documentos también se han actualizado como consecuencia de la retroalimentación de la comunidad involucrada en CMMI, generando la última versión 1.2 de SCAMPI y ARC ambas publicadas el año 2006.

1.2 NIVELES DE MADUREZ Y ÁREAS DE PROCESO

Al igual que los restantes modelos de la familia, CMMI plantea que las organizaciones pueden ubicarse en alguno de cinco posibles niveles de madurez, dependiendo del grado de sofisticación de sus procesos (ver Fig. 4)

A su vez, cada nivel de madurez con excepción del inicial queda caracterizado por un conjunto de áreas de proceso que agrupan prácticas que, al ser ejecutadas colectivamente, permiten cumplir con algún objetivo que es considerado importante para el modelo. III

III Mary Beth Chrissis, Mike Konrad, Sandy Shrum; “CMMI® for Development, v1.2”, 2006.

10 Inicial Administrado Definido Administrado Cuantitativamente Optimizado

Administración Básica de Proyectos Proceso Estandarizado

Proceso Administrado Cuantitativamente Proceso en Mejora Continua

1 2 3 4 5 martes, 21 de octubre de 2008

Capability Maturity Model Integration (CMMI)

Niveles de Madurez

Autor: Juan Carlos Chimborazo

Fig. 4 Niveles de Madurez

Como puede apreciarse en la Fig. 5, antes de introducir prácticas de un nivel determinado deben estabilizarse las prácticas del nivel anterior. Es así que, por ejemplo, antes de introducir el área de proceso RSKM-Administración de Riesgos (perteneciente al nivel 3 ó definido) deben estabilizarse las relacionadas con la gestión del proyecto (PP-Planificación del Proyecto y PMC-Monitoreo y Control del Proyecto, pertenecientes al nivel 2 ó administrado).

11

OID CAR

OPP QPM

RD TS PI VER VAL OPF OPD

OT IPM RSKM DAR OEI IT ISM

SAM PPQA CM PP PMC REQM MA

martes, 21 de octubre de 2008 Capability Maturity Model Integration (CMMI)

Áreas de Proceso por Nivel de Madurez

Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Organizational Process Focus Organizational Process Definition Validation Organizational Training Integrated Project Management Risk Management Decision Analysis and Resolution Organizational Environment for Integration Integrated Teaming Integrated Supplier Management Supplier Agreement Management Product and Process QA Configuration Management Project Planning Project Minitoring And Control Requirements Management Measurement And Analysis 2 NM 3 NM 4 NM 5 NM

Autor: Juan Carlos Chimborazo

Fig. 5: Áreas de Proceso por Nivel de Madurez.

Además de poder ver las áreas de proceso por nivel de madurez, el modelo propone una vista alternativa (llamada continua) en donde las áreas están agrupadas por categoría (ver Fig. 6).

12 OPP QPM RD TS PI VER VAL OPF OPD OT IPM RSKM DAR OEI IT ISM PPQA CM PP PMC REQM MA martes, 21 de octubre de 2008

Capability Maturity Model Integration (

CMMI)

Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Organizational Process Focus Organizational Process Definition Validation Organizational Training Integrated Project Management Risk Management Decision Analysis and Resolution Organizational Environment for Integration Integrated Teaming Integrated Supplier Management Product and Process QA Configuration Management Project Planning Project Minitoring And Control Requirements Management Measurement And Analysis Ingeniería Gestión de Procesos Gestión de Proyectos SAM Supplier Agreement Management CAR OID

Autor: Juan Carlos Chimborazo

Soporte

13

Esta es una diferencia sustancial respecto a los modelos anteriores, que sólo permitían una vista u otra (Por ejemplo, CMM-SW proponía una vista por niveles de madurez, mientras que el CMMI-SE lo hacía por categorías).

1.3 ÁREAS DE PROCESO

El modelo CMMI v1.2 (CMMI-DEV) contiene las siguientes 22 áreas de proceso:

 Análisis de Causas y Resolución (CAR)  Gestión de la configuración (CM)

 Análisis de Decisiones y Resolución (DAR)  Gestión Integrada de Proyectos (IPM)  Medición y Análisis (MA)

 Innovación y Despliegue Organizacionales(OID)  Definición de procesos organizacionales (OPD)  Enfoque Organizacional en Procesos (OPF)

 Rendimiento de Procesos Organizacionales (OPP)  Formación Organizacional (OT)

 Monitorización y Control de Proyecto (PMC)  Planificación de proyecto (PP)

 Aseguramiento de calidad de Procesos y Productos (PPQA)  Integración de Producto (PI)

 Gestión Cuantitativa de Proyectos (QPM)  Gestión de Requerimientos (REQM)  Desarrollo de Requerimientos (RD)  Gestión de Riesgos (RSKM)

 Gestión de Acuerdos con Proveedores (SAM)  Solución Técnica (TS)

 Validación (VAL)  Verificación (VER)

14

CAPÍTULO II: ESTRUCTURA DE CMMI Y ANALISIS DE OTROS MODELOS

2.1 LOS CINCO NIVELES DE MADUREZ

Nivel 1: Inicial

En el nivel de madurez 1, la mayoría de los procesos son “ad-hoc” y caóticos. La organización usualmente no provee un ambiente estable para soportar los procesos. Éxitos en estas organizaciones se debe a la competencia y esfuerzos heroicos de la gente dentro de la organización y no al uso de procesos probados.

A pesar de este caos, organizaciones pertenecientes al nivel de madurez 1 con frecuencia producen productos y servicios que funcionan; sin embargo, ellos frecuentemente exceden sus presupuestos y no cumplen sus planes.

Estas organizaciones son caracterizadas por la tendencia a no cumplir sus compromisos, al abandono de procesos durante tiempos de crisis, y a la incapacidad para repetir sus éxitos. El Nivel 1 está caracterizado además por la realización de trabajo redundante, por personas que no comparten sus métodos de trabajo a lo largo de la organización y cuando una persona clave en un área de negocio específica dentro de la organización se marcha, su conocimiento se va con ella y se pierde para la organización. Es claro que el Nivel 1 es uno donde ninguna organización quiere estar y donde por lo general la mayoría que no tiene sus procesos definidos se encuentra. IV

IV Margaret K. Kulpa, Kent A. Johnson: “Interpreting the CMMI: A Process Improvement

15 Nivel 2: Manejado

En el nivel de madurez 2 se ordena el caos. En el nivel 2 las organizaciones se enfocan en tareas cotidianas referentes a la administración. Cada proyecto de la organización cuenta con una serie de procesos para llevarlo a cabo, los cuales son planeados y ejecutados de acuerdo con políticas establecidas; los proyectos utilizan gente capacitada quienes disponen de recursos para producir salidas controladas; se involucran a las partes interesadas; son monitoreados, controlados y revisados; y son evaluados según la descripción del proceso.

La disciplina del proceso reflejada por el nivel de madurez 2 ayuda a asegurar que existen prácticas y los proyectos son realizados y manejados de acuerdo a los planes documentados. En el nivel de madurez 2 el estado de los artefactos y la entrega de los servicios siguen planes definidos.

Acuerdos son establecidos entre partes interesadas y son revisados cuando sea necesario. Los artefactos y servicios son apropiadamente controlados. Estos además satisfacen sus descripciones especificadas, estándares, y procedimientos.

Nivel 3: Definido

En el nivel de madurez 3, los procesos son caracterizados y entendidos de buena forma, y son descritos en estándares, procedimientos, herramientas, y métodos. El conjunto de procesos estándares de la organización, los cuales son la base para el nivel de madurez 3, es establecido y mejorado continuamente. Estos procesos estándares son usados para establecer consistencia a través de la organización. Los proyectos establecen sus procesos adaptando el conjunto de procesos estándares de la organización de acuerdo a guías de adaptación.

16

Una diferencia importante entre el nivel 2 y 3 es el alcance de los estándares: la descripción de procesos y los procedimientos. En el nivel de madurez 2, los estándares pueden ser un poco diferentes en cada instancia específica del proceso (por ejemplo sobre un proyecto particular).

En el nivel de madurez 3, los estándares, descripción de procesos y procedimientos para un proyecto, son adaptados desde un conjunto de procesos estándares de la organización a un particular proyecto o unidad organizacional y así son más consistentes.

Otra distinción crítica es que el nivel de madurez 3, los procesos son típicamente descritos más rigurosamente que en el nivel 2. Un proceso definido claramente plantea el propósito, entradas, criterios de entrada, actividades, roles, medidas, pasos de verificación, salidas y criterios de salida. En el nivel de madurez 3, los procesos son manejados más proactivamente entendiendo las interrelaciones de las actividades y medidas detalladas del proceso, sus artefactos y sus servicios.

Nivel 4: Manejado Cuantitativamente

En el nivel de madurez 4, la organización y proyectos establecen objetivos cuantitativos para medir la calidad y realización de los procesos y los usa como criterios en el manejo de ellos. Los objetivos cuantitativos son definidos en base a las necesidades de clientes, usuarios finales, organización, y actores de los procesos. La calidad y realización de procesos son entendidos en términos estadísticos y son manejados durante todo el ciclo de vida del proceso. Para subprocesos seleccionados, se recolectan y analizan estadísticamente medidas sobre la realización de procesos.

17

Estas métricas son incorporadas en el repositorio de métricas de la organización para apoyar la toma de decisiones. Causas especiales de variación de procesos son identificadas y, cuando sea necesario, las fuentes de estas causas son corregidas para prevenir futuras ocurrencias.

Una diferencia importante entre los niveles 3 y 4 es la capacidad de predicción de la realización del proceso. En el nivel de madurez 4, la realización de procesos es controlada usando técnicas estadísticas y cuantitativas, y el proceso es cuantitativamente predecible, en cambio en el nivel de madurez 3 la realización del proceso es sólo predecible cualitativamente.

Nivel 5: Optimizado

En el nivel de madurez 5, una organización mejora continuamente sus procesos basándose en el conocimiento de las causas comunes de variación inherente en los procesos. El nivel de madurez 5 se focaliza sobre la mejora continua de los procesos a través de mejoras continuas, incrementales y tecnológicas.

Los objetivos de mejora cuantitativa de procesos para la organización son establecidos, continuamente revisados para reflejar cambios en los objetivos del negocio y usados como criterio en la mejora de procesos. Los efectos del empleo de las mejoras de procesos son medidos y evaluados contra los objetivos de mejora cuantitativa del proceso.

Una diferencia importante entre el nivel de madurez 4 y 5 es el enfoque de la variación de los procesos. En el nivel de madurez 4, la organización está orientada a encontrar causas especiales de variación y proveer una predicción estadística de los resultados.

18

Sin embargo, los resultados pueden ser insuficientes para alcanzar los objetivos establecidos. En el nivel de madurez 5 la organización está enfocada en las causas comunes de variación de procesos y modificar los procesos afectados para mejorar la realización de ellos y alcanzar los objetivos cuantitativos de mejora de procesos.

2.2 ARQUITECTURA DEL MODELO

En la representación por niveles, cada nivel de madurez contiene varias áreas de proceso, las que a su vez quedan definidas por uno o varios objetivos específicos y un objetivo genérico.

Cada uno de ellos tiene vinculado un conjunto de prácticas, llamadas específicas y genéricas respectivamente. Como se puede observar en la figura Nro. 7.

19

2.2.1 OBJETIVOS Y PRÁCTICAS GENÉRICAS

Los objetivos y prácticas genéricas tienen que ver con el grado de institucionalización de los procesos (compromiso con la ejecución, capacidad para ejecutar, dirección de la ejecución, verificación de la ejecución). Son llamados así porque son los mismos en todas las áreas de proceso (aunque hay aspectos específicos para cada una de ellas). Cumplir con un objetivo genérico de un área de proceso determinada implica tener un mayor control de la planificación e implementación de los procesos vinculados a esa área de proceso. En el nivel 2, el objetivo y las prácticas genéricas son los siguientes:

Institucionalizar un proceso administrado

 Establecer políticas organizacionales

 Planificar el proceso

 Proveer Recursos

 Asignar responsabilidades

 Entrenar al personal

 Administrar la configuración

 Identificar e involucrar a los interesados

 Monitorear y controlar los procesos

 Evaluar adhesión objetivamente

 Revisar el estado con la alta gerencia

En los niveles 3, 4 y 5, a los anteriores se agregan los siguientes:

Institucionalizar un proceso definido

 Establecer un proceso definido

20

2.2.2 OBJETIVOS Y PRÁCTICAS ESPECÍFICAS

Los objetivos y prácticas específicas están vinculados a un área de proceso determinada. Son considerados elementos que deben ser satisfechos para implementar exitosamente los procesos relacionados con un área de proceso en particular. V

Por ejemplo, como se puede observar en la tabla Nro. 1 constan, los objetivos y prácticas, del área de Administración de Requerimientos (REQM).

Objetivo Específico Prácticas Específicas Administrar Requerimientos

Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto.

 Comprender el significado de los requerimientos.

 Obtener compromiso de los participantes/interesados acerca de los requerimientos.

 Administrar cambios a los requerimientos.

 Mantener la trazabilidad bidireccional de los requerimientos.

 Identificar inconsistencias entre los requerimientos y otros productos del proyecto.

Tabla Nro. 1 Administración de requerimientos 2.3 OTROS ESTÁNDARES Y MODELOS DE REFERENCIA

Además de CMMI, existen otros modelos y estándares que pueden ser empleados como referencia para definir e implantar procesos: ISO 9001, CobIT, ITIL y ESCM.

V Software Engineering Institute, University Carnegie-Mellon: “Capability Maturity

21

A continuación se describe sus principales características y ámbitos de aplicación.

2.3.1 ISO 9001:2000

El más conocido de los mencionados anteriormente es ISO 9001:2000, un estándar internacional que puede ser aplicado a cualquier tipo de organización. Este estándar, que establece los requerimientos que debe cumplir un sistema genérico de gestión de la calidad (QMS, por sus siglas en inglés), puede ser usado para mejorar procesos internos, para obtener una certificación o para establecer relaciones contractuales. Si bien su ámbito de aplicación es más amplio, existen lineamientos para su uso en organizaciones de sistemas.

Los requerimientos de la norma se agrupan en cinco capítulos: sistema de gestión de calidad, responsabilidad de la dirección, gestión de recursos, realización del producto y medición, análisis y mejora. Dentro de cada uno de ellos encontraremos las cláusulas que describen los requerimientos que deben satisfacerse para cumplir con el modelo.

ISO 9001:2000 y CMMI tienen varios puntos de contacto, y algunas diferencias. Si bien es necesario analizar las situaciones caso por caso, podríamos decir que una organización deseosa de certificar el estándar debería cumplir con las áreas de proceso de nivel 2 y nivel 3, más algunas de las correspondientes a los niveles cuatro y cinco. En la Fig. 4 se ilustran las relaciones entre cada uno de los capítulos del estándar y las áreas de proceso y prácticas genéricas de CMMI.

Por ejemplo, ISO 9001:2000 plantea requerimientos para los procesos de relacionamiento con los clientes, aspectos omitidos en CMMI. VI

22

VI

Página 1

Capability Maturity Model Integration (CMMI)

Relación entre CMMI e ISO 9001:2000

Autor: Juan Carlos Chimborazo

Gestión de Calidad. CMMI: OPF, OPD, PPQA, CM, SAM: GP 2.1, 2.2, 2.3, 2.6, 2.7, 2.8, 2.9, 3.1, 3.2 ISO: Responsabilidad de la Dirección. CMMI: OPF, OPD, RD, PMC, OPP, QPM; GP 2.1 a 2.4, 2.6, 2.7, 2.10, 3.1

ISO: Gestión de Recursos.

CMMI: PP, OT, OEI; GP 2.3, 2.5

ISO: Medición, Análisis y Mejora.

CMMI: PMC, PPQA, MA, CM, REQM, RD, SAM, OPF, VER, VAL, OID, OPP, QPM, CAR; GP 2.1 a 2.6, 2.8, 2.9, 3.2

ISO: Realización del Producto.

CMMI: REQM, RD, TS, PI, MA, QPM, VER, VAL, OPD, PP, PMC, IPM, CM, SAM; GP 2.1 a 2.10, 3.1

Fig. 8 Relación entre CMMI e ISO 9001:2000

2.3.2 CobIT

CobIT, por otro lado, es un modelo desarrollado por el IT Governance Institute cuyo propósito es establecer una serie de objetivos de control para las actividades de la organización de IT.

CobIT se organiza en cuatro dominios, los cuales a su vez se descomponen en procesos que contienen los objetivos de control como se observa en el siguiente grafico.

VI Boris Mutafelija, Harvey Stromberg; Systematic Process Improvement Using ISO 9001:2000 and CMMI; Artech House Publishers, 2003

23 Página 1

COBIT

Dominios y procesos de CobIT

Autor: Juan Carlos Chimborazo

Monitoreo y Evaluación Planificación y Organización Entrega y Soporte Adquisición e Implementación M1 Monitorear Procesos

M2 Evaluar Controles Internos

M3 Obtener Aseguramiento Independiente M4 Proveer Auditoria Independiente

DS1 Definir Niveles de Servicio DS2 Administrar Servicios de Terceros DS3 Administrar Perfomance y Capacidad DS4 Asegurar Continuidad del Servicio DS5 Asegurar Seguridad de los Sistemas DS6 Identificar y Distribuir Costos DS7 Educar y Entrenar Usuarios DS8 Asistir al Cliente de IT DS9 Administrar Configuraciones DS10 Administrar Problemas e Incidentes DS11 Administrar Datos

DS12 Administrar Instalaciones DS13 Administrar Operaciones

PO1 Definir el Plan Estratégico de IT PO2 Definir la Arquitectura de la Información PO3 Determinar la Dirección Tecnológica PO4 Definir la Organización de IT PO5 Administrar las Inversiones en IT PO6 Comunicar Objetivos y Dirección PO7 Administrar Recursos Humanos PO8 Asegurar el Cumplimiento de Regulaciones PO9 Evaluar Riesgos

PO10 Administrar Proyectos PO11 Administrar Calidad

AI1 Identificar Soluciones

AI2 Adquirir y Mantener Software de Aplicación AI3 Adquirir y Mantener Infraestructura Tecnológica AI4 Desarrollar y Mantener Procedimientos AI5 Instalar y Certificar Sistemas AI6 Administrar Cambios

Fig. 9 Dominios y procesos de CobIT

Como puede apreciarse en la Fig. 9, varios de los procesos tienen puntos de contacto con CMMI. Por ejemplo, P09 Administrar Riesgos está claramente relacionado con Gestión del Riesgo (RSKM) (aunque los alcances son distintos) y P10 Administrar Proyectos con Planificación del Proyecto (PP), Monitoreo y Control del Proyecto (PMC) y Administración Integrada del Proyecto (IPM).

Sin embargo, debe recordarse que ambos modelos tienen propósitos distintos: uno apunta a facilitar la evaluación y mejora de procesos, mientras que el otro está enfocado en proveer objetivos y guías para controlar las actividades de IT.

24 2.3.3 ITIL

ITIL es el acrónimo de Information Technology Infrastructure Library. Desarrollado en los años ochenta por la CCTA (Central Computer & Telecommunications Agency) del Reino Unido y administrado actualmente por la OGC (Office of Government Commerce), ITIL es un marco para organizar las actividades de provisión de servicios de IT. No es un estándar, sino un conjunto de best practices organizado alrededor de diez procesos como se puede observar.

Página 1

ITIL

Procesos de ITIL

Autor: Juan Carlos Chimborazo Incident Management Change Management Configuration Management Release Management Problem Management Financial Management Service Level Management Availability Management Capacity Management Continuity Management

Fig. 10: Procesos de ITIL

La principal característica de ITIL es que no prescribe sino que describe: en cada uno de los libros correspondientes a cada proceso se proveen lineamientos detallados de los procedimientos y actividades necesarias para implementarlo. Esta es una diferencia sustancial respecto a los distintos frameworks incluidos en esta sección.

25

A pesar de lo antes mencionado, hay dos estándares basados en ITIL: BS15000 y el más reciente ISO 20000.

Si bien ITIL implementa las actividades relacionadas con lo que pasa luego de que la solución es puesta en producción uno de los aspectos no contemplados por CMMI, hay muchos puntos de contacto con dicho modelo; por ejemplo, change, configuration y release management están claramente relacionados con el área de proceso Administración de la Configuración (CM). También Problem management tiene muchos puntos de contacto con Análisis y resolución de causas de defectos/problemas (CAR).

2.3.4 MODELO ESCM

Este modelo (eSourcing Capability Model) es el desarrollo más reciente de la Carnegie Mellon University, pero en esta ocasión su origen no es el Software Engineering Institute sino el IT Services Qualification Center (ITsqc), dependiente del Institute for Software Research International de la Facultad de Ciencias de la Computación.

Participaron además empresas como IBM, Accenture y EDS, entre otras. Este modelo de capacidades apunta a cubrir ciertos aspectos relacionados con la provisión de servicios basados en IT que el resto de los modelos no cubre (por ejemplo, transferencia de conocimientos al proveedor del servicio, contratación, gestión de relaciones, etc.) Su propósito es que los proveedores de servicios sean más eficaces y eficientes, que sus contratos no sean interrumpidos por mal desempeño, y que haya una mejor relación entre proveedores, clientes y organizaciones asociadas.

26

Existen dos variantes del modelo, uno destinado a los proveedores del servicio (eSCM-SP) y otro a los clientes del servicio (aún no liberado). Claramente, el modelo es aplicable en aquellas situaciones en donde una organización desee tercerizar no sólo sus servicios de IT (desarrollo, help desk, etc.) sino también procesos de negocio que hagan uso intensivo de la tecnología (call centers, facturación, etc.). A toda esta gama de actividades tercerizadas es a las que eSCM llama eSourcing.

Página 1

Fases y Áreas de Capacidad de eSCM

Autor: Juan Carlos Chimborazo Cantidad de Practicas

por Nivel de Capacidad Fase Área de Capacidad 1 2 3

3 3 3 3 4 6 9 6 2 7 2 4 7 3 4 1 1 2 2 1 1 1 1 5 1 1 1 Continua Iniciación Entrega

Realizacion Servicio de Traslado (Fuera) Entrega de Servicio Servicio de Traslado (Dentro)

Amenaza Administrativa Conocimiento Administrativo Personal Administrativo Rendimiento Administrativo Relación Administrativa Tecnología Administrativa

No hay practicas en el nivel de capacidad 5. Hay que mantener las practicas anteriores durante dos o mas certificaciones consecutivas

Contratante

Servicio de Diseño y Despliegue

Fig. 11: Fases y áreas de capacidad de eSCM El modelo tiene muchas particularidades (ver Fig. 11). Por un lado, las prácticas pueden agruparse por áreas de capacidad (similares a las categorías de proceso de CMMI), por fase, en función de la etapa en la cual se encuentre la provisión del servicio (iniciación antes de la

27

formalización del contrato, despliegue, prestación del servicio, cierre y ongoing (continua), para aquellas prácticas que se aplican en todas las fases anteriores), y por niveles (2, 3 y 4).

De todas maneras, es interesante observar que uno de sus autores es Mark Paulk, quien fue también autor del CMM-SW. Otro de los aspectos interesantes es que no es un modelo de madurez, sino de capacidad. Esto implica que las áreas pueden ser evaluadas individualmente (de manera similar a cuando se emplea la representación continua de CMMI) y reciben una clasificación entre 2 y 5 en función de las prácticas implementadas. VII

Otra de las particularidades es que el nivel de capacidad 5 se otorga luego de haber certificado dos veces seguidas la de nivel 4 (existe una certificación formal realizada por el ITsqc).

2.3 INTEGRANDO LOS MODELOS

Cada uno de los modelos y estándares propuestos tiene un propósito y un alcance claros. Sin embargo, cada uno de ellos puede ser usado simultáneamente de ser necesario.

Por ejemplo, CMMI y eSCM podrían ser usados concurrentemente en aquellas situaciones en donde se tercerice el desarrollo y mantenimiento de software (software factory).

ITIL ó ISO 20000 podría aplicarse para resolver los temas no cubiertos por CMMI.

CobIT es un framework que es propuesto como modelo de IT Governance, de manera que hay muchos puntos de contacto con ITIL y

VII Ivar Jacobson, Grady Booch, James Rumbaugh: “The Unified Software Development

28

CMMI que deberían ser analizados, sobre todo en organizaciones internas de sistemas.

ISO 9001:2000 y CMMI comparten filosofía (la mejora continua y la gestión de procesos) y prácticas. Una alternativa sería usar CMMI como guía para obtener una certificación ISO 9001:2000.

Sin embargo, debe hacerse un análisis detallado ya que el mapeo entre el estándar y el modelo de referencia no es necesariamente lineal (ver Fig. 8).

En la siguiente tabla Nro. 2 se muestra una comparación entre los modedol anteriormente mencionados:

CMMI ISO9001 CobIT ITIL eSCM-SP

Organizaciones de desarrollo de sistemas basados en software. Proveedores de cualquier tipo de producto/servicio. Organizaciones de IT. Proveedores de servicios de IT Proveedores de servicios basados en IT.

Proveer las mejores prácticas para el desarrollo de software, sistemas, productos y procesos integrados, y adquisición. Requerimientos para el establecimiento de un sistema de calidad. Auditoría y control de sistemas de información. Alineamiento y gobierno de IT. Marco de trabajo para organizar los procesos de provisión de servicios de IT. Desarrollar y mejorar las habilidades del proveedor para cumplir con las necesidades del cliente durante todo el ciclo de vida. 628 prácticas en 25 áreas de proceso 51 cláusulas. 4 dominios, 34 procesos de IT y 318 objetivos de control. 10 procesos. 84 prácticas en 10 áreas de capacidad. Reporte de evaluación/assessment; no hay certificación formal.

Certificación por entes autorizados. Reporte del auditor; no hay certificación formal. Es un modelo de referencia y una descripción de procesos al mismo tiempo. No se certifica ni se evalúa formal-mente. El nuevo estándar ISO 20000 está inspirado en él Certificación de CMU.

TABLA Nro. 2: COMPARACIÓN ENTRE CMMI, ISO 9001, COBIT, ITIL Y ESCM.

29 2.5 DISCIPLINAS

El modelo incluye cuatro cuerpos de conocimiento distintos:

 Ingeniería de software.

 Ingeniería de sistemas.

 Desarrollo integrado de productos y procesos.

 Adquisición de productos.

Si bien el modelo es esencialmente el mismo para las cuatro disciplinas, en algunas de ellas se agrega áreas de proceso o prácticas puntuales. También pueden aparecer comentarios particulares que clarifican su aplicación en el contexto de alguna de las cuatro disciplinas (amplificaciones).

Las disciplinas de ingeniería de software e ingeniería de sistemas (SW y SE) no merecen mayor aclaración (en cierta manera, cubren el alcance del SW-CMM y de SE-CMM, respectivamente); la recomendación que da el modelo es que se use la segunda, ya que toda pieza de software forma parte de un sistema mayor.

Adquisición de productos (SS, por supplier sourcing) es un cuerpo de conocimiento que debe ser aplicado siempre que el proyecto dependa de actividades críticas que deban realizar proveedores. El modelo agrega un área específica para esta disciplina, Gestión Integrada de Proveedores (ISM).

Por último, desarrollo integrado de productos y procesos (IPPD) es una disciplina aplicable en aquellas situaciones en donde sea necesario desarrollar, en forma concurrente, no sólo el producto sino también los procesos a emplear para diseñarlo, construirlo y mantenerlo (incluyendo el soporte a los usuarios).

30

Se agregan dos áreas de proceso específicas, Equipo Integrado (IT) y Ambiente Organizacional para la Integración (OEI). IPPD debe ser usada junto a alguna de las otras disciplinas disponibles.

31

CAPÍTULO III: LAS ÁREAS DE CMMI

3.1 ÁREAS DE PROCESO DE NIVEL 2

En una organización que haya alcanzado este nivel de madurez encontraremos que hay una disciplina para la gestión de proyectos que se mantiene aún en periodos de estrés. Los recursos estarán capacitados para hacer su trabajo, y habrá políticas organizacionales formalmente establecidas, cuyo cumplimiento será monitoreado. Habrá visibilidad de las actividades realizadas, y los proyectos se ejecutarán siguiendo un plan y de acuerdo a un proceso formalmente establecido.

Si bien el establecimiento de estándares organizacionales recién es contemplado en el siguiente nivel, aquí nos encontraremos con procesos definidos en el contexto de cada proyecto. Por supuesto que pueden definirse procesos más o menos generales (que puedan ser usados por más de un proyecto), pero el modelo no lo prescribe por la sencilla razón de que primero es necesario poner orden dentro de cada proyecto para luego ordenar el resto de la organización (el foco de nivel 3).

Las áreas de proceso del nivel 2 son siete en total, las cuales se describe a continuación:

3.1.1 ADMINISTRACIÓN DE REQUERIMIENTOS (REQM)

Esta área de proceso tiene como propósito mantener bajo control los requerimientos que el producto a desarrollar deberá satisfacer. Las prácticas incluidas aquí apuntan a que los requerimientos no solo estén claramente identificados, sino también que todos los involucrados en el proyecto (el cliente, el equipo de proyecto, etc.) estén de acuerdo en su significado. Adicionalmente, los requerimientos deben ser la entrada a las actividades de planificación (ver Planificación del Proyecto (PP)) y a las técnicas incluidas en nivel 3.

32

Un tema fundamental planteado en esta área de proceso es que cualquier cambio realizado a los requerimientos se efectúe de manera controlada (por ejemplo, solamente un grupo reducido de personas debería proponer cambios) y que el resto de los artefactos del proyecto (planes, especificaciones, diseño, etc.) se mantengan consistentes. Otro aspecto importante incluido en esta área es el de trazabilidad bidireccional.

Cuando los requerimientos son correctamente administrados deberíamos estar en condiciones de relacionar cuál ha sido el origen de los requerimientos, cuál es la relación entre los requerimientos de bajo nivel y los de alto nivel (por ejemplo, cuáles son derivados y de cuál requerimiento), cuáles son los artefactos relacionados con los requerimientos (por ejemplo, especificaciones, documentos de diseño o planes), y cuáles componentes del producto implementan cada requerimiento.

Esta práctica es sumamente importante para poder realizar un buen análisis de impacto ante posibles cambios, y fundamental para poder determinar si el alcance del proyecto ha sido cubierto o no (han sido satisfechos todos los requerimientos).

Como se puede observar en la tabla Nro. 3 en esta área hay solamente un objetivo específico y cinco prácticas:

Objetivo Específico Prácticas Específicas Administrar Requerimientos

Los requerimientos son administrados, y se identifican las inconsistencias entre los requerimientos y los planes y otros artefactos del proyecto.

 Comprender el significado de los requerimientos.

 Obtener compromiso de los participantes acerca de los requerimientos.

 Administrar cambios a los requerimientos.

 Mantener la trazabilidad. bidireccional de los requerimientos.

 Identificar inconsistencias entre los requerimientos y otros productos del proyecto.

33

Desde el punto de vista práctico, el área de proceso se satisface poniendo en marcha algún tipo de mecanismo o sistema que:

 Identifique quienes son las fuentes oficiales de requerimientos.

 Identifique cuáles son los canales válidos para ingresar requerimientos al proyecto.

 Controle los cambios (no cualquiera estaría en condiciones de generar un cambio a un requerimiento).

 Permita determinar si todos los involucrados tienen la misma visión respecto al significado de los requerimientos (por ejemplo, mediante la aprobación de algún tipo de documento formal).

 Mantenga la trazabilidad entre los requerimientos y otros artefactos (incluyendo al producto y sus componentes).

Si bien a esta altura no es necesario definir ninguna técnica de especificación en particular (tema atacado recién en el nivel 3), lo más usual es que se avance en esa dirección para poder tener efectivamente requerimientos para administrar.

Vale aclarar que para este modelo, los requerimientos se clasifican en tres categorías:

 Los del usuario (aquellos que formula el usuario y que, por ejemplo, pueden ser documentados en una minuta de reunión)

 Los del producto (derivados a partir de los primeros; generalmente descriptos en un lenguaje más cercano al equipo de proyecto), y

 Los de las componentes del producto (derivados de los anteriores)

En algunas organizaciones los usuarios suelen volcar sus necesidades en algún tipo de herramienta (por ejemplo, en un workflow), las que

34

posteriormente serán elaboradas por el equipo de proyecto y formalizadas en algún tipo de documento con un nivel de detalle suficiente para poder conducir las actividades técnicas y de gestión (por ejemplo, una Visión o un Acuerdo de Proyecto).

3.1.2 PLANIFICACIÓN DEL PROYECTO (PP)

Esta área de proceso tiene como propósito establecer y mantener el plan que será empleado para ejecutar y monitorear el proyecto. El plan se desarrolla sobre la base de los requerimientos administrados por el área REQM (ver sección anterior)

Dentro de esta área de proceso se incluyen todas las actividades necesarias para determinar el alcance del proyecto (funcionalidad a desarrollar, actividades incluidas y excluidas, etc.), estimar esfuerzo y costos, establecer el cronograma, identificar riesgos, y obtener el compromiso de todos los involucrados respecto al plan de proyecto.

En la tabla Nro. 4 se listan los objetivos y prácticas específicas son las siguientes:

Objetivos Específicos Prácticas Específicas Establecer estimaciones

Se realizan y mantienen estimaciones de las magnitudes del proyecto.

 Estimar el alcance del proyecto.

 Estimar atributos de las tareas y de los productos del proyecto.

 Definir el ciclo de vida del proyecto.

 Estimar esfuerzo y costo del proyecto. Desarrollar el plan de proyecto

Se establece y mantiene un plan de proyecto que es empleado para administrar el proyecto.

 Establecer el cronograma y el presupuesto del proyecto.

 Identificar los riesgos del proyecto. Planificar la administración de datos del proyecto.

 Planificar recursos necesarios para el proyecto.

 Planificar la adquisición de conocimiento y habilidades.

 Planificar la participación de los interesados en el proyecto.

 Establecer el plan del proyecto.

35

interesados acerca del plan de proyecto.

Los compromisos con el plan están formalmente establecidos y son mantenidos a lo largo del proyecto.

afectar al proyecto.

 Ajustar el plan de proyecto para reflejar recursos estimados vs. Disponibles.

 Obtener compromisos respecto al plan.

TABLA Nro. 4 PLANIFICACIÓN DEL PROYECTO

Las actividades de esta área suelen implementarse mediante la combinación de varios elementos. Por un lado, será necesario establecer algún tipo de mecanismo de estimación que emplee como input los requerimientos del proyecto. También será necesario formalizar el plan de proyecto (que no es solamente el cronograma), el ciclo de vida a emplear (por lo menos, fases e hitos), y los mecanismos de aprobación.

Si bien no está explícitamente indicado en el modelo, el establecimiento de una función tipo PMO (Project Management Office) podría actuar como facilitador de la implementación de esta área de proceso y de la siguiente (Monitoreo y Control del Proyecto (PMC)).

3.1.3 MONITOREO Y CONTROL DEL PROYECTO (PMC)

No tiene sentido formular planes para algo que no se tiene intenciones de gestionar. Esta área de proceso es complementaria y una consecuencia de Planificación del Proyecto (PP): su propósito es monitorear la ejecución del proyecto empleando para ello el plan y gestionar acciones correctivas en el caso de detectarse desvíos.

En la tabla Nro. 5 se listan los objetivos y prácticas específicas son las siguientes:

Objetivos Específicos Prácticas Específicas Monitorear el Proyecto

El avance y la performance del proyecto se monitorean respecto a lo establecido en el plan de proyecto.

Monitorear los parámetros de planificación del proyecto.

Monitorear los compromisos. Monitorear los riesgos del proyecto.

36

Monitorear la administración de datos del proyecto.

Monitorear la participación de los interesados.

Conducir revisiones de avance.

Conducir revisiones de cumplimiento de hitos.

Gestionar Acciones Correctivas Cuando los resultados o la performance del proyecto se desvían significativamente del plan se gestionan acciones correctivas.

Analizar temas pendientes. Ejecutar acciones correctivas. Administrar acciones correctivas.

TABLA Nro. 5 MONITOREO Y CONTROL DEL PROYECTO

Para poder cumplir con estos objetivos será necesario implementar prácticas de seguimiento, tales como el reporte de horas trabajadas en el proyecto, el informe de avance periódico, revisiones en puntos particulares del proyecto (por ejemplo, al final de cada fase), etc. Si bien esto suena sencillo, conseguir cambiar la cultura (que en general favorece la ‘no visibilidad’ de los proyectos) es una tarea durísima.

La PMO (Project Management Office) también puede jugar un papel importante aquí, realizando el seguimiento a alto nivel de los proyectos en ejecución, y generando los indicadores correspondientes (ver Medición y Análisis (MA).

Por supuesto que, al igual que el área de proceso anterior, es imprescindible identificar personas dentro de la organización que puedan cubrir el rol de líder o gerente de proyecto. Esto puede sonar redundante, pero es bastante habitual encontrar organizaciones que ni siquiera reconocen la existencia del rol.

3.1.4 MEDICIÓN Y ANÁLISIS (MA)

Una premisa presente en todos los movimientos de calidad es que lo que no puede medirse no puede mejorarse. Esta área de proceso apunta,

37

justamente, a desarrollar y mantener capacidades de medición que permitan satisfacer las necesidades de información de la organización.

Sus objetivos y prácticas como se puede observar en la tabla Nro. 6, son las siguientes:

Objetivos Específicos Prácticas Específicas Alinear actividades de medición y análisis.

Las actividades de medición y análisis están alineadas con los objetivos y necesidades de información.

Establecer objetivos de las mediciones. Especificar métricas. Especificar procedimientos de recolección y almacenamiento de datos. Especificar procedimientos de análisis.

Proveer los resultados de la medición Se proveen mediciones que satisfacen necesidades y objetivos de información.

Recolectar datos Analizar datos

Almacenar datos y resultados Comunicar resultados

TABLA Nro. 6 MONITOREO Y CONTROL DEL PROYECTO

Estos objetivos pueden satisfacerse básicamente mediante la puesta en marcha de un programa de métricas que defina:

 Objetivos de la organización (por ejemplo, aumentar la productividad un X% o disminuir los defectos en producción un Z%);

 Métricas que permitan determinar si se cumplen o no con los objetivos (por ejemplo, productividad, densidad de defectos, etc.);

 Mecanismos de obtención de las métricas (procedimientos manuales, aplicaciones, orígenes de datos).

Usualmente, los indicadores pueden agruparse en dos: por un lado, los empleados para monitorear cada proyecto (valor ganado, densidad de defectos, etc.), y por el otro los más generales (porcentaje de proyectos finalizados en fecha, desvío promedio, etc.).

38

Un enfoque muy interesante que puede emplearse para implementar los indicadores del segundo grupo es el balanced scorecard propuesto por Kaplan y Norton.

3.1.5 ASEGURAMIENTO DE LA CALIDAD DE PRODUCTOS Y PROCESOS (PPQA)

Una vez establecidos procesos y estándares será necesario evaluar su aplicación.

El objetivo de esta área es justamente ese: proveer una evaluación objetiva de los procesos y de los artefactos producidos.

Es importante aclarar que las prácticas de esta área implican:

 Evaluar los procesos ejecutados, los artefactos producidos y los servicios provistos versus los estándares y descripciones de proceso aplicables;

 Identificar no conformidades, comunicarlas a los responsables, y asegurar su resolución;

 Informar a los interesados (básicamente, el equipo de proyecto y la gerencia) el resultado de las actividades de aseguramiento de la calidad.

De ninguna manera debe confundirse esta área con la de Verificación (VE) incluida en el nivel 3, cuyo propósito es garantizar que se satisfagan los requerimientos. El foco aquí está puesto en garantizar que se apliquen los estándares y que los procesos se ejecuten de acuerdo a lo previsto.

Un tema importante es el de la objetividad, debe garantizarse un nivel apropiado de independencia entre los productores y los evaluadores (aquellos que ejecuten actividades de aseguramiento de la calidad). Un

39

canal de reporte con la gerencia también es importante para comunicar las no conformidades y garantizar que se resuelvan.

Los objetivos y prácticas específicas del área se puede observar en la siguiente tabla Nro. 7:

Objetivos Específicos Prácticas Específicas Evaluar objetivamente procesos y

artefactos.

Se evalúa objetivamente la adhesión de los procesos y artefactos a los estándares y descripciones de proceso vigentes.

 Evaluar procesos objetivamente.

 Evaluar productos y servicios objetivamente.

Proveer realimentación objetivamente. El no cumplimiento de los estándares y descripciones de proceso es objetivamente comunicado y su resolución asegurada.

 Comunicar y asegurar la resolución de cuestiones de calidad.

 Establecer y mantener registros de las actividades de aseguramiento de la calidad.

TABLA Nro. 7 ASEGURAMIENTO DE LA CALIDAD DE PRODUCTOS Y PROCESOS Estas prácticas suelen implementarse mediante la creación de un rol (no necesariamente full-time) encargado de estas actividades, y por supuesto, de los procesos y estándares correspondientes.

Algunas actividades de aseguramiento de la calidad podrán estar embebidas en el proceso de producción (por ejemplo, como una actividad en el plan de proyecto), mientras que otras podrán ejecutarse independientemente y tener su propio plan (más en el estilo de una auditoria).

Hemos adoptado el término ‘artefacto’ para traducir lo que en el original figura como ‘workproduct’. Un artefacto es todo aquello producido por un proceso (el producto final, los productos intermedios).

Es sumamente importante que el nivel de management adecuado reciba los informes de no-conformidad y facilite su regularización. Por supuesto que su postura no debe ser coercitiva.

40

3.1.6 ADMINISTRACIÓN DE LA CONFIGURACIÓN (CM)

Esta área de proceso tiene como propósito mantener la integridad de todos los artefactos (entregables o no ) producidos por el proyecto, lo cual implica identificar los ítems de configuración, realizar sobre ellos cambios de manera controlada, generar y mantener líneas base, y proveer información precisa acera del estado del estado de la configuración a todos los interesados.

En la siguiente tabla Nro. 8 se definen los objetivos y prácticas incluidas son los siguientes:

Objetivos Específicos Prácticas Específicas Establecer líneas base

Se establecen líneas base de los artefactos puestos bajo administración de la configuración.

Identificar ítems de configuración. Establecer un sistema de administración de la configuración. Crear o liberar líneas base. Monitorear y controlar cambios

Los cambios a los artefactos son monitoreados y controlados.

Monitorear pedidos de cambio. Controlar ítems de configuración.

TABLA Nro. 8 ADMINISTRACIÓN DE LA CONFIGURACIÓN Esta área de proceso es, probablemente, una de las más difíciles de implementar de todas las incluidas en este nivel. Además de tener problemas para planificar y ejecutar sus actividades de acuerdo a esos planes, las organizaciones de nivel 1 suelen tener serias complicaciones para identificar y mantener las versiones correctas de sus productos y artefactos asociados.

Es bastante común encontrarse con organizaciones que tienen múltiples versiones activas de una misma aplicación, sin poder llegar a controlarlas del todo e invirtiendo ingentes recursos en arreglar los mismos problemas una y otra vez. Estas prácticas apuntan, justamente, a resolver este tipo de problemas.

41

¿Cómo se implementan? En general, será necesario contar con algún tipo de sistema (preferiblemente, total o parcialmente automatizado) que permita realizar las actividades típicas de administración de la configuración:

 Identificar ítems de configuración y mantener sus relaciones con otros ítems.

 Crear, extraer (checkout) e ingresar (checkin) ítems de configuración del/al sistema de administración de la configuración.

 Generar líneas base en determinados hitos del proyecto.

 Auditar ítems, líneas base y el sistema de administración de la configuración.

 Elevar, analizar y aprobar pedidos de cambio.

La introducción de una herramienta de este tipo tendrá un impacto importantísimo en el trabajo diario de todos los miembros del proyecto (o de la organización, dependiendo de su alcance), sobre todo en la de los desarrolladores.

3.1.7 ADMINISTRACIÓN DE ACUERDOS CON PROVEEDORES (SAM)

Esta área de proceso apunta a resolver otro de los problemas habituales en muchas organizaciones: el de la tercerización.

Si bien está originalmente pensada para todo lo relacionado con la adquisición de productos que vayan a ser incorporados en la solución a entregar al cliente, las prácticas incluidas aquí también sirven para todo aquello que sea necesario comprar pero que no será finalmente entregado al cliente, como por ejemplo herramientas de desarrollo.

42

Los objetivos y prácticas del área son las que se indican en el siguiente tabla Nro. 9:

Objetivos Específicos Prácticas Específicas Establecer acuerdos con proveedores

Se establecen y mantienen acuerdos con proveedores.

 Determinar tipo de adquisición.

 Seleccionar proveedores.

 Establecer acuerdos con proveedores.

Satisfacer acuerdos con proveedores Los acuerdos con los proveedores son satisfechos por el proyecto y por los proveedores.

 Revisar productos adquiridos.

 Ejecutar acuerdos con proveedores.

 Aceptar el producto adquirido

 Transicionar productos.

TABLA Nro. 9 ADMINISTRACIÓN DE ACUERDOS CON PROVEEDORES

Para poner en práctica esta área de proceso será necesario definir los mecanismos mediante los cuales:

 Se seleccionarán los potenciales proveedores (por ejemplo, mediante un proceso que implique le creación de RFIs y RFPs);

 Se elegirán los proveedores que suministrarán al proyecto los productos/servicios necesarios.

 Se formalizarán los acuerdos con los proveedores (por ejemplo, mediante un contrato o mediante un acuerdo de nivel de servicio).

 Se formalizará la entrega de los requerimientos al proveedor.

 Se formalizará la recepción del producto/servicio solicitado al proveedor, y los correspondientes criterios de aceptación.

En el nivel 3 existe un área de proceso llamada Análisis y Toma de Decisiones (DAR) que propone un enfoque formal para la toma de decisiones, el cual podría ser empleado para seleccionar proveedores seguramente, una vez arribados a dicho nivel.

Es importante aclarar que:

43

 Los proveedores de los que habla el área de proceso no necesariamente pertenecen a otra empresa u organización; todo grupo que deba suministrar productos y servicios al proyecto (inclusive, otros proyectos) puede ser considerado un proveedor. Será necesario, entonces, formalizar con ellos el acuerdo.

 Si la solución a entregar al cliente necesitará de algún tipo de producto COTS (por ejemplo, un motor de base de datos o algún tipo de componente puntual), también será necesario formalizar el acuerdo con el proveedor correspondiente.

3.2 ÁREAS DE PROCESO DE NIVEL 3

Para alcanzar este nivel de madurez deben ser formalizadas las actividades de ingeniería del producto (diseño, desarrollo, verificación, etc.) y ser adoptadas prácticas de gestión de proyectos más avanzadas (por ejemplo, gestión de riesgos).

También deben definirse procesos, procedimientos y estándares más detallados que, a diferencia del nivel anterior, tendrán alcance organizacional.

Adicionalmente, tienen que ser establecidas las estructuras y los mecanismos necesarios para instrumentar la mejora continúa de procesos (por ejemplo, el SEPG, los TWGs, etc.).

En este nivel de madurez hay un total de catorce áreas de proceso, dos de ellas específicas para IPPD y una puntualmente necesaria para SS. 3.2.1 DESARROLLO DE REQUERIMIENTOS (RD)

En el nivel anterior nuestra preocupación pasaba más por administrar los requerimientos que por tener una manera estándar para identificarlos y especificarlos. Justamente es esta área de proceso la encargada de