Modelo Prescriptivos de proceso - ti

Report
Modelo Prescriptivos de
proceso
Modelos Prescriptivos
•
•
•
•
•
Cualquier organización de ingeniería de software debe describir un conjunto de actividades dentro del
marco de trabajo para el o los procesos que adopte.
También debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería.
Y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo y los productos de
trabajo, que deben alcanzarse para alcanzar las metas de desarrollo.
Después la organización debe adoptar el modelo de procesos resultante y ajustarlo a la naturaleza
específica de cada proyecto, personas y ambiente en donde se ejecutará el trabajo.
Sin importar el modelo de proceso seleccionado, los ingenieros de software han elegido de manera general
un marco de trabajo genérico para el proceso que incluye las siguientes actividades: comunicación,
planeación, modelado, construcción y desarrollo.
¿Por qué se les llama modelo prescriptivos?
• Se les llama “prescriptivos”, por que
prescriben un conjunto de elementos del
proceso: actividades de marco de trabajo,
acciones de ingeniería del software,
tareas, productos de trabajo,
aseguramiento de la calidad y
mecanismos de control de cambio para
cada proyecto.
Flujo de trabajo
• Cada modelo de proceso
prescribe un flujo de
trabajo; esto es, la forma en
que los elementos del
proceso se interrelacionan
entre si.
Modelo de cascada
• Existen ocasiones en que los requisitos de un problema se entienden de
manera razonable: cuando el trabajo fluye desde la comunicación hasta
despliegue de manera lineal.
• El modelo cascada algunas veces llamado ciclo de vida clásico, sugiere un
enfoque sistemático secuencial hacia el desarrollo del software, que se
inicia con la especificación de requerimientos del cliente y que continúa con
la planeación el modelado, la construcción y el despliegue para terminar con
el soporte del software terminado.
Modelo cascada
• Este modelo se aplica en situaciones de actualización de un software, como un sistema contable
cuando el gobierno ha dictado nuevas regulaciones.
• También se aplica a un número limitado de nuevos proyectos, solamente cuando están bien
definidos los requerimientos y son estables en forma razonable.
Problemas al aplicar el modelo de cascada
•
•
•
•
•
Es muy raro que los proyectos reales sigan el flujo secuencial que propone el
modelo.
Con frecuencia es difícil para el cliente establecer todos los requisitos de manera
explícita.
El cliente debe tener paciencia. Una versión que funcione del programa estará
disponible cuando el poryecto esté muy avanzado.
En la actualidad el trabajo de software está acelerado y sujeto a una cadena infinita
de cambios (de características, funciones y contenido de la información). Con
frecuencia el modelo de cascada no es apropiado para dicho trabajo.
El modelo de cascada puede ser útil en situaciones donde los requerimientos están
fijos y donde el trabajo se realiza hasta su conclusión de una manera lineal
Modelos de procesos incrementales
• El modelo incremental
• El modelo DRA (Desarrollo
Rápido de Aplicaciones)
Modelo incremental
•
•
•
El modelo incremental combina elementos del modelo cascada aplicado en forma iterativa
Como se muestra en la figura 3.2 el modelo incremental aplica secuencias lineales de manera
escalonada conforme avanza el tiempo en el calendario
Cada secuencia lineal produce incrementos de software.
Modelo incremental
•
•
•
•
•
En el modelo incremental el primer incremento es un producto esencial (se incorporan los
requisitos básicos, pero muchas características suplementarias no se incorporan.
El producto esencial queda en manos del cliente (o se somete a una evaluación detallada)
Como resultado de la evaluación se elabora un plan para el incremento siguiente
El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor
manera la necesidad del cliente y la entrega de características y funcionalidad adicionales.
Este proceso se repite después de la entrega de cada incremento mientras no se haya
elaborado el producto completo
El modelo DRA
• El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso de
software incremental que resalta un ciclo de desarrollo corto.
• El DRA es una adaptación de “alta velocidad” del modelo de cascada en el
que se logra el desarrollo rápido mediante un enfoque de construcción
basado en componentes
• Si se entienden bien los requisitos y se limita el ámbito del proyecto DRA
permite que un equipo de desarrollo cree un “sistema completamente
funcional” en un periodo corto de tiempo (60 a 90 días)
• La comunicación trabaja para entender el problema de negocios y las
características de información que debe incluir el software.
• La planeación se orienta para que varios equipos de software trabajen en
paralelo sobre diferentes funciones del sistema.
• El modelado incluye tres grandes fases –modelado de negocios, modelado
de datos y modelado de proceso- y establece representaciones del diseño
que sirve como base para la actividad de construcción del modelo DRA.
• La construcción resalta el empleo de componentes de software existente y la
aplicación de la generación automática de código.
• Por último el despliegue establece la base para las iteracciones subsecuentes
si estas son necesarias.
Inconvenientes del modelo DRA
1.
Para proyectos grandes, pero escalables, el DRA necesita suficientes
recursos humanos para crear el número correcto de equipos DRA
2. Si los desarrolladores y clientes no se comprometen con las actividades
rápidas necesarias para completar el sistema en un marco de tiempo muy
breve los proyectos de DRA fallarán.
3.
Si un sistema no se puede modular en forma apropiada, la construcción de
los componentes necesarios para el DRA será problemática.
Modelo de procesos evolutivos
•
•
•
•
El software como todos los sistemas
complejos evolucionan con el tiempo
Los requisitos de los negocios y productos a
menudo cambian como se realiza el desarrollo
Por lo tanto la ruta lineal que conduce a un
producto final no será real
Las estrictas fechas tope del mercado
imposibilitan la conclusión de un producto
completo, por lo que se tiene que presentar
una versión limitada para liberar la presión
competitiva y de negocios.
Modelo de procesos evolutivos
•
•
En esta y otra situaciones similares, los
ingenieros de software necesitan un modelo
de proceso que haya sido diseñado de
manera explícita para incluir un producto
que evolucione con el tiempo.
Los modelos evolutivos son interactivos; los
caracteriza la forma en que permiten que los
ingenieros de software desarrollen
versiones
Construcción de prototipos
• A menudo un cliente define un conjunto de objetivos generales para el
software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida.
• El responsable del desarrollo del software esta inseguro de la eficacia de un
algoritmo.
• En estas y otras situaciones un paradigma de construcción de prototipos
puede ofrecer el mejor enfoque.
El paradigma de la construcción de
prototipos ayuda al ingeniero de sistemas y
al cliente a entender de mejor manera cuál
será el resultado de la construcción
cuando los requisitos estén satisfechos.
Construcción de prototipos …
•
•
•
Se inicia con la comunicación. El
ingeniero de software y el cliente
encuentran y definen los objetivos
globales para el software.
Identifican los requisitos conocidos y las
áreas del esquema en donde es mas
necesaria mas definición.
Entonces se plantea con rapidez una
interacción de construcción de
prototipos y se presenta el modelado (en
la forma de un diseño rápido.
Construcción de prototipos…
•
•
•
•
El diseño rápido se centra en una
representación de aquellos aspectos del
software que serán visibles para el cliente
o el usuario final (por ejemplo, la
configuración de la interfaz con el usuario
y los formatos de despliegue de salida
El diseño rápido conduce a la
construcción de un prototipo.
Después el prototipo es evaluado por el
cliente y con la retroalimentación se
refinan los requisitos del software que se
desarrollará.
La Interacción ocurre cuando el prototipo
se ajusta para satisfacer las necesidades
del cliente.
¿qué se debe hacer con el prototipo?
• En la mayoría de los proyectos, el primer sistema construido apenas se
utiliza. Tal vez sea demasiado lento, muy grande o torpe en su uso, o reuna
las tres características a la vez.
• No existe otra opción que comenzar de nuevo, aunque sea doloroso, es lo
mejor, y construir una revisión rediseñada en la que se resuelvan estos
problemas…
Problema de la construcción de prototipos
• El cliente ve lo que parece una versión en funcionamiento del software, sin
saber que el prototipo está unido con “chicle y cable para embalaje”, que por
la prisa de hacerlo funcionar no se ha considerado la calidad del software
global o la facilidad de mantenimiento a largo plazo.
• A menudo el desarrollador establece compromisos de implementación para
lograr que el prototipo funcione con rapidez. Tal vez se utilice un sistema
operativo o lenguaje de programación inadecuado solo por que es conocido
y esta disponible.

similar documents