Valencia, 21 de Abril de 2009

Transcripción

1 Por qué la mejora de procesos de software Valencia, 21 de Abril de 2009 Capability Maturity Model and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University ESI

2 Agenda 1. Motivación para la Mejora de Procesos 2. Modelos de Mejora de Procesos CMMI ISO/IEC (SPICE) ITMark ISO/IEC Beneficios y Conclusiones ESI

3 1. Motivación para la mejora de procesos ESI

4 Software is everywhere Fuente: Paul Nielsen, SEI 2007 ESI

5 Ejemplo del Crecimiento del Software 1990: 1 millón de líneas de código ITEA: el volumen de embedded software se duplica cada 2 años 2010: 100 millones de líneas de código Windows 2000: 35 M LOC Windows XP: 40 M LOC Debian 3.1: 230 M LOC Fuente: Paul Nielsen, SEI 2007 ESI

6 Impacto del Software Se achaca a las TIC el 45% del aumento de la productividad, y el 25% del aumento del PIB en Europa Fundación BBVA Impacto de las TIC en el crecimiento económico español (03/2007): relaciona productividad y gasto en TIC Plan Avanza: Objetivo TIC el 7% PIB en 2010 ESI

7 Qué está sucediendo? Problemáticos 46% Éxitosos Problemáticos Fallidos Definiciones Éxitosos 35% Fallidos (Cancelados) 19% En tiempo, en presupuesto, en funcionalidad prometida Tarde, sobrepasado el presupuesto, falta funcionalidad Proyectos cancelados De una inversión en proyectos de $255 billones, se desperdician $55 billones De cada 100 proyectos, 94 se reinician Al liberar un producto, tan sólo están incluidas el 52% de las funciones y propiedades requeridas. De media los costes de los proyectos suponen el 143% de lo estimado, y el 82% se pasa de plazos Source: Standish Group Chaos Report ESI

8 Estamos mejorando, pero 1994 Chaos Report Problemáticos 53% 2006 Chaos Report Problemáticos 46% Éxitosos 16% Fallidos (Cancelados) 31% Éxitosos 35% Fallidos (Cancelados) 19% El dinero perdido en gastos del proyecto ha descendido del 32% al 21.5% Los sobrecostes han descendido del 180% al 43% Las compañías liberan los productos a sus clientes con un 15% de los defectos Muchas compañías gastan del 30% al 44% de su tiempo y dinero en rehacer el software que ya han escrito ESI

9 CALIDAD Bill Gates en COMDEX Si la General Motors pudiese tener un desarrollo tecnológico comparable al de la industria TIC, hoy conduciríamos todos autos de $25 que recorrerían millas con un galón de combustible ESI

10 CALIDAD Respuesta de Rick Wagoner (1/2) Si GM se hubiese desarrollado como Microsoft, hoy: Su coche tendría 2 accidentes al día sin causa explicable Cada vez que se pintasen las líneas de la carretera debería comprar un coche nuevo De vez en cuando su coche se saldría de la carretera sin causa explicable; usted lo aceptaría, arrancaría de nuevo y seguiría conduciendo Si al hacer una determinada maniobra su coche se detuviese y se negase a arrancar de nuevo, se vería obligado a instalar un nuevo motor en el coche Sólo se podría sentar usted en su coche, aunque podría adquirir Car95 o Car2000 y pagar por los asientos adicionales ESI

11 CALIDAD Respuesta de Rick Wagoner (2/2) Si GM se hubiese desarrollado como Microsoft, hoy: El indicador de aceite, el de exceso de temperatura y el de batería se reemplazarían por una lámpara general de fallo del vehículo El sistema Airbag le preguntaría Está usted seguro? antes de activarse Ocasionalmente se le bloquearían todas las puertas del vehículo. Podría usted desbloquearlas tirando del tirador al tiempo que gira la llave con una mano y con la otra agarra la antena de radio Cada vez que GM lanzase un nuevo vehículo debería usted aprender a conducir de nuevo, porque ninguno de los mandos del coche funcionaría igual que en el anterior modelo ESI

12 Objetivo en tiempo y forma a menor coste con menos defectos PRODUCIR MEJOR SOFTWARE Qué hacer Modelos de Mejora de Procesos (Calidad) Cómo hacerlo Métodos Técnicas Metodologías ESI

13 La premisa El desarrollo de software debe ser contemplado como un proceso de negocio que tiene que ser gestionado, ser eficiente y ser predecible Artesanía / Ingeniería ESI

14 La Calidad tiene coste Prevención Evaluación Fallos internos Fallos externos Costes asociados con la prevención de defectos Planificación Documentación Entrenamiento Herramienta Políticas y procedimientos Proyectos de mejora de la calidad Toma y análisis de datos Análisis de fallos y de causas Costes asociados con la búsqueda de defectos Revisiones Requisitos Diseño Planes de pruebas Casos de pruebas Revisiones e inspecciones de código Testing (Primera vez) Auditorías Evaluaciones de Certificación Clase A, B, C Costes asociados con defectos detectados antes de la entrega/ instalación de un producto Rehacer Requisitos Diseño Codificación Documentatión Re-testing Menor eficiencia (trabajo repetido, desviaciones de plazos, presupuestos, etc.) Costes asociados con defectos detectados tras la entrega/instalación de un producto Garantías Gestión de quejas Proyectos perdidos Soporte técnico Nuevas releases, parches, Services Packs (terminología MS) ESI

15 pero es muy rentable CMM Nivel CMM Nivel Nuevo desarrollo Coste de Calidad CMM Nivel CMM Nivel 4 Coste de No-Calidad ROI 7.7:1, Productividad 140%, $4.48M ahorrados en 6 proyectos durante 1 año Source: Ratheon Electronic Systems Experience in Software Process Improvement, CMU/SEI-95-TR-017, November 1995 ESI

16 Qué he mejorado? LA PRODUCTIVIDAD!!!!! ESI

17 Dónde se desarrolla? En pequeñas empresas - PyME En pequeñas organizaciones En pequeños proyectos PYME TIC: 99,2% del total empresas TIC 67% de los puestos de trabajo 58% valor añadido EUROSTAT Key Figures in Europe ESI

18 Situación PYME TIC Un alto porcentaje de empresas TIC son PYME. El número medio de trabajadores es bajo. Los recursos económicos son limitados. Su enfoque es a corto plazo: desean soluciones a problemas conocidos con la mínima inversión, mínima interrupción y resultados rápidamente demostrables. Su principal fortaleza en el mercado es la cercanía con el cliente. ESI

19 Situación PYME TIC Dificultad para comercializar gran escala sus actuales productos y servicios. Dificultad para gestionar el crecimiento de la estructura productiva. Dificultad para adaptarse a un nuevo mercado: Globalización Factorías de Software near/off shoring Tecnología emergentes (OSS,..) ESI

20 Situación PYME TIC En la mayoría conscientes de la problemática.. Reducir quejas del cliente Reducir defectos Reducir costes Incrementar ventas Incrementar satisfacción del cliente Mejora del acceso al mercado Mejora de productividad Mejora de proceso Mejora de calidad de producto 0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00% 70,00% 80,00% 90,00% 100,00% ESI *Motivación para comenzar un programa de mejora SoftAragón 2006

21 Objetivo con las empresas del Sector TIC Mejora de la Competitividad de la PYME. Industrializar y madurar el sector TIC. Generar confianza y visibilidad de un sector TIC maduro. Medida para potenciar la Calidad del Software de la industria TIC ESI

22 2. Modelos de Mejora de Procesos Software ESI

23 Qué es un proceso de software? Conjunto de actividades para desarrollar y mantener el software y los productos asociados (documentos de diseño, casos de pruebas, manuales de usuario ) y para gestionar su producción Procedimiento y métodos que definen las relaciones entre las tareas Gente con conocimiento, motivación y formación Proceso Herramientas y equipos ESI

24 Premisa básica de la mejora de procesos PRODUCTO Malo Bueno Situación esperada Esfuerzo heroico PROCESO No debiera ocurrir Negocio maduro Bueno La calidad de un producto está determinada en gran medida por la calidad de los procesos de desarrollo y mantenimiento del producto Basado en los principios de TQM de Shewhart, Juran, Deming y Humphrey. ESI

25 Qué es y por qué es importante usar un modelo de procesos? Un modelo de procesos es una colección estructurada de prácticas que describen las características de los procesos efectivos. Las prácticas incluidas son aquéllas que han demostrado ser eficaces en la industria. Un modelo indica QUÉ se debe hacer, NO CÓMO hacerlo Un modelo proporciona un punto de inicio el beneficio de experiencias previas de la comunidad un lenguaje común y visión compartida un marco para priorizar mejoras ESI

26 Entonces Qué modelo utilizo? ITIL ISO 20000???? ESI

27 Uso del sentido común All models are wrong, but some are useful. George Box Aproximaciones simplificadas de la realidad que aportan entendimiento. ESI

28 Ciclo de vida Desarrollo & Servicio Calidad debe cubrir todo el Ciclo de Vida ESI

29 Mapa Mejora de procesos ESI Fuente: Paul Nielsen, SEI 2008

30 Ciclo de vida Desarrollo & Servicio Métodos de Evaluación de Procesos ISO/IEC SPICE (Futuro ISO ) MODELOS (QUÉ hacer) CMMI-DEV y CMMI-ACQ Spice-for-Space Automotive SPICE ITMark-DEV ISO / (?) CMMI-SVC ISO ITMark-SVC DESARROLLO SW METODOLOGÍAS (CÓMO hacerlo) RUP SCRUM, XP, Agile Métodos Estructurados PMI PSP-TSP Otros muchos SERVICIOS DE EXPLOTACIÓN SW ITIL etc Calidad debe cubrir todo el Ciclo de Vida ESI

31 Modelo de Excelencia EFQM ESI

32 EFQM Excellence model for SIOs version 2.2 Sw and SE Processes Process Areas Process Management ENABLERS Project Management PEOPLE Engineering PEOPLE RESULTS Support RESULTS LEADERSHIP POLICY AND STRATEGY PROCESSES CUSTOMER RESULTS KEY PERFORMANCE RESULTS PARTNERSHIPS AND RESOURCES SOCIETY RESULTS ESI SIO: Sw. Intensive Organisations

33 Visión general de CMMI ESI

34 Qué es CMMI? Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para tener procesos eficaces La familia de productos CMMI aborda los siguientes materiales: Modelo Evaluación Formación CMMI se organiza en constelaciones : Desarrollo (CMMI DEV) Adquisición (CMMI ACQ) Servicios (CMMI - SVC) Source: 2006 Carnegie Mellon University; CMMI v1.2 Upgrade Training, Module 5 ESI

35 CMMI-DEV Proporciona guías para medir, controlar y gestionar los procesos de desarrollo Constelaciones CMMI 16 áreas de proceso usadas en todos CMMI-SVC Proporciona guías para aquellos que proveen servicios dentro de la organización y a clientes externos Source: 2006 Carnegie Mellon University; CMMI v1.2 Upgrade Training, Module 5 CMMI-ACQ proporciona una guía para habilitar una gestión en adquisiciones informada y decisiva ESI

36 5 4 3 Foco en la mejora continua El proceso se controla cuantitativamente Niveles de Madurez CMMI Escalonado Proceso definido para la organización y proactivo 3. Definido 5. En optimización 4. Gestionado cuantitativamente 2 Proceso definido caracterizado para proyectos y frecuentemente reactivo 2. Gestionado 1 Proceso impredecible, poco controlado 1. Inicial ESI

37 NIVEL FOCO AREAS DE PROCESO Calidad 5 En optimización 4 Gestionado cuantitativamente 3 Definido 2 Gestionado Niveles de Madurez Mejora continua del proceso Gestión cuantitativa Estandarización del proceso Gestión de proyectos básica Innovación y despliegue organizativo Análisis causal Rendimiento de procesos organizativos Gestión de proyectos cuantitativa Desarrollo de requerimientos Solución técnica Integración de producto Verificación Validación Foco en proceso organizativo Definición de proceso organizativo + IPPD Entrenamiento organizativo Gestión de proyecto integrada + IPPD Gestión de riesgos Análisis de decisiones y soluciones Gestión de requerimientos Planificación de proyecto Seguimiento y control de proyecto Gestión de acuerdos con proveedores Medición y análisis Aseguramiento de la calidad Gestión de la configuración Productividad Riesgo 1 Inicial Sin áreas de proceso el trabajo se realiza de alguna manera! Retrabajo ESI

38 N. Madurez ML2 ML 1 Escalonada ML3 ML4 ML5 Organización Nivel Madurez 5 OID, CAR Nivel Madurez 4 OPP, QPM Nivel Madurez 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR Nivel Madurez 2 REQM, PP, PMC, MA, PPQA, CM, SAM Resumen CMMI-DEV Áreas de proceso Innovación y Despliegue Organizativo (OID) Análisis Causal (CAR) ML5 Rendimiento de Procesos Organizativos (OPP) Gestión de Proyectos Cuantitativa (QPM) ML4 Desarrollo de Requisitos (RD) Solución Técnica (TS) Integración de Producto (PI) Verificación (VER) ML3 Validación (VAL) Foco en Proceso Organizativo (OPF) Definición de Proceso Organizativo + IPPD (OPD) Formación Organizativa (OT) Gestión de Proyecto Integrada + IPPD (IPM) Gestión del Riesgo (RSKM) Análisis de Decisiones y Soluciones (DAR) ML2 Gestión de Requisitos (REQM) Planificación de Proyecto (PP) Seguimiento y Control de Proyecto (PMC) Gestión de Acuerdos con Proveedores (SAM) Medición y Análisis (MA) Aseguramiento Calidad Proceso Producto (PPQA) Gestión Configuración (CM) N. Capacidad Continua PA Gestión Proyecto PP, PMC, SAM, IPM, RSKM, QPM PA PA Áreas Proceso Gestión Proceso OPF, OPD, OT, OPP, OID Ingeniería REQM, RD, TS, PI, VER, VAL Soporte CM, PPQA, MA, CAR, DAR ESI

39 Del nivel de madurez 2 al nivel de madurez 3 P & P Proyectos P & P Análisis de Procesos Organización P & P Políticas y Procedimientos P & P Buenas Prácticas P & P Implantación Organizativa P & P Nivel 2 Nivel 3 ESI

40 Moviéndose a niveles de madurez superiores Nivel 3 Nivel 4 Política y Procedimientos Implantación en la organización Nivel 5 Cambios según se requieran Objetivos de Negocio estratégicos Cambios por prevención, tecnología o mejora Conocimiento cuantitativo de la capacidad de los procesos y productos ESI

41 Estructura del Área de Proceso Área de Proceso(AP) Propósito Introducción AP Relacionadas Metas Específicas Metas Genéricas Prácticas Específicas Prácticas Genéricas Resultados típicos Subprácticas Subprácticas Elaboraciones Requerido Esperado Informativo ESI

42 Ejemplo: Gestión de Requisitos 1/5 Process Area 1 Staged v1.2 Maturity Level Process Area 2 Process Area n El propósito de la Gestión de Requisitos (REQM) es gestionar los requisitos de los productos del proyecto y los componentes del producto, e identificar inconsistencias entre dichos requisitos y los planes de proyecto y productos de trabajo. Generic Goals Specific Goals G ALS Note: no common features Generic Specific Practices Practices ESI SG1: Gestionar Requisitos Se gestionan los requisitos y se identifican las inconsistencias con los planes de proyecto y productos de trabajo. GG 2: Institucionalizar un Proceso Gestionado: El proceso es institucionalizado como un proceso gestionado.

43 Ejemplo: Gestión de Requisitos 2/5 Requirements Development (RD) Develop Customer Requirements Develop Product Requirements Analyze and Validate Requirements Stakeholders Requirements Manage Requirements Requirements Management (REQM) ESI

44 Ejemplo: Gestión de Requisitos 3/5 SP1.1 Obtener Conocimiento de los Requisitos SP1.2 Obtener Compromiso a los Requisitos SP1.3 Gestionar los Cambios a los Requisitos SP1.4 Mantener Trazabilidad Bidireccional entre los Requisitos SP1.5 Identificar Inconsistencias entre los requisitos y productos de trabajo ESI Identificar quienes son los actores Criterios de Aceptación de Requisitos Documentación de los Requisitos Registro de los Requisitos Registros de Compromisos Aceptación de Requisitos Proceso de Gestión del cambio Análisis de Impacto Seguimiento del cambio Registros de cambio Matriz de trazabilidad Entre Requisitos Reqs- Casos de prueba, Reqs- plan de proyecto Registro de inconsistencias y de acciones correctivas. Identificación de cambios a realizar en otros productos y planes

45 Ejemplo: Gestión de Requisitos 4/5 Meta Genérica 2: Institucionalizar un Proceso Gestionado GP 2.1 Establecer una política organizativa GP 2.2 Planificar el proceso GP 2.3 Proporcionar recursos GP 2.4 Asignar responsabilidades GP 2.5 Entrenar al personal GP 2.6 Gestionar configuraciones GP 2.7 Identificar e involucrar agentes relevantes GP 2.8 Supervisar y controlar el proceso GP 2.9 Evaluar objetivamente la adherencia GP 2.10 Revisar el estado con un nivel superior de Gerencia ESI

46 Ejemplo: Gestión de Requisitos 5/5 GG2: Institucionalizar un proceso gestionado El proceso es institucionalizado como un proceso gestionado. GP 2.1 Establecer una política en la organización Política Roles Canales de comunicación Criterios de aceptación GP 2.2 Planificar el proceso Existe tarea en el plan de proyecto GP 2.3 Proporcionar recursos GP 2.4 Asignar responsabilidades GP 2.5 Formar al personal La tarea está asignada a un responsable Herramientas, Plantillas,.. Tiempo (plan SP2.2) Personal Definición de roles y sus responsabilidades Planes de formación (especialmente referida al área de proceso) Saben realizar los responsables su trabajo? Y además GP 2.6, 2.7, 2.8, 2.9, 2.10 ESI

47 Referencias Oficiales CMMI Modelo CMMI-DEV Informes General CMMI Informes de evaluaciones, método de evaluación y requisitos. Información para la adopción de CMMI, comparación y equivalencias entre modelos. Resultados de rendimientos, ROI, casos de éxito Programa de formación y eventos, CMMI, CMM, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office. CMM Integration, SCAMPI, and IDEAL are service marks of Carnegie Mellon University. ESI

48 Visión general de ISO/IEC SPICE ESI

49 ISO/IEC SPICE ISO/IEC es un estándar internacional que es aplicable a cualquier organización/empresa que quiera conocer y mejorar la capacidad de sus procesos. Es independiente del tipo de organización, del modelo del ciclo de vida, de la metodología de desarrollo y de la tecnología utilizada. No pretende fijar la manera de realizar los procesos dentro de una organización, sino que valora su capacidad y ayuda a proponer mejoras que aumenten esta capacidad. La descripción de los procesos de Desarrollo está en ISO (los de Servicios en ISO-20000) ESI

50 PRIMARY Life Cycle Processe Acquisition Process Group (ACQ) ACQ.1 Acquisition preparation ACQ.2 Supplier selection ACQ.3 Contract agreement ACQ.4 Supplier monitoring ACQ.5 Customer acceptance Supply Process Group (SPL) SPL.1 Supplier tendering SPL.2 Product release SPL.3 Product acceptance support Engineering Process Group (ENG) ENG.1 Requirements elicitation ENG.2 System requirements analysis ENG.3 System arquitecture design ENG.4 Software requirements analysis ENG.5 Software design ENG.6 Software construction Operation Process Group (OPE) OPE.1 Operational use OPE.2 Customer support Dimensión de procesos ENG.7 Software integration ENG.8 Software testing ENG.9 System integration ENG.10 System testing ENG.11 Software installation ENG.12 Software and system maintenance SUPPORTING Life Cycle Processes ORGANIZATIONAL Life Cycle Processes Management Process Group (MAN) MAN.1 Organizational alignment MAN.2 Organizational management MAN.3 Project management MAN.4 Quality management MAN.5 Risk management MAN.6 Measurement Process Improvement Process Group (PIM) PIM.1 Process establishment PIM.2 Process assessment PIM.3 Process improvement Resource and Infraestructure Process Group (RIN) RIN.1 Human resource management RIN.2 Training RIN.3 Knowledge management RIN.4 Infraestructure Reuse Process Group (REU) REU.1 Asset management REU.2 Reuse program management REU.3 Domain engineering Support Process Group (SUP) SUP.1 Quality assurance SUP.2 Verification SUP.3 Validation SUP.4 Joint review SUP.5 Audit ESI SUP.6 Product evaluation SUP.7 Documentation SUP.8 Configuration management SUP.9 Problem resolution management SUP.10 Change request management

51 Niveles de Capacidad Atributos Optimizando Predecible Establecido Gestionado Realizado Incompleto 5.1 Innovación procesos 5.2 Optimización procesos 4.1 Medición de los procesos 4.2 Control de procesos 3.1 Definición de procesos 3.2 Despliegue de los procesos 2.1 Gestión del proceso 2.2 Gestión de los productos 1.1 Ejecución del proceso ESI

52 Ejemplo de Perfil de Madurez Representación Continua (CMMI ó SPICE) No existen Niveles de Madurez definidos Nivel de Capacidad MAN3 SUP1 SUP8 MAN6 ENG1 Áreas de Proceso individuales Project Management Quality Assurance Configuration Management Measurement Requirements Elicitation ESI

53 ISO SPICE es un Modelo con Representación Continua sólo 5 Niveles de Capacidad para cada Proceso (como CMMI) Algunas variantes tienen Niveles de Madurez (Spice-for-Space, Automotive SPICE, TR ) Técnicamente similar a CMMI En proceso de migración / integración a ISO/IEC con ISO20000 y más Realmente Parte 2 es sólo Norma de Evaluación de Procesos (no dice qué procesos) La descripción de los procesos de Desarrollo está en ISO (los de Servicios en ISO-20000) ESI

54 Ventajas e inconvenientes SPICE / CMMI ISO/IEC es una Norma ISO, evolucionada a partir de CMM y otros modelos. CMMI no es ISO. No existe un mecanismo de Acreditación de Organismos de Certificación (similar a ENAC), por tanto no hay certificaciones reconocidas. No existe un mecanismo de acreditación de Auditores 15504, Formadores, etc. Demasiadas variantes SPICE sin reconocimiento mutuo En vías de migración y modificación CMMI compatible (realmente su método de evaluación SCAMPI con , que es la única parte normativa de la familia 15504) Escasa implantación y reconocimiento de salvo en mercados específicos (relativamente pequeños) Al no haber Niveles de Madurez comparables dificulta mucho el benchmarking entre empresas pedir que mis suministradores sean SPICE nivel 2 es algo que no tiene sentido ESI

55 Modelo ESI

56 Qué es IT Mark? Certificación que evalúa los procesos técnicos y de negocio, diseñado específicamente para PYME del sector TI Procesos de desarrollo de software CMMI-DEV v1.2, representación escalonada, niveles de madurez 2 y 3 Procesos de gestión del negocio Ten squared (10²) del estilo del Modelo EFQM, simplificado Procesos de gestión de la seguridad de la información Basado en ISO/IEC 27000:2005 Information Technology Security techniques Diseñado para PYME, a quienes ayuda a posicionarse a través de la Mejora Continua, arrancando una iniciativa de mejora con sostenibilidad. ESI

57 Niveles de IT Mark y CMMI 5. En optimización 4. Gestionado cuantitativamente 3. Definido 2. Gestionado 1. Inicial CMMI ESI

58 Niveles IT Mark Nivel Procesos de negocio (10squared) Procesos de seguridad de la información (ISO27000) Clase de la evaluación Proceso de software (CMMI) Hallazgos Ninguna categoría en rojo y > 75% Nivel 3 Clase B, Nivel de madurez 3 Ningún área de proceso en rojo & Nº áreas de proceso en verde >=11 Ninguna categoría en rojo y > 60% Nivel 2 Clase B, Nivel de madurez 2 Ningún área de proceso en rojo & Nº áreas de proceso en verde >=3 No más de una categoría en rojo y > 50% Nivel 1 Clase C, Nivel de madurez 2 No más de 2 AP alcanzando menos de 50%. Estas AP no pueden ser ni PP, ni PMC. Más información ESI

59 ESI Compatibilidad ITMark e ISO/IEC SPICE Perfil Objetivo del proyecto: Nivel de Capacidad MAN3 SUP1 SUP8 MAN6 ENG1 Project Managem ent Quality Assurance Configuration Managem ent Measurem ent Requirements Elicitation

60 Visión general de ISO/IEC ESI

61 Ciclo de vida Desarrollo & Servicio ISO Calidad debe cubrir todo el Ciclo de Vida ESI

62 Perfil de empresa participante CMMI, ISO15504, ITMark Desarrollo Software Procesos ISO20000 Provisión de Servicio Atención y soporte Preventa Implantación SW Soporte y Mantenimiento Instalación Infraestructura física Los procesos que abarca la ISO20000 están especialmente orientados a actividades relacionadas con la provisión del servicio una vez que el producto se ofrece en el mercado y posteriormente se implanta y se provee de soporte y mantenimiento al cliente. ESI

63 Procesos ISO/IEC Requisitos para el sistema de Gestión Planificando e implementando Gestión de Servicios Planificando e implementando Servicios nuevos o cambiados Gestión de Capacidad Gestión de Continuidad y Disponibilidad de Servicio Procesos de Versiones Gestión de Versiones Procesos de Entrega de Servicios Gestión de Niveles de Servicio Informes de Servicio Procesos de Control Gestión de Configuraciones Gestión de Cambios Procesos de Resolución Gestión de Incidentes Gestión de Problemas Gestión de Seguridad de la Información Presupuestación y Contabilización de Servicios de TI Procesos de Relaciones Gestión de Relaciones de Negocio Gestión de Proveedores ESI

64 Category Process Management Project Management Service Establishment and Delivery Support Engineering CMMI for Services Process Area Organizational Innovation and Deployment (OID) Organizational Process Definition (OPD) Organizational Process Focus (OPF) Organizational Process Performance (OPP) Organizational Service Management (OSM)* Organizational Training (OT) Capacity and Availability Management (CAM) Integrated Project Management (IPM) Project Monitoring and Control (PMC) Project Planning (PP) Requirements Management (REQM) Risk Management (RSKM) Quantitative Project Management (QPM) Service Continuity (SCON)* Supplier Agreement Management (SAM) Incident and Request Management (IRM) Service Delivery (SD) Service System Development (SSD)* Service Transition (ST) Causal Analysis and Resolution (CAR) Configuration Management (CM) Decision Analysis and Resolution (DAR) Measurement and Analysis (MA) Problem Management (PRM) Process and Product Quality Assurance (PPQA) none ESI Diferencias CMMI-SVC frente a CMMI-DEV

65 3. Conclusiones y datos ESI

66 5 Razones clave para la adopción La Mejora de Procesos Software ayuda a las organizaciones: Mejoras en la entrega de los productos en funcionalidad, coste y plazos. Coordinación eficaz con proveedores y clientes. Proveer productos y servicios con reconocimiento de calidad world class (CMMI, ITMark, SPICE,..) Definición e implementación de una perspectiva integrada de negocio e ingeniería. Procesos comunes, integrados y basados en la mejora para el desarrollo de sistemas y software. ESI

67 ESI Coste y Beneficio CMMI

68 Beneficios CMMI Predicción Level Predicted Performance Results Results 5 Optimizing 4 Managed 3 Defined 2 Repeatable 1 Initial Probability Probability Probability Probability Probability Target N-Z Target N-Y Target N-X Target N Target N-a Time/$/... Time/$/... Time/$/... Time/$/... Time/$/... Q u a l i t y R I S K P r o d u c t i v i t y Performance continuously improves. Performance improves based on quantitative understanding of process and product. With well-defined processes performance improves. Plans based on past performance are more realistic. Targets not achieved. Commitments not kept. ESI

69 Resultado de mejora CMMI Process Improvement Metric Median Total Data Points Minimum Maximum Mean ROI 3 Ratio 9 2 Ratio 13.3 Ratio 4.6 Ratio Impact on Cycle Time -38% 5-15% -50% % Reduction in Rework -60% 1-60% -60% -60% Impact on Quality (% defect reduction) Impact on Productivity (Improvement) % 20-0,5% 95% -47,6% +39% 12 +5% +250% +57% Impact on Schedule Variance -40% 3-35% -50% -41,7% Impact on Quality (% of defects found) 98% 1 98% 98% 98% Reduction in Project Cost -30% 2-20% -40% -30% Cost of the Improvement (% of total engineering effort) 1.1 % % 1.1 % 1.1 % ESI Datos publicados referidos a DACS is a Department of Defense (DoD) Information Analysis Center (IAC). DACS technical area of focus is Software Technology and Software Engineering, in its broadest sense.

70 ESI Caso de estudio CMMI Nivel 4

71 Caso de estudio CMMI Nivel 4 6,7 hh/pf * 5,7inc./100pf = 5,7 incidencias por cada 670 horas de desarrollo!! ESI

72 Datos de programa de mejora CMMI Esfuerzo Interno % Dedicación de recursos internos a la definición de procesos y soluciones, incluido el desarrollo de herramientas Consultoría externa % Contratación de consultoría externa como soporte a la iniciativa de mejora Formación 5.90 % Contratación de formación externa y dedicación interna a actividades de formación Varios 1.80 % Viajes, compra de material, ESI

73 Beneficios para las pymes I Capacidad gestión del proceso productivo con datos objetivos: incidencias, cambios en requisitos, fechas, etc. Organización menos dependiente de las personas. Fundamental en una PYME. Mejora en los métodos de estimación del trabajo a realizar y de planificación. Incremento de la satisfacción del cliente externo e interno. Mayor confianza ante el sector y ante los clientes. Mejor posicionamiento en la oferta de contratos públicos y grandes cuentas. *Datos Competic/SofAragón 2006 ESI

74 Beneficios para las pymes II Reducción del coste de la calidad Mejora de la moral de los trabajadores Mejora de la satisfacción del cliente Mejora de la calidad de producto (numero de defectos) Mejora de la productividad Mejora del tiempo de desarrollo Calendario y presupuestos mas predecibles 0,00 1,00 2,00 3,00 4,00 5,00 6,00 7,00 8,00 9,00 10,00 *Datos SoftAragón 2006 ESI

75 Y cuánto tiempo cuesta un proyecto de mejora? Source: SEI, Process Maturity Profiles for CMMI, 2009 End-Year Update ESI

76 Soy pyme esto es para mí? ESI Source: SEI, Process Maturity Profiles for CMMI, 2009 End-Year Update

77 Perfil de madurez mundial ESI Source: SEI, Process Maturity Profiles for CMMI, 2009 End-Year Update,

78 Madurez en España 1º país en evaluaciones CMMI de Europa con algún nivel alcanzado. Gran crecimiento relativo, junto con el de China y Argentina Datos en España 71% - PYME Nº de CMMI ORGANIZACIONES NIVEL 1 1 1% NIVEL % NIVEL % NIVEL 4 3 2% NIVEL 5 4 2% TOTAL 180 EMPRESAS SOLICITUDES PLAN AVANZA CMMI % SPICE TOTAL % ESI Diciembre Diciembre Diciembre Diciembre

79 Para más información Félix Nanclares Gerente de Proyectos Asociativos Parque Tecnológico, # 204 E Zamudio Bizkaia (Spain) Tel.: Fax: Mikel Emaldi Director Relaciones Institucionales Mikel.Emaldi@esi.es Parque Tecnológico, # 204 E Zamudio Bizkaia (Spain) Tel.: Fax: ESI Sexta edición de la conferencia SEPG LA 2010, del 10 al 12 de noviembre en Medellín, Colombia. La SEPG LA es la edición de las conferencias SEPG para Latinoamérica, el lugar de encuentro de la Comunidad de Mejora de Procesos Latinoamericana para aprender, compartir experiencias y desarrollar habilidades para alcanzar los mejores resultados de negocio. La SEPG LA 2010 combinará un programa de máxima calidad con el networking esperado. Organizada por SEI y ESI