El modelo lineal secuencial.

Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal secuencial sugiere un enfoque sistemtico, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. La Figura 2.4 muestra el modelo lineal secuencial para la ingeniera del software. Modelado segn el ciclo de ingeniera convencional, el modelo lineal secuencial comprende las siguientes actividades: Ingeniera y modelado de Sistemas/Informacin. Como el software siempre forma parte de un sistema ms grande (o empresa), el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algn subgrupo de estos requisitos. Esta visin del sistema es esencial cuando el software se debe interconectar con otros elementos como hardware, personas y bases de datos. La ingeniera y el anlisis de sistemas comprenden los requisitos que se recogen en el nivel del sistema con una pequea parte de anlisis y de diseo. La ingeniera de informacin abarca los requisitos que se recogen en el nivel de empresa estratgico y en el nivel del rea de negocio.

Diseo. El diseo del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso del diseo traduce requisitos en una representacin del software donde se pueda evaluar su calidad antes de que comience la codificacin. Generacin de cdigo. El diseo se debe traducir en una forma legible por la mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo de una forma detallada, la generacin de cdigo se realiza mecnicamente. Pruebas. Una vez que se ha generado el cdigo, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales; es decir, realizar las pruebas para la deteccin de errores y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos. Mantenimiento. El software indudablemente sufrir cambios despus de ser entregado al cliente (una excepcin posible es el software empotrado). Se producirn cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su

entorno externo (por ejemplo: se requiere un cambio debido a un sistema operativo o dispositivo perifrico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El soporte y mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.

Desventajas Por qu falla algunas veces el modelo lineal? Los proyectos reales raras veces siguen el modelo Secuencial que propone el modelo. Aunque el modelo lineal puede acoplar interaccin, lo hace indirectamente. Como resultado, los cambios pueden causar confusin cuando el equipo del proyecto comienza. A menudo es difcil que el cliente exponga explcitamente todos los requisitos. El modelo lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre natural al comienzo de muchos proyectos. El cliente debe tener paciencia. Una versin de trabajo del (los) programa(s) no estar disponible hasta que el proyecto est muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

El Desarrollo Rpido de Aplicaciones (DRA)

es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rpido utilizando una construccin basada en componentes. Ventajas Si se comprenden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente funcional dentro de perodos cortos de tiempo (por ejemplo: de 60 a 90 das) Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Desventajas Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el nmero correcto de equipos DRA. DRA requiere clientes y desarrolladores comprometidos en las rpidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay compromiso por ninguna de las partes constituyentes, los proyectos DRA fracasarn. No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modularizar adecuadamente, la construccin de los componentes necesarios para DRA ser problemtico. Si est en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistemas, el enfoque DRA puede que no funcione. Etapas Modelado de Gestin. El flujo de informacin entre las funciones de gestin se modela de forma que responda a las siguientes preguntas: Qu informacin conduce el proceso de gestin? Qu informacin se genera? Quin la genera? A dnde va la informacin? Quin la procesa? Modelado de datos. El flujo de informacin definido como parte de la fase de modelado de gestin se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de informacin necesario para implementar una funcin de gestin. Las descripciones del proceso se crean para aadir, modificar, suprimir, o recuperar un objeto de datos.

.7.2. El modelo espiral

El modelo en espiral, propuesto originalmente por Boehm [BOE88], es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construccin de prototipos con los aspectos controlados y sistemticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rpido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteracciones, la version incremental podra ser un modelo en papel o un prototipo. Durante las ltimas iteraciones, se producen versiones cada vez ms completas del sistema diseado. El modelo en espiral se divide en un nmero de actividades de marco de trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres y seis regiones de tareas. comunicacin con el cliente-

las tareas requeridas para establecer comunicacin entre el desarrollador y el cliente. planificacin- las tareas requeridas para definir recursos, el tiempo y otra informacin relacionadas con el proyecto. anlisis de riesgos- las tareas requeridas para evaluar riesgos tcnicos y de gestin. ingeniera- las tareas requeridas para construir una o ms representaciones de la aplicacin. construccin y accin- las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentacin y prctica) evaluacin del cliente- las tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las representaciones del software creadas durante la etapa de ingeniera e implementada durante la etapa de instalacin. Ventajas A diferencia del modelo de proceso clsico que termina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. Desventajas Pero al igual que otros paradigmas, el modelo en espiral no es la panacea. Puede resultar difcil convencer a grandes clientes (particularmente en situaciones bajo contrato) de que el enfoque evolutivo es controlable. Requiere una considerable habilidad para la evaluacin del riesgo, y cuenta con esta habilidad para el xito. Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas. El modelo de mtodos formales. El modelo de mtodos formales comprende un conjunto de actividades que conducen a la especificacin matemtica del software de computadora. Los mtodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notacin rigurosa y matemtica. Algunas organizaciones de desarrollo del software actualmente aplican una variacin de este enfoque, llamado ingeniera del software de sala limpia. ventajas durante el desarrollo, proporcionan un mecanismo para eliminar muchos de los problemas que son difciles de superar con paradigmas de la ingeniera del software.

La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen ms fcilmente -no mediante un revisin a propsito para el caso, sino mediante la aplicacin del anlisis matemtico-. Cuando se utilizan mtodos formales durante el diseo, sirven como base'para la verificacin de programas y por consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera. Desventajas El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo. Se requiere un estudio detallado porque pocos responsables del desarrollo de software tienen los antecedentes necesarios para aplicar mtodos formales. Es difcil utilizar los modelos como un mecanismo de comunicacin con clientes que no tienen muchos conocimientos tcnicos. etapas o pasos El primer paso en la aplicacin de los mtodos formales es definir el invariante de datos, el estado y las operaciones para el funcionamiento de un sistema. El invariante de datos es una condicin que se verifica mediante la ejecucin de una funcin que contiene un conjunto de datos. Los datos almacenados forman el estado en donde una funcin puede acceder y alterar; y las operaciones son las acciones que tienen lugar en un sistema a medida que lee o escribe datos en un estado. Una operacin se asocia a dos condiciones: una precondicin y una postcondicin. La notacin y la heurstica asociadas con los conjuntos y especificaciones constructivas operadores de conjuntos, operadores lgicos y sucesiones- forman la base de los mtodos formales.