Ciclo de vida
El ciclo de vida de un sistema de información es el periodo de tiempo que vive un sistema informático desde que es pensado hasta que es desechado o actualizado
Definición
El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Confiable, predecible y eficiente.
El Ciclo de Vida del Desarrollo de Sistemas es un proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de información y aplicaciones informáticas. (Oviedo G.J.)
Objetivo:
Determinar el orden de las etapas involucradas en el desarrollo del software, establece el criterio de transición para progresar de una etapa a la siguiente (Bohem):
- criterio para determinar la finalización
- criterio para comenzar y elegir la siguiente.
Así un modelo de proceso apunta a:
- ¿Qué debemos hacer a continuación?
- ¿Por cuánto tiempo debemos hacerlo?
Ciclos de vida
- Lineal – Secuencial – Cascada
- Ciclo Semiestructurado
- Ciclo - Modelo Estructurado
- Modelo V
- Modelo Evolutivo - Prototipos
- Iterativo - Incremental
- Espiral
1. Modelo en Cascada, Lineal o Secuencial
Implantación Ascendente
Progresión Secuencial
Modelo en Cascada
Características
- Ingeniería y Análisis del Sistema
Debido a que el software es siempre parte de un sistema mayor el trabajocomienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software.
- Análisis de los requisitos del software
el proceso de recopilación de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software (Analistas) debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas.
- Diseño
el diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación.
- Codificación
el diseño debe traducirse en una forma legible para la maquina. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente.
- Prueba
una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren.
- Mantenimiento
el software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a que hayan encontrado errores, a que el software deba adaptarse a cambios del entorno externo (sistema operativo dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
Evaluación
- Ventaja
Su sencillez ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el software.
- Desventajas
- Los proyectos reales raramente siguen el flujo secuencial que propone el modelo, siempre hay iteraciones y se crean problemas en la aplicación del paradigma.
- Normalmente, es difícil para el cliente establecer explícitamente al principio todos los requisitos. El ciclo de vida clásico lo requiere y tiene dificultades en acomodar posibles incertidumbres que pueden existir al comienzo de muchos productos.
- El cliente debe tener paciencia. Hasta llegar a las etapas finales del proyecto, no estará disponible una versión operativa del programa. Un error importante no detectado hasta que el programa este funcionando puede ser desastroso.
2. Ciclo Semiestructurado
3. Ciclo – Modelo Estructurado
4. Modelo V
Evaluación
- Ventajas
- Se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con primero.
- Este modelo involucra controles de cada una de las etapas del modelo
- Desventajas
- El riesgo es mayor que el de otros modelos, pues en lugar de hacer pruebas de aceptación al final de cada etapa, las pruebas comienzan a efectuarse luego de haber terminado la implementación, lo que puede traer como consecuencia un “roll-back” de todo un proceso que costó tiempo y dinero.
- El modelo no contempla la posibilidad de retornar a etapas inmediatamente anteriores, cosa que en la realidad puede ocurrir.
- Se toma toda la complejidad del problema de una vez y no en iteraciones o ciclos de desarrollo, lo que disminuye el riesgo.
5. Modelo Evolutivo – Prototipos
Modelo de prototipos
Prototipos
Prototipos
- No modifica el flujo del ciclo de vida
- Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios
- Reduce costos y aumenta la probabilidad de éxito
- Exige disponer de las herramientas adecuadas
- No presenta calidad ni robustez
- Una vez identificados todos los requisitos mediante prototipo, se construye el producto de ingeniería.
Para que sea efectivo
- Debe ser un sistema con el que se pueda experimentar
- Debe ser comparativamente barato (< 10%)
- Debe desarrollarse rápidamente
- Énfasis en la interfaz de usuario
- Equipo de desarrollo reducido
- Herramientas y lenguajes adecuados “El prototipado es un medio excelente para recoger el ‘feedback’ (retroalimentación) del usuario final”
Detalle
- Se basa en la idea de desarrollar una versión inicial, presentándola al usuario, y refinándola en sucesivas versiones
- Tipos
- Desarrollo exploratorio
- Prototipos desechables
- Ver Procesos Ágiles
Evaluación
- Ventajas
- Satisface las necesidades inmediatas del usuario
- Desventajas
- No es visible el proceso
- A menudo los sistemas tienen una estructura deficiente
- Problemas de escala (para sistemas grandes)
- El cliente ve funcionando lo que para el es la primera versión del prototipo que ha sido construido con “plastilina y alambres”, y puede desilusionarse al decirle que el sistema aun no ha sido construido.
- El desarrollador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente
El prototipazo Evolutivo
- Construcción de una implementación parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema
- Reduce el riesgo y aumenta la probabilidad de éxito
- No se conocen niveles apropiados de calidad y documentación
- Problemas de gestión de configuración
- Construir software para que pueda ser modificado fácilmente es un “arte desconocido”
6. Modelo Iterativo – Incremental
- Incremental
- Se evitan proyectos largos y se entrega “Algo de valor” a los usuarios con cierta frecuencia
- El usuario se involucra más
- Difícil de evaluar el costo total
- Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar como un todo
- Requiere desarrolladores experimentados
- Los errores en los requisitos se detectan tarde
- El resultado puede ser muy positivo
- El producto se desarrolla en varios incrementos
- Cada incremento agrega funcionalidad adicional al producto
- Versión 1: Requerimiento 1, 3, 4, y 6
- Versión 2: Requerimiento 2, 5, y 7
- Versión 3: Requerimiento 8
- Iterativo
- Cada iteración “refina” las mismas funcionalidades que la iteración anterior, pero con mas detalle, con mejor desempeño, etc.
- Las primeras iteraciones son bosquejos, la última es el producto terminado.
7. Modelo Espiral
Detalle
- Características
- Prevención de riesgos de desarrollo
- Marco para otros ciclos de vida (fases, prototipos)
- Cada fase es una vuelta que se divide en cuatro actividades
- Filosofía
- No dejar la resolución de los riesgos de desarrollo para el final
- Antes que nada, detectar las posibles fuentes de riesgo
- Proponer inmediatamente una estrategia de resolución de los riesgos
- La aplicación de estas estrategias podrá llevarnos a:
- Encontrar soluciones viables, ó
- A abandonar el proyecto a tiempo
Evaluación
- Ventajas
- Evaluación en cada fase que permite cambios de objetivos
- Funciona bien en proyectos de innovación
- Inconvenientes
- La evaluación de riesgos es compleja
- Excesiva flexibilidad para algunos proyectos
Sitios Consultados
Bibliografía
Análisis estructurado, Yourdon
Análisis y diseño de sistema, Kendall
f
ResponderEliminar