Programación: Diseño de sistemas

Diseño y desarrollo de sistemas
En esta sección definimos el diseño de sistemas de abajo hacia arriba y de arriba hacia abajo, así como el
enfoque modular a la programación. Demostraremos las ventajas de cada uno, así como las desventajas que
deben ser observadas cuando se emplea un enfoque de cualquier tipo. También trataremos la aplicabilidad de
los enfoques de arriba hacia abajo y modular para que ayuden en el aseguramiento de la calidad de los tipos de
diseño.
Diseño 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 computarízació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 mas 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ícíl 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 limite 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 aun 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.
.
Diseño descendente (Top − down)
Es fácil visualizar a que se refiere el enfoque de arriba hacia abajo, ya que se refiere a ver una gran imagen del
sistema y luego de explotarla en partes o subsistemas pequeños, tal como, se muestra en la siguiente figura. El
diseño descendente permite que el analista de sistemas logre primero los objetivos organizacionales generales.
Luego, el analista se mueve para dividir el sistema en subsistemas y sus requerimientos.
El diseño descendente es compatible con la manera de pensar sobre los sistemas en general. Cuando el
analista de sistemas emplea un enfoque descendente , esta pensando acerca de las interdependencias de los
subsistemas, tal como cae en la organización existente.
El enfoque descendente da la importancia debida a la sinergia o las interfaces requeridas por el sistema y los
subsistemas; los cuales no existen en el enfoque ascendente.
1
Dentro de las ventajas de la utilización de un enfoque descenden-te en el diseño de sistemas, se encuentra:
• E evitar el caos originado al tratar de diseñar el sistema "en un solo paso". Como hemos visto, la
planeación y la implementación de sistemas de información es increíblemente compleja. El tratar de
integrar a todos los subsistemas y que todos ellos funcionen al unísono, es buscar el fracaso.
• La segunda ventaja de hacer uso del enfoque descendente en el diseño, es la posibilidad de contar con
grupos de analistas de sistemas trabajando por separado pero simultáneamente en subsistemas
independientes, pero necesarios. Esto puede ahorrar una gran cantidad de tiempo. El trabajo de grupos
integrados par el diseño subsistemas es particularmente conveniente para la búsqueda del
aseguramiento de la calidad total.
• La tercera ventaja estriba en evitar el gran problema asociado con un enfoque ascendente. Esto es, la
utilización de un enfoque descendente, previene que el analista de sistemas se adentre en los detalles y
dé la pauta para que se pierdan los objetivos centrales del sistema.
Existen ciertos inconvenientes en el diseño descendente que el analista de sistemas debe mantener en mente.
• El primero es que ende el riesgo de que el sistema se divida en subsistemas "incorrectos". Se debe
prestar atención a la necesidad dé la superposición y la distribu-ción de los recursos, de tal forma que
una participación de subsistemas tenga sentido en el esquema global del sistema Además, es
importante que cada subsistema se integre dé manera correcta al sistema.
• El segundo inconveniente es que una vez que», realizan las divi-siones en subsistemas, sus interfaces
pueden descuidarse o simplemente ignorarse. La responsabilidad para lograr la adecuada interrelación
debe .quedar bien detallada.
• Una tercera precaución que debe acompañar al uso del diseño descendente, es que los subsistemas
deberán reintegrarle eventualmente. Los mecanismos para la reintegración deben plantearte desde un
principio. Una sugerencia es intercambiar de manera regular, la información entre los equipos de
subsistemas, otra es la utilización de instrumentos que permitan cierta flexibilidad, si se requirieran
cambios de los sistemas relacionados.
Un programa de aseguramiento de la calidad total y la toma es él diseño de un enfoque descendente pueden ir
de la mano. El enfoque descendente proporciona al grupo de sistemas una clara división establecida de los
usuarios en fuerzas de tareas para los subsistemas. Los grupos asignados a las tareas establecidos por esta
manera pueden tener una función doble, tal y como los círculos de control de calidad de los sistemas
informáticos para la administración. De esta manera se tiene una estructura necesaria para el aseguramiento de
la calidad, así como una motivación apropiada para incorporar el subsistema al cumplimiento de los objetivos
de los departamentos involucrados.
Desarrollo Modular
Una vez que se ha tomado el enfoque del diseño descendente, también será útil durante la programación un
enfoque de concepción modular. Esto significa descomponer la programación en fracciones lógicas y
manejables. Este tipo de programación se apega bien al diseño descen-dente porque enfatiza las interfaces
entre los módulos, mis qué mantenerlas ignoradas hasta el final del desarrollo del sistema. De manera ideal,
cada módulo debe ser funcionalmente cohesivo, de tal manera que satisfaga sólo una función.
El disueno de programas modulares, tiene tres ventajas básicas:
2
• Primero, los módulos son más fáciles de escribir y de revisar, ya que es-tán virtualmente
autocontenidos. La detección de un error dentro de un módulo es menos complicada, ya que los
problemas asociados a un módulo no llegarán a trascender a los otros.
• Una segunda ventaja del diseño modular, es que el mantenimien-to de los módulos es más fácil. Las
modificaciones pueden limitarse a unos cuantos módulos y no al programa completo.
• Una tercera ventaja del diseño modular es que la problemática de los módulos es más fácil de
entender, ya que son sistemas autocontenidos. Eso significa que un lector entenderá la función de un
módulo especificó, con sólo tomar su listado de código.
Algunos lineamientos para la programación modular son:
• Mantener cada módulo de un tamaño manejable (de manera ideal incluyendo sólo una función).
• Prestar atención particular en las interfaces criticas (esto es, a los datos y a las variables de control que
pasan entre los módulos).
3. Minimizar el numero de módulos que el usuario necesite modificar cuando haga cambios.
4. Mantener las relaciones jerárquicas establecidas en las etapas de descenso.
3