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.