Archivo

Archive for the ‘Auditoria de Sistemas’ Category

Auditoría de proyectos de tecnología. Parte 7. Medición de Resultados.

octubre 20, 2010 1 comentario

Objetivo.

El objetivo en esta parte es buscar anomalías en la forma en la que el equipo del proyecto mide el logro de resultados en cuanto a aceptación de entregables y otros aplicado al proyecto. Te recomiendo buscar la falta de procesos de aprobación.

Detalle.

  1. Determinar si existio  aprobación del usuario a los resultados de las pruebas finales.
    1. Se han establecido estándares para la aceptación de las pruebas finales? Es decir, los usuarios tienen claramente definido que es lo aceptable y que no?
    2. El área de usuarios y su gerencia han revisado el desempeño del sistema y aprobado los resultados?
    3. El área de usuarios ha identificado alguna ineficiencia en el sistema?
    4. Puede este ineficiencia ser corregida? Si es así; será corregida antes de la implementación del sistema?
  2. Revisar los resultados de las pruebas finales y determinar si existen resultados no esperados. Te recuerdo que en el anterior punto, ya revisamos que exista documentación adecuada al respecto.
    1. Determinar si los resultados no esperados de las pruebas han sido adecuadamente evaluados para determinar las razones de las variaciones.
  3. Determinar si existe o existió un adecuado seguimiento a los resultados no esperados.
    1. Se realizaron las correcciones?
    2. Se realizaron nuevas pruebas después de las correcciones?
  4. Has una revisión minuciosa de esos resultados no esperados e identifica aquellos que puedas considerar críticos, trabaja sobre estos en detalle y asegúrate que la entidad los haya resuelto adecuadamente y en su totalidad.

Como te darás cuenta conceptualmente esta parte es muy breve, sin embargo es muy importante, y los resultados de ella son de gran valor en la presentación del reporte de auditoría. La gerencia de la entidad te lo agradecerá.

Comentanos cómo te fue, te recuerdo que esta guía no es la Biblia, y puede ser mejorada con la ayuda de tu profesionalismo.

Saludos,

Álvaro Cuadros

Anuncios

Auditoría de proyectos de tecnología. Parte 6. Pruebas

octubre 11, 2010 Deja un comentario

 

Bien, ya hemos avanzado un 60% en nuestra evaluación de proyectos de tecnología, y ahora nos toca buscar anomalías o la falta de un marco de trabajo adecuado para las pruebas en el proyecto. Buscaremos procesos faltantes en la etapa de pruebas.

Vamos con nuestro checklist.

  1. Determina si han sido preparados datos de prueba y verifica si éstos incluyen todas los posibles condiciones incluidos los errores.
    1. Han sido preparados scripts de prueba?
    2. Han sido definidos archivos de pruebas
    3. se tienen pasos detallados para la realización de las pruebas
  2. determina si existen procesos desarrollados para evaluar los resultados de las pruebas.
    1. Tenemos resultados predeterminados para poder realizar las comparaciones necesarias?
    2. Existe un esquema de resolución de problemas?
    3. Existe un registro detallado respecto a los problemas que se fueron presentando las pruebas?
    4. Los usuarios están incluidos en las pruebas y en las evaluaciones de los resultados?
  3. Determina si los resultados esperados de las pruebas han sido definidos con anterioridad a las pruebas en sí.
    1. Los scripts de prueba deben incluir todos los resultados esperados.
    2. Existen procedimientos definidos para monitorear los resultados de las pruebas?
  4. Determina existe un procedimiento de resolución de los problemas diseñados para aquellas pruebas que no logren los resultados esperados.

Finalmente, debe determinar si existe un registro detallado y que además es revisado adecuadamente de los resultados de la prueba que pueden ser considerados como inesperados, en este grupo podrás encontrar por ejemplo la generación de buffer overflows, punteros al vacío y otros, que suelen ser ignorados porque se presentaron en alguna prueba y nunca más se repitieron.

Categorías:Auditoria de Sistemas

Auditoria de proyectos de tecnología. Parte 5

octubre 4, 2010 3 comentarios

 

 

En esta nuestra nueva entrega sobre metodología para la auditoría de proyectos de tecnología revisaremos la etapa conocida como:

 

Plan de pruebas

 

Esta etapa si bien es sencilla, es fundamental en la auditoría del proyecto pues nos revelará si se ha creado una estructura ordenada para realizar las pruebas del software o elemento de tecnología. Qué es lo que debemos buscar?

 

  1. El equipo del proyecto ha desarrollado un plan de pruebas
    1. el plan de pruebas está escrito?
    2. Considera pruebas del sistema y aceptación?
    3. Los usuarios finales están incluidos en las pruebas?

       

  2. Determinar si todos los aspectos del sistema van a ser probados tal como están definidos en el detalle de requerimientos, esto incluye, pero no se limita a:
    1. entrada de datos
    2. edición
    3. reportes
    4. cálculos realizados dentro aplicación
    5. reporte de errores
    6. interfases con otros sistemas
    7. comunicaciones de red
    8. todas las funciones críticas

       

  3. determinar cuándo se realizarán las pruebas y asegurarse que las pruebas serán concluidas todas de manera exitosa previa a la implementación, por lo cual debemos verificar si el plan permite nuevas pruebas de errores que se generan así como también de cambios realizados en el sistema. En general, te recomiendo tener mucho cuidado en la verificación de que los cambios que se hagan en el sistema sean probados adecuadamente.

     

  4. Determinar si una prueba en paralelo será realizada.

     

     

  5. Determinar si se realizaran pruebas que contemplen el final de periodos específicos es decir finales de mes finales de semestre y finales de año.

     

  6. Determinar si se realizaran pruebas de estrés
    1. una prueba de estrés adecuada deberá tener dos escenarios: un escenario normal de procesamiento y un escenario de alto volumen de transacción, impresión, etcétera.
    2. Durante esta prueba de estrés también se debe probar los tiempos de respuesta del sistema en estas situaciones específicas.

       

En la parte seis de nuestra entrega entraremos en detalle a identificar los aspectos de las pruebas en sí.

 

Saludos,

 

Álvaro cuadros

Categorías:Auditoria de Sistemas

Auditoria de proyectos de tecnología. Parte 4

octubre 1, 2010 Deja un comentario

En esta parte de nuestra revisión de una metodología para realizar auditorías de proyectos de tecnología veremos la fase de:

 

Capacitación

El objetivo es buscar anomalías por la falta de entrenamiento en el proyecto. No olvidemos que muchas veces cuando el proyecto se retrasa por razones de falencias dentro del desarrollo mismo del proyecto, las áreas que sufren las consecuencias más duramente son las áreas de seguridad, por tener tiempos extremadamente restringidos para hacer sus evaluaciones y las áreas de usuarios finales que se capacitan muy brevemente y de manera inadecuada.

 

Pruebas: determinar si

 

  1. Un plan de capacitación ha sido desarrollado y se encuentra apropiadamente documentado

     

  2. El plan de capacitación y entrenamiento contiene capacitación relativa a
    1. Entrada de datos
    2. Respaldos del sistema
    3. Operaciones de usuarios
    4. Reconciliación.

       

  3. El entrenamiento será completado antes de la implementación del sistema?
    1. El personal crítico será entrenado con la suficiente anticipación?
    2. Habrá un equipo que será entrenado para que a su vez entrene al resto de los usuarios?
    3. El manejo de las cuentas de usuarios se hace en un ambiente específico para el entrenamiento y capacitación y que está separado del de producción?

       

  4. Ha sido claramente definida la audiencia asistente a la capacitación y entrenamiento?
    1. Hay diferentes niveles de entrenamiento de acuerdo a las responsabilidades y roles dentro del sistema (Gerentes, Front Office, etc….)?
    2. Habrá algún método de evaluación al final del periodo de capacitación de manera que los usuarios puedan probar que tienen la competencia adecuada para operar el nuevo sistema?
    3. Habrá algún método de evaluación del equipo de capacitación y entrenamiento?
    4. Hay un procedimiento que nos asegura que los futuros nuevos usuarios serán entrenados adecuadamente?

 

Alvaro Cuadros

Categorías:Auditoria de Sistemas

Auditoria de Proyectos de Tecnología . Parte 3

septiembre 27, 2010 1 comentario

Etapa: Diseño

Objetivo: buscar anomalías o la carencia de prácticas adecuadas para el diseño de sistemas. Usualmente un diseño pobre puede llevar un producto o servicio pobre e incluso inservible. Busca la falta de detalle en los requerimientos, criterios de aceptación, regulaciones y procesos.

Qué buscar:

  • Determinar si el diseño del sistema está amplia y adecuadamente documentado.

o   Se ha hecho un análisis de todas las interfaces con otros sistemas  que necesitará el nuevo sistema?

o   Si el diseño está realizado para un reemplazo total de un sistema existente tenemos una documentación clara y suficiente del antiguo sistema?

o   Están las especificaciones debidamente documentadas? Revisar:

§   Archivos de datos

§  Interfaces.

§  Reportes.

§  Procedimientos

§  Infraestructura.

  • Verifique que se encuentren todas las cuentas necesarias así como productos y servicios documentados.
  • Determine si ha sido desarrollado un documento detallado de los requerimientos usuario.
  • Determine la precisión y exactitud de las fórmulas que se usan dentro del sistema.
  • Están claramente detalladas las especificaciones del reporte así como su frecuencia?
  • El tiempo de respuesta del sistema está incluido en el diseño
  • Los requerimientos de seguridad, que deben ir en línea con la política de seguridad han sido claramente documentados?
  • El ambiente de operación del nuevo sistema ha sido documentado.

Saludos

ACS

Auditoria de proyectos de Tecnología (Parte 2)

septiembre 22, 2010 1 comentario

Evaluación de factibilidad

Objetivo: El objetivo es buscar anomalías en la continuidad del proyecto  el proyecto o las malas decisiones tomadas en esta fase del proyecto o programa. Busca los pasos que indican procesos de aprobación pobres o la falta de gobernabilidad

Que buscar:

  1. Determinar si un estudio de viabilidad del proyecto ha sido redactado y aprobado por la administración  y el departamento de sistemas.
    • El estudio de detalla claramente el ámbito del proyecto?
    • Hay un plan de gestión de los proyectos incluidos
    • Tiene un presupuesto detallado del proyecto incluido?
    • El presupuesto parece realista? (Y cuanto está asignado para contingencias?
    • El nivel adecuado de gerencia ha revisado y aprobado el estudio?
    • ¿Qué disposiciones se han tomado para casos de retrasos y cambios imprevistos? (OJO. Acá es fundamental la revisión del Plan de Riesgos)
    • Determine si el equipo del proyecto ha establecido un plan de proyecto.
  • – ¿El plan está escrito?
  • – ¿Los plazos son realistas?
  • – ¿Son las fases críticas determinadas?
  • – ¿El plan exige que la gerencia y usuarios finales autoricen continuar  con el proyecto en puntos específicos?
  • – ¿El proyecto puede ser cancelado por razones especificas?
  • – ¿El plan planteaba riesgos clave en el proyecto?  Las estrategias de reducción del riesgo existen  y hay un proceso en curso para actualizar y revisar el registro de riesgos?
  • Determine si el plan del proyecto incluye todas las fases que requiere un proyecto iniciación, desarrollo, pruebas, capacitación, reconversión, y la implementación
    – ¿Cubre todas las aplicaciones y áreas involucradas?
    – ¿Cubre todos los fabricantes o proveedores?
    – ¿Cubre todas las interfaces hacia y desde la aplicación? (OJO)
    – ¿Todas las personas involucradas en el proyecto entienden su nivel de participación, funciones y responsabilidades?
    – ¿Cubre hardware y software upgrades, supresiones o cambios?
  • Determine si el plan de proyecto fue seguido y algunas desviaciones documentadas, incluyendo extensiones del horario o atrasos inesperados.
    ¿- Está todas las desviaciones documentadas?
    ¿- Todas las extensiones y atrasos son aprobados por el equipo de proyecto y gerencia?
    ¿- Está todas las partes pertinentes notificadas de cualquier extensión o cambio en el  proyecto?
  • Determine si la propuesta /contrato comercial para el sistema incluyó toda información pertinente:
    – Las justificaciones para el proyecto
    – El alcance del proyecto
    – Las restricciones del proyecto (ver aspectos financieros, el humano, y el software)
  • Costos y beneficios del proyecto
    1. Planes y cronogramas detallados
    2. Requerimientos de usuario
    3. Expansión, crecimiento y escalabilidad. Este último factor frecuentemente es ignorado, sin embargo, el hacerlo implica costos elevados a futuro.

Auditoria de Proyectos de Tecnología (Parte 1)

septiembre 20, 2010 Deja un comentario

Para poder realizar una auditoría de proyectos es fundamental seguir las fases del proyecto así como los entregables de cada fase. Dependiendo la metodología existen muchas variaciones del ciclo de vida, sin embargo para simplificar nuestra auditoria diremos que fundamentalmente son:

  1. Iniciación
  2. Planeación
  3. Ejecución
  4. Control
  5. Cierre

Cuando audites un proyecto es vital que recabes toda la información posible y te entrevistes con el Jefe del Proyecto.

NOTA IMPORTANTE. Nunca pierdas de vista que un proyecto siempre es desarrollado para dar algún beneficio claro a la organización y este beneficio debe por supuesto ser mayor que el costo de desarrollar el proyecto, por lo que, mas allá de seguir en detalle los pasos que acá describiremos, debes tener en cuenta que esta condición se cumpla. Paso 1. Generalidades Objetivo: Detectar anomalías o la falta de enfoque o marco de trabajo del proyecto. Detectar procesos faltantes en el ciclo de vida del software (SDLC). Actividades: a)      Determinar si el proyecto ha establecido un equipo bien definido, que incluya un líder del área de Sistemas (producción).

  • Existe un comité de alto nivel que maneja el proyecto? Quien es el sponsor del proyecto?
  • El nivel ejecutivo adecuado está incluido en el proyecto?
  • El equipo del proyecto tiene la autoridad necesaria para la toma de decisiones concernientes al proyecto?
  • El equipo del proyecto tiene la experiencia suficiente, técnica y de negocio, para llevar adelante el proyecto? (Te aconsejo una revisión aleatoria de CVs)
  • En particular tienen experiencia con el software y tecnología utilizada en el proyecto?
  • El proyecto incluye miembros de las áreas usuario? , incluye desarrolladores, abogados, y personal de Seguridad de Sistemas o Riesgo Tecnológico?
  • Existe una metodología claramente definida y documentada usada en el proyecto?
  • Se ha generado una CLARA justificación de negocio y ha sido esta aprobada por la alta gerencia?
  • Esta justificación incluye documentación detallada de los beneficios que se esperan? (Esto te será muy útil, pues es la base para que puedas evaluar el ROI del proyecto).

ACS

Categorías:Auditoria de Sistemas Etiquetas: ,