CIRCULAR EXTERNA 17 DE 1999

 

CIRCULAR EXTERNA 17 DE 1999 

(Febrero 26)

Asunto: Fase de pruebas de los planes de acción del Proyecto Año 2000.

En adición a lo establecido en las circulares relacionadas con los planes de acción y los procesos de certificación que deben realizar las entidades vigiladas para hacer frente a la problemática del año 2000, esta superintendencia ha estimado conveniente instruir a sus vigilados sobre los aspectos relevantes a considerar en la fase de pruebas.

Para tal efecto, se anexa a la presente circular el documento “Guía para el seguimiento y control de la fase de pruebas del proyecto año 2000”, que contiene los lineamientos que las entidades vigiladas deben seguir.

La presente circular rige a partir de la fecha de su publicación en el Diario Oficial.

N. del D.: La presente circular va dirigida a representantes legales y revisores fiscales de las entidades vigiladas.

Guía para el seguimiento y control de la fase de pruebas del proyecto año 2000

1. Introducción

Este documento es una guía de uso general para todas las entidades vigiladas por la Superintendencia Bancaria, y les ayudará a determinar si la institución está enfrentando en forma adecuada la fase de pruebas que hace parte fundamental de sus planes de acción para evitar los posibles problemas que puedan generarse en los sistemas informáticos, telemáticos y otros relacionados con la operación del negocio, con ocasión de la llegada del nuevo milenio.

2. Objetivos

Determinar si la organización cuenta con un plan efectivo de pruebas para garantizar que sus sistemas de misión crítica estarán preparados para afrontar el cambio de milenio.

Determinar si la organización ha coordinado de manera eficiente y coherente sus esfuerzos internos, con proveedores y clientes.

Identificar en qué puntos del proceso adelantado existen debilidades y se deben tomar los correctivos más severos para asegurar un proceso de pruebas que garantice la operación de los sistemas de misión crítica.

3. Aspectos generales a considerar

La organización debe tener un plan de pruebas, documentado y en funcionamiento, para sus sistemas de misión crítica tanto internos como externos (incluyendo software, bases de datos, hardware y redes).

Las directivas de la organización deben estar conscientes de la importancia de la fase de pruebas para llevar a buen término la solución del problema del año 2000. Por tal razón, deben asegurarse de que el personal dedicado a estas actividades tenga el conocimiento y la destreza en el tema. De igual forma, deben ser conscientes de los recursos humanos y financieros que se requieren para el proceso.

Este plan debe estar aprobado por el comité año 2000 y sus resultados deben ser sujeto de información tanto para la administración de la entidad como para su junta directiva.

El plan debe incluir aspectos como: Cuál es el alcance del proceso; cuál es el ambiente o entorno en donde se realizan las pruebas; la metodología de pruebas o comprobación utilizada; los cronogramas de pruebas; recursos humanos y financieros involucrados en el plan; procedimientos de aceptación y rechazo de resultados; fechas críticas de pruebas, y la documentación.

3.1. Sistemas y servicios sujetos al proceso de pruebas. Las instituciones vigiladas deberán probar primero sus sistemas de misión crítica, entendiendo por éstos los que son vitales para la continuación satisfactoria de su negocio. Una aplicación o un dato puede catalogarse como de misión crítica si interactúa o se interconecta con un sistema que ha sido identificado como de misión crítica.

Deberán considerarse:

Los sistemas desarrollados internamente.

Los servicios suministrados por proveedores externos o terceros.

Las soluciones de software suministradas por empresas desarrolladoras o distribuidoras de productos.

Los sistemas computacionales, las redes locales y remotas.

Las redes de cajeros electrónicos y otros dispositivos asociados con la prestación de servicios electrónicos.

Las bases de datos y datos relacionados con los procesos y sistemas de misión crítica.

Otras terceras personas.

Otros dispositivos electrónicos.

3.2. Metodología de pruebas. La Superintendencia Bancaria es consciente de que no existe un método único para la realización de pruebas del año 2000. La variedad de pruebas existentes va desde las pruebas que se realizan en el ámbito propio de la institución hasta las pruebas que se delegan a terceras personas. Por tal motivo, cada institución financiera debe haber determinado cuáles de las diferentes metodologías de prueba utiliza, sobre la base de la complejidad de sus operaciones, de sus sistemas, su nivel de interconexión con redes internas o externas, propias o de terceros, su grado de exposición al año 2000 y su dependencia de terceras personas para los productos y servicios basados en la tecnología informática.

A continuación se describen algunos tipos de pruebas:

Pruebas de base. Se utilizan antes de hacer cualquier cambio a un programa o aplicación informática. Este tipo de pruebas le permiten a las instituciones vigiladas comparar el rendimiento y los resultados de los sistemas después de haber realizado cambios en los mismos. Es la base de las comparaciones.

Pruebas unitarias. Se realizan a un programa o aplicación para confirmar que los esfuerzos de corrección o rehabilitación producen resultados exactos para esa aplicación. Sin embargo, este tipo de pruebas no comprueban cómo operará la aplicación junto con otras aplicaciones.

Pruebas integradas. Se ejecutan en forma simultánea en aplicaciones o sistemas que interactúan. El propósito es verificar que estos programas que operan en forma interdependiente funcionan correctamente.

Pruebas regresivas. Se ejecutan con datos previos al año 2000, con el objeto de asegurar que los resultados obtenidos por el sistema corregido son iguales a los del sistema original, confirmándose de esta manera que no se han introducido errores en el proceso de rehabilitación. La prueba regresiva debe aplicarse tanto a las partes modificadas como aquellas que no se modificaron.

Pruebas de fechas futuras. Es una simulación del procesamiento de sistemas y aplicaciones rehabilitadas, para fechas futuras críticas, con el fin de cerciorarse que esas fechas no causarán problemas a los programas o sistemas informáticos.

Pruebas de aceptación de usuarios. Se ejecuta con el usuario y es en esa forma como se valida el hecho de que la rehabilitación se llevó a cabo correctamente y que los sistemas funcionarán tal y como se espera.

Pruebas punto a punto. Sirve para verificar la capacidad de una institución para transmitir o recibir datos, a otra o de otra entidad o sistema.

Pruebas extremo a extremo. Sirve para verificar la capacidad de una institución para realizar transacciones electrónicas o intercambio de información a una entidad o sistema a través de otros agentes o sistemas que sirven como intermediarios del proceso.

Pruebas proxy. Son de gran utilidad cuando se trata de evaluar la preparación que en cuanto al año 2000 tienen los proveedores de servicios. Se fundamenta en la realización de pruebas con muestras representativas de entidades vigiladas que utilizan un servicio en particular y en la misma plataforma tecnológica. Los resultados de las pruebas se comparten con los clientes del proveedor de servicios que tengan una situación similar.

Estos tipos de pruebas pueden ser utilizados sobre sistemas de información, aplicativos, datos y hardware en general.

4. Aspectos específicos del plan de pruebas

El proceso de pruebas debe considerar cuando menos los aspectos relacionados a continuación:

4.1. Alcance

Identificación de sistema a probar.

Tipo o metodología de pruebas a utilizar.

Descripción o enfoque de las pruebas:

• Para constatar que el programa funciona como se diseñó.

• Para ver dónde produce errores el programa.

• Para ver cómo se integra con otros sistemas.

• Para comprobar datos y su integridad con otros datos y sistemas de información.

Identificación de las funciones, comandos, características, transacciones, interfases de usuario, interfases internas y externas y archivos de datos a probar.

Necesidad de probar uno o varios sistemas o aplicaciones a la vez.

Dependencias o entidades vinculadas o relacionadas con el sistema que se prueba.

Herramientas de prueba a utilizar.

Fechas críticas a probar.

Resultados esperados.

4.2. Ambiente de pruebas

Se refiere a los aspectos técnicos, logísticos y de infraestructura que deben ser considerados para la realización de las pruebas. Este proceso debe consultar la capacidad computacional de la institución, así como la compelida del negocio y sus interrelaciones con otros agentes externos o internos. Cuando menos debe contemplar:

Definición de los recursos computacionales sobre los cuales o con los cuales se ejecutarán las pruebas, para lo cual debe analizarse la conveniencia de utilizar esquemas como:

• Ambiente dedicado a pruebas.

• Particiones específicas para pruebas.

• Sistemas de producción en horas no hábiles.

• Equipos del plan de contingencia de la institución.

• Pruebas proxy.

• Uso de múltiples sistemas de pruebas.

Las pruebas no deberían realizarse sobre equipos de producción, es preferible ejecutarlas sobre instalaciones de cómputo separadas o sobre la infraestructura tecnológica que utiliza la institución para la atención de contingencias. De cualquier manera, independiente del esquema de pruebas que elija la institución, deberá tenerse en cuenta la forma en la cual toda la infraestructura computacional y las interconexiones, tanto internas como externas, serán reproducidas para pruebas y cómo posteriormente se garantizará que este ambiente de pruebas sea equivalente al ambiente de producción donde finalmente se implantarán los sistemas rehabilitados.

Para el caso de las pruebas proxy, se debe seleccionar una muestra representativa del conjunto de instituciones que utilizan los servicios a probar. La prueba debe considerar:

• Tipo de institución.

• Tamaño de la institución.

• Alcance de la prueba.

• Versión de software.

• Versión del hardware y sistema operacional.

• Características del sistema que utiliza cada entidad y qué aspectos particulares de cada una de ellas no se incluyen en las pruebas.

• El grupo de instituciones de prueba debe tener independencia del proveedor del servicio.

• Conclusiones en cuanto a la aplicabilidad de la prueba para cada institución.

Definición clara del conjunto de operaciones y datos a probar.

Escenarios de pruebas a ejecutar.

Duración de las pruebas.

4.3. Planeación de recursos necesarios para las pruebas

Las directivas de las entidades vigiladas y sus comités de año 2000 deberán disponer los recursos financieros, humanos, tecnológicos, y de infraestructura física necesarios para llevar a buen término los planes de pruebas de los sistemas computacionales con los riesgos que conlleva el cambio de milenio.

Cuando menos deben tener en cuenta:

Definición del alcance de las pruebas.

Alistamiento del ambiente de pruebas definido.

Estimación y alistamiento de la capacidad computacional requerida para la prueba.

Definición y preparación de los formularios de pruebas a ejecutar.

Preparación de bases de datos y archivos de datos a probar.

Preparación y disposición de equipos de pruebas.

Preparación y disposición de usuarios para pruebas.

Preparación y disponibilidad de los terceros involucrados.

Procedimientos de auditoría.

Procedimientos de rechazo y aceptación.

Responsables de la planeación de las pruebas y de su aceptación o rechazo.

Procedimientos de protección de los sistemas y datos de producción.

Procedimientos de retorno a la operación normal.

Cronograma de pruebas.

Horarios de pruebas.

5. Verificación del proceso de pruebas

Las directivas de las instituciones vigiladas deben asegurarse que dentro del proceso de pruebas, participen los revisores fiscales, auditores internos y externos, y cualquier otra fuente calificada para evaluar las pruebas efectuadas. La verificación del proceso de pruebas debe involucrar, cuando menos, al gerente del proyecto, al dueño del sistema que se prueba y a una parte independiente, objetiva, como sería el revisor fiscal, el auditor, un asesor o un experto de un área independiente.

El proceso de verificación debe estar soportado por:

Planillas de ejecución de pruebas para el conjunto de operaciones y datos a probar, en cada fecha crítica a ejecutar.

Resultados de las pruebas:

• Informe de errores de las pruebas a la gerencia.

• Seguimiento a las correcciones y nuevas pruebas.

Confrontación de resultado versus los criterios de aceptación establecidos.

Aceptación o rechazo de los sistemas probados.

6. Documentación de las pruebas

Las instituciones deben conservar documentación escrita para respaldar cada una de las etapas del proceso de pruebas. Esta documentación suministra un rastro de auditoría y debe facilitar la rectificación de los problemas cuando se presentasen. La documentación deberá incluir, cuando menos, los siguientes aspectos:

Planificación del proceso de pruebas para el año 2000.

Sistemas sobre el cual se realizaron las pruebas.

Los tipos de pruebas que se llevaron a cabo (por ejemplo, base, unitaria, regresión, integración, etc.).

Descripción del por qué la institución eligió la metodología de pruebas que ejecutó.

Los criterios utilizados por la institución para seleccionar las operaciones, datos y los escenarios de prueba que ejecutó.

Verificación del proceso de pruebas.

Los criterios utilizados para determinar si el sistema se encuentra listo para afrontar el año 2000.

La planificación para la corrección o rehabilitación y nuevas pruebas de los sistemas de información y/o de cómputo que fallaron en las pruebas de año 2000.

Las personas responsables de la autorización de la planificación de pruebas y de la aceptación de los resultados de las pruebas.

Cualquier otra documentación que la institución considera que apoya sus decisiones y conclusiones.

La planificación de las pruebas debe ser consistente con la planificación de las contingencias para el año 2000.

7. Mantenimiento de la preparación para el año 2000

Una vez confirmado que los sistemas funcionaron correctamente en las fechas críticas establecidas, las directivas de la institución deberán cerciorarse que todas las aplicaciones, los archivos de datos, los sistemas operativos, el software, las redes y los equipos se encuentran disponibles para su implantación, independiente de cuántas veces y cuándo fueron revisados, corregidos, actualizados o adquiridos.

Finalizados los procesos conversión y reemplazo, así como el de pruebas, las aplicaciones, datos y en general todos los componentes de sistemas compatibles con año 2000 deben implantarse en el ambiente de producción. La integración de aplicaciones y componentes compatibles en el ambiente productivo de la entidad debe ser cuidadosamente coordinada para tomar en cuenta las interdependencias de todos los sistemas.

Fechas críticas de comprobación

Las entidades vigiladas deberán verificar cuáles son las fechas críticas que es necesario comprobar en cada uno de sus sistemas de misión crítica. Las pruebas de cálculos se deben realizar mínimo con los siguientes escenarios, para tener mayor certeza:

31 de diciembre de 1899 Debe aceptarlo, cambio de siglo. 

29 de febrero de 1999 No debe aceptarlo, año no bisiesto. 

9 de abril de 1999 9999 en el calendario Juliano. El día 99 del año 1999. Debe aceptarlo como fecha y no como instrucción o descripción de campo. 

9 de septiembre de 1999 Debe aceptarlo como fecha y no como instrucción o descripción de campo. 

31 de diciembre de 1999 Debe aceptarlo, debe cambiar automáticamente el milenio mediante el 

reloj interno. 

1º de enero del 2000 Debe aceptarlo, cambio de milenio. 

3 de enero del 2000 Debe aceptarlo, primer día hábil del 2000. 

10 de enero del 2000 Debe aceptarlo, primera fecha que requiere de un campo de fecha 

con 7 dígitos. 

31 de enero del 2000 Debe aceptarlo, primer cierre mensual. 

29 de febrero del 2000 Debe aceptarlo, año bisiesto. 

31 de marzo del 2000 Debe aceptarlo, el final del primer trimestre. 

10 de octubre del 2000 Debe aceptarlo, primera fecha que utiliza los 8 dígitos. 

31 de diciembre del 2000 Debe aceptarlo, debe cambiar el año automáticamente mediante 

el reloj interno. 

1º de enero del 2001 Debe aceptarlo, comienzo del año 2001. 

31 de diciembre del 2001 Debe aceptarlo, debe cambiar el año automáticamente mediante 

el reloj interno. 

1º de enero del 2002 Debe aceptarlo. 

1º de enero del 2037, u otro Debe aceptarlo, garantiza que la u otro año posterior. 

solución sirve mínimo hasta dicho año. 

________________________