CICLO DE VIDA DE LOS SISTEMAS DE

INFORMACIÓN

Etapas del Ciclo de Vida de los Sistemas:

Planificación
Cualquiera que esté involucrado en alguna etapa del desarrollo dirá que los
sistemas de información más importantes comienzan con un buen plan. Sin una
fase de planificación es difícil tener una idea de lo que debe suceder y cuándo
debe suceder.

En la fase de planificación, el analista de sistemas debe centrarse en lo que el

sistema pretende lograr y utilizar esa información para encontrar una manera de
lograr ese objetivo.

La evaluación de los sistemas que ya se encuentran en funcionamiento resulta

también importante en esta fase, ya que podría haber un sistema preexistente que
pudiera ofrecer una solución más barata si se le efectúan algunas mejoras.

Diseño
Luego que están totalmente en su lugar tanto la planificación como los
requerimientos, se entregan los planos al arquitecto de sistemas, quien así podrá
comenzar a trabajar en el diseño del sistema.

A menudo, los sistemas a diseñar se basan en el software o la infraestructura

informática. Esto significa que los diseñadores de sistemas serán probablemente
especialistas en informática o desarrolladores de software.

Esta fase describe cómo abordar el diseño de la arquitectura del sistema, por
ejemplo, las interfaces de usuario, la red de computadoras, la base de datos y la
seguridad, que puedan satisfacer los requerimientos y permitan actualizaciones
futuras.

Desarrollo
Una vez que están listos los nuevos diseños, los miembros del equipo podrán
comenzar a trabajar en el desarrollo del sistema. En esta fase, el plano del sistema
pasará del modelo a la práctica, a medida que los programadores desarrollen un
sistema completamente funcional.

Los ingenieros de software escriben el código y van ajustando las tecnologías

involucradas en el proyecto. Esta es probablemente la fase más activa del ciclo de
vida, ya que implica un arduo trabajo de todos los expertos involucrados en ella.

Prueba
Al final de la fase de desarrollo, los sistemas pudieran parecer que están
completamente operativos, pero es importante que primero se prueben antes que
comiencen a funcionar.

Esto elimina cualquier distorsión en el sistema, asegurándose así que el mismo

esté funcionando tan perfectamente como debiera.

En esta fase, el sistema debe someterse a una inspección exhaustiva en diferentes

escenarios. Si se encuentran errores o problemas, el equipo de trabajo deberá
alinearse para resolverlos sin alterar el resto del sistema.

Integración y ejecución
En esta fase se realiza el primer lanzamiento del sistema. En una situación ideal,
la ejecución será tan fluida que no se requerirá ningún esfuerzo adicional cuando
ocurra la integración.

De ser posible, la integración de un nuevo sistema en una empresa debería ser

automática y ágil.

Esta fase se realiza moviendo al nuevo sistema los datos y componentes que tenía
el sistema anterior. Después de la correspondiente ejecución, el sistema estará
disponible para los usuarios finales.

Operación y mantenimiento
Aunque las pruebas deberían haber resuelto cualquier problema que pudiera
haber surgido, es importante monitorear el nuevo sistema para asegurarse que
esté funcionando correctamente. También es importante que el sistema se someta
a un mantenimiento frecuente para que pueda seguir funcionando sin problemas.
Desde el punto de vista de la investigación, es crucial monitorear el sistema para
comprender si está beneficiando al negocio tal como se esperaba, además de
cómo está influyendo su desempeño en el flujo de trabajo.

Durante los primeros meses después del lanzamiento de un nuevo sistema, el

analista de sistemas deberá informar sobre cómo está funcionando y las mejoras
que está haciendo.

Todo sistema de información debe revisarse con frecuencia para detectar errores
e irse actualizando con otras funciones. De hecho, el sistema podría funcionar
bien después de su lanzamiento, pero pueden surgir errores en cualquier
momento.

En cuanto al mantenimiento, el sistema de información debe adaptarse a las

cambiantes necesidades de los usuarios finales.

Modelos iterativos
En 1994, el Departamento de Defensa de Estados Unidos (el mayor contratista mundial
de proyectos de desarrollo de software) cambió oficialmente sus estándares de
desarrollo de software y descartó el modelo en cascada para introducir el estándar 498,
que utiliza un modelo iterativo de desarrollo de software.

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.

Usualmente, las personas involucradas en el proyecto establecen prioridades entre los

requerimientos iniciales del sistema para decidir qué parte del mismo se construirá
primero.

El cliente y los usuarios finales abogarán por darle prioridad a las funciones más útiles
del sistema (o las más "vendibles"). Por otro lado, los diseñadores del sistema deberán
determinar las dependencias existentes entre sus distintos componentes y priorizar
aquéllos que supongan un riesgo mayor para la viabilidad final del proyecto. Las
prioridades de unos y otros habrán de consensuarse razonablemente y servirán para
determinar el ámbito de los subproyectos en que se descompondrá el proyecto inicial.

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.

Modelo Lineal Secuencial

Es el más antiguo de todos los modelos de Ingeniería del Software. El modelo lineal presenta
una estructura secuencial (de ahí el nombre de Modelo en cascada).

Es también conocido como “Modelo en cascada”, “Modelo lineal secuencial”, “Ciclo de vida
básico” o “Ciclo de vida clásico”.

Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Tiene su origen en
el "Modelo de cascada" ingeniado por Winston Royce, sugiere un enfoque sistemático o más
bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con
el análisis, diseño, codificación, pruebas y mantenimiento.

El MLS tiene las siguientes actividades:

 Análisis de los requerimientos del software: es la fase en la cual se reúnen todos los
requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del
cliente que documenta y repasa dichos requisitos.
 Diseño: es una etapa dirigida hacia la estructura de datos, la arquitectura del software,
las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma
general se hace un esbozo de lo solicitado y se documenta haciéndose parte del
software.
 Generación del código: es la etapa en la cual se traduce el diseño para que sea
comprensible por la máquina. Esta etapa va a depender estrechamente de lo detallado
del diseño.
 Pruebas: esta etapa se centra en los procesos lógicos internos del software, asegurando
que todas las sentencias se han comprobado, y en la detección de errores.
 Mantenimiento: debido a que el programa puede tener errores, puede no ser del
completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios
en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de
uno ya existente se realizan algunos cambios.

Desventajas:
 Los proyectos raramente siguen el paradigma secuencial que propone el proyecto.
 Los responsables del desarrollo de software siempre se retrasan innecesariamente.
 No siempre se sigue el flujo secuencial.
 Es difícil tener un 100% de los requisitos al inicio.
  El cliente debe tener paciencia. Los primeros resultados serán hasta que ya esté
operando el sistema.

Modelos Evolutivos
El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va
refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del
usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de
separarse.

Existen dos tipos de desarrollo evolutivo:

1.desarrollo exploratorio: donde el objetivo del proceso es trabajar con el cliente para explorar
sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema
que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el
cliente.

2.prototipos desechables: donde el objetivo del proceso de desarrollo evolutivo es comprender

los requerimientos del cliente y entonces desarrollar una definición mejorada de los
requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos
del cliente que no se comprenden del todo.

Desde el punto de vista de desarrollo de sistema el enfoque evolutivo suele traer más ventajas
en comparación con un enfoque en cascada ya que el sistema se va ajustando a las necesidades
del cliente, a la vez que él mismo entiende mejor sus propios requerimientos. Sin embargo el
enfoque evolutivo desde una perspectiva de ingeniería y gestión suele tener dos grandes
problemas:

1.proceso no visible : Los administradores tienen que hacer entregas regulares para medir el
progreso. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que
reflejen cada versión del sistema.

2. A menudo los sistemas tienen una estructura deficiente. Los cambios continuos tienden a
corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una
tarea difícil y costosa.
Aunque supone grandes ventajas el desarrollo evolutivo solo es recomendado para sistemas
pequeños y medianos. En los sistemas grandes, los constantes cambios en el desarrollo solo
dificultan la estabilidad y la integración de los avances de los distintos grupos de trabajo que
puedan existir. La mayoría de las empresas que desarrollan grandes sistemas usan un modelo
mixto que usa las mayores fortalezas de los enfoques evolutivos y de cascada.