PARADIGMAS DE DESARROLLO DE SOFTWARE

1. Ciclos de vida Clsico (cascada)

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el
software a partir de ciclos de vida de otras ramas de la ingeniera. Es el primero
de los propuestos y el ms ampliamente seguido por las organizaciones (se
estima que el 90% de los sistemas han sido desarrollados as). Ordena
rigurosamente las etapas del ciclo de vida del software.
Para pasar de una fase a otra es necesario conseguir todos los objetivos de la
etapa previa.
1.1

Representacin grfica

Despus de cada etapa se realiza una revisin para comprobar si se puede pasar
a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un
tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo
diferente gracias a la documentacin generada entre las fases. Las fases son:
Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que
quiere el cliente. Produce el S.R.D. (Software Requirements Document
Documento de Requisitos del software).
o Anlisis de Requisitos del Sistema.
o Anlisis de Requisitos del Software.
Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design
Document Documento de Plan del software)
o Diseo Preliminar.
o Diseo Detallado.

1.2

Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen

tambin pruebas de unidad.
Pruebas: A partir de los mdulos probados se realiza la integracin y
pruebas de todo el sistema. El resultado de las pruebas es el producto final
listo para entregar.
Mantenimiento: Se realizan constantemente al detectarse alguna falla en
el sistema o para mejorarlo incluyendo algn nuevo modulo al mismo.
Ventajas
La planificacin es sencilla.
La calidad del producto resultante es alta.
Permite trabajar con personal poco calificado.
Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes
esperados.
Es mejor que no seguir ningn ciclo de vida.

1.3 Desventajas
Es difcil obtener todos los requisitos al comienzo. Lo normal es que el
cliente no tenga perfectamente definidas las especificaciones del sistema, o
puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difcil volver atrs. Al cambiar
alguna de las etapas se debe revisar todas las etapas subsiguientes.
Es comparativamente ms lento que los dems y el coste es mayor
tambin.
Se tarda mucho en disponer del software.
No se tiene el producto hasta el final, esto quiere decir que:
o Si se comete un error en la fase de anlisis no lo descubrimos hasta
la entrega, con el consiguiente gasto intil de recursos.
o El cliente no ver resultados hasta el final, con lo que puede
impacientarse.
No se tienen indicadores fiables del progreso del trabajo (sndrome del
90%).
El mantenimiento se realiza en el cdigo fuente
Impone una estructura de gestin de proyectos
1.4 Aplicaciones
Aquellos para los que se dispone de todas las especificaciones desde el
principio, por ejemplo, los de reingeniera.
Se est desarrollando un tipo de producto que no es novedoso.
Proyectos complejos que se entienden bien desde el principio.

2. Tcnicas de 4ta generacin

Facilitan al ingeniero del software la especificacin de algunas
caractersticas del software a alto nivel. Luego, la herramienta genera
automticamente el cdigo fuente basndose en la especificacin del tcnico.

Cada vez parece ms evidente que 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 se orienta hacia la posibilidad
de especificar el software usando formas de lenguaje especializado o notaciones
grficas que describa el problema que hay que resolver en trminos que los
entienda el cliente.
Actualmente, un entorno para el desarrollo de software que soporte el paradigma
T4G puede incluir todas o algunas de las siguientes herramientas:
Lenguajes no procedimentales de consulta a bases de datos,
Generacin de informes,
Manejo de datos,
Interaccin y definicin de pantallas,
Generacin de cdigos,
Capacidades grficas de alto nivel,
Capacidades de hoja de clculo,
Generacin automatizada de HTML y lenguajes similares utilizados para la
creacin de sitios web usando herramientas de software avanzado.
Al igual que otros paradigmas, T4G comienza con el paso de reunin de
requisitos. Por esta razn, el dilogo cliente-desarrollador descrito por los otros
paradigmas sigue siendo una parte esencial del enfoque T4G.
Las tcnicas de cuarta generacin ya se han convertido en una parte importante
del desarrollo de software. Cuando se combinan con enfoques de
ensamblaje de componentes el paradigma T4G se puede convertir en el
enfoque dominante hacia el desarrollo del software.
2.1 Desventajas.
Las T4G estn limitadas a las aplicaciones de sistema de informacin
comercial, y de la obtencin de informes en las grandes bases de datos.
Las herramientas actuales de T4G no son ms fciles de utilizar que los lenguajes
de programacin.
El cdigo fuente producido por tales herramientas es ineficiente y el
mantenimiento de grandes sistemas de software desarrollados mediante T4G, es
cuestionable
2.2 Diseo Grafico

3. Prototipo
Un cliente, a menudo, define un conjunto de objetivos generales para el
software, pero no identifica los requisitos detallados de entrada, proceso o salida.

En otros casos, el responsable del desarrollo del software puede no estar seguro
de la eficacia de un algoritmo, de la capacidad de adaptacin de un sistema
operativo, o de la forma en que debera tomarse la interaccin hombre mquina.
En este caso el paradigma de construccin de prototipos puede ofrecer el mejor
enfoque.
Escuchar al Cliente: 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.

Construir/Revisar la maqueta: 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 (por ejemplo: enfoques
de entrada y formatos de salida). El diseo rpido lleva a la construccin de
un prototipo.

El Cliente Prueba la maqueta: El prototipo lo evala el cliente/usuario y

se utiliza para refinar los requisitos del software a desarrollar. La iteracin
ocurre cuando el prototipo se pone a punto para satisfacer las necesidades
del cliente, permitiendo al mismo tiempo que el desarrollador comprenda
mejor lo que se necesita hacer.

3.1 Representacin grfica

23.1 Ventajas

Ayuda a identificar los requisitos del software.

Hace el software amigable al usuario.

El cliente estar seguro de que el producto final reflejara lo que l desea.

3.3 Desventajas

Primera versin de un producto es construido con poca funcionalidad y

poca fiabilidad.
El cliente ve lo que parece ser una versin de trabajo del software, y piensa
que el trabajo esta hecho.
Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres
a la vez.
No hay otra alternativa que comenzar de nuevo, aunque nos duela pero es
ms inteligente, y construir una versin rediseada en la que se resuelvan
estos problemas

3.4 Diferencia entre Prototipo y Producto Final

La diferencia entre prototipo y producto final es que el prototipo es eficiente
y el producto final debe serlo y, que en el prototipo no estn todos los detalles y,
el producto final debe contenerlos.
Clases de prototipos:

Vertical: no recoge todas las funciones del sistema final.

Horizontal: recoge todas las funciones, pero no las desarrolla por completo.

4. Desarrollo de Aplicaciones Rpidas (RAD)

El Desarrollo Rpido de Aplicaciones (DRA) es un modelo de proceso del
desarrollo del software lineal secuencial 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 una
construccin basada 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 perodos cortos de tiempo. 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 del 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 para facilitar la
construccin del software.
4.1 Representacin grfica

Pruebas y entrega. Como el proceso DRA enfatiza la reutilizacin, ya se han

comprobado muchos de los componentes de los programas. Esto reduce tiempo
pruebas. Sin embargo, se deben probar todos los componentes nuevos y se
deben ejercitar todas las interfaces a fondo.
4.2 Ventajas
El DRA hace un fuerte uso de componentes reutilizables. Obviamente, las
limitaciones de tiempo impuestas en un proyecto DRA demandan mbito en
escalas. 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 puede ser afrontada por un equipo DRA separado y ser
integradas en un solo conjunto.
4.3 Desventajas
Para proyectos grandes aunque por escalas, requiere recursos humanos
suficientes como para crear el nmero correcto de equipos.
Requiere clientes y desarrolladores comprometidos en las rpidas actividades
necesarias para completar un sistema en un marco de tiempo abreviado.
4.4 Aplicaciones no apropiadas
Si un sistema no se puede modularizar adecuadamente, la construccin de
los componentes necesarios

Si est en juego el alto rendimiento, y se va a conseguir el rendimiento

convirtiendo interfaces en componentes de sistemas
No es adecuado cuando los riesgos tcnicos son altos.

5. Proceso Unificado Desarrollado de Software (PUDS)

Casos de uso: Los casos de uso son las funciones que proporciona un sistema
para aadir valor a sus usuarios es un medio para capturar requisitos funcionales.
5.1. Principales caractersticas

Dirigido por los casos de uso: El proceso de trabajo sigue un hilo de

trabajo que parte de los casos de uso. Los casos de uso guan el proceso y
se desarrollan a la vez que la arquitectura del sistema y la arquitectura del
sistema influye en la seleccin de los casos de uso, la arquitectura del
sistema y los casos de uso maduran segn avanza el ciclo de desarrollo.
Centrado en la arquitectura: La arquitectura debe permitir el desarrollo
de todos los casos de uso requeridos, ahora y en el futuro los casos de uso
y la arquitectura deben evolucionar en paralelo debe disearse para
permitir que el sistema evolucione
Iterativo e incremental: Cada miniproyecto es una iteracin que resulta
en un incremento. Las iteraciones hacen referencia a pasos en el flujo de
trabajo, y los incrementos, al crecimiento del producto las iteraciones
deben estar controladas deben seleccionarse y ejecutarse de una forma
planificada por lo que son miniproyectos.

5.2. Fases dentro de un ciclo

Fase inicio: Es una descripcin del producto final a partir de una buena
idea y se presenta el anlisis de negocio para el producto
Fase de elaboracin: Especifica en detalle la mayora de los casos de
uso del producto y se disea la arquitectura del sistema. Se crea la lnea
base de la arquitectura.
Fase de construccin: Se construye el producto. Aqu la lnea base de la
arquitectura crece hasta convertirse en el sistema completo y preparado
para ser entregado a los usuarios.

Fase de transicin: Cubre el periodo durante el cual el producto se

convierte en versin beta. Un nmero reducido de usuarios y con
experiencia prueba el producto e informa de defectos y deficiencias.

5.3 Flujos de trabajo

Modelo de casos de uso: Con todos los casos de uso y su relacin con los
usuarios.

Modelo de anlisis: Con dos propsitos: refinar los casos de uso con ms
detalle y establecer la asignacin inicial de funcionalidad del sistema a un
conjunto de objetos que proporcionan el comportamiento.

Modelo de diseo: Define:

a) La estructura esttica del sistema en la forma de subsistemas, clases
e interfaces y
b) Los casos de uso reflejados como
subsistemas, clases, e interfaces.

colaboraciones

entre

los

Modelo de implementacin: Incluye componentes y la correspondencia

de las clases con los componentes.

Incluye un modelo de despliegue que define los nodos fsicos

(ordenadores) y la correspondencia de los componentes con esos
nodos.

Modelo de prueba: Que describe los casos de prueba que verifican los
casos de uso y por supuesto una representacin de la arquitectura.
El sistema tambin debe tener un modelo del dominio o modelo del negocio
que describa el contexto del negocio en el que se halla el sistema.

Todos estos modelos estn relacionados. Juntos representan al sistema

como un todo.

5.4 Las cuatro Ps

Proyecto: Elemento organizativo a travs del cual se gestiona el desarrollo

de software. El resultado de un proyecto es una versin de un producto.

Proceso: conjunto de actividades necesarias para transformar los

requisitos de usuario en un producto. Un proceso es una plantilla para crear
proyectos.

Persona: Los principales autores de un proyecto software son los

arquitectos, desarrolladores, ingenieros de prueba, y el personal que les da
soporte, adems de los usuarios, clientes, y otros interesados. Las personas
son realmente seres humanos a diferencia del trmino abstracto
trabajadores.

Producto: Artefactos que se crean durante la vida del proyecto, como los
modelos, cdigo fuente, ejecutables y documentacin.
5.5

Participantes. Convirtiendo recursos en trabajadores:

Un tipo de trabajador es un papel que un individuo puede desempear en el

desarrollo de software como puede ser un especificador de casos de uso, un
arquitecto, un ingeniero de componentes, o un ingeniero de pruebas de
integracin.
El termino rol se emplea para hablar de los papeles que cumple un trabajador.
Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un
conjunto de actividades en el desarrollo de software.

5.6

Relaciones entre modelos:

Un sistema contiene todas las relaciones y restricciones entre elementos

incluidos en diferentes modelos. Por tanto un sistema no es solo la
coleccin de sus modelos sino que contiene tambin las restricciones entre
ellos.

5.7 Las actividades relacionadas conforman flujos de trabajo

Un flujo de trabajo es un conjunto de actividades. El proceso unificado se basa en
una amplia experiencia para encontrar el conjunto factible de artefactos y
trabajadores.

En trminos de UML un flujo de trabajo es un estereotipo de colaboracin, en el

cual los trabajadores y los artefactos son los participantes.

5.8 Ventajas

De fcil comprensin para el equipo de desarrollo

Fcil control de cambios
Se obtiene un modelado visual del software
Verificacin de la calidad del software
Totalmente organizado.
Los desarrolladores, los supervisores y directores pueden cambiar de
proyecto o de divisin sin tener que aprender un nuevo proceso
El desarrollo del software es repetible puede planificarse y estimarse en
coste con suficiente exactitud como para cumplir las expectativas.

5.9 Desventajas

Si el grupo que desarrolla el proyecto no llega a un estndar de codificacin

se produce entropa.
Si no se realiza la documentacin apropiada se produce entropa en el
grupo que desarrolla el proyecto.

5.10 EL MODELO RUP (Proceso Unificado de Rational)

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de
vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan
varias iteraciones en nmero variable segn el proyecto. En la Figura muestra
cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se
encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan
hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del
proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una
baseline (Lnea Base) de la arquitectura.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la
baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos,
modelo de negocios (refinamiento), anlisis, diseo y una parte de
implementacin orientado a la baseline de la arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por medio
de una serie de iteraciones.
Para cada iteracin se selecciona algunos Casos de Uso, se refina su
anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una
pequea cascada para cada ciclo. Se realizan tantas iteraciones hasta que se
termine la implementacin de la nueva versin del producto.
En la fase de transicin se pretende garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.

6. El modelo espiral WINWIN

El modelo en espiral 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, el desarrollador simplemente
pregunta al cliente lo que se necesita y el cliente proporciona detalles suficientes
para continuar.

Desgraciadamente, esto raramente ocurre. En realidad el cliente y el

desarrollador entran en un proceso de negociacin, donde el cliente puede ser
preguntado para sopesar la funcionalidad, rendimiento, y otros productos o
caractersticas del sistema frente al coste y al tiempo de comercializacin.
La obtencin de requisitos del software requiere una negociacin. Tiene xito
cuando ambas partes ganan.
Representacin grfica

Las mejores negociaciones se esfuerzan en obtener victoria-victoria. El

cliente gana obteniendo el producto o sistema que satisface la mayor parte de
sus necesidades y el desarrollador gana trabajando para conseguir presupuestos
y lograr una fecha de entrega realista.
Adems del nfasis realizado en la negociacin inicial, el modelo en espiral
WINWIN introduce tres hitos en el proceso, llamados puntos de fijacin
representan tres visiones diferentes del progreso mientras que el proyecto
recorre la espiral.

El primer punto de fijacin, llamado objetivos del ciclo de vida (OCV),

define un conjunto de objetivos para cada actividad principal de ingeniera
del software.

El segundo punto de fijacin, llamado arquitectura del ciclo de vida

(ACV), establece los objetivos que se deben conocer mientras que se define
la arquitectura del software y el sistema.

La capacidad operativa inicial (COI) es el tercer punto de fijacin y

representa un conjunto de objetivos asociados a la preparacin del software para
la instalacin/distribucin, preparacin del lugar previamente a la instalacin, y la
asistencia precisada de todas las partes que utilizar o mantendr el software.

7. Recursivo paralelo (Orientado a Objetos - OO)

Hoy en da el paradigma OO encierra una completa visin de la ingeniera
del software. Edward Berard declara: Los beneficios de la tecnologa orientada a
objetos se fortalecen si se usa antes y durante el proceso de ingeniera del
software.
7.1 Caractersticas
Esta tecnologa orientada a objetos considerada debe hacer sentir su
impacto en todo el proceso de ingeniera del software.
Un simple uso de programacin orientada a objetos (POO) no brindar los
mejores resultados.
Los ingenieros del software y sus directores deben considerar tales elementos:
El anlisis de requisitos orientado a objetos (AROO),
El diseo orientado a objetos (DOO),
El anlisis del dominio orientado a objetos (ADOO),
Sistemas de gestin de bases de datos orientadas a objetos (SGBDOO) y
La ingeniera del software orientada a objetos assistida por comutadora
(ISOOAC).
7.2 Representacin grfica
Los sistemas OO utilizan un modelo de ingeniera mediante proceso evolutivo.
Ms adelante, en este mismo captulo, nos referiremos a l como el modelo
recursivo paralelo.

El proceso OO se mueve a travs de una espiral evolutiva que comienza

con la comunicacin con el usuario.

Es aqu donde se define el dominio del problema y se identifican las clases

bsicas del problema. La planificacin y el anlisis de riesgos establecen

una base para el plan del proyecto OO. El trabajo tcnico asociado con la
ingeniera del software OO sigue el camino iterativo. La ingeniera del
software OO hace hincapi en la reutilizacin. Por lo tanto, las clases se
buscan en una biblioteca (de clases O0 existentes) antes de construirse.
Cuando una clase no puede encontrarse en la biblioteca, el desarrollador de
software aplica anlisis orientado a objetos (AOO), diseo orientado a
objetos (DOO), programacin orientada a objetos (POO) y pruebas
orientadas a objetos (PROO) para crear la clase y los objetos derivados de
la clase. La nueva clase se pone en la biblioteca de tal manera que pueda
ser reutilizada en el futuro.

7.3 Ventajas

Fomenta el ensamblaje (reutilizacin) de componentes es el mejor

paradigma para ingeniera del software OO.

7.4 Desventajas

Ser extremadamente difcil definir las clases necesarias para un gran

sistema o producto en una sola iteracin.
La visin orientada a objetos demanda un enfoque evolutivo de la
ingeniera del software.

8. Ciclo de vida en cascada Incremental

En este caso se va creando el sistema aadiendo pequeas
funcionalidades. Cada uno de los pequeos incrementos es parecido a lo que
ocurre dentro de la fase de mantenimiento, en el sentido de aumentar mdulos.
Combina elementos del modelo cascada (aplicados repetidamente) con la
filosofa interactiva de construccin de prototipos.
8.1 Representacin grfica

Por un lado est el anlisis y el diseo global. Por otra parte estn los
pequeos incrementos, con las fases de diseo detallado, codificacin y
mantenimiento.
El modelo incremental aplica secuencias lineales de forma escalonada
mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un
incremento del software.
El modelo incremental entrega el software en partes pequeas, pero
utilizables, llamadas ((incrementos).
En general, cada incremento se construye sobre aqul que ya ha sido entregado.

El primer incremento a menudo es un producto esencial. 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.

El plan afronta la modificacin del producto central a fin de cumplir mejor

las necesidades del cliente y la entrega de funciones, y caractersticas
adicionales.

Este proceso se repite siguiendo la entrega de cada incremento, hasta que

se elabore el producto completo.
El modelo de proceso incremental, como la construccin de prototipos y otros
enfoques evolutivos, es iterativo por naturaleza.El modelo incremental se centra
en la entrega de un producto operacional con cada incremento. Los primeros
incrementos son versiones incompletas del producto final, pero proporcionan al
usuario la funcionalidad que precisa y tambin una plataforma para la evaluacin.
8.2 Ventajas

No es necesario tener todos los requisitos en un principio.

Entrega un producto operacional con cada incremento.
til cuando la dotacin de personal no est disponible para una
implementacin completa en la fecha lmite que se haya establecido para
el proyecto
Los primeros incrementos se pueden implementar con menos personas y
proporcionan al usuario una plataforma para la evaluacin.

8.3 Desventajas
Los errores en la deteccin de requisitos se encuentran tarde.
Cada incremento no es el producto final, sino ms bien un producto q se acerca
cada vez ms a serlo, el incremento n ser el producto final.

9. Framework
En el desarrollo de software, un framework es una estructura de soporte
definida en la cual otro proyecto de software puede ser organizado y desarrollado.
Tpicamente, un framework puede incluir soporte de programas, bibliotecas y un
lenguaje interpretado entre otros software para ayudar a desarrollar y unir los
diferentes componentes de un proyecto.
9.1 Arquitectura
Dentro de este aspecto, podemos basarnos en el modelo MVC (Controlador =>
Modelo => Vista) ya que debemos fragmentar nuestra programacin. Tenemos
que contemplar estos aspectos bsicos en cuanto a la implementacin de nuestro
sistema:

Controlador: Con este apartado podemos controlar el acceso (incluso

todo) a nuestra aplicacin, esto pueden ser: archivos, scripts... programas;
cualquier tipo de informacin que permita la interfaz. As, podremos
diversificar nuestro contenido de forma dinmica, y esttica (a la vez);

pues, solo debemos controlar ciertos aspectos (como se ha mencionado

antes).

Modelo: Este miembro del controlador maneja las operaciones lgicas, y

de manejo de informacin (previamente enviada por su ancestro) para
resultar de una forma explicable, y sin titubeos. Cada miembro debe ser
meticulosamente llamado, en su correcto nombre y en principio, con su
verdadera naturaleza: el manejo de informacin, su complementacin
directa.

Vista: Al final, a este miembro de la familia le corresponde dibujar, o

expresar la ltima forma de los datos: la interfaz grfica que interacta con
el usuario final del programa (GUI). Despus de todo, a este miembro le
toca evidenciar la informacin obtenida hasta hacerla llegar con el
controlador. Solo (e inicialmente), nos espera demostrar la informacin.

10. Modelo de ciclo de vida en espiral

Propuesto originalmente por Boehm en 1988, es un modelo de proceso de
software evolutivo que conjuga la naturaleza iterativa de construccin de
prototipos con los aspectos controlados y sistemticos del modelo cascada

(clsico). Proporciona el potencial para el desarrollo rpido de versiones

incrementales del software. En el modelo espiral, el software se desarrolla en una
serie de versiones incrementales.
10.1 Regiones de tareas

El modelo en espiral se divide en un nmero de actividades de marco de

trabajo, tambin llamadas regiones de tareas. Generalmente, existen entre tres y
seis regiones de tareas. La Figura anterior representa un modelo en espiral que
contiene seis regiones de tareas: ms sofisticadas del software. Cada paso por la
regin de planificacin produce ajustes en el plan del proyecto.
El coste y la planificacin se ajustan con la realimentacin ante la evaluacin
del cliente. Adems, el gestor del proyecto ajusta el nmero planificado de
iteraciones requeridas para completar el software.
Comunicacin con el cliente- Establecer comunicacin entre
desarrollador y cliente.
Planificacin- Definir recursos, el tiempo y otra informacin relacionadas
con el proyecto.
Anlisis de riesgos- evaluar riesgos tcnicos y de gestin.
Ingeniera- las tareas requeridas para construir una o ms
representaciones de la aplicacin.
Construccin y accin- construir, probar, instalar y proporcionar soporte
al usuario (por ejemplo: documentacin y prctica)
Evaluacin del cliente- las tareas requeridas para obtener la reaccin del
cliente segn la evaluacin de las representaciones del software creadas
durante la etapa de ingeniera e implementada durante la etapa de
instalacin.
Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente
cumple con los requisitos establecidos, tambin se verifica que funciona
correctamente. El propio cliente evala el producto. No existe una diferencia muy
clara entre cuando termina el proyecto y cuando empieza la fase de
mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un
nuevo ciclo.
10.2 Ventajas

No necesita una definicin completa de los requisitos para empezar a

funcionar.
Al entregar productos desde el final de la primera iteracin es ms fcil
validar los requisitos.
El riesgo en general es menor, porque si todo se hace mal, solo se ha
perdido el tiempo y recursos invertidos en una iteracin (las anteriores
iteraciones estn bien).
El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en
etapas tempranas hay tiempo de subsanarlos.

10.3. Desventajas

Es difcil evaluar los riesgos.

Necesita de la participacin continua por parte del cliente.

Cuando se subcontrata hay que producir previamente una especificacin
completa de lo que se necesita, y esto lleva tiempo.

10.4 Aplicaciones

Sistemas de gran tamao.

Proyectos donde sea importante el factor riesgo.
Cuando no sea posible definir al principio todos los requisitos.

11. Ciclo de vida tipo Sashimi

En este caso sin embargo, se permite un solapamiento entre fases. Por
ejemplo, sin tener terminado del todo el diseo se comienza a implementar. El
nombre sashimi deriva del modo del estilo de presentacin de rodajas de
pescado crudo en Japn.
Las fases de este ciclo de vida son:
Concepto.- consiste en definir los objetivos del proyecto, beneficios, tipo de
tecnologa y el tipo de ciclo de vida.
Anlisis.- Se analiza los requerimientos y se busca una solucin optima.
El diseo arquitectnico.- es el de alto nivel.
El diseo detallado.- es el de bajo nivel.
Codificacin.- Se implementa el cdigo del proyecto
Pruebas.- Se prueba si el proyecto funciona correctamente es decir sin
entropa.
11.1 Representacin grfica

11.2 Ventajas

Una ventaja de este modelo es que no necesita generar tanta

documentacin como el ciclo de vida en cascada puro debido a la
continuidad del mismo personal entre fases.

11.3 Desventajas

Es an ms difcil controlar el progreso del proyecto debido a que los finales

de fase ya no son un punto de referencia claro.
Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir
inconsistencias.