compendio de ingeniería del softwarecotana.informatica.edu.bo/downloads/modelos...
TRANSCRIPT
MODELOS PRESCRIPTIVOS
MODULO II
Gabinete de Auditoría de Sistemas CPA - 506
Resumen preparado por Miguel Cotaña 1
Los modelos prescriptivos de proceso
proporcionan estabilidad, control y
organización a una actividad que si no
se controla puede volverse caótica.
El proceso conduce a un equipo de
software a través de un conjunto de
actividades del marco de trabajo que se
organizan en un flujo de proceso, el cual
puede ser lineal, incremental o
evolutivo. 2
Se les llama “prescriptivos” porque
prescriben un conjunto de elementos del
proceso:
Actividades del marco de trabajo,
Acciones de la IS,
Tareas,
Productos del trabajo,
Aseguramiento de la calidad,
Mecanismos de control del cambio para
cada proyecto.
3
Modelo en cascada
Algunas veces llamado el ciclo de vida
clásico, sugiere un enfoque sistemático
secuencial hacia el desarrollo de software.
Se considera 5 etapas:
Construcción
código
prueba
Comunicación
Inicio proyecto
Recopilación req Planeación
estimación
itinerario
seguimiento Modelado
análisis
diseño
Despliegue
Entrega
Soporte
retroalimentacion
4
Entre los problemas al aplicar el modelo:
1.- Son raros los proyectos que siguen un
flujo secuencial, a pesar de que el modelo
lineal incluye iteraciones, lo hace de manera
indirecta.
2.- Con frecuencia es difícil para el cliente
especificar todos los requisitos de manera
exacta.
3.- El cliente debe tener paciencia. Una
versión estará disponible sólo cuando el
proyecto esté muy avanzado.
5
El modelo en cascada conduce a
“estados de bloqueo” (Bradac) en los
cuales algunos miembros del equipo
deben esperar a otros para terminar
tareas dependientes.
Sin embargo, sirve como modelo de
proceso útil en situaciones donde los
requerimientos son claros y completos y
donde el trabajo se realiza, hasta su
conclusión, de una manera lineal. 6
El modelo incremental aplica secuencias
lineales de manera escalonada conforme
avanza el tiempo en el calendario. Cada
secuencia lineal produce “incrementos”
del software.
Se debe tener en cuenta que el flujo del
proceso de cualquier incremento puede
incorporar el paradigma de construcción de
prototipos.
El modelo incremental:
7
Modelos de procesos incrementales
Al utilizar el modelo incremental, el primer
incremento es un “producto esencial”, se
incorporan requisitos básicos. Este producto
queda en manos del cliente (o se somete a
una evaluación). Como resultado de la
evaluación se desarrolla un plan para el
siguiente incremento. El plan afronta la
modificación del producto esencial afin de
satisfacer necesidades del cliente. Este
procesos se repite hasta la entrega final.
8
Combina elementos del modelo en cascada
aplicado en forma iterativa.
Incremento #1
Entrega del 1er.
incremento
Incremento #2
Entrega del 2do.
incremento
Incremento #n
Entrega del n-ésimo
incremento
Tiempo del calendario de proyecto
Funcio
nalidad y
cara
cté
rísticas d
el Sw
9
El modelo DRA
El Desarrollo Rápido de Aplicaciones es un
modelo de proceso de software incremental
que resalta un ciclo de desarrollo corto. El
modelo DRA es una adaptación a “alta
velocidad” del modelo en cascada en el
que se logra el desarrollo rápido mediante
un enfoque de construcción basado en
componentes. Si se entiende los requisitos y
el dominio del proyecto. El proceso DRA
permite crear un sistema completamente
funcional dentro de un periodo muy corto. 10
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso
construcción
Reutilización componentes
Generación de código
pruebas
construcción
Reutilización componentes
Generación de código
pruebas
construcción
Reutilización componentes
Generación de código
pruebas
despliegue
integración
entrega
retroalimentación
60 – 90 días
planeación
comunicación
Equipo #1
Equipo #2
Equipo #n
11
Las restricciones de tiempo impuestas
sobre un proyecto DRA exigen ámbito de
escalas.
Si una aplicación de negocios se puede
modular de forma que cada gran función
pueda completarse en menos de tres
meses, ésta es una candidata para el
DRA. Cada gran función se puede
abordar mediante un equipo de DRA por
separado, para después integrarlas y
formar un todo. 12
Modelos de procesos evolutivos
El software, al igual que todos los sistemas
complejos, evolucionan con el tiempo. Los
requisitos de los negocios y productos a
menudo cambian conforme se realiza el
desarrollo; por lo tanto, la ruta lineal que
conduce a un producto final no será real;
las fechas tope del mercado imposibilitan la
conclusión de un producto completo.
13
Construcción de prototipos
Con frecuencia un cliente define un conjunto de
objetivos generales para el software, pero no
identifica los requisitos detallados de entrada,
procesamiento o salida. En otros casos, el
responsable del desarrollo de software está
inseguro de la eficacia de un algoritmo, de la
adaptabilidad de un SO. En estas y en otras
situaciones , un paradigma de construcción
de prototipos puede ofrecer el mejor enfoque
14
Un prototipo se puede usar de manera
independiente, se emplea más
comúnmente como una técnica que puede
implementarse dentro del contexto de
cualquiera de los modelos de proceso.
La construcción de prototipos ayuda al IS
y al cliente a entender de mejor manera
cuál será el resultado de la construcción
cuando los requisitos estén satisfechos.
15
La construcción de prototipos se inicia con
la comunicación. El IS y el cliente
encuentran y definen los objetivos globales
para el software, identifican los requisitos
conocidos y las áreas del esquema en
donde es necesaria más definición.
Entonces se plantea con rapidez una
iteración de construcción de prototipos y se
presenta el modelo (en la forma de un
diseño rápido).
16
El diseño rápido se centra en una
representación de aquellos aspectos del
software que serán visibles para el cliente
(por ejemplo, la configuración de la interfaz
con el usuario y el formato de los
despliegues de salida). El diseño rápido
conduce a la construcción de un prototipo.
Después, el prototipo lo evalúa el cliente y
con la retroalimentación se refinan los
requisitos del software que se desarrollará.
17
La iteración ocurre cuando el prototipo se
ajusta para satisfacer las necesidades del
cliente.
De manera ideal, el prototipo debería servir
como un mecanismo para identificar los
requisitos del software. Si se construye un
prototipo de trabajo, el desarrollador
intenta emplear los fragmentos del
programa ya existentes o aplica
herramientas que permita producir
programas de trabajo con rapidez. 18
Plan rápido
Modelado
Diseño rápido
Construcción
del prototipo Desarrollo
Entrega y
retroalimentación
comunicación
Modelo de construcción de prototipos 19
20
Identificar los requerimientos
Desarrollar un prototipo
Utililizar el prototipo
Usuario satisfecho?
Revisar y mejorar el prototipo
Prototipo funcional
NO SI
a) El cliente ve lo que parece una versión en
funcionamiento del software, sin saber
que el prototipo (por la prisa de hacerlo
funcionar) no considera calidad y
facilidad de mantenimiento a largo plazo.
b) Frecuentemente, el desarrollador
establece compromisos de
implementación para lograr que el
prototipo funcione con rapidez
Desventajas
21
El modelo en espiral
El modelo en espiral que Boehm propuso
originalmente, es un modelo de proceso de
software evolutivo que conjuga la
naturaleza iterativa de la construcción de
prototipos con los aspectos controlados y
sistemáticos del modelo en cascada.
Proporciona el material para el desarrollo
rápido de versiones incrementales del
software.
22
Cuando se aplica el modelo en espiral, el
software se desarrolla en una serie de
entregas evolutivas. Durante las
primeras iteraciones, la entrega tal vez
sea un documento del modelo o un
prototipo. Durante las últimas
iteraciones se producen versiones cada
vez mas completas del sistema
desarrollado.
23
Un proceso en espiral se divide en un
conjunto de actividades del marco de
trabajo que define el equipo de IS.
Cada una de las actividades del marco de
trabajo representa un segmento de la ruta
en espiral. Cuando comienza este proceso
evolutivo el equipo de software realiza
actividades implicadas en un circuito
alrededor de la espiral y que se inicia desde
el centro. 24
comunicación
Planeación
construcción despliegue
modelado
Entrega
retroalimentación
Codigo
construcción
Analisis
diseño
Estimación
Itinerario
Analisis de riesgos
Reingeniería
Mantenimiento
de la Aplicación
Mejora de
la Aplicación
Desarrollo de
la Nueva Aplicación
Desarrollo del
concepto
25
El factor riesgo es considerado en cada
revolución. Los puntos de fijación (una
combinación de productos de trabajo y
condiciones incluidas a lo largo de la ruta de la
espiral) se consideran para cada paso
evolutivo.
El primer circuito alrededor de la espiral quizá
genere el desarrollo de una especificación del
producto; los pasos siguientes se pueden
aprovechar para desarrollar un prototipo y
después, en forma progresiva, versiones más
elaboradas del software. 26