No hay bala de plata -Esencia y el accidente en Ingeniera de Software Frederick P. Brooks, Jr. Universidad de Carolina del Norte en Chapel Hill No hay desarrollo individual, ya sea en tecnologa o la gestin tcnica, que de por s promete incluso un orden de magnitud mejora dentro de una dcada en la productividad, la fiabilidad, en la sencillez. Abstracto 1 Toda la construccin de software implica tareas esenciales, la elaboracin de los complejos estructuras conceptuales que componen la entidad software abstracto, y las tareas accidental, el la representacin de estas entidades abstractas en lenguajes de programacin y la asignacin de stos. en lenguajes de mquina dentro de las limitaciones de espacio y la velocidad La mayor parte de los ltimos grandes aumento de la productividad de software han llegado al eliminar las barreras artificiales que han hizo las tareas accidental excesivamente duro, tales como las limitaciones de hardware grave, lenguajes de programacin difciles, la falta de tiempo de mquina. Cunto de lo que el software Los ingenieros ahora no se sigue dedicando a lo accidental, a diferencia de lo esencial? A menos que es ms de 9 / 10 de todo el esfuerzo, la reduccin de todas las actividades accidental a cero el tiempo no dar un orden de magnitud de mejora. Por lo tanto, parece que ha llegado el momento para hacer frente a las partes esenciales de la tarea de software, los interesados en forma a las estructuras abstractas conceptuales de gran complejidad. Yo sugiero: Explotar el mercado de masas para evitar la construccin de lo que se puede comprar. Utilizando el prototipado rpido, como parte de una iteracin planificada en el establecimiento de programas requisitos. Cada vez mayor de software de manera orgnica, la adicin de la funcin cada vez ms a los sistemas ya que son ejecutar, usado y probado. Identificacin y desarrollo de los grandes diseadores conceptuales de la nueva generacin. Introduccin De todos los monstruos que llenan las pesadillas de nuestro folklore, ninguno aterroriza ms hombres lobo, porque transforman inesperadamente de lo familiar en horrores. Para

estos, buscamos balas de plata que por arte de magia se puede sentar a descansar. 1 Reproducido de: Frederick P. Brooks, La edicin de Mythical Man-Month, aniversario con 4 nuevos captulos, Addison-Wesley (1995), reimpreso en s de las Actas de la Dcimo Mundial de IFIP Conferencia de computacin, H.-J. Kugler, ed., Elsevier Science BV, Amsterdam, NL (1986) pp 1069-1076. Pgina 2 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 2 El proyecto de software familiar tiene algo de este personaje (por lo menos como se ve por el no el director tcnico), por lo general inocente y sencillo, pero capaz de convertirse en una monstruo de las planificaciones perdidas, los presupuestos de soplado, y los productos defectuosos. Por lo tanto, escuchar desesperada clama por una bala de plata, algo que hace que los costos de software caer tan rpidamente como equipo los costos de hardware hacer. Pero, al mirar al horizonte de una dcada, por lo tanto, no vemos ninguna bala de plata. No hay nico de desarrollo, ya sea en tecnologa o tcnica de gestin, que por s mismo promesas, incluso un orden de magnitud de la mejora de la productividad, la fiabilidad, en simplicidad. En este captulo vamos a tratar de ver por qu, pero examinando tanto la naturaleza de la problema de software y las propiedades de las balas propuesto. El escepticismo no es pesimismo, sin embargo. Aunque no vemos avances sorprendentes, y, de hecho, creen que tal es incompatible con la naturaleza del software, muchos fomentar las innovaciones en curso. Un esfuerzo disciplinado y consistente para el desarrollo, se propagan, y los explotan de hecho debera producir una mejora de un orden de magnitud. No hay camino real, pero hay un camino. El primer paso hacia el manejo de la enfermedad fue la sustitucin de las teoras de demonio y de los humores teoras de la teora de los grmenes. Que paso, el comienzo de la esperanza, en s mismo punteada todas las esperanzas de soluciones mgicas. Se dijo a los trabajadores el progreso se hizo paso a paso, con gran esfuerzo, y que una atencin persistente, sin tregua tendra que ser pagado a un la disciplina de la limpieza. Lo mismo ocurre con la ingeniera de software hoy en da. Tiene que ser difcil? - Las dificultades esenciales No slo no hay balas de plata ahora a la vista, la naturaleza misma del software que hace poco probable que haya alguna-no inventos que va a hacer por software de productividad,

confiabilidad y simplicidad lo que la integracin de la electrnica, los transistores, y en gran escala hizo por equipo de hardware. No podemos esperar que lleguemos a ver las ganancias doble cada dos aos. En primer lugar, debemos observar que la anomala no es que el progreso del software es tan lento, pero que el progreso del hardware es tan rpido. Ninguna otra tecnologa desde el comienzo de la civilizacin ha visto a seis rdenes de magnitud de precio-rendimiento de ganancia en 30 aos. En ningn otro La tecnologa se puede optar por tomar la ganancia, ya sea en rendimiento o en la reduccin de los costos. Estos flujo de ganancias derivadas de la transformacin de la fabricacin de equipo de un conjunto de la industria en una industria de proceso. En segundo lugar, para ver qu tipo de progreso que podemos esperar en tecnologa de software, vamos a examinar las dificultades. Siguiendo a Aristteles, que los dividen en esencia, las dificultades inherente a la naturaleza del software y los accidentes, las dificultades que hoy asisten a su produccin, pero que no son inherentes. Los accidentes de discutir en la prxima seccin. En primer lugar vamos a considerar la esencia. La esencia de una entidad de software es una construccin de conceptos interrelacionados: conjuntos de datos, las relaciones entre los elementos de datos, algoritmos, e invocaciones de funciones. Esta esencia es abstracto, en que la construccin conceptual es el mismo en muchos diferentes representaciones. Sin embargo, es muy precisa y detallada ricamente. Yo creo que la parte ms difcil de la creacin de software para la especificacin, diseo y pruebas de esta construccin conceptual, no el trabajo de los que lo representan y la prueba la fidelidad de los representacin. Todava cometemos errores de sintaxis, sin duda; pero son pelusa en comparacin con el errores conceptuales en la mayora de los sistemas. Pgina 3 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 3 Si esto es cierto, la construccin de software siempre va a ser difcil. No es de por s hay plata bala. Consideremos las propiedades inherentes de esta esencia irreductible de software moderno sistemas: complejidad, conformidad, variabilidad, y la invisibilidad.

Complejidad. Las entidades de software son ms complejas por su tamao que quizs cualquier otro humanos construyen, porque no hay dos partes iguales (al menos por encima del nivel de instruccin). Si que son, que hacen las dos partes similares en una sola, una subrutina, abierto o cerrado. En este sistemas de software difieren profundamente el respeto de los ordenadores, edificios o automviles, donde abundan los elementos repetidos. Las computadoras digitales son en s mismos ms compleja que la mayora de las cosas la gente a construir, sino que tienen un gran nmero de estados. Esto hace concebir, describir y probarlas duro. Los sistemas de software tienen rdenes de magnitud ms que los estados hacen las computadoras. Del mismo modo, una ampliacin de una entidad de software no es simplemente una repeticin de lo mismo los elementos de mayor tamao, es necesariamente un aumento en el nmero de elementos diferentes. En la mayora de los casos, los elementos interactan entre s de alguna manera no lineal, y la complejidad del conjunto aumenta mucho ms que linealmente. La complejidad de software est en propiedad esencial, no una accidental. Por lo tanto descripciones de una entidad de software que abstraen la complejidad a menudo abstraer su esencia. Las matemticas y las ciencias fsicas hecho grandes progresos durante tres siglos por la construccin de modelos simplificados de fenmenos complejos, derivando propiedades de la modelos, y la verificacin de las propiedades de forma experimental. Esto funcion ya que el complejidades ignoradas en los modelos no eran las propiedades esenciales de los fenmenos. Lo no funciona cuando las complejidades son la esencia. Muchos de los problemas clsicos de los productos de software de desarrollo derivados de este complejidad esencial y su no lineal aumenta con el tamao. De la complejidad viene la dificultad de comunicacin entre los miembros del equipo, lo que conduce a los defectos del producto, el costo sobrecostos, retrasos en el programa. De la complejidad surge la dificultad de enumerar, comprender y mucho menos, todos los posibles estados del programa, y de ah procede el falta de fiabilidad. De la complejidad de las funciones viene la dificultad de la invocacin de los funciones, lo que hace que los programas sean difciles de usar. De la complejidad de la estructura viene la dificultad de extender los programas a las nuevas funciones sin crear efectos secundarios. Desde el complejidad de la estructura de la informacin del estado que unvisualized que constituyen la seguridad

trampillas. No slo problemas tcnicos, sino los problemas de gestin y provienen de la complejidad. Esta complejidad hace difcil panorama, impidiendo as la integridad conceptual. Que hace que sea difcil de encontrar y controlar todos los cabos sueltos. Crea el gran aprendizaje y la comprensin de carga que hace que la rotacin de personal de un desastre. Conformidad. Software de la gente no estn solos frente a la complejidad. La fsica se ocupa objetos tremendamente complejos, incluso en el nivel de "fundamental" de las partculas. Los trabajos fsicos , sin embargo, en una fe firme de que hay principios unificadores que se encuentran, ya sea en quarks o en las teoras del campo unificado. Einstein sostenido en repetidas ocasiones que debe haber simplificar las explicaciones de la naturaleza, porque Dios no es caprichoso ni arbitrario. No hay tal fe consuela a los ingenieros de software. Gran parte de la complejidad que debe maestro es la complejidad arbitraria, forzada sin ton ni son por el ser humano muchas Pgina 4 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 4 las instituciones y los sistemas a los que sus interfaces deben confirmar. Estos difieren de la interfaz a la interfaz, y de vez en cuando, no por necesidad, pero slo porque eran diseados por diferentes personas, en lugar de Dios. En muchos casos, el software debe confirmar, ya que ms recientemente ha llegado a la escena. En otros se deben cumplir porque se percibe como el ms adaptable. Sin embargo, en todos los casos, la complejidad de gran parte proviene de la conformacin de otras interfaces, lo que no puede ser simplificado por un nuevo diseo 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 se fabrican con poca frecuencia cambiado despus de la fabricacin, sino que son reemplazados por modelos ms tarde, o se producen cambios esenciales ms tarde incorporado en el nmero de serie-copias de el mismo diseo bsico. Las devoluciones de llamada de los automviles son muy poco frecuentes, cambios en el campo de los ordenadores algo menos. Ambos son mucho menos frecuentes que las modificaciones a los programas de campaa. En parte, esto se debe a que el software en un sistema incorpora la funcin y la funcin es la parte que ms se siente la presin del cambio. En parte es porque el software puede ser

modificarse con ms facilidad-es el pensamiento puro, cosas, infinitamente maleable. Edificios, de hecho, se cambian, pero los altos costos del cambio, entendido por todos, sirven para amortiguar el capricho de los cambistas. Todos los programas exitosos que se cambia. Dos son los procesos de trabajo. Como un software producto se encuentra para ser til, la gente lo trate de nuevos casos en el borde de, o ms all, el dominio original. Las presiones para la funcin ampliada proceden principalmente de los usuarios que les gusta la funcin bsica y utiliza inventar nuevas para l. Software en segundo lugar, el xito tambin sobrevive ms all de la vida normal de la mquina vehculo para el que primero se escribe. Si no los nuevos equipos, a continuacin, al menos, nuevos discos, nuevos pantallas, impresoras nuevas vienen a lo largo, y el software debe estar conforme con su nuevo vehculos de ocasin. En resumen, el producto de software est integrado en una matriz cultural de aplicaciones, los usuarios leyes, y los vehculos de la mquina. Estos cambiar todo continuamente, y sus cambios inexorablemente forzar un cambio en el producto de software. Invisibilidad. Software es invisible y unvisualizable. Abstracciones geomtricas son herramientas de gran alcance. La planta de un edificio ayuda tanto a arquitecto y el cliente evaluar espacios, los flujos de trfico y puntos de vista. Contradicciones se hacen evidentes, las omisiones pueden ser atrapado. Dibujos a escala de las partes mecnicas y los modelos de figuras de palo de las molculas, a pesar de las abstracciones, sirven al mismo propsito. Una realidad geomtrica es capturado en una la abstraccin geomtrica. La realidad de software no es de por s integrado en el espacio. Por lo tanto, no tiene listo representacin geomtrica de la forma en que la tierra tiene los mapas, los chips de silicio tienen diagramas, los equipos tienen esquemas de conectividad. Tan pronto como intento de software de diagrama de estructura, nos encontramos con que se constituya no uno, sino varios grficos, en general las instrucciones, superpuestas una sobre otra. Los grficos de varios puede representar el flujo de control, el flujo de datos, los patrones de dependencia, la secuencia de tiempo, espacio de nombres de relaciones. Estos son por lo general ni siquiera planos, y mucho menos jerrquica. De hecho, una de las formas de

Pgina 5 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 5 establecer control conceptual sobre dicha estructura es de corte para hacer cumplir enlace hasta que uno o ms de los grficos se jerrquica. 2 A pesar del progreso en la restriccin y la simplificacin de las estructuras de software, siendo intrnsecamente 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 una mente, obstaculiza seriamente la comunicacin entre mentes. Avances pasado Resuelto dificultades accidentales Si examinamos los tres pasos en la tecnologa de software que han sido ms fructferos en la pasado, descubrimos que cada uno atac a una dificultad importante en diferentes programas de construccin, pero han sido de lo accidental, no lo esencial, las dificultades. Tambin podemos ver lo natural lmites a la extrapolacin de cada uno de estos ataques. Lenguajes de alto nivel. Sin duda, el golpe ms potente de software de productividad, confiabilidad y simplicidad ha sido el uso progresivo de lenguajes de alto nivel para programacin. La mayora de los observadores de crdito que el desarrollo de al menos un factor de cinco en productividad, y con las ganancias concomitante de fiabilidad, simplicidad y comprensibilidad. Qu hace un lenguaje de alto nivel de lograr? Libera a un programa de gran parte de su la complejidad accidental. Un programa abstracto consiste de constructos conceptuales: operaciones, tipos de datos, las secuencias, y la comunicacin. El programa de mquinas de hormign preocupados por los bits, los registros, las condiciones, las ramas, los canales, los discos, y tal. Al medida en que el lenguaje de alto nivel representa las construcciones quera en el resumen programa y evita todos los inferiores, se elimina todo un nivel de complejidad que se Nunca inherentes al programa en absoluto. La mayora de los lenguajes de alto nivel puede hacer es proporcionar a todas las construcciones del programador imagina en el programa de resumen. Sin duda, el nivel de sofisticacin en el pensamiento de nuestros sobre las estructuras de datos, tipos de datos y las operaciones va en constante aumento, pero a un cada vez ms 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 de los usuarios que rara vez utiliza la esotrica las construcciones. La mayor parte de tiempo compartido. Observadores de crdito de tiempo compartido con una importante mejora en la productividad de los programadores y en la calidad de sus productos, aunque no tan grande como que llev por lenguajes de alto nivel. Tiempo compartido ataca una dificultad muy diferentes. Tiempo compartido conserva inmediatez, y por lo tanto nos permite mantener una visin de la complejidad. El lento cambio de la programacin por lotes significa que inevitablemente se olvidan los detalles, si no la muy de empuje, de lo que estaban pensando cuando dejamos de programacin e instaron a compilacin y ejecucin. Esta interrupcin de la conciencia es costoso en tiempo, para que debe actualizar. El efecto ms grave puede ser la decadencia de la comprensin de todo lo que est pasando en un sistema complejo. 2 Parnas, DL, "Diseo de software para facilitar la extensin y contraccin de" Trans IEEE. en la SE, 5, 2 (Marzo de 1979), pp 12-138. Pgina 6 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 6 Lento giro, al igual que la complejidad de lenguaje de mquina, es un accidente en lugar de una dificultad esencial del proceso de software. Los lmites de la contribucin de tiempo compartido derivan directamente. El efecto principal es reducir el tiempo de respuesta del sistema. A medida que se va a cero, en algn momento que pasa el umbral humano de la vistosidad, alrededor de 100 milisegundos. Ms all de que no hay beneficios se pueden esperar. Unificado de entornos de programacin. Unix y INTERLISP, el primer sistema integrado entornos de programacin a entrar en uso generalizado, se percibe que han mejorado la productividad por factores integral. Por qu? Ellos atacan las dificultades accidentales de la utilizacin de programas en conjunto, ofreciendo bibliotecas integradas, formatos de archivo unificado, y las pilas y filtros. Como resultado, conceptual estructuras que, en principio, siempre se podra denominar, de alimentacin, y el uso de uno al otro en realidad puede fcilmente hacerlo en la prctica. Este avance, a su vez estimul el desarrollo de toolbenches conjunto, ya que

cada nueva herramienta podra aplicarse a cualquier programa mediante el uso de los formatos estndar. Debido a estos xitos, los entornos son objeto de gran parte del software actual de investigacin de ingeniera. Vamos a ver a su promesa y las limitaciones en la siguiente seccin. Las esperanzas de la Plata Ahora vamos a considerar los avances tcnicos que son ms a menudo avanzados como balas de plata potencial. Qu problemas abordan? Son los problemas de esencia, o son restos de las dificultades accidentales? Ofrecen avances revolucionarios, o las copias incrementales? Ada y otros funcionarios de alto nivel de los avances del lenguaje. Uno de los ms recientes promociona desarrollo es el lenguaje de programacin Ada, una de propsito general, lenguajes de alto nivel de la dcada de 1980. Ada no slo refleja el hecho mejoras evolutivas en la lengua conceptos, sino que incorpora caractersticas para fomentar el diseo moderno y modularizacin conceptos. Tal vez la filosofa de Ada es ms de un anticipo que el lenguaje Ada, para es la filosofa de diseo modular, de tipos abstractos de datos, de jerarquizacin. Ada es tal vez ms rico, el producto natural del proceso por el cual los requisitos se puesto en su diseo. Eso no es fatal, para vocabularios subgrupo de trabajo se puede resolver el problema de aprendizaje, y los avances de hardware nos dar la MIPS barato que pagar por el compilacin de los costos. Avanzar en la estructuracin de sistemas de software es de hecho una muy buena utilizar para el aumento de los dlares de nuestros MIPS va a comprar. Sistemas operativos, en voz alta denunciado en el 1960 para la memoria y los costes del ciclo, han demostrado ser una excelente forma en la que utilizar algunos de los MIPS y bytes de memoria barata de la oleada de hardware anteriores. Sin embargo, Ada no llegar a ser la bala de plata que acaba con el software productividad monstruo. Es, despus de todo, slo un lenguaje de alto nivel, y el ms grande pago de estas lenguas procedan de la primera transicin, frente a lo accidental complejidad de la mquina en la declaracin ms abstracta de las soluciones paso a paso. Una vez que los accidentes se han eliminado, las restantes son ms pequeas, y la recompensa de su retiro seguramente ser menor. Mi prediccin es que dentro de una dcada, cuando la efectividad de Ada se evala, se visto que han hecho una diferencia sustancial, pero no debido a ningn idioma en particular funcin, ni tampoco porque de todos ellos juntos. Tampoco lo har el nuevo Ada Pgina 7 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 7

medio ambiente resultan ser la causa de las mejoras. Mayor contribucin de Ada se ser que el cambio para los programadores de formacin ocasionado en el diseo de un moderno software tcnicas. Programacin orientada a objetos. Muchos de los estudiantes de arte tienen ms esperanza de objetos programacin orientada a que para cualquiera de las modas otras tcnicas de la poca. 3 Yo estoy en medio de ellos. Mark Sherman, del Dartmouth seala que debemos tener cuidado de distinguir entre dos ideas diferentes que van con ese nombre: tipos abstractos de datos y tipos jerrquicos, tambin llamados clases. El concepto de tipo abstracto de datos es que un tipo de objeto debe ser definido por un nombre, un conjunto de valores propios, y un conjunto de operaciones propias, en lugar de su estructura de almacenamiento, que debe ser ocultado. Ejemplos de ello son los paquetes de Ada (con bao privado los tipos) o mdulos de Modula. Tipo jerrquico, como Simula-67 de las clases, permite la definicin de los generales interfaces que puede ser refinado, proporcionando tipos subordinados. Los dos conceptos son ortogonales, puede haber jerarquas sin esconder y ocultar, sin jerarquas. Ambos conceptos representan avances reales en el arte de la construccin de software. Cada uno elimina una dificultad ms accidental del proceso, que permite al diseador para expresar la esencia de su diseo sin tener que expresar una gran cantidad de sintaxis material que no aaden ningn contenido de la informacin. Para ambos tipos abstractos y jerrquica tipos, el resultado es para quitar una especie de orden superior de dificultad accidental y permiten una de orden superior la expresin del diseo. Sin embargo, estos avances no pueden hacer ms para eliminar todas las accidentales las dificultades de la expresin del diseo. La complejidad del diseo en s es esenciales, como los ataques y no hacer cualquier cambio en eso. Una ganancia del orden de magnitud se puede hacer programacin orientada a objetos slo si la maleza innecesaria de tipo especificacin restantes hoy en da en nuestro lenguaje de programacin es en s mismo responsable de nueve dcimas de los trabajos en el diseo de un producto de programa. Yo lo dudo. La inteligencia artificial. Muchas personas esperan que los avances en inteligencia artificial para proporcionar el avance revolucionario que le dar un orden de magnitud de las ganancias en el software productividad y calidad. 4 Yo no lo hacen. Para ver por qu, debemos analizar qu se entiende por "Inteligencia artificial", y luego ver cmo se aplica. Parnas ha clarificado el caos terminolgico: Dos definiciones muy diferentes de la IA son de uso comn hoy en da. AI-1: El uso de la

computadoras para resolver problemas que antes slo podan ser resueltos mediante la aplicacin de humanos la inteligencia. AI-2: El uso de un conjunto especfico de tcnicas de programacin conocida como heurstico o de programacin basado en reglas. En este enfoque de los expertos humanos son los estudios de determinar qu heursticas o reglas de oro que utilizan en la solucin de problemas. . . . La 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, California: Benjamin Cummings, 1983. 4 Mostow, J., ed., Nmero especial sobre Inteligencia Artificial e Ingeniera del Software, IEEE Trans. en la SE, 11, 11 (noviembre 1985). Pgina 8 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 8 La primera definicin tiene un sentido de deslizamiento. . . . Algo que puede ajustarse a la definicin de la IA-1 hoy, pero, una vez que veamos cmo funciona el programa y entender el problema, vamos a no pensar en ella como la IA ms. . . . Lamentablemente no puedo identificar un conjunto de tecnologa que es nico en este campo. . . . La mayora del trabajo es un problema especfico, y algunos la abstraccin y la creatividad se requieren para ver la forma de transferencia. 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 son a la vez diferentes de los utilizados en los sistemas expertos. Se me hace difcil ver cmo la imagen reconocimiento, por ejemplo, har una diferencia apreciable en la prctica de programacin. Lo mismo se puede tratar de reconocimiento de voz. Lo difcil es decidir la construccin de software qu decir, no lo dice. No facilitar la expresin puede dar ms que marginal ganancias. Experto en sistemas de tecnologa, AI-2, merece un apartado propio. Los sistemas expertos. La parte ms avanzada de la tcnica de inteligencia artificial, y la mayora de los

se aplica ampliamente, es la tecnologa para la construccin de sistemas expertos. Muchos cientficos software estn trabajando duro en la aplicacin de esta tecnologa para el entorno de software de la capacidad. 6 Qu es el concepto, y cules son las perspectivas? Un sistema experto es un programa que contiene un motor de inferencia generalizada y una regla base, diseada para tomar los datos y supuestos y explorar las consecuencias lgicas a travs de las inferencias que pueden obtenerse de la base de reglas, las conclusiones de rendimiento y asesoramiento, y que ofrece para explicar sus resultados por volver sobre sus motivos para el usuario. La inferencia motores normalmente se puede tratar con datos borrosos o probabilstico y normas, adems de puramente lgica determinista. Estos sistemas ofrecen algunas ventajas claras sobre los algoritmos programados para llegar en las mismas soluciones a los mismos problemas: La tecnologa de motor de inferencia se desarrolla de una manera independiente de la aplicacin, a continuacin, aplicado a muchos usos. Se puede justificar un esfuerzo mucho mayor en los motores de inferencia. De hecho, de que la tecnologa est muy avanzada. La partes variables de los materiales peculiares de la aplicacin estn codificados en la base de reglas de una manera uniforme, y se proporcionan herramientas para el desarrollo, el cambio, las pruebas y documentacin de la base de reglas. Esta regulariza la mayor parte de la complejidad de la aplicacin s mismo. Edward Feigenbaum dice que el poder de estos sistemas no viene de siempre elegante mecanismos de inferencia, sino las bases de conocimientos cada vez ms ricos, que reflejan el mundo real con ms precisin. Creo que el avance ms importante que ofrece el La tecnologa es la separacin de la complejidad de las aplicaciones desde el propio programa. Cmo puede ser aplicado a la tarea de software? En muchos sentidos: la interfaz lo que sugiere normas, asesoramiento sobre estrategias de ensayo, recordando, pero de tipo frecuencias, ofreciendo consejos de optimizacin, etc 5 Parnas, DL, "los aspectos del software de sistemas de defensa estratgica", Communications of the ACM, 28, 12 (diciembre,

1985), pp 1326-1335. Tambin en la revista American Scientist, 73, 5 (septiembre-octubre, 1985), pp 432-440. 6 Balzer, R., "Una perspectiva de 15 aos en la programacin automtica," en Mostow, op. cit. Pgina 9 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 9 Considere la posibilidad de un asesor de pruebas imaginario, por ejemplo. En su forma ms rudimentaria, el sistema experto de diagnstico es muy parecido a una lista de control del piloto, en el fondo que ofrece sugerencias en cuanto a las posibles causas de dificultades. Como la base de reglas se desarrolla, la sugerencias ms especficas, teniendo en cuenta ms sofisticado de los problemas los sntomas reportados. Se puede visualizar un asistente de depuracin que ofrece muy generalizado sugerencias al principio, pero como la estructura del sistema cada vez ms se manifiesta en la base de reglas, viene ms y ms en particular en la hiptesis se genera y que las pruebas recomienda. Como un sistema experto puede apartarse radicalmente de la mayora de los convencionales en los que su base de reglas probablemente debera ser jerrquicamente en mdulos de la misma manera el producto de software correspondiente, de modo que como el producto de forma modular modificado, el base de reglas de diagnstico puede ser modificada, de forma modular. El trabajo necesario para generar las reglas de diagnstico es un trabajo que tendr que hacer de todos modos en la generacin de la serie de casos de prueba para los mdulos y para el sistema. Si se hace de manera general adecuada, con una estructura uniforme de las reglas y una buena inferencia motor disponible, en realidad puede reducir la mano de obra total de la generacin de traera los casos de prueba, as como ayudar en el mantenimiento de toda la vida y la prueba de modificacin. De la misma manera, se puede postular otros asesores los probablemente muchos de ellos y simple, probablemente para el otras partes de la tarea de construccin de software. Muchas dificultades se interponen en el camino de la pronta realizacin de asesores expertos tiles para el programa de desarrollo. Una parte crucial de nuestro escenario imaginario es el desarrollo de fcil

maneras de conseguir a partir de las especificaciones del programa a la estructura automtica o semiautomtica generacin de normas de diagnstico. An ms difcil e importante es la doble tarea de la adquisicin de conocimientos: la bsqueda de articular, de auto-anlisis de expertos que saben por qu lo hacen las cosas, y desarrollo de tcnicas eficientes para la extraccin de lo que saben y destilarlo en las bases de reglas. El requisito esencial para la construccin de un sistema experto es tener un experto. La contribucin ms potente de los sistemas expertos que seguramente ser para poner al servicio del programador sin experiencia con la experiencia y sabidura acumulada de los mejores los programadores. Esto no es una pequea contribucin. La brecha entre el mejor software prctica de la ingeniera y la prctica media es muy amplia, tal vez ms amplia que en cualquier la disciplina de la ingeniera. Una herramienta que difunde buenas prcticas, sera importante. "Automtica" de programacin. Durante casi 40 aos, la gente ha estado esperando y escribir acerca de "programacin automtica", la generacin de un programa para resolver un problema de una declaracin de las especificaciones del problema. Algunas personas hoy en da escribir como si se espera que esta tecnologa para ofrecer el siguiente avance. 7 Parnas implica que el trmino es usado por el glamour y el contenido no semntica, afirmando, En resumen, la programacin automtica ha sido siempre un eufemismo para la programacin con un lenguaje de alto nivel que se dispone actualmente para el programador. 8 Argumenta, en esencia, que en la mayora de los casos es el mtodo de solucin, no del problema, cuya especificacin se ha de dar. 7 Mostow, op. cit. 8 Parnas, 1985, op. cit. Pgina 10 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 10 Las excepciones se pueden encontrar. La tcnica de construccin de los generadores es muy poderoso, y que se utiliza rutinariamente en una gran ventaja en los programas para la ordenacin. Algunos sistemas de

la integracin de ecuaciones diferenciales tambin han permitido la especificacin directa del problema. El sistema de evaluacin de los parmetros, elegir entre una biblioteca de mtodos de solucin, y generado los programas. Estas aplicaciones tienen propiedades muy favorables: Los problemas son fcilmente caracterizadas por parmetros relativamente pocos. Hay muchos mtodos conocidos de solucin para proporcionar una biblioteca de alternativas. Extenso anlisis ha dado lugar a normas explcitas para la seleccin de tcnicas de solucin, teniendo en cuenta parmetros del problema. Es difcil ver cmo estas tcnicas se generalizan al resto del mundo de lo comn sistema de software, donde los casos con tales propiedades ordenadas son la excepcin. Es difcil incluso imaginar cmo este avance en la generalizacin podra ocurrir. Programacin grfica. Un tema favorito para el doctorado tesis de software ingeniera grfica o visual, la programacin, la aplicacin de grficos de PC software de diseo. 9 A veces, la promesa de este enfoque se postula desde el analoga con el diseo de chips VLSI, en grficos de computadora juega un papel tan fructfero. A veces, el enfoque se justifica por diagramas de flujo considerando como el programa ideal medio del diseo, y proporcionar servicios de gran alcance para su construccin. Nada, incluso convincente, mucho menos emocionante, ha salido a la luz de tales esfuerzos. Yo estoy convencido de que nada lo har. En primer lugar, como he argumentado en otra parte, el diagrama de flujo es una abstraccin muy pobres de la estructura del software. 10 De hecho, es mejor visto como Burks, von Neumann y Goldstine intento de proporcionar una necesita desesperadamente lenguaje de alto nivel de control para su propuesta ordenador. En los mltiples lamentable, a la conexin en caja de forma que el flujo tabla ha sido elaborada hoy, que ha demostrado ser esencialmente intil como una herramienta de diseo programadores dibujar diagramas de flujo despus, no antes, la escritura de los programas que describen.

En segundo lugar, las pantallas de hoy en da son muy pequeas, en pxeles, para mostrar el alcance y la resolucin de cualquier esquema de software detallada graves. El llamado "escritorio metfora" de la estacin de trabajo de hoy es un lugar "avin-asiento" metfora. Cualquier persona que ha barajado un lapful de los documentos mientras se est sentado en un coche entre dos pasajeros corpulentos se reconoce la diferencia se puede ver slo una pocas cosas a la vez. El escritorio proporciona cierto y visin general de acceso aleatorio a una veintena de pginas. Por otra parte, cuando un ataque de ejecutar la creatividad fuerte, ms de un programador o el escritor ha sabido abandonar el escritorio para el piso ms espacioso. La tecnologa de hardware tendr que avanzar bastante sustancialmente antes de que el alcance de nuestra mbitos es suficiente para la tarea de diseo de software. Ms fundamentalmente, como he dicho antes, el software es muy difcil de visualizar. Ya sea que el diagrama de flujo de control, mbito de las variables de anidacin, la variable de referencias cruzadas, los datos golpe, estructuras de datos jerrquicos, o lo que sea, nos sentimos una sola dimensin de la intrincadamente entrelazadas elefante software. Si superponemos los diagramas generados por los puntos de vista relevantes muchos, es difcil extraer cualquier visin global. El VLSI 9 Raeder, G., "Un estudio de las tcnicas actuales de programacin grfica", en RB Grafton y T. Ichikawa, eds., nmero especial sobre Programacin Visual, Informtica, 18, 8 (agosto, 1985), pp 1125 10 Brooks 1995, op. cit., captulo 15. Pgina 11 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 11 analoga es fundamentalmente engaoso, un diseo de chip es en capas bidimensionales de objetos cuya geometra refleja su esencia. Un sistema de software no lo es. La verificacin del programa. Gran parte del esfuerzo en la programacin moderna entra en la prueba y reparacin de errores. Existe tal vez una bala de plata que se encuentran mediante la eliminacin de los errores en la fuente, en la fase de diseo del sistema? Puede la productividad y la fiabilidad del producto se mejorar radicalmente, siguiendo la estrategia profundamente diferente de los diseos de prueba correcta antes de que el inmenso esfuerzo que se vierte en la implementacin y prueba de ellos?

No creo que vamos a encontrar la magia aqu. Programa de verificacin es un programa muy potente concepto, lo cual ser muy importante para cosas tales como seguro de ncleos del sistema operativo. La tecnologa no promete, sin embargo, para ahorrar trabajo. Las verificaciones son mucho trabajo que slo un programas sustanciales pocos han sido verificados. Verificacin de programas no significa a prueba de errores de programas. No hay magia aqu, tampoco. Las pruebas matemticas tambin puede ser defectuoso. As, mientras que la verificacin puede reducir el programa de pruebas de carga, no puede eliminarlo. Ms en serio, ni siquiera la verificacin del programa perfecto slo puede demostrar que el programa de cumple con su especificacin. La parte ms difcil de la tarea de software es llegar a una completa y especificacin consistente, y gran parte de la esencia de la creacin de un programa es en realidad el depuracin de la especificacin. Entornos y herramientas. Cunto ms se puede esperar obtener de la explosin investigaciones en los entornos de programacin ms? Uno de reaccin instintiva es que la grandes problemas de rentabilidad fueron los primeros atacados, y se han resuelto: jerrquico de archivos sistemas, formatos de archivo uniforme a fin de tener interfaces de programa de uniforme y generalizada herramientas. Especficos del lenguaje editores inteligentes son desarrollos todava no estn generalizados en la prctica, pero lo ms que promesa es la ausencia de errores sintcticos y simples errores semnticos. Tal vez el mayor avance an no se ha realizado en el entorno de programacin es el uso de los sistemas de base de datos integrada para realizar un seguimiento de las miradas de detalles que deben ser record con precisin por el programador individual y mantenerse al da en un grupo de colaboradores en un solo sistema. Sin duda, este trabajo vale la pena, y seguramente va a tener un poco de fruta, tanto en la productividad y la fiabilidad. Pero por su propia naturaleza, el retorno a partir de ahora debe ser marginal. Estaciones de trabajo. Qu beneficios se esperan para el software de ltima generacin a partir de lo cierto y rpido aumento de la capacidad de potencia y la memoria de la estacin de trabajo individual? Bueno, cmo muchos MIPS se puede utilizar provechosamente? La composicin y edicin de programas y documentos es totalmente compatible con las velocidades de hoy. Compilacin poda soportar un impulso, pero un factor de 10 en la velocidad de la mquina seguramente dejara que los tiempos de la actividad dominante en el da del programador. De hecho, parece ser ahora. Estaciones de trabajo ms potentes que sin duda bienvenida. Mejoras mgicas de ellos

no podemos esperar. Pgina 12 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 12 Los ataques prometedores en la esencia conceptual A pesar de que no avance tecnolgico promete dar a la tecla de funcin de magia resultados con los que nos son tan familiares en el rea de hardware, que es a la vez una gran cantidad de buen funcionamiento sucediendo ahora, y la promesa de un progreso constante, si no espectacular. Todos los ataques tecnolgicos de los accidentes de los procesos de software son fundamentalmente limitada por la ecuacin de productividad: Tiempo de trabajo = (Frecuencia) yo x (tiempo) yo Si, como creo, los componentes conceptuales de la tarea que ahora estn tomando la mayora de los momento, ningn tipo de actividad en los componentes de trabajo que son meramente la expresin de los conceptos pueden dar grandes ganancias de productividad. Por lo tanto debemos tener en cuenta los ataques que se ocupan de la esencia del software problema, la formulacin de estas estructuras conceptuales complejas. Afortunadamente, algunos de los estos son muy prometedores. Comprar o construir. La solucin ms radical para la construccin de software no es construir en absoluto. Cada da esta ms fcil, ya que los vendedores cada vez ms ofrecer ms y mejores productos de software para una enorme variedad de aplicaciones. A pesar de que los ingenieros de software han trabajado en la metodologa de produccin, la revolucin del ordenador personal ha creado no una, sino m hay, los mercados de masas para el software. Cada quiosco lleva mensuales revistas que, ordenados por tipo de mquina, anunciar y revisar decenas de productos en los precios de unos pocos dlares a unos pocos cientos de dlares. Las fuentes ms especializadas ofrecen muy productos de gran alcance para la estacin de trabajo Unix y otros mercados. Incluso los peajes de software y ambientes se pueden comprar fuera de la plataforma. En otro lugar he propuesto una plaza de mercado para mdulos individuales. Cualquiera de estos productos es ms barato comprar que construir de nuevo. Incluso a un costo de $ 100.000,

compr un pedazo de software est costando slo tanto como un programador de aos. Y la entrega es inmediata! Inmediata, al menos para los productos que realmente existen, los productos cuyos desarrolladores pueden hacer referencia a la perspectiva de un usuario feliz. Por otra parte, estos productos tienden a mucho mejor documentado y mantenido un poco mejor que el software de cosecha propia. El desarrollo del mercado de masas es, creo, la ms profunda tendencia a largo plazo en ingeniera de software. El costo del software siempre ha sido el costo de desarrollo, no replicacin de los costos. Compartir los costos entre los que incluso unos pocos usuarios radicalmente cortes por usuario costos. Otra forma de verlo es que el uso de n copias de un sistema de software multiplica la productividad de sus desarrolladores por n. Que es una mejora del la productividad de la disciplina y de la nacin. La cuestin clave, por supuesto, es de aplicacin. Puedo utilizar una disposicin fuera de la plataforma de paquetes para hacer mi tarea? A lo sorprendente que ha ocurrido aqu. Durante los aos 1950 y 1960, el estudio despus de un estudio mostr que los usuarios no utilizar fuera de la plataforma de paquetes de nmina, inventario de control, cuentas por cobrar, etc Los requisitos eran demasiado especializados, el caso a caso variacin muy alta. Durante la dcada de 1980, nos encontramos con este tipo de paquetes de alta demanda y uso generalizado. Qu ha cambiado? En realidad, no los paquetes. Que puede ser algo ms generalizada y algo ms personalizable que antes, pero no mucho. En realidad, no las aplicaciones, ya sea. Si Pgina 13 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 13 nada, las necesidades empresariales y cientficos de hoy son ms diversas, ms complicado que los de hace 20 aos. El gran cambio ha sido en el hardware / costo del software. El comprador de un $ 2 millones de mquinas en 1960, senta que poda pagar $ 250.000 ms de una nmina personalizada programa, que se desliz con facilidad y sin interrupciones en el ordenador sociales hostiles el medio ambiente. Los compradores de mquinas de oficina $ 50.000 hoy en da no es concebible puede permitirse el lujo programas personalizados de nmina, por lo que adaptar sus procedimientos de nmina a los paquetes disponible. Los ordenadores son ahora tan comunes, aunque todava no tan querido, 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

los sistemas. Estas poderosas herramientas, tan obvio en retrospectiva ya la vez tan de aparicin tarda, prestar s a miles de usos, algunos de ellos muy poco ortodoxas. Los libros de artculos y hasta ahora abundan sobre cmo abordar las tareas inesperado con la hoja de clculo. Un gran nmero de aplicaciones que anteriormente hubiera sido escrito como programas a medida en el programa de Cobol o Informe Generador se hoy se usan rutinariamente con estas herramientas. Muchos usuarios ya operan sus propios ordenadores da a da en diversas aplicaciones sin tener que escribir un programa. De hecho, muchos de estos usuarios no pueden escribir nuevos programas para sus mquinas, sin embargo, son expertos en la solucin de nuevos problemas con ellos. Yo creo que la estrategia de software nico de la productividad ms potente para el hombre las organizaciones de hoy es para equipar a los trabajadores intelectuales ordenador ingenuo en la lnea de fuego con ordenadores personales y buena escritura generalizada, dibujo, archivo y hoja de clculo programas, y ellos a su vez suelto. La misma estrategia, con una programacin sencilla capacidades, tambin trabajo para cientos de cientficos de laboratorio. Refinamiento de requisitos y prototipado rpido. La parte ms difcil de la construccin de una sola sistema de software es decidir precisamente qu construir. Ninguna otra parte del trabajo conceptual es difcil establecer los requisitos tcnicos detallados, incluyendo todos los interfaces para la gente, a las mquinas, y otros sistemas de software. Ninguna otra parte de la trabajo paraliza el sistema resultante si se hace mal. No otra es ir ms difcil rectificar despus. Por lo tanto, la funcin ms importante que los fabricantes de software hacen por sus clientes es el iterativo de extraccin y refinamiento de los requisitos del producto. Porque la verdad es, la los clientes no saben lo que quieren. Por lo general, no saben qu preguntas deben ser respondi, y casi nunca han pensado en el problema en los detalles que deben ser especificada. Incluso la respuesta: "facilidad de uso hacen del nuevo software de sistema de trabajo como nuestro viejo manual de procesamiento de informacin del sistema ", es en realidad muy simple. Los clientes nunca quieren exactamente eso. Sistemas de software complejos, adems, son cosas que actan, que se mueven, que el trabajo. La dinmica de la accin que son difciles de imaginar. Por lo tanto en la planificacin de cualquier otro software actividad, es necesario para permitir una amplia iteracin entre el cliente y la de diseo como parte de la definicin del sistema. Yo ira un paso ms all y afirman que es realmente imposible para los clientes, incluso aquellos

trabajando con los ingenieros de software, para especificar completamente, precisamente, la exacta y correcta requisitos de un producto de software moderno antes de haber construido y probado algunas versiones de el producto que se especifica. Pgina 14 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 14 Por lo tanto, uno de los ms prometedores de los esfuerzos tecnolgicos actuales, y una que ataca la esencia no, los accidentes, de los problemas de software, es el desarrollo de los enfoques y herramientas para la creacin rpida de prototipos de sistemas como parte del proceso iterativo especificacin de requisitos. Un sistema de software prototipo que simula las interfaces importantes y realiza las funciones principales del sistema previsto, si bien no es necesariamente obligado por la velocidad del mismo hardware, el tamao o las limitaciones de costo. Los prototipos se realizan normalmente los las tareas de la lnea principal de la aplicacin, pero no hacen ningn intento para controlar las excepciones, responden correctamente a las entradas invlidas, abortar limpia, etc El objetivo del prototipo es hacer real de la estructura conceptual especfico, por lo que el cliente puede hacer la prueba de la consistencia y la facilidad de uso Mucho de lo que hoy los procedimientos de adquisicin de software se basa en el supuesto de que se puede especificar un sistema satisfactorio de antelacin, obtener ofertas para su construccin, se han construccin, e instalarlo. Creo que esta suposicin es un error fundamental, y que muchos la adquisicin de los problemas de software surgen de esa falacia. Por lo tanto no se puede arreglar sin una revisin fundamental, que prev el desarrollo iterativo y especificacin de los prototipos y productos. El desarrollo incremental - crecer, construir, no por software todava recuerdo la sacudida que se sinti en. 1958, cuando escuch por primera vez una charla amigo sobre la construccin de un programa, en lugar de escribir una. En un instante se ampli mi visin de conjunto del proceso de software. El cambio de metfora potente y preciso. Hoy en da entendemos como otros procesos como la construccin de la construccin de software, y utilizar libremente los dems elementos de la metfora, como especificaciones, montaje de componentes, y el andamio. La metfora del edificio ha sobrevivido a su utilidad. Es hora de cambiar de nuevo. Si, como yo

creen, las estructuras conceptuales que construimos hoy en da son demasiado complicados para ser precisa especificados de antemano, y demasiado complejos para ser incorporado sin problemas, entonces tenemos que tomar una radicalmente enfoque diferente. Volvamos a la naturaleza y la complejidad del estudio de los seres vivos, en lugar de los muertos obras del hombre. Aqu nos encontramos con construcciones cuyas complejidades emocin nosotros con respeto. El cerebro es el nico complejo ms all de la cartografa, de gran alcance ms all de la imitacin, rico en diversidad, la autola proteccin y la auto renovacin. El secreto es que ha crecido, no construido. Por lo tanto, debe ser con nuestros sistemas de software. Hace algunos aos Harlan Mills propuso que cualquier sistema de software debe ser cultivado por el desarrollo incremental. 11 Es decir, el sistema primero debe ser obligado a correr, a pesar de que no hace nada til, excepto llamar a un conjunto apropiado de subprogramas maniqu. Luego, poco a poco se concretarse, con los subprogramas a su vez se estn desarrollando en las acciones o las llamadas a los talones vaco en el nivel inferior. He visto los resultados ms dramticos desde que comenz a instar a esta tcnica en el los constructores del proyecto en mi clase de laboratorio de ingeniera de software. No hay nada en la ltima dcada ha cambiado radicalmente mi propia prctica, o su eficacia. El enfoque requiere diseo top-down, ya que es una de arriba hacia abajo cada vez mayor del software. Que permite una fcil dando marcha atrs. Se presta a los primeros prototipos. Cada funcin de agregado y la nueva disposicin de datos ms complejos o circunstancias crecido orgnicamente a partir de lo que ya existe. 11 Mills, de alta definicin, "de arriba hacia abajo en la programacin de grandes sistemas," tcnicas de depuracin en los grandes sistemas, R. Rustin, ed., Englewood Cliffs, NJ, Prentice-Hall, 1971. Pgina 15 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 15 Los efectos de la moral son alarmantes. El entusiasmo salta cuando hay un sistema en funcionamiento, incluso un simple. Redoblar los esfuerzos en la primera imagen de un nuevo software de grficos sistema aparece en la pantalla, incluso si es slo un rectngulo. Uno siempre tiene, en cada etapa del proceso, un sistema de trabajo. Me parece que los equipos pueden crecer mucho ms complejo

entidades en cuatro meses de lo que pueden construir. Los mismos beneficios que se pueden realizar en grandes proyectos como en mi los ms pequeos. 12 Los grandes diseadores. La cuestin central de cmo mejorar los centros de arte software, ya que siempre, en las personas. Podemos conseguir buenos diseos, siguiendo las buenas prcticas en lugar de los pobres. Bueno prcticas de diseo se puede ensear. Los programadores se encuentran entre la parte ms inteligente de los poblacin, para que puedan aprender las buenas prcticas. As, un mayor impulso en los Estados Unidos es promulgar una 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 pobre a buena. Esto es completamente correcto. 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 las buenas puede estar en el la solidez del mtodo de diseo, la diferencia entre los buenos diseos y los grandes sin duda no lo hace. Los grandes diseos provienen de grandes diseadores. La construccin de software es un creativo proceso. Una metodologa slida, puede potenciar y liberar a la mente creativa, no puede inflamar o inspirar a la esclava. Las diferencias no son menores-que es como Salieri y Mozart. Estudio tras estudio muestra que los mejores diseadores producen estructuras que son ms rpidos, ms pequeos, ms simples, ms limpio, y se producen con menos esfuerzo. Las diferencias entre los grandes y el promedio enfoque de un orden de magnitud. Un poco de retrospectiva muestra que aunque muchos sistemas bien, el software de utilidad que sido diseado por los comits y construido por los proyectos de varias partes, los sistemas de software que han entusiasmado a los aficionados apasionados son los que son producto de uno o unos pocos disear mente, los grandes diseadores. Considere la posibilidad de 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 No Unix Cobol APL PL / 1

Pascal Algol Modula MVS/370 Smalltalk MS-DOS Fortran Fig. 1 productos de gran inters Por lo tanto, a pesar de que apoyan la transferencia de tecnologa y plan de estudios los esfuerzos de desarrollo en curso, creo que el esfuerzo ms importante que puede montaje es desarrollar maneras de hacer crecer grandes diseadores. 12 Boehm, BW, "Un modelo de la espiral del desarrollo de software y mejora", ordenador, 20, 5 (mayo, 1985), pp 43-57. Pgina 16 F. Brooks: No Silver Bullet-Esencia y accidente en ingeniera de software (1986) 16 Ninguna organizacin de software se puede ignorar este reto. Buenos gestores, aunque escasos que sean, no son ms escasos que los buenos diseadores. Los grandes diseadores y gestores de grandes son a la vez muy raro. La mayora de las organizaciones de realizar un esfuerzo considerable en la bsqueda y el cultivo de la las perspectivas de gestin, no conozco ninguno que gasta el mismo esfuerzo en la bsqueda y desarrollo los grandes diseadores en los que la excelencia tcnica de los productos en ltima instancia, dependen. Mi primera propuesta es que cada organizacin de software debe determinar y proclamar que grandes diseadores son tan importantes para su xito como gestores de grandes son, y que se puede espera que sea similar alimentado y recompensado. No salariales, sino las prebendas de el reconocimiento de la oficina de tamao, mobiliario, equipo tcnico personal, fondos para viajes, personal de apoyo debe ser completamente equivalentes. Cmo hacer crecer los grandes diseadores? El espacio no permite una larga discusin, pero algunos los pasos son obvios:

Identificar sistemticamente a los diseadores lderes lo ms pronto posible. Los mejores son a menudo no con ms experiencia. Asignar un tutor de carrera para ser responsable del desarrollo de la perspectiva, y mantener un archivo de carrera con cuidado. Formular y aplicar un plan de desarrollo de carrera para cada candidato, incluyendo cuidado aprendizajes seleccionados con los mejores diseadores, los episodios de la educacin formal avanzada, y cursos de corta duracin, todos entremezclados con un diseo individual y la direccin tcnica asignaciones. Proporcionar oportunidades para que los diseadores cada vez mayor para interactuar con y estimularse mutuamente