GESTIÓN DE SOFTWARE

Grupo 11 – Mayo/2006
Retrabajo – Calidad del Software

Claudia Melo, Javier Minhondo, Saul Scanziani, Adriana Sucoff

Retrabajo

Introducción
Qué se entiende por retrabajo?
Se considera retrabajo al trabajo que se hace a causa de no haber realizado el “trabajo”
correctamente la primera ve, también se considera retrabajo los cambios continuos que se hacen y el
trabajo duplicado entre personas. La causa más frecuente de retrabajo es la necesidad de hacer
correcciones para resolver defectos o no cumplimientos de los estándares establecidos. Las
métricas de retrabajo puede ayudar al equipo de SQA a demostrar la conveniencia de mejores
planes de proyectos teniendo más cuidado y prestando mayor atención a los requerimientos.

Costo de calidad. (COQ)

SQS: Software Quality System, indice que mide la calidad del sistema.
COA: Cost of Quality, costo de recursos asignados para prevenir errores y alcanzar la calidad.
Incluye ítems como entrenamiento, implantación de metodologías, de herramientas automáticas,
planificación , desarrollo de estándares entre otros. Estos son los costos en los que se incurre por
reducir la probabilidad de que un error se haga por primera vez.
COF: Cost of Failure, Costo de recursos utilizados por que la calidad no fue alcanzada (este es el
retrabajo)

 COQ = COA + COF

La estimación de costos se da como resultado de las revisiones y testeos, son los costos en los que
incurrimos por mirar errores una vez que el producto ha sido producido.

Se incurren en costos de fallas cuando un producto manifiesta un error. Es importante reconocer que
la primera vez que se hace una revisión de un producto, o el primer test que se le hace a una pieza
de código cuanta como una estimación de costos.
Cualquier otra revisión o re testeo que se necesite por los defectos que fueron encontrados y
corregidos son parte del COF. Este es un costo en el cual no se quiere caer una vez que la tarea se
hizo correctamente la primera vez.

En la mayoría de las empresas 3/4 del costo del COQ es invertido en el COF este indicador incluye
el retrabajo.

Porque minimizar el retrabajo ?

“Los proyectos de software gastan entre el 40 y 50% de su esfuerzo en retrabajo que podría
haberse evitado...” Frase extraída del articulo “Software Defect Reduction top 10 list “ de Boehm
y Basili.
Para estos autores el retrabajo consiste en “gastar” esfuerzo en arreglar problemas que podrían
haberse detectado previamente haciendo que el “arreglo” del mismo sea menos costoso, o
directamente se podrían haber evitado. Reducir el retrabajo evitable traerá una mejora significativa
en la productividad del desarrollo de software. Según estos autores la reducción del costo de
retrabajo se logra teniendo un proceso de desarrollo maduro, una mejora en las arquitecturas del
software y gestión de riesgos

“80% del retrabajo evitable viene del 20% de defectos....”

Este 80% puede ser un valor alto o bajo dependiendo del tamaño del sistema que se esta
desarrollando. Uno de los puntos que llevan a este problema es hacer especificaciones de
requerimientos a las corridas y un diseño no muy claro hace que la arquitectura no sea bien definida
lo que traerá problemas al momento de la codificación.

El tener un sistema que permita hacer el seguimiento de los defectos y los arreglos que se llevan
hechos ayudan a hacer un análisis de los problemas y saber el costo del esfuerzo que se ha incurrido
en retrabajo.

Actividades de SQA y SCM

Como ya se definió al principio el esfuerzo de retrabajo tiene tres perspectivas:
 Tareas que se ejecutaron incorrectamente
 Tareas nuevas por cambios continuos de un proyecto
 Tareas duplicadas por mala gestión de los documentos/productos compartidos

Vamos ahora a vincular estas visiones del retrabajo con los roles de SQA y SCM en un proyecto de
software, los cuales son directamente responsables de minimizar el esfuerzo en retrabajo. A
continuación se describirán solo algunas actividades de estas dos disciplinas, mas adelante en este
documento se ampliará sobre los factores y las medidas generales a tomar en proyectos de
ingeniería de software.

Actividades del SCM: Definición y Seguimiento de la Línea Base + Control de Cambios

El cambio es inevitable cuando se construye software. Los procesos de desarrollo intentan ser cada
vez más rápidos. Procesos lentos impactan produciendo perdida de oportunidades de negocio, los
mercados cambian, las demandas de los clientes cambian y la competencia cambia rápidamente. Es
fundamental la gestión de estos cambios para que se den en forma ordenada y consistente. Una
responsabilidad del SCM es administrar un protocolo de aprobación y reporte de cambios a los
interesados. Dado un alcance negociado y validado pueden surgir tareas de retrabajo por
modificaciones (en requerimientos, diseño,...) durante la implementación. Además, si se introducen
defectos al producto por no haber evaluado el impacto de un cambio también estaremos incurriendo
en “retrabajo” por corrección de errores.

La Gestión de Configuración permite, entre otras cosas, identificar claramente las versiones
“activas” de un producto. Es una práctica común mantener el entorno de desarrollo de la versión
actual, mientras se trabaja en una nueva versión. Esto permite planes de contingencia ante
eventuales fallas de la versión en uso, corrigiendo el error (parches) y comunicándolo al grupo de
desarrollo de la nueva (futura) versión. No prever esta situación es un factor importante de
retrabajo que exigiría un gran esfuerzo para el equipo de desarrollo.
En un proyecto de software muchas personas interactúan con elementos comunes, compartidos o
muy relacionados. Podemos interpretar que el “retrabajo” es el polo opuesto al “reuso” y en tal
sentido si la línea base de un proyecto esta bien definida esto nos da la pauta para poder construir,
avanzar sobre esos cimientos, las nuevas funcionalidades de un sistema. Por el contrario, si la línea
base es difusa puede ocurrir que algunos integrantes del equipo trabajen sobre diferentes versiones
de los documentos o prototipos, siendo esta la tercer perspectiva de desperdicio de recursos en
retrabajo.

Actividad del SQA: Revisión Técnica Formal o Inspecciones Formales

Un defecto es una desviación en el valor esperado para una determinada característica. Una
inspección formal de software es un proceso de detección y eliminación de defectos, y verificación
de su corrección, en un producto de software. Su objetivo es asegurar la temprana detección y
corrección de errores.
Las inspecciones se enmarcan dentro de las pruebas estáticas (sin uso de computadora) del
software. Son planificadas, preparadas, luego se ejecutan (reunión), se obtiene un conjunto de
funcionalidades a corregir (retrabajo) y mas adelante se hace una reinspección para chequear que
los defectos ya no están presentes.
En este proceso se introduce formalmente como actividad el “retrabajo”, el cuál será registrado
como tal en el informe de la inspección y finalmente aportará un índice para medir el esfuerzo
insumido.

Por ultimo podemos ver que estos dos roles (SCM y SQA) caben en el área de “Gestión” y ya se ha
mencionado en este curso que fracasan mas proyectos de software que los que resultan exitosos y
las causas de fondo casi nunca son de carácter técnico, sino de gestión. El retrabajo es tal vez uno
de los factores que inciden en dichos fracasos y a su vez SCM y SQA son roles desatendidos que
originan estas situaciones.

Retrabajo en PIS y CMM

La idea de esta sección del documento es mostrar los factores del retrabajo en el PIS. Para ello
primero debemos entender el modelo de proceso de desarrollo de software seguido. Por esta razón
primero se da un breve pantallaza de las actividades llevadas a cabo en cada una de las fases del
proceso.

Fase inicial: Se hace hincapié en:

 La obtención de requerimientos
  Del entendimiento y factibilidad del proyecto
 El entendimiento del proceso de desarrollo

Fase de elaboración: Se hace hincapié en:

 La obtención de requerimientos
 Definir el alcance del proyecto
 Identificar los principales riesgos para la elaboración del producto

Fase de construcción: Se hace hincapié en:

 Acuerdo definitivo del alcance
 Implementación del producto

Fase de transición: Se hace hincapié en:

 Terminar el producto
 Capacitar al cliente
 Instalar la aplicación
 Pruebas en un ambiente de producción

Ahora que tenemos una idea del modelo de proceso adoptado en el PIS, podemos identificar los
factores que influyen en el retrabajo, identificar las medidas que podemos adoptar para evitar caer
en retrabajo e inclusive podemos definir como medir el esfuerzo en el cual incurrimos.
En la mayor parte de los procesos de desarrollo de software sucede que uno de los factores más
cambiantes son los requerimientos. El PIS no es una excepción. En primer lugar, el cliente no
siempre tiene claro que es lo que quiere, y si tiene claro lo que quiere no siempre sabe priorizar los
requerimientos. Si a esto le sumamos la poca experiencia de los alumnos en la toma de
requerimientos en proyectos de mediano porte, obtenemos una combinación explosiva.
Para obtener una versión considerablemente estable de los requerimientos se debe esperar
generalmente hasta la semana 6 (Fase Elaboración, Iteración 1). En paralelo, ya a partir de la
semana 4 (Fase Inicial, Iteración 2) se debe construir un prototipo que contemple aquellos aspectos
del producto que pueden ser riesgosos para la construcción del producto. Si luego de construido el
prototipo, los requerimientos cambian dramáticamente o se deja fuera del alcance el o los
requerimientos que daban lugar al prototipo, la construcción del mismo habrá sido en vano. En este
caso se puede dar el caso que haya que construir un nuevo prototipo para cubrir otros aspectos de
los requerimientos.
Dejando de lado la construcción del prototipo, es normal que inclusive luego de haber llegado a
acuerdo respecto al alcance del producto, y luego de que se realice la especificación final de los
requerimientos, el cliente y el grupo de desarrollo decidan incluir algún requerimiento que se había
dejado de lado, y por ende se deberán retocar no solo los fuentes que componen el producto sino
también toda la documentación necesaria.
Los requerimientos no son el único factor de retrabajo. Una mala gestión de la configuración puede
ser un factor clave en el retrabajo. La mala administración tanto de fuentes como de documentos
puede hacer que los mismos se pierdan o que los distintos integrantes del grupo trabajen sobre
versiones desactualizadas. Si esto sucede será necesario que se vuelvan a reconstruir todos los
componentes perdidos. De la misma manera, se deberá reconstruir toda la información perdida por
desincronización de los documentos.
Por último, otro factor que generalmente no es tenido en cuenta son las instalaciones de versiones
intermedias para las presentaciones. Si no se cuenta con un software instalador del producto, el
grupo puede incurrir en un gran esfuerzo para instalar los diferentes prototipos. Dado que hay varias
instancias de presentación del producto al cliente, el esfuerzo que toma la instalación no es para
nada despreciable.
Ahora que tenemos algunos de los factores que aportan al retrabajo, podemos buscar herramientas o
metodologías para poder registrar, medir y analizar el esfuerzo incurrido por tener que repetir
actividades que ya han sido efectuadas y que no aportan al avance del proyecto.
Para esto separamos las metodologías según el factor:
 Requerimientos:
o Dada la naturaleza cambiante de los requerimientos es poco lo que podemos hacer de
antemano para poder evitar el retrabajo. Pero si podemos registrar (ya sea en una
planilla o en una pequeña base de datos) cada uno de los incidentes que se den
debido a esto. Así podremos saber los diferentes motivos por los cuales fue necesario
volver a realizar actividades que ya se habían hecho, y la cantidad de veces que se
realizó la actividad. A su vez podemos registrar la cantidad de tiempo que nos llevó
rehacer la actividad.
o Luego de finalizado el proyecto, se podrá llevar a cabo por parte de los docentes un
análisis post mortem del mismo, e identificar las diferentes causas del retrabajo, el
esfuerzo que esto le insume a los grupos y las medidas de prevención que deben
realizar los alumnos.
 Gestión de la configuración:
o En este punto son mayores las medidas que podemos adoptar para evitar el retrabajo
derivado de una mala gestión. Si define un plan de gestión de forma correcta, si se
comunica al resto de los integrantes del grupo, si se auditan los elementos
administrados con regularidad, si se marca la línea base, se respaldan los elementos
que componen al producto (fuera del repositorio) y si se hace gestión del cambio, es
muy difícil que la gestión de configuración sea causante de retrabajo.
o De todas formas, si igual se dan incidentes, podemos adoptar la misma medida que
en el caso anterior.
 Instalaciones:
o Si el producto a construir es adecuado y si se adopta desde un primer momento una
política de versionado de prototipos con sus respectivos instaladores, se puede evitar
incurrir en retrabajo. Si no se construye un instalador, puede ser interesante crear una
suerte de manual de instalación (por lo menos para uso interno) que indique todos los
pasos a seguir para instalar el producto.
o Si ninguna de las dos medidas es adoptada como prevención, podemos registrar cada
uno de las veces que fue necesario instalar el producto, el tiempo que insumió y las
dificultades técnicas que se encontraron.
Caso de estudio
Presentación de herramienta que ayuda a grupos de trabajo alcanzar proactivamente calidad en
productos y procesos de software, IBM Rational.
Basado en paper: The business value of software quality
Geoffrey Bessin, Market Mannager, Software Quality Products, IBM Rational
Link http://www-128.ibm.com/developerworks/rational/library/4995.html

Se plantea que organizaciones exitosas en el desarrollo de software que han asumido compromiso
para alcanzar un buen nivel de calidad, han encontrado en la práctica que una provoca desarrollos
más rápidos, reduce costos y permite agregar nuevas características con mayor facilidad. La
organización que construye apuntando a la calidad desde el comienzo puede ir más allá, capaz de
innovar y perseguir nuevas oportunidades.
Las organizaciones tienen que hacer más que manifestar su interés en la calidad, necesitan proveer
herramientas, procesos, guías y entrenamiento para alcanzar los resultados que los gerentes, clientes
y usuarios están buscando. La mejora de la Calidad es como el desarrollo de software, es un proceso
iterativo, como primer paso el convencimiento de la alta gerencia, es necesaria, luego el grupo de
herramientas IBM Rational ayudará a el equipo a ser más eficaz no solo encontrando bugs, sino que
creando previsibilidad, mayor calidad, menor costos y clientes más satisfechos.
IBMRational ha desarrollado software y soluciones de desarrollo que ayuda a equipos a innovar y
obtener mayores resultados de calidad simplificando, automatizando e, integrando el desarrollo de
software e implementación del proceso.
Se plantea la calidad según James Juran: “fitness for use” (aptitud para el uso)
La calidad agrega valor al consumidor y al productor, alta calidad en procesos significa que no se
perderá tiempo en retrabajo, rehaciendo o reescribiendo.
Se tiene atención el transcurso de la implantación, integración y testing.

MODOS DEL DESARROLLO DEL SOFTWARE

Hay muchas razones para el alto costo de tener baja calidad, por ejemplo pobre análisis de dominio
del problema, pobre análisis de requerimientos derivan en un no considerado costo en retrabado.

Las fases iterativas de RUP enfatizan en una o más disciplinas del proceso de base, análisis, diseño,
codificación, testing e implantación. En cada fase y cada disciplina se enfatiza la atención en la
calidad para identificar problemas tempranamente dentro del ciclo de vida, que es cuando son más
fáciles de resolver.
Disciplinas de proceso en RUP
Análisis
Grupos de reportes para presentar a los clientes, con el fin de verificación.
IBM Racional RequisitePro es la herramienta para gestión de requerimientos, permite el ingreso de
requerimientos de una forma clara (para clientes e implementadores) y tiene capacidades analíticas
en bases de datos, para realizar el análisis de los requerimientos.
Diseño
Principal punto que ataca es la arquitectura, en esta área el costo de corregir defectos, crece
exponencialmente.
IBM Racional Rose XDE permite a diseñadores manejar la complejidad creando modelos
tecnológicos independientes con UML (Unified Modeling Language)
Desarrollo
Errores de código es costoso no solo por el tiempo en corregirlos sino por el tiempo que se gasta en
encontrarlos.
IBM Racional Purify Plus es un set de rutinas de análisis automatizadas para mejorar la
confiabilidad y performance.

Test
Testers usan IBM Rational Robot para crear, modificar y ejecutar test funcional automatizado, test
funcional distribuido y test de regresión.
IBM Racional Performance Tester es usado para medir la escalabilidad y confiabilidad bajo casos
del mundo real, simulando usuarios interactuando con la aplicación.

Monitoreando, Supervisando
IBM Tivoli Monitoring provee monitoreo recursos de sistema esenciales, para detectar cuellos de
botella errores potenciales, y permite ver la recuperación automática en situaciones críticas.

Responsabilidad del Equipo

El equipo debe hacer todo lo que pueda para integrar workflows, establecer trasablidad y especificar
comunicación. Un quiebre en la cadena que une al equipo puede derivar en pérdida de información,
retrabajo, falta de claridad e ineficiencia, finalmente deriva en una baja calidad del software.
IBM Rational Team Unifying Plataform es una infraestructura integrada de herramientas y
procesos que unifica a equipos de desarrollo brindando acceso común a los activos(assets) el
componente IBM Racional ClearCase se asegura que estos activos están protegidos, alarmas de
comunicación, y procesos de workflow.

Varias demos de la aplicación:

http://www3.software.ibm.com/ibmdl/pub/software/rational/web/demos/

IBM Racional ClearCase ejemplo versionado

Imágenes de la demo:
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/demos/clearcase/assetmgmt/cc_de
mo.html
Conclusiones

- En la mayoría de los proyectos de software entre el 40 y 50 % del esfuerzo se debe al

retrabajo
- En la mayoría de las empresas ¾ del C.O.Q. es a causa del C.O.F. (COQ = COA + COF)

- COF es un costo que se quiere evitar

- Las métricas de Retrabajo son índices que permiten a los SQA demostrar la conveniencia
de mejorar y ajustarse a los planes y estándares adoptados

- En la mayor parte de los proyectos, se incurre en esfuerzo por retrabajo debido a

problemas de gestión y no en problemas técnicos
- Roles fundamentales en la gestión para minimizar el impacto:
SQA
SCM
Administrador

- Para medir el esfuerzo:

Necesitamos una herramienta para el seguimiento de las actividades
Registramos el tipo de la actividad, una descripción y el tiempo que nos tomó la tarea

- Estamos en condiciones de analizar la información y poder entonces medir el esfuerzo

que nos lleva el retrabajo.

- Ejemplos de herramientas:
Rational
Project
Jira
Y más …