1.3 modelos prescriptivoscotana.informatica.edu.bo/downloads/microsoft... · organizan en un flujo...
TRANSCRIPT
1.3 MODELOS PRESCRIPTIVOS
MODULO IMODULO I
Los modelos prescriptivos de proceso
se propusieron originalmente para
ordenar el caos del desarrollo de
software. Estos modelos
convencionales han traído consigo
cierta cantidad de estructuras útiles.
El trabajo de la IS y el producto
resultante aún permanecen “al borde
del caos”
Los modelos prescriptivos de proceso
definen un conjunto distinto de
actividades, acciones, tareas
fundamentos y productos de trabajo
que se requieren para desarrollar
software de alta calidad.
Estos modelos son una guía para el
trabajo de la IS.
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.
Los productos de trabajo son los
programas, documentos y datos.
Existen mecanismos para la evaluación
del proceso de software que permite a las
organizaciones determinar la “madurez”
del conjunto de procesos.
Los mejores indicadores de la eficacia del
proceso que se utiliza son la calidad, el
tiempo de entrega y la viabilidad a largo
plazo del producto que se construye
Cualquier organización de IS debe
describir un conjunto único de actividades
dentro del marco de trabajo.
También debe llenar cada actividad del
marco de trabajo con un conjunto de
acciones de IS, y definir cada acción en
cuanto a un conjunto de tareas que
identifique el trabajo (y los productos del
trabajo) que deben completarse para
alcanzar las metas de desarrollo.
Modelos prescriptivosModelos prescriptivos
Luego, la organización debe adaptar
el modelo de proceso resultante y
ajustarlo a cada proyecto, a las
personas que lo realizarán, y el
ambiente en el que se ejecutará el
trabajo. Sin importar el modelo de
proceso seleccionado, los ingenieros
de software han elegido de manera
tradicional un marco de trabajo.
El marco de trabajo incluye:
Comunicación,
Planeación,
Modelado,
Construcción,
Despliegue.
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.
Cada modelo de proceso
prescribe también un “flujo de
trabajo”; esto es, la forma en
la cual los elementos del
proceso se interrelacionan
entre sí.
Modelo en cascadaModelo 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ónestimación
itinerario
seguimientoModelado
análisis
diseño
DespliegueEntrega
Soporte
retroalimentacion
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.
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.
Modelos de procesos incrementalesModelos de procesos incrementales
En algunas ocasiones los requisitos iniciales
del software están bien definidos en forma
razonable, pero el enfoque global del
esfuerzo de desarrollo excluye un proceso
puramente lineal. Además existe la
necesidad de proporcionar en forma rápida
un conjunto limitado de funcionalidad para
el usuario y después refinarla y expandirla
en las entregas posteriores. Entonces, en
estos casos se elige el modelo incremental.
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:El modelo incremental:
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.
Este modelo se enfoca en la entrega de un
producto operacional con cada
incremento. Los primeros incrementos son
versiones incompletas del producto final,
pero proporcionan al usuario la
funcionalidad que necesita y una
plataforma para evaluarlo.
El modelo incremental es útil sobre todo
cuando el personal necesario para una
implementación completa no está
disponible
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
Funcionalidad y caractérísticas del Sw
El modelo DRAEl 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.
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
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.
Inconvenientes del DRAInconvenientes del DRA
1) Para proyectos grandes, pero escalables,
el DRA necesita suficientes recursos
humanos para crear el número correctos
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 DRA fallarán.
3) Si un sistema no se puede modular en
forma apropiada, la construcción de
componentes necesarios será
problemática.
4) Si el alto rendimiento es un aspecto
importante, y se alcanzará al convertir
interfases en componentes del sistema,
el enfoque DRA podría no funcionar.
5) El DRA sería inapropiado cuando los
riesgos técnicos son altos.
Modelos de procesos evolutivosModelos 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.
Por lo que se debe presentar una versión
limitada para liberar la presión competitiva
y de negocios; se tiene claro un conjunto de
requisitos del producto o sistema esencial.
Pero todavía se deben definir los detalles de
las extensiones del producto. Por lo que se
necesita un modelo de proceso que haya
sido diseñado de manera explícita para
incluir un producto que evoluciones con el
tiempo
Construcción de prototiposConstrucció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
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.
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).
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á.
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.
Plan rápido
Modelado
Diseño rápido
Construcción
del prototipoDesarrollo
Entrega y
retroalimentación
comunicación
Modelo de construcción de prototipos
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
DesventajasDesventajas
Sin embargo, la construcción de prototipos
puede ser un paradigma efectivo para la IS.
La clave es definir las reglas de juego desde
el principio; es decir, el cliente y el
desarrollador se deben poner de acuerdo en
que el prototipo se construya y sirva como
un mecanismo para la definición de
requisitos, en que se descarte, al menos en
parte y que luego será desarrollado el
software real con enfoque hacia la calidad.
El modelo en espiralEl 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.
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.
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.
comunicación
Planeación
construccióndespliegue
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
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.
El modelo en espiral es un enfoque realista
para el desarrollo de software y de sistemas
a gran escala. Como el software evoluciona
conforme avanza el proceso, el
desarrollador y el cliente entienden y
reaccionan de mejor manera ante los
riesgos en cada etapa evolutiva. Este
modelo emplea la construcción de
prototipos para reducir riesgos en cualquier
etapa evolutiva del producto
El modelo de desarrollo concurrenteEl modelo de desarrollo concurrente
Llamado algunas veces ingeniería concurrente,
se representa en forma esquemática como una
serie de actividades del marco de trabajo,
acciones y tareas de la IS y sus estados
asociados.
El modelo de proceso concurrente define una
serie de eventos que dispararán transiciones de
estado para cada una de las actividades,
acciones o tareas de IS.
El modelo de proceso concurrente se aplica
a todos los tipos de desarrollo de software y
proporciona una visión exacta del estado
actual de un proyecto, definiendo una red
de actividades. Cada actividad, acción o
tarea en la red existe de manera simultanea
con otras actividades, acciones o tareas.
Los eventos generados en un punto de la
red del proceso disparan transiciones entre
los estados
Modelos especializados de procesoModelos especializados de proceso
Desarrollo basado en componentesDesarrollo basado en componentes
Los nuevos componentes de software
comerciales (NCSC), desarrollados por
vendedores que los ofrecen como productos, se
pueden emplear cuando el software está en
proceso de construcción. Estos componentes
proporcionan funcionalidad dirigida con
interfaces bien definidas que permiten que el
componente se integre en el software.
El modelo de desarrollo basado en
componentes (DBC) incorpora muchas de las
características del modelo en espiral. Es
evolutivo por naturaleza y exige un enfoque
iterativo para la creación del software.
Sin embargo, el modelo configura aplicaciones
a partir de componentes de software
empaquetados previamente.
Las actividades de modelado y construcción
comienzan con la identificación de los
componentes candidatos. Estos componentes
se pueden diseñar como módulos de software
convencionales o como clases o paquetes de
clases orientados a objetos. Sin importar la
tecnología que se aplique en la creación de
componentes.
El modelo de desarrollo basado en
componentes incorpora los siguientes pasos
(implementados mediante un enfoque
evolutivo):
Los productos basados en componentes
disponibles se investigan y evalúan para el
dominio de aplicación en cuestión
Se consideran los aspectos de integración
de componentes.
Se diseña una arquitectura de software
para adaptar los componentes.
Los componentes se integran en la
arquitectura.
Se realizan pruebas detalladas para
asegurar una funcionalidad apropiada.
El modelo de desarrollo basado en
componentes conduce a la reutilización del
software, que proporciona beneficios a los
ingenieros de software.
Con base en estudios de reutilización, QSM
Associates, informa que el ensamblaje de
componentes conduce a:
Una reducción de 70% del ciclo de
desarrollo
84% del costo del proyecto y un índice de
productividad de 26,2, comparado con una
norma de la industria de 16,9.
Por lo que el modelo de desarrollo basado en
componentes proporciona ventajas
significativas para los ingenieros de software.
Comprende un conjunto de actividades que
conducen a la especificación matemática del
software de computadora. Los métodos
formales permiten que un ingeniero de
software especifique, desarrolle y verifique un
sistema basado en computadora al aplicar una
notación matemática rigurosa.
Algunas organizaciones de desarrollo de
software aplican en la actualidad una variación
de este enfoque, llamado ingeniería de
software de sala limpia.
Cuando se utilizan métodos formales durante
el desarrollo, éstos proporcionan un
mecanismo para eliminar muchos de los
problemas difíciles de superar con otros
paradigmas de la IS. La ambigüedad, el
estado incompleto y la inconsistencia se
descubren y corrigen con mayor facilidad
(mediante la aplicación de un análisis
matemático).
Este modelo ofrece la promesa de un
software libre de defectos.
Sin embargo, existe dudas sobre su
aplicabilidad en su entorno de gestión:
El desarrollo de modelos formales es muy
caro y consume mucho tiempo.
Se requiere una capacitación detallada,
debido a que pocos responsables del
desarrollo de software cuentan con los
antecedentes necesarios para aplicar
métodos formales.
Es difícil la utilización de estos modelos
como un mecanismo de comunicación con
los clientes.
Desarrollo del software orientado a aspectosDesarrollo del software orientado a aspectos
Independientemente del proceso de
software que se elija, los constructores de
software complejo implementan de manera
invariable un conjunto específico de
características, funciones y contenido de
información. Estas características
específicas del software se modelan como
componentes (por ejemplo, clases
orientadas a objetos) y después se
construyen dentro del contexto de una
arquitectura de sistema.
Conforme los sistemas basados en
computadora se vuelven más elaborados (y
complejos), ciertos “intereses” abarcan
toda la arquitectura. Algunos intereses son
propiedades de alto nivel de un sistema
(por ejemplo, seguridad, falta de
tolerancia). Otros intereses afectan las
funciones (como la palicación de reglas de
negocios), mientras que otros son
sistemáticos (como la sincronización de
tareas o la gestión de memoria).
Cuando los intereses se relacionan con
múltiples funciones, características e
información del sistema, con
frecuencia se denominan “intereses
generales”. Los requerimientos de
aspectos definen estos intereses
generales que ejercen un impacto a
través de la arquitectura del software.
El desarrollo de software orientado a
aspectos (DSOA), referido con frecuencia
como programación orientada a
aspectos (POA), es un paradigma de la IS
relativamente nuevo que proporciona un
proceso y enfoque metodológico para
definir, especificar, diseñar y construir
aspectos (mecanismos más allá de
subrutinas y legados para localizar la
expresión de un interés general)
Grundy explica con profundidad los
aspectos en el contexto de lo que él llama
ingeniería de componentes orientada a
aspectos (ICOA):
La ICOA utiliza un concepto de capas
horizontales a través de componentes de
software descompuestos en forma vertical,
llamados “aspectos” para caracterizar
propiedades generales de los componentes,
los cuales pueden ser funcionales y no
funcionales.
Por lo general, los aspectos sistémicos
incluyen:
Interfases con el usuario,
Trabajo en colaboración,
Distribución,
Persistencia,
Gestión de memoria,
Procesamiento de transiciones,
Seguridad,
Integridad
Los componentes pueden proporcionar o
requerir uno o más “detalles de aspecto”
relacionados con un aspecto particular,
como:
Mecanismo de visión,
acceso extensible,
Tipo de interfase (aspectos de la
interfase con el usuario),
Generación,
Transportación,
Recepción de eventos (aspectos de
distribución),
Almacenamiento/recuperación e
indización de datos (persistencia),
Autenticación,
Codificación y derechos de acceso
(aspectos de seguridad),
Atomicidad de la transacción,
Control de concurrencia,
Control de transporte (aspectos de
transición).
Lamentablemente, hasta ahora no se ha
concretado un proceso orientado a aspectos
diferente. Es probable que tal proceso adopte
características de los modelos en espiral y
concurrente. La naturaleza evolutiva del
modelo en espiral es apropiada cuando se
identifican y construyen los aspectos. La
naturaleza paralela del desarrollo concurrente
es esencial por que los aspectos se desarrollan
de manera independiente de los componentes
del software.