factorías de software - fundación dinteldintel.org/web/eventos/foros/focal/2008/ses1/emaldi.pdf–...

© ESI 2008 1

DINTEL, Foro FOCAL, 28 Mayo 2008

Factorías de Software

© ESI 2008 2


Agenda

• Problemática de la Industria del Software

• Mejora de procesos

• Reutilización Sistemática

• Conclusiones

© ESI 2008 3


Software is everywhere

Fuente: Paul Nielsen, SEI 2007

© ESI 2008 4


Ejemplo del Crecimiento del Software

1990: 1 millón de líneas de código

2010: 100 millones de líneas de códigoWindows 2000: 35 M LOC

Windows XP: 40 M LOCDebian 3.1: 230 M LOCITEA: el volumen de embedded

software se duplica cada 2 años


© ESI 2008 5


la Industria informática hoy encuentra– Excesivos defectos en sus productos– Excesivos recursos gastados en mantenimiento, en

lugar de centrarlos en el desarrollo de nuevosproductos y sistemas estratégicos

– Escaso cumplimiento de plazos y presupuestos– Excesiva dependencia respecto a personas

– ... Necesidad de mejorar la capacidadde producción

– Necesidad de asociar la mejora con los objetivos de negocio, demostrando la rentabilidad de ésta (RoI).

Problemas hoyProblemas hoy

© ESI 2008 6


Situación real …Situación real …

“Sólo el 34% de los proyectos de software

tiene éxito.”Standish Group, CHAOS Report, 2003

© ESI 2008 7


¿Qué está sucediendo?Éxitosos

34%

Fallidos(Cancelados)

15%

Problemáticos51%

Proyectos canceladosFallidos

tarde, pasado el presupuesto, falta funcionalidadProblemáticos

En plazo, en presupuesto, con la funcionalidad prometidaÉxitosos

Definiciones

De una inversión en proyectos de $255 billones, se desperdician $55 billonesDe cada 100 proyectos, 94 se reinicianAl 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 - 2003

© ESI 2008 8


Estamos mejorando, pero…Éxitosos 16%

Fallidos(Cancellados)

31%

Problemáticos53%

Éxitosos 34%

Fallidos(Cancelados)

15%

Problemáticos51%

1994 Chaos Report

2003 Chaos Report

El dinero perdido en gastos del proyecto ha descendido del 32% al 21.5%Los sobrecostes handescendido del 180% al 43%

Las compañías liberan los productos a sus clientes con un 15% de los defectosMuchas compañías gastan del 30% al 44% de su tiempo y dinero en rehacer el software que ya han escrito

Las compañías liberan los productos a sus clientes con un 15% de los defectosMuchas compañías gastan del 30% al 44% de su tiempo y dinero en rehacer el software que ya han escrito

© ESI 2008 9


MantenimientoMantenimiento

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


Las Factorías de SoftwareLas 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 2008 11


Las Factorías de SoftwareLas Factorías de SoftwareUna 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 pocodependientes de las personas concretas que los lleven a cabo

• En resumen, es una organización que consigue mejorarsignificativamente (¿ al menos 2 veces ?) los resultados de una organización “artesanal”.

© ESI 2008 12


¿Cómo conseguirlo?¿Cómo conseguirlo?

Qué hacer

ModelosModelos Calidad Calidad de de ProcesosProcesos

MMéétodostodosTTéécnicascnicasHerramientasHerramientas

Cómo hacerlo

CON MÁS CALIDAD

A MENOR COSTEA MENOR COSTEMÁS RÁPIDOMÁS RÁPIDO

PRODUCIR MEJOR SOFTWARE

© ESI 2008 13


La Mejora de Procesos

© ESI 2008 14


¿Por qué debería la Gerencia preocuparsepor el proceso de software ?

Resulta muy complicadoentregar constantementeconstantemente

productosproductos de calidad a nuestros clientes y a la vez

obtener beneficios, partiendo de unos

procesosprocesos de desarrollopobremente definidos.

© ESI 2008 15


Premisa básica de la mejora de procesos

PROCESOMalo Bueno

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

Esfuerzoheroico

PR

OD

UC

TO

¡TÍPICO! No esperable

Negociomaduro

Bueno

© ESI 2008 16


SATISFACCISATISFACCIÓÓN DEL N DEL CLIENTECLIENTE

ProductosProductos

PersonasPersonas

TecnologíaTecnologíaProcesoProceso

Todo el mundoentiende la importancia de teneruna plantilla de calidad y motivada, pero…

...incluso los mejores empledos no pueden rendir de manera óptima cuandolos procesos no se entienden o no operande manera adecuada.

Los mayorescondicionantes del coste del producto,

plazos y calidad

Puntos de apoyo de la calidadPuntos de apoyo de la calidad

© ESI 2008 17


La Calidad tiene coste…

PrevenciónCostes asociadoscon la prevenciónde defectosPlanificaciónDocumentaciónEntrenamientoHerramientaPolíticas y procedimientosProyectos de mejora de la calidadToma y análisis de datosAnálisis de fallos y de causas

EvaluaciónCostes asociadoscon la “búsqueda”de defectosRevisiones• Requisitos• Diseño• Planes de pruebas• Casos de pruebasRevisiones e inspecciones de códigoTesting (Primera vez)AuditoríasEvaluaciones de Certificación• Clase A, B, C

Fallos internosCostes asociadoscon defectosdetectados antes de la entrega/ instalación de un productoRehacer• Requisitos• Diseño• Codificación• DocumentatiónRe-testingMenor eficiencia(trabajo repetido, desviaciones de plazos, presupuestos, etc.)

Fallos externosCostes asociadoscon defectosdetectados tras la entrega/instalaciónde un productoGarantíasGestión de quejasProyectos perdidosSoporte técnicoNuevas releases, parches, “Services Packs” (terminologíaMS)

© ESI 2008 18


… pero es muy rentable (1)

5821

21

67

23

10

77

176

39

20

41

1988 - CMM Nivel 1 1990 – CMM Nivel 2

1992 - CMM Nivel 3 1995 – CMM Nivel 4

Nuevo desarrolloCoste de CalidadCoste 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 2008 19



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 16 2 : 1 27.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 -- http://www.sei.cmu.edu/cmmi/results.html

http://www.sei.cmu.edu/cmmi/results.html

© ESI 2008 20



Datos publicados referidos a 2007.

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. https://www.thedacs.com/databases/roi/

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% - 32.6 %

Reduction in Rework -60% 1 -60% -60% -60%

Impact on Quality (% defect reduction) - 48.5 % 20 -0,5% 95% -47,6%

Impact on Productivity (Improvement) +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.1 % 1.1 %

© ESI 2008 21


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 TIC2. Explotación de la solución por sus usuarios, atención a usuarios,

soporte, etc3. 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 20000 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

© ESI 2008 22


Países con Evaluaciones realizadas

Fuente: SEI 2007

© ESI 2008 23


Los niveles de madurez

Proceso impredecible, poco controlado

Gestión básica de proyectos, organización todavía reactiva

Estandarización de los procesos, organización más proactiva

Gestión cuantitativa

Optimización de los procesos 5. En optimización

4. Gestionado cuantitativamente

3. Definido

1. Inicial

2. Gestionado

1

2

3

4

5

© ESI 2008 24


Re-trabajo

Riesgo

Productividad

Calidad

Inicial

Gestionado

Definido

Gestionado cuantitativamente

En optimización

Sin áreas de proceso – ¡el trabajo se realiza de alguna manera!1

Gestión de requisitos Planificación de proyectoSeguimiento y control de proyectoGestión de acuerdos con proveedoresMedición y análisisAseguramiento de la calidadGestión de la configuración

Gestión de proyectos básica2

Desarrollo de requisitos Solución técnicaIntegración de productoVerificaciónValidaciónEnfoque hacia procesosDefinición de procesosFormaciónGestión integrada de proyectos Gestión de riesgosToma de decisiones

Estandarización de los procesos3

Rendimiento de los procesos organizativosGestión cuantitativa de proyectosGestión cuantitativa4

Innovación y despliegue organizativoAnálisis de causas

Mejora continua del proceso5

ÁREAS DE PROCESOPROPÓSITONIVEL

© ESI 2008 25


Beneficios debidos a madurez

Fuente: DACS y SEI

© ESI 2008 26


Estructura del modelo CMMINivel de Madurez

Esperado

Obligatorio

Área de Proceso Área de Proceso Área de Proceso

Metas Genéricas

MetasEspecíficas

PrácticasGenéricas

PrácticasEspecíficas

© ESI 2008 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”.– 3.113 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 2008 28


Three Complementary “Constellations”CMMI-SVC provides guidance for those providing services within organizations and to external customers

CMMI-DEV provides guidance for measuring, monitoring and managing development processes

CMMI-SVC

16 Core Process Areas, common to all CMMI-ACQ provides

guidance to enableinformed and decisiveacquisition leadership CMMI-ACQCMMI-DEV

© ESI 2008 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


© ESI 2008 30


ReutilizaciReutilizacióónnSistemSistemááticatica

© ESI 2008 31


Software FactoriesSoftware 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 2008 32


¿ Por qué Reuse ?¿ 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 nuevocódigo, los componentes reutilizables permiten que el producto final se entregue un 40% más rápido.

Meta Group

© ESI 2008 33


La Reutilización no es nuevaLa Reutilización no es nuevaLa 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 2008 34


¿ Qué tipo de organización ?¿ Qué tipo de organización ?

Desarrollos únicos Similaridades entre proyectosOne-of-a-kind Familias

La mayoría de las organizaciones desarrollan familiasde proyectos relacionados

© ESI 2008 35


EstrategiasEstrategias de de ReutilizaciReutilizacióónn::

Standard adaptable product

Ad-hoc reuse

Project-based reuse Importancia relativa de la Ingeniería del Dominio vs

Ingeniería de Aplicación

Domain driven reuse

Production centre reuse

© ESI 2008 36


El Proceso de la ReutilizaciónDos 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 necesariapara 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 2008 37


Limitaciones de la ReutilizaciónInformal (ad-hoc)

Limitaciones de la ReutilizaciónInformal (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 2008 38


Reutilización SistemáticaUn 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, dentrode 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 2008 39


Reutilización SistemáticaReutilización SistemáticaEs 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

Fuente: Manu Prego, “Reuse Based Software factory”, ESERNET MethodBook v3.0, Lecture Notes in Computer Science, Springer-Verlag 2003 pp256-273, ISBN 0302-9743

© ESI 2008 40


Factoría de softwareDescripció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 2008 41


Factoría de software1.- 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 2008 42


Factoría de software2.- 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 2008 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 2008 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 2008 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 creceEl desorden aumenta espontáneamente

© ESI 2008 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 vienenpisando fuerte

• Para poder compatir, el sector necesita mejorar significativamente:

Duplicar (o más) su eficiencia a medio plazo ???

¡ Se puede hacer !

© ESI 2008 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 paracada 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 2008 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 2008 50


¿Cómo conseguirlo?¿Cómo conseguirlo?

Qué hacer

ModelosModelos Calidad Calidad de de ProcesosProcesos

MMéétodostodosTTéécnicascnicasHerramientasHerramientas

Cómo hacerlo

CON MÁS CALIDAD

A MENOR COSTEA MENOR COSTEMÁS RÁPIDOMÁS RÁPIDO

PRODUCIR MEJOR SOFTWARE

© ESI 2008 51


Resultados: Estimación de esfuerzosen Boeing

.

0 %

140%

-140%

....

.

..

. ... .

.

. .. . . .

.. . .

. .

.

.. . . .. .. . . . . .... . . .. .

.. .

. ...

..

. .. .. ...... . .. . ... . .. . .. ..

Sin datos históricos Con datos históricosVarianza: + 20% a - 145% Varianza: - 20% a + 20%

(Niveles 1 & 2) (Nivel 3)

Porc

enta

jede

des

viac

ión

.

(Basado en 120 proyectos de Boeing Information Systems)

.. . .

.

.. .

...

. .. .

..

. .

..

.. .. .. . . . . . .. . . . . .. .

... . .. . . . . . .. . . .. . . . .

. . . . .. . . . .. . . . . .. . . . .. . . . . .

. . . . . .. . . . .. . .

. . . . . . . .

. . . . . . . . .

. . . . . .. . . . . .

. . . . . .

Tener calendarios y presupuestos máspredecibles

Referencia: John D. Vu. “Software Process Improvement Journey:From Level 1 to Level 5.”7th SEPG Conference, San Jose, March 1997.

© ESI 2008 52


Mejorar tiempos de desarrollo

Project Cycle Times

0250500750

Año

Núm

ero

med

ioD

ías

de tr

abaj

o

Def. Req.Implant.

‘91 ‘94 ‘95 ‘96‘92 ‘93

Fuente: Software Engineering Div., Hill AFB, Published in Crosstalk May 1999

© ESI 2008 53


Mejorar la productividad y la calidadINDICADORES DE CALIDAD Y PRODUCTIVIDAD

1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999

TASA DEPRODUCTIVIDAD

TASA DEERRORES

L2 L3 L4

PRODUCTIVIDAD(SLOC/DIA-PERSONA)

TASA DE ERRORES(DEFECTOS/KSLOC)

ReferencIa: Presented at SEPG 99

© ESI 2008 54


Mejora de los Procesos Software (SPI)

compromiso de la dirección

dirigidos por las necesidades de negocio

requiere unainversión de tiempo

esfuerzo de equipo

medicióncuantitativa actividad continua

modelo de referencia

© ESI 2008 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 propiacapacidad

© ESI 2008 57


Parque Tecnológico 20448170 Zamudio (Bilbao)T: + 34 94 420 95 19F: + 34 94 420 94 20www.esi.es

Corazón de María 6, 7º - 528002 MadridT: + 34 91 519 78 18F: + 34 91 515 02 05www.esiconsulting.es

No hay mayor signo de demencia que hacer lo mismo una y otra vez y esperar resultados diferentes.

Alfred Einstein

factorías de software - fundación dinteldintel.org/web/eventos/foros/focal/2008/ses1/emaldi.pdf–...

Documents