Las perspectivas de una disciplina de ingeniera de software de

Mary Shaw
de septiembre de de 1990
CMU-CS-90-165

Facultad de Ciencias de la Computacin de la Universidad Carnegie Mellon de

Pittsburgh, PA 15213 a 3809
Este informe tambin aparecern en IEEE Software noviembre de 1990 y
como Carnegie Mellon University, Instituto de Ingeniera de Software Informe
tcnico CMU / SEI-90-TR-20, EDS-TR-90-221
Resumen
ingeniera de Softwaretodava no es una verdadera disciplina de ingeniera, pero
tiene el potencial para convertirse en uno. Campos de la ingeniera de ms edad
ofrecen atisbos del carcter ingeniera de software podra tener. A partir de estos
consejos y una evaluacin del estado actual de la prctica de software, podemos
proyectar algunas caractersticas de ingeniera de software tendr y sugerir
algunos pasos hacia una disciplina de ingeniera de software de
la ingeniera del software trmino fue acuado en 1968 como una declaracin de
aspiracin con una especie de grito de guerra. Ese ao la OTAN convoc un
taller con ese nombre para evaluar el estado y las perspectivas de la produccin
de software [69] de la OTAN. Capturar la imaginacin de los desarrolladores de
software, la frase logra popularidad durante la dcada de 1970. Ahora se hace
referencia a un conjunto de procesos de gestin, herramientas de software, y las
actividades de diseo para el desarrollo de software La prctica resultante, sin
embargo, difiere significativamente de la prctica de las formas ms antiguas de
la ingeniera.

1. Qu es la Ingeniera?
La ingeniera de software es una etiqueta aplicada a un conjunto de prcticas actuales
para el desarrollo de software. El uso de la palabra ingeniera para describir esta
actividad se lleva a una considerable libertad con el uso comn del trmino. Por el
contrario, el uso ms habitual se refiere a la aplicacin disciplinada de los
conocimientos cientficos para resolver las limitaciones y exigencias antagnicas de
problemas de importancia prctica inmediata.
Definiciones de muestreo de definiciones tpicas de ingeniera:
La creacin de soluciones rentables ... Ingeniera no se trata slo de resolver
problemas; Se trata de resolver los problemas con el uso econmico de todos los
recursos, incluyendo el dinero.
... a los problemas prcticos ...
Ingeniera se ocupa de los problemas prcticos cuyas soluciones importa a la gente
fuera de los dominios de ingeniera-los clientes.
... mediante la aplicacin de conocimientos cientficos ... Ingeniera resuelve los
problemas de una manera particular: mediante la aplicacin de la ciencia, las
matemticas y anlisis de diseo.
... construir cosas ...
Ingeniera hace hincapi en las soluciones, que suelen ser los artefactos tangibles.
... al servicio de la humanidad
Ingeniera no slo sirve al cliente inmediata, sino que tambin desarrolla la tecnologa y
los conocimientos que apoyar la sociedad.
Ingeniera se basa en la codificacin de conocimiento cientfico acerca de un dominio
del problema tecnolgico en una forma que es directamente til para el profesional, por
lo tanto proporcionar respuestas para las preguntas que comnmente ocurren en la
prctica. Los ingenieros de talento ordinaria pueden entonces aplicar este conocimiento
para resolver problemas mucho ms rpido de lo que lo pudiera. De esta manera, la
ingeniera acciones soluciones anteriores en lugar de confiar siempre en la resolucin
de problemas virtuoso.
Prctica de la ingeniera 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 comprensin del problema a resolver, desajuste
de solucin al problema, o seguimiento inadecuado a travs del diseo a la
implementacin. Algunas fracasaron por no trabajan, otros por invadiendo los
presupuestos de costos y programas.
En la prctica actual del software, el conocimiento de las tcnicas 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
informtica ha contribuido alguna teora relevante, pero la prctica 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 diseo innovador de diseo de ingeniera Las tareasson de varios tipos;
una de las distinciones ms importantes separa de rutina de diseo innovador. Diseo
rutinario consiste en resolver los problemas familiares, la reutilizacin de gran parte de
las soluciones anteriores. El diseo innovador, por el contrario, consiste en encontrar
nuevas soluciones a los problemas que no conoce. Diseos originales son mucho ms
raramente necesitan que los diseos de rutina, por lo que el ltimo es el pan de cada
da de la ingeniera.
Ms de ingeniera disciplinas captura, organizar y compartir los conocimientos de
diseo con el fin de hacer el diseo ms simple rutina. Guas y manuales son a
menudo los portadores de esta informacin organizada [Marcas 87, Perry 84]. Pero
notaciones actuales para los diseos de software no son adecuados para la tarea de la
grabacin y diseos que se comunican, por lo que no pueden proporcionar una
representacin adecuada para tales manuales.
Software en la mayora de los dominios de aplicacin se trata ms a menudo como
rutina- original que sin duda ms de lo que sera necesario si hemos capturado y
organizado lo que ya sabemos. Una va para el aumento de la productividad es la
identificacin de las aplicaciones que podran ser rutina y el desarrollo de un apoyo
adecuado.
Dada nuestra trayectoria, hay un problema fundamental con el uso del trmino
ingeniero de software
El enfoque actual de la reutilizacin destaca la captura y organizar el conocimiento
existente de un tipo particular: el conocimiento expresado en forma de cdigo. De
hecho, las bibliotecas de subrutinas-especialmente de las llamadas al sistema y
matemticas de propsito general rutinas han sido un elemento bsico de la
programacin durante dcadas. Pero este conocimiento no puede ser til si los
programadores no conocen o no se les anima a utilizarlo. Adems, los componentes de
la biblioteca requieren ms cuidado en el diseo, implementacin y documentacin 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 diseos. Este grito desde el desierto apareci en unos grupos
de Ingeniera de Software:
"En Chem E, cuando tena que disear un intercambiador de calor, he utilizado un
conjunto de referencias que me dijo cules eran las constantes ... y las ecuaciones de
diseo estndar .. .
"en general, a menos que yo, o alguien ms en mi grupo de ingeniera, ha ledo o
recuerda y da a conocer una solucin a un problema pasado, estoy condenado a
recrear la solucin. ... supongo ... la diferencia fundamental es la capacidad de armar
pequeas piezas del problema que son relativamente bien conocidos, sin tener que
generar una solucin a medida para cada aplicacin ...
"Quiero dejar claro que yo soy consciente de las bibliotecas de algoritmos y cdigo,
pero son soluciones incompletas a lo que estoy describiendo. (Hay Manual ninguna de
Perry de ingeniera de software.)"
Este ex ingeniero qumico se quejaba de que el software no cuenta con los
mecanismos institucionalizados de una disciplina de ingeniera madura para la
grabacin y difundir demostrable buenos diseos y formas de elegir entre alternativas
de diseo. Manual de Perry es el manual de diseo estndar para la ingeniera
qumica; que es de aproximadamente 4 pulgadas de espesor x 8-1 / 2" x 11" , impreso
en pequea tipo en papel de seda [Perry 84].
Un modelo para la evolucin de una disciplina de ingeniera Histricamente, la
ingeniera ha surgido de la prctica ad hoc en dos etapas: En primer lugar, las tcnicas
de gestin y produccin permiten la produccin de rutina. Ms tarde, los problemas de
la produccin rutinaria estimulan el desarrollo de una ciencia de apoyo; la ciencia
madura finalmente se fusiona con la prctica establecida para producir la prctica
profesional de la ingeniera. Este modelo se representa en la figura 1. Las lneas
inferiores seguimiento de la tecnologa, y las lneas superiores muestran la forma en la
entrada de las habilidades de produccin y los conocimientos cientficos contribuyen
nueva capacidad a la prctica de la ingeniera.
Explotacin de una tecnologa comienza con la artesana: un conjunto de problemas
deben ser resueltos, y que se resuelven cualquier -que vas. 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 intuicin y la fuerza bruta son los
motores principales en el diseo y la construccin. El progreso es irregular, sobre todo
antes de la llegada de una buena comunicacin; por lo tanto, las soluciones se inventan
y reinvented- La transmisin de conocimientos entre los artesanos es lento, en parte
debido a las comunicaciones subdesarrollados, sino tambin por los aficionados con
talento a menudo no reconocen ninguna necesidad especial para comunicarse.
Sin embargo, la prctica ad hoc con el tiempo se mueve en el folclore. Esta etapa del
desarrollo artesanal ve extravagante uso de los materiales disponibles. La construccin
o la fabricacin es a menudo para uso personal o local, o para el trueque, pero hay
poca o ninguna produccin a gran escala en previsin 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 algn momento, el producto de la tecnologa 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 fabricacin comercial y sistemtica para reunir la
experiencia de la explotacin 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 prctica comercial, se requiere que los mdicos expertos para la
continuidad y la consistencia de esfuerzo. Ellos estn capacitados en procedimientos
establecidos de manera pragmtica. La administracin no puede saber por qu estos
procedimientos funcionan, pero saben que los procedimientos funcionan y cmo
ensear a las personas a ejecutarlos. Los procedimientos son refinados, pero el
refinamiento es impulsado de manera pragmtica: una modificacin se trat de ver si
funciona, entonces incorporado en el procedimiento estndar si tiene xito. Las
consideraciones econmicas 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 produccin para explotar la base de la tecnologa; cuestiones
econmicas sealan a menudo problemas en la prctica comercial. Las estrategias de
manejo para controlar el desarrollo de software encajan en este punto del modelo.
Los problemas de la prctica actual menudo estimulan el desarrollo de una ciencia
correspondiente. Con frecuencia hay una fuerte interaccin productiva entre los usos
comerciales y la ciencia emergente. En algn momento la ciencia se convierte en la
madurez suficiente para ser un importante contribuyente a la prctica comercial. Esto
marca el surgimiento de prcticas de ingeniera en el sentido que la conocemos hoy en
da-base cientfica suficiente para que un ncleo de profesionales educados para
aplicar la teora de anlisis de problemas y la sntesis 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 fsicas bsicas de las ciencias naturales y la ingeniera. Por un lado,
la reduccin de muchas tcnicas de ingeniera emprica a una base ms cientfica fue
esencial a nuevos avances de la ingeniera. por otro lado, esta relacin ha sido til y
estimulante para nuevos avances en las ciencias naturales. una alianza importante y
mutuamente estimulante entre las ciencias naturales y la ingeniera, un desarrollo que
haba sido desalentado durante siglos por Jhe larga influencia dominante de principios
de pensamiento griego, fue por fin consumado"[51 Finch, p.6].
La aparicin de una disciplina de ingeniera permite el desarrollo tecnolgico para pasar
los lmites previamente impuestas por confiar en la intuicin; progreso con frecuencia
se vuelve dependiente de la ciencia como una funcin de fuerza. Se necesita una base
cientfica para conducir anlisis, que permite nuevas aplicaciones e incluso la
segmentacin de mercado a travs de la variedad de productos. Se han hecho intentos
para ganar suficiente control sobre el diseo para apuntar productos especficos bajo
demanda.
Por lo tanto, la ingeniera emerge de la explotacin comercial que suplanta nave; la
ingeniera moderna depende crticamente de la adicin de bases cientficas a la
artesana y la comercializacin. Explotacin de la tecnologa depende no slo de la
ingeniera cientfica, sino tambin en la gestin y el clculo de referencias de los
recursos. La ingeniera y la ciencia se apoyan mutuamente: Ingeniera genera buenos
problemas para la ciencia, y la ciencia, despus de encontrar buenos problemas en las
necesidades de la prctica, regresa soluciones viables. La ciencia a menudo no es
impulsado por las necesidades inmediatas de la ingeniera; Sin embargo, los buenos
problemas cientficos a menudo se derivan de una comprensin de los problemas que
la parte de ingeniera del campo es hacer frente.
La prctica de la ingeniera de software ha sido objeto recientemente de la crtica [89
Dijkstra, Parnas 90]. A pesar de que la prctica actual del software no coincide con las
expectativas habituales de una disciplina de ingeniera, el modelo descrito aqu sugiere
que la bsqueda vigorosa de la ciencia aplicable y la reduccin de esa ciencia a la
prctica puede conducir a una disciplina de ingeniera de software de sonido.
Pasamos ahora a dos ejemplos que sirven para hacer de este modelo concreto, a
continuacin, evaluar el estado actual de la prctica de software y sus perspectivas de
seguir este camino evolutivo.
Ejemplos de Ingeniera Tradicional
La evolucin de las disciplinas de ingeniera se demuestra por la ingeniera civil y
qumica. La comparacin de los dos tambin es iluminadora, porque tienen muy
diferentes organizaciones de base.
Ingeniera Civil: una base en la Teora
Originalmente llamada para distinguirla de la ingeniera militar, la ingeniera civil inclua
todo de la ingeniera civil hasta la mitad del siglo 19. Divergencia de intereses llev
ingenieros especializados en otras tecnologas de romper, y hoy en da los ingenieros
civiles son los expertos tcnicos de la industria de la construccin. Ellos se ocupan
principalmente a gran escala, los esfuerzos de construccin de capital intensivo, tales
como edificios, puentes, presas, tneles, canales, carreteras, ferrocarriles, suministros
pblicos de agua y saneamiento. Por regla general, los esfuerzos de ingeniera civil
implican grupos de tareas bien definidas que utilizan herramientas y tecnologas
apropiadas para ejecutar los planes bien trazados.
Aparicin de Ingeniera Civil
A pesar de las grandes estructuras civiles se han construido desde antes de la historia,
slo en los ltimos siglos hace que su diseo y construccin se basa en la comprensin
terica ms que en la intuicin y la experiencia acumulada. Ni la Edad Media ni el
mundo antiguo mostraron ningn signo de la aplicacin cuantitativa deliberada de las
matemticas a la determinacin de las dimensiones y formas que caracteriza a la
ingeniera civil moderna. Pero an sin entendimiento formal, se documentaron reglas
pragmticas para los elementos que se repiten. Constructores prcticos haban
intuiciones sobre la esttica muy desarrollado y se bas en algunas reglas empricas.
La revolucin cientfica del Renacimiento dio lugar a serios intentos por Galileo,
Brunelleschi, y otros para explicar las estructuras y por qu funcion. Durante un
perodo de unos doscientos aos hubo intentos de explicar la composicin de las
fuerzas de flexin y de una viga. Sin embargo, el avance se vio frenado durante mucho
tiempo por problemas en la formulacin de conceptos bsicos, como la fuerza, en
particular la idea de que la gravedad podra ser tratado como simplemente otra fuerza
igual que todos los dems. Hasta los conceptos bsicos fueron ordenados a cabo, no
fue posible hacer un anlisis adecuado del problema de combinar fuerzas (utilizando la
suma de vectores) que ahora que enseamos a estudiantes de primer ao, ni tampoco
era posible hacer frente a las fortalezas de los materiales.
1700 Varignon y Newton desarroll la teora de la esttica para explicar la composicin
de las fuerzas y de Coulomb y de Navier explican flexin con la teora de la resistencia
de los materiales. Estos ahora proporcionan la base para la ingeniera civil. A mediados
del siglo 18 ingenieros civiles fueron tabulacin de propiedades de los materiales. La
mitad del siglo 18 tambin vio los primeros intentos de aplicar la ciencia exacta de la
construccin prctica. El Papa Benedicto orden un anlisis de la cpula de San Pedro
en 1742 y 1743 para determinar la causa de las grietas y proponer reparaciones; el
anlisis se basa en el principio del desplazamiento virtual y se llev a cabo con
precisin (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 anlisis estructural formal.
Por lo tanto, incluso despus de las teoras bsicas estaban en la mano, se tard 150
aos antes de que la teora era lo suficientemente rico y lo suficientemente maduro
para ser de utilidad directa en la escala de un diseo del puente.
Estructura de obras pblicas Ingeniera Civil se enraza as en dos teoras cientficas,
que corresponden a dos problemas clsicos. Un problema es la composicin de
fuerzas: la bsqueda de la fuerza resultante cuando se combinan mltiples fuerzas. El
otro es el problema de la flexin: la determinacin de las fuerzas dentro de una viga
soportada en un extremo y ponderado en el otro. Dos teoras, la esttica y la
resistencia de los materiales, resolver estos problemas; Ambos fueron desarrollados
alrededor de 1700. je moderna puede ser considerada como la aplicacin de estas
teoras al problema de la construccin de edificios.
tradicional "Para las embarcaciones de casi dos siglos, en cuestin civil, con la
ingeniera hechura tangible, se ha sometido a una una ciencia abstracta irresistible, de
transicin basado a partir de una tecnologa matemtica de clculo de materiales.
significada Cada una ms nuevo resultado racional de diseo, investigacin ms
econmica dimensiones estructurales, anlisis y o completamente de enfoque
estructural nuevo analticos;. posibilidades no hubiera hay aparente hubo problemas
evidentes en limitaciones construccin edificio a las posibilidades que no se poda
resolver por clculo"[Straub 64 pp.236-241].
La transicin de la artesana a la prctica 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 aplicacin exitosa de practicar algn momento entre
mediados del siglo 18 y el siglo de mid-19th. La figura 2 pone los eventos significativos
en nuestro modelo.

Figura 2: Evolucin de Ingeniera Civil

Ingeniera Qumica: una base en la prctica el segundo ejemplo trata de un tipo muy
diferente de la ingeniera, la ingeniera qumica. Esta disciplina se basa en
observaciones empricas y no en una teora cientfica. Se ocupa de problemas
prcticos de fabricacin de productos qumicos; su alcance cubre la produccin a
escala industrial de productos qumicos: disolventes, productos farmacuticos, fibras
sintticas, caucho, papel, tintes, fertilizantes, productos derivados del petrleo, aceites
de cocina, etc. Aunque la qumica proporciona la especificacin y diseo de las
reacciones bsicas, el ingeniero qumico es responsable de escalar las reacciones
arriba de escala de laboratorio a escala industrial. Como resultado, la ingeniera
qumica depende en gran medida de la ingeniera mecnica, as como la qumica.

Aparicin de Ingeniera Qumica

Hasta finales del siglo 18, la produccin qumica fue en gran medida una industria
artesanal. La primera sustancia qumica producida a escala industrial era alcalino,
necesaria para la fabricacin de vidrio, jabn, y textiles. El primer proceso industrial
econmica para lcali surgi en 1789, mucho antes de la teora atmica de la qumica
explica la qumica subyacente. Por la mitad del siglo 19, la produccin industrial de
productos qumicos de docenas haba convertido a la regin central de Inglaterra en un
distrito de fabricacin de productos qumicos. Se aprobaron leyes para controlar la
contaminacin resultante, y los inspectores de control de contaminacin, 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 qumicos, 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 fabricacin de diferentes productos qumicos. Dio una serie de
conferencias en 1887 en la Escuela Tcnica 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 ingeniera qumica tal como se practica hoy en
da. Esta estructura se denomina operaciones de la unidad; el trmino fue acuado en
1915 por Arthur D. Little.
Estructura de Ingeniera Qumica
Los problemas fundamentales de la ingeniera qumica son el control cuantitativo de las
grandes masas de material en la reaccin y el diseo de procesos a escala industrial
rentables para las reacciones qumicas.
El modelo de operaciones unitarias afirma que los procesos de fabricacin de
productos qumicos industriales pueden resolverse en un nmero relativamente
pequeo de unidades, cada una de las cuales tiene una funcin definida y cada uno de
los cuales se utiliza repetidamente en diferentes tipos de procesos. Las operaciones
unitarias son pasos como la filtracin y la aclaracin, intercambio de calor, destilacin,
cribado, separacin magntica, y flotacin. La base de la ingeniera qumica es, pues,
una coleccin determinado pragmticamente 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 ingeniera civil. Es una
estructura pragmtica, emprica, en lugar de una terica.
"La ingeniera qumica como ciencia ... no es un compuesto de la qumica y la
ingeniera mecnica y civil, sino una ciencia de s mismo, la base de que es esas
operaciones unitarias que en su secuencia y coordinacin adecuada constituyen un
proceso qumico como se llev a cabo en el escala industrial. Estas operaciones, como
la molienda, extraccin, asar, cristalizacin, destilacin, secado al aire, separar, y as
sucesivamente, no son la materia de la qumica como tal, ni de la ingeniera mecnica.
Su tratamiento es en la forma cuantitativa con adecuada exposicin de las leyes que
controlan ellos y de los materiales y equipos interesados en ellos es la provincia de la
ingeniera qumica. es este nfasis selectiva sobre las operaciones de la unidad en s
en sus aspectos cuantitativos que diferencia el ingeniero qumico de la qumica
industrial, que se ocupa principalmente de procesos y productos generales"[Comit
AIChE de Educacin, 1922, citado en van Antwerpen pp.111- 12].
La transicin de la artesana a la prctica comercial se puede fechar a la introduccin
del proceso de LeBlanc de lcali en 1789. La ciencia surgi con la teora atmica de
Dalton a principios del siglo 19, y madur al xito de la fusin con a gran escala los
procesos mecnicos en la dcada de 1890 . Figura 3 pone los eventos significativos en
nuestro modelo.
Figura 3: Evolucin de Ingeniera Qumica
Estado actual de la tecnologa de software
Pasamos ahora al software. Comenzamos estableciendo que el problema es adecuado
considerar como un problema de ingeniera: la creacin de soluciones rentables a los
problemas prcticos ... construir cosas en el servicio de la humanidad. A continuacin,
nos dirigimos a la cuestin de si los desarrolladores de software hacen o puede hacer
nunca esto mediante la aplicacin del conocimiento cientfico. En el proceso de
ingeniera de software posicionamos en el modelo evolutivo descrito anteriormente.
Procesamiento de la informacin como unfuerza econmica
negocio de computadorasEstados Unidos, incluyendo ordenadores, perifricos,
software empaquetado, y comunicaciones, fue de aproximadamente $ 150B en 1989 y
se prev que sea ms de $ 230B de 1992. El componente de software empaquetado se
prev que crezca a partir de $ 23.7B a $ 37.5B en este perodo [DAG 89]. Servicios,
incluida la integracin 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
ms grande. Las cifras mundiales son difciles de estimar, pero el costo del software
interno slo en los EE.UU. pueden estar en el rango de $ 150B- $ 200B [CSTB 90]. No
est claro cunto modificacin despus de la liberacin (el llamado "mantenimiento") se
incluye en esta cifra. De este modo el software est llegando a dominar el costo de
procesamiento de la informacin.
La presencia econmica de procesamiento de la informacin tambin se da a conocer
a travs 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
computacin 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 satlites y sondas espaciales, y as sucesivamente. A pesar de los xitos muy
reales (y bastante sustanciales), la letana de los desajustes de costos, plazos y
expectativas es familiar.
La creciente papel del software en aplicaciones crticas
de la Academia Nacional de Ingeniera (EE.UU.) recientemente seleccionado los diez
logros de ingeniera ms grandes de los ltimos 25 aos. De los diez, tres son
informtica logros: satlites de comunicaciones y de recopilacin de informacin, el
microprocesador y la comunicacin de fibra ptica. Dos ms son aplicaciones directas
de los ordenadores: el diseo y la fabricacin asistida por ordenador y la tomografa
axial computarizada. Y la mayora del resto son por ordenador intensiva: la llegada a la
luna, materiales compuestos avanzados, el jumbo jet, lser, y la aplicacin de la
ingeniera gentica para producir nuevos productos farmacuticos y los cultivos [89]
NAE.
La conducta de la ciencia es impulsado cada vez ms por los paradigmas
computacionales de pie en pie de igualdad con los paradigmas tericos y
experimentales. Ambas disciplinas cientficas y de ingeniera requieren clculos muy
sofisticados. Las demandas se expresan a menudo en trminos 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 crtico.
Debido a la presencia generalizada de software, el objetivo apropiado para sus
desarrolladores debera ser la prestacin eficaz de la capacidad computacional de los
usuarios reales en formas que responden a su necesidades- la distincin entre el
componente computacional de un sistema y la aplicacin se sirve a menudo es muy
suave, el desarrollo de software efectivo ya menudo requiere experiencia en
aplicaciones sustancialparte,...

de madurez de las tcnicas de desarrollo de software Nuestras capacidades de

desarrollo de software sin duda han mejorado en los 40 o ms aos de experiencia en
programacin progreso ha sido tanto cualitativa como cuantitativa Por otra se ha
tomado diferentes formas en los mundos de la investigacin y de la prctica.
Uno de los ms conocidos characterizati complementos de este progreso ha sido el
cambio de la programacin-en-el-pequeo para la programacin-en-el-grande.
Tambin es til observar un cambio que tuvo lugar 10 aos antes de que, desde la
programacin a cualquier -que vas de programacin- en-el-Smail. La Figura 4 resume
estos cambios, los cuales describen el foco de atencin de la comunidad de
investigacin de software.
Antes de aproximadamente mediados de la dcada de 1960, la programacin 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 construccin fue altamente ya sea emprico o una actividad
virtuosa. Para que los programas inteligible, se utiliz la mnemotcnica, tratamos de ser
precisos acerca de cmo escribir los comentarios, y escribimos especificaciones prosa.
Nuestro nfasis se puso en pequeos programas, que era todo lo que poda manejar
era previsible. Hemos llegado a comprender que las computadoras son procesadores
de informacin simblica, no el nmero slo crunchers-una penetracin 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 cmo
fijar frmulas lgicas de programas permite el razonamiento formal acerca de los
programas. As a finales de 1960 se observ un cambio de la elaboracin de
programas monolticos de nfasis en algoritmos andjdata estructuras ^ pero los
programas en cuestin seguan siendo simples programas que se ejecutan una vez y
luego terminan.
El cambio que tuvo lugar a mediados de la dcada de 1970, desde la
programacin-en-el-pequeo para PROGRAMACION- en-el-grande se pueden ver en
los mismos trminos. Atencin de la investigacin se dirigi a los sistemas complejos
cuyas especificaciones fueron ocupa no slo de las relaciones funcionales de las
entradas y salidas, pero tambin 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
gestin del proceso de programacin. Adems, los datos de los sistemas complejos a
menudo sobrevive a los programas y puede ser ms 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 conmutacin telefnica, 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 ms importante que el (posiblemente indeseable) condicin de terminacin.
Las herramientas y tcnicas que acompaaron el paso de la programacin de cualquier
-que vas de programacin-en-el-pequea proporcionado primeros pasos hacia el
desarrollo sistemtico, la rutina de pequeos programas; Tambin sembraron el
desarrollo de una ciencia que slo ha madurado en la ltima dcada. Las herramientas
y tcnicas que acompaaron el paso de programacin- el desarrollo in-the-pequea.
programadores en la produccin de los procesos de trabajo de
programacin-en-el-grande.
Cambios significativos ende InvestigacinAtencin
el desarrollo de softwarePrcticaprocedieron a grandes sistemas complejos mucho
ms rpido que la comunidad investigadora. Por ejemplo, el sistema de defensa
antimisiles SAGE de la dcada de 1950 y el sistema de reserva de vuelos Sabre de la
dcada de 1960 eran los sistemas interactivos de xito en una escala que excedan la
madurez de la ciencia. Parece que han sido desarrollados por excelentes ingenieros
que entienden los requisitos bien y aplicar mtodos de diseo y desarrollo de otros
procedimientos de ingeniera (por ejemplo, electricidad). Metodologas de desarrollo de
software modernos pueden ser vistos como los procedimientos de gestin destinados a
guiar a un gran nmero de desarrolladores a travs de disciplinas similares.
La ingeniera de software trmino fue introducido en 1968 [NAT069]. Boehm en 1976
propuso la definicin, "la aplicacin prctica del conocimiento cientfico en el diseo y
construccin de programas de ordenador y la documentacin asociada requerida para
desarrollar, operar y mantener ellos"[Boehm76], Esta definicin es consistente con las
definiciones anteriores de la ingeniera, aunque Boehm observ la falta de
conocimiento cientfico para
Desafortunadamente, el trmino es ahora ms a menudo usado para referirse a los
modelos de ciclo de vida, metodologas de rutina ., tcnicas de estimacin de costos,
los marcos de documentacin, herramientas de gestin de la configuracin, las
tcnicas de control de calidad, y otras tcnicas para la normalizacin de las actividades
de produccin Estas tecnologas son caractersticos de la etapa comercial de la
evolucin, el software managementwould ser un trmino mucho ms
apropiadoingeniera..
base cientfica para la prctica 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
problemswhich 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 costthat 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
specializationfor 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.