Puntos de Vista

Peter J. Denning y Richard D. Riehle

La Profesin de Tecnologa de la Informacin

La Ingeniera de Software es una Ingeniera?

La ingeniera de software contina siendo perseguida por declaraciones de que no es una ingeniera. Adoptar una visin ms de sistemas de computacin puede ayudar.
* Traducido de Communications of the ACM, Vol.52 Nro. 3 (Marzo 2009) pp.24-26
campo2. Sin embargo, el argumento de computacin como ingeniera an est disputado por los ingenieros tradicionales. La ingeniera de computacin (la arquitectura y el diseo de mquinas de computacin) es aceptado, pero la ingeniera de software sigue siendo controvertida. En esta columna examinamos los motivos para el persistente cuestionamiento sobre la ingeniera de software y sugerimos rumbos para superarlas.

Esta es una poca de considerable introspeccin para el campo de la computacin. Reconocemos la necesidad de trascender a la imagen tradicional, pero estrecha, de somos programadores. Esa imagen no indica nuestras responsabilidades mayores como profesionales de software y nos limita en nuestro seguimiento de un modelo ingenieril de la prctica del software. La bsqueda de una alternativa a la imagen del programador ya tiene una generacin de antigedad. En 1989 nos preguntamos: Somos matemticos? Cientficos? Ingenieros?1 Concluimos que ramos las tres cosas. Adoptamos el trmino computacin en analoga al europeo informtica para evitar el sesgo hacia cualquier etiqueta o descripcin. Actualmente queremos que los tres aspectos sean crebles en un mundo en expansin. Los argumentos de computacin como matemtica y como ciencia parecen estar ampliamente aceptados fuera de este

Proceso de Ingeniera
El diccionario define a la ingeniera como la aplicacin de principios cientficos y matemticos para lograr el diseo, manufactura y operacin de estructuras, mquinas, procesos y sistemas eficientes y econmicos. Cuando se la aplica a la ingeniera de software, esta definicin destaca la atencin a la importancia de la ciencia y los principios matemticos de la computacin. La ingeniera de software tambin ha contribuido principios para

manejar la complejidad en sistemas de software. Algunas definiciones insisten en que la ingeniera maneja propiedades de la materia y fuentes de energa en la naturaleza. Aunque la ingeniera de software no involucra directamente fuerzas de la naturaleza, esta diferencia es menos importante en la ingeniera moderna. El principal punto de discusin es si las prcticas ingenieriles de software son capaces de brindar software seguro, confiable y econmicamente realizable. Teniendo esto en cuenta los fundadores del campo de la ingeniera de software, en la legendaria conferencia de la NATO de 1968 propusieron que rigurosos procesos de ingeniera en el diseo e implantacin del software podra ayudar a salvar la crisis del software. En su forma ms general, el proceso de la ingeniera consiste en un ciclo repetido a travs de requerimientos, especificaciones, prototipos y pruebas. En la ingeniera de software, los modelos del proceso

han evolucionado en varias formas que van desde una planificacin altamente estructurada (cascadas, espirales, Vs y CMM) hasta giles relativamente poco estructurados (XP, SCRUM, Crystal y evolutivo). Ningn proceso es el mejor para todos los problemas. A pesar de la larga experiencia con estos procesos, ninguno brinda consistentemente sistemas de software seguros, confiables y econmicamente realizables. Aproximadamente un tercio de los proyectos de software fracasan no produciendo nada til y otro tercio terminan entregando algo que funciona, pero no satisfactoriamente. A menudo, an los proyectos exitosos toman un tiempo mayor al esperado y registran sobrecostos importantes. Los grandes sistemas, que se basan en una cuidadosa planificacin, suelen ser rutinariamente obsoletos para la poca de su entrega, aos despus que comenz su diseo3. El confiado seguimiento de un proceso por si mismo no es suficiente para alcanzar los resultados buscados por la ingeniera.

Prctica de Ingeniera
Gerald Weinberg escribi alguna vez si la ingeniera de software es verdaderamente una ingeniera, entonces debera ser capaz de aprender de las otras disciplinas de ingeniera. Robert Glass y sus colegas provocativamente evalua-

ron cun a menudo la bibliografa sobre ingeniera de software lo hace4. Concluyeron que la bibliografa se basa mucho en ancdotas de software y extrae muy ligeramente de otros campos de la ingeniera. Walter Tichy encontr que menos del 50% de los trabajos publicados sobre ingeniera de software verifican sus hiptesis, comparado con el 90% en la mayora de otros campos5. As la ingeniera de software puede sufrir a causa de nuestro hbito de prestar demasiada poca atencin a cmo otras ingenieras hacen ingeniera. En un extensivo estudio reciente sobre las prcticas que los ingenieros pretenden explcita o tcitamente, Riehle encontr seis que no hacemos bien6. Resultados predecibles (principio de la menor sorpresa). Los ingenieros creen que los comportamientos inesperados pueden ser no solo costosos, sino tambin peligrosos; en consecuencia trabajan duro para construir sistemas cuyo comportamiento pueden predecir. En la ingeniera de software tratamos de eliminar sorpresas derivando especificaciones rigurosas de requerimientos bien investigados, luego utilizando herramientas para la verificacin de programas y la administracin de procesos a fin de asegurar que se cumplen las especificaciones. El Risks Forum de ACM documenta una intermina-

ble serie de sorpresas en sistemas sobre los cuales esa atencin ha sido desperdiciada., Al escribir durante 2005 en el SIGSOFT de ACM, Riehle sugiri un aspecto cultural de esto: mientras que los investigadores y los artistas tienen una alta tolerancia, si no amor, por las sorpresas, los ingenieros hacen todo lo que est a su alcance para eliminar las sorpresas7. Muchos de nuestros desarrolladores han sido formados en una tradicin de investigacin, no en una tradicin de ingeniera. Mtricas de diseo, incluyendo diseo con tolerancias. Cada rama de la ingeniera moderna involucra mtricas de diseo, incluyendo los esfuerzos permitidos, tolerancias, rangos de comportamiento, complejidad estructural y probabilidades de falla en diversas condiciones. Los ingenieros de software no trabajan consistentemente con estas medidas. Tienden a usar simples medidas retrospectivas tales como lneas de cdigo o rangos de comportamiento con una prueba determinada. El desafo es incorporar ms de estas mtricas de diseo de la ingeniera tradicional en el proceso de desarrollo de software. Sangran da un ejemplo exitoso8. Tolerancia a fallas. Henry Petroski escribe una idea que unifique toda la ingeniera es el concepto de falla. Virtualmente cada clculo que

realiza un ingeniero es un clculo de falla para dar los lmites que no se pueden exceder. Probablemente no hay una tarea ms importante en la ingeniera que la administracin del riesgo. Los ingenieros de software podran verificar y examinar ms a fondo los modos de falla de sus soluciones de ingeniera y calcular los riesgos de todas las fallas que se identifiquen. Separacin del diseo de la implementacin. Para proyectos del mundo fsico los ingenieros y arquitectos representan un diseo con planos y pasan la implementacin a especialistas en la construccin. En la prctica actual, los ingenieros de software hacen ambos, disean y construyen (escriben los programas). La separacin de ambas actividades podra resultar mejor? Reconciliacin de fuerzas y restricciones en conflicto. Los ingenieros actuales enfrentan muchos balances entre fuerzas naturales y un vertiginoso despliegue de restricciones no tcnicas de orden econmico, regulatorias y lgicas que estn en conflicto. La ingeniera de software es similar, excepto que hay menos fuerzas que involucran al mundo natural. Adaptacin a los ambientes cambiantes. La mayor aprte de los ambientes que usan computacin cambian y se expanden constantemente. Con los prolongados procesos de

adquisicin que tienen los sistemas de software complejos, no es inusual para un sistema que resulte obsoleto para el momento de su entrega. Qu desperdicio! Manejar el desarrollo evolutivo es un nuevo desafo.

El sistema
Los problemas que rodean los seis tpicos sealados aqu son, en gran medida, la consecuencia de una visin demasiado estrecha del sistema por el cual es responsable el ingeniero de software. Aunque controlado por software, usualmente el sistema es una combinacin compleja de software, hardware y ambiente. La independencia de plataformas es un ideal de muchos sistemas de software. Significa que el software debera operar bajo una variedad de sistemas operativos y hardware de computacin. Para alcanzarlo, todas las funciones que dependan de la plataforma se renen en un mdulo que hace de interfase con la plataforma; en ese caso trasladar el sistema a otra plataforma implica slo la construccin de ese mdulo para la nueva plataforma. Ejemplosde estos son el componente Bsico del Sistema de Entrada-Salida (BIOS) de los sistemas operativos y la Mquina Virtual Java (JVM). Cuando esto se puede lograr, el ingeniero de software est justificado en una visin del sistema centrada en el software.

Pero no todos los sistemas de software son independientes de la plataforma. Un ejemplo prominente es el sistema de control para un avin avanzado. El sistema de control est implementado como un sistema distribuido a travs de muchos procesadores a lo largo de la estructura, donde puedan estar cerca de los sensores y superficies de control. Otro ejemplo es el software en cualquier gran sistema, que constantemente debe adaptarse a un ambiente rpidamente cambiante. En esos casos las caractersticas del hardware, las interconexiones y el ambiente influencian continuamente al diseo del software. El ingeniero de software debe o conocer bien el sistema o interactuar bien con alguien que lo haga. En tales casos resultar importante agregar a un ingeniero de sistemas al equipo.

Equipo de Ingeniera
No importa qu procesos de ingeniera utilice para lograr sus objetivos de sistemas, ellos tienen que formar y administrar un equipo de ingeniera. Se ha escrito mucho sobre este tpico. La currcula de ingeniera de software estn mejorando en ensear a los estudiantes cmo formar y trabajar en equipos efectivos, pero a muchos les falta mucho todava. Todo equipo de software tiene cuatro importantes roles que cumplir. Estos

roles pueden distribuirse entre diversas personas. El arquitecto de software rene los requerimientos y los convierte en especificaciones, busca lograr una comprensin de todo el sistema y sus caractersticas negociables, y desarrolla un plan de arquitectura para el sistema y las interfaces de sus usuarios. El ingeniero de software crea el sistema que cumple mejor el plan de arquitectura. Identifica y resuelve los conflictos y restricciones que no resolvi el arquitecto y disea controles y realimentaciones para resolverlos. El ingeniero tambin disea y supervisa las pruebas. El ingeniero tiene que tener experiencia y conocimiento como para disear una solucin econmica y efectiva con un resultado predecible. El programador convierte los diseos del ingeniero en cdigo verificado que funcione. Los programadores son solucionadores de problemas por derecho propio debido a que deben desarrollar progra-

mas eficientes y confiables para el diseo. Ms an, cualquiera que haya sido programador sabe cun fcil es cometer errores y cunto tiempo y esfuerzo se necesitan para detectar y eliminar los errores del cdigo. Cuando el ingeniero de software ha brindado una buena especificacin, con excepciones predefinidas conocidas y controles claramente delineados, el programador puede trabajar con un modelo que hace el trabajo de implementacin menos propenso a errores. El gerente de proyeco es responsable de coordinar todas las partes del equipo, cumplir con los programas de trabajo, conseguir los recursos y mantenerse dentro del presupuesto. El gerente de proyecto interacta con los interesados en el mismo, los arquitectos, ingenieros y programadores para asegurar que el proyecto resulta de valor para sus interesados. En algunos casos, como fue notado antes, se necesi-

tar tambin un ingeniero de sistemas en el equipo.

Conclusin
An no hemos llegado al punto en que la prctica de ingeniera de software pueda satisfacer todos los criterios de ingeniera descriptos en esta columna. Necesitamos herramientas ms efectivas, mejor educacin de ingeniera de software y una adopcin ms amplia de las prcticas ms efectivas. An ms, necesitamos alentar un sistema de pensamiento que comprenda al hardware y el ambiente del usuario tanto como el software. Al comprender las ideas fundamentales que vinculan todas las disciplinas de ingeniera podemos reconocer cmo dichas ideas contribuyen a una mejor produccin de software. Esto nos ayudar a construir la disciplina de referencia de ingeniera que Glass nos dice que nuestra profesin no encuentra. Dejemos descansar a esta controversia.

Denning, P. et al. Computing as a discipline. Commun. ACM 32, 1 (Jan 1989), 9-23. Denning, P. Computing is a natural science. Commun. ACM 50, 7 (July 2007), 13-18. 3 Denning, P., Gunderson, C. and Hayes Roth, R. Evolutionary system development. Commun. ACM 51, 12 (Dec 2008), 29-31. 4 Glass, R., Vessey, I. adn Ramesh, V. Research in software engineering: An analysis of the literature. Information and Software Technology 44, 8 (2002) 491-506. 5 Tichy, W. Should computer scientists experiment more? IEEE Computer (May 1998), 32-40. 6 Riehle, R. An Engineering Context for Software Engineering, PhD thesis, 2008; theses.nps.navy.mil/08Sep_Riehle_PhD.pdf 7 Riehle, R. Engineering on the surprise continuum: As applied to software practice. ACM SIGSOFT Software Engineering News 30, 5 (Sep 2005), 1-6. 8 Sangwan, R., Lin, L-P, and Neill, C. Structural complexity in architecture-centric software. IEEE Computer (Mar 2008), 96-99.
2