Robot Asesino

Ingeniera de Software I

El Caso del Robot Asesino

1Programador de Silicon Valley Acusado por Homicidio noPremeditadoEl 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 deRandy Samuels con los cargos de asesinato no premeditado. Samuels trabajaba como programadoren Silicon Techtronics, Inc., una de las empresas ms nuevas de Silicon Valley en la arena de laalta tecnologa. El cargo involucra la muerte de Bart Matthews, quien fuera muerto el pasado mesde mayo por un robot de la lnea de armado.

Matthews, quien trabajaba como operador de robot en Cybernetics, Inc., en Silicon Heights, fueaplastado y muri a consecuencias de ello, cuando el robot que estaba operando produjo un malfuncionamiento y comenz a oscilar su brazo violentamente. El brazo del robot alcanz aMatthews, arrojndolo contra una pared. Matthews muri en forma casi instantnea a causa de losgolpes recibidos, en un caso que conmocion e indign a muchos de Silicon Valley. De acuerdocon la dictamen de los cargos, Samuels fue quien escribi la pieza del programa de computadoraen 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 queprogramar Samuels. Pero negligentemente malinterpret la frmula, y esto llev a una horriblemuerte. La sociedad debe protegerse de los programadores que cometen errores descuidadamente ode 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 blockborrador tamao oficio. Cada una de las frmulas describe el movimiento del brazo del robot enuna direccin: este-oeste, norte-sur y arriba-abajo.

El SENTINEL-OBSERVER mostr las frmulas a Bill Park, profesor de Fsica en la Universidadde Silicon Valley. ste confirm que estas ecuaciones podan ser usadas para describir elmovimiento del brazo de un robot.

El SENTINEL-OBSERVER mostr entonces el cdigo del programa a Bill Park, escrito por elacusado en lenguaje C de programacin. Preguntamos al Profesor Park, quien est muyfamiliarizado con ste y muchos otros lenguajes de programacin, si el cdigo era o no correctopara las frmulas dadas del brazo del robot.

La respuesta del Profesor Park fue inmediata: No puede ser! Parece que interpret los puntos yde las frmulas como barras y, e hizo lo mismo con las x y las z. Se supona que tena que usar lasderivadas, pero en su lugar tom los promedios!. Si me preguntan, est muy claro que esculpable!

El SENTINEL-OBSERVER no pudo contactar a Samuels para entrevistarlo. Se encuentraprofundamente deprimido por todo esto, nos dijo su novia por telfono. Pero, Randy cree que vaa aliviarse en cuanto pueda decir su versin de la historia.

2Los que Desarrollaron al Robot Asesino Trabajaron bajo unaEnorme Presin


Silicon Valley, EEUUpor Mabel Muckraker

El SENTINEL-OBSERVER tom conocimiento hoy que Randy Samuels y otros que trabajaron enel proyecto del Robot Asesino en Silicon Techtronics, estuvieron bajo tremendas tensiones parafinalizar el software del robot para el 1 de enero de este ao. Segn una fuente bien informada, losaltos niveles gerenciales advirtieron a los integrantes del staff del proyecto que rodaran cabezassi no se cumpla el objetivo del 1 de enero.

Randy Samuels, programador de Silicon Techtronics, fue acusado la semana pasada bajo loscargos de asesinato no premeditado en el ahora famoso caso del robot asesino. Samuels escribiel 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 roboten Cybernetics, Inc. Conforme a la Fiscal de Silicon Valley, Jane McMurdock, Samuelsmalinterpret la frmula matemtica, volviendo al inofensivo Robbie un asesino.

Nuestra fuente informada, quien desea mantenerse en el anonimato y a la que llamaremos Martapor el resto de este artculo, tiene un ntimo conocimiento de todos los aspectos del proyectoRobbie CX30. Marta dijo al SENTINEL-OBSERVER que exista una enorme friccin entre elJefe 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 pusofurioso. Haba rumores de que echaran a toda la Divisin Robtica, que l lideraba, si Robbie [elrobot CX30] no daba muestras de ser un xito comercial. l (Johnson) llam a Sam (Reynolds) asu oficina y realmente lo destruy. Quiero decir, uno poda or los gritos desde el fondo de laoficina. Johnson le dijo a Sam que terminara el proyecto para el primero de enero o de lo contrariorodaran cabezas.

Yo no estoy diciendo que Johnson le ordenara a Sam acortar camino, agreg Marta. Creo quela idea de cortar camino estaba implcita. El mensaje fue: acort camino si quers mantener tupuesto.

De acuerdo con documentos provistos por Marta al SENTINEL-OBSERVER, el 12 de junio delao pasado fueron agregados al proyecto Robbie CX30 veinte nuevos programadores. Esto ocurrialgunos 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 losarreglos de estas contrataciones, seguramente desviando recursos de otros aspectos del proyectoRobbie (CX30). Reynolds se opona con vehemencia a esto. Johnson slo conoca acerca de lafabricacin de hardware. Esa era su especialidad. No pudo haber entendido las dificultades quenosotros estabamos teniendo con el software de la robtica. Usted no puede acelerar un proyecto desoftware agregando ms gente. No es como en una lnea de montaje.

3Segn Marta y otras fuentes dentro del proyecto, la contratacin de estos nuevos veinteprogramadores llev a que se hiciera una reunin entre Johnson, Reynolds y todos los integrantesdel 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 queJohnson y otros miembros a nivel directivo no entendan que el Robbie CX30 erafundamentalmente diferente de versiones anteriores del robot. Estas fuentes dijeron alSENTINEL-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 mata Bart Matthews, ya haban sido despachados. Segn Marta, Sam slo quera mantener las cosaslo ms simples posible. No quera que el nuevo personal complicara las cosas. Se pasaron seismeses leyendo manuales. La mayora de los empleados nuevos no saban nada de robots y Sam noestaba como para perder su tiempo tratando de ensearles. Segn Marta, la reunin del 12 dejunio se hizo famosa en la corporacin Silicon Techtronics porque fue en esa reunin donde RayJohnson anunci su Teora Ivory Snow [no existe el blanco perfecto, o bien, no hay blanco msblanco que el blanco nieve] de diseo y desarrollo de software. De acuerdo a Marta, Ray(Johnson) nos dio una gran presentacin en multi-media, con diapositivas y todo. La esencia deesta Teora Ivory Snow es simplemente que el blanco nieve es 99,44 porciento puro y que nohay razn por la que el software de robtica deba ser ms puro que esto. Dijo repetidas veces queEl software perfecto era un oxmoron .

Marta y otros personajes annimos que se acercaron con informacin, retrataron a Johnson comoun gerente con una desesperada necesidad de ser ayudado por un xito en el proyecto. Versionesanteriores de Robbie, CX10 y CX20, fueron experimentales en naturaleza y nadie esperaba quefueran xitos comerciales. De hecho, la Divisin Robtica de Silicon Techtronics estaba operandocon sus finanzas en rojo desde su concepcin seis aos atrs. O triunfaba el CX30 o SiliconTechtronics quedara fuera del negocio de robtica industrial. Los robots Robbie anteriorestuvieron mucha prensa, especialmente ac en Silicon Valley, dijo otra fuente que tambin quierepermanecer annima. Robbie CX30 iba a capitalizarse con la buena publicidad generada por losproyectos anteriores. Lo nico es que Robbie CX30 era ms revolucionario de lo que Johnsonquera 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 elCX30. Mucho de lo que deba ejecutar era completamente nuevo, pero Johnson nunca lo pudoentender. l slo nos vea como unos perfeccionistas. Uno de sus dichos favoritos era Laperfeccin es la enemiga de lo bueno .

4Los Compaeros Acusan: el Programador del Robot Asesinose Crea una Estrella



Randy Samuels, el que fuera programador de Silicon Techtronics que fue acusado por escribir elsoftware que caus el horrible incidente del robot asesino el pasado mes de mayo, eraaparentemente una prima donna que encontraba muy difcil aceptar crticas, aseguraron hoyvarios compaeros de trabajo.

En una rueda de prensa con varios compaeros de trabajo de Samuels en el proyecto del robotasesino, el SENTINEL-OBSERVER pudo obtener importantes revelaciones acerca de la psiquisdel hombre que puede haber sido criminalmente responsable de la muerte de Bart Matthews,operador de robot y padre de tres criaturas.

Con el permiso de los entrevistados, el SENTINEL-OBSERVER permiti a la profesora SharonSkinner del Departamento de Psicologa de Software en la Universidad de Silicon Valley, escucharuna grabacin de la entrevista. La Profesora Skinner estudia la psicologa de los programadores yotros 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. Estees un trmino utilizado para referirse a un programador que simplemente no puede aceptar lascrticas, o ms precisamente, no puede aceptar su propia falibilidad.

Randy Samuels tiene lo que nosotros, psiclogos de programadores, llamamos una personalidadorientada hacia una tarea, lindando con una personalidad orientada hacia s mismo. Le gusta podercompletar cosas, pero su ego est muy densamente involucrado en su trabajo. En el mundo de laprogramacin esto se lo considera un no, no, agreg el Profesor Skinner en su oficina tapizadade libros.

La Profesora Skinner continu explicando algunos hechos adicionales sobre equipos deprogramacin y personalidades del programador. Bsicamente, hemos encontrado que un buenequipo de programacin requiere de una mezcla de tipos de personalidad, incluyendo a una personaque est orientada hacia la interaccin, que saca una enorme satisfaccin del hecho de trabajar conotra gente, alguien que pueda ayudar a mantener la paz y a que las cosas se muevan en unadireccin positiva. Muchos programadores estn orientados hacia lo que es la tarea, y esto puedeser 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 eldesastre del robot, pero cuando se los presion para que comentaran sobre la personalidad deSamuels y sus hbitos laborales, surgieron varios hechos importantes. Samuels trabajaba en unequipo formado por aproximadamente una docena de analistas, programadores y testers desoftware. (Esto no incluye a veinte programadores que fueron incorporados posteriormente y quenunca llegaron a estar activamente involucrados en el desarrollo del software de la robtica). Sibien cada individuo del equipo posea una especialidad, casi todos estaban comprometidos en todoel proceso de software de principio a fin.

5Sam Reynolds tena un background en procesamiento de datos. Dirigi unos cuantos proyectos desoftware de esa naturaleza, dijo uno de los integrantes del equipo, refirindose al gerente delproyecto Robbie CX30. Pero su rol en el proyecto era ms que nada de lder. Asista a todas lasreuniones importantes y lo mantena a Ray (Ray Johnson, el Jefe de Divisin Robtica) sobrenuestras espaldas lo ms posible. San Reynolds, como ya fuera informado en el SENTINEL-OBSERVER de ayer, se encontraba bajo una severa presin para lograr producir un robot RobbieCX30 operativo para el 1 de enero de este ao. Sam Reynolds no pudo ser ubicado paraentrevistarlo 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), observotro miembro del equipo. En el mundo del desarrollo de software, un equipo democrtico es unequipo en donde todos los miembros de ste tienen un decir igual en el proceso de toma dedecisiones. Desafortunadamente, nosotros ramos un equipo de individualistas muy ambiciosos,muy talentosos - si debo referirme a m mismo - y muy opinadores. Randy (Samuels) era justo elpeor del grupo. Lo que quiero decir es que tenamos, por ejemplo, a dos chicos y a una chica conmasters 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 QualityAssurance. Esta reunin involucraba a Samuels y a tres revisores de un mdulo de software queSamuels haba diseado e implementado. Tales reuniones son llamadas revisiones de cdigo.Uno de los revisores mencion que Samuels haba usado un algoritmo sumamente ineficiente paralograr un determinado resultado y Samuels se puso todo colorado. Empez a gritar una sarta deobscenidades 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 sumdulo, agreg el colega.

El mdulo de software del incidente de la reunin de Quality Assurance fue el primero en seridentificado como una falla en el asesino del operador de robot. No obstante, este colega seapur 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. Setomaba todo muy a pecho. Se gradu con el puntaje ms alto de su clase y luego se recibi conhonores 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. Esees el tipo de arrogancia que tena y tambin demuestra que tena muy poca paciencia paradesarrollar y verificar las especificaciones. Amaba el aspecto de solucionar el problema, laprogramacin propiamente dicha. No pareciera que Randy Samuels qued atrapado en el espritude la programacin sin egolatra, observ la Profesora Skinner cuando escuch esta parte de laentrevista con los colegas de trabajo de Samuels. La idea de una programacin sin egocentrismoes que el producto de software pertenece al equipo y no a los programadores individuales. La ideaes estar abierto a las crticas y estar menos atado al trabajo propio. Ciertamente que la tarea derevisin de cdigo es coherente con esta filosofa en general. Una colega habl acerca de otroaspecto de la personalidad de Samuels: su capacidad de ayuda. Randy odiaba las reuniones, peroera muy bueno con las relaciones de uno a uno. Siempre estaba ansioso por ayudar. Recuerdo unavez que me encontraba encerrada en un camino sin salida y l, en vez de tan slo sealarme ladireccin correcta, se hizo cargo del problema y lo resolvi l mismo. Se pas cerca de cinco dascompletos en mi problema. Por supuesto que mirado en retrospectiva, hubiera sido mejor para el

6pobre Sr. Matthews y su familia que Randy se hubiese dedicado tan slo a sus propias cosas,agreg luego de una larga pausa.

7El 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


Dos grupos, comprometidos con diferentes filosofas de desarrollo de software, casi se enfrentanviolentamente durante las reuniones iniciales de planeamiento para el Robbie CX30, el robot deSilicon Techtronics que mat a un obrero de la lnea de ensamble el pasado mes de mayo. Estabaen cuestionamiento si el proyecto Robbie CX30 deba proseguir de acuerdo con el modelo decascada o el modelo de prototipo .

El modelo de cascada y el de prototipo son dos mtodos comunes de organizar un proyecto desoftware. En el modelo de cascada, el proyecto de software pasa a travs de etapas definidas dedesarrollo. La primera etapa es el anlisis de los requerimientos y especificaciones, durante la cualse intenta arribar a un acuerdo en cuanto a la funcionalidad detallada del sistema. A medida que elproyecto pasa de una etapa a la siguiente, existen limitadas oportunidades de dar marcha atrs ycambiar decisiones ya tomadas. Una desventaja de este enfoque es que los usuarios potenciales notienen oportunidad de interactuar con el sistema recin hasta bien entrado en el ciclo de vida delmismo.

En el modelo de prototipo, se pone un gran nfasis en producir un modelo o prototipo operativobien temprano durante el ciclo de vida del sistema. El prototipo es construido con el propsito dearribar a una especificacin final de la funcionalidad del sistema propuesto. Los usuariospotenciales interactan con el prototipo en forma temprana y con frecuencia hasta que sonacordados los requerimientos. Este enfoque le da a los potenciales usuarios la oportunidad deinteractuar con un sistema prototipo en forma temprana durante el ciclo de desarrollo, y muchoantes que el sistema final est diseado y codificado.

En un memorndum de fecha 11 de diciembre del anteao pasado, Jan Anderson, un miembro delequipo original del proyecto CX30, atac duramente la decisin tomada por el gerente de proyectoSam Reynolds de emplear el modelo de cascada. El SENTINEL-OBSERVER obtuvo una copiadel memo de Anderson, dirigido a Reynolds, y Anderson verific la autenticidad del memorndumpara este diario.

Reynolds despidi a Anderson el 24 de diciembre, justo dos semanas despus que ella escribiera elmemo.

El memo de Anderson hace referencia a una reunin anterior en la que ocurri un fuerteintercambio de opiniones relacionadas con la filosofa del desarrollo del software.

En el memo, Anderson subray el siguiente prrafo.:

8No fueron mis intenciones impugnar su competencia durante nuestra reunin de ayer, pero deboprotestar con mi mayor vehemencia contra la idea de que completemos el software de RobbieCX30 siguiendo el modelo de cascada que usted ya us en otros proyectos. No necesito recordarleque aquellos eran proyectos de procesamiento de datos que involucraban el procesamiento detransacciones de negocios. El proyecto Robbie CX30 llevar un alto grado de interaccin, tantoentre robot y componentes como entre robot y su operador. Dado que la interaccin del operadorcon el robot es tan importante, la interfaz no puede estar diseada como una idea de ltimomomento.

Randy Samuels, a quien se lo acus de asesinato no premeditado por la muerte del operador BartMatthews, 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 sobrela controversia cascada-prototipo, pero s afirm que dara una mano con tal que exoneraran aSamuels.

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 delmtodo cascada vs. prototipo en trminos simples. El punto principal en realidad era si podamosllegar a ponernos de acuerdo en los requerimientos del sistema sin dejar que los operadores delrobot presintieran lo que tenamos en mente. Reynolds ha estado en el negocio de procesamiento dedatos por tres dcadas y es bueno en eso, pero nunca debera haber sido el gerente de esteproyecto.

Conforme a registros obtenidos por el SENTINEL-OBSERVER, Silicon Techtronics transfiri aSam Reynolds de la Divisin Procesamiento de Datos, que se encargaba de inventario y salarios, ala Divisin Robtica, justo tres semanas antes de la reunin del 11 de diciembre a que aludeAnderson en su memo.

Reynolds fue transferido a la Divisin Robtica por el presidente de Silicon Techtronics, MichaelWaterson. Reynolds reemplazaba a John Cramer, quien gerenciaba el anterior proyecto RobbieCX10 y CX20. Cramer fue puesto a cargo del proyecto CX30, pero muri inesperadamente en unaccidente areo. Al colocar a Reynolds a cargo del proyecto CX30, nos dice nuestra fuente, queWaterson iba en contra del consejo de Ray Johnson, Jefe de la Divisin Robtica. De acuerdo conestas fuentes, Johnson se opona fuertemente a la alternativa de ponerlo a Reynolds como jefe delproyecto Robbie CX30. Estas fuentes dijeron al SENTINEL-OBSERVER que la eleccin deWaterson por Reynolds fue puramente una decisin de recorte de gastos. Era ms barato transferira Reynolds a la Divisin Robtica que incorporar a un nuevo lder de proyecto fuera de lacorporacin.

La fuente annima que el SENTINEL-OBSERVER llamar Marta describi la situacin de estemodo: Waterson pensaba que sera ms barato transferir a Reynolds a robtica antes que intentarencontrar afuera un nuevo gerente para el proyecto Robbie. Adems, Waterson tenda a sospecharde la gente de afuera del grupo. Con frecuencia mandaba memos sobre cunto tarda la gente enaprender el modo de hacer las cosas de Silicon Techtronics. Desde el punto de vista deWaterson, Reynolds era el gerente y fue transferido a su nuevo puesto en Robtica como ungerente y no como un experto tcnico. Claramente, Reynolds se vea a s mismo tanto gerente comoexperto tcnico. Reynolds no tena conciencia de sus propias limitaciones tcnicas.

9Segn Marta, Reynolds era muy renuente a gerenciar un proyecto que no usara el modelo decascada que tan bien le haba servido en el procesamiento de datos. Tild al modelo prototipo comoun modelo de moda en la reunin del 11 de diciembre, y despus de una serie de intercambiosverbales la cosa se puso muy personal.

Anderson estaba especialmente expresiva, recuerda Marta. Tena mucha experiencia coninterfaces con usuarios y desde su perspectiva, la interfaz robot-operador era crtica para el xitodel CX30, dado que la intervencin del operador sera frecuente y a veces crtica. En suentrevista con el SENTINEL-OBSERVER, Jan Anderson coment sobre este aspecto de la reunindel 11 de diciembre:

Reynolds estaba en contra de perder el tiempo - para usar sus propias palabras - con cualquiertipo 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 lacomputadora eran una moda, el diseo orientado a objetos era una moda, la especificacin formal ylas 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 recibiun 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 reporter mientrasrevisaba una copia del memo con el plan del proyecto. Anlisis de requerimientos yespecificacin, luego diseo de arquitectura y diseo detallado, codificacin, prueba, entrega ymantenimiento. En el modo de ver de Reynolds, no haca falta tener ninguna interaccin del usuariocon el sistema hasta muy, pero muy avanzado el proyecto. El SENTINEL-OBSERVER se haenterado de que el primer operador que realmente us el robot Robbie CX30 en una funcinindustrial fue Bart Matthews, el hombre que fue muerto en la tragedia del robot asesino. Esteprimer uso de Robbie CX30 en un uso industrial fue cubierto por los medios, incluyendo esteperidico. Como una gran 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 BartMatthews. A Matthews se lo muestra operando al mismsimo robot Robbie CX30 que lo aplasthasta la muerte tan solo dos meses despus de la toma fotogrfica.

10

Silicon Techtronics Prometi Entregar un Robot Seguro

Cuestionada la Calidad de Entrenamiento del Operador

Especial para el SENTINEL-OBSERVER de SILICON VALLEY


En una conferencia de prensa de esta tarde, un grupo de programadores que se autodenominanComit de Justicia para Randy Samuels, distribuy documentos que muestran que SiliconTechtronics se oblig a s misma a hacer entrega de robots que no causaran ningn dao corporala los operadores humanos. Randy Samuels es el programador que ha sido acusado de asesinato enel infame caso del robot asesino.

No podemos entender como el Fiscal pudo acusar a Randy con esos cargos cuando, de hecho, lacompaa Silicon Techtronics estaba legalmente obligada a producir y entregar robots seguros aCybernetics, dijo el vocero del comit, Ruth Witherspoon. Creemos que en todo esto hay unencubrimiento y que hay algn tipo de confabulacin entre la gerencia de SiliTech [SiliconTechtronics] y la oficina del Fiscal. Michael Waterson era uno de los ms grandes contribuyentesde la campaa de reeleccin de la Sra. McMurdock del ao pasado. Michael Waterson esPresidente Ejecutivo de Silicon Techtronics. Jane McMurdock es la Fiscal de la ciudad de SiliconValley. El SENTINEL-OBSERVER confirm que Waterson hizo varios grandes aportes a lacampaa de reeleccin de McMurdock el otoo pasado.

A Randy le estn haciendo pagar los platos rotos por una empresa que tiene estndares de controlde calidad malos y no lo vamos a permitir! Grit Whiterspoon en una emotiva declaracin a losperiodistas. Creemos que la poltica ha entrado en todo esto.

Los documentos que fueron distribuidos por el comit por la Justicia para Randy Samuels eranporciones de lo que se llama un documento de requerimientos. Segn Ruth Witherspoon y otrosmiembros del comit, este documento prueba que Samuels no fue legalmente responsable de lamuerte de Bart Matthews, el desafortunado operador de robot que fue muerto por un robot deSilicon 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 Techtronicsprometi entregar a Cybernetics. Segn Whiterspoon, el robot Robbie CX30 fue diseado para serun 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 RobbieCX30 no era un robot de llave en mano sino un robot que necesitaba ser programado de formadiferente para cada aplicacin.

No obstante, todos los documentos de requerimientos que fueron acordados bajo los auspicios delproyecto Robbie CX30, incluyendo al acuerdo entre Silicon Techtronics y Cybernetics, contienenlos siguientes fundamentos de importancia:

11

El robot ser de operacin segura y aun bajo circunstancias excepcionales (ver Seccin 5.2), elrobot no causar dao corporal alguno al operador humano.

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 decdigos 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 realdao corporal. Las condiciones excepcionales incluyen eventos inusuales tales como datosextraos desde los sensores del robot, movimiento errtico o violento del robot o error deloperador. 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 tratasobre los requerimientos no funcionales. Los requerimientos no funcionales listan en detalle lasrestricciones bajo las cuales operara el robot. Por ejemplo, el requerimiento de que el robot seraincapaz de daar a su operador humano es una restriccin y Silicon Techtronics, segn RuthWhiterspoon, estaba legalmente obligada a satisfacer este punto. La parte de los requerimientosfuncionales del documento de requerimientos cubre (nuevamente en sumo detalle) elcomportamiento del robot y su interaccin con el entorno y su operador humano. En particular, losrequerimientos funcionales especificaban el comportamiento del robot bajo cada una de lascondiciones excepcionales esperadas. En su declaracin a los periodistas en la conferencia deprensa, Whiterspoon explic que Bart Matthews fue muerto cuando se produjo la condicinexcepcional 5.2.4.26. sta involucra un movimiento del brazo del robot extremadamente violento eimpredecible. Esta condicin requiere de la intervencin del operador, a saber el ingreso de loscdigos de comando mencionados en el documento, pero aparentemente Bart Matthews seconfundi y no pudo ingresar con xito estos cdigos.

Si bien el programa de Randy Samuels estaba mal - l en verdad malinterpret las frmulas de ladinmica del robot, como se inform a los medios. La condicin excepcional 5.2.4.26 estabadiseada para protegerse de justamente este tipo de contingencia, dijo Whiterspoon a losperiodistas. Los valores del movimiento del robot generados por el programa de Randyidentificaron correctamente a esta condicin excepcional y el operador del robot recibi el debidoaviso de que algo andaba mal.

Whiterspoon dijo que posea una declaracin firmada de otro operador de robot de Cybernetics endonde afirmaba que las sesiones de entrenamiento ofrecidas por Silicon Techtronics nuncamencionaron a sta ni a tantas otras condiciones excepcionales. Segn Whiterspoon, el operadordel robot ha jurado que ni a l ni a ningn otro operador de robot les fue dicho jams que el brazodel robot poda oscilar violentamente.

Whiterspoon cit esta declaracin en la conferencia de prensa. Ni yo ni Bart recibimosentrenamiento para manejar este tipo de condicin excepcional. Dudo mucho que Bart Matthewstuviese idea de qu se supona deba hacer cuando la pantalla de la computadora comenz amostrar el mensaje de error.

Las condiciones excepcionales que requieren de la intervencin del operador causan un mensaje deerror que se genera en la consola del operador. La Polica de Silicon Valley confirm que cuandoBart Matthews fue muerto, el manual de referencia en su consola estaba abierto en la pgina delndice que contena los cdigos de ingreso para los errores.

Witherspoon luego cit secciones del documento de requerimientos que obligan a SiliconTechtronics (el vendedor) a entrenar adecuadamente a los operadores de robots:

12

El vendedor suministrar cuarenta (40) horas de entrenamiento para los operadores. Esteentrenamiento cubrir todos los aspectos de la operacin del robot, incluyendo una coberturaexhaustiva de los procedimientos de seguridad que deben seguirse en caso de condicionesexcepcionales que contengan potencialmente el riesgo de dao corporal. El vendedor proveer yadministrar instrumentos de prueba apropiados que sern usados para certificar el suficienteentendimiento del operador de las operaciones de la consola del robot y de los procedimientos deseguridad. Slo los empleados del cliente que hayan pasado estas pruebas estarn habilitadas paraoperar el robot Robbie CX30 en una verdadera funcin industrial.

El manual de referencia deber suministrar instrucciones claras para la intervencin del operadoren todas las situaciones excepcionales, especialmente e inclusive aquellas que contenganpotencialmente 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 losoperadores. Es ms, casi no se dedic tiempo alguno al tratamiento de condicionesexcepcionalmente peligrosas.

La prueba escrita desarrollada por Silicon Techtronics para habilitar a un operador de robot eraconsiderada por los empleados de Cybernetics como un chiste, asegur Whiterspoon.Obviamente Silicon Techtronics no le dedic mucho al entrenamiento y procedimientos de pruebaobligatorios segn el documento de requerimientos segn la evidencia en nuestro poder.Reimpreso con el permiso de ROBOTIC WORLDel diario de ROBOTICS AND ROBOTICS APPLICATIONS

13

La Interfaz del Robot Asesino

Dr. Horace Gritty, Departamento de Ciencias de la Computacin y materias relacionadasUniversidad de Silicon VallleySilicon Valley, EEUU

Resumen: El robot industrial Robbie CX30 se supona que deba establecer unnuevo modelo de inteligencia de robots industriales. Desgraciadamente, uno de losprimeros robots Robbie CX30 mat a un obrero de la lnea de montaje, y sto lleva la acusacin de uno de los que desarrollaron el software del robot, RandySamuels. Este paper promueve la teora de que quien debera estar en juicio en estecaso sera el diseador de la interfaz robot-operador. El robot Robbie CX30 violacasi todas las reglas del diseo de interfaz. Este paper se centra en cmo la interfazdel Robbie CX30 viol cada una de las Ocho Reglas de Oro de Shneiderman.

1. IntroduccinEl 17 de mayo de 1992, un robot industrial Robbie CX30 de Silicon Techtronics mat a suoperador, 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 unmdulo de software, escrito y desarrolado por Randy Samuels, un programador de SiliconTechtronics, fue el responsable del comportamiento errtico y violento que a su vez llev a lamuerte por decapitacin de Bart Matthews [NOTA AL PIE. Los medios de prensa manejaron lainformacin haciendo creer que Bart Matthews haba sido aplastado por el robot, pero la evidenciafotogrfica dada a este autor muestra otra cosa. Tal vez, las autoridades trataban de proteger lasensibilidad pblica].

Como experto en el rea de interfaces con el usuario (1, 2, 3), se me pidi prestar ayuda a lapolica en la reconstruccin del accidente. Para poder hacer esto, se le pidi a Silicon Techtronicsque me suministrara un simulador de Robbie CX30 que incluyera por completo la consola deloperador del robot. Esto me permiti investigar el comportamiento del robot sin tener que enrealidad arriesgarme seriamente. Debido a mi profundo entendimiento de interfaces con el usuarioy factores humanos pude reconstruir el accidente con extrema precisin. Sobre la base de estareconstruccin, llegu a la conclusin de que fue el diseo de la interfaz y no el por ciertoimperfecto 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 contraRandy Samuels. Pienso que cualquier Computador Cientfico competente, dado una oportunidad deinteractuar con el simulador del Robbie CX30, tamben habra concludo que el diseador de lainterfaz y no el programador debera haber sido acusado por negligencia, si no por homicidio nopremeditado.

14

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 deoro de Shneiderman (4). Tambin utilic otras tcnicas para evaluar la interfaz, pero stas sernpublicadas en papers separados. En esta seccin ofrezco una breve revisin de las ocho reglas deoro de Shneiderman, un tema que resultar ms familiar para expertos en interfaces decomputacin 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 unainterfaz con el usuario sea coherente a muchos niveles. Por ejemplo, los diseos depantalla deben ser coherentes de una pantalla a la siguiente. En un entorno en que seusa una interfaz grfica con el usuario (GUI), esto tambin implicar concordancia deun utilitario al siguiente.

2. Permitirle a los usuarios frecuentes el uso de shortcuts. Los usuarios frecuentes (o,power users) pueden desalentarse ante tediosos procedimientos. Permitirle a estosusuarios un procedimiento menos tedioso para completar una tarea dada.

3. Dar realimentacin de informacin. Los usuarios necesitan ver las consecuencias de susacciones. Si un usuario ingresa un comando pero la computadora no muestra ya sea quelo est procesando o lo ha procesado, esto puede dejar al usuario confundido odesorientado.

4. Disear dilogos que tengan un fin. Interactuar con una computadora es algo as comodialogar o conversar. Cada tarea debe tener un inicio, un desarrollo y un fin. Esimportante que el usuario sepa cundo una tarea est finalizada. El usuario necesitatener la sensacin de que la tarea ha alcanzado su trmino.

5. Permitir manejos simples de los errores. Los errores del usuario deben estar diseadosdentro del sistema. Otro modo de decirlo es que no debe haber ninguna accin por partedel usuario que sea considerada como un error que est ms all de la capacidad delsistema 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 usuariodeshacer este error.

6. Permitir deshacer las acciones con facilidad. Ms genricamente, los usuarios debenpoder deshacer lo que han hecho, sea sto o no de naturaleza errnea.

7. Respaldar que el centro del control est internamente. La satisfaccin del usuario esalta cuando el usuario tiene la sensacin de que es l o ella quien tiene el control y lasatisfaccin del usuario es baja cuando el usuario siente que la computadora tiene elcontrol. Disear interfaces para reforzar la sensacin de que es en el usuario donde yaceel control en el mbito de la interaccin humano-computadora.

8. Reducir la carga de la memoria inmediata. La memoria inmediata del ser humano esnotablemente limitada. Los psiclogos regularmente citan a la ley de Miller que diceque la memoria inmediata est limitada a siete piezas discretas de informacin. Hacertodo lo posible para liberar la carga en la memoria del usuario. Por ejemplo, en lugar de

15

pedirle al usuario que tipee el nombre de un archivo para abrirlo, presentar al usuariouna lista de archivos disponibles en ese momento.

3. Revisin de la consola del robotLa 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 lamuerte de un operador de robot.

La consola del robot era una IBM PS/2 modelo 55SX con un procesador 80386 y un monitor EGAcolor con resolucin 640 x 480. La consola tena un teclado, pero no mouse. La consola estabaempotrada en una estacin de trabajo que tena, adems, estantes para manuales y un rea paratomar notas y para leer manuales. No obstante, el rea para escribir/leer estaba a bastantedistancia de la pantalla de la computadora, o sea que era bastante incmodo y cansador para eloperador manejar cualquier tarea que requiriera de mirar algo en el manual y luego actuarrpidamente con respecto al teclado de la consola. La silla del operador estaba deficientementediseada 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 mejordiseo para los ingresos de los datos. Uno slo podra concluir que Silicon Techtronics no tenamucha experiencia en tecnologa de interfaces con el usuario. El documento de requerimientos (5)especificaba un sistema manejado por menes, lo cual era una eleccin razonable. Sin embargo, enun utilitario en donde lo escencial era la rapidez, especialmente cuando la seguridad del operadorestaba en juego, el uso de un teclado para todas las tareas de seleccin de opcin de menes fueuna eleccin de extremada pobreza, que requera de mucho uso del teclado para lograr el mismoefecto que poda haberse conseguido casi instantneamente mediante un mouse. (Ver el paperescrito por Foley et al. (6) En realidad, se me ocurrieron todas estas ideas antes que Foley laspublicara, pero l me gan).

El operador del robot poda interactuar con el robot y de este modo producir un impacto sobre sucomportamiento al hacer las opciones en un sistema de menes. El men principal consista de 20temes, demasiados en mi opinin, y cada tem del men principal tena un submen tipodesplegable asociado a ste. Algunos de los submenes tenan tanto como veinte temes -nuevamente, demasiados. Es ms, pareca haber muy poca rima o razn en cuanto a por qu lostemes de los menes estaban listados en el rden en que lo estaban. Hubiese sido mucho mejor unaorganizacin alfabtica o funcional.

Algunos del los temes en los menes desplegables tenan hasta cuatro menes pop up relacionadosa stos. stos apareceran en secuencias a medida que se haca la seleccin correspondiente en lossubmenes. Ocasionalmente, una eleccin de un submen abrira un cuadro de dilogo en lapantalla. Un cuadro de dilogo requiere de cierto tipo de interaccin entre el operador y el sistema,por ejemplo para resolver ciertos temas, como ser, ingresar cul es el dimetro de un dispositivodado a ser bajado en el bao de cido.

El sistema de menes presenta una estricta jerarqua de eleccin de menes. El operador podravolver hacia atrs en esta jerarqua apretando la tecla de escape. Esta tecla escape tambin podraterminar los dilogos.

El uso de color en la interfaz fue muy poco profesional. Haba demasiados colores en un espaciodemasiado chico. Los contrastes eran muy fuertes y el resultado, para este revisor, result en una

16

severa fatiga ocular en tan slo quince minutos de uso. Hubo uso excesivo de efectos musicalestontos y flashes cuando se ingresaban opciones o cdigos errneos.

17

Uno debera preguntarse por qu Silicon Techtronics no intent un enfoque ms sofisticado para eldiseo de la interfaz. Luego de un cuidadoso estudio del dominio de los utilitarios del RobbieCX30, he llegado a la conclusin de que una interfaz de manipulacin directa, que mostraraliteralmente al robot en la consola del operador, habra sido lo ideal. El entorno tan visual dentrodel cual operaba el robot se prestaba naturalmente al diseo de metforas de pantalla apropiadaspara ese entorno, metforas que el operador podra entender con facilidad. Esto permitira que eloperador manipulara el robot mediante el manejo, en la consola del robot, de la representacingrfica del robot en su entorno. He solicitado a uno de mis estudiantes en el doctorado, SusanFarnsworth, que investigara un poco ms esta posibilidad.

4. En qu modo la interfaz del robot Robbie CX30 viol las ocho reglasde oro

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

4.1 Buscar siempre la coherenciaEn la interfaz del usuario de Robbie CX30 hubieron muchas incoherencias. Los mensajes de errorpodan aparecer en casi cualquier color y podan estar acompaados por casi cualquier tipo deefecto musical. Adems, los mensajes de error podan aparecer en casi cualquier lugar de lapantalla.

Cuando Bart Matthews vio el mensaje de error de la condicin excepcional que ocurri luego, lacual requera la intervencin del operador, es probable que fuera esa la primera vez que vea esemensaje en especial. Adems, el mensaje de error apareci en un cuadro verde, sin ningn efecto desonido. Este es el nico mensaje de error de todo el sistema que aparece en verde y sin ningn tipode acompaamiento de orquesta.

4.2 Permitir que los usuarios frecuentes utilicen shortcutsEste principio no aparece de ningn modo en todo el diseo de la interfaz. Por ejemplo, hubierasido una buena idea permitir que los usuarios frecuentes pudieran ingresar la primera letra de laopcin de un submen o men en lugar de requerrseles el uso de las teclas del cursor y luego latecla enter para elegir esa opcin determinada. El mecanismo de seleccin de menes de estesistema debe haber provocado al operador bastante fatiga mental.

Es ms, debera haberse permitido algn tipo de sistema de tipeo anticipado que permitiera alusuario frecuente ingresar una secuencia de opciones de men sin tener que esperar a queapareciera realmente el men en pantalla.

18

4.3 Ofrecer realimentacin1 de informacinEn muchos casos el usuario no tiene idea de si el comando que acaba de ingresar se estprocesando o no. Este problema se exagera adems por las inconsistencias en el diseo de lainterfaz con el usuario. En algunos casos al operador se le da una realimentacin detallada de loque el robot est ejecutando. En otros, el sistema permanece misteriosamente silencioso. Engeneral, al usuario se lo lleva a que espere algn tipo de realimentacin y por consiguiente se quedaconfundido cuando sta no se le da. En la pantalla, no hay una representacin visual del robot y suentorno, 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, unatarea completa, pero al operador se lo deja sin el tipo de realimentacin que le confirmare que latarea ha sido en efecto completada. Por ejemplo, hay un dilogo bastante complicado que senecesita cuando se quiere sacar un elemento de un bao de cido. Sin embargo, luego de completareste dilogo, el usuario es llevado a otro dilogo nuevo, y no relacionado con ste, sin que se leinforme que el dilogo anterior ha finalizado.

4.5 Ofrecer manejo simple de los erroresEl 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 enrealidad ocurre, es probable que no se repita por algn tiempo. Ello se debe a que la interfaz con elusuario 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 facilidadComo se menciona en el prrafo anterior, la interfaz con el usuario hace muy dificil la tarea dedeshacer entradas errneas. En general, el sistema de menes permite deshacer facilmente lasacciones, pero esta filosofa no alcanza al diseo de los cuadros de dilogo y al manejo decondiciones excepcionales. Desde un punto de vista prctico (opuesto al terico), la mayora de lasacciones son irreversibles cuando el sistema est en un estado de condicin excepcional, y estoayud a llegar a la tragedia del robot asesino.

1Feedback

19

4.7 Promover que uno sea el centro del control.Muchas de las deficiencias tratadas en los prrafos precedentes disminuyeron la sensacin detener el control. Por ejemplo, no recibir informacin, no poder concluir las interacciones, nopermitir deshacer con facilidad las acciones en el momento en que surgen las excepciones, todasestas cosas actan para disminuir la sensacin de que el usuario posee el control sobre el robot.Hubieron muchas caractersticas de esta interfaz que hicieron que el operador sintiera que hay unenorme bache entre la consola del operador y el robot en s, mientras que un buen diseo deinterfaz hubiera hecho transparente la interfaz con el usuario y le hubiera dado al operador delrobot la sensacin de estar en contacto directo con el mismo. En un caso, le orden al robot moverun elemento desde bao de cido hasta la cmara de secado y pasaron 20 segundos antes de que elrobot pareci responder. De este modo, no tuve la sensacin de estar controlando al robot. Tanto larespuesta demorada del robot como la falta de realimentacin en la pantalla de la computadora, mehicieron sentir que el robot era un agente autnomo, la verdad, un sentimiento como mnimoperturbador.

4.8 Reducir la carga de la memoria de corto plazoUn sistema que se maneja por medio de menes es en general bueno en trminos de la carga dememoria que crea en los usuarios. No obstante, hay una gran variacin entre implementacionesparticulares de sistemas de men en lo que hace a carga de memoria. La interfaz con el usuario deRobbie CX30 tena menes muy grandes sin una obvia organizacin interna. Esto crea una grancarga al operador en trminos de memoria y tambin en trminos de tiempos de bsqueda, eltiempo 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 facilmente de formade mostrarle al usuario estos nmeros de parte, etc., sin necesitar que el usuario recordara estascosas 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 ningnainstalacin de ayuda en lnea o sensible al contexto! Si bien he ido a los cursos de entrenamientoofrecidos por Silicon Techtronics, muchas veces me encontr navegando por los manuales dereferencia para poder encontrar la respuesta a an las ms bsicas preguntas, tales como:Qusignifica esta opcin de men? Qu pasa si selecciono esta opcin?

5. Una reconstruccin de la tragedia del robot asesinoLas fotos policiales de la escena del accidente no son nada agradables de ver. La consola deloperador estaba salpicada con bastante cantidad de sangre. No obstante, la calidad de las fotos esexcepcional y utilizando tcnicas de ampliacin pude descubrir los siguientes factores deimportancia sobre el momento en que se produjo el accidente:

1. La luz NUM LOCK estaba encendidaEl teclado IBM contiene un tablero numrico que puede operar de dos modos. Cuando la luz NUMLOCK est encendida, esa parte se comporta como una calculadora. Del otro modo, las teclaspueden usarse para mover el cursor en la pantalla.

20

2. Haba sangre esparcida en el tablero numricoLas huellas ensangrentadas indican que Bart Matthews estaba usando el tablero numrico en elmomento en que fue golpeado y muerto.

3. Se encontraba titilando en verde un mensaje de errorEsto nos dice la situacin de error vigente en el momento en que ocurri la tragedia. El mensaje deerror deca ROBOT DYNAMICS INTEGRITY ERROR-452

4. Haba un manual de referencia que estaba apoyado abierto sobre el rea delectura/escritura de la estacin de trabajoUno de los cuatro volmenes del manual de referencia estaba abierto en la pgina del ndice quecontena el tem ERRORES/MENSAJES.

5. En la pantalla tambin haba un mensaje que mostraba instrucciones aloperadorEl mensaje apareca en amarillo en la parte inferior de la pantalla. En el mensaje se lea . PORFAVOR INGRESE INMEDIATAMENTE LA SECUENCIA DE COMANDOS PARACANCELAR EL ERROR DINMICO DEL ROBOT!!!

En base a las evidencias fsicas ms otras evidencias contenidas en los registros del sistema, ybasndose en la naturaleza del error ocurrido (error de integridad de dinmica del robot - 45, elerror que estuvo causado por el programa de Randy Samuels), he llegado a la conclusin de queoccurri 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 apareceen la pantalla. Bart Matthews no lo ve porque no hay efecto de audio o seal sonora tal comoocurre con todas las otras situaciones de error. Adems, el mensaje de error aparece en verde, loque 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 BartMatthews lo note.

10:24:05 Bart Matthews se da cuenta del mensaje de error, no sabe lo que significa. No sabequ hacer. Intenta con el submen cancelacin de emergencia, un submen de uso genrico paraapagar el robot. Este involucra SEIS opciones de men por separado, pero el Sr. Matthews no seda cuenta de que la luz NUM LOCK est encendida. Por ende, las opciones del men no estningresando dado que las teclas del cursor operan como teclas de calculadora.

10:24:45 El robot gira del bao de cido y comienza a arrastrar la consola del operador, consus brazos dentados batindose con gran amplitud. Nadie esperaba que un operador tuviera quehuir de un robot descontrolado, as que Bart Matthews queda atrapado en su rea de trabajo por elrobot que avanza. Ms o menos para este momento es que Bart Matthews saca el manual dereferencia y empieza a buscar el error ERROR DE INTEGRIDAD DE DINMICA DELROBOT - 45 en el ndice. Ubica con xito una referencia a mensajes de error en el ndice.

2 Error de integridad de dinmica de robot-45

21

10:25:00 El robot ingresa al rea del operador. Bart Matthews abandona la bsqueda delprocedimiento del operador ante un error de integridad de dinmica del robot. En su lugar, intentauna vez ms ingresar la secuencia de cancelacin de emergencia desde el teclado numrico,momento en que es golpeado.

6. Resumen y conclusionesSi bien el mdulo de software escrito por Randy Samuels caus en verdad que el robot RobbieCX30 oscilara fuera de control y atacara a su operador humano, un buen diseo de la interfazhubiera permitido al operador terminar con el comportamiento errtico del robot. En base alanlisis de la interfaz del usuario del robot llevado a cabo utilizando las ocho reglas de oro deShneiderman, el experto en diseo de interfaces ha arribado a la conclusin de que el diseador dela 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 delrobot asesino], charla dada en el Simposio Internacional de la Universidad de Silicon Valley sobreSeguridad de Robots e Interfaces con el Usuario, Marzo de 1991. Tambin por aparecer en lasNotas de Alumnos de la Universidad de Silicon Valley.

3. Gritty, Horace (se espera para 1993). CODEPENDENCY: How Computer Users Enable Poor UserInterfaces, Angst Press, New York [Cmo los usuarios de computadoras permiten interfacesdeficientes]

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 RobbieCX 30: versin de Cybernetics Inc., Documento Tcnico N 91-0023XA, Silicon TechtronicsCorporation, Silicon Valley, USA 1245 pag.

6. Foley, J. P., Wallace, V. L., y Chan, P. (1984): The Human Factors of Computer GraphicsInteraction Techniques [Los factores humanos de las tcnicas de interaccin de grficas decomputacin] IEEE COMPUTER GRAPHICS AND APPLICATIONS, 4(11) pag. 13-48.

22

Ingeniero de Software Cuestiona la Autenticidad de las Pruebasde Software del Robot Asesino

La Indagacin de un Profesor de la Universidad de Silicon Valley ProvocaSerios Cuestionamientos Legales y ticos

Especial para el SENTINEL-OBSERVER DE SILICON VALLEY


El caso del robot asesino dio un giro significativo ayer cuando un profesor de la Universidad deSilicon Valley present un informe en donde cuestiona la autenticidad de las pruebas que fueronhechas por Silicon Techtronics al software del rtobot asesino. El Profesor Wesley Silber,Profesor de Ingeniera de Software, dijo en una conferencia de prensa realizada en la universidadque los resultados de las pruebas reflejados en los documentos internos de Silicon Techtronics noconcordaban con los resultados de las pruebas obtenidos cuando l y sus colegas ensayaron elsoftware real del robot.

Silicon Valley an est reaccionando por el anuncio del Profesor Silber, que podra jugar un papelimportante en el juicio a Randy Samuels, el programador de Silicon Techtronics que fue acusadopor homicidio no premeditado en el ahora infame incidente del robot asesino. Presionada por sureaccin por el informe del Profesor Silber, la Fiscal Jane McMurdock reiter su confianza en queel jurado encontrar culpable a Randy Samuels. Sin embargo, la Fiscal Jane McMurdockimpresion a los periodistas cuando agreg pero, esto en verdad promueve la posibilidad denuevas acusaciones.

Ruth Whiterspoon, la vocero del Comit de justicia para Randy Samuels, tambin estuvoexultante cuando habl a este peridico. McMurdock no puede tener ambas cosas. O elprogramador es el responsable por esta tragedia o se deber hacer responsable a la gerencia porello. Creemos que el informe de Silber exhonera a nuestro amigo y colega Randy Samuels.

El gerente Ejecutivo de Silicon Techtronics Michael Waterson hizo la siguiente tibia declaracinsobre el informe de Silber:

Tan pronto se anunci la acusacin de Randy Samuels personalmente le ped a un estimadoingeniero de software, el Dr. Wesley Silber, que llevara a cabo una indagacin objetiva sobre losprocedimientos de aseguramiento de la calidad en Silicon Techtronics. Como gerente ejecutivo deeste proyecto, siempre he insistido en que la calidad es lo primero, a pesar de lo que hayan podidoleer en los peridicos.

Le ped al profesor Silber que condujera una investigacin objetiva de todos los aspectos deaseguramiento de la calidad de Silicon Techtronics. Promet al Profesor Silber que tendra acceso atoda la informacin relevante a esta infortunada situacin. Le dije en una reunin frente a frente enmi oficina que deba proseguir la investigacin hasta su final sin importar a donde terminara, sinimportar las implicancias.

23

Basndome en la informacin que yo reciba de mis gerentes, nunca se me ocurri que hubiera unproblema de que los procedimientos de aseguramiento de la calidad fueran ya sea dbiles odeliberadamente alterados. Quiero asegurarle al pblico que la o las personas responsables de estafalta en el aseguramiento de la calidad del software dentro de la Divisin Robtica de SiliconTechtronics sern exhortados a encontrar trabajo en otro lado.

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. Samuelscondenado por lo que le hizo a mi marido. No entiendo de dnde viene toda la conmocin. Elhombre 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 enel campo de ingeniera de software y aseguramiento de la calidad del software. Comenzamos laentrevista pidiendo al Profesosr 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 complejoscreados por la mente humana, explic el Profesor Silber sentado frente a un monitor de grandesdimensiones. En algn momento un programa de computacin est en uno de los tantos estadosposibles, y hay una imposibilidad prctica de asegurar que el programa se comportar comocorresponde en cada uno de esos estados. No tenemos el tiempo suficiente para hacer tal tipo deprueba exhaustiva. De modo que usamos estrategias de prueba o heursticas que muyprobablemente encontrarn los errores o bugs, si es que existe alguno.

El Profesor Silber ha publicado numerosos papers sobre ingeniera de software. Estuvo en laprimera plana cuando el ao pasado public su lista de Aerolneas a Evitar Si su Vida Dependierade Ello. Esa lista enumeraba las aerolneas de cabotaje que l consideraba irresponsables por sucompra 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 gerenteEjecutivo de Silicon Techtronics, Michael Waterson, pidi al Profesor Silber que condujera unarevisin objetiva de los procedimientos de aseguramiento de la calidad de Silicon Techtronics. Laintencin de Waterson era contrarrestar la mala publicidad de su empresa luego de las acusacionesde Samuels.

El Aseguramiento de la Calidad se refiere a aquellos mtodos que usa un especialista dedesarrollo de software para asegurar que el software es confiable, correcto y robusto. Estosmtodos se aplican a todo lo largo del ciclo de vida de desarrollo del producto de software. En cadaetapa se aplican los mtodos de aseguramiento de calidad adecuados. Por ejemplo, cuando unprogramador escirbe cdigo, una medida de aseguramiento de calidad es probar el cdigoconfrontndolo 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 unprograma que busca patrones sospechosos en los programas, patrones que podrian indicar un erroro bug.

Estas dos formas de aseguramiento de calidad son denominadas pruebas dinmicas y pruebasestticas, respectivamente.

24

El software consiste de componentes discretos o unidades que eventualmente se combinan paracrear un sistema ms grande. Las unidades mismas deben ser probadas, y este proceso de pruebaindividual de las unidades es llamado prueba unitaria. Cuando las unidades se combinan, se debenprobar 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 procedimientosde prueba de software y de hacer pblicos mis hallazgos. Mike pareca confiado, tal vez debido alo que le haban dicho sus gerentes, en el sentido de que no encontraran nada malo en losprocedimientos de aseguramiento de calidad de Silicon Techtronics.

Luego de arribar a Silicon Techtronics, el Profesor Silber centr su atencin en los procedimientospara ensayo dinmico de software en la compaa.

Ayudado por un grupo de graduados, el Profesor Silber descubri una discrepancia entre elcomportamiento real de la seccin del cdigo del programa (escrito por Randy Samuels) que causque el robot Robbie CX30 matara a su operador, y el comportamiento segn se lo registr en ladocumentacin de pruebas de Silicon Techtronics. Este descubrimiento en realidad fue hecho porSandra Henderson, una estudiante graduada en ingeniera de software que est completando sudoctorado con el Profesor Silber. Entrevistamos a la Sra. Henderson en uno de sus laboratorios decomputacin para egresados en la Universidad de Silicon Valley. Encontramos un problema en laprueba de la unidad, explic la Sra. Henderson. Ac estn los resultados de la prueba, que nosdio el Sr. Waterson en Silicon Techtronics, que se supone estn hechos para cdigo C [lenguaje deprogramacin] que Randy Samuels escribi y que caus el incidente del robot asesino. Comopuede ver, todo est claramente documentado y organizado. Hay dos juegos de prueba: uno basadoen una prueba de caja blanca y otro en una prueba de caja negra. Basndonos en nuestros propiosestndares para probar software, estos juegos de prueba estn bien diseados, completos yrigurosos. La prueba de caja negra implica ver la unidad de software (o sus componentes) comouna caja negra que tiene comportamientos predecibles de input y output. Si en el juego de prueba elcomponente demuestra los comportamientos esperados para todos los inputs, entonces pasa laprueba. Los juegos de prueba estn diseados para cubrir todos los comportamientosinteresantes que una unidad podra mostrar pero sin tener conocimiento alguno sobre laestructura o naturaleza del cdigo en realidad. La prueba de caja blanca implica cubrir todos lospasos posibles a travs de la unidad. As, la prueba de caja blanca se hace con vasto conocimientode la estructura de la unidad. En la prueba de caja blanca, el juego de prueba debe causar que cadasentencia del programa se ejecute por lo menos una vez de modo que ninguna quede sin serejecutada.

Sandra Henderson prosigui explicando el significado de la prueba de software. Ni la prueba decaja blanca ni de caja negra prueban que un programa est correcto. No obstante, los probadoresde software, tales como los que se emplean en Silicon Techtronics, pueden volverse bastanteexpertos en el diseo casos de prueba para descubrir nuevos bugs en el software. La actitudapropiada es que una prueba es exitosa cuando se encuentra un bug. Bsicamente, el probador leda un juego de especificaciones y hace lo mejor de s para demostrar que el cdigo que estprobando no satisface sus especificaciones, explic la Sra. Henderson.

La Sra. Henderson luego mostr a este reporter los resultados de las pruebas que ella en verdadobtuvo cuando corri el cdigo crtico del robot asesino usando los juegos de prueba de lacompaa, tanto para ensayo de caja blanca como de caja negra. En muchos casos, los resultadosregistrados en los documentos de prueba de la compaa no fueron los mismos que los generadospor el verdadero cdigo del robot asesino.

25

Durante su entrevista de ayer con el SENTINEL-OBSERVER, el Profesor Silber discuti ladiscrepancia. Ver, el software que en verdad fue entregado junto con el robot Robbie CX30 nofue el mismo que el que supuestamente fue probado, por lo menos de acuerdo con estosdocumentos!. 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 sugierevarias posibilidades. Primero, el proceso de prueba de software, por lo menos para esta partecrtica del software, fue falseado deliberadamente. Todos sabemos que hubo una enorme presinpara tener listo a este robot en una fecha determinada. Otra posibilidad es que hubo una ciertadificultad en la versin de la gerencia en Silicon Techtronics, en cuanto a que el cdigo correctofue verdaderamente escrito, y probado con xito, pero en el producto entregado se insert el cdigoequivocado.

Solicitamos al Profesor Silber que explicara que quera decir con versin de la gerencia. En unproyecto 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 teneralgn tipo de mecanismo para tener control de las versiones de los componentes de software en unproyecto tan complejo como este. Tal vez el probador de software prob una versin correcta delcdigo de dinmica del robot, pero en realidad se entreg una versin equivocada del mismo. Noobstante, 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 cdigoasesino hubiese sido pasado por el proceso de prueba de un modo honesto, el robot nunca hubieseasesinado a Bart Matthews. Entonces, la pregunta es, qu pasaba en Silicon Techtronics que nopermiti una prueba honesta del cdigo crtico?

El SENTINEL-OBSERVER pregunt al Profesor Silber si estaba de acuerdo con el concepto deque la interfaz del usuario fue la primordial culpable en este caso. No creo en el argumento queesgrime mi colega, el Profesor Gritty, de que toda la culpabilidad en este caso pertenece aldiseador 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 interfazdel usuario como la ltima lnea de defensa contra el desastre. Esto es, ellos saban que haba unproblema, 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 hacanen cuanto que nunca debera haber aceptado la designacin de Waterson para conducir unainvestigacin objetiva del accidente. Las crticas sealan que la Universidad de Silicon Valley, y enparticular el Profesor Silber, tenan muchos intereses comunes con Silicon Techtronics, y de esemodo no poda ser elegido para conducir una investigacin objetiva.

Pienso que mi informe habla por s mismo, replic el Profesor Silber, visiblemente molesto pornuestra pregunta. Ya les he dicho a ustedes los periodistas una y otra vez que no se trat de unainvestigacin gubernamental sino de una interna de la corporacin, de modo que creo que SiliconTechtronics tena el derecho de elegir a quien se le ocurriera. Creo que yo les resultaba una personacon integridad.

26

Ayer tarde, Sam Reynolds, el gerente de Proyecto del CX30 contrat a una abogada, ValerieThomas. La Sra. Thomas hizo estas declaraciones en favor de su cliente:

Mi cliente est escandalizado de que alguien de Silicon Techtronics haya podido engaar alProfesor 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 quehaba algo que no funcionaba en el software de dinmica del robot. Sin embargo, el Sr. RayJohnson, el superior inmediato de mi cliente en Silicon Valley, decidi que el robot fuera entregadoa 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 elSr. Johnson, el riesgo de falla era muy pequeo y el costo por demorar ms la entrega del robot eramuy alto. Segn mi cliente, el Sr. Johnson crey que las condiciones del medio ambiente quepodra llegar a disparar un comportamiento errtico y violento del robot eran extremadamenteimprobables de ocurrir. An ms, el Sr. Johnson crey que el operador del robot no podra estar enpeligro debido a que la interfaz del usuario fue diseada de modo de permitir al operador detener elrobot fijo en sus guas en el caso de un movimiento del robot que comprometiera la vida deloperador.

El Sr. Johnson, Jefe de la Divisin Robtica de Silicon Techtronics, no pudo ser ubicado paraobtener sus comentarios. Randy Samuels ser juzgado el mes entrante en la Corte de SiliconValley. Cuando se lo contact por telfono, Samuels deriv todas las preguntas a su abogado, AlexAllendale.

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 conla esperanza de que su cdigo fuera probado exhaustivamente. Desconoca hasta el momento deque saliera a la luz el informe del Profesor Silber, que el cdigo involucrado en esta terribletragedia no haba sido probado adecuadamente o que los resultados de prueba pudieran haber sidofalsificados.

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 sentidascondolencias a la Sra. Matthews y a sus hijos.

3Teora Ivory Snow

27

Empleado de Silicon Techtronics Admite Falsificacin de lasPruebas del Software

Mensajes Tomados del Correo Electrnico Revelan Nuevos Detalles en elCaso del Robot Asesino

Una Asociacin de Computadores Cientficos Lanza una Investigacinsobre Violaciones al Cdigo de tica

Especial para el SENTINEL-OBSERVER DE Silicon Valley


Cindy Yardley, una probadora de software de Silicon Techtronics, admiti hoy que ella fue lapersona que cre las pruebas de software fraudulentas del robot asesino. Las pruebasfraudulentas fueron reveladas a principios de esta semana por el profesor Wesley Silber de laUniversidad 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 cdigodel programa escrito por Randy Samuels, el programa acusado por asesinato no premeditado en elincidente del robot asesino. El Informe Silber afirma que los resultados de las pruebas reflejados endocumentos internos de Silicon Techtronics son inconsistentes con respecto a los resultados de laspruebas 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 Seguridadde Silicon Techtronics, el Sr. Max Worthington, en una conferencia de prensa que fue transmitidaen vivo por CNN y otros informativos.

Worthington sacudi a los periodistas cuando comenz su conferencia de prensa con el anuncioYo 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. Porextranjeros quiero significar adversarios de otras corporaciones. Mi papel era ms que nada dedireccin. 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 oque 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. Estosvolmenes representan tan solo algunos de los relevamientos electrnicos de empleados que yo hicea 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 tipode requisa electrnica. No obstante, creo que la evidencia muestra que algunos empleadossospechaban que esto poda estar pasando.

28

Varios periodistas preguntaron a los gritos quin en Silicon Techtronics estaba al tanto de estarequisa.

Worthington respondi. Nadie saba de esto a excepcin del Sr. Waterson y yo, y uno de misasistentes que era el responsable de en verdad conducir el monitoreo. Mi asistente produca uninforme especial, resumiendo toda la actividad por E-mail de la semana, y ese informe era para quelo viera Waterson y yo solamente. Si se lo solicitaba, mi asistente poda dar un recuento msdetallado de las comunicaciones electrnicas.

Worthington explic que estaba poniendo a disposicin de la prensa las transcripciones del correoelectrnico porque quera que saliera a luz toda la verdad sobre Silicon Techtronics y el incidentedel robot asesino.

Los mensajes de E-mail entre empleados de Silicon Techtronics en verdad revelaron nuevas facetasdel caso. Un mensaje de Cindy Yardley al Jefe de Divisin Robtica, Ray Johnson, indica que ellafalsific a su pedido los resultados de las pruebas. Ac est el texto del mensaje:a: Ray Johnsonde: Cindy Yardleyre: Software de Samuels

Termin de crear los resultados de las pruebas de software para esesoftware problemtico, segn tu idea de usar una simulacin en vez delsoftware propiamente dicho. Adjunto encontrars el documento de pruebamodificado, 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 electrnicopoda no ser seguro:En respuesta a: Cindy Yardleyde: Ray Johnsonre: Software de Samuels

Saba que podra contar contigo. Estoy seguro de que tu dedicacin aSilicon Techtronics te ser pagada con creces. Por favor, en el futurous un medio de comunicacin ms seguro cuando discutimos este tema. Teaseguro que el modo en que manejamos esto fue completamentetransparente, pero yo tengo mis enemigos ac mismo en la propiaSiliTech.

Ray.

Estas comunicaciones fueron intercambiadas justo unos das antes que se enviara el robot RobbieCX30 a Cybernetics Inc. Este hecho es importante porque las pruebas de software falsificadas nofueron parte de un encubrimiento en el incidente del robot asesino. Estos hechos parecen indicarque el propsito de falsificar las pruebas de software era asegurarse de que el robot Robbie CX30fuera entregado a Cybernetics, Inc. en la fecha que fue negociada entre Silicon Techtronics yCybernetics.

Las transcripciones del correo electrnico revelan que hubieron repetidos mensajes de Ray Johnsona diferentes personas en el sentido de que la Divisin Robtica iba a ser cerrada definitivamente siel proyecto Robbie CX30 no era completado en trmino. En uno de los mensajes, diserta con sulder de proyecto, Sam Reynolds, acerca de la Teora Ivory Snow.

29

a: Sam Reynoldsde: Ray Johnsonre: no seas un perfeccionista!

Sam:

T y yo hemos tenido nuestras diferencias, pero debo decirte quepersonalmente me caes bien. Por favor entiende que todo lo que hago escon el propsito de SALVAGUARDAR TU TRABAJO Y EL TRABAJO DE TODOS ENESTA DIVISIN. Yo te veo a t y a toda la gente que trabajan para m enla Divisin Robtica como mi familia.Waterson fue claro: quiere tener el proyecto del robot completado entrmino. Y punto. Entonces, no tenemos otro recurso ms que el de IvorySnow. Sabes lo que quiero decir con eso. No tiene que ser perfecto. Lainterfaz del usuario es nuestro respaldo si esta versin del softwarepara el robot tiene algunas fallas. El operador del robot va a estarseguro porque podr cancelar cualquier movimiento del robot en cualquiermomento. Concuerdo contigo en cuanto a que los requerimientos nofuncionales son en algunas partes demasiado vagos. Lo ideal sera quesi estos no fueran tiempos de apuros, cuantificramos el tiempo que lellevara al operador detener el robot en un caso de accidente.Sin embargo no podemos renegociar esto ahora. Como tampoco tenemostiempo para disear requerimientos no funcionales nuevos y ms precisos.No puedo enfatizar suficientemente de que estos son tiempos deapurarse. A Waterson no le cuesta nada deshacerse de toda la DivisinRobtica. Sus amigos del Wall Street slo le van a decirFelicitaciones!. Vers, para Waterson nosotros tan slo somos delmontn.

Ray.

En este mensaje Ray Johnson parecera estar menos preocupado por la seguridad de comunicarsepor correo electrnico.

El SENTINEL-OBSERVER entrevist ayer por la tarde a Cindy Yardley en su propia casa. No sepudieron contactar ni a Ray Johnson ni a Sam Reynolds.

La Srta. Yardley estaba notoriamente ofuscada porque sus mensajes por E-mail fueran dados aconocer a la prensa. De alguna forma me siento aliviada. Sent una enorme culpa cuando esehombre 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 eleccintica 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 mepas. Estudi ciencias de la computacin en una universidad de gran nivel y all me ensearonsobre pruebas de software, pero jams me dijeron que alguien con poder sobre m me pediragenerar una prueba falseada!

Cuando Johnson me pidi que lo hiciera, me llam a su oficina, como para mostrarme las trampasdel poder; ver, algn da me gustara estar en un puesto gerencial. Me sent en su oficina y vinodirectamente y me dijo Quiero que falsifiques los resultados de las pruebas del software deSamuels. No quiero que Reynolds se entere de nada de esto.

30

Yardley contuvo las lgrimas. Me asegur de que probablemente nadie vera jams los resultadosde las pruebas dado que el robot era perfectamente seguro. Era tan slo una cuestin interna, untema de prolijidad, en caso de que alguien de Cybernetics o de un puesto alto dentro de lacorporacin le diera curiosidad de ver los resultados de las pruebas. Le pregunt si estaba segurode que el robot era seguro y todo eso y me dijo Es seguro! La interfaz del usuario es nuestra lneade defensa. En alrededor de seis meses podemos enviar una segunda versin del software del roboty 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 nfasisespecial. Entonces me dijo que si yo no falsificaba las pruebas, todos los de la Divisin Robticaperderan sus trabajos. Sobre esa base decid falsificar las pruebas, trataba de proteger mi trabajoy el de mis compaeros.

La Srta. Yardley est al presente cursando un grado de Maestra en Administracin de Empresasen la Universidad de Silicon Valley.

Luego el SENTINEL-OBSERVER pregunto a la Srta. Yardley si an senta que haba tomado unadecisin 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 elhecho 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 primeravez su software y dio resultados errneos:En respuesta a: Cindy Yardleyde: Randy Samuelsre: maldito si lo s

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

Randy.

Los expertos le dijeron al SENTINEL-OBSERVER que tomar software de paquetes comercialesde software como el PACKSTAT 1-2-3 es una violacin a la ley. El software tal como elinmensamente popular PACKSTAT 1-2-3 est protegido por el mismo copyright que protege almaterial impreso.

Mike Waterson, Presidente Ejecutivo de Silicon Techtronics, emiti una enojosa declaracinporque Max Worthington haba dado a conocer las transcripciones del correo electrnicoconfidencial. Las declaraciones de Waterson decan, en parte, que Yo le ped a nuestrosabogados que intervinieran en este tema. Consideramos que esas transcripciones son propiedadexclusiva de Silicon Techtronics. Nuestra intencin es efectuar cargos ya sea civiles o criminalescontra el Sr. Worthington.

Como reaccin a lo ocurrido ayer en el caso del robot asesino, la ACM o Association forComputer Machinery anunci su intencin de investigar si algn miembro de la ACM de Silicon

31

Techtronics ha violado el Cdigo de tica de la ACM. La ACM es una asociacin internacional decomputadores cientficos con 85.000 miembros.

La Dra. Turina Babbage, presidente de la ACM, hizo una declaracin en la Conferencia deCiencias de la Computacin de ACM que se lleva a cabo cada invierno y que esta temporada sehar 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 dela ACM [NOTA AL PIE: Un borrador de este cdigo fue dado a conocer en Comunicaciones de laACM, Mayo 1992. Por favor ntese que las declaraciones hechas por la ficticia Dra. Babbagecontienen citas del verdadero cdigo de ACM] Este cdigo establece, en parte, que los miembrosde 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 loscontratos, acuerdos y responsabilidades asignadas, y de dar evaluaciones profundas y completas delos sistemas de computacin y de sus impactos, poniendo especial nfasis en los riesgospotenciales.

Varias de las personas involucradas en el caso del robot asesino son miembros de la ACM y haycausas para creer que han incurrido en violacin del cdigo de tica de nuestra asociacin. Por lotanto, estoy solicitando al directorio de la ACM designar una Fuerza de Tareas para investigar alos 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 delrobot asesino no slo ha costado una vida humana, sino que ha causado mucho dao a lareputacin de la profesin de computacin.

32

La Revista Dominical del SENTINEL-OBSERVER - UnaConversacin con el Dr. Harry YoderporRobert Franklin

Harry Yoder es una figura muy bien conocida en el campo universitario de Silicon Valley. Elprofesor de Tecnologa y tica de la Computacin de Samuel Southerland ha escrito numerososartculos y textos sobre tica y el impacto social de las computadoras. Sus clases son muyfamosas, y muchos de sus cursos estn completos mucho antes de que finalice el perodo deinscripcin. El Dr. Yoder ha recibido su Doctorado en ingeniera elctrica del Instituto deTecnologa de Georgia en 1958. En 1976 recibi un grado en Maestra en Divinidad delHarvard Divinity School. En 1983 recibi un Master en Ciencias de la Computacin de laUniversidad de Washington. Ingres en la facultad de la Universidad de Silicon Valley en 1988.

Entrevist al Dr. Yoder en su oficina del campus. Mi intencin era obtener su reaccin conrespecto al caso del robot asesino y leer su pensamiento sobre los temas ticos que involucra elcaso.

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 vidainterior, 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 enlo que hago. Es eso lo que lo llev a la Escuela de Divinidad de Harvard? Usted quera clarificarsu vida interior?

Yoder: Sucedan muchas cosas en la Escuela de la Divinidad, y muchas de ellas eran muypoderosas. Sin embargo, ms que nada yo quera comprender la diferencia entre lo que estaba bieny 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 todasellas tenan cosas interesantes que decir acerca de Dios. No obstante, cuando yo discuto sobre ticaen un foro tal como este, que es secular, o cuando discuto tica en mis cursos de tica en lacomputacin, no coloco a esa discusin en un contexto religioso. Pienso que la fe religiosa puedeayudarle a una persona a abrazar la tica, pero por otra parte, todos sabemos que ciertaspersonalidades notorias que se han autopronunciado religiosas han sido altamente no ticas. Deeste 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 elluchar por la excelencia tica es una tarea humana que vale la pena. Por lo menos, lo que noqueremos es herir a otros, no queremos mentir, robar, hacer trampas, asesinar, etc.

SENTINEL-OBSERVER : Quin es el responsable de la muerte de Bart Matthews?

33

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 profesorera un hombre mayor, tal vez de setenta aos, de la Europa Oriental, un rabino. Este rabino dijoque de acuerdo al Talmud, una tradicin antigua de la ley juda, si se derrama sangre inocente enun pueblo, entonces los lderes de ese pueblo deben ir a los lmites del mismo y realizar un acto depenitencia. Esto

Robot Asesino

Documents

Transcript of Robot Asesino