Concepto Madurez de un Software y Sus Ejemplos

Integrantes: Catalina Castro Claudia Daz Escuela: Informtica y Tecnologa Carrera: Ingeniera de Ejecucin en Informtica Modulo: Ingeniera del Software

Profesor: Oscar Castro Fecha entrega: 16 de Mayo de 2012

20

INDICE
Conclusin .. 3 Introduccin ..4 Desarrollo del Tema

Madurez de un Software.............................................................................................. .....5 Ejemplo 1 ......................................................................................................... ......................13 Ejemplo 2. .........14 Ejemplo 3. ..17 Ejemplo 4. ..18

20

CONCLUSIN
Podemos concluir que gracias a un modelo de madurez se puede conocer el proceso que nos muestra y explica el camino de una organizacin para alcanzar excelencia en la gerencia de proyectos, a travs de diversos niveles de madurez. El modelo de madurez se ha convertido en una herramienta para la direccin continuada de proyectos. Cumpliendo as con los objetivos fundamentales del modelo CMM: establecer un indicador de calidad y una mejora continua de la organizacin.

20

INTRODUCCIN
En el siguiente informe se da a conocer ejemplos. A nivel mundial, organizaciones de todos los tamaos han abordado iniciativas de mejora de la madurez y calidad del software con nfasis en la mejora de sus procesos de desarrollo y mantenimiento del software. La tendencia actual en el sector de las Tecnologas de Informacin se dirige hacia la adquisicin de un nivel de madurez en los procesos de software que asegure una mayor calidad de los productos obtenidos y que sirva de base para la mejora continua de este tipo de procesos. A continuacin abordaremos de una mejor manera el tema a tratar, el cual trata de las Herramientas o tcnicas para medir la madurez del proyecto. el concepto de software junto a 4

20

DESARROLLO DEL TEMA PROCESO DE MADUREZ

Un modelo de madurez consiste en un proceso que nos muestra y explica el camino de una organizacin para alcanzar la excelencia en la gerencia de proyectos, a travs de diversos niveles de madurez. El mismo, ofrece una estructura para comparar el grado de desarrollo de la capacidad de la administracin de proyectos existente en la organizacin. Existen varios modelos, la mayora de ellos basados en el modelo de madurez de desarrollo de software CMM. Entre los reconocidos estn: 1.Organizacional Project Management Maturity Model (OPM3): Propuesto por PMI en el 2003, est basado integralmente en el PMBOK. El Proyecto de Gestin Organizacional Modelo de Madurez o OPM3 es reconocida a nivel mundial las mejores prcticas estndar para la evaluacin y el desarrollo de capacidades en gestin de cartera, gestin de programas y gestin de proyectos. Fue publicado por el Project Management Institute (PMI). OPM3 provee un mtodo para que las organizaciones entiendan sus organizativas de gestin de proyectos procesos y medir sus capacidades en la preparacin para la mejora. OPM3 continuacin, ayuda a las organizaciones a desarrollar el plan de trabajo que la empresa va a seguir para mejorar el rendimiento.

20

OPM3 ofrece la clave de la Gestin de Proyectos de Organizacin (OPM), con tres elementos interrelacionados: Conocimiento - Ms informacin sobre cientos de Gestin de Proyectos de Organizacin (OPM) las mejores prcticas. Evaluacin - Evaluar las capacidades actuales de una organizacin e identificar las reas en necesidad de mejoramiento. Mejora - Utilizar la evaluacin completa para trazar los pasos necesarios para alcanzar los objetivos de mejora del rendimiento.

2. Modelo de madurez en Administracin de Proyectos de Arnold Kerzner: La madurez es una consecuencia de la planeacin estratgica. No se logra en gerencia de proyectos si no es parte de la estrategia corporativa y se concentra en los aspectos estratgicos y tcticos ms que en los operacionales. Niveles de maduracin Nivel 1: Lenguaje Comn
Prcticamente no hay soporte a nivel gerencial. No hay inversin en entrenamiento y educacin en gerencia de

proyectos.

Nivel 2: Procesos Comunes

Se reconocen los beneficios de la Gerencia de Proyectos.

Apoyo organizacional a todos los niveles Reconocimiento de la necesidad de procesos y metodologas Nivel 3: Metodologa nica Procesos integrados. Apoyo cultural. Apoyo gerencial a todos los niveles.

Nivel 4: BenchMarking Benchmarking con industrias similares y distintas. Benchmarking cuantitativo en procesos y metodologas.

20

 Benchmarking cualitativo en la aplicacin de la Gerencia de Proyectos.

Nivel 5: Mejoramiento Continuo

Registro de las lecciones aprendidas. Planeacin estratgica para la Gerencia de Proyectos.

3. Modelo de Madurez en Administracin de Proyectos de la empresa PM Solutions. Dos marcos de referencia: Procesos 5 procesos: iniciacin, planeacin, ejecucin, control y cierre reas de Conocimiento 8 conjuntos de habilidades / experiencias 1 noveno conjunto de experiencia (integracin) Niveles de maduracin Nivel 1: Procesos inciales Hay reconocimiento de la existencia de procesos de Gerencia de Proyectos. No hay prcticas o estndares establecidos.

Nivel 2: Procesos Estructurados y Estndares

Existe documentacin para estos procesos bsicos. La gerencia apoya la implementacin de la Gerencia de Proyectos. Organizacionales y Procesos

Nivel 3: Estndares Institucionalizados

La gerencia est activamente involucrada. Muchos de los procesos estn automatizados.

20

Nivel 4: Procesos Administrados

Todos los proyectos utilizan los procesos, con mnimas excepciones. Cada proyecto es evaluado y administrado a la luz de otros proyectos.

Nivel 5: Procesos Optimizados

Se utilizan medidas de eficiencia y efectividad para tomar decisiones en el proyecto. Todos los cambios en el proyecto son evaluados a la luz de las mtricas.

4.Modelo Trillium es un producto usado por Bell Canada para dar valor al desarrollo de un producto y apoyar las capacidades de proveedores de telecomunicaciones o productos basados en tecnologas de la informacin existentes o futuros. El modelo ha sido diseado para ser aplicado a sistemas de software empotrados tales como sistemas de telecomunicaciones, no obstante buena parte del modelo puede ser aplicado a otros segmentos de la industria del software como sera el rea de Management Information Systems. Con respecto al CMM, el modelo Trillium, se distingue en que: define roadmaps en lugar de reas clave; tiene una perspectiva orientada al producto, hacindolo ms general y de amplio uso; da amplia cobertura a los aspectos que inciden o impactan en la capacidad del proceso; y, se enfoca al cliente en lugar del desarrollo mismo. Esto consigue que se definan prcticas que guan al proyectista sobre cmo conseguir lo que desea un usuario/cliente donde, en lugar de sealar determinadas metas que se deben alcanzar con ciertas prcticas de diseo, se buscan aquellas prcticas que habiliten la consecucin de lo que desea el usuario. A semejanza del modelo CMM, el modelo Trillium presenta una escala de cinco niveles de madurez: Nivel 1. Desestructurado. En este nivel el proceso de desarrollo es ad-hoc. Los proyectos frecuentemente no pueden satisfacer objetivos de calidad o de programacin. El xito posible se basa ms en el trabajo de los individuos que en la propia estructura e infraestructura organizacional. Nivel 2. Repetible y orientado al proyecto. El xito individual del proyecto se consigue a travs de una frrea planificacin y control

20

de gestin del proyecto, dando especial nfasis a los requerimientos de gestin, tcnicas de estimacin y configuracin del cambio. Nivel 3. Definido y orientado al proceso. Aqu los procesos son definidos y utilizados al nivel organizacional, no obstante se acepta que el proyecto sea adaptado a las circunstancias. Los procesos son controlados y mejorados. Se incorporan requerimientos ISO 9001 como procesos de entrenamiento y auditoria interna. Nivel 4. Gestionado e integrado. La monitorizacin y anlisis del proceso es usado como mecanismo clave de mejora. Procesos de gestin del cambio y programas de prevencin de defectos son integrados. Las herramientas CASE se integran dentro del proceso. Nivel 5. Completamente integrado. Metodologas formales son extensivamente usadas. Repositorios organizacionales son usados para soportar y mantener la historia del proceso de desarrollo.

Qu es el Modelo de Madurez de la Capacidad del Software?

En el Modelo de Madurez de la Capacidad del Software del SEI (Software Capability Maturity Model, SW-CMM) se definen un conjunto de reas clave del proceso, que describen las funciones de ingeniera del software que deben llevarse a cabo para el desarrollo de una buena prctica, agrupadas en cinco niveles inclusivos. Estos niveles sirven de referencia para el conocimiento del estado de la madurez del proceso del software en la organizacin. Mediante un amplio conjunto de mtricas se determina la calidad de cada una de las reas clave, obtenindose una visin precisa del rigor, la eficacia y la eficiencia de la metodologa de desarrollo de una organizacin productora de software. Cada una de las reas est organizada en cinco secciones, denominadas caractersticas comunes: Compromiso de realizacin. Capacidad para llevarla a cabo. Actividades que hay que realizar. Medicin y anlisis. Verificacin de la implementacin.

20

En cada caracterstica comn se especifican unas prcticas claves que son normas, procedimientos y actividades cuya realizacin lleva a la consecucin de los objetivos del rea. En algunos casos se detallan subprcticas ms especficas, guas e interpretaciones de la prctica y, cuando procede, ejemplos y referencias cruzadas a otras prcticas. Por ejemplo, las prcticas de la caracterstica medicin y anlisis describen las medidas que se han de realizar sobre el rea de proceso correspondiente. Asimismo, el SEI define indicadores clave, que son aquellas prcticas clave o componentes de prcticas clave que ofrecen una visin mayor de la consecucin de los objetivos de un rea clave de proceso.

Los niveles en los que se agrupan las reas claves de proceso son inclusivos para alcanzar uno es necesario haber alcanzado (y mantener) todos los anteriores:

20

Inicial Est caracterizado por una aproximacin intuitiva al proceso de desarrollo del software. El xito depende del esfuerzo individual. No se han definido procesos metodolgicos, o se han definido pero no se siguen. Es necesario realizar medidas de lnea base, es decir, medidas que servirn para estimar y planificar en el futuro. Asimismo, es el momento de hacer un esfuerzo de estructuracin y control en el proceso.

Repetible La madurez metodolgica de la organizacin permite estimar fiablemente el tamao funcional o fsico del sistema, as como recursos, esfuerzo, costes y calendario. Se han sentado las bases para repetir xitos anteriores en proyectos con aplicaciones similares. Las reas clave de proceso definidas en este nivel, cuyo estado se puede conocer mediante diversas mtricas, son las siguientes: Gestin de requisitos. Planificacin del proyecto software. Seguimiento y control del proyecto.

20

 Gestin de la subcontratacin del software. Aseguramiento de la calidad del software. Gestin de la configuracin del software. Definido Se conoce la forma de construccin del sistema. El proceso del software de las actividades de la gestin e ingeniera se documenta y se estandariza. Las actividades intermedias estn bien definidas y por tanto se pueden medir. Por ejemplo se pueden medir los defectos o la densidad de los errores del producto y detectar con tiempo y aplicar una buena gestin de riesgo. Las areas definidas en este nivel son: Desarrollo y mejora de los procesos de la organizacin. Definicin de los procesos de la organizacin. Programa de formacin. Gestin integrada del software. Ingeniera de producto software. Coordinacin intergrupos. Revisin conjunta.

Por ejemplo, en el rea 1 se podra medir el esfuerzo empleado en las actividades de evaluacin, desarrollo y mejora de los procesos de la organizacin comparado con el plan. En el rea 2 se podra medir el coste de las actividades de definicin del proceso.

Gestionado Se aade la gestin a un proceso definido. Se usa realimentacin desde las primeras actividades del proyecto para seleccionar prioridades en las actividades actuales y conocer cmo se emplean los recursos. Los efectos de los cambios en una actividad se pueden seguir en otras. Se recopilan medidas detalladas del proceso del software y de la calidad del producto. En definitiva, se evala la efectividad de las actividades del proceso. Por ejemplo, se podra medir cunto se est produciendo para ser reutilizado, cunto se est reutilizando de proyectos anteriores, cmo y cundo son descubiertos los defectos y la relacin entre fechas de finalizacin de los mdulos y fechas previstas.

20

Las reas clave definidas en este nivel son dos: Gestin cuantitativa del proyecto. Gestin de calidad del software. Optimizado Existe una mejora continua de los procesos. Las medidas de actividades se usan para mejorar el proceso, eliminando y aadiendo actividades y reorganizando su estructura como respuesta a los resultados de las medidas. Las reas definidas para este nivel son: Prevencin de defectos. Gestin de cambios tecnolgicos Gestin de cambios en los procesos. Por ejemplo, en el rea 2 se podran medir los efectos de la implementacin de los cambios tecnolgicos comparados con los objetivos. En el rea 3 se podra medir el nmero de propuestas de mejora enviadas por departamento. Adems del Modelo de Madurez de la Capacidad del Software existen el Modelo de Madurez de la Capacidad en la Adquisicin de Software (SACMM), y el Modelo de Madurez de la Capacidad de las Personas (P-CMM)-.

Qu es CMMI?

20

CMMI (Capability Maturity Model Integration) es un conjunto de modelos elaborados por el SEI que permiten obtener un diagnstico preciso de la madurez de los procesos relacionados con las tecnologas de la informacin de una organizacin, y describen las tareas que se tienen que llevar a cabo para mejorar esos procesos. Los mdulos CMMI son extractos de los modelos CMMI a los que se han aadido posibles pruebas a realizar, y sirven de base para emprender la mejora de procesos. Existen actualmente cuatro modelos CMMI, que contemplan los procesos de mejora en las diversas reas de los sistemas de informacin., de manera que la organizacin deber elegir el que ms se ajuste a sus necesidades: CMMI-SE/SW/IPPD/SS CMMI-SE/SW/IPPD CMMI-SE/SW CMMI-SW

Para cada modelo hay una representacin continua y otra por etapas. Las diferencias son las siguientes:

20

Representacin Continua Las reas de proceso se organizan por categoras de reas de proceso. La mejora se mide en niveles de capacidad que reflejan la implantacin incremental de un rea de proceso particular. Hay seis niveles de capacidad (0-6) Hay dos tipos de prcticas: bsicas y avanzadas.

Representacin por Etapas Las reas de proceso se organizan por niveles de madurez. La mejora se mide utilizando niveles de madurez que reflejan la implementacin concurrente de mltiples reas de proceso. Hay cinco niveles de madurez (1-5).

Hay slo un tipo de prcticas. El concepto de prctica avanzada se consigue por otros medios. Los niveles de capacidad se Las prcticas genricas se usan usan para organizar las segn caractersticas comunes. prcticas genricas. Todas las prcticas genricas Slo se usan en un rea de proceso se usan en todas las reas de las prcticas aplicables al nivel de proceso. madurez. Existen prcticas genricas Existen prcticas genricas para los para los niveles de capacidad niveles de madurez del 2 al 5. del 1 al 5. Algunas de las prcticas utilizadas en la representacin continua se aplican en algunas reas de proceso. Existe la posibilidad de obtener No es posible determinar con qu el nivel de madurez equivalente perfil de la representacin continua al perfil obtenido. se corresponde un determinado nivel. Con la finalidad de determinar la madurez de los procesos de las organizaciones y de hacerlos ms efectivos existe un programa de Evaluacin que se compone de 2 grandes reas basadas en el CMM y CMMI. Evaluaciones basadas en CMM El mtodo de evaluacin interna utilizado en SW-CMM se denomina Evaluacin Basada en CMM para Mejora del Proceso Interno (CMM-Based Appraisal for Internal Process Improvement, CBA IPI). Se trata de un mtodo que saca a relucir los puntos fuertes y dbiles del actual proceso del software de la organizacin, utilizando CMM como modelo de referencia, y que tambin sirve para que la organizacin se comprometa a mejorar su proceso del software.

20

Las medidas que se llevan a cabo se encuadran en la fase de diagnstico de IDEAL para la mejora del proceso del software. CBA IPI est actualmente en su versin 1.2 y cumple los requisitos CAF8. Este mtodo se lleva a la prctica por un supervisor de evaluacin interna9 CBA IPI autorizado por el SEI. Los requisitos para convertirse en supervisor de evaluacin interna CBA IPI son:
1. Haber participado como miembro de un equipo de evaluacin CBA

IPI en al menos dos proyectos de evaluacin en los dos aos anteriores al momento de la solicitud. 2. Tener al menos diez aos de experiencia en desarrollo o mantenimiento de software en el rea tcnica apropiada (diseo de software, aseguramiento de la calidad, anlisis de requisitos). 3. Tener al menos dos aos de experiencia en direccin de desarrollo de software. 4. Tener una titulacin o probada experiencia en una disciplina tcnica apropiada. 5. Haber superado el curso de Introduccin a CMM. Una vez admitido, el solicitante deber realizar el curso correspondiente y liderar un equipo de evaluacin bajo la supervisin del SEI antes de un ao despus de haber terminado la formacin. El mtodo de evaluacin externa utilizado en la versin 1.1 de SW-CMM es la Evaluacin de la Capacidad del Software (SCE, Software Capability Evaluation). Este mtodo se utiliza en adquisicin de software para determinar cul es el mejor proveedor, y para monitorizacin de contratos. Tambin se puede usar internamente para preparar a la organizacin para una evaluacin externa. Mediante la utilizacin de este mtodo, la organizacin puede responder con precisin a la pregunta: Hasta qu punto es competente un posible proveedor en su proceso del software? En definitiva, SCE es una herramienta de ayuda a la decisin para identificar los riesgos que se pueden derivar de los procesos de desarrollo de software de un proveedor, riesgos que en ltima instancia pueden

20

incluso poner en peligro el cumplimiento de los objetivos organizativos. SCE, al igual que CBA IPI, cumple los requisitos CAF. Los requisitos para ser un supervisor de evaluacin externa SCE son similares a los de CBA IPI. En SA-CMM tambin se usa CBA IPI como mtodo de evaluacin interna. Una organizacin o un consultor independiente pueden llevar a cabo evaluaciones SA-CMM para uso interno o a terceros. Para ello deben firmar con el SEI un Acuerdo de Supervisin de Evaluacin SEI SA-CMM. Este acuerdo permite que puedan dirigir equipos de evaluacin e impartir formacin sobre SA-CMM. Pero para conseguirlo deben haber superado la formacin correspondiente y dirigir con xito, bajo la observacin del SEI, a un equipo de evaluacin SACMM. Finalmente, tambin existe un mtodo de evaluacin interna para P-CMM, existiendo a su vez el correspondiente Acuerdo de Supervisin de Evaluacin P-CMM en los mismos trminos que para SA-CMM. Para llevar a cabo la evaluacin basada en CMMI el SEI ha diseado el Mtodo Estndar de Evaluacin de CMMI para Mejora de Procesos (Standard CMMI Appraisal Method for Process Improvement, SCAMPI), actualmente en su versin 1.1. Este mtodo cumple todos los requisitos que se exigen a un mtodo de evaluacin ARC de clase A y puede dar soporte a la gestin de las evaluaciones de la norma ISO/IEC 15504. SCAMPI permite: Comprender mejor el nivel de competencia en ingeniera de una organizacin, identificando los puntos fuertes y dbiles de sus procesos actuales. Relacionar esos puntos fuertes y dbiles con el modelo CMMI. Priorizar planes de mejora. Centrarse en las mejoras ms importantes que haya que acometer segn el nivel de madurez de la organizacin y de los recursos de que disponga. Obtener para la organizacin su clasificacin en uno de los niveles del modelo. Identificar riesgos de desarrollo y adquisicin relativos a las limitaciones de la organizacin.

Las evaluaciones de las organizaciones se llevan a cabo por supervisores de evaluacin_- externos que tienen la autorizacin del SEI. Estos supervisores han recibido la formacin necesaria y tienen acceso a

20

mtodos de evaluacin, materiales de formacin, asistencia tcnica y actualizacin formativa proporcionados por el SEI. A travs de su participacin en evaluaciones de organizaciones y de los mecanismos de realimentacin previstos en los mtodos de evaluacin, los supervisores de evaluacin contribuyen a la mejora continua de la tecnologa de evaluacin del SEI. Para que un profesional tenga la consideracin de supervisor de evaluacin SCAMPI debe estar en posesin del informe favorable que acredite que ha superado el plan formativo para supervisores de evaluacin diseado por el SEI. Para acceder a esta formacin son necesarios los siguientes requisitos:

El SEI debe haber aceptado como asociada para servicios de evaluacin SCAMPI a la organizacin a la que el profesional pertenezca. Completar con xito el proceso de seleccin, acreditando los conocimientos mnimos requeridos. Se exige haber formado parte de un equipo de evaluacin SCAMPI en al menos dos evaluaciones en los dos aos inmediatamente anteriores a la solicitud_5. Aprobar un curso de introduccin a CMMI. Aprobar un curso de conocimientos intermedios de CMMI.

20

Carencias frecuentes dentro de las empresas. A continuacin se definen una serie de carencias ms habituales dentro de los departamentos de desarrollo y mantenimiento de software. Estas dificultades representan el punto de inicio para la adopcin del modelo CMM 1- Los proyectos se desvan en coste y plazo. La calidad es baja. 2- El software resultante tiene numerosos defectos y no satisface las expectativas de los clientes. 3- Poca documentacin de las aplicaciones y los proyectos. 4- No se puede validar la calidad del software en puntos intermedios. 5- No existe control sobre los cambios en los requisitos. 6- No existe uniformidad entre el trabajo desarrollado por distintas personas. 7- El xito de los proyectos depende de las capacidades individuales. 8- Si personas clave dejan de participar en el proyecto se para la fabrica. Ante este tipo de deficiencias que en la actualidad se dan en los departamentos de desarrollo y mantenimiento de software, se debe de decidir sobre la conveniencia de implantar una metodologa compatible con CMM. No obstante, antes de comenzar su implantacin se deben de valorar 5 cuestiones de suma importancia para el xito de este modelo. 1- Compromiso de toda la organizacin. La implantacin del CMM debe de aglutinar los esfuerzos de toda la organizacin desde la direccin hasta el equipo que finalmente se encarga del desarrollo del proyecto. 2- Se deben realizar moderadas inversiones inciales en medios o herramientas que sirvan de base para la implantacin del modelo CMM. 3- Los resultados derivados de la implantacin de este tipo de modelos no siempre son visibles a corto plazo. 4- Una vez implantado el modelo CMM, debe mantenerse de forma permanente e ir

20

Autoalimentndose para lograr el objetivo: un desarrollo de software bajo el paradigma de la mejora continua. 5- La adopcin de prcticas de planificacin, gestin, seguimiento y control dentro de las empresas supone un esfuerzo y un cambio de mentalidad empresarial sin el cual no es posible alcanzar una implantacin exitosa del modelo CMM.

Beneficios y ventajas de la implantacin del CMM

A continuacin se exponen las 7 principales ventajas que aporta a las organizaciones la implantacin del modelo CMM. 1- Mayor efectividad en la deteccin de errores a lo largo del ciclo de vida, reduciendo drsticamente el nmero de errores que afecta directamente a los clientes y usuarios. 2- Reduccin de las desviaciones en plazo de los proyectos. 3- Mayor tolerancia al cambio e incremento de la capacidad de adopcin y adaptacin de nuevas tecnologas 4- Mejora en la rapidez y efectividad de respuesta ante exigencias del negocio (Reduccin del Time to Market) 5- Mejora en la colaboracin y comunicacin efectiva con implicados internos y externos. 6- Resultados predecibles en los proyectos. 7- Implementar tcnicas proactivas de gestin, mitigando los riesgos que afectan los proyectos. Todos los beneficios derivan finalmente en un incremento de la productividad en la realizacin de Software y en una considerable mejora de la calidad del producto terminado.

20

7 pasos en la implantacin de CMM A continuacin se exponen una serie de pasos principales de los que costa la implantacin del modelo CMM: 1. Apreciacin Inicial - Evaluacin de la documentacin - Entrevistas a proyectos - Anlisis de carencias con respecto a CMM-SW o CMMI-SW/SE - Informe de puntos fuertes / dbiles y plan de accin 2. Definir / mejorar proceso - Definir y documentar mejoras del proceso - Identificar nuevas responsabilidades - Mecanizacin de aspectos del proceso - Preparar formacin en las nuevas prcticas 3. Piloto de la solucin - Seleccin de un grupo de proyectos piloto - Formacin a proyectos piloto - Ejecucin y uso de las nuevas prcticas en un entorno controlado - Retroalimentacin y recomendaciones 4. Implementacin - Identificacin de grupos de implantacin gradual - Formacin a implicados - Asignacin de nuevas responsabilidades - Implementacin de las herramientas 5. Seguimiento y soporte - Soporte telefnico, por e-mail y presencial - Reuniones de lanzamiento del uso de las nuevas prcticas - Revisiones peridicas y obtencin de mtricas - Seguimiento con la Direccin 6. Evaluacin / certificacin - Apreciacin parcial CMM para las reas de proceso implementadas - Apreciacin completa representada por niveles

20

- Acciones recomendadas - Certificado por Lead Asesor / Tasador autorizado por el SEI.

7. Mejora continua - Implementar acciones recomendadas - Estudio y anlisis de las mtricas y los resultados del seguimiento con la Direccin - Implementar mejoras correspondientes a otras reas de procesos y/o niveles de madurez

20