Al igual que en otros sistemas de
ingeniería, los sistemas de software requieren un tiempo y esfuerzo
considerable para su desarrollo y deben permanecer en uso por un periodo mucho
mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la
necesidad de construir un sistema de software hasta que este es retirado, se
identifican varias etapas que en conjunto se denominan el ciclo de vida del
software y en cada caso, en función de cuales sean las características del
proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se
consideran las etapas: especificación y análisis de requisitos, diseño del sistema, implementación
del software, aplicación y pruebas,
entrega y mantenimiento. Un
aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos
y especificaciones en cada fase. Dado que esta tarea siempre estará influida
por la fase del desarrollo en curso, se explicará de forma distribuida a lo
largo de las diferentes fases como un apartado especial para recalcar su
importancia en el conjunto del desarrollo del software.
Tal como ya hemos mencionado, las
etapas principales a realizar en cualquier ciclo de vida son:
- Análisis: Construye un modelo de los
requisitos
- Diseño: A partir del modelo de análisis
se deducen las estructuras de datos, la estructura en la que descompone el
sistema y la interfaz de usuario.
- Codificación: Construye el sistema. La salida
de esta fase es código ejecutable.
- Pruebas: Se comprueba que se cumplen
criterios de corrección y calidad.
- Mantenimiento: En esta fase, que tiene lugar
después de la entrega se asegura que el sistema siga funcionando y
adaptándose a nuevos requisitos.
Las etapas constan de tareas. La documentación es una tarea importante
que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios
documentos procedentes de las etapas anteriores y produce otros documentos de
salida según se muestra en la figura
Algunos autores dividen la fase del
diseño en dos partes: Diseño global
o arquitectónico y diseño detallado.
En el primero se transforman los requisitos en una arquitectura de alto nivel,
se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza
la documentación y se planifica la integración. En el detallado para cada
módulo se refina el diseño, se definen los requisitos del módulo y su
documentación.
Las formas de organizar y
estructurar la secuencia de ejecución de las tareas en las diferentes fases de
cada uno de los métodos puede dar lugar a un tipo de ciclo de vida diferente.
Los principales ciclos de vida que se van a presentar a continuación realizan
estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.
El ciclo de vida inicialmente
propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos
de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el
más ampliamente seguido por las organizaciones (se estima que el 90% de los
sistemas han sido desarrollados así). La estructura se muestra en la figura
Este modelo admite la posibilidad de
hacer iteraciones, es decir, durante las modificaciones que se hacen en el
mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el
diseño, lo cual significa que se harán los cambios necesarios en la
codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se
tiene que volver a una de las etapas anteriores al mantenimiento hay que
recorrer de nuevo el resto de las etapas.
Después de cada etapa se realiza una
revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es
decir, la entrada y la salida de cada fase es un tipo de documento específico.
Idealmente, cada fase podría hacerla un equipo diferente gracias a la
documentación generada entre las fases. Los documentos son:
- Análisis: Toma como entrada una descripción en
lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software
Requirements Document).
- Diseño: Su entrada es el S.R.D. Produce el S.D.D.
(Software Design Document)
- Codificación: A partir del S.D.D. produce
módulos. En esta fase se hacen también pruebas de unidad.
- Pruebas: A partir de los módulos probados se
realiza la integración y pruebas de todo el sistema. El resultado de las
pruebas es el producto final listo para entregar.
- La planificación es sencilla.
- La calidad del producto resultante es alta.
- Permite trabajar con personal poco cualificado.
- Lo peor es la necesidad de tener todos los
requisitos al principio. Lo normal es que el cliente no tenga
perfectamente definidas las especificaciones del sistema, o puede ser que
surjan necesidades imprevistas.
- Si se han cometido errores en una fase es difícil
volver atrás.
- No se tiene el producto hasta el final, esto
quiere decir que:
- Si se comete un error en la fase de análisis no
lo descubrimos hasta la entrega, con el consiguiente gasto inútil de
recursos.
- El cliente no verá resultados hasta el final,
con lo que puede impacientarse .
- No se tienen indicadores fiables del progreso del
trabajo (síndrome del 90%).1.1
- Es comparativamente más lento que los demás y el
coste es mayor también.
- Aquellos para los que se dispone de todas las
especificaciones desde el principio, por ejemplo, los de reingeniería.
- Se está desarrollando un tipo de producto que no
es novedoso.
- Proyectos complejos que se entienden bien desde
el principio.
Como el modelo en cascada ha sido
muy popular ha generado algunas variantes. Ahora veremos algunas.
Propuesto por Alan Davis, tiene las
mismas fases que el anterior pero se considera el nivel de abstracción de cada
una. Una fase además de utilizarse como entrada para la siguiente, sirve para
validar o verificar otras fases posteriores. Su estructura está representada en
la figura
Ciclo de vida en cascada con subproyectos
Si una vez
que se ha llegado al diseño arquitectónico, se comprueba que el sistema se
divide en varios subsistemas independientes entre sí, sería razonable suponer
que a partir de ese punto cada uno se puede desarrollar por separado y en
consecuencia en paralelo con los demás. Cada uno tendrá seguramente fechas de
terminación distintas. Una vez que han terminado todos se integran y se prueba
el sistema en su conjunto. La ventaja es que se puede tener a más gente
trabajando en paralelo de forma eficiente. El riesgo es que existan
interdependencias entre los subproyectos.
En este caso
se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los
pequeños incrementos es parecido a lo que ocurre dentro de la fase de
mantenimiento. La ventaja de este método es que no es necesario tener todos los
requisitos en un principio. El inconveniente es que los errores en la detección
de requisitos se encuentran tarde.
Hay dos
partes en el ciclo de vida, similares al anterior. Por un lado está el análisis
y el diseño global. Por otra parte están los pequeños incrementos, con las
fases de diseño detallado, codificación y mantenimiento..
No hay comentarios:
Publicar un comentario