Enginyeria del Software III

LOrientaci a processos en el desenvolupament de software. Avaluaci i millora daquests processos.

10 Octubre 2007

Antnia Mas Pichaco

1

Continguts
Tema 1
Introducci als continguts de la matria. Evoluci histrica El treball per processos en el desenvolupament de software: ISO/IEC 12207 Models davaluaci i millora de processos de software

Tema 2
El model CMM El model CMMi

Tema 3
Lestndard ISO/IEC 15504 El procs davaluaci segons la norma ISO/IEC 15504. Estat actual
2

Continguts
Tema 4
Les normes de la famlia ISO relacionades amb processos de software El procs de certificaci segons la ISO 9001:2000

Tema 5
La millora dels processos de software a les petites i mitjanes empreses (pimes) El projecte QuaSAR: aplicaci dels resultats a les empreses Projectes i iniciatives actuals. El Plan Avanza. Convocatries pbliques de subvencions

Tema 6
Treball en equip

Conferencies

Enginyeria del Software III

Tema 1. El treball per processos en el
desenvolupament de software
10 Octubre 2007

Antnia Mas Pichaco

4

Continguts
Introduccin a los contenidos de la materia Introducci Situacin en el campo de estudio: La Ingeniera del software Evolucin histrica El trabajo por procesos en el desarrollo de software
El ciclo de vida del software Los procesos del ciclo de vida del software. ISO/IEC 12207

Modelos de evaluacin i mejora de procesos de software

5

Situacin
Hace ms de cuatro dcadas que existe la disciplina de la Ingeniera del Software como tal, pero an no hemos sido capaces de convertirla en una verdadera disciplina de ingeniera La reciente orientacin a procesos del desarrollo de software representa un paso en la direccin correcta Las expectativas surgidas a partir de la evolucin tecnolgica y del nacimiento de las herramientas CASE no han aportado todos los beneficios esperados La experimentacin de tales herramientas en la industria ha permitido probar que las principales razones del fracaso de los proyectos software:
Tiene poco que ver con la tecnologa y con las herramientas utilizadas en el desarrollo y Mucho con los procesos y los equipos humanos que los llevan a cabo.

La industria del software ha ido progresando a travs de tres etapas con unas tendencias muy marcadas en cada una de ellas
6

1970 - 1986

Evolucin Histrica. Primera etapa Transformacin del desarrollo de software hacia una disciplina de ingeniera:
1970. Mtodos estructurados y el ciclo de vida en cascada
Nacieron como respuesta al gran crecimiento de la demanda y de la complejidad del software y, en consecuencia, del incremento del tamao de los equipos de desarrollo.

1980. Avance principal:

Representacin de las actividades relacionadas con el desarrollo de software en forma de diagramas.
7

1989 - 2000

Evolucin Histrica. Segunda etapa

La segunda etapa se distingue por el movimiento de madurez de los procesos. La orientacin a procesos en el desarrollo de software se inici debido a una iniciativa del Departamento de Defensa de los EEUU que fund el SEI (Software Engineering Institute) en la CMU (Carnegie Mellon University) para desarrollar un mtodo de evaluacin de la capacidad de sus proveedores de software, que ms tarde dara lugar al conocido CMM. Watts Humphrey fue nombrado director del programa y fue el primero que incorpor al desarrollo de software los principios de calidad ideados por Edwards Deming y Philip Crosby para las industrias de produccin de todo tipo y a lo largo de todo el mundo. El principio bsico establecido por Humphrey es la orientacin a procesos, vista como la necesidad de contemplar todas las tareas relacionadas con el desarrollo de software, como un proceso que puede ser controlado, medido y mejorado. La gestin de los procesos del software proporciona una visin mucho ms amplia que las simples etapas o fases de anlisis, diseo o codificacin, ya que cubre tanto los aspectos de gestin como las actividades de soporte. 8

2000 Actualidad

Evolucin Histrica. Tercera etapa

Factoras de software
La industrializacin del software, que incluye:
Tecnologas orientadas a objetos Libreras de componentes reutilizables y Un conjunto de procesos disciplinados de Ingeniera del Software

representa un paso ms hacia la produccin masiva de software de calidad

Consolidacin de la orientacin a procesos en el desarrollo de software

Se ha extendido a lo largo de todo el mundo a travs de las SPINs (Software Process Improvement Networks), lideradas por
El SEI y por ISO (International Organization for Standardization)
9

Continguts
Introduccin a los contenidos de la materia Introducci Situacin en el campo de estudio: La Ingeniera Ingenier Situaci del software Evolucin histrica Evoluci hist El trabajo por procesos en el desarrollo de software
El ciclo de vida del software Los procesos del ciclo de vida del software. ISO/IEC 12207

Modelos de evaluacin i mejora de procesos de software

10

El trabajo por procesos en el desarrollo de software Proceso de software: Definici de procs de software Un proceso de software define el enfoque que se toma cuando el software es tratado por la ingeniera
Pressman
Salida

Procesos del Ciclo de vida de software: Las organizaciones internacionales han publicado diversas normas referentes a los procesos del ciclo de vida del software. Todas ellas consideran Un proceso como un conjunto de actividades, una actividad como un conjunto de tareas, y una tarea como una accin que transforma las entradas en salidas.
11

Entrada

Proceso

Los procesos del ciclo de vida del software

Estndares de procesos del ciclo de vida del software Estndares de procesos del ciclo de vida del software

IEEE Std. 1074-1997

IEEE Standard for Developing Software Life Cycle Processes Computer Society/Software & Systems Engineering Standards Committee. December 1998

ISO/IEC 12207/Amd2:2004
International Standard - Information Technology - Software Life Cycle Processes
Computer Society/Software & Systems Engineering Standards Committee

Establecen un marco comn para los procesos del ciclo de Establecen marco comn para los procesos del ciclo de vida del software, con una terminologa bien definida para vida del software, con una terminologa bien definida para que pueda ser utilizada por la industria del software. que pueda ser utilizada por la industria del software. Contienen las actividades y las tareas que se aplican durante Contienen las actividades durante la adquisicin, desarrollo, operacin y mantenimiento de un la adquisicin, desarrollo, operacin y mantenimiento de un sistema que contiene software o de un producto/servicio de sistema que contiene software o de un producto/servicio de software. software.
12

Los procesos del ciclo de vida del software ISO/IEC 12207/Amd2:2004

Procesos de la organizacin
Gestin Calidad
Infraestructura

Mejora
Ingeniera Dominio

Las actividades que se pueden realizar durante el ciclo de vida del software se agrupan en:
5 procesos principales

Recursos Humanos

Gestin Activos

Gest. Progr. Reutilizacin

Compras

Procesos primarios
Desarrollo

Suministro

Operacin

Mantenimiento

Documentacin

Procesos de soporte
Validacin Revisin conjunta Auditora

Resolucin problemas Usabilidad Evaluacin producto Gest. Pet. cambio 13

11 procesos de soporte 7 procesos de la organizacin

GCS
Aseguramiento Calidad

Verificacin

Los procesos del ciclo de vida del software ISO/IEC 12207/Amd2:2004

14

Los procesos del ciclo de vida del software ISO/IEC 12207/Amd2:2004 Procesos de Soporte: Aseguramiento de la calidad

Asegura que los productos de trabajo y los procesos cumplen las previsiones y planes predefinidos:
Se desarrolla una estrategia para llevar a cabo el aseguramiento de la calidad. Se produce y mantiene evidencia del aseguramiento de la calidad. Se identifican y registran los problemas y/o no conformidades con los requisitos acordados. Se verifica el cumplimiento por parte de los productos, procesos y actividades de los estndares, procedimientos y requisitos aplicables.
15

Los procesos del ciclo de vida del software ISO/IEC 12207/Amd2:2004 Procesos de Soporte: Aseguramiento de la calidad

Plan para el aseguramiento de la calidad

Identificar estndares, metodologas, procedimientos y herramientas para llevar a cabo las actividades de aseguramiento de la calidad y su adaptacin al proyecto. Identificar los recursos y las responsabilidades para la realizacin de las actividades de aseguramiento de la calidad. Establecer y garantizar la independencia de los responsables de llevar a cabo las actividades de aseguramiento de la calidad. Realizar las actividades identificadas de aseguramiento de la calidad en consonancia con los planes y procedimientos relevantes. Aplicar los sistemas de gestin de calidad organizacionales al proyecto. 16

Los procesos del ciclo de vida del software ISO/IEC 12207/Amd2:2004 Procesos de la Organizacin: Gestin de calidad Conseguir la satisfaccin de los clientes, monitorizando la calidad de los productos y servicios, a nivel organizacional y de proyecto, con el fin de asegurar que estos satisfacen los requisitos de los clientes.
Se establecen objetivos de calidad basados en requisitos de calidad implcitos y explcitos definidos por el cliente. Se desarrolla una estrategia global para conseguir los objetivos definidos. Se establece un sistema de gestin de calidad para implementar dicha estrategia. Se realiza, y se confirma el desempeo, de las actividades de control y aseguramiento de la calidad identificadas. Se monitoriza el desempeo real respecto a los objetivos de calidad. Se toman las acciones oportunas cuando no se logran los objetivos de calidad. 17

Los procesos del ciclo de vida del software ISO/IEC 12207/Amd2:2004 Procesos de la Organizacin: Proceso de Mejora Mejorar de forma continua la efectividad y eficiencia de los procesos utilizados y mantenidos de forma alineada con las necesidades de negocio. Las fuentes de informacin que pueden proporcionar las entradas para el cambio son:
Resultados de valoracin de los procesos Auditoras Informes de satisfaccin del cliente Eficiencia/efectividad organizacional

El estado actual de los procesos podra determinarse mediante el proceso de valoracin. Se compone de tres subprocesos:
Establecimiento de procesos Valoracin de procesos y Mejora de procesos
18

Continguts. Sessi 1 (18 abril)

Introduccin a los contenidos de la materia Introducci Situacin en el campo de estudio: La Ingeniera Ingenier Situaci del software Evolucin histrica Evoluci hist El trabajo por procesos en el desarrollo de software
El ciclo de vida del software Los procesos del ciclo de vida del software. ISO/IEC 12207

Modelos de evaluacin i mejora de procesos de software

19

Modelos de evaluacin y mejora de los procesos de software

Si una empresa quiere iniciar un plan de mejora de sus procesos de desarrollo de software Si una empresa quiere iniciar un plan de mejora de sus procesos de desarrollo de software

1 1

En primer lugar, debe conocer que procesos realiza: Dnde est?

Si no conoce donde est, desconoce el punto de partida!

2 2 3 3

En segundo lugar, debe conocer que procesos desea realizar: Dnde quiere llegar? y Cmo debe hacerlo?
Si no sabe donde ir, desconoce el camino que debe tomar!

En tercer lugar, debe conocer que procesos puede mejorar: Ha llegado?

Si no comprueba nuevamente donde est ahora, no sabr si ha llegado donde quera ni si puede mejorar la ruta! 20

10

Modelos de evaluacin y mejora de los procesos de software

La calidad del software es una disciplina dentro del campo La calidad del software es una disciplina dentro del campo de la Ingeniera del software de la Ingeniera del software

El marco de la calidad del software abarca dos aspectos bien diferenciados:

Calidad del proceso de software. Modelos de evaluacin y mejora de procesos Calidad del producto software

Existe un acuerdo generalizado en que cuanto mejor sea el proceso:

Mejor es la calidad del producto Ms exactos son los planes Ms puntuales son las entregas Ms barato es el coste
21

Modelos de evaluacin y mejora de los procesos de software Los modelos de evaluacin y mejora de procesos de software permiten:
Calcular la capacidad o madurez de todos los procesos que intervienen en el ciclo de vida del software. Detectar los puntos fuertes y los dbiles de cada uno, y Proponer un conjunto de actividades o tareas orientadas a guiar a la organizacin hacia una mejora gradual y continuada de cada uno de estos procesos.

Un modelo proporciona:
Un punto de partida para la homogeneizacin de los procesos Una terminologa y un marco de actuacin comunes. Un campo de conocimiento derivado de su uso en toda una comunidad. Una gua para priorizar las acciones de mejora surgidas a partir de una evaluacin.

22

11

Modelos de evaluacin y mejora de los procesos de software A pesar de que los ingenieros de software conocen con detalle los factores y los problemas que afectan a su trabajo, no siempre estn de acuerdo en cules son las actividades ms importantes que deberan realizarse. Para que los esfuerzos destinados a la mejora de los procesos sean visibles, es necesario disponer de un plan que pueda conducir a la madurez de la organizacin de manera escalonada. Las iniciativas que han ido surgiendo en todo el mundo para la investigacin en esta rea de mejora de procesos han propiciado el desarrollo de diversos modelos que proponen:
Diferentes mtodos de evaluacin de la capacidad de los procesos. Diferentes maneras de representar las actividades necesarias para la mejora. Diferentes maneras de guiar a la organizacin hacia la 23 madurez.

Resumen histrico de los modelos surgidos

Modelos de evaluacin y mejora de los procesos de software

24

12

Resumen histrico de los modelos surgidos

Modelos de evaluacin y mejora de los procesos de software

25

Resumen histrico de los modelos surgidos

Modelos de evaluacin y mejora de los procesos de software

26

13

Modelos de evaluacin y mejora de los procesos de software

ISO 9001 ISO 90003

Tr ill iu m
E YM OP ES
Tic k

IT

Software Process Matrix

SPM

The IDEALSM Model

Pro ce

ss

us

Y ms

...
27

Modelos de evaluacin y mejora de los procesos de software

La evaluacin de los procesos consiste en una revisin exhaustiva, planificada y detallada de los procesos de la organizacin (de los que se hayan seleccionado). Un modelo de evaluacin requiere:
Una escala de medida. Habitualmente se denomina Niveles de capacidad o de madurez. Un conjunto de criterios de evaluacin, frente a los cuales se apoya el modelo de madurez. Un conjunto de estndares que agrupe las mejores prcticas (procesos) realizados en la industria. Un mecanismo claro para presentar los resultados.
28

14

Modelos de evaluacin y mejora de los procesos de software

Los principales objetivos de la evaluacin de procesos son:

La informacin en s misma, que permite mostrar a la empresa la posicin en qu se encuentra cada uno de sus procesos, sus puntos fuertes y sus puntos dbiles. La mejora de los procesos. Le permite trazar un conjunto de acciones de mejora priorizadas. Cumplir los requisitos de un contrato. Cuando un proveedor impone unos determinados requisitos.
29

Modelos de evaluacin y mejora de los procesos de software Orgenes de la evaluacin de procesos Ciclo de Shewhart PDCA

Planifica Planifica

Actua Actua

Realiza Realiza

Chequea Chequea
30

15

Los estados de madurez de los procesos

Modelos de evaluacin y mejora de los procesos de software Phillip Crosby. 1970. La calidad es gratis!

Certidumbre

Deseo

Iluminacin

Despertar Incertidumbre
31

La madurez de los procesos

Modelos de evaluacin y mejora de los procesos de software Proceso inmaduro

Proceso improvisado por los Proceso improvisado por los profesionales que lo utilizan. No es de profesionales que lo utilizan. No es de uso obligado ni seguido por la direccin. uso obligado ni seguido por la direccin. Es dependiente de los profesionales Es dependiente de los profesionales actuales. actuales. Sin una estrategia de mejora es difcil Sin una estrategia de mejora es difcil alcanzar un consenso sobre las alcanzar un consenso sobre las actividades prioritarias para mejorar el actividades prioritarias para mejorar el proceso. proceso. El estado de la calidad de los productos El estado de la calidad de los productos y de los procesos est oculto. Se y de los procesos est oculto. Se desconoce el porqu de los problemas desconoce el porqu de los problemas con la calidad. con la calidad. Cuando ocurre un problema, se Cuando ocurre un problema, se reacciona y se intenta solucionar. reacciona y se intenta solucionar. No hay actividades organizadas de No hay actividades organizadas de mejora. mejora.

Vs

Proceso maduro
Proceso definido y documentado. Es Proceso definido y documentado. Es comprendido y utilizado de manera comprendido y utilizado de manera habitual. Respaldado por la direccin. habitual. Respaldado por la direccin. Es independiente de los profesionales. Es independiente de los profesionales. Est estandarizado. Est estandarizado. El conjunto de prcticas a seguir para la El conjunto de prcticas a seguir para la mejora del proceso estn bien definidas. mejora del proceso estn bien definidas.

La calidad en todos los mbitos es la La calidad en todos los mbitos es la cuestin principal. Se conoce el por qu cuestin principal. Se conoce el por qu de la no existencia de problemas de la no existencia de problemas relacionados con la calidad. relacionados con la calidad.
Se previenen los problemas y se establece un Se previenen los problemas y se establece un plan de accin. plan de accin. Las acciones de mejora son actividades Las acciones de mejora son actividades normales y realizadas de forma establecida. normales y realizadas de forma establecida. 32

16

Modelos de evaluacin y mejora de los procesos de software

Necesidad de desarrollar un estndar debido a:
El nmero creciente de mtodos de evaluacin que han ido surgiendo. La extensin de la orientacin a procesos en diferentes reas.

1993

Acontecimientos principales 1995

El SEI emite el SW-CMM V1.1 Se lanza el proyecto SPICE

Acontecimientos principales
Se emite el primer borrador del estndar ISO/IEC 15504 ISO publica la primera versin del estndar ISO/IEC 12207 El SEI publica el modelo IDEAL

1998 2002 2004

Acontecimientos principales
Primera versin del Informe Tcnico ISO/IEC TR-15504

Acontecimientos principales
El SEI emite el SW-CMMi V1.1

Acontecimientos principales
Primera publicacin de las partes 1, 2, 3 y 4 del estndar internacional ISO/IEC 15504. 33 Publicacin del estndar ISO/IEC 90003

Modelos de evaluacin y mejora de los procesos de software

En las siguientes diapositivas se efecta una revisin del estado del arte sobre los modelos de evaluacin y mejora de procesos de software, sin llegar a describir de manera detallada ninguno de ellos

34

17

El proyecto SPICE

ISO/IEC 15504:2004 (SPICE)

El proyecto SPICE representa el mayor marco de colaboracin internacional establecido con la finalidad de desarrollar un estndar de evaluacin de procesos de software. Se inici en el ao 1993 con tres objetivos clave:
Desarrollar un marco de trabajo comn para la evaluacin y mejora de procesos de software. Aplicar el estndar desarrollado en la industria del software. Promover la transferencia de conocimiento y de tecnologa sobre procesos de software entre todas las empresas.

ISO/IEC 15504 es un estndar internacional que es aplicable a cualquier organizacin/empresa que quiera conocer y mejorar la capacidad de sus procesos, independientemente del tipo de organizacin, del modelo del ciclo de vida adoptado, de la metodologa de desarrollo y de la tecnologa utilizada.
35

Objetivos del estndar ISO/IEC 15504

ISO/IEC 15504:2004 (SPICE)

ISO/IEC 15504 proporciona una base para realizar evaluaciones de la capacidad de los procesos de software y permite reflejar los resultados obtenidos sobre una escala comn, que puede usarse, por una parte, para comprobar la evolucin de una organizacin en el tiempo o para observar su situacin respecto a la competencia, y por la otra, para la definicin de estrategias de mejora. El estndar no pretende fijar la manera de realizar los procesos dentro de una organizacin, sino que valora su capacidad y ayuda a proponer mejoras que aumenten esta capacidad. La manera de llevar a cabo estas mejoras no entra dentro del alcance de la Norma.
36

18

Historia del estndar ISO/IEC 15504

ISO/IEC 15504:2004 (SPICE)

La primera versin del borrador del estndar apareci en junio de 1995. Fue aplicado en numerosas empresas donde se fue revisando y refinando segn el procedimiento habitual de desarrollo de estndares internacionales. Su primera publicacin como informe tcnico data del ao 1998, y llev por nombre ISO/IEC TR 15504. Desde esa fecha se han realizado ms de 4.000 evaluaciones en empresas y organizaciones de todo el mundo. En base al conocimiento adquirido en la aplicacin del Informe tcnico en estas industrias, la comunidad internacional sigui con el proceso de revisin de la Norma, liberando entre los aos 2003-06 las 5 partes del nuevo estndar. Con el fin de coordinar todo el proyecto, que ha incluido un gran nmero de personas de ms de 20 pases, se crearon cinco Centros Tcnicos Internacionales.

37

Partes que forman el estndar

ISO/IEC 15504:2004 (SPICE)

El estndar completo vigente hoy en da se denomina ISO/IEC 15504, Information Technology Process Assessment, y se divide a su vez en cinco partes:
ISO/IEC 15504-1:2004. Part 1: Concepts and vocabulary. Representa una introduccin general a la Norma, proporcionando una gua de uso de la misma. En esta parte se incluye el conjunto de trminos definidos especficamente para la Norma. ISO/IEC 15504-2:2003/Cor 1:2004. Part 2: Performing an assessment. Define los requisitos que debe cumplir una evaluacin para que produzca resultados repetibles, fiables y consistentes. ISO/IEC 15504-3:2004. Part 3: Guidance on performing an assessment. Establece una gua para la realizacin de evaluaciones de procesos, interpretando los requisitos de las partes normativas para diferentes contextos de evaluacin. ISO/IEC 15504-4:2004. Part 4: Guidance on use for process improvement and process capability determination. Proporciona una gua para poder utilizar los resultados de una evaluacin en la mejora de los procesos evaluados. La gua incluye ejemplos de la aplicacin de mejoras en una gran variedad de situaciones. ISO/IEC 15504-5:2006 Part 5: An exemplar Process Assessment Model. Proporciona un modelo totalmente compatible con la parte normativa, que incluye un conjunto de indicadores que facilitan el clculo de la capacidad de los procesos.
38

19

Partes pendientes de publicar

ISO/IEC 15504:2004 (SPICE)

Estan actualmente an en proceso de elaboracin y revisin dos partes ms del estndar internacional:
Parte 6 - An exemplar process assessment model for systems life cycle processes (publication Q3 2007) Parte 7 - Assessment of organizational maturity (expected publication 2008)

39

El modelo CMM
El modelo Capability Maturity Model (CMM), tambin denominado CMM-SW, fue desarrollado por el SEI como marco de referencia para la evaluacin y mejora de procesos software.
Con el fin de proporcionar al gobierno de los Estados Unidos un mtodo para evaluar la capacidad de sus proveedores de software. En septiembre de 1987, publicaron el primer resultado en forma de una breve descripcin del proceso de madurez as como un cuestionario para detectar los puntos dbiles de la empresa evaluada. Despus de unos cuantos aos de aplicacin del primer modelo y refinamiento del mismo a partir de los resultados que se iban obteniendo en su aplicacin en diferentes empresas, el SEI desarroll y public la primera versin de CMM en 1991. Esta primera versin fue utilizada y revisada por la comunidad de software durante 1991 y 1992, y en abril de este ao surgi la primera versin definitiva, CMM Versin 1.0

CMM contiene los elementos esenciales para conseguir procesos eficaces en uno o ms cuerpos de conocimiento, estando estos elementos basados en los conceptos desarrollados por los padres de la calidad: Crosby, Deming, Juran y Humphrey. En el ao 2000, el CMM-SW fue actualizado hacia el modelo CMMI (Capability Maturity Model Integration). 40

20

Los cinco niveles de madurez

El modelo CMM
El modelo CMM organiza la madurez de un proceso software en 5 Niveles. En cada Nivel, adems de establecer una escala de medida de la capacidad de los procesos, se fijan unos objetivos que ayudan a la organizacin a priorizar los esfuerzos dedicados a la mejora de estos procesos.
5. En optimizacin

Procesos en mejora continua

4. Gestionado

Cada Nivel de Cada Nivel de madurez est madurez est organizado en reas organizado en reas Clave de proceso Clave de proceso KPA (Key Process KPA (Key Process Area) Area) Las KPA Las KPA representan un representan un grupo de prcticas o grupo de prcticas o actividades actividades relacionadas que, relacionadas que, colectivamente colectivamente ayudan a alcanzar ayudan a alcanzar un conjunto de un conjunto de objetivos que objetivos que permiten mejorar la permiten mejorar la capacidad o capacidad o madurez del proceso madurez del proceso

Procesos controlados cuantitativamente Evaluacin y medicin de procesos 3. Definido

Procesos software documentados y estandarizados 2. Repetible

Actividades bsicas de gestin de proyectos 1. Inicial

Proceso impredecible, poco controlado

41

Relacin entre los Niveles de madurez y las KPA

El modelo CMM
Nivel 1. Inicial reas clave de proceso No hay reas clave de proceso establecidas Gestin de la configuracin del software Aseguramiento de la calidad del software Gestin de acuerdos y contratos con proveedores Planificacin, seguimiento y control de proyectos Gestin de requisitos Revisin detallada de los procesos Coordinacin dentro del grupo de trabajo Ingeniera del producto software Gestin integrada del proyecto Programa de formacin Definicin del proceso organizativo Enfoque hacia los procesos organizativos Gestin de la calidad de software Gestin cuantitativa de procesos Gestin del cambio en los procesos Gestin de los cambios tecnolgicos Prevencin de defectos
42

2. Repetible

3. Definido

4. Gestionado 5. En optimizacin

21

Personal Software Process (PSP)

Personal Software Process (PSP) es un modelo de mejora del proceso software formado por un conjunto estructurado de descripciones de procesos, de mediciones y de mtodos basado en la aplicacin de mtodos avanzados y tradicionales de ingeniera al desarrollo de software y orientado a la mejora individual de cada ingeniero de software. Fue desarrollado por Watts Humphrey, quien haba participado en la creacin de la primera versin del modelo CMM en la dcada de los 80 y del que algunos decan que no era aplicable a pequeas organizaciones y a proyectos pequeos. Para demostrar que estas afirmaciones eran equivocadas, Humphrey desarroll, entre los aos 1989 y 1993, ms de 60 programas y escribi ms de 25.000 lneas de cdigo, aplicando los principios de CMM hasta el Nivel 5. Concluy que los principios incluidos en el modelo CMM eran aplicables incluso en el trabajo de un nico ingeniero de software y de ah surgi el modelo PSP. Segn PSP, para realizar un buen trabajo de Ingeniera de software, un tcnico debe:
En primer lugar, conocer el tiempo que necesita para realizar bien su trabajo En segundo lugar, planificarlo antes de comenzarlo y En tercer lugar, realizarlo de forma correcta.

Segn el autor de PSP The right way is always the fastest and cheapest way to do a job. Finalmente, se debern analizar los resultados de cada actividad y utilizarlos para mejorar los procesos, actividades y tareas.

43

Personal Software Process (PSP)

Los principios del PSP se describen brevemente a continuacin:
Cada Tcnico es diferente. Para ser efectivos deben tener en cuenta sus capacidades personales y adaptar la planificacin de sus trabajos a sus tiempos. Un mtodo que puede que sea efectivo para un persona no tiene porqu serlo para otra. Las personas que trabajan en el desarrollo de software pueden mejorar su rendimiento utilizando procesos bien definidos. Para conocer el rendimiento de cada persona es necesario medir el tiempo o esfuerzo dedicado a cada actividad o tarea, los defectos que se generan y que se corrigen durante ese periodo de tiempo y los tamaos de los productos que se obtienen. Es decir, el PSP utiliza tres tipos de mediciones: esfuerzo, nmero de defectos y tamao de los productos. Para obtener productos de calidad, cada persona debe responsabilizarse del trabajo que ha realizado y de los productos que ha obtenido. Para reducir los costes de produccin, se debe intentar prevenir los defectos antes de que ocurran, y en todo caso, descubrir los defectos en las fases ms tempranas.

El PSP pretende fundamentalmente:

Mejorar la gestin de la calidad de un proyecto. Mejorar la estimacin y la planificacin de un proyecto. Reducir el nmero de defectos en los productos obtenidos durante el desarrollo.
44

22

Arquitectura principal del modelo PSP

Personal Software Process (PSP)

Revisin del cdigo Revisin del cdigo Revisin de diseo Revisin de diseo

PSP2 PSP2

Diseo de plantillas Diseo de plantillas

PSP2.1 PSP2.1

Fase 2

Introduce gestin de calidad y diseo

Estimacin del tamao Estimacin del tamao Informe de pruebas Informe de pruebas

PSP1 PSP1

Planificacin de tareas Planificacin de tareas Planificacin de tiempos Planificacin de tiempos

PSP1.1 PSP1.1

Fase 1

Introduce estimacin y planificacin

Proceso actual Proceso actual Medidas bsicas Medidas bsicas

PSP0 PSP0

Estndares de codificacin Estndares de codificacin Propuesta de mejora de Propuesta de mejora de procesos procesos Medidas del tamao Medidas del tamao

PSP0.1 PSP0.1

Durante la Fase 0 el objetivo principal del ingeniero de software es aprender a seguir un proceso definido y a recopilar los datos bsicos sobre tamao, tiempo y defectos.

Fase 0

Introduce disciplina de proceso y medida

Durante la Fase 1, como ya se dispone de datos histricos para el proceso, el objetivo principal se centra en la estimacin y en la planificacin. Para ello, es necesario conocer mtodos de estimacin de esfuerzo y de tamao, y utilizar estos resultados en la planificacin y en el seguimiento. Durante la Fase 2, debido a que ya se realiza el control de la planificacin, el objetivo principal est en la gestin de la calidad. El tcnico debe conocer los mtodos de deteccin temprana y de eliminacin de defectos. Una vez que se ha finalizado con las tres fases, el tcnico debe realizar un informe sobre su rendimiento y debe ser capaz de analizar los datos que ha ido recopilando para efectuar los cambios que considere oportunos y que le conduzcan a la mejora de su trabajo.
45

Team Software Process (TSP)

Team Software Process (TSP) es un mtodo de establecimiento y mejora del trabajo en equipo para procesos software. TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organizacin pueda establecer prcticas de ingeniera avanzadas y as obtener productos eficientes, fiables y de calidad. TSP se basa en los siguientes principios:
Los tcnicos conocen muchas cosas sobre su trabajo y pueden realizar las mejores planificaciones. Cuando son ellos quienes planifican su propio trabajo, se encuentran comprometidos con el plan. Un seguimiento preciso de un proyecto requiere planes bien detallados y datos precisos. nicamente el personal que realiza el trabajo es capaz de recoger con precisin dichos datos. Para minimizar el tiempo del proyecto, los ingenieros deben equilibrar su carga de trabajo. Para maximizar la productividad, el primer foco de atencin debe ser la calidad.

TSP est formado por dos componentes primarios bien diferenciados que abarcan distintos aspectos del trabajo en equipo y que pueden observarse de manera resumida en la prxima figura, que son:
Formacin del equipo de trabajo. Gestin del equipo de trabajo.
46

23

Relacin entre PSP y TSP

Team Software Process (TSP)

Gestin del equipo

Formacin del equipo

Establecimiento de objetivos Asignacin de roles Adaptacin del proceso Planificacin detallada

Habilidades de los miembros del equipo

Disciplina del proceso Medidas de rendimiento Habilidades para la estimacin y para la planificacin Habilidades de gestin de calidad

PSP
47

Relacin entre PSP y TSP

Team Software Process (TSP)

Segn Humphrey, para que una organizacin mejore el proceso software y desarrolle productos de calidad, debe contemplar diferentes aproximaciones de mejora del proceso, todas ellas complementarias:
La organizacin debe llevar a cabo sus procesos segn la forma establecida en un modelo. Humphrey propone utilizar el modelo CMM. Los ingenieros deben desarrollar sus capacidades individuales de una forma eficiente y controlada. El autor propone utilizar los principios del PSP. El trabajo debe desarrollarse dentro de un equipo formado y con una capacidad de trabajo conjunta. El autor propone utilizar los principios del TSP.

De manera conjunta PSP y TSP permiten definir y mantener equipos que consideren las capacidades individuales de sus miembros.
Si bien esta capacidad individual es crtica, ya que cada instruccin de un mdulo ha sido realizada por un nico ingeniero de software Tambin es cierto que un producto software es el resultado de un trabajo en equipo, formado por un conjunto de subproductos o mdulos que han sido diseados, construidos, integrados, probados y mantenidos por un equipo de ingenieros de software cuyas habilidades, capacidades y disciplina, contribuirn en el xito del proyecto. 48

TSP

Comunicacin del equipo Coordinacin del equipo Pruebas del proyecto Anlisis de riesgos

24

Relacin entre CMM/CMMI, TSP y PSP

En la figura se puede observar como CMM/CMMI, TSP y PSP pueden usarse de forma conjunta y combinada para mejorar las capacidades de toda la organizacin:

CMM/CMMI CMM/CMMI para las capacidades para las capacidades de la organizacin de la organizacin

TSP TSP para la capacidad para la capacidad de trabajo en equipo de trabajo en equipo PSP PSP para la mejora de para la mejora de las capacidades las capacidades individuales individuales

49

Relacin entre CMM/CMMI, TSP y PSP

El uso combinado de TSP y PSP aceleran el proceso de mejora segn CMM, si bien es necesario establecer los pasos para combinar ambos esfuerzos:
En primer lugar, con la aplicacin de TSP, los tcnicos y los equipos, pueden ver las razones del alto Nivel de madurez de la mayora de prcticas de CMM, y entienden ms la necesidad de cooperar en los esfuerzos de mejora. En segundo lugar, ya que el objetivo de cualquier esfuerzo de mejora de procesos de software es aumentar el rendimiento de la organizacin, y ello requiere cambios en el funcionamiento de los procesos de ingeniera, cualquier esfuerzo de mejora debe estar acompaado por pasos que puedan demostrar cambios en los comportamientos de ingeniera. TSP y PSP se utilizan para este fin. En tercer lugar, cualquier esfuerzo de mejora conlleva el riesgo de burocratizarse y de imponer presin sobre los ingenieros en lugar de ayudarles. Si como se sugiere en TSP, el equipo es tratado como si fueran clientes, este riesgo disminuye considerablemente. En cuarto lugar, TSP permite mejorar substancialmente el rendimiento de los grupos de software en una organizacin.

50

25

Bootstrap
Bootstrap es el resultado del proyecto ESPRIT 5441, que fue llevado a cabo entre septiembre de 1991 y febrero de 1993. El principal objetivo del proyecto era acelerar la aplicacin tanto de los principios como de la tecnologa relacionada con la Ingeniera del Software a la industria del software en Europa. Durante este proyecto se realiz el desarrollo del modelo Bootstrap que describe el proceso de evaluacin desarrollado para determinar si una organizacin se encuentra en un cierto Nivel de madurez, identificando los puntos dbiles, los puntos fuertes y ofreciendo las pautas de mejora. Bootstrap se prob en unos 60 casos en empresas. Ms tarde, en 1996, se fund el Instituto Bootstrap, que ha sido quien se ha hecho cargo de las posteriores revisiones del modelo y quien mantiene la base de datos de los resultados obtenidos en sus aplicaciones, principalmente en empresas europeas, pero tambin en el resto del mundo.
51

La Metodologa Bootstrap
El modelo de procesos de software utilizado por Bootstrap es un modelo cclico, compatible con el que se utiliza en ISO/IEC 15504, que tambin es equivalente al modelo IDEAL del SEI. La metodologa propuesta por Bootstrap comprende las actividades que se muestran en la figura.
1 1 Examinar necesidades Examinar necesidades empresa empresa 2 2 Iniciar Iniciar proceso de mejora proceso de mejora

6 6 Finalizar mejoras Finalizar mejoras 3 3 Preparar yydirigir Preparar dirigir evaluacin evaluacin 5 5 Implantar mejoras Implantar mejoras

Analizar resultados y Analizar resultados y establecer plan de accin establecer plan de accin

4 4

52

26

La Metodologa Bootstrap
Examinar las necesidades de la empresa, realizando los primeros contactos con los responsables y delimitando la accin. Iniciar el proceso de mejora, definiendo el objetivo de la mejora y comenzando a desarrollar un plan de mejora. Preparar y dirigir la evaluacin, para conocer el estado de todos los procesos de la empresa. Analizar los resultados de la evaluacin y establecer el plan de accin, identificando y priorizando las reas de mejora y estableciendo el plan de accin para mejorar estos procesos seleccionados. Implantar las mejoras, a travs de un plan de accin detallado aplicado a proyectos reales. Finalizar las mejoras, garantizando que se han alcanzado todos los objetivos establecidos.

53

El modelo IDEAL
El modelo IDEAL, desarrollado en el SEI, intenta dar respuesta a la pregunta Qu debo hacer, una vez evaluados mis procesos, para iniciar un programa de mejora y qu actividades debe incluir el programa?. El modelo IDEAL propone el camino de acciones que deben formar parte del programa de mejora de procesos de software cuando una organizacin desea llevar a cabo las buenas prcticas recomendadas por el modelo CMM, en el cual se basa. IDEAL es el acrnimo que corresponde a las iniciales de las cinco fases del modelo (I:Initiating, D: Diagnosing, E: Establishing, A:Acting, L: Leveraging) que se muestra en la siguiente figura.

54

27

El modelo IDEAL

55

El modelo IDEAL
Las 5 fases se dividen a su vez en un mximo de 10 tareas y stas en 5 6 subtareas Fase de Iniciacin. Se definen los objetivos generales del programa de mejora de procesos software basados en las necesidades de negocio. Se establece la infraestructura necesaria para la mejora, se definen los roles y las responsabilidades de cada uno y se asignan los recursos iniciales. Se crea el plan que cubre todas las tareas a realizar para las dos fases sucesivas. Fase de Diagnstico. Se realizan las actividades de evaluacin que permitan conocer el estado actual de la organizacin, y se incluyen los resultados y las recomendaciones derivadas de estas evaluaciones en la primera versin del plan de mejora. Fase de Establecimiento. Se priorizan y se buscan soluciones para los temas seleccionados por la empresa. Se completa el plan de accin y se establecen medidas y objetivos medibles para controlar el alcance de los objetivos. Fase de Actuacin. Se llevan a cabo las soluciones adoptadas en la fase anterior. Fase de Difusin. Se evalan las informaciones recogidas en las fases anteriores, los conocimientos adquiridos y las mtricas de rendimiento establecidas, para que el prximo paso o aplicacin del modelo sea ms efectivo. 56

28

El modelo MoProSoft (Oktaba 2005) Modelo basado en las mejores prcticas internacionales con las siguientes caractersticas:
Fcil de entender Fcil de aplicar No costoso en su adopcin Ser la base para alcanzar evaluaciones exitosas con otros modelos o normas, tales como ISO 9000:2000 o CMM V1.1

57

El modelo MoProSoft (Oktaba 2005)

n cci ire ta D Al R ) I (D n sti Ge ) ES (G n aci pe r O ) PE (O

Categora

Gestin de Negocio
Categora

Gestin de Procesos Gestin de Proyectos Gestin de Recursos

Categora

Administracin de Proyectos Especficos Desarrollo y Mantenimiento de Software

58

29

El modelo MoProSoft (Oktaba 2005)

Norma Mexicana
Qu

Modelo de Procesos
Normativa (qu procesos) Informativa (cmo implantarlos) Anexo ISO/IEC FDIS 15504-2 Performing an assesment Requisitos

MOPROSOFT
Cmo ISO 12207 Software life cycle processes Relacin

Modelo de Capacidades Norma de Procesos (qu evaluar) Mtodo de evaluacin (cmo evaluar)
ISO/IEC FDIS 15504-3 Guidance on performing an assesment Guas

Requisitos

59

30