1. No category

L. S. C. Edgar Darío Ramírez de León
[email protected]
NO SILVER BULLET: ESSENCE AND ACCIDENTS OF
SOFTWARE ENGINEERING
(ENSAYO)
Resumen
Este ensayo discute las aseveraciones de Brooks [1] sobre las características y/o problemas
intrínsecos (esencia, como los denomina el autor), los avances “accidentales” que han resuelto
algunos problemas de la ingeniería de software y las esperanzas en más avances, tecnologías,
desarrollos e investigación para resolver aquellos problemas no resueltos aún por dicha disciplina.
Dentro de las características y/o problemas intrínsecos el autor discute: complejidad,
conformidad, mutabilidad e invisibilidad del software. Por su parte, señala como avances o
desarrollos accidentales: lenguajes de alto nivel, tiempo compartido y ambientes de programación
unificados. Finalmente, como esperanzas destaca: avances en lenguajes de alto nivel,
programación orientada a objetos, inteligencia artificial, sistemas expertos, programación
“automática”, programación gráfica, verificación de programas, ambientes y herramientas, y
estaciones de trabajo.
1. Introducción
Brooks [1] desarrolla un ensayo donde plantea características y/o problemas intrínsecos
(esencia), donde señala: complejidad, conformidad, mutabilidad e invisibilidad del software. Por
otra parte, argumenta avances “accidentales” que han resuelto algunos problemas de la ingeniería
de software, avances tales como: lenguajes de alto nivel, tiempo compartido y ambientes de
programación unificados.
Finalmente discute algunas esperanzas en más avances, tecnologías, desarrollos e
investigación para resolver problemas no resueltos aún por dicha disciplina, en consecuencia, el
autor discute sobre los lenguajes de alto nivel, programación orientada a objetos, inteligencia
artificial, sistemas expertos, programación “automática”, programación gráfica, verificación de
programas, ambientes y herramientas, y estaciones de trabajo.
Como en una película de terror, donde se busca matar al lobo (el monstruo de la película),
usando balas de plata, Brooks trata esas esperanzas computacionales como la(s) posible(s) bala(s)
de plata que acabará con el monstruo computacional, concretamente en el área de ingeniería de
software. De dicha analogía deriva el titulo: No silver bullet.
El presente ensayo está dividido de la siguiente manera: la sección 2 comprende el análisis
del trabajo del autor. En de dicha sección se encuentran: la sección 2.1 donde se describe, de
manera general el contenido del artículo (dividido en 3 subsecciones, uno correspondiente a los
problemas –esencia- del software, otro a las dificultades resueltas, y un último sobre las
esperanzas para la solución de los problemas inherentes) y la sección 2.2 enfatiza detalles
relevantes de dicha investigación (con 3 subsecciones asimilando las subsecciones en 2.1) con las
Página 1 de 6
L. S. C. Edgar Darío Ramírez de León
[email protected]
subsecciones, indicando los conceptos en los que existe mutuo acuerdo (opinión personal) y
algunas discrepancias ideológicas. La sección 2.2 es, en esencia, la crítica al artículo.
Por último, se presentan las conclusiones del análisis del ensayo de Brooks. Y, al igual que en
[2] se proponen algunas líneas o temas de investigación futuros, no una gran cantidad ya que el
ensayo analizado no provee, en mi opinión, elementos cuantitativos que permitan el desarrollo de
otras investigaciones, más allá de la simple emisión de juicios personales.
2. Análisis del artículo
Para tener una mayor comprensión del tema, así como de las discrepancias ideológicas
(personales) respecto al mismo, es necesario, describir un panorama general del artículo,
destacando sus puntos importantes. Por tanto, a manera de lista, describiré a grandes rasgos el
desarrollo del tema, para posteriormente desplegar el análisis.
2.1. Descripción general del artículo
Para el desarrollo de su ensayo, Brooks adopta el concepto del esencialismo de Aristóteles [3],
[4], donde Aristóteles plantea la esencia como todo aquello inherente de la naturaleza (en este
caso, naturaleza del software, y concretamente, Brooks señala esencia como los problemas
inherentes del software), y los accidentes, aquellas dificultades que han sido resueltas en la
naturaleza, que, sin embargo no son las inherentes a ella (en este caso, avances, tecnologías,
desarrollos e investigación para resolver problemas no resueltos aún por la ingeniería de software,
y cuya naturaleza problemática no es inherente al software). A continuación se presentan dichos
elementos y las esperanzas en la búsqueda de la bala de plata que acabe con los monstruos de la
ingeniería de software.
2.1.1. Esencias (problemas inherentes del software)
1. El autor plantea características y/o problemas intrínsecos (esencia) del software. En ellos,
señala la complejidad, conformidad, mutabilidad e invisibilidad del software.
2. Señala que las entidades de software son más complejas por su tamaño que quizás,
cualquier otra construcción humana, ya que no existe, en un software dos partes iguales
(al menos a nivel de código).
3. Indica que la conformidad es algo difícil de lograr en un software, debido a que muchos
aspectos de conformidad son forzados sin ritmo o razón por sistemas e instituciones
humanas.
4. La mutabilidad del software, de acuerdo con el autor, es aún mayor que en otro tipo de
construcciones. Presenta como ejemplo, construcción de edificios, carros y computadoras.
En dichos ejemplos, los cambios difícilmente se hacen a un producto acabado (carro), y si
se necesitasen remodelaciones, estas son mínimas y en periodos de tiempo considerables.
Este escenario no existe en los sistemas. Brooks menciona además, que los sistemas, en
corto tiempo, estarán sujetos a múltiples factores sociales, leyes, usuarios, entre otros que
forzarán una mayor naturaleza dinámica en los sistemas.
Página 2 de 6
L. S. C. Edgar Darío Ramírez de León
[email protected]
5. Para concluir con la esencia (problemas) del software, destaca que éste es invisible, una
abstracción de una entidad.
2.1.2. Accidentes (dificultades resueltas en el software)
1. Brooks argumenta avances “accidentales” que han resuelto algunos problemas (no
intrínsecos) de la ingeniería de software, avances tales como: lenguajes de alto nivel,
tiempo compartido y ambientes de programación unificados.
2. Concibe al génesis de los lenguajes de alto nivel, como el ataque más poderoso en los
problemas de productividad, fiabilidad y simplicidad del software. Afirma que los
lenguajes de alto nivel liberan mucho de la complejidad accidental de un programa,
proporcionando operaciones, tipos de datos, secuencias y condiciones.
3. Con el concepto de tiempo compartido, se logró una mayor productividad de los
programadores y en la calidad de sus productos.
4. El autor, ve a los ambientes unificados de programación como una manera de atacar las
dificultades que resultan del uso individual de programas, proveyendo en un mismo
entorno, librerías, unified file formats, filtros, entre otros.
2.1.3. Esperanzas de encontrar la bala de plata (avances técnicos)
1. Avances en los lenguajes de alto nivel. Brooks señala que cuando la efectividad del
lenguaje de programación Ada sea juzgada, se verá que habrá hecho una gran diferencia.
No por las opciones particulares del lenguaje, ni por la combinación de ellas. La gran
contribución de Ada habrá sido el cambio ocasionado en los programadores adoptando
técnicas modernas de diseño de software.
2. Brooks, concuerda con muchos estudiantes quienes tienen muchas esperanzas en la
programación orientada a objetos que cualquier otra técnica de moda en los 80’s.
3. Duda que Inteligencia Artificial sea el descubrimiento revolucionario que impacte
enormemente en la productividad y calidad del software. En esencia, no cree que las
técnicas o algoritmos de la IA sean lo suficientemente genéricos para ser aplicados en
cualquier dominio de problemas, por ejemplo, algoritmos de reconocimiento de imágenes
pudieran servir en reconocimiento de voz.
4. Ve que los Sistemas expertos seguramente pondrán al servicio lo que personas expertas
pondrán a disposición de personas sin tanta experiencia en un área específica.
5. Concibe el origen de la programación “automática” como una técnica para la construcción
de generadores de sistemas.
6. El autor, no considera que la programación gráfica resuelva los problemas inherentes del
software ya que como algo abstracto, los sistemas son difíciles de visualizar.
7. No cree en la verificación de programas como algo para aumentar la productividad.
8. Considera a las herramientas y entornos como algo que seguramente aumentará la
productividad y fiabilidad del software.
9. La evolución de las estaciones de trabajo, proceso que seguramente se dará, no será algo
mágico que proporcione mejoras en los problemas de software.
Página 3 de 6
L. S. C. Edgar Darío Ramírez de León
[email protected]
2.2. Críticas y aseveraciones respecto al artículo
Antes de presentar las críticas y aseveraciones relacionadas con los puntos indicados en las
secciones anteriores, restaría destacar tres puntos que por razones estructurales no fueron
presentados anteriormente. Estos son:
1. Brooks opina que la adquisición de software a la medida ha cambiado en relación con la
compra de paquetes de software generalizados y que este gran cambio se debe a la
proporción en costo software/hardware. Hace años, quien compraba una computadora de
un millón, consideraba que pagar cien mil para adquirir un programa contable a la medida
era viable. No obstante, dado que el costo en hardware se ha reducido, es ahora inviable
pagar cien mil cuando un equipo de cómputo cuesta diez mil.
2. Considera al refinamiento de requisitos y desarrollo de prototipos como una técnica
importante para el desarrollo de software, no sólo proyectos “pequeños” (ningún proyecto
es pequeño realmente), sino también, en grandes proyectos.
3. Critica el hecho que muchas organizaciones se centran en la búsqueda de grandes
administradores y, creen que ellos (los administradores) les resolverán todos los
problemas. Señala entonces, que no sólo se debe contar con un buen administrador del
proyecto, además, debe existir un buen diseñador del mismo, y sus beneficios (equipo,
financiamiento, infraestructura, etc.) deben ser los mismos que los del equipo de
administración del proyecto.
Aunque no existen críticas (personales) en cuanto a lo que Brooks llama esencias y
accidentes en la ingeniería de software, y concretamente, en sus productos (software), se
detallarán el porqué de la ausencia de críticas en las secciones correspondientes a continuación.
Por su parte, en la “búsqueda por la bala de plata” sí se emitirán juicios personales, algunos
contrariando las opiniones del autor, otros confirmándolos y añadiendo más argumentos que
sostienen las opiniones del autor.
2.2.1. Críticas a las esencias (problemas inherentes del software)
Cualquier persona quien haya participado en el desarrollo de un software, estaría de acuerdo
con los problemas inherentes del software de los que habla Brooks (complejidad, conformidad,
mutabilidad e invisibilidad). Por tanto, en cuanto a las esencias (problemas inherentes del
software) de las que trata el ensayo no hay refutación alguna y siguen siendo, hoy en día, temas
de investigación.
2.2.2. Críticas de los accidentes (dificultades resueltas en el software)
En lo que define Brooks como los avances técnicos “accidentales” que han resuelto algunos
problemas de la naturaleza (no inherente) del software, muchas concordaríamos en que los puntos
expuestos por el autor, son indudables ya que tratan avances significativos en el desarrollo de
software, avances que han marcado una época.
Página 4 de 6
L. S. C. Edgar Darío Ramírez de León
[email protected]
2.2.3. Críticas en las esperanzas de encontrar la bala de plata (avances
técnicos)
Las siguientes críticas corresponden a la lista de puntos de la sección 2.1.3.
1. Lo que señala el autor en el punto 1, tuvo relevancia en su momento. Hoy en día, Ada ha
dejado de ser un lenguaje en uso, debido principalmente a la existencia de lenguajes de
alto nivel más potentes y técnicas de programación orientada a objetos. Sin embargo, no
podemos negar que los conceptos de modularidad y demás que introdujo Ada y sus
lenguajes contemporáneos fueron fundamentos de los lenguajes y técnicas modernas.
2. La POO ha demostrado, hoy por hoy, ser una técnica poderosa para el desarrollo de
software. Por lo que las aseveración de Brooks (punto 2) y muchos estudiantes de los 80’s
ha sido atinada.
3. Acuerdo totalmente con el autor sobre el punto 3. Muchas investigaciones se realizan hoy
en día en el campo de la IA. No obstante, no creo que las computadoras puedan, algún día
resolver problemas de la misma manera en que lo hacemos los humanos. Las
computadoras sólo pueden resolver problemas si los humanos las programamos para ello,
y un problema en particular.
El desarrollo vertiginoso en las tecnologías del ser humano es visto por Monserrat [5]
como una “involución crítico fundamental”. La IA no debería escapar de este dictamen.
Por ser una disciplina creada por el ser humano, que forma parte del cúmulo de
conocimientos generados por el proceso de evolución del mismo ser humano, sería
interesante hacer una evaluación de qué tenemos, dónde estamos, hacia dónde vamos y
qué queremos de nuestra humanidad.
García [6], en “¿Qué inventar? Hacia una “involución crítico fundamental” dice: “La
idea sería la de hacer un stop en la evolución, abrir un paréntesis, para volver (involución)
críticamente sobre los fundamentos mismos de dicha evolución… El caso es que dicha
reflexión crítica se podría hacer sobre muchos aspectos y repercusiones, sociales entre
otras, del avance tecnológico…”.
Más allá del debate filosófico y social y lo que las repercusiones tecnológicas de ello
implica, dudo mucho que la IA sea la disciplina que acabe con los problemas del mundo,
del ser humano y por consecuencia, ser la bala de plata para los monstruos de la ingeniería
de software.
4. En los puntos 4, 5 y 6 me encuentro totalmente de acuerdo con el autor.
5. Respecto a la verificación de programas, es totalmente cierto que no contribuye en la
productividad del desarrollo de software, por el contrario, incrementa la complejidad y
disminuye la productividad al requerirse, además del software mismo, técnicas o métodos
los verifiquen.
6. En cuanto a las herramientas y entornos (punto 8 de la sección 2.1.3) es, hoy en día un
hecho que éstas aumentan la productividad en el desarrollo de software.
Página 5 de 6
L. S. C. Edgar Darío Ramírez de León
[email protected]
7. Finalmente, lo que Brooks comenta sobre las estaciones de trabajo y cómo estas no
proporcionarán alguna mejora en el desarrollo de software no estoy de acuerdo. Por el
contrario, se requieren equipos de cómputo acordes con las exigencias de los sistemas
actuales, y, mientras más potentes sean los equipos, el desempeño de los sistemas será
mejor.
3. Conclusiones y posibles líneas o temas de investigación
El ensayo presentado por Brooks, es un reflejo, en su mayor parte (salvo en las criticas
personales realizadas en la sección anterior) de la ingeniería de software y sus productos
(software). Hoy en día, factores como la complejidad, conformidad, mutabilidad, invisibilidad del
software siguen siendo la esencia (problemas inherentes) de los mismos.
Tal vez no exista una bala de plata, sino más bien se requiera de balas de plata (en plural)
para acabar con los monstruos del software. Es decir, se necesita de la combinación de las
técnicas, métodos y disciplinas tecnológicas para atacar de manera eficiente y reducir (muy lejos
de acabar) la fortaleza de los monstruos del software.
Finalmente, la línea o tema de investigación que sería muy interesante analizar es la
“involución crítico fundamental” y que consiste, básicamente en detenernos y no sólo evaluar
dónde estamos tecnológicamente hablando, sino también, detenernos para organizarnos y tal vez,
empujar todos para una misma dirección. ¿Cuál dirección? Eso no lo sabremos hasta que no lo
sometamos a escrutinio.
Referencias
[1] Brooks, F. P. 1986. No Silver Bullet Essence and Accidents in Software Engineering.
Proceedings of the IFIP Tenth World Computing Conference, pp. 10691076, 1986
[2] Ramírez de León, E. D. 2009. Calidad en modelos conceptuales: un análisis
multidimensional de modelos cuantitativos basados en la ISO 9126 (Ensayo).
http://edario-it.blogspot.com/iso9126
[3] Estrada, C., Oyarzún, M., y Yzerbyt, V. 2007. Teorías implícitas y esencialismo psicológico:
herramientas conceptuales para el estudio de las relaciones entre y dentro de los grupos.
http://redalyc.uaemex.mx/redalyc/pdf/967/96716109.pdf
[4] Molina Cantó, E. 2002. Principio de No-Contradicción y usos del verbo ser en Aristóteles.
http://onomazein.net/7/ser.pdf
[5] Monserrat, J. 1984. Epistemología Evolutiva y Teoría de la Ciencia. Madrid: Publicaciones de
la Universidad Pontificia Comillas.
[6] García García, P. E. ¿Qué inventar? Hacia una “involución crítico fundamental”.
http://www.uam.es/personal_pdi/psicologia/pei/download0607/pablo_garcia.pdf
Página 6 de 6