Calidad Del Software

INTRODUCCI~N AL PROCESO SOFTWARE PERSONALsM
CONSULTORES EDITORIALES:
SEBASTIN DORMIDO BENCOMO Departamento de Informtica y Automtica UNIVERSIDAD NACIONAL DE EDUCACI~NISTANCIA AD LUIS JOYANES AGUILAR Departamento de Lenguajes, Sistemas Informticos e Ingeniera del Software UNIVERSIDAD PONTIFICIA DE SALAMANCA en Madrid
INTRODUCCIN AL PROCESO SOFTWARE PERSONALsM

WATTS S. HUMPHREY
CARNEGIE MELLON UNIVERSITY
Traduccin: Javier Zapata Martnez Universidad de Murcia Coordinador de la traduccin: Jess Garca Molina Universidad de Murcia Revisin Tcnica: Jos Antonio Cerrada Somolinos Universidad Nacional de Educacin a Distancia
Madrid Mxico Santaf de Bogot Buenos Aires Caracas Lima Montevideo San Juan San Jos Santiago Sao Paulo Reading, Massachussetts Harlow, England
Datos de catalogacin bibliogrfica
Humphrey W S. . Introduccin al Pmmo Sofiware PersonalSM PEARSON EDUCACIN, S.A., Madrid, 2001
ISBN 84-7829-052-4
Materia: Informtica: 681.3 Formato: 170 x 240 Pginas: 328
Watts. S. Humphrey
Introduccin al Proceso Software Personal M
No est permitida la reproduccin total o parcial de esta obra ni su tratamiento o transmisin por cualquier medio o mtodo sin autorizacin escrita de la Editorial. DERECHOS RESERVADOS O 2001 respecto a la pqmera edicin en espaol por: PEARSON EDUCACION, S.A. Nez de Balboa, 120 28006 Madrid
JSBN: 84-7829-052-4 Depsito Legal: M- Impreso por: Sprint, S.L.

ADDISON WESLEY es un sello editorial autorizado de PEARSON EDUCACIN, S. A.
Traducido de: Introduction to the Personal Software ProcesssM,First Edition by Watts Humphrey O 1997, por Pearson Education, S. A. ISBN: 0-201-54809-7 Edicin en espaol: Equipo editorial: Editor: Andrs Otero Asistente editorial: Ana Isabel Garca Equipo de produccin: Director: Jos A. Clares Tcnico: Jos A. Hernn Diseo de cubierta: Mario Guindel y Yann Boix Composicin; DiScript Preimpresin, S. L. Impreso Por: Depsito Legal: M-28.980-2001'
IMPRESO EN ESPAA - PRINTED IN SPAIN
Este libro ha sido impreso con papel y tintas ecolgicos
A BRBARA Mi amo< mi esposa, mi vida
Contenido
Prlogo de los profesores Prlogo de los estudiantes Prlogo

1
xv
XIX
XXI
f
1 2 2 3 4
4 5
El trabajo del ingeniero del software

1.1 Qu es la ingeniera del software?................................................. 1.2 Por qu es importante una buena ingeniera?................................ 1.3 El proceso personal del software .................................................... 1.4 La disciplina del trabajo de alta calidad .......................................... 1.5 La importancia del trabajo de alta calidad ...................................... 1.6 Cmo mejorar la calidad de tu trabajo? ........................................ 1.7 El proceso de mejora ....................................................................... 1.8 El objetivo de este libro .................................................................. Resumen ..................................................................................................... Ejercicio 1................................................................................................... Referencia ...................................................................................................
6
7
8 8
2
2.1 2.2 2.3
La gestin del tiempo

La lgica de la gestin del tiempo .................................................. Comprende cmo utilizas el tiempo ................................................ El cuaderno de ingeniera................................................................
9
9 11 12
Vlll
CONTENIDO
2.4 El diseo del cuaderno .................................................................... 2.5 Ejemplos de cuadernos de ingeniera .............................................. Resumen ..................................................................................................... Ejercicio 2 ...................................................................................................
12 14 16 16
El control del tiempo

3.1 Por qu controlar el tiempo? ......................................................... 3.2 El registro de los datos de tiempos.................................................. 3.3 El control del tiempo ....................................................................... 3.4 El uso de una tabla de registro de tiempos normalizada ................. 3.5 La gestin de las interrupciones...................................................... 3.6 El control de las tareas finalizadas .................................................. 3.7 Cmo mantener la tabla de tiempos en el cuaderno de ingeniera? .. 3.8 Ideas para registrar tu tiempo .......................................................... Resumen ..................................................................................................... Ejercicio 3 ...................................................................................................
17
17 18 19 20 22 24 25 25 27 27
Planificacin de perodos y productos

4.1 Planes de perodos y productos ....................................................... 4.2 El resumen semanal de actividades................................................. 4.3 El resumen de los tiempos semanales ............................................. 4.4 Clculo de los tiempos y medias del perodo .................................. 4.5 La utilizacin del resumen semanal de actividades ........................ Resumen ..................................................................................................... Ejercicio 4 ...................................................................................................
29
29 31 33 35 38 41 41
La planificacin del producto

5.1 La necesidad de los planes del producto ......................................... 5.2 Por qu son tiles los planes del producto ...................................... 5.3 Qu es un plan del producto? ........................................................ 5.4 La planificacin del producto en este libro ..................................... La planificacin de pequeos trabajos ............................................ 5.5 5.6 Algunas definiciones....................................................................... 5.7 El Cuaderno de Trabajos ................................................................. 5.8 Algunas sugerencias sobre cmo utilizar el Cuaderno de Trabajos .. La utilizacin de tiempos y medias del producto ............................ 5.9 Resumen ..................................................................................................... Ejercicio 5 ...................................................................................................
43
43 44 45 45 46 46 46 49 54 55 55
INTRODUCCIN AL PROCESO SOFTWARE PERSONAL
IX
6
6.1 6.2 6.3
El tamao del producto

El proceso de planificacin del producto ........................................ Medida del tamao .......................................................................... Algunas precauciones sobre la utilizacin de las medidas de tamao ........................................................................................ 6.4 El tamao de un programa .............................................................. 6.5 Otras medidas del tamao ............................................................... 6.6 La estimacin del tamao del programa ......................................... 6.7 Cmo hacer estimaciones de tamaos mayores .............................. 6.8 Cmo utilizar medidas de tamao en el Cuaderno de Trabajos ...... Resumen ..................................................................................................... Ejercicio 6...................................................................................................
57
57 58 58 59 62 62 64 65 69 71

Elementos de la gestin del tiempo ................................................. 7.1 La clasificacin de las actividades .................................................. 7.2 La recogida de datos sobre el tiempo dedicado a cada actividad .... 7.3 Cmo evaluar tu distribucin del tiempo ........................................ 7.4 Cmo hacer una estimacin de tiempo ........................................... 7.5 Cmo encontrar ms tiempo ........................................................... 7.6 Cmo establecer reglas bsicas ....................................................... 7.7 Cmo priorizar tu tiempo ................................................................ 7.8 La gestin del tiempo estimado ...................................................... 7.9 7.10 Sugerencias para la gestin del tiempo variable ............................. 7.1 1 Tu objetivo en la gestin del tiempo ............................................... Resumen ..................................................................................................... Ejercicio 7 ...................................................................................................
73
13 74 74 74 75 77 77 79
82 84 85 85 86
La gestin de los compromisos

8.1 Definicin de compromiso .............................................................. 8.2 Responsabilidad para hacer compromisos ...................................... Ejemplo de un compromiso ............................................................ 8.3 Un ejemplo en la industria .............................................................. 8.4 La gestin de compromisos no conseguidos ................................... 8.5 La importancia de gestionar compromisos ..................................... 8.6 Las consecuencias de no gestionar los compromisos ..................... 8.7 La forma de gestionar compromisos ............................................... 8.8 Resumen ..................................................................................................... Ejercicio 8...................................................................................................
87
87 89 90 91 92 93 94 95 96 96
CONTENIDO
La gestin de las programaciones

9.1 La necesidad de las programaciones ............................................... 9.2 El diagrama de Gantt....................................................................... 9.3 Cmo hacer una programacin de un proyecto .............................. 9.4 Puntos de control ............................................................................. 9.5 El seguimiento de los planes de los proyectos ................................ 9.6 El seguimiento del valor conseguido .............................................. Resumen ..................................................................................................... Ejercicio 9................................................................................................... Referencias .................................................................................................
99
99 100 101 103 105 108 112 112 112
El plan del proyecto

10.1 La necesidad de los planes de los proyectos ................................... 10.2 El Resumen del Plan del Proyecto .................................................. 10.3 El Resumen ..................................................................................... 10.4 El tamao del programa .................................................................. 10.5 El tiempo en Fases .......................................................................... 10.6 Cmo estimar con exactitud ............................................................ Resumen ..................................................................................................... Ejercicio 10................................................................................................. Referencias .................................................................................................
3
113 114 116 117 120 122 122 122 123
El proceso de desarrollo del software

11.1 Por qu utilizamos los procesos ...................................................... 11.2 Algunas definiciones ....................................................................... .. 11.3 El guion del proceso ........................................................................ 11.4 Puntos de control y fases ................................................................. 11.5 Actualizacin de la tabla Resumen del Plan del Proyecto .............. 11.6 Un ejemplo de planificacin ........................................................... 11.7 Un ejemplo para calcular los datos hasta la fecha .......................... Resumen ..................................................................................................... Ejercicio 11................................................................................................. Referencia...................................................................................................
125
125 126 127 129 130 132 135 138 138 139
Defectos
12.1 Qu es la calidad del software? ..................................................... 12.2 Defectos y calidad ........................................................................... 12.3 Qu son los defectos? ....................................................................
4
141 142 143
INTRODUCCINAL PROCESO SOFTWARE PERSONAL
XI
12.4 Defectos versus bugs ....................................................................... 12.5 Tipos de defectos ............................................................................. 12.6 La comprensin de los defectos ...................................................... 12.7 El cuaderno de registro de defectos ................................................ 12.8 La contabilizacin de los defectos .................................................. 12.9 La utilizacin del cuaderno de registro de defectos ........................ 12.10 El proceso del PSP actualizado ....................................................... Resumen ..................................................................................................... Ejercicio 12................................................................................................. Referencias .................................................................................................
144 146 147 148 153 154 155 159 161 161
3
13.1 13.2 13.3 13.4 13.5 13.6 13.7 13.8 13.9 13.10
Encontrar defectos
Un compromiso personal con la calidad ......................................... Los pasos para encontrar defectos .................................................. Formas de encontrar y corregir defectos ......................................... La revisin del cdigo ..................................................................... Por qu hay que encontrar pronto los defectos ? ........................... El coste de encontrar y corregir defectos ........................................ El uso de las revisiones para encontrar defectos ............................. Revisar antes de compilar ............................................................... Datos sobre defectos de compilacin y pruebas ............................. Actualizacin de la tabla Resumen del Plan del Proyecto del PSP ............................................................................................ 13.11 Otras clases de revisiones ................................................................ Resumen ................ .r ................................................................................... Ejercicio 13................................................................................................ Referencias .................................................................................................
63
163 163 164 166 167 167 169 170 172 174 174 178 180 180
Listas de comprobacin para la revisin del cdigo

14.1 Por qu ayudan las listas de comprobacin? ................................. 14.2 Un ejemplo de lista de comprobacin para la revisin de cdigo ... 14.3 Utilizacin de una lista de comprobacin para la revisin de cdigo ......................................................................................... 14.4 La elaboracin de una lista de comprobacin personal .................. 14.5 La mejora de la lista de comprobacin ........................................... 14.6 Estndares de codificacin .............................................................. Resumen ..................................................................................................... Ejercicio 14.................................................................................................
83
183 184 187 188 194 196 197 200
XII
CONTENIDO
15
15.1 15.2 15.3 15.4 15.5 15.6
La previsin de defectos
El porcentaje de defectos ................................................................ La utilizacin de los datos de defectos............................................ Densidad de defectos ...................................................................... Cmo estimar las tasas de defectos ..............: .................................. Estimacin de defectos.................................................................... Actualizacin y ejemplo de la tabla Resumen del Plan del Proyecto ..................................................................................... 15.7 La anotacin de los datos reales ...................................................... Resumen ..................................................................................................... Ejercicio 15................................................................................................. Referencia ...................................................................................................
201
201 203 204 204 205 207 212 214 215 215
16
16.1 16.2 16.3 16.4 16.5 16.6
La economa de eliminar defectos

La necesidad del trabajo de calidad ................................................ El problema de eliminar defectos.................................................... El tiempo de eliminar defectos........................................................ Experiencia en la introduccin y eliminacin de defectos .............. Ahorro en la eliminacin de defectos ............................................. El clculo de los DefectoslHora en el Resumen del Plan del Proyecto del PSP ............................................................................. 16.7 El clculo del rendimiento en el Resumen del Plan del Proyecto ... 16.8 La mejora de las tasas de eliminacin de defectos .......................... 16.9 La reduccin de las tasas de introduccin de defectos .................... Resumen ..................................................................................................... Ejercicio 16................................................................................................. Referencias .................................................................................................
21 7
217 218 219 219 221 223 225 229 230 231 232 232
$7
Defectos de diseo
17.1 La naturaleza de los defectos de diseo .......................................... 17.2 Identificacin de los defectos de diseo.......................................... 17.3 Qu es disear? .............................................................................. 17.4 El proceso de diseo ....................................................................... 17.5 Las causas de los defectos del diseo ............................................. 17.6 El impacto de los defectos de diseo .............................................. 17.7 Representacin del diseo ............................................................... Resumen ..................................................................................................... Ejercicio 17................................................................................................. Referencias .................................................................................................
233
233 235 235 236 237 238 239 244 245 246
Xlll
18
Calidad del producto

18.1 La calidad viene primero ................................................................. 18.2 Las pruebas ..................................................................................... 18.3 El filtro de las pruebas ..................................................................... 18.4 Los beneficios del trabajo cuidadoso .............................................. 18.5 El clculo de los valores de rendimiento ......................................... 18.6 La estimacin del rendimiento definitivo ........................................ 18.7 Los beneficios de un rendimiento de proceso del 100%................. 18.8 Experiencia del rendimiento ........................................................... 18.9 Prototipado ...................................................................................... Resumen ..................................................................................................... Ejercicio 18................................................................................................. Referencia ...................................................................................................
247
247 248 249 251 251 254 256 257 258 258 259 259
19
La calidad del proceso

19.1 Medidas del proceso ........................................................................ 19.2 La paradoja de la eliminacin de defectos ...................................... 19.3 Una estrategia para la eliminacin de defectos ............................... 19.4 El coste de la calidad ....................................................................... 19.5 Clculo del coste de la calidad ........................................................ 19.6 La relacin ValoracidFallos .......................................................... 19.7 Cmo mejorar las tasas de revisin ................................................. 19.8 Clculo del verdadero Coste de Calidad ......................................... Resumen ..................................................................................................... Ejercicio 19.................................................................................................
261
261 262 263 264 265 267 273 275 276 277
20
Un compromiso personal con la calidad

20.1 La importancia de la calidad ........................................................... 20.2 El aumento del riesgo asociado a la poca calidad ........................... 20.3 Cmo hacer un compromiso con la calidad .................................... 20.4 Tus objetivos personales ................................................................. 20.5 Las recompensas del logro .............................................................. Referencia ...................................................................................................
279
279 280 282 282 283 284
ndice analtico Pginas suplementarias
285
293
Prlogo de los profesores
Nosotros utilizamos un borrador de este libro para ensear los principios de los procesos en el primer curso del programa de Informtica, en la Universidad Aeronutica de Embry-Riddle. El libro proporciona un subconjunto de los elementos y actividades del Proceso Software Personal (PSP)SM,acrnimo de Personal Software Process, que un estudiante de primer ao puede fcilmente asimilar junto con los temas ms tradicionales del primer ao de programacin. Este libro tambin proporciona la motivacin y una estructura para introducir a los estudiantes en prcticas personales disciplinadas. Hemos disfrutado utilizando este libro y comprobado cmo ayuda a nuestros estudiantes, para llegar a ser profesionales competentes del software. Durante aos, hemos estado intentando proporcionar a nuestros estudiantes experiencias reales de ingeniera del software. Hemos tenido un xito moderado con la introduccin de la teora y prctica de la ingeniera del software al principio del currculum, y aadiendo proyectos en equipo en cursos superiores. Desafortunadamente, hemos encontrado que cuando los estudiantes trabajan en estos proyectos, no entienden la gestin del tiempo, la planificacin y la gestin de la calidad. La industria encontr que la capacidad de los equipos de ingeniera para desarrollar productos software de calidad de una forma eficiente y eficaz, dependa en gran parte de la capacidad individual de los ingenieros. Reflexionando sobre ello, los problemas de los estudiantes con la gestin del tiempo y de la calidad no nos sorprendieron ya que no se les haba dado cursos sobre cmo planificar y gestionar su trabajo. Decidimos intentar introducir los conceptos sobre procesos al comienzo del plan de estudios universitarios.
SM Personal Software Process y PSP son marcas registradas de la Universidad de Camegie Mellon.
XVI
PRLOGO DE LOS PROFESORES
Observamos que los estudiantes de primer curso podan aprender mejor y beneficiarse ms directamente de las prcticas de gestin del tiempo, por ello comenzamos introduciendo del Captulo 1 al Captulo 10 de este libro asignaturas del CS1. Aunque todos los estudiantes que accedieron a nuestros cursos del CS 1 tenan alguna experiencia en programacin, no estaban an preparados para un proceso de desarrollo de software formalmente definido. Necesitaban enfrentarse antes a los problemas de desarrollo de software para que pudieran comprender los papeles y prcticas de los ingenieros de software. Despus de finalizar el CS1 y completar su primer semestre, los estudiantes estaban preparados para desarrollar programas de una forma ms disciplinada. Entonces introdujimos el proceso PSP en el CS22, utilizando el material de los Captulos 11 al 20. Aqu, el estudiante planific cada uno de sus proyectos de programacin. Siguiendo las prcticas definidas en el PSP, utilizaron sus propios datos histricos para estimar el tamao, el esfuerzo y la calidad (estimacin de defectos). Tambin reunieron y registraron los datos reales de cada proyecto en una tabla resumen. Despus de un ao de experiencia, hemos encontrado que el enfoque de introducir las actividades de los procesos en los primeros cursos de CS, permite trabajar a los estudiantes. Con permite trabajar queremos decir que los estudiantes pueden aprender cmo utilizar los procesos tratados en este libro. Con el tiempo ven el valor de registrar los datos de esfuerzo, tamao y calidad, y pueden utilizar estos datos en la planificacin de proyectos y analizar su efectividad personal. La recogida de datos de su propio trabajo les da unas bases cuantitativas para la estimacin. Regularmente realizan revisiones estructuradas y aprenden las fases de desarrollo definidas en su trabajo (por ejemplo, planificacin, diseo, codificacin, compilacin, pruebas y postmortem). Tambin observamos que el retraso en la introduccin del PSP para otro semestre ( o ao) llevara consigo que los alumnos adquiriesen prcticas de programacin descuidadas e indisciplinadas bien arraigadas y seran ms resistentes u1 cambio. El PSP ha ayudado a los estudiantes a entender la importancia de un enfoque disciplinado al desarrollo del software. Tambin proporciona un fundamento ms riguroso para la posterior introduccin de cuestiones ms avanzadas de tipo individual y de equipo. La mayor parte de los datos de los estudiantes son exactos, pero hay que ser cuidadoso al analizar y rechazar los datos sospechosos. Desafortunadamente, los estudiantes no
Asignatura de programacin del primer semestre del primer curso en los currcula USA (N. del T.). Asignatura de programacin del segundo semestre del primer curso en los currcula USA (N. del T.).
XVll
mejoraron en la planificacin de su trabajo. Muchos aplazaron sus ejercicios hasta que no tuviesen los datos adecuados: problema perpetuo en los inicios de los programadores.
No fue sorprendente descubrir que el xito de la tcnica del PSP dependa en gran medida de nuestra capacidad para motivar a los estudiantes a aprender y practicar estos conceptos. Utilizamos las ideas y argumentos de este libro para animar a tener una visin positiva de los mtodos del proceso. Observamos, que facilitando la retroalimentacin en la clasificacin y anlisis de los datos, se estimulaba a los estudiantes a interesarse en mayor medida por sus datos personales. Tambin fue til invitar a los profesionales de la industria a discutir en clase sus experiencias en los procesos.
Hubo algunos problemas al comenzar la enseanza en los nuevos cursos. Inicialmente, no tenamos suficientemente integradas las materias del PSP con el resto de materias de CS I y CS2. Los estudiantes tuvieron problemas al relacionar las actividades de gestin del tiempo con sus trabajos de programacin. Nosotros tambin fallamos en proporcionarle suficiente retroalimentacin en los datos acumulados de las clases. Un efecto interesante y beneficioso del PSP fue la gran cantidad de datos suministrados al profesor. En el CS 1 hacemos resmenes semanales de actividades sobre como los estudiantes gastan su tiempo en el curso. En el CS2 hacemos un resumen del PSP sobre cada proyecto de programacin y obtenemos datos de tamao, esfuerzo y defectos. A menudo estos datos provocan discusiones sobre los mtodos enseados en el curso y cmo afectan a la productividad del programador y a la calidad del programa. El PSP proporciona una base cuantitativa para el anlisis y discusin de dichas cuestiones. Continuamos enseando el PSP a los estudiantes del primer ao de nuestro programa. Tambin requerimos a los estudiantes que han completado el CSl y el CS2 a que utilicen el PSP en los cursos de algoritmos y estructuras de datos que siguen al CS2. Creemos que estarn mejor preparados para trabajar en equipos de proyectos complejos en su futuro profesional. Tambin pretendemos orientar a los estudiantes a extender y mejorar el PSP en cursos posteriores. Hemos encontrado este libro t i l para introducir a nuestros estudiantes en la disciplina del software profesional y esperamos que otros estudiantes y profesores que utilicen este libro tengan experiencias similares a la nuestra. Thomas B. Hilburn, Aboalfazl Salimi, Massood Towhidnejad Universidud Aeronuticu de Enzbry-Riddle
Prlogo de los estudiantes
Despus de acabar el curso del PSP en el primer ao, los profesores de la facultad de la Universidad Aeronutica de Embry-Riddle nos preguntaron si nos gustara colaborar en la redaccin del prlogo del libro de texto. Nosotros aceptamos. Puesto que no sabamos cmo escribir un prlogo, nos sugirieron que sencillamente respondisemos a algunas preguntas. He aqu las preguntas y las respuestas:
1. Qu tipo de tareas hicisteis en el curso del PSP?
Registramos todo el tiempo que dedicbamos a los ejercicios de programacin y a los proyectos. Haba mucha documentacin. Tambin registramos el tamao del programa y los defectos cometidos, y utilizamos los datos recogidos para estimar el tiempo, el tamao y los defectos de futuros proyectos.
2. Cmo hicisteis el trabajo? Cmo adaptasteis este material a los materiales de los otros cursos?
Lo adaptamos bien al trabajo del curso, y disponiendo de una estimacin nos ayud a coger confianza en lo que estbamos haciendo.
Al principio, parece que el trabajo del PSP es un obstculo a los otros trabajos del curso, pero una vez que llegas al final del curso, te das cuenta de que estas actividades realmente te ayudan a completar tu trabajo. Al avanzar el curso te preguntas: "por qu estoy haciendo esto?', pero ms tarde comienzas a ver que disponer de una estimacin de lo que ests haciendo te ayuda realmente a completar el programa.
PRLOGO DE LOS ESTUDIANTES
Es muy importante no amaar los datos (tiempos) porque entonces no te sern tan tiles. 3. Qu aprendisteis?
Adems de lo que ya hemos dicho, aprendes cmo puedes utilizar tu tiempo ms eficientemente y a trabajar antes de utilizar el computador. Terminas haciendo mucho trabajo sobre papel antes de utilizar el ordenador. Aprendes sobre tus errores y sobre los de otras personas (por medio de ejemplos y discusiones). Tambin te ayuda a organizar tu programacin (puesto que haces el trabajo en papel antes de utilizar el computador). El PSP tambin se puede utilizar en otras actividades (no solamente en el desarrollo del software), aunque es necesario modificar las tablas.
4. Qu recomendarais a otros estudiantes que van a utilizar el PSP en el futuro?
Hacerlo bien. No amaar los datos. Seguir las instrucciones. Intentar entender el marco de referencia y sus conceptos. No permitir que el papel les coma, los liquidar. Ben Bishop, Andrew Henderson, Michael Patrick Universidad Aeronutica de Embry-Riddle
Prlogo
Si ests estudiando para ser un ingeniero de software, este libro est diseado para ti. Describe los mtodos que muchos ingenieros de software experimentados utilizan para hacer un trabajo competente, y proporciona ejercicios para ayudarte a aprender estos mtodos. Cada captulo describe un tema sencillo que ser practicado cuando hagas los ejercicios. Los ejemplos de cada ejercicio te ayudarn a comprobar tu trabajo.
POR QU HE ESCRITO ESTE LIBRO?

El desarrollo de productos software implica algo ms que escribir instrucciones de programacin juntas y ejecutarlas en un ordenador. Requiere cumplir los requisitos del cliente a un coste y planificacin acordada. Para tener xito, los ingenieros de software necesitan producir de forma regular programas de alta calidad de acuerdo con una planificacin y unos costes. Este libro muestra cmo hacerlo. Te introduce al Proceso Software Personal (PSP), que es una gua que utiliza prcticas personales disciplinadas para ser un ingeniero de software. El PSP mostrar cmo planificar y revisar tu trabajo, y cmo producir de forma regular software de alta calidad. Utilizando el PSP obtendrs datos que muestren la efectividad de tu trabajo e identifique tus puntos fuertes y tus debilidades. Esta herramienta es como las mediciones con cronmetro y de distancia que necesita hacerse uno mismo en relacin con el ingreso en un equipo de atletismo y decidir en qu pruebas participar. Para tomar una decisin inteligente, necesitamos esas medidas para saber dnde destacamos y dnde necesitamos mejorar. Como un equipo de atletismo, la ingeniera del software tiene muchos especialistas, y los
XXll
PRLOGO
ingenieros tienen una gran variedad de habilidades y talentos. Para tener una carrera satisfactoria y til, necesitas conocer tus destrezas y habilidades, y sacar partido de tus talentos en el trabajo que haces. El PSP te ayudar a hacer esto.
LA UTILIZACIN DEL PSP

Utilizando el PSP, estars practicando las habilidades y mtodos que ingenieros del software profesionales han desarrollado durante muchos aos de pruebas y errores. Basndote en las experiencias de tus predecesores, aprenders ms rpidamente y evitars repetir sus errores. La esencia de ser un profesional es entender lo que otros han hecho antes que t y construir sobre su experiencia.
CMO SE BENEFICIARN LOS ESTUDIANTES

Aunque el PSP se introduce actualmente en programas de ingeniena del software para licenciados, sus principios pueden ser aprendidos y practicados por estudiantes de los primeros cursos. Este libro est diseado para introducir los mtodos del PSP en pasos graduales de la misma forma que haces tus otros trabajos del curso. Al terminar de leer cada captulo, haz los ejercicios. Estos te muestran cmo gestionar tu tiempo, cmo planificar y controlar tu trabajo y cmo producir regularmente programas de alta calidad. Puesto que lleva su tiempo desarrollar las habilidades y hbitos de forma efectiva, deberas practicar los mtodos del PSP en cada ejercicio de software. Si haces esto, habrs aprendido, practicado y perfeccionado estas habilidades antes de que las necesites en tu trabajo de ingeniero de software.
CMO PUEDEN UTILIZAR ESTE LIBRO LOS INGENIEROS QUE TRABAJAN

Los ingenieros de software tambin pueden utilizar este libro para aprender los fundamentos del PSP. Te sugiero que trabajes los ejercicios desde el principio del libro hasta el final, utilizndolos como guas para mejorar la forma de hacer tu trabajo cotidiano. Practica cada ejercicio hasta que lo hayas aprendido, entonces lee el siguiente captulo e incorpora sus mtodos. De nuevo, practica tanto los mtodos nuevos como los aprendidos antes de avanzar al siguiente paso. La clave es dedicarle tiempo a dominar un mtodo antes de seguir avanzando. Con algo de dedicacin y disciplina no tendrs problema en dominar esta materia. El xito es ms probable, sin embargo, si haces este trabajo
INTRODUCCI~N AL PROCESO SOFTWARE PERSONAL
XXM
en una clase o con un grupo de colaboradores con quien puedas intercambiar experiencias y compartir ideas. En cualquier caso, planifica dedicar entre una o dos horas cada semana a estudiar el libro de texto, registrar y analizar tus datos del PSP, y adaptar los mtodos a tu trabajo. Aunque el tiempo que necesitas para aprender el PSP depender de tus hbitos actuales y de tus prcticas, una vez que hayas terminado esta materia, tendrs una base slida para continuar desarrollndote profesionalmente. Observa, sin embargo, que la clave para aprender el PSP es examinar y pensar sobre los datos de tu trabajo y lo que estos datos te indican sobre tu rendimiento personal.
ALGUNAS SUGERENCIAS PARA LOS PROFESORES

Este libro est diseado como un texto de apoyo para los cursos tradicionales de informtica (CS) o ingeniera del software de duracin bisemestral' . Solo presupone una formacin preuniversitaria. El libro presenta el PSP en una serie de pasos que los estudiantes pueden utilizar en sus trabajos programados durante el curso. Los ejercicios de los 10 primeros captulos son bastante generales y pueden utilizarse con o sin trabajos de programacin. Los ejercicios de los diez ltimos captulos estn diseados para realizarlos con pequeos programas, de seis a ocho o ms. Aunque algunos estudiantes aprenden a programar en la universidad, ahora muchos aprenden nociones bsicas de programacin en institutos de enseanza secundaria. Este material est diseado tanto para utilizarse en los primeros cursos de programacin como en cursos ms avanzados. Si los estudiantes ya saben cmo programar o estn aprendiendo, deberan entender fcilmente el material y encontrarlo inmediatamente til. Este libro presenta solo una introduccin al PSP, pero no lo describe por completo. El libro no trata, por ejemplo, las tcnicas estadsticas necesarias para hacer estimaciones con exactitud o anlisis de datos. Tampoco trata los mtodos para dimensionar el PSP a grandes proyectos, o la definicin de procesos y la mejora de tcnicas utilizadas al aplicar el PSP a tareas distintas de las de codificar pequeos programas. El PSP completo debera ensearse posteriormente a los estudiantes dentro del programa educativo2.
Tal y como se organizan las asignaturas en la Universidad espaola, el autor se refiere a una asignatura anual, organizada en dos cuatrimestres, en vez de dos semestres (N. del T.). El PSP y el curso del PSP estn descritos con ms detalle en mi libro de texto A Discipline f o r Software Engineering (Reading, MA: Addison-Wesley, 1995). El libro de texto lleva materiales que incluyen una gua para el profesor y un disquete con transparencias para clase, as como ejercicios.
'
xxtv
PRLOGO
Conforme los estudiantes son conducidos a travs del material de este libro y completan sus ejercicios, aprendern a controlar y monitorizar su trabajo, gestionar su tiempo y hacer planes. En el segundo semestre, aprendern sobre la calidad de los programas, las formas de hacer revisiones y a utilizar varias medidas de calidad y mtodos de gestin. Aprendern sobre los defectos, sus causas y la responsabilidad personal del ingeniero en la calidad de los productos que hacen. Al final del segundo semestre del curso, los estudiantes habrn aprendido los principios bsicos del PSP. A partir de estos principios bsicos y aumentando la experiencia con estos mtodos, se debera requerir a los estudiantes que en cursos posteriores continuasen utilizando el PSP.
UNA ESTRATEGIA DE ENSEANZA

Puesto que este libro pretende ser utilizado en combinacin con un curso bisemestral de ingeniera del software o de introduccin a la informtica, el material est dividido en un primer semestre que trata sobre la gestin del tiempo (10 captulos) y un segundo semestre que trata sobre la calidad. La enseanza de este material supone unas seis horas de clase en los dos semestres. Puesto que los estudiantes utilizan los mtodos del PSP al mismo tiempo que hacen otros trabajos del curso, este material no aade una carga de trabajo significativa a los estudiantes. El tiempo adicional que dedican los estudiantes a aprender estos mtodos se compensa por la eficiencia que consiguen. Conforme se avanza en el libro, se deben proponer los ejercicios de cada captulo a los estudiantes. La experiencia indica que es mejor hacer los 10 primeros captulos en las primeras semanas del primer semestre. Los estudiantes tienen entonces el resto del semestre para practicar los mtodos introducidos. En el segundo semestre se debera seguir la misma estrategia, introducir los temas del PSP en las primeras semanas del semestre y posteriormente utilizar estos mtodos durante el resto del semestre. Es de gran importancia presentar este material como una parte integral del curso. Explicando que estos son mtodos fundamentales de ingeniera del software, que los estudiantes deben aprender y practicar para completar de modo satisfactorio el curso. Cuando se proponga un ejercicio, se debe explicar que la evaluacin de los estudiantes depender tanto de la calidad de su trabajo como de lo bien que apliquen los mtodos del PSP. Deben hacer cada ejercicio del PSP y continuar utilizndolos despus de esta primera introduccin. La estrategia del curso, sugiere la imparticin de los contenidos y los ejercicios incluidos en el libro y los materiales de apoyo descritos al final del mismo.
INTRODUCCI~N PROCESO SOFTWARE PERSONAL AL
xxv
PREPARACIN DEL PROFESOR

Para la imparticin de este curso, ser til que el profesor haya aplicado l mismo los mtodos. Podra utilizar, por ejemplo, los mtodos de planificacin y gestin del tiempo para preparar las clases o evaluar el trabajo de casa. Despus de utilizar personalmente el PSP, apreciar mucho mejor la disciplina personal requerida. Este conocimiento le ayudar a explicar el PSP a los estudiantes y no solo a guiarlos en su utilizacin. Cuando vean que el profesor ha utilizado el PSP, es ms probable que ellos mismos lo utilicen.
AGRADECIMIENTOS
Al escribir este libro estoy especialmente agradecido a la Facultad de Informtica de la Universidad Aeronutica de Embry-Riddle. Ellos me animaron a desarrollar este libro y me revisaron amablemente el manuscrito. Puesto que haban impartido varios cursos y utilizado ellos mismos los mtodos del PSP, hicieron muchas sugerencias tiles. Por su apoyo y nimo, les doy particularmente las gracias a los profesores Tom Hilburn, Iraj Hirmanpour, Aboalfazl Salimi, Davie Srachet, y Massood Towhidnejad. Tambin doy las gracias a sus tres estudiantes, Ben Bishop, Guillermo Jos Hernndez y Richard Rickert, por compartir sus datos del curso y las experiencias de clase conmigo. Adems, agradezco a Ben Bishop, Andrew Henderson y Michael Patrick su amable descripcin de sus experiencias con este material en el prlogo de los estudiantes. Varios amigos y compaeros del SE1 y de otros centros han revisado amablemente el manuscrito y me han indicado sugerencias y comentarios tiles. Estoy agradecido a Steve Burke, Howie Dow, John Eikenberry, Andy Huber, Julia Mullaney, Glenn Rosander, Marie Silverthorn, y Bob Stoddard. Mi secretaria Marlene MacDonald ha sido de gran ayuda en la lectura y comentario de las partes de este manuscrito, y en la distribucin y revisin del mismo. Doy las gracias a Peter Gordon, Helen Goldstein, y a la direccin de Addison-Wesley por su apoyo en la impresin de este libro. Finalmente, he sido bendecido por una esposa maravillosa. Brbara me ha proporcionado ayuda y estmulo como en los otros libros. Como en las otras obras, ha ledo el manuscrito final antes de enviarlo a su publicacin. A pesar de toda su ayuda y apoyo, estoy seguro de que ni Brbara ni mis muchos colaboradores habrn encontrado todas mis equivocaciones y errores. Los errores que permanecen son completamente mos.
Watts S. Humphrey
Surusota, Florida
El trabajo del ingeniero software
Adems de describir el trabajo del ingeniero de software y algunas de sus actividades principales, este captulo tambin da una visin de la estrategia de este libro para ayudarte a desarrollar y mejorar tu formacin en ingeniera del software. El captulo termina con un ejercicio que consiste en especificar las tareas ms importantes que realizars a lo largo del tiempo que trabajes con este libro.
1.1
~ Q U LA INGENlERA DEL SOFWARE? ES

El trabajo de un ingeniero del software es entregar productos software de alta calidad a unos costes establecidos y en un plazo determinado. Hay as, tres aspectos que hacen efectivo un trabajo de ingeniero del software: producir productos de calidad, hacer el trabajo a los costes esperados y completar el trabajo de acuerdo con la planificacin establecida. Despus de aos de dolorosas experiencias, muchos ingenieros de software han aprendido que para hacer un trabajo efectivo necesitan:
1. Planificar su trabajo. 2 Hacer su trabajo de acuerdo con el plan. . 3. Esforzarse en producir productos de mxima calidad.
El principal objetivo de este libro es mostrarte cmo hacerlo.
EL TRABAJO DEL INGENIERO DEL SOFTWARE
1.2
POR QU ES IMPORTANTE UNA BUENA INGENIERIA?

Hasta ahora, son pocas las organizaciones de software que han satisfecho de forma fiable sus compromisos de costes y planificacin. Este pobre record no solamente da a la ingeniera del software una mala imagen, tambin causa serios problemas en los negocios. Hay muchos ejemplos de negocios fracasados, disputas de contratos, litigios y molestias a los clientes. Entre ellos: el multimillonario sistema de control de trfico areo de la FAA que duplic su coste y sufri repetidos retrasos de entrega debido a problemas de software, y Ashton Tate, una gran empresa de software, quebr debido a la pobre calidad de sus productos software. Los defectos del software han causado prdidas humanas [Leveson]. El software de los ordenadores es actualmente crtico para muchos negocios. Funciona en la mayora de las modernas industrias, maneja diariamente las transferencias internacionales de billones de dlares, y es un elemento clave en los nuevos productos y servicios que utilizamos. Puesto que la importancia del software en los negocios aumenta, la eficacia de los grupos de ingeniera del software es cada vez ms importante. Por lo tanto, tu activo ms importante como ingeniero ser tu capacidad para hacer coincidir consistentemente tus compromisos con la calidad de los productos.
1.3
EL PROCESO SOFTWARE PERSONAL

El Proceso Software Personal (PSP)SM diseado para ayudar a los infue genieros del software a hacer bien su trabajo. Muestra cmo aplicar mtodos avanzados de ingeniera a sus tareas diarias. Proporciona mtodos detallados de planificacin y estimacin, muestra a los ingenieros cmo controlar su rendimiento frente a estos planes y explica cmo los procesos definidos guan su trabajo. El Proceso Software Personal completo puede ser enseado en un curso universitario de 15 clases (15 lecciones de una hora), donde los estudiantes practican los mtodos del PSP mientras completan 10 ejercicios de programacin y 5 ejercicios de anlisis. Esto les ayuda a entender cmo el PSP trabaja para ellos. El PSP se ha impartido en un gran nmero de universidades y est siendo introducido en muchas organizaciones industriales. Los datos reunidos de los cursos impartidos muestran que el PSP es efectivo a la hora de mejorar el rendimiento en la planificacin de los ingenieros y la calidad de sus productos.
SM Personal Software Process y PSP son marcas registradas de la Universidad de Camegie Mellon.
El PSP tambin es efectivo en la industria del software. En un caso, antes de aprender el PSP, un grupo de ingenieros necesit, en promedio, unas cinco veces ms de lo que haban estimado para desarrollar tres componentes de un sistema software. Despus del entrenamiento con el PSP, los mismos ingenieros terminaron los seis siguientes componentes del mismo producto en un 10,4%menos del tiempo que haban planificado. Cuando midieron los defectos encontrados por los clientes, la calidad de los componentes terminados despus del curso del PSP fue cinco veces mejor que la calidad de los primeros componentes programados. Cada captulo de este libro, introduce un mtodo del PSP que t deberas aplicar posteriormente en tu trabajo. Utilizndolo, vers cmo funciona el mtodo y adquieres prctica en su aplicacin. Supone un considerable esfuerzo y perseverancia aplicar el mtodo del PSP de una forma consistente, pero esa, es la nica forma de aprenderlo. Las clases del curso y el libro de texto son importantes, pero el principal medio de aprendizaje son los datos que renas en tu propio trabajo conforme completas cada ejercicio del PSP. Es importante tener estos datos para que puedas ver posteriormente cmo has mejorado tu rendimiento con el PSP.
1.4
LA DISCIPLINA DEL TRABAJO DE ALTA CALIDAD

La disciplina se define como una actividad o ejercicio que desarrolla o mejora habilidades. Contrariamente a la visin popular de la disciplina como una limitacin onerosa, es un marco de trabajo para aprender y mejorar personalmente. La disciplina del PSP proporciona un marco de trabajo estructurado para desarrollar las habilidades personales y los mtodos que necesitars como ingeniero del software. La cuestin no es si t necesitas habilidades personales sino cunto tiempo necesitas para desarrollarlas y cmo las utilizas de forma consistente. La disciplina de PSP acelerar tu aprendizaje. Los profesionales en muchos otros campos aprenden y practican las habilidades y los mtodos de sus profesiones durante su educacin formal. Los qumicos aprenden a manejar los equipos del laboratorio y a hacer anlisis precisos. Antes de ejercer la ciruga, los mdicos internos observan y practican bajo la supervisin de cirujanos expertos. Ninguno de ellos pensma en tener que aprender cuestiones de higiene, infecciones o procedimientos de quirfano en el trabajo. Los pilotos de lneas areas estn muy cualificados antes de sus primeros vuelos comerciales, y los msicos dedican aos a ensayar antes de su debut. As, en otros campos, los profesionales demuestran su competencia bsica antes de que se les permita desarrollar el trabajo ms simple, mientras que en el software, los
ingenieros sin entrenamiento en el PSP deben aprender las habilidades que necesitan en el trabajo. Esto no solo es costoso y consume tiempo, sino que aumenta el riesgo.
1.5
LA IMPORTANCIA DEL TRABAJO DE ALTA CALIDAD

Como ingeniero del software en prcticas, probablemente desarrollars partes de grandes productos o sistemas. No importa cmo sean de pequeas con respecto al tamao total del producto o su escasa importancia, cualquier defecto en ellas podra potencialmente daar todo el sistema. La calidad de un sistema software no solamente est gobernada por la calidad de sus partes, sino que cualquier error trivial en los programas de soporte puede tener efectos devastadores. Los sistemas informticos modernos pueden ejecutar millones de instrucciones por segundo. As, un defecto poco probable que pueda suceder solamente una vez de entre un billn puede ocurrir varias veces en un da. Con el software, las condiciones inusuales se presentan todas las veces, condiciones que parecen imposibles ocurren en poco tiempo. Los defectos en los elementos ms pequeos de un gran sistema pueden causar serios problemas de forma impredecible y ocasional. Si cometes un error trivial que deja un defecto en el producto, el resultado puede causar un gran inconveniente o incluso un dao fsico al usuario. Para producir sistemas software de calidad, cada ingeniero debe aprender a hacer el trabajo con calidad. Si aprendes de forma consistente a producir programas de gran calidad, t y tus productos seris muy valorados por tus jefes y por tus clientes.
1.6
&MO MEJORAR LA CALIDAD DE TU TRABAJO?

Cuando estaba en la Marina de los Estados Unidos tuve que aprender a disparar un fusil. El entrenamiento era con fusiles y platos de barro. Mis puntuaciones eran psimas y no mejoraban, aunque practicase. Despus de observarme, el instructor me sugiri que intentase disparar con la mano izquierda. Siendo diestro, al principio encontr eso ilgico, despus de unos pocos disparos de prueba, yo mejor mis puntuaciones. Hay varias cuestiones en este ejemplo. Primero, las medidas son necesarias para diagnosticar un problema. Sabiendo cuntos fallos y aciertos cometa, el instructor y yo podamos ver fcilmente qu cosas tena que hacer de forma diferente. A continuacin, tenamos que utilizar esas medidas en algn tipo de anlisis objetivo. Observndome, el instructor poda analizar el proceso que yo segua para disparar el fusil, los pasos
INTRODUCCI~NAL PROCESO SOFTWARE PERSONAL
que haca eran: cargar, posicionarme, localizar, apuntar y disparar. El objetivo del instructor era descubrir qu pasos eran la fuente de mi problema. l rpidamente se centr en el objetivo y sugiri que yo tena que hacer cambios. Finalmente, y ms importante, vino el cambio mismo. El proceso de mejora es difcil porque las personas son reacias a intentar cosas nuevas. Sus hbitos parecen tan naturales que pueden pensar que el cambio no les ayudar. Yo siempre haba sido diestro y nunca pens disparar con la izquierda. Una vez que hice el cambio sugerido, mis puntuaciones mejoraron. Definir medidas no es siempre fcil, pero al menos no es imposible. Este libro define varias medidas para el proceso software. Una vez que has definido las medidas para tu trabajo, debes reunir y analizar los datos. Si necesitas mejorar, a continuacin analizas el proceso para ver dnde tienes que hacer cambios. Finalmente, para mejorar, debes cambiar lo que haces normalmente. Si no hubiese cambiado mi proceso, poda haber estado intentndolo durante aos sin mejorar como tirador. Las medidas, por si solas no producirn mejora aunque se repitan frecuentemente una y otra vez. Si continas trabajando como siempre lo has hecho, continuars produciendo los mismos resultados de siempre.
1.7
EL PROCESO DE MEJORA
Los pasos necesarios para cambiar la forma de tu trabajo son los mismos que los pasos que segu para aprender a disparar. No son complicados. El proceso de mejora se muestra en la Figura 1.1. Definir el objetivo de calidad. Obviamente, mi objetivo era darle a la diana el mayor nmero de veces posible, el 100% era el objetivo final. Medir la calidad del producto. El instructor y yo podamos ver que mis puntuaciones eran malas y algo haba que hacer. Entender el proceso. El instructor observ qu haca yo para ver qu es lo que deba de cambiar. Ajustar el proceso. l sugiri que tena que disparar con la mano izquierda. Utilizar el proceso ajustado. A continuacin, dispar varias veces, pero esta vez con la izquierda. Medir los resultados. Contamos el nmero de aciertos y fallos.
Definir el objetivo de calidad
Medir la calidad del producto
Ajustar
Realimentar y continuar mejorando Medir los resultados
Comparar los resultados con el objetivo
Figura 1.1 El proceso de mejora.
Comparamos los resultados con el objetivo. A partir de esos datos, pudimos ver que mis puntuaciones mejoraron bastante. Realimentar y mejorar continuamente. Puesto que aprender a disparar un fusil era sencillo, el proceso de mejora continua no fue necesario. Con procesos ms complejos, generalmente se requieren varios ciclos. Con un proceso sofisticado como el desarrollo del software, los ciclos de mejora no deberan terminar nunca.
1.8
EL OBJETIVO DE ESTE LIBRO

Este libro introduce algunos mtodos clave de ingeniera del software, uno por uno. Estos mtodos son todos importantes, pero deben ensearse
en algn orden. Esto es un poco como ensear a alguien a aprender a nadar. Puedes hablar sobre la respiracin, los movimientos de piernas, la flotacin y los movimientos de brazos como actividades individuales, pero tienes que hacerlas todas a la vez para nadar. Generalmente ensears primero la respiracin, pero el orden en el cual expliques el resto de cosas no lo hace muy diferente. Debes, sin embargo, cubrir todos los aspectos. En cualquier caso, hasta que no los hagas todos juntos, no puedes nadar. Con este libro, somos ms afortunados. Muchos de estos mtodos pueden ser utilizados independientemente y te ayudarn de alguna forma. Dichos mtodos, sin embargo, se refuerzan unos a otros. Por lo tanto, hasta que no los utilices todos, no conseguirs un beneficio global del proceso disciplinado de la ingeniera del software. De la misma forma que debes primero aprender a respirar en el agua antes de poder nadar, en la ingeniera del software disciplinada debes comenzar por reunir datos. El objetivo de este libro es introducirte en los pasos del proceso de mejora que se muestran en la Figura 1.1. Puesto que el orden no es crtico, he decidido presentar este material en dos partes. Los 10 primeros captulos del libro tratan de la planificacin y gestin del tiempo: procesos de planificacin. Los 10 ltimos captulos tratan de la calidad del producto: proceso de gestin de defectos. Es importante tratar primero el proceso de planificacin porque proporciona una base slida para el proceso de gestin de defectos.
RESUMEN
Los ingenieros del software deberan planificar su trabajo, y actuar de acuerdo con dicho plan. El resultado sern productos de alta calidad ajustados a un presupuesto y unos plazos. El Proceso Software Personal (PSP) es un marco de trabajo diseado para ensear a los ingenieros del software a hacer mejor su trabajo. Muestra cmo estimar y planificar,tu trabajo, cmo controlar tu rendimiento frente a esos planes y cmo mejorar la calidad de los programas que produces.
Los mtodos de calidad lleva tiempo aprenderlos y practicarlos, pero te ayudarn durante tu carrera como ingeniero. Para mejorar consistentemente la calidad de tu trabajo, debes establecer objetivos, medir la calidad del producto, entender el proceso, cambiar y reutilizar el proceso, medir y analizar los resultados y finalmente realimentar y mejorar continuamente.
La estrategia de este libro es mostrarte cmo organizar y planificar tu trabajo, y cmo gestionar la calidad de los programas que produces. El primer paso para entender tu proceso es identificar las tareas que haces, estimar cunto tiempo necesitar cada tarea, y medir el tiempo gastado.
EJERCICIO 1
El primer paso para entender tu proceso es identificar las tareas que haces. Por ejemplo, como estudiante, asistirs a clase, escribirs programas, leers libros de texto y hars varios trabajos en casa. En algn momento, necesitars estudiar para los exmenes. Parte del trabajo de casa consistir en escribir programas. Una forma de describir estas tareas podra ser la que se muestra en la Tabla 1.1. Aqu, el Estudiante X espera dedicar unos 1200 minutos a sus tareas semanales y otros 300 minutos una vez al semestre a estudiar exmenes. Esto da un total de 20 horas cada semana y otras 5 horas para estudiar los exmenes.
Tarea
Asistir a clase Leer libros de texto Trabajo en casa Escribir programas Preparar exmenes Revisar apuntes
Frecuencia
L, M,V Semanal Semanal Semanal Una vez al semestre Durante el trabajo de casa, estudiar
Tiempo (minutos)
180semana 100semana 420semana 420semana 300lsemestre Incluido en otros tiempos
En este ejercicio, debes definir tus principales actividades para este curso y escribirlas en un formato como el indicado en la Tabla 1.1. Despus de hacer esta lista, estima la frecuencia de dichas tareas y cunto tiempo le dedicars a cada una. Para todas las tareas semanales, estima el tiempo que utilizars cada semana, y para las tareas mensuales o semestrales, estima los tiempos mensuales o semestrales. Este ejercicio no requiere que midas esos tiempos. Una estimacin es suficiente. Haz y guarda una copia de esta lista antes de hacer tu trabajo de casa. Asegrate de poner tu nombre y la fecha.
REFERENCIA
[Leveson] Leveson, Nancy G. Safeware, System Safety and Computers. Reading, MA: Addison-Wesley, 1995.
CAPITULO 2
Este captulo muestra cmo gestionar tu tiempo y por qu es importante hacerlo. Tambin describe cmo y por qu utilizar un cuaderno de ingeniera. Como ejercicio del captulo hars un cuaderno de notas de ingeniera para utilizarlo en tu trabajo.
2.1
LA LGICA DE LA GESTIN DEL TIEMPO

Los fundamentos para gestionar el tiempo son:
Probablemente hars esta semana lo mismo que hiciste la semana pasada. En general, la forma en que utilizaste tu tiempo la ltima semana te proporcionar una aproximacin bastante buena a la forma en la que gastars tu tiempo en futuras semanas. Hay, sin embargo, muchas excepciones. Durante la semana del examen, por ejemplo, no puedes asistir al mismo nmero clases y probablemente dedicars ms tiempo a estudiar y menos a hacer trabajos en casa. Para hacer un plan realista, tienes que controlar tu forma de gastar tu tiempo. Aunque recuerdes cmo gastaste tu tiempo la ltima semana, te sorprenderas de tus datos reales. Las personas recuerdan algunas cosas y olvidan otras. Por ejemplo, el tiempo que utilizaste en hacer trabajo en casa es probablemente mucho menor de lo que estimaste, mientras que el tiempo de comer o de relajarte con los amigos, es con frecuencia, muy superior al esperado. Nuestra memoria tiende a minimizar el tiempo que de-
10
LA GESTIN DEL TIEMPO
dicamos a cosas que parecen que transcurren rpidamente, porque nos agrada hacer dichas cosas. Por el contrario, en las actividades lentas, aburridas o difciles parece que se dedica ms tiempo del que realmente se consume. Por lo tanto, para saber cmo utilizar tu tiempo, necesitas tener registros exactos del mismo.
Para comprobar la exactitud de tus estimaciones de tiempo y planes, debes documentarlas y posteriormente compararlas con la que realmente haces. Mientras esto no es un problema serio en las universidades, es de importancia crtica para el trabajo de los ingenieros. La planificacin es una habilidad que pocas personas han aprendido. Hay, sin embargo, mtodos de planificacin conocidos que se pueden aprender y practicar. El primer paso para aprender a hacer buenos planes, es hacer planes. As que, escribe tu plan para que posteriormente tengas algo con lo que puedas comparar tus datos actuales. Para hacer ms precisos tus planes, determina las equivocaciones de los planes anteriores, y qu podras haber hecho para mejoral: Cuando hagas el trabajo planificado, registra el tiempo que utilizas. Esos datos del tiempo sern tiles si se anotan con un poco de detalle. Por ejemplo, cuando ests haciendo el trabajo del curso, registra por separado el tiempo que dedicas a asistir a clase, leer libros de texto, escribir programas y estudiar para los exmenes. Cuando codifiques grandes programas, de igual forma encontrars til registrar los tiempos para las distintas partes del trabajo: diseo del programa, escritura del cdigo, compilacin y pruebas. Aunque dicho grado de detalle no es necesario para programas muy cortos, puede ser til cuando trabajes en proyectos que necesiten varias horas o ms.
Cuando tengas la copia documentada de tu plan y hayas registrado a qu has dedicado tu tiempo, puedes comparar fcilmente los resultados reales con el plan original. Vers donde estaba equivocado el plan y como tu proceso de planificacin puede ser mejorado. La clave para planificar con exactitud es hacer planes consistentes y compararlos con los resultados reales posteriores. Entonces vers como puedes hacer planes mejores.
Para gestionar tu tiempo, planijica tu tiempo y sigue el plan. Determinar qu podras hacer para producir mejores planes es la parte ms fcil. Llevarlo a cabo es lo realmente difcil. El mundo est lleno de resoluciones que nunca se cumplen, como seguir una dieta o dejar de fumar.
Al principio, cumplir un plan es probablemente difcil. Hay muchas razones posibles, pero la ms comn es que el plan no era muy bueno. Hasta que no intentes seguirlo, probablemente no sabrs porque. Trabajando con el plan, consigues el primero de dos beneficios: saber dnde estaba equivocado el plan, lo cual te ayudar a mejorarlo en el prximo proyecto. El segundo beneficio de trabajar con el plan es que hars el trabajo de la forma que lo has planificado. Puede que esto no parezca muy importan-
11
te, pero lo es. Muchos de los problemas en la ingeniera del software son causados por atajos irreflexivos, descuidos y distracciones en los detalles. En muchos casos, los propios mtodos eran conocidos y especificados pero no se seguan. Aprender a establecer planes tiles es importante, pero aprender a seguir dichos planes es absolutamente crucial. Otro beneficio ms sutil de trabajar de acuerdo a un plan es que cambias tu comportamiento actual. Con un plan, es menos probable que derroches tiempo en decidir qu hars despus. El plan tambin te ayuda a centrarte en lo que ests haciendo. Es menos probable que te distraigas y es ms fcil ser eficiente.
2.2
COMPRENDE CMO UTILIZAS EL TIEMPO

Para practicar la gestin del tiempo, el primer paso es entender cmo utilizas el tiempo ahora. Esto se hace en varios pasos:
Clasijica tus principales actividades. Cuando comiences a controlar el tiempo, probablemente encontrars que gran parte del mismo lo dedicas a relativamente pocas actividades. Esto es normal. Para hacer algo, debemos centramos en pocas cosas que sean muy importantes. Si distribuyes tu tiempo entre muchas cosas, ser difcil encontrarle sentido a los datos. De tres a cinco categoras debern ser suficientes para controlar el tiempo durante el curso. Si posteriormente necesitas un mayor grado de detalle, divide las categoras ms generales en subcategoras. Registra el tiempo dedicado a cada una de las actividades principales. Se necesita bastante disciplina personal para registrar el tiempo de forma consistente. Toma un registro exacto, registra el tiempo de inicio y fin de cada actividad principal. Al principio lo olvidars con frecuencia, pero despus de cierta prctica ser natural en ti. El Captulo 3 describe el registro del tiempo con ms detalle. Registra el tiempo de forma normalizada. Normalizar los registros de tiempo es necesario porque el volumen de datos aumentar rpidamente. Si no registras y almacenas cuidadosamente estos datos, se perdern o estarn desorganizados. Los datos confundidos o desordenados son difciles de encontrar o interpretar. Si no intentas tratar los datos de forma adecuada, puede que no los renas bien. El Captulo 3 describe una tabla normalizada de registro de tiempos, utilizada en el PSP para reunir datos. Guarda los datos de tiempo en un lugar adecuado. Puesto que necesitars guardar los registros de tiempo con los trabajos del curso, gurdalos en un lugar adecuado. Esta es una de las principales utilidades del cuademo de ingeniera.
12
2.3
EL CUADERNO DE INGENIERIA
En este curso, utilizars un cuaderno de ingeniera para controlar el tiempo. Lo utilizars tambin para otras cosas, tales como, guardar los ejercicios, controlar compromisos, tomar notas de clase y como un cuaderno de trabajo para anotar ideas de diseo y clculos. Como un profesional del software, le dars mltiples usos al cuaderno de ingeniera tales como: registrar los tiempos, guardar los clculos y tomar notas de diseo. Podrs utilizarlo como una evidencia de lo que haces en la prctica de la ingeniera, evidencia importante para la defensa de tu empresa, si es que tienes que defender la responsabilidad legal de un producto. Cuando las partes perjudicadas demandan a la compaa, su principal objetivo es demostrar que los suministradores fueron negligentes. Para la compaa, la mejor defensa es la evidencia de que los ingenieros siguieron las practicas de ingeniera. Por esta razn tener un cuaderno de ingeniera es un buen hbito. Una utilizacin adicional del cuaderno de ingeniera es la proteccin de los activos intelectuales de los empleados, por ejemplo, registrando ideas que se puedan patentar. Una vez, en una reunin de diseo, entre mis colegas y yo ideamos algo que se poda considerar como una idea a patentar. Escribimos la idea en mi cuaderno de ingeniera y todos firmamos cada pgina. El asesor de patentes nos dijo que esto podra ser til para establecer la fecha del invento. La compaa tambin nos dio a cada uno de nosotros un premio en metlico. Aunque probablemente estas ideas no te interesen como estudiante, este curso trata sobre cmo aprender los mtodos y establecer los hbitos que necesitars en la prctica como ingeniero. Por ello, deberas disponer a partir de ahora de tu propio cuaderno de ingeniera y crearte el hbito de utilizarlo.
2.4
EL DISEO DEL CUADERNO

El diseo particular del cuaderno no es clave, pero la prctica general en la industria es utilizar un cuaderno de gusanillo. Si numeras cada pgina, el diseo de gusanillo te permitir tener las pginas en orden y un registro legal til de tu trabajo. La desventaja, por supuesto, es que tendrs que registrar tus notas en orden cronolgico y no podrs insertar o eliminar pginas fcilmente. Una sugerencia para la portada de tu cuaderno de ingeniera se puede observar en la Tabla 2.1. En la parte superior, deberas etiquetar el cuaderno con un nmero de cuaderno. Despus de haber guardado los cuadernos de ingeniera durante varios aos, dispondrs de bastantes. La
13
Tabla 2.1 Ejemplo de portada del cuaderno de ingeniera.

Cuaderno nmero: 1
Cuaderno de ingeniera Nombre de la Empresa o Universidad
Nombre del Ingeniero Telfonolcorreo electrnico
Jane Doe
id@d b.xvz.edu
Fecha de apertura
9/9/96
Fecha de cierre
numeracin de los cuadernos es conveniente para almacenarlos en orden cronolgico. Tambin, etiqueta cada cuaderno con tu nombre y nmero de telfono o direccin de correo electrnico. Escribe la fecha de inicio de introduccin de datos en el cuaderno, y cuando lo hayas terminado escribe la fecha del ltimo registro. Dentro del cuaderno, numera cada pgina, utiliza las dos primeras pginas para una breve tabla de contenidos. En los contenidos, escribe cualquier referencia especial para que puedas encontrarla posteriormente, por ejemplo: ejercicios del curso. Esto te evitar que tengas que buscar por to-
14
do el cuaderno. No es necesario registrar los contenidos por pginas si no esperas referenciarlos en el futuro.
2.5
EJEMPLOS DE CUADERNOS DE INGENIERIA

Un ejemplo de la pgina de contenidos del cuaderno de ingeniera se muestra en la Tabla 2.2. Para materias que necesitars en el futuro, escribe a la izquierda el nmero de la pgina del cuaderno con una breve desTabla 2.2 Ejemplo de la pgina de contenidos del cuaderno de ingeniera.
Contenidos del Cuaderno de Ingeniera Pgina
3
4
Tema
Ejercicios IP Notas IK temas 1,2,3,4 Notas de diseo, primer programa Llamadas telefnicas, etc. Notas iP (cont.), tema 4, Ejercicios IP (continuacin)
Fechas
9-1619 9-1319 11 19 11 19 13-19 23-19
8 9
10
l1
15
cripcin del tema. Por ejemplo, el estudiante registra en la pgina 3 todos los ejercicios de la asignatura de IP (Introduccin a la Programacin) para dos semanas. Los contenidos tambin muestran que los ejercicios se continuarn registrando en la pgina 11. Un ejemplo de la pgina 3 del cuaderno se muestra en la Tabla 2.3. Los contenidos tambin muestran que entre el 9/9 y el 13/9, el estudiante tom notas de clase en las pginas 4, 5 , 6 y 7. Despus, continu
Tabla 2 3 Ejemplo de una pgina del cuaderno de ingeniera. .
Fecha
919
Ejercicio IF: entrega 1619 Hacer un cuaderno de ingeniera Referencia, pgina 206 del libro de t e x t o Leer el texto de programacin, captulo 1
11 19
Ejercicio IF: entrega 20/9 Hacer ejercicios de programacin, captulo 1
I
1319
Ejercicio IF: entrega 23/9 Leer el texto de programacin del captulo 2 Revisar 1 5 ejercicios del captulo 2 y preparar para el examen 0
1619
Ejercicio IP, entrega 2319 Completar

105
I I
registros de tiempos
l l
Utilizar la tabia de registros de tiempos Poner las pginas de registro al final del cuaderno de ingeniera Ver los ejemplos del captulo 3 del libro de texto
(105
ejercicios continan en la pgina 11)
16
tomando notas en la pgina 10. Siempre que tengas que saltar algunas pginas debido a otras anotaciones, es una buena idea escribir en la parte inferior de la pgina dnde contina ese tema. Vase, por ejemplo, la ltima lnea de la Tabla 2.3.
Para gestionar tu tiempo efectivamente, necesitas planificar tu tiempo y seguir el plan. Para hacer planes realistas, primero tendrs que controlar la forma de utilizar el tiempo. Debes documentar tus planes y compararlos con lo que haces realmente. Para mejorar la precisin de tu planificacin, determina los errores de los planes anteriores y qu podras hacer para mejorar el plan. El primer paso para la planificacin y gestin del tiempo es entender cmo utilizas tu tiempo realmente. Para hacer esto, necesitas clasificar tus actividades en categoras principales, entonces, de una forma normalizada, registra el tiempo dedicado a cada actividad. Para guardar estos datos en un lugar adecuado, utiliza el libro de ingeniera. En este curso utilizars el libro de ingeniera para registrar los ejercicios, tomar notas y tambin como libro de trabajo para el diseo de ideas y la realizacin de clculos.
EJERCICIO 2
Prepara un cuaderno de ingeniera para el trabajo que tengas que hacer en este curso. La portada debera incluir los puntos descritos en la Seccin 2.4 y su tabla de contenidos debera incluir al menos una entrada para los ejercicios del curso o los compromisos de trabajo para la semana actual. Muestra el cuaderno al profesor en la siguiente clase. Despus, el profesor podr ocasionalmente pedirte el cuaderno de ingeniera para revisarlo. Observa que esto es un ejercicio opcional. No necesitas hacerlo a menos que te lo pida el profesor.
CAPITULO 3
El control del tiempo
Este captulo describe un procedimiento y una forma de controlar y registrar la manera de gastar tu tiempo. Tambin se dan ejemplos de los tipos de registros de tiempos a guardar. En el ejercicio hars y utilizars una tabla de registro de tiempos.
3.1
POR QU CONTROLAR EL TIEMPO?

Como se describi en el Captulo 1, la forma de mejorar la calidad de tu trabajo comienza por entender lo que haces realmente. Esto significa que tienes que conocer las tareas que haces, cmo las haces y los resultados que obtienes. El primer paso en este proceso es definir las tareas y averiguar cunto tiempo gastas en cada una de ellas. Para hacer esto, debes medir tu tiempo real. Este captulo describe cmo medir el tiempo y anotarlo en una tabla. Mi experiencia escribiendo mi anterior libro me demuestra que esto puedes hacerlo. En la planificacin para escribir A Disciplinefor Sofnyare Engineering, revis mis datos de libros anteriores y encontr que haba dedicado una media de 26 horas por semana a escribirlos. Esto me pareci mucho tiempo porque yo entonces trabajaba a tiempo completo y poda solamente dedicar las tardes y los fines de semana a escribir. Por ello, decid planificar sobre 20 horas a la semana para cuando tuviese que es-
18
EL CONTROL DEL TIEMPO
cribir un nuevo libro. A esta velocidad, yo podra acabar el manuscrito el siguiente mes de enero. Despus de estar trabajando en el nuevo libro durantes un mes, encontr que el trabajo era mucho ms difcil de lo que haba previsto. Revisando mis datos, encontr que para cada captulo le estaba dedicando ms tiempo que el que haba planificado. Y en vez de 20 horas por semana, le estaba dedicando realmente ms de 30 horas. Aunque el trabajo era mayor de lo esperado, mis registros de tiempos me permitan hacer una estimacin de que podra terminar el manuscrito cuatro meses despus de lo que haba planificado inicialmente. Y fue cuando realmente acab. Aunque no esperes escribir muchos libros, encontrars mucho ms fcil controlar la cantidad de tiempo que dedicas a cualquier proyecto que incrementar tu productividad. Cuando las personas dicen que trabajan de firme, quieren decir que estn trabajando muchas horas. Si no sabes cmo utilizas realmente tu tiempo, no sers capaz de gestionar la forma de utilizarlo.
3.2
EL REGISTRO DE LOS DATOS DE TIEMPOS

Cuando registres el tiempo, recuerda que el objetivo es obtener datos de cmo trabajas realmente. La forma y el procedimiento utilizado para reunir los datos no es tan importante mientras los datos sean exactos y completos. Yo personalmente utilizo el mtodo descrito en este captulo y que he enseado en los cursos a muchos estudiantes. Tambin he enseado esta aproximacin a muchos ingenieros que han utilizado los mtodos con un xito considerable. Despus de haber superado su resistencia natural a utilizar las tablas y procedimientos, muchos ingenieros encuentran los mtodos sencillos y adecuados. A ti probablemente te suceder lo mismo. Conforme vayas trabajando con este libro, utiliza los mtodos descritos en este captulo para registrar el tiempo. h e d e s preguntarte: por qu debo utilizar esta tabla? Por qu no diseo mi propia tabla? Las respuestas son: En una clase, no sera prctico tener a cada estudiante utilizando una tabla o mtodo diferente. Sin una experiencia previa en la recogida de datos, sera difcil para ti idear una tabla y un procedimiento personal factibles. Despus de acabar este curso, tendrs el conocimiento y la experiencia para modificar las tablas y procedimientos para adaptarlos a ti.
19
En otras palabras, utiliza los mtodos descritos aqu. As, despus de haber intentado utilizar estos mtodos en este curso, tienes libertad para cambiarlos o disear algo completamente nuevo. No importa el formulario que utilices, pero, si quieres gestionar tu tiempo debes controlarlo continuamente.
3.3

Cuando las personas hablan generalmente sobre lo que hacen, a menudo utilizan las horas como medida. Pero esto no es muy til. La razn es porque t, realmente, no dedicas una hora completa a algo. Por ejemplo, en la Figura 3.1 mostramos un resumen de tiempos de 7 estudiantes tomados de un curso reciente en donde haba que escribir algn ejercicio de codificacin relativamente pequeo. Estos ejercicios requirieron una media de cuatro a seis horas cada uno, y los estudiantes tuvieron que controlar cundo comenzaban y paraban su trabajo. Como puedes observar, el 90% de los perodos de trabajo de los 7 estudiantes fueron inferiores a una hora. La cantidad tpica de tiempo no interrumpido que los ingenieros dedican a sus tareas es generalmente inferior a una hora. Medir el trabajo en unidades de horas no proporcionar el detalle necesario para posteriormente planificar y gestionar tu trabajo. Es mucho ms fcil controlar el tiempo en minutos que en fracciones de una hora. Considera, por ejemplo, los registros de tiempos que obtendras si utilizases fracciones de hora. Las entradas serian nmeros como 0,38 horas o 1,27 horas. Aunque las unidades de horas pueden ser ms tiles en resmenes mensuales o semanales, estas cantidades fraccionadas son difcil de calcular y complicado de interpretar. Por ejemplo, en vez de poner 0,38 horas, es ms fcil de entender y de registrar 23 minutos. Una vez que has decidido controlar el tiempo, es ms fcil controlarlo en minutos que en horas.
40r 35
\g
E s
30 a 25 20
15
10
5
n
Longitud de los perodos dc trabajo (minutos)
Figura 3.1 Perodos de trabajo del estudiante.
20
3.4
EL USO DE UNA TABLA DE REGISTRO DE TIEMPOS NORMALIZADA

La tabla utilizada para registrar el tiempo se muestra en la Tabla 3.1. La parte superior de la tabla, llamada cabecera tiene unos espacios para poner tu nombre, la fecha de comienzo, el nombre del profesor y el nombre o nmero de clase. Las columnas del cuerpo de la tabla son para registrar los datos de tiempo. Cada periodo de tiempo se introduce en una lnea de la siguiente forma: Fecha. La fecha de realizacin de alguna actividad, como asistir a clase o escribir un programa. Comienzo. La hora de comienzo de la actividad. Fin. La hora a la que terminas de hacer la actividad. Interrupcin. Cualquier prdida de tiempo debida a interrupciones (vase la seccin siguiente). ATiempo. El tiempo dedicado a cada actividad en minutos, entre los tiempos de comienzo y fin menos el tiempo de interrupcin. Actividad. Nombre descriptivo para la actividad. Comentarios. Una descripcin ms completa de lo que ests haciendo, el tipo de interrupcin o cualquier cosa que podra ser til cuando posteriormente analices los datos de tiempo. De nuevo, vase en la seccin siguiente las interrupciones. C (Completado). Rellena esta columna cuando termines una tarea, como leer un captulo del libro de texto o escribir un programa (vase 3.6). U (Unidades). El nmero de unidades de una tarea acabada (vase 3.6). Un ejemplo de cmo rellenar la tabla de registros de tiempos lo podemos ver en la Tabla 3.2. Aqu, la Estudiante Y escribe su nombre y la fecha en que comienza a rellenar la tabla. Tambin escribe el nombre del profesor y el nombre o nmero de curso. Cuando comenz a guardar registros de tiempos el da 9 de septiembre, registr esa fecha en la parte superior del formulario y hace el primer registro en la parte superior izquierda. Su primera actividad fue asistir a la clase de IP a las 9:OO A.M. La clase dur hasta las 950, o sea un total de 50 minutos. La estudiante puso 9:OO en la columna de comienzo, 9 5 0 en la columna de fin y los 50 minutos de duracin en la columna de ATiempo. A la derecha, puso el nombre de la actividad en la columna denominada Actividad. Finalmente, en la columna Comentarios, anot lo que estaba haciendo. Como la Estudiante Y continu
INTRODUCCI~N PROCESO SOFTWARE PERSONAL AL
21
haciendo actividades durante varios das, anot sus otras actividades para el curso de IP en la tabla de registro de tiempos.
Tabla 3.1 Cuaderno de registro de tiempos.
Estudiante Profesor Fecha Class
22
Registrar el tiempo de esta forma significa que hay que medirlo. Si no tienes un reloj, sera deseable conseguir uno.
3.5
LA GESTIN DE LAS INTERRUPCIONES

Un problema comn con el control del tiempo son las interrupciones. Es sorprendente la frecuencia con que somos interrumpidos por llamadas telefnicas, personas que quieren charlar, molestias ocasionales o la necesidad de descansar. La forma de gestionar las interrupciones en el Cuaderno de Registro de Tiempos, consiste en anotarlas en la columna Tiempo de Interrupcin. Como se observa en la Tabla 3.2, por ejemplo, la Estudiante Y comenz su trabajo de casa a las 11:06 del da 10 y par a las 12:19. Durante dicho perodo, tuvo dos interrupciones, una de 6 minutos y otra de 5. El tiempo neto que dedic a su trabajo de casa fue de 73 minutos menos 11 minutos de interrupcin, es decir un total de 62 minutos. La Estudiante Y no solamente anot estos tiempos en el Cuaderno de Registro de Tiempos, sino que tambin describi brevemente las interrupciones en la columna de comentarios. Una cosa que he encontrado til, es utilizar el cronmetro para controlar las interrupciones. Cuando me interrumpen, pongo en marcha el cronmetro y cuando estoy preparado para reanudar el trabajo, lo paro. Antes de comenzar a trabajar de nuevo, anoto el tiempo de interrupcin en el cuaderno y pongo a cero el cronmetro. Encuentro esto ms adecuado que apuntar el tiempo de inicio de cada interrupcin. Esto es tambin ms exacto que estar adivinando. Un ingeniero que jugaba al ajedrez me dijo que encontr un reloj de ajedrez especialmente adecuado para controlar el tiempo de las interrupciones. La tcnica que utilices no es tan importante mientras te sea til. Puesto que el tiempo de las interrupciones no es tiempo de trabajo productivo, debes controlar las interrupciones. Si la cantidad de este tiempo fuese constante, no tendras que hacer mucho para gestionarlo. El tiempo de las interrupciones, sin embargo, es muy variable. Si no lo mides, deberas de aadir un nmero aleatorio en todos los datos de tiempos. Esto hma ms difcil utilizar estos datos para planificar o gestionar tu tiempo. Los datos de tiempo registrados pueden utilizarse para comprender con qu frecuencia se interrumpe tu trabajo. Las interrupciones no son solamente un despilfarro de tiempo, sino que rompen tu ritmo de pensamiento, llevndote a la ineficiencia y al error. Comprender como eres interrumpido te ayudar a mejorar la calidad y eficiencia de tu trabajo. Algunos ingenieros me han dicho que aprender a controlar el nmero y
23
duracin de las interrupciones era uno de los beneficios ms importantes del control de su tiempo.
Tabla 3.2 Ejemplo del cuaderno de registro de tiempos.
E~~~~~~~~~ Estudiante Y
Profesor
Sr.
Fecha
Ciass
"'
999 'f6
1219 1319
1419
642 1238 9:15
904
1Ot6t12
14 1
9 0 950 :0
1:16 11:59 5t3t22
50 38 134
Cod. Clase Texm

Revisin
Ejercicio 3 Clase TextoCap.4 Preparar examen, descanso, telfono, charla
24 '
3.6
EL CONTROL DE LAS TAREAS FINALIZADAS

Para controlar cmo gastas tu tiempo, necesitas controlar los resultados producidos. Para la asistencia a clases o reuniones, por ejemplo, un registro del tiempo sera adecuado. Cuando desarrollas programas, lees los captulos de tu libro o escribes informes, necesitas saber cunto trabajo has realizado. Podras calcular la productividad de la tarea. Un ejemplo podra ser cunto tiempo necesitas para leer un captulo de un libro o escribir un programa. Con este conocimiento, podrs mejorar la planificacin de futuros trabajos. Las columnas C y U de la derecha del Cuaderno de Registro de Tiempos, significan Completado (C) y Unidades (U). Estas columnas te ayudan a identificar rpidamente el tiempo dedicado a las distintas tareas y lo que has hecho. Utilizars esta informacin en posteriores captulos de este libro, comenzando por el Captulo 4. Aqu, una unidad es una unidad de trabajo. Cuando has ledo un captulo, has completado una unidad de trabajo. Un programa acabado es otra unidad de trabajo. En el Captulo 6, introducimos ms medidas detalladas de unidades de trabajo, como las pginas de texto o las lneas de un programa fuente. Entonces, las 11 pginas de un captulo seran 11 unidades de trabajo. Mientras puedas contar las unidades de cualquier forma, eso es til, las unidades ms detalladas como las lneas de cdigo o las pginas de un texto son generalmente ms tiles que las unidades grandes de captulos o programas. Por ahora, sin embargo, utilizaremos unidades grandes y aplazaremos la discusin de la medida de unidades ms detalladas hasta el Captulo 6. Para rellenar la columna C, comprueba cuando has terminado una tarea. En la Tabla 3.2, por ejemplo, la Estudiante Y lee el libro desde las 6:25 a las 7:45 el 9 de septiembre. Durante este tiempo, complet la lectura de dos captulos. Por ello puso una X en la columna C (Completado). Para anotar las unidades de trabajo acabadas, puso un 2 en la columna de U (Unidades). Posteriormente, cuando resuma su trabajo de la semana, rpidamente podra ver estas columnas para encontrar los elementos acabados. Podra tambin determinar cuntas unidades de trabajo ha realizado y cunto tiempo ha dedicado. En la Tabla 3.2, por ejemplo, hay tres actividades de tipo Texto, pero solamente dos de ellas tienen rellena la columna C. En estas dos filas, la Estudiante Y dedic un total de 80 + 28 = 108 minutos a leer un total de 2 + 1 = 3 captulos del libro. Utilizando estos datos, por termino medio, lee un captulo del libro en 36 minutos. Para tener unos registros de tiempos exactos, es importante completar las columnas C y U cada vez que acabes una tarea que tenga resultados medibles. Si olvidas hacerlo, puedes fcilmente encontrar la informacin, pero es mucho ms fcil rellenarlo en el momento que aca-
25
bas la tarea. Las instrucciones para rellenar el Cuaderno de Registros de Tiempos estn repetidas en la Tabla 3.3 para facilitar la tarea de controlarlas antes de empezar a utilizarlas y vuelve a comprobarlas despus, para estar seguro de que ests registrando los tiempos de forma adecuada.
37 .
&MO MANTENER LA TABLA DE TIEMPOS EN EL CUADERNO DE INGENIERA?

Para mantener los registros de tiempos, debes tener una copia del cuaderno de tiempos a mano durante este curso. El cuaderno de ingeniera resulta ser un lugar adecuado para guardar el Cuaderno de Registros de Tiempos. Yo registro mi tiempo en la parte posterior de mi cuaderno porque trabajo con frecuencia en diferentes proyectos al mismo tiempo. Puesto que comienzo y finalizo los proyectos todos a la vez, he encontrado ms fcil guardarlos en el cuaderno de notas de ingeniera que tener diferentes hojas de tiempos a la vez. El mtodo que he encontrado ms adecuado, consiste en poner el Cuaderno de Registro de Tiempos en la ltima pgina del cuaderno y avanzo pginas hacia el principio. Cuando completo una pgina paso a la siguiente. Hago esto hasta que la documentacin de la parte delantera coincide con los Cuadernos de Tiempos de la parte trasera. Cuando sucede esto. comienzo un nuevo cuaderno. Puede haber razones por las que quieras guardar separados los registros de tiempos de cada proyecto. Cuando hagas un solo proyecto cada vez, es ms adecuado utilizar pginas separadas. Tambin, en este curso, tu profesor puede querer que registres el tiempo en Cuadernos de Registros de Tiempos separados porque son ms fciles de entregar y de calificar. Mientras registres tu tiempo, la tcnica que elijas no tiene la mayor importancia.
IDEAS PARA REGISTRAR TU TIEMPO

El control del tiempo es sencillo en teora. Unos pocos trucos, sin embargo, pueden ayudarte a hacerlo de forma ms consistente y precisa.
Lleva siempre contigo el cuaderno de notas. Esto parece obvio, pero al principio lo olvidars algunas veces. Cuando ocurra, anota la informacin de los tiempos en una hoja aparte y cpiala en el cuaderno tan pronto como puedas. Si utilizas el cuaderno para registrar otras cosas importantes como notas de clase, ejercicios y citas, es ms probable que lo lleves siempre.
26
Table 3.3 Instrucciones para los cuadernos de registro de tiempos.

Propsito Este formulario es para registrar el tiempo dedicado en este curso. Utiliza las pginas del final del cuaderno de ingeniera para hacer el Cuaderno de Registros de Tiempos. Registra todos los tiempos de este curso. Registra el tiempo en minutos. S tan preciso como puedas. Anota lo siguiente: Tu nombre y fecha actual. El nombre del profesor y el nombre o nmero de curso. Asegrate que tu nombre est en todas las copias del Cuaderno de Registro de Tiempos. Anota la fecha de inicio de la tabla. 14/9/96 Anota la hora de inicio de la tarea. 9:15 Anota la hora de finalizacin de la tarea. 11:59
Mtodo
Cabecera
Fecha Ejemplo Comienzo Ejemplo Fin Ejemplo
Tiempo interrupcin Registra el tiempo de interrupcin de la tarea y la causa de la interrupcin. Ejemplo ATiempo Ejemplo Actividad Ejemplo Comentarios 5 + 3 + 22, descanso, telfono, charla. Anota el tiempo que dedicas a la tarea, menos el tiempo de interrupcin. Desde las 9:15 a las 11:59, menos 30 minutos o 134 minutos. Anota el nombre de la tarea o actividad que estas realizando. Exmenes. Anota cualquier comentario pertinente que posteriormente te permita recordar cualquier circunstancia inusual observada con relacin a la actividad. Preparar exmenes. Cuando una tarea se termina, rellena este campo. A las 7:45 del 919, acabaste de leer uno o ms captulos, rellena este campo.
-
EjempIo
C (Completada)
Ejemplo U (Unidades) Ejemplo Importante
Anota el nmero de las unidades de trabajo acabadas. Desde las 6:25 a las 7:45 del 9/9 leste 2 captulos, escribe un 2. Registra todos los tiempos de este curso. Si olvidas registrar un tiempo, anota la mejor estimacin. Si olvidas el Cuaderno de Registros de Tiempos, anota estos tiempos y cpialos en tu tabla tan pronto como puedas.
27
Cuando ocasionalmente olvides registrar la hora de comienzo, la hora de$n o la duracin de la interrupcin, haz una estimacin tan pronto como lo recuerdes. Esto no ser tan riguroso como registrar la hora exacta, pero es lo mejor que puedes hacer. Ser lo ms parecido al tiempo real. Puedes utilizar un cronmetro para controlar las interrupciones. Puede parecer excesivamente preciso, pero es ms sencillo registrar el tiempo de inicio y de finalizacin de cada interrupcin. Resume tu tiempo puntualmente. Utilizars el Resumen Semanal de Actividades para resumir semanalmente tu tiempo en este curso. Cmo y por qu haces esto se discute en el Captulo 4.
Otra aproximacin es registrar los datos de tiempos en un computador. He intentado esto y he observado que lleva ms tiempo y era menos adecuado que tomar notas en el papel. Los ordenadores podran ser tiles para este propsito, pero sera necesario una aplicacin adecuada. Pero hasta que se desarrolle dicha aplicacin, puedes elegir entre escribirla tu mismo, utilizar un sistema manual de registro de tiempos o no controlar tu tiempo.
RESUMEN
Este captulo describe cmo controlar tu tiempo. Controla el tiempo en minutos utilizando el Cuaderno de Registro de Tiempos, que deberas guardar al final de tu cuaderno de notas de ingeniera. Lleva contigo el cuaderno cuando hagas las tareas de este curso. Si olvidas el cuaderno, registra el tiempo de la tarea en una hoja aparte y cpiala en el cuaderno tan pronto como puedas. Considera la utilizacin de un cronmetro para controlar las interrupciones.
EJERCICIO 3
Utiliza el Cuaderno de Registro de Tiempos para controlar el tiempo que dedicas a las distintas actividades de este curso. Como parte de este ejercicio, examina la lista de actividades que pusiste en el Ejercicio 1 y ajstalas si es necesario. Entrega la prxima semana una copia de tu registro de tiempos. Ser obligatorio entregar una copia del Cuaderno de Registro de Tiempos cada semana desde este momento hasta el final del curso.
CAPITULO 4
Planificacin de perodos y productos
Este captulo describe la planificacin de perodos y de productos, y muestra cmo relacionarlos con tu trabajo personal. Aprenders a rellenar un Resumen Semanal de Actividades para los datos del Cuaderno de Registro de Tiempos, que lleves anotados hasta ahora en el curso.
4.1
PLANES DE PERIODOS Y PRODUCTOS

Hay dos clases de planificacin. La primera est basada en un perodo de tiempo. Puede ser cualquier intervalo del calendario: un da, semana, mes o ao. Un plan del perodo hace referencia a la forma de planificar la utilizacin del tiempo durante ese perodo. La segunda clase de plan est basada en la actividad, cmo desarrollar un programa o escribir un informe. Los productos pueden ser tangibles como los programas o informes, o intangibles como el conocimiento que adquieres al leer un libro o el servicio que proporcionas cuando trabajas en una oficina. Para ver la diferencia entre planificacin del perodo y del producto, considera la actividad de leer este libro. Para planificar este trabajo, en primer lugar deberas estimar el tiempo total del trabajo. Por ejemplo, puedes suponer que necesitas 20 horas para leer los 20 captulos del libro. Para el plan del producto, deberas planificar el tiempo que dedicas a la
30
PLANIFICACIN DE PERODOS Y PRODUCTOS
lectura, por ejemplo una hora a la semana. El plan del producto para esta tarea tendra el objetivo de leer los 20 captulos del libro en 20 horas. El plan del perodo sera la forma de repartir el tiempo de lectura en incrementos semanales de una hora.
LA RELACIN ENTRE LOS PLANES DEL PERIODO Y DEL PRODUCTO

Todos nosotros utilizamos el plan del perodo y el del producto en nuestra vida diaria. En los negocios, por ejemplo, los dos estn relacionados tal y como se muestra de forma simplificada en la Figura 4.1. La parte izquierda de la figura trata de las tareas basadas en el producto y la parte derecha trata sobre las tareas basadas en el perodo. Las dos estn relacionadas como veremos a continuacin. La gestin corporativa proporciona fondos para que los departamentos de ingeniera y fabricacin desarrollen y produzcan productos. La ingeniera desarrolla productos y los enva a fabricacin. Por medio del grupo de mrketing, fabricacin entrega estos productos a los clientes, los cuales pagan un precio. Ingeniera y fabricacin tambin proporcionan planes de productos a finanzas y administracin, que utilizan los planes del producto para producir planes de perodo para ingresos y gastos anuales y trimestrales. Finanzas y administracin envan sus planes a la gestin corporativa. Tambin dan informacin sobre precios y previsiones a ingeniera y fabricacin para que sepan cuntos productos pueden hacer cada mes y qu cobrar a los clientes. La gestin corporativa decide qu dividendos o intereses van a pagar a los inversores y qu nuevas inversiones se necesitan.
Tareas basadas en el Producto
Ingresos
Tareas basadas en el perodo

Inversiones
Gestin Corporativa
Dividendos/ intereses
1 del lenodo
Productos Planes de
Precios y Previsiones
Figura 4.1 Plan del perodo y del producto.
31
Cuando sepan cunto dinero van a tener en el futuro, la gestin corporativa puede decidir que fondos va a proporcionar a ingeniera para el desano110 y fabricacin de futuros productos, completando de esta forma el ciclo.
LA IMPORTANCIA DE LOS PLANES DEL PERiODO Y DEL PRODUCTO

En los negocios, los planes del producto son importantes porque le indican a mrketing cundo pueden esperar nuevos productos para venderlos a los clientes. Tambin le indican a finanzas lo que costar el desarrollo y la fabricacin. Finanzas puede entonces determinar los precios que ellos necesitan cargar y proporcionan unos planes de perodo precisos para la gestin corporativa. La gerencia puede asignar el dinero que ingeniera y fabricacin necesitan. Si los planes del producto no son exactos, los planes del perodo sern tambin inexactos. Gerencia, mrketing, los inversores y los clientes estarn mal informados. Esto significara que los fondos necesarios no estaran disponibles para cuando ingeniera y fabricacin los necesitasen. Sin los fondos adecuados, ingeniera y fabricacin, tendran que reducir sus planes. Si redujesen sus planes, a ti te podran despedir. Aunque este ciclo de planificacin puede sonar terico y necesite varios aos, la amenaza es real. La clave para la seguridad del trabajo en cualquier negocio es la salud financiera de la organizacin. Y una clave para la salud financiera de los negocios es la exactitud de los planes del perodo y del producto. Por lo tanto es importante que los ingenieros sepan cmo hacer buenos planes del perodo y del producto. Aunque los planes del perodo y del producto deben estar relacionados, son diferentes. Tu trabajo de planificacin, tus ingresos y tus otras actividades diarias estn gobernadas por perodos de tiempo. Es decir, t duermes, comes, trabajas y descansas durante ciertos perodos del da o de la semana. Tus gastos e ingresos estn gobernados por planificaciones semanales, mensuales y anuales. De esta manera vives en un mundo con perodos de actividades, reglas y limitaciones. El principal propsito de tu trabajo es producir productos y servicios de valor para otros. El coste, la planificacin y la calidad de esos bienes y servicios son lo ms importante. No puedes hacer un plan competente de uno de ellos sin planificar tambin el otro. Este captulo se centra sobre la planificacin del perodo, en el siguiente captulo discutiremos la planificacin del producto.
EL RESUMEN SEMANAL DE ACTIVIDADES

Para hacer un plan del perodo, es importante entender cmo gastas tu tiempo. El primer paso es registrar tu tiempo utilizando el Cuaderno de
32
Registro de Tiempos introducido en el Captulo 3. Despus de reunir los datos de tiempo durante una o dos semanas, empezars a ver cmo empleas el tiempo. Puesto que los registros de tiempos son muy detallados para el propsito de la planificacin, necesitas resumir los datos de una forma ms til. El Resumen Semanal de Actividades de la Tabla 4.1 muestra los formatos de tiempo que son ms adecuados para la planificacin del perodo. En las lneas 1 a la 10 del Resumen Semanal de Actividades, registras el tiempo que dedicas a cada actividad principal durante cada da de la ltima semana. En la parte inferior derecha, en las lneas 13 a la 16, estn la media, el mximo y el mnimo tiempo que dedicas a cada tarea durante las semanas anteriores del semestre. De las lneas 18 a la 21 se
Tabla 4.1 Resumen semanal de actividades.
Nombre
1
2 3 4
Fecha
5
6
7
8 9 10
11 Tiempos y Medias del Perodo
Nmero de Semanas (nmero anterior + l ) :
12 Resumen de las semanas anteriores
13 14 15
16
17 Resumen incluyendo la ltima semana 18 19 20 21
33
muestran el total, la media, mximo y mnimo del tiempo que dedicas a cada trabajo definido para todo el semestre, incluyendo la ltima semana. Cuando desees hacer un plan del perodo para la prxima semana, comienza con el ltimo Resumen Semanal de Actividades. Basndonos en los tiempos previos dedicados a cada tarea, puedes juzgar cunto tiempo dedicars a estas tareas la prxima semana. La forma ms sencilla de hacer dicho plan, sera asumir que dedicars en el futuro la misma cantidad de tiempo que el tiempo medio dedicado en el pasado. Una aproximacin ms sofisticada debera considerar el trabajo a realizar en la prxima semana y juzgar dnde ubicarte entre los tiempos mximo y mnimos de las semanas anteriores. Esto dar como resultado un plan ms exacto. Las siguientes secciones describen cmo rellenar el Resumen Semanal de Actividades.
4.3
EL RESUMEN DE LOS TIEMPOS SEMANALES

Un ejemplo del Resumen Semanal de Actividades parcialmente relleno se muestra en la Tabla 4.2. Estos clculos utilizan datos de la Tabla de Registro de Tiempos mostrados en la Tabla 4.3. Rellena la tabla de la siguiente manera:
1. Anota tu nombre y fecha.

2. Anota las categoras de actividades como cabeceras de las columnas. En el ejemplo de la Tabla 4.2, las categoras de trabajo son: Clases, Codificar Programas, Preparar Exmenes y Leer Textos.
3. Escribe la fecha en la columna Fecha, anotando el domingo como primer da de la semana (fila 3).
4. Para cada da, suma todos los minutos para cada actividad de los registros de tiempos y anota el resultado en la columna correspondiente. Por ejemplo, en la Tabla 4.2 la primera tarea es Clase. En el Cuaderno de Registro de Tiempos de la Tabla 4.3, la Estudiante Y dedic 50 minutos, desde las 9:00 a las 9:50 A.M. del 9/9, a asistir a clase. As, puso en la Tabla 4.2 un valor de 50 en la fila 4 en la columna Clase para el da 9/9. El valor total de 96 minutos para Codificar Programas se obtiene a partir de los valores 38 y 58 minutos. Por ello, puso en la Tabla 4.2 el valor 96 en la fila 4 columna Codificar Programas.
5. Despus de completar todas las casillas para cada da, se obtiene el total para cada da en la columna Total. Por ejemplo, los totales de la fila 4 de la Tabla 4.2 son 50 + 96 + 80 = 226.
6. Repite este proceso para cada da de la semana (filas 5-9).
34
Tabla 4.2 Ejemplo de resumen semanal de actividades.

Nombre
EstudianteY
Fecha
9/16/96
11 Tiempos y Medias del Perodo
Nmero de Semanas (nmero anterior +l):
12 Resumen de las semanas anteriores

13 Total 14 15
Med. Mx.
16 Mn.
17
18 Total 19 Med. 20 21
150 150
150
341 341 341 341
134 134 134 134
146 146 146 146
771
771
T71
Mx. Mn.
150
71 7
7 Calcula los totales semanales para cada tarea clasificada en la .

fila 10. Por ejemplo, bajo la columna Codificar Programas pondras 96 + 62 + 69 + 114 = 341.
8. A continuacin, se obtiene el total de los tiempos de las actividades que aparecen en la fila 10. En este caso, el total es 150 + 341 + 134 + 146 = 771.
9. Por ltimo, suma los totales diarios para comprobar que obtienes el mismo resultado. En este caso tenemos: 226 + 62 + 147 + 114 + 88 + 134 = 771, as no hay error. Si dichos nmeros difieren, deberas de volver a calcular el total de todos los das y de todas las tareas para localizar el error.
35
10. El Resumen de Tiempos de la semana actual se completa tal y como se explic en la Seccin 4.2.
Una buena forma de minimizar los errores es hacer la suma de las columnas dos veces, de arriba abajo y de abajo a arriba, para asegurarte que obtienes el mismo total. Otra forma de minimizar los errores de clculo podra ser utilizar la hoja de calculo EXCEL, proporcionada como parte del material de apoyo disponible para este libro'.
4.4
CLCULO DE LOS TIEMPOS Y MEDIAS DEL PERODO

Un resumen sencillo de tus tiempos semanales sera suficiente si estuvieras nicamente interesado en una semana, pero realmente ests interesado en los tiempos medios, mximos y mnimos dedicados a estas tareas durante un semestre o ao completo. Para mostrar cmo obtener estos datos, completamos a continuacin el Resumen Semanal de Actividades mostrado en la Tabla 4.4. Utilizamos el Resumen Semanal de Actividades de la Estudiante Y para la semana 1, mostrado en la Tabla 4.2. Utilizando estos datos, la seccin de Tiempos y Medias del Perodo de la Tabla 4.4 se completa como vemos a continuacin:
1. Anota el total de semanas transcurridas. Comprueba la fila 11 del resumen semanal de actividades de semanas anteriores para ver cuntas semanas se tuvieron en cuenta. Puesto que la Tabla 4.2 tiene un 1 en la lnea 11, escribe 1 + 1 = 2 en el nmero de semanas de la Tabla 4.4. 2. En las filas 13-16 de la tabla de la semana actual (Tabla 4.4), copia todas las entradas de las filas 18-21 de la tabla de la semana anterior (Tabla 4.2).
3. Suma los tiempos dedicados a cada tarea en la semana actual. En cada columna de la fila 18 de la Tabla 4.4 anota el resultado de sumar las filas 13 y 10. Para la primera columna, Clase, dicho resultado es 150 + 150 = 300. Para la segunda columna, Codificar Programas, obtenemos 339 + 341 = 680. Haz lo mismo para el resto de columnas. Cada columna de la fila 18 muestra ahora el tiempo total dedicado a cada tarea en las dos primeras semanas de este semestre.
4. Calcula el tiempo medio dedicado semanalmente a cada tarea durante este semestre. En la fila 19 de la Tabla 4.4, divide el valor de cada columna de la fila 18 por el nmero de semanas. El primer
Las descripciones del material de apoyo y las instrucciones para conseguirlo aparecen en la ltima pgina del libro.
'
36
Tabla 4.3 Ejemplo de cuaderno de registro de tiempos para la primera semana.

Estudiante Estudiante Y Profesor sr. Fecha Clase
999 ''6
c51
37
Tabla 4.4 Tiempos y medias del perodo, segunda semana.
11 12
Tiempos y Medias del Perodo
Nmero de Semanas (nmero anterior +l):
Resumen de las semanas anteriores
13 Total
14
Med.
15 Mx.
16 Mn.
17 Resumen incluyendo la ltima semana
150 150
341 341 341 341
134 134 134 134
146 146 146 146
771 771 71 7 771
150
150
18
19
20
21
valor medio es de 300/2=150 y el segundo es 680/2=340. Repite estos clculos para el resto de columnas.
5. Para encontrar el mayor tiempo dedicado a una tarea durante una semana, calcula el tiempo mximo. Calcula el valor Mximo en la fila 20, comparando cada columna de la fila 15 con la misma columna de la fila 10. Anota el valor mayor en la fila 20. Para la columna leer Textos, el valor Mximo anterior era 146 (vase fila 15) y el valor para la semana actual es de 224 (vase fila 10). Puesto que el valor mayor es 224, antalo en la fila 20.
6. Para saber el menor tiempo que has dedicado a una tarea durante una semana, calcula el tiempo mnimo. Para calcular el valor
38
Mnimo de la columna 21, compara cada columna de la fila 16 con la misma columna de la fila 10. Anota el valor ms pequeo en la fila 21. Para la columna Leer Texto, el valor anterior Mnimo era 146 (vase fila 16) y el valor para la semana actual es 224 (vase fila 10). Puesto que 146 es menor, antalo en la fila 21. La fila 21 muestra los tiempos mnimos dedicados cada semana a cada actividad. Observa que ignoras los valores nulos en el clculo de los tiempos mnimos.
7 Observa que, excepto para la primera semana, el Tiempo Total . Mximo y Mnimo sern diferentes.
La columna Preparar Exmenes proporciona un ejemplo de por qu deberas ignorar los valores nulos en el clculo de los tiempos mnimos. Puesto que no se dedic tiempo a esta actividad en esta semana, el tiempo medio tiene un valor de 67 minutos. As, la Estudiante Y dedic 134 minutos una semana y cero la siguiente, dando un valor medio 67 minutos. El valor Mximo se calcula como hemos visto antes, pero el valor Mnimo cero no es til. La razn es que para la actividad de Preparar Exmenes ya sabes que no le dedicars tiempo durante muchas semanas del semestre. As el valor cero para el Mnimo no aade nueva informacin. Puede ser interesante, sin embargo, saber que cuando estudiaste para los exmenes, el tiempo mnimo que dedicaste fue de 134 minutos. Puesto que solamente quieres saber la cantidad mnima de tiempo dedicado cuando hiciste esta tarea, sustituye el valor Mnimo en la fila 16 por un valor mayor de cero en la fila 10.
Las orientaciones para completar el Resumen Semanal de Actividades aparecen en las Tablas 4.5 y 4.6.
LA UTILIZACIN DEL RESUMEN SEMANAL DE ACTIVIDADES

Para completar esta Tabla, cada semana tendrs que calcular el tiempo medio, mximo y mnimo que has dedicado a cada actividad cada semana. Aunque esta tabla puede parecer un poco complicada, despus de un poco de prctica, ser inmediata. Vers que es una forma sencilla de organizar y conservar una gran cantidad de datos de tiempos. Si utilizas una hoja de clculo para hacer estos clculos, ser an ms fcil.
Los datos en el Resumen Semanal de Actividades te ayudarn a entender cmo gastas tu tiempo. Con esta informacin, por ejemplo, podras estimar que una gran tarea probablemente se realizar en el tiempo mximo y una tarea sencilla se realizar en el tiempo mnimo. Puedes utilizar estos datos para planificar las semanas subsiguientes. La planificacin se discute en los captulos siguientes.
39
Tabla 4.5 Instrucciones resumen semanal de actividades (1) Resumen semanal del tiempo.
Propsito
Esta tabla se utiliza para controlar y analizar el tiempo gastado durante este curso. Estos datos se obtienen del Cuaderno de Registro de Tiempos. Resume los datos del Cuaderno de Registro de Tiempos al final de cada semana. Si la clasificacin de las tareas no es adecuada, cmbialas. Si no tienes suficientes columnas para todas las tareas, utiliza copias de la tabla. Introduce los siguientes datos: Tu nombre. La fecha actual. Anota los nombres de las principales tareas a las que dedicars tu tiempo durante este curso. Clases, Codificar Programas, Revisar exmenes, Leer libros, etc. Con D (Domingo), anota la fecha para ese da. 819 Para cada da de la semana, determina el tiempo total dedicado a cada tarea descrita en el Cuaderno de Registro de Tiempos. Anota este nmero en la columna correspondiente para ese da. Para el lunes, 919, los tiempos de Codificar Programas del Cuaderno de Registro de Tiempos eran 38 y 58 minutos. Anota la suma (96 minutos) en la fila 4 del lunes 919. Anota en la fila 10 el total para cada tarea durante una semana completa. 96+62+69+114=341 en la fila 10 columna Codificar Programas. Para cada fila, anota el total de los tiempos de las tareas para un da dado, columna de la derecha. Si tienes varias tablas, anota el total de todas las tablas en la columna situada ms a la derecha (en la primera tabla). 50+96+80=226 para el Total del Lunes 919 Calcula el total de los tiempos dedicados durante una semana y antalos en la columna y fila de Total para esa semana.
226+62+147+114+88+134=771 es el total semanal. __ __ -~ 150+341+134+146=771 total de las tareas (fila 10). Puesto que es igual al total de la columna de la derecha no hay error.
Mtodo
Cabecera
Tarea Ejemplo Fecha Ejemplo Columnas
Ejemplo
--
,
r
Totales Semana (filalo) Ejemplo
__ Totales
Ejemplo Primera Comprobacin

~-
__ Comprobacin Final
Ejemplo
Aunque al principio aprenders mucho del Resumen Semanal de Actividades, pronto suministrar poca informacin cada semana. Cuando llegues a este punto, prepara un Resumen Semanal de Actividades una vez
40
Tabla 4.6 Instrucciones resumen semanal de actividades (2) Resumen de medias, mximos y mnimos.
Propsito Esta tabla se utiliza para controlar y analizar el tiempo dedicado a este curso. Estos datos se obtienen del Cuaderno de Registro de Tiempos. Estas instrucciones son una continuacin de las vistas en las Instrucciones Resumen Semanal de Actividades (1). Pasa la cabecera y el resto de informacin consulta las instrucciones de la Tabla 4.5. Este es el nmero de semanas incluidas en el resumen de datos. Consulta el Nmero de Semanas en la fila 11 para ver cuantas semanas previas se han acumulado. Suma uno a dicho nmero, y anota el total. Para las filas 13 a 16, copia, columna a columna, los datos de las filas 18 a 21 de los resmenes de semanas anteriores. Incluye las filas de Total, Media, Mx. y Mn. para cada columna, incluyendo la columna total. Para calcular los valores de la fila 18, suma las cantidades de las filas 10 y 13. Haz esto para cada columna de esta tabla. En la Tabla 4.4, el valor de la columna Codificar Programas para la fila 18 se calcula as, 339+341=680. El valor medio se calcula dividiendo los valores de la fila 18 en cada columna por el nmero de semanas de la fila 11. En la Tabla 4.4, el valor medio de Codificar Programas es 680/2=340. Los valores de la fila 20 se obtienen comparando los valores de la fila 15 con los de la fila 10. Anota el valor mayor de los dos nmeros. Haz esto para cada columna, incluyendo la columna Total. En la Tabla 4.4 y para Codificar Programas, el valor Mximo era 341 y el valor para esta semana es 339, por lo que el valor Mximo sigue siendo 341. En la Tabla 4.4 para Leer Libros, el valor Mximo era 146 y el valor para esta semana es 224, por lo que el nuevo valor mximo es 224.
Mtodo
Nmero de semanas (fila 11)
Tiempos Hasta la Fecha (filas 13-16)
Total Tiempos Actuales (fila 18) Ejemplo Media Tiempos Actuales (fila 19) Ejemplo Mximo Tiempo Actual (fila 20) Ejemplo
Otro Ejemplo
Mnimo Tiempo Actual (fila 21) Ejemplo
Los valores de la fila 21 se obtienen comparando los valores de las filas 16 y 10. Anota el valor ms pequeo superior a cero. Haz esto para cada columna, incluyendo la columna Total.
En la Tabla 4.4 y para la actividad Codificar Programas, el valor Mnimo era 341 y el valor para la fila 1O es 339, el nuevo valor Mnimo sigue siendo 339. En la Tabla 4.4 y para la actividad Leer Libros, el valor Mnimo era 146 y el valor para la fila 10 es 224, el nuevo valor Mnimo sigue siendo 146. En la Tabla 4.4 y para la actividad Preparar Exmenes, el valor Mnimo era 134 y el valor para la fila 10 es O, el nuevo valor Mnimo sigue siendo 134.
Otro Ejemplo
Un ejemplo ms
41
al mes o comprueba que la distribucin actual de tiempos es la adecuada. Tambin, una vez que hayas reunido los datos de proyectos en el Captulo 5 y posteriores, sabrs cunto tiempo dedicas a los proyectos y podrs reunirlos en el Resumen Semanal de Actividades cuando lo necesites. En la prctica he pasado a utilizar un Resumen Mensual de Actividades para controlar el tiempo que he dedicado a mis dos principales actividades: escribir libros y realizar otros proyectos. Puesto que escribo libros en mi tiempo particular y hago proyectos en mi tiempo en la empresa, es importante saber cunto tiempo particular y de proyectos puedo esperar tener disponible durante cualquier semana o mes. Esto me ayuda a hacer los planes con precisin y cumplir compromisos. Para este propsito, una revisin mensual es suficiente. Sigo encontrando til resumir mi tiempo cada mes.
RESUMEN
Este captulo muestra como la planificacin de perodos y de productos estn relacionados y describe la planificacin del perodo. El primer paso en la planificacin del perodo es entender tus datos de tiempos. Comienza con datos de tiempos bsicos a partir del Cuaderno de Registro de Tiempos y haz un Resumen Semanal de Actividades para cada semana. El Resumen Semanal de Actividades proporciona un registro del tiempo dedicado a cada actividad y el tiempo medio, mximo y mnimo dedicado a cada actividad durante un semestre. Finalmente, puedes dejar de resumir los tiempos semanales y hacer un resumen cuando tu distribucin de tiempos cambie o consideres interesante resumir mensualmente tus tiempos.
EJERCICIO 4
Completa y entrega el Resumen Semanal de Actividades para las dos semanas anteriores. Utiliza los registros diarios de tiempos para rellenar esta tabla. Entrega una copia de las pginas de tiempos registrados que no hayas entregado todava.
CAPITULO 5
La planificacin de/ producto
Este captulo describe cmo utilizar los datos de los registros de tiempos para hacer planes del producto. La nueva tabla, el Cuaderno de Trabajos se introduce para ayudar a registrar los datos histricos del producto. Tambin se muestra un ejemplo de cmo rellenar la tabla. En cuanto al ejercicio, consistir en rellenar el Cuaderno de Trabajos con las tareas que hayas hecho hasta ahora en el curso.
5.1
LA NECESIDAD DE LOS PLANES DEL PRODUCTO

Hace algunos aos, cuando trabajaba en IBM, estaba encargado del departamento de desarrollo de grandes proyectos software. Muchos de los proyectos se retrasaban bastante y el director estaba preocupado. Mi trabajo consisti en arreglar la complicada situacin. La primera cosa que hice, fue revisar los proyectos principales. Me sorprend de que ninguno tuviese planes documentados. Inmediatamente, insist en que todos los ingenieros hiciesen planes para todos sus proyectos. Ninguno de ellos haba preparado anteriormente un plan formal, y les llev un par de meses hacerlo. Se impartieron clases sobre planificacin de proyectos, ellos hicieron sus planes, y entonces pudimos establecer programaciones realistas para su trabajo.
44
LA PLANIFICACIN DEL PRODUCTO
El acto de hacer planes tiene un efecto sorprendente: este grupo de desarrollo nunca haba entregado anteriormente un producto a tiempo. Con sus nuevos planes, no se equivocaron en una fecha durante los dos aos y medio siguientes. Desde entonces, han estado planificando su trabajo. La planificacin es una parte crtica del trabajo del ingeniero del software, y por lo tanto para ser un ingeniero del software, tienes que saber cmo hacerla. La clave est en la prctica, para adquirirla, comienza haciendo planes ya y contina hacindolos en todos tus proyectos futuros.
5.2
POR QU SON TILES LOS PLANES DEL PRODUCTO

En este libro, sugiero que desarrolles planes de producto para todos tus proyectos o tareas ms importantes: codificar un programa, leer un libro o preparar un informe. El plan del producto te ayudar a decidir cunto tiempo necesitas para hacer tu trabajo y cundo lo acabars. Los planes, tambin ayudan a controlar el progreso mientras se est haciendo el trabajo. Cuando los ingenieros trabajan en equipos de desarrollo, necesitan planificar su trabajo personal. La planificacin proporciona una slida base para comprometerse a unas fechas de entrega, y permite a los ingenieros coordinar sus trabajos con los productos. Sus planes individuales del producto, les permiten cumplir las fechas para cada una de sus tareas interdependientes y cumplir sus compromisos de forma consistente. En los negocios se utilizan los planes del producto por las mismas razones que lo vas a hacer t: para planificar y gestionar el trabajo. Un plan bien hecho incluye una estimacin del coste del proyecto. Las estimaciones son esenciales para contratar desarrollos, ya que los clientes necesitan saber el precio por adelantado. Las estimaciones tambin son necesarias cuando se desarrollan productos. El coste del proyecto es la parte ms importante del precio de un producto y debe ser lo bastante bajo para que el precio sea competitivo en el mercado. Los ingenieros tambin utilizan los planes del producto para entender el estado de su proyecto. Con planes razonablemente detallados y precisos, pueden juzgar dnde se encuentra el proyecto frente al plan. Puede ser, que estn retrasados y necesiten ayuda, o que tengan que retrasar la programacin. Pero tambin pueden ir ms adelantados con respecto a lo planificado, y ser capaces de ayudar a sus compaeros o entregar antes. Cuando los ingenieros hacen planes pueden organizar mejor su tiempo, y evitar las crisis en los ltimos minutos. Entonces es menos probable que cometan errores y generalmente producirn mejores resultados. Puesto que la planificacin es tan importante, necesitas conocer cmo hacer planes precisos. Y tambin, saber compararlos con tus resultados reales, para que puedas aprender a hacer mejores planes.
45
5.3
QU ES UN PLAN DEL PRODUCTO?

El primer paso para hacer un plan del producto, es tener una definicin clara del producto que quieres producir. Aunque esto parece obvio, es sorprendente como con frecuencia la gente se sumerge en los mecanismos de desarrollo del producto antes de definir qu estn intentando hacer. nicamente despus de saber qu quieres hacer, podras comenzar a pensar cmo hacerlo. En este momento comienza la planificacin. Un adecuado plan del producto requiere tres cosas: El tamao y las caractersticas ms importantes del producto a realizar. Una estimacin del tiempo requerido para hacer el trabajo. Una previsin de la planificacin. El producto podra ser un programa ejecutable, un diseo de un programa o un plan de pruebas. Un plan del producto identifica el producto a hacer y contiene estimaciones del tamao del producto, las horas de trabajo a realizar y la programacin. Productos ms complejos requieren una planificacin ms sofisticada y ms tipos de informacin, tales como asignacin de responsabilidades, planes de personal, especificaciones de procesos o productos, dependencias con otros grupos, pruebas especiales y cuestiones de calidad. En este libro, sin embargo, trataremos solamente los tres elementos bsicos del plan: estimaciones de tamao, horas previstas y programaciones.
5.4
LA PLANIFICACIN DEL PRODUCTO EN ESTE LIBRO

La planificacin del producto es una habilidad que puede mejorarse con la prctica. Si como estudiante empiezas ahora a hacer planes, desarrollars tus habilidades de planificacin. As, cuando necesites elaborar un plan para un proyecto importante, sabrs cmo hacerlo. En este captulo, deberas hacer un plan para cada tarea principal. Y en el Captulo 10, sabrs hacer planes ms globales para desarrollar programas. En este libro, empezamos planificando pequeos trabajos, porque esta es una buena manera de aprender a planificar. Despus de todo, si no puedes planificar una tarea pequea, cmo podrs planificar un gran proyecto? Los ingenieros en su trabajo hacen muchas tareas pequeas como parte de un gran trabajo. As, si planificas cada una de estas pequeas tareas, tendrs ms oportunidades de desarrollar tus habilidades de planificacin. En grandes trabajos, puedes integrar estos pequeos planes en un gran plan, para el trabajo completo. Esta es la forma ms efectiva de hacer planes exactos para grandes trabajos.
46
5.5
LA PLANIFICACIN DE PEQUEOSTRABAJOS
Es importante hacer un plan que se adecue a la magnitud y complejidad del trabajo a realizar. Tendra poco sentido, por ejemplo, hacer un plan sofisticado para una tarea que necesitara una o dos horas. A la inversa, con una tarea que necesitase varias semanas, un plan ms elaborado est justificado.
El plan del producto ms bsico consistir nicamente en estimar el tiempo necesario para hacer una tarea o trabajo. Una vez que puedas estimar con precisin el tiempo para hacer el trabajo, todas las otras cuestiones de planificacin se pueden hacer de una forma bastante fcil. Reuniendo datos sobre la duracin de varias tareas realizadas anteriormente, puedes predecir para unas tareas de duracin similar, cunto tiempo necesitarn en el futuro. Esta aproximacin se puede aplicar a casi cualquier tarea relacionada con un producto que necesite de unas pocas horas a unos pocos das para su realizacin. Por ejemplo, si planificas leer un captulo de un libro, sera til saber cunto tiempo necesitaste en leer los captulos anteriores. Con los datos de los tiempos de lectura medio, mximo y mnimo, puedes predecir mejor tu tiempo de lectura para un nuevo captulo.
5.6
ALGUNAS DEFINICIONES
Antes de continuar, necesitamos definir algunos trminos: Un producto es algo que produces para un compaero, un empresario o un cliente. Un proyecto normalmente produce un producto. Una tarea se define como un elemento de trabajo. Un proceso se define como la forma de hacer proyectos. El Captulo 11 trata de una forma ms detallada los procesos.
Los planes describen la forma en que un proyecto concreto va a ser hecho: cmo, cundo y qu coste tendr. Tambin puedes planificar tareas individuales.
Un trabajo es algo que haces, tanto un proyecto como una tarea.
5.7
EL CUADERNO DE TRABAJOS
El Cuaderno de Trabajos que se muestra en la Tabla 5.1 se dise para registrar los datos de tiempos estimados y reales. Obsrvese que este cuaderno es un documento de planificacin del producto, ya que trata datos
47
del producto. A la inversa, el Cuaderno de Registro de Tiempos y el Resumen Semanal de Actividades contienen datos de planificacin de perodos. Las entradas en el Cuaderno de Trabajos se hacen como se muestra en la Tabla 5.2. Este ejemplo utiliza datos del Cuaderno de Registro de Tiempos de la EstudianteY de la Tabla 5.3. Las instrucciones del Cuaderno de Trabajos se muestran en la Tabla 5.4. Obsrvese que en el Cuaderno, la Estudiante Y controla dos actividades generales: asistir a clases y preparar exmenes. Tambin controla dos actividades importantes: codificar programas y leer captulos del libro. Las casillas en la Tabla 5.2 se completan de la siguiente manera:
1. Trabajo
Cuando ests planificando una actividad, asgnale un nmero de trabajo comenzando por 1. Escribe la fecha de comienzo del trabajo. Escribe el tipo de tarea, tal como leer un libro, codificar un programa o preparar un informe. Calcula el tiempo que crees que gastars en hacer esa tarea y antalo en la columna de Tiempo Estimado. Para hacer esta estimacin, examina los datos de proyectos similares anteriores y utilzalos. Obsrvese que para la estimacin del programa 6 (trabajo 1 O), la Estudiante Y utiliz el tiempo medio de los programas 1-5. Encontr un valor de 105,s minutos observando las Velocidades Hasta la Fecha de programas anteriores (trabajo 8). Para las unidades elementales de trabajo, escribe un 1 en la columna de Unidades Estimadas. En el prximo captulo se introducen medidas de tamao ms refinadas. Al terminar el trabajo, anota el tiempo que le has dedicado. Para el trabajo 10, este tiempo fue de 151 minutos.
2. Fecha
3. Proceso
4. Tiempo estimado
5 . Unidades estimadas
6. Tiempo real
48
7.Unidades reales
Cuando termines el trabajo, registra las unidades reales. Aqu, debera ser una por cada trabajo. En el captulo siguiente, se utiliza una medida del tamao para las unidades de trabajo. La velocidad real es el Tiempo Real dividido por las Unidades Reales. Para el programa 6 (trabajo 10) la Velocidad Real es 151/1 = 1.51 minutos por programa. Al acabar el trabajo, calcula y anota el Tiempo Hasta la Fecha para todas las tareas realizadas hasta la fecha para el mismo proceso. Por ejemplo, con 151 minutos para el Tiempo Real para el programa 6 y un Tiempo Hasta la Fecha para los programas 15 de 529 minutos (vase trabajo S), el Tiempo Hasta la Fecha para el programa 6 es 151 + 529 = 680 minutos. Anota las Unidades Hasta la Fecha para todas las tareas de cada tipo que hayas finalizado. Con el programa 6, aade las Unidades Reales para este trabajo a las Unidades Hasta la Fecha para los trabajos ms recientes de este tipo (de nuevo, el trabajo 8): 5 + 1 = 6.
8. Velocidad real
9. Tiempo Hasta la Fecha
10. Unidades Hasta la Fecha
11. Velocidad Hasta la Fecha La Velocidad Hasta la Fecha es el Tiempo Hasta la Fecha dividido por las Unidades Hasta la Fecha, es decir 680/6 = 1 13,3 minutos por programa. Este es el tiempo medio dedicado a hacer un trabajo de este tipo.
12.Mximo Hasta la Fecha
Para encontrar la velocidad mxima para cualquier tarea, compara la Velocidad Real de los trabajos ms recientes con el Mximo Hasta la Fecha de los trabajos previos del mismo tipo y anota el valor. Para el programa 6, el Mximo Hasta la Fecha para el programa 5 (trabajo 8) es 158 minutos por unidad, que es mayor que la Velocidad Real de 151 minutos
49
por unidad para el programa 6, por lo tanto escribe 158 para el programa 6 en el Mximo Hasta la Fecha.
13. Mnimo Hasta la Fecha
El valor Mnimo Hasta la Fecha es la velocidad mnima para cualquier tarea de un tipo dado. Para determinar este valor, compara la Velocidad Real del trabajo con el Mnimo Hasta la Fecha de los trabajos ms recientes de este tipo y escribe el valor menor. Para el programa 6, por ejemplo, la Velocidad Real de 151 minutos por unidad es mayor que los 69 minutos por unidad para el Mnimo Hasta la Fecha del programa 5 (trabajo 8), por lo que el programa 6 mantiene el valor de 69 en el Mnimo Hasta la Fecha.
Con estos datos puedes consultar la velocidad media para cualquier tarea dada, as como las velocidades mxima y mnima. La ventaja principal del Cuaderno de Trabajos es que proporciona una forma concisa de registrar y acceder a una gran cantidad de datos histricos de proyectos. Como vers, es la clave para hacer estimaciones exactas. Las estimaciones exactas, son a su vez la clave para hacer buenas planificaciones.
5.8
ALGUNAS SUGERENCIAS SOBRE CMO UTILIZAR EL CUADERNO DE TRABAJOS

Las siguientes prcticas deberan ayudarte a hacer una utilizacin ms efectiva del Cuaderno de Trabajos: Para el primer trabajo de un tipo dado, la Estudiante Y no tena datos previos para guiar sus estimaciones. Ella las tuvo que predecir. Suponer la primera vez est bien, pero conforme vayas reuniendo datos ya no tienes que seguir adivinando. En general para la estimacin del tiempo de un nuevo trabajo, querrs utilizar la Velocidad Hasta la Fecha del trabajo del mismo tipo realizado recientemente. La Estudiante Y hizo esto. Para el trabajo 6, la Estudiante Y no utiliz el valor de 36 minutos por captulo para la Velocidad hasta la Fecha. Presumiblemente, pens que el Captulo 4 le llevara ms tiempo leerlo que la media de los captulos anteriores. Estaba en lo cierto, y le llev ms tiempo que el esperado. Es importante recordar que los datos del Cuaderno de Trabajos estn para ayudarte a hacer planes.
50
Tabla 5.1 El cuaderno de trabajos.

Nombre: Fecha:
Descripcin: DescriDcin:
Ten en cuenta las cantidades, sin embargo, si t crees que una estimacin ms grande o ms pequea es ms precisa, utiliza tu experiencia.
51
Trabajo Fecha Proceso
Estimado
Real
Hasta la Fecha
10
11
1919
12
1 Cod. 1106 1 1 1 151 1 1 1 151 20/91 Texto] 59 1 1 1 40 1 1 1 40 Descripcin: Leer el Captulo 6 del libro de texto 2 1 1 Texto 1 56 1 19 1 1
Descriocin: Escribir el proarama 6
8 -
Descripcin: Leer el Captulo 5 del libro de texto
1600
1
[
1337
1 113,3 1 1 562 1
150
18 1
69
28
DescriDcin: Leer el Captulo 7 del libro de texto
Descripcin: Descripcin: DescriDcin:
Para encontrar rpidamente todas las entradas en el Cuaderno de Registro de Tiempos para un nmero de trabajo dado, es til aadir el n-
52
Tabla 5.3 Ejemplo del cuaderno de registro de tiempos.

Estudiante
Estudiante Y
Fecha
Clase
Profesor
ComienFecha zo
919
5r.
9/9/96 IP
Fin
Tiempode interrupci6n
Tiempo Actividad Commentarios

50 30
Clase
c u
~
9O : O 9:50 1240 1:10
Clase Eiercicio 1
9O : O 4:21 11 9 9 651 2019 9O : O 12:33 1:24 21 19 1:0 11 1019
9:50 5:43 9:21 9:50 11 :0 2:30 1:1 15
11
51+16+6 5
50 7 1 77 50 40 74 33
Clase
9 1 0
Clase
11 1 0 12
Clase Texto Cap. 5, descanso Ejercicio 6 Ciase Texto Cap.6, descanso Ejercicio 6 Texto Cap. 7
x 1
mero de trabajo en la columna Actividad del Cuaderno de Registro de Tiempos, tal como se muestra en la Tabla 5.3. En efecto, encontrars ms
53
Tabla 5.4 Instrucciones para el cuaderno de trabajos.

Propsito Esta tabla se utiliza para controlar los trabajos de cada proyecto. Registra la informacinclave de cada proyecto. Un proyecto es cualquier actividad que deseas controlar, cmo desarrollar un programa o escribir un artculo. Cuando comiences un proyecto, anota el nmero de trabajo en este cuaderno. Anota los nmeros comenzando desde 1. Introduce los siguientes datos: Tu nombre. La fecha de comienzo de este Cuaderno de Trabajos. Anota el nmero de trabajo que has seleccionado. Anota la fecha de inicio del trabajo Anota el tipo de tarea. Por ejemplo, para un trabajo tcnico anota Artculo, para desarrollar un programa, utiliza Cod., etc. Anota el tiempo total en minutos que se estim para ese trabajo. Utiliza los valores de Velocidad Hasta la Fecha, Mximo y Mnimo como gua. Si estas velocidades no son razonables, utiliza tu experiencia. Anota las unidades estimadas para el trabajo acabado. Cuando hagas una tarea, escribe 1 en las Unidades. Anota el tiempo total real para el trabajo realizado. Anota el nmero real de unidades totales. De nuevo, escribe 1 unidad para cada trabajo acabado. Anota el Tiempo Real dividido por las Unidades Reales. Localiza el trabajo del mismo tipo que tu nuevo trabajo. Suma al valor de Tiempo Hasta la Fecha de este trabajo el Tiempo Real para el nuevo trabajo. Anota este total en la casilla de Tiempo Hasta la Fecha para el nuevo trabajo. Localiza el trabajo del mismo tipo que tu nuevo trabajo. Suma las Unidades Hasta la Fecha de este trabajo a las Unidades Reales para el nuevo trabajo. Anota este total en la casilla de Unidades Hasta la Fecha para el nuevo trabajo. Divide el tiempo Hasta la Fecha por las Unidades Hasta la Fecha para obtener los minutos por unidad para todos los trabajos terminados hasta la fecha. Anota este nmero en la casilla Velocidad hasta la Fecha, para este trabajo. Anota la velocidad mxima para todos los trabajos de cada tipo que hayan acabado. Anota la velocidad mnima para todos los trabajos de cada tipo que hayan acabado. Anota una descripcin del trabajo que se ha hecho. S suficientemente claro para que el contenido del trabajo pueda ser fcilmente identificado.
Mtodo
Cabecera
Tiempo Estimado
Unidades Estimadas Tiempo Real Unidades Reales Velocidad Real Tiempo hasta la fecha
Unidades hasta la fecha
Velocidad hasta la fecha
Mx. Mn. Descripcin
54
adecuado dejar todos los tipos de actividades y referenciarlas por sus nmeros. Seguiremos esta prctica en los ejemplos restantes de este libro. Despus de aprender a utilizar el Cuaderno de Trabajos, probablemente encontrars ms adecuado utilizar una hoja de clculo para hacer los clculos. Un ejemplo de hoja de clculo de este tipo se incluye en el material de apoyo de este libro. Las instrucciones para conseguir dicho material se indican en la ltima pgina del libro.
5.9
LA UTILIZACIN DE TIEMPOS Y MEDIAS DEL PRODUCTO

Supongamos que tienes los datos de la Tabla 5.2 y quieres planificar tu tiempo para la prxima semana. Puedes, por ejemplo, planificar, codificar dos programas y leer cuatro captulos. Puedes saber que uno de los programas es ms complejo que cualquiera de los que hayas codificado hasta ahora y el otro se parece a la media. Para estimar los tiempos para codificar estos dos programas, observa en la Tabla 5.2 el trabajo 10. Aqu, el tiempo medio para codificar los seis primeros programas es de 113,3 minutos, un poco menos de 2 horas. El tiempo mximo ha sido 158 minutos o aproximadamente 2 horas y media. Para un programa medio es probable que se necesiten 2 horas y para el ms complejo alrededor de 158 minutos o ms. Para estar ms seguro, supn que el programa complejo necesitar 3 horas y media, o sea 21 O minutos. Esto da un total de 330 minutos de programacin para la prxima semana. Para los captulos del libro, consideras que dos captulos sern de tipo medio y los otros dos necesitarn un poco ms de tiempo. De los datos del Trabajo 11, los tiempos medios para leer captulos han sido de 56,2 minutos. Puedes asumir que leers los dos captulos intermedios en una hora cada uno. Para los captulos ms complejos, sin embargo, necesitars el tiempo mximo de 118 minutos, unas dos horas por captulo. En total, prevs dedicar durante la prxima semana unas 5 horas y media a codificar programas y 6 horas para leer el libro. Con esta informacin, puedes mejorar la planificacin para estos trabajos. Como vers pronto, los tiempos para las tareas pequeas variarn considerablemente tus estimaciones. Esto es normal. La clave para una buena estimacin, sin embargo, es aprender a hacer estimaciones equilibradas. Un conjunto equilibrado de estimaciones tiene en cuenta las sobreestimaciones y las subestimaciones. En el ejemplo de la Tabla 5.2,5 de las 11 estimaciones fueron bajas, 5 altas y el trabajo 5 se hizo en el tiempo previsto. Las estimaciones bajas fueron las de los trabajos 1, 2, 6, 9 y 10, las otras cinco estimaciones fueron altas. La Estudiante Y haba aprendido a hacer estimaciones equilibradas. Hizo esto, utilizando sus ve-
55
locidades medias anteriores para estimar un nuevo trabajo. Mientras hagas esto con coherencia y tus trabajos sean razonablemente similares, pronto hars estimaciones equilibradas. La ventaja de hacer estimaciones equilibradas es que, en promedio, tus trabajos durarn aproximadamente lo que hayas estimado. Es decir, cuando un trabajo se realice en ms tiempo, se compensar con otro que necesite menos tiempo. Cuando ests estimando grandes trabajos como agrupaciones de muchos trabajos pequeos, es ms probable que consigas una aproximacin razonable al plan global.
RESUMEN
Los planes del producto te ayudan a resumir y gestionar datos de tiempos para los productos que planificas hacer: codificar un programa, redactar informes, leer captulos de libros y estudiar para los exmenes. El Cuaderno de Trabajos es una herramienta para controlar el tiempo dedicado a cada tarea. Los clculos del Cuaderno de Trabajos utilizan datos de tiempos del Cuaderno de Registro de Tiempos.
Cuando lo completes, el Cuaderno de Trabajos te proporciona los tiempos medio, mximo y mnimo que dedicas a terminar cada uno de tus proyectos hasta ese momento. Puedes utilizar esta informacin para planificar el trabajo de la prxima semana o para hacer planes ms sofisticados que se requieran en captulos posteriores.
EJERCICIO 5
Completa y entrega el Cuaderno de Trabajos para el trabajo que hayas hecho hasta ahora en el curso. Donde hayas estimado datos antalos, de lo contrario, deja el espacio de estimacin en blanco. Utiliza los cuadernos diarios de tiempos para completar estas tablas. Contina hasta completar los datos en el Cuaderno de Trabajos para cada proyecto. Haz una estimacin del tiempo y de las unidades antes de iniciar un trabajo, registra los datos reales y los datos Hasta la Fecha cuando hayas finalizado.
CAPITULO 6
El tamao del producto
Hasta ahora hemos considerado grandes unidades de trabajo, como programas o captulos de un libro. Para hacer planes del producto, necesitas utilizar medidas ms precisas. Este captulo describe cmo medir y estimar el tamao del producto. En el ejercicio del captulo, medirs el tamao de los trabajos que has hecho en los ejercicios anteriores de este libro y calculars tu productividad para ese trabajo.
6.1
EL PROCESO DE PLANIFICACIN DEL PRODUCTO

La planificacin del producto no es un proceso exacto. Aunque hicieses los mejores planes que pudieses, reconoce que estos probablemente sern inexactos. La planificacin es una habilidad que se puede desarrollar y mejorar: desarrolla planes para cada trabajo que hagas, y una vez acabado, compara lo planificado con lo que realmente has hecho. As, entenders mejor los errores cometidos en estos planes y aprenders a hacerlos mejor. Para hacer un plan del producto, compara lo que planificas hacer con lo que has hecho antes. Comienza con datos de trabajos parecidos y compara la nueva tarea con los trabajos anteriores. Busca trabajos previos que hayas hecho del mismo tamao y planificacin. Entonces, basndote en el tamao de los trabajos que anteriormente hayas realizado, estima el tamao del nuevo trabajo a realizar.
58
EL TAMAODEL PRODUCTO
La razn principal para reunir datos de trabajo en este curso, es para saber qu tiempo dedicas a las distintas tareas que haces. Si, por ejemplo, juzgas que una nueva tarea es parecida a dos tareas realizadas anteriormente, y cuya duracin fue de 3 y 4,2 horas respectivamente, probablemente deducirs que la nueva tarea se realizar en un tiempo medio de 3,6 horas. Esta estimacin burda, probablemente ser mejor que una estimacin hecha sin ningn dato histrico.
6.2
MEDIDA DEL TAMAO

Puesto que las tareas, a menudo, varan considerablemente en tamao y complejidad, sera til tener una forma de comparar sus tamaos. Consideremos la lectura de los captulos de un libro de texto. Con los datos del tiempo dedicado a leer cinco captulos, podras estimar el tiempo de leer el Captulo 6. Una forma sera hacer la media de los tiempos de lectura de los captulos anteriores. Aunque esto sera mejor que nada, no podras distinguir entre captulos largos y cortos. Probablemente dedicars menos tiempo a leer un captulo corto que uno largo. Por lo que podras considerar medir en minutos por pgina mejor que en minutos por captulo. Considera ahora, en la Tabla 6.1, los datos de los tiempos de la Estudiante Y dedicados a leer captulos del libro. Los tiempos para leer captulos varan desde 28 a 118 minutos. El cociente entre los tiempos mayores y menores es superior a 4. Cuando mides en minutos por pgina, el rango va desde los 2,33 minutos por pgina para el Captulo 3 a los 7,38 minutos por pgina para el Captulo 4. Esto es todava un rango grande, ya que est entre uno y tres. Aunque habr una variacin considerable, intenta mejorar la estimacin de los tiempos de lectura de los captulos del libro, para ello, basa tu estimacin en el tamao del captulo y en la velocidad media de lectura expresada en minutos por pgina. Para calcular la velocidad media de lectura, suma todos los tiempos de lectura y divide dicho valor por el nmero total de pginas de los captulos: Velocidad media = (80 + 28 + I 18 + 7 I + 40)/(20 + 12 + 16 + 17 + 12) = 337177 = 4,38 minutos por pgina.
6.3
ALGUNAS PRECAUCIONES SOBRE LA UTILIZACIN DE LAS MEDIDAS DE TAMAO

Aunque utilizar las medidas de tamao parece bastante sencillo, hay algunas complicaciones. Primero, algunos documentos son mucho ms di-
59
Tabla 6.1 Tiempos de lectura de captulos de la Estudiante Y.

Estudiante Estudiante Y Profesor 5r. Z Fecha Clase
30/09/96 IP
1
1
1
Captulo
1
1
1
Tiempo de lectura
1
l
Pginas
1
-
Minutosipgina
1
I
l
3
4
28 10 1
'2
1 6
l I
2,33 7,30
~ ~~
5 6
Totales Medias
71
40 337
17
12
4,10 3.33
77
12,03 4,309
5,7 61
fciles de leer que otros. Esto significa que t deberas considerar el tipo de trabajo y no solo su tamao. Tambin, hay una cuestin expuesta anteriormente. Supongamos, por ejemplo, que ests preparndote para un examen. Los tiempos para releer los captulos estudiados anteriormente posiblemente sern inferiores a los tiempos iniciales de lectura. De forma similar, para releer un documento que has escrito, los tiempos de lectura podran variar significativamente, dependiendo de la atencin que se preste. Para una redaccin inicial del borrador de un documento, puedes dedicarle de 15 a 20 minutos. Una hojeada rpida al documento completo, sin embargo, necesitara un minuto por pgina o menos. Cuestiones similares se presentan en la planificacin del desarrollo de programas. Las productividades para diferentes clases de trabajo, tales como la reutilizacin de programas desarrollados previamente, la modificacin de un programa existente o el desarrollo de nuevos programas, sern bastante diferentes. Para tratar estas cuestiones, deberas guardar de forma separada los registros de tamao y tiempo para las distintas clases de trabajo que haces.
6.4
EL TAMAO DE UN PROGRAMA
Cuando ests estimando el tiempo requerido para codificar un programa, basa las estimaciones en los tiempos que anteriormente has dedicado a codificar programas parecidos. Como se muestra en la Tabla 6.2, los tiempos de la Estudiante Y para codificar programas oscilan en un rango de 69 a 158 minutos. Aunque este es un rango algo superior al doble, este aumentar en el futuro, cuando la Estudiante Y codifique programas ms
60
EL TAMAO DEL PRODUCTO
Tabla 6.2 Tiempos de desarrollo de programas de la Estudiante Y.

30109l96
IP
grandes. De nuevo, es una buena idea basar las estimaciones de tiempo en el tamao del programa. La medida que utilizamos para el tamao del programa, es la lnea de texto del programa fuente. As, si el programa tiene 16 lneas, el programa tiene 16 lneas de cdigo (LOC, acrnimo de Lines Of Code). Al contar las LOC, se asume que no se cuentan las lneas en blanco o las lneas de comentarios. Aunque podras escoger cualquier estndar coherente, en este libro contaremos las lneas de cdigo sin contar las lneas en blanco o las lneas de comentarios. As, el siguiente fragmento de programa en Ada. tiene 5 LOC.
Ejemplo 1 _ - c o m e n t a r i o que d e s c r i b e l a f u n c i n d e l programa

I f (X-Media
>= 100) t h e n
Tamao := X-Media; else Tamao := X-MediaI2; end i f ;
De forma similar, si escribes ese mismo fragmento de programa sin comentarios y en un formato ms comprimido, podras tener 3 LOC:
Ejemplo 2
If (X-Media
>= 100) t h e n
Tamao : = X-Media; e l s e Tamao := X_Media/2; end i f ;
61
Aunque son programas idnticos y sus tiempos de desarrollo podran ser los mismos, sus tamaos son diferentes con este mtodo. Mientras mantengas la coherencia en la forma de codificar programas, estas variaciones de contabilizar no son importantes. Para asegurar que los tamaos contados sean coherentes, te sugiero que adoptes una forma normalizada para codificar los programas. Aunque sigas el formato propuesto por tu profesor, personalmente prefiero el formato ms abierto que se muestra en el Ejemplo 1. La medida de las LOC es aplicable a muchos lenguajes de programacin. Por ejemplo, el mismo fragmento del programa en C++, sera el siguiente:
Ejemplo 3
/ / comentario que describe la funcin del programa
if (X-Media >= 100) Tamatio := X-Media; else Tamao : = X-MediaI2;
Cuando escribas de esta forma, este fragmento de cdigo de C++ tendr 4 LOC. El siguiente fragmento de cdigo C++ , ligeramente superior tiene 12 LOC:
Ejemplo 4
while (n>0)
1
push(n); cout << "Introducir un entero positivo. \ n " ; cout << "Introducir 0 para terminar. \ n " ; cin >> n:
1
/ / Sacar de la pila
while (stack-pointer ! = NULL)

{
cout.width(8); cout << pop ( ) ;

}
Utilizando la tcnica de las LOC para medir, los tamaos de los seis programas se muestran en la Tabla 6.2. El rango de minutos por lnea de cdigo (LOC) vara desde 6,27 del programa 2 a 9,3 para el programa 4.
62
Puesto que tus tiempos en minutos por LOC cambiarn bastante con la experiencia, deberas revisar la media de minutos por LOC y basar las estimaciones en las medias ms recientes de los ltimos 5- 1 O programas.
6.5
OTRAS MEDIDAS DEL TAMAO

Aunque no las utilicemos en este libro, hay muchas otras medidas del tamao del software. Por ejemplo, el desarrollo industrial del software generalmente implica documentacin, que se podra medir en pginas. Incluso para los programas, la medida de LOC no cubre todos los casos. Ejemplos de tipos de productos donde la LOC no es adecuada son los mens, los ficheros, las pginas de informes o las pantallas. A no ser que puedas concebir una adecuada medida del tamao, deberas utilizar la contabilizacin de las unidades y las tasas vistas en el Captulo 5. Tambin, si estas utilizando una herramienta de apoyo en el desarrollo de un programa que genera varias clases de pantallas, ventanas u otros elementos de programa estndar, la contabilizacin puede ser un poco ms delicada. Aqu, es importante contar solamente las LOC que desarrolles y no las LOC generadas por las herramientas de apoyo de la programacin. Sin tener en cuenta las medidas utilizadas, el objetivo principal, es estimar el trabajo a desarrollar. Para esto, necesitas medidas de tamao que relacionen el trabajo requerido, con el producto a desarrollar. Es decir, los desarrollos de productos que necesitan ms tiempo deberan tener medidas de tamao proporcionalmente mayores.
'
6.6
LA ESTIMACIN DEL TAMAO DEL PROGRAMA

Aunque ahora pareciera que puedes estimar el tiempo de codificar un programa, no es tan sencillo. Para leer los captulos de un libro, podras contar las pginas y utilizar la media histrica de minutos por pgina, para calcular el tiempo probable de lectura. Puedes clasificar los captulos por dificultad de lectura y asignar una velocidad de minuto por pgina algo mayor para aquellos captulos que parezcan ms complejos o impliquen una materia con la que se est menos familiarizado. Hojeando los nuevos captulos, valoras su dificultad relativa y eliges una tasa (minutodpgina) basada en experiencias anteriores.
Para una discusin completa de las medidas y estimaciones del tainaio, vanse los Captulos 4 y 5 de mi libro A Discipline for Sojhvare Enginnering (Reading, MA: Addison-Wesley, 1995).
'
63
Para codificar programas, sin embargo, no es posible una contabilizacin de los mismos hasta que no los has desarrollado. Para estimar el tiempo de codificar un programa, tienes que estimar en primer lugar cuntas LOC requerir y a partir de ah, el nmero de minutos por LOC que probablemente necesitars para desarrollarlo. Puedes entonces calcular el tiempo total estimado. Aunque hay varios mtodos para estimar los tamaos de los programas antes de desarrollarlos, todos los mtodos de estimacin de tamao implican mucho juicio. Primero, examina los requisitos para los programas a desarrollar. Despus, clasifica los tamaos relativos de los nuevos programas entre los programas que has escrito ya. Finalmente, basndote en tu experiencia de dnde ubicas el nuevo programa dentro del histrico de rangos de tamaos, estima sus LOC. Un ejemplo de este procedimiento se muestra en la Tabla 6.3. Es una lista de programas desarrollados anteriormente por la Estudiante Y, clasificados por tamaos. La lista muestra el tamao del programa en LOC, el tiempo de desarrollo en minutos, las velocidades en minutos/LOC y una breve descripcin de la funcin del programa. Examinando dichos datos en tus programas, y considerando que sabes bastante sobre el programa que vas a codificar, puedes juzgar dnde se ubicar este programa en la lista de tamaos. Esto te ayudar a estimar el rango de tamao del nuevo programa. Basndote en los datos histricos de minutos por LOC, puedes estimar el tiempo para desarrollar el nuevo programa. Por ejemplo, supongamos que la Estudiante Y planific codificar un nuevo programa con un bucle while algo complicado. De la Tabla 6.3, estimara que el tamao es superior a las 14 LOC del programa 5 y probablemente menor a las 20 LOC del programa 1. A partir de lo anterior puede calcular la media de estos valores extremos, (14+20)/2=17 LOC.
Tabla 6.3 Rangos de tamaos de programas de la Estudiante Y
Estudiante Estudiante Y Profesor sr. Fecha Clase
30/09/96
IP
64
6.7
CMO HACER ESTIMACIONES DE TAMAOS MAYORES

Mientras la tcnica mostrada en la Tabla 6.3 funciona razonablemente bien para programas pequeos parecidos a los que hayas codificado anteriormente, no funciona tan bien para nuevos tipos de programas o programas grandes. La razn es que incluso los programas ms pequeos generalmente contienen una mezcla de funciones y procedimientos. Con programas ms grandes, tendrs progresivamente ms problemas al relacionar un nuevo programa con los programas desarrollados previamente. Una solucin a este problema es utilizar un formulario como el de la Tabla 6.4. Aqu, se pueden poner varios programas o funciones y procedimientos incluidos en programas. Con los datos de un cierto nmero de programas, podras dividir la lista en categoras, como la Estudiante Y hizo en la Tabla 6.5. Ejemplos de otras clasificaciones tiles son: Texto, Control, Lgica, Pantalla e Impresin. El objetivo es construir un registro histrico de elementos previamente escritos junto con los datos de cuantas lneas de cdigo contiene cada uno. Cuando consideres las funciones de un nuevo programa, puedes estimar el tamao de cada funcin y sumar todas estas estimaciones de funciones para obtener la estimacin total del programa. Con programas pequeos, haz una lista para cada programa como la mostrada en la Tabla 6.5. Con programas de mayor tamao, que contendrn probablemente mltiples funciones o procedimientos, enumerando cada funcin y procedimiento separadamente, puedes construir rpidamente una base histrica de datos de estimaciones. Si son muchos datos, es til guardarlos en un formulario como el de la Tabla 6.4 para cada categora de programa. Puedes tener un formulario para clculos, otro para procedimientos que manejen texto, otro para control, etc. Para cada formulario, clasifica las funciones del programa por su tamao e incluye el nombre o nmero del programa que la contiene. Un ejemplo de cmo hacer una estimacin de tamao de esta manera, se muestra en la Tabla 6.5. Aqu, la Estudiante Y ha agrupado los datos de un nmero de programas en varias categoras. Puesto que estos programas eran todos bastante pequeos, puso solamente los programas completos. Para estimar el nmero de LOC que tendr un nuevo programa, estim cuantas LOC de cada tipo de funcin seran necesarias para el nuevo programa. La Estudiante Y hizo esto, examinando en primer lugar los requisitos para el nuevo programa y estableciendo una estrategia general de cmo construirlo. Esperaba utilizar un bucle repetir-hasta y una sencilla sentencia case. Tambin esperaba hacer bastantes clculos sencillos. Haciendo estas estimaciones, sin embargo, no estaba completamente segura de qu tamao tendran cada una de las partes del programa, por ello estim un
65
Tabla 6.4 Formulario para estimar el tamao del programa.

Estudiante Profesor Fecha Clase
Estimado
~~
Commentarios:
tamao mnimo y uno mximo, a partir de ah obtuvo el tamao medio para cada funcin. Mientras utilizase los tamaos medios en sus estimaciones, el ejercicio de pensar en los tamaos mximo y mnimo le ayudaba a evitar hacer estimaciones que son o muy grandes o muy pequeas. Aunque este no es un mtodo infalible de estimacin de tamaos, es mucho mejor que estar adivinando. Conforme codifiques ms programas, podrs aadirlo a la lista de rutinas. El aumento del nmero de datos histricos te ayudar a hacer progresivamente mejores programas.
No hay mtodos que garanticen una buena estimacin del tamao. La estimacin del tamao es una habilidad. La clave para hacer buenas estimaciones de tamao, es tener una cantidad sustancial de datos histricos, hacer muchas estimaciones de tamao y comparar con regularidad tus resultados con las estimaciones.
CMO UTILIZAR MEDIDAS DE TAMAO EN EL CUADERNO DE TRABAJOS

Cuando utilizas las medidas de tamao, en vez contar las unidades deberas guardar los datos del tamao en el Cuaderno de Trabajos, tal y como
66
Tabla 6.5 Estimacin del tamao del programa de la Estudiante Y.
Estudiante Estudiante Y' ' Profesor 5r. Z Fecha Clase
7/10/96
IP
Comentarios: Este proqrama tiene una sentencia case sencilla, un bucle y un clculo. Asumo que, como mximo, el tamao se obtendr sumando estos tamaos tpicos, 11+14+20=45 LOC. Para el valor mnimo, asumo que estas funciones podran combinarse ms efectivamente que cuando estn como elementos separados. E s t o nos da 22 LOC como ei valor mnimo. 34 LOC es el punto medio entre 105 dos valores anteriores.
se muestra en las Tablas 6.6 y 6.7. Estos ejemplos utilizan los datos de tamao de las Tablas 6.1 y 6.2. Aqu, en vez de anotar que uno o dos captulos o programas fueron terminados, se ponen sus tamaos en la columna de unidades. Como se muestra en la Tabla 6.6, la Estudiante Y complet un programa de 20 LOC el 10/9, por ello puso un 20 en la columna U (unidades). El lU9, ley el Captulo 3, puesto que dedic 28 minutos a leer las 12 pginas, puso un 12 en la columna de unidades de la Tabla 6.6 y 28 en la columna de ATiempo. Puesto que tendrs datos de tamao en el Cuaderno de Trabajos, puede parecer redundante ponerlos tambin en el Cuaderno de Registro de Tiempos. Si tu experiencia es como la ma, con frecuencia completars el Cuaderno de Trabajos una o dos veces por semana. Entonces tendrs que buscar por datos de tamao. En el momento que hagas el trabajo, sin em-
67
Tabla 6.6 El cuaderno de registro de tiempos con datos pequeos.

~~~~d~~~~~ Estudiante Y
Profesor
sr.
Fecha Clase
999 '/6
IP
ComienFecha zo Fin
liempode interrupcin
A Tiempo Actividad Commentarios
c u
1 1
919
1
9 0 9:50 :0
12:40 1 11 1 :0 2:45 I3:53 1 0
] 50 11 I 0 12 0
50 Clase 30 1 1
Clase Eiercicio 1 I J Ejercicio 1 1 Leer t e x t o - Cap. ly2
I x 12c
bargo, no te llevar mucho tiempo escribir los datos de tamao en el Cuaderno de Registro de Tiempos.
68
Tabla 6.7 El cuaderno de trabajo con datos pequeos.

Nombre:
Estudiante Y
Fecha:
9/9/96
Hasta la Fecha
69
En la Tabla 6.7, la Estudiante Y utiliz estos datos de tamao para calcular velocidades del producto. Hizo esto utilizando las instrucciones del Cuaderno de Trabajos dadas en la Tabla 6.8. Por ejemplo, para el Trabajo 1 no hizo estimacin de tamao, dejando el espacio de Unidades Estimadas en blanco. El Tiempo Real permaneci en 158 minutos, pero las Unidades Reales son 20 LOC. Esto significa que las Unidades Hasta la Fecha son tambin 20 LOC y la velocidad Hasta la Fecha es 158/20=7,90 minutos por LOC. Puesto que este es el primer programa, los valores Mximo y Mnimo tambin son 7,90. Para el segundo programa, Trabajo 3, la Estudiante Y de nuevo no hizo estimaciones, dej en blanco las Unidades Estimadas. El Tiempo Real para el programa 2 fue de 69 minutos y las Unidades Reales para el programa 2 fueron de 11 LOC. Esto da ahora para el Tiempo Hasta la Fecha un valor de 227 minutos y 20+11=31 LOC para las Unidades Hasta la Fecha. La Estudiante Y obtuvo este valor buscando en las Unidades Hasta la Fecha la tarea de este tipo (Trabajo 1) ms recientemente realizada, cuyo valor era 20 LOC y se lo aadi a las 11 LOC de las Unidades Reales. Ahora, con 31 LOC Hasta la Fecha y 227 de Tiempo Hasta la Fecha, el valor de la velocidad Hasta la Fecha es de 227/31 = 7,32 minutos por LOC. La velocidad Mxima para el Trabajo 1 era 7,90, que es mayor que los 6,27 minutos por LOC para el Trabajo 3, por lo que la velocidad Mxima permanece en 7,90. La velocidad Mnima para el Trabajo 1 tambin era de 7,90, pero aqu, el valor de 6,27 minutos por LOC para el Trabajo 3 es menor que 7,90, por lo que el Mnimo es sustituido por 6,27, la velocidad del nuevo trabajo. Sigue este mismo procedimiento para cada uno de los programas, hasta que hayas puesto todos los datos del Nmero de Trabajo para los programas codificados hasta la fecha. En el futuro, podras estimar y escribir el valor de LOC para cada nuevo programa antes de escribirlo. Aunque esto lleva asociado un poco de trabajo, el procedimiento descrito en las Secciones 6.6 y 6.7 es relativamente fcil de seguir mientras tienes datos histricos. Para la lectura de textos, el procedimiento es idntico, excepto que para determinar las Unidades Estimadas, debes contar el nmero de pginas que vas a leer del libro. Utilizando estos datos, puedes ver cuanto tiempo has dedicado a codificar programas y a leer captulos del libro. Podras de igual forma incluir otras tareas, para las cuales t tengas medidas de tamao y tiempos.
RESUMEN
Este captulo introduce las medidas de tamao del producto y muestra cmo encajan en el proceso de planificacin del producto.
70
Tabla 6.8 Instructiones para el cuaderno de trabajos.

Propsito Esta tabla se utiliza para controlar los trabajos de cada proyecto. Registra la informacinclave de cada proyecto. Un proyecto es cualquier actividad que deseas controlar, como desarrollar un programa o escribir un artculo. Cuando comiences un proyecto, escribe el nmero de trabajo en este cuaderno. Escribe nmeros comenzando desde 1. Introduce los siguientes datos: Tu nombre. La fecha de comienzo de este Cuaderno de Trabaios Escribe el nmero de trabajo que has seleccionado. Escribe la fecha de inicio del trabajo. Escribe el tipo de tarea. Por ejemplo, para un trabajo tcnico Escribe Altculo, para desarrollar un programa, utiliza Cod., etc. Escribe el tiempo total en minutos que se estim para ese trabajo. Utiliza los valores de Velocidad Hasta la Fecha, Mximo y Mnimo como gua. Si estas velocidades no son razonables, utiliza tu experiencia. Escribe las unidades estimadas para el trabajo acabado. Para el desarrollo de un programa, por ejemplo, estima el nmero de LOC que esperas que contenga el programa completo. Escribe el tiempo total real para el trabajo realizado. Escribe el nmero real de unidades totales. Para un programa, por ejemplo, podras contar las LOC en el programa acabado. Escribe el Tiempo Real dividido por las Unidades Reales. Localiza el trabajo ms reciente de este tipo. Suma al valor de Tiempo Hasta la Fecha de este trabajo el Tiempo Real para el trabajo ms reciente. Escribe este total en la casilla de Tiempo Hasta la Fecha para el nuevo trabajo. Localiza el ltimo trabajo realizado de este tipo. Suma las Unidades Hasta la Fecha de este trabajo a las Unidades Reales para el trabajo ms reciente. Escribe este total en la casilla de Unidades Hasta la Fecha para el nuevo trabaja
~~
Mtodo Cabecera
Tiempo Estimado
Unidades Estimadas Tiempo Real Unidades Reales
Velocidad Real Tiempo Hasta la Fecha
Unidades Hasta la Fecha
Velocidad Hasta la Fecha Mx. Mn. Descripcin
Divide el tiempo Hasta la Fecha por las Unidades Hasta la Fecha para obtener los minutos por unidad para todos los trabajos terminados hasta la fecha. Escribe la velocidad mxima para todos los trabajos de cada tipo que hayan acabado. Escribe la velocidad mnima para todos los trabajos de cada tipo que hayan acabado. Escribe una descripcin del trabajo que se ha hecho. S suficientemente claro para que el contenido del trabajo pueda ser fcilmente identificado.
71
Las medidas de tamao se introducen para ayudar a estimar el tamao del producto. El captulo describe como determinar el tamao de un programa en lneas de cdigo (LOC). Otras medidas de tamao, como los mens, los ficheros, las pantallas y las pginas de informes, son frecuentemente necesarias para proyectos de software a escala industrial. El primer paso para planificar un producto es estimar su tamao. Para hacer una estimacin exacta del tamao, utiliza datos histricos. Es til dividir los datos histricos del tamao en categoras funcionales. Puedes estimar cuntas lneas de cada categora necesitars en el nuevo programa. Conforme acumules datos histricos, probablemente hars estimaciones ms exactas. El Cuaderno de Trabajos proporciona una forma adecuada para registrar grandes volmenes de datos histricos de tamao y velocidad.
EJERCICIO 6
Revisa las tareas finalizadas en los ejercicios hechos hasta la fecha y cuenta sus tamaos en LOC y pginas. Presenta estos datos en el formato de la Tabla 6.1 para los ejercicios de los captulos y en el de la Tabla 6.3 para los programas. Tambin, entrega actualizados, el Resumen Semanal de Actividades y el Cuaderno de Trabajos, con los datos de velocidades expresadas en minutos por LOC y minutos por pgina. Si no tienes copias de todos los programas acabados, incluye datos de al menos los 3 ltimos. Tambin, presenta una copia de algunas pginas del Cuaderno de Registro de Tiempos, del Cuaderno de Trabajo y del Resumen Semanal de Actividades que no hayas entregado anteriormente. A partir de ahora, presenta en donde proceda, todos los cuadernos y resmenes con tasas en minutos por LOC y minutos por pgina.
CAPITULO 7
Este captulo describe las estimaciones de tiempo y muestra cmo usarlas. Explica cmo hacer una estimacin de tiempo y sugiere algunas tcnicas para satisfacerlo. El ejercicio del captulo consistir en hacer una estimacin de tiempo.
7.1
ELEMENTOS DE LA GESTIN DEL TIEMPO

Hasta ahora, a lo largo de este curso, durante varias semanas hemos medido a qu dedicamos nuestro tiempo. Disponemos de una modesta cantidad de datos y una buena idea de cunto tiempo dedicamos a realizar diversas tareas. Este conocimiento no ha sido difcil de conseguir, y ahora comprobamos cmo te ayudan estos datos a hacer planes futuros. En este captulo, los utilizaremos para gestionar tu tiempo de la siguiente forma:
1. Decidir cmo quieres utilizar tu tiempo.
2 Hacer una estimacin de tiempo. .

3. Controlar la forma de utilizar el tiempo frente a lo estimado.
4. Decidir qu cambios hacer para llevar tus acciones en concordancia con lo estimado.
Estos temas se discuten en las secciones siguientes.
74
7.2
LA CLASIFICACIN DE LAS ACTIVIDADES

Revisa las categoras de tiempo para ver si cubren todas tus actividades principales. Si no es as, aade ms, revisndolas. Puedes encontrar, por ejemplo, que dedicas un tiempo significativo a analizar y utilizar los datos que has reunido en este curso. En este caso, te conviene aadir una categora de anlisis de datos al Resumen Semanal de Actividades. Aunque tengas ahora una buena idea del tiempo que dedicas semanalmente a las tareas, tendrs muchos datos sobre tareas que surgen de forma ocasional a lo largo de un mes, semestre o ao, como estudiar para los exmenes o trabajar en proyectos trimestrales. Naturalmente, no puedes reunir datos de estas tareas hasta que las hagas, pero intenta identificar estas categoras ahora, para que puedas hacer algunas previsiones de ellas en tus planes.
7.3
LA RECOGIDA DE DATOS SOBRE EL TIEMPO DEDICADO A CADA ACTIVIDAD

El Resumen Semanal de Actividades muestra los tiempos medio, mximo y mnimo que se dedican a cada actividad durante la semana. Es una buena idea examinar estas categoras ahora, para ver si son muy generales o muy detalladas. Una distribucin desigual puede hacer, que una categora tenga un 50% o ms de tiempo y las otras un 5 % o menos. Para gestionar el tiempo, necesitas centrarte en esas pocas categoras que consumen la mayor parte de tu tiempo. Necesitars saber con algn detalle qu haces. Si dedicas el 25% de tu tiempo a categoras etiquetadas como Otras, puedes dividirlas en un par de actividades mejor definidas. Sin datos ms precisos de estas Otras actividades, tendrs problemas en controlar cunto tiempo dedicas a ellas.
7.4
CMO EVALUAR TU DISTRIBUCIN DEL TIEMPO

Ahora que puedes saber cmo utilizas tu tiempo, pregntate a ti mismo si ests utilizando el tiempo de la forma que quieres. Decide qu actividades son ms importantes y considera si ests dedicndole el tiempo suficiente. A algunas tareas, le dedicas ms tiempo que a otras que son ms importantes? Ests dejando suficiente tiempo para leer el libro de texto? Haces el trabajo? Y, jcules son tus compromisos personales? Comienzas los ejercicios a tiempo para acabarlos, o los terminas en el 1timo momento? No hay guas generales sobre cmo utilizar tu tiempo.
75
Esta es una decisin muy personal que debes equilibrar entre el trabajo acadmico, las tareas, el descanso y la vida social. Algunos de estos componentes son cuestiones personales que implican complejas elecciones, particularmente si tienes un trabajo y responsabilidades familiares.
7.5
CMO HACER UNA ESTiMACiN DE TIEMPO

La estimacin de tiempo es tu plan de cmo utilizar el tiempo. Comenzando por los datos de cmo has utilizado anteriormente el tiempo, puedes asignar cantidades de tiempo que probablemente utilizars en cada categora en el futuro. La estimacin de tiempo preliminar para la Estudiante Y se muestra en la Tabla 7.1.
Tabla 7.1 Ejemplo de presupuesto semanal de tiempo.
23/9/96
IP
1
1 1 1
Actividad
Asistir a clase
Escribir programas Leer Texto Preparar exmenes Otros
1
I I I
Minutos estimados
150
1
I I I
Minutos reales
1
l l l
~
360
100
120
30
Total
00 4
La Tabla 7.2 es una copia del Resumen Semanal de Actividades de la Estudiante Y de la Tabla 4.4. Observando la lnea 19, puedes comparar la estimacin de tiempo en la Tabla 7.1 con la forma de utilizarlo realmente. Esto nos conduce a las siguientes conclusiones: El tiempo total de la Estudiante Y en este curso tiene una media de 742 minutos por semana hasta la fecha. Es decir 12,37 horas. Con la nueva estimacin, ella planifica dedicarle 840 minutos, o sea 14 horas por semana, lo que supone un tiempo adicional de 1,5 horas. Este es un cambio demasiado grande ya que puede tener problemas para encontrar este tiempo adicional cada semana. La Estudiante Y est estimando la misma cantidad de tiempo para asistir a clase, tal y como vena hacindolo hasta la fecha, es un plan razonable. Planifica dedicar 20 minutos ms de tiempo cada semana a codificar programas. Esto, probablemente, tambin es razonable.
76
Tabla 7.2 Resumen semanal de actividades de la Estudiante Y.

Nombre
1
2 3
EstudianteY
Fecha
23/9/96
4 5 6 7 J 8 V
9 S
77
77
4 0 33 14 6
33
50
7 4
10 Totales
10 5
339
24 2
73 1
11 Tiempos y medias del perodo
Nmero de semanas (nmero anterior +l):2
12 Resumen de las semanas anteriores 13 14 15 16 17 18 19 20 21
Planifica dedicarle, aproximadamente, el mismo tiempo que el empleado hasta ahora para leer libros. Esto parece razonable. Los grandes incrementos estn en las categoras de preparar exmenes y Otros. Estas dos suman un total de 150 minutos por semana, o 2,5 horas. Este gran cambio, probablemente, no es realista. Aunque, puede tener sentido para la Estudiante Y, aumentar su tiempo total a un valor prximo al mximo de los 771 minutos dedicados hasta ahora, esperar hacer mucho ms podra no ser realista. La clave para gestionar el tiempo es reequilibrar gradualmente la forma de utilizarlo. As, no puedes esperar dedicar ms tiempo a algunas tareas en el futuro, a menos que identifiques otras reas que puedas acortar, sino esto es ilusorio. Un paso importante es asegurarte que utilizas tu tiempo con ms
77
efectividad. A menudo, las personas gastan mucho tiempo decidiendo qu van a hacer prximamente. Estableciendo planes personales y estimando el tiempo, podrn srrber qu hacer a continuacin. Asombrosamente, esto mejorar de inmediato su eficiencia en el trabajo. Puedes necesitar ms tiempo para hacer todas las cosas que deseas hacer. De nuevo, sin embargo, necesitas ser realista. Normalmente, puedes encontrar algn tiempo extra en una situacin de crisis, pero no quieras vivir perpetuamente en crisis. As, dedica cantidades razonables de tiempo al cuidado de tu salud, a la familia, a los amigos, a las aficiones y a las comidas. Aunque podrs ser capaz de hacer algunos ajustes en estas reas, deberas hacerlo de forma gradual. Te sugiero que establezcas un ritmo sostenido de trabajo que puedas llevar de forma continua durante el curso acadmico. Puedes ser capaz de recortar profundamente una o ms reas en una crisis, pero no puedes hacerlo durante mucho tiempo. Si debes dedicar ms tiempo a alguna actividad, necesitas tomar este tiempo de otra parte. Entonces haz tu estimacin de tiempo de acuerdo con esto.
7.6
CMO ENCONTRAR MS TIEMPO

Despus de haber revisado la estimacin de tiempo, puedes necesitar aumentar la cantidad total de tiempo. LCom puedes hacer esto? Tienes varias opciones. Primero, si tu agenda no est muy ocupada, sers capaz de encontrar un poco de tiempo extra, pero desdichadamente, pocas personas estn bendecidas con el tiempo libre.
Es ms probable que ests super comprometido. En este caso, haz un amplio estudio de todos tus compromisos. Despus revisa el tiempo que utilizas tanto en las clases, como en las principales reas de trabajo, as como en las actividades de ocio.
El problema es que el da solamente tiene 24 horas y no hay nada que puedas hacer para aumentarlas. Si necesitas dedicar ms tiempo a alguna actividad, dcbcs tomar ese tiempo de otras actividades. As, hasta que no sepas cuanto tiempo dedicas a cada categora de actividades, ser difcil hacer ajustes realistas.
7.7
CMO ESTABLECER REGLAS BSICAS

Ahora que has decidido cmo quieres utilizar el tiempo, necesitas realmente utilizarlo de esa forma. Esta regla tan sencilla lleva ms esfuerzo del que puedas prever. La razn es que las estimaciones de tiempo son,
78
generalmente, declaraciones de lo que quieres hacer. La gestin del tiempo real, requiere tomar decisiones minuto a minuto. As, para hacer realmente lo que quieres hacer, necesitas ser muy concreto. Probablemente habrs observado que es fcil gestionar la cantidad de tiempo que dedicas a asistir a clase. La razn es que las clases ocurren a intervalos regulares. Cuando las personas tienen unas rutinas especficas que seguir, generalmente las pueden hacer. Muchas de las cosas que hacemos, son en respuesta a algunas reglas que alguien ha establecido. Para una efectiva gestin del tiempo, tambin necesitas reglas, pero ahora, debes fijarlas t mismo. En efecto, la gestin del tiempo estimado es: el conjunto de reglas que tienes establecidas para gestionar tu propio tiempo. Para proporcionar una gua til en tu comportamiento diario, necesitars una estimacin diaria del tiempo. Tus estimaciones para los distintos das y semanas, probablemente diferirn. As, ser necesario un formato como el de la Tabla 7.3. Ahora puedes ver, por qu la estimacin de la Tabla 7.1 no era muy til. Por ejemplo, tendra poco sentido dedicar un tiempo semanal a preparar exmenes. No querrs esperar hasta el ltimo da antes del examen, ni querrs prepararlo por adelantado, para olvidar los temas el da del examen. Tambin, la categora de Otros en la Tabla 7.1 era una asignacin para actividades no planificadas. Aunque, es una buena idea hacer alguna asignacin para cuestiones imprevistas, obviamente, no hay forma de hacer planes detallados por sorpresa. Una forma de gestionar las contingencias imprevistas, es asignar un poco ms de tiempo de la media histrica
Tabla 7 3 Estimacin semanal de actividades. .
Nombre Estimacidn !Semana #1 Fecha
79
Tabla 7 3 Estimacin semanal de actividades (Continuacin). .

Estimacin Semana #2
Estimacin Semana #3
a cada actividad. Poner excedentes, te permitir gestionar errores ocasionales de planificacin y eventos imprevistos. Una estimacin de tiempo ms realista para la Estudiante Y se puede ver en la Tabla 7.4.
7.8
CMO PRIORIZAR TU TIEMPO

Un paso esencial en la gestin del tiempo es establecer prioridades. Algunas veces estn firmemente establecidas, cmo asistir a clase o cundo trabajas. Podras llamar a esto, tiempos fijos. Cualquier otra cosa, es el tiempo va-
80
riable: actividades que haces cuando puedes encontrar tiempo. Hay, sin embargo, dos tipos de actividades variables: las exigidas y las discrecionales. Las actividades exigidas incluyen tareas como, hacer en casa los trabajos asignados en clase, leer un libro o preparar los exmenes. Aunque son exigidas, son variables, porque las haces si encuentras tiempo, y dedicas a las mismas, cantidades variables de tiempo cada semana. Las actividades discrecionales son todas las otras cosas que haces: comer, dormir, vida social, hacer deporte, ver deporte en la televisin y otros entretenimientos. Cuando haces una estimacin global de tiempo, es til determinar de forma exacta cunto tiempo has dedicado a cada categora. Programar los
Tabla 7.4 Ejemplo de estimacin semanal de actividades.
hombre Estudiante Y Estimacin Semana #1
I I
Fecha
Estimacin para una semana normal
23/9/96
t
Tarea
Clase
Codificar
Prog.
Fecha
Mi
50
I J I I s I
Totale
150
1 1
10 2
120
360
200
7O 1
V S Totales
50
120
170 150
820
150 150
240
430
81
Tabla 7.4 Ejemplo de estimacin semanal de actividades (Continuacin).

Estimacin Semana #3
Semana del examen
tiempos fijos no es problema, el problema ms comn es, asignar el tiempo variable. Por ejemplo, si no tienes suficiente tiempo para hacer los trabajos asignados cuando debas, el nico sitio para obtener tiempo adicional es de tus actividades discrecionales. Esto sugiere que eches un vistazo a los tiempos fijos, exigidos y discrecionales para ver donde puedes hacer los ajustes. Una herramienta para examinar la distribucin personal del tiempo es el resumen global de tiempos que se muestra en la Tabla 7.5. Para completar dicha tabla, tendrs que registrar, aproximadamente, cuanto tiempo dedicas normalmente a cada actividad. Aunque, podras utilizar el Cuaderno de Registro de Tiempos, no se necesitar, en una primera aproximacin este grado de detalle. Para empezar, es adecuado anotar al final de cada da, a qu has dedicado tu tiempo en cada categora. As te aseguras que los tiempos de cada da suman 24 horas y el tiempo total de la semana suma 168 horas o sea 10.080 minutos, tus totales probablemente estarn bien. Si no eres capaz de hacer un resumen adecuado de esta forma, entonces puedes utilizar el Cuaderno de Registro de Tiempos. Con un resumen total como el que se muestra en la Tabla 7.5, tienes los datos bsicos para decidir de donde coger el tiempo adicional que necesitas. De nuevo, sin embargo, necesitas ser realista. Reducir las horas de sueo o de comer, por ejemplo, puede daar tu salud y disminuir la eficiencia del trabajo. Saltarse comidas y trasnochar puede ser una forma de solucionar problemas a corto plazo, pero generalmente, no es una buena idea planificar importantes reducciones en estas reas. Siendo realista, surge otro aspecto: tu buena voluntad para trabajar realmente en el plan establecido. Una planificacin sin tiempo para la vida social, la relajacin o los ejercicios fsicos, puede llegar a resultar un fastidio. Aunque puedas reducir el tiempo dedicado al relax y a la diver-
82
Tabla 7.5 Resumen global de los tiempos semanales.

Nombre
Estudiante Y
~~~h~
23/9/96
Actividad
Fija
Infonk
Fsica
Matem.
Ingls Comer/ Descanso
Otros
Total
sin, es necesaria una cierta cantidad de ocio. Es fcil llegar a estar cansado y depresivo cuando te concentras exclusivamente en el trabajo. As como rendirse a unas patatas fritas, al chocolate o a un helado, puede causarte que frustres una dieta, esto te podra conducir a rebelarte contra la idea global de la gestin del tiempo. Aunque es importante estimar y revisar el tiempo, asegrate de que tu estimacin es algo que ests dispuesto a llevarlo a cabo con buena voluntad. Conforme vayas controlando el tiempo, compara el tiempo real dedicado frente al tiempo estimado. Si puedes gestionar el tiempo consistentemente, de acuerdo a tu estimacin, no necesitas hacer muchos cambios. Sin embargo, lo ms probable es que tu plan inicial necesite ajustes. No te sientas mal si tienes que cambiar las estimaciones bsicas. Puesto que las actividades cambiarn de semana en semana, necesitars hacer revisiones ocasionalmente. Recuerda, sin embargo, anotar las nuevas estimaciones.
7.9
LA GESTIN DEL TIEMPO ESTIMADO

Para establecer las reglas bsicas de la gestin del tiempo, utiliza la aproximacin que se muestra en la Tabla 7.6, anota para cada da los tiempos
83
de cada categora. Si quieres utilizar dos perodos de tiempo para una categora en un da, utiliza dos columnas o haz ms grande los espacios de este formulario. El formato no es lo importante, cntrate, ms bien, en establecer un conjunto de reglas explcito y claro.
Tabla 7.6 Ejemplo de estimacin y gestin semanal del tiempo.
Nombre
Estudiante Y Estimacin para una semana normal
Fecha
23/9/96
Estimacin Semana #1
Tu capacidad para trabajar de acuerdo al tiempo estimado depender en gran parte de la disciplina personal, pero tambin depender del nmero y prioridad de las cosas que ests intentando hacer. Los asuntos inesperados, son cosas naturales y normales de la vida, especialmente en la ingeniera del software. Los problemas alterarn tus planes peridicamente y tendrs que hacer ajustes. Por ejemplo, para cumplir una fecha importante, puedes tener que trabajar hasta muy avanzada la noche o aplazar las actividades planificadas de tipo familiar, ocio o social. Puedes encontrar, que la primera vez que utilizas la estimacin de tiempo, no es muy til. Esto es normal, no renuncies al proceso de estimar el tiempo porque no funcione la primera vez. En su lugar, piensa qu es lo que ha sucedido. Fue algn suceso inusual, que probablemente no volver a suceder ? o fue el tiempo inesperadamente gastado en alguna actividad normal? Si fue una emergencia verdadera, no tendrs necesidad de hacer cambios radicales en la estimacin. Intenta utilizarlo otra sema-
84
na, y vuelve a examinar de nuevo los resultados. Si, por el contrario, la estimacin fue alterada por algn suceso normal, considera ajustar la estimacin para adelantarte a dichos sucesos en el futuro.
7.1O
SUGERENCIAS PARA LA GESTIN DEL TIEMPO VARIABLE

Cuando establezcas las reglas bsicas para la gestin del tiempo variable, considera las siguientes cuestiones:
Qu actividades son de mxima prioridad? Intenta hacer las tareas ms importantes primero. Es natural aplazar las tareas difciles o poco interesantes, pero nunca se volvern fciles. Si t mismo ests retrasando trabajo importante, detente y piensa un poco lo que ests haciendo. Vers que cuando aplazas tareas importantes, inconscientemente te preocupas por ellas. A menudo, en efecto, decidir hacerlas de forma correcta, ser ms eficiente y te proporcionar un sentido til de logro. Recuerda tambin, que una vez que has iniciado las tareas temidas, raramente volvern a ser tan difciles como creas.
, Hay algunas tareas que se deberan realizar en momentos espej c@cos? Por ejemplo, estudiar para un examen, prepararte para una sesin de laboratorio o reunirte con tu tutor de la Facultad. Asigna tiempos especficos a estas demandas en tu presupuesto de tiempo. ,jHay actividades que quieres hacer tan pronto como tengas tiempo? En tu cuaderno de ingeniera, guarda una lista de cosas que necesitas hacer lo antes posible, como codificar los programas asignados o leer el siguiente captulo del libro. Entonces, puedes comprobarlas cuando las termines.
Para gestionar diariamente tu tiempo, necesitas llevar las estimaciones de la gestin del tiempo contigo en todo momento. Una buena idea para hacer esto, es llevarlos en tu cuaderno de ingeniera. Insrtalos con un clip en la parte delantera o trasera del cuaderno de ingeniera, o grpalos. Cuando actualices el presupuesto, toma el ms reciente y guarda las copias antiguas. Comprueba las versiones anteriores antes de hacer un cambio, pues te ayudarn a evitar hacer correcciones. Para compensar haber sobreestimado una tarea estimada, por ejemplo, probablemente la subestimars la prxima vez. Si examinas las estimaciones anteriores, te mostrarn la tendencia y te ayudarn a escoger un valor medio ms documentado. Una regla para sobrevivir en la ingeniera del software es: no tires los planes, datos o programas viejos. Asombrosamente, los necesitars despus.
85
7.11
TU OBJETIVO EN LA GESTIN DEL TIEMPO

Despus de haber gestionado tu tiempo de esta forma durante unas pocas semanas, considera simplificar la recoleccin de datos, mediante la consolidacin de varias categoras de tiempo en unas pocas. Tu objetivo en este punto, es conseguir una visin global de tu distribucin de tiempo, antes que conocer los detalles. Por ejemplo, despus de revisar mis tiempos de varios aos, yo he reducido mi tiempo de trabajo solamente a dos categoras: proyectos de empresa y proyectos personales. Puesto que yo planifico cada proyecto separadamente, un anlisis de un periodo detallado, no aade ms informacin til. Para m, la cuestin ms importante, es saber cunto tiempo puedo dedicar a cada una de mis dos categoras de proyecto cada semana o mes. Recuerda que reunir los datos de tiempos te ayudar a ti mismo a gestionar el tiempo. Si los datos que renes no son tiles, reconsidera la forma de agruparlos. Haz esto, solo despus de tener prctica en estimar el tiempo. An as, si por alguna razn la distribucin de tu tiempo cambia significativamente, rene ms datos hasta que entiendas cmo utilizas tu tiempo realmente.
RESUMEN
Para gestionar bien tu tiempo analiza tus propios datos histricos de tiempos. Establece una estimacin para utilizar el tiempo y registra tu tiempo real frente al estimado. Para hacer una estimacin de tiempo decide cmo quieres utilizar el tiempo. Haz una programacin que refleje tu eleccin y que muestre los tiempos cada da; puedes necesitar diferentes estimaciones para distintas semanas. Las reglas bsicas para estimar el tiempo pueden ser tiles: identifica tus compromisos fijos y variables. Divide tu tiempo variable en tareas que son exigidas y aquellas que son discrecionales. Analiza como divides ahora tu tiempo en estas categoras. Recuerda que tu tiempo total es fijo: si necesitas ms tiempo para algunas actividades, debes dedicar menos tiempo a otras. Finalmente, revisa el rendimiento frente al tiempo estimado: contina reuniendo datos de tiempos. Revisa el tiempo estimado frente a tu experiencia real. Revisa la estimacin basndote en tus necesidades y experiencias. Haz los cambios de forma gradual. Cuando cambies tu estimacin de tiempo, guarda las versiones anteriores.
86
EJERCICIO 7
Utilizando los datos de la forma que tienes de gastar el tiempo, establece una estimacin de tu tiempo para semanas normales y para alguna especial que prevs durante el resto del semestre. Para los casos donde tu estimacin difiera sustancialmente de los tiempos medios, explica brevemente porque haces las distintas elecciones. Utiliza los formatos de estimacin mostrados en las Tablas 7.4 y 7.6. Entrega varias copias de estas estimaciones con el trabajo asignado para casa. Observa que la estimacin de tiempo es un ejercicio opcional que no necesitas completar a no ser que te lo pida tu profesor. Entrega las copias de las pginas del Cuaderno de Registro de Tiempos y del Resumen Semanal de Actividades que no hayas entregado todava.
CAPITULO 8
La gestin de los compromisos
Este captulo se centra en los compromisos, discute qu son, por qu son importantes y cmo se gestionan. En el ejercicio revisars y anotars tus compromisos.
8.1
DEFINICIN DE COMPROMISO
Estar comprometido, es un estado mental. Por cualquier razn, te has comprometido a hacer algo, y sientes que deberas hacerlo. Un compromiso, sin embargo, es algo ms que hacer lo que desees hacer, hay algo que alguien espera que hagas. En efecto, esta es la cuestin clave en los compromisos: quin es la persona con la que te has comprometido? En sentido legal o contractual, ests comprometido con alguien: tu profesor, tu director, tu jefe. Ms importantes, sin embargo, son los compromisos ntimos que haces contigo mismo. El principal problema con muchas programaciones y planes de software, es que la direccin las ve como compromisos contractuales, pero los ingenieros del software no las ven como compromisos personales. La diferencia, como veremos, est en gran parte, en cmo se hacen los com-
88
LA GESTIN DE LOS COMPROMISOS
promisos. En este captulo, aprenderemos cmo hacer compromisos contractuales que sean tambin compromisos personales. Con un compromiso contractual, dos o ms personas deben ponerse de acuerdo antes sobre la accin a realizar, esto es un compromiso. Por ejemplo, el Sr. A y la Sra. B llegan al acuerdo de que el Sr. A proporcionar algn producto o realizar alguna tarea para la Sra. B. Un ejemplo, es tu compromiso con tu profesor de hacer el ejercicio asignado para este curso. Otro ejemplo, podra ser tu contrato de escribir un programa para un cliente. Cuando el Sr. A se compromete, se pone de acuerdo con la Sra. B, para realizar una tarea especfica en un tiempo determinado y por una recompensa o compensacin. Esto indica que hay dos elementos adicionales en los compromisos. Adems de comprometerte en la tarea, las partes tambin se ponen de acuerdo sobre el tiempo en que va a ser hecha y en el pago u otra retribucin que recibir el Sr. A. Un ejemplo podra ser la obligacin del cliente de pagarte por el desarrollo e instalacin de algn software. Una caracterstica de los compromisos personales es que son voluntarios. Supongamos, por ejemplo, que tu cliente necesita el programa antes
y te dice que lo acabes dos semanas antes de lo inicialmente establecido. l, nunca pregunt si podas realizar la proeza, y t, por tu parte, no te comprometiste. Vosotros comentis la nueva fecha. Aunque pudieses comprometerte con la nueva fecha, probablemente no querrs sentirte personalmente comprometido a hacerlo.
Para estar verdaderamente comprometido, debes de considerar atentamente las alternativas y decidir que esto es algo que t puedes hacer y hars. Cuando te ordenan que debes hacer algo, no se tratar de un compromiso personal. En efecto, cuando a las personas se les ordena hacer cosas, a menudo, se sienten amenazadas y enfadadas. Se resisten a la persona que dicta las ordenes y puede que quieran responder contra ellos. Una forma de respuesta, naturalmente, sera no hacer la accin demandada. Dicha reaccin en los negocios puede parecer infantil, pero muchas personas responden inconscientemente de esta forma. El verdadero acuerdo es la caracterstica ms importante de un compromiso personal. Las partes deben ponerse de acuerdo sobre qu hacer, cuando se terminar y qu es lo que se dar a cambio. Un verdadero compromiso, es tanto personal como contractual y requiere un acuerdo voluntario y explicito entre dos o ms partes sobre: Qu se har. Los criterios para determinar que est hecho. Quin lo har.
89
Cundo se har. La compensacin u otra retribucin que se dar a cambio.
Y quin proporcionar la compensacin o retribucin.
8.2
RESPONSABILIDAD PARA HACER COMPROMISOS

Adems de las caractersticas ya descritas, los compromisos deberan hacerse responsablemente y gestionarse de manera adecuada. Puedes asegurarte de que tus compromisos son responsables y estn bien gestionados de la siguiente forma:
Analiza el trabajo antes de aceptar el compromiso. Ambas partes deben establecer el compromiso de buena fe. T ests personalmente comprometido y realmente pretendes hacer el trabajo y la otra parte est dispuesta a proporcionarte la adecuada remuneracin a cambio. La cuestin, sin embargo, es el grado en que podis asegurar que podis cumplir el compromiso. Por ejemplo, has examinado el trabajo con suficiente detalle para saber que lo puedes hacer? De forma similar, la otra parte tiene la capacidad de remunerarte? Con frecuencia, los compromisos software estn basados en algo ms que esperanzas. Cuando ambas partes pretenden verdaderamente llevarlo a cabo, con buenas intenciones no se proporciona una base razonable para un buen acuerdo. Apoyar el compromiso con un plan. Para un trabajo de cualquier tamao, la forma de hacerse responsable de un compromiso, es hacer en primer lugar un plan para el trabajo. La planificacin implica algn esfuerzo, pero no es necesario que sea muy grande. En efecto, si has tenido experiencia en hacer planes formales, puedes normalmente completarlos rpidamente. Documentar el compromiso. Aunque esto puede parecer obvio, no lo es. Hay un malentendido comn de que las personas honestas solo necesitarn unas pocas palabras y un apretn de manos. Pero las palabras, a menudo, son mal interpretadas. Despus de que dos personas se comprometen oralmente, tienen, a menudo, problemas de comprometerse por escrito. Esto significa que sus compromisos originales eran superficiales e irreales. El segundo problema tiene que ver sobre qu harn las dos partes si surgen problemas. Esta, en efecto, es la principal razn de muchos contratos. No necesitas un contrato cuando las cosas funcionan de acuerdo con lo planificado, lo necesitas cuando hay problemas.
Si eres incapaz de cumplir el compromiso, dselo inmediatamente a la otra parte e intenta minimizar el impacto sobre esa persona. Cuando hayas aprendido a gestionar tus compromisos, casi siempre los cumplirs. Desdichadamente, aun con los mejores planes, el trabajo ocasional-
90
mente ser ms complejo de lo que esperabas o puede surgir algo imprevisible.
8.3
EJEMPLO DE UN COMPROMISO
La Estudiante Y se ha comprometido a hacer 10 horas de trabajo a tiempo parcial cada semana en la Oficina de Administracin de la Universidad. Los pasos necesarios para establecer adecuadamente el compromiso para este caso, se muestran a continuacin.
1. La Estudiante Y se rene con el jefe de la Oficina de Administracin, que le explica el trabajo que deber hacer. Esta es la fase de requisitos del proceso de compromiso, en la cual la Estudiante Y se entera de qu clase de trabajo se espera que haga. Para un trabajo de oficina, el producto de esta fase debera ser una lista de tareas a realizar, posiblemente una descripcin del trabajo.
2. La Estudiante Y analiza las tareas y concluye que est dispuesta a hacer ese trabajo y es capaz de llevarlo a cabo.
Respondida la primera cuestin: puedo hacer el trabajo?, la siguiente cuestin es: puedo hacerlo en el tiempo y con los recursos requeridos? Para responder a esta cuestin, la Estudiante Y hace lo siguiente:
3. Examina sus compromisos personales de tiempo y concluye que puede encontrar 10 horas (o sea 600 minutos) durante cada semana para hacer el trabajo. Como puedes observar, comparando la Tabla 8.1 con la Tabla 7.5, obtiene este tiempo, reduciendo su tiempo total de descanso en 600 minutos.
4. Revisa sus propios compromisos, mostrados en la Tabla 8.2, y concluye que la franja horaria que necesita para el trabajo, de 4:OO a 6:OO de la tarde de lunes a viernes, est disponible.
5. Ahora que est segura de que puede hacer el trabajo, discute, la
cantidad de dinero a percibir y la fecha de incorporacin al trabajo, con el jefe de la Oficina de Administracin.
6. Con todas estas cuestiones establecidas, la Estudiante Y y el jefe se comprometen en todas las cuestiones discutidas y el supervisor se compromete a proporcionarle una carta que resuma los puntos clave.
Este es un compromiso responsable. La Estudiante Y se tom su tiempo para entender el trabajo y su capacidad para hacerlo. Se asegur que poda hacer el trabajo y que tendra el tiempo disponible. Tambin se lleg a un acuerdo con el jefe sobre la cantidad de dinero a percibir y otras condiciones del trabajo.
91
Tabla 8.1 Resumen semanal de tiempos semanales de la Estudiante Y.

Nombre
Estudiante Y
Fecha Clase
3019196
IP
UN EJEMPLO EN LA INDUSTRIA
A un ingeniero de una de las principales compaas de automviles, le asignaron un trabajo de software urgente. Antes, la direccin le haba dado simplemente la fecha junto con el trabajo asignado. Pero puesto que el ingeniero y su equipo haban terminado el curso de PSP, pidi tiempo para echarle un vistazo al problema y volver a la maana siguiente con un plan. El ingeniero estim el tamao del trabajo y utiliz sus datos del PSP para determinar cunto tiempo le llevara el trabajo. Volvi a hablar con su director y le explic el plan y por qu crea que era realista. Su director estuvo de acuerdo y el ingeniero acab el trabajo en el perodo que se haba comprometido. Antes, las programaciones impuestas por el departamento de gestin raramente eran satisfechas. Aunque muchos de ellos no eran realistas, el problema principal fue la falta de compromiso personal por parte de los ingenieros. Jugando un papel activo en hacer un compromiso mutuo con la direccin, este ingeniero fue capaz de establecer una programacin razonable. En el proceso, el tambin se comprometi personalmente.
92
Tabla 8.2 Compromisos semanales fijos de la Estudiante Y.

Nombre
Estudiante Y
Fecha
Compromisos fijos de tiempo
3019196
Presupuesto Semana #1
t
Tarea Fecha
D
Inform.
I
Fsica
I
Matem.
I
Ingls
I
Trabajo
I I I
I
Total
L
M
M
J
V S
Totales
9:oo950
1o:oo1050
400600
220
150
150
100
100
600
10 10
8.5
LA GESTIN DE COMPROMISOS NO CONSEGUIDOS

Despus de llegar a ser competente haciendo planes, probablemente no fallars en las fechas de finalizacin muy a menudo. No puedes, sin embargo, garantizar que nunca vas a fallar en una fecha. Puesto que muchas de las cosas que los ingenieros del software hacen son originales y creativas, hay un riesgo considerable. Si tuvieses en cuenta todos los riesgos posibles, tus estimaciones seran altas de forma poco razonable, de aqu que una programacin ocasional o fallos de coste sean inevitables. Cuando tengas que faltar a un compromiso, notifcalo inmediatamente a la otra parte y poder trabajar juntos para resolver los problemas resultantes. Podras, por ejemplo, acordar ampliar el plazo de tiempo o reducir la extensin del trabajo. Con el software, una estrategia comn es entregar una versin mnima que funcione en la fecha prxima a la programacin original y entonces, seguir con una o ms mejoras del producto. Definiendo adecuadamente el orden y las fechas de las siguientes funcionalidades, puedes minimizar el trastorno al cliente.
93
La forma de manejar los errores ocasionales de fecha de entrega o compromisos no cumplidos es importante. Los problemas de los compromisos son siempre desagradables. Probablemente te sentirs mal cuando hayas planificado mal, y la persona con la que te has comprometido se podra sentir engaada o timada. Podra haber consecuencias financieras y la bsqueda de algn culpable. Las cosas desagradables empeoran con el tiempo. Retrasar la notificacin con la esperanza de que las cosas mejorarn, normalmente hace que empeoren. Es mejor enfrentarse a lo desagradable tan pronto como entiendas el problema.
Una advertencia importante: no abandones sin intentar seriamente cumplir el compromiso. Lo has discutido con un experto independiente para ver si hay una forma mejor? Podras aadir recursos para acelerar el trabajo? Hay formas ms inteligentes de hacer el diseo? Examina atentamente las alternativas y entonces, si no hay otra forma, enfrntate al problema sin dilacin. Los compromisos incumplidos generalmente conducen a molestias e insatisfacciones. Esto es porque, a menudo, la gente retrasa enfrentarse a dichos problemas hasta el ltimo momento posible; como los avestruces, estn aplazando lo desagradable con la esperanza de que los problemas desaparezcan de algn modo. Desafortunadamente, meter la cabeza bajo el ala, siempre aumenta la desorganizacin, reduce las opciones de los clientes y maximiza los resultados desagradables.
8.6
LA IMPORTANCIA DE GESTIONAR COMPROMISOS

La principal razn para gestionar tus compromisos, es para no dejarlos pasar u olvidarlos. El trabajo de los ingenieros tiene muchos compromisos. Participan en revisiones, escriben informes, asisten a reuniones, hacen correcciones de programas y actualizan mdulos de programas. Pueden tener que: documentar diseos, responder a llamadas de los clientes, reunirse con los vendedores o participar en comisiones. No es inusual, en el trabajo de los ingenieros, hacer juegos malabares con una docena de compromisos simultneamente. Es importante aprender a gestionar los compromisos para no romperlos u olvidarlos. Otra razn para gestionar tus compromisos, es la de ayudarte cuando el trabajo que necesitas hacer, exceda el tiempo disponible. Si planificas tu trabajo, no deberas excederte del tiempo con frecuencia, pero puede ser un problema ocasional aun cuando hagas los compromisos de forma responsable. En esta situacin, identifica rpidamente aquellos compromisos que corren el riesgo de romperse y notifcalo inmediatamente a las otras partes.
94
8.7
LAS CONSECUENCIAS DE NO GESTIONAR LOS COMPROMISOS

Hasta que no aprendas a gestionar tus compromisos, a menudo te enfrentars a algunas de las siguientes situaciones desagradables: El trabajo requerido excede del tiempo disponible. Frecuentemente tendrs ms que hacer de lo que puedas realizar. Si no guardas una lista de tus compromisos, puedes obtener nuevos compromisos cuando no deberas hacerlo. Puedes, por ejemplo, comprometerte a una cuestin social cuando debas de hacer unos ejercicios en casa para el prximo da. Por la tarde, recuerdas lo de los ejercicios y entonces, tienes que quedarte toda la noche para hacerlo. Peor an, puede que ni te acuerdes. Fallar al enfrentarte a los compromisos. A menudo, los trabajos de desarrollo de software son ms complejos de lo que se espera. Cuando no tienes una forma ordenada de establecer compromisos, es probable que asumas que el trabajo es ms sencillo de lo que realmente es. Estars desbordado desde el momento que comiences a realizar el trabajo. Prioridades mal colocadas. Cuando se est desbordado las personas, a menudo, hacen las prioridades basndose en lo que debe hacerse primero, en vez de lo que es ms importante. Cuando se tiene que hacer ms de lo que realmente puedes hacer, es natural trabajar sobre la siguiente cosa que debas hacer. Desafortunadamente, resolver la amenaza inmediata, es frecuentemente una estrategia errnea. Cuando ests realmente desbordado, necesitas reestructurar todos tus compromisos, para ajustar lo que puedas hacer. Aplazar o dejar algunas de las tareas inmediatas, puede ser adecuado para hacer los trabajos ms importantes que vienen despus. Pobre calidad del trabajo. Trabajando presionados, los ingenieros del software, a menudo, sienten la presin para hacer recortes. Es cuando los descuidos y errores tontos son ms probables, y cuando la atencin a la calidad es ms necesaria. Cuando el tiempo se reduce, los ingenieros deberan tener un cuidado especial para evitar errores. Desafortunadamente, la experiencia demuestra que son en estas circunstancias cuando los ingenieros y directores, probablemente, dedican menos tiempo a hacer revisiones, inspecciones o pruebas completas. Prdida de confiunza. Si frecuentemente faltas a tus compromisos, la gente lo notar. Sabrn que cuando te comprometes a algo, a menudo, no cumples tu palabra. Tal reputacin es difcil de reparar y afectar a tus notas, tu prestigio en el trabajo, tu sueldo e incluso a tu seguridad en el puesto de trabajo. Prdida de respeto a tus opiniones. Cuando las personas no confan en lo que t dices, no es probable que te pidan opinin y es ms probable
95
que te insistan en que t trabajes con programaciones que no sean razonables. El activo ms importante que puede tener un ingeniero del software es su reputacin para cumplir los compromisos. Para que las personas confen en tu palabra, necesitas exponer tu plan de trabajo y entonces hacer lo que dices. Un propsito importante de este libro es proporcionarte herramientas que te ayuden a hacer compromisos reales que puedas cumplir de forma consecuente.
8.8
LA FORMA DE GESTIONAR COMPROMISOS

Para gestionar adecuadamente los compromisos, comienza haciendo una lista de los compromisos que tienes. Observa la fecha de cada compromiso y la cantidad de tiempo que necesitars.. La Tabla 8.3 muestra la lista de compromisos de la Estudiante Y.
Tabla 8 3 Lista de compromisos de la Estudiante Y. .
~~~b~~ Profesor
EstudianteY 5r.
Fecha Clase
3019196
IP
Compromiso Fecha comprometida
1 1
LMV LMV Martes
Asistir a clase
IProfesor
Entregar trabajo inform. Profesor
1 1
1.5
6,O
4,O
1 1
19 1
1 Aprobar 1 Aprobar
Aprobar Paga
Leer libro L=>V Trabajo tiempo parcial, 400-600 PM
Profesor Admisin
10,o
Ejercicio trimestral
Profesor
24
11 19
Aprobar
Para gestionar los compromisos en ingeniera del software, es importante recordar varios hechos de la vida del negocio del software. Si te ests retrasando, tu planificacin continuar retrasndose a no ser que hagas algo diferente. Intentarlo ms duramente no ayudar. Recuerda, que ya estuviste intentndolo con bastante esfuerzo.
96
Si no sabes exactamente dnde ests en el proyecto y cunto trabajo te queda, sin lugar a dudas ests en un problema. Cuando debas tener buena suerte para cumplir un compromiso, no la tendrs. Cuando tus estimaciones son errneas, casi siempre son muy bajas. Casi todos los cambios implican ms trabajo. Es importante trabajar enrgicamente para cumplir los compromisos, pero si no puedes terminar el trabajo con unas pocas horas de esfuerzo extra, enfrntate al problema ahora y trtalo con responsabilidad.
RESUMEN
Este captulo ha definido el compromiso. Ha explicado por qu es importante cumplir los compromisos y cmo gestionarlos. Dos o ms partes se comprometen a alguna tarea, cuando estn de acuerdo sobre lo que es esa tarea, quin la har, cundo se har y qu se pagar a cambio. Los compromisos que se hacen de forma adecuada, es razonable que se cumplan. Estn respaldados por un plan, y tanto el plan como el compromiso estn documentados. Deberas gestionar los compromisos para evitar desbordamientos. Si ests desbordado, te equivocars en establecer algunos compromisos y ganars la reputacin de ser una persona que no es de fiar. No cumpliendo los compromisos puedes daar tu carrera, afectar a tus calificaciones y a tu habilidad para conseguir y mantener un trabajo.
Los pasos para gestionar los compromisos son: (1) hacer una lista de tus compromisos actuales, (2) incluir que es lo que hay que hacer y cuando, e (3) incluir una estimacin de cuanto trabajo te supondr cada compromiso.
Recuerda los siguientes hechos en la vida del ingeniero del software: continuars retrasndote a menos que hagas algo diferente. Intentarlo ms duramente no ayudar. Necesitas conocer con precisin dnde ests y qu trabajo te queda por hacer. No puedes contar con la buena suerte para salir de un apuro. Cuando tus estimaciones estn equivocadas, sern casi siempre muy bajas. Casi todos los cambios implican ms trabajo.
EJERCICIO 8
H z una lista de tus compromisos. Incluye un breve resumen sobre en qu a consiste el compromiso, quin est comprometido, cundo se debe cum-
INTRODUCCIN AL PROCESO SOFWARE PERSONAL
97
plir, cunto tiempo esperas dedicarle para cumplirlo, y qu esperas obtener a cambio. Utiliza un formato como el que se muestra en la Tabla 8.3. Entrega una copia de esta lista junto con tu trabajo de casa. Observa que la lista de compromisos es un ejercicio opcional que no necesitas completar a no ser que te lo pida tu profesor. Entrega las copias de las pginas del cuaderno de registro de tiempos, del cuaderno de trabajos y del resumen semanal de actividades que no hayas entregado todava.
CAPITULO 9
La gestin de las programaciones
Este captulo muestra cmo desarrollar y utilizar las programaciones' para controlar el progreso del proyecto. Aprenders a utilizar los puntos de control para controlar el progreso real frente a lo programado; en el ejercicio del captulo, identificars y describirs varios puntos de control para controlar el progreso sobre un proyecto de programacin.
9.1
LA NECESIDAD DE LAS PROGRAMACIONES

Haces programaciones con objeto de cumplir tus compromisos. Una programacin es necesaria cuando tienes varios compromisos de trabajo al mismo tiempo. Con pequeos proyectos o tareas, puedes acabar una tarea antes de comenzar la siguiente. Esta estrategia es factible para unas pocas tareas, cuando hay tiempo suficiente para completarlas todas, y cuando las tareas son cortas o lo bastante sencillas como para acabarlas de un tirn. Cuando las tareas son largas o complejas, o aumenta la carga
No se debe confundir el sentido del trmino programacin como elaboracin de un programa de actividades con su sentido como actividad de desarrollo de programas software. Del contexto queda claro que nos referimos a la elaboracin de un programa de actividades (N. del T.).
'
100
LA GESTIN DE LAS PROGRAMACIONES
de trabajo, o cuando existen restricciones sobre las programaciones, se necesita una gestin del tiempo ms sofisticada. Debes alternar las tareas, haciendo una durante algn tiempo y pasndote entonces a la siguiente. Supongamos, por ejemplo, que tienes que entregar un programa en tres semanas y un trabajo trimestral que completar en 4 semanas. Supn que prevs que vas a necesitar unas cinco horas para escribir el programa, pero el trabajo debe hacerse en un sistema particular disponible solamente una hora al da. Supn tambin, que el trabajo trimestral requiere alguna bsqueda bibliogrfica y que debes entregar un esbozo en una semana. Esperas que el trabajo trimestral te suponga unas 10 horas de trabajo total. Puesto que planificas dedicar 5 horas a la semana a ambos ejercicios, esperas terminarlos en unas tres semanas. Siguiendo la estrategia de terminar una tarea antes de comenzar la siguiente, comienzas el trabajo trimestral primero, puesto que el resumen lo debes entregar en una semana. Como esperabas, haces la bsqueda, realizas el esbozo y acabas el resumen en una semana. Entonces, comienzas a programar. Despus de trabajar un poco, sin embargo, encuentras que el programa te supondr alrededor de 10 horas de trabajo en vez de las 5 estimadas. Desafortunadamente, ni con un intenso esfuerzo, puedes tener el ordenador el tiempo suficiente para acabar el programa en el tiempo previsto. Supn, sin embargo, que has hecho algn trabajo inicial de ambos ejercicios durante la primera semana. Entonces veras que el programa era ms largo de lo que esperabas y tendras tres semanas para encontrar el tiempo necesario extra de ordenador. Conforme trabajes en proyectos cada vez ms grandes, ser cada vez ms importante cuidar la programacin de tu tiempo. Un ingeniero del software tpico puede tener varios mdulos que comprobar para el desarrollo de un proyecto, mientras est trabajando simultneamente en un informe tcnico sobre la documentacin de un producto. Pueden surgir cuestiones sobre un programa desarrollado previamente, necesitando reuniones tcnicas y de revisin del proyecto. Los ingenieros de algn modo pueden encajar muchas de dichas tareas en sus programaciones diarias sin olvidar o menospreciar cualquiera de ellas. Tambin pueden, a menudo, coordinar su trabajo con muchas otras personas. Es necesario hacer juegos malabares para no tirar ninguna bola, por ello el ingeniero necesita tener una programacin personal.
EL DIAGRAMA DE GANTT
Una programacin es una lista ordenada por tiempos de eventos planificados, generalmente presenta un formato como el que se muestra en la
101
Figura 9.1. Dicha figura se denomina Diagrama de Gantt y tiene los siguientes elementos clave: En la parte superior del diagrama estn las fechas. Dependiendo del grado de detalle deseado, la lnea de tiempos, se puede dividir en das, semanas, meses o aos. Tambin puede estar en horas si lo deseas. La columna que est ms a la izquierda contiene un nmero de identificacin (ID) para cada tarea. En la segunda columna de la izquierda estn los nombres de las tareas a realizar. Estn normalmente enumeradas en el orden en el cual esperas hacerlas. En el cuerpo del diagrama, las barras muestran las fechas previstas de comienzo y fin para cada tarea. En la parte inferior izquierda, est el nombre del proyecto, el autor de la programacin y la fecha en que se hizo la programacin. Varios puntos de control se muestran mediante pequeos valos (IDs 2,5,7,9 y 14). Los puntos de control se discutirn posteriormente en este captulo. Como puedes observar, el diagrama de Gantt es una forma til de presentar el flujo general de las tareas de un proyecto. Dichos diagramas son particularmente tiles para coordinar mltiples actividades. Como se explica ms adelante, el diagrama de Gantt tambin proporciona una forma til de seguir el progreso del proyecto frente al plan y la programacin.
CMO HACER UNA PROGRAMACIN DE UN PROYECTO

Para un proyecto de cualquier tamao, el primer paso para hacer una programacin es analizar el trabajo con bastante detalle para identificar las distintas tareas que lo componen. A continuacin, estimar el tamao para cada una de estas pequeas tareas y determinar la cantidad de trabajo que probablemente necesitarn. Finalmente, registra cada tarea en el diagrama de Gantt con una barra, para mostrar cundo comienzan y acaban. Cuando elabores programaciones para trabajar que implican a varias personas, necesitas seguir algunos pasos adicionales:
1. Asegrate de que cada individuo conoce las tareas que tiene que hacer. 2. Obtn un compromiso de fechas para cada una de estas tareas.
3. Identifica las interdependencias entre las tareas. Qu informacin necesita cada persona antes, para ser capaz de realizar el trabajo y de quin le tiene que llegar esa informacin?
Proyecto: Proyecto ABC Autor: Ingeniero X Fecha: 12/1 1/95
Figura 9.1 Ejemplo de diagrama de Gantt.
103
4. Documenta cada una de estas interdependencias. 5. Revisa la programacin propuesta y las interdependencias con todas las personas implicadas, asegrate de que no hay conflictos, desacuerdos o malentendidos.
6. Revisa la programacin para asegurarte de que cubre todas las tareas necesarias para completar todo el trabajo.
Aunque, necesitars ms pasos para elaborar programaciones en grandes proyectos de software, estos principios bsicos te ayudarn a hacer planes para tu trabajo personal o para proyectos con equipos pequeos que impliquen a tus compaeros de clase o colegas.
9.4
PUNTOSDECONTROL
En la planificacin de cualquier proyecto, por pequeo que sea, es importante dividir el trabajo en varias partes que puedan ser estimadas y planificadas. Cada una de estas partes se puede tratar como un elemento de la programacin. Es decir, cuando se completa cada parte, se ha realizado un determinado grado de progreso. Estos puntos de la programacin que son medibles se llaman puntos de control o hitos. Los hitos son una parte importante de la planificacin y gestin de proyectos. Un hito es un punto que, objetivamente, se puede identificar en un proyecto. Un ejemplo, sera la terminacin de alguna actividad especfica del proyecto o una accin importante. Cuando un plan incluye varios hitos, cada uno con una fecha de terminacin planificada, puedes ver fcilmente si ests dentro de lo programado o ests retrasndote. Para ser tiles, los hitos deben ser claros y no ambiguos. Es decir, un punto de control debe ser una accin especfica que se hace o no se hace. Algunos ejemplos de puntos de control concretos son: Has terminado y entregado un trabajo trimestral. Has elaborado y documentado el plan para escribir un programa, utilizando un formato normalizado de planificacin. Has revisado el plan de desarrollo con tu profesor y has hecho las modificaciones sugeridas. Has completado y documentado un diseo de un programa, utilizando un formato de diseo especificado. Has implementado, compilado y corregido un programa hasta que se compila sin errores. Hay muchos ejemplos de puntos de control concretos que son adecuados para los propsitos de la planificacin. El requisito clave, es que la terminacin de cada punto de control se pueda verificar objetivamente.
104
Las informaciones generales que no conducen a un criterio verificable no pueden utilizarse como puntos de control.
Puntos de control no adecuados son:
Has hecho un plan para escribir un programa. Has diseado un programa. Se ha completado el 90% de la codificacin. Aunque algunas de estas sentencias podran refinarse posteriormente, para conducir a un criterio de un punto de control directo y no ambiguo, tal y como estn escritas son muy generales. Para la sentencia, has hecho un plan para escribir un programa, jcmo podras saber si el plan contiene la informacin necesaria? Aunque pudieras encontrar un plan, el punto de control por s mismo no te dice lo que quieres saber. Si no utilizas un marco de trabajo que defina la planificacin, el plan puede estar o no completo. La segunda sentencia, has diseado un programa, jsabes lo que constituye el diseo completo? Casi cualquier cosa se puede considerar como diseo, desde un sencillo diagrama de flujo hasta una descripcin detallada. Si se aade a dicha sentencia que el diseo ha de ser documentado en un formato especificado, esto s podra ser un punto de control adecuado. Fred Brooks describi la sentencia La codificacin se ha completado hasta un 90%, como ejemplo de un informe vago y engaoso sobre el estado de un proyecto tpico de muchos proyectos software [Brooks]. Si alguien te dice que un proyecto va bien, porque la codificacin est casi hecha, es un signo seguro de que hay problemas. Si la persona te dice que ha completado, revisado, compilado y corregido el cdigo de 7 de los 9 nuevos mdulos y ha comenzado a trabajar en el octavo, puedes estar tranquilo de que esa persona sabe de lo que est hablando.
SUGERENCIAS PARA EL ESTABLECIMIENTO DE PUNTOS DE CONTROL

En la realizacin de un plan, establecer puntos de control para cualquier proyecto implica unas pocas horas de trabajo. Intenta identificar varios puntos de control durante una semana. Por ejemplo, si un trabajo te supone unas dos semanas, establece al menos dos puntos de control y preferiblemente cuatro o cinco. Escoge un nmero de puntos de control coherente con la cantidad de trabajo requerido. Ms de un punto de control para una tarea que requiera de tres a cuatro horas sera excesivo. He encontrado ms til establecer un punto de control por cada cinco horas de trabajo. Ms puntos de control te llevara mucho ms tiempo para controlar actividades insignificantes. Para tareas de menos de cinco horas de duracin, gestiona la tarea como una unidad completa. Con es-
105
tas condiciones, la gestin de proyectos reduce el tiempo de gestin. Conforme vayas dedicando las horas necesarias, irs aproximando el trabajo a lo programado. Deberas, permitir siempre un tiempo reducido de seguridad para cada tarea, para el caso de que te lleve ms tiempo de lo esperado. Para las tareas que tengan una duracin de varias semanas, establece al menos un punto de control por cada semana, si solamente esperas dedicarle aproximadamente una media hora semanal a la tarea. Este punto es necesario para recordarte que hagas el trabajo que est planificado. Sin dichos recordatorios, es fcil olvidarse de estas pequeas tareas. Si realmente no puedes definir un punto de control para cada uno de estos perodos de media hora, lo mejor que puedes hacer es gestionar la cantidad de tiempo que t decidas. Hasta que realmente completes un determinado punto de control, solo puedes estimar el progreso de forma general. Los grandes proyectos, a menudo, suponen varias semanas o meses, e implican a varios ingenieros del software. Puesto que las tareas en el proyecto son interdependientes y el proyecto tiene dependencias con otros proyectos, no puedes acabar tus tareas hasta que los otros ingenieros completen las suyas. Es importante para cada ingeniero en un proyecto, tener varios puntos de control intermedios, para que todos puedan saber el estado de todos los trabajos. Si algunos ingenieros tienen problemas, otros pueden ayudarles o adaptar su trabajo para prevenir retrasos en el proyecto global.
9.5
EL SEGUIMIENTO DE LOS PLANES DE LOS PROYECTOS

El seguimiento de un proyecto es una parte importante de la gestin de proyectos y una habilidad clave para los ingenieros del software. Mientras el seguimiento de tu trabajo puede ayudarte con pequeas tareas, la razn principal de hablarte de este tema ahora, es para mostrarte las tcnicas de planificacin y control que necesitars posteriormente. Las habilidades que aprendas con este libro, las aplicars directamente a los trabajos de gran tamao que hars como ingeniero del software. El seguimiento de un plan del proyecto te permite determinar si el proyecto va, adelantado o retrasado segn lo programado. Define puntos de control y un plan detallado que pueda descubrir con precisin qu partes de un proyecto estn teniendo problemas y dnde se necesita ayuda para ajustarse a lo programado. Estos asuntos se vuelven crticos conforme aumenta el tamao del proyecto. Tambin se volvern ms significativos conforme las repercusiones de faltar a un compromiso se vuelven ms serias. Informar sobre el estado real es esencial cuando los proyectos se hacen para los clientes, que son los que pagan.
106
Otra razn para controlar los planes, es para ser capaz de actuar a tiempo frente al problema. Con un efectivo seguimiento del proyecto, reconocers los problemas muy pronto, vers cmo corregirlos y, a menudo, sers capaz de recuperar el proyecto. En efecto, un buen sistema de seguimiento puede ayudarte a anticiparte a los problemas antes de que se vuelvan lo bastante serios como para amenazar el xito del proyecto.
UN EJEMPLO
Un diagrama de Gantt se puede utilizar tanto para representar la programacin del proyecto como para informar dcl progreso frente a lo programado. En la Figura 9.2, por ejemplo, el Ingeniero X informa sobre el estado del proyecto el 13 de diciembre. Observa lo siguiente: La fecha actual se indica por medio de una lnea vertical doble en el da 13/12. Las actividades acabadas se indican por medio de una lnea horizontal sobre el bloque de la tarea. Por ejemplo, los requisitos (ID 1) se han acabado. Las actividades parcialmente acabadas se indican con una lnea horizontal parcial sobre el bloque de la tarea. Por ejemplo, el diseo (ID 6) debera haber sido acabado el 12/12, pero muestra solamente una terminacin del 80%. Hasta acabarlo, naturalmente, este 80% puede ser solamente una estimacin. Las actividades del proyecto que llevan ventaja sobre lo programado se indican con una lnea de progreso que se extiende ms all de la fecha de evaluacin. Por ejemplo, el Ingeniero X comenz la codificacin y las pruebas antes (IDs 8 y 10). Los puntos de control acabados se marcan con una flecha en la fecha real de su realizacin (IDs 2 y 5). Con esta actualizacin puedes ver que el Ingeniero X va un poco retrasado en el diseo con respecto a lo programado, pero va un poco adelantado con la codificacin y pruebas. El hito Diseo acabado an no se ha alcanzado, por lo que el proyecto se puede considerar que lleva retraso.
ALGUNAS SUGERENCIAS SOBRE LA REVISIN DE LA PROGRAMACIN

El principal riesgo con la revisin de la programacin, es que las personas pueden engaarse a ellas mismas. Pueden tener una falsa visin optimista, fijndose en puntos de control vagos o cambiando frecuentemente la programacin. Algunos pasos que te ayudarn a evitar la auto-decepcin son:
Proyecto ABC Ingeniero X

12/1 1/95 13/12/95
Proyecto: Autor: Fecha: Actualizado:
Figura 9.2 Estado del diagrama de Gantt.
108
Asegrate de que los puntos de seguimiento estn definidos con claridad y estn por escrito. No cambies la programacin hasta que hagas un nuevo plan. Cuando informes de la situacin real frente al plan, no cambies el plan. Si deseas mostrar una nueva estimacin de fechas de finalizacin, deja la programacin original en el mismo lugar y anota las nuevas fechas con lneas de puntos. Guarda copias de la programacin original y de todas las actualizaciones. La clave consiste en recordar que ests comparando la situacin real frente a la programacin original que no has cambiado. Dicha programacin era el plan que ests midiendo frente al trabajo realizado. Si alteras el plan original, no tendrs nada frente a lo que medir. Esto es por lo que, cuando ests controlando el estado del proyecto, es una buena idea comprobar la fecha inicial de la programacin. Si dicha fecha est muy prxima a la fecha de revisin, entonces la actualizacin no proporciona una medida til del progreso del proyecto. Pide una programacin original.
9.6
EL SEGUIMIENTO DEL VALOR CONSEGUIDO

Un problema que surge con el seguimiento del proyecto es que, a menudo, es difcil saber donde ests. Supn, por ejemplo, que ests siguiendo mi progreso en la escritura del manuscrito del libro. El plan original para los diez primeros captulos se muestra en la Tabla 9.1. Como puedes ver, el trabajo comenz con una planificacin y un esbozo del esfuerzo, a lo que esperaba dedicarle unos 681 minutos. Siguiendo la planificacin, escrib el prlogo y cada captulo. La tarea implicaba escribir un borrador del captulo, corregir el borrador y reescribirlo. El tiempo esperado para cada captulo se muestra en la Tabla 9.1. Aqu, el tiempo que esperaba dedicar a cada tarea se muestra en la columna Plan-Minutos y la fecha que esperaba para la finalizacin se muestra bajo la columna Semana-Plan. La semana 1, comenc el lunes 17 de abril de 1995. Este plan estaba basado en los datos que haba reunido mientras estaba escribiendo mis dos libros anteriores. Despus de completar este plan, me entrevist con el profesorado de informtica de la Universidad Aeronutica de Embry-Riddle, que queran utilizar el manuscrito del libro para impartir cursos en el mes de septiembre de ese ao. Eso significaba que necesitaba completar el manuscrito de los 1O primeros captulos para el 10 de agosto. Como se ve en la Tabla 9.1, el plan no mostraba la terminacin del captulo 10 hasta la semana 21, que comenzaba el da 4 de septiembre, o sea, tres semanas ms tarde.
1o9
Tabla 9.1 Plan de desarrollo del manuscrito.

Valor Planificado Valor Conseguido
Captulo
Minutos
!Semana
Prlogo
1 Borrador 1 1 Editar 1
Reescribir
207
000
1 1 3,010 1 0,420 1
3,2431 3,243 1,3671 4,610 3,619 12,0391 1,3671 13,4061
1 2 2 3 3 4 4 4
1 1 1
1 1 1
1 1 2
1 1 1
1
3,244 1,367 3,010 1,367 3,010 1,367
760
000
2 2
2
1 Editar 1 1 Reescribir 1
Captulo 2 Borrador
760 207
000
1 17,216 1 3,619 1 20,0351

3,010 1,3671 22,202
1
1
1
1 1
1 1
1 1
Captulo3
1 1 1
1 Reescribir 1 Borrador 1
Editar Editar Borrador Editar Reescribir
760 207
3,619 29,631
1,3671 30,9901 3,010 34,000 3,619 30,427 1,367 39,794
7 7
0
3 3 3
1,367 3,010 1,367
000
Captulo4
1 1
1 1
207
000
1 0 1 0 1 0 11
1 3,619 1 1
3,010 43,6041 47,223 1,367140,5901
1 1
1
1 1 1 1
1 1
4 4
1 1
1 1
3,010 1,367
Editar
000
Captulo 6
1 Reescribir 1 1 Borrador 1
Editar
760 207
3,619 56,019 1,3671 57,3061 3,010 61,196 1,367166,102
12 12
1 4
1,367
000
207
000
Captulo 7
1 Borrador 1 1 Editar 1
Reescribir
1 5 1 6 17
760 800 760 207 000 760 207 000
3,010 69,9921 3,619 73,611 1,367 74,970 3,010 70,700 3,619 02,407 1,367 03,774 3,010 07,505 3,619 91,203 1,367 92,570 1 0O 3,619 1 0 , 1
1 1
1,367
17
1 0
1 Editar 1 1 Reescribir 1
Captulo 9
1 Borrador 1
1 1 1 1 Reescribir 1 Borrador 1
Editar Editar
1 0
19 19
20 20
Captulo 1 0
Total
1
1
21
I
1
20.990
100,o
110
Antes que rehacer el plan, decid revisar mi trabajo de unas semanas, para ver si poda hacer una nueva programacin ms reducida. Tambin decid, que en vez de completar cada captulo, uno tras otro, yo escribira y corregira los borradores, y que algn editor asociado los revisara antes de la redaccin final. Esta aproximacin tendra la ventaja de informarme sobre las crticas del trabajo, y probablemente redundara en un mejor producto final. La desventaja era que no podra completar la revisin de cualquier captulo hasta muy tarde. Entonces, jcmo podra decir si estaba actuando sobre lo programado? La respuesta a este problema es algo llamado valor conseguido. Bsicamente, examin el plan y asign un valor a cada tarea basndome en la cantidad de tiempo que esperaba dedicarle, de acuerdo con lo planificado. Hice esto calculando para cada tarea el porcentaje correspondiente del total de los 20.998 minutos planificados para esta parte del proyecto. As, la tarea planificada de 68 1 minutos tendra un valor ganado de 100*68U20.998 = 3,243%. Para conseguir la programacin acelerada, tena que alcanzar el valor del 100% el da 10 de agosto, o la semana 17, en vez de la semana 2 1. Despus de las cuatro primeras semanas de trabajo, pude ver que completara los 10 primeros captulos a tiempo (vanse la Tabla 9.2 y la Figura 9.3). Aqu, calcul el valor estimado, anotando lo que haba ganado de valor durante cuatro semanas (37,037), o 9,259 cada semana. A
lo0
r
c c ,
,
/
/ /
. .. . .. .
Estimacin
10
13
16
19
Nmero de semana
Figura 9 3 Manuscrito del libro. Valores reales y estimados. .
111
Tabla 9.2 Programacin del libro.

Valor Planificado
Valor Ganado
Valor Estimado
I I
1 0
11
I I
47,223 52,400 57,306 57,386 64,815 66,182 69,992 74,978 82,407 87,585 96,380
I I
I I
92,592 1182 0,5
I I
l2 1 3
1 4
1 5
1 6
1 7 1 8 1 9
20
2 1
100,o
esta velocidad, poda esperar conseguir los valores que se muestran en la columna de Valores Estimados de la Tabla 9.2. Aqu, aparece que alcanzara el 100% la semana 1 1 , o sea mucho antes de la semana 17 que era la semana obligada. El caso es que, utilizando el valor ganado, poda hacer el trabajo en un orden diferente al planificado originalmente y todava controlar el progreso frente al plan. Aunque poda haber rehecho el plan, habra sido mucho trabajo y habra retrasado el proyecto. Puesto que haba aadido la tarea de revisin, la terminacin llevaba un poco ms que lo planificado y realmente acab el manuscrito en la semana 15, a tiempo para el prximo semestre. Aunque no se requiere utilizar ms adelante en este libro, el seguimiento del valor ganado lo encontrars una tcnica muy til para poste-
112
riores gestiones de programaciones en grandes proyectos. El valor conseguido se discute ms a fondo en el captulo 6 del libro general del PSP [Humphrey].
RESUMEN
Este captulo cubre la programacin y los puntos de control, explicando porqu las programaciones son necesarias y cmo utilizar los diagramas de Gantt para hacer programaciones. Los puntos de control son una parte importante de la planificacin y gestin de un proyecto: un punto de control identifica la terminacin de un determinado evento del proyecto, se debe de especificar y establecer el criterio de terminacin. Tendrs al menos un punto de control cada 5 o 10 horas de trabajo, y al menos uno o dos puntos de control para cada proyecto semanal. Los puntos de control te ayudan a ver dnde se encuentra el proyecto y a tomar acciones correctivas cuando el proyecto se est retrasando. El valor ganado te ayuda a controlar con precisin el estado del proyecto y estimar exactamente cundo acabara.
EJERCICIO 9
Define tres o ms puntos de control para el trabajo de codificar un programa de tamao reducido. Entrega un breve informe describiendo cada punto de control y como estos puntos te podran indicar cunto se ha avanzado. Observa que el ejercicio del punto de control es opcional y que no lo necesitas hacer a no ser que te lo pida tu profesor. Entrega las copias de las paginas del Cuaderno de Registro de Tiempos, del Cuaderno de Trabajos y del Resumen Semanal de Actividades que no hayas entregado todava.
REFERENCIAS
[Brooks] Brooks, Frederick P. The Mythical Man-Month, Essays un Software Engineering, Anniversary Edition. Reading, MA: AddisonWesley, 1995. [Humphrey] Humphrey, W.S. A Discipline f o r Software Engineering. Reading, MA: Addison-Wesley, 1995.
CAPITULO 10
/ plan de/proyecto
Este captulo extiende la discusin de la planificacin del producto, para incluir estimaciones de tiempo. Se introduce la tabla del Resumen del Plan del Proyecto para registrar, lo estimado y lo real, del tamao del programa y el tiempo de desarrollo. Como ejercicio, elaborars un plan del proyecto para el siguiente programa que desarrolles.
10.1
LA NECESIDAD DE LOS PLANES DE LOS PROYECTOS

El plan del proyecto define el trabajo y cmo se har. Proporciona una definicin de cada tarea principal, una estimacin del tiempo y de los recursos necesarios y un marco de trabajo para gestionar la revisin y el control. El plan del proyecto, es tambin, un poderoso vehculo de aprendizaje. Cuando est adecuadamente documentado, es un punto de referencia para comparar con el rendimiento real. Esta comparacin permite a los planificadores ver sus errores de estimacin y mejorar su exactitud en la planificacin [Humphrey 891. El plan del proyecto es una parte esencial del mismo. En un proyecto grande, lo ms importante es tener un plan. La razn de que hagas planes de proyectos en este curso, es para que aprendas a hacerlos. Conforme adquieras ms experiencia, tu capacidad para elaborar planes exactos mejorar y sers capaz de hacerlos rpidamente cuando los necesites. Por ahora, el plan del proyecto que hars, solamente incluir una estimacin
114
EL PLAN DEL PROYECTO
del tamao del producto y el tiempo que estimas en hacer el trabajo. Despus de acabar el trabajo, tambin escribirs los datos reales de tama-' o y tiempo. Una vez que has hecho una estimacin de tiempo, escribe la fecha de finalizacin del trabajo, y as, puedes comparar lo estimado con la fecha real de realizacin del mismo. Analizar dichas comparaciones, te ayudar a hacer mejores estimaciones para las tareas futuras. Si por ejemplo, tus estimaciones normalmente son muy bajas, puedes ajustarlas al alza, o a la inversa, si las estimaciones son muy altas, puedes ajustarlas a la baja. Ten cuidado al hacer estos ajustes, aunque sean fciles de corregir.
EL RESUMEN DEL PLAN DEL PROYECTO

La tabla que utilizars para registrar los datos planificados y reales del proyecto se muestra en la Tabla 10.1. En captulos posteriores se aadirn otros elementos a esta tabla. Para evitar el tener que introducir nuevas tablas en cada captulo, utilizaremos ahora la tabla Resumen del Plan del Proyecto mostrada en la Tabla 10.2, en la cual las entradas que posteriormente se introducirn aparecen sombreadas. Ignora ahora lo sombreado. Para completar la tabla, rellena las partes de Plan, antes de comenzar el proyecto de codificacin. Cuando acabes, completa los datos en la
Tabla 10.1 Resumen del plan del proyecto.

Estudiante Programa Profesor Resumen Minutos/LOC LOC/Hora Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Total Tiempo Mximo Tiempo Mnimo Plan Real Plan Fecha Programa # Lenguaje Real
Plan
Real
115
Tabla 10.2 Resumen del plan del proyecto del PSP.

Estudiante
Programa
Fecha
Programa # Lenguaje
Real
Profesor
Plan Resumen MinutosiLOC LOCiHora DefectosIKLOC Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Plan Tiempo por Fase (min.) Planificacin Disetio Codificacin Revisin del cdigo Compilacn Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Plan Real Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Plan Actual Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas rota1
Hasta la Fecha
Real
Hasta la Fecha
% Hasta la Fecha
Hasta la Fecha % Hasta la Fecha
DefJHora
Hasta la Fecha %Hastala Fecha
DefAora
parte de Real. En los ejercicios del captulo, te pedirn que presentes una tabla rellena del Resumen del Plan del Proyecto por cada programa que termines a partir de ahora. Guarda copias de estas tablas para que tengas datos de tu trabajo, y puedas utilizarlos en futuros ejercicios. El siguiente apartado explica como rellenar la tabla del Resumen del Plan del Proyecto.
116
10.3
EL RESUMEN
La seccin Resumen contiene los datos de la velocidad utilizados para hacer el plan. Tambin, proporciona un lugar para registrar la velocidad real despus de acabar el trabajo. La primera entrada en la seccin Resumen es MinutosLOC (minutos por lneas de cdigo). Bajo la columna Plan, escribe la velocidad planificada en MinutosLOC. Como se muestra en el ejemplo de la Tabla 10.3, el Estudiante X utiliza los datos histricos de
Tabla 10.3 Ejemplo del resumen del plan del proyecto.
Estudiante Programa Profesor
sr. Z
Estudiante X
Fecha Programa# Lenguaje
//10/96
6
Ada
Resumen Minutos/LOC LOClHora DefeCiMLOC Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin DiseAo Wikaci6n Reviskh del cdigo Compilacin Pruebas Postmorfen Total Tiempo Mximo Tiempo Mnimo Deiectosintroducidos Planificacidn Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Deiectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
~
Plan
7,82 7,67
Real
7,21 8,32
Hasta la Fecha
26 36
18
1 9
Plan
Real
Hasta la Fecha
% Hasta la Fecha
203 282
1Al
137
Plan
Actual
Dei.lHora
Plan
Actual
Def.lHora
117
sus programas anteriores o del Cuaderno de Trabajos para tomar la velocidad de 7,82 MinutosLOC para este programa. Naturalmente, si no tienes datos histricos, tendrs que inventrtelos.
A no ser que tengas una buena razn para hacerlo de otra manera, utiliza tus datos histricos de velocidad media de los ltimos programas registrados en el Cuaderno de Trabajos. Puedes tener necesidad de utilizar un valor diferente, si un nuevo programa es difcil y necesita ms tiempo de la media. O puedes necesitar utilizar un valor diferente para el caso inverso, si un nuevo programa es parecido a otro que has escrito recientemente pero que probablemente necesite menos esfuerzo. Comprobando los valores de tiempo medio, mximo y mnimo para los trabajos de codificacin ms recientes, puedes seleccionar un valor adecuado para un nuevo programa.
La siguiente entrada en la seccin Resumen es LOC/Hora (lneas de cdigo por hora). De nuevo, escribe el valor planificado antes de comenzar el trabajo y el valor real despus de terminarlo. El valor de LOC/Hora se calcula a partir de los MinutosLOC, dividiendo 60 por el valor de MinutosLOC. En el ejemplo de la Tabla 10.3, el Estudiante X planific una velocidad de 7,82 MinutosLOC, por lo que el valor de LOCmora planificado es 60/7,82 = 7,67. El valor de la velocidad de LOC/Hora lo utilizan normalmente los ingenieros para analizar la productividad del desarrollo.
10.4
EL TAMAODEL PROGRAMA
La seccin Tamao del Programa (LOC) de la tabla Resumen del Plan del Proyecto, contiene los datos estimados y reales de los tamaos de los programas y de los rangos de dichos tamaos. Utilizando los mtodos descritos en el Captulo 6, estima el tamao total de un programa que planificas desarrollar y escrbelo en la columna Plan de la fila Total Nuevo & Cambiado. Para completar el Resumen del Plan del Proyecto para el programa 8, el Estudiante X hizo una estimacin del tamao, tal y como se muestra en la tabla 10.4. La razn de que la casilla del tamao est etiquetada como Total Nuevo & Cambiado, es porque deberas registrar solamente los nmeros de LOC que escribas realmente. Despus de escribir unos pocos programas, comenzars a utilizar la librera de rutinas para hacer funciones estndar, o desarrollar un nuevo programa aadiendo o modificando uno hecho previamente. Para ahorrar tiempo de desarrollo, puedes copiar partes de programas hechos anteriormente. Puedes, por ejemplo, decidir reutilizar una funcin en un programa que ya tengas escrita. Antes que escribir todo de nuevo, sencillamente copia ese cdigo y reutilzalo en el nuevo programa.
118
Tabla 10.4 Estimacin del tamao del programa del Estudiante X.

Estudiante Estudiante x Profesor 5 .Z
Fecha Clase
7/10/96 IP
Programa
LOC
Sentencia case sencilla Sentencia case media Bucles Bucle while sencillo Repetir-hasta medio
1 Sentencia casegrande 1
I
12
1
I
17
1
I
24
1 Bucle oeaueo
I I 1 3 1
4 1 5
I
Calc. Clculo grande
LE&
Texto
Cadena pequea de t e x t o Cadena sencilla de t e x t o Cadena media de texto
-+-t
5
1 8
Estimado
26
36
Comentarios: Este programa tiene una sentencia case bastante grande para seleccionar entre un
nmero de condiciones de texto, su tamao podra 5er un poco mayor que la del proqrama 4. Se necesita un bucle sencillo para iterar la5 condiciones de la sentencia case para cada cadena que entra, tambin se necesita un sencillo analizador de cadenas de texto para formatear el texto y obtener el resultado final. Supn que 105 tamaos mximo para las funciones del bucle y del texto son similares a 105 de proqramas anteriores, y el de la sentencia ca5e es alqo mayor. Asume tambin que el tamao mnimo e5 la mitad del tamao mximo.
Ninguna de las lneas de cdigo desarrolladas anteriormente son contabilizadas cuando estimas el tamao del nuevo programa. La razn es que t quieres controlar las LOC que realmente escribes. Ya que estas 1neas son las que consumen la mayor parte del tiempo y con ellas se calcula la velocidad de productividad en MinutosLOC. Esta fila, en el Resumen del Plan del Proyecto, se denomina Total Nuevo & Cambiado, porque este es el nico tipo de cdigo a contabilizar, tanto las LOC nuevas escritas como cualquiera de las anteriores que se hayan cambiado. Entonces, para estimar cuanto tiempo necesitars para desarrollar un programa nuevo, multiplica los MinutosLOC planificados por las LOC Nuevas & Cambiadas planificadas. Por ejemplo, si copias 25 LOC de un programa anterior y desarrollas 30 LOC de cdigo nuevo, solamente tendrs 30 LOC Nuevas & Cambiadas.
119
Por otra parte, si copias 25 LOC de un programa anterior y modificas 7 de esas LOC, seran 37 las LOC Nuevas y Cambiadas: 7 LOC del cdigo cambiado y 30 LOC de cdigo nuevo.
La razn de contabilizar solamente las LOC Nuevas & Cambiadas de esta forma es que, la cantidad de cdigo que utilizas de las libreras y de programas anteriormente desarrollados variar mucho. Tambin, el tiempo, expresado en minutosLOC, para incluir cdigo, es generalmente inferior al que se requiere normalmente para desarrollar cdigo nuevo o modificar el existente. As, si ignoras las LOC reutilizadas y copiadas, generalmente ignorars una parte relativamente pequea del trabajo total y tus estimaciones probablemente sern bastante exactas. Aunque la forma de contabilizar el cdigo modificado y reutilizado puede ser muy compleja, por ahora incluirs todas las LOC nuevas y cambiadas en las estimaciones de tamao, pero no el cdigo reutilizado sin modificar. Ignora cualquier LOC tomada de varios sistemas de librera o de programas previamente desarrollados. Pero si el tiempo dedicado en la reutilizacin de programas previamente desarrollados parece mucho para ignorarlo, consulta un tratamiento ms detallado de este tema en los Captulos 4 y 5 del libro general del PSP [Humphrey 951.
TAMAOMXIMO Y MlNlMO
Los valores de tamao mximo y mnimo en la seccin Tamao del Programa (LOC) se obtienen a partir de un tamao estimado, que se hace de la forma que se describi en el Captulo 6. En el ejemplo de la Tabla 10.4, el Estudiante X utiliz la suma de los tamaos de los programas 1 y 5 como los tamaos mximos para dos de las funciones y seleccion un valor algo mayor del programa 4 para la otra funcin. Para calcular el mnimo, asumi que las nuevas funciones combinadas deberan ser la mitad del tamao total mximo. Entonces, selecciona el tamao ms probable como el valor medio entre esos nmeros. As, tom 36 como el tamao mximo y 18 LOC como el mnimo, y 26 LOC como el tamao ms probable. Los valores de tamao mximo y mnimo son tiles para considerar el rango de tiempo probable para estimar un desarrollo. Por ejemplo, si ests particularmente interesado en completar un programa nuevo en una fecha acordada, considera el tamao mximo como una indicacin de cmo de grande podra ser el programa. Si has estimado que el tamao probable para el nuevo programa era de 26 LOC y el tamao mximo de 36 LOC, puedes permitirte alguna libertad en la codificacin, en caso de que el programa se aproxime hacia el valor mximo. El valor del tamao mnimo se obtiene como se describe en el Captulo 6. La razn principal para calcular este nmero es animarte a pensar sobre el rango de tamao de un programa planificado. Generalmente,
120
basa los planes y los compromisos en los valores de tamao mximo y mnimo. Observa tambin, que los valores mximo y mnimo estn basados nicamente en los rangos de tamao estimado. No se deducen estadsticamente y no se pueden tomar para proporcionarte lmites estadsticos. Hasta que no tengas una cantidad sustancial de datos, solamente utiliza las estimaciones de tamao mximo y mnimo como gua de planificacin general. Cuando tengas ms datos, considera utilizar los clculos de prediccin de intervalos dados en el Captulo 5 y en el Apndice A del libro general del PSP [Humphrey 951.
10.5
EL TIEMPO EN FASES
La siguiente seccin de la Tabla 10.3 del Resumen del Plan del Proyecto se denomina Tiempo en Fase, ya que posteriormente se utiliza para los datos de las fases del proceso de desarrollo del software. Hasta el prximo captulo, sin embargo, utiliza solamente el tiempo total de desarrollo del programa.
Para calcular el tiempo total planificado para el desarrollo de un nuevo programa, estima el tamao del programa en LOC y entonces multiplcalo por los Minutos/LOC planificados de la parte superior de la tabla. Esto te da una estimacin de los minutos totales para desarrollar el programa. Estos valores tambin se muestran en el ejemplo de la Tabla 10.3. El tiempo total planificado se obtiene multiplicando los MinutosLOC planificados por las LOC Nuevas & Cambiadas planificadas: 7,82*26=203,32, o 203 minutos. Tambin calcula los tiempos mximo y mnimo y escrbelos en la columna de Plan. Obtn estos valores multiplicando los tamaos mximo y mnimo por los Minutos/LOC para calcular los tiempos mximo y mnimo respectivamente. Para el mnimo tenemos 7,82* 18=140,76 y para el mximo, 7,82*36=28 1,52. Observa que t tambin podras obtener los valores mximo/mximo y mnimo/mnimo multiplicando las LOC mximas y mnimas por las velocidades mxima y mnima del Cuaderno de Trabajos. Puesto que estos valores, generalmente, proporcionan lmites amplios para utilizarlos de gua, nosotros no los utilizaremos en el Resumen del Plan del Proyecto. Pero pueden dar alguna idea de los mejores y peores tiempos de desarrollo que puedes esperar. Completa y escribe estos datos del Plan en el Resumen del Plan del Proyecto antes de desarrollar el programa y entonces completa los datos Reales cuando acabes el programa. Conforme hagas el trabajo, revisa el tiempo y cuando acabes escribe el total en la fila de Total bajo la colum-
121
na Real. Tambin, cuenta las LOC Nuevas & Cambiadas en el programa terminado y calcula los MinutosLOC y las LOChora reales. Para revisar la forma de rellenar totalmente el Resumen del Plan del Proyecto consulta las instrucciones en la Tabla 10.5.
Tabla 10.5 Instrucciones del resumen del plan del proyecto.
~ ~
Propsito
~.
Esta tabla trata los datos estimados y reales de los proyectos de una forma cmoda y fcilmente recuperable.
_~
.~..~____ _ ~ . . _ _ _ _ _ _ _ _ .
~~
Cabecera
.
~~
____~Resumen MinutosiLOC
Introduce los siguientes datos: Tu nombre y fecha de hoy. Nombre y nmero de programa. Nombre del profesor. El lenguaje que utilizars para escribir el programa.
~
~~~
Antes de iniciar el desarrollo: Escribe los Minutos/LOC planificados para este proyecto. Despus del desarrollo: Divide el tiempo total de desarrollo por el tamao real del programa para obtener los Minutos/LOC reales. Por ejemplo, si el proyecto se hizo en 137 minutos e hiciste 19 LOC, los MinutosiLOC seran 13719 = 7,21. Antes de iniciar el desarrollo: Calcula las LOC por hora planificada para este programa dividiendo 60 por los Minutos/LOC de la casilla de Plan. Despus del desarrollo: Para LOC/Hora Real divide 60 por los Minutos/LOC Reales. Para los 7,21 Minutos/LOC Reales, tenemps 60/7,21 = 8,32 LOClHora Reales
~~~~~~ ~~~
LOC/Hora
~- _____
~~ ~
~~~~
~-
-~
~~
-~
Tamao Programa Antes de iniciar el desarrollo: Escribe bajo la columna plan el valor estimado de Total Nuevas (LOC) & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y escribe las LOC Nuevas & Cambiadas Reales.
~~
.~
.. ..
~~
Tiempo por fase
Para el tiempo total de desarrollo, multiplica el valor de Total Nueva & Cambiada LOC por los Minutos/LOC. Por ejemplo, con 7,82 MinutoslLOC y Total Nueva & Cambiada LOC de 26 LOC, Total = 26*7,82 = 203 minutos. Para el tiempo Mximo, multiplica el tamao Mximo por los Minutos/LOC. Por ejemplo, con 7,82 Minutos/LOC y un tamao Mximo de 36 LOC, Tiempo Mximo = 36*7,82 = 282 minutos. Para el tiempo Mnimo, multiplica el tamao Mnimo por los Minutos/LOC. Por ejemplo, con 7,82 Minutos/LOC y un tamao Mnimo de 18 LOC, Tiempo Mnimo = 18*7,82 = 141 minutos. Una vez acabado el trabajo, escribe el tiempo de desarrollo real en minutos. Obtn estos datos del Cuaderno de Tiempos.
Real
122
10.6
CMO ESTIMAR CON EXACTITUD

Tus estimaciones iniciales de tamao y tiempo probablemente no sern muy precisas al principio. Esto es normal. El primer objetivo, es aprender a hacer estimaciones imparciales. Es decir, por cada 10 estimaciones, ser deseable que 5 estn por arriba y otras 5 por abajo. Aunque preferiras que todas fuesen correctas, dicha exactitud no es probable. Las fluctuaciones en las estimaciones se reducirn gradualmente, pero deberas ser capaz rpidamente de hacer estimaciones imparciales, es decir, hacer ms o menos las mismas sub y sobrestimaciones. Con experiencia, puedes gradualmente reducir la desviacin media del error de la estimacin. Documenta tus estimaciones, estdialas y aprende de ellas. Esto te ayudar a hacer mejores estimaciones. Algunos ingenieros estiman mejor que otros. Conforme sean ms precisas tus estimaciones, aprenders cmo es de grande la tolerancia para hacer sub y sobrestimaciones. Esto te ayudar a estimar el riesgo de hacer compromisos que no puedas cumplir.
Este captulo muestra como hacer planes de proyectos. Describe el proceso de planificacin del producto, define los datos que necesitas y las tablas, y muestra un ejemplo completo de un plan de proyecto. Documentar los planes del proyecto te permite comparar el tiempo y el tamao estimados con el de desarrollo real y aprenders a hacer mejores planes. Para hacer buenos planes, necesitas una estimacin de la cantidad de trabajo a realizar comparndola con trabajos anteriores, datos histricos de tareas similares que hayas hecho, y una tabla para registrar el plan. Para obtener los datos para hacer planes, mide los tamaos de los productos acabados, estima el tamao del siguiente trabajo, estima la velocidad de desarrollo para este trabajo, calcula el tiempo que te supondr el nuevo trabajo, y determina sus rangos probables de tamao y tiempo de desarrollo.
EJERCICIO 10
Haz un plan para codificar el prximo programa. Basa este plan en tus datos histricos y utiliza la Tabla 10.2 de planificacin. En el futuro, haz y entrega un plan para cada ejercicio de codificacin. En este plan, registra la estimacin inicial antes de comenzar el desarrollo y escribe los tiempos y tamaos reales cuando hayas acabado el trabajo. Tambin, entrega
123
una copia de la estimacin del tamao del programa, para ello utiliza la Tabla 10.4. Entrega una copia de los Cuadernos de Tiempos, del Cuaderno de Trabajos y del Resumen Semanal de Actividades que no hayas entregado todava. A partir de ahora y hasta el final del semestre, entrega estas tablas rellenas para cada programa que desarrolles durante este curso.
REFERENCIAS
[Humphrey 891 Humphrey, W.S. Munuging the Software Process. Reading, MA: Addison-Wesley, 1989. [Humphrey 951 Humphrey, W.S. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, 1995.
CAPITULO 11
/ proceso de desarrollo
del soffware
Seguir un proceso sistemtico, te ayudar a planificar y gestionar tu trabajo ms efectivamente. En este captulo se explica cmo utilizar un proceso para desarrollar software. Como ejercicio, hars un plan y codificars un programa, utilizando el proceso descrito en este captulo.
11.1
POR QU UTILIZAMOS LOS PROCESOS

Cuando he colaborado con organizaciones de software para mejorar su rendimiento, uno de los principales problemas que he encontrado, es la determinacin del rendimiento real de las mismas. Un grupo, por ejemplo, no poda decirme cuntos proyectos se haban entregado tarde o haban superado el presupuesto. Sin dichos datos, no haba forma de decirles si ellos iban mejorando o empeorando. Para centrar este problema, comenzaron a reunir datos utilizando los mtodos que aprenders en este captulo. Un proceso es un conjunto definido de pasos para hacer un trabajo. Cada paso o fase de un trabajo tiene especificado unos criterios de entrada que deben ser satisfechos antes de comenzar la fase. De forma similar, cada fase tiene unos criterios de salida que deben satisfacerse antes de ter-
126
EL PROCESO DE DESARROLLO DEL SOFTWARE
minar la fase. Los pasos del proceso definen las tareas y cmo se hacen. El diseo y gestin de procesos son importantes en ingeniera del software, porque la calidad del proceso del ingeniero, determina en gran parte, la calidad y productividad de su trabajo. El objetivo del proceso personal definido en este libro es ayudarte a ser ms efectivo como ingeniero del software. El proceso utilizado en este curso se denomina Proceso Software Personal (PSP). El PSP es un marco de trabajo que ayuda a los ingenieros del software a medir y mejorar su forma de trabajar. Estos dos objetivos son los que te ayudan a desarrollar programas y a mostrarte, como utilizando los procesos, puedes mejorar tu forma de trabajar. Posteriormente, cuando desarrolles programas ms grandes y complejos, puedes extender el PSP para ayudarte con ese trabajo. Este libro no describe cmo definir y extender los procesos. Todo esto se cubre en el texto general del PSP [Humphrey 951.
11.2
ALGUNAS DEFINICIONES
Para discutir los procesos, utilizamos los trminos definidos en el Captulo 5 y algunos pocos ms: Un producto es algo que produces para un colaborador, un empresario o un cliente. Un proyecto normalmente produce un producto. Una tarea se define como un elemento de trabajo. Un proceso define la forma de hacer proyectos.
Los procesos tienen varias fases o pasos, como la planificacin, el desarrollo y las pruebas.
Una fase de un proceso puede estar compuesta de mltjples tareas o actividades, como pruebas de integracin, pruebas del producto y pruebas del sistema. Obsrvese que un proceso puede tener solamente una o muchas fases, y una fase puede tener solamente una o muchas tareas o actividades.
Los planes describen la forma en que un proyecto concreto va a ser hecho: cmo, cundo y qu coste tendr. Tambin puedes planificar tareas individuales.
Un trabajo es algo que haces, tanto un proyecto como una tarea. Cuando un proceso est totalmente descrito, se denomina proceso definido. Los procesos definidos estn compuestos normalmente de guiones, ta-
127
blas, plantillas y estndares. Un guin del proceso es una conjunto de pasos escritos, que los usuarios o agentes del proceso siguen cuando utilizan el proceso. Distintas tablas, tales como registros y resmenes, se utilizan para registrar y almacenar los datos del proyecto. En el resto de captulos del libro, utilizars el PSP. Los elementos del PSP se muestran en la Figura 11.1. Observa que, aunque esta figura muestre tanto los tiempos como los cuadernos de los defectos, no comenzars a reunir datos de defectos hasta el Captulo 12.
Requisitos
I
Planificar Pruebas
Datos de defectos y tiempos
Resumen del plan proyecto
Producto acabado
Datos planificados y reales del proyecto y del proceso
Figura 11.1 Flujo del proceso del PSP
11.3
EL GUIN DEL PROCESO

El guin inicial del PSP se presenta en la Tabla 11.1. Esta es la primera de las distintas versiones del guin del PSP. En los captulos siguientes, este guin se extiende para incluir pasos adicionales. Las fases del proceso del PSP se describen a continuacin y estn resumidas en la Tabla 1 l . 1.
Planificacin. Primero obtn los requisitos del proyecto y completa las partes no sombreadas del Plan en la tabla Resumen del Plan del Proyecto. Finalmente, escribe el tiempo dedicado a hacer esta planificacin en el Cuaderno de Registro de Tiempos.
128
Tabla 11.1 Guin del proceso del PSP.

Propsito Criterios de entrada Guiar en el desarrollo de pequeos programas. La descripcin del problema. Tabla Resumen del Plan del Proyecto del PSP. Datos de tamaos y tiempos reales de programas anteriores. Cuaderno de Registro de Tiempos. Obtn una descripcin de las funciones del programa. Estima las LOC Mx., Mn. y total requeridas. Determina los Minutos/LOC. Calcula los tiempos de desarrollo Mx., Mn., y total. Escribe los datos del plan en la tabla Resumen del Plan del Proyecto. Anota el tiempo de planificacin en el Cuaderno de Registro de Tiempos. Disea el programa. Anota el diseo en el formato especificado. Anota el tiempo de diseo en el Cuaderno de Registro de Tiempos. lmplementa el diseo. Utiliza un formato estndar para introducir el cdigo. Anota el tiempo de codificacin en el Cuaderno de Registro de Tiempos. Compila el programa. Corrige todos los errores encontrados. Anota el tiempo de compilacin en el Cuaderno de Registro de Tiempos. Prueba el programa. Corrige todos los errores encontrados. Anota el tiempo de pruebas en el Cuaderno de Registro de Tiempos. Completa la tabla de Resumen del Plan del Proyecto con los datos de tiempo y tamao reales. Anota el tiempo postmortem en el Cuaderno de Registro de Tiempos. Programa probado a fondo. Diseo adecuadamente documentado. Listado completo del programa. Resumen del Plan del Proyecto completado. Cuaderno de Registro de Tiempos completado.
Planificacin
Diseo
Codificacin
Compilacin
Pruebas
PostmorIem
Criterios de salida
Diseo. Disea el programa. Aunque el diseo necesario no se haga, piensa toda la lgica del programa antes de comenzar a escribir el cdigo. Guarda el diseo en un diagrama de flujo, seudocdigo o en cualquier formato que especifique tu profesor. Al final de la fase de diseo, anota el tiempo de diseo en el Cuaderno de Registro de Tiempos. El proceso de
129
diseo y las distintas clases de representacin del mismo se discutirn posteriormente en el Captulo 17.
Codificacin. Implementa el diseo codificndolo en el lenguaje de programacin seleccionado. Utiliza un formato de codificacin consistente y sigue los estndares de codificacin que especifique tu profesor. Al final de la fase de codificacin, anota el tiempo de codificacin en el Cuaderno de Registro de Tiempos. Compilacin. Compila el programa y corrige todos los defectos que encuentres. Contina compilando y corrigiendo los defectos hasta que compiles el programa sin ningn mensaje de error. Todo el tiempo dedicado a esta fase se contabiliza como tiempo de compilacin, aunque corrijas el cdigo o cambies el diseo. Al final de la fase de compilacin, anota el tiempo de compilacin en el Cuaderno de Registro de Tiempos. Pruebas. Haz bastantes pruebas para asegurarte que los programas cumplen todos los requisitos y superan un conjunto adecuado de pruebas sin error. Todo el tiempo que dediques a esta fase se contabiliza como tiempo de prueba, incluyendo la correccin del cdigo, el cambio de diseo y la re-compilacin. Al final de esta fase, anota el tiempo de pruebas en el Cuaderno de Registro de Tiempos. Postmortem. Completa los datos reales en la tabla Resumen del Plan del Proyecto, tal y como se describe en el resto de este captulo. Puesto que has registrado el tiempo postmortem antes de que hayas acabado la fase postmortem, completa el trabajo como puedas y entonces dedica unos pocos minutos para hacer los clculos finales y escribirlos en el tiempo postmortem estimado. Utiliza este tiempo postmortem estimado para calcular el tiempo de desarrollo total y el resto de clculos.
11.4
PUNTOS DE CONTROL Y FASES

Los puntos de control fueron introducidos en el Captulo 9 para ayudar a hacer y controlar las programaciones de los proyectos. Definiendo de forma explcita y clara los puntos de control del proyecto, puedes hacer planes mejores. La causa de por qu estos planes son mejores, se debe a que los puntos de control proporcionan unos puntos de referencia precisos para medir el estado del proyecto mientras ests haciendo el trabajo.
El proceso de desarrollo del software, extiende la idea de punto de control desde unos pocos puntos a todas las fases del proceso. Con un proceso definido, cada fase produce un resultado especifico y por lo tanto la conclusin de una fase es un punto de control medible. Utilizando un proceso definido, tendrs muchos puntos de control para ayudarte a la planificacin y revisin de tu trabajo.
130
11.5
ACTUALIZACIN DE LA TABLA RESUMEN DEL PLAN DEL PROYECTO

El Resumen del Plan del Proyecto de la Tabla 11.2, es una de las tablas para el proceso del PSP. Sus instrucciones aparecen en la Tabla 11.3. Como hemos visto antes, algunas partes del Resumen del Plan del Proyecto estn sombreadas. Estas partes pueden ignorarse ahora porque
Estudiante Programa Profesor Plan Resumen MinutodLOC LOCiHora DefectosIKLOC Rendimiento VF I Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Plan Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cddigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Plan Defectos introducidos Planificacin __ Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Plan Planificacidn Diseo Codificacidn Revisidn del cdigo Compilacin Pruebas Total Fecha Programa # Lenguaje
Real
Hasta la fecha
Real
Hasta la Fecha
% Hasta la Fecha
Real
Def.iHora
Real

~-
Def./Hora
131
Tabla 11.3 Instrucciones del resumen del plan del proyecto del PSP.
Propsito Cabecera Esta tabla trata los datos estimados y reales de los proyectos de una forma cmoda y fcilmente recuperable.
Minutos/LOC
Antes de iniciar el desarrollo Escribe los Minutos/LOC planificados para este proyecto. Utiliza la velocidad Hasta la Fecha de un programa reciente del Cuaderno de Trabajos o del Resumen del Plan del Proyecto. Despus del desarrollo Divide el tiempo total de desarrollo por el tamao real del programa para obtener los Minutos/LOC reales. Por ejemplo, si el proyecto se realizo en 196 minutos e hiciste 29 LOC, los Minutos/LOC seran 196/29 = 6,76. Antes de iniciar el desarrollo: Calcula las LOC por hora planificada para este programa dividiendo 60 por los Minutos/LOC de la casilla de Plan. Despus del desarrollo Para LOC/Hora Real divide 60 por Minutos/LOC Reales. Para los 6,76 MinutosiLOC Reales, tenemos 60/6,76 = 8,238 LOC/Hora Reales
LOC/Hora
Tamao Programa Antes de iniciar el desarrollo Escribe bajo la columna plan, el valor estimado de Total (LOC) Nuevas & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y escribe las LOC Nuevas & Cambiadas Reales. Para la columna Hasta la Fecha, aade LOC Reales Nuevas & Cambiadas a las LOC Hasta la Fecha Nuevas & Cambiadas de programas anteriores. Tiempo por fase Plan
Para el tiempo total de desarrollo, multiplica el valor de las LOC Total Nuevas & Cambiadas por los Minutos/LOC. Para el tiempo Mximo, multiplica el tamao Mximo por los Minutos/LOC. Para el tiempo Mnimo, multiplica el tamao Mnimo por los Minutos/LOC. Del Resumen del Plan del Proyecto de un programa reciente, busca los valores de % Hasta la Fecha para cada fase. Utilizando el % Hasta la Fecha de programas anteriores calcula el tiempo planificado para cada fase. Una vez acabado el trabajo, anota el tiempo real en minutos que has gastado en cada fase del desarrollo. Obtn estos datos del Cuaderno de Tiempos.
Real
Hasta la fecha
Para cada fase, escribe la suma del tiempo real y el tiempo Hasta la Fecha de los programas ms recientes. la Fecha y lo divides por el total del tiempo Hasta la Fecha.
% hasta la fecha Para cada fase, escribe 100 multiplicado por el tiempo Hasta
132
no se utilizarn hasta captulos posteriores. Para identificar los cambios de una versin del proceso a la siguiente, los aadidos se muestran en negnta. Comparando la Tabla 10.2 y la 11.2, puedes observar que varias secciones que antes estaban sombreadas ahora se utilizan. Por ejemplo, bajo la columna Tiempo por Fase, las filas de Planificacin, Diseo, Codificacin, Compilacin, Pruebas y Postmortem se incluyen ahora en la Tabla. Tambin, se utilizan las columnas Hasta la Fecha y % Hasta la Fecha. Para indicar que estas columnas se aaden de nuevo a la tabla, las cabeceras de la nueva columna y fila aparecen en negrita. La seccin de Tiempo por Fase de la nueva tabla del Resumen del Plan Proyecto, tiene una fila por cada fase del proceso. Esta fila tiene los tiempos planificados y reales para cada fase del proceso. Durante la fase de planificacin, escribe los datos bajo la columna Plan. Durante la fase Postmortem, escribe los datos bajo la columna Real. Cuando anotes el tiempo en el Cuaderno de Registro de Tiempos, escribe en la seccin de comentarios la fase del proceso donde ests. Entonces, durante la fase postmortem, escribe estos tiempos en la columna Real de la seccin Tiempo en Fase para cada fase. Antes de iniciar un proyecto, completa la parte de Plan de la tabla Resumen del Plan Proyecto, tal y como se indica en el Captulo 10. Ahora, la nica diferencia es que t necesitas estimar el tiempo que vas a dedicar a cada fase. Esto se hace asignando a c.ada fase un porcentaje del tiempo de desarrollo total, basndote en la utilizacin del tiempo en proyectos anteriores. La primera vez que utilices esta versin del PSP, no tendrs datos reales para hacer esto, entonces, tendrs que inventrtelos. Para proyectos sucesivos, sin embargo, puedes utilizar los datos de proyectos anteriores para estimar el tiempo para cada fase del nuevo proyecto. Esta es la razn de por qu aparecen los valores de % Hasta la Fecha en la tabla Resumen del Plan del Proyecto. Las columnas de Hasta la Fecha y % Hasta la Fecha de la tabla Resumen del Plan del Proyecto, proporcionan una forma sencilla de calcular la distribucin de los porcentajes del tiempo de desarrollo para las fases del proceso. La columna Hasta la Fecha contiene el total de todos los tiempos dedicados en cada fase para todos los programas acabados. La columna de % Hasta la Fecha tiene el porcentaje de los tiempos de la columna Hasta la Fecha. El ejemplo de la Seccin l l .7 muestra cmo calcular las entradas de Hasta la Fecha y % Hasta la Fecha.
'
11.6
UN EJEMPLO DE PLANIFICACIN
La Tabla 11.4 muestra como el Estudiante X ha completado parte del plan de la tabla Resumen del Plan del Proyecto para el programa 9. Utiliz los
133

sr. Z
Estudiante X
Fecha
Programa#
21/10/96
9
Ada
Lenguaje
Plan
7,21
Resumen MinutosiLOC LOClHora DefectosiKl OC Rendimiento VIF Tamaio Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
Real
8.32
Hasta la fecha
23
15
Plan
Real
Hasta la Fecha
% Hasta la Fecha
74
25 52 1 0 166 224 108
Plan
Real
Hasta la Fecha %Hasta la Fecha
DefJHora
Plan
Real
DefJHora
datos del Resumen del Plan del Proyecto del programa 8 de la Tabla 11.5. Los datos del plan de la Tabla 11.4 se obtienen de la siguiente forma: Minutos/LOC. En la planificacin del programa 9, busca los Minutos/LOC Reales para el programa anterior, el programa 8 de la Tabla 1 1.5, y localiza la velocidad de 7,21 MinutosLOC.
A no ser que tengas una buena razn para hacer otra cosa, utiliza estas velocidades reales anteriores en la planificacin de los nuevos proyec-
134

5r. Z
Estudiante X
Fecha Programa#
7/10/96
0
__
Real
Lenguaje
721 0,32
Ad a
Resumen Plan 7,02 Minutos/LOC 7,67 LOClHora DefectosIKiOC Rendimiento VIF Tamao Programa (LOC): 26 Total Nuevo & Cambiado 36 Tamao Mximo 18 Tamao Mnimo Tiempo por Fase (min.) Plan Planificacin 1 0 Diseo 19 10 1 Codificacin Revisin del cdigo 12 Compilacin 29 Pruebas 1 5 Postmorten 203 Total _no Tiempo Mximo 1Al Tiempo Mnimo Defectos introducidos Plan Real Planificacin DiSeAo Codificacin Revisin del cdigo compilacin PnrebeS rota/ Defectos eliminados Plan Real Planiffcacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas rota1
Hasta la iecha
721 0,32
19
1 9
Real
4
Hasta la Fecha
% Hasta la Fecha
O
6 1
2 1 43 0 137
4 0 6 1 2 1 43
0
23 O
44,6 153
31,4
137
5,8 100,O
DefJHora
Def.IHora
tos. En el futuro, mejor que utilizar la velocidad real de los programas anteriores, utilizars las velocidades media de todos los programas desarrollados hasta la fecha. Cuando se incluyan las velocidades Hasta la Fecha en el PSP en el Captulo 12, podrs utilizar estos datos. LOC/Hora. El Estudiante X calcul el valor de LOC/Hora, as: 60/7,2 1=8,32. Tamao del programa. De igual forma que en el Captulo 6, el Estudiante X estim las LOC Total Nuevas & Cambiadas del pro-
135
grama y las LOC Mx. y Mn. En el ejemplo de la Tabla 11,4, estos tamaos son 23, 31 y 15 LOC respectivamente. Tiempo por Fasefloral. Utilizando el tamao estimado de 23 LOC y la velocidad de 7,21 minutosLOC, el tiempo de desarrollo es 7,21*23 = 166 minutos. Tiempo Mximo. El tiempo mximo se obtiene multiplicando el valor de los MinutosLOC por el tamao mximo, 7,21 * 31 = 224 minutos. Tiempo Minimo. El tiempo mnimo se obtiene multiplicando el valor de los MinutosLOC por el tamao mnimo, 7,21 * 15 = 108 minutos. Con un tiempo total de desarrollo estimado de 166 minutos, utiliza los datos de % Hasta la Fecha de la Tabla 11.5 para estimar los tiempos de las fases para desarrollar el programa 9. El Estudiante X hizo estos clculos de la siguiente forma:
Plan$cacin. El tiempo de planificacin estimado es 2,9* 166/100 = 4,81, o aproximadamente 5 minutos. Diseo. El tiempo de diseo planificado es 0*166/100 = O. Codificacin. El tiempo de codificacin planificado es 44,6*166/100 = 74,04, o 74 minutos. Compilacin. El tiempo de compilacin planificado es 15,3*166/100 = 25,40, o 25 minutos. Pruebas. El tiempo de pruebas planificado es 31,4*166/100 = 52,12, o 52 minutos. Posrmorrem. El tiempo postmortem planificado es 5,8* 166/100 = 9,63, o 10 minutos.
Recuerda que del primer programa desarrollado con el PSP, no tendrs datos anteriores para utilizarlos como gua. Puesto que el Estudiante X no tena datos anteriores cuando estaba planificando el programa 8, se los invent. Como puedes observar, comparando los tiempos planificados y reales de la Tabla 11.5, su distribucin real de tiempo era bastante distinta a sus suposiciones. Unos pocos datos pueden provocar una gran diferencia en la planificacin. Para el programa 9, el plan del Estudiante X est mucho ms prximo a sus datos reales.
11.7
UN EJEMPLO PARA CALCULAR LOS DATOS HASTA LA FECHA

En la fase postmortem del programa 9, el Estudiante X contabiliz 29 LOC nuevas y cambiadas, y anot este nmero en la casilla Real de la
136
Tabla Resumen del Plan del Proyecto de la Tabla 11.6. Despus, localiz los tiempos reales para cada fase en el Cuaderno de Registro de Tiempos y los anot en la tabla Resumen del Plan del Proyecto. Esta vez, ambas estimaciones de tamao y tiempo eran razonablemente ms prximas al resultado real. El Estudiante X le dedic algo ms de lo esperado para el desarrollo del programa, su velocidad LOC/Horas real estaba muy prxima a sus velocidades histricas. Tambin, la distribucin de tiempos no se alej mucho del plan. Para completar la columna Hasta la Fecha de la Tabla 11.6, el Estudiante X sum los tiempos reales de esta tabla a los tiempos Hasta la Fecha del programa 8 de la Tabla 11.5. Tambin, calcul los porcentajes Hasta la Fecha de la Tabla 11.6, dividiendo los valores de Hasta la Fecha en cada fase por el tiempo Total Hasta la Fecha de 333 minutos y multiplicarlos por 100. Los clculos para estos valores fueron los siguientes: LOC Total Nuevas & Cambiadas LOC Hasta la Fecha Nuevas y Cambiadas = 19 + 29 = 48. Tiempo de planificacin Hasta Planificacin la Fecha = 4 + 11 = 15. % Hasta la Fecha, planificado = 100" 15/333 = 4 3 Diseo Tiempo de diseo Hasta la Fecha = O + 12 = 12. % Hasta la Fecha, diseo = 100*12/333 = 3,6. Tiempo de codificacin Hasta la Codificacin Fecha = 61 + 85 = 146. % Hasta la Fecha, codificacin = 100*146/333 = 43,9 Compilacin Tiempo de compilacin Hasta la Fecha = 21 + 28 = 49. % Hasta la Fecha, compilacin = 100*49/333 = 14,7. Tiempo de pruebas Hasta la FePruebas cha = 43 + 49 = 92. % Hasta la Fecha, pruebas = 100*92/333 = 27,6. Tiempo postmortem Hasta la Postmortem Fecha = 8 + 11 = 19. % Hasta la Fecha, postmortem = 100*19/333 = 5,7. Tiempo total de desarrollo HasTotal ta la Fecha = 137 + 196 = 333.
137

Estudiante
Estudiante X
Fecha
21/10/96
Programa
Profesor
5 %
Programa#
9
Ada
Z
Plan
7,21 0,32
Lenguaje
Resumen MinutosiLOC LOCiHora DefectosIKLOC Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
Real
6,76 0,00
Hasta la fecha
23 3 1 1 5
29
48
Plan
5 O 74
Real
11
Hasta la Fecha
12 05 20 49 11 196
15 12 146
% Hasta la Fecha 4,5 3,6 43,9
25 52 10 166 224 100

~
49 92 1 9 333
14,7 27,6 5,7 100,o
Plan
Real
DefJHora
Plan
Real
DefJHora
Con los datos del programa 9, el Estudiante X puede estimar los tiempos que va a dedicar en cada fase de su prximo proyecto. Para ser ms prctico, sin embargo, deberas utilizar la media de los tiempos de los distintos proyectos. Las columnas Hasta la Fecha y % Hasta la Fecha realizan estos clculos. En el programa 8 de la Tabla 11.5, la columna Hasta la Fecha contiene los tiempos reales que el Estudiante X ha dedicado al proyecto. Cuando desarroll el programa 9, sin embargo, aadi los tiempos reales de los programas 8 y 9 para obtener los nuevos valores
138
Hasta la Fecha. El nuevo valor de % Hasta la Fecha nos da la distribucin de tiempos medios de los programas 8 y 9. De forma similar, cuando se complete el Resumen del Plan del Proyecto para el programa 10, tendrs la distribucin de tiempos medios para los programas 8, 9 y 10 y as sucesivamente. De un proyecto a otro, los tiempos de desarrollo total variarn. Sin embargo, la distribucin del tiempo entre las fases, ser ms estable. Esto, naturalmente, depende de la calidad de tus procesos. Por ejemplo, cuando dedicas mucho tiempo a compilar y probar, los tiempos de planificacin de las distintas fases sern menos exactos debido a la gran cantidad de tiempo impredecible que se dedica a resolver os defectos. Cuando se obtienen los tiempos medios de los distintos programas, sin embargo, la cantidad media de tiempo dedicado a la compilacin y a las pruebas no cambiar mucho. Es decir, no cambiar mientras no cambies el proceso. Cuando al principio utilices el PSP, probablemente dedicars de 1/3 a 1/2 de tu tiempo a encontrar y corregir los defectos durante la fase de compilacin y pruebas. Conforme utilices los mtodos del PSP en los siguientes captulos, reducirs el nmero de defectos encontrados en la compilacin y pruebas, y as reducirs los tiempos de compilacin y pruebas. Esto ahorrar tiempo de desarrollo, mejorar la estimacin y permitir planes ms exactos y programas mejor hechos.
RESUMEN
Este captulo define un proceso, describe el proceso bsico del PSP y muestra como un proceso definido, puede ayudar a mejorar tus planes. La tabla del Resumen del Plan del Proyecto aumenta para incluir los tiempos de las fases del proyecto y calcular el tiempo Hasta la Fecha y el porcentaje del tiempo de desarrollo dedicado a cada fase. Haciendo planes de proyectos, querrs estimar el tiempo que vas a dedicar a cada fase. Te basars en experiencias anteriores, utilizando para ello los valores de % Hasta la Fecha de los programas anteriores. Utilizando el PSP, hars un Resumen del Plan del Proyecto para cada proyecto, completa las partes del Plan antes de comenzar a trabajar, escribe los datos Reales cuando acabes y completa los apartados de Hasta la Fecha y % Hasta la Fecha.
EJERCICIO 11
Utilizando la tabla del Resumen del Plan del Proyecto mostrada en la Tabla 11.2, haz un plan para codificar tu prximo programa. Primero, estima el tamao del programa, tal y como se describe en el Captulo 6. Para
INTRODUCCION AL PROCESO SOFTWARE PERSONAL
139
este primer programa con el PSP, estima la distribucin del tiempo en las distintas fases. En adelante, utiliza para hacer estimaciones, las cifras de % Hasta la Fecha de la tabla del Resumen del Plan del Proyecto del programa ms recientemente desarrollado. Anota la estimacin antes de hacer el trabajo y cuando lo acabes, escribe los tiempos y tamaos reales de las distintas fases. Tambin, entrega una copia de los Cuadernos de Registro de Tiempos, del Cuaderno de Trabajos y del Resumen Semanal de Actividades que no hayas entregado todava.
REFERENCIA
[Humphrey 951 Humphrey, W.S. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, 1995.
CAPITULO 12
En este captulo se introduce el tema de los defectos del software (vase la Seccin 12.4 para saber por qu no le llamamos bugs). Los defectos pueden causar serios problemas a los usuarios de los productos software, y pueden ser caros de encontrar y corregir. Puesto que los defectos son causados por los errores de los desarrolladores, los ingenieros necesitan entender los defectos que introducen para aprender a gestionarlos. El primer paso para la gestin de defectos, es reunir los datos de los defectos que has introducido en tu programa. Con estos datos, puedes mejorar la forma de encontrarlos y corregirlos. Como ejercicio del captulo, reunirs y resumirs los datos de los defectos que hay en tus programas. Hasta ahora, en este libro, solamente hemos hablado de mtodos para gestionar el coste y las programaciones. Esta, es la mitad de la historia. Comenzando con este captulo, estudiaremos la necesidad de entregar productos software de calidad. Primero, necesitaremos una definicin de calidad.
12.1
QU ES LA CALIDAD DEL SOFTWARE?

La calidad del software afecta a los costes de desarrollo, programacin de las entregas y la satisfaccin del usuario. Puesto que la calidad del software es tan importante, necesitamos discutir primero qu significa la palabra calidud. La calidad de un producto software debe ser definida en trminos
142
DEFECTOS
que tengan significado para los usuarios del producto. As, un producto que proporciona las prestaciones que son ms importantes para los usuarios, es un producto de calidad. Las necesidades de los usuarios, a menudo, se expresan en los documentos de requisitos. Debido a su importancia, el desarrollo, clarificacin y refinamiento de los requisitos es un objetivo por si mismo. Por lo tanto, nosotros no vamos a tratar los requisitos en este libro. Es importante recordar, sin embargo, que hasta que no tengas claro los requisitos, no puedes desarrollar un programa de calidad. Aunque puedes comenzar con requisitos poco claros, debes entenderlos antes de poder acabar. La calidad del software es un tema tan enorme, que en este libro se tratar de forma parcial. El libro, sin embargo, proporciona las habilidades y prcticas que necesitars para entender los defectos que introduces, y esto te dotar, de un mecanismo eficiente para que encuentres y corrijas muchos de tus defectos. Tambin te proporcionar los datos para ayudar a prevenir estos defectos en el futuro. Finalmente, una vez que puedas gestionar los defectos eficientemente, puedes dedicar ms atencin a aquellos aspectos de la calidad que afectan a la utilidad y valor de los programas que desarrolles.
12.2
DEFECTOS Y CALIDAD
Recuerda, del Captulo 1, que el trabajo de un ingeniero del software es entregar productos de calidad con unos costes y programaciones planificadas. Recuerda tambin, que los productos software deben satisfacer tanto las necesidades funcionales de los usuarios como hacer de una forma segura y consistente el trabajo de los mismos. La realizacin del trabajo es un aspecto clave. Aunque las funciones del software son muy importantes para los usuarios de los programas, estas funciones no sern tiles a menos que el software funcione. Para que el software funcione, debes eliminar sus defectos. As, aunque hay muchos aspectos relacionados con la calidad del software, el primer aspecto de la calidad est relacionado necesariamente con sus defectos. Esto no significa que los defectos son el nico aspecto o que son lo ms importante, pero debes tratar con muchos de los defectos antes de poder satisfacer cualquiera de los otros objetivos del programa. Despus de conseguir que los programas funcionen, si tienes unos pocos defectos, no funcionarn en grandes sistemas, no se utilizarn, y no se tendr en cuenta sus otras cualidades. La causa de que los defectos sean tan importantes, es porque las personas cometen muchos errores. En efecto, los programadores experimentados normalmente cometen un error por cada 7 a 10 lneas de cdigo que desarrollan. Aunque generalmente encuentran y corrigen muchos de esos defectos cuando compilan y prueban sus programas, a
143
menudo, muchos de los defectos permanecen en el producto acabado. Entonces, tu primera prioridad es entender los defectos que introduces y prevenirlos como puedas. Para hacer esto, necesitas dominar el lenguaje de programacin que utilices, entender a fondo los sistemas que soportan el desarrollo y haber dominado los tipos de aplicaciones que desarrollars. Estos y otros pasos ms son necesarios para reducir el nmero de defectos que introduces.
12.3
LQU SON LOS DEFECTOS?

El termino defecto se refiere a algo que est equivocado en un programa, tal como un error sintctico, una falta tipogrfica, un error de puntuacin, o una sentencia incorrecta del programa. Los defectos pueden estar en los programas, en los diseos o incluso en los requisitos, las especificaciones o en otra documentacin. Los defectos pueden ser sentencias extra o redundantes, sentencias incorrectas o secciones del programa omitidas. Un defecto, es cualquier cosa que reduce la capacidad de los programas para cumplir completa y efectivamente las necesidades de los usuarios. Un defecto es una cosa objetiva. Es algo que puedes identificar, describir y contabilizar. Errores sencillos de codificacin pueden producir defectos muy destructivos o que sea difcil encontrarlos. A la inversa, muchos defectos sofisticados de diseo pueden encontrarse fcilmente. La sofisticacin del error de diseo y el impacto del defecto resultante, son en gran parte independientes. Los errores triviales de implementacin pueden causar serios problemas en el sistema. En efecto, la fuente de muchos defectos software son simples descuidos y errores del programador. Aunque los aspectos de diseo son siempre importantes, cuando comienzas a codificar los programas, normalmente tienen pocos defectos de diseo comparados con el nmero de simples descuidos, erratas y pifias. Para mejorar la calidad del programa, es esencial que los ingenieros aprendan a gestionar todos los defectos que introducen en sus programas.
Es importante separar la cuestin de encontrar o identificar los defectos de la determinacin de sus causas. La simple contabilizacin y registro de los defectos en los productos software no es la especificacin de las causas ni la asignacin de culpas. Los defectos cometidos, sin embargo, tienen sus causas. Puedes haber cometido un error al escribir el nombre de un parmetro, omitido un signo de puntuacin o llamado incorrectamente un procedimiento. Todos estos errores causan defectos. Todos los defectos, por consiguiente, provienen de errores humanos y muchos de los que los ingenieros del software cometen, causan defectos en los programas.
144
DEFECTOS
Los errores son cosas incorrectas que cometen las personas y, sin tener en cuenta cundo y quin los comete, los defectos son elementos defectuosos de los programas. As, las personas cometen errores o equivocaciones mientras que los programas tienen defectos. Cuando los ingenieros cometen errores que conducen a defectos, nosotros nos referimos a esto como la introduccin de defectos. Esto significa que para reducir el nmero de defectos que introduces en tus productos, debes cambiar la forma de hacer las cosas. Para eliminar los defectos en tus productos, sin embargo, sencillamente tienes que encontrarlos. La eliminacin de defectos es, por lo tanto, un proceso ms sencillo que la prevencin de defectos. La prevencin de defectos es un aspecto importante y prioritario que requiere un estudio comprensivo de todo el proceso de desarrollo del software [Humphrey 891. El resto de este libro nos centraremos en la eliminacin de defectos.
A no ser que los ingenieros encuentren y corrijan los defectos que introducen, estos defectos llegarn al final a los productos acabados. El problema es que lleva mucho tiempo y dinero encontrar y corregir los defectos del software. Para producir pocos defectos, debes aprender de los defectos que has introducido, identificar los errores que los causan y aprender cmo evitar repetir el mismo error en el futuro. Puesto que los productos defectuosos pueden ser caros de probar, difcil de corregir y posiblemente peligrosos de utilizar, es importante que aprendas a minimizar el nmero de defectos que dejas en tus productos. Este libro muestra cmo hacer esto.
Los defectos deberan ser importantes para cada ingeniero del software no slo porque afectan a los usuarios, sino tambin porque ms de la mitad del esfuerzo de las organizaciones de software est dedicado a encontrar y corregir los defectos. Puesto que el tiempo de pruebas es difcil de predecir, los defectos son, a menudo, la causa principal de los problemas de costes y programaciones.
12.4
DEFECTOS VERSUS BUGS

Algunas personas, errneamente se refieren a los defectos del software como bugs. Cuando lo denominan como bugs, parece que son cosas malditas que deberan ser aplastadas o ignoradas. Esto trivializa un problema crtico y fomenta una actitud errnea. As, cuando un ingeniero dice que hay solamente unos pocos bugs en el programa, la reaccin es de alivio. Supongamos, sin embargo, que los denominamos bombas de efecto retardado en vez de bugs. Sentiras la misma sensacin de alivio si un proEs habitual usar el trmino bug (gusano) para denotar los errores que hay en un programa. El autor se refiere a esta forma de referenciar los errores (N. del T.).
145
gramador te dijese que ha probado a fondo un programa y que ha dejado solamente unas pocas bombas de efecto retardado? Utilizando trminos diferentes, tu actitud cambia completamente. Los defectos son ms parecidos a las bombas de efecto retardado que a los bugs. Aunque todos no tendrn un impacto explosivo, alguno si podra tenerlo. Cuando los programas se utilizan mucho y de manera distinta a la que sus diseadores haban previsto, los errores triviales pueden tener consecuencias imprevisibles. Cuanto ms ampliamente se utilizan los sistemas software, ms se incrementan las nuevas necesidades a satisfacer, los problemas latentes podrn aparecer y un defecto aparentemente trivial puede ser verdaderamente destructivo. En este momento, aquellos lectores que han codificado varios programas, probablemente movern sus cabezas y pensarn que estoy exagerando el caso. En cierto sentido, lo estoy haciendo. La gran mayora de defectos triviales tienen consecuencias triviales. Desafortunadamente, sin embargo, un pequeo porcentaje de errores aparentemente tontos pueden causar serios problemas. Por ejemplo, un simple error de inicializacin caus el desbordamiento de un buffer. Esto origin que un sistema de control de ferrocarril perdiese datos. Entonces, cuando hubo una interrupcin, el sistema no pudo restablecerse rpidamente y todos los trenes en varios miles de millas de trayectoria tuvieron que parar durante varias horas, mientras los datos necesarios se volvieron a introducir. Algn porcentaje de defectos en un programa, probablemente tendr consecuencias impredecibles. Si supisemos por adelantado cules son dichos errores, entonces los podramos arreglar y no preocuparnos del resto. Desafortunadamente, no hay forma de hacer esto y cualquier defecto que se ha dejado pasar, puede potencialmente tener serias consecuencias. Aunque es verdad que muchos programas no se utilizan en aplicaciones donde el fallo es ms que una molestia, el nmero est creciendo. As, aunque los defectos puede que no sean ahora una cuestin importante para ti, pronto lo podrn ser. Es importante que aprendas a gestionar los defectos ahora para que ests preparado cuando verdaderamente necesites hacer programas de gran calidad. El ingeniero del software que escribe un programa, est ms capacitado para encontrar y corregir sus defectos. Es importante que los ingenieros del software asuman la responsabilidad personal con respecto a la calidad de los programas que hacen. Aprender a codificar programas libres de defectos es, sin embargo, un enorme reto. Esto no es algo que cualquiera pueda hacer rpidamente o fcilmente. Requiere informacin, una tcnica efectiva y habilidad. Utilizando los mtodos descritos en este libro, puedes desarrollar y perfeccionar tu capacidad para hacer programas de gran calidad. Despus de todo, si no te esfuerzas en hacer un trabajo sin defectos, probablemente nunca lo conseguirs.
146
DEFECTOS
12.5
TIPOS DE DEFECTOS
Para analizar los defectos, es til dividirlos en categoras. Este libro clasifica los defectos en 10 tipos generales. Clasificando los defectos en unos pocos tipos, puedes ver rpidamente qu categoras causan mayor problema y as, te puedes centrar en su prevencin y eliminacin. Esto, naturalmente, es la clave de la gestin de defectos. Cntrate en unos pocos tipos de defectos que son los ms problemticos. Una vez que estos tipos estn bajo control, identifica el conjunto siguiente y trabaja sobre ellos, y as indefinidamente. Los tipos de defectos utilizados en este libro se muestran en la Tabla 12.1. Esta lista procede del trabajo de Chillarege y sus colegas en el centro de investigacin de IBM [Chillarege]. Estudi los defectos en una amplia variedad de productos IBM e identific sus categoras principales. Estos mismos tipos se han utilizado en el PSP [Humphrey 951. En la Tabla 12.1, las categoras de defectos se refieren a clases genricas de problemas. Por ejemplo, los defectos de sintaxis del tipo 20 se refieren a todos aquellos elementos que no coinciden con la especificacin del lenguaje de programacin. Por ejemplo, omitir un punto y coma, escribir incorrectamente la sentencia i f , errores de ortografa o declaracioTabla 12.1 Tipos de defectos estndar.
Tipos de defectos
Nmero del tb0 10 20
1
1 1 1
I
DescriDcin
Nombre del tiD0
Documentacin Sintaxis
comentarios, mensajes ortografa, puntuacin, erratas, formato de las instrucciones
30 40
1 Construir, paquetes 1 gestin del cambio, libreras, cn o 1 Asignacin Interfaz declaracin, nombres duplicados, mbito, lmites llamadas a procedimientos y referencias, E/S, formatos de usuario
50
60
70
1 Chequeo
Datos Funcin
1 mensajes de error, chequeos inadecuados

estructura, contenido lgica, punteros, bucles, recursin, computacin, defectos de la funcin
1 I
80 90
1O0
1 Sistema
Entorno
1 configuracin, temporizacin, memoria

diseo, compilacin, pruebas y otros problemas que soporta el sistema
147
nes inadecuadas. Un defecto de sintaxis del tipo 20 es cualquier defecto que da lugar a un programa sintcticamente incorrecto, sin tener en cuenta como se originaron los defectos o se encontraron. Otra categora de defecto podra ser la del tipo 80 (el tipo funcin). Un ejemplo aqu sera el bucie do-while con una incorreccin lgica en la condicin while. La clasificacin de la Tabla 12.1, est ordenada por el grado de sofisticacin general de la probable causa del defecto. Por ejemplo, los defectos de los tipos 10,20 y 30 resultan de un simple descuido o error. Los defectos de los tipos 80,90 y 100, sin embargo, normalmente implican un diseo ms sofisticado o cuestiones del sistema. Antes de refinar cada una de estas 10 categoras de defectos del PSP en subcategoras, espera hasta que hayas reunido los datos de defectos de un nmero de programas. Entonces puedes ver, dnde un mayor detalle te ayudara y qu informacin especfica adicional sera necesaria. Por ejemplo, podras dividir los defectos de sintaxis del tipo 20 en los subtipos 21 para los puntos y comas, el 22 para otros errores de puntuacin, el 23 para los problemas de expresiones booleanas, el 24 para formatos de instrucciones incorrectas y as sucesivamente. Antes de definir nuevas subcategoras para cada tipo de defecto, espera hasta que hayas reunido los datos de al menos 100 o ms defectos. An as, probablemente encontrars que estos tipos de datos de defectos iniciales son adecuados.
12.6
LA COMPRENSIN DE LOS DEFECTOS

El primer paso para gestionar los defectos es entenderlos. Para hacer eso, debes reunir los datos de defectos. Entonces, podrs entender estos errores y comprender cmo evitarlos. Puedes tambin comprender cmo encontrarlos mejor, corregirlos o prevenir el defecto que todava introduces. Para reunir datos de defectos de tus programas, haz lo siguiente: Registra cada defecto que encuentres en un programa. Registra la informacin suficiente sobre cada defecto para que puedas entenderlo posteriormente. Analiza estos datos para ver qu tipos de defectos causan los mayores problemas. Idea formas de encontrar y corregir estos defectos. Los defectos que introduces y encuentras en tus propios programas, son solamente parte de la historia. Algn da, necesitars aprender sobre los defectos que otras personas encuentran en tus programas. Puesto que estos defectos se escaparn a todos los esfuerzos de deteccin y prevencin de defectos, sern ms importantes para entender y tratar las debilidades de tus procesos personales. Estos defectos se denominan escapes, porque han
148
DEFECTOS
escapado a todos tus esfuerzos de eliminacin de defectos. Conforme mejore tu proceso personal, los defectos que se escapan sern la ltima fuente principal de datos para tu mejora personal.
12.7
EL CUADERNO DE REGISTRO DE DEFECTOS

El cuaderno de registro de defectos est diseado para ayudarte a reunir datos de defectos. El cuaderno se muestra en la Tabla 12.2 y sus instrucciones se indican en la Tabla 12.3. Utiliza este cuaderno para reunir datos de defectos para cada programa que codifiques. Describe cada defecto con bastante detalle para que puedas entenderlo ms adelante. Despus de haber terminado cada programa, analiza los datos para ver dnde has introducido y eliminado los defectos y qu tipos de defectos causan los principales problemas. Antes de utilizar este cuaderno, lee el resto de ese captulo y las instrucciones de la Tabla 12.3. Los siguientes prrafos utilizan el ejemplo del Cuaderno de Registro de Defectos de la Tabla 12.4 para mostrar como completar el cuaderno:
1. Cuando comiences a desarrollar un programa, coge varias pginas del Cuaderno de Registro de Defectos y rellena los datos de la cabecera de la primera pgina. Despus de utilizar todos los espacios en la primera pgina, completa la cabecera antes de comenzar la segunda pgina. 2. Cuando encuentres un defecto por primera vez, anota su nmero en el cuaderno, pero no introduzcas el resto de datos hasta que hayas corregido el defecto. Cuando el Estudiante X intent compilar el programa 10, el compilador mostr ms de una docena de mensajes de error. Aunque al principio no saba qu problema tena, al menos saba que era un error. Anot la fecha y puso un 1 en la casilla Nmero de la primera lnea del cuaderno de defectos. Esto fue para el primer defecto del programa 1 O. Estos nmeros te ayudarn posteriormente a analizar los datos de los defectos. En programas ms grandes, los nmeros de defecto se utilizan para controlar los problemas con correcciones incorrectas y ayudar a la prevencin de defectos.
3. Utiliza una lnea separada para cada defecto. No agrupes mltiples defectos idnticos en la misma lnea.
4. Escribe la fecha de localizacin del defecto. Si encuentras varios
defectos el mismo da, es aceptable dejar las siguientes casillas de la fecha en blanco, hasta la primera anotacin del da siguiente. En la Tabla 12.4, el Estudiante X encontr todos los defectos el da 28 de octubre, por lo que no necesit volver a anotar la fecha, pues supuso que se repeta hasta que no la cambiase.
149
Tipos de defectos 10 Documentacin 20 Sintaxis 30 Construccin Paquetes 40 Asignacin
50 60 70 80
lnterfaz Comprobacin Datos Funcin
90 Sistema 1O0 Entorno
Tabla 12.2 Cuaderno de registro de defectos.

Estudiante Profesor Fecha Fecha Programa # ___ Tiempo de Defecto correccin corregido
Nmero
Tipo
Introducido
Eliminado
Descripcin: Fecha
nnnnnan
Nmero Tipo Introducido Eliminado Tiempo de correccin Defecto corregido
Descripcin : Fecha
nnnnnun
Descripcin: Fecha
I
Nmero
I
Tipo
Introducido
Eliminado
Descripcin: Fecha
nnunun
Tiempo de correccin
Defecto corregido
Descripcin: Fecha
nnnnnnn
Descripcin: Fecha
nunnnnu
Descripcin: Fecha
nnnnnnn
Descripcin:
nnuunnn
150
DEFECTOS
Tabla 12.3 Instrucciones para el cuaderno de registro de defectos.

Propsito Utiliza esta tabla para mantener los datos de cada defecto que encuentres y corrijas. Utiliza estos datos para completar el Resumen del Plan del Proyecto. Anota todas las revisiones, compilaciones y pruebas de defectos en este cuaderno. Anota cada defecto de forma separada y completa. Si necesitas espacio adicional, utiliza otra copia de la tabla.
Mtodo
Cabecera
Introduce los siguientes datos: Tu nombre. Fecha actual. Nombre del profesor. Nmero de programa.
Fecha Nmero
Anota la fecha en la que se encontr el defecto.

_ _ _ ~
Nmero de cada defecto. Para cada programa, utiliza una numeracin secuencia, comenzando por el 1 (o 001, etc.). Anota el tipo de defecto, segn la lista de tipos de defectos de la Tabla 12.1 (tambin resumida en la parte superior izquierda del cuaderno de defectos). Utiliza tu criterio para seleccionar que tipo aplicar. Anota la fase en la que se introdujo el defecto. Utiliza tu criterio. Anota la fecha en la que se elimin el defecto. Generalmente, sta sera la fase durante la cual encontraste y corregiste el defecto. Estima o mide el tiempo necesario para encontrar y corregir el defecto. Puedes utilizar un cronmetro si lo deseas. Puedes ignorar esta casilla la primera vez. Si introduces este defecto mientras ests arreglando otro, anota el nmero del defecto incorrectamente corregido. Si no puedes identificar el nmero de defecto, anota una X en la casilla de Defecto corregido. Escribe una breve descripcin del defecto. Haz la descripcin lo suficientemente clara para que recuerdes posteriormente, el error que caus el defecto y por qu lo hiciste.
Tipo
Introducido Eliminado
Tiempo de correccin Defecto corregido
Descripcin
5. Despus de corregir el defecto, anota el tipo de defecto. Aunque puedas confundirte sobre qu tipo es el adecuado, utiliza tu mejor criterio. No dediques mucho tiempo preocupndote sobre qu tipo de defecto es el ms preciso. Sin embargo, intenta ser razonablemente coherente. Sobre el defecto 1 en la Tabla 12.4, por ejemplo, el Estudiante X encontr que el problema era un punto
151
Tipos de defectos 1O Documentacin 20 Sintaxis 30 Construccin Paquetes 40 Asignacin
50 lnteraz 60 Comprobacin 70 Datos 80 Funcin
90 Sistema 100 Entorno
Tabla 12.4 Ejemplo del cuaderno de registro de defectos.

Estudiante Profesor Fecha
Estudiante X
sr. Z
Nmero Tipo Introducido Eliminado
[ 8 1 1 T] 210
Descripcin: omitido:
raGq
Tipo
-
Fecha 20/10/96 Programa # 1 0 Tiempo de Defecto correccin corregido
pG@q 1 -
Fecha
Nmero
Introducido
-
Eliminado
-
[ Descripcin: omitido:
Tiempo de correccin j
Defecto corregido ~
Fecha
Nmero
Tipo
Introducido
Eliminado
1-1
1 1 3TI
i-xzxq 1 Introducido Eliminado
Tiempo de correccin IIminj
Defecto corregido
7 1
Defecto corregido
Descripcin: defecto en la parte derecha del operador binario, debe t r a t a r s e ei entero como float Fecha Nmero Tipo Tiempo de correccin
~
Fecha Nmero
~
Tipo
m
Descripcin: error en la parte derecha, la constante debera ser 0.0 v no O Tiempo de correccin Defecto corregido
1 1 15
Fecha Nmero Tipo
rzmzzq
7
Defecto corregido
Descripcin: error en la parte derecha, tenas que t r a t a r el entero como f l o a t Tiempo de correccin
6
Nmero
r~ m i ~compilac.1
Tipo Introducido Eliminado
1
I
7
.
m
Defecto corregido
Descripcin: el exponent e debe ser un entero. investigu v utilic la lib reria matematica para sart. '
la intearal no se clculo correctamentn
Fecha
1 1 TI 7
Fecha Nmero Tipo
1codificac.l
r
Eliminado
Tiempo de correccin
1m 1
Descripcin: respuesta std. dev = desviacin estndar) incorrecta-la ecuacin no se proeram

adecuadamente, rest cuando tena Que haber dividido
Introducido
l a l
sustraccin
r n
Icodificac.1-
Tiempo de correccin
Defecto corregido
Descripcin: el bucle no termin con un exponente neaativo. olvid camb iar el siano en la
152
DEFECTOS
y coma olvidado. Una vez resuelto el problema, anot el nmero 20 para el defecto 1 en la casilla de Tipo.
6. Anota la fase del proceso en la que introdujiste el defecto. Aunque esto pueda no estar siempre claro, no debera ser un problema para programas pequeos. Utiliza tu mejor criterio y no te preocupes mucho tiempo de este tema. En el ejemplo, el Estudiante X estaba convencido de que haba cometido el error del punto y coma cuando estaba codificando el programa, por eso puso la palabra codi$car en la casilla de Introducido.
7 Anota la fase del proceso cuando hayas eliminado el defecto. Esta .

es normalmente la fase en la que encuentras el defecto. Despus de iniciar la fase de compilacin, por ejemplo, anota la palabra compilar para la fase de eliminacin. Aqu, para el defecto 1, el Estudiante X estaba en la fase de compilacin cuando encontr y corrigi el defecto, por eso anot la palabra compilar en la casilla de Eliminado.
8. Para el tiempo de correccin del defecto, estima el tiempo en que te diste cuenta y comenzaste a trabajar sobre el defecto hasta que lo acabaste de corregir y chequear. Cuando comenz a corregir el defecto 1, el Estudiante X anot la hora de su reloj. Una vez que haba arreglado el problema y comprobado para asegurarse de que estaba correctamente corregido, de nuevo comprob su reloj y vio que solamente le haba dedicado un minuto. Generalmente, para defectos de compilacin, el tiempo de correccin ser solamente de un minuto aproximadamente. Para los defectos encontrados en las pruebas, sin embargo, la correccin puede llevar mucho ms tiempo. Podras utilizar un reloj o un cronmetro para medir el tiempo de correccin, pero para correcciones pequeas, tu criterio ser adecuado. 9. La casilla de Defectos Corregidos es para los defectos introducidos mientras corriges otros defectos. Aunque esto ser importante ms adelante, ignralo por ahora. 10. Escribe una breve descripcin del defecto en la seccin de descripcin. Haz esto tan breve y sencillo como sea posible, pero describe el defecto claramente. Por ejemplo, simplemente anota un ; para designar un punto y coma omitido. Para un defecto lgico ms sofisticado, escribe varias lneas, escribe en las siguientes lneas del cuaderno de defectos si es necesario. Para el defecto 1, el Estudiante X simplemente anot omitido ;. Para muchos de los defectos de la Tabla 12.4, tuvo que poner una descripcin ms detallada. Puesto que estas descripciones son nicamente para tu uso, no es necesario escribir ms de lo preciso para que puedas recordar el problema.
153
A menudo, las personas se confunden sobre los tipos de defectos y piensan que deberan tener un tipo especial para interpretaciones errneas y confusiones. Por ejemplo, si no entendiste los requisitos o no estabas familiarizado con el entorno de desarrollo, probablemente cometiste muchos errores. Esta cuestin es importante, pero est relacionada con las cuusus del defecto. Por lo que al tipo de defecto se refiere, hay solamente dos cuestiones. Haba algo errneo en el producto? y si es as, cul era el tipo de defecto del producto? As, aunque entender la causa es necesario para prevenir los defectos, el tipo de defecto solamente describe lo que estaba incorrecto en el producto.
12.8
LA CONTABILIZACIN DE LOS DEFECTOS

Aunque la definicin de un defecto puede parecer obvia, no lo es. Durante la compilacin, por ejemplo, cuenta solamente los cambios que haces. Es decir, si el compilador presenta 10 mensajes de error por una omisin del punto y coma, la omisin del punto y coma es un nico defecto. As, anota un defecto en el Cuaderno de Registro de Defectos para cada correccin del programa, sin tener en cuenta la naturaleza de la correccin y el nmero de mensajes de error del compilador. De forma similar, cuando encuentres un defecto de diseo mientras ests codificando, se considerar un defecto de diseo. Mientras diseas, sin embargo, con frecuencia puedes cambiar tu idea de cmo hacer algo. Si ests corrigiendo un error en los requisitos o en las especificaciones, eso sera un defecto de requisitos o de especificacin. Si, por el contrario, has pensado una forma mejor de hacer el diseo, no sera un defecto. A menudo, advertirs y corregirs errores conforme los vas cometiendo. Dichos ajustes son las cosas ms naturales de un pensamiento creativo y no son defectos. La clave est en registrar aquellos defectos que has dejado en el producto cuando hayas acabado el diseo inicial o terminado la codificacin. Por ejemplo, si escribes una lnea de cdigo e inmediatamente ves un error en el nombre del parmetro y lo corriges, este error no es un defecto. Si, por el contrario, acabas de codificar el programa y posteriormente observas el error, entonces s sera un defecto y lo contabilizaras. As, si normalmente compruebas la correccin de cada lnea despus de introducirla, los defectos que encuentres de esta forma no es necesario contabilizarlos. Comienza a contabilizar los defectos cuando termines una fase de un producto o parte del mismo. Despus de la fase de diseo, por ejemplo, contaras todos los defectos de diseo. Supongamos, sin embargo, que ests codificando dos procedimientos de un programa. Despus de codificar
154
DEFECTOS
el primero, decides codificar el segundo, antes de comenzar la compilacin del primero. A mitad de codificar el segundo procedimiento, te das cuenta de que has dado un nombre equivocado a un parmetro en el primer procedimiento. Esto es un defecto, porque aunque ests en la fase de codificacin, en ese momento habas terminado la codificacin del primer procedimiento. Observa que en este libro no se te exige contabilizar los defectos encontrados durante las fases de diseo y codificacin. Inicialmente, es importante concentrarte sobre aquellos defectos encontrados durante la compilacin y pruebas. Una vez que ests acostumbrado a reunir datos de defectos, sabrs mejor por qu son necesarios dichos datos. Entonces puedes querer aprender ms sobre los errores que cometes y corriges durante las fases de codificacin y diseo. Puesto que probablemente cometers muchos errores mientras diseas y codificas, estas son las fases donde debes tratar de entender las causas de los defectos y ver cmo prevenirlos. Por el momento, sin embargo, comienza con aquellos defectos que encuentres en la compilacin y en las pruebas.
12.9
LA UTILIZACIN DEL CUADERNO DE REGISTRO DE DEFECTOS

Por qu deberas contar los defectos? Conforme renas datos de defectos, recuerda por qu lo ests haciendo:
Para mejorar tu programacin. Estos datos de los defectos te ayudan a mejorar la forma que tienes de escribir programas. Aunque es fcil defenderte frente a los defectos, no puedes gestionar los defectos si no los entiendes. Esto significa que debes reunir datos exactos sobre ellos. Si pones excusas o pretendes, por ejemplo, que los errores sintcticos no se cuenten si son detectados por un corrector sintctico en vez de por un compilador, te engaars a ti mismo. Si ests deseando engaarte a ti mismo, no esperes mejorar. Para reducir el nmero de dejectos en tus programas. Todos introducen defectos pero, utilizando mtodos cuidadosos y adecuados, puedes reducir el nmero de defectos introducidos. Para ahorrar tiempo. Los errores causan ms errores. Los grandes defectos permanecen en un programa, debido al tiempo que dedicas a encontrarlos y lo difcil que es corregirlos. Los problemas de requisitos conducen a diseos inadecuados. Los errores de diseo causan errores de implementacin. Los errores de implementacin introducen defectos en los programas. Por ello, es importante eliminar los defectos lo antes posible despus de introducirlos.
155
Paru ahorrar dinero. Los defectos son caros. Despus de una prueba, los costes de encontrar y corregir los defectos aumentan en un factor de 10 para cada subsiguiente fase de pruebas o de mantenimiento. Paru hacer tu trabajo de una forma responsable. Los defectos son introducidos por los ingenieros y es su responsabilidad encontrarlos y corregirlos.
12.10
EL PROCESO DEL PSP ACTUALIZADO

La gua del proceso del PSP actualizada se muestra en la Tabla 12.5. El aadido principal es la reunin y registro de datos de defectos. La tabla del Resumen del Plan del Proyecto se muestra en la Tabla 12.6 y sus instrucciones estn en la Tabla 12.7. Observa que no hay espacio para registrar los defectos introducidos durante la fase postmortem. Aunque no es probable que encuentres o introduzcas defectos durante el anlisis postmortem, es posible. Un ejemplo podra ser que observases un defecto mientras contabilizas las LOC Nuevas & Cambiadas. Puedes introducir un defecto durante la fase postmortem si cometes un error mientras corriges el primer defecto. Los prrafos siguientes explican cmo se completan las partes nuevas del Resumen del Plan del Proyecto de la Tabla 12.8. Durante la fase postmortem, revisa el Cuaderno de Registro de Defectos y contabiliza el nmero de defectos introducidos en cada fase. En el Cuaderno de Registro de Defectos de la Tabla 12.4, el Estudiante X, en primer lugar contabiliz los defectos 3 y 6 como introducidos durante la fase de diseo, por lo que anot un 2 en la casilla Real de la fila de Diseo en la Tabla 12.8. Los otros 6 defectos fueron todos introducidos durante la codificacin, por ello anot un 6 en la fila de codificacin. Resultando un total de 8 defectos. Aunque introdujeras la mayor parte de los defectos en la fase de codificacin, puedes introducir unos pocos en las fases de diseo, compilacin o pruebas. Ocasionalmente, con programas ms complejos, puedes introducir algn defecto durante la fase de planificacin.
A continuacin, contabiliza los defectos eliminados en cada fase. El Estudiante X contabiliz 6 defectos eliminados en la fase de compilacin y dos en la de pruebas, por lo que anot un 6 y un 2 en las dos filas de la seccin de eliminados. De nuevo, obtendremos un total de 8. Con el PSP, probablemente comenzars encontrando la mayor parte de los defectos durante la fase de compilacin. Las pruebas, sin embargo, necesitan ms tiempo, puesto que es ms difcil encontrar y corregir defectos en dicha fase.
Despus de anotar el nmero de defectos introducidos y eliminados, completa las columnas de Hasta la Fecha y % Hasta la Fecha de la misma forma que rellenaste las mismas columnas con los datos de tiempos (vase la Seccin 11.7 del Captulo 11). No necesitars los datos de defectos
156
DEFECTOS

Propsito Criterios de entrada Guiarte en el desarrollo de pequeos programas. La descripcin del problema. Tabla Resumen del Plan del Proyecto del PSP. Datos de tamaos y tiempos reales para programas anteriores. Cuaderno de Registro de Tiempos. Cuaderno de Registro de Defectos.
~ ~
~~~
Planificacin
Obtn una descripcin de las funciones del programa. Estima las LOC Mx., Mn. y total requeridas. Determina los Minutos/LOC. Calcula los tiempos de desarrollo Mx., Mn., y total. Anota los datos del plan en la tabla Resumen del Plan del Proyecto. Anota el tiempo de planificacin en el Cuaderno de Registro de Tiempos. Disea el programa. Anota el diseo en el formato especificado. Anota el tiempo de diseo en el Cuaderno de Registro de Tiempos. lmplementa el diseo. Utiliza un formato estndar para introducir el cdigo. Anota el tiempo de codificacin en el Cuaderno de Registro de Tiempos. Compila el programa. Corrige y anota todos los defectos encontrados. Anota el tiempo de compilacin en el Cuaderno de Registro de Tiempos. Prueba el programa. Corrige y anota todos los defectos encontrados. Anota el tiempo de pruebas en el Cuaderno de Registro de Tiempos. Completa la tabla de Resumen del Plan del Proyecto con los datos de tiempo, tamao y defectos reales. Anota el tiempo postmortem en el Cuaderno de Registro de Tiempos. Programa probado a fondo. Diseo adecuadamente documentado. Listado completo del programa. Resumen del Plan del Proyecto completado. Cuadernos de Tiempos y defectos completados.
Diseo
Codificacin
Compilacin
Pruebas
Postmortem
Criterios de salida
Hasta la Fecha y % Hasta la Fecha hasta el Captulo 15, que ser cuando comenzars a estimar el nmero de defectos introducidos y eliminados. Con los datos del % Hasta la Fecha, es sorprendente la precisin con que los ingenieros pueden estimar el nmero de defectos que introducen y eliminan. Las personas son animales de costumbres y nuestras costum-
157

Estudiante Programa Profesor Resumen MinutoslLOC LOClHora DefectosKLoc Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas rota1 Plan Real Fecha Programa # Lenguaje Hasta la Fecha
Plan
Real
Hasta la Fecha
% Hasta la Fecha
Plan
Real
DefJHora
Plan
Real
Def.lHora
bres gobiernan nuestros errores. Mientras no cambiemos estos hbitos, continuaremos cometiendo errores similares. As, a no ser que hagas un gran cambio, tal como utilizar un proceso diferente, trabajar en aplicaciones ms complejas o modificar el entorno de desarrollo, probablemente introducirs aproximadamente el mismo nmero de defectos en el prximo programa de la misma forma que lo hiciste la ltima vez. El resto del Resumen del Plan del Proyecto se completa de la misma forma como hemos visto anteriormente. Hay, sin embargo, unas pocas
158
DEFECTOS
Propsito Cabecera Esta tabla trata los datos estimados y reales de los proyectos de una forma cmoda y fcilmente recuperable. ~ _ _ Introduce los siguientes datos: Tu nombre y fecha de hoy. Nombre y nmero de programa. Nombre del profesor. El lenguaje que utilizars para escribir el programa. Antes de iniciar el desarrollo. Escribe los Minutos/LOC planificados para este proyecto. Utiliza la velocidad Hasta la Fecha de un programa reciente del Cuaderno de Trabajos o del Resumen del Plan del Proyecto. Despus del desarrollo: Divide el tiempo total de desarrollo por el tamao real del programa para obtener los MinutoslLOC reales y los Minutos/LOC Hasta la Fecha. Por ejemplo, si el proyecto se hizo en 196 minutos e hiciste 29 LOC, los Minutos/LOC seran 196/29 = 6,76. Antes de iniciar el desarrollo: Calcula las LOC por hora planificada para este programa dividiendo 60 por los Minutos/LOC de la casilla de Plan. Despus del desarrollo: Para LOC/Hora Real y Hasta la Fecha divide 60 por Minutos/LOC Reales y Hasta la Fecha. Para los 6,76 Minutos/LOC Reales, tenemos 60/6,76 = 8,88 LOClHora Reales.
~~
MinutosLOC
LOC/Hora
Tamao Programa Antes de iniciar el desarrollo: (LOC) Escribe bajo la columna plan, el valor estimado de Total Nuevas & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y escribe las LOC Nuevas & Cambiadas Reales. Para la columna Hasta la Fecha, aade LOC reales Nuevas & Cambiadas a las LOC Hasta la Fecha Nuevas & Cambiadas de programas anteriores. Tiempo por fase Plan
Para el tiempo total de desarrollo, multiplica el valor de las LOC Total Nuevas & Cambiadas por Minutos/LOC. Para el tiempo Mximo, multiplica el tamao Mximo por los Minutos/LOC. Para el tiempo Mnimo, multiplica el tamao Mnimo por los MinutodLOC. Del Resumen del Plan del Proyecto de un programa reciente, busca los valores de % Hasta la Fecha para cada fase. Utilizando el Hasta la Fecha de programas anteriores calcula el tiempo planificado para cada fase. Una vez acabado el trabajo, anota el tiempo real en minutos que has gastado en cada fase del desarrollo. Obtn estos datos del Cuaderno de Tiempos.
( Contina)
Real
159
Tabla 12.7 Instrucciones del resumen del plan del proyecto del PSP. (Continuacin)
Hasta la Fecha Para cada fase, escribe la suma del tiempo real y el tiempo Hasta la Fecha de los programas ms recientes.
Hasta la Fecha Para cada fase, escribe 1O0 multiplicado por el tiempo Hasta la Fecha y lo divides por el total del tiempo Hasta la Fecha. Defectos reales introducidos Hasta la Fecha Despus del desarrollo, localiza y anota el nmero real de defectos introducidos en cada fase. Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes.
~
% Hasta la Fecha Para cada fase, multiplica por 100 los Defectos Hasta la
Fecha para esa fase y divdelos por el total de defectos Hasta la Fecha.
~~
Defectos reales eliminados Hasta la Fecha
Despus del desarrollo, localiza y anota el nmero real de defectos eliminados en cada fase. Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes. Fecha para esa fase y divdelos por el total de defectos Hasta la Fecha.
% Hasta la Fecha Para cada fase, multiplica por 100 los Defectos Hasta la
consideraciones a tener en cuenta: primero, el dato Hasta la Fecha en Minutos/LOC se obtiene del cociente entre el tiempo total de desarrollo Hasta la Fecha y las LOC Nuevas & Cambiadas Hasta la Fecha; tenemos, 682/105=6,50 Minutos/LOC. Segundo, las LOC/Hora se calculan dividiendo 60 por los Minutos/LOC hasta la Fecha, tenemos 60/6,50=9,23 LOC/Hora. Observa que con estas velocidades de Hasta la Fecha, no necesitas controlar las Unidades y Medias del Cuaderno de Trabajos de los programas desarrollados. Este cuaderno es una referencia muy adecuada para la informacin del proyecto, sin embargo, te sugiero que contines revisando los Cuadernos de Trabajo del programa. Si tus experiencias son como las mas, rpidamente acumulars una gran cantidad de datos. Yo he controlado hasta ahora unos 200 trabajos, y he almacenado mis datos de proyectos por nmero de trabajo. As, encuentro que el Cuaderno de Trabajos es la forma ms adecuada para identificar datos histricos o encontrar datos de un proyecto particular.
RESUMEN
La calidad del software consiste en satisfacer las necesidades de los usuarios haciendo el trabajo de los mismos de una forma fiable y consistente. Esto requiere que el software que hagas tenga pocos defectos.
160
DEFECTOS
Tabla 12.8 Ejemplo del resumen del plan del proyecto del PSP.
Estudiante
Programa
Estudiante X- -
Fecha
28/10/96
1 0
Ada
Programa#
Sr. Z
Profesor
Lenguaje
Resumen MinutosiLOC LOClHora Defectos/KLoc Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
Plan
Real
6,76 8,88
6,12 9 8 , 0
Hasta la Fecha 6,50 9,23
4 4 58
3 0
57
15 0
Plan
Real
1 0
1 3 11 10 3
Hasta la Fecha 33
% Hasta la Fecha
43 12 6 2 1 73 32 39 4
55
30 0
4,8 81 . 452
Plan
4 4 82 1 7 297 392 203 Actual
70 15 6 5 1 682
10,2 24,2 7,5

100,o
Def.lHora
2 6
2 6
25,O 75,O
8
Plan Actual
100,o
Def.lHora
6 2
0
6 2
0
75,O 25,O
100,o
Un defecto del software es algo en el producto que est incorrecto. Los defectos son causados por errores humanos. Puesto que los defectos son costosos de encontrar y corregir, es muy eficiente que los ingenieros encuentren y corrijan inmediatamente los defectos introducidos. El primer paso en la gestin de defectos es entenderlos. Para esto, el programador necesita reunir datos de defectos, analizar estos datos y determinar la mejor forma de prevenir, localizar y corregir dichos defectos.
161
El Estndar de Tipos de Defectos es un estndar simplificado utilizado en este libro para ayudarte a identificar tus categoras de defectos ms importantes. Despus de que tengas algunos datos de defectos, puedes desear extender estas categoras. Utiliza el Cuaderno de Defectos para reunir los datos de los defectos. Registra cada defecto utilizando una casilla del cuaderno para cada defecto. Para cada programa, resume estos datos en la tabla del Plan del Proyecto.
EJERCICIO 12
Utiliza el Cuaderno de Registro de Defectos para registrar cada defecto que encuentres en los programas que escribas. Identifica el programa donde encontraste los defectos, anota cada defecto como un registro separado y describe detalladamente cada defecto. Resume los datos de defectos en el Resumen del Plan del Proyecto para cada programa. Tambin, entrega una copia del Cuaderno de Tiempos, del Cuaderno de Trabajos y del Resumen Semanal de Actividades que no hayas entregado todava, y entrega una planificacin y un Cuaderno de Registro de Defectos para cada nuevo programa que desarrolles.
REFERENCIAS
[Chillarege] Chillarege, Ram, Inderpal S. Bhandari, Jarir K. Chaar, Michael J. Halliday, Diane S. Moebus, Bonnie K. Ray, and Man-Yuen Wong. Orthogonal Defect Classification-A Concept for In-Process Measurements. IEEE Transactions on Software Engineering, vol., 18, no. 1 1, Nov 1992, pp. 943-956. [Humphrey 891 Humphrey, W.S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. [Humphrey 951 Humphrey, W.S. A Discipline for Software Engineering. Reading, MA: Addison-Wesley, 1995.
CAPITULO 13
Encontrar defectos
Hay varias formas de encontrar defectos. Este captulo resume brevemente las principales alternativas y muestra cmo un mtodo particular, la revisin de cdigo, puede ayudar a mejorar la productividad y calidad de tu trabajo. En el ejercicio, hars revisiones de cdigo para los siguientes programas que escribas.
13.1
UN COMPROMISO PERSONAL CON LA CALIDAD

A pesar de todas las herramientas y mtodos disponibles, el factor ms importante en la calidad de un programa es el compromiso personal del ingeniero del software a desarrollar un producto de calidad. Cuando los ingenieros se comprometen con la calidad, tienen ms cuidado con su trabajo y se enorgullecen de la calidad de los productos que hacen. El PSP puede ayudarte a hacer productos de calidad, mostrndote cmo utilizar mtodos efectivos de calidad. El primer paso, es entender los defectos que has introducido en programas anteriores. Entonces, utilizando los mtodos del PSP, aprender rpidamente a encontrar y corregir los defectos. Este y los siguientes captulos describen cmo hacerlo.
13.2
LOS PASOS PARA ENCONTRAR DEFECTOS

Aunque no hay forma de acabar con la introduccin de defectos, es posible encontrar y eliminar casi todos los defectos al principio del desarro-
164
ENCONTRAR DEFECTOS
110. Despus de que hayas aprendido el PSP, encontrars que eliminar los defectos al principio, te ahorrar tiempo y hars mejores productos. Por ejemplo, si pudieras encontrar y corregir un defecto de diseo antes de hacer el cdigo, no gastaras tiempo implementando un diseo incorrecto. De forma similar, cuando corriges defectos de codificacin antes de compilar y hacer las pruebas, ahorras tiempo que tendras que dedicar a encontrar y corregir estos defectos durante la fase de compilacin y pruebas. Este captulo muestra cmo encontrar los defectos y proporciona datos que puedes utilizar para evaluar la efectividad de estos mtodos de eliminacin de defectos. Hay varias formas de encontrar los defectos en un programa. En esencia, todos estos mtodos implican los siguientes pasos:
1. Identificar los sntomas del defecto.
2 Deducir de estos sntomas la localizacin del defecto. . 3. Entender lo que es errneo en el programa.
4. Decidir cmo corregir el defecto. 5. Hacer la correccin.
6. Verificar que el arreglo ha resuelto el problema.
13.3
FORMAS DE ENCONTRAR Y CORREGIR DEFECTOS

Se han inventado varias herramientas y ayudas para ayudar a los ingenieros en estos pasos. La primera herramienta que los ingenieros normalmente utilizan es un compilador. Para entender cmo y por qu un compilador ayuda a encontrar los defectos, es importante discutir su propsito. Fundamentalmente, el trabajo del compilador es generar cdigo. As, un compilador explorar todo el cdigo fuente para ver si puede generar cdigo. Si puede, lo har, tanto si el cdigo es correcto como si no. As, el compilador generar cdigo hasta que encuentre algunos caracteres que no pueda interpretar. Por ejemplo, si pones la cadena de caracteres ABC en un programa fuente y no la habas declarado, el compilador marcar esta cadena como un error. Los compiladores pueden identificar muchos defectos sintcticos, pero no te pueden decir lo que pretendes. As, los compiladores, a menudo, proporcionan muchos mensajes de error para defectos aparentemente sencillos. Los compiladores, sin embargo, solamente proporcionan sntomas de defectos y debes entender dnde y cul es el problema. Aunque normalmente hars esto rpidamente, en ocasiones puedes necesitar mucha dedicacin. Los compiladores no detectarn cada error tipogrfico, de puntuacin u otro defecto sintctico. La razn es porque los compiladores, a menudo,
165
pueden generar cdigo de programas fuente defectuosos. Aunque muchos de estos defectos que pasan inadvertidos provienen de diseos inadecuados, algunos podran ser simples errores sintcticos. Puede parecer improbable que un compilador pudiese pasar por alto errores sintcticos, pero mis datos de varios miles de defectos de C++ muestran que esto sucedi en el 9,4% de los errores sintcticos que comet. As como un corrector ortogrfico no puede detectar todos los errores ortogrficos, el compilador no detectar todos los defectos sintcticos. Una segunda forma de encontrar defectos, es por medio de las pruebas. Aunque hay muchas clases de pruebas, todas requieren que los examinadores proporcionen datos de prueba y condiciones de prueba (algunas veces llamadas casos de prueba o escenarios de prueba). La calidad de las pruebas est gobernada por el grado en que estos escenarios cubren todas las funciones importantes del programa. El examinador, entonces, ejecuta estos casos de prueba para ver si el programa proporciona los resultados adecuados. Esto implica otra responsabilidad del examinador: comprender que los resultados de estas pruebas deberan parecerse si el programa trabajase correctamente. Aunque las pruebas pueden utilizarse para comprobar casi cualquier funcin del programa, tienen varias desventajas. Primero, como con los compiladores, las pruebas solo suponen el primer paso de correccin de defectos. Es decir, an tienes que moverte desde los sntomas a los problemas antes de comenzar a trabajar en la correccin. Otro problema, es que cada prueba verifica solamente un conjunto de condiciones del programa. Es decir, si el programa multiplica dos nmeros, x e y, y lo pruebas con x=l 1 e y=18, sabras solamente que funciona para esos valores. No sabras, por ejemplo, cmo trabaja el programa con nmeros negativos, o con el cero, o con nmeros positivos o negativos muy grandes en el sistema numrico, o con cualquier otro par de nmeros. Para comprobar todas estas posibilidades tendras que hacer muchas pruebas. Puesto que cada programa sencillo implica muchas combinaciones posibles de datos y condiciones operativas, unas pruebas globales consumen tiempo. En efecto, para cualquier programa sencillo, una prueba global es prcticamente imposible. La tercera forma de encontrar los defectos, es la ms comn de todas. Consiste en entregar programas defectuosos y esperar que los usuarios identifiquen e informen de los defectos. Esta es la estrategia ms costosa. Por ejemplo, durante un ao, IBM gast unos 250 millones de dlares en reparar y reinstalar correcciones de los 13.000 defectos detectados por los clientes. Esto supone unos 20.000 dlares por defecto. Por ltimo, indicar que la forma ms efectiva de encontrar y corregir defectos es revisar personalmente el cdigo fuente del programa. Aunque esto puede parecer una forma difcil de limpiar un programa de-
166
ENCONTRAR DEFECTOS
fectuoso, se trata de la forma ms rpida y eficiente. Este captulo explica el porqu.
13.4
LA REVISIN DEL CDIGO

Una revisin de cdigo es una forma de encontrar defectos rpidamente. Para hacer una revisin de cdigo, estudias el cdigo fuente para encontrar los errores. Esto es mejor hacerlo despus de escribir el cdigo fuente y antes de comenzar a compilarlo o probarlo. miesto que muchos defectos software provienen de simples descuidos y bobadas, son fciles de encontrar despus de hacer el diseo o el cdigo. Es cuando ms probablemente, recordars cul era tu intencin y sabrs cmo corregir cualquier problema. Aunque hay muchas formas de hacer una revisin de cdigo, la aproximacin ms comn es imprimir un listado con el cdigo fuente y revisarlo lnea por lnea. Podras revisar el cdigo en la pantalla del ordenador, pero normalmente, los ingenieros realizan ms cmoda la revisin, incluso de los programas pequeos, cuando los tienen en un listado impreso. Los listados tambin nos permiten movernos rpidamente entre los segmentos de cdigo, tomar notas, o examinar secciones completas. Aunque la revisin de cdigo consume tiempo, es mucho ms eficiente que las pruebas. Los datos de los estudiantes e ingenieros muestran que, la revisin de cdigo es entre 3 y 5 veces ms eficiente que ejecutar las pruebas de unidad. Un ingeniero, por ejemplo, encontrar solamente entre 2 a 4 defectos en una hora de pruebas, pero encontrar de 6 a 10 defectos en cada hora de revisin de cdigo. La causa de que la revisin de cdigo sea tan eficiente, es porque cuando haces revisiones, ves los problemas no los sntomas. Es decir, mientras revisas el cdigo, piensas sobre lo que el programa debe hacer. As cuando algo no lo ves correcto, puedes ver el posible problema y rpidamente verificar el cdigo. Puesto que el tiempo transcurrido desde que se detecta el sntoma hasta que se llega al problema, es la mayor parte del coste de encontrar y corregir los defectos durante la compilacin y pruebas, las revisiones pueden ahorrar mucho tiempo. Las revisiones tambin tienen desventajas. Las dos desventajas principales son que las revisiones de cdigo consumen tiempo y es difcil hacerlas correctamente. La revisin, sin embargo, es una habilidad que se puede ensear y mejorar con la prctica. Con la experiencia, sin embargo, probablemente encontrars solamente una media del 75% al 80% de los defectos en un programa. Necesitars al menos 30 minutos para revisar minuciosamente cada 100 LOC del cdigo fuente. Cuando hagas revisiones mucho ms rpido, normalmente encontrars menos defectos. El resto de este captulo describe el proceso de revisin de cdigo. Los si-
167
guientes captulos discuten las medidas y las tcnicas que te ayudarn a mejorar la forma de hacer las revisiones de cdigo y te proporcionan datos para demostrar su efectividad.
13.5
POR QU HAY QUE ENCONTRAR PRONTO LOS DEFECTOS?

Hay muchas razones para revisar los programas antes de compilarlos y probarlos. La razn ms importante es que no puedes parchear un programa defectuoso y transformarlo posteriormente en un producto de calidad. Una vez que has hecho un programa defectuoso, siempre ser defectuoso. Puedes corregir todos los problemas que encuentres y puedes hacer que trabaje de acuerdo con las especificaciones con que lo has probado, pero seguir siendo un programa defectuoso con muchos parches. Como ejemplo, supn que ests comprando un coche nuevo. Antes de cerrar el trato, visitas dos fbricas de ensamblaje. En una planta, ves muchos coches bonitos que salen de la lnea de produccin y van a la de pruebas. Aunque salen grandes coches de la lnea de produccin, en la fase de pruebas se encuentran una media de 10 defectos por coche. Estos defectos son corregidos y los coches se envan a los comercios. En la segunda planta, los coches que salen de la lnea de produccin se parecen a los de la primera. Aqu, sin-embargo, en las pruebas solamente se encuentra un defecto por cada 10 coches. Aunque los coches de la segunda planta cuestan un poco ms, probablemente los preferirs, sin tener en cuenta cualquier otra diferencia. Sabes que en las pruebas no encontrars todos los problemas y que si en el proceso de produccin del coche ha habido muchos fallos, ese coche probablemente siempre tendr muchos fallos, independientemente de la cantidad de pruebas finales e inspecciones. Los programas no son diferentes. Cuando los ingenieros toleran un trabajo defectuoso, harn productos de poca calidad. Una actitud de estoy tan ocupado, podemos arreglarlo ms tarde, es improbable que produzca un producto de gran calidad. Para hacer software de calidad, cada paso del proceso de desarrollo de software debe ser de gran calidad. Aunque las prcticas rigurosas de calidad pueden parecer costosas, te ahorran mucho tiempo.
13.6
EL COSTE DE ENCONTRAR Y CORREGIR DEFECTOS

En los tpicos proyectos de software, el producto es dividido en muchos programas elementales o mdulos pequeos. Cada ingeniero, desarrolla
168
ENCONTRAR DEFECTOS
uno o ms de estos mdulos. Despus de disear el mdulo, implementarlo y compilarlo, los ingenieros hacen una prueba inicial o prueba de unidad. Despus de estas pruebas de unidad privadas, se combinan los mdulos en un gran componente y se hacen pruebas de integracin. Se realizan varios niveles de pruebas de componentes antes de que se combinen los componentes en productos para hacer las pruebas del producto. Finalmente, se ensamblan los productos en los sistemas para hacer las pruebas del sistema. Aunque el tipo, duracin y complejidad de las pruebas de integracin, de componentes, de producto y del sistema variar con el tamao y complejidad del sistema, se utiliza el mismo proceso general para casi todos los productos software a gran escala. El coste medio de encontrar y corregir un defecto crece unas 10 veces en cada paso del proceso de desarrollo. Aunque el tiempo de corregir los defectos vara enormemente, estos valores medios muestran, a pesar de todo, los tipos de defectos. Algunos defectos triviales de sintaxis, como un punto y coma mal colocado o errores tipogrficos en los nombres pueden pasar la fase de compilacin, siendo muy difcil encontrarlos en la fase de pruebas. En la revisin de cdigo encontrars y corregirs los defectos en una media de l a 2 minutos. En las pruebas de unidad iniciales, sin embargo, los tiempos para corregir los defectos tendrn un valor medio de entre 10 y 20 minutos o ms. Estos datos corresponden, en su mayor parte, a correcciones que necesitan entre l y 2 minutos, y existen unas pocas que necesiten varios minutos o varias horas. El tiempo de encontrar los defectos en las pruebas de integracin, de componentes o del sistema, tambin variar con el tamao y la complejidad del sistema. Muchas veces se requiere encontrar y corregir defectos en sistemas grandes y muy complejos. En las pruebas de integracin, por ejemplo, cada defecto puede costar una hora o ms, y en las pruebas del sistema cada defecto puede costar entre 10 a 40 o ms horas de ingeniero. Una vez que los productos son entregados a los clientes, el coste de encontrar y corregir los defectos puede ser mucho mayor, dependiendo de la clase de productos y de los tipos y nmero de clientes. Mis datos personales de los tiempos de encontrar y corregir los defectos en C++ se muestran en la Figura 13.1. El siguiente ejemplo 'muestra el coste de esperar hasta que las pruebas eliminen todos los defectos del programa. Una empresa pequea de software comercial desarroll un programa con varios componentes. Las pruebas de integracin realizadas por los ingenieros que estaban entrenados en el PSP duraron un par de semanas. Un componente, sin embargo, se desarroll por un grupo que no haba recibido formacin en el PSP y las pruebas de integracin se realizaron en varias semanas. El tiempo de las pruebas para encontrar y corregir los defectos fue de 300 horas. Puesto que las pruebas necesitaron mucho ms tiempo que el planificado, la entrega al cliente se hizo dos meses ms tarde.
169
120
0NombreTipo
2
4-
100
Sintaxis Asignacin interfaz Funcin
80
.* U
60
O C
8
-0 u
o a
:
c;
40
20
O R
C T U Revisin, Compilacin, Pruebas, Utilizacin
Figura 13.1 Tiempos de correccin de defectos.
El desarrollo de un sistema aeroespacial, necesit una media de 40 horas de ingeniero para encontrar y corregir cada defecto en las pruebas del sistema de un sistema de navegacin area. En Digital Equiment Corporation, para un sistema, el tiempo mnimo para encontrar y corregir cada defecto informado por el cliente fue de 88 horas de ingeniero. Adems del coste, una razn de igual importancia para encontrar los defectos al-principio, es que la compilacin, depuracin y las pruebas tienen una efectividad reducida. Los compiladores son las herramientas ms rpidas que tenemos para detectar defectos, pero solamente encuentran alrededor del 90% de los defectos de sintaxis y muy pocos defectos lgicos. La prueba de unidad es normalmente la prueba ms efectiva, pero encuentra la mitad de los defectos del programa. Despus de la prueba de unidad, la efectividad de las pruebas disminuye, con las pruebas del sistema, normalmente se encuentran entre un 30% y un 40% de los defectos del producto. As, si quieres producir un producto de alta calidad, tendrs que producir un programa sin defectos al principio o esperar dedicarle mucho tiempo en las pruebas.
13.7
EL USO DE LAS REVISIONES PARA ENCONTRAR DEFECTOS

Puedes encontrar difcil creer que controlando y comprobando tus defectos, mejorars tu trabajo, pero otros estudiantes han reducido de 5 a 10 ve-
170
ENCONTRAR DEFECTOS
ces el nmero de defectos que encuentran en la compilacin y en las pruebas. Lo consiguen, siguiendo los pasos esbozados en este y en los siguientes captulos. El trabajo de revisar el cdigo es tan adecuado que despus de utilizarlo durante este curso y ver sus buenos resultados, probablemente hars de las revisiones una parte normal de tu proceso personal. El primer paso para hacer las revisiones, es entender la clase de defectos que puedes introducir. Esta es la razn principal de reunir datos de defectos. El tipo de defectos en tu prximo programa, sern muy parecidos a los encontrados en programas anteriores. Esto ser cierto mientras contines desarrollando software de la misma forma. Por otra parte, conforme vayas adquiriendo ms habilidades y experiencia, o si cambias de proceso, el nmero y tipo de defectos cambiar. Puesto que las clases de defectos que introduces podran ser diferentes a las introducidas por otra persona, tu estrategia de revisin debera basarse en tu perfil de defectos personales. Al igual que un mecangrafo habilidoso comete pocos errores de mecanografa, un ingeniero del software experimentado cometer pocos errores de programacin. Mejorars de forma natural conforme tengas ms prctica, pero hay algn punto a partir del cual la mejora es ms difcil. Entonces, debes estudiar los defectos. Esto te ayudar a saber cmo mejorar la forma de encontrarlos y corregirlos.
Los objetivos de la revisin de cdigo son encontrar el mayor nmero de defectos lo ms pronto posible en el proceso software. T tambin quieres encontrar cada defecto en el menor tiempo posible. Un guin para hacer una revisin de cdigo se muestra en la Tabla 13.1. Aunque, este resumen es autoexplicativo, es importante que cuando revises el cdigo tengas en cuenta lo siguiente:
Hacer la revisin antes de la primera compilacin. Hacer la revisin en un listado impreso del cdigo fuente. Registrar cada defecto encontrado en el Cuaderno de Registro de Defectos. Durante la revisin, comprueba los tipos de defectos que hayas previamente encontrado en compilaciones y en pruebas. Un mtodo ordenado para hacer esto se describe en el Captulo 14.
13.8
REVISAR ANTES DE COMPILAR

Hay varias razones para revisar los programas antes de compilarlos. En esencia son:
1. Dedicars casi el mismo tiempo a hacer una revisin completa de cdigo si la haces antes o despus de la compilacin.
171
Tabla 13.2 Guin para la revisin de cdigo.

Criterios de entrada Comprueba que tienes a mano: Especificacin de requisitos. El diseo del programa. El cdigo fuente del programa. Estndares de codificacin.
Procedimiento Primero escribe el cdigo fuente del programa completo. de revisin Antes de compilar o probar el programa, imprime un listado del cdigo fuente. A continuacin, haz la revisin del cdigo. Durante la revisin del cdigo, chequea cuidadosamente cada lnea del cdigo fuente para encontrar y corregir tantos defectos como puedas. Corregir los defectos Revisar el mbito Revisar la lgica del programa Comprobar los nombres y los tipos Comprobar todas las variables Comprobar la sintaxis del programa Criterios de salida Corregir todos los defectos encontrados. Comprobar las correcciones para asegurar que son correctas. Anotar los defectos en el Cuaderno de Registro de Defectos. Verifica que el diseo del programa satisface todas las funciones descritas en la especificacin. Verifica que el cdigo fuente implementa todo el diseo. Verifica que el diseo lgico es correcto. Verifica que el programa implementa correctamente el diseo lgico.
~~
Verifica que todos los nombres y tipos son correctamente declarados y utilizados. Chequea la correcta declaracin de los tipos de dato integer, long integer y float. Asegrate que cada variable est inicializada. Chequea los problemas de desbordamiento, underflow y fuera de rango. Verifica que el cdigo fuente cumple todas las especificaciones del lenguaje. Al finalizar debes tener: El cdigo fuente terminado y corregido. El Cuaderno de Registro deTiempos completo. El Cuaderno de Registro de Defectos completo.
2. Revisar primero te ahorrar mucho tiempo de compilacin. Antes de hacer una revisin de cdigo, los ingenieros normalmente dedican entre el 12% y el 15% de su tiempo de desarrollo a la compilacin. Una vez que aprenden a hacer la revisin de cdigo, sus tiempos de compilacin caen hasta un 3% o menos.
3. Una vez que los ingenieros han compilado sus programas, normalmente sus revisiones no son tan completas.
172
ENCONTRAR DEFECTOS
4. La compilacin es igualmente efectiva antes o despus de la revisin de cdigo. 5. La experiencia indica que cuando los programas tienen muchos defectos durante la compilacin, generalmente tienen muchos defectos en las pruebas.
El argumento para revisar antes de compilar es sencillo: hazlo de esta forma y lo vers. Si, an despus de este curso, quisieras intentar compilar antes de hacer la revisin, entonces escribe unos pocos programas de cada forma y compara su rendimiento. Entonces, utiliza los mtodos descritos en los Captulos 18 y 19, evala los datos del proceso y del producto para ver qu aproximacin es ms efectiva. Un punto importante es no seguir tu intuicin o hacer lo que todo el mundo hace. Rene los datos de tu propio trabajo y toma una decisin lgica basada en estos hechos.
13.9
DATOS SOBRE DEFECTOS DE COMPILACIN Y PRUEBAS

Los ingenieros de un proyecto haban sido entrenados en el PSP. Ellos desarrollaron seis componentes de un nuevo producto y cada componente tena de 600 a 2500 LOC. En su proceso hicieron pruebas de unidad despus de codificar y compilar, y despus una prueba de desarrollo. El producto se entreg al cliente y este inform sobre los defectos, que fueron registrados como defectos de postdesarrollo. Los datos de los defectos de compilacin y pruebas para estos componentes se muestran en las Figuras 13.2, 13.3 y 13.4. Un ingeniero que
..
40
3s
.
so
I
173
30
2 2
a
Y
25
20 -
1s
'O
S'.. O' O
I
1O0
1so
200
Defectos de Compilacin
Figura 13.3 Defectos de compilacin vs. post-PSP.
O l i
SO
I O0 Defectos de Compilacin
1so
200
Figura 13.4 Defectos de compilacin vs. postdesarrollo.
se haba opuesto firmemente a hacer una revisin de cdigo, encontr cerca de 200 defectos durante la compilacin. Como se muestra en la Figura 13.2, sus pruebas tenan muchos ms defectos que la de los otros componentes. Lo que es interesante, es que, este mismo componente tambin tena ms defectos en las pruebas de integracin y en las del sistema. Aunque el cliente haba hecho solamente unas breves pruebas de aceptacin del total de componentes, el mismo componente volva a tener ms defectos. Finalmente, este componente defectuoso necesit el doble de
174
ENCONTRAR DEFECTOS
tiempo de lo planificado para desarrollarlo. Los otros componentes fueron entregados en el momento planificado o antes, mientras que aquel componente se entreg cinco semanas despus. El trabajo cuidadoso se amortiza. Cuando los ingenieros sienten personalmente la responsabilidad de la calidad de sus programas, ellos no dependern de los compiladores o de otras herramientas para encontrar sus defectos. Cuando te comprometes a hacer un producto de calidad, tu compromiso aparecer en el nmero de defectos que encuentras en la compilacin, en las pruebas y en la calidad de tus programas acabados.
13.1O
ACTUALIZACIN DE LA TABLA RESUMEN DEL PLAN DEL PROYECTO DEL PSP

El proceso del PSP se mejora ahora con la inclusin de la revisin de cdigo. Esto se hace en el guin del proceso modificado que se muestra en la Tabla 13.2. La tabla del Resumen del Plan del Proyecto se actualiza tambin, tal como se muestra en las Tablas 13.3, 13.4 y en el ejemplo resumen de la Tabla 13.5. Estas tablas son autoexplicativas, pero hay un punto que merece mencin especial. Al completar las columnas de Hasta la Fecha y % Hasta la Fecha para este proceso, recuerda que la introduccin de la revisin del cdigo cambiar tus distribuciones de tiempo y de los defectos. Cuando planifiques un nuevo programa, puedes querer ajustar el tiempo calculado estimado para contabilizar estos cambios.
13.11
OTRAS CLASES DE REVISIONES

En las organizaciones de software, una prctica comn es tener a varios ingenieros revisando programas unos a otros. Esto se llama revisiones en pareja o inspecciones. Las inspecciones bien hechas normalmente encuentran del 50 al 70% de los defectos de un programa. Aunque las inspecciones suponen mucho tiempo, pueden ser muy efectivas para encontrar defectos. La razn es que los ingenieros, a menudo, tienen dificultad en ver sus propios errores de diseo. Ellos crean el diseo y saben qu es lo que pretenden hacer. Si su idea era defectuosa o hacen un diseo errneo o una suposicin en la implementacin, a menudo, tienen dificultad en detectarlo. Las inspecciones pueden ayudar a superar este problema. Los datos de los tiempos para encontrar defectos en las inspecciones se muestran en la Tabla 13.6.
175

Propsito Criterios de entrada Guiarte en el desarrollo de pequeos programas. La descripcin del problema. Tabla Resumen del Plan del Proyecto del PSP. Datos de tamaos y tiempos reales para pequeos programas. Cuaderno de Registro de Tiempos. Cuaderno de Registro de Defectos. Obtn una descripcin de las funciones del programa. Estima las LOC Mx., Mn., total requeridas. Determina los Minutos/LOC. Calcula los tiempos de desarrollo Mx., Mn., y total. Anota los datos del plan en la tabla Resumen del Plan del Proyecto. Anota el tiempo de planificacin en el Cuaderno de Registro de Tiempos. Disea el programa. Anota el diseo en el formato especificado. Anota el tiempo de diseo en el Cuaderno de Registro de Tiempos. lmplementa el diseo. Utiliza un formato estndar para introducir el cdigo. Anota el tiempo de codificacin en el Cuaderno de Registro de Tiempos. Revisar completamente el cdigo fuente. Seguir el guin de revisin de cdigo. Corregir y registrar todos los defectos encontrados. Registrar el tiempo de revisin en el Cuaderno de Registro de Tiempos. Compila el programa. Corrige y registra todos los errores encontrados. Anota el tiempo de compilacin en el Cuaderno de Registro de Tiempos. Prueba el programa. Corrige y anota todos los errores encontrados. Anota el tiempo de pruebas en el Cuaderno de Registro de Tiempos. Completa la tabla de Resumen del Plan del Proyecto con los datos de tiempo, tamao y defectos reales. Anota el tiempo postmortem en el Cuaderno de Registro de Tiempos. Programa probado a fondo. Diseo adecuadamente documentado. Listado completo del programa. Resumen del Plan del Proyecto completo. Cuadernos de tiempos y defectos completos.
Planificacin
Diseo
Codificacin
Revisin de cdigo
Compilacin
Pruebas
Postmortem
Criterios de salida
176
ENCONTRAR DEFECTOS

Estudiante
Programa Profesor Resumen Minutos/LOC LOC/Hora Plan Real
Fecha
Programa # Lenguaje Hasta la Fecha
Defectoa/KLoc Rendimiento Vff

Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cddigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cddigo Compilacin Pruebas Total
Plan
Real
Hasta la Fecha
% Hasta la Fecha
_-
plan
Real
DefJHora
plen
Real
et.Mora
Para ejercicios muy pequeos de clase, las inspecciones generalmente no estn justificadas, pero para grandes proyectos o cualquier programa industrial, las inspecciones deberan hacerse siempre. La estrategia ptima, es hacer una revisin de cdigo personal antes de compilar, y compilar despus el programa. A continuacin, antes de cualquier prueba, haz una inspeccin. Aunque este libro no discute posteriormente las inspecciones, hay varias referencias tiles sobre este asunto [Fagan, Gilb, Hymphrey 891.
177
Propsito Cabecera Esta tabla trata los datos estimados y reales de los proyectos de una forma cmoda y fcilmente recuperable. Introduce los siguientes datos: Tu nombre y fecha de hoy. Nombre y nmero de programa. Nombre del profesor. * El lenguaje que utilizars para escribir el programa.
-MinutosiLOC
Antes de iniciar el desarrollo: Escribe los Minutos/LOC planificados para este proyecto. Utiliza la velocidad Hasta la Fecha de un programa reciente del Cuaderno de Trabajos o del Resumen del Plan del Proyecto. Despus del desarrollo: Divide el tiempo total de desarrollo por el tamao real del programa para obtener los Minutos/LOC reales y los Minutos/LOC Hasta la Fecha. Por ejemplo, si el proyecto se hizo en 196 minutos e hiciste 29 LOC, los Minutos/LOC seran 196/29= 6,76. Antes de iniciar el desarrollo: Calcula las LOC por hora planificada para este programa dividiendo 60 por los Minutos/LOC de la casilla de Plan. Despus del desarrollo: Para LOC/Hora Real y Hasta la Fecha divide 60 por Minutos/LOC Reales y Hasta la Fecha. Para los 6,76 Minutos/LOC Reales, tenemos 60/6,76 = 8,88 LOC/Hora Reales.
LOC/Hora
Tamao Programa Antes de iniciar el desarrollo: (LOC) Escribe bajo la columna plan, el valor estimado de Total Nuevas & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y anota las LOC Nuevas & Cambiadas Reales. Para la columna Hasta la Fecha, aade LOC reales Nuevas & Cambiadas a las LOC Hasta la Fecha Nuevas & Cambiadas de programas anteriores. Tiempo por fase Plan
Para el tiempo total de desarrollo, multiplica el valor de las LOC Total Nuevas & Cambiadas por Minutos/LOC. Para el tiempo Mximo, multiplica el tamao Mximo por los Minutos/LOC. Para el tiempo Mnimo, multiplica el tamao Mnimo por los Minutos/LOC. Del Resumen del Plan del Proyecto de un programa reciente, busca los valores de % Hasta la Fecha para cada fase. Utilizando el Yo Hasta la Fecha de programas anteriores calcula el tiempo planificado para cada fase. Una vez acabado el trabajo, anota el tiempo real en minutos que has gastado en cada fase del desarrollo. Obten estos datos d:~l7uaderno de Registro de Tiempos. (Contina)
Real
178
ENCONTRAR DEFECTOS
~ ~
Hasta la Fecha
Para cada fase, anota la suma del tiempo real y el tiempo Hasta la Fecha de los programas ms recientes.
lo divides por el total del tiempo Hasta la Fecha.
Yo Hasta la Fecha Para cada fase, multiplica por 1O0 el tiempo Hasta la Fecha y
Defectos Introducidos Despus del desarrollo, localiza y anota el nmero real de defectos introducidos en cada fase. Reales Hasta la Fecha Para cada fase, anota la suma de los defectos reales y los Hasta la Fecha de los programas ms recientes.
Yo Hasta la Fecha Para cada fase, multiplica por 1O0 los Defectos Hasta la Fecha para esa fase y divdelos por el total de defectos Hasta la Fecha.
~-
Defectos Eliminados Despus del desarrollo, localiza y anota el nmero real de defectos eliminados en cada fase. Reales Hasta la Fecha Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes. para esa fase y divdelos por el total de defectos Hasta la Fecha.
Yo Hasta la Fecha Para cada fase, multiplica por 100 los Defectos Hasta la Fecha
Tabla 13.6 Horas para encontrar un defecto.

Referencia Inspeccin Prueba Utilizacin
Ackerman O'Neill Ragland Russell Shooman VanGenuchten Weller
2-1 o
I
33
0,26
20
1
2-4
3,05 8
0,6 0,25
0,7
RESUMEN
Este captulo describe cmo y porqu encontrar defectos al principio del desarrollo. El factor ms importante en la calidad de un programa es el compromiso personal del ingeniero con la calidad. Con este compromiso, los ingenieros eliminan los defectos al principio, antes de compilar o probar sus programas.
179

Estudiante Programa
Profesor
5r. Z
E5tudiante X
Fecha
Programa#
Lenguaje
Plan
6,50 9,23
4/12/96
11
Ada
Resumen Minutos/LOC LOC/Hora DefectosKLOC Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
Real
5,00 10,20
Hasta la fecha 6,3O 9,52
53
-7-
40
153
35 Plan
17 20 156
O
Real
1 5 20 132 36 7 30 26 202
Hasta la Fecha
40 03 440 36
% Hasta la Fecha 5,0 66 45,6 3,7
35 03 26 345 460 220
77 203 77 964
0,o
21,l
0.0 1O0,O
Plan
Real
1

3 11
ef/Hara
21,4 70,6
Pian
Real
1 4 100 Hasta la Fecha % Hasta la Fecha
Lh?f.Mom
2 1 6
3 0 3
1 4
21,4 57.2 21,4

100,o
El principal mtodo para eliminar defectos introducidos con el PSP es la revisin de cdigo personal. Aqu, primero imprimes un listado del programa y lo revisas lnea por lnea para arreglar tantos defectos como puedas encontrar. Para ser ms eficiente, mira aquellos tipos de defectos que te hayan aparecido en tus errores de compilacin y en las pruebas de programas anteriores. Puesto que las personas tienden a repetir los mismos errores, tus datos de los defectos te ayudarn a encontrar todos o muchos de los defectos de los programas, antes de que los compiles y les hagas pruebas.
180
ENCONTRAR DEFECTOS
La experiencia ha mostrado que cuando los ingenieros revisan a fondo sus cdigos antes de la primera compilacin, reducen el tiempo de compilacin en un 10% del tiempo de desarrollo y el tiempo de pruebas, an ms. Aunque una revisin a fondo del cdigo lleva su tiempo, dichas revisiones reducirn el tiempo total al menos, tanto el tiempo como el empleado en las revisiones y se producirn productos de mejor calidad.
EJERCICIO 13
Para el prximo programa, revisa el cdigo fuente antes de compilarlo y probarlo. Sigue el guin de revisin de cdigo mostrado en la Tabla 13.1. Registra todos los defectos encontrados en el Cuaderno de Registro de Defectos y anota los datos del proyecto en la tabla del Resumen del Plan del Proyecto. Entrega copias del Cuaderno de Registro de Tiempos y de las hojas del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega copias completas del Resumen del Plan del Proyecto y del Cuaderno de Registro de Defectos para cada programa que desarrolles. Incluye los tiempos de desarrollo planificados y reales y los defectos reales introducidos y eliminados.
REFERENCIAS
[Ackerman] Ackerman, Frank A., Lynne S. Buchwald, and Frank H. Lewski. Software Inspections: An Effecttive Verification Process. IEEE Software, May 1989, pp. 3 1-36. [Fagan] Fagan, Michael. Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, vol. 15, no. 3, 1976. [Gilb 931 Gilb, Tom, and Dorothy Graham. Software Znspectiun. Edited by Susannah Finzi, Reading, MA: Addison-Wesley, 1993. [Humphrey 891 Humphrey, W.S. Managing ?he Software Process. Reading, MA: Addison-Wesley, 1989. [ONeill] ONeill, Don. Comunicacin personal. [Ragland] Ragland, Bryce. Inspections Are Needed Now More Than Ever. Juurnal of Defense Software Enginneering, 38. Software Technology Support Center, U.S. Departament of Defense, Nov. 1992. [Russell] Russell, Gien W. Experience with Inspections in UltralargeScale Development. IEEE Sqftwure, Jan. 199 1, pp. 25-3 1.
181
[Shooman] Shooman, M. L., and M. 1. Bolsky. Types, Distribution, and Test and Correction Times for Programming Errors. Proceedings of the 1975 Conference on Reliable Sofmare. Catalog no. 75 CHO 940-7CST, IEEE, New York: p. 347. [vanGenuchten] vanGenuchten, Michael. Comunicacin personal. [Weller] Weller, E. E, Lessons Learned from Two Years of Inspection Data. IEEE Software, Sept. 1993, pp. 38-45.
CAPITULO
14
Listas de comprobacin para la revisin de cdigo
La clave para realizar una revisin de cdigo efectiva es tener un procedimiento de revisin eficiente. Este captulo describe las listas de comprobacin para la revisin de cdigo, y explica cmo pueden ayudarte, para que de una forma rpida y eficiente, encuentres los defectos en tus programas y hagas una lista de comprobacin para tu uso personal. Como ejercicio, disears una lista de comprobacin para los defectos que normalmente introduzcas y la utilizars en la revisin de tus programas.
14.1
POR QUAYUDAN LAS LISTAS DE COMPROBACIN?

Una lista de comprobacin contiene una serie de pasos de procedimiento que quieres seguir de forma precisa. Cuando las personas tienen cosas importantes que quieren hacer exactamente tal y como estn especificadas, a menudo, utilizan las listas de comprobacin. Los pilotos de lneas areas, por ejemplo, las utilizan para hacer una comprobacin pre-vuelo antes de despegar. Aunque hayan hecho una comprobacin del mismo avin una hora antes, la vuelven a hacer. Un estudio de los accidentes en una base de las Fuerzas Areas de los EE.UU., encontr que en cada caso, la lista de comprobacin pre-vuelo no se haba seguido rigurosamente. Otro ejemplo de una lista de comprobacin completa y compleja es la cuenta
184
LISTAS DE COMPROBACIN PARA LA REVISIN DE CDIGO
atrs utilizada por la NASA antes de cada lanzamiento espacial. Este procedimiento se realiza durante varios das y sigue cientos de pasos. Es tan complejo, que se utilizan computadoras para controlar el progreso de la cuenta atrs. Cuando es esencial encontrar y corregir cada defecto en un programa, debes seguir un procedimiento preciso. Una lista de comprobacin te puede ayudar a asegurarte de que se sigue el procedimiento. En este captulo, trataremos una clase muy especial de lista de comprobacin: una diseada para ayudarte a encontrar los defectos cuando hagas una revisin de cdigo de un programa que has escrito. Vers cmo construyes una lista de comprobacin para la revisin de cdigo, que se adapta para encontrar los defectos que te han causado anteriormente muchos problemas. Las listas de comprobacin tambin pueden ser una fuente de ideas. Cuando sigues una lista de comprobacin personal, sabes cmo revisar tu cdigo. Si utilizas la lista correctamente, tambin sabes cuantos defectos encuentras en cada paso de dicha lista. Comparar tu lista de comprobacin con las de otros ingenieros, te puede sugerir aproximaciones tiles para la revisin. La lista de comprobacin encapsula la experiencia personal. Utilizndola con regularidad y mejorndola, mejorars en la deteccin de los defectos de tus programas. La lista de comprobacin tambin te ayudar a encontrar estos defectos en menos tiempo.
14.2
UN EJEMPLO DE LISTA DE COMPROBACIN PARA LA REVISIN DE CDIGO

La lista de comprobacin para la revisin de cdigo que dise para revisar mis programas en C++ se muestra en la Tabla 14.1. Una lista de comprobacin similar para el lenguaje Ada se muestra en la Tabla 14.2. Estas listas de comprobacin sugieren un nmero de puntos a considerar, conforme desarrolles y utilices tu propia lista de comprobacin personal. Un primer paso muy til es asegurar que el cdigo implementa todas las funciones incluidas en el diseo. En grandes programas, es fcil descuidar la codificacin de algn procedimiento u operacin. Dichos descuidos son errores comunes y pueden, ocasionalmente, pasar las siguientes etapas de revisin, compilacin y pruebas. Los descuidos generalmente son fciles de encontrar con una lista de comprobacin.
ths), inicializaComprobaciones completas para i n c ludes (o w i cin, llamadas a procedimientos y nombres, son tambin efectivas. Estas, son las reas de problemas comunes que deberas comprobar a no ser que los datos histricos te indicasen que t NUNCA has cometido dichos errores.
185
Tabla 14.1 Lista de comprobacin y gua para la revisin de cdigo en C + +

Nombre del Programa y #: Propsito
Mtodo
Gua para realizar una revisin de cdigo efectiva
Cuando completes cada paso de la revisin, anota el nmero de defectosque has encontrado de cada tipo en la casilla de la derecha. Si no hay ninguno, anota un control en la casilla de la derecha. Completala lista de comprobacin para un programa, clase, objeto, o mtodo antes de comenzar a revisar la siguiente. Verifica que todaslas funciones del diseoestn programadas. Verificaque los includes estn completos Comprobar la inicializacin parmetros y variables: de * Al inicio del programa. * Al comenzar cada bucle. En la entrada a un procedimiento o funcin.
Completo Includes Inicializacin
Llamadas
Nombres
--
--
Comprobar los formatosde las llamadas a las funciones: Punteros. Parmetros. Utilizacin de ' & '
Comprobar la ortografa de los nombres y su utilizacin: Es Consistente? * Est dentro del mbito declarado? Todas las estructuras/clasesutilizan la referencia '.'? Comprobar que todas las cadenas de caracteres: Estn identificadas por punteros. Terminan en NULL. Comprobar los punteros: * Estn inicializados a NULL. * Solamente se eliminan despus de new. Siempre se eliminan despus de utilizarlos.
Cadenas de caracteres Punteros
Formato de salida
( ) Parejas
- Es
Comprobar el formato de salida: Esadecuado el salto de lnea? * adecuado el espaciado? Asegurarse que los corchetes ( ) son los adecuados y estn balanceados. Verificar la utilizacin correcta de ==, =, ||, etc. Comprobar que cada funcin lgica tiene ().
Operadores lgicos Comprobacin lnea a lnea Estndares
--9
Comprobar cada lnea de cdigo: Sintaxis de las instrucciones. Signos de puntuacin adecuados. Asegurar que cada programa se adapta a los estndares de codificacin.
Apertura y Verifica que todos los ficheros son: cierre de ficheros Declarados de forma adecuada. Abiertos. Cerrados. Global Totales Hacer una revisin global al programa para comprobar los resultados del sistema y problemas inesperados.
186
Tabla 14.2 Lista de comprobacin y gua para la revisin de cdigo en Ada.

Nombre del Programa y #: Propsito Mtodo Gua para realizar una revisin de cdigo efectiva Cuando completes cada paso de la revisin, anota el nmero de defectos que has encontrado de cada tipo en la casilla de la derecha. Si no hay ninguno, anota un control en la casilla de la derecha. Completa la lista de comprobacinpara un programa, clase, objeto, o mtodo antes de comenzar a revisar la siguiente. Verifica que todas las funciones del diseo estn programadas. Verifica que las sentencias with estn completadas Comprobar la inicializacinde parmetros y variables: Al inicio del programa. Al comenzar cada bucle. En la entrada a un procedimientoo funcin. Comprobar los formatosde las llamadas a los procedimientos: Signos de puntuacin. Parmetros. Comprobar la ortografa de los nombres y su utilizacin: Esconsistente? Estdentro del mbito declarado? Todas las estructuras y paquetes utilizan la referencia '.'? Comprobar que todas las cadenas de caracteres hacen una utilizacin adecuada de la particin. Comprobar los punteros: Solamente se eliminan despus de new. Siempre se eliminan despus de utilizarlos. lasta la % Hasta fecha la Fecha
~
Llamadas
--
Nombres
--
Cadenas de caracteres Punteros
Formato de salida
( ) Parejas
Comprobar el formato de salida: Esadecuado el salto de lnea? Es adecuado el espaciado? Asegurarse que los corchetes ( ) son los adecuados y estn balanceados. Verificar la utilizacincorrecta de todas las operaciones lgicas Comprobar que cada funcin lgica tiene ( ) . Comprobar cada lnea de cdigo: * Sintaxis de las instrucciones. Puntuacin adecuada. Asegurar que cada programa se adapta a los estndares de codificacin.
Operadores lgicos Comprobacin lnea alinea Estndares Apertura y cierre de ficheros
Verifica que todos los ficheros son: Declarados de forma adecuada. Abiertos. Cerrados.
Global Totales
Hacer una revisin global al programa para comprobai los resultados del sistema y problemas inesperados.
187
Tambin considera comprobar el cdigo frente a estndares de codificacin, para asegurarte que no has omitido comentarios clave, utilizado un formato inadecuado u omitido informacin importante del proceso o del producto. Aunque los estndares de codificacin pueden parecer que no tienen importancia, pueden ser de gran ayuda para trabajos posteriores, tales como la correccin de un programa, la mejora o la reutilizacin. Puesto que estas son las actividades principales para muchas organizaciones de software, deberas adquirir el hbito de seguir estndares de codificacin (vase la seccin 14.7). El principal peligro con las listas de comprobacin es que generalmente encuentras lo que buscas. Aunque esto es til, el problema es que, si solamente haces las pruebas de la lista de comprobacin, solamente encontrars lo que est en dicha lista. A menudo, sin embargo, los problemas serios aparecen de forma inesperada, tales como interacciones globales entre programas, cuestiones de coordinacin imprevistas, problemas complejos de utilizacin de memoria o condiciones de funcionamiento inusuales. Por ello es una buena idea hacer al menos una revisin general del programa para buscar lo inesperado. Cuando lo hagas, intenta mirarlo desde la perspectiva del sistema o del usuario.
14.3
UTILIZACINDE UNA LISTA DE COMPROBACINPARA LA REVISINDE CDIGO

Para utilizar una lista de comprobacin para la revisin de cdigo, lee cada apartado sucesivamente y haz las acciones prescritas, tal y como estn establecidas. Cuando completes cada accin, mrcala en la lista de comprobacin. Al final, revisa toda la lista de comprobacin para asegurarte que has comprobado cada apartado. Si no lo has hecho, vuelve atrs y haz las acciones omitidas, comprubalas y revisa de nuevo la lista para asegurarte de que no has omitido nada. Al utilizar una lista de comprobacin, te podran ser tiles las siguientes prcticas:
1. Revisa todo el programa para cada apartado de la lista de comprobacin. Con la lista de la Tabla 14.1, por ejemplo, revisa en primer lugar todo el programa, para asegurarte de que se ha implementado todo el diseo. Durante esta revisin, si observas otros defectos, corrgelos Tu intencin, sin embargo, es comprobar todo el programa frente al diseo. A continuacin, revisa el siguiente apartado de la lista de comprobacin y as sucesivamente.
2 Cuando encuentres defectos durante cualquier comprobacin, ano.

ta ese hecho con una marca en la primera columna libre de la derecha #. Para un segundo defecto, se escribir una segunda marca en la misma columna. As, despus de una revisin completa, pue-
188
LISTAS DE COMPROBACIN PARA LA R E V I S I N E CDIGO D
des volver atrs y ver cuntos defectos has encontrado en cada paso de la revisin.
3. Despus de completar cada comprobacin, si no has encontrado defectos, se escribe una x en la primera casilla no utilizada de la columna # .
4. Cuando revises un programa con varias funciones, objetos o procedimientos, es una buena idea revisar cada entidad por separado. Es decir, revisa el procedimiento y escribe una x o el nmero de defectos en la primera columna de la derecha #. Para el segundo procedimiento, se hace lo mismo y se anota el resultado de la revisin en la segunda columna #. Contina as hasta que hayas revisado todas las funciones, objetos o procedimientos. 5. Como se ha observado anteriormente, siempre es una buena idea hacer un examen final global de todo el programa para buscar lo inesperado, nuevas clases de problemas, o problemas del sistema o del usuario.
El proceso general a seguir con una lista de comprobacin para la revisin de cdigo se muestra actualizado en el guin para la revisin de cdigo de la Tabla 14.3. En la Tabla 14.4, se muestra actualizado el guin del Proceso del PSP. Estos guiones tienen solamente un par de cambios con respecto al ltimo captulo, para incluir la lista de comprobacin y la exigencia de que se complete cuando hagas la revisin.
14.4
LA ELABORACIN DE UNA LISTA DE COMPROBACIN PERSONAL

Para hacer una lista de comprobacin para la revisin de cdigo, revisa en primer lugar los datos de los defectos y observa cules de esos defectos provocan los mayores problemas. Aunque inicialmente tendrs una cantidad limitada de datos de defectos, tendrs ms con cada nuevo programa que hagas. Para ser ms efectivo, recuerda que la lista de comprobacin debe ser diseada por ti, para el lenguaje que utilices y para los tipos de defectos que normalmente encuentras y omites. Aunque para comenzar cualquier lista te puede ayudar, probablemente no ser tan eficiente si no se adapta a tus necesidades especficas. A continuacin. indicamos algunas instrucciones que te pueden ayudar a hacer una lista de comprobacin personal til:
1. Hacer una lista clasificada numricamente con los defectos en cada fase del proceso software. Vase, por ejemplo, los datos del Estudiante X en la Tabla 14.5. En la parte inferior de la tabla p o demos ver los defectos encontrados por fase para cada programa.
189
Tabla 14.3 Guin para la revisin de cdigo.

Criterios de entrada Comprueba que tienes a mano: Especificacin de requisitos. El diseo del programa. El cdigo fuente del programa. Estndares de codificacin. Una copia de la lista de comprobacinpara la Revisin de Cdigo. Utiliza la Lista de Comprobacinpara la Revisin de Cdigo. Sigue las instrucciones de la lista de comprobacin durante la revisin. Una vez completada la revisin, rellena las columnas Hasta la Fecha y % Hasta la Fecha, y la fila de Totales.
Mtodo
Procedimiento Primero escribe el cdigo fuente del programa completo. Antes de compilar o probar el programa, imprime un listado del de revisin cdigo fuente. A continuacin, haz la revisin del cdigo. Durante la revisin delcdigo, comprueba cuidadosamente cada lnea del cdigo fuente para encontrar y corregir tantos defectos como puedas. Corregir los defectos Revisar el mbito Revisar la lgica del programa Comprobar los nombres y los tipos Comprobar todas las variables Comprobar la sintaxis del programa Revisar el programa Criterios de salida Corregir todos los defectos encontrados. Comprobar las correcciones para asegurarte que son correctas. Anotar los defectos en el Cuaderno de Registro de Defectos. Verifica que el diseo del programa satisface todas las funciones descritas en la especificacin. Verifica que el cdigo fuente implementa todo el diseo. Verifica que el diseo lgico es correcto. Verifica que el programa implementa correctamente el diseo lgico. Verifica que todos los nombres y tipos son correctamente declarados y utilizados. Comprueba la correcta declaracin de los tipos de dato integer, long integer y float Asegrate que cada variable est inicializada. Comprueba los problemas de desbordamiento, underflow y fuera de rango. Verifica que el cdigo fuente cumple todas las especificaciones del lenguaje. Haz una revisin global del programa para comprobar cuestiones del sistema y problemas inesperados. Al finalizar debes tener: El cdigo fuente terminado y corregido. El Cuaderno de Registro de Tiempos completo. El Cuaderno de Registro de Defectos completo.
190
LISTAS DE COMPROBACIN PARA LA REVISINDE CDIGO

1
Propsito Entradas requeridas
Guiarte en el desarrollo de pequeos programas. La descripcin del problema. Tabla Resumen del Plan del Proyecto PSP. Una copia de la lista de comprobacin para la revisin de cdigo. Datos de tamaos y tiempos reales de programas anteriores. Cuaderno de Registro de Tiempos. Cuaderno de Reaistro de Defectos. Obtn una descripcin de las funciones del programa. Estima las LOC Mx., Mn., total requeridas. Determina los Minutos/LOC Calcula los tiempos de desarrollo Mx., Mn., y total. Escribe los datos del plan en la tabla Resumen del Plan del Proyecto. Anota el tiempo de planificacin en el Cuaderno de Registro de Tiempos. Disea el programa. Anota el diseo en el formato especificado. Anota el tiempo de diseo en el Cuaderno de Registro de Tiempos. lmplementa el diseo. Utiliza un formato estndarpara introducir el cdigo. Anota el tiempo de codificacin en el Cuaderno de Registro de Tiempos. Revisar completamente el cdigo fuente. Seguir el guin de revisin de cdigo y de la lista de comprobacin. Corregir y registrar todos los defectos encontrados. Registrar el tiempo de revisin en el Cuaderno de Registro de Tiempos. Compila el programa. Corrige y anota todos los errores encontrados. Anota el tiempo de compilacin en el Cuaderno de Registro de Tiempos. Prueba el programa. Corrige y anota todos los errores encontrados. Anota el tiempo de pruebas en el Cuaderno de Registro de Tiempos. Completa la tabla Resumen del Plan del Proyecto con los datos de tiempo, tamao y defectos reales. Revisa los datos de defectos y actualiza la lista de comprobacin para la revisin de cdigo. Anota el tiempo postmortemen el Cuaderno de Registro de Tiempos. Programa probado a fondo. Diseo adecuadamente documentado. Lista de comprobacin para la revisin de cdigo completa. Listado completo del programa. Resumen del Plan del Proyecto completo. Cuadernos de Registro de tiempos y defectos completos.
l
1
Planificacin
Diseo
Codificacin
Revisin de cdigo
Compilacin
Pruebas
Postmortem
Criterios de salida
INTRODUCCINL PROCESO SOFTWARE PERSONAL A
191
Tabla 14.5 Anlisis de datos de defectos del Estudiante X.

Tipo
Disear
10
Introducido Codificar
8
2
3
Eliminado
Omitido
Otros
Revisar
4
1
Compilar Pruebas En Revisin

4
4 1
20 30 40
50
4
4
60 70
80 90 10 0 Total
1 6
1 0
1 5
Programa
10 11 12
2 1 1
1-
6 2 2
3 4
As, podemos hacer una comprobacin fcil de todos los defectos contabilizados.
2. Clasifica los tipos de defectos en orden descendiente del nmero de defectos encontrados en las fases de compilacin y pruebas. Un ejemplo de esta clasificacin se muestra en la Tabla 14.6.
3. Para los tipos con el mayor nmero de defectos, examina el Cuaderno de Registro de Defectos y averigua los errores especficos que causan estos tipos. En la Tabla 14.6, tenemos: el tipo 80, defectos de funcin, el tipo 20 defectos sintcticos y el tipo 40 defectos de asignacin.
4. Para los defectos que resultan de los problemas ms importantes, idea los pasos necesarios en la revisin de cdigo para encontrarlos. Supongamos que para el tipo 20 defectos de sintaxis, el Estudiante X encontr que su problema ms frecuente era olvidar o colocar mal el punto y coma. Entonces decidi aadir una prueba que le recordase examinar cada lnea del programa fuente para comprobar especficamente el punto y coma. 5. Registrar las comprobaciones ideadas en la Lista de Comprobacin para la Revisin de Cdigo para asegurarte que haces estos pasos. Por ejemplo, el Estudiante X pudo aadir el siguiente apartado punto y coma en la lista de comprobacin: revisar cada lnea del programa fuente para verificar que los punto y coma son utilizados de forma correcta.
192
Tabla 14.6 Clasificacin de los datos de defectos del Estudiante X .
6. Despus de utilizar la nueva lista de comprobacin, examina los datos de los defectos de la misma forma.
7 Si la lista de comprobacin fue efectiva para encontrar esos de.

fectos ms importantes, aade otro tipo y utilzala de nuevo.
8. Si la lista de comprobacin no fue efectiva para encontrar algunos tipos de defectos, cmbiala para detectar mejor estos defectos e intntalo de nuevo. En este caso, si el Estudiante X encontr que escriba con frecuencia dos puntos en vez de un punto y coma, pudo aadir una nota para comprobar cada punto y coma, y asegurarse de que no fue errneamente escrito como dos puntos. Esta actualizacin de la lista de comprobacin se muestra en la Tabla 14.7.
9. Al desarrollar o actualizar la lista de comprobacin, agrupa las pruebas parecidas y no las dupliques. Si una prueba no funciona bien, sustityela en vez de aadir una nueva prueba para la misma cosa. En el ejemplo de la Tabla 14.7, el Estudiante X incluy las comprobaciones del punto y coma con otras comprobaciones de signos de puntuacin.
10. Despus de desarrollar cada programa, examina los datos de defectos y la lista de comprobacin para identificar los cambios o adiciones tiles.
11. Es una buena idea considerar qu pasos podran prevenir estos defectos en el futuro. Como por ejemplo, la actualizacin de los estndares de codificacin o aadir un paso al proceso de diseo.
En las Tablas 14.5 y 14.6, el Estudiante X mostr todos los defectos que haba introducido y eliminado desde que comenz a reunir datos de defectos. Aunque incluy solamente 20 defectos, esos fueron todos los
193
Tabla 14.7 Lista de comprobacin de Ada actualizada del Estudiante X.

Nombre del Programa y #: Propsito Mtodo Gua para realizar una revisin de cdigo efectiva Cuando completes cada paso de la revisin, anota el nmero de defectos que has encontrado de cada tipo en la casilla de la derecha. Si no hay ninguno, anota un control en la casilla de la derecha. Completa la listade comprobacin para un programa, clase, objeto o mtodo antes de comenzar a revisar la siguiente. Verifica que todas las funciones del diseo estn programadas. Verifica que las sentencias wi t h estn completadas. Comprobar la inicializacin de parmetros y variables: Al inicio del programa. Al comenzar cada bucle. * En la entrada a un procedimiento o funcin. Comprobar los formatosde las llamadas a los procedimientos:
* Signos de puntuacin. * Parmetros.
Llamadas
Nombres
Comprobar la ortografa de los nombres y su utilizacin* Es consistente?
* Est dentro del mbito declarado? 0 Todaslas estructuras y paquetes utilizan la referencia '.'?
Cadenas
Comprobar que todas las cadenas de caracteres hacen
lnicializadoa NULL. Solamentese eliminan despus de new. Siempre se eliminan despus de utilizarlos.
Formato de salida
() Parejas
Comprobar el formato de salida: Es adecuado el salto de lnea? Es adecuado el espaciado?
Asegurarse que los corchetes ( ) son las adecuados y estn balanceados. Verificar la utilizacin correcta de todos los operadores lgicos. Comprobar que cada funcin lgica tiene (). Comprobar cada lnea de cdigo: Sintaxis de la instruccin. Utilizacinadecuada de los puntos y comas. comprobar que los puntos y comas no se escriben como dos puntos. Otros signos de puntuacin.
Operadores lgicos Comprobacin lnea a lnea
Estndares
Asegurar que cada programa se adapta a los estndares de codificacin
Abiertos. Cerrados.
los resultados del sistema y problemas inesperados.

Totales
194
datos que tena. En la Tabla 14.5, puso primero los totales de los programas que haba obtenido de los Resmenes del Plan del Proyecto y despus obtuvo del Cuaderno de Registro de Defectos informacin del tipo. En la Tabla 14.6, clasific la Tabla 14.5 en orden decreciente al nmero de defectos que aparecen en la columna que est ms a la derecha de la tabla. En la parte alta de la lista aparece el mayor nmero de defectos omitidos y a continuacin el segundo tipo de defecto y as sucesivamente. Este tipo de clasificacin se denomina distribucin de Pareto. Estas distribuciones ordenan las entradas en un orden de prioridad, determinado por los datos. Obsrvese tambin, que puesto que el Estudiante X no hizo una revisin de cdigo para el programa 10, contabiliz todos los defectos encontrados en la compilacin y pruebas como defectos omitidos en la revisin de cdigo.
14.5
LA MEJORA DE LA LISTA DE COMPROBACIN

Habitate a revisar con frecuencia tus datos de defectos y vuelve a examinar la lista de comprobacin. Cuando los pasos sean efectivos, vuelve sobre ellos. Cuando algn paso no sea adecuado, idea cmo puedes hacer el paso ms efectivo y actualiza la lista de comprobacin. As, la lista de comprobacin se convierte en un resumen de tu experiencia personal. Tambin ayuda a seguir de forma consistente los pasos que personalmente has inventado para encontrar y corregir defectos. Los siguientes prrafos sugieren formas de mejorar tu lista de comprobacin personal. Despus de terminar un programa, rellena la columna Hasta la Fecha de la lista de comprobacin. Para ello, aade al valor Hasta la Fecha ms reciente de dicha lista el nmero de defectos encontrados en cada paso de la revisin que acabas de completar. Actualiza el valor de la columna Hasta la Fecha para cada fila. El Estudiante X actualiz la lista de comprobacin de la Tabla 14.7. Rellena la columna de % Hasta la Fecha de esta forma: primero suma los valores de la columna Hasta la Fecha y anota el resultado en dicha columna y en la fila de total de la parte inferior de la lista de comprobacin. Con dicho total, calcula el porcentaje para cada fila de Hasta la Fecha y escribe el resultado en la columna de % Hasta la Fecha. De nuevo, la Tabla 14.7 muestra un ejemplo. Durante la fase postmortem para cada programa, compara la lista de comprobacin con el cuaderno de registro de defectos para ver dnde y cmo, la lista de comprobacin podra ser mejorada para perfeccionar el hallazgo de defectos. Tambin debes considerar descartar los pasos de la revisin que no han encontrado o han omitido algn defecto entre los ltimos cinco a diez programas ms recientes. Aqu, por ejemplo, el
195
50 60 70 80
lntelfaz Comprobacin
Datos
9 0 Sistema
10 0 Entorno
Funcin
Tabla 14.8 Ejemplo del cuaderno de registro de defectos del Estudiante X.

Estudiante X
5r. Z
Nmero
Tipo
Introducido
Eliminado
11/1
Descripcin: Fecha
1
omitir:
rm1c dFc cl - - Io i ia.
rzGgz-l
Eliminado
Fecha 11/11/96 Programa # Tiempo de Defecto correccin corregido
Nmero
Tipo
Introducido
lempo de correccin
Defecto corregido
) (codificac.1-1-
7
Descripcin: Fecha
escribir mal la variable X-axis como X-axes
Nmero
Tipo
Introducido
Eliminado
( 2 0 1
; introducido como:
[m piTgizq
rTz-lr-7
Descripcin: Fecha
Nmero
Tipo
1-1
Descripcin: Fecha
( 1 4
Y (codificac./ ]
Tipo Introducido
Lcompilac.1
m
lempo de correccin
Tiempo de correccin
Defecto corregido
incorrectamente escrita la llamada para el procedimiento Normalize
Nmero
Eliminado
Defecto corregido
~
Descripcin: Fecha
olvidado inicializar las variables X a x i s e Y-axis
Nmero
Tipo
Introducido
Eliminado
[mm
Tipo Introducido
m
Tiempo de correccin
Tiempo de correccin
Defecto corregido
Descripcin: bucle while no tiene un valor negativo para X-axis Fecha Nmero Eliminado Defecto corregido
Descripcin: Fecha
nnnnnnn
Descripcin:
nnnnnun
196
Estudiante X debera examinar el cuaderno de registro de defectos para el programa 12 en la Tabla 14.8 para ver si tiene que cambiar la lista de comprobacin con objeto de mejorar la localizacin de defectos que ha omitido. Esta comprobacin le convenci para aadir la referencia del punto y coma en la lista de comprobacin de la Tabla 14.7. Te sugiero que renas datos de ms de 20 defectos antes de actualizar la lista de comprobacin, no obstante, revisa los datos de defectos durante cada fase postmortem del programa. Cuando hayas visto los mismos defectos varias veces en la fase de compilacin y en la de pruebas, considera la actualizacin de la lista de comprobacin para tratar ese problema especfico. Reduce peridicamente la lista de comprobacin. Dicha lista, por su naturaleza, crece con el tiempo. El poder de una lista de comprobacin, sin embargo, es que centre la atencin. Cuando crece mucho, se pierde la concrecin. Es importante revisar peridicamente los datos de defectos y eliminar las entradas de la lista de comprobacin que no encuentren problemas. Puedes agrupar estas entradas eliminadas en una categora de miscelnea para considerarlas cuando examines las otras entradas.
El mtodo de la lista de comprobacin personal reconoce que cada ingeniero es diferente y que las prcticas que unos ingenieros utilizan pueden no ser necesariamente efectivas para otros. Disea tu propia lista de comprobacin y examnala peridicamente para hacerla ms efectiva. Conforme contines omitiendo defectos en las revisiones de cdigo, contina buscando formas de mejorar la lista de comprobacin. Recuerda, sin embargo, que las mejoras llegarn lentamente. Al principio, tu habilidad para encontrar defectos mejorar con cada revisin. Despus, la mejora ser ms difcil. Rene y analiza los datos de defectos y piensa qu podras hacer para prevenir o mejorar la localizacin de defectos omitidos. Conforme vayas haciendo esto, continuars mejorando las revisiones que hagas. Tambin continuars mejorando la calidad de los programas que hagas.
14.6
ESTNDARES DE CODIFICACIN
Una razn de por qu las listas de comprobacin son efectivas es que proporcionan un estndar frente al cual se pueden revisar los programas. El principal estndar de revisin de cdigo son las especificaciones sintcticas del lenguaje de programacin, pero estas no especifican estilos o formatos de codificacin. Por esto, necesitas un estndar de codificacin. Un estndar es una base para la comparacin oficialmente aceptada. Un estndar de codificacin define un conjunto de prcticas de codificacin aceptadas, las cuales pueden servir como un modelo para tu trabajo. Este estndar deberas utilizarlo como una gua cuando escribas cdigo
197
fuente. Dichos estndares, normalmente especificarn la forma en la que el cdigo fuente es formateado, qu sentencias van en lneas de texto separadas, y cmo se sangran las sentencias. Se definen prcticas para escribir comentarios, incluyendo cundo son necesarios los comentarios explicativos. Normalmente, el nombre del ingeniero, la fecha de trabajo, el nombre del programa, el nombre del proyecto y la versin se ponen en una cabecera de comentarios en la parte superior del listado del programa. Un ejemplo del estndar de codificacin utilizado con el lenguaje C++ se muestra en la Tabla 14.9. Los estndares de codificacin tambin pueden ser tiles para prevenir defectos. Aqu, por ejemplo, puedes utilizar ciertas prcticas para evitar, sentencias como go- t o , tener mltiples salidas en los procedimientos o utilizar rutinas recursivas. Algunas prcticas tambin son generalmente muy tiles, tales como inicializar siempre las variables a la entrada al bucle o cuando las declares. Las prcticas de poner nombres inadecuados pueden ser la principal fuente de error. Se deben utilizar nombres que claramente se relacionen con las funciones de las variables, y los nombres deberan ser lo bastante diferentes para que no se confundiesen fcilmente. Dos nombres que se confunden y son propensos a error seran XY34B y XY35C. Una eleccin ms adecuada sera AZIM34 y ACTUALIZA-AZIM.
Si tu profesor ha establecido un estndar de codificacin, consigue una copia y utilzala. Te ayudar a hacer programas ms legibles y fcilmente comprensibles. La legibilidad del cdigo tambin ayuda en las pruebas y en la depuracin de los programas, y ayudar a cualquiera que quiera utilizar o modificar tus programas.
RESUMEN
Este captulo introduce las listas de comprobacin para la revisin de cdigo y describe cmo puedes desarrollarlas y utilizarlas. Una lista de comprobacin contiene una serie de pasos que t quieres seguir de forma rigurosa. Cuando utilizas una lista de comprobacin desarrollada a partir de tus propios defectos, hars revisiones ms eficientes. La lista de comprobacin no solamente ayuda a encontrar ms defectos, tambin ayuda a encontrarlos ms rpidamente. Para construir una lista de comprobacin para la revisin de cdigo, adptala al lenguaje que utilices, disala a partir de tus propios defectos y ajstala a tus habilidades y experiencia cambiante. Algunas orientaciones para utilizar la lista de comprobacin son: haz las revisiones paso a paso, completa cada programa o procedimiento antes de iniciar el siguiente, examina cada apartado de la lista de comprobacin cuando lo completes. Cuando encuentres defectos, anota el
198
Tabla 14.9 Estndar de codificacion de C++.

Propsito Cabeceras del programa Formato de la cabecera Guiar el desarrollo de programas en C++.
Todos los programas comienzan con una cabecera descriptiva
/ Programa e j e r c i c i o : e l nmero de programa */ Nombre: t u nombre */ Fecha: f e c h a de i n i c i o de */ d e s a r r o l l o d e l programa * / Descripcin: una b r e v e d e s c r i p c i n d e * / l a f u n c i n d e l programa * / ................................................ /
................................................
/* /* /* /* /* /*
Listado de contenidos Ejemplos de contenidos
Proporciona un resumen de la lista de contenidos
.................................................
/ * L i s t a d o de c o n t e n i d o s : Instrucciones a r e u t i l i z a r /* Includes /* /* D e c l a r a c i o n e s de c l a s e s : /* CData /* ASet / * Cdigo f u e n t e en c : \ c l a s e s \ C D a t a . c p p : /* CData /* CData() /* EmPtY ( 1
*/ */ */ */ */ */ */ */ */ */ ................................................ /
Instrucciones de reutilizacin
Describe cmo se utiliza el programa. Proporciona el formato de declaracin, valores de los parmetros y tipos, y lmites de los parmetros. Proporciona avisos para valores no vlidos, condiciones de desbordamiento u otras condiciones que podran, en potencia, dar lugar a operaciones inadecuadas.
Ejemplo
................................................
/ * I n s t r u c c i o n e s de r e u t i l i z a c i n /* i n t P r i n t L i n e (char *linea-de-caracteres) /* P r o p s i t o : i m p r i m i r cadena de c a r a c t e r e s , linea-de-caracteres, o i m p r i m i r una /*
/ */ */ */ */ lnea */ /* L i m i t a c i o n e s : l a l o n g i t u d mxima de l a */ /* l n e a es LONGITUD-LINEA */ /* Devuelve: 0 s i l a i m p r e s o r a no e s t */ /* preparada p a r a i m p r i m i r s i n o 1 */ ................................................ /
Identificadores
Utiliza nombres descriptivos para todas las variables, nombres de funciones, constantes y otros identificadores. Evita abreviaturas o variables de una sola letra. i n t numero-de-estudiantes; f l o a t x4, j , f t a v e ; /*Est bien*/ /*Est mal*/ (Contina)
Ejemplo de identificador
199
Tabla 14.9 Estndar de codificacion de C++. (Continuacin)

Comentarios Documenta el programa suficientemente para que el lector pueda entenderlo. Los comentarios deberan explicar tanto el propsito como el funcionamiento del cdigo. Comenta la declaracin de variables indicando su propsito.
~~ ~~
Buen comentario Mal comentario Secciones principales Ejemplo
I f ( c o n t a d o r - r e g > l i m i t e ) / * Han s i d o / * procesados t o d o s l o s r e g i s t r o s ? I f ( c o n t a d o r - r e g > l i m i t e ) * comprueba s i / * contador- reg es mayor que l i m i t e
*/ */ */ */
Las secciones principales del programa deberan ser precedidas por un bloque de comentarios que describan el procesamiento que se realizar en la seccin siguiente.
................................................
/ * E s t a seccin d e l programa examinar l o s / * contenidos d e l array "notas" y c a l c u l a r / * l a n o t a media de l a c l a s e
/ */ */ */ ................................................ /
~ ~~
Espacios en blancc Sangrado
Escribe programas con suficientes espacios en blanco para facilitar la lectura. Separa cada bloque con al menos un espacio. Sangra cada nivel de corchete con respeto al anterior. La apertura y cierre de corchetes deberan hacerse uno por lnea estar alineados unos con respecto a otros. w h i l e (distancia- que- falta > umbral)
{
Ejemplo de sangrado
e x i t o - c o d i g o = mueve-robot ( l o c a l i z a c i n objetivo); i f ( e x i t o - c o d i g o == MOVIMIENTO-FALLIDO)

{
p r i n t f ( " H a f a l l a d o e l movimiento d e l robot " ) ;
1
1
Maysculas Todos los defines se escriben en maysculas. Todos los otros identificadores y palabras reservadas en minscula. En los mensajes de usuario pueden ir mezcladas las maysculas y minsculas, para que la presentacin sea ms clara. # d e f i n e NUMERO-ESTUDIANTES-PORDEFECTO 15 i n t tamao-clase= NUMERO-ESTUDIANTES-POR_DEFECTO;
Ejemplos de maysculas
nmero encontrado en cada apartado de la lista de comprobacin. Cuando lo hagas, completa las columnas Hasta la Fecha y % Hasta la Fecha. Despus de acabar cada programa, revisa los datos y la lista de comprobacin para ver cmo la puedes mejorar.
200
LISTAS DE COMPROBACI~N PARA LA R E V I S I ~ N CDIGO DE
EJERCICIO 14
Haz una lista de comprobacin para encontrar los defectos que causan la mayor parte de problemas durante la compilacin y las pruebas. Restringe esta lista de comprobacin inicial a unos pocos tipos de defectos y utilzala en tu prximo programa. Entrega una lista de comprobacin acabada, junto con el programa y completa el Resumen del Plan del Proyecto. Entrega una copia de los datos de los defectos utilizados para hacer la lista de comprobacin. Para analizar los defectos, utiliza un formato similar al mostrado en la Tabla 14.6. Entrega copias del Cuaderno de Registro de Tiempos y de las hojas del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega copias completas del Resumen del Plan del Proyecto, del Cuaderno de Registro de Defectos y de la Lista de Comprobacin para la Revisin de Cdigo para cada programa que desarrolles. Incluye los tiempos de desarrollo planificados y reales y los defectos reales introducidos y eliminados.
CAPITULO 15
La previsin de defectos
Este captulo discute las formas de analizar y utilizar tus datos de defectos para ayudarte a mejorar tanto la precisin de la planificacin como la calidad del producto. Tambin, se muestran ejemplos tiles de cmo analizar estos datos de defectos. Como ejercicio, preparars un breve resumen de los datos de defectos para los programas que hayas desarrollado hasta la fecha en este curso. La razn principal para utilizar los datos de defectos, es para determinar cmo mejorar la prevencin o localizacin de defectos que hayas introducido. En los ltimos captulos, introducimos medidas que ayudan a controlar la calidad de tu trabaja Esto te ayudar a que de una forma ms consistente produzcas programas de alta calidad.
15.1
EL PORCENTAJE DE DEFECTOS
El porcentaje de defectos introducidos por los ingenieros del software experimentados, oscila normalmente en un rango de entre 50 a 250 defectos/KLOC. La Figura 15.1 muestra los defectos/KLOC que un grupo de 38 ingenieros introdujo en un ejercicio de codificacin pequeo. Esto fue antes de que ellos comenzasen a medir, revisar y controlar el nmero de defectos que introducan. Esta figura muestra el porcentaje de defectos introducidos por estos ingenieros antes de que fuesen entrenados en el PSP.
202
LA PREVISI~NDE DEFECTOS
450 400 -
I
I I
350 -
x $
u
300250 I I
22 2 0 0 -
E;
150 -
loa50 -
I I
m
I
- -- - I -
m '
I I I
Obsrvese tambin que la Figura 15.1 muestra la densidad de defectos en funcin de los aos de experiencia del ingeniero en escribir programas. Algunos de los ingenieros menos experimentados tenan un nmero ms elevado de defectos que los otros, sin embargo para estos pocos ingenieros, los aos de experiencia tenan poca influencia en el nmero de defectos. Esto implica que hay algunas prcticas de calidad, que muchos ingenieros aprenden con la experiencia. Algunos adquiran la experiencia ms rpidamente que otros. Entonces, a partir de un grado de experiencia similar, los defectos dependen en gran parte de la disciplina personaI, La Figura 15.2 muestra los datos de los mismos 38 ingenieros despus de haber completado un curso del PSP [Humphrey 951. En este pnto, haban revisado sus defectos para un total de 10 programas pequeos, y haban hecho dos estudios de los tipos, distribuciones y tiempos de corregir sus defectos. Como resultado, comprendieron el nmero y tipos de defectos que normalmente introducan y cunto tiempo le dedicaban a corregirlos. Esto les ayuda a valorar la importancia de las prcticas personales disciplinadas, y les motiv a ser ms cuidadosos en el diseo y codificacin de sus programas. Como resultado, tambin redujeron su porcentaje de introduccin de defectos. Los datos de las Figuras 15.1 y 15.2 sugieren que la disciplina personal, asociada con la revisin de defectos y su anlisis, es mucho ms efectiva que los aos de experiencia para la reduccin del nmero de defectos introducidos. Otro mensaje de las Figuras 15.1 y 15.2 es que los ingenieros del software introducen muchos defectos. Con pocas excepcioncs, la tasa de introduccin de defectos por grupos de software est alrededor de los 100 defectos/KLOC o ms. Incluso los ingenieros que han aprendido a ges-
203
10
15
20
25
30
Aos de experiencia en programar
Figura 15.2 Defectoc/KLOC vs. aos - decpues del entrenamiento en el PSP.
tionar los defectos, introducen una media de unos 50 defectos/KLOC. Es decir 1 defecto por cada 20 LOC. Aunque esto no pueda parecer una gran cantidad, seran 50 defectos en un programa de 1.000 LOC, 500 en uno de 10.000 LOC y 50.000 en uno de 1 .OOO.OOO LOC. Todos estos defectos se deben localizar y corregir antes de que puedas estar seguro de que el programa funcionar adecuadamente,Bepitiendo una cuestin clave, puesto que la introduccin de defectodes una co'msecuencia natural del ser humano, todos los ingenieros del software introdhcen defectos. Todos los ingenieros deberan por lo tanto comprender el nmero y tipo de defecto que introducen.
15.2
LA UTILIZACIN DE LOS DATOS DE DEFECTOS

Hasta ahora, has reunido datos de defectos para ayudarte a comprender los defectos que has introducido. A continuacin utilizaste esos datos para disear una lista de comprobacin personal para hacer la revisin de cdigo. En este captulo, utilizars esos datos de defectos para estimar el nmero de defectos que introducirs en un nuevo programa. Utilizando datos histricos, tambin vers cmo haces unas buenas estimaciones del nmero de defectos que introducirs y eliminars en cada fase de un proyecto de codificacin. Las estimaciones exactas del grado de defectos son importantes. Siempre puedes realizar otra prueba u otra revisin de cdigo. La nica manera para decidir realizar dichas pruebas y revisiones, consiste en analizar los datos de los defectos. Comparando los datos del proyecto en cur-
204
LA PREVISIN DE DEFECTOS
so con los datos histricos, puedes determinar la posible calidad del programa a desarrollar. Puedes decidir si son necesarios pasos adicionales para la eliminacin de los defectos.
Todas estas medidas y planes no te ayudarn mucho, a menos que ests personalmente comprometido a hacer programas libres de defectos. Aunque es costoso producir programas de alta calidad y rara vez sers capaz de hacerlo al primer intento, con mucha prctica, hars cada vez ms programas libres de defectos. Esto es importante, puesto que algn da probablemente trabajars en un proyecto, donde es esencial el trabajo libre de defectos. Te sugiero que consideres cada programa que desarrollas como una prctica para ese da.
15.3
DENSIDAD DE DEFECTOS
La unidad de medida de defectos utilizada en el PSP es la de defectos por miles de lneas de cdigo (KLOC). Esto se denomina densidad de defectos (Dd) y se mide en unidades de defectos/KLOC. Aqu, la K hace referencia a 1.OOO. Para calcular el total de defectos/KLOC encontrados en un programa, haz lo siguiente:
1. Suma el total de nmero de defectos (D) encontrados en todas las fases del proceso. 2. Cuenta el nmero (N) de lneas de cdigo nuevas o cambiadas en un programa.
3. Calcula la densidad de defectos por KLOC como Dd= I.OOO*D/N.
Por ejemplo, si un programa de 96 LOC tena un total de 14 defectos, entonces la densidad de defectos sera 1.OOO* 14/96=145,83 defectos/KLOC. En el clculo de las densidades de defectos, es importante utilizar medidas de tamao correctas. Tal y como se describi en el Captulo 6, este libro cuenta el tamao del programa por el nmero de LOC nuevas y cambiadas. Es decir, si utilizas una rutina de librera o copias una parte de un programa, esto no se contabiliza como LOC. Sin embargo, contabiliza como LOC nueva, cualquier LOC modificada de los programas que habas copiado.
15.4
CMO ESTIMAR LAS TASAS DE DEFECTOS

Cuando ests desarrollando un nuevo programa, probablemente tendrs problemas en estimar cuntos defectos introducirs. La razn es que este nmero variar de un programa al siguiente. Hay varias causas para esto.
205
Primera, con la experiencia, tus habilidades mejorarn. Cuando comienzas a programar, te enfrentas a muchos problemas que no te habas encontrado anteriormente. No puedes estar seguro de cmo trabaja alguna funcin o procedimiento, puedes confundirte con algn elemento del lenguaje, o puedes encontrar nuevos aspectos del entorno o del compilador. Estos problemas darn lugar a que tus tiempos de desarrollo y el porcentaje de introduccin de defectos flucte. Con la experiencia, superars de forma gradual estos problemas iniciales y cometers pocos errores. Esto reducir tanto el nmero total de defectos como la variacin de estos nmeros. La reduccin inicial en el nmero de defectos ser como resultado de la mayor experiencia y de tu mejor desenvoltura con el lenguaje. Ms all de esta mejora inicial, sin embargo, necesitars reunir y analizar los datos de los defectos para continuar mejorando. La segunda razn para la fluctuacin en la tasa de defectos, es que tu proceso no es estable. Es decir, conforme aprendas a escribir programas, tambin aprenders nuevos mtodos y procedimientos. Tus prcticas de trabajo evolucionarn. Esto causar fluctuaciones en el tiempo que necesitas para hacer las distintas tareas de codificacin y en el nmero de los defectos introducidos. Finalmente, los mismos defectos son una fuente de fluctuacin. A mayor nmero de defectos introducidos, ser necesario ms tiempo para repararlos. Puesto que los ingenieros normalmente introducen de 6 a 8 defectos por hora durante la codificacin de un programa, cada hora dedicada a la correccin de defectos aumentar la probabilidad de introducir ms defectos. Puesto que el tiempo de correccin de defectos es generalmente variable. un proceso que introduce muchos defectos es intrnsecamente impredecible. Conforme vayas mejorando los procesos, sin embargo, te estabilizars y esta estabilidad mejorar la precisin de tus previsiones de defectos. Si dedicas una cantidad de tiempo suficiente a las revisiones de cdigo, tus procesos tendern a estabilizarse a un modelo fijo. Una vez que tus procesos sean razonablemente estables, sern ms predecibles. As, revisando el nmero de defectodKLOC introducidos y eliminados en los ltimos programas, puedes estimar con precisin el nmero de defectos que probablemente introducirs y eliminars en el futuro.
15.5
ESTIMACIN DE DEFECTOS
Cuando ests planificando un nuevo programa, estima primero el nmero de LOC nuevas y cambiadas que probablemente tendr el programa. A continuacin, calcula el valor medio de los defectos/KLOC de los programas que hayas desarrollado anteriormente. Con estos datos, ahora, puedes calcular el nmero de defectos/KLOC esperados en el nuevo programa:
206
Ddplan 1.000(0, +...+ Di)/(N,+ ... + N i ) =

Supongamos, por ejemplo, que tenas datos de los 5 programas mostrados en la Tabla 15.1. El valor de Ddplan calcula de esta forma: se Ddplan l.OOO(6 + 11 + 7 + 9 + 3 4 3 7 + 62 + 49 + 53 + 28) = = 1.000*38/229 = 165,94 defectos/KLOC Suponiendo que el nuevo programa tendr la misma densidad de defectos, el nmero de defectos esperados ser:
Dplan Nplan* = Ddplan 1.ooo. Ahora, utilizando este mismo ejemplo, y suponiendo que las LOC estimadas para el nuevo programa son 56, el nmero de defectos esperados es:
Dplan 56" 165,94 / 1.000 = = 9,29 defectos.

Utilizando estos datos, tendrs una previsin de 9 defectos para un proyecto de codificacin con 56 LOC planificadas. El tamao Hasta la Fecha y los datos de defectos en el Resumen del Plan del Proyecto fueron diseados para ayudarte a hacer estos clculos.
Dplan
= Nplan* DHasia
la Fecha
'
NHasta la Fechai
O, utilizando los datos de la Tabla 15.1, esta ecuacin da:

Dplan 56*38/229 = 9,29, = obtenindose el mismo resultado que antes. Con el nmero total de defectos esperados para el nuevo programa, puedes calcular el nmero de defectos esperados que se introducirn y eliminarn en cada fase. Para obtener estos nmeros, multiplica el nmero total de defectos esperados por el valor de % Hasta la Fecha para cada fase y divdelo por 100. Esto nos da el nmero de defectos esperados para esa fase del nuevo proyecto. Esta fue la razn de calcular los valores de los defectos Hasta la Fecha y el % de defectos Hasta la Fecha. Ya que,
Tabla 15.1 Ejemplo de datos de defectos.
Nmero de programa
1
Defectos (D)
LOC (N)
6
11
37
62
4 9
2
3 4
7
9
5
53
28
229
5
Total Hasta la Fecha
38
207
proporcionan los datos histricos necesarios para estimar los defectos. En la Seccin 15.7 se muestra un ejemplo de estos clculos con la actualizacin del Resumen del Plan del Proyecto.
15.6
ACTUALIZACIN Y EJEMPLO DE LA TABLA RESUMEN DEL PLAN DEL PROYECTO

El nuevo guin del Proceso PSP y la plantilla del Resumen del Plan del Proyecto incluyen ahora la planificacin de defectos, lo podemos observar en las Tablas 15.2 y 15.3. Las instrucciones para el Resumen del Plan del Proyecto se muestran en la Tabla 15.4. Las nuevas entradas de estas tablas se muestran en cursiva. Las nuevas incorporaciones son: la columna del Plan para los defectos introducidos y eliminados y la fila defectos/KLOC en la seccin resumen. La Tabla 15.5 muestra un ejemplo de la tabla Resumen del Plan del Proyecto del Estudiante X para el programa 13. Los siguientes prrafos describen cmo ha utilizado los datos del programa 12, resumidos en la Tabla 15.6, para completar los datos de la Tabla 15.5. Varios de los valores de esta tabla estn etiquetados con letras para ayudar a identificar la fuente del dato. Primero, durante la planificacin:
1. Primero el Estudiante X estim el tamao del nuevo programa en 58 LOC (a) y el mximo y mnimo en 72 (a) y 41 (a) LOC.
2. Despus, observ la tabla Resumen del Plan del Proyecto del programa 12 para encontrar los minutosLOC Hasta la Fecha. Como se observa, este valor era 5,92 (b) minutosLOC. Utiliz dicho valor como velocidad de planificacin para el programa 13. 3. Con el total estimado de 58 LOC (a), el tiempo total estimado del proyecto es: 58*5,92 = 343,36 o 343 minutos (c). 4. Entonces el Estudiante X calcul los tiempos de desarrollo mximo y mnimo, multiplicando los tamaos mximo y mnimo (a) por 5,92 para obtener 426 y 243 (d) minutos, respectivamente. 5. Para el tiempo por fase, tom los % Hasta la Fecha del resumen (e) del programa 12 y los multiplic por el tiempo total estimado de 343 minutos (c), y dividi el resultado por 100. Esto dio los tiempos para cada fase, tal y como se muestra en (f).Por comodidad, redonde los minutos a un valor entero. 6. Para el total de defectos introducidos y eliminados, el Estudiante X encontr el valor de 94,79 (8) defectos/KLOC Hasta la Fecha en la Tabla 15.6 del Resumen del Plan del Proyecto para el programa 12. Como se ve abajo, este valor se calcul a partir de LOC Hasta la Fecha (h) y los defectos Hasta la Fecha (i).
208

~ ~~
Propsito Entradas requeridas
Guiarte en el desarrollo de pequeos programas. La descripcin del problema. Tabla Resumen del Plan del Proyecto PSP. Una copia de la lista de comprobacin para la revisin de cdigo. Datos de tamaos y tiempos reales de programas anteriores. Cuaderno de Registro de Tiempos. Cuaderno de Registro de Defectos. Obtn una descripcin de las funciones del programa. Estima las LOC Mx., Mn., total requeridas. Determina los Minutos/LOC. Calcula los tiempos de desarrollo Mx., Mn., y total.
Planificacin
Estima los defectos a introducir y eliminar en cada fase.

Escribe los datos del plan en la tabla Resumen del Plan del Proyecto. Anota el tiempo de planificacin en el Cuaderno de Registro de Tiempos. 2 Diseo Disea el programa. Anota el diseo en el formato especificado. Anota el tiempo de diseo en el Cuaderno de Registro de Tiempos. lmplementa el diseo. Utiliza un formato estndar para introducir el cdigo. Anota el tiempo de codificacin en el Cuaderno de Registro de Tiempos. Revisar completamente el cdigo fuente. Seguir el guin de revisin de cdigo de la lista de comprobacin. Corregir y registrar todos los defectos encontrados. Registrar el tiempo de revisin en el Cuaderno de Registro de Tiempos. Compila el programa. Corrige y registra todos los errores encontrados. Anota el tiempo de compilacin en el Cuaderno de Registro de Tiempos. Prueba el programa. Corrige y anota todos los errores encontrados. Anota el tiempo de pruebas en el Cuaderno de Registro de Tiempos. Completa la tabla Resumen del Plan del Proyecto con los datos de tiempo, tamao y defectos reales. Revisa los datos de defectos y actualiza la lista de comprobacin para la revisin de cdigo. Anota el tiempo postmortem en el Cuaderno de Registro de Tiempos. Programa probado a fondo. Diseo adecuadamente documentado. Lista de comprobacin para la revisin de cdigo completa Listado completo del programa. Resumen del Plan del Proyecto completo. Cuaderno de Registro de tiempos y defectos completos.
Codificacin
Revisin de cdigo
~~~
Compilacin
Pruebas
Postmortem
Criterios de salida
209

Estudiante
Programa
Fecha
Programa #
Profesor Resumen MinutosiLOC LOClHora DefectosiKLOC Rendimienfo VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Plan Real
Lenguaje
Hasta la Fecha
Plan
Real
Hasta la Fecha
% Hasta la Fecha
Plan
Real
DefJHora
Plan
Real
DefJHora
7 Con los valores de 94,79 defectos/KLOC (i) y las 58 LOC (a) .

planificadas, calcul el nmero total de defectos esperados 94,79*58/1.O00 = 5,50, aproximadamente 6 defectos 6).
8. Basndose en los valores de % Hasta la Fecha para los defectos introducidos y eliminados del programa 12 (k), calcul la estimacin del nmero de defectos a ser introducidos y eliminados por fase (1).
210
Propsito Cabecera Esta tabla trata los datos estimados y reales de los proyectos de una forma cmoda y fcilmente recuperable. Introduce los siguientes datos: Tu nombre y fecha de hoy. Nombre y nmero de programa. Nombre del profesor. El lenguaje que utilizars para escribir el programa. Antes de iniciar el desarrollo: Escribe los MinutoslLOC planificados para este proyecto. Utiliza la velocidad Hasta la Fecha de un programa reciente del Cuaderno de Trabajos o del Resumen del Plan del Proyecto. Despus del desarrollo: Divide el tiempo total de desarrollo por el tamao real del programa para obtener los Minutos/LOC reales y los MinutosLOC Hasta la Fecha. Por ejemplo, si el proyecto se hizo en 196 minutos e hiciste 29 LOC, los Minutos/LOC seran 196/29= 6,76.
Minutos/LOC
LOC/Hora
Antes de iniciar el desarrollo: Calcula las LOC por hora planificada para este programa dividiendo 60 por los MinutosLOC de la casilla de Flan. Despus del desarrollo: Para LOC/Hora Real y Hasta la Fecha divide 60 por Minutos/LOC Reales y Hasta la Fecha. Para los 6,76 MinutosiLOC Reales, tenemos 60/6,76 = 8,88 LOC/Hora Reales.
~~
DefectodKLOC
Antes de desarrollar: Encuentra los defectodKL0C Hasta la Fecha del programa ms reciente. Utiliza dicho valor como los defectos/KLOC planificados. Despus del desarrollo: Calcula los valores de defectos/KLOC reales y Hasta la Fecha para este programa. Para el valor real, multiplica el total de defectos reales por 1.000y divdelo por las LOC Total Nuevas & Cambiadas Reales. Para el valor Hasta la Fecha haz unos clculos similares. Con 1 defectos Hasta la fecha y 153 LOC Total Nuevas & 7 Cambiadas, los defectos/KLOC Hasta la Fecha =
1.000*17/153= 1,ll. 11
Tamao Programa Antes de iniciar el desarrollo: (LOC) Escribe bajo la columna plan, el valor estimado de LOC Total Nuevas & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y anota las LOC Nuevas & Cambiadas Reales. Para la columna Hasta la Fecha, aade LOC reales Nuevas & Cambiadas a las LOC Hasta la Fecha Nuevas & Cambiadas de programas anteriores.
( Contina)
211
(Continuacin)
Tiempo por fase Plan Para el tiempo total de desarrollo, multiplica el valor de LOC . Total Nuevas 8 Cambiadas por los Minutos/LOC. Para el tiempo Mximo, multiplica el tamao Mximo por los Minutos/LOC. Para el tiempo Mnimo, multiplica el tamao Mnimo por los Minutos/LOC. Del Resumen del Plan del Proyecto de un programa reciente, busca los valores de Yo Hasta la Fecha para cada fase. Utilizando el Yo Hasta la Fecha de programas anteriores calcula el tiempo planificado para cada fase. Una vez acabado el trabajo, anota el tiempo real en minutos que has gastado en cada fase del desarrollo. Obtn estos datos del Cuaderno de Registro de Tiempos. Para cada fase, escribe la suma del tiempo real y el tiempo Hasta la Fecha de los programas ms recientes. Fecha y lo divides por el total del tiempo Hasta la Fecha.
~
Real
Hasta la Fecha
% Hasta la Fecha Para cada fase, escribe 1O0 multiplicado por el tiempo Hasta la
.. . _
Defectos introducidos Plan
Antes del desarrollo, estima el nmero total de defectos a introducir en el programa. El valor es: defectos/KLOCplanificados multiplicado por las LOC Total Nuevas & Cambiadas planificadas para este programa y dividido por 7.000. Por ejemplo, con un valor de defectos/KLOCplanificado de 75,9 y un valor de LOC Nuevas & Cambiadas planificadas de 75, el total de Defectos Planificados = 75,9*75/1.000=5,69, redondeado a 6. Antes de desarrollar, estima los defectos introducidos por fase utilizando el total de defectos estimados y el % Hasta la Fecha de defectos introducidos de programas anteriores. Despus del desarrollo, localiza y anota el nmero real de defectos introducidos en cada fase. Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes.
Real Hasta la Fecha
% Hasta la Fecha Para cada fase, multiplica por 1O0 los defectos Hasta la Fecha para esa fase y divdelos por el total de defectos Hasta la Fecha.
Defectos eliminados Plan Real Hasta la Fecha
En la fila de total, escribe el total de defectos estimados. Utilizando los valores de % Hasta la Fecha de los programas ms recientes, calcula los defectos eliminados planificados para cada fase. Despus del desarrollo, localiza y anota el nmero real de defectos eliminados en cada fase. Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes.
~
% Hasta la Fecha Para cada fase, multiplica por 1O0 los defectos Hasta la Fecha
para esa fase y divdelos por el total de defectos Hasta la Fecha.
212
Tabla 15.5 Ejemplo de resumen del plan del proyecto del PSP.
5r. Z
Estudiante X
Fecha Programa#
10/11/96 1 3
Ada
Lenguaje Plan
b
i
Resumen Minutos/LOC LOClHora DefectoslKLOC Rendimienfo VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin I Diseo Codificacin I Revisin del cdigo Compilacin Pruebas Total i Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo l Compilacin I I Pruebas Total i
Real
592 10,14 94,79
P
q r
Hasta la Fecha
4.07 12,32 1064
x
y
5,73 10,47 96,90
a
a
50
72
47
250
4 1
Plan
f f
Real
1 0
m
Hasta la Fecha
c s
% Hasta la Fecha
u
f
f
f f f
C
35 149 20 24
64
m
m m m m m m
d d
33 343 426 243
22 24 93 37 4 8 4 1 229
s
c
s s
s s
88 11 5 637 111 92 240 160 1479
6,O
10,2 43,l 7,5 62 16,2 10,8 100
u
u
u
u u
Plan
1
5 n
Real
t

4 21
u
Dei./Hora
16,O 84,O
25
100,O
Plan
Real
Def./Hora
3 1
6
n
n
3 2 5
t t
t
0 12 5 25
u u
u
32,O 40,O 20,o 100,O
Esto ahora completa las estimaciones de defectos para el programa 13.
15.7
LA ANOTACIN DE LOS DATOS REALES

Despus de desarrollar el programa, el Estudiante X anot los datos reales en la tabla, de la siguiente forma:
213
Tabla 15.6 Resumen del plan de programa 12 del Estudiante X.

Estudiante Estudiante X
Programa
Fecha Programa#
11/11/96 12
Profesor
5r. Z
Lenguaje
Plan
6,30 9,52
Ada
Resumen MinutoslLOC LOClHora DefectoslKLOC Rendimienfo VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Minimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
Real
4,93 1,7 21
b 9
Hasta la Fecha
5.92 10,14 94,79
5 1 65 37
58
211
Plan
1 6 27 146
Real
1 s 8
Hasta la Fecha
66
44s
104 s 38 s
11 s
127
544 74
e e
e
12
26 68 26 321 4O 1 233
e e
e
80
232 19 1 1250
29 s 42 s 286 s
% Hasta la Fecha 5,3 10,2 43,5 5,9 70 18,6 9,5 100,o
Plan
Real
1 t

4 1 6
k k
DefJHora
20,O 80,O
20
100,o
Plan
Real
DefJHora
20
100,o
1. Anot los valores reales del Tiempo por Fase (m), del Cuaderno de Registro de Tiempo.
2. Anot los valores reales de los defectos Introducidos y Eliminados (n), del Cuaderno de Registro de Defectos.
3. Contabiliz 47 LOC Nuevas & Cambiadas en el programa y las anot bajo la columna Real (o).
214
4. Con estos datos, calcul los MinutosLOC reales a partir de los minutos totales, 229 (m), dividido por las 47 (o) LOC Nuevas & Cambiadas, obteniendo 229/47 = 4,87(p).
5. Calcul las LOC/Hora reales a partir de los minutos/LOC reales (p) de esta forma: 60/4,87 = 12,32 (9).
6. Calcul los defectos/KLOC reales a partir del total de defectos reales (n) y de las LOC (o) reales, 1.000*5/47=106,4(r).
7 A continuacin, calcul los valores Hasta la Fecha para el Tiempo . por Fase, sumando los tiempos en las fases para este proyecto a
los tiempos Hasta la Fecha para los proyectos anteriores (s).
8. Tambin calcul los valores para los defectos introducidos y eliminados Hasta la Fecha, sumando los defectos reales en cada fase a los valores de los defectos Hasta la Fecha de proyectos anteriores (t).
9. Los valores de % Hasta la Fecha se calcularon tambin, como se ve en (u).
10. A continuacin, calcul el valor Hasta la Fecha para los Minutos/LOC, dividiendo el tiempo Total Hasta la Fecha, 1.479 minutos (s) por el valor de LOC Total Nuevas & Cambiadas, 258(w). Obteniendo 1.479/258 = 5,73 (x).
11. Utilizando el valor 5,73(x), calcul el valor Hasta la Fecha de LOC/Hora, 60/5,73=10,47 (y).
12. Finalmente, calcul los defectos/KLOC Hasta la Fecha, multiplicando 1.000 por los defectos totales introducidos Hasta la Fecha (t) y dividiendo el resultado por las LOC Totales Nuevas & Cambiadas Hasta la Fecha (w), obtenindose 1.000*25/258= 96,90 (z).
Obsrvese que las columnas Hasta la Fecha y % Hasta la Fecha muestran el tiempo total y la distribucin de defectos. Con ms experiencia, puedes encontrar que tu productividad y el grado de defectos cambia tan significativamente que los datos de los programas iniciales no sirven de gua til para las planificaciones actuales. En esta situacin, puedes desear recalcular todos los valores de Hasta la Fecha y % Hasta la Fecha sin los valores de los primeros programas.
RESUMEN
En este captulo, utilizas los datos de los defectos para estimar el nmero de defectos que introducirs y eliminars en cada fase de un nuevo programa. Conforme aprendas a hacer las previsiones de los defectos,
215
tambin aprenders a hacer mejores planes de desarrollo y un mejor control del nmero de defectos que introduces y eliminas. Para hacer una proyeccin de defectos, necesitas los datos de los defectos y del tamao de los programas anteriores, y un tamao estimado para el nuevo programa. Para calcular el nmero de defectos esperados, supn que los defectos/KLOC para este programa sern iguales a la media de los programas que hayas desarrollado previamente. Tambin asume que el porcentaje de introduccin y eliminacin de defectos ser similar. Utiliza los valores de los defectosKLOC y % Hasta la Fecha del nmero de defectos del programa anterior, para hacer los clculos de planificacin. Se hace una actualizacin del Resumen del Plan del Proyecto para incorporar la estimacin de defectos. Haz el plan de valores durante la fase de planificacin para cada proyecto de codificacin. Calcula los valores de defectos/KLOC Planificados, Reales y Hasta la Fecha durante la fase postmortem de cada nuevo programa y utiliza estos datos para planificar el siguiente proyecto.
EJERCICIO 15
Para el siguiente programa que escribas, determina el porcentaje de defectos/KLOC y la estimacin de defectos introducidos y eliminados por fase. Anota estos datos en el Resumen del Plan del Proyecto de la Tabla 15.3. Entrega copias del Cuaderno de Registro de Tiempo y de las hojas del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega copias completas del Resumen del Plan del Proyecto, del Cuaderno de Registro de Defectos y de la Lista de Comprobacin para la Revisin de Cdigo para cada programa que desarrolles. Incluye los valores planificados y reales de los tiempos de desarrollo y de los defectos introducidos y eliminados.
REFERENCIA
[Humphrey 951 Humphrey, W.S. A Discipline for Sofhare Engineering. Reading, MA: Addison-Wesley, 1995.
CAPITULO 16
La economa de eliminar defectos
Este captulo trata sobre el ahorro que supone eliminar los defectos. Eliminar los defectos es una cuestin econmica, ya que muchas decisiones sobre la eliminacin de defectos tienen que ver con el equilibrio entre coste, planificacin y calidad. Aunque la calidad del producto debe tener siempre una alta prioridad, muchos proyectos estn limitados por la planificacin y los costes. As, el coste relativo de la eliminacin de defectos durante el desarrollo, el impacto de los defectos que quedan sobre el cliente y el coste resultante del soporte al cliente, son cuestiones importantes en el desarrollo del software. En el ejercicio de este captulo, analizars las tasa de defectos introducidos y eliminados en los programas que has desarrollado hasta ahora en este curso.
16.1
LA NECESIDAD DEL TRABAJO DE CALIDAD

A pesar de los distintos avances tecnolgicos que se han producido en el campo de los computadores, el trabajo de los ingenieros software no ha experimentado cambios en los ltimos 30 aos. Los ingenieros software siempre dividen un gran programa a realizar en pequeas partes. Y generalmente, trabajan en el desarrollo de una o ms de estas partes. En este proceso utilizan el 30-40% o ms de su tiempo intentando hacer que es-
218
LA ECONOMA DE ELIMINAR DEFECTOS
tos programas funcionen con pruebas bsicas. Una vez que el programa funciona, los programadores, de una forma progresiva los prueban e integran con otros programas hasta formar un gran sistema. El proceso de integracin y pruebas esta orientado a encontrar y eliminar los defectos. Cuando el producto final se entrega, a menudo su calidad es tan escasa que los ingenieros deben dedicar muchos meses a corregir los defectos que encuentran los clientes. Esto era una prctica comn hace 30 aos y lo es hoy en da tambin. Hay mejores formas de desarrollar software. El problema bsico es que cuando los ingenieros software escriben primero sus programas, normalmente pasan muy rpidamente por el diseo y la codificacin, para obtener sus programas en las fases de compilacin y pruebas. Un principio del trabajo de calidad, es obtener el producto correcto a la primera. Si se aprende lo anterior, no ser necesario eliminar estos defectos en las fases de compilacin y pruebas, y tanto t como tu organizacin no necesitaris dedicar tiempo a encontrar y corregir defectos. Un ejemplo de algunos ingenieros de Motorola muestra la importancia de lo anteriormente dicho. Su software se utilizaba para poner en funcionamiento una fbrica de productos avanzados. Si el producto o el proceso de produccin lo cambiaban, los ingenieros tenan que cambiar el software. Para encontrar los defectos en cada nueva versin del software, la lnea de produccin tena que parar, para hacer las pruebas. Despus de cada prueba, la lnea de produccin era interrumpida peridicamente por los defectos del software que haban quedado ocultos. En la primera actualizacin de software, despus de que los ingenieros hicieran la formacin del PSP, hubo solamente un defecto en las pruebas y ninguno en los siguientes meses de produccin. Esto no solo ahorr tiempo de pruebas, sino tambin redujo las interrupciones durante la fabricacin. Como resultado, se obtuvo que la planta de fabricacin poda producir ms productos, y la compaa poda obtener ms ingresos.
16.2
EL PROBLEMA DE ELIMINAR DEFECTOS

Eliminar los defectos es costoso porque los defectos son difciles de encontrar y corregir. Conforme haces sistemas software ms grandes y complejos, este problema se agravar. El tamao y complejidad de los sistemas software aumenta unas diez veces cada diez aos. As. las primeras impresoras lser necesitaban unos programas de 20.000 LOC para gestionarlas, la ltima versin utiliza entorno al milln de LOC. Hace diez aos, los automviles no tenan software; los coches modernos contienen muchas miles de lneas de software. Puesto que el tamao y la complejidad del software probablemente continuarn creciendo, la eliminacin de defectos continuar siendo ms costosa y consumir ms tiempo.
219
Para entender y controlar los costes de los defectos, es fundamental medir la efectividad de la eliminacin de defectos. Una de dichas medidas, es el nmero de defectos eliminados en una hora. Otra medida til es el rendimiento en la eliminacin de defectos. El rendimiento mide la tasa de los defectos encontrados con un mtodo de eliminacin. As, si un producto contena 100 defectos antes de hacer las pruebas, y se encontraron 45 defectos durante la realizacin de las pruebas, el rendimiento de dichas pruebas sera del 45%. Cuando sabes el rendimiento y la tasa de eliminacin para cada mtodo de eliminacin de defectos, puedes decidir mejor cmo encontrar y corregir los defectos. El rendimiento y las medidas de eliminacin de defectos se discuten en este captulo, y en los siguientes captulos se muestra cmo se utilizan estas medidas.
16.3
EL TIEMPO DE ELIMINAR DEFECTOS

Con programas de unas pocas docenas a cientos de LOC, probablemente introducirs pocos defectos. Aunque encontrarlos y corregirlos ser una molestia, llevar poco tiempo. Con grandes programas, sin embargo, el tiempo necesario es mucho mayor. Por ejemplo, 250 ingenieros del sistema NT de Microsoft dedicaron un ao completo a encontrar y corregir 30.000 defectos [Zachary]. Esto equivale a una media de 16 horas por defecto. En grandes sistemas, cuando el ingeniero que est desarrollando un programa no elimina todos los defectos introducidos, otro deber encontrarlos y corregirlos. Cuantos ms defectos haya y se corrijan posteriormente, mayores son los costes del trabajo de reparacin. Con grandes productos, estos costes pueden crecer de forma alarmante. Como se indic en el Captulo 13, un ingeniero puede encontrar y corregir un defecto en unos pocos minutos durante la revisin personal del cdigo. En las pruebas de unidad, los costes son varias veces superiores, oscilando el tiempo de 15 a 30 minutos. Los defectos que los ingenieros cometen en su trabajo personal, sin embargo, deben detectarse en pruebas posteriores y cuando el usuario utiliza el producto software. Entonces, lleva muchas horas encontrar y corregir cada defecto.
16.4
EXPERIENCIA EN LA INTRODUCCIN Y ELIMINACIN DE DEFECTOS

Los estudiantes y los ingenieros, normalmente introducen de 1 a 3 defectos por hora durante el diseo y de 5 a 8 defectos cuando escriben el programa. Solamente eliminan de 2 a 4 defectos por hora en las pruebas, pero
220
encuentran de 6 a 12 defectos por hora durante la revisin personal del cdigo. La Figura 16.1 muestra la tasa de introduccin de defectos para una clase de 14 ingenieros y la Figura 16.2 muestra la tasa de eliminacin de defectos. Antes de comenzar a escribir el programa 1, vase la parte izquierda de la grfica, los estudiantes no hacan revisiones de cdigo o seguimiento de las tasas de introduccin y eliminacin de defectos. Del programa 1 al programa 10, estos ingenieros aprendieron a calcular las tasas de introduccin y eliminacin de defectos, y fueron adquiriendo habilidad en los mtodos de eliminacin de defectos del PSP. Hay varios puntos interesantes en los datos de las Figuras 16.1 y 16.2. Primero, las tasas mostradas en dichas figuras, son los valores medios para los 14 ingenieros. Estos valores parecen razonablemente normales. La tasas individuales de los ingenieros son ms variables. Sus tasas personales, probablemente tendrn grandes variaciones de un programa al siguiente. Pero utilizando el PSP para controlar su trabajo, mejorarn inmediatamente. Los defectos eliminados por hora en las pruebas oscilan de forma consistente entre 2 y 4. Tasas similares se encontraron con estudiantes inexpertos y con ingenieros muy experimentados. La revisin de cdigo es una habilidad. Con la prctica, muchos ingenieros pueden alcanzar tasas de eliminacin de defectos de entre 8 a 10 defectos por hora. La clave est en utilizar los mtodos descritos en los Captulos 13 y 14.
Codificacin
10
O' 1
10
Nmero de Programa
Figura 16.1 Tasas de introduccin de defectos
221
+ Revisin & Pruebas
+Compilacin
o
1 2
10
Nmero de Programa
Figura 16.2 Tasas de eliminacin de defectos.
La gestin de defectos es un poco como trepar por una escalera que baja. Cuando diseas y codificas, introduces defectos. Conforme encuentras y eliminas estos defectos, dedicars ms tiempo a redisear y a codificar. Durante este tiempo, tambin introducirs ms defectos. Para ganar esta carrera, necesitas reducir la tasa de introduccin de defectos y aumentar la tasa de eliminacin. Para hacer esto, debes calcular y controlar las tasas de introduccin y eliminacin de defectos. Los datos reunidos con el PSP son todos necesarios para calcular las tasas de introduccin y eliminacin de defectos personales.
16.5
AHORRO EN LA ELIMINACIN DE DEFECTOS

Entender las tasas de eliminacin de defectos es importante para grandes proyectos y puede ser til para los ingenieros software. Cuando ests desarrollando un programa de tamao moderado, y asumes que tus datos son similares a los de otros ingenieros, introducirs unos 1O0 defectos/KLOC, encontrars alrededor de 50 defectos/KLOC en la compilacin, y otros 40 defectos/KLOC en las pruebas de unidad. Como se muestra en la Tabla 16.1, esto significa que las 500 LOC de programa tendran un total de 50 defectos. De estos, 25 se encontraran en la compilacin, y con suerte otros 20 en las pruebas de unidad. Si no usas la revisin de cdigo, necesitaras alrededor de 2 horas para conseguir un programa libre de errores de compilacin y encontrar esos 25 defectos. Las pruebas de unidad necesitaran unas 10 horas para encontrar los 20
222
Tabla 16.1 Ejemplos de introduccin y eliminacin de defectos.

500 LOC
Sin PSP
10.000 LOC
Con PSP
Sin PSP
Con PSP
Defectos
Defectos Totales Encontrados en la revisin de cdigo Defectos que quedan
5 0 0 5 0
25
100 .0
50 0 30 0 20 0
1 5
1 0
O
100 .0
1 1 1
Encontrados en la compilacin
Encontradosenlapruebasdeunidad
Defectos que queda
1 1
1
25
2 0 5
1 1
1
5
4
1
1 1
50 0 40 0
1 1
10 0
80
11001
2 0
1 1 1
Tiempo (horas)
Tiempo de revisin de cdigo Tiempo de compilacin
0 2
25
05
O
4 0
5 0 1 0
Tiempo de pruebas de unidad Tiempo personal de eliminacin de defectos Tiempo de integracin y pruebas del sistema
1 0
1 2
2
5
200
240
40
~~~ ~
10 0 20 0
100 .0
Tiempo total de eliminacin de defectos
1 2
120 .4
300
defectos esperados. Es decir, un total de 12 horas dedicadas a la eliminacin de defectos. Despus de aprender del PSP, solamente introduciras alrededor de 50 defectos por KLOC (25 defectos). Con las revisiones de cdigo, encontraras entre el 60 y el 70% de estos defectos antes de la primera compilacin. De esta forma, la compilacin supone unos 30 minutos y quedan de 4 a S defectos que se han de encontrar en las pruebas de unidad. Las pruebas suponen alrededor de unas 2 horas. Suponiendo que dedicas unas 2,5 horas a la revisin de cdigo, el tiempo total para la eliminacin de los defectos sera de unas 5 horas. Esto supone un ahorro de 7 horas. Aunque no pueda parecer mucho esfuerzo, reducir el tiempo de eliminacin de defectos en 7 horas para un trabajo de varios das, considera cmo se multiplican estos nmeros. Si en vez de un programa de SO0 LOC, desarrollsemos uno de 10.000 LOC, comenzaras con 1000 defectos. Con un entrenamiento en el PSP, seran solo 500 defectos. Si dedicas SO horas a la revisin de cdigo, reduciras el tiempo de compilacin de 40 a 1O horas y el tiempo de pruebas de unidad de 200 a 40 horas. Las 140 horas que ahorras son equivalentes a varias semanas de trabajo.
223
De mayor significado, es el coste de los defectos que t no encontraste en tu proceso. En el caso de las 500 LOC, los defectos eran unos pocos. Con el Componente ms grande, alrededor de unos 100 defectos ocultos se encontraran en las pruebas y muchos ms por el usuario. Encontrar esos 100 defectos llevara normalmente unas 1000 horas. Con el proceso del PSP, solamente se dejaran unos 20 defectos que se encontraran ms tarde en las pruebas, reduciendo el tiempo de las pruebas en unas 800 horas. Para ver lo que esto puede significar en la prctica, supn que t y otros cuatro ingenieros desarrollis un producto software de 50.000 LOC. Puedes planificar que cada uno desarrolla un componente de 10.000 LOC y posteriormente se integra y prueba el sistema completo. Basndonos en los datos tpicos de un ingeniero, t y tus compaeros probablemente introduciris unos 100 defectos/KLOC en el programa. Esto significa que habr que encontrar y corregir 5000 defectos. Utilizando tasas normales, unos 2500 de estos defectos se encontrarn durante la fase de compilacin y otros 2000 en las pruebas de unidad personales. Esto nos deja unos 500 defectos a detectar en la integracin y pruebas del sistema. Asumiendo que tu producto era ms sencillo que el NT de Microsoft, puedes encontrar estos defectos a un coste medio de solo unas 10 horas. Eliminar estos defectos le supondra a tu equipo de cinco personas unas 5000 horas. Si el equipo no hace ms de 40 horas semanales, esto sera un trabajo de 6 meses. Si hubieses revisado personalmente todo tu trabajo y dejas que el equipo inspeccione tus programas, podras ahorrarte al menos cinco meses de pruebas. Para un proyecto de dos aos, esta diferencia en el tiempo de pruebas podra ser la diferencia entre entregar a tiempo el producto o sufrir un serio retraso.
16.6
EL CLCULO DE LOS DEFECTOSlHORA EN EL RESUMEN DEL PLAN DEL PROYECTO DEL PSP
La Tabla 16.2 muestra cmo se calculan las tasas de eliminacin de defectos Hasta la Fecha en la tabla Resumen del Plan del Proyecto. Para cualquier fase, comienza con el nmero de defectos introducidos Hasta la Fecha en esa fase y el nmero de minutos dedicados Hasta la Fecha en dicha fase. A continuacin calcula los defectodhora introducidos Hasta la Fecha de esta forma: O*(defectos introducidos Hasta la Fecha en una fase)/(minutos dedicados Hasta la Fecha en esa fase). Los defectos eliminados por hora se calculan as: 60*(defectos eliminados Hasta la Fecha en una fase)/(minutos dedicados Hasta la Fecha en esa fase). En el ejemplo de la Tabla 16.2, estos clculos se muestran en la columna de la derecha de las secciones de Defectos introducidos y Defectos eliminados. Estos clculos se hacen como se muestra a continuacin.
224

5r. Z
Estudiante x
Fecha Programa# Lenguaje

Plan Real
2/19 81/6 1 4
Ada
Resumen MinutosiLOC LOClHora DefectosiKLOC Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmorten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
5,73 1,7 04 96,90 33,3 67 05 4 9

Plan Real
4,65 1,0 29 7, 79 80,O 7 7
Hasta la Fecha 5,40 1,5 09 92,53 40,O
335
2 3
32
Hasta la Fecha 10 2
% Hasta la Fecha
24 62 4 1 384 407
781
8 39 4 6 350
10 0 29 7 206 13 07
65 1, 06 4, 3l 7,9 5,5 12 5
1 1 2
100,o
Plan
Actual
1
4
1

5 2 5
Def.iHora
1. . 1 61 80,7
15 .4 , 18 ,9
6 Plan
5 Actual
3 1 100,o Hasta la Fecha % Hasta la Fecha
DeliHora
3
1
1 2 1 3 6 3 1
38,7 4, 19 1, 94 100,o
4,97 7,80 123 ,5
Para los defectos introducidos por hora:

Defectos introducidos Hasta la Fecha en la fase de diseo
= 60*(defectos introducidos Hasta la Fecha en el diseo)/(minutos dedicados Hasta la Fecha al diseo) = 60*5/195 = 1.54
225
Defectos introducidos Hasta la Fecha en la fase de codificacin

= 60*(defectos introducidos Hasta la Fecha en la codifica-
cin)/(minutos dedicados Hasta la Fecha a la codificacin)

= 60*25/792
= 1,89
Aunque podras calcular las tasas de introduccin de defectos para las otras fases, estas dos fases que hemos visto son las ms importantes. Para la tasa de eliminacin de defectos tenemos: Defectos eliminados Hasta la Fecha en la fase de revisin de cdigo
= 60*(defectos eliminados hasta la Fecha en la revisin de cdi-
go)/(minutos dedicados Hasta la Fecha a la revisin de cdigo)

= 60*12/145
= 4,97
Defectos eliminados Hasta la Fecha en la fase de compilacin

= 60*(defectos eliminados hasta la Fecha en la compilacin)/
(minutos dedicados Hasta la Fecha a la compilacin)

= 60*13/100
= 7,80
Defectos eliminados Hasta la Fecha en la fase de pruebas

= 60*(defectos eliminados Hasta la Fecha en las pruebas)/(mi-
nutos dedicados Hasta la Fecha a las pruebas) = 60*6/279 = 1,29 Aunque estos clculos se realizan solamente para los valores de Hasta la Fecha, podras calcular, si lo deseas, los defectos por hora para los datos planificados y reales. Observa que estos valores cambiarn conforme cambies tu proceso. Tambin, el nmero de defectos es un poco inferior al que debera ser, puesto que no se registraron los datos de defectos de los primeros programas. Las instrucciones para actualizar el Resumen del Plan del Proyecto se muestran en la Tabla 16.3.
16.7
EL CLCULO DEL RENDIMIENTO EN EL RESUMEN DEL PLAN DEL PROYECTO

Cuando eliminamos defectos en una fase, nos gustara saber cuntos se encontraron y cuntos quedaron ocultos. Aunque no hay forma de saber esto durante el desarrollo, los datos de procesos histricos pueden ayudar a tener una ligera idea. La forma de hacer esto es calcular y controlar el rendimiento. Para el PSP, definimos el rendimiento del proceso como la tasa de defectos encontrados antes de la primera compilacin y las pruebas.
226
Tabla 16.3 Instrucciones del resumen del plan del proyecto del PSP
Propsito Cabecera Esta tabla trata los datos estimados y reales de los proyectos de una forma cmoda y fcilmente recuperable. Introduce los siguientes datos: Tu nombre y fecha de hoy. Nombre y nmero de programa. Nombre del profesor. El lenguaje que utilizars para escribir el programa.
Minutos/LOC
Antes de iniciar el desarrollo: Escribe los Minutos/LOC planificados para este proyecto. Utiliza la velocidad Hasta la Fecha de un programa reciente del Cuaderno de Registro de Trabajos o del Resumen del Plan del Proyecto. Despus del desarrollo: Divide el tiempo total de desarrollo por el tamao real del programa para obtener los MinutosiLOC reales y los Minutos/LOC Hasta la Fecha. Por ejemplo, si el proyecto se hizo en 196 minutos e hiciste 29 LOC, los Minutos/LOC seran 196/29= 6,76.
LOCiHora
Antes de iniciar el desarrollo: Calcula las LOC por hora planificada para este programa dividiendo 60 por los Minutos/LOC de la casilla de Plan. Despus del desarrollo: Para LOC/Hora Real y Hasta la Fecha divide 60 por Minutos/LOC Reales y Hasta la Fecha. Para los 6,76 Minutos/LOC Reales, tenemos 60/6,76 = 8,88 LOC/Hora Reales. Antes de desarrollar: * Encuentra los defectos/KLOC Hasta la Fecha del programa ms reciente. Utiliza dicho valor como los defectos/KLOC planificados. Despus del desarrollo: Calcula los valores de defectos/KLOC reales y Hasta la Fecha para este programa. Para el valor real, multiplica el total de defectos reales por 1000 y divdelo por las LOC Reales Total Nuevas & Cambiadas. Para el valor Hasta la Fecha haz unos clculos similares. * Con 17 defectos Hasta la fecha y 153 LOC Total Nuevas & Cambiadas, los defectos/KLOC Hasta la Fecha = 1000*17/153=111,11
Defectos/KLOC
Rendimiento
Calcula el rendimiento planificado, real y Hasta la Fecha. Rendimiento = 100* (defectos eliminados antes de compilar) / (defectos introducidos antes de compilar), as6 con 5 defectos introducidos y 4 localizados, el rendimiento = 100*45=80,0%
(Contina)
227
Tabla 16.3 Instrucciones del resumen del plan del proyecto del PCP.
(Continuacin)
Tamao Programa Antes de iniciar el desarrollo. WC) Escribe bajo la columna plan, el valor estimado de LOC Total Nuevas & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y escribe las LOC Nuevas & Cambiadas Reales. Para la columna Hasta la Fecha, aade LOC Reales Nuevas & Cambiadas a las LOC Hasta la Fecha Nuevas & Cambiadas de programas anteriores. ___ _ _ ~ Tiempo por Fase Para el tiempo total de desarrollo , multiplica el valor de las LOC Plan Total Nueva & Cambiada por los Minutos/LOC. Para el tiempo Mximo, multiplica el tamao Mximo por los Minutos/LOC. Para el tiempo Mnimo, multiplica el tamao Mnimo por los Minutos/LOC. Del Resumen del Plan del Proyecto de un programa reciente, busca los valores de % Hasta la Fecha para cada fase. Utilizando el % Hasta la Fecha de programas anteriores calcula el tiempo planificado para cada fase.
~
Real
Una vez acabado el trabajo, anota el tiempo real en minutos que has gastado en cada fase del desarrollo. Obtn estos datos del Cuaderno de Registro de Tiempos. Para cada fase, escribe la suma del tiempo real y el tiempo Hasta la Fecha de los programas ms recientes.
Hasta la Fecha
% Hasta la Fecha Para cada fase, escribe 1O0 multiplicado por el tiempo Hasta la Fecha y lo divides por el total del tiempo Hasta la Fecha.
Defectos Introducidos Plan
Antes del desarrollo, estima el nmero total de defectos a introducir en el programa. El valor es: defectos/KLOC planificados multiplicado por las LOC Total Nuevas & Cambiadas planificadas para este programa y divido por 1000. Por ejemplo, con un valor de defectos/KLOC planificado de 75,9 y un valor de LOC Nuevas & Cambiadas planificadas de 75, el total de Defectos Planificados = 75,9*75/1000=5,69, se redondea a 6. Antes de desarrollar, estima los defectos introducidos por fase utilizando el total de defectos estimados y el o/o Hasta la Fecha de defectos introducidos de programas anteriores. Despus del desarrollo, localiza y anota el nmero real de defectos introducidos en cada fase. Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes. la Fecha para esa fase y divdelos por el total de defectos Hasta la Fecha.
Real Hasta la Fecha
% Hasta la Fecha Para cada fase, multiplica por 1O0 los defectos Hasta
228
Defectodhora Calcula los defectos introducidos por hora para la fase de diseo y codificacin. Para la fase de diseo, por ejemplo, se multiplica 60 por los defectos de diseo Hasta la Fecha y se divide por el tiempo de diseo Hasta la Fecha = 60*5/195=1,54defectodhora. En la fila de total, escribe el total de defectos estimados. Utiliza los valores de o/o Hasta la Fecha de los programas ms recientes, calcula los defectos eliminados planificados por cada fast Despus del desarrollo, localiza y anota el nmero real de defectos eliminados en cada fase. Para cada fase, escribe la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes. para esa fase y divdelos por el total de defectos Hasta la Fecha. Defectodhora Calcula los defectos eliminados por hora para la revisin de cdigo, compilacin y pruebas. Para las pruebas, por ejemplo, multiplica 60 por los defectos de las pruebas Hasta la Fecha y divdelo por el tiempo de pruebas Hasta la Fecha = 60*6/279=1,29 defectodhora.
Defectos eliminados Plan
Real Hasta la Fecha
Yo Hasta la Fecha Para cada fase, multiplica por 1O0 los defectos Hasta la Fecha
Los clculos para el rendimiento Planificado, Real y Hasta la Fecha se muestran en la seccin resumen en la parte superior de la tabla Resumen del Plan del Proyecto (vase Tabla 16.2). Bajo la columna Planificado, por ejemplo, los valores de rendimiento del proceso se calculan de la siguiente manera:
Los defectos introducidos planificados antes de compilar son 1+5=6. Los defectos eliminados planificados antes de compilar son 2.
El valor planificado de rendimiento del proceso es: Rendimientoplanificado
= 100*(Plan de defectos eliminados antes de compilar)/(Plan de = 100*2/(1 = 100*2/6 = 33,396
defectos introducidos antes de compilar) + 5)
El valor del rendimiento real se calcula as: Rendimien toRea,

= 1OO*(Defectos eliminados reales antes de compilar)/(Defectos = 100*4/(1
introducidos reales antes de compilar) + 4)
229
= 100*4/5 = 80,0% y el valor Hasta la fecha:

RendimientoHasta
la Fecha
= 100*(Defectos eliminados Hasta la Fecha antes de compi= 100*12/(5 + 25) = 100*12/30 = 40,0%
lar)/(Defectos introducidos Hasta la Fecha antes de compilar)
Obsrvese que en la Tabla 16.2, se introdujo un defecto durante la compilacin. Puesto que el calculo del rendimiento del proceso concierne a la tasa de defectos eliminados antes de compilar, deberas considerar solamente los defectos introducidos y eliminados antes de la fase de compilacin. Cualquier defecto introducido en la fase de compilacin o pruebas no estaba en el programa durante la revisin del cdigo y no se incluye en los clculos de rendimiento del proceso.
16.8
LA MEJORA DE LAS TASAS DE ELIMINACIN DE DEFECTOS

Puedes mejorar rpidamente la tasa de eliminacin de defectos haciendo revisiones de cdigo. Una vez que has obtenido estos beneficios iniciales, las mejoras posteriores sern ms difciles de conseguir. Puesto que los cambios a los que se deben enfrentar los ingenieros software aumentan cada ao, no puedes permitirte dejar de mejorar. Algunas sugerencias de cmo mejorar tu tasa de eliminacin de defectos son: Fjate primero en el rendimiento. Recuerda, que el objetivo es eliminar todos los defectos. Tu primer objetivo debe ser alcanzar de forma consistente un rendimiento del 70% o superior. Haz revisin del cdigo antes de la primera compilacin. Como se indic en el Captulo 13, para alcanzar el mximo rendimiento posible, utiliza el compilador para comprobar la calidad de tu revisin de cdigo. Una vez que has conseguido de forma consistente un rendimiento adecuado, utiliza los mtodos descritos en los Captulos 13 y 14 para mejorar las tasas de revisin. Controla en la lista de comprobacin dnde se encuentran y se pasan por alto defectos y haz ajustes de forma peridica. Si en algn paso no encuentras o pasas por alto muchos defectos, considera eliminarlo. Cuando se pasan por alto defectos, considera aadir un paso en la lista de comprobacin que se centre especficamente en este tipo de defectos.
230
Recuerda que es una insensatez hacer lo mismo una y otra vez y esperar un resultado diferente [Brown]. Si no cambias la lista de comprobacin, pasars por alto los mismos defectos. Contina reuniendo datos de defectos y calculando el rendimiento y las tasas de introduccin y de eliminacin de defectos. Controla estos datos y experimenta con distintas aproximaciones para ver cules te ayudarn a mejorar. Un objetivo de este libro es que seas tan consciente de los costes y consecuencias de los defectos que personalmente llegues a estar comprometido a producir programas de alta calidad. Esto har que se ahorre tiempo. Tal y como se observa en la Figura 16.3, los estudiantes que controlaron y gestionaron su rendimiento y sus tasas de eliminacin de defectos, dedicaron menos tiempo a la compilacin y a las pruebas. Al principio del curso, en los programas 1 y 2, los 14 estudiantes dedicaron alrededor de un 30% de su tiempo a la compilacin y a las pruebas. Pero al finalizar el curso, cuando utilizaron consistentemente el PSP, el tiempo medio de compilacin y pruebas fue un 10% del tiempo de desarrollo.
O'
1
10
Nmero de Programa
Figura 16.3 Tiempo de compilacin y pruebas.
16.9
LA REDUCCIN DE LAS TASAS DE INTRODUCCIN DE DEFECTOS

Las tasas de introduccin de defectos son difciles de reducir puesto que se introducen defectos en cada parte del proceso. Por ello, necesitas considerar cada tarea del software. Algunas aproximaciones para reducir las tasas de introduccin de defectos son las siguientes:
231
1. Registrar todos tus defectos. Estando enterado de los defectos, trabajars ms cuidadosamente y reducirs el nmero de defectos que introduces.
2 Hacer mejores diseos. Haciendo diseos ms completos y mejor .

documentados, puedes mejorar la calidad de tus programas de dos formas. Primero, evitars aquellos defectos que podran resultar de un diseo confuso o incompleto. Segundo, un diseo ms completo te ahorrar tiempo de codificacin. Puesto que las tasas de introduccin de defectos son ms bajas durante la fase de diseo que durante la fase de codificacin, esto tambin reducir los defectos. Esta cuestin se discute en el Captulo 17.
3. Utilizar los mejores mtodos. Puesto que los defectos pueden introducirse en cualquier fase, las mejoras en la forma de desarrollar los requisitos, especificaciones, diseos, casos de pruebas y cdigo fuente ayudarn a reducir los defectos. Muchos cursos de ingeniera del software ensean mtodos tiles para estas actividades. Utilizando el PSP y midiendo tu trabajo con estos mtodos, puedes ver cmo funcionan para ti.
4. Utilizar herramientas mejores. Si una herramienta ahorra tiempo, probablemente reducir el nmero de defectos que se introducen. Cada ao se desarrollan nuevas herramientas de software y los datos del PSP permitirn medirlas y evaluarlas. Puedes ver cul te ayuda y cunto.
RESUMEN
Los defectos son una de las principales causas de los problemas del software. Su correccin supone un coste econmico y un retraso en la planificacin del proyecto. Puesto que los tiempos dedicados a corregir defectos son impredecibles, los defectos tambin reducen la precisin de la planificacin. La gestin de defectos puede, de esta forma, verse como una cuestin econmica. Este captulo explica las consecuencias econmicas de los defectos e introduce medidas para ayudar a gestionar los defectos en los programas que hagas. Hasta los ingenieros experimentados introducen muchos defectos. El coste de encontrarlos aumenta unas 10 veces en cada fase posterior a la compilacin. Las tasas tpicas de eliminacin de defectos muestran que las pruebas son una forma ineficiente de eliminar defectos. En las pruebas de unidad, los ingenieros solamente encuentran de 2 a 4 defectos por hora. En la revisin de cdigo, encuentran y corrigen de 6 a 12 defectos por hora. Los compiladores son muy eficientes para encontrar defectos sintcticos, pero no encontrarn todos los defectos sintcticos de tu programa.
232
El tiempo para encontrar y corregir cada defecto pasado por alto en un proceso personal llevar varias horas entre la integracin, las pruebas del sistema y la utilizacin del producto. Para mejorar tu efectividad en encontrar y corregir defectos, se han introducido dos nuevas medidas: los DefectodHora que miden la eficiencia de la fase para introducir y eliminar los defectos. En el PSP, el rendimiento del proceso mide la tasa de defectos eliminados antes de la primera compilacin. Para ver dnde y cmo mejoras tu proceso, calcula las tasas de introduccin y eliminacin de defectos y el rendimiento del proceso.
EJERCICIO 16
Para cada uno de los programas que has escrito en este curso, encuentra la tasa de defectos introducidos Hasta la Fecha en las fases de diseo y codificacin y la tasa de defectos eliminados Hasta la Fecha para la revisin de cdigo, compilacin y pruebas. Tambin calcula el rendimiento del proceso para cada uno de estos programas. Calcula y entrega estos valores junto con un breve resumen que describa las implicaciones de estos datos para ti. Entrega copias del Cuaderno de Registro de Tiempos y de las hojas del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega copias completas del Resumen del Plan del Proyecto, del Cuaderno de Registro de Defectos y de la Lista de Comprobacin para la Revisin de Cdigo para cada programa que desarrolles. Incluye los valores Planificados, Reales y Hasta la Fecha de los tiempos de desarrollo, de los defectos introducidos, de los defectos eliminados y del rendimiento.
REFERENCIAS
[Brown] Brown, Rita Mae. Comunicacin privada. [Humphrey 891 Humphrey, W.S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989. [Zachary] Zachary, G. Pascal. Showstopper! New York: The Free Press, 1994.
CAPTULO 17
Defectos de diseo
Este captulo trata sobre los defectos de diseo, el proceso de diseo y las representaciones del diseo. Tambin trata los mtodos para reducir el nmero de defectos de diseo que introduces. La cuestin principal en la gestin de los defectos de diseo es comprender cundo y cmo los introduces. Como ejercicio, analizars los defectos de diseo en tus programas y determinars cundo y por qu se introdujeron.
17.1
LA NATURALEZA DE LOS DEFECTOS DE DISEO

Muchos de los defectos que encuentras en las pruebas, probablemente fueron introducidos durante la fase de codificacin. Esto implica que el principal problema del defecto est relacionado con simples errores de codificacin. De hecho, de los defectos que encontraron en las pruebas los 14 estudiantes de uno de mis cursos, introdujeron la mitad de defectos en la fase de diseo que durante la fase de codificacin. Puesto que el compilador haba eliminado muchos de los errores sintcticos, esto pareci un poco sorprendente. Como se muestra en la Tabla 17.1, esta proporcin cambi cuando los estudiantes aprendieron el PSP. De los defectos encontrados en las pruebas, los estudiantes comenzaron a introducir una vez y media ms defectos en la codificacin que los introducidos durante el diseo. Hacia el final del curso, introdujeron un promedio de solamente un 14 % ms. Aunque redujeron el nmero de defectos introducidos en am-
234
DEFECTOS DE DISEO
bos casos, la mejora fue algo menor para los defectos introducidos durante el diseo. Obsrvese que los valores de la Tabla 17.1 se refieren a las fases donde los defectos fueron introducidos. Si examinamos los tipos de defectos, la cuestin es diferente. En el PSP, los tipos de defectos estn ordenados por grado de sofisticacin del problema, los tipos del 10 a 20 son los ms sencillos y los tipos del 90 a 100 los ms complejos. Podemos decir que los tipos del 10 al 40 son defectos sencillos o de codificacin, y los tipos del 50 a 100 son defectos ms complejos o de diseo.
Tabla 17.1 Defectos de pruebas introducidos en las fases de diseo y programacion.
Diseo DefectodKLOC
Ejercicio 1 Ejercicio 1 O
Codificacin DefectodKLOC
Relacin de defectos codificacin y diseo
8,66
5,055
12,99 5,77 55,56%
150 ,5 1,14
YoReduccin
41,67Yo
Si clasificamos estos mismos defectos de pruebas por tipos, obtendremos la Tabla 17.2. Aqu, la mayor parte de los defectos de pruebas son del tipo diseo, pero muchos de ellos se introdujeron durante la codificacin. Aunque estos ingenieros haban reducido bastante el nmero de defectos introducidos, cometieron muchos de sus errores de diseo durante
Tipo Diseo Defectos/KLOC
Tipo Codificacin Defectos/KLOC
% de defectos
de Diseo
Fase de diseo Fase de codificacin

~
7,22 9,38
~
1,44 3,61
5,05
83,33% 72,22% 76,67%
____
Total Ejercicio 10 Fase de diseo Fase de codificacin Total
1659
3,61 3,61 7,22
1,44 2,16 3,61
71,43% 62,50% 66,67%
Tasa de Reduccin Fasedediseo
1
50,00%
I
61,54% 56,52%
I
oYo
40,00% 28,57%
1 1 1
1 Fase de codificacin 1 Total 1
1 1 1
I 1 1
I I I
235
la fase de codificacin. Como vimos en el Captulo 16, los mismos ingenieros introdujeron de 5 a 8 defectos por hora durante la codificacin y solamente de l a 3 dcfectos por hora durante el diseo. Esto sugiere que una forma potencialmente efectiva para introducir pocos defectos de diseo sera dejar de hacer el diseo durante la fase de codificacin. En este captulo se trata este problema y cmo abordarlo.
17.2
IDENTIFICACIN DE LOS DEFECTOS DE DISEO

Podemos pensar que todos los defectos detectados por un compilador deberan clasificarse como defectos de codificacin. Esto implica que los defectos no detectados por el compilador son defectos de diseo. Desafortunadamente, este no es el caso. Los mejores compiladores no encuentran todos los defectos sintcticos, y algunos errores de diseo tambin podran producir una sintaxis incorrecta. La razn de que los compiladores no encuentren todos los defectos sintcticos, se debe a que algunos errores de sintaxis, producen cdigo que tiene validez sintctica para el compilador. Por ejemplo, al teclear podemos equivocarnos, pero casualmente introducir caracteres que sean vlidos para el lenguaje. Esto supone alrededor del 10% de todos los defectos sintcticos. Un ejemplo de esto, sera poner x = y cuando t pretendes escribir x == y. El compilador de C++ no detectara este error. Entonces, en vez de hacer la comprobacin lgica de si x es igual a y, el programa asignara a x el valor de y. De forma similar, en Ada o Pascal, podras tener el mismo problema cuando escribieses errneamente x := y, en vez de poner x = y. Aunque estos errores no se consideran errores de diseo. Hacen que la lgica del programa sea incorrecta.
No hay forma sencilla y objetiva de definir los defectos de diseo. Las dos elecciones son:
Definir todos aquellos defectos introducidos en la fase de diseo como defectos de diseo. Definir aquellos tipos de defectos que implican cuestiones de funciones de codificacin, lgica, rendimiento y sincronizacin como defectos de diseo. En este libro, seguimos la segunda definicin.
17.3
QU ES DISEAR?
Para considerar los defectos de diseo, es importante definir qu entendemos por diseo. Esta cuestin no es fcil. La razn, es que cualquier co-
236
DEFECTOS DE DISEO
sa relacionada con la estructura e implementacin de un programa est relacionada con el diseo. Esto incluye el flujo del programa, la estructura y naturaleza de los elementos del lenguaje, el uso de los smbolos de separacin en el cdigo fuente. Aunque todo lo anterior es parte del diseo, lo es en diferentes grados de detalle. El problema es que el diseo es una cuestin de perspectiva. Puedes disear en detalle o a alto nivel. Cuando desarrollamos programas, hacemos algo de diseo en cada paso. Si se implementan los detalles de una sentencia case o de un bucle, especificamos el diseo detallado. Cuando definimos una estructura de datos o establecemos un mdulo de interfaz, estamos trabajando a alto nivel. La divisin entre diseo y codificacin es un poco arbitraria. Los ingenieros software, normalmente encuentran til dividir sus actividades de acuerdo al nivel de detalle implicado en su trabajo. Esto les ayuda a centrarse sobre las cuestiones adecuadas en el orden correcto. Por ejemplo, los ingenieros cometen pocos errores y son ms eficientes cuando piensan los diseos antes de implementarlos. Esto no significa que hagan todo su trabajo de arriba a bajo. Significa que normalmente comienzan con un concepto de alto nivel antes de entrar profundamente en detalle. El trmino que utilizamos para describir una aproximacin conceptual de alto nivel, es abstraccin. As, cuando hablamos de la abstraccin funcional raz cuadrada, estamos hablando de un procedimiento que calcula la raz cuadrada. En este nivel, no nos preocupamos de los detalles para calcular la raz cuadrada. Siguiendo esta estrategia de abstraccin, los ingenieros pueden hacer diseos completos de alto nivel antes de profundizar en el embrollo de detalles de cmo se construye cada abstraccin o funcin. As, por ejemplo, puedes comenzar a disear un programa sencillo, definiendo cuatro funciones abstractas o procedimientos: Entrada, Fichero, Calcular y Salir. Podras disear la rutina del programa principal utilizando estas abstracciones. Aunque t tambin podras tener definidas las variables principales y los ficheros, es posible completar el diseo de alto nivel del programa utilizando estas abstracciones funcionales. El siguiente paso sera disear cada una de estas abstracciones. En grandes programas, podras tener varios niveles de abstraccin y podras construir una librera de abstracciones previamente desarrolladas para utilizarla en futuros programas.
17.4
EL PROCESO DE DISEO
Haciendo lo que ellos llaman diseo, los ingenieros experimentados, a menudo, se mueven dinmicamente entre niveles de diseo [Curtis]. La
237
razn es que ellos estn tratando con muchas abstracciones funcionales. Antes de que se sientan cmodos utilizando estas abstracciones en un diseo de alto nivel, generalmente necesitan conocer cmo funcionan dichas abstracciones. Si han utilizado anteriormente dichas funciones, pueden diferir la definicin de los detalles. Si no han trabajado nunca con dichas abstracciones, a menudo, se detendrn y completarn su diseo detallado. Pueden escribir y probar un prototipo antes de estar suficientemente satisfechos como para continuar con el diseo de alto nivel. Los diseadores experimentados hacen esto porque han aprendido que las abstracciones aparentemente sencillas, a menudo, tienen sutiles complicaciones. As, cuando utilizan una abstraccin que no saben cmo construir, frecuentemente encuentran que el trabajo es ms difcil de lo esperado. Ocasionalmente, en efecto, cuando los diseos del sistema estn basados en abstracciones aparentemente simples, pero mal definidas, se encuentra que la aproximacin al diseo global no es factible. La nocin de abstraccin es muy til cuando se trata con funciones conocidas y definidas. Cuando utilizas esta aproximacin conceptual para definir lo ms arduo del trabajo de diseo, es fcil no tener problemas. Los ingenieros experimentados son reacios a utilizar cualquier abstraccin en un diseo de alto nivel, a menos que previamente hayan trabajado con funciones similares o tengan una implementacin que sepan cmo funciona. La distincin entre diseo y codificacin es as arbitraria. Esto tambin significa que la especificacin de qu constituye un diseo completo es arbitraria. Por lo tanto, es importante distinguir entre el proceso de diseo y la fase de diseo especfico en el PSP. La fase de diseo comienza cuando realizas el producto que llamas diseo. El proceso de diseo describe las tareas necesarias para elaborar este producto. Hasta cierto punto, estamos definiendo diseo como lo que hacemos en la fase de diseo. Esto, probablemente parece tan til como definir pensamiento como lo que la gente hace cuando piensa. A menudo, es til definir actividades en trminos de los productos que obtienes. Posteriormente en este captulo discutiremos cmo representar el producto del diseo.
17.5
LAS CAUSAS DE LOS DEFECTOS DEL DISEO

Los defectos del diseo son causados por varios problemas. El primero es un diseo errneo. Has trabajado seriamente sobre el problema y tomas una decisin de diseo que era errnea. Quizs no se comprendi una funcin matemtica, se dise un bucle bajo en condiciones errneas, o se ignor alguna condicin del sistema. Puedes haber estado escasamente informado, cansado o inadecuadamente entrenado. A pesar de todas las causas, has tomado conscientemente una decisin de diseo pero incorrecta.
238
DEFECTOS DE DISEO
Una segunda causa sera, conociendo el diseo que haba que hacer, cometes un simple error. Puedes pensar terminar un bucle bajo ciertas condiciones pero olvidas incluir todos los casos. Esto podra ser un descuido o una tontera. Sabas qu hacer y cmo hacerlo, pero cometiste un error tonto. Estos errores son ms comunes cuando tienes prisas o ests cansado. Una tercera causa de los defectos de diseo es una mala comprensin de lo que se quera. Tanto si has interpretado mal el diseo de alto nivel o no has entendido los requisitos. En cualquier caso, se hace un diseo incorrecto. Realmente el diseo era correcto en el sentido que realizaba la funcin que pretendas, pero implementaste la funcin errnea. Otra causa parecida a la ltima es cuando se entiende el diseo local y el del sistema, es decir, se comprende los requisitos pero no se entiende el contexto del sistema. Esto es lo que denomin el problema de interpretacin literal. Por ejemplo, cuando pides a alguien que explique la expresin derramar las judas, obtendrs diferentes respuestas dependiendo a quin preguntes. Alguien que entienda el ingls coloquial tal y como se habla en Estados Unidos la interpretar como decir un secreto, mientras que alguien que est aprendiendo ingls en otro pas puede decir que significa tirar la comida. Este es un problema en el software, porque muchas decisiones de diseo implican detalles que afectan a los usuarios del sistema. Cuando los diseadores no han conocido profundamente el contexto del usuario, es probable que interpreten los requisitos de forma literal, sin entender sus implicaciones desde el punto de vista operativo. Aunque dichos sistemas, normalmente cumplen todos los requisitos establecidos, generalmente son poco prcticos y algunas veces es imposible utilizarlos. Sorprendentemente, los errores de diseo provienen de un exceso de confianza. El ejemplo comn sera una o dos lneas corregidas en un gran programa. Puesto que dichos cambios son pequeos, los ingenieros normalmente piensan que son sencillos y no debe llevar mucho tiempo entender realmente el problema o las implicaciones de la correccin. Aunque estos errores podran ser clasificados en cualquiera de las categoras anteriores, normalmente se ubicaran entre la tercera o cuarta: incomprensin o errores de contexto.
17.6
EL IMPACTO DE LOS DEFECTOS DE DISEO

Un ejemplo de problema de diseo comn es aquel que me expuso una directora de desarrollo en IBM. Ella haba odo por casualidad a dos ingenieros debatir sobre cmo debera ser implementada una funcin de un programa. Aunque ninguno de los dos saba con exactitud qu era lo que el cliente quera, tenan diferentes opiniones. En vez de informarse sobre
239
lo que se quera, se comprometieron en una tercera interpretacin. Cuando los ingenieros toman decisiones de diseo sin estar bien informados, a menudo, producen diseos poco prcticos y posiblemente no operativos.
Aunque todas estas causas son reales y contribuyen al nmero total de defectos de diseo, el mayor nmero de defectos proviene de simples descuidos, tonteras y malentendidos. La razn de que estas causas excedan en nmero a todas las dems, es porque, cuando los ingenieros software se enfrentan a un nuevo diseo del problema, normalmente tienen un cuidado especial. Saben que podran fcilmente cometer un error y procuran comprobar su trabajo. Puesto que los ingenieros software cometen muchos errores simples y dichos errores pueden ser complicados de encontrar, estos simples defectos son una de las causas de muchos problemas. Dichos defectos logran pasar los procesos de diseo y pruebas y llegan a los usuarios del sistema. Estos defectos triviales causan muchos de los problemas que los usuarios tienen con los sistemas de software. Resulta que muchos de estos defectos son evitables. El ingeniero saba que esto era lo deseable. El diseo fue adecuadamente concebido, pero pobremente representado. As, cuando lleg el momento de desarrollar el cdigo, el programador no pudo ver lo que se pretenda. Antes que detenerse y buscar al diseador, muchos programadores completan el diseo precipitadamente sobre la marcha. Puesto que estn trabajando en la implementacin, a menudo no entienden todas las implicaciones del diseo. As, es muy probable cometer un error. Aunque el diseador saba lo que quera, el programador no. Tambin puede haber un malentendido cuando ests implementando un diseo ideado por ti mismo. Cuando ests haciendo un diseo, a menudo buscars un punto a partir del cual el resto del diseo parezca obvio. Si tambin ests planificando que hars el cdigo, parece poco razonable documentar esta parte para el diseo. Desdichadamente, ms tarde durante la implementacin, puede que no recuerdes una cosa obvia del diseo y vuelvas a disear otra vez. Puesto que probablemente habrs olvidado el contexto del diseo, debes reconstruir todos los conceptos y condiciones relevantes del diseo. Puesto que este proceso de reconstruccin es propenso a errores, probablemente cometers errores de diseo. La causa del error no fue una pobre implementacin, sino que fue un diseo representado de manera muy pobre.
17.7
REPRESENTACIN DEL DISEO

Una clara y completa representacin del diseo te ayudar a reducir el nmero de defectos introducidos. Esto significa que una vez que has realizado el diseo, necesitas representarlo para que est claro para cualquier
240
DEFECTOS DE DISEO
persona que lo implemente. Esta es una cuestin crtica con programas de 10.000 LOC o ms y puede ser un problema con mdulos de programa de 50 a 100 LOC. Representando completamente el diseo cuando lo crees, probablemente ahorrars tiempo. Esto es debido a que puedes producir mucho ms rpidamente a partir de un diseo completo y claro, que a partir de uno vago e incompleto. Puesto que un menor tiempo de codificacin implica pocos defectos de codificacin, con un buen diseo es ms probable que hagas un programa de calidad superior. Hay tres formas comunes de representar los diseos: grficamente, con un seudocdigo o matemticamente. En las siguientes secciones de este captulo discutimos estos mtodos de representacin. Aunque esto es un tema muy extenso y se podra decir mucho sobre el mismo, este breve tratamiento te dar algunas ideas sobre el diseo de mdulos de programas. Tambin proporciona un contexto para pensar sobre el diseo, conforme utilizas el PSP en el futuro. El objetivo aqu, no es ensear mtodos de representacin, sino convencerte de la importancia de hacer un diseo y de representarlo de forma clara. As, cuando te enseen varios mtodos de representacin en cursos o en el trabajo, podrs valorar por qu son importantes y tendrs en cuenta probarlos.
REPRESENTACIONESGRFICAS DEL DISEO

Las personas generalmente entienden las imgenes con ms rapidez que las frmulas o el texto. Cuando describes un diseo complejo, una imagen ilustrativa ayudar a las personas a entenderlo. Puesto que una gran parte del problema del diseo tiene que ver con la comprensin deberas, en general, utilizar representaciones grficas para extender el diseo. La forma ms comn de representacin grfica es el diagrama de flujo. Este es un diagrama con las funciones del programa representadas por cajas y la lgica del programa fluye representada por lneas que unen las cajas. Aunque hay muchas formas de dibujar dichos diagramas, describiremos los smbolos del diagrama de flujo tal y como se muestran en la Figura 17.1. Un sencillo ejemplo de estos smbolos se muestra en la Figura 17.2 En la parte superior del diagrama, el smbolo conector muestra que la entrada x viene de 8 A x y en la parte inferior muestra que la salida y va a 3Ay y 5By.Los smbolos en los conectores se refieren a otras pginas del diseo. Con esta notacin, la variable x viene de la pgina 8 del diseo en el punto AX. De forma similar, la variable y va a los puntos Ay de la pgina 3 y al By de la pgina 5. La caja en la mitad de la Figura 17.2 muestra una funcin de decisin. Puedes representarla con una estructura if - then-elseo con una
241
Interconexiones
Funcin predefinido
definido
Figura 17.1 Smbolos de los diagramas.
x<o
Rutina-Error
4
x =o
Correccin-Cero
1 Salida-y
Figura 17.2 Ejemplo de diagrama lgico.
sentencia case.Esta eleccin se deja al programador. La caja que contiene, y = f (x , describe un clculo. ) Las dos cajas a izquierda y derecha de la Figura 17.2 representan funciones definidas. A la izquierda tenemos la caja de la funcin, R u t ina-Error, tiene dos barras verticales para representar una funcin predefinida. Esto se refiere a una funcin que ya ha sido implementada y es reutilizada en este programa. La caja de la derecha Correccin-Cero, tiene una lnea horizontal para representar una funcin definida. Esta es una nueva abstraccin funcional que ests definiendo y utilizars en este programa cuando est acabado.
242
DEFECTOS DE DISEO
Aunque las representaciones grficas son fciles de entender, a menudo, son imprecisas o voluminosas. Este no es un problema inherente al mtodo, pero es otro ejemplo de una representacin imprecisa e incompleta. Este problema de precisin puede ser tratado teniendo un diseo escrito completo y utilizando la representacin grfica para ayudar a explicar la lgica del programa. Recuerda, sin embargo, que cuanta ms informacin pongas en el diagrama, mayor desorden habr y ms difcil ser entenderlo. La mejor aproximacin a este problema es utilizar varios niveles de diagrama de flujo, donde cada nivel incluye abstracciones que estn definidas en diagramas de flujo de bajo nivel. Debido a sus ventajas, deberas utilizar una representacin grfica para ilustrar el diseo de cada programa que hagas. A menudo, el proceso de dibujar el diagrama de flujo revelar relaciones que no habas considerado. A pesar de cmo lo hagas, dichos diagramas pueden ahorrar tiempo y reducir la confusin cuando posteriormente implementes, pruebes, corrijas o mejores el programa.
REPRESENTACIONES DEL DISEO CON SEUDOCDIGO

El seudocdigo proporciona otra forma de representar la lgica del programa. Aqu, la aproximacin es escribir el programa en un lenguaje parecido al que utilizas para la implementacin, pero con una escritura que sea fcilmente comprensible para las expresiones complejas. La idea es representar la lgica pero ignorar muchos de los requisitos sintcticos del lenguaje de programacin. Un ejemplo de un seudocdigo para describir un diseo se muestra en la Tabla 17.3. Podras extender esta descripcin con sentencias adicionales para describir cmo se calcula la funcin f(x). Tambin podras aadir definiciones de tipos, declaraciones u otros detalles si fuesen necesarios en el momento de la implementacin.
Tabla 17.3 Ejemplo de representacin en seudocdigo.
a l g o r i t m o (Funcin c a l c u l o f ( x ) )
i f ( x < 0)
then (Rutina- Error) e l s e i f ( x = 0) t h e n (Correccin- Nula) else
Y =
end.
(x)
Una descripcin de diseo con seudocdigo es una mezcla de lenguaje humano y elementos de codificacin. En vez de utilizar una lgica
243
completa para definir bien las funciones, se utilizan sentencias sencillas. De forma similar, el flujo del programa puede representarse con sentencias condicionales tradicionales, utilizando expresiones escritas que describen la lgica. Aunque no hay un estndar de notacin de seudocdigo ampliamente aceptado, es una buena idea utilizar elementos del lenguaje que sean similares a aquellos que son utilizados en lenguajes de alto nivel. Cuando lo hagas, el seudocdigo parecer familiar en el momento de la implementacin y proporcionar un marco de trabajo para la misma. Debido a que el seudocdigo no requiere los detalles del lenguaje de programacin, es generalmente, ms fcil y rpido para trabajar, que hacer un programa fuente completo. Tambin, puedes documentar un diseo con muchos ms detalles de los que necesites. Esto facilita la captura del diseo cuando desarrollas por primera vez. Esto es cuando entiendes mejor el diseo y puedes registrarlo de una forma ms eficiente. La principal ventaja del seudocdigo es que es tan preciso como t necesites y es fcil de entender. La principal desventaja es que, un diseo en seudocdigo puede ser tan detallado que sea difcil de entender. Por eso, es una buena idea proporcionar tanto el seudocdigo como un diagrama de flujo para cualquier diseo por muy sencillo que sea. Un problema potencial con el seudocdigo es causado por el hecho de que omite mucha puntuacin y estructura, utilizada para definir totalmente el significado de un programa fuente. Es fcil cometer errores con elementos lgicos comunes. Por ejemplo, es una buena idea utilizar la sangra o la puntuacin para conectar cada sentencia else con el i f apropiado, o mostrar la extensin de los bucles o condiciones case. El mbito de las variables y los parmetros tambin puede causar confusin y debera ser cuidadosamente observado donde no es obvio. Un problema comn con el seudocdigo tiene que ver con el nivel de detalle. Muchos ingenieros escribirn una lnea de seudocdigo por cada 3 o 5 lneas de programa fuente acabado. Sin embargo, he visto casos donde los ingenieros han hecho una lnea de seudocdigo por cada lnea de cdigo fuente acabado. Aunque ellos pueden llamar a esto diseo, esto es realmente la implementacin en una forma menos rigurosa. Puesto que el simple acto de copia introduce defectos, diseando con tanto detalle se podra introducir ms defectos que codificando desde el principio. Debido a su flexibilidad, un diseo con seudocdigo puede estar en cualquier nivel de detalle. No hay forma de especificar con precisin qu debe contener un diseo con seudocdigo. Aunque las representaciones con seudocdigo pueden ser muy tiles, estamos an con el problema que tenamos al principio: cmo definir con precisin lo que se entiende por diseo. En efecto, una gran ventaja del seudocdigo es que permite al ingeniero especificar el nivel de detalle del diseo necesario para cada situacin.
244
DEFECTOS DE DISENO
Cuando ests utilizando el seudocdigo, los datos del PSP pueden ayudarte a decidir un nivel adecuado de detalle. Cuando se estn controlando datos de defectos, por ejemplo, si encuentras que ests introduciendo defectos del tipo diseo durante la fase de codificacin, piensa la utilizacin de un diseo ms preciso. A la inversa, si no has tenido problemas de representacin del diseo, puedes intentar utilizar un seudocdigo menos detallado para ver si aumentas la velocidad en tu trabajo de diseo, sin causar errores de diseo en la implementacin.
OTROS MTODOS DE REPRESENTACIN

Varios mtodos matemticos han sido ideados para definir con precisin sistemas software. Estos mtodos tienen la ventaja de ser precisos y la desventaja de ser muy difciles de aprender, al menos por ingenieros que no han tenido una formacin adecuada en matemticas. Los mtodos formales, sin embargo, ofrecen una gran promesa de ayudar a los ingenieros a hacer programas con un mnimo nmero de defectos [Gries]. Puesto que la representacin del diseo es un problema importante, indudablemente habr muchas ideas nuevas y aproximaciones. Si consideras utilizar varias representaciones, ten en cuenta los siguientes puntos: Disear es un proceso mental. Una notacin de diseo rica, puede ayudar a pensar con precisin y a representar un diseo complejo. Las notaciones ricas, sin embargo, son difciles de aprender. Cuando ests utilizando una notacin de diseo con la que no ests familiarizado, probablemente no pensars en esa notacin. Entonces debes pensar todo el diseo en una notacin familiar y traducirla mentalmente a la notacin no familiar. Este proceso de traduccin inhibe la creatividad, retarda el trabajo de diseo y causa errores. Cuando pruebes nuevos mtodos de diseo y notaciones, intenta utilizarlos con fluidez antes de evaluarlos. Tambin recuerda que la notacin de diseo es un medio de comunicacin. Si los implementadores no estn a gusto con la notacin, tendrn muchos problemas descritos anteriormente.
RESUMEN
La fuente de muchos defectos es la fase de codificacin. Una forma de reducir los defectos de diseo es analizar los tipos de defectos. Defi-
245
nimos los defectos de diseo como los tipos de defectos del PSP del 50 al 100. Si introduces muchos de estos tipos en la fase de codificacin, considera dedicar ms tiempo al diseo. Es importante hacer el diseo lgico y funcional en la fase de diseo y no durante la codificacin. Las representaciones de diseo precisas pueden ahorrar tiempo de implementacin y reducir los defectos de diseo. Una pobre representacin puede causar defectos. Las representaciones grficas son fciles de entender pero pueden ser imprecisas. Las representaciones con seudocdigo pueden estar a varios niveles de detalle y pueden utilizar un lenguaje que es similar al lenguaje de programacin utilizado. Al seleccionar una representacin del diseo, familiarzate con la representacin antes de hacer una evaluacin. Utiliza tus datos del PSP para hacer la evaluacin y tomar la decisin.
EJERCICIO 17
Como ejercicio, revisa los defectos que has encontrado en todos los programas de los que tengas datos de defectos. Utilizando los mtodos mostrados en las Tablas 17.1 y 17.2, muestra cul de estos defectos provienen de una representacin imprecisa del diseo y sugiere los pasos para prevenirlos. Para el trabajo de casa, lista el nmero de defectos de diseo por tipos de problemas y la representacin que podra haberlos previsto. Tambin indica el tiempo total de correccin que esta mejora podra ahorrar. Haz un seudocdigo y un diagrama de flujo para el prximo programa. Entrega los diseos con el programa, y escribe un breve comentario del impacto que estos mtodos de diseo han tenido en el nmero de defectos de diseo introducidos. Muestra los datos que llevan a estas conclusiones. Obsrvese que tanto los anlisis de defectos y los ejercicios de diseo son opcionales y no es necesario terminarlos a no ser que lo pida el profesor. Entrega copias del Cuaderno de Registro de Tiempos y de las hojas del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega copias completas del Resumen del Plan del Proyecto, del Cuaderno de Registro de Defectos y de la Lista de Comprobacin para la Revisin de Cdigo para cada programa que desarrolles. Incluye los valores planificados, reales y Hasta la Fecha, de los tiempos de desarrollo, los defectos introducidos, los defectos eliminados y el rendimiento.
246
DEFECTOS DE DISEO
REFERENCIAS
[Curtis] Curtis, Bill, Herb Krasner, and Neil Iscoe. A Field Study of the Software Design Process for Large Systems, Communicutions of the ACM, November 1988, vol. 31, no. 1 1 . [Gries] Gries, David. The Science o Progrumming. New York: Springerf Verlag, 1981.
CAPTULO 18
Calidad del producto
Este captulo discute cmo tu disciplina personal de trabajo afecta a la calidad de los productos que realizas. Ilustra la relacin entre el nmero de defectos que encuentras durante la compilacin y las pruebas, y el nmero de defectos que dejars en tus productos acabados. Describe los pasos que puedes hacer para mejorar la calidad de tus programas. Como ejercicio, examinars la relacin, entre el nmero de defectos de compilacin y el nmero de defectos de pruebas que tienes en los programas que has desarrollado en este curso.
18.1
LA CALIDAD VIENE PRIMERO

Como hemos visto. las pruebas son caras, aunque sea para pequeos programas. Tambin hemos visto que puedes ahorrar tiempo encontrando defectos al principio. Revisando los programas antes de compilarlos y probarlos, reduces el nmero de defectos que encuentras en las pruebas y por lo tanto dedicars menos tiempo a las mismas. Tambin hemos visto que dedicando ms tiempo a la revisin del cdigo, tardars menos en la compilacin y en las pruebas. Adems de estas ventajas, encontrando defectos al principio, haces productos de alta calidad. Este captulo explica por qu esto es as. Muchos ingenieros software piensan que ellos no deberan preocuparse por sus defectos hasta que comenzasen a compilar y probar sus pro-
248
CALIDAD DEL PRODUCTO
gramas. Pasan deprisa por las etapas de diseo y codificacin, y as pueden empezar las pruebas. Con el PSP, los ingenieros se centran en hacer programas limpios y libres de defectos desde el principio. La razn para esta estrategia, es que una vez que el ingeniero hace un producto poco slido, no hay herramienta que pueda dejarlo libre de defectos. Una forma de demostrarlo, es mostrar los datos que relacionan los defectos encontrados en la compilacin, con los encontrados en las pruebas y los defectos encontrados por los usuarios de los programas. Otra aproximacin, sera que reunieses los datos de tu trabajo y vieses por ti mismo como esta estrategia trabaja para ti. Este captulo se centra en ambas aproximaciones.
LASPRUEBAS
Cuanto ms complejo es el producto, las pruebas consumen ms tiempo y son ms caras. Las pruebas, tambin, son menos efectivas para encontrar los defectos. Es decir, con programas ms grandes y complejos, ser ms costoso encontrar y corregir cada defecto, y los encontrars en una tasa muy baja. Hay varias razones para esto. Primero, los defectos enmascaran o agravan a otros. Es decir, cuando un programa tiene muchos defectos, sus interacciones complican el proceso de identificacin y correccin del mismo. Esto hace que algunos de los defectos sean muy difciles de encontrar y corregir. Un defecto tambin puede enmascarar los sntomas de otros. Puesto que estos defectos enmascarados son difciles de encontrar, aumenta la posibilidad de que su deteccin se escape del todo. Otra razn de la complejidad de las pruebas, es la dificultad de probar, aun en los programas pequeos, el nmero de caminos lgicos de un programa, ya que puede ser muy grande. No es prctico probar todas las combinaciones posibles ni tan siquiera en los programas pequeos. Conforme el programa es ms grande y complejo, es ms difcil hacer una prueba que sea moderadamente global. Considera el caso sencillo de un programa que analiza una cadena de caracteres. Si hay solamente 60 posibles caracteres, una cadena de 10 caracteres tendra 6010posibles combinaciones. Es decir, un 6 seguido de 17 ceros. Si pudieras probar 1 .OOO.OOO de combinaciones en un segundo, necesitaras 20.000 aos para probar todas las posibilidades. As, vemos que no es posible probar todas las combinaciones imaginables. En el anterior ejemplo, muchas de las combinaciones de caracteres seran lgicamente idnticas, pero los encargados de las pruebas del sistema no podran saber cules ignorar, y cules probar. Los diseadores, naturalmente, podran decirles qu combinaciones deberan ignorar. El
249
problema de esta estrategia es que los diseadores cometen errores. Si ellos no lo hicieran, naturalmente que no habra necesidad de probar sus programas. Las pruebas son un gran problema, pues los programas no se comportan de la forma que nosotros pensamos que lo haran. As, con sistemas complejos, cuando unicamente probamos las condiciones que pensamos que son importantes, generalmente pasamos por alto muchos defectos. Si sigues mtodos disciplinados y revisiones cuidadosas, y pruebas tus pequeos mdulos de programa, sers mucho ms efectivo que cualquier grupo encargado de pruebas para encontrar defectos en tus programas. Esto se debe a que t conoces la lgica del programa y qu haras. Tambin comprendes las cosas inusuales y las condiciones singulares, y rpidamente puedes ver qu funcionar y qu no. Si haces todo lo que puedas para asegurar que los mdulos de tu programa no tengan defectos, consigues eliminar en gran parte el coste y el tiempo requerido para anular los defectos posteriormente. Aunque no puedes evitar un error ocasional, puedes al menos asegurarte de que tus productos estn esencialmente libres de errores. Y si t no haces un programa libre de defectos, nadie puede hacerlo por ti.
18.3
EL FILTRO DE LAS PRUEBAS

Piensa en la eliminacin de defectos como un filtro. Esto es, cada revisin, compilacin y prueba elimina algn porcentaje de los defectos que estn en el producto. As, si pones ms defectos en el filtro, probablemente encontrars ms defectos. Cuando, por ejemplo, pruebas un programa que contiene 25 defectos, t esperas encontrar una parte de ellos, por ejemplo 12. De forma similar, si pruebas otro programa con 50 defectos, esperas encontrar una fraccin parecida, unos 24. Cuanto mayor es el nmero de defectos a encontrar, mayor es el nmero que probablemente encuentres.
Lo contrario de esto es, sin embargo, que cada proceso de eliminacin de defectos tambin pasa por alto una fraccin de los mismos. As, a mayor nmero de defectos en el filtro, mayor es el nmero que probablemente sern pasados por alto. El nmero de defectos que se cogen por medio del filtro es por lo tanto, proporcional al nmero de defectos que entran al filtro. Aunque el grado que esta relacin guarda, vara considerablemente con la calidad y tipo de proceso de eliminacin de defectos, normalmente esta relacin se mantiene. As, a mayor nmero de defectos que entran en la fase de pruebas, compilacin o revisin, mayor ser el nmero con probabilidad de dejarlos en el producto a la salida de dichas fases.
250
La siguiente cuestin, naturalmente, tiene que ver con la calidad de los filtros. Si pudisemos idear filtros con rendimientos de eliminacin de defectos prximos al 100%,nuestro problema de eliminar defectos se resolvera. Desafortunadamente, los datos sobre los rendimientos de compilacin y pruebas no son tranquilizadores. Como se muestra en la Tabla 18.1, las revisiones de cdigo e inspecciones tienen mejores rendimientos, mientras la compilacin, pruebas de unidad y otras formas de pruebas son menos efectivas [Humphrey 891. Estas cifras estn basadas en datos limitados y puede que no se apliquen a tu situacin particular, pero estos son todos los datos que tenemos. La mejor respuesta para ti, naturalmente, sera reunir los datos de rendimiento de tus propios mtodos de eliminacin de defectos y sacar tus propias conclusiones. Es interesante observar que el mtodo de mayor rendimiento de la Tabla 18.1 es para los ingenieros que hacen una revisin de cdigo. El siguiente mayor rendimiento es para las inspecciones, donde varios ingenieros revisan entre s el diseo y el cdigo.
Tabla 18.1 Rendimientos de eliminacin de defectos.
l
Compilacin
Mtodo
Revisin de cdigo Inspeccin de cdigo
Rendimiento aproximado (%)

70-80 50-70 50
Prueba de unidad Prueba de integracin Prueba de requisitos
40-50
45
1 1
1 Prueba del algoritmo
l I
45
8
I l
Los mtodos que tienen los mayores rendimientos son manuales y no implican ninguna herramienta automatizada. La razn de que sean mejores que otros mtodos es que la mente humana es el instrumento de deteccin de defectos ms poderoso que cualquier herramienta software actual. La conclusin lgica de estos datos es que, para hacer programas de alta calidad, debes tener el menor nmero de defectos posible al comenzar las pruebas. Comenzar las pruebas con el menor nmero de defectos, significa salir de la fase de compilacin con el menor nmero de defectos. Finalmente, para salir de la fase de compilacin con el menor nmero de defectos, debes eliminar los defectos antes de comenzar a compilar. Naturalmente, para hacer productos de mxima calidad, deberas medir, analizar y mejorar cada fase de eliminacin de defectos.
INTRODUCCIN AL PROCESO SOFiWARE PERSONAL
251
LOS BENEFICIOS DEL TRABAJO CUIDADOSO

Otra forma para establecer el filtro de las pruebas es: una chapuza, siempre es una chapuza. En esencia, cuando los ingenieros hacen productos software poco slidos, introducirn y dejarn ms defectos en cada fase de compilacin y pruebas. Cuando los ingenieros hacen el trabajo con esmero, los beneficios destacan en todo el proceso. Esto significa, por ejemplo, que cuando tienes muchos defectos en la compilacin, probablemente tendrs muchos defectos en las pruebas. Y con muchos defectos en las pruebas, probablemente tambin tendrs muchos en el programa. Como muestran los datos de las Figuras 18.1, 18.2 y 18.3, hay una relacin general entre el nmero de defectos encontrados en la fase de compilacin y los encontrados en la de pruebas. Aunque la relacin no es fuerte en trminos estadsticos, un gran nmero de defectos en la compilacin indica posibles problemas en las pruebas.
18.5
EL CLCULO DE LOS VALORES DE RENDIMIENTO

El proceso de medida del rendimiento introducido en el Captulo 16, tiene que ver con la tasa de eliminacin de defectos antes de la primera compilacin. La medida del rendimiento, sin embargo, puede ser aplicada a cualquier paso de la eliminacin de defectos. As, el rendimiento de cada fase puede calcularse de la siguiente forma: Rendimiento de la Fase = 100*(nmero defectos eliminados durante la fase)/(nmero de defectos en el producto al inicio de la fase).
rn
rn
W
2
2IE
I -
252
.
I -
rn
rn
.
I
I
rn
I I
6 -
3
3
fi
5 4 -
5
8
0
3 -
.. .
rn rn
I I
rn
2 -
rn
I 0 .
'
Un clculo preciso del rendimiento requiere datos de defectos de todas las subsiguientes fases del proceso. Por ejemplo, si encuentras 5 defectos en una revisin de cdigo, 3 en la compilacin y 2 ms en las pruebas, en la revisin de cdigo habrs encontrado 5 defectos de un total de 10. Esto da un rendimiento de revisin del 50%. Aunque an puede haber defectos en el programa, este es el rendimiento de la revisin en este punto. Como se muestra en la Figura 18.4, cuando encuentres subsiguientes defectos, el rendimiento de todas las fases que pasan por alto esos defectos disminuye. A la salida de la revisin de cdigo, habas encontrado 5 defectos. Puesto que estos son todos los defectos que has podido encontrar, estos son todos los que crees que hay. A la salida de la revisin, creas que el rendimiento de la misma era del 100%.
253
Programa Fuente
Total de defectos 12
Revisin de Cdigo
Quedan 7 defectos
5 defectos encontrados rendimiento de la revisin = 5/5 = 100%
3 defectos encontrados rendimiento de la compilacin = 313 = 100% rendimiento de la revisin = 5/8 = 62,5%
Prueba de unidad
Quedan 2 defectos
Posterior a las pruebas o durante utilizacin
P
Quedan O defectos
2 defectos encontrados rendimiento prueba de unidad = 212 = 100% rendimiento de la compilacin = 3/5 = 60% rendimiento de la revisin = 5/10 = 50% 2 defectos encontrados rendimiento prueba de unidad = 2/4 = 50% rendimiento de la compilacin = 317 = 42,9% rendimiento de la revisin = 5/12 = 41,7%
Figura 18.4 Valores de rendimiento.
Si en la fase de compilacin encuentras 3 defectos ms, sabemos ahora que en la fase de revisin se encontraron solo 5 defectos de un total de 8. As, el rendimiento de la revisin fue realmente del 62,5% en vez del 100%. El rendimiento aparente del compilador es del 100%. Si en la prueba de unidad encuentras 2 defectos ms, en la revisin se haba encontrado solamente 5 de un total de 10 defectos. As, el rendimiento de la revisin fue realmente del 50%. En este punto el compilador encontr 3 defectos pero pas por alto 2, as el rendimiento en ese punto es del 60%. Puesto que en las pruebas de unidad se supuso que se haban encontrado todos los defectos restantes, el rendimiento aparente es del 100%. Supngase que en la subsiguiente prueba del programa, encuentras 2 defectos ms. Entonces en la revisin se habra encontrado 5 de un total de 12 defectos que tiene el producto. As, el rendimiento de la revisin en este punto sera del 41,7%. De forma similar, el compilador haba encontrado 3 de 7 defectos, por lo que su rendimiento en ese punto sera del 42,9%. Incluso ahora no podras tener la certeza de los valores de rendimiento final. Una vez entregado el producto a los usuarios finales, se podran encontrar an muchos defectos, lo que reducira el rendimiento de todas las fases de eliminacin de defectos.
254
La medida del rendimiento se puede aplicar a cualquier fase del proceso. Cuando se aplica a las pruebas de unidad, por ejemplo, se refiere a la tasa de defectos en el producto que son eliminados durante dichas pruebas. Como se describi en el Captulo 16, el rendimiento del proceso se refiere a la tasa de defectos eliminados antes de la primera compilacin. As, el rendimiento del proceso se calcula de esta forma: Rendimiento del Proceso = 100*(nmero de defectos eliminados antes de la compilacin)/(nmero de defectos introducidos antes de la compilacin).
18.6
LA ESTIMACIN DEL RENDIMIENTO DEFINITIVO

Aunque nunca puedas saber con certeza el rendimiento cuando acabas una fase, la medida de rendimiento ayudar a evaluar y mejorar el proceso. Por ejemplo, cuando encuentras 17 defectos en la revisin de cdigo, 2 en la compilacin y 1 en las pruebas, puedes asegurar de forma razonable que el rendimiento de la revisin estuvo prximo al 85%. Aunque posteriormente pueden encontrarse algunos defectos ms, probablemente has encontrado ya la mayor parte de ellos. Si encuentras 17 defectos en la revisin, otros 15 en la compilacin y 8 ms en las pruebas, el rendimiento inicial de la revisin es del 42,5% y probablemente disminuir en el futuro. Cuando encuentres 23 defectos en la compilacin y pruebas, puedes asegurar de forma razonable que an hay unos pocos defectos ms en el producto. La nica forma de determinar cuntos defectos quedan, es controlar los que vas encontrando en el producto durante el resto de su vida til.
50
40
2
5 cr:
30
1,
1 2
O
3
4
5
10
Nmero de programa
Figura 18.5 Mejora de rendimiento del Estudiante 1.
INTRODUCCINAL PROCESO SOF;TW#Rf PCRsONAL
255
'E 5
!Y
50 40
a
E
~~~
10 1 O
10
Nmero de programa
Figura 18.6 Mejora de rendimiento dd Estudiante 14.

100 -
90 80 -
:g o
!Y
70
60
50 40 30
10
Nmero de programa
Figura 18.7 Mejora de rendimiento del Estudiante 20.
Debido a que durante los aos de utilizacin es posible que no se encuentren todos los defectos, nunca tendrs la certeza. Si el nmero de defectos encontrados disminuye bruscamente con cada eliminacin de defectos, los valores del rendimiento son probablemente bastante precisos. Despus de que hayas reunido datos de defectos, puedes desarrollar medidas de rendimiento para cada fase. Entonces puedes calcular el nmero de defectos que quedan en cualquier producto que desarrolles. Una regla de utilidad emprica es asumir que los defectos que quedan en un producto equivalen al nmero de los mismos encontrados en la 1tima fase de eliminacin. Esto equivale a asumir que el rendimiento de esta ltima fase fue del 50 %. Basndome en mis datos, este rendimiento es un poco bajo para las buenas inspecciones y revisiones de cdigo, bas-
256
tante adecuado para la compilacin y un poco alto para la mayor parte de las fases de pruebas. Considera de nuevo el caso con los 17 defectos encontrados en la revisin de cdigo, 2 en la compilacin y 1 en las pruebas, la estimacin actual del rendimiento de revisin es de 17/(17 + 2 + 1) = 85%. La regla emprica asumira que se encontrar un defecto ms. Esto dara un rendimiento final de 17/(17 + 2 + 1 + 1) = 80,95%. En el otro ejemplo, 17 defectos encontrados en la revisin de cdigo, 15 en la compilacin y 8 en las pruebas. Aqu, el valor del rendimiento actual es de 17/(17 + 15 + 8) = 42,5%. La regla de utilidad emprica sugiere que se encontrarn 8 defectos ms, dando un rendimiento estimado definitivo de revisin de 17/(17 + 15 + 8 + 8) = 35,4%. Con los datos histricos del rendimiento real para cada fase de eliminacin de defectos, podras hacer estimaciones definitivas de rendimiento ms precisas. Hmas esto utilizando el valor del rendimiento conocido para la fase final y calculando el nmero de defectos que probablemente se han pasado por alto. Con bastantes datos de rendimiento, podras calcular rangos estadsticos para el nmero de defectos que quedan. Aunque nunca sabrs realmente los verdaderos valores del rendimiento, estos datos te ayudarn a hacer estimaciones un poco ms aproximadas.
18.7
LOS BENEFICIOS DE UN RENDIMIENTO DE PROCESO DEL 100%

El objetivo de la revisin de cdigo sera alcanzar de forma consistente un rendimiento de proceso del 100%. Si pudieras hacerlo, encontraras todos los defectos y no dejaras ninguno para encontrarlo en la fase de compilacin o pruebas. Esto no solamente ahorrar tiempo de compilacin y pruebas, sino que el mayor beneficio estar en los costes y planificacin del proyecto. Con mdulos de programas libres de defectos, tu equipo de desarrollo no dedicara tiempo a probar tus programas. Esto ahorrara los costes de las pruebas, reducira el tiempo de las mismas y mejorara las planificaciones del desarrollo. Tambin producira mejores productos. Lograr un rendimiento de un 100% no es fcil. Requiere tiempo, prctica y un gran acopio de datos y anlisis. El desarrollo de software de alto rendimiento, es una habilidad que puede aprenderse y mejorarse. Considera la analoga con tocar un instrumento musical. Cuando aprendes a tocarlo por primera vez, probablemente tocars muchas notas errneas. Con la prctica, irs gradualmente tocando mejor las notas y cometers menos errores. Despus de mucha prctica, puedes aprender a
257
tocar sin cometer errores en las notas. As, cuando se llega a esta situacin, es cuando los msicos comienzan a ser realmente artistas. El trabajo de realizar software de calidad es muy parecido a tocar un instrumento musical. Hasta que t puedas hacer un cdigo que tenga pocos o ningn defecto, no logrars ser un ingeniero software. Mientras dediques la mayor parte de tu tiempo a encontrar y corregir defectos, no estars actuando como un profesional. Con mtodos de calidad disciplinados, sin embargo, hars pequeos programas libres de defectos de una forma coherente. Entonces, podrs centrarte en desafos ms importantes para producir grandes programas de alta calidad. Aunque dominar estas disciplinas requiere tiempo y un esfuerzo constante, vers que mejoras gradualmente. Tu objetivo personal, sin embargo, debe ser alcanzar un rendimiento del 100%. Recuerda que nunca hars grandes programas de calidad hasta que no hagas de forma rutinaria pequeos programas de calidad. Esto requiere disciplina personal y mucha prctica.
18.8
EXPERIENCIA DEL RENDIMIENTO

Tan difcil como alcanzar un alto rendimiento, es poder mantenerlo. Las Figuras 18.5 y 18.7 muestran las mejoras de rendimiento de tres ingenieros que lo hicieron. Estos ingenieros aprendieron el PSP en un curso donde escribieron un total de 10 pequeos programas. Comenzaron con el programa 1 y progresivamente aadieron medidas del PSP y mtodos en los sucesivos programas. En el programa 7, se exigieron revisiones de cdigo. Como se muestra en las figuras, todos los ingenieros haban mejorado claramente sus rendimientos. Obsrvese, sin embargo, que no hay un patrn normalizado de mejora. Algunos ingenieros llevarn a cabo constantes mejoras, mientras que otros tendrn fluctuaciones considerables. Algunos estudiantes pueden alcanzar rendimientos del 80% o superiores, mientras que otros lucharn por conseguir el 50%. Durante mi desarrollo del PSP, aprend a conseguir de forma consistente rendimientos del 80%. Esto, sin embargo, fue despus de haber trabajado en la mejora del rendimiento durante tres aos y haber escrito 62 programas con el PSP. Las personas tienen diferentes habilidades. Algunas hacen de forma natural cdigo de calidad mientras otras pueden visualizar diseos complejos. Algunas personas han nacido para hacer pruebas y otras son aptas para disear interfaces sencillas de usuario. Todos los ingenieros deberan ser capaces de alcanzar de forma consistente un rendimiento del 70%, pero algunos le llevar ms tiempo que a otros.
258
PROTOTIPADO
Una vez que has alcanzado de forma consistente un rendimiento del 70%, continuar mejorando ser ms difcil. Aunque ocasionalmente pases por alto uno o dos defectos sintcticos, la mayor parte de los defectos pasados por alto tendrn que ver con el diseo. Encontrars nuevos sistemas o cuestiones de soporte o necesitars utilizar funciones de programas desconocidas. Con grandes programas, las interfaces, el rendimiento, la gestin de memoria y muchos otros aspectos sern muy importantes. Cada vez que hagas algo nuevo probablemente cometers errores. As, para eliminar todos los defectos, deberas intentar escribir prototipos de programas pequeos. Experimenta con cada funcin desconocida o procedimiento antes de utilizarlo en un programa. Prueba nuevas ideas y haz simples prototipos de cualquier estructura o elemento que no hayas utilizado previamente. Esto evitar muchos de los defectos que normalmente se escaparan a tus revisiones personales. Tambin encontrars que ciertos tipos de defectos son ms difciles de localizar o prevenir que otros. Conforme idees formas de encontrar los defectos con ms frecuencia te equivocars, muchos implicarn aplicaciones, soporte de sistemas y cuestiones del entorno de desarrollo. Cada fuente de confusin es una fuente de defectos. La clave est en reconocer la diferencia entre lo que realmente sabes de algo y lo que t crees que sabes. Ocasionalmente cometers un error con algo que realmente conoces, pero muchas veces tus errores implicarn suposiciones que no son completamente correctas. Aprende a reconocer estas suposiciones. Entonces construye un prototipo para probarlas antes de incorporar las suposiciones en el producto.
RESUMEN
Conforme los programas son ms grandes, es ms costoso encontrar y corregir los defectos. El proceso de eliminacin de defectos es tambin menos efectivo. La estrategia para producir grandes programas de gran calidad es, en primer lugar, eliminar todos los defectos de los mdulos que forman estos grandes programas. La eliminacin de defectos es un proceso de filtrado: ve cada fase de eliminacin de defectos como un filtro. Cuantos ms defectos se pongan en el filtro ms se encontrarn. Tambin, cuanto ms defectos se pongan en el filtro, ms se pasarn por alto. El rendimiento de muchas fases de prueba es menor del 50%. As, para obtener un producto de alta calidad al final de una prueba, debes poner un producto de alta calidad al comienzo de la prueba.
259
Un trabajo concienzudo en cada paso de tu proceso ser rentable y ahorrar tiempo. Si haces un programa mal, se encontrarn muchos defectos en la compilacin y en cada subsiguiente fase de pruebas. El rendimiento mide la calidad de la eliminacin de defectos. El rendimiento del proceso se refiere a la tasa de defectos en el producto que son eliminados antes de la primera compilacin. El rendimiento puede medir tambin la tasa de defectos en un producto que son eliminados en la fase de eliminacin de defectos. Tu objetivo sera lograr el 100% de rendimiento del proceso. Recuerda: no sers capaz de hacer grandes programas de mucha calidad hasta que no puedas hacer de forma constante pequeos programas de gran calidad. Esto supone una dedicacin constante a la calidad, disciplina personal y mucha prctica. Para lograr la mxima calidad en un programa, haz pequeos prototipos para probar cada suposicin antes de incorporarla al producto. Aprende a reconocer la diferencia entre lo que crees que sabes y lo que realmente sabes. Cada vez que hagas una suposicin, es probable que introduzcas un defecto.
EJERCICIO 18
Para el ejercicio, muestra la relacin entre los defectos de la fase de compilacin y de pruebas para todos los programas que has escrito en este curso. Mustralos en grficos como los de las Figuras 18.1, 18.2 y 18.3. Calcula el rendimiento del proceso para cada programa, y estima la probabilidad del rendimiento final una vez que todos los defectos que queden en el programa se hayan encontrado. Observa que este anlisis de defectos es un ejercicio opcional y no es necesario terminarlo a no ser que lo pida tu profesor. Entrega copias del Cuaderno de Registro de Tiempos y del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega acabado el Resumen del Plan de Proyecto del PSP, el Cuaderno de Registro de Defectos y la Lista de Comprobacin para la Revisin de Cdigo para cada programa. Incluye los valores Planificados, Reales y Hasta la Fecha de los tiempos de desarrollo, de los defectos introducidos, de los defectos eliminados y del rendimiento.
REFERENCIA
[Humphrey 891 Humphrey, W.S. Munuging the Software Process. Reading, MA: Addison-Wesley, 1989.
CAPITULO 19
La calidad del proceso
Este captulo describe la calidad del proceso y algunas medidas que puedes utilizar para evaluar la calidad de tu trabajo de desarrollo de software. Tambin muestra como calcular y controlar estas medidas. Como ejercicio, calculars una de estas medidas para los programas que hayas desarrollado en este curso y dibujars una grfica que muestre cmo han cambiado estas medidas.
19.1
MEDIDAS DEL PROCESO

La calidad de tus programas est determinada por la calidad de tu proceso. La calidad de tu proceso, por otra parte, est determinada por tu forma de trabajar. As, para desarrollar mejores programas, necesitas cambiarla. Para hacerlo ms eficientemente, necesitas saber cmo es de bueno tu proceso. Para saber esto, necesitas medir la calidad de tu proceso. La medida fundamental de un proceso tiene que ver con el volumen de productos realizados, su calidad, el tiempo y los recursos requeridos para hacer el trabajo. A partir de aqu, puedes determinar tu rendimiento real y cmo puedes cambiar para obtener mejores resultados en el futuro. En los Captulos 3-11, introdujimos varias medidas de coste y tamao. En el Captulo 12, se comenz a controlar defectos y se introdujeron medidas de eliminacin de defectos y el nmero de defectos eliminados por hora. En los Captulos 16-18 se introdujo el rendimiento y otras medidas de la
262
LA CALIDAD DEL PROCESO
efectividad del proceso en la bsqueda y correccin de defectos. Ahora, nos centramos en las medidas de calidad del proceso. Es importante recordar que en este libro nos centramos solamente en la calidad desde la perspectiva de la introduccin y eliminacin de defectos. Despus de haber aprendido y practicado los mtodos del PSP descritos en este libro, deberas considerar cmo mejorar el proceso que utilizas en otras reas importantes. Por ejemplo, realmente has entendido los requisitos? Algn paso del proceso que lleva a requisitos equivocados podra incluir desarrollar un primer prototipo, para revisar con tu profesor o cliente. Otro tpico importante tiene que ver con la utilidad o rendimiento de las pruebas, la compatibilidad de estndares, la revisin de interfaces, etc. Para cada una de estas cosas, puedes idear varios pasos para mejorar la calidad del producto. La calidad es un tema importante y hay, potencialmente, muchas acciones tiles del proceso que podras tener en cuenta para ayudarte a asegurar que entregas productos de calidad a tus clientes.
19.2
LA PARADOJA DE LA ELIMINACIN DE DEFECTOS

Un fenmeno que puedes haber observado, es que las tasas de eliminacin de defectos disminuyen conforme mejora la calidad del producto. Esto es porque, por ejemplo, la tasa de eliminacin media para los defectos de las pruebas de la Figura 16.2 disminuy de 4 a 2 por hora en un rango de 10 programas. En este mismo perodo, los defectos que estos estudiantes encontraron en las pruebas disminuy en un factor de 10: de 40 a 4 defectos/KLOC. Esta disminucin parece natural cuando consideras casos extremos. Cuando hay muchos defectos que localizar, normalmente encontrars muchos rpidamente. Aunque un defecto ocasional pueda llevar mucho tiempo, el tiempo medio es relativamente corto. En el otro extremo, con un solo defecto en un gran programa, todo el tiempo dedicado a revisar y probar ser asignado a este nico defecto. Dependiendo de la naturaleza del defecto y del orden de las pruebas y revisiones, esto podra llevar mucho tiempo.
As, con pocos defectos, llevar mucho tiempo encontrarlos, independientemente de los mtodos que utilices. Esto es cierto para la revisin y las pruebas, pero lo es menos para la compilacin. Aunque hay una leve tendencia descendente para la tasa de eliminacin de defectos en la compilacin, la naturaleza automtica de los compiladores los hace menos sensibles a la densidad de defectos. La tendencia descendente para las revisiones y pruebas puede no ser evidente para secuencias cortas de da-
263
tos, pero la tasa para cualquier mtodo dado, generalmente, disminuir conforme disminuya el nmero de defectos.
As, conforme pongas progresivamente mayor calidad en los programas por medio de sucesivas fases de integracin y pruebas del sistema, sus defectos residuales sern progresivamente ms difciles de encontrar y corregir. Esto sugiere que cuanto ms defectos encuentres, ms importante es encontrarlos y corregirlos.
19.3
UNA ESTRATEGIA PARA LA ELIMINACIN DE DEFECTOS

Se podra argumentar que muchos de los defectos en los programas grandes estn en el sistema y no en los mdulos. Esto, sin embargo, no es cierto. Con pocas excepciones, los defectos en los grandes sistemas estn en los mdulos que lo constituyen. Estos defectos se pueden dividir en dos clases: aquellos que implican solamente un mdulo y los que implican interacciones entre mdulos. Cuando tengas un alto rendimiento con el PSP, eliminars casi toda la primera clase de defectos. La segunda clase, sin embargo, es mucho ms difcil. La razn es que, los sistemas grandes y complejos, implican muchas interacciones que son difciles de visualizar para los diseadores. Una buena forma de abordar este problema es seguir una estrategia como la siguiente: Esfurzate en desarrollar mdulos con la mxima calidad posible. Haz inspecciones de todas las interfaces de mdulos y sus interacciones. (Observa que una inspeccin es cuando un equipo de ingenieros revisa un producto. Las inspecciones se tratan brevemente en la Seccin 13.11.) Inspecciona los requisitos para asegurarte que todas las funciones importantes son adecuadamente entendidas, diseadas e implementadas. Inspecciona el sistema y el diseo del programa frente a los requisitos, para asegurarte que son tratados adecuadamente todos los requisitos clave. Haz unas pruebas de unidad exhaustivas despus de que se haya inspeccionado el cdigo. Haz una prueba de integracin global. Haz pruebas a todo el sistema. Excepto el primer paso, el resto estn ms all del mbito de tu proceso personal. Sin embargo, el primer paso depende de ti. Si tus mdulos no
264
son de mxima calidad, el resto de pasos sern mucho menos efectivos. Entonces el proceso de desarrollo debe concentrarse en encontrar y corregir los defectos que t y tus compaeros dejan en tus mdulos. Esto tambin significa que el trabajo que los restantes pasos se supone que acabaron, realmente no fue hecho. En vez de asegurar que el sistema realiza adecuadamente las funciones que el usuario pretende, las pruebas del sistema y de integracin se dedicarn principalmente a encontrar y corregir los defectos que quedan en los mdulos. Con mdulos que inicialmente tienen una alta calidad, sin embargo, puedes seguir la estrategia anteriormente mencionada. Entonces tendrs una oportunidad razonable de hacer sistemas de alta calidad. Mejor que derrochar el tiempo intentando encontrar y arreglar los defectos de los mdulos, la prueba de integracin se puede enfocar en probar las interfaces entre los mdulos. La prueba del sistema ahora podra tratar cuestiones crticas del sistema como el rendimiento, la funcionalidad, recuperacin y seguridad. Hasta que los ingenieros no logren de una forma consistente rendimientos personales altos, dichas pruebas no se harn.
19.4
EL COSTE DE LA CALIDAD
Aunque pudieras dedicar cualquier cantidad de tiempo a buscar defectos, nunca estaras seguro de haberlos encontrado todos. As, si tu nico objetivo era hacer programas libres de defectos, podras continuar haciendo revisiones y pruebas indefinidamente. Aunque dejases de hacerlas despus de no haber encontrado defectos por un tiempo, podras aun, no haberlos encontrado todos. Como ingeniero del software, sin embargo, necesitars un equilibrio entre el tiempo dedicado y la calidad de los productos hechos. El Coste de la Calidad (CDC) proporciona una forma de tratar estas cuestiones. El CDC tiene tres elementos principales: costes de los fallos, costes de valoracin y costes de prevencin.
Los costes de los fallos incluyen todos los costes de corregir los defectos del producto. Mientras ests corrigiendo un defecto, ests incurriendo en unos costes de los fallos. De forma similar, mientras ests ejecutando el depurador para detectar la sentencia defectuosa, ests incurriendo en costes de fallos. Cualquier cosa hecha como una parte normal de la reparacin de un defecto se contabiliza como coste de fallos. Esto incluye el volver a disear, a compilar y a probar.
Los costes de valoracin incluyen todo el trabajo de valoracin del producto para ver si tiene defectos, excluyendo el tiempo dedicado a la correccin de defectos. Incluye la revisin de cdigo, el tiempo de compilacin y las pruebas para un programa libre de errores. As, los costes de
265
valoracin no incluyen los costes de reparacin. El coste de valoracin es la tasa pagada para asegurar que el programa est libre de defectos.
Los costes de prevencin son los costes incurridos cuando modificas el proceso para evitar introducir defectos. Incluye, por ejemplo, los anlisis hechos para comprender los defectos. Tambin incluye el trabajo realizado para mejorar los procesos de especificacin de requisitos, diseo e implementacin. El tiempo gastado en el rediseo y pruebas de un nuevo proceso, es tambin un coste de prevencin.
Otra actividad importante para la prevencin de defectos es la construccin de prototipos para probar el diseo o las ideas de implementacin. Cuando ests utilizando una funcin de librera desconocida puedes estar tentado a tan solo usarla. Sabes, sin embargo, que esto conduce a errores de diseo y defectos en el programa. El coste de escribir pequeos prototipos del programa para comprobar cmo trabaja dicha funcin es un coste de prevencin.
19.5
CLCULO DEL COSTE DE LA CALIDAD

El PSP mide el CDC de una forma muy sencilla. Aunque el tiempo dedicado a la compilacin incluye algn tiempo de compilacin libre de defectos, el PSP contabiliza todo el tiempo de compilacin como costes de fallos. De forma similar, las pruebas incluyen algn tiempo que debera dedicarse a probar un programa libre de defectos. De nuevo, el PSP contabiliza todo el tiempo de pruebas como costes de fallos. Finalmente, todo el tiempo de revisin es contabilizado como coste de valoracin. Este tiempo incluye algn coste de reparacin, pero el PSP contabiliza todo el tiempo de revisin como coste de valoracin. Podras calcular los valores exactos del CDC con los mtodos descritos en la Seccin 19.8, pero esto implica mucho trabajo y no cambia considerablemente la efectividad de las medidas. Por eso, recomiendo que utilices las definiciones simplificadas del PSP. El coste de la calidad se calcula como un porcentaje del tiempo de desarrollo total. Para el PSP, los costes de valoracin y fallos se calculan de las siguiente forma:
La valoracin CDC es la suma de todo el tiempo de revisin como un porcentaje del tiempo total de desarrollo. Los fallos CDC es la suma de todo el tiempo de compilacin y pruebas como un porcentaje del tiempo total de desarrollo.
Por ejemplo, supongamos que tienes los datos del proceso que se muestran en la Tabla 19.1 Resumen del Plan del Proyecto. Podras calcular la valoracin CDC de la siguiente forma:
266

sr. Z
Estudiante x
Fecha Programa# Lenguaje Plan

5,40 1,5 09 5 9253 40,O 0,375 49 62 36
9/12/96 1 5
Ada
Resumen MinutodLOC LOClHora DefectodKLOC Rendimiento VIF Tamao Programa (LOC): Total Nuevo & Cambiado Tamao Mximo Tamao Mnimo Tiempo por Fase (min.) Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Postmotten Total Tiempo Mximo Tiempo Mnimo Defectos introducidos Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total Defectos eliminados Planificacin Diseo Codificacin Revisin del cdigo Compilacin Pruebas Total
Real
4,60 13,04 52,6 100,0% 133 57
Hasta la Fecha
5,35 11,21 06,7 45,5
04 ,4
392
Plan
1 7
Real
29 16 1 21
1 5
Hasta la Fecha
20 30 19 1 29 5
10
4 1 30 269 340
197
262
140 233 91 1 14 7 105 209 247 2099
% Hasta la Fecha 6,7 11,l 43,4 83 5,O 13,0 11,7 100,o
Plan
1
4
Actual

5 20 1 14,7 02,4
Def./Hora
1,29 1,54
23
100,o
5
Plan
34
Actual
ef./Hora
2 2
1
1 5 1 3
6
34
44,l 35.2 17,l 100,o
5,17 7,43 1,25
Tiempo total real de desarrollo = 262 minutos. Tiempo real de revisin del cdigo = 29 minutos. Valoracin CDC = 100*29/262 = 11.07%. Los costes de los fallos se obtendran as: Tiempo real de compilacin = 5 minutos. Tiempo real de pruebas = 10 minutos. Fallos CDC = 100*(5+10)/262= 100*15/262 = 5,73%.
267
19.6
LA RELACIN VALORACIN /FALLOS

Una medida til del PSP es la relacin ValoracidFallos, o V/F. Es calculada dividiendo la valoracin CDC por los fallos CDC. En el ejemplo de la Seccin 19.5, con una valoracin CDC de 11,07% y con un valor de fallos CDC de 5,73%, V/F = 11,07/5,73 = 1,93. Es sencillo calcular el valor V/F como el tiempo de revisin de cdigo dividido por el total del tiempo de compilacin y pruebas. Utilizando esta aproximacin,V/F = 29/(5+10) = 1,93, que es el mismo valor que hemos obtenido en el prrafo anterior. Estos clculos estn descritos en las Instrucciones del Resumen del Plan del Proyecto en la Tabla 19.2. El valor de V/F mide la cantidad relativa de tiempo dedicada a encontrar defectos antes de la primera compilacin. Los datos del estudiante X muestran que el valor V/F es un buen indicador de la probabilidad de encontrar defectos en las pruebas. En la Figura 19.1, los valores de V/F para 14 estudiantes del PSP se muestran frente al nmero de defectos/KLOC que encontraron en las pruebas. Estos datos se refieren a un total de 140 programas. Cuando el valor de V/F es menor que 1, las pruebas del programa generalmente encuentran muchos defectos. Aunque esto no est garantizado, muchos programas en este rango tendrn un valor bastante alto de defectos/KLOC en las pruebas. Tambin, de la Figura 19.1, se deduce claramente que procesos con V/F por encima de 2 tienen pocos defectos/KLOC en las pruebas. Esto sugiere que procesos con un valor de V/F por encima de 2 es ms probable que produzcan productos libres de defectos que los procesos que tienen un valor de V/F por debajo de 1. Deberas intentar lograr unos valores de V/F de 2 o superiores.
Los datos de una empresa muestran cmo puede ser de efectivo el valor de V/F para juzgar la calidad del producto. La Figura 19.2 muestra un grfico del nmero de defectos encontrados en las pruebas de unidad de seis componentes de un producto frente al valor de V/F. La Figura 19.3 muestra el nmero de defectos encontrados durante la integracin, las pruebas del sistema y la utilizacin por el cliente de estos mismos componentes. Obsrvese que uno de los componentes con un valor bajo de V/F tena relativamente pocos defectos en las pruebas de unidad pero se encontraron muchos ms tarde. Obviamente, las pruebas de unidad no haban sido muy minuciosas. La Figura 19.4 muestra los defectos encontrados en la compilacin frente al nmero de defectos encontrados despus de la compilacin. Evidentemente, cuantos ms defectos se encontraron en la compilacin, ms defectos se encontraron en las subsiguientes fases de pruebas y utilizacin. El mensaje es claro: si quieres reducir los defectos de las pruebas, debes limpiar tus programas antes de comenzar la compilacin. El componente con el mayor nmero de defectos de compilacin
268
Propsito Cabecera Esta tabla trata los datos estimados y reales de los proyectos, de una forma cmoda y fcilmente recuperable.
Minutos/LOC
Antes de iniciar el desarrollo: Escribe los Minutos/LOC planificados para este proyecto. Utiliza la velocidad Hasta la Fecha de un programa reciente del Cuaderno de Registro de Trabajos o del Resumen del Plan del Proyecto. Despus del desarrollo: Divide el tiempo total de desarrollo por el tamao real del programa para obtener los Minutos/LOC reales y los MinutoslLOC Hasta la Fecha. Por ejemplo, si el proyecto se hizo en 196 minutos e hiciste 29 LOC, los MinutoslLOC seran 196/29 = 6,76.
LOCiHora
Antes de iniciar el desarrollo: Calcula las LOC por hora planificadas para este programa dividiendo 60 por los Minutos/LOC de la casilla de Plan. Despus del desarrollo: Para LOC/Hora Real y Hasta la Fecha divide 60 por los Minutos/LOC Reales y Hasta la Fecha. Para los 6,76 Minutos/LOC Reales, tenemos 60/6,76 = 8,88 LOC/Hora Reales. Antes de desarrollar: Encuentra los defectos/KLOC Hasta la Fecha del programa ms reciente. Utiliza dicho valor como los Defectos/KLOC planificados. Despus del desarrollo: Calcula los valores de defectos/KLOC reales y Hasta la Fecha para este programa. Para el valor real, multiplica el total de defectos reales por 1O00 y divdelo por las LOC Total Nuevas & Cambiadas Reales. Para el valor Hasta la Fecha haz unos clculos similares. Con 17 defectos Hasta la fecha y 153 LOC Total Nuevas & Cambiadas, los Defectos/KLOC Hasta la Fecha = 1000'17/153= 111,11.
Defectos/KLOC
Rendimiento
Calcula el rendimiento planificado, real y Hasta la Fecha. Rendimiento = 1 OO*(nmerode defectos eliminados antes de la compilacin)/(nmerode defectos introducidos antes de la compilacin), as, con 5 defectos introducidos y 4 localizados, el rendimiento = 100*4/5 = 80,0%.
Calcula el valor de V/Fplanificado, real y Hasta la Fecha. Para el valor real, por ejemplo, toma la relacin del tiempo de revisin de cdigo real y divdelo por la suma de los tiempos reales de compilacin y pruebas. Para un tiempo de revisin de 29 minutos, uno de compilacin de 5 minutos y uno de pruebas de 10 minutos, V/F = 29/(5 + 10) = 1,93.
( Contina)
V/F
269
Tamao Programa Antes de iniciar el desarrollo: WC) Escribe bajo la columna plan, el valor estimado de LOC Total Nuevas & Cambiadas, Mximo y Mnimo. Despus del desarrollo: Cuenta y anota las LOC Nuevas & Cambiadas Reales. * Para la columna Hasta la Fecha, aade LOC Reales Nuevas & Cambiadas a las LOC Hasta la Fecha Nuevas & Cambiadas de programas anteriores. Tiempo por Fase Plan
Para el tiempo total de desarrollo, multiplica el valor de las LOC Total Nuevas & Cambiadas por Minutos/LOC. Para el tiempo Mximo, multiplica el tamao Mximo por los MinutoslLOC. Para el tiempo Mnimo, multiplica el tamao Mnimo por los Minutos/LOC. Del Resumen del Plan del Proyecto de un programa reciente, busca los valores de YoHasta la Fecha para cada fase. Utilizando el % Hasta la Fecha de programas anteriores calcula el tiempo planificado para cada fase. Una vez acabado el trabajo, anota el tiempo real en minutos que has gastado en cada fase del desarrollo. Obtn estos datos del Cuaderno de Registro de Tiempos. Para cada fase, anota la suma del tiempo real y el tiempo Hasta la Fecha de los programas ms recientes. Fecha y lo divides por el total del tiempo Hasta la Fecha.
~
Actual
Hasta la Fecha
Y Hasta la Fecha Para cada fase, anota 1O0 multiplicado por el tiempo Hasta la !
Defectos introducidos Plan
Antes del desarrollo, estima el nmero total de defectos a introducir en el programa. El valor es: defectos/KLOC planificados multiplicado por las LOC Total Nuevas & Cambiadas planificadas para este programa y divido por 1000. Por ejemplo, con un valor de defectos/KLOC planificado de 7 5 9 y un valor de LOC Nuevas & Cambiadas planificadas de 75, el total de Defectos Planificados = 75,9*75/1O00 = 5,69, redondeo a 6. Antes de desarrollar, estima los defectos introducidos por fase utilizando el total de defectos estimados y el % Hasta la Fecha de defectos introducidos de programas anteriores. Despus del desarrollo, localiza y anota el nmero real de defectos introducidos en cada fase. Para cada fase, anota la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes. para esa fase y divdelos por el total de defectos Hasta la Fecha.
Real Hasta la Fecha
Yo Hasta la Fecha ara cada fase, multiplica por 1O0 los defectos Hasta la Fecha
Defectos/hora Calcula los defectos introducidos por hora para la fase de diseo y codificacin. Para la fase de diseo, por ejemplo, se multiplica 60 por los defectos de diseo Hasta la Fecha y se divide por el tiempo de diseo Hasta la Fecha = 60*5/195=1,54 defectos/hora.
270
Defectos
eliminados Plan
Real Hasta la Fecha En la fila de total, anota el total de defectos estimados. Utiliza los valores de % Hasta la Fecha de los programas mas recientes, calcula los defectos eliminados planificados para cada fase. Despus del desarrollo, localiza y anota el nmero real de defectos eliminados en cada fase. Para cada fase, anota la suma de los defectos reales y los defectos Hasta la Fecha de los programas ms recientes.
% Hasta la Fecha Para cada fase, multiplica por 1O0 los defectos Hasta la Fecha para esa fase y divdelos por el total de defectos Hasta la Fecha.
~~
Defectos/hora
Calcula los defectos eliminados por hora para la revisin de cdigo, compilacin y pruebas. Para las pruebas, por ejemplo, multiplica 60 por los defectos de las pruebas Hasta la Fecha y divdelo por el tiempo de pruebas Hasta la Fecha = 60*6/279 = 1,29 defectodhora.
Relacin ValoraciniFallo
Figura 19.1 Defectos en la prueba vs. VIF.
tena ms defectos en cada subsiguiente fase del proceso. Tambin tena ms defectos en el producto entregado al cliente. Para mostrar el impacto de una pronta eliminacin de defectos en el tiempo de desarrollo, la Figura 19.5 muestra las horas de pruebas frente a los valores de V/E Aqu, los dos componentes con valores bajos de V E tuvieron 140 y 245 horas de pruebas, mientras que los otros tuvieron de 10 a 40 horas de pruebas. La Figura 19.6 muestra las horas de pruebas por KLOC. En un proceso de baja calidad, las pruebas consumen de 80 a 100 horas por KLOC; con un proceso de alta calidad, las pruebas suponen sobre unas 20 horas. Esta diferencia de 60 a 80 horas de pruebas por KLOC
271
50
3 .5
2 5
45 40 3530-
z &
8
25 20 15
t; 2
10 5 O O
1
H
I
OS
1,s
Calidad del proceso ( V E )
Figura 19.2 Defectos en la prueba de unidad vs. calidad del proceso.

40
H
30
a
u
$
I
2520 -
8 a 8
15
10 -
01 O
5t
0s
1,5
Figura 19.3 Defectos post-PSP vs. calidad del proceso.
puede ser muy significativa cuando trabajes con productos de 100.000 LOC o ms. El coste aadido de un PSP de poca calidad estara entre 6.000 a 8.000 horas adicionales de pruebas, o de 3 a 4 aos de tiempo de programador derrochados. En productos de varios millones de LOC, que pronto sern comunes, esto podra ser la diferencia entre un producto entregado a tiempo y el fracaso total.
UTILIZANDO LA RELACIN VALORACIN /FALLOS

Para lograr valores de V/F por encima de 2,O revisa el histrico de compilaciones, el tiempo de pruebas y planifica dedicar al menos el doble de
272
90 80 -
:o o r=
*
70 60 -
50 -
40-
v)
30 2010
O
=p
I I I
Defectos compilacin
Figura 19.4 Defectos compilacin vs. defectos post-compilacin.
50
I I
tiempo a la siguiente revisin de cdigo. Puedes aumentar el valor de V/F simplemente dedicando ms tiempo a la revisin de cdigo. Si no encuentras defectos, no mejorar la calidad del programa. Es importante para la productividad utilizar el tiempo de revisin para encontrar defectos. Mientras que tu rendimiento no est en un rango del 80 al 100%,contina aumentando el valor de V/F. No debes hacer esto, solamente dedicando ms tiempo. Revisa los datos de los defectos de tus programas ms recientes e idea formas de encontrar todos los defectos que con ms fre-
273
1O 0
90 80
f
O
50
40
;
10 O
OS
1.5
Figura 19.6 Horas/KLOC de prueba vs. calidad del proceso.
cuencia pasas por alto. Si no ests seguro de cmo hacerlo, relee el Captulo 14. Despus de determinar cmo encontrar los defectos que pasas por alto con ms frecuencia, introduce los pasos apropiados en las lista de comprobacin para la revisin del cdigo. Por ltimo, sigue estos pasos cuando hagas la revisin de cdigo. Si haces todo esto, dedicars ms tiempo a la revisin, encontrars ms defectos y aumentar el valor de V/F. Posiblemente reduzcas el nmero de defectos que encuentres en la compilacin y en las pruebas. Esto ahorrar mucho tiempo de pruebas, reducir costes de fallos y realizar productos de alta calidad.
19.7
CMO MEJORAR LAS TASAS DE REVISIN

No te preocupes de las tasas de revisin de cdigo defectohora hasta que de forma regular encuentres casi todos los defectos antes de la compilacin y las pruebas. Contina comprobando los datos de defectos para ver qu pasos de la revisin deberan haber encontrado los defectos que se encontraron en la fase de compilacin y en la de pruebas. Tambin, contina actualizando tu lista personal de comprobacin para la revisin de cdigo para encontrar estos defectos. Una vez que encuentres la mayor parte de los defectos en la revisin de cdigo, piensa cmo mejorar las tasas de revisin de cdigo. Para hacer esto, identifica cualquier paso de la revisin que ni encuentre ni pase por alto defectos. A continuacin, reconsidera tus razones para incluir estos pasos en primer lugar. Si estas cuestiones ya no son un problema, sl-
274
50 60 70 80
lnterfaz Comprobacin
Datos
90 Sistema 1O0 Entorno
Funcin
Tabla 19.3 E j e m p l o del c u a d e r n o de registro de defectos.

Estudiante X
5r. Z
Nmero
Tipo
Introducido
Eliminado
r
Fecha
Nmero
T
Tipo
n
Introducido
m
Eliminado
Fecha 9/12/96 Programa # 1 5 Tiempo de Defecto correccin corregido
Descripcin: omitir declaracin de 5et-X
1-
1 1 2
Fecha Nmero TiDo
pazzizq
r n
Eliminado
Tiempo de correccin
Defecto corregido
Descripcin: olvidar en el bucle while un desidual Introducido TiemDo de correccin Defecto corregido
n7
Descripcin: no poner: Fecha Nmero
201
ICRI
1-1
m
Defecto corregido
Tipo
Introducido
Eliminado
Descripcin : Fecha
nnnnnnn
Tiempo de correccin
Descripcin: Fecha
nnnnnnn
Descripcin: Fecha
nnnnnnn
U
Fecha
I
Nmero
I
Tipo
~
Descripcin: Introducido Eliminado
nnnnnnn
Descripcin:
275
tate los pasos. Por otra parte, si piensas que estas pruebas son an importantes, combina varias de ellas para poder hacerlas ms rpidamente. Con cada programa, contina controlando los datos de defectos y restituye cualquier paso de la revisin que podra haber detectado defectos pasados por alto posteriormente. Cuando los pasos no son efectivos, no dudes en eliminarlos.
19.8
CLCULO DEL VERDADERO COSTE DE CALIDAD

Para el PSP, los clculos simplificados del CDC son adecuados. Cuando trabajas en grandes proyectos de desarrollo, sin embargo, puedes querer utilizar las medidas ms precisas de CDC. Para calcular los verdaderos costes de fallos y valoracin, debes dividir los tiempos de revisin, compilacin y pruebas entre los componentes respectivos de valoracin y fallos. Por ejemplo, podemos denominar el tiempo de compilacin en el que no se encuentran defectos como compilacin (valoracin) o C, y al tiempo de correccin de defectos durante la compilacin como tiempo de compilacin (fallos) o C,. As, C, + C,= C es el tiempo total de compilacin. Para los tiempos de revisin y pruebas, tenemos R, + R v = R como tiempo total de revisin y P, + P,= P como tiempo total de pruebas. Utilizando estos parmetros, ahora puedes calcular con precisin la valoracin y fallos CDC de la siguiente manera: Valoracin CDC = 1 OO*(Rv + C,+ P,) / (tiempo total de desarrollo) Fallos CDC
= 100*(RF+ C,+ P,) / (tiempo total de desarrollo)
El siguiente ejemplo utiliza los datos del Resumen del Plan del Proyecto de la Tabla 19.1 y del Cuaderno de Registro de Defectos de la Tabla 19.3. Primero, calcula los valores de R , C , P , R,, C, y P,de la siguiente manera: Para calcular R , calcula primero R, a partir del Cuaderno de Registro de Defectos, como la suma de los tiempos de correccin para los defectos eliminados en la revisin de cdigo: R , = 2 + 8 + 1 = 11.
A continuacin, calcula R, como R - R, = 29 - 11 = 18.
Puesto que no se encontraron defectos durante la compilacin, todo el tiempo de compilacin es tiempo de valoracin. As, c,= 5 y c,= o. Puesto que no se encontraron defectos durante las pruebas, todo el tiempo de pruebas es tiempo de valoracin. As, P, = 10 y P, = O.
276
Ahora, con estos valores, calculamos los costes de valoracin y fallos de la siguiente forma:
+ Valoracin CDC = 100*(RV C,+ Pv) / (tiempo total de desarrollo)

= 100*(18
+ 5 +lo) / 262 = 100*33/262 = 12,60%
Fallos CDC
= 100*(RF+ C,+ P,) / (tiempo total de desarrollo) = 100*(11 + O +O) / 262 = 100*11/262 = 4,20%
Estos valores son algo diferentes a los calculados anteriormente. Se obtiene un valor significativamente ms alto de V/F de 3,O en vez de 1,93. Puesto que los valores de V/F y CDC son ms precisos y bastante sensibles a los tiempos de reparacin de defectos, no deberas utilizar este mtodo a menos que ests midiendo los tiempos de correccin con un cronmetro. Tambin tendrs como objetivo un valor mayor de V/F ya que ahora un valor de V/F de 2,O probablemente presentar muchos defectos en las pruebas.
RESUMEN
El coste de calidad (CDC) mide la calidad de un proceso software en trminos de 3 componentes: costes de valoracin, de fallos y de prevencin. El PSP utiliza clculos simplificados del CDC. El coste de valoracin se calcula dividiendo el tiempo de revisin de cdigo por el tiempo total de desarrollo y multiplicando por 100. Este clculo ignora los tiempos de correccin durante la revisin de cdigo. El coste de los fallos se calcula dividiendo la suma de los tiempos de compilacin y pruebas por el tiempo total de desarrollo y multiplicando por 100. Este clculo ignora los tiempos de compilacin y pruebas libre de defectos. La relacin Valoraciflallos (VE) mide la calidad del proceso. Se calcula dividiendo el valor CDC de la valoracin por el valor del CDC de fallos. La relacin V/F indica la cantidad relativa dedicada a encontrar y corregir defectos antes de la primera compilacin. El valor de V/F tambin indica la probabilidad de encontrar defectos del programa en las pruebas. Valores de V/F menores de 1 generalmente indican que se encontrarn muchos defectos en las pruebas, mientras que valores superiores a 2 indican que se encontrarn pocos defectos en las pruebas. Cuando se encuentran pocos defectos en las pruebas, esto indica generalmente que el programa tiene pocos defectos residuales. Aunque los clculos simplificados de CDC son ahora adecuados, puedes querer utilizar clculos ms precisos de CDC cuando trabajes en grandes proyectos.
277
EJERCICIO 19
Como ejercicio, calcula el valor de VA? para todos los programas que has escrito en este curso. Determina el nmero de defectos/KLOC en las pruebas para dichos programas y muestra el valor de V/F frente a los defectos/KLOC en las pruebas, en un grfico similar al mostrado en la Figura 19.1 Entrega copias del Cuaderno de Registro de Tiempos y del Resumen Semanal de Actividades que no hayas entregado previamente. Tambin, entrega acabado el Resumen del Plan de Proyecto del PSP, el Cuaderno de Registro de Defectos y la Lista de Comprobacin para la Revisin de Cdigo para cada programa. Incluye los valores Planificados, Reales y Hasta la Fecha de los tiempos de desarrollo, de los defectos introducidos, de los defectos eliminados, del rendimiento y de la relacin VE.
CAPITULO 20
Un compromiso personal con la calidad
El trabajo de calidad es importante para tus jefes, clientes y para ti mismo. Este captulo discute por qu deberas establecer la calidad como tu mxima prioridad personal.
20.1
LA IMPORTANCIA DE LA CALIDAD
Como ingeniero de software, la calidad de los programas que produzcas tendr una importancia crtica para tus jefes y clientes. El software se utiliza en muchas aplicaciones y los defectos del software pueden causar perjuicios econmicos e incluso algn dao fsico. Cuando los programas que escribes son utilizados para trabajos financieros o procesamiento de textos, sus defectos pueden ser molestos y costosos, pero no es probable que nadie sea asesinado o quede mutilado. Cuando tu software forme parte de un sistema de vuelo de aviones, de conduccin de coches, de gestin del trafico areo, de funcionamiento de una fbrica o control de plantas nucleares, tus defectos no podran detectarse y posiblemente tendran consecuencias peligrosas. Ha habido personas que han muerto por defectos del software [Leveson]. Aunque no ha habido muchas fatalidades hasta ahora, sin du-
280
da los nmeros crecern algo. Esto es porque, a pesar de todos los problemas, el software no se desgasta o deteriora. Es idealmente adecuado para aplicaciones crticas que implican seguridad. Por ejemplo, cuando las actuales plantas generadoras de energa nuclear fueron construidas, los instrumentos de control eran electromecnicos. Era la tecnologa ms fiable conocida hasta ese momento. Pasados los aos, sin embargo, esos primeros instrumentos se han deteriorado gradualmente y han sido reemplazados. Hoy, los sistemas de control ms fiables estn informatizados. Mientras la primera generacin de controladores nucleares era sencilla y utilizaba relativamente poco software, los sistemas de control ms sofisticados del futuro implicarn cantidades crecientes de cdigo. Esto significa que la calidad del software ser cada vez ms importante para aquellos que construyan y gestionen plantas generadoras de energa nuclear. Ser tambin importante para cualquiera que viva cerca. La misma tendencia es aplicable a cada campo. Los sistemas de control informatizados son tan verstiles, econmicos y fiables que los veremos en casi todos los aspectos de nuestras vidas. Es importante que todos los ingenieros de software reconozcan que su trabajo podra tener serios impactos sobre la salud, seguridad y el bienestar de muchas personas.
20.2
EL AUMENTO DEL RIESGO ASOCIADO A LA POCA CALIDAD

Cualquier defecto en una pequea parte de un gran programa podra, potencialmente, causar serios problemas. Puede parecer improbable que un error tonto en una parte remota de un gran sistema fuese potencialmente desastroso pero, en efecto, estas son las fuentes de problemas ms frecuentes. La razn es que los sistemas software son distintos a los sistemas mecnicos, donde los ingenieros pueden construir una proteccin mecnica. Diseando adecuados sistemas de seguridad mecnica, los ingenieros pueden hacer que muchas clases de accidentes o fallos sean prcticamente imposibles. Ejemplos comunes aqu son los dispositivos de seguridad utilizados en las prensas para los trabajadores. La prensa tiene acoplado mecnicamente un dispositivo de seguridad, de tal forma que cuando la mquina estampa, los operadores no pueden tener nunca las manos dentro. Con los sistemas software, sin embargo, los sistemas de seguridad generalmente tambin se hacen con software. Las protecciones de software, son solamente efectivas cuando el software cumple las reglas y normas del sistema. Esto significa que los defectos de software que causan la ruptura de estas normas podran tener consecuencias impredecibles. Aunque la seguridad del sistema se enfocase desde el nivel del sistema y se utilizasen protecciones hardware y software, no sera siem-
281
pre prctico. Por lo tanto, para tener sistemas verdaderamente seguros debemos esforzarnos en tener un software libre de defectos. El diseo de grandes sistemas multiusuario en tiempo real puede ser enormemente complejo. A estas complejas cuestiones de diseo se les presta una gran atencin. Aunque las cuestiones difciles de diseo son normalmente estudiadas, revisadas y probadas con gran cuidado, a los problemas de diseo sencillos se les presta menos atencin. Como resultado tenemos que, la causa ms comn de los problemas con grandes sistemas software, son simples descuidos y tonteras. Aunque muchos de estos errores tontos se detectarn en la integracin y pruebas del sistema, algunos seguirn ocultos en el proceso de pruebas y cuando el usuario final utilice el sistema.
El problema es que los ingenieros del software, a menudo, confunden sencillez con facilidad. Consideran que sus constantes errores sencillos sern fciles de localizar. Se sorprenden, al enterarse, de que dichos errores triviales como: la omisin de un signo de puntuacin, la denominacin errnea de un parmetro, establecer una condicin incorrecta o la terminacin errnea de un bucle, podran pasar las pruebas sin ser detectados y causar serios problemas cuando el usuario utilizase la aplicacin. Estos son los tipos de cosas que causan casi todos los problemas, y a las que los suministradores de software dedican millones de dlares a localizar y corregir.
La calidad de los grandes programas depende de la calidad de los pequeos programas que lo forman. As, para producir grandes programas de alta calidad, cada ingeniero del software que desarrolla uno o ms de estos mdulos, debe hacer su trabajo con gran calidad. Esto significa que todos estos ingenieros deben estar personalmente comprometidos con la calidad. Cuando estn comprometidos, controlarn y gestionarn sus defectos con un cuidado tal, que los pocos defectos que tengan sus aplicaciones se encontrarn posteriormente en la integracin, en las pruebas del sistema o por los clientes. Cuando los ingenieros estn personalmente comprometidos con la calidad, estn orgullos de sus logros. Saben cunto cdigo han producido y cuntos defectos han encontrado otros en sus productos. Algunos ingenieros me comentan, cunto tiempo haca que alguien no haba encontrado un defecto en los programas que ellos haban hecho. Cuando los ingenieros del software no estn personalmente comprometidos con la calidad, no le dan importancia a esto. Ellos me dirn que en las pruebas encontrarn muchos de los defectos y que el resto que queda, se encontrarn y corregirn fcilmente. No es sorprendente que, cuando los ingenieros piensan de esta forma es poco probable que hagan productos de calidad.
282
20.3
CMO HACER UN COMPROMISO CON LA CALIDAD

Muchos ingenieros del software ven los defectos como bugs (gusanos). Los tratan como algo que arrastran desde alguna parte, pero no es algo de lo que se sientan responsables. Eso es un error. Los defectos son introducidos por los ingenieros y cuando un programa tiene defectos, jes defectuoso! El ingeniero que hizo ese programa hizo un programa defectuoso. Cuando los ingenieros estn comprometidos con la calidad, prestan atencin y cuando prestan atencin, son muy cuidadosos con su trabajo. Cuando son muy cuidadosos, producen mejores productos. El primer paso para producir un software de calidad es decidir que la calidad es importante. El segundo paso es establecer el objetivo de producir programas libres de defectos. Para tener oportunidad de cumplir esta meta, debes medir la calidad de tus programas y dar los pasos que mejoren dicha calidad. Como seres humanos, todos introducimos defectos ocasionalmente. El reto es gestionar nuestra falibilidad. Esto, sin embargo, es una lucha interminable. No puedes aprender unos pocos trucos de calidad y relajarte. Los productos software del futuro sern ms sofisticados y ms complejos. Te enfrentars a problemas que estn constantemente cambiando. La cuestin no es si puedes hacer un trabajo libre de defectos, sino, si eres lo bastante cuidadoso para continuar hacindolo. Esto no solamente har que t y tu organizacin sean ms productivos, sino que tambin tengas ms satisfaccin por tu trabajo.
TUS OBJETIVOS PERSONALES

Qu es lo que deseas de la vida? Esta es una gran pregunta que mucha gente tiene problemas al responder. Merece la pena considerar algunas cosas al pensar en la respuesta. Una forma de conseguir la satisfaccin en un trabajo, es tener estatus o poder. Las personas pueden conseguir esto siendo jefes u ocupando cargos en donde desempean un servicio importante. El poder y el estatus pueden ser indirectos como ganar gran cantidad de dinero, trabajar para una compaa importante o conducir un coche fabuloso. Estas son todas las partes de ser alguien. Aunque no hay nada malo en lo del estatus, eso es temporal. Puedes ocupar un cargo importante por un tiempo, pero tarde o temprano, tu siEs habitual usar el trmino bug (gusano) para denotar los errores que hay en un programa. El autor se refiere a esta forma de referenciar los errores.
283
guiente paso ser descender. La prdida de estatus puede dar lugar a una crisis. Algunas personas quedan sumidas en la tristeza cuando pierden por primera vez un puesto de trabajo importante. Es fcil confundir la importancia de un puesto de trabajo con la importancia personal. He conocido a directores que quedaron chafados por una degradacin. Se haban construido una imagen de s mismos como personas importantes. Mientras tenan un gran puesto de trabajo, todo el mundo les trataba como personas importantes. En el momento que perdieron el trabajo, sin embargo, eran como cualquier otra persona. Nadie se preocupaba de lo que decan y si dejaron de tener un tratamiento especial. Haban perdido su lujoso despacho y no tenan secretaria. Esto puede suponer un fuerte shock que lleva a algunas personas a tener una crisis nerviosa, ataques al corazn o crisis familiares. Su recompensa era el estatus y se perdi.
20.5
LAS RECOMPENSAS DEL LOGRO

Es necesario decidir lo que t quieres. Piensa por adelantado. Cuando finalmente te jubiles, qu satisfaccin te gustara tener de tu vida? Sugiero que lo que has hecho ser ms reconfortante que lo que has sido. Si, por ejemplo, planificas trabajar como ingeniero, probablemente tengas el instinto de un constructor. Puede ser que construyas sistemas o componentes. Al final podras crear mtodos o procesos. O puedes tener una inclinacin cientfica y construir teoras o investigar cmo generar el conocimiento fundamental. De todo lo que construyas, sin embargo, la calidad ser la clave. Tendrs poca satisfaccin del trabajo descuidado. De algn modo, aunque nadie lo averige, sabrs que tu trabajo era descuidado. Esto destruir tu orgullo en el trabajo y limitar tu satisfaccin con la vida. No puedes honestamente decirte a ti mismo que realmente crees en la calidad sin haberla conseguido ni una sola vez. Se pueden poner muchas excusas. Puedes satisfacer a otros con una respuesta oportuna, pero nunca te satisfars a ti mismo. Cuando hagas un trabajo de calidad, te sentirs orgulloso. Aunque nadie lo sepa, tu sabes que hiciste un trabajo de primera categora y ests satisfecho de que hiciste lo mejor. Una cosa sorprendente, es que el trabajo de calidad se reconoce. Puede que pase mucho tiempo, pero tarde o temprano el trabajo de calidad es reconocido. Si sabes esto, tendrs crdito para la calidad de tu trabajo. Hazte a ti mismo esta pregunta: quiero sentirme orgulloso de lo que hago?. Muchas personas responderan que s. Pero si realmente lo dices en serio, necesitas tener estndares personales y esforzarte en conseguir-
284
los. Cuando encuentres estos estndares, elvalos y esfurzate otra vez. Desafate a ti mismo a hacer un trabajo superior y te sorprenders de lo que puedes lograr.
REFERENCIA
[Leveson] Leveson, Nancy G. Safeware, System Safety and Computers. Reading, MA: Addison-Wesley, 1995.
A tiempo, en el Cuaderno de Registro de Tiempos 20, 2 1, 23, 26
A
abstraccin 237, 238 definicin 237 Ackerman, Frank A. 180, 181 actividad 20, 26 clasificacin 74 actividades discrecionales 80 actividades exigidas 80 anotacin de los datos actuales 212, 213, 214 anotaciones reales, en el Cuaderno de Trabajos tarea 49, 53 tiempo 49, 53 unidades 49, 53,70 Ashton Tate 3 asignacin de defectos 146
B
Brooks, Frederick P. 104, 1 12 Brown, Rita Mae 230,232 bugs 144
C
C (completado) 20 en el Cuaderno de Registro de Tiempos 25 C++ Codificacin Estndar 198 C++ Lista de Comprobacin para la Revisin de Cdigo 185
calidad 94, 250 compromiso personal con 163,279 definicin 141 hacer un compromiso con 282 importancia de 4,279 necesidad del trabajo de calidad 217 proceso 261 producto 247 riesgo asociado a la poca calidad 280 vase tambin coste de la calidad Carnegie Mellon University 2 CDC, vase coste de la calidad Chillarege, Ram 146, 161 Codificacin, 129 codificacin, estndares de 196 C++ 198 cdigo revisin de 166, 175, 229 Ada lista de comprobacin 186 antes de la compilacin 170, 171, 172 C++ lista de comprobacin 185 ejemplo de lista de comprobacin 184 guin 171, 189 lista de comprobacin 183 lista de comprobacin personal 193 objetivos 170 por qu la eficiencia 167 utilizacin de las listas de comprobacin para la revisin de cdigo 187 columnas, en el Resumen Semanal de Actividades 39 comentarios 20, 26 compilacin 128, 129 defectos, datos 172 tiempo 230,23 1
286
NDICE ANALTICO
versus defectos post-compilacin 272 versus defectos post-PSP 172 versus defectos postdesarrollo 173 versus defectos prueba de unidad 172 y pruebas, defectos 251,252 compilacin, revisin antes de la 170 compiladores 164 objeto 164 completadas, tareas 24,26 comprobacin de defectos 146 compromiso 87 como contrato 87 definicin 87 ejemplo 90 ejemplo en la industria 91 la gestin de compromisos no conseguidos 92 lista 95 personal 87 responsable 89,90 semanal, ejemplo 90 vase turnbin la gestin de los compromisos verdadero 8 compromisos no conseguidos, gestin 92 confianza 94 construccin, paquetes defectos de 146 contabilizacin de defectos 153 coste de la calidad (CDC) 264 clculo 265 clculo verdadero (CDC) 275 definicin 265 coste de los fallos 264 costes de encontrar y corregir los defectos 167, 168 criterios de entrada, en el Guin del Proceso del PSP 128 criterios de salida, en el Guin del Proceso del PSP 128 Cuaderno de Ingeniera 9, 11, 12 contenidos 15 Cuaderno de Registro 148, 154 cabecera 150 completado 148 de Tiempos 24 defecto corregido 150 descripcin 150 ejemplo 15 1, 195,274 eliminar1 50 formulario 149 instrucciones 150 introducido 150 nmero 150 propsito 150
tiempo de correccin 150 tipo 150 utilizacin 154 diseo 12 ejemplo 14 eliminacin ahorro 221 economa 2 17 eficacia 219 estrategia 263 paradoja 262 problema 2 18, 250 rendimiento 250 tasas, mejora 229 tiempo 2 19 tipo estndar 146 usos de 12 Cuaderno de Trabajos 47, 159 cabecera 53 con datos de tamao 68 ejemplo 5 1 formulario 50 instrucciones 53, 70 medidas de tamao 65 proceso 53 propsito 53 sugerencias 49 Curtis, Bill236, 246
D
defecto encontrado, en el Cuaderno de Registro de Defectos 150 defecto datos 147 anlisis 191 clasificacin 192 ejemplo 206 utilizacin 203 definicin 143 densidad, definicin 204 estimacin 205 introduccin tasas, reduccin 220,230 y eliminacin, ejemplo 222 y eliminacin, experiencia 21 9 tasas 204,205,221 tiempos de correccin 169 defectos 4, 141, 247 compilacin 172 versus postdesarrollo 173 versus defectos post-PSP 173 versus defectos prueba 172,25 1,252.27 1 contabilizacin 153
287
coste de encontrar y corregir 167, 168 datos 172 de datos 146 de documentacin 146 de entorno 146 de funcin 146 diseo, 233 documentacin 146 eliminados, plan, en el Resumen del Plan del Proyecto 2 I 1 entender 147 entorno 146 estimacin 201, 204 formas de encontrar y corregir 164 localizacin 163 localizacin con revisiones 169, 170 funcin 146 importancia de 142 interfaz 146 introducidos, plan, en el Resumen del Plan del Proyecto 2 1 1 gestin 221 pasos para encontrar 163 por hora, clculo 223, 228 por que hay que encontrar pronto 167 prueba 234 sistema 146 tiempo para encontrar 178 versus bugs 144 y calidad 142 DefectodKLOC 201, 204 definicin 204 densidad 204 en el Resumen del Plan del Proyecto 2 1 0 seguimiento 205 versus aos de experiencia 202,203 definiciones abstraccin 236 calidad 141 codificacin estndar 196 coste de la calidad (CDC) 264 coste de los fallos 265 coste de prevencin 265 coste de valoracin 264 defectos 143 densidad de defecto 204 estndar 196 lista de comprobacin 183 proceso 46, 126 producto 46, 126 proyecto 46, 126 relacin valoracin/fallos (V/F) 267 rendimiento 2 19, 25 1 rendimiento del proceso 225 tarea 46, 126 trabajo 47, 126
descripcin en el Cuaderno de Registro de Defectos 150 en el Cuaderno de Trabajos 53 diagrama lgico 241 Digital Equipment Corporation 169 disciplina, definicin 3 diseo 128 defectos 233 causas 237 identificacin 235 impacto de 238 naturaleza de 233 vase tambin defectos definicin 235 proceso 236 representacin 239 representacin grfica 240 representaciones en seudocdigo 242 diseo en seudocdigo ejemplo 242 representacin 242
E
eliminacin, en el Cuaderno de Registro de Defectos 150 Embry-Riddle, Universidad Aeronutica (UAER) 108 errores, definicin 143 estimacin del tamao del programa 62 estimado, tiempo en el Cuaderno de Trabajos 47,53,70 exactitud de las estimaciones 10. 122
F
FAA (Federal Aviation Administration) 2 Fagan, Michael 176, 180 formularios, por qu utilizarlos 18 Fuerzas areas de los EE.UU. 183
G
Gantt, Diagrama 100, 101 ejemplo 102, 106 registro del estado en 107 registro del progreso en 106 gestionar compromisos 87 cmo 95 consecuencias de no 94 importancia de 93 vase tambin compromiso Gilb, Tom 176, 180 Gries, David 244, 246
288
NDlCE ANALTiCO
Hasta la Fecha % Hasta la Fecha vase tambin Resumen del Plan del Proyecto, % Hasta la Fecha ejemplo del clculo 135, 136 en planificacin de defectos 157 ejemplo del clculo 135, 136 mx, en el Cuaderno de Trabajos 47,48,49,
Lista de Comprobacin para la Revisin de Cdigo en Ada 185, 193 LOC nuevas y cambiadas 1 1 6 LOC/Hora, en el Resumen del Plan del Proyecto 116
M
Marina de los Estados Unidos 4 medida definicin 5 proceso de 26 1 mejora 4,s vase tambin mejora del proceso mtodos formales 244 Microsoft NT 219 minutos/LOC 63 en el Resumen del Plan del Proyecto 1 1 6 Motorola 2 1 8
53
mn, en el Cuaderno de Trabajos 47,48,49, 53 tiempo, en el Cuaderno de Trabajos 47,48,
49,53
tiempo, en el Resumen Semanal de Actividades 40 unidades, en el Cuaderno de Trabajos 47,
48,49,53
vase tambin Resumen del Plan del Proyecto, Hasta la Fecha velocidad, en el Cuaderno de Trabajos 47,
48,49, 53 HumphreyWattsS.112,113,123,126,139,144, 146,161,176,180,202,215,232,250,259
N
NASA (National Aeronautics and Space Administration) 184 necesidad del trabajo de calidad 217 nmero de semanas, en el Resumen Semanal de Actividades 40 nmero, en el Cuaderno de Registro de Defectos 150
1
IBM (International Business Machines Corporation) 43,146,238 defectos informados por el cliente 165 importancia de la calidad 4,279 inspecciones 174,176 interfaz, defectos 146 interrupciones, en el Cuaderno de Registro de Tiempos 19,20 gestin 22 tiempo 26 introducido, en el Cuaderno de Registro de Defectos 150
O
ONeill, Don 178,180 objetivos, personales 282
P
Pareto, distribucin 194 planes definicin 47 exactitud 10 planificacin 127, 128 beneficio 1 0 habilidad 10 vase tambin planificacin del perodo, planificacin del producto planificacin del perodo 29 importancia de 3 1 relacin con la planificacin del producto 30 por qu ayuda la lista de comprobacin 183 por qu contabilizar defectos 153, 154 por qu encontrar pronto los defectos 167 postmortem 128,129
L
las recompensas del logro, 283 Leveson, Nancy G. 2, 8,279,284 lneas de cdigo (LOC) 60,62 contabilizacin 60 lista de comprobacin 183 definicin 183 mejora 194 personal 188, 196 por qu ayudan 183 vase tambin Lista de Comprobacin para la Revisin de Cdigo
289
prevencin, costes de 265 priorizar el tiempo 79 vase tambin tiempo Proceso Software Personal (PSP) 2, 3,7, 126, 146, 155, 163,218,222,240,248,257 flujo de 127 rendimiento 263 proceso calidad 26 1 definicin 46, 126 en el Cuaderno de Trabajos 53 Guin 127, 156, 175, 190, 208 criterios de entrada 128 propsito 128 medida 261 pasos para la mejora 5 por qu utilizarlo 125 rendimiento 225 productividad 59 producto calidad 247 definicin 46 planes contenidos 45 definicin 45 por qu son tiles 44 planificacin 29,43, 113 importancia de 3 1 necesidad 43 proceso 57 relacin entre planificacin del periodo 30 tamao 57 utilizacin de tiempos y medias 54 programa funciones 64 tamao 59, 1 17 ejemplo de estimacin 666, 118 , estimacin 62 formulario de estimacin 65 medicin 58 programaciones 99 hacer 101 gestin 99 necesidad 99 pasos para hacer 1O 1, 103 sugerencias de seguimiento 106, 108 prototipado 258 proyecto definicin 46 planes, definicin 1 13 planes, necesidad para 113 Resumen del Plan 114, 115, 130, 157, 174, 176,209,224,266 cabecera 121, 131
defectos eliminados 21 1 defectoshora, clculo 223 defectos introducidos 21 1 defectos/KLOC 210 ejemplo 116, 132, 133, 134, 160, 179, 207, 212 en negrita 133 formulario 114,130 Hasta la Fecha 131 clculo, ejemplo 135, 136 instrucciones 121, 131, 158, 177, 210, 226, 268 LOC/Hora 121, 131 clculo 116 minutosLOC 121, 131 clculo 1 16 propsito 121, 131 rendimiento, clculo 225, 228,229 seccin resumen 116 sombreado 130 tamao programa (LOC) 121, 13 1 tiempo en fase 120, 121, 131 seguimiento 105 seguimiento de problemas 106, 108 prueba 128,129 defectos 234 categoras 234 datos 172 introducida por fases 234 vase tambin defectos, prueba versus VF 270,27 1 horas versus VF 272,273 tiempo 230 pruebas 248 filtro de 249 sistemas complejos 249 PSP, vase Proceso Software Personal puntos de control 99, 104 ejemplos 104 noadecuados 104 sugerencias 104 y fases 129
R
Ragland, Bryce 178, 180 recogida de datos de tiempo, por actividad 74 recompensas del logro 283 registro de tiempo 11 ideas para 25 Relacin Valoracin/Fallos 267 clculo 267, 268 definicin 267 utilizacin 271,272,273
290
NDICE ANALTICO
rendimiento 219, 250,263 beneficios del 100%de rendimiento 256 clculo 225, 25 1, 268 ejemplo 253 estimacin del rendimiento definitivo 254 experiencia 257 frmula 25 1 mejora 254,255 personal 263 valores 253 representacin grfica del diseo 240, 241 respeto 94 reutilizar 117 revisiones en parejas 174 Russell, Glen W. 178, 180
T
tamao 59 estimacin, para programas grandes 64 mximo 53 medicin 58 medidas en el Cuaderno de Trabajos 65 objetivos 62 precauciones sobre 58 otras medidas de tamao 62 vase tambin tamao del producto, tamao del programa tarea definicin 46 en el Resumen Semanal de Actividades 39 tareas, completadas 24,26 tasas de revisin, mejora 273 tiempo medio 38 vase tambin tiempo tiempo variable 79, 80 sugerencias para gestionar 84 tiempo Cuaderno de Registro 17, 20, 29, 8 1 C (completado) 24 cabecera 26 completar 20 con datos pequeos 67 ejemplo 23, 36,52 formulario 2 1 ideas 25 instrucciones 20,26 mantener en el Cuaderno de Ingeniera 25 U (unidades) 24 datos 11 distribucin 74 encontrar ms tiempo 77 estimacin 77 ejemplo 75 gestin 82 hacer 75 gestin 9 elementos de 73 objetivo 85 pasos en 11 regias bsicas para 77 ideas para registrar tu tiempo 25 mximo 37 media 35 mnimo 37,53 perodos 19 por fase, en Resumen del Plan del Proyecto 120, 121, 131 por qu controlar 17 priorizacin 79
S
seguimiento del tiempo 17 semanal ejemplo de compromisos 90 estimacin de la actividad 79 ejemplo 80 Resumen Actividades 29, 31,74 cabecera 39 ejemplo 34,76 formulario 32 instrucciones 39,40 propsito 39 utilizacin 38 resumen del tiempo 82 ejemplo 9 1,92 tiempo programado y estimado, ejemplo 83 totales, en el Resumen Semanal de Actividades 39 Shooman, M. L. 178, 181 smbolos de los diagramas 241 software cronmetro 22,276 estndar, definicin 196 fin, en el Cuaderno de Registro de Tiempos 26 ingeniera calidad, vase calidad hechos de la vida 95 medidas proceso 4 problemas que causa 11 trabajo 1 inicio, en el Cuaderno de Registro de Tiempos 26 proceso de desarrollo 125 sintaxis, defectos 145 sistema, defectos 146
291
registro 18 resumen 33 seguimiento 17 tiempos de correccin 8 1 tiempos incluida la ltima semana, en el Resumen Semanal de Actividades, 40 tiempos y medias del perodo 35 clculo 35 tipo 146 totales, en el Resumen Semanal de Actividades 39 trabajo definicin 46 nmero, en el Cuaderno de Trabajos 53
utilizacin de una lista de comprobacin para la revisin de cdigo 187
V
VE, vase Relacin ValoracidFallos valor ganado 108, 110 ejemplo 109, 111 estimacin 110 seguimiento 108 van Genuchten, Michael 178, 181
W
Weller, E. E 178, 181
U
U (unidades) 20, 26
UAER (Universidad Aeronutica de EmbryRiddle) 108
Z
Zachary, G . Pascal219,232
MATERIAL DE APOYO
En la Introduccin al Proceso Software Personal, Watts S. Humphrey proporciona una serie de ejercicios para demostrar el proceso software personal y su utilizacin.
El material de apoyo de la pgina web est disponible para ayudar a los estudiantes y lectores a hacer sus ejercicios, los anlisis requeridos y los informes. El material contiene kits para hacer los ejercicios indicados en el texto, incluyendo copias de las tablas del libro, y hojas de clculo para hacer el anlisis de datos de los ejercicios. Los lectores encontrarn el material como un complemento prctico del libro. Puede obtenerse en la pgina web de la editorial, cuya direccin es:
( 1 ) http://www.librosite.net/humphrey
Ms informacin para obtener una informacin actualizada de este libro, sus apndices y de otros trabajos de inters para profesores de ingeniera del software y profesionales, se puede acceder a la ltima informacin sobre los libros de esta materia de la editorial en la siguiente direccin de Internet (www.pearsoneducacion.com).

Calidad Del Software

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Calidad Del Software

Cargado por

Copyright:

Formatos disponibles

INTRODUCCI~N AL PROCESO SOFTWARE PERSONALsM

INTRODUCCIN AL PROCESO SOFTWARE PERSONALsM

Datos de catalogacin bibliogrfica

Introduccin al Proceso Software Personal M

JSBN: 84-7829-052-4 Depsito Legal: M- Impreso por: Sprint, S.L.

IMPRESO EN ESPAA - PRINTED IN SPAIN

Este libro ha sido impreso con papel y tintas ecolgicos

A BRBARA Mi amo< mi esposa, mi vida

Prlogo de los profesores Prlogo de los estudiantes Prlogo

El trabajo del ingeniero del software

La gestin del tiempo

El control del tiempo

Planificacin de perodos y productos

La planificacin del producto

INTRODUCCIN AL PROCESO SOFTWARE PERSONAL

El tamao del producto

La gestin del tiempo

La gestin de los compromisos

La gestin de las programaciones

El plan del proyecto

El proceso de desarrollo del software

INTRODUCCINAL PROCESO SOFTWARE PERSONAL

Listas de comprobacin para la revisin del cdigo

La economa de eliminar defectos

INTRODUCCIN AL PROCESO SOFTWARE PERSONAL

Calidad del producto

La calidad del proceso

Un compromiso personal con la calidad

ndice analtico Pginas suplementarias

Prlogo de los profesores

PRLOGO DE LOS PROFESORES

INTRODUCCINAL PROCESO SOFTWARE PERSONAL

Prlogo de los estudiantes

PRLOGO DE LOS ESTUDIANTES

POR QU HE ESCRITO ESTE LIBRO?

LA UTILIZACIN DEL PSP

CMO SE BENEFICIARN LOS ESTUDIANTES

CMO PUEDEN UTILIZAR ESTE LIBRO LOS INGENIEROS QUE TRABAJAN

INTRODUCCI~N AL PROCESO SOFTWARE PERSONAL

ALGUNAS SUGERENCIAS PARA LOS PROFESORES

UNA ESTRATEGIA DE ENSEANZA

INTRODUCCI~N PROCESO SOFTWARE PERSONAL AL

PREPARACIN DEL PROFESOR

El trabajo del ingeniero software

~ Q U LA INGENlERA DEL SOFWARE? ES

EL TRABAJO DEL INGENIERO DEL SOFTWARE

POR QU ES IMPORTANTE UNA BUENA INGENIERIA?

EL PROCESO SOFTWARE PERSONAL

INTRODUCCINAL PROCESO SOFTWARE PERSONAL

LA DISCIPLINA DEL TRABAJO DE ALTA CALIDAD

EL TRABAJO DEL INGENIERO DEL SOFTWARE

LA IMPORTANCIA DEL TRABAJO DE ALTA CALIDAD

&MO MEJORAR LA CALIDAD DE TU TRABAJO?

INTRODUCCI~NAL PROCESO SOFTWARE PERSONAL

EL TRABAJO DEL INGENIERO DEL SOFTWARE

Definir el objetivo de calidad

Medir la calidad del producto

Realimentar y continuar mejorando Medir los resultados

Comparar los resultados con el objetivo

Figura 1.1 El proceso de mejora.

EL OBJETIVO DE ESTE LIBRO

INTRODUCCIN AL PROCESO SOFTWARE PERSONAL

EL TRABAJO DEL INGENIERO DEL SOFTWARE