Regístrate | Conectar
El Tamiz Libros Recursos Series Únete 9 Users Online
Skip to content

Historia de un Viejo Informático. Aparecen las Metodologías de Desarrollo para facilitarnos la vida.




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... !

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...

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

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.

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

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

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.

Un ERD

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)

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

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

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

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

É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.


Sobre el autor:

Macluskey ( )

Macluskey es un informático de los tiempos heroicos, pero no ha dejado de trabajar en Informática y disfrutar con ella hasta la fecha. Y lo que el cuerpo aguante. Y además, le gusta la música...
 

{ 33 } Comentarios

  1. Gravatar Leonardo Torres | 07/05/2009 at 06:26 | Permalink

    Yo fuí un Arturito!!

    Recuerdo con horror el Method/1. No te quepa la menor duda sobre su utilidad: ninguna! Bueno, si. Facturar capazos de horas al cliente.

    Eso que dices de que traíamos bien aprendido el Method/1(?!). Yo no conocí a nadie que supiera más que una mínima parte, ni tan solo los formadores. Y luego su aplicación era tan escasa como poco rigurosa, al menos en los proyectos donde yo caí. En banca es posible que la cosa fuese diferente.

    Y tienes toda la razón. La documentación generada era aberrante por su cantidad e inútil por su falta de puesta al día. En el único proyecto de banca en el que participé, llegué cuando ya estaba prácticamente terminado. De hecho estaba a caballo entre la puesta en marcha y el mantenimiento. Un dia me topé con montañas de carpetas y papeles y cuando pregunté me dijeron que era la documentación del proyecto. Sugerí que ya que había documentación, podíamos usarla, no? Entre caras de asombro y risotadas me contestaron que vale, que yo mismo. Que ahí estaba todo y que me sirviese si quería, pero que ellos no iban a perder un segundo en mirarse aquello.

    En fin. Por suerte he podido olvidar todo lo que aprendí sobre aquello. Espero haber dejado libres neuronas para otros conocimientos.

    Saludos

  2. Gravatar Macluskey | 07/05/2009 at 09:09 | Permalink

    Je! Yo también recuerdo con horror el Method/1… Y tienes razón en que los Arturitos (tus palabras, no las mías) tampoco se sabían el Method/1, pero ¡aparentaban que lo sabían! y comonosotros apenas éramos capaces de enterarnos de tres o cuatro cosas…

    En fin, poco queda de aquello… por no quedar, no queda ni una referencia al Method/1 en la red: apenas hay nada y lo poco que hay, circunstancial. La wikipedia no tiene nada en ningún idioma normal, y en la web de Accenture, tampoco hay nada. Uno más para el olvido, como tantas y tantas cosas.

    Gracias, Leonardo, por comentar

  3. Gravatar Mazinger | 08/05/2009 at 05:52 | Permalink

    Dos reflexiones.

    Creo que las metodologías y estándares de desarrollo son muy importantes para garantizar la calidad de un proyecto informático (excesos como los comentados con Method/1 aparte, claro). Esto se nos ha vendido en la universidad y en la empresa, en libros y revistas, por activa y por pasiva. Pero… ¿alguien del sector informático ha sentido que en su empresa se pongan realmente en valor estas metodologías?

    He trabajado muchos años en desarrollo y en la mayor parte de los proyectos se seguía más la filosofía de sacarlos adelante rápidamente y sin cabeza, y a base de esfuerzo y sudor, que atendiendo a las directrices y buenas prácticas de una metodología decente. Eso sí, al cliente se le vendía que eramos la repera porque empleábamos la última metodología de moda (mentira), teníamos el último sello “ISO la leche” (sólo de cara a la galería, realmente no se implementaban procesos de calidad) y además contratábamos a los mejores profesionales del mercado(osease, chicos recién salidos de la universidad, con muchas ganas eso sí, pero sin ninguna experiencia). Creo que esto sigue pasando en muchas empresas de servicios informáticos, incluidas las grandes.

    Lamentablemente la informática es más hoy en día una artesanía que una ingeniería (dicho esto sin menosprecio a los artesanos).

    Segunda reflexión. Has dicho ya varias veces, Macluskey, que no has encontrado, o has tenido grandes dificultades para encontrar en la web, material para tus artículos. ¡Cuántas cosas se olvidan! Y de lo que se olvida no se aprende…

    Please Mac, necesitamos tu memoria. Continúa con tu labor…

  4. Gravatar David Horat | 08/05/2009 at 08:31 | Permalink

    ¡Me encantan los artículos! Felicidades :)

  5. Gravatar ubersoldat | 08/05/2009 at 08:41 | Permalink

    Genial la entrada, como siempre, aunque se me ha hecho corta, sobretodo en la parte de Métrica que me gustaría entender un poco mejor si es realmente útil como haces entender. Saludos y continua con el gran trabajo.

  6. Gravatar cruzki | 08/05/2009 at 08:49 | Permalink

    @Mazinger

    Pero es que eso es “lógico”. ¿A cuantas empresas conoces que se mamen el marrón de mantener un programa? Me refiero a empresas de desarrollo externas. Normalmente te hacen el programa y luego se desentienden en mayor o menor medida (la frase clara sería, se escaquearán tanto como les permita el contrato). De hecho, ¿te has leido la licencia de algún programa que instalas en tu PC? ¿En serio que esas licencias son legales o asumibles para una empresa? Yo solo espero que las de los mainframe no sean como las de los pcs…

    Bajo este supuesto, ¿qué interés tiene la documentación? Ninguno, sólo el de perder el tiempo… y encima como el código fuente se lo quedan ellos, se pueden hacer unas ñapas del copón que como nadie se va a enterar. Y así va la profesión de informático… y lo peor es que mira que cuesta meterles en la cabeza a los alumnos esas cosas. Si ellos no se comportan “como ingenieros profesionales” ¿cómo pretenden que la sociedad los considere como tal?

    @Mac

    ¿Hablaras de programación orientada a objetos y estas “nuevas metodologías”?

    Por cierto, ¿hay alguna forma de conseguir contactarte en privado?

  7. Gravatar Mazinger | 08/05/2009 at 09:31 | Permalink

    @Cruzki

    “…A cuantas empresas conoces que se mamen el marrón de mantener un programa? Me refiero a empresas de desarrollo externas…”

    ¡A TODAS! Aunque según veo en la Universidad las cosas son diferentes. ;-)

    Te puedo asegurar que las empresas de servicios informáticos, las externas, se dan de tortas por conseguir proyectos, incluso con bajadas de pantalones sensacionales (y en épocas de vacas flacas no te digo nada.., con mano de obra barata no sólo informática propiamente dicha, sino filóloga, bióloga y todas las carreras habidas y por haber). De hecho ahí empieza los problemas para los pobres informáticos. Proyectos mal dimensionados que acaban siendo imposibles de llevar a cabo con los tiempos y recursos asignados, siempre insuficientes.

    Una vez dentro, una de las piezas más golosas es precisamente el mantenimiento de la aplicación. Da mucho dinero, y antes más aún que ahora. ¿Desentendernos del mantenimiento? Al revés, no solo se intentan resolver los desmanes cometidos durante la etapa de desarrollo sino que se aportan todas las ideas y nuevas funcionalidades que a uno se le ocurran para alargar lo más posible el mantenimiento.

  8. Gravatar Piluso | 08/05/2009 at 11:53 | Permalink

    Me parece, Mac, a la luz de los comentarios que preceden, que aquello de “el software está en crisis”, da en el clavo…, no? Muy bueno este nuevo artículo.

  9. Gravatar Jimmy Jazz | 08/05/2009 at 11:55 | Permalink

    Efectivamente cuando una Charcutera digooooo una Consultora negocia con los clientes, lo gordo es quedarse con el mantenimiento de la aplicación (por lo menos lo que yo he visto). Siempre hay incidencias que resolver (tiene que ser horrible estar en un CAU); y según la empresa y la aplicación, son aplicaciones bastante “vivas”… ampliaciones, cambios, que si abrimos más almacenes, que si se cambia nosequé en las facturaciones… o si se está desarrollando en paralelo la aplicación nueva a la que se va a migrar, la vieja también suele tener mucho curro; es bastante diferente a una aplicación del mundo PC donde una vez está hecha ahí se queda (hasta que saan una nueva versión o lo que sea).

    Salud, y Mac genial, as usual! ;)

  10. Gravatar Macluskey | 08/05/2009 at 12:56 | Permalink

    ¡Qué excelentes comentarios, amigos!

    Hay de todo, como en botica. hay quien prefiere hacer siempre cosas nuevas (y si puede ser, vender lo mismo a diversos clientes una y otra vez como si fuera nuevo; conozco a algún que otro experto en esto), y los hay que se matan para conseguir el mantenimiento (por la cosa de que una vez conseguido, es muy difícil cambiar de proveedor, lo que te asegura contratos a largo plazo, aunque con menos margen). Lo que sí que ocurre casi siempre es que todos te venden su recojometodología-ISO tropecientos, y luego hacen las cosas como las hacen… y no quiero ser cruel. Pero es que es normal.

    Y conozco los dos lados de la moneda: Yo también he sido proveedor algunos años, hace algún tiempo, y lo que te interesa es “tente mientras cobro”; una vez entregas la aplicación y te pagan… piés para qué os quiero; toda petición posterior de cambio requiere sistemáticamente un Estudio del copón, afecta precisamente a la parte nuclear del Sistema, bla, bla, bla… En fin, nada nuevo bajo el sol.

    Creo que la próxima entrada (que está escrita hace algunas semanas) os va a encantar aún más que ésta… ya me diréis.

    Gracias por comentar

  11. Gravatar Macluskey | 08/05/2009 at 01:01 | Permalink

    @cruzki: Esta noche o mañana te envío un emilio con mi dirección. Esta tarde tengo un Concierto (el de Violonchelo de Shostakovich) y no me lo pierdo ni con 40 de fiebre…

    @Piluso: No es el software el que está en crisis… es la forma de escribir software la que está, no en crisis, sino más bien en liquidación por derribo… Creo que ya hablamos de esto mismo en la entrada anterior. Desde que el negocio de la informática se convirtió en un Negocio, las cosas son diferentes. Prima el margen, el beneficio, más que la calidad (por otra parte, si montas un negocio es para ganar dinero, no para hacer favores a los clientes, ¿cierto?). Así que… así están las cosas, amigo. ¡Qué te voy a contar que tú no sepas!

    Saludos

  12. Gravatar Piluso | 08/05/2009 at 02:59 | Permalink

    De eso hablamos, Mac, de eso hablamos: que la escritura de software no sea como el concierto para Violonchelo de Shostakovich:)

  13. Gravatar Macluskey | 08/05/2009 at 03:44 | Permalink

    ¡Y que lo digas!

  14. Gravatar Brigo | 08/05/2009 at 10:21 | Permalink

    Yo fui uno de esos técnicos reciclados a informáticos. Tengo muy buenos recuerdos de aquellos años.

  15. Gravatar Macluskey | 09/05/2009 at 07:54 | Permalink

    @cruzki: Te he enviado un emilio… espero que la hoayas recibido, en otro caso, avísame.

    ¡Qué bueno el Concierto de ayer…! El nº 1 de celllo de Shostakovich y Sheherezade, de Rimsky-Korsakoff… Aaahh!

  16. Gravatar cruzki | 09/05/2009 at 02:47 | Permalink

    @mac

    Recibido. En un rato tendrás noticias mías ;) Muchas gracias.

    @Mazinger

    La verdad es que estoy de acuerdo en que el NEGOCIO esta en el mantenimiento (tanto de software como de hardware) pero me da la sensación que lo que prima es la visión de Mac:

    • Te hago software rápido y barato (que por supuesto va de pena) y luego te clavo un huevo por el mantenimiento… que encima no te lo hago, o te lo hago a cuentagostas…

    O por lo menos eso es lo que yo he visto/sufrido en la universidad (tampoco es que tengo mucha experiencia, pero a poco que intentas algo “raro” empiezan a salir problemas por todos sitios y no te quejes…)

    Y la verdad es que me cuesta creer que eso no sea así en todos sitios. Si ni siquiera los desarrollos internos son decentes (por ejemplo, las trabajos fin de carrera etc.) no me quiero ni imaginar lo que venga de fuera.

    @ Mac

    Ahora que me doy cuenta, ¿hablarás de software libre y del aparente proceso de migración hacia él que parece que se está llevando a cabo en según que sectores?

  17. Gravatar Macluskey | 09/05/2009 at 02:53 | Permalink

    @cruzki: ¿Hablar del Software libre? No creo.

    Me he puesto como límite temporal aproximadamente el año 2000. Desde entonces yo no he estado ya tan metido en temas de día a día, y debería hablar mucho de oídas, lo que no es el espíritu de la serie (que trata sobre todo de lo que yo he visto, vivido y sufrido), pero es que además hay colaboradores de elcedazo (como tú mismo, amigo) con muchísimas más atribuciones que yo para contar ese proceso.

    Así que allá por el año 2000, seguramente con el pinchazo de la burbuja puntocom, me pararé, que ya está bien de dar la lata…

    Saludos

  18. Gravatar Mazinger | 09/05/2009 at 06:14 | Permalink

    @Cruzki

    Los informáticos no hacemos lo que se nos pide sino lo que podemos con el tiempo que se nos ha concedido (como diría Gandalf). ;-) ¿Has oído hablar del Proyecto Bicicleta? Si no, sigue este enlace para echar unas risas a cuenta del mantenimiento informático…

    http://www.alfredodehoces.com/press/proyecto-bicicleta

    En el fondo estamos de acuerdo, simplemente nuestras experiencias han sido algo diferentes. ;-)

    @Macluskey

    ¿Terminarás con la burbuja puntocom? ¡Qué bueno, justo desde donde yo pensaba arrancar cuando cuente algo sobre los orígenes de la subprime! Nada mejor que el refranero: un clavo saca a otro clavo (la formación de una nueva burbuja “arregla” el desastre de la explosión de otra anterior, así va el mundo).

  19. Gravatar J@viLinuX | 12/05/2009 at 12:06 | Permalink

    Jajaja, muy bueno lo del Proyecto bicicleta, Mazinger. Sería estupendo que nos contases algo así como la segunda parte de Mcluskey.

    @Mcluskey Te he seguido durante toda la serie (pero NO se me ocurría que decir…). Me encanta la forma que tienes de escribir (a pesar de que dices que te excedes en demasía!!!, NO LO CREO). Espero con impaciencia la parte de las herramientas CASE…

    Hasta la próxima.

  20. Gravatar Macluskey | 12/05/2009 at 07:00 | Permalink

    Sí, J@viLinux, sí… ¿Tú nunca has hecho un proyecto bicicleta…? ¿Y, encima, sin ruedas…? Que levante la mano el que esté libre de pecado, porque no le queda mucho para pecar…

    Muy buen enlace, Mazinger… como siempre, acertado.Y sí. Tengo la sana intención de acabar con la burbuja puntocom (contada desde mi peculiar y extraño punto de vista, claro), ¡pero aún tendréis que esperar cuatro o cinco artículos…! …si es que no me puedo callar… ¡ni debajo del agua!

    Saludos a todos y gracias por vuestros comentarios

  21. Gravatar joel | 13/05/2009 at 01:52 | Permalink

    Hace año y medio en barrapunto comentaban que la UOC había liberado todos los materiales de los masters sobre software libre.

    http://softlibre.barrapunto.com/article.pl?sid=08/08/05/2032227

    Entre ellos hay un master de Ingeniería del software en entornos del software libre en el que se explican, entre otras cosas, muchas cosas de las que cuentas, entre ellas un poco acerca de la Métrica 3.

    http://ocw.uoc.edu/informatica-tecnologia-y-multimedia/ingenieria-del-software-en-entornos-del-software-libre/Course_listing

    La ingeniería del software es un tema que siempre me ha fascinado, (algún día intentaré sacarme la asignatura) y la veo inalcanzable y algo utópica. Gracias a tu artículo me consuela ver que casi nadie lo sigue a rajatabla. (MAL DE MUCHOS, CONSUELO DE …) Y tengo la impresión de que los que tienen acabada la carrera no sabrán mucho más …

    En fin, todo un arte.

    Como decían en Piratas del Caribe, no son unas “leyes” estrictas sino sólo unas DIRECTRICES.

  22. Gravatar Macluskey | 13/05/2009 at 07:03 | Permalink

    No, joel, no es un arte… Te aseguro que el Modelo de Entidad-Relación es sencillo, compresible, utilizable y sobre todo, útil. Mucho.

    Usando herramientas CASE, como por ejemplo Erwin, especializada sólo en Modelos de Datos, genera los creates para las tablas, las copys… para cualquier base de datos del mercado. Y también hace reingeniería inversa: toma las definiciones de las tablas del Catálogo y crea un modelo de datos, imperfecto, claro (salvo que hayas usado “integridad referencial”, en cuyo caso sí que reconstruye perfectamente el modelo de datos… lo que pasa es que si has usado “integridad referencial”, tu aplicación probablemente no funcionará, pero bueno).

    El problema no son las técnicas en sí… el problema es el Ciclo de Vida de las Aplicaciones. Sufren modificaciones, hechas por personas que no conocen la aplicación, y que, presionados por el tiempo, hacen cualquier chapuza. Y claro, cuando hay que hacer setecientos formularios para cumplir una metodología… o no se hacen, o no se actualizan después… simplemente PORQUE NO SE PAGAN. Así de simple.

    El tema da para muchísimas conversaciones, de hecho entre esta entrada y la siguiente hay más de doce mil palabras… y me he dejado en el tintero muchísimas cosas… en algún punto hay que poner la raya…

    Gracias por tus comentarios y tus enlaces.

  23. Gravatar pucelano | 07/06/2009 at 03:48 | Permalink

    Una nota. En el Ayuntamiento de Valladolid, cada vez que piden un desarrollo por nimio que sea, siempre piden que se cumpla métrica 3. Lo han usado varias veces para no adjudicar a las empresas de informática serias pero pequeñas de la zona. Y nadie -nadie- ha visto nunca informes conformes a métrica 3 de programas adjudicados.

  24. Gravatar Alfonso FR | 13/06/2009 at 11:33 | Permalink

    Ooooh… Eso de que con MAESTRO “apretabas una tecla y aparecía casi al instante” me ha hecho soltar la lagrimilla, recordando los teminales VT de la uni. La gente “tuneaba” sus usuarios UNIX para que aparecieran animaciones con caracteres en pantalla al hacerles un “finger/whois”.

  25. Gravatar Cesar | 27/10/2009 at 04:52 | Permalink

    Ains, que me estais metiendo el miedo en el cuerpo, que acabo de empezar en esto de estudiar, que no aprender, a desarrollar software (que si análisis, que si programación, que si sistemas). Fuera cachondeos, en realidad el problema de la informática es el mismo que el que hay en culaquier actividad comercial, y no tan comercial, ¡Prima los márgenes, por encima de la satisfacción del cliente! y éso a la larga es algo muy peligroso. Siempre habrá empresas que después de un fracaso tendrán un acierto, éso es así, -lease el caso de Microsoft con su Vista y su posterior upgrade a Windows 7- En ese aspecto los pequeños no pueden competir, y los grandes manejan los estándares como se les pasa por el mismísimo.

    Una gran pagina de artículos. La he descubierto en clase.

    Un saludo

  26. Gravatar Venger | 20/01/2012 at 12:41 | Permalink

    Errata: creo que hay una errata casi al final: donde dice “de hacer aquéllo por lo que “, debería decir de hacer aquello por lo que”.

    Por otra parte, me voy a crear una base de datos con el léxico nuevo que estoy aprendiendo contigo, Mac: paladino, arcano, palmaria…

    Y otra reflexión, si me permitís: me resulta preocupante leer vuestros comentarios acerca del menoscabo de la calidad de los software. Me gustaría saber si creéis que eso se produce también en aplicaciones vitales, como por ejemplo en navegación aérea o en la exploración espacial. Yo estoy seguro que no, que los sistemas operativos y los programas tienen que ser muy sólidos. De hecho, sería interesante que alguien no lego en la informática escribiese algo al respecto.

  27. Gravatar Macluskey | 20/01/2012 at 06:51 | Permalink

    Bueno, no quisiera ser negativo. Pero me cuesta no serlo.

    El software que últimamente he podido probar, testar, o, en muchos casos, sufrir, tiene cada vez peor calidad. Da igual que lo hagan mis compañeros de Informática o haya sido adquirido a la compañía de software de turno, por grande que ésta sea y caro que resulte el dichoso software. Suele tener carencias importantes de todo tipo: de interfaz, de funcionalidad y no digamos nada de rendimiento…

    Y en el origen de todo está, a mi modesto entender, el que la labor de desarrollar software ya no se toma como una responsabilidad (para tus clientes, tus compañeros o quien sea), sino como un medio puro y duro de hacer negocio.

    Se lleva la programación a la India o a Pakistán, los equipos de mantenimiento se preocupan más por cumplir sus ratios (es decir, que “parezca” que todo va bien) a que realmente las cosas vayan bien, la comunicación de los usuarios con Informática es cada vez más frustrante…

    En fin, es flor de los tiempos. Basta con que enciendas el televisor o leas la prensa para que te des cuenta de que lo importante no es hacer las cosas bien, sino contarlas para que parezca que lo están. ¿O no?

    Bienvenido al Siglo XXI.

  28. Gravatar Sergio B | 23/01/2012 at 01:58 | Permalink

    Pues yo no lo creo, quiza sea cosa de los programas que uso yo, de elementos finitos, pero la verdad es que las versiones nuevas suelen ser mejores, en interface, en caracteristicas y en todo. Ademas el sistema tecnico suele responder, aunque si es por cuestiones nuevas como suelen ser, la realidad es que ni ellos saben como funcionan bien. No es que sean incompetentes, si son cosas que estan en desarrollo y alguien las hace para una barrita que tiras de ella, pues se lo mete a la simulacion de una estructura compleja y pasa lo que pasa, pero vamos, pa eso estoy yo aqui, no el informatico. Vamos, yo creo que el problema es que la gente cada vez quiere hacer menos y parece que los ordenadores sean genios de la lampara. A mi se me grabo una frase de un profesor de programacion: “el ordenador es idiota, no sabe hacer nada que no le digas tu como hacer”, y la verdad es que he vivido mucho mas tranquilo desde entonces.

    Pero vamos, recuerdo de mis clases de filosofia, cierto mecanismo psicologico, de olvido selectivo, lo que me hace ser bastante critico en cuanto oigo “tiempos pasados siempre fueron mejores…” Vamos, al fin y al cabo, fueron las masas de informaticos de tu epoca, las que han levantado a las actuales, y a no ser que tuvieseis muy mala leche, me imagino que incorporariais cosas necesarias para ir a mejor, no a peor. Yo que se, se hacen cosas impresionantes, y cada vez mas y mejor, sobre todo en informatica.

  29. Gravatar Gonzalo | 24/02/2015 at 09:29 | Permalink

    Llevo varios días enganchado a esta serie, tanto al texto de Mac como a los comentarios. La calidad es altísima en el contenido y en cómo está escrita (literatura de calidad). ¡¡Es la PRIMERA vez en mi vida, después de que lo dijera mi profesora de latín, que oigo (leo) a alguien decir CURRICULA para referirse al plural de curriculum!! Amé la informática desde que en el año 83 vi ordenadores (un Apple II y un VIC-20) en la clase de EATP del instituto (nunca supe lo que significaba EATP) y más cuando lei, intentando entender una línea de un listado que venía ser 40IFX>20THENGOTO100 y la entendí y dije: con esta herramienta (IF…THEN) se puede llegar a construir inteligencia artificial. Yo, viendo al ser humano en su conjunto, dudo que exista la inteligencia natural, pero bueno… que me quedé enganchado a estos ‘paratos’ leyendo y practicando todo lo que podía.

    Trabajé en un algún CPD en COBOL/400 y en ILE RPG, como operador de AS/400 en otro sitio y ahora soy auxiliar de cartería (no hay ni un PC en todo el almacén, es decir, sólo uso el ‘parato’ en casa). Y tan contento. El mes que viene compraré el libro de Mac porque joyas como ésta de la historia de la ciencia y de la ciencia en sí hay que protegerlas incluso más allá de Farenheit 451.

    No diga, Sr Macluskey, que nos da la lata, que habla mucho, que tiene verborrea… Para mi gusto es POCO porque lo bueno muy bueno no cansa.

    Saludos, mis respectos al máximo, y, POR FAVOR, más. Más. Más. Más…

  30. Gravatar Macluskey | 25/02/2015 at 05:43 | Permalink

    @Gonzalo:

    Ja, ja, efectivamente, pocos saben que el plural de curriculum es curricula… como seguramente pocos saben que el singular de DATA es DATUM (sí, lo correcto nunca sería EL Big Data, sino LOS Big Data, los “datos grandes”…). Ni que Media (como en Mass Media) es el plural de medium. Si mi memoria no me falla, segunda declinación, ¿no? ;)

    Gracias por el panegírico, amigo.

  31. Gravatar Sergio B | 26/02/2015 at 01:52 | Permalink

    Pues por lo que yo he leido por internet, con referencias a articulos de la RAE que no he sabido encontrar, por ser sincero, el uso de curricula es incorrecto en castellano, o bien dices los curriculum vitae o dices los curriculos. Usar el plural curricula parece ser correcto en ingles, como supongo lo sera usar data y datum, que nosotros usariamos dato y datos, sino nos gustase usar anglicismos cuando son completamente innecesarios, ya que no creo que lo hagamos por rememorar el latin. Respecto a media, yo si creo que es un conocimiento bastante amplio, ya que siempre se dice los mass media y cuando se habla de uno se dice medio, que viene a ser lo suyo.

  32. Gravatar no_puedorr | 23/11/2015 at 06:08 | Permalink

    @Sergio B y para todos en general.

    No puedo estar mas de acuerdo en lo que se dice sobre la calidad de Software. Actualmente trabajo dando soporte a los usuarios de una oficina. Para un informático es fácil siempre decir eso de que el usuario no tiene ni idea y que por eso pasa lo que pasa, que si va lento es porque lo habrá llenado de porquería, etc. Yo hace tiempo que me baje de ese burro. ¡¡Es culpa del Software!!.

    En esta empresa hará cosa de 3 años, quizá 4, empezamos a cambiar equipos Core 2 Duo o incluso Pentiums IV que por lo general tiraban con sus 2 GB de RAM. Este cambio lo terminamos de hacer más o menos el año pasado y ahora todo el mundo “disfruta” de sus Core I3 pa’rriba y sus 4 GB de RAM pa’rriba. Pese a esto no dejo de frustrarme cuando un usuario me dice que va lento…y es verdad (como iba entonces con el Core 2 Duo mas o menos), cuando ves que en un ordenador el antivirus se como la mitad de los recursos, cuando en un equipo de estas características ves que en arrancar Outlook (UN SIMPLE GESTOR DE CORREO), Skype Empresarial (o sea Messenger, pero peor) y Lotus Notes te puedes tirar alrededor de 10 minutos (eso si luego si tiene el día bueno a lo mejor el equipo va…regular), pues eso que da penita.

    Yo hago mis pinitos en programación lo suficiente para darme cuenta de que estoy programando bajo chopocientas capas de Framework y sobre un sistema Windwos que va “virtualizado” sobre una capa de abstracción de hardware para que se adapte a tantos equipos diferentes. Eso unido a los problemas que habéis descrito, o sea que mucho o casi todo es negocio hace que gente como Macluskey hablen con escepticismo de la informatica actual. Resumiendo, que para cuando llegas a tu poderoso Core I7 recibe tu peticion esta ya ha pasado por mas niveles que pisos tiene el Empire State incluido la codicia y el mal hacer de algunos creadores de software.

    Vamos, que cuando voy por la oficina antes me pedían que les cambiara un ordenador porque de veras eran viejos, ahora me piden que les ponga 4 GB (el doble) mas, un disco SSD,…total mientras se pueda tapar todo esto con hardware vamos bien no?…

    O eso o meten ‘Do Sleep Loop’ en el código o yo que se, porque peor no se puede hacer.

    Creo que dejare la informática y montare una granja pollos…¿alguien se apunta?

  33. Gravatar telmar | 12/04/2019 at 07:51 | Permalink

    Buenos días! .Me gustaría dar un enorme aprobado por amena información que tenemos aquí en este sitio . Voy a volver muy pronto a divertime con esta web.

{ 1 } Trackback

  1. Gravatar meneame.net | 07/05/2009 at 05:16 | Permalink

    Historia de un Viejo Informático. Aparecen las Metodologías de Desarrollo para facilitarnos la vida…

    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 oc…

Escribe un comentario

Tu dirección de correo no es mostrada. Los campos requeridos están marcados *

Al escribir un comentario aquí nos otorgas el permiso irrevocable de reproducir tus palabras y tu nombre/sitio web como atribución.