El Cedazo

En la entrada anterior hablamos de los procesos batch, necesarios en casi todas las instalaciones, y en la anterior a ésta vimos cómo fueron los comienzos de las Bases de Datos Relacionales, las que hoy en día dominan el mercado, en la década de los ochenta del siglo pasado. Antes vimos la aparición de los PC’s, y hoy me centraré en la tercera tecnología de gran calado que apareció y cobró enorme importancia en la segunda mitad de los ochenta: Las Metodologías de Desarrollo, y cómo al poco empezaron a aparecer, como setas en un día soleado de otoño, decenas de Herramientas Informáticas para facilitar la cumplimentación de las técnicas incluidas en ellas: el software para hacer Ingeniería de Software Asistida por Ordenador, es decir, las Herramientas CASE (CASE Tools, según su nombre en inglés), aunque en estas últimas me centraré en el próximo artículo, por razones de espacio.

Repito una vez más lo mismo que vengo diciendo en toda la serie: no es mi intención escribir una crónica oficial de nada, sino más bien cuáles son mis recuerdos de las vivencias de aquella época (segunda mitad de los ochenta); el advenimiento de las Metodologías y de las Herramientas CASE la viví también muy de cerca… igual diréis que cómo es posible que estuviera metido en tantos fregados tecnológicos al mismo tiempo… en nuestros tiempos es muy difícil para un técnico, por muy listo que sea, estar al tanto de todo lo que acontece en cada parcela de la técnica informática; entonces tampoco era posible estar al tanto de todo avance… pero sí de la mayoría, siempre que se fuera muy, muy curioso, y se tuviera la suerte de estar trabajando en el puesto adecuado de la empresa adecuada… lo que, afortunadamente, era mi caso durante los ochenta y primeros noventa del siglo pasado..

Como la serie va teniendo ya unos pocos capítulos, para aquéllos que no hayáis leído los capítulos anteriores, y que dispongáis de algunas horas para hacerlo, aquí tenéis la dirección donde podéis encontrar el acceso a todos ellos.

Ya comenté hace algunos artículos que la aparición de la Bases de Datos Relacionales había significado un shock para la profesión: implicaban la utilización de técnicas de diseño de Base de Datos bastante diferentes de lo que estábamos acostumbrados, mucho menos “personalistas”, si se me permite la expresión, y mucho más industriales. Es decir, comenzaba a vislumbrarse el mismo camino que, pocos años antes, habían seguido las técnicas de programación, con la aparición y rápida adopción de la Programación Estructurada.

Por tanto, el sentimiento de los profesionales de la época (mediados de los ochenta), y entre ellos el mío propio, era algo así como: “Vaya, por fin comienza a ser posible unificar formas y métodos, y encontrar un lenguaje común que nos permita una comunicación precisa entre nosotros…”. ¡Cuán equivocados estábamos…! Pero, como entonces no lo sabíamos, hicimos grandes esfuerzos para conseguir ese “idioma común”.

Porque la situación estaba cambiando a pasos agigantados. Los últimos años de los ochenta y primeros de los noventa fueron de un enorme crecimiento en todos los aspectos de la informática: Crecimiento en potencia y variedad de las máquinas, en Sistemas instalados, en Aplicaciones funcionando (ya, casi todas, online) y, sobre todo, de fuerte crecimiento del personal de los Departamentos de Informática (o Proceso de Datos, como seguían llamándose mayoritariamente por entonces: no había llegado aún la moda del marketing a los nombres de los Departamentos dedicados a esto).

Entrevistas y más entrevistas... y no, yo no soy el de la foto: ¡mis corbatas son más bonitas!

Casi podría asegurar que en el plazo de tres o cuatro años, el plantel de informáticos al menos se duplicó en la mayoría de grandes empresas, y en algunas, bastante más. Y no fue nada fácil encontrar a tanto informático. Doy fe. ¡La de currícula que me leí, y la de entrevistas que pude hacer esos años!

Costó un gran esfuerzo poder incorporar tanto técnico informático a las empresas, simplemente porque en el mercado no los había. Todas las Universidades Españolas quizá podían graduar a, digamos, mil informáticos anuales, seguramente bastantes menos… totalmente insuficiente para tales crecimientos, por lo que no hubo más remedio que echar las redes en los caladeros de cualquier otra especialidad, sobre todo las técnicas (lo que por entonces se conocía como “Carreras de Ciencias”): Matemáticas, Física, Biología, Geología, Ingenierías, sobre todo Teleco (aunque menos), ¡incluso Medicina!

Eran éstas Carreras que proporcionaban una buena preparación de base, algún conocimiento de informática, y que, con la excepción de Medicina, no tenían mucha salida en España, quitando la docencia, que obviamente pagaba bastante peor que la informática…y que, además, por entonces tenía menos glamour, qué demonios (ahora, de ninguna manera, pero ésa es otra historia, y será contada en otro momento). Así que las grandes empresas nos lanzamos a contratar Licenciados, Diplomados, Peritos o lo que pilláramos (sí, también algún que otro recomendado, por si lo os lo estáis preguntando, pero pocos), y a formarlos en la tecnología pertinente, mayormente Cobol, DB2, IMS o CICS, según el caso, y toda la parafernalia mainframera asociada: ISPF, JCL, SPUFI, etc.

Y Programación Estructurada, naturalmente… Porque en esa época (mediados y finales de los ochenta), estas cosas mundanas ya casi no se explicaban en las Universidades españolas, a pesar de que eran las que daban trabajo a quizás siete de cada diez informáticos de los de entonces.

Todo este movimiento trajo como consecuencia una desmitificación de la profesión. Porque, total, si con un curso de un par de meses o tres, convertíamos a un biólogo, o un químico experimental, o un físico de partículas, en un informático, y lo poníamos a programar, y no lo hacía tan mal… no sería esto tan difícil, ¿no?

Los Departamentos de Recursos Humanos, asustados ante la necesidad de contratar miríadas de informáticos de elevado sueldo, a los que encima había que formar a precio de oro antes de que fueran capaces de escribir su primera MOVE, comenzaron a ajustar los salarios. A reducirlos, vaya, a racanear. Dejaron de creerse, ya para siempre, el mantra que repetíamos continuamente de que “los informáticos somos unos sofisticados técnicos, conocedores de un extraño e ininteligible arcano, y que por tanto, rara avis como somos, debemos tener un (enorme) sueldo en consonancia”. Allí comenzó nuestro declive, amigos. Y así seguimos…

Bueno, y… ¿Por qué os cuento todo esto?

Pues, veréis, porque con tanta incorporación de personal comenzaba a ser evidente que era necesario llegar bastante más allá de una simple recomendación de uso de técnicas: había que asegurarse, en lo posible, de que tanto el procedimiento de Diseño de las Aplicaciones como la Documentación asociada estuvieran formalizados, uniformizados, reglamentados, constreñidos, de tal modo que cualquier persona pudiera leer, comprender y, llegado el caso, modificar cualquier Aplicación sin necesidad de apelar a la memoria o el conocimiento de su creador…

Pues igual, pero con una Aplicación...

Tenía yo un compañero, algunos años antes, que se autodefinía como “El Hombre-Aplicación”, porque llevaba la Aplicación de Nómina en la cabeza, igual que los “Hombres-Libro” de Fahrenheit 451, de Ray Bradbury, se aprendían de memoria un cierto libro, digamos Hamlet o El Quijote, para salvaguardarlo de la gubernamental y malsana campaña de quema de libros… sólo que en este caso, si al pobre hombre le daba por irse de vacaciones, o enfermar, igual no se podía pagar la Nómina.

Esta era una situación que se daba con alguna frecuencia, y que las empresas no estaban dispuestas a que volviera a ocurrir en el futuro. Aunque igual sabéis que, en realidad, por mucho que documentes, y que mantengas la documentación, sigue siendo mucho más eficaz que realice cualquier cambio a la Aplicación alguien que la conozca, que alguien que no sepa de qué va, por mucha documentación electrónica o en papel que haya… Pero siempre será mejor que exista documentación a que no exista.

Por ello, parecía evidente que había que implantar un procedimiento de Diseño, Construcción y Documentación que permitiera eliminar a los “Hombres-Aplicación” (o “Mujeres-Aplicación”, que también había). Y para ello, se necesitaba, en primer lugar, un Método que dijera qué había que hacer, y qué no; en segundo lugar, unas Técnicas de uso común para realizar Análisis, Diseño, y Programación (aunque esta última ya estaba bastante formalizada); y en tercero, a ser posible, un Sistema de algún tipo que se asegure que las Normas del Método se cumplen y las Técnicas se aplican.

Estas necesidades básicas son solucionadas, como habéis intuido, por las Metodologías de Desarrollo de Software, por las Técnicas de Análisis y Diseño, y por las Herramientas CASE, respectivamente. Pero… ¿cuál era el estado de cada una de ellas a mediados de los ochenta? Allá vamos (en este artículo hablaré sobre todo de Metodologías y Técnicas, en las  Herramientas CASE me centraré el próximo día).

.

No había Metodologías de Desarrollo, tal como las conocemos ahora, en la práctica. Sí que había algunas, de las que hablaré brevemente en un momento, que eran más bien un listado de tareas y documentos que había que cumplimentar, firmar y guardar. Y esto porque, en su mayoría, fueron promovidas por ciertos Gobiernos para asegurar el cumplimiento de las especificaciones y, sobre todo, de los costes de los grandes proyectos contratados por la Administración.

En cuanto a Técnicas, hemos visto cómo la Programación Estructurada había triunfado ya, pero apenas había nada sobre cómo realizar el Diseño Técnico, ni mucho menos el Análisis Funcional. Para el Diseño Técnico, ya se escribían y guardaban con cierto formato los Cuadernos de Carga, pero a la hora de explicar lo que debía hacer el programa, se explicaba… en cristiano… como se le ocurría al Analista Orgánico. Sin ir más lejos: “Abrimos el fichero de entrada; leemos registros, y consultamos en la Base de Datos BDCUENTA si la cuenta existe; si existe, patatín, patatán… si no existe, patatán, patatín…” y así todo.

Y en cuanto al Funcional, se daban reglas, sugerencias… pero el Analista, en definitiva, escribía su Análisis Funcional explicando en román paladino lo que debía hacer la Aplicación como buenamente podía, sabía y se le ocurría.

Luego, en cuanto al diseño de las Bases de Datos, tampoco había mucho más que la experiencia del Analista, y las Reglas de Normalización de Codd, siempre que fueran las Bases de Datos fueran Relacionales, que si eran jerárquicas, ni eso.

Y por fin, en cuanto a las Herramientas informáticas, alguna había, pero muy orientadas a facilitar el trabajo del programador (que era, en verdad, el único que trabajaba con herramientas informáticas, el TSO, el ISPF, etc, pues el resto de roles del Desarrollo de Aplicaciones trabajaban mayormente en aquellos años con un lápiz y un papel… y gastar saliva, sobre todo, mucha saliva).

Curva de Costes durante el Ciclo de Vida de una Aplicación

Quizá conviene resaltar que, ya entonces, el Mantenimiento de Aplicaciones era un serio problema… y tenía toda la pinta de convertirse en El Problema. Aquí tenemos un gráfico de los costes de cualquier gran Aplicación a lo largo del tiempo. La Concepción del Sistema, el Funcional, el Técnico, el Desarrollo, las Pruebas… es decir, todo el coste incurrido hasta la puesta en marcha de la Aplicación es la zona verde de la curva; una vez puesta en marcha comienza su fase de mantenimiento (la zona naranja), que supondrá seguramente, a lo largo de toda la Vida de la Aplicación, entre un 75% y un 90% del coste total dedicado a dicha Aplicación a lo largo de su vida útil.

Además, las proyecciones eran palmarias: de seguir así, en unos pocos años el 90% de la plantilla de Desarrollo, o más, estaría dedicada exclusivamente al Mantenimiento… y entonces, ¿quién escribiría las nuevas Aplicaciones? Nuevo personal, claro está. Que habría que fichar o subcontratar, obviamente. Y que, una vez terminada su Aplicación, quedaría, en un 90%, dedicado a su mantenimiento. Y habría que fichar entonces más personal nuevo para escribir las nuevas aplicaciones… No parecía que el círculo vicioso originado por esta forma de trabajar resultara muy eficiente a la larga.

Así que las connotaciones son evidentes: No hay que escatimar esfuerzos durante la etapa inicial de Diseño y Construcción de la Aplicación para reducir todo lo posible el coste del Mantenimiento posterior. Es decir, incrementar un 20%, un 30% ó incluso un 50% el coste del Desarrollo de la Aplicación no supondrá, a la larga, un porcentaje importante del coste total de la Aplicación (quizá un 5%-10% del total), mientras que reducir en un 20% ó un 30% el coste del Mantenimiento sí que tendrá un efecto importante en los costes finales acumulados.

Fue en aquellos años cuando empezamos a escuchar en Congresos (los pocos que íbamos) y leer en revistas (los que leíamos, que éramos algunos más) sobre el “nuevo paradigma” de la generación automática de código. La idea es que, una vez introducidas las especificaciones de la Aplicación en el Sistema, descritas formalmente en algún tipo de lenguaje por inventar, el supuesto Sistema sería capaz de generar mágicamente todo el código necesario para que la Aplicación pueda funcionar correctamente: las definiciones de las Bases de Datos, con sus índices, vistas y toda la parafernalia, la definición de las pantallas de interfaz, la codificación de los programas, los JCL’s de las cadenas batch… ¡todo!, es decir, que apretando un botón se obtendría milagrosamente todo el código necesario (lo de “apretar un botón” y que todo lo que se desea salga automáticamente -mejor: milagrosamente- es una vieja aspiración de todo informático y, sobre todo, de todo usuario: un jefe que yo tuve decía que había que dejarse de zarandajas, y que lo que había que inventar de una vez por todas era la “Máquina-con-Orejas”… y encima, obediente, añadía yo, que como saliera peleona…).

Había ya algunas Herramientas aquéllos años (mediados de los ochenta, para que no os perdáis) que eran capaces de generar cierto código en base a ciertas especificaciones. Las que más se conocían en España eran Pacbase, de la francesa CGI (a mediados de los noventa, CGI fue comprada por IBM, y Pacbase incorporada dentro de ese galimatías de productos llamado VisualAge), y MAESTRO, de la alemana Softlab, aunque en España la vendía Philips. Cuando apareció su sucesor, llamado Maestro II, a fines de los ochenta, este MAESTRO-a-secas pasó a denominarse Maestro I. Ninguna de las dos podría considerarse aún como una auténtica “Herramienta CASE” como las que conocemos hoy en día, sino más bien como un Producto que ayudaba al programador, básicamente, a hacer su trabajo más rápido.

Maestro: P7000 y teclado.

Mientras Pacbase era sólo software, que funcionaba en las propias máquinas para las que generaba su código (es decir, en el propio mainframe bajo TSO), MAESTRO era un conjunto de hardware (un miniordenador Motorola vendido en Europa por Philips, como “Philips P7000″) y un software muy bien hecho (el propio Maestro en sí), que corría en este miniordenador. A Pacbase se podían conectar todos los usuarios que fuera capaz de soportar el TSO, pero cada MAESTRO daba servicio como máximo a un cierto número de usuarios (24 ó 32, no recuerdo bien), que usaban pantallas “tontas” conectadas por cable coaxial con la CPU. Por el diseño de la máquina utilizada (inicialmente pensada como máquina de Data Entry), era rapidísima, muy similar en tiempo de respuesta a los de un PC actual, es decir, cuando pulsabas una tecla (por ejemplo, la A), la A aparecía inmediatamente en tu pantalla (de 24 columnas de 80 caracteres, naturalmente), y se grababa en tu espacio privado de disco. Lo que editabas y guardabas era, fundamentalmente, programas, que luego debías enviar al mainframe para su compilación y prueba.

Para ello, se conectaba a los mainframes de IBM (supongo que también a los de otras marcas) de dos formas: por emulación 3270 (para conectarse al TSO, al CICS, etc) o por RJE (para submitir trabajos: compilaciones, pruebas, etc). Y el gran argumento de marketing de Philips-Softlab era precisamente la velocidad: editar un programa (o una documentación, un JCL o lo que fuera) en MAESTRO era tan rápido como puede serlo hoy en día… sólo que lo normal entonces era que, en TSO, los tiempos de respuesta fueran de varios segundos, de media ocho o diez, para cada interacción (por ejemplo, un avance de página, insertar una línea, una búsqueda, etc). Y así vendió Softlab muchos sistemas en todo el mundo: MAESTRO fue el líder absoluto en puestos de trabajo de desarrollo durante unos años, a finales de los ochenta: llegó a tener varias decenas de miles de puestos de trabajo operativos en todo el mundo.

Pero las cosas iban a cambiar rápidamente, para desgracia de Softlab… bueno, y de CGI, que con su Pacbase dominaba el mercado francés de largo, aunque no vendió mucho fuera de Francia. En España, ambos productos tuvieron un éxito limitado, consiguiendo algunas ventas en empresas muy importantes… pero pocas (claro que tampoco había tantas empresas importantes en España, y para poder siquiera considerar la compra de estos productos, que eran realmente caros, había que tener una masa crítica considerable, que permitiera amortizarlos en un cierto plazo).

Primero, porque los PC’s comenzaban a ser asequibles (al menos, más asequibles que los años precedentes), y todo el mundo estaba asumiendo que todo técnico iba a acabar con uno encima de la mesa más temprano que tarde.

Y segundo, porque varios ingenieros de la computación estaban atacando ya (de hecho, llevaban algunos años en ello) el problema siguiente al de cómo realizar eficientemente la Programación, es decir: ¿cómo realizar el Diseño de los Sistemas? Es decir, tanto el Diseño Técnico (Bases de Datos, Transacciones, Procesos Batch…) como el propio Análisis Funcional, de alguna manera ciertamente más formal que simplemente escribir la documentación, aunque fuera en un flamante editor de textos, en vez de con papel y boli…

Uno de los esfuerzos vino del propio Michael Jackson, que en 1983 publicó su libro “System Development”, en el que presenta su método JSD, aunque ya estaba dando cursos y seminarios sobre el asunto desde hacía un par de años. En realidad JSD es una extensión de su método de Estructuración de Programas, esta vez orientado al Diseño de los Sistemas. No tuvo excesivo éxito (veremos que llegó algo tarde), pero nuevamente Jackson hizo una formalización extraordinaria: su método fue el primero que estableció que los Sistemas deben ser diseñados a partir de las Salidas (es decir, los resultados esperados). Eso que ahora es tan evidente, lo estableció él… ¿o… no es tan evidente?  Bueno, para mí sí que lo es. Todos los procesos, los datos necesarios, etc, son la consecuencia lógica de conocer para qué debe servir nuestro sistema, es decir, qué es lo que esperamos que haga el sistema, lo que debe de producir, en definitiva: las salidas. Malamente vamos a escribir un Sistema que no sabemos qué información es la que tiene que obtener…

Peter Chen

Efectivamente, el método de diseño de Jackson llegó algo tarde, pues algún tiempo antes, otros gurús de la informática habían ya publicado diferentes visiones para sistematizar el proceso de Análisis y Diseño Estructurado de Sistemas.

Peter Chen había atacado con éxito la problemática de la modelización de los datos, mediante su técnica “Modelo de Entidad-Relación” (ERM), publicado inicialmente tan pronto como en 1976, pero que no tuvo aceptación real hasta que las Bases de Datos Relacionales no comenzaron a invadir las instalaciones de todo el mundo, a mediados de los ochenta.

El motivo es obvio, ya que, una vez realizado el Modelo de Datos según su método, es prácticamente inmediato obtener una estructura de Tablas Relacionales (que no tiene por qué ser muy eficiente, pero en principio, es funcional).

Esta forma de modelizar los datos fue adoptada por virtualmente todos los métodos de Desarrollo de Aplicaciones de entonces (y de ahora), debido a su consistencia y, sobre todo, a su facilidad de aprendizaje y comprensión.

Utiliza apenas tres elementos bastante intuitivos: Atributos (es decir, los diferentes datos individuales que se precisan para nuestro Sistema de Información), Entidades, que son los contenedores de los atributos, que deben estar una y sólo una vez en cada ocurrencia de la Entidad, y Relaciones entre Entidades, que modelizan qué tipo de conexión hay entre dos diferentes Entidades.

El nombre de la técnica: Modelo de Entidad-Relación, describe perfectamente sus constituyentes fundamentales.

Las Relaciones que indican las correspondencias entre dos Entidades pueden ser de tres tipos (supongamos en lo que sigue una relación entre las Entidades A y B):

Un ERD Sencillo

a) de uno a uno (por cada ocurrencia de la Entidad A hay una y sólo una ocurrencia en la B; se representa 1:1);

b) de uno a muchos (para cada ocurrencia de la Entidad A hay un número indeterminado de ocurrencias relacionadas en la Entidad B, pero cada ocurrencia de la Entidad B sólo se relaciona con una única ocurrencia de la Entidad A; se representa 1:n);

c) y de muchos a muchos (para cada ocurrencia de la Entidad A hay un número indeterminado de ocurrencias relacionadas en la Entidad B, pero también para cada ocurrencia de la Entidad B hay un número indeterminado de ocurrencias relacionadas en la Entidad A; se representa n:m, y debe ser descompuesta mediante una Entidad intermedia, con los datos de intersección, y dos relaciones 1:n en la Fase de Diseño Técnico (es decir, para definir las tablas Relacionales definitivas). En el ejemplo de la derecha, la entidad “Usage” descompone la Relación n:m que hay entre “User” y “Service”.

Antes de que me lo digáis, este tipo de nomenclatura se refiere al número máximo de elementos de una entidad que están relacionados con otra; para realizar la definición formal completa efectivamente hay que especificar también el número mínimo de elementos de la relación. Por ejemplo, en una relación 1:n, si es posible que cada entidad pueda estar relacionada con de cero a ene elementos de la otra, habría que especificarlo de la forma 1:(0,n), por ejemplo. Lo que ocurre es que en la vida real es muy difícil encontrar relaciones del tipo 1:(1:n), por ejemplo, lo normal es que sean 1:(0:n), por lo que, si no se dice nada en contra, se asume que la n (o la m, claro) puede valer cero también, o sea, el valor cero es también un valor aceptable para el término muchos.

Aquí tenemos un Modelo de Entidad Relación, a saber de qué extraño Sistema, cortesía de la Wikipedia.

Unos pequeños ejemplos de Entidades Financieras (que ya sabéis que son las que mejor me sé):

a) Oficina – Dirección de la Oficina (de uno a uno): Una Oficina está en un único Domicilio (Dirección), mientras que en cada Dirección hay una única Oficina (no tiene ninguna lógica mantener dos Oficinas diferentes de la misma entidad en la misma Ubicación, ¿no os parece?).

b) Cuenta – Movimiento (de uno a muchos): Cada Cuenta puede tener muchos movimientos (apuntes) a lo largo de un periodo, un número en principio indeterminado (desde ninguno a cientos, o miles), pero cada apunte pertenece a una única Cuenta. En el caso de la típica Operación que involucra dos Cuentas (un traspaso de fondos, por ejemplo), se generan dos movimientos diferentes, un adeudo en la cuenta que emite los fondos, y un abono en la que los recibe, por lo que cada apunte es de una y sólo una cuenta.

c) Cliente – Cuenta (de muchos a muchos): Cada Cliente puede ser titular de varias Cuentas, mientras que cada Cuenta puede tener varios titulares. Fijaos en este caso que podría haber Clientes sin Cuentas asociadas, pero toda Cuenta debe estar necesariamente asociada a un Cliente; la Relación Cliente-Cuenta debe especificarse como (1,n):(0,m) para hacerlo correctamente.

Esta técnica de modelización fue rápidamente adoptada por casi todo el mundo, como ya dije, y también en España, y de hecho sigue siendo la utilizada por prácticamente todas las metodologías al uso para realizar el Modelo de Datos.

Ed Yourdon (izquierda) y Tom de Marco (derecha)

Pero había otros gurús que pensaban justo lo contrario que Jackson y Chen: que lo importante de las aplicaciones no son los datos, sino los Procesos, es decir, conocido lo que hay que hacer, los datos necesarios para hacerlo se hacen evidentes, pues son el subproducto de los procesos.

Para mi gusto, esto es mucho decir, pero Edward Yourdon y Tom de Marco propusieron esta Técnica de Análisis y Diseño Estructurado, que se basa en una aproximación top-down al problema del Diseño de los Sistemas de Información: comenzar con el diagrama más general, e ir descomponiendo el Sistema desde lo más general a lo más particular.

El resultado son los Diagramas de Flujo de Datos (DFD’s), que nuevamente utiliza exclusivamente cuatro símbolos: Uno para representar los Procesos (o Funciones del Sistema), otro, para los Almacenes de Datos del Sistema (ficheros o Bases de Datos: en inglés Data Store; no confundir con Data Warehouse, concepto que se definió años más tarde, y que sirve para otras cosas, pero ésa es otra historia y será contada en otro momento), otro para las Entidades Externas (Usuarios u Otros Sistemas, que son los que proporcionan o reciben la información), y el último, para representar los Flujos de Información entre los Procesos y los Almacenes de Datos o Entidades Externas, es decir, los datos que el Proceso necesita o genera.

Símbolos usados en los DFDs

Aquí a la izquierda tenéis los cuatro símbolos utilizados para definir los Diagramas de Flujos de Datos; combinándolos entre sí, se obtienen los DFD’s.

El primero de los que es preciso realizar es el Diagrama de más alto nivel; posteriormente, cada Proceso de Alto Nivel se va definiendo mediante un nuevo DFD de segundo nivel, cuyos procesos son a su vez definidos con más DFD’s de tercer nivel… hasta llegar al mínimo nivel de definición deseado (que puede ser tan mínimo como queramos; generalmente se queda al nivel del programa individual).

Con razón se llaman “Métodos Estructurados”; si se listaban todos los diagramas juntos, resultaba un precioso árbol de procesos, que se iban descomponiendo a su vez en procesos de menor nivel… Muy estructurado, desde luego.

Uno de los personajes más importantes de la informática del siglo pasado, el británico James Martin, se adhirió pronta y entusiásticamente a las técnicas de modelización, y creó, o quizá sólo la adoptó y dio a conocer, en 1981, la Metodología IE (Information Engineering), que tuvo casi de inmediato una muy buena aceptación… en el mundo anglosajón, por supuesto; en España, muy poca. Pero todos fuimos a seminarios, leímos artículos, en fin, nos culturizamos en IE.

James Martin

En ella combina una lista de tareas y actividades a realizar para llevar a buen término los proyectos informáticos, con el uso de las dos técnicas de modelización antes mencionadas: la de procesos, vía los DFD’s, y la de datos, vía los ERD’s.

James Martin se convirtió en el máximo defensor y valedor de las nuevas técnicas y de los nuevos métodos; buena parte del éxito de ambos en los ochenta y primeros noventa, es debido a él… y muchas más cosas.

La idea de adoptar una Metodología de Desarrollo de Aplicaciones es, por un lado, minimizar los riesgos del proyecto, controlar costes, asegurar la funcionalidad prevista, gestionar los tiempos, facilitar el mantenimiento… en fin, todas esas cosas que nos encanta citar a los informáticos, aun a sabiendas de que no hay manera, por mucha lujosa metodología que uses, de asegurar tales cosas.

Y también, cómo no, la posibilidad de utilizar un Lenguaje Gráfico de Diseño que fuera fácilmente comprensible, no sólo por los propios informáticos, que ya era importante, sino también por Usuarios, cosa que igualmente sabéis que no es tan cierta como aseguramos… pero así andamos, que hay que vender proyectos, o desaparecemos del mapa.

A partir de aquí, en la meca de la informática, EEUU, se comienzan a utilizar las metodologías de desarrollo, primero de forma tímida, luego con cada vez mayor aceptación.

Un DFD típico

¿Y en Europa? Pues también se estaba trabajando, pero con curiosas connotaciones nacionales.

En Francia existía desde hacía unos años (mediados de los setenta) la metodología Merise, en principio una relación (exhaustiva, eso sí) de pasos y tareas con alguna técnica manual sencilla, y que también a principios de los ochenta se enriqueció con las nuevas técnicas de modelización de Datos y Procesos; se trata de un método francés, pensado por y para franceses, y que tuvo pocos seguidores fuera del mundo francófono, pero como la Administración francesa exigió el uso de Merise para la contratación de proyectos informáticos desde muy pronto (principios de los ochenta), se convirtió en el standard de facto en el mercado francés en el final de la década de los ochenta.

En el Reino Unido, en la misma época, se estaba gestando SSADM, que adoptó entre sus técnicas a una mezcla de varios de los incipientes métodos de análisis estructurado del momento, en particular los de Yourdon, De Marco, Jackson y Constantine, que fueron incorporados desde el principio al método, se supone que tomando lo mejor de cada uno de ellos. A partir de 1983, también se hizo obligatorio el uso de SSADM para poder contratar proyectos para la Administración británica, por lo que fue ampliamente seguida en el Reino Unido, y después también en el resto de Europa.

¿Y en España? También hacíamos nuestros pinitos, no os creáis. A mediados de los ochenta, el Ministerio de Administraciones Públicas comenzó el desarrollo de una Metodología española (a imagen y semejanza de la francesa y la británica), que recibió el nombre de Métrica. Participaron diferentes Organismos de la Administración, y se encargó su realización final a una consultora (Coopers & Lybrand, que por entonces no estaba aún fusionada con Price Waterhouse, ni mucho menos con IBM, como ahora lo está). Ahora un poco de queja habitual: como de costumbre con lo que ocurre en España, se encuentra muy poca documentación de Métrica en la red, y la poca que hay es de la versión 3, ya de fines de los noventa…

Métrica se parecía, inicialmente, a SSADM, pero se le aligeró de bastantes pasos burocráticos, para adaptarlo más a nuestra mentalidad, aunque se añadieron algunos otros. Resultó una Metodología moderna y muy bien fundada. En cuanto a técnicas, básicamente usaba las mismas que los demás, ERD, DFD, Diseño Estructurado… A la versión 1 siguió la versión 2… y, por fin, la actual versión 3, desarrollada en la segunda mitad de los noventa, que incorpora ya las últimas novedades (Orientación a Objetos, UML, etc).

Pero Métrica, en ninguna de sus versiones, nunca fue obligatoria en su uso para la presentación de proyectos a la Administración, salvo en algún que otro proyecto aislado, por lo que no tuvo un gran impacto en las empresas españolas. Y, que yo sepa, nadie la usa en nuestros días. Tanto esfuerzo, para nada. En fin…

Y es una buena metodología, probablemente las más completa y útil de todas las que pululan (bueno, pululaban) por ahí. Pero ya sabemos que los españoles preferimos inventar la rueda cada vez, así que… así son las cosas…

…Porque el método más usado en los ochenta en las instalaciones españolas fue Method/1, de Arthur Andersen (aún no se había fundado Andersen Consulting, ni mucho menos Accenture) . Y esto era así por la enorme (apabullante en algunos casos, y hablo por experiencia) presencia de los queridos “Arturos” en muchas de las grandes compañías españolas de la época. Y los “Arturos” venían con el Method/1 de serie, bien aprendido de sus cursos de Chicago, y convencían a sus clientes (a los Directores, desde luego) de lo increíblemente apropiado de su uso para gestionar costes, conseguir calidad, y bla, bla, bla. Así que muchísimos profesionales de la época tuvimos que lidiar lo mejor que supimos con los tomos y tomos de fases, actividades, tareas, memorandos, tablas y relaciones interminables del Method/1.

Ésta era la pinta del Method/1

No estoy yo nada seguro de que la aplicación del susodicho método trajera grandes beneficios (excepto para la propia Arthur Andersen, of course). Nada seguro…

Es más, estoy convencido de que la cantidad enorme de interminables informes, documentos y papeles que había que rellenar no sirvieron para otra cosa que distraer al personal de hacer aquéllo por lo que se supone que le pagaban: desarrollar Sistemas de Información.

Una cosa es documentar… y otra, aquéllo. Inhumano. De veras…

Pero eso sí, si estabas al día con todos tus papeles en regla, cuando el proyecto se iba en tiempo, coste y esfuerzo, siempre le podías echar la culpa a otro… así que fue un sistema perfecto para cubrir las espaldas de los Jefes de Proyecto. Pero desde el punto de vista de las empresas, no creo yo que fuera ninguna buena inversión, ni a la corta ni a la larga. En fin.

Bien, la entrada se está volviendo un pelín larga, como de costumbre, diréis, así que en la próxima, que espero sea más corta, echaremos un vistazo a algunas de las tropecientas herramientas CASE que aparecieron en los últimos años de los ochenta y durante los noventa del siglo pasado.

Disfrutad de la vida, mientras podáis.

The Historia de un Viejo Informático. Aparecen las Metodologías de Desarrollo para facilitarnos la vida. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.