Modelos de desarrollo de software separata

marfonline@gmail.com UGB San Miguel Lic. Marvin Romero

MODELOS DE PROCESOS
DESARROLLO DE SOFTWARE
EL MODELO EN CASCADA

El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere

el o
un enfoque sistemático, secuencial hacia el desarrollo del software, que se

igu er
inicia con la especificación de requerimientos del cliente y que continúa con
M om
la planeación, el modelado, la construcción y el despliegue para culminar en
el soporte del software terminado.
El modelo en cascada es el paradigma más antiguo para la ingeniería del
an R

software. Sin embargo, en las décadas pasadas.
, S rvin

Problemas:
GB a

1. Es muy raro que los proyectos reales sigan el flujo secuencial que
U c. M

propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo
hace de manera indirecta. Como resultado, los cambios confunden
mientras el equipo de proyecto actúa.
Con frecuencia es difícil para el cliente establecer todos los requisitos de
Li

2.
manera explícita. El modelo en cascada lo requiere y se enfrentan
dificultades al incorporar la incertidumbre natural presente en el inicio de
muchos proyectos.
3. El cliente debe tener paciencia. Una versión que funcione de los
programas estará disponible cuando el proyecto esté muy avanzado. Un
error grave será desastroso si no se detecta antes de la revisión del
programa.

En la actualidad, el trabajo del 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 en cascada no es apropiado para
dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en
situaciones donde los requerimientos están fijos y donde el trabajo se
realiza, hasta su conclusión, de una manera lineal.

www.miceminfo.net Busca en FB como CEMINFO Blog, Foros, y más...


MODELO INCREMENTAL

el o
igu er
M om
an R
El modelo incremental combina elementos del modelo en cascada aplicado en
forma iterativa. El modelo incremental aplica secuencias lineales de manera
, S rvin

escalonada conforme avanza el tiempo en el calendario. Cada secuencia
lineal produce "incrementos" del software. Por ejemplo, el software
procesador de texto, desarrollado con el paradigma incremental en su
GB a

primer incremento, podría realizar funciones básicas de administración de
U c. M

archivos, edición y producción de documentos; en el segundo incremento,
ediciones más sofisticadas, y tendría funciones más complejas de
producción de documentos; en el tercer incremento, funciones de corrección
Li

ortográfica y gramatical; y en el cuarto, capacidades avanzadas de
configuración de página.

El modelo de proceso incremental, al igual que la construcción de prototipos
y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de
la construcción de prototipos, el modelo incremental 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 desarrollo incremental es útil sobre todo cuando el personal necesario
para una implementación completa no está disponible. Los primeros
incrementos se pueden implementar con menos gente. Si el producto
esencial es bien recibido se agrega (si se requiere) más personal para
implementar el incremento siguiente. Además, los incrementos se pueden
planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande
podría requerir la disponibilidad de un hardware nuevo que está en
desarrollo y cuya fecha de entrega es incierta. Sería posible planear los
primeros incrementos de forma que se evite el uso de este hardware, lo que



permitiría la entrega de funcionalidad parcial a los usuarios finales sin
retrasos desordenados.

MODELO DRA

el o
igu er
M om
an R
, S rvin
GB a
U c. M
Li

El desarrollo rápido de aplicaciones (DRA) 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 entienden bien los requisitos y se limita el ámbito del
proyecto, el proceso DRA permite que un equipo de desarrollo cree un
"sistema completamente funcional" dentro de un periodo muy corto (por
ejemplo, de 60 a 90 días).

Como otros modelos de proceso, el enfoque DRA cumple con las actividades
genéricas del marco de trabajo que ya se han presentado. 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 es esencial porque
varios equipos de software trabajan en paralelo sobre diferentes funciones
del sistema. El modelado incluye tres grandes fases —modelado de negocios,



modelado de datos y modelado del proceso— y establece representaciones
del diseño que sirven 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 una base para las iteraciones subsecuentes, si éstas
son necesarias.

Si una aplicación de negocios se puede modular de forma que cada gran
función pueda completarse en menos de tres meses (mediante la aplicación
del enfoque ya descrito), é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.

Como todos los modelos de proceso, el enfoque DRA tiene inconvenientes

1) para proyectos grandes, pero escalables, el DRA necesita suficientes
recursos humanos para crear el número correcto de equipos DRA;

el o
2) si los desarrolladores y clientes no se comprometen con las actividades

igu er
rápidas necesarias para completar el sistema en un marco de tiempo muy
breve, los proyectos de DRA fallarán;
M om
3) si un sistema no se puede modular en forma apropiada, la construcción de
an R

los componentes necesarios para el DRA será problemática;
, S rvin

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;
y
GB a
U c. M

5) el DRA sería inapropiado cuando los riesgos técnicos son altos (por
ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).
Li



MODELOS EVOLUTIVOS
Los modelos evolutivos son iterativos; los caracteriza la forma en que
permiten que los ingenieros de software desarrollen versiones cada vez más
completas del software.

• CONSTRUCCIÓN DE PROTOTIPOS

• MODELO EN ESPIRAL

• MODELO DE DESARROLLO CONCURRENTE

CONSTRUCCION DE PROTOTIPOS

el o
igu er
M om
an R
, S rvin
GB a
U c. M
Li

A menudo 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 del
software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de



un sistema operativo o de la forma que debería tomar la interacción
humano-máquina. En éstas, y en muchas otras situaciones, un paradigma de
construcción de prototipos puede ofrecer el mejor enfoque.

A pesar de que la construcción de prototipos se puede utilizar como un
modelo de proceso independiente, se emplea más comúnmente como una
técnica susceptible de implementarse dentro del contexto de cualquiera de
los modelos de proceso expuestos en este capítulo. Sin importar la forma en
que éste se aplique, el paradigma de 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.

El paradigma de 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 necesaria más definición. Entonces se plantea con rapidez una
iteración de construcción de prototipos y se presenta el modelado (en la
forma de un diseño rápido). El diseño rápido se centra en una representación

el o
de aquellos aspectos del software que serán visibles para el cliente o el

igu er
usuario final (por ejemplo, la configuración de la interfaz con el usuario y el
M om
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
an R
cliente/usuario y con la retroalimentación se refinan los requisitos del soft-
ware que se desarrollará. La iteración ocurre cuando el prototipo se ajusta
, S rvin

para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo
el desarrollador entienda mejor lo que se debe hacer.
GB a

De manera ideal, el prototipo debería servir como un mecanismo para
U c. M

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 (como generadores de informes,
administradores de ventanas, etcétera) que permiten producir programas de
Li

trabajo con rapidez.

Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito
descrito? Brooks ofrece una respuesta:

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
reúna 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... Cuando se aplica un
concepto nuevo de sistema o una tecnología nueva, se tiene que construir
un sistema inservible y que sea necesario desechar, porque incluso la
mejor planeación no es omnisciente como para que el sistema esté
perfecto desde la primera vez. Por lo tanto, la pregunta de la
administración no es si debe construirse un sistema piloto y desecharlo.
Esto tendrá que hacerse. La única pregunta es si se planea la construcción
de un desechable o se promete entregárselo a los clientes.



El prototipo puede servir como "primer sistema", el que Brooks recomienda
desechar. Pero ésta tal vez sea una visión idealizada. Es verdad que a los
clientes y los desarrolladores les gusta el paradigma de construcción de
prototipos. A los usuarios les gusta el sistema real y a los desarrolladores les
gusta construir algo de inmediato. Sin embargo, la construcción de
prototipos también se torna problemática por las siguientes razones:

1. 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. Cuando se informa que
el producto debe construirse otra vez para mantener los altos niveles de cali-
dad, el cliente no lo entiende y pide la aplicación de "unos pequeños ajustes"
para que se pueda elaborar un producto final a partir del prototipo. Es muy
frecuente que la gestión del desarrollo de software sea muy lenta.

2. A menudo, el desarrollador establece compromisos de implementación
para lograr que el prototipo funcione con rapidez. Tal vez se utilice un

el o
sistema operativo o lenguaje de programación inadecuado sólo porque está

igu er
disponible y es conocido; se puede implementar un algoritmo ineficiente
M om
sólo para mostrar capacidad. Después de un tiempo, el desarrollador quizá
se familiarice con estas selecciones y olvide las razones por las que son
an R
inapropiadas. La selección menos ideal ahora se convierte en una parte
integral del sistema.
, S rvin

A pesar de que tal vez surjan problemas, la construcción de prototipos
puede ser un paradigma efectivo para la ingeniería del software. La clave
GB a

es definir las reglas del juego desde el principio; es decir, el cliente y el
U c. M

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 en que después se desarrolle el software
real con un enfoque hacia la calidad.
Li



MODELO EN ESPIRAL

el o
igu er
M om
an R
, S rvin

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

modelo en cascada. Proporciona el material para el desarrollo rápido de
U c. M

versiones incrementales del software. Boehm describe este modelo de la
siguiente manera:

El modelo de desarrollo en espiral es un generador del modelo de proceso
Li

guiado por el riesgo que se emplea para conducir sistemas intensivos de
ingeniería del software concurrente y con múltiples usuarios. Tiene dos
características distintivas principales. Una de ellas es un enfoque cíclico
para el crecimiento incremental del grado de definición e implementación
de un sistema, mientras disminuye su grado de riesgo. La otra es un con-
junto de puntos de fijación para asegurar el compromiso del usuario con
soluciones de sistema que sean factibles y mutuamente satisfactorias.

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 más completas del sistema
desarrollado.

Un proceso en espiral se divide en un conjunto de actividades del marco de
trabajo que define el equipo de ingeniería del software. Para propósitos
ilustrativos se aprovechan las actividades genéricas del marco de trabajo
expuestas páginas atrás. 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 que tiene una dirección en el sentido del movimiento
de las manecillas del reloj, y que se inicia desde el centro. El riesgo es un
factor 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 subsecuentes alrededor de la espiral
se pueden aprovechar para desarrollar un prototipo y después, en forma
progresiva, versiones más elaboradas del software. Cada paso a través de la
región de planeación resulta en ajustes al plan del proyecto. Los costos y el
itinerario se ajustan con base en la retroalimentación derivada de la relación
con el cliente después de la entrega. Además, el administrador del proyecto
ajusta el número de iteraciones planeado que se requiere para completar el
software.

A diferencia de otros modelos de proceso que terminan cuando se entrega el

el o
software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la

igu er
vida del software de computadora. Por lo tanto, el primer circuito alrededor
M om
de la espiral podría representar un "proyecto de desarrollo del concepto", el
cual se inicia en el centro de la espiral y continúa por múltiples iteraciones 6
an R
hasta que el desarrollo del concepto esté completo. Si el concepto se
desarrollará en un producto real, el proceso continúa en la siguiente fase de
, S rvin

la espiral y comienza un "proyecto de desarrollo de un producto nuevo". El
nuevo producto evolucionará a través de un número de iteraciones alrededor
de la espiral. Después, un circuito alrededor de la espiral se podría emplear
GB a

para representar un "proyecto de mejoramiento del producto". En esencia, la
U c. M

espiral, cuando se caracteriza de esta forma, permanece operativa hasta que
el software se retira. En ocasiones el proceso está inactivo, pero siempre que
se inicie un cambio el proceso comienza en el punto de entrada aprobado
Li

(por ejemplo, mejoramiento del producto).

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. El modelo en espiral emplea
la construcción de prototipos como un mecanismo encaminado a reducir
riesgos pero, en forma más importante, permite al desarrollador la
aplicación del enfoque de la construcción de prototipos en cualquier etapa
evolutiva del producto. Mantiene el enfoque sistemático de los pasos que
sugiere el ciclo de vida clásico, pero lo incorpora al marco de trabajo ite-
rativo que refleja de forma más verídica el mundo real. El modelo en espiral
exige una consideración directa de los riesgos técnicos en todas las etapas del
proyecto y, si se aplica en forma apropiada, debe reducir los riesgos antes de
que se vuelvan problemáticos.

Así como otros paradigmas, el modelo en espiral no es una panacea. Es
difícil convencer a los clientes (en particular en situaciones bajo contrato) de
que el enfoque evolutivo es controlable, ya que se requiere una habilidad



considerable para evaluar el riesgo y se confia en dicha habilidad para
obtener el éxito. Si un riesgo importante no se descubre y administra, sin
duda surgirán problemas.

MODELO DE DESARROLLO CONCURRENTE

el o
igu er
M om
an R
, S rvin
GB a
U c. M
Li

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 ingeniería del
software y sus estados asociados. Por ejemplo, la actividad de modelado,
definida para el modelo en espiral, se lleva a cabo al invocar las acciones
siguientes: construcción de prototipos o modelado y especificación del
análisis y diseño.7



Se proporciona un esquema de una tarea de ingeniería de software
relacionada con la actividad de modelado para el modelo de proceso
concurrente. La actividad —modelado— puede estar en alguno de los
estados destacados mencionados antes en cualquier momento dado. De
forma similar, otras actividades o tareas (por ejemplo, la comunicación y la
construcción) se representan de una manera análoga. Todas las actividades
existen de forma concurrente, pero se encuentran en diferentes estados. Por
ejemplo, al principio del proyecto la actividad de comunicación (no se
muestra en la figura) ha completado su primera iteración y existe en el
estado de en espera de cambios. La actividad de modelado que existió en el
estado ninguno mientras se realizaba la comunicación inicial, ahora realiza
una transición al estado en desarrollo. Sin embargo, si el cliente indica
cambios en los requisitos, la actividad de modelado se mueve del estado en
desarrollo al estado de en espera de cambios.

El modelo de proceso concurrente define una serie de eventos que
dispararán transiciones de estado a estado para cada una de las actividades,

el o
acciones o tareas de la ingeniería del software. Por ejemplo, durante los

igu er
primeros estados del diseño (una acción de la ingeniería del software que
ocurre en el curso de la actividad de modelación) no se detecta una
M om
inconsistencia en el modelo del análisis. Esto genera el evento corrección del
análisis del modelo, el cual disparará la creación del análisis desde el estado
an R

realizado hasta el estado de en espera de cambios.
, S rvin

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. En lugar de confinar las actividades, acciones y tareas de la
GB a

ingeniería del software a una secuencia de eventos, define una red de
U c. M

actividades. Cada actividad, acción o tarea en la red existe de manera
simultánea con otras actividades, acciones o tareas. Los eventos generados
entre los estados.
Li



Actividad Nº 1

el o
igu er
M om
Actividad Nº 2
an R
Investigue Y Explique:
, S rvin

• Cuáles son los Modelos Especializados de Proceso:

– Desarrollo basado en C____________
GB a

– Modelo de _____________ Formales
U c. M

– Desarrollo de Software Orientado a A_________
Li


Modelos de desarrollo de software separata

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (16)

Similaire à Modelos de desarrollo de software separata

Similaire à Modelos de desarrollo de software separata (20)

Plus de Marvin Romero

Plus de Marvin Romero (20)

Dernier

Dernier (20)

Modelos de desarrollo de software separata