Please enable JavaScript.
Coggle requires JavaScript to display documents.
TEMA 41 : EL CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN. MODELO DEL…
TEMA 41 : EL CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN. MODELO DEL CICLO DE VIDA
EL CICLO DE VIDA DE LOS SISTEMAS DE INFORMACIÓN
Introducción al desarrollo del software
El proceso de resolución de cualquier problema sigue , en general , los siguientes pasos :
Decisión de qué hacer (identificar el problema)
Decisión de cómo hacerlo
Hacerlo
Probar el resultado
Usar el resultado
El auge que se produjo en el ámbito de la informática en los años 60 tuvo como consecuencia que se realizara una masiva escritura incontrolada de líneas de código, sin plantearse ningún tipo de metodología para el diseño y construcción del software ni para resolver los problemas relacionados con el mantenimiento , eficiencia, fiabilidad, portabilidad..etc . Esta situación tuvo como consecuencia la llamada
crisis del software
Para resolver los problemas planteados apareció el término de
Ingeniería del Software" :
establecimiento y uso de principios de ingeniería robustos, orientados a obtener software económico que sea fiable y funciona de manera eficiente sobre máquinas reales.
La construcción de un sistema de información tiene
2 objetivos
Dada una necesidad, desarrollar una solución usando
los principios de la Ingeniería del Software
El
mantenimiento del sistema
producido hasta el final de su vida útil
El
proceso mínimo
necesario sea cual sea el área de aplicación, el tamaño del proyecto, su complejidad y el paradigma elegido consta de las siguientes etapas :
1. Obtención de los requisitos software
, que incluye el análisis del problema y acaba con una especificación completa del comportamiento que deberá tener el sistema a construir
2. Diseño del sistema
: mediante la descomposición en sus componentes principales y la definición de los algoritmos que realizarán las funciones a realizar en cada módulo
3. Implementación del sistema
o codificación : transformar los algoritmos definidos durante el diseño en un lenguaje comprensible para el ordenador
4. Realización de las pruebas :
unitarias para comprobar cada módulo, de integración para comprobar el conjunto, y del sistema para asegurar el funcionamiento de todo el sistema integrado en su entorno
5. Instalación del sistema
, donde el software y su entorno hardware pasan a estar operativos
6. Mantenimiento y ampliación del sistema :
detección o prevención continuada de errores y su corrección, así como la incorporación de nuevas prestaciones
Todo p
roceso de desarrollo
de un sistema de información constituye un proyecto y comprende un amplio conjunto de
actividades divididas en dos grandes grupos
Actividades de desarrollo
: aquellas mediante las cuales se crean los productos que componen el sistema
Análisis y especificaciones de requisitos
DIseño de software
Programación o implementación del código
Pruebas..
etc
Actividades de gestión de proyectos
: ejecución, administración y supervisión del proceso de desarrollo del sistema
Planificación del proyecto
Asignación de recursos
Organización del equipo de desarrollo
Estimación de costes
Aspectos legales
Evolución del software (control de cambios y gestión de las configuraciones)
Calidad del software
Seguridad
El ámbito de este tema es el primer grupo
Estándares de procesos de desarrollo
: el conjunto de actividades esenciales que deben ser incorporadas en el desarrollo de un producto software están recogidas en el estándar
IEEE 1074:1997
Este estándar no recomienda un ciclo de vida específico y requiere adaptarse a cada proyecto
Considera que el proceso de desarrollo de un SI está compuesto por
3 grupos de actividades (65 en total)
Procesos de
gestión del proyecto
Procesos
orientados al desarrollo
propiamente dicho del software
Procesos de predesarrollo
: reconocimiento del problema, estudio de la viabilidad y determinación de los requisitos funcionales
Procesos de desarrollo :
los que se deben realizar para la construcción del producto software
Procesos de postdesarrollo :
los que se deben realizar para instalar, operar, soportar, mantener y retirar un producto software
Por otra parte, el estándar
ISO/IEC 12207:2008
(Procesos del ciclo de vida del software) tiene el objetivo principal de proporcionar una estructura común en forma de procesos bien definidos, actividades y tareas que se pueden adaptar en función del proyecto software. Tampoco propone un modelo de ciclo de vida concreto
MODELOS DEL CICLO DE VIDA
Definición y clasificación
Concepto :
según el estándar
ISO/IEC 12207:2008 **
el ciclo de vida de un S.I.** es el marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de requisitos hasta la finalización de su uso
Modelo de ciclo de vida :
conjunto de fases o etapas por las que pasa el sistema desde que se concibe hasta que se retira del servicio
Objetivos del ciclo de vida
Definir las actividades a realizar y en qué orden
Proporcionar puntos de control para la gestión del proyecto (fases o etapas)
Establecer los criterios de transición para pasar de una fase a otra
Asegurar la consistencia con el resto de los SI de la organización
Diferencia entre ciclo de vida (el qué) y metodología (el cómo)
: esta indica cómo avanzar en la constitución del sistema (técnicas, recursos, herramientas.)
Para cada proyecto hay que decidir el ciclo de vida que se seguirá, adaptándose mediante un mapa de actividades. Según el proyecto se pueden adoptar aspectos de distintos modelos que sean más adecuados en función de criterios como la volatilidad de los requisitos, los riesgos, el área de aplicación..etc
Modelos tradicionales
El modelo Code-and-Fix
: utilizado en los primeros desarrollos de software, se fundamente en la creación del código y en la corrección y adaptación del mismo
2 Pasos : Escribir código y corregir problemas del mismo
Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación y manteniiento
Problemas
Después de un nº de correcciones, el código puede tener una muy mala estructura, con modificaciones cada vez más costosas
Frecuentemente no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara. (se soluciona añadiendo una fase de análisis de requerimientos antes del diseño)
Modelo clásico o en cascada
:
Los
modelos por etapas
estaban basados en una serie de fases que se suceden secuencialmente donde se generan en cada fase los resultados necesarios para iniciar la fase siguiente, pero
no permitían la realimentación entre fases
, lo que dificultaba la resolución de problemas detectados en una etapa anterior
El
modelo en cascada, enunciado por Royce en 1970
, con la misma estructura secuencial,
permite la retroalimentación entre fases
, y en algunas de sus variantes incluso entre las que no son consecutivas
Fases
1. Planificación :
se realizan tareas previas para determinar como mínimo el ámbito, los recursos, las tareas, el coste y una planificación temporal
2. Análisis (qué) :
se desarrolla el documento de requisitos del software que consistirá en una especificación precisa y completa de lo que debe hacer el sistema
3. Diseño (cómo) :
se descompone el sistema en elementos que puedan ser desarrollados por separado. Se desarrolla el documento del diseño del software que será una descripción de la estructura global del sistema
4. Codificación :
se traduce el diseño a un lenguaje de programación ejecutable por un ordenador, y las pruebas necesarias para garantizar que dicho código funciona perfectamente
5. Pruebas e integración :
se prueba el sistema completo para garantizar el funcionamiento correcto del conjunto
6. Implantación y aceptación :
se valida que el sistema es lo que necesitan los usuarios y se pone en producción para su utilización
7. Mantenimiento :
durante la explotación del sistema puede ser necesario realizar cambios para corregir errores no detectados en las fases anteriores o para introducir mejoras
Trata de aislar las fases de forma que puedan ser desarrolladas por grupos de personas distintas facilitándose la especialización
Inconvenientes
En los proyectos reales es muy difícil seguir estrictamente la secuencialidad
Resultados totales : la utilización de los resultados de una fase como inicio de la siguiente supone que de cara a los usuarios, el sistema sólo se pueda validad cuando esté terminado
Se suela aplicar en los desarrollos mediante prototipos
Modelos evolutivos
: son modelos
iterativos
basados en la construcción de versiones tempranas de los sistemas software que pueden evaluar los usuarios para luego desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado.
Ventajas
Facilita la comunicación entre el analista y el usuario.
Se hace partícipe al usuario en el desarrollo, con lo que disminuye el riesgo de rechazo en la implantación
Inconvenientes
Puede crear falsas expectativas
Puede ser a veces difícil evolucionar la versión si no se ha construido pensando en la flexibilidad o se ha construido usando algoritmos ineficientes y poco optimizados
Modelos basados en prototipos
: se centran en ofrecer una mayor comprensión de los requisitos que el usuario plantea, a la vez que intenta valorar la viabilidad de la solución propuesta de una manera temprana
Prototipado rápido
: llamados de "usar y tirar", deben poder construirse con facilidad y en poco tiempo para evaluarlos en una fase temprana del desarrollo y han de ser baratos
El prototipo sirve para validar la especificación con lo que realmente necesita el usuario antes de comenzar el desarrollo, en especial sobre aspectos desconocidos o que se sospecha que se hayan podido entender mal
Una vez aceptado, el prototipo de desecha y comienza el desarrollo desde cero, aplicando el modelo en cascada.
Prototipado evolutivo :
indicado cuando le usuario no sabe lo que quiere. EL objetivo es tener un sistema que se pueda expandir rápidamente haciendo uno nuevo cuando los requisitos cambien o se van conociendo. El prototipo NO se desecha
Se asume desde el principio que los requisitos van a cambiar continuamente .
Los restantes requisitos se añaden en sucesivas evoluciones del prototipo, donde cada una es realmente una nueva versión de todo el sistema
Este modelo está relacionado con el concepto de
RAD (Rapid Application Development)
Inconveniente
: la estructura del código de una determinada versión del prototipo muchas veces no es lo suficientemente flexible y fácil de cambiar, y se ve obligado a reescribir la estructura básica del sistema, lo que incrementa mucho el coste de la siguiente versión
Prototipado incremental
: consiste en desarrollar un sistema que logre cubrir una parte de los requisitos especificados y luego ir generando nuevas versiones del sistema que incorporen el resto de funcionalidades y requisitos especificados, hasta llegar a un producto final planteado
Los
requisitos SI se conocen en su totalidad
, pero su implementación se va dosificando deliberadamente
Modelos alternativos
El modelo en espiral
: propuesto por Boehm y tiene las características propia de un desarrollo iterativo mediante el cual se generan distintos prototipos, pero incorpora como nuevo elemento el análisis de riesgos
Es el modelo más versátil y flexible, pero también el más complejo
Cada vuelta de espiral supone un refinamiento del desarrollo hacia el sistema final.
Cada ciclo se basa en iteraciones o ciclos de la espiral y en cada uno :
Se planifica
lo que se va a hacer teniendo en cuenta los condicionantes para su cumplimiento (restricciones de coste, tiempo, etc) y las posibles alternativas
Se analiza el riesgo
de hacerlo y se elige la mejor alternativa. Se puede plantear la realización de prototipos para evaluar el riesgo de un cierto aspecto. Del resultado de la evaluación de tomará una opción u otra a la hora del siguiente paso,
Se construye
aplicando un proceso de ingeniería y siguiendo el modelo de ciclo de vida que se considere oportuno, un elemento o prototipo del sistema final.
Se evalúa
lo que se ha alcanzado. De la evaluación se determina si se debe continuar con otro ciclo de espiral o por el contrario se debe parar porque se ha completado el sistema
De este modo habrá unos
ciclos externos
de la espiral que representan las fases del desarrollo del proyecto software (normalmente las del modelo clásico) y unos
ciclos internos iterativos
en los que se llevan a cabo las 4 actividades citadas para cada fase
Elementos más habituales de riesgo. Para todos ellos hay que elaborar un plan para resolverlo y hacer un seguimiento de su estado y el resultado de las acciones correctoras
Personal
Presupuestos y calendarios no realistas
Desarrollo de funciones de software no adecuadas
Desarrollo de interfaz de usuario no adecuada
Continuos cambios de requerimientos
Componentes adquiridos de baja calidad
Tareas realizadas externamente sin el nivel adecuado
Problemas en el rendimiento en tiempo real
Querer ir más allá del estado actual de las posibilidades tecnológicas
Ventajas
Incluye a los demás modelos
en etapas, mientras el procedimiento dirigido por el análisis de riesgos evita muchas dificultades
Facilita la temprana
eliminación de errores y alternativas poco atractivas
Permite la
reutilización de software existente
La identificación de objetivos y restricciones en cada ciclo benefician el
grado de calidad
en el desarrollo
El procedimiento para el desarrollo del software es el mismo que el de mejora del mismo
(mantenimiento)
Es aplicable a
sistemas de software muy grandes y complejo
s
Dificultades
Es difícil su aplicación en el caso de software contratado
, por el esfuerzo que supone las tareas que no son de ingeniería, como la validación de los usuarios, análisis de riesgos y el prototipado
Depende en exceso de la experiencia en la evaluación de riesgos
No resulta apropiado para sistemas pequeños
Modelos basados en la transformación
Se han propuesto como s
olución al problema del código mal estructurado
, de difícil mantenimiento, que en general se produce con los modelos en cascada
La filosofía general es llegar a
generar código
a partir de especificaciones formales transformándolas por medio de
herramientas automáticas
Pasos
Especificación formal de los requisitos del sistema
Transformación automática de la especificación de código
Un bucle iterativo, si fuera necesario, para mejorar el rendimiento del código
Probar el producto resultante
Reajustar las especificaciones y volver al punto 2 hasta la completa aceptación del sistema
Dificultad :
las posibilidades de transformación automáticas solo están disponibles para aplicaciones muy pequeñas o para áreas muy limitadas
Tipos
Los que usan técnicas de 4ª generación :
basados en lenguajes no procedimentales para consultas a BBDD, generadores de código-pantalla-informes, facilidades gráficas de alto nivel..
Basados en herramientas CASE :
permiten, siguiendo el modelo de ciclo de vida clásico, pasar de una etapa a otra aplicando las transformaciones que dan las herramientas.
Ejemplo :
SONAR
Modelos ágiles
: En 2001 se acuñó el término para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales, consideradas excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas
4 postulados del Manifiesto Ágil
Los
individuos y su interacción
, por encima de procesos y herramientas
El software que funciona
, por encima de la documentación exhaustiva
La colaboración con el cliente
, por encima de la negociación contractual
La respuesta al cambio
, por encima del seguimiento a un plan
Ejemplos de metodologías (no ciclos de vida) : SCRUM, LEAN
Otras alternativas
DSBC (Desarrollo de Software Basado en Componentes) :
este modelo hace hincapíe en la
reutilización
ya que su enfoque consiste en configurar y ensamblar componentes de software ya existentes al software que se está desarrollando y que normalmente están contenidos en librerías
Pretende
reducir costes
no con prototipado, sino con la reutilización de componentes software incorporando
código previamente probado
Fase del ciclo de vida
Buscar componentes (COTS)
Seleccionar los más adecuados para el sistema
Crear una solución compuesta que integre lo previo
Adaptar los componentes seleccionados de forma que se ajuste a lo que se requiere
Componer y distribuir el producto
Mantener el producto global y reemplazar las versiones anteriores de los COTS
Los productos COTS, pueden presentar problemas específicos como incompatibilidad, inflexibilidad (no hay fuentes), complejidad(esfuerzo de aprendizaje) o cambios de versiones
Son los
COTS (Commercial off-the-self)
, o componentes ya realizados listos para usar. Adecuado para
tecnologías orientadas a objetos
PUDS (Proceso Unificado de Desarrollo de Software) :
plantea un MCV
iterativo e incremental,
centrado en una arquitectura que guía el desarrollo del sistema, cuyas actividades están dirigidas por
casos de uso y soporta las técnicas orientadas a objetos
. PUDS impulsa un control de calidad y una gestión de riesgos objetivos y continuos.
Se compone de fases, iteraciones y ciclos
Fase :
es el intervalo de tiempo entre dos hitos importantes del
proceso durante la cual se cumple un conjunto bien definido de objetivos, se completan entregables y se toman las decisiones
sobre si pasar o no a la siguiente fase.
Fase de Iniciación: establece la planificación del proyecto
Fase de Elaboración :establece un plan para el proyecto y una arquitectura correcta
Fase de Construcción : desarrollo del sistema
Fase de Transición :proporciona el sistema a los usuarios finales
En cada fase hay varias
iteraciones
: . La iteración produce una versión de un producto entregable que luego se irá incrementando de iteración en iteración hasta convertirse en el sistema final.Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el
ciclo de vida
clásico o en cascada: Análisis de requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.
Características
Iterativo e incremental
Dirigido por los casos de uso
: los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño, implementación, prueba, etc. El proceso dirigido por casos de uso es el
rup
Centrado en la arquitectura
: asume que no existe un modelo único que cubra todos los aspectos del sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de software de un sistema
Enfocado en los riesgos
: requiere que el equipo del proyecto se centre en identificar los riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase de Elaboración deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.