Auditoria de Sistemas

AUDITORIA DE SISTEMAS

Presentación

1. EVALUACIONES Y CONTROLES

SistemasAspectos a Controlar

2. INSTRUMENTOS DE CONTROL

Documentación de las Sub Etapas del Desarrollo e Implantación de SistemasReuniones de Revisión TécnicaBenchmark o Pruebas del SistemaFormularios de Control

3. CONTROL DE SISTEMAS EN FUNCIONAMIENTO

3.1 Plan de Trabajo3.2 Aspectos a Revisar

4. METODOLOGIA DE PRUEBAS DEL SISTEMA

4.1 Modalidad de Pruebas4.2 Niveles de Prueba4.3 Pruebas Especiales del Sistema4.4 Tipos de Datos de Prueba

5. CONTROL INTERNO DEL SERVICIO INFORMATICA

5.1 Evaluación y Control de la Organización5.2 Evaluación Funcional5.3 Procedimientos5.4 Metodologías5.5 Recursos Humanos5.6 Seguridad

6. DE LOS SERVICIOS EXTERNOS DE COMPUTACION

6.1 Planeamiento de Sistemas6.2 Definición de Requerimientos6.3 Definición de Especificaciones6.4 Elaboración de los Términos de Referencia de Sub-Contratación6.5 Control de los Servicios Externos6.6 Control de Sistemas

GLOSARIO DE TERMINOS

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ PRESENTACION ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

El Instituto Nacional de Estad¡stica e Inform tica (INEI), en su calidad de ente central y rector de los Sistemas Nacionales de Estad¡stica e Inform tica y , como tal responsable de que las actividades inform ticas oficiales se desarrollen bajo una normat- ividad t‚cnica com£n, se complace en presentar el manual "Auditor¡a de Sistemas".

El objetivo del presente manual es colaborar al establecimiento y/o implantaci¢n y documentaci¢n de los procedimientos y normas de control que permitan el uso correcto de los equipos de procesamiento autom tico de datos, tratando de que el Servicio Inform tico sea lo adecuado, coherente, continuo y confiable que se espera.

El presente manual consta de seis Cap¡tulos: el Cap¡tulo I, Evalu- aciones y Controles, presenta una visi¢n integral de los aspectos a controlar en una Auditor¡a de Sistemas. En el Cap¡tulo II, Instrumentos de Control, se realiza una descripci¢n de los formularios de control a utilizar en la Evaluaci¢n del sistema. El Cap¡tulo III, trata sobre el Control de Sistemas en funcionamiento y describe el plan de trabajo para la evaluaci¢n de los Sistemas en Operaci¢n.

En el Cap¡tulo IV, Metodolog¡a de Pruebas del Sistema se detallan las modalidades b sicas de pruebas y las consideraciones a tomarse en cuenta para su ejecuci¢n. El Cap¡tulo V, Control Interno al Servicio Inform tico, eval£a la organizaci¢n del Area de Servicio Inform tico y su entorno organizacional y el efecto sobre el Sistema en si. Finalmente en el Cap¡tulo VI, De los Servicios Externos de Computaci¢n, se dan los lineamientos para la evaluaci¢n del desempe¤o de los servicios contratados a terceros para la ejecuci¢n de funciones del Area de Sistemas.

Asimismo, el documento presenta un Glosario de T‚rminos, para guiar y orientar al lector en los conceptos y terminolog¡a emplea- dos en este Manual.

El INEI, con el fin de apoyar a una mejor gesti¢n de los servicios Inform ticos, pone a disposici¢n de las Entidades P£blicas, Privadas, estudiantes y p£blico en general, este Manual, agradeci- endo a los Integrantes del Sistema Nacional de Inform tica, as¡ como a todas las personas que han contribuido de alguna manera a la realizaci¢n de la presente edici¢n.

Lima, Abril de 1996

INSTITUTO NACIONAL DE ESTADISTICA E INFORMATICA

Econ. FELIX MURILLO ALFARO JEFE

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ EVALUACIONES Y CONTROLES ³

ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

AUDITORIA DE SISTEMAS

La Auditor¡a de Sistemas es el conjunto de t‚cnicas que permiten detectar deficiencias en las organizaciones de inform tica y en los sistemas que se desarrollan u operan en ellas, incluyendo los servicios externos de computaci¢n, que permitan efectuar acciones preventivas y correctivas para eliminar las fallas y carencias que se detecten.

Se verifica la existencia y aplicaci¢n de todas las normas y procedimientos requeridos para minimizar las posibles causas de riesgos tanto en las instalaciones y equipos, como en los programas computacionales y los datos, en todo el mbito del Sistema: usuarios, instalaciones, equipos.

Las Instituciones efect£an Auditor¡as de Sistemas, con la finalidad de asegurar la eficiencia de las organizaciones de inform tica, as¡ como la confiabilidad y seguridad de sus sistemas.

ASPECTOS A CONTROLAR

Para lograr desarrollar e implantar un Sistema con Calidad, dentro de los plazos y costos previstos, cuyos beneficios sean los planificados, es necesario controlar que:

- El Proyecto de Desarrollo de Sistemas est‚ enmarcado dentro del Plan General de Sistemas.

- El Cronograma del Proyecto sea realista y el Sistema est‚ operativo en forma oportuna, de acuerdo a las necesidades de la Instituci¢n.

- Se aplique la Metodolog¡a de Desarrollo de Sistemas.

- Exista un control permanente de la consistencia y confiabilidad de los Sistemas Inform ticos.

- La Calidad del Sistema producido, permita una ¢ptima operatividad del mismo.

- La tecnolog¡a utilizada sea la m s adecuada a los fines del sistema y permita una vida £til satisfactoria para la inversi¢n realizada.

- Los Costos, tanto del desarrollo como de su operaci¢n y mantenimiento, sean los planificados y exista un retorno de la inversi¢n.

- Se hayan logrado los beneficios esperados.

1.1 El Proyecto de Desarrollo de Sistemas est‚ enmarcado dentro

del Plan General de Sistemas. Para asegurar que el Sistema a desarrollar o desarrollado logre estar integrado y tenga todas las interfases con los dem s sistemas, es necesario se compruebe que es uno de los componentes del Sistema Global de Informaci¢n de la Instituci¢n y est interrelacionado con otros sistemas, a trav‚s del intercambio de informaci¢n o acceso a informaci¢n com£n.

1.2 El Cronograma del Proyecto permita o haya permitido que el Sistema est‚ operativo oportunamente. Debe verificarse que exista un Cronograma del Desarrollo del Sistema, usando el m‚todo de Gantt como m¡nimo, siendo ideal utilizar adicionalmente el PERT-CPM.

Se evaluar , de acuerdo a la estacionalidad del ciclo operativo del sistema, si el inicio de la implantaci¢n y puesta en marcha es acorde con las necesidades de la Instituci¢n, debiendo empezar, de ser factible, simult neamente al comenzar el ciclo administrativo, de tal forma que se evite la puesta al d¡a de informaci¢n

1.3 Se aplique la Metodolog¡a de Desarrollo de Sistemas. La forma m s adecuada para asegurar que el Sistema se desarrolle de acuerdo a una metodolog¡a, consiste en verificar dos aspectos:

- Que cuente con toda la documentaci¢n del An lisis, Dise¤o e Implantaci¢n del Sistema.

- Que se hayan aplicado correctamente las t‚cnicas de an lisis y dise¤o de Sistemas.

Documentaci¢n de Sistemas: Si el control es realizado preventivamente, la documentaci¢n deber ser revisada al finalizar cada sub-etapa, siendo recomendable que se revise internamente en la Direcci¢n de Inform tica, previa a la entrega del mismo al Comit‚ del Sistema.

Deber llevarse un Registro de la Documentaci¢n generada, para efectos de seguimiento permanente y control posterior.

Deber contarse con la firma de conformidad del usuario de la documentaci¢n que ‚ste deba aprobar.

Si el control es realizado posteriormente, deber verificarse la existencia de toda la documentaci¢n y la aprobaci¢n del usuario.

Con la documentaci¢n de sistemas generada, se debe verificar que todas las etapas y sub-etapas de la Metodolog¡a de An lisis, Dise¤o, Programaci¢n e Implantaci¢n de Sistemas se hayan ejecutado, con resultados satisfactorios.

Aplicaci¢n de T‚cnicas :

Se deber verificar que se hayan utilizado las t‚cnicas adecuadas para cada etapa y sub-etapas del desarrollo e implantaci¢n del Sistema.

Para cada etapa se aplicar n las siguientes t‚cnicas :

An lisis de Sistemas :

- Entrevistas. - Diagrama de Flujo de Datos (D.F.D.). - Modelizaci¢n de Datos. - Diagrama de Estructura de Datos (D.E.D.). - Historia de Vida de la Entidad (H.E.V.). - An lisis de Costo-Beneficio (A.C.B.). - Prototipeo.

Dise¤o de Sistemas :

- Dise¤o Estructurado. - Diagrama de Estructura de Cuadros. - Optimizaci¢n del Dise¤o F¡sico. - Dise¤o de Pruebas. - Prototipeo. Programaci¢n :

- Programaci¢n Estructurada. - Pruebas Unitarias. - Pruebas de Integraci¢n. - Prueba del Sistema. Implantaci¢n de Sistemas : - Capacitaci¢n. - Creaci¢n de archivos iniciales. - Proceso en paralelo.

1.4 Exista un control permanente de la consistencia y confiabilidad de los Sistemas Inform ticos.

Deben existir los controles espec¡ficos de :

- Detecci¢n de errores. - Prevenci¢n de acceso no autorizado y mal uso de la informaci¢n y del equipo. - Controles ambientales y seguridad.

1.5 La Calidad del Sistema producido sea tal que permita una ¢ptima operatividad del mismo.

Este aspecto, adem s de ser evaluado por un especialista en Sistemas, debe tambi‚n ser verificado con el rea usuaria, ya que ella puede dar su apreciaci¢n del sistema, en forma real y responsable, porque se encargar de operarlo y administrarlo. La informaci¢n garantizar que:

- Cumpla con los requerimientos del usuario, establecido en la fase de An lisis y Dise¤o del Sistema.

- La secuencia de trabajo u operaci¢n del sistema, sea el mismo que el de proceso real.

- El sistema sea totalmente operado con: . Gu¡a al usuario.

. Ayudas permanentes en l¡nea.

- El tiempo de respuesta sea adecuado para el volumen real de datos.

- El consumo de recursos de c¢mputo sea razonable y est‚ dentro de lo previsto.

- Responda a todas las bifurcaciones posibles en la operaci¢n del sistema.

- La interfase-usuario sea adecuada y de f cil manejo y comprensi¢n

- Se disponga de todas las facilidades utilitarias de reorganizaci¢n de archivos y copias de respaldo.

- Se disponga de procedimientos de respaldo ante ca¡das del sistema.

1.6 La tecnolog¡a utilizada sea la m s adecuada a los fines del sistema, y permita una vida £til satisfactoria para la inversi¢n realizada.

Se debe verificar que los siguientes elementos sean los m s adecuados:

- Equipos. - Sistema de Red. - Sistema de Base de Datos. - Sistema de Comunicaciones. - Lenguaje de Programaci¢n.

Es conveniente indicar que en algunas organizaciones se define en forma global toda la plataforma de Hardware y Software a utilizar como standard para la Instituci¢n, quedando en este caso tratar de aprovecharla al m ximo.

Sin embargo, existen organizaciones en la que se dan soluciones departamentalizadas con interfases entre ellas, manteniendo cierta independencia entre si. A continuaci¢n mencionamos algunas consideraciones que se deben tener en cuenta para evaluar si el equipamiento y software es adecuado para el sistema. Equipos :

Se deber utilizar los equipos adecuados, de acuerdo al tipo de sistema desarrollado. Si la aplicaci¢n es monousuaria, se requerir un equipo que tenga independencia de operaci¢n, debiendo contar individualmente con la potencia del caso para soportar todo el procesamiento.

En caso de que el sistema sea multiusuario, deben utilizarse equipos terminales conectados a un servidor, debiendo estar balanceados adecuadamente los recursos entre ambos, de tal forma de contar con el tiempo de respuesta requerido. Sistema de Red :

Dependiendo del tipo de Sistema, se deber utilizar el tipo de plataforma de Red que m s convenga. Si el sistema es cerrado y netamente operativo con un criterio de procesamiento centralizado,

pueden utilizarse los Sistemas orientados a la centralizaci¢n y si el sistema es de filosof¡a abierta y descentralizada, se deben utilizar redes de este tipo.

Sistema de Base de Datos :

En funci¢n a las necesidades del sistema se debe utilizar la plataforma necesaria de Base de Datos. Para aplicaciones sencillas e independientes, se utiliza el manejador de base de datos del lenguaje. Sin embargo, para aplicaciones corporativas, se utilizan manejadores de base de datos relacionales de nivel, as¡ como para aplicaciones de tipo cliente-servidor.

Sistema de Comunicaciones :

Este es un factor importante a evaluar en funci¢n a la naturaleza del sistema. Muchas veces el sistema debe instalarse en una tipolog¡a de comunicaciones pre-establecida y hay que tratar de aprovecharla al m ximo. Sin embargo, si el dise¤o de las comunicaciones pudiera estar correlacionado con el sistema, permitir¡a un mejor desempe¤o de las mismas.

Se debe evaluar si el lenguaje a utilizar o ya utilizado es el m s conveniente, dependiendo de las necesidades de eficiencia y facilidad de desarrollo y explotaci¢n, por lo que deben evaluarse los siguientes factores :

- Tiempos de procesamiento y respuesta. - Facilidades en tiempos de programaci¢n y mantenimiento de sistemas. - Rapidez en el desarrollo de sistemas a trav‚s de generadores de programas. - Ambientes gr ficos.

1.7 Que los Costos, tanto del desarrollo as¡ como de su operaci¢n y mantenimiento, sean los planificados y que exista un retorno de la inversi¢n.

El proyecto para ser aprobado debe contar con un presupuesto general, el cual debe ser detallado en la fase de An lisis de Sistemas.

Los componentes de costos deben ser :

. Costos de Personal de Sistemas y del Usuario. . Costo de Supervisi¢n. . Costos de Equipamiento. . Costos de Originales de Software de Base. . Costos de Instalaciones y Servicios. . Costo de Relevamiento de Datos. . Costo de Capacitaci¢n. . Costo de Creaci¢n de Archivos Maestros. . Costo de Procesamiento en Paralelo. . Costo de Producci¢n. . Costo de Mantenimiento.

El control de costos debe efectuarse por etapas :

. An lisis y Dise¤o del sistema. . Programaci¢n del sistema. . Implantaci¢n del sistema. . Operaci¢n del sistema. 1.8 Se hayan logrado los beneficios esperados.

Una vez puesto en operaci¢n el sistema, se debe esperar que transcurran por lo menos dos per¡odos de procesamiento para evaluar si los beneficios del sistema se han logrado, tanto en las ventajas esperadas por su implantaci¢n, como los beneficios econ¢micos que estaban planificados.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ INSTRUMENTOS DE CONTROL ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Los Elementos e Instrumentos de Control a utilizar en forma individual o en forma conjunta son :

- Documentaci¢n de las Sub-etapas del Desarrollo e Implantaci¢n de Sistemas. - Reuniones de Revisi¢n T‚cnica. - Benchmark o pruebas del sistema. - Formularios de Control.

LA DOCUMENTACION DE LAS SUB-ETAPAS DEL DESARROLLO E IMPLANTACION DEL SISTEMA

La primera informaci¢n que debe servir de base para efectuar un an lisis para el control del sistema lo constituye la documentaci¢n generada en las diferentes fases de desarrollo e implantaci¢n del sistema.

La documentaci¢n debe leerse detenidamente con la finalidad de:

. Comprender la concepci¢n del sistema. . Planificar el contenido de las reuniones de revisi¢n t‚cnica. . Determinar los vacios o carencias de informaci¢n. . Elaborar los cuestionarios de consultas. . Efectuar el control del Sistema, con un conocimiento s¢lido del mismo.

El t‚cnico que efect£e el control del sistema debe tomar conocimiento completo de la documentaci¢n escrita existente, de tal forma de reducir el tiempo del proceso de auditor¡a del sistema y brindar resultados en corto plazo.

REUNIONES DE REVISION TECNICA

Un aspecto fundamemental para efectuar un buen control del sistema son las Entrevistas de Revisi¢n T‚cnica, ya que la documentaci¢n en la mayor¡a de los casos es muy escasa y deficiente y generalmente cubre solo una parte de la informaci¢n y las entrevistas permiten complementar la informaci¢n t‚cnica y recabar opiniones sobre deficiencias del sistema.

Las reuniones de Revisi¢n T‚cnica, debe estar debidamente planificadas y contar con formularios de los temas y consultas a tratar, para evitar olvidar cualquier aspecto fundamental para el an lisis y la investigaci¢n.

Las reuniones de Revisi¢n T‚cnica deben efectuarse con todas las personas que participaron en el desarrollo e implantaci¢n del sistema, as¡ como los que operan y utilizan el sistema.

Deben efectuarse reuniones de Revisi¢n T‚cnica con cada participante en forma separada para lograr informaci¢n y opiniones libres e independientes de cada uno de ellos, despu‚s de las reuniones individuales puede efectuarse una reuni¢n global para determinar las conclusiones de consenso. Las Entrevistas de Revisi¢n T‚cnica deben efectuarse con la o las siguientes personas que llevaron o llevan a cabo las siguientes funciones:

. El Analista de Sistemas. . El Programador. . El Implementador. . El/los Operadores del Sistema. . Los Usuarios Operativos que utilizan el Sistema. . Los Usuarios que utilizan la informaci¢n para la toma de decisi- ones.

En todo caso deben consultarse los factores que limitaron el desarrollo, implantaci¢n, operaci¢n y uso del sistema, as¡ como las deficiencias, aspectos de confiabilidad y seguridad, en funci¢n de cada persona.

BENCHMARK O PRUEBAS DEL SISTEMA

Instrumento vital para evaluar la confiabilidad del Sistema es lo que se denomina Benchmark o Pruebas del Sistema. No basta con evaluar el sistema tomando conocimiento de su documentaci¢n y sosteniendo reuniones de revisi¢n t‚cnica con el personal involucrado, lo fundamental que demuestra la buena funcionalidad y confiabilidad del sistema es efectuar procesos de prueba simulando situaciones extremas de tal forma de determinar si el sistema responde a lo especificado y es confiable produciendo resultados correctos en los tiempos esperados.

Es por eso que se deben realizar Benchmark o procesos de prueba especiales tales como:

. Prueba de carga m xima. . Prueba de almacenamiento. . Prueba de tiempo de ejecuci¢n. . Prueba de recuperaci¢n.

FORMULARIOS DE CONTROL

Para efectos de registrar y controlar preventivamente el desarrollo e implantaci¢n del Sistema o evaluarlo posteriormente, es necesario utilizar formularios denominados de control, cuya relaci¢n se indica a continuaci¢n:

. Control de Cronograma del Proyecto. . Control de Documentaci¢n de Sistemas. . Control T‚cnico del An lisisdel Sistema. . Control T‚cnico del Dise¤o del Sistema. . Benchmark o Prueba real del Sistema. . Control de la Implantaci¢n.

En las siguientes p ginas se incluyen los dise¤os de los Formulari- os de Control.

2.1 Control de Cronograma del Proyecto :

Para efectos de controlar o evaluar el cumplimiento de los plazos y la duraci¢n de las etapas del sistema y por razones de sencillez se recomienda utilizar el diagrama de GANTT, debiendo en el mismo cuadro registrar lo planeado y lo ejecutado con dos s¡mbolos diferentes.

Se recomienda que se utilicen herramientas computarizadas de formulaci¢n y control de proyectos que permiten utilizar el PERT-PCM.

Utilizar el diagrama N§ 1.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ CONTROL DE CONOGRAMA DE PROYECTO ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³CONTROL DEL DESARROLLO SISTEMA : ³ ³ ³ ³E IMPLANTACION DE SISTEMA JEFE DE PROYECTO: ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´³ ³ PERIODO : EMANAS / MESES ³

³ ETAPAS/SUB-ETAPAS ÃÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄ´ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³1. PROYECTO ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³1.1 Definici¢n del Proyecto ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³1.2 Conograma del Proyecto ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³2. ANALISIS DE SISTEMA ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³2.1 An lisis requisitos Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³2.2 Especificaci¢n Funcional ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³³ ³2.3 Interfase del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³3. DISE¥O DEL SISTEMA ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³3.1 Dise¤o Fisico del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³3.2 Especific. Complementaria ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³4. PROGRAMACION ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³4.1 Programaci¢n del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³4.2 Pruebas del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³5. IMPLANTACION DE SISTEMAS ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³5.1 Capacitaci¢n ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³

ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³5.2 Benchmark del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´ ³ ³5.3 Creaci¢n de Archivos ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ ³5.4 Proceso en Paralelo ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³6. PRODUCCION ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³7. EVALUACION ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÙ

2.2 Control de Documentaci¢n de Sistemas

Este formulario permite verificar la aplicaci¢n de la metodolog¡a de desarrollo e implantaci¢n de sistemas, mediante el registro de la documentaci¢n que se debe haber generado para cada etapa y sub-etapa. Deber contarse con la firma de conformidad del usuario de la documentaci¢n que ‚ste deba aprobar.

Utilizar el diagrama N§ 2.

2.3 Control T‚cnico del An lisis

Para verificar que el Control del An lisis se haya efectuado adecuadamente, se debe utilizar el Formulario de Registro de T‚cnicas Utilizadas y se deben realizar estudios de gabinete de la documentaci¢n generada, as¡ como efectuar reuniones de revisi¢n t‚cnica, conjuntamente con el personal de analistas del proyecto. En caso de verificarse la falta de aplicaci¢n de las t‚cnicas o errores en el trabajo de an lisis, ‚stas se registrar n en un acta, para que sean superadas.

Es mejor efectuar el control en forma permanente, apenas se finaliza una sub-etapa y antes de proceder a la pr¢xima, pues hacerlo en forma posterior, es m s costoso y requiere de mayor tiempo, teniendo mayores implicancias.

Las t‚cnicas que se deben haber utilizado son : - Entrevistas. - Diagrama de Flujo de Datos (D.F.D). - Modelizaci¢n de Datos. - Diagrama de Estructura de Datos (D.E.D). - Historia de Vida de la Entidad (H.E.V). - An lisis de Costo-Beneficio (A.C.B). - Prototipeo.

Se utilizar el diagrama N§ 3 para facilitar el registro de las t‚cnicas que se han utilizado para cada etapa o sub-etapa, marc ndolas con asterisco (*)

2.4 Control T‚cnico del Dise¤o

Para verificar que el Control T‚cnico del Dise¤o se ha efectuado adecuadamente, se debe utilizar el Formulario de Registro de T‚cnicas Dise¤o y se deben realizar estudios de gabinete de la documentaci¢n generada, as¡ como efectuar reuniones de revisi¢n t‚cnica, conjuntamente con el personal de analistas del proyecto.

En caso de verificarse la falta de aplicaci¢n de las t‚cnicas o errores en el trabajo de dise¤o, ‚stas se registrar n en un acta, para que sean superadas.

En este caso tambi‚n es mejor efectuar el control en forma permanente, apenas se finaliza una sub-etapa y antes de proceder a la pr¢xima, pues hacerlo en forma posterior es m s costoso y

requiere de mayor tiempo, teniendo mayores implicancias. Las t‚cnicas que se deben haber utilizado son :

- Dise¤o Estructurado. - Diagrama de Estructura de Cuadros. - Optimizaci¢n del Dise¤o F¡sico. - Dise¤o de Pruebas. - Prototipeo.

Se utilizar el diagrama N§ 4 para facilitar el registro de las t‚cnicas que se han utilizado para cada etapa o sub-etapa, marc ndolas con asterisco (*)

Diagrama N§ 2.

CONTROL DE DOCUMENTACION DE SISTEMAS ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³CONTROL DE DESARROLLO SISTEMA : ³³ ³³E IMPLANTACION DE SISTEMAS JEFE DE PROYECTO : ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´³ ³ FECHA DE ³ FECHA DE APROBACION ³³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄ´³ DOCUMENTACION ³ EMISION ³INFORMATICA ³ USUARIO ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´³1. ETAPA:ANALISIS DEL SISTEMA ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³1.1 Definici¢n del Proyecto ³ ³ ³ ³

ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´³1.2 Conograma de Proyecto ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´³1.3 Analisis del Sistema Actual ³ ³ ³ ³ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.3.1 Descripci¢n del Sist. Actual ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´³ ³1.3.2 Cat logo Requisitos Sist. ³ ³ ³ ³ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´³ ³1.3.3 Analisis de Alternativas ³ ³ ³ ³ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´³1.4 Especificaci¢n Funcional ³ ³ ³ ³ ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.4.1 Especific. Sistema ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.4.2 Especific. Sub-Sistemas ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.4.3 Modelo de Datos Sistema ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.4.4 Modelo Eventos Sistema ³ ³ ³ ³ ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³1.5 Interfase del Sistema ³ ³ ³ ³ ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.5.1 Interface con Usuario ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.5.2 Seguridad y control ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³1.5.3 Especific. de Entrega ³ ³ ³ ³ ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ 2. DISE¥O DEL SISTEMA ³ ³ ³ ³

ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ 2.1 Dise¤o Fisico del Sistema ³ ³ ³ ³ ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³2.1.1 Arquitectura Fisica Sist. ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³2.1.2 Estructura de Datos ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³2.1.3 Entorno Tecnologico ³ ³ ³ ³ ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³2.2 Especif. Complementarias ³ ³ ³ ³ ÃÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³2.2.1 Plan Pruebas del Sistema ³ ³ ³ ³ ÃÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ ³2.2.2 Especific. Dise¤o ³ ³ ³ ³ ÃÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³3. PROGRAMACION DE SISTEMA ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³ 3.1 Manual de Programaci¢n ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³4. IMPLANTACION DEL SISTEMA ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄ´ ³4.1 Manual: Operaci¢n y Usuario ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÙ DIAGRAMA N§ 3

CONTROL TECNICO DEL ANALISIS DEL SISTEMA ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄ¿ ³ ³ ENTRE ³ ³ Modelo ³ ³ ³ An lisis ³ Proto- ³ ³ETAPA/SUB-ETAPA ³ VISTAS ³ DFD ³ Datos ³ DED ³ HVE ³ C.B ³ tipeo ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´

³1. ANALISIS REQUISISTOS ³ ³ ³ ³ ³ ³ ³ ³³ DEL SISTEMA ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 1.1 Identificaci¢n ³ ³ ³ ³ ³ ³ ³ ³³ de Requisitos ³ * ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´ ³ 1.2 Dise¤o del Modelo ³ ³ ³ ³ ³ ³ ³ ³³ L¢gico Actual ³ * ³ * ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 1.3 Estudios Alternativas ³ * ³ * ³ ³ ³ ³ * ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³2. ESPECIFICACION ³ ³ ³ ³ ³ ³ ³ ³³ FUNCIONAL SISTEMA ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 2.1 Modelo de proceso ³ * ³ * ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 2.2 Modelo de Datos ³ ³ ³ * ³ * ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 2.3 An lisis detallado ³ ³ * ³ ³ ³ * ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³3. INTERFASES DEL SISTEMA ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 3.1 Interfase con usuario ³ ³ ³ ³ ³ ³ ³ * ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 3.2 Complementar Especifi- ³ ³ ³ ³ ³ ³ ³ ³³ caciones Sistema ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ´³ 3.3 Complementar Especifi- ³ ³ ³ ³ ³ ³ ³ ³³ caciones de Entrega ³ ³ ³ ³ ³ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÙ

DIAGRAMA N§4

CONTROL TECNICO DEL DISE¥O DEL SISTEMA ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ Dise¤o ³ ³ Optimi ³ Dise¤o ³ Prototipeo ³³ ³ Estruct.³ DEC ³ Dise¤o ³ Pruebas ³ ³³ ³ ³ ³ Fisico ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´ ³1. DISE¥O FISICO DEL SISTEMA ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´³ 1.1 ARQUITECTURA FISICA DEL SISTEMA³ ³ * ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´³ 1.2 ESTRUCTURA DE DATOS ³ * ³ ³ * ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´³ 1.3 ENTORNO TECNOLOGICO ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´³ 1.4 ESTUDIOS ALTERNATIVAS ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´ ³2. ESPECIFICACION ³ ³ ³ ³ ³ ³³ COMPLEMENTARIAS ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´³ 2.1 PLAN DE PRUEBAS SISTEMAS ³ ³ ³ * ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÅÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄ´³ 2.2 ESPECIFICACIONES SISTEMAS ³ ³ ³ ³ ³ * ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÙ

INSTRUMENTOS DE CONTROL

3.1 PLAN DE TRABAJO

Para efectuar el Control, el Especialista deber establecer su plan de trabajo, el cual debe basarse en pasos y etapas a ejecutar en un plazo determinado y deber contemplar las etapas siguientes:

a) Planeamiento del Trabajo a Realizar. b) Investigaci¢n Preliminar. c) Evaluaci¢n del Sistema. d) Planeamiento y Dise¤o de las Pruebas de Control. e) Ejecuci¢n y Evaluaci¢n de los Resultados de las Pruebas. f) Confecci¢n del Informe de Auditor¡a del Sistema. g) Revisi¢n y Opini¢n del Informe. h) Seguimiento de las Recomendaciones de Auditor¡a.

a. Planeamiento del trabajo a realizar

Consiste en la estrategia que conduzca al logro de los objetivos concretos y a las expectativas de la Alta Direcci¢n en el menor tiempo posible, para lo cual se elaborar el plan de trabajo que permita medir el avance del trabajo en puntos claves y administrar eficientemente los recursos de tiempo y personal que sean asignados. En el documento de planeaci¢n se debe considerar lo siguiente:

. Objetivo general del trabajo a realizar. En forma concreta se plantea los objetivos del trabajo.

. Alcances del trabajo a realizar. Se marcan los escenarios de riesgos que ser n examinados en el trabajo, pudiendo ser todos o solamente algunos.

. Puntos de inter‚s para este trabajo. Se registran los aspectos que requieren especial atenci¢n, de acuerdo con los antecedentes que se conozcan de la aplicaci¢n o de otras similares y de la informaci¢n que se procesa con ella.

. Auditores asignados. Un grupo se encarga de verificar que se cumplan con los est ndares de calidad y las normas y directivas que ha emitido la Instituci¢n y el ente rector en Inform tica. Otro grupo se encarga de verificar el funcionamiento de los sistemas.

. Duraci¢n estimada. Comprende la suma de los tiempos estimados asignados a cada una de las etapas desde la b) hasta la h).

. Fechas de iniciaci¢n/terminaci¢n. Para el desarrollo completo de las actividades del proyecto.

. Diagrama de actividades. Se coloca el tiempo estimado que va a durar cada una de las actividades.

. Entrevista de iniciaci¢n de auditor¡a. Se realiza una reuni¢n con el personal directivo de Sistemas en la cual se plantean los objetivos y el enfoque de trabajo a realizar y se establecen los mecanismos de comunicaci¢n a emplear en el desarrollo del trabajo.

. Puede utilizar el formato de Plan de Trabajo indicado en el diagrama No. 5.

b. Investigaci¢n Preliminar

Se determinan las caracter¡sticas t‚cnicas y operativas de la aplicaci¢n objeto del trabajo y su importancia para los objetivos y metas de la Instituci¢n.

Se deber conseguir la documentaci¢n del sistema, para que en el trabajo de gabinete pueda investigarse en forma preliminar el Sistema, con la siguiente informaci¢n :

. Dependencias involucradas en el manejo de la aplicaci¢n. . Inventario de documentos fuentes. . Inventario de informe que produce. . Normas legales e institucionales que rigen el funcionamiento de la aplicaci¢n. . Interfases de la aplicaci¢n con otros sistemas. . Procesos manuales y automatizados que realiza la aplicaci¢n. . Perfil t‚cnico de la aplicaci¢n. . Personal clave para el manejo de la aplicaci¢n en cada dependencia involucrada. . Inventario de manuales de documentaci¢n existente. . Informaci¢n sobre fraudes que se hayan cometido.

(Diagrama 5)

c. Evaluaci¢n del Sistema

Se deber efectuar la revisi¢n de los 10 aspectos indicados en el punto 3.2.

Al evaluar el sistema tambi‚n debe considerarse los riesgos deter- min ndose cu les son las situaciones de riesgo y cu les sus causas.

Para evaluar los controles existentes se deben utilizar una de las dos alternativas, o ambas :

- An lisis de Riesgo.

- Cuestionarios de Control. Riesgos:

. Riesgos Accidentales Ingreso accidental v¡a en apertura. Falla imprevista que anula seguridad. Error en sistema de comunicaci¢n.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿³ CONTROL DE SISTEMAS ³ SISTEMA : ³³ ³ RESPONSA : ³³ EN FUNCIONAMIENTO ³ AUDITOR : ³³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´³ ACTIVIDADES ³ PEDIDOS: DIAS O SEMANAS ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄÂÄÄ´³1. PLANEAMIENTO ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 1.1 Elaboraci¢n del Plan ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 1.2 Aprobaci¢n del Plan ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³2. INVESTIGACION PRELIMINAR ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´ ³ 2.1 Relevamiento de informaci¢n ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³

ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 2.3 Analisis de Informaci¢n ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³3. EVALUACION ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.1 Documentaci¢n del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´ ³ 3.2 Procesamiento del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.3 Operatividad del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.4 Controles del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.5 Integridad de Datos ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.6 Validez de Resultado ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.7 Seguridad del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.8 Sistema de Respaldo ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.9 Auditabilidad del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³ 3.10 Efectividad del Sistema ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³4. DISE¥O DE PRUEBAS DE CONTROL ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³5. EJECUCION-EVALUACION RESULTADOS ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³6. ELABORACION INFORME DE AUDITORIA ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³

ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³7. REVISION OPINIONES DEL INFORME ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´³8. EMISION DE INFORME FINAL ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄÅÄÄ´ ³9. SEGUIMIENTO DE RECOMENDACIONES ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ ³ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÁÄÄÙ

. Riesgos Pasivos Captaci¢n electromagn‚tica de transmisi¢n de microondas. Intercepci¢n por alambres o cables coaxiales. Acceso v¡a procedimientos t‚cnicos avanzados.

. Amenazas Activas

Otorgamiento de clave de seguridad a usuario realmente no autorizado.

Ingresar al sistema cuando el usuario autorizado ha dejado su terminal abierto, sin salir del sistema. Ingreso por personas expertas.

d. Planeamiento y dise¤o de las pruebas de control

De acuerdo a la metodolog¡a indicada en el ac pite V (Pruebas del Sistema) se deber n dise¤ar los juegos de datos de pruebas, los cuales deben asegurar que se investigue totalmente la confiabilidad del sistema y los controles que poseen.

En esta se debe considerar :

. Naturaleza y extensi¢n de las pruebas de auditor¡a. . Plan de las pruebas a ejecutar. . Dise¤o de las pruebas de auditor¡a.

e. Ejecuci¢n y Evaluci¢n de los resultados de las pruebas

Una vez, ejecutadas las pruebas se deber evaluar los resultados de las mismas y determinar en qu‚ m¢dulos el Sistema no es confiable y controles que no posee, que deban ser imprescindibles.

f. Confecci¢n del Informe de Auditor¡a del Sistema

Producto de la revisi¢n del Sistema se deber preparar el Informe de

Auditor¡a y Control del Sistema.

El informe preliminar debe ser opinado y recibirse los comentarios del caso para reci‚n emitir el informe final

g. Revisi¢n y Opini¢n del Informe

Tanto el rea usuaria, como el rea de Inform tica que desarroll¢ o administra la operaci¢n del Sistema, debe tener la oportunidad de revisar y opinar sobre el informe preliminar, de tal forma de asegurar que se est n aceptando las observaciones indicadas.

h. Seguimiento de las Recomendaciones de Auditor¡a

Siendo el objetivo de este trabajo que se mejore el sistema y se su- peren sus deficiencias para beneficio de la Instituci¢n, se deber , a trav‚s de un Registro de Seguimiento, efectuar el control de las acciones tomadas y las observaciones superadas.

3.2 ASPECTOS A REVISAR

Los aspectos que deben ser revisados son :

1- La documentaci¢n del sistema. 2- El procedimiento del sistema. 3- La operatividad del sistema. 4- Controles del sistema. 5- Integridad de los datos. 6- Validez de los resultados. 7- Seguridad del sistema. 8- Sistema de Respaldo. 9- Auditabilidad del sistema. 10- Efectividad del sistema.

3.2.1 DOCUMENTACION DEL SISTEMA

Como paso inicial del proceso de control de una aplicaci¢n en funcionamiento, deber ser revisada la documentaci¢n existente, la cual permitir adem s de tomar conocimiento escrito del mismo, revisar si se ha cumplido con la metodolog¡a y est ndares establecidos para el desarrollo de sistemas, anotando las falencias para su evaluaci¢n en los pasos siguientes, ya que podr¡an ser causa de problemas del sistema en operaci¢n.

3.2.2 PROCEDIMIENTO DEL SISTEMA

Todo sistema es un conjunto de procesos manuales y automatizados, cuya operativizaci¢n debe estar definida en un ®Procedimiento del Sistema¯. Es imprescindible la existencia del procedimiento formal para efectos de poder operativizar eficientemente y con eficacia el sistema.

3.2.3 OPERATIVIDAD DEL SISTEMA

Una vez revisada la documentaci¢n del Sistema, se deber proceder a revisar su operatividad.

Se revisar todo el ciclo del sistema :

. Generaci¢n del Dato. . Ingreso del Dato al sistema. . Transmisi¢n del Dato. . Procesamiento del Dato. . Actualizaci¢n de Archivos. . Emisi¢n de Reportes y Consultas.

Se debe verificar que el sistema efect£e en cada etapa de su ciclo las especificaciones establecidas en el An lisis y Dise¤o y se cumpla con el procedimiento aprobado para el sistema.

Debe analizarse y observar si realmente tiene los requisitos de operatividad que hagan al sistema eficiente y eficaz.

3.2.4 CONTROLES DEL SISTEMA

3.2.4.1 Generaci¢n del Dato

Debe verificarse las condiciones en que se genera el dato, ya sea ‚ste, externo o interno a la Instituci¢n, revisando que sea veraz y consistente y que refleje exactamente la operaci¢n realizada. Se podr tomar una muestra de datos para efectos de verificar su exactitud.

El sistema debe contemplar como uno de sus controles el efectuar muestreos de calidad de los datos con una frecuencia pre-establecida.

3.2.4.2 Ingreso del Dato

Debe revisarse que el ingreso o transcripci¢n de los datos se efect- £e cumpliendo con controles b sicos, tal como se indica :

a. Si el sistema es descentralizado, que el dato sea ingresado por el mismo que lo genera, para tener un mayor control sobre la calidad del ingreso del dato, ya que dicha persona es la que m s conoce la informaci¢n y es la responsable de la misma.

En el caso de que sean varias personas las que tengan que ingresar datos por que la organizaci¢n establece responsabilidades diferenciadas, debe constatarse que el sistema regist- re de alguna forma el c¢digo del ingresador del dato, para los controles del caso.

Si el Sistema es centralizado en un centro de c¢mputo del rea usuaria o de la Direcci¢n de Servicios Inform ticos, los datos deber n ser recepcionados por lotes y con hojas de control que indiquen el total de datos lotizado y totales de control, que permitan validar la completitud de los datos al ingresar la informaci¢n por personas transcriptoras de datos.

b. Que los programas de ingreso de datos tengan consistencia f¡sica y l¢gica de datos.

La consistencia f¡sica debe ser sobre el registro de datos en s¡, donde debe existir datos obligatorios y opcionales y rangos de valores de los datos.

La consistencia l¢gica debe ser contra los archivos maestros del sistema y contra reglas de validaci¢n cruzadas que deba cumplir la informaci¢n.

c. Que los datos ingresados deban imprimirse como validaci¢n del ingreso de datos, de la forma m s conveniente dependiendo de la naturaleza del sistema.

Si el ingreso de datos es desde terminales y en ventanillas de atenci¢n al p£blico, debe efectuarse una revisi¢n visual previa y debe imprimirse el comprobante producto del ingreso del conjunto de datos y al final del turno o d¡a de trabajo, debe emitirse un parte diario de comprobaci¢n y cuadre.

Si el ingreso de datos es desde terminales, pero en forma de proceso en lotes, al final de cada lote debe imprimirse un listado de revisi¢n visual y de cuadre para poder ser revisado con todos los documentos fuentes, si el volumen de registros es manejable, o por t‚cnica de muestreo, cuando existe una cantidad considerable de registros. Al final del d¡a debe adicionalmente imprimirse un parte diario de los lotes ingresados.

3.2.4.3 La Transmisi¢n del Dato

En un sistema en l¡nea la transmisi¢n del dato desde el terminal a la Base de Datos Central es manejado por el Software de Comunicacio- nes, Software de Red y Software de Base de Datos, debiendo en este caso :

El Sistema aplicativo debe tener rutinas programadas que controlen la £ltima transacci¢n procesada en caso de ca¡das del sistema y un programa alternativo de captura descentralizada del dato en el terminal, si su configuraci¢n de equipo lo permite y posterior transmisi¢n y registro en la base de datos central.

En un sistema de proceso en lotes, la transmisi¢n del dato puede ser v¡a diskettes o modems. En este caso debe verificarse: Que los diskettes sean probados previamente antes de su remisi¢n y que quede un medio de respaldo en el centro de ingreso de datos. Asimismo se les coloque en modo protegido contra escritura y est‚ claramente identificado en su etiqueta el n£mero o n£meros de lote y la cantidad de registros que contiene.

Que Para el caso de transmisi¢n de datos v¡a modem, el archivo a transmitir debe poseer un registro de encabezado de control que indique el n£mero o n£meros de lote y la cantidad de registros que contiene, debiendo el aplicativo que leer dicha informaci¢n efectuar la verificaci¢n de la informaci¢n del registro encabezado con los registros le¡dos.

3.2.4.4 El Procesamiento del Dato

Comprende los procesos manuales y automatizados que se realizan para producir los resultados previstos en las diferentes funciones que satisface el sistema.

Se da especial ‚nfasis a los controles incluidos en el software de las aplicaciones para lograr exactitud y confiabilidad del proceso y de los resultados que produce.

Debe verificarse que el sistema tenga registros y rutinas de control que permitan que ante una ca¡da del sistema pueda reiniciarse el procesamiento desde la £ltima transacci¢n procesada, ya sea el sistema en l¡nea o en lotes.

Para asegurar la integridad del procesamiento de los datos, en los sistemas en l¡nea debe contarse con las seguridades f¡sicas tales como UPS y equipos de respaldo de energ¡a el‚ctrica de tal forma que evite el truncamiento del procesamiento y desincronizaci¢n de su operaci¢n.

En los casos de los sistemas de procesamiento en lotes debe existir procedimientos computarizados para que los programas se ejecuten en la secuencia prevista y de acuerdo a las bifurcaciones establecidas.

Tambi‚n deben establecerse condiciones de error que no puedan ser consistenciados f¡sica o l¢gicamente en la etapa de ingreso de datos, que no deben paralizar el procesamiento, sino m s bien reportar las ocurrencias para acci¢n inmediata en los sistemas en l¡nea o acciones posteriores en los sistemas de procesos de lotes.

3.2.4.5 Actualizaci¢n de Archivos

Debe verificarse que existan registros y rutinas de control que con cierta frecuencia de tiempo o de per¡odo, determine si existe coherencia entre la cantidad de registros y valores de los totales de los archivos. Por ejemplo, si se ha producido una cantidad de nuevas entidades debe reflejarse ‚sto en un incremento del n£mero de registros del archivo principal. Al final del d¡a deber¡a producirse un reporte de integridad de archivos.

3.2.4.6 Emisi¢n de Reportes y Consultas.

Deben existir rutinas de control y procedimientos que permitan al final de un per¡odo cuadrar cifras entre reportes y consultas, que aseguren la integridad de los resultados emitidos. Cada sistema, seg£n su naturaleza, tiene una l¢gica de cuadre entre reportes, la cual debe estar claramente definida en el procedimiento.

3.2.5 INTEGRIDAD DE LOS DATOS

Adicionalmente a los controles anteriormente mencionados, para fines de asegurar la integridad de los datos en cuanto a su completitud y confiabilidad, el sistema debe poseer programas que rastreen los archivos y determinen incongruencias y falta de cuadre de la informaci¢n.

Debe asimismo, en forma externa, establecerse procedimientos de comparaci¢n de la informaci¢n producida por el sistema contra otras informaciones disponibles, para efectos de determinar la confiabilidad de la informaci¢n. Dentro de este aspecto est n las circulariza- ciones de comprobaci¢n de la informaci¢n del computador con las reas o personas involucradas.

3.2.6 VALIDEZ DE LOS RESULTADOS

El aspecto m s importante de todo el sistema son los resultados, por lo que al revisar el sistema debe verificarse que los resultados cumplan con las especificaciones del dise¤o del sistema, lo cual

debe comprobarse mediante juegos de datos de pruebas especialmente preparados, y que prueben todas las posibilidades de las entidades, datos y situaciones.

En el ac pite siguiente ®Pruebas del Sistema¯ se detalla la metodolog¡a que puede utilizarse.

3.2.7 SEGURIDAD DEL SISTEMA

Debe comprobarse que el Sistema cuente con los siguientes tipos de seguridad :

- Seguridad en el acceso a la informaci¢n. - Seguridad del sistema. - Seguridades F¡sicas.

3.2.7.1 Seguridad de acceso a la informaci¢n :

Debe existir a nivel Instituci¢n, un esquema global de seguridad de acceso a la informaci¢n, donde deben existir para cada rea y para cada funcionario ®Perfiles de Acceso¯ a los Sistemas, a las funciones dentro de cada sistema y a la Base de Datos, constituyendo una matriz de accesos ®usuario versus sistemas-funciones¯ donde el nivel de usuario es el c¢digo de cada funcionario.

El sistema debe tener claves de seguridad discriminadas donde cada usuario tiene un acceso basado en las siguientes opciones :

. Ingreso de datos. . Procesamiento de los datos. . Consultas por niveles. . Emisi¢n de Reportes.

Asimismo el sistema debe mantener un log de uso del sistema por sesi¢n de trabajo.

Los niveles de acceso a la informaci¢n pueden ser :

. Nivel de consulta de informaci¢n no restringida. . Nivel de mantenimiento de la informaci¢n no restringida. . Nivel de consulta incluyendo la informaci¢n restringida. . Nivel de mantenimiento de la informaci¢n restringida.

3.2.7.2 Seguridad del sistema

Acceso y Seguridad a los Programas

El Area de Servicio inform tico debe ser la £nica que debe tener ac-

ceso sobre los programas fuentes, que deber n estar archivados en bibliotecas especiales, bajo control de un Administrador de Sistemas.

Asimismo, los programas objetos tambi‚n deben tener nombres s¢lo conocidos por el administrador del sistema, quien le coloca los nombres claves una vez recibidos los programas fuentes y ‚stos son compilados.

En la medida de lo posible, dependiendo de la envergadura del Servicio Inform tico y de la naturaleza de los sistemas, se deber¡a tratar de utilizar un Software de Resguardo Autom tico de Redes.

Cambios a los Programas de Aplicaci¢n :

Debe existir una solicitud con la autorizaci¢n respectiva para proceder a realizar los cambios a los programas.

El control sobre los programas objetos debe tenerlo el Administrador de Sistemas, y cualquier cambio a los programas deben ser probados y s¢lo reemplazados, despu‚s de demostrarse la confiabilidad del mismo.

Cuando se cambien los programas fuentes deben documentarse en el programa con comentarios y registrar las modificaciones en el Registro de Control de Cambios.

Asimismo el sistema debe contar con los elementos necesarios para poder darle mantenimiento, por lo que debe disponer de :

. Manuales de An lisis y Dise¤o. . Manual de Programaci¢n. . Programas Fuentes. . Originales de Software de Base. . Personal de programaci¢n que conozca el sistema.

Seguridades F¡sicas

Los ambientes donde se procesan los sistemas deben contar con un suministro de energ¡a el‚ctrica de calidad, con pozo de l¡nea a tierra, estabilizadores, UPS, equipos de reemplazo de energ¡a el‚ctrica, y extintores contra incendio.

Debe tambi‚n, en la medida de lo posible, disponer el acceso

restringido al rea donde se procesa la informaci¢n, sea al ambiente de los terminalistas o al centro de c¢mputo.

Seguridad ante contaminaci¢n de Virus

Ante la creciente proliferaci¢n de virus, debe existir instalado en el equipo central y equipos descentralizados sistemas antivirus, para prevenir la contaminaci¢n y afecci¢n de virus.

Deben, establecerse disposiciones espec¡ficas que prohiban al personal de sistemas o usuarios, utilicen diskettes externos a la instituci¢n, para evitar la introducci¢n de virus. En caso de recibir diskettes externos de trabajo oficial, ‚stos de todas maneras, deber n ser desinfectados antes de ser le¡dos por los equipos de c¢mputo.

Cuando sea factible, tal es el caso de sistemas que requieren s¢lo terminales, es preferible que ‚stos no tengan unidad de diskette para evitar la contaminaci¢n o infecci¢n.

En lo posible tambi‚n deber tratarse de utilizar Sistemas Operativ- os, que eviten la contaminaci¢n por virus. 3.2.8 SISTEMA DE RESPALDO

Previendo posibles problemas con el hardware o el software es necesario que el equipo central cuente con caracter¡sticas t‚cnicas de respaldo tales como :

- Sistema tolerante a fallas. - Tape-backup. - Equipo de capacidad similar de respaldo.

Asimismo, debe contarse con elementos para ser cargados en el otro equipo de respaldo:

- Instalador del Sistema o Backup del Sistema. - Backup de la Base de Datos por lo menos del turno anterior. En muchas oportunidades es conveniente, para reas cr¡ticas de atenci¢n al p£blico, disponer de listados diarios de informaci¢n resumen para poder seguir operando por lo menos manualmente en casos extremos.

Los backups de la Base de Datos deben efectuarse por cada cambio de turno de trabajo o como m¡nimo al final del d¡a, debiendo inclusive el sistema haber sido programado para que exija efectuar el backup respectivo.

Una copia de respaldo de los programas fuentes y objetos de las aplicaciones, de la plataforma de software y de las bases de datos completas de la Instituci¢n (hasta de tres per¡odos anteriores) y debe guardarse una copia en el local ad-hoc de la Instituci¢n e inclusive una copia adicional en otro local para afrontar siniestros o desastres que pudieran ocurrir.

3.2.9 AUDITABILIDAD DEL SISTEMA

Todo Sistema debe tener la capacidad de poder ser auditado, para lo cual debe reunir una serie de caracter¡sticas que lo permitan :

. Contar con la documentaci¢n completa. . Disponer de una biblioteca de pruebas. . Disponer de Log del Sistema. . Contar con reportes de auditor¡a del sistema. . Contar con reporteadores de base de datos para producir reportes de cruce de informaci¢n.

Por lo tanto deber verificarse que el sistema disponga de los elementos antes indicados para poder facilitar su auditor¡a y en caso de no contar con ellos exigir se disponga de ellos.

3.2.10 EFECTIVIDAD DEL SISTEMA

Uno de los aspectos m s importante del sistema, por ser su raz¢n de ser, es que sea efectivo en conseguir los objetivos y beneficios esperados, por lo que se deber :

. Efectuar visitas a los usuarios e indagar sobre su opini¢n respecto a :

- su satisfacci¢n de los resultados del sistema.

- el grado de confiabilidad que le dan al sistema.

. Evaluar en forma independiente en qu‚ magnitud los beneficios han sido conseguidos y cu les son las razones o limitaciones que impiden que ‚stos se logren.

. Determinar si los costos de operaci¢n del sistema se encuentran dentro de lo planificado y si son actualmente razonables para los beneficios tangible e intangibles obtenidos.

Se deben evaluar aspectos tales como :

. Qu‚ mejoras se han obtenido en la reducci¢n de costos de operaci¢n. . Qu‚ mejoras se han obtenido en las operaciones de la Instituci¢n. . Cu nto ha mejorado la precisi¢n de la informaci¢n obtenida. . Qu‚ mejoras se han obtenido en disponer de la informaci¢n completa requerida. . Qu‚ mejoras se han obtenido respecto a incluir controles en las operaciones de la Instituci¢n. . Qu‚ incremento se han obtenido en el n£mero de operaciones aten- didas, mejorando el tiempo de atenci¢n a los usuarios. . Qu‚ incremento de productividad de la instituci¢n se ha obtenido. . Qu‚ mejoras se han producido en la organizaci¢n del rea involucrada en el sistema.

4.1 MODALIDADES DE PRUEBAS

Existen dos modalidades de pruebas que se deben hacer al sistema

- Pruebas de Rutas.

- Pruebas de especificaci¢n.

Pruebas de Rutas :

Tambi‚n es conocida como prueba de c¢digo. Examina la l¢gica del programa, para lo cual se desarrollan casos de prueba que fuercen a probar la ejecuci¢n de todas las instrucciones de cada m¢dulo o ruta de un programa.

Como un sistema puede tener cientos de m¢dulos, debe priorizarse cu- les son los m s cr¡ticos de ser probados, de tal forma de poder probar dentro de plazos y costos razonables las rutas m s importantes del sistema.

Pruebas de Especificaci¢n :

En ‚sta, se examina el sistema bajo diferentes situaciones. Que ejecute lo que indican las especificaciones, bajo casos de pruebas preparados para dicho fin. En este caso se tratan a los programas como si fueran cajas negras, s¢lo siendo de inter‚s de que si se cumplen siempre las especificaciones, el sistema no falla.

4.2 NIVELES DE PRUEBA

Existen 2 niveles :

- Pruebas parciales.

- Pruebas de sistemas.

PRUEBAS PARCIALES:

Este consiste en probar independientemente los m¢dulos de un sistema que llevan a cabo una funci¢n espec¡fica. A su vez existen dos m‚todos para llevar a cabo estas pruebas :

. M‚todo ascendente : Van de los m¢dulos inferiores a los superiores.

. M‚todo descendente : Van de los m¢dulos superiores a los inferiores.

PRUEBAS DEL SISTEMA :

No prueba el detalle de cada m¢dulo, sino m s bien la integraci¢n de cada m¢dulo en el sistema, buscando las discrepancias que ocurran y la falta de compatibilidad entre ellos.

4.3 PRUEBAS ESPECIALES DE SISTEMA

Existen 6 pruebas b sicas :

- Prueba de carga m xima. - Prueba de almacenamiento. - Prueba de tiempo de ejecuci¢n. - Prueba de recuperaci¢n. - Prueba de procedimientos. - Prueba de recursos humanos.

Prueba de Carga M xima :

Consiste en probar si el sistema puede manejar el volumen de activid-

ades que ocurren cuando el Sistema est en el punto m s alto de su demanda de procesamiento, tanto en n£mero de transacciones, n£mero de terminales y magnitud de los valores.

Prueba de Almacenamiento :

Determinar si el sistema puede almacenar una alta cantidad proyectada de datos tanto en sus dispositivos de discos fijos y removibles, y seg£n el dise¤o y configuraci¢n de los archivos.

Prueba de Tiempo de Ejecuci¢n :

Determina el tiempo de m quina que el Sistema necesita para procesar los datos de una transacci¢n, si en su m xima carga (volumen de informaci¢n y n£mero de terminales simult neos) el tiempo de respuesta es adecuado para las funciones de : . Ingreso de Datos. . Actualizaci¢n. . Transmisi¢n. . Proceso. . Reordenamiento e indexaci¢n de archivos. . Consultas. . Impresiones de comprobantes y listados.

Pruebas de Recuperaci¢n

Probar la capacidad del sistema para recuperar datos y restablecerse despu‚s de una falla. Para efectuar estas pruebas se deben previamente sacar copias de respaldo de los archivos reales. Prueba de Procedimientos

Evaluar la claridad, validez seguridad as¡ como su facilidad de uso y sencillez de los manuales de procedimientos y operaci¢n respecto a la operaci¢n real del Sistema, haciendo que los usuarios lleven a cabo exactamente lo que el manual pide.

Los manuales deben contener una gu¡a de respuestas ante mensajes de advertencia, error, o contingencia.

Asimismo se debe verificar su actualizaci¢n y concordancia con la versi¢n del software aplicativo al cual pertenecen.

Prueba de Factores Humanos

Se determina c¢mo utilizar n los usuarios el sistema al procesar datos

o preparar informes.

Respecto al sistema : debe ser amigable y de f cil operaci¢n, con gu¡a interactiva de orientaci¢n al usuario y mensajes indicativos de ocurrencias del sistema.

Evaluar, respecto a los usuarios : el nivel de capacitaci¢n, el grado de utilizaci¢n del sistema, su correcta aplicaci¢n o uso.

Evaluar, respecto al personal de inform tica : el nivel tecnol¢gico para operar el sistema y la disponibilidad de t‚cnicos con capacidad de mantener el sistema.

4.4 TIPOS DE DATOS DE PRUEBA

Datos reales : los cuales permiten probar ocurrencias y casos reales que se presentan en la Instituci¢n, aunque no permiten probar otras rutas programadas pero que no han sido alcanzados por los usuarios para las pruebas en el caso de sistemas en desarrollo, o que no ocurren actualmente en el per¡odo de prueba de los sistemas en funcionamiento.

Datos artificiales : Son los que se crean artificialmente tratando de considerar todas las combinaciones y rutas posibles, debiendo en lo posible ser preparados por personas distintas de las que programaron el sistema.

Se recomienda contar con una Biblioteca de Pruebas que es un conjunto de datos preparados para probar todo el sistema en su conjunto y que se utiliza tanto cuando se desarrolla el sistema, como cuando se audita y se hace modificaciones al software, debiendo archivarse en una biblioteca especialmente organizada para tal fin. Esto tambi‚n permite que con la misma biblioteca puedan probarse los sistemas interrelacionados.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿

³ CONTROL INTERNO AL ³ ³ SERVICIO INFORMATICO ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

La evaluaci¢n de un Sistema no s¢lo depende del Sistema en s¡, sino del entorno en la que se desenvuelve, es decir el sistema puede haber sido dise¤ado correctamente, pero el Area de Servicio Inform- tico puede tener problemas que afectan al Sistema, por lo que tambi‚n debe hacerse un "Control Interno al Servicio de Inform tica".

El Control Interno al Servicio de Inform tica debe contemplar:

. La Organizaci¢n. . Los Procedimientos Generales. . Metodolog¡as Utilizadas. . Recursos Humanos. . Seguridad.

5.1 EVALUACION Y CONTROL DE LA ORGANIZACION

Se deber verificar que por un concepto de integralidad, existan funciones claramente definidas que obligatoriamente deben efectuarse y que existan grupos de trabajo diferenciados, que permita delimitar responsabilidades y dinamizar la gesti¢n de inform tica. Las funciones que deben existir son :

- Desarrollo de Sistemas. - Operaci¢n de Sistemas. - Mantenimiento de Sistemas. - Soporte T‚cnico. - Soporte a equipos. - Control de Sistemas.

La magnitud de la organizaci¢n del servicio inform tico, depende tambi‚n de la envergadura de la Instituci¢n. Sin embargo, debe existir la divisi¢n funcional que permita su adecuado desenvolvimiento.

5.2 EVALUACION FUNCIONAL

Desarrollo de Sistemas Debe estar claramente diferenciada la funci¢n del "Desarrollo de S- istemas" de "Operaci¢n de los Sistemas", de tal forma de permitir dos grupos de personal con funciones que puedan desarrollarse independientemente y en forma permanente, sin restringir la capacidad de desarrollo por razones de carga operativa de trabajo.

Operaci¢n de Sistemas

Esta ser efectuada por personal operativo, encargado de que los sistemas operen adecuadamente, tanto en el Centro de c¢mputo como en las reas usuarias descentralizadas. Para la realizaci¢n de esta funci¢n deben existir para cada sistema los Manuales de Operaci¢n respectivos, los cuales deben contener:

. El proceso normal. . Mensajes de advertencia y error. . Recomendaciones para la soluci¢n a los mensajes presentados. . Puntos de reinicio. . Comunicaci¢n de Problemas.

Mantenimiento de Sistemas La ubicaci¢n de la funci¢n de mantenimiento de sistemas, depende del estado evolutivo del rea de servicio inform tico, es as¡ que si reci‚n se inicia un plan ambicioso de desarrollo de sistemas, es preferible no distraerlo en funciones de mantenimiento de sistemas y ubicarla como una unidad del Area de Operaci¢n de Sistemas. Sin embargo si gran parte del desarrollo del sistema ya ha sido efectuado, es conveniente ubicar la funci¢n de mantenimiento de sistemas dentro del Area de Desarrollo de Sistemas.

En todo caso siempre debe existir un control de cambios y la oblig- atoriedad de que los cambios sean autorizados.

Soporte T‚cnico

Todo Servicio de Inform tica debe tambi‚n desarrollar funciones de soporte t‚cnico, por el continuo avance tecnol¢gico. Dependiendo de la magnitud de la Instituci¢n esta puede ser desarrollada desde un solo especialista hasta contar con una unidad especializada, donde se d‚ soporte a las plataformas que se utilicen o que se tengan que implementar en la Instituci¢n en el mbito de Sistema Operativo, Base de Datos, Comunicaciones y equipos de c¢mputo.

Para fines de soporte t‚cnico es muy importante que exista un registro de fallas y solicitudes, as¡ como de atenciones de soportes t‚cnicos brindados.

Soporte a Equipos de C¢mputo

Dependiendo tambi‚n de la envergadura de la Instituci¢n deber realizarse la funci¢n de atenci¢n a los problemas de los equipos de c¢mputo, donde debe existir una persona o una unidad que se encargue de dicho aspecto, ya sea dando atenci¢n directa o administrando un servicio externo de mantenimiento y soluci¢n de problemas de los equipos de c¢mputo.

Debe existir Registros de :

. Equipos existentes. . Softwares instalados en cada equipo. . Mantenimientos realizados a cada equipo firmados por el proveedor, soporte t‚cnico y usuario.

Control de Sistemas

Debe existir una funci¢n de Control de Sistemas que pueda efectuar control preventivo durante el desarrollo de sistemas y correctivo durante su funcionamiento. Que efect£e coordinaciones para evaluar la satisfacci¢n del usuario, control a los planes y presupuestos y seguimiento de las observaciones a los sistemas.

En peque¤as Instituciones puede ser llevado a cabo por la Jefatura del Servicio Inform tico. En medianas, por un Especialista Contralor, o una unidad para los casos de Instituciones de

envergadura.

5.3 PROCEDIMIENTOS

Debe verificarse que existan normas y procedimientos precisos para la realizaci¢n de sus funciones, de tal forma de asegurar que se aplican est ndares y metodolog¡as comunes que den integralidad a las actividades que realicen.

Las normas que deber¡an disponer son :

. Norma de An lisis de Sistemas. . Norma de Dise¤o de Sistemas. . Norma de Programaci¢n de Sistemas. . Norma de Implantaci¢n de Sistemas. . Norma de Operaci¢n de Sistemas. . Norma de Mantenimiento de Sistemas. . Norma de Control de Sistemas.

Los procedimientos que debieran estar disponibles son :

. Procedimientos de Operaci¢n de todos los Sistemas. . Procedimiento General de Seguridad. . Procedimiento General de Respaldo de la Informaci¢n. . Procedimientos ante Contingencias. . Procedimientos de Administraci¢n de Bibliotecas de Software.

5.4 METODOLOGIAS

El nivel y la calidad del Servicio Inform tico depender del uso de metodolog¡as modernas, entre las que podemos mencionar :

Planeamiento de Sistema :

. Planeamiento Estrat‚gico de Sistemas de Informaci¢n An lisis de Sistemas :

- Entrevistas. - Diagrama de Flujo de Datos (D.F.D.). - Modelizaci¢n de Datos. - Diagrama de Estructura de Datos (D.E.D.). - Historia de Vida de la Entidad (H.E.V.). - An lisis de Costo-Beneficio (A.C.B.). - Prototipeo.

Dise¤o de Sistemas :

- Dise¤o Estructurado. - Diagrama de Estructura de Cuadros. - Optimizaci¢n del Dise¤o F¡sico. - Dise¤o de Pruebas. - Prototipeo.

Programaci¢n :

- Programaci¢n Estructurada. - Pruebas Unitarias. - Pruebas de Integraci¢n. - Prueba del Sistema.

Implantaci¢n de Sistemas : - Capacitaci¢n. - Creaci¢n de archivos iniciales. - Proceso en paralelo.

5.5 RECURSOS HUMANOS

Debe evaluarse que la formaci¢n y experiencia de los recursos humanos, asignados a cada Area para el desempe¤o de sus funciones, sean las adecuadas.

Se debe analizar tambi‚n el balance de la cantidad de recursos humanos por Area, de tal forma que no existan desequilibrios que afecten el desempe¤o del Servicio Inform tico en su conjunto.

Debe analizarse si los tiempos utilizados para la obtenci¢n de resultados en cada uno de los tipos de actividades son los adecuados y se efect£an dentro de los plazos razonables.

5.6 SEGURIDAD

Debe comprobarse que el Area de Servicios Inform ticos cuente con los siguientes tipos de seguridad :

- Seguridad en el acceso a la informaci¢n.

- Seguridad de los Sistemas. - Seguridades F¡sicas.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ DE LOS SERVICIOS EXTERNOS ³ ³ DE COMPUTACION ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

Dependiendo de la pol¡tica de la Instituci¢n puede ser encargado el desarrollo, la implantaci¢n y la operaci¢n de uno o varios sistemas a Servicios Externos de Computaci¢n.

En estos casos tambi‚n deben aplicarse los mismos controles y veri- ficaciones indicados en la presente norma, donde el Area de Inform- tica de la Instituci¢n deber efectuar permanentemente la tarea de fiscalizaci¢n de los Servicios Externos de Computaci¢n.

En estos casos se debe reforzar en el Area de Inform tica las siguientes funciones :

- Planeamiento de Sistemas.

- Definici¢n de Requerimientos de Sistemas.

- Especificaci¢n de Requerimientos.

- Elaboraci¢n de T‚rminos de Referencia de Sub-Contrataci¢n de Servicios Externos de Computaci¢n.

- Control de los Servicios Externos.

- Control de Sistemas.

Cuando se realice actividades de auditor¡a del Area de Inform tica deber evaluarse el desempe¤o de las funciones antes mencionadas ya que son de primordial importancia cuando se trabaja bajo sub-contrataciones.

6.1 PLANEAMIENTO DE SISTEMAS

Es preferible que el Planeamiento de Sistemas lo realice el Area de Inform tica de la propia Instituci¢n, ya que el personal se encuen- tra involucrado con sus objetivos y metas, as¡ como experimenta permanentemente las vivencias de su organizaci¢n.

Sin embargo, muchas veces el trabajo Planeamiento de Sistemas es e- ncargado a un Servicio Externo, en todo caso, ‚ste debe tomarse como una Asesor¡a y la participaci¢n del Area de Inform tica es fundamental.

6.2 DEFINICION DE REQUERIMIENTOS DE SISTEMA

Es conveniente que la definici¢n de requerimientos de sistema por parte de las diferentes reas de la Instituci¢n, sea determinado por el Area de Inform tica, ya que permitir efectuar una prioriz- aci¢n del desarrollo y mantenimiento de sistemas desde el punto de vista institucional, y plantear la sub-contrataci¢n de los servicios externos de computaci¢n en la medida de las necesidades.

6.3 DEFINICION DE ESPECIFICACIONES DE REQUERIMIENTOS

Esta funci¢n, de preferencia, deber ser efectuada por el Area de Inform tica de la Instituci¢n, lo cual servir de base para la confecci¢n de los t‚rminos de referencia de las Sub-Contrataciones de Servicios Externos de Computaci¢n.

6.4 ELABORACION DE TERMINOS DE REFERENCIA DE LA SUB-CONTRATACION DE SERVICIOS EXTERNOS DE COMPUTACION

En los T‚rminos de Referencia de Sub-Contrataci¢n de Servicios Externos de Computaci¢n, deber establecerse claramente las normas, metodolog¡as y plataformas que se utilizar n para mantener est ndares e integralidad dentro de la Instituci¢n. Tambi‚n debe quedar claramente especificado que estar n sujetos a los mecanismos de control establecidos en las presentes normas, tanto durante el desarrollo de sistemas, as¡ como durante su funcionamiento si as¡ fuera el caso.

6.5 Control de los Servicios Externos

Los Servicios Externos de Computaci¢n deben ser controlados en base a la funci¢n Sub-Contratada, aplicando para cada caso la parte cor- respondiente de las normas y controles establecidos en el presente documento.

6.6 Control de Sistemas

Si es pol¡tica de la Instituci¢n la Sub-Contrataci¢n de Servicios Externos de Computaci¢n, se hace m s prioritario e importante fort- alecer la funci¢n de Control de Sistemas. En ese sentido se deber efectuar permanentemente controles preventivos durante el desarrollo de sistemas y correctivos durante su funcionamiento, efectuar coordinaciones para evaluar la satisfacci¢n del usuario, controlar los planes y presupuestos y hacer seguimiento de las observaciones a los sistemas.

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ GLOSARIO DE TERMINOS ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

ANALISIS DE COSTO BENEFICIO

Es una t‚cnica utilizada en el An lisis de Sistemas que tiene como objetivo fundamental proporcionar una medida de los costos en que se incurren en la realizaci¢n de un proyecto inform tico y, a su vez, comparar dichos costos previstos con los beneficios esperados en la realizaci¢n de dicho proyecto.

ANALISIS DE SISTEMAS

Es el proceso mediante el cual se estudian e interpretan los hechos del sistema actual, con el fin de especificar los requerimientos y especificaciones funcionales del nuevo sistema a desarrollar.

CONFIABILIDAD DEL SISTEMA

Se define que un sistema es confiable cuando posee los controles y las seguridades del caso, permitiendo que sus resulta-

dos sean exactos y que su operaci¢n sea estable y segura.

DISE¥O ESTRUCTURADO

Es una t‚cnica utilizada en el Dise¤o de Sistemas, para obtener la estructura modular y los detalles de proceso del sistema, partiendo solamente de la informaci¢n obtenida en la fase de an lisis de sistemas En ‚sta se define c¢mo debe estructurarse el sistema utilizando herramientas gr ficas.

DIAGRAMA DE ESTRUCTURA DE CUADROS

Es una t‚cnica utilizada en el Dise¤o de Sistemas para modelar el sistema computarizado, visualizando modularmente el sistema, la conexi¢n y comunicaci¢n entre los mismos, dando una visi¢n integral de la Arquitectura del Sistema.

DIAGRAMA DE ESTRUCTURA DE DATOS (DED)

Es una t‚cnica utilizada en el An lisis de Sistemas para la modelizaci¢n de datos, la cual representa un conjunto de datos relacionados entre s¡ y describen en forma colectiva un componente del sistema. DIAGRAMA DE FLUJO DE DATOS (DFD)

Proporciona una representaci¢n del sistema a nivel l¢gico y conceptual, describiendo el movimiento de los datos en el sistema, ya sea manual o autom tico, incluyendo procesos y lugares para almacenar datos.

DIAGRAMAS DE GANTT

Son herramientas que se utilizan en la planificaci¢n de un proyecto o etapas del mismo, y que consiste en el registro de lo planificado y de lo ejecutado a trav‚s de barras de difer- ente dise¤o en dos ejes, una de actividades y la otra de la variable tiempo.

DISE¥O DE PRUEBAS

Es una t‚cnica utilizada en el Dise¤o de Sistemasque consiste en definir un programa de pruebas, para asegurar la confiabilidad del dise¤o y de que no existen errores en los programas que se especifiquen.

DISE¥O DE SISTEMAS

Es el proceso de definici¢n de la arquitectura de software: componentes, m¢dulos, interfaces, procedimientos de pruebas y datos de un Sistema que se crean para satisfacer unos requerimientos espec¡ficos.

ENTREVISTAS

Es una t‚cnica que se utiliza en el An lisis de Sistemas para recabar la informaci¢n verbal, a trav‚s de una serie de preguntas que propone el analista. Esta a su vez es imprescindible para obtener informaci¢n cualitativa, relacionarse con los usuarios y recoger un conjunto de hechos y/o requeri-

mientos de informaci¢n necesaria para el estudio.

HISTORIA DE VIDA DE LA ENTIDAD

Es una t‚cnica utilizada en el An lisis de Sistemas que permite describir la evoluci¢n de las entidades de datos del sistema. Esta t‚cnica utiliza las entidades de datos identific- ados y descritas en los Diagramas de Estructura de Datos (DED) y en las transacciones o eventos del sistema identificado en el Diagrama de Flujo de Datos (DFD). Tambi‚n constituye un poderoso instrumento para verificar la exactitud de los dos modelos antes mencionados y garantizar la coherencia entre las tres versiones del sistema.

IMPLANTACION DE SISTEMAS

Es el proceso por el cual se instala un sistema, se crean los archivos maestros, se capacita al personal involucrado, se procesa un per¡odo de informaci¢n, se efect£an ajustes al sistema y se inicia la producci¢n del sistema.

INTEGRACION DE SISTEMAS

Es el proceso por el cual se analiza, dise¤a y programa las interfases entre diferentes aplicaciones, sub-sistemas y sistemas, de tal forma que no se desarrollen sistemas aislados, sino m s bien interconectados que compartan archivo y base de datos comunes y se transfieran informaci¢n entre ellos.

INTEGRIDAD DE LA INFORMACION

Consiste en que los valores de los datos se mantengan tal como fueron puestos intencionalmente en el Sistema. Las t‚cnicas de integridad sirven para prevenir que existan valores errados en los datos provocados por el software de la Base de Datos o por fallas de programas o del sistema. El concepto de integridad abarca la precisi¢n y la fiabilidad de los datos, as¡ como la discreci¢n que se debe tener con ellos.

INTEGRIDAD DEL SISTEMA

Es una caracter¡stica que deben poseer los sistemas computarizados . Consiste en que se deben tener las seguridades de que el software no puede ser alterado ni la informaci¢n producida puede ser accesada por personas no autorizadas, para lo cual deben existir los controles y seguridades del caso.

MODELIZACION DE DATOS

Es una t‚cnica utilizada en el An lisis de Sistemas para conseguir estructuras de datos no redundantes, sin inconsistenc- ias, seguras e ¡ntegras, utilizando representaciones gr ficas.

OPTIMIZACION DEL DISE¥O FISICO

Es una t‚cnica utilizada en el Dise¤o de Sistemas para optim- izar el modelo de datos elaborado en la fase de An lisis de Sistemas, permitiendo obtener la estructura f¡sica del

sistema, as¡ como la representaci¢n ¢ptima de la informaci¢n.

PERT-CPM

Es una t‚cnica que se utiliza en la planificaci¢n de proyectos o etapas del mismo, y que consiste en el registro de las actividades, recursos y costos planificados, as¡ como los ejecutados realmente mediante representaci¢n gr fica de nodos y fechas de dependencia de actividades. PLATAFORMA DE HARDWARE

Es el conjunto de equipos que se utiliza para desarrollar y operar un sistema o todos los sistemas de una organizaci¢n, com prendiendo el Computador Central, las estaciones de trabajo tales como terminales, equipos de microcomputaci¢n, impresoras, as¡ como equipos de comunicaci¢n local en Red o remotas.

PLATAFORMA DE SOFTWARE

Es el conjunto de Software de Base y Aplicativos de uso general que se utiliza para un sistema determinado o para toda la organizaci¢n, consistente de los sistemas operativos, sistemas de bases de datos, sistemas de redes, sistemas de comunicaciones y sistemas generales de automatizaci¢n de oficinas.

PROCESO EN PARALELO

Es una t‚cnica utilizada en la implantaci¢n de sistemas, que consiste en permitir que se siga utilizando el sistema anterior, mientras se procesa paralelamente el nuevo sistema, de tal forma de comparar resultados y efectuar el reemplazo necesario con la seguridad de la correcta operatividad y confiabilidad del nuevo sistema.

PROGRAMACION ESTRUCTURADA

Es una t‚cnica utilizada en la Programaci¢n de Sistemas, y que consiste en llevar a cabo la programaci¢n en forma modular y utilizar sub-funciones para ser utilizadas en forma com£n.

PROGRAMACION DE SISTEMAS

Es el proceso por el cual el dise¤o de un sistema se transcr- ibe a un lenguaje de programaci¢n que pueda ser interpretado por el computador, para que ‚ste ejecute instrucciones que realicen las funciones, especificados para el nuevo sistema. PROTOTIPEO

Es una t‚cnica utilizada en el An lisis de Sistemas y Dise¤o de Sistemas, que permite desarrollar con rapidez un sistema de trabajo computarizado, para posibilitar probar el dise¤o ante el usuario en un software provisional que permite analizar en forma f¡sica el ingreso de los datos, el procesamiento y la emisi¢n de resultados, y poder efectuar los ajustes necesarios para el dise¤o definitivo.

PRUEBAS DE INTEGRACION

Son las que deben realizarse para probar la integraci¢n entre los componentes del sistema y asegurarse que encajen correctamente.

PRUEBAS DEL SISTEMA

Son las que deben realizarse para probar el sistema globalme- nte.

PRUEBAS UNITARIAS

Son las que deben realizarse para probar todos los componentes del sistema que se desarrollan individualmente.

RESPALDO DE LA INFORMACION

Es la informaci¢n que se archiva en un medio alternativo al del almacenamiento de un computador con fines de disponer de una copia de seguridad por si ocurriese p‚rdidas del sistema o la informaci¢n.

Documents

Auditoria de Sistemas