Insidencias En Los Paradigmas De La Ingeniera De Software

Universidad De Córdoba. Molina Sergio, Burgos Hernán. Paradigmas de la ing. de software.
1
Incidencias en los paradigmas de la ingeniería de
software
Molina Sergio Manuel., Burgos Hernán Antonio
Sergiomontiel1@hotmail.com , heburg95@hotmail.com
Universidad De Córdoba

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.

2
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

3
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

4
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:
diseño y realización. La concurrencia se logra de dos
formas:

5
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/Polilibr
os/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).

Insidencias En Los Paradigmas De La Ingeniera De Software

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Insidencias En Los Paradigmas De La Ingeniera De Software

Último

Insidencias En Los Paradigmas De La Ingeniera De Software