1 / 54

CMMI

CMMI. Profesor: 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

Download Presentation

CMMI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. 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 • Cubre el desarrollo del total de los sistemas, incluyendo o no el software. SECM

  16. Ingeniería de Software (SW) Modelos Predecesores • 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 • 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. Estructura de CMMI “Un modelo, dos visiones”

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

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

  21. Estructura de CMMIRepresentació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 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.

  23. Estructura de CMMIRepresentación Escalonada • 5 Niveles de Madurez • Inicial • Administrado • Definido • Administrado cuantitativamente • Optimizado

  24. Estructura de CMMIRepresentació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 Esperado 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 • 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 • 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 • 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 • 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 deImplementació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. 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

  44. Niveles de Empresas Chilenas

  45.  NIVELES CMMI, EMPRESAS CHILENAS

More Related