Proceso de Mejora Continuo: CMM y CMMI Software Engineering Institute (SEI) evaluación SCAMPI CMM (Década del ’90): Características Mide la capacidad del proceso seguido para desarrollar software incrementando la predictibilidad en cuanto a costos, tiempos y calidad lograda. Es el modelo más utilizado en la industria de software. No contempla todas las necesidades de la organización, por lo que se fueron agregando otros modelos que daban solución a los problemas detectados. CMMI (A partir del 2001): Características Sirve como guía única para la mejora de múltiples disciplinas tales como la Ingeniería de sistemas (SE), Ingeniería de software (SWE), el desarrollo integrado entre el producto y el proceso (IPPD) y la gestión de compras y control de proveedores. Objetivos que se persiguen: Determinar el nivel de madurez del Proceso de Desarrollo (Indicador de calidad) Servir de guía en el Proceso de Desarrollo permitiendo la Mejora Continua de la organización.

Proceso de Mejora Continuo: CMMI (Cont.) Características principales: Para cada nivel de madurez se describen áreas de proceso a ser desarrolladas y para cada Área de Proceso se establecen niveles de capacidad a ser alcanzados. Cada área de proceso se asocia a uno de los 5 niveles de madurez. Una organización alcanza un nivel de madurez determinado cuando ha puesto en práctica todas y cada una de las áreas de proceso aplicables a ese nivel y a todos los niveles inferiores. Los niveles de capacidad se designan para cada área de proceso, proporcionando un orden recomendado para acercarse a la mejora dentro de cada área de proceso. Permite flexibilidad en las áreas a seleccionar para mejorar y para alinearse a los objetivos del negocio definidos por la organización. Es compatible con ISO 9000:2000 Sienta las bases para que las organizaciones del sector de desarrollo de software se encaminen hacia el ciclo de mejora continua.

Proceso de Mejora Continuo: CMMI Mejora continua de los procesos Nivel 5: Optimizado Procesos analizados y medidos Nivel 4: Gestionado de forma cuantitativa Procesos estandarizados Nivel 3: Definido Gestión básica de proyectos Nivel 2: Gestionado 5 Niveles de Madurez 23 Áreas Claves de Proceso Nivel 1: Inicial http://www.sei.cmu.edu/library/assets/cmmi-dev-v12-spanish.pdf

Basado en las competencias y acciones individuales de las personas

¿Qué es una evaluación SCAMPI? Una evaluación SCAMPI® es la forma de evaluar de cómo una Empresa que trabaja con procesos y metodología(s) para ejecutar sus procesos cumple con un modelo de la familia de CMMI. Es decir, una evaluación SCAMPI es una forma para: Identificar qué haces; Entender cómo lo haces; Verificar que haces lo que dices, como dices que lo haces; Verificar que esta forma de ejecutar los procesos se apega a lo que dice algún modelo de CMMI® (CMMI-SVC, CMMI-DEV, CMMI-ACQ, People CMM) .

La evaluación SCAMPI es un acrónimo de “Método estándar de Evaluaciones basadas en CMMI® para la Mejora de Procesos” por sus siglas en inglés (Standard CMMI-Based Appraisal Method for Process Improment). Una evaluación SCAMPI® se puede utilizar para diagnósticos internos y/o para la evaluación de proveedores y es capaz de producir un perfil de capacidades con base en algunas áreas de proceso (PA’s por sus siglas en inglés), o bien un nivel de madurez para una organización. La idea de una evaluación SCAMPI® es identificar que  las prácticas que se estén evaluando no sólo están descritas, sino que están aplicadas en los distintos proyectos y, de hecho, están institucionalizadas, es decir, son parte de la cultura de la organización. Existen diferentes tipos de evaluaciones: A, B y C. Las evaluaciones clase A son las más amplias y robustas, son las únicas que pueden determinar un nivel de madurez y/o capacidad. Las evaluaciones SCAMPI son ejecutadas por un evaluador líder certificado por el SEI

REQM PROPÓSITO gestionar los requisitos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requisitos y los planes y productos de trabajo del proyecto. Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Se garantiza que los requisitos  son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los  requisitos hacia las diferentes entidades del producto y a la inversa.

Cuando se presentan cambios a requisitos, y es algo que sucederá en la gran mayoría de las ocasiones, pueden presentarse inconsistencias particularmente por problemas de comunicación dentro del equipo que desconoce los cambios que han sido aprobados. REQM debe identificar esas situaciones y tomar acciones correctivas para garantizar su solución. Gestionar los requisitos SG1 Los requisitos son gestionados y las inconsistencias con los planes y productos de trabajo del proyecto son identificadas. SP1.1 Desarrollar una comprensión del significado de los requisitos con los proveedores de los requisitos. SP1.2 Obtener el compromiso de los participantes de proyecto sobre los requisitos. SP1.3 Gestionar los cambios a los requisitos a medida que evolucionan durante el proyecto SP1.4 Mantener la trazabilidad bidireccional entre requisitos y productos de trabajo SP1.5 Asegurar que planes del proyecto y productos de trabajo permanecen alineados con requisitos.