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