Mejora del proceso (parte I)

Cuando hablamos de calidad en el software de una empresa, debemos identificar

diferentes conceptos desde el punto de vista de diferentes autores sobre mejora de
procesos, el proceso de mejora y la medición del proceso.

Caso de análisis

Mejora de procesos

Medición del proceso

Referencias
Lección 1 de 4

Caso de análisis

Una cadena de hoteles llamada Cabañas permite realizar la reserva de

habitaciones vía web. La persona interesada reservará un tipo de habitación
para un periodo determinado. La tarifa varía según la temporada (alta, media
o baja). En el momento de la reserva, no se deberá abonar nada, pero sí se
deberá hacerlo al momento de confirmar, un mes antes del periodo elegido.
La cadena tiene un catálogo con los tipos de cabañas con que cuenta y las
tarifas de acuerdo a la temporada. Esta información es enviada dos veces
por año a los clientes. En el momento de llegada al complejo, se asigna el
número de cabaña.

La cadena se encuentra en toda la Argentina. La empresa necesita que se

puedan realizar reservas y generar los check in y check out de cada cliente en
cualquiera de las sucursales.

El equipo de sistemas de la empresa se encuentra en un proceso de gestión

de calidad. Se hace necesario contratar un profesional que brinde
asesoramiento sobre los diferentes instrumentos para realizar una gestión
adecuada de los cambios de software.
Para poder orientar a las Cabañas sobre la importancia de realizar un
cambio adecuado, vamos a explicar los conceptos de mejora de procesos.

C O NT I NU A R
Lección 2 de 4

Mejora de procesos

La mejora de procesos significa comprender los procesos existentes y

cambiarlos para incrementar la calidad del producto o reducir los costos y el
tiempo de desarrollo.

Se usan dos enfoques muy diferentes para la mejora y el cambio de

procesos:

1 Enfoque de madurez de procesos. Se orienta a mejorar el proceso

y a la gestión del proyecto. Introduce buenas prácticas de
ingeniería de software. El nivel de madurez del proceso refleja la
adopción de buenas prácticas (técnicas y administrativas) en los
procesos de desarrollo de software organizacional. Las metas
principales de este enfoque consisten en mejorar la calidad del
producto y la previsibilidad del proceso.

2 Enfoque ágil. Se orienta al desarrollo iterativo y a la reducción de

las sobrecargas en el proceso de software. Los métodos ágiles
permiten una rápida entrega de funcionalidad y una capacidad de
respuesta eficiente ante las exigencias de los clientes.
Deming, entre otros autores, introdujo la idea del control estadístico de
calidad. Esta herramienta se basa en medir el número de defectos de
productos para relacionarlos con el proceso. En ese sentido, su objetivo es
analizar y modificar el proceso para detectar y reducir las posibilidades de
introducir defectos.

Una vez lograda la reducción en el conteo de defectos, el proceso se

estandariza y comienza un ciclo más de la mejora.

Humphrey (1989), en un libro de gran influencia sobre gestión de procesos,

argumenta que pueden aplicarse las mismas técnicas a la ingeniería de
software. 

W. E. Deming, en su trabajo con la industria japonesa después de la Segunda

Guerra Mundial, aplicó a la industria los conceptos de control estadístico de
procesos. Si bien existen importantes diferencias, estos conceptos pueden
aplicarse al software, a los automóviles, a las cámaras, a los relojes de
pulsera y a la producción de acero.

Figura 1: Factores 
 Fuente: Sommerville, 2005, p. 707.

Para productos de software o cualquier producto intelectual (como libros o

películas) donde la calidad depende del diseño, hay cuatro factores
elementales que afectan la calidad del producto como muestra la figura
anterior. 

La influencia de cada uno de estos factores depende del tamaño y tipo del
proyecto.

Para sistemas muy grandes que incluyen subsistemas separados,

desarrollados por equipos que pueden trabajar en diferentes lugares, el
factor principal que afecta a la calidad del producto es el proceso de
software.
 

Los principales problemas con los proyectos grandes son la

integración, la gestión del proyecto y las comunicaciones. Por lo
general, existe una mezcla de habilidades y experiencia entre
los miembros del equipo y, puesto que el proceso de desarrollo
requiere de varios años, el equipo de desarrollo es volátil. Puede
cambiar por completo durante la vida del proyecto.
(Sommerville, 2005, p. 610).

En los proyectos grandes, es esencial un nivel básico de tecnología de

desarrollo para la gestión de la información. No obstante, paradójicamente,
las herramientas sofisticadas de software  son menos importantes en los
proyectos grandes (Sommerville, 2005).

Sin embargo, para proyectos pequeños donde existen

únicamente unos pocos miembros, la calidad del equipo de
desarrollo es más importante que el proceso de desarrollo
utilizado. Si el equipo tiene un nivel alto de habilidad y
experiencia, la calidad del producto probablemente sea alta. Si
el equipo no tiene experiencia y habilidades, un buen proceso
delimita el daño, pero no conducirá, por sí mismo, a software de
alta calidad.
 Si los equipos son pequeños, es importante contar con una
buena tecnología de desarrollo. El equipo no puede dedicar
mucho tiempo a procedimientos administrativos tediosos. Los
ingenieros invierten mucho de su tiempo diseñando y
programando el sistema, por lo que las buenas herramientas
afectan de forma importante a su productividad. (Sommerville,
2005, p. 610).

Figura 2: Mejora de procesos

 Fuente: Sommerville, 2005, p. 709.

La figura anterior muestra algunos ejemplos de atributos de proceso que

pueden ser objeto de mejora.

Figura 3: El ciclo de mejora de procesos

Fuente: Sommerville, 2005, p. 710.

El proceso de mejora de procesos es cíclico. Incluye tres subprocesos:

 

1. Proceso de medición de los atributos del proyecto actual o del

producto. El objetivo es mejorar las mediciones de acuerdo con
las metas de la organización involucrada en el proceso de
mejora. 

2. Proceso de análisis. El proceso actual es valorado, y se

identifican puntos flacos y cuellos de botella. En esta etapa se
suelen desarrollar los procesos que describen los modelos de
proceso. 

3. Introducción de los cambios del proceso identificados en el

análisis. (Sommerville, 2005, pp. 608-609).

Sin datos concretos respecto de un proceso, es imposible estimar el valor de

la mejora del proceso. Sin embargo, es improbable que las compañías que
inician el proceso de mejora de procesos cuenten con datos de proceso
disponibles como una línea de referencia para la mejora. Por eso, como parte
del primer ciclo de cambios, quizás haya que introducir actividades de
proceso para recopilar datos sobre el proceso de software y medir las
características del producto de software.
La mejora del proceso es una actividad de largo plazo, así que cada una de
las etapas en el proceso de mejora puede durar varios meses. También es
una actividad continua pues, independientemente de los procesos
introducidos, el ambiente de negocios cambiará y los nuevos procesos
tendrán que evolucionar para tomar en cuenta dichos cambios.

C O NT I NU A R
Lección 3 de 4

Medición del proceso

Las mediciones del proceso son datos cuantitativos acerca del proceso de
software, como el tiempo que tarda en realizarse cierta actividad del proceso.
Por ejemplo, es posible medir el tiempo requerido para desarrollar casos de
prueba del programa. 

Humphrey (1989) argumenta que la medición del proceso y los atributos del
producto son esenciales para la mejora de los procesos. Además, este autor
refiere que la medición desempeña un importante papel en la mejora de
procesos personales a pequeña escala, donde los individuos tratan de ser
más productivos.

Las mediciones de procesos pueden usarse para valorar si la eficiencia de un

proceso mejoró o no. Por ejemplo, se puede monitorizar el esfuerzo y el
tiempo dedicados a las pruebas. Las mejoras efectivas deben reducir el
esfuerzo o tiempo de pruebas. No obstante, las mediciones del proceso, por
sí mismas, no pueden usarse para determinar si mejoró la calidad del
producto.

 
 Según Sommerville (2005), se pueden recopilar tres tipos de
métricas de proceso:

1. El tiempo que tarda en completarse un proceso particular. Es el

tiempo total dedicado al proceso, tiempo calendario, tiempo
empleado en el proceso por ciertos ingenieros en particular,
etcétera.

2. Los recursos requeridos para un proceso particular. Los

recursos pueden incluir esfuerzo total en días-hombre, costos de
viaje o recursos de cómputo, etcétera.

3. El número de ocurrencias de un evento particular.  Los

ejemplos de eventos que pueden monitorizarse incluyen el
número de defectos descubiertos durante la inspección del
código, el número de cambios solicitados a los requerimientos y
el número promedio de líneas de código modificadas en
respuesta a un cambio de requerimientos, etcétera.
(Sommerville, 2005, p. 613).

Figura 4: Paradigma GQM

 Fuente: Sommerville, 2005, p. 712.

El paradigma GQM se usa en la mejora de procesos para ayudar a responder

tres preguntas fundamentales:

1 ¿Por qué se introduce la mejora de procesos?

2 ¿Qué información se necesita para ayudar a identificar y valorar las

mejoras?

3 ¿Qué mediciones de proceso y producto se requieren para obtener

esta información?

Siguiendo a Sommerville (2005), estas preguntas se relacionan directamente

con las abstracciones (metas, preguntas, métricas) en el paradigma GQM.
1. Metas
–
Una meta es algún objetivo que la organización pretende lograr. No debe
ocuparse directamente de los atributos del proceso, sino más bien de cómo el
proceso afecta a los productos o a la organización en sí. Ejemplos de metas
pueden ser un mejor nivel de madurez de procesos, un tiempo de desarrollo
de producto más corto o un aumento en la fiabilidad del producto.

2. Preguntas
–
Se trata de mejoras de las metas, en las que se identifican áreas específicas
de incertidumbre relacionadas con las metas. Por lo general, una meta tendrá
algunas preguntas asociadas que necesiten responderse. Ejemplos de
preguntas relacionadas con la meta de acotar los tiempos de desarrollo de
productos pueden ser: 

¿Dónde están los cuellos de botella en el proceso actual? 

¿Cómo puede reducirse el tiempo requerido para finalizar los

requerimientos de producto con los clientes? 

¿Cuántas pruebas son efectivas para descubrir defectos de producto?

3. Métricas
–
Se trata de mediciones que deben recopilarse para ayudar a responder las
preguntas y confirmar si las mejoras del proceso lograron o no las metas
deseadas. Para ayudar a responder las preguntas anteriores, se pueden
recopilar datos acerca del tiempo que tarda en completarse cada actividad
del proceso (normalizado por tamaño de sistema), el número de
comunicaciones formales entre clientes y usuarios para cada cambio de
requerimientos, y la cantidad de defectos descubiertos mediante la ejecución
de pruebas.

La ventaja de este enfoque cuando se aplica a la mejora de

procesos es que separa las cuestiones organizacionales (las
metas) de las cuestiones específicas del proceso (las
preguntas). Se centra en la recolección de datos y señala que
estos datos se deben analizar de diferentes formas,
dependiendo de la pregunta que se pretenda contestar. Basili y
Green (Basili y Green, 1993) describen cómo se utilizó este
enfoque en un programa a largo plazo de mejora de procesos
basado en las mediciones.

En el método AMI de mejora de procesos del software (Pulford

et al., 1996), el enfoque GQM se desarrolló y combinó con el
modelo de madurez de la capacidad del SEI. Los desarrolladores
del método AMI proponen un enfoque de etapas para la mejora
de procesos en la que las mediciones se incluyen después de
que la organización haya introducido algún tipo de disciplina en
 sus procesos. Esto proporciona guías y consejos prácticos al
implementar la mejora de procesos basada en mediciones.
(Sommerville, 2005, p. 614).

Cuando se observan cambios en una métrica, siempre es tentador atribuir

dichos cambios a los cambios de proceso introducidos. Sin embargo, es
peligroso hacer suposiciones simplistas en lo tocante a las mejoras. Los
cambios en una métrica pueden ser causa de algo completamente diferente,
por ejemplo: un cambio del personal en el equipo de proyecto, cambios a la
calendarización del proyecto o cambios administrativos. En el caso de las
herramientas para reportar errores, algunas de las razones por las que se
observa el cambio incluyen:

1 El nuevo sistema puede tener carga reducida y, así, más tiempo

disponible para reparar bugs. Esto conduce a una reducción en los
tiempos promedios para “reparar bugs”. La mejora del proceso
pudo hacer una diferencia real.

2 El nuevo sistema tal vez no haga la diferencia con el tiempo que en

verdad se tarda en corregir los bugs, pero puede facilitar el registro
de información. Por lo tanto, los tiempos de reparación de bugs se
miden más exactamente con el nuevo sistema. No hay un cambio
real en el tiempo promedio para corregir bugs.
 3 Las mediciones antes de que el nuevo sistema se introdujera se
hicieron, tal vez, a través de las pruebas de un sistema. Los bugs
que eran más fáciles y rápidos de corregir ya se habían corregido y
sólo permanecieron los “bugs duros” que tardaban más en
repararse. Sin embargo, después de introducir el sistema de
reporte de bugs, las mediciones se hicieron al comienzo de las
pruebas del nuevo sistema. Los bugs corregidos fueron los “bugs
sencillos” que podían repararse rápidamente.

4 Un nuevo gerente del equipo de pruebas pudo instruir a los

miembros del equipo para reportar las inconsistencias de la
interfaz de usuario como bugs, mientras que antes se ignoraban.
Esto significó el reporte de muchos más “bugs sencillos” que
podían corregirse rápidamente.

La medición es una forma de generar evidencia respecto a un proceso y los

cambios de proceso. No obstante, esta evidencia tiene que interpretarse
junto con otra información sobre el proceso antes de poder estar seguros de
que son efectivos los cambios. Siempre se debe usar la medición en
conjunto con la valoración cualitativa de los cambios. Esto implica hablar con
las personas implicadas en el proceso acerca de los cambios que se
introdujeron y obtener su impresión de la efectividad de los mismos.

Esto no sólo revela otros factores que pudieron influir en el proceso, sino
también la medida en la que el equipo adoptó los cambios propuestos y
cómo éstos afectaron la práctica de desarrollo actual.
Actividades de repaso de lecturas

La mejora de procesos significa comprender los procesos existentes y

cambiarlos para incrementar la seguridad del producto y reducir los costos y
el tiempo de desarrollo.

Verdadero.

Falso.

SUBMIT

El enfoque de madurez de procesos se orienta en mejorar el proceso y la

gestión del proyecto de pruebas.

Verdadero.

Falso.
 SUBMIT

Existen factores que afectan la calidad de un software. Identifica los

factores que consideres necesarios:

Calidad del proceso.

Tecnología de desarrollo.

Calidad de personal.

Diseño del proceso.

SUBMIT

El paradigma GQM tiene relacionadas tres abstracciones. Identifica la

abstracción correcta en la siguiente lista:
Metas.

Entrevistas.

Encuestas.

Diagnóstico.

SUBMIT

C O NT I NU A R
Lección 4 de 4

Referencias

Humphrey, W. (1989). Managing the software process. Estados Unidos:

Addison-Wesley. 

Sommerville, I. (2005). Ingeniería de software. Madrid: Editorial Pearson.

C O NT I NU A R