El Papel del Modelado en la Transformación de los Requisitos en Software

No nos digamos mentiras: desarrollar software es notoriamente difícil e impredecible. Muchos proyectos de software son cancelados, terminan tarde y sobre-presupuestados o tienen una calidad bastante deplorable.

Para justificar los continuos errores que cometemos proyecto tras proyecto en materia de calidad, de entrega a tiempo y de presupuesto establecido (Recursos + Talento Humano), muchos de nosotros nos amparamos en el hecho de que la Ingeniería de Software es una ciencia muy nueva, si la comparamos con ciencias milenarias como la medicina o la arquitectura, y nos decimos a nosotros mismos y a los demás que esto del desarrollo de software es un “arte” más que una ciencia o una disciplina.

Pero y hasta cuándo vamos a esperar para convertir nuestro trabajo de “artistas” en trabajo de profesionales del desarrollo de software?

Precisamente, para que el Desarrollo de Software se convierta en una disciplina de la Ingeniería del Software debe saltar por encima de un conjunto de paradigmas que ha justificado la mediocridad patibularia en la que nos hemos postrado desde siempre.

Uno de ellos es el del Modelado. Si bien es cierto que el producto primordial de un proyecto no son artefactos como documentos de todo tipo, formateados, coloreados, estandarizados, ni consignas de grandeza o empuje (El Trabajo Dignifica al Ser Humano!), ni miles de líneas de código en el lenguaje más rebuscado o de moda, sino un magnífico fruto de software que plasme las necesidades muchas veces caprichosas (léase cambiantes) de los usuarios, el modelado de software constituye una pieza fundamental de todo ese engranaje que es el ciclo de vida del desarrollo, puesto que nos guía por un camino más o menos correcto hacía la generación de un buen sistema de información y es el que permite producir los accesorios correctos (documentos, código fuente, etc.)

Hoy día estamos gastando mucho más tiempo en corregir código que no funciona o presenta un mal comportamiento porque se hizo sin haber adquirido el conocimiento del sistema en construcción, en vez de gastar ese mismo tiempo en entenderlo a través de modelos que nos hubieran permitido además visualizar y controlar no solo la arquitectura de ese sistema, sino los mayores riesgos potenciales, los componentes a reutilizar y, en general, la funcionalidad del software, el objetivo final.

Y a todas estas, ¿qué es un modelo? Algunos de ustedes creerán que los estoy tomando del pelo, pero si les cuento que durante quince años he hecho esa pregunta en conferencias y cursos “especializados” en materia de desarrollo de software y que las respuestas que he recibido de mis estudiantes son bastante imprecisas (a veces son totalmente mudas…), aceptarán que no estoy bromeando.

Pues bien, un modelo es una representación (simple) de la realidad. Representación en el sentido de grafía, forma. Simple en el sentido de escueto, desnudo. Realidad en el sentido de contexto, situación.

Aquí la palabra clave es “simple”. Si la realidad, los requisitos establecidos por nuestros usuarios, es compleja, deberíamos abordar el modelado dividiendo el conjunto de requisitos en subconjuntos de requisitos más simples (los subconjuntos, no los requisitos) y si todavía tenemos “conjunticos” complejos, seguiremos fragmentándolos hasta obtener los agregados (“humanamente”) más simples.

¿Qué les explique cómo es el asunto? Bueno, el problema que encontramos a diario quienes nos hemos atrevido a “modelar” (software) es que tratamos de modelar todos los requisitos al tiempo, o una gran porción de ellos; sin embargo, en los últimos tiempos he encontrado que manejar estos requisitos por raciones más asequibles al conocimiento “humano” trae mejores beneficios, construimos entonces esos modelos más simples, modelos que a su vez son sistemas, sistemas que a su vez cumplen con los requisitos de los usuarios, ¡el ciclo vital! (Tengo que confesarlo, eso se lo debo también al excelente equipo de desarrolladores y arquitectos de software con los que he tenido la oportunidad de compartir proyectos durante estos años).

Y puesto que un modelo es un sistema, todo sistema se caracteriza por determinados parámetros que le aportan una descripción dimensional bien definida. Estos parámetros son:

1. Entrada o insumo o impulso (“input”).

2. Salida o producto o resultado (“output”).

3. Procesamiento o procesador o transformador (“throughput”).

4. Retroalimentación o retroinformación (“feedback”) o alimentación de retorno.

5. Ambiente.

El detalle de cada una de estas características está por fuera del alcance de este ensayo. Lo que sí puedo decirles es que estos parámetros son el pilar cardinal de lo que se ha dado en llamar “Primer Principio de Desarrollo de Software”, principio que, a la postre, si todos lo seguimos, transformará de arte en disciplina al desarrollo de software, un principio con el que podamos definir muy pronto un “patrón de diseño universal” que nos guíe a través del diseño de software y que le dé a los modelos el papel y la importancia que realmente tienen y no el de “irrelevante” como muchos creíamos hasta hoy.

Ahora bien, muchos pensamos que el estudio del modelado empezaba con conocer a fondo un lenguaje de modelado como UML (en Gazafatonario IT ya inicié una labor de publicación de artículos sobre el tema, y estos finalmente servirán para profundizar y entender mejor lo que aquí expongo), no obstante, primero era necesario saber que es un modelo y para qué sirve; teníamos un escenario enfermizo.

Bueno, este es un intento por aliviar esa situación.

Luis Antonio Salazar Caraballo

Medellín, julio 15 de 2003

Visiones

Gazafatonario IT

Visiones

“En primer lugar existió el Caos. Después Gea (Tierra), la de amplio pecho, sede siempre segura de todos los Inmortales que habitaban la nevada cumbre del Olimpo. En el fondo de la tierra de anchos caminos existió el tenebroso Tártaro (infierno griego). Por último, Eros (dios del amor), el más hermoso entre los dioses inmortales, que afloja los miembros y cambia de todos los dioses y todos los hombres el corazón y la sensata voluntad en sus pechos.”

El Origen del Universo Según la Mitología Griega

Parece irónico echar una mirada al pasado, aunque sea un pasado de fábula, para hablar de las visiones que tengo de un futuro probable. Aunque es cierto que nadie puede inventar el futuro, podemos, desde el punto de vista de la tecnología y la ciencia, tratar de saber cómo será el universo que habitaremos en 20 años, en 50 años, en mil años. Al menos, podemos imaginar como será, podemos crear la mitología del futuro.

¿Hacía dónde nos llevará la tecnología? Especialmente la Tecnología Informática. ¿Podremos esperar, a largo plazo, que el PC desaparezca y que el acceso a la informática esté en todas partes? ¿Podremos esperar que los computadores, en vez de convertirse en los demonios rapaces que aparecen en películas como Terminator, se conviertan en elementos tan pequeños, omnipresentes y tan poderosos que desaparezcan de la vista humana?

Algunos seres, humanos por supuesto, de esos que tienen el don poco frecuente de combinar la capacidad técnica en bruto con el virtuosismo artístico y creativo, como Mark Weiser, célebre director del Xerox PARC, padre de la Computación Ubicua y que muriera en 1999, creen que así será la vida en el futuro cercano. Weiser se basó en la teoría de que la desaparición es una consecuencia fundamental no de la tecnología sino de la psicología humana; siempre que la gente aprende algo suficientemente bien, deja de ser consciente de ello. ¿Tendría Weiser la razón? El tiempo nos lo dirá.

Entre tanto, el resto de los no tan Inmortales habitantes de la Tierra (de esa Gea que nos enseñaron los antiguos griegos), debemos prepararnos para abordar ese futuro complejo y lleno de dilemas a partir del mejor uso de la tecnología. Hoy vivimos para la tecnología, la estamos creando. Mañana, deberemos ser capaces de usarla, de ser mejores personas cada vez. Sí, quizás dejemos de ser, sin hacer ningún ruido, los seres más brillantes de esta Tierra, pero quizás también, podremos ser capaces de desencadenar poderosas fuerzas que podrían elevar nuestra civilización hacía el siguiente estado de la vida, uno en el que todas las culturas confluyan y donde la comunicación sea el pilar de la existencia. Hablo de una comunicación que sea comprendida por unos y por otros (seres humanos), una en la que, como dijo Einstein, la mayor parte de las ideas fundamentales de la ciencia sean esencialmente sencillas y por regla general puedan ser expresadas en un lenguaje comprensible para todos (quizás entonces pueda responder a mi hija Pamela, hoy de tan solo 6 años, la pregunta que me hizo sobre si clonar el Tilacino era lo mismo que clonar un computador, refiriéndose a un programa de TV que vimos juntos acerca de las posibilidades de clonación del Tigre de Tasmania y de su computador Clon con el que juega ávidamente a escaparse de Dursley junto a Harry Potter).

Seguramente habrá más intentos de configurar el mundo y modificar la personalidad humana, tal como hoy lo hacemos con la Interfaz Gráfica de nuestro PC, para crear un modelo de vida autoelegido, y eso entrañará muchas consecuencias inexploradas. También, como hoy, el destino humano continuará siendo una empresa aventurada y, en algún instante impredecible la naturaleza contraatacará, volviéndonos a recordar que desde siempre vivimos en un hogar configurado por ella.

Sin embargo, más allá de toda ciencia y tecnología, más allá de toda concepción filosófica o dogmática (o mitológica) que trate de ofrecer una respuesta a la trama humana, nuestro espíritu seguirá inquieto… y expectante.

Estas son algunas de mis visiones, quería compartirlas con ustedes. Ahora volvamos a temas más terrenales.

Pero ustedes también pueden compartir sus propias visiones escribiéndome a lucho.salazar@gmail.com.

Luis Antonio Salazar Caraballo

Medellín, junio 27 de 2003