No hay bala de plata:

Esencia y accidentes de Ingeniera de Software

Frederick P. Brooks, Jr.
Fashioning construcciones conceptuales complejas es la esencia ;accidentales tareas
aparecen en la representacin de las construcciones en el lenguaje. Avances anteriores
han reducido tanto las tareas accidentales que el progreso futuro depende ahora de
abordar la esencia.
De todos los monstruos que pueblan la pesadilla de nuestro folklore, ninguno aterrorice ms de
los hombres lobo, ya que transforman inesperadamente de lo familiar en horrores. Para estos,
se busca balas de plata que puede mgicamente sentar a descansar.
El proyecto de software familiar, al menos como se ve por el administrador no tcnico, tiene
algo de este personaje, por lo general es inocente y sencillo, pero es capaz de convertirse en
un monstruo de las planificaciones perdidas, presupuestos soplado y productos
defectuosos. As escuchamos gritos desesperados de una bala de plata - algo para que los
costos de software caen tan rpidamente como los costos de hardware hacen.
Pero, al mirar tp el horizonte de una dcada, por lo tanto, no vemos ninguna bala de plata. No
hay desarrollo nico, ya sea en la tecnologa o en la tcnica de mananagement, que por s
mismo incluso promete una mejora de un orden de magnitud de la productividad, en la
fiabilidad, en la simplicidad. En este artculo, voy a tratar de mostrar por qu, examinando tanto
la naturaleza del problema del software y las propiedades de las balas propuestas.
El escepticismo no es pesimismo, sin embargo. Aunque no vemos avances sorprendentes - y,
de hecho, creo que tal como incnsistent con la naturaleza del software - muchas innovaciones
alentadoras estn en marcha. A, el esfuerzo constante disciplinado para desarrollar, difundir y
explotar estas innovaciones realmente debera producir una mejora de un orden de
magnitud. No hay camino real, pero hay un camino.
El primer paso hacia el tratamiento de la enfermedad fue la sustitucin de las teoras del
demonio y humores teoras de la teora de los grmenes. Esa misma etapa, el comienzo de la
esperanza, en s mismo corriendo todas las esperanzas de soluciones mgicas. Se dijo a los
trabajadores que se avance paso a paso, con gran esfuerzo, y que un persistente, incesante
atencin tendra que ser pagado a un disclipline de limpieza. Lo mismo sucede con la
ingeniera de software hoy en da.

Tiene que ser difcil? - Dificultades Esenciales

No slo no hay balas de plata ahora a la vista, la propia naturaleza del software hace que sea
poco probable que haya alguna - no hay inventos que harn de la productividad del software, la
fiabilidad y la sencillez lo que la electrnica, transistores, y la integracin a gran escala hicieron
por hardware del equipo. No podemos esperar que lleguemos a ver las ganancias de doble
cada dos aos.
En primer lugar, hay que observar que la anomala no es que el progreso del software es muy
lento, pero que el progreso material informtico es tan rpido.Ninguna otra tecnologa ya la
civilizacin comenz ha visto seis rdenes de magnitud en la ganancia de rendimiento-precio
en 30 aos. En ningn otro tipo de tecnologa se puede optar por tomar la ganancia, ya sea en
un mejor desempeo o en la reduccin de costos. Estos flujo de ganancias a partir de la
transformacin de la fabricacin de un ordenador en una industria de ensamblaje de la industria
de procesos.
En segundo lugar, para ver qu grado de avance se puede esperar en la tecnologa de
software, vamos a examinar las dificultades de esa tecnologa. Despus de Aristteles, los

divido en esencia, las dificultades inherentes a la naturaleza del software y los accidentes, las
dificultades que hoy asisten a la produccin, pero no son inherentes.
La esencia de una entidad de software es una construccin de los conceptos entrelazados: los
conjuntos de datos, las relaciones entre los elementos de datos, algoritmos, y las invocaciones
de funciones. Esta esencia se resumen en que tal construccin conceptual es el mismo en
muchas representaciones diferentes. Sin embargo, es altamente preciso y rico en detalles.
Creo que la parte ms difcil de la construccin de software para ser la especificacin, diseo y
ensayo de este constructo conceptual, no es el trabajo de representar y probar la fidelidad de la
representacin.
Todava cometemos errores de sintaxis, sin duda, pero son demasiadas complicaciones en
comparacin con los errores conceptuales en la mayora de los sistemas. Si esto es cierto, la
construccin de software siempre va a ser difcil. No es de por s hay una frmula mgica.
Vamos a considerar las propiedades inherentes de esta esencia irreducible de los sistemas de
software moderno: la complejidad, la conformidad, la mutabilidad y la invisibilidad.
Complejidad
Entidades de software son ms complejos por su tamao que quizs cualquier otra
construccin humana, porque no hay dos piezas iguales (al menos por encima del nivel de los
estados). Si es as, hacemos las dos partes similares en una subrutina - abierto o cerrado. En
este sentido, los sistemas de software difieren profundamente de los ordenadores, edificios o
automviles, donde abundan los elementos repetidos.
Computadoras digitales son de forma ms compleja de lo que la mayora de cosas que las
personas construyen: Tienen gran nmero de estados. Esto hace concebir, describir y probar
con fuerza. Los sistemas de software tienen rdenes de magnitud ms estados que las
computadoras hacen.
Del mismo modo, una ampliacin de una entidad de software no es meramente la repeticin del
mismo elemento en tamaos ms grandes, que es necesariamente un aumento en el nmero
de diferentes elementos. En la mayora de los casos, los elementos interactan unos con otros
de alguna manera no lineal, y la complejidad del conjunto aumenta mucho ms que
linealmente.
La complejidad de software es una propiedad esencial, no una accidentales. Por lo tanto, la
descripcin de una entidad software que abstrae la complejidad a menudo abstraer su
esencia. Durante tres siglos, las matemticas y las ciencias fsicas hicieron grandes avances en
la construccin de modelos simplificados de fenmenos complejos, las propiedades de los
modelos derivados, y la verificacin de las propiedades mediante experimentos. Este
paradigma funcion porque las complejidades ignorados en los modelos no eran las
propiedades esenciales de los fenmenos. No funciona cuando la complejidad es la esencia.
Muchos de los problemas clsicos de desarrollo de productos de software se derivan de esta
complejidad esencial y sus no lineales aumenta con el tamao. De la complejidad viene de la
dificultad de comunicacin entre los miembros del equipo, lo que conduce a defectos del
producto, los sobrecostos, retrasos en el programa. De la complejidad viene la dificultad de
enumerar, mucho menos comprensin, todos los estados posibles del programa, y de que
vienen de la falta de fiabilidad. A partir de la complejidad de la funcin viene la dificultad de la
invocacin de la funcin, lo que hace que los programas sean difciles de usar. De la
complejidad de la estructura viene la dificultad de extender los programas a las nuevas
funciones sin crear efectos secundarios. De la complejidad de la estructura vienen los estados
unvisualized que constituyen trampas de seguridad.

No slo los problemas tcnicos, pero los problemas de gestin, as vienen de la

complejidad. Hace panorama duro, impidiendo as la integridad conceptual. Esto hace que sea
difcil de encontrar y controlar todos los cabos sueltos. Se crea la tremenda lerarning y
comprensin carga que hace que la rotacin de personal de un desastre.
Conformidad
La gente de software no son los nicos que enfrenta la complejidad. Fsica tratar con objetos
tremendamente complejos, incluso a nivel de partculas "fundamentales". El trabajo fsico, sin
embargo, en una fe firme de que hay principios unificadores que se encuentran, ya sea en los
quarks o en las teoras unificadas de campo. Einstein sostuvo que no se debe simplificar las
explicaciones de la naturaleza, porque Dios no es caprichoso o arbitrario.
Sin esta fe consuela el ingeniero de software. Gran parte de la complejidad que tiene que
dominar es la complejidad arbitraria, forzada y sin ton ni son por las muchas instituciones
humanas y sistemas para que sus interfaces deben ajustarse. Estos difieren de interfaz para la
interfaz, y de vez en cuando, no por necesidad, pero slo porque fueron diseados por
diferentes personas, en lugar de por Dios.
En muchos casos, el software debe conformarse, porque es la ms reciente llegada a la
escena. En otros, se debe cumplir, ya que se percibe como el ms adaptable. Pero en todos los
casos, tanto la complejidad proviene de conformacin a otras interfaces; esta complejidad no
se puede simplificar a cabo por un rediseo del software por s solo.
Variabilidad
La entidad de software es constantemente objeto de presiones para el cambio. Por supuesto,
por lo que estn construyendo, los coches, los ordenadores. Pero las cosas estn
manufacturados con poca frecuencia cambian despus de la fabricacin, sino que son
reemplazados por modelos ms tarde, o cambios esenciales se incorporan a las copias en
serie de nmeros posteriores del mismo diseo bsico. Call-Back para automviles son muy
poco frecuentes, cambios en el campo de los ordenadores un poco menos. Ambos son mucho
menos frecuentes que las modificaciones de software alineado.
En parte, este modo porque el software de un sistema encarna su funcin, y la funcin es la
parte que ms se siente las presiones del cambio. En parte se debe a que el software se puede
cambiar ms fcilmente - es pura materia pensamiento, infinitamente maleable. Edificios de
hecho se cambian, pero los altos costos de cambio, entendida por todos, sirven para
amortiguar los caprichos de los que cambiaban.
Todo el software con xito se cambia. Dos procesos son en el trabajo. En primer lugar, tal como
se encuentra un producto de software para ser til, la gente intenta en nuevos casos en el
borde o ms all del dominio original. Las presiones para la funcin ampliada vienen
principalmente de los usuarios que les gusta la funcin bsica e inventar nuevos usos para ella.
En segundo lugar, el software de xito sobrevive ms all de la vida normal del vehculo,
equipo para el que est escrito primero. Si no nuevas computadoras, entonces al menos discos
nuevos, nuevas pantallas, impresoras nuevas vienen a lo largo, y el software debe acomodarse
a sus nuevos vehculos de ocasin.
En definitiva, el producto de software est integrado en una matriz cultural de aplicaciones, los
usuarios, las leyes, y los vehculos de la mquina. Todos ellos cambian continuamente, y sus
cambios obligan inexorablemente cambios en el producto de software.
Invisibilidad
El software es invisible y unvisualizable. Abstracciones geomtricas son herramientas
poderosas. La planta de un edificio de ayuda tanto arquitecto y el cliente evalan espacios,

flujos de trfico, vistas. Las contradicciones y omisiones se vuelven obvias. Dibujos a escala de
las partes mecnicas y modelos de figuras de palo de molculas, aunque abstracciones, tienen
el mismo propsito. Una realidad geomtrica es capturado en una abstraccin geomtrica.
La realidad de software no est inherentemente incrustado en el espacio. Por lo tanto, no tiene
representacin geomtrica preparados en la forma en que la tierra tiene mapas, fichas sillicon
tienen diagramas, las computadoras tienen esquemas de conectividad. Tan pronto como
tratamos de estructura de software grfico, nos encontramos con que se constituya no slo
una, sino varias grficas, dirigida generales superpuestas una sobre otra. Los varios grficos
pueden representar el flujo de control, el flujo de datos, los patrones de dependencia,
secuencia Tiem, las relaciones de espacio de nombres. Estos grficos son por lo general ni
siquiera plana, mucho menos jerrquica. En efecto, una de las maneras de establecer el control
conceptual sobre dicha estructura es hacer cumplir de corte hasta que enlace uno o ms de los
grficos se convierte jerrquica [1].
A pesar de los avances en la restriccin y la simplificacin de las estructuras de software,
siguen siendo intrnsecamente unvisualizable, y por lo tanto no permiten a la mente para utilizar
algunos de sus ms poderosas herramientas conceptuales.Esta falta no slo impide el proceso
de diseo dentro de un mismo sentir, que dificulta gravemente la comunicacin entre las
mentes.

Los avances anteriores resuelven dificultades accidentales

Si examinamos los tres pasos en el desarrollo de software de tecnologa que han sido ms
fructfera en el pasado, descubrimos que cada atacaron una gran dificultad diferente en la
creacin de software, pero que esas dificultades han sido accidental, no esencial,
dificultades. Tambin podemos ver los lmites naturales a la extrapolacin de cada uno de esos
ataques.
Lenguajes de alto nivel
Sin duda, el ms poderoso golpe de la productividad del software, confiabilidad y simplicidad ha
sido la progresiva utilizacin de lenguajes de alto nivel para la programacin. La mayora de los
observadores de crdito que el desarrollo de al menos un factor de cinco en la productividad, y
con aumentos concomitantes en la fiabilidad, simplicidad y comprensibilidad.
Qu quiere lograr un lenguaje de alto nivel? Se libera un programa de gran parte de su
complejidad accidental. Un programa abstracto formado por construcciones conceptuales:
operaciones, tipos de datos, las secuencias y la comunicacin. El programa de la mquina
concreta se refiere a los bits, los registros, las condiciones, las ramas, los canales, los discos, y
tal. En la medida en que el lenguaje de alto nivel representa las construcciones que uno quiere
en el programa abstracto y evita todos los inferiores, que elimina todo un nivel de complejidad
que no era inherente en el programa en absoluto.
Lo ms que un lenguaje de alto nivel puede hacer es presentar todas las construcciones que se
representa el programador en el programa abtract. Sin duda, el nivel de nuestra manera de
pensar acerca de las estructuras de datos, tipos de datos y operaciones va en constante
aumento, pero a un ritmo cada vez menor. Y el desarrollo del lenguaje se acerca ms y ms a
la sofisticacin de los usuarios.
Por otra parte, en algn momento de la elaboracin de un lenguaje de alto nivel crea una carga
de herramientas maestra que aumenta, no disminuye, la tarea intelectual de los usuarios que
rara vez utiliza las construcciones esotricas.
Tiempo compartido

Tiempo compartido trajo una mejora importante en la productividad de los programadores y de

la calidad de sus productos, aunque no tan grande como el interpuesto por lenguajes de alto
nivel.
Tiempo compartido ataca una dificultad muy diferente. Tiempo compartido conserva
inmediatez, y por lo tanto permite a uno mantener una visin de la complejidad. El lento
turaround de programacin por lotes significa que uno se olvida de invevitably las minucias, si
no el mismo empuje, de lo que se pensaba cuando se detuvo la programacin y la llama de la
elaboracin y ejecucin. Esta interrupcin es costosa en tiempo, pues hay que refrescar la
memoria. El efecto ms grave y puede ser la decadencia de la comprensin de todo lo que est
pasando en un sistema complejo.
Respuesta lenta, como la complejidad de lenguaje de mquina, es un accidente y no una
dificultad esencial del proceso de software. Los lmites de la contribucin potencial de tiempo
compartido se derivan directamente. El efecto principal de tiempo compartido es acortar el
tiempo de respuesta del sistema. Como este tiempo de respuesta va a cero, en algn momento
se pasa el umbral de perceptibilidad humana, alrededor de 100 milisegundos. Ms all de este
umbral, no hay beneficios son de esperar.
Estados Programacin Entornos
Unix y Interlisp, los primeros entornos de programacin integrados para entrar en uso
generalizado, parecen tener una mayor productividad por factores integrales.Por qu?
Atacan las dificultades accidentales que resultan del uso de los programas individuales juntas ,
proporcionando bibliotecas integradas, formatos de archivos unificados y tuberas y
filtros. Como resultado, las estructuras conceptuales que, en principio, siempre se poda llamar,
alimentar, y el uso de los otros puede hacer fcilmente, as que de hecho en la prctica.
Este avance a su vez estimula el desarrollo de toolbenches enteros, puesto que cada nueva
herramienta podra aplicarse a todos los programas que utilizan los formatos estndar.
Debido a estos xitos, el medio ambiente son objeto de gran parte de la investigacin de
ingeniera de software de hoy en da. Nos fijamos en su promesa y limitaciones en la siguiente
seccin.

Las esperanzas de la Plata

Ahora vamos a considerar los avances tcnicos que ms a menudo se adelantan como
posibles soluciones mgicas. Qu problemas se dirigen - los problemas de la esencia o las
dificultades accidentales restantes? Ofrecen avances revolucionarios, o los incrementales?
Ada y otros avances lenguaje de alto nivel
Uno de los ms recientes acontecimientos promocionado es Ada, un lenguaje de propsito
general de alto nivel de la dcada de 1980. Ada no slo refleja las mejoras evolutivas en los
conceptos del lenguaje, pero en realidad incluye caractersticas para fomentar el diseo
moderno y la modularizacin. Tal vez la filosofa Ada es ms de un anticipo que el lenguaje
Ada, ya que es la filosofa de la modularizacin, de los tipos abstractos de datos, de
estructuracin jerrquica. Ada es ms rica, un resultado natural del proceso por el cual los
requisitos fueron puestos sobre su diseo. Eso no es fatal, para vocabularios de trabajo
agrupada pueden resolver el problema de aprendizaje, y los avances de hardware nos dar las
MIPS econmicos para pagar los costos de compilacin. Promover la estructuracin de los
sistemas de software es de hecho un muy buen uso de la mayor MIPS nuestro dinero va a
comprar. Los sistemas operativos, fuertemente denunciadas en 1960 por su memoria y los
costes del ciclo, han demostrado ser una excelente forma en la que utilizar algunos de los
MIPS y bytes de memoria ms barato de la ltima oleada de hardware.

Sin embargo, Ada no resultar ser la bala de plata que mata al monstruo de la productividad del
software. Es, despus de todo, slo un lenguaje de alto nivel, y la mayor rentabilidad de estas
lenguas lleg a la primera transicin - la transicin a partir de la complejidad accidental de la
mquina en el estado ms abstracto de soluciones paso a paso. Una vez que los accidentes se
han eliminado, los restantes sern menores, y la recompensa de su retiro que seguramente
ser menos.
Mi prediccin es que dentro de una dcada, cuando se evaluar la eficacia de Ada, se ve que
han hecho una diferencia sustancial, pero no por ninguna caracterstica del lenguaje en
particular, ni tampoco a causa de todos ellos juntos. Tampoco sern los nuevos entornos Ada
llegar a ser la causa de las mejoras. La mayor contribucin de Ada ser que el cambio a que
los programadores de formacin ocasionados en las tcnicas de software de diseo moderno.
Programacin orientada a objetos
Muchos estudiosos de la materia tienen ms esperanza para la programacin orientada a
objetos que para otros caprichos tcnicos del da [2]. Yo estoy en medio de ellos. Marcos
Sherman de notas Dartmouth en CSnet News que uno debe tener cuidado de distinguir dos
ideas separadas que van con ese nombre:tipos abstractos de datos y tipos jerrquicos . El
concepto de tipo abstracto de datos es el de un tipo de objeto debe ser definido por un nombre,
un conjunto de valores propios, y un conjunto de operaciones propias en lugar de por su
estructura de almacenamiento que debe ser ocultado. Ejemplos de ello son los paquetes Ada
(con tipos particulares) y los mdulos de Modula.
Tipos jerrquicas, como las clases de Simula-67, le permiten a uno para definir las interfaces
generales que pueden ser an ms refinada, proporcionando tipos subordinados. Los dos
conceptos son ortogonales - uno puede tener jerarquas sin esconder y ocultar sin
jerarquas. Ambos conceptos representan avances reales en el arte de la construccin de
software.
Cada quita todava otra dificultad accidental del proceso, que permite al diseador para
expresar la esencia del diseo sin tener que expresar grandes cantidades de material sintctica
que no aaden ningn contenido de informacin. Para ambos tipos abstractos y tipos
jerrquicos, el resultado es para eliminar una especie de orden superior de dificultad accidental
y permitir que un espression de orden superior de diseo.
Sin embargo, como se puede hacer nada ms que para eliminar todas las dificultades
accidentales de la expresin del diseo. La complejidad del diseo en s mismo es esencial, y
este tipo de ataques hacer ningn cambio en lo que. Un aumento de un orden de magnitud se
puede hacer mediante la programacin orientada a objetos nicamente si la maleza tipo de
especificacin innecesaria todava en nuestro lenguaje de programacin es en s misma nueve
dcimas partes de las tareas realizadas en el diseo de un producto de programa. Lo dudo.
Inteligencia artificial
Muchas personas esperan avances en inteligencia artificial para proporcionar el avance
revolucionario que le dar ganancias de un orden de magnitud en la productividad y la calidad
del software [3]. No lo hago. Para ver por qu, debemos analizar qu se entiende por
"inteligencia artificial".
DL Parnas ha aclarado el caos terminolgico [4]:
Dos definiciones muy diferentes de AI son de uso comn hoy en da. AI-1: El uso de las
computadoras para resolver problemas que antes slo podan ser resueltos mediante
la aplicacin de la inteligencia humana. AI-2: El uso de un conjunto especfico de
tcnicas de programacin que se conoce como heurstica o programacin basada en
reglas. En este enfoque, los expertos humanos son estudiados para determinar qu
heursticas o reglas generales que utilizan en la solucin de problemas ... El programa

est diseado para resolver un problema en la forma en que los seres humanos
parecen resolverlo.
La primera definicin tiene un significado deslizante ... Algo que puede ajustarse a la
definicin de la IA-1 hoy, pero, una vez que vea cmo funciona el programa y entender
el problema, no vamos a pensar en l como AI ms ... Lamentablemente no puedo
identificar un conjunto de tecnologas que es nico en este campo ... La mayor parte
del trabajo es un problema especfico y se requiere una abstraccin o la creatividad
para ver cmo transferirlo.
Estoy completamente de acuerdo con esta crtica. Las tcnicas utilizadas para el
reconocimiento de voz parecen tener poco en comn con los utilizados para el reconocimiento
de imgenes, y ambos son diferentes de los utilizados en los sistemas expertos. Tengo un
tiempo difcil ver cmo el reconocimiento de imgenes, por ejemplo, har que una diferencia
apreciable en la prctica de programacin. El mismo problema es el caso de reconocimiento de
voz. Lo difcil acerca de la construccin de software es decidir lo que se quiere decir, no lo
dice.No ayuda a la expresin puede dar ms que ganancias marginales.
Tecnologa de sistemas expertos, AI-2, se merece una seccin propia.
Sistemas Expertos
La parte ms avanzada de la inteligencia artificial, y la ms ampliamente aplicada, es la
tecnologa para la construccin de sistemas expertos. Muchos cientficos de software estn
trabajando duro en la aplicacin de esta tecnologa en el entorno de software de capacidad
[3,5]. Cul es el concepto, y cules son las perspectivas?
Un sistema experto es un programa que contiene un motor de inferencia generalizada y una
base de reglas, toma los datos y supuestos, explora las consecuencias derivables de la base
de reglas, ofrece conclusiones y recomendaciones, y ofrece para explicar sus resultados por
volver sobre sus motivos para el usuario . El motor de inferencia tpicamente puede tratar con
datos y reglas difusas o probabilstico, adems de la lgica puramente determinista.
Estos sistemas ofrecen algunas ventajas claras sobre los algoritmos programados diseados
para llegar a las mismas soluciones a los mismos problemas:

Tecnologa de Inferencia-motor se desarrolla de una manera independiente de la

aplicacin, y luego se aplica a muchos usos. Uno puede justificar tanto esfuerzo en los
motores de inferencia. En efecto, que la tecnologa est muy avanzada.

Las partes variables de los materiales de aplicacin peculiares estn codificados en la

base de reglas de una manera uniforme, y se proporcionan herramientas para el
desarrollo, el cambio, prueba y documentacin de la base de reglas. Esta regulariza
gran parte de la complejidad de la aplicacin en s.

El poder de este tipo de sistemas no proviene de mecanismos de inferencia siempre lujosos,

sino de bases cada vez ms ricos conocimientos que reflejan el mundo real ms precisa. Creo
que el avance ms importante que ofrece esta tecnologa es la separacin de la complejidad de
la aplicacin desde el propio programa.
Cmo puede esta tecnologa puede aplicar a la tarea de ingeniera de software?En muchos
sentidos: Estos sistemas pueden sugerir reglas de interfaz, asesorar sobre estrategias de
ensayo, recordar las frecuencias de tipo insecto, y ofrecen consejos de optimizacin.

Considere la posibilidad de un asesor prueba imaginaria, por ejemplo. En su forma ms

rudimentaria, el sistema experto de diagnstico es como lista de control de piloto, simplemente
enumerando sugerencias en cuanto a las posibles causas de dificultades. A medida que ms y
ms la estructura del sistema se materializa en la base de reglas, y como la base de reglas
lleva ms sofisticada en cuenta los sntomas de problemas reportados, el asesor de prueba se
vuelve ms y ms en particular en las unas hiptesis que genera y las pruebas que
recomienda. Tal un sistema experto puede apartarse ms radicalmente de los convencionales
en que su base de reglas probablemente debera ser jerrquicamente modularizado de la
misma manera el producto de software correspondiente es, por lo que a medida que el
producto es modificado de forma modular, la regla de diagnstico puede ser modificada
modularmente, as .
El trabajo necesario para generar las reglas de diagnstico es un trabajo que tendra que ser
hecho de todos modos en la generacin del conjunto de casos de prueba para los mdulos y
para el sistema. Si esto se hace de manera general adecuado, tanto con una estructura
uniforme de las normas y buena motor de inferencia disponibles, que en realidad puede reducir
la mano de obra total de la generacin de traer-hasta casos de prueba, y ayudar as con el
mantenimiento de toda la vida y de pruebas de modificacin. De la misma manera, se puede
postular otros asesores, probablemente muchos y probablemente sencilla, para las otras partes
de la tarea de software-construccin.
Muchas dificultades se interponen en el camino de la pronta realizacin de tiles asesores
expertos del sistema para el desarrollador del programa. Una parte crucial de nuestro escenario
imaginario es el desarrollo de formas fciles de obtener a partir de las especificaciones del
programa-estructura para la generacin automtica o semiautomtica de reglas de
diagnstico. An ms difcil e importante es la doble tarea de adquisicin de conocimientos:
bsqueda de expertos de anlisis articulados, uno mismo que saben por qu hacen las cosas,
y el desarrollo de tcnicas eficientes para la extraccin de lo que saben y de destilacin en
bases de reglas. La condicin esencial para la construccin de un sistema experto es tener un
experto.
La ms poderosa contribucin de los sistemas expertos que seguramente ser poner al servicio
del programador sin experiencia la experiencia y la sabidura acumulada de los mejores
programadores. Esto no es una pequea contribucin.La brecha entre las mejores prcticas de
ingeniera de software y la prctica media es muy amplia - tal vez mayor que en cualquier otra
disciplina de la ingeniera. Una herramienta que difunde buenas prcticas sera importante.
Programacin "Automatic"
Durante casi 40 aos, la gente ha estado esperando y escribiendo sobre "programacin
automtica", o la generacin de un programa para resolver un problema de una declaracin de
las especificaciones del problema. Algunos hoy escribir como si esperan que esta tecnologa
para proporcionar la siguiente avance [5].
Parnas [4] implica que el trmino se utiliza para el glamour, no por contenido semntico,
afirmando:
En resumen, la programacin automtica ha sido siempre un eufemismo para la
programacin con un lenguaje de alto nivel que se dispone actualmente para el
programador.
Sostiene, en esencia, que en la mayora de los casos, es el mtodo de solucin, no del
problema, cuya especificacin tiene que ser determinado.
Uno puede encontrar excepciones. La tcnica de construccin de los generadores es muy
potente, y se utiliza de forma rutinaria en una gran ventaja en los programas de
seleccin. Algunos sistemas para la integracin de las ecuaciones diferenciales tambin han

permitido especificacin directa del problema, y los sistemas han evaluado los parmetros,
elegido a partir de una biblioteca de mtodos de solucin, y los programas generados.
Estas aplicaciones tienen propiedades muy favorables:

Los problemas se caracterizan fcilmente por relativamente pocos parmetros.

Hay muchos mtodos conocidos de solucin para proporcionar una biblioteca de

alternativas.

Un amplio anlisis ha dado lugar a normas explcitas para la seleccin de tcnicas de

solucin de problemas, los parmetros dados.

Es difcil ver cmo estas tcnicas se generalizan al resto del mundo del sistema de software
comn, donde los casos con tales propiedades ordenadas son la excepcin. Es difcil de
imaginar cmo podra ocurrir este gran avance en la generalizacin.
Programacin Grfica
Un tema favorito de tesis doctorales en ingeniera de software es grfico o visual, programacin
- la aplicacin de los grficos de computadora para el diseo de software [6,7]. A veces, la
promesa que por este enfoque se postula con una analoga con el diseo de chips VLSI, en el
que los grficos por ordenador juegan un papel tan fructfera. A veces, el terico que justifica el
enfoque al considerar diagramas de flujo como el medio de programas de diseo ideal y
proporcionando instalaciones poderosas para la construccin de ellos.
Nada siquiera convincente, mucho menos emocionante, pero ha surgido de tales
esfuerzos. Estoy persuadido de que nada lo har.
En primer lugar, como he argumentado en otra parte [8], el diagrama de flujo es una muy mala
abstraccin de la estructura del software. De hecho, se ve mejor como Burks, von Neumann, y
el intento de Goldstine para proporcionar un lenguaje de control de alto nivel que necesita
desesperadamente para su equipo propuesto. En el, varias pginas, forma de conexin en caja
lamentable que el organigrama actual se ha elaborado, se ha demostrado ser intil como una
herramienta de diseo - programadores dibujar diagramas de flujo despus, no antes, escribir
los programas que describen.
En segundo lugar, las pantallas de hoy en da son demasiado pequeas, en pxeles, para
mostrar tanto el alcance como la resolucin de cualquier diagrama detallado grave software. La
denominada "metfora de escritorio" de estacin de trabajo de hoy es ms bien una metfora
"avin-asiento". Cualquier persona que ha barajado una vuelta completa de los documentos
mientras se est sentado entre dos pasajeros corpulentos reconocer la diferencia - se puede
ver slo unas pocas cosas a la vez. El verdadero escritorio proporciona panorama general y un
acceso aleatorio a una veintena de pginas. Por otra parte, cuando se ajusta la creatividad son
fuertes, ms de un programador o un escritor se ha conocido a abandonar el escritorio para el
ms amplio piso. La tecnologa de hardware tendr que avanzar de forma sustancial antes de
que el alcance de nuestros mbitos es suficiente para la tarea de software-diseo.
Ms fundamentalmente, como he sealado anteriormente, el software es muy difcil de
visualizar. Si un flujo de control de diagramas, variable alcance de anidacin, variable de
referencias cruzadas, flujo de datos, estructuras de datos jerrquicos, o lo que sea, se siente

slo una dimensin del elefante software intrincadamente entrelazada. Si se superpone todos
los diagramas generados por los muchos puntos de vista relevantes, es difcil extraer cualquier
visin global. La analoga VLSI es fundamentalmente engaoso - un diseo de chip es una
descripcin de dos dimensiones en capas cuya geometra refleja su realizacin en el espacio
de 3 dimensiones. Un sistema de software no lo es.
Programa de Verificacin
Gran parte del esfuerzo en la programacin moderna entra en prueba y reparacin de
errores. Existe tal vez una bala de plata que se encuentran al eliminar los errores en la fuente,
en la fase de diseo del sistema? Puede la productividad y la fiabilidad del producto ser
radicalmente mejorada siguiendo el profundamente diferente estrategia de probar diseos
correctos antes de que el inmenso esfuerzo se vierte en la implementacin y prueba de ellos?
No creo que vamos a encontrar la magia de la productividad aqu. Programa de verificacin es
un concepto muy poderoso, y que ser muy importante para tal cosa como la seguridad
ncleos del sistema operativo. La tecnologa no promete, sin embargo, para ahorrar mano de
obra. Las verificaciones son mucho trabajo que se han verificado siempre slo unos pocos
programas importantes.
Programa de verificacin no significa programas de prueba de errores. No hay magia aqu,
tampoco. Pruebas matemticas tambin pueden estar defectuosos.As que el control puede
reducir la carga de la programacin de pruebas, no puede eliminarlo.
Ms en serio, incluso la verificacin programa perfecto slo puede demostrar que el programa
cumple con su especificacin. La parte ms difcil de la tarea de software est llegando a una
especificacin completa y consistente, y gran parte de la esencia de la construccin de un
programa, de hecho, la depuracin de la especificacin.
Entornos y herramientas
Cunto se puede esperar ms de ganancia de las investigaciones de la explosin en mejores
entornos de programacin? De una reaccin instintiva es que los problemas de gran
rentabilidad - sistemas de archivos jerrquicos, formatos de archivo uniformes para hacer
posibles interfaces de programa de uniformes y herramientas generalizadas - fueron el primer
ataque, y han sido resueltos. Editores inteligentes especficos del idioma son avances an no
se utiliza ampliamente en la prctica, pero la mayora de ellos prometen es la ausencia de
errores sintcticos y errores semnticos simples.
Tal vez el mayor beneficio an no se ha dado cuenta de entornos de programacin es el uso de
sistemas de bases de datos integradas para realizar un seguimiento de la gran cantidad de
detalles que hay que recordar con precisin por el programador individual y se mantienen en
curso para un grupo de colaboradores en un solo sistema.
Sin duda, este trabajo vale la pena, y seguramente va a dar frutos en la productividad y la
fiabilidad. Pero, por su propia naturaleza, el regreso a partir de ahora debe ser marginal.
Estaciones de Trabajo
Qu ganancias son de esperar para la tcnica de software desde cierta y rpido aumento de
la capacidad de potencia y la memoria de la estacin de trabajo individual? Bueno, cuntos
MIPS se puede utilizar provechosamente? La composicin y edicin de programas y
documentos es totalmente compatible con velocidades de hoy en da. Compilar poda soportar
un impulso, sino un factor de 10 en la velocidad de la mquina, sin duda, dejar pensar a tiempo
la actividad dominante en el da del programador. De hecho, parece ser ahora.
Workstation ms poderosa que sin duda bienvenida. Mejoras mgicas de ellos no pueden
esperar.

Los ataques prometedores en la esencia conceptual

A pesar de que no avance tcnico se compromete a dar la clase de resultados mgicos que
nos son tan familiares en el rea de hardware, no es tanto una gran cantidad de buen trabajo
pasando ahora, y la promesa de equilibrio, si el progreso espectacular.
Todos los ataques tecnolgicos de los accidentes del proceso del software estn
fundamentalmente limitados por la ecuacin de la productividad:

Si, como creo, los componentes conceptuales de la tarea que estn tomando la mayor parte del
tiempo, entonces ninguna cantidad de actividad de los componentes de tareas que no son ms
que la expresin de los conceptos puede dar grandes ganancias de productividad.
Por lo tanto, debemos tener en cuenta los ataques que se ocupan de la esencia del problema
de software, la formulacin de estas estructuras conceptuales complejas.Afortunadamente,
algunos de estos ataques son muy prometedores.
Compre frente Construir
La solucin ms radical posible fro construir software no es construir en absoluto.
Cada da esto se vuelve ms fcil, ya que cada vez ms proveedores ofrecen ms y mejores
productos de software para una vertiginosa variedad de aplicaciones.Mientras nosotros, los
ingenieros de software han trabajado en la metodologa de produccin, la revolucin de las
computadoras personales ha creado no uno, sino muchos, los mercados masivos de
software. Cada quiosco lleva revistas mensuales, segn tipo de mquina, publicidad y revisar
decenas de productos a un precio de unos pocos dlares a unos pocos cientos de
dlares. Fuentes ms especializadas ofrecen productos muy potentes para la estacin de
trabajo y en otros mercados de Unix. Incluso las herramientas y entornos de software se
pueden comprar fuera de la plataforma. He propuesto en otro lugar un mercado para los
mdulos individuales [9].
Cualquier producto es ms barato comprar que construir de nuevo. Incluso a un costo de cien
mil dlares, una pieza de software comprado cuesta slo alrededor tanto como un programador
aos. Y ofrecer es inmediato! Inmediata, al menos, para los productos que realmente existen,
productos cuyos desarrollador puede consultar los productos a un usuario feliz. Por otra parte,
estos productos tienden a ser mucho mejor documentado y mantenido un poco mejor que el
software de cosecha propia.
El desarrollo del mercado de masas es, creo, la ms profunda tendencia a largo plazo en la
ingeniera de software. El costo del software siempre ha sido el coste de desarrollo, no cuesta
replicacin. Compartir ese costo, incluso entre algunos usuarios corta radicalmente el costo por
usuario. Otra forma de verlo es que el uso de n copias de un sistema de software multiplica
efectivamente la productividad de sus desarrolladores por n . Eso es una mejora de la
productividad de la disciplina y de la nacin.
La cuestin clave, por supuesto, es de aplicacin. Puedo utilizar un paquete off-the-shelf
disponible para realizar mi tarea? Algo sorprendente ha sucedido aqu.Durante los aos 1950 y
1960, estudio tras estudio muestra que el usuario no utilice paquetes off-the-shelf de nmina,
control de inventarios, cuentas por cobrar, etc. Los requisitos eran demasiado especializados,
la variacin caso por caso demasiado alto. Durante la dcada de 1980, nos encontramos con
este tipo de paquetes en alta demanda y uso generalizado. Qu ha cambiado?

No los paquetes, de verdad. Ellos pueden ser algo ms generalizado y algo ms personalizable
que en otro tiempo, pero no mucho. No las aplicaciones, ya sea. En todo caso, las necesidades
de las empresas y cientficos de hoy en da son ms diversos y complicados que los de hace
20 aos.
El gran cambio ha sido en el ratio de eficiencia del hardware / software. En 1960, el comprador
de una mquina de dos millones de dlares senta que l poda pagar 250.000 dlares ms
para un programa de nmina personalizada, que se desliz con facilidad un sin interrupciones
en el entorno social hostil ordenador. Hoy en da, el comprador de una mquina de oficina $
50,000 no puede permitirse concebir un programa de nmina personalizada, por lo que se
adapta el procedimiento de la nmina de los paquetes disponibles. Las computadoras son
ahora tan comn, si no es sin embargo tan querida, que las adaptaciones se aceptan como
algo natural.
Hay excepciones dramticas a mi argumento de que la generalizacin de los paquetes de
software ha cambiado poco en los ltimos aos: las hojas de clculo electrnicas y sistemas de
bases de datos simples. Estas herramientas de gran alcance, tan evidente en retrospectiva ya
la vez tan tarde en aparecer, se prestan a miles de usos, algunos de ellos muy poco
ortodoxo. Artculos e incluso libros ahora abundan en la manera de abordar las tareas
inesperadas con la hoja de clculo. Un gran nmero de aplicaciones que anteriormente se han
escrito los programas personalizados en Cobol o generador de informes del programa son
ahora rutinariamente hacen con estas herramientas.
Muchos usuarios ahora tienen sus propios ordenadores en da tras da en diversas aplicaciones
sin tener que escribir un programa. De hecho, muchos de estos usuarios no pueden escribir
nuevos programas para sus mquinas, sin embargo, son expertos en la resolucin de nuevos
problemas con ellos.
Creo que la estrategia de software de productividad ms poderosa para muchas
organizaciones hoy en da es equipar a los trabajadores intelectuales ordenador ingenuos que
estn en la lnea de fuego con las computadoras personales y la buena escritura generalizada,
dibujos, archivos y hojas de clculo y luego soltarlos.La misma estrategia, llevada a cabo con
los paquetes de matemticas y estadsticas y algunas capacidades de programacin simples,
tambin trabajar para cientos de cientficos de laboratorio.
Requisitos, Rapid Prototyping Refinamiento y
La parte ms difcil de la construccin de un nico sistema de software es decidir exactamente
qu construir. Ninguna otra parte del trabajo conceptual es tan difcil como la que se establecen
los requisitos tcnicos detallados, incluyendo todas las interfaces con las personas, a las
mquinas, as como a otros sistemas de software. Ninguna otra parte de la obra por lo paraliza
el sistema resultante si se hace mal. Ninguna otra parte es ms difcil de corregir ms adelante.
Por lo tanto, la funcin ms importante que el constructor de software realiza para el cliente es
la extraccin y refinamiento de los requisitos del producto iterativo.Pues la verdad es que el
cliente no sabe lo que quiere. El cliente generalmente no sabe qu preguntas deben ser
contestadas, y tiene casi nunca, aunque el problema con el detalle necesario para la
especificacin. Incluso la respuesta simple - "Hacer que el nuevo sistema funcione software
como nuestro antiguo sistema de procesamiento de informacin manual" - es, de hecho,
demasiado simple. Uno nunca quiere exactamente eso. Sistemas de software complejos son,
por otra parte, las cosas que actan, que se mueven, que funcionan. La dinmica de la accin
es difcil de imaginar. As que en la planificacin de cualquier actividad de software-diseo, es
necesario para permitir una amplia iteracin entre el cliente y el diseador como parte de la
definicin del sistema.
Me gustara ir un paso ms all y afirmar que es realmente imposible para un cliente, incluso
trabajando con un ingeniero de software, para especificar completamente, precisa y
correctamente los requisitos exactos de un producto de software moderno antes de probar
algunas versiones del producto.

Por lo tanto, uno de los ms prometedores de los actuales esfuerzos tecnolgicos, y uno que
ataca a la esencia, no los accidentes, del problema de software, es el desarrollo de mtodos y
herramientas para la creacin rpida de prototipos de sistemas como la creacin de un
prototipo es parte de la especificacin iterativo de requisitos.
Un sistema de software prototipo es uno que simula las interfaces importantes y realiza las
principales funciones del sistema de destino, aunque no necesariamente estar limitado por la
misma velocidad de hardware, tamao o limitaciones de costo.Los prototipos suelen realizar las
tareas de la lnea principal de la aplicacin, pero no tratan de manejar las tareas excepcionales,
responder correctamente a las entradas no vlidas, o abortar limpiamente. El propsito del
prototipo es de hacer realidad la estructura conceptual especificado, de modo que el cliente
puede probar que para la consistencia y facilidad de uso.
Gran parte del proceso de adquisicin de software de hoy en da se basa en la suposicin de
que se puede especificar un sistema satisfactorio de antemano, obtener ofertas para su
construccin, lo han construido, e instalarlo. Creo que esta suposicin es un error fundamental,
y que muchos programas de adquisicin de los problemas surgen de la falacia. Por lo tanto, no
pueden ser fijados sin la revisin fundamental - revisin que proporciona para el desarrollo y
especificacin de prototipos y productos iterativo.
Desarrollo Incremental - Crecer, no construyen, Software
Todava recuerdo la sacudida que sent en 1958 cuando por primera vez o a un amigo hablar
de la construccin de un programa, en lugar de escribir una. En un instante, ampli toda mi
visin del proceso de software. El cambio de metfora era poderoso y preciso. Hoy
entendemos cmo al igual que otros procesos de construccin, la construccin de software es,
y libremente usar otros elementos de la metfora, como especificaciones , montaje de
componentes y andamios .
La metfora de la construccin ha dejado de ser til. Es el momento de cambiar de nuevo. Si,
como creo, las estructuras conceptuales que construimos hoy son demasiado complejos para
ser especificado con precisin de antemano, y demasiado complejos para ser construido sin
errores, entonces tenemos que adoptar un enfoque radical diferente.
Volvamos a la naturaleza y complejidad estudio de los seres vivos, en lugar de las obras de
muerte del hombre. Aqu nos encontramos con construcciones cuyas complejidades
emocionarnos con asombro. El cerebro es el nico intrincada all de la cartografa, poderosos
ms all de la imitacin, rico en diversidad, la auto-proteccin y auto-renovacin. El secreto es
que ha crecido, no se construye.
Y as debe ser con nuestros sistemas de software. Harlan Mills hace algunos aos propusieron
que cualquier sistema de software debe ser cultivado por desarrollo incremental [10]. Es decir,
el sistema primero debe ser obligado a correr, incluso si no hace nada til, excepto llame el
conjunto adecuado de subprogramas ficticias.Luego, poco a poco, debe concretarse, con los
subprogramas a su vez, se estn desarrollando en acciones o llamadas a los talones vacos en
el nivel inferior.
He visto los resultados ms dramticos desde que comenz a instar a esta tcnica en los
constructores del proyecto en mi clase de Laboratorio de Ingeniera de Software. Nada en la
ltima dcada ha cambiado radicalmente mi propia prctica, o su eficacia. El enfoque requiere
el diseo de arriba hacia abajo, ya que es un crecimiento de arriba hacia abajo del
software. Permite una fcil dar marcha atrs.Se presta a los primeros prototipos. Cada funcin
de agregado y la nueva disposicin de los datos o circunstancias ms complejas crece
orgnicamente a partir de lo que ya est ah.
Los efectos de nimo son sorprendentes. Saltos de entusiasmo cuando hay un sistema
runnign, incluso simple. Los esfuerzos de re-doblar cuando la primera imagen de un nuevo
sistema de software de grficos en la pantalla, incluso si es slo un rectngulo. Uno siempre

tiene, en cada etapa del proceso, un sistema de trabajo. Me parece que los equipos
pueden crecer las entidades ms complejas en cuatro meses lo que pueden construir .
Tha mismos beneficios que se pueden realizar en los grandes proyectos como en mis
pequeos [11].
Grandes diseadores
La cuestin central en la forma de mejorar los centros de arte de software, como siempre, en
las personas.
Podemos conseguir buenos diseos, siguiendo las buenas prcticas en lugar de los
pobres. Buenas prcticas diseos se pueden ensear. Los programadores se encuentran entre
la parte ms inteligente de la poblacin, para que puedan aprender las buenas prcticas. Por lo
tanto, un impulso importante en los Estados Unidos es promulgar buenas prcticas
moderna. Nuevos planes de estudio, la nueva literatura, nuevas organizaciones, como el
Instituto de Ingeniera de Software, todos han llegado a ser con el fin de elevar el nivel de
nuestra prctica de mala a buena. Esto es totalmente adecuada.
Sin embargo, no creo que podamos dar el siguiente paso hacia arriba de la misma
manera. Considerando que las diferencias entre los diseos conceptuales pobres y buenos
puede estar en la solidez del mtodo de diseo, la diferencia entre los buenos diseos y
grandes diseos seguramente no lo hace. Grandes diseos provienen de grandes
diseadores. Construccin de software es un creativoproceso. Metodologa de sonido puede
potenciar y liberar la mente creativa, no puede inflamar o inspirar el esclavo.
Las diferencias no son menores - son algo as como las diferencias entre Salieri y
Mozart. Estudio tras estudio muestra que los mejores diseadores producen estructuras que
son ms rpidos, ms pequeos, ms simple, ms limpio, y producidos con menos esfuerzo
[12]. Las diferencias entre el grande y el enfoque de media son un orden de magnitud.
Un poco de retrospectiva muestra que aunque muchos sistemas de software finas, tiles han
sido diseados por los comits y construido como parte de los proyectos de varias partes, los
sistemas de software que se han emocionado los fanticos son los que son los productos de
una o unas pocas mentes diseo, grandes diseadores. Considere la posibilidad de Unix, APL,
Pascal, Modula, la interfaz de Smalltalk, incluso Fortran, y constraste con Cobol, PL / 1, Algol,
MVS/370 y MS-DOS.
Productos Interesantes

No

Unix
APL
Pascal
Modula
Smalltalk
Fortran

Cobol
PL / 1
Algol
MVS/370
MS-DOS
Tabla 1. Productos de software emocionantes vs til pero aburrida

Por lo tanto, a pesar de que apoyo firmemente los esfuerzos de transferencia de tecnologa y el
plan de estudios de desarrollo en curso, creo que el ms importante esfuerzo solo podemos
montar es desarrollar maneras de hacer crecer grandes diseadores.
Ninguna organizacin software puede ignorar este reto. Los buenos gerentes, escasos que
sean, no son ms escasos que los buenos diseadores. Grandes diseadores y grandes
gerentes son muy raros. La mayora de las organizaciones gastan considerable esfuerzo en la
bsqueda y el cultivo de las perspectivas de gestin: no conozco ninguno que pasa el mismo

esfuerzo en la bsqueda y el desarrollo de los grandes diseadores a quienes la excelencia

tcnica de los productos depender finalmente.
Cmo hacer crecer grandes diseadores? El espacio no permite una larga discusin, pero
algunas medidas son obvias:

Identificar sistemticamente los diseadores lo antes posible. La mejor muchas veces

no son los ms experimentados.

Asignar un tutor de carrera para ser responsable del desarrollo de la perspectiva, y

tener cuidado de un archivo de carrera.

Elaborar y mantener un plan de desarrollo profesional para cada propspect, incluyendo

una seleccin de programas de aprendizaje con los mejores diseadores, los episodios
de la educacin formal avanzada, y cursos cortos, todos entremezclados con las tareas
en solitario de diseo y tcnico-liderazgo.

Proporcionar oportunidades para que los diseadores de crecimiento de interactuar y

estimular el uno al otro.

Agradecimientos
Doy las gracias a Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, Robert Patrick, y, muy
especialmente, David Parnas por sus puntos de vista e ideas estimulantes, y Rebeca Bierly
para la produccin tcnica del artculo.

Referencias
1. DL Parnas, "Software de diseo para la facilidad de extensin y contraccin", IEEE
Trans. Ingeniera del Software , Vol.5 No.2, marzo 1979, pp 128-138

2. G. Booch, "Diseo Orientado a Objetos", Ingeniera de Software con Ada , 1983,

Benjamin Cummings, Menlo Park, California

3. IEEE Trans. Ingeniera de Software (nmero especial sobre la inteligencia artificial y la

ingeniera de software), J. Mostow, editor invitado., Vol. 11, N 11, noviembre 1985

4. DL Parnas, "Aspectos de Software de Sistemas de Defensa Estratgica",American

Scientist , 11 1985

5. R. Balzer, "Una perspectiva de 15 aos en el Programa Automtico", IEEE

Trans. Ingeniera de Software (nmero especial sobre la inteligencia artificial y la
ingeniera de software), J. Mostow, editor invitado., Vol.18, N 8, agosto 1985

6. Computer (nmero especial sobre programacin visual), RB Graphton y T. Ichikawa,

invitado eds., vol.18, n 8, agosto 1985

7. G. Reader, "Estudio de las tcnicas actuales de programacin

grfica",Computer (nmero especial sobre programacin visual), RB Graphton y T.
Ichikawa, invitado eds., vol.18, n 8, agosto 1985, pp 11-25

8. FP Brooks, The Mythical Man-Month , 1975, Addison-Wesley, Reading, Massachusetts,

Nueva York, Captulo 14

9. Junta de Ciencias de Defensa, Informe del Grupo de Trabajo sobre Software Militar , en
prensa

10. HD Mills, "Programacin de arriba abajo en grandes sistemas", en Tcnicas de

depuracin en sistemas grandes , R. Ruskin, ed., Prentice-Hall, Englewood Cliffs, NJ,
1971

11. BW Boehm, "Un Modelo Espiral de Desarrollo de Software y Mejora", 1985, TRW
tecnologa. informe 21-371-85, TRW, Inc., 1 plaza, Redondo Beach, CA 90278

12. H. Sackman, WJ Erickson y EE Grant, "exploratorios Estudios Experimentales

Comparacin online y offline Rendimiento de programacin",MCCA , Vol. 11, No. 1,
enero 1968, pp 3-11