Paradigmas De La Ingenieria De Software

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 u modelo.

Un "paradigma" es un modelo para comprender la realidad, que nos permite relacionarnos con el mundo circundante y tener un sentido de identidad dentro de lo que percibimos que es "el mundo real".

Fases Generales del Proceso de Desarrollo de Software:

Independientemente del procedimiento de desarrollo, la aplicación del software y el tamaño del proyecto; el desarrollo de software contiene tres fases genéricas definición, desarrollo y mantenimiento, desde la concepción de desarrollo estructurado de software.

Los paradigmas de la ingeniería de software conservan estas fases generales, variando los métodos, las herramientas y procedimientos para aplicarlos.

Paradigmas de la Ingeniería 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 de una industria, un ingeniero del software o un equipo de ingenieros deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos, 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.

Raccoon [RAC95] sugiere un << modelo del caos >> que describa el << desarrollo del software como una extensión desde le usuario hasta el desarrollador y la tecnología >>. Conforme progresa el trabajo hacia un sistema completo, las etapas descritas anteriormente se aplican recursivamente a las necesidades, del usuario y a la especificación técnica del desarrollador del software.

Modelo Lineal Secuencial o Cascada Pura (Waterfall)

Por supuesto Royce en 1970; 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.

Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica y se centra especialmente en el software. Para comprender la naturaleza de el (los) programa (s) a construirse, el ingeniero (<< analista >>) del software debe comprender el dominio de información del software (descrito en el Capitulo 1.1), así como la función requerida, comportamiento, rendimiento e interconexión. El cliente documenta y repasa los requisitos del sistema y del software.

Diseño. El diseño del software es real mente un proceso de muchos pasos que se centra en cuatro atributos de un programa: estructura de datos, arquitectura del software, representaciones de interfaz y detalle procedimental (algoritmo). El proceso de diseño traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación del código. Al igual que los requisitos, el diseño se documenta y se hace parte de la configuración del software.

Generación de código. El diseño se debe traducir en una forma legible por la máquina. 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. Una vez que se ha generado un código, comienzan las pruebas del programa. El proceso de pruebas se centra en los procesos lógico internos del software, asegurando que todas las sentencias se han comprobado, yen los proceso externos funcionales, es decir, la realización de las pruebas para le detección de errores y el sentirse seguro de que la entrada definida produzca resultados reales de acuerdo con los resultados requeridos.

Mantenimiento. El software indudablemente sufrirá cambios después de ser entregado al cliente (una excepción posible es el software empotrado). Se producirán cambios porque se han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios de su entorno externo (p. Ej.: se requiere un cambio debido a un sistema operativo o dispositivo periférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El mantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.

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 lo 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.

El paradigma de cascada puro presenta las siguientes ventajas y desventajas.

La aplicación de este paradigma es recomendada para proyectos donde cada etapa sea independiente de la siguiente, para proyectos donde los requerimientos de información se puedan determinar de manera clara y exacta, y éstos no sean modificados conforme pase el tiempo, para proyectos donde nos enfrentemos a clientes pacientes, pues el software no estará disponible hasta el final del ciclo, para proyectos donde se cuente con herramientas de calidad para el levantamiento acertado de información.

Modelos en Función de Prototipos

Cuando en la etapa de análisis se necesitan de técnicas amigables para la elaboración del ERS, es recomendable el empleo de herramientas de levantamiento de información como son los prototipos o modelos previos. 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 (p. Ej.: enfoques de entrada y formatos de salida). 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 satsface 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 (p. Ej.: generadores de informes, gestores de ventanas, etc.) 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.

El paradigma de desarrollo por prototipos presenta las siguientes ventajas y desventajas.

El paradigma de prototipos es aplicable a proyectos de análisis acelerado, donde sólo se cuente con requisitos generales; a proyectos con clientes impacientes de ver algo funcionando; a proyectos con clientes dispuestos a reaccionar abiertamente con el prototipo. No es recomendable aplicarlo a proyectos con clientes exigentes de calidad, pues los prototipos son susceptibles a muchos fallos, y el cliente se puede formar una idea equivocada de la seriedad del desarrollador.

Modelo de Desarrollo rápido de Aplicación (DRA)

Este es un modelo de proceso de desarrollo del software lineal, secuencias que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a << alta velocidad >> del modelo lineal secuencial 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 (p. Ej.: de 60 a 90 días) [MAR9]. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

Modelado

...