3. Modelo de Cascada
En resumen, los inconvenientes del
venerado modelo en cascada hacen que
sea, a menudo, un modelo poco
apropiado para un proyecto de
desarrollo rapido.
Incluso en los casos en los que las
ventajas del modelo en cascada pura
superan los inconvenientes, los
modelos de cascada modificada (con
retroceso) pueden funcionar mejor.
4. Las desventajas del modelo se centran en las
dificultades para especificar claramente los
requerimientos al comienzo del proyecto, antes
de que se realice ningún trabajo de diseno y
antes describir ningun codigo.
No proporciona resultados tangibles en forma
de software hasta el final del ciclo de forma
desoftware del ciclo de vida de algunas
herramientas, metodos y actividades que
abarcan varias etapas de la cascada; estas
actividades son dificiles de ajustar en las
etapas discontinuas del modelo para un
proyecto de desarrollo rapido, el modelo en
cascada puede suponer una cantidad excesiva de
5.
6. Ciclo de vida en 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
ingenieria. Es el primero de los propuestos y
el mas ampliamente seguido por las
organizaciones (se estima que el 90% de los
sistemas han sido desarrollados asi).Este
modelo admite la posibilidad de hacer
iteraciones, es decir, durante las
modificaciones que se hacen en el
mantenimiento se puede ver por ejemplo la
necesidad de cambiar algo en el diseno.
7. Modelo en espiral
Este es un modelo de proceso de software evolutivo
El cual enlaza la naturaleza interactiva de la contruiccion
De prototipos, pero conservando aquellas propiedades
De modelo de cascada.
El modelo de espiral fue desarrollado por Boehm,quien
Lo describe asi
*el modelo de desarrollo en espiral es un generador
De modelo de proceso guiado por el riesgo
Para q se emplea para conducir sistemas intensivos de
ingeniería de software concurrente y a la vez con muchos
usuarios.
8.
9. se caracteriza:
0 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.
0 Un conjunto de puntos de fijación para asegurar el
compromiso del usuario con soluciones de sistema
que sean factibles y mutuamente satisfactorias.
10. MODELO DE PROTOTIPO.
0 Aproximación al modelo basado en prototipos Es
habitual que en un proyecto software:
0 No se identifiquen los requisitos detallados de entrada,
procesamiento o salida. No se está seguro de la
eficiencia de un algoritmo, o de la forma en que se ha de
implantar la interface hombre-máquina. Lo habitual es
construir un PROTOTIPO que según la Real Academia
Española está definido como: 1. m. Ejemplar original o
primer molde en que se fabrica una figura u otra cosa. 2.
m. Ejemplar más perfecto y modelo de una virtud, vicio
o cualidad, que idealmente sirviera como mecanismo
para identificar los requisitos del software.
11. 0 es una visión
preliminar del modelo
0 un modelo operable-
fácilmente
0 ampliable y
modificable tiene todas
0 características
propuestas, pero
0 realmente es un
modelo básico que
0 tiene que ser mejorado.
12. SELECCIÓN DEL MODELO DE
PROTOTIPO
Este modelo es recomendado cuando:
Los requerimientos no son conocidos al
principio. Coloca énfasis en la etapa de
Especificación de Requerimientos a través
de la construcción de Prototipos que
aproximan al usuario a la idea final del
sistema con el propósito de poder clarificar
los requerimientos. Los usuarios lo prueban y
añaden requerimientos. Se hace una
implementación parcial del sistema y se
prueba. Se utiliza en sistemas complejos
13. VENTAJAS Y DESVENTAJAS
VENTAJAS
0 de la incertidumbre y del riesgo, reducción de tiempo y de
costos, incrementos en la aceptación del nuevo sistema,
mejoras en la administración de proyectos, mejoras en la
comunicación entre desarrolladores y clientes, etc.
Desventajas : la dependencia de las herramientas de
software para el éxito ya que la necesidad de disminución
de incertidumbre depende de las iteraciones del prototipo,
entre más iteraciones existan mejor y esto último se logra
mediante el uso de mejores herramientas lo que hace a
este proceso dependiente de las mismas. También, no es
posible aplicar la metodología a todos los proyectos de
software y, finalmente, la mala interpretación que pueden
hacer los usuarios del prototipo, al cual pueden confundir
con el sistema terminado.
14. PROCESO UNIFICADO RACIONAL
RUP es un proceso para el desarrollo de un
proyecto de un software que define claramente
quien, como, cuando y que debe hacerse en el
proyecto. Como 3 caracteristicas esenciales
esta dirigido por los Casos de Uso: que
orientan el proyecto a la importancia para el
usuario y lo que este quiere, esta centrado en
la arquitectura: que Relaciona la toma de
decisiones que indican como tiene que ser
construido el sistema y en que orden, y es
iterativo e incremental: donde divide el
proyecto en mini proyectos donde los casos de
uso y la arquitectura cumplen sus objetivos
15. Adaptacion del proceso
El proceso deberá adaptarse a las
caracteristicas propias de la organizacion. El
tamano del mismo, asi como las regulaciones
que lo condicionen, influiran en su diseno
especifico. Tambien se deberá tener en cuenta
el alcance del proyecto.
Balancear prioridades
Los requerimientos de los diversos inversores
pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe
encontrarse un balance que satisfaga los
16. Colaboracion entre equipos
El desarrollo de software no lo hace una unica
persona sino multiples equipos. Debe haber una
comunicacion fluida para coordinar
requerimientos, desarrollo, evaluaciones,
planes, resultados, etc.
Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un
modo interno, en etapas iteradas. En cada
iteracion se analiza la opinion de los
inversores, la estabilidad y calidad del
producto, y se refina la direccion del
17. Elevar el nivel de abstraccion
Este principio dominante motiva el uso de
conceptos reutilizables tales como patron del
software, lenguajes 4GL o esquemas
(frameworks) por nombrar algunos.
Enfocarse en la calidad
El control de calidad no debe realizarse al
final de cada iteraciOn, sino en todos los
aspectos de la producciOn.
El ciclo de vida de RUP
RUP divide el proceso en 4 fases, dentro de
las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que
se hace un mayor o menor hincapié en los
distintas actividades.
18. En las iteraciones de cada fase se hacen
diferentes esfuerzos en diferentes actividades
• Inicio: Se hace un plan de fases, se identifican
los principales casos de uso y se identifican los
riesgos. Se define el alcance del proyecto.
• Elaboracion: se hace un plan de proyecto, se
completan los casos de uso y se eliminan los riesgos.
• Construccion: se concentra en la elaboración de un
producto totalmente operativo y eficiente y el manual
de usuario.
• Transicion: se Instala el producto en el cliente y
se entrena a los usuarios. Como consecuencia de esto
suelen surgir nuevos requisitos a ser analizados.