Paradigmas de la ingenieria de software

Modelo Lineal Secuencial o Cascada Pura (Waterfall)

Por supuesto Royce en 1970; es el paradigma ms antiguo y fue el ms utilizado
durante la hegemona del mtodo estructurado. El nmero de etapas propuestas
vara de acuerdo al proyecto a desarrollar, aunque existen etapas comunes para
este paradigma.
Anlisis de los requisitos del software. El proceso de reunin 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 informacin del software (descrito en el
Capitulo 1.1), as como la funcin requerida, comportamiento, rendimiento e
interconexin. El cliente documenta y repasa los requisitos del sistema y del
software.
Diseo. El diseo 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 diseo traduce requisitos en una representacin del software que se
pueda evaluar por calidad antes de que comience la generacin del cdigo. Al
igual que los requisitos, el diseo se documenta y se hace parte de la
configuracin del software.
Generacin de cdigo. El diseo se debe traducir en una forma legible por la
mquina. El paso de generacin de cdigo lleva a cabo esta tarea. Si lleva a cabo
el diseo de una forma detallada, la generacin de cdigo se realiza
mecnicamente.
Pruebas. Una vez que se ha generado un cdigo, comienzan las pruebas del
programa. El proceso de pruebas se centra en los procesos lgico internos del
software, asegurando que todas las sentencias se han comprobado, yen los
proceso externos funcionales, es decir, la realizacin de las pruebas para le
deteccin 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 despus de ser
entregado al cliente (una excepcin posible es el software empotrado). Se
producirn 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 perifrico 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 simultnea; 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 algn error en alguna etapa, lo ms probable ser abandonar todo lo
avanzado y regresar a la etapa primera de anlisis de requisitos del sistema; pues,
aunque la vuelta atrs por etapas es posible, sta demanda mucho esfuerzo y
puede terminar en el colapso.
Modelos en Funcin de Prototipos
Cuando en la etapa de anlisis se necesitan de tcnicas amigables para la
elaboracin del ERS, es recomendable el empleo de herramientas de
levantamiento de informacin como son los prototipos o modelos previos. Los
modelos previos pueden ser en papel o computadora para mostrar la interaccin
hombre-mquina; un modelo que muestra algunas funciones del software; o, algn
software anterior (parte o todo) parecido al que se desea, que luego ser
modificado y adaptado segn los requerimientos del usuario.
El paradigma de construccin de prototipos comienza con la recoleccin 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 ms definicin. Entonces aparece un << diseo rpido >>.
El diseo rpido se centra en una representacin de esos aspectos del software
que sern visibles para el usuario/cliente (p. Ej.: enfoques de entrada y formatos
de salida). El diseo rpido lleva a la construccin de un prototipo. El prototipo lo
evala el cliente/usuario y lo utiliza para refinar los requisitos del software a
desarrollar. La interaccin 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 sera 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 rpidamente programas de trabajo.

El paradigma de la elaboracin por prototipos resulta una alternativa para el

desarrollo rpido de aplicaciones de software; pues el analista acorta en tiempo
entre la determinacin de los requerimientos de informacin y la entrega de un
sistema funcional, adems que el usuario podr modificar y depurar sus
requerimientos conforme avance el desarrollo del proyecto.

Modelo de Desarrollo rpido de Aplicacin (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
adaptacin a << alta velocidad >> del modelo lineal secuencial en el que se logra
el desarrollo rpido utilizando un enfoque de construccin 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 das) [MAR9]. Cuando se utiliza principalmente para aplicaciones de sistemas
de informacin, el enfoque DRA comprende las siguientes fases:
Modelado de Gestin. El flujo de informacin entre las funciones de gestin se
modela de forma que responda a las siguientes preguntas: Qu informacin
conduce el proceso de gestin?, Qu informacin se genera?, Quin la
genera?, A dnde va la informacin?, Quin la procesa?.
Modelado de Datos. El flujo de informacin definido como parte de la fase de
modelado de gestin se refina como un conjunto de objetos de datos necesarios
para apoyar la empresa. Se definen las caractersticas (llamadas atributos) de
cada uno de los objetos y las relaciones entre estos objetos.
Modelado de Proceso. Los objetos de datos definidos en la fase de modelado de
datos quedan transformados para lograr el flujo de informacin necesario para
implementar una funcin de gestin. Las descripciones del proceso se crean para
aadir, modificar, suprimir o recuperar un objeto de datos.
Generacin de Aplicaciones. El DRA asume la utilizacin de tcnicas de cuarta
generacin. En lugar de crear software con lenguajes de programacin de tercera

generacin, 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 automticas
para facilitar la construccin del software.
Pruebas y Entrega. Como el proceso DRA enfatiza la reutilizacin, 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.
El modelo de proceso DRA se ilustra en la Figura 2.6. Obviamente las limitaciones
de tiempo impuestas en un proyecto DRA demandan <<mbito en escalas>>
[KER94]. Si una aplicacin de gestin puede modularse de forma que permita
completarse cada una de las funciones principales en menos de tres meses
(utilizando el enfoque descrito anteriormente), es un candidato del DRA. Cada una
de las funciones pueden ser afrontadas por un equipo DRA diferente y ser
integradas en un solo conjunto.

Modelos de Procesos Evolutivos de Software

Modelo Incremental

Definido por Lehman en 1984; constituye una de las variantes del modelo en
cascada puro; el modelo incremental o de cascada con subproyectos, corrige la
necesidad de una secuencia no lineal de pasos de desarrollo.
El modelo Incremental se va creando el Software aadiendo componentes
funcionales al sistema: incrementos.
Los sistemas presentan alguna reas que incluyen sorpresas al momento de
definir o desarrollar el producto, pero tambin presentan otras reas que hemos
implementado varias veces y no incluyen sorpresas, entonces, por qu retrasar la
implementacin de estas reas que son fciles de modelar solamente porque
estamos considerando que en el proyecto existen algunas reas difciles.
Cuando se utiliza un modelo incremental, el primer incremento a menudo es un
producto esencial (ncleo). Es decir, se afrontan requisitos bsicos, pero muchas
funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El
cliente utiliza el producto central (o sufre la revisin detallada). Como un resultado
de utilizacin y/o de evaluacin, se desarrolla un plan para el incremento siguiente.
Este proceso se repite siguiendo la entrega de cada incremento, hasta que se
elabore el producto completo. En este paradigma el software se ve como una
integracin de resultados sucesivos obtenidos despus de cada interaccin. Este
modelo se adecua a entornos de alta incertidumbre.
Modelo en Espiral
Propuesto por 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 construccin por
prototipos, agregando una etapa de "anlisis 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 ms riesgos
importantes hasta que todos estos estn controlados. Este modelo se realiza en
varias iteraciones; se parte de una escala pequea la cual comienza con la
identificacin de objetivos, alternativas y restricciones; en medio de la espiral, se
localizan riesgos, se genera un plan para manejarlos, y a continuacin se
establece una aproximacin a la siguiente iteracin.
Se proporciona el potencial para el desarrollo rpido de versiones incremntales
del software. En el modelo espiral, el software se desarrolla en una serie de
versiones incremntales. Durante las primeras iteraciones, la versin incrementar
podra ser un modelo en papel prototipo. Durante las ltimas iteraciones, se
producen versiones cada vez ms completas de ingeniera del sistema. El modelo

en espiral se divide en un nmero de actividades estructurales tambin llamadas

guiones de tareas. Estas inclusive pueden variar de 3 a 6 tareas.
Cuando empieza este proceso evolutivo, el equipo de ingeniera del software gira
alrededor de la espiral en la direccin de las agujas del reloj, comenzando por el
centro. El primer circuito de la espiral produce el desarrollo de una especificacin
de productos; los pasos siguientes en la espiral se podran utilizar para desarrollar
un prototipo y progresivamente versiones ms sofisticadas del software. Cada
paso de la regin de planificacin produce ajustes en el plan del proyecto. El costo
y la planificacin se ajustan segn la reaccin ante la evaluacin del cliente.
Adems, el gestor del proyecto ajusta el nmero planificado de iteraciones
requeridas para completar el software.
En esencia, la espiral, cuando se caracteriza de esta forma, permanece operativo
hasta que el software de 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 construccin de prototipos como
mecanismos de reduccin de riesgos, pero lo que es ms importante, permite a
quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier
etapa de evolucin del producto. Mantiene el enfoque sistemtico de los pasos
sugeridos por el ciclo de vida clsico, pero lo incorpora al marco de trabajo
interactivo que refleja de forma ms realista el mundo real. El modelo en espiral
demanda una consideracin directa de los riesgos tcnicos en todas las etapas del
proyecto, y si se aplica adecuadamente, debe reducir los riesgos antes de que se
conviertan en problemticos.
Modelo de Ensamblaje de Componentes
Las tecnologas de objetos proporcionan el marco de trabajo tcnico para un
modelo de proceso basado en componentes para la ingeniera del software. El
paradigma de orientacin a objetos enfatiza la creacin de clases que encapsula
tanto los datos como los algoritmos que se utilizan para manejar los datos. Si se
disean 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 ingeniera comienza con la identificacin de clases candidatas. Esto

se lleva a cabo examinando los datos que se van a manejar por parte de la
aplicacin 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 de ensamblaje de componentes incorpora muchas de las caractersticas
del modelo en espiral. Es evolutivo por naturaleza [NIE92], y exige un enfoque
interactivo para la creacin del software. Sin embargo, el modelo ensamblador de
componentes configura aplicaciones desde componentes preparados de software
(algunas veces llamados << clases >>).

El modelo ensamblador de componentes lleva a la reutilizacin del software, y la

reutilizacin proporciona beneficios a los ingenieros del software.
Modelo de Desarrollo Concurrente
Definido por Davis y Sitaram [DAV94], el modelo de proceso concurrente se puede
representar en forma de esquema como una serie de actividades tcnicas
importantes, tareas, y estados asociados a ellas. Por ejemplo, la actividad de
ingeniera definida para el modelo en espiral, se lleva a cabo invocando las tareas
siguientes: modelado de construccin de prototipos y/o anlisis, especificacin de
requisitos, y diseo.
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
ingeniera 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
[SHE94]: una dimensin de sistemas y una dimensin de componentes. Los
aspectos del nivel de sistemas se afrontan mediante tres actividades: diseo,
ensamblaje y uso. La dimensin de componentes se afronta con dos: diseo y
realizacin. La concurrencia se logra de dos formas:
Las actividades de sistemas y de componentes ocurren simultneamente y
pueden moderarse con el enfoque orientado a objetos descrito anteriormente.
Una aplicacin cliente/servidor tpica se implementa con muchos componentes,
cada uno de los cuales se pueden disear y realizar concurrentemente.

En realidad, el modelo de proceso concurrente es aplicable a todo tipo de

desarrollo de software y proporciona una imagen exacta del estado actual de un
proyecto. En vez de confinar las actividades de ingeniera del software a una
secuencia de sucesos, define una red de actividades. Todas las actividades de la
red existen simultneamente con otras. Los sucesos generados dentro de una
actividad dada o en algn otro lugar en la red de actividad inicia la s transiciones
entre los estados de una actividad.
Modelo de Mtodos Formales
El modelo de mtodos formales acompaa a un conjunto de actividades que
conducen a la especificacin matemtica del software de computadora. Los
mtodos formales permiten que un ingeniero del software especifique, desarrolle y
verifique un sistema basado en computadora aplicando una notacin rigurosa y
matemtica.
La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen ms
fcilmente, no mediante una revisin a propsito para el caso, sino mediante la
aplicacin del anlisis matemtico. Cuando se utilizan mtodos formales durante
el diseo, sirven como base para la verificacin de programas y por consiguiente
permiten que el ingeniero del software descubra y corrija errores que no se
pudieron detectar de otra manera.
Aunque todava no hay un enfoque establecido, los modelos de mtodos formales
ofrecen la promesa de un software libre de defectos. Sin embargo, se ha hablado
de una gran preocupacin sobre su aplicabilidad en un entorno de gestin:
El desarrollo de modelos formales actualmente es bastante caro y lleva mucho
tiempo.
Se requiere un estudio caro porque pocos responsables del desarrollo de software
tiene los antecedentes necesarios para aplicar mtodos formales.
Es difcil utilizar los modelos como un mecanismo de comunicacin con clientes
que no tiene muchos conocimientos tcnicos.
No obstante, es posible que el enfoque a travs de mtodos formales tenga ms
partidarios entre los desarrolladores del software que deben construir software de
mucha seguridad (p. Ej.: los desarrolladores de avinica y dispositivos mdicos), y
entre los desarrolladores que pasan grandes penurias econmicas al aparecer
errores de software.
Tcnicas de Cuarta Generacin

Abarca un amplio espectro de herramientas de software que tienen algo en

comn: todas facilitan al ingeniero del software, la especificacin de lagunas
caractersticas del software de alto nivel. Luego, la herramienta genera
automticamente el cdigo fuente basndose en la especificacin del tcnico.
Cada vez parece ms evidente que en cuanto mayor sea el nivel en el que se
especifique el software, ms rpido se podr construir el programa. El paradigma
T4G para la ingeniera del software usando formas de lenguaje especializado o
notaciones graficas que describan el problema que hay que resolver en trminos
que los entienda el cliente.
Al igual que otros paradigmas, T4G comienza con el paso de reunin de
requisitos. Idealmente, el cliente describe los requisitos, que son, a continuacin,
traducidos directamente a un prototipo operativo. Estado actual de los enfoques de
T4G:
El uso de T4G ha crecido considerablemente en la ltima dcada y ahora es un
enfoque viable para muchas de las diferentes reas de aplicacin. Junto con las
herramientas de ingeniera de software asistida por computadora (CASE) y los
generadores de cdigo, T4G ofrece una solucin fiable a muchos problemas de
software.

Los datos recogidos en compaas que usan T4G parecen indicar que el tiempo
requerido para producir software se reduce mucho para aplicaciones pequeas y
de tamao medio, y que la cantidad de anlisis y diseo para las aplicaciones
pequeas, tambin se reduce.
Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige
el mismo o ms tiempo de anlisis, diseo y prueba (actividades de ingeniera del
software), perdindose as un tiempo sustancial que se ahorra mediante la
eliminacin de la codificacin.
Tecnologa de Procesos
Las herramientas de tecnologa de procesos permiten que una organizacin de
software construya un modelo automatizado de la estructura comn del proceso,
conjunto de tareas, y actividades de proteccin.
El modelo, presentado normalmente como una red, se puede analizar para
determinar el flujo de trabajo tpico y para examinar estructuras alternativas de
procesos que pudieran llevar a un tiempo o costo de desarrollo reducidos. Una vez
que se ha creado un proceso aceptable, se pueden utilizar otras herramientas de
tecnologa de procesos para asignar, supervisar, e incluso controlar todas las

tareas de ingeniera del software definidas como parte del modelo de proceso.
Cada uno de los miembros de un equipo de proyecto de software pueden utilizar
tales herramientas para desarrollar una lista de control de tareas de trabajo a
realizarse productos de trabajo a producirse, y actividades de garanta de calidad
a conducirse.
ERP
Los sistemas de planificacin de recursos empresariales (ERP, por sus siglas en
ingls, enterprise resource planning) son sistemas de informacin gerenciales que
integran y manejan muchos de los negocios asociados con las operaciones de
produccin y de los aspectos de distribucin de una compaa en la produccin de
bienes o servicios.
La planificacin de recursos empresariales es un trmino derivado de la
planificacin de recursos de manufactura (MRPII) y seguido de la planificacin de
requerimientos de material (MRP); sin embargo los ERP han evolucionado hacia
modelos de suscripcin por el uso del servicio (SaaS, cloud computing).
Los sistemas ERP tpicamente manejan la produccin, logstica, distribucin,
inventario, envos, facturas y contabilidad de la compaa de forma modular. Sin
embargo, la planificacin de recursos empresariales o el software ERP puede
intervenir en el control de muchas actividades de negocios como ventas, entregas,
pagos, produccin, administracin de inventarios, calidad de administracin y la
administracin de recursos humanos.
Los sistemas ERP son llamados ocasionalmente back office (trastienda) ya que
indican que el cliente y el pblico general no estn directamente involucrados.
Este sistema es, en contraste con el sistema de apertura de datos (front office),
que crea una relacin administrativa del consumidor o servicio al consumidor
(CRM), un sistema que trata directamente con los clientes, o con los sistemas de
negocios electrnicos tales como comercio electrnico, administracin electrnica,
telecomunicaciones electrnicas y finanzas electrnicas; asimismo, es un sistema
que trata directamente con los proveedores, no estableciendo nicamente una
relacin administrativa con ellos (SRM).
CRM
CRM proviene de la sigla del trmino en ingls customer relationship
management, y puede poseer varios significados:1
Administracin basada en la relacin con los clientes. CRM es un modelo de
gestin de toda la organizacin, basada en la satisfaccin del cliente (u orientacin
al mercado segn otros autores). El concepto ms cercano es marketing relacional

(segn se usa en Espaa) y tiene mucha relacin con otros conceptos como:
clienting, marketing 1x1, marketing directo de base de datos, etc.
Software para la administracin de la relacin con los clientes. Sistemas
informticos de apoyo a la gestin de las relaciones con los clientes, a la venta y al
marketing. Dicho software puede comprender varias funcionalidades para
gestionar las ventas y los clientes de la empresa: automatizacin y promocin de
ventas, tecnologas data warehouse (almacn de datos) para agregar la
informacin transaccional y proporcionar capa de reporting, dashboards e
indicadores claves de negocio, funcionalidades para seguimiento de campaas de
marketing y gestin de oportunidades de negocio, capacidades predictivas y de
proyeccin de ventas
SCM
Gestin de Configuracin de Software (Software Configuration Management,
SCM) es una especializacin de la gestin de configuracin a todas las
actividades en el sector del desarrollo de software.
SCM trata y controla:
-la elaboracin de cdigo fuente por varios desarrolladores simultneamente;
-el seguimiento del estado de las fases del desarrollo de software (versiones) y
sus cambios (control de versiones) y
-la conduccin de la integracin de las partes del software en un solo producto de
software.
Para la realizacin de la SCM hay diferentes herramientas. Pero herramientas que
pretenden ofrecer una solucin total al problema, a menudo no cumplen con los
requisitos tcnicos como:
-apoyo a diferentes plataformas.
-iniciar el proceso de build.
-conexin a los bancos de datos existentes.
-integracin a la organizacin existente.
Por esa razn ofrece una mayor flexibilidad una solucin que integre herramientas
parciales que sean ms fciles de integrar en el proceso existente.
Por ejemplo:

Uso de un software de administracin de versiones como IBM Rational Team

Concert, CVS, Subversion, SourceSafe, ClearCase, Darcs, Plastic SCM.
Introduccin de una herramienta para la documentacin comunitaria con una
administracin de cambios, acceso interactivo y foro o alguna plataforma para la
comunicacin.
Determinar un entorno para el build automtico.