PDF de programación - En busca de respuestas para la ingeniería software

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



................................................................................................................................


3
1. Introducción


................................................

4


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


...................................................................

6


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


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


.............................................................................................................................


34

35


...................................................................................................................................



7. Conclusiones

Bibliografía


2

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

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

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

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

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

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