• Author / Uploaded
• Riviera Lore Sap

Citation preview

La bala de plata Esencia y Accidentes de la Ingeniería de Software De todos los monstruos que llenan las pesadillas de nuestro folclore, nadie se asusta más que los hombres lobo, porque se transforman inesperadamente de lo familiar en horrores. Para estos, uno busca balas de plata que pueden ponerlas mágicamente a descansar. El proyecto de software familiar, al menos tal como lo ve el gerente no técnico, tiene algo de este carácter; suele ser inocente y sencillo, pero es capaz de convertirse en un monstruo de horarios perdidos, presupuestos malgastados y productos defectuosos. Así que oímos gritos desesperados por una bala de plata, algo que haga que los costos de software disminuyan tan rápido como lo hacen los costos de hardware de computadoras. Pero, mientras miramos hacia el horizonte de una década, no vemos ninguna bala de plata. No hay un desarrollo único, ni en la tecnología ni en la técnica de gestión, que por sí solo prometa una mejora de la productividad, en la fiabilidad, en la simplicidad. En este artículo, intentaré demostrar por qué, examinando tanto la naturaleza del problema del software como las propiedades de las balas propuestas. Sin embargo, el escepticismo no es pesimismo. Aunque no vemos avances sorprendentes, y de hecho, creo que son inconsistentes con la naturaleza del software, muchas innovaciones alentadoras están en marcha. Un esfuerzo disciplinado y constante para desarrollar, propagar y explotar estas innovaciones debería producir una mejora en el orden de magnitud. No hay camino real, pero sí un camino. El primer paso hacia el manejo de la enfermedad fue reemplazar las teorías demoníacas y las teorías del humor por la teoría germinal. Ese mismo paso, el comienzo de la esperanza, en sí mismo defraudó todas las esperanzas de soluciones mágicas. Les dijo a los trabajadores que el progreso se haría paso a paso, con gran esfuerzo, y que se tendría que pagar un cuidado persistente e incesante a una disciplina de limpieza. Así es con la ingeniería de software hoy en día.

¿Tiene que ser difícil? Dificultades Esenciales No sólo no hay ahora ninguna bala de plata a la vista, la naturaleza misma del software hace que sea poco probable que haya invenciones que sirvan para la productividad, confiabilidad y simplicidad del software lo que la electrónica, los transistores y la integración a gran escala hicieron para el hardware informático. No podemos esperar nunca que se produzcan dos aumentos cada dos años. Primero, uno debe observar que la anomalía no es que el progreso del software sea tan lento, sino que el progreso del hardware de la computadora es tan rápido. Ninguna otra tecnología desde que comenzó la civilización ha visto seis órdenes de magnitud en el aumento del precio de rendimiento en 30 años. En ninguna otra tecnología se puede elegir tomar la ganancia en la mejora del rendimiento o en la reducción de costes. Estas ganancias fluyen de la transformación de la fabricación de computadoras de una industria de ensamblaje a una industria de proceso. En segundo lugar, para ver el ritmo de progreso que se puede esperar en la tecnología del software, examinemos las dificultades de esa tecnología. Siguiendo a Aristóteles, los divido en esencia, las dificultades inherentes a la naturaleza del software, y los accidentes, esas dificultades que hoy en día asisten a su producción pero no son inherentes. La esencia de una entidad de software es una construcción de conceptos interrelacionados: conjuntos de datos, relaciones entre elementos de datos, algoritmos e invocaciones de funciones. Esta esencia es abstracta en el sentido de que tal construcción conceptual es la misma bajo muchas representaciones diferentes. No obstante, es muy preciso y rico en detalles. Creo que la parte difícil de construir software es la especificación, diseño y prueba de esta construcción conceptual, no el trabajo de representarla y probar la fidelidad de la representación. Todavía cometemos errores de sintaxis, para estar seguros; pero son borrosos comparados con los errores conceptuales en la mayoría de los sistemas. Si esto es cierto, construir software siempre será difícil. No hay una bala de plata intrínseca. Consideremos las propiedades inherentes a esta esencia irreducible de los sistemas de software modernos: complejidad, conformidad, cambiabilidad e invisibilidad.

Complejidad. Las entidades de software son más complejas por su tamaño que cualquier otra construcción humana porque no hay dos partes iguales (al menos por encima del nivel de declaración). Si lo son, hacemos las dos partes similares en subrutina -abierta o cerrada. En este sentido, los sistemas de software difieren profundamente de las computadoras, edificios o automóviles, donde abundan los elementos repetitivos. Las computadoras digitales son en sí mismas más complejas que la mayoría de las cosas que la gente construye: tienen un gran número de estados. Esto hace que concebir, describir y probarlas sea difícil. Los sistemas de software tienen órdenes de magnitud de más estados que las computadoras. Del mismo modo, la ampliación de una entidad de software no es simplemente una repetición de los mismos elementos en tamaños más grandes, sino que es necesariamente un aumento en el número de diferentes elementos. En la mayoría de los casos, los elementos interactúan entre sí de manera no lineal, y la complejidad del conjunto aumenta mucho más que linealmente. La complejidad del software es una propiedad esencial, no accidental. Por lo tanto, las descripciones de una entidad de software que abstrae su complejidad a menudo abstraen su esencia. Durante tres siglos, las matemáticas y las ciencias físicas dieron grandes pasos al construir modelos simplificados de fenómenos complejos, derivando propiedades de los modelos y verificando esas propiedades mediante experimentos. Este paradigma funcionó porque las complejidades ignoradas en los modelos no eran las propiedades esenciales de los fenómenos. No funciona cuando las complejidades son la esencia. Muchos de los problemas clásicos del desarrollo de productos de software derivan de esta complejidad esencial y sus aumentos no lineales con el tamaño. De la complejidad viene la dificultad de comunicación entre los miembros del equipo, lo que lleva a fallas del producto, sobrecostes, retrasos en la programación. De la complejidad viene la dificultad de enumerar, mucho menos entender, todos los estados posibles del programa, y de eso viene la falta de fiabilidad. De la complejidad de la función viene la dificultad de invocar la función, lo que dificulta el uso de los programas. De la complejidad de la estructura viene la dificultad de extender los programas a nuevas funciones sin crear efectos secundarios. De la complejidad de la estructura vienen los estados no visualizados que constituyen trampas de seguridad.

No sólo los problemas técnicos, sino también los de gestión se deben a la complejidad. Hace que la visión de conjunto sea difícil, impidiendo así la integridad conceptual. Hace difícil encontrar y controlar todos los cabos sueltos. Esto crea la tremenda carga de aprendizaje y comprensión que hace que la rotación del personal sea un desastre. Conformidad. La gente de software no es la única que enfrenta la complejidad. La física se ocupa de objetos terriblemente complejos incluso a nivel de partículas "fundamentales". El físico trabaja, sin embargo, en una fe firme de que hay principios unificadores que se pueden encontrar, ya sea en quarks o en teorías unificadas de campo. Einstein argumentó que debe haber explicaciones simplificadas de la naturaleza, porque Dios no es caprichoso ni arbitrario. Tal fe no conforta al ingeniero de software. Gran parte de la complejidad que debe dominar es arbitrariamente compleja, forzada sin rima ni razón por las muchas instituciones y sistemas humanos a los que deben ajustarse sus interfaces. Estos difieren de interfaz en interfaz, y de vez en cuando, no por necesidad sino sólo porque fueron diseñados por diferentes personas, en vez de por Dios. En muchos casos, el software debe conformarse porque es la llegada más reciente en la escena. En otros, debe conformarse porque es percibido como el más confortable. Pero en todos los casos, mucha complejidad viene de la conformación a otras interfaces; esta complejidad no puede ser simplificada por cualquier rediseño del software solamente. Cambiabilidad. La entidad de software está constantemente sujeta a presiones de cambio. Por supuesto, también lo son los edificios, coches, ordenadores. Pero las cosas fabricadas se cambian con poca frecuencia después de su fabricación; son reemplazadas por modelos posteriores, o se incorporan cambios esenciales en copias de números de serie posteriores del mismo diseño básico. Call-backs de automóviles son realmente bastante infrecuentes; los cambios de campo de las computadoras algo menos frecuentes. Ambos son mucho menos frecuentes que las modificaciones al software de campo. En parte, esto es así porque el software de un sistema encarna su función, y la función es la parte que más siente las presiones del cambio. En parte se debe a que el software se puede cambiar más fácilmente: es puro pensamiento, infinitamente maleable. De hecho, los edificios se cambian, pero los altos costos del cambio, entendidos por todos, sirven para amortiguar los caprichos de los cambiadores.

Todo el software exitoso cambia. Hay dos procesos en marcha. En primer lugar, como se encuentra que un producto de software es útil, la gente lo prueba en nuevos casos en el borde o más allá del dominio original. Las presiones para la función extendida provienen principalmente de usuarios a los que les gusta la función básica e inventan nuevos usos para ella. En segundo lugar, el software exitoso sobrevive más allá de la vida útil normal del vehículo de la máquina para el cual fue escrito por primera vez. Si no hay computadoras nuevas, entonces al menos nuevos discos, pantallas y nuevas impresoras nuevas aparecen; y el software debe ajustarse a sus nuevos vehículos de oportunidad. En resumen, el producto de software está integrado en una matriz cultural de aplicaciones, usuarios, leyes y vehículos de máquina. Todo esto cambia continuamente, y sus cambios obligan inexorablemente a cambiar el producto de software. Invisibilidad. El software es invisible e invisualizable. Las abstracciones geométricas son herramientas poderosas. El plano de planta de un edificio ayuda tanto al arquitecto como al cliente a evaluar espacios, flujos de tráfico y vistas. Las contradicciones y omisiones se hacen evidentes. Dibujos a escala de piezas mecánicas y modelos de moléculas con figuras de palillo, aunque abstracciones, sirven para el mismo propósito. Una realidad geométrica es capturada en una abstracción geométrica. La realidad del software no está inherentemente incrustada en el espacio. Por lo tanto, no tiene una representación geométrica lista en la forma en que la tierra tiene mapas, los chips de silicio tienen diagramas, las computadoras tienen esquemas de conectividad. Tan pronto como intentamos diagramar la estructura del software, encontramos que no constituye una, sino varios gráficos dirigidos generales superpuestos uno sobre otro. Los varios gráficos pueden representar el flujo de control, el flujo de datos, patrones de dependencia, secuencia temporal, relaciones nombre-espacio. Estos gráficos no suelen ser ni siquiera planares, mucho menos jerárquicos. De hecho, una de las maneras de establecer el control conceptual sobre tal estructura es forzar el corte de enlaces hasta que uno o más de los gráficos se conviertan en jerárquicos. [1] A pesar del progreso en la restricción y simplificación de las estructuras del software, éstas siguen siendo intrínsecamente invisualizables, y por lo tanto no permiten que la mente utilice algunas de sus herramientas conceptuales más

poderosas. Esta carencia no sólo impide el proceso de diseño dentro de una mente, sino que dificulta severamente la comunicación entre las mentes.

Avances pasados resolvieron dificultades accidentales Si examinamos los tres pasos en el desarrollo de la tecnología de software que han sido más fructíferos en el pasado, descubrimos que cada uno de ellos atacó una dificultad importante en la construcción de software, pero que esas dificultades han sido accidentales, no esenciales. También podemos ver los límites naturales de la extrapolación de cada ataque. Lenguas de alto nivel. Seguramente el golpe más poderoso para la productividad, confiabilidad y simplicidad del software ha sido el uso progresivo de lenguajes de alto nivel para la programación. La mayoría de los observadores dan crédito a ese desarrollo con al menos un factor de cinco en la productividad, y con las ganancias concomitantes en fiabilidad, simplicidad y comprensibilidad. ¿Qué logra un lenguaje de alto nivel? Libera a un programa de gran parte de su complejidad accidental. Un programa abstracto consiste en construcciones conceptuales: operaciones, tipos de datos, secuencias y comunicación. El programa concreto de la máquina se ocupa de los bits, registros, condiciones, ramas, canales, discos y demás. En la medida en que el lenguaje de alto nivel encarna los constructos que uno quiere en el programa abstracto y evita todos los más bajos, elimina todo un nivel de complejidad que nunca fue inherente al programa. Lo más que puede hacer un lenguaje de alto nivel es amueblar todas las construcciones que el programador imagina en el programa abstracto. Sin duda, el nivel de nuestro pensamiento sobre las estructuras de datos, los tipos de datos y las operaciones está en constante aumento, pero a un ritmo cada vez menor. Y el desarrollo del lenguaje se acerca cada vez más a la sofisticación de los usuarios. Además, en algún momento la elaboración de un lenguaje de alto nivel crea una carga de herramientas-masterización que aumenta, no reduce, la tarea intelectual del usuario que raramente utiliza las construcciones esotéricas. Tiempo compartido. El tiempo compartido supuso una mejora importante en la productividad de los programadores y en la calidad de su producto, aunque no tan grande como la aportada por los lenguajes de alto nivel.

Compartir el tiempo ataca una dificultad muy diferente. El tiempo compartido preserva la inmediatez, y por lo tanto permite mantener una visión general de la complejidad. El lento giro de la programación por lotes significa que uno se olvida inevitablemente de las minucias, si no del empuje, de lo que uno estaba pensando cuando dejó de programar y llamó a la compilación y ejecución. Esta interrupción es costosa en el tiempo, pues hay que refrescar la memoria. El efecto más grave bien puede ser la decadencia del agarre de todo lo que está sucediendo en un sistema complejo. El giro lento, al igual que las complejidades del lenguaje de la máquina, es una dificultad accidental y no esencial del proceso de software. Los límites de la contribución potencial del tiempo compartido se derivan directamente. El principal efecto del tiempo compartido es acortar el tiempo de respuesta del sistema. A medida que este tiempo de respuesta pasa a cero, en algún momento sobrepasa el umbral humano de notoriedad, unos 100 milisegundos. Más allá de ese umbral, no cabe esperar ningún beneficio. Entornos de programación unificados. Unix e Interlisp, los primeros entornos de programación integrados que entran en uso generalizado, parecen haber mejorado la productividad por factores integrales. ¿Por qué? Atacan las dificultades accidentales que resultan del uso conjunto de programas individuales, proporcionando bibliotecas integradas, formatos de archivo unificados y tuberías y filtros. Como resultado de ello, las estructuras conceptuales que en principio siempre podrían llamarse, alimentarse y utilizarse mutuamente pueden hacerlo fácilmente en la práctica. Este avance a su vez estimuló el desarrollo de bancos de herramientas completos, ya que cada herramienta nueva podía aplicarse a cualquier programa que utilizara los formatos estándar. Debido a estos éxitos, los entornos son el tema de gran parte de la investigación actual en ingeniería de software. Miramos sus promesas y limitaciones en la siguiente sección.

Esperanzas para la Plata Consideremos ahora los avances técnicos que más a menudo son avanzados como posibles balas de plata. ¿Qué problemas abordan, los problemas de esencia o las

dificultades accidentales incrementales?

restantes?

¿Ofrecen

avances

revolucionarios

o

Ada y otros avances lingüísticos de alto nivel. Uno de los acontecimientos recientes más aclamados es Ada, un lenguaje de alto nivel para fines generales de los años ochenta. Ada no sólo refleja mejoras evolutivas en los conceptos lingüísticos, sino que además incorpora características para fomentar el diseño moderno y la modularización. Tal vez la filosofía Ada es más un avance que el lenguaje Ada, porque es la filosofía de la modularización, de los tipos de datos abstractos, de la estructuración jerárquica. Ada es excesivamente rica, un resultado natural del proceso por el que se establecieron los requisitos en su diseño. Eso no es fatal, porque los vocabularios de trabajo subestablecidos pueden resolver el problema del aprendizaje, y los avances de hardware nos darán el MIPS barato para pagar los costos de compilación. Avanzar en la estructuración de los sistemas de software es de hecho un uso muy bueno para el aumento del MIPS que nuestros dólares comprarán. Los sistemas operativos, fuertemente criticados en los años 60 por sus costes de memoria y ciclos, han demostrado ser una forma excelente de utilizar algunos de los MIPS y bytes de memoria baratos de la pasada oleada de hardware. Sin embargo, Ada no será la bala de plata que mate al monstruo de la productividad del software. Después de todo, es sólo otro lenguaje de alto nivel, y la mayor recompensa de tales lenguajes vino de la primera transición -- la transición de las complejidades accidentales de la máquina a la declaración más abstracta de soluciones paso a paso. Una vez que esos accidentes hayan sido eliminados, los restantes serán menores, y el resultado de su remoción seguramente será menor. Predigo que dentro de una década, cuando se evalúe la eficacia de Ada, se verá que ha hecho una diferencia sustancial, pero no debido a ninguna característica lingüística en particular, ni por la combinación de todas ellas. Tampoco los nuevos entornos Ada serán la causa de las mejoras. La mayor contribución de Ada será que el cambio a ella ocasionó que los programadores de entrenamiento en técnicas modernas de diseño de software. Programación orientada a objetos. Muchos estudiantes de arte tienen más esperanza para la programación orientada a objetos que para cualquiera de las otras técnicas de modas del día. Yo estoy entre ellos. Mark Sherman de Dartmouth anota en CSnet News que uno debe tener cuidado de distinguir dos ideas separadas que van bajo ese nombre: tipos de datos abstractos y tipos jerárquicos. El concepto del

tipo de datos abstractos es que el tipo de un objeto debe estar definido por un nombre, un conjunto de valores propios y un conjunto de operaciones adecuadas en lugar de por su estructura de almacenamiento, que debe ocultarse. Algunos ejemplos son los paquetes Ada (con tipos privados) y los módulos de Modula. Los tipos jerárquicos, como las clases de Simula-67, permiten definir interfases generales que pueden perfeccionarse aún más proporcionando tipos subordinados. Los dos conceptos son ortogonal_uno puede tener jerarquías sin esconderse y ocultarse sin jerarquías. Ambos conceptos representan avances reales en el arte de construir software. Cada uno de ellos elimina otra dificultad accidental del proceso, permitiendo al diseñador expresar la esencia del diseño sin tener que expresar grandes cantidades de material sintáctico que no agrega contenido informativo. Tanto para los tipos abstractos como para los tipos jerárquicos, el resultado es eliminar un tipo de dificultad accidental de orden superior y permitir una expresión de mayor orden del diseño. Sin embargo, tales avances no pueden sino eliminar todas las dificultades accidentales de la expresión del dibujo o modelo. La complejidad del diseño en sí mismo es esencial, y tales ataques no hacen ningún cambio en eso. Una ganancia de orden de magnitud sólo se puede obtener mediante programación orientada a objetos si el subcepillo de especificación de tipo innecesario que todavía se encuentra en nuestro lenguaje de programación es nueve décimas partes del trabajo que implica el diseño de un producto de programa. Lo dudo. Inteligencia artificial. Mucha gente espera que los avances en inteligencia artificial proporcionen el revolucionario avance que dará ganancias de orden de magnitud en productividad y calidad del software. [3] Yo no. Para ver por qué, debemos diseccionar lo que significa "inteligencia artificial". D.L. Parnas ha aclarado el caos terminológico:[4] Hoy en día se utilizan comúnmente dos definiciones bastante diferentes de la IA. AI-1: El uso de ordenadores para resolver problemas que antes sólo podían resolverse mediante la aplicación de inteligencia humana. Al-2: El uso de un conjunto específico de técnicas de programación conocidas como programación heurística o basada en reglas. En este enfoque se estudian los expertos humanos para determinar qué heurística o reglas de pulgar utilizan

para resolver problemas..... El programa está diseñado para resolver un problema de la manera en que los seres humanos parecen resolverlo. La primera definición tiene un significado deslizante.... Algo puede encajar con la definición de Al-1 hoy en día pero, una vez que veamos cómo funciona el programa y entendamos el problema, ya no pensaremos en él como Al? Desafortunadamente no puedo identificar un cuerpo de tecnología que es único en este campo..... La mayor parte de la obra es específica del problema, y se requiere algo de abstracción o creatividad para ver cómo transferirla. Estoy totalmente de acuerdo con esta crítica. Las técnicas utilizadas para el reconocimiento de voz parecen tener poco en común con las utilizadas para el reconocimiento de imágenes, y ambas son diferentes de las utilizadas en sistemas expertos. Me cuesta mucho trabajo ver cómo el reconocimiento de imágenes, por ejemplo, marcará cualquier diferencia apreciable en la práctica de la programación. El mismo problema ocurre con el reconocimiento del habla. Lo difícil de construir software es decidir lo que uno quiere decir, no decirlo. Ninguna facilitación de la expresión puede dar más que ganancias marginales. La tecnología de sistemas expertos, AI-2, merece una sección propia. Sistemas expertos. La parte más avanzada del arte 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 arduamente aplicando esta tecnología al entorno de creación de software. 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 generalizado y una base de reglas, toma los datos de entrada y las suposiciones, explora las inferencias derivadas de la base de reglas, genera conclusiones y consejos, y ofrece explicar sus resultados mediante el rastreo de su razonamiento para el usuario. Los motores de inferencia típicamente pueden tratar con datos borrosos o probabilísticos y reglas, además de la lógica puramente determinista. Tales sistemas ofrecen algunas ventajas claras sobre los algoritmos programados diseñados para llegar a las mismas soluciones a los mismos problemas: La tecnología del motor de inferencia se desarrolla de forma independiente de la aplicación y luego se aplica a muchos usos. Uno puede justificar mucho

esfuerzo en los motores de inferencia. De hecho, esa tecnología está muy avanzada. Las partes intercambiables de los materiales característicos de la aplicación se codifican en la base de reglas de manera uniforme y se proporcionan herramientas para desarrollar, cambiar, probar y documentar la base de reglas. Esto regulariza gran parte de la complejidad de la propia aplicación. El poder de tales sistemas no proviene de mecanismos de inferencia cada vez más fanáticos, sino de bases de conocimiento cada vez más ricas que reflejan el mundo real con mayor precisión. Creo que el avance más importante que ofrece la tecnología es la separación de la complejidad de la aplicación del programa en sí. ¿Cómo se puede aplicar esta tecnología a la ingeniería de software? De muchas maneras: Estos sistemas pueden sugerir reglas de interfaz, aconsejar sobre estrategias de prueba, recordar frecuencias de tipo bug y ofrecer consejos de optimización. Muchas dificultades se interponen en el camino de la pronta realización de útiles asesores expertos en sistemas para el desarrollador del programa. Una parte crucial de nuestro escenario imaginario es el desarrollo de formas fáciles de llegar desde la especificación de la estructura del programa hasta 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 adquirir conocimientos: encontrar expertos autoanalíticos que sepan por qué hacen las cosas y desarrollar técnicas eficientes para extraer lo que saben y destilarlo en bases de reglas. El prerrequisito esencial para construir un sistema experto es contar con un experto. La contribución más poderosa de los sistemas expertos seguramente será poner al servicio del programador inexperto la experiencia y sabiduría acumulada de los mejores programadores. Esta no es una contribución pequeña. La brecha entre la mejor práctica de ingeniería de software y la práctica promedio es muy amplia_quizás más amplia que en cualquier otra disciplina de ingeniería. Sería importante disponer de una herramienta que difunda las buenas prácticas. Programación "automática". Durante casi 40 años, la gente ha estado anticipando y escribiendo acerca de la "programación automática", o la generación de un programa para resolver un problema a partir de una declaración de las especificaciones del problema. Algunos escriben hoy en día como si esperaran que esta tecnología les proporcione el próximo avance. [5]

Parnas[4] implica que el término se usa para glamour, no para contenido semántico, afirmando, En resumen, la programación automática siempre ha sido un eufemismo para la programación con un lenguaje de nivel superior al que estaba disponible actualmente para el programador. Sostiene, en esencia, que en la mayoría de los casos es el método de solución, no el problema, cuya especificación hay que dar. Estas aplicaciones tienen propiedades muy favorables:  Los problemas se caracterizan fácilmente por un número relativamente reducido de parámetros.  Hay muchos métodos conocidos de solución para proporcionar una biblioteca de alternativas.  Un análisis exhaustivo ha conducido a reglas explícitas para seleccionar las técnicas de solución, dados los parámetros del problema. Es difícil ver cómo estas técnicas generalizan al mundo más amplio del sistema de software ordinario, donde los casos con propiedades tan limpias son la excepción. Es difícil incluso imaginar cómo podría ocurrir este avance en la generalización. Programación gráfica. Una asignatura favorita para las tesis de doctorado en ingeniería de software es la programación gráfica, o visual, la aplicación de gráficos computarizados al diseño de software. [6,7] A veces la promesa de tal enfoque se postula por analogía con el diseño de chips VLSI, en el que los gráficos computarizados juegan un papel tan fructífero. A veces el teórico justifica el enfoque considerando los diagramas de flujo como el medio ideal para diseñar programas y proporcionando poderosas facilidades para construirlos. Nada, ni siquiera convincente y mucho menos emocionante, ha surgido de tales esfuerzos. Estoy convencido de que nada lo hará. En primer lugar, como he argumentado en otras partes[8], el diagrama de flujo es una abstracción muy pobre de la estructura del software. De hecho, es mejor verlo como Burks, von Neumann y el intento de Goldstine de proporcionar un lenguaje de control de alto nivel desesperadamente necesario para su computadora propuesta. En la forma lamentable, multipágina, caja de conexión a la que se ha elaborado el diagrama de flujo hoy en día, ha demostrado ser inútil como herramienta de diseño -

los programadores dibujan diagramas de flujo después, no antes, de 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 de software muy detallado. La llamada "metáfora de escritorio" de la estación de trabajo actual es, en cambio, una metáfora de "asiento de avión". Cualquiera que haya barajado una vuelta llena de papeles mientras está sentado entre dos pasajeros portentosos reconocerá la diferencia - uno puede ver sólo muy pocas cosas a la vez. El verdadero escritorio proporciona información general y acceso aleatorio a una veintena de páginas. Por otra parte, cuando los ajustes de la creatividad corren fuertes, más de un programador o escritor ha sido conocido por abandonar el escritorio para el piso más espacioso. La tecnología de hardware tendrá que avanzar bastante antes de que el alcance de nuestros alcances sea suficiente para la tarea de diseño de software. Más fundamentalmente, como he argumentado anteriormente, el software es muy difícil de visualizar. Verificación del programa. Gran parte del esfuerzo en la programación moderna se dedica a las pruebas y la reparación de errores. ¿Existe quizás una bala de plata que se pueda encontrar eliminando los errores en la fuente, en la fase de diseño del sistema? ¿Se puede mejorar radicalmente tanto la productividad como la fiabilidad del producto siguiendo la estrategia profundamente diferente de demostrar que los diseños son correctos antes de que el inmenso esfuerzo sea vertido en su implementación y prueba? No creo que encontremos magia de productividad aquí. La verificación de programas es un concepto muy poderoso, y será muy importante para cosas como los núcleos de sistemas operativos seguros. Sin embargo, la tecnología no promete ahorrar mano de obra. Las verificaciones son tanto trabajo que sólo unos pocos programas sustanciales han sido verificados. La verificación del programa no significa programas a prueba de errores. Aquí tampoco hay magia. Las pruebas matemáticas también pueden ser erróneas. Por lo tanto, mientras que la verificación puede reducir la carga de prueba del programa, no puede eliminarla. Más en serio, incluso la verificación perfecta del programa sólo puede establecer que un programa cumple con sus especificaciones. La parte más difícil de la tarea de

software es llegar a una especificación completa y consistente, y gran parte de la esencia de construir un programa es de hecho la depuración de la especificación. Entornos y herramientas. ¿Cuánta más ganancia se puede esperar de la explosión de las investigaciones en mejores entornos de programación? La reacción instintiva de uno es que los grandes problemas de pago: sistemas de archivos jerárquicos, formatos de archivo uniformes para hacer posibles interfaces de programa uniformes y herramientas generalizadas, fueron los primeros en ser atacados y se han resuelto. Los editores inteligentes específicos del idioma son desarrollos que aún no se utilizan ampliamente en la práctica, pero lo más prometedor es que están libres de errores sintácticos y errores semánticos simples. Tal vez la mayor ganancia que todavía no se ha realizado de los entornos de programación es el uso de sistemas de base de datos integrados para mantener un seguimiento de los innumerables detalles que deben ser recuperados con precisión por el programador individual y mantenerse actualizados para un grupo de colaboradores en un solo sistema. Sin duda, este trabajo merece la pena, y seguramente dará algún fruto tanto en productividad como en fiabilidad. Pero por su propia naturaleza, el retorno de ahora en adelante debe ser marginal. Estaciones de trabajo. ¿Qué ventajas se pueden esperar para el software art del aumento seguro y rápido de la potencia y la capacidad de memoria de la estación de trabajo individual? Bueno, ¿cuántos MIPS se pueden usar fructíferamente? La composición y edición de programas y documentos está totalmente soportada por las velocidades actuales. La compilación podría soportar un empuje, pero un factor de 10 en la velocidad de la máquina seguramente dejaría el thinktime la actividad dominante en el día del programador. De hecho, así parece ser ahora. Unas estaciones de trabajo más potentes son bienvenidas. Mejoras mágicas de ellos que no podemos esperar.

Ataques prometedores a la esencia conceptual A pesar de que ningún avance tecnológico promete dar el tipo de resultados mágicos con los que estamos tan familiarizados en el área de hardware, hay una abundancia de buenos trabajos que están sucediendo ahora, y la promesa de un progreso constante, aunque no espectacular.

Todos los ataques tecnológicos sobre los accidentes del proceso de software están fundamentalmente limitados por la ecuación de productividad: Si, como creo, los componentes conceptuales de la tarea están tomando ahora la mayor parte del tiempo, entonces ninguna cantidad de actividad en los componentes de la tarea que son simplemente la expresión de los conceptos puede dar grandes ganancias de productividad. Por lo tanto, debemos considerar aquellos ataques que abordan la esencia del problema del software, la formulación de estas complejas estructuras conceptuales. Afortunadamente, algunos de estos ataques son muy prometedores. Comprar contra construir. La solución más radical posible para construir software es no construirlo en absoluto. Cada día esto se hace más fácil, ya que cada vez más y más proveedores ofrecen más y mejores productos de software para una variedad vertiginosa de aplicaciones. Mientras que nosotros los ingenieros de software hemos trabajado en la metodología de producción, la revolución personal-computadora ha creado no uno, sino muchos mercados masivos de software. Cada quiosco tiene revistas mensuales, que clasificadas por tipo de máquina, anuncian y revisan docenas de productos a precios que van desde unos pocos dólares hasta cientos de dólares. Fuentes más especializadas ofrecen productos muy potentes para el mercado de estaciones de trabajo y otros mercados Unix. Incluso las herramientas y los entornos de software se pueden comprar de serie. En otras partes he propuesto un mercado para módulos individuales. [9] Cualquier producto de este tipo es más barato de comprar que de construir de nuevo. Incluso a un costo de cien mil dólares, una pieza de software comprada está costando sólo alrededor de un año programador. Y la entrega es inmediata! Inmediato al menos para los productos que realmente existen, productos cuyo desarrollador puede referir los productos a un usuario satisfecho. Además, tales productos tienden a estar mucho mejor documentados y en cierto modo mejor mantenidos que el software local. Creo que el desarrollo del mercado masivo es la tendencia más profunda a largo plazo en ingeniería de software. El costo del software siempre ha sido el costo de desarrollo, no el costo de replicación. Compartir ese costo entre unos pocos usuarios reduce radicalmente el costo por usuario. Otra manera 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 la aplicabilidad. ¿Puedo utilizar un paquete disponible para realizar mi tarea? Algo sorprendente ha pasado aquí. Durante las décadas de 1950 y 1960, un estudio tras otro demostró que los usuarios no utilizarían paquetes estándar para la nómina, el control de inventarios, cuentas por cobrar, etcétera. Los requisitos eran demasiado especializados, la variación de un caso a otro demasiado grande. Durante los años ochenta, encontramos tales envases en alta demanda y uso generalizado. ¿Qué ha cambiado? No los paquetes, en realidad. Pueden ser algo más generalizadas y algo más personalizables que antes, pero no mucho. Tampoco las solicitudes. En todo caso, las necesidades empresariales y científicas de hoy en día son más diversas y complicadas que las de hace 20 años. El gran cambio se ha producido en la relación coste hardware/software. En 1960, el comprador de una máquina de dos millones de dólares sentía que podía permitirse 250.000 dólares más para un programa de nómina personalizado, uno que se deslizaba fácilmente y sin interrupciones en el entorno social hostil a las computadoras. Hoy en día, el comprador de una máquina de oficina de 50.000 dólares no puede permitirse un programa de nómina personalizado, por lo que adapta el procedimiento de nómina a los paquetes disponibles. Las computadoras son ahora tan comunes, si no tan queridas, que las adaptaciones son aceptadas como algo natural. Hay excepciones dramáticas a mi argumento de que la generalización de los paquetes de software ha cambiado poco a lo largo de los años: hojas de cálculo electrónicas y sistemas de bases de datos simples. Estas poderosas herramientas, tan obvias en retrospectiva y sin embargo tan tardías en su aparición, se prestan a innumerables usos, algunos poco ortodoxos. Ahora abundan los artículos e incluso los libros sobre cómo abordar tareas inesperadas con la hoja de cálculo. Un gran número de aplicaciones que anteriormente se habrían escrito como programas personalizados en Cobol o Report Program Generator ahora se hacen rutinariamente con estas herramientas. Muchos usuarios ahora operan sus propias computadoras día tras día en varias aplicaciones sin necesidad de escribir un programa. De hecho, muchos de estos usuarios no pueden escribir nuevos programas para sus máquinas, pero son expertos en resolver nuevos problemas con ellos.

Creo que la única estrategia de productividad de software más poderosa para muchas organizaciones hoy en día es equipar a los trabajadores intelectuales que están en la línea de fuego con computadoras personales y buenos programas generalizados de escritura, dibujo, archivos y hojas de cálculo, y luego liberarlos. La misma estrategia, llevada a cabo con paquetes matemáticos y estadísticos generalizados y algunas capacidades simples de programación, también funcionará para cientos de científicos de laboratorio. Perfeccionamiento de requerimientos y prototipado rápido. La parte más difícil de construir un sistema de software es decidir exactamente qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requisitos técnicos detallados, incluyendo todas las interfaces con personas, máquinas y otros sistemas de software. Ninguna otra parte del trabajo paraliza el sistema resultante si se hace mal. Ninguna otra parte es más difícil de rectificar después. Por lo tanto, la función más importante que el constructor de software realiza para el cliente es la extracción iterativa y el refinamiento de los requisitos del producto. La verdad es que el cliente no sabe lo que quiere. Por lo general, el cliente no sabe qué preguntas deben ser respondidas, y casi nunca ha pensado en el problema en los detalles necesarios para la especificación. Incluso la simple respuesta_"Hacer que el nuevo sistema de software funcione como nuestro antiguo sistema de procesamiento manual de información"_es demasiado simple. Uno nunca quiere exactamente eso. Los sistemas de software complejos son, además, cosas que actúan, que se mueven, que funcionan. La dinámica de esa acción es difícil de imaginar. Así que en la planificación de cualquier actividad de diseño de software, es necesario tener en cuenta una amplia iteración entre el cliente y el diseñador como parte de la definición del sistema. Yo iría un paso más allá y afirmaría que es realmente imposible para un cliente, incluso trabajando con un ingeniero de software, especificar completa, 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 esfuerzos tecnológicos más prometedores de los actuales, y que ataca la esencia, no los accidentes, del problema del software, es el desarrollo de enfoques y herramientas para la creación rápida de prototipos de sistemas, ya que el prototipado es parte de la especificación iterativa de los requisitos.

Un sistema de software prototipo es aquel que simula las interfaces importantes y realiza las funciones principales del sistema previsto, aunque no necesariamente está sujeto a las mismas limitaciones de velocidad, tamaño o coste del hardware. Los prototipos suelen realizar las tareas principales de la aplicación, pero no intentan manejar las tareas excepcionales, responder correctamente a entradas no válidas o abortar limpiamente. El propósito del prototipo es hacer realidad la estructura conceptual especificada, de manera que el cliente pueda probarla para comprobar su consistencia y usabilidad. Gran parte del actual procedimiento de adquisición de software se basa en la suposición de que uno puede especificar un sistema satisfactorio por adelantado, obtener ofertas para su construcción, construirlo e instalarlo. Creo que esta suposición es fundamentalmente errónea, y que muchos problemas de adquisición de software surgen de esa falacia. Por lo tanto, no se pueden fijar sin una revisión fundamental -revisión que prevé el desarrollo iterativo y la especificación de prototipos y productos. Desarrollo incremental---crecer, no construir, software. Todavía recuerdo la sacudida que sentí en 1958 cuando escuché por primera vez a un amigo hablar sobre la construcción de un programa, en lugar de escribir uno. En un santiamén amplió mi visión del proceso de software. El cambio de metáfora era poderoso y preciso. Hoy en día entendemos como otros procesos constructivos la construcción del software es, y libremente utilizamos otros elementos de la metáfora, como especificaciones, ensamblaje de componentes y andamios. La metáfora del edificio ha sobrevivido a su utilidad. Es hora de cambiar de nuevo. Si, como creo, las estructuras conceptuales que construimos hoy en día son demasiado complicadas para ser especificadas de antemano con precisión y demasiado complejas para ser construidas sin errores, entonces debemos adoptar un enfoque radicalmente diferente. Volvamos la naturaleza y estudiemos la complejidad en los seres vivos, en vez de sólo las obras muertas del hombre. Aquí encontramos construcciones cuyas complejidades nos emocionan con admiración. El cerebro por sí solo es intrincado más allá del mapeo, poderoso más allá de la imitación, rico en diversidad, autoprotector y renovador. El secreto es que crece, no se construye.

Así debe ser con nuestros sistemas de software. Hace algunos años, Harlan Mills propuso que cualquier sistema de software debería ser cultivado mediante un desarrollo incremental. 10] Es decir, primero se debe hacer funcionar el sistema, aunque no haga nada útil excepto llamar al conjunto adecuado de subprogramas ficticios. Luego, poco a poco, se debe desarrollar, con los subprogramas a su vez desarrollados, en acciones o llamadas para vaciar los stubs en el nivel inferior. He visto los resultados más dramáticos desde que empecé a instar esta técnica a los constructores de proyectos en mi clase de Laboratorio de Ingeniería de Software. Nada en la última década ha cambiado tan radicalmente mi propia práctica, o su eficacia. El enfoque requiere un diseño de arriba hacia abajo, ya que es un crecimiento del software de arriba hacia abajo. Permite un fácil retroceso. Se presta a prototipos antiguos. Cada función añadida y nueva disposición para datos o circunstancias más complejas crece orgánicamente a partir de lo que ya existe. Los efectos de la moral son sorprendentes. El entusiasmo salta cuando hay un sistema en marcha, incluso uno simple. Los esfuerzos se redoblan cuando la primera imagen de un nuevo sistema de software gráfico aparece en la pantalla, aunque sólo sea un rectángulo. Uno siempre tiene, en cada etapa del proceso, un sistema de trabajo. Encuentro que los equipos pueden crecer en entidades mucho más complejas en cuatro meses de lo que pueden construir. Los mismos beneficios se pueden obtener en grandes proyectos como en los pequeños. [11] Grandes diseñadores. La cuestión central en cómo mejorar los centros de software art, como siempre lo ha hecho, sobre las personas.

Podemos conseguir buenos diseños siguiendo buenas prácticas en vez de malas. Se pueden enseñar buenas prácticas de diseño. Los programadores se encuentran entre los sectores más inteligentes de la población, por lo que pueden aprender buenas prácticas. Por lo tanto, un gran impulso en los Estados Unidos es promulgar buenas prácticas modernas. Nuevos planes de estudio, nueva literatura, nuevas organizaciones como el Instituto de Ingeniería del Software, todos han surgido para elevar el nivel de nuestra práctica de pobre a bueno. Esto es totalmente correcto. Sin embargo, no creo que podamos dar el siguiente paso hacia arriba de la misma manera. Mientras que la diferencia entre los diseños conceptuales pobres y los

buenos puede estar en la solidez del método de diseño, la diferencia entre los buenos diseños y los grandes seguramente no lo es. Grandes diseños vienen de grandes diseñadores. La construcción de software es un proceso creativo. Una metodología sólida puede empoderar y liberar la mente creativa; no puede inflamar o inspirar el impulso. Las diferencias no son menores, son como las diferencias entre Salieri y Mozart. Estudio tras estudio muestra que los mejores diseñadores producen estructuras más rápidas, pequeñas, simples, limpias y producidas con menos esfuerzo. 12] Las diferencias entre lo grande y lo medio se acercan a un orden de magnitud. Un poco de retrospección muestra que aunque muchos sistemas de software buenos y útiles han sido diseñados por comités y construidos como parte de proyectos multiparte, aquellos sistemas de software que han entusiasmado a los apasionados son aquellos que son producto de una o varias mentes de diseño, grandes diseñadores. Considere Unix, APL, Pascal, Modula, la interfaz Smalltalk, incluso Fortran; y compárelos con Cobol, PL/I, Algol, MVS/370 y MS-DOS. (Ver Tabla 1.) Por lo tanto, aunque apoyo firmemente los esfuerzos de transferencia de tecnología y desarrollo curricular actualmente en curso, creo que el esfuerzo más importante que podemos realizar es desarrollar maneras de hacer crecer a los grandes diseñadores. Ninguna organización de software puede ignorar este desafío. Los buenos gerentes, por escasos que sean, no son más escasos que los buenos diseñadores. Los grandes diseñadores y los grandes managers son muy raros. La mayoría de las organizaciones invierten un esfuerzo considerable en encontrar y cultivar las perspectivas de gestión; no conozco a nadie que se esfuerce por igual en encontrar y desarrollar a los grandes diseñadores de los que la excelencia técnica de los productos dependerá en última instancia. Table 1. Exciting Vs. Useful But Unexciting Software Products. Exciting Products Yes No Unix Cobol APL PL/I Pascal Algol Modula MVS/370 Smalltalk MS-DOS Fortran

Mi primera propuesta es que cada organización de software debe determinar y proclamar que los grandes diseñadores son tan importantes para su éxito como lo son los grandes gerentes, y que se puede esperar que sean igualmente nutridos y recompensados. No sólo el salario, sino también los requisitos de reconocimiento tamaño de la oficina, mobiliario, equipo técnico personal, fondos para viajes y apoyo del personal- deben ser completamente equivalentes. ¿Cómo hacer crecer a los grandes diseñadores? El espacio no permite una discusión larga, pero algunos pasos son obvios:  Identificar sistemáticamente a los mejores diseñadores lo antes posible. Los mejores a menudo no son los más experimentados.  Asignar un mentor de carrera para que sea responsable del desarrollo del prospecto, y mantener cuidadosamente un expediente de carrera.  Elaborar y mantener un plan de desarrollo de carrera para cada prospecto, incluyendo aprendizajes cuidadosamente seleccionados con los mejores diseñadores, episodios de educación formal avanzada y cursos cortos, todos mezclados con tareas de diseño individual y liderazgo técnico.  Proporcionar oportunidades para que los diseñadores en crecimiento interactúen y se estimulen entre sí.