Unidad 5 Modelo Desarrollo Software
Unidad 5 Modelo Desarrollo Software
Modelos prescriptivos.
Cualquier organización de ingeniería del software debe describir un conjunto único
de actividades dentro del marco de trabajo para el (los) proceso(s) de software que
adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de
acciones de ingeniería del software, 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. Después, la organización debe adaptar el modelo de
proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas
que lo realizarán, y el ambiente en el que se ejecutará el trabajo. Sin importar el modelo
del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un
marco de trabajo genérico para el proceso, el cual incluye las siguientes actividades dentro
del marco: comunicación, planeación, modelado, construcción y desarrollo.
El modelo en cascada.
1. Es muy raro que los proyectos reales sigan el flujo secuencial que 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.
2. Con frecuencia es difícil para el cliente establecer todos los requisitos de 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.
El modelo incremental.
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.
El modelo DRA.
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 [KER94].
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.
satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador
entienda mejor lo que se debe hacer.
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 (como
generadores de informes, administradores de ventanas, etcétera) que permiten producir
programas de trabajo con rapidez.
Pero ¿qué debe hacerse con el prototipo una vez cumplido el propósito descrito?
Brooks [BRO75] 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 in-servible 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 dese-
char. 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 calidad, 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 sistema operativo o
lenguaje de programación inadecuado sólo porque está disponible y es conocido;
se puede implementar un algoritmo ineficiente 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 inapropiadas. La selección menos ideal ahora se
convierte en una parte integral del sistema.
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 es definir las reglas
del 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 en que después se desarrolle el
software real con un enfoque hacia la calidad.
MC Genaro Alberto Gómez Chi Página 6 de 18
Modelos de desarrollo de software
El modelo en espiral.
continúa por múltiples iteraciones 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
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 para representar un "proyecto de
mejoramiento del producto". En esencia, la 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 (por ejemplo, mejoramiento del producto).
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.
A pesar de los incuestionables beneficios de los procesos evolutivos de software, se tienen algunas
dificultades con este tipo de procesos. La primera dificultad es que la construcción de prototipos [y otros
procesos evolutivos más elaborados] implican un problema para la planeación del proyecto debido al número
incierto de ciclos requeridos para construir el producto. La mayoría de las técnicas de gestión y estimación
de proyectos se basa en configuraciones lineales de las actividades, por lo que éstas no se ajustan por
completo.
La segunda dificultad es que los procesos evolutivos de software no establecen la velocidad máxima
de la evolución. Si las evoluciones suceden demasiado rápido, sin un periodo de relajación, existe la
certidumbre de que el proceso caerá en el caos. Por otro lado, si la velocidad es demasiado lenta, se podría
afectar la productividad.
Una tercera dificultad es que los procesos de software se deben enfocar en la flexibilidad y
extensibilidad en vez de en la alta calidad. Esta afirmación suena atemorizante. Sin embargo, se debe
priorizar la velocidad del desarrollo sobre los cero defectos. Si el desarrollo se extiende para alcanzar una
alta calidad, se produciría un retraso en la entrega del producto, la cual se haría cuando el nicho de
No obstante, tal vez el enfoque a través de métodos formales haya ganado adeptos
entre los desarrolladores de software que deben construir sistemas de alta seguridad (por
ejemplo, en los campos de la aeronáutica y de los dispositivos médicos), y entre los
desarrolladores que padecen severas penurias económicas cuando aparecen errores en el
software.
El proceso unificado.
En su libro fundamental sobre el proceso unificado, Ivar Jacobson, Grady Booch y
James Rumbaugh [JAC99] exponen la necesidad de un proceso de software "guiado por
los casos de uso, de arquitectura céntrica, iterativo e incremental". Estos autores
establecen:
En esta sección se presenta una visión general de los elementos clave del proceso
unificado.
riesgos importantes, define un itinerario y establece una base para las fases que se
aplicarán conforme se desarrolle el incremento del software.
A lo largo de las fases del PU se distribuye un flujo de trabajo de ingeniería del software.
En el contexto del PU, un flujo de trabajo es análogo a un conjunto de tareas. Esto es, un
flujo de trabajo identifica las tareas necesarias para completar una acción importante de
ingeniería del software y los productos de trabajo que se producen como consecuencia de la
realización exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un
flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar
el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades.
En la siguiente figura se ilustran los productos de trabajo clave que se produjeron como
consecuencia de las cuatro fases técnicas del PU. Durante la fase de inicio, el propósito es
establecer una "visión" general
para el proyecto, identificar un
conjunto de requisitos de
negocios, formar un caso de
negocios para el software y
definir los riesgos del proyecto y
del negocio que pudieran
representar un obstáculo para el
éxito. Desde el punto de vista del
ingeniero de software, el
producto de trabajo más impor-
tante generado durante la etapa
de inicio es el modelo de caso de
uso: una colección de casos de
uso que describen la forma en
que actores externos ("usuarios" humanos y no humanos del software) interactúan con el
sistema y obtienen valor a partir de éste. En esencia, el modelo de casos de uso es una
colección de escenarios de uso con plantillas estandarizadas que implican características
y funciones del software mediante la descripción de una serie de condiciones previas, un
flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la
interacción representada. En un inicio, los casos de uso describen requisitos al nivel del
dominio de negocios (por ejemplo, el grado de abstracción es alto). Sin embargo, el
modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve
como una entrada importante para la creación de productos de trabajo subsecuentes.
Durante la fase de inicio sólo se completa entre el 10 y 20 por ciento de los casos de uso.
Después de la elaboración, se ha creado entre un 80 y 90 por ciento del modelo.
en la fase de elaboración se revisan los riesgos y el plan de proyecto para asegurar que
cada uno de ellos conserve su validez.
Resumen.
Los modelos prescriptivos del proceso de software se han aplicado durante muchos
años en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada
uno de estos modelos convencionales sugiere un flujo de proceso que de alguna forma es
diferente, pero todos realizan el mismo conjunto de actividades genéricas del marco de
trabajo: comunicación, planeación, modelado, construcción y despliegue.
Los modelos increméntales del proceso de software producen software como una
serie de entregas de incrementos. El modelo DRA está diseñado para proyectos gran
des que se deben entregar en marcos de tiempo muy reducidos.
El modelo orientado a aspectos incluye los intereses generales que cubren la arqui-
tectura total del sistema.
1) una fase de inicio que abarca la comunicación con el cliente y las actividades de
planeación, y destaca el desarrollo y el refinamiento de casos de uso como un
modelo primario;
2) una fase de elaboración que abarca la comunicación con el cliente y las actividades
de modelado con un enfoque en la creación de modelos de análisis y diseño, con
énfasis en las definiciones de clase y representaciones arquitectónicas;
3) una fase de construcción que refina y después traduce el modelo de diseño en
componentes de software implementados;
4) una fase de transición que transfiere el software del desarrollador al usuario final
para realizar las pruebas beta y obtener la aceptación; y
5) una fase de producción en la cual se realiza el monitoreo continuo y el soporte.