Informática y Sistemas (β)

2009/12/16 - 16 diciembre 2009

Las delicadas etapas de definiciones en proyectos de sistemas

Filed under: Filosofía y Sistemas de Información — Mario Mendez @ 15:08
Tags: ,

Caso de Uso UML

La disciplina de Sistemas Informáticos está asimilada a una rama de la Ingeniería, pero las principales diferencias con las carreras tradicionales (Ingeniería Civil, Química o Arquitectura) son su poca antigüedad, y en especial la alta incidencia del factor humano al momento de definir los proyectos. Este último tiene una importancia especial dado que puede llegar a ser causal de proyectos abortados con la consiguiente pérdida de tiempo y recursos.

Por ejemplo, una obra de ingeniería cómo puede ser la construcción de un puente, hoy en día no solo tiene la suficiente base técnica y estudios previos para asegurar su fin exitoso, sino también que difícilmente se llegue a la situación de definir erróneamente la ubicación o expectativas de utilización que tendrá. Sin embargo, en el campo de la informática lamentablemente no es poco común encontrarse con proyectos que no cumplen las expectativas o que las necesidades nunca quedan establecidas claramente y persistan cambios hasta la entrega, dejando obsoleto el producto desde su mismo inicio. Existen innumerables ejemplos que van desde sistemas operativos (¿alguien recuerda al BOB?) hasta aplicaciones ofimáticas y web, la mayoría de las veces de iniciativa privada de las organizaciones.  

Son varios los factores que inciden como riesgo, pero en especial los problemas de definiciones en las etapas de levantamiento (entrevistas y evaluación de requerimientos), y en cierta medida también las definiciones de diseños, son los puntos débiles que tienen este tipo de proyectos. Uno de los peligros ya lo analicé en extenso en mi artículo sobre la incidencia de la metonimia y el problema del lenguaje en la interpretación de las necesidades; pero además se suma otro riesgo en cierto modo emparentado respecto a la comunicación y definición consensuada.

En efecto, la herramienta principal en proyectos informáticos son las definiciones previas; las que muchas veces no tienen más antecedentes que la experiencia del actor entrevistado para establecer los requerimientos. Además de la posible falta de criterio formal por parte de este actor para expresar su definición, o reconocer la que interpreta el profesional de sistemas a partir de su entrevista; existe el peligro de que las premisas o entes que se suponen conocidos por las partes, no sean tales. La percepción de la realidad que tienen los actores puede diferir notablemente en aspectos técnicos, dado los ambientes diferentes en los que realizan sus actividades y la propia formación de cada uno. Para compensar esto se puede caer en el error de comenzar a definir la base de cada definición, en un círculo vicioso de definiciones que terminarán en una pérdida de tiempo y pérdida total del enfoque.

En este sentido, el caso relacionado más extremo lo tenemos en la figura de René Descartes, filósofo que inició una rama moderna llamada cartesianismo, pero sin duda en el prólogo de su Discurso del Método explica la forma en que aislado y evidentemente marcado por las consecuencias de una guerra que vivió pudo encontrar un sentido en que creer ignorando todo lo asimilado por sus sentidos los que considera al estilo de Platón solo percepciones indirectas del mundo real, y partiendo de razonamientos puramente lógicos reconstruye un sistema de realidad redefiniéndolo y que lo devuelve al mundo. Este caso plantea la base del existencialismo (llevado al extremo por Jean Paul Sartre) y que se constituye en piedra fundamental junto al método científico que aplicadas a diferentes ciencias intentan definir y aprehender la realidad desde la lógica pura. Sin embargo, tras estas construcciones sólidas, la búsqueda de la definición básica sobre la que se fundamentan siempre lleva a entes o simples postulaciones que se consideran válidas solo por el sentido común y que no admiten más predefiniciones que su sola existencia. Hasta la matemática y la geometría basan sus desarrollos en entes tan simples que no se pueden demostrar y se aceptan tal cuál constituyendo sus axiomas.

La teoría de sistemas incluye técnicas que permiten acotar este modelado de la realidad estableciendo los límites por un lado, y alcance por el otro. Sin embargo el profesional responsable del diseño no tiene lineamientos claros para establecer la profundidad de las definiciones que realiza, por lo que debe establecer cuáles serán las postulaciones axiomáticas del sistema; y que en definitiva serán aquellas proposiciones elementales establecidas con el (buen) criterio suficiente como para ser consensuadas. Pero el caso es que estos axiomas son en sí mismos estructuras de mayor o menor complejidad que tienen un fuerte riesgo de no tener la misma interpretación por todos los actores involucrados en los proyectos.

Asimismo, la etapa de diseño en la que debe documentarse la elaboración de los requisitos en un producto realizable también corre el riesgo de ser susceptible de definiciones recursivas por parte del equipo responsable del desarrollo. En efecto, muchas veces la arquitectura especificada por sus diseños (UML, DFD, etc.) es susceptible de generar más preguntas, en mayor medida cuanto menos experiencia y trabajo en conjunto tenga dicho equipo. Aunque esto es independiente de los casos en que un diseño deba ser acompañado de código ejecutable por necesidad interna del equipo de desarrollo, ya que esto excede los problemas de comunicación evidenciando otras falencias como falta de capacitación o competencia. Los puntos que intento destacar son la comunicación débil y la interpretación errónea de la visión esquemática de un diseño, justamente por ser una representación simbólica que implica ser decodificada; tratando de minimizar las divergencias entre el símbolo y su significante respecto al individuo que trabaje sobre el diseño.

Planteados estos puntos, aquí es fundamental rescatar que el nexo alrededor del cual giran estos riesgos es la figura del responsable de la toma de requerimientos y la del arquitecto o responsable del diseño; que si bien pueden estar representadas en el mismo equipo o actor por este hecho no se minimizan. Y esta es la razón principal de que existan dichos roles en los proyectos de sistemas informáticos; ya que el proceso de modelar un aspecto de la realidad para informatizarlo y solucionar problemas es un ejercicio en el que la comunicación juega un papel fundamental, y los criterios aplicados para establecer un consenso de definiciones y por consiguiente un consenso en lo requerido tanto desde el punto de vista funcional como de plazos, son la base necesaria para llevar adelante proyectos informáticos exitosos.

(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

Crea un blog o un sitio web gratuitos con WordPress.com.

A %d blogueros les gusta esto: