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.

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:

• 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:

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.