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

...