Definición de Paradigma:
Para la Ingeniería de Software el paradigma es una agrupación de métodos, herramientas y procedimientos con el fin de describir un modelo.
Paradigmas de la Ingeniería de Software:
Cada metodología de desarrollo de software tiene más o menos su propio enfoque para el desarrollo de software.
La ingeniería del Software define paradigmas de desarrollo estructurado como base a seguir en un proyecto de Software. Si ninguno de estos paradigmas se adecua al problema por resolver, entonces el desarrollador se verá obligado a combinar los paradigmas o definir uno nuevo.
Para resolver los problemas reales, el ingeniero del software debe incorporar una estrategia de desarrollo que acompañe al proceso, métodos y capas de herramientas.
La estrategia a menudo se llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse y los controles y entregas que se requieren.
Los paradigmas o modelos de desarrollo de software más utilizados son: el método de cascada, el método de prototipos y el de Espiral.
Modelo Lineal Secuencial o de Cascada (Waterfall):
La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce en 1970, aunque Royce no utilizó el término "cascada" en este artículo.
Es el paradigma más antiguo y fue el más utilizado durante la hegemonía del método estructurado. El número de etapas propuestas varía de acuerdo al proyecto a desarrollar, aunque existen etapas comunes para este paradigma.
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.
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.
Definición de los requisitos. En este proceso se identifican las necesidades y requerimientos del cliente con respecto al software.
Análisis y Diseño. En el análisis se establece la viabiliad del software desde el punto de vista técnico y económico, se planifican las actividades y el presupuesto. En 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.
Modelos de Prototipos:
El prototipo permite al cliente evaluar en forma temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si se está cumpliendo con las expectativas y las funcionalidades acordadas.
Los Prototipos no poseen la funcionalidad total del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, y maneja un alto grado de participación del usuario.
Los modelos previos pueden ser en papel o computadora para mostrar la interacción hombre-máquina; un modelo que muestra algunas funciones del software; o, algún software anterior (parte o todo) parecido al que se desea, que luego será modificado y adaptado según los requerimientos del usuario.
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.
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existentes o aplica herramientas que permiten generar rápidamente programas de trabajo.
El paradigma de la elaboración por prototipos resulta una alternativa para el desarrollo rápido de aplicaciones de software; pues el analista acorta en tiempo entre la determinación de los requerimientos de información y la entrega de un sistema funcional, además que el usuario podrá modificar y depurar sus requerimientos conforme avance el desarrollo del proyecto.
Modelo en Espiral:
Este paradigma combina el paradigma de cascada y el de construcción por prototipos, agregando una etapa de "análisis de riesgo".
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.
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.
Se proporciona el potencial para el desarrollo rápido de versiones increméntales del software. En el modelo espiral, el software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones, la versión incrementar podría ser un modelo en papel prototipo.
Durante las últimas iteraciones, se producen versiones cada vez más completas de ingeniería del sistema. El modelo en espiral se divide en un número de actividades estructurales también llamadas guiones de tareas. Estas inclusive pueden variar de 3 a 6 tareas.
Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso de la región de planificación produce ajustes en el plan del proyecto.
El costo y la planificación se ajustan según la reacción ante la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para completar el software.
En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativo hasta que el software se retira. Hay veces en que el proceso está inactivo, pero siempre que se inicie un cambio, el proceso arranca en el punto de entrada adecuado (p. Ej.: mejora el producto).
El modelo en espiral es un enfoque realista del desarrollo de sistemas y de software a gran escala. Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.
El modelo en espiral utiliza la construcción de prototipos como mecanismos de reducción de riesgos, pero lo que es más importante, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.
Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero lo incorpora al marco de trabajo interactivo que refleja de forma más realista el mundo real. El modelo en espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.
El paradigma espiral, al igual que los demás modelos, se puede combinar con otros paradigmas.
Módelo “Rapid Application Development” (RAD)
El desarrollo rápido de aplicaciones es un término originalmente utilizado para describir un proceso de desarrollo de software introducido por James Martin en 1991.
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.
Hace especial hincapié en el cumplimiento de la necesidad comercial, mientras que la ingeniería tecnológica o excelencia es de menor importancia.
El control de proyecto implica el desarrollo de prioridades y la definición de los plazos de entrega. Si el proyecto empieza a aplazarse, se hace hincapié en la reducción de requisitos para el ajuste, no en el aumento de la fecha límite.
En general incluye “Joint application development” (JAD), donde los usuarios están intensamente participando en el diseño del sistema, ya sea a través de la creación de consenso estructurado en talleres, o por vía electrónica.
La participación activa de los usuarios es imprescindible.
Iterativamente realiza la producción de software, en lugar de enfocarse en un prototipo.
Produce la documentación necesaria para facilitar el futuro desarrollo y mantenimiento.
Criterios Generales para Seleccionar un Paradigma:
El ingeniero de sistemas debe estar en capacidad de seleccionar de manera correcta la utilización de alguno de los paradigmas anteriormente mencionados o una combinación de ellos, evaluando las principales características del problema al cual se enfrentará.
Estas características se deben captar en la fase de análisis general del sistema y deberán reforzarse en la etapa de análisis detallado del sistema. Como puntos de evaluación para la selección del paradigma adecuado tenemos:
- La naturaleza del proyecto, donde se agrupan criterios como la complejidad del producto final, el conocimiento de la aplicación por parte del grupo, la utilización final del software, etc.
- El control del proyecto y la importancia de los avances, directamente relacionado con las características del cliente, sus perspectivas y deseos respecto al software, la importancia de su inclusión en el grupo de desarrollo del producto, etc..
- Los métodos y las herramientas disponibles para el desarrollo de cada una de las fases a realizar.
