Magazine de Información Independiente sobre Nueva Economía y Mercados de las Tecnologías de la Información

También puedes descargar el Magazine en PDF.

por Stuart Shapiro

Durante el último cuarto de siglo, los tecnólogos del software han trabajado con tesón para enfrentarse a la "crisis del software" que fue identificada en los años 60. Sus esfuerzos han situado el foco de interés en diversas áreas, pero con frecuencia se han dirigido a la búsqueda de soluciones óptimas a problemas particulares. Sin embargo, la naturaleza fundamental del software (que implica procesos básicos no demasiado bien entendidos aplicables a la resolución de problemas muy diversos, junto con una complejidad multifaceta sin precedentes) pesa muy fuertemente en contra de la utilidad de las aproximaciones singulares a los problemas de orden metodológico que afectan a la disciplina de la ingeniería del software.

Un examen atento del discurso de los tecnólogos a través de los artículos de un número importante de publicaciones profesionales y de revistas al uso a lo largo de los últimos 25 años, descubre la existencia de varias disputas en torno al núcleo fundamental de la ingeniería del software y pone de relieve la necesidad de un enfoque más plural e interdisciplinario para abordar los problemas relacionados con la síntesis metodológica de esta disciplina.

Hacia el final de los años 60 se estaba empezando a hacer obvio para la comunidad de profesionales informáticos que el software era un grave problema y que el paso del tiempo iba a empeorar aún más la situación. Las primeras conferencias internacionales sobre ingeniería del software, organizadas por la NATO en 1968 y 1969, pusieron de manifiesto que los grandes proyectos adolecían casi unánimemente de problemas análogos de retraso en los plazos, sobrecoste y una gran cantidad de fallos y defectos. Hoy día las quejas siguen siendo básicamente las mismas, y de ahí la naturaleza endémica de los problemas.

El esfuerzo formalizador y metodológico emprendido por los tecnólogos llevó a poner de manifiesto una de las razones que pueden esgrimirse como causa de los problemas: la complejidad de los sistemas, que se deriva de la naturaleza abstracta del software y del hecho que los programas constituyen artefactos discretos basados en la lógica matemática, que se comportan de forma muy distinta de los modelos que estudia la ingeniería tradicional, habitualmente continuos y de naturaleza analógica. El software se caracteriza por lo que Fred Brooks llama una "complejidad arbitraria", que es conceptualmente distinta de la complejidad de los sistemas físicos, mejor sujeta a patrones.

La complejidad asociada a la tecnología del software no es por tanto directamente atacable mediante formalismos metodológicos unificados, ya que implica numerosas facetas y dimensiones. El contexto en que debe analizarse la complejidad incluye entre otras, cuestiones tan profundas como la eficiencia algorítmica, la estructuración de procesos y datos y el esfuerzo psicológico necesario para entender los problemas, traducirlos en términos lógicos y diseñar los sistemas capaces de computarlos o procesarlos correctamente. Esta riqueza de cuestiones ha ido dando paso a una gran variedad de aproximaciones teórico-prácticas relativas a la programación estructurada, la métrica del software, la verificación de los programas, los métodos formales, los lenguajes de programación, los modelos de ciclo de vida y los entornos de desarrollo.

Ninguna de las soluciones propuestas a lo largo de las tres décadas que han pasado desde que se acuñó el término "ingeniería del software" ha sido capaz por sí sola de proporcionar alivio suficiente a la comunidad técnica. Acuerdos sobre la validez razonablemente general y aceptable de aproximaciones concretas a cada una de las cuestiones enunciadas en el párrafo anterior no han sido posibles, debido en parte a la ingente variedad "filosófica" que subyace en cada uno de los métodos examinados y por su imposibilidad para abordar dentro de un marco unificado la diversidad aparentemente inagotable de singularidades técnicas y excepciones que constituyen norma habitual en la práctica real de esta disciplina.

Una acción efectiva para resolver las dificultades expuestas requiere un espíritu de acomodación pragmática entre la naturaleza de los problemas y la validez de las soluciones propuestas (fundamentos teóricos y disciplinas prácticas), admitiendo una especie de pluralismo y de tolerancia tecnológica que no parecen ser fáciles de conseguir, al menos hasta el momento, dentro de la comunidad de los tecnólogos del software. Durante estos años se ha teorizado, polemizado, propuesto y refutado largamente. He aquí algunos de los hitos más significados:

• Las conferencias de la NATO en 1968-69, que tuvieron lugar respectivamente en Garmisch y Roma, y que sirvieron para fijar los problemas básicos sobre dimensión, complejidad y rendimiento del software. Entre los principales actores hay que recordar a Ross (M.I.T.), David (Bell Labs), Needham (Cambridge University) y Aron (IBM).
• La polémica creada en torno a un artículo publicado en 1971 por Nicklaus With en la prestigiosa revista Communications of the ACM sobre el concepto de modularidad del software. A lo largo de varios años, padres fundadores de la ingeniería del software como Parnas, Myers, Liskov o Zilles discutieron y elaboraron propuestas para el tratamiento de esta cuestión, sólo parcialmente resuelta.
• El debate sobre la abstracción de las estructuras de datos y de los procedimientos en los lenguajes de programación: La inició Guttag en 1977 y adquirió magnitud a través de Simula y Smalltalk con los noruegos Nygaard y Dahl, dando origen a lo que años más tarde se denominó "orientación a objetos".
• La pugna desarrollada con motivo de los métodos y de los lenguajes estructurados, iniciada en los años 70 y que se prolongó durante más de una década. Aquí se deben recordar los nombre de Jackson, Orr, Warnier y Constantine y los de sus críticos Abrahams, Berry y Clemens entre otros.
• La publicación de un libro excepcionalmente impactante en la comunidad del software, "The Mythical Man-Month", escrito por Brooks, el manager del proyecto del OS/360 de IBM, que atrajo la atención sobre cuestiones prácticas como la dinámica de los equipos de programadores, la escalabilidad del soft, los principios de diseño y las técnicas de estimación de proyectos.
• El impacto de los trabajos de la "escuela matemática", en la que se sitúan Mills, Hoare y Dijkstra, partidarios de conducir los procesos intuitivos de la programación hacia modelos rigurosos aplicables a la construcción de soft, basados en la lógica formal y en las matemáticas.
• Los estructuralistas, que formularon propiedades de la complejidad, fiabilidad y mantenibilidad del software a partir del estudio de las propiedades estructurales de los programas. Entre ellos se puede destacar a Halstead, Mc Cabe, Kernighan, Myers y Plauger.
• Los representacionistas, tanto intuitivos (Chen) como formales (Codd), cuya influencia metodológica en la modelización de datos es bien conocida, y los impulsores de la denominada cuarta generación (4GL) como Martin, Read y Harmon.

La lista anterior podría prolongarse largamente más allá de la paciencia del lector sin variar esencialmente la valoración que se establecía al principio de este artículo. Para finalizar hay que recordar las palabras con que se clausuraba la mesa redonda de expertos en la Conferencia Internacional de Ingeniería del Software de 1978: "los problemas de los '80s se parecen mucho a los problemas de los '70s y son deprimentemente similares a los de los '60s". En la conferencia de 1985, Geoffrey Pattie, ministro de estado británico de Industria y Tecnología de la Información, parecía confirmarlo años más tarde: "Para decirlo de forma clara, demasiado software se entrega en condiciones insatisfactorias, muy a menudo tarde, a un coste elevado, con fallos inaceptables".

Ya en esta década de los '90s, la revista Scientific American, intentando explicar la crisis crónica del software concluía con desánimo "la persistencia de la crisis es decepcionante". La necesidad histórica de una síntesis de los fundamentos teóricos y de los métodos prácticos de esta joven rama de la ingeniería ha de conjugarse con el pragmatismo que imponen a la industria las condiciones de nuestra época.

Stuart Shapiro es Doctor por Carnegie-Mellon University y desarrolla una notable actividad investigadora sobre la historia y sociología de la ingeniería del software. Actualmente es investigador visitante de la Brunnel University, en el Reino Unido. Este artículo es un breve resumen de uno más amplio que tiene por título "Splitting the Difference: The Historical Necessity of Synthesis in Software Engineering" publicado en IEEE Annals of the History of Computing. El Dr Shapiro puede ser localizado en la siguiente dirección de correo electrónico: s_shapiro@acm.org.

• Opina sobre este tema en Un Foro Para TI.
• Escribe a la redacción con tus comentarios sobre este artículo.

Puedes examinar artículos aparecidos en números anteriores:

• ¿Internet o no Internet?: Internet segura

© 1999 Tecnova.