0901 Preguntas

En busca de respuestas
para la ingeniería software
Nelson Medinilla Martínez

Primavera del 2005
En busca de respuestas para la ingeniería de software Nelson Medinilla Martínez
Tabla de contenidos
1. Introducción................................................................................................................................3
2. Fundamentos filosóficos de la temprana ingeniería de software................................................4
3. Consecuencias prácticas de la influencia filosófica...................................................................6
4. Influencia de la incertidumbre ...................................................................................................8
5. Otra alternativa filosófica...........................................................................................................9
6. Respuestas................................................................................................................................11
6.1 El diseño.............................................................................................................................12
6.2 Reproducir la realidad en el diseño....................................................................................14
6.3 Objetos vs. estructurado.....................................................................................................15
6.4 Las metodologías................................................................................................................17
6.4.1 Problemas....................................................................................................................18
6.4.2 Estrategias....................................................................................................................19
6.4.3 Problemas, estrategias y modelos de solución............................................................23
6.4.4 Metodologías...............................................................................................................24
6.5 Recapitulación ...................................................................................................................33
7. Conclusiones.............................................................................................................................34
Bibliografía...................................................................................................................................35
2
1. Introducción
La construcción de software ha avanzado mucho, pero todavía hay innumerables
preguntas importantes sin responder.
Los objetos software y el carnaval de serpentinas que los rodea parecen ser una moda.
¿Lo son? Últimamente, se oye una jerga de términos extraños (Java, C++, patrones, J2EE, …)
en los bares, trenes, metro, y hasta en las cenas románticas, donde él (siempre es él) usa esos
términos, como el pavo real su cola, para demostrar a una ella (siempre aburrida). La misma
treta puede dar resultados con los jefes, los entrevistadores de recursos humanos y los clientes
que oyen lo que quieren oír, pero profesionalmente hablando:
¿Cuándo, cómo, por qué usar objetos en vez de estructurado? Más aún, ¿qué es
estructurado y qué es objetos? ¿Cuánto de verdad hay en las ventajas que dicen los defensores
de los objetos? ¿Conviene que el software sea un modelo de la realidad? ¿Por qué se cree que la
modularidad del software facilita las modificaciones cuándo realmente no lo hace? ¿Qué hacer
para facilitar las modificaciones del software?
¿Por qué fue distorsionada la programación estructurada original, al punto de creer hoy
que es algo que no es? ¿Por qué ha sido maldecido y desvirtuado el principio de ocultación de
información? ¿Por qué se han dejado de lado las estructuras abstractas de datos?
En el campo del proceso de construcción de software: ¿Cuándo usar una metodología u

otra? Todas pugnan por ser adoptadas; sus autores dicen que expresan la mejor práctica, desde
las clásicas hasta las recientes y hay cientos de metodologías para escoger. Todas se
autoproclaman universales, sirven para construir cualquier software. Ninguna ingeniería tiene
metodologías universales para construir cualquier producto. ¿En qué se diferencian unas de
otras? Hay incluso metodologías con manifiestos, como aquél de “un fantasma recorre el
mundo” ¿Se ha quedado la técnica sin argumentos técnicos y recurre a las emociones para ganar
prosélitos?
¿Cómo interpretar una metodología de desarrollo de software? Por ejemplo, ¿el Proceso
Unificado es una sucesión de ciclos en Cascada o es otra cosa, radicalmente distinta? ¿Se podría
utilizar eXtreme Programming para construir software estructurado o mejor, qué metodología se
debe usar con qué modelo de software? ¿Qué relaciones existen entre modelos de software
(objetos, estructurado,…) y metodologías, considerando que hay metodologías estructuradas
para diseñar software de objetos?
En temas más generales ¿por qué hubo que esperar hasta mediados de los noventa para
incorporar los patrones al software, cuando los patrones son elementos cotidianos de cualquier
3
profesión? ¿Por qué hay tan poca experimentación, en sentido estricto, en la ingeniería de
software, cuando es usual en el resto de las ingenierías? ¿Por qué se ha abandonado
prácticamente la línea de investigación sobre complejidad del software? ¿Por qué ha sido
insuficiente el diluvio de metodologías? ¿Por qué tantas cosas sin responder?
Cada gurú tiene su propia respuesta, más aún cada constructor de software tiene la suya
propia, que es la mejor, por supuesto. Prevalece el criterio de autoridad: “lo dijo fulano”. Pero
faltan las respuestas universales que tiene cualquier ingeniería y su ausencia ha producido
desconcierto, confusión, empirismo, frustración. Hay demasiadas alternativas y ninguna ofrece
argumentos sólidos; se diseña objetos como si fuese estructurado, y se aplica el Proceso
Unificado como si fuese un desarrollo en Cascada; casi nunca hay suficiente tiempo para los
requisitos y casi nada de lo aprendido en los libros se utiliza en la práctica; para qué tanto
estudio, si cualquiera construye software.
Después de muchos años de empirismo se descubre que hay respuestas universales y

que están en el lugar común de las preguntas trascendentes: la filosofía. Aunque parezca
inverosímil, una visión filosófica enraizada desde el siglo XVII ha sido la guía fundamental,
casi el manual, para la construcción de software. Fue el impulso y la luz de los primeros pasos,
pero lo hizo con tanta fuerza que deslumbró otras perspectivas clave. El análisis de las
tendencias actuales del desarrollo de software señala que la perspectiva filosófica ha cambiado
radicalmente, si bien todavía no se tiene conciencia de ese cambio.
Todas las preguntas técnicas que se han enunciado en esta introducción pueden ser
respondidas desde la visión filosófica del universo software. Ahí se encuentran las respuestas y
los cimientos de las posibles teorías que permitan describir y predecir las propiedades de
modelos, diseños y metodologías software. Por razones de espacio y tiempo, cada uno de los
temas ha sido tratado de forma resumida. Cada uno de ellos requiere de un trabajo aparte.
2. Fundamentos filosóficos de la temprana ingeniería de software

A finales de los años sesenta del siglo XX se quiso convertir el software en una
industria y la ingeniería de software apareció como una declaración de intenciones. A partir de
ahí comenzó una lluvia de innumerables elementos metodológicos con el fin de edificar los
cimientos teóricos de la nueva industria y de la nueva ingeniería. Se quería dejar atrás la
confusión de los años precedentes y establecer un orden sólido, claro y preciso en la
construcción de software.
Los fundadores de la ingeniería de software tomaron como modelo las ideas contenidas
en el “Discurso del método para dirigir bien la razón y buscar la verdad en las ciencias”, escrito
por Descartes y publicado en 1637. A fin de cuentas, Descartes también se había propuesto
4
eliminar la confusión en su mundo mediante una explicación racional y científica. “Buscando

desesperadamente la verdad indubitable, el firme asidero, la certeza absoluta, Descartes
descubre que las matemáticas poseen esos rasgos que él está deseando para sus ideas vitales e
intenta darle a la filosofía el mismo grado de exactitud de las matemáticas utilizando el mismo
modelo. Su fe filosófica es una fe matemática, en definitiva una fe absoluta en la razón
humana.”
La premisa de Descartes era que todo se puede conocer o dicho de otro modo, que la
incertidumbre es erradicable. “no puede haber ninguna [cosa], por lejos que se halle situada o
por oculta que esté, que no se llegue a alcanzar y descubrir.” Y creía, además, que la clave para
alcanzar ese conocimiento es el método, porque el método equivale al compás para trazar una
circunferencia perfecta, independiente del pulso del dibujante. Suponía que la razón es igual
para todos los humanos y que no todos llegan a la verdad por falta de método. “lo importante no
es tener un buen entendimiento, sino aplicarlo bien […] Si la ciencia es una, si la naturaleza
humana es única, si el método matemático es, con orden y cuidado, exacto, bastará utilizar la
razón metódicamente para encontrar una verdad incuestionable de donde se puedan deducir
otras certezas.” Cualquier verdad es alcanzable con el mismo método.
Los pensadores principales de la época compartían la misma premisa y la misma

obsesión por el método aunque existían diferencias respecto al método. Descartes en particular,
depositó toda su fe en la razón, desestimando el camino de la experiencia, porque “nunca
estamos seguros que un nuevo hecho venga a desmentirnos”
Preocupado por los prejuicios Descartes rechaza como falsas todas las razones que
anteriormente había tenido por demostrativas. Es decir, rechaza todas las soluciones previas
porque “Nadie podrá ejercitar en forma atinada su razón si está lleno de prejuicios, que estorban
al libre discernimiento y la búsqueda correcta.”
Las principales ideas en boga de la temprana ingeniería de software tenían el mismo

discurso que el Discurso del Método cartesiano, aunque apenas se menciona esta coincidencia
casi literal:
• El software adopta una forma matemática. Se define cualquier sistema software

como una función de transformación de datos.
• El método de desarrollo de software se considera la clave del éxito y universal para

cualquier (verdad) sistema software. La culpa de los fallos recae en la forma de
aplicación, la falta de tiempo, la veleidad de los clientes, el dinero vil; casi nunca en
la esencia del método. La infinidad de variantes y métodos intenta paliar esas causas
accidentales, no esenciales. Se busca El Método como si fuese El Dorado o mejor,
5
la piedra filosofal capaz de convertir cualquier conjunto de requisitos en un sistema

software; una receta para triunfar, independiente del problema y de las capacidades
humanas.
• El método básico de desarrollo de software coincide con el método cartesiano. La

etapa llamada Requisitos con el precepto de evidencias: “no admitir como
verdadera cosa alguna que no supiese con evidencia que lo es”. La etapa llamada
Análisis con el precepto de análisis: “dividir cada una de las dificultades que
examinare en cuantas partes fuese posible y en cuantas requiriese su mejor
solución”. Las llamadas etapas de Diseño e Implementación con el precepto de
síntesis: “conducir ordenadamente mis pensamientos, empezando por los objetos
más simples y más fáciles de conocer, para ir ascendiendo poco a poco hasta el
conocimiento de los más compuestos”. La etapa llamada Pruebas con el precepto de
revisión: “hacer en todos unos recuentos tan integrales y unas revisiones tan
generales, que llegase a estar seguro de no omitir nada”.
• La premisa software coincide con la premisa cartesiana: todo se puede conocer. El

estándar IEEE Std. 830 recomienda obtener unos requisitos completos, exactos, no
ambiguos,…
• La ingeniería de software temprana obvia las soluciones previas. La construcción de

cualquier sistema software, según los textos tradicionales, comienza siempre a partir
de las condiciones específicas del problema sin atender a soluciones previas, para
que los prejuicios no estorben el libre discernimiento y la búsqueda correcta. En
particular, se comienza siempre desde el llamado diagrama de contexto que es una
expresión de las condiciones específicas. La aplicación adecuada del método
asegura llegar a la solución, sin necesidad de ver qué se ha hecho antes.
• La ingeniería de software no se ha ocupado de la experimentación en sentido

estricto o de cualquier otro camino de investigación inductiva, durante muchos
años.
3. Consecuencias prácticas de la influencia filosófica

La influencia de las ideas cartesianas tuvo como primera y más importante
consecuencia, la credibilidad de la ingeniería de software. Estaba en sintonía con el paradigma
filosófico vigente, aunque nadie mencionara para nada a la filosofía. Así, de modo encubierto, la
filosofía del XVII, traducida al universo software, se convirtió en el cimiento tecnológico de la
novísima industria del software. El marco cartesiano fue el elemento de cohesión que sirvió para
6
tirar del carro. Es difícil imaginar una consecuencia más favorable de la filosofía, en particular
cartesiana, sobre el software. Por esta causa entristece ver la tumba de Descartes abandonada y
sombría en un rincón perdido de la iglesia de Saint Germain d´Pres, en París.
Los problemas llegaron después, cuando por ejemplo:
• el modelo software, como una función de transformación de datos, era insuficiente

para expresar la diversidad de los sistemas software, a pesar de la intención
universal de este modelo;
• había que distorsionar o saltarse el método porque la verdad era inalcanzable, al

menos, en el tiempo del proyecto;
• el método consumía demasiados recursos persiguiendo objetivos difíciles o

quiméricos, como los galgos detrás de una ilusión;
• había que reinventar la rueda en cada proyecto;
• el método se hacía demasiado inerte para ajustarse a los cambios de requisitos;
• convenía tener datos experimentales para tomar decisiones y no se disponía de

ellos.
Y cuando se juntó todo lo malo se abrió el suelo, apareció la perplejidad y la frustración.

¿Por qué no funciona lo que parece tan natural de toda la vida? La respuesta es simple, pero
difícil de aceptar. Todo el edificio metodológico de la ingeniería de software temprana se apoya
en una premisa alejada de la realidad del universo software. Se supuso que la incertidumbre era
erradicable y ahora se considera inevitable. Con esta profunda grieta, la ingeniería de software
temprana ha sufrido de:
• Ineficacia para encontrar soluciones porque ha buscado en un espacio equivocado,

además con herramientas inapropiadas, como la división que no es capaz de reducir
la incertidumbre y sí puede aumentarla.
• Ineficiencia buscando objetivos inalcanzables en el espacio equivocado. El estándar

de requisitos IEEE 830 equivale a decir en el ejército: trate que el enemigo se
coloque en fila india para matarlo de un solo disparo, aunque este ideal no se
consigue siempre.
• Frustración, porque todo el sistema de creencias, la teoría de toda la vida no se

sostiene en el mundo real, sin que otro sistema lo haya sustituido aún.
Y los cuatro siglos de arraigo filosófico han sido los causantes de la:
7
• Confusión de las ideas nuevas con las viejas, porque interpreta lo nuevo con las
gafas de siempre. Se confunde el modelo de objetos con el modelo estructurado; se
confunden las metodologías tradicionales con las recientes, la Cascada con el
Proceso Unificado. Se continúa buscando El Método. Se continúa creyendo en la
eficacia de la división para resolverlo todo, que la modularidad resuelve el
problema del cambio de requisitos.
• Oposición virulenta a los puntos de vista diferentes. Se agredió a la programación

estructurada original, al principio de ocultación y se dejaron de lado a las
estructuras abstractas de datos. Dijkstra y Parnas sufrieron personalmente esas
agresiones. La paz del universo software es tan solo una ilusión. La idea de
reutilizar las soluciones previas, por ejemplo los patrones, no fue atacada
explícitamente pero su aceptación se retrasó hasta mediados de los noventa, aunque
todas las ingenierías trabajan con patrones.
En fin, el fundamento filosófico cartesiano de la temprana ingeniería de software tuvo

una gran virtud: ofreció un marco común, familiar a todos durante cuatro siglos, para aunar
inteligencias y viabilizar el desarrollo de la industria del software. Pero se agotó demasiado
pronto. En unos pocos años mostró signos de ineficacia e ineficiencia y, lejos de reconocer estos
problemas, el paradigma filosófico se convirtió en enemigo feroz de cualquier idea diferente.
Los cuatro siglos de arraigo cartesiano todavía niegan la otra orilla. Pero esto sucede con
frecuencia en la historia. La influencia newtoniana sobre el carácter corpuscular de la luz
impidió aceptar, también durante varios siglos, que la luz tenía un comportamiento ondulatorio.
Al menos ahora hay un artefacto espacial llamado Huygens que recuerda al creador de la teoría
ondulatoria de la luz y que le tocó ser contemporáneo de Newton.
4. Influencia de la incertidumbre
Incertidumbre es una palabra de amplio contenido semántico: problemático,
cuestionable, vago, no definido o determinado, dudoso, no seguro, ambiguo, sujeto a
oportunidad o cambio, no estable, variable, no confiable. Todos estos significados se pueden
agrupar en dos categorías: vaguedad (imprecisión) y ambigüedad.
En general, vaguedad se asocia con la dificultad de hacer distinciones agudas o precisas

en el mundo; esto es, algún dominio de interés es vago si no puede ser delimitado por fronteras
precisas. Ambigüedad se asocia con relaciones de uno a muchos; esto es, con situaciones donde
la elección entre dos o más alternativas se deja sin especificar. La vaguedad está asociada a un
concepto que no está definido del todo, ni ahora ni después. La ambigüedad está asociada al
desconocimiento de cuál es el concepto, de varios conceptos posibles, definidos y precisos.
8
Cada uno de esas dos formas de incertidumbre (vaguedad y ambigüedad) se relaciona

con un conjunto de ideas emparentadas. Por ejemplo, con vaguedad se relaciona borroso,
nubloso, sin claridad, indistinguible, brumoso, confuso, obtuso, impreciso. Con ambigüedad, se
relaciona variedad, no específico, relación uno a muchos, generalidad, diversidad, divergencia.
En ausencia de incertidumbre, la percepción del mundo es simple. La complejidad

(dificultad de comprensión) está dada básicamente por la diversidad; los universos sometidos a
estudio se pueden dividir y recomponer sin que se alteren; en principio, es posible determinar
primero qué se quiere antes de pensar cómo hacerlo; todo es cognoscible y predecible; …
En presencia de incertidumbre la percepción del mundo es mucho más compleja. La

incertidumbre oscurece las relaciones causa y efecto, dificultando la comprensión de los
fenómenos. La complejidad está dada por una ligadura de diversidad e incertidumbre
estrechamente interrelacionadas. La división puede reducir la complejidad por diversidad, no
puede reducir la complejidad por incertidumbre, pero sí puede aumentarla. La reducción de la
complejidad por incertidumbre, puede reducir o aumentar la complejidad por diversidad.
En presencia de incertidumbre los universos sometidos a estudio se alteran si se dividen

y deben ser tratados de manera holística; no es posible determinar primero qué se quiere antes
de pensar cómo hacerlo, la comprensión de qué se quiere llega a través de las soluciones como
sucede en el proceso hermenéutico de comprensión de un texto. No todo es cognoscible, ni
predecible, por mucho esfuerzo que se haga; aparece el concepto de riesgo que, en términos
sencillos, se puede definir como una terna. Riesgo ≡ {suceso, consecuencia desfavorable,
incertidumbre}
Hay riesgo cuando existe incertidumbre sobre la ocurrencia de un suceso cuya

consecuencia es desfavorable. Se podría considerar también la incertidumbre sobre la
consecuencia. En cualquier caso, el valor del riesgo depende del valor de la consecuencia y de
la incertidumbre. El riesgo desaparece si desaparece la consecuencia o la incertidumbre. Un
suceso cierto carece de riesgo.
5. Otra alternativa filosófica

Los intentos de describir un mundo perfectamente cognoscible y predecible se
corresponden con una visión divina del mundo capaz de ejercer un control absoluto de todo. La
descripción de un mundo, considerando incertidumbre inevitable, se corresponde con una
humilde visión humana de ese mundo. Pero no ha sido una humildad espontánea, ha sido
consecuencia de una necesidad. Las descripciones anteriores del mundo eran insuficientes para
explicar los fenómenos.
9
Dicho en tono metafórico. Hasta ahora la llave caída se ha estado buscando en la zona
iluminada de la calle porque era más fácil, pero si la llave se ha caído en la zona oscura, habrá
que buscarla ahí aunque sea más difícil.
Se puede considerar que la incertidumbre es inevitable porque es imposible evitarla o

porque no conviene o no se quiere evitar. En cualquier caso, incertidumbre inevitable significa
incertidumbre presente que carece de sentido tratar de evitar por razones teóricas o prácticas. El
primer caso considera que es imposible evitar la incertidumbre. El segundo caso considera que,
aunque sea evitable, no es práctico evitarla, por alguna causa.
La premisa no es tan nueva. Posiblemente sea recurrente en la historia humana con

diferentes matices, incluyendo la magia y la superchería asociado a lo ignoto. En el siglo XIX,
la ciencia comenzó a estudiar fenómenos donde la incertidumbre se mostraba inevitable. Por
ejemplo, los trabajos de Boltzman en termodinámica, de Darwin en la biología y de Hegel en
filosofía, fueron hitos de ese comienzo, interrumpido por las dos guerras mundiales.
A mediados del XX, volvió la incertidumbre inevitable a la ciencia. Poco a poco se ha

extendido a la meteorología, física, química, biología, psicología, teoría de sistemas, entre otros.
“Lo artificial es determinista y reversible. Lo natural contiene elementos esenciales de azar e
irreversibilidad […] Este cambio es tan profundo que podemos hablar con justicia de un nuevo
dialogo del humano con la naturaleza. […] Podemos decir que buscábamos esquemas globales,
simetrías, leyes generales inmutables y hemos descubierto lo mutable, lo temporal, lo
complejo.” “Cualquier sistema inicialmente simple tenderá a hacerse más complejo. No hay
otro sitio a donde ir.” “La aceptación de la complejidad es la aceptación de una contradicción, es
la idea que no podemos escamotear las contradicciones con una visión eufórica del mundo [...]
Podemos decir que aquello que es complejo recupera al mundo empírico, a la incertidumbre, la
incapacidad de formular una ley, de concebir un orden absoluto”.
La ingeniería de software aceptó la incertidumbre inevitable a finales del XX, a pesar de

que la incertidumbre es una de las cualidades fundamentales del software. Gracias a su
capacidad de ambigüedad, el software tiene capacidad para realizar una tarea en infinidad de
situaciones distintas, en infinidad de alternativas. Un software de contabilidad puede realizar el
cálculo contable de cualquier mes de cualquier año; no sería tan útil si sólo es capaz de realizar
la contabilidad de noviembre de este año. La ambigüedad del software deriva, básicamente, de
las variables y de las instrucciones que expresan alternativas, aunque también posee otras
cualidades que aumentan su capacidad de ambigüedad.
El software no ha inventado nada nuevo. Desde hace mucho tiempo, los humanos
admiten o introducen incertidumbre en la solución cuando se enfrentan a un problema donde no
10
pueden erradicar la incertidumbre. El oráculo de Delfos respondía con textos ambiguos a las
preguntas que se le formulaban. Los adivinos actuales repiten las mismas fórmulas de antaño.
En algunos transportes públicos se puede leer “la multa será de veinte veces el precio del
billete”, que simplifica el problema de renovar el cartel para que no se devalúe la multa. El
juego de ordenar ocho números colocados en nueve casillas no sería posible sin el margen de la
novena casilla vacía que permite el movimiento. El cálculo numérico de raíces irracionales se
realiza gracias a procesos cíclicos que toleran imprecisión en la soluciones. Pero en general,
estas soluciones, no son gratis; aumentan la complejidad de la solución. Retomando el ejemplo
del transporte público, hay que estar dispuesto a pagar ahora un cartel más caro y más difícil de
entender, para mañana ahorrarse la renovación del cartel.
La incertidumbre en la solución, como solución, siempre ha estado ahí, pero tapada por
el paradigma filosófico vigente. La tapaba o la agredía porque contradice sus propósitos:
alcanzar el conocimiento absoluto, el control detallado de todo. La incertidumbre se ha
considerado accidente y no esencia. Se podía arrinconar y eliminar, más tarde o temprano.
¡Cómo entonces, se puede renunciar a conocerlo todo y peor aún, cómo se puede
introducir voluntariamente incertidumbre en la solución! Nada, un disparate. Con esta idea
Brooks explicaba porqué había calificado de receta para el desastre al principio de ocultación de
información. “Los programadores deben conocer la semántica detallada de las interfaces, con
las que trabajan, mediante el conocimiento de qué hay en el otro lado. El ocultamiento de esa
semántica conduce a equivocaciones en el sistema” Quizás la misma idea pueda explicar porqué
IBM, en particular Harlan Mills, distorsionó y se robó el término de programación estructurada
desarrollado por Dijkstra (Brooks reconoció que las ideas de Harlan Mills estaban detrás de sus
argumentos en contra del principio de ocultación). Y, quizás también, esta obsesión por la
claridad absoluta explique porqué las estructuras abstractas de datos no llegaron a florecer.
Las estructuras abstractas de datos, el principio de ocultación de información y la

programación estructurada original comparten la misma idea: introducir incertidumbre en el
diseño software como solución a la incertidumbre inevitable, aunque posiblemente sus autores
pasaran por alto este hecho clave. Ellos, y muchos otros, se creían dentro de las fronteras del
paradigma vigente, pero realmente eran disidentes sin saberlo y por causa de la disidencia,
consciente o no, los humanos son capaces de llegar hasta la crucifixión.
6. Respuestas
Los problemas mencionados en la introducción se derivan de ese estar y no estar o no
saber dónde se está, que se ha producido como consecuencia del apego a un paradigma
inoperante. La base de la solución a todos esos conflictos es el cambio de la premisa filosófica,
11
de modelo del mundo. Es una situación análoga al cambio de modelo del átomo cuando se creía
que era compacto y resultó que un haz de electrones atravesó un pan de oro, de lado a lado, sin
apenas desvío. Para explicar este fenómeno había que cambiar de modelo y aceptar que el
átomo debía estar prácticamente vacío, aunque al apoyarse en una tabla no se tenga la sensación
de vacío.
El cambio de perspectiva filosófica se ha podido explicar el problema clave ¿Por qué no

funciona lo que parece tan natural de toda la vida? Y también, ha permitido hilvanar y explicar
los conflictos de las estructuras abstractas de datos, del principio de ocultación de información y
de la programación estructurada original, que parecían ser conflictos inconexos y no tenían
explicación. Parnas, el autor del principio de ocultación, se preguntaba el porqué de las
tribulaciones del principio de ocultación e intuía que detrás de la respuesta podía estar algo
importante. Efectivamente, había un cambio radical de paradigma. Parnas casi lo descubre, pero
no lo alcanzó. Blum percibió la necesidad de un cambio de paradigma, propuso un enfoque
holístico de la ingeniería de software, opuesto al cartesiano, y lo aplicó en la práctica durante
varios años. Su libro “Beyond Programming” es un notable estudio filosófico del software,
quizás el más extenso, pero le faltó descubrir la pieza clave del nuevo paradigma: la
incertidumbre inevitable.
Desde el punto de vista de la complejidad, el espacio de existencia de la ingeniería de

software temprana contaba sólo con la dimensión de la complejidad descriptiva. La
incertidumbre enriquece el espacio de la ingeniería de software con otra dimensión, la
complejidad de incertidumbre. El nuevo espacio muestra propiedades distintas y permite
resolver problemas irresolubles en el espacio tradicional. La situación es semejante al
enriquecimiento del espacio geométrico. El sentido de orden absoluto se pierde al pasar de una a
dos dimensiones, pero el problema de hacer coincidir un guante derecho con un guante
izquierdo se resuelve al pasar de dos a tres dimensiones.
El nuevo paradigma resuelve muchos problemas y permite predecir propiedades de las

técnicas de diseño, de los modelos software, de las metodologías, de los sistemas software, de
las relaciones entre todos ellos. El nuevo paradigma, que acepta la incertidumbre inevitable,
declina la idea de diseños que se anticipen a los cambios, puesto que no es posible anticiparse, y
realza la idea de diseños con facilidad de acomodación progresiva a los cambios.
6.1 El diseño
La división del todo en partes es un antiguo recurso de los humanos para reducir las
dimensiones del problema que se debe enfrentar a la vez, con el objetivo de facilitar su
resolución. El “Arte de la guerra”, del siglo IV a.C., lo expresa del siguiente modo: “Gobernar
12
sobre muchas personas como si fueran pocas es una cuestión de dividirlas en grupos o sectores;
es organización”. El método cartesiano, del siglo XVII, recomienda: “Dividir cada una de las
dificultades que examinare en cuantas partes fuere posible y en cuantas requiriese su mejor
solución.” Y un texto de software dice: “El sistema software debe ser dividido en un número de
módulos con interfaces bien definidas; cada módulo debe ser suficientemente pequeño y simple
para ser comprendido y programado.” Tantos años de persistencia han convertido la división en
un dogma de fe, pero no siempre funciona.
La disidencia involuntaria de Parnas comenzó cuando escribe que la referida forma de

dividir en módulos no facilita la modificación, ni la construcción en paralelo de los módulos,
por la excesiva dependencia entre ellos. Pero mantiene su fe en la división como recurso
omnipotente y propone otra forma de división en módulos que denomina: principio de
ocultación de información, El trabajo “On the Criteria To Be Used in Decomposing System into
Modules” acierta en lo más importante, el principio funciona, disminuye la dependencia, pero
va más allá de un simple criterio de división. El principio de ocultación de información es una
forma de introducir ambigüedad en el diseño software para reducir la dependencia entre las
partes del diseño.
Dos o más elementos son independientes entre ellos sí y sólo sí carecen de relaciones
entre ellos. El principio de ocultación procura eliminar las relaciones entre los elementos de los
sistemas software o, si no puede, las debilita sustituyendo las relaciones unívocas (uno a uno)
por relaciones ambiguas (uno a muchos). Por ejemplo, la relación unívoca “dame el saldo” que
establece la parte del sistema encargada de la extracción, con la parte que tiene acceso al saldo,
se sustituye por la relación ambigua “autoriza la extracción de esta (cantidad)”. Así, la parte
encargada de la extracción se hace indiferente del mecanismo de autorización. Una distorsión
frecuente del principio de ocultación es “privatizar” las variables y después, acceder a ellas a
través de los llamados “get” y “set”; es una forma encubierta de diseñar estructurado con ropaje
de objetos.
Parnas tenía razón, los módulos tradicionales no facilitan las modificaciones del
software, ni la reducción del tiempo de desarrollo, pero tampoco lo puede hacer ninguna forma
de división. La definición de modularidad del estándar IEEE hace trampa cuando dice que se
trata de una propiedad del software que facilita los cambios. El estándar se equivoca y, propaga
la equivocación a todos los que le lean y le crean. La equivocación consiste en pensar que la
independencia (la cualidad que facilita las modificaciones y la reducción del tiempo de
desarrollo) es una consecuencia directa de la separación, pero muchas parejas de personas
separadas dirán que no es así.
13
La división del todo en partes tiene dos problemas en el universo software. Primero, es
incapaz de producir independencia porque no destruye, ni debilita las relaciones entre los
elementos. Por tanto, es incapaz de facilitar la modificación, ni la construcción en paralelo de
los elementos del sistema software, para conseguir estos dos resultados es necesario introducir
incertidumbre en el diseño. Segundo, la división del todo en partes genera incertidumbre cuando
se divide un universo no aditivo, porque al reunir las partes, no se obtiene el todo inicial.
Muchas de las pruebas de integración fallan por esta causa.
6.2 Reproducir la realidad en el diseño

Desde toda la vida se insiste en la conveniencia de diseñar el software copiando la
realidad del problema que resuelve. Se dice que reproducir, en el diseño, los elementos y
funciones del dominio del problema facilita la comprensión y el desarrollo del software.
Posiblemente, sea cierto y útil si no hay que tocar nunca más el sistema. Pero, copiar la realidad
(dominio) en el diseño software genera un severo problema cuando la incertidumbre inevitable
obliga a realizar cambios en el sistema, porque la copia dificulta notablemente los cambios.
Puesto que el dominio y el software, generalmente, difieren de naturaleza, se copian

sólo aspectos fenomenológicos externos, nada de esencia. Cuando los fenómenos del dominio
cambian, los elementos del dominio se acomodan fácilmente a los cambios porque su naturaleza
lo permite, pero los elementos del software no tienen la misma naturaleza y se atasca el cambio.
Ésta es la idea de Haythorn cuando califica de ingenua la técnica de diseño software de copiar la
realidad. Yourdon también se opone a copiar la realidad, pero por otras causas que se suman al
problema de la dificultad de cambios.
Para facilitar los cambios en el software hay que introducir ambigüedad en el diseño y,
generalmente, esto distorsiona los elementos software y sus relaciones, respecto al dominio. Por
ejemplo, el elemento Cuenta, en el dominio del banco, sólo es una ficha, incapaz por sí sola de
hacer algo. Sin embargo, un elemento software “Cuenta”, diseñado para facilitar los cambios, es
capaz de autorizar el mismo la extracción de dinero, porque contiene el saldo y el algoritmo de
autorización. Es un reflejo anamórfico, que tiene el nombre “Cuenta”, únicamente, para no
perder la referencia con el dominio.
La copia de la realidad, en el diseño software, posiblemente facilite la comprensión del

diseño, pero dificulta en general, su modificación. En un mundo de incertidumbre inevitable
esto es un problema importante.
14
6.3 Objetos vs. estructurado

Uno de los problemas más controvertido del universo software es el tema de objetos vs.
estructurado e, incluso, qué es objetos y qué es estructurado. La resolución detallada de estos
temas supera el marco del presente documento, pero se puede indicar cómo utilizar la
incertidumbre, de instrumento metodológico, para aclarar algunos aspectos. Figura 1.
a x
b
f(x)
y
c funciones y datos
n
a
m
s c p x
h i
b y
MODELOS
dividir
modelos
cosas
admitir ambigüedad interrelacionadas
COMPLEJIDAD
Figura 1. Modelos software
El modelo estructurado, en términos de una función de transformación de datos, fue

concebido con la intención de la exactitud matemática. Mientras que el origen del modelo de
objetos fue la simulación. El primero excluye la incertidumbre y el segundo la incluye, como
recurso para abordar la diversidad de la simulación. Ésta es la diferencia clave entre
estructurado y objetos. Se aprecia en los siguientes aspectos.
Primero, en las definiciones. El elemento fundamental del estructurado es la función de

transformación de datos; el elemento fundamental de los objetos es el objeto, que significa cosa.
Cualquier sistema software estructurado es una función de transformación de datos, mientras
que un sistema software de objetos es un conjunto de elementos software que colaboran entre sí
para producir un resultado. La sensación, débilmente justificada, de la facilidad de los objetos
15
para copiar o representar la realidad, deriva de la ambigüedad de esas definiciones. Los objetos
no se parecen más a la realidad que el estructurado, ni siquiera conviene que se parezcan a la
realidad porque se tornan engorrosos de modificar, pero los objetos ofrecen más libertad de
imaginación gracias a su ambigüedad. De esta libertad se aprovechan los que se aferran a la idea
estructurada para continuar diseñando software de forma estructurada, pero con ropaje de
objetos.
Segundo, en la capacidad de abstracción, que es un recurso de ambigüedad en la

solución. El estructurado separa datos y funciones, de manera que su capacidad de abstracción
se manifiesta por separado. La abstracción sobre los datos se aprecia en las variables
individuales, en los vectores y otros tipos de conjuntos estáticos de datos, en los conjuntos
dinámicos de datos. La abstracción sobre el código se observa en las rutinas, asociadas con la
reutilización de código, pero que son recursos de simplificación a través de la abstracción,
aunque una rutina se ejecute una sola vez. Los tipos abstractos de datos elevan la capacidad de
abstracción porque ocultan los datos y las funciones que actúan sobre esos datos. Los objetos
superan, aún más este nivel de abstracción porque permiten la aparición del concepto de cosa,
mucho más ambiguo que dato, función y que dato abstracto. En los lenguajes de objetos donde
existen, las clases son abstracciones de objetos y las clases abstractas son abstracciones de
clases.
En fin, el modelo estructurado es simple, se expresa en términos de funciones que

procesan datos, separa datos y funciones, e intenta minimizar la incertidumbre. Por tanto, es
adecuado cuando se quieran aprovechar estas cualidades, por ejemplo en el procesamiento de
datos, siempre que la incertidumbre inevitable del contexto sea pequeña y exija pocos cambios.
En la medida que un diseño estructurado se quiera proteger contra los cambios se aproximará a
un diseño de objetos.
El modelo de objetos es mucho más complejo por su mayor riqueza de conceptos y por
su mayor capacidad de incertidumbre. Esta complejidad afecta a la máquina y a los
desarrolladores. Pero también, esta complejidad facilita la libertad de imaginación durante el
diseño y el enfrentamiento con la incertidumbre inevitable. De los recursos disponibles, los
objetos ofrecen las mejores condiciones para facilitar los cambios, pero no vale recubrir con
ropaje de objetos a los diseños estructurados. Figura 2.
16
a x
b CONVERGENCIA DE MODELOS
y
c
a n
m
s c p x a n
h m
b i s c p x
y
h
b i
y
funciones y datos
n m
s
h p
modelos
i
cosas
interrelacionadas
Figura 2. Convergencia de objetos y estructurado
6.4 Las metodologías

Las metodologías de desarrollo de software dicen ser vías universales del éxito y
exponentes de la mejor práctica. Las metodologías tienden a sublimarse a sí mismas, como lo
hacían en el siglo XVII. Detrás de esta conducta hay razones filosóficas, de vanidad y
económicas. La adopción de una metodología puede suponer dinero para sus autores por
diversos conceptos. Cada metodología aspira a representar La Verdad y ser La Elegida; no todo
es ingenuidad.
En la ingeniería de software abunda la literatura que se apoya en la experiencia personal

para decir que algo es bueno. La frase estándar tiene más o menos la siguiente forma: “Nuestra
(mi) experiencia dice que esto que decimos (digo) es la mejor práctica”. Así, sin otro argumento,
las metodologías se autojustifican; como hizo Descartes en su Discurso del método, allá por el
siglo XVII; como se lee en el Génesis: “… hizo esto y vio que era bueno y lo dejó.” Y, quizás de
mirar desde tan alto, desde la sublimación del método, las metodologías padecen de soberbia;
una soberbia insultante (mi método os salvará). Algunos sienten vergüenza o se justifican.
Refiriéndose al grupo que propuso el enfoque Ágil un miembro ha dicho: Nosotros (las
17
personas del grupo) somos desarrolladores de software practicantes, no simples espectadores

haciendo reglas para otros. Pero, aunque sean desarrolladores de verdad, la experiencia de unos
ha discurrido por caminos distintos de otros y los resultados son diferentes, aunque todos se
proclaman universales.
Con esos discursos y sin otros argumentos, la elección de una metodología sólo se
puede hacer por afinidad o simpatía; es fácil confundir las metodologías, mezclarlas o hacer
cualquier otra cosa. Para distinguir una metodología de otra hay que distinguir la esencia de
cada una, oculta detrás del empirismo y enredada en la madeja de sus respectivas peroratas
apologéticas. El bisturí teórico de la incertidumbre puede cortar esas madejas y mostrar la
esencia de cada metodología: su estrategia de resolución de problemas.
6.4.1 Problemas
Los problemas (dificultades) primarios del desarrollo de software están alrededor del
conocimiento y la estabilidad del problema del cliente y de la solución. Hace veinticinco años,
Lehman clasificó los sistemas software según estas dificultades. La Tabla 1 muestra la
clasificación de Lehman.
Problema Solución Tipo
Bien conocido y estable Bien conocida y estable S
Bien conocido y estable No bien conocida e inestable P
No bien conocido e inestable No bien conocida e inestable E
Tabla 1. Clasificación de los sistemas software

Un ejemplo de sistema software de tipo S es un sistema para la inversión de una matriz.
Un ejemplo de sistema tipo P es un sistema para jugar al ajedrez. Un sistema de tipo E es un
sistema para el mundo real.
Desde el punto de vista de la incertidumbre, la clasificación de Lehman se puede

representar como se muestra en la Figura 3.
Las estrategias de resolución de problemas, en el software, deberían tener en cuenta las

dificultades a que se enfrentan, qué tipo de sistema están construyendo. Lamentablemente esta
clasificación ha pasado inadvertida, salvo algunas pocas citas, por ejemplo la de Pfleeger.
18
SISTEMAS SOFTWARE
(CLASIFICACIÓN DE LEHMAN)
S P E
Se conoce el problema, Se conoce el problema, NO se conoce el problema,
se conoce la solución NO se conoce la solución NO se conoce la solución
INCERTIDUMBRE
Figura 3. Incertidumbre acerca de los sistemas software
6.4.2 Estrategias
Los humanos utilizan fundamentalmente tres tipos de estrategias de resolución de

problemas según la magnitud de la incertidumbre presente. La estrategia lineal, cuando la
incertidumbre es nula o despreciable; la estrategia cíclica, cuando la incertidumbre es media (se
conoce algo) y la estrategia exploratoria, cuando la incertidumbre es alta. La capacidad de cada
una de estas estrategias para enfrentar la incertidumbre está relacionada con la incertidumbre
que admite en la formulación y resolución del problema.
La estrategia lineal supone que la incertidumbre se ha erradicado antes de comenzar la

resolución; no admite incertidumbre. La estrategia cíclica propone una aproximación inicial y la
refina sucesivamente; admite alguna incertidumbre en la formulación y solución del problema.
Si el proceso converge, la estrategia cíclica se acerca progresivamente a la solución, suponiendo
una solución estable. La estrategia exploratoria ensaya y prueba hasta encontrar la solución o
agotar los recursos; admite mucha incertidumbre. Si el universo es abierto, la estrategia
exploratoria no asegura encontrar la solución, pero es el único camino racional posible en
presencia de elevada incertidumbre.
19
A continuación se estudian estas tres estrategias de resolución de problemas y sus

respectivos reflejos en el software.
• Estrategia lineal
Cuando la incertidumbre es erradicable y se consigue que sea nula o despreciable, la

recomendación de siempre (cartesiana) es utilizar el método lineal (secuencial) de resolución.
Primero, especificar qué se quiere resolver (sin incertidumbre). Segundo, analizar el problema.
Tercero, determinar cómo llegar a la solución y llegar a ella (todo esto también sin
incertidumbre). Finalmente, se revisa cada elemento de la solución y su integración para
corregir las posibles equivocaciones.
Se revisa para enmendar lo mal hecho (equivocaciones), no para reducir el error

(aproximación) porque se ha supuesto que la incertidumbre se ha erradicado al principio, en la
fase donde se especificó qué se quiere. Por tanto, carece de sentido el concepto de error. La
solución es exacta, siempre que se eliminen las equivocaciones1. Trasladado al ámbito de la
matemática, el método lineal ignora los números irracionales.
Cuatro siglos de costumbre han inducido a creer que ese método es El Método Ideal, el
método lógico, el único; cualquier desviación del Método refleja mediocridad.
En el software, el paradigma del método lineal toma el nombre de desarrollo en

Cascada, aunque está presente con diferentes nombres y variantes. La llamada etapa de Análisis
Estructurado sólo puede comenzar cuando se haya erradicado toda la incertidumbre. La última
etapa llamada Pruebas, se destina a corregir las posibles equivocaciones durante la aplicación
del método para que el resultado coincida exactamente con lo previsto inicialmente.
Cuando la incertidumbre es apreciable e inevitable las condiciones se tornan

desfavorables para la estrategia lineal. No es posible conocer el qué antes del cómo; la división
altera el universo sometido a estudio; se disuelven las presunciones. Con la incertidumbre
además, aparece el riesgo y entonces cada proyecto adquiere el carácter de apuesta.
Sobre la promesa de éxito seguro, si se siguen estrictamente los pasos de la estrategia

lineal (y se cumple su premisa), aparece la sombra de la suerte; un elemento totalmente fuera de
control donde no influye ni el cuidado, ni los recursos, ni el método. En presencia de
incertidumbre apreciable e inevitable, la estrategia lineal equivale a disparar con un fusil
oxidado a un blanco borroso que se mueve de manera impredecible; una apuesta de alto riesgo.
1
Equivocación tiene el significado de algo mal hecho, mientras que error en ciencia o
tecnología, significa aproximación.
20
Para tratar de eludir los inconvenientes de la incertidumbre inevitable (llamada

veleidad, incapacidad, falta de tiempo, etc.), algunos desarrolladores de software acostumbran a
“congelar” los requisitos con la firma de los clientes. Yourdon alertó hace tiempo sobre los
resultados de esta congelación: el producto satisface las condiciones firmadas, pero no al cliente
(como consecuencia de la presencia de incertidumbre inevitable). Hoy la congelación de
requisitos se reconoce como una práctica poco adecuada, a la vez que se reconoce la presencia
de incertidumbre inevitable en el software. No obstante, la práctica de “congelar” continúa y no
pasa nada, mientras los proveedores de software sean los dueños de la situación en el
distorsionado mercado de software.
• Estrategia cíclica
La incertidumbre inevitable en el software es análoga, en matemática, a la existencia de

números irracionales en el problema o en la solución, con el agravante de ser números
escurridizos; hoy quizás se trata de √3 y después, quizás de √2. Es un problema que no se
asegura su resolución admitiendo márgenes de tolerancia (incertidumbre) en cada una de las
etapas. Los márgenes en las etapas sólo sirven para manejar la incertidumbre en la realización
de las etapas, pero no para manejar las incertidumbres esenciales del problema: las
incertidumbres sobre qué se quiere y el cómo se llega.
El cálculo de los irracionales renuncia a conocer con exactitud la respuesta, supone que
se conoce una solución aproximada (la incertidumbre esencial no es demasiado alta) y aplica
métodos cíclicos de aproximaciones sucesivas. En cada situación particular, la práctica será
quien decida los hitos, cada solución satisfactoria. Desde el punto de vista teórico no existe
solución exacta y por tanto, tampoco existe solución definitiva. Los métodos cíclicos también se
pueden alejar de la solución, aún en ausencia de equivocaciones. Cualquier refinamiento
expresa una estrategia cíclica.
En el software, el paradigma del método cíclico toma el nombre de desarrollo en

Espiral, y se define como un método de desarrollo guiado por el riesgo. La Espiral reconoce
explícitamente la incertidumbre inevitable cuando su autor expresa que es una forma de
desarrollo de software para cuando el cliente dice: “sabré lo que quiero cuando lo vea”. La
definición de guiado por el riesgo es consecuente con esta premisa.
Desde el punto de vista de riesgo, los métodos cíclicos representan una estrategia más
prudente que los métodos lineales, porque arriesgan mucho menos de cada vez. Los métodos
cíclicos abordan al comienzo, el mayor riesgo.
21
Además de la Espiral existen diversas referencias a métodos cíclicos. En general, todos

ellos han sido relegados, durante mucho tiempo, como les ha sucedido históricamente a las
soluciones que contienen incertidumbre. El giro progresivo hacia la premisa de incertidumbre
inevitable ha puesto de relieve a los métodos cíclicos asociados con el modelo de objetos.
• Estrategia exploratoria
Cuando la incertidumbre es demasiado alta e inevitable, por ejemplo porque se carece

de una idea de la solución, entonces no queda otro remedio que el ensayo y error; es decir,
explorar. Se propone un camino de solución y se prueba. Si el camino se cierra, se vuelve atrás y
se propone otro camino. Si el camino se disgrega en varios caminos, se aleje uno de ellos y se
prueba. Así hasta encontrar la solución o agotar los recursos. La exploración no asegura
encontrar la solución, ni siquiera aproximarse a ella; se le puede pasar por el lado a la solución
sin percibir su existencia. Pero, si la incertidumbre es alta, no hay otra vía. El aspecto
geométrico de la estrategia exploratoria es un árbol.
En el software y en cualquier otra actividad creativa, la exploración se utiliza infinidad

de veces (cada vez que se abandona una solución y se emprende otra), pero se toma como algo
accidental y no esencial, salvo en Inteligencia Artificial, donde el algoritmo A* expresa una
estrategia exploratoria.
En la ingeniería de software, la única referencia a la estrategia de ensayo y error como

esencia se denomina ciclo de vida Caos, que trata de describir el desarrollo de software en
condiciones de máxima impredecibilidad. No obstante, el arraigo cartesiano del autor, lastra su
resultado porque describe el ciclo Caos como una ¡cascada caótica de cascadas! El autor utiliza
un modelo de pensamiento, cuya premisa es incertidumbre nula, en condiciones de
incertidumbre máxima. Sin embargo, a pesar de esta aquiescencia cartesiana, el ciclo de vida
Caos tampoco logra ser aceptado y se le menciona como: “un documento intrigante sobre la
naturaleza del proceso de software [donde el autor de Caos] utiliza fractales como base de
estudio de la verdadera naturaleza del proceso de software.”
En resumen, estas tres estrategias de resolución de problemas se pueden ordenar en el

eje de incertidumbre según su premisa. Figura 4. La estrategia lineal supone incertidumbre nula
o despreciable e intenta llegar a una solución exacta, completa, no ambigua. La estrategia cíclica
supone incertidumbre media e inevitable, e intenta aproximarse de modo progresivo a una
solución que nunca conocerá. La estrategia exploratoria supone incertidumbre elevada e
inevitable, e intenta encontrar una solución mediante un proceso de búsqueda. La búsqueda
puede pasar por el lado de una solución sin percibir su existencia; si el espacio de búsqueda es
abierto, la estrategia exploratoria no asegura encontrar la solución.
22
MÉTODOS DE DESARROLLO
Método lineal
Se conoce el fin
Pruebas
Implementación (Cascada)
Diseño
Análisis
Requisitos
dividir
métodos
Método iterativo Método exploratorio
NO se conoce el fin, pero NO se conoce el fin,
se conoce su proximidad NI se conoce su
admitir incertidumbre
proximidad
(Espiral)
(Caos)
COMPLEJIDAD
Figura 4. Métodos de resolución de problemas
6.4.3 Problemas, estrategias y modelos de solución
Los problemas, las estrategias y los modelos de solución se pueden relacionar en el eje
de incertidumbre. Los sistemas tipo S se deben enfrentar con una estrategia lineal porque es la
estrategia que se ajusta a la premisa de incertidumbre nula o despreciable. Los sistemas de tipo
P se deben enfrentar con una estrategia cíclica, que es adecuada para incertidumbre media.
Mientras que los sistemas de tipo E se deben enfrentar, de ser posible, con una estrategia cíclica
o con una estrategia exploratoria, en el peor caso. Una estrategia lineal para enfrentar un sistema
tipo P o E resulta poco prudente porque, en presencia de incertidumbre, arriesga todo a un solo
disparo con un arma deficiente.
Si las estrategias se asocian con formas de movimiento (lineal, cíclico y arbóreo) se

puede ver que la estrategia lineal puede manejar modelos de gran inercia (resistencia al cambio)
porque la dirección es constante; la estrategia cíclica requiere de modelos menos inertes para ser
eficiente y la estrategia exploratoria necesita modelos apenas inertes para reducir el consumo de
recursos.
23
6.4.4 Metodologías
Las metodologías de desarrollo de software son visiones particulares de estrategias de

resolución de problemas y de modelos software aplicados a la construcción de sistemas software
dirigidos a resolver problemas del mundo real. Las metodologías también consideran aspectos
sociales y de organización del desarrollo de software.
A continuación se estudian, de forma breve, tres metodologías actuales, difíciles de

comparar porque tienen orígenes distintos y, aparentemente, carecen de relación entre ellas:
Métrica 3, Proceso Unificado y enfoque Ágil. La descripción de las metodologías se ha tomado
de la literatura referida, aunque distintos autores ofrecen descripciones de matices distintos. El
objetivo central de este estudio es demostrar el valor de la incertidumbre primero, como
elemento de comparación, y segundo, como instrumento de análisis y predicción de las
características de las metodologías de desarrollo de software.
• Métrica Versión 3
Los objetivos declarados de Métrica 3 son:
• Definir un marco estratégico para el éxito.
• Satisfacer las necesidades de los usuarios enfatizando el análisis de requisitos.
• Mejorar la productividad permitiendo una mayor capacidad de adaptación y

reutilización.
• Facilitar la comunicación y el entendimiento.
• Facilitar la operación, mantenimiento y uso de los productos obtenidos.
Métrica 3:
Es un enfoque orientado a procesos, enmarcado en la norma ISO 12.207, y se centra en

la clasificación y definición de los procesos del ciclo de vida del software. Los procesos
principales se han enriquecido especificando relaciones y participantes de forma más precisa a
nivel de tarea. En las relaciones no se ha llegado a una definición exhaustiva que haría perder en
adaptabilidad. El orden asignado a las actividades no debe interpretarse como secuencia en su
realización que puede ser diferente o en paralelo. Sin embargo, un proceso sólo finaliza cuando
finalizan todas las actividades del proceso que se haya determinado llevar a cabo.
24
Abarca el desarrollo completo de Sistemas de Información sea cual sea su complejidad

y magnitud, y puede adaptarse y dimensionarse en cada momento de acuerdo a las
características de cada proyecto. Cubre tanto desarrollos estructurados como orientados a
objetos, definiendo así una metodología mixta. Métrica Versión 3 proporciona sistemas con
calidad y seguridad.
Es una nueva versión de Métrica que conserva la adaptabilidad, flexibilidad y sencillez

de la versión 2.1, robustece sus puntos fuertes y solventa los débiles a través de la experiencia
de los actuales usuarios. Ha sido enriquecido con el análisis de los últimos estándares de
calidad, ingeniería de software y referencias específicas.
Resumiendo, Métrica 3 dice ser una estrategia universal enfocada hacia el proceso
(método) de desarrollo que contempla software estructurado y orientado a objetos. Enfatiza el
análisis de requisitos y pretende facilitar la adaptación, reutilización, comunicación,
entendimiento, además de facilitar la operación, mantenimiento y uso del producto software.
Métrica 3, según dice ella misma, es el resultado práctico de los últimos avances. Un análisis de
Métrica 3 ofrece el siguiente resultado.
Primero, Métrica pone toda su atención en el método y enfatiza los requisitos. Esto es
patognomónico de las metodologías que suscriben la premisa de incertidumbre erradicable.
Consideran que la verdad es alcanzable siempre y que el método es la vía para alcanzarla,
cualquiera que sea la verdad e independiente de la persona que aplique el método.
Métrica, sin embargo, no impone explícitamente la secuencia lineal (qué-cómo-revisar)

característica del método cartesiano. Deja libertad para el orden de realización de diversas
actividades, pero mantiene la condición de terminación exhaustiva. Esa libertad refleja la
intención de los estándares de proceso software que definen los procesos que se deben realizar,
sin inmiscuirse en el orden de realización, para distinguirse así de los ciclos de vida. No
obstante, el espíritu de la secuencia está presente.
Segundo, el énfasis en los requisitos pretende satisfacer correctamente las necesidades

de los usuarios a través de la exactitud, no ambigüedad y completitud de los requisitos
(incertidumbre nula) y pretende además, anticiparse al futuro para prever los cambios y otros
posibles usos del producto (incertidumbre nula mañana). Métrica pretende, a través de la
especificación de requisitos, satisfacer el presente y predecir el futuro. Aunque no lo dice de
forma explícita, su camino hacia la adaptación y reutilización se inclina más por la anticipación
que por la acomodación a lo desconocido.
Tercero, la facilidad de comunicación y entendimiento con los usuarios o clientes

pretende erradicar la incertidumbre antes del diseño y construcción del sistema. La facilidad de
25
comunicación y entendimiento dentro del equipo de desarrollo pretende reducir las

equivocaciones durante la construcción del software. En ningún caso se trata de comunicación y
entendimiento, entre todos, para encontrar progresivamente la solución.
Cuarto, la facilidad de operación, mantenimiento y uso se supone directamente de una

buena documentación (detallada).
Quinto, el nivel de detalle y precisión que ofrece Métrica, de cada tarea, de los
productos, procesos, participantes, etc., (y el orgullo de dar esos detalles y precisiones) es otro
índice claro de las pretensiones de exactitud y control propias de la premisa de incertidumbre
erradicable. El detalle y la precisión carecen de sentido en condiciones de incertidumbre
inevitable.
Estas cinco características de Métrica la sitúan dentro de los enfoques (estrategias) de

desarrollo de software que suponen una incertidumbre erradicable o casi. Confían el éxito al
método (proceso) y a la obtención de requisitos completos, exactos, no ambiguos como clave
del método para satisfacer las necesidades de los clientes y facilitar la evolución futura del
sistema software. Métrica 3 aspira a ser anticipativa (proactiva en el sentido de Presman) a
escala del sistema software. Es decir, aspira a conocer todo o casi todo antes de comenzar el
desarrollo del sistema.
La libertad en el orden de realización de actividades, que tolera Métrica, es una

concesión a la premisa de incertidumbre inevitable. Algo así como: erradique. la incertidumbre,
pero si no puede entonces tómese algunas libertades para resolver el problema. No obstante,
cumpla estrictamente los procesos. Esta libertad beneficiosa es, también, un elemento de
confusión porque contradice el orden estricto que establece su raíz filosófica. Pero casi todas las
metodologías tienen algo de ecléctico y sufren de contradicciones entre la superficie que
muestran y las premisas que las sostienen.
• Proceso Unificado
Con los objetos aparecieron muchas metodologías específicas para desarrollar software
utilizando objetos. En 1996 había alrededor de ochenta metodologías. Hoy se oye mucho el
Proceso Unificado, autoproclamado meta-metodología; algo así como una metodología de
metodologías, capaz de ajustarse a cualquier situación.
El Proceso Unificado se proclama dirigido por casos de uso, centrado en la arquitectura,

iterativo e incremental. Se justifica, como casi todas las metodologías: es el resultado de más de
treinta años de experiencia; pero, debe ser una experiencia distinta de Métrica y del enfoque
Ágil porque difieren sustancialmente.
26
Mientras que el enfoque Ágil promueve la programación directa, el Proceso Unificado

rechaza el desarrollo de software dirigido por código. “Muchas organizaciones de software
tienden a lanzarse a escribir código porque son las líneas de código lo que los jefes tienen en
cuenta. […] El énfasis de la organización debe pasar de contar líneas de código a reducir los
riesgos y a crear la línea base de funcionalidad para la arquitectura. […] De otro modo, los
desarrolladores pronto volverán a aquello a lo que estaban acostumbrados, las líneas de código.”
Según el libro del Proceso Unificado, dirigido por casos de uso quiere decir que el
proceso de desarrollo sigue el hilo de los requisitos funcionales (expresados en los casos de
uso). Conjuntamente con los casos de uso se desarrolla la arquitectura del sistema, en un sentido
similar al papel que desempeña la arquitectura en la construcción de edificios.
Los casos de uso guían la arquitectura y la arquitectura del sistema influye en la

selección de los casos de uso. Es un problema de equilibrado de la forma y la función, similar al
de huevo y la gallina. El huevo y la gallina se consiguen a lo largo de iteraciones casi sin fin en
el proceso evolutivo. De manera parecida, durante el proceso de desarrollo de software, se
consigue el equilibrio (entre casos de uso y arquitectura) a lo largo de una serie de iteraciones.
Por tanto, el desarrollo iterativo e incremental constituye el tercer aspecto clave del Proceso
Unificado.
La idea del huevo y la gallina, que utiliza el Proceso Unificado, expresa que sus autores
reconocen el carácter hermenéutico del proceso de diseño, la interdependencia entre el qué y el
cómo que impide disociarlos. Aunque después intenten disociarlos al proponer que todas las
iteraciones sigan la secuencia análisis, diseño, implementación, pruebas. Como no se aclara esta
contradicción es difícil saber si es involuntaria o intencional, siguiendo la idea de Parnas de
forzar (falsear) cualquier proceso a una cascada.
Cada iteración es un mini-proyecto que resulta en un incremento. Las iteraciones hacen

referencia al flujo de trabajo y los incrementos al crecimiento del producto. Un incremento no
es necesariamente aditivo. Por ejemplo, reemplazar un diseño superficial por uno más detallado.
Para una efectividad máxima las iteraciones deben seleccionarse y ejecutarse de forma
planificada. Es por esto que son mini-proyectos. Cada uno de ellos sigue la secuencia análisis,
diseño, implementación, pruebas, como si cada iteración fuese una pequeña cascada.
No obstante, el Proceso Unificado, marca diferencias con la cascada. El Proceso

Unificado:
• es un desarrollo de software dirigido por los riesgos, mientras que la cascada está
dirigida por documento;
27
• entremezcla desarrolladores y artefactos software a través de las fases, mientras que

la cascada los separa claramente;
• emplea una planificación por aproximaciones sucesivas, mientras que en la cascada

toda la planificación se hace al principio.
La presencia de mini cascada en los mini proyectos (iteraciones) es consecuente con el

criterio de éxito: “un proyecto con éxito se ejecutará de una forma directa, sólo con pequeñas
desviaciones de la planificación inicial. Para los planificadores, el éxito fundamental es una
secuencia de iteraciones que siempre avanza, sin tener que volver nunca a los resultados de una
iteración previa para corregir el modelo a algo que se descubrió en una iteración posterior.” Por
tanto, el Proceso Unificado asocia el éxito con la erradicación de la incertidumbre.
Para el Proceso Unificado el desarrollo de software debe ser un proceso incremental que
tolera el refinamiento e, incluso, la marcha atrás, aunque le disgusta. El Proceso Unificado
aspira a ser anticipativo, (proactivo en el sentido de Pressman) a escala pequeña (iteraciones),
pero renuncia a la anticipación a escala del sistema software.
Esta última cualidad unida a las otras, ya descritas, indican que el Proceso Unificado es
una metodología que acepta la incertidumbre y se prepara para enfrentarla (aproximaciones
sucesivas guiadas por el riesgo), pero que desea y espera erradicar la incertidumbre trabajando
con esmero.
La imposición de la secuencia análisis, diseño, implementación y pruebas, en cada

iteración, supone que la incertidumbre correspondiente a cada iteración se ha erradicado antes
de comenzar la iteración, aunque no se haya erradicado la incertidumbre del proyecto en su
conjunto. Algo así, como sumar oráculos exactos de corto plazo para conseguir el resultado de
un oráculo exacto de largo plazo. El Proceso Unificado presume que la incertidumbre es
erradicable, pero no de un golpe como lo intenta la cascada, sino poco a poco.
La capacidad de manejo de incertidumbre del Proceso Unificado encaja bien con la

capacidad de manejo de la incertidumbre de los objetos y se han emparentado. Aunque los
objetos se pueden desarrollar al más puro estilo tradicional y lo hacen en la metodología
llamada OMT, y el modelo estructurado se podría desarrollar con el Proceso Unificado, tomado
en su vertiente incremental.
• Enfoque Ágil
Contrastando con el Proceso Unificado, el enfoque Ágil expresa: “No se puede dar una
descripción del software que se necesita y entonces que alguien lo desarrolle siguiendo un plan
28
y un precio fijo. Una y otra vez, los intentos de conducir los proyectos software de esta manera
han fallado.” Tuvieron que pasar tres décadas desde la adopción (implícita) de las ideas
cartesianas para que comenzaran a cuajar las ideas Ágiles:
“En el 2001, motivados por la observación de que en muchas compañías los equipos de
software estaban atascados cada vez más en el lodo de los procesos, un grupo de expertos de la
industria se reunieron para establecer los valores y principios que permitan a los equipos de
software trabajar rápidamente y responder al cambio. Ellos se denominaron a sí mismos la
Alianza Ágil. Durante varios meses este grupo trabajó para crear una declaración de valores. El
resultado es El Manifiesto de la Alianza Ágil.
Manifiesto para el Desarrollo de Software Ágil
Estamos descubriendo mejores maneras de desarrollar Software haciéndolo y

ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:
• Los individuos y las interacciones sobre los procesos y las herramientas.
• Software operativo sobre documentos detallados.
• Colaboración del cliente sobre la negociación de contratos.
• Responder a los cambios sobre seguir un plan.”
Como sucede repetidamente en el software, unos gurús, se reúnen, piensan mucho y

proponen un sistema de valores para alcanzar el éxito. El adjetivo gurú no es gratis. Salvando
las distancias, Siddarta Gautama hizo algo semejante para alcanzar el nirvana y se convirtió en
Buda. El manifiesto de los Ágiles se parece más a los manuales de autoayuda, a los libros del
tipo ¿Quién se ha llevado mi queso?, que a los textos de ingeniería mecánica, eléctrica, química,
etc.
Los textos de ingeniería mecánica, eléctrica o química se apoyan en modelos de

probado éxito durante siglos: las llamadas leyes naturales. Sobre esos modelos se han
construido edificios metodológicos tan complejos que normalmente requieren de estudios
universitarios y más allá.
La ingeniería de software no dispone aún de un cimiento equivalente a las leyes

naturales y opera con manifiestos explícitos, como el manifiesto Ágil, o encubiertos como los
que subyacen en las metodologías lineales. Debajo de los manifiestos se encuentran las
premisas.
29
El manifiesto Ágil expone dos conjuntos de alternativas y toma partido por el conjunto
que difiere de las ideas vigentes. Es una manera de expresar rebeldía contra esas ideas.
Los Ágiles dicen que tuvieron que descubrir los cuatro valores, mencionados en su
manifiesto, desarrollando software. Pero no hacía falta, esos cuatro valores que tanto trabajo les
costó encontrar son deducibles de la premisa que está debajo del manifiesto: la incertidumbre es
inevitable.
Efectivamente, si la incertidumbre es inevitable:
• La verdad no siempre es alcanzable y ningún método puede asegurar llegar a ella. En estas
condiciones, los humanos son los únicos capaces de tener éxito con su inteligencia,
experiencia, habilidad, intuición y demás cualidades que, históricamente, les han permitido
enfrentar la inmortal incertidumbre inevitable. Por tanto, son preferibles los individuos y las
interacciones sobre los procesos y las herramientas.
• La solución exacta, no ambigua, completa, etc. es inalcanzable. Sólo se podrá llegar a una
solución satisfactoria y la negociación de contratos poco puede precisar las condiciones de
la solución. Únicamente, la colaboración reiterada de los clientes validando software
operativo puede encontrar una solución satisfactoria. Las validaciones no se pueden hacer
sobre documentación por muy detalladas que sean. Por tanto, es preferible software
operativo sobre documentación detallada y la colaboración del cliente sobre negociación
de contratos. A las validaciones se puede llegar mediante aproximaciones sucesivas, si se
conoce algo de la solución y no se mueve demasiado o, en caso contrario, a través de
búsquedas, que pueden ser conducidas por heurísticas si se dispone de ellas. La estrategia
secuencial de primero averiguar con el cliente qué quiere y después desarrollar todo el
cómo, es muy arriesgada porque la incertidumbre inevitable sobre el qué puede hacer errar
el tiro y llegar a una solución no satisfactoria, cuando se han consumido todos los recursos.
• Habrá cambios y habrá que seguirlos para tratar de encontrar una solución satisfactoria; los
planes pueden conducir a soluciones no satisfactorias. Por tanto, es preferible responder a
los cambios sobre seguir un plan. Los contratos, planes y documentos serán más propensos
a consumir recursos inútilmente, mientras más detallados pretendan ser.
El enfoque Ágil adopta (implícitamente) la premisa de incertidumbre inevitable y acepta

sus consecuencias. Cockburn dice: No hay un opuesto a las metodologías ágiles como no hay un
opuesto al tigre de Bengala. Posiblemente sea cierto, teniendo en cuenta la variedad de
dimensiones de las metodologías, pero en el eje de incertidumbre, las metodologías ágiles se
oponen a las metodologías que adoptan la premisa de incertidumbre erradicable. De hecho, el
30
manifiesto contrapone ambos extremos y esta oposición es una cualidad distintiva del enfoque
Ágil que marca una diferencia abisal con las metodologías lineales. Beck se expresa de forma
prudente. “A veces los consejos de Extreme Programming (XP) son absolutamente contrarios a
la sabiduría aceptada.”. En realidad, los consejos de XP son casi siempre contrarios a los
cánones tradicionales. Aunque, como dice Beck, ninguna de las ideas de XP es nueva. La
humanidad utiliza esas mismas ideas de una forma u otra, desde que se tiene que enfrentar con
incertidumbre inevitable.
Cada variante Ágil propone una forma de enfrentar esa premisa, y la matiza con
aspectos sociales del desarrollo de software. Esperar que alguna de esas variantes sea El Camino
del Éxito es aceptar otra vez la tentación de la sublimar la importancia del método. Pero es muy
difícil resistir a esa tentación. Dice un libro reciente de desarrollo Ágil: Extreme Programming
es un buen método de propósito general para el desarrollo de software.
Sería mejor tomar los métodos Ágiles como conjuntos de heurísticas que pueden o no
ser adecuadas, juntas o por separado, según cuándo, cómo, … Una descripción más detallada de
XP confirma la premisa de incertidumbre inevitable y la magnitud de esta incertidumbre que
pretende abordar: XP es una metodología ligera para equipos de trabajo de tamaño pequeño a
medio, desarrollando software en condiciones de requisitos vagos o de cambios frecuentes.
El enfoque Ágil considera que el problema básico del desarrollo de software es el

riesgo, consecuente con la premisa de incertidumbre inevitable. Para enfrentar el riesgo, el
enfoque Ágil propone ciclos cortos de versiones y dentro de ellas, iteraciones de una a cuatro
semanas; implementar las características de más alta prioridad; integrar al cliente al equipo de
desarrollo; crear y mantener conjuntos detallados de pruebas, … El enfoque Ágil, renuncia a la
anticipación a escala de iteración y de sistema. Adopta una actitud reactiva, en el sentido de
Pressman.
El enfoque Ágil estima que el diseño no es dibujar un puñado de esquemas y entonces

implementar el sistema conforme a esos esquemas. Se reconoce que los esquemas pueden
aportar beneficios, pero que no ofrecen una retroalimentación concreta, es decir de
funcionamiento. Con esta última idea, el enfoque Ágil marca profundamente su vocación
exploratoria y rompe el dogma que exige un buen diseño antes de la implementación. Una vez
más se hace patente la premisa de incertidumbre inevitable que no se puede eliminar por mucho
que se piense.
Se deja libertad de diseñar con esquemas a quien lo necesite, pero se recomienda que
recurran inmediatamente al código cuando surja alguna pregunta que puede ser respondida por
el software operativo. El diseño puede ser mejorado en la siguiente versión mediante la
31
denominada refactorización: un cambio en el sistema que no modifica su comportamiento, pero

enriquece alguna cualidad no funcional. Los Ágiles renuncian a erradicar la incertidumbre del
qué (en este caso, diseño) antes del cómo (en este caso implementación) porque la consideran
inevitable y se enfrentan a ella de las dos maneras posibles: refinar la solución o volver a
empezar, en el peor caso.
Es cierto que el diseño esquemático no ofrece la retroalimentación del funcionamiento

del sistema, pero también es cierto que el diseño esquemático es la fuente común de
retroalimentación sobre las propiedades del sistema que dependen de su estructura; ni el código,
ni el sistema funcionando ofrecen retroalimentación sobre estas propiedades, por ejemplo, la
flexibilidad.
La arquitectura del sistema es importante para el enfoque Ágil, pero la imaginan como
un todo, más que dividida en partes. Se manifiesta la intención holística del enfoque Ágil. La
arquitectura es capturada por la metáfora del sistema. Si se dispone de una buena metáfora,
cualquier miembro del equipo podrá decir el funcionamiento del sistema como un todo.
El análisis de las propiedades del enfoque Ágil lo aleja de las metodologías

tradicionales, más allá del Proceso Unificado, en el eje de incertidumbre. El enfoque Ágil aplica
una estrategia cíclica, de mayor frecuencia, con una componente exploratoria importante. Se
podría decir que el enfoque Ágil se dirige a problemas del tipo “sabré lo que quiero cuando lo
vea”, referidos por Boehm para justificar la Espiral.
La capacidad de incertidumbre del modelo de objetos, su moderada inercia, se acomoda

relativamente bien a las cualidades de movilidad del enfoque Ágil, aunque convendría un
modelo menos inerte aún para aumentar la eficiencia del ensayo y error. El modelo de software
tradicional (funciones y datos) es demasiado inerte, aún cuando renuncie a los esquemas
(dibujos), a causa de su riqueza de relaciones unívocas.
• Resumen de las metodologías
Métrica 3 es la metodología más cercana a la premisa de incertidumbre erradicable y a

la pretensión de erradicarla antes de comenzar el desarrollo del sistema. La división, exactitud,
detalle y completitud son cualidades fundamentales. Métrica 3 espera obtener del análisis de los
requisitos la satisfacción del usuario y además, facilidad de adaptación, en virtud de una
supuesta capacidad predictiva del análisis de los requisitos. En el sentido de Pressman, Métrica
3 es proactiva
Proceso Unificado considera que la incertidumbre es erradicable, pero poco a poco, no

antes de comenzar el desarrollo. La división, exactitud, detalle y completitud también son
32
cualidades fundamentales, pero progresivas y además, se admiten perspectivas de carácter

holístico y hermenéutico. El Proceso Unificado aspira a que el desarrollo sea un proceso
incremental con refinamiento, pero sin marcha atrás, aunque admite esta posibilidad.
El enfoque Ágil considera que la incertidumbre es inevitable, acepta todas sus

consecuencias, y adopta medidas para enfrentar la incertidumbre. El enfoque Ágil busca la
satisfacción del usuario a través de la interacción reiterada del usuario con software operativo y
además, por esa misma vía intentan adaptarse a la evolución porque desconfían de la
anticipación e incluso la desaconsejan. En el sentido de Pressman, el enfoque Ágil es reactivo,
al estilo de Indiana Jones de “No te preocupes, ya pensaré algo”.
6.5 Recapitulación
El estudio de todos los problemas citados demuestra que su origen es la premisa acerca
de la incertidumbre. La suposición de incertidumbre erradicable conduce a una actitud que
aspira a alcanzar una solución exacta, no ambigua, completa, anticipada, a través de la
aplicación rigurosa de un método. El pensamiento, los modelos, las técnicas responden a esta
aspiración. Cuando no se consigue lo esperado, generalmente, se buscan las causas en
situaciones accidentales, falta de tiempo, de rigor, veleidad de los clientes, y se busca hasta otro
método, pero se mantiene la premisa, como sucede frecuentemente en la historia humana.
El modelo de software temprano aspiraba a la exactitud que inspira su aspecto

matemático de función de transformación de datos. El diseño procuraba otorgar la exactitud, no
ambigüedad, completitud y anticipación esperada, a través de un método de descomposición
(análisis) y recomposición (síntesis) lineal del sistema software.
Siguiendo el pensamiento cartesiano, cada diseño comenzaba a partir de los requisitos

ad hoc de cada situación, sin utilizar soluciones previas; se renunciaba implícitamente a la
reutilización, aunque se clamaba por ella y por no redescubrir diariamente el Mediterráneo.
Los diseños trataban de ser un reflejo fidedigno del dominio del problema que debía
resolver el sistema software. La idea estaba en sintonía con los métodos científicos tradicionales
de describir la estructura de los flujos existentes, sin considerar mecanismos sobre la génesis de
esas estructuras, porque simplemente estaban dadas y eran inmutables.
Para enfrentarse a los cambios no previstos, considerados incertidumbre excepcional,

utilizaron la división en módulos. Pero no se produjo el resultado deseado de facilitar los
cambios y además, los cambios se convirtieron en un azote del desarrollo de software. Los
trabajos dirigidos a resolver ese problema no fueron atendidos y continuaron las dificultades.
33
En ese universo donde muchas cosas no funcionaban según lo esperado, proliferó el

empirismo, los gurús y el criterio de autoridad, como elemento decisor. Cada autor decía lo que
le parecía bien y lo avalaba con la frase: esto (que digo) es la mejor práctica.
Aparecieron innumerables métodos de desarrollo de software y tomó fuerza el modelo

de objetos, nacido en la cuna de la simulación. Los objetos traían la carga de incertidumbre
propia de su cuna y la enriquecieron, aún más añadiéndole mayor capacidad de ambigüedad.
Con los objetos, más métodos, más confusión, desorden, preguntas. Surgieron los
patrones, el primer camino oficial de reutilización, ricos además, en técnicas de introducción de
ambigüedad en el diseño, aunque de forma implícita. La ambigüedad todavía no era, ni es, bien
recibida. No obstante, los objetos se diseñaban según las ideas tradicionales de funciones que
transforman datos, complicando los problemas, en vez de atenuarlos.
A pesar de esos inconvenientes, con y alrededor de los objetos, comenzó un movimiento

de cambio de perspectiva del universo software, cuyo fondo era el cambio de premisa filosófica.
Hubo que esperar más de diez años para que se reconociera explícitamente, y de forma general,
la premisa de incertidumbre inevitable. Falta aún edificar una teoría de la ingeniería de software
que considere esta premisa, aceptada hoy por la ciencia.
7. Conclusiones
La filosofía es parte de la cultura y está presente siempre aunque las tecnologías se
crean en otro mundo aparte. En particular, la ingeniería de software temprana se construyó sobre
cimientos puramente cartesianos que le dieron un impulso inicial, pero que después se
convirtieron en un severo obstáculo. La suposición de una verdad alcanzable, a través del
método, era una mirada arrogante, desde afuera, al universo software; era una expectativa muy
alta que al naufragar fomentó la frustración y el desorden. Cada uno se dedicó a buscar su
propia verdad.
La práctica actual de desarrollo de software se está desplazando de paradigma filosófico

y ya acepta la nueva premisa, junto con sus consecuencias. La ingeniería de software está
modificando la perspectiva de su universo, está cambiando implícitamente de modelo. En el
curso de este trabajo se ha demostrado que la incertidumbre es una pieza clave del nuevo
modelo de la ingeniería de software; una pieza con capacidad para enlazar, explicar y predecir
propiedades de los elementos del universo software: modelos, diseños, productos, métodos. La
incertidumbre es la mirada humilde, desde adentro, al universo software; es la mirada que
muestra su complejidad.
34
Bibliografía
Almendros, Manuel Psicología del caos Ediciones La llave. Madrid 2002.
Beck, Kent eXtreme Programming explained Addison – Wesley 2000
Berard, Edward V. Abstraction, Encapsulation and Information Hiding
http//www.toa.com/pub/abstraction.txt.
Blum, B. I. Beyond Programming: To a New Era of Design. Oxford University Press, 1996.
Boehm, Barry W. A Spiral Model of Software Development and Enhancement ACM SIGSOFT
Engineering Notes. Vol. 11 Nº 4 Aug. 1986 pp. 14-24.
Booch, Grady Object Oriented Analysis and Design Benjamin/Cummins Publishing. 1994.
Bourque, Pierre et al. Fundamental principles of software engineering- a journey Journal of
Systems and Software 62 (2002) pp. 59-70).
Brooks, F.P. Jr. The Mythical Man-Month: Essays on Software Engineering, Addison Wesley
Reading MA 1995. Second Edition.
Cockburn, Alistair Agile Software Development Addison-Wesley 2002.
DeMarco, Tom Slack Broadway Books NY. 2002.
DeMarco, Tom Controlling Software Projects Yourdon Press Computing Series. Prentice Hall
1982.
Descartes, René El discurso del método Editorial Alba. Madrid. España. 2001.
Dijkstra, Edsger W. EWD 1308: GAT Led to Notes on Structured Programming in Software
Pioneers. Springer 2002.
Eickelmann, Nancy ACM Fellow Profile: David Lorge Parnas Software Engineer Notes vol. 24
nº 3 May 1999 pp. 10-14.
Glass, Robert L. Reuse: What´s Wrong with This Picture? IEEE Software April 1998 pp. 57-59.
Glass, Robert L. Questioning the Software Engineering Unquestionable IEEE Software
May/June 2003 Vol. 20 Nº 3 pp.120-119.
Gómez, F.J. Espelosín Introducción a la Grecia antigua Alianza Editorial Madrid 1998.
Goodwin, Brian Las manchas del leopardo Tusquets 1998.
Guttag, John V. Abstract Data Types, Then and Now in Software Pioneers. Springer 2002.
Haythorn, Wayne What is object-oriented design? JOOP Vol. 7 Nº1 March/April 1994 pp-67-
78.
Henderson-Seller, Brian Convergence Is in the Air ROAD March/April 1996 pp. 47-49, 54.
Jacobson, Ivar et al. El proceso unificado de desarrollo de software Addison - Wesley 2000.
Johnson, Spencer. ¿Quién se ha llevado mi queso? 18º Edición Colección Empresa XXI.
Ediciones Urano. Barcelona. 2000
Klir, George J. and Tina A. Folger Fuzzy Sets, Uncertainty and Information Prentice Hall. N. J.
1988.
Larman, Craig Applying UML and Patterns First Edition. Prentice Hall 1998.
Lehman, M.M. Programs, Life Cycles and laws of software Evolution Proc. IEEE Special Issue
on Software Engineering, 68 (September 1980) 1060-1076.
35
Lorenz, Edward N. La esencia del Caos Debate 2000 España.

Martin, Robert C. Agile Software Development Prentice Hall 2003.
Matsubara, Tomoo Instability and Uncertainty Are Our Challenge IEEE Software Nov/Dec.
1997 Vol. 14 Nº 6.
Ministerio de Administraciones Públicas. España. Métrica Versión 3 (2000).
Morin, Edgar Introducción al pensamiento complejo Gedisa. S.A. España 1995.
Parnas, David L. The Secret History of Information Hiding in Software Pioneers. Springer 2002.
Parnas, David L. On the Criteria To Be Used in decomposing System into Modules Com. ACM
Dec 1972 Vol. 15 Nº 12 pp. 1053 – 1058.
Parnas, David L. Why Software Jewels Are Rare? Computer. February 1996, pp. 57-60.
Parnas, David L. & Paul C. Clements A Rational design Process: How and Why to Fake It
Trans. on Software Engineering Vol. SE 12 Nº 2 February1996 pp. 251-257.
Parnas, David L. Successful Software Engineering Research ACM Sigsoft Software Engineering
Notes Vol. 23 Nº 3 May 1998 pp. 64-68.
Parsons, Rebecca Components and the World of Chaos IEEE Software May/June 2003 Vol. 20
Nº 3 pp. 83-85.
Pfleeger, Shari Lawrence The Nature of System Change. IEEE Software. May, 1998.
Pressman, Roger S. Ingeniería de Software. Un enfoque práctico Cuarta Edición. McGraw Hill.
1997 España.
Roger S. Pressman. “Ingeniería del Software. Un Enfoque Práctico”. McGraw-Hill. 1997.
Prigogine, Ilya ¿Tan solo una ilusión? Cuarta edición. 1997 Tusquets. España.
Raccoon, L.B.S. The Chaos Model and the Chaos Life Cycle ACM SIGSOFT Software
Engineering Notes Jan. 1995 Vol. 20 Nº 1. pp. 55 – 66.
Rodríguez, Juan Manuel Introducción al Discurso del Método Editorial Alba, Madrid 2001.
Rumbaugh, James et al. Modelado y diseño orientado a objetos Prentice Hall 1994.
Tzu, Sun El arte de la guerra Edaf, Madrid 2001.
Sobrino, Alejandro et al. ¿Hay algoritmos imprecisos? Actas del IV Congreso de la Lógica,
Metodología y Filosofía de la Ciencia en España. Valladolid 3-6 noviembre de 2004. pp. 614-
620.
Xing, Cong-cong & Boumediene Belkhouche On Pseudo Object-Oriented Programming
Considered Harmfu” Communication of ACM October 2003 Vol. 46 Nº 10 pp. 115-117.
Webster, New Encyclopedic Dictionary Könemann. Germany 1994.
Weisert, C. Pseudo Object-Oriented Programming Considered Harmful ACM SIGPLAN
Notices 37, 4 (2002).
Yourdon, Ed Análisis estructurado moderno Prentice Hall. México 1993.
36

0901 Preguntas

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

0901 Preguntas

Hochgeladen von

Copyright:

Verfügbare Formate

En busca de respuestas

para la ingeniería software

Nelson Medinilla Martínez

En el campo del proceso de construcción de software: ¿Cuándo usar una metodología u

Después de muchos años de empirismo se descubre que hay respuestas universales y

2. Fundamentos filosóficos de la temprana ingeniería de software

eliminar la confusión en su mundo mediante una explicación racional y científica. “Buscando

Los pensadores principales de la época compartían la misma premisa y la misma

Las principales ideas en boga de la temprana ingeniería de software tenían el mismo

• El software adopta una forma matemática. Se define cualquier sistema software

• El método de desarrollo de software se considera la clave del éxito y universal para

la piedra filosofal capaz de convertir cualquier conjunto de requisitos en un sistema

• El método básico de desarrollo de software coincide con el método cartesiano. La

• La premisa software coincide con la premisa cartesiana: todo se puede conocer. El

• La ingeniería de software temprana obvia las soluciones previas. La construcción de

• La ingeniería de software no se ha ocupado de la experimentación en sentido

3. Consecuencias prácticas de la influencia filosófica

Los problemas llegaron después, cuando por ejemplo:

• el modelo software, como una función de transformación de datos, era insuficiente

• había que distorsionar o saltarse el método porque la verdad era inalcanzable, al

• el método consumía demasiados recursos persiguiendo objetivos difíciles o

• había que reinventar la rueda en cada proyecto;

• el método se hacía demasiado inerte para ajustarse a los cambios de requisitos;

• convenía tener datos experimentales para tomar decisiones y no se disponía de

Y cuando se juntó todo lo malo se abrió el suelo, apareció la perplejidad y la frustración.

• Ineficacia para encontrar soluciones porque ha buscado en un espacio equivocado,

• Ineficiencia buscando objetivos inalcanzables en el espacio equivocado. El estándar

• Frustración, porque todo el sistema de creencias, la teoría de toda la vida no se

• Oposición virulenta a los puntos de vista diferentes. Se agredió a la programación

En fin, el fundamento filosófico cartesiano de la temprana ingeniería de software tuvo

En general, vaguedad se asocia con la dificultad de hacer distinciones agudas o precisas

Cada uno de esas dos formas de incertidumbre (vaguedad y ambigüedad) se relaciona

En ausencia de incertidumbre, la percepción del mundo es simple. La complejidad

En presencia de incertidumbre la percepción del mundo es mucho más compleja. La

En presencia de incertidumbre los universos sometidos a estudio se alteran si se dividen

Hay riesgo cuando existe incertidumbre sobre la ocurrencia de un suceso cuya

5. Otra alternativa filosófica

Se puede considerar que la incertidumbre es inevitable porque es imposible evitarla o

La premisa no es tan nueva. Posiblemente sea recurrente en la historia humana con

A mediados del XX, volvió la incertidumbre inevitable a la ciencia. Poco a poco se ha

La ingeniería de software aceptó la incertidumbre inevitable a finales del XX, a pesar de

Las estructuras abstractas de datos, el principio de ocultación de información y la

El cambio de perspectiva filosófica se ha podido explicar el problema clave ¿Por qué no

Desde el punto de vista de la complejidad, el espacio de existencia de la ingeniería de

El nuevo paradigma resuelve muchos problemas y permite predecir propiedades de las

La disidencia involuntaria de Parnas comenzó cuando escribe que la referida forma de

6.2 Reproducir la realidad en el diseño

Puesto que el dominio y el software, generalmente, difieren de naturaleza, se copian

La copia de la realidad, en el diseño software, posiblemente facilite la comprensión del

6.3 Objetos vs. estructurado

Figura 1. Modelos software

El modelo estructurado, en términos de una función de transformación de datos, fue

Primero, en las definiciones. El elemento fundamental del estructurado es la función de

Segundo, en la capacidad de abstracción, que es un recurso de ambigüedad en la

En fin, el modelo estructurado es simple, se expresa en términos de funciones que

Figura 2. Convergencia de objetos y estructurado

6.4 Las metodologías

En la ingeniería de software abunda la literatura que se apoya en la experiencia personal

personas del grupo) somos desarrolladores de software practicantes, no simples espectadores

Problema Solución Tipo

Bien conocido y estable Bien conocida y estable S

Bien conocido y estable No bien conocida e inestable P

No bien conocido e inestable No bien conocida e inestable E

Tabla 1. Clasificación de los sistemas software