Informática y Sistemas (β)

2009/09/11 - 11 septiembre 2009

Metonimia y otras figuras semánticas que el profesional debe reconocer para realizar correctas definiciones de sistemas

primer bug documentado

primer bug documentado

Como introducción a este tema me gustaría comentar sobre los pocos glamorosos orígenes de la palabra “debug”, término muy conocido en la jerga informática como sinónimo de “depurar código” para eliminar fallos de software. Esta palabra deriva de “bug” que en inglés significa insecto, y generalmente se aplica a las cucarachas o baratas; por lo que debug vendría a ser desinsectar o quitar cucarachas. Ahora bien ¿qué tienen que ver estos animales tan desagradables con los programas de software? Existen algunos antecedentes de antiguas máquinas electromecánicas en base a relés (o relays) del siglo XIX cuyo funcionamiento se entorpecía precisamente porque los insectos se colaban en sus mecanismos. Pero su incorporación en el ambiente informático se remonta a los primeros computadores eléctricos de la década del 40 y 50, previos a la era de los semiconductores que ocupaban habitaciones enteras y consistían en paneles y circuitos con cientos de válvulas, bulbos o ampolletas de vacío (sí las mismas que se usaban en las radios a válvulas). Era muy común que en estos aparatos se produjeran fallos debidos a válvulas quemadas, pero gran parte de los fallos se debían a que las cucarachas y otros insectos menores se colaban entre las conexiones y producían cortocircuitos en los zócalos de las válvulas y empalmes descubiertos. Entonces, la gran tarea de esos pioneros programadores para corregir estos fallos era justamente limpiar de cucarachas los circuitos eléctricos, o hacer “debug”.

Hoy en día prácticamente se ha forzado al olvido vergonzoso la etimología del término, aunque la tarea de depuración de programas en sí lleva en general una cierta carga de antipatía, fastidio y rechazo por parte del programador, seguramente heredada en parte de estos orígenes. Pero lo más importante es el hecho de que este ejemplo, es el más representativo en el ambiente informático para ejemplificar el desplazamiento de significado o transnominación; lo que se conoce con el nombre de “metonimia”. El designar una cosa con el nombre de otra, con la que mantiene alguna relación. Esta figura lingüística literaria es muy común junto con la metáfora en prosa y poesía; pero el alcance de la metonimia en el lenguaje común o coloquial es el que aquí nos interesa. O sea que la vemos aquí desde el punto de vista de la semiótica, como símbolo que desplaza su significado desde un significante a otro; y que podemos ver una y otra vez en jergas de diferentes ambientes, utilizando en forma corriente términos que para alguien ajeno al ámbito pueda significar algo completamente distinto.

Los profesionales informáticos para poder realizar sus actividades, deben basarse tanto en conocimientos propios como otros que son parte inherente de los sistemas que desean modelar, y que pueden pertenecer a ámbitos tan diversos como los que hacen uso de ordenadores hoy en día (finanzas, salud, construcción, administración, etc.). Esto lleva a realizar mucho trabajo de investigación, no para convertirse en especialistas en estos ámbitos sino solo para poder solucionar un problema específico; y una parte importante de esta tarea de investigación la llevan las entrevistas a especialistas (personales o por cuestionarios); en lo que se conoce comúnmente como “toma de requisitos” o “levantamiento”.  En este conocimiento adquirido de primera mano, el lenguaje tiene un papel fundamental; y su buen manejo lo convierte en una herramienta definitiva para asegurar la calidad del modelado, diseño del sistema y la posterior construcción del software. Hay que tener en cuenta que cualquier diferencia menor en la interpretación de los requisitos se amplifica notablemente en las etapas posteriores, y la brecha entre lo que el usuario deseaba y lo que obtiene puede llegar a significar el rechazo del producto o una inversión de corrección más que importante. Las iteraciones constantes con los usuarios a través de las distintas etapas del ciclo de vida del proyecto pueden minimizar y corregir sobre la marcha muchos problemas, pero las correcciones deben ser mínimas para poder tener un desarrollo eficiente y rentable; para ello el foco de la correcta interpretación de la toma de requisitos es un punto que el responsable no debe descuidar y para el que debe estar capacitado.

Y el principal enemigo como pueden adivinar a estas alturas es la metonimia; responsable muchas veces de que los encargados de tomar requisitos y arquitectos diseñadores de sistemas ante sucesivas modificaciones y rechazos de sus productos concluyan livianamente en juicios como “el cliente no sabe lo que quiere”, “no tengo un buen interlocutor”; o desde el punto de vista del destinatario del sistema pierda la confianza en el analista porque “no entiende del asunto”. La gran mayoría de los casos, se trata principalmente de dificultad de comunicación, precisamente en la falta de manejo del lenguaje por parte del analista, ya que del usuario o cliente del sistema no se puede pretender que sea más que una persona que sabe hacer sus actividades y necesita una solución, aunque no sepa expresar con corrección cual son las mismas. Y gran parte de las veces, el analista debe ir más allá de la definición literal que reciba; tratando de interpretar tanto o más lo que el entrevistado quiso decir en mayor medida de lo que realmente dijo. Y justamente las iteraciones podrán guiar y ajustar la metainterpretación de las entrevistas, pero que bien realizadas aceleran notablemente los tiempos y foco de los diseños minimizando los desvíos. Partiendo de entrevistas y diseños de calidad es donde se encuentran los desarrollos de mejor rentabilidad, y lo más importante es que el usuario tiene mejor predisposición a acompañar y adoptar los sistemas desarrollados, cuando realmente resuelven el problema que tienen; y no el que decían tener. En este sentido, y en base a mi experiencia profesional, muchas veces este gap lleva a replantear las condiciones de contratos, dado que el desarrollo de sistemas es también un tema comercial; y no pocas veces se termina desarrollando bajo estas renegociaciones un producto sensiblemente diferente al contratado inicialmente por el cliente; otro punto por el cual el detectar estos desvíos de lineamientos en etapa de levantamiento de requisitos es esencial para poder sentarse en una mesa de renegociación de condiciones sin perder esfuerzo y tiempo extras, que como de costumbre también significan costo económico y de prestigio.

(tiny)

Anuncios

Dejar un comentario »

Aún no hay comentarios.

RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: