INVESTIGACION:

2.3. Modelos de la ingeniera del software:

model de cascada, modelo de prototipos,
modelo de espiral, modelo de Proceso Unificado
Racional (RUP).
UNIDAD ll

Hernndez Najera Carlos Enrique

Escobar Barrera Juan de Mata
ING. EN TECNOLOGIAS DE LA INFORMACION Y
COMUNICACION

Unidad 2: Modelos de Ingeniera del software

2.3. Modelos de la ingeniera del software: model de cascada, modelo de
prototipos, modelo de espiral, modelo de Proceso Unificado Racional (RUP).
1.- Modelo cascada:
Es un modelo sencillo para explicar al cliente.
Tambin llamado ciclo de vida clsico sugiere un enfoque sistemtico. Secuencial en el
desarrollo del software.
Requiere que los requerimientos estn bien definidos y estables en forma razonable.
Es el paradigma ms antiguo para la Ingeniera del Software.
Fases:
Ingeniera y Anlisis del Sistema:
Debido a que el software siempre es
parte de un sistema mayor el trabajo
comienza
estableciendo
los
requerimientos
de
todos
los
elementos del sistema y luego
asignando algn subconjunto de
estos requisitos al software.
Anlisis de los requerimientos del
software: El proceso de recopilacin
de los requerimientos se centra e
intensifica especialmente en el
software. El ingeniero del software
debe comprender el mbito de la informacin del software as como la funcin del
rendimiento
y
las
interfaces
requeridas.
.
Diseo: Se enfoca en cuatro atributos distintos del programa la estructura de los datos,
la arquitectura del software, el detalle procedimental y la caracterizacin de la interfaz.
Codificacin: Debe traducirse en una forma legible para la mquina.
Prueba: Se centra en la lgica interna del software y en las funciones externas,
realizando pruebas que aseguren que la entrada definida produce los resultados que
realmente se requiere.
Mantenimiento: El software sufrira cambios despus de que se entrega al cliente
ocurren debido a que hayan encontrado errores que el software deba adaptarse a
cambios del entorno externo o que el cliente requiera aplicaciones funcionales o del
rendimiento.
Caractersticas:

Es el ms utilizado.

Es una visin del proceso de desarrollo de software como una sucesin de etapas
que producen productos intermedios.
Para que el proyecto tenga xito deben desarrollarse todas las fases.
Las fases continan hasta que los objetivos se han cumplido.
Si se cambia el orden de las fases, el producto final ser de inferior calidad.

Ventajas:

La planificacin es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco calificado.

Desventajas:

No refleja realmente el proceso de desarrollo del software.

Se tarda mucho tiempo en pasar por todo el ciclo.
El mantenimiento se realiza en el cdigo fuente.
Las revisiones de proyectos de gran complejidad son muy difciles.

2.- Modelo de prototipos:

Es una visin preliminar del modelo futuro.
Es un modelo operable.
Fcilmente ampliable y modificable.
Tiene todas las caractersticas propuestas pero realmente es un modelo bsico que tiene
que ser mejorado

Ventajas:
La posibilidad de cambiar el modelo.
La oportunidad para suspender el modelo del desarrollo del modelo sino es funcional.
La oportunidad de crear un nuevo modelo que se ajuste a mejor a las necesidades y
expectativas de los usuarios.
Relaciones de usuario:
Las sugerencias obtenidas de los usuarios lleven al analista hacia adecuaciones o
cambios que se ajustan mejor a las necesidades de los usuarios y que no haban sido
pensadas antes de la interaccin del usuario con el prototipo. Debe ser construido en
poco tiempo, no debe de utilizarse mucho dinero, cuando este sea aprobado podemos
iniciar el verdadero desarrollo del software. Podr ser construido si con el software es
posible experimentar.
Desventajas:
Debido a que el usuario ve que funciona piensa que este es el producto terminado y no
entienden que recin se va a desarrollar el software. Debe ir acompaado de otro modelo
para
su
desarrollo.
Tipo de modelo de prototipo:

Desechable. Nos sirve para eliminar dudas sobre las que realmente quiere al cliente
adems para desarrollar la interfaz que ms le convenga al cliente.
Evolucionario: Es parcialmente construido que puede pasar de ser prototipo a ser
software pero no tiene una buena documentacin y calidad.
A favor:

tiles cuando los requerimientos son cambiantes.

Cuando no se conoce bien la aplicacin.
Cuando el usuario no se quiere comprometer con los requerimientos.
Cuando se quiere probar una arquitectura o tecnologa. Cuando se requiere
rapidez en el desarrollo.

En contra:
No
se
conoce
cuando
se
tendr
un
producto
No
se
sabe
cuntas
interacciones
sern
Da una falsa ilusin al usuario sobre la velocidad del
Se puede volver al producto aun y cuando no est en los estndares.

aceptable.
necesarias.
desarrollo.

Modelo en espiral:
Las actividades se conforman en un espiral en la que cada bucle o interaccin representa
un conjunto de actividades, no estn fijadas a prioridad sino que las siguientes se eligen
en funcin de anlisis de riesgo comenzando por el bucle interior.
Caractersticas:
Encada giro se construye un nuevo modelo del sistema completo.
Este modelo puede combinarse con otros modelos de proceso de desarrollo.
Mejo
ir
modelo
para
desarrollo
de
grandes
sistemas.
El anlisis de riesgo requiere la participacin del personal con alta calificacin.
No hay nmero definido de interacciones, deben de decidirlas el equipo de gestin de
proyecto.
Ventajas:
Modelo espiral de cuatro regiones o modelo original de Boehm.
Modelo espiral de seis regiones.
Modelo espiral WINWIN.
3.- Modelo espiral WINWIN:
WINWIN (Victoria) sugiere una actividad del marco de trabajo que aborda la comunicacin
con el cliente. El objetivo de esta actividad es mostrar los requisitos del cliente. En un
contexto ideal del desarrollador simplemente pregunta al cliente lo que se necesita y
proporciona detalles suficientes para continuar.
Ventajas:

El modelo en espiral es un enfoque realista del desarrollo de sistemas.

Modelo de proceso adaptable.
El modelo en espiral puede s aplicarse a lo largo de la vida del software.
El desarrollador y el cliente comprenden y reaccionan mejor ante riegos en cada uno de
los niveles evolutivos.
Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en
cualquier etapa de evolucin del producto.
Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del
proyecto y si se aplicada adecuadamente debe reducir los riesgos antes de que se
conviertan en problemas.
Modelos evolutivos como el espiral son apropiados particularmente para el desarrollo de
Sistemas OO.
Trata de mejorar los ciclos de vida de clsicos y prototipos.
Permite acomodar otros modelos.
Incorpora objetivos de calidad y gestin de riesgos.
Elimina errores y alternativas no atractivas al comienzo.
Desventajas:
Resulta difcil convencer a grandes clientes de que el enfoque evolutivo es controlable.
Es nuevo y no se ha utilizado tanto como otro modelo de ciclo de vida.
Requiere una considerable habilidad para la evaluacin del riesgo y cuenta con esta
habilidad para el xito.
Si un riesgo es importante no es detectado y gestionado a tiempo indudablemente
surgirn problemas.
Hitos del modelo WIN-WIN:
Introduce tres hitos son los procesos llamados puntos de fijacin que ayudan a establecer
la completitud de un ciclo alrededor de la espiral y proporcionan hitos de decisin antes de
continuar el proyecto de software.
Los puntos de fijacin representan tres visiones diferentes del progreso mientras que el
proyecto recorre la espiral.
Modelos ms destacados del proceso de la produccin de software (ciclos de vida).
1.- Codifica y corrige (code-and-fix).

Proceso:
o

Codifica un poco.

Prueba y elimina los errores.

Repite el proceso.

Ventaja: efectivo para productos pequeos.

Desventaja: diseo "spaghetti", no manejable para sistemas grandes.

Caracterstica: basado en la inspiracin personal.

2.- Modelo Codifica y corrige. (Transparencia A2)

El ciclo de vida o proceso de desarrollo de software ms antiguo y utilizado hasta la fecha,

sobre todo por la gente que empieza a aprender la programacin, es el llamado "codeand-fix", cuya traduccin correcta al espaol sera "codifica y corrige". En este proceso los
pasos ha seguir por los desarrolladores son:

Codifica un poco, luego

Prueba y elimina los errores, es decir, realiza, si es necesario, la correccin y

Repite el proceso hasta que se obtenga la solucin buscada.

El ciclo de vida es efectivo para productos o sistemas pequeos, principalmente cuando

se trata de desarrollos unipersonales. En contraste, el diseo final puede ser de estilo
"spaghetti", es decir, que al ir pegando poco a poco diferentes partes de cdigo, es
posible obtener un producto, que aunque funcione, no sea muy coherente, y no cuente,
desde el punto de vista del diseo, con una arquitectura legible y razonable.
Otra desventaja es que este tipo de arquitectura no es adecuado para sistemas medianos
y grandes. Su caracterstica principal es que depende de la inspiracin personal, del
herosmo, de la experiencia, del conocimiento y de las habilidades del desarrollador.

3.- Modelo Evolutivo.

A partir de este modelo, encontramos los ms recientes originados del de cascada, que
actualmente estn impactando y adaptndose cada vez ms a la orientacin a objetos.
El modelo Evolutivo conocido tambin como incremental e iterativo, consiste en hacer la
documentacin de las fases, realizando un prototipo del sistema, se evala el qu tan
lejos el prototipo est de la solucin final esperada por el cliente; se toman en cuenta las
observaciones de esta evaluacin, y se crea un nuevo prototipo que las incluya. Esto se
realiza en una vuelta repetitiva donde se incrementa el alcance del prototipo en pequeas
proporciones hasta cumplir los requerimientos totales.
En este mtodo no es necesario esperar hasta que toda una fase est terminada para
iniciar la siguiente. Si se cuenta con una parte del anlisis bien entendida, se puede
realizar un primer diseo del corazn o de una parte medular del sistema, hacer su
codificacin y con esto, formar nuestro primer prototipo que ampliaremos en las siguientes

iteraciones (vueltas), creando prototipos cada vez mejores y amplios con respecto a los
requerimientos originales.
La ventaja es que es ideal para sistemas que no tiene bien definidos los requerimientos,
es decir, para la mayora de los sistemas que se desarrollan. El cliente desde el principio
tiene una idea de los requerimientos de su sistema, pero no estn claros hasta el ltimo
detalle. Aun as podemos basarnos en lo ya entendido (cliente y desarrollador), trabajar
con esta informacin, y mientras se vayan creando prototipos, el cliente detallar sus
especificaciones.

Su desventaja es que es difcil distinguirlo del proceso "codifica y corrige", pues en cierta
medida son parecidos, la diferencia est que en la prctica se requiere que al construir el
prototipo se aplique el anlisis y el diseo pero slo a una parte de los requerimientos ya
entendidos, que se documente y se codifique, logrndose con todo esto, un poco de
disciplina heredada del modelo en cascada, de esta manera, la desventaja no lo es tanto.
La caracterstica de este modelo es que est enfocado a la produccin de prototipos.
4.- Evolutivo (evolutionary).

Proceso:
o

Haz un prototipo.

Mide qu tan lejos est de lo esperado.

Toma en cuenta las observaciones para generar el siguiente prototipo.

Es un proceso repetitivo y creciente.

Ventaja: ideal para sistemas que no tienen bien definidos los requerimientos.
Desventaja: es difcil de distinguirlo del proceso "codifica y corrige".
Caracterstica: enfocado a la produccin de prototipos.

4.- Modelo Espiral.

La misma idea de prototipos la encontramos en este modelo, (se sugiere revisar las notas
de la clase de Ingeniera de Software para mayores detalles). En la propuesta de Boehm,
la espiral representa muy bien la idea del desarrollo iterativo e incremental, as como la
del desarrollo por prototipos, en donde estos al principio abarcan una pequea parte del
sistema, (la evaluacin de riesgos) y empiezan en el centro de la espiral.
Es un modelo evolutivo pero en cada vuelta, antes de generar un nuevo prototipo, se
evala el riesgo que se corre si continuramos con la siguiente iteracin, es decir, si an
por parte del cliente y de nosotros existe tiempo, recursos y decisin para seguir

mejorando este proceso de desarrollo o por el contrario, si encontramos que los riesgos
son demasiado grandes, pues entonces tomar las decisiones adecuadas como la
suspensin del proyecto o la solicitud de ms recursos. La idea es que antes de generar
un prototipo, evaluemos la factibilidad y analicemos los riesgos. Si el resultado es positivo,
entonces generamos el primer prototipo (el cual abarca slo una parte del sistema),
continuamos con las fases siguientes (simulacin, comparacin, validacin de
requerimientos) hasta que deje de ser prototipo y se convierta en el sistema completo,
cuya puesta en operacin, ya integrada y aceptada por el cliente, constituye la salida del
proceso. Este modelo es iterativo pues repite los pasos incrementndolos cada vez al ir
robusteciendo el prototipo en su funcionalidad.

5.- Modelo Transformador. (Transparencia A.6)

Este modelo actualmente no es ni bsico ni popular en la modelacin orientada a objetos,

pero s es el sueo dorado de los desarrolladores, puesto que propone la posibilidad de
construir cdigo a partir de las especificaciones dadas. Esto constituye la base para las
herramientas CASE, donde, utilizando un lenguaje abstracto o grfico para describir las
especificaciones de manera ms agradable, la herramienta automatizada se encarga de
realizar el cdigo. En el modelo transformador, se realiza la especificacin formal del
sistema y la herramienta convierte automticamente esta especificacin en el cdigo.
Rational Rose pude ser un ejemplo de este modelo porque de una especificacin con
UML puede generar cdigo en Java, C++ o VisualBasic. En realidad slo genera
esqueletos, especificaciones de clases y encabezados de mtodos pero no sus cdigos.
Existen otras propuestas de lenguajes de especificacin formal como Z, que permiten
especificar sistemas matemticamente con mayor precisin y generar el cdigo. Como
actualmente estos mtodos son poco eficientes y populares, creemos que el proceso de
desarrollo de software va encaminado a crear lenguajes de especificacin ms
expresivos.
La desventaja es que es bueno para productores relativamente pequeos de reas
limitadas. Las hojas de clculo y lenguajes de cuarta generacin (4GL) desarrollados en
la prctica para el uso de bases de datos- son ejemplos de lenguajes de especificaciones
ms abstractas que permite generar el cdigo, pero hasta la fecha, estos lenguajes estn
restringidos a ciertas aplicaciones (como los constructores de la familia Visual) y an no
existen para propsito general.
La caracterstica de este modelo es que se trabaja en el nivel de especificacin y no se
llega al nivel del lenguaje de programacin.
Proceso:
o

Haz la especificacin formal.

Convirtela automticamente en cdigo.

Ventaja: las modificaciones se hacen en el nivel de especificacin y no a nivel del cdigo,

ahorra tiempo de diseo, codificacin y pruebas.
Desventaja: bueno para productores relativamente pequeos de reas limitadas (hojas
de clculo, 4GLs).
Caracterstica: trabajo en el nivel de especificacin.

MODELO ITERATIVO INCREMENTAL

El modelo incremental combina elementos del modelo cascada (aplicado repetidamente)
as como la filosofa iterativa del prototipado. La parte inicial es el ncleo del producto (es
la parte mas importante).Una nueva versin del producto surge cuando nuevas
caractersticas han sido implementadas a medida que han sido sugeridas por el usuario.
La Descripcin del Sistema es esencial para especificar y confeccionar los distintos
incrementos hasta llegar al Producto global y final. Las actividades concurrentes
(Especificacin, Desarrollo y Validacin) sintetizan el desarrollo pormenorizado de los
incrementos.
Diagrama genrico del desarrollo evolutivo incremental
El modelo iterativo incremental es slo esquemtica, un incremento no necesariamente se
iniciar durante la fase de diseo del anterior, puede ser posterior (incluso antes), en
cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de
Operacin y Mantenimiento (indicada "Operacin" en la figura), que es donde se
produce la entrega del producto parcial al cliente. El momento de inicio de cada
incremento es dependiente de varios factores: tipo de sistema; independencia o 17

Dependencia entre incrementos (dos de ellos totalmente independientes pueden ser

fcilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y
cantidad de profesionales involucrados en el desarrollo; etc.
Como se muestra en la anterior imagen, se aplican secuencias Cascada en forma
escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada
produce un incremento y a menudo el primer incremento es un sistema bsico, con
muchas funciones suplementarias (conocidas o no) sin entregar.
El cliente utiliza inicialmente ese sistema bsico intertanto, el resultado de su uso y
evaluacin puede aportar al plan para el desarrollo del/los siguientes incrementos (o
versiones). Adems tambin aportan a ese plan otros factores, como lo es la priorizacin
(mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre
incrementos (o independencia).
Luego de cada integracin se entrega un producto con mayor funcionalidad que el previo.
El proceso se repite hasta alcanzar el software final completo.
Siendo iterativo, con el modelo incremental se entrega un producto parcial pero
completamente operacional en cada incremento, y no una parte que sea usada para
reajustar los requerimientos (como si ocurre en el modelo de construccin de prototipos).
La principal caracterstica de estos modelos es que permite crear cada vez
versiones ms completas de software, para esto construimos versiones
sucesivas de un producto. Se crea una primera versin que es utilizada por el
usuario donde se provee retroalimentacin al desarrollador, y segn los
requerimientos especificados de ste usuario se crea una segunda versin.