MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS

(1)

MPS.BR - Mejora de Proceso del Software Brasileño

Guía de Implementación – Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS

Esta guía contiene orientaciones para la implementación del nivel B del Modelo de Referencia MR-MPS.

VIGENCIA Y TRANSICIÓN: La Guía General:2011 entra en vigor el 30 de junio de 2011. Así, a partir de esta fecha pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Sin embargo, queda definido un período de transición, de 30 de junio a 31 de diciembre de 2011, durante el cual pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011 o la versión anterior MR-MPS:2009. A partir del 1º de enero de 2012 solo serán válidas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Las implementaciones a ser realizadas utilizando esta Guía de Implementación deberán llevar en cuenta estas vigencias.

Julio de 2011

Actualizado en Agosto de 2011

Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN 978-85-99334-70-6

(2)

Índice

1 Prefacio ... 3

2 Introducción ... 5

3 Objetivo ... 6

4 Evolucionando del nivel C al nivel B ... 6

5 Gestión de Proyectos (GPR) (evolución) ... 8

5.1 Propósito ... 8

5.2 Fundamentación teórica ... 9

5.3 Resultados esperados ... 18

6 Los atributos de proceso del nivel B ... 23

6.1 Fundamentación teórica ... 25

6.2 AP 4.1 - El proceso es medido ... 29

6.3 AP 4.2 - El proceso es controlado ... 35

Referencias bibliográficas... 40

Lista de colaboradores de la Guía de Implementación – Parte 6:2011 ... 44

Lista de colaboradores de la Guía de Implementación – Parte 6:2009 ... 45

Lista de colaboradores de la Guía de Implementación – Parte 6 versión 1.0 - Julio/2007 ... 46

(3)

1 Prefacio

El MPS.BR¹ es un programa movilizador, de largo plazo, creado en diciembre de 2003, es coordinado por la Asociación para Promoción de la Excelencia del Software Brasileño (SOFTEX), y cuenta con el apoyo del Ministerio de Ciencia y Tecnología (MCT), de la Financiera de Estudios y Proyectos (FINEP), del Servicio Brasileño de Apoyo a las Micro y Pequeñas Empresas (SEBRAE) y del Banco Interamericano de Desarrollo (BID).

El objetivo del programa MPS.BR (acrónimo) es la Mejora de Proceso del Software, para lograr dos metas a mediano y largo plazo:

a) meta técnica, teniendo como objetivo la creación y perfeccionamiento del modelo MPS, con resultados esperados tales como: (i) guías del modelo MPS; (ii) Instituciones Implementadoras (II) acreditadas para prestar servicios de consultoría de implementación del modelo de referencia MR-MPS; (iii) Instituciones Evaluadoras (IA) acreditadas para prestar servicios de evaluación siguiendo el método de evaluación MA-MPS; (iv) Consultores de Adquisición (CA) certificados para prestar servicios de consultoría de adquisición de software y servicios asociados;

b) meta de mercado, teniendo como objetivo la propagación y adopción del modelo MPS, en todas las regiones del país, en un intervalo de tiempo justo, a un costo razonable, tanto en PYMEs (foco principal) así como en grandes organizaciones públicas y privadas, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops; (iii) organizaciones que implementaron el modelo MPS; (iv) organizaciones con evaluación MPS publicada (vigencia de tres años).

El programa MPS.BR cuenta con dos estructuras de apoyo al desarrollo de sus actividades, el Foro de Acreditación y Control (FCC) y el Equipo Técnico del Modelo (ETM). Por medio de estas estructuras, el MPS.BR obtiene la participación de representantes de universidades, instituciones gubernamentales, centros de investigación y de organizaciones privadas, las cuales contribuyen con sus visiones complementarias que agregan calidad al emprendimiento.

Cabe al FCC: (i) emitir parecer para auxiliar las decisiones de la SOFTEX sobre la acreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA);

(ii) supervisar los resultados de las Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA), emitiendo parecer proponiendo a la SOFTEX su desacreditación en caso de comprometimiento de la credibilidad del modelo MPS.

Cabe al ETM apoyar a la SOFTEX sobre los aspectos técnicos relacionados al Modelo de Referencia (MR-MPS) y Método de Evaluación (MA-MPS), para: (i) creación y perfeccionamiento continuo del MR-MPS, MA-MPS y sus guías específicas; (ii) capacitación de personas por medio de cursos, pruebas y workshops.

1 MPS.BR, MR-MPS, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla MPS.BR está asociada al programa MPS.BR – Mejora del Proceso de Software Brasileño y la sigla MPS está

(4)

La creación y el perfeccionamiento de esta Guía de Implementación son también atribuciones del ETM, siendo que esta guía forma parte del siguiente conjunto de documentos del modelo MPS:

• Guía General [SOFTEX, 2011a];

• Guía de Implementación (partes 1 a 11);

• Guía de Evaluación [SOFTEX, 2011b]; y

• Guía de Adquisición [SOFTEX, 2011c].

Esta Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos.

La Guía de implementación está subdividida en once partes, contemplando, respectivamente, los siguientes niveles de madurez:

• Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS;

• Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS;

• Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS;

• Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS;

• Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS;

• Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS;

• Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS;

• Parte 8: Implementación del MR-MPS:2009 (Niveles G a A) en organizaciones que adquieren software;

• Parte 9: Implementación del MR-MPS:2009 (Niveles G a A) en organizaciones del tipo Fábrica de Software;

• Parte 10: Implementación del MR-MPS:2009 (Niveles G a A) en organizaciones del tipo Fábrica de Pruebas; y

• Parte 11: Implementación y Evaluación del MR-MPS (Niveles G a A) en conjunto con el CMMI-DEV.

Los cambios de esta Guía de Implementación en relación a la versión 2009 se deben a:

• cambios realizados en la versión 2009 de la Guía General;

• corrección ortográfica y gramatical;

• adecuación de las referencias bibliográficas;

• inclusión de notas explicativas contenidas en las partes 8, 9 y 10 de la Guía de Implementación; y

• revisión del texto debido a la reorganización de los resultados esperados de atributos de proceso del nivel B del MR-MPS y de la evolución del proceso Gestión de Proyectos en este nivel.

(5)

Adicionalmente, en agosto de 2011, las siguientes modificaciones fueron realizadas en relación a la versión publicada en julio de 2011:

• adecuación en la redacción del resultado esperado DFP8.

2 Introducción

Los cambios que están sucediendo en los ambientes de negocios han motivado a las empresas a modificar sus estructuras organizacionales y procesos productivos, saliendo de la visión tradicional basada en áreas funcionales hacia redes de procesos centrados en el cliente. La competitividad depende, cada vez más, del establecimiento de conexiones en estas redes, creando vínculos esenciales en las cadenas productivas. Lograr competitividad por la calidad, para las empresas de software, implica tanto la mejora de la calidad de los productos de software y servicios asociados, así como la de los procesos de producción y distribución de software.

De esta forma, así como para otros sectores, la calidad es un factor crítico de éxito para la industria de software. Para que se tenga un sector de software competitivo nacional e internacionalmente, es esencial que los emprendedores del sector se concentren en la eficiencia y la eficacia de sus procesos, buscando ofrecer productos de software y servicios asociados conforme estándares internacionales de calidad.

Se busca que el modelo MPS sea apropiado para el perfil de empresas con diferentes tamaños y características, públicas y privadas, aunque con especial atención a las micro, pequeñas y medianas empresas. También se espera que el modelo MPS sea compatible con los estándares de calidad aceptados internacionalmente y que tenga como presupuesto el aprovechamiento de toda la competencia existente en los estándares y modelos de mejora de proceso ya disponibles. De esta forma, tiene como base los requisitos de procesos definidos en los modelos de mejora de proceso y atiende a la necesidad de implantar los principios de Ingeniería de Software de manera adecuada al contexto de las empresas, estando en consonancia con los principales abordajes internacionales para la definición, evaluación y mejora de procesos de software.

El Modelo MPS se basa en los conceptos de madurez y capacidad de proceso para la evaluación y mejora de la calidad y productividad de productos de software y servicios asociados. Dentro de ese contexto, el MPS.BR posee tres componentes:

Modelo de Referencia (MR-MPS), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS).

El Modelo MPS está descrito por medio de documentos en forma de guías:

• Guía General: contiene la descripción general del modelo MPS y detalla el Modelo de Referencia (MR-MPS), sus componentes y las definiciones comunes necesarias para su entendimiento y aplicación.

• Guía de Adquisición: describe un proceso de adquisición de software y servicios asociados. Está descrito de modo que apoye a las instituciones que quieran adquirir productos de software y servicios asociados.

• Guía de Evaluación: describe el proceso y el método de evaluación MA-MPS, los requisitos para evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA); y

(6)

• Guía de Implementación: serie de once documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS.

3 Objetivo

La Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. Este documento corresponde a la parte 6 de la Guía de Implementación y aborda la implementación del nivel de madurez B.

Este documento está dirigido, pero no se limita, a organizaciones interesadas en utilizar el MR-MPS para mejora de sus procesos de software e Instituciones Implementadoras (II). El contenido de este documento es informativo, o sea, no se espera que una organización implementando el MR-MPS cumpla todos los elementos citados en la explicación referente a los resultados esperados. Las observaciones presentes en este documento buscan apenas explicitar elementos importantes en la interpretación de los resultados esperados. Durante una evaluación MPS, solo es requerido el cumplimiento de los resultados esperados definidos en la Guía General. Los evaluadores MPS deben analizar si la implementación de los procesos de la organización cumple cada resultado, con abertura a múltiples formas válidas de implementación.

4 Evolucionando del nivel C al nivel B

Al lograr el nivel C, una organización/unidad organizacional tiene definidos e implementados sus procesos estándar y usa prácticas de ingeniería de software en sus proyectos.

A partir del nivel B, con la implementación de los atributos de proceso AP 4.1 y AP 4.2, la organización/unidad organizacional pasa a tener una visión cuantitativa del desempeño de sus procesos en el apoyo al logro de los objetivos de calidad y de desempeño de los procesos. Es importante tener en cuenta que, al implementar los niveles anteriores, en especial el proceso Medición, ya se debe preparar el camino para la implementación del nivel B, por medio de una elección adecuada de las medidas, de la realización de recolección consistente y de la definición de una base de medidas capaz de almacenar y de proporcionar los datos necesarios para el análisis de desempeño de los procesos, realizada por medio del control estadístico de procesos. En [BARCELLOS, 2009] son presentados requisitos que deben ser atendidos para que una base de medidas sea considerada apropiada para el control estadístico de procesos y acciones que pueden ser realizadas para adaptar (cuando posible) una base de medidas para el control estadístico de procesos. También son presentadas algunas recomendaciones para medición objetivando el control estadístico de procesos y es descrita una Ontología de Medición de Software que provee conocimiento útil para la creación de bases de medidas apropiadas para el control estadístico de procesos.

Todavía, en relación a la implementación de los niveles anteriores, también se debe tener en cuenta la imposibilidad de realizar cambios radicales en los procesos, a fin de que sea posible utilizar los datos históricos recolectados para las medidas en el

(7)

análisis de la estabilidad de los procesos. Con eso, la organización/unidad organizacional pasa a tener datos de desempeño, límites de control y modelos para gestionar sus proyectos de forma cuantitativa, lo que significa una nueva evolución del proceso Gestión de Proyectos².

No hay necesidad de, ni es conveniente, que sean establecidos límites de control de desempeño para todos los procesos o medidas, ni siquiera para un proceso completo. Esto debe hacerse, apenas, para procesos, subprocesos y medidas seleccionados por la organización. Esta selección, sin embargo, no puede ser aleatoria pero si basada en criterios. Entre los criterios que deben apoyar esta decisión, los principales son: (i) relación del proceso/subproceso con los objetivos de negocio relevantes; (ii) existencia de datos; (iii) variabilidad de los datos; (iv) estabilidad del proceso/subproceso; y (v) posibilidad de construir modelos predictivos a partir de las informaciones disponibles en la organización [SEI, 2010].

De esta forma, el primer paso al iniciarse la implementación del nivel B del MPS es identificar los objetivos de negocio relevantes de la organización, la necesidad de informaciones para apoyar el logro de estos objetivos y generar la lista de los procesos y/o subprocesos seleccionados para análisis de desempeño. La implementación de los resultados de atributo de proceso RAP22 a RAP25 se hace una única vez para todos los procesos. Sin embargo, se debe revisar periódicamente la lista de procesos/subprocesos seleccionados, incluyéndose nuevos procesos/subprocesos conforme sea apropiado.

Para los procesos/subprocesos seleccionados para análisis de desempeño, todos los demás resultados de los atributos de proceso AP 4.1 y AP 4.2 deben ser implementados.

A partir del nivel B, la organización/unidad organizacional pasa, también, a gestionar cuantitativamente los proyectos. De esta forma, el proceso Gestión de Proyectos pasa a ser ejecutado de forma cuantitativa. Algunos de sus resultados esperados son modificados para tener este enfoque y nuevos resultados son acrecentados.

Gestionar cuantitativamente un proyecto depende de la existencia de datos de desempeño, límites de control y modelos colocados a disponibilidad por la implementación de los atributos de proceso AP 4.1 y AP 4.2. A su vez, la implementación de la gestión de proyectos con enfoque cuantitativo provee datos reales de desempeño de los procesos en los proyectos que alimentan las líneas base con nuevos datos. La Figura 1 muestra la relación entre los atributos de proceso AP 4.1 y AP 4.2 y el proceso Gestión de Proyectos conforme el nivel B del MPS.

2 Una primeira evolución ocurre al implementarse el nivel E, cuando la gestión de proyectos pasa a

(8)

Figura 1 - Relación entre el proceso Gestión de Proyectos y los atributos de proceso AP 4.1 y AP 4.2

Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes

de Software (Parte 8)

El nivel B del MR-MPS no tiene nuevos procesos. El cambio de nivel implica en la evolución del proceso Gestión de Proyectos, en la implementación de los resultados de atributos de proceso RAP22 a RAP25 y en la implementación de los demás atributos de proceso de AP 4.1 y AP 4.2 en los procesos seleccionados.

Para las organizaciones adquirientes, os procesos a ser seleccionados para análisis de desempeño son procesos que ella ejecuta y no los procesos ejecutados por el proveedor.

Fábrica de Software (Parte 9)

Fábrica de Pruebas (Parte 10)

5 Gestión de Proyectos (GPR) (evolución)

5.1 Propósito

El propósito del proceso Gestión de Proyectos es establecer y mantener planes que definen las actividades, recursos y responsabilidades del proyecto, así como proporcionar informaciones sobre el progreso del proyecto que permitan la realización de correcciones cuando se tengan desvíos significativos en el desempeño del proyecto. El propósito de este proceso evoluciona a medida que la organización crece en madurez. Así, a partir del nivel E, algunos resultados evolucionan y otros son incorporados, de modo que la gestión de proyectos pase a ser realizada con base en el proceso definido para el proyecto y en los planes integrados. En el nivel B, la gestión

(9)

de proyectos pasa a tener un enfoque cuantitativo, reflejando la alta madurez que se espera de la organización. Nuevamente, algunos resultados evolucionan y otros son incorporados.

5.2 Fundamentación teórica

La implementación del nivel B del MR-MPS implica en un cambio en la forma como los proyectos son gestionados, pasando a envolver técnicas cuantitativas y estadísticas para controlar los procesos y la calidad. A seguir presentamos una introducción a la gestión cuantitativa de proyectos, así como una breve descripción del método QFD (Quality Function Deployment), de la norma ISO/IEC 9126, de modelos dinámicos y de simulación. Con esto, se busca proporcionar una fundamentación teórica para la gestión cuantitativa de proyectos.

5.2.1 Gestión cuantitativa de proyectos

Cada día, las organizaciones buscan mejorar sus prácticas de desarrollo y gestión de proyectos de software, con el fin de aumentar su competitividad por medio de la elaboración de productos en proyectos que sean adherentes, principalmente, a sus objetivos de plazo, costo y calidad.

Los métodos de gestión tradicional que incluyen análisis de medidas y la comparación de estas, en un determinado punto del proyecto, con los valores que fueron planificados para aquel momento, no son suficientes para determinar el desempeño³ de ejecuciones anteriores de los procesos o para predecir el desempeño de los procesos en los proyectos corrientes y futuros [FENTON et al., 2004].

La gestión cuantitativa del proyecto consiste en utilizar técnicas estadísticas y otras técnicas cuantitativas para analizar los procesos utilizados en el proyecto y, a partir de allí, proveer subsidios para su mejora, incluyendo análisis de causas de defectos y otros problemas, aplicación de acciones correctivas y preventivas e implantación de mejoras. La gestión cuantitativa del proyecto es capaz de proveer, por medio del análisis de datos obtenidos en mediciones, una visión objetiva del proyecto y de los procesos en él utilizados. Permitiendo así la comprensión de su status y andamiento del proyecto, sus variaciones de desempeño y calidad y el grado de alcance de los objetivos del proyecto y de la organización. Eso es posible, pues ella proporciona medios para definir y mantener estable los niveles de variación de los procesos, permitiendo la previsión de resultados futuros [FLORAC e CARLETON, 1999].

Técnicas estadísticas utilizadas en la gestión cuantitativa incluyen [SEI, 2010]

análisis, creación o uso de modelos de desempeño de proceso; análisis, creación o uso de líneas base de desempeño de proceso; uso de gráficos de control (también conocidos como gráficos de desempeño de proceso); análisis de variancia, análisis de regresión; uso de intervalos de confianza o intervalos de predicción, análisis sensitiva, simulación y Pruebas de hipótesis. Ejemplos de técnicas cuantitativas no estadísticas incluyen [SEI, 2010] análisis de tendencia, histogramas, análisis de

3 Desempeño de proceso puede ser definido como una medida de los resultados observados que el proceso logra y puede ser caracterizado por medidas de proceso, como por ejemplo esfuerzo, plazo y eficiencia de la remoción de defectos, y por medidas de producto, como confiabilidad y

(10)

Pareto, gráficos de barra, gráfico de radar. Ejemplos de técnicas estadísticas [SEI, 2010] incluyen técnicas de muestreo, análisis de variancia, Prueba chi-cuadrado, gráficos de control de proceso.

Para aplicar la gestión cuantitativa, las organizaciones deben haber logrado un buen nivel de madurez en sus procesos de software [SARGUT e DEMIRORS, 2006]. La efectiva utilización de la gestión cuantitativa identifica un grado considerable de madurez organizacional, pues significa que la organización ejecuta lo esencial para desarrollar software de calidad y está realizando acciones con el objetivo de pasar al nivel de mejora continua de sus procesos.

Para que sea posible gestionar estadísticamente los proyectos, los procesos involucrados necesitan ser estables (ver AP 4.1 e AP 4.2). Después de la fase de estabilización del desempeño de los procesos, se pueden utilizar los resultados históricos de su desempeño (línea base) y los modelos de desempeño, para la gestión cuantitativa. Antes de eso, no es posible caracterizar una gestión cuantitativa efectiva, sino más bien, un esfuerzo para conocer y estabilizar los procesos [CAMPOS et al, 2007].

La gestión cuantitativa no necesita ser aplicada a todo el proceso definido para el proyecto. En la práctica, se debe analizar los subprocesos que componen el proceso definido y determinar cuáles serán gestionados cuantitativamente, pudiendo ser todos o algunos. La decisión de cuales subprocesos serán sometidos a la gestión cuantitativa debe basarse en la selección de los procesos más relevantes para los objetivos de la organización. Procesos que consumen recursos significativos o que están en el camino crítico de los proyectos, o que tienen relación con la calidad del producto deben ser priorizados [KULPA e JOHNSON, 2004].

Una cuestión que se coloca es sobre el número de procesos/subprocesos que necesitan ser gestionados cuantitativamente. Una respuesta para esta cuestión puede ser encontrada en [SEI, 2010] que indica que se debe seleccionar por lo menos un subproceso relevante por fase del ciclo de vida, un subproceso relacionado a la gestión del proyecto y uno relacionado a los procesos de apoyo.

Una vez que la gestión cuantitativa está directamente relacionada a las mediciones realizadas en los proyectos, la medición de software es uno de sus principales pilares. El plan de medición debe definir medidas alineadas a los objetivos organizacionales y, después de la recolección y análisis de los datos, los resultados deben ser utilizados para identificar desvíos y aplicar las acciones necesarias.

Para que las acciones correctivas sean determinadas eficientemente, es esencial que las medidas y previsiones sean confiables, o sea, es necesario que las mediciones y los análisis se hagan correctamente para asegurar que las previsiones sobre el alcance de los objetivos de desempeño y de calidad de los procesos sean factibles. Otro factor muy importante para la predicción del alcance de los objetivos es la capacidad de entender la naturaleza y extensión de las variaciones detectadas en el desempeño de los procesos del proyecto cuando estos no se presentan adecuados para lograr los objetivos establecidos. Para eso, la gestión cuantitativa de proyecto utiliza técnicas cuantitativas que auxilian en el entendimiento y predicción del desempeño y calidad de los procesos, así como en la identificación de las acciones correctivas que deben ser realizadas para resolver posibles desvíos con relación al alcance de los objetivos.

(11)

5.2.2 Quality Function Deployment (QFD)

Quality Function Deployment (QFD) fue concebido en el Japón en el final de los años 60, como un método de desarrollo de nuevos productos en el contexto de la Calidad Total [AKAO, 1997].

El QFD provee una estructura para el ciclo de desarrollo. Esa estructura puede ser comparada a la estructura de una casa donde la base es formada por los requisitos del cliente [BOSERT, 1991]. Según EUREKA e RYAN [1992], el QFD es una forma sistemática de asegurar que el desarrollo de atributos, características y especificaciones del producto, así como la selección y el desarrollo de equipamientos, métodos y controls del proceso sean dirigidos hacia las demandas del cliente o del mercado. Este método traduce las necesidades de los clientes en requisitos apropiados para la organización, en cada ciclo del desarrollo del producto, desde la investigación y el desarrollo hasta la ingeniería. De esa forma, el QFD disminuye problemas en el inicio de la producción, minimiza cambios en el proyecto, acorta los ciclos de desarrollo, maximiza la productividad y reduce los costos.

La principal característica del QFD es el foco en los requisitos del cliente. El proceso es guiado por lo que el cliente quiere, y no por innovaciones tecnológicas.

Consecuentemente, un esfuerzo mayor es dedicado al levantamiento de las informaciones necesarias para determinar lo que el cliente realmente quiere. Ese esfuerzo tiende a aumentar el tiempo de la planificación inicial del proyecto, pero reduce el tiempo total del desarrollo [BOSERT, 1991].

El QFD es realizado por medio de una serie de matrices, que desdoblan las necesidades del cliente y los requisitos técnicos con ellas relacionados, a partir de la planificación y del proyecto del producto. Cada matriz es popularmente llamada como “casa de la calidad” [EUREKA e RYAN, 1992]. El QFD envuelve básicamente cuatro fases que ocurren en el proceso de desarrollo del producto. Durante cada fase una o más “casas de la calidad” son preparadas para ayudar en la planificación y comunicar cuales procesos e informaciones del proyecto son críticos [EUREKA e RYAN, 1992; D'OLIVEIRA, 2003].

La primera fase del QFD se refiere a la planificación del producto y tiene como objetivos principales: (i) definir y priorizar las necesidades de los clientes; (ii) analizar las oportunidades ofrecidas por sus competidores; (iii) planificar el producto para responder a las necesidades y oportunidades, y (iv) establecer los valores de las características críticas.

La segunda fase, desdoblamiento de componentes, se refiere al montaje y características de componentes, donde se desdoblan algunos de los requisitos del proyecto, identificados en la fase anterior, a nivel de subsistema y componentes. La

“casa de la calidad” resultante de esta fase sirve de base para todas las actividades preliminares de proyecto. Sin embargo, no todos los requisitos de proyecto son desdoblados, apenas aquellos que representen riesgos al proyecto (nuevos, difíciles, y extremamente importantes) son desdoblados.

La tercera fase, denominada de planificación del proceso, representa la transición del proyecto hacia las operaciones de fabricación, donde un diagrama de la planificación del proceso es registrado para cada característica crítica de componente (identificado en la fase anterior).

(12)

La cuarta fase, planificación de la producción, se tiene alta consideración por el control de la calidad y del proceso donde las informaciones generadas son transferidas a la fábrica.

Según BOSERT [1991] además de las cuatro fases, existen algunos pasos que deben ser seguidos para construir la “casa de la calidad” del QFD:

(i). Definir los requisitos del cliente: definir los objetivos dictados por el cliente (qué);

(ii). Definir la importancia de los requisitos del cliente;

(iii). Definir los requisitos del producto: el objetivo de este paso es establecer los requisitos del producto (“como”) que responden a las necesidades de los clientes;

(iv). Identificar relaciones entre los requisitos del cliente y los requisitos del producto;

(v). Identificar correlaciones entre los requisitos del producto: determinar las correlaciones entre los requisitos del producto o características técnicas utilizando símbolos para las relaciones fuertes, medianas, positivas o negativas. Se debe evaluar cada requisito del producto en relación a todos los otros. En caso de que la implementación de un requisito pueda perjudicar la implementación de otro, se considera que existe una correlación negativa entre ellos;

(vi). Realizar la evaluación competitiva técnica: desarrollar una comparación con la competencia sobre los requisitos del producto;

(vii). Definir la importancia de los requisitos del producto: calcular la importancia de los requisitos del producto, obtenida por medio de la multiplicación del peso de los requisitos del cliente por el factor de relacionamiento. Un factor de relacionamiento es definido como fuerte, mediano o débil e indica el grado de la relación entre los requisitos del cliente y los requisitos del producto;

(viii). Determinar el valor ideal para los requisitos del producto: cuantificar los requisitos del producto encontrando su valor ideal por medio de la comparación de las características técnicas relacionadas a los requisitos del producto de la organización en relación a sus competidores. Inmediatamente después, el equipo debe analizar los requisitos del cliente y del producto buscando inconsistencias. Ese análisis puede mostrar puntos que necesitan de mejora y dónde las estrategias de mercado deben ser mejoradas. Es necesario realizar una evaluación de la dificultad relacionada a cada característica técnica. Generalmente, esa evaluación es hecha por medio de una escala de 1 (baja) a 5 (alta) lo que podrá ayudar a determinar el esfuerzo de desarrollo de los requisitos del producto; y

(ix). Analizar la “Casa de la Calidad”: analizar la “casa de la calidad” y finalizar la estrategia de desarrollo del producto. Determinar las áreas que merecen enfoque y las acciones operativas necesarias. Pueden ser tomadas varias decisiones analizando la “casa de la calidad”.

El uso del QFD en proyectos de software puede traer beneficios, entre ellos [BOSERT, 1991; HAAG et al., 1996]:

• Aumento de la atención a las perspectivas de los clientes;

(13)

• Uso efectivo de las informaciones competitivas;

• Mejora en la comunicación entre los departamentos y con los usuarios;

• Priorización de recursos;

• Fundamentación para justificar las decisiones;

• Disminución de futuras redundancias en el desarrollo;

• Cuantificación cualitativa de los requisitos del cliente;

• Representatividad de los datos facilitando el uso de medidas;

• Definición más rápida de las características del producto; y

• Capacidad de adaptación a varias metodologías.

5.2.3 La norma Internacional ISO/IEC 9126

La calidad deseable en un producto de software está relacionada a los requisitos identificados por el cliente. Al desarrollar un producto con la calidad deseada por el usuario, es de esperar que se obtenga la satisfacción del usuario. Sin embargo, identificar los requisitos de calidad de un producto no es una tarea trivial. Para auxiliar en esta tarea, se puede describir la calidad de un producto por medio de un conjunto de características que deben ser logradas en un determinado grado para que el producto atienda a las necesidades de sus usuarios. Cada una de las características de calidad puede ser detallada en varios niveles de subcaracterísticas, llegándose a un amplio conjunto de atributos que describen la calidad de un producto de software. En ese contexto, la norma ISO/IEC 9126-1 [ISO/IEC, 2001] fue definida buscando consolidar en un modelo las diferentes visiones de la calidad. Actualmente, esta norma está siendo revisada bajo la identificación ISO/IEC 25010, estando previstas cambios en el modelo de calidad.

La norma internacional ISO/IEC 9126-1 [ISO/IEC, 2001] define un modelo de calidad que organiza las características y subcaracterísticas de calidad deseables para un producto de software. Ella puede ser usada para especificar y evaluar la calidad del producto, permitiendo validar la completitud de la definición de los requisitos, identificar los requisitos de software, identificar los objetivos del proyecto de software, identificar los objetivos de las pruebas de software, identificar los criterios de aseguramiento de la calidad e identificar los criterios de aceptación para un producto de software completo.

Esa norma tiene como objetivo apoyar la evaluación de los productos de software de modo que el producto evaluado cumpla con las necesidades específicas en un determinado contexto de uso. El modelo de calidad definido en la norma ISO/IEC 9126-1 [ISO/IEC, 2001] está subdivido en: (i) modelo de calidad para características internas y externas, y; (ii) modelo de calidad para calidad en uso.

La calidad interna es la totalidad de características del producto de software vista desde una perspectiva interna (de los desarrolladores), o sea por medio de sus artefactos estáticos. Ya la calidad externa es la totalidad de características observadas por una perspectiva externa (de los evaluadores o usuarios) y puede ser percibida cuando el producto es ejecutado. Por fin, la calidad en uso es la visión de calidad por la perspectiva de uso (de los usuarios) del producto de software. Esa

(14)

última mide el nivel de éxito en la realización de tareas por los usuarios en un entorno particular de operación, en vez de medir el producto de software en sí.

El modelo de calidad para características internas y externas clasifica los atributos de calidad en seis características:

• Funcionalidad: se refiere a la existencia de un conjunto de funciones que satisfacen las necesidades implícitas o explícitas y sus propiedades específicas.

Sus subcaracterísticas son: Adecuación, Exactitud, Interoperatividad, Seguridad de acceso y Conformidad de funcionalidad.

• Fabilidad: se refiere a la capacidad del software de mantener su nivel de desempeño, bajo condiciones establecidas, por un período de tiempo. Sus subcaracterísticas son: Madurez, Tolerancia a fallas, Recuperabilidad y Conformidad de fiabilidad.

• Usabilidad: se refiere al esfuerzo necesario para usar un producto de software, así como el juicio individual de tal uso por un conjunto explícito o implícito de usuarios. Sus subcaracterísticas son: Entendimiento, Aprendizaje, Operabilidad, Atractividad y Conformidad de usabilidad.

• Eficiencia: se refiere a la relación entre el nivel de desempeño del software y la cantidad de los recursos utilizados bajo las condiciones establecidas. Sus subcaracterísticas son: Comportamiento en relación al tiempo, Utilización de recursos y Conformidad de eficiencia.

• Capacidad de Mantenimiento: se refiere al esfuerzo necesario para hacer cambios específicos en el software. Sus subcaracterísticas son: Capacidad de ser analizado, Cambiabilidad, Estabilidad, Facilidad de Prueba y Conformidad de facilidad de mantenimiento

• Portabilidad: se refiere a la capacidad de que el software sea transferido de un entorno para otro. Sus subcaracterísticas son: Adaptabilidad, Facilidad de instalación, Coexistencia, Reemplazabilidad y Conformidad de portabilidad.

La calidad en uso también puede ser vista como la capacidad del producto de software para permitir que determinados usuarios logren metas especificas como eficacia, efectividad, productividad, seguridad y satisfacción en un contexto especificado. En el modelo de calidad en uso, los atributos son clasificados en cuatro características:

• Eficacia: se refiere a la capacidad de que el producto de software posibilite a los usuarios lograr sus metas especificadas con acurácia y completitud en un contexto de uso especificado;

• Productividad: se refiere a la capacidad del producto de software para posibilitar que los usuarios utilicen una cantidad adecuada de recursos en relación a la efectividad lograda en un contexto de uso especificado;

• Seguridad: se refiere a la capacidad del producto de software para ofrecer niveles aceptables de riesgo de daños a personas, negocios, software, propiedades o al entorno en un contexto de uso especificado; y,

• Satisfacción: se refiere a la capacidad del producto de software para satisfacer a los usuarios en un contexto de uso especificado.

(15)

Con el objetivo de auxiliar la medición de software durante el desarrollo de productos de software, guiando la definición de medidas para evaluación de la calidad, la norma internacional ISO/IEC 9126-1 [ISO/IEC, 2001] define un conjunto de medidas para evaluación de cada característica de calidad en ella definida. Las medidas están divididas en:

• Medidas internas: pueden ser aplicadas a un producto de software no ejecutable, durante fases de su desarrollo (como un pedido de propuesta, especificación de requisitos, especificación de proyecto o código fuente).

Medidas internas proporcionan a los usuarios la capacidad de medir la calidad de productos intermediarios y, así, prever la calidad del producto final. Eso permite al usuario identificar problemas relacionados a la calidad e iniciar acciones correctivas tempranas en el ciclo de desarrollo de software. Ejemplos de medidas internas definidas en esta norma son la remoción de defectos y el impacto de cambios.

• Medidas externas: pueden ser usadas para medir la calidad del producto de software por medio de la medición del comportamiento del sistema del cual él forma parte. Las medidas externas pueden ser usadas apenas durante la fase de pruebas en el ciclo de vida y durante cualquier fase operativa. La medición es realizada durante la ejecución del producto de software en el entorno de sistema en el cual él debe operar. Como ejemplo de medidas externas definidas en esta norma tenemos: adecuación funcional y tiempo medio entre fallas.

• Medidas de calidad en uso: miden si un producto satisface las necesidades especificadas por usuarios con respecto a lograr niveles definidos de eficiencia, productividad, seguridad y satisfacción en un contexto de uso especificado. Eso solo puede ser logrado en un entorno de sistema real. Frecuencia de error y escala de satisfacción son ejemplos de medidas de calidad en uso definidas en esta norma.

Para cada medida propuesta en los informes técnicos ISO/IEC 9126-2 [ISO/IEC, 2003a], ISO/IEC 9126-3 [ISO/IEC, 2003b], ISO/IEC 9126-4 [ISO/IEC, 2004a] son presentados el nombre y el propósito de la medida, el método para su aplicación, las fórmulas de cálculo de la medida y los elementos computacionales usados en la composición de la medida, la interpretación del valor medido, el tipo de escala de la medida, el tipo de medida, los datos de entrada para la medición, las referencias a la norma ISO/IEC 12207 [ISO/IEC, 2008] y los usuarios interesados en los resultados de la medida.

5.2.4 Simulación de procesos de software y dinámica de sistemas

Realizar cambios en procesos es una actividad frecuente en las organizaciones de software que invierten en mejora continua. Se espera que, para cada nuevo cambio, los efectos sean siempre positivos. No obstante, siempre hay un conjunto de incertidumbres asociadas que pueden implicar en resultados inesperados.

Resultados inesperados en proyectos de software son extremamente indeseables, especialmente para organizaciones que se vanaglorian por la calidad de sus productos y satisfacción de sus clientes. En este escenario, la simulación de procesos de software puede ser de gran utilidad.

(16)

Simular procesos de software consiste en la manipulación de modelos formales⁴ capaces de reproducir artificialmente la ejecución de los procesos. La simulación puede ser utilizada para auxiliar en la predicción del comportamiento del proceso y responder cuestiones del tipo "que ocurre si". En muchos casos, el objetivo es apoyar la toma de decisión, apoyar la reducción de riesgos y auxiliar en la gestión en los niveles operativo, táctico y estratégico.

Según [KELLNER et al., 1999] el propósito de utilizar la simulación puede ser agrupado en seis categorías:

• Gestión estratégica: parámetros organizacionales pueden ser manipulados para simular escenarios alternativos y apoyar la toma de decisión;

• Planificación: a medida que el plan es elaborado, el gerente del proyecto puede utilizar la simulación para observar el comportamiento del esfuerzo, costo, plazo, calidad del producto y otras variables de interés.

• Control y gestión operativa: Durante la ejecución de un proyecto, el gerente puede verificar el estado actual y manipular parámetros de los proyectos de modo que se verifiquen los potenciales efectos en los resultados del proyecto.

• Mejora de proceso y adopción de tecnología: La simulación puede apoyar en decisiones para optar o no por una propuesta de mejorar o actuar en la priorización de un conjunto de propuestas.

• Entendimiento: Por medio de la simulación del proceso, los gerentes, desarrolladores, grupo de calidad y demás interesados, pueden entender mejor el flujo del proceso, la secuencia y dependencia de las actividades y demás propiedades del proceso.

• Entrenamiento y aprendizaje: Personas pueden practicar y aprender sobre gestión de proyectos a partir de la simulación. El uso de la simulación, en este caso, es análogo al uso de simuladores de vuelo. En el entorno simulado, los aprendices pueden observar el impacto de acciones y decisiones más comunes, como reducir el tiempo para pruebas, optar por no realizar inspección y otras.

Para simular un proceso de software es necesario: (i) construir un modelo que represente el proceso de software de interés y que contenga un conjunto de parámetros de entrada y variables de respuesta; y (ii) registrar el modelo en un entorno de simulación cuyo objetivo sea facilitar la interacción con el modelo, por medio de los parámetros de entrada, y la observación de los efectos de la interacción por medio de las variables de respuesta.

La definición sobre el tipo de modelo a ser desarrollado para la simulación depende del propósito del modelo y de cuales cuestiones se desea investigar [KELLNER et al., 1999]. La determinación del alcance del modelo es una decisión que se debe tomar llevando en cuenta lo que se desea manipular, la amplitud los potenciales efectos de la manipulación y cómo los resultados de la manipulación deben o pueden ser observados. En general, el alcance está restringido a una parte del ciclo de vida, un proyecto de desarrollo, evolución de largo plazo de un producto o cuestiones de largo plazo en una organización. Estos cuatro alcances son

4 Modelo constituído por un conjunto de postulaciones matemáticas y lógicas con detalles suficientes para describir los objetivos y las limitaciones de un sistema [BARROS, 2001].

(17)

fundamentados por dos dimensiones: intervalo de tiempo y amplitud organizacional (menos de un proyecto o equipo, un proyecto o equipo, múltiples proyectos o equipos).

Son variables de respuesta típicas: esfuerzo y costo; nivel de defectos, ciclo del tiempo (duración, cronograma, intervalo), requisitos de personal sobre el tiempo, proporción de utilización del personal, costo/beneficio (ROI), desempeño/productividad; y backlogs. La abstracción del proceso requiere la identificación de todos sus elementos (actividades, artefactos, herramientas, técnicas, medidas asociadas y el propio proceso) y como ellos interactúan entre sí.

El desarrollo y el mantenimiento de software son caracterizados por la complejidad de la interacción entre personas, procesos y tecnologías. Cada uno de esos elementos incluye factores que pueden ejercer inúmeras influencias que se reflejan en el producto final. Con el propósito de entender sistemas que presentan este grado de complejidad, en el final de la década de 50, FORRESTER [1961] introdujo el concepto de Dinámica de Sistemas. FORRESTER describió un caso real en la industria de componentes electrónicos, donde desarrolló un modelo experimental y realizó un análisis sensitivo para identificar cuales partes del sistema productivo eran más cruciales para determinar su comportamiento. Con base en las observaciones, él propuso cambios en la política del sistema de producción real y fueron obtenidas mejoras.

En el dominio de la ingeniería de software, un trabajo que sirvió de marco y que exploró con profundidad el concepto Dinámica de Sistemas fue el de ABDEL-HAMID y MADNICK [1991]. Los autores construyeron un modelo que permite visualizar los potenciales efectos de la manipulación de factores que influencian al costo y a los esfuerzos necesarios para la conclusión de un proyecto de desarrollo de software.

Desde entonces, inúmeros estudios han sido conducidos en el dominio de la ingeniería de software con foco en áreas específicas, entre ellos: gestión de proyectos de software [COOPER y MULLEN, 1993], [LIN et al., 1997], [HENDERSON y HOWARD, 2000], ingeniería de software concurrente [POWELL, MANDER y BROWN, 1999], ingeniería de requisitos de software [CHRISTIE y STALEY, 2000], impacto de la mejora del proceso en el ciclo de vida [TVEDT y COLLOFELLO, 1995], [TVEDT, 1996], efectos de las actividades de la mejora de la calidad del software [ARANDA et al., 1993], [CHICHAKLY, 1993], [MADACHY, 1994], [MADACHY, 1996], gestión de confiabilidad de software [RUS, 1996], [RUS y COLLOFELLO, 1999], mantenimiento de software [CARTWRIGHT y SHEPPERD, 1999], evolución de software [LEHMAN y RAMIL,1999], outsourcing [ROEHLING et al., 2000], entrenamiento en ingeniería de software [MADACHY y TARBET, 2000], entre otros.

En todos estos estudios, el concepto de Dinámica de Sistemas es aplicado a la construcción de modelos capaces de reproducir artificialmente la ejecución de los procesos por medio de la simulación con la intención de responder cuestiones del tipo "que ocurre si".

de Software No son permitidas exclusiones de resultados de este proceso.

(18)

(Parte 8) Fábrica de Software (Parte 9)

No son permitidas exclusiones de resultados de este proceso.

Como no existen especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios en los resultados esperados.

No son permitidas exclusiones de resultados de este proceso.

Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios adicionales a los resultados esperados.

5.3 Resultados esperados

Además de todos los resultados esperados del proceso Gestión de Proyectos, ya implementados en los niveles anteriores⁵, en el nivel B, los resultados esperados GPR22⁶ a GPR28 son incorporados, reflejando el abordaje cuantitativo de la gestión de proyectos en este nivel. Estos resultados esperados del proceso Gestión de Proyectos están basados en el área de proceso Gestión Cuantitativa de Proyectos del CMMI-DEV [SEI, 2010].

5.3.1 GPR22 - (A partir del nivel B) Los objetivos de calidad y de desempeño del proceso definido para el proyecto son establecidos y mantenidos Este resultado esperado tiene como objetivo asegurar la definición de objetivos mensurables de calidad y de desempeño del proceso para cada proyecto, de una forma satisfactoria para la organización y los clientes involucrados.

La identificación de los objetivos de calidad y de desempeño debe partir de los objetivos de calidad y de desempeño de la organización. Sin embargo, es posible que no todos los objetivos de la organización sean aplicables al proyecto o que sea necesario incluir nuevos objetivos por las necesidades específicas del proyecto y del cliente. Es importante en este momento ser realista estableciendo objetivos viables de ser logrados. Una negociación entre los involucrados puede ser necesaria.

Siempre que necesario, los objetivos deben ser revisados.

La implementación de este resultado requiere, por lo tanto: (i) entendimiento de las características del proyecto; (ii) entendimiento de las necesidades de calidad del cliente y priorización de estas necesidades; (iii) transformar las necesidades del cliente en requisitos de software y objetivos de calidad; y (iv) entender el proceso y su desempeño actual por medio del análisis de datos históricos. Cuidado especial debe ser tomado para que los objetivos de calidad sean realmente derivados de las necesidades del cliente, esto es, de las necesidades de negocio.

5 Ver descripción detallada de la implementación de los demás resultados esperados en las partes 1 y 3 de la Guía de Implementación.

6 El resultado esperado GPR22 (A partir del nivel E) es reemplazado en el nivel B.

(19)

Para identificar las necesidades del cliente y prioridades, una técnica útil es el QFD (Quality Function Deployment). Una fuente importante de consulta sobre atributos de calidad es la ISO/IEC 9126. Una experiencia de implementación usando QFD es la ISO/IEC 9126 puede ser encontrada en [ANTONIOL et al., 2004]. Otro ejemplo puede ser encontrado en [CAMPOS et al., 2007].

Organizaciones que adquieren software deben establecer los objetivos de calidad del producto y de desempeño del proceso con base en los objetivos de la organización y del proyecto. Pueden, también, establecer objetivos para el proveedor, que en este caso deben estar definidos en el acuerdo [HOFMANN et al., 2007].

Sin comentario adicional para este resultado.

5.3.2 GPR23 - (A partir del nivel B) El proceso definido para el proyecto que le posibilita lograr sus objetivos de calidad y de desempeño se compone de técnicas estadísticas y de otras técnicas cuantitativas

Este resultado esperado tiene como objetivo asegurar que los subprocesos que serán parte del proceso definido para el proyecto sean seleccionados considerando las características del proyecto y datos históricos que evidencien la estabilidad y capacidad de los subprocesos.

Con ese resultado esperado, la definición del proceso para el proyecto es hecha de forma distinta de cómo es hecha del nivel E hasta el nivel C del MR-MPS. A partir del nivel B, la definición del proceso para el proyecto incluye identificar alternativas a uno o más procesos y subprocesos, ejecutar análisis cuantitativa de desempeño y seleccionar las alternativas más capaces de ayudar al proyecto para lograr sus objetivos de calidad y de desempeño [SEI, 2010].

La selección de los subprocesos que serán parte del proceso definido para el proyecto, que deben ser parte de la biblioteca de activos de la organización/unidad organizacional, impacta en la selección de los subprocesos que serán gestionados estadísticamente. Luego, es importante que sean subprocesos que puedan ser gestionados estadísticamente durante la ejecución del proyecto. De esta forma, es conveniente que GPR22, GPR23 y GPR24 sean implementados de forma iterativa.

Al componer los subprocesos, todavía es importante analizar la interacción de estos subprocesos para verificar si ellos interactúan de la forma deseada (ver AP 4.1 y, en especial, el RAP29). Este análisis puede ser hecho usando modelos dinámicos y simulación. Otro aspecto que debería ser evaluado es el riesgo de no lograr los objetivos de calidad y de desempeño definidos, lo que puede direccionar la

(20)

identificación de nuevas alternativas o áreas que requieran más atención gerencial [SEI, 2010].

5.3.3 GPR24 - (A partir del nivel B) Subprocesos y atributos críticos para evaluar el desempeño y que están relacionados al logro de los objetivos de calidad y de desempeño del proceso del proyecto son seleccionados Este resultado esperado tiene como objetivo seleccionar los subprocesos a ser gestionados cuantitativamente. Esta selección debe estar basada en los subprocesos seleccionados por la organización (RAP25) y en la relevancia de los subprocesos para el logro de los objetivos de calidad y de desempeño del proyecto.

Algunos subprocesos son críticos porque sus desempeños influencian o contribuyen significantemente para el alcance de los objetivos del proyecto. Estos subprocesos pueden ser buenos candidatos para la supervisión y control usando técnicas estadísticas y otras técnicas cuantitativas [SEI, 2010] (ver GPR26 y GPR27).

Así como en el contexto organizacional, no todos los subprocesos son objeto de análisis de desempeño, en el contexto del proyecto, ni todos los subprocesos que componen el proceso definido para el proyecto serán gestionados cuantitativamente.

Después de la selección de los subprocesos, se debe identificar los atributos del producto y del proceso que serán medidos y controlados, esto es, gestionados cuantitativamente. Algunos de estos atributos pueden servir como importantes indicadores para el desempeño esperado de futuros subprocesos a ser ejecutados y, así, pueden ser utilizados para evaluar el riesgo de no lograr parte de los objetivos de los proyectos (por ejemplo, usando modelos de desempeño de procesos) [SEI, 2010].

Caso la organización adquiriente desee utilizar, además de sus propios datos, los datos del proveedor, esto debe estar definido en el acuerdo.

5.3.4 GPR25 - (A partir del nivel B) Medidas y técnicas analíticas son seleccionadas para ser utilizadas en la gestión cuantitativa

A partir de la selección realizada en el alcance del resultado esperado anterior, es posible identificar medidas que apoyen la gestión cuantitativa y, también, seleccionar las técnicas estadísticas a ser utilizadas para el entendimiento de la variación de los subprocesos seleccionados y, consecuentemente, para el uso de la gestión del proyecto.

(21)

Estas medidas incluyen aquellas almacenadas en la biblioteca de activos organizacionales y, también, medidas adicionales, caso necesario. Con base en eso, líneas base y modelos de desempeño y técnicas estadísticas y otras técnicas cuantitativas pueden ser utilizadas para la gestión del proyecto [SEI, 2010]. Esas medidas deben ser asociadas a los objetivos de calidad del proyecto y de desempeño del proceso, bien como deben estar basadas en las medidas establecidas para la organización (RAP26). Sin embargo, pueden ser acrecentadas nuevas medidas para atender las necesidades del producto, del proceso y del cliente.

5.3.5 GPR26 - (A partir del nivel B) El desempeño de los subprocesos seleccionados para la gestión cuantitativa es monitoreado usando técnicas estadísticas y otras técnicas cuantitativas

El objetivo de este resultado esperado es usar técnicas estadísticas y otras técnicas cuantitativas para analizar la variación en el desempeño de los subprocesos y para determinar acciones necesarias para lograr los objetivos de desempeño y de calidad de cada subproceso o acciones relacionadas a deficiencias en la estabilidad o capacidad del proceso.

La capacidad de cada subproceso seleccionado es determinada con relación a los atributos de calidad y de desempeño establecidos para el subproceso. Estos objetivos son derivados de los objetivos de calidad y de desempeño establecidos para el proyecto.

De esa forma, la supervisión del desempeño de los subprocesos en el proyecto incluye supervisar la variación y la estabilidad del subproceso y evaluar la probabilidad de que el proceso logre con éxito sus objetivos de calidad y de desempeño, lo que significa comparar la capacidad del subproceso seleccionado para atender a los objetivos de calidad y de desempeño con relación a cada atributo del subproceso medido. Esta evaluación solo es posible de ser realizada cuando el subproceso es estable con relación al atributo. Es conveniente, para facilitar la comunicación de los resultados, que la exhibición de los resultados sea hecha de forma gráfica.

Además de eso, se debe identificar, cuando necesario, las acciones correctivas a ser tomadas para resolver las deficiencias con relación a la ejecución del proceso, buscando que el proyecto use un proceso de mayor capacidad que pueda satisfacer los objetivos de calidad del producto y de desempeño del proceso. El enfoque se da en las acciones correctivas relacionadas a la ejecución de los procesos. Sin embrago, causas especiales de variación de los procesos pueden revelar oportunidades de mejora a ser incorporadas futuramente en la definición del subproceso. Las acciones correctivas pueden estar relacionadas a la renegociación de los objetivos del proyecto, implementación de subprocesos alternativos o hasta realizar mediciones en subprocesos de nivel más bajo para conseguir mejor os datos de desempeño [SEI, 2010]. Además de eso, se puede ejecutar acciones para mejorar la implementación de un subproceso para reducir su variación o mejorar su desempeño (o sea, tratar causas comunes de variación) [SEI, 2010].

(22)

Con esta supervisión el adquiriente puede predecir la posibilidad de lograr los objetivos del proyecto a respecto de la calidad y del desempeño del proceso.

5.3.6 GPR27 - (A partir del nivel B) El proyecto es gestionado utilizando técnicas estadísticas y otras técnicas cuantitativas para determinar si sus objetivos de calidad y de desempeño del proceso serán logrados Este resultado esperado tiene como objetivo asegurar la gestión del proyecto con el uso de técnicas estadísticas y otras técnicas cuantitativas y del uso de múltiples datos de entrada para predecir si los objetivos de calidad y de desempeño de proceso del proyecto serán logrados [SEI, 2010]. Eso incluye la revisión periódica y en cortos intervalos de tempo (algunas veces diaria) del desempeño y de la capacidad de cada subproceso seleccionado para ser gestionado cuantitativamente para poder evaluar el progreso en dirección al logro exitoso de los objetivos de calidad y de desempeño del proceso del proyecto.

Con base en esta predicción, riesgos asociados con o sin el cumplimiento de los objetivos de calidad y de desempeño de proceso del proyecto son identificados y gestionados, y acciones para tratar las deficiencias son definidas conforme necesario [SEI, 2010]. Para cumplir este resultado esperado de forma integral, deben ser utilizados modelos que puedan anticipar (por medio de estimativas y simulaciones) cuales son las chances de lograr resultados futuros (por ejemplo, plazos, costos, calidad) con base en los valores actuales. Se tiene así una gestión proactiva.

Entradas clave para este análisis incluyen datos de la estabilidad y capacidad de cada subproceso (ver GPR26), así como datos de desempeño relacionados a la supervisión de otros subprocesos, riesgos y progreso de proveedores [SEI, 2010].

Ejemplos de acciones que pueden ser tomadas para tratar deficiencias contra el logro exitoso de los objetivos del proyecto incluyen [SEI, 2010]:

• alteración de los objetivos de calidad y de desempeño de modo que ellos estén dentro de la faja esperada del proceso definido para el proyecto;

• mejora en la implementación del proceso definido para el proyecto;

• adopción de nuevos subprocesos y tecnologías con potencial para lograr los objetivos y gestionar los riesgos asociados;

• identificación de riesgo y estrategias de mitigación de riesgo para las deficiencias;

(23)

• cancelación del proyecto.

Los subprocesos seleccionados son supervisados con respecto al desempeño, incluyendo los que tienen interacción con el proveedor.

Los productos de trabajo entregados por el proveedor, también son supervisados con respecto a los objetivos de calidad y de desempeño [HOFMANN et al., 2007].

5.3.7 GPR28 - (A partir del nivel B) Cuestiones que afectan los objetivos de calidad y de desempeño del proceso del proyecto son objeto de análisis de causa raíz

El objetivo de este resultado esperado es realizar análisis de causa en temas relacionados a deficiencias en la estabilidad y capacidad de subprocesos y deficiencias en el desempeño del proyecto con relación a sus objetivos. Análisis de causas raíz de los temas seleccionados trae más beneficios si se hace luego después de que el problema sea inicialmente identificado, mientras que el evento es reciente lo suficiente para ser investigado cuidadosamente [SEI, 2010]. La formalidad y el esfuerzo requerido para un análisis de causa raíz puede variar enormemente [SEI, 2010]. Más detalles sobre Análisis de Causa y Resolución pueden ser vistos en la Parte 7 de la Guía de Implementación.

6 Los atributos de proceso del nivel B

De acuerdo con la Guía General del MR-MPS, “la capacidad del proceso es representada por un conjunto de atributos de proceso descrito en términos de resultados esperados. La capacidad del proceso expresa el grado de refinamiento e institucionalización con que el proceso es ejecutado en la organización/unidad organizacional. En el MR-MPS, a medida que la organización/unidad organizacional evoluciona en los niveles de madurez, debe lograr un mayor nivel de capacidad para desempeñar el proceso” [SOFTEX, 2011a].

Los atributos de proceso en el nivel B buscan asegurar que los procesos operan dentro de límites definidos. Sin embargo, no todos los procesos/subprocesos necesitan ser objeto de análisis del desempeño. La elección se hace a partir de la identificación de los objetivos de negocio de la organización y de la importancia de los procesos/subprocesos para el logro de estos objetivos (ver RAP22 a RAP25).

Como los atributos de proceso son acumulativos, para lograr el nivel B, además de los atributos de proceso AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2, una unidad

(24)

organizacional debe implementar los resultados esperados de atributos de proceso RAP26 a RAP34 para todos los procesos y/o subprocesos seleccionados para análisis de desempeño. La implementación de los resultados RAP22 a RAP25 es obligatoria para todos los procesos del MPS.

Atención especial debe ser dada al orden de los resultados esperados de este atributo de proceso. El objetivo de los resultados esperados de atributos de proceso del RAP22 al RAP25 es identificar los procesos/subprocesos para los cuales tiene sentido que sean gestionados cuantitativamente y no simplemente aquellos que se desearía gestionar cuantitativamente. Estos resultados esperados son ejecutados, en general, en conjunto, de modo organizacional, para que se pueda seleccionar los procesos/subprocesos. De esa forma, a principio y en teoría, todos los procesos del MR-MPS podrían ser candidatos a la gestión cuantitativa, no obstante, eso tiene sentido para apenas un subconjunto de estos procesos. Así, los resultados a partir del RAP26 son implementados apenas para aquellos procesos del MR-MPS para los cuales tiene sentido la gestión cuantitativa (conforme demostrado por la ejecución del RAP25).

En una evaluación, según el MA-MPS [SOFTEX, 2011b], para considerar un proceso como “SATISFACTORIO” con relación al nivel B, se exige que estos nuevos atributos de proceso (AP 4.1 y AP 4.2) sean caracterizados como T (Totalmente implementado) o L (Ampliamente implementado). Todos los demás atributos de proceso (AP 1.1 a AP 3.2) deben ser caracterizados con T (Totalmente implementado).

A seguir, los atributos de proceso AP 4.1 y AP 4.2 son descritos con detalles, precedidos de una breve fundamentación teórica.

No hay ninguna alteración en los resultados esperados para los atributos de proceso debido al hecho de tratarse de una organización que adquiere software. Además, estos resultados deberán ser interpretados en el contexto de los procesos definidos para esta situación.

No son permitidas exclusiones de resultados de atributos de proceso.

No hay ninguna alteración en los resultados esperados para los atributos de proceso debido al hecho de tratarse de una organización del tipo Fábrica de Software. Además, estos resultados deberán ser interpretados en el contexto de los procesos definidos para la Fábrica de Software.

No hay ninguna alteración en los resultados esperados para los atributos de proceso debido al hecho de tratarse de una organización del tipo Fábrica de Pruebas. Además, estos resultados deberán ser interpretados en el contexto de los procesos definidos para la Fábrica de Pruebas.