PDF de programación - El desarrollo del software

El desarrollo del software



1



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.



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

El desarrollo del software



2



G

M

T.I.



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.



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

El desarrollo del software



3



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 (con las especificaciones cumplidas) la anterior. Sin embargo, esto no es siempre
posible, y hay que recurrir a iteraciones (por ejemplo, entre el diseño y la codificación), que nos
lleven mediante aproximaciones sucesivas a cumplir con los objetivos de la mejor forma posible.

Desde el punto de vista jerárquico (véase el capítulo sobre las jerarquías) esta división en etapas
puede verse como una jerarquía multicapa de toma de decisiones. Así, cada una de las etapas (capa
de decisiones) termina cuando, tras haber hecho todas las elecciones necesarias, se han cumplido los
objetivos marcados, sentando las bases para la siguiente etapa. Al dividirse el problema en estas
capas, en cada momento del desarrollo nos enfrentamos con una complejidad menor (únicamente la
debida a cada capa, ya que las anteriores habrán sido satisfactoriamente resueltas).


3. El modelo de desarrollo en cascada.

Uno de estos modelos del ciclo de vida, quizás el más ampliamente utilizado, es el del desarrollo en
cascada. En él, cada etapa deja el camino preparado para la siguiente, de forma que esta última no

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

El desarrollo del software



4



debe comenzar hasta que no ha acabado aquélla. De esta forma, se reduce mucho la complejidad de
la gestión, ya que basta con no dar por terminada una etapa hasta que haya cumplido totalmente con
sus objetivos. De esta forma, la siguiente puede apoyarse con total confianza en ella. A la hora, por
ejemplo, de fijar plazos, se podrían establecer planes de una forma totalmente secuencial, quedando
perfectamente delimitadas las responsabilidades de los equipos que desarrollen cada etapa.

En la realidad la aplicación de este modelo no suele ser tan radical. Aunque se intenta conseguir la
mayor secuencialidad posible, es difícil evitar las "vueltas atrás". Si después de la terminación de
alguna etapa los resultados no son los esperados, en la práctica es muy posible que el problema esté
en la mala realización de una etapa anterior. Y esto es así porque no sabemos cómo decidir con total
certidumbre que una etapa ha sido perfectamente desarrollada hasta que se observan las
consecuencias, quizás varias etapas y bastante tiempo después de que fue "cerrada". En estos casos,
habrá que volver a ella, refinando el producto de una forma iterativa hasta que se considere que
tiene la calidad deseada.


Definición

Diseño

Codificación

Integración

Prueba

Documentación



Fig. 1. Modelo en cascada del desarrollo de software.

En el modelo "puro", las fases en que se suele dividir el ciclo de vida en este modelo son [Grady,
1990]:


a. Definición (análisis de los requerimientos software).
b. Diseño (podría dividirse en preliminar y detallado).
c. Codificación.
d. Integración.
e. Prueba.
f. Documentación.


Estas fases de desarrollarían una tras otra, excepto quizás las dos últimas. La prueba de módulos
podría realizarse después de la codificación y la del sistema completo tras la integración. La
documentación, por su parte, puede irse creando a lo largo de todo el proceso.

Sin embargo, los caminos reales que se siguen en el desarrollo de software suelen parecerse mucho
más a los que se pueden ver en la figura 2 (basada en [Fox, 1982]. En ella, las flechas que apuntan
en sentido descendente representarían el modelo puro, mientras que las ascendentes corresponden a
los demás caminos que se suelen seguir en la realidad.

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

El desarro