Mejora de procesos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 1

 Objetivos
● Explicar los principios de la mejora de procesos de
software
● Explicar cómo los factores del proceso de software
influencian la calidad y la productividad del software.
● Explicar cómo desarrollar modelos simples de
procesos de software
● Explicar la noción de capacidad de proceso y el
modelo CMMI para la mejora de procesos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 2

 Contenidos
● Calidad de producto y de proceso
● Clasificación de procesos
● Medición de procesos
● Análisis y modelado de procesos
● Cambio en los procesos
● El marco de trabajo para la mejora de
procesos CMMI

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 3

 Mejora de procesos
● Comprender los procesos existentes e
introducir cambios de proceso para mejorar
la calidad del producto, reducir los costes y
acelerar el tiempo de desarrollo.
● La mayoría de las mejoras de procesos
trabajan centradas en la reducción de
defectos. Esto refleja el aumento de atención
que presta la industria a la calidad.
● Sin embargo, otros atributos del proceso
también pueden se objeto de mejoras.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 4

 Atributos del proceso

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 5

 Ciclo de mejora del proceso

Medición

cambio análisis

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 6

 Etapas de mejora del proceso
● Medición del proceso
• Se miden los atributos del proceso actual.
Estos son el punto de partida para la
valoración de mejoras.
● Análisis del proceso
• Se valora el proceso actual y se identifican
las debilidades y dificultades.
● Cambio del proceso
• Se introducen en el proceso los cambios que
han sido identificados durante el proceso

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 7

 Calidad de producto y proceso
● La calidad de producto y la calidad del proceso
están estrechamente relacionados y los beneficios
de mejora del proceso aumenta porque la calidad
del producto depende de su proceso de desarrollo.
● Normalmente hace falta un buen proceso para
producir un buen producto
● Para los fabricantes de bienes, el proceso es el
principal determinante de la calidad.
● Para actividades basadas en el diseño, están
implicados también otros factores, especialmente
las capacidades de los diseñadores.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 8

 Principales factores de calidad
del producto

Tecnología de
desarrollo

Calidad Calidad Calida

del del producto d del
proceso person
al

Coste, tiempo
y duración

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 9

 Factores de calidad
● Para proyectos grandes como capacidades
«medias», el proceso de desarrollo determina la
calidad del producto.
● Para proyectos pequeños, las capacidades de los
desarrolladores es el principal determinante.
● La tecnología de desarrollo es particularmente
importante para proyectos pequeños.
● En todos los casos, si se impone un calendario poco
realista, entonces sufre la calidad del producto.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 10

 Clasificación de procesos
● Informales
• No hay modelo de proceso detallado. El equipo de
desarrollo elige su propia manera de trabajar.
● gestionados
• Modelo de proceso definido que conduce el proceso de
desarrollo
● Metodológicos
• Los son apoyados por algún método de desarrollo como
el RUP
● Apoyados
• Procesos apoyados por herramientas CASE automáticas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 11

 Aplicabilidad del proceso
Prototipos
Sistemas con tiempos de
Proceso
vida cortos
informal
Sistemas de gestión 4GL
Sistemas pequeños o
medianos

Proceso Sistemas grandes

gestionad Productos con tiempos
o de vida largos

Dominios de aplicación bien

Proceso entendidos
metodológico Sistemas donde se ha aplicado
reingeniería

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 12

 Elección del proceso
● El proceso utilizado debería depender del tipo de
producto que se está desarrollando
• Para sistemas grandes, la gestión es normalmente el
problema principal así que se necesitará un proceso
estrictamente gestionado;
• Para sistemas más pequeños, es posible una mayor
informalidad.
● No hay un proceso uniformemente aplicable que
deba estar estandarizado en una organización
• puede incurrir en altos costes si se fuerza un proceso
inadecuado en un equipo de desarrollo;
• Los métodos inadecuados también pueden incrementar los
costes y derivar en una reducción de la calidad.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 13

 Herramientas de apoyo al
proceso

Proceso Proceso Proceso Proceso

informal administrad metódico de mejora
o

Herramientas de Herramienta Bancos de

Herramient Herramient
administración s de trabajo de
as as
de la administraci análisis y
genéricas especializa
configuración ón de diseño
das
proyectos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 14

 Medición del proceso
● Siempre que sea posible, deberían recogerse datos
cuantitativos del proceso
• Sin embargo, en las organizaciones en las que no se
tiene unos estándares de proceso claramente definidos
esto resulta muy difícil ya que no se sabe qué es lo que
hay que medir. Un proceso puede tener que definirse
antes de que sea posible cualquier medición.
● Las mediciones del proceso deberían utilizarse para
valorar las mejoras del proceso
• Pero esto no significa que las mediciones conduzcan las
mejoras. Los objetivos organizacionales debieran ser
quienes condujeran las mejoras.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 15

 Clases de mediciones de
procesos
● Tiempo requerido para completar las actividades del
proceso
• P.ej: El tiempo de calendario o esfuerzo necesario para
completar una actividad o proceso
● Recursos requeridos para los procesos o
actividades
• P.ej: Esfuerzo total en días/persona.
● Número de ocurrencias de un evento en particular
• P.ej: Número de defectos descubiertos.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 16

 Paradigma Goal-Question-Metric
(GQM)
● Metas (goals)
• ¿Qué está tratando de conseguir la organización? El
objetivo de la mejora del proceso es satisfacer esas
metas.
● Preguntas (Questions)
• Preguntas sobre las áreas de incertidumbre relacionadas
con las metas. Se necesita conocimiento del proceso
para derivarlas.
● Métricas (Metrics)
• Las mediciones a recoger para responder a las preguntas

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 17

 Análisis y modelado de procesos
● Análisis de procesos
• Estudio de procesos existentes para
comprender las relaciones entre las partes del
proceso y compararlas con otros procesos
● Modelado de procesos
• La documentación de un proceso que registra la
tarea, los roles y las entidades utilizadas;
• Los modelos de proceso pueden estar
presentados desde diferentes perspectivas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 18

 Análisis y modelado de procesos
● Estudiar un proceso existente para comprender sus
actividades.
● Producir un modelo abstracto del proceso.
Normalmente se debería representar gráficamente.
Pueden hacer falta varias perspectivas (P.ej:
actividades, entregas, etc)
● Analizar el modelo para descubrir los problemas del
proceso. Esto implica la discutir con los stakeholders
sobre y descubrir problemas y posibles cambios en
el proceso.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 19

 Técnicas de análisis del proceso
● Modelos de proceso publicados y estándares de
proceso
• Siempre es mejor iniciar el análisis del proceso con un
modelo existente. Las personas, entonces, deberían
ampliarlo y cambiarlo.
● Cuestionarios y entrevistas
• Debe ser diseñado cuidadosamente. Los participantes
podrían decir lo que piensan que quieres oír
● Análisis etnográfico
• Implica asimilar el conocimiento del proceso mediante la
observación. Es mejor para análisis en profundidad de los
fragmentos del proceso en lugar de para la comprensión
global del proceso.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 20

 Elementos de un modelo de
proceso 1
Actividad (representada por
un rectángulo redondeado
sin sombra)
Proceso (representado por
un rectángulo redondeado
con sombra)
Producto a entregar
(representado por un
rectángulo con sombra)
Condición (representada
por un paralelogramo)
©Ian Sommerville 2004
Una actividad tiene claramente definidos un objetivo, las entradas y
las condiciones de salida. Ejemplos de actividades son preparar un
conjunto de datos de prueba de lectura a un documento, etcétera.
Por lo general, una actividad es atómica, es decir, incumbe a una
persona o a un grupo. No se descompone en subactividades
Un proceso es un conjunto de actividades que tienen alguna
coherencia y cuyo objetivo generalmente es acordado dentro de la
organización. Ejemplos de procesos son el análisis de
requerimientos, el diseño arquitectónico, la planificación de
pruebas, etc.
Un producto a entregar es una salida tangible de una actividad
prevista en un plan de proyecto.
Una condición es o una precondición que debe cumplirse antes de
iniciar un proceso o actividad o una postcondición que se cumple
después de terminar el proceso o la actividad.
Software Engineering, 7th edition. Chapter 28 Slide 21
 Elementos de un modelo de
proceso 2

Rol (representado por un Un rol es un área limitada de responsabilidad. Ejemplo de roles son
círculo con sombra) el gestor de configuraciones, el ingeniero de pruebas, el diseñador
de software, etc. Una persona puede tener varios roles distintos, y
un solo rol se puede asociar a varias personas
Excepción (no se muestra Una excepción es una descripción de cómo modificar el proceso si
en los ejemplos pero se ocurre un evento anticipado o no anticipado. Las excepciones a
representa como un cuadro menudo son indefinidas y se deja a la habilidad de los
de doble borde) administradores e ingenieros del proyecto el manejo de la excepción
Comunicación Un intercambio de información entre personas o entre personas y
(representada por una sistemas de cómputo de apoyo. Las comunicaciones pueden ser
flecha) informales o formales. Las comunicaciones formales podrían ser
que un administrador del proyecto apruebe un producto a entregar;
las comunicaciones informales podrían ser el intercambio de un
correo electrónico para resolver las ambigüedades en un documento

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 22

 Proceso de pruebas de un
módulo
Rol
Postcondición
Ingenier Todas las
Precondición
o de pruebas definidas
pruebas se ejecutan en el
El módulo
módulo
compila sin
errores de Responsable
sintaxis salidas

Probar módulo Registro de

pruebas firmado
Entrada
Proceso
Especificaci Datos de prueba
ón del del módulo
módulo

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 23

 Actividades involucradas en la
prueba de un módulo
PREPARACIÓN DE LOS DATOS DE PRUEBA

Preparar datos
Leer Someter a Revisar los datos
de prueba
especificación revisión los de prueba
acordes con la
del módulo datos de prueba
especificación

PREPARACIÓN DEL ARNÉS DE PRUEBAS DEL MÓDULO

Comprobar un
módulo a partir Leer y comprender Preparar arnés de Compilar
del sistema de la interfaz del pruebas para el arnés de
administración módulo módulo pruebas
dela configuración

EJECUCIÓN DE LA PRUEBA

Ejecutar las Registrar resultados

Incorporar módulo
pruebas de pruebas para
con el arnés de
aprobadas en el pruebas de
pruebas
módulo regresión

GENERACÍÓN DE INFORMES DE LAS PRUEBAS

Redactar informe de
la prueba del módulo Someter el Someter resultados
incluyendo detalles de informe a de prueba al CM
los problemas aprobación
descubiertos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 24

 Excepciones del proceso
● Los procesos de software son complejos y los
modelos de proceso no pueden representar de forma
efectiva cómo manejar las excepciones:
• Varias personas clave se ponen enfermas justo antes de la
revisión crítica;
• Avería en la computadora de seguridad que deja todas las
comunicaciones fuera de servicio durante varios días;
• Reorganización organizacional
• Se hace una petición no prevista de propuestas para nuevos
proyectos. El esfuerzo se transfiere de un proyecto a
trabajar en una propuesta.
● En estas circunstancias el modelo se suspende y los
gestores utilizan su iniciativa para tratar la excepción.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 25

 Cambio de proceso
● Implica hacer modificaciones en los procesos
existentes.
● Lo que puede conllevar:
• La introducción de nuevas prácticas, métodos o
procesos;
• El cambio de ordenación de las actividades del proceso;
• La introducción o eliminación de entregas;
• La introducción de nuevos roles o responsabilidades.
● El cambio debería estar conducido por metas
mesurables.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 26

 El proceso de cambio de proceso

Introducir
cambios de
Identifica Priorizar mejoras proceso Refinar los
r mejoras cambios de
Capacitar a proceso
los
ingenieros

Modelo de proceso Plan de Plan de Retroalimenta Modelo de

cambio de capacitación ción de proceso
proceso mejoras revisado

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 27

 Etapas de cambio del proceso
● Identificación de la mejora.
● Priorización de la mejora.
● Introducción de cambios en el proceso.
● Capacitación en el cambio del proceso.
● Refinamiento.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 28

 El marco de trabajo CMMI
● El marco de trabajo CMMI es la etapa habitual de trabajo en
la valoración y mejora de procesos que se inició en el
Software Engineering Institute (SEI) en 1980.
● La misión del SEI es promocionar la transferencia de
tecnología del software particularmente para los contratistas
de defensa.
● Ha tenido una profunda influencia en la mejora de procesos
• El Modelo de Madurez de la Capacidad fue introducido a principios
de los noventa.
• El marco de trabajo de madurez revisado (CMMI) fue introducido en
2001

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 29

 Valoración de las capacidades
del proceso
● Previsto como medio para valorar hasta qué
punto los procesos de la organización
siguen la mejor práctica.
● Proporcionando un medio de valoración es
posible identificar las áreas de debilidad
para la mejora de procesos.
● Han existido varios modelos de valoración y
mejora de procesos pero el trabajo del SEI
ha sido el más influyente.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 30

 El modelo de madurez de la
capacitación del SEI
● Inicial
• Esencialmente no controlado
● Repetible
• Se definen y utilizan Procedimientos de gestión del producto
● Definido
• Se definen y utilizan Procedimientos y estrategias de gestión
del proceso
● gestionado
• Se definen y utilizan estrategias de gestión de la calidad
● Optimización
• Se definen y utilizan Estrategias de mejora del proceso

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 31

 Problemas con el CMM
● Prácticas asociadas con los niveles del modelo
• Las compañías podrían estar usando prácticas de
diferentes niveles al mismo tiempo pero si todas las
prácticas de un nivel inferior no se utilizan, no es posible
moverse por encima de ese nivel
● Discreto en lugar de continuo
• No se reconocieron las distinciones entre la parte
superior y la parte inferior de los niveles
● Orientado a prácticas
• Se ocupaba de cómo se habían las cosas (las prácticas)
en lugar de en las metas perseguidas.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 32

 El modelo CMMI
● Un modelo de capacidad integrado que
incluye la valoración de la capacidad de
ingeniería de sistemas.
● El modelo tiene dos ejemplos
• En etapas, en el que el modelo se expresa en
términos de niveles de habilidad;
• Continuo en el que se calcula la valoración de
la habilidad.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 33

 Componentes del modelo CMMI
● Áreas de proceso
• Se identifican 24 áreas de proceso que son relevantes
para la capacidad y mejora del proceso. Éstas se
organizan en 4 grupos.
● Metas
• Las metas son descripciones de estados
organizacionales deseables. Cada área del proceso tiene
metas asociadas.
● Practicas
• Las prácticas son formas de conseguir metas – sin
embargo, son consultativas y se podrían usar otros
enfoques para conseguir la meta.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 34

 Áreas de proceso en el CMMI 1

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 35

 Áreas de proceso en el CMMI 2

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 36

 Metas del CMMI

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 37

 Prácticas del CMMI
Práctica Meta asociada
Análisis de los requerimientos derivados para Los requerimientos son analizados y
asegurar que son necesarios y suficientes validados, y se define la funcionalidad
requerida
Validar los requerimientos para asegurar que el
producto resultante funciona tal y como se pretendía
en el entorno del usuario, utilizando múltiples
técnicas cuando sea apropiado
Seleccionar lso defectos y otros problemas a analizar Se determinan sistemáticamente las
principales causas de defectos y otros
Análisis causal de los defectos y otros problemas problemas
seleccionados y proponer acciones para corregirlos
Establecer y mantener una política organizacional de El proceso es institucionalizado como
planificación y presentación del proceso de un proceso definido
desarrollo de requerimientos
Asignar responsabilidades y autorizaciones para
presentar el proceso, desarrollar los productos de
trabajo y proveer los servicios para el proceso de
desarrollo de los requerimientos

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 38

 Valoración del CMMI
● Examina los procesos utilizados en una organización
y valora su madurez en cada área de proceso.
● Basados en una escala de seis puntos:
• No productivo;
• productivo;
• Gestionado;
• Definido;
• Gestionado cuantitativamente;
• Optimizado.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 39

 El modelo CMMI en etapas
● Comparable al software CMM
● Cada nivel de madurez tiene áreas y metas de
proceso. Por ejemplo, el área del proceso asociado
con el nivel gestionado incluye:
• Gestión de requerimientos;
• Planificación del proyecto;
• Monitorización y control del proyecto;
• Acuerdos con los proveedores;
• Análisis y mediciones;
• Garantía de la calidad del proceso y del producto.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 40

 El modelo CMMI en etapas
Nivel 5
Optimizado

Nivel 4
Gestionado
cuantitativamente

Nivel 3
Definido

Nivel 2
Gestionado

Nivel 1
Inicial

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 41

 Prácticas institucionales
● Las instituciones que operan en el nivel gestionado
deberían tener prácticas institucionalizadas que
estén adaptadas a la estandarización.
• Establecer y mantener políticas para realizar el proceso
de gestión del proyecto;
• Proporcionar recursos adecuados para realizar el
proceso de gestión del proyecto;
• Monitorizar y controlar el proceso de planificación del
proyecto;
• Revisar las actividades, el estatus y los resultados del
proceso de planificación del proyecto.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 42

 El modelo CMMI continuo
● Este es un modelo de grano fino que considera las
prácticas individuales o en grupo y valora su uso.
● La valoración de la madurez no es un valor único
sino un conjunto de valores que muestran la
madurez de las organizaciones en cada área.
● El CMMI estima cada área del proceso desde el
nivel 1 hasta el 5
● La ventaja de un enfoque continuo es que las
organizaciones pueden tomar y elegir áreas del
proceso para mejorarlas de acuerdo con sus
necesidades locales.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 43

 Perfil de capacidad de proceso
Control y seguimiento
del proyecto
Gestión de los
acuerdos con
proveedores
Gestión de riesgos

Gestión de
configuracio
nes
Gestión de
requerimien
tos
Verificación

Validación

1 2 3 4 5

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 44

 Puntos clave
● La mejora del proceso implica el análisis del proceso, la
estandarización, mediciones y cambio.
● Los procesos pueden clasificarse como informales,
gestionados, metódicos y de mejora. Esta clasificación
puede utilizarse para identificar el soporte de herramientas
del proceso.
● El ciclo de mejora del proceso implica la medición del
proceso, el análisis del proceso y el cambio del proceso.
● La medición del proceso debería utilizarse para responder
a preguntas específicas sobre el proceso basadas en
metas de mejora organizacionales.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 45

 Puntos clave
● Los tres tipos de métricas utilizados en los procesos de
medición son las métricas de tiempo, las métricas de
utilización de recursos y las métricas de eventos.
● Los modelos de proceso incluyen descripciones de
tareas, actividades, roles, excepciones, comunicaciones,
entregas y otros procesos.
● El modelo de madurez de proceso CMMI integra software
y mejoras en el proceso de ingeniería de sistemas.
● La mejora de procesos en el modelo CMMI está basada
en alcanzar un conjunto de metas relacionadas a una
buena práctica de ingeniería del software.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 28 Slide 46