No hay bala de plata: Esencia y accidentes de Ingeniería de Software

Frederick P. Brooks, Jr.

Fashioning construcciones conceptuales complejas es la esencia ;accidentales tareas aparecen en la representación de las construcciones en el lenguaje. Avances anteriores

han reducido tanto las tareas accidentales que el progreso futuro depende ahora de abordar la esencia.

De todos los monstruos que pueblan la pesadilla de nuestro folklore, ninguno aterrorice más de los hombres lobo, ya que transforman inesperadamente de lo familiar en horrores. Para estos, se busca balas de plata que puede mágicamente sentar a descansar.

El proyecto de software familiar, al menos como se ve por el administrador no técnico, tiene algo de este personaje, por lo general es inocente y sencillo, pero es capaz de convertirse en un monstruo de las planificaciones perdidas, presupuestos soplado y productos defectuosos. Así escuchamos gritos desesperados de una bala de plata - algo para que los costos de software caen tan rápidamente como los costos de hardware hacen.

Pero, al mirar tp el horizonte de una década, por lo tanto, no vemos ninguna bala de plata. No hay desarrollo único, ya sea en la tecnología o en la técnica de mananagement, que por sí mismo incluso promete una mejora de un orden de magnitud de la productividad, en la fiabilidad, en la simplicidad. En este artículo, voy a tratar de mostrar por qué, examinando tanto la naturaleza del problema del software y las propiedades de las balas propuestas.

El escepticismo no es pesimismo, sin embargo. Aunque no vemos avances sorprendentes - y, de hecho, creo que tal como incnsistent con la naturaleza del software - muchas innovaciones alentadoras están en marcha. A, el esfuerzo constante disciplinado para desarrollar, difundir y explotar estas innovaciones realmente debería producir una mejora de un orden de magnitud. No hay camino real, pero hay un camino.

El primer paso hacia el tratamiento de la enfermedad fue la sustitución de las teorías del demonio y humores teorías de la teoría de los gérmenes. Esa misma etapa, el comienzo de la esperanza, en sí mismo corriendo todas las esperanzas de soluciones mágicas. Se dijo a los trabajadores que se avance paso a paso, con gran esfuerzo, y que un persistente, incesante atención tendría que ser pagado a un disclipline de limpieza. Lo mismo sucede con la ingeniería de software hoy en día.

¿Tiene que ser difícil? - Dificultades Esenciales

No sólo no hay balas de plata ahora a la vista, la propia naturaleza del software hace que sea poco probable que haya alguna - no hay inventos que harán de la productividad del software, la fiabilidad y la sencillez lo que la electrónica, transistores, y la integración a gran escala hicieron por hardware del equipo. No podemos esperar que lleguemos a ver las ganancias de doble cada dos años.

En primer lugar, hay que observar que la anomalía no es que el progreso del software es muy lento, pero que el progreso material informático es tan rápido.Ninguna otra tecnología ya la civilización comenzó ha visto seis órdenes de magnitud en la ganancia de rendimiento-precio en 30 años. En ningún otro tipo de tecnología se puede optar por tomar la ganancia, ya sea en un mejor desempeño o en la reducción de costos. Estos flujo de ganancias a partir de la transformación de la fabricación de un ordenador en una industria de ensamblaje de la industria de procesos.

En segundo lugar, para ver qué grado de avance se puede esperar en la tecnología de software, vamos a examinar las dificultades de esa tecnología. Después de Aristóteles, los

divido en esencia, las dificultades inherentes a la naturaleza del software y los accidentes, las dificultades que hoy asisten a la producción, pero no son inherentes.

La esencia de una entidad de software es una construcción de los conceptos entrelazados: los conjuntos de datos, las relaciones entre los elementos de datos, algoritmos, y las invocaciones de funciones. Esta esencia se resumen en que tal construcción conceptual es el mismo en muchas representaciones diferentes. Sin embargo, es altamente preciso y rico en detalles.

Creo que la parte más difícil de la construcción de software para ser la especificación, diseño y ensayo de este constructo conceptual, no es el trabajo de representar y probar la fidelidad de la representación.

Todavía cometemos errores de sintaxis, sin duda, pero son demasiadas complicaciones en comparación con los errores conceptuales en la mayoría de los sistemas. Si esto es cierto, la construcción de software siempre va a ser difícil. No es de por sí hay una fórmula mágica.

Vamos a considerar las propiedades inherentes de esta esencia irreducible de los sistemas de software moderno: la complejidad, la conformidad, la mutabilidad y la invisibilidad.

Complejidad

Entidades de software son más complejos por su tamaño que quizás cualquier otra construcción humana, porque no hay dos piezas iguales (al menos por encima del nivel de los estados). Si es así, hacemos las dos partes similares en una subrutina - abierto o cerrado. En este sentido, los sistemas de software difieren profundamente de los ordenadores, edificios o automóviles, donde abundan los elementos repetidos.

Computadoras digitales son de forma más compleja de lo que la mayoría de cosas que las personas construyen: Tienen gran número de estados. Esto hace concebir, describir y probar con fuerza. Los sistemas de software tienen órdenes de magnitud más estados que las computadoras hacen.

Del mismo modo, una ampliación de una entidad de software no es meramente la repetición del mismo elemento en tamaños más grandes, que es necesariamente un aumento en el número de diferentes elementos. En la mayoría de los casos, los elementos interactúan unos con otros de alguna manera no lineal, y la complejidad del conjunto aumenta mucho más que linealmente.

La complejidad de software es una propiedad esencial, no una accidentales. Por lo tanto, la descripción de una entidad software que abstrae la complejidad a menudo abstraer su esencia. Durante tres siglos, las matemáticas y las ciencias físicas hicieron grandes avances en la construcción de modelos simplificados de fenómenos complejos, las propiedades de los modelos derivados, y la verificación de las propiedades mediante experimentos. Este paradigma funcionó porque las complejidades ignorados en los modelos no eran las propiedades esenciales de los fenómenos. No funciona cuando la complejidad es la esencia.

Muchos de los problemas clásicos de desarrollo de productos de software se derivan de esta complejidad esencial y sus no lineales aumenta con el tamaño. De la complejidad viene de la dificultad de comunicación entre los miembros del equipo, lo que conduce a defectos del producto, los sobrecostos, retrasos en el programa. De la complejidad viene la dificultad de enumerar, mucho menos comprensión, todos los estados posibles del programa, y de que vienen de la falta de fiabilidad. A partir de la complejidad de la función viene la dificultad de la invocación de la función, lo que hace que los programas sean difíciles de usar. De la complejidad de la estructura viene la dificultad de extender los programas a las nuevas funciones sin crear efectos secundarios. De la complejidad de la estructura vienen los estados unvisualized que constituyen trampas de seguridad.

No sólo los problemas técnicos, pero los problemas de gestión, así vienen de la complejidad. Hace panorama duro, impidiendo así la integridad conceptual. Esto hace que sea difícil de encontrar y controlar todos los cabos sueltos. Se crea la tremenda lerarning y comprensión carga que hace que la rotación de personal de un desastre.

Conformidad

La gente de software no son los únicos que enfrenta la complejidad. Física tratar con objetos tremendamente complejos, incluso a nivel de partículas "fundamentales". El trabajo físico, sin embargo, en una fe firme de que hay principios unificadores que se encuentran, ya sea en los quarks o en las teorías unificadas de campo. Einstein sostuvo que no se debe simplificar las explicaciones de la naturaleza, porque Dios no es caprichoso o arbitrario.

Sin esta fe consuela el ingeniero de software. Gran parte de la complejidad que tiene que dominar es la complejidad arbitraria, forzada y sin ton ni son por las muchas instituciones humanas y sistemas para que sus interfaces deben ajustarse. Estos difieren de interfaz para la interfaz, y de vez en cuando, no por necesidad, pero sólo porque fueron diseñados por diferentes personas, en lugar de por Dios.

En muchos casos, el software debe conformarse, porque es la más reciente llegada a la escena. En otros, se debe cumplir, ya que se percibe como el más adaptable. Pero en todos los casos, tanto la complejidad proviene de conformación a otras interfaces; esta complejidad no se puede simplificar a cabo por un rediseño del software por sí solo.

Variabilidad

La entidad de software es constantemente objeto de presiones para el cambio. Por supuesto, por lo que están construyendo, los coches, los ordenadores. Pero las cosas están manufacturados con poca frecuencia cambian después de la fabricación, sino que son reemplazados por modelos más tarde, o cambios esenciales se incorporan a las copias en serie de números posteriores del mismo diseño básico. Call-Back para automóviles son muy poco frecuentes, cambios en el campo de los ordenadores un poco menos. Ambos son mucho menos frecuentes que las modificaciones de software alineado.

En parte, este modo porque el software de un sistema encarna su función, y la función es la parte que más se siente las presiones del cambio. En parte se debe a que el software se puede cambiar más fácilmente - es pura materia pensamiento, infinitamente maleable. Edificios de hecho se cambian, pero los altos costos de cambio, entendida por todos, sirven para amortiguar los caprichos de los que cambiaban.

Todo el software con éxito se cambia. Dos procesos son en el trabajo. En primer lugar, tal como se encuentra un producto de software para ser útil, la gente intenta en nuevos casos en el borde o más allá del dominio original. Las presiones para la función ampliada vienen principalmente de los usuarios que les gusta la función básica e inventar nuevos usos para ella.

En segundo lugar, el software de éxito sobrevive más allá de la vida normal del vehículo, equipo para el que está escrito primero. Si no nuevas computadoras, entonces al menos discos nuevos, nuevas pantallas, impresoras nuevas vienen a lo largo, y el software debe acomodarse a sus nuevos vehículos de ocasión.

En definitiva, el producto de software está integrado en una matriz cultural de aplicaciones, los usuarios, las leyes, y los vehículos de la máquina. Todos ellos cambian continuamente, y sus cambios obligan inexorablemente cambios en el producto de software.

Invisibilidad

El software es invisible y unvisualizable. Abstracciones geométricas son herramientas poderosas. La planta de un edificio de ayuda tanto arquitecto y el cliente evalúan espacios,

flujos de tráfico, vistas. Las contradicciones y omisiones se vuelven obvias. Dibujos a escala de las partes mecánicas y modelos de figuras de palo de moléculas, aunque abstracciones, tienen el mismo propósito. Una realidad geométrica es capturado en una abstracción geométrica.

La realidad de software no está inherentemente incrustado en el espacio. Por lo tanto, no tiene representación geométrica preparados en la forma en que la tierra tiene mapas, fichas sillicon tienen diagramas, las computadoras tienen esquemas de conectividad. Tan pronto como tratamos de estructura de software gráfico, nos encontramos con que se constituya no sólo una, sino varias gráficas, dirigida generales superpuestas una sobre otra. Los varios gráficos pueden representar el flujo de control, el flujo de datos, los patrones de dependencia, secuencia Tiem, las relaciones de espacio de nombres. Estos gráficos son por lo general ni siquiera plana, mucho menos jerárquica. En efecto, una de las maneras de establecer el control conceptual sobre dicha estructura es hacer cumplir de corte hasta que enlace uno o más de los gráficos se convierte jerárquica [1].

A pesar de los avances en la restricción y la simplificación de las estructuras de software, siguen siendo intrínsecamente unvisualizable, y por lo tanto no permiten a la mente para utilizar algunos de sus más poderosas herramientas conceptuales.Esta falta no sólo impide el proceso de diseño dentro de un mismo sentir, que dificulta gravemente la comunicación entre las mentes.

Los avances anteriores resuelven dificultades accidentales

Si examinamos los tres pasos en el desarrollo de software de tecnología que han sido más fructífera en el pasado, descubrimos que cada atacaron una gran dificultad diferente en la creación de software, pero que esas dificultades han sido accidental, no esencial, dificultades. También podemos ver los límites naturales a la extrapolación de cada uno de esos ataques.

Lenguajes de alto nivel

Sin duda, el más poderoso golpe de la productividad del software, confiabilidad y simplicidad ha sido la progresiva utilización de lenguajes de alto nivel para la programación. La mayoría de los observadores de crédito que el desarrollo de al menos un factor de cinco en la productividad, y con aumentos concomitantes en la fiabilidad, simplicidad y comprensibilidad.

¿Qué quiere lograr un lenguaje de alto nivel? Se libera un programa de gran parte de su complejidad accidental. Un programa abstracto formado por construcciones conceptuales: operaciones, tipos de datos, las secuencias y la comunicación. El programa de la máquina concreta se refiere a los bits, los registros, las condiciones, las ramas, los canales, los discos, y tal. En la medida en que el lenguaje de alto nivel representa las construcciones que uno quiere en el programa abstracto y evita todos los inferiores, que elimina todo un nivel de complejidad que no era inherente en el programa en absoluto.

Lo más que un lenguaje de alto nivel puede hacer es presentar todas las construcciones que se representa el programador en el programa abtract. Sin duda, el nivel de nuestra manera de pensar acerca de las estructuras de datos, tipos de datos y operaciones va en constante aumento, pero a un ritmo cada vez menor. Y el desarrollo del lenguaje se acerca más y más a la sofisticación de los usuarios.

Por otra parte, en algún momento de la elaboración de un lenguaje de alto nivel crea una carga de herramientas maestría que aumenta, no disminuye, la tarea intelectual de los usuarios que rara vez utiliza las construcciones esotéricas.

Tiempo compartido

Tiempo compartido trajo una mejora importante en la productividad de los programadores y de la calidad de sus productos, aunque no tan grande como el interpuesto por lenguajes de alto nivel.

Tiempo compartido ataca una dificultad muy diferente. Tiempo compartido conserva inmediatez, y por lo tanto permite a uno mantener una visión de la complejidad. El lento turaround de programación por lotes significa que uno se olvida de invevitably las minucias, si no el mismo empuje, de lo que se pensaba cuando se detuvo la programación y la llama de la elaboración y ejecución. Esta interrupción es costosa en tiempo, pues hay que refrescar la memoria. El efecto más grave y puede ser la decadencia de la comprensión de todo lo que está pasando en un sistema complejo.

Respuesta lenta, como la complejidad de lenguaje de máquina, es un accidente y no una dificultad esencial del proceso de software. Los límites de la contribución potencial de tiempo compartido se derivan directamente. El efecto principal de tiempo compartido es acortar el tiempo de respuesta del sistema. Como este tiempo de respuesta va a cero, en algún momento se pasa el umbral de perceptibilidad humana, alrededor de 100 milisegundos. Más allá de este umbral, no hay beneficios son de esperar.

Estados Programación Entornos

Unix y Interlisp, los primeros entornos de programación integrados para entrar en uso generalizado, parecen tener una mayor productividad por factores integrales.¿Por qué?

Atacan las dificultades accidentales que resultan del uso de los programas individuales juntas , proporcionando bibliotecas integradas, formatos de archivos unificados y tuberías y filtros. Como resultado, las estructuras conceptuales que, en principio, siempre se podía llamar, alimentar, y el uso de los otros puede hacer fácilmente, así que de hecho en la práctica.

Este avance a su vez estimula el desarrollo de toolbenches enteros, puesto que cada nueva herramienta podría aplicarse a todos los programas que utilizan los formatos estándar.

Debido a estos éxitos, el medio ambiente son objeto de gran parte de la investigación de ingeniería de software de hoy en día. Nos fijamos en su promesa y limitaciones en la siguiente sección.

Las esperanzas de la Plata

Ahora vamos a considerar los avances técnicos que más a menudo se adelantan como posibles soluciones mágicas. ¿Qué problemas se dirigen - los problemas de la esencia o las dificultades accidentales restantes? ¿Ofrecen avances revolucionarios, o los incrementales?

Ada y otros avances lenguaje de alto nivel

Uno de los más recientes acontecimientos promocionado es Ada, un lenguaje de propósito general de alto nivel de la década de 1980. Ada no sólo refleja las mejoras evolutivas en los conceptos del lenguaje, pero en realidad incluye características para fomentar el diseño moderno y la modularización. Tal vez la filosofía Ada es más de un anticipo que el lenguaje Ada, ya que es la filosofía de la modularización, de los tipos abstractos de datos, de estructuración jerárquica. Ada es más rica, un resultado natural del proceso por el cual los requisitos fueron puestos sobre su diseño. Eso no es fatal, para vocabularios de trabajo agrupada pueden resolver el problema de aprendizaje, y los avances de hardware nos dará las MIPS económicos para pagar los costos de compilación. Promover la estructuración de los sistemas de software es de hecho un muy buen uso de la mayor MIPS nuestro dinero va a comprar. Los sistemas operativos, fuertemente denunciadas en 1960 por su memoria y los costes del ciclo, han demostrado ser una excelente forma en la que utilizar algunos de los MIPS y bytes de memoria más barato de la última oleada de hardware.

Sin embargo, Ada no resultará ser la bala de plata que mata al monstruo de la productividad del software. Es, después de todo, sólo un lenguaje de alto nivel, y la mayor rentabilidad de estas lenguas llegó a la primera transición - la transición a partir de la complejidad accidental de la máquina en el estado más abstracto de soluciones paso a paso. Una vez que los accidentes se han eliminado, los restantes serán menores, y la recompensa de su retiro que seguramente será menos.

Mi predicción es que dentro de una década, cuando se evaluará la eficacia de Ada, se ve que han hecho una diferencia sustancial, pero no por ninguna característica del lenguaje en particular, ni tampoco a causa de todos ellos juntos. Tampoco serán los nuevos entornos Ada llegar a ser la causa de las mejoras. La mayor contribución de Ada será que el cambio a que los programadores de formación ocasionados en las técnicas de software de diseño moderno.

Programación orientada a objetos

Muchos estudiosos de la materia tienen más esperanza para la programación orientada a objetos que para otros caprichos técnicos del día [2]. Yo estoy en medio de ellos. Marcos Sherman de notas Dartmouth en CSnet News que uno debe tener cuidado de distinguir dos ideas separadas que van con ese nombre:tipos abstractos de datos y tipos jerárquicos . El concepto de tipo abstracto de datos es el de un tipo de objeto debe ser definido por un nombre, un conjunto de valores propios, y un conjunto de operaciones propias en lugar de por su estructura de almacenamiento que debe ser ocultado. Ejemplos de ello son los paquetes Ada (con tipos particulares) y los módulos de Modula.

Tipos jerárquicas, como las clases de Simula-67, le permiten a uno para definir las interfaces generales que pueden ser aún más refinada, proporcionando tipos subordinados. Los dos conceptos son ortogonales - uno puede tener jerarquías sin esconder y ocultar sin jerarquías. Ambos conceptos representan avances reales en el arte de la construcción de software.

Cada quita todavía otra dificultad accidental del proceso, que permite al diseñador para expresar la esencia del diseño sin tener que expresar grandes cantidades de material sintáctica que no añaden ningún contenido de información. Para ambos tipos abstractos y tipos jerárquicos, el resultado es para eliminar una especie de orden superior de dificultad accidental y permitir que un espression de orden superior de diseño.

Sin embargo, como se puede hacer nada más que para eliminar todas las dificultades accidentales de la expresión del diseño. La complejidad del diseño en sí mismo es esencial, y este tipo de ataques hacer ningún cambio en lo que. Un aumento de un orden de magnitud se puede hacer mediante la programación orientada a objetos únicamente si la maleza tipo de especificación innecesaria todavía en nuestro lenguaje de programación es en sí misma nueve décimas partes de las tareas realizadas en el diseño de un producto de programa. Lo dudo.

Inteligencia artificial

Muchas personas esperan avances en inteligencia artificial para proporcionar el avance revolucionario que le dará ganancias de un orden de magnitud en la productividad y la calidad del software [3]. No lo hago. Para ver por qué, debemos analizar qué se entiende por "inteligencia artificial".

DL Parnas ha aclarado el caos terminológico [4]:

Dos definiciones muy diferentes de AI son de uso común hoy en día. AI-1: El uso de las computadoras para resolver problemas que antes sólo podían ser resueltos mediante la aplicación de la inteligencia humana. AI-2: El uso de un conjunto específico de técnicas de programación que se conoce como heurística o programación basada en reglas. En este enfoque, los expertos humanos son estudiados para determinar qué heurísticas o reglas generales que utilizan en la solución de problemas ... El programa

está diseñado para resolver un problema en la forma en que los seres humanos parecen resolverlo. La primera definición tiene un significado deslizante ... Algo que puede ajustarse a la definición de la IA-1 hoy, pero, una vez que vea cómo funciona el programa y entender el problema, no vamos a pensar en él como AI más ... Lamentablemente no puedo identificar un conjunto de tecnologías que es único en este campo ... La mayor parte del trabajo es un problema específico y se requiere una abstracción o la creatividad para ver cómo transferirlo.

Estoy completamente de acuerdo con esta crítica. Las técnicas utilizadas para el reconocimiento de voz parecen tener poco en común con los utilizados para el reconocimiento de imágenes, y ambos son diferentes de los utilizados en los sistemas expertos. Tengo un tiempo difícil ver cómo el reconocimiento de imágenes, por ejemplo, hará que una diferencia apreciable en la práctica de programación. El mismo problema es el caso de reconocimiento de voz. Lo difícil acerca de la construcción de software es decidir lo que se quiere decir, no lo dice.No ayuda a la expresión puede dar más que ganancias marginales.

Tecnología de sistemas expertos, AI-2, se merece una sección propia.

Sistemas Expertos

La parte más avanzada de la inteligencia artificial, y la más ampliamente aplicada, es la tecnología para la construcción de sistemas expertos. Muchos científicos de software están trabajando duro en la aplicación de esta tecnología en el entorno de software de capacidad [3,5]. ¿Cuál es el concepto, y cuáles son las perspectivas?

Un sistema experto es un programa que contiene un motor de inferencia generalizada y una base de reglas, toma los datos y supuestos, explora las consecuencias derivables de la base de reglas, ofrece conclusiones y recomendaciones, y ofrece para explicar sus resultados por volver sobre sus motivos para el usuario . El motor de inferencia típicamente puede tratar con datos y reglas difusas o probabilístico, además de la lógica puramente determinista.

Estos sistemas ofrecen algunas ventajas claras sobre los algoritmos programados diseñados para llegar a las mismas soluciones a los mismos problemas:

Tecnología de Inferencia-motor se desarrolla de una manera independiente de la aplicación, y luego se aplica a muchos usos. Uno puede justificar tanto esfuerzo en los motores de inferencia. En efecto, que la tecnología está muy avanzada.

Las partes variables de los materiales de aplicación peculiares están codificados en la base de reglas de una manera uniforme, y se proporcionan herramientas para el desarrollo, el cambio, prueba y documentación de la base de reglas. Esta regulariza gran parte de la complejidad de la aplicación en sí.

El poder de este tipo de sistemas no proviene de mecanismos de inferencia siempre lujosos, sino de bases cada vez más ricos conocimientos que reflejan el mundo real más precisa. Creo que el avance más importante que ofrece esta tecnología es la separación de la complejidad de la aplicación desde el propio programa.

¿Cómo puede esta tecnología puede aplicar a la tarea de ingeniería de software?En muchos sentidos: Estos sistemas pueden sugerir reglas de interfaz, asesorar sobre estrategias de ensayo, recordar las frecuencias de tipo insecto, y ofrecen consejos de optimización.

Considere la posibilidad de un asesor prueba imaginaria, por ejemplo. En su forma más rudimentaria, el sistema experto de diagnóstico es como lista de control de piloto, simplemente enumerando sugerencias en cuanto a las posibles causas de dificultades. A medida que más y más la estructura del sistema se materializa en la base de reglas, y como la base de reglas lleva más sofisticada en cuenta los síntomas de problemas reportados, el asesor de prueba se vuelve más y más en particular en las unas hipótesis que genera y las pruebas que recomienda. Tal un sistema experto puede apartarse más radicalmente de los convencionales en que su base de reglas probablemente debería ser jerárquicamente modularizado de la misma manera el producto de software correspondiente es, por lo que a medida que el producto es modificado de forma modular, la regla de diagnóstico puede ser modificada modularmente, así .

El trabajo necesario para generar las reglas de diagnóstico es un trabajo que tendría que ser hecho de todos modos en la generación del conjunto de casos de prueba para los módulos y para el sistema. Si esto se hace de manera general adecuado, tanto con una estructura uniforme de las normas y buena motor de inferencia disponibles, que en realidad puede reducir la mano de obra total de la generación de traer-hasta casos de prueba, y ayudar así con el mantenimiento de toda la vida y de pruebas de modificación. De la misma manera, se puede postular otros asesores, probablemente muchos y probablemente sencilla, para las otras partes de la tarea de software-construcción.

Muchas dificultades se interponen en el camino de la pronta realización de útiles asesores expertos del sistema para el desarrollador del programa. Una parte crucial de nuestro escenario imaginario es el desarrollo de formas fáciles de obtener a partir de las especificaciones del programa-estructura para la generación automática o semiautomática de reglas de diagnóstico. Aún más difícil e importante es la doble tarea de adquisición de conocimientos: búsqueda de expertos de análisis articulados, uno mismo que saben por qué hacen las cosas, y el desarrollo de técnicas eficientes para la extracción de lo que saben y de destilación en bases de reglas. La condición esencial para la construcción de un sistema experto es tener un experto.

La más poderosa contribución de los sistemas expertos que seguramente será poner al servicio del programador sin experiencia la experiencia y la sabiduría acumulada de los mejores programadores. Esto no es una pequeña contribución.La brecha entre las mejores prácticas de ingeniería de software y la práctica media es muy amplia - tal vez mayor que en cualquier otra disciplina de la ingeniería. Una herramienta que difunde buenas prácticas sería importante.

Programación "Automatic"

Durante casi 40 años, la gente ha estado esperando y escribiendo sobre "programación automática", o la generación de un programa para resolver un problema de una declaración de las especificaciones del problema. Algunos hoy escribir como si esperan que esta tecnología para proporcionar la siguiente avance [5].

Parnas [4] implica que el término se utiliza para el glamour, no por contenido semántico, afirmando:

En resumen, la programación automática ha sido siempre un eufemismo para la programación con un lenguaje de alto nivel que se dispone actualmente para el programador.

Sostiene, en esencia, que en la mayoría de los casos, es el método de solución, no del problema, cuya especificación tiene que ser determinado.

Uno puede encontrar excepciones. La técnica de construcción de los generadores es muy potente, y se utiliza de forma rutinaria en una gran ventaja en los programas de selección. Algunos sistemas para la integración de las ecuaciones diferenciales también han

permitido especificación directa del problema, y los sistemas han evaluado los parámetros, elegido a partir de una biblioteca de métodos de solución, y los programas generados.

Estas aplicaciones tienen propiedades muy favorables:

Los problemas se caracterizan fácilmente por relativamente pocos parámetros.

Hay muchos métodos conocidos de solución para proporcionar una biblioteca de alternativas.

Un amplio análisis ha dado lugar a normas explícitas para la selección de técnicas de solución de problemas, los parámetros dados.

Es difícil ver cómo estas técnicas se generalizan al resto del mundo del sistema de software común, donde los casos con tales propiedades ordenadas son la excepción. Es difícil de imaginar cómo podría ocurrir este gran avance en la generalización.

Programación Gráfica

Un tema favorito de tesis doctorales en ingeniería de software es gráfico o visual, programación - la aplicación de los gráficos de computadora para el diseño de software [6,7]. A veces, la promesa que por este enfoque se postula con una analogía con el diseño de chips VLSI, en el que los gráficos por ordenador juegan un papel tan fructífera. A veces, el teórico que justifica el enfoque al considerar diagramas de flujo como el medio de programas de diseño ideal y proporcionando instalaciones poderosas para la construcción de ellos.

Nada siquiera convincente, mucho menos emocionante, pero ha surgido de tales esfuerzos. Estoy persuadido de que nada lo hará.

En primer lugar, como he argumentado en otra parte [8], el diagrama de flujo es una muy mala abstracción de la estructura del software. De hecho, se ve mejor como Burks, von Neumann, y el intento de Goldstine para proporcionar un lenguaje de control de alto nivel que necesita desesperadamente para su equipo propuesto. En el, varias páginas, forma de conexión en caja lamentable que el organigrama actual se ha elaborado, se ha demostrado ser inútil como una herramienta de diseño - programadores dibujar diagramas de flujo después, no antes, escribir los programas que describen.

En segundo lugar, las pantallas de hoy en día son demasiado pequeñas, en píxeles, para mostrar tanto el alcance como la resolución de cualquier diagrama detallado grave software. La denominada "metáfora de escritorio" de estación de trabajo de hoy es más bien una metáfora "avión-asiento". Cualquier persona que ha barajado una vuelta completa de los documentos mientras se está sentado entre dos pasajeros corpulentos reconocerá la diferencia - se puede ver sólo unas pocas cosas a la vez. El verdadero escritorio proporciona panorama general y un acceso aleatorio a una veintena de páginas. Por otra parte, cuando se ajusta la creatividad son fuertes, más de un programador o un escritor se ha conocido a abandonar el escritorio para el más amplio piso. La tecnología de hardware tendrá que avanzar de forma sustancial antes de que el alcance de nuestros ámbitos es suficiente para la tarea de software-diseño.

Más fundamentalmente, como he señalado anteriormente, el software es muy difícil de visualizar. Si un flujo de control de diagramas, variable alcance de anidación, variable de referencias cruzadas, flujo de datos, estructuras de datos jerárquicos, o lo que sea, se siente

sólo una dimensión del elefante software intrincadamente entrelazada. Si se superpone todos los diagramas generados por los muchos puntos de vista relevantes, es difícil extraer cualquier visión global. La analogía VLSI es fundamentalmente engañoso - un diseño de chip es una descripción de dos dimensiones en capas cuya geometría refleja su realización en el espacio de 3 dimensiones. Un sistema de software no lo es.

Programa de Verificación

Gran parte del esfuerzo en la programación moderna entra en prueba y reparación de errores. ¿Existe tal vez una bala de plata que se encuentran al eliminar los errores en la fuente, en la fase de diseño del sistema? ¿Puede la productividad y la fiabilidad del producto será radicalmente mejorada siguiendo el profundamente diferente estrategia de probar diseños correctos antes de que el inmenso esfuerzo se vierte en la implementación y prueba de ellos?

No creo que vamos a encontrar la magia de la productividad aquí. Programa de verificación es un concepto muy poderoso, y que será muy importante para tal cosa como la seguridad núcleos del sistema operativo. La tecnología no promete, sin embargo, para ahorrar mano de obra. Las verificaciones son mucho trabajo que se han verificado siempre sólo unos pocos programas importantes.

Programa de verificación no significa programas de prueba de errores. No hay magia aquí, tampoco. Pruebas matemáticas también pueden estar defectuosos.Así que el control puede reducir la carga de la programación de pruebas, no puede eliminarlo.

Más en serio, incluso la verificación programa perfecto sólo puede demostrar que el programa cumple con su especificación. La parte más difícil de la tarea de software está llegando a una especificación completa y consistente, y gran parte de la esencia de la construcción de un programa, de hecho, la depuración de la especificación.

Entornos y herramientas

¿Cuánto se puede esperar más de ganancia de las investigaciones de la explosión en mejores entornos de programación? De una reacción instintiva es que los problemas de gran rentabilidad - sistemas de archivos jerárquicos, formatos de archivo uniformes para hacer posibles interfaces de programa de uniformes y herramientas generalizadas - fueron el primer ataque, y han sido resueltos. Editores inteligentes específicos del idioma son avances aún no se utiliza ampliamente en la práctica, pero la mayoría de ellos prometen es la ausencia de errores sintácticos y errores semánticos simples.

Tal vez el mayor beneficio aún no se ha dado cuenta de entornos de programación es el uso de sistemas de bases de datos integradas para realizar un seguimiento de la gran cantidad de detalles que hay que recordar con precisión por el programador individual y se mantienen en curso para un grupo de colaboradores en un solo sistema.

Sin duda, este trabajo vale la pena, y seguramente va a dar frutos en la productividad y la fiabilidad. Pero, por su propia naturaleza, el regreso a partir de ahora debe ser marginal.

Estaciones de Trabajo

¿Qué ganancias son de esperar para la técnica de software desde cierta y rápido aumento de la capacidad de potencia y la memoria de la estación de trabajo individual? Bueno, ¿cuántos MIPS se puede utilizar provechosamente? La composición y edición de programas y documentos es totalmente compatible con velocidades de hoy en día. Compilar podía soportar un impulso, sino un factor de 10 en la velocidad de la máquina, sin duda, dejar pensar a tiempo la actividad dominante en el día del programador. De hecho, parece ser ahora.

Workstation más poderosa que sin duda bienvenida. Mejoras mágicas de ellos no pueden esperar.

Los ataques prometedores en la esencia conceptual

A pesar de que no avance técnico se compromete a dar la clase de resultados mágicos que nos son tan familiares en el área de hardware, no es tanto una gran cantidad de buen trabajo pasando ahora, y la promesa de equilibrio, si el progreso espectacular.

Todos los ataques tecnológicos de los accidentes del proceso del software están fundamentalmente limitados por la ecuación de la productividad:

Si, como creo, los componentes conceptuales de la tarea que están tomando la mayor parte del tiempo, entonces ninguna cantidad de actividad de los componentes de tareas que no son más que la expresión de los conceptos puede dar grandes ganancias de productividad.

Por lo tanto, debemos tener en cuenta los ataques que se ocupan de la esencia del problema de software, la formulación de estas estructuras conceptuales complejas.Afortunadamente, algunos de estos ataques son muy prometedores.

Compre frente Construir

La solución más radical posible fro construir software no es construir en absoluto.

Cada día esto se vuelve más fácil, ya que cada vez más proveedores ofrecen más y mejores productos de software para una vertiginosa variedad de aplicaciones.Mientras nosotros, los ingenieros de software han trabajado en la metodología de producción, la revolución de las computadoras personales ha creado no uno, sino muchos, los mercados masivos de software. Cada quiosco lleva revistas mensuales, según tipo de máquina, publicidad y revisar decenas de productos a un precio de unos pocos dólares a unos pocos cientos de dólares. Fuentes más especializadas ofrecen productos muy potentes para la estación de trabajo y en otros mercados de Unix. Incluso las herramientas y entornos de software se pueden comprar fuera de la plataforma. He propuesto en otro lugar un mercado para los módulos individuales [9].

Cualquier producto es más barato comprar que construir de nuevo. Incluso a un costo de cien mil dólares, una pieza de software comprado cuesta sólo alrededor tanto como un programador años. Y ofrecer es inmediato! Inmediata, al menos, para los productos que realmente existen, productos cuyos desarrollador puede consultar los productos a un usuario feliz. Por otra parte, estos productos tienden a ser mucho mejor documentado y mantenido un poco mejor que el software de cosecha propia.

El desarrollo del mercado de masas es, creo, la más profunda tendencia a largo plazo en la ingeniería de software. El costo del software siempre ha sido el coste de desarrollo, no cuesta replicación. Compartir ese costo, incluso entre algunos usuarios corta radicalmente el costo por usuario. Otra forma de verlo es que el uso de n copias de un sistema de software multiplica efectivamente la productividad de sus desarrolladores por n . Eso es una mejora de la productividad de la disciplina y de la nación.

La cuestión clave, por supuesto, es de aplicación. ¿Puedo utilizar un paquete off-the-shelf disponible para realizar mi tarea? Algo sorprendente ha sucedido aquí.Durante los años 1950 y 1960, estudio tras estudio muestra que el usuario no utilice paquetes off-the-shelf de nómina, control de inventarios, cuentas por cobrar, etc. Los requisitos eran demasiado especializados, la variación caso por caso demasiado alto. Durante la década de 1980, nos encontramos con este tipo de paquetes en alta demanda y uso generalizado. ¿Qué ha cambiado?

No los paquetes, de verdad. Ellos pueden ser algo más generalizado y algo más personalizable que en otro tiempo, pero no mucho. No las aplicaciones, ya sea. En todo caso, las necesidades de las empresas y científicos de hoy en día son más diversos y complicados que los de hace 20 años.

El gran cambio ha sido en el ratio de eficiencia del hardware / software. En 1960, el comprador de una máquina de dos millones de dólares sentía que él podía pagar 250.000 dólares más para un programa de nómina personalizada, que se deslizó con facilidad un sin interrupciones en el entorno social hostil ordenador. Hoy en día, el comprador de una máquina de oficina $ 50,000 no puede permitirse concebir un programa de nómina personalizada, por lo que se adapta el procedimiento de la nómina de los paquetes disponibles. Las computadoras son ahora tan común, si no es sin embargo tan querida, que las adaptaciones se aceptan como algo natural.

Hay excepciones dramáticas a mi argumento de que la generalización de los paquetes de software ha cambiado poco en los últimos años: las hojas de cálculo electrónicas y sistemas de bases de datos simples. Estas herramientas de gran alcance, tan evidente en retrospectiva ya la vez tan tarde en aparecer, se prestan a miles de usos, algunos de ellos muy poco ortodoxo. Artículos e incluso libros ahora abundan en la manera de abordar las tareas inesperadas con la hoja de cálculo. Un gran número de aplicaciones que anteriormente se han escrito los programas personalizados en Cobol o generador de informes del programa son ahora rutinariamente hacen con estas herramientas.

Muchos usuarios ahora tienen sus propios ordenadores en día tras día en diversas aplicaciones sin tener que escribir un programa. De hecho, muchos de estos usuarios no pueden escribir nuevos programas para sus máquinas, sin embargo, son expertos en la resolución de nuevos problemas con ellos.

Creo que la estrategia de software de productividad más poderosa para muchas organizaciones hoy en día es equipar a los trabajadores intelectuales ordenador ingenuos que están en la línea de fuego con las computadoras personales y la buena escritura generalizada, dibujos, archivos y hojas de cálculo y luego soltarlos.La misma estrategia, llevada a cabo con los paquetes de matemáticas y estadísticas y algunas capacidades de programación simples, también trabajará para cientos de científicos de laboratorio.

Requisitos, Rapid Prototyping Refinamiento y

La parte más difícil de la construcción de un único sistema de software es decidir exactamente qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como la que se establecen los requisitos técnicos detallados, incluyendo todas las interfaces con las personas, a las máquinas, así como a otros sistemas de software. Ninguna otra parte de la obra por lo paraliza el sistema resultante si se hace mal. Ninguna otra parte es más difícil de corregir más adelante.

Por lo tanto, la función más importante que el constructor de software realiza para el cliente es la extracción y refinamiento de los requisitos del producto iterativo.Pues la verdad es que el cliente no sabe lo que quiere. El cliente generalmente no sabe qué preguntas deben ser contestadas, y tiene casi nunca, aunque el problema con el detalle necesario para la especificación. Incluso la respuesta simple - "Hacer que el nuevo sistema funcione software como nuestro antiguo sistema de procesamiento de información manual" - es, de hecho, demasiado simple. Uno nunca quiere exactamente eso. Sistemas de software complejos son, por otra parte, las cosas que actúan, que se mueven, que funcionan. La dinámica de la acción es difícil de imaginar. Así que en la planificación de cualquier actividad de software-diseño, es necesario para permitir una amplia iteración entre el cliente y el diseñador como parte de la definición del sistema.

Me gustaría ir un paso más allá y afirmar que es realmente imposible para un cliente, incluso trabajando con un ingeniero de software, para especificar completamente, precisa y correctamente los requisitos exactos de un producto de software moderno antes de probar algunas versiones del producto.

Por lo tanto, uno de los más prometedores de los actuales esfuerzos tecnológicos, y uno que ataca a la esencia, no los accidentes, del problema de software, es el desarrollo de métodos y herramientas para la creación rápida de prototipos de sistemas como la creación de un prototipo es parte de la especificación iterativo de requisitos.

Un sistema de software prototipo es uno que simula las interfaces importantes y realiza las principales funciones del sistema de destino, aunque no necesariamente estar limitado por la misma velocidad de hardware, tamaño o limitaciones de costo.Los prototipos suelen realizar las tareas de la línea principal de la aplicación, pero no tratan de manejar las tareas excepcionales, responder correctamente a las entradas no válidas, o abortar limpiamente. El propósito del prototipo es de hacer realidad la estructura conceptual especificado, de modo que el cliente puede probar que para la consistencia y facilidad de uso.

Gran parte del proceso de adquisición de software de hoy en día se basa en la suposición de que se puede especificar un sistema satisfactorio de antemano, obtener ofertas para su construcción, lo han construido, e instalarlo. Creo que esta suposición es un error fundamental, y que muchos programas de adquisición de los problemas surgen de la falacia. Por lo tanto, no pueden ser fijados sin la revisión fundamental - revisión que proporciona para el desarrollo y especificación de prototipos y productos iterativo.

Desarrollo Incremental - Crecer, no construyen, Software

Todavía recuerdo la sacudida que sentí en 1958 cuando por primera vez oí a un amigo hablar de la construcción de un programa, en lugar de escribir una. En un instante, amplió toda mi visión del proceso de software. El cambio de metáfora era poderoso y preciso. Hoy entendemos cómo al igual que otros procesos de construcción, la construcción de software es, y libremente usar otros elementos de la metáfora, como especificaciones , montaje de componentes y andamios .

La metáfora de la construcción ha dejado de ser útil. Es el momento de cambiar de nuevo. Si, como creo, las estructuras conceptuales que construimos hoy son demasiado complejos para ser especificado con precisión de antemano, y demasiado complejos para ser construido sin errores, entonces tenemos que adoptar un enfoque radical diferente.

Volvamos a la naturaleza y complejidad estudio de los seres vivos, en lugar de las obras de muerte del hombre. Aquí nos encontramos con construcciones cuyas complejidades emocionarnos con asombro. El cerebro es el único intrincada allá de la cartografía, poderosos más allá de la imitación, rico en diversidad, la auto-protección y auto-renovación. El secreto es que ha crecido, no se construye.

Y así debe ser con nuestros sistemas de software. Harlan Mills hace algunos años propusieron que cualquier sistema de software debe ser cultivado por desarrollo incremental [10]. Es decir, el sistema primero debe ser obligado a correr, incluso si no hace nada útil, excepto llame el conjunto adecuado de subprogramas ficticias.Luego, poco a poco, debe concretarse, con los subprogramas a su vez, se están desarrollando en acciones o llamadas a los talones vacíos en el nivel inferior.

He visto los resultados más dramáticos desde que comenzó a instar a esta técnica en los constructores del proyecto en mi clase de Laboratorio de Ingeniería de Software. Nada en la última década ha cambiado radicalmente mi propia práctica, o su eficacia. El enfoque requiere el diseño de arriba hacia abajo, ya que es un crecimiento de arriba hacia abajo del software. Permite una fácil dar marcha atrás.Se presta a los primeros prototipos. Cada función de agregado y la nueva disposición de los datos o circunstancias más complejas crece orgánicamente a partir de lo que ya está ahí.

Los efectos de ánimo son sorprendentes. Saltos de entusiasmo cuando hay un sistema runnign, incluso simple. Los esfuerzos de re-doblar cuando la primera imagen de un nuevo sistema de software de gráficos en la pantalla, incluso si es sólo un rectángulo. Uno siempre

tiene, en cada etapa del proceso, un sistema de trabajo. Me parece que los equipos pueden crecer las entidades más complejas en cuatro meses lo que pueden construir .

Tha mismos beneficios que se pueden realizar en los grandes proyectos como en mis pequeños [11].

Grandes diseñadores

La cuestión central en la forma de mejorar los centros de arte de software, como siempre, en las personas.

Podemos conseguir buenos diseños, siguiendo las buenas prácticas en lugar de los pobres. Buenas prácticas diseños se pueden enseñar. Los programadores se encuentran entre la parte más inteligente de la población, para que puedan aprender las buenas prácticas. Por lo tanto, un impulso importante en los Estados Unidos es promulgar buenas prácticas moderna. Nuevos planes de estudio, la nueva literatura, nuevas organizaciones, como el Instituto de Ingeniería de Software, todos han llegado a ser con el fin de elevar el nivel de nuestra práctica de mala a buena. Esto es totalmente adecuada.

Sin embargo, no creo que podamos dar el siguiente paso hacia arriba de la misma manera. Considerando que las diferencias entre los diseños conceptuales pobres y buenos puede estar en la solidez del método de diseño, la diferencia entre los buenos diseños y grandes diseños seguramente no lo hace. Grandes diseños provienen de grandes diseñadores. Construcción de software es un creativoproceso. Metodología de sonido puede potenciar y liberar la mente creativa, no puede inflamar o inspirar el esclavo.

Las diferencias no son menores - son algo así como las diferencias entre Salieri y Mozart. Estudio tras estudio muestra que los mejores diseñadores producen estructuras que son más rápidos, más pequeños, más simple, más limpio, y producidos con menos esfuerzo [12]. Las diferencias entre el grande y el enfoque de media son un orden de magnitud.

Un poco de retrospectiva muestra que aunque muchos sistemas de software finas, útiles han sido diseñados por los comités y construido como parte de los proyectos de varias partes, los sistemas de software que se han emocionado los fanáticos son los que son los productos de una o unas pocas mentes diseño, grandes diseñadores. Considere la posibilidad de Unix, APL, Pascal, Modula, la interfaz de Smalltalk, incluso Fortran, y constraste con Cobol, PL / 1, Algol, MVS/370 y MS-DOS.

Productos Interesantes

Sí No

Unix

APL

Pascal

Modula

Smalltalk

Fortran

Cobol

PL / 1

Algol

MVS/370

MS-DOS

Tabla 1. Productos de software emocionantes vs útil pero aburrida

Por lo tanto, a pesar de que apoyo firmemente los esfuerzos de transferencia de tecnología y el plan de estudios de desarrollo en curso, creo que el más importante esfuerzo solo podemos montar es desarrollar maneras de hacer crecer grandes diseñadores.

Ninguna organización software puede ignorar este reto. Los buenos gerentes, escasos que sean, no son más escasos que los buenos diseñadores. Grandes diseñadores y grandes gerentes son muy raros. La mayoría de las organizaciones gastan considerable esfuerzo en la búsqueda y el cultivo de las perspectivas de gestión: no conozco ninguno que pasa el mismo

esfuerzo en la búsqueda y el desarrollo de los grandes diseñadores a quienes la excelencia técnica de los productos dependerá finalmente.

¿Cómo hacer crecer grandes diseñadores? El espacio no permite una larga discusión, pero algunas medidas son obvias:

Identificar sistemáticamente los diseñadores lo antes posible. La mejor muchas veces no son los más experimentados.

Asignar un tutor de carrera para ser responsable del desarrollo de la perspectiva, y tener cuidado de un archivo de carrera.

Elaborar y mantener un plan de desarrollo profesional para cada propspect, incluyendo una selección de programas de aprendizaje con los mejores diseñadores, los episodios de la educación formal avanzada, y cursos cortos, todos entremezclados con las tareas en solitario de diseño y técnico-liderazgo.

Proporcionar oportunidades para que los diseñadores de crecimiento de interactuar y estimular el uno al otro.

Agradecimientos

Doy las gracias a Gordon Bell, Bruce Buchanan, Rick Hayes-Roth, Robert Patrick, y, muy especialmente, David Parnas por sus puntos de vista e ideas estimulantes, y Rebeca Bierly para la producción técnica del artículo.

Referencias

1. DL Parnas, "Software de diseño para la facilidad de extensión y contracción", IEEE Trans. Ingeniería del Software , Vol.5 No.2, marzo 1979, pp 128-138

2. G. Booch, "Diseño Orientado a Objetos", Ingeniería de Software con Ada , 1983, Benjamin Cummings, Menlo Park, California

3. IEEE Trans. Ingeniería de Software (número especial sobre la inteligencia artificial y la ingeniería de software), J. Mostow, editor invitado., Vol. 11, N º 11, noviembre 1985

4. DL Parnas, "Aspectos de Software de Sistemas de Defensa Estratégica",American Scientist , 11 1985

5. R. Balzer, "Una perspectiva de 15 años en el Programa Automático", IEEE Trans. Ingeniería de Software (número especial sobre la inteligencia artificial y la ingeniería de software), J. Mostow, editor invitado., Vol.18, N º 8, agosto 1985

6. Computer (número especial sobre programación visual), RB Graphton y T. Ichikawa, invitado eds., vol.18, n º 8, agosto 1985

7. G. Reader, "Estudio de las técnicas actuales de programación gráfica",Computer (número especial sobre programación visual), RB Graphton y T. Ichikawa, invitado eds., vol.18, n º 8, agosto 1985, pp 11-25

8. FP Brooks, The Mythical Man-Month , 1975, Addison-Wesley, Reading, Massachusetts, Nueva York, Capítulo 14

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

10. HD Mills, "Programación de arriba abajo en grandes sistemas", en Técnicas de depuración en sistemas grandes , R. Ruskin, ed., Prentice-Hall, Englewood Cliffs, NJ, 1971

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

12. H. Sackman, WJ Erickson y EE Grant, "exploratorios Estudios Experimentales Comparación online y offline Rendimiento de programación",MCCA , Vol. 11, No. 1, enero 1968, pp 3-11