ENFOQUES METODOLGICOS DE

DESARROLLO
Presentado por:
Sofa Monroy
Cristian Garzn
Duvan Esquivel
Jorge Menjura
Ivn Reyes

MODELO DE CASCADA

Modelo de cascada
En Ingeniera de software el
desarrollo en cascada, tambin
llamado modelo en cascada, es el
enfoque metodolgico que ordena
rigurosamente
las
etapas
del
proceso para el desarrollo de
software, de tal forma que el inicio
de cada etapa debe esperar a la
finalizacin de la etapa anterior.

Metodologa de desarrollo en cascada

es:
1. Anlisis y definicin de requerimientos: Los servicios,
restricciones y metas del sistema se define a partir de las
consultas con los usuarios. Se define una especificacin del
sistema.
2. Diseo del sistema y del software: El proceso de diseo del
sistema divide los requerimientos en sistemas hardware o
software. Establece una arquitectura completa del sistema. El
diseo de software identifica y describe las abstracciones
fundamentales del sistema software y sus relaciones.

3. Implementacin y prueba de unidades: Durante esta etapa,

el diseo del software se lleva a cabo como un conjunto o
unidades de programas.

4. Integracin y prueba del sistema: Los programas

o las unidades individuales de programas se integran
y prueban como un sistema completo para asegurar
que se cumplan los requerimientos del software.

5. Funcionamiento y mantenimiento: El sistema se

instala y se pone en funcionamiento practico. El
mantenimiento implica corregir errores no
descubiertos en las etapas anteriores del ciclo de
vida.

Modelo en Cascada - Fortalezas

Fcil entendimiento e implementacin.
Ampliamente utilizado y conocido ( En teora ).
Refuerza buenos hbitos: definir antes que
disear, disear antes que codificar.
Identifica entregables e hitos.
Orientado a documentos.
Funciona bien en productos maduros y equipos
dbiles.

Modelo en Cascada - Debilidades

No aprovecha la iteracin, ni el desarrollo
exploratorio
Espera requerimientos definidos completamente al
Inicio del proyecto
IREAL
Dificultad para integrar administracin del riesgo
El software es entregado tarde en el proyecto esto
hace que se detecten errores graves muy tarde.
Hacer cambios es difcil y costoso.

MODELO ESPIRAL
Boehm, ide y promulg un
modelo desde un enfoque distinto
al tradicional en Cascada: El
Modelo Evolutivo Espiral. Su
Modelo de Ciclo de Vida en
Espiral
tiene
en
cuenta
fuertemente
el
riesgo
que
aparece a la hora de desarrollar
software. Para ello, se comienza
mirando las posibles alternativas
de desarrollo, se opta por la de
riesgo ms asumible y se hace un
ciclo de la espiral.

HISTORIA

Barry Boehm era un Programador-Analista en General

Dynamics entre 1955 y 1959, sus intereses actuales de
la investigacin incluyen modelar de proceso del
software, ingeniera de requisitos del software, las
arquitecturas del software, mtrica del software y los
modelos del coste, los ambientes de la tecnologa de
dotacin lgica, y tecnologa de dotacin lgica basada
en el conocimiento.

DEFINICION
El MODELO en espiral, propuesto
originalmente por BOEHM en 1976, es
un modelo de proceso de software
evolutivo
donde
se
conjuga
la
naturaleza
de
construccin
de
prototipos
con
los
aspectos
controlados
y
sistemticos
del
MODELO LINEAL y SECUENCIAL.
EL modelo en espiral se divide en un
nmero de actividades de marco de
trabajo, tambin llamadas REGIONES
DE TAREAS , Cada una de las regiones
estn compuestas por un conjunto de
tareas del trabajo llamado CONJUNTO
DE TAREAS que se adaptan a las
caractersticas del proyecto que va a
emprenderse en todos los casos se
aplican actividades de proteccin.

TIPOS

El modelo espiral tuvo varias

modificaciones que son:
Modelo Original de Boehm.
Modelo Tpico de Seis
Regiones.
Modelo WINWIN.

MODELO ORIGINAL DE BOEHM

Cada vuelta se divide en 4 sectores:
Planeacin
: determinacin
de
los
objetivos,
alternativas y restricciones
Anlisis de riesgo : anlisis de alternativas e
identificacin/resolucin de riesgos
Ingeniera : desarrollo del producto hasta "el siguiente
nivel".
Evaluacin : valoracin por parte del cliente de los
resultados obtenidos.
El movimiento de la espiral, ampliando con cada iteracin
su amplitud radial, indica que cada vez se van
construyendo versiones sucesivas del software, cada vez
ms completas.

MODELO TIPICO DE SEIS

REGIONES
A diferencia del modelo de proceso clsico que termina cuando se entrega el
software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la
vida del software de computadora.
Las regiones de tareas que componen este modelo son:
Comunicacin con el cliente: las tareas requeridas para establecer
comunicacin entre el desarrollador y el cliente.
Planificacin: las tareas requeridas para definir recursos, el tiempo y
otras informaciones relacionadas con el proyecto. Son todos los
requerimientos.
Anlisis de riesgos: las tareas requeridas para evaluar riesgos tcnicos y
otras informaciones relacionadas con el proyecto.
Ingeniera: las tareas requeridas para construir una o ms
representaciones de la aplicacin.
Construccin y adaptacin: las tareas requeridas para construir, probar,
instalar y proporcionar soporte al usuario.
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 implementacin durante la etapa de
instalacin.

MODELO WINWIN
El modelo en espiral WINWIN de Boehm, define un
conjunto de actividades de negociacin al principio de casa
paso alrededor de la espiral.
Identificacin del sistema o subsistemas clave de los
directivos.
Determinacin de las condiciones de victoria de los
directivos.
Negociacin de las condiciones de victoria de los
directivos para reunirlas en un conjunto de condiciones
para todos los afectados (incluyendo el equipo del
proyecto de software).

VENTAJAS
El modelo en espiral puede adaptarse y aplicarse a lo largo de
la vida del software de computadora.
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 nivele evolutivos.
El modelo en espiral permite a quien lo desarrolla aplicar el
enfoque de construccin de prototipos en cualquier etapa de
evolucin del producto.
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 problemas.
En la utilizacin de grandes sistemas a doblado la
productividad.

DESVENTAJAS

Resulta difcil convencer a grandes clientes de que el enfoque

evolutivo es controlable.
Debido a su elevada complejidad no se aconseja utilizarlo en
pequeos sistemas.
Genera mucho tiempo en el desarrollo del sistema
Modelo costoso
Requiere experiencia en la identificacin de riesgos

MODELO V
QUE ES?
Describe las actividades y los resultados que se
producen durante el desarrollo del software. El
Mtodo-V es una representacin grfica del ciclo de
vida del desarrollo del sistema. Cada fase tiene que
estar respaldada por su documento correspondiente
y test

OBJETIVOS
Minimizacin de los riesgos del
proyecto

Mejora y calidad del

proyecto

Mejora la transparencia del proyecto y

control del mismo. Describe los resultados
correspondientes y funciones de
responsabilidad. Permite una deteccin
temprana de las desviaciones y los riesgos
mejorando la gestin de procesos,
reduciendo as los riesgos del proyecto.

Como modelo de estndar,

asegura que los resultados que
se proporcionan sean
completos y que contengan la
calidad deseada.

Reduccin de los
gastos
Puede ser calculado,
estimado y controlado
mediante la aplicacin de un
modelo de procesos
estandarizados

Mejora la
comunicacin entre
todos los
inversionistas
Se reduce la perdida de
friccin entre el usuario,
comprador, proveedor y
desarrollador.

MODELO
EN V
Funcin
El modelo en V se encarga de representar las
relaciones temporalmente entre las fases del
ciclo de desarrollo del proyecto, en el se
realizan dos procesos al mismo tiempo hasta
llegar a la punta de la V.

NIVELES
El nivel 1 est orientado al
cliente. El nivel 2 se
dedica a las
caractersticas funcionales
del sistema propuesto.
El nivel 3 define los
componentes hardware y
software del sistema final,
a cuyo conjunto se
denomina arquitectura del
sistema.
El nivel 4 es la fase de
implementacin

Fase de verificacin
Anlisis de
requisitos
Se colectan los requisitos del
sistema y se analizan las
necesidades del usuario.

Anlisis de
requisitos
Se selecciona el puente
entre los
requerimientos y el
cdigo.

Diseo del
sistema
Se calcula cada
posibilidad y tcnica
que dichas
exigencias pudieran
ser ejecutadas

Diseo del
modulo
Codificar los
fragmentos del
sistema

Fase de validacin
Prueba de unidas

Prueba de integracin

Realizando el anlisis de cdigo se

descubren primero fallos. Si se corrigen se
har una reduccin de costos al proyecto
final.

Probar los mdulos separados

en conjunto para detectar
errores en interfaces

Prueba del sistema

Se utiliza los documentos
de diseo y se hace una
comparacin del sistema
producido hasta el
momento con el sistema
real.

Prueba de
aceptacin de
usuario
En caso de que no sea
aceptado se realizaran
los cambios segn las
necesidades originales.

GRACIAS