2. El análisis y diseño estructurado español estructurado es otro
método para evitar los problemas de ambigüedad del lenguaje al
establecer condiciones y acciones, tanto en procedimientos como en
decisiones. Este método no hace uso de árboles o tablas; en su lugar
utiliza declaraciones para describir el proceso. El método no muestra
las reglas de decisión-, las declara.
Sin embargo, este método también le permite hacer una lista de todos
los pasos en el orden en que se llevan a cabo, como lo muestran los
ejemplos de esta sección. Para ello no se utilizan símbolos y formatos
especiales, características de los árboles y tablas de decisión que
para algunos resultan incómodos. Además, es posible describir con
rapidez los procedimientos en su totalidad ya que para ello se
emplean declaraciones muy similares al español.

3.  El análisis estructurado, como todos los demás
métodos de análisis de requisitos, es una
actividad de construcción de modelos. Mediante
una notación que es única de este método, se
crean modelos que reflejan el flujo y el contenido
de la información (datos y control); se parte el
sistema funcionalmente y, según los distintos
comportamientos, se establece la esencia de lo
que se debe construir.

4.  El diseño de software es un proceso mediante el
que se traducen los requisitos en una
representación del software.
 En el diseño se realizan dos pasos. El diseño
preliminar se centra en la transformación de los
requisitos en los datos y arquitectura del
software. El diseño detallado se ocupa del
refinamiento de la representación arquitectónica
que lleva a una estructura de datos detallada y a
las representaciones algorítmicas del software.

6.  Cuando se considera una solución modular para
cualquier problema, pueden formularse muchos niveles
de abstracción. En el nivel superior de abstracción, se
establece una solución en términos amplios, usando el
lenguaje del entorno del problema. En los niveles
inferiores de abstracción se toma una orientación más
procedimental. La terminología orientada al problema se
acompaña con una terminología orientada a la
implantación, en un esfuerzo para establecer una
solución. Por último, en el nivel más bajo de abstracción,
se establece la solución de forma que pueda
implementarse directamente.


7.  El refinamiento sucesivo es una primera estrategia
de diseño descendente (propuesta por Niklaus
Wirth). Un programa se desarrolla en niveles
sucesivos de refinamiento de los detalles
procedimentales. Se desarrolla una jerarquía
descomponiendo una declaración macroscópica de
una función en forma sucesiva hasta que se llega a
las sentencias del lenguaje de programación. Cada
paso de refinamiento implica algunas decisiones de
diseño. Es importante que el programador sea
consciente de sus decisiones y de la existencia de
soluciones alternativas.

8.  Se ha dicho que modularidad es el atributo
individual del software que permite a un programa
ser intelectualmente manejable. El software
monolítico (compuesto por sólo un módulo) no
puede ser fácilmente abarcado por un lector. El
número de caminos de control, la expansión de
referencias, el número de variables y la
complejidad global podrían hacer imposible su
correcta comprensión.

9.  La calidad del diseño debe ser una meta para el diseñador. El
diseño estructurado ofrece guías para apoyar al diseñador a
determinar módulos, y sus interconexiones, que mejor realizarán
los requerimientos especificados por el analista.

10.  Grado en el cuál los módulos se interconectan o se
relacionan entre ellos. Entre más fuerte sea el
acoplamiento entre módulos en un sistema, más difícil
es implantarlo y mantenerlo, pues entonces se
necesitará un estudio cuidadoso para la modificación
de algún módulo o módulos. En la práctica, esto
significa que cada módulo debe tener interfaces
sencillas y limpias con otros, y que se debe compartir
un número mínimo de datos entre módulos. También
significa que un módulo dado no debe modificar la
lógica interna o los datos de algún otro módulo; lo que
se conoce como una conexión patológica.

11.  Grado en el cuál los componentes de un módulo
(típicamente las instrucciones individuales que lo
conforman) son necesarios y suficientes para
llevar a cabo una sola función bien definida
 Se dividen en varios tipos que se mostraran a
continuación:

12.  Los grados de cohesión, de menor a mayor son:
 a. Cohesión Coincidente. No existe una relación
significativa entre los elementos del módulo.
 b. Cohesión Lógica. La relación entre los elementos
del módulo está basada en obtener ventajas en el
procesamiento, por ejemplo, todos manipulan el
mismo dato. Normalmente esto implica tener un
código truculento o compartido, que degrada los
propósitos de un buen diseño.
 c. Cohesión Temporal. Los elementos del módulo
constituyen un conjunto que se ejecuta
secuencialmente en un punto fijo en el tiempo.
Aunque tiende, a veces, a confundirse con la
cohesión lógica, la diferencia está en que este tipo
de módulo s más simple y se ejecuta sin la
intervención de otras aplicaciones.

13.  d. Cohesión Comunicacional. Los elementos del
módulo hacen referencia al mismo conjunto de
datos. Aquí se presenta un grado "aceptable" de
cohesión.
 e. Cohesión Secuencial. Implica que la salida de
un elemento es la entrada para el próximo.
 f. Cohesión Funcional. Aquí, todos los elementos
del módulo están orientados a la realización de
una función única.

14.  De ser posible, cada módulo debe ser lo
suficientemente pequeño como para caber en
una sola página ( o para que se pueda desplegar
en una sola pantalla). Desde luego, a veces no
es posible determinar qué tan grande va a ser un
módulo hasta haberlo escrito, pero las
actividades iniciales de diseño a menudo darán
al diseñador una buena pista de que el módulo
será grande o complejo. Si es así, debe
subdividirse en uno o más niveles de
submódulos.

15.  El número de subordinados inmediatos que un
módulo administrador puede llamar se conoce como
el alcance del control. Un módulo no debe poder
llamar a más de una media docena de módulos de
nivel inferior. La razón es evitar la complejidad: si el
módulo tuviera, por ejemplo, que llamar a 25
módulos de nivel inferior, entonces seguramente
contendrá tanta lógica compleja que nadie lo
entenderá (un sin fin de if-then anidados). La
solución es introducir un nivel intermedio de módulos
administradores, como haría un administrador de
una organización humana.

16.  Esta regla sugiere que cualquier módulo afectado por el resultado de
alguna decisión debe ser subordinado (aunque no necesariamente un
subordinado inmediato) del módulo que toma la decisión. Es un tanto
análogo a la regla de administración que dice que cualquier empleado
afectado por los resultados de la decisión de algún administrador (es
decir, dentro del alcance de efecto de la decisión), debe estar dentro del
alcance de control del administrador (es decir trabajando entre la
jerarquía de personas que se reportan con el administrador). Violar esta
regla en un ambiente de diseño estructurado usualmente lleva a un paso
innecesario de banderas y condiciones (lo cual incrementa el
acoplamiento entre módulos), la toma redundante de decisiones o (en el
peor de los casos) conexiones patológicas entre módulos.

17.  Se refiere a la economía de recursos que se
emplean para la obtención de un resultado. Esto
es, sólo se debe realizar lo que se pide. Mientras
mayor la parsimonia, mejor el diseño.

18.  Los módulos deben tener la capacidad de
manejar sus propias condiciones de error, tanto
en la detección como en la corrección de los
mismos. De no ser así, el manejo de banderas
(flags) de control y la transmisión de datos
erróneos a otros módulos aumentará
considerablemente el acoplamiento.

19.  Los diagramas de flujos de datos también son
llamados Carta de Burbujas, DFD, Diagramas de
burbujas, modelo de proceso, diagrama de flujo de
trabajo o modelo de función en la literatura
computacional.
 A medida que la información se mueve a través del
software, es modificada por una serie de
transformaciones. El DFD es una técnica gráfica que
representa el flujo de la información y las
transformaciones que se aplican a los datos al
moverse desde la entrada hasta la salida.