Universidad De Córdoba. Molina Sergio, Burgos Hernán. Paradigmas de la ing. de software.

Resumen—la Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software. Integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería. 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.

Índice de Términos— Paradigmas, ingeniería, software, ingeniería de software, análisis de sistema, análisis de software, diseño, mantenimiento, clientes.

I.INTRODUCCIÓN

El desarrollo de software se ha convertido en una industria con crecimiento vertical en los últimos años, hoy por hoy uno de los hombres más ricos del mundo es el dueño de una casa de software, Microsoft. Hace un par de décadas se sostenía la teoría de que los países que poseían los mejores recursos naturales estaban destinados a ser los más ricos y poderosos del mundo, en México por ejemplo, se manejó la idea de que el petróleo era la puerta de entrada grande al mundo desarrollado. Indudablemente los recursos naturales tienen un papel importante en la economía de los países, sin embargo poco a poco se fue acuñando una nueva ideología que se sintetiza en lo siguiente: “El que posee la información y el conocimiento y hace mejor uso de él, es el que tiene el poder”; así la ingeniería de software que surgió de la ingeniería de sistemas y de hardware ha desarrollado una agrupación de métodos, herramientas y procedimientos con el fin de describir un modelo para su mejor desempeño, esta 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, las herramientas a utilizarse, los controles y entregas que se requieren.

II. MODELO LINEAL SECUENCIAL O CASCADA PURA (WATERFALL).

Es el paradigma más antiguo, también conocido como modelo clásico, modelo tradicional o modelo lineal secuencial, si sufre algún cambio durante la ejecución en alguna etapa en el modelo en cascada puro implicaría empezar desde 0 todo el ciclo de nuevo, lo cual implica altos costos de tiempo y desarrollo.El modelo consta de las siguientes etapas:

A. 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 del programa a construirse, el ingeniero de software debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento e interconexión. El cliente documenta y repasa los requisitos del sistema y del software.

B. Diseño.

El diseño del software es realmente 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.

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

Incidencias en los paradigmas de la ingeniería de software

Molina Sergio Manuel., Burgos Hernán AntonioSergiomontiel1@hotmail.com , heburg95@hotmail.com

Universidad De Córdoba

1

Universidad De Córdoba. Molina Sergio, Burgos Hernán. Paradigmas de la ing. de software.

D. 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, y en 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.

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

III. MODELOS EN FUNCIÓN DE PROTOTIPOS.

Cuando en la etapa de análisis se necesitan de técnicas amigables para la elaboración de la especificación de requisitos de software (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 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 (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.

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

2

Universidad De Córdoba. Molina Sergio, Burgos Hernán. Paradigmas de la ing. de software.

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). Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

A. 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 procesa?

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

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

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

E. Pruebas y 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 interfaces a fondo.

No todos los tipos de aplicaciones son apropiados para 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.

MODELOS DE PROCESO EVOLUTIVOS DEL SOFTWARE.

V. MODELO INCREMENTAL.

Definido por Meir Manny Lehman en 1984; constituye una de las variantes del modelo en cascada puro; el modelo incremental o de cascada con sus proyectos, corrige la necesidad de una secuencia no lineal de pasos de desarrollo. En el modelo Incremental se va creando el Software añadiendo componentes funcionales al sistema: incrementos. Los sistemas presentan algunas á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. 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.

VI. MODELO EN ESPIRAL.

Propuesto por Barry Boehm en 1988 con la finalidad de paliar los inconvenientes del modelo en cascad y adecuar el desarrollo por prototipos a problemas complejos. 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 mini-proyectos y donde cada mini-proyecto 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

3

Universidad De Córdoba. Molina Sergio, Burgos Hernán. Paradigmas de la ing. de software.

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

VII. MODELO DE ENSAMBLAJE DE COMPONENTES.

Las tecnologías de objetos proporcionan el marco de trabajo técnico para un modelo de proceso basado en componentes para la ingeniería del software. El paradigma de orientación a objetos enfatiza la creación de clases que encapsula tanto los datos como los algoritmos que se utilizan para manejar los datos. 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 computadora.

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. El modelo ensamblador de componentes lleva a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros del software.

VIII. MODELO DE DESARROLLO CONCURRENTE.

Definido por Davis Sitaram, el modelo de proceso concurrente se puede representar en forma de esquema como una serie de actividades técnicas importantes, tareas, y estados asociados a ellas. Por ejemplo, la actividad de ingeniería definida para el modelo en espiral, se lleva a cabo invocando las tareas siguientes: Modelado de construcción de prototipos y/o análisis, especificación de requisitos, y diseño.

El modelo de proceso concurrente define una serie de acontecimientos que disparan 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 dos dimensiones:Una dimensión de sistemas y una dimensión de componentes. Los aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño, ensamblaje y uso. La dimensión de componentes se afronta con dos:

4

Universidad De Córdoba. Molina Sergio, Burgos Hernán. Paradigmas de la ing. de software.

diseño y realización. La concurrencia se logra de dos formas:

1. Las actividades de sistemas y de componentes ocurren simultáneamente y pueden moderarse con el enfoque orientado a objetos descrito anteriormente.

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.

IX. MODELO DE MÉTODOS FORMALES.

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.

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.

Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran preocupación sobre su aplicabilidad en un entorno de gestión:

1. El desarrollo de modelos formales actualmente es bastante caro y lleva mucho tiempo.

2. Se requiere un estudio caro porque pocos responsables del desarrollo de software tiene los antecedentes necesarios para aplicar métodos formales

3. Es difícil utilizar los modelos como un mecanismo de comunicación con clientes que no tiene muchos conocimientos técnicos.

X. CONCLUSIONES

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.

REFERENCIAS

[1] Unidad de Informática UPIICSA http://www.sites.upiicsa.ipn.mx/polilibros/portal/Polilibros/P_proceso/ANALISIS_Y_DISEnO_DE_SISTEMAS/IngenieriaDeSoftware/CIS/UNIDAD%20I/1.5.htm[2] https://es. wikipedia .org/

[3] http://www.itlalaguna.edu.mx/

Autores

Sergio Molina, bachiller de la institución educativa Simón Bolívar y actualmente universitario de la carrera de ingeniería de sistemas en la universidad de Córdoba (Colombia). Hernán Burgos, bachiller del colegio José A. Galán del municipio de San Pelayo y actualmente universitario de la carrera de ingeniería de sistemas en la universidad de Córdoba (Colombia).

5