MODELOS DE DESARROLLO DE SOFTWARE

1. MODELO CODIFICAR CORREGIR:

Es un modelo poco til, pero sin embargo bastante comn Se puede tener una
especificacin formal, o no tenerla Si no se ha utilizado formalmente un
mtodo, probablemente ya se est usando el mtodo Codificar y Corregir en
forma intuitiva Cuando se utiliza ste mtodo se empieza con una idea
general de lo que se necesita construir, Se utiliza cualquier combinacin de
diseo, cdigo, depuracin y mtodos de prueba no formales que sirven hasta
que se tiene el producto listo para entregarlo.

Ventajas:
No conlleva ninguna gestin; no se pierde tiempo en la planificacin, en la
documentacin, en el control de calidad, en el cumplimiento de los
estndares, o en cualquier otra actividad que no sea codificacin pura.
Como se pasa directamente a codificar, se pueden mostrar inmediatamente
indicios de progreso.
Requiere poca experiencia: cualquier persona que haya escrito alguna vez un
programa est familiarizada con ste modelo.
Para proyectos pequeos que se intentan liquidar en un tiempo breve, o para
modelos como programas de demostracin o prototipos desechables, el
modelo codificar y corregir puede ser til.

Desventajas:
El modelo resulta peligroso para otro tipo de proyectos que no sean pequeos.
Puede que no suponga gestin alguna, pero tampoco ofrece medios de
evaluacin del progreso.
No proporciona medios de evaluacin de la calidad o de identificacin de
riesgos.
Si al llevar tres cuartas partes de la codificacin descubre que el diseo es
incorrecto, no hay otra solucin que desechar el trabajo y comenzar de nuevo.

2. MODELO CASCADA (SECUENCIAL LINEAL)

Este es tambin llamado "Modelo Clsico", "Modelo Tradicional" o "Modelo en

Cascada".
Este es el ms bsico de todos los modelos, y sirve como bloque de construccin
para los dems modelos de ciclo de vida. La visin del modelo cascada del
desarrollo de software es muy simple; dice que el desarrollo de software puede
ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de
metas bien definidas, y las actividades dentro de una fase contribuyen a la
satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la
fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de
avance muestra el flujo normal. Las flechas hacia atrs representan la
retroalimentacin.
Caractersticas:
Planear un proyecto antes de embarcarse en l.
Definir el comportamiento externo deseado del sistema antes de disear
su arquitectura interna.
Documentar los resultados de cada actividad.
Disear un sistema antes de codificarlo.
Testear un sistema despus de construirlo.

Ventaja:
Una de las contribuciones ms importantes del modelo cascada es para los
administradores, posibilitndoles avanzar en el desarrollo, aunque en una
escala muy bruta.
Desventajas:

Los cambios introducidos durante el desarrollo pueden confundir al equipo

profesional en las etapas tempranas del proyecto. Si los cambios se
producen en etapa madura (codificacin o prueba) pueden ser
catastrficos para un proyecto grande.

No es frecuente que el cliente o usuario final explicite clara y

completamente los requisitos (etapa de inicio); y el modelo lineal lo
requiere. La incertidumbre natural en los comienzos es luego difcil de
acomodar.

El cliente debe tener paciencia ya que el software no estar disponible

hasta muy avanzado el proyecto. Un error detectado por el cliente (en fase
de operacin) puede ser desastroso, implicando reinicio del proyecto con
altos costos.

Critica:
Este es un modelo en el cual se debe usar cuando todos los requerimientos han
sido establecidos claramente de entrada.

3. MODELO DE CONSTRUCCION DE PROTOTIPOS

El prototipado de requerimientos es la creacin de una implementacin parcial de
un sistema, para el propsito explcito de aprender sobre los requerimientos del
sistema. Un prototipo es construido de una manera rpida tal como sea posible.
Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que
ellos experimenten con el prototipo. Estos individuos luego proveen la
retroalimentacin sobre lo que a ellos les gust y no les gust acerca del
prototipo proporcionado, quienes capturan en la documentacin actual de la
especificacin de requerimientos la informacin entregada por los usuarios para
el desarrollo del sistema real. El prototipado puede ser usado como parte de la
fase de requerimientos (determinar requerimientos) o justo antes de la fase de
requerimientos (como predecesor de requerimientos). En otro caso, el
prototipado puede servir su papel inmediatamente antes de algn o todo el
desarrollo incremental en modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin
de requerimientos para sistemas complejos tienden a ser relativamente
dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho ms
fcil proveer retroalimentacin convenientemente basada en la manipulacin,
leer una especificacin de requerimientos potencialmente ambigua y extensa.

Esc
uch
ar
al
clie
nte

donde

Val
idar
pro
toti
po

Co
nstr
uir
pro
toti
po

Diferente del
modelo
evolutivo
los

requerimientos mejor entendidos estn incorporados, un prototipo generalmente

se construye con los requerimientos entendidos ms pobremente.
Desventajas:

Cliente cree que es el sistema.

Peligro de familiarizacin con malas elecciones iniciales (quick and dirty).

Critica:
Se debe usar cuando inicialmente no estn claros los requerimientos. Para as
definir claramente de entrada las reglas con el cliente.

4. MODELOS DESARROLLO EVOLUTIVO

Se adaptan ms fcilmente a los cambios introducidos a lo largo del

desarrollo.
Iterativos
En cada iteracin se obtienen versiones ms completas del SW.
Existen cuatro (4) tipos de desarrollo evolutivo:
a. . Modelo incremental
b. . Modelo en espiral
c. . Modelo de ensamblaje de componentes
d. . Modelo de desarrollo concurrente

4.1. MODELO INCREMENTAL

Los riesgos asociados con el desarrollo de sistemas largos y complejos son
enormes. Una forma de reducir los riesgos es construir slo una parte del
sistema, reservando otros aspectos para niveles posteriores. El desarrollo
incremental es el proceso de construccin siempre incrementando subconjuntos
de requerimientos del sistema. Tpicamente, un documento de requerimientos es
escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El
desarrollo incremental no demanda una forma especfica de observar el
desarrollo de algn otro incremento. As, el modelo cascada puede ser usado
para administrar cada esfuerzo de desarrollo, como se muestra en la figura.

El modelo de desarrollo incremental provee algunos beneficios significativos para

los proyectos:

Construir un sistema pequeo es siempre menos riesgoso que construir un

sistema grande.
Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si
los requerimientos planeados para los niveles subsiguientes son correctos.
Si un error importante es realizado, slo la ltima iteracin necesita ser
descartada.
Reduciendo el tiempo de desarrollo de un sistema (en este caso en
incremento del sistema) decrecen las probabilidades que esos
requerimientos de usuarios puedan cambiar durante el desarrollo.
Si un error importante es realizado, el incremento previo puede ser usado.

Los errores de desarrollo realizados en un incremento, pueden ser

arreglados antes del comienzo del prximo incremento.

Ventajas:
El modelo proporciona todas las ventajas del modelo en cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.

Desventajas:
El modelo Incremental no es recomendable para casos de sistemas de tiempo
real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice
de riesgos.

Critica:
En este modelo se debe especificar con precisin todo lo que el sistema va a
hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuira los costos.

4.2. MODELO EN ESPIRAL

Este es un modelo de proceso de software evolutivo, el cual enlaza la naturaleza
iterativa de la construccin de prototipos, pero conservado aquellas propiedades
del modelo en cascada.
El modelo en espiral fue desarrollado por Boehm, quien lo describe as:
El modelo de desarrollo en espiral es un generador de modelo de proceso guiado
por el riesgo que se emplea para conducir sistemas intensivos de ingeniera de
software concurrente y a la vez con muchos usuarios.

Caractersticas:

Un enfoque cclico para el crecimiento incremental del grado de definicin

e implementacin de un sistema, mientras que disminuye su grado de
riesgo.

Un conjunto de puntos de fijacin para asegurar el compromiso del usuario

con soluciones de sistema que sean factibles y mutuamente satisfactorias.

El modelo espiral no es una alternativa del modelo cascada, ellos son

completamente compatibles.

Funcionamiento del modelo Espiral

En cada vuelta tomamos en cuenta:

Los Objetivos: Que necesidad debe envolver el programa.

Alternativas: Los varios mtodos de alcanzar los objetivos de manera
exitosa, a travs de diferentes puntos como son:
o

Caractersticas: experiencia del personal, exigencias a efectuar.

Formas de gestin del programa.

Riesgo tomado con cada alternativa.

Desarrollar y Verificar: Programar y probar el programa .

Se planificaran los siguientes pasos y se volver a empezar la espiral. La
espiral tiene una forma de caracola y se dice que mantiene dos dimensiones
la radial y la angular.

Desventajas:

Requiere mucha experiencia y habilidad para la evaluacin de los riesgos,

lo cual es requisito para el xito del proyecto.

Es difcil convencer a los grandes clientes que se podr controlar este

enfoque evolutivo.

4.3. MODELO ENSAMBLAJE DE COMPONENTES:

- Incorpora muchas de las caractersticas del modelo en espiral.
- Es evolutivo por naturaleza, y exige un enfoque iterativo para la creacin
del software.
- Configura aplicaciones desde componentes preparados de software
(algunas veces llamados clases).
- Las clases (llamadas componentes) creadas en proyectos de ingeniera
de software anteriores se almacenan en una biblioteca de clases o
depsito.

4.4. MODELO DE DESARROLLO CONCURRENTE

Como el modelo espiral, el modelo concurrente provee una meta-descripcin del
proceso software. Mientras que la contribucin primaria del modelo espiral es en
realidad que esas actividades del software ocurran repetidamente, la
contribucin del modelo concurrente es su capacidad de describir las mltiples
actividades del software ocurriendo simultneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades
que ocurren en algn tiempo del proceso de desarrollo de software.
Los requerimientos son usualmente "lneas de base", cuando una mayora de los
requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un
esfuerzo considerable al diseo. Sin embargo, una vez que comienza el diseo,
cambios a los requerimientos son comunes y frecuentes (despus de todo, los
problemas reales cambian, y nuestro entendimiento de los problemas
desarrollados tambin). Es desaconsejado detener el diseo en este camino
cuando los requerimientos cambian; en su lugar, existe una necesidad de

modificar y rehacer lneas de base de los requerimientos mientras progresa el

diseo. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseo puede no ser afectado, medianamente afectado o se
requerir comenzar todo de nuevo.
Durante el diseo de arquitectura, es posible que algunos componentes
comiencen a ser bien definidos antes que la arquitectura completa sea
estabilizada. En tales casos, puede ser posible comenzar el diseo detallado en
esos componentes estables. Similarmente, durante el diseo detallado, puede
ser posible proceder con la codificacin y quizs regular testeando en forma
unitaria o realizando testeo de integracin previo a llevar a cabo el diseo
detallado de todos los componentes.
En algunos proyectos, mltiples etapas de un producto se han desarrollado
concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la
etapa 1 de un producto, y al mismo tiempo estar haciendo mantencin sobre un
componente 2, mientras que se est haciendo codificacin sobre un componente
3, mientras se realiza diseo sobre una etapa 4, y especificacin de requisitos
sobre un componente 5.

Critica:
Este modelo se utiliza cuando las actividades estn ocurriendo simultneamente
as, se posibilita el conocimiento del estado real en el que se encuentra el
proyecto.

5. MODELOS DE DESARROLLO RPIDO DE APLICACIONES:

El Desarrollo Rpido de Aplicaciones (DRA) (Rapid Application Development
RAD) es un modelo de proceso del desarrollo del software lineal secuencial
que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una
adaptacin a Alta velocidad 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. 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 proceso?
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.
Es
la
comunicacin
entre
los
objetos.
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 de 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.

6. MODELO DE DESARROLLO FORMAL DE SISTEMAS:

Comprende un conjunto de actividades que conducen a la especificacin
matemtica del software de computadora.
- Lo mtodos formales permiten que un ingeniero de software especifique,
desarrolle y verifique un sistema basado en computadora aplicando una notacin
rigurosa y matemtica.

- El enfoque ms conocido del proceso de desarrollo formal es el proceso de

Cuarto limpio, que comprende el desarrollo incremental del software en el cual
cada etapa se desarrolla y verifica utilizando un enfoque formal.
- Este enfoque es adecuada para el desarrollo de sistemas que tiene
requerimientos severos de proyeccin, fiabilidad o seguridad.
- En realidad para la mayora de sistemas este proceso no ofrece ventajas
significativas sobre los dems enfoques en los costos y calidad.
- En el entorno de gestin, es caro y lleva muchos tiempo, requiere un estudio
detallado donde pocos desarrolladores tienen estos antecedentes, su notacin es
difcil que sirva de medio de
comunicacin con el cliente .

7. MODELO DE DESARROLLO BASADO EN LA REUTILIZACION:

El diseo basado en reutilizacin puro busca construir un producto software integrando
componentes pre-existentes. Los beneficios principales que otorga este modelo son:

Tiempos de desarrollos cortos

-Disminucin de errores
-Disminucin de costos y riegos ya que se reduce los componentes a desarrollar
Existe un aumento de la confiabilidad ya que los componentes a utilizar ya fueron testeados y
utilizados en otro momento previo al comienzo del proyecto

A modo de desventaja podemos mencionar el hecho de que al no poseer algn componente que
cubra con un requisito dado por el usuario, este debe ser modificado para adaptarlo a los
componentes almacenados en el repositorio de componentes.
Esto se da en el modelo puro. En cambio en el modelo real si no se puede adaptar un requisito de
usuario, se conseguir o se desarrollara ese modulo para que cumpla con lo pedido por el
usuario.
Otra desventaja de este modelo es que una vez finalizada la etapa de modificacin de requisitos,
y ante la eventual necesidad de cambios en estos ltimos, puede pasar que no haya
componentes que se adapten a las nuevas modificaciones.