ANALISIS DISEO DE SISTEMAS2 TICS G-2

Nombre del
modelo

Ventajas

*Comprar puede ahorrar

dinero en comparacin
con construir.
*El desarrollo se realiza a
un nivel de abstraccin
mayor

Modelo RAD

Desventajas

Caractersticas

*Comprar puede ser ms caro

que construir.
*Costo de herramientas
integradas y equipo
necesario.

*Equipos Hbridos

*Progreso ms difcil de medir.

*Herramientas
Especializadas

*Visibilidad temprana.

*Menos eficiente.

*Mayor flexibilidad.

*Menor precisin cientfica.

*Menor codificacin
manual.

*Riesgo de revertirse a las

prcticas sin control de
antao.

*Timeboxing

*Ms fallas (por sndrome de

"codificar a lo bestia").

*Prototipos
interactivos &
evolucionarios.

*Mayor involucramiento
de los usuarios.
*Posiblemente menos
fallas.
*Posiblemente menor
costo.
*Ciclos de desarrollo ms
pequeos.
*Interfaz grfica estndar

*Prototipos pueden no
escalar, un problema
maysculo.
*Funciones reducidas (por
"timeboxing").
*Dependencia en
componentes de terceros:
funcionalidad de ms o de
menos, problemas legales.

*Con un paradigma
incremental se reduce el
tiempo de desarrollo
inicial, ya que se
implementa la
funcionalidad parcial.

Metodologa
en desarroll
(Modelos flor
y modelo V)

*Tambin provee un
impacto ventajoso frente
al cliente, que es la
entrega temprana de
partes operativas del
software.
*El modelo proporciona
todas las ventajas del
modelo en Cascada
realimentado, reduciendo
sus desventajas slo al
mbito de cada
incremento.
*Resulta ms sencillo
acomodar cambios al
acotar el tamao de los
incrementos.

MODELO FLOR
*til
es cuando los
requerimientos son
cambiables.
*Cuando el usuario no se
quiere comprometer con
los requerimientos.
*Cuando no se conoce
bien la aplicacin.

Metodologa
en desarroll

*Cuando se quiere probar

una arquitectura o
tecnologa.

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

*Requiere de mucha
planeacin, tanto
administrativa como tcnica.

*Requiere de metas claras

para conocer el estado del
proyecto.

*El usuario se
involucra
completamente en
todas las etapas
MODELO FLOR
*No se conoce cuando
tengamos un producto
aceptable.
*No se sabe cuntas
iteraciones sern necesarias.
*Dan una falsa ilusin al
usuario sobre la velocidad del
desarrollo.
*Se puede volver al producto
aun y cuando no est con los
estndares.

*Se pueden realizar

pruebas durante el
proceso
*Se expone a
demasiado trabajo
*Implementacin
*Pruebas

*Calidad
*Calidad de
rendimiento
*Diseo

*Cuando se requiera

(Modelos flor
y modelo V)

rapidez en
el desarrollo.
MODELO V
*El modelo en V hace
ms explcita la tarea
parte de la iteracin de
las actividades del
proceso.
*Las pruebas de cada
fase ayudaran a corregir
posibles errores sin tener
que esperar a que sean
rectificados en la etapa
final del proceso.
*Con las pruebas
unitarias y de integracin
se consigue obtener
exactitud en los
programas

Modelo de
desarrollo en
espiral

*No requiere una

definicin completa de
los requerimientos del
software a desarrollar
para comenzar su
funcionalidad.

*En la terminacin de un
producto desde el final
de la primera iteracin es
muy factible aprobar los
requisitos.

Modelo de
desarrollo en

*Sufrir retrasos corre un

riesgo menor, porque se
comprueban los
conflictos presentados
tempranamente y existe

MODELO V
*Al encontrarse errores luego
de realizar las pruebas se
pierde tiempo y dinero, ya
que cada prueba se realiza
luego de haber terminado la
implementacin.

*Documentacin
*Mantenimiento
*Reingeniera

*Este modelo est relacionado

con el modelo de cascada,
pero el modelo V es ms
efectivo ya que puede con las
pruebas que se van haciendo
durante cada fase hacen
menos los errores por que
estos se pueden corregir al
momento, lo malo de estas
pruebas es que generan
muchos costos y tambin se
pierde tiempo para la entrega
al usuario final

*Existe complicacin cuando

se evala los riesgos.

*Determina los
objetivos

*Se requiere la participacin

continua por parte del cliente.

*Anlisis de riesgo
*Desarrolla, verifica &
valida

*Se pierde tiempo al volver

producir inicialmente una
especificacin completa de los
requerimientos cuando se
modifica o mejora el software.

*Planifica

*El riesgo es todo lo

que pueda salir mal en
un proyecto de
desarrollo de software.

espiral

la forma de poder
corregirlos a tiempo.

*Metodologa basada
en prueba y error.
*Programacin
organizada.

Programacin

*Es recomendable emplearlo

solo en proyectos a corto
plazo.

*Menor taza de errores.

extrema
*Satisfaccin del
programador.

*Altas comisiones en caso de

fallar.

*Fundamentada en
Valores y Prcticas.
*Expresada en forma
de 12 Prcticas
Conjunto completoSe
soportan unas a otras
Son conocidas desde
hace tiempo. La
novedad es juntarlas.