Kendal y kendal

La calidad ha sido durante mucho tiempo una preocupacin para las empresas, como lo
debe ser para los analistas de sistemas en el anlisis y diseo de sistemas de
informacin. Es demasiado arriesgado emprender todo el proceso de anlisis y diseo
sin usar un enfoque de aseguramiento de la calidad. Dos propsitos guan el
aseguramiento de la calidad. El primero es que el usuario del sistema de informacin es
el factor individual ms importante en establecer y evaluar su calidad. El segundo es
que es mucho menos costoso corregir los problemas en sus fases iniciales que esperar
hasta que un problema se manifieste a travs de las quejas o crisis del usuario.

Los tres enfoques para el aseguramiento de la calidad mediante ingeniera de software
son: (1) garantizar el aseguramiento de la calidad total diseando sistemas y software
con un enfoque modular, descendente [de arriba a abajo); [2) documentar el software
con las herramientas adecuadas, y [3) probar, mantener y auditar el software.
SEIS SiGMA
La llegada de Seis Sigma ha cambiado el enfoque de la administracin de la calidad.
Cada analista de sistemas necesita estar consciente de Seis Sigma y aplicar algunos de
los principios a sus proyectos de anlisis de sistemas. Originalmente desarrollado por
Motorola en la dcada de 1980, Seis Sigma es ms que una metodologa; es una cultura
basada en la calidad.
La meta de Seis Sigma es eliminar todos los defectos. Esto se aplica a cualquier
producto, servicio o proceso. En los libros de texto de administracin de operaciones
que se publicaron a partir de la dcada de 1970 y hasta fines del siglo pasado, el control
de calidad se expres en trminos de tres desviaciones estndar de la media, o tres
sigma, lo cual es equivalente a aproximadamente 67,000 defectos por milln de
oportunidades. Seis Sigma implica una meta de slo 3.4 defectos por milln de
oportunidades.
Seis Sigma es un enfoque descendente de arriba a abajo. Se requiere que un CEO adopte
la filosofa y un ejecutivo funja como campen de proyecto. Un lder de proyecto de
SeisSigma se denomina Black Belt (cinta negra]. Las personas escogidas para ser Black
Belts pueden provenir de diferentes niveles e incluso diferentes niveles salariales, pero
deben tener experiencia en el proyecto y contar con capacitacin especial. Los Black
Belts se certifican despus que han liderado proyectos de manera exitosa. Los miembros
del proyecto se denominan Green Belts (cintas verdes). Los Black Belts maestros son
los Black Belts que han trabajado en muchos proyectos y estn disponibles como un
recurso para los equipos de proyectos. (La metfora de Black Belt viene del sistema de
clasificacin de capacidades en las artes marciales. Resalta la importancia de la
disciplina en todos los mbitos.]
DISEO Y DESARROLLO DE SISTEMAS
En esta seccin definimos los diseos de sistemas ascendente (de abajo a arriba o
bottom-up) y descendente (de arriba abajo o top-down), as como tambin el enfoque
modular para la programacin. Discutimos las ventajas de cada uno, as como tambin
las precauciones quese deben observar al emplear un enfoque descendente o uno
modular. Tambin discutimos las propiedades de los enfoques descendente y modular
para ayudar en el aseguramiento de la calidad de los proyectos de sistemas.

Diseo ascendente Este diseo se refiere a identificar los procesos que necesitan
computarizarse conforme surgen, analizarlos como sistemas y codificar los procesos o
comprar software empaquetado para resolver el problema inmediato. Los problemas que
requieren computarizarse normalmente se encuentran en el nivel ms bajo de la
organizacin. Con frecuencia este tipo de problemas son estructurados y por lo tanto
son ms sensibles a la computarizacin; tambin son los ms rentables. Por lo tanto, el
nombre ascendente se refiere al nivel inferior en el cual se introduce primero la
computarizacin. Por ejemplo, con frecuencia los negocios toman este enfoque para el
desarrollo de sistemas al adquirir software comercial para la contabilidad, un paquete
diferente para la programacin de produccin y otro para el marketing.

Cuando la programacin interna se hace con un enfoque de ascendente, es difcil
interconectar los subsistemas de manera que se desempeen fcilmente como un
sistema. Es muy costoso corregir las fallas de la interconexin y muchas de ellas no se
descubren sino hasta que se completa la programacin, cuando los analistas intentan
reunir el sistema en la fecha lmite sealada para la entrega. En esta situacin, hay poco
tiempo, presupuesto o paciencia del usuario para la depuracin de interconexiones
delicadas que se han ignorado. Aunque cada subsistema aparenta conseguir lo que
quiere, al considerar el sistema global hay serias limitantes para tomar un enfoque de
ascendente. Una es que hay duplicidad de esfuerzo en comprar software e incluso en
introducir los datos. Otra es que se introducen datos invlidos en el sistema. Una
tercera, y quizs la desventaja ms seria del enfoque ascendente, es que no se
consideran los objetivos organizacionales globales, y por lo tanto dichos objetivos no se
pueden cumplir.

Diseo descendente Es fcil visualizar este enfoque; significa ver una descripcin
amplia del sistema y despus dividirla en partes ms pequeas o subsistemas. El diseo
descendente permite a los analistas de sistemas determinar primero los objetivos
organizacionales globales, as como tambin determinar cmo se renen mejor en un
sistema global. Despus el analista divide dicho sistema en subsistemas y sus
requerimientos.

Las ventajas de usar un enfoque descendente para el diseo de sistemas incluyen evitar
el caos de intentar disear un sistema de repente. Como hemos visto, planear e
implementar sistemas de informacin de administracin es increblemente complejo.
Intentar colocar todos los subsistemas en su lugar y ejecutarlos en seguida es casi un
fracaso seguro. Una segunda ventaja de tomar un enfoque descendente para disear es
que permite separar a los equipos de anlisis de sistemas para trabajar en paralelo en
diferentes subsistemas, lo cual puede ahorrar mucho tiempo. El uso de equipos para el
diseo de subsistemas se ajusta particularmente bien a un enfoque de control de calidad
total.

Una tercera ventaja es que un enfoque descendente evita un problema mayor asociado
con un enfoque ascendente; evita que los analistas de sistemas se metan tanto en los
detalles que pierdan de vista lo que se supone que el sistema hace. Hay algunas
dificultades con el diseo descendente que el analista de sistemas necesita saber. La
primera es el riesgo de que el sistema se divida en subsistemas "errneos". Se debe
poner atencin a las necesidades que se traslapen y a la comparticin de recursos de
manera que la particin en subsistemas tenga sentido para todos los sistemas. Adems,
es importante que cada subsistema solucione el problema correcto.

Un segundo riesgo es que una vez que se hacen las divisiones de un subsistema, sus
interfaces se podran descuidar o ignorar. Es necesario detallar de quin es la
responsabilidad de las interfaces.
Una tercera advertencia que acompaa al uso de un diseo descendente es que los
subsistemas se deben reintegrar eventualmente. Los mecanismos para la reintegracin
se necesitan poner en funcionamiento desde el principio. Una sugerencia es negociar
informacin regular entre los equipos del subsistema; otra es usar herramientas que
permiten flexibilidad si se requieren cambios para los subsistemas interrelacionados.
La administracin de la calidad total y el enfoque descendente para disear pueden estar
relacionados. El enfoque descendente proporciona el grupo de sistemas con una divisin
ms natural de usuarios en grupos de trabajo para subsistemas. Los grupos de trabajo
establecidos de esta forma despus pueden servir a una funcin dual como crculos de
calidad para el sistema de informacin de administracin. La estructura necesaria para
el control de calidad est en el lugar, as como la motivacin apropiada para obtener el
subsistema para lograr las metas departamentales que son importante para los usuarios
involucrados.

Una vez que se toma el enfoque del diseo descendente, el enfoque modular es til en la
programacin. Este enfoque implica dividir la programacin en partes lgicas y
manejables llamadas mdulos. Este tipo de programacin funciona bien con el diseo
descendente porque da nfasis a las interfaces entre los mdulos y no los descuida hasta
el final del desarrollo de sistemas. Idealmente, cada mdulo individual debe ser
funcionalmente cohesivo de manera que se encargue de realizar una sola funcin.
El diseo de programa modular tiene tres ventajas principales. Primero, los mdulos son
ms fciles de escribir y de depurar porque prcticamente son independientes. Rastrear
un error en un mdulo es menos complicado, debido a que un problema en un mdulo
no debe causar problemas en otros.

Una segunda ventaja del diseo modular es que los mdulos son ms fciles de
mantener.
Normalmente las modificaciones se limitarn a unos mdulos y no seguirn en todo el
programa. Una tercer ventaja del diseo modular es que los mdulos son ms fciles de
entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede
adquirir una lista del cdigo de un mdulo y entender su funcin.

Algunos linchamientos para la programacin modular incluyen lo siguiente:
1. Mantener cada mdulo de un tamao manejable (incluir a la perfeccin una sola
funcin).
2. Poner particular atencin a las interfaces crticas (los datos y variables de control que
se pasan a otros mdulos].
3. Minimizar el nmero de mdulos que el usuario debe modificar al hacer los cambios.
4. Mantener las relaciones jerrquicas establecidas en las fases descendentes.

MODULARIDAD EN EL ENTORNO DE WINDOWS
La modularidad se est volviendo muy importante. Microsoft desarroll dos sistemas
para vincular los programas en su entorno de Windows. El primero se llama
intercambio dinmico de datos (DDE], el cual comparte cdigo al usar archivos de
biblioteca de vnculos dinmicos

(DLL). Al usar DDE, un usuario puede almacenar datos en un programa quizs en
una hoja de clculo tal como Excel y despus usar dichos datos en otro programa, por
decir, en un paquete de procesamiento de texto tal como Word para Windows. El
programa que contiene los datos originales se denomina servidor y el programa que los
usa se denomina cliente. El vnculo de DDE se puede establecer de manera que cuando
se abra el archivo de procesamiento de texto del cliente, los datos se actualicen
automticamente y se reflejen los cambios hechos en el archivo de hoja de clculo del
servidor desde la ltima vez que se abri dicho archivo de procesamiento de texto.

Uno de los archivos de la DLL normalmente usados es COMMDLG.DLL, el cual
contiene los cuadros de dilogo de Windows para Abrir Archivos, Guardar Archivos,
Buscar e Imprimir. Una ventaja de usar este archivo es que los programas tendrn la
misma apariencia y funcionamiento que otros programas de Windows. Tambin acelera
el desarrollo, debido a que los programadores no tienen que escribir el cdigo contenido
en los archivos DLL ms comunes. Un segundo enfoque para vincular programas en
Windows se denomina vinculacin e incrustacin de objetos (OLE). Este mtodo de
vincular programas es superior a DDE porque est ligado a los datos y grficos de la
aplicacin. Mientras que DDE utiliza un enfoque de cortar y pegar para vincular datos y
no retiene el formato, OLE retiene todas las propiedades de los datos creados
originalmente. Este enfoque orientado a objetos permanecer en la aplicacin del cliente
y editar los datos originales en la aplicacin del servidor.

Con OLE, cuando un usuario final hace clic en el objeto incrustado, se despliega una
barra de herramientas que permite la edicin visual.

La herramienta recomendada para disear un sistema modular descendente se denomina
diagrama de estructura. Este grfico simplemente es un diagrama que consiste de
cuadros rectangulares, los cuales Es necesario que tanto el analista como la empresa se
comprometan desde el principio con la calidad para lograr la meta de calidad. Este
compromiso da como resultado un esfuerzo uniformemente controlado hacia la calidad
durante todo el ciclo de vida del desarrollo de sistemas, y est en marcado contraste con
tener que dedicar gran cantidad de esfuerzo para resolver problemas al final del
proyecto.
El apoyo organizacional para conseguir calidad en sistemas de informacin de
administracin se puede lograr al proporcionar tiempo en el trabajo para los crculos de
calidad de SI, los cuales consisten de seis a ocho pares organizacionales
especficamente responsables de considerar cmo mejorar los sistemas de informacin y
cmo implementar las mejoras.
Mediante el trabajo en los crculos de calidad de SI o a travs de otros mecanismos ya
colocados, la administracin y usuarios deben desarrollar lineamientos para los
estndares de calidad de sistemas de informacin. Preferentemente, los estndares se
redisearn cada vez que un nuevo sistema o una modificacin mayor se proponen
formalmente por el equipo de anlisis de sistemas.
No es fcil crear los estndares de calidad, pero es posible y se ha hecho. Parte del
trabajo del analista de sistemas es alentar a usuarios a que cristalicen sus expectativas
acerca de los sistemas de informacin y sus interacciones con stos.

Los estndares de calidad departamentales se deben comunicar mediante
retroalimentacin para el equipo de anlisis de sistemas. Normalmente el equipo est
sorprendido por lo que se ha desarrollado. Las expectativas generalmente son menos
complejas de lo que analistas experimentados saben se podra hacer con un sistema.
Adems, los problemas humanos que se han omitido o menospreciado por el equipo del
analista se podran disear como extremadamente urgentes en los estndares de calidad
que fijen los usuarios. Involucrar a los usuarios en explicar los estndares de calidad
para los sistemas de informacin ayudarn al analista a evitar errores costosos en el
desarrollo de sistemas no deseados o innecesarios.

Laudon Kenneth y jane
Ingeniera de software auxiliada por computadora
La ingeniera de software auxiliada por computadora (CASE), algunas veces
conocida como ingeniera de sistemas auxiliada por computadora, provee herramientas
de software para automatizar las metodologas que acabamos de describir para reducir la
cantidad de trabajo repetitivo que necesita realizar el desarrollador. Las herramientas
CASE tambin facilitan la creacin de una documentacin clara y la coordinacin de los
esfuerzos de desarrollo en equipo. Los miembros del equipo pueden compartir su
trabajo con facilidad al acceder a los archivos de los dems para revisar o modificar lo
que ya se ha hecho. Tambin se pueden lograr beneficios modestos de productividad si
las herramientas se utilizan de manera apropiada.

Las herramientas CASE cuentan con herramientas de grficos automatizadas para
producir tablas y diagramas, generadores de pantallas e informes, diccionarios de datos,
herramientas para informes extensos, herramientas de anlisis y comprobacin,
generadores de cdigo y generadores de documentacin. En general, las herramientas
CASE tratan de incrementar la productividad y la calidad al:
Hacer valer una metodologa de desarrollo y una disciplina de diseo estndar
Mejorar la comunicacin entre los usuarios y los especialistas tcnicos
Organizar y correlacionar los componentes de diseo y proveer acceso rpido a ellos
mediante un almacn de diseo
Automatizar las porciones tediosas y propensas a errores del anlisis y diseo
Automatizar la generacin de cdigo y el despliegue de la prueba y el control
Las herramientas CASE contienen caractersticas para validar diagramas de diseo y
especificaciones. Por ende, las herramientas CASE soportan el diseo iterativo al
automatizar las revisiones y los cambios, y al proveer habilidades para crear prototipos.

Un almacn de informacin CASE guarda toda la informacin definida por el anlisis
durante el proyecto. El almacn indica los diagramas de flujo de datos, los diagramas de
estructura, los diagramas entidad-relacin, las definiciones de datos, las especificaciones
de los procesos, los formatos de las pantallas e informes, las notas y comentarios, y los
resultados de las pruebas. Para usarse con efectividad, las herramientas CASE requieren
una disciplina organizacional. Cada miembro de un proyecto de desarrollo se debe
adherir a un conjunto comn de convenciones de nomenclatura y estndares, as como a
una metodologa de desarrollo. Las mejores herramientas CASE respetan los mtodos y
estndares comunes, lo cual puede provocar que se dejen de usar en situaciones en
donde no exista una disciplina organizacional.
13.3