MODELOS DE DESARROLLO DE SOFTWARE

1. MODELO SECUENCIAL LINEAL

Este es también llamado "Modelo Clásico", "Modelo Tradicional" o "Modelo en

Cascada".
Este es el más básico de todos los modelos, y sirve como bloque de
construcción para los demás modelos de ciclo de vida. La visión del modelo
cascada del desarrollo de software es muy simple; dice que el desarrollo de
software puede ser a través 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 satisfacción de metas de esa fase o quizás a una
subsecuencia de metas de la fase. Las flechas muestran el flujo de información
entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia
atrás representan la retroalimentación.
Características:
 Planear un proyecto antes de embarcarse en él.

 Definir el comportamiento externo deseado del sistema antes de diseñar

su arquitectura interna.

 Documentar los resultados de cada actividad.

 Diseñar un sistema antes de codificarlo.

 Testear un sistema después de construirlo.

Ventaja:
 Una de las contribuciones más importantes del modelo cascada es para
los administradores, posibilitándoles 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 (codificación o prueba) pueden ser
catastróficos 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 difícil 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 operación) 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.
 2. MODELO DE CONSTRUCCION DE PROTOTIPOS

El prototipado de requerimientos es la creación de una implementación parcial

de un sistema, para el propósito explícito de aprender sobre los requerimientos
del sistema. Un prototipo es construido de una manera rápida 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 retroalimentación sobre lo que a ellos les gustó y no les gustó
acerca del prototipo proporcionado, quienes capturan en la documentación
actual de la especificación de requerimientos la información 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 algún
o todo el desarrollo incremental en modelos incremental o evolutivo.

El Prototipado ha sido usado frecuentemente en los 90, porque la

especificación de requerimientos para sistemas complejos tienden a ser
relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que
es mucho más fácil proveer retroalimentación convenientemente basada en la
manipulación, leer una especificación de requerimientos potencialmente
ambigua y extensa.

Escuchar Construir
al cliente prototipo

Validar
prototipo
Diferente del modelo evolutivo donde los requerimientos mejor entendidos
están incorporados, un prototipo generalmente se construye con los
requerimientos entendidos más pobremente.
Desventajas:

 Cliente cree que es el sistema.

 Peligro de familiarización con malas elecciones iniciales (quick and
dirty).

Critica:

Se debe usar cuando inicialmente no están claros los requerimientos. Para así
definir claramente de entrada las reglas con el cliente.

3. MODELOS EVOLUTIVOS
 Se adaptan más fácilmente a los cambios introducidos a lo largo del
desarrollo.
 Iterativos
 En cada iteración se obtienen versiones más completas del SW.

3.1. MODELO INCREMENTAL

Los riesgos asociados con el desarrollo de sistemas largos y complejos son

enormes. Una forma de reducir los riesgos es construir sólo una parte del
sistema, reservando otros aspectos para niveles posteriores. El desarrollo
incremental es el proceso de construcción siempre incrementando
subconjuntos de requerimientos del sistema. Típicamente, 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 específica de observar el
desarrollo de algún 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 pequeño es siempre menos riesgoso que construir

un sistema grande.

 Al ir desarrollando parte de las funcionalidades, es más fácil determinar

si los requerimientos planeados para los niveles subsiguientes son
correctos.

 Si un error importante es realizado, sólo la última iteración 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 próximo incremento.

En la figura se muestra un refino del diagrama previo, bajo un esquema

temporal, para obtener finalmente el esquema del Modelo de ciclo de vida
Iterativo Incremental, con sus actividades genéricas asociadas. Aquí se
observa claramente cada ciclo cascada que es aplicado para la obtención de
un incremento; estos últimos se van integrando para obtener el producto final
completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por
simplicidad, en la figura 5 se muestra como secuencial puro.

Se observa que existen actividades de desarrollo (para cada incremento) que

son realizadas en paralelo o concurrentemente, así por ejemplo, en la figura,
mientras se realiza el diseño detalle del primer incremento ya se está
realizando en análisis del segundo.

Ventajas:

El modelo proporciona todas las ventajas del modelo en cascada realimentado,

reduciendo sus desventajas sólo 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 precisión todo lo que el sistema va a
hacer antes de desarrollarlo. Lo cual lo hace manejable y disminuiría los
costos.

3.2. MODELO EN ESPIRAL

Este es un modelo de proceso de software evolutivo, el cual enlaza la
naturaleza iterativa de la construcción 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
ingeniería de software concurrente y a la vez con muchos usuarios.
Características:

 Un enfoque cíclico para el crecimiento incremental del grado de

definición e implementación de un sistema, mientras que disminuye su
grado de riesgo.

 Un conjunto de puntos de fijación 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 métodos de alcanzar los objetivos de
manera exitosa, a través de diferentes puntos como son:
 o Características: experiencia del personal, exigencias a
efectuar.
o Formas de gestión del programa.
o 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:

o Angular=Avance del proyecto Software, dentro de un ciclo.

o Radial=Aumento del coste del proyecto, ya que con cada
nueva iteración se pasa más tiempo desarrollando.

Este sistema es muy utilizado en proyectos largos como pueden ser la creación
de un Sistema Operativo. Y que necesitan constantes cambios.

Al ser un modelo de Ciclo de Vida orientado al riesgo se dice que uno de los
aspectos fundamentales de su éxito radica en que el equipo que lo aplique sea
capaz de detectar y catalogar correctamente dicho riesgo.

Desventajas:

 Requiere mucha experiencia y habilidad para la evaluación de los

riesgos, lo cual es requisito para el éxito del proyecto.
 Es difícil convencer a los grandes clientes que se podrá controlar este
enfoque evolutivo.

Critica:

Este modelo es útil para grandes proyectos pero no ha sido utilizado tanto
como el lineal secuencial o el de prototipos. Tiene similitud con el modelo en
cascada, pero aquí lo enfoca en un sistema más real.
 3.3. MODELO WINWIN

Una variante interesante del Modelo Espiral previamente visto es el "Modelo

Espiral Win-Win" (Barry Boehm). El Modelo Espiral previo (clásico) sugiere la
comunicación con el cliente para fijar los requisitos, en que simplemente se
pregunta al cliente qué necesita y él proporciona la información para continuar;
pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y
desarrollador entran en una negociación, se negocia coste frente a
funcionalidad, rendimiento, calidad, etc.

"Es así que la obtención de requisitos requiere una negociación, que tiene éxito
cuando ambas partes ganan".

Las mejores negociaciones se fuerzan en obtener "Victoria & Victoria" (Win &
Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el
desarrollador también gane consiguiendo presupuesto y fecha de entrega
realista. Evidentemente, este modelo requiere fuertes habilidades de
negociación.

El modelo Win-Win define un conjunto de actividades de negociación al

principio de cada paso alrededor de la espiral; se definen las siguientes
actividades:

1 - Identificación del sistema o subsistemas clave de los directivos(*)

(saber qué quieren).
2 - Determinación de "condiciones de victoria" de los directivos (saber
qué necesitan y los satisface)
3 - Negociación de las condiciones "victoria" de los directivos para
obtener condiciones "Victoria & Victoria" (negociar para que ambos
ganen).

(*) Directivo: Cliente escogido con interés directo en el producto, que puede ser
premiado por la organización si tiene éxito o criticado si no.
El modelo WinWin hace énfasis en la negociación inicial, también introduce 3
hitos en el proceso llamados "puntos de fijación", que ayudan a establecer la
completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de
continuar el proyecto de desarrollo del software.

Critica:

En este modelo las actividades que se definen son importantes como lo son: la
identificación del sistema, la determinación de las condiciones y la negociación
de estas.

3.4. MODELO DE DESARROLLO CONCURRENTE

Como el modelo espiral, el modelo concurrente provee una meta-descripción

del proceso software. Mientras que la contribución primaria del modelo espiral
es en realidad que esas actividades del software ocurran repetidamente, la
contribución del modelo concurrente es su capacidad de describir las múltiples
actividades del software ocurriendo simultáneamente.

Esto no sorprende a nadie que ha estado involucrado con las diversas

actividades que ocurren en algún tiempo del proceso de desarrollo de software.

Los requerimientos son usualmente "líneas de base", cuando una mayoría de

los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica
un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el
diseño, cambios a los requerimientos son comunes y frecuentes (después de
todo, los problemas reales cambian, y nuestro entendimiento de los problemas
desarrollados también). Es desaconsejado detener el diseño en este camino
cuando los requerimientos cambian; en su lugar, existe una necesidad de
modificar y rehacer líneas de base de los requerimientos mientras progresa el
diseño. Por supuesto, dependiendo del impacto de los cambios de los
requerimientos el diseño puede no ser afectado, medianamente afectado o se
requerirá comenzar todo de nuevo.
Durante el diseño 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 diseño detallado
en esos componentes estables. Similarmente, durante el diseño detallado,
puede ser posible proceder con la codificación y quizás regular testeando en
forma unitaria o realizando testeo de integración previo a llevar a cabo el
diseño detallado de todos los componentes.

En algunos proyectos, múltiples etapas de un producto se han desarrollado

concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la
etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un
componente 2, mientras que se está haciendo codificación sobre un
componente 3, mientras se realiza diseño sobre una etapa 4, y especificación
de requisitos sobre un componente 5.

Critica:

Este modelo se utiliza cuando las actividades están ocurriendo

simultáneamente así, se posibilita el conocimiento del estado real en el que se
encuentra el proyecto.

MODELO DRA

Es el proceso de desarrollo rápido de software diseñado para facilitar y acelerar

la creación de aplicaciones, que permite construir sistemas utilizables en poco
tiempo, normalmente de 60 a 90 días. En conclusión, es una adaptación a "Alta
velocidad" 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.

Características del Modelo

Debido a que el software o aplicación se requiere lo más pronto posible no

existe una especificación del sistema detallada.

El software no se desarrolla y utiliza en su totalidad, sino en una serie de

incrementos, donde en cada incremento se incluyen nuevas funcionalidades al
sistema.
A menudo se desarrollan las interfaces de usuario del sistema utilizando un
sistema de desarrollo interactivo que permite que el diseño de la interfaz se
cree rápidamente dibujando y colando iconos en la interfaz.

Para su desarrollo se utilizan herramientas de desarrollo visual para agilizar el

proceso.

Se necesitan equipos compuestos por alrededor de seis personas, incluyendo

desarrolladores y usuarios de tiempo completo, así como aquellas personas
involucradas en los requisitos.

Las funciones secundarias son eliminadas como sea necesario para cumplir
con el calendario.

Fases

• 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 proceso?

• 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.

• Modelado de Procesos

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. Es la comunicación entre
los objetos.

• 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).

• Pruebas de 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.

Ventajas

-Los entregables pueden ser fácilmente trasladados a otra plataforma.

-El desarrollo se realiza a un nivel de abstracción mayor.

-Entrega temprana al cliente.

-Compromiso del cliente con el sistema.

-Mayor flexibilidad.

-Menor codificación manual.

-Mayor involucramiento de los usuarios.

-Posiblemente menos fallas.

-Posiblemente menor costo.

-Ciclos de desarrollo más pequeños.

-Interfaz gráfica estándar.

Desventajas

-Tiene inconvenientes para proyectos grandes, necesita suficientes recursos

humanos para crear el número correcto de equipos.

-Si los desarrolladores y clientes no se comprenden con las actividades

necesarias para completar el sistema, los proyectos fallarán.

-Un alto costo de herramientas integradas y equipo necesario.

-Progreso más difícil de medir.

-Menos eficiente y con menor precisión científica.

Modelo de Métodos Formales

METODOS FORMALES

La denominación métodos formales se usa para referirse a cualquier actividad

relacionada con representaciones matemáticas del software, incluyendo la
especificación formal de sistemas, análisis y demostración de la especificación,
el desarrollo transformacional y la verificación de programas. Todas estas
actividades dependen de una especificación formal del software.
Una especificación formal del software es una especificación expresada en un
lenguaje cuyo vocabulario, sintaxis y semántica están formalmente definidos.
Esta necesidad de una definición formal significa que los lenguajes de
especificación deben basarse en conceptos matemáticos cuyas propiedades se
comprendan bien. La rama de las matemáticas usada es la de matemática
discreta, y los conceptos matemáticos provienen de la teoría de conjuntos, la
lógica y el álgebra.