Introducción
v Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre la idea inicial y el producto final.
v Un modelo de desarrollo establece el orden en el que se harán las cosas en el proyecto, nos provee de requisitos de entrada y salida para cada una de las actividades.
v Es necesario destacar el ciclo de vida del proyecto y el modelo de desarrollo.
v El ciclo de vida del proyecto ayuda a controlar las actividades del proyecto desde el inicio al fin del mismo.
v El modelo de desarrollo nos ayuda a la forma en la que vamos a construir el producto.
v Ambos se complementan para generar el producto desde el punto de vista técnico y administrativo.
Modelo Lineal SecuencialTambién llamado "Ciclo de vida básico" o "Modelo de casca "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.
El MLS es el paradigma de desarrollo de software más antiguo que existe, sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de él basada en los siguientes errores reales:
* Los proyectos raramente siguen el paradigma secuencial que propone el proyecto.
* A menudo es difícil que el cliente exponga exactamente todos los requisitos.
* El cliente debe tener paciencia.
* Los responsables del desarrollo de software siempre se retrasan innecesariamente.
Modelo de Construcción de Prototipos
Este modelo arranca con el establecimiento de los requerimientos del sistema, se definen los objetivos del sistema y los requisitos conocidos con base en las áreas de mayor prioridad e importancia para el sistema.
Luego se hace un diseño preliminar, sobre el cual se construye un prototipo o modelo del sistema, compuesto a menudo de ventanas, tablas de la Base de Datos, formatos de entrada y de salida básicos.
Un prototipo es una representación o modelo del producto de programación que, a diferencia de un modelo de simulación, incorpora componentes del producto real. Por lo regular, un prototipo tiene un funcionamiento limitado en cuanto a capacidades, confiabilidad o eficiencia.
Hay varias razones para desarrollar un prototipo; una de ellas es ilustrar los formatos de datos de entrada, mensajes, informes y diálogos al cliente, este es un mecanismo adecuado para explicar opciones de procesamiento y tener un mejor entendimiento de las necesidades de él.
Al igual que el ciclo de vida clásico, la construcción de prototipos puede ser problemática por las siguientes razones:
1.- El cliente ve funcionando lo que parece ser una primera versión del software, ignorando que, por las prisas en hacer que funcione, no hemos considerado los aspectos de calidad o de mantenimiento del software a largo plazo. Cuando se le informa de que el producto debe ser reconstruido, el cliente se vuelve loco y solicita que se apliquen “cuantas mejoras” sean necesarias para hacer del prototipo un producto final que funcione.
2.- El técnico de desarrollo, frecuentemente, impone ciertos compromisos de implementación con el fin de obtener un prototipo que funciones rápidamente. Puede que utilice un sistema operativo inapropiado, o un lenguaje de programación equívoco o simplemente porque ya está disponible y es conocido, puede que implemente ineficientemente un algoritmo, sencillamente para demostrar su capacidad.
Modelo de Desarrollo Rápido de Aplicaciones
El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. 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 periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:
- Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?
- Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.
- Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.
- Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.
- Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, 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 interfases a fondo.
Obviamente la limitación de tiempo impuestas en un proyecto DRA demanda "ámbito en escalas". Si una aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y ser integradas en un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
- Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el número correcto de equipos DRA.
- DRA requiere clientes y desarrolladores comprometidos en las rápidas 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 fracasaran.
No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.
DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.
Modelo Incremental
Perteneciente a la familia de los Modelos de Procesos Evolutivos, el Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de prototipos.
El proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o "Pipeline", utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo.
Al igual que los otros métodos, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
Modelo Espiral
El modelo espiral para la ingeniería de software ha sido desarrollado para cubrir las mejores características tanto del ciclo de vida clásico, como de la creación de prototipos, añadiendo al mismo tiempo un nuevo elemento: el análisis de riesgo. El modelo representado mediante la espiral define cuatro actividades principales:
1. Planificación: determinación de objetivos, alternativas y restricciones.
2. Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos.
3. Ingeniería: desarrollo del producto del "siguiente nivel",
4. Evaluación del cliente: Valorización de los resultados de la ingeniería.
Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el análisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creación de prototipos en el cuadrante de ingeniería para dar asistencia tanto al encargado de desarrollo como al cliente.
El cliente evalúa el trabajo de ingeniería (cuadrante de evaluación de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificación y de análisis de riesgo. En cada bucle alrededor de la espiral, la culminación del análisis de riesgo resulta en una decisión de "seguir o no seguir".
Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez más completa y, al final, al propio sistema operacional.
Utiliza un enfoque evolutivo para la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de creación de prototipos en cualquier etapa de la evolución de prototipos.
Modelo de Desarrollo Concurrente
ue escrito por Davis y Sitaram, algunas veces llamado ingeniería concurrente. Se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas y estados asociados a ellas.
El modelo de proceso concurrente define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software.
El modelo de proceso concurrente se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componentes funcionales. Cuando se aplica a cliente/servidor, el modelo de proceso concurrente define actividades en 2 dimensiones: una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante 3 actividades: diseño, ensamblaje y uso. La dimensión de componentes se afronta con 2 actividades: diseño y realización.
La concurrencia se logra de 2 formas: 1).- las actividades de sistemas y de componentes ocurren simultáneamente y pueden modelarse con el enfoque orientado a objetos; 2).- una aplicación cliente/servidor típica se implementa con muchos componentes, cada uno de los cuales se pueden diseñar y realizar concurrentemente.
El modelo de proceso concurrente es aplicable a todo tipo de desarrollo de software y proporciona una imagen exacta del estado actual del proyecto.
Modelo de Desarrollo basado en Componentes
Incorpora muchas de las características del Modelo Espiral. Es evolutivo por naturaleza y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo ensamblador de componentes configura aplicaciones desde componentes separados del software (algunas veces llamados "clases").
Esto se debe gracias a que, si se diseñan y se implementan adecuadamente, las clases orientadas a objetos son reutilizables por las diferentes aplicaciones y arquitecturas de sistemas basados en computadoras.
En primer lugar se identifica las clases candidatas examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a crear para conseguir el tratamiento. Si estas clases han sido creadas por programas anteriores se almacenan en un biblioteca de clases o depósito. Se determina cuáles de ellas ya existen a fin de reutilizarlas. En caso de que exista alguna que no esté diseñada, se aplican los métodos orientados a objetos. Este proceso se inicia en el estado de Análisis de Riesgos del Espiral y se inserta en el estado de Construcción de Ingeniería.
En resumen, este modelo se basa en ir construyendo con la construcción de cada sistema una biblioteca de Componentes (clases /objetos) , cuando se va a construir un nuevo sistema, se hace el proceso de definir los objetos del sistema, buscar en la librería de objetos, construir los que no existen, meterlos en la biblioteca, emsamblar los objetos, la metodología busca que sea evolutiva pasando por una fase de planificación, análisis de riesgos, ingeniería, construcción y adaptación, evaluación del cliente y repetir estas fases de tal forma que las primeras iteraciones desarrollan los conceptos, al avanzar se desarrollan los nuevos componentes, luego se busca mejorarlos y finalmente se les da mantenimiento.
Modelo de Métodos Formales
Su objetivo es aumentar la rigurosidad, consistencia y completitud en el desarrollo del software y evitar los problemas que son origen de errores en el software.
Una de las técnicas utilizadas para garantizar la calidad en un proyecto software es la verificación formal, que engloba una serie de técnicas matemáticas para demostrar que el software que se está desarrollando se ajusta a las especificaciones.
En 1967, fue Robert Floyd quien propuso utilizar lo que se denominó método de aserciones intermedias como una manera de estudiar las propiedades de los programas. Destacó la posibilidad de definir la semántica de las operaciones mediante reglas lógicas afirmando que estas aserciones son válidas después de ejecutarse las operaciones basándose en la información de las aserciones que son válidas antes de ejecutarse dichas operaciones.
Estas ideas fueron perfeccionadas por Hoare dando lugar al método axiomático (precondiciones E/S) donde introdujo la idea de "invariante".
En 1976, Edsger Dijkstra, presentó un método formal llamado precondición más débil, basado en la transformación de predicados wp (weakest precondition). De esta manera rompía con las ideas de verificación a posteriori de Floyd y Dijkstra. La idea principal era invertir los métodos de ambos de tal manera que se pudiera derivar la precondición a partir de la postcondición.
Entre los métodos de verificación más utilizados, se encuentran:
- Aserciones E/S
- Precondición más débil
- Inducción estructural.
Basado en la lógica de Hoare. El programa, en lógica de Hoare, se especifica mediante aserciones que relacionan las entradas y salidas del programa. Se garantiza que si la entrada actual satisface las restricciones de entrada (precondiciones) la salida satisface las restricciones de salida (poscondiciones).
Se utiliza una expresión del tipo P{programa}Q, siendo P y Q aserciones de la lógica, para indicar que si P es cierto antes de la ejecución del programa y dicho programa termina, entonces Q es cierto tras la ejecución de dicho programa. Este método permite tanto la corrección parcial como total de los programas.
Un caso especial son los bucles, donde los predicados deben mostrar una relación invariante, es decir, deben ser ciertos independientemente del número de vueltas del bucle, por lo tanto el predicado debe cumplir lo siguiente:
- Es cierto a la entrada del bucle
- Es cierto en cualquier paso del bucle
- Junto con la negación de la condición del bucle, implica que el predicado se cumple a la salida del bucle.
Precondición más débil
Básicamente, consiste en dada una poscondición POST, encontrar, operando hacia atrás, un programa S tal que wp(S, POST) (la precondición) se satisfaga en un amplio conjunto de situaciones
Dada una proposición (P) S (Q) donde S es un conjunto de sentencias de un módulo de un programa, y donde P y Q son los predicados que se cumplen antes y después de S respectivamente, se dice que P es la precondición más débil (wp) de S, si es la condición mínima que garantiza que R es cierto tras la ejecución de S.
Inducción estructural
La inducción estructural es una técnica de verificación formal que se basa en el principio de inducción matemática.
Dado un conjunto S con una serie de propiedades y una proposición P que se desea probar, la inducción matemática:
- Demuestra que P es cierto para el mínimo número de elementos (o casos triviales) de S.
- Asume que P es cierto para un número de elementos (o casos posibles) de S menores o iguales a N.
Demuestra que entonces P es cierto para el elemento N+1 de S.
Técnicas de 4ta Generación
Todas facilitan al ingeniero del software la especificación de algunas características del software a alto nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la especificación del técnico.
-Herramientas
Actualmente, un entorno para el desarrollo de el software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas:
· Lenguajes no procedí mentales de consulta a bases de datos.
· Generación de informes.
· Manejo de datos.
· Interacción y definición de pantallas.
· Generación de códigos.
· Capacidades gráficas de alto nivel.
Capacidades de hoja de cálculo.
Inicial mente estas herramientas eran utilizadas pero solo para aplicaciones muy especificas, y ahora la T4G se ha extendido a todas las categorías de aplicaciones de el software.
Las herramientas T4G generan automáticamente el código fuente basándose en el análisis y el diseño.
T4G comienza con el paso de reunión de requisitos; el dialogo cliente-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.
Ventajas y Desventajas
Ventajas:
Reducción en tiempo de desarrollo.
Desventajas:
Código ineficiente.
No más fáciles de usar que L3G.
Mantenimiento cuestionable.
No hay comentarios:
Publicar un comentario