|
| Estás en:
ManyComics > Informática > Ingeniería del Software > Ciclo de vida del software
|
Ciclo de vida del software
| |
- "¿Podría decirme, por favor, qué camino debo tomar desde aquí?".
- "Eso depende, en gran medida, de a dónde quieras ir", dijo el Gato.
- "Eso no importa mucho", dijo Alicia.
- "Entonces no tienes problema con el camino que cojas", dijo el Gato.
- "...con tal de que llegue a alguna parte...", añadió Alicia como justificación.
- "Oh, seguro que lo harás", dijo el Gato, "con tal de que camines lo bastante".
|
Conversación con el Gato de Cheshire en
"Alicia en el País de las Maravillas". |
El desarrollo de software va unido a un ciclo de vida compuesto por
una serie de etapas que comprenden todas las actividades, desde el momento
en que surge la idea de crear un nuevo producto software, hasta aquel en
que el producto deja definitivamente de ser utilizado por el último
de sus usuarios.
Etapas en el ciclo.
Veamos, a grandes rasgos, una pequeña descripción de etapas
con que podemos contar a lo largo del ciclo de vida del software; una vez
delimitadas en cierta manera las etapas, habrá que ver la forma en
que estas se afrontan (existen diversos modelos de ciclo de vida,
y la elección de un cierto modelo para un determinado tipo de
proyecto puede ser de vital importancia; el orden de las etapas es un factor
importante, p.ej. tener una etapa de validación al final del proyecto,
tal como sugiere el modelo en cascada o lineal, puede implicar serios
problemas sobre la gestión de determinados proyectos; hay que tener
en cuenta que retomar etapas previas es costoso, y cuanto más tarde
se haga más costoso resultará, por tanto el hecho de contar
con una etapa de validación tardía tiene su riesgo y, por su
situación en el ciclo, un posible tiempo de reacción
mínimo en caso de tener que retornar a fases previas):
Expresión de necesidades- Esta etapa tiene como objetivo la consecución
de un primer documento en que queden reflejados los requerimientos y
funcionalidades que ofrecerá al usuario del sistema
a desarrollar (qué, y no cómo, se va a desarrollar).
Dado que normalmente se trata de necesidades del cliente para el que
se creará la aplicación, el documento resultante suele
tener como origen una serie de entrevistas cliente-proveedor situadas
en el contexto de una relación comercial, siendo que debe ser
comprendido por ambas partes (puede incluso tomarse como base para
el propio acuerdo comercial).
Especificaciones- Ahora se trata de formalizar los requerimientos; el
documento obtenido en la etapa anterior se tomará como punto de partida
para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones
que será necesario completar y depurar.
Por medio de esta etapa se obtendrá un nuevo documento que
definirá con más precisión el sistema requerido
por el cliente (el empleo de los casos de uso,
use cases, de Jacobson es una muy buena elección para
llevar a cabo la especificación del sistema).
Lo más normal será que no resulte posible obtener una
buena especificación del sistema a la primera; serán
necesarias sucesivas versiones del documento en que irán
quedando reflejada la evolución de las necesidades del cliente
(por una parte no siempre sabe en los primeros contactos todo lo que
quiere realmente, y por otra parte pueden surgir cambios externos que
supongan requerimientos nuevos o modificaciones de los ya contemplados).
Análisis- Es necesario determinar que elementos intervienen en el
sistema a desarrollar, así como su estructura, relaciones, evolución
en el tiempo, detalle de sus funcionalidades, ... que van a dar una descripción
clara de qué sistema vamos a construir, qué
funcionalidades va a aportar y qué comportamiento va a tener.
Para ello se enfocará el sistema desde tres puntos de vista
relacionados pero diferentes:
- Funcional.
- Estático.
- Dinámico.
Diseño- Tras la etapa anterior ya se tiene claro que debe hacer el sistema,
ahora tenemos que determinar como va a hacerlo (¿cómo debe
ser construido el sistema?; aquí se definirán en detalle entidades
y relaciones de las bases de datos, se pasará de casos de uso esenciales
a su definición como casos expandidos reales, se seleccionará el lenguaje
más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso,
librerías, configuraciones hardware, redes, etc.).
- Observación:
- Aunque todo debe ser tratado a su tiempo, y sería
muy deseable que las decisiones correspondientes en esta etapa fueran tomadas
precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones
previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se
dirán justificadas en simple política de empresa y por
mantener "compatibilidad" en lo que respecta a los demás proyectos
de la propia empresa, y en otras ocasiones por rumores de que tal o cual
herramienta mejoraría la velocidad de desarrollo u otro aspecto
de interés (en parte de los casos no serán rumores con
fundamento o estudios previos realizados al efecto, sino más
bien debidos a la propia publicidad como consejera).
Implementación- Llegado este punto se empieza a codificar algoritmos y estructuras de datos,
definidos en las etapas anteriores, en el correspondiente lenguaje de
programación y/o para un determinado sistema gestor de bases de
datos.
- Observación:
- Lamentablemente en la actualidad, año 2.000, quedan
bastantes empresas en las que, tras una reunión comercial en que tan solo se
ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse
a proyectos grandes-medios, se pasa directamente a la etapa de implementación;
son proyectos guiados por el riesgo que supone adoptar un modelo de ciclo de vida de
codificar-corregir (code
and fix) donde se eliminan las fases de especificaciones, análisis y diseño
con la consiguiente pérdida de control sobre la gestión del proyecto.
Pruebas- El objetivo de estas pruebas es garantizar que el sistema ha sido
desarrollado correctamente, sin errores de diseño y/o programación. Es
conveniente que sean planteadas al menos tanto a nivel de cada módulo
(aislado del resto), como de integración del sistema (según sea la
naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas
adicionales, p.ej. de rendimiento).
Validación- Esta etapa tiene como objetivo la verificación de que el
sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente
y que han dado lugar al presente proyecto (para esta fase también es
interesante contar con los use cases, generados a través de las
correspondientes fases previas, que servirán de guía para la
verificación de que el sistema cumple con lo descrito por estos).
Mantenimiento y evolución- Finalmente la aplicación resultante se encuentra ya en
fase de producción (en funcionamiento para el cliente, cumpliendo ya los
objetivos para los que ha sido creada). A partir de este momento se entra en la etapa
de mantenimiento, que supondrá ya pequeñas operaciones tanto de
corrección como de mejora de la aplicación (p.ej. mejora del rendimiento),
así como otras de mayor importancia, fruto de la propia
evolución (p.ej. nuevas opciones para el usuario debidas a
nuevas operaciones contempladas para el producto).
La mayoría de las veces en que se desarrolla una nueva
aplicación, se piensa sólamente en un ciclo de vida
para su creación, olvidando la posibilidad de que esta deba
sufrir modificaciones futuras (que tendrán que producirse con
casi completa seguridad para la mayor parte de los casos).
|
|
|
|
|
