ENFOQUE DE ADMINISTRACIÓN DE LA CALIDAD TOTAL

ENFOQUE DE ADMINISTRACIÓN DE LA CALIDAD TOTAL.

La administración de la calidad total (TQM, por sus siglas en inglés) es esencial a lo largo de todos los pasos del desarrollo de sistemas. Según Dean y Evans (1994), los principales elementos de la TQM sólo son significativos cuando se presentan en un contexto organizacional que favorece un esfuerzo integral por la calidad. Es en este contexto donde los elementos de enfoque en el cliente, planificación estratégica y liderazgo, mejora continúan, facultar al empleado y trabajo en equipo se unifican con el propósito de cambiar el comportamiento de los empleados y, en consecuencia, el curso de la organización.

SEISSEGMA.

La llegada de Seis Sigma ha cambiado el enfoque de la administración de la calidad. Cada analista de sistemas necesita estar consciente de Seis Sigma y aplicar algunos de los principios a sus proyectos de análisis de sistemas. Originalmente desarrollado por Motorola en la década de 1980, Seis Sigma es más que una metodología; 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. (Anexo Nº 1).

RESPONSABILIDAD DE LA ADMINISTRACIÓN DE LA CALIDAD TOTAL.

En términos prácticos, gran parte de la responsabilidad por la calidad de los sistemas de información recae en los usuarios de éstos y en los directivos. Para que la ADMINISTRACIÓN DE LA CALIDAD TOTAL (TQM) se vuelva una realidad en los proyectos de sistemas, deben darse dos condiciones. Primera, debe existir un apoyo organizacional incondicional por parte de los directivos, lo cual es distinto a simplemente respaldar el nuevo proyecto de los directivos.

Este apoyo significa establecer un con texto para que los directivos consideren seriamente cómo afecta su trabajo la calidad de los sistemas de información y la información misma. 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.

DISEÑO Y DESARROLLO DE SISTEMAS.

Diseño ascendente: Este diseño 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. Cuando la programación interna se hace con un enfoque de ascendente, es difícil interconectar los subsistemas de manera que se desempeñen fácilmente como un sistema. Es muy costoso corregir las fallas de la interconexión y muchas de ellas no se descubren sino hasta que se completa la programación, cuando los analistas intentan reunir el sistema en la fecha límite señalada para la entrega. En esta situación, hay poco tiempo, presupuesto o paciencia del usuario para la depuración de interconexiones delicadas que se han ignorado.

Diseño descendente: El diseño descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales, así como también determinar cómo se reúnen mejor en un sistema global. Después el analista divide dicho sistema en subsistemas y sus requerimientos.

DESARROLLO MODULAR.

Una vez que se toma el enfoque del diseño descendente, el enfoque modular es útil en la programación. Este enfoque implica dividir la programación en partes lógicas y manejables llamadas módulos.

El diseño de programa modular tiene tres ventajas principales. Primero, los módulos son más fáciles de escribir y de depurar porque prácticamente son independientes. Rastrear un error en un módulo es menos complicado, debido a que un problema en un módulo no debe causar problemas en otros.

Una segunda ventaja del diseño modular es que los módulos son más fáciles de mantener. Normalmente las modificaciones se limitarán a unos módulos y no seguirán en todo el programa.

Una tercera ventaja del diseño modular es que los módulos son más fáciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del código de un módulo y entender su función.

Algunos lineamientos para la programación modular incluyen lo siguiente:

1. Mantener cada módulo de un tamaño manejable, (incluir a la perfección una

sola función).

2. Poner particular atención a las interfaces críticas (los datos y variables de

control que se pasan a otros módulos).

3. Minimizar el número de módulos que el usuario debe modificar al hacer los

cambios.

4. Mantener las relaciones jerárquicas establecidas en las fases descendentes.

INGENIERÍA DE SOFTWARE Y DOCUMENTACIÓN.

La planeación y control son elementos fundamentales en todo sistema exitoso. En el desarrollo de software para el sistema, el analista de sistemas debe saber que la planeación tiene lugar en el diseño, incluso antes de que empiece la programación. Necesitamos técnicas que nos ayuden a establecer los objetivos del programa, de manera que nuestros programas estén completos.

PSEUDOCÓDIGO:

El pseudocódigo es similar al español estructurado porque no es un tipo particular de programar código, pero se puede usar como un paso intermedio para desarrollar el código de programa.

En la industria es común el uso del pseudocódigo, pero la falta de estandarización evitará que sea aceptado por todos. Debido a que el pseudocódigo está tan cerca del código de programa, naturalmente es favorecido por programadores y por consiguiente no es favorecido por analistas de negocios. El pseudocódigo con frecuencia se usa para representar la lógica de cada módulo en un diagrama de estructura.

MANUALES DE PROCEDIMIENTO:

Los manuales de procedimiento son documentos organizacionales comunes que la mayoría de las personas ha visto. Son el componente en Español de la documentación, aunque también podrían contener códigos de programa, diagramas de flujo, etc. Se pretende que los manuales comuniquen a aquellos que los usan.

Podrían contener comentarios de fondo, los pasos requeridos para lograr diferentes transacciones, instrucciones de cómo recuperarse de los problemas y qué hacer si algo no funciona (solucionar problemas). Actualmente muchos manuales están disponibles en línea, con capacidad de hipertexto que facilita el uso.

Las secciones importantes de un manual deben incluir una introducción, cómo usar el software, qué hacer si las cosas salen mal, una sección de referencia técnica, un índice e información de cómo contactar al fabricante. Los manuales en línea en los sitios Web también deben incluir información sobre descargar actualizaciones y una página de FAQ.

Los problemas con los manuales de procedimiento son que (1) están mal organizados, (2) es difícil encontrar la información necesaria en ellos, (3) el caso específico en cuestión no aparece en el manual y (4) el manual no está escrito en español. Más adelante, en la sección donde se habla de pruebas, discutimos la importancia de tener usuarios que "prueban" los manuales de sistemas y prototipos de los sitios Web antes de que se terminen.

EL MÉTODO DE FOLKLORE.

El FOLKLORE, es una técnica sistemática, basada en métodos tradicionales usados para recopilar el folklore sobre las personas y leyendas. Este enfoque para la documentación de sistemas requiere que el analista entreviste a los usuarios, investigue la documentación existente en los archivos y observe el procesamiento de información. El objetivo es recopilar la información correspondiente a una de cuatro categorías: costumbres, anécdotas, proverbios y formas artísticas. En Anexo Nº 2, sugiere cómo se relaciona cada categoría a la documentación de sistemas de información.

EL PROCESO DE PROBAR.

Aunque probar es tedioso, es una serie esencial de pasos que ayuda a asegurar la calidad del eventual sistema. Es mucho menos inquietante probar de antemano que tener un sistema probado deficientemente que falle después de la instalación. Las pruebas se realizan en subsistemas o módulos del programa conforme avance su desarrollo. Las pruebas se hacen en muchos niveles diferentes a varios intervalos. Antes de que el sistema se ponga en producción, todos los programas se deben verificar en el escritorio, verificar con datos de prueba y verificar para ver si los módulos trabajan entre sí como se planeó.

El sistema también se debe probar como un todo en funcionamiento. Incluso hay que probar las interfaces entre los subsistemas; la exactitud de salida; y la utilidad y entendimiento de la documentación y salida de sistemas. Como se muestra en el Anexo Nº 3, los programadores, analistas, operadores y usuarios cumplen un papel diferente en los varios aspectos a probar. Las pruebas de hardware normalmente se proporcionan como un servicio por los vendedores de equipo quienes ejecutarán sus propias pruebas en el equipo cuando se libere en el sitio.

Prueba de vínculos con datos de prueba: Cuando los programas pasan la verificación de escritorio y la verificación con datos de prueba, se deben pasar por las pruebas de vínculos, que también se conocen como prueba de cadena. Estas pruebas verifican si los programas que realmente son interdependientes trabajan juntos como se planeó.

Prueba completa de sistemas con datos de prueba: Cuando las pruebas de

...