Ingeniería del software - Ciclo de desarrollo

El software es un elemento lógico, por lo que tiene unas características muy diferentes a las del hardware:

El software se desarrolla, no se fabrica en el sentido clásico de la palabra. Ambas actividades se dirigen a la construcción de un "producto", pero los métodos son diferentes. Los costes del software se encuentran en la ingeniería, esto implica que los proyectos no se pueden gestionar como si lo fueran de fabricación. A mediados de la década de 1980, se introdujo el concepto de "fábrica de software", que recomienda el uso de herramientas para el desarrollo automático del software.

Si se representa gráficamente la proporción de fallos en función del tiempo, para el hardware se tiene la figura conocida como "curva de bañera". Al principio de su vida hay bastantes fallos (normalmente por defectos de diseño y/o fabricación), una vez corregidos se llega a un nivel estacionario (bastante bajo). Sin embargo conforme pasa el tiempo, aparecen de nuevo, por efecto de suciedad, malos tratos, temperaturas extremas y otras causas. El hardware empieza a estropearse.

El software no se estropea. La gráfica de fallos en función del tiempo, tendría forma de caída desde el principio, hasta mantenerse estable por tiempo casi indefinido. El software no es susceptible a los males del entorno que provocan el deterioro del hardware. Los efectos no detectados harán que falle el programa durante las primeras etapas de su vida, sin embargo una vez corregidas, no se producen nuevos errores. Aunque no se estropea, si puede deteriorarse. Esto sucede debido a los cambios que se efectúan durante su vida.

Cuando un componente hardware se estropea, se cambia por otro que actúa como una "pieza de repuesto", mientras que para el software, no es habitual este proceso, lo cual significa que el mantenimiento de los programas es muy complejo.

La mayoría del software se construye a medida, en vez de ensamblar componentes previamente creados. Por contra en el hardware se dispone de todo tipo de circuítos integrados, para fabricar de manera rápida un equipo completo. Los ingenieros de software no disponen de esta comodidad, aunque ya se están dando los primeros pasos en esta dirección, que facilitaria tanto el desarrollo de aplicaciones informáticas.

La formalización del proceso de desarrollo se define como un marco de referencia denominado ciclo de desarrollo del software o ciclo de vida del desarrollo del software o ciclo de vida del desarrollo. Se puede describir como, "el período de tiempo que comienza con la decisión de desarrollar un producto software y finaliza cuando se ha entregado éste". Este ciclo, por lo general incluye, una fase de requisitos, fase de diseño, fase de implantación, fase de prueba, y a veces, fase de instalación y aceptación.

En la siguiente figura cada área está asociada a una actividad específica del desarrollo, y se le asigna un porcentaje de incidencia en el costo del desarrollo que corresponde al número en ella inscrito. El área designada Operaciones comprende las actividades comúnmente asociadas al desarrollo de sistemas de información administrativos, mientras que el resto corresponde a actividades asociadas al desarrollo de software como producto.

El ciclo de desarrollo software se utiliza para estructurar las actividades que se llevan a cabo en el desarrollo de un producto software. A pesar de que no hay acuerdo acerca del uso y la forma del modelo, este sigue siendo útil para la comprensión y el control del proceso.

Seguidamente se exponen las distintas aproximaciones de desarrollo de software, en función del tipo de ciclo de vida:

A) Aproximación convencional

Se introdujo como una técnica rígida para mejorar la calidad y reducir los costos del desarrollo de software. Tradicionalmente es conocido como "modelo en cascada", porque su filosofía es completar un paso con un alto grado de exactitud, antes de empezar el siguiente.

Esquemáticamente se puede representar de la siguinte forma:

donde:

FACTIBILIDAD: Definir un concepto preferente para el producto de software y determinar su factibilidad de ciclo de vida y superioridad frente a otros conceptos.

REQUERIMIENTOS: Elaborar una especificación completa y validada de las funciones requeridas, sus interfaces y el rendimiento del producto de software.

DISEÑO: Elaborar una especificación completa y validada de la arquitectura global hardware-software, de la estructura de control y de la estructura de datos del producto, así como un esquema de los manuales de usuarios y planes de test.

DISEÑO DETALLADO: Elaborar una especificación completa y verificada de la estructura de control, de la estructura de datos, de las interfaces de relación, dimensionamiento y algoritmos claves de cada componente de programa (rutina con un máximo de 100 instrucciones fuentes).

CODIFICACION: Construir un conjunto completo y verificado de componentes de programas.

INTEGRACION: Hacer funcionar el producto de software compuesto de componentes de programa.

IMPLEMENTACION: Hacer funcionar el sistema global hardware-software incluyendo conversión de programas y datos, instalación y capacitación.

OPERACION Y MANTENCION: Hacer funcionar una nueva versión del sistema global.

TRANSICION: Realizar una sucesión limpia de este a otros eventuales productos.

En cada caso, "verificación" tienen la siguiente acepción:

VERIFICACION: Establecer la verdad de la correspondencia entre un producto de software y su especificación. Es decir: ¿ESTAMOS CONSTRUYENDO CORRECTAMENTE EL PRODUCTO?

Los principales problemas que se han detectado en esta aproximación son debidos a que se comienza estableciendo todos los requisitos del sistema:

• En muchas ocasiones no es posible disponer de unas especificaciones correctas desde el primer momento, porque puede ser difícil para el usuario establecer al inicio todos los requisitos.
  
  
• En otras hay cambio de parecer de los usuarios sobre las necesidades reales cuando ya se ha comenzado el proyecto, siendo probables los verdaderos requisitos no se reflejen en el producto final
  
  
• Otro de los problemas de esta aproximación es que los resultados no se ven hasta muy avanzado el proyecto, por lo tanto la realización de modificaciones, si ha habido un error, es muy costosa.
  

Esta aproximación es la más empleada por los ingenieros informáticos, aunque ha sido muy criticada, y de hecho se ha puesto en duda su eficacia. Entre los problemas que se pueden encontrar con este modelo, se tienen:

• Los proyectos raras veces siguen el modelo secuencial que se supone. Los cambios pueden causar confusión.
  
  
• Es difícil disponer en principio de todos los requisitos. Este modelo presenta dificultades en el momento de acomodar estas incertidumbres.
  
  
• La versión operativa de los programas no está disponible hasta que el proyecto está muy avanzado. Un error importante puede ser desastroso, si se descubre al final del proceso.
  
  
• Los responsables del desarrollo siempre se retrasan innecesariamente. Algunos integrantes del equipo de desarrollo han de esperar a otros para completar tareas pendientes.
  

B) Aproximación prototipo

Es habitual que en un proyecto software no se identifiquen los requisitos detallados de entrada, procesamiento o salida. En otros casos no se está seguro de la eficiencia de un algoritmo, o de la forma en que se ha de implantar la interface hombre-máquina.

En casos así, lo habitual es construir un prototipo, que idealmente sirviera como mecanismo para identificar los requisitos del software. Esta aproximación consiste en realizar la fase de definición de requisitos del sistema en base a estos tres factores:

• Un alto grado de iteración
  
  
• Un muy alto grado de participación del usuario
  
  
• Un uso extensivo de prototipos
  
  

Las premisas clave de esta aproximación son:

• Que los prototipos constituyen un medio mejor de comunicación que los modelos en papel
  
  
• Que la iteración es necesaria para canalizar, en la dirección correcta, el proceso de aprendizaje. Esta aproximación se enfoca a mejorar la efectividad del proceso de desarrollo y no a mejorar la eficacia de ese proceso.
  
  
• El problema, es que los usuarios finales, ven lo que parece ser una versión de trabajo del software, sin considerar que no es la versión definitiva y por lo tanto no se han considerado aspectos de calidad o facilidad de mantenimiento. Cuando se les dice, que el producto es a partir de entonces cuando se debe de empezar a "fabricar", no lo entiende y empieza de nuevo con ajustes, lo cual hace este proceso muy lento.
  

C) Aproximación evolutiva

En esta aproximación el énfasis está en lograr un sistema flexible y que se pueda expandir de forma que se pueda realizar muy rápidamente una versión modificada del sistema cuando los requisitos cambien.

Se diferencia de la aproximación anterior, en que en esta los requisitos cambian continuamente, lo cual implicaría en el caso previo que las iteraciones no tendrían fin.



D) Aproximación incremental

Es un concepto muy parecido al de desarrollo evolutivo, y frecuentemente comprendido en la aproximación del desarrollo evolutivo. Se comienza el desarrollo del sistema para satisfacer un subconjunto de requisitos especificados. Las últimas versiones prevén los requisitos que faltan. De esta forma se logra una rápida disponibilidad del sistema, que aunque incompleto, es utilizable y satisface algunas de las necesidades básicas de información.

La diferencia con la aproximación anterior es que en este caso cada versión parte de una previa sin cambios pero con nuevas funciones, mientras que la aproximación evolutiva cada vez se desarrolla una nueva versión de todo el sistema.

Un ejemplo de este paradigma se tiene en el desarrollo de una aplicación sencilla, como es un editor de textos. En el primer incremento se podría desarrollar con un reducido conjunto de funciones, como las funciones básicas de gestión de archivos. En un segundo incremento, se puede incluir la gestión avanzada de textos. Y en un tercer incremento se pondría la corrección ortográfica.

E) Aproximación espiral

Nace con el objetivo de captar lo mejor de la aproximación convencional y de la de prototipo, añadiendo un nuevo componente, el análisis de riesgos. Esquemáticamente se puede ilustrar mediante una espiral, con cuatro cuadrantes que definen actividades.

En la primera vuelta de la espiral se definen los objetivos, las alternativas y las restricciones y se analizan y se identifican los riesgos. Si como consecuencia del análisis de riesgo se observa que hay incertidumbre sobre el problema entonces en la actividad correspondiente a la ingeniería se aplicará la aproximación prototipo cuyo beneficio principal es el de reducir la incertidumbre de la naturaleza del problema de información y los requerimientos que los usuarios establecen para la solución a ese problema.

Al final de esta primera vuelta alrededor de la espiral el usuario evalúa los productos obtenidos y puede sugerir modificaciones. Se comenzaría avanzando alrededor del camino de la espiral realizando las cuatro actividades indicadas a continuación. En cada vuelta de la espiral, la actividad de ingeniería se desarrolla mediante la aproximación convencional o ciclo de desarrollo en cascada o mediante la aproximación de prototipos.

• Actividades
  
  
• Acciones
  
  
• Planificación Determinación de alternativas, identificación y resolución de riesgos
  
  
• Ingeniería
  
  
• Desarrollo y verificación del producto de siguiente nivel
  
  
• Evaluación del cliente
  
  
• Valoración de los resultados del proceso de desarrollo
  

F) Aproximación basada en transformaciones

Con la aparición de las herramientas CASE junto con los generadores de código, el ciclo de desarrollo software en cascada ha cambiado a un ciclo de vida basado en transformaciones.

CASE (Computer Aided Software Engineering), en castellano "Ingeniería de software Asistida por Computadora", es un conjunto de métodos, utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo de sistemas de información.

La utilización de herramientas CASE afecta a todas las fases del ciclo de vida del software. Este ciclo de vida se puede considerar como una serie de transformaciones. Primero se definen los requisitos del sistema, seguidamente existe un proceso de transformación que hace que la especificación se convierta en un diseño lógico del sistema. Posteriormente, este sufre otro proceso de transformación para lograr un diseño físico, es decir que responda a la tecnología destino.

La tecnología CASE propone que estos procesos de transformación sean lo más automatizables posible. Sus ventajas son:

• Posibilidad de comprobación de errores en etapas iniciales de desarrollo
  
  
• Posibilidad de realizar el mantenimiento en el ámbito de especificación
  
  
• Soporte de rastreabilidad de los requisitos
  
  
• Soporte de reusabilidad
  
  
• Potencia la especificación orientada al problema
  
  

El siguiente enlace ofrece una relación de tipos de CASE.