Universidad Fermín Toro
Vice-rectorado Académico
Facultad de Ingeniería
Escuela de Computación
DISEÑO ESTRUCTURADO
(UNIDAD II)
Autor: Wilcar A. Rojas
C.I: 13.313.297
CABUDARE, NOVIEMBRE 2012

Desarrollo Estructurado
El desarrollo estructurado comenzó con la programación. A mediados de los
60 el enfoque estructurado se extiende a la fase de diseño que se conoce como
diseño estructurado, el cual se basa en definir una abstracción más amplia usando
los módulos de programa como componentes básicos de construcción. A mediados
de los 70, se empezaron a surgir las técnicas estructuradas, donde se empezó a
construir programas de una forma artesanal con métodos de ingeniería. El
desarrollo estructurado permitió facilitar la comprensión de programas, normas
para la aplicación de estructuras de datos y de control.
En el diseño estructurado se caracteriza por lo siguiente:
Mayor nivel de abstracción (independencia del lenguaje programación).
Elemento básico de diseño: módulo.
Modularidad que permite medir la calidad de programas.
Representa los procesos, flujos y estructuras de datos, de una manera
jerárquica y descendente.
Ven el sistema como entradas-proceso-salidas.
Se concentran en la parte del proceso.
Se lee de porciones, independientes de las especificaciones.
Aunque este desarrollo permite diseñar un buen proceso y estructura de un
programa, tiene inconvenientes como:
Leer todas las especificaciones para entender el problema.
Se repetía la misma información en partes diferentes del documento.
El enfoque de requisitos se interpretaba diferente por cada usuario.
Cuando se finalizaba el proceso de desarrollo las especificaciones eran
obsoletas.
Este enfoque se conoce como análisis estructurado o análisis descendente o
top - down. Desde su aparición se han hecho mejoras como dar menor
importancia a la construcción de los modelos físicos actuales y a los modelos
lógicos actuales, diferenciar más los modelos físicos y lógicos. Ampliar las técnicas

de análisis estructurado, para modelar sistemas en tiempo real y enfocarse en el
modelo de datos.
En el desarrollo estructurado los programas están divididos en distintos
bloques, estos bloques tienen funciones que se van confeccionado en forma de
arriba-abajo, empezando desde las generales hasta las particulares, hasta llegar a
detallar cada uno de los procedimientos y su interacción. Este desarrollo se enfoca
al diseño del programa y la compresión se hace mas fácil. Se ha hecho evidente
que este enfoque aun está un poco arraigado ya que se tiende a no pasar de un
proceso o iteración a otra, sin culminar con la anterior, ademas que el ciclo de vida
debe recorrerse completo y al manejarse de esta manera, trae como
consecuencias información redundante, costos y desperdicio de tiempo.
Desarrollo Orientado a Objetos
El desarrollo del paradigma de Orientado a Objetos (OO) trata los procesos
y datos de forma conjunta. Este comienza a mediados de los 80 con los lenguajes
de programación Orienta a Objetos en los que se daba énfasis a la abstracción de
datos para los que se adjuntaba un conjunto de operaciones. Por otra parte los
conceptos de técnicas estructuradas han servido de base para muchas de las
metodológicas OO.
La orientación a objetos empieza con los lenguajes de programación
orientados a objetos; en estos lenguajes los problemas del mundo real se
representan como un conjunto de objetos para los que se adjuntan un conjunto de
operaciones. Ej. C++, Java, entre otros.
En la metodología orientada a objetos el sistema se organiza como una
colección de objetos que interactúan entre sí y que contienen tanto estructuras de
datos como un comportamiento. Esto se opone a la programación convencional, en
la cual las estructuras de datos y el comportamiento solamente están relacionadas
de forma débil, ya que estos se enfocan principalmente a las funciones.

Los principios del modelo OO son:
Abstracción: Es una descripción simplificada o especificación de un sistema
que enfatiza algunos de los detalles o propiedades del sistema, mientras
suprime otros.
Encapsulación: En el proceso de ocultar todos los detalles de un objeto que
no contribuyen a sus características esenciales.
Modularidad: Es la propiedad de un sistema que ha sido descompuesto en
un conjunto de módulos coherentes e independientes.
Jerarquía o herencia: Es el orden de las abstracciones organizado por
niveles.
Tipificación: Es la definición precisa de un objeto de tal forma que objetos
de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan
intercambiarse de manera muy restringida.
Concurrencia: Es la propiedad que distingue un objeto que está activo de
uno que no lo está.
Persistencia: Es la propiedad de un objeto a través de la cual su existencia
trasciende el tiempo (es decir, el objeto continua existiendo después de que
su creador ha dejado de existir) y/o el espacio (es decir, la localización del
objeto se mueve del espacio de dirección en que fue creado).
Booch (1986) dice que “si un modelo que se dice OO no contiene alguno de
los primeros cuatro elementos, entonces no es Orientado a Objetos”.
El desarrollo orientado a objetos comprende dividir un programa en clases,
donde estas clases estarán estructuradas por propiedades, atributos, variables,
pretendiendo simular y describir de manera conceptual a un objeto, y lo
importante de este desarrollo es que al usar el principio de encapsulamiento
proporciona la ventaja de que se evite interferencias extrañas entre distintas
partes del programa y podemos cambiar la implementación concreta de un objeto
sin afectar al resto del sistema. Actualmente este desarrollo es el que esta

aflorando más en los aspectos de desarrollo de software ya que permite crear un
modelo parecido a la realidad y ver las cosas como un objeto, es decir, realmente
como son y como se comportan.
Características deseables de una metodología
Existencia de reglas predefinidas, fases y subfases, tareas, productos
intermedios, técnicas y herramientas tales que se amolden a cualquier
desarrollo.
Cobertura total del ciclo de desarrollo.
Verificaciones intermedias.
Planificación y control.
Comunicación efectiva.
Utilización sobre un abanico amplio de proyectos.
Fácil formación.
Herramientas case.
La metodología debe contener actividades que mejoren el proceso de
desarrollo.
Soporte al mantenimiento. Por ejemplo. Reingeniería.
Soporte de la reutilización de software, no solo reutilización de código.
Actualmente, se huye de métodos muy burocráticos o monolíticos.
Se dice entonces que una metodología es la que permita definir las etapas,
las salidas, entradas de un proyecto. Mantener un programa no es fácil pero se
puede lograr, por lo tanto, las metodologías deben permitir una robusta formación
del proyecto que permita utilizar mecanismos de mejora y que se usen los recursos
disponibles con su mayor rendimiento y eficacia.

Metodologías Vs. Ciclo de vida
Una metodología es un conjunto integrado de técnicas y métodos que
permite abordar de forma homogénea y abierta cada una de las actividades del
ciclo de vida de un proyecto de desarrollo. Una definición estándar de metodología
puede ser el conjunto de métodos que se utilizan en una determinada actividad
con el fin de formalizarla y optimizarla. Determina los pasos a seguir y cómo
realizarlos para finalizar una tarea.
Si esto se aplica a la Ingeniería de software, podemos destacar que una
metodología:
Optimiza el proceso y el producto software.
Es una guía en la planificación y en el desarrollo del software.
Define qué hacer, cómo y cuándo durante todo el desarrollo y
mantenimiento de un proyecto.

Una metodología define una estrategia global para enfrentarse con el
proyecto. Entre los elementos que forman parte de una metodología se pueden
destacar:
Fases: tareas a realizar en cada fase.
Productos: E/S de cada fase, documentos.
Procedimientos y herramientas: apoyo a la realización de cada tarea.
Criterios de evaluación: del proceso y del producto. Saber si se han logrado
los objetivos.
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se
está desarrollando desde que nace la idea inicial hasta que el software es retirado
o remplazado.
Entre las funciones que debe tener un ciclo de vida se pueden destacar:
Determinar el orden de las fases del proceso de software.
Establecer los criterios de transición para pasar de una fase a la siguiente.
Definir las entradas y salidas de cada fase.
Describir los estados por los que pasa el producto.
Describir las actividades a realizar para transformar el producto.
Definir un esquema que sirve como base para planificar, organizar,
coordinar, desarrollar, entre otros.
Las etapas de un ciclo de vida de un software son:
Inicio: éste es el nacimiento de la idea. Aquí definimos los objetivos del
proyecto y los recursos necesarios para su ejecución. Hacia dónde
queremos ir, y no cómo queremos ir. Las características implícitas o
explícitas de cada proyecto hacen necesaria una etapa previa destinada a
obtener el objetivo por el cual se escribirán miles o cientos de miles de
líneas de código. Un alto porcentaje del éxito de nuestro proyecto se
definirá en estas etapas que, al igual que la etapa de debugging, muchos
líderes de proyecto subestiman.

Planificación: idearemos un planeamiento detallado que guíe la gestión
del proyecto, temporal y económicamente.
Implementación: acordaremos el conjunto de actividades que componen
la realización del producto.
Puesta en producción: nuestro proyecto entra en la etapa de definición,
allí donde se lo presentamos al cliente o usuario final, sabiendo que
funciona correctamente y responde a los requerimientos solicitados en su
momento. Esta etapa es muy importante no sólo por representar la
aceptación o no del proyecto por parte del cliente o usuario final sino por
las múltiples dificultades que suele presentar en la práctica, alargándose
excesivamente y provocando costos no previstos.
Control en producción: control del producto, analizando cómo el proceso
difiere o no de los requerimientos originales e iniciando las acciones
correctivas si fuesen necesarias. Cuando decimos que hay que corregir el
producto, hacemos referencia a pequeñas desviaciones de los
requerimientos originales que puedan llegar a surgir en el ambiente
productivo. Si nuestro programa no realiza la tarea para lo cual fue creada,
esta etapa no es la adecuada para el rediseño. Incluimos también en esta
etapa el liderazgo, documentación y capacitación, proporcionando directivas
a los recursos humanos, para que hagan su trabajo en forma correcta y
efectiva.
Objetivos de cada etapa:
Expresión de necesidades: Esta etapa tiene como objetivo el armado de
un documento en el cual se reflejan los requerimientos y funcionalidades
que ofrecerá al usuario el sistema a implementar (qué, y no cómo, se va a
implementar).
Especificaciones: Formalizamos los requerimientos; el documento
obtenido en la etapa anterior se tomará como punto de partida para esta
etapa.

Análisis: Determinamos los elementos que intervienen en el sistema a
desarrollar, su estructura, relaciones, evolución temporal, funcionalidades,
tendremos una descripción clara de qué producto vamos a construir, qué
funcionalidades aportará y qué comportamiento tendrá.
Diseño: Ya sabemos qué hacer, ahora tenemos que determinar cómo
debemos hacerlo (¿cómo debe ser construido el sistema en cuestión?);
definimos en detalle entidades y relaciones de las bases de datos,
seleccionamos el lenguaje que vamos a utilizar, el Sistema Gestor de Bases
de Datos, entre otros).
Implementación: Empezamos a codificar algoritmos y estructuras de
datos, definidos en las etapas anteriores, en el correspondiente lenguaje de
programación o para un determinado sistema gestor de bases de datos. En
muchos proyectos se pasa directamente a esta etapa; son proyectos muy
arriesgados que adoptan un modelo de ciclo de vida de code & fix (codificar
y corregir) donde se eliminan las etapas de especificaciones, análisis y
diseño con la consiguiente pérdida de control sobre la gestión del proyecto.
Debugging (Depuración): El objetivo de esta etapa es garantizar que
nuestro programa no contiene errores de diseño o codificación. En esta
etapa no deseamos saber si nuestro programa realiza lo que solicitó el
usuario, esa tarea le corresponde a la etapa de implementación. En ésta
deseamos encontrar la mayor cantidad de errores. Todas los programas
contienen errores: encontrarlos es cuestión de tiempo. Lo ideal es encontrar
la mayoría, si no todos, en esta etapa. También se pueden agregar pruebas
de rendimiento.
Validación: Esta etapa tiene como objetivo la verificación de que el
sistema desarrollado cumple con los requerimientos expresados inicialmente
por el cliente y que han dado lugar al presente proyecto. En muchos
proyectos las etapas de validación y debugging se realizan en paralelo por
la estrecha relación que llevan. Sin embargo, tenemos que evitar la
confusión: podemos realizarlos en paralelo, pero no como una única etapa.

Evolución: En la mayoría de los proyectos se considera esta etapa como
Mantenimiento y evolución, y se le asigna, no sólo el agregado de nuevas
funcionalidades (evolución); sino la corrección de errores que surgen
(mantenimiento). En la práctica esta denominación no es del todo errónea,
ya que es posible que aun luego de una etapa de debugging y validación
exhaustiva, se filtren errores.
Una metodología puede seguir uno o varios modelos de ciclo de vida,
adaptándose a cada uno de ellos, dependiendo de las necesidades dadas en un
momento determinado, es decir, el ciclo de vida indica lo que hay que obtener a lo
largo del desarrollo del proyecto pero no da las indicaciones de como obtenerlo. La
metodología indica los diferentes pasos y fases para obtener los distintos
productos parciales y finales. En sí para el desarrollo de software, se necesita
aplicar una metodología o varias metodologías, dentro de un ciclo de vida, de
manera que sepamos qué hacer y como hacerlo para conseguir lo que se quiere y
cumplir con las metas planteadas.
Modelos de procesos en el desarrollo de software
Un modelo de proceso para el desarrollo de software es una representación
simplificada de pasos, representada desde una perspectiva específica. Por su
naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del
software es una abstracción de un proceso real.

Estos modelos tienen como propósito la producción eficaz y eficiente de un
producto software que reúna los requisitos del cliente. Este proceso es
intensamente intelectual, afectado por la creatividad y juicio de las personas
involucradas. La mayoría de los modelos de procesos de desarrollo del software
son dirigidos por el tiempo; cuanto más tarde sea, más atrás se encontrará en el
proceso de desarrollo. Como todo proceso, están constituidos de pasos o fases que
contienen a su vez actividades, estos modelos de desarrollo de software se basan
en un ciclo de vida para desarrollar el mismo, como lo son:
La necesidad de solucionar un problema (surgimiento de
necesidades)
Inicio del proceso (desarrollo), dentro de esta fase se encuentra la
definición del proyecto, el análisis del contexto, definición de
requerimientos, diseño del sistema, construcción del sistema,
pruebas e implantación.
Operación y mantenimiento, donde realiza ajustes y se buscan fallas.
Renovación o extinción.
Los procesos de software son complejos debido a que un producto de
software es intangible y por lo general muy abstracto, esto dificulta la definición
del producto y sus requisitos, sobre todo cuando no se tiene precedentes en
productos software similares. En general este producto está compuesto por

hardware y software. En cuanto al hardware, su producción se realiza
sistemáticamente y la base de conocimiento para el desarrollo de dicha actividad
está claramente definida. Respecto del software, su construcción y resultados han
sido históricamente cuestionados debido a los problemas asociados
Los modelos de procesos permiten al analista de sistemas desarrollar un
plan de requisitos del software, permiten establecer un trabajo en forma ordenada,
además que existen muchos modelos que se adaptan a las exigencias del
proyecto, solo debemos saber cual nos conviene, pero lo mas importante, es que
estos modelos nos llevan a presentar los proyectos al cliente de manera que éste
vea su diseño y sus funciones y que la mayoría de ellos están orientados al
mantenimiento.
Clasificación de las Metodologías según el modelo de proceso
Modelos Convencionales o Prescriptivos de Procesos
Los modelos convencionales o modelos prescriptivos de procesos permiten
llenar el marco de trabajo con un conjunto de tareas orientadas al desarrollo de un
software.
Se les llama "prescriptivos" porque prescriben un conjunto de elementos del
proceso, tales como:
Actividades del Marco de Trabajo.
Acciones de la Ingeniería del software.
Tareas.
Productos de trabajo.
Aseguramiento de la calidad.
Mecanismos de control del cambio para cada proyecto.
Estos modelos son útiles si queremos describir un conjunto único de
actividades dentro de un marco de trabajo para un proceso de software. cada
actividad debe contener 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. Sin importar el modelo del proceso que se desee usar, los ingenieros de
software eligen una manera tradicional para realizar el marco de trabajo genérico
para el proceso, ya que estos modelos se caracterizan por ser en esencia rígidos,
estrictos y los más utilizados.
En las metodologías convencionales, el ciclo de vida de un proyecto, puede
definirse como un ciclo de vida lineal, ya que imponen una disciplina de trabajo
sobre el proceso de desarrollo del software, con el fin de conseguir un software
más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo
a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del
producto software. Se centran especialmente en el control del proceso, mediante
una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones
para el modelado y documentación detallada. Además, las metodologías
tradicionales no se adaptan adecuadamente a los cambios, por lo que no son
métodos adecuados cuando se trabaja en un entorno, donde los requisitos no
pueden predecirse o bien pueden variar.
Los modelos prescriptivos de proceso definen un conjunto distinto de
actividades, acciones, tareas fundamentos y productos de trabajo que es requieren
para desarrollar software de alta calidad. Los ingenieros de software y sus
gerentes deben adaptar un modelo prescripto de proceso a sus necesidades y
después lo siguen. Además, la gente que ha solicitado el software tiene un papel
por desempeñar se ejecuta el modelo de software. ¿Por qué es importante?
Porque proporciona estabilidad, control y organización a una actividad que si no se
controla puede volverse caótica. ¿Cuáles son los pasos? 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. ¿Cuál es un obtenido? Desde punto de
vista de un ingeniero de software, los productos de trabajo son los programas,
documentos y datos que se producen como consecuencia de las actividades y
tareas que define el proceso.
Modelo en Cascada
El modelo en cascada, algunas veces llamado el 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 culminar en el
soporte del software terminado.
Este modelo es aplicable en donde existen ocasiones en que los requisitos
de un problema se entienden de una manera razonable y deben estar bien
definidos, también cuando el trabajo fluye desde la comunicación a través del
despliegue de una manera casi lineal, esta situación se encuentra a veces cuando
es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente.
El modelo en cascada es el paradigma más antiguo para la ingeniería del software.
Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han
ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia.

Entre los problemas que algunas veces se encuentran al aplicar el modelo en
cascada están:
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.
En un análisis interesante de proyectos reales, Bradac(1994) concluyó que la
naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los
cuales algunos miembros del equipo del proyecto deben esperar a otros para
terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que
se aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común al
principio y al final del proceso secuencial.
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.
Las principales etapas de este modelo según Sommerville (2005) son:
Análisis y definición de requerimientos. Los servicios,
restricciones y metas del sistema se definen a partir de las consultas
con los usuarios. Se define una especificación del sistema.
Diseño del sistema y del software. El proceso de diseño del
sistema divide los requerimientos en sistemas hardware o software.

Establece una arquitectura completa del sistema. El diseño del
software identifica y describe las abstracciones fundamentales del
sistema software y sus relaciones.
Implementación y prueba de unidades. Durante esta etapa, el
diseño del software se lleva a cabo como un conjunto o unidades de
programas.
Integración y prueba del sistema. Los programas o las unidades
individuales de programas se integran y prueban como un sistema
completo para asegurar que se cumplan los requerimientos del
software.
Funcionamiento y mantenimiento. El sistema se instala y se
pone en funcionamiento práctico. El mantenimiento implica corregir
errores no descubiertos en las etapas anteriores del ciclo de vida.
Modelo de Procesos Incrementables
El modelo incremental combina elementos del modelo en cascada aplicado
en forma iterativa. El modelo incremental aplica secuencias lineales de manera
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 primer incremento, podría realizar

funciones básicas de administración de 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 ortográfica y gramatical; y en el cuarto, capacidades
avanzadas de configuración de página. Se debe tener en cuenta que el flujo del
proceso de cualquier incremento puede incorporar el paradigma de construcción
de prototipos que se expone más adelante.
A menudo, al utilizar un modelo incremental el primer incremento es un
producto esencial. Es decir, se incorporan los requisitos básicos, pero muchas
características suplementarias (algunas conocidas, otras no) 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 desarrolla un plan para el
incremento siguiente. El plan afronta la modificación del producto esencial con el
fin de satisfacer de mejor manera las necesidades del cliente y la entrega de
características y funcionalidades adicionales. Este proceso se repite después de la
entrega de cada incremento mientras no se haya elaborado el producto completo.
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.
Combina elementos del modelo en cascada aplicado en forma iterativa. El
modelo incremental aplica secuencias lineales de manera escalonada conforme
avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos.
Produce entregas de software pequeñas pero usables (incrementos). Cada parte se
construye sobre partes ya entregadas.
Modelo de desarrollo rápido de aplicaciones (DRA)
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.
El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las
restricciones de tiempo impuestas sobre un proyecto DRA exigen un "á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 (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 procesos, el enfoque DRA tiene inconvenientes:
1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos
humanos para crear en 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 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.
4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertir
interfaces en componentes del sistema, el enfoque DRA podría no funcionar.
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).
Es un modelo de proceso del software incremental que resulta 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. Hace un uso intensivo de componentes
reusables de software con un ciclo de desarrollo extremadamente corto.
Es importante destacar que los Modelo Prescriptivos proporcionan un
conjunto de pautas para el diseño, uso y rehusó de los objetos de aprendizaje,
como complemento al proceso de su descripción, de una manera iterativa o
incremental, desde la concepción del objeto de aprendizaje hasta su reusabilidad a
corto, mediano y largo plazo. Pero el éxito en la creación de cualquier objeto de
aprendizaje dependerá de la adecuada aplicación del proceso de Ingeniería de
Software, cuyas etapas facilitan el desarrollo de los objetos de aprendizaje.
TECNICA DE DISEÑO ESTRUCTURADO
OBJETIVOS DE LA TECNICA
• Obtener la estructura modular y los detalles de proceso del sistema, partiendo
solamente de los «productos» obtenidos en la fase de Análisis del Sistema.
• Cambiar la atención del QUE al COMO.
• Obtener un diseño que no sólo «funcione», sino que también sea mantenible,
mejore la reutilización y se pueda probar y entender fácilmente.
• Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros) para
representar la estructura modular del sistema.
Se trata por tanto, de conseguir que cada módulo de la estructura en árbol
que se obtenga cumpla las siguientes características:
1. Módulos de pequeño tamaño.
El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamaño
de los módulos es reducido, una determinada modificación afectará a un número
mayor de módulos, sin embargo, la cantidad de código a considerar será menor.
o Independencia modular. Cuanto mayor es la independencia de un módulo es
más sencillo trabajar con él, por tanto, el diseño debe reducir la compartición de
ficheros, de datos, la de dispositivos, las interfases comunes con el Sistema
Operativo y las llamadas, desde o hacia otros módulos.

2. Características de Caja Negra.
La característica de Caja Negra se aplica a cualquier sistema, programa o módulo,
para dar una visión exclusiva de sus entradas y salidas, sin tener en cuenta los
detalles de cómo se realiza el proceso. El uso de la Caja Negra permite una visión
más fácil del conjunto, posponiendo la consideración de los detalles para una
etapa posterior.
3. Modelización conceptual.
Un sistema será más fácil de mantener si el modelo utilizado en su diseño se ha
basado en los conceptos lógicos de la organización, los cuales serán más familiares
y comprensibles para el personal de mantenimiento que las descripciones físicas
(equipo, organización de la unidad, cómo se realiza el trabajo en la actualidad,...).
o Aislamiento de los detalles. En un sistema existen partes que reflejan la filosofía
y otras partes que reflejan los detalles. Debido a que los detalles son más
susceptibles de cambiar, ambas partes deben diseñarse por separado para evitar
que una variación en los detalles afecte a la filosofía del sistema.