DESARROLLO DE SOFWARE

El desarrollo del software 1

Complejidad y Tecnologías de la Información (Tecnologías de la información)

El desarrollo del software.

Introducción.

El ciclo de vida.

El modelo de desarrollo en cascada.

Definición.

Diseño.

Codificación.

Integración.

Prueba.

Documentación.

Los "productos intermedios".

Resumen.

Bibliografía.

No disponemos de herramientas, ni siquiera de metodologías, que nos permitan transformar el software ordinario en otro que sea fiable y fácilmente mantenible. Los sistemas software medianamente grandes suelen estar "plagados" de errores, y realizar cambios en ellos es, cuando menos, una tarea arriesgada.

Frente a este duro panorama, nos encontramos con la necesidad de acometer el desarrollo de programas cada vez mayores. Para poder realizar estos desarrollos con la mejor calidad posible se hace necesaria la utilización de ciertas estrategias que, si bien no garantizan un buen resultado, si suelen mejorar bastante las características del producto desarrollado.

El desarrollo del software 2

Complejidad y Tecnologías de la Información (Tecnologías de la información)

1. Introducción.

Como puede leerse en [Grady, 1990], hoy por hoy no disponemos de herramientas, ni siquiera de metodologías, que nos permitan transformar el software ordinario en otro que sea fiable y fácilmente mantenible. En el campo del hardware, por el contrario, esta anhelada situación está mucho más cerca de la realidad. Así, disponemos de chips que son a la vez extremadamente complejos y muy fiables. Sin embargo, los sistemas software medianamente grandes suelen estar "plagados" de errores, y realizar cambios en ellos es, cuando menos, una tarea arriesgada.

Esta diferencia puede ser debida al hecho de que el desarrollo de hardware siempre ha estado constreñido por limitaciones físicas (por ejemplo, densidad de integración). Así, la evolución se ha hecho "paso a paso", añadiendo complejidad poco a poco en cada uno de estos pasos, a medida que se lograba introducir más componentes en una superficie dada. Pero el software no tiene este tipo de limitaciones, con lo que desde el principio tenemos una gran cantidad de complejidad, que hemos de manejar de alguna forma.

Por eso, el gran desafío con que se encuentra la gestión de proyectos software consiste precisamente en limitar los productos que se desarrollan en esos proyectos a unos niveles de complejidad aceptables y manejables. Dicho de otra forma, se pretende reducir los grados de libertad en la producción de software para, al operar dentro de unos ciertos márgenes, mantener la complejidad resultante lo más baja posible.

Esto ha llevado a la concepción y uso de varios modelos del ciclo de vida. Con ellos se intenta descomponer los problemas de la gestión del proyecto de forma lógica, a la vez que generar productos tras cada etapa del modelo. Estos productos pueden ser usados para comprobar si estamos moviéndonos en la dirección deseada, o si por el contrario nos apartamos de los objetivos de complejidad previstos. Al fin y al cabo, utilizamos la acreditada técnica del "divide y vencerás".

Para enmarcar el estudio de los problemas relacionados con el desarrollo de software, señalemos que estamos tratando con uno de los llamados sistemas antropotécnicos, dentro del modelo de tres niveles de complejidad de Sáez Vacas (véase el capítulo sobre Marcos Conceptuales). El lector estará de acuerdo con esta afirmación si piensa que el proceso de desarrollo de programas un poco grandes implica la gestión y coordinación de los esfuerzos de numerosos grupos de personas, ayudadas de herramientas tecnológicas cada vez más avanzadas.

MT.I.G

El desarrollo del software 3

Complejidad y Tecnologías de la Información (Tecnologías de la información)

2. El ciclo de vida.

En principio, el ciclo de vida de un proyecto software incluye todas las acciones que se realizan sobre él desde que se especifican las características que debe tener, hasta que se mantiene en operación. A veces (aunque no será éste nuestro caso) se incluyen en el ciclo de vida las modificaciones que pueden realizarse al sistema para adaptarse a nuevas especificaciones.

Podría pensarse que el ciclo de vida de un programa no tiene por qué seguir un desarrollo "lineal", entendiendo como tal una sucesión de etapas. En principio, las distintas actividades que se realizan son bastante independientes, y pueden llevarse (hasta cierto punto) en paralelo. Por ejemplo, para empezar a codificar hay que tener mínimamente claras las especificaciones que hay que cumplir. Pero (aunque no es una buena decisión, como veremos más adelante), podría pensarse en comenzar la producción de código mientras se completan las especificaciones, para poder irlo probando, por ejemplo. Más adelante se harían las modificaciones necesarias.

Pero si el desarrollo de productos software ya es algo complejo en sí mismo (véase el capítulo sobre Medidas o Métricas de la Complejidad del Software), aún lo complicaremos más si intentamos "hacerlo todo a la vez", sin seguir una cuidadosa y detallada planificación. Y esto es precisamente lo que pretenden los modelos del ciclo de vida del software: simplificar en lo posible la gestión del proceso de desarrollo. La meta está en añadir la mínima complejidad que sea posible a la que de por sí ya implica el software.

Desde el punto de vista del esquema HxIxO->IO, podríamos decir que los modelos del ciclo de vida son un instrumento conceptual (I) que permite a la persona encargada (H) de gestionar un desarrollo de software (el O será por tanto el propio proceso de desarrollo) tratar con un problema más sencillo (el IO resultante).

Para ello, estos modelos dividen el proceso de desarrollo en unas cuantas etapas bien diferenciadas, y definen los posibles caminos por los que se deben relacionar. Además intentan que estos caminos lleven a un "progreso lineal", en el sentido de que antes de comenzar una etapa se haya concluido exitosamente

...