Paradigmas de desarrollo de Software

1. Modelo de prototipos

1.1. El modelo de prototipos permite desarrollar modelos de aplicaciones de software que permiten ver la funcionalidad básica de la misma, sin necesariamente incluir toda la lógica o características del modelo terminado.

1.2. El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un “diseño rápido”. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.

2. Modelo de desarrollo rápido de aplicación (DRA)

2.1. El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de software, que implica el desarrollo iterativo y la construcción de prototipos.

2.2. El objetivo clave de este modelo es un rápido desarrollo y entrega de una alta calidad en un sistema de relativamente bajo coste de inversión. Intenta reducir el riesgos inherente del proyecto partiendolo en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo. Orientación dedicada a producir sistemas de alta calidad con rapidez, principalmente mediante el uso de iteración por prototipos (en cualquier etapa de desarrollo), promueve la participación de los usuarios y el uso de herramientas de desarrollo computarizadas. Estas herramientas pueden incluir constructores de Interfaz gráfica de usuario (GUI), Computer Aided Software Engineering (CASE) las herramientas, los sistemas de gestión de bases de datos (DBMS), lenguajes de programación de cuarta generación, generadores de código, y técnicas orientada a objetos.

3. Modelo de desarrollo concurrente.

3.1. Este modelo se utiliza a menudo como el paradigma de desarrollo de aplicaciones cliente/servidor.

3.2. Provee una meta-descripción del proceso del software. El modelo concurrente tiene la capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.

4. Modelo de métodos formales.

4.1. El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la especificación matemática del software de computadora. Los métodos formales permiten que un ingeniero del software especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.

4.2. La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente, no mediante una revisión a propósito para el caso, sino mediante la aplicación del análisis matemático. Cuando se utilizan métodos formales durante el diseño, sirven como base para la verificación de programas y por consiguiente permiten que el ingeniero del software descubra y corrija errores que no se pudieron detectar de otra manera.

5. Modelo lineal Secuencial o Cascada

5.1. Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implantación, pruebas (validación), la integración, y mantenimiento.

5.2. Este paradigma concibe las fases de desarrollo como proceso independientes en el tiempo, es decir, no se pueden realizar de manera simultánea; cada fase empieza cuando se ha terminado la fase anterior y para poder pasar a otra fase es necesario haber conseguido todos los objetivos de la etapa previa.

5.3. Las etapas de este paradigma se desarrollan en forma secuencial y cuando se detecta algún error en alguna etapa, lo más probable será abandonar todo lo avanzado y regresar a la etapa primera de análisis de requisitos del sistema; pues, aunque la vuelta atrás por etapas es posible, ésta demanda mucho esfuerzo y puede terminar en el colapso. Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Diseño. El diseño del software se centra en cuatro atributos de un programa: estructura de datos, arquitectura del software, representaciones de interfaz y detalle procedimental (algoritmo). Codificación: Se traducir en forma legible por la máquina el modelo previamente diseñado. El paso de generación de código lleva a cabo esta tarea. Si lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente. Pruebas. El proceso de pruebas se centra en los procesos lógico internos del software, y en los procesos externos funcionales. Se deben realizar las pruebas para detección de errores y asegurarse que las entradas definidas produzcan resultados reales que concuerden con los resultados requeridos. Mantenimiento. El software indudablemente sufrirá cambios después de ser entregado al cliente. El mantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.

6. Modelo Espiral

6.1. El paradigma de espiral es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en miniproyectos y donde cada miniproyecto se centra en uno o más riesgos importantes hasta que todos estos estén controlados.

6.2. Este modelo se realiza en varias iteraciones; se parte de una escala pequeña la cual comienza con la identificación de objetivos, alternativas y restricciones; en medio de la espiral, se localizan riesgos, se genera un plan para manejarlos, y a continuación se establece una aproximación a la siguiente iteración.

7. Modelo Incremental.

7.1. El modelo Incremental se va creando el Software añadiendo componentes funcionales al sistema: incrementos.

7.2. Los sistemas presentan alguna áreas que incluyen sorpresas al momento de definir o desarrollar el producto, pero también presentan otras áreas que hemos implementado varias veces y no incluyen sorpresas, entonces, por qué retrasar la implementación de estas áreas que son fáciles de modelar solamente porque estamos considerando que en el proyecto existen algunas áreas difíciles.

7.3. Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial (núcleo). Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detallada). Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente.

7.4. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. En este paradigma el software se ve como una integración de resultados sucesivos obtenidos después de cada interacción. Este modelo se adecua a entornos de alta incertidumbre.

8. Modelo de ensamblaje de compoentes.

8.1. El modelo ensamblador de componentes configura aplicaciones desde componentes preparados de software (algunas veces llamados << clases >>). La actividad de la ingeniería comienza con la identificación de clases candidatas. Esto se lleva a cabo examinando los datos que se van a manejar por parte de la aplicación y el algoritmo que se va a aplicar para conseguir el tratamiento. Los datos y los algoritmos correspondientes se empaquetan en una clase.

8.2. El modelo de ensamblaje de componentes incorpora muchas de las características del modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un enfoque interactivo para la creación del software. Sin embargo, el modelo ensamblador de componentes configura aplicaciones desde componentes preparados de software (algunas veces llamados << clases >>).

8.3. El modelo ensamblador de componentes lleva a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros del software.