Fases de Desarrollo de vida de los Sistemas

Se rige por las siguientes fases

Planeación: La función de la planeación “pretende señalar y establecer prioridades sobre aquellas tecnologías y aplicaciones que producirán un máximo beneficio para la organización” (Whitten; Benthley y Barlow, 1996).El objetivo de esta fase consiste en la elaborar junto con el equipo humano de la organización donde de va a implementar el sistema, los objetivos generales, específicos y los esquemas generales de la manera más clara y precisa. En esta fase se debe responder a preguntas como: Cuáles son los objetivos que deberá cumplir en SIG?; Cuáles son las necesidades de la organización que deben resolverse? .

Se debe realizar un levantamiento completo de requerimientos teniendo en cuenta el Flujo de la Información con que se trabaja en la organización o las áreas que se desea sistematizar mediante un SIG. Se debe documentar el proceso mediante Diagrama de Flujo de Datos. Quienes son los usuarios del sistema y sus necesidades? Se debe identificar los usuarios internos y potenciales de la información institucional, empresarial o del proyecto; que gestionará el sistema.Cuál es la información y los datos que usan y generan en la organización para desarrollar sus funciones?Cuáles son los productos esperados del sistema? Se debe conocer cuales son los productos esperados del sistema dependiendo del tipo de usuario. Se deben establecer prioridades respecto a los productos. Cuál es el alcance del sistema? Se debe identificar si el alcance es local, regional, nacional o global. El nivel define la escala o resolución de los datos necesarios para alimentar el sistema.

Análisis: El Analista de Sistemas es imprescindible en cualquierorganización, debido al abanico de destrezas que éste posee y los beneficios que le produce. Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen. Todo desarrollolíderizado o no por un analista de sistemas posee fases que pueden dividirse lógica en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. Este conjunto de fases son conocidas como el Ciclo de Vida de Desarrollo de Sistemas, herramienta fundamental para el desempeño de un analista de sistemas.

El análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de manejarla conmétodos y procedimientos más adecuados." (Senn, 1992, p.11). Se puede dividir en dos: el análisis de sistemas que comprende laplanificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema; y el diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable. En pocas palabras; "Elanálisis especifica qué es lo que el sistema debe hacer. El diseño establece cómo alcanzar el objetivo" (op. cit., p.13) Ciertamente, todo sistema de información debe presentar salidas en base a entradas de datos y procesos, lo que nos dice que si deseamos entender todo lo que le ocurre a los datos antes de llegar al usuario como información –Es decir antes de ser interpretado por el usuario final- debemos utilizar metodologías que permiten ver los sistemas en base a sus procesos, por lo menos en sistemas de procesado por lotes o secuencial. Un ejemplo de ello es la metodologíaestructurada. Existen muchas metodologías pero esta es la más arraigada debido a su antigüedad. Recordemos que hace apenas dos décadas los computadores no soportaban el multitasking (procesamiento multitarea), lo que limitaba a procesar una pantalla a la vez, esto sólo permitía sistemas secuenciales donde cada tarea en procesamiento comenzaba cuando la anterior ya había terminado por completo.Diseño “Evalúa las soluciones alternativas y específica una solución detallada de tipo informático” (Whitten; Benthley y Barlow, 1996). Fases del Diseño (Whitten; Benthley y Barlow, 1996):Elección de una solución de diseño entre las soluciones candidatas. Estas soluciones se evalúan con los siguientes criterios: Viabilidad técnica, operativa, económica, en tiempo.Evaluación del hardware y software requeridosDiseño e Integración del nuevo sistema. Diseño General. El método comúnmente utilizado es la modelización (acto de elaborar una o más representaciones gráficas del sistema).

Los modelos de diseño general describen:

La estructura de los archivos y las bases de datos (diagrama de estructuras de datos)- Los métodos y procedimientos de proceso (diagrama de flujo)- La estructura de la red informática (diagrama de flujo)Diseño Detallado. Se divide en:

Diseño Externo. (conjunto de especificaciones de la interfaz del sistema con sus usuarios incluyen entradas, consultas, salidas, diseño de ventanas y transición entre ventanas.

Diseño Interno. Especificaciones de aplicación del sistema, los archivos, diseño de la base de datos. “En esta etapa es necesario elaborar un modelo de datos que estructure el SIG, definir la verificación y control de calidad de los datos, seleccionar las capas de información por áreas de trabajo, estructurar la base de datos espacial y temática y concretar todos los procesos que soportará el SIG. Igualmente en ésta etapa se definen los programas y equipos para el SIG, de tal manera que satisfagan los requerimientos”. 

Implantación Es la construcción del nuevo sistema y el paso de dicho sistema a “producción” (funcionamiento diario)”. (Whitten; Benthley y Barlow, 1996). Se le conoce también como desarrollo pero se confunde con el ciclo de vida completo del sistema de información.

Fases de Implantación:

-. Probar las redes y las bases de datos

.-Construcción y prueba de las aplicaciones

.- Instalación y prueba del nuevo sistema

.- Entrega del sistema para puesta en funcionamiento 

Pruebas A través de esta fase se conoce en realidad los resultados del sistema. Los criterios de evaluación son la precisión, la calidad y los productos esperados. Las pruebas son un proceso cíclico que debe dar como resultado el cumplimiento de los objetivos propuestos.

Mantenimiento

Es el soporte “continuado de un sistema después de que se ha puesto en funcionamiento. Incluye el mantenimiento de aplicaciones y mejoras al sistema”.

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

¿Secuencial o iterativo?

El modelo de desarrollo más adecuado para un proyecto dependerá del tipo de sistema que se ha de construir: 

- En general, se elegirá un modelo secuencial cuando los requerimientos se conocen bastante bien y son estables, cuando el diseño será similar al de otros sistemas con los que tenemos experiencia, cuando los integrantes del equipo de desarrollo ya se conocen y están familiarizado con el entorno de desarrollo, o cuando el coste de tener que cambiar algo en las etapas finales del proyecto resultaría prohibitivo.

- En la práctica, no obstante, los modelos iterativos se adaptan mejor a la realidad del desarrollo de software (especialmente en sistemas medianos y grandes). Nos decantaremos por un modelo iterativo cuando los requerimientos no se conocen con exactitud o se prevé que puedan cambiar en el futuro, cuando el diseño del sistema es complejo o no tiene precedentes para nosotros, cuando el proyecto en sí es arriesgado económicamente y cuando podamos controlar el coste de futuros cambios en el sistema (algo que siempre tendremos que hacer si tenemos en cuenta lo que aprendimos al estudiar la etapa de mantenimiento).

Al seguir un modelo iterativo, puede que le dediquemos muy poco tiempo a las etapas iniciales del ciclo de vida de un sistema, lo que puede causar una tasa de cambios tan alta que impida que el proyecto progrese. Del mismo modo, si les dedicamos demasiado tiempo, hasta el punto de seguir a pies juntillas los requerimientos iniciales del sistema, puede que estemos negando la realidad con la que nos encontramos y, de nuevo, impidamos que el proyecto progrese adecuadamente.

Para planificar un proyecto que siga un modelo iterativo, primero se prepara una descomposición a grandes rasgos del proyecto en una serie de iteraciones, cada una de las cuales se considerará como un proyecto independiente. En vez de realizar una planificación detallada de todo el proyecto, sólo se detallará el plan correspondiente a la primera iteración. Sí se establecerán las fechas de inicio y finalización de las distintas iteraciones y se definirán los objetivos principales de cada una de ellas. Llegado el caso, estos objetivos se pueden redefinir conforme avance el proyecto.

A lo largo de los años se han propuesto multitud de modelos iterativos de desarrollo de software. A continuación se describen algunos de los más conocidos: 

- El modelo en espiral de Barry Boehm hace especial hincapié en la prevención de riesgos. Este modelo define cuatro actividades principales: planificación (determinar los objetivos, alternativas y restricciones del proyecto), análisis de riesgos (análisis de alternativas e identificación/resolución de riesgos), ingeniería (desarrollo del producto) y evaluación (revisión por parte del cliente y valoración de los resultados obtenidos de cara a la siguiente iteración). En cada iteración alrededor de la espiral se construyen versiones cada vez más completas del software.

- Los modelos evolutivos (como el modelo Evo de Tom Gilb o los modelos ágiles populares hoy en día, entre los que se encuentra la auto-denominada programación extrema) se caracterizan por realizar entregas por etapas del sistema. Usualmente, el proyecto se descompone en iteraciones de longitud fija (de 1 a 6 semanas) y cada iteración ha de proporcionar algún aspecto completo de la funcionalidad del sistema. Cada ciclo se concentra en las funciones de mayor valor añadido. De esta forma, si se cancelase el proyecto en cualquier momento, el usuario siempre tendrá lo máximo que se puede conseguir con los recursos invertidos hasta el momento. Igualmente, se puede prorrogar el proyecto si se considera interesante seguir añadiéndole funcionalidad al proyecto. 

- También existen otros modelos, conocidos por el nombre de modelos de estabilización y sincronización, en los que se sigue la misma estrategia que en los modelos iterativos pero sin llegar a realiza una entrega por etapas del sistema. Éste es el caso, por ejemplo, del modelo de desarrollo de software utilizado internamente en empresas como Microsoft. 

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. Esto puede conducir a la consolidación de aspectos de baja calidad de un prototipo en el sistema final que se entrega si el prototipo no se desecha a tiempo. 

Fred Brooks nos aclara lo que hay que hacer cuando un prototipo ya ha cumplido con su propósito: "En la mayoría de los proyectos, el primer sistema que se construye apenas resulta utilizable. Puede que sea demasiado lento, demasiado grande, difícil de usar o las tres cosas a la vez. No queda más remedio que comenzar de nuevo y construir una versión rediseñada que resuelva los problemas... Cuando se utiliza un concepto nuevo... hay que construir un sistema para desecharlo, porque incluso la mejor planificación no puede asegurar que vaya a salir bien la primera vez. Por tanto, la cuestión no es si hay que construir un sistema piloto y desecharlo. Se desechará. La única cuestión es si planificar de antemano la construcción de algo que se va a desechar, o prometer la entrega del desecho a los clientes..." (The Mythical Man-Month, "El mítico hombre-mes", 1975, uno de los libros de gestión de proyectos de desarrollo de software más populares que jamás se han escrito).

A veces, los prototipos desechables no se llegan a desechar. Pero los prototipos no siempre son desechables. En tal caso, estaremos utilizando un modelo iterativo de refinamiento de prototipos en el que, tras varias iteraciones, seremos capaces de construir un sistema que se adapte mejor a las necesidades de nuestro cliente.  

Ciclo de vida clasico

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

Tal cual, el modelo de ciclo de vida en cascada no nos indica nada acerca de la relación contractual existente entre el cliente y la organización encargada del desarrollo de software. Desde el punto de vista de una empresa de desarrollo de software, formalizar la firma de un contrato al final de la etapa de análisis, por ejemplo, puede ayudar a reducir el riesgo que supone elaborar un presupuesto cuando aún no se dispone de toda la información necesaria para que la estimación del esfuerzo requerido por el proyecto sea lo suficientemente precisa. Este tipo de contrato obliga a que el cliente se haga cargo de los costes adicionales ocasionados por cambios en los requerimientos, mientras que la empresa de desarrollo de software deberá asumir los gastos ocasionados si el producto finalmente entregado no cumple todas las condiciones pactadas a la firma del contrato. Por desgracia, un modelo contractual como el descrito en el párrafo anterior no siempre resulta aceptable para el cliente, que puede verse obligado a invertir dinero a cambio de nada. Esto podría pasar si, tras la etapa de análisis, el proyecto se desestima por no ser técnica o económicamente viable. Es más, si el cliente acepta a regañadientes la firma de un contrato al final de la etapa de análisis, la imagen de la empresa desarrolladora de software puede verse seriamente deteriorada en cuanto surja cualquier tipo de problema.

¿Que es un ciclo de vida de sistemas de información?

Es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de ciclo especifico de actividades del analista y del usuario.