Tecnicas Programacion Personal

Tcnicas de Programacin Personal con Calidad
Modelo Paracurricular Desarrollador de Software 2004 V.1.0.0.

I

CURSO

TCNICAS DE
PROGRAMACIN PERSONAL
CON CALIDAD


II
Introduccin

En la inmensa mayora de los pases los sistemas sociales, polticos, econmicos
y hasta culturales dependen en gran medida de complejos sistemas basados en
computadoras, y evidentemente en software. La dependencia no es
exclusivamente hacia su interior, sino que las relaciones entre ellos son tambin,
en muchos casos, regidas por tecnologa. El desarrollo de software de complejidad
y tamao cada vez mayores ha sido inevitable. Aunado a esto, la necesidad de
que los productos de software sean seguros y con calidad, es un reclamo
constante.

Roger Pressman, en su libro de ingeniera de software cuarta edicin, escriba: El
software es casi ineludible en un mundo moderno. A medida que nos adentremos
en el siglo XXI, ser el que nos conduzca a nuevos avances en todo, desde la
educacin elemental a la ingeniera gentica cualquier cometario a esto sale
sobrando.

El uso y el desarrollo de software se ha vuelto crtico y en muchos aspectos
vitales; quiz sin que lo percibamos dependen de l directa e indirectamente no
slo vidas, sino la calidad de sta. Por natural necesidad hemos transitado de la
no tan simple programacin de computadoras a lo que ahora se conoce como
ingeniera de software. Una diferencia entre estos dos puntos es que el
programador solitario de antao ha sido sustituido por un equipo de especialistas
de software. Esta diferencia, aunque bsica, no es la nica. El trmino ingeniera
da una profundidad que es necesario entender completamente.

El desarrollo de software a final de cuentas tiene como objetivo la entrega de un
producto, y como tal, este producto tiene un usuario. No era posible que pasara
mucho tiempo sin que la comunidad que desarrolla software y los mismos usuarios
se percataran de que este hecho exiga darle al desarrollo de software otras
dimensiones.

Si bien en sus inicios el desarrollo de software era artesanal, y en alguna medida
sigue sindolo, era necesario incorporarle al menos por analoga con otras
disciplinas e industrias: procesos, mtodos tcnicos y de gestin, as como
herramientas. Evidentemente a la par, o quiz de forma ms adecuada mediante
la creacin de una disciplina de estudio, de investigacin y de aplicacin, que
fundamentalmente tomara el desarrollo de software como leit motiv La Ingeniera
de Software es esta disciplina y es una disciplina joven.

El principal objetivo es introducir disciplina en el proceso de desarrollo de software
del individuo. Mediante TCNICAS DE CALIDAD PERSONALES DE
PROGRAMACIN se describe el desarrollo de programas pequeos desde la


III
asignacin del problema hasta las pruebas de unidad dejando fuera todo lo
relacionado a manejo de equipos de proyecto y estructura de la organizacin

Agradecimiento y Reconocimiento

Despus de una ardua tarea de investigacin se ha logrado la creacin de una
obra vasta en conocimiento en el desarrollo de las Tecnologas de la Informacin y
Comunicacin.

La presente obra no hubiera sido posible sin la valiosa aportacin de destacados
autores y especialistas en la materia. Es por ello que a manera de reconocimiento
queremos agradecer su participacin:

TCNICAS DE PROGRAMACIN CON
CALIDAD

M. en C. Carlos Mojica Ruiz
Universidad Autnoma de Yucatn

Dr. Leonardo Chapela Castaares
Prodigia, S.A. de C.V.

Intencin Educativa

Desarrollar software no es solo producir lneas de cdigo (hacer programas) que al
final den un resultado esperado. Detrs de la programacin existen otros aspectos
importantes, por ejemplo: calidad, proceso, mtricas, planeacin, productividad
entre otros.

Con este curso sabrs obtener datos personales relativos a tu proceso de
desarrollar programas y con ellos podrs analizar, planear y mejorar la calidad de
tus programas. Esto ayudar a incrementar tu desempeo como programador
mediante el entendimiento y mejoramiento de tu proceso personal de
programacin.

La disciplina adquirida y la aplicacin de la tcnica aprendida durante el curso, te
harn ms competitivo en el mercado laboral.


IV

Objetivos Generales

Al terminar el curso, el alumno:

Tendr una disciplina y una tcnica para aplicar y mejorar su proceso
personal de desarrollo de programas y producirlos con mayor calidad.

Objetivos Especficos

Al terminar el curso, el alumno ser capaz de:

Definir e identificar los conceptos de la Ingeniera de Software y explicar su
importancia.

Conocer y describir cuales son las principales aplicaciones del software.

Analizar todas las etapas del proceso de Ingeniera de Software.

Aplicar las diferentes mtricas para la productividad y la calidad del
software.

Aplicar las diferentes metodologas diseo e implementacin del software.

Conocer y aplicar las diferentes estrategias para realizar las pruebas del
software.

Discutir la planeacin de proyectos y el proceso de planeacin.

Aplicar las diferentes metodologas de anlisis de requisitos del sistema y
del software .

Establecer planes para el desarrollo del proyecto y su manejo, que
involucran: definicin de qu se va a hacer, restricciones, objetivos,
estimados de tamao y esfuerzo requerido, recursos necesarios,
calendario, identificacin y manejo de riesgos.

Comparar el diseo de interfases mostrando el uso de las diferentes
herramientas de desarrollo.

Analizar en lneas generales de la construccin de un programa la
planificacin, desarrollo.


V

Determinar el comportamiento controlado del individuo en el desarrollo de la
ingeniera con resultado de alta productividad y calidad y resultados
predecibles.

Disear productos de software resolviendo aspectos bsicos de desarrollo.

Preparar y medir el trabajo de desarrollo de software mediante mtricas
establecidas.

Establecer el proceso y asignacin de pruebas a los sistemas que sean
capaces de mejorar el desarrollo de sistemas.

Metodologa

La prctica prevalece en este curso. A continuacin se describe el mtodo
generalmente empleado.

Comprobacin de Lectura

La tcnica de comprobacin de lectura tiene como finalidad fomentar en el alumno
la habilidad de leer, analizar y comprender. La comprensin se comprobar al final
de cada leccin, ya que se presenta una evaluacin por medio de preguntas muy
puntuales acerca de la lectura.

Los materiales que se utilizarn en este mtodo son una recopilacin de diferentes
autores de un tema, para homogenizar los conceptos e ideas referentes al tema.

La tcnica de comprobacin de lectura es una de las ms empleadas en los
procesos de enseanza-aprendizaje y tiene como finalidad conformar conceptos e
ideas propias al alumno, por lo que no pretende que se memoricen los temas
tratados.

Fuentes de Informacin

Humphrey W., "A Discipline for Software Engineering" READING, MASS. :
ADDISON WESLEY, SEI Series in Software Engineering, 1995.

Humphrey W., "Introduction to the Personal Software Process" READING,
MASS. : ADDISON WESLEY, SEI Series in Software Engineering, 1997.
Traduccin al Espaol: Introduccin al Proceso Software Personal,
Pearson


VI
Contenido
INTRODUCCIN .............................................................................................................................................................II
INTENCIN EDUCATIVA......................................................................................................................................... III
OBJETIVOS GENERALES ......................................................................................................................................... IV
OBJETIVOS ESPECFICOS ...................................................................................................................................... IV
METODOLOGA..............................................................................................................................................................V
FUENTES DE INFORMACIN..................................................................................................................................V
1. LA ADMINISTRACIN DEL TIEMPO................................................................................................................1
INTRODUCCIN.................................................................................................................................................................1
OBJETIVO GENERAL.........................................................................................................................................................1
OBJETIVOS ESPECFICOS.................................................................................................................................................1
1.1. UNA DISCIPLINA EN LA INGENIERA DE SOFTWARE.............................................................................................1
EJERCICIO........................................................................................................................................................................51
EJERCICIO........................................................................................................................................................................53
1.2. QU ES PSP?..........................................................................................................................................................56
1.2.1 Principios en los que se basa PSP............................................................................................................. 58
Ejercicio ................................ ................................ ................................ ................................ ................................ . 59
1.2.2. El modelo PSP.............................................................................................................................................. 60
1.2.2.1 El ciclo de Mejora Continua ...................................................................................................................... 63
FUENTES DE REFERENCIA BIBLIOGRFICA................................................................................................................73
2. EL TAMAO DEL PRODUCTO.......................................................................................................................... 74
INTRODUCCIN...............................................................................................................................................................74
OBJETIVO GENERAL.......................................................................................................................................................74
OBJETIVOS ESPECFICOS...............................................................................................................................................74
2.1. POR QU PREOCUPARNOS POR EL TAMAO DEL PRODUCTO?.........................................................................75
2.1.1. Tamao del Producto.................................................................................................................................. 75
2.1.1.1. Tamao y Esfuerzo...................................................................................................................................78
2.1.1.2. Tamao del Cdigo ...................................................................................................................................78
EJERCICIOS......................................................................................................................................................................84
3. LA PLANEACIN DEL PRODUCTO ................................................................................................................ 87
INTRODUCCIN...............................................................................................................................................................87
3.1. ESTIMACIN DEL TAMAO...................................................................................................................................88
3.2. MTODOS DE ESTIMACIN....................................................................................................................................90
3.2.1 Wideband-Delphi .......................................................................................................................................... 91
3.2.2 Estimacin por analoga.............................................................................................................................. 92
3.2.3 PERT ............................................................................................................................................................... 93
3.3. DISTRIBUCIN DEL TIEMPO EN LAS FASES.................................................................................................95
EJERCICIO DE PROGRAMACIN....................................................................................................................................95
4. LA AGENDA DE TRABAJO................................................................................................................................. 98
INTRODUCCIN...............................................................................................................................................................98
4.1. POR QU ES IMPORTANTE PLANEAR?.................................................................................................................99
4.1.1. Qu tomamos en cuenta para planear?...............................................................................................101


VII
4.1.2. Pasos para Planear...................................................................................................................................101
4.2. ESTIMACIN DE LA AGENDA..............................................................................................................................102
Ejemplo de una grfica de Gantt........................................................................................................................103
5. SEGUIMIENTO DE LA AGENDA DE TRABAJO.......................................................................................106
Ejemplo de Planeacin de la Agenda................................................................................................................107
5.1. COMPLETANDO EL PLAN.....................................................................................................................................109
5.2. VALOR GANADO...................................................................................................................................................110
5.2.2. Establecimiento del Valor Planeado ......................................................................................................110
5.2.2.1 Dndole seguimiento al plan.................................................................................................................112
5.3. PROYECTANDO LA FINALIZACIN DEL PROYECTO...........................................................................................113
EJERCICIO DE PROGRAMACIN...................................................................................................................................115
6. LA ADMINISTRACIN DE LOS DEFECTOS..............................................................................................118
INTRODUCCIN.............................................................................................................................................................118
OBJETIVO GENERAL.....................................................................................................................................................118
OBJETIVOS ESPECFICOS.............................................................................................................................................118
6.1. LA ADMINISTRACIN DE DEFECTOS..................................................................................................................119
6.1.1. Pero, qu es un defecto?.........................................................................................................................119
6.1.2. Defecto vs. Error ........................................................................................................................................119
6.1.3. Remocin vs. Prevencin..........................................................................................................................120
6.1.4. La Calidad del Software y los Defectos.................................................................................................120
6.1.5. Costos de Encontrar y Corregir Defectos .............................................................................................121
6.1.6. Quin debe remover los defectos?........................................................................................................121
6.1.7. El Proceso de Administracin de Defectos...........................................................................................121
6.1.8. Clasificacin de Defectos.........................................................................................................................122
6.1.9. Cmo saber qu registrar como defecto?............................................................................................127
6.1.9.1. Cmo encontrar los defectos?...............................................................................................................127
6.1.9.2. Densidad de Defectos..............................................................................................................................128
6.1.9.3. Eficiencia de Remocin ..........................................................................................................................128
EJERCICIO DE PROGRAMACIN...................................................................................................................................129


1
1. La Administracin del Tiempo
Introduccin

Uno de los puntos principales para poder mejorar en cualquier rea, es primero conocer
qu es lo que hacemos y cmo lo hacemos, por ello, debemos iniciar el registro de las
actividades al desarrollar productos de software y cunto tiempo invertimos en ello. Esta
informacin servir para mejorar nuestro proceso de desarrollo de software e iniciar la
creacin de una base de datos que nos sirva para predecir con mayor exactitud
nuestros trabajos futuros.

Comenzaremos estableciendo la necesidad de contar con mecanismos sistemticos
para producir software en tiempo, costo y calidad. Describiremos lo que es un proceso
de software, para lo cual nos centraremos a analizar lo que desarrollemos antes de
ponerlo en prctica. Tambin daremos una descripcin rpida de la metodologa de
PSP
, en la cual est basada este curso.

Objetivo General


Describir y aplicar mecanismos para la administracin del tiempo.


Distinguir entre las actividades productivas y aquellas que nos distraen del
trabajo.

Medir el tiempo que nos toma realizar las distintas actividades.

1.1. Una disciplina en la Ingeniera de Software

El objetivo de la Ingeniera de Software es proveer un marco de trabajo para mejorar la
capacidad individual de producir productos y brindar servicios de software de calidad,
de una manera sistemtica aplicando principios de ingeniera.


2
Da tras da el software esta presente en ms lugares y dispositivos de uso comn, as
por ejemplo, podemos encontrar hoy en da software en:

Juegos de vdeo.
Sistemas de navegacin area.
Sistemas controladores de automviles, navegacin martima.

El software ha dejado desde hace tiempo ser un ente de laboratorio, ha traspasado las
barreras de los grandes corporativos para estar instalado en mbitos de uso cotidiano.
Hoy en da, muchos pases han tomado como estrategia de desarrollo econmica el
impulsar la industria del software, entre ellos por ejemplo, Mxico. Muchas de las
comodidades modernas, que pasan desapercibidas contienen algn tipo de software,
como por ejemplo:

Dispositivos del hogar como: lavadoras, refrigeradores, hornos de microondas,
etc.
Dispositivos de control como: sealizadores, mquinas industriales, etc.
Sistemas mdicos.
Sistemas militares.

Son muchas las actividades que dependen o hacen uso del software.
A quin de nosotros nos gustara que los frenos de nuestro automvil fallaran
por un error en el software?
A quin le gustara que le explotara el horno de microondas o se perdiera el
avance en nuestro vdeo juego favorito por una falla en el software?
A quin le gustara que durante sus transacciones electrnicas financieras se le
perdieran algunos centavos?

Como forma de involucrar a los alumnos de entender y darse cuenta de la importancia
que representa tener productos de software correctos, completos, seguros y confiables,
dar ejemplos de desventajas e incomodidades que podran presentarse al funcionar mal
un programa de software.

La calidad de los productos y servicios de software debe estar entre las ms
altas!

La tica de los encargados de desarrollar software tambin debe estar entre las
ms altas!

Mucho se ha estado discutiendo ltimamente sobre la especialidad de las personas que
programan software. Ejemplos abundan, los ejecutivos de cuenta de un banco
desarrollando macros de hojas de clculo para realizar algunas prospecciones,


3
contadores haciendo lo mismo para elaborar las deducciones de impuestos y la
tendencia creciente de los sistemas de programacin orientados hacia el usuario final.
Sin embargo, de lo que estamos hablando es de la creacin de productos de software
que van a aportar, como por ejemplo, a realizar operaciones quirrgicas en personas,
controlar misiones espaciales, modificar sistemas financieros que mueven millones de
dlares en horas. El personal que desarrolle este tipo de software debe estar preparado
para ello y tener una solvencia profesional para poderle confiar la informacin y la
automatizacin de los procesos crticos.

Objetivos en el Desarrollo de SW

Tradicionalmente se ha fallado en cumplir con entregar el producto de software ha
tiempo, al igual, ms de las veces, se ha sobrepasado el costo establecido del producto
o servicio y al final, su calidad no ha resultado la esperada.

Los objetivos de la Ingeniera de Software se han definido, tomadas de algunas
definiciones de lo que es en s misma la Ingeniera de Software, como el desarrollo de
programas de computadoras en el tiempo, costo y calidad establecida. Sin embargo
existen muchos datos estadsticos que demuestran que estos objetivos no se alcanzan
en ms del 60% de los proyectos de desarrollo de software.

Un ejercicio interesante para los alumnos que les permitir conocer esta situacin es
crear un resumen del reporte anual de Standish Group sobre la situacin de la industria
del software.

Qu tan malo ha sido el desarrollo de Software?

A lo largo de la historia del desarrollo de software se tienen ejemplos de que en su
construccin no se sigue un enfoque sistemtico, ingeniera .

Por ejemplo, de datos tomados de estudios realizados por Standish Group se tiene:

Ao xito Fallo Cancelado
1994 16% 31% 53%
1996 27% 40% 33%
1998 26% 28% 46%

Despus de los primeros 35 seg. del despegue del Cohete Ariane 5 en 1996, se deton
porque amenazaba con caer en una zona poblada.

El sistema de bandas para el manejo de las maletas en el aeropuerto de Denver,
Colorado, EEUU, no funcionaba para la fecha de inauguracin del aeropuerto.

Durante la guerra del Golfo, un misil Patriot fall el detectar un misil Scud.


4
Todo por algn tipo de falla en el software!

11/11/2004 Tcnica Personal de Calidad en Programacin 16
Un pequeo problema puede
convertirse en un desastre

Aqu lo que se trata de mostrar es la reaccin en cadena que desata un fallo.

Ejercicio:

Qu otros ejemplos de desastres por culpa del software conoces?

Alguno donde se hayan perdido vidas humanas?

Investiga y documenta algunos de ellos

Este es un ejercicio que sirve para darnos cuenta de la reputacin que ha adquirido el
personal de desarrollo de software. Se puede complementar con un anlisis del cdigo
de tica para los Ingenieros de Software de la IEEE-ACM haciendo el anlisis entre los
preceptos del cdigo de tica y la descripcin de las situaciones presentadas en los
casos documentados de fallas por culpa del software.

Existe una novela, que narra las desventuras ocurridas en una compaa constructoras
de robots industriales, escrita por Richard G. Epstein para utilizacin exclusiva en la
academia. En esta historia se narra un accidente donde perdi la vida un operador de
estos robots y las investigaciones apuntan a diversos fallos en su construccin,
principalmente en la elaboracin del software que lo controlaba.

Se anexa un archivo en espaol sobre el Robot Asesino de Epstein, del cual, podr
encontrar el original en:
http://onlineethics.org/cases/robot/author.html
o
http://portal.acm.org/citation.cfm?id=382055&coll=portal&dl=ACM


5

Ingeniera de Software I

El Caso del Robot
Asesino


6
Programador de Silicon Valley Acusado por Homicidio no
Premeditado

El Error del Programa Caus la Muerte del Operador del Robot
Especial para el SENTINEL-OBSERVER de Silicon Valley
Jane McMurdock, Fiscal de la Ciudad de Silicon Valley, anunci en la fecha la acusacin
de Randy Samuels con los cargos de asesinato no premeditado. Samuels trabajaba como
programador en Silicon Techtronics, Inc., una de las empresas ms nuevas de Silicon
Valley en la arena de la alta tecnologa. El cargo involucra la muerte de Bart Matthews,
quien fuera muerto el pasado mes de mayo por un robot de la lnea de armado.
Matthews, quien trabajaba como operador de robot en Cybernetics, Inc., en Silicon
Heights, fue aplastado y muri a consecuencias de ello, cuando el robot que estaba
operando produjo un mal funcionamiento y comenz a oscilar su brazo violentamente.
El brazo del robot alcanz a Matthews, arrojndolo contra una pared. Matthews muri en
forma casi instantnea a causa de los golpes recibidos, en un caso que conmocion e
indign a muchos de Silicon Valley. De acuerdo con el dictamen de los cargos, Samuels
fue quien escribi la pieza del programa de computadora en particular, que fue la
responsable de la falla del robot. Hay una evidencia incriminatoria, anunci triunfante
McMurdock en una conferencia de prensa mantenida en la Corte.
Tenemos la frmula manuscrita, suministrada por el fsico del proyecto, que se supona
tena que programar Samuels. Pero negligentemente malinterpret la frmula, y esto
llev a una horrible muerte. La sociedad debe protegerse de los programadores que
cometen errores descuidadamente o de lo contrario nadie estar a salvo, y menos que
nadie nuestras familias e hijos, dijo.
El SENTINEL-OBSERVER ha podido obtener una copia de la frmula manuscrita en
cuestin. En realidad, existen tres frmulas similares, garabateadas en un papel
amarillo de un block borrador tamao oficio. Cada una de las frmulas describe el
movimiento del brazo del robot en una direccin: este-oeste, norte-sur y arriba-abajo.
El SENTINEL-OBSERVER mostr las frmulas a Bill Park, profesor de Fsica en la
Universidad de Silicon Valley. ste confirm que estas ecuaciones podan ser usadas
para describir el movimiento del brazo de un robot.
El SENTINEL-OBSERVER mostr entonces el cdigo del programa a Bill Park, escrito
por el acusado en lenguaje C de programacin. Preguntamos al Profesor Park, quien
est muy familiarizado con ste y muchos otros lenguajes de programacin, si el cdigo
era o no correcto para las frmulas dadas del brazo del robot.
La respuesta del Profesor Park fue inmediata: No puede ser! Parece que interpret los
puntos y de las frmulas como barras y, e hizo lo mismo con las x y las z. Se supona que
tena que usar las derivadas, pero en su lugar tom los promedios!. Si me preguntan,
est muy claro que es culpable!
El SENTINEL-OBSERVER no pudo contactar a Samuels para entrevistarlo. Se
encuentra profundamente deprimido por todo esto, nos dijo su novia por telfono. Pero,
Randy cree que va a aliviarse en cuanto pueda decir su versin de la historia.


7
Los que Desarrollaron al Robot Asesino Trabajaron bajo una
Enorme Presin
Silicon Valley, EEUU
por Mabel Muckraker

El SENTINEL-OBSERVER tom conocimiento hoy que Randy Samuels y otros que
trabajaron en el proyecto del Robot Asesino en Silicon Techtronics, estuvieron bajo
tremendas tensiones para finalizar el software del robot para el 1
de enero de este ao.

Segn una fuente bien informada, los altos niveles gerenciales advirtieron a los integrantes
del staff del proyecto que rodaran cabezas si no se cumpla el objetivo del 1
de enero.
Randy Samuels, programador de Silicon Techtronics, fue acusado la semana pasada bajo
los cargos de asesinato no premeditado en el ahora famoso caso del robot asesino.
Samuels escribi el software defectuoso que caus que el robot industrial de Silicon
Techtronics, Robbie CX30, aplastara y lesionara fatalmente a su operador, Bart Matthews.
Matthews era un operador de robot en Cybernetics, Inc. Conforme a la Fiscal de Silicon
Valley, Jane McMurdock, Samuels malinterpret la frmula matemtica, volviendo al
inofensivo Robbie un asesino.
Nuestra fuente informada, quien desea mantenerse en el anonimato y a la que llamaremos
Marta por el resto de este artculo, tiene un ntimo conocimiento de todos los aspectos
del proyecto Robbie CX30. Marta dijo al SENTINEL-OBSERVER que exista una enorme
friccin entre el Jefe de Divisin Robtica, Ray Johnson y el Gerente del Proyecto Robbie
CX30, Sam Reynolds. Se odiaban a muerte manifest Marta al SENTINEL-OBSERVER
en una entrevista exclusiva.
Hacia junio del ao pasado el proyecto se encontraba atrasado seis meses y Johnson
se puso furioso. Haba rumores de que echaran a toda la Divisin Robtica, que l
lideraba, si Robbie [el robot CX30] no daba muestras de ser un xito comercial. l
(Johnson) llam a Sam (Reynolds) a su oficina y realmente lo destruy. Quiero decir, uno
poda or los gritos desde el fondo de la oficina. Johnson le dijo a Sam que terminara el
proyecto para el primero de enero o de lo contrario rodaran cabezas.
Yo no estoy diciendo que Johnson le ordenara a Sam acortar camino, agreg Marta.
Creo que la idea de cortar camino estaba implcita. El mensaje fue: acorta camino si
quieres mantener tu puesto.
De acuerdo con documentos provistos por Marta al SENTINEL-OBSERVER, el 12 de
junio del ao pasado fueron agregados al proyecto Robbie CX30 veinte nuevos
programadores. Esto ocurri algunos das despus de la tormentosa reunin entre
Johnson y Reynolds que Marta cont.
De acuerdo a Marta, los nuevos contratados eran un desastre. Johnson, unilateralmente,
hizo los arreglos de estas contrataciones, seguramente desviando recursos de otros
aspectos del proyecto Robbie (CX30). Reynolds se opona con vehemencia a esto.
Johnson slo conoca acerca de la fabricacin de hardware. Esa era su especialidad. No
pudo haber entendido las dificultades que nosotros estbamos teniendo con el software de
la robtica. Usted no puede acelerar un proyecto de software agregando ms gente. No es
como en una lnea de montaje.


8
Segn Marta y otras fuentes dentro del proyecto, la contratacin de estos nuevos veinte
programadores llev a que se hiciera una reunin entre Johnson, Reynolds y todos los
integrantes del proyecto de software del Robbie CX30. Esta vez fue Sam (Reynolds) el
que se puso furioso. Se quej de que el proyecto no necesitaba ms gente. Sostuvo que el
problema principal era que Johnson y otros miembros a nivel directivo no entendan que el
Robbie CX30 era fundamentalmente diferente de versiones anteriores del robot. Estas
fuentes dijeron al SENTINEL-OBSERVER que los nuevos empleados no estaban
totalmente integrados al proyecto, an seis meses despus de su ingreso, cuando diez
robots Robbie CX30, incluido al robot que mat a Bart Matthews, ya haban sido
despachados. Segn Marta, Sam slo quera mantener las cosas lo ms simples posible.
No quera que el nuevo personal complicara las cosas. Se pasaron seis meses leyendo
manuales. La mayora de los empleados nuevos no saban nada de robots y Sam no estaba
como para perder su tiempo tratando de ensearles. Segn Marta, la reunin del 12 de
junio se hizo famosa en la corporacin Silicon Techtronics porque fue en esa reunin
donde Ray Johnson anunci su Teora Ivory Snow [no existe el blanco perfecto, o bien,
no hay blanco ms blanco que el blanco nieve] de diseo y desarrollo de software. De
acuerdo a Marta, Ray (Johnson) nos dio una gran presentacin en multimedia, con
diapositivas y todo. La esencia de esta Teora Ivory Snow es simplemente que el blanco
nieve es 99,44 por ciento puro y que no hay razn por la que el software de robtica deba
ser ms puro que esto. Dijo repetidas veces que El software perfecto era un oxmoron.
Marta y otros personajes annimos que se acercaron con informacin, retrataron a
Johnson como un gerente con una desesperada necesidad de ser ayudado por un xito
en el proyecto. Versiones anteriores de Robbie, CX10 y CX20, fueron experimentales en
naturaleza y nadie esperaba que fueran xitos comerciales. De hecho, la Divisin
Robtica de Silicon Techtronics estaba operando con sus finanzas en rojo desde su
concepcin seis aos atrs. O triunfaba el CX30 o Silicon Techtronics quedara fuera del
negocio de robtica industrial. Los robots Robbie anteriores tuvieron mucha prensa,
especialmente ac en Silicon Valley, dijo otra fuente que tambin quiere permanecer
annima. Robbie CX30 iba a capitalizarse con la buena publicidad generada por los
proyectos anteriores. Lo nico es que Robbie CX30 era ms revolucionario de lo que
Johnson quera admitir. CX30 representaba un paso gigante hacia adelante en trminos
de sofisticacin. Haba muchsimas preguntas acerca de los parmetros industriales en
los que debera trabajar el CX30. Mucho de lo que deba ejecutar era completamente
nuevo, pero Johnson nunca lo pudo entender. l slo nos vea como unos
perfeccionistas. Uno de sus dichos favoritos era La perfeccin es la enemiga de lo
bueno. Los Compaeros Acusan: el programador del Robot Asesino se
Crea una Estrella
por Mabel Muckraker
Randy Samuels, el que fuera programador de Silicon Techtronics que fue acusado por
escribir el software que caus el horrible incidente del robot asesino el pasado mes de
mayo, era aparentemente una prima donna que encontraba muy difcil aceptar crticas,
aseguraron hoy varios compaeros de trabajo.
En una rueda de prensa con varios compaeros de trabajo de Samuels en el proyecto
del robot asesino, el SENTINEL-OBSERVER pudo obtener importantes revelaciones
acerca de la psiquis del hombre que puede haber sido criminalmente responsable de la
muerte de Bart Matthews, operador de robot y padre de tres criaturas.


9
Con el permiso de los entrevistados, el SENTINEL-OBSERVER permiti a la profesora
Sharon Skinner del Departamento de Psicologa de Software en la Universidad de Silicon
Valley, escuchar una grabacin de la entrevista. La Profesora Skinner estudia la
psicologa de los programadores y otros factores psicolgicos que tienen un impacto en el
proceso de desarrollo del software.
Estara de acuerdo con la mujer que lo llam prima donna, explic la Profesora Skinner.
Este es un trmino utilizado para referirse a un programador que simplemente no puede
aceptar las crticas, o ms precisamente, no puede aceptar su propia falibilidad.
Randy Samuels tiene lo que nosotros, psiclogos de programadores, llamamos una
personalidad orientada hacia una tarea, lindando con una personalidad orientada hacia s
mismo. Le gusta poder completar cosas, pero su ego est muy densamente involucrado
en su trabajo. En el mundo de la programacin esto se lo considera un no, no, agreg el
Profesor Skinner en su oficina tapizada de libros.
La Profesora Skinner continu explicando algunos hechos adicionales sobre equipos de
programacin y personalidades del programador. Bsicamente, hemos encontrado que
un buen equipo de programacin requiere de una mezcla de tipos de personalidad,
incluyendo a una persona que est orientada hacia la interaccin, que saca una enorme
satisfaccin del hecho de trabajar con otra gente, alguien que pueda ayudar a mantener la
paz y a que las cosas se muevan en una direccin positiva. Muchos programadores estn
orientados hacia lo que es la tarea, y esto puede ser problemtico si se tiene un equipo
donde todos son de este modo.
Los compaeros de trabajo de Samuels se mostraron muy reticentes a culpar a alguien
por el desastre del robot, pero cuando se los presion para que comentaran sobre la
personalidad de Samuels y sus hbitos laborales, surgieron varios hechos importantes.
Samuels trabajaba en un equipo formado por aproximadamente una docena de analistas,
programadores y testers de software. (Esto no incluye a veinte programadores que fueron
incorporados posteriormente y que nunca llegaron a estar activamente involucrados en el
desarrollo del software de la robtica). Si bien cada individuo del equipo posea una
especialidad, casi todos estaban comprometidos en todo el proceso de software de
principio a fin.
Sam Reynolds tena un background en procesamiento de datos. Dirigi unos cuantos
proyectos de software de esa naturaleza, dijo uno de los integrantes del equipo,
refirindose al gerente del proyecto Robbie CX30. Pero su rol en el proyecto era ms
que nada de lder. Asista a todas las reuniones importantes y lo mantena a Ray (Ray
Johnson, el Jefe de Divisin Robtica) sobre nuestras espaldas lo ms posible. San
Reynolds, como ya fuera informado en el SENTINELOBSERVER de ayer, se encontraba
bajo una severa presin para lograr producir un robot Robbie CX30 operativo para el 1
de enero de este ao. Sam Reynolds no pudo ser ubicado para entrevistarlo ya sea
sobre su rol en el incidente o sobre Samuels y sus hbitos en el trabajo.
ramos un equipo democrtico, a excepcin del liderazgo provisto por Sam (Reynolds),
observ otro miembro del equipo. En el mundo del desarrollo de software, un equipo
democrtico es un equipo en donde todos los miembros de ste tienen un decir igual en el
proceso de toma de decisiones. Desafortunadamente, nosotros ramos un equipo de
individualistas muy ambiciosos, muy talentosos - si debo referirme a m mismo - y muy
opinadores. Randy (Samuels) era justo el peor del grupo. Lo que quiero decir es que
tenamos, por ejemplo, a dos chicos y a una chica con masters de CMU, y no eran tan
arrogantes como Randy. CMU significa Universidad de Carnegie-Mellon, una lder nacional
en enseanza de ingeniera de software.
Un compaero coment sobre un incidente que Samuels caus en una reunin de Quality
Assurance. Esta reunin i nvolucraba a Samuels y a tres revisores de un mdulo de


10
software que Samuels haba diseado e implementado. Tales reuniones son llamadas
revisiones de cdigo. Uno de los revisores mencion que Samuels haba usado un
algoritmo sumamente ineficiente para lograr un determinado resultado y Samuels se puso
todo colorado. Empez a gritar una sarta de obscenidades y despus se levant y se fue.
Nunca regres.
Le enviamos un memo con un algoritmo ms rpido y a su tiempo us este algoritmo
en su mdulo, agreg el colega.
El mdulo de software del incidente de la reunin de Quality Assurance fue el primero en
ser identificado como una falla en el asesino del operador de robot. No obstante, este
colega se apur a sealar que la eficacia del algoritmo no era un tpico en el mal
funcionamiento del robot. Era slo que Randy haca muy difcil para la gente el poderle
comunicar las observaciones. Se tomaba todo muy a pecho. Se gradu con el puntaje
ms alto de su clase y luego se recibi con honores en ingeniera de software en Purdue.
Definitivamente es muy inteligente.
Randy, en su pared, tiene este inmenso cartel hecho en Banner, continu este colega,
Deca, DENME LA ESPECIFICACIN Y LES DAR EL PROGRAMA DE
COMPUTACIN. Ese es el tipo de arrogancia que tena y tambin demuestra que tena
muy poca paciencia para desarrollar y verificar las especificaciones. Amaba el aspecto de
solucionar el problema, la programacin propiamente dicha. No pareciera que Randy
Samuels qued atrapado en el espritu de la programacin sin egolatra, observ la
Profesora Skinner cuando escuch esta parte de la entrevista con los colegas de trabajo
de Samuels. La idea de una programacin sin egocentrismo es que el producto de
software pertenece al equipo y no a los programadores individuales. La idea es estar abierto
a las crticas y estar menos atado al trabajo propio. Ciertamente que la tarea de revisin de
cdigo es coherente con esta filosofa en general. Una colega habl acerca de otro
aspecto de la personalidad de Samuels: su capacidad de ayuda. Randy odiaba las
reuniones, pero era muy bueno con las relaciones de uno a uno. Siempre estaba ansioso
por ayudar. Recuerdo una vez que me encontraba encerrada en un camino sin salida y l,
en vez de tan slo sealarme la direccin correcta, se hizo cargo del problema y lo resolvi
l mismo. Se pas cerca de cinco das completos en mi problema. Por supuesto que
mirado en retrospectiva, hubiera sido mejor para el pobre Sr. Matthews y su familia que
Randy se hubiese dedicado tan slo a sus propias cosas, agreg luego de una larga
pausa.

El Proyecto del Robot Asesino Controvertido desde el Vamos
Bandos Enfrentados por el Modo en que Deba Proseguir el Proyecto
Especial para el SENTINEL-OBSERVER de SILICON VALLEY
por Mabel Muckraker

Dos grupos, comprometidos con diferentes filosofas de desarrollo de software, casi se
enfrentan violentamente durante las reuniones iniciales de planeamiento para el Robbie
CX30, el robot de Silicon Techtronics que mat a un obrero de la lnea de ensamble el
pasado mes de mayo. Estaba en cuestionamiento si el proyecto Robbie CX30 deba
proseguir de acuerdo con el modelo de cascada o el modelo de prototipo .
El modelo de cascada y el de prototipo son dos mtodos comunes de organizar un proyecto
de software. En el modelo de cascada, el proyecto de software pasa a travs de etapas


11
definidas de desarrollo. La primera etapa es el anlisis de los requerimientos y
especificaciones, durante la cual se intenta arribar a un acuerdo en cuanto a la funcionalidad
detallada del sistema. A medida que el proyecto pasa de una etapa a la siguiente, existen
limitadas oportunidades de dar marcha atrs y cambiar decisiones ya tomadas. Una
desventaja de este enfoque es que los usuarios potenciales no tienen oportunidad de
interactuar con el sistema recin hasta bien entrado en el ciclo de vida del mismo.
En el modelo de prototipo, se pone un gran nfasis en producir un modelo o prototipo
operativo bien temprano durante el ciclo de vida del sistema. El prototipo es construido
con el propsito de arribar a una especificacin final de la funcionalidad del sistema
propuesto. Los usuarios potenciales interactan con el prototipo en forma temprana y con
frecuencia hasta que son acordados los requerimientos. Este enfoque les da a los
potenciales usuarios la oportunidad de interactuar con un sistema prototipo en forma
temprana durante el ciclo de desarrollo, y mucho antes que el sistema final est diseado
y codificado.
En un memorando de fecha 11 de diciembre del ao pasado, Jan Anderson, un miembro del
equipo original del proyecto CX30, atac duramente la decisin tomada por el gerente de
proyecto Sam Reynolds de emplear el modelo de cascada. El SENTINEL-OBSERVER
obtuvo una copia del memo de Anderson, dirigido a Reynolds, y Anderson verific la
autenticidad del memorando para este diario.
Reynolds despidi a Anderson el 24 de diciembre, justo dos semanas despus que ella
escribiera el memo.
El memo de Anderson hace referencia a una reunin anterior en la que ocurri un fuerte
intercambio de opiniones relacionadas con la filosofa del desarrollo del software.
En el memo, Anderson subray el siguiente prrafo.:
No fueron mis intenciones impugnar su competencia durante nuestra reunin de ayer, pero
debo protestar con mi mayor vehemencia contra la idea de que completemos el software
de Robbie CX30 siguiendo el modelo de cascada que usted ya us en otros proyectos. No
necesito recordarle que aquellos eran proyectos de procesamiento de datos que
involucraban el procesamiento de transacciones de negocios. El proyecto Robbie CX30
llevar un alto grado de interaccin, tanto entre robot y componentes como entre robot y su
operador. Dado que la interaccin del operador con el robot es tan importante, la interfaz no
puede estar diseada como una idea de ltimo momento.
Randy Samuels, a quien se lo acus de asesinato no premeditado por la muerte del
operador Bart Matthews, padre de tres nios, haba participado de la reunin del 11 de
diciembre.
En una conversacin con este diario, Anderson dijo que Samuels no tena mucho para
decir sobre la controversia cascada-prototipo, pero s afirm que dara una mano con tal
que exoneraran a Samuels.
El proyecto fue sentenciado a muerte mucho antes que Samuels malinterpretara esas
frmulas, aclar Anderson enfticamente en la sala de su casa en los suburbios.
En conversacin con este diario, Anderson hizo lo mejor de s para explicar la
controversia del mtodo cascada vs. prototipo en trminos simples. El punto principal en
realidad era si podamos llegar a ponernos de acuerdo en los requerimientos del sistema
sin dejar que los operadores del robot presintieran lo que tenamos en mente. Reynolds ha
estado en el negocio de procesamiento de datos por tres dcadas y es bueno en eso, pero
nunca debera haber sido el gerente de este proyecto.
Conforme a registros obtenidos por el SENTINEL-OBSERVER, Silicon Techtronics
transfiri a Sam Reynolds de la Divisin Procesamiento de Datos, que se encargaba de


12
inventario y salarios, a la Divisin Robtica, justo tres semanas antes de la reunin del 11
de diciembre a que alude Anderson en su memo.
Reynolds fue transferido a la Divisin Robtica por el presidente de Silicon Techtronics,
Michael Waterson. Reynolds reemplazaba a John Cramer, quien gerenciaba el anterior
proyecto Robbie CX10 y CX20. Cramer fue puesto a cargo del proyecto CX30, pero muri
inesperadamente en un accidente areo. Al colocar a Reynolds a cargo del proyecto
CX30, nos dice nuestra fuente, que Waterson iba en contra del consejo de Ray Johnson,
Jefe de la Divisin Robtica. De acuerdo con estas fuentes, Johnson se opona fuertemente
a la alternativa de ponerlo a Reynolds como jefe del proyecto Robbie CX30. Estas fuentes
dijeron al SENTINEL-OBSERVER que la eleccin de Waterson por Reynolds fue
puramente una decisin de recorte de gastos. Era ms barato transferir a Reynolds a la
Divisin Robtica que incorporar a un nuevo lder de proyecto fuera de la corporacin.
La fuente annima que el SENTINEL-OBSERVER llamar Marta describi la situacin de
este modo: Waterson pensaba que sera ms barato transferir a Reynolds a robtica antes
que intentar encontrar afuera un nuevo gerente para el proyecto Robbie. Adems,
Waterson tenda a sospechar de la gente de afuera del grupo. Con frecuencia mandaba
memos sobre cunto tarda la gente en aprender el modo de hacer las cosas de Silicon
Techtronics. Desde el punto de vista de Waterson, Reynolds era el gerente y fue
transferido a su nuevo puesto en Robtica como un gerente y no como un experto tcnico.
Claramente, Reynolds se vea a s mismo tanto gerente como experto tcnico. Reynolds no
tena conciencia de sus propias limitaciones tcnicas.
Segn Marta, Reynolds era muy renuente a gerenciar un proyecto que no usara el modelo
de cascada que tan bien le haba servido en el procesamiento de datos. Tild al modelo
prototipo como un modelo de moda en la reunin del 11 de diciembre, y despus de una
serie de intercambios verbales la cosa se puso muy personal.
Anderson estaba especialmente expresiva, recuerda Marta. Tena mucha experiencia
con interfaces con usuarios y desde su perspectiva, la interfaz robot-operador era crtica
para el xito del CX30, dado que la intervencin del operador sera frecuente y a veces
crtica. En su entrevista con el SENTINEL-OBSERVER, Jan Anderson coment sobre este
aspecto de la reunin del 11 de diciembre:
Reynolds estaba en contra de perder el tiempo - para usar sus propias palabras - con
cualquier tipo de anlisis formal de las propiedades de los factores humanos y su interfaz
con el usuario. Para l, las interfaces con el usuario real eran un tema perifrico.
Para l [Reynolds], cualquier cosa nueva era moda, agrega Anderson. Las interfaces de
la computadora eran una moda, el diseo orientado a objetos era una moda, la
especificacin formal y las tcnicas de verificacin eran una moda, y por sobre todo, el
modelo prototipo era una moda.
Justo una semana despus de la reunin del 11 de diciembre, el grupo del proyecto
Robbie recibi un memo de Sam Reynolds concerniente al plan para el proyecto Robbie
CX30.
Era el modelo de cascada, como salido de un libro, Anderson dijo a este reportero
mientras revisaba una copia del memo con el plan del proyecto. Anlisis de
requerimientos y especificacin, luego diseo de arquitectura y diseo detallado,
codificacin, prueba, entrega y mantenimiento. En el modo de ver de Reynolds, no haca
falta tener ninguna interaccin del usuario con el sistema hasta muy, pero muy avanzado el
proyecto. El SENTINEL-OBSERVER se ha enterado de que el primer operador que
realmente us el robot Robbie CX30 en una funcin industrial fue Bart Matthews, el
hombre que fue muerto en la tragedia del robot asesino. Este primer uso de Robbie CX30
en un uso industrial fue cubierto por los medios, incluyendo este peridico. Como una gran


13
irona, El Informe Anual de Silicon Techtronics para los Accionistas, publicado el pasado
mes de marzo, contiene en la brillante portada una foto de un sonriente Bart Matthews. A
Matthews se lo muestra operando al mismsimo robot Robbie CX30 que lo aplast hasta la
muerte tan solo dos meses despus de la toma fotogrfica.
Silicon Techtronics Prometi Entregar un Robot Seguro
Cuestionada la Calidad de Entrenamiento del Operador Especial
para el SENTINEL-OBSERVER de SILICON VALLEY

Silicon Valey, EEUU
por Mabel
Muckraker
En una conferencia de prensa de esta tarde, un grupo de programadores que se
autodenominan Comit de Justicia para Randy Samuels, distribuy documentos que
muestran que Silicon Techtronics se oblig a s misma a hacer entrega de robots que no
causaran ningn dao corporal a los operadores humanos. Randy Samuels es el
programador que ha sido acusado de asesinato en el infame caso del robot asesino.
No podemos entender como el Fiscal pudo acusar a Randy con esos cargos cuando, de
hecho, la compaa Silicon Techtronics estaba legalmente obligada a producir y entregar
robots seguros a Cybernetics, dijo el vocero del comit, Ruth Witherspoon. Creemos
que en todo esto hay un encubrimiento y que hay algn tipo de confabulacin entre la
gerencia de SiliTech [Silicon Techtronics] y la oficina del Fiscal. Michael Waterson era uno
de los ms grandes contribuyentes de la campaa de reeleccin de la Sra. McMurdock
del ao pasado. Michael Waterson es Presidente Ejecutivo de Silicon Techtronics. Jane
McMurdock es la Fiscal de la ciudad de Silicon Valley. El SENTINEL-OBSERVER
confirm que Waterson hizo varios grandes aportes a la campaa de reeleccin de
McMurdock el otoo pasado.
A Randy le estn haciendo pagar los platos rotos por una empresa que tiene estndares
de control de calidad malos y no lo vamos a permitir! Grit Whiterspoon en una emotiva
declaracin a los periodistas. Creemos que la poltica ha entrado en todo esto.
Los documentos que fueron distribuidos por el comit por la Justicia para Randy Samuels
eran porciones de lo que se llama un documento de requerimientos. Segn Ruth
Witherspoon y otros miembros del comit, este documento prueba que Samuels no fue
legalmente responsable de la muerte de Bart Matthews, el desafortunado operador de
robot que fue muerto por un robot de Silicon Techtronics en Cybernetics, Inc. en Silicon
Heights el pasado mes de abril.
El documento de requerimientos es un contrato entre Silicon Techtronics y Cybernetics,
Inc. Especifica con total detalle la funcionalidad del robot Robbie CX30 que Silicon
Techtronics prometi entregar a Cybernetics. Segn Whiterspoon, el robot Robbie CX30
fue diseado para ser un robot inteligente que pudiera ser capaz de operarse en una
variedad de funciones industriales. Cada cliente de la corporacin necesit de documentos
de requerimientos separados ya que Robbie CX30 no era un robot de llave en mano sino
un robot que necesitaba ser programado de forma diferente para cada aplicacin.
No obstante, todos los documentos de requerimientos que fueron acordados bajo los
auspicios del proyecto Robbie CX30, incluyendo al acuerdo entre Silicon Techtronics y
Cybernetics, contienen los siguientes fundamentos de importancia:
El robot ser de operacin segura y aun bajo circunstancias excepcionales (ver Seccin
5.2), el robot no causar dao corporal alguno al operador humano.


14
En el caso de condiciones excepcionales que potencialmente contengan el riesgo de dao
corporal (ver Seccin 5.2.4 y todas sus subsecciones), el operador humano podr ingresar
una secuencia de cdigos de comando, segn se describe en las secciones relevantes de
la especificacin funcional (ver Seccin 3.5.2), que detendr el movimiento del robot mucho
antes que pueda ocurrir un real dao corporal. Las condiciones excepcionales incluyen
eventos inusuales tales como datos extraos desde los sensores del robot, movimiento
errtico o violento del robot o error del operador. Fue justamente esa condicin excepcional
la que llev a la muerte a Bart Matthews.
Estos prrafos fueron extractados de las porciones del documento de requerimientos que
trata sobre los requerimientos no funcionales. Los requerimientos no funcionales listan en
detalle las restricciones bajo las cuales operara el robot. Por ejemplo, el requerimiento de
que el robot sera incapaz de daar a su operador humano es una restriccin y Silicon
Techtronics, segn Ruth Whiterspoon, estaba legalmente obligada a satisfacer este punto.
La parte de los requerimientos funcionales del documento de requerimientos cubre
(nuevamente en sumo detalle) el comportamiento del robot y su interaccin con el entorno y
su operador humano. En particular, los requerimientos funcionales especificaban el
comportamiento del robot bajo cada una de las condiciones excepcionales esperadas. En
su declaracin a los periodistas en la conferencia de prensa, Whiterspoon explic que Bart
Matthews fue muerto cuando se produjo la condicin excepcional 5.2.4.26. sta involucra un
movimiento del brazo del robot extremadamente violento e impredecible. Esta condicin
requiere de la intervencin del operador, a saber el ingreso de los cdigos de comando
mencionados en el documento, pero aparentemente Bart Matthews se confundi y no pudo
ingresar con xito estos cdigos.
Si bien el programa de Randy Samuels estaba mal - l en verdad malinterpret las
frmulas de la dinmica del robot, como se inform a los medios. La condicin excepcional
5.2.4.26 estaba diseada para protegerse de justamente este tipo de contingencia, dijo
Whiterspoon a los periodistas. Los valores del movimiento del robot generados por el
programa de Randy identificaron correctamente a esta condicin excepcional y el operador
del robot recibi el debido aviso de que algo andaba mal.
Whiterspoon dijo que posea una declaracin firmada de otro operador de robot de
Cybernetics en donde afirmaba que las sesiones de entrenamiento ofrecidas por Silicon
Techtronics nunca mencionaron a sta ni a tantas otras condiciones excepcionales. Segn
Whiterspoon, el operador del robot ha jurado que ni a l ni a ningn otro operador de robot
les fue dicho jams que el brazo del robot poda oscilar violentamente.
Whiterspoon cit esta declaracin en la conferencia de prensa. Ni yo ni Bart recibimos
entrenamiento para manejar este tipo de condicin excepcional. Dudo mucho que Bart
Matthews tuviese idea de qu se supona deba hacer cuando la pantalla de la
computadora comenz a mostrar el mensaje de error.
Las condiciones excepcionales que requieren de la intervencin del operador causan un
mensaje de error que se genera en la consola del operador. La Polica de Silicon Valley
confirm que cuando Bart Matthews fue muerto, el manual de referencia en su consola
estaba abierto en la pgina del ndice que contena los cdigos de ingreso para los
errores.
Witherspoon luego cit secciones del documento de requerimientos que obligan a
Silicon Techtronics (el vendedor) a entrenar adecuadamente a los operadores de
robots:
El vendedor suministrar cuarenta (40) horas de entrenamiento para los
operadores. Este entrenamiento cubrir todos los aspectos de la operacin del
robot, incluyendo una cobertura exhaustiva de los procedimientos de seguridad
que deben seguirse en caso de condiciones excepcionales que contengan


15
potencialmente el riesgo de dao corporal. El vendedor proveer y administrar
instrumentos de prueba apropiados que sern usados para certificar el suficiente
entendimiento del operador de las operaciones de la consola del robot y de los
procedimientos de seguridad. Slo los empleados del cliente que hayan pasado
estas pruebas estarn habilitados para operar el robot Robbie CX30 en una
verdadera funcin industrial.
El manual de referencia deber suministrar instrucciones claras para la intervencin del
operador en todas las situaciones excepcionales, especialmente e inclusive aquellas que
contengan potencialmente el riesgo de dao corporal.
Segn Whiterspoon, las declaraciones juradas de varios operadores de robots de
Cybernetics Inc., aseguran que slo se destin un da laborable (aproximadamente 8 horas)
al entrenamiento de los operadores. Es ms, casi no se dedic tiempo alguno al
tratamiento de condiciones excepcionalmente peligrosas.
La prueba escrita desarrollada por Silicon Techtronics para habilitar a un operador de
robot era considerada por los empleados de Cybernetics como un chiste, asegur
Whiterspoon. Obviamente Silicon Techtronics no le dedic mucho al entrenamiento y
procedimientos de prueba obligatorios segn el documento de requerimientos segn la
evidencia en nuestro poder.
Reimpreso con el permiso de ROBOTIC WORLD
El diario de ROBOTICS AND ROBOTICS APPLICATIONS

La Interfaz del Robot Asesino
Dr. Horace Gritty, Departamento de Ciencias de la Computacin y materias
relacionadas Universidad de Silicon Vallley
Resumen: El robot industrial Robbie CX30 se supona que deba establecer
un nuevo modelo de inteligencia de robots industriales. Desgraciadamente,
uno de los primeros robots Robbie CX30 mat a un obrero de la lnea de
montaje, y esto llev a la acusacin de uno de los que desarrollaron el
software del robot, Randy Samuels. Este artculo promueve la teora de que
quien debera estar en juicio en este caso sera el diseador de la interfaz
robot -operador. El robot Robbie CX30 viola casi todas las reglas del diseo de
interfaz. Este artculo se centra en cmo la interfaz del Robbie CX30 viol cada
una de las Ocho Reglas de Oro de Shneiderman.

1. Introduccin

El 17 de mayo de 1992, un robot industrial Robbie CX30 de Silicon Techtronics mat a su
operador, Bart Matthews, en Cybernetics Inc., en Silicon Heights, un suburbio de Silicon
Valley. La investigacin de los hechos del accidente guiaron a las autoridades a la
conclusin de que un mdulo de software, escrito y desarrollado por Randy Samuels, un
programador de Silicon Techtronics, fue el responsable del comportamiento errtico y
violento que a su vez llev a la muerte por decapitacin de Bart Matthews [NOTA AL PIE.
Los medios de prensa manejaron la informacin haciendo creer que Bart Matthews haba
sido aplastado por el robot, pero la evidencia fotogrfica dada a este autor muestra otra
cosa. Tal vez, las autoridades trataban de proteger la sensibilidad pblica].
Como experto en el rea de interfaces con el usuario (1, 2, 3), se me pidi prestar ayuda
a la polica en la reconstruccin del accidente. Para poder hacer esto, se le pidi a Silicon
Techtronics que me suministrara un simulador de Robbie CX30 que incluyera por
completo la consola del operador del robot. Esto me permiti investigar el


16
comportamiento del robot sin tener que en realidad arriesgarme seriamente. Debido a mi
profundo entendimiento de interfaces con el usuario y factores humanos pude reconstruir
el accidente con extrema precisin. Sobre la base de esta reconstruccin, llegu a la
conclusin de que fue el diseo de la interfaz y no el por cierto imperfecto diseo del
software lo que debera haber sido visto como el criminal en este caso.
A pesar de mi descubrimiento, la Fiscal Jane McMurdock insisti en proseguir el caso
contra Randy Samuels. Pienso que cualquier Computador Cientfico competente, dado una
oportunidad de interactuar con el simulador del Robbie CX30, tambin habra concluido
que el diseador de la interfaz y no el programador deberan haber sido acusado por
negligencia, si no por homicidio no premeditado.

2. Las ocho reglas de oro de Shneiderman
Mi evaluacin de la interfaz con el usuario del Robbie CX30 est basada en las ocho
reglas de oro de Shneiderman (4). Tambin utilic otras tcnicas para evaluar la interfaz,
pero stas sern publicadas en artculos separados. En esta seccin ofrezco una breve
revisin de las ocho reglas de oro de Shneiderman, un tema que resultar ms familiar
para expertos en interfaces de computacin como yo y no a hackers de robtica que
leyeron este oscuro peridico.
Las ocho reglas de oro son:
1. Buscar siempre la coherencia. Tal como se puede ver ms abajo, es importante
que una interfaz con el usuario sea coherente a muchos niveles. Por ejemplo,
los diseos de pantalla deben ser coherentes de una pantalla a la siguiente. En
un entorno en que se usa una interfaz grfica con el usuario (GUI), esto
tambin implicar concordancia de un utilitario al siguiente.
2. Permitirle a los usuarios frecuentes el uso de mtodos abreviados por
teclas. Los usuarios frecuentes (o, power users) pueden desalentarse ante
tediosos procedimientos. Permitirle a estos usuarios un procedimiento
menos tedioso para completar una tarea dada.
3. Dar realimentacin de informacin. Los usuarios necesitan ver las
consecuencias de sus acciones. Si un usuario ingresa un comando pero la
computadora no muestra ya sea que lo est procesando o lo ha procesado, esto
puede dejar al usuario confundido o desorientado.
4. Disear dilogos que tengan un fin. Interactuar con una computadora es algo
as como dialogar o conversar. Cada tarea debe tener un inicio, un desarrollo y
un fin. Es importante que el usuario sepa cundo una tarea est finalizada. El
usuario necesita tener la sensacin de que la tarea ha alcanzado su trmino.
5. Permitir manejos simples de los errores. Los errores del usuario deben estar
diseados dentro del sistema. Otro modo de decirlo es que no debe haber
ninguna accin por parte del usuario que sea considerada como un error que
est ms all de la capacidad del sistema para manejarlo. Si el usuario comete
un error, debe recibir informacin til, clara y concisa sobre la naturaleza de tal
error. Debe resultar fcil para el usuario deshacer este error.
6. Permitir deshacer las acciones con facilidad. Ms genricamente, los
usuarios deben poder deshacer lo que han hecho, sea esto o no de
naturaleza errnea.
7. Respaldar que el centro del control est internamente. La satisfaccin del


17
usuario es alta cuando el usuario tiene la sensacin de que es l o ella quien
tiene el control y la satisfaccin del usuario es baja cuando el usuario siente que
la computadora tiene el control. Disear interfaces para reforzar la sensacin de
que es en el usuario donde yace el control en el mbito de la interaccin
humano-computadora.
8. Reducir la carga de la memoria inmediata. La memoria inmediata del ser
humano es notablemente limitada. Los psiclogos regularmente citan a la ley de
Miller que dice que la memoria inmediata est limitada a siete piezas discretas
de informacin. Hacer todo lo posible para liberar la carga en la memoria del
usuario. Por ejemplo, en lugar de pedirle al usuario que teclee el nombre de un
archivo para abrirlo, presentar al usuario una lista de archivos disponibles en ese
momento.
3. Revisin de la consola del robot

La interfaz del operador de Robbie CX30 viol todas y cada una de las reglas de
Shneiderman. Muchas de estas violaciones fueron directamente responsables del accidente
que termin con la muerte de un operador de robot.
La consola del robot era una IBM PS/2 modelo 55SX con un procesador 80386 y un monitor
EGA color con resolucin 640 x 480. La consola tena un teclado, pero no ratn. La
consola estaba empotrada en una estacin de trabajo que tena, adems, estantes para
manuales y un rea para tomar notas y para leer manuales. No obstante, el rea para
escribir/leer estaba a bastante distancia de la pantalla de la computadora, o sea que era
bastante incmodo y cansado para el operador manejar cualquier tarea que requiriera de
mirar algo en el manual y luego actuar rpidamente con respecto al teclado de la consola.
La silla del operador estaba deficientemente diseada y estaba demasiado alta con
respecto a la posicin de la consola y al rea de escribir/leer. Esto resenta mucho la
espalda del operador y tambin causaba excesivo cansancio de la vista.
No puedo comprender cmo un sistema sofisticado como este no pudo incluir un aparato
de mejor diseo para los ingresos de los datos. Uno slo podra concluir que Silicon
Techtronics no tena mucha experiencia en tecnologa de interfaces con el usuario. El
documento de requerimientos (5) especificaba un sistema manejado por mens, lo cual era
una eleccin razonable. Sin embargo, en un utilitario en donde lo esencial era la rapidez,
especialmente cuando la seguridad del operador estaba en juego, el uso de un teclado
para todas las tareas de seleccin de opcin de mens fue una eleccin de extremada
pobreza, que requera de mucho uso del teclado para lograr el mismo efecto que poda
haberse conseguido casi instantneamente mediante un ratn. (Ver el artculo escrito por
Foley et al. (6) En realidad, se me ocurrieron todas estas ideas antes que Foley las
publicara, pero l me gan).
El operador del robot poda interactuar con el robot y de este modo producir un impacto
sobre su comportamiento al hacer las opciones en un sistema de mens. El men principal
consista de 20 tems, demasiados en mi opinin, y cada tem del men principal tena un
submen tipo desplegable asociado a ste. Algunos de los submens tenan tanto como
veinte tems - nuevamente, demasiados. Es ms, pareca haber muy poca rima o razn en
cuanto a por qu los tems de los mens estaban listados en el orden en que lo estaban.
Hubiese sido mucho mejor una organizacin alfabtica o funcional.
Algunos del los tems en los mens desplegables tenan hasta cuatro mens pop up
relacionados a stos. stos apareceran en secuencias a medida que se haca la seleccin
correspondiente en los submens. Ocasionalmente, una eleccin de un submen abrira
un cuadro de dilogo en la pantalla. Un cuadro de dilogo requiere de cierto tipo de


18
interaccin entre el operador y el sistema, por ejemplo para resolver ciertos temas, como
ser, ingresar cul es el dimetro de un dispositivo dado a ser bajado en el bao de cido.
El sistema de mens presenta una estricta jerarqua de eleccin de mens. El operador
podra volver hacia atrs en esta jerarqua apretando la tecla de escape. Esta tecla escape
tambin podra terminar los dilogos.
El uso de color en la interfaz fue muy poco profesional. Haba demasiados colores en un
espacio demasiado chico. Los contrastes eran muy fuertes y el resultado, para este
revisor, result en una severa fatiga ocular en tan slo quince minutos de uso. Hubo uso
excesivo de efectos musicales tontos y flashes cuando se ingresaban opciones o cdigos
errneos.
Uno debera preguntarse por qu Silicon Techtronics no intent un enfoque ms
sofisticado para el diseo de la interfaz. Luego de un cuidadoso estudio del dominio de
los utilitarios del Robbie CX30, he llegado a la conclusin de que una interfaz de
manipulacin directa, que mostrara literalmente al robot en la consola del operador,
habra sido lo ideal. El entorno tan visual dentro del cual operaba el robot se prestaba
naturalmente al diseo de metforas de pantalla apropiadas para ese entorno,
metforas que el operador podra entender con facilidad. Esto permitira que el operador
manipulara el robot mediante el manejo, en la consola del robot, de la representacin
grfica del robot en su entorno. He solicitado a uno de mis estudiantes en el doctorado,
Susan Farnsworth, que investigara un poco ms esta posibilidad.
4. En qu modo la interfaz del robot Robbie CX30 viol las ocho reglas de
oro

La interfaz con el usuario de Robbie CX30 viol todas y cada una de las reglas de oro en
diferentes modos. En este artculo slo tratar unas pocas instancias de violaciones de
reglas, dejando la discusin ms en detalle para futuros artculos y mi prximo libro [NOTA
AL PIE: CODEPENDENCIA: Cmo los Usuarios de Computadoras permiten deficientes
Interfaces con el Usuario, Angst Press, Nueva York. Este libro presenta una teora
radicalmente nueva con respecto a la relacin entre la persona y su mquina.
Esencialmente, algunas personas necesitan una interfaz de mala calidad a los fines de
evitar ciertos problemas psicolgicos no resueltos en sus vidas.]. Lo que har es destacar
esas violaciones que fueron relevantes en este accidente en particular.
4.1 Buscar siempre la coherencia

En la interfaz del usuario de Robbie CX30 hubo muchas incoherencias. Los mensajes de
error podan aparecer en casi cualquier color y podan estar acompaados por casi
cualquier tipo de efecto musical. Adems, los mensajes de error podan aparecer en casi
cualquier lugar de la pantalla.
Cuando Bart Matthews vio el mensaje de error de la condicin excepcional que ocurri
luego, la cual requera la intervencin del operador, es probable que fuera esa la primera
vez que vea ese mensaje en especial. Adems, el mensaje de error apareci en un cuadro
verde, sin ningn efecto de sonido. Este es el nico mensaje de error de todo el sistema que
aparece en verde y sin ningn tipo de acompaamiento de orquesta.


19
4.2 Permitir que los usuarios frecuentes utilicen mtodos abreviados por
teclas

Este principio no aparece de ningn modo en todo el diseo de la interfaz. Por ejemplo,
hubiera sido una buena idea permitir que los usuarios frecuentes pudieran ingresar la
primera letra de la opcin de un submen o men en lugar de requerrseles el uso de las
teclas del cursor y luego la tecla enter para elegir esa opcin determinada. El
mecanismo de seleccin de mens de este sistema debe haber provocado al operador
bastante fatiga mental.
Es ms, debera haberse permitido algn tipo de sistema de tecleado anticipado que
permitiera al usuario frecuente ingresar una secuencia de opciones de men sin tener
que esperar a que apareciera realmente el men en pantalla.

4.3 Ofrecer realimentacin
1
de informacin

En muchos casos el usuario no tiene idea de si el comando que acaba de ingresar se est
procesando o no. Este problema se exagera adems por las inconsistencias en el diseo
de la interfaz con el usuario. En algunos casos al operador se le da una realimentacin
detallada de lo que el robot est ejecutando. En otros, el sistema permanece
misteriosamente silencioso. En general, al usuario se lo lleva a que espere algn tipo de
realimentacin y por consiguiente se queda confundido cuando sta no se le da. En la
pantalla, no hay una representacin visual del robot y su entorno, y la visin que tiene el
operador del robot a veces est obstruida.
4.4 Disear dilogos que tengan fin

Hay muchos casos en los que una secuencia dada de tecleado representa una idea
holstica, una tarea completa, pero al operador se lo deja sin el tipo de realimentacin que
le confirmare que la tarea ha sido en efecto completada. Por ejemplo, hay un dilogo
bastante complicado que se necesita cuando se quiere sacar un elemento de un bao de
cido. Sin embargo, luego de completar este dilogo, el usuario es llevado a otro dilogo
nuevo, y no relacionado con ste, sin que se le informe que el dilogo anterior ha
finalizado.
4.5 Ofrecer manejo simple de los errores

El sistema pareciera estar diseado para que el usuario se lamentara por cualquier ingreso
errneo. No slo el sistema permite numerosas oportunidades para el error, sino que
cuando un error en realidad ocurre, es probable que no se repita por algn tiempo. Ello se
debe a que la interfaz con el usuario hace que recuperarse de un error sea una odisea
tediosa, frustrante y a veces enfurecedora. Algunos de los mensajes de error eran
directamente ofensivos y condescendientes.
4.6 Permitir deshacer las acciones con facilidad

Como se menciona en el prrafo anterior, la interfaz con el usuario hace muy difcil la
tarea de deshacer entradas errneas. En general, el sistema de mens permite deshacer
fcilmente las acciones, pero esta filosofa no alcanza al diseo de los cuadros de dilogo
y al manejo de condiciones excepcionales. Desde un punto de vista prctico (opuesto al
terico), la mayora de las acciones son irreversibles cuando el sistema est en un estado
de condicin excepcional, y esto ayud a llegar a la tragedia del robot asesino.


20

4.7 Promover que uno sea el centro del control

Muchas de las deficiencias tratadas en los prrafos precedentes disminuyeron la
sensacin de tener el control. Por ejemplo, no recibir informacin, no poder concluir las
interacciones, no permitir deshacer con facilidad las acciones en el momento en que
surgen las excepciones, todas estas cosas actan para disminuir la sensacin de que el
usuario posee el control sobre el robot. Hubo muchas caractersticas de esta interfaz que
hicieron que el operador sintiera que hay un enorme bache entre la consola del operador y
el robot en s, mientras que un buen diseo de interfaz hubiera hecho transparente la
interfaz con el usuario y le hubiera dado al operador del robot la sensacin de estar en
contacto directo con el mismo. En un caso, le orden al robot mover un elemento desde
bao de cido hasta la cmara de secado y pasaron 20 segundos antes de que el robot
pareciera responder. De este modo, no tuve la sensacin de estar controlando al robot.
Tanto la respuesta demorada del robot como la falta de realimentacin en la pantalla de la
computadora, me hicieron sentir que el robot era un agente autnomo, la verdad, un
sentimiento como mnimo perturbador.
4.8 Reducir la carga de la memoria de corto plazo

Un sistema que se maneja por medio de mens es en general bueno en trminos de la
carga de memoria que crea en los usuarios. No obstante, hay una gran variacin entre
implementaciones particulares de sistemas de men en lo que hace a carga de memoria.
La interfaz con el usuario de Robbie CX30 tena mens muy grandes sin una obvia
organizacin interna. Esto crea una gran carga al operador en trminos de memoria y
tambin en trminos de tiempos de bsqueda, el tiempo que le lleva al operador ubicar
una opcin determinada de un men.
Muchas pantallas de dilogo requeran que el usuario ingresara con el teclado nmeros de
partes, nombres de archivos, y otra informacin. El sistema podra haberse diseado
fcilmente de forma de mostrarle al usuario estos nmeros de parte, etc., sin necesitar
que el usuario recordara estas cosas de su propia memoria. Esto incrementaba la carga
sobre la memoria del usuario.
Para finalizar, y esto es realmente imperdonable, increble como puede parecer, no haba
ninguna instalacin de ayuda en lnea o sensible al contexto! Si bien he ido a los cursos de
entrenamiento ofrecidos por Silicon Techtronics, muchas veces me encontr navegando
por los manuales de referencia para poder encontrar la respuesta a an las ms bsicas
preguntas, tales como:Qu significa esta opcin de men? Qu pasa si selecciono
esta opcin?
5. Una reconstruccin de la tragedia del robot asesino

Las fotos policiales de la escena del accidente no son nada agradables de ver. La
consola del operador estaba salpicada con bastante cantidad de sangre. No obstante, la
calidad de las fotos es excepcional y utilizando tcnicas de ampliacin pude descubrir los
siguientes factores de importancia sobre el momento en que se produjo el accidente:


21
1. La luz NUM LOCK estaba encendida

El teclado IBM contiene un tablero numrico que puede operar de dos modos. Cuando la
luz NUM LOCK est encendida, esa parte se comporta como una calculadora. Del otro
modo, las teclas pueden usarse para mover el cursor en la pantalla.
2. Haba sangre esparcida en el tablero numrico

Las huellas ensangrentadas indican que Bart Matthews estaba usando el tablero
numrico en el momento en que fue golpeado y muerto.
3. Se encontraba titilando en verde un mensaje de error

Esto nos dice la situacin de error vigente en el momento en que ocurri la tragedia. El
mensaje de error deca ROBOT DYNAMICS INTEGRITY ERROR-45
2

4. Haba un manual de referencia que estaba apoyado abierto sobre el
rea de lectura/escritura de la estacin de trabajo

Uno de los cuatro volmenes del manual de referencia estaba abierto en la pgina del
ndice que contena el tem ERRORES/MENSAJES.
5. En la pantalla tambin haba un mensaje que mostraba
instrucciones al operador

El mensaje apareca en amarillo en la parte inferior de la pantalla. En el mensaje se lea .
POR FAVOR INGRESE INMEDIATAMENTE LA SECUENCIA DE COMANDOS PARA
CANCELAR EL ERROR DINMICO DEL ROBOT!!!
En base a las evidencias fsicas ms otras evidencias contenidas en los registros del
sistema, y basndose en la naturaleza del error ocurrido (error de integridad de
dinmica del robot - 45, el error que estuvo causado por el programa de Randy
Samuels), he llegado a la conclusin de que ocurri la siguiente secuencia de eventos
en la fatal maana de la tragedia del robot asesino:
10:22:30 ERROR DE INTEGRIDAD DE DINMICA DEL ROBOT - 45 aparece
en la pantalla. Bart Matthews no lo ve porque no hay efecto de audio o seal sonora tal
como ocurre con todas las otras situaciones de error. Adems, el mensaje de error
aparece en verde, lo que en todos los otros contextos significa que hay un proceso
completndose con normalidad.
10:24:00 El robot comienza a moverse lo suficientemente violento como para que
Bart Matthews lo note.
10:24:05 Bart Matthews se da cuenta del mensaje de error, no sabe lo que significa.
No sabe qu hacer. Intenta con el submen cancelacin de emergencia, un submen de
uso genrico para apagar el robot. Este involucra SEIS opciones de men por separado,
pero el Sr. Matthews no se da cuenta de que la luz NUM LOCK est encendida. Por ende,
las opciones del men no estn ingresando dado que las teclas del cursor operan como
teclas de calculadora.


22
10:24:45 El robot gira del bao de cido y comienza a arrastrar la consola del
operador, con sus brazos dentados batindose con gran amplitud. Nadie esperaba que un
operador tuviera que huir de un robot descontrolado, as que Bart Matthews queda
atrapado en su rea de trabajo por el robot que avanza. Ms o menos para este momento
es que Bart Matthews saca el manual de referencia y empieza a buscar el error ERROR
DE INTEGRIDAD DE DINMICA DEL ROBOT - 45 en el ndice. Ubica con xito una
referencia a mensajes de error en el ndice.
10:25:00 El robot ingresa al rea del operador. Bart Matthews abandona la bsqueda
del procedimiento del operador ante un error de integridad de dinmica del robot. En su
lugar, intenta una vez ms ingresar la secuencia de cancelacin de emergencia desde el
teclado numrico, momento en que es golpeado.
6. Resumen y Conclusiones

Si bien el mdulo de software escrito por Randy Samuels caus en verdad que el robot
Robbie CX30 oscilara fuera de control y atacara a su operador humano, un buen diseo
de la interfaz hubiera permitido al operador terminar con el comportamiento errtico del
robot. En base al anlisis de la interfaz del usuario del robot llevado a cabo utilizando las
ocho reglas de oro de Shneiderman, el experto en diseo de interfaces ha arribado a la
conclusin de que el diseador de la interfaz y no el programador fue la parte ms
culpable en este desafortunado evento.
7. Referencias
1. Gritty, Horace (1990). The Only User Interface Book Youll Ever Need. Vanity Press,
Oshkosh, WI, 212 pag. [El nico libro sobre Interfaz del usuario que usted necesitar]
2. Gritty, Horace (1992). What We Can learn from the Killer Robot [Lo que podemos aprender
del robot asesino], charla dada en el Simposio Internacional de la Universidad de Silicon Valley
sobre Seguridad de Robots e Interfaces con el Usuario, Marzo de 1991. Tambin por aparecer en
las Notas de Alumnos de la Universidad de Silicon Valley.
3. Gritty, Horace (se espera para 1993). CODEPENDENCY: How Computer Users Enable
Poor User Interfaces, Angst Press, New York [Cmo los usuarios de computadoras
permiten interfaces deficientes]
4. Shneiderman, Ben (1987), Designing the User Interface, Addison-Wesley, Reading MA, 448
pag. [Diseo de Interfaces]
5. DOCUMENTO DE REQUERIMIENTOS DEL ROBOT INDUSTRIAL INTELIGENTE
Robbie CX 30: versin de Cybernetics Inc., Documento Tcnico N
91-0023XA, Silicon
Techtronics Corporation, Silicon Valley, USA 1245 pag.
6. Foley, J. P., Wallace, V. L., y Chan, P. (1984): The Human Factors of Computer
Graphics Interaction Techniques [Los factores humanos de las tcnicas de interaccin
de grficas de computacin] IEEE COMPUTER GRAPHICS AND APPLICATIONS,
4(11) pag. 13-48.


23
Ingeniero de Software Cuestiona la Autenticidad de las Pruebas
de Software del Robot Asesino
La Indagacin de un Profesor de la Universidad de Silicon Valley Provoca
Serios Cuestionamientos Legales y ticos
Especial para el SENTINEL-OBSERVER DE SILICON VALLEY
por Mabel Muckraker

El caso del robot asesino dio un giro significativo ayer cuando un profesor de la
Universidad de Silicon Valley present un informe en donde cuestiona la autenticidad de
las pruebas que fueron hechas por Silicon Techtronics al software del robot asesino. El
Profesor Wesley Silber, Profesor de Ingeniera de Software, dijo en una conferencia de
prensa realizada en la universidad que los resultados de las pruebas reflejados en los
documentos internos de Silicon Techtronics no concordaban con los resultados de las
pruebas obtenidos cuando l y sus colegas ensayaron el software real del robot.
Silicon Valley an est reaccionando por el anuncio del Profesor Silber, que podra jugar un
papel importante en el juicio a Randy Samuels, el programador de Silicon Techtronics que
fue acusado por homicidio no premeditado en el ahora infame incidente del robot asesino.
Presionada por su reaccin por el informe del Profesor Silber, la Fiscal Jane McMurdock
reiter su confianza en que el jurado encontrar culpable a Randy Samuels. Sin embargo,
la Fiscal Jane McMurdock impresion a los periodistas cuando agreg pero, esto en
verdad promueve la posibilidad de nuevas acusaciones.
Ruth Whiterspoon, la vocero del Comit de justicia para Randy Samuels, tambin
estuvo exultante cuando habl a este peridico. McMurdock no puede tener ambas
cosas. O el programador es el responsable por esta tragedia o se deber hacer
responsable a la gerencia por ello. Creemos que el informe de Silber exonera a nuestro
amigo y colega Randy Samuels.
El gerente Ejecutivo de Silicon Techtronics Michael Waterson hizo la siguiente tibia
declaracin sobre el informe de Silber:
Tan pronto se anunci la acusacin de Randy Samuels personalmente le ped a un
estimado ingeniero de software, el Dr. Wesley Silber, que llevara a cabo una indagacin
objetiva sobre los procedimientos de aseguramiento de la calidad en Silicon Techtronics.
Como gerente ejecutivo de este proyecto, siempre he insistido en que la calidad es lo
primero, a pesar de lo que hayan podido leer en los peridicos.
Le ped al profesor Silber que condujera una investigacin objetiva de todos los aspectos
de aseguramiento de la calidad de Silicon Techtronics. Promet al Profesor Silber que
tendra acceso a toda la informacin relevante a esta infortunada situacin. Le dije en una
reunin frente a frente en mi oficina que deba proseguir la investigacin hasta su final sin
importar a donde terminara, sin importar las implicancias.
Basndome en la informacin que yo reciba de mis gerentes, nunca se me ocurri que
hubiera un problema de que los procedimientos de aseguramiento de la calidad fueran ya
sea dbiles o deliberadamente alterados. Quiero asegurarle al pblico que la o las
personas responsables de esta falta en el aseguramiento de la calidad del software dentro
de la Divisin Robtica de Silicon Techtronics sern exhortados a encontrar trabajo en otro
lado.


24
Roberta Matthews, viuda de Bart Matthews, el operador del robot que fue muerto en el
incidente, habl telefnicamente desde su casa con el Sentinel-Observer. An quiero ver
al Sr. Samuels condenado por lo que le hizo a mi marido. No entiendo de dnde viene
toda la conmocin. El hombre que asesin a mi esposo debera haber probado su propio
software!
El SENTINEL-OBSERVER entrevist al Profesor Silber justo antes de su conferencia de
prensa. En las paredes de su oficina estaban colgados numerosos premios recibidos a raz
de su trabajo en el campo de ingeniera de software y aseguramiento de la calidad del
software. Comenzamos la entrevista pidiendo al Profesor Silber que explicara por qu a
veces el software no es confiable. Contest a nuestra pregunta citando la enorme
complejidad del software.
Los grandes programas de computadora son indiscutiblemente los artefactos ms
complejos creados por la mente humana, explic el Profesor Silber sentado frente a un
monitor de grandes dimensiones. En algn momento un programa de computacin est
en uno de los tantos estados posibles, y hay una imposibilidad prctica de asegurar que
el programa se comportar como corresponde en cada uno de esos estados. No tenemos
el tiempo suficiente para hacer tal tipo de prueba exhaustiva. De modo que usamos
estrategias de prueba o heursticas que muy probablemente encontrarn los errores o
bugs, si es que existe alguno.
El Profesor Silber ha publicado numerosos artculos sobre ingeniera de software. Estuvo
en la primera plana cuando el ao pasado public su lista de Aerolneas a Evitar Si su Vida
Dependiera de Ello. Esa lista enumeraba las aerolneas de cabotaje que l consideraba
irresponsables por su compra de aviones que estn controlados casi por completo por
software de computacin.
Poco tiempo despus de los cargos contra Randy Samuels en el caso del robot asesino, el
gerente Ejecutivo de Silicon Techtronics, Michael Waterson, pidi al Profesor Silber que
condujera una revisin objetiva de los procedimientos de aseguramiento de la calidad de
Silicon Techtronics. La intencin de Waterson era contrarrestar la mala publicidad de su
empresa luego de las acusaciones de Samuels.
El Aseguramiento de la Calidad se refiere a aquellos mtodos que usa un especialista de
desarrollo de software para asegurar que el software es confiable, correcto y robusto.
Estos mtodos se aplican a todo lo largo del ciclo de vida de desarrollo del producto de
software. En cada etapa se aplican los mtodos de aseguramiento de calidad adecuados.
Por ejemplo, cuando un programador escribe cdigo, una medida de aseguramiento de
calidad es probar el cdigo confrontndolo en verdad con los datos de prueba. Otro
mtodo sera correr programas especiales, llamados analizadores estticos,
confrontndolo con el nuevo cdigo. Un analizador esttico es un programa que busca
patrones sospechosos en los programas, patrones que podran indicar un error o bug.
Estas dos formas de aseguramiento de calidad son denominadas pruebas dinmicas y
pruebas estticas, respectivamente.
El software consiste de componentes discretos o unidades que eventualmente se
combinan para crear un sistema ms grande. Las unidades mismas deben ser
probadas, y este proceso de prueba individual de las unidades es llamado prueba
unitaria. Cuando las unidades se combinan, se deben probar los subsistemas
integrados y este proceso se llama prueba de integracin.
El Profesor Silber coment al SENTINEL-OBSERVER sobre su trabajo en Silicon
Techtronics: Mike [Waterson] me dijo de ir all [a la compaa] y conducir una revisin de
sus procedimientos de prueba de software y de hacer pblicos mis hallazgos. Mike


25
pareca confiado, tal vez debido a lo que le haban dicho sus gerentes, en el sentido de
que no encontraran nada malo en los procedimientos de aseguramiento de calidad de
Silicon Techtronics.
Luego de arribar a Silicon Techtronics, el Profesor Silber centr su atencin en los
procedimientos para ensayo dinmico de software en la compaa.
Ayudado por un grupo de graduados, el Profesor Silber descubri una discrepancia entre
el comportamiento real de la seccin del cdigo del programa (escrito por Randy Samuels)
que caus que el robot Robbie CX30 matara a su operador, y el comportamiento segn se
lo registr en la documentacin de pruebas de Silicon Techtronics. Este descubrimiento
en realidad fue hecho por Sandra Henderson, una estudiante graduada en ingeniera de
software que est completando su doctorado con el Profesor Silber. Entrevistamos a la
Sra. Henderson en uno de sus laboratorios de computacin para egresados en la
Universidad de Silicon Valley. Encontramos un problema en la prueba de la unidad,
explic la Sra. Henderson. Ac estn los resultados de la prueba, que nos dio el Sr.
Waterson en Silicon Techtronics, que se supone estn hechos para cdigo C [lenguaje de
programacin] que Randy Samuels escribi y que caus el incidente del robot asesino.
Como puede ver, todo est claramente documentado y organizado. Hay dos juegos de
prueba: uno basado en una prueba de caja blanca y otro en una prueba de caja negra.
Basndonos en nuestros propios estndares para probar software, estos juegos de
prueba estn bien diseados, completos y rigurosos. La prueba de caja negra implica ver
la unidad de software (o sus componentes) como una caja negra que tiene
comportamientos predecibles de input y output. Si en el juego de prueba el componente
demuestra los comportamientos esperados para todos los inputs, entonces pasa la
prueba. Los juegos de prueba estn diseados para cubrir todos los comportamientos
interesantes que una unidad podra mostrar pero sin tener conocimiento alguno sobre la
estructura o naturaleza del cdigo en realidad. La prueba de caja blanca implica cubrir
todos los pasos posibles a travs de la unidad. As, la prueba de caja blanca se hace con
vasto conocimiento de la estructura de la unidad. En la prueba de caja blanca, el juego de
prueba debe causar que cada sentencia del programa se ejecute por lo menos una vez de
modo que ninguna quede sin ser ejecutada.
Sandra Henderson prosigui explicando el significado de la prueba de software. Ni la
prueba de caja blanca ni de caja negra prueban que un programa est correcto. No
obstante, los probadores de software, tales como los que se emplean en Silicon
Techtronics, pueden volverse bastante expertos en el diseo casos de prueba para
descubrir nuevos bugs en el software. La actitud apropiada es que una prueba es exitosa
cuando se encuentra un bug. Bsicamente, el probador le da un juego de
especificaciones y hace lo mejor de s para demostrar que el cdigo que est probando
no satisface sus especificaciones, explic la Sra. Henderson.
La Sra. Henderson luego mostr a este reportero los resultados de las pruebas que ella
en verdad obtuvo cuando corri el cdigo crtico del robot asesino usando los juegos de
prueba de la compaa, tanto para ensayo de caja blanca como de caja negra. En muchos
casos, los resultados registrados en los documentos de prueba de la compaa no fueron
los mismos que los generados por el verdadero cdigo del robot asesino.
Durante su entrevista de ayer con el SENTINEL-OBSERVER, el Profesor Silber discuti
la discrepancia. Ver, el software que en verdad fue entregado junto con el robot Robbie
CX30 no fue el mismo que el que supuestamente fue probado, por lo menos de acuerdo
con estos documentos!. Hemos podido determinar que el verdadero cdigo asesino, tal
como lo llamamos, fue escrito despus de que se condujeron supuestamente las pruebas
del software. Esto sugiere varias posibilidades. Primero, el proceso de prueba de
software, por lo menos para esta parte crtica del software, fue falseado deliberadamente.
Todos sabemos que hubo una enorme presin para tener listo a este robot en una fecha


26
determinada. Otra posibilidad es que hubo una cierta dificultad en la versin de la
gerencia en Silicon Techtronics, en cuanto a que el cdigo correcto fue verdaderamente
escrito, y probado con xito, pero en el producto entregado se insert el cdigo
equivocado.
Solicitamos al Profesor Silber que explicara que quera decir con versin de la gerencia.
En un proyecto dado, un componente dado de software puede tener varias versiones,
versin 1, versin 2, etc.
Esto refleja la evolucin de ese componente a medida que avanza el proyecto. Se
necesita tener algn tipo de mecanismo para tener control de las versiones de los
componentes de software en un proyecto tan complejo como este. Tal vez el probador de
software prob una versin correcta del cdigo de dinmica del robot, pero en realidad se
entreg una versin equivocada del mismo. No obstante, esto trae a colacin una
pregunta en cuanto a qu pas con el cdigo correcto.
El Profesor Silber se reclin en su silln. Realmente esto es una gran tragedia. Si el
cdigo asesino hubiese sido pasado por el proceso de prueba de un modo honesto, el
robot nunca hubiese asesinado a Bart Matthews. Entonces, la pregunta es, qu pasaba
en Silicon Techtronics que no permiti una prueba honesta del cdigo crtico?
El SENTINEL-OBSERVER pregunt al Profesor Silber si estaba de acuerdo con el
concepto de que la interfaz del usuario fue la primordial culpable en este caso. No creo
en el argumento que esgrime mi colega, el Profesor Gritty, de que toda la culpabilidad en
este caso pertenece al diseador o diseadores de la interfaz. Concuerdo con ciertas
cosas que dice, pero no con todo. Debo preguntarme a m mismo si Silicon Techtronics
estaba poniendo mucho nfasis en la interfaz del usuario como la ltima lnea de defensa
contra el desastre. Esto es, ellos saban que haba un problema, pero pensaron que la
interfaz del usuario podra permitirle al operador manejarlo.
El SENTINEL-OBSERVER pregunt entonces al Profesor Silber sobre los cargos que se le
hacan en cuanto que nunca debera haber aceptado la designacin de Waterson para
conducir una investigacin objetiva del accidente. Las crticas sealan que la Universidad
de Silicon Valley, y en particular el Profesor Silber, tenan muchos intereses comunes con
Silicon Techtronics, y de ese modo no poda ser elegido para conducir una investigacin
objetiva.
Pienso que mi informe habla por s mismo, replic el Profesor Silber, visiblemente
molesto por nuestra pregunta. Ya les he dicho a ustedes los periodistas una y otra vez
que no se trat de una investigacin gubernamental sino de una interna de la corporacin,
de modo que creo que Silicon Techtronics tena el derecho de elegir a quien se le
ocurriera. Creo que yo les resultaba una persona con integridad.
Ayer tarde, Sam Reynolds, el gerente de Proyecto del CX30 contrat a una abogada,
Valerie Thomas. La Sra. Thomas hizo estas declaraciones en favor de su cliente:
Mi cliente est escandalizado de que alguien de Silicon Techtronics haya podido engaar
al Profesor Silber en lo concerniente a las pruebas de software del robot Robbie CX30. El
Sr. Reynolds asegura que el software fue probado y que l y otros saban muy bien el
hecho de que haba algo que no funcionaba en el software de dinmica del robot. Sin
embargo, el Sr. Ray Johnson, el superior inmediato de mi cliente en Silicon Valley, decidi
que el robot fuera entregado a Cybernetics, Inc., basndose en la teora del Sr. Johnson:
Nada es tan blanco como la nieve.
3

Conforme a esa teora, el software estaba casi libre de bugs y por ende poda ser liberado.
Segn el Sr. Johnson, el riesgo de falla era muy pequeo y el costo por demorar ms la
entrega del robot era muy alto. Segn mi cliente, el Sr. Johnson crey que las
condiciones del medio ambiente que podra llegar a disparar un comportamiento errtico y


27
violento del robot eran extremadamente improbables de ocurrir. An ms, el Sr. Johnson
crey que el operador del robot no podra estar en peligro debido a que la interfaz del
usuario fue diseada de modo de permitir al operador detener el robot fijo en sus guas en
el caso de un movimiento del robot que comprometiera la vida del operador.
El Sr. Johnson, Jefe de la Divisin Robtica de Silicon Techtronics, no pudo ser ubicado
para obtener sus comentarios. Randy Samuels ser juzgado el mes entrante en la Corte
de Silicon Valley. Cuando se lo contact por telfono, Samuels deriv todas las preguntas a
su abogado, Alex Allendale.
Allendale tena esto para decir con respecto a los descubrimientos del Profesor Silber:
Mi cliente remiti el software en cuestin del modo usual junto con la documentacin usual
y con la esperanza de que su cdigo fuera probado exhaustivamente. Desconoca hasta
el momento de que saliera a la luz el informe del Profesor Silber, que el cdigo
involucrado en esta terrible tragedia no haba sido probado adecuadamente o que los
resultados de prueba pudieran haber sido falsificados.
El Sr. Samuels nuevamente quiere expresar su gran pesar por este accidente. l, ms
que nadie, quiere que se haga justicia en este caso. El Sr. Samuels nuevamente
extiende sus ms sentidas condolencias a la Sra. Matthews y a sus hijos.

Empleado de Silicon Techtronics Admite Falsificacin de las Pruebas del
Software
Mensajes Tomados del Correo Electrnico Revelan Nuevos Detalles en el
Caso del Robot Asesino
Una Asociacin de Computadores Cientficos Lanza una Investigacin
sobre Violaciones al Cdigo de tica
Especial para el SENTINEL-OBSERVER DE Silicon Valley

Silicon Valey, EEUU
por Mabel
Muckraker
Cindy Yardley, una probadora de software de Silicon Techtronics, admiti hoy que ella
fue la persona que cre las pruebas de software fraudulentas del robot asesino. Las
pruebas fraudulentas fueron reveladas a principios de esta semana por el profesor
Wesley Silber de la Universidad de Silicon Valley, con lo que se ha dado en llamar El
Informe Silber.
Se cuestionan los procedimientos de aseguramiento de la calidad que fueron realizados en
el cdigo del programa escrito por Randy Samuels, el programa acusado por asesinato no
premeditado en el incidente del robot asesino. El Informe Silber afirma que los resultados de
las pruebas reflejados en documentos internos de Silicon Techtronics son inconsistentes
con respecto a los resultados de las pruebas obtenidos cuando fue probado el verdadero
cdigo del robot asesino.
Ayer al medioda, en un acontecer inesperado, anunci su renuncia al cargo de Jefe de
Seguridad de Silicon Techtronics, el Sr. Max Worthington, en una conferencia de prensa
que fue transmitida en vivo por CNN y otros informativos.


28
Worthington sacudi a los periodistas cuando comenz su conferencia de prensa con el
anuncio Yo soy Marta.
Worthington describi de este modo sus responsabilidades en Silicon Techtronics:
Bsicamente, mi trabajo era proteger a Silicon Techtronics de todos los enemigos,
locales y extranjeros. Por extranjeros quiero significar adversarios de otras
corporaciones. Mi papel era ms que nada de direccin. Aquellos que trabajaban bajo
mi supervisin tenan muchas responsabilidades, incluyendo la de proteger la planta en
s, estar alertas por espionaje industrial e incluso sabotaje. Tambin yo era responsable
de vigilar a los empleados que pudiesen estar abusando de drogas o que de algn modo
estuviesen siendo desleales con Silicon Techtronics.
Luego Worthington apunt a una pila de volmenes que haba en una mesa a su
izquierda. Estos volmenes representan tan solo algunos de los mensajes electrnicos de
empleados que yo hice a lo largo de los aos para mi superior, el Sr. Waterson. Estas son
impresiones de mensajes por E-mail que los empleados de Silicon Techtronics se enviaron
entre s y a personas de otros sitios. Puedo decir con gran certeza que nunca jams se le
dijo a ningn empleado que se haca este tipo de requisa electrnica. No obstante, creo
que la evidencia muestra que algunos empleados sospechaban que esto poda estar
pasando.
Varios periodistas preguntaron a los gritos quin en Silicon Techtronics estaba al tanto de
esta requisa.
Worthington respondi. Nadie saba de esto a excepcin del Sr. Waterson y yo, y uno de
mis asistentes que era el responsable de en verdad conducir el monitoreo. Mi asistente
produca un informe especial, resumiendo toda la actividad por E-mail de la semana, y ese
informe era para que lo viera Waterson y yo solamente. Si se lo solicitaba, mi asistente
poda dar un recuento ms detallado de las comunicaciones electrnicas.
Worthington explic que estaba poniendo a disposicin de la prensa las transcripciones del
correo electrnico porque quera que saliera a luz toda la verdad sobre Silicon Techtronics
y el incidente del robot asesino.
Los mensajes de E-mail entre empleados de Silicon Techtronics en verdad revelaron nuevas
facetas del caso. Un mensaje de Cindy Yardley al Jefe de Divisin Robtica, Ray Johnson,
indica que ella falsific a su pedido los resultados de las pruebas. Ac est el texto del
mensaje:
a: Ray Johnson
de: Cindy Yardley
re: Software de Samuels

Termin de crear los resultados de las pruebas de software para ese
software problemtico, segn tu idea de usar una simulacin en vez del
software propiamente dicho. Adjunto encontrars el documento de prueba
modificado, mostrando la simulacin exitosa.
Le deberamos decir a Randy sobre esto? Cindy
La respuesta de Johnson al mensaje de Yardley sugiere que l sospechaba que el correo
electrnico poda no ser seguro:
En respuesta a: Cindy Yardley
de: Ray Johnson
re: Software de Samuels

Saba que podra contar contigo. Estoy seguro de que tu dedicacin a
Silicon Techtronics te ser pagada con creces. Por favor, en el futuro


29
usa un medio de comunicacin ms seguro cuando discutimos este tema. Te
aseguro que el modo en que manejamos esto fue completamente
transparente, pero yo tengo mis enemigos ac mismo en la propia
SiliTech.

Ray.
Estas comunicaciones fueron intercambiadas justo unos das antes que se enviara el robot
Robbie CX30 a Cybernetics Inc. Este hecho es importante porque las pruebas de software
falsificadas no fueron parte de un encubrimiento en el incidente del robot asesino. Estos
hechos parecen indicar que el propsito de falsificar las pruebas de software era
asegurarse de que el robot Robbie CX30 fuera entregado a Cybernetics, Inc. en la fecha
que fue negociada entre Silicon Techtronics y Cybernetics.
Las transcripciones del correo electrnico revelan que hubieron repetidos mensajes de Ray
Johnson a diferentes personas en el sentido de que la Divisin Robtica iba a ser cerrada
definitivamente si el proyecto Robbie CX30 no era completado en trmino. En uno de los
mensajes, diserta con su lder de proyecto, Sam Reynolds, acerca de la Teora Ivory
Snow.

a: Sam Reynolds
de: Ray Johnson
re: no seas un perfeccionista!

Sam:

T y yo hemos tenido nuestras diferencias, pero debo decirte que
personalmente me caes bien. Por favor entiende que todo lo que hago es
con el propsito de SALVAGUARDAR TU TRABAJO Y EL TRABAJO DE TODOS EN
ESTA DIVISIN. Yo te veo a ti y a toda la gente que trabajan para m en la
Divisin Robtica como mi familia.
Waterson fue claro: quiere tener el proyecto del robot completado en
trmino. Y punto. Entonces, no tenemos otro recurso ms que el de Ivory
Snow. Sabes lo que quiero decir con eso. No tiene que ser perfecto. La
interfaz del usuario es nuestro respaldo si esta versin del software para
el robot tiene algunas fallas. El operador del robot va a estar seguro
porque podr cancelar cualquier movimiento del robot en cualquier momento.
Concuerdo contigo en cuanto a que los requerimientos no funcionales son en
algunas partes demasiado vagos. Lo ideal sera que si estos no fueran
tiempos de apuros, cuantificramos el tiempo que le llevara al operador
detener el robot en un caso de accidente. Sin embargo no podemos
renegociar esto ahora. Como tampoco tenemos tiempo para disear
requerimientos no funcionales nuevos y ms precisos. No puedo enfatizar
suficientemente de que estos son tiempos de apurarse. A Waterson no le
cuesta nada deshacerse de toda la Divisin Robtica. Sus amigos del Wall
Street slo le van a decir Felicitaciones!. Vers, para Waterson nosotros
tan slo somos del montn.
Ray.
En este mensaje Ray Johnson parecera estar menos preocupado por la seguridad de
comunicarse por correo electrnico.
El SENTINEL-OBSERVER entrevist ayer por la tarde a Cindy Yardley en su propia casa.
No se pudieron contactar ni a Ray Johnson ni a Sam Reynolds.
La Srta. Yardley estaba notoriamente ofuscada porque sus mensajes por E-mail fueran
dados a conocer a la prensa. De alguna forma me siento aliviada. Sent una enorme


30
culpa cuando ese hombre fue muerto por un robot que yo ayud a producir. Una
tremenda culpa.
El SENTINEL-OBSERVER pregunt a la Srta. Yardley si es que ella haba hecho una
eleccin tica al acceder a falsear los resultados de las pruebas de software. Respondi
con gran emocin. Nada, pero nada a lo largo de mi experiencia y background me prepar
para algo como lo que me pas. Estudi ciencias de la computacin en una universidad de
gran nivel y all me ensearon sobre pruebas de software, pero jams me dijeron que
alguien con poder sobre m me pedira generar una prueba falseada!
Cuando Johnson me pidi que lo hiciera, me llam a su oficina, como para mostrarme las
trampas del poder; ver, algn da me gustara estar en un puesto gerencial. Me sent en
su oficina y vino directamente y me dijo Quiero que falsifiques los resultados de las
pruebas del software de Samuels. No quiero que Reynolds se entere de nada de esto.


31
Yardley contuvo las lgrimas. Me asegur de que probablemente nadie vera jams los
resultados de las pruebas dado que el robot era perfectamente seguro. Era tan slo una
cuestin interna, un tema de prolijidad, en caso de que alguien de Cybernetics o de un
puesto alto dentro de la corporacin le diera curiosidad de ver los resultados de las
pruebas. Le pregunt si estaba seguro de que el robot era seguro y todo eso y me dijo Es
seguro! La interfaz del usuario es nuestra lnea de defensa. En alrededor de seis meses
podemos enviar una segunda versin del software del robot y para ese entonces este
problema de Samuels estar resuelto.
Yardley se reclin en su asiento como si lo que dijera a continuacin necesitara de un
nfasis especial. Entonces me dijo que si yo no falsificaba las pruebas, todos los de la
Divisin Robtica perderan sus trabajos. Sobre esa base decid falsificar las pruebas,
trataba de proteger mi trabajo y el de mis compaeros.
La Srta. Yardley est al presente cursando un grado de Maestra en Administracin de
Empresas en la Universidad de Silicon Valley.
Luego el SENTINEL-OBSERVER pregunto a la Srta. Yardley si an senta que haba
tomado una decisin tica, en vista de la muerte de Bart Matthews. Creo que fui
manipulada por Ray Johnson. l me dijo que el robot era seguro.
Otra revelacin, contenida el las transcripciones del correo electrnico dadas a
conocer, fue el hecho de que Randy Samuels hurt parte del software que us en el
proyecto del robot asesino. Este hecho se revel en un mensaje que Samuels envi a
Yardley cuando ella prob por primera vez su software y dio resultados errneos:
En respuesta a: Cindy Yardley
de: Randy Samuels
re: maldito si lo s

Por mi vida, no puedo entender qu es lo que anda mal en esta funcin
balancear_brazo(). Verifiqu la frmula de la dinmica del robot una y
otra vez y pareciera estar implementada correctamente. Como sabes, la
funcin balancear_brazo() invoca a 14 funciones diferentes. A cinco de
ellas las tom tal cual del paquete estadstico PACKSTAT 1-2-3. Por
favor no se lo digas a nadie! No son stas los que causaran el
problema, o s?

Randy.
Los expertos le dijeron al SENTINEL-OBSERVER que tomar software de paquetes
comerciales de software como el PACKSTAT 1-2-3 es una violacin a la ley. El software
tal como el inmensamente popular PACKSTAT 1-2-3 est protegido por el mismo
copyright que protege al material impreso.
Mike Waterson, Presidente Ejecutivo de Silicon Techtronics, emiti una enojosa
declaracin porque Max Worthington haba dado a conocer las transcripciones del
correo electrnico confidencial. Las declaraciones de Waterson decan, en parte, que
Yo le ped a nuestros abogados que intervinieran en este tema. Consideramos que
esas transcripciones son propiedad exclusiva de Silicon Techtronics. Nuestra intencin
es efectuar cargos ya sea civiles o criminales contra el Sr. Worthington.
Como reaccin a lo ocurrido ayer en el caso del robot asesino, la ACM o Association
for Computer Machinery anunci su intencin de investigar si algn miembro de la ACM
de Silicon


44
Techtronics ha violado el Cdigo de tica de la ACM. La ACM es una asociacin
internacional de computadores cientficos con 85.000 miembros.
La Dra. Turina Babbage, presidente de la ACM, hizo una declaracin en la Conferencia
de Ciencias de la Computacin de ACM que se lleva a cabo cada invierno y que esta
temporada se har en Duluth, Minnesota.
Un extracto de las declaraciones de la Dra. Babbage sigue a continuacin:
Todos los miembros de la ACM estn ligados por el Cdigo de tica y Conducta
Profesional de la ACM [NOTA AL PIE: Un borrador de este cdigo fue dado a conocer en
Comunicaciones de la ACM, Mayo 1992. Por favor ntese que las declaraciones hechas
por la ficticia Dra. Babbage contienen citas del verdadero cdigo de ACM] Este cdigo
establece, en parte, que los miembros de ACM tienen el imperativo moral de contribuir
con el bienestar de la sociedad y los hombres, evitar daos a terceros, ser honestos y
confiables, dar crdito adecuado a la propiedad intelectual, acceder a los recursos de
comunicacin y de computacin slo cuando as lo estn autorizados, respetar la
privacidad de terceros y honrar la confidencialidad.
Ms all de eso, existen responsabilidades profesionales tales como la obligacin de
cumplir los contratos, acuerdos y responsabilidades asignadas, y de dar evaluaciones
profundas y completas de los sistemas de computacin y de sus impactos, poniendo
especial nfasis en los riesgos potenciales.
Varias de las personas involucradas en el caso del robot asesino son miembros de la
ACM y hay causas para creer que han incurrido en violacin del cdigo de tica de
nuestra asociacin. Por lo tanto, estoy solicitando al directorio de la ACM designar una
Fuerza de Tareas para investigar a los miembros de la ACM que puedan haber violado
groseramente el cdigo.
No tomamos este paso a la ligera. Esta sancin ha sido aplicada slo rara vez, pero el
incidente del robot asesino no slo ha costado una vida humana, sino que ha causado
mucho dao a la reputacin de la profesin de computacin.
La Revista Dominical del SENTINEL-OBSERVER - Una Conversacin con el
Dr. Harry Yoder
por
Robert Franklin
Harry Yoder es una figura muy bien conocida en el campo universitario de Silicon
Valley. El profesor de Tecnologa y tica de la Computacin de Samuel Southerland ha
escrito numerosos artculos y textos sobre tica y el impacto social de las
computadoras. Sus clases son muy famosas, y muchos de sus cursos estn completos
mucho antes de que finalice el perodo de inscripcin. El Dr. Yoder ha recibido su
Doctorado en ingeniera elctrica del Instituto de Tecnologa de Georgia en 1958. En
1976 recibi un grado en Maestra en Divinidad del Harvard Divinity School. En 1983
recibi un Master en Ciencias de la Computacin de la Universidad de Washington.
Ingres en la facultad de la Universidad de Silicon Valley en 1988.


45
Entrevist al Dr. Yoder en su oficina del campus. Mi intencin era obtener su reaccin
con respecto al caso del robot asesino y leer su pensamiento sobre los temas ticos
que involucra el caso.
SENTINEL-OBSERVER : Ir de la ingeniera elctrica al estudio de religin parece un gran
salto.
Yoder: Yo era un ingeniero electricista por profesin, pero todos los seres humanos tienen
una vida interior, no lo cree as?
SENTINEL-OBSERVER : S
Yoder: De qu se trata su vida interior?
SENTINEL-OBSERVER : Trata de hacer lo correcto. Tambin se trata de lograr la
excelencia en lo que hago. Es eso lo que lo llev a la Escuela de Divinidad de Harvard?
Usted quera clarificar su vida interior?
Yoder: Sucedan muchas cosas en la Escuela de la Divinidad, y muchas de ellas eran
muy poderosas. Sin embargo, ms que nada yo quera comprender la diferencia entre lo
que estaba bien y lo que estaba mal.
SENTINEL-OBSERVER : Y qu hay de Dios?
Yoder: S, estudi mi propia religin cristiana y a la mayora de las religiones del mundo,
y todas ellas tenan cosas interesantes que decir acerca de Dios. No obstante, cuando yo
discuto sobre tica en un foro tal como este, que es secular, o cuando discuto tica en
mis cursos de tica en la computacin, no coloco a esa discusin en un contexto
religioso. Pienso que la fe religiosa puede ayudarle a una persona a abrazar la tica, pero
por otra parte, todos sabemos que ciertas personalidades notorias que se han
autopronunciado religiosas han sido altamente no ticas. De este modo, cuando yo
discuto sobre tica de la computacin, el punto de partida no es la religin, sino ms bien
un acuerdo comn entre mis estudiantes y yo de que queremos ser gente tica, que el
luchar por la excelencia tica es una tarea humana que vale la pena. Por lo menos, lo
que no queremos es herir a otros, no queremos mentir, robar, hacer trampas, asesinar,
etc.
SENTINEL-OBSERVER : Quin es el responsable de la muerte de Bart Matthews?
Yoder: Por favor disclpeme si lo remito nuevamente a la escuela de la Divinidad de
Harvard, pero creo que uno de mis profesores de all tiene la respuesta correcta a su
pregunta. Este profesor era un hombre mayor, tal vez de setenta aos, de la Europa
Oriental, un rabino. Este rabino dijo que de acuerdo al Talmud, una tradicin antigua de la
ley juda, si se derrama sangre inocente en un pueblo, entonces los lderes de ese pueblo
deben ir a los lmites del mismo y realizar un acto de penitencia. Esto es adems de la
justicia que se le aplicar a la persona o personas que cometieron el asesinato.
SENTINEL-OBSERVER : Ese es un concepto interesante.
Yoder: Y uno de verdad! Un pueblo, una ciudad, una corporacin son sistemas en que
la parte est ligada al todo y el todo a la parte.
SENTINEL-OBSERVER : Usted quiere decir que los lderes de Silicon Techtronics,
tales como Mike Waterson y Ray Johnson, deberan haber asumido la responsabilidad por
este incidente desde el vamos. Adems, tal vez otros individuos, como ser Randy
Samuels y Cindy Yardley, comparten una carga especial de responsabilidad.


46
Yoder: S, responsabilidad, no culpabilidad. La culpabilidad es un concepto legal y la
culpabilidad o la inocencia de las partes involucradas, sean ya en lo criminal o lo civil, ser
decidida en la corte. Estimo que una persona es responsable por la muerte de Bart
Matthews si su accin ha ayudado a causar el incidente - es una cuestin de causalidad,
independiente de los juicios ticos y legales.
Las cuestiones de responsabilidad podran serle de inters a los ingenieros de software y
gerentes, quienes tal vez querran analizar qu es lo que anduvo mal, de modo de evitar
que similares problemas ocurrieran en el futuro.
Mucho de lo que sali de los medios con respecto a este caso indica que Silicon
Techtronics era una organizacin enferma. Esa enfermedad cre el accidente. Quin
cre la enfermedad? La gerencia cre a esa enfermedad, pero tambin los empleados
que no tomaron las decisiones ticas correctas contribuyeron con la misma.
Tanto Randy Samuels como Cindy Yardley eran recin egresados. Se graduaron en
ciencias de la computacin y su primera experiencia en el mundo laboral fue en Silicon
Techtronics. Uno debera preguntarse si recibieron alguna enseanza sobre tica.
Relacionado a esto est la cuestin de si alguno de ellos tena con anterioridad
experiencia en trabajos en grupo. En el momento en que se los asign al desarrollo del
robot asesino, ellos vieron la necesidad de ser personas ticas? Vieron que el xito
como profesionales requiere de un comportamiento tico? Hay mucho ms para ser un
cientfico en computacin o un ingeniero de software que tan slo la habilidad y el
conocimiento de la tcnica.
SENTINEL-OBSERVER : S con seguridad que ninguno de los dos tom cursos sobre
tica o tica de la computacin.
Yoder: Lo sospechaba. Veamos a Randy Samuels. Basndome en lo que le en su
peridico y en otros lados, era bsicamente de los del tipo hacker. Amaba la
computacin y la programacin. Comenz a programar en los primeros aos de la
secundaria y continu a lo largo de toda la carrera universitaria. El punto importante es
que Samuels an era un hacker cuando entr en Silicon Techtronics y ellos le
permitieron que l siguiera siendo as.
Estoy usando el trmino hacker de un modo un tanto peyorativo y tal vez esto no sea
justo. El punto que estoy tratando de remarcar es que Samuels nunca madur ms all
de su angosto enfoque como hacker. En Silicon Techtronics, Samuels an mantuvo esta
actitud en lo que haca a sus funciones de programador, la misma que tena cuando
estaba en la secundaria. Su percepcin de la vida y de sus responsabilidades no creci.
l no madur. No hay evidencia de que tratara de desarrollarse y convertirse en una
persona tica.
SENTINEL-OBSERVER : una dificultad, en lo que hace a ensear tica, es que en
general los estudiantes no les gusta que se les diga esto est bien y aquello est mal.
Yoder: Los alumnos necesitan entender que el tocar temas de tica es parte de ser
computadores cientficos o ingenieros de software profesionales.
Una cosa que me ha fascinado acerca de la situacin de Silicon Techtronics es que a
veces es difcil ver los lmites entre lo legal, lo tcnico y lo tico. Los temas tcnicos
involucran temas de gerencia y de computacin. He llegado a la conclusin de que este
desvanecimiento de los lmites resulta del hecho de que la industria de software an se


47
encuentra en paales. Los temas ticos surgen abruptamente en parte porque hay una
ausencia de lineamientos tcnicos y legales.
En particular, no existen prcticas normalizadas para desarrollar y probar software. Hay
estndares, pero no lo son realmente. Una broma muy comn entre los computadores
cientficos es que lo bueno de los estndares es que hay muchos para elegir.
Ante la ausencia de prcticas normalizadas aceptadas universalmente para ingeniera de
software, surgen muchos juicios de valor, probablemente ms que para cualquier otra
forma de produccin. Por ejemplo, en el caso del robot asesino, hubo una controversia con
respecto al uso del modelo de cascada versus el de prototipo. Debido a que no haba un
proceso de desarrollo de software
estandarizado, esto se transform en una controversia, y los temas ticos surgen por el
modo en que se resuelve la controversia. Usted recordar que el modelo de cascada fue
elegido no por sus mritos sino porque el gerente de proyecto tena experiencia en
ste.
SENTINEL-OBSERVER : Usted cree que Cindy Yardley actu ticamente?
Yoder: Al principio su argumento parece poderoso: ella, efectivamente, minti, para as
salvar los puestos de trabajo de sus compaeros, y por supuesto, el de ella. Pero,
siempre es correcto mentir, para crear una falsedad, en un marco profesional?
Un libro que he usado en mis cursos de tica de computacin es el Ethical Decision
Making and Information Technology (Toma de Decisin tica y Tecnologa de la
Informacin) de Kallman y Grillo [NOTA AL PIE: Este texto es un texto real y est
publicado por McGraw-Hill]. En este libro se dan algunos de los principios y teoras que
estn detrs de la toma tica de decisiones. Yo uso este y otros libros para ayudar a que
los alumnos desarrollen sus apreciaciones sobre la naturaleza de dilemas ticos y toma
tica de decisiones.
Kallman y Grillo presentan un mtodo para la toma de decisin tica y parte de su mtodo
consiste en el uso de cinco pruebas: la prueba de la mam: le dira Ud. a su mam lo que
hizo?; la prueba de la TV: le dira Ud. a una audiencia nacional de TV lo que hizo?; la
prueba del olfato: lo que Ud. hizo tiene mal olor?; la prueba de ponerse en los zapatos
del otro: le gustara que el otro le haga lo que Ud. hizo?; y la prueba del mercado:
sera su accin una buena estrategia de venta?
Lo que hizo Yardley reprob todas estas pruebas, pienso que casi todos concuerdan
conmigo. Por ejemplo, pueden imaginar a Silicon Techtronics usando una campaa
publicitaria que diga algo como?:
En Silicon Techtronics el software que usted recibir de nosotros est libre de bugs,
porque an cuando haya uno, distorsionaremos los resultados de las pruebas para
esconderlo, usted nunca se enterar.. La ignorancia es la felicidad
Esto demuestra que el altruismo aparente no es un indicador suficiente de un
comportamiento tico. Uno podra preguntarse qu otros motivos no declarados tena la
Srta. Yardley. Podra ser que la ambicin personal la llevara a aceptar la explicacin que
le dio Ray Johnson y su afirmacin de que el robot era seguro?
SENTINEL-OBSERVER : Existe alguna fuente de gua tica para gente que
se ve confrontada con un dilema tico?


48
Yoder: Algunas empresas dan gua tica, en la forma de polticas de la corporacin, y
existe un documento as en Silicon Techtronics, o por lo menos as me dijeron. Yo no lo vi.
Un empleado tambin podra remitirse a los lineamientos ticos que proveen sociedades
profesionales, tales como la ACM. Adems, el o la empleada podra leer sobre el tema para
obtener una mejor percepcin de la toma tica de decisiones. Por supuesto que uno
siempre debe consultar con su propia conciencia y con sus convicciones ms profundas.
SENTINEL-OBSERVER : Usted cree que Randy Samuels actu
ticamente? Yoder: Robar software en el modo que lo hizo es tanto ilegal
como no tico.
Pienso que el punto ms importante con Randy Samuels nunca fue discutido en los
medios de prensa. Honestamente dudo que Samuels tuviera el conocimiento necesario
para su puesto. Este tipo de conocimiento se lo llama conocimiento de la especialidad.
Samuels tena conocimiento de computacin y programacin, pero no tena un slido
conocimiento de fsica, en especial de la mecnica clsica. Su falta de conocimiento en el
dominio de la aplicacin fue una causa directa del horrible accidente. Si alguien con
conocimientos de matemticas, estadsticas y fsica hubiera programado al robot en lugar
de Samuels, probablemente hoy Bart Matthews estuviera vivo. No tengo dudas de ello.
Samuels malentendi la frmula fsica porque no entendi su significado e importancia en
la aplicacin en el robot. Puede ser que la gerencia sea en parte responsable por la
situacin. Puede que Samuels les haya dicho acerca de sus limitaciones y la gerencia
habr dicho. Y bueno, qu importa
Samuels tena dificultades en trabajar en equipo, hacer revisiones en conjunto, y
programar sin egosmo. Es posible que estuviera intentando esconder su falta de
experiencia en el rea?
SENTINEL-OBSERVER : Cree que Ray Johnson actu ticamente?
Yoder: Este tema del Ivory Snow! El problema con la teora del Ivory Snow es que
es tan solo eso, una teora. Si fuera ms que una teora, o sea una metodologa real
para mantener la probabilidad de la falla dentro de lmites estadsticamente
determinados, como lo que se llama ingeniera de software en sala limpia [cleanroom
software engineering], entonces habra menos culpabilidad en ese punto.
Basndome en la informacin que dispongo, la teora de Ivory Snow fue tan slo una
racionalizacin para sacarse de encima a software fallado y entregarlo en trmino al
cliente. Esta teora slo es vlida, tica y profesionalmente, si al cliente se le informa de
los bugs de los que se tiene conocimiento, o de impurezas, utilizando la jerga. En el caso
de Silicon Techtronics, la teora Ivory Snow funcion as: sabemos que no es puro, pero
el cliente cree que s lo es!
Desde luego, presionar a Cindy Yardley como lo hizo Ray Johnson tampoco es tico. El
crea en lo que le dijo a la Srita. Yardley, es decir, que el robot era seguro, o fue eso una
mentira del momento? Si el crea que el robot era seguro, entonces por qu cubrirse
con pruebas falsas? Si la interfaz con el usuario era tan importante como la ltima lnea de
defensa, entonces por qu evitar pruebas ms rigurosas de la interfaz?
SENTINEL-OBSERVER : Qu piensa de Mike Waterson en todo esto?


49
Yoder: Si Johnson es el padre de la teora Ivory Snow, Waterson el es abuelo. Su exigencia
de que el robot estuviera completado para una fecha determinada o de lo contrario
rodaran cabezas, puede haber causado que Johnson formulara la teora Ivory Snow.
Ver, es evidente que Johnson pensaba que era imposible entregar a Cybernetics Inc. el
robot CX 30 para una fecha determinada, a menos que el software fuera con bugs.
En muchos sentidos pienso que Waterson actu sin tica e irresponsablemente. Pone a
Sam Reynolds a cargo del proyecto del robot, cuando an l, Reynolds, careca de
experiencia con robots e interfaces con el usuario modernas, Reynolds rechaz la idea de
desarrollar un prototipo, lo que podra haber permitido el desarrollo de una mejor interfaz.
Waterson cre una atmsfera opresiva entre sus empleados, que en s mismo es falto de
tica. No slo amenaz con despedir a todos los de la Divisin Robtica si el robot no se
terminaba a tiempo, sino que hurg en comunicaciones por correo electrnico privadas de
toda la corporacin, un derecho controvertido que algunas empresas alegan tener.
Mi creencia personal es que este tipo de investigacin es falto de tica. La naturaleza del E-
mail es algo as como un hbrido de correspondencia comn y conversacin telefnica.
Monitorear o espiar la correspondencia ajena est considerado no tico, tal como lo es
interferir un telfono. Por cierto, estas actividades tambin son ilegales bajo la mayora de
las circunstancias. O sea, creo que monitorear a los empleados del modo que lo hizo
Waterson es un abuso de poder. SENTINEL-OBSERVER: Usted cree que en esto
el fiscal tiene un caso? Yoder: Contra Randy Samuels?
SENTINEL-OBSERVER : S. Yoder: Lo dudo, a menos que ella tenga informacin que
hasta ahora no se ha hecho pblica. El asesinato no premeditado, a mi entender, implica
un tipo de acto irresponsable y negligente, que causa la muerte de un tercero. Se aplica
esta descripcin a Samuels? Pienso que la mejor apuesta de la fiscal es hacer hincapi
en su falta de conocimiento en el rea de aplicacin, si puede mostrarse que Samuels se
involucr deliberadamente en un fraude.
La semana pasada le que el 79% de la gente est a favor de la absolucin. La gente es
proclive a acusar a la compaa y a sus gerentes. La otra noche, uno de los noticieros dijo,
Samuels no es un asesino, es un producto de lo que lo rodea.
SENTINEL-OBSERVER : Podra nuevamente decir su posicin sobre el tema de la
responsabilidad final en el caso del robot asesino?
Yoder: En mi mente, el tema de la responsabilidad del individuo versus la responsabilidad
de la corporacin, es un tema muy importante. La corporacin cre un entorno en el que
podan ocurrir este tipo de accidentes. An as, los individuos, dentro de ese sistema,
actuaron sin tica e irresponsablemente, y fueron los que de hecho causaron el accidente.
Una compaa puede crear un entorno que saca a flote lo peor de sus empleados, pero
cada empleado tambin puede contribuir a empeorar ese ambiente corporativo. Este es un
lazo cerrado que se alimenta a s mismo, un sistema en el sentido clsico. Entonces, hay
cierta responsabilidad de la corporacin y cierta responsabilidad de los individuos en el
caso del robot asesino.
SENTINEL-OBSERVER : Muchas gracias Profesor Yoder.


50
Te has preguntado por qu no alcanzas tus metas?

Es una pregunta en general para los alumnos para descubrir los posibles motivos,
causas que dan pie a que fallemos en alcanzar los propsitos, por qu no
terminas tus proyectos de software a tiempo, en el costo y con la calidad
establecida?, o cualquier otro proyecto, aprobar un examen, ganar una
competencia deportiva, ahorrar, etc.

Falta Tiempo?!

Bomberazos - no hay tiempo para planear.
Ms bomberazos - no hay tiempo para mejorar.
Ms, ms, ... , bomberazos - no hay tiempo para
otra cosa (estimar, registrar datos, analizar, etc.).
nicamente se presta atencin al problema actual. nicamente se presta atencin al problema actual. nicamente se presta atencin al problema actual.

Muchas de las veces, la respuesta inmediata es es que no tengo tiempo, pero,
cmo saben que efectivamente no tienen tiempo?, en qu consumen el tiempo
que tienen?, si tienen problemas, cmo los atienden?, descuidan otras tareas,
actividades para solucionar lo urgente, lo prioritario?

Por qu la industria del software no puede alcanzar sus
objetivos?

Y si extrapolramos las ideas, respuestas a nivel personal a la industria del
software, seran las mismas?, probablemente s, pues al fin y al cabo quien
produce el software son personas, claro que habr algunos otros factores propios
de una organizacin ajenos a lo personal.


51
Evolucin

Ms demandante. - Da tras da,
la industria y sociedad
requieren de ms y ms
software.
Ms grande.- Esto va desde
satisfacer pequeas
necesidades hasta grandes
expectativas.
Ms complejo.- Por lo que las
soluciones tcnicas y
administrativas se vuelven
complejas.
S
o
f
t
w
a
r
e

Debido a la penetracin constante y creciente del software a mbitos de la vida
cotidiana, los propios usuarios son los que exigen ms y ms, sistemas de
software ms sofisticados en menos tiempo, estas exigencias tambin de negocio
incrementan la complejidad que se multiplica al combinarse con cuestiones de
mercado. Ahora, los avances tecnolgicos, el ritmo con que se liberan, estn
dictados por esta demanda.

Reflexiona

Me dejara operar con software creado por m?

Ejercicio

Tmate algunos minutos y reflexiona la siguiente pregunta, piensa en todo el
software y la manera en que lo has creado. Anota tus reflexiones, el porqu s y el
porqu no, comparte estas reflexiones con tus compaeros.

Por ejemplo, si estuvieras en el quirfano y vieras que el aparato para realizarte
una intervencin en tus ojos es controlado por aquel software que alguna vez
desarrollaste.

De esta respuesta se puede pone r un antecedente para dejar en claro que
realmente hace falta aplicar mecanismos para realizar un mejor trabajo. Si la
respuesta general es que s se dejaran operar, preguntar entonces, confiaran en
el software y hardware con el cual interactuara el software que ellos crearan


52
(sistemas operativos, administradores de bases de datos, memorias RAM,
unidades de procesamiento, etc.).

El trabajo del Ingeniero de Software

Todo trabajo (producto/servicio) de un Ingeniero de Software se debe ajustar a:
Producir/Brindar productos/servicios de calidad.
Hacerlos dentro del costo.
Completarlos en el tiempo.

En esencia esto es el trabajo de cualquier profesional, el punto aqu es hacer una
analoga con los objetivos de la ingeniera de software, es decir, el trabajo del
Ingeniero de Software es cumplir y hacer cumplir los objetivos de la Ingeniera de
Software.

Qu vs. Cmo

El cmo hacer es tan importante como el qu se va a hacer.
Es decir, debemos tambin manejar y controlar la manera en que hacemos las
cosas y no nicamente pensar en el resultado final. Es a travs de la ejecucin
adecuada de los procesos que llegaremos al producto deseado.

Producto

Si nos centramos en el producto (el qu), podemos no darnos cuenta de cmo
mejorarlo.

En cierta parte de la historia automotriz, algunas compaas se centraban en
corregir las fallas en cada uno de los automviles, es decir, pensaban ms en el
qu, en el producto, corregan las fallas en cada uno de los productos.

Si nos centramos en el proceso (el cmo), podemos:
Predecir la repeticin de la salida.
Conocer las tendencias del proyecto.
Controlar las caractersticas de calidad en el producto.


53
Lleg el tiempo, en que una de ellas, pens ms en el porqu salan defectuosos
sus productos, e investig la manera en que los produca, encontrando fallas en su
cmo eran construidos, as corrigi esa manera de desarrollar sus automviles y la
falla no se volvi a presentar. Mejorar los procesos tendr un impacto positivo en
el producto resultante, si no en funcionalidades, al menos en el costo.

PROCESO
Gente con habilidades,
entrenamiento y motivacin
Procedimientos que definan la
relacin entre las actividades
Herramientas y equipo
Define en tus propias palabras
lo que es un proceso?

Podemos definir a un proceso como una la combinacin de un conjunto de
actividades (procedimientos) que deben ser realizadas por un conjunto de
personas que tienen las habilidades para ello y que adems utilizarn
herramientas que les permitirn realizar su trabajo en forma ms eficiente. As,
podemos definir al proceso de desarrollo de software como el conjunto de
actividades que tienen que ejecutarse para producir el software, las cuales sern
ejecutadas y controladas por personas con el conocimiento y las habilidades para
ello (los Ingenieros de Software), que utilizarn herramientas que les permitan
realizar su trabajo ms rpido y poder comunicar de mejor manera la intencin de
cada uno de los productos de trabajo que realizan de forma tal que se entienda
que se han cumplido los requisitos establecidos, incluyendo los de calidad, en
cada uno de estos productos.

Ejercicio

Define un Proceso:

1. Describe el proceso que sigues para baarte.
2. Describe el proceso para hacer un pastel.

El ejercicio tiene como objetivo que los estudiantes se den cuenta que definir
implica un esfuerzo.


54
Qu se tiene que hacer.
En qu orden se tiene que hacer.
Quin lo tiene que hacer.
Qu hay que tomar en cuenta antes de realizar las actividades.
Qu recursos se necesitan para realizar las actividades.
Cules son los resultados de las actividades.
Cmo saber que ya se termin cada actividad.
Qu saber y qu hacer para poder mejorar la forma de realizar el trabajo y
que estos puntos deben estar presentes en la definicin de procesos.

Creatividad vs. Disciplina

La creatividad emerge y se mejora con disciplina.
Los procesos nos sirven para no pensar en las cuestiones mecnicas y tener ms
tiempo para la parte creativa en la construccin de las soluciones.
Entonces, si existen procesos que nos dicen qu hacer, cmo hacerlo y cundo
hacerlo, se pudiera pensar que el proceso de desarrollo de software mecaniza la
creacin de productos de software haciendo de esta actividad algo fra. No, el
hecho de tener procesos para desarrollar software nos permite concentrarnos en
lo importante, en las cuestiones crticas dejando que los procesos nos guen a
cada paso.

Utilizando procesos, podemos cambiar?

El desarrollo de software es una actividad muy intensa, personas en forma
individual siguen escribindolo.
Cualquier mejora en la eficiencia o productividad de estas personas, resultar en
ganancia en los proyectos y en la industria en general.
Al final, quienes escriben el software son personas, en proyectos de muchos
ingenieros de software a cada uno le corresponde una parte, la calidad del trabajo
final depende de la suma de las habilidades y conocimiento de cada uno de los
miembros del equipo de desarrollo, as que cualquier ganancia en modificar la
forma de desarrollar software, en los procesos que se siguen a nivel de equipo o
personal, tendr una repercusin en la calidad del producto.


55
Qu hace falta?
Necesitamos una disciplina de Ingeniera de Software que provea a las personas
que desarrollan los componentes, un mtodo para planear, dar seguimiento y
administrar efectivamente los defectos. Ms an, que les permita aprender de sus
xitos y fracasos.
De dnde tomar el conjunto de procesos que nos ayude?, de eso se trata
precisamente este curso, de aprender tcnicas que aplicadas en conjunto
permitirn potenciar las habilidades y conocimiento en el desarrollo de software.
Hay que distinguir entre:
La realizacin del producto.
La administracin del proyecto.
Planeando el trabajo.- qu hacer y cmo hacerlo.
Realizando el trabajo.- segn lo planeado.
Buscando la calidad.- dando seguimiento, evaluando y mejorando el producto y el
proceso.
Entonces, para resumir, una cosa es el producto que vamos a desarrollar y otra
cosa muy distinta el cmo lo vamos a desarrollar, necesitamos un conjunto de
procesos que nos permitan planear el trabajo, realizar el trabajo y al mismo tiempo
nos ayude en el camino de mejorar la forma que tenemos de trabajar. Ese es el
conjunto de habilidades y conocimiento que la metodologa a estudiar nos
presenta y que necesitamos aprender y aplicar si en verdad queremos
convertirnos en Ingenieros de Software.

PSP, ser parte de ese proceso

PSP es un mtodo basado en procesos, es un mtodo de mejora continua a
nivel personal.
Con PSP tenemos la oportunidad de aprender a usar y ver los beneficios de
trabajar de una manera disciplinada y orientada a procesos.
PSP fue desarrollado en el Instituto de Ingeniera de Software de la Universidad
de Carnegie Mellon por Watts Humphrey.
Slo para poner en antecedentes las tcnicas estn basadas en la metodologa
desarrollado por Watts Humphrey, aunque es importante decir que por s mismas
las tcnicas ya existan, lo que hizo Humphrey fue ponerlas dentro de un marco de
trabajo aplicativo, describiendo guas de la aplicacin paso a paso.


56
1.2. Qu es PSP?

PSP comprende:

PSP = Planeacin* + Diseo + Revisiones de Diseo* + Codificacin +
Revisiones de Cdigo* + Pruebas

PSP ensea, re-ensea desde una perspectiva sistmica muchos conceptos de
Ingeniera de Software, en este curso veremos partes de esos procesos,
sentaremos las bases para aplicar en su totalidad PSP.

Tradicionalmente al desarrollar software a nivel personal (y muchas veces a nivel
de organizacin), las actividades o fases ms comunes, si no las nicas son las de
Codificacin y Pruebas. Despus, quiz se realice diseo, pero planeacin y
revisiones de cdigo y diseo?

En este curso abarcaremos parte de la planeacin, cuestiones de codificacin y
administracin de defectos.

PSP es un marco de trabajo basado en procesos.
Ensea y ayuda a los Ingenieros de Software a:
Planear y dar seguimiento.
Cumplir sus compromisos.
Crear productos de calidad.
Resistir a presiones irracionales
Identificar sus reas de mejora.
Lo anterior con el registro y anlisis de los datos emanados de los propios
procesos de los Ingenieros de Software.
Con crear productos de calidad se refiere a que se tienda al concepto de cero
defectos. Resistir presiones irracionales es negociar los tiempos de desarrollo con
base a datos histricos y estadsticas que demuestren la tendencia de la
productividad de los ingenieros de software, para que stos tengan herramientas
con las cuales demostrar que los tiempos que proponen son los correctos.

PSP est basado en la mejora continua, y lo demuestra al pedir realizar anlisis
de los indicadores de rendimiento que se registran y de analizar la manera en que
se est trabajando para proponer nuevas formas, ms econmicas en tiempo y
costo, que incrementen la productividad.


57
Ejemplos en otras disciplinas
Otros profesionales, como los qumicos, cirujanos, pilotos aviadores, msicos,
demuestran competencias bsicas antes de realizar an los procedimientos ms
simples.

Por qu los Ingenieros de Software no?

Con la aplicacin sistemtica de las tcnicas presentadas en este curso podremos
obtener la competencia necesaria.

Qu tiene que hacer un piloto para demostrar que est listo para hacerse
responsable de una aeronave?

Qu tiene que demostrar un cirujano para poder realizar operaciones?

Qu esperaramos que demuestre un Ingeniero de Software para confiarle la
construccin de productos de software?

Que demuestre que sus productos corren sin problemas, que son fciles de usar,
que hacen lo que deben de hacer.

Qu utilizaremos?

Formas.- Un conjunto de plantillas en donde registraremos diversos indicadores
de la manera en que construimos nuestros productos de software.


58

PSP est basado en un conjunto de formas, guas y descripcin de procesos. En
el curso utilizaremos algunas de estas formas y explicaremos y utilizaremos los
procesos, con variaciones, de varias las tcnicas presentadas en PSP.

Las formas te ayudan a evitar el desperdiciar el tiempo pensando el formato y lo
que debe llevar. Pero, las formas buenas son difciles de construir, por lo que
deben ser revisadas peridicamente para ver que cumplan con las necesidades
del momento.

1.2.1 Principios en los que se basa PSP

1. La calidad de los sistemas de software depende de la calidad de sus peores
componentes.
2. La calidad de los sistemas de software depende de la calidad de sus peores
componentes.
3. El ingeniero de software debe conocer su rendimiento, medir, dar
seguimiento y analizar su trabajo y aprender de las variaciones de su
rendimiento e incorporar estas lecciones a sus prcticas personales.

Una cadena es tan fuerte como su eslabn ms dbil!


59

Para qu nos sirve PSP?

1. Conocer nuestro rendimiento: al medir nuestro trabajo, reconocer que
funciona mejor y aprender a como repetirlo y mejorarlo.
2. Entender las variaciones: lo que es repetible y lo que podemos aprender de
las variaciones.
3. Incorporar estas lecciones en una creciente documentacin de prcticas
personales.
Para dejar de ser nicamente programadores y convertirnos en verdaderos
Ingenieros de Software

Ejercicio

Del siguiente artculo realiza un resumen:
Ferguson, Pat, Watts S. Humphrey, Soheil Khajenoori, Susan Macke,
and Annette Matvya, "Introducing the Personal Software Process:
Three Industry Case Studies," IEEE Computer, Vol. 30, No. 5, May
1997, pp. 24-31.
Este artculo describe en trminos generales lo que es PSP. Si el profesor no ha
tomado los cursos de PSP o no est capacitado, es recomendable que lea
tambin este artculo.


60
1.2.2. El modelo PSP

11/11/2004 Tcnica Personal de Calidad en Programacin 43
PSP0
Proceso actual
Registro de Tiempos
Registro de Defectos
Estndar de Tipos de Defectos
PSP0.1
Estndar de codificacin
Mediciones de tamao
Propuesta de mejora del proceso
PSP 1
Estimacin de tamao
Reporte de pruebas
PSP1.1
Planeacin de tareas
Programacin de actividades
PSP2
Revisiones de cdigo
Revisiones de diseo
PSP2.1
Plantillas de diseo
PSP3
Desarrollo cclico
Proceso Personal Base
Proceso de Planeacin
Personal
Administracin de
la Calidad Personal
Proceso cclico Personal
El modelo PSP

Este modelo est explicado en las siguientes lminas. Aqu hay que mencionar
que est descrito por niveles ms para cuestiones de aprendizaje que para su
aplicacin, el beneficio completo de PSP est basado en la aplicacin total de
sus conceptos.

Nivel 0

PSP0
Proceso actual
Registro de Tiempos
Registro de Defectos
Estndar de Tipos de Defectos
PSP0.1
Estndar de codificacin
Mediciones de tamao
Propuesta de mejora del proceso
Nivel 0

Registro de las mtricas bsicas del proceso actual de desarrollo del programador,
dichas mtricas es el tiempo y los defectos con base a un estndar de clasificacin
de los mismos, de igual forma en este nivel se introduce la aplicacin de
estndares de programacin y registros de medicin del tamao de los programas
generados.


61
Nivel 1
PSP 1
Estimacin de tamao
Reporte de pruebas
PSP1.1
Planeacin de tareas
Programacin de actividades
Nivel 1

Ensea al programador a estimar el tamao y el tiempo que ocupar en cada una
de las fase de implementacin de sus programas; esta estimacin est basada en
mtodos estadsticos e informacin histrica que el mismo programador ha
generado a lo largo de la aplicacin del nivel 0 en varios programas.

Nivel 2
PSP2
Revisiones de cdigo
Revisiones de diseo
PSP2.1
Plantillas de diseo
Nivel 2

Las revisiones permiten verificar el aumento de la calidad de los productos
generados por el programador y minimizar el nmero de defectos inyectados en su
diseo y en su programacin, esto permite que el nmero de defectos en las fases
de pruebas y entrega al cliente disminuyan significativamente y que por lo tanto el
tiempo de deteccin y correccin de defectos se minimicen, de igual forma en este
nivel se incorporan formatos para realizar el diseo de los programas en forma
estndar.

Nivel 3
PSP3
Desarrollo cclico
Nivel 3

Se incorporan tcnicas de desarrollo cclico a fin de permitir utilizar los
procedimientos definidos por el Personal Software Process a proyectos de mayor
tamao y de mayor duracin.


62
Algunos resultados obtenidos
Results of applyingthe Personal Software Process Pat
Ferguson et al. IEEE Computer 1997.

La interpretacin de estos y otros resultados pueden leerse del artculo sealado.
Se les puede pedir a los alumnos que lean y hagan un resumen.

Es PSP la solucin?

PSP no es la panacea a todos los problemas de la Ingeniera de Software. Todo
es posible de ser perfeccionado, pero hay que empezar por algo y PSP es una
buena opcin.
Adems, sus tcnicas las podemos aplicar a otras actividades de nuestras vidas.
Existen muchos seguidores como detractores de PSP. Sin embargo como se
seala, es un buen principio, un muy buen principio para mejorar la construccin
de productos de software.

Muchas de las tcnicas que vamos a estudiar las podemos aplicar en otros
quehaceres de nuestra vida, y dan tambin buenos resultados.

El inicio hacia nuestra mejora en el desarrollo de productos y servicios de
software.
Poniendo las bases, este es el primer nivel de PSP, aqu estudiaremos la
manera en que invertimos el tiempo que tenemos para trabajar. Sentaremos las
bases para la mejora. Haciendo una analoga, cuando nos sentimos enfermos y
vamos al mdico, qu es lo primero que nos hace el mdico?

Nos realiza una exploracin, nos manda a realizar unos anlisis. Esto es porque
necesita poner un punto de referencia para que despus de que nos d el
tratamiento pueda comparar si el tratamiento est resultando o no.


63
Esto mismo haremos, primero conoceremos nuestro estado en el desarrollo de
software para despus, siguiendo los procedimientos descritos saber si nos
funcionan o no.

Reflexiona
1. Cmo te preparas para aprobar un examen?
2. Cmo se prepara un equipo deportivo para ganar una competencia?
3. Cmo le haces para pasar de un nivel a otro en un juego de video?
4. Cunto tiempo se invierte en la preparacin?

El propsito es hacer reflexionar a los alumnos para que determinen los procesos
que siguen en las actividades descritas, cunto tiempo emplean en alcanzar el
objetivo

1.2.2.1 El ciclo de Mejora Continua

Define tu meta
(tu objetivo
de mejora)
Mide cmo
ests hoy
(Conocer)
Entiende cmo
haces tu trabajo
(cmo es tu
proceso)
Compara el
resultado con
la meta
Mide tu
nuevo
resultado
Usa tu
proceso
modificado
Ajustar tu
proceso con
rumbo a tu
objetivo
Reciclar y continuar la mejora
Si no sabes qu ests haciendo, es difcil que
lo mejores!
Alcanzaste tu objetivo?,
bravo!, ponte objetivos ms
altos, retadores
No Alcanzaste tu objetivo?,
ajusta nuevamente tu proceso,

Con las lminas anteriores se comenz a poner las bases para darnos cuenta de
qu hacemos y cmo lo hacemos, esto es el punto de partida para alcanzar los
objetivos que nos tracemos. Primero definimos a dnde queremos llegar, despus
medimos cmo estamos y/o cmo est la competencia, trabajamos en entender
cmo hacemos las cosas, si no est funcionando o encontramos mejores maneras
de hacerlas, modificamos nuestro cmo hacer, lo probamos, medimos el resultado
de esta nueva forma de trabajar y si no funciona, realizamos las modificaciones
necesarias para conseguir los objetivos iniciales. Si funciona, nos ponemos metas
ms altas y comenzamos el ciclo.


64

La base de la mejora personal
El primer proceso que desarrollaremos ser el que te permita la recoleccin de
datos sobre el tiempo que inviertes en cada tarea de software.
Estos datos te ayudarn a analizar en qu inviertes tu tiempo, en dnde inviertes
ms tiempo, es decir, en dnde te tardas ms.
Y quiz, primero, que te des cuentas de qu es lo que haces y as podrs decidir
si vale o no la pena invertir tanto tiempo en ello.

Ejercicio 1

Realzate las siguientes preguntas y registra la siguiente informacin, piensa en un
da normal de escuela o trabajo:

1. Cunto tiempo dorm?
2. Cunto tiempo estudi/trabaj?
3. Cunto tiempo me llev trasladarme de un lugar a otro (casa-
escuela/trabajo-casa)?

Ejercicio 2

Ahora piensa en lo siguiente:

1. Cuntas veces te levantaste durante la noche (para ir al bao, tomar agua,
despertaste por pesadillas, etc.)?
2. En el trabajo/escuela, cuntas veces fuiste al bao, a tomar agua?,
cunto tiempo empleaste para tomar tu almuerzo, hablando por telfono,
platicar con amigos, leyendo el peridico?


65
Resultados

Del tiempo que registraste en la pregunta 1 del ejercicio 1, rstale el tiempo que
empleaste en las actividades de la pregunta 1 del ejercicio 2. Haz lo mismo con la
pregunta 2 de ambos ejercicios.
Ahora tienes un panorama ms claro de cuanto tiempo empleas en algunas tareas
diarias. Realmente trabajas/estudias lo que pensaste inicialmente?
La situacin ms probable es que los alumnos se sorprendan de la cantidad
(mnima), del tiempo efectivo que realmente le dedican a los estudios.

Nuestra bitcora

Utilizando la siguiente plantilla, registra las actividades de 3 a 5 das consecutivos
(dormir, ver tele, transportacin, comer, hacer tareas, juntas, hablar por telfono, ir
al bao, etc.).

Fecha Actividad Hora inicio
(en minutos)
Hora
finalizacin
(en minutos)
Tiempo total
empleado
(en minutos)

Este ejercicio permitir comenzar a registrar datos, crear el hbito de registrar la
informacin que estamos generando. En el archivo anexo, Forma de registro de
tiempos contiene la plantilla completa y la explicacin de su uso.

Administrar nuestro tiempo

Para poder cambiar, necesitamos primero, conocer cmo estamos. Por ello el
ejercicio de la bitcora de registro de actividades.
Recuerda es tu tiempo, qu haces y cmo lo inviertes es tu responsabilidad y va
en funcin de tus necesidades.


66
En qu invert mi tiempo?
Qu dej de hacer?, en su lugar qu hice?, por qu no las hice?
Qu me consume ms tiempo?
En qu invierto menos tiempo cuando debiera invertirle ms?

Despus de que haya concluido el tiempo asignado para la tarea de la bitcora, el
profesor debe revisar que est bien llenada y no haya discrepancias en la
informacin (omisiones e inconsistencias). El profesor puede pedir ahora que los
alumnos hagan un anlisis, sntesis de las actividades principales que realizan y el
tiempo total que le dedican por da y semana.
El tiempo es uno de los recursos ms importantes, hay que tener en cuenta que
para que podamos sacarle el mayor provecho, ste tiene que ser y estar
organizado.
Una mala organizacin nos har perder mucho tiempo.
Antes de actuar hay que planear y programar cmo vamos a distribuir el tiempo,
ya que ste es limitado.
Debemos administrar nuestro tiempo de la manera ms efectiva para cumplir
nuestros compromisos.
Si no tenemos orden, si no sabemos qu hacer y cundo hacer cada cosa el caos
cunde. Es importante que de ahora en adelante sepamos qu tenemos que hacer
con anterioridad para organizarnos mejor. LOS COMPROMISOS ADQUIRIDOS
DEBEN SER CUMPLIDOS.

Elementos que nos harn perder tiempo
Mala organizacin (mala o falta de planificacin).
Exceso de compromisos.
Intrusiones (llamadas telefnicas, reuniones mal planeadas o a destiempo).
Falta de delegacin.
Pedir a los alumnos que hagan un nuevo anlisis y descubran los motivos por los
cuales no estn cumpliendo sus objetivos, qu les impide o distrae de realizar sus
compromisos.


67
Actividades Preactivas y Reactivas

Para aprovechar al mximo el tiempo debemos clasificar las actividades en:
Preactivas: aquellas que estn programadas (reuniones, tareas,
exmenes).
Reactivas: las que no estn planeadas.
Debemos minimizar el tener actividades reactivas!
Del anlisis realizado, qu porcentaje de las actividades son reactivas y cuntas
preactivas, qu pueden hacer para que las actividades preactivas sean las que
predominen?

Para un trabajo ms eficaz:
Tener organizado y limpio el lugar de trabajo.
Cuidar el aspecto personal.
Cada cosa en su momento.
Tener una agenda diaria (tener planeado lo de hoy).
Cumplir los compromisos.
Lista priorizada de los pendientes.

Sugerencias para mejorar la organizacin del tiempo

1. Poner horarios realistas a nuestras actividades.
2. Objetivos cortos y largo plazo.
3. Tener un horario diario y semanal lo ms preciso posible.
4. No planear hacer muchas cosas al mismo tiempo.
5. Replanear cuando sea necesario.
6. Ser constante en la aplicacin de lo planeado.
7. Realizar las mismas tareas en los mismos momentos.
8. Reordenar las actividades para que se lleven a cabo en los momentos que
tengamos mejor rendimiento.
9. No dejar para maana lo que se puede hacer hoy.


68
10. Utilizar la curva de trabajo.
11. Tomar breves descansos.

Ser una persona organizada significa ser eficaz; saber organizarse es un hbito
que hemos de lograr, aunque cueste un poco de trabajo.

Con tu bitcora, analiza los datos, trata de justificar cada actividad (por qu, para
qu la realizo, necesita todo ese tiempo, qu me distrajo mientras la realizaba?).

Comienza a planear tus actividades diarias y semanales, sigue llevando la bitcora
y realizando los anlisis para mejorar la organizacin de tu tiempo.

En la Ingeniera de Software me sirve todo lo anterior?

La idea es relacionar todo la experiencia de la vida cotidiana al desarrollo de
software, contestar las preguntas de cmo aplicaran lo aprendido a la manera en
que desarrollan el software (los alumnos).
S, por supuesto, durante el desarrollo de un producto de software el Ingeniero de
Software realiza muchas tareas, tiene interrupciones (llamadas de los clientes por
ejemplo), adquiere compromisos de entrega, etc.
Tiene que cumplir con su trabajo en tiempo!

En Resumen

La base lgica de la administracin del tiempo es la siguiente:
Se emplear la misma cantidad del tiempo y de la misma manera esta semana
como se hizo la semana pasada.
Por supuesto que hay excepciones. Por ejemplo, durante el periodo de exmenes,
podra no atenderse al mismo nmero de clases por estar estudiando. Otro
ejemplo, el caso de la presencia de un huracn.
Del segundo prrafo se despende la justificacin del ejercicio, qu tanto tiempo
efectivo tengo disponible para dedicrselo a las tareas productivas?, cules son
los perodos disponibles para trabajar?
Para realizar planes realistas, se le tiene que dar seguimiento a la manera en que
se emplea el tiempo.


69
La gente recuerda algunas cosas y olvida otras. Por ejemplo, la cantidad de
tiempo empleado para hacer la tarea; mientras que el tiempo empleado en
relajacin y comidas, podra ser ms de lo pensado.
Para saber a donde se va el tiempo, se necesita mantener un registro preciso.

Para saber qu hacemos debemos

1. Categorizar las actividades.
2. Registrar el tiempo empleado en cada actividad.
3. Registrar el tiempo de manera estandarizada.
4. Guardar los datos en un lugar conveniente.
Cuando la gente dice que est trabajando duro, lo que realmente quiere decir es
que est trabajando ms horas (no que son ms productivos)!
Con categorizar las actividades nos referimos a enmarcar dentro de algo ms
grande a un conjunto de actividades ms pequeas. As por ejemplo estar
codificando diversas rutinas, cada una de ellas debe ser registrada para saber
cunto tiempo nos tom codificarlas, sin embargo, nos interesar saber el tiempo
total de la codificacin, por lo que la accin de estar codificando la enmarcamos en
la fase de Implementacin.

El proceso que seguiremos para desarrollar nuestro 1er programa

Planeacin
Compilacin
Requerimientos
desarrollar nuestro 1er programa
Diseo
Codificacin
Pruebas
{
{
{
Tiempo que emplears para entender el
problema ms el tiempo para calcular cunto
te vas a tardar en realizar todo el proyecto
ms el tiempo que vas a invertir en disear la
solucin.
Tiempo que emplears en codificar el
programa.
Tiempo que emplears para compilar el
programa ms el tiempo que emplears para
probarlo hasta que funcione correctamente y
calcular cunto te tardaste en desarrollarlo.
Postmortem
Implementacin
Calidad y
Liberacin
Compromiso y
Solucin

El proceso de desarrollo de software tradicionalmente se ha descrito por las
actividades marcadas en los modelos de ciclo de vida del software, obtencin de
requisitos, anlisis, diseo, codificacin, pruebas, liberacin y mantenimiento. Sin
embargo, existe otro conjunto de procesos que tambin deben estar presentes
para asegurar el xito en le proyecto de desarrollo de software, muchos de estos
procesos slo tienen sentido cuando se trabaja en equipo. Aqu, describiremos


70
nuestro proceso de desarrollo de software en tres fases, como muestra la grfica.
Esto se hace para simplificar el registro de los datos en este curso introductorio.

Hacer nfasis que la etapa de codificacin implica codifi car toda la solucin del
problema, sin hacer ninguna compilacin o ejecucin del programa. En el
momento en que se compile o ejecute por primera vez el programa (est finalizado
o no), se pasa a la etapa nombrada Calidad y Liberacin.

{
{
{
Queda a tu consideracin realizar o no diseo,
si no haces, inviertes 0 minutos en ello.
Aqu es codificar toda la solucin sin compilar
o ejecutar el programa.
Planeacin
Compilacin
Requerimientos
Diseo
Codificacin
Pruebas
Postmortem
Implementacin
Calidad y
Liberacin
Compromiso y
Solucin

Forma de Registro de Compromisos
Compromisos

Registra tu nombre y la fecha en que inicias la solucin del problema, el nombre
del proyecto y el lenguaje de programacin que utilizars.
En la columna Planeado fila Total, registra el total del tiempo que crees vas a
tardar en desarrollar el programa.
En la columna Actual, registra en cada fila el tiempo que tardaste en cada fase.
En la columna A la fecha, la suma de todos tus tiempos por fase hasta ahora (en
tu primer programa esta columna y la columna Actual tendrn los mismos datos).
En la columna % a la fecha, el porcentaje del tiempo empleado en cada fase
respecto al total.


71
Forma de Registro de Actividades

Utiliza esta forma como si fuera la forma de la bitcora que utilizaste
anteriormente.
Registra el nombre de tu proyecto y tu nombre.
En la columna Actividad registra cada actividad que realices en el desarrollo del
programa.
En la columna Fase, la fase en la cual realizas la actividad.
En la columna Inicio y Fin, la hora en que comienzas y finalizas la actividad.
En la columna Tiempo empleado, el total de tiempo empleado en la actividad.
En la columna Comentarios, cualquier comentario pertinente referente a la
actividad.
En la columna Fecha, la fecha en que realizas la actividad.
Interrupciones
Una interrupcin es cualquier cosa que nos distraiga de la actividad productiva que
estemos realizando. As por ejemplo, supongamos que estamos implementando
una funcin y suena nuestro telfono, el contestar el telfono es una nueva
actividad que nos distrae de la actividad de codificacin.
Debemos registrar las interrupciones para saber en qu hemos estado invirtiendo
el tiempo y cuanto tiempo nos toman las actividades ajenas al desarrollo del
proyecto.
En la forma de registro de actividades, utiliza un rengln por cada actividad
productiva y por cada interrupcin.

Ejemplo de llenado de la Forma de Registro de Actividades

Laura Daniela inicia el desarrollo de su proyecto a las 8:33 AM, finaliza la fase de
compromiso y solucin a las 9:47 AM. A las 9:50 se levanta a tomar un vaso de
agua y regresa a las 10:00 AM para continuar con la implementacin de la
solucin, a las 10:25 suena su telfono, es un cliente preguntndole sobre un
proyecto pasado, cuelga el telfono a las 10:38, contina su trabajo y finaliza la
implementacin a la 1:54 PM.


72
A las 2:00 PM toma su almuerzo y regresa a trabajar a las 2:36. A las 3:30 ha
finalizado la fase de calidad y liberacin.
de Registro de Actividades [2/3]
35 14:35 14:00 Lunch
195 13:54 10:39 I Implementando
altas de usuarios
12 10:38 10:26 I Atendiendo
telfono, cliente X
25 10:25 10 I Implementando
altas de usuarios
9 9:59 9:50 Tomar agua
46 9:47 9:01 CS Diseando
10 9:00 8:50 CS Planeando
16 8:49 8:33 CS Entendiendo el
problema
3/Jul/2004
Comentarios Tiempo
empleado
(minutos)
Fin Inicio Fase Actividad Fecha

4 3:30 3:26 CL Registro de datos
finales
28 3:25 2:57 CL Probando
Mala insercin de datos
por mala definicin de
campos
20 2:56 2:36 CL Compilando 3/Jul/2004
Comentarios Tiempo
empleado
(minutos)
Fin Inicio Fase Actividad Fecha
Laura Daniela emple 72 minutos en la etapa de compromiso y solucin, 320
minutos en la etapa de implementacin y 52 minutos en la etapa de calidad y
liberacin.
En total emple 444 minutos en desarrollar el proyecto.

Ejercicio de Programacin 1

Escribe un programa en el que se proporcione una palabra como entrada y se
determine el nmero posible de palabras a formar. Al igual, lista cada palabra
posible.
Por ejemplo, se da la palabra MAR y es posible formar 5 palabras ms (con esas 3
letras se forman 6 palabras, la que sirve como entrada y las otras 5). Tales
palabras son: MRA, RAM, RMA, AMR y ARM. Cada nueva palabra debe ir en su
propia lnea.
Utiliza la forma de registro de compromisos y de actividades.


73
Orden de Entrega de los Documentos
Forma de Registro de Compromisos.
Forma de Registro de Actividades.
Cdigo Fuente del Programa.
Pantallas de la Interfase Grfica.
Pantallas de los Resultados.

Este es el orden en que debe ser entregada la tarea de programacin.

Fuentes de Referencia Bibliogrfica

Watts Humphrey, Introduction to the Personal Software Process, 1996,
Addison-Wesley Professional.
Watts Humphrey, A Discipline for Software Engineering, 1995, Addison-
Wesley Professional.
Hayes, Will, "The Personal Software Process: An Empirical Study of the
Impact of PSP on Individual Engineers", CMU/SEI-97-TR-001.
Humphrey, W.S., "Using a Defined and Measured Personal Software
Process", May 1996, IEEE Software.
Ferguson, Pat, Watts S. Humphrey, Soheil Khajenoori, Susan Macke,
and Annette Matvya, "Introducing the Personal Software Process: Three
Industry Case Studies," Vol. 30, No. 5, May 1997, IEEE Computer, pp. 24-
31.


74
2. El Tamao del Producto
Introduccin

Una vez entendido lo que hacemos y cuanto tiempo nos toma llevarlo, nos
preocuparemos ahora por mejorar nuestra productividad, es decir, comenzaremos
a entender qu tan productivos somos al desarrollar productos de software. Para
esto introduciremos el concepto de tamao del producto, el cual relacionaremos
con el tiempo que invertimos en desarrollarlo, de tal manera que obtengamos
informacin que nos permita realizar mejores estimaciones cuando aprendamos a
planear nuestro trabajo.

Debido a que la dimensin de los proyectos que estamos atacando queda a nivel
personal, relacionaremos el tamao del producto final a las tres fases que
describimos en la unidad 1, Compromiso y Solucin, Implementacin, y Calidad y
Liberacin. Mediremos nicamente el tamao del cdigo y relacionaremos el
tiempo invertido a las tres fases.

Existen diversas tcnicas para contabilizar (medir) el cdigo, cada una con sus
detractores y promovedores, no existe un consenso sobre qu unidad de medida
utilizar, lo importante es medir, y revisar continuamente nuestros datos histricos
para hacerlos pertinentes a la tecnologa y tipos de proyectos que realicemos.

Objetivo General

Al trmino de esta unidad el alumno ser capaz de:

Describir el concepto de productividad al desarrollar productos de software.


Describir tcnicas para contabilizar el tamao del cdigo.

Describir el concepto de estndar de codificacin y de conteo de cdigo.


75
2.1. Por qu preocuparnos por el tamao del producto?

Existen dos razones principales:
1) Para conocer nuestra productividad.
2) Para poder realizar planes adecuados.
La productividad se refiere a la cantidad de cdigos podemos escribir en una
unidad de tiempo, cdigo que cumpla con su cometido, es decir, que cumpla con
los requerimientos.

Otra de las razones por las que hay que saber manejar el tamao de los productos
es para poder realizar planes adecuados, ya que al conocer el tamao de cada
uno de los diferentes subproductos que componen el producto final nos ser ms
fcil saber el avance real que llevamos.

Hacer recapitulacin sobre el hecho de que en la unidad 1 se comenz a registrar
el tiempo que nos est tomando realizar los proyectos, distinguiendo algunas
fases de desarrollo.

Tambin comentar sobre que conocer de antemano el tamao de los productos
finales servir para que se tomen diversas acciones respecto a por ejemplo, saber
cuantos CDs sern requeridos para distribuir el software (sabiendo el tamao final
del producto), cuanto costar la impresin del manual de usuario (sabiendo el
nmero de pginas que contendr, etc.).
2.1.1. Tamao del Producto

En el desarrollo de un proyecto generamos diversos productos:
Requerimientos.
Diseo.
Cdigo.
Casos de Prueba.
Manuales de Usuario.


76
Al iniciar cualquiera de estos u otros productos, sabemos de qu tamao
resultar el esfuerzo para crearlos?

Aqu es importante anali zar el concepto de esfuerzo, el cual est definido por la
cantidad de trabajo a realizar por unidad de tiempo. Esta cantidad de trabajo es lo
inicialmente llamaremos el tamao del producto.

El tamao del Producto en la Planeacin

El proceso de planeacin comienza con la estimacin del tamao del trabajo a
realizar, de esta manera se descubre la cantidad de trabajo que se requiere. Para
poder estimar el tamao, se requiere de un mecanismo consistente y repetible.

Se est amplificando la justificacin de medir el tamao del producto para realizar
mejores planes. El decir estimar, significa que debemos de saber con anterioridad
a la creacin de los productos cul va es su tamao, adems de que esta
prediccin se debe realizar de una manera sistemtica.

El Estimar el Tamao del Proyecto es el Primer Paso para la Planeacin.

Qu unidades de medida debemos usar?

Los indicadores deben ser:
tiles para la planeacin.
Precisos.
Factibles de ser automatizados.
Dentro de un proyecto se pueden medir nicamente 3 cosas: Los Procesos, Los
Productos y Los Recursos.

A cada uno de estos se les puede medir: El Tamao, El Tiempo, El Costo, La
Calidad y Los Recursos Crticos.

La dificultad radica en saber cmo, qu unidad de medida especfica debemos
utilizar para cada proceso, producto y recurso en particular.

Uno de los puntos principales a tomar en cuenta cuando selecciones qu unidad
de medida utilizar es que esta medida de tamao debe estar directamente
relacionada al costo de desarrollo.


77
Se debe dejar en claro que el motivo por el cual nos preocupa este punto es que a
travs del tamao podremos estimar el tiempo en que desarrollaremos el
producto, de esta manera, tambin obtendremos el costo del mismo.

Una vez seleccionada una unidad de medida precisa, se requieren medios
automticos, econmicos y exactos para obtenerla.

Ejemplo

Consideremos un ejemplo sencillo:
Tarea: Leer 6 ejemplares de El mundo del Ftbol
Al finalizar esta tarea hemos recolectado los siguientes datos
Ejemplar Tiempo de
lectura
Pginas Minutos/pgina
1 50 25 2
2 30 18 1.66
3 45 22 2.04
4 124 80 1.55
5 77 37 2.08
6 40 22 1.81
Total 366 204
Promedio 61 34 1.79

Si el nuevo ejemplar consta de 33 pginas, cunto tiempo te tomar leerlo?

Hacer notar las variaciones que existen entre la cantidad de pginas ledas y el
tiempo que toma leer el total de cada ejemplar.

El profesor debe iniciar un intercambio de ideas preguntndoles a los alumnos el
porqu consideran que se dan estas variaciones.


78
Precauciones

El tamao por s slo no es un indicador adecuado. La complejidad del trabajo
tambin es importante.
Quiz las variaciones se hayan debido a:
Tipo de informacin.
Presentacin de la informacin.
Etc.
El profesor aqu al explicar diversos ejemplos de complejidades ajenas al software,
debe finalizar haciendo la pregunta: Qu consideran que puede ser complejo en
la construccin de los proyectos de software?, y especficamente en la
codificacin?

2.1.1.1. Tamao y Esfuerzo

Encontrar el indicador adecuado para el tamao y el esfuerzo es complicado.
Debemos de describir la forma de conteo del tamao del producto para que sea:
Fcil de comunicar.- Si al utilizar el mismo mtodo, podrn otros
saber precisamente qu ha sido medido, incluido y excluido?
Repetible.- Podr alguien repetir la medicin y obtener el mismo
resultado?

2.1.1.2. Tamao del Cdigo

En este curso, nos preocuparemos nicamente por el tamao del cdigo.
Hay muchas posibles unidades de medida:
Lneas de cdigo (LOC).
Puntos Funcionales.


79
Pginas, pantallas, scripts, reportes, etc.
Uno pudiera pensar que tomar el programa final como unidad de medida pudiera
ser suficiente, sin embargo, esto sera una unidad de medida demasiada grande.

Para poder realizar una mejor planeacin hace falta descomponer los programas
en algo ms sencillo, ms pequeo, que permita estimaciones ms exactas y
poder tener un mejor control durante el seguimiento de los proyectos.

Un enfoque tpico para medir el tamao del cdigo son las LOC.
Hay que tener cuidado al utilizarlas, ya que su medicin puede variar por
diferentes motivos:
Complejidad del programa.
Experiencia del Ingeniero de Software.
Lenguaje de programacin.
Estndares utilizados en la codificacin.
Aqu el profesor puede iniciar una reflexin pidiendo a los alumnos que registren
en algn lugar la cantidad de cdigo que creen han escrito a lo largo de sus vidas.

Las LOC no son adecuadas en todos los casos, por ejemplo, no son adecuadas
para:
Mens.
Reportes.
Pantallas.
Documentos.
2.1.1.2.1. Tipos de cdigo

Existen diversos tipos de cdigo:
Cdigo de pruebas.
Cdigo de apoyo.


80
Cdigo del producto.
Cdigo generado automticamente.
Cada uno de ellos debe ser contabilizado por separado.
Un punto importante es que las el cdigo generado automticamente no debe ser
contabilizado como parte de la productividad, pero s como parte del tamao total
del producto. El cdigo generado automticamente es aquel que es traducido del
diseo o la especificacin por alguna herramienta CASE.

El decir que sea contabilizado por separado significa que se debe mantener un
registro del tamao del cdigo por cada uno de los tipos mencionados.

El cdigo de pruebas es aquel que escribimos cuando dentro del programa que
estamos desarrollando incluimos cdigo que servir para probarlo, generalmente
este cdigo es borrado o comentado antes de liberar el programa.

Cuando el programa que estamos desarrollando tiene que interactuar con otros
mdulos que no existen, entonces creamos un prototipo de estos mdulos, el
cdigo de estos prototipos es lo que llamamos cdigo de apoyo.

2.1.1.2.2. Formas de Contar el Cdigo

Existen dos formas en que podemos contabilizar el cdigo:
Por lneas fsicas.
Por lneas lgicas.
El conteo por lneas fsicas es aquel en donde cada lnea (finalizada por un retorno
de carro) es contabili zada.

Las lneas lgicas son aquellas que representan un agrupamiento lgico de lneas,
que en su conjunto tienen un significado.

Ejemplos de Lneas Fsicas

1)
if A < B then
C:= C + 1


81
else
C:= C 1
4 LOC

2)
if A < B then C:= C + 1
else C:= C 1
2 LOC

Cada una de las lneas terminadas por un retorno de carro es contabilizada. Hacer
hincapi sobre el hecho de la forma en que se escribe el cdigo, lo cual puede
afectar la productividad. Suponiendo que se tard 4 minutos en escribir el cdigo,
se tendra una productividad par el primer caso de 4 LOC/4 min = 1 LOC/min; en el
otro caso 2 LOC/4 min = .5 LOC/min

Aqu el punto es ser consistente en la forma en que escribamos nuestro cdigo

Ejemplos de Lneas Lgicas

1)
if A < B then
C:= C + 1
else
C:= C 1
1 LOC

2)
for i:= 0 to z
i:= i * 2
if i > 20 and i < 30 then
z:= 2


82
else if i > 30 and i < 40 then
z:= 3
else
z:= 4
2 LOC

Las lneas lgicas son aquellas que representan un agrupamiento lgico de lneas,
que en su conjunto tienen un significado.

Cmo agrupar estas lneas en una estructura lgica es algo que cada uno debe
definir y ser constante en contar estas estructuras de la misma manera.

2.1.1.2.2.1. Lneas Lgicas Vs. Lneas Fsicas

Lneas Lgicas
Invariable a los cambios de edicin.
Definicin nica.
Compleja de contar.
Lneas Fsicas
Fcil de contar.
Variable.
No existe una definicin nica.
Para las lneas lgicas.- invariable a los cambios de edicin significa que no
importa si se le agrega y quita cdigo, siempre representar una estructura (una
nica LOC) a contar. Definicin nica, que una vez definida qu es y cmo es una
estructura se mantendr as. Compleja de contar, no es tan sencilla su
automatizacin y hay que tener cuidado para realmente dimensionar durante el
conteo el alcance de la estructura definida.


83
Para las lneas fsicas.- es sencilla la automatizacin del conteo, variable y que
no existe una nica definicin significa que la manera en que se escribe el cdigo,
como en ejemplo, podra dar resultados variables.

Lneas Fsicas

En este curso tomaremos como estndar a utilizar para medir el tamao de los
programas las lneas fsicas.

No debemos contar los espacios en blanco, ni los comentarios.
Si en una lnea hay cdigo y comentarios, s debe ser contada.

if a < z then a:= 1; // a debe ser impar.

La LOC anterior se cuenta como una.
Para ser constantes en nuestra forma de escribir y contar nuestro cdigo debemos
de seguir algn estndar:
Para escribir: estndar de codificacin.
Para contar: estndar de conteo.
El profesor debe proporcionar ejemplos de lo que es un estndar de codificacin y
un estndar de conteo. Ayudarse de los ejemplos anexos.

El estndar de codificacin especifica el cmo debe el Ingeniero de Software
escribir su cdigo, describiendo por ejemplo, si va a utilizar encabezado en cada
mdulo de los programas, qu contendr este encabezado. Cmo va a escribir las
declaraciones de variables, si las variables debern tener nombres significativos,
si cada variable estar en una sola lnea o se pueden poner varias variables en
una sola, la manera de indentar el texto, si las constantes sern escritas solo en
maysculas, etc.

Un ejercicio de investigacin adecuado para este ejercicio es el encontrar el
estndar de codificacin propuesto por la compaa que desarroll el lenguaje de
programacin o compilador que est utilizando cada alumno.


84
En Resumen

Medimos para poder realizar estimaciones y tomar decisiones sobre la
evolucin de nuestros proyectos.
Estimar el esfuerzo para escribir un programa es ms complejo que estimar el
tiempo para leer una revista.
No hay mtodos que garanticen una estimacin exacta de los programas.
La clave para realizar estimaciones exactas es:
Realizar muchas estimaciones y comparar contra la realidad.
Ejercicios

1) Definir:
Tu estndar de codificacin.
Tu estndar de conteo.
Ejercicio de Programacin

2) Escribe un programa para contar las lneas fsicas de tus programas. No debes
contar las lneas en blanco ni los comentarios.

Cuenta manualmente las lneas de cdigo de tus programas 1 y 2 y compralos
con el resultado de tu programa 2.

Los alumnos debern reportar el resultado de sus pruebas, el profesor debe
indicar el formato de reporte de pruebas y asegurarse que este formato sea
seguido.

Orden de entrega de los documentos

Estndar de Codificacin.
Estndar de Conteo.


85

Forma de Registro de Compromisos Unidad 2

Nombre: ___________________________________Fecha: _______________
Proyecto:_______________________________________________________
Lenguaje de programacin: _________________

A continuacin se muestra un ejemplo de cmo se debe llenar la Plantilla de
Estndar de Conteo de LOC.

Tamao del Progama (LOC) Planeado Actual A la fecha
Total de LOC fsicas

Tiempo en Fase (min.) Planeado Actual A la fecha % a la fecha
Compromiso y Solucin
Implementacin

Calidad y Liberacin
Total

Productividad

Total de
LOC fsicas /
Total tiempo

Total de LOC
fsicas / Total
tiempo


86
Plantilla de Estndar de Conteo de LOC

Nombre: Estndar de codificacin para curso de programacin Lenguaje: Delphi
Autor: Carlos Mojica Fecha: 16/Sep/2001

Tipo Comentarios Tipo de conteo
Fsico/Lgico Fsico
Tipo de Sentencia Incluir Comentarios

Ejecutables S
No ejecutables:
Declaraciones S
Directivas del
compilador
S
Comentarios
En su propia lnea S
Con cdigo S
Banners S
Todos los comentarios se contarn por
separado de las LOC.
Lneas en blanco No
Aclaraciones
Nulos S
Sentencias vacas S
Instanciaciones genricas S Cada instanciacin deber estar en una
lnea
Begin...End No
Begin...End No
Pbas de condicin S
Evaluacin de
expresiones
Como una lnea si viene despus de un if,
else, elseif, case
Smbolos End No
Smbolos End No
Then, else, otherwise S Como una lnea si viene despus de un if,
else, elseif, case
Elseif S Como una lnea si viene despus de un if,
else, elseif, case
Palabras reservadas No
Etiquetas No No se utilizarn etiquetas


87

3. La Planeacin del Producto
Introduccin

Una vez que hemos aprendido a medir nuestra productividad al desarrollar
software y la hemos entendido, aprenderemos algunos mtodos de estimacin del
tamao del producto y el esfuerzo necesario para desarrollarlo. Se estudiarn las
tcnicas de estimacin Wideband-Delphi, por Analoga y de PERT al igual que la
media de la productividad para estimar el tamao y el esfuerzo respectivamente.

Las tcnicas sern descritas en trminos de su uso y no se discutir sobre los
antecedentes tericos estadsticos de su fundamentacin. Para un tratamiento
estadstico completo se recomienda acudir a los diversos textos al respecto. En el
libro A Discipline for Software Engineering, existen captulos y apndices que dan
algunos antecedentes estadsticos al respecto de las tcnicas.
Objetivo General


Describir tcnicas para estimar el tamao y esfuerzo en proyectos de
desarrollo de software.


Definir y aplicar tcnicas de estimacin del tamao del cdigo.

Definir y aplicar tcnicas de estimacin del esfuerzo de desarrollo de
proyectos de software.


88
3.1. Estimacin del Tamao

El requisito esencial para realizar cualquier plan es la habilidad para estimar el
proyecto:
Su tamao, respecto a un indicador.
Recursos necesarios (tiempo, personas, materiales, etc.).
Nota: La estimacin del tamao es lo primero.
El orden de estimacin en un proyecto grande es: Tamao, Tiempo (Esfuerzo),
Calidad, Costos, Recursos, Riesgos. Para proyectos a nivel personal en este
curso nos concentraremos en estimar el tamao y el tiempo.

Un programa tiene diferentes componentes:
Mens.
Pantallas.
Reportes.
Archivos.
Funciones:
Sencillas o complejas.
De texto, matemticas.
Lgicas, de entrada/salida, etc.
De ahora en adelante debemos encontrar cules son las partes que compondrn a
nuestros programas, es decir, qu componentes tenemos que construir para
satisfacer los requerimientos. El trabajo de encontrar estos componentes es parte
de lo que se conoce como diseo conceptual y entra en la fase que hemos
definido como Compromiso y Solucin.

Para estimar el total del tamao de un programa:
Estimar el tamao de cada componente.
Sumar las estimaciones de los componentes.


89
Si la estimacin no te parece lgica, realiza el ajuste necesario.
Las estimaciones no son una ciencia exacta, a pesar de que existen diversos
mtodos para estimar todos dependen de datos histricos, al final todos estos
mtodos envuelven algn tipo de juicio de experto, lo cual depende de la
experiencia. Este juicio ser mucho mejor si est basado en datos histricos ms
que en una adivinanza.

Ejemplo 1

Programa Componente Tiempo LOC fsicas
1 Login/Password 45 24
2 Regresin lineal
simple
322 134
3 Bsqueda parecida 123 78
4 Validacin IVA 12 22
5 Ordenamiento de
enteros
66 43

Aqu se muestra un ejemplo de registro de componentes con su tiempo de
desarrollo y las lneas de cdigo fsicas que contienen. Es momento oportuno para
sealar a los estudiantes que es importante que en la forma de registro de
actividades se anote el desarrollo de cada componente.


90
Ejemplo 2

Programa Componente Tipo Tiempo LOC
fsicas
1 Login/Password Entrada/
Salida
45 24
2 Regresin lineal
simple
Matemtica 322 134
3 Bsqueda parecida Texto 123 78
4 Validacin IVA Lgica 12 22
5 Ordenamiento de
enteros
Datos 66 43

En este ejemplo se ha aadido la columna de tipo con la cual se clasifica a cada
uno de los componentes, de esta manera ser ms fcil ubicar un componente
que estemos buscando.
3.2. Mtodos de Estimacin

Ya que el objetivo principal de la estimacin del tamao es tener estimaciones
exactas para hacer mejores planes, debes experimentar con varios mtodos de
estimacin y usar el que mejor te ajuste.
Wideband-Delphi.
Por analoga.
PERT.
Existen diversos mtodos para estimar el tamao, pasando de slo usar la
experiencia hasta aquellos que utilizan tcnicas estadsticas paramtricas. Un
buen ejercicio para los alumnos es el asignarles que investiguen y presenten
alguna otra tcnica de estimacin aparte de las mostradas.


91
3.2.1 Wideband-Delphi

Es una tcnica basada en juicio de experto. Se le pide a varias personas por
separado realicen la estimacin y se la proveen a un coordinador.

El coordinador calcula el promedio de la estimacin. Registra el promedio y las
estimaciones de los expertos en una forma.

Si el coordinador juzga que no es lgico el resultado, realiza una nueva ronda
proveyendo los resultados.

Ejemplos

1) Se les pide a 3 personas realizar sus estimaciones sobre un producto.
a) Las estimaciones iniciales son:
A = 13,800 LOC
B = 15,700 LOC
C = 21,000 LOC
b) Luego, el coordinador:
Calcula el promedio, 16,833 LOC
Proporciona a cada persona este promedio y las otras estimaciones sin
decir de quien es cual.
c) Las personas que realizaron las estimaciones se renen y discuten las
estimaciones.

d) Sus segundas estimaciones son:
A = 18,500 LOC
B = 19,500 LOC
C = 20,000 LOC


92
e) Luego, el coordinador:
Calcula el promedio, 19,333 LOC
Pregunta a los que realizaron las estimaciones si estn de acuerdo con esta
estimacin
Ventajas:
Puede producir resultados muy precisos.
Se usan habilidades de la organizacin.
Trabaja para cualquier tamao de producto.
Desventajas:

Recae sobre pocos expertos.
Consume tiempo.
Est sujeta a percepciones personales.

Esta es la manera en que el coordinador proporciona la informacin a los expertos
para que realicen una nueva estimacin.

3.2.2 Estimacin por analoga

Tambin est basada en la experiencia, es decir, la utilizacin de datos histricos.
Una vez encontrados los componentes del programa, se busca en la base de
datos por un componente similar.

Si se encuentra alguno similar tomar el tamao del componente encontrado como
una base para la estimacin.

40 20 60 80
X X1 X2 avg
40 20 60 80
X X1 X2 avg


93
Cada vez que se mencione la experiencia, hacer hincapi de lo importante que es
contar con una base de datos histrica de mediciones. Un ejercicio oportuno en
este momento es que los estudiantes revisen sus dos programas anteriores y
registren cada componente en la Forma de Registro de Tamaos.

Supongamos que necesitamos realizar un componente que orden nmeros
flotantes, si buscamos en la base de datos histricas podremos encontrar que
tenemos uno que ordena nmeros enteros, 43 LOC.

Utilizando t juicio puede ajustar estas LOC a que sean ms o menos o quizs la
utilices como base combinndola con la tcnica Wideband-Delphi.

3.2.3 PERT

Esta tcnica tambin tiene sus fundamentos en tcnicas estadsticas. Est basada
en tomar 3 valores:
El valor mnimo esperado.
El valor ms probable.
El valor mximo esperado.
y aplicar una frmula.
Otro ejercicio interesante, dependiendo del nivel de estudios, es el dejar un trabajo
de investigacin y exponer los fundamentos tericos de PERT.

a = Valor Inferior
b = El valor esperado
c = Valor Superior

E = a + 4b + c
6
Los valores a, b y c pueden ser obtenidos utilizando la tcnica de Wideband-
Delphi o la tcnica por analoga.


94

Ejemplo:

Valor mnimo pensado = 87
Valor ms probable = 95
Valor mximo pensado = 120
E = (87 + 4*95 + 120)/6= 97.83 = 98 LOC

Para determinar cunto tiempo nos puede tomar el desarrollar nuestro proyecto,
podemos acudir a la tcnica de analoga, una vez que hemos estimado el tamao
total del proyecto podemos buscar en nuestra base de datos histrica de
estimaciones.

Tambin podemos recurrir a utilizar una tcnica estadstica utilizando nuestros
datos histricos de productividad.

Tiempo estimado = LOC estimadas del proyecto
Media de la Productividad

Media de la = Total de LOC de todos los proyectos realizados
Productividad Total del tiempo empleado en los proyectos realizados

No es la mejor aproximacin pero s da un mejor reflejo que si slo utilizramos
analoga y mejor an que si adivinramos, para un mejor detalle de las tcnicas
estadsticas referirse al libro A discipline for Software Engineering.

La informacin necesaria se toma de la Forma de Registro de Compromisos.

Ejemplo de estimacin del esfuerzo

Tomando los datos del ejemplo de la Forma de Registro de Tamaos tenemos:
LOC totales a la fecha = 301
Minutos totales a la fecha = 568


95
Media de la productividad = 301 = 0.53
568
Tiempo estimado = 98 = 184.9 = 185 minutos
0.53

3.3. Distribucin del Tiempo en las Fases

Una vez estimado el tiempo total de desarrollo, debes usar este dato y el
porcentaje a la fecha de los tiempos empleados en cada fase para distribuirlo en
tus nuevas estimaciones.

Ejemplo:

Has estimado que tardars 185 minutos en desarrollar el nuevo programa y tienes
en tu forma de Registro de Compromisos los siguientes datos:

Fase % a la fecha
Compromiso y Solucin 25
Implementacin 60
Calidad y Liberacin 15

En tu nuevo programa tendrs durante la planeacin:
Fase Planeado
Compromiso y Solucin 46
Implementacin 111
Calidad y Liberacin 28

Ejercicio de Programacin

Desarrollar un programa para contar el nmero de LOC fsicas de cada funcin y
procedimiento de un programa en particular. Este mismo programa debe arrojar el


96
total de LOC del mismo. Utiliza tu estndar de conteo y codificacin para construir
la solucin.

Estndar de Codificacin.
Estndar de Conteo.
Nota: El orden de entrega de la documentacin es importante, si no se cumple,
disminuir puntos de la calificacin.


Nombre:_____________________________________ Fecha: _______________
Proyecto:_______________________________________________________

Total de LOC fsicas

Implementacin

Calidad y Liberacin
Total

Productividad

Total de
LOC fsicas /
Total tiempo

Total de LOC
fsicas / Total
tiempo


97

Forma de Registro de Tamaos

Nombre:___________________________________Fecha: ______________



98
4. La Agenda de Trabajo

Introduccin

Ya que hemos calculado el esfuerzo que vamos a necesitar para desarrollar
nuestros productos de software, procede el distribuir esta cantidad de esfuerzo en
el tiempo. Por ejemplo, si ya hemos estimado que requeriremos de 18 horas para
finalizar nuestro trabajo, quiere decir que trabajaremos 18 horas seguidas? o
quiz podamos trabajar 3 horas diarias durante 6 das. Cmo distribuir el esfuerzo
del trabajo en el tiempo que tengamos disponible es tema de esta unidad, es decir,
aprenderemos a planear nuestro trabajo.

Si hemos realizado un plan es porque lo vamos a seguir, sino, qu caso tiene
planear? Sin embargo, an falta poder controlarlo, es decir, cmo podemos estar
seguros que a medida que transcurre el tiempo estamos alcanzando nuestros
objetivos en el tiempo fijado? En este tema, se presentar la tcnica de valor
devengado, la cual nos servir para poder saber cual es el porcentaje de avance
real que lleva nuestro proyecto, ms an, poder saber cunto ms tiempo
requeriremos para finalizar nuestro trabajo.
Objetivo General


Planear el proyecto y darle seguimiento para poder asumir y cumplir los
compromisos adquiridos.


Describir tcnicas para planear pequeos proyectos, proyectos a nivel
personal.

Describir tcnicas para darle seguimiento a proyectos a nivel personal.


99
4.1. Por qu es importante planear?

Antes de comprometernos a realizar un trabajo debemos estar seguros de:
El propsito del compromiso.
Las tareas que tienen que ser realizadas y cmo sern manejadas.
El esfuerzo requerido para cumplir.
No podemos adquirir un compromiso sin conocer el alcance del mismo,
refirindonos a compromiso a la realizacin de un proyecto en tiempo, costo y
calidad. Por ello es que necesitamos descomponer en tareas manejables el
problema a solucionar de tal forma que podamos dimensionar la cantidad de
esfuerzo requerido para finalizar con xito La planeacin es el primer paso dentro
de cualquier proceso, y aqu estamos hablando del proceso de desarrollo de
software.

Por qu son necesarios los planes?

1) Proveen una base de negocio para realizar el trabajo:
Estableciendo el precio.
Definiendo la agenda.
Acordando el trabajo.
2) Establecen un marco de trabajo para la administracin:
Definiendo los compromisos.
Ayudando a coordinar el trabajo.
Permitiendo el seguimiento del estado del proyecto.
Debido a que en los planes se encuentran detalladas todas y cada una de las
tareas en trminos de alcance, responsables, tiempo de inicio y finalizacin,
podemos establecer el costo. De esta manera quedan establecidos los
compromisos por parte de los ejecutores.


100
En la ejecucin del proyecto, los planes sirven para dar seguimiento al
cumplimiento de los compromisos y poder coordinar el trabajo que debe ser
ejecutado para cumplirlos.

No hay planeacin perfecta

La planeacin es una habilidad que se desarrolla.
An los planes ms simples estn sujetos a errores.
Eventos no previstos.
Complicaciones inesperadas.
Errores en la planeacin.
La mejor estrategia es planear a detalle:
Identificar las tareas.
Estimar basndose en experiencias similares.
Hacer un buen juicio con lo dems.
La planeacin es un juego de adivinar el futuro y adelantarse a los problemas que
puedan presentarse. La cantidad y calidad de la informacin que tengamos al
momento de planear es decisiva para determinar que tan bueno o malo ser el
plan, a menor informacin existe mayor riesgo de un plan imperfecto. Qu tanto y
cunto planear? son las interrogantes a responder, a nivel personal, el nivel al que
est orientado este curso, es conveniente detallar lo ms posible el conjunto de
tareas que como Ingenieros de Software vamos a realizar.

Alguien, de alguna manera, ya ha descompuesto el problema total y nos ha dado
el pedazo de problema que tenemos que desarrollar, a este nivel van enfocadas
las tcnicas descritas en este captulo.

Como ejemplos de eventos no previstos pudiramos pensar en desastres
naturales como temblores, huracanes, apagones, enfermedades. Sobre las
complicaciones algo que se pens era sencillo resulto ms complejo, por lo que se
previ menos tiempo dando pie a errores en la planeacin.


101
4.1.1. Qu tomamos en cuenta para planear?

Bsicamente pensamos en dos cosas:
El producto a construir.
El tiempo en que debe/ser construido.
El producto debe ser descompuesto en sus subproductos, en tareas y servicios
necesarios para su construccin. Una vez obtenida esta lista de productos y
servicios, es necesario encontrar las dependencias de construccin entre ellos, es
decir, qu se debe hacer primero, qu despus y as sucesivamente.

Ya qu sabemos qu se tiene que hacer y en qu orden y habiendo establecido el
tiempo necesario para desarrollar las tareas y servicios queda la tarea de
establecer en qu lapso de tiempo sern desarrollados, es decir, la manera en que
pensamos vamos a invertir nuestro tiempo, acabar en un da, una semana, un
mes, un ao, etc.

4.1.2. Pasos para Planear

1) Tener una definicin clara del producto a construir en trminos de:
1.1) Caractersticas del producto.
1.2) Tamao de cada caracterstica.
1.3) Tiempo requerido para cada caracterstica.
1.4) Tiempo disponible para trabajar en el desarrollo.


102

Forma de Registro de Tamaos

Nombre:_____________________________________ Fecha: _______________

2) Preparar el plan.
Los requisitos del producto a construir son esenciales pues ellos delimitan el
alcance del producto, aunque hay que tomar en cuenta algunas otras cosas como
restricciones de equipo u otro material que se vaya a utilizar. A partir de estos
requisitos encontramos los componentes que formarn parte del producto y les
estimamos su tamao y el tiempo de desarrollo. Con esta informacin estamos
preparados para documentar el plan al comenzar a generar la agenda de trabajo.

4.2. Estimacin de la Agenda

Para realizar la agenda se necesitan 3 cosas:
1) La estimacin de las horas directas del proyecto.
2) Un calendario de las horas directas disponibles.
3) El orden en que las tareas sern realizadas.
Luego se necesitan realizar:
1) Las estimaciones del tiempo necesario para cada tarea.
2) Acomodar este tiempo a lo largo del calendario.
La agenda de trabajo describe todas las actividades a realizarse y el momento en
que deben iniciar y terminar, es decir, l as fechas de inicio y finalizacin. Para
crearla debimos ya haber estimado el esfuerzo requerido para el proyecto.

El calendario de las horas directas disponibles se refiere a que debemos saber
cules son los momentos, perodos de tiempo, que tenemos disponibles para


103
llevar a cabo la ejecucin de las tareas. Quiz el proyecto que vamos a desarrollar
no sea la nica actividad que tengamos.

Con la informacin anterior ya estamos en posicin de poder distribuir el esfuerzo
requerido por cada tarea en los espacios de tiempo que tengamos disponibles.

Ejemplo de una grfica de Gantt

Lo ms representativo para describir una agenda es la grfica de Gantt, en la cual
barras describen el esfuerzo requerido por las tareas y el inicio de la barra
comienza en el momento en que debe iniciar la tarea y finaliza, la barra, tambin
correspondiendo con la finalizacin planeada de la tarea. En este curso no
generaremos grficas de Gantt (el nombre viene por la persona que desarroll por
primera vez este tipo de grfica), pero con la informacin que manejaremos
podemos construirla sin dificultad.

Horas disponibles directas

Producir un calendario con el tiempo disponible.


104
52 semanas en un ao con 40 horas de trabajo por semana = 2080 horas.
Con 3 semanas de vacaciones y 10 das de asueto; un ao = 1880 horas
(90%).
Con 10% para reuniones, 55 hrs. para correo-e; un ao de trabajo
representa entre 1000 a 1400 horas (50 a 65%).
Aqu un ejercicio de reflexin es pedirles a los alumnos revisen su Forma de
Registro de Actividades y calculen cunto tiempo realmente trabajan a la semana,
al mes, al ao.

Horas disponibles directas

El saber cules son los momentos que tenemos disponibles es importante, ya que
en ellos podremos asignar esfuerzo para realizar las tareas del proyecto que
estamos planeando.

El orden de las tareas

El orden de las tareas debe estar dictado por la estrategia de desarrollo.
Cada tarea necesita un criterio de finalizacin.
Se deben considerar las dependencias entre las tareas.
2
0
2
1
0
9
D
S
V
J
M
M
L
2
4
2
3
2
2
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
1
1
1
0
0
8
0
7
0
6
0
5
0
4
0
3
0
2
0
1
0
0
2
0
2
1
0
9
D
S
V
J
M
M
L
2
4
2
3
2
2
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
1
1
1
0
0
8
0
7
0
6
0
5
0
4
0
3
0
2
0
1
0
0
No laborables
Disponibles
Ocupadas
No laborables
Disponibles
Ocupadas


105
Tambin considerar los costos y las prioridades de tiempo o de cualquier
otra ndole.
Determinar el orden de las tareas planeadas.
El orden de las tareas pudiera cambiar a medida que avanza el proyecto.
Realizar un bosquejo o mejor, un diseo conceptual, de la solucin del problema
nos ayuda a encontrar las dependencias existentes entre las diversas tareas, es
decir, qu se tiene que hacer primero. Muchas veces, por diversas cuestiones
como por ejemplo requerimientos del usuario, pudiramos cambiar el orden inicial
que le dimos a la consecucin de las tareas. Sin embargo, debemos de tener
cuidado en no poner por delante tareas que dependen de otras an sean
exigencias del cliente.

Ya que hemos quedado que planear es predecir, y al estar construyendo la
agenda estamos prediciendo la mejor manera en que debemos construir el
producto, a medida que avanza el proyecto adquirimos nuevo conocimiento o
simplemente las prioridades cambian, por lo que la re-planeacin ser algo
comn.


106

5. Seguimiento de la Agenda de Trabajo

Habr algo inusual que afecte al proyecto?
Distribuir el tiempo de las tareas sobre el calendario.
Identificar los hitos principales del proyecto.
Usar un formato estndar.
Generalmente un error que cometemos al planear es pensar que todo va a salir
bien, pero la realidad es otra. Hay que pensar en qu cosas pueden salir mal y
tenerlas contempladas al momento de realizar y revisar las estimaciones, ms
cuando estamos distribuyendo las tareas en el tiempo.

El asignar hitos, el identificar cosas, personas o hechos claves en el proyecto nos
permitir dar un mejor seguimiento al proyecto. Los hitos no tienen duracin, son
puntos en el tiempo que nos permitirn saber si hemos alcanzado o no logros a lo
largo del proyecto para poder tomar decisiones de si seguir o no con la realizacin
del proyecto, de si debemos o no cambiar la estrategia que estamos siguiendo.

La estandarizacin en el manejo de la agenda nos permitir ser consistente en el
registro y anlisis de la informacin a travs del tiempo, a travs de diferentes
proyectos.
Plantilla de planeacin de tareas

Id Nombre
Plantilla de Planeacin de Tareas
Fecha:_____________________________
Tarea Plan Actual
Nombre:_________________________________________________________________________
Proyecto:________________________________________________________________________
Minutos
Valor
planeado
Minutos
acumulados
Valor planeado
acumulado
Fecha Fecha
Valor
ganado
Valor ganado
acumulado


107
Para comenzar a llenar esta plantilla:
1) Listar las tareas en el orden respectivo de finalizacin.
2) Registrar los minutos que se espera tome cada tarea.
3) Aadir los minutos en la columna de minutos acumulados.
En este punto, comenzar a preparar la plantilla de planeacin de la agenda.
Se tiene que explicar la utilizacin de las plantillas, Plantilla de Planeacin de
Tareas y la Plantilla de Planeacin de la Agenda.

En esta pri mera lmina se describe el uso de la Plantilla de Planeacin de Tareas.
En la columna Id se pone un nmero entero nico con el cual hacer referencia a
las tareas y bajo la columna Nombre se listan las tareas en el orden en que se
piensan completar. Recordar que en cada tarea listada debe quedar explcito su
criterio de finalizacin, un truco sencillo es por ejemplo mencionar la finalizacin
del producto o accin: Planeacin finalizada, programa compilado, defectos
corregidos, prueba finalizada.

Una vez llenada esta lista (en trminos de planeacin se le conoce como
estructura de descomposicin de trabajo), se asigna el tiempo de desarrollo, bajo
la columna Minutos.
Ejemplo de Planeacin de la Agenda

Usando la plantilla de planeacin de tareas, comenzar con el desglose de las
tareas y el tiempo estimado para cada una de ellas.

I
H
G
F
E
D
C
B
A
Nombre tarea
37 2 9
35 3 8
32 6 7
26 5 6
21 3 5
18 7 4
11 4 3
7 5 2
2 2 1
Horas acumuladas Horas Id tarea
I
H
G
F
E
D
C
B
A
Nombre tarea
37 2 9
35 3 8
32 6 7
26 5 6
21 3 5
18 7 4
11 4 3
7 5 2
2 2 1
Horas acumuladas Horas Id tarea


108
08/11/2004 Tcnica Personal de Calidad en Programacin
CarlosMojica
16
Plantilla de planeacin
de la agenda
+ Ver formato.
+ Para comenzar a llenar esta plantilla.
- Listar las fechas del calendario en la columna izquierda.
- Usar das o semanas, dependiendo de la escala del
proyecto.
* Para das, listar cada fecha.
* Para semanas, usar un da estndar, digamos
lunes.
- Listar los minutos planeados a invertir en el proyecto
para esa semana.
- Completar la columna de minutos acumulados.
+ Completar las plantillas de tareas y agenda en forma
simultanea.


Usando la plantilla de planeacin de la agenda, estimar los minutos a emplear en
el proyecto.

La columna Nmero de da es un consecutivo para saber el total de das que
trabajaremos en el proyecto, la columna Fecha denota eso, la fecha en la cual
trabajaremos en el proyecto, las Horas directas es el total del tiempo que
pensamos invertir en el proyecto en la Fecha dada, y finalmente la columna de
Horas acumuladas, es la suma acumulada del tiempo distribuido en el perodo del
proyecto que pensamos invertirle. As para el 3 de julio pensamos invertir
nicamente 3 horas al proyecto, el da 4, 5 y 10 de julio invertiremos en cada uno
5 horas al proyecto.
14/jul
13/jul
12/jul
11/jul
10/jul
05/jul
04/jul
03/jul
Fecha
38 5 8
33 5 7
28 6 6
22 4 5
18 5 4
13 5 3
8 5 2
3 3 1
Horas acumuladas Horas directas Nmero de
da
14/jul
13/jul
12/jul
11/jul
10/jul
05/jul
04/jul
03/jul
Fecha
38 5 8
33 5 7
28 6 6
22 4 5
18 5 4
13 5 3
8 5 2
3 3 1
Horas acumuladas Horas directas Nmero de
da


109

En una lmina anterior estimamos que el proyecto va a durar 37 horas (la suma
del tiempo de las 9 tareas que se estn planeando), en la agenda hemos
reservado en nuestro calendario 38 horas para el proyecto.

5.1. Completando el Plan

Para cada tarea:
Encontrar las horas acumuladas para completar esa tarea en la plantilla de
tareas.
Encontrar la semana en la plantilla de la agenda cuando esas horas se han
excedido por primera vez.
Registrar la fecha de la semana en la columna de fecha para esa tarea en
la plantilla de tareas.
Ahora se tiene ya la agenda de las tareas.


Registrar la agenda de la tarea: el da en el cual las horas acumuladas para cada
tarea ser alcanzada.

Regresando a la Plantilla de Planeacin de Tareas, en la columna Fecha de la
parte de Planeacin se registra el da en el cual se piensa se va a terminar cada
una de las tareas, esto se hace revisando la columna Horas (minutos) acumulados
dentro de la parte de planeacin de la Plantilla para la Planeacin de la Agenda.
Por ejemplo la tarea nmero 1 tiene una duracin planeada de 2 horas, para el da
37
35
32
26
21
18
11
7
2
Horas
acumuladas
8 2 9
8 3 8
7 6 7
6 5 6
5 3 5
4 7 4
3 4 3
2 5 2
1 2 1
Da Horas Id tarea
37
35
32
26
21
18
11
7
2
Horas
acumuladas
8 2 9
8 3 8
7 6 7
6 5 6
5 3 5
4 7 4
3 4 3
2 5 2
1 2 1
Da Horas Id tarea


110
3 de julio se ha programado trabajar 3 horas, lo que quiere decir que finalizaremos
la tarea 1 y nos sobrar una hora. Esta hora sobrante ser empleada para iniciar
la tarea 2, cuya duracin planeada es de 5, por lo que nos quedarn 4 horas. Para
el da 4 de julio se han reservado 5 horas, suficientes para finalizar la tarea 2 e
iniciar la tarea 3, es decir, que la tarea 2 la finalizaremos el da 2. De esta manera
se procede con las dems tareas.
5.2. Valor Ganado

El propsito del valor ganado es:
Establecer un valor para cada tarea.
Permitir dar seguimiento al progreso comparndolo contra lo planeado.
Facilitar el seguimiento an cuando el plan cambie.
Los principios tras el valor ganado son:
Provee un valor comn para cada tarea.
Este valor es el porcentaje que esta tarea tiene respecto al total de horas
planeadas del proyecto.
No se gana nada por tareas parcialmente completadas.
Si el proyecto sufre cambios grandes, se requieren nuevos planes.
Es comn encontrar la siguiente situacin, supongamos que tenemos un proyecto
que hemos establecido que vamos a finalizarlo en 10 das, por lo cual muchas de
las veces se asume, errneamente, que al finalizar el da 1 se te ndr 10% de
avance, el da 2, 20% de avance y as por cada uno de los das hasta llegar el da
10 donde se alcanzar el 100%. Quiz si pueda darse esta situacin, pero
debemos estar seguros de eso. Cmo hacerlo?, encontrando una unidad que
permita distribuir la cantidad de trabajo alcanzado una vez que es finalizada cada
tarea, esto es el valor ganado.
5.2.2. Establecimiento del Valor Planeado

En la plantilla de planeacin de tareas:
Sumar las horas del proyecto.


111
Calcular el % de cada tarea respecto al total de horas.
Registrar este % como el valor planeado para la tarea.
Calcular el valor planeado acumulado para cada tarea.
En la plantilla de la agenda:
Registrar el valor planeado acumulado para las tareas que sean
completadas cada semana.

Luego, calcular el valor planeado:

El valor planeado, lo que se conseguir de avance al terminar la tarea 1 es
100*2/37=5.4, 2 el tiempo planeado para la tarea 1 y 37 el total del tiempo que se
va a invertir en el proyecto.

37
35
32
26
21
18
11
7
2
Horas
acumuladas
8
8
7
6
5
4
3
2
1
Da
5.4
8.1
16.3
13.5
8.1
18.9
10.8
13.5
5.4
Valor
planeado
100.0 2 9
94.6 3 8
86.5 6 7
70.2 5 6
56.7 3 5
48.6 7 4
29.7 4 3
18.9 5 2
5.4 2 1
Valor planeado
acumulado
Horas Tarea
37
35
32
26
21
18
11
7
2
Horas
acumuladas
8
8
7
6
5
4
3
2
1
Da
5.4
8.1
16.3
13.5
8.1
18.9
10.8
13.5
5.4
Valor
planeado
100.0 2 9
94.6 3 8
86.5 6 7
70.2 5 6
56.7 3 5
48.6 7 4
29.7 4 3
18.9 5 2
5.4 2 1
Valor planeado
acumulado
Horas Tarea


112

38
33
28
22
18
13
8
3
Horas
acumuladas
100.0 5 8
86.5 5 7
70.2 6 6
56.7 4 5
48.6 5 4
29.7 5 3
18.9 5 2
5.4 3 1
Valor
planeado
acumulado
Horas Da
38
33
28
22
18
13
8
3
Horas
acumuladas
100.0 5 8
86.5 5 7
70.2 6 6
56.7 4 5
48.6 5 4
29.7 5 3
18.9 5 2
5.4 3 1
Valor
planeado
acumulado
Horas Da

Luego, registrar el valor planeado acumulado para cada da:
Tomando la columna Fecha de la seccin de Planeacin de la Plantilla de
Planeacin de Tareas, se suman los valores planeados para cada fecha y se
registra esta suma en la columna Valor planeado acumulado de la seccin de
planeacin de la Plantilla para la planeacin de la Agenda.

Con esto se completa la planeacin del proyecto.

Ejecutando el Plan

Si se ha realizado un plan, hay que seguirlo, sino para que planeamos!
5.2.2.1 Dndole seguimiento al plan

A medida que cada tarea es completada, gana su valor planeado:
Registrar este valor ganado.
Registrar la fecha en que la tarea fue finalizada.
Aadir el valor ganado a la fecha en la columna de valor ganado
acumulado.


113
En la plantilla de la agenda, registrar el valor ganado acumulado para cada
semana a medida que se completan.

Dar seguimiento al valor ganado respecto al valor planeado por semana.
Una tarea gana su valor solamente si es completada. Si al finalizar el da no se
complet la tarea su valor no se contabilizar para ese da, sino hasta el da en
que se termine. Al completar una tarea, su valor se registra al igual que el valor
acumulado hasta ese da. El valor ganado nos sirve para saber el estado de
nuestro proyecto, es decir, si estamos adelantados, atrasados o igual a como
planeamos solucionar el proyecto.

5.3. Proyectando la finalizacin del proyecto

Se asume que el proyecto continuar ganando valor a la velocidad que lo ha
ganado.

Extrapolar los resultados del proyecto extendiendo linealmente la funcin de valor
ganado hasta que alcance el 100%.

Con la informacin anterior se determina la fecha de finalizacin proyectada, a
menos que:

Esta es la fecha de finalizacin proyectada, a menos que:
La velocidad del proyecto sea cambiada.
El trabajo que falta para las tareas restantes pueda ser reducido por abajo
de lo planeado.
En la lmina [8/8] del ejemplo de planeacin de la agenda se explica la proyeccin
(la extrapolacin) para saber cuando finalizaramos el proyecto.

Ejemplo de Planeacin de la agenda

Durante el proyecto, registrar en la plantilla de planeacin de tareas el da en que
cada tarea es completada.


114
100.0
94.6
86.5
70.2
56.7
48.6
29.7
18.9
5.4
Valor planeado
acumulado
37
35
32
26
21
18
11
7
2
Horas
acumuladas
8
8
7
6
5
4
3
2
1
Da
5.4
8.1
16.3
13.5
8.1
18.9
10.8
13.5
5.4
Valor
planeado
2 9
3 8
6 7
5 6
3 5
5 7 4
4 4 3
2 5 2
1 2 1
Da de
finalizacin
Horas Tarea
100.0
94.6
86.5
70.2
56.7
48.6
29.7
18.9
5.4
Valor planeado
acumulado
37
35
32
26
21
18
11
7
2
Horas
acumuladas
8
8
7
6
5
4
3
2
1
Da
5.4
8.1
16.3
13.5
8.1
18.9
10.8
13.5
5.4
Valor
planeado
2 9
3 8
6 7
5 6
3 5
5 7 4
4 4 3
2 5 2
1 2 1
Da de
finalizacin
Horas Tarea


Tambin registrar en la planti lla de planeacin de la agenda el valor ganado cada
da.

100.0
86.5
70.2
56.7
48.6
29.7
18.9
5.4
Valor
planeado
acumulado
38
33
28
22
18
13
8
3
Horas
acumuladas
5 8
5 7
6 6
48.6 4 5
29.7 5 4
18.9 5 3
18.9 5 2
5.4 3 1
Valor
ganado
Horas Da
100.0
86.5
70.2
56.7
48.6
29.7
18.9
5.4
Valor
planeado
acumulado
38
33
28
22
18
13
8
3
Horas
acumuladas
5 8
5 7
6 6
48.6 4 5
29.7 5 4
18.9 5 3
18.9 5 2
5.4 3 1
Valor
ganado
Horas Da


115

77.8 100.0 38 5 8
87.5 9
97.2 10
48.6
29.7
18.9
18.9
5.4
Valor
ganado
86.5
70.2
56.7
48.6
29.7
18.9
5.4
Valor planeado
acumulado
33
28
22
18
13
8
3
Horas
acumuladas
100.0 11
68.0 5 7
58.3 6 6
48.6 4 5
29.7 5 4
18.9 5 3
18.9 5 2
5.4 3 1
Valor ganado
proyectado
Horas Da
77.8 100.0 38 5 8
87.5 9
97.2 10
48.6
29.7
18.9
18.9
5.4
Valor
ganado
86.5
70.2
56.7
48.6
29.7
18.9
5.4
Valor planeado
acumulado
33
28
22
18
13
8
3
Horas
acumuladas
100.0 11
68.0 5 7
58.3 6 6
48.6 4 5
29.7 5 4
18.9 5 3
18.9 5 2
5.4 3 1
Valor ganado
proyectado
Horas Da

Usando el valor ganado actual por da de 9.72, registrar el valor ganado por da
para proyectar la finalizacin.

En el ejemplo en el da 5 del proyecto hemos alcanzado (avanzado) el 48.6% por
lo que en promedio hemos logrado 9.72 (48.6/5), en una columna que llamaremos
Valor ganado proyectado, podemos ver el comportamiento que tendr nuestro
proyecto (qu tanto vamos a avanzar en los das subsecuentes para poder saber
cundo vamos a finalizar el proyecto) si continuamos trabajando de la manera en
que lo hemos venido haciendo. As, a partir del 6 da le sumamos 9.72, es decir si
continuamos la tendencia de slo lograr 9.72% de avance diario finalizaremos el
proyecto hasta el da 11 y no para el da 10 como estaba planeado.

Ejercicio de programacin

Se tienen dos listas de datos de nmeros enteros, las cuales no necesariamente
se encuentran ordenadas ni tienen la misma cantidad de elementos. Se desea
crear una tercera lista que contenga todos los nmeros (sin repeticin), de las dos
listas iniciales, esta tercera lista estar en orden creciente o decreciente a
preferencia del usuario. Al final, el programa debe desplegar las tres listas en el
orden seleccionado por el usuario, el nmero de elementos que se repiten y la
diferencia entre el elemento mayor y menor. Utilizar listas enlazadas en la
solucin.


116
Ejemplo

Entrada
l1 = {23, 12, 4, 56, 13, 9, 6}
l2 = {5, 43, 23, 6, 27, 8, 25}
Seleccin
Ordenamiento = Creciente
Salida
l1 = {4, 6, 9, 12, 13, 23, 56}
l2 = {5, 6, 8, 23, 25, 27, 43}
l3 = {4, 5, 6, 8, 9, 12, 13, 23, 25, 27, 43, 56}
Elementos repetidos = 2
Diferencia = 52.
Nota: Los alumnos debern reportar el resultado de sus pruebas.

Plantilla de Planeacin de Tareas.
Plantilla para la Planeacin de la Agenda.
Estndar de codificacin.
Estndar de conteo.
Pantallas de la interfase grfica.
Pantallas de los resultados.
Nota: El orden de entrega de la documentacin es importante, si no se
cumple, disminuir puntos de la calificacin.


117
Forma de Registro de Compromisos

Nombre: ____________________________________ Fecha: _______________
Proyecto:_______________________________________________________

Total de LOC fsicas

Implementacin

Calidad y Liberacin
Total

Productividad

Total de
LOC fsicas /
Total tiempo

Total de LOC
fsicas / Total
tiempo


118
6. La Administracin de los Defectos
Introduccin

El trabajo de un desarrollador de software es entregar productos de software de
calidad en los tiempos y al costo en que fueron planeados, para ello es
imprescindible que el software est libre de defectos. En esta unidad
comenzaremos a recolectar informacin sobre los errores que cometemos, los
clasificaremos y analizaremos para encontrar estrategias que nos ayuden a evitar
el estar inyectndolos. Entenderemos que no es lo mismo un error que un defecto
y pondremos al descubierto el costo que implica el no realizar un trabajo con
calidad desde la primera vez.

Objetivo General


Comprender el costo que tiene el cometer errores en el desarrollo de
productos de software.



Identificar y remover los defectos que inyectamos al producir productos de
software.

Qu es la Administracin de los Defectos?

Antes de contestar esta pregunta, debemos estar seguros de sabe qu es lo que
se entiende por calidad del software.

Aqu el profesor comienza la discusin realizando la pregunta, qu es la calidad
del software?


119

La Calidad del Software

En trminos sencillos, entendemos por calidad del software, desde el punto de
vista del usuario que el software:

Hace lo que tiene que hacer.
Es fcil de instalar.
Es fcil de usar.

Los defectos evitan que el software cumpla con los 3 puntos anteriores.
6.1. La Administracin de Defectos

Es:
Entender los defectos que uno inyecta.
Encontrar y corregir eficientemente los defectos inyectados.
Prevenir la inyeccin de defectos.
Tenemos que tener un mecanismo que nos permita darnos cuenta de los defectos
que estamos inyectando en los diversos productos de software que desarrollamos,
que nos permita entender el porqu los inyectamos, es decir, saber cules son las
causas de inyeccin, que nos permita darnos cuenta lo ms pronto posible de la
presencia de los defectos y nos permita corregirlos de la manera ms econmica.
6.1.1. Pero, qu es un defecto?

Un defecto es cualquier cosa que impida que el software haga lo que tenga que
hacer.

Podemos mencionar como ejemplos, errores de sintaxis, error de interpretacin de
los requisitos, error al momento de teclear el cdigo, etc.
6.1.2. Defecto vs. Error

Los errores son las acciones que las personas realizan que dan como resultado un
defecto.

Las personas cometen errores (causa), los programas tienen defectos
(resultado)!


120

Debemos cambiar la manera de trabajar para eliminar las causas de tal modo que
los defectos puedan ser corregidos o eliminados de la manera ms eficaz y
eficiente posible.

6.1.3. Remocin vs. Prevencin

Remocin de defectos:

Encontrar y corregir.
Proceso costoso.

Prevencin de defectos:

Reduce los errores que uno comete.
Necesita cambios a la manera de trabajar.

Son dos conceptos diferentes pero complementarios para asegurar la calidad de
los productos de software. Con la remocin asumimos que existen defectos, los
cuales deben ser localizados y removidos, es costoso pues te nemos que buscar
en todo el producto lo cual puede consumir mucho tiempo. No es tan fcil
aprender, distinguir los errores que los inyectaron, pues muchas de las veces
estamos ms preocupados por eliminar los defectos que por entender el porqu
de sus causas.

La prevencin requiere tiempo de anlisis, el averiguar las causas, motivos que
dan pie a que se inyecten defectos, una vez entendidas las causas implica trabajar
para eliminarlas, lo cual se traducir en una manera diferente de trabajar.

6.1.4. La Calidad del Software y los Defectos

La remocin de defectos es un proceso que no termina, es decir, no podemos
estar completamente seguros de que un defecto tiene ceros defectos.

La Administracin de los Defectos es cara, impacta tanto a las ganancias como a
la credibilidad de las organizaciones.


121
Nunca podremos estar seguros, completamente seguros, que un producto estar
libre de defectos, pudiramos probar que cierto tipo de defecto no est presente,
pero el dominio de casos de prueba es tan grande que sera econmicamente
imposible probarlos todos.

6.1.5. Costos de Encontrar y Corregir Defectos

Algunos estudios indican que este costo se incrementa en una proporcin de 10 a
medida que un defecto avanza de fase.

Entonces s tiene sentido corregir los defectos lo ms pronto posible, ms an,
prevenir la inyeccin

Por ejemplo, supongamos que se inyecta un defecto en la fase de requerimientos,
si se descubriera en la fase de diseo tendra un costo de 10, en la fase de
codificacin de 100, y as sucesivamente.
6.1.6. Quin debe remover los defectos?

Inicialmente quien los inyect. Cada Ingeniero de Software es responsable de la
calidad de su trabajo.

Qu significa esto?, pues que los ingenieros de software deben tener un
mecanismo sistemtico, un proceso para administrar los defectos.

Existen 3 tcnicas reconocidas para encontrar defectos, las revisiones personales,
las caminatas y las inspecciones. Las revisiones personales como su nombre lo
indica, es el proceso que cada ingeniero de software debe seguir para remover los
defectos que haya podido inyectar en sus productos. Ms adelante en este curso
se explicarn las 3 tcnicas.

6.1.7. El Proceso de Administracin de Defectos

Debemos:
1) Clasificar los defectos.
2) Darles seguimiento.
3) Priorizar los defectos que inyectamos.
4) Analizar las causas para prevenirlas.
5) Implementar las estrategias de prevencin.


122
Aqu es bueno recordar el ciclo de mejora continua de la calidad estudiado en una
leccin anterior.

Debemos mantener un registro de cada defecto que encontremos.

Registrar la mayor cantidad de informacin para poder determinar sus causas. A
medida que incrementamos nuestra base de datos de defectos, podremos darnos
cuenta de cules defectos cometemos con mayor frecuencia y cuales cuestan
ms.

Analizar la informacin recolectada para determinar con certeza cules son los
defectos que causan ms problemas.

Finalmente encontrar maneras para descubrir y corregir los defectos en el
producto y para evitar inyectarlos.
6.1.8. Clasificacin de Defectos

Esta clasificacin debe estar basada en la criticidad de las causas que los
inyectan. La clasificacin que seguiremos es:

Nmero
de Tipo
Nombre del Tipo Descripcin
10 Documentacin Problema: La documentacin, comentarios o mensajes
no se entienden o estn mal.
Correccin: Corregir la documentacin, los comentarios
o los mensajes.
20 Sintaxis/Esttica Problema: Un defecto que puede usualmente ser
detectado por el compilador (errores de sintaxis,
declaraciones faltantes, errores de dedo, formatos de
instrucciones).
Correccin: Corregir la sintaxis o la semntica esttica
de las instrucciones defectuosas.
30 Construccin /
Paquete
Problema: Errores en el control de versiones o en la
administracin del cambio, como por ejemplo en la
reutilizacin o en las bibliotecas.
Correccin: Crear o usar la versin correcta o corregir
el cambio.
40 Asignacin Problema: Una sentencia contiene defectos (operadores
incorrectos, expresiones incorrectas, asignacin de
objetos errneos, nombres duplicados, lmites, alcance
de variables).
Correccin: Corregir la sentencia.


123
Nmero
de Tipo
Nombre del Tipo Descripcin
50 Interfase Problema: Mal diseo o mal uso de las interfases (la
interfase de clase, procedimiento o tipo de dato est
incompleta o es errnea o no es utilizada
apropiadamente).
Correccin: Cambiar la interfase.
60 Chequeo Problema: El manejo de excepciones y errores es
manejado mal o no est presente.
Correccin: Aadir o corregir el manejo de excepciones
y/o errores.
70 Datos Problema: La estructura o contenido de los datos es
errnea.
Correccin: Corregir la estructura o contenido de los
datos.
80 Funcin Problema: Defectos ms all de una sola sentencia en
algoritmos o funcionalidad (algo hecho muy pronto o
muy tarde, algo hecho en forma equivocada, algoritmo
incorrecto, una funcionalidad mal diseado o faltante,
ciclos infinitos, recursin).
Correccin: Aadir o corregir ms de una sentencia.
90 Sistema Problema: Problemas de temporizacin, sincronizacin,
red, hardware, memoria, configuracin o algo parecido.
Correccin: Corregir el problema o cambiar la
configuracin.
100 Ambiente Problema: Defectos en el ambiente de desarrollo o en
los sistemas de soporte (compiladores, herramientas de
diseo, datos para pruebas, etc.).
Correccin: Corregir los defectos de los sistemas de
apoyo o evitar ambientes de desarrollo defectuosos.

En un documento anexo se encuentra la clasificacin de los defectos con la
explicacin y una posible manera de corregir cada uno de ellos.

A medida que vayamos entendiendo los defectos que cometemos podemos refinar
nuestra clasificacin.

No confundir las causas con los tipos de defectos!

Por ejemplo, de Sintaxis podemos abrir una clasificacin para los que tienen que
ver con errores de dedo y otra para los que denoten que no conocemos la sintaxis
de cierta funcin propia del lenguaje o herramienta que estamos usando.


124
Entendiendo los Defectos

Las acciones para encontrar los posibles defectos que inyectamos y el hecho de
encontrarlos son slo el inicio de la mejora de nuestro proceso.

Pudieran escaprsenos defectos, que posteriormente pudieran ser encontrados
por otros.

Hay que aprender de los defectos que encontramos en nuestros programas, pero
ms importante, hay que aprender de los defectos que otros encuentran en
nuestros programas, esto incrementar nuestra mejora.

La falla ms grande es fallar en aprender de lo que hemos fallado!


125
Forma de Registro de Defectos

Nombre:________________________________Fecha: _____________________
Proyecto: ____________________________________

Tipos de defectos
10 Documentacin 60 Chequeo
20 Sintaxis 70 Datos
30 Construccin/Paquete 80 Funcin
40 Asignacin 90 Sistema
50 Interfas e 100 Ambiente
Fases
1 Compromiso y Solucin (Planeacin y Diseo)
2 Implementacin (Codificacin)
3 Calidad y Liberacin (Compilacin, Pruebas y
PostMortem)
Fecha Nmero Tipo Inyectado
en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:

en Fase
Removido
en Fase
Tiempo de
Correccin
Defecto
Corregido

Descripcin:


126

Instrucciones para la Forma de Registro de Defectos

Propsito Esta forma mantiene los datos de cada defecto que es
encontrado y corregido. Los datos son utilizados para
completar la Forma de Resumen del Plan del Proyecto.
General Registrar en esta forma todos los defectos
encontrados en revisiones, compilaciones y pruebas.
Registrar cada defecto por separado y de forma
completa.
Si se necesita espacio adicional, utilizar otra copia de la
forma.
Encabezado Registrar los siguientes datos:
Tu nombre.
La fecha de hoy.
El nombre del proyecto.
El nombre del mdulo/componente.
Fecha Registrar la fecha en que es encontrado el defecto.
Nmero Registrar el nmero de defecto.
Para cada programa, este debe ser un nmero secuencial
comenzando por ejemplo con 1 001.
Tipo Registrar el tipo de defecto tomndolo de la tabla de
estndares de defectos, la cual se encuentra resumida en la
parte superior de la Forma de Registro de Defectos.
Inyectado en Fase Registrar la Fase en la cual fue inyectado el defecto. Utiliza
tu mejor juicio.
Removido en Fase Registrar la fase en la cual el defecto fue removido.
Esto generalmente ser la fase en la cual encuentras el
defecto.
Tiempo de
Correccin
Registrar el tiempo que te tom corregir el defecto. Utiliza tu
mejor juicio. Este tiempo puede ser determinado utilizando
un cronmetro.
Defecto corregido Si inyectaste este defecto mientras corregas otro, registra el
nmero del defecto que estabas corrigiendo.
Si no puedes identificar el nmero de defecto, registra una
X.
Descripcin Escribe una descripcin del defecto que sea clara para que
posteriormente puedas utilizarla para saber porqu
cometiste el error.

Fase de Inyeccin: fase en la cual se comete (inyecta) el defecto.
Fase de Remocin: fase en la cual se encuentra y remueve el defecto.


127
De ahora en adelante, no debemos posponer la solucin, defecto encontrado,
defecto removido inmediatamente!

En un archivo anexo se presenta la forma de registro de defectos, contiene la
explicacin de uso.
6.1.9. Cmo saber qu registrar como defecto?

Una vez que se ha finalizado una tarea y se descubre que contiene defectos, cada
uno de estos defectos debe ser contabilizado.

Una correccin que hagamos en una tarea que no hayamos terminado no se
cuenta como defecto (una correccin al diseo mientras seguimos en el diseo no
es un defecto).

Sin embargo si estamos en la codificacin (implementacin), y un defecto
encontrado requiere un cambio en el diseo, entonces fue un defecto inyectado en
el diseo (compromiso y solucin).

Este punto es importante, est relacionado con entender las fases de desarrollo
(requerimientos, diseo, codificacin, pruebas, etc.).

Debo registrar todos los defectos?

No, si lo que quieres es aparentar, hacerte tonto a ti mismo.

Pero si ests verdaderamente comprometido con mejorar no debes evitar registrar
todos y cada uno de los defectos que encuentres.

Tip: Piensa sobre el tipo de defecto ms apropiado para clasificar tus defectos,
ms an, describe a detalle el sntoma y la causa del error.
Slo teniendo registrada toda la informacin podremos saber por dnde mejorar
(tiempo, costo, calidad).

6.1.9.1. Cmo encontrar los defectos?

Hasta ahora:

En la fase de Implementacin, utilizando el compilador.
En la fase de Calidad y Liberacin, realizando las pruebas.
Despus de la liberacin, cuando los usuarios comiencen a quejarse.


128
El compilador slo encontrar defectos de sintaxis, algunos que caigan en la
clasificacin de interfase y de ambiente. Este es un conjunto reducido de defectos,
adems, el hecho de dejar a una herramienta descubrir nuestros h errores,
posibilita que no tomemos conciencia de estos tipos de defectos y evitemos
encontrar estrategias para no cometerlos en el futuro.

Tradicionalmente la fase de pruebas se ha manejado como sinnimo de calidad,
pero como hemos descrito, nunca estaremos seguros de que efectivamente un
programa est libre de defectos pues del dominio de solucin, datos que puede
manejar un programa y caminos para solucionar, puede ser extremadamente caro
y econmicamente no factible.

6.1.9.2. Densidad de Defectos

La densidad de defectos es definida como el nmero de defectos removidos en un
proyecto dividido por el tamao del proyecto.

Ejemplo:

8 defectos removidos
120 LOC de tamao final

Densidad de defectos = 8/120 = 0.06 defectos/LOC = 66.66 defectos/KLOC
Generalmente esta medida viene expresada por cada 1000 LOC = 1KLOC

6.1.9.3. Eficiencia de Remocin

La eficiencia de remocin est definida como el nmero de defectos removidos en
cada fase dividido por el tiempo empleado en la fase.

Ejemplo:

5 defectos removidos en Calidad y Liberacin.
30 minutos empleados en Calidad y Liberacin.

ERD Calidad y Liberacin = 5/30 = 0.16 defectos/minuto = 10 defectos/hora

El ERD generalmente se expresa en horas, multiplicar por 60


129
6.1.9.3.1. Rendimiento de la Remocin (yield)

Del proceso: El % de defectos removidos antes de la fase de Calidad y Liberacin
(propiamente antes de la compilacin).

De una fase en particular: % de defectos removidos del producto en esa fase.

Objetivo: un yield del 100% (Todos los defectos removidos antes de la primera
compilacin).

La relacin de defectos removidos en la fase analizada respecto al total de
defectos removidos.

Hay una forma ms econmica y eficiente?

S, la prevencin tema de la siguiente unidad.

Ejercicio de programacin

Modifica el programa anterior para:
Decir cuntos elementos estaban en la misma posicin en las listas
originales l1 y l2.
En caso de existir elementos repetidos en l1 y l2, obtener la suma de estos
elementos y guardar el total en l3 eliminando los elementos originales.
Entrada
l1 = {23,12,4,6,13,9,56}
l2 = {5,43,23,6,27,8,25}
Salida
l3 = {4, 5, 8, 9, 12, 13, 23, 25, 27, 43, 46, 56}

Elementos repetidos 6 y 23
Elementos repetidos en la misma posicin 1 (6)
6+6 = 12
23+23 = 46

Slo aparece una vez el 12 pues en l3 no se pueden repetir elementos

Nota: Los alumnos debern reportar el resultado de sus pruebas.


130
Plantilla de Planeacin de Tareas.
Plantilla para la Planeacin de la Agenda.
Forma de Registro de Defectos.
Estndar de codificacin.
Estndar de conteo.
Pantallas de la interfase grfica.
Pantallas de los resultados.

Nota: El orden de entrega de la documentacin es importante, si no se
cumple, disminuir puntos de la calificacin.


131

Nombre:_________________________________________Fecha:_________
Proyecto:_______________________________________________________

Tamao del Progama (LOC)
Planeado

Actual

A la fecha

Total de LOC fsicas

Densidad de defectos Actual
Densidad de defectos

Rendimiento de remocin de
defectos
Actual
Yield

Implementacin
Calidad y Liberacin
Total

Productividad

Total de
LOC fsicas /
Total tiempo

Total de LOC
fsicas / Total
tiempo

Defectos Inyectados Actual A la fecha % a la fecha
Implementacin
Calidad y Liberacin
Total en el Desarrollo

Defectos Removidos Actual A la fecha % a la fecha

Implementacin
Calidad y Liberacin
Total en el Desarrollo
Despus del Desarrollo

Tecnicas Programacion Personal

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tecnicas Programacion Personal

Caricato da

Copyright:

Formati disponibili

Tcnicas de Programacin Personal con Calidad

Modelo Paracurricular Desarrollador de Software 2004 V.1.0.0.

, en la cual est basada este curso.

de enero de este ao.

Potrebbero piacerti anche