Factorías de Software

Transcripción

1 Factorías de Software ESI

2 Agenda Problemática de la Industria del Software Mejora de procesos Reutilización Sistemática Conclusiones ESI

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

4 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

5 Problemas hoy la Industria informática hoy encuentra Excesivos defectos en sus productos Excesivos recursos gastados en mantenimiento, en lugar de centrarlos en el desarrollo de nuevos productos y sistemas estratégicos Escaso cumplimiento de plazos y presupuestos Excesiva dependencia respecto a personas... Necesidad de mejorar la capacidad de producción Necesidad de asociar la mejora con los objetivos de negocio, demostrando la rentabilidad de ésta (RoI). ESI

6 Situación real Sólo el 34% de los proyectos de software tiene éxito. Standish Group, CHAOS Report, 2003 ESI

7 Qué está sucediendo? Problemáticos 51% Éxitosos Problemáticos Fallidos Definiciones Éxitosos 34% Proyectos cancelados Fallidos (Cancelados) 15% En plazo, en presupuesto, con la funcionalidad prometida tarde, pasado el presupuesto, falta funcionalidad 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% 2003 Chaos Report Problemáticos 51% ESI Éxitosos 16% Fallidos (Cancellados) 31% Éxitosos 34% Fallidos (Cancelados) 15% El dinero perdido en gastos del proyecto ha descendido del 32% al 21.5% Los sobrecostes han descendido del 180% al 43% Las Las compañías liberan los los productos a sus sus clientes con con un un 15% 15% de de los los defectos Muchas compañías gastan del del 30% 30% al al 44% 44% de de su sutiempo y dinero en en rehacer el el software que queya yahan hanescrito

9 Mantenimiento Todo lo descrito anteriormente se refiere a las fases de Desarrollo de nuevas soluciones, PERO, Las organizaciones intensivas en software dedican en torno al 40% de sus recursos a tareas de mantenimiento (de todo tipo) de sus aplicaciones, en lugar de desarrollos nuevos que aumenten su negocio. Sources: Capers Jones and Software Engineering Institute ESI

10 Las Factorías de Software La única solución en nuestro sector es la PRODUCCIÓN DE SOFTWARE DE FORMA INDUSTRIAL Los coches y otros bienes también se construían de forma artesanal al principio del siglo XX, pero ya no. Una FACTORÍA es un concepto muy diferente al de un almacén de Artesanos. Supone Organización de la producción (estructura, procesos y medios), especialización, producción en serie, limitar la dependencia de los artesanos concretos que producen un bien, etc. ESI

11 Las Factorías de Software Una Factoría No es otro nombre para lo mismo, sino una organización que proporciona a sus clientes Productos de mayor calidad Plazos más cortos Costes reducidos (incluyendo los de mantenimiento) Por medio de procesos fiables, predecibles y poco dependientes de las personas concretas que los lleven a cabo En resumen, es una organización que consigue mejorar significativamente ( al menos 2 veces?) los resultados de una organización artesanal. ESI

12 Cómo conseguirlo? MÁS RÁPIDO A MENOR COSTE CON MÁS CALIDAD PRODUCIR MEJOR SOFTWARE Qué hacer Modelos Calidad de Procesos Cómo hacerlo Métodos Técnicas Herramientas ESI

13 La Mejora de Procesos ESI

14 Por qué debería la Gerencia preocuparse por el proceso de software? Resulta muy complicado entregar constantemente productos de calidad a nuestros clientes y a la vez obtener beneficios, partiendo de unos procesos de desarrollo pobremente definidos. ESI

15 Premisa básica de la mejora de procesos PROCESO Malo Bueno PRODUCTO Bueno TÍPICO! Esfuerzo heroico No esperable Negocio maduro The quality of a product is largely determined by the quality of the process that is used to develop and maintain it. Basado en los principios de TQM de Shewhart, Juran, Deming y Humphrey. ESI

16 Puntos de apoyo de la calidad Todo el mundo entiende la importancia de tener una plantilla de calidad y motivada, pero Proceso Productos Personas Personas Los mayores condicionantes del coste del producto, plazos y calidad Tecnología Tecnología SATISFACCIÓN N DEL CLIENTE...incluso los mejores empledos no pueden rendir de manera óptima cuando los procesos no se entienden o no operan de manera adecuada. ESI

17 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

18 pero es muy rentable (1) CMM Nivel CMM Nivel Nuevo desarrollo Coste de Calidad CMM Nivel 3 Coste de No-Calidad 1995 CMM Nivel 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

19 pero es muy rentable (2) Performance Category Median Number of Data Points Low High Cost 20% 21 3% 87% Schedule 37% 19 2% 90% Productivity 62% 17 9% 255% Quality 50% 20 7% 132% Customer Satisfaction 14% 6-4% 55% Return on Investment 4.7 : : : 1 Datos publicados el día 15 de diciembre de 2005 por el SEI sobre los resultados obtenidos a través de Procesos de Mejora en un grupo de empresas sobre las que existen datos públicos -- ESI

20 Metric DINTEL, Foro FOCAL, 28 Mayo 2008 pero es muy rentable (3) 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 1.1 % % 1.1 % 1.1 % engineering effort) 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. ESI

21 ESI DINTEL, Foro FOCAL, 28 Mayo 2008 Modelos de Mejora de los Procesos de Software El Ciclo de Vida de una Solución TIC pasa por varias fases: 1. Diseño, desarrollo, pruebas y entrega de la solución TIC 2. Explotación de la solución por sus usuarios, atención a usuarios, soporte, etc 3. Mantenimiento, tanto correctivo como evolutivo, que normalmente se desarrolla en paralelo con la explotación. Las tres fases utilizan Procesos Software, pero los Modelos de Mejora habituales son diferentes para unas u otras. Así: Los modelos CMMI (DEV y ACQ), ISO15504 SPICE e I.T.Mark son aplicables a las fases 1 y 3 Los modelos ITIL (I.T. Infrastructure Library) e ISO y los próximos CMMI-for-Services e I.T.Mark-Services son aplicables a la fase 2 y parcialmente a la 3. Capability Maturity Model and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University

22 Países con Evaluaciones realizadas ESI Fuente: SEI 2007

23 Los niveles de madurez 5 4 Optimización de los procesos Gestión cuantitativa 5. En optimización 4. Gestionado cuantitativamente Estandarización de los procesos, organización más proactiva Gestión básica de proyectos, organización todavía reactiva Proceso impredecible, poco controlado 1. Inicial 3. Definido 2. Gestionado ESI

24 NIVEL En optimización Gestionado cuantitativamente Definido Gestionado Inicial PROPÓSITO Mejora continua del proceso Gestión cuantitativa Estandarización de los procesos Gestión de proyectos básica ÁREAS DE PROCESO Innovación y despliegue organizativo Análisis de causas Rendimiento de los procesos organizativos Gestión cuantitativa de proyectos Desarrollo de requisitos Solución técnica Integración de producto Verificación Validación Enfoque hacia procesos Definición de procesos Formación Gestión integrada de proyectos Gestión de riesgos Toma de decisiones Gestión de requisitos 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 Sin áreas de proceso el trabajo se realiza de alguna manera! Calidad Productividad Riesgo Re-trabajo ESI

25 Beneficios debidos a madurez Fuente: DACS y SEI ESI

26 Estructura del modelo CMMI Nivel de Madurez Área de Proceso Área de Proceso Área de Proceso Obligatorio Metas Genéricas Metas Específicas Esperado Prácticas Genéricas Prácticas Específicas ESI

27 CMMI modelo de mejora El modelo CMMI es una colección estructurada de elementos que describen las características de un proceso efectivo de desarrollo de SW. Los procesos incluidos son aquellos que por experiencia han demostrado ser efectivos Realizado por la industria del Software Modelo mundialmente reconocido por la industria, estándar de facto organizaciones evaluadas CMMI Clase A (y >3.600 CMM pre-2002) CMMI 2 : 34% CMMI 3 : 48% CMMI 4 : 1% CMMI 5 : 9% España 75 en Marzo 2008 (1 año antes eran 31) ESI

28 Three Complementary Constellations CMMI-DEV provides guidance for measuring, monitoring and managing development processes CMMI-SVC CMMI-SVC provides guidance for those providing services within organizations and to external customers CMMI-DEV 16 Core Process Areas, common to all CMMI-ACQ CMMI-ACQ provides guidance to enable informed and decisive acquisition leadership ESI

29 Multi-Model Environments Mapping the Process Improvement Landscape Multiple models: complicate PI environment make PI more powerful Tailor to specific user needs Address various environments Fuente: Paul Nielsen, SEI 2007 ESI

30 Reutilización Sistemática tica ESI

31 Software Factories Software factories are about reusing patterns, frameworks, tools, templates, requirements, tests, instrumentation, process guidance, and many other assets used throughout the software life cycle, in a systematic, rather than ad hoc fashion, not about stamping out endless copies of the same thing Jack Greenfield ESI

32 Por qué Reuse? En el 2010, al menos el 70% de todas las nuevas aplicaciones se realizarán a partir de componentes. Los componentes técnicos enfocados al aspecto tecnológico de las aplicaciones pueden mejorar la productividad del programador en un 40% o más. Gartner Group Reuse reduce el coste, tiempo y esfuerzo mientras se mejora la productividad del proceso, la calidad del producto y el mantenimiento del sistema. Reuse code reduce el 25% de los defectos encontrados en el nuevo código, los componentes reutilizables permiten que el producto final se entregue un 40% más rápido. ESI Meta Group

33 La Reutilización no es nueva La Reutilización informal (ad-hoc) es intuitiva y habitual desde que existe el software. Algunas formas son: cut & paste. Bibliotecas de funciones. Componentes genéricos. Reuse-as-it-is y COTS. People reuse etc ESI

34 Qué tipo de organización? Desarrollos únicos One-of-a-kind Similaridades entre proyectos Familias La mayoría de las organizaciones desarrollan familias de proyectos relacionados ESI

35 Estrategias de Reutilización: Standard adaptable product Domain driven reuse Production centre reuse Project-based reuse Ad-hoc reuse Importancia relativa de la Ingeniería del Dominio vs Ingeniería de Aplicación ESI

36 El Proceso de la Reutilización Dos ciclos de vida con objetivos diferentes, aunque complementarios: Ingeniería del Dominio Establece la organización y arquitectura de las aplicaciones dentro del dominio Desarrolla y mantiene la infraestructura necesaria para desarrollar las aplicaciones dentro del dominio Ingeniería de Aplicación Desarrolla las aplicaciones de forma industrial, de forma relativamente mecánica, de acuerdo con las necesidades de cada cliente. ESI

37 Limitaciones de la Reutilización Informal (ad-hoc) El éxito no es repetible / sistemático Sólo aplicable en grupos pequeños de desarrolladores Muy dependiente de la iniciativa de los individuos Vida limitada de los elementos a reutilizar, ya que no existe un mantenimiento o soporte de los mismos Escaso impacto en la simplificación del mantenimiento de las aplicaciones ESI

38 Reutilización Sistemática Un enfoque Sistemático exige: Prever la producción de un conjunto (familia) de productos o sistemas (multi-system perspective) Dicho conjunto constituye una familia, y se desarrolla a partir de un grupo de elementos comunes, en un dominio concreto (domain scope) Se identifican las partes comunes y las variantes, dentro de la familia de sistemas, para definir la Base de Elementos Reutilizables (domain analysis) Se define cómo desarrollar nuevos miembros de la familia, a partir de la Base (domain process) Mantenimiento ESI

39 Reutilización Sistemática Es posible, y existen experiencias cercanas Ratios de Reutilización del 70% de media en uso comercial sostenido, y por tanto: Plazos acortados un 30% Costos reducidos un 50% Defectos remanentes reducidos >70% Reducciones de costos de mantenimiento muy grandes, pero difíciles de cuantificar ESI Fuente: Manu Prego, Reuse Based Software factory, ESERNET Method Book v3.0, Lecture Notes in Computer Science, Springer-Verlag 2003 pp , ISBN

40 Factoría de software Descripción general UNA ORGANIZACIÓN BASADA EN LA INGENIERÍA. 1. Estructura organizativa Separar producción de los medios de producción. Creación de una Oficina Técnica. 2. Organización de trabajo Normalización y estandarización. Construcción por componentes. Reutilización masiva a nivel global. 3. Herramientas ESI

41 Factoría de software 1.- Organización Objetivo Separar los medios de producción de la propia producción de software. Estrategia Creación y desarrollo de una organización específica: Oficina Técnica. Sus funciones: Define las líneas de producto. Crea, desarrolla y gestiona componentes estándar. Controla los índices de producción: Reutilización. Productividad. Rendimientos. ESI

42 Factoría de software 2.- Normalización-Estandarización-Técnicas Paradigma La normalización y estandarización como principios, las técnicas y la organización como instrumentos, la productividad y calidad como resultados. Objetivos Alcanzar altas cotas de reutilización de código. Independizar el código de sus autores. Incrementar la productividad y calidad en la construcción del software. Estrategias Romper los dilemas de la construcción basada en componentes. Análisis y clasificación del código. ESI

43 Qué beneficios voy a obtener? A corto? Homogeneización de los programas construidos. Estandarización y normalización del código. Independencia de los autores. Mayor calidad en los programas. Alto porcentaje del código técnicamente más complejo, ya probado. Software del nivel de expertos. Control total del proceso de fabricación. Reducción del tiempo de desarrollo. En la fabricación. En las pruebas. ESI

44 Qué beneficios voy a obtener? A medio/largo? Reducción del esfuerzo en mantenimiento. Por menos errores. Por rapidez en la realización. Por conocimiento de la estructura del código. Por la estandarización y normalización del código. Mayor fiabilidad del mantenimiento. Por el conocimiento con que se ejecuta. ESI

45 Conclusiones ESI

46 Aquello que parece sencillo esconde tras sí un gran esfuerzo: lo espontáneo siempre es el desorden Carlos Casares La 2ª ley de la Termodinámica: La entropía del universo siempre crece El desorden aumenta espontáneamente ESI

47 Motivación El Sector TIC ha sido el motor del crecimiento del mundo occidental estos últimos años Tiene un historial pobre en cuanto a calidad, plazos, etc Nuevos países y regiones vienen pisando fuerte Para poder compatir, el sector necesita mejorar significativamente: Duplicar (o más) su eficiencia a medio plazo??? Se puede hacer! ESI

48 Las premisas a considerar La mejora de procesos debería llevarse a cabo para mejorar el negocio, y no como un objetivo en sí mismo Mejorar tiene diferentes connotaciones para cada organización cuáles son sus objetivos de negocio? cómo mide su consecución? La mejora es un esfuerzo estratégico a largo plazo cuál es el impacto esperado en la organización In God we trust, all others bring data. -W. Edwards Deming ESI

49 Beneficios esperados Los beneficios de la mejora deben afectar a todas las categorías: tener calendarios y presupuestos más predecibles mejorar tiempos de desarrollo mejorar la productividad mejorar la calidad (medida en número de defectos) mejorar la satisfacción del cliente mejorar la moral de los empleados reducir el coste de la calidad aumentar el retorno de la inversión ESI

50 Cómo conseguirlo? MÁS RÁPIDO A MENOR COSTE CON MÁS CALIDAD PRODUCIR MEJOR SOFTWARE Qué hacer Modelos Calidad de Procesos Cómo hacerlo Métodos Técnicas Herramientas ESI

51 Tener calendarios y presupuestos más Porcentaje de desviación 140% 0 % -140% Resultados: Estimación de esfuerzos en Boeing Sin datos históricos predecibles Con datos históricos Varianza: + 20% a - 145% Varianza: - 20% a + 20% (Niveles 1 & 2) (Nivel 3) (Basado en 120 proyectos de Boeing Information Systems) Referencia: John D. Vu. Software Process Improvement Journey:From Level 1 to Level 5. 7th SEPG Conference, San Jose, March ESI

52 Mejorar tiempos de desarrollo Project Cycle Times Número medio Días de trabajo Def. Req. Implant. Año Fuente: Software Engineering Div., Hill AFB, Published in Crosstalk May 1999 ESI

53 Mejorar la productividad y la calidad INDICADORES DE CALIDAD Y PRODUCTIVIDAD TASA DE ERRORES TASA DE PRODUCTIVIDAD PRODUCTIVIDAD (SLOC/DIA-PERSONA) TASA DE ERRORES (DEFECTOS/KSLOC) L2 L3 L4 ReferencIa: Presented at SEPG ESI

54 Mejora de los Procesos Software (SPI) dirigidos por las necesidades de negocio compromiso de la dirección requiere una inversión de tiempo esfuerzo de equipo medición cuantitativa modelo de referencia actividad continua ESI

55 El objetivo es ser más competitivo La cuestión es cómo? En términos sencillos 3 aspectos clave para el éxito son: Entender las expectativas de los clientes y el mercado Posicionamiento correcto ante los competidores Conocer y mejorar la propia capacidad ESI

56 Puede ayudarle la mejora de procesos como a otras organizaciones? Es su decisión! ESI

57 No hay mayor signo de demencia que hacer lo mismo una y otra vez y esperar resultados diferentes. Alfred Einstein ESI Parque Tecnológico Zamudio (Bilbao) T: F: Corazón de María 6, 7º Madrid T: F: