2.2 METODOLOGÍA PARA EL DISEÑO DE SOFTWARE.

El Diseño de Software.
Se lo define como el proceso de aplicar ciertas técnicas y principios con el propósito
de definir un dispositivo, un proceso o un sistema, con suficientes detalles como
para permitir su interpretación y realización física.

La etapa del diseño del Software encierra cuatro etapas:

1) Trasforma el modelo de dominio de la información, creado durante el
análisis, en las estructuras de datos necesarios para implementar el
software.
2) El diseño de los datos. Define la relación entre cada uno de los elementos
estructurales del programa.
3) El diseño arquitectónico. Describe como se comunica el software consigo
mismo, con los sistemas que operan junto con él y con los operadores y
usuarios que lo emplean.
4) El diseño de la interfaz.
5) El diseño de procedimientos.

El diseño del software transforma elementos estructurales de la arquitectura del

programa. La importancia del diseño del software se puede definir en una sola
palabra calidad, dentro del diseño es donde se fomenta la calidad del Proyecto. El
diseño es la única manera de
materializar con precisión los
requerimientos del cliente.
El proceso de diseño es un conjunto de pasos repetitivos que permiten al diseñador
describir todos los aspectos del sistema a construir. A lo largo del diseño se evalúa
la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas:

1. El diseño debe implementar todos los requisitos explícitos contenidos en el

modelo de análisis y debe acumular todos los requisitos implícitos que desea el
cliente. Debe ser una guía que puedan leer y entender los que construyan
el código y los que prueban y mantienen el software.
2. El Diseño debe proporcionar una completa idea de lo que es el software,
enfocando los dominios de datos, funcional y comportamiento desde el punto de
vista de la Implementación. Para evaluar la calidad de una presentación del
diseño, se deben establecer criterios técnicos para un buen diseño como son:

 Un diseño debe presentar una organización jerárquica que haga un uso

inteligente del control entre los componentes del software.
 El diseño debe ser modular, es decir, se debe hacer una
partición lógica del software en elementos que realicen funciones y
subfunciones específicas.
 Un diseño debe contener abstracciones de datos y procedimientos.
 Debe producir módulos que presenten características de funcionamiento
independiente.
 Debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los módulos y el entorno exterior.
 Debe producir un diseño usando un método que pudiera repetirse según
la información obtenida durante el análisis de requisitos de software.

Estos criterios no se consiguen por casualidad. El proceso de diseño del software

exige buena calidad a través de la aplicación de principios fundamentales de diseño,
metodología sistemática y una revisión exhaustiva. Cuando se va a diseñar un
sistema de computadoras se debe tener presente que el proceso de un diseño
incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o
croquis.
Diseño de la Salida. En este caso salida se refiere a los resultados e informaciones
generadas por el sistema, para la mayoría de los usuarios la salida es la única razón
para el desarrollo de un sistema y la base de evaluación de su utilidad. Sin embargo,
cuando se realiza un sistema, como analistas deben realizar lo siguiente:
1) Determine qué información presentar. Decidir si la información será
presentada en forma visual, verbal o impresora y seleccionar el medio de
salida.
2) Disponga la presentación de la información en un formato aceptable.
3) Decida como distribuir la salida entre los posibles destinatarios.

Diseño de archivos. Incluye decisiones con respecto a la naturaleza y contenido del

propio archivo, como si se fuera a emplear para guardar detalles de las
transacciones, datos históricos, o información de referencia. Entre las decisiones
que se toman durante el diseño de archivos, se encuentran las siguientes:
 Los datos que deben incluirse en el formato de registros contenidos en el
archivo.
 La longitud de cada registro, con base en las características de los datos
que contenga.
 La secuencia a disposición de los registros dentro del archivo
(la estructura de almacenamiento que puede ser secuencial, indexada o
relativa).

No todos los sistemas requieren del diseño de todos los archivos, ya que la mayoría
de ellos pueden utilizar los del viejo sistema y solo tenga que enlazarse el nuevo
sistema al archivo maestro donde se encuentran los registros.
Diseño de interacciones con la base de datos. La mayoría de los sistemas de
información ya sean implantado en sistemas de cómputos grandes o pequeños,
utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razón
estos sistemas utilizan u administrador de base de datos, en este caso el diseñador
no construye la base de datos sino que consulta a su administrador para ponerse
de acuerdo en el uso de esta en el sistema.
Programación descendente (top-down).

También conocida como de arriba-abajo y consiste en establecer una serie de

niveles de mayor a menor complejidad (arriba-abajo) que den solución al problema.
Consiste en efectuar una relación entre las etapas de la estructuración de forma que
una etapa jerárquica y su inmediato inferior se relacionen mediante entradas y
salidas de información. Este diseño consiste en una serie de descomposiciones
sucesivas del problema inicial, que recibe el refinamiento progresivo del repertorio
de instrucciones que van a formar parte del programa.

La utilización de la técnica de diseño top-down tiene los siguientes objetivos

básicos:
 Simplificación del problema y de los subprogramas de cada
descomposición.
 Las diferentes partes del problema pueden ser programadas de modo
independiente e incluso por diferentes personas.
 El programa final queda estructurado en forma de bloque o módulos lo que
hace más sencilla su lectura y mantenimiento.

Las estructuras desde los dos puntos de vista se representan de la siguiente forma:
El diseño descendente se representa así:

Un proceso descendente está basado en dos características esenciales:

 Representación en forma de árbol.

 Descomposición funcional.

El diseño se basa en la realización de diferentes niveles. El primer nivel resuelve

totalmente el problema y el segundo y sucesivos niveles son refinamientos
sucesivos del primero (stepwise) y se sigue siempre la metodología de recursos
abstractos.

Si el diseño y planteamiento es correcto nunca será preciso volver atrás ya que los
niveles anteriores al que se esté situando en un momento dado ya habrán resuelto
el problema en su totalidad.

Técnica ascendente (bottom - up).

El diseño ascendente se refiere a la identificación de aquellos procesos que

necesitan computarizarse conforme vayan apareciendo, su análisis como sistemas
y su codificación; o bien, la adquisición de paquetes de software para satisfacer el
problema inmediato. Los problemas que requieren de la computarización, con
mayor frecuencia se encuentran en los niveles inferiores de la. organización. Es por
ello, que los problemas en tales niveles inferiores en principio son los únicos
problemas en los cuales el cómputo podría ser costeable. En consecuencia, este
enfoque se denomina ascendente, refiriéndose a que la computarización se
implanta desde un nivel más bajo. Con frecuencia, las empresas se apegan a este
enfoque del desarrollo de sistemas para iniciarse adquiriendo, por ejemplo,
paquetes de software de contabilidad, otro para la programación de producción y
algún otro para mercadotecnia.
Cuando la programación se realiza internamente y haciendo uso de un enfoque
ascendente, es difícil Ilegar a Integrarlos subsistemas, a grado tal de que el
desempeño global sea fluido. Los problemas de interacción entre los sistemas son
sumamente costosos y muchos de ellos no se solucionan hasta que la programación
alcanza la fecha límite para la integración total del sistema. En esta fecha, ya se
cuenta con poco tiempo, presupuesto o paciencia de los usurarios, como para
corregir aquellas delicadas interfaces, que, en un principio, se ignoraron.

Aunque cada subsistema parece ofrecer lo que se requiere, cuando se contempla

al sistema como una entidad global, adolece de ciertas limitaciones por haber
tomado un enfoque ascendente. Uno de ellos es:
 Duplicación de esfuerzos para accesar al software y más aún para introducir
datos.
 Introducir muchos datos carentes de valor.
 Los objetivos globales de la organización no fueron considerados y, en
consecuencia, no se satisface.
Modular.

Es un paradigma de programación que consiste en dividir un programa en módulos

o subprogramas con el fin de hacerlo más legible y manejable.

Se presenta históricamente como una evolución de la programación

estructurada para solucionar problemas de programación más grandes y complejos
de lo que esta puede resolver.

Al aplicar la programación modular, un problema

complejo debe ser dividido en varios subproblemas
más simples, y estos a su vez en otros subproblemas
más simples. Esto debe hacerse hasta obtener
subproblemas lo suficientemente simples como para
poder ser resueltos fácilmente con algún lenguaje de
programación. Esta técnica se llama refinamiento
sucesivo, divide y vencerás o análisis descendente
(top-down).

Un “módulo” es cada una de las partes de un programa que resuelve uno de los
subproblemas en que se divide el problema complejo original. Cada uno de estos
módulos tiene una tarea bien definida y algunos necesitan de otros para poder
operar. En caso de que un módulo necesite de otro, puede comunicarse con éste
mediante una interfaz de comunicación que también debe estar bien definida.

Si bien un módulo puede entenderse como una parte de un programa en cualquiera

de sus formas y variados contextos, en la práctica se los suele tomar como
sinónimos de procedimientos y funciones. Pero no necesaria ni estrictamente un
módulo es una función o un procedimiento, ya que el mismo puede contener muchos
de ellos. No debe confundirse el término "módulo" (en el sentido de programación
modular) con términos como "función" o "procedimiento", propios del lenguaje que
lo soporte.
 Ilustración 1subprogramas.

Programación estructurada.
La programación estructurada ofrece algunos beneficios, pero no se la debe
considerar como algo sencillo en el desarrollo de programas dado que requiere de
dedicación, esfuerzo y creatividad. El resultado final son programas más fáciles de
comprender y analizar lo cual trae un ahorro de tiempo en las actividades de
pruebas, mantenimiento y modificación. Los programas estructurados deben estar
divididos en módulos que cumplan con las características de un “módulo propio” las

cuales son:

 Tener una sola entrada y una sola salida.

 No poseer lazos infinitos.

 No contener instrucciones que jamás se utilizan.

Cuando varios programas “propios” se combinan para formar uno solo, el resultado
es también un programa propio.
En la programación estructurada todas las bifurcaciones de control se encuentran
estandarizadas en tres tipos de estructuras lógicas, las cuales son:

 Secuencial.

 Selectiva.
 Repetitivas.

Mediante la combinación de estas tres estructuras junto con la programación

modular es posible crear cualquier tarea, obteniendo programas que puedan ser
leídos desde su inicio hasta su fin en una forma continua, sin tener que estar
saltando de un lugar a otro del programa, tratando de seguir el rastro de la lógica
establecida por el programador.

A continuación, se muestra una pequeña descripción de cada una de las estructuras

mencionadas anteriormente, las cuales son empleadas en los programas de
ejemplo de este texto.

Estructura Secuencial: Es simplemente la formalización de las instrucciones en un

programa las cuales son ejecutadas en el mismo orden en que aparecen. En
términos de diagrama de flujo tenemos la figura 1.

Figura 1. Esquema de una estructura secuencial.

Estructura Selectiva: Estas se utilizan para tomar decisiones lógicas. En estas se
evalúa una condición y en función al resultado se realiza una determinada secuencia
de instrucciones. Esta estructura de control es denominada usualmente como IF-
THEN-ELSE (Si esto – Entonces – Si no). Estas estructuras a su vez se encuentran
clasificadas en tres, las cuales se explican a continuación.

Selectiva simple: Ejecuta una determinada condición y si el resultado es verdadero

se ejecuta solo una determinada acción. Si la condición es falsa el programa sigue
con su secuencia normal. A esta estructura se le conoce en el mundo de la
programación como if–then.
Herramientas para el diseño de Software.
Las herramientas para el diseño del software, apoyan el proceso de formular las
características que el sistema debe tener para satisfacer los requerimientos
detectados durante las actividades del análisis:

 Herramientas de especificación. Apoyan el proceso de formular las

características que debe tener una aplicación, tales como entradas, salidas,
procesamiento y especificaciones de control. Muchas incluyen herramientas
para crear especificaciones de datos.

 Herramientas para presentación. Se utilizan para describir la posición de

datos, mensajes y encabezados sobre las pantallas de las terminales,
reportes y otros medios de entrada y salida.

 Herramientas para el desarrollo de sistemas. Estas herramientas nos ayudan

como analistas a trasladar diseños en aplicaciones funcionales.

 Herramientas para ingeniería de software. Apoyan el proceso de formular

diseños de software, incluyendo procedimientos y controles, así como la
documentación correspondiente.

 Generadores de códigos. Producen el código fuente y las aplicaciones a

partir de especificaciones funcionales bien articuladas.

 Herramientas para pruebas. Apoyan la fase de la evaluación de un Sistema

o de partes del mismo contra las especificaciones. Incluyen facilidades para
examinar la correcta operación del sistema, así como el grado de perfección
alcanzado en comparación con las expectativas.
https://blogereducativo.wordpress.com/diseno-y-desarrollo-del-software/

http://sedici.unlp.edu.ar/handle/10915/4055

http://www.formaciondocente.com.mx/BibliotecaDigital/17_TecnologiaEducativa/07%20Metodol
ogia%20para%20la%20Elaboracion%20de%20Software%20Educativo.pdf