¡Descarga Análisis del Caso del 'Robot Asesino' en Silicon Techtronics y más Apuntes en PDF de Ingeniería solo en Docsity!
In Inggeenniieerrííaa ddeell SSooffttwwaarree II
Gu Guííaass
Tr Traabbaajjooss PPrrááccttiiccooss
IN INGGEENNIIEERRIIAA DDEE SSOOFFTTWWAARREE II
PPrrooffeessoorreess: D:Drr..^ RaRammoonn^ GGaarrccííaa MMaarrttíínneezz
Dr Dr.. DDaarriioo RRooddrriigguueezz
Mg Mg.. HHeerrnnáánn AAmmaattrriiaaiinn
AAyyuuddaanntteess::^ LiLicc..^ SaSannttiiaaggoo BBiiaannccoo
Li Licc.. SeSebbaassttiiaann MaMarrttiinnss
Es Espp.. EEzzeeqquuiieell BBaallddiizzzzoonnii
Índice
- Guía de Trabajo práctico 1: Ciclo de Vida ("El Robot Asesino") Pág.
- Guía de Trabajo Práctico 2 : Diagramas de Flujo de Datos (DFDs) Pág.
- 2.1. Ejercicio 1: Títulos Pág.
- 2.2. Ejercicio 2: Gestoría "Placente, Gancedo y CIA." Pág.
- 2.3. Ejercicio 3: Distribuidora "Su Remedio" Pág.
- 2.4. Ejercicio 4: Comprador Frecuente Pág.
- 2.5. Ejercicio 5: Laboratorium Pág.
- 2.6. Ejercicio 6: Ticketronn Pág.
- 2.7. Ejercicio 7: Comunicación Pág.
- 2.8. Ejercicio 8: Demoras Pág.
- 2.9. Ejercicio 9: MacMickey Pág.
- 2.10. Ejercicio 10: Administración de Alumnos Pág.
- 2.11. Ejercicio 1 1 : Importac Pág.
- 2.12. Ejercicio 1 2: Circ_Event Pág.
- 2.13. Ejercicio 1 3: Rascacie Pág.
- 2.14. Ejercicio 1 4: Sargo Pág.
- Guía de Trabajo práctico 3 : Diagramas de Entidad Relación (DER) Pág.
- 3.15. Ejercicio 1 5 : Películas para completar Pág.
- 3.16. Ejercicio 1 6 : Peluquería 1 Pág.
- 3.17. Ejercicio 1 7 : Banco Pág.
- 3.18. Ejercicio 1 8 : Proyecto Pág.
- 3.19. Ejercicio 1 9 : Rayo Pág.
- 3.20. Ejercicio 20 : Banco Mar Pág.
- 3.21. Ejercicio 2 1: Administración de Actas de Finales Pág.
- 3.22. Ejercicio 22 : Gerox Pág.
- 3.23. Ejercicio 23 : DER Completo Pág.
- 3.24. Ejercicio 24 : Editoriales Pág.
- 3.25. Ejercicio 2 5 : Buques Pág.
- 3.26. Ejercicio 26 : Becas RCI Pág.
- 3.27. Ejercicio 27 : Taller Pág.
- 3.28. Ejercicio 28 : Peluquería 2 Pág.
- Guía de Trabajo práctico 4: Diseño de Sistemas OO Pág.
Vale aclara que este punto y el texto donde se caracterizan los personajes de la historia no se deben utilizar como texto de análisis.
Este artículo fue utilizado por Richard G. Epstein. “El uso de escenarios sobre ética de la computación en la educación de Ingeniería del Software: el caso del robot asesino.” Enseñanza de Ingeniería de Software: Anticipo de la 7ma. Conferencia SEI CSEE, San Antonio. Jorge L. Díaz-Herrera, editor. Notas del discurso en Computer Science 750. Springer-Verlag 1994.
1.2. LOS INVOLUCRADOS
El caso del robot asesino consta de nueve artículos publicados en periódicos, un artículo de un jornal y de una entrevista publicada en una revista. Esta historia intenta llamar la atención sobre tópicos de ética en la computación y en la ingeniería de software.
Las personas e instituciones involucradas en esta historia son enteramente ficticias (excepto por las referencias a las Universidades de Carnegie-Mellon y Purdeue y a los venerables computadores científicos Ben Shneiderman y Jim Foie). Se eligió Silicon Valley para la ubicación del accidente debido a que éste es un icono de la alta tecnología. Todas las personas e instituciones nombradas en Silicon Valley son ficticias.
La caracterización de los personajes:
Alex Allendale , Abogado, contratado para defender a Randy Samuels.
Jan Anderson , programadora y analista de Silicon Techtronics. Se oponía al uso del modelo de
cascada en el proyecto del robot y fue despedida por ser honesta.
Turina Babbage , presidente de la Association for Computing Machinery (ACM). Anuncia que
ACM realizaría una investigación sobre violaciones al Código de ética de la ACM por parte de los empleados de Silicon Techtronics.
Robert Franklin , periodista del SENTINEL-OBSERVER de Silicon-Valley. Entrevistó al Profesor
Harry Yoder para conocer la visión de un experto en ética sobre la evolución del caso del robot asesino. La entrevista fue publicada en la revista dominical del SENTINEL- OBSERVER.
Horace Gritty , Profesor de Ciencias de la Computación.
Sandra Herdenson , estudiante reciba en la Universidad de Silicon Valley. Coperó en la
investigación sobre procedimientos de aseguramiento de la calidad en la Universidad de Silicon Valley.
Ray Jonson , Jefe de División Robótica en Silicon Techtronics. La División Robótica necesitaba un
robot exitoso.
Marta , fuente anónima de un periódico. Una persona interna de Silicon Valley que dio al
SENTINELA-OBSERVER información sobre la dinámica de grupo del proyecto del robot Robbie CX30.
Bart Matthews , operador del robot. Un programa de computación con defectos causo que el
robot Robbie CX30 lo matara.
Roberta Matthews , viuda de Bart.
Jane McMurdock , Fiscal de la Ciudad de Silicon Valley. Fue quien incrimina a Randy Samuels
con los cargos de asesinato no premeditado.
Mabel Muckraker , periodista del Silicon Valley Sentinel Observer. Fue designada a la historia
del robot asesino por su reputación de eficaz reportera investigadora.
Bill Park , profesor de física de la Universidad de Silicon Valley. Confirmo que Randy Samuels
malinterpreto las ecuaciones de la dinámica del robot.
Randy Samuels , programador. Escribió el código del programa que causó que el robot Robbie
CX30 oscilara con gran amplitud, matando a su operador, Bart Matthews.
Sam Reynolds , Gerente del proyecto del CX30, Ray Johson era su superior inmediato. SU
experiencia fue adquirida en el campo del procesamiento de datos, pero fue puesto al mando del proyecto CX30, muy a su pesar. Estaba a favor de aplicar el modelo de cascada del desarrollo del software.
Robbie CX30 , el robot. Robbie jamás tuvo un mal pensamiento hacia nadie, aún así se torno un
salvaje asesino.
Wesley Silber , profesor de Ingeniería del Software en la Universidad del Silicon Valley. Condujo
una revisión e los procedimientos de aseguramiento de la calidad en Silicon Techtronics.
Sharon Skinner , profesora de psicología en la Universidad de Silicon Valley. Veía a Randy
Samuels como una persona aplicada a su tarea, susceptible por demás a las criticas.
Valeria Thomas , abogada, contratada por Sam Reynolds.
Michael Waterson , presidente y presidente ejecutivo de Silicon Techtronics. Puso a Sam
Reynolds a cargo del proyecto Robbie CX30 como una medida para recortar gastos. Contribuyo generosamente a la campaña de reelección de James McMurdock. Contrato al Dr. Silber para llevar adelante una investigación sobre aseguramiento de calidad en Silicon Techtronics.
Max Worthington , jefe de seguridad de Silicon Techtronics. Monitoreaba la comunicación
electrónica entre los empleados y así descubrió a Cindy Yardley.
Ruth Whiterspoon , analista y programadora vocera del comité “Justicia para Randy Samuels”.
Defendía a Randy Samuels sobre la base que Silicon Techtronics estaba legalmente obligada a entregar un robot confiable y seguro.
Cindy Yardley , empleada y probadora de software de Silicon Techtronics. Admitió la
falsificación de las pruebas de software con el fin de resguardar el puesto de trabajo de sus compañeros.
Harry Yoder , profesor de tecnología de computación y ética. Examino, en una entrevista
publicada en la revista dominical del SENTINEL – OBSERVER, la tensión entre las responsabilidades individuales y corporativas.
1.3. LOS ARTICULOS
1.3.1. Articulo 1- 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 acusación de Randy Samuels con los cargos de asesinato no premeditado. Samuels trabajaba como programador en Silicon Techtronics, Inc., una de las empresas mas nuevas de Silicon Valley en la arena de la alta tecnología. El cargo involucra la muerte de Bart Matthews, quien fuera muerto el pasado mes de mayo por un robot de la línea de armado.
Matthews, quien trabajaba como operador de robot en Cybernetics, Inc., en Silicon Heights, fue aplastado y murió como consecuencia de ello, cuando el robot que estaba operando produjo un malfuncionamiento y comenzó a oscilar su “brazo” violentamente. El brazo del robot alcanzó a Matthews, arrojándolo contra una pared y aplastando su cráneo. Matthews murió en forma casi instantánea en un caso que conmocionó e indignó a muchos en Silicon Valley. De acuerdo con el dictamen de 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 fórmula manuscrita, suministrada por el físico del proyecto, que se suponía que tenía que programar Samuels. Pero negligentemente malinterpretó la formula, y esto llevó a una horrible muerte. La sociedad debe protegerse de los programadores que comenten errores descuidadamente o de lo contrario nadie estará a salvo, y menos que nadie nuestra familia e hijos”, dijo:
De acuerdo con documentos provistos por Marta al SENTINEL – OBSERVER, el 12 de julio del año pasado fueron agregados al proyecto Robbie CX30 veinte nuevos programadores. Esto ocurrió días después de la tomentosa reunión entre Jonson y Reynolds que Marta contó.
De acuerdo a Marta, los nuevos contratados eran un desastre. “Jonson, unilateralmente, hizo los arreglos de estas contrataciones, seguramente desviando recursos de otros aspectos del proyecto Robbie (CX30). Reynolds se oponía con vehemencia a esto. Jonson solo conocía acerca de la fabricación del hardware. Esa era su especialidad. No pudo haber entendido de las dificultades que nosotros estamos teniendo con el software de la robótica. Usted no puede acelerar un proyecto de software agregando mas gente. No es como una línea de montaje”.
Según Marta y otras fuentes, la contratación de estos nuevos veinte programadores llevó a que se hiciera una reunión entre Johson, Reynolds y todos los integrantes del proyecto de software de Robbie CX30. “Esta vez fue Sam (Reynolds) el que se puso furioso. Se quejó de que el proyecto no necesitaba más gente. Sostuvo que el problema principal era que Jonson y otros miembros a nivel directivo no entendían que el Robbie CX30 era fundamentalmente diferente a otras versiones anteriores del robot”. Estas fuentes dijeron al SENTINEL – OBSERVER que los nuevos empleados no estaban totalmente integrados al proyecto, aún seis meses después de su ingreso, cuando diez robots Robbie CX30, incluido el robot que mato a Bart Matthews, ya habían sido despachados. Según Marta, “Sam solo quería mantener las cosas lo mas simples posible. No quería que el nuevo personal complicara las cosas”. “Se pasaron seis meses leyendo manuales. La mayoría de los empleados nuevos no sabia nada de robots y Sam no estaba como para perder tiempo tratando de enseñarles”. Según Marta, la reunión del 12 de junio se hizo famosa en la corporación Silicon Techtronics porque fue en esa reunión donde Ray Jonson anuncio su “Teoría Ivory Snow *“no existe el blanco perfecto, o bien, no hay más blanco que el blanco nieve”+ de diseño y desarrollo de software”. De acuerdo a Marta, “Ray (Johson) nos dio una gran presentación en multimedia, con diapositivas y todo. La esencia de esta “Teoría Ivory Snow” es simplemente que el blanco nieve es 99,44 % puro y que no hay razón por la que el software de robótica deba ser más puro que esto. Dijo repetidas veces que “El software perfecto era un oximoron”.
Marta y otros personajes anónimos que se acercaron con información, retrataron a Jonson 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 por naturaleza y nadie esperaba que fueran éxitos comerciales. De hecho, la División Robótica de Silicon Techtronis estaba operando con sus finanzas en rojo desde su concepción 6 años atrás. O triunfaba el CX30 o Silicon Techtronics quedaría fuera del negocio de robótica industrial. “Los robots Robbie anteriores tuvieron mucha prensa, especialmente aquí en Silicon Valley”, dijo otra fuente que también quiere permanecer anónima. “Robbie CX30 iba a capitalizarse con la buena publicidad generada por los proyectos anteriores. Lo único es que Robbie CX30 era mas revolucionario de lo que Jonson quería admitir. CX30 representaba un paso gigante hacia delante en términos de sofisticación. Había muchísimas preguntas acerca de los parámetros industriales en los que debería trabajar el CX30. Mucho de lo que debía ejecutarse era completamente nuevo, pero Jonson nunca lo pudo entender. Él solo nos veía como unos perfeccionistas. Uno de sus dichos favoritos era ‘La perfección es enemiga de lo bueno’”.
1.3.3. Articulo 3 - Los compañeros acusan: “El programador del `Robot Asesino´ era una estrella”
Especial para el SENTINEL – OBSERVER de Silicon Vallley. Silicon Valley, EEUU por Mabel Muckraker
Randy Samuels, el que fuera el 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 difícil aceptar criticas, aseguraron hoy varios compañeros de trabajo.
En una rueda de prensa con varios compañeros de trabajo de Samuels en el proyecto del “robot asesino”, el SENTINEL – OBSERVER pudo obtener importantes revelaciones acerca de la psiquis del hombre que pudo haber sido criminalmente responsable de la muerte de Bart Matthews, operador de robot y padre de 3 criaturas.
Con el permiso de los entrevistados, el SENTINEL – OBSERVER permitió a la profesora Sharon Skinner del Departamento de Psicología de Software en la Universidad de Silicon Valley, escuchar una grabación de la entrevista. La profesora Skinner estudia la psicología de los programadores y otros factores psicológicos que tienen impacto en el proceso de desarrollo del software.
“Estaría de acuerdo con la mujer que lo llamó “prima donna””, explicó la profesora Skinner. “Este es un término utilizado para referirse a un programador que simplemente no puede aceptar las críticas, o más precisamente, no puede aceptar su propia falibilidad.”
“Randy Samuels tiene lo que nosotros, psicólogos 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 esta muy densamente involucrado en su trabajo. En el mundo de la programación esto se considera “no, no”, agregó la profesora Skinner en su oficina tapizada en libros.
La profesora Skinner continuó explicando algunos hechos adicionales sobre equipos de programación y personalidades del programador. “Básicamente, hemos encontrado que un buen equipo de programación requiere de una mezcla de personalidades, incluyendo a una persona que esté orientada hacia la interacción, que saca una enorme satisfacción del hecho de trabajar con otra gente, alguien que pueda ayudar a mantener la paz y a que las cosas se muevan en una dirección positiva. Muchos programadores están orientados hacia lo que es la tarea, y esto puede ser problemático si se tiene un equipo donde son todos de este modo”.
Los compañeros 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 la personalidad de Samuels y sus hábitos laborales, surgieron varios hechos importantes. Samuels trabajaba en un equipo formado aproximadamente por una docena de analistas, programadores y probadores de software. (Esto no incluye a 20 programadores que fueron incorporados posteriormente y que nunca llegaron a estar activamente involucrados en el desarrollo del software de la robótica). Si bien cada individuo del equipo poseía una especialidad, casi todos están comprometidos en todo el proceso del software del principio al fin.
“Sam Reynolds tenía un background en el procesamiento de datos. Dirigió unos cuantos proyectos de software de esta naturaleza”, dijo uno de los integrantes del equipo, refiriéndose al gerente del proyecto Robbie CX30. “Pero su rol en el proyecto era mas que nada de líder. Asistía a todas las reuniones importantes y lo mantenía a Ray (Ray Jhonson jefe del Departamento de robótica) sobre nuestras espaldas lo mas posible”. Sam Reynolds, como ya fuera informado en el SENTINEL – OBSERVER de ayer, se encontraba bajo una severa presión para lograr producir un robot Robbie CX30 operativo para el 1° de enero de este año. Sam Reynolds no pudo ser ubicado para entrevistarlo ya sea sobre su rol en el incidente o sobre Samuels y sus hábitos de trabajo.
“Éramos un equipo democrático, a excepción del liderazgo provisto por Sam (Reynolds)”, observó otro miembro del equipo. En el mundo del desarrollo del software, un equipo democrático es un equipo en donde todos los miembros de este tienen un decir en el proceso de toma de decisiones. “Desafortunadamente, nosotros éramos un equipo de individualistas muy ambiciosos, muy talentosos – si debo referirme a mi mismo – y muy opinadores. Randy (Samuels) era justo el peor del grupo. Lo que quiero decir es que teníamos, por ejemplo, a dos chicos y una chica con grados de maestría de la CMU1 , y no eran tan arrogantes como Randy.”
(^1) CMU significa Universidad de Carnegie – Mellon, una líder nacional en enseñanza de Ingeniería del Software.
En el modelo de prototipo, se pone un gran énfasis en producir un modelo de prototipo bien temprano durante el ciclo de vida del sistema. El prototipo es construido con el propósito de arribar a una especificación final de la funcionalidad del sistema propuesto. Los usuarios potenciales pueden interactuar con el prototipo en forma temprana y con frecuencia hasta que son acordados los requerimientos. Este enfoque le da 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é diseñado y codificado.
En un memorando de fecha 11 de diciembre del anteaño pasado, Jan Anderson, miembro del equipo original del proyecto CX30, ataco duramente la decisión tomada por el gerente del proyecto Sam Reynolds de emplear el modelo en 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 después de que ella escribiera el memo.
El memo de Anderson hace referencia a una reunión anterior en la que ocurrió un fuerte intercambio de opiniones relacionadas con la filosofía del desarrollo del software.
En el memo, Anderson subrayó el siguiente párrafo:
“No fueron mis intenciones impugnar su competencia durante la reunión 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 negocio. El proyecto Robbie CX30 llevará un alto grado de interacción, tanto entre robot y componentes como entre robot y su operador. Dado que la interacción del operador con el robot es tan importante, la interfaz no puede estar diseñada como una idea de último momento”. Randy Samuels, a quien se lo acuso de asesinato no premeditado por la muerte de Bart Matthews, padre de 3 niños, había participado de la reunión del 11 de diciembre.
En una conservación con este diario, Anderson dijo que Samuels no tenía mucho que decir sobre la controversia cascada – prototipo, pero sí afirmó que daría “una mano” con tal de que exoneraran a Samuels.
“El proyecto fue sentenciado a muerte mucho antes de que Samuels malinterpretara las fórmulas”, aclaró Anderson enfáticamente en la sala de su casa en los suburbios. En conversación con este diario, Anderson hizo lo mejor de sí para explicar la controversia del método cascada vs. prototipo en términos simples. “El punto principal en realidad era si podíamos llegar a ponernos de acuerdo con los requerimientos del sistema sin dejar que los operadores del robot presintieran lo que teníamos en mente. Reynolds ha estado en el negocio del procesamiento de datos por tres décadas y es bueno en eso, pero nunca debería haber sido gerente de este proyecto”.
Conforme a registros obtenidos por el SENTINEL – OBSERVER, Silicon Techtronics, Michael Waterson. Reynolds reemplazaba a John Cramer, quien gerenciaba al anterior proyecto Robbie CX10 y CX20. Cramer fue puesto a cargo del proyecto CX30, pero murió inesperadamente en un accidente aéreo. Al colocar a Reynolds a cargo del proyecto CX30, nos dice nuestra fuente, que Waterson iba en contra del consejo de Ray Jonson, jefe de la División de robótica. De acuerdo con estas fuentes, Jonson se oponía fuertemente a la alternativa de ponerlo a Reynolds como jefe del proyecto Robbie CX30. Estas fuentes dijeron al SENTINEL
- OBSERVER que la elección de Waterson por Reynolds fue puramente una decisión de recorte de gastos. Era más barato transferir a Reynolds a la División robótica que incorporar a un nuevo líder de proyecto de fuera de la corporación.
La fuente anónima que el SENTINEL – OBSERVER llamará “Marta” describió la situación de este modo: “Waterson pensaba que sería mas barato transferir a Reynolds a robótica antes que intentar encontrar afuera un nuevo gerente para el proyecto Robbie. Además, Waterson tendía a sospechar de la gente de
afuera del grupo. Con frecuencia mandaba memos sobre cuánto 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 de robótica como un gerente y no como un experto técnico. Claramente, Reynolds se veía a sí mismo tanto gerente como experto técnico. Reynolds no tenia conciencia de sus propias limitaciones técnicas”.
Según Marta, Reynolds era muy renuente a gerenciar proyecto que no usaran el modelo de cascada que tan bien le había servido en el procesamiento de datos. Tildó al modelo prototipo como un “modelo de moda” en la reunión del 11 de diciembre, y después de una serie de intercambios verbales la cosa se puso muy personal.
“Anderson estaba especialmente expresiva”, recuerda Marta. “Tenía mucha experiencia con interfaces con usuarios y desde su perspectiva, la interfaz robot – operador era crítica para el éxito del CX30, dado que la intervención del operador seria frecuente y a veces crítica”. En su entrevista con el SENTINEL – OBSERVER, Jan Anderson comentó sobre el aspecto de la reunión del 11 de diciembre:
“Reynolds estaba en contra de “perder el tiempo” – para usar sus propias palabras – con cualquier tipo de análisis formal de las propiedades de los factores humanos y su interfaz con el usuario. Para él, la interfaz con el usuario real eran un tema periférico”.
“Para él (Reynolds), cualquier cosa nueva era “moda”, agrega Anderson. “Las interfaces de las computadoras eran una moda, el diseño orientado a objetos era una moda, la especificación formal y las técnicas de verificación eran una moda, y por sobre todo, el modelo en prototipo era una moda”. Justo una semana después de la reunión del 11 de diciembre, el grupo de 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. “Análisis de requerimiento y especificación, luego diseño de arquitectura y diseño detallado, codificación, prueba, entrega y mantenimiento. En el modo de ver de Reynolds, no hacía falta tener ninguna interacción 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 uso a Robbie CX30 en una función 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 periódico. Como una gran ironía, 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 mismísimo robot Robbie CX30 que aplastó hasta tan solo dos meses después de la toma fotográfica.
1.3.5. Articulo 5 - Silicon Techtronics prometió entregar un robot seguro. Cuestionada la calidad del entrenamiento del operador.
Especial para el SENTINEL – OBSERVER de Silicon Vallley. Silicon Valley, 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”, distribuyo documentos que muestran que Silicon Techtronics se obligo a sí misma a hacer entrega de robots que “no causarían daño corporal a los operadores humanos”. Randy Samuels es el programador que ha sido acusado del asesinato infame del caso del “robot asesino”.
“No podemos entender como el Fiscal pudo acusar a Randy con esos cargos cuando, de hecho, la compañía 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 algún tipo de confabulación entre la gerencia de SiliTech (Silicon Techtronic) y la oficina del Fiscal. Michael Waterson era uno de los mas grandes contribuyentes de la campaña de reelección de la Sra. McMurdock
robot generados por el programa de Randy identificaron correctamente a esta condición excepcional y el operador del robot recibió el debido aviso de que algo andaba mal”.
Whiterspoon dijo que poseía una declaración formada de otro operador de robot de Cybernetics en donde afirmaba que las sesiones de entrenamientos ofrecidas por Silicon Techtronics nunca mencionaron a ésta ni a tantas otras condiciones excepcionales. Según Whiterspoon, el operador del robot ha jurado que ni a él ni a ningún otro operador de robots les fue dicho que jamás el brazo del robot podía oscilar violentamente.
Whiterspoon citó esta declaración en la conferencia de prensa. “Ni yo ni Bart recibimos entrenamiento para manejar este tipo de condición excepcional. Dudo mucho que Bart Matthews tuviese idea de que se suponía que debía hacer cuando la pantalla de la computadora comenzó a mostrar mensaje de error”.
Las condiciones excepcionales que requieren de la intervención del operador causan un mensaje de error que se genera en la consola del operador. La Policía de Silicon Valley afirmó que cuando Bart Matthews fue muerto, el manual de referencia en su consola estaba abierto en la página del índice que contenía los códigos de ingreso para “errores”.
Whiterspoon luego citó, secciones del documento de requerimientos que obligan a Silicon Techtronics (el vendedor) a entrenar adecuadamente a sus operadores:
“El vendedor suministrará cuarenta (40) horas de entrenamiento para los operadores. Este
entrenamiento cubrirá todos los aspectos de la operación del robot, incluyendo una cobertura exhaustiva que contenga potencialmente el riesgo de daño corporal. El vendedor proveerá y administrará instrumentos de prueba apropiados que serán usados para certificar el suficiente entendimiento del operador de las operaciones de la consola del robot y de los procedimientos de seguridad. Solo los empleados del cliente que hayan pasado estas pruebas estarán habilitados para operar el robot Robbie CX30 en una verdadera función industrial.
“El manual de referencia deberá suministrar instrucciones claras para la intervención del
operador en todas las situaciones excepcionales, especialmente e inclusive aquellas que contengan potencialmente el riesgo de daño corporal”.
Según Whiterspoon, las declaraciones juradas de varios operadores de robots de Cybernetics Inc., aseguran que solo se destino un día laborable (aproximadamente 8 horas) al entrenamiento de operadores. Es mas, casi no dedicó tiempo alguno al tratamiento de condiciones excepcionalmente peligrosas.
“La prueba escrita desarrollada por Silicon Techtronics para habilitar a un operador están considerada por los empleados de Cybernetics como un chiste”, aseguro Whiterspoon, “Obviamente Silicon Techtronics no le dedicó mucho tiempo al entrenamiento y procedimientos de pruebas obligatorios según el documento de requerimientos según la evidencia en nuestro poder”. Reimpreso con el permiso de ROBOTIC WORD el diario de ROBOTICS AND ROBOTICS APPLICATIONS.
1.3.6. Articulo 6 - La interfaz del “Robot Asesino”
Dr. Horace Gritty, Departamento de Ciencias de la Computación y materias relacionadas. Universidad de Silicon Valley, Silicon Valley, EEUU
Resumen: El robot industrial Robbie CX30 se suponía que debía restablecer un nuevo modelo de inteligencia de robots industriales. Desgraciadamente, uno de los primeros robots Robbie CX30 mató a un obrero de la línea de montajes, y esto llevó a la acusación de uno de los que desarrollaron el robot, Randy Samuels. Este paper promueve la teoría de que quien debería estar en juicio es el desarrollador de la
interfaz robot – operador. El robot Robbie CX30 viola casi todas las reglas del diseño de interfaz. Este paper se centra en como la interfaz del Robbie CX30 violó cada una de las “Ocho reglas de oro” de Shneiderman.
1. Introducción
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 investigación de los hechos del accidente guiaron a las autoridades a la conclusión de que un módulo de software, escrito y desarrollado por Randy Samuels, un programador de Silicon Techtronics, fue el responsable del comportamiento errático y violento que a su vez llevo a la muerte por decapitación a Bart Matthews
NOTA: Los medios de prensa manejaron la información haciendo creer que Bart Matthews había sido aplastado por el robot, pero la evidencia fotográfica dada a este autor muestra otra cosa. Tal vez, las autoridades trataban de proteger la sensibilidad pública.
Como experto en el área de interfases con el usuario (1, 2, 3), se me pidió prestar ayuda a la policía en la reconstrucción 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 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 precisión. Sobre la base de esta reconstrucción, llegué a la conclusión de que fue el diseño de la interfaz y no el imperfecto diseño del software lo que debería haber sido visto como el criminal en este caso. A pesar de mi descubrimiento, la fiscal Jane McMurdock insistió en proseguir el caso en contra Randy Samuels. Pienso que cualquier computador científico competente, dado una oportunidad de interactuar con el simulador del Robbie CX30, también habría concluido que el diseñador de la interfaz y no el programador debería haber sido acusado por negligencia, si no por homicidio no premeditado.
2. “Las ocho reglas de oro” de Schneiderman
Mi evaluación de la interfaz con el usuario del Robbie CX30 está basada en las “ochos reglas de oro” de Scheiderman (4), también utilicé otras técnicas para evaluar la interfaz, pero estas serán publicadas en papers separados. En esta sección ofrezco una breve revisión de las ocho reglas de oro de Scheiderman, un tema que resultará más familiar para los expertos en interfaces de computación como yo y no hackers de robótica que leyeron este oscuro periódico.
Las ocho reglas de oro son:
- Buscar siempre la coherencia. Tal como se puede ver mas abajo, es importante que una interfaz con el usuario sea coherente a muchos niveles. Por ejemplo, los diseños de pantalla deben ser coherentes de una pantalla a la siguiente. En un entorno en que se usa una interfaz grafica con el usuario (GUI), esto también implicará concordancia de un utilitario al siguiente.
- Permitirle a los usuarios frecuentes el uso de shortcuts. Los usuarios frecuentes (o,´power users´) pueden desalentarse ante tediosos procedimientos. Permitirles a estos usuarios un procedimiento menos tedioso para completar una tarea dada.
- Dar realimentación de información. Los usuarios necesitan ver las consecuencias de sus acciones. Si un usuario ingresa un comando pero la computadora no muestra yá lo que sea que esté procesando o lo que ha procesado, esto puede dejar al usuario confundido o desorientado.
- Diseñar diálogos 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 cuando una tarea esta finalizada. El usuario necesita tener la sensación de que la tarea ha alcanzado su término.
dialogo requiere de cierto tipo de interacción entre el operador y el sistema, por ejemplo resolver ciertos temas, como ser, ingresar cuál es el diámetro de un dispositivo dado a ser bajado en el baño de ácido.
El sistema de menús presenta una estricta jerarquía de elección de menús. El operador podría volver hacia atrás en esta jerarquía apretando la tecla de escape. Esta tecla escape también podría terminar los diálogos. El uso del color en la interfaz fue muy poco profesional, había 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 solo quince minutos de usos. Hubo uso excesivo de efectos musicales tontos y falsees cuando se ingresaba opciones o códigos erróneos.
Uno debería preguntarse por qué Silicon Techtronics no intentó un enfoque mas sofisticado para el diseño de interfaz. Luego de un cuidadoso estudio del dominio de los utilitarios del Robbie CX30, he llegado a la conclusión de que una interfaz de manipulación directa, que mostrara literalmente al robot en la consola del operador, habría sido lo ideal. El entorno tan visual dentro del cual operaba el robot se prestaba naturalmente al diseño de metáforas de pantallas apropiadas para ese entorno, metáforas que el operador podría entender con facilidad. Esto permitiría que el operador manipulara el robot mediante el manejo, en la consola del robot, de la representación grafica del robot en su entorno. He solicitado a unos de mis estudiantes en el doctorado, Susan Farnsworth, que investigará un poco más 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 las reglas de oro en diferentes modos. En este paper sólo trataré unas pocas instancias de violaciones de reglas, dejando la discusión más detallada para futuros artículos y mi próximo libro.
NOTA:. CODEPENDENCIA, Cómo los Usuarios de Computadoras permiten deficientes Interfaces con el Usuario, Angst Press, Nueva York. Este libro presenta una teoría radicalmente nueva con respecto a la relación entre la persona y la máquina. Esencialmente, algunas personas necesitan una interfaz de mala calidad a los fines de evitar ciertos problemas psicológicos no resueltos en sus vidas.
Lo que haré es destacar esas violaciones que fueron relevantes en este accidente en particular:
Buscar siempre la coherencia: En la interfaz del usuario de Robbie CX30 hubieron muchas
incoherencias. Los mensajes de error podían aparecer en casi cualquier color y podían estar acompañados por casi cualquier tipo de efecto musical. Además, los mensajes de error podían aparecer en casi cualquier lugar de la pantalla. Cuando Bart Matthews vio el mensaje de error de la condición excepcional que ocurrió luego, la cual requería la intervención del operador, es probable que fuera esa la primera vez que veía ese mensaje en especial. Además, el mensaje de error apareció en un cuadro verde, sin ningún efecto de sonido. Este es el único mensaje de error de todo el sistema que aparece en verde y sin ningún tipo de acompañamiento de orquesta.
Permitir que los usuarios frecuentes utilicen shortcuts: Este principio no aparece de ningún modo en
todo el diseño de la interfaz. Por ejemplo, hubiera sido una buena idea permitir que los usuarios frecuentes pudieran ingresar la primera letra de la opción de un submenú o menú en lugar de requerírseles el uso de las teclas del cursor y luego la tecla “enter” para elegir esa opción determinada. El mecanismo de selección de menús de este mismo sistema debe haber provocado al operador bastante fatiga mental. Es más, debería haberse permitido algún tipo de sistema de tipeo 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.
Ofrecer realimentación de información: 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 además por las inconsistencias en el diseño de la interfaz con el usuario. En algunos casos al operador se le da una realimentación 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 algún tipo de realimentación y por
consiguiente se queda confundido cuando está no se le da. En la pantalla, no hay una representación visual del robot y su entorno, y la visión que tiene el operador del robot a veces está obstruida.
Diseñar diálogos que tengan fin: Hay muchos casos en los que una secuencia dada de tecleado
representa una idea holística, una tarea completa, pero al operador se lo deja sin el tipo de realimentación que le confirmare que la tarea ha sido en efecto completada. Por ejemplo, hay un dialogo bastante complicado que se necesita cuando se quiere sacar un elemento de un baño de ácido. Sin embargo, luego de completar este dialogo, el usuario es llevado a otro dialogo nuevo, y no relacionado con este, sin que se les informe que el dialogo anterior ha finalizado.
Ofrecer manejo simple de los errores: El sistema pareciera estar diseñado para que el usuario se
lamentara por cualquier ingreso erróneo. No sólo el sistema permite numerosas oportunidades para el error, sino que cuando un error en realidad ocurre, es probable que se repita por algún tiempo. Ello se debe a que la interfaz con el usuario, fue diseñada en forma tal que corregir el error era una odisea tediosa, frustrante y a veces enfurecedora. Algunos de los mensajes de error eran directamente ofensivos y condescendientes.
Permite deshacer las acciones con facilidad: Como se menciona en el párrafo anterior, la interfaz con el
usuario hace muy difícil la tarea de deshacer entradas erróneas. En general, el sistema de menús permite deshacer fácilmente las acciones, pero esta filosofía no alcanza para el diseño de los cuadros de diálogos y al manejo de condiciones excepcionales. Desde un punto de vista práctico (opuesto al teórico), la mayoría de las acciones son irreversibles cuando el sistema está en un estado de condición excepcional, y esto ayudó a llegar a la tragedia del robot asesino.
Promover que uno sea el centro del robot: Muchas de las deficiencias tratadas en los párrafos
precedentes disminuyeron la sensación de “tener el control”. Por ejemplo, no recibir información, no poder concluir con las interacciones, no permitir deshacer con facilidad las acciones en el momento que surgen las excepciones, todas estas cosas actúan para disminuir la sensación de que el usuario posee el control sobre el robot. Hubieron muchas características 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 diseño de interfaz hubiera hecho transparente la interfaz con el usuario y le hubiere dado al operador del robot la sensación de estar en contacto directo con el mismo. En un caso, le ordené al robot mover un elemento desde el baño de ácido hasta la cámara de secado y pasaron 20 segundos antes de que el robot pareció responder. De este modo, no tuve la sensación de estar controlando al robot. Tanto la repuesta demorada del robot como la falta de realimentación en la pantalla de computadora, me hicieron sentir que el robot era un agente autónomo, la verdad un sentimiento como mínimo perturbador.
Reducir la carga de memoria de corto plazo: Un sistema que se maneja por medio de menús es
generalmente bueno en términos de carga de memoria que crea a los usuarios. No obstante, hay gran variación entre implementaciones particulares de sistemas de menú en lo que hace a carga de memorias. La interfaz con el usuario de Robbie CX30 tenía menúes muy grandes sin ninguna organización interna. Esto crea una gran carga al operador en términos de memoria y también en términos de tiempo de búsqueda, el tiempo que lleva al operador ubicar una opción determinada del menú.
Muchas pantallas de dialogo requerían que el usuario ingresara con el teclado números de partes,
nombre de archivos, y otra información. El sistema podría haberse diseñado fácilmente de forma de mostrarle al usuario estos números de partes, etc., sin la necesidad 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, increíble como pueda parecer ¡no había ninguna
instalación de ayuda en línea o sensible al contexto!. Si bien he ido a los cursos de entrenamientos ofrecidos por Silicon Techtronics, muchas veces me encontré navegando por los manuales de referencia para poder encontrar la respuesta aún a las más básicas preguntas, tales como: “¿Qué significa esta opción de menú? ¿Qué pasa si selecciono esta opción?”.
5. Una reconstrucción 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
del robot llevado a cabo utilizando las ochos reglas de oro de Schneiderman, el experto en diseño de interfaces ha arribado a la conclusión de que el diseñador de la interfaz y no el programador fue la parte mas culpable en este desafortunado evento.
7. Referencias
Gritty, Horace (1990). The only user interface book you´ll ever need. Vanity Press, Oshkosk, WI
212 pag. [El único libro sobre interfaz de usuarios que Usted necesitara].
Gritty, Horace (1992). What we cant learn from the killer robot [Lo que podemos aprender de
un robot asesino], charla dada en el Simposio internacional de la Universidad de Silicon Valley sobre Seguridad en robot e Interfaces de usuario, Marzo de 1991. también por aparecer en las Notas de los alumnos de la Universidad de Silicon Valley].
Gritty, Horace (se espera para 1993). CODEPENDENDY: How computer users enable poor user
interfaces, Angst press, New York [Como los usuarios de computadoras permiten interfaces deficientes].
Shneiderman, Ben (1987), Designing the user interface, Addison Wesley, reading MA, 448 pag
[Diseño de Interfaces].
DOCUMENTO DE REQUERIMIENTOS DEL ROBOT INDUSTRIAL INTELIGENTE Robbie CX30:
versión de Cybernetics INCS., Documento Técnico N° 91-0023XA, Silicon Techtronics Corporation Silicon Valley, USA 1245 pag.
Foley, J. P., Wallace, V. L., y Chan, P. (1984): The human factors of computer graphics
interaction techniques [Los factores humanos de las técnicas de interacción de graficas de computación] IEEE COMPUTER GRAPHICS AND APPLICATIONS, 4(11) pag, 13-48.
1.3.7. Artículo 7 - Ingeniero de software cuestiona la autenticidad de las pruebas de software del “Robot Asesino”. La indagación de un profesor de la Universidad de Silicon Valley provoca serios cuestionamientos legales y éticos.
Especial para el SENTINEL – OBSERVER de Silicon Vallley. Silicon Valley, EEUU 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 que cuestiona la autenticidad de las pruebas que fueron hechas por Silicon Techtronics al software del “robot asesino”. El profesor Wesley Silber, profesor de Ingeniería del 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 aún está reaccionando por el anuncio del Profesor Silber, que podría 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 reacción por el informe del profesor Silber, la fiscal Jane McMurdock reiteró su confianza en que el jurado encontrara culpable a Ray Samuels. Sin embargo, la Fiscal Jane McMurdock impresionó a los periodistas cuando agregó “pero, esto en verdad promueve la posibilidad de nuevas acusaciones”.
Ruth Whirterspoon, la vocero del “Comité de justicia para Randy Samuels”, también estuvo exultante cuando habló a este periódico. “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 del Silber exonera a nuestro amigo y colega Randy Samuels”. El gerente Ejecutivo de Silicon Techtronics Michael Waterson hizo la siguiente tibia declaración sobre el informe de Silber:
“Tan pronto se anunció la acusación de Randy Samuels personalmente le pedí a un estimado ingeniero
del software, el Dr. Wesley Silber, que llevara a cabo una indagación 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 periódicos”.
“Le pedí al profesor Silber que condujera una investigación objetiva de todos los aspectos de
aseguramiento de la calidad de Silicon Techtronics. Prometí al profesor Silber que tendría acceso a toda la información relevante a esta infortunada situación. Le dije en una reunión frente a frente, en mi oficina, que debía proseguir la investigación hasta su final sin importar a donde terminara, sin importar las implicancias”.
“Basándome en la información que yo recibía de mis gerentes, nunca se me hubiera ocurrido que
pudiesen existir problemas de que los procedimientos de aseguramiento de la calidad fueran, ya sea débiles, o estuviesen alterados. Quiero asegurarle al publico que la o las personas responsables de esta falta de aseguramiento de la calidad del software dentro de la División de Robótica de Silicon Techtronics serán exhortados a encontrar trabajo en otro lado”.
Roberta Matthews, viuda de Bart Matthews, el operador del robot que fue muerto en el incidente, habló telefónicamente desde su casa con el SENTINEL – OBSERVER. “Aún quiero ver al Sr. Samuels condenado por lo que le hizo a mi marido. No entiendo de dónde viene toda la conmoción. EL hombre que asesinó a mi esposo, debería 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 raíz de su trabajo en el campo de Ingeniería del 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 más complejos creados por la mente humana”, explico el profesor Silber sentado frente a un monitor de grandes dimensiones. “En algún momento un programa de computación está en uno de los tantos estados posibles, y hay imposibilidad práctica 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 heurísticas que muy probablemente encontrarán los errores o bugs, si es que existe alguno”.
El profesor Silber ha publicado numerosos papers sobre Ingeniería del Software. Estuvo en la primera plana cuando el año pasado publicó su lista de “Aerolíneas a evitar si su vida dependiera de ello”. En esa lista se enumeraban las aerolíneas de cabotaje que él consideraba irresponsables por su compra de aviones que están controladas casi por completo por software de computación.
Poco tiempo después 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 revisión objetiva de los procedimientos de aseguramiento de la calidad de Silicon Techtronics. La intención 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 métodos que usa un especialista de desarrollo de software para asegurar que el software es confiable, correcto y robusto. Estos métodos se aplican a todo lo largo del ciclo de vida de desarrollo del producto de software. En cada etapa se aplican los métodos de aseguramiento de calidad adecuados. Por ejemplo, cuando un programador escribe código, una medida de aseguramiento de la calidad es probar el código confrontándolo en verdad con los datos de prueba. Otro método sería correr programas especiales, llamados analizadores estáticos, confrontándolos con el nuevo código. Un analizador estático es un programa que busca patrones sospechosos en los programas, patrones que podrían indicar errores o bug.
