Ciclo de vida de los sistemas 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.

Las etapas del proceso de desarrollo de software

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  

Antes de que se le de oficialmente el pistoletazo de salida a un proyecto de desarrollo de un sistema de información, es necesario realizar una serie de tareas previas que influirán decisivamente en la finalización con éxito del proyecto. Estas tareas se conocen popularmente como el fuzzy front-end del proyecto al no estar sujetas a plazos. 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.

Delimitación del ámbito del proyecto

Resulta esencial determinar el ámbito del proyecto al comienzo del mismo. Han de establecerse de antemano qué cuestiones han de resolverse durante la realización del proyecto y cuáles se dejarán fuera. Tan importante es determinar los aspectos abarcados por el proyecto como fijar aquéllos aspectos que no se incluirán en el proyecto. Estos últimos han de indicarse explícitamente. Si es necesario, se puede especificar todo aquello que se posponga hasta una versión posterior del sistema. Si, en algún momento, fuese necesario incluir en el proyecto algún aspecto que no había sido considerado o que ya había sido descartado, es obligatorio reajustar la estimación del coste del proyecto y su planificación temporal.

 Como resultado de la delimitación del ámbito del proyecto se obtiene un documento breve, de 1 ó 2 páginas, en el que se describe el problema que nuestro sistema de información pretende resolver. Este documento, denominado a veces mission statement o project charter, debe existir siempre en todo proyecto. En él se recogerá la descripción de más alto nivel de la funcionalidad que tendrá nuestro sistema de información, sus características principales y sus objetivos clave. Obviamente, este documento debe formar parte del contrato que se firme con el cliente en el arranque oficial del proyecto.

 Además de ser breve, una buena descripción del proyecto debe superar con éxito la prueba del ascensor. Debe estar escrito en un lenguaje que cualquiera pueda entender, evitando un vocabulario excesivamente técnico. 

Estudio de viabilidad 

Antes de comenzar un proyecto, se debería evaluar la viabilidad económica, técnica y legal del mismo. Y no sólo eso, el resultado del estudio de viabilidad debería ajustarse a la realidad.

Análisis de riesgos 

La evaluación de riesgos se utiliza para identificar "riesgos" que pueden afectar negativamente al plan de nuestro proyecto, estimar la probabilidad de que el riesgo se materialice y analizar su posible impacto en nuestro proyecto. ¿Qué sucedería si algún miembro clave del nuestro equipo abandona la empresa, se va de vacaciones, se pone enfermo o pide una baja por depresión causada por un entorno de trabajo hostil? ¿y si al final nos encontramos con algún problema de compatibilidad del sistema que hemos desarrollamos con la configuración de los equipos sobre los que ha de funcionar? ¿si, inadvertidamente, borramos o modificamos erróneamente algún que otro fichero clave? ¿si nuestro ordenador se avería? .

Una vez analizados los riesgos potencialmente más peligrosos, podemos recurrir a distintas técnicas de control de riesgos. Por ejemplo, podemos elaborar planes de contingencia para los riesgos que sean más probables y de consecuencias más desastrosas para el proyecto. O tal vez seamos capaces de eliminar el riesgo de raíz (o mitigarlo) si buscamos alguna alternativa en la que el riesgo identificado no pueda presentarse (o se presente debilitado).

Estimación 

Nunca se ha de realizar una estimación sobre la marcha, por mucho que nos presionen. Una respuesta apresurada sólo sirve para pillarnos los dedos y que después no podamos cumplir con las expectativas que nosotros mismos hemos creado. Una estimación siempre ha de ser meditada, tras un estudio pormenorizado de los distintos factores que pueden afectar a la realización de nuestro proyecto.

Planificación temporal y asignación de recursos 

Una vez que hemos decidido seguir adelante con nuestro proyecto, hemos de planificar su temporización. Una planificación excesivamente detallada (con el proyecto descompuesto en tareas de un día, por ejemplo) puede resultar contraproducente. Cualquier error de planificación causado por algún imprevisto nos forzará a replanificar el resto del proyecto, retrasando aún más nuestro proyecto. Una planificación por semanas suele ser razonable para afrontar con comodidad las contingencias con las que nos vayamos encontrando sin tener que estar continuamente reajustando el plan del proyecto.

Pase lo que pase, la planificación del proyecto ha de reajustarse cada vez que cambien las circunstancias del mismo. Si no se ha podido terminar una tarea en el tiempo inicialmente establecido, no nos vale suponer alegremente que posteriormente se recuperará el tiempo perdido. Los proyectos se retrasan poco a poco. Debemos aprovechar las primeras señales de alarma y no esconderlas debajo de la alfombra fingiendo que todo marcha según lo previsto.

Tampoco vale decir que algo está casi terminado. O lo está o no lo está. Si no lo está, el plan ha de ajustarse a la situación real del proyecto. Pensar que algo está casi acabado sólo sirve para darnos una falsa sensación de seguridad.

Análisis  

Lo primero que debemos hacer para construir un sistema de información es averiguar qué es exactamente lo que tiene que hacer el sistema. 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).

Diseño  

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.

Pruebas

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). 

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.

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.

Modelos de ciclo de vida

Ciclo de vida clásico 

El modelo de ciclo de vida clásico, también denominado "modelo en cascada", se basa en intentar hacer las cosas bien desde el principio, de una vez y para siempre. Se pasa, en orden, de una etapa a la siguiente sólo tras finalizar con éxito las tareas de verificación y validación propias de la etapa. Si resulta necesario, únicamente se da marcha atrás hasta la fase inmediatamente anterior.

Este modelo tradicional de ciclo de vida exige una aproximación secuencial al proceso de desarrollo del software. Por desgracia, esta aproximación presenta una serie de graves inconvenientes, entre los que cabe destacar:

- Los proyectos reales raramente siguen el flujo secuencial de actividades que propone este modelo. 

- Normalmente, es difícil para el cliente establecer explícitamente todos los requisitos al comienzo del proyecto (entre otras cosas, porque hasta que no vea evolucionar el proyecto no tendrá una idea clara de qué es lo que realmente quiere). 

- No habrá disponible una versión operativa del sistema hasta llegar a las etapas finales del proyecto, por lo que la rectificación cualquier decisión tomada erróneamente en las etapas iniciales del proyecto supondrá un coste adicional significativo, tanto económico como temporal (y eso sin tener en cuenta la mala impresión causada por un retraso en la fecha de entrega).

Desarrollo de prototipos 

Normalmente, el cliente es capaz de definir un conjunto general de objetivos para el sistema que hemos de construir, pero no identifica los requisitos detallados. En otros casos, puede que nosotros no estemos seguros de la eficiencia de un algoritmo, de la capacidad de nuestro diseño para soportar los requerimientos del sistema o de la forma en que debe diseñarse la interfaz de usuario. En cualquiera de estas situaciones, resulta adecuado construir un prototipo.

El desarrollo de prototipos reduce el riesgo de que nuestro proyecto fracase y facilita la especificación de requerimientos de productos que desconocemos. Sin embargo, también tiene sus inconvenientes: el cliente puede pensar que el prototipo es el sistema definitivo, ignorando que un prototipo no es un sistema acabado aunque tenga el mismo aspecto externo.

Modelos iterativos 

Los modelos iterativos consisten en descomponer un proyecto de desarrollo de software en una serie de subproyectos de menor envergadura. Estos subproyectos deben diseñarse de tal forma que cada uno de ellos aporte funcionalidad nueva para el sistema desde el punto de vista del usuario final del mismo.

Los modelos iterativos de desarrollo de software permiten adelantar el momento en el que se determina si un proyecto es técnicamente viable o no (con lo que se eliminan costes innecesarios si, finalmente, el proyecto hubiese de cancelarse). También promueven una mejor comunicación con el usuario/cliente, ya que se dispondrá antes de una versión operativa del sistema, aunque sea de funcionalidad reducida. Estas versiones intermedias del producto ayudan a la eliminación de malentendidos que pueden surgir en la etapa de elicitación de requerimientos. Además, ayudan a que el usuario se forme una idea más clara de lo que realmente necesita.

Diseño Estructurado de Sistemas

El diseño estructurado de sistemas se ocupa de la identificación, selección y organización de los módulos y sus relaciones. Se comienza con la especificación resultante del proceso de análisis, se realiza una descomposición del sistema en módulos estructurados en jerarquías, con características tales que permitan la implementación de un sistema que no requiera elevados costos de mantenimiento.

Bibliográfica 

Robert L. Glass: "Facts and Fallacies of Software Engineering", Addison-Wesley, 2003. ISBN 0321117425

Martin Fowler: "Patterns of Enterprise Application Architecture", Addison-Wesley, 2003. ISBN 0321127420 

Cem Kaner, James Bach & Bret Pettichord: "Lessons learned in software testing", Wiley Computer Publishing, 2002. ISBN 0471081124 

creado por 

Eduardo C.Z.