VI.

CONTROL DE LA CALIDAD DEL SISTEMA Y PUESTA EN

MARCHA

1. ASEGURAMIENTO DE LA CALIDAD

Asegurar la calidad es la revisión de los productos de software y la documentación

relacionada para que sean completos, correctos, confiables y mantenibles, y que incluye
asegurar que los sistemas cumplan las especificaciones y requerimientos que se
proyectaron para sus uso y desempeño. Se utilizan cuatro niveles para asegurar la
calidad:

La prueba de sistemas es el proceso de ejecutar un programa con la intención específica

de encontrara errores; es decir, hacer que el programa falle. Este es un proceso caro pero
crítico, que puede utilizar hasta el 50% del presupuesto del desarrollo de programas. En
general, la prueba se lleva a cabo para probar que no existen errores en un programa.

La verificación se desarrolla al ejecutar un programa en un ambiente simulado. También

se utiliza con el objeto de encontrar errores. La validación se refiere al proceso de utilizar
el software en un ambiente real para encontrara errores.

La certificación del software es la confirmación de que el programa es correcto. Esto se

hace citando a un grupo de especialistas, quienes examinan cuidadosamente la
documentación del sistema para determinar que lo que el vendedor afirma es en realidad
lo que el sistema hace, probando el paquete contra las características de venta.

1.1 Estrategias de Prueba

Un caso de prueba es un conjunto de datos que el sistema procesará como una entrada
normal; sin embargo, los datos son creados con la intención expresa de determinar si el
sistema los procesará correctamente. Existen dos estrategias generales para probar el
software, éstas son:

- Prueba de Código: Examina la lógica del programa. El analista desarrolla casos de

prueba que resultan en la ejecución de cada instrucción del programa o módulo; es decir,
cada ruta dentro del programa se prueba. Una ruta es una combinación específica de
condiciones. En general la prueba de código parece ser un método ideal para probar el
software.

- Prueba de Especificación: Se examinan las especificaciones que el programa debe

hacer y cómo debe desempeñarlas bajo diferentes condiciones. Este tipo de prueba es
una mejor estrategia dado que se enfoca a la manera en la que se espera que el software
sea utilizado.

- Prácticas de Prueba: Los niveles de prueba y tipos de datos de pruebas acoplados con
las bibliotecas de prueba son aspectos importantes del proceso actual de prueba. Los
sistemas no están diseñados como sistemas enteros ni son probados como sistemas
solos.

1.2 Niveles de Prueba

Existen tres niveles de prueba que son: prueba unitaria, prueba del sistema y pruebas
especiales

- Prueba unitaria. En esta prueba el analista verifica los programas que conforman un
sistema (prueba de programas). Las unidades de software en un sistema son los módulos
y rutinas que se ensamblan e integran para desempeñar una función específica.

La prueba unitaria se enfoca primero a los módulos, independientes uno del otro, para
localizar errores. Se puede llevar a efecto de abajo hacia arriba, comenzando con los
módulos más pequeños y de menor nivel y desarrollando uno a la vez.

En la prueba ascendente un programa corto (programa conductor), ejecuta el módulo y

proporciona los datos necesarios, de modo que se le pide al módulo desempeñar, en
todas las formas, lo que tiene que hacer dentro de un sistema mayor. En la descendente
se comienza con los módulos de mayor nivel; sin embargo, dado que las actividades
detalladas normalmente, desempeñadas en las rutinas de menor nivel, no se
proporcionan se escriben los módulos esclavos.

Un módulo esclavo es aquél que puede ser llamado por el módulo de mayor nivel; y
cuando se le alcanza apropiadamente, regresará un mensaje al módulo que lo llamó,
indicando que ocurrió la interacción en forma apropiada.

- Prueba de sistemas. Esta no prueba el software, sino la integración de cada módulo en

el sistema. También hace pruebas para encontrar discrepancias entre el sistema y su
objetivo original, las especificaciones actuales y la documentación de sistemas

Se trata de encontrar áreas en donde los módulos se han diseñado con diferentes
especificaciones para la longitud de datos, tipo y nombre de los elementos dato. La
principal preocupación es la compatibilidad de los módulos individuales. Esta prueba debe
verificar también que el tamaño de los archivos sea adecuado y que se han construido
apropiadamente los índices.

- Pruebas especiales de sistemas. Estas pruebas no se enfocan a la forma normal de

trabajo de un sistema y son la siguientes: de carga pico (búsqueda de momentos críticos
reales); de almacenamiento (se miden en términos del número de registros que un disco
puede manejar o que un archivo puede contener; estas capacidades están ligadas a un
espacio en disco y al tamaño de los índices, llaves de registro, etc.); de desempeño en
tiempo (se lleva a cabo antes de poner en marcha el sistema para determinar cuánto
tomará recibir una respuesta a una consulta, obtener un copiado de respaldo de un
archivo o enviara una transmisión y recibir respuesta. Incluye corridas de prueba para
reindizar el tiempo o reclasificar los archivos grandes); de recuperación (creando una
situación de falla o pérdida de datos en donde se vean forzados a volver a cargar y
recuperar una copia de respaldo, para determinar si los procedimientos son los
adecuados); de procedimiento (se pide seguir los pasos indicados en los procedimientos
para verificar lo presentado en los manuales de documentación y de trabajo); de factores
humanos (encontrar respuesta a las preguntas sobre cómo reaccionará la gente al
sistema en formas que no hayan anticipado).

1.3 Diseño de Datos de Prueba

Existen dos fuentes de datos de prueba que son:

- Datos reales: Extraídos de los archivos de la empresa; es difícil obtener datos reales en
cantidades suficientes para llevar a cabo una prueba extensiva. Estos no permitirán
probar todas las combinaciones o formatos que pueden introducirse al sistema.

- Datos artificiales: Se crean únicamente para propósitos de prueba, dado que se

generan para probar todas las combinaciones de formatos y valores. Hacen posible la
prueba de todas las rutas lógicas y de control, a través del programa.

1.4 Bibliotecas de Prueba

Una biblioteca de prueba es un conjunto de datos desarrollados para probar

completamente un sistema de programas; se almacena en forma legible por la máquina, y
se utiliza por todas las que trabajan con un sistema específico. Estas no son sólo para la
prueba inicial; conforme el sistema evoluciona y los programas se van modificando y
manteniendo se deben volver a probar.

2. PUESTA EN MARCHA DE SISTEMAS

Los aspectos importantes a considerar en la puesta en marcha de un sistema,

independiente de que sea nuevo o un reemplazo, son los siguientes: capacitación del
personal, procedimientos de conversión, y revisión posterior a la puesta en marcha.

2.1 Capacitación del Personal

La calidad de la capacitación del personal involucrado con el sistema en varias de sus

facetas, ayuda o dificulta y puede incluso obstaculizar por entero el éxito de la puesta en
marcha de un sistema de información

- Capacitación de operadores de sistemas: Debe garantizar que están en condición

para manejar todas las operaciones posibles, tanto de rutina como extraordinarias
(encendido, operación, y apagado del equipo; errores comunes, cómo detectarlos y tomar
medidas). También debe incluir la preparación del personal de manejo de datos
(perforadores y capturadores).

- Capacitación de usuarios: Existen dos aspectos para la capacitación del usuario: uno,
la familiaridad con el sistema de procesamiento (equipo usado para los datos de
entrada o su procesamiento); y dos, en el empleo de la aplicación (software que acepta
los datos, los procesa y produce resultados). Debe instruirlo en la solución de problemas
dentro del sistema. Debe incluir una guía de problemas comunes en la documentación del
sistema.

La capacitación en la codificación de datos destaca los métodos que han de seguirse en

la captación de datos, a partir de transacciones, o en la preparación de datos necesarios
para las actividades de apoyo a las decisiones. Las actividades de manejo de datos que
recibe la máxima atención dentro de la capacitación de usuarios son las entradas de
nuevos datos, edición de datos, formulación de consultas, obtención de respuestas a
preguntas, y borrara registros de datos.
Los métodos y el contenido de la capacitación varían a menudo y dependen del origen
y de la ubicación de la capacitación. Las actividades pueden llevarse a cabo en las
instalaciones de venta, en lugares alquilados, o en las instalaciones de la compañía.

- Capacitación por parte de los proveedores y en locales de servicio: Con frecuencia

el mejor instructor para capacitar al personal sobre el equipo proviene del vendedor que lo
proporciona. Los cursos conducidos por capacitadores experimentados y por personal de
ventas cubren todos los aspectos del empleo del equipo, desde cómo encenderlo y
apagarlo, hasta el almacenamiento y eliminación de datos, incluyendo el manejo de las
funciones deficientes.

Si se instala software especial, como un paquete de teleprocesamiento o un sistema de

manejo de bases de datos, es preferible enviar al personal a cursos externos que
proporcionen capacitación completa.

- Capacitación dentro de la compañía: La ventaja que ofrece radica en que la

instrucción se puede adecuar a las necesidades de la empresa donde se efectúa, y se
puede centrar en los procedimientos especiales que se emplean, en le crecimiento que se
ha planeado y en los problemas que surgen.

Los manuales de capacitación pueden adoptar uno de dos enfoques: algunos llevarán al
usuario a trabajar a diferentes actividades por etapas; otros, a la creación de un caso para
estudio que incluye con frecuencia todas las circunstancias encontradas que el sistema
puede manejar y que los usuarios deberán ser capaces de enfrentar.

Durante el entrenamiento el personal de sistemas debe mantenerse preparado para

recibir comentarios hechos por los usuarios o para detectar problemas que éstos
encuentran con frecuencia.

2.2 Conversión

La conversión es el proceso de cambio del sistema antiguo al nuevo. Existen cuatro

métodos para mejorar la conversión de sistemas; cada uno se debe considerar de
acuerdo a las oportunidades que ofrece y los problemas que pudiera originar. Los
métodos son los siguientes:

- Sistemas paralelos: Radica en operar ambos sistemas en forma paralela, lo que

significa que los usuarios continúan operando el sistema viejo de la manera
acostumbrada, pero empiezan también a emplear el nuevo sistema. Este método permite
la puesta en marcha más segura, en caso de dificultades, pero no se pueden ignorar los
costos y riesgos de no ensayar adecuadamente el sistema.

- Cambio directo: Este método convierte el sistema viejo al nuevo de manera repentina.
Obliga a los usuarios a hacer que funcione el nuevo sistema; pero tiene el inconveniente
de no tener un apoyo si surgen dificultades.

El cambio directo requiere de una planificación cuidadosa por adelantado; la capacitación

se debe programar y mantener; y la instalación de todo el equipo debe ser puntual con
fechas precisas dentro del programa para corregir las dificultades que puedan ocurrir.
- Enfoque piloto: Una versión práctica del sistema se pone en marcha en una parte de la
empresa; cuando se calcula que el sistema está completo, se instala en toda la compañía
ya sea de una sola vez (cambio directo), o en forma gradual (por etapas).
- Por etapas: Se emplea cuando no es posible instalar un sistema nuevo en toda la
compañía de manera simultánea. La conversión de archivos, capacitación de personal o
la llegada de equipo pueden forzar a la puesta en marcha gradual.

El plan de conversión incluye una descripción de todas las actividades que deben
llevarse a cabo para poner en práctica el sistema nuevo y ponerlo en operación;
asimismo, identifica a las personas que son responsables de cada actividad e incluye una
distribución de horarios que estipula cuándo ocurrirá cada actividad.

Cuando la conversión está en la etapa de planeación se debe preparar un alista de todas

las tareas incluyendo las siguientes:

- Lista de todos los archivos que se usarán en la conversión.

- Identificación de todos los datos que se requieran para la construcción de archivos
nuevos durante la conversión.
- Lista de todos los documentos y procedimientos nuevos que se usarán durante la
conversión.
- Identificación de todos los controles que se utilizarán durante la conversión.
- Determinación de responsabilidades para cada actividad.
- Verificación de programas de conversión.

El plan de conversión debe anticipar los posibles problemas y métodos para enfrentarlos.
Entre los problemas más frecuentes se encuentran: documentos faltantes; formatos con
datos cruzados entre los archivos actuales y los nuevos; errores en la traducción de
datos; datos faltantes o archivos perdidos y circunstancias que no se previeron durante el
desarrollo de sistemas.

La preparación del sitio de trabajo es ideal que esté preparado antes de la llegada del
equipo. El cliente y los ingenieros de sistemas deben presentar una lista de
especificaciones para disponer el cableado del sistema eléctrico, las tomas de corriente,
las necesidades del sistema de aire acondicionado, los controles de humedad y los
requisitos de espacio.

La disposición del lugar deberá incluir amplio espacio para el movimiento de equipo y su
disposición para operación normal; los proveedores deberán proporcionar los requisitos
de espacio para las actividades de operación, mantenimiento y circulación del aire.

La preparación de datos y archivos maestros del sistema es, junto con la capacitación,
el aspecto que lleva más tiempo en la conversión. Los controles sugeridos incluyen:
Cuentas de registro (cerciorarse de que todos los registros han entrado al sistema; al
final del proceso de conversión, el número de registros en los archivos maestros del
sistema deberá ser igual al número de registros del sistema antiguo); totales financieros
(además de asegurar que todos los registros se convierten a los nuevos archivos, los
gerentes de conversión deberán verificar su exactitud financiera); totales de control
preestablecidos (los totales de control, sumas de aspectos no financieros, proporcionan
protección adicional durante la conversión); y situaciones que implican transmisión de
datos (cuando entran datos al sistema mediante terminales en localidades distintas, se
incluyen precauciones adicionales en la conversión; cada transacción se debe identificar
con un número secuencial para proporcionar un método que garantice que cada
transacción inscrita se ha recibido y se ha incluido en los nuevos archivos).
2.3 Revisión Posterior a la Puesta en Marcha

Después de que el sistema se pone en marcha y se termina la conversión, se lleva a cabo

una revisión del sistema por los usuarios y los analistas, lo que no es sólo una tendencia
normal, sino que debe ser un proceso formal para determinar qué tan bien está trabajando
el sistema, cómo se ha aceptado y si son necesarios varios ajustes.

La revisión es también importante para obtener información que sirve al mantenimiento

del sistema. La revisión posterior a la puesta en marcha proporciona la primera fuente de
información respecto a requisitos de mantenimiento.