No Silver Bullet

-Esencia Y accidentes en Ingeniera del Software

Frederick P. Brooks, Jr.

Universidad de Carolina del Norte en Chapel Hill

No existe un nico desarrollo, ya sea en la tecnologa o la gestin tcnica, que por s

mismo promete an un orden de magnitud mejora dentro de una dcada en la
productividad, en la fiabilidad, en la simplicidad.

Abstracto 1
Toda la construccin de software implica tareas esenciales, la confeccin del complejo
estructuras conceptuales que componen la entidad de software abstracto y tareas
accidentales, la representacin de estas entidades abstractas en lenguajes de programacin
y la asignacin de stas en los idiomas de la mquina dentro de las limitaciones de espacio
y velocidad. La mayor parte de la gran pasado ganancias de productividad de software han
venido de la eliminacin de las barreras artificiales que tienen realizado las tareas
accidentales excesivamente duro, tales como las limitaciones de hardware graves,
lenguajes de programacin difciles, la falta de tiempo de mquina. Cunto de lo que el
software los ingenieros ahora hacen es todava dedican a lo accidental, en contraposicin a
lo esencial? A menos que es ms de 9/10 de todo el esfuerzo, la reduccin de todas las
actividades accidentales a tiempo cero no lo har dar un orden de magnitud de mejora.
Por lo tanto, parece que ha llegado el momento de abordar las partes esenciales de la tarea
de software, los relacionados con la configuracin de las estructuras conceptuales
abstractas de gran complejidad. Sugiero:

Explotar el mercado de masas para evitar la construccin de lo que se puede

comprar.
Uso de creacin rpida de prototipos como parte de una iteracin planificada en el
establecimiento de software requisitos.
Creciendo software de forma orgnica, aadiendo cada vez ms la funcin de los
sistemas, ya que son ejecutar, que se utiliza, y probado.
La identificacin y el desarrollo de los grandes diseadores conceptuales de la
nueva generacin.

Introduccin
De todos los monstruos que pueblan las pesadillas de nuestro folklore, ninguno aterrorice
ms hombres lobo, porque transforman inesperadamente de lo familiar en horrores. Por
stos, buscamos balas de plata que les puede poner mgicamente para descansar.

1 Reproducido de: Frederick P. Brooks, The Mythical Man-Month, edicin aniversario con
4 nueva captulos, Addison-Wesley (1995), reimpreso en s de las Actas de la IFIP Dcimo
Mundial Computing Conferencia, H.-J. Kugler, ed., Elsevier Science BV, Amsterdam, NL
(1986) pp. 1069-1076

El proyecto de software familiar tiene algo de este personaje (al menos como se ve por el
gerente no tcnica), por lo general inocente y sencilla, pero capaz de convertirse en un
monstruo de las planificaciones perdidas, presupuestos soplado y productos
defectuosos. As escuchamos desesperada llora por una bala de plata, algo para que los
costos de software caen tan rpidamente como equipo los costos de hardware hacen.
Pero, al mirar al horizonte de una dcada, por lo tanto, no vemos ninguna bala de plata. No
hay el desarrollo individual, ya sea en tecnologa o tcnica de gestin, lo que por s mismo
promete incluso un orden de magnitud de mejora de la productividad, en la fiabilidad, en
simplicidad. En este captulo vamos a tratar de ver por qu, pero el examen tanto de la
naturaleza de la problema de software y las propiedades de las balas proponen.
El escepticismo no es pesimismo, sin embargo. Aunque no vemos avances sorprendentes,
y, de hecho, creer tal es incompatible con la naturaleza del software, muchas innovaciones
alentadoras estn en marcha. Una disciplina, esfuerzo constante para desarrollar,
propagar, y explotarlos de hecho debe producir una mejora 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. Ese mismo paso, el comienzo de
la esperanza, en s mismo discontinua todas las esperanzas de soluciones mgicas. Se dijo a
los trabajadores se hara el progreso paso a paso, con gran esfuerzo, y que una, la atencin
incesante persistente tendra que pagar a un disciplina de la limpieza. Lo mismo sucede
con la ingeniera de software hoy.
Tiene que ser duro? - Dificultades Esenciales
No slo no hay balas de plata ahora a la vista, la naturaleza misma de software hace que
sea poco probable que no habr ningn-no hay inventos que harn para la productividad
de software, fiabilidad y simplicidad lo que la electrnica, transistores, y la integracin a
gran escala hicieron por hardware de la computadora. No podemos esperar que nunca para
ver ganancias al doble cada dos aos.

En primer lugar, hay que observar que la anomala no es que el progreso software es tan
lento, pero que el progreso material informtico es tan rpido. Ninguna otra tecnologa
desde el inicio de la civilizacin ha visto seis rdenes de magnitud aumento de preciorendimiento en 30 aos. En ninguna otra tecnologa puede un solo optar por tomar la
ganancia, ya sea en un mejor rendimiento o reducido costes. Estas ganancias se derivan de
la transformacin de la fabricacin de un ordenador industria de ensamblaje en una
industria de proceso.
En segundo lugar, para ver qu tasa de progreso que podemos esperar en la tecnologa de
software, nos dej examinar sus dificultades. Siguiendo a Aristteles, yo las divido en
esencia las dificultades inherente a la naturaleza de los programas y accidentes, aquellas
dificultades que hoy asisten su produccin, pero que no son inherentes.
Los accidentes que discuten en la siguiente seccin. En primer lugar vamos a considerar la
esencia.
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 es abstracto, en que el constructo conceptual es el
mismo bajo diferentes representaciones. 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 pruebas de este constructo conceptual, no el trabajo de representarlo y probar la
fidelidad de la representacin. Todava cometemos errores de sintaxis, sin duda; pero son
fuzz en comparacin con los errores conceptuales en la mayora de los sistemas

Si esto es cierto, la creacin de software siempre ser difcil. No es inherentemente no plata

bala.
Vamos a considerar las propiedades inherentes de esta esencia irreductible de software
moderno sistemas: la complejidad, la conformidad, la mutabilidad, y la invisibilidad.
Complejidad. Entidades de software son ms complejos para su tamao que quizs
cualquier otra construccin humana, porque no hay dos piezas iguales (al menos por
encima del nivel de los estados). Si son, hacemos las dos partes similares en una sola, una
subrutina, abierta o cerrada. En esto sistemas de software respecto difieren
profundamente de los ordenadores, edificios o automviles, donde abundan los elementos
repetidos.
Ordenadores digitales son a su vez ms complejo que la mayora de cosas que las personas
construyen; ellos tener un gran nmero de estados. Esto hace concebir, describiendo, y
prueba de ellos difcil. Los sistemas de software tienen rdenes de magnitud ms estados
que las computadoras hacen.

Asimismo, una ampliacin de una entidad de software no es ms que una repeticin de los
mismos elementos en tamao ms grande; es necesariamente un aumento en el nmero de
diferentes elementos.
En la mayora de los casos, los elementos interactan entre s de alguna manera no lineal, y
el la complejidad de la totalidad aumenta mucho ms que linealmente.
La complejidad de software est en propiedad esencial, no un accidente. Por lo tanto
descripciones de una entidad software que abstraer su complejidad menudo abstracta de
distancia de su esencia. Matemticas y ciencias fsicas hicieron grandes avances durante
tres siglos por construir modelos simplificados de fenmenos complejos, derivando
inmuebles de las modelos, y la verificacin de estos inmuebles experimentalmente. Esto
funcion porque las complejidades ignoradas en los modelos no eran las propiedades
esenciales de los fenmenos. Ello no funciona cuando las complejidades son la esencia.
Muchos de los problemas clsicos de desarrollar productos de software derivados de esta
complejidad esencial y su no lineal aument con el tamao. De la complejidad viene la
dificultad de la comunicacin entre los miembros del equipo, lo que conduce a defectos del
producto, costo sobrecostos, retrasos en el programa. De la complejidad viene la dificultad
de enumerar, mucho menos comprensin, todos los posibles estados del programa, y desde
ese viene la falta de fiabilidad. A partir de la complejidad de las funciones viene la
dificultad de invocar aquellos funciones, lo que hace que los programas de difcil de
usar. De la complejidad de la estructura viene la dificultad de extender los programas a las
nuevas funciones sin crear efectos secundarios. Desde la complejidad de la estructura viene
el estado unvisualized que constituyen la seguridad trampillas.
No slo problemas, pero los problemas de gestin tcnica y venir del complejidad. Esta
complejidad hace panorama duro, impidiendo as la integridad conceptual.
Esto hace que sea difcil de encontrar y controlar todos los cabos sueltos. Se crea el
tremendo aprendizaje y la comprensin de carga que hace que el personal de facturacin
de un desastre.
Conformidad. La gente de software no estn solos para afrontar la complejidad. Ofertas
de Fsica con objetos tremendamente complejos, incluso a nivel de partculas
"fundamentales". Los trabajos fsico, sin embargo, en una fe firme que hay principios
unificadores que se encuentran, ya sea en quarks o en las teoras del campo
unificado. Einstein argument reiteradamente que debe haber explicaciones simplificadas
de la naturaleza, porque Dios no es caprichoso o arbitrario.
Sin tal fe consuela el ingeniero de software. Gran parte de la complejidad que debe
principal es la complejidad arbitraria, forzada sin ton ni son por el que muchos humanos
instituciones y sistemas a los que sus interfaces deben confirmar. Estos difieren de interfaz
para interactuar, y de vez en cuando, no por necesidad, sino slo porque eran diseada por
diferentes personas, en lugar de Dios.
En muchos casos, el software debe confirmar porque ha llegado ms recientemente a la
escena. En otros, debe cumplir porque se percibe como el ms adaptable. Pero en todos los
casos, tanto la complejidad proviene de conformacin a otras interfaces; esto no puede ser
simplificado por cualquier rediseo del software por s solo.

Mutabilidad. La entidad de software es constantemente objeto de presiones para el

cambio. De
Por supuesto, tambin lo son los edificios, automviles y computadoras. Pero las cosas son
fabricados con poca frecuencia cambiado despus de la fabricacin; que se sustituya por
los modelos posteriores, o cambios esenciales son incorporados en copias del nmero de
serie posteriores del mismo diseo bsico. Devoluciones de llamada de los automviles son
realmente muy poco frecuente; cambios en el campo de los ordenadores un poco menos.
Ambos son mucho menos frecuentes que las modificaciones de software fielded.
En parte esto se debe a que el software en 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 puede
ser cambiado ms fcilmente: es puro pensamiento-cosas, infinitamente
maleable. Edificios de hecho conseguir cambiado, pero los altos costos del cambio,
entendida por todos, sirven para amortiguar el caprichode los cambiadores.
Todo el software exitoso se cambia. Dos procesos estn en el trabajo. Como un software
producto se encuentra para ser til, la gente trata de l en nuevos casos en el borde de, o
ms all, la dominio original. Las presiones para la funcin ampliada venir principalmente
de los usuarios que les gusta la funcin bsica e inventar nuevos usos para ella.
En segundo lugar, el software de xito tambin sobrevive ms all de la vida normal de la
mquina vehculo para el que est escrito primero. Si no las computadoras nuevas,
entonces al menos discos nuevos, nuevo pantallas, impresoras nuevas vienen a lo largo; y
el software debe ser conformado a su nueva vehculos de ocasin.
En resumen, el producto de software est incrustado en una matriz cultural de las
aplicaciones, los usuarios, leyes, y los vehculos de la mquina. Todos ellos cambian
continuamente, y sus cambios inexorablemente fuerza de cambio en el producto de
software.
Invisibilidad. El software es invisible y unvisualizable. Abstracciones geomtricas son
herramientas de gran alcance. La planta de un edificio de ayuda tanto arquitecto y el
cliente evalan espacios, flujos de trfico, y vistas. Las contradicciones se hacen evidentes,
omisiones pueden ser atrapados. Dibujos a escala de partes mecnicas y modelos de
figuras de palo de molculas, aunque abstracciones, tienen el mismo propsito. Una
realidad geomtrica es capturado en un la abstraccin geomtrica.
La realidad de software no est incrustada inherentemente en el espacio. Por lo tanto, no
tiene ninguna listo representacin geomtrica de la manera que la tierra contiene mapas,
chips de silicio tienen diagramas, computadoras tienen esquemas de conectividad. Tan
pronto como se intenta diagramar software estructura, encontramos a no constituye una,
sino varias, en general dirigida grficos, superpuestas una sobre otra. Los varios grficos
pueden representar el flujo de control, el flujo de datos, patrones de dependencia,
secuencia de tiempo, relaciones nombre en el espacio. Estas son por lo general ni siquiera
plana, mucho menos jerrquica. De hecho, una de las formas de

establecer el control conceptual sobre dicha estructura es hacer cumplir el corte de enlace
hasta la una o ms de los grficos se convierte jerrquica.2

A pesar del progreso en la restriccin y la simplificacin de las estructuras de software, que

siendo inherentemente unvisualizable, privando as a la mente de algunos de sus ms
poderosos herramientas conceptuales. Esta falta no slo impide el proceso de diseo
dentro de un mismo sentir, que dificulta gravemente la comunicacin entre mentes.
Los avances anteriores Resuelto Dificultades accidental
Si examinamos los tres pasos en la tecnologa de software que han sido ms fructfera en el
pasado, descubrimos que cada atacaron una de las principales dificultades diferentes en la
construccin de software, pero que han sido las dificultades, no las esenciales,
accidentales. Tambin podemos ver lo natural lmites a la extrapolacin de cada uno de
esos ataques.
Los lenguajes de alto nivel. Seguramente la carrera ms poderoso para la
productividad de software, fiabilidad y simplicidad ha sido la progresiva utilizacin de
lenguajes de alto nivel para programacin. La mayora de los observadores acreditan que el
desarrollo con al menos un factor de cinco en productividad, y con ganancias
concomitantes en fiabilidad, simplicidad y comprensibilidad.
Qu quiere lograr un lenguaje de alto nivel? Libera un programa de gran parte de su
complejidad accidental. Un programa de resumen consiste en construcciones
conceptuales: operaciones, tipos de datos, secuencias, y la comunicacin. El programa de
la mquina hormign es trate con trozos, registros, condiciones, sucursales, canales,
discos, y tal. A la medida en que el lenguaje de alto nivel encarna las construcciones quera
en abstracto programa y evita todos los inferiores, se elimina todo un nivel de complejidad
que era
Nunca inherente en el programa en absoluto.
El ms un lenguaje de alto nivel puede hacer es presentar todas las construcciones del
programador imagina en el programa abstracto. Sin duda, el nivel de sofisticacin en
nuestro pensamiento sobre estructuras de datos, tipos de datos y operaciones est
aumentando de manera constante, pero aun en constante tasa decreciente. 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 se
convierte en una carga que aumenta, no disminuye, la tarea intelectual del usuario que
rara vez se utiliza lo esotrico construye.

Tiempo compartido. Observadores de crdito La mayor parte de tiempo compartido

con una mejora importante en el la productividad de programadores y en la calidad de su
producto, aunque no tan grande como la ejercitada por lenguajes de alto nivel.
Tiempo de intercambio de ataques una dificultad claramente diferente. Conservas de
tiempo compartido inmediatez, y por lo tanto nos permite mantener una visin general de
la complejidad. El lento cambio de la programacin por lotes significa que inevitablemente
nos olvidamos de los pequeos detalles, si no el muy empuje, de lo que estbamos
pensando cuando paramos programacin y llamamos para compilacin y ejecucin. Esta
interrupcin de la conciencia es costoso en tiempo, ya que debe actualizar. El efecto ms
grave puede ser la decadencia de comprensin de todo lo que est pasando en un sistema
complejo.
2Parnas, DL, "software de diseo para facilitar la extensin y contraccin," IEEE Trans. en
SE, 5, 2(Marzo, 1979), pp. 12-138

Vuelco lenta, como las complejidades de lenguaje de mquina, es un accidente y no un

dificultad esencial del proceso de software. Los lmites de la contribucin de tiempo
compartido derivar directamente. El efecto principal es reducir el tiempo de respuesta del
sistema. Como se va a cero, en algn momento se pasa el umbral de perceptibilidad
humana, alrededor de 100 milisegundos.
Ms all de eso no hay beneficios son de esperar.
Entornos de programacin unificado.
Unix y Interlisp, el primero integrado programacin entornos prximos al uso
generalizado, se perciben haber mejorado la productividad por factores integrales. Por
qu?
Ellos atacan a las dificultades accidentales de uso de programas juntos, proporcionando
bibliotecas integradas, formatos de archivo unificadas, y pilas y filtros. Como resultado,
conceptual estructuras que, en principio, siempre se podra llamar, alimentacin, y el uso
de los otros puede de hecho fcil hacerlo en la prctica.
Este avance a su vez estimul el desarrollo de toolbenches enteros, ya que cada nueva
herramienta podra aplicarse a todos los programas mediante el uso de los formatos
estndar.

Debido a estos xitos, los entornos son objeto de gran parte de software de hoy
investigacin en ingeniera. Vamos a mirar a su promesa y limitaciones en la siguiente
seccin.
Las esperanzas de la Plata
Ahora vamos a considerar los desarrollos tcnicos que ms a menudo avanzado como
potenciales balas de plata. Qu problemas se dirigen? Son los problemas de esencia, o
son restos de nuestras dificultades accidentales? Ofrecen avances revolucionarios, o los
incrementales?
Ada y otros avances del lenguaje de alto nivel.
Uno de los ms promocionado reciente desarrollos es el lenguaje de programacin Ada,
una de propsito general, lenguaje de alto nivel de la dcada de 1980. Ada de hecho no slo
refleja mejoras evolutivas en el lenguaje conceptos, pero encarna caractersticas para
fomentar el diseo moderno y la modularizacin conceptos. Tal vez la filosofa Ada es ms
de un anticipo que el lenguaje Ada, por es la filosofa de la modularizacin, de tipos de
datos abstractos, de estructuracin jerrquica.
Ada es quizs sobre-rico, el producto natural del proceso por el cual requisitos eran puesto
en su diseo. Eso no es fatal, para vocabularios de trabajo de subconjuntos pueden resolver
el aprendiendo problema, y los avances de hardware nos darn las MIPS baratas para
pagar la la compilacin de los costos. Avanzando la estructuracin de sistemas de software
es de hecho una muy buena utilizar para el aumento de MIPS nuestros dlares
comprarn. Sistemas operativos, en voz alta denunciado en el 1960 por sus costos de
memoria y de ciclo, han demostrado ser una excelente forma en la que utilizar algunos de
los MIPS y bytes de memoria baratas del pasado oleada de hardware.
Sin embargo, Ada no resultar ser la bala de plata que mata el software monstruo de la
productividad. Es, despus de todo, slo otro lenguaje de alto nivel, y el mayor pago de
tales lenguas vino de la primera transicin, por encima de lo accidental complejidades de la
mquina en el estado ms abstracto de soluciones paso a paso.
Una vez que se han eliminado los accidentes, los restantes son ms pequeos, y la
recompensa de su eliminacin seguramente ser menor.
Mi prediccin es que una dcada a partir de ahora, cuando se evala la eficacia de Ada,
ser visto que han hecho una diferencia sustancial, pero no a causa de cualquier idioma en
particular funcin, ni tampoco porque de todos ellos juntos. Tampoco lo har el nuevo Ada
entorno de llegar a ser la causa de las mejoras. La mayor contribucin de ADA sea que el
cambio a ocasion programadores de formacin en diseo de software moderno tcnicas.

Programacin orientada a objetos. Muchos estudiantes de la tcnica tienen ms

esperanza para la programacin orientada a objetos, que para cualquiera de las otras
modas tcnicas del da. 3 Yo estoy entre ellos. Marcos Sherman de Dartmouth seala que
hay que tener cuidado de distinguir de dos ideas separadas que van con ese nombre: tipos
abstractos de datos y tipos jerrquicos, tambin llamadas clases. El concepto de tipo
abstracto de datos es que el tipo de un objeto debe ser definido por un nombre, un
conjunto de valores propios, y un conjunto de operaciones apropiadas, en lugar de su
estructura de almacenamiento, que debe ser ocultado. Ejemplos de ello son los paquetes de
Ada (con privada tipos) o mdulos de Modula.
Tipos jerrquicas, como las clases de Simula-67, permiten la definicin de generales
interfaces que pueden ser refinados an ms al ofrecer tipos subordinados. Los dos
conceptos son ortogonales-puede haber jerarquas sin esconder y ocultar sin jerarquas.
Ambos conceptos representan avances reales en la tcnica de la construccin de software.
Cada elimina una dificultad ms accidental del proceso, permitiendo que el diseador para
expresar la esencia de su diseo sin tener que expresar grandes cantidades de sintctica
material que aadir ningn nuevo contenido de informacin. Para ambos tipos abstractos
y jerrquica tipos, el resultado es para eliminar una orden superior tipo de dificultad
accidental y permitir que un expresin de orden superior del diseo.
Sin embargo, estos avances pueden hacer ms que para eliminar todo lo accidental
dificultades de la expresin del diseo. La complejidad del diseo en s mismo es
esencial; y este tipo de ataques no hacen el cambio alguno en eso. Una ganancia de orden
de magnitud se puede hacer por la programacin orientada a objeto slo si la maleza
innecesaria de tipo especificacin restante hoy en nuestro lenguaje de programacin es en
s mismo responsable de nueve dcimas de trabajo involucrado 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 dar orden de magnitud ganancias en software
productividad y la calidad. 4 Yo no. Para ver por qu, debemos diseccionar lo que se
entiende por "Inteligencia artificial" y luego ver cmo se aplica.
Parnas ha aclarado el caos terminolgico:
Dos definiciones muy diferentes de AI son de uso comn en la actualidad. AI-1: El uso de
ordenadores para resolver problemas que antes slo podan ser resueltos mediante la
aplicacin humana inteligencia. AI-2: El uso de un conjunto especfico de tcnicas de
programacin sabe cmo programacin heurstica o basada en reglas. En este enfoque
expertos humanos son los estudios realizados hasta determinan lo heursticas o reglas de
oro que utilizan en la solucin de problemas. . . . El programa est diseado para
resolver un problema de la forma en que los seres humanos parecen resolverlo.

3 Booch, G., "diseo orientado a objetos", en Ingeniera de Software con Ada. Menlo Park,
Calif .: Benjamin Cummings, 1983.

4 Mostow, J., ed., Edicin Especial sobre Inteligencia Artificial e Ingeniera

del Software, IEEE Trans. en SE, 11, 11 (. 11 1985).

La primera definicin tiene un significado de deslizamiento. . . . Algo puede ajustarse a la

definicin de AI-1 hoy, pero, una vez que veamos cmo funciona el programa y entender
el problema, lo haremos no pensar en ella como la IA ms. . . . Lamentablemente no
puedo identificar un cuerpo de la tecnologa que es nico a este campo. . . . La mayor
parte del trabajo es especfico del problema, y algunos abstraccin o la creatividad es
requiere para ver cmo transferirlo. 5

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 sistemas
expertos. Tengo un tiempo difcil ver cmo la imagen reconocimiento, por ejemplo, har
ninguna diferencia apreciable en la prctica de programacin.
Lo mismo es tratar de reconocimiento de voz. La cosa difcil sobre la construccin de
software es decidir qu decir, no decirlo. Sin facilitacin de expresin puede dar ms de lo
marginal ganancias.
Tecnologa de sistemas expertos, AI-2, merece un apartado propio.
Los sistemas expertos. La parte ms avanzada de la tcnica de inteligencia artificial, y
el ms ampliamente aplicable, es la tecnologa para la construccin de sistemas
expertos. Muchos cientficos de software estn trabajando duro en la aplicacin de esta
tecnologa para el entorno de creacin de software. 6
Que es el concepto, y cules son las perspectivas?
Un sistema experto es un programa que contiene un motor de inferencia generalizada y
una reglan base, diseado para tomar los datos y supuestos y explorar las consecuencias
lgicas a travs de las inferencias derivables de la base de reglas, conclusiones rendimiento
y asesoramiento, y ofreciendo para explicar sus resultados por volver sobre su
razonamiento para el usuario. La inferencia motores normalmente pueden hacer frente a
los datos y reglas difusas o probabilsticos, adems de puramente lgica determinista.
Estos sistemas ofrecen algunas ventajas claras sobre algoritmos programados para llegar
en las mismas soluciones a los mismos problemas:

Tecnologa de motor de inferencia se desarrolla de una manera independiente de la

aplicacin, y luego aplicada a muchos usos. Uno puede justificar un esfuerzo mucho
mayor en los motores de inferencia. De hecho, de que la tecnologa est muy
avanzada.
Las piezas cambiables de los materiales de aplicacin-peculiar se codifican en la
base de reglas de una manera uniforme, se proporcionan y herramientas para el
desarrollo, el cambio, las pruebas y documentacin de la base de reglas. Este
regulariza gran parte de la complejidad de la aplicacin en s.

Edward Feigenbaum dice que el poder de este tipo de sistemas no viene de en constante
mecanismos ms elegantes de inferencia, sino desde siempre ms ricas bases de
conocimiento que reflejan el mundo real con mayor precisin. Creo que el avance ms
importante que ofrece el tecnologa es la separacin de la complejidad de la aplicacin
desde el propio programa.
Cmo se puede aplicar a la tarea de software? En muchos sentidos: Interfaz sugiriendo
normas, asesoramiento sobre estrategias de ensayo, recordando las frecuencias, pero de
tipo, oferta consejos de optimizacin, etc.

5 Parnas, DL, "aspectos de software de sistemas de defensa estratgica", Communications

of the ACM, 28, 12 (diciembre, 1985), pp. 1.326-1.335. Tambin en American
Scientist, 73, 5 (septiembre-octubre de 1985), pp. 432-440.
6 Balzer, R., "Una perspectiva de 15 aos en la programacin automtica," en Mostow,
op. cit.

Considere la posibilidad de un asesor de pruebas imaginario, por ejemplo. En su forma

ms rudimentaria, el sistema experto de diagnstico es muy como lista de verificacin de
un piloto, que ofrece fundamentalmente sugerencias en cuanto a las posibles causas de
dificultades. A medida que se desarrolla la base de reglas, la sugerencias se hacen ms
especfica, teniendo en cuenta ms sofisticado de los problemas sntomas reportados. Se
puede visualizar un asistente de depuracin que ofrece muy generalizada sugerencias al
principio, pero a medida que ms y ms la estructura del sistema est incorporado en la
base de reglas, viene ms y ms en particular en las hiptesis es genera y de las pruebas,
recomienda. Tal sistema experto puede apartarse ms radical de lo convencional en los que
su base de reglas probablemente deben ser modularizados jerrquicamente de la misma
manera el producto de software correspondiente es, por lo que a medida que el producto es
modificado de forma modular, la base de reglas de diagnstico se puede modular
modificado tambin.
El trabajo necesario para generar las reglas de diagnstico es un trabajo que tendr que
hacer de todos modos en la generacin del conjunto de casos de prueba para los mdulos y
para el sistema. Si se hace de una manera adecuada en general, con una estructura
uniforme de las normas y una buena inferencia motor disponible, en realidad puede
reducir la mano de obra total de la generacin de casos de prueba traen en marcha, as
como ayudar en el mantenimiento de toda la vida y las pruebas de modificacin. De la
misma manera, hemos puede postular otros consejeros probablemente muchos de ellos y
los probablemente simples para la otras partes de la tarea de construccin de software.
Muchas dificultades se interponen en el camino de la realizacin precoz de tiles asesores
expertos al creador del programa. Una parte crucial de nuestro escenario imaginario es el
desarrollo de fcil maneras de conseguir a la especificacin de la estructura del programa
para la automtica o semi-automtica generacin de reglas de diagnstico. An ms difcil
e importante es la doble tarea de la adquisicin de conocimientos: articular la bsqueda,
los expertos independientes de anlisis que saben por qu lo hacen las cosas; y el
desarrollo de tcnicas eficientes para la extraccin de lo que saben y destilndolo en bases
de reglas. El requisito previo 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 el mejor
software prctica de la ingeniera y de la prctica media es muy amplia, tal vez ms amplio
que en cualquier otra disciplina de la ingeniera. Una herramienta que difunde buenas
prcticas sera importante.
Programacin "automtica". Durante casi 40 aos, la gente ha estado anticipando y
escribiendo sobre "programacin automtica", la generacin de un programa para resolver
un problema desde una declaracin de las especificaciones del problema. Algunas personas
hoy escriben como si se espera que esta tecnologa para proporcionar la siguiente avance. 7
Parnas implica que el trmino se utiliza para el glamour y no contenido semntico,
afirmando,

En resumen, la programacin automtica ha sido siempre un eufemismo para la

programacin con un lenguaje de alto nivel que era actualmente disponible en el
programador. 8
Sostiene, en esencia, que en la mayora de los casos es el mtodo de solucin, no el
problema, cuya especificacin tiene que ser dada.

7 Mostow, op. cit.

8 Parnas, 1.985, op. cit

Las excepciones se pueden encontrar. La tcnica de los generadores de construccin es

muy potente, y que se usa rutinariamente para buena ventaja en los programas para la
clasificacin. Algunos sistemas para la integracin de las ecuaciones diferenciales tambin
han permitido la especificacin directa del problema.
El sistema evala los parmetros, escogi de una biblioteca de mtodos de solucin, y
generado los programas.

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.
Anlisis extensivo ha llevado a reglas explcitas para la seleccin de tcnicas de
solucin, teniendo en cuenta parmetros del problema.

Es difcil ver cmo tales tcnicas generalizan al resto del mundo de lo ordinario sistema de
software, donde los casos con tales propiedades ordenadas son la excepcin. Es difcil
incluso imaginar cmo podra ocurrir posiblemente este avance en la generalizacin.
Programacin grfica. Un tema favorito de PH.D. Disertaciones en el software
ingeniera es grfico, o visual, la programacin, la aplicacin de grficos de ordenador para
diseo de software. 9
A veces la promesa de un enfoque de este tipo se postula desde el analoga con el diseo de
chips VLSI, donde los grficos de computadora juega un papel tan fructfera.
A veces, el enfoque se justifica considerando diagramas de flujo como el programa ideal
disear medio y proporcionar instalaciones de gran alcance para la construccin de ellos.
Nada siquiera convincente, mucho menos emocionante, sin embargo, ha surgido de tales
esfuerzos. Yo estoy convencido de que nada lo har.

En primer lugar, como ya he dicho en otro lugar, el diagrama de flujo es una abstraccin
muy pobre de la estructura de software. 10
De hecho, se ve mejor como Burks, von Neumann y
El intento de Goldstine proporcionar un lenguaje de control de alto nivel necesita
desesperadamente para su equipo propuesto. En varias pginas, forma lastimosa, conexin
en caja a la que el flujo carta ha sido elaborado hoy, se ha demostrado ser esencialmente
intil como una herramienta de diseo programadores dibujar diagramas de flujo despus,
no antes, escribiendo los programas que describen.
En segundo lugar, las pantallas de hoy son demasiado pequeos, en pxeles, para mostrar
el alcance y la resolucin de cualquier diagrama detallado grave software. El llamado
"metfora del escritorio" de estacin de trabajo de hoy es ms bien una metfora "avinasiento". Cualquier persona que ha barajado un lapful de papeles, mientras que sentado en
un coche entre dos pasajeros corpulentos reconocer el diferencia se puede ver slo un par
de cosas a la vez. El verdadero escritorio proporciona visin general y el acceso aleatorio a
una veintena de pginas. Adems, cuando un ataque de creatividad corren fuerte, ms de
un programador o escritor se ha conocido a abandonar el escritorio el piso ms amplio. La
tecnologa de hardware tendr que avanzar bastante sustancialmente antes de que el
alcance de nuestros telescopios es suficiente para la tarea de diseo de software.
Ms fundamentalmente, como he argumentado anteriormente, el software es muy difcil
de visualizar.
Ya sea que diagrama de flujo de control, anidacin alcance variables, referencias cruzadas
variables, los datos soplar, estructuras de datos jerrquicos, o lo que sea, nos sentimos slo
una dimensin de la intrincadamente entrelazados elefante software. Si superponemos
todos los diagramas generados por los muchos puntos de vista relevantes, es difcil extraer
cualquier visin global. El VLSI analoga es fundamentalmente engaoso-un diseo de
chip es un objeto bidimensional en capas cuya geometra refleja su esencia. Un sistema de
software no lo es.

9 Raeder, G., "Un estudio de las tcnicas de programacin grfica actual," en RB Grafton y
T. Ichikawa,
eds., Edicin Especial de Programacin Visual, ordenador, 18, 8 (agosto, 1985), pp. 1125
10 Brooks 1,995, op. cit., captulo 15.

La verificacin de programas. Gran parte del esfuerzo en la programacin moderna

entra en la prueba y reparacin de errores. Hay quiz una bala de plata que se encuentran
al eliminar los errores en la fuente, en la fase de diseo del sistema? Pueden la
productividad y la fiabilidad del producto es mejorar radicalmente siguiendo el
profundamente diferente estrategia de diseos que demuestren correcta antes de que el
inmenso esfuerzo se vierte en la implementacin y prueba de ellos?
No creo que vayamos a encontrar la magia aqu. Programa de verificacin es un muy
potente concepto, y ser muy importante para cosas tales como granos de sistema
operativo seguro.
La tecnologa no promete, sin embargo, para ahorrar mano de obra. Las verificaciones son
tanto trabajo que se han verificado siempre slo unos pocos programas sustanciales.
Programa de verificacin no significa programas de prueba de error. No hay magia aqu, ya
sea. Pruebas matemticas tambin pueden estar defectuosos. As que mientras que la
verificacin podra reducir el programa de pruebas de carga, no puede eliminarlo.
Ms en serio, incluso la verificacin programa perfecto slo puede establecer que un
programa cumple con su especificacin. La parte ms difcil de la tarea de software est
llegando a una completa y especificacin consistente, y gran parte de la esencia de la
construccin de un programa es de hecho el la depuracin de la especificacin.
Entornos y herramientas. Cunto ms la ganancia se puede esperar de The Exploding
investiga en mejores entornos de programacin? Uno de reaccin instintiva es que el
problemas grandes Payoff fueron los primeros atacados, y se han resuelto: archivos
jerrquico sistemas, formatos de archivo de uniformes de manera que tienen interfaces de
programa de uniformes, y generalizada herramientas. Editores inteligentes especficos del
idioma son desarrollos an no se utiliza ampliamente en la prctica, pero el ms que
prometen es la libertad de los errores sintcticos y errores semnticos simples.
Tal vez la mayor ganancia an no se ha realizado en el entorno de programacin es el uso
de los sistemas de bases de datos integradas para realizar un seguimiento de las miradas
de detalles que deben ser record con precisin por el programador individual y
mantenido al da en un grupo de colaboradores en un solo sistema.
Seguramente este trabajo vale la pena, y seguramente llevar un poco de fruta, tanto en la
productividad y fiabilidad. Pero por su propia naturaleza, el regreso a partir de ahora debe
ser marginal.
Las estaciones de trabajo. Qu beneficios se esperan para el arte software del seguro y
rpido aumento en la capacidad de potencia y la memoria de la estacin de trabajo
individual? Bien, cuntos MIPS se puede utilizar con provecho? La composicin y edicin
de los programas y documentos es totalmente compatible con velocidades de
hoy. Compilar poda soportar un impulso, sino un factor de 10 en velocidad de la mquina
seguramente dejar pensar a tiempo la actividad dominante en el da del programador. De
hecho, parece ser lo que ahora.
Estaciones de trabajo ms potentes que sin duda dan la bienvenida. Mejoras mgicas de
ellos no podemos esperar.

Ataques prometedores en la esencia conceptual

A pesar de que ningn avance tecnolgico promete dar la suave mgica resultados con los
que nos son tan familiares en el rea de hardware, no es a la vez una gran cantidad de buen
funcionamiento pasando ahora, y la promesa de constante, si el progreso espectacular.
Todos los ataques tecnolgicos sobre los accidentes del proceso de software son
fundamentalmente limitada por la ecuacin de la productividad:
Tiempo de trabajo = (Frecuencia) x (Tiempo)
Si, como creo, los componentes conceptuales de la tarea estn tomando la mayor parte del
tiempo, entonces ninguna cantidad de la actividad en los componentes de tareas que no
son ms que la expresin de los conceptos pueden dar grandes ganancias de productividad.
Por lo tanto debemos tener en cuenta los ataques que abordan la esencia del software
problema, la formulacin de estas estructuras conceptuales complejas. Afortunadamente,
algunos de estos son muy prometedores.
Compre frente de construccin. La solucin ms radical posible para la construccin
de software no es construirlo en absoluto.
Cada da esta se vuelve ms fcil, ya que cada vez ms vendedores ofrecen ms y mejor
productos de software para una variedad vertiginosa de aplicaciones. Mientras que los
ingenieros de software que han trabajado en la metodologa de la produccin, la revolucin
del ordenador personal ha creado no uno, sino Muchas, los mercados de masas para el
software. Cada quiosco lleva mensual revistas que, ordenados por tipo de mquina,
anunciar y revisar decenas de productos en precios desde unos pocos dlares a unos pocos
cientos de dlares. Las fuentes ms especializadas ofrecen muy productos de gran alcance
para la estacin de trabajo y otros mercados de Unix. Incluso los peajes y de software
ambientes se pueden comprar fuera de la plataforma. He propuesto un mercado a otro
lugar paran mdulos individuales.
Cualquier producto es ms barato comprar que construir de nuevo. Incluso a un costo de $
100.000, una pieza comprada de software est costando slo alrededor tanto como un
programador aos.

Y la entrega es inmediata! Inmediato al menos para los productos que realmente existen,
productos cuyo desarrollador puede referirse a la perspectiva de un usuario feliz. Adems,
tales productos tienden a ser mucho mejor documentados y algo mejor mantenidos que el
software de cosecha propia.
El desarrollo del mercado de masas es, creo, la ms profunda tendencia a largo plazo en
ingeniera de software. El costo del software siempre ha sido el coste de desarrollo, no
costo de replicacin. Compartiendo ese costo incluso entre algunos usuarios reduce
radicalmente el usuario al-costo. 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
disponibles para hacer mi tarea? Una cosa sorprendente ha sucedido aqu. Durante los
aos 1950 y 1960, el estudio despus de un estudio mostr que los usuarios no utilizar offthe-shelf paquetes para la nmina, inventario control, cuentas, etc. Los requisitos eran
demasiado especializado, el caso por al-cobrar variacin demasiado alto. Durante la
dcada de 1980, nos encontramos con este tipo de paquetes de alta demanda y uso
generalizado. Lo que ha cambiado?
En realidad, no los paquetes. Ellos pueden ser algo ms generalizada y algo ms
personalizable que en otro tiempo, pero no mucho. En realidad, no las aplicaciones,
tampoco. Si nada, el de las necesidades cientficas de hoy en da los negocios y son ms
diversos, ms complicado que los de hace 20 aos.

El gran cambio ha sido en el ratio de eficiencia de hardware / software. El comprador de

un $ 2- millones de mquinas en 1960 sinti que poda pagar $ 250.000 ms por una
nmina personalizada programa, que se desliz con facilidad y sin interrupciones en el
ordenador hostil sociales ambiente. Los compradores de $ 50.000 mquinas de oficina de
hoy no puede permitirse el lujo concebible programas de nmina personalizados; para que
adapten sus procedimientos de nmina a los paquetes disponible. Computadoras ahora
son tan comunes, 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 del software
paquetes ha cambiado poco en los ltimos aos: las hojas de clculo electrnicas y base de
datos simple sistemas. Estas herramientas de gran alcance, tan obvias en retrospectiva y
sin embargo, tan tarde que aparecen, se prestan s mismos para infinidad de usos, algunos
bastante poco ortodoxa. Artculos e incluso libros abundan ahora sobre cmo abordar
tareas inesperadas con la hoja de clculo. Un gran nmero de aplicaciones eso sera antes
se han escrito los programas personalizados en Cobol o Programa Reportar
Generador ahora se realizan de forma rutinaria con estas herramientas.

Muchos usuarios ahora operan su propio da computadoras a da de variada aplicaciones

sin tener que escribir un programa. De hecho, muchos de estos usuarios no pueden escribir
nuevos programas para sus mquinas, pero son, sin embargo, expertos en resolucin de
nuevo problemas con ellos.
Creo que la estrategia de la productividad de software ms poderosa para el hombre
organizaciones a da es dotar a los trabajadores intelectuales en computadoras ingenuo en
la lnea de fuego con ordenadores personales y buena generalizada escritura, dibujo,
archivo y hoja de clculo programas, y los convierten suelto. La misma estrategia, con una
programacin sencilla capacidades, tambin trabajarn para cientos de cientficos de
laboratorio.
Requisitos refinamiento y prototipado rpido. La parte ms difcil de la nica
construccin de un sistema de software es decidir exactamente qu construir. Ninguna otra
parte del trabajo conceptual es difcil, ya que se establecen los requisitos tcnicos
detallados, incluyendo toda la interfaces para las personas, a las mquinas, y de otros
sistemas de software. Ninguna otra parte del trabajo de modo paraliza el sistema
resultante si se hace mal. Ninguna otra parte es ir ms difcil rectificar ms tarde.
Por lo tanto, la funcin ms importante que los constructores de software hacen para sus
clientes es la extraccin y refinamiento iterativo de los requisitos del producto. Pues la
verdad es que el los clientes no saben lo que quieren. Por lo general, no saben qu
preguntas debe ser contestadas, y que casi nunca han pensado en el problema en el detalle
que debe ser especificado. Incluso el simple respuesta- "Hacer que el nuevo sistema
funcione software como nuestro viejo sistema de informacin-procesamiento manual ", es,
de hecho, demasiado simple. Los clientes nunca quieren exactamente eso. Sistemas de
software complejos son, por otra parte, las cosas que actan, que se mueven, que
trabajo. La dinmica de la accin son difciles de imaginar. As que en la planificacin de
cualquier software la actividad, es necesario para permitir una extensa 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 los clientes,
incluso aquellos trabajar con los ingenieros de software, para especificar por completo,
precisa y correctamente el exacto requisitos de un producto de software moderno antes de
haber construido y trataron algunas versiones del producto que estn especificando.

Por lo tanto uno de los ms prometedores de los actuales esfuerzos tecnolgicos, y uno que
ataca la esencia, no los accidentes, del problema de software, es el desarrollo de enfoques y
herramientas para la creacin rpida de prototipos de sistemas como parte de la iterativo
especificacin de los requisitos.
Un sistema de software prototipo es una que simula las interfaces importantes y realiza las
principales funciones del sistema previsto, mientras que no siendo necesariamente
vinculado por las mismas limitaciones de velocidad de hardware, el tamao, o el costo. Los
prototipos suelen realizar la tareas de la lnea principal de la aplicacin, pero no intentan
manejar las excepciones, responden correctamente a las entradas no vlidas, abortar
limpiamente, etc. El propsito del prototipo es hacer real de la estructura conceptual
especifica, de manera que el cliente puede probar para la consistencia y usabilidad
Gran parte de los procedimientos de adquisicin de software actual se basa en la
suposicin de que se puede especificar un sistema satisfactorio de antelacin, obtener
ofertas para su construccin, lo tienen construccin, e instalarlo. Creo que esta suposicin
es fundamentalmente equivocada, y que muchos problemas de adquisicin de software
surgen de esa falacia. Por lo tanto no pueden ser fijos sin revisin fundamental, que prev
el desarrollo iterativo y especificacin de los prototipos y productos.
Desarrollo incremental - crecer, no construye, software. Todava recuerdo la
sacudida que sent en 1958, cuando escuch por primera vez a un amigo hablar de la
construccin de un programa, en lugar de escribir una.
En un instante ampliarse todo mi punto de vista del proceso de software. El cambio
metfora era poderoso y preciso. Hoy entendemos cmo al igual que otro edificio procesa
la construccin de software es, y usamos libremente otros elementos de la metfora, como
especificaciones, montaje de componentes y andamios.
La metfora edificio ha sobrevivido a su utilidad. Es el momento de cambiar de nuevo. Si,
como yo creer, las estructuras conceptuales que construimos hoy son demasiado
complicados para ser precisa especificada de antemano, y demasiado complejos para ser
construida sin errores, entonces tenemos que tomar una enfoque radicalmente diferente.
Volvamos a la naturaleza y estudiamos la complejidad de los seres vivos, en lugar de los
muertos obras del hombre. Aqu nos encontramos con construcciones cuyas complejidades
emocionarnos con asombro. El cerebro solo es complicado ms all de la cartografa,
poderoso ms all de la imitacin, rico en diversidad, auto-proteccin y autorenovacin. El secreto es que se cultiva, no construido.
Y as debe ser con nuestros sistemas de software. Hace algunos aos Harlan Mills propuso
que cualquier sistema de software debe ser cultivado por desarrollo incremental. 11 Es
decir, el sistema de primero debe ponerse a correr, a pesar de que no hace nada til,
excepto llamada el conjunto adecuado de subprogramas ficticios. Luego, poco a poco se
enriquezca con los subprogramas a su vez, est desarrollando en acciones o llamadas a
vaciar los talones en el nivel inferior.
He visto los resultados ms dramticos desde que comenc instando a esta tcnica en los
constructores de proyectos de software de clase de laboratorio de ingeniera. Nada en la
ltima dcada ha cambiado tan radicalmente mi propia prctica, o su eficacia. Las requiere

enfoque diseo descendente, ya que es una de arriba hacia abajo cada vez mayor del
software. Permite fcil retroceso. Se presta a los primeros prototipos. Cada funcin de
agregado y nueva disposicin para los datos ms complejos o circunstancias crecidas
orgnicamente de lo que ya existe

11 Mills, de alta definicin, la "programacin de arriba hacia abajo en grandes

sistemas," tcnicas de depuracin en sistemas grandes, R. Rustin, ed., Englewood Cliffs,
NJ, Prentice-Hall, 1971

Los efectos de moral son alarmantes. El entusiasmo salta cuando hay un sistema en
funcionamiento, aunque sea simple. Redoblar los esfuerzos cuando la primera imagen de
un nuevo software de grficos sistema aparezca en la pantalla, incluso si es slo un
rectngulo. Uno siempre tiene, en cada etapa en el proceso, un sistema de trabajo. Me
parece que los equipos pueden crecer mucho ms complejo entidades en cuatro meses lo
que pueden construir.
Los mismos beneficios se pueden realizar en grandes proyectos como en mis pequeos. 12
Los grandes diseadores. La cuestin central de cmo mejorar los centros de arte de
software, ya que siempre, en las personas.
Podemos conseguir buenos diseos siguiendo las buenas prcticas en lugar de los
pobres. Bien prcticas de diseo 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 empuje importante en los Estados Unidos es promulgar buena
prctica moderna. Nuevos planes de estudio, la nueva literatura, nuevas organizaciones
tales 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 adecuado.
Sin embargo, no creo que podamos dar el siguiente paso hacia arriba de la misma manera.
Mientras que la diferencia entre pobres diseos conceptuales y buenos puede estar en el
solidez del mtodo de diseo, la diferencia entre los buenos diseos y grandes sin duda
no. Grandes diseos provienen de grandes diseadores. La construccin de software es un
creativo proceso. Metodologa de sonido pueden potenciar y liberar la mente creativa; no
puede inflamar o inspirar el esclavo.

Las diferencias no son menores, es ms bien como Salieri y Mozart. Estudio tras estudio
muestra que los mejores diseadores producen estructuras que son ms rpidos, ms
pequeos, ms simple, limpiador, y producido con menos esfuerzo. Las diferencias entre el
grande y el promedio acercarse a un orden de magnitud.
Un poco de retrospectiva muestra que aunque muchos bien, los sistemas de software tiles
tienen sido diseado por los comits y construido por los proyectos de varias partes, los
sistemas de software que han emocionado aficionados apasionados son los que son los
productos de una o unas pocas diseo mentes, grandes diseadores. Considere Unix, APL,
Pascal, Modula, la interfaz de Smalltalk, incluso Fortran; y el contraste con Cobol, PL / I,
Algol, MVS / 370 y MS-DOS (fig. 1)
S

Sin

Unix

Cobol

APL

PL / 1

Pascal

Algol

Modula

MVS / 370

Smalltalk

MS-DOS

Fortran
Fig. 1 productos emocionantes
Por lo tanto, aunque yo apoyo firmemente la transferencia de tecnologa y currculo los
esfuerzos de desarrollo en marcha, creo que el esfuerzo ms importante que podemos
montaje es desarrollar formas de hacer crecer grandes diseadores

12 Boehm, BW, "Un modelo espiral de desarrollo de software y mejora," Computer, 20, 5
(mayo, 1985), pp. 43-57

Ninguna organizacin software puede ignorar este reto. Los buenos gerentes, aunque
escasa que sean, no son ms escasos que los buenos diseadores. Grandes diseadores y
gerentes son a la vez muy raro. La mayora de las organizaciones gastan considerable
esfuerzo en la bsqueda y el cultivo de la perspectivas de gestin; No conozco ninguno que
gasta el mismo esfuerzo en la bsqueda y desarrollo los grandes diseadores a quienes la
excelencia tcnica de los productos en ltima instancia, depender.
Mi primera propuesta es que cada organizacin debe determinar el software y proclamar
que grandes diseadores son tan importantes para su xito como los grandes gerentes son,

y que pueden ser espera que se nutre y recompensado de manera similar. No slo el
sueldo, pero las gratificaciones de
Tamao reconocimiento oficina, mobiliario, equipo tcnico personal, fondos para viajes, el
personal apoyo debe ser totalmente equivalente.
Cmo crecer grandes diseadores? El espacio no permite una larga discusin, pero
algunos pasos son obvios:

Sistemticamente identificar a los mejores diseadores tan pronto como sea

posible. Lo mejor suele ser el son ms experimentados.
Asignar un mentor profesional a ser responsable para el desarrollo de la
perspectiva, y mantenerlo un archivo de carrera cuidado.
Elaborar y mantener un plan de desarrollo de carrera para cada prospecto,
incluyendo cuidado aprendizajes seleccionados con los mejores diseadores,
episodios de la educacin formal avanzada, y cursos cortos, todos entremezclados
con un diseo individual y el liderazgo tcnico asignaciones.
Proporcionar oportunidades para el crecimiento de los diseadores para
interactuar y estimular entre s.