de noviembre en La Nación habla de las cuantiosas sumas gastadas por instituciones estatales en software inadecuado. Los proveedores afirman que el software vendido se ajusta a los requerimientos del cartel. Como estamos en Costa Rica, entonces nadie tiene la culpa y todo sigue igual.
Pero el costo más alto del software inadecuado no son los millones de dólares pagados: es el costo de oportunidad de no tener el software adecuado. El software adecuado no sólo no produce dependencia del proveedor, ya que está basado en estándares abiertos y se dispone del código fuente para poder contratar el mantenimiento con cualquiera (o realizarlo internamente con personal propio), sino que se ajusta a los requerimientos (siempre cambiantes) de la institución.
El meollo del problema. Los requerimientos de software son como los planos de un edificio. Nadie en su sano juicio licitaría la construcción de un inmueble ofreciendo una descripción en castellano del inmueble requerido, pero las instancias de control estatal permiten que se licite la compra o desarrollo de software con requerimientos mal definidos.
La especificación de requerimientos de software, no puede y no debe ser un documento escrito en un lenguaje tan ambiguo como el castellano. El lenguaje natural es una maravilla para escribir novelas y poemas, es aceptable para explicar algunas cosas no muy técnicas, pero nunca serviría para que la torre de control se comunique con los aviones o para describir, de manera rigurosa el edificio que se desea construir.
Conforme se han hecho las computadoras más poderosas y se han escrito programas más complejos, también se han desarrollado técnicas y estándares que permiten especificar de manera rigurosa los requerimientos de un software.
Existe una notación llamada Z, basada en la teoría de conjuntos que nos permite no solo especificar muy rigurosamente lo que un software debe hacer, sino después (como cualquier ingeniería) demostrar que el software cumple con los requerimientos. Pero las matemáticas asustan a algunos, de manera que se han desarrollado notaciones formales, menos rigurosas que Z, pero mucho más rigurosas que el castellano. UML es el estándar más utilizado en el mundo; es un lenguaje de modelaje de sistemas que nos permite definir de una manera bastante certera los requerimientos y hasta la arquitectura de un sistema. A la fecha, nunca he visto una licitación para la adquisición de software con la especificación de requerimientos en UML.
Fracaso casi seguro. Un discurso de los proveedores de software empaquetado es que, además de software, provee las "mejores prácticas" e implementa los mejores procesos del negocio ya que este software es utilizado por muchas empresas en el ámbito mundial.
Implementar grandes paquetes de software es, en el mundo, muy riesgoso; el éxito depende de la capacidad de adaptación de la empresa. Cuando se intenta adaptar el paquete a la idiosincrasia de la empresa, el fracaso está casi asegurado.
Para una institución, lidiar con el cambio de los procesos y del software que soporta los procesos al mismo tiempo es muy complicado por muchas razones. Una razón importante es la reacción al cambio, que con el tiempo se ha ido exacerbando, sobre todo cuando los sindicatos logran oponerse, pues esos cambios podrían traer aumentos en productividad y eficiencia -los cuales tienden a reducir la planilla-.
Pobre argumento sería, de una institución, prescindir de los requerimientos en la compra de software, basado en el discurso de las mejores prácticas. Pretender reformar una institución a partir de un software, sin definir el resultado deseado, es un poco más que optimista. Primero se debe definir qué se quiere; después, si no hubiere en el mercado ningún software que cumpla con esos requerimientos sin crear dependencia, entonces se deberá, en la evaluación, sumar, al costo del software, el costo de lograr la independencia. La independencia tecnológica siempre es posible, pero requiere tiempo y dinero. La dependencia siempre es más cara en el largo plazo.
Artículo publicado en el periódico La Nación
