Introducción a la ingeniería del software

Intentos de definición de la ingeniería del software

La expresión ingeniería del software se utilizó por primera vez en el año 1968, como tema de una conferencia organizada por la división de asuntos científicos de la OTAN. En dicha conferencia se llegó a la conclusión de la necesidad de una nueva disciplina científica con una gran orientación práctica que superara las limitaciones que la ciencia informática (computer science) había encontrado a la hora de realizar productos de software grandes y complejos. Ya entonces surgió la idea de aplicar técnicas típicas de la actividad de ingeniería a la construcción de software para incrementar, al mismo tiempo, tanto la productividad como la calidad del proceso de desarrollo de aplicaciones informáticas, así como para hacer más fácil el inevitable proceso de su mantenimiento.

Ya en 1969, en una nueva conferencia sobre el tema, Fritz Bauer caracterizaba la ingeniería del software como "el establecimiento y uso de principios de ingeniería robustos, orientados a obtener económicamente software que sea fiable y funcione con eficiencia sobre máquinas reales".

Con el tiempo han surgido otras definiciones de ingeniería del software, como la proporcionada por H.D. Mills en 1980, que la considera "un conjunto de disciplinas y procedimientos para la construcción y el mantenimiento de software viable y económico".

Es especialmente interesante la definición proporcionada en 1981 por Barry W. Boehm, el cual, tras analizar los conceptos de software e ingeniería define la ingeniería del software parafraseando la definición de ingeniería del diccionario Webster pero aplicándola concretamente al aprovechamiento del equipo informático y los ordenadores en concreto: "La aplicación de la ciencia y las matemáticas por la cual las capacidades de los ordenadores se hacen útiles a los humanos por medio de los programas de ordenador, los procedimientos y la documentación que los acompaña".

También encontramos un resumen adecuado del alcance de la ingeniería del software en la escueta y concisa definición de una famosísima asociación de profesionales: "Una perspectiva sistemática del desarrollo, la operación, el mantenimiento y la retirada del software" (IEEE, Institute of Electrical and Electronics Engineers, Standard Glossary of Software Engineering Terminology, 1983). Hay que destacar la incorporación de una fase necesaria de "retirada" o sustitución del software, que se añade a otras más fácilmente reconocidas: desarrollo, utilización y mantenimiento.

En todos los casos, la ingeniería del software se presenta como un enfoque sistemático y profesional que quiere producir software de calidad con el coste económico más bajo posible y cumpliendo los plazos de tiempo establecido.

La calidad de este software tiene que entenderse en el sentido de que no sólo sea útil a los usuarios, eficiente en el uso del hardware y no incorpore errores, sino que también permita un fácil mantenimiento.

Especificidad de la ingeniería del software

Evidentemente la creciente importancia de los costes del software informático y, principalmente, de su mantenimiento justifican la necesidad de un enfoque sistemático y profesional en la construcción de aplicaciones y sistemas informáticos. Pero, además, hay razones específicas que surgen de la particularidad del proceso de desarrollo y mantenimiento del software.

De hecho, los proyectos informáticos de construcción de software presentan unas características diferenciales que impiden gestionarlos con los mismos métodos y técnicas con que se gestionan otros proyectos de ingeniería.

La diferencia más significativa reside en el hecho de que, en los proyectos informáticos, el diseño y la construcción del sistema son un solo proceso y no hay una fase de diseño previa a la construcción o fabricación.

En realidad, la construcción de software es un mero proceso de diseño, pero el que este diseño adquiera finalmente la forma de una especificación final en un lenguaje ejecutable por ordenador asimila dicho diseño en un proceso que incluye también la fabricación, de modo que la comprobación de la calidad del software se hace francamente compleja y difícil.

Objetivos de la ingeniería del software

Hay dos objetivos centrales en la ingeniería del software: por una parte, obtener un producto de software de calidad (económico, fiable, eficiente y de uso y mantenimiento fáciles), y, por otra parte, construir ese software mediante un proceso correcto y adecuado que signifique una gestión eficaz de los recursos puestos a disposición del ingeniero de software para la construcción de un nuevo sistema informático: personas y recursos informáticos.

En definitiva, la ingeniería del software debe atender a la elaboración del software y a la gestión del proyecto que lleva a dicha elaboración.

Componentes de la ingeniería del software

Para conseguir los dos objetivos centrales de la ingeniería del software, Boehm analiza la existencia de tres componentes fundamentales: las relaciones humanas (human relations), la ingeniería de recursos (ressource engineering) y la ingeniería de programas (program engineering).

En lo que respecta al producto, las relaciones humanas se concretan en la necesidad de que el software producido sea fácil de utilizar y satisfaga necesidades reales; la ingeniería de recursos exige que el producto sea ajustable y adaptable y que su eficiencia proceda de un equilibrio adecuado entre los costes de producirlo y los beneficios obtenidos de utilizarlo; la ingeniería de programas se concreta en el hecho de que el software esté especificado con precisión de una manera completa, consistente, verificable y realizable, además del hecho de que sea correcto, así como intrínsecamente adaptable o modificable, por ejemplo, porque utiliza técnicas como la estructuración y porque garantiza la legibilidad y fácil comprensión de diseños y resultados.

En cuanto al proceso, el aspecto de las relaciones humanas representa planificación, organización, dirección y control del proceso de construcción del software y su posible automatización; la ingeniería de recursos presupone la adecuada estimación previa a la planificación y el correcto análisis de costes y beneficios, así como el control de los hitos o puntos cruciales del proyecto y el cumplimiento de plazos y presupuestos; por último, la ingeniería de programas exige la validación de la factibilidad del proyecto y de sus requerimientos y especificaciones, además de la verificación y validación del diseño, la programación y la misma integración del sistema y de su implementación y los procedimientos establecidos para su mantenimiento.

Para un especialista como Mills, todo esto se traduce en la incorporación y el dominio de técnicas procedentes de tres entornos conceptuales complementarios: el diseño, el desarrollo y la gestión.

En el diseño (software engineering design) tiene que atenderse a los temas más teóricos propios de la ciencia informática, como son los esquemas básicos de composición de algoritmos, la estructuración de datos y programas o el control de procesos múltiples y asíncronos en los sistemas distribuidos y en tiempo real.

En el desarrollo (software engineering development) se agrupan los procesos prácticos del desarrollo de software desde el punto de vista de las herramientas y técnicas puestas a disposición de las personas responsables de construir el producto final: entornos de desarrollo (lenguajes, ayudas, herramientas, etc.), procedimientos ordenados de desarrollo progresivo (top down) y técnicas formales de documentación de productos de software.

Por último, en la gestión (software engineering management) se agrupan todas las prácticas necesarias para valorar, planificar y controlar el trabajo de construir software y, en definitiva, gestionar el proyecto informático consistente en la elaboración de una determinada aplicación informática.

Principales etapas y actividades en el desarrollo del software

De una manera genérica, todo proceso de construcción de software pasa por etapas sucesivas cuyo nombre, contenido y detalle ha ido variando a lo largo del tiempo según los diferentes métodos utilizados. Si se une el inevitable mantenimiento y la retirada del software al desarrollo, se habla con más frecuencia de ciclo de vida que de "etapas", para marcar este carácter evolutivo y perecedero de cualquier aplicación informática.

Un esquema sencillo y clásico de este ciclo de vida es el que forman:

  1. el análisis de los requerimientos, funciones y objetivos del sistema y la elaboración de las especificaciones correspondientes;
  2. el diseño de una solución, lógica y técnica, que satisfaga las especificaciones;
  3. la implementación final del sistema, concretada en forma de procedimientos y, sobre todo, en la codificación de programas escritos ya en lenguaje fuente;
  4. la prueba del sistema;
  5. la instalación, la operación y el mantenimiento del sistema hasta que se decida retirarlo.

Distribución de costes en el desarrollo del software

Varios autores han analizado la distribución del coste global del desarrollo de un proyecto informático y, aunque las proporciones exactas pueden depender de cada sistema concreto y del método utilizado para construirlo, se aceptan como referencia general las cifras establecidas a finales de los años setenta por autores como Boehm y Brooks: un 40% del coste de desarrollar una aplicación informática se emplea en las etapas de análisis y diseño; sólo un 20%, en la etapa de codificación, y el resto, un 40%, queda para la parte correspondiente a las pruebas.

Desglose del porcentaje de esfuerzo en las etapas del ciclo de vida:

análisis y diseño 40%

codificación 20%

pruebas 40%

Por supuesto, el mantenimiento, uno de los costes más elevados del software, se ha dejado al margen de esta distribución, que se ocupa sólo de los costes del desarrollo hasta la puesta en marcha inicial, aunque ya se ha indicado que el mantenimiento suele representar el doble del coste del desarrollo, si bien se extiende a lo largo de un periodo de tiempo mucho más dilatado.

La figura 2 muestra un diagrama de la evolución del uso de recursos de personal a lo largo de un proyecto informático, con indicación de dos grandes etapas: desarrollo y mantenimiento, de momento separados de la puesta en marcha inicial. El diagrama es esquemático y, en la etapa de mantenimiento, es posible añadir varios picos puntuales causados por cambios de envergadura que una aplicación informática puede experimentar más de una vez en su vida.

Origen e importancia de los errores en el software

Estudios como los de T.C. Jones a finales de los años setenta han establecido que sólo un 30% de los errores presentes en el software proceden de la etapa de codificación. Se considera que un 15% de los errores procede de la fase de análisis y diseño funcional; un 20% más, de la fase de diseño lógico, y hasta un 35% son errores que tienen el origen en insuficiencias de la documentación, incomprensiones y malentendidos y otras causas a lo largo de todo el ciclo de desarrollo.

Origen de los errores de software:

15% de la fase de análisis

20% de la fase de diseño

30% de la fase de codificación

35% por documentación insuficiente, incomprensiones y malentendidos

Boehm ha mostrado que la importancia de los errores y el coste asociado a corregirlos difiere según la etapa en que se descubren. Tomando como base el coste de corregir un error de análisis descubierto en la etapa de análisis de requerimientos y elaboración de especificaciones, la corrección de un error detectado en la fase de diseño cuesta 7 veces más. El coste de corrección es 10 veces más alto si se detecta en la etapa de codificación, entre 20 y 50 veces más si se descubre en la fase de pruebas y hasta 100 veces más si se detecta ya en la fase final de operación y mantenimiento.

Por este motivo existe la necesidad de establecer métodos y procesos de desarrollo de software que permitan detectar los inevitables errores cuanto antes mejor. Encontramos un ejemplo claro de esto en la reciente tendencia a experimentar con prototipos provisionales para detectar, sobre todo, los errores creados en la fase de análisis de requerimientos y elaboración de especificaciones que no suelen detectarse hasta las pruebas finales de integración o aceptación del sistema.

Arriba
Cerrar