Etapas en la vida de un sistema de información.
Un sistema de información es un sistema, automatizado o manual, que engloba a personas,
máquinas y/o métodos organizados para recopilar, procesar, transmitir datos que representan
información. Un sistema de información engloba la infraestructura, la organización, el
personal y todos los componentes necesarios para la recopilación, procesamiento,
almacenamiento, transmisión, visualización, diseminación y organización de la información.
Cualquier sistema de información va pasando por una serie de fases a lo largo de su vida. Su
ciclo de vida comprende una serie de etapas entre las que se encuentran las siguientes:
- Planificación
- Análisis
- Diseño
- Implementación
- Pruebas
- Instalación o despliegue
- Uso y mantenimiento.
Planificación. Las tareas iniciales que se
realizarán esta fase inicial del proyecto incluyen actividades tales como la determinación del
ámbito del proyecto, la realización de un estudio de viabilidad, el análisis de los riesgos
asociados al proyecto, una estimación del coste del proyecto, su planificación temporal y la
asignación de recursos a las distintas etapas del proyecto.
La planificación es fundamental en la gestión de un proyecto de desarrollo de software.
Procure siempre mantener su plan al día. Un plan que no se ajusta a la realidad no sirve de
mucho. Cuando algún retraso indique que posiblemente le será imposible cumplir los plazos
establecidos, hable con su cliente. A él le interesa saberlo y, aunque probablemente no se lo
agradezca, a la larga resultará beneficioso y usted habrá cumplido con su obligación
profesional.
Analisis. La etapa de análisis en el ciclo de vida del
software corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente
se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las
características que el sistema debe poseer).
¿Por qué resulta esencial la etapa de análisis? Simplemente, porque si no sabemos con
precisión qué es lo que se necesita, ningún proceso de desarrollo nos permitirá obtenerlo. El
problema es que, de primeras, puede que ni nuestro cliente sepa de primeras qué es
exactamente lo que necesita. Por tanto, deberemos ayudarle a averiguarlo con ayuda de
distintas técnicas (algunas de las cuales aprenderemos a utilizar más adelante).
Diseño. Mientras que los modelos utilizados en la etapa de análisis representan los requisitos del
usuario desde distintos puntos de vista (el qué), los modelos que se utilizan en la fase de
diseño representan las características del sistema que nos permitirán implementarlo de forma
efectiva (el cómo).
Un software bien diseñado debe exhibir determinadas características. Su diseño debería ser
modular en vez de monolítico. Sus módulos deberían ser cohesivos (encargarse de una tarea concreta y sólo de una) y estar débilmente acoplados entre sí (para facilitar el mantenimiento
del sistema). Cada módulo debería ofrecer a los demás unos interfaces bien definidos (al
estilo del diseño por contrato propuesto por Bertrand Meyer) y ocultar sus detalles de
implementación (siguiendo el principio de ocultación de información de Parnas). Por último,
debe ser posible relacionar las decisiones de diseño tomadas con los requerimientos del
sistema que las ocasionaron (algo que se suele denominar "trazabilidad de los
requerimientos").
En la fase de diseño se han de estudiar posibles alternativas de implementación para el
sistema de información que hemos de construir y se ha de decidir la estructura general que
tendrá el sistema (su diseño arquitectónico). El diseño de un sistema es complejo y el
proceso de diseño ha de realizarse de forma iterativa. La solución inicial que propongamos
probablemente no resulte la más adecuada para nuestro sistema de información, por lo que
deberemos refinarla. Afortunadamente, tampoco es necesario que empecemos desde cero.
Existen auténticos catálogos de patrones de diseño que nos pueden servir para aprender de los
errores que otros han cometido sin que nosotros tengamos que repetirlos.
Implementaciòn. Para la fase de implementación hemos de seleccionar las herramientas adecuadas, un entorno
de desarrollo que facilite nuestro trabajo y un lenguaje de programación apropiado para el tipo
de sistema que vayamos a construir. La elección de estas herramientas dependerá en gran
parte de las decisiones de diseño que hayamos tomado hasta el momento y del entorno en el
que nuestro sistema deberá funcionar.
A la hora de programar, deberemos procurar que nuestro código no resulte indescifrable. Para
que nuestro código sea legible, hemos de evitar estructuras de control no estructuradas, elegir
cuidadosamente los identificadores de nuestras variables, seleccionar algoritmos y estructuras
de datos adecuadas para nuestro problema, mantener la lógica de nuestra aplicación lo más
sencilla posible, comentar adecuadamente el texto de nuestros programas y, por último,
facilitar la interpretación visual de nuestro código mediante el uso de sangrías y líneas en
blanco que separen distintos bloques de código.
Además de las tareas de programación asociadas a los distintos componentes de nuestro
sistema, en la fase de implementación también hemos de encargarnos de la adquisición de
todos los recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso
del sistema gestor de bases de datos que vayamos a utilizar). Usualmente, también
desarrollaremos algunos casos de prueba que nos permitan ir comprobando el funcionamiento
de nuestro sistema conforme vamos construyéndolo.
Pruebas. Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se hayan
podido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos). Lo suyo,
además, es hacerlo antes de que el usuario final del sistema los tenga que sufrir. De hecho,
una prueba es un éxito cuando se detecta un error (y no al revés, como nos gustaría pensar).
La búsqueda de errores que se realiza en la etapa de pruebas puede adaptar distintas formas,
en función del contexto y de la fase del proyecto en la que nos encontremos:
- Las pruebas de unidad sirven para comprobar el correcto funcionamiento de un
componente concreto de nuestro sistema. Es este tipo de pruebas, el "probador"
debe buscar situaciones límite que expongan las limitaciones de la
implementación del componente, ya sea tratando éste como una caja negra
("pruebas de caja negra") o fijándonos en su estructura interna ("pruebas de caja
blanca"). Resulta recomendable que, conforme vamos añadiéndole nueva
funcionalidad a nuestras aplicaciones, vayamos creando nuevos tests con los
medir nuestro progreso y también repitamos los antiguos para comprobar que lo
que antes funcionaba sigue funcionando (test de regresión).
- Las pruebas de integración son las que se realizan cuando vamos juntando los
componentes que conforman nuestro sistema y sirven para detectar errores en sus
interfaces. En algunas empresas, como Microsoft, se hace una compilación diaria
utilizando los componentes del sistema tal como estén en ese momento (daily
build) y se somete al sistema a una serie de pruebas básicas (la prueba de humo,
smoke test) que garanticen que el proyecto podrá seguir avanzando al día siguiente. El causante de que la compilación diaria falle suele tener que quedarse a
hacer horas extra para que sus compañeros puedan seguir trabajando al día
siguiente.
- Una vez "finalizado" el sistema, se realizan pruebas alfa en el seno de la
organización encargada del desarrollo del sistema. Estas pruebas, realizadas desde
el punto de vista de un usuario final, pueden ayudar a pulir aspectos de la interfaz
de usuario del sistema.
- Cuando el sistema no es un producto a medida, sino que se venderá como un
producto en el mercado, también se suelen realizar pruebas beta. Estas pruebas
las hacen usuarios finales del sistema ajenos al equipo de desarrollo y pueden
resultar vitales para que un producto tenga éxito en el mercado.
- En sistemas a medida, se suele realizar un test de aceptación que, si se supera
con éxito, marcará oficialmente el final del proceso de desarrollo y el comienzo de
la etapa de mantenimiento.
- Por último, a lo largo de todo el ciclo de vida del software, se suelen hacer
revisiones de todos los productos generados a lo largo del proyecto, desde el
documento de especificación de requerimientos hasta el código de los distintos
módulos de una aplicación. Estas revisiones, de carácter más o menos formal,
ayuden a verificar la corrección del producto revisado y también a validarlo
(comprobar que se ajusta a los requerimientos reales del sistema).
Instalación/Despliegue. Instalación / Despliegue
Una vez concluidas las etapas de desarrollo de un sistema de información (análisis, diseño,
implementación y pruebas), llega el instante de que poner el sistema en funcionamiento, su
instalación o despliegue. De cara a su instalación, hemos de planificar el entorno en el que el sistema debe funcionar,
tanto hardware como software: equipos necesarios y su configuración física, redes de
interconexión entre los equipos y de acceso a sistemas externos, sistemas operativos
(actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados
por terceras partes, etcétera.
Para asegurar el correcto funcionamiento del sistema, resulta esencial que tengamos en cuenta
las dependencias que pueden existir entre los distintos componentes del sistema y sus
versiones. Una aplicación puede que sólo funcione con una versión concreta de una biblioteca
auxiliar. Un disco duro puede que sólo rinda al nivel deseado si instalamos un controlador
concreto. Componentes que por separado funcionarían correctamente, combinados causan
problemas, por lo que deberemos utilizar sólo combinaciones conocidas que no presenten
problemas de compatibilidad.
Si nuestro sistema reemplaza a un sistema anterior o se despliega paulatinamente en distintas
fases, también hemos de planificar cuidadosamente la transición del sistema antiguo al nuevo
de forma que sus usuarios no sufran una disrupción en el funcionamiento del sistema. En
ocasiones, el sistema se instala físicamente en un entorno duplicado y la transición se hace de
forma instantánea una vez que la nueva configuración funciona correctamente. Cuando el
presupuesto no da para tanto, tal vez haya que buscar un momento de baja utilización del
sistema para realizar la actualización (por la noches o en fin de semana, por ejemplo).
Uso y mantenimiento. La etapa de mantenimiento consume típicamente del 40 al 80 por ciento de los recursos de
una empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente la
etapa más importante del ciclo de vida del software. Dada la naturaleza del software, que ni se
rompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes:
- Eliminar los defectos que se detecten durante su vida útil (mantenimiento
correctivo), lo primero que a uno se le viene a la cabeza cuando piensa en el
mantenimiento de cualquier cosa.
- Adaptarlo a nuevas necesidades (mantenimiento adaptativo), cuando el sistema
ha de funcionar sobre una nueva versión del sistema operativo o en un entorno
hardware diferente, por ejemplo.
- Añadirle nueva funcionalidad (mantenimiento perfectivo), cuando se proponen
características deseables que supondrían una mejora del sistema ya existente.
De las distintas facetas del mantenimiento, la eliminación de defectos sólo supone el 17% del
coste de mantenimiento de un sistema, mientras que el diseño e implementación de mejoras es
responsable del 60% del coste de mantenimiento. Es decir, más de un tercio del coste total del software se emplea en añadirle características a software ya existente (el 60% del 60%). La
corrección de errores supone, en contraste, "sólo" en torno al 10% del coste total del software.
Aún menos cuanto mejores sean las técnicas usadas en su desarrollo.
Se ha observado que, cuanto mejor sea el software, más tendremos que invertir en su
mantenimiento, aun cuando se emplee menos esfuerzo en corregir defectos. Este hecho, que
puede parecer paradójico, se debe, simplemente, a que nuestro sistema se usará más (a veces,
de formas que no habíamos previsto). Por tanto, nos llegarán más propuestas de modificación
y mejora que si el sistema hubiese quedado aparcado, cogiendo polvo, en algún rincón.
Si examinamos las tareas que se llevan a cabo durante la etapa de mantenimiento, nos
encontramos que en el mantenimiento se repiten todas las etapas que ya hemos visto del ciclo
de vida de un sistema de información. Al tratar principalmente de cómo añadirle nueva
funcionalidad a un sistema ya existente, el mantenimiento repite "en miniatura" el ciclo de
vida completo de un sistema de información. Es más, a las tareas normales de desarrollo
hemos de añadirle una nueva, comprender el sistema que ya existe, por lo que se podría decir
que el mantenimiento de un sistema es más difícil que su desarrollo (Glass, 2003).
BIBLIOGRAFIA.
Ramez A. Elmasri & Shamkant B. Navathe: "Fundamentos de Sistemas de Bases
de Datos", Addison-Wesley, 2002 [3ª edición]. ISBN 8478290516
Robert L. Glass: "Facts and Fallacies of Software Engineering",
Addison-Wesley, 2003. ISBN 0321117425
Steve McConnell: "Rapid Development: Taming wild software schedules",
Microsoft Press, 1996. ISBN 1556159005
Martin Fowler: "Patterns of Enterprise Application Architecture",
Addison-Wesley, 2003. ISBN 0321127420
Steve McConnell: "Code Complete: A practical handbook of software
construction", Microsoft Press, 2ª edición, 2004. ISBN 0735619670
Cem Kaner, James Bach & Bret Pettichord: "Lessons learned in software testing",
Wiley Computer Publishing, 2002. ISBN 0471081124
Es aquella en la cual toda la información se almacena en tablas. Una tabla esta formada por filas y columnas 
