documento

1. No hay bala de plata:
Esencia y accidentes de Ingeniería de Software
Frederick P. Brooks, Jr.
Fashioning construcciones conceptuales complejas es la esencia ;accidentales tareas
aparecen en la representación 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 más de
los hombres lobo, ya que transforman inesperadamente de lo familiar en horrores. Para estos,
se busca balas de plata que puede mágicamente sentar a descansar.
El proyecto de software familiar, al menos como se ve por el administrador no técnico, 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 rápidamente como los costos de hardware hacen.
Pero, al mirar tp el horizonte de una década, por lo tanto, no vemos ninguna bala de plata. No
hay desarrollo único, ya sea en la tecnología o en la técnica 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 artículo, 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 están en marcha. A, el esfuerzo constante disciplinado para desarrollar, difundir y
explotar estas innovaciones realmente debería 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 sustitución de las teorías del
demonio y humores teorías de la teoría de los gérmenes. Esa misma etapa, el comienzo de la
esperanza, en sí mismo corriendo todas las esperanzas de soluciones mágicas. Se dijo a los
trabajadores que se avance paso a paso, con gran esfuerzo, y que un persistente, incesante
atención tendría que ser pagado a un disclipline de limpieza. Lo mismo sucede con la
ingeniería de software hoy en día.
¿Tiene que ser difícil? - Dificultades Esenciales
No sólo 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 harán de la productividad del software, la
fiabilidad y la sencillez lo que la electrónica, transistores, y la integración a gran escala hicieron
por hardware del equipo. No podemos esperar que lleguemos a ver las ganancias de doble
cada dos años.
En primer lugar, hay que observar que la anomalía no es que el progreso del software es muy
lento, pero que el progreso material informático es tan rápido.Ninguna otra tecnología ya la
civilización comenzó ha visto seis órdenes de magnitud en la ganancia de rendimiento-precio
en 30 años. En ningún otro tipo de tecnología se puede optar por tomar la ganancia, ya sea en
un mejor desempeño o en la reducción de costos. Estos flujo de ganancias a partir de la
transformación de la fabricación 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 tecnología de
software, vamos a examinar las dificultades de esa tecnología. Después de Aristóteles, los

2. divido en esencia, las dificultades inherentes a la naturaleza del software y los accidentes, las
dificultades que hoy asisten a la producción, pero no son inherentes.
La esencia de una entidad de software es una construcción 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 construcción conceptual es el mismo en
muchas representaciones diferentes. Sin embargo, es altamente preciso y rico en detalles.
Creo que la parte más difícil de la construcción de software para ser la especificación, diseño y
ensayo de este constructo conceptual, no es el trabajo de representar y probar la fidelidad de la
representación.
Todavía cometemos errores de sintaxis, sin duda, pero son demasiadas complicaciones en
comparación con los errores conceptuales en la mayoría de los sistemas. Si esto es cierto, la
construcción de software siempre va a ser difícil. No es de por sí hay una fórmula mágica.
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 más complejos por su tamaño que quizás cualquier otra
construcción 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
automóviles, donde abundan los elementos repetidos.
Computadoras digitales son de forma más compleja de lo que la mayoría de cosas que las
personas construyen: Tienen gran número de estados. Esto hace concebir, describir y probar
con fuerza. Los sistemas de software tienen órdenes de magnitud más estados que las
computadoras hacen.
Del mismo modo, una ampliación de una entidad de software no es meramente la repetición del
mismo elemento en tamaños más grandes, que es necesariamente un aumento en el número
de diferentes elementos. En la mayoría de los casos, los elementos interactúan unos con otros
de alguna manera no lineal, y la complejidad del conjunto aumenta mucho más que
linealmente.
La complejidad de software es una propiedad esencial, no una accidentales. Por lo tanto, la
descripción de una entidad software que abstrae la complejidad a menudo abstraer su
esencia. Durante tres siglos, las matemáticas y las ciencias físicas hicieron grandes avances
en la construcción de modelos simplificados de fenómenos complejos, las propiedades de los
modelos derivados, y la verificación de las propiedades mediante experimentos. Este
paradigma funcionó porque las complejidades ignorados en los modelos no eran las
propiedades esenciales de los fenómenos. No funciona cuando la complejidad es la esencia.
Muchos de los problemas clásicos de desarrollo de productos de software se derivan de esta
complejidad esencial y sus no lineales aumenta con el tamaño. De la complejidad viene de la
dificultad de comunicación 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 comprensión, todos los estados posibles del programa, y de que
vienen de la falta de fiabilidad. A partir de la complejidad de la función viene la dificultad de la
invocación de la función, lo que hace que los programas sean difíciles 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.

3. No sólo los problemas técnicos, pero los problemas de gestión, así vienen de la
complejidad. Hace panorama duro, impidiendo así la integridad conceptual. Esto hace que sea
difícil de encontrar y controlar todos los cabos sueltos. Se crea la tremenda lerarning y
comprensión carga que hace que la rotación de personal de un desastre.
Conformidad
La gente de software no son los únicos que enfrenta la complejidad. Física tratar con objetos
tremendamente complejos, incluso a nivel de partículas "fundamentales". El trabajo físico, sin
embargo, en una fe firme de que hay principios unificadores que se encuentran, ya sea en los
quarks o en las teorías 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 sólo porque fueron diseñados por
diferentes personas, en lugar de por Dios.
En muchos casos, el software debe conformarse, porque es la más reciente llegada a la
escena. En otros, se debe cumplir, ya que se percibe como el más adaptable. Pero en todos
los casos, tanto la complejidad proviene de conformación a otras interfaces; esta complejidad
no se puede simplificar a cabo por un rediseño del software por sí solo.
Variabilidad
La entidad de software es constantemente objeto de presiones para el cambio. Por supuesto,
por lo que están construyendo, los coches, los ordenadores. Pero las cosas están
manufacturados con poca frecuencia cambian después de la fabricación, sino que son
reemplazados por modelos más tarde, o cambios esenciales se incorporan a las copias en
serie de números posteriores del mismo diseño básico. Call-Back para automóviles 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 función, y la función es la
parte que más se siente las presiones del cambio. En parte se debe a que el software se puede
cambiar más fácilmente - 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 más allá del dominio original. Las presiones para la función ampliada vienen
principalmente de los usuarios que les gusta la función básica e inventar nuevos usos para ella.
En segundo lugar, el software de éxito sobrevive más allá de la vida normal del vehículo,
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 vehículos de ocasión.
En definitiva, el producto de software está integrado en una matriz cultural de aplicaciones, los
usuarios, las leyes, y los vehículos de la máquina. Todos ellos cambian continuamente, y sus
cambios obligan inexorablemente cambios en el producto de software.
Invisibilidad
El software es invisible y unvisualizable. Abstracciones geométricas son herramientas
poderosas. La planta de un edificio de ayuda tanto arquitecto y el cliente evalúan espacios,

4. flujos de tráfico, vistas. Las contradicciones y omisiones se vuelven obvias. Dibujos a escala de
las partes mecánicas y modelos de figuras de palo de moléculas, aunque abstracciones, tienen
el mismo propósito. Una realidad geométrica es capturado en una abstracción geométrica.
La realidad de software no está inherentemente incrustado en el espacio. Por lo tanto, no tiene
representación geométrica 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 gráfico, nos encontramos con que se constituya no sólo
una, sino varias gráficas, dirigida generales superpuestas una sobre otra. Los varios gráficos
pueden representar el flujo de control, el flujo de datos, los patrones de dependencia,
secuencia Tiem, las relaciones de espacio de nombres. Estos gráficos son por lo general ni
siquiera plana, mucho menos jerárquica. En efecto, una de las maneras de establecer el control
conceptual sobre dicha estructura es hacer cumplir de corte hasta que enlace uno o más de los
gráficos se convierte jerárquica [1].
A pesar de los avances en la restricción y la simplificación de las estructuras de software,
siguen siendo intrínsecamente unvisualizable, y por lo tanto no permiten a la mente para utilizar
algunos de sus más poderosas herramientas conceptuales.Esta falta no sólo impide el proceso
de diseño dentro de un mismo sentir, que dificulta gravemente la comunicación entre las
mentes.
Los avances anteriores resuelven dificultades accidentales
Si examinamos los tres pasos en el desarrollo de software de tecnología que han sido más
fructífera en el pasado, descubrimos que cada atacaron una gran dificultad diferente en la
creación de software, pero que esas dificultades han sido accidental, no esencial,
dificultades. También podemos ver los límites naturales a la extrapolación de cada uno de esos
ataques.
Lenguajes de alto nivel
Sin duda, el más poderoso golpe de la productividad del software, confiabilidad y simplicidad ha
sido la progresiva utilización de lenguajes de alto nivel para la programación. La mayoría de los
observadores de crédito 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 comunicación. El programa de la máquina
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 más 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 más y más a
la sofisticación de los usuarios.
Por otra parte, en algún momento de la elaboración de un lenguaje de alto nivel crea una carga
de herramientas maestría que aumenta, no disminuye, la tarea intelectual de los usuarios que
rara vez utiliza las construcciones esotéricas.
Tiempo compartido

5. 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 visión de la complejidad. El lento
turaround de programación 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 programación y la llama de la
elaboración y ejecución. Esta interrupción es costosa en tiempo, pues hay que refrescar la
memoria. El efecto más grave y puede ser la decadencia de la comprensión de todo lo que está
pasando en un sistema complejo.
Respuesta lenta, como la complejidad de lenguaje de máquina, es un accidente y no una
dificultad esencial del proceso de software. Los límites de la contribución 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 algún momento
se pasa el umbral de perceptibilidad humana, alrededor de 100 milisegundos. Más allá de este
umbral, no hay beneficios son de esperar.
Estados Programación Entornos
Unix y Interlisp, los primeros entornos de programación 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 tuberías y
filtros. Como resultado, las estructuras conceptuales que, en principio, siempre se podía llamar,
alimentar, y el uso de los otros puede hacer fácilmente, así que de hecho en la práctica.
Este avance a su vez estimula el desarrollo de toolbenches enteros, puesto que cada nueva
herramienta podría aplicarse a todos los programas que utilizan los formatos estándar.
Debido a estos éxitos, el medio ambiente son objeto de gran parte de la investigación de
ingeniería de software de hoy en día. Nos fijamos en su promesa y limitaciones en la siguiente
sección.
Las esperanzas de la Plata
Ahora vamos a considerar los avances técnicos que más a menudo se adelantan como
posibles soluciones mágicas. ¿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 más recientes acontecimientos promocionado es Ada, un lenguaje de propósito
general de alto nivel de la década de 1980. Ada no sólo refleja las mejoras evolutivas en los
conceptos del lenguaje, pero en realidad incluye características para fomentar el diseño
moderno y la modularización. Tal vez la filosofía Ada es más de un anticipo que el lenguaje
Ada, ya que es la filosofía de la modularización, de los tipos abstractos de datos, de
estructuración jerárquica. Ada es más rica, un resultado natural del proceso por el cual los
requisitos fueron puestos sobre su diseño. Eso no es fatal, para vocabularios de trabajo
agrupada pueden resolver el problema de aprendizaje, y los avances de hardware nos dará las
MIPS económicos para pagar los costos de compilación. Promover la estructuración 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 más barato de la última oleada de hardware.

6. Sin embargo, Ada no resultará ser la bala de plata que mata al monstruo de la productividad
del software. Es, después de todo, sólo un lenguaje de alto nivel, y la mayor rentabilidad de
estas lenguas llegó a la primera transición - la transición a partir de la complejidad accidental
de la máquina en el estado más abstracto de soluciones paso a paso. Una vez que los
accidentes se han eliminado, los restantes serán menores, y la recompensa de su retiro que
seguramente será menos.
Mi predicción es que dentro de una década, cuando se evaluará la eficacia de Ada, se ve que
han hecho una diferencia sustancial, pero no por ninguna característica del lenguaje en
particular, ni tampoco a causa de todos ellos juntos. Tampoco serán los nuevos entornos Ada
llegar a ser la causa de las mejoras. La mayor contribución de Ada será que el cambio a que
los programadores de formación ocasionados en las técnicas de software de diseño moderno.
Programación orientada a objetos
Muchos estudiosos de la materia tienen más esperanza para la programación orientada a
objetos que para otros caprichos técnicos del día [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 jerárquicos . 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 módulos de Modula.
Tipos jerárquicas, como las clases de Simula-67, le permiten a uno para definir las interfaces
generales que pueden ser aún más refinada, proporcionando tipos subordinados. Los dos
conceptos son ortogonales - uno puede tener jerarquías sin esconder y ocultar sin
jerarquías. Ambos conceptos representan avances reales en el arte de la construcción de
software.
Cada quita todavía otra dificultad accidental del proceso, que permite al diseñador para
expresar la esencia del diseño sin tener que expresar grandes cantidades de material sintáctica
que no añaden ningún contenido de información. Para ambos tipos abstractos y tipos
jerárquicos, el resultado es para eliminar una especie de orden superior de dificultad accidental
y permitir que un espression de orden superior de diseño.
Sin embargo, como se puede hacer nada más que para eliminar todas las dificultades
accidentales de la expresión del diseño. La complejidad del diseño en sí mismo es esencial, y
este tipo de ataques hacer ningún cambio en lo que. Un aumento de un orden de magnitud se
puede hacer mediante la programación orientada a objetos únicamente si la maleza tipo de
especificación innecesaria todavía en nuestro lenguaje de programación es en sí misma nueve
décimas partes de las tareas realizadas en el diseño 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 terminológico [4]:
Dos definiciones muy diferentes de AI son de uso común hoy en día. AI-1: El uso de las
computadoras para resolver problemas que antes sólo podían ser resueltos mediante
la aplicación de la inteligencia humana. AI-2: El uso de un conjunto específico de
técnicas de programación que se conoce como heurística o programación basada en
reglas. En este enfoque, los expertos humanos son estudiados para determinar qué
heurísticas o reglas generales que utilizan en la solución de problemas ... El programa

7. está diseñado para resolver un problema en la forma en que los seres humanos
parecen resolverlo.
La primera definición tiene un significado deslizante ... Algo que puede ajustarse a la
definición de la IA-1 hoy, pero, una vez que vea cómo funciona el programa y entender
el problema, no vamos a pensar en él como AI más ... Lamentablemente no puedo
identificar un conjunto de tecnologías que es único en este campo ... La mayor parte
del trabajo es un problema específico y se requiere una abstracción o la creatividad
para ver cómo transferirlo.
Estoy completamente de acuerdo con esta crítica. Las técnicas utilizadas para el
reconocimiento de voz parecen tener poco en común con los utilizados para el reconocimiento
de imágenes, y ambos son diferentes de los utilizados en los sistemas expertos. Tengo un
tiempo difícil ver cómo el reconocimiento de imágenes, por ejemplo, hará que una diferencia
apreciable en la práctica de programación. El mismo problema es el caso de reconocimiento de
voz. Lo difícil acerca de la construcción de software es decidir lo que se quiere decir, no lo
dice.No ayuda a la expresión puede dar más que ganancias marginales.
Tecnología de sistemas expertos, AI-2, se merece una sección propia.
Sistemas Expertos
La parte más avanzada de la inteligencia artificial, y la más ampliamente aplicada, es la
tecnología para la construcción de sistemas expertos. Muchos científicos de software están
trabajando duro en la aplicación de esta tecnología en el entorno de software de capacidad
[3,5]. ¿Cuál es el concepto, y cuáles 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 típicamente puede tratar con
datos y reglas difusas o probabilístico, además de la lógica puramente determinista.
Estos sistemas ofrecen algunas ventajas claras sobre los algoritmos programados diseñados
para llegar a las mismas soluciones a los mismos problemas:
Tecnología de Inferencia-motor se desarrolla de una manera independiente de la
aplicación, y luego se aplica a muchos usos. Uno puede justificar tanto esfuerzo en los
motores de inferencia. En efecto, que la tecnología está muy avanzada.
Las partes variables de los materiales de aplicación peculiares están codificados en la
base de reglas de una manera uniforme, y se proporcionan herramientas para el
desarrollo, el cambio, prueba y documentación de la base de reglas. Esta regulariza
gran parte de la complejidad de la aplicación en sí.
El poder de este tipo de sistemas no proviene de mecanismos de inferencia siempre lujosos,
sino de bases cada vez más ricos conocimientos que reflejan el mundo real más precisa. Creo
que el avance más importante que ofrece esta tecnología es la separación de la complejidad de
la aplicación desde el propio programa.
¿Cómo puede esta tecnología puede aplicar a la tarea de ingeniería 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 optimización.

8. Considere la posibilidad de un asesor prueba imaginaria, por ejemplo. En su forma más
rudimentaria, el sistema experto de diagnóstico es como lista de control de piloto, simplemente
enumerando sugerencias en cuanto a las posibles causas de dificultades. A medida que más y
más la estructura del sistema se materializa en la base de reglas, y como la base de reglas
lleva más sofisticada en cuenta los síntomas de problemas reportados, el asesor de prueba se
vuelve más y más en particular en las unas hipótesis que genera y las pruebas que
recomienda. Tal un sistema experto puede apartarse más radicalmente de los convencionales
en que su base de reglas probablemente debería ser jerárquicamente 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 diagnóstico puede ser modificada
modularmente, así .
El trabajo necesario para generar las reglas de diagnóstico es un trabajo que tendría que ser
hecho de todos modos en la generación del conjunto de casos de prueba para los módulos 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 generación de traer-hasta casos de prueba, y ayudar así con el
mantenimiento de toda la vida y de pruebas de modificación. De la misma manera, se puede
postular otros asesores, probablemente muchos y probablemente sencilla, para las otras partes
de la tarea de software-construcción.
Muchas dificultades se interponen en el camino de la pronta realización de útiles asesores
expertos del sistema para el desarrollador del programa. Una parte crucial de nuestro
escenario imaginario es el desarrollo de formas fáciles de obtener a partir de las
especificaciones del programa-estructura para la generación automática o semiautomática de
reglas de diagnóstico. Aún más difícil e importante es la doble tarea de adquisición de
conocimientos: búsqueda de expertos de análisis articulados, uno mismo que saben por
qué hacen las cosas, y el desarrollo de técnicas eficientes para la extracción de lo que saben y
de destilación en bases de reglas. La condición esencial para la construcción de un sistema
experto es tener un experto.
La más poderosa contribución de los sistemas expertos que seguramente será poner al
servicio del programador sin experiencia la experiencia y la sabiduría acumulada de los
mejores programadores. Esto no es una pequeña contribución.La brecha entre las mejores
prácticas de ingeniería de software y la práctica media es muy amplia - tal vez mayor que en
cualquier otra disciplina de la ingeniería. Una herramienta que difunde buenas prácticas sería
importante.
Programación "Automatic"
Durante casi 40 años, la gente ha estado esperando y escribiendo sobre "programación
automática", o la generación de un programa para resolver un problema de una declaración de
las especificaciones del problema. Algunos hoy escribir como si esperan que esta tecnología
para proporcionar la siguiente avance [5].
Parnas [4] implica que el término se utiliza para el glamour, no por contenido semántico,
afirmando:
En resumen, la programación automática ha sido siempre un eufemismo para la
programación con un lenguaje de alto nivel que se dispone actualmente para el
programador.
Sostiene, en esencia, que en la mayoría de los casos, es el método de solución, no del
problema, cuya especificación tiene que ser determinado.
Uno puede encontrar excepciones. La técnica de construcción de los generadores es muy
potente, y se utiliza de forma rutinaria en una gran ventaja en los programas de
selección. Algunos sistemas para la integración de las ecuaciones diferenciales también han

9. permitido especificación directa del problema, y los sistemas han evaluado los parámetros,
elegido a partir de una biblioteca de métodos de solución, y los programas generados.
Estas aplicaciones tienen propiedades muy favorables:
Los problemas se caracterizan fácilmente por relativamente pocos parámetros.
Hay muchos métodos conocidos de solución para proporcionar una biblioteca de
alternativas.
Un amplio análisis ha dado lugar a normas explícitas para la selección de técnicas de
solución de problemas, los parámetros dados.
Es difícil ver cómo estas técnicas se generalizan al resto del mundo del sistema de software
común, donde los casos con tales propiedades ordenadas son la excepción. Es difícil de
imaginar cómo podría ocurrir este gran avance en la generalización.
Programación Gráfica
Un tema favorito de tesis doctorales en ingeniería de software es gráfico o visual, programación
- la aplicación de los gráficos de computadora para el diseño de software [6,7]. A veces, la
promesa que por este enfoque se postula con una analogía con el diseño de chips VLSI, en el
que los gráficos por ordenador juegan un papel tan fructífera. A veces, el teórico que justifica el
enfoque al considerar diagramas de flujo como el medio de programas de diseño ideal y
proporcionando instalaciones poderosas para la construcción 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
abstracción 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 páginas, forma de conexión en caja
lamentable que el organigrama actual se ha elaborado, se ha demostrado ser inútil como una
herramienta de diseño - programadores dibujar diagramas de flujo después, no antes, escribir
los programas que describen.
En segundo lugar, las pantallas de hoy en día son demasiado pequeñas, en píxeles, para
mostrar tanto el alcance como la resolución de cualquier diagrama detallado grave software. La
denominada "metáfora de escritorio" de estación de trabajo de hoy es más bien una metáfora
"avión-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 sólo unas pocas cosas a la vez. El verdadero escritorio proporciona panorama general y un
acceso aleatorio a una veintena de páginas. Por otra parte, cuando se ajusta la creatividad son
fuertes, más de un programador o un escritor se ha conocido a abandonar el escritorio para el
más amplio piso. La tecnología de hardware tendrá que avanzar de forma sustancial antes de
que el alcance de nuestros ámbitos es suficiente para la tarea de software-diseño.
Más fundamentalmente, como he señalado anteriormente, el software es muy difícil de
visualizar. Si un flujo de control de diagramas, variable alcance de anidación, variable de
referencias cruzadas, flujo de datos, estructuras de datos jerárquicos, o lo que sea, se siente

10. sólo una dimensión del elefante software intrincadamente entrelazada. Si se superpone todos
los diagramas generados por los muchos puntos de vista relevantes, es difícil extraer cualquier
visión global. La analogía VLSI es fundamentalmente engañoso - un diseño de chip es una
descripción de dos dimensiones en capas cuya geometría refleja su realización en el espacio
de 3 dimensiones. Un sistema de software no lo es.
Programa de Verificación
Gran parte del esfuerzo en la programación moderna entra en prueba y reparación de
errores. ¿Existe tal vez una bala de plata que se encuentran al eliminar los errores en la fuente,
en la fase de diseño del sistema? ¿Puede la productividad y la fiabilidad del producto será
radicalmente mejorada siguiendo el profundamente diferente estrategia de probar diseños
correctos antes de que el inmenso esfuerzo se vierte en la implementación y prueba de ellos?
No creo que vamos a encontrar la magia de la productividad aquí. Programa de verificación es
un concepto muy poderoso, y que será muy importante para tal cosa como la seguridad
núcleos del sistema operativo. La tecnología no promete, sin embargo, para ahorrar mano de
obra. Las verificaciones son mucho trabajo que se han verificado siempre sólo unos pocos
programas importantes.
Programa de verificación no significa programas de prueba de errores. No hay magia aquí,
tampoco. Pruebas matemáticas también pueden estar defectuosos.Así que el control puede
reducir la carga de la programación de pruebas, no puede eliminarlo.
Más en serio, incluso la verificación programa perfecto sólo puede demostrar que el programa
cumple con su especificación. La parte más difícil de la tarea de software está llegando a una
especificación completa y consistente, y gran parte de la esencia de la construcción de un
programa, de hecho, la depuración de la especificación.
Entornos y herramientas
¿Cuánto se puede esperar más de ganancia de las investigaciones de la explosión en mejores
entornos de programación? De una reacción instintiva es que los problemas de gran
rentabilidad - sistemas de archivos jerárquicos, 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 específicos del idioma son avances aún no
se utiliza ampliamente en la práctica, pero la mayoría de ellos prometen es la ausencia de
errores sintácticos y errores semánticos simples.
Tal vez el mayor beneficio aún no se ha dado cuenta de entornos de programación 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 precisión 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 técnica de software desde cierta y rápido aumento de
la capacidad de potencia y la memoria de la estación de trabajo individual? Bueno, ¿cuántos
MIPS se puede utilizar provechosamente? La composición y edición de programas y
documentos es totalmente compatible con velocidades de hoy en día. Compilar podía soportar
un impulso, sino un factor de 10 en la velocidad de la máquina, sin duda, dejar pensar a tiempo
la actividad dominante en el día del programador. De hecho, parece ser ahora.
Workstation más poderosa que sin duda bienvenida. Mejoras mágicas de ellos no pueden
esperar.

11. Los ataques prometedores en la esencia conceptual
A pesar de que no avance técnico se compromete a dar la clase de resultados mágicos 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 tecnológicos de los accidentes del proceso del software están
fundamentalmente limitados por la ecuación de la productividad:
Si, como creo, los componentes conceptuales de la tarea que están tomando la mayor parte
del tiempo, entonces ninguna cantidad de actividad de los componentes de tareas que no son
más que la expresión 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 formulación de estas estructuras conceptuales complejas.Afortunadamente,
algunos de estos ataques son muy prometedores.
Compre frente Construir
La solución más radical posible fro construir software no es construir en absoluto.
Cada día esto se vuelve más fácil, ya que cada vez más proveedores ofrecen más y mejores
productos de software para una vertiginosa variedad de aplicaciones.Mientras nosotros, los
ingenieros de software han trabajado en la metodología de producción, la revolución de las
computadoras personales ha creado no uno, sino muchos, los mercados masivos de
software. Cada quiosco lleva revistas mensuales, según tipo de máquina, publicidad y revisar
decenas de productos a un precio de unos pocos dólares a unos pocos cientos de
dólares. Fuentes más especializadas ofrecen productos muy potentes para la estación 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
módulos individuales [9].
Cualquier producto es más barato comprar que construir de nuevo. Incluso a un costo de cien
mil dólares, una pieza de software comprado cuesta sólo alrededor tanto como un programador
años. 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 más profunda tendencia a largo plazo en la
ingeniería de software. El costo del software siempre ha sido el coste de desarrollo, no cuesta
replicación. 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 nación.
La cuestión clave, por supuesto, es de aplicación. ¿Puedo utilizar un paquete off-the-shelf
disponible para realizar mi tarea? Algo sorprendente ha sucedido aquí.Durante los años 1950 y
1960, estudio tras estudio muestra que el usuario no utilice paquetes off-the-shelf de nómina,
control de inventarios, cuentas por cobrar, etc. Los requisitos eran demasiado especializados,
la variación caso por caso demasiado alto. Durante la década de 1980, nos encontramos con
este tipo de paquetes en alta demanda y uso generalizado. ¿Qué ha cambiado?

12. No los paquetes, de verdad. Ellos pueden ser algo más generalizado y algo más personalizable
que en otro tiempo, pero no mucho. No las aplicaciones, ya sea. En todo caso, las necesidades
de las empresas y científicos de hoy en día son más diversos y complicados que los de hace
20 años.
El gran cambio ha sido en el ratio de eficiencia del hardware / software. En 1960, el comprador
de una máquina de dos millones de dólares sentía que él podía pagar 250.000 dólares más
para un programa de nómina personalizada, que se deslizó con facilidad un sin interrupciones
en el entorno social hostil ordenador. Hoy en día, el comprador de una máquina de oficina $
50,000 no puede permitirse concebir un programa de nómina personalizada, por lo que se
adapta el procedimiento de la nómina de los paquetes disponibles. Las computadoras son
ahora tan común, si no es sin embargo tan querida, que las adaptaciones se aceptan como
algo natural.
Hay excepciones dramáticas a mi argumento de que la generalización de los paquetes de
software ha cambiado poco en los últimos años: las hojas de cálculo electrónicas 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. Artículos e incluso libros ahora abundan en la manera de abordar las tareas
inesperadas con la hoja de cálculo. Un gran número 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 día tras día en diversas
aplicaciones sin tener que escribir un programa. De hecho, muchos de estos usuarios no
pueden escribir nuevos programas para sus máquinas, sin embargo, son expertos en la
resolución de nuevos problemas con ellos.
Creo que la estrategia de software de productividad más poderosa para muchas
organizaciones hoy en día es equipar a los trabajadores intelectuales ordenador ingenuos que
están en la línea de fuego con las computadoras personales y la buena escritura generalizada,
dibujos, archivos y hojas de cálculo y luego soltarlos.La misma estrategia, llevada a cabo con
los paquetes de matemáticas y estadísticas y algunas capacidades de programación simples,
también trabajará para cientos de científicos de laboratorio.
Requisitos, Rapid Prototyping Refinamiento y
La parte más difícil de la construcción de un único sistema de software es decidir exactamente
qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como la que se establecen
los requisitos técnicos detallados, incluyendo todas las interfaces con las personas, a las
máquinas, 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 más difícil de corregir más adelante.
Por lo tanto, la función más importante que el constructor de software realiza para el cliente es
la extracción 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
especificación. Incluso la respuesta simple - "Hacer que el nuevo sistema funcione software
como nuestro antiguo sistema de procesamiento de información manual" - es, de hecho,
demasiado simple. Uno nunca quiere exactamente eso. Sistemas de software complejos son,
por otra parte, las cosas que actúan, que se mueven, que funcionan. La dinámica de la acción
es difícil de imaginar. Así que en la planificación de cualquier actividad de software-diseño, es
necesario para permitir una amplia iteración entre el cliente y el diseñador como parte de la
definición del sistema.
Me gustaría ir un paso más 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.

13. Por lo tanto, uno de los más prometedores de los actuales esfuerzos tecnológicos, y uno que
ataca a la esencia, no los accidentes, del problema de software, es el desarrollo de métodos y
herramientas para la creación rápida de prototipos de sistemas como la creación de un
prototipo es parte de la especificación 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, tamaño o limitaciones de costo.Los prototipos suelen realizar las
tareas de la línea principal de la aplicación, pero no tratan de manejar las tareas excepcionales,
responder correctamente a las entradas no válidas, o abortar limpiamente. El propósito 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 adquisición de software de hoy en día se basa en la suposición de
que se puede especificar un sistema satisfactorio de antemano, obtener ofertas para su
construcción, lo han construido, e instalarlo. Creo que esta suposición es un error fundamental,
y que muchos programas de adquisición de los problemas surgen de la falacia. Por lo tanto, no
pueden ser fijados sin la revisión fundamental - revisión que proporciona para el desarrollo y
especificación de prototipos y productos iterativo.
Desarrollo Incremental - Crecer, no construyen, Software
Todavía recuerdo la sacudida que sentí en 1958 cuando por primera vez oí a un amigo hablar
de la construcción de un programa, en lugar de escribir una. En un instante, amplió toda mi
visión del proceso de software. El cambio de metáfora era poderoso y preciso. Hoy
entendemos cómo al igual que otros procesos de construcción, la construcción de software es,
y libremente usar otros elementos de la metáfora, como especificaciones , montaje de
componentes y andamios .
La metáfora de la construcción 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 precisión 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 cartografía, poderosos
más allá de la imitación, rico en diversidad, la auto-protección y auto-renovación. El secreto es
que ha crecido, no se construye.
Y así debe ser con nuestros sistemas de software. Harlan Mills hace algunos años 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 están desarrollando en acciones o llamadas a los talones vacíos en
el nivel inferior.
He visto los resultados más dramáticos desde que comenzó a instar a esta técnica en los
constructores del proyecto en mi clase de Laboratorio de Ingeniería de Software. Nada en la
última década ha cambiado radicalmente mi propia práctica, o su eficacia. El enfoque requiere
el diseño de arriba hacia abajo, ya que es un crecimiento de arriba hacia abajo del
software. Permite una fácil dar marcha atrás.Se presta a los primeros prototipos. Cada función
de agregado y la nueva disposición de los datos o circunstancias más complejas crece
orgánicamente 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 gráficos en la pantalla, incluso si es sólo un rectángulo. Uno siempre

14. tiene, en cada etapa del proceso, un sistema de trabajo. Me parece que los equipos
pueden crecer las entidades más complejas en cuatro meses lo que pueden construir .
Tha mismos beneficios que se pueden realizar en los grandes proyectos como en mis
pequeños [11].
Grandes diseñadores
La cuestión central en la forma de mejorar los centros de arte de software, como siempre, en
las personas.
Podemos conseguir buenos diseños, siguiendo las buenas prácticas en lugar de los
pobres. Buenas prácticas diseños se pueden enseñar. Los programadores se encuentran entre
la parte más inteligente de la población, para que puedan aprender las buenas prácticas. Por lo
tanto, un impulso importante en los Estados Unidos es promulgar buenas prácticas
moderna. Nuevos planes de estudio, la nueva literatura, nuevas organizaciones, como el
Instituto de Ingeniería de Software, todos han llegado a ser con el fin de elevar el nivel de
nuestra práctica 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 diseños conceptuales pobres y buenos
puede estar en la solidez del método de diseño, la diferencia entre los buenos diseños y
grandes diseños seguramente no lo hace. Grandes diseños provienen de grandes
diseñadores. Construcción de software es un creativoproceso. Metodología 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 diseñadores producen estructuras que
son más rápidos, más pequeños, más simple, más 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 diseñados por los comités y construido como parte de los proyectos de varias partes, los
sistemas de software que se han emocionado los fanáticos son los que son los productos de
una o unas pocas mentes diseño, grandes diseñadores. 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
Sí 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 tecnología y el
plan de estudios de desarrollo en curso, creo que el más importante esfuerzo solo podemos
montar es desarrollar maneras de hacer crecer grandes diseñadores.
Ninguna organización software puede ignorar este reto. Los buenos gerentes, escasos que
sean, no son más escasos que los buenos diseñadores. Grandes diseñadores y grandes
gerentes son muy raros. La mayoría de las organizaciones gastan considerable esfuerzo en la
búsqueda y el cultivo de las perspectivas de gestión: no conozco ninguno que pasa el mismo

15. esfuerzo en la búsqueda y el desarrollo de los grandes diseñadores a quienes la excelencia
técnica de los productos dependerá finalmente.
¿Cómo hacer crecer grandes diseñadores? El espacio no permite una larga discusión, pero
algunas medidas son obvias:
Identificar sistemáticamente los diseñadores lo antes posible. La mejor muchas veces
no son los más 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 selección de programas de aprendizaje con los mejores diseñadores, los episodios
de la educación formal avanzada, y cursos cortos, todos entremezclados con las tareas
en solitario de diseño y técnico-liderazgo.
Proporcionar oportunidades para que los diseñadores 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 producción técnica del artículo.
Referencias
1. DL Parnas, "Software de diseño para la facilidad de extensión y contracción", IEEE
Trans. Ingeniería del Software , Vol.5 No.2, marzo 1979, pp 128-138
2. G. Booch, "Diseño Orientado a Objetos", Ingeniería de Software con Ada , 1983,
Benjamin Cummings, Menlo Park, California
3. IEEE Trans. Ingeniería de Software (número especial sobre la inteligencia artificial y la
ingeniería de software), J. Mostow, editor invitado., Vol. 11, N º 11, noviembre 1985
4. DL Parnas, "Aspectos de Software de Sistemas de Defensa Estratégica",American
Scientist , 11 1985

16. 5. R. Balzer, "Una perspectiva de 15 años en el Programa Automático", IEEE
Trans. Ingeniería de Software (número especial sobre la inteligencia artificial y la
ingeniería de software), J. Mostow, editor invitado., Vol.18, N º 8, agosto 1985
6. Computer (número especial sobre programación visual), RB Graphton y T. Ichikawa,
invitado eds., vol.18, n º 8, agosto 1985
7. G. Reader, "Estudio de las técnicas actuales de programación
gráfica",Computer (número especial sobre programación 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, Capítulo 14
9. Junta de Ciencias de Defensa, Informe del Grupo de Trabajo sobre Software Militar , en
prensa
10. HD Mills, "Programación de arriba abajo en grandes sistemas", en Técnicas de
depuración 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
tecnología. informe 21-371-85, TRW, Inc., 1 plaza, Redondo Beach, CA 90278
12. H. Sackman, WJ Erickson y EE Grant, "exploratorios Estudios Experimentales
Comparación online y offline Rendimiento de programación",MCCA , Vol. 11, No. 1,
enero 1968, pp 3-11