• Author / Uploaded
• Jona Ruiz

• Categories
• Ingeniería Química
• Ingeniería
• Ciencia
• Química
• Diseño

Citation preview

Las​ ​perspectivas​ ​de​ ​una​ ​disciplina​ ​de​ ​ingeniería​ ​de​ ​software​ ​de Mary​ ​Shaw de​ ​septiembre​ ​de​ ​de​ ​1990 CMU-CS-90-165

Facultad de Ciencias de la Computación de la Universidad Carnegie Mellon de Pittsburgh,​ ​PA​ ​15213​ ​a​ ​3809 Este​ ​informe​ ​también​ ​aparecerán​ ​en​ ​IEEE​ ​Software​ ​noviembre​ ​de​ ​1990​ ​y como Carnegie Mellon University, Instituto de Ingeniería de Software Informe técnico​ ​CMU​ ​/​ ​SEI-90-TR-20,​ ​EDS-TR-90-221 Resumen ingeniería de Softwaretodavía no es una verdadera disciplina de ingeniería, pero tiene el potencial para convertirse en uno. Campos de la ingeniería de más edad ofrecen atisbos del carácter ingeniería de software podría tener. A partir de estos consejos y una evaluación del estado actual de la práctica de software, podemos proyectar algunas características de ingeniería de software tendrá y sugerir algunos​ ​pasos​ ​hacia​ ​una​ ​disciplina​ ​de​ ​ingeniería​ ​de​ ​software​ ​de la ingeniería del software término fue acuñado en 1968 como una declaración de aspiración con una especie de grito de guerra. Ese año la OTAN convocó un taller con ese nombre para evaluar el estado y las perspectivas de la producción de software [69] de la OTAN. Capturar la imaginación de los desarrolladores de software, la frase logra popularidad durante la década de 1970. Ahora se hace referencia a un conjunto de procesos de gestión, herramientas de software, y las actividades de diseño para el desarrollo de software La práctica resultante, sin embargo, difiere significativamente de la práctica de las formas más antiguas de la​ ​ingeniería. 1.​ ​¿Qué​ ​es​ ​la​ ​Ingeniería? La ingeniería de software es una etiqueta aplicada a un conjunto de prácticas actuales para el desarrollo de software. El uso de la palabra ingeniería para describir esta actividad se lleva a una considerable libertad con el uso común del término. Por el contrario, el uso más habitual se refiere a la aplicación disciplinada de los conocimientos científicos para resolver las limitaciones y exigencias antagónicas de problemas​ ​de​ ​importancia​ ​práctica​ ​inmediata.

Definiciones​ ​de​ ​muestreo​ ​de​ ​definiciones​ ​típicas​ ​de​ ​ingeniería: La creación de soluciones rentables ... Ingeniería no se trata sólo de resolver problemas; Se trata de resolver los problemas con el uso económico de todos los recursos,​ ​incluyendo​ ​el​ ​dinero. ...​ ​a​ ​los​ ​problemas​ ​prácticos​ ​... Ingeniería se ocupa de los problemas prácticos cuyas soluciones importa a la gente fuera​ ​de​ ​los​ ​dominios​ ​de​ ​ingeniería-los​ ​clientes. ... mediante la aplicación de conocimientos científicos ... Ingeniería resuelve los problemas de una manera particular: mediante la aplicación de la ciencia, las matemáticas​ ​y​ ​análisis​ ​de​ ​diseño. ...​ ​construir​ ​cosas​ ​... Ingeniería​ ​hace​ ​hincapié​ ​en​ ​las​ ​soluciones,​ ​que​ ​suelen​ ​ser​ ​los​ ​artefactos​ ​tangibles. ...​ ​al​ ​servicio​ ​de​ ​la​ ​humanidad Ingeniería no sólo sirve al cliente inmediata, sino que también desarrolla la tecnología y los​ ​conocimientos​ ​que​ ​apoyará​ ​la​ ​sociedad. Ingeniería se basa en la codificación de conocimiento científico acerca de un dominio del problema tecnológico en una forma que es directamente útil para el profesional, por lo tanto proporcionar respuestas para las preguntas que comúnmente ocurren en la práctica. Los ingenieros de talento ordinaria pueden entonces aplicar este conocimiento para resolver problemas mucho más rápido de lo que lo pudiera. De esta manera, la ingeniería acciones soluciones anteriores en lugar de confiar siempre en la resolución de​ ​problemas​ ​virtuoso. Práctica de la ingeniería permite a los profesionales ordinarias para crear sistemas sofisticados que trabajan a poco espectacular, tal vez, pero de forma fiable. La historia del desarrollo de software está marcada por los éxitos y los fracasos. Los éxitos han sido a menudo actuaciones virtuoso o el resultado de la diligencia y el trabajo duro. Los fracasos han reflejado a menudo pobre comprensión del problema a resolver, desajuste de solución al problema, o seguimiento inadecuado a través del diseño a la implementación. Algunas fracasaron por no trabajan, otros por invadiendo los presupuestos​ ​de​ ​costos​ ​y​ ​programas. En la práctica actual del software, el conocimiento de las técnicas que funcionan no se comparte de manera efectiva con los proyectos posteriores, ni hay un gran cuerpo de conocimiento organizado de desarrollo de software para una pronta referencia. La informática ha contribuido alguna teoría relevante, pero la práctica se procede en gran medida independiente de este conocimiento organizado. Teniendo en cuenta estos

antecedentes, existen problemas fundamentales con el uso del ingeniero de software plazo. de rutina y diseño innovador de diseño de ingeniería Las tareasson de varios tipos; una de las distinciones más importantes separa de rutina de diseño innovador. Diseño rutinario consiste en resolver los problemas familiares, la reutilización de gran parte de las soluciones anteriores. El diseño innovador, por el contrario, consiste en encontrar nuevas soluciones a los problemas que no conoce. Diseños originales son mucho más raramente necesitan que los diseños de rutina, por lo que el último es el pan de cada día​ ​de​ ​la​ ​ingeniería. Más de ingeniería disciplinas captura, organizar y compartir los conocimientos de diseño con el fin de hacer el diseño más simple rutina. Guías y manuales son a menudo los portadores de esta información organizada [Marcas 87, Perry 84]. Pero notaciones actuales para los diseños de software no son adecuados para la tarea de la grabación y diseños que se comunican, por lo que no pueden proporcionar una representación​ ​adecuada​ ​para​ ​tales​ ​manuales. Software en la mayoría de los dominios de aplicación se trata más a menudo como rutina- original que sin duda más de lo que sería necesario si hemos capturado y organizado lo que ya sabemos. Una vía para el aumento de la productividad es la identificación de las aplicaciones que podrían ser rutina y el desarrollo de un apoyo adecuado. Dada nuestra trayectoria, hay un problema fundamental con el uso del término “ingeniero​ ​de​ ​software” El enfoque actual de la reutilización destaca la captura y organizar el conocimiento existente de un tipo particular: el conocimiento expresado en forma de código. De hecho, las bibliotecas de subrutinas-especialmente de las llamadas al sistema y matemáticas de propósito general rutinas han sido un elemento básico de la programación durante décadas. Pero este conocimiento no puede ser útil si los programadores no conocen o no se les anima a utilizarlo. Además, los componentes de la biblioteca requieren más cuidado en el diseño, implementación y documentación de componentes​ ​similares​ ​que​ ​simplemente​ ​se​ ​incorporan​ ​en​ ​los​ ​sistemas. Los profesionales son conscientes de la necesidad de mecanismos para compartir la experiencia con buenos diseños. Este grito desde el desierto apareció en unos grupos de​ ​Ingeniería​ ​de​ ​Software: "En Chem E, cuando tenía que diseñar un intercambiador de calor, he utilizado un conjunto de referencias que me dijo cuáles eran las constantes ... y las ecuaciones de diseño​ ​estándar​ ​..​ ​.

"en general, a menos que yo, o alguien más en mi grupo de ingeniería, ha leído o recuerda y da a conocer una solución a un problema pasado, estoy condenado a recrear la solución. ... supongo ... la diferencia fundamental es la capacidad de armar pequeñas piezas del problema que son relativamente bien conocidos, sin tener que generar​ ​una​ ​solución​ ​a​ ​medida​ ​para​ ​cada​ ​aplicación​ ​... "Quiero dejar claro que yo soy consciente de las bibliotecas de algoritmos y código, pero son soluciones incompletas a lo que estoy describiendo. (Hay Manual ninguna de Perry​ ​de​ ​ingeniería​ ​de​ ​software.)" Este ex ingeniero químico se quejaba de que el software no cuenta con los mecanismos institucionalizados de una disciplina de ingeniería madura para la grabación y difundir demostrable buenos diseños y formas de elegir entre alternativas de diseño. Manual de Perry es el manual de diseño estándar para la ingeniería química; que es de aproximadamente 4 pulgadas de espesor x 8-1 / 2" x 11" , impreso en​ ​pequeña​ ​tipo​ ​en​ ​papel​ ​de​ ​seda​ ​[Perry​ ​84]. Un modelo para la evolución de una disciplina de ingeniería Históricamente, la ingeniería ha surgido de la práctica ad hoc en dos etapas: En primer lugar, las técnicas de gestión y producción permiten la producción de rutina. Más tarde, los problemas de la producción rutinaria estimulan el desarrollo de una ciencia de apoyo; la ciencia madura finalmente se fusiona con la práctica establecida para producir la práctica profesional de la ingeniería. Este modelo se representa en la figura 1. Las líneas inferiores seguimiento de la tecnología, y las líneas superiores muestran la forma en la entrada de las habilidades de producción y los conocimientos científicos contribuyen nueva​ ​capacidad​ ​a​ ​la​ ​práctica​ ​de​ ​la​ ​ingeniería.

Explotación de una tecnología comienza con la artesanía: un conjunto de problemas deben ser resueltos, y que se resuelven cualquier -que vías. Se resuelven por aficionados con talento y por virtuosos, pero hay una clase distinta profesional se dedica a problemas de este tipo en particular. La intuición y la fuerza bruta son los motores principales en el diseño y la construcción. El progreso es irregular, sobre todo antes de la llegada de una buena comunicación; por lo tanto, las soluciones se inventan y reinvented- La transmisión de conocimientos entre los artesanos es lento, en parte debido a las comunicaciones subdesarrollados, sino también por los aficionados con talento​ ​a​ ​menudo​ ​no​ ​reconocen​ ​ninguna​ ​necesidad​ ​especial​ ​para​ ​comunicarse. Sin embargo, la práctica ad hoc con el tiempo se mueve en el folclore. Esta etapa del desarrollo artesanal ve extravagante uso de los materiales disponibles. La construcción o la fabricación es a menudo para uso personal o local, o para el trueque, pero hay poca o ninguna producción a gran escala en previsión de reventa. Levantamientos granero comunidad son un ejemplo de esta etapa; por lo que es software escrito por

expertos​ ​en​ ​aplicaciones​ ​para​ ​sus​ ​propios​ ​fines. En algún momento, el producto de la tecnología se convierte en ampliamente aceptada y la demanda supera a la oferta. En ese punto, se hacen intentos para definir los recursos necesarios para la fabricación comercial y sistemática para reunir la experiencia de la explotación de estos recursos. El capital es necesario de antemano para comprar materias primas, por lo que las habilidades financieras se vuelven importantes,​ ​y​ ​la​ ​escala​ ​de​ ​funcionamiento​ ​aumenta​ ​con​ ​el​ ​tiempo. Como florece la práctica comercial, se requiere que los médicos expertos para la continuidad y la consistencia de esfuerzo. Ellos están capacitados en procedimientos establecidos de manera pragmática. La administración no puede saber por qué estos procedimientos funcionan, pero saben que los procedimientos funcionan y cómo enseñar a las personas a ejecutarlos. Los procedimientos son refinados, pero el refinamiento es impulsado de manera pragmática: una modificación se trató de ver si funciona, entonces incorporado en el procedimiento estándar si tiene éxito. Las consideraciones económicas conducen a las preocupaciones sobre la eficiencia de los procedimientos y el uso de materiales. La gente comienza a explorar formas para las instalaciones de producción para explotar la base de la tecnología; cuestiones económicas señalan a menudo problemas en la práctica comercial. Las estrategias de manejo​ ​para​ ​controlar​ ​el​ ​desarrollo​ ​de​ ​software​ ​encajan​ ​en​ ​este​ ​punto​ ​del​ ​modelo. Los problemas de la práctica actual menudo estimulan el desarrollo de una ciencia correspondiente. Con frecuencia hay una fuerte interacción productiva entre los usos comerciales y la ciencia emergente. En algún momento la ciencia se convierte en la madurez suficiente para ser un importante contribuyente a la práctica comercial. Esto marca el surgimiento de prácticas de ingeniería en el sentido que la conocemos hoy en día-base científica suficiente para que un núcleo de profesionales educados para aplicar la teoría de análisis de problemas y la síntesis de soluciones. En los siglos 18 y principios​ ​del​ ​19, "lo que estaba ocurriendo fue un dibujo gradual en conjunto de los intereses comunes en entendimientos físicas básicas de las ciencias naturales y la ingeniería. Por un lado, la reducción de muchas técnicas de ingeniería empírica a una base más científica fue esencial a nuevos avances de la ingeniería. por otro lado, esta relación ha sido útil y estimulante para nuevos avances en las ciencias naturales. una alianza importante y mutuamente estimulante entre las ciencias naturales y la ingeniería, un desarrollo que había sido desalentado durante siglos por Jhe larga influencia dominante de principios de​ ​pensamiento​ ​griego,​ ​fue​ ​por​ ​fin​ ​consumado"[51​ ​Finch,​ ​p.6]. La aparición de una disciplina de ingeniería permite el desarrollo tecnológico para pasar los límites previamente impuestas por confiar en la intuición; progreso con frecuencia

se vuelve dependiente de la ciencia como una función de fuerza. Se necesita una base científica para conducir análisis, que permite nuevas aplicaciones e incluso la segmentación de mercado a través de la variedad de productos. Se han hecho intentos para ganar suficiente control sobre el diseño para apuntar productos específicos bajo demanda. Por lo tanto, la ingeniería emerge de la explotación comercial que suplanta nave; la ingeniería moderna depende críticamente de la adición de bases científicas a la artesanía y la comercialización. Explotación de la tecnología depende no sólo de la ingeniería científica, sino también en la gestión y el cálculo de referencias de los recursos. La ingeniería y la ciencia se apoyan mutuamente: Ingeniería genera buenos problemas para la ciencia, y la ciencia, después de encontrar buenos problemas en las necesidades de la práctica, regresa soluciones viables. La ciencia a menudo no es impulsado por las necesidades inmediatas de la ingeniería; Sin embargo, los buenos problemas científicos a menudo se derivan de una comprensión de los problemas que la​ ​parte​ ​de​ ​ingeniería​ ​del​ ​campo​ ​es​ ​hacer​ ​frente. La práctica de la ingeniería de software ha sido objeto recientemente de la crítica [89 Dijkstra, Parnas 90]. A pesar de que la práctica actual del software no coincide con las expectativas habituales de una disciplina de ingeniería, el modelo descrito aquí sugiere que la búsqueda vigorosa de la ciencia aplicable y la reducción de esa ciencia a la práctica​ ​puede​ ​conducir​ ​a​ ​una​ ​disciplina​ ​de​ ​ingeniería​ ​de​ ​software​ ​de​ ​sonido. Pasamos ahora a dos ejemplos que sirven para hacer de este modelo concreto, a continuación, evaluar el estado actual de la práctica de software y sus perspectivas de seguir​ ​este​ ​camino​ ​evolutivo. Ejemplos​ ​de​ ​Ingeniería​ ​Tradicional La evolución de las disciplinas de ingeniería se demuestra por la ingeniería civil y química. La comparación de los dos también es iluminadora, porque tienen muy diferentes​ ​organizaciones​ ​de​ ​base. Ingeniería​ ​Civil:​ ​una​ ​base​ ​en​ ​la​ ​Teoría Originalmente llamada para distinguirla de la ingeniería militar, la ingeniería civil incluía todo de la ingeniería civil hasta la mitad del siglo 19. Divergencia de intereses llevó ingenieros especializados en otras tecnologías de romper, y hoy en día los ingenieros civiles son los expertos técnicos de la industria de la construcción. Ellos se ocupan principalmente a gran escala, los esfuerzos de construcción de capital intensivo, tales como edificios, puentes, presas, túneles, canales, carreteras, ferrocarriles, suministros públicos de agua y saneamiento. Por regla general, los esfuerzos de ingeniería civil implican grupos de tareas bien definidas que utilizan herramientas y tecnologías

apropiadas​ ​para​ ​ejecutar​ ​los​ ​planes​ ​bien​ ​trazados. Aparición​ ​de​ ​Ingeniería​ ​Civil A pesar de las grandes estructuras civiles se han construido desde antes de la historia, sólo en los últimos siglos hace que su diseño y construcción se basa en la comprensión teórica más que en la intuición y la experiencia acumulada. Ni la Edad Media ni el mundo antiguo mostraron ningún signo de la aplicación cuantitativa deliberada de las matemáticas a la determinación de las dimensiones y formas que caracteriza a la ingeniería civil moderna. Pero aún sin entendimiento formal, se documentaron reglas pragmáticas para los elementos que se repiten. Constructores prácticos habían intuiciones​ ​sobre​ ​la​ ​estática​ ​muy​ ​desarrollado​ ​y​ ​se​ ​basó​ ​en​ ​algunas​ ​reglas​ ​empíricas. La revolución científica del Renacimiento dio lugar a serios intentos por Galileo, Brunelleschi, y otros para explicar las estructuras y por qué funcionó. Durante un período de unos doscientos años hubo intentos de explicar la composición de las fuerzas de flexión y de una viga. Sin embargo, el avance se vio frenado durante mucho tiempo por problemas en la formulación de conceptos básicos, como la fuerza, en particular la idea de que la gravedad podría ser tratado como simplemente otra fuerza igual que todos los demás. Hasta los conceptos básicos fueron ordenados a cabo, no fue posible hacer un análisis adecuado del problema de combinar fuerzas (utilizando la suma de vectores) que ahora que enseñamos a estudiantes de primer año, ni tampoco era​ ​posible​ ​hacer​ ​frente​ ​a​ ​las​ ​fortalezas​ ​de​ ​los​ ​materiales. 1700 Varignon y Newton desarrolló la teoría de la estática para explicar la composición de las fuerzas y de Coulomb y de Navier explican flexión con la teoría de la resistencia de los materiales. Estos ahora proporcionan la base para la ingeniería civil. A mediados del siglo 18 ingenieros civiles fueron tabulación de propiedades de los materiales. La mitad del siglo 18 también vio los primeros intentos de aplicar la ciencia exacta de la construcción práctica. El Papa Benedicto ordenó un análisis de la cúpula de San Pedro en 1742 y 1743 para determinar la causa de las grietas y proponer reparaciones; el análisis se basa en el principio del desplazamiento virtual y se llevó a cabo con precisión (aunque el modelo ahora se sabe que no tienen en cuenta adecuadamente de la elasticidad). En 1850 fue posible para el Britannia tubular Puente de Robert Stephenson sobre el estrecho de Menai ser sometido a un análisis estructural formal. Por lo tanto, incluso después de las teorías básicas estaban en la mano, se tardó 150 años antes de que la teoría era lo suficientemente rico y lo suficientemente maduro para​ ​ser​ ​de​ ​utilidad​ ​directa​ ​en​ ​la​ ​escala​ ​de​ ​un​ ​diseño​ ​del​ ​puente. Estructura de obras públicas Ingeniería Civil se enraíza así en dos teorías científicas, que corresponden a dos problemas clásicos. Un problema es la composición de fuerzas: la búsqueda de la fuerza resultante cuando se combinan múltiples fuerzas. El

otro es el problema de la flexión: la determinación de las fuerzas dentro de una viga soportada en un extremo y ponderado en el otro. Dos teorías, la estática y la resistencia de los materiales, resolver estos problemas; Ambos fueron desarrollados alrededor de 1700. je moderna puede ser considerada como la aplicación de estas teorías​ ​al​ ​problema​ ​de​ ​la​ ​construcción​ ​de​ ​edificios. tradicional "Para las embarcaciones de casi dos siglos, en cuestión civil, con la ingeniería hechura tangible, se ha sometido a una una ciencia abstracta irresistible, de transición basado a partir de una tecnología matemática de cálculo de materiales. significada Cada una más nuevo resultado racional de diseño, investigación más económica dimensiones estructurales, análisis y o completamente de enfoque estructural nuevo analíticos;. posibilidades no hubiera hay aparente hubo problemas evidentes en limitaciones construcción edificio a las posibilidades que no se podía resolver​ ​por​ ​cálculo"[Straub​ ​64​ ​pp.236-241]. La transición de la artesanía a la práctica comercial se puede fechar extenso sistema de transporte de los romanos del siglo primero. La ciencia subyacente surgió alrededor de 1700, y se maduró a la aplicación exitosa de practicar algún momento entre mediados del siglo 18 y el siglo de mid-19th. La figura 2 pone los eventos significativos en​ ​nuestro​ ​modelo.

Figura​ ​2:​ ​Evolución​ ​de​ ​Ingeniería​ ​Civil Ingeniería Química: una base en la práctica el segundo ejemplo trata de un tipo muy diferente de la ingeniería, la ingeniería química. Esta disciplina se basa en

observaciones empíricas y no en una teoría científica. Se ocupa de problemas prácticos de fabricación de productos químicos; su alcance cubre la producción a escala industrial de productos químicos: disolventes, productos farmacéuticos, fibras sintéticas, caucho, papel, tintes, fertilizantes, productos derivados del petróleo, aceites de cocina, etc. Aunque la química proporciona la especificación y diseño de las reacciones básicas, el ingeniero químico es responsable de escalar las reacciones arriba de escala de laboratorio a escala industrial. Como resultado, la ingeniería química​ ​depende​ ​en​ ​gran​ ​medida​ ​de​ ​la​ ​ingeniería​ ​mecánica,​ ​así​ ​como​ ​la​ ​química. Aparición​ ​de​ ​Ingeniería​ ​Química Hasta finales del siglo 18, la producción química fue en gran medida una industria artesanal. La primera sustancia química producida a escala industrial era alcalino, necesaria para la fabricación de vidrio, jabón, y textiles. El primer proceso industrial económica para álcali surgió en 1789, mucho antes de la teoría atómica de la química explica la química subyacente. Por la mitad del siglo 19, la producción industrial de productos químicos de docenas había convertido a la región central de Inglaterra en un distrito de fabricación de productos químicos. Se aprobaron leyes para controlar la contaminación resultante, y los inspectores de control de contaminación, llamados inspectores​ ​alcalinos,​ ​monitoreados​ ​cumplimiento​ ​planta. Uno de estos inspectores alcalinos, GE Davis, trabajaban en el área de Manchester a finales de 1880. Se dio cuenta de que a pesar de las plantas estaba inspeccionando fabricados docenas de diferentes tipos de productos químicos, que no eran de diferentes procedimientos involucrados decenas. Se identificó un conjunto de operaciones funcionales que tuvieron lugar dentro de las empresas transformadoras y se utilizaron en la fabricación de diferentes productos químicos. Dio una serie de conferencias en 1887 en la Escuela Técnica de Manchester. Las ideas expuestas en estas conferencias fueron importados a los Estados Unidos por el MIT en la última parte del siglo y forman la base de la ingeniería química tal como se practica hoy en día. Esta estructura se denomina operaciones de la unidad; el término fue acuñado en 1915​ ​por​ ​Arthur​ ​D.​ ​Little. Estructura​ ​de​ ​Ingeniería​ ​Química Los problemas fundamentales de la ingeniería química son el control cuantitativo de las grandes masas de material en la reacción y el diseño de procesos a escala industrial rentables​ ​para​ ​las​ ​reacciones​ ​químicas. El modelo de operaciones unitarias afirma que los procesos de fabricación de productos químicos industriales pueden resolverse en un número relativamente pequeño de unidades, cada una de las cuales tiene una función definida y cada uno de

los cuales se utiliza repetidamente en diferentes tipos de procesos. Las operaciones unitarias son pasos como la filtración y la aclaración, intercambio de calor, destilación, cribado, separación magnética, y flotación. La base de la ingeniería química es, pues, una colección determinado pragmáticamente de funciones muy alto nivel que adecuada y​ ​apropiada​ ​describen​ ​los​ ​procesos​ ​a​ ​realizar. Este es un tipo muy diferente de la estructura de la de la ingeniería civil. Es una estructura​ ​pragmática,​ ​empírica,​ ​en​ ​lugar​ ​de​ ​una​ ​teórica. "La ingeniería química como ciencia ... no es un compuesto de la química y la ingeniería mecánica y civil, sino una ciencia de sí mismo, la base de que es esas operaciones unitarias que en su secuencia y coordinación adecuada constituyen un proceso químico como se llevó a cabo en el escala industrial. Estas operaciones, como la molienda, extracción, asar, cristalización, destilación, secado al aire, separar, y así sucesivamente, no son la materia de la química como tal, ni de la ingeniería mecánica. Su tratamiento es en la forma cuantitativa con adecuada exposición de las leyes que controlan ellos y de los materiales y equipos interesados en ellos es la provincia de la ingeniería química. es este énfasis selectiva sobre las operaciones de la unidad en sí en sus aspectos cuantitativos que diferencia el ingeniero químico de la química industrial, que se ocupa principalmente de procesos y productos generales"[Comité AIChE​ ​de​ ​Educación,​ ​1922,​ ​citado​ ​en​ ​van​ ​Antwerpen​ ​pp.111-​ ​12]. La transición de la artesanía a la práctica comercial se puede fechar a la introducción del proceso de LeBlanc de álcali en 1789. La ciencia surgió con la teoría atómica de Dalton a principios del siglo 19, y maduró al éxito de la fusión con a gran escala los procesos mecánicos en la década de 1890 . Figura 3 pone los eventos significativos en nuestro​ ​modelo.

Figura​ ​3:​ ​Evolución​ ​de​ ​Ingeniería​ ​Química Estado​ ​actual​ ​de​ ​la​ ​tecnología​ ​de​ ​software Pasamos ahora al software. Comenzamos estableciendo que el problema es adecuado considerar como un problema de ingeniería: la creación de soluciones rentables a los problemas prácticos ... construir cosas en el servicio de la humanidad. A continuación, nos dirigimos a la cuestión de si los desarrolladores de software hacen o puede hacer nunca esto mediante la aplicación del conocimiento científico. En el proceso de ingeniería​ ​de​ ​software​ ​posicionamos​ ​en​ ​el​ ​modelo​ ​evolutivo​ ​descrito​ ​anteriormente. Procesamiento​ ​de​ ​la​ ​información​ ​como​ ​unfuerza​ ​económica negocio de computadorasEstados Unidos, incluyendo ordenadores, periféricos, software empaquetado, y comunicaciones, fue de aproximadamente $ 150B en 1989 y se prevé que sea más de $ 230B de 1992. El componente de software empaquetado se prevé que crezca a partir de $ 23.7B a $ 37.5B en este período [DAG 89]. Servicios, incluida la integración de sistemas y desarrollo de software en la casa no se incluyen en​ ​estas​ ​cifras. A nivel mundial, las ventas de software ascendieron a alrededor de $ 65B en 1989. Esto no incluye el valor del desarrollo de software propio, que es una actividad mucho más grande. Las cifras mundiales son difíciles de estimar, pero el costo del software interno sólo en los EE.UU. pueden estar en el rango de $ 150B- $ 200B [CSTB 90]. No está claro cuánto modificación después de la liberación (el llamado "mantenimiento") se incluye en esta cifra. De este modo el software está llegando a dominar el costo de

procesamiento​ ​de​ ​la​ ​información. La presencia económica de procesamiento de la información también se da a conocer a través de los costes reales y de oportunidad de los sistemas que no funcionan ejemplos de fracasos abundan costoso sistema. Menos obvio es el costo de la computación que ni siquiera intentaron: retrasos de desarrollo de software tan grande como para desalentar a las nuevas solicitudes, gigabytes de datos primas sin procesar de los satélites y sondas espaciales, y así sucesivamente. A pesar de los éxitos muy reales (y bastante sustanciales), la letanía de los desajustes de costos, plazos y expectativas​ ​es​ ​familiar. La​ ​creciente​ ​papel​ ​del​ ​software​ ​en​ ​aplicaciones​ ​críticas de la Academia Nacional de Ingeniería (EE.UU.) recientemente seleccionado los diez logros de ingeniería más grandes de los últimos 25 años. De los diez, tres son informática logros: satélites de comunicaciones y de recopilación de información, el microprocesador y la comunicación de fibra óptica. Dos más son aplicaciones directas de los ordenadores: el diseño y la fabricación asistida por ordenador y la tomografía axial computarizada. Y la mayoría del resto son por ordenador intensiva: la llegada a la luna, materiales compuestos avanzados, el jumbo jet, láser, y la aplicación de la ingeniería genética para producir nuevos productos farmacéuticos y los cultivos [89] NAE. La conducta de la ciencia es impulsado cada vez más por los paradigmas computacionales de pie en pie de igualdad con los paradigmas teóricos y experimentales. Ambas disciplinas científicas y de ingeniería requieren cálculos muy sofisticados. Las demandas se expresan a menudo en términos de poder- de procesamiento en bruto un petabyte (10 ** 15) de almacenamiento '[Levin 89] -pero la comunidad Supercomputing "una (10 ** 18) procesador con memoria teraword / exaflop'​ ​reconoce​ ​cada​ ​vez​ ​desarrollo​ ​de​ ​software​ ​como​ ​un​ ​cuello​ ​de​ ​botella​ ​crítico.

Debido a la presencia generalizada de software, el objetivo apropiado para sus desarrolladores debería ser la prestación eficaz de la capacidad computacional de los usuarios reales en formas que responden a su necesidades- la distinción entre el componente computacional de un sistema y la aplicación se sirve a menudo es muy suave, el desarrollo de software efectivo ya menudo requiere experiencia en aplicaciones​ ​sustancialparte,...

de madurez de las técnicas de desarrollo de software Nuestras capacidades de desarrollo de software sin duda han mejorado en los 40 o más años de experiencia en programación progreso ha sido tanto cualitativa como cuantitativa Por otra se ha tomado​ ​diferentes​ ​formas​ ​en​ ​los​ ​mundos​ ​de​ ​la​ ​investigación​ ​y​ ​de​ ​la​ ​práctica. Uno de los más conocidos characterizati complementos de este progreso ha sido el cambio de la programación-en-el-pequeño para la programación-en-el-grande. También es útil observar un cambio que tuvo lugar 10 años antes de que, desde la programación a cualquier -que vías de programación- en-el-Smail. La Figura 4 resume estos cambios, los cuales describen el foco de atención de la comunidad de investigación​ ​de​ ​software. Antes de aproximadamente mediados de la década de 1960, la programación fue sustancialmente ad-hoc; fue un logro significativo para obtener un programa que se ejecute en absoluto. Sistemas de software complejos se creado- algunos funcionó bastante bien, pero su construcción fue altamente ya sea empírico o una actividad virtuosa. Para que los programas inteligible, se utilizó la mnemotécnica, tratamos de ser

precisos acerca de cómo escribir los comentarios, y escribimos especificaciones prosa. Nuestro énfasis se puso en pequeños programas, que era todo lo que podía manejar era previsible. Hemos llegado a comprender que las computadoras son procesadores de información simbólica, no el número sólo crunchers-una penetración significativa. Sin embargo, las abstracciones de algoritmos y estructuras de datos no aparecieron hasta 1967, cuando Knuth demostró la utilidad de pensar en ellos en forma aislada de los programas particulares that'happe ^ ellos .. Un cambio similar en las actitudes sobre las especificaciones ocurrió alrededor de la' misma tiempo, cuando Floyd mostró cómo fijar fórmulas lógicas de programas permite el razonamiento formal acerca de los programas. Así a finales de 1960 se observó un cambio de la elaboración de programas monolíticos de énfasis en algoritmos andjdata estructuras ^ pero los programas en cuestión seguían siendo simples programas que se ejecutan una vez y luego​ ​terminan. El cambio que tuvo lugar a mediados de la década de 1970, desde la programación-en-el-pequeño para PROGRAMACION- en-el-grande se pueden ver en los mismos términos. Atención de la investigación se dirigió a los sistemas complejos cuyas especificaciones fueron ocupa no sólo de las relaciones funcionales de las entradas y salidas, pero también con el rendimiento, la fiabilidad y los estados por los que pasó el sistema. Esto condujo a un cambio en el énfasis a las interfaces y la gestión del proceso de programación. Además, los datos de los sistemas complejos a menudo sobrevive a los programas y puede ser más valioso, por lo que tiene que preocuparse por la integridad y consistencia de las bases de datos. Muchos de nuestros programas (por ejemplo, el sistema de conmutación telefónica, o un sistema operativo de la computadora) no deben terminar. Estos sistemas requieren un tipo diferente de razonamiento que hacer programas que tengan entrada, calcular, producen una salida, y terminan: la secuencia de estados del sistema es a menudo mucho​ ​más​ ​importante​ ​que​ ​el​ ​(posiblemente​ ​indeseable)​ ​condición​ ​de​ ​terminación. Las herramientas y técnicas que acompañaron el paso de la programación de cualquier -que vías de programación-en-el-pequeña proporcionado primeros pasos hacia el desarrollo sistemático, la rutina de pequeños programas; También sembraron el desarrollo de una ciencia que sólo ha madurado en la última década. Las herramientas y técnicas que acompañaron el paso de programación- el desarrollo in-the-pequeña. programadores en la producción de los procesos de trabajo de programación-en-el-grande. Cambios​ ​significativos​ ​ende​ ​InvestigaciónAtención el desarrollo de softwarePrácticaprocedieron a grandes sistemas complejos mucho más rápido que la comunidad investigadora. Por ejemplo, el sistema de defensa antimisiles SAGE de la década de 1950 y el sistema de reserva de vuelos Sabre de la

década de 1960 eran los sistemas interactivos de éxito en una escala que excedían la madurez de la ciencia. Parece que han sido desarrollados por excelentes ingenieros que entienden los requisitos bien y aplicar métodos de diseño y desarrollo de otros procedimientos de ingeniería (por ejemplo, electricidad). Metodologías de desarrollo de software modernos pueden ser vistos como los procedimientos de gestión destinados a guiar​ ​a​ ​un​ ​gran​ ​número​ ​de​ ​desarrolladores​ ​a​ ​través​ ​de​ ​disciplinas​ ​similares. La ingeniería de software término fue introducido en 1968 [NAT069]. Boehm en 1976 propuso la definición, "la aplicación práctica del conocimiento científico en el diseño y construcción de programas de ordenador y la documentación asociada requerida para desarrollar, operar y mantener ellos"[Boehm76], Esta definición es consistente con las definiciones anteriores de la ingeniería, aunque Boehm observó la falta de conocimiento​ ​científico​ ​para Desafortunadamente, el término es ahora más a menudo usado para referirse a los modelos de ciclo de vida, metodologías de rutina ., técnicas de estimación de costos, los marcos de documentación, herramientas de gestión de la configuración, las técnicas de control de calidad, y otras técnicas para la normalización de las actividades de producción Estas tecnologías son característicos de la etapa comercial de la evolución, el software managementwould ser un término mucho más apropiadoingeniería.. base científica para la práctica de Engineering practice emerges from commercial practice by exploiting the results of a companion science. The scientific results must be mature and rich enough to model practical problems; they must also be organized in a form that is useful to practitioners. Computer science has a few models and theories that are ready to support practice, but packaging of these res ults for operational use is lacking. Maturity of Supporting Science Despite the criticism sometimes made by software producers that computer science is irrelevant to practical software, good models and theories have been developed in areas that have had enough time for the theories to mature. In the early 1960s, algorithms and data structures were simply created as part of each program. Some folklore grew up about good ways to do certain sorts of things, and it was transmitted informally; by the mid-1960s good programmers shared the intuition that if you get the data structures right, the rest of the program is much simpler. In the late 1960s algorithms and data structures began to be abstracted from individual programs, and their essential properties were described and analyzed. The 1970s saw substantial progress in supporting theories, including performance analysis as well as correctness. Concurrently, the programming implications of these abstractions were

explored;​ ​abstract​ ​data​ ​type​ ​research​ ​dealt​ ​with​ ​such​ ​issues​ ​as: ● ● ● ● ● ●

Specifications​ ​abstract​ ​models,​ ​algebraic​ ​axioms Software​ ​structure​ ​bundling​ ​representation​ ​with​ ​algorithms Language​ ​issues​ ​modules,​ ​scope,​ ​user-defined​ ​types Information​ ​hiding​ ​protecting​ ​integrity​ ​of​ ​information​ ​not​ ​in​ ​specification Integrity​ ​constraints​ ​invariants​ ​of​ ​data​ ​structures Rules​ ​for​ ​composition​ ​declarations

Both sound theory and language support were available by the early 1980s, and routine good​ ​practice​ ​now​ ​depends​ ​on​ ​this​ ​support.

Compiler construction is another good example. In 1960 simply writing a compiler at all was a major achievement; it is not clear that we really understood what a higher level language was. Formal syntax was first used systematically for Algol 60, and tools for processing it automatically (then called compiler-compilers, but now called parser

generators) were first developed in the mid-1960s and made practical in the 1970s. Also in the 1970s, we started developing theories of semantics and types, and the 1980s have​ ​brought​ ​significant​ ​progress​ ​toward​ ​the​ ​automation​ ​of​ ​compiler.construction. Both of these examples have roots in the problems of the 1960s and became genuinely practical in the 1980s. It takes a good twenty years from the time that work starts on a theory until it provides serious assistance to routine practice. Development periods of comparable length have also preceded the widespread use of systematic methods and technologies such as structured programming, Smalltalk, and unix [Redwine 84]. But the whole field of computing is only about 40 years old, and many theories are emerging in​ ​the​ ​research​ ​pipeline. Interaction​ ​Between​ ​Science​ ​and​ ​Engineering The development of good models within the software domain follows the pattern of Figure 5. We begin by solving problems any way we can manage. After some time we distinguish in those ad hoc solutions things that usually work and things that do not usually work. The ones that do work enter the folklore: people tell each other about them informally. As the folklore becomes more and more systematic, we codify it as written heuristics and rules of procedure. Eventually that codification becomes crisp enough to support models and theories, together with the associated mathematics. These can then help to improve practice, and experience from that practice can sharpen the theories. Further, the improvement in practice enables us to think about harder problems—which we first solve ad hoc, then find heuristics, eventually develop new models and theories, and so on. The models and theories do not have to be fully fleshed out for this process to assist practice: the initial codification of folklore may be useful​ ​in​ ​and​ ​of​ ​itself. This progression is illustrated in the use of machine language for control flow in the 1960s. In the late 1950s and the early 1960s, we did not have crisp notions about what an iteration or a conditional was, so we laid down special-purpose code, building each structure individually out of test and branch instructions. Eventually a small set of patterns emerged as generally useful, generally easy to get right, and generally at least as good as the alternatives. Designers of higher-level languages explicitly identified the most useful ones and codified them by producing special-purpose syntax. A formal result about the completeness of the structured constructs provided additional reassurance. Now, almost nobody believes that new kinds of loops should be invented as a routine practice. A few kinds of iterations and a few kinds of conditionals are captured in the languages. They are taught as control concepts that go with the language; people use them routinely, without concern for the underlying machine code.

Further experience led to verifiable formal specifications of the semantics of these statements and of programs that used them. Experience with the formalization in turn refined the statements supported in programming languages. In this way ad hoc practice entered a period of folklore and eventually matured to have conventional syntax and​ ​semantic​ ​theories​ ​that​ ​explain​ ​it. Where, then, does current software practice lie on the path to engineering? As Figure 6 suggests, it is still in some cases craft and in some cases commercial practice. A science is beginning to contribute results, and for isolated examples it is possible to argue that professional engineering is taking place. That is not, however, the common case.

There are good grounds to expect that there will eventually be an engineering discipline of software. Its nature will be technical, and it will be based in computer science. Though​ ​we​ ​have​ ​not​ ​yet​ ​matured​ ​to​ ​that​ ​state,​ ​it​ ​is​ ​an​ ​achievable​ ​goal. The​ ​next​ ​tasks​ ​for​ ​the​ ​software​ ​profession​ ​are​ ​to: ● pick an appropriate mix of short-term, pragmatic, possible purely empirical contributions​ ​that​ ​help​ ​to​ ​stabilize​ ​commercial​ ​practice​ ​and ● invest in long term efforts to develop and make available basic scientific contributions. Understand​ ​the​ ​Nature​ ​of​ ​Expertise Proficiency in any field requires not only higher-order reasoning skills but also a large store of facts together with a certain amount of context about their implications and

appropriate use. Studies demonstrate this across a wide range of problem domains, including medical diagnosis, physics, chess, financial analysis, architecture, scientific research,​ ​policy​ ​decision​ ​making,​ ​and​ ​others​ ​[Reddy​ ​88,​ ​pp.​ ​13-14;​ ​Simon​ ​89,​ ​pp.1]. An expert in a field must know around 50,000 chunks of information, where a chunk is any cluster of knowledge sufficiently familiar that it can be remembered rather than derived. Furthermore, in domains where there are full-time professionals, it takes no less than ten years for a world-class expert to achieve that level of proficiency [Simon 89,​ ​pp.2-4]. Thus, fluency in a domain requires content and context as well as skills. In the case of natural language fluency, Hirsch argues that abstract skills have driven out content; students are expected (unrealistically) to learn general skills from a few typical examples rather than by a "piling up of information"; intellectual and social skills are supposed to develop naturally without regard to the specific content [Hirsch 88]. However, says Hirsch, specific information is important at all stages. Not only are the specific facts important in their own right, but they serve as carriers of shared culture and shared values. A software engineer's expertise includes facts about computer science in general, software design elements, programming idioms, representations, and specific knowledge about the program of current interest. In addition, it requires skill with tools: the language, environment, and support software with which this program is implemented. Hirsch provides a list of some five thousand words and concepts that represent the information actually possessed by literate Americans. The list goes beyond simple vocabulary to enumerate objects, concepts, titles, and phrases that implicitly invoke cultural context beyond their dictionary definitions. Whether or not you agree in detail with its composition, the list and accompanying argument demonstrate the need for connotations as well as denotations of the vocabulary. Similarly, a programmer needs to know not only a programming language but also the system calls supported by the environment, the general-purpose libraries, the application-specific libraries, and how to combine invocations of these definitions effectively. He or she must be familiar with the global definitions of the program of current interest and the rules about their use. In addition,​ ​a​ ​developer​ ​of​ ​application​ ​software​ ​must​ ​understand​ ​application-area​ ​issues. The engineering of software would be better supported if we knew better what specific content a software engineer should know. We could organize the teaching of this material so that useful subsets are learned first, followed by progressively more sophisticated subsets. We could also develop standard reference materials as carriers of​ ​the​ ​content. Recognize​ ​Different​ ​Ways​ ​to​ ​Obtain​ ​Information

Given that a large body of knowledge is important to a working professional, we must ask how software engineers should acquire the knowledge, either as students or as working professionals. Generally speaking, there are three ways to obtain a piece of information ​you need: you can remember it, you can look it up, or you can derive it. These​ ​different​ ​distributions​ ​of​ ​costs:

Memorization requires a relatively large initial investment in learning the material, which is then available for instant use. Reference materials require a large investment by the profession for developing both the organization and the content; each individual student must then learn how to use the reference materials and then do so as a working professional. Deriving information may involve ad hoc creation from scratch, it may involve instantiation of a formal model, or it may involve inferring meaning from other available information; to the extent that formal models are available their formulation requires a substantial initial investment. Students first learn the models, then apply them in practice; since each new application requires the model to be applied anew, the cost in​ ​use​ ​may​ ​be​ ​quite​ ​high​ ​[SGR​ ​89]. Each professional's allocation of effort among these alternatives is driven by what he or she has already learned, by habits developed during that education, and by the reference materials available. At present, general-purpose reference material for software is scarce, though documentation for specific computer systems, programming languages, and applications may be quite extensive. Even when documentation is available, however, it may be under-used because it is poorly indexed or because software developers have learned to prefer fresh derivation to use of existing solutions. The​ ​same​ ​is​ ​true​ ​of​ ​subroutine​ ​libraries. Software engineering requires investment in the infrastructure cost—that is, in creating the materials required to organize information, especially reference material for practitioners. Encourage Routine Practice Good engineering practice for routine design depends on the engineer's command of factual knowledge and design skills and on the quality of

reference materials available. It also depends on the incentives and values associated with​ ​innovation. Unfortunately, computer science education has prepared software developers with a background that emphasizes fresh creation almost exclusively. Students learn to work alone and to develop programs from scratch. They are rarely asked to understand software systems they have not written. However, just as natural language fluency requires instant recognition of a core vocabulary, programming fluency should require an extensive vocabulary of definitions that the programmer can use familiarly, without repeated​ ​recourse​ ​to​ ​documentation. Brooks argues that argued the great hopes for software engineering is the cultivation of great designers [Brooks 86]. Indeed, innovative designs require great designers. But great designers problems building presentation designers from by of ordinary using scratch. It is unreasonable to expect a software designer or developer to take advantage of scientific theories or prior experience if the necessary information is not readily available. Scientific results need to be recast in operational form; the important information from prior experience must be extracted from particular examples. The content should include design elements, components, interfaces, interchange representations, and algorithms. A conceptual structure must be developed so that the information can be found when it is needed. These facts must be augmented with analysis techniques or guidelines to support selection of alternatives that best match the problem​ ​at​ ​hand​ ​[CSTB​ ​89]. A few examples of well-organized reference materials already exist. For example, the summary flowchart of Martin's sorting survey [Martin 71] captured in one page the information a designer needed to choose among the then-current sorting techniques. Cody & Waite's manual for implementing elementary mathematical functions [CW 80] gives for each the basic strategy and special considerations needed to adapt that strategy​ ​to​ ​various​ ​hardware​ ​architectures. Although engineering has traditionally relied on handbooks published in book form, a software engineers' handbook must be on-line and interactive. No other alternative allows for rapid distribution of updates at the rate this field changes, and no other alternative has the potential for smooth integration with on-line design tools. The on-line incarnation will require solutions to a variety of electronic publishing problems, including distribution, validation, organization and search, and collection and distribution of royalties. Software engineering would benefit from a shift of emphasis in which both reference materials and case studies of exemplary software designs are incorporated in the

curriculum. The discipline must find ways to reward preparation of material for reference use​ ​and​ ​the​ ​development​ ​of​ ​good​ ​case​ ​studies. Expect​ ​Professional​ ​Specializations systems specialties. administration long As knowledge software since programming required grown practice was large of long matures a has designer ago enough been separated toward or to resistant developer require engineering, from to continues specialization—for the explicit corresponding the body to recognition grow. of substantive​ ​In​ ​example,​ ​programming. In the coming decade we can expect to see specialization of two kinds: internal specialization as the technical content within the core of software grows deeper, and external specialization with an increased range of applications that require both substantive​ ​application​ ​knowledge​ ​and​ ​substantive​ ​computing​ ​knowledge. Internal specialties are already starting to be recognizable for communications, reliability, real-time programming, scientific computing, and graphics, among others. Since these specialties rely critically on mastery of a substantial body of computer science,​ ​they​ ​may​ ​be​ ​most​ ​appropriately​ ​organized​ ​as​ ​post-baccalaureate​ ​education. External specialization is becoming common, but the required dual expertise is usually acquired informally (and often incompletely). Computational specializations in various disciplines can be supported via joint programs involving both computer science and the application​ ​department;​ ​this​ ​is​ ​being​ ​done​ ​at​ ​some​ ​universities​ ​[NSF​ ​89]. Software engineering will require explicit recognition of specialties. Educational opportunities should be provided to support them. This should not However, be done at the cost of a solid foundation in computer science and, in the case of external specialization,​ ​in​ ​the​ ​application​ ​discipline. Improve Coupling Between Science and Commercial Practice Good science is often based on problems underlying the problems of production. This should be as true for computer science as for any other discipline.; it depends on strong interactions between researchers and practitioners. However, cultural differences, lack of access to large complex systems, and the sheer difficulty of understanding those systems have interfered with the communication that supports these interactions. Similarly, the adoption of results from the research community has been impeded by poor understanding of how to turn a research result into a useful element of a production environment. Some companies and universities are already developing cooperative programs​ ​to​ ​bridge​ ​this​ ​gap,​ ​but​ ​the​ ​logistics​ ​are​ ​often​ ​daunting. An engineering basis for software will evolve faster if constructive interaction between research​ ​and​ ​production​ ​communities​ ​can​ ​be​ ​nurtured.

Acknowledgements This work was supported by the US Department of Defense and a grant from Mobay corporation. The presentation benefitted from comments by Allen Newell, Norm Gibbs Frank Friedman, Tom Lane, and the authors of other papers in the special issue of IEEE Software in which it appeared. Most importantly, Eldon Shaw fostered my appreciation for engineering; without his support this paper would not have been possible,​ ​and​ ​it​ ​is​ ​dedicated​ ​to​ ​his​ ​memory.