desarrollo de sistemas

© 2009 DATABASE TEAM -- www.db-team.com© 2009 Hermenegildo Romero -- [email protected]

Desarrollo, adquisición e implantación de nuevos sistemas

Hermenegildo Romero


Desarrollo, adquisición e implantación de nuevos sistemas

• Acercamiento al ciclo de vida del desarrollo.• Personas implicadas en el proceso• Evaluación de riesgos• Auditoría del desarrollo de sistemas• Metodologías de desarrollo• Gestión de proyectos de desarrollo• Calidad de software


El ciclo de vida del desarrollo

• Dependiendo de la metodología seleccionada, cada metodología tiene su propio ciclo de vida

• Quizás la metodología más facilmente comprensible es la conocida como Waterfall Model.

• Aunque hoy en día hay otras alternativas incluso más indicadas para la gestión de proyectos de desarrollo software.– Metodología de prototipos– Incremental– Espiral– RAD (Rapid Application Development)


El ciclo de vida del desarrollo

… en las citadas metodologías se basan algunos de los modelos de desarrollo que se enumeran aqui…

• Antes de los 80– Structured programming 1969– Jackson Structured Programming 1975

• Los 80– Structured Systems Analysis and Design Methodology (SSADM) desde 1980 en adelante– Structured Analysis and Design Technique (SADT) desde 1980 en adelante– Information Engineering (IE/IEM) desde 1981– Merise desde finales de los 80

• Los 90– Object-oriented programming (OOP) 1990s.– Rapid application development (RAD) 1991.– Virtual finite state machine (VFSM) 1990s– Dynamic Systems Development Method UK-1995.– Scrum desde 1990s

• En los últimos años– Extreme Programming since 1999– Enterprise Unified Process (EUP) y RUP desde 2002– Rational Unified Process (RUP) desde 2003.– Constructionist design methodology (CDM) desde 2004– Agile Unified Process (AUP) desde 2005


waterfall model

• Etapa 1– Viabilidad

• Se especifican los beneficios de implementar el sistema.

• Etapa 2– Definición de los requisitos

• En esta etapa se desarrollan y especifican los requisitos reflejados durante la etapa de viabilidad para el desarrollo del sistema.

– Funcionalidades del sistema (lo que debe hacer)– Interacción del usuario con el sistema– Condiciones de operación del sistema– Información generada por el sistema y su tratamiento


waterfall model

• Etapa 3– Diseño

• Especificaciones de programación

• Especificaciones de base de datos

• Especificaciones de seguridad, etc...

• Etapa 4– Desarrollo

• Parte desde el diseño para llevar a la practica los distintos procesos orgánicos descritos en la fase de diseño

• En esta fase también se incluyen las pruebas del sistema antes de pasar a producción

• Etapa 5– Implementación

• El sistema se lleva a producción después de la aceptación del usuario final

• Etapa 6– Mantenimiento


waterfall model

Viabilidad

Requisitos

Diseño

Desarrollo

Implementación

Waterfall Model


Personas implicadas en un proceso de desarrollo o adquisición de sistemas• La alta dirección• Los directivos del área usuaria del sistema• El comité de dirección del proyecto• Patrocinador del proyecto• Director de desarrollo de sistemas• Jefe del proyecto• Desarrolladores del sistema• Usuarios designados para el proyecto.• Responsable de seguridad• Departamento de Calidad


Evaluación de riesgos

• Básicamente el gran número de riesgos que pueden presentarse en un proyecto de desarrollo y adquisición, pueden resumirse en:– Riesgos del negocio

• El sistema no satisface las necesidades, los requerimientos y las expectativas de negocio de la compañía

– Riesgos inherentes al proyecto• Presupuestarios (recursos)• Tiempo de entrega



• Generalmente el riesgo se manifiesta por una falta de disciplina a la hora de administrar el proceso.– Una buena gestión del proceso puede:

• Favorecer el control• Ayudar a la medición del progreso• Identificar áreas de mejora

– Este proceso también se conoce como SDLC (Systems Development Life Cycle, “Ciclo de vida del desarrollo de sistemas”)



• Seguir una metodología de desarrollo de software no implica el éxito del proyecto. – Se hace necesaria una revisión de:

• La planificación del proyecto, con una correcta estimación de recursos y tiempo.

• Realizar un seguimiento de las actividades de diseño y desarrollo.

• Soporte y participación de la alta dirección en las etapas de diseño y desarrollo del proyecto.



• Riesgos en la fase de estudio de viabilidad– No disponer de estudio viabilidad

• No hay una determinación clara acerca de los beneficios del sistema.

• No se conocen los riesgos inherentes al desarrollo del sistema– Marco de tiempo– Recursos necesarios para el desarrollo, implementación y mantenimiento

del nuevo sistema.» Personal» Software» Hardware» Etc...



• ...Riesgos en la fase de estudio de viabilidad– ...No disponer de estudio de viabilidad

• No se posee una idea acerca del ahorro de costos que supone el nuevo sistema, su capacidad productiva o los beneficios de su implementación.

• No se puede determinar si existe en la compañía un sistema en funcionamiento que pueda hacerse cargo de las funcionalidades de la nueva con pocas o ningunas modificaciones.

• No se conoce si existe un producto comercial de terceros que pueda dar solución a las funcionalidades requeridas por el nuevo sistema con el consiguiente ahorro en tiempo.



• ...Riesgos en la fase de estudio de viabilidad– ... No disponer de estudio viabilidad

• No hay respuesta a la pregunta ¿Encaja el sistema proyectado en la estrategia de negocio de la compañía?

• No se tiene una idea aproximada del retorno de la inversión proyectada para el nuevo sistema (ROI).

• Puede afectar a un incremento de costos futuros debido a que:– El proyecto desarrollado no cumpla las expectativas del negocio.– Una vez comenzado el proyecto se cuestione su rentabilidad y se pare el

proyecto con el consiguiente gasto realizado.



• ...Riesgos en la fase de estudio de viabilidad– Una de las claves mas importantes del estudio de viabilidad se centra en la

decisión acerca de desarrollar un nuevo sistema o adquirir uno existente de terceros

Desarrollar Adquirir



• ...Riesgos en la fase de estudio de viabilidad– Factores que afectan a la decisión de desarrollar frente a

adquirir un software “llave en mano”• La fecha límite de entrada en producción• Comparativa costo-desarrollo vs costo-“llave en mano”• Recursos necesarios en las distintas fases del proyecto

– Personal

– Software

– Hardware

– Etc...

• Compatibilidad con la estrategia de negocio presente y futura de la compañía• Compatibilidad con la estructura tecnológica existente de sistemas de

información



• ...Riesgos en la fase de estudio de viabilidad– Desarrollar frente a adquirir

• El estudio de viabilidad debe contener argumentos que respalden la decisión de adquirir el software.

• En caso de no existir este estudio se incurren en los mismos riesgos que podemos encontrar en el proceso de desarrollo del software.



• Riesgos asociados a la definición de los requisitos del sistema.– La correcta definición de requisitos del sistema influye en

su posterior:

• Efectividad

• Eficiencia

• Confidencialidad

• Integridad

• Disponibilidad

• Cumplimiento y fiabilidad



• ...Riesgos asociados a la definición de los requisitos del sistema.– Los riesgos de una incorrecta o inexistente definición de

requisitos se pueden traducir en:• No reconocimiento del sistema por parte de los usuarios (prototipos, pantallas)• Expectativas de los usuarios no cumplidas (involucración del usuario)• Prioridades y conflictos no resueltos• Baja o nula integración del sistema con el entorno de negocio y tecnológico• Requerimientos no viables• Ambigüedad o interpretaciones erróneas.




requisitos se pueden traducir en:

• Rectificaciones en la fase de desarrollo para revisar los requerimientos (scope creep) sobrecostes retrasos.

– A menor esfuerzo en la fase de definición, mayor coste por redefinición durante la fase de desarrollo.

• No disponer de los elementos de control necesarios para saber si el desarrollo del proyecto se está realizando en tiempo y manera.

• Asegurarse los recursos necesarios tanto para la fase de desarrollo como para la de implementación o mantenimiento.

• Carecer de compromisos de los departamentos y personas implicadas en el proyecto...(desarrolladores, usuarios, directivos).




requisitos se pueden traducir en:

• La inexistencia de un método para el control de cambios hará que no se revisen los costes derivados de la redefinición de requisitos durante la fase de desarrollo.

• No establecer las medidas mínimas de seguridad durante el desarrollo del proyecto acerca de la:– Confidencialidad– Integridad– Disponibilidad

• No disponer de las pistas de auditoria necesarias en el sistema, que ayuden a la capacidad del auditor para, identificar los posibles problemas o errores del sistema.



• Fase de desarrollo– Falta de estándares para la codificación de programas

• Código espagueti (ilegibilidad)

• Mentes distintas estructuras de código distintas

– Documentación interna a nivel de código• Dificultad para encontrar procedimientos, funciones o funcionalidades

• Dificultad para interpretar el código por una persona distinta al escritor del mismo.

– Documentación externa acerca de modificaciones posteriores al sistema (control de cambios)

• Concurrencia de desarrolladores



• ...Fase de desarrollo– Almacenamiento y mantenimiento de los ficheros fuentes

• Desconocimiento de versiones• Control de cambios• Seguridad

– Normas de uso y aplicación de componentes en la programación estructurada



• ...Fase de desarrollo– Pruebas

• Realización del plan formal de pruebas• Generadores de datos de prueba• Documentación (actas) de los resultados de las pruebas• Las distintas pruebas a realizar:

– Prueba piloto

– Prueba de unidad

– Prueba de interface o integración

– ...



– ...

– Prueba final del sistema.

» De recuperación

» De seguridad

» De estrés

» De rendimiento

– Pruebas de función

– De regresión

– En paralelo

– De sociabilidad

• Cuando se completan las pruebas el auditor debe emitir una opinión a la dirección de la compañía respecto a si el sistema debe ser o no puesto en producción.



• Fase de implementación– Requerir la prueba de aceptación del usuario antes de la

implementación– Obtener las firmas de aprobación adecuadas antes de la

implementación– Seguir el proceso de implementación definido, cronograma de

implementación– Debe cumplir los requisitos y procedimientos de control de cambios



• ...Fase de implementación– El proceso de implementación así como el sistema

deben estar suficientemente documentados– Las distintas actualizaciones deben constar por escrito y

se debe asegurar de la implementación de las últimas actualizaciones después de la fase de pruebas

– Revisar la integridad de los datos generados en las etapas de prueba antes de la implementación



• ...Fase de implementación– Después de la implementación

• ¿Se alcanzaron los objetivos?• ¿Están reflejados todos los requerimientos del sistema?• Medir la satisfacción del usuario con el sistema• Analizar el costo-beneficio• Revisar las solicitudes de cambio• Revisar los controles integrados y pistas de auditoria• Revisar los registros de error o “logs” de actividad para localizar

posibles errores• Revisar los datos generados para garantizar su integridad



• Mantenimiento del sistema– Procedimientos de cambio

• Autorizaciones• Prioridades• Control de cambios y versiones• Pistas de auditoria para localizar cambios en el sistema.• Revisión y actualización de la documentación• Seguridad del sistema• Pruebas de los cambios• Integridad del código fuente• Comparación de versiones producción


Evaluación de riesgos en la adquisición

• Adquisición del software– Solicitud de propuesta

• Carecer de la solicitud de propuesta (Request for Proposal RFP), puede producir ambigüedades a la hora de entender los requerimientos del sistema por parte de los proveedores, así como realizar inversiones en sistemas que no se adecuan a las necesidades del negocio, requerimientos de usuarios, infraestructura tecnológica, etc... Tal como se vio en los riesgos asociados al desarrollo del software.

– Contenidos» Producto frente a los requisitos del sistema» Referencias de clientes» Viabilidad / estabilidad financiera del vendedor» Disponibilidad de documentación completa y fiable» Soporte del vendedor» Número de años de experiencia en el producto ofrecido» Lista de las actualizaciones recientes o planificadas del producto con sus fechas» Número de clientes usando el producto con una lista de usuarios actuales» Pruebas de aceptación del producto



• ...Adquisición del software– ...Solicitud de propuesta

• A partir de la solicitud de propuesta el equipo formado para su redacción y evaluación ha de evaluar cada una de las propuestas recibidas e identificar aquella que cumpla mejor los requisitos de negocio, usuarios, etc..., así como de presupuesto.

– Verificar las capacidades del sistema del proveedor a través de referencias

• Confianza en el producto, actualizaciones, mantenimiento.• Nivel de servicio del proveedor.• Formación y documentación del producto.



• ...Adquisición del software– Documentación del proceso de toma de decisión acerca de que

proveedor o solución seleccionar– El contrato

– Descripción especifica de los productos que van ha ser entregados y sus costos– Fechas de compromiso para la entrega de los productos– Documentación, mantenimiento, actualizaciones, notificaciones de nuevas versiones y

entrenamiento/formación.– Contrato fideicomiso del software (deposito de fuentes) si los productos no incluyen el código fuente– Soporte en la instalación– Disposición para permitir un periodo razonable de pruebas de aceptación, antes de comprometerse

con la compra.– Mantenimiento y soporte– Autorización para los cambios que deba hacer la compañía compradora– Autorización para mantener una copia del software que pueda actualizarse en el proceso de

continuidad del negocio y para fines de prueba– Programa de pagos vinculados con las fechas efectivas de entrega



• ...Adquisición del software– Pistas de auditoria– Controles de contraseñas– Deficiente seguridad general de la aplicación.



• ...Adquisición del software– En grandes instalaciones como ERPs debido a su impacto en la

compañía se hace necesario la realización de un estudio minucioso del impacto y riesgo de adquisición.


Auditoría de la organización y gestión del área de desarrollo

• Objetivos de control• Sobre la organización y cometidos del área de desarrollo.• Sobre la formación y motivación del personal del área.• Sobre el cumplimiento y actualización del plan de sistemas• Sobre la propuesta y aceptación de nuevos proyectos• Sobre asignación de recursos• Sobre aplicación de los métodos y procedimientos de la

ingeniería de software• Sobre procedimientos de relaciones con el resto de

departamentos y proveedores.



• Sobre la organización y cometidos del área de desarrollo– Establecer las funciones del área de desarrollo.

• Comprobar la existencia de un documento que contenga:– las funciones que son competencia del área

– que tiene las debidas aprobaciones

– que se respeta...



• ...Sobre la organización y cometidos del área de desarrollo– Especificación de los diversos puestos de trabajo del área y su

organigrama• Comprobar que existe un organigrama

• Comprobar que existe un manual que indique las relaciones entre los diversos puestos

• Comprobar que existe una relación del personal con inclusión de su labor, puesto dentro de la organización del área.

– Comprobar el cumplimiento.

• Comprobar si están establecidos los procedimientos para la promoción del personal, teniendo en cuenta la experiencia y formación.

– Comprobar el cumplimiento.



• ...Sobre la organización y cometidos del área de desarrollo– Planes a corto, medio y largo plazo y su coherencia con

el plan de sistemas.• Comprobar que el plan existe y es realista.• Comprobar que los recursos actuales son suficientes para el

cumplimiento del plan, para el futuro, siguiendo el plan, se asignarán nuevos recursos.

• Comprobar que el plan se revisa y actualiza periódicamente.• Comprobar la difusión a todos los empleados del área y otras

áreas que puedan verse afectadas.



• ...Sobre la organización y cometidos del área de desarrollo– Control presupuestario

• Comprobar que existe un presupuesto por cada ejercicio de actividad para el área.

– Comprobar su cumplimiento.

• Comprobar que el presupuesto está de acuerdo con los objetivos del área.



• Sobre la formación y motivación del personal del área.– Procedimientos de contratación.

• Comprobar la difusión de las ofertas de trabajo de forma suficiente fuera de la compañía.

• Comprobar que existen procedimientos de selección objetivos.

• Comprobar que los trabajadores seleccionados cumplen los requisitos del puesto al que tienen acceso.



• ...Sobre la formación y motivación del personal del área.– Plan de formación en consonancia con los objetivos tecnológicos del área.

• Comprobar la existencia del plan de formación a corto, medio y largo plazo– Comprobar que este sea coherente con la tecnología presente y futura del área.

– Que incluye información sobre fechas y horas, lugar, profesores, material, medios, etc..

• Comprobar la existencia de evaluaciones de asistentes a los distintos eventos formativos.

– Comprobar que estas evaluaciones influyen a la hora de tomar decisiones para la realización de otros eventos de carácter formativo.

• Comprobar que los planes de formación afectan a todos los empleados y tiene en cuenta la posición de cada uno de ellos.

• Los periodos de formación son tenidos en cuenta en los distintos cronogramas y plazos de desarrollo.



• ...Sobre la formación y motivación del personal del área.– Protocolos de recepción y abandono de personal del área

• Comprobar que los protocolos existen y son respetados.• Comprobar que el protocolo de incorporación incluye:

– Estándares de programación, organización, etc..., definidos.

– Organización del área.

– Definición de puestos

– Normas de uso internas

– Etc..

• Comprobar que el protocolo de abandonos incluye medidas que ayuden a la protección del área desde el punto de vista de:

– Seguridad

– Continuidad del negocio

– Propiedad intelectual

– Etc..



• ...Sobre la formación y motivación del personal del área.

– Existencia de materiales de apoyo• Comprobar que existen libros, publicaciones, etc..., y que el

personal tiene acceso a ellas.



• ...Sobre la formación y motivación del personal del área.

– Aspectos “motivacionales” del personal.• Comprobar que existen mecanismos para que los empleados

puedan hacer sugerencias.• La rotación es baja.• El ambiente de trabajo es bueno.• El rendimiento del personal es razonable.• El absentismo laboral es similar al del resto de la organización.



• Sobre el cumplimiento y actualización del plan de sistemas– El desarrollo de nuevos proyectos debe tener su base en el plan de

sistemas.• Comprobar que las fechas de realización coinciden con las del plan de

sistemas.

• Comprobar que la documentación existente en el plan de sistemas para cada proyecto es puesta a disposición del jefe del proyecto .

• Comprobar que la información en el plan de sistemas relativa a un proyecto contiene:

– Objetivos del proyecto– Requisitos– Plan inicial del proyecto



• ... Sobre el cumplimiento y actualización del plan de sistemas– Actualización continua del plan de sistemas

• Comprobar que los cambios en los proyectos son comunicados al responsable de mantener el plan de sistemas, para revisar las implicaciones que pueda conllevar el cambio, así como su actualización.



• Sobre la propuesta y aceptación de nuevos proyectos– Procedimientos para la propuesta de realización de nuevos proyectos

• Comprobar que existe un mecanismo de registro de las necesidades de desarrollo de nuevos sistemas.

– Comprobar que incluyen los siguientes datos:

» Descripción

» Necesidad

» Departamento

» Riesgos

» Tiempo

» Coste de la no realización

» Ventajas que aporta

» Adaptación a los planes de negocio

– Comprobar que se respeta el mecanismo para todas las propuestas de desarrollo



• ...Sobre la propuesta y aceptación de nuevos proyectos– ...Procedimientos para la propuesta de realización de nuevos proyectos

• Procedimientos de aceptación de nuevos proyectos– Este mecanismo depende o no de si existe plan de sistemas

– Si hay plan de sistemas

» Comprobar que se parte de las prioridades, pautas y planificación que marque el plan de sistemas para el desarrollo de un nuevo sistema.

– Si no existe plan de sistemas

» Comprobar la existencia de procedimientos de estudio y viabilidad de la propuesta, así como de coste-beneficio.

» Comprobar que existe una designación formal de las áreas de la organización que tienen competencia para aprobar formalmente la realización y prioridad de los nuevos proyectos.

» Comprobar los mecanismos de reasignación de prioridades si esto fuera necesario.



• Sobre asignación de recursos– Procedimientos para la asignación de jefe de proyecto y equipo de

desarrollo.• Comprobar que el procedimiento existe y se respeta.

• Comprobar que todo el personal del área que posea un perfil adecuado para cada proyecto y disponibilidad es tenida en cuenta.

• Existe un protocolo de petición de colaboración en el proyecto para el resto de áreas.

– Comprobar su aplicación.

– Procedimientos de obtención-petición de recursos materiales necesarios para el proyecto.

• Comprobar que el procedimiento existe y se respeta



• Sobre aplicación de los métodos y procedimientos de ingeniería de software– Implantación de metodologías de desarrollo de sistemas.

• Comprobar que la metodología de desarrollo se encuentra apoyada por una herramienta CASE y que esta cumple los requisitos mínimos para una herramienta de este tipo.

– Comprobar la existencia de un diccionario de datos mantenido por la herramienta.

– Comprobar si existe un procedimiento para seleccionar aquellos proyectos para los cuales el uso de la herramienta se recomienda y para cuales no.

– Comprobar si esta herramienta cumple los requisitos mínimos para asegurar la confidencialidad de la documentación asociada al proyecto.



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– ...Implantación de metodologías de desarrollo de sistemas.

• Comprobar que la metodología cubre todas las fases del desarrollo.

• Comprobar que la metodología es adaptable a distintos tipos de proyecto.

• Comprobar que la metodología se adapta a la tecnología y organización del área.

• Comprobar que el personal se encuentra debidamente formado sobre la metodología, su aplicación, así como en el uso de la herramienta CASE seleccionada.



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– Mecanismos de creación y actualización de estándares de

desarrollo.• Comprobar que el mecanismo de creación de estándares está

documentado.– Comprobar si es conocido por el personal del área.

• Comprobar que existe un estándar para la realización del análisis y diseño de un proyecto.

– Que incluya» Con que herramientas» Cual es la técnica a aplicar» Etc...



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– ...Mecanismos de creación y actualización de estándares de desarrollo.

• Comprobar la existencia de un estándar de programación para cada lenguaje de uso.

– Verificación de normas/estándares para evitar el “código espagueti”.

• Comprobar que se establecen estándares acerca de aspectos de desarrollo como:

– Módulos

– Nomenclatura

» Funciones

» Variables

» Tablas

» Columnas, etc..

– Comentarios

– Documentación asociada al código fuente

– Estilo de programación



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– ...Mecanismos de creación y actualización de estándares de desarrollo.

• Comprobar la existencia de un estándar para las documentaciones de proyectos.– Documentación técnica

» Análisis» Diseño» Documentación del código» Poblado de Bases de datos» Migraciones, etc..

• Comprobación de la existencia de estándares de diseño de interfaces de usuario, informes, etc...

• Comprobar que los estándares de desarrollo son conocidos por todas las personas implicadas en el proceso de desarrollo.

• Comprobar que las modificaciones sobre los estándares son debidamente difundidas a los miembros del área.



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– Homologación de herramientas y lenguajes de desarrollo.

• Comprobar la existencia de un mecanismo de adquisición y homologación de nuevos productos para el área.

• Comprobar que los usuarios de las herramientas adquiridas son formados de manera conveniente en su uso.

• Comprobar que se almacena información de configuración, instalación, etc., sobre los productos adquiridos.

• Comprobar que los productos son necesarios y suficientes para el logro de los objetivos del área.

• Comprobar que periódicamente se revisa el nivel tecnológico para establecer su coherencia con el plan de sistemas.



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– Mecanismos para asegurar la reutilización de módulos de desarrollo y componentes.

• Comprobar que existe un catalogo con los módulos, componentes y aplicaciones (desarrolladas y adquiridas) susceptibles de ser reutilizados en otros proyectos de desarrollo.

– Identificar si:» El catalogo es conocido y accesible en el área.» Si está actualizado» Posee índices de búsqueda



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– Métodos de estimación de tiempos de las distintas fases

de desarrollo en los proyectos.• Comprobar que existe un método y que el método usado es

correcto y está documentado.• Comprobar que se mantiene una base de datos con la duración

de las distintas fases de desarrollo de cada uno de los proyectos (proyectado vs real) y que estas desviaciones son usadas para la estimación de tiempos.



• ...Sobre aplicación de los métodos y procedimientos de ingeniería de software– Existencia de registros de incidencias por proyecto.

• Comprobar la existencia de una base de datos de problemas o incidencias con sus respectivas soluciones, así como el proyecto en que surgió y personas relacionadas con la resolución.

– Comprobar la accesibilidad

– Comprobar que se actualiza periódicamente

– Comprobar que posee índices de búsqueda



• Sobre procedimientos de relaciones con el resto de departamentos y proveedores.– Contacto permanente con proveedores

• Comprobar que se está en contacto con un numero suficiente de proveedores con el objetivo de recibir una información objetiva y completa.



• ... Sobre procedimientos de relaciones con el resto de departamentos y proveedores.

– Protocolos de contratación de servicios.• Comprobar que existe el procedimiento, esta documentado, aprobado y se hace

uso de el.– Debe incluir un contrato tipo que incluya:

» Riesgos más frecuentes» Penalizaciones en caso de incumplimiento

• Comprobar en la medida de lo posible que la selección de proveedor se realiza de manera objetiva.

• Comprobar que el personal externo que intervenga en los proyectos cumpla al menos los mismos requisitos que se exigen a los empleados del área.

• Comprobar que una persona supervisa el trabajo antes de proceder al pago.

• Los desarrollos externos deben cumplir todos los estándares establecidos.


Auditoría de la fase de viabilidad

• Objetivos de control• Sobre la definición, aprobación y planificación del proyecto

• Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma



• Estudios de viabilidad/factibilidad– Verificar si el proyecto es razonable mediante el estudio de la

documentación generada.

– Verificación de la justificación de Beneficios/costos, estos deben de ser presentados mostrando los beneficios anticipados que van ha ser obtenidos con el sistema.

– Identificar y determinar la importancia crítica de la necesidad que se desea satisfacer.

– Determinar si se puede alcanzar una solución con los sistemas ya existentes. En caso contrario, revisar la evaluación de las soluciones alternativas para verificar si estas son razonables.

– Determinar si la solución escogida es razonable.



• Sobre la definición, aprobación y planificación del proyecto– Orden de aprobación del proyecto

• Comprobar que incluye:– Definición de los objetivos– Restricciones

» Temporales» Recursos técnicos y humanos» Presupuesto

• Comprobar que está refrendada por un órgano competente.

• Comprobar que se han identificado las distintas áreas y personas a las que afecta el proyecto.



• ...Sobre la definición, aprobación y planificación del proyecto– Responsable del proyecto

• Comprobar que la designación se ha desarrollado siguiendo el procedimiento establecido

• Se le ha hecho entrega de la documentación e información relevante sobre el proyecto.



• ...Sobre la definición, aprobación y planificación del proyecto– Determinación del ciclo de vida del proyecto

• Comprobar que el proyecto se ha dimensionado según los procedimientos y normas establecidos.

• Comprobar que los riesgos asociados al proyecto han sido evaluados.

• Comprobar que se ha seleccionado un ciclo de vida de acuerdo con la naturaleza y particularidades del proyecto.

• Comprobar que se ha dimensionado utilizando la información histórica de la que se dispone.

• Comprobar que se han evaluado los riesgos utilizando la información del histórico.



• ...Sobre la definición, aprobación y planificación del proyecto– Plan del proyecto y equipo técnico.

• Comprobar que la elección del jefe de proyecto así como de los integrantes del equipo se ha realizado siguiendo los procedimientos establecidos.

• Comprobar que han sido solicitada la colaboración de otros departamentos o áreas según el procedimiento establecido.

• Comprobar que los perfiles profesionales de los integrantes del equipo tanto internos como externos son adecuados a su papel dentro del proyecto.

• Comprobar que ha sido comunicado a todos los integrantes del equipo:– Los objetivos del proyecto

– La responsabilidades individuales en el proyecto

– Las fechas y forma de participación en el proyecto

• Comprobar que el plan es realista y utiliza información basada en la historia de otros proyectos para realizar una estimación.



• Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Los responsables de las áreas afectadas han de participar en la

gestión del proyecto.• Comprobar que se ha constituido formalmente un comité de dirección

del proyecto.– Incluyendo a los responsables de todas las áreas afectadas.

• Comprobar la periodicidad de reunión del comité así como de las competencias del mismo.

– Las reuniones se deben de hacer con un orden del día previo.– Las decisiones que sean tomadas en el comité quedarán documentadas.– El número de reuniones debe venir marcado por la envergadura del

proyecto y siempre mantenerse dentro de unos límites razonables.



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Mecanismos para la resolución de incidencias.

• Comprobar la existencia de hojas de registro de incidencias– Persona encargada de su registro y recepción– Procedimientos de tramitación de la incidencia

• Comprobar los métodos de catalogación, prioridades y resolución de incidencias



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Control de cambios del proyecto

• Comprobar la existencia de un registro de control de cambios que se produzcan a lo largo de la vida del proyecto.

• Comprobar que con motivo de un cambio, la documentación se actualiza de manera adecuada.

– Control de versiones

– Fechas de actualización

• Comprobar que las nuevas versiones de documentación son debidamente difundidas.



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Reajustes al plan del proyecto

• Comprobar que los límites temporales se respetan.• Comprobar que los límites de presupuesto se respetan.• Comprobar que al realizar un reajuste se han tenido en cuenta

los riesgos del mismo.• Comprobar que se ha notificado el cambio• Comprobar que si existe un plan de sistemas, este ha sido

actualizado debidamente.



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Seguimiento de tiempos

• Comprobar que existe un procedimiento para registrar los tiempos empleados en las distintas tareas y fases del proyecto.

• Comprobar que la productividad de los distintos miembros del equipo es uniforme y se asemeja a los datos de la historia.



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Etapas del ciclo de vida

• Comprobar que antes de comenzar una nueva etapa se ha documentado la etapa previa en su totalidad.

• Comprobar que se respeta el plan establecido, o en caso contrario se han tomado las medidas oportunas.

• Comprobar que se hace uso de los recursos establecidos.



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Documentación

• Comprobar que la documentación cumple los estándares del área.



• ...Sobre la gestión del proyecto para lograr los objetivos en tiempo y forma– Finalización del proyecto

• Comprobar que la documentación del proyecto está completa y perfectamente catalogada.

• Comprobar que se ha hecho un balance del proyecto mediante actas de reunión entre el jefe del proyecto y el comité de dirección del proyecto.

• Comprobar que la nueva aplicación desarrollada es adjuntada al catalogo de aplicaciones existente en el área.



• Proceso de adquisición del software– Analizar la documentación a partir del estudio de viabilidad para

determinar que la decisión de adquirir una solución fue apropiada– Revisar el RFP (request for proposal) para asegurar que este cubre

los puntos enumerados en esta sección.– Determinar si el proveedor seleccionado está respaldado por la

documentación del RFP.– Revisar el contrato del vendedor antes de su firma para asegurarse

que incluye los puntos enumerados.– Asegurarse de que el contrato sea revisado por el asesor legal

antes de que sea firmado


Auditoría de la fase de análisis

• Objetivos de control– Sobre establecimiento de requisitos.– Sobre la búsqueda de la alternativa mas favorable.– Sobre las especificaciones funcionales



• Definición de los requisitos– Obtener el documento de definición detallada de requisitos y verificar si son correctos

por medio de entrevistas con los departamentos relevantes de usuario.– Identificar los miembros clave en el equipo de proyecto y verificar que todos los

grupos de usuarios afectados estén debidamente representados.– Verificar que los costos hayan recibido las aprobaciones pertinentes.– Revisar las especificaciones conceptuales del diseño.– Revisar el diseño conceptual para asegurar de que se hayan definido las

especificaciones de control.– Determinar si un número razonable de proveedores recibió la propuesta que cubra el

alcance del proyecto y los requerimientos de usuario.– Determinar si la aplicación es candidata para el uso de rutinas integradas de

auditoría.



• Sobre establecimiento de requisitos– Participación de usuarios

• Comprobar que existe un documento aprobado por el comité de dirección donde se especifica el grupo de usuarios que tomará parte en el proyecto.

• Comprobar que los usuarios seleccionados representan las distintas funcionalidades de las áreas afectadas por el proyecto.

• Comprobar que se ha comunicado su participación a los usuarios afectados en el proyecto.



• ...Sobre establecimiento de requisitos– Plan de entrevistas a usuarios

• Comprobar que existe un plan realizado junto con el comité de dirección de entrevistas que incluye:

– Fecha y hora

– Lugar

– Tipo de entrevista

» Individual

» En grupo

» Por escrito

– Temas a tratar

• Comprobar que se entrevista a todos los usuarios seleccionados así como a los responsables de las áreas afectadas.

• Comprobar que los guiones de entrevistas incluyen todas las cuestiones necesarias para obtener información de usuario.

• Comprobar que las entrevistas son debidamente documentadas.



• ...Sobre establecimiento de requisitos– Documentación de los problemas de los usuarios con el

sistema actual• Comprobar que ha sido realizado un modelo del sistema actual

con los objetivos y funciones de cada unidad, así como flujos de entrada y salida de información.

– Modelo lógico de datos

– Modelo lógico de procesos

• Comprobar que los problemas del sistema actual han sido catalogados.



• ...Sobre establecimiento de requisitos– Requisitos del nuevo sistema

• Comprobar que existe un catalogo de requisitos.– Que ha sido revisado y aprobado por el grupo de usuarios y el

comité de dirección.

• Comprobar la justificación de los requisitos.• Comprobar que los requisitos sean concretos y cuantificables de

manera que pueda ser evaluado el grado de cumplimento al final del proyecto.

• Comprobar que cada requisito tiene una prioridad.



• ...Sobre establecimiento de requisitos– Procedimientos de registro de cambios en los requisitos.

• Comprobar que existe un procedimiento de registro de cambios, y que está aprobado.

• Comprobar que el procedimiento es coherente con el procedimiento general de cambios del proyecto.



• Sobre la búsqueda de la alternativa mas favorable.– Diferentes alternativas de desarrollo

• Comprobar que existe un documento con las diferentes alternativas de desarrollo.

• Comprobar que existe más de una alternativa.– Si sólo existe una acompañarla de su argumento.

– Una de las alternativas ha de contemplar el desarrollo por una empresa externa.

– Otra alternativa ha de tener en cuenta los productos en el mercado que cubran los requisitos con una mínima garantía.



• ... Sobre la búsqueda de la alternativa mas favorable.– ... Diferentes alternativas de desarrollo

• Comprobar que cada alternativa está descrita desde un punto de vista coherente con los requisitos.

• Comprobar que ha sido evaluadas las distintas alternativas desde el punto de vista de sus ventajas e inconvenientes de manera objetiva

– Coste-beneficio– Riesgos

• Comprobar los argumentos de selección por parte del comité de dirección de una de las alternativas como la más ventajosa para la organización.



• Sobre las especificaciones funcionales– Construcción del modelo lógico del sistema

• Comprobar que el modelo parte del análisis de los requisitos.• Comprobar que existe un modelo lógico de procesos.

– Diferentes agentes externos con los que está relacionado el sistema.

– Flujo de entrada y salida de datos

» Frecuencia

» Contenido

» Donde se origina



• ...Sobre las especificaciones funcionales– ...Construcción del modelo lógico del sistema

• Comprobar que existe un modelo lógico de datos normalizado hasta al menos la tercera norma formal.

– Relaciones entre entidades

– Atributos

– Claves primarias

• Comprobar que el modelo de procesos es coherente con el modelo de datos.

• Comprobar la aprobación por parte de los usuarios y el comité de los dos modelos.



• ...Sobre las especificaciones funcionales– Diccionario de datos

• Comprobar que existe un diccionario de datos automático.• Comprobar que los cambios están reflejados en el diccionario de

datos.



• ...Sobre las especificaciones funcionales– Forma de interacción con los usuarios

• Comprobar que se han descrito las diferentes pantallas del sistema.

– Campos– Teclas de función– Menús y botones

• Comprobar que se han descrito los diferentes informes que se obtendrán.

• Verificar que se respetan las normas de estilo y diseño para las pantallas e informes.

• Comprobar que la interfaz de usuario ha sido aprobada por el grupo de usuarios y el comité de dirección.



• ...Sobre las especificaciones funcionales– Requisitos de seguridad del sistema

• Comprobar que se ha solicitado información acerca de los distintos aspectos de seguridad a los usuarios en las distintas entrevistas y que se han documentado debidamente.

– Copias de seguridad

– Recuperación

– Autenticación

– Nivel de confidencialidad de los datos

• Comprobar que los requisitos de seguridad han sido añadidos al catalogo de requisitos.



• ...Sobre las especificaciones funcionales– Pruebas de aceptación del sistema

• Comprobar que se ha elaborado un plan de pruebas y que este está en línea con los requisitos y funcionalidades del sistema.

• Comprobar que el plan de pruebas tiene en cuenta los recursos necesarios.


Auditoría de la fase de diseño

• Objetivos de control– Sobre la arquitectura física del sistema



• Sobre la arquitectura física del sistema– Descripción del entorno tecnológico

• Comprobar que están definidos todos los elementos del entorno tecnológico para el sistema.

– Servidores

– Periféricos

– Ordenadores personales

– Sistemas operativos

– Conexiones de red

– Protocolos de comunicación

– Sistemas de bases de datos

– Etc...

• Comprobar que todos los elementos se encuentran dentro de los estándares del Dpto.. de informática y responden a los requisitos del sistema.



• Sobre la arquitectura física del sistema– Identificación de las actividades físicas del

sistema en los distintos módulos.• Comprobar que todas las actividades físicas del sistema

han sido documentadas.– Que son coherentes con el modelo lógico de procesos.– Se ha identificado las comunes, así como aquellas que ya

existen en las librerías del área.

• Comprobar que existe un documento con la estructura modular del sistema realizado con una herramienta CASE apropiada.

• Comprobar el tamaño y acoplamiento entre los diferentes módulos del sistema.



• ...Sobre la arquitectura física del sistema– ...Identificación de las actividades físicas del sistema en

los distintos módulos.• Comprobar la reusabilidad de los módulos.

• Comprobar que los distintos módulos y componentes se han definido a partir de los módulos de procesos y datos del sistema.

– Sigue los estándares del área– La definición es correcta– La descripción de los componentes es suficiente para que un programador

los aplique sin tener conocimiento previo de ellos.

• Comprobar que se han definido las interfaces de datos y de control con otros módulos, así como la interfaz de usuario.



• ...Sobre la arquitectura física del sistema– Estructura física de datos

• Comprobar que el modelo físico de datos está basado en el modelo lógico de datos.

– Entidades– Campos– Relaciones– Claves– Vistas, etc...

• Comprobar que tiene en cuenta el entorno tecnológico, el volumen de datos y transacciones.

• Comprobar que si existe algún incumplimiento de las normas formales de diseño, este, está justificado.



• ...Sobre la arquitectura física del sistema– Plan de pruebas para los componentes del sistema

• Comprobar que existe el plan de pruebas.– Incluye las personas encargadas de las pruebas

» Personas distintas a las de desarrollo (segregación de funciones)

• Comprobar que el plan de pruebas es adecuado para validar cada uno de los componentes del sistema de manera individual y de manera conjunta.

– Teniendo en cuenta:» Condiciones lógicas de ejecución» Fallos de “hard” o “soft”


Auditoría de la fase de desarrollo

• Objetivos de control– Sobre las técnicas de programación– Sobre capacitación de los usuarios en el uso del sistema



• Diseño detallado y etapas de programación– Revisar los diagramas de flujo del sistema para verificar si se ajusta al diseño

general. Verificar que se hayan obtenido las debidas aprobaciones para cualquier cambio y que todos los cambios hayan sido discutidos y aprobados por la gerencia de usuario apropiada.

– Revisar los controles para el ingreso de los datos, del procesamiento y los resultados, diseñados en el sistema para verificar si son apropiados.

– Entrevistar a los usuarios claves del sistema para determinar su comprensión de cómo operará el sistema y determinar su nivel de participación en el diseño de los formatos de pantalla y reportes de salida.

– Evaluar si las pistas de auditoría son adecuadas para permitir que se rastreen y se evidencie la responsabilidad por las transacciones del sistema.



• ...Diseño detallado y etapas de programación– Verificar la integridad de los cálculos y procesos claves.– Verificar que el sistema pueda identificar y procesar los datos

erróneos correctamente– Revisar los resultados de aseguramiento de calidad de los

programas desarrollados durante esta etapa.– Verificar que se hayan efectuado todas las correcciones de los

errores de programación y que se hayan codificado las pistas de auditoría o los módulos integrados de auditoria recomendados, en los programas apropiados.



• Etapa de pruebas– Revisar el plan de pruebas para verificar si está completo y con evidencia

que indique la participación del usuario como por ejemplo en la definición de los escenarios de pruebas y/o la aprobación de los resultados obtenidos. Considerar una repetición de la ejecución de las pruebas críticas.

– Se debe efectuar una reconciliación de los totales de control y de los datos convertidos.

– Revisar los informes de errores para verificar su precisión para reconocer los datos erróneos y para la resolución de errores.

– Verificar el procesamiento cíclico para establecer si es correcto (procesamiento a fin de mes, fin de año, etc...)



• ...Etapa de pruebas– Entrevistar a los usuarios finales del sistema para verificar si entienden los

nuevos métodos, los nuevos procedimientos y las instrucciones de operación.

– Revisar, durante la fase de pruebas, la documentación del sistema y de los usuarios finales para determinar si está completa y verificar si es correcta.

– Revisar los resultados de las pruebas en paralelo para verificar si son correctos.

– Verificar que la seguridad del sistema este funcionando como se diseño mediante el desarrollo y ejecución de pruebas de acceso

– Revisar los planes de las pruebas de unidad y del sistema para determinar si se planifican y realizan pruebas de los controles internos.



• Sobre las técnicas de programación– Preparación del entorno de desarrollo y pruebas

• Comprobar que se han creado las bases de datos y ficheros necesarios y que coinciden con las especificaciones del diseño.

• Comprobar que no se trabaja contra información de producción.

• Comprobar que se han preparado los procedimientos de copia de seguridad para los fuentes y documentos del proyecto.

• Comprobar que están disponibles los equipos de pruebas de componentes e integración.

• Comprobar que se documentan todos los procedimientos de la operativa para cuando el sistema entre en producción.



• ...Sobre las técnicas de programación– Programación, pruebas y documentación de los componentes del

sistema.• Comprobar que se han desarrollado todos los componentes o módulos

del sistema.

• Comprobar que se han seguido los estándares de programación, estructura y documentación en código.

• Comprobar que se ha realizado la prueba de cada componente y el informe de la misma.



• ...Sobre las técnicas de programación– Pruebas de integración

• Comprobar que las pruebas de integración se han llevado a cabo según las especificaciones del plan de pruebas.

• Comprobar que se han evaluado las pruebas y que se han tomado las acciones correctoras necesarias en las incidencias encontradas.

• Comprobar que no han participado usuarios en las pruebas de integración.



• Sobre capacitación de los usuarios en el uso del sistema– Perfiles de usuario para el nuevo sistema

• Comprobar que están definidos los distintos perfiles de usuario requeridos para la explotación del sistema.

– Incluye una definición acerca de la dedicación requerida, así como de las fechas.



• ... Sobre capacitación de los usuarios en el uso del sistema– Procedimientos de usuario.

• Comprobar el desarrollo de los distintos componentes de usuario, así como su coincidencia con las funciones descritas en el diseño.

• Comprobar que cada componente describe el perfil de usuario asociado, así como las funcionalidades a las que da solución y recursos necesarios

• Comprobar que los manuales de usuario cumplen los estándares del área.



• ... Sobre capacitación de los usuarios en el uso del sistema– Procesos de formación y selección de usuarios

• Comprobar que los perfiles de usuarios y recursos requeridos es realista con respecto a los usuarios actuales.

• Comprobar que los procedimientos derivados son adecuados y están debidamente aprobados por los responsables de las áreas afectadas.

• Comprobar que se han definido y preparado los recursos necesarios para la formación de los usuarios.



• ... Sobre capacitación de los usuarios en el uso del sistema– Recursos necesarios para el trabajo de los usuarios.

• Comprobar que se han determinado los recursos necesarios para los distintos usuarios.

– Periféricos

– Consumibles, etc.

• Comprobar que se ha planificado la adquisición de los recursos necesarios no disponibles dentro del plazo de implantación del proyecto.


Auditoría de la fase de implantación

• Objetivos de control– Sobre la aceptación del sistema por los usuarios.– Sobre el paso a producción y mantenimiento del sistema.



• Etapa de implantación– Se inicia únicamente en caso de que se haya pasado con éxito la fase de pruebas. El

sistema debe de estar instalado en conformidad con los procedimientos de control de cambios de la organización. El auditor de SI debe verificar que se hayan obtenido las firmas de aprobación apropiadas antes de la implementación.

– Revisar los procedimientos planificados y usados para programar y poner en funcionamiento el sistema junto con los parámetros del sistema usados para la ejecución del cronograma de producción.

– Revisar toda la documentación del sistema para asegurar que está completa y para asegurarse de que la totalidad de las actuaciones recientes, a partir de la fase de pruebas, hayan sido incorporadas.

– Verificar todas las conversiones de datos para asegurarse de que estén correctas y completas antes de implantar el sistema en producción.



• Sobre la aceptación del sistema por los usuarios.– Situación final del proyecto y plan de implantación

• Comprobar que se revisa el plan de implantación inicial y que se documentan los cambios debidamente.

• Comprobar que está incluida la instalación de todos los componentes desarrollados, así como:

– Librerías– Utilidades, etc.

• Comprobar que el plan incluye la inicialización o migración de datos.

• Comprobar que son especificados los recursos necesarios para las distintas actividades de implantación, así como el orden de las mismas.

• Comprobar que ha sido tenido en cuenta la información proveniente del histórico para realizar las estimaciones.



• ... Sobre la aceptación del sistema por los usuarios.– Aceptación de los usuarios antes del paso a producción

• Comprobar que se sigue el plan de pruebas de aceptación aprobado en la fase de análisis.

• Comprobar que las pruebas de aceptación son llevadas a cabo por los usuarios.

• Comprobar que se evalúan los resultados de las pruebas de aceptación, y se toman las medidas correctoras necesarias.

• Comprobar que tanto el grupo de usuarios como el comité de dirección firman su conformidad con las pruebas de aceptación.



• Sobre el paso a producción y mantenimiento del sistema.– Instalación de todos los procedimientos necesarios para la

producción.• Comprobar que además del sistema principal, han sido instalados los

procedimientos auxiliares como copias de seguridad y recuperación.

• Comprobar que la instalación se encuentra documentada de manera correcta.

• Comprobar que los usuarios han recibido la formación necesaria y tienen en su poder la documentación necesaria.

• Comprobar que han sido eliminados otros procedimientos ya implantados que sean incompatibles con el nuevo sistema.



• ...Sobre el paso a producción y mantenimiento del sistema.– Coordinación y migración de datos del sistema sustituido.

• Comprobar que existe un periodo de funcionamiento en paralelo de los dos sistemas.

• Comprobar que el sistema antiguo está en modo consulta si este va ha ser mantenido por motivos de consulta.

• Comprobar que los datos son migrados de acuerdo al procedimiento de migración descrito.

– Se comprueba la consistencia de la información entre el sistema nuevo y el antiguo



• ...Sobre el paso a producción y mantenimiento del sistema.– Fin de implantación

• Comprobar la existencia del documento de aceptación de la implantación, por parte de los usuarios y el comité de dirección, con las debidas rúbricas.



• ...Sobre el paso a producción y mantenimiento del sistema.– Supervisión del trabajo en la entrada a producción.

• Comprobar que se supervisa el uso del sistema durante las primeras semanas.

– Comprobar que el índice de uso es el correcto.

• Comprobar las impresiones de los usuarios acerca del nuevo sistema.



• ...Sobre el paso a producción y mantenimiento del sistema.– Mantenimiento del sistema

• Comprobar que los procedimientos de mantenimiento existen y que están aprobados por el comité de dirección del proyecto y el área de mantenimiento.

• Comprobar que tiene en cuenta los tiempos de respuesta máximos que pueden permitirse ante diferentes situaciones.

• Comprobar que los procedimientos a seguir en caso de incidencia o mantenimiento son conocidos por todos los usuarios del sistema.

– Persona de contacto, teléfono– Información a aportar, etc.



• Revisión posterior a la implantación– Después de que el nuevo sistema se haya estabilizado en el entorno de producción,

se debe efectuar una revisión posterior a la implementación. Antes de esta revisión es importante que se de tiempo suficiente para que el sistema se estabilice en producción. De este modo habrá oportunidad para que aparezca cualquier problema significativo.

– Determinar si se lograron los objetivos y requerimientos del sistema. Durante la revisión posterior a la implementación, se debe prestar mucha atención a la utilización que hace el usuario del sistema y la satisfacción general de este con el sistema. Esto indicará si se lograron los objetivos y requerimientos del sistema.

– Determinar si se están midiendo y analizando el costo-beneficio identificado en el estudio de factibilidad y si los mismos son reportados a la gerencia con exactitud.



• Revisión posterior a la implantación– Revisar las solicitudes de cambio a programas para evaluar el tipo de cambios que

requiere el sistema. El tipo de cambios solicitado puede indicar problemas en el diseño, en la programación o en la interpretación de los requerimientos del usuario.

– Revisar los controles integrados en el sistema para asegurarse que los mismos estén operando en conformidad con el diseño. Si se incluyo un módulo de integrado de auditoría en el sistema, usar este módulo para probar las operaciones claves.

– Revisar los registros de error de operación para determinar si hay algún problema de recursos o de operación inherente en el sistema. Los registros pueden indicar una planificación o pruebas inapropiadas del sistema antes de su implementación.

– Revisar los balances / cuadres de control de entrada y salida y demás reportes para verificar que el sistema este procesando los datos correctamente.


Muchas GraciasHermenegildo Romero

Database Team

[email protected]

www.db-team.com

desarrollo de sistemas

Documents