guía general del mps.br v1

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

Guía General MPS de Software

Esta guía contiene la descripción general del Modelo MPS y detalla el Modelo de Referencia MPS para Software (MR-MPS-SW) y las definiciones comunes necesarias para su entendimiento y aplicación.

VIGENCIA Y TRANSICIÓN: La Guía General MPS de Software: 2012 entra en vigor el 24 de agosto de 2012. Así, a partir de esta fecha pueden ser realizadas evaluaciones MPS usando el Modelo de Referencia MPS para Software MR-MPS-SW:2012.

Diciembre de 2012

Copyright © 2012 - SOFTEX Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN (Solicitado a la Biblioteca Nacional)

MPS.BR – Guía General MPS de Software:2012 2/57

Índice

1 Prefacio ................................................................................................................. 4

2 Introducción ........................................................................................................... 6

3 Objetivo ................................................................................................................. 7

4 Términos y definiciones......................................................................................... 7

5 Símbolos y abreviaturas ...................................................................................... 12

6 Descripción general del modelo MPS ................................................................. 12

7 Base técnica para la definición del modelo MPS ................................................ 14 7.1 ISO/IEC 12207:2008 ..................................................................................... 14

7.2 ISO/IEC 15504 .............................................................................................. 15 7.3 ISO/IEC 20000 .............................................................................................. 15 7.4 CMMI-DEV® .................................................................................................. 16 7.5 CMMI-SVC® .................................................................................................. 16

8 Descripción del MR-MPS-SW ............................................................................. 17 8.1 NIVELES DE MADUREZ ...................................................................................... 17

8.2 PROCESO ....................................................................................................... 17 8.3 CAPACIDAD DEL PROCESO ............................................................................... 17

8.4 EXCLUSIÓN DE PROCESOS ............................................................................... 23

9 Descripción detallada de los procesos ................................................................ 25

9.1 NIVEL G – PARCIALMENTE GESTIONADO ........................................................... 25 9.1.1 Proceso: Gestión de Proyectos - GPR ............................................... 25

9.1.2 Proceso: Gestión de Requisitos - GRE .............................................. 28 9.2 NIVEL F – GESTIONADO ................................................................................... 29

9.2.1 Proceso: Adquisición - AQU ............................................................... 29

9.2.2 Proceso: Gestión de Configuración - GCO ........................................ 30

9.2.3 Proceso: Aseguramiento de la Calidad - GQA ................................... 31 9.2.4 Proceso: Gestión de Portafolio de Proyectos – GPP ......................... 32

9.2.5 Proceso: Medición - MED ................................................................... 33 9.3 NIVEL E – PARCIALMENTE DEFINIDO ................................................................. 34

9.3.1 Proceso: Evaluación y Mejora del Proceso Organizacional - AMP .... 34

9.3.2 Proceso: Definición del Proceso Organizacional - DFP ..................... 35 9.3.3 Proceso: Gestión de Recursos Humanos - GRH ............................... 36

9.3.4 Proceso: Gestión de Reutilización - GRU .......................................... 37 9.4 NIVEL D – AMPLIAMENTE DEFINIDO................................................................... 38

9.4.1 Proceso: Desarrollo de Requisitos - DRE .......................................... 38 9.4.2 Proceso: Integración del Producto - ITP ............................................. 39 9.4.3 Proceso: Diseño y Construcción del Producto - PCP ......................... 40

9.4.4 Proceso: Validación - VAL .................................................................. 41 9.4.5 Proceso: Verificación - VER ............................................................... 42

9.5 NIVEL C – DEFINIDO ........................................................................................ 43 9.5.1 Proceso: Desarrollo para Reutilización - DRU .................................... 43 9.5.2 Proceso: Gestión de Decisiones - GDE ............................................. 44

9.5.3 Proceso: Gestión de Riesgos - GRI ................................................... 45


9.6 NIVEL B – GESTIONADO CUANTITATIVAMENTE ................................................... 46 9.7 NIVEL A – EN OPTIMIZACIÓN ............................................................................ 47

10 Instituciones Implementadoras (II) ...................................................................... 48

Referencias Bibliográficas ......................................................................................... 49

Lista de colaboradores de la Guía General MPS de Software:2012 ......................... 52

Lista de colaboradores de la Guía General:2011 ...................................................... 53

Lista de colaboradores de la Guía General:2009 – Junio/2009 ................................. 54

Lista de colaboradores de la Guía General versión 1.2 – Junio/2007 ....................... 55

Lista de colaboradores de la Guía General versión 1.1 – Mayo/2006 ....................... 56

Lista de colaboradores de la Guía General versión 1.0 – Mayo/2005 ....................... 57


1 Prefacio

El MPS.BR1 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, Tecnología e Innovación (MCTI), 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/FUMIN).

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

a) meta técnica, tiene 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) autorizadas para prestar servicios de consultoría de implementación del Modelo de Referencia MPS para Software (MR-MPS-SW) y/o del Modelo de Referencia MPS para Servicios (MR-MPS-SV); (iii) Instituciones Evaluadoras (IA) autorizadas para prestar servicios de evaluación siguiendo el método de evaluación (MA-MPS); (iv) Instituciones de Consultoría de Adquisición (ICA) autorizadas para prestar servicios de consultoría de adquisición de software y/o servicios asociados;

b) meta de negocio, tiene como objetivo la diseminació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 micro, pequeñas y medianas empresas (que constituyen su foco principal), así como en grandes organizaciones privadas y gubernamentales, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops MPS; (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 una Unidad de Ejecución del Programa (UEP) y dos estructuras de apoyo para llevar a cabo 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 puede contar con 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 valor y calidad al programa.

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.

1 MPS.BR, MR-MPS-SW, MR-MPS-SV, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla

MPS.BR está asociada al programa MPS.BR, que es coordinado por la SOFTEX. La sigla MPS es una marca genérica asociada al modelo MPS, comprendiendo tanto la sigla MPS-SW asociada a la Mejora de Proceso de Software, así como la sigla MPS-SV asociada a la Mejora de Proceso de Servicios.


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

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

Guía General MPS de Servicios:2012 [SOFTEX, 2012a];

Guía de Evaluación:2012 [SOFTEX, 2012b];

Guía de Adquisición:2011 [SOFTEX, 2011a];

Guía de Implementación – Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS:2011 [SOFTEX, 2011b];

Guía de Implementación – Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS:2011 [SOFTEX, 2011c];

Guía de Implementación – Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS:2011 [SOFTEX, 2011d];

Guía de Implementación – Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS:2011 [SOFTEX, 2011e];

Guía de Implementación – Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS:2011 [SOFTEX, 2011f];

Guía de Implementación – Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS:2011 [SOFTEX, 2011g]; y

Guía de Implementación – Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS:2011 [SOFTEX, 2011h];

Guía de Implementación – Parte 8: Implementación del MR-MPS:2011 (Niveles G a A) en organizaciones que adquieren software [SOFTEX, 2011i];

Guía de Implementación – Parte 9: Implementación del MR-MPS:2011 (Niveles G a A) en organizaciones del tipo Fábrica de Software [SOFTEX, 2011j];

Guía de Implementación – Parte 10: Implementación del MR-MPS:2011 (Niveles G a A) en organizaciones del tipo Fábrica de Pruebas [SOFTEX, 2011k]; y

Guía de Implementación – Parte 11: Implementación y Evaluación del MR-MPS-SW en Conjunto con el CMMI-DEV 1.3 [SOFTEX, 2012c].

Esta Guía General MPS de Software describe de forma detallada el Modelo de Referencia MPS para Software (MR-MPS-SW) y proporciona una visión general sobre las demás guías que apoyan la implementación de los diversos niveles del MR-MPS-SW, bien como sobre los procesos de evaluación y de adquisición. Esta guía tiene como referencias la Norma Internacional ISO/IEC 12207:2008 [ISO/IEC,

2 El MR-MPS-SW es la nueva nomenclatura utilizada para el MR-MPS.


2008a], la Norma Internacional ISO/IEC 15504 [ISO/IEC, 2003] y el modelo CMMI-DEV® (Capability Maturity Model Integration for Development) [SEI, 2010a]. El detalle de la Guía General MPS de Software incluye la definición de los niveles de madurez, sus procesos y capacidad, además de los resultados esperados proporcionando una estructura de trabajo para una institución que desee implementar el MR-MPS-SW.

La versión 2012 de la Guía General incorpora los siguientes cambios con relación a la versión 2011:

Alteración de la nomenclatura de Guía General para Guía General MPS de Software;

Alteración de la nomenclatura de Modelo de Referencia (MR-MPS) para Modelo de Referencia MPS para Software (MR-MPS-SW);

Alteraciones en el Prefacio y en la Introducción incluyendo el nuevo Modelo de Referencia MPS para Servicios (MR-MPS-SV); y

revisión y adecuación de las referencias bibliográficas;

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 para el éxito de industria de software. Para que se tenga un sector de software competitivo a nivel nacional e internacional, 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, como presuposición, que sea aprovechada 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 la necesidad de implantar los principios de ingeniería de software de manera apropiada en el 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 software y servicios asociados y también para la mejora de la calidad y productividad de los servicios prestados. Dentro de este contexto, el modelo MPS posee cuatro componentes:


Modelo de Referencia MPS para Software (MR-MPS-SW), Modelo de Referencia MPS para Servicios (MR-MPS-SV), Método de Evaluación (MA-MPS) y Modelo de Negocio para Mejora de Proceso de Software y Servicios.

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

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

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

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 deseen adquirir productos de software y servicios asociados apoyándose en el MR-MPS [SOFTEX, 2011a];

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) [SOFTEX, 2012b];

Guía de Implementación: serie de documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS-SW [SOFTEX, 2011b], [SOFTEX, 2011c], [SOFTEX, 2011d], [SOFTEX, 2011e], [SOFTEX, 2011f], [SOFTEX, 2011g], [SOFTEX, 2011h], [SOFTEX, 2011i], [SOFTEX, 2011j], [SOFTEX, 2011k] y [SOFTEX, 2012c].

3 Objetivo

Esta Guía General MPS de Software tiene como objetivo describir de forma detallada el MR-MPS-SW y las definiciones comunes entre los diversos documentos que componen el MPS.BR.

Este documento está dirigido, pero no se limita, a organizaciones interesadas en utilizar el MR-MPS-SW para mejora de sus procesos de software, Instituciones Implementadoras (II), Instituciones Evaluadoras (IA) y otros interesados en procesos de software que pretendan conocer y utilizar el MR-MPS-SW como referencia técnica.

4 Términos y definiciones

Activo de dominio: Activo reutilizable producido a partir de la ingeniería de dominio.

Activo de proceso: Cualquier cosa que la organización considere útil para lograr los objetivos del proceso, por ejemplo, políticas, procesos definidos, lecciones aprendidas, modelos de documentos, estándares, material de entrenamiento [SEI, 2010a].

Activo reutilizable: Un elemento, como, por ejemplo, diseño, especificación, código fuente, documentación, casos de pruebas, manuales, procedimientos, etc., que fue proyectado para utilización en múltiples contextos.


Alcance de la evaluación: Una definición de los limites organizacionales de la evaluación, los procesos que están incluidos y el contexto en el cual los procesos a ser evaluados son llevados a cabo [ISO/IEC, 2004a].

Alta Gerencia: Persona(s) que proporciona(n) la política y las directrices generales para el proceso, pero no realiza(n) su supervisión y control del día a día. Tales personas pertenecen a un nivel de gerencia superior al del responsable por el proceso y pueden ser (pero no necesariamente) directores [SEI, 2010a].

Atributo de proceso: Una característica mensurable de la capacidad del proceso aplicable a cualquier proceso [ISO/IEC, 2004a].

Capacidad del proceso: Una caracterización de la habilidad del proceso para lograr los objetivos de negocio actuales o futuros [ISO/IEC, 2004a].

Componente del producto: Es una parte del producto final o algo usado en su desarrollo (por ejemplo, un subproducto, un proceso, una herramienta) que es parte de la entrega. Los componentes son integrados sucesivamente en niveles para componer el producto final [SEI, 2010a].

Coordinador local: Responsable por apoyar la planificación y coordinar las actividades de la evaluación. Esta persona ayuda al evaluador líder a escoger al equipo de evaluación y asegura que todos los entrevistados estén disponibles en el momento señalado. Él también es responsable por la logística requerida para el buen andamiento de la evaluación y asegura que la documentación necesaria esté disponible, comprometiéndose con la devolución de esa documentación al destino correcto.

Elemento de configuración: Una entidad dentro de una configuración que cumple una función de uso final y que se puede identificar de forma única en una determinada línea base. Un elemento de configuración puede agregar varios productos de trabajo, pero se debe tratar como una entidad singular por el proceso Gestión de Configuración. Todos los cambios en los productos de trabajo identificados como elementos de configuración se deben controlar por el proceso Gestión de Configuración [ABNT, 2009] [SEI, 2010a].

Equipo Técnico del Modelo (ETM): Equipo técnico responsable por la definición y perfeccionamiento del MR-MPS, MA-MPS y guías específicas. También, es responsable por el programa anual de entrenamiento del MPS.BR, compuesto por cursos, pruebas y workshops.

Evaluación: Una determinación sistemática del grado con que una entidad cumple los criterios establecidos para ella [ABNT, 2009].

Evaluación de proceso: Una evaluación disciplinada de los procesos de la organización con relación a un modelo de evaluación de proceso [ISO/IEC, 2004a].

Evaluador adjunto: Una persona que tiene una autorización formal de la SOFTEX para llevar a cabo una evaluación MPS como evaluador adjunto. El evaluador adjunto apoya al evaluador líder y al equipo de evaluación en la ejecución de la evaluación.

Evaluador líder: Una persona que tiene una autorización formal de la SOFTEX para llevar a cabo una evaluación MPS, como líder del equipo de evaluación, utilizando el Método de Evaluación MA-MPS.

Evaluar / auditar objetivamente: Revisar actividades y productos de trabajo por un grupo que no estuvo participando directamente en la ejecución de esas actividades y


en la elaboración de esos productos de trabajo con base en criterios que minimicen la subjetividad y la tendencia del revisor. Un ejemplo de evaluación objetiva es una auditoria de requisitos, estándares o procedimientos por un grupo de aseguramiento de la calidad independiente [SEI, 2010a].

Evidencia objetiva: Datos que demuestran la existencia o veracidad de alguna cosa [ISO/IEC, 2004a].

NOTA: Evidencia objetiva puede ser obtenida por observación, medición, pruebas u otros medios.

Foro de Acreditación y Control (FCC): Foro con representantes de la Industria (SOFTEX), academia y gobierno, responsable por el análisis y el parecer que auxilian las decisiones sobre acreditación (autorización) y desacreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA).

Ingeniería de dominio: Un abordaje basado en reutilización para definir el alcance, especificar la estructura y construir activos (por ejemplo, requisitos, diseño, código fuente, documentación) para una clase de sistemas, subsistemas o aplicaciones. La ingeniería de dominio puede incluir las siguientes actividades: definición de dominio, análisis de dominio, desarrollo de la arquitectura de dominio e implementación de dominio.

Institución Evaluadora (IA): Institución autorizada, mediante convenio con la SOFTEX, como evaluadora siguiendo el MA-MPS.

Institución Implementadora (II): Institución autorizada, mediante convenio con la SOFTEX, como implementadora del MR-MPS.

Institución Organizadora de Grupo de Empresas (IOGE): Institución autorizada, mediante convenio con la SOFTEX, como organizadora de grupo de empresas para la implementación del MR-MPS-SW y MR-MPS-SV y evaluación siguiendo el MA-MPS.

Interesados (stakeholders): Un individuo o un grupo que es responsable o afectado por el producto de una tarea, actividad o proceso. Puede incluir al equipo del proyecto, proveedores, clientes y usuarios del producto entre otros [SEI, 2010a].

Línea Base (baseline): Una versión formalmente aprobada de un elemento de configuración, independiente del medio, formalmente definida y fijada en un determinado momento durante el ciclo de vida del elemento de configuración [ABNT, 2009].

Medición: Conjunto de operaciones con el objetivo de determinar el valor de una medida [ISO/IEC, 2007].

Medida: La variable para la cual un valor le es atribuido como resultado de una medición [ISO/IEC, 2007].

Método de evaluación MA-MPS: Método que orienta la ejecución de una evaluación de conformidad al MR-MPS. El MA-MPS está en conformidad con la Norma Internacional ISO/IEC 15504.

Mini equipo: Subconjunto del equipo de evaluación que es responsable por evaluar los procesos que le son atribuidos por el evaluador líder.

Modelo de dominio: Un producto del análisis de dominio que proporciona una representación de los requisitos de un dominio. El modelo de dominio identifica y describe la estructura de los datos, flujo de información, funciones y restricciones


que están incluidos en aplicaciones pertenecientes al dominio. El modelo de dominio describe las similitudes y variaciones entre los requisitos de aplicaciones pertenecientes al dominio.

Modelo de referencia de proceso: Un modelo que comprende definiciones de procesos en el ciclo de vida, descrito en términos de propósitos y resultados, en conjunto con una arquitectura que describe las relaciones entre los procesos [ISO/IEC, 2004a].

Nivel de madurez: Grado de mejora de proceso para un conjunto predeterminado de procesos en el cual todos los resultados esperados del proceso y de los atributos de los procesos se cumplen.

Observador: Responsable por observar la conducción de una evaluación por un evaluador líder en proceso de formación. El observador no participa de la evaluación, salvo si ocurre algún problema grave durante la evaluación.

Oportunidad de mejora: Una implementación de un resultado de proceso que puede ser mejorada, pero que cumple los requisitos mínimos de un resultado requerido por algún proceso de nivel del MR-MPS-SW o MR-MPS-SV evaluado.

Participante de la evaluación: Un individuo que tiene responsabilidades dentro de la extensión de la evaluación [ISO/IEC, 2004a].

NOTA: Ejemplos incluyen, pero no se limitan a, los evaluadores líder y adjunto, promotor, miembros de la unidad organizacional, miembros del equipo de evaluación, coordinador local.

Perfil del proceso: Un conjunto de puntuación de atributos de proceso para un proceso evaluado [ISO/IEC, 2004a].

Portafolio de proyectos: Colección de proyectos que tratan de los objetivos estratégicos de la organización [ISO/IEC, 2008a].

Proceso: Un conjunto de actividades relacionadas o interactivas, que transforma insumos (entradas) en productos (salidas) [ABNT, 2001].

Proceso de calificación: Proceso para demostrar la capacidad para cumplir con los requisitos especificados [ABNT, 2001].

NOTA 1: El término “calificado” es usado para designar una situación correspondiente.

NOTA 2: Calificación se puede aplicar a personas, productos, procesos o sistemas.

Proceso de evaluación: Determinación de la extensión con que el proceso estándar de la organización contribuye para lograr sus objetivos de negocio y para ayudar a la organización a enfocar la necesidad de mejora de proceso continua [ISO/IEC, 2004a].

Proceso definido: Un proceso que es gestionado (planificado, supervisado y ajustado) y adaptado de un conjunto de procesos estándar de acuerdo con las guías de adaptación de la organización [ISO/IEC, 2004a].

Proceso estándar: Un conjunto de definiciones de procesos básicos que guían todos los procesos en la organización [ISO/IEC, 2004a].

NOTA 1: Esas definiciones de procesos cubren los elementos de procesos principales (y sus relaciones) que se deben incorporar dentro de los procesos definidos que son implementados en los proyectos por la organización. Un proceso estándar establece consistencia entre las actividades de la organización y es deseable para la estabilidad y la mejora a largo plazo.

NOTA 2: El conjunto de procesos estándar de la organización describe los elementos de procesos principales que serán parte de los procesos definidos para el proyecto. También


describe las relaciones (por ejemplo: secuencia e interfaces) entre esos elementos del proceso.

Producto: Un producto de trabajo que se pretende entregar a un cliente o usuario final. La forma de un producto puede variar en contextos diferentes [SEI, 2010a].

Producto de trabajo: Un artefacto asociado a la ejecución de un proceso [ISO/IEC, 2004a].

NOTA: Un producto de trabajo puede ser usado, producido o modificado por un proceso.

Programa de reutilización: Un mecanismo utilizado por la organización que establece las metas, extensión y estrategias para el tratamiento de temas relacionados al negocio, personas, proceso y tecnología involucrados en la adopción de la reutilización de software.

Promotor de la evaluación: Un individuo, interno o externo a la unidad organizacional que será evaluada, que solicita la evaluación y suministra recursos financieros u otros recursos para que la evaluación sea llevada a cabo en

la unidad organizacional [ISO/IEC, 2004a].

Propósito del proceso: El objetivo general de la ejecución del proceso. Conviene que la implementación del proceso proporcione beneficios tangibles a los involucrados [ISO/IEC, 2004a].

Proyecto: Un emprendimiento realizado para crear un producto, servicio o resultado específico. El proyecto se caracteriza por temporalidad y resultado, servicio o producto único y elaboración progresiva [PMI, 2008].

Puntos débiles: Una implementación inadecuada o que no cumple los requisitos de un resultado requerido por algún proceso del nivel de madurez evaluado.

Puntos fuertes: Una implementación excepcionalmente buena de un resultado de proceso o de algo que supera lo requerido para el nivel de madurez evaluado.

Resultado esperado del proceso: Un resultado observable del logro exitoso del propósito del proceso [ISO/IEC, 2008a].

NOTA 1: Un resultado puede ser: un artefacto producido, un cambio significativo de estado y el cumplimiento de las especificaciones, como por ejemplo: requisitos, metas, etc.

NOTA 2: Una lista con los principales resultados del proceso es parte de la descripción de cada proceso en el Modelo de Referencia.

Servicio asociado al software: Ejecución de actividades, trabajos u obligaciones relacionadas al producto software, tales como su desarrollo, mantenimiento y operación [ABNT, 2009].

Software: Se entiende software como sinónimo de producto software que es el conjunto de programas de computadora, procedimientos y posible documentación y datos asociados [ABNT, 2009].

Unidad organizacional: Parte de una organización que será evaluada [ISO/IEC, 2004a].

NOTA 1: Una unidad organizacional utiliza uno o más procesos que tienen un contexto de proceso coherente y opera dentro de un conjunto coherente de objetivos de negocio.

NOTA 2: Una unidad organizacional es típicamente parte de una gran organización, sin embargo, en una pequeña organización, la unidad organizacional puede ser toda la organización. Una unidad organizacional puede ser, por ejemplo:

- un proyecto específico o un conjunto de proyectos relacionados;


- una unidad dentro de la organización enfocada en una fase (o fases) específica(s) del ciclo de vida, tales como, adquisición, desarrollo, mantenimiento o soporte;

- una parte de una organización responsable por todos los aspectos de un producto particular o conjunto de productos.

5 Símbolos y abreviaturas

AP: Atributo de Proceso.

CMMI-DEV®: Capability Maturity Model Integration for Development – Modelo de Madurez y de Capacidad Integrado para Desarrollo.

CMMI®: Capability Maturity Model Integration – Modelo de Madurez y de Capacidad Integrado.

IA: Institución Evaluadora, autorizada por la SOFTEX.

II: Institución Implementadora, autorizada por la SOFTEX.

IOGE: Institución Organizadora de Grupo de Empresas, autorizada por la SOFTEX.

MA-MPS: Método de Evaluación para Mejora de Proceso de Software.

MN-MPS: Modelo de Negocio para Mejora de Proceso de Software.

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

MR-MPS-SW: Modelo de Referencia MPS para Software.

MR-MPS-SV: Modelo de Referencia MPS para Servicios.

RAP: Resultado del Atributo de Proceso.

SCAMPI® 3: Standard CMMI Appraisal Method for Process Improvement – Método Estándar de Evaluación del CMMI para Mejora de Proceso.

SOFTEX: Asociación para Promoción de la Excelencia del Software Brasileño.

6 Descripción general del modelo MPS

Una de las metas del Programa MPS.BR es definir y perfeccionar un modelo de mejora y evaluación de proceso de software y servicios, dando preferencia a las micro, pequeñas y medianas empresas (mPMyE), de modo que se atiendan sus necesidades de negocio y que sea reconocido nacional e internacionalmente como un modelo aplicable a la industria de software y servicios. El modelo MPS establece dos modelos de referencia de procesos, uno para software y otro para servicios, y un proceso/método para evaluación de procesos. Esta estructura da soporte al modelo MPS y asegura que sea empleado de modo coherente con sus definiciones. El modelo MPS establece también un modelo de negocio para apoyar su adopción por las empresas desarrolladoras de software y prestadoras de servicios.

La base técnica para la construcción y perfeccionamiento de este modelo de mejora y evaluación de proceso de software y servicios está compuesta por las normas ISO/IEC 12207:2008 [ISO/IEC, 2008a], ISO/IEC 20000:2011 [ISO/IEC, 2011] e ISO/IEC 15504-2 [ISO/IEC, 2003]. Una evaluación MPS es realizada utilizando el

3 SCAMPI

SM es marca de servicio de la Carnegie Mellon University/Software Engineering Institute

(CMU/SEI).


proceso y el método de evaluación MA-MPS descritos en la guía de evaluación. Una evaluación MPS verifica la conformidad de una organización/unidad organizacional a los procesos del MR-MPS-SW y MR-MPS-SV. El modelo MPS está definido en consonancia con la Norma Internacional ISO/IEC 12207:2008 [ISO/IEC, 2008a] e ISO/IEC 20000:2011 [ISO/IEC, 2011], adaptándola a las necesidades de la comunidad de interés. El MR-MPS-SW es compatible con el CMMI-DEV® [SEI, 2010a] y el MR-MPS-SV es compatible con el CMMI-SVC® [SEI, 2010b]. Para la definición y revisión del modelo de referencia, se hace una amplia consulta a la comunidad de implementadores y evaluadores MPS. La elaboración final es responsabilidad del ETM. La base técnica del modelo MPS es presentada con más detalle en la sección 7 de este documento.

El modelo MPS está dividido en cuatro (4) componentes (Figura 1): Modelo de Referencia MPS para Software (MR-MPS-SW), Modelo de Referencia MPS para Servicios (MR-MPS-SV), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS). Cada componente está descrito por medio de guías y/o de documentos del Programa MPS.BR.

Figura 1 – Componentes del Modelo MPS

El Modelo de Referencia MPS para Software MR-MPS-SW contiene los requisitos que los procesos de las unidades organizacionales deben cumplir para estar en conformidad con el MR-MPS-SW. Contiene también las definiciones de los niveles de madurez, procesos y atributos del proceso, y están descritas en esta Guía General MPS de Software, en las secciones 8 y 9. El MR-MPS-SW está en conformidad con os requisitos de modelos de referencia de proceso de la Norma Internacional ISO/IEC 15504-2 [ISO/IEC, 2003].

El Modelo de Referencia MPS para Servicios MR-MPS-SV contiene los requisitos que los procesos de las unidades organizacionales deben cumplir para estar en conformidad con el MR-MPS-SV. Contiene también las definiciones de los niveles de madurez, procesos y atributos del proceso. El MR-MPS-SV está en conformidad con os requisitos de modelos de referencia de proceso de la Norma Internacional ISO/IEC 15504-2 [ISO/IEC, 2003].


La Guía de Adquisición es un documento complementario destinado a organizaciones que pretenden adquirir software y servicios. La Guía de Adquisición no contiene los requisitos del MR-MPS-SW o del MR-MPS-SV, pero si buenas prácticas para la adquisición de software y servicios.

La Guía de Implementación, en sus partes 1 a 7 sugiere cómo implementar cada uno de los niveles del MR-MPS-SW. La parte 8 de la Guía de Implementación sugiere cómo una unidad organizacional que adquiere productos de software puede implementar el MR-MPS. Las partes 9 y 10 de la Guía de Implementación sugieren cómo las fábricas de software y las fábricas de pruebas, respectivamente, pueden implementar el MR-MPS-SW. La parte 11 de la Guía de Implementación presenta un mapeo entre el MR-MPS-SW y el CMMI-DEV que auxilia a las organizaciones en las iniciativas de mejora de procesos de software multimodelos, sea en el ámbito de las implementaciones o de las evaluaciones de procesos. Las explicaciones presentes en las Guías de Implementación no constituyen requisitos del modelo y deben ser consideradas apenas con carácter informativo.

La Guía de Evaluación contiene el proceso y el método de evaluación MA-MPS, los requisitos para los evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA). El proceso y el método de evaluación MA-MPS están en conformidad con la Norma Internacional ISO/IEC 15504-2 [ISO/IEC, 2003].

El Modelo de Negocio MN-MPS describe reglas de negocio para implementación del MR-MPS-SW y del MR-MPS-SV por las Instituciones Implementadoras (II), evaluación siguiendo el MA-MPS por las Instituciones Evaluadoras (IA), organización de grupos de empresas por las Instituciones Organizadoras de Grupos de Empresas (IOGE) para implementación del MR-MPS-SW y del MR-MPS-SV y evaluación MA-MPS, certificación de Consultores de Adquisición (CA) y programas anuales de entrenamiento del MPS por medio de cursos, pruebas y workshops. Un resumen ejecutivo de esas reglas de negocio se encuentra disponible en www.softex.br/mpsbr.

7 Base técnica para la definición del modelo MPS

7.1 ISO/IEC 12207:2008

La Norma Internacional ISO/IEC 12207 [ISO/IEC, 2008a] fue creada por la ISO – International Organization for Standardization y la IEC - International Electrotechnical Commission en un esfuerzo conjunto de esas organizaciones.

En 1988, fue propuesto el desarrollo de la norma y, en agosto de 1995, fue publicada como Norma Internacional. En 1998, fue publicada su versión brasileña que tiene el mismo nombre que la internacional, precedida por la sigla NBR. En octubre de 2002 y 2004, se hicieron actualizaciones en la Norma Internacional ISO/IEC 12207, llamadas enmiendas 1 y 2 respectivamente, donde fueron incluidas diversas mejoras. Esas mejoras crearon nuevos procesos o ampliaron la extensión de algunos procesos, incluyeron para cada proceso su propósito y resultados y para los nuevos procesos definieron sus actividades y tareas. Esos cambios tuvieron el objetivo de reflejar la evolución de la Ingeniería de Software, las necesidades vividas por los usuarios de la norma y la busca de la armonía con la serie ISO/IEC 15504.

En 2008, la Norma Internacional ISO/IEC 12207 fue reformulada, incorporando las mejoras que ya aparecían en las enmiendas 1 y 2 y armonizando su estructura a la


Norma Internacional ISO/IEC 15288. La norma ISO/IEC 12207:2008 fue publicada también como estándar IEEE (IEEE Std 12207:2008) y como norma brasileña [ABNT, 2009]. Ella establece una arquitectura común para el ciclo de vida de procesos de software con una terminología bien definida. Contiene procesos, actividades y tareas a ser aplicadas durante el suministro, adquisición, desarrollo, operación, mantenimiento y descarte de productos software, así como partes de software de un sistema. La norma también se aplica a la adquisición de sistemas, productos de software y servicios.

7.2 ISO/IEC 15504

En septiembre de 1992, la ISO realizó un estudio llamado “Necesidades y Exigencias para una Norma de Evaluación de Procesos de Software”. El trabajo concluyó que era pertinente la elaboración de una norma que fuese aplicable a la mejora de procesos y a la determinación de la capacidad. Este estándar debería considerar los métodos y normas ya existentes (como por ejemplo, el SW-CMM® y la ISO 9001), abarcar todos los procesos de software y ser construido por los especialistas que ya desarrollaban y trabajaban con los métodos y normas existentes en la época. Como resultado de ese primer trabajo, la ISO inició en enero de 1993 el proyecto SPICE (Software Process Improvement and Capability dEtermination) cuyo objetivo era producir inicialmente un informe técnico que fuera, al mismo tiempo, más general y amplio que los modelos existentes y más específico que la norma ISO 9001 originando así la serie de normas ISO/IEC 15504: Parte 1 [ISO/IEC, 2004a], Parte 2 [ISO/IEC, 2003], Parte 3 [ISO/IEC, 2004b], Parte 4 [ISO/IEC, 2004c] y Parte 5 [ISO/IEC, 2006]. Posteriormente, en 2008, fueron desarrolladas dos partes más: Parte 6 [ISO/IEC, 2008b] y Parte 7 [ISO/IEC, 2008c].

La ISO/IEC 15504 se aplica para la realización de evaluaciones de procesos de software con dos objetivos: la mejora de procesos y la determinación de la capacidad de los procesos de una unidad organizacional. En caso de que el objetivo sea la mejora de procesos, la unidad organizacional puede realizar una evaluación con el objetivo de generar un perfil de los procesos que será usado para la elaboración de un plan de mejoras. El análisis de los resultados identifica los puntos fuertes, los puntos débiles y los riesgos inherentes a los procesos. En el segundo caso, la organización tiene el objetivo de evaluar un proveedor en potencial, obteniendo su perfil de capacidad. El perfil de capacidad permite al contratante estimar el riesgo asociado a la contratación de aquel proveedor en potencial para auxiliar en la toma de decisión de contratarlo o no.

7.3 ISO/IEC 20000

La norma ISO/IEC 20000 [ISO/IEC, 2011], publicada en diciembre de 2005 tiene como objetivo proveer un estándar de referencia común para que cualquier empresa ofrezca servicios de TI para clientes internos o externos. Esta norma proporciona la adopción de un abordaje de procesos integrado para la gestión de servicios de TI y se alinea con las mejores prácticas del ITIL para entrega y soporte de servicios. La ISO/IEC 20000 consiste en cinco partes bajo el título general Tecnología de la Información – Gestión de Servicio.

La ISO/IEC 20000-1 especifica al proveedor de servicios los requisitos para planificar, establecer, implementar, operar, monitorear, revisar, mantener y mejorar la GSTI (Gestión de Servicios de TI). Los requisitos incluyen el proyecto, transición, entrega y mejora de los servicios para cumplir los requisitos previamente acordados.


La ISO/IEC 20000-2 representa un consenso del sector sobre estándares de calidad en procesos de GSTI y describe las mejores prácticas para esos procesos [ISO/IEC, 2011]. La ISO/IEC TR 20000-3 provee orientaciones, explicaciones y recomendaciones para la definición del alcance, aplicabilidad y demostración de la conformidad con la ISO/IEC 20000-1 por medio de ejemplos prácticos. La ISO/IEC 20000-4 tiene como objetivo facilitar el desarrollo de un modelo para evaluación de proceso de acuerdo con la norma ISO/IEC 15504. El modelo de referencia de proceso, previsto en esta norma, es una representación lógica de los elementos de los procesos para la gestión de servicios que pueden ser ejecutados en un nivel básico. Cada proceso es descrito en términos de un propósito y resultados asociados. La ISO/IEC 20000-5 presenta un ejemplo de plan de implementación en el cual se proporcionan guías para que los proveedores de servicios atiendan los requisitos de la ISO/IEC 20000-1. También incluye orientaciones para iniciar el proyecto y una lista de actividades principales para cumplir cada fase de la implementación de la ISO/IEC 20000-1.

7.4 CMMI-DEV®

El origen del CMMI-DEV® (CMMI for Development) [SEI, 2010a] se remonta a la creación del modelo SW-CMM® (Software Capability Maturity Model) que fue definido por el SEI (Software Engineering Institute) a pedido del Departamento de

Defensa de los Estados Unidos. A partir de 1991, fueron desarrollados CMMs®

para

varias disciplinas (Ingeniería de Sistemas, Ingeniería de Software, Adquisición de Software, Gestión y Desarrollo de la Fuerza de Trabajo, Desarrollo Integrado del Proceso y del Producto). Aunque estos modelos hayan mostrado su utilidad, el uso de modelos múltiples se mostró problemático. El CMMI® surgió para resolver el problema de utilización de varios modelos y es el resultado de la evolución del SW-CMM®, SECM® (System Engineering Capability Model) e IPD-CMM® (Integrated Product Development Capability Maturity Model). Es, por lo tanto, el sucesor de estos modelos. Además de eso, el marco de referencia (framework) CMMISM fue desarrollado para ser consistente y compatible con la ISO/IEC 15504. En 2010 fue

publicada la versión 1.3 del CMMI®, el CMMI-DEV® (CMMI for Development) [SEI,

2010a].

7.5 CMMI-SVC®

El CMMI for Services - CMMI-SVC, lanzado en 2009 es el más reciente modelo de la serie del SEI. Este modelo está orientado para la aplicación de prácticas de mejora de procesos para empresas prestadoras de servicios de TI. El modelo CMMI-SVC es una guía para la aplicación de las mejores prácticas del CMMI en organizaciones proveedoras de servicios. Las mejores prácticas del modelo se concentran en las actividades para ofrecer servicios de calidad para el cliente y usuarios finales [SEI, 2010b].

El CMMI-SVC contiene 24 áreas de procesos. De esas, 16 son las mismas del modelo CMMI-DEV. Siete áreas de procesos son específicas de servicios y se refieren a: gestión de la capacidad y disponibilidad; continuidad de servicios; entrega de servicios; prevención y resolución de incidentes; transición de servicios; desarrollo de sistemas de servicios; y proceso de gestión estratégica de servicios. Sus niveles de madurez siguen la misma estructura del CMMI, o sea, cinco niveles de madurez, partiendo del nivel 1 hasta el nivel 5.


8 Descripción del MR-MPS-SW

El Modelo de Referencia MPS para Software (MR-MPS-SW) define niveles de madurez que son una combinación entre procesos y capacidades.

La definición de los procesos sigue los requisitos para un modelo de referencia de proceso presentados en la ISO/IEC 15504-2, declarando el propósito y los resultados esperados de su ejecución. Eso permite evaluar y atribuir grados de efectividad en la ejecución de los procesos. Las actividades y tareas necesarias para lograr el propósito y los resultados esperados no son definidas en esta guía, debiendo quedar a cargo de los usuarios del MR-MPS-SW.

La capacidad del proceso es la caracterización de la habilidad del proceso para lograr los objetivos de negocio, actuales y futuros; estando relacionada al cumplimiento de los atributos de proceso asociados a los procesos de cada nivel de madurez.

8.1 Niveles de madurez

Los niveles de madurez establecen etapas de evolución de procesos, caracterizando escalones de mejora de la implementación de procesos en la organización. El nivel de madurez en que se encuentra una organización permite la previsión de su desempeño futuro al ejecutar uno o más procesos. El MR-MPS-SW define siete niveles de madurez: A (En Optimización), B (Gestionado Cuantitativamente), C (Definido), D (Ampliamente Definido), E (Parcialmente Definido), F (Gestionado) y G (Parcialmente Gestionado). La escala de madurez se inicia en el nivel G y progresa hasta el nivel A. Para cada uno de estos siete niveles de madurez se atribuye un perfil de procesos que indican adonde la organización debe colocar el esfuerzo de mejora. El progreso y el logro de un determinado nivel de madurez del MR-MPS-SW se obtienen cuando se cumplen los propósitos y todos los resultados esperados de los respectivos procesos y los resultados esperados de los atributos de proceso establecidos para aquel nivel.

La división en 7 escalones tiene el objetivo de posibilitar una implementación y evaluación apropiada para las micro, pequeñas y medianas empresas. La posibilidad de realizar evaluaciones considerando más niveles también permite una visibilidad de los resultados de mejora de procesos en plazos más cortos.

8.2 Proceso

Los procesos en el MR-MPS-SW están descritos en términos de propósito y resultados y están detallados en la sección 9.

El propósito describe el objetivo general que debe ser logrado durante la ejecución del proceso.

Los resultados esperados del proceso establecen los resultados que deben ser obtenidos con la efectiva implementación del proceso. Estos resultados pueden ser evidenciados por un producto de trabajo producido o un cambio significativo de estado al ejecutarse el proceso.

8.3 Capacidad del Proceso

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-SW, a medida que la organización/unidad organizacional evoluciona en los niveles de madurez, un mayor nivel de capacidad para desempeñar el proceso debe ser logrado.

Para todos los procesos en el nivel correspondiente al nivel de madurez, se requiere el cumplimiento de los atributos del proceso (AP), evidenciado por medio del cumplimiento de los resultados esperados de los atributos del proceso (RAP), aunque no estén detallados dentro de cada proceso. Los niveles son acumulativos, o sea, si la organización está en el nivel F, esta posee el nivel de capacidad del nivel F que incluye los atributos de proceso de los niveles G y F para todos los procesos relacionados en el nivel de madurez F (que también incluye los procesos del nivel G). Esto significa que, al pasar del nivel G al nivel F, los procesos del nivel de madurez G pasan a ser ejecutados en el nivel de capacidad correspondiente al nivel F. En otras palabras, en el pase hacia un nivel de madurez superior, los procesos anteriormente implementados deben pasar a ser ejecutados en el nivel de capacidad exigido en ese nivel superior.

Los diferentes niveles de capacidad de los procesos son descritos por nueve atributos de procesos (AP). El alcance de cada atributo de proceso es evaluado utilizando los respectivos resultados esperados de atributo de proceso (RAP), conforme se define a continuación:

AP 1.1 El proceso es ejecutado

Este atributo evidencia cuánto es que el proceso logra su propósito.

Resultado esperado:

RAP1. El proceso logra sus resultados definidos.

AP 2.1 El proceso es gestionado

Este atributo evidencia cuánto es que la ejecución del proceso es gestionada.

Resultados esperados:

RAP 2. Existe una política organizacional establecida y mantenida para el proceso;

RAP 3. La ejecución del proceso es planificada;

RAP 4. (Para el Nivel G)4. La ejecución del proceso es supervisada y ajustes son realizados;

RAP 4. (A partir del Nivel F). Medidas son planificadas y recolectadas para la supervisión de la ejecución del proceso y ajustes son realizados;

RAP 5. Las informaciones y los recursos necesarios para la ejecución del proceso son identificados y colocados a disponibilidad;

RAP 6. (Hasta el nivel F)5 Las responsabilidades y la autoridad para ejecutar el proceso son definidas, atribuidas y comunicadas;

4 EL RAP 4 tiene exigencias diferentes para el Nivel G y para los niveles superiores.

5 El RAP 6 tiene exigencias diferentes para los niveles G y F y para los niveles superiores.


RAP 6. (A partir del nivel E) Los roles requeridos, responsabilidades y autoridad para ejecución del proceso definido son atribuidos y comunicados;

RAP 7. Las personas que ejecutan el proceso son competentes en términos de formación, entrenamiento y experiencia;

RAP 8. La comunicación entre las partes interesadas en el proceso es planificada y ejecutada de modo que se asegure su participación;

RAP 9. (Hasta el nivel F)6 Los resultados del proceso son revisados con la alta gerencia para proporcionar visibilidad sobre su situación en la organización;

RAP 9. (A partir del nivel E) Métodos adecuados para supervisar la eficacia y adecuación del proceso son determinados y los resultados del proceso son revisados con la alta gerencia para proporcionar visibilidad sobre su situación en la organización;

RAP 10. (Para el nivel G)7 El proceso planificado para el proyecto es llevado a cabo;

RAP 10. (A partir del nivel F) La adherencia de los procesos ejecutados a las descripciones de proceso, estándares y procedimientos es evaluada objetivamente y son tratadas las no conformidades.

AP 2.2 Los productos de trabajo del proceso son gestionados

Este atributo evidencia cuánto es que los productos de trabajo producidos por el proceso son gestionados apropiadamente.


RAP 11. Los requisitos de los productos de trabajo del proceso son identificados;

RAP 12. Requisitos para documentación y control de los productos de trabajo son establecidos;

RAP 13. Los productos de trabajo son colocados en niveles apropiados de control.

RAP 14. Los productos de trabajo son evaluados objetivamente con relación a estándares, procedimientos y requisitos aplicables y son tratadas las no conformidades.

AP 3.1. El proceso es definido

Este atributo evidencia cuánto es que un proceso estándar es mantenido para apoyar la implementación del proceso definido.


6 El RAP 9 tiene exigencias diferentes para los niveles G y F y para los niveles superiores.

7 El RAP 10 tiene exigencias diferentes para el nivel G y para los niveles superiores.


RAP 15. Un proceso estándar es descrito, incluyendo directrices para su adaptación;

RAP 16. La secuencia y la interacción del proceso estándar con otros procesos son determinadas;

RAP 17. Los roles y competencias requeridos para ejecutar el proceso son identificados como parte del proceso estándar;

RAP 18. La infraestructura y el entorno de trabajo requeridos para ejecutar el proceso son identificados como parte del proceso estándar.

AP 3.2 El proceso está implementado

Este atributo evidencia cuánto es que el proceso estándar es efectivamente implementado como un proceso definido para lograr sus resultados.


RAP 19. Un proceso definido es implementado con base en las directrices para selección y/o adaptación del proceso estándar;

RAP 20. La infraestructura y el entorno de trabajo requeridos para ejecutar el proceso definido son colocados a disponibilidad, gestionados y mantenidos;

RAP 21. Datos apropiados son recolectados y analizados, constituyendo una base para el entendimiento del comportamiento del proceso, para demostrar la adecuación y la eficacia del proceso, y evaluar adonde puede hacerse la mejora continua del proceso;

AP 4.1 El proceso es medido

Este atributo evidencia cuánto es que los resultados de medición son utilizados para asegurar que la ejecución del proceso logre sus objetivos de desempeño y apoye al logro de los objetivos de negocio definidos.


RAP 22. Las necesidades de información de los usuarios de los procesos, requeridas para apoyar objetivos de negocio relevantes de la organización, son identificadas;

RAP 23. Objetivos de medición organizacionales de los procesos y/o subprocesos son derivados de las necesidades de información de los usuarios del proceso;

RAP 24. Objetivos cuantitativos organizacionales de calidad y de desempeño de los procesos y/o subprocesos son definidos para apoyar los objetivos de negocio;

RAP 25. Los procesos y/o subprocesos que serán objeto de análisis de desempeño son seleccionados a partir del conjunto de procesos estándar de la organización y de las necesidades de información de los usuarios de los procesos;

RAP 26. Medidas, así como la frecuencia de realización de sus mediciones, son identificadas y definidas de acuerdo con los objetivos de medición del


proceso/subproceso y los objetivos cuantitativos de calidad y de desempeño del proceso;

RAP 27. Resultados de las mediciones son recolectados, analizados, utilizando técnicas estadísticas y otras técnicas cuantitativas apropiadas, y son comunicados para supervisar el logro de los objetivos cuantitativos de calidad y de desempeño del proceso/subproceso;

RAP 28. Resultados de medición son utilizados para caracterizar el desempeño del proceso/subproceso;

RAP 29. Modelos de desempeño del proceso son establecidos y mantenidos.

AP 4.2 El proceso es controlado

Este atributo evidencia cuánto es que el proceso es controlado estadísticamente para producir un proceso estable, capaz y previsible dentro de límites establecidos.


RAP 30. Técnicas de análisis y de control para la gestión cuantitativa de los procesos/subprocesos son identificadas y aplicadas cuando necesario;

RAP 31. Límites de control de variación son establecidos para el desempeño normal del proceso;

RAP 32. Datos de medición son analizados con relación a causas especiales de variación;

RAP 33. Acciones correctivas y preventivas son realizadas para tratar causas especiales, o de otros tipos, de variación;

RAP 34. Límites de control son restablecidos, cuando necesario, siguiendo las acciones correctivas, de modo que los procesos continúen estables, capaces y previsibles.

AP 5.1 El proceso es objeto de mejoras incrementales e innovaciones

Este atributo evidencia cuánto es que los cambios en el proceso son identificados a partir del análisis de defectos, problemas, causas comunes de variación del desempeño y de la investigación de enfoques innovadores para la definición e implementación del proceso.


RAP 35. Objetivos de negocio de la organización son mantenidos con base en el entendimiento de las estrategias de negocio y resultados de desempeño del proceso;

RAP 36. Objetivos de mejora del proceso son definidos con base en el entendimiento del desempeño del proceso, de modo que se verifique que los objetivos de negocio relevantes se pueden lograr;

RAP 37. Datos que influencian en el desempeño del proceso son identificados, clasificados y seleccionados para análisis de causas;

RAP 38. Datos seleccionados son analizados para identificar causas raíz y proponer soluciones aceptables para evitar ocurrencias futuras de resultados similares o incorporar mejores prácticas en el proceso;


RAP 39. Datos apropiados son analizados para identificar causas comunes de variación en el desempeño del proceso;

RAP 40. Datos apropiados son analizados para identificar oportunidades para aplicar mejores prácticas e innovaciones con impacto sobre el logro de los objetivos de negocio;

RAP 41. Oportunidades de mejora derivadas de nuevas tecnologías y conceptos de proceso son identificadas, evaluadas y seleccionadas con base en el impacto sobre el logro de los objetivos de negocio;

RAP 42. Una estrategia de implementación para las mejoras seleccionadas es establecida para lograr los objetivos de mejora del proceso y para resolver problemas.

AP 5.2 El proceso es optimizado continuamente

Este atributo evidencia cuánto es que los cambios en la definición, gestión y desempeño del proceso impactan efectivamente para el logro de los objetivos relevantes de mejora del proceso.


RAP 43. El impacto de todos los cambios propuestos es evaluado con relación a los objetivos del proceso definido y del proceso estándar;

RAP 44. La implementación de todos los cambios acordados es gestionada para asegurar que cualquier alteración en el desempeño del proceso sea entendida y que sean tomadas las acciones pertinentes;

RAP 45. Las acciones implementadas para resolución de problemas y mejora en el proceso son acompañadas, con el uso de técnicas estadísticas y otras técnicas cuantitativas, para verificar si los cambios en el proceso corrigieron el problema y mejoraron su desempeño;

RAP 46. Datos del análisis de causas y de resolución son almacenados para utilizarlos en situaciones similares.

La Tabla 8-1 presenta los niveles de madurez del MR-MPS-SW, los procesos y los atributos de proceso que corresponden a cada nivel.

Tabla ‎8-1 - Niveles de madurez del MR-MPS-SW

Nivel Procesos Atributos de Proceso

A AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 y AP 5.2

B Gestión de Proyectos – GPR (evolución) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 y AP 4.2

C Gestión de Riesgos – GRI AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2

Desarrollo para Reutilización – DRU

Gestión de Decisiones – GDE


Nivel Procesos Atributos de Proceso

D Verificación – VER AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2

Validación – VAL

Diseño y Construcción del Producto – PCP

Integración del Producto – ITP

Desarrollo de Requisitos – DRE

E Gestión de Proyectos – GPR (evolución) AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2

Gestión de Reutilización – GRU

Gestión de Recursos Humanos – GRH

Definición del Proceso Organizacional – DFP

Evaluación y Mejora del Proceso Organizacional – AMP

F Medición – MED AP 1.1, AP 2.1 y AP 2.2

Aseguramiento de la Calidad – GQA

Gestión de Portafolio de Proyectos - GPP

Gestión de Configuración – GCO

Adquisición – AQU

G

Gestión de Requisitos – GRE AP 1.1 y AP 2.1

Gestión de Proyectos – GPR

Nota: Los atributos de proceso AP 4.1, AP 4.2, AP 5.1 e AP 5.2 se deben implementar solamente para los procesos críticos de la organización/unidad organizacional, seleccionados para análisis de desempeño. Los demás atributos de proceso se deben implementar para todos los procesos.

8.4 Exclusión de Procesos

Algunos procesos se pueden excluir, total o parcialmente, del alcance de una evaluación MPS cuando no son pertinentes al negocio de la unidad organizacional que está siendo evaluada. Cada exclusión se debe justificar en el Plan de Evaluación. La aceptación de las exclusiones y sus justificativas es de responsabilidad del Evaluador Líder, conforme descrito en la Guía de Evaluación [SOFTEX, 2012b].

Se permite la exclusión completa del siguiente proceso, cuando no sea ejecutado por la organización:

Adquisición (AQU)

Se permite la exclusión completa del siguiente proceso, cuando la única actividad de la unidad organizacional es la evolución de producto:


Gestión de Portafolio de Proyectos (GPP)

Se permite la exclusión del siguiente proceso, siguiendo las orientaciones de la Tabla ‎8-2:

Desarrollo para Reutilización (DRU)

Tabla ‎8-2 – Exclusiones de los Resultados de DRU.

Oportunidades (DRU1)

Capacidad (DRU2)

Solución

Si Si - Los demás resultados del DRU son obligatorios

Si No - Debe ejecutar acciones correctivas para generar capacidad

- Debe comprobar que esas acciones correctivas están siendo llevadas a cabo

- Los demás resultados se pueden excluir de esa evaluación

- Para la próxima evaluación, en un plazo de 3 años, se debe obligatoriamente haber construido la capacidad

No Excluido - Debe mostrar, vía proceso formal de toma de decisión, que no existen oportunidades de reutilización

- Mientras haya ausencia de oportunidades de reutilización, los demás resultados se pueden excluir (en esa y en las próximas evaluaciones)

Otras exclusiones son permitidas para organizaciones con características específicas:

Organizaciones que adquieren software: las exclusiones permitidas para este tipo de organización están descritas en la Guía de Implementación – parte 8.

Fábricas de Código: las exclusiones permitidas para este tipo de organización están descritas en la Guía de Implementación – parte 9.

Fábricas de Pruebas: las exclusiones permitidas para este tipo de organización están descritas en la Guía de Implementación – parte 10.

Respecto de los resultados de atributos de proceso, en los niveles A y B, los resultados RAP 22 a RAP 46 pueden quedar fuera del alcance de la evaluación para algunos de los procesos de la organización. Apenas los procesos críticos de la organización, seleccionados para ser gestionados cuantitativamente, deben tener implementados todos os resultados de atributos de proceso.


9 Descripción detallada de los procesos

En esta sección, los procesos están descritos en términos de propósito y resultados esperados. Los procesos descritos están ordenados por el nivel de madurez de forma creciente, siendo que cada nivel incluye los procesos del nivel anterior.

9.1 Nivel G – Parcialmente Gestionado

El nivel de madurez G está compuesto por los procesos Gestión del Proyecto y Gestión de Requisitos. En este nivel, la implementación de los procesos debe cumplir los atributos de proceso AP 1.1 y AP 2.1.

9.1.1 Proceso: Gestión de Proyectos - GPR

Nivel MR-MPS-SW: G – Parcialmente Gestionado

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


GPR 1. El alcance del trabajo para el proyecto está definido;

GPR 2. Las tareas y los productos de trabajo del proyecto son dimensionados, utilizando métodos apropiados;

GPR 3. El modelo y las fases del ciclo de vida del proyecto son definidos;

GPR 4. (Hasta el nivel F) El esfuerzo y el costo para la ejecución de las tareas y de los productos de trabajo son estimados con base en datos históricos o referencias técnicas;

GPR 4. (A partir del nivel E) La planificación y las estimativas de las tareas del proyecto se hacen con base en el repositorio de estimativas y el conjunto de activos de proceso organizacional;

GPR 5. El presupuesto y el cronograma del proyecto, incluyendo la definición de hitos (marcos) y puntos de control, son establecidos y mantenidos;

GPR 6. Los riesgos del proyecto son identificados y su impacto, probabilidad de ocurrencia y prioridad de tratamiento son determinados y documentados;


GPR 7. Los recursos humanos para el proyecto son planificados considerando el perfil y el conocimiento necesarios para llevarlo a cabo;

GPR 8. (Hasta el nivel F) Los recursos y el entorno de trabajo necesarios para llevar a cabo el proyecto son planificados;

GPR 8. (A partir del nivel E) Los recursos y el entorno de trabajo necesarios para ejecutar los proyectos son planificados a partir de los entornos estándar de trabajo de la organización;

GPR 9. Los datos relevantes del proyecto son identificados y planificados respecto a la forma de recolección, almacenamiento y distribución. Un mecanismo es establecido para su acceso, incluyendo, para el caso en que sea pertinente, cuestiones de privacidad y seguridad;

GPR 10. Un plan general para la ejecución del proyecto es establecido con la integración de planes específicos;

GPR 11. La viabilidad de lograr las metas del proyecto es explícitamente evaluada considerando restricciones y recursos disponibles. En caso necesario, ajustes son realizados;

GPR 12. El Plan del Proyecto es revisado con todos los interesados y el compromiso con él es obtenido y mantenido;

GPR 13. El alcance, las tareas, las estimativas, el presupuesto y el cronograma del proyecto son supervisados con relación a lo planificado;

GPR 14. Los recursos materiales y humanos bien como los datos relevantes del proyecto son supervisados con relación a lo planificado;

GPR 15. Los riesgos son supervisados con respecto a lo planificado;

GPR 16. La participación de las partes interesadas en el proyecto es planificada, supervisada y mantenida;

GPR 17. Revisiones son realizadas en hitos (marcos) del proyecto y conforme lo establecido en los planes;

GPR 18. Registros de problemas identificados y el resultado del análisis de cuestiones pertinentes, incluyendo dependencias críticas, son establecidos y tratados con las partes interesadas;

GPR 19. Acciones para corregir desvíos de lo planificado y para prevenir la repetición de los problemas identificados son establecidas, implementadas y acompañadas hasta su conclusión;

GPR 20. (A partir del nivel E) Equipos involucrados en el proyecto son establecidos y mantenidos a partir de las reglas y directrices para estructuración, formación y actuación;

GPR 21. (A partir del nivel E) Experiencias relacionadas a los procesos contribuyen para los activos de proceso organizacional;

GPR 22. (A partir del nivel E) Un proceso definido para el proyecto es establecido de acuerdo con la estrategia para adaptación del proceso de la organización;


GPR 22. (A partir del nivel B) Los objetivos de calidad y de desempeño del proceso definido para el proyecto son establecidos y mantenidos;

GPR 23. (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;

GPR 24. (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;

GPR 25. (A partir del nivel B) Medidas y técnicas analíticas son seleccionadas para ser utilizadas en la gestión cuantitativa;

GPR 26. (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;

GPR 27. (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;

GPR 28. (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.


9.1.2 Proceso: Gestión de Requisitos - GRE

Nivel MR-MPS-SW: G – Parcialmente Gestionado

Propósito:

El propósito del proceso Gestión de Requisitos es gestionar los requisitos del producto y componentes del producto del proyecto e identificar inconsistencias entre los requisitos y los planes del proyecto y los productos de trabajo del proyecto.


GRE 1. El entendimiento de los requisitos es obtenido en conjunto con los proveedores de requisitos;

GRE 2. Los requisitos son evaluados con base en criterios objetivos y el compromiso del equipo técnico con estos requisitos es obtenido;

GRE 3. La rastreabilidad bidireccional entre los requisitos y los productos de trabajo es establecida y mantenida;

GRE 4. Revisiones en planes y productos de trabajo del proyecto son realizadas con el objetivo de identificar y corregir inconsistencias relacionadas a los requisitos;

GRE 5. Cambios en los requisitos son gestionados durante el proyecto.


9.2 Nivel F – Gestionado

El nivel de madurez F está compuesto por los procesos del nivel de madurez anterior (G), agregándoles los procesos Adquisición, Aseguramiento de la Calidad, Gestión de Configuración, Gestión de Portafolio de Proyectos y Medición. En este nivel, la implementación de los procesos debe cumplir los atributos de proceso AP 1.1, AP 2.1 y AP 2.2.

9.2.1 Proceso: Adquisición - AQU

Nivel MR-MPS-SW: F - Gestionado

Propósito:

El propósito del proceso Adquisición es gestionar la adquisición de productos8 que satisfagan la necesidad expresada por el adquiriente.


AQU 1. Las necesidades de adquisición, las metas, los criterios de aceptación del producto, los tipos de adquisición y la estrategia de adquisición son definidos;

AQU 2. Los criterios de selección del proveedor son establecidos y usados para evaluar los proveedores en potencial;

AQU 3. El proveedor es seleccionado con base en la evaluación de las propuestas y de los criterios establecidos;

AQU 4. Un acuerdo que expresa claramente las expectativas, las responsabilidades y las obligaciones de ambas partes (cliente y proveedor) es establecido y negociado entre ellas;

AQU 5. Un producto que satisfaga la necesidad expresada por el cliente es adquirido con base en el análisis de los potenciales candidatos;

AQU 6. La adquisición es supervisada de modo que se cumplan las condiciones especificadas, tales como: costo, cronograma y calidad, generando acciones correctivas cuando necesario;

AQU 7. El producto es entregado y evaluado con relación a lo acordado y los resultados son documentados;

AQU 8. El producto adquirido es incorporado al proyecto, en el caso de que sea pertinente.

8 En el contexto del MR-MPS se considera que el término producto puede incluir también servicios,

desde que sean entregados como parte del producto final al cliente.


9.2.2 Proceso: Gestión de Configuración - GCO


Propósito:

El propósito del proceso Gestión de Configuración es establecer y mantener la integridad de todos los productos de trabajo de un proceso o proyecto y colocarlos a disponibilidad de todos los involucrados.


GCO 1. Un Sistema de Gestión de Configuración es establecido y mantenido;

GCO 2. Los elementos de configuración son identificados con base en criterios establecidos;

GCO 3. Los elementos de configuración sujetos a un control formal son colocados bajo una línea base;

GCO 4. La situación de los elementos de configuración y de las líneas base es registrada a lo largo del tiempo y colocada a disponibilidad;

GCO 5. Cambios en elementos de configuración son controlados;

GCO 6. El almacenamiento, la manipulación y la entrega de elementos de configuración y líneas base son controlados;

GCO 7. Auditorias de configuración son realizadas objetivamente para asegurar que las líneas base y los elementos de configuración estén íntegros, completos y consistentes;


9.2.3 Proceso: Aseguramiento de la Calidad - GQA


Propósito:

El propósito del proceso Aseguramiento de la Calidad es asegurar que los productos de trabajo y la ejecución de los procesos estén en conformidad con los planes, procedimientos y estándares establecidos.


GQA 1. La adherencia de los productos a los estándares, procedimientos y requisitos aplicables es evaluada objetivamente, antes de que los productos sean entregados y en hitos (marcos) predefinidos a lo largo del ciclo de vida del proyecto;

GQA 2. La adherencia de los procesos ejecutados a las descripciones de proceso, estándares y procedimientos es evaluada objetivamente;

GQA 3. Los problemas y las no conformidades son identificados, registrados y comunicados;

GQA 4. Acciones correctivas para las no conformidades son establecidas y supervisadas hasta sus efectivas conclusiones. Cuando necesario, el escalamiento de las acciones correctivas para niveles superiores es realizado, de modo que se asegure su solución.


9.2.4 Proceso: Gestión de Portafolio de Proyectos – GPP


Propósito:

El propósito del proceso Gestión de Portafolio de Proyectos es iniciar y mantener proyectos que sean necesarios, suficientes y sustentables, de modo que se logren los objetivos estratégicos de la organización.

Este proceso compromete la inversión y los recursos organizacionales adecuados y establece la autoridad necesaria para llevar a cabo los proyectos seleccionados. Él ejecuta la calificación continua de proyectos para confirmar que justifican la continuidad de las inversiones, o pueden ser re-direccionados para que las justifiquen.


GPP 1. Las oportunidades de negocio, las necesidades y las inversiones son identificadas, calificadas, priorizadas y seleccionadas con relación a los objetivos estratégicos de la organización por medio de criterios objetivos;

GPP 2. Los recursos y presupuestos para cada proyecto son identificados y atribuidos;

GPP 3. La responsabilidad y la autoridad por la gestión de los proyectos son establecidas;

GPP 4. El portafolio es supervisado con relación a los criterios que fueron utilizados para la priorización;

GPP 5. Acciones para corregir desvíos en el portafolio y para prevenir la repetición de los problemas identificados son establecidas, implementadas y acompañadas hasta su conclusión;

GPP 6. Los conflictos sobre recursos entre proyectos son tratados y resueltos, de acuerdo con los criterios utilizados para la priorización;

GPP 7. Proyectos que cumplen con los acuerdos y requisitos que llevaron a su aprobación son mantenidos, y los que no cumplen son re-direccionados o cancelados;

GPP 8. La situación del portafolio de proyectos es comunicada a las partes interesadas, con periodicidad definida o cuando el portafolio es alterado.


9.2.5 Proceso: Medición - MED


Propósito:

El propósito del proceso Medición es recolectar, almacenar, analizar e informar los datos referentes a los productos desarrollados y a los procesos implementados en la organización y en sus proyectos, de modo que se apoyen los objetivos organizacionales.


MED 1. Objetivos de medición son establecidos y mantenidos a partir de los objetivos de negocio de la organización y de las necesidades de información de procesos técnicos y gerenciales;

MED 2. Un conjunto adecuado de medidas, orientado por los objetivos de medición, es identificado y definido, priorizado, documentado, revisado y, cuando pertinente, actualizado;

MED 3. Los procedimientos para la recolección y el almacenamiento de medidas son especificados;

MED 4. Los procedimientos para el análisis de las medidas son especificados;

MED 5. Los datos requeridos son recolectados y analizados;

MED 6. Los datos y los resultados de los análisis son almacenados;

MED 7. Los datos y los resultados de los análisis son comunicados a los interesados y son utilizados para apoyar decisiones.


9.3 Nivel E – Parcialmente Definido

El nivel de madurez E está compuesto por los procesos de los niveles de madurez que le preceden (G y F), agregándoles los procesos Evaluación y Mejora del Proceso Organizacional, Definición del Proceso Organizacional, Gestión de Recursos Humanos y Gestión de Reutilización. El proceso Gestión de Proyectos sufre su primera evolución retratando su nuevo propósito: gestionar el proyecto con base en el proceso definido para el proyecto y en los planes integrados. En este nivel la implementación de los procesos debe cumplir los atributos de proceso AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2.

9.3.1 Proceso: Evaluación y Mejora del Proceso Organizacional - AMP

Nivel MR-MPS-SW: E – Parcialmente Definido

Propósito:

El propósito del proceso Evaluación y Mejora del Proceso Organizacional es determinar cuánto es que los procesos estándar de la organización contribuyen para lograr los objetivos de negocio de la organización y para apoyar a la organización a planificar, realizar e implantar mejoras continuas en los procesos con base en el entendimiento de sus puntos fuertes y débiles.


AMP 1. La descripción de las necesidades y los objetivos de los procesos de la organización son establecidos y mantenidos;

AMP 2. Las informaciones y los datos relacionados al uso de los procesos estándar para proyectos específicos existen y son mantenidos;

AMP 3. Evaluaciones de los procesos estándar de la organización son realizadas para identificar sus puntos fuertes, puntos débiles y oportunidades de mejora;

AMP 4. Registros de las evaluaciones realizadas son mantenidos accesibles;

AMP 5. Los objetivos de mejora de los procesos son identificados y priorizados;

AMP 6. Un plan de implementación de mejoras en los procesos es definido y ejecutado, y los efectos de esta implementación son supervisados y confirmados con base en los objetivos de mejora;

AMP 7. Activos de proceso organizacional son implantados en la organización;

AMP 8. Los procesos estándar de la organización son utilizados en proyectos a ser iniciados y, en caso de que sea pertinente, en proyectos siendo llevados a cabo;

AMP 9. La implementación de los procesos estándar de la organización y el uso de los activos de proceso organizacional en los proyectos son supervisados;

AMP 10. Experiencias relacionadas a los procesos son incorporadas a los activos de proceso organizacional.


9.3.2 Proceso: Definición del Proceso Organizacional - DFP


Propósito:

El propósito del proceso Definición del Proceso Organizacional es establecer y mantener un conjunto de activos de proceso organizacional y estándares del entorno de trabajo utilizables y aplicables a las necesidades de negocio de la organización.


DFP 1. Un conjunto definido de procesos estándar es establecido y mantenido, en conjunto con la indicación de la aplicabilidad de cada proceso;

DFP 2. Una biblioteca de activos de proceso organizacional es establecida y mantenida;

DFP 3. Tareas, actividades, roles y productos de trabajo asociados a los procesos estándar son identificados y detallados, en conjunto con el desempeño esperado del proceso;

DFP 4. Las descripciones de los modelos de ciclo de vida a ser utilizados en los proyectos de la organización son establecidas y mantenidas;

DFP 5. Una estrategia para la adaptación del proceso estándar es desarrollada considerando las necesidades de los proyectos;

DFP 6. El repositorio de medidas de la organización es establecido y mantenido;

DFP 7. Los entornos estándar de trabajo de la organización son establecidos y mantenidos;

DFP 8. Reglas y directrices para la estructuración, formación y actuación de equipos son establecidas y mantenidas.


9.3.3 Proceso: Gestión de Recursos Humanos - GRH


Propósito:

El propósito del proceso Gestión de Recursos Humanos es proveer, a la organización y a los proyectos, los recursos humanos necesarios y mantenerles sus competencias apropiadas a las necesidades del negocio.


GRH 1. Las necesidades estratégicas de la organización y de los proyectos son revisadas para identificar recursos, conocimientos y habilidades requeridos y, de acuerdo con la necesidad, planificar cómo desarrollarlos o contratarlos;

GRH 2. Individuos con las habilidades y competencias requeridas son identificados y reclutados;

GRH 3. Las necesidades de entrenamiento que son responsabilidad de la organización son identificadas;

GRH 4. Una estrategia de entrenamiento es definida, con el objetivo de atender a las necesidades de entrenamiento de los proyectos y de la organización;

GRH 5. Un plan táctico de entrenamiento es definido, con el objetivo de implementar una estrategia entrenamiento;

GRH 6. Los entrenamientos identificados como responsabilidad de la organización son conducidos y registrados;

GRH 7. La efectividad de los entrenamientos es evaluada;

GRH 8. Criterios objetivos para evaluación del desempeño de grupos e individuos son definidos y supervisados para proveer informaciones sobre este desempeño y mejorarlo;

GRH 9. Una estrategia apropiada de gestión de conocimiento es planificada, establecida y mantenida para compartir informaciones en la organización;

GRH 10. Una red de especialistas en la organización es establecida y un mecanismo de apoyo al intercambio de informaciones entre los especialistas y los proyectos es implementado;

GRH 11. El conocimiento es colocado a disponibilidad y compartido en la organización.


9.3.4 Proceso: Gestión de Reutilización - GRU


Propósito:

El propósito del proceso Gestión de Reutilización es gestionar el ciclo de vida de los activos reutilizables.


GRU 1. Una estrategia de gestión de activos es documentada, contemplando la definición de activo reutilizable, además de los criterios para aceptación, certificación, clasificación, discontinuidad y evaluación de activos reutilizables;

GRU 2. Un mecanismo de almacenamiento y recuperación de activos reutilizables es implantado;

GRU 3. Los datos de utilización de activos reutilizables son registrados;

GRU 4. Los activos reutilizables son periódicamente mantenidos, según los criterios definidos, y sus modificaciones son controladas durante su ciclo de vida;

GRU 5. Los usuarios de activos reutilizables son notificados sobre problemas detectados, cambios realizados, nuevas versiones disponibles y discontinuidad de activos.


9.4 Nivel D – Ampliamente Definido

El nivel de madurez D está compuesto por los procesos de los niveles de madurez que le preceden (G al E), agregándoles los procesos Desarrollo de Requisitos, Integración del Producto, Diseño y Construcción del Producto, Validación, y Verificación. En este nivel la implementación de los procesos debe cumplir los atributos de proceso AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2.

9.4.1 Proceso: Desarrollo de Requisitos - DRE

Nivel MR-MPS-SW: D – Ampliamente Definido

Propósito:

El propósito del proceso Desarrollo de Requisitos es definir los requisitos del cliente, del producto y de los componentes del producto.


DRE 1. Las necesidades, expectativas y restricciones del cliente, tanto del producto como de sus interfaces, son identificadas;

DRE 2. Un conjunto definido de requisitos del cliente es especificado y priorizado a partir de las necesidades, expectativas y restricciones identificadas;

DRE 3. Un conjunto de requisitos funcionales y no-funcionales, del producto y de los componentes del producto que describen la solución del problema a ser resuelto, es definido y mantenido a partir de los requisitos del cliente;

DRE 4. Los requisitos funcionales y no-funcionales de cada componente del producto son refinados, elaborados y atribuidos;

DRE 5. Interfaces internas y externas del producto y de cada componente del producto son definidas;

DRE 6. Conceptos operativos y escenarios son desarrollados;

DRE 7. Los requisitos son analizados, usando criterios definidos, para equilibrar las necesidades de los interesados con las restricciones existentes;

DRE 8. Los requisitos son validados.


9.4.2 Proceso: Integración del Producto - ITP

Nivel MR-MPS-SW: D - Ampliamente Definido

Propósito:

El propósito del proceso Integración del Producto es combinar los componentes del producto, produciendo un producto integrado consistente con su diseño, y demostrar que los requisitos funcionales y no-funcionales se cumplen para el entorno al que se destina el producto o entorno equivalente.


ITP 1. Una estrategia de integración, consistente con el diseño y con los requisitos del producto, es desarrollada y mantenida para los componentes del producto;

ITP 2. Un entorno para integración de los componentes del producto es establecido y mantenido;

ITP 3. La compatibilidad de las interfaces internas y externas de los componentes del producto es asegurada;

ITP 4. Las definiciones, el diseño y los cambios en las interfaces internas y externas son gestionados para el producto y los componentes del producto;

ITP 5. Cada componente del producto es verificado, utilizando criterios definidos, para confirmar que estos están listos para la integración;

ITP 6. Los componentes del producto son integrados, de acuerdo con la estrategia determinada y siguiendo los procedimientos y criterios para integración;

ITP 7. Los componentes del producto integrados son evaluados y los resultados de la integración son registrados;

ITP 8. Una estrategia de prueba de regresión es desarrollada y aplicada para una nueva verificación del producto, en caso de que ocurra un cambio en los componentes del producto (incluyendo requisitos, diseño y códigos asociados);

ITP 9. El producto y la documentación relacionada son preparados y entregados al cliente.


9.4.3 Proceso: Diseño y Construcción del Producto - PCP

Nivel MR-MPS-SW: D – Ampliamente Definido

Propósito:

El propósito del proceso Diseño y Construcción del Producto es diseñar, desarrollar e implementar soluciones para cumplir los requisitos.


PCP 1. Alternativas de solución y criterios de selección son desarrollados para cumplir los requisitos definidos de producto y componentes de producto;

PCP 2. Soluciones son seleccionadas para el producto o componentes del producto, con base en escenarios definidos y en criterios identificados;

PCP 3. El producto y/o componente del producto es diseñado y documentado;

PCP 4. Las interfaces entre los componentes del producto son diseñadas con base en criterios predefinidos;

PCP 5. Un análisis de los componentes del producto es conducido para decidir sobre su construcción, compra o reutilización;

PCP 6. Los componentes del producto son implementados y verificados de acuerdo con lo diseñado;

PCP 7. La documentación es identificada, desarrollada y colocada a disponibilidad, de acuerdo con los estándares establecidos;

PCP 8. La documentación es mantenida de acuerdo con los criterios definidos.


9.4.4 Proceso: Validación - VAL


Propósito:

El propósito del proceso Validación es confirmar que un producto o componente del producto cumplirá su uso pretendido cuando colocado en el entorno para el cual fue desarrollado.


VAL 1. Productos de trabajo a ser validados son identificados;

VAL 2. Una estrategia de validación es desarrollada e implementada estableciendo cronograma, participantes involucrados, métodos para validación y cualquier material a ser utilizado en la validación;

VAL 3. Criterios y procedimientos para validación de los productos de trabajo a ser validados son identificados y un entorno para validación es establecido;

VAL 4. Actividades de validación son ejecutadas para asegurar que el producto de software esté listo para uso en el entorno operativo pretendido;

VAL 5. Problemas son identificados y registrados;

VAL 6. Resultados de actividades de validación son analizados y colocados a disponibilidad de las partes interesadas;

VAL 7. Evidencias de que los productos de software desarrollados están listos para el uso pretendido son suministradas.


9.4.5 Proceso: Verificación - VER


Propósito:

El propósito del proceso Verificación es confirmar que cada servicio y/o producto de trabajo del proceso o del proyecto cumple apropiadamente los requisitos especificados.


VER 1. Productos de trabajo a ser verificados son identificados;

VER 2. Una estrategia de verificación es desarrollada e implementada estableciendo cronograma, revisores involucrados, métodos para verificación y cualquier material que sea utilizado en la verificación;

VER 3. Criterios y procedimientos para verificación de los productos de trabajo a ser verificados son identificados y un entorno para verificación es establecido;

VER 4. Actividades de verificación, incluyendo pruebas y revisiones por pares, son llevadas a cabo;

VER 5. Defectos son identificados y registrados;

VER 6. Los resultados de las actividades de verificación son analizados y colocados a disponibilidad de las partes interesadas;


9.5 Nivel C – Definido

El nivel de madurez C está compuesto por los procesos de los niveles de madurez que le preceden (G al D), agregándoles los procesos Desarrollo para Reutilización, Gestión de Decisiones y Gestión de Riesgos. En este nivel, la implementación de los procesos debe cumplir los atributos de proceso AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2.

9.5.1 Proceso: Desarrollo para Reutilización - DRU

Nivel MR-MPS-SW: C - Definido

Propósito:

El propósito del proceso Desarrollo para Reutilización es identificar oportunidades de reutilización sistemática de activos en la organización y, si es posible, establecer un programa de reutilización para desarrollar activos a partir de ingeniería de dominios de aplicación.


DRU 1. Dominios de aplicación en que serán investigadas oportunidades de reutilización de activos o en los cuales se pretende practicar reutilización son identificados, detectando los respectivos potenciales de reutilización;

DRU 2. La capacidad de reutilización sistemática de la organización es evaluada y acciones correctivas son tomadas, caso necesario;

DRU 3. Un programa de reutilización, incluyendo propósitos, alcance, metas y objetivos, es planificado con la finalidad de atender las necesidades de reutilización de dominios;

DRU 4. El programa de reutilización es implantado, supervisado y evaluado;

DRU 5. Propuestas de reutilización son evaluadas de modo que se asegure que el resultado de la reutilización sea apropiado para la aplicación a la que se destina;

DRU 6. Formas de representación para modelos de dominio y arquitecturas de dominio son seleccionadas;

DRU 7. Un modelo de dominio es desarrollado y sus límites y relaciones con otros dominios son establecidos y mantenidos. Este modelo debe ser capaz de capturar características, capacidades, conceptos y funciones comunes, variantes, opcionales y obligatorios;

DRU 8. Una arquitectura de dominio describiendo una familia de aplicaciones para el dominio es desarrollada y mantenida durante todo su ciclo de vida;

DRU 9. Activos del dominio son especificados; adquiridos o desarrollados, y mantenidos durante todo su ciclo de vida.


9.5.2 Proceso: Gestión de Decisiones - GDE


Propósito:

El propósito del proceso Gestión de Decisiones es analizar posibles decisiones críticas usando un proceso formal, con criterios establecidos, para evaluación de las alternativas identificadas.


GDE 1. Guías organizacionales para la gestión de decisiones son establecidas y mantenidas;

GDE 2. El problema o cuestión a ser objeto de un proceso formal de toma de decisión es definido;

GDE 3. Criterios para evaluación de las alternativas de solución son establecidos y mantenidos en orden de importancia, de modo que los criterios más importantes tengan más influencia en la evaluación;

GDE 4. Alternativas de solución aceptables para el problema o cuestión son identificadas;

GDE 5. Los métodos de evaluación de las alternativas de solución son seleccionados de acuerdo con su viabilidad de aplicación;

GDE 6. Soluciones alternativas son evaluadas usando los criterios y métodos establecidos;

GDE 7. Decisiones se toman con base en la evaluación de las alternativas utilizando los criterios de evaluación establecidos.


9.5.3 Proceso: Gestión de Riesgos - GRI


Propósito:

El propósito del proceso Gestión de Riesgos es identificar, analizar, tratar, supervisar y reducir continuamente los riesgos a nivel organizacional y de proyecto.


GRI 1. El alcance de la gestión de riesgos es determinado;

GRI 2. Los orígenes y las categorías de riesgos son determinados, y los parámetros usados para analizar riesgos, categorizarlos y controlar el esfuerzo de la gestión de riesgos son definidos;

GRI 3. Las estrategias apropiadas para la gestión de riesgos son definidas e implementadas;

GRI 4. Los riesgos del proyecto son identificados y documentados incluyendo su contexto, condiciones y posibles consecuencias para el proyecto y las partes interesadas;

GRI 5. Los riesgos son priorizados, estimados y clasificados de acuerdo con las categorías y los parámetros definidos;

GRI 6. Planes para la mitigación de riesgos son desarrollados;

GRI 7. Los riesgos son analizados y la prioridad de aplicación de los recursos para la supervisión de esos riesgos es determinada;

GRI 8. Los riesgos son evaluados y supervisados para determinar cambios en su situación y en el progreso de las actividades para su tratamiento;

GRI 9. Acciones apropiadas son llevadas a cabo para corregir o evitar el impacto del riesgo, basadas en su prioridad, probabilidad, consecuencia u otros parámetros definidos.


9.6 Nivel B – Gestionado Cuantitativamente

Este nivel de madurez está compuesto por los procesos de los niveles de madurez que le preceden (G al C). En este nivel, el proceso de Gestión de Proyectos sufre su segunda evolución, agregándoles nuevos resultados para lograr los objetivos de la gestión cuantitativa. En este nivel, la implementación de los procesos debe cumplir los atributos de proceso AP 1.1, AP 2.1, AP 2.2, AP 3.1 y AP 3.2 y los RAP 22 a RAP 25 del AP 4.1. La implementación de los procesos seleccionados para análisis de desempeño debe cumplir íntegramente los atributos de proceso AP 4.1 y AP 4.2.

Este nivel no posee procesos específicos.


9.7 Nivel A – En Optimización

Este nivel de madurez está compuesto por los procesos de los niveles de madurez que le preceden (G al B). En este nivel, la implementación de los procesos debe cumplir los atributos de proceso AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2 y los RAP 22 a RAP 25 del AP 4.1. La implementación de los procesos seleccionados para análisis de desempeño debe cumplir integralmente los atributos de proceso AP 4.1 y AP 4.2. Los atributos de procesos AP 5.1 y AP 5.2 se deben cumplir integralmente por la implementación de por lo menos uno de los procesos seleccionados para el análisis de desempeño.

Este nivel no posee procesos específicos.


10 Instituciones Implementadoras (II)

Una implementación del MR-MPS-SW puede ser conducida por una Institución Implementadora (II) acreditada, mediante convenio con la SOFTEX, con base en parecer del Foro de Acreditación y Control (FCC).

Para solicitar su acreditación, las Instituciones proponentes deben cumplir los siguientes requisitos institucionales:

demostrar experiencia de la institución en el área de procesos de software;

poseer una estrategia de implementación del Modelo de Referencia MPS MR-MPS-SW;

poseer una estrategia de selección, capacitación y mantenimiento de la competencia de los miembros del equipo de Implementación del MR-MPS;

tener a ella vinculados, por lo menos, 3 (tres) profesionales que cumplan los siguientes requisitos, siendo que uno de ellos debe ser el coordinador del equipo: (i) aprobación en la Prueba de Introducción (P1); (ii) aprobación en la Prueba para Implementadores (P2); (iii) graduación completa9; (iv) experiencia en desarrollo de software e implantación de procesos de software.

Después del análisis del documento y parecer favorable del Foro de Acreditación y Control (FCC), la SOFTEX firma un Término de Convenio con la Institución Implementadora (II) para su acreditación por un período de 2 años.

Obligatoriamente el Coordinador de la II, o su representante, debe participar en el Workshop anual de Implementadores y participar de la reunión de Coordinadores de Instituciones Implementadoras. El no cumplimiento de esta cláusula implicará en la inmediata desacreditación de la II.

9 Una institución implementadora puede tener a ella vinculados otros implementadores sin graduación

completa. Sin embargo, por lo menos, 3 implementadores de la institución deben cumplir ese requisito.


Referencias Bibliográficas

[ABNT, 2009] - ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12207 – Tecnologia de informação - Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 2009.

[ABNT, 2001] - ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 9000:2000 – Sistemas de gestão da qualidade e garantia da qualidade – Fundamentos e Vocabulário. Rio de Janeiro: ABNT, 2001.

[ISO/IEC, 2003] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-2: Information Technology - Process Assessment – Part 2 - Performing an Assessment, Geneve: ISO, 2003.

[ISO/IEC, 2004a] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-1: Information Technology - Process Assessment – Part 1 - Concepts and Vocabulary, Geneve: ISO, 2004.

[ISO/IEC, 2004b] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-3: Information Technology - Process Assessment - Part 3 - Guidance on Performing an Assessment, Geneve: ISO, 2004.

[ISO/IEC, 2004c] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-4: Information Technology - Process Assessment – Part 4 - Guidance on use for Process Improvement and Process Capability Determination, Geneve: ISO, 2004.

[ISO/IEC, 2006] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-5: Information Technology - Process Assessment - Part 5: An exemplar Process Assessment Model, Geneve: ISO, 2006.

[ISO/IEC, 2007] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15939: Software Engineering – Software Measurement Process, Geneve: ISO, 2007.

[ISO/IEC, 2008a] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 12207 Systems and software engineering– Software life cycle processes, Geneve: ISO, 2008.

[ISO/IEC, 2008b] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 15504-6: Information Technology - Process Assessment - Part 6: An exemplar system life cycle process assessment model, Geneve: ISO, 2008.

[ISO/IEC, 2008c] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC TR 15504-7: Information Technology - Process Assessment - Part 7: Assessment of organizational maturity, Geneve: ISO, 2008.


[ISO/IEC, 2011] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 20000 Information Technology– Service Management, Geneve: ISO, 2011.

[PMI, 2008] PROJECT Management Institute. A Guide To The Project Management Body of Knowledge. 4. ed. Newton Square: PMI Publications, 2008.

[SEI, 2010a] SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.3, Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2010.

[SEI, 2010b] SOFTWARE ENGINEERING INSTITUTE. CMMI for Services, Version 1.3, Technical Report CMU/SEI-2010-TR-034. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2010.

[SOFTEX, 2011a] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Adquisición:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011b] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011c] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011d] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011e] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011f] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011g] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011h] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Implementación – Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS:2011, junio 2011. Disponible en: www.softex.br.

[SOFTEX, 2011i] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 8: Implementação do MR-MPS:2011 em organizações que adquirem software, junho 2011. Disponible en: www.softex.br.


[SOFTEX, 2011j] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 9: Implementação do MR-MPS:2011 v 2.0 em organizações do tipo Fábrica de Software, junho 2011. Disponible en: www.softex.br.

[SOFTEX, 2011k] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 10: Implementação do MR-MPS:2011 em organizações do tipo Fábrica de Teste, junho 2011. Disponible en: www.softex.br.

[SOFTEX, 2012a] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia Geral MPS de Serviços:2012, agosto 2012. Disponible en: www.softex.br.

[SOFTEX, 2012b] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guía de Evaluación:2012, mayo 2011. Disponible en: www.softex.br.

[SOFTEX, 2012c] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia de Implementação – Parte 11: Implementação e Avaliação do MR-MPS-SW:2012 em Conjunto com o CMMI-DEV v1.3, maio 2011. Disponible en: www.softex.br.


Lista de colaboradores de la Guía General MPS de Software:2012

Editores:

Gleison dos Santos Souza UNIRIO y COPPE/UFRJ

Ana Regina C. Rocha COPPE/UFRJ

Cristina Ângela Filipak Machado CELEPAR y QualityFocus (Coordinadora del ETM)

Revisores:

Danilo Scalet CELEPAR

Maria Teresa Villalobos IMA – Informática de Munícipios Associados

Traducción al español:

Maria Teresa Villalobos IMA – Informática de Munícipios Associados


Lista de colaboradores de la Guía General:2011

Editores:

Gleison dos Santos Souza UNIRIO y COPPE/UFRJ

Ana Regina C. Rocha COPPE/UFRJ (Coordinadora del ETM)

Cristina Ângela Filipak Machado CELEPAR y QualityFocus

Revisores:

Ana Liddy Cenni C. Magalhães QualityFocus y UFMG


Elaine Nunes COPPE/UFRJ

Jorge Bória LIVEWARE

Maria Teresa Villalobos IMA

Mariano Montoni ProMove

Odisnei Galarraga SOFTWARE PROCESS

Reinaldo Cabral Silva Filho COPPE/UFRJ e UFAL

Renato Ferraz Machado Quality Focus

Sheila Reinehr PUCPR y QualityFocus




Lista de colaboradores de la Guía General:2009 – Junio/2009

Editoras:


Sheila Reinehr PUCPR y QualityFocus

Colaboradores:

Káthia Marçal de Oliveira Universidad Católica de Brasilia

Revisores:

Ana Cecília Zabeu ASR

Ana Liddy Cenni C. Magalhães QualityFocus y Universidad FUMEC

Carlos Barbieri FUMSOFT

Cristina Ângela Filipak Machado CELEPAR y QualityFocus


Edmeia Andrade EMBRAPA

Fábio Bianchi Campos Universidad Católica de Brasilia

Gleison dos Santos Souza COPPE/UFRJ

Kival Chaves Weber SOFTEX

Marcio Pecegueiro do Amaral RIOSOFT

Mariano Montoni COPPE/UFRJ

Odisnei Galarraga Software Process

Sarah Kohan Fundación Vanzolini



Revisión de la traducción:

Andrés Rubinstein Liveware


Lista de colaboradores de la Guía General versión 1.2 – Junio/2007

Editores:


Ana Liddy C. C. Magalhães SwQuality



Colaboradores:

Ahilton Barreto COPPE/UFRJ

Alfredo Nozomu Tsukumo CenPRA

Claudia Maria Lima Werner COPPE/UFRJ


Leonardo Murta COPPE/UFRJ

Marco Lopes COPPE/UFRJ

Marcos Kalinowski COPPE/UFRJ

Revisores:

Cristina Ângela Filipak Machado CELEPAR


Fábio Bianchi Campos Universidad Católica de Brasilia

Francisco Vasconcellos Marina del Brasil y COPPE/UFRJ


Marcio Pecegueiro Amaral RIOSOFT

Regina M. Thienne Colombo CenPRA


Maria Teresa Villalobos CenPRA e IMA


Lista de colaboradores de la Guía General versión 1.1 – Mayo/2006

Editoras:


Ana Cristina Rouiller Universidad Federal Rural de Pernambuco


Revisores:

Ana Cervigni Guerra CenPRA

Christiane Gresse von Wangenheim UNIVALI

Clênio F. Salviano CenPRA



Francisco Vasconcellos Marina del Brasil y COPPE/UFRJ




Maria Teresa Villalobos CenPRA


Lista de colaboradores de la Guía General versión 1.0 – Mayo/2005

Editoras:

Ana Regina C. Rocha COPPE/UFRJ


Colaboradores:

Adriano B. de Albuquerque COPPE/UFRJ

Ana Candida Natali COPPE/UFRJ

Clênio F. Salviano CenPRA


Edson Saraiva de Almeida SCOPUS


Marcelo Pessôa Fundación Vanzolini/USP


Odisnei Galarraga EsiCenter Unisinos

Paula Mian COPPE/UFRJ

Sávio Figueiredo COPPE/UFRJ

Sheila Reinehr PUC-PR

Tayana Conte COPPE/UFRJ

Teresa Maciel CESAR

Revisores:

Ana Cervigni Guerra CenPRA

Ana Cristina Rouiller UFLA

André Villas-Boas CPqD

Clenio F. Salviano CenPRA


Eratóstenes Araújo SOFTEX

Kathia Marçal Oliveira UCB


Jorge Bória Liveware

Luiz Carlos de Almeida Oliveira CELEPAR

Marcelo Pessoa Fundación Vanzolini/USP


Teresa Maciel CESAR

Viviana L. Rubinstein Liveware

guía general del mps.br v1

Documents