MODULO I

MODULO I

1.3 MODELOS PRESCRIPTIVOS

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

Modelos prescriptivos
Modelos prescriptivos

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.

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 cascada
Modelo en cascada

Algunas veces llamado el ciclo de vida

clásico, sugiere un enfoque sistemático

secuencial
Comunicación hacia el desarrollo de software.
Inicio proyecto
Planeación
Se considera 5 etapas:
Recopilación req
estimación
itinerario
Modelado
seguimiento
análisis
Construcción
diseño
código
prueba
Despliegue
Entrega
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 incrementales
Modelos 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:

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.
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 #n

Entrega del n-ésimo

incremento

Incremento #2

Entrega del 2do.

Incremento #1
incremento
 Entrega del 1er.
incremento

Tiempo del calendario de proyecto

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.

 Equipo #n
Modelado
Modelado del negocio
Modelado de los datos
Modelado del proceso

construcción

Modelado
Equipo #2
Generación de código
Modelado del negocio
pruebas
Reutilización componentes
Modelado de los datos
comunicación
Modelado del proceso

construcción
planeación Modelado
Modelado del negocio Generación de código
Equipo #1 despliegue
Modelado de los datos pruebas
Reutilización componentes integración
Modelado del proceso
entrega

construcción retroalimentación

Generación de código
pruebas

Reutilización componentes
60 – 90 días
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 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 evolutivos
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.

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

comunicación
Modelado
Diseño rápido

Construcción
Desarrollo
del prototipo
Entrega y

retroalimentación
Modelo de construcción de prototipos
Desventajas

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

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 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.
 Estimación
Itinerario
Analisis de riesgos
Planeación
modelado
comunicación
Analisis
diseño
concepto

Desarrollo del
Reingeniería
Desarrollo de

la Nueva Aplicación
Mejora de

Entrega la Aplicación Codigo

Mantenimiento
retroalimentación
de la Aplicación
construcción

construcción
despliegue
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 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 proceso
Modelos especializados de proceso

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