white paper 2006 - · pdf filefig. 12 dominios y procesos de cobit ... los cinco niveles de...

White Paper 2006 Una Introducción a CMMI

Whi

te P

aper

200

6

Contenidos

INTRODUCCIÓN............................................................................................................................. 4 NIVELES DE MADUREZ Y ÁREAS DE PROCESO..............................................................................................4 UN MODELO DE REFERENCIA NO ES LA DESCRIPCIÓN DE UN PROCESO .................................................................7

PROCESOS ESTADÍSTICAMENTE CONTROLADOS............................................................................ 7 ESTABILIDAD DEL PROCESO...................................................................................................................9

LOS CINCO NIVELES DE MADUREZ............................................................................................... 11

ARQUITECTURA DEL MODELO ...................................................................................................... 12 OBJETIVOS Y PRÁCTICAS GENÉRICAS .....................................................................................................12 OBJETIVOS Y PRÁCTICAS ESPECÍFICAS ....................................................................................................13 DISCIPLINAS ..................................................................................................................................13

ÁREAS DE PROCESO DE NIVEL 2 .................................................................................................. 15 ADMINISTRACIÓN DE REQUERIMIENTOS (REQM).......................................................................................15 PLANIFICACIÓN DEL PROYECTO (PP)......................................................................................................17 MONITOREO Y CONTROL DEL PROYECTO (PMC).........................................................................................18 MEDICIÓN Y ANÁLISIS (MA) ...............................................................................................................19 ASEGURAMIENTO DE LA CALIDAD DE PRODUCTOS Y PROCESOS (PPQA)............................................................19 ADMINISTRACIÓN DE LA CONFIGURACIÓN (CM) ........................................................................................21 ADMINISTRACIÓN DE ACUERDOS CON PROVEEDORES (SAM).........................................................................22

ÁREAS DE PROCESO DE NIVEL 3 .................................................................................................. 24 DESARROLLO DE REQUERIMIENTOS (RD) ................................................................................................24 SOLUCIÓN TÉCNICA (TS)...................................................................................................................25 INTEGRACIÓN DEL PRODUCTO (PI)........................................................................................................26 VERIFICACIÓN (VE) .........................................................................................................................26 VALIDACIÓN (VA) ...........................................................................................................................29 ENFOQUE ORGANIZACIONAL EN EL PROCESO (OPF) ...................................................................................29 DEFINICIÓN ORGANIZACIONAL DEL PROCESO (OPD) ..................................................................................31 ENTRENAMIENTO ORGANIZACIONAL (OT)................................................................................................32 GESTIÓN DEL RIESGO (RSKM)............................................................................................................33 ANÁLISIS Y TOMA DE DECISIONES (DAR) ...............................................................................................34 ADMINISTRACIÓN INTEGRADA DEL PROYECTO (IPM)...................................................................................35 GESTIÓN INTEGRADA DE PROVEEDORES (SS) (ISM)..................................................................................36 AMBIENTE ORGANIZACIONAL PARA LA INTEGRACIÓN (IPPD) (OEI).................................................................37 EQUIPO INTEGRADO (IPPD) (IT) .........................................................................................................38

ÁREAS DE PROCESO DE NIVEL 4 .................................................................................................. 39 DESEMPEÑO DEL PROCESO DE LA ORGANIZACIÓN (OPP) .............................................................................39 ADMINISTRACIÓN CUANTITATIVA DE PROYECTOS (QPM)..............................................................................40

ÁREAS DE PROCESO DE NIVEL 5 .................................................................................................. 42 INNOVACIÓN ORGANIZACIONAL Y DESPLIEGUE (OID)..................................................................................42 ANÁLISIS Y RESOLUCIÓN DE CAUSAS DE DEFECTOS/PROBLEMAS (CAR).............................................................43

DEFINIENDO LOS PROCESOS DE LA ORGANIZACIÓN................................................................... 45

1

OTROS ESTÁNDARES Y MODELOS DE REFERENCIA ...................................................................... 46 ISO 9001:2000............................................................................................................................46 COBIT .........................................................................................................................................47 ITIL ............................................................................................................................................48 ESCM..........................................................................................................................................49 INTEGRANDO LOS MODELOS ................................................................................................................51

CONCLUSIONES ........................................................................................................................... 52

GLOSARIO ................................................................................................................................... 54

REFERENCIAS .............................................................................................................................. 55

2

Figuras y Tablas

Fig. 1: Niveles de Madurez..................................................................................................................5 Fig. 2: Áreas de Proceso por Nivel de Madurez ......................................................................................6 Fig. 3: Áreas de Proceso por Categoría .................................................................................................7 Fig. 4: Un ejemplo de gráfico de control ...............................................................................................8 Fig. 5: Variación debida a causas comunes .........................................................................................10 Fig. 6: Variación debida a causas especiales........................................................................................10 Fig. 7: Estructura de la representación por niveles...............................................................................13 Fig. 8: Técnica de inspección.............................................................................................................28 Fig. 9: Un diagrama de Pareto...........................................................................................................44 Fig. 10: Un diagrama de causa-efecto o de Ishikawa............................................................................45 Fig. 11: Relación entre CMMI e ISO 9001:2000 ...................................................................................47 Fig. 12 Dominios y procesos de CobIT ................................................................................................48 Fig. 13: Procesos de ITIL ..................................................................................................................49 Fig. 14: Fases y áreas de capacidad de eSCM......................................................................................50

Tabla 1: Comparación entre CMMI, ISO 9001, CobIT, ITIL y eSCM.........................................................51

3

Introducción El Capability Maturity Model Integration (CMMISMi de aquí en adelante)1 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)2, ,3 ii

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.

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. 1) 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.

i CMMI es servicio registrado de Carnegie Mellon University.

ii Otros modelos de madurez son: SA-CMM (Software acquisition), P-CMM (People CMM), SE-CMM (Systems Engineering).

4

Fig. 1: Niveles de Madurez

Como puede apreciarse en la Fig. 2, 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).

5

Fig. 2: Áreas de Proceso por Nivel de Madureziii

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. 3) 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).

iii Para facilitar la referencia al modelo, hemos dejado en el gráfico las áreas de proceso con sus iniciales y nombres en inglés.

6

Fig. 3: Áreas de Proceso por Categoría

Un modelo de referencia no es la descripción de un proceso Llegados a este punto, es importante hacer una aclaración: CMMI, como su nombre lo indica, es un modelo que propone un conjunto de best practices que pueden emplearse para evaluar y mejorar procesos; de ninguna manera debe suponerse que estamos ante la descripción de un proceso. Será nuestro trabajo definir el proceso productivo de nuestra organización –que seguramente tendrá una estructura completamente diferente a la de CMMI- de manera tal que cumpla con los atributos y mejores prácticas propuestos por el modelo.

Procesos Estadísticamente Controlados Uno de los principios fundamentales de la calidad total –sobre los cuales está basado este modelo- es el de control estadístico de procesos. Según él, la variabilidad de un proceso puede ser controlada y, por consiguiente, sus resultados pueden ser

7

predecibles4. Que los resultados de un proceso sean predecibles no quiere decir que sean idénticos, sino que estos variarán dentro de límites conocidos.

Veamos un ejemplo tomado de Practical Software Measurement. Un grupo de trabajo es responsable del desarrollo de una nueva versión de una aplicación, mientras que al mismo tiempo debe dar soporte a los usuarios de la vieja versión. El proyecto ha sido planificado bajo el supuesto de que serían necesarias 40 horas-hombre diarias de soporte.

Luego de finalizado el proyecto, y con la información de la cantidad real de horas incurridas diariamente en actividades de soporte, se realiza el siguiente grafo de control (ver Fig. 4), en el que podemos observar su evolución a lo largo de las dieciséis semanas del periodo.

Fig. 4: Un ejemplo de gráfico de control

No es nuestro propósito en adentrarnos en el detalle de cómo construir este tipo de gráficos; por el momento diremos que, luego de realizado el análisis, podemos afirmar que el esfuerzo aplicado a actividades de soporte durante las dieciséis semanas que duró el proyecto estuvo en torno a las 45.03 horas-hombre por día (la línea punteada identificada en el gráfico como CL=45.03). Mediante un cálculo que forma parte de esta técnica podemos, además, determinar los límites inferior y superior del proceso (LCL=40.66 y UCL=49.41, respectivamente), los que corresponden a +/- 3 desviaciones estándariv.

Para determinar si el proceso se encuentra estadísticamente controlado debemos

iv La desviación estándar (sigma) es la ‘dispersión’ de una distribución normal. Por regla sabemos que el 99.74% de superficie por debajo de la curva normal debería estar dentro de +/- 3 veces sigma.

8

verificar si en el gráfico se cumplen o no una serie de reglas. Para ello será necesario identificar tres zonas en el gráfico, llamadas A, B y C. Cada una de las zonas representa, respectivamente, la distancia entre la media y +/- una, dos y tres desviaciones estándar (o sea, deberíamos dividir en tres zonas iguales la distancia entre la media y los límites inferior y superior) Un proceso estará fuera de control si se cumple alguna o varias de las siguientes reglas:

Dos de tres puntos consecutivos están en la zona “C”

Cuatro de cinco puntos consecutivos al mismo lado de la línea central en las zonas “B” y “C”.

Nueve puntos consecutivos están por encima o por debajo del promedio.

Hay seis puntos consecutivos crecientes o decrecientes.

Hay catorce puntos consecutivos alternándose arriba y abajo del promedio.

Hay quince puntos consecutivos dentro de la zona “A”. De acuerdo a lo que podemos observar, el gráfico de la Fig. 4 no cumple con ninguna de estas reglas, con lo cual estamos en condiciones de afirmar que se encuentra estadísticamente controlado. En otras palabras, la estimación de 40 horas-hombre fue más que aceptable.

Estabilidad del proceso Las características de todos los procesos y productos presentan algún tipo de variación cuando las medimos a lo largo del tiempo. Dicha variación puede tener dos fuentes: la misma naturaleza del proceso (la variación normal o natural del proceso, relacionada con la interacción entre sus distintos componentes –personal, maquinaria, materiales, métodos y ambiente-) por un lado, y las causas relacionadas con alguna causa específica por el otro (las variaciones especiales).v

La variación normal del proceso (llamada causa común de variación) tiene un comportamiento al azar, pero con un patrón estable y dentro de ciertos límites (ver Fig. 5 [reproducida de Practical Software Measurement]) Si un proceso presenta únicamente este tipo de variación estaremos ante un proceso estadísticamente controlado.

v Ver la sección Glosario para una definición formal de causas especiales y comunes.

9

Fig. 5: Variación debida a causas comunes

La variación especial, por el contrario, no tiene un patrón de comportamiento que pueda ser identificado (ver Fig. 6, reproducida de la misma obra) El impacto de este tipo de variaciones en la performance del proceso y en las características del producto son importantísimos, a tal punto que es imposible predecir los resultados.

Fig. 6: Variación debida a causas especiales

Las variaciones especiales no tienen su origen en el proceso, sino en causas externas tales como el medio ambiente, el material de input al proceso, personal no capacitado, métodos o herramientas incorrectamente usados, etc.

Una vez que las variaciones originadas en causas especiales sean removidas, nos encontraremos con un proceso estable (estadísticamente controlado) Una vez alcanzado este estado, podremos optimizar el proceso, reduciendo la variabilidad o “corriendo” la media.

Como veremos en las próximas secciones, las organizaciones de nivel de madurez 5 de CMMI se esfuerzan en remover las causas comunes, mientras que las de nivel 4 se enfocan en remover las especiales.

10

Los Cinco Niveles de Madurez En general, los niveles de madurez suelen explicarse en orden creciente; tomaremos aquí una dirección distinta y los explicaremos exactamente al revés: desde el nivel cinco al nivel uno.

Imaginémonos por un momento que estamos en una organización de nivel cinco. En este tipo de organizaciones, como dijimos en la sección anterior, los procesos son analizados para eliminar las causas comunes de variación, o sea, aquellas que tienen que ver con la misma naturaleza del proceso, no atribuibles a causas externas. Las variaciones en las salidas de los procesos son al azar, pero se encuentran controladas estadísticamente (podemos predecir los resultados de los procesos con cierto nivel de confiabilidad)

Para poder haber arribado a este nivel, la organización debería primero haber eliminado las causas especiales de variación, aquellas que tienen que ver con causas externas, como por ejemplo falta de entrenamiento del personal, problemas con las herramientas, etc. Este tipo de causas no son aleatorias: Si examináramos los resultados podríamos ver las tendencias que claramente nos indicarían que las variaciones tienen un origen concreto. En una organización de nivel cuatro, entonces, las causas especiales de variación son identificadas y eliminadas.

Para poder llegar a identificar causas de variación necesitamos tener un proceso estándar: difícil sería poner bajo control estadístico un proceso que no se encuentre mínimamente formalizado.

Así llegamos al nivel tres, en el cual los proyectos emplean un proceso productivo adaptado del proceso estándar de la organización. Las actividades técnicas y de gestión son realizadas de acuerdo a políticas, procesos y procedimientos formalizados en algún tipo de estándar organizacional profundamente arraigado en la cultura. La gente está entrenada y dispone de recursos para poder hacer su trabajo. También hay una infraestructura básica (personal, herramientas, etc.) para definir y mejorar el proceso productivo.

Pero para poder arribar a semejante situación es necesario pasar por una etapa previa: difícilmente podamos introducir en una organización prácticas estándar relacionadas con la ingeniería del producto (análisis, diseño, etc.) si no ofrecemos un contexto en donde ellas puedan ser correctamente ejecutadas. Ese es el foco del nivel dos: poner en orden las prácticas relacionadas con el manejo elemental de los proyectos.

En el nivel dos, los proyectos de la organización siguen algún tipo de proceso para realizar las actividades relacionadas con la gestión del proyecto (planificación, control), para administrar los requerimientos y las configuraciones, y para medir y analizar la calidad de los productos y el desempeño de los procesos. También hay prácticas de aseguramiento de la calidad que permiten garantizar que cada proyecto sigue sus propios estándares.

11

En el nivel dos no importan tanto las técnicas y los métodos que empleemos para desarrollar y construir nuestros productos y servicios: Lo importante es que podamos tener un mínimo de capacidad de gestión de proyectos.

Y así llegamos al nivel uno: La situación aquí es caótica. No tenemos procesos (no al menos en el sentido del modelo) y la performance de los proyectos depende profundamente de la buena voluntad y la capacidad de la gente.

Arquitectura del Modelo En la representación por niveles (ver Fig. 7), 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.

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 (GG) y las prácticas genéricas (GP) son los siguientes:

GG 2 Institucionalizar un proceso administrado > GP 2.1 Establecer políticas organizacionales > GP 2.2 Planificar el proceso > GP 2.3 Proveer Recursos > GP 2.4 Asignar responsabilidades > GP 2.5 Entrenar al personal > GP 2.6 Administrar la configuración > GP 2.7 Identificar e involucrar a los interesados > GP 2.8 Monitorear y controlar los procesos > GP 2.9 Evaluar adhesión objetivamente > GP 2.10 Revisar el estado con la alta gerencia

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

GG 3 Institucionalizar un proceso definido > GP 3.1 Establecer un proceso definido > GP 3.2 Recolectar información para mejoras

12

Fig. 7: Estructura de la representación por niveles

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. Por ejemplo, en el área Administración de Requerimientos (REQM), los objetivos y prácticas son las siguientes:

Objetivo Específico Prácticas Específicas

SG 1 Administrar Requerimientos

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

SP 1.1 Comprender el significado de los requerimientos

SP 1.2 Obtener compromiso de los participantes/interesados acerca de los requerimientos

SP 1.3 Administrar cambios a los requerimientos

SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos

SP 1.5 Identificar inconsistencias entre los requerimientos y otros productos del proyecto

Disciplinas El modelo incluye cuatro cuerpos de conocimiento distintos: ingeniería de software, ingeniería de sistemas, desarrollo integrado de productos y procesos, y adquisición de

13

productos. Si bien el modelo es esencialmente el mismo para las cuatro disciplinas, en algunas de ellas se agregan á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 son sus siglas en inglés) 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, por su denominación en inglés) 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). 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.vi

vi Para mayor información respecto a IPPD puede consultarse http://www.npd-solutions.com/ippdtenets.html

14

Á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 describimos rápidamente en las próximas secciones.

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.

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?).

En esta área hay solamente un objetivo específico –SG 1 Administrar Requerimientos-y

15

cinco prácticas:


SG 1 Administrar Requerimientos

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

SP 1.1 Comprender el significado de los requerimientos

SP 1.2 Obtener compromiso de los participantes/interesados acerca de los requerimientos

SP 1.3 Administrar cambios a los requerimientos

SP 1.4 Mantener la trazabilidad bidireccional de los requerimientos

SP 1.5 Identificar inconsistencias entre los requerimientos y otros productos del proyecto

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 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)

16

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. Sus objetivos y prácticas específicas son las siguientes:

Objetivos Específicos Prácticas Específicas

SG 1 Establecer estimaciones Se realizan y mantienen estimaciones de las magnitudes del proyecto.

SP 1.1 Estimar el alcance del proyecto

SP 1.2 Estimar atributos de las tareas y de los productos del proyecto

SP 1.3 Definir el ciclo de vida del proyecto

SP 1.4 Estimar esfuerzo y costo del proyecto

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

SP 2.1 Establecer el cronograma y el presupuesto del proyecto

SP 2.2 Identificar los riesgos del proyecto

SP 2.3 Planificar la administración de datos del proyecto

SP 2.4 Planificar recursos necesarios para el proyecto

SP 2.5 Planificar la adquisición de conocimiento y habilidades

SP 2.6 Planificar la participación de los interesados en el proyecto

SP 2.7 Establecer el plan del proyecto

SG 3 Obtener el compromiso de los interesados acerca del plan de proyecto Los compromisos con el plan están formalmente establecidos y son mantenidos a lo largo del proyecto.

SP 3.1 Revisar todos los planes que puedan afectar al proyecto

SP 3.2 Ajustar el plan de proyecto para reflejar recursos estimados vs. disponibles

SP 3.3 Obtener compromisos respecto al plan

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

17

Proyecto (PMC))

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.


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

SP 1.1 Monitorear los parámetros de planificación del proyecto

SP 1.2 Monitorear los compromisos

SP 1.3 Monitorear los riesgos del proyecto

SP 1.4 Monitorear la administración de datos del proyecto

SP 1.5 Monitorear la participación de los interesados

SP 1.6 Conducir revisiones de avance

SP 1.7 Conducir revisiones de cumplimiento de hitos

SG 2 Gestionar Acciones Correctivas Cuando los resultados o la performance del proyecto se desvian significativamente del plan se gestionan acciones correctivas.

SP 2.1 Analizar temas pendientes

SP 2.2 Ejecutar acciones correctivas

SP 2.3 Administrar acciones correctivas

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.

18

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, 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 son las siguientes:


SG 1 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.

SP 1.1 Establecer objetivos de las mediciones

SP 1.2 Especificar métricas

SP 1.3 Especificar procedimientos de recolección y almacenamiento de datos

SP 1.4 Especificar procedimientos de análisis

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

SP 2.1 Recolectar datos

SP 2.2 Analizar datos

SP 2.3 Almacenar datos y resultados

SP 2.4 Comunicar resultados

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.)

Un enfoque muy interesante que puede emplearse para implementar los indicadores del segundo grupo es el balanced scorecard propuesto por Kaplan y Norton.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:

19

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 (ver el Glosario para una definición de control y aseguramiento de la calidad).

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 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 son lo siguientes:


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

SP 1.1 Evaluar procesos objetivamente

SP 1.2 Evaluar productos y servicios objetivamente

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

SP 2.1 Comunicar y asegurar la resolución de cuestiones de calidad

SP 2.2 Establecer y mantener registros de las actividades de aseguramiento de la calidad

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 auditoría).

vii 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).

20

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.

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.

Los objetivos y prácticas incluidas son los siguientes:


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

SP 1.1 Identificar ítems de configuración

SP 1.2 Establecer un sistema de administración de la configuración

SP 1.3 Crear o liberar líneas base

SG 2 Monitorear y controlar cambios Los cambios a los artefactos son monitoreados y controlados.

SP 2.1 Monitorear pedidos de cambio

SP 2.2 Controlar ítems de 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.

¿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;

21

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.

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.

Los objetivos y prácticas del área son las que se indican en el siguiente cuadro:


SG 1 Establecer acuerdos con proveedores Se establecen y mantienen acuerdos con proveedores.

SP 1.1 Determinar tipo de adquisición

SP 1.2 Seleccionar proveedores

SP 1.3 Establecer acuerdos con proveedores

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

SP 2.1 Revisar productos adquiridos

SP 2.2 Ejecutar acuerdos con proveedores

SP 2.3 Aceptar el producto adquirido

SP 2.4 Transicionar productos

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;viii

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

viii 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-.

22

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.

Es importante aclarar que:

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 COTSix (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.

ix Ver el Glosario.

23

Á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 continua de procesos (por ejemplo, el SEPG, los TWGs, etc.)x

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.

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 producir y analizar los requerimientos del cliente, del producto, y de las componentes del producto.

El área incluye tres objetivos específicos y diez prácticas específicas:


SG1 Desarrollar Requerimientos del Cliente Se relevan las necesidades, expectativas, restricciones e interfaces y se traducen en requerimientos del cliente.

SP 1.1 Relevar Necesidades

SP 1.2 Desarrollar los Requerimientos del Cliente

SG2 Desarrollar los Requerimientos del Producto Los requerimientos del cliente son refinados y elaborados para obtener los requerimientos del producto y sus componentes.

SP 2.1 Establecer Requerimientos del Producto y sus Componentes

SP 2.2 Asignar Requerimientos a las Componentes del Producto

SP 2.3 Identificar Requerimientos de Interfaz

SG3 Analizar y Validar Requerimientos Los requerimientos son analizados y validados, y se desarrolla una definición de la funcionalidad requerida.

SP 3.1 Desarrollar Concepto de Operación y Escenarios

SP 3.2 Desarrollar una Definición de la Funcionalidad Requerida

SP 3.3 Analizar Requerimientos

SP 3.4 Analizar Requerimientos para Balancear Necesidades y Restricciones

SP 3.5 Validar Requerimientos

x Estos dos últimos puntos –la definición más detallada de procesos y el establecimiento de la mejora continua- están soportados por el objetivo GG3 y las prácticas genéricas GP 3.1 y 3.2, correspondientes a este nivel.

24

Esta área suele implementarse mediante la adopción de técnicas de relevamiento y análisis de requerimientos, como por ejemplo prototipado, escenarios de operación, casos de uso, etc. Más allá de las técnicas elegidas es importante que se formalice:

Cómo se obtendrán los requerimientos del usuario;

Cómo se refinarán dichos requerimientos hasta obtener los del producto y los correspondientes a sus componentes;

Cómo se especificarán, analizarán y validarán los requerimientos.

Solución Técnica (TS) En el nivel 2 no importaba tanto formalizar el diseño y la construcción del producto; una vez que la organización ha arribado a este nivel necesitaremos hacerlo.

Esta área de proceso incluye todas las actividades necesarias para:

Identificar y seleccionar una solución a los requerimientos;

Desarrollar el diseño del producto;

Implementar el diseño y obtener el producto.

Los objetivos y prácticas del área son las siguientes:


SG1 Seleccionar Soluciones Soluciones para el producto o para sus componentes son seleccionadas.

SP 1.1 Desarrollar Soluciones Alternativas y Criterios de Selección

SP 1.2 Evolucionar Conceptos Operacionales y Escenarios

SP 1.3 Seleccionar Soluciones

SG2 Desarrollar el Diseño Se diseñan el producto y sus componentes.

SP 2.1 Diseñar el Producto y las Componentes

SP 2.2 Desarrollar un Paquete Técnico de Datos

SP 2.3 Diseñar Interfaces

SP 2.4 Realizar Análisis de Construir, Reusar o Comprar

SG3 Implementar el Diseño del Producto Las componentes del producto y la documentación de soporte son desarrolladas a partir del diseño.

SP 3.1 Implementar el Diseño

SP 3.2 Desarrollar la Documentación de Soporte

La implementación de las actividades aquí descriptas es bastante compleja. En parte, los objetivos específicos quedarían satisfechos de poner en práctica alguna técnica o método de diseño y programación particular (diseño orientado a objetos, patrones de diseño, etc.) que permitan obtener el producto deseado a partir de los requerimientos y respetando el plan de proyecto. Hay que ser muy cuidadoso para no formalizar la

25

práctica más allá de lo recomendable.

También será necesario formalizar la evaluación de las posibles alternativas de solución a los requerimientos (ver Análisis y Toma de Decisiones (DAR) para un enfoque formal de toma de decisiones)

Integración del Producto (PI) El propósito de esta área de proceso es ensamblar el producto a partir de sus componentes, garantizando que su funcionamiento sea el previsto. Tiene tres objetivos y ocho prácticas específicas:


SG1 Preparar la Integración del Producto Se prepara la integración del producto a partir de sus componentes.

SP 1.1 Determinar la Secuencia de Integración

SP 1.2 Establecer el Ambiente de Integración

SP 1.3 Establecer Procedimientos y Criterios de Integración

SG2 Garantizar la Compatibilidad de las Interfaces Las interfaces internas y externas son compatibles.

SP 2.1 Revisar las Descripciones de las Interfaces

SP 2.2 Administrar Interfaces

SG3 Ensamblar las Componentes y Liberar el Producto Las componentes verificadas son ensambladas y el producto integrado, verificado y validado es entregado.

SP 3.1 Confirmar Aptitud de Componentes para la Integración

SP 3.2 Ensamblar las Componentes del Producto

SP 3.3 Evaluar los Componentes Ensamblados

SP 3.4 Empaquetar y Entregar el Producto o Componente

Esta área se puede implementar mediante la definición de procedimientos para mantener bajo control las interfaces internas y externas (probablemente, uno de los problemas más habituales en el desarrollo de software) y para integrar periódicamente el producto (las prácticas de daily build y smoke test propuestas por Microsoft son un ejemplo típico de integración progresiva). Quizás el aspecto más complicado de poner en marcha sea el de disponer de un ambiente de integración estable; sin embargo, de contar con un buen sistema de administración de la configuración que permita identificar distintos ambientes (desarrollo, integración, prueba, etc.), la implementación se facilita notablemente.

Verificación (VE) Esta área de proceso tiene como objetivo garantizar que los artefactos seleccionados cumplan con los requerimientos asignados. Similar en ciertos aspectos a Validación (VA) esta área de proceso apunta a evaluar si el producto final y los productos intermedios del proyecto cumplen con los requerimientos del cliente, del producto, y

26

de las componentes del producto. Sus objetivos y prácticas son las siguientes:


SG1 Preparar la Verificación Se prepara la verificación de los artefactos.

SP 1.1 Seleccionar Artefactos para su Verificación

SP 1.2 Establecer el Ambiente de Verificación

SP 1.3 Establecer Procedimientos y Criterios de Verificación

SG2 Realizar Revisiones de Pares Se realizan revisiones de pares sobre artefactos seleccionados.

SP 2.1 Preparar la Revisión de Pares

SP 2.2 Conducir la Revisión de Pares

SP 2.3 Analizar Datos de la Revisión de Pares

SG3 Verificar Artefactos Seleccionados Artefactos seleccionados son verificados versus los requerimientos especificados.

SP 3.1 Realizar la Verificación

SP 3.2 Analizar los resultados de la Verificación e Identificar Acciones Correctivas

Las técnicas empleadas para realizar la verificación pueden ser similares a las utilizadas en la validación (inspecciones, revisiones, pruebas, etc.); sin embargo, el propósito de esta área es determinar si estamos construyendo el producto correctamente.

La verificación siempre es progresiva: a lo largo del ciclo de vida del proyecto tendremos varios momentos en los cuales revisaremos los resultados de las actividades con el propósito de comprobar si cumplen o no con los requerimientos que les han sido asignados (por ejemplo, si la salida de la actividad de diseño cumple con los requerimientos asignados a dicha actividad). De esta manera se detectan problemas tempranamente y se evita que lleguen al producto final.

Uno de los mecanismos para realizar verificaciones que propone el modelo es el de revisión de pares. En este tipo de revisiones, pares del productor o autor de un artefacto lo revisan con el propósito de identificar defectos o cambios. Una técnica de revisión de pares muy popular es la de inspecciones (ver Fig. 8).

27

Fig. 8: Técnica de inspección

Para implementar esta área de proceso es necesario identificar puntos clave en donde realizar las revisiones, y las técnicas correspondientes para hacerlo. También será necesario disponer de un ambiente para realizar la verificación (esto se ve muy claro cuando la verificación involucre algún tipo de testing).

Aquí van algunos ejemplos:

Al final de la primer fase del proyecto, en donde se define el alcance y se establece el plan, inspeccionar los artefactos relacionados con la funcionalidad a desarrollar (acuerdo de proyecto, visión, especificación de requerimientos, etc.);

Revisar el modelo de datos y la especificación de diseño al final de las actividades de diseño;

Inspeccionar el código fuente de componentes de software clave;

Realizar pruebas de software durante la construcción;

Inspeccionar manuales de usuario y material de entrenamiento;

Etc.

28

Validación (VA) A diferencia del área de proceso anterior, ésta está enfocada en demostrar si el producto (o sus componentes) satisface las necesidades de uso en el ambiente deseado.

Así como Verificación se focaliza en determinar si ‘lo construimos bien’, Validación se ocupa de evaluar si ‘construimos el producto correcto’.

Los objetivos y prácticas específicas del área son los siguientes:


SG1 Preparar la Validación Se realiza la preparación de la validación.

SP 1.1 Seleccionar Productos para Validación

SP 1.2 Establecer el Ambiente de Validación

SP 1.3 Establecer Procedimientos y Criterios de Validación

SG2 Validar el Producto o sus Componentes El producto o sus componentes son validados para garantizar que ellos son adecuados para ser usados en el ambiente operativo deseado.

SP 2.1 Realizar la Validación

SP 2.2 Analizar los Resultados de la Validación

Verificación y validación suelen ocurrir simultáneamente y usar el mismo ambiente. A menudo, los usuarios están involucrados.

Esta área de proceso se implementa mediante la inclusión de actividades de validación en lugares clave del proceso productivo. Las técnicas y métodos a emplear podrán ser similares a los utilizados en las actividades de verificación (pruebas, revisiones, inspecciones, etc.).

Son varios los aspectos importantes que deben ser contemplados antes y durante la validación:

Ambientes para realizar la validación (por ejemplo, procesadores, redes, datos, infraestructura, etc.);

Herramientas para realizar la validación;

Personal capacitado.

Enfoque Organizacional en el Proceso (OPF) Una organización de nivel 3 debe tener un enfoque formal y disciplinado para continuamente mejorar sus procesos. Esta área –junto a Definición Organizacional del Proceso (OPD) y Entrenamiento Organizacional (OT)- contribuye a alcanzar dicho

29

objetivo.

El propósito de esta área en particular es planificar e implementar las mejoras a los procesos de la organización. OPD, por su lado, es la encargada de establecer y mantener los “activos de proceso” (políticas, descripciones de procesos y procedimientos, estándares, métricas, etc.), mientras que OT es la responsable de desarrollar los conocimientos y habilidades del personal para que puedan desempeñar sus roles de manera adecuada.

Los objetivos y prácticas específicas de esta área son:


SG1 Determinar Oportunidades de Mejora de Procesos Periódica o eventualmente se identifican fortalezas, debilidades y oportunidades de mejora a los procesos de la organización.

SP 1.1 Determinar Necesidades de los Procesos de la Organización

SP 1.2 Evaluar los Procesos de la Organización

SP 1.3 Identificar Mejoras a los Procesos de la Organización

SG2 Planificar e Implementar Actividades de Mejora Las mejoras son planeadas e implantadas, los activos de proceso son distribuídos, y se incorpora la experiencia adquirida en los activos de proceso.

SP 2.1 Establecer Planes de Acción

SP 2.2 Implementar Planes de Acción

SP 2.3 Desplegar Activos de Proceso

SP 2.4 Incorporar Experiencias Reales en los Activos de Proceso

Esta área de proceso se implementa poniendo en marcha la infraestructura básica para la mejora de procesos (SEPG, TWGs, etc.)xi, planificando las actividades de mejora, y formalizando la evaluación (appraisal) de los procesos de la organización.

Probablemente, ya desde nivel 2 exista algún tipo de infraestructura para realizar este tipo de actividades; lo que cambia es que en este nivel hay un mayor grado de formalización y compromiso.

Este tipo de iniciativas deben manejarse como proyectos ejecutados en el contexto de un programa de mejora continua a mediano plazo (de tres a cinco años), con planes tácticos de menor alcance. El modelo de mejora propuesto por el SEI es IDEAL (Initiating, Diagnosing, Establishing, Acting, Leveraging, las iniciales de las cinco fases del modelo), un proceso para ejecutar y guiar programas de este tipo.xii

Un tema crítico es la pelea por los recursos: ante la posibilidad de ejecutar un proyecto de mejoras y un proyecto más relacionado con el negocio, probablemente la balanza se inclinará a favor del último. Una manera de resolver este tipo de conflictos es tener un comité que auspicie la iniciativa, a la vez que se encuentre en funcionamiento una PMO que tenga a su cargo “balancear” la cartera de proyectos. xi Ver el Glosario.

xii Más información al respecto: http://www.sei.cmu.edu/ideal/

30

Por otro lado, las evaluaciones (los appraisals de los que habla el modelo) deben realizarse siguiendo el proceso oficial, llamado SCAMPI (Standard CMMI Appraisal Method for Process Improvement).xiii Hay tres tipos posibles (A, B y C), dependiendo del objetivo que se persiga (evaluación interna o externa, generación de rating –nivel de madurez o capacidad-). Para demostrar que una práctica específica de un área de proceso determinada se encuentra implementada, es necesario mostrar evidencias directas (resultado directo de su ejecución) e indirectas (consecuencia no directa de su implementación).

En resumen, esta área de proceso se resuelve teniendo un proceso definido para efectuar mejoras a los procesos de la organización. Ni más ni menos.

Definición Organizacional del Proceso (OPD) Esta área de proceso, complementaria de la anterior, tiene como propósito establecer y mantener un conjunto utilizable de ‘activos’ de proceso. En este contexto, un activo es cualquier elemento que forme parte de los procesos de la organización (una política, la descripción de un proceso, un estándar, la plantilla de un documento, etc.) y que sea empleado para describir, implementar y mejorar procesos.

El objetivo y las prácticas de esta área son las siguientes:


SG1 Establecer Activos de Proceso Se establece y mantiene un conjunto de activos de proceso.

SP 1.1 Definir Procesos Estándar

SP 1.2 Definir Modelos de Ciclo de Vida

SP 1.3 Definir Criterios y Guías para Adaptar Procesos

SP 1.4 Establecer Repositorio Organizacional de Métricas

SP 1.5 Establecer la Biblioteca de Activos Organizacionales de Proceso

Esta área de proceso se implementa documentando los activos y resguardándolos en algún tipo de repositorio (una intranet, un conjunto de documentos en un directorio, una base de conocimiento, etc.) que pueda ser fácilmente consultado por todos los interesados.

Usualmente, las organizaciones definen una arquitectura general en donde identifican sus grandes procesos (por ejemplo, desarrollo de software, implantación de paquetes, administración de cambios, etc.); posteriormente, cada uno de los procesos es bajado a mayor nivel de detalle (subprocesos, actividades). Para cada actividad podrán definirse técnicas (por ejemplo, cómo construir el modelo de datos) y procedimientos detallados (cómo usar una herramienta determinada para completar una tarea específica). Las actividades consumirán y producirán algún tipo de artefacto

xiii Más información: http://www.sei.cmu.edu/cmmi/appraisals/appraisals.html

31

(especificaciones, planes, modelos, componentes de software, etc.) para los cuáles existirá un estándar (por ejemplo, una plantilla). Para las actividades y artefactos se definirán, probablemente, checklists para su revisión.

Además de todo esto, el repositorio deberá incluir lineamientos para adaptar los procesos a las necesidades de cada proyecto en particular. Usualmente, también incluirá políticas, material de entrenamiento y capacitación, manuales de productos, métricas, lecciones aprendidas en otros proyectos, etc.

La experiencia ha demostrado la importancia de gestionar el conocimiento y la experiencia organizacional. Sin un adecuado manejo de estos temas será difícil comunicar y sustentar en el tiempo los procesos adoptados por la organización.xiv

Entrenamiento Organizacional (OT) Los esfuerzos de mejora deben ser complementados con el entrenamiento necesario para que todos los integrantes de la organización estén preparados para realizar su trabajo de manera adecuada. El propósito de esta área es, justamente, proveer los conocimientos y habilidades necesarios para que el personal pueda desempeñar sus roles eficaz y eficientemente, y así facilitar el cumplimiento de los objetivos estratégicos de la organización y las necesidades tácticas de los proyectos y áreas de soporte.

Sus objetivos y prácticas específicas son las siguientes:


SG1 Establecer Capacidad de Entrenamiento Organizacional Se establece y mantiene una capacidad de entrenamiento que permite desarrollar los conocimientos y habilidades necesarias para las actividades de la organización.

SP 1.1 Determinar las Necesidades Estratégicas de Entrenamiento

SP 1.2 Determinar Cuáles Necesidades de Entrenamiento son Responsabilidad de la Organización

SP 1.3 Establecer un Plan Táctico de Entrenamiento Organizacional

SP 1.4 Establecer Capacidades de Entrenamiento

SG2 Proveer el Entrenamiento Necesario Se provee el entrenamiento necesario para que las personas desempeñen efectivamente sus roles.

SP 2.1 Proveer Entrenamiento

SP 2.2 Establecer Registros del Entrenamiento

SP 2.3 Evaluar la Efectividad del Entrenamiento

Esta área de proceso normalmente se resuelve estableciendo un programa de capacitación y entrenamiento basado en los conocimientos y habilidades necesarios para que el personal pueda desempeñar los roles que les hayan sido asignados. Esto suele llevar a que la organización formalice la definición de los puestos y los planes de

xiv Un excelente enfoque para el manejo de conocimiento es el propuesto por Basili, Caldiera y Rombach en The Experience Factory: http://www.cs.umd.edu/~mvz/handouts/fact.pdf

32

carrera del personal.

El entrenamiento y la capacitación deberán incluir todos aquellos temas relacionados con los procesos de la organización y, en función de cuáles áreas de conocimiento queden en manos de cada individuo y cuáles no, todos aquellos considerados importantes para desempeñar exitosamente el puesto asignado.

Por ejemplo, una organización podría definir que sus líderes de proyecto tengan un adecuado manejo de los procesos planteados por el PMBOKxv o que sus desarrolladores satisfagan determinadas áreas de conocimiento del SWEBOK.xvi Otra alternativa sería obtener algún tipo de certificación de un ente reconocido, como por ejemplo, la certificación de Project Management Professional otorgada por el Project Management Institute, o la de Certified Software Development Professional de la IEEE Computer Society.

Gestión del Riesgo (RSKM) Esta área es una evolución de las prácticas básicas de manejo de riesgo incluidas en Planificación del Proyecto (PP) y Monitoreo y Control del Proyecto (PMC) pertenecientes al nivel 2. Aquí se plantea un enfoque sistemático para planear, anticipar y mitigar riesgos para proactivamente minimizar su impacto en el proyecto. Sus objetivos y prácticas específicas son las siguientes:


SG1 Preparar la Gestión del Riesgo Se establece y mantiene una estrategia para identificar, analizar y mitigar riesgos.

SP 1.1 Determinar Fuentes y Categorías de Riesgo

SP 1.2 Definir Parámetros de Riesgo

SP 1.3 Establecer una Estrategia para la Gestión del Riesgo

SG2 Identificar y Analizar Riesgos Los riesgos son identificados y analizados para determinar su importancia relativa.

SP 2.1 Identificar Riesgos

SP 2.2 Evaluar, Categorizar y Priorizar Riesgos

SG3 Mitigar Riesgos Los riesgos son manejados y mitigados para reducir su impacto negativo en los objetivos.

SP 3.1 Desarrollar Planes de Mitigación de Riesgo

SP 3.2 Implementar Planes de Mitigación de Riesgo

Los objetivos de esta área se satisfacen mediante la puesta en marcha de mecanismos formales para manejar los riesgos. En este nivel no basta simplemente con identificarlos (ver la SP 2.2 de Planificación del Proyecto (PP)) y administrarlos en la medida que vayan ocurriendo; aquí será necesario establecer un proceso para definir y ejecutar una estrategia para gestionarlos.

Por ejemplo, podría establecerse un esquema de clasificación de riesgos y posibles xv Project Management Body of Knowledge: http;//www.pmi.org

xvi Software Engineering Body of Knowledge: http://www.swebok.org

33

respuestas basado en experiencias anteriores. También podrían identificarse probabilidades de ocurrencia y magnitudes de impacto en función de aspectos técnicos y de gestión, basados en lo ocurrido en proyectos previos.

En resumen, una organización de nivel 3 debe proponerse tener un enfoque mucho más formal para identificar riesgos y clasificarlos, y para planear posibles acciones de mitigación y contingencia.xvii

Análisis y Toma de Decisiones (DAR) Esta área tiene como propósito que determinadas decisiones sean tomadas de acuerdo a un proceso formal. Por ejemplo, decidir entre distintas alternativas de solución, o seleccionar un producto o un proveedor, son todas decisiones que podrían tomarse mediante un proceso formal compatible con los objetivos y prácticas de esta área de proceso.

Cuando hablamos de un proceso de evaluación formal nos estaremos refiriendo a un enfoque estructurado para evaluar alternativas y recomendar una solución a un problema determinado. Esto implica que se deberán:

Establecer criterios (qué decisiones es recomendable que pasen por este proceso y cuáles no, cuáles son los criterios de evaluación, etc.);

Identificar soluciones alternativas;

Determinar métodos para evaluarlas;

Evaluar las soluciones alternativas y recomendar una de ellas.

El área tiene un único objetivo específico y seis prácticas:


SG 1 Evaluar Alternativas Las decisiones están basadas en la evaluación de alternativas usando criterios establecidos.

SP 1.1 Establecer Lineamientos para el Análisis de Decisiones

SP 1.2 Establecer Criterios de Evaluación

SP 1.3 Identificar Soluciones Alternativas

SP 1.4 Seleccionar Métodos de Evaluación

SP 1.5 Evaluar Alternativas

SP 1.6 Seleccionar Soluciones

Estas prácticas se implementan mediante la definición y uso de un procedimiento (o de varios, según el caso) mediante el cual determinados tipos de decisiones sean tomadas. Por ejemplo, podría plantearse un procedimiento que haga uso de una matriz

xvii Un enfoque muy interesante es el Software Risk Evaluation Method propuesto por el SEI: http://www.sei.cmu.edu/risk/main.html

34

de criterios de selección para evaluar potenciales proveedores o productos. Ídem para decisiones relacionadas con temas técnicos (por ejemplo, diseños o arquitecturas alternativas).

Lo más interesante de esta área de proceso, además de proveer un marco para un análisis racional de alternativas, es que otorga transparencia al proceso decisorio. Probablemente, una de las áreas de proceso más difíciles de implementar.

Administración Integrada del Proyecto (IPM) Junto a Gestión del Riesgo (RSKM) y Equipo Integrado (IPPD) (IT), esta es una de las áreas de gestión avanzada de proyectos incluidas en el nivel 3. Elaborada sobre las prácticas del nivel anterior, su propósito es administrar el proyecto y el involucramiento de todos los interesados mediante un proceso que, basado en el proceso estándar de la organización, ha sido adaptado a las necesidades particulares del proyecto.

El área tiene cuatro objetivos, dos de ellos válidos solamente si se está usando la disciplina IPPD (ver la sección Disciplinas). Los objetivos y prácticas son los siguientes:


SG 1 Usar el Proceso Definido para el Proyecto El proyecto es dirigido usando un proceso definido, adaptado del conjunto de estándares de proceso de la organización.

SP 1.1 Establecer el Proceso Definido para el Proyecto

SP 1.2 Usar los Activos de Proceso de la Organización para planificar las actividades del proyecto.

SP 1.3 Integrar Planes

SP 1.4 Gerenciar el Proyecto Usando Planes Integrados

SP 1.5 Contribuir a los Activos de Proceso de la Organización

SG 2 Coordinar y Colaborar con los Interesados La coordinación y la colaboración del proyecto y los interesados es manejada adecuadamente.

SP 2.1 Administrar el Involucramiento de los Interesados

SP 2.2 Administrar Dependencias

SP 2.3 Resolver Problemas de Coordinación

SG 3 Usar la Visión Compartida del Proyecto (sólo para IPPD) El proyecto es dirigido empleando la visión compartida del proyecto.

SP 3.1 Definir el Contexto de la Visión Compartida del Proyecto.

SP 3.2 Establecer la Visión Compartida del Proyecto.

SG 4 Organizar Equipos Integrados (sólo para IPPD) Los equipos integrados necesarios para ejecutar el proyecto son identificados, definidos, estructurados y asignados.

SP 4.1 Determinar la Estructura del Equipo Integrado de Proyecto

SP 4.2 Desarrollar una Distribución Preliminar de los Requerimientos a los Equipos Integrados.

SP 4.3 Establecer Equipos Integrados

35

Implementar esta área de proceso implicará:

Definir el proceso que seguirá el proyecto tomando como base los procesos y ciclos de vida estándar de la organización, siguiendo las recomendaciones de adaptación incluidos en el repositorio de activos de proceso. En aquellos casos en donde no pueda realizarse la adaptación, solicitar una excepción a quien corresponda (por ejemplo, el área de calidad o la PMO). El proceso del proyecto, así definido, deberá quedar documentado en el plan de proyecto.

Emplear los activos de proceso para estimar y planificar el proyecto.

Integrar el plan de proyecto con otros planes (por ejemplo, el plan de marketing, capacitación, etc.)

Identificar y administrar las interfaces entre el proyecto y otros grupos de trabajo y/o individuos.

Gerenciar el proyecto usando el plan del proyecto, el proceso del proyecto, y otros planes.

Contribuir al repositorio de activos de la organización (nuevas plantillas, métricas, nuevos procesos definidos por el proyecto, lecciones aprendidas, etc.)

Adicionalmente, de emplearse IPPD se deberá:

Establecer la visión compartida del proyecto (todos los participantes/interesados deben estar involucrados en su desarrollo).

Usar la visión para gerenciar el proyecto.

Establecer equipos interdisciplinarios a cargo de los distintos aspectos del proyecto.

Un comentario adicional es que, en muchos casos, además de definir el proceso del proyecto será necesario establecer los procesos de soporte y ‘producción’ (por ejemplo, si el proyecto consiste en diseñar un avión necesitaremos definir también cómo lo fabricaremos).

Gestión Integrada de Proveedores (SS) (ISM) Esta área de proceso, aplicable solamente en el contexto de la disciplina supplier sourcing o adquisición de productos, tiene como propósito identificar potenciales proveedores de productos y establecer con ellos relaciones mutuamente beneficiosas.

Sus objetivos y prácticas específicas son las que se detallan a continuación:


SG 1 Analizar y Seleccionar Proveedores de Productos

SP 1.1 Analizar Potenciales Proveedores de Productos

36

Se identifican, analizan y seleccionan aquellos proveedores potenciales cuyos productos mejor satisfagan las necesidades del proyecto.

SP 1.2 Evaluar y Determinar Proveedores de Productos

SG 2 Coordinar Trabajo con Proveedores El trabajo con los proveedores es coordinado con el propósito de garantizar que el acuerdo con el proveedor sea ejecutado apropiadamente.

SP 2.1 Monitorear Procesos Seleccionados del Proveedor

SP 2.2 Evaluar Artefactos Seleccionados del Proveedor

SP 2.3 Revisar el Acuerdo con el Proveedor

Esta área de proceso podría implementarse a través de un proceso que permita formalizar la selección y alianza estratégica con proveedores que estén en condiciones de entregar productos y servicios del nivel de calidad exigido por la organización. La evaluación y selección debería ser extremadamente formal –una alternativa sería usar Análisis y Toma de Decisiones (DAR)- y el acuerdo con el proveedor podría formalizarse con algún tipo de contrato marco en donde se establezcan las condiciones generales de la relación (términos legales, niveles de servicio, auditoría de productos y procesos, revisión periódica, etc.)

Ambiente Organizacional para la Integración (IPPD) (OEI) Esta área de proceso –válida solamente para la disciplina IPPD- tiene como propósito proveer la infraestructura necesaria para que los distintos grupos implicados en el proyecto trabajen de manera integrada. En general, la infraestructura mencionada contendrá los siguientes elementos:

Una definición de la visión de la organización, la que deberá hacer referencia a valores y prácticas importantes para esta disciplina (trabajo en equipo, desarrollo de productos en forma concurrente, etc.)

Un ambiente de trabajo preparado para la colaboración e integración del personal y de los distintos grupos involucrados.

Personal especialmente entrenado para integrarse, colaborar y liderar a otros.

El área de proceso tiene dos objetivos específicos y un total de seis prácticas específicas:


SG 1 Proveer Infraestructura para IPPD Se provee una infraestructura que maximiza la productividad de la gente y facilita la colaboración.

SP 1.1 Establecer la Visión Compartida de la Organización

SP 1.2 Establecer un Ambiente de Trabajo Integrado

SP 1.3 Identificar Requerimientos de Capacidades Propias para IPPD

SG 2 Gestionar la Integración del P l

SP 2.1 Establecer Mecanismos de Liderazgo

37

Personal El personal es gerenciado para nutrir los comportamientos colaborativos y de integración.

SP 2.2 Establecer Incentivos para la Integración

SP 2.3 Establecer Mecanismos para Balancear las Responsabilidades del Equipo y la Organización

Equipo Integrado (IPPD) (IT) Esta es otra de las áreas de proceso aplicable únicamente cuando se emplea la disciplina IPPD. Su propósito es establecer y mantener equipos integrados para el desarrollo de productos. En este contexto, el grupo de trabajo puede estar integrado por representantes de distintas áreas –funcionales y técnicas-, proveedores o clientes. Cada uno de estos representantes están autorizados por sus respectivas organizaciones para actuar y tomar decisiones en su nombre.

El área de proceso incluye dos objetivos y ocho prácticas específicas:


SG 1 Establecer Composición del Equipo Se establece y mantiene una estructura de equipo que provee los conocimientos y habilidades necesarias para proveer el producto del equipo.

SP 1.1 Identificar las Tareas del Equipo

SP 1.2 Identificar Necesidades de Conocimientos y Habilidades

SP 1.3 Asignar Miembros de Equipo Apropiados

SG 2 Gobernar la Operación del Equipo La operación del equipo integrado es gobernada de acuerdo a principios establecidos.

SP 2.1 Establecer una Visión Compartida

SP 2.2 Establecer el Acuerdo del Equipo

SP 2.3 Definir Roles y Responsabilidades

SP 2.4 Establecer Procedimientos Operativos

SP 2.5 Colaborar entre los Equipos Participantes

38

Áreas de Proceso de Nivel 4 En una organización de este nivel, los procesos son analizados con el propósito de resolver las causas especiales de variación (ver Glosario) Las métricas son empleadas para establecer objetivos y requerimientos de calidad para los productos y servicios, además de ser usadas para fijar las metas de desempeño de los procesos.

En este nivel, los procesos son predecibles y cuantitativamente comprendidos. Se emplean herramientas estadísticas para entender cuál es la performance real de los procesos y la calidad de los productos y servicios de la organización. Las mismas herramientas se usan para predecir el futuro desempeño de los procesos, y los niveles de calidad de los productos y servicios.

Solamente hay dos áreas de proceso en el nivel 4: Desempeño del Proceso de la Organización (OPP) y Administración Cuantitativa de Proyectos (QPM)

Desempeño del Proceso de la Organización (OPP) Esta área de proceso tiene como propósito comprender cuál es la performance de los procesos de la organización y emplear dicha información para administrar cuantitativamente los proyectos.

En una organización en este nivel, las métricas de los procesos (por ejemplo, esfuerzo, efectividad del testing, etc.) y del producto (por ejemplo, densidad de defectos, confiabilidad, etc.) son empleadas para modelar la performance pasada y para predecir la futura. A su vez, estos modelos son empleados como base para contrastar el desempeño real de los proyectos.

Con esta información la organización estará en condiciones de determinar cuáles procesos son estables, cuáles merecen atención, cuáles deberían ser estadísticamente controlados y cómo, y cuáles procesos deberían ser mejorados.

El área tiene un solo objetivo y cinco prácticas específicas, a saber:


SG 1 Establecer Líneas Base y Modelos

Se establecen y mantienen modelos y líneas base que caracterizan el desempeño esperado del conjunto de procesos estándar de la organización.

SP 1.1 Seleccionar Procesos

SP 1.2 Establecer Métricas de Desempeño de los Procesos

SP 1.3 Establecer Objetivos de Calidad y Desempeño

SP 1.4 Establecer Líneas Base de Desempeño

SP 1.5 Establecer Modelos de Desempeño

Estas prácticas pueden implementarse, por ejemplo, mediante un buen programa de métricas que contemple la generación de modelos de performance. Será necesario,

39

además, contar con un proceso definido para realizar estas actividades, que podrían ser asignadas al departamento de aseguramiento de la calidad (si existiere) u a otro similar.

Las herramientas y técnicas que pueden emplearse aquí son las clásicas popularizadas por la calidad total: diagramas de control, prueba de hipótesis, etc.

Más allá de quién realice estas actividades, es importante tener en claro que no todos los procesos deberán (o podrán) ser controlados estadísticamente. La decisión de cuáles son esos procesos deberá tomarse en función de las necesidades del negocio y del proyecto.

Son muchos los procesos candidatos a ser controlados estadísticamente. Por ejemplo, el proceso de testing podría ser analizado para determinar su efectividad (defectos post-release) y así predecir su comportamiento en el futuro. También podríamos buscar determinar el nivel de confiabilidad de nuestro proceso de estimación, el tiempo medio entre fallas de nuestros productos, el nivel de productividad de la organización, etc.

Administración Cuantitativa de Proyectos (QPM) El propósito de esta área de proceso es administrar el proyecto de manera tal de cumplir con sus objetivos de calidad y desempeño. El proyecto es gestionado cuantitativamente, lo cual implica:

Establecer y mantener los objetivos de calidad y desempeño del proyecto;

Configurar el proceso que empleará el proyecto seleccionando aquellos subprocesos sobre la base de su estabilidad y/o capacidad (lo que se encuentra en los modelos y líneas base mencionados en el área de proceso anterior);

Seleccionar los subprocesos del proceso del proyecto que serán estadísticamente administrados, y con cuáles técnicas y herramientas;

Monitorear el comportamiento del proyecto para determinar si se cumplen o no los objetivos de calidad y desempeño;

Monitorear el desempeño de los subprocesos seleccionados para determinar si pueden cumplir sus objetivos de calidad y desempeño, y tomar acciones correctivas de ser necesario;

Alimentar el repositorio de métricas de la organización con los datos del desempeño y calidad reales.

Los objetivos y prácticas específicas del área son las siguientes:


40

SG 1 Administrar el Proyecto Cuantitativamente

El proyecto es cuantitativamente administrado usando objetivos de calidad y desempeño.

SP 1.1 Establecer los Objetivos del Proyecto

SP 1.2 Ensamblar el Proceso Definido para el Proyecto

SP 1.3 Seleccionar Subprocesos a Ser Administrados Estadísticamente

SP 1.4 Administrar el Desempeño del Proyecto

SG 2 Administrar Estadísticamente el Desempeño de los Subprocesos

El desempeño de los subprocesos seleccionados, pertenecientes al proceso definido del proyecto, es administrado estadísticamente.

SP 2.1 Seleccionar Métricas y Técnicas de Análisis

SP 2.2 Aplicar Métodos Estadísticos para Entender la Variación

SP 2.3 Monitorear el Desempeño de los Subprocesos Administrados

SP 2.4 Registrar Datos de la Gestión Estadística

Las herramientas que pueden usarse para implementar estas prácticas son similares a las propuestas para el área anterior: todas las de gestión estadística de procesos. La diferencia radica en que aquí las empleamos para tener un conocimiento cabal del comportamiento de los subprocesos del proyecto (naturaleza de las variaciones, estabilidad, etc.)

41

Áreas de Proceso de Nivel 5 Las organizaciones de este nivel trabajan en el análisis de sus procesos con el objetivo de identificar y eliminar las causas comunes de variación (ver Glosario) Para ello hacen uso de métricas que les permiten:

Seleccionar mejoras e innovaciones

Estimar los costos y beneficios de las mejoras e innovaciones

Medir los costos y beneficios reales de las mejoras e innovaciones

La permanente búsqueda de mejores maneras de hacer las cosas, basada en la medición de los procesos y sin alterar su estabilidad, está arraigada en lo más profundo de la cultura de la organización. No hay otra manera de manejar el negocio.

La diferencia entre este nivel y el anterior radica fundamentalmente en el tipo de causas de variación que son atacadas: en nivel 4 se trabaja sobre las causas especiales (aquellas que producen variaciones no al azar en los resultados del proceso y que son atribuibles a factores externos, como por ejemplo condiciones en el medio ambiente), mientras que en nivel 5 el objetivo son las causas comunes (aquellas que producen variaciones al azar en los resultados del proceso y que tienen por origen el propio proceso)

Solamente hay dos áreas de proceso en este nivel: Innovación organizacional y despliegue (OID) y Análisis y resolución de causas de defectos/problemas (CAR).

Innovación organizacional y despliegue (OID) El propósito de esta área es seleccionar e implantar cambios que, de manera incremental, permitan mejorar –en forma medible- los procesos y las tecnologías empleadas por la organización, al mismo tiempo que se alinean los objetivos de calidad y desempeño con los objetivos del negocio. En general, las mejoras estarán relacionadas con el incremento de la satisfacción de los clientes o usuarios, la disminución de los tiempos de desarrollo, o con el aumento de la productividad.

En este nivel de madurez, las organizaciones poseen una cultura y una infraestructura que facilitan y estimulan la participación de todos sus integrantes en las actividades de innovación. La identificación de potenciales mejoras puede ser realizada por cualquiera, sin importar su jerarquía o posición en la organización. Los cambios seleccionados son efectivamente implementados, y sus consecuencias, medidas.

El área tiene dos objetivos específicos y un total de siete prácticas específicas, los que se describen a continuación:


42

SG1 Seleccionar mejoras

Se seleccionan mejoras a las tecnologías y a los procesos que contribuyan a alcanzar los objetivos de calidad y desempeño.

SP 1.1 Recibir y Analizar Propuestas de Mejora

SP 1.2 Identificar y Analizar Innovaciones

SP 1.3 Realizar Pilotos de las Innovaciones

SP 1.4 Seleccionar Mejoras para Implantación

SG2 Implantar Mejoras

Las mejoras a los procesos y las tecnologías de la organización son continua y sistemáticamente implantados.

SP 2.1 Planificar la Implantación

SP 2.2 Gestionar la Implantación

SP 2.3 Medir los Efectos de la Mejora

Estos objetivos se pueden satisfacer de contarse con un proceso para realizar mejoras sistemáticas a los procesos de la organización. Por ejemplo, podría plantearse que las propuestas de mejora sean elevadas a algún tipo de comité para su evaluación, y que las que finalmente resulten aprobadas sean definidas e implementadas por una iniciativa que deberá ser manejada como un proyecto más –con alcance, plan, presupuesto, recursos asignados, etc.-

Si bien mecanismos de este tipo existirán en los niveles anteriores, en este nivel el manejo del tema es más sistemático y formal.

Análisis y resolución de causas de defectos/problemas (CAR) Poder identificar defectos tempranamente y evitar sus consecuencias es una característica fundamental de las organizaciones pertenecientes al nivel 5. Las prácticas incluidas aquí apuntan a identificar, analizar y eliminar las causas no sólo de los defectos sino también de los problemas (por ejemplo, para mejorar atributos de calidad de productos y servicios). Los objetivos y prácticas específicos son las siguientes:


SG1 Determinar Causas de Defectos

Las causas raíz de defectos y otros problemas son sistemáticamente identificadas.

SP 1.1 Seleccionar Datos de Defectos para Analizar

SP 1.2 Analizar Causas

SG2 Resolver Causas de los Defectos

Las causas raíz de defectos y otros problemas son sistemáticamente resueltas para prevenir su ocurrencia.

SP 2.1 Implementar Acciones Propuestas

SP 2.2 Evaluar el Efecto de los Cambios

SP 2.3 Registrar Datos

Estos objetivos suelen ser satisfechos mediante la definición e implementación de un proceso que sistemáticamente realice, a escala organizacional y por proyecto, el análisis de los defectos y problemas encontrados, y la definición y ejecución de acciones concretas que permitan resolver sus causas de origen.

43

Una buena manera de implementar este análisis, al menos a nivel proyecto, es realizar el cierre formal de los proyectos, registrando lecciones aprendidas y sugiriendo acciones de mejora.

Otra alternativa es que el grupo de la organización a cargo de los temas de calidad sistemáticamente examine los indicadores disponibles (por ejemplo, densidad de defectos o cantidad de incidentes en producción) y que los analice con el propósito de identificar posibles causas de su comportamiento.

Las herramientas que pueden emplearse en el análisis son las que clásicamente han sido usadas por la calidad total: el diagrama de Pareto (ver Fig. 9), el de causa-efecto (ver Fig. 10) y el de dispersión.

Fig. 9: Un diagrama de Pareto

44

Fig. 10: Un diagrama de causa-efecto o de Ishikawa

Una vez realizado el análisis deben definirse e implementarse las mejoras, las que podrán ejecutarse dentro de este proceso o en aquel relacionado con el área de proceso Innovación organizacional y despliegue (OID).

Definiendo los procesos de la organización Como dijimos en secciones anteriores, CMMI es solamente un modelo de referencia que describe las características que debería reunir un proceso de desarrollo de productos de clase mundial.

El proceso de desarrollo que definamos para nuestra organización debería tener una estructura adecuada a nuestras necesidades. No debemos caer en la tentación de organizar nuestro proceso alrededor de las áreas del modelo.

En general, el proceso de desarrollo suele organizarse en fases y actividades, algunas de las cuales podrán pertenecer a distintas disciplinas o especialidades (gestión del proyecto, diseño y desarrollo, etc.) Esas actividades serán las encargadas de implementar las áreas de proceso de CMMI.

En algunas organizaciones, los procesos relacionados con administración de la configuración y aseguramiento de la calidad serán independientes del proceso de desarrollo empleado por los proyectos. Lo mismo ocurrirá con el proceso encargado de identificar inicialmente las necesidades de los clientes que darán origen a los proyectos (el que suele ser llamado gestión de demanda). Idéntica situación se dará con los

45

procesos relacionados con el análisis y la mejora de procesos.

Pero además del proceso productivo, será necesario definir otros procesos que son vitales para cualquier organización y que CMMI no cubre por ser un modelo de referencia para procesos de desarrollo. Puntualmente, todas las actividades relacionadas con lo que ocurre después de que el producto ha sido entregado no están incluidas en el modelo. Será necesario, entonces, definir los procesos relacionados con el soporte a los usuarios (atención de incidentes y consultas, gestión de problemas, etc.) y con la operación de la solución (resguardo, procesamiento, análisis de performance, seguridad, etc.), de manera de obtener así una organización ‘balanceada’: de poco servirá ser muy buenos produciendo si no podemos administrar el producto una vez salido de la ‘fábrica’.

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 (ver Tabla 1). A continuación, describimos sus principales características y ámbitos de aplicación.

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.6

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 (ver Tabla 1 para más detalles)xviii. 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. 1 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.7

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

46

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

CobIT CobIT, por otro lado, es un modelo desarrollado por el IT Governance Institutexix 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 (ver Fig. 12).

xix www.itgi.org

47

Fig. 12 Dominios y procesos de CobIT

Como puede apreciarse en la Fig. 12, 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. Podríamos pensar, entonces, que las prácticas descriptas en CMMI, una vez implementadas, deberían facilitar el cumplimiento de algunos de los objetivos de control de CobIT.

ITIL ITIL es el acrónimo de Information Technology Infrastructure Library.8 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 (ver Fig. 13).

48

Fig. 13: 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.

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).

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)xx, dependiente del Institute for

xx Participaron además empresas como IBM, Accenture y EDS, entre otras.

49

Software Research International de la Facultad de Ciencias de la Computación.xxi

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.

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.

Fig. 14: Fases y áreas de capacidad de eSCM

El modelo tiene muchas particularidades (ver Fig. 14). Por un lado, las prácticas

xxi De todas maneras, es interesante observar que uno de sus autores es Mark Paulk, quien fue también autor del CMM-SW.

50

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 formalización del contrato-, despliegue, prestación del servicio, cierre y ongoing –para aquellas prácticas que se aplican en todas las fases anteriores-), y por niveles (2, 3 y 4).

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. 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).

Integrando los modelos Cada uno de los modelos y estándares propuestos tiene un propósito y un alcance claros (ver Tabla 1). 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 CMMI que deberían ser analizados, sobre todo en organizaciones internas de sistemas.xxii

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. 11).

Tabla 1: Comparación entre CMMI, ISO 9001, CobIT, ITIL y eSCM9

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

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

xxii De hecho, el dominio ‘Entrega y Soporte’ de CobIT está basado en ITIL.

51

procesos integrados, y adquisición.

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.

Conclusiones CMMISM es un modelo más que interesante si lo que nos preocupa es mejorar la forma en la cual desarrollamos nuestros productos. Si bien hay muchas voces a su favor y varias otras en su contra, el modelo representa bastante bien la visión actual de cómo los conceptos de calidad deberían ser aplicados a las industrias relacionadas con las tecnologías de la información (y, en general, a todas aquellas que desarrollen productos).

Por supuesto que para ser exitosos en su aplicación hay varios aspectos que no deberíamos perder de vista. El primero tiene que ver con el contexto en el cual queramos aplicarlo: CMMISM es solamente un marco de referencia, por lo que queda librado a nuestro sentido común cómo interpretarlo y cómo aplicarlo en función de las características de nuestra organización y del tipo de industria en la que nos encontremos. No es lo mismo una pequeña casa de software que atiende clientes locales que una gran software factory con clientes en el extranjero; claramente, ambas tendrán factores en común (planificación, seguimiento, manejo de requerimientos, etc.), pero también tendrán diferencias sustanciales (escala, complejidad técnica, formalidad en el manejo de la demanda de los clientes, etc.) que será necesario analizar antes de aplicar las ideas detrás de CMMISM.

Otro aspecto que no debe perderse de vista es que CMMISM apunta fundamentalmente a la eficiencia operativa. Por consiguiente, alcanzar un determinado nivel de madurez no garantiza el éxito de la organización; son la estrategia de negocio y la capacidad de ponerla en práctica las que permiten hacerlo. Endilgarle al modelo fortalezas o

52

debilidades en ese rubro es no comprender las ideas que le dieron origen.

Y, por último, no debemos olvidarnos del aspecto humano. Contar con un proceso formalizado no es una excusa para pensar que las personas son recursos fácilmente reemplazables. Muchas organizaciones han caído en la tentación de ‘sobreespecificar’ sus procesos, llegando a describir hasta el más mínimo detalle. Eso agobia a la gente que debe ejecutarlos. Debemos ser conscientes de que es sumamente importante lograr un equilibrio entre la formalidad de nuestros procesos y la flexibilidad que necesitan quienes harán uso de ellos.

© Sergio Villagra & Axentia, 2006

53

Glosario

Aseguramiento de la calidad Todas aquellas acciones planeadas y sistemáticas necesarias para proveer una adecuada confianza de que un producto o servicio satisfará determinados requerimientos de calidad (ISO 8402).

Causa común de variación Variaciones en la salida de un proceso originada en el propio proceso (mano de obra, materiales, métodos, maquinaria, métricas, medio ambiente)

Causa especial de variación Variación no aleatoria en la salida de un proceso, atribuible a causas externas específicas (por ejemplo, falta de entrenamiento, materia prima de baja calidad, no seguimiento del proceso, fallas en las herramientas, etc.)

Control de calidad Las actividades y técnicas operativas usadas para cumplir con los requerimientos de calidad (ISO 8402).

COTS Commercial-of-the-Shelf. Productos de software disponibles para ser comprados y usados sin necesidad de realizar actividades de desarrollo.

SEPG Software Engineering Process Group. Grupo de trabajo encargado de coordinar las actividades de mejora de procesos en una organización de desarrollo de software.

TWG Technical Working Group. Grupo de trabajo encargado de identificar e implementar mejoras a los procesos. En general, está formado por personal involucrado en los procesos que se pretende mejorar.

54

Referencias 1 La información de CMMI empleada para elaborar este artículo ha sido tomada de Capability Maturity Model Integration Version 1.1 Staged Representation, CMU/SEI-2002-TR-012. 2 Watts S. Humphrey; Managing the Software Process; Addison-Wesley, 1989. 3 Paulk, Weber, Curtis, Chrissis; Capability Maturity Model for Software Version 1.1; CMU/SEI-93-TR-24. 4 William Florac, Robert Park, Anita Carleton; Practical Software Measurement; CMU/SEI-97-HB-003. 5 Robert Kaplan, David Norton; The Strategy Focused Organization; Harvard Business School, 2001 6 ISO/IEC; Software engineering — Guidelines for the application of ISO 9001:2000 to computer software; ISO/IEC 90003. 7 Boris Mutafelija, Harvey Stromberg; Systematic Process Improvement Using ISO 9001:2000 and CMMI; Artech House Publishers, 2003 8 itSMF; IT Service Management: An Introduction; Van Haren Publishing, 2002 9 Mark Paulk, Elaine Hyder, Keith Heston; The eSCM –SP v2: Model Overview; Information Technology Qualification Center-Carnegie Mellon University.

55

white paper 2006 - · pdf filefig. 12 dominios y procesos de cobit ... los cinco niveles de...

Documents