CMMI Profesor: Sr. Gustavo Donoso

Presentación del tema: "CMMI Profesor: Sr. Gustavo Donoso"— Transcripción de la presentación:

1 CMMI Profesor: Sr. Gustavo Donoso
Asignatura: “Producción y Distribución de Software” Alumnos: Darío Díaz Iván Vallejos Manuel Morales

2 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

3 Introducción

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

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

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

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

8 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

9 Historia

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

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

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

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

14 Modelos Predecesores SECM IPD-CMM SW-CMM CMMI

15 Ingeniería de Sistemas (SE).
Modelos Predecesores Ingeniería de Sistemas (SE). Cubre el desarrollo del total de los sistemas, incluyendo o no el software. SECM

16 Ingeniería de Software (SW)
Modelos Predecesores 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

17 Producto Integrado y Desarrollo de Procesos (IPD-CMM)
Modelos Predecesores 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

18 “Un modelo, dos visiones”
Estructura de CMMI “Un modelo, dos visiones”

19 Estructura de CMMI Representació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

20 Estructura de CMMI Representación Continua
6 niveles de Capacidad 0.- Incompleto 1.- Ejecutado 2.- Administrado. 3.- Definido 4.- Cuantitativamente administrado. 5.- Optimizado

21 Estructura de CMMI Representación Continua
Área de Proceso 1 Área de Proceso 2 Área de Proceso n Objetivos Específicos Objetivos Genéricos Prácticas Específicas Prácticas Genéricas Niveles de Capacidad

22 Estructura de CMMI Representació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.

23 Estructura de CMMI Representación Escalonada
5 Niveles de Madurez Inicial Administrado Definido Administrado cuantitativamente Optimizado

24 Estructura de CMMI Representación Escalonada
Área de Proceso 1 Área de Proceso 2 Área de Proceso n Objetivos Específicos Objetivos Genéricos Compromiso Realización Capacidad Realización Dirigir implementación Verificar implementación Prácticas Específicas Prácticas Genéricas

25 Estructura de CMMI

26 Áreas de procesos

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

28 Áreas de procesos Los componentes de un área de proceso están agrupados en tres categorías: Áreas de Proceso Requerido Esperado Informativo

29 Áreas de procesos Componentes Requeridos Áreas de Proceso Requerido
Esperado Informativo Obj. General Obj. Específico

30 Áreas de procesos 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.

31 Áreas de procesos Componentes Esperados Áreas de Proceso Requerido
Informativo Pract. General Pract. Específica

32 Áreas de procesos 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.

33 Áreas de procesos Componentes Informativos Áreas de Proceso Requerido
Esperado Informativo Nombres Notas

34 Áreas de procesos 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.

35 Á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

36 Áreas de procesos Existen 25 áreas de proceso, las cuales se dividen en 4 Categorías: Áreas de Proceso Admin. De Proc. Admin. De Proyecto Ingeniería Soporte

37 Áreas de procesos Foco de proceso de organización
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

38 Áreas de procesos Planeamiento del Proyecto
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

39 Áreas de procesos Desarrollo de los requisitos
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

40 Áreas de procesos Administración de Configuración
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

41 Software de Implementación
“Autoevalúese con CMMI”

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

43

44

45

46 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

47

48

49 Niveles de Empresas Chilenas

50 NIVELES CMMI, EMPRESAS CHILENAS
Modelo Nivel 01 SONDA Sistemas Financieros                      SW-CMMI  3  02 Adexus SW-CMMI 2 03 TUXPAN Software S.A. 3 04 LAN Airlines S.A.

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

52 CMMI BLOG

53 Referencias http://es.wikipedia.org/wiki/CMMI

54 Gracias… Muchas Gracias a todos…