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

MPS.BR - Mejora de Proceso del Software Brasileño Guía de Implementación Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS Esta guía contiene orientaciones para la implementación del nivel E del Modelo de Referencia MR-MPS. VIGENCIA Y TRANSICIÓN: La Guía General:2011 entra en vigor el 30 de junio de 2011. Así, a partir de esta fecha pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Sin embargo, queda definido un período de transición, de 30 de junio a 31 de diciembre de 2011, durante el cual pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011 o la versión anterior MR-MPS:2009. A partir del 1º de enero de 2012 solo serán válidas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Las implementaciones a ser realizadas utilizando esta Guía de Implementación deberán llevar en cuenta estas vigencias. Julio de 2011 Actualizado en Agosto de 2011 Copyright 2011 - SOFTEX Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN 978-85-99334-74-4

Índice 1 Prefacio... 3 2 Introducción... 5 3 Objetivo... 6 4 Evolucionando del nivel F al nivel E... 6 5 Comenzando la implementación del MR-MPS por el nivel E... 7 6 Gestión de Proyectos (GPR) (evolución)... 8 6.1 Propósito... 8 6.2 Fundamentación teórica... 9 6.3 Resultados esperados... 10 7 Evaluación y Mejora del Proceso Organizacional (AMP)... 15 7.1 Propósito... 15 7.2 Fundamentación teórica... 16 7.3 Resultados esperados... 18 8 Definición del Proceso Organizacional (DFP)... 23 8.1 Propósito... 23 8.2 Fundamentación teórica... 25 8.3 Resultados esperados... 26 9 Gestión de Recursos Humanos (GRH)... 32 9.1 Propósito... 32 9.2 Fundamentación teórica... 35 9.3 Resultados esperados... 39 10 Gestión de Reutilización (GRU)... 47 10.1 Propósito... 47 10.2 Fundamentación teórica... 49 10.3 Resultados esperados... 50 11 Los atributos de proceso del nivel E... 53 11.1 AP 2.1 - El proceso es gestionado... 54 11.2 AP 3.1 - El proceso es definido... 55 11.3 AP 3.2 - El proceso está implementado... 56 Referencias bibliográficas... 59 Lista de colaboradores de la Guía de Implementación Parte 3:2011... 63 Lista de colaboradores de la Guía de Implementación Parte 3:2009... 64 Lista de colaboradores de la Guía de Implementación Parte 3 versión 1.1 - Julio/2007... 65 Lista de colaboradores de la Guía de Implementación Parte 3 versión 1.0 - Diciembre/2006... 66 MPS.BR Guía de Implementación Parte 3:2011 2/66

1 Prefacio El MPS.BR 1 es un programa movilizador, de largo plazo, creado en diciembre de 2003, es coordinado por la Asociación para Promoción de la Excelencia del Software Brasileño (SOFTEX), y cuenta con el apoyo del Ministerio de Ciencia y Tecnología (MCT), de la Financiera de Estudios y Proyectos (FINEP), del Servicio Brasileño de Apoyo a las Micro y Pequeñas Empresas (SEBRAE) y del Banco Interamericano de Desarrollo (BID). El objetivo del programa MPS.BR (acrónimo) es la Mejora de Proceso del Software, para lograr dos metas a mediano y largo plazo: a) meta técnica, teniendo como objetivo la creación y perfeccionamiento del modelo MPS, con resultados esperados tales como: (i) guías del modelo MPS; (ii) Instituciones Implementadoras (II) acreditadas para prestar servicios de consultoría de implementación del modelo de referencia MR-MPS; (iii) Instituciones Evaluadoras (IA) acreditadas para prestar servicios de evaluación siguiendo el método de evaluación MA-MPS; (iv) Consultores de Adquisición (CA) certificados para prestar servicios de consultoría de adquisición de software y servicios asociados; b) meta de mercado, teniendo como objetivo la propagación y adopción del modelo MPS, en todas las regiones del país, en un intervalo de tiempo justo, a un costo razonable, tanto en PYMEs (foco principal) así como en grandes organizaciones públicas y privadas, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops; (iii) organizaciones que implementaron el modelo MPS; (iv) organizaciones con evaluación MPS publicada (vigencia de tres años). El programa MPS.BR cuenta con dos estructuras de apoyo al desarrollo de sus actividades, el Foro de Acreditación y Control (FCC) y el Equipo Técnico del Modelo (ETM). Por medio de estas estructuras, el MPS.BR obtiene la participación de representantes de universidades, instituciones gubernamentales, centros de investigación y de organizaciones privadas, las cuales contribuyen con sus visiones complementarias que agregan calidad al emprendimiento. Cabe al FCC: (i) emitir parecer para auxiliar las decisiones de la SOFTEX sobre la acreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA); (ii) supervisar los resultados de las Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA), emitiendo parecer proponiendo a la SOFTEX su desacreditación en caso de comprometimiento de la credibilidad del modelo MPS. Cabe al ETM apoyar a la SOFTEX sobre los aspectos técnicos relacionados al Modelo de Referencia (MR-MPS) y Método de Evaluación (MA-MPS), para: (i) creación y perfeccionamiento continuo del MR-MPS, MA-MPS y sus guías específicas; (ii) capacitación de personas por medio de cursos, pruebas y workshops. 1 MPS.BR, MR-MPS, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla MPS.BR está asociada al programa MPS.BR Mejora del Proceso de Software Brasileño y la sigla MPS está asociada al modelo MPS Mejora del Proceso de Software. MPS.BR Guía de Implementación Parte 3:2011 3/66

La creación y el perfeccionamiento de esta Guía de Implementación son también atribuciones del ETM, siendo que esta guía forma parte del siguiente conjunto de documentos del modelo MPS: Guía General:2009 [SOFTEX, 2011a]; Guía de Implementación (partes 1 a 11); Guía de Evaluación:2009 [SOFTEX, 2011b]; y Guía de Adquisición:2009 [SOFTEX, 2011c]. Esta Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. La Guía de implementación está subdividida en once partes, contemplando, respectivamente, los siguientes niveles de madurez: Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS; Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS; Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS; Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS; Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS; Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS; Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS; Parte 8: Implementación del MR-MPS (Niveles G a A) en organizaciones que adquieren software; Parte 9: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Software; Parte 10: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Pruebas; y Parte 11: Implementación y evaluación del MR-MPS (Niveles G a A) en conjunto con el CMMI-DEV. Los cambios de esta Guía de Implementación en relación a la versión 2009 se deben a: cambios realizados en la versión 2009 de la Guía General; corrección ortográfica y gramatical; adecuación de las referencias bibliográficas; inclusión de notas explicativas contenidas en las partes 8, 9 y 10 de la Guía de Implementación; Adicionalmente, en agosto de 2011, los siguientes cambios fueron realizados en relación a la versión publicada en julio de 2011: adecuación en la redacción del resultado esperado DFP8. MPS.BR Guía de Implementación Parte 3:2011 4/66

2 Introducción Los cambios que están ocurriendo en los ambientes de negocios han motivado a las empresas a modificar sus estructuras organizacionales y procesos productivos, saliendo de la visión tradicional basada en áreas funcionales hacia redes de procesos centrados en el cliente. La competitividad depende, cada vez más, del establecimiento de conexiones en estas redes, creando vínculos esenciales en las cadenas productivas. Lograr competitividad por la calidad, para las empresas de software, implica tanto la mejora de la calidad de los productos de software y servicios asociados, así como la de los procesos de producción y distribución de software. De esta forma, así como para otros sectores, la calidad es un factor crítico de éxito para la industria de software. Para que se tenga un sector de software competitivo nacional e internacionalmente, es esencial que los emprendedores del sector se concentren en la eficiencia y la eficacia de sus procesos, buscando ofrecer productos de software y servicios asociados conforme estándares internacionales de calidad. Se busca que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, aunque con especial atención a las micro, pequeñas y medianas empresas. También se espera que el modelo MPS sea compatible con los estándares de calidad aceptados internacionalmente y que tenga como presupuesto el aprovechamiento de toda la competencia existente en los estándares y modelos de mejora de proceso ya disponibles. De esta forma, tiene como base los requisitos de procesos definidos en los modelos de mejora de proceso y atiende a la necesidad de implantar los principios de Ingeniería de Software de manera adecuada al contexto de las empresas, estando en consonancia con los principales abordajes internacionales para la definición, evaluación y mejora de procesos de software. El Modelo MPS se basa en los conceptos de madurez y capacidad de proceso para la evaluación y mejora de la calidad y productividad de productos de software y servicios asociados. Dentro de ese contexto, el MPS.BR posee tres componentes: Modelo de Referencia (MR-MPS), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS). El Modelo MPS está descrito por medio de documentos en forma de guías: Guía General: contiene la descripción general del modelo MPS y detalla el Modelo de Referencia (MR-MPS), sus componentes y las definiciones comunes necesarias para su entendimiento y aplicación. Guía de Adquisición: describe un proceso de adquisición de software y servicios asociados. Está descrito de modo que apoye a las instituciones que quieran adquirir productos de software y servicios asociados. Guía de Evaluación: describe el proceso y el método de evaluación MA-MPS, los requisitos para evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA); y Guía de Implementación: serie de once documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS. MPS.BR Guía de Implementación Parte 3:2011 5/66

3 Objetivo La Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. Este documento corresponde a la parte 3 de la Guía de Implementación y aborda la implementación del nivel de madurez E. Este documento está dirigido, pero no se limita, a organizaciones interesadas en utilizar el MR-MPS para mejora de sus procesos de software e Instituciones Implementadoras (II). El contenido de este documento es informativo, o sea, no se espera que una organización implementando el MR-MPS cumpla todos los elementos citados en la explicación referente a los resultados esperados. Las observaciones presentes en este documento buscan apenas explicitar elementos importantes en la interpretación de los resultados esperados. Durante una evaluación MPS, solo es requerido el cumplimiento de los resultados esperados definidos en la Guía General. Los evaluadores MPS deben analizar si la implementación de los procesos de la organización cumple cada resultado, con abertura a múltiples formas válidas de implementación. 4 Evolucionando del nivel F al nivel E Hasta el nivel F del MR-MPS no hay exigencia de que los proyectos ejecuten procesos estandarizados en toda la organización, esto es, la organización puede no tener su(s) proceso(s) estándar. De esta forma los gerentes pueden definir procesos para los proyectos que sean diferentes unos de los otros, aunque todos deben obedecer a lo establecido en la política organizacional definida en la organización para los procesos. En los niveles G y F, también, muchas veces la organización no tiene todavía la preocupación de tener los procesos integrados en un proceso de desarrollo y/o mantenimiento. El nivel E tiene como foco principal la estandarización de los procesos de la organización, por medio de la definición de procesos estándar. Estos deben ser definidos a partir de los procesos y mejores prácticas ya existentes en la organización, lo que constituye el primer paso de una continua evaluación y mejora de los procesos. La definición de procesos estándar incluye, además de los procesos del nivel E, todos los procesos que pertenecen a los niveles G y F del MR- MPS. Definir procesos estándar no significa, sin embargo, que todos los proyectos deben usar los procesos estándar de la misma forma. Proyectos tienen características diferentes en lo que se refiere, por ejemplo, al tamaño, requisitos de calidad, innovación y experiencia del equipo. Estas características tienen influencia en la adecuación de un proceso al proyecto y necesitan ser consideradas. La definición de los procesos estándar debe incluir la definición de directrices para su adaptación a los proyectos y, a cada proyecto, se debe definir el proceso a ser utilizado en el proyecto a partir de los procesos estándar y de estas directrices. Como exigencia MPS.BR Guía de Implementación Parte 3:2011 6/66

para la evolución al nivel E del MR-MPS, se tiene todavía la construcción de la biblioteca de activos 2 y del repositorio de medidas. En este nivel, para asegurar la institucionalización de los procesos y la corrección en su uso, se debe institucionalizar la gestión de recursos humanos por medio de la identificación, desarrollo y/o contratación de individuos que posean los conocimientos y habilidades necesarios para atender los objetivos estratégicos de la organización. Esa gestión de recursos humanos envuelve también la identificación y realización de entrenamientos que deben estar bajo la responsabilidad de la organización y no, apenas, bajo la responsabilidad personal de los colaboradores o de los proyectos específicos. Además de eso, para asegurar la preservación adecuada del capital intelectual de la organización, también se debe gestionar eficientemente todo el conocimiento necesario para ejecutar los procesos de la organización. Finalmente, la organización debe también en este nivel implementar una estrategia de gestión de activos reutilizables para aumentar la eficiencia y la eficacia de los procesos de software de la organización por medio de la reutilización de productos de trabajo proyectados para utilización en múltiples contextos. De acuerdo con el método de evaluación MA-MPS, ningún proceso o resultado de proceso puede ser excluido del alcance de la evaluación de los procesos de una organización. 5 Comenzando la implementación del MR-MPS por el nivel E Es posible comenzar la implementación del MR-MPS por el nivel E y, de hecho, ya existen experiencias exitosas en este sentido. La mayor diferencia, utilizando este abordaje, es que desde el inicio se han definido los procesos estándar y una estrategia para evaluación de los procesos con el objetivo de su mejora continua. La adaptación de los procesos estándar es realizada para cada proyecto específico con base en directrices establecidas. Existe una biblioteca de activos y un repositorio de medidas. Además de esto, la organización establece mecanismos para gestionar sus recursos humanos desde la contratación de individuos con habilidades y conocimientos adecuados para ejecutar los procesos de la organización, pasando por la identificación e implementación de entrenamientos de los colaboradores bajo responsabilidad de la organización y por la gestión del conocimiento, que constituye el capital intelectual de la organización. La organización se debe preocupar también desde el inicio con la gestión de reutilización de activos en los proyectos. Para no correr el riesgo de fracaso, la organización juntamente con la Institución Implementadora (II) debe tomar con mucho cuidado la decisión de comenzar la implementación directamente por el nivel E. En este momento, se debe considerar factores tales como, madurez de la organización en procesos, capacitación de los colaboradores de la organización en ingeniería de software, experiencia de los consultores de la II, recursos y tiempo disponibles. 2 Para detalles sobre la biblioteca de activos y el repositorio de métricas consultar el proceso Definición del Proceso Organizacional. MPS.BR Guía de Implementación Parte 3:2011 7/66

6 Gestión de Proyectos (GPR) (evolución) 6.1 Propósito El propósito del proceso Gestión de Proyectos es establecer y mantener planes que definen las actividades, recursos y responsabilidades del proyecto, así como proporcionar informaciones sobre el progreso del proyecto que permitan la realización de correcciones cuando se tengan desvíos significativos en el desempeño del proyecto. El propósito de este proceso evoluciona a medida que la organización crece en madurez. Así, a partir del nivel E, algunos resultados evolucionan y otros son incorporados, de manera 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. Hasta el nivel F del modelo no hay necesidad de que los proyectos ejecuten procesos estandarizados en toda la organización. A partir de la evolución de algunos resultados esperados del proceso Gestión de Proyectos (GPR) en el alcance del nivel E del MR-MPS era de esperarse que fuese previsto un mecanismo para asegurar que los procesos que componen el conjunto de procesos estándar de la organización fuesen utilizados de forma consistente en toda la organización, pero atendiendo a las necesidades y características específicas de los proyectos. Ese mecanismo corresponde a la implementación de los resultados evolucionados para el proceso Gestión de Proyectos (GPR) en el alcance del nivel E del MR-MPS. Los resultados esperados de este proceso que evolucionan en el alcance del nivel E del MR-MPS están relacionados a resultados esperados de los procesos Gestión de Proyectos (resultados esperados en el alcance del nivel G del MR-MPS), Definición del Proceso Organizacional, Evaluación y Mejora del Proceso Organizacional y Medición. La intersección de este proceso con los resultados esperados en el alcance del nivel G del MR-MPS del proceso Gestión de Proyectos (GPR) está presente en los resultados esperados referentes a la adaptación de la planificación y supervisión del proyecto para la inclusión de nuevos planes que pueden surgir como consecuencia de la adición de nuevos procesos de los niveles superiores del modelo. Es importante resaltar que en este nivel más partes interesadas están involucradas en los proyectos y más dependencias críticas deben ser gestionadas. Por lo tanto, en este nivel, la gestión de los proyectos debe concentrar su atención en la gestión y supervisión de la participación de los interesados en los proyectos y en la gestión y supervisión de las dependencias críticas y de los planes de acción decurrentes de la ejecución de los proyectos. Una importante intersección con el proceso Definición del Proceso Organizacional (DFP) está presente por medio de la necesidad de adaptación de los procesos estándar para la planificación del proceso para el proyecto de acuerdo con la estrategia de adaptación establecida por la organización y de los demás activos disponibles. De la misma forma que los activos de proceso organizacional son utilizados por los proyectos, los datos y experiencias obtenidos por medio de la ejecución de los proyectos deben contribuir para realimentación de la base de activos de proceso organizacional, sirviendo, también, como insumos al proceso MPS.BR Guía de Implementación Parte 3:2011 8/66

Evaluación y Mejora del Proceso Organizacional (AMP). Otra intersección con el proceso Definición del Proceso Organizacional (DFP) está en el uso del ambiente estándar de la organización y de los guías para la estructuración, formación y actuación de equipos. La intersección con el proceso Medición (MED) está presente por medio del uso de la base de estimativas de la organización para la planificación de las estimativas de las actividades de los proyectos a ser ejecutados. Probablemente, esta base debe haber comenzado a ser creada y estructurada con la implementación del proceso Medición en el nivel F del MR-MPS. Sin embargo, a partir del nivel E, su uso es facilitado debido al hecho de que los proyectos son, ahora, planificados con base en una estructura común: el conjunto de procesos estándar. Los datos recolectados por medio de la ejecución de nuevos proyectos también deben ser utilizados para la evolución y mejora de la base de estimativas, contribuyendo con la mejora del conocimiento de la organización sobre el comportamiento de sus procesos. Estos datos serán particularmente útiles para apoyar la implementación de los procesos referentes a los Niveles B y A del MR-MPS. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) No son permitidas exclusiones de resultados de este proceso. No son permitidas exclusiones de resultados de este proceso. Como no existen otras especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios en los resultados esperados. Fábrica de Pruebas (Parte 10) No son permitidas exclusiones de resultados de atributos de proceso. Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios adicionales a los resultados esperados. 6.2 Fundamentación teórica Según la norma internacional ISO/IEC 12207, el propósito de la Gestión de Proyectos es identificar, establecer, coordinar y supervisar las actividades, tareas y recursos que un proyecto necesita para producir un producto y/o servicio, en el contexto de los requisitos y restricciones del proyecto [ISO/IEC 2008]. La gestión de esfuerzo, costos, cronograma, equipo, riesgos y otros factores están íntimamente relacionados a tareas del proceso definido del proyecto, la cual puede, también, ser parte del Plan del Proyecto. Ciertas actividades pueden ser cubiertas en otros planes que afectan al proyecto, como plan de aseguramiento de la calidad, plan de gestión de riesgos y plan de gestión de configuración, plan de verificación y plan de validación. En el contexto de la gestión del proyecto, la integración incluye características como unificación, consolidación, articulación y acciones de MPS.BR Guía de Implementación Parte 3:2011 9/66

integración que son cruciales para concluir el proyecto, cumplir satisfactoriamente los requisitos de los interesados y clientes y gestionar las expectativas [PMI, 2008]. Como en el nivel E del MR-MPS, el proceso definido para cada proyecto se debe adaptar del conjunto de procesos estándar de la organización, la variabilidad entre los proyectos tiende a reducirse y los proyectos pueden más fácilmente compartir los activos de proceso organizacional, datos y lecciones aprendidas. Las características del entorno del proyecto que tienen influencia en la adaptación del proceso estándar deben ser identificadas. Algunas de las características pueden ser: modelo de ciclo de vida; requisitos del sistema y del software; políticas, procedimientos y estrategias organizacionales; tamaño, criticidad y tipos del sistema, producto o servicio de software; cantidad de personas y partes interesadas; y características del equipo y de la gerencia. Todas las decisiones de adaptación deben ser documentadas juntamente con sus motivos [ISO/IEC, 2008]. A partir de este nivel, hay un aumento de la complejidad de las actividades de gestión de proyectos debido a la necesidad de gestionar cuestiones levantadas por las partes interesadas en los proyectos, y a la necesidad de asegurar que los interesados desempeñen sus tareas de una forma coordinada y regular para (i) tratar requisitos del producto y componentes del producto, planes, objetivos, problemas y riesgos; (ii) cumplir con sus compromisos; e (iii) identificar, rastrear y resolver problemas de coordinación [SEI, 2010]. Además, en este nivel es importante facilitar el desarrollo de los proyectos con base en procesos estándar por medio del establecimiento de un entorno de trabajo para el proyecto basado en los estándares de entornos de trabajo de la organización. 6.3 Resultados esperados 6.3.1 GPR4 - (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 Para cumplir este resultado esperado, la realización de estimativas y de la planificación del proyecto es hecha con base en el proceso definido para el proyecto, en los activos de proceso y en el repositorio de medidas de la organización. La definición de los activos de proceso de la organización se hace dentro del alcance del proceso Definición del Proceso Organizacional. La definición del repositorio de medidas de la organización, a pesar de prevista por el proceso Definición del Proceso Organizacional, tiene, obviamente, mucha influencia del proceso Medición, responsable por la definición, recolección, análisis y comunicación de las medidas recolectadas en la organización. Con el objetivo de facilitar las estimativas y el entendimiento del comportamiento de los proyectos de la organización, se debe organizar una base histórica consistente basada en los proyectos realizados por la organización. Para organizaciones que cuentan con un reducido número de proyectos ejecutados periódicamente o que estén comenzando la implantación de procesos, la construcción de tal base de datos puede no ser trivial. Además de eso, el simple acto de recolectar y almacenar los datos históricos de los proyectos no asegura que se esté construyendo de hecho una base histórica. Los datos deben ser analizados y organizados de modo que sean útiles para auxiliar en la planificación o toma de decisiones en los proyectos. MPS.BR Guía de Implementación Parte 3:2011 10/66

Una posible solución para la construcción de esta base histórica seria, por ejemplo, levantar, en un determinado número de proyectos con características semejantes, el tiempo o esfuerzo gastado para la elaboración de determinadas actividades previstas en el proceso estándar. Así, cuando la estimativa inicial del proyecto tenga que ser realizada, estos valores podrían ser utilizados como justificación para los valores presentados. Otra solución, principalmente para organizaciones con pequeño número de proyectos, seria analizar los datos de las actividades ejecutadas dentro del propio proyecto y no entre proyectos. Por ejemplo, si la implementación de los requisitos de un proyecto de desarrollo fuese dividida en más de una iteración, se puede utilizar los datos históricos referentes a la primera iteración (por ejemplo, el tiempo medio para implementación de un caso de uso simple) para la planificación de la segunda. Después de la finalización del proyecto los datos ya consolidados deberán, entonces, contribuir para los activos de proceso organizacionales y, obviamente, para la base histórica de medidas. Diferente del nivel G, en este nivel es obligatorio utilizar métodos paramétricos para dimensionar las tareas y los productos de trabajo del proyecto, por ejemplo, métodos de Análisis de Puntos por Función (APF), de Análisis de Puntos por Casos de Uso o mismo un método documentado propio de la organización. Por tanto, los factores de ajuste de estos métodos deben ser regularmente calibrados con base en el contenido de la base histórica. Una vez que los factores hayan sido ajustados, los nuevos valores pueden ser utilizados, por ejemplo, para una re-planificación del proyecto o durante una supervisión para verificar los riesgos de que el cronograma del proyecto se desvíe de lo planificado. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) Fábrica de Pruebas (Parte 10) Es deseable que la base histórica esté organizada de modo que almacene y permita la recuperación de datos de proyectos anteriores con los proveedores para apoyar la realización de estimativas en nuevos proyectos. Sin comentario adicional para este resultado. Sin comentario adicional para este resultado. 6.3.2 GPR8 - (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 Este resultado se refiere a la necesidad de planificar las tareas, con base en la EAP (o estructura equivalente), bien como prever los recursos y el entorno necesarios, incluyendo, por ejemplo, equipamientos, herramientas, servicios, componentes, viajes y requerimientos de proceso (que sean especiales para el proyecto). A partir MPS.BR Guía de Implementación Parte 3:2011 11/66

del nivel E, la planificación del ambiente de trabajo para el proyecto debe estar compatible con el ambiente estándar de trabajo de la organización (conforme definido en DFP7 del proceso Definición del Proceso Organizacional). Adaptaciones a la planificación del entorno de trabajo estándar de la organización deben ser descritas, caso pertinente. Además de eso, caso la planificación del entorno del ambiente de trabajo para el proyecto esté previsto integralmente en la planificación del entorno de trabajo de la organización, ese hecho debe ser documentado. Los recursos humanos, incluyendo entrenamientos, son tratados por el GPR7 del proceso Gestión de Proyectos. Todos os recursos deben ser explícitamente planificados, aún los ya considerados como existentes y disponibles o que serán compartidos con otros proyectos, una vez que se trata de su designación para uso. Estos elementos pueden, por ejemplo, estar registrados en el plan del proyecto. Caso no haiga necesidad de ningún recurso a ser adquirido para el proyecto, se debe registrar el hecho de que la cuestión fue examinada. Este resultado es importante porque recursos especiales necesitan de presupuesto y planificación de su adquisición, lo que puede tornarse crítico en algunos proyectos. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) El adquiriente debe realizar la planificación identificando lo que él mismo debe proporcionar y lo que es responsabilidad del proveedor. En todo caso, el ambiente de trabajo estándar de la organización debe ser llevado en consideración. En organizaciones del tipo Fábrica de Software puede ser necesario planificar los recursos específicos relacionados a la compatibilidad con el entorno de la contratante, lo que incluye: recursos para las Pruebas unitarias o de módulos, disponibilidad de infraestructura para acceso remoto a repositorios de la contratante, entrenamiento en herramientas de uso de la contratante, etc. En todo caso, el ambiente de trabajo estándar de la organización debe ser llevado en consideración. Fábrica de Pruebas (Parte 10) Sin comentario adicional para este resultado. 6.3.3 GPR20 - (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 El objetivo de este resultado esperado es el estabelecimiento de los equipos necesarios para la ejecución del proyecto de acuerdo con las reglas y directrices para la estructuración, formación y actuación de equipos en la organización (previstas por el resultado esperado DFP8 del proceso Definición del Proceso Organizacional). MPS.BR Guía de Implementación Parte 3:2011 12/66

La visión compartida del proyecto consiste en la comprensión común de sus principios directores a ser utilizados, incluyendo misión, objetivos, comportamiento esperado, valores y resultados finales [SEI, 2010]. Esta visión es definida antes de la formación de la estructura del equipo. Un equipo puede ser tratado en determinados casos como siendo toda la organización o interesados externos al proyecto [SEI, 2010]. Un punto importante de este resultado esperado es la coordinación de los equipos, internos y externos, involucrados en el proyecto de modo que se facilite la colaboración y, así, se aumenten las chances de éxito del proyecto. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) En organizaciones Adquirientes de Software, es importante que haiga el mapeo de los equipos internos de la organización con equipos de las empresas contratadas. En organizaciones del tipo Fábrica de Software, los equipos pueden contener también miembros de las empresas contratantes. Además de eso, puede haber la necesidad de mapear las interfaces entre los equipos de la propia organización y de la contratante. Fábrica de Pruebas (Parte 10) En organizaciones del tipo Fábrica de Pruebas, los equipos pueden contener también miembros de las empresas contratantes. Además de eso, puede haber la necesidad de mapear las interfaces entre los equipos de la propia organización y de la contratante. 6.3.4 GPR21 - (A partir del nivel E) Experiencias relacionadas a los procesos contribuyen para los activos de proceso organizacional Para atender a este resultado esperado es necesario que haiga la identificación de las experiencias obtenidas durante la ejecución del proyecto que pueden contribuir para el conjunto de activos de proceso organizacionales. Estas experiencias incluyen, pero no se limitan a, medidas recolectadas, propuestas de mejoras en el proceso y en los productos de trabajo, datos para refinamiento de la base de estimativas, lecciones aprendidas, buenas prácticas, ejemplos de documentos a ser seguidos, productos de trabajo diversos, guías, material de entrenamiento, etc. El repositorio de medidas de la organización debe ser continuamente actualizado con datos de los proyectos para que, en el futuro, datos históricos sean utilizados en nuevos proyectos. La creación y mantenimiento del repositorio de medidas de la organización deben ser hechas siguiendo los resultados esperados del proceso Medición. Con la implementación de los resultados esperados en el alcance del nivel E del MR-MPS del proceso Gestión de Proyectos (GPR), los datos de ese repositorio tienden a quedar más organizados, una vez que, al seguir un mismo proceso estándar, las informaciones recolectadas en los proyectos deben tener una estructura estandarizada. Además de eso, la planificación de la medición en los proyectos tiende a seguir una estructura común, definida por la organización. MPS.BR Guía de Implementación Parte 3:2011 13/66

No es apenas el repositorio de medidas que es realimentado con datos de los proyectos de la organización, experiencias adquiridas en los proyectos también pueden contribuir para los activos de proceso organizacional. Por ejemplo, lecciones aprendidas recolectadas durante reuniones periódicas de los equipos de los proyectos o durante evaluaciones post mortem. Además de eso, solicitaciones de mejora en los procesos identificadas debido al uso de estos procesos durante los proyectos también pueden contribuir para la mejora de los activos de proceso organizacional. Organizaciones que estén controlando estadísticamente sus procesos (ver más detalles en las Partes 6 y 7 de la Guía de Implementación) también deben considerar la inclusión, en el repositorio de medidas organizacional, de resultados relativos a los atributos de interés para análisis del comportamiento de los procesos/subprocesos. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) Fábrica de Pruebas (Parte 10) Los productos de trabajo y medidas que deben contribuir para los activos de proceso organizacional incluyen los producidos por el adquiriente y los producidos por el proveedor, cuya entrega al adquiriente esté establecida en el acuerdo. Es importante para la organización adquiriente documentar las experiencias relacionadas a la actuación del proveedor en el proyecto. Sin comentario adicional para este resultado. Sin comentario adicional para este resultado. 6.3.5 GPR22 - (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 Para cumplir este resultado esperado, se debe definir un proceso para el proyecto a partir del conjunto de procesos estándar de la organización. La definición de este proceso para el proyecto debe llevar en consideración las directrices establecidas, en la organización, para adaptación del proceso estándar a los proyectos. El conjunto de los procesos estándar de la organización es un producto del proceso Definición del Proceso Organizacional, así como las estrategias para adaptación de estos procesos y los modelos de ciclo de vida que deben ser utilizados en los proyectos. El proceso definido para el proyecto debe abarcar todas las actividades necesarias para el desarrollo o mantenimiento del producto por el proyecto a partir de lo que es pedido por el cliente hasta la entrega del producto final (que puede variar dependiendo de las características de desarrollo de la organización). El punto de MPS.BR Guía de Implementación Parte 3:2011 14/66

partida del proyecto puede variar de acuerdo con las características de desarrollo de la organización. Por ejemplo, en una fábrica de software, el proceso podría comenzar en el momento de la entrega de los modelos de análisis y proyecto por el cliente. En otros proyectos, sin embargo, el inicio del proyecto podría ser considerado como el levantamiento del alcance inicial con el cliente. La existencia de un proceso para el proyecto, de un proceso estándar y de directrices de adaptación son previstas por el proceso Definición del Proceso Organizacional. Este resultado esperado tiene como objetivo verificar que estos elementos son de hecho utilizados durante la definición del proceso para el proyecto. Además de eso, se debe asegurar también que durante la ejecución del proyecto las reglas para adaptación sean seguidas. Por ejemplo, en el caso de que a lo largo del proyecto se note que una actividad no es necesaria, se debe justificar su exclusión, si es posible, utilizando directrices definidas por la organización. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) Fábrica de Pruebas (Parte 10) El proceso definido para el proyecto engloba actividades y tareas cuya responsabilidad es del adquiriente y otras cuya responsabilidad es del proveedor. Las actividades y tareas del proveedor pueden estar descritas sin detalles, explicitando apenas los productos de trabajo a ser generados. Sin comentario adicional para este resultado. Sin comentario adicional para este resultado. 7 Evaluación y Mejora del Proceso Organizacional (AMP) 7.1 Propósito El propósito del proceso Evaluación y Mejora del Proceso Organizacional es determinar lo cuánto 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. A partir de la aplicación de los procesos estándar de la organización y otros activos de proceso organizacional en la definición, planificación y estimativa de procesos para los proyectos, y de la ejecución de los procesos definidos, pueden ser identificadas oportunidades de mejora en los procesos estándar para señalar puntos de ajustes en los procesos de acuerdo con las necesidades de negocio de la organización. La realización sistemática de revisiones en los procesos, la planificación y la implementación de mejoras identificadas a partir de esas revisiones MPS.BR Guía de Implementación Parte 3:2011 15/66

y de la experiencia en utilizar los procesos estándar de la organización, es el objetivo del proceso Evaluación y Mejora del Proceso Organizacional Los resultados esperados de este proceso están relacionados a resultados esperados de los procesos Definición del Proceso Organizacional (DFP), Gestión de Proyectos (GPR) y Gestión de Recursos Humanos (GRH). La intersección de este proceso con el proceso Definición del Proceso Organizacional (DFP) está presente en los resultados esperados referentes al establecimiento y mantenimiento de las necesidades y objetivos de los procesos de la organización y de mejora que orientan las definiciones de los procesos estándar de la organización, así como en los resultados referentes a las realizaciones de las revisiones de los procesos estándar de la organización que identifican los puntos fuertes y débiles que deben ser tratados en la evolución de estos procesos. La intersección de este proceso con el proceso Gestión de Proyectos (GPR) está presente en el resultado esperado referente a la identificación de oportunidades de mejora en los activos de proceso organizacional con base en los productos de trabajo, mediciones y experiencias documentadas de los proyectos de la organización. La intersección de este proceso con el proceso Gestión de Recursos Humanos (GRH) está presente en el resultado esperado referente al establecimiento y mantenimiento de las necesidades y objetivos de los procesos de la organización y de mejora que orientan la planificación y la implementación de la estrategia de entrenamiento y la identificación de necesidades de entrenamiento que son responsabilidad de la organización. Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes de Software (Parte 8) Fábrica de Software (Parte 9) No son permitidas exclusiones de resultados de este proceso. Como no existen especificidades para organizaciones adquirientes, no fueron incluidos comentarios a los resultados esperados. No son permitidas exclusiones de resultados de este proceso. Como no existen especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios para los resultados esperados. Fábrica de Pruebas (Parte 10) No son permitidas exclusiones de resultados de este proceso. Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios adicionales a los resultados esperados. 7.2 Fundamentación teórica Los objetivos principales de mejora de procesos de una organización son: (i) entender las características de los procesos existentes y los factores que afectan la capacidad del proceso, (ii) planificar e implementar acciones que modifiquen el MPS.BR Guía de Implementación Parte 3:2011 16/66

proceso para atender mejor las necesidades de negocio, y (iii) evaluar los impactos y beneficios obtenidos y compararlos con los costos de los cambios realizados en los procesos [FLORAC y CARLETON, 1999]. Para determinar cuánto es que los procesos estándar contribuyen con la organización, evaluaciones disciplinadas de los procesos deben ser realizadas utilizando un modelo de evaluación de procesos que permita evaluar la capacidad de los procesos con base en un modelo de referencia de procesos de software [ISO/IEC, 2004a]. Por medio del análisis de los resultados obtenidos a partir de esas evaluaciones, pueden ser identificados puntos fuertes, puntos débiles y riesgos involucrados en utilizar los procesos evaluados en un proyecto específico en el contexto de una unidad organizacional [ISO/IEC, 2004b]. A partir del análisis de los resultados de las evaluaciones, son derivadas informaciones de mejoras en los procesos estándar de la organización que podrán ser utilizadas para mejorar los procesos estándar por medio de la realización de cambios en sus capacidades existentes o por medio de la substitución de subprocesos por otros más eficientes o efectivos [FLORAC y CARLETON, 1999]. Informaciones de mejoras en los procesos estándar de la organización pueden ser identificadas de diversas formas. Medidas de supervisión de cada proceso, por ejemplo, pueden ser utilizadas como una manera de evaluar la capacidad de los procesos y determinar oportunidades de mejora en el desempeño de los procesos estándar de la organización. Otra fuente importante de oportunidades de mejora en los procesos estándar son los descubrimientos obtenidos a partir de diagnósticos en los procesos con base en el MPS.BR, aplicaciones no oficiales del CMMI (SCAMPI C o B) o evaluación oficial MPS.BR (MA-MPS) o CMMI (SCAMPI A). El equipo de implementadores de los procesos estándar en una organización también puede proporcionar informaciones relevantes sobre potenciales mejoras en los procesos, pues poseen diversas experiencias en acompañar implementaciones en otras organizaciones que pueden ser compartidas. Otras fuentes de mejoras pueden ser los resultados de actividades de evaluación de productos generados por los procesos, resultados de benchmarking con relación a procesos de otras organizaciones, lecciones aprendidas recolectadas durante la implementación de los procesos y recomendaciones de otras iniciativas de mejoras en la organización [SEI, 2010]. Una vez identificadas las mejoras potenciales en los procesos estándar de la organización, estas son analizadas y transformadas en elementos de acción, que necesitan ser realistas y alineadas a los roles y responsabilidades definidos en la organización. Tales elementos de acción deben ser planificados e implementados, considerando no solo la disponibilidad de recursos, como también los riesgos inherentes a los cambios a ser implementados en los procesos estándar de la organización [ZAHARAN, 1998]. Para tratar de forma adecuada las diferentes variables que afectan iniciativas de mejoras en los procesos, es importante aplicar métodos estructurados para mejorar los procesos de software de modo semejante a proyectos de desarrollo de productos [O HARA, 2000]. Por lo tanto, es recomendable establecer en la organización un programa de mejora de proceso que describa las estrategias, políticas, objetivos, responsabilidades y actividades con el propósito de alcanzar los objetivos de mejora determinados por la organización. De esta forma, proyectos de mejora de proceso pueden ser ejecutados comprendiendo algunas actividades del programa de mejora MPS.BR Guía de Implementación Parte 3:2011 17/66

de proceso de la organización, formando un conjunto coherente de acciones para lograr una mejora específica [ISO/IEC, 2004a]. Métodos de gestión de proyectos pueden ser aplicados adecuadamente para planificar, controlar y supervisar evaluaciones de los procesos estándar de la organización e implementaciones de las oportunidades de mejora identificadas. Una manera eficiente de identificar posibles áreas de mejora en futuros proyectos es por medio de evaluaciones post mortem, que consiste en una evaluación después de la ejecución del proyecto de todos los aspectos del proyecto, incluyendo productos, procesos y recursos [PFLEEGER, 2001]. COLLIER et al. [1996] proponen un proceso de evaluación compuesto por 5 etapas: (i) establecer un mecanismo de recolección de informaciones para el proyecto (generalmente una encuesta implementada en la forma de un cuestionario); (ii) recolección de informaciones objetivas sobre el proyecto (generalmente por medio de medidas relacionadas a la ejecución del proyecto); (iii) conducir un encuentro de profundización (una reunión estructurada envolviendo los miembros del proyecto con el objetivo de recolectar informaciones no capturadas durante el primer esfuerzo de recolección de informaciones); (iv) conducir el día de la historia del proyecto (un encuentro, reuniendo personas clave, para evaluar los principales eventos ocurridos durante el proyecto y las informaciones obtenidas y consolidar los principales problemas y sus posibles causas asociadas); y (v) publicar los resultados. Después de implementar las mejoras en los procesos estándar de la organización, es importante apoyar la utilización adecuada de los procesos y otros activos de proceso organizacional en los proyectos de la organización, así como supervisar esa utilización para asegurar que las mejoras implementadas tengan los efectos deseados y no tengan impacto negativo en los proyectos [ZAHARAN, 1998]. 7.3 Resultados esperados 7.3.1 AMP1 - La descripción de las necesidades y los objetivos de los procesos de la organización son establecidos y mantenidos Los objetivos y necesidades de los procesos estándar de la organización deben ser descritos en detalles, permitiendo comprender, por ejemplo, las características de los procesos y los objetivos esperados de desempeño y efectividad de los procesos. Las organizaciones productoras de software actúan en un mercado dinámico y altamente competitivo. De esta forma, las necesidades y los objetivos de los procesos de la organización deben ser constantemente revisados y actualizados cuando pertinente para asegurar que mejoras continuas en los procesos traigan beneficios reales y tangibles para la organización. La organización debe mantener los registros de las reuniones de definición de objetivos de los procesos y de sus necesidades, así como mantener los registros de cambios en los procesos estándar de la organización de modo que sea posible rastrear los cambios en los procesos a las necesidades y objetivos de los procesos de la organización. MPS.BR Guía de Implementación Parte 3:2011 18/66

7.3.2 AMP2 - Las informaciones y los datos relacionados al uso de los procesos estándar para proyectos específicos existen y son mantenidos La ejecución de procesos en la organización en el contexto de proyectos específicos deja un rastro visible en la forma de informaciones y datos. Esas informaciones y datos son generados conforme el proceso definido para el proyecto con base en los procesos estándar de la organización. Por lo tanto, mecanismos adecuados para preservación y recuperación de esas informaciones deben estar implementados en la organización de modo que sea posible evidenciar la utilización de los procesos estándar de la organización en la definición de procesos para proyectos específicos. La generación y el almacenamiento de informaciones y datos relacionados a la adaptación y utilización de un proceso estándar de la organización para proyectos específicos proporcionan el mecanismo fundamental para la realización de evaluaciones y mejoras en los procesos estándar de la organización. Las informaciones y los datos relacionados al uso de los procesos estándar para proyectos específicos servirán como evidencia objetiva de la ejecución de los procesos definidos. Por lo tanto, esas evidencias deberán estar disponibles para los responsables de las actividades de evaluación de los procesos definidos para los proyectos de manera que sea posible analizar el contexto de generación de cada evidencia, además de obtener informaciones sobre los cambios realizados en las evidencias y comparar evidencias generadas entre diversos proyectos con la intención de verificar la institucionalización de los procesos estándar en la organización. Cambios podrán ser realizados en los procesos estándar de la organización al definir los procesos para los proyectos. Dependiendo de las características y de las restricciones de los proyectos, algunas actividades de los procesos podrán no ser ejecutadas o algunos formalismos en los métodos aplicados pueden ser reducidos, buscando agilizar el proceso y aumentar las posibilidades de éxito. Sin embargo, todos los cambios deberán ser justificados y analizados objetivamente para verificar si existe consistencia en los procesos, o sea, si los estándares de la organización, objetivos y estrategias fueron adecuadamente considerados de forma apropiada. 7.3.3 AMP3 - Evaluaciones de los procesos estándar de la organización son realizadas para identificar sus puntos fuertes, puntos débiles y oportunidades de mejora Periódicamente, evaluaciones de los procesos estándar de la organización deben ser realizadas para posibilitar la identificación y entendimiento de sus puntos fuertes, puntos débiles y oportunidades de mejora. Por lo tanto, deben ser definidos y mantenidos planes de evaluación y mejora de los procesos de la organización, conteniendo informaciones sobre las evaluaciones a ser realizadas en cada período definido. Estos planes deben describir, por ejemplo, el cronograma de las evaluaciones y el tiempo necesario para implementar los procesos hasta las evaluaciones, además de los recursos necesarios para realizar la evaluación, el modelo de referencia que será utilizado como base para realizar la evaluación de los procesos y la logística de la evaluación [SEI, 2010]. Las evaluaciones en los procesos estándar de la organización pueden ser de varios tipos, por ejemplo, diagnósticos en los procesos con base en el MR-MPS, aplicaciones no oficiales del CMMI (SCAMPI C o B) o evaluación oficial MPS o CMMI (SCAMPI A). MPS.BR Guía de Implementación Parte 3:2011 19/66

La ejecución de las actividades realizadas en el contexto de las evaluaciones de los procesos de software, también, deja un rastro visible en la forma de informaciones y datos. Los registros de las evaluaciones pueden abarcar los informes de evaluación del proceso estándar basados en las medidas recolectadas de los procesos, los informes de evaluaciones oficiales MPS.BR o informes de evaluaciones SCAMPI y registros de solicitaciones de cambios en los procesos. 7.3.4 AMP4 - Registros de las evaluaciones realizadas son mantenidos accesibles Los resultados de las evaluaciones deben ser registrados y mantenidos accesibles para análisis futuros, por ejemplo, para identificar informaciones sobre el retorno de la inversión de las mejoras en los procesos de software y para evidenciar la ejecución de actividades de evaluación y mejora en evaluaciones externas de los procesos estándar de la organización. Los resultados también servirán para definir recomendaciones sobre las mejoras que deben ser implementadas en los procesos estándar de la organización. 7.3.5 AMP5 - Los objetivos de mejora de los procesos son identificados y priorizados Los objetivos de mejora de la organización deben ser identificados y priorizados para apoyar la planificación de la implementación de las mejoras identificadas. Los objetivos de mejora son utilizados también para supervisar los efectos de las mejoras implementadas y para asegurar que los objetivos con la implementación de las mejoras están siendo logrados efectivamente. Los objetivos de mejora son definidos con base en las necesidades de mejoras, identificadas a partir de las evaluaciones de los procesos estándar de la organización. Esas evaluaciones producen un conjunto de resultados conteniendo informaciones de los puntos fuertes, puntos débiles y oportunidades de mejora en los procesos estándar de la organización. Sin embargo, esos resultados, generalmente, son muy genéricos y no contienen detalles suficientes para la planificación de acciones de mejora. De esta forma, los resultados de esas revisiones deben ser analizados, revisados y acciones de mejora deben ser identificadas para tratar adecuadamente las debilidades y oportunidades de mejora de los procesos. Objetivos de mejora también pueden ser identificados a partir de solicitaciones de cambios en los procesos estándar de la organización, registradas durante la ejecución de los procesos definidos para proyectos específicos por los equipos de los proyectos y por los equipos de implementadores de los procesos. Estas solicitaciones deben ser registradas y almacenadas en repositorios específicos. Periódicamente, las solicitaciones deben ser analizadas y los objetivos de mejora deben ser identificados y priorizados de acuerdo con las necesidades y objetivos de los procesos de la organización. MPS.BR Guía de Implementación Parte 3:2011 20/66