CMMI

CMMIProfesor: Sr. Gustavo Donoso

Asignatura: “Producción y Distribución de Software”

Alumnos:- Darío Díaz- Iván Vallejos- Manuel Morales

Estructura de la presentación Aspectos generales

Definición Problema Historia Modelos Antecesores

Estructuras de CMMI Continua Escalonada

Áreas de Proceso Software de Implantación Información de Entidades Chilenas

Introducción

Introducción

CMMI Capability Maturity Model Integration Modelo para la mejora o evaluación de

los procesos de desarrollo y mantenimiento de sistemas y productos de software.

Fue desarrollado por el Instituto de Ingeniería del Software de la Universidad Carnegie Mellon (SEI), y publicado en su primera versión en enero de 2002.

Introducción

CMMI Su principal premisa es: “La calidad de un

producto es determinada en gran medida por la calidad del proceso utilizado para desarrollarlo y mantenerlo”

Es un modelo de referencia sobre buenas prácticas, maduras, consolidadas y probadas.

Cubre todo el ciclo de vida, desde el inicio hasta la entrega y mantenimiento.

Indica QUE es lo que se debe hacer, no COMO hacerlo.

Introducción

Muchos Proyectos fracasan, debido a costes, plazos, alcance y nivel de calidad.

Cada vez más organizaciones se preocupan por la implantación de modelos de calidad en el desarrollo del software.

Introducción

Al inicio de la década de los 90, surgieron una serie de iniciativas para aplicar las mejores prácticas en el ámbito del desarrollo del software.

Su orientación era casi exclusivamente a la mejora de los procesos de funcionamiento.

Introducción

Al final de los años 90, se actualizaron normas orientados a la gestión empresarial en su conjunto: ISO/IEC TR 15504 ISO 9000:2000

Historia

El departamento de defensa de los estados unidos tenía muchos problemas con el software que encargaba desarrollar a otras empresas, los presupuestos se disparaban y las fechas se alargaban mas y mas.

Historia

Software Engineering Institute

“Tienen que crear un instituto de la ingeniería del software, dedicado exclusivamente a los problemas del software”.

Historia

Historia

El SEI desarrolló modelos para la mejora y medición de la madurez específicos para varias áreas:

CMM-SW : CMM Para Software P-CMM : Personas CMM. SA-CMM : Adquisición de Software CMM. SSE-CMM : Ingeniería en seguridad de sistemas T-CMM : Confianza CMM SE-CMM : Ingeniería de sistemas CMM. IPD-CMM : Desarrollo de producto integrado.

A finales de la década era habitual que una organización implantara de forma simultánea los modelos: CMM-SW: CMM Para Software SE-CMM: Ingeniería en sistemas CMM.

Historia

SW-CMM SECM IPD-CMM

CMMI

Modelos Predecesores

Ingeniería de Sistemas (SE). Cubre el desarrollo del total de los sistemas,

incluyendo o no el software.

SECM


Ingeniería de Software (SW) Cubre el desarrollo de los sistemas de

software. Los ingenieros de software se enfocan en la aplicación sistemáticas y aproximaciones cuantificadas para el desarrollo, operación, y mantenimiento del software.

SW-CMM


Producto Integrado y Desarrollo de Procesos (IPD-CMM)

Es una aproximación sistemática que obtiene en forma temprana la colaboración de los stakeholders más importantes a través del ciclo de vida del producto para la satisfacción de requerimientos y necesidades de los clientes.

IPD-CMM


Estructura de CMMI

“Un modelo, dos visiones”

Estructura de CMMIRepresentación Continua

La representación continua permite a una organización seleccionar un área de proceso (o el grupo de áreas de proceso) y mejorar procesos relacionado con ella. Esta representación utiliza niveles de la capacidad para caracterizar la mejora concerniente a un área de proceso individual


6 niveles de Capacidad

1. 0.- Incompleto2. 1.- Ejecutado3. 2.- Administrado.4. 3.- Definido5. 4.- Cuantitativamente administrado.6. 5.- Optimizado


Área de Proceso 1 Área de Proceso 2 Área de Proceso n

ObjetivosEspecíficos

ObjetivosGenéricos

PrácticasEspecíficas

PrácticasGenéricasNiveles de Capacidad

Estructura de CMMIRepresentación Escalonada

Se agrupan todas las áreas de proceso en 5 niveles de Madurez para definir una trayectoria de mejora de la organización.

Cada nivel de la madurez proporciona un conjunto de áreas de proceso que caracterizan diversos comportamientos de la organización.


5 Niveles de Madurez

1. Inicial 2. Administrado3. Definido4. Administrado cuantitativamente 5. Optimizado


Área de Proceso 1 Área de Proceso 2 Área de Proceso n

ObjetivosEspecíficos

ObjetivosGenéricos

PrácticasEspecíficas

PrácticasGenéricas

CompromisoRealización

CapacidadRealización

Dirigirimplementación

Verificarimplementación

Estructura de CMMI

Áreas de procesos

Áreas de procesos

Definición: Un área de proceso es un conjunto de prácticas en un área que, cuando se implementa colectivamente, satisface a un conjunto de objetivos considerados importantes para crear una mejora significante en esa área.

Los componentes de un área de proceso están agrupados en tres categorías:

Áreas de procesos

Áreas de ProcesoÁreas de Proceso

InformativoInformativoEsperadoEsperadoRequeridoRequerido

Componentes Requeridos

Áreas de procesos



Obj. GeneralObj. General Obj. EspecíficoObj. Específico

Componentes Requeridos Objetivo genérico: Los objetivos genéricos

asociados a un nivel de capacidad establecen lo que una organización debe alcanzar en ese nivel de capacidad.

Objetivo específico: Los objetivos específicos se aplican a una única área de proceso y localizan las particularidades que describen que se debe implementar para satisfacer el propósito del área de proceso.

Áreas de procesos

Componentes Esperados

Áreas de procesos



Pract. GeneralPract. General Pract. EspecíficaPract. Específica

Componentes Esperados Práctica genérica: Una práctica genérica se

aplica a cualquier área de proceso porque puede mejorar el funcionamiento y el control de cualquier proceso.

Práctica específica: Una práctica específica es una actividad que se considera importante en la realización del objetivo específico al cual está asociado.

Áreas de procesos

Componentes Informativos

Áreas de procesos



NombresNombres NotasNotas

Informativo: Los componentes informativos proveen detalles que ayudan a pensar en la manera en como lograr los componentes requeridos y esperados. Notas introductorias Nombres Tablas de relaciones práctica -

objetivo Elaboraciones de prácticas

genéricas: cómo la práctica genérica debe aplicarse al área de proceso.

Áreas de procesos

Ejemplo: AP Manejo de Requerimientos (REQM)

Objetivo General El propósito del Manejo de Requerimientos (REQM) es

manejar los requerimientos de los productos del proyecto y sus components e identificar inconsistencias entre esos requerimientos y los planes de proyecto y los productos de trabajo.

Objetivos Especificas (SG ) : Manejar Requerimientos SP 1.1 Obtener un Entendimiento de los

Requerimientos SP 1.2 Manejar Cambios de Requerimientos SP 1.3 Mantener un Seguimiento Bidireccional de

los Requerimientos SP 1.4 Identificar Inconsistencias entre el Proyecto

y los Requerimientos

Áreas de procesos

Existen 25 áreas de proceso, las cuales se dividen en 4 Categorías:


SoporteSoporteIngenieríaIngenieríaAdmin. De ProyectoAdmin. De ProyectoAdmin. De Proc.Admin. De Proc.

Áreas de procesos

Áreas de procesos1. Administración de Procesos:

Contienen las actividades relacionas con definir, planear, desplegar, implementar, monitorear, controlar, evaluar, medir, y mejorar procesos.

Foco de proceso de organización Definición de proceso de organización Entrenamiento organizacional Funcionamiento de proceso de organización Innovación y despliegue organizacional

Áreas de procesos2. Administración de proyectos:

Cubren actividades relacionas con planear, monitorear y controlar el proyecto.

Planeamiento del Proyecto Monitoreo y control del proyecto Administración de proyecto integrado Administración de Riesgos Integración de Equipo Administración Cuantitativa del Proyecto

Áreas de procesos3. Ingeniería

Actividades de implementación y mantenimiento compartidas por las disciplinas de ingeniería. Las AP se escribieron usando una terminología general para la ingeniería, de manera que cualquier disciplina técnica pueda involucrarse en el proceso de desarrollo de productos.

Desarrollo de los requisitos Administración de Requerimientos Solución Técnica Integración de Producto Verificación Validación

Áreas de procesos4. Support

Cubren las actividades que proveen soporte y mantenimiento al desarrollo de productos. Encaminan procesos que se usan en el desempeño de otros procesos. Las áreas de proceso incluidas en Support son:

Administración de Configuración Proceso y aseguramiento de la calidad del

producto Medida y Análisis Ambiente de organización para la integración Analisis de Decición y resolución Análisis causal y resolución

Software deImplementación

“Autoevalúese con CMMI”

CMM Quest

Permite efectuar evaluaciones según la representación continua.

La evaluación se limita a asignar valores a los objetivos.

No tiene soporte para Standard CMMI Appraisal Method for Process Improvement (SCAMPI).

Appraisal Wizard

Soporta gran parte de los modelos CMM y CMMI

Pensada para cubrir todas las necesidades del método SCAMPI

Se necesita gran domino del modelo Al ser tan amplia y detallada, no es

para nada fácil de utilizar

Niveles de Empresas Chilenas

NIVELES CMMI, EMPRESAS CHILENAS

N° Empresa Modelo Nivel

01SONDA Sistemas Financieros

SW-CMMI 3

02 Adexus SW-CMMI 2

03 TUXPAN Software S.A. SW-CMMI 3

04 LAN Airlines S.A. SW-CMMI 2

Conclusiones

La calidad del resultado depende principalmente de la calidad de los procesos empleados

Por esto es importante conocer metodologías como CMMI, que nos ayuden a guiar y evaluar los procesos de desarrollo de software.

CMMI BLOG

http://cmmiuct.wordpress.com/

Referencias

http://es.wikipedia.org/wiki/CMMI http://www.sei.cmu.edu/cmmi/ http://www.qualitatis.org/content/blog

section/3/42/ http://www.spin-chile.cl/ http://www.ieee.org.ar/

actividadesdocs.asp

Gracias…

Muchas Gracias a todos…

CMMI

Documents

Transcript of CMMI