Revisión del ciclo de vida del desarrollo de Aplicaciones, adquisición o mantenimiento.

El Objetivo de esta revisión es identificar, analizar y evaluar los requerimientos del usuario, riesgos, exposiciones a ellos y los controles en aplicaciones específicas durante la fase de desarrollo, adquisición o mantenimiento de las aplicaciones. Las tareas del auditor de sistemas incluyen las siguientes:

Determinar los componentes, objetivos y requerimientos principales de los usuarios de la aplicación e identificar las áreas que exigen controles al hacer entrevistas con miembros claves del proyecto.

Determinar y clasificar los principales riesgos y exposición a riesgos de la aplicación, para permitir controles por medio de discusiones con miembros del equipo del proyecto.

Identificar los controles para minimizar los riesgos y exposiciones a riesgos de la aplicación por referencia a fuentes confiables y por medio de discusiones con miembros del equipo del proyecto.

Asesorar al equipo del proyecto respecto del diseño de la aplicación y la implantación de controles al evaluar los controles disponibles y al participar en discusiones con miembros del equipo del proyecto.

Monitorear el proceso de desarrollo, mantenimiento o adquisición de las aplicaciones para asegurarse de que se implantan los controles, se satisfacen los requerimientos de los usuarios y se sigue la metodología mas adecuada en cada caso, esto permite asegurarse que las aplicaciones son eficaces y eficientes, al realizar reuniones periódicas con miembros del equipo del proyecto y al hacer exámenes de la documentación y los productos en sus diversas etapas.

a. Revisión de desarrollo de sistemas.

Cuando se revisa el proceso de desarrollo de sistemas, se espera que el auditor de sistemas obtenga la documentación necesaria y disponible de las diversas fases así como que asista a las reuniones del equipo del proyecto ofreciendo asesoramiento durante todo el proyecto de desarrollo de sistemas. También, el auditor de sistemas debe evaluar la capacidad de los equipos del proyecto para producir los productos claves a entregar para las fechas prometidas. Durante todo el proceso de desarrollo de sistemas el auditor de sistemas debe analizar los riesgos asociados y las exposiciones que son inherentes en cada fase y asegurarse de que los mecanismos de control adecuados están vigentes para minimizar esos riesgos y una forma que sea eficaz en cuanto a costos. Debe utilizarse el tino para recomendar controles que no cuesten mas administrarlos que los riesgos que deben minimizar.

1. Estudio de Factibilidad . El auditor de sistemas debe revisar la documentación producida en esta fase y corroborar su razonabilidad. Debe verificarse todas las justificaciones de costo / beneficio junto con el cronograma de cuando se anticipaba que se realizarían los beneficios. Identificar si la necesidad del negocio que se utiliza para justificar el sistema, realmente existe, y hasta que punto existe la necesidad. Determinar si puede obtenerse una solución con los sistemas vigentes. De no ser así corroborar la razonabilidad de la evaluación de las soluciones alternativas. Determinar si finalmente se eligió la solución mas apropiada.

2. Definición de requerimientos . El auditor de sistemas debe obtener el documento de definición de requerimientos detallados y verificar su exactitud por medio de entrevistas con los departamentos usuarios que lo solicitan. Identificar los miembros clave del equipo del proyecto y verifique que todos los grupos usuarios afectados tienen una adecuada representación. Verificar que la gerencia aprobó la iniciación del proyecto y el costo del proyecto. Revisar los diagramas de flujo de datos y el diseño conceptual para asegurarse de que se trata las necesidades del usuario. Revisar el diseño conceptual por el nivel adecuado del control. Revisar las propuestas dadas a los proveedores para asegurarse de que cubren el verdadero alcance del proyecto y los requerimientos de los usuarios. Determinar si esta aplicación es apropiada para el uso de una rutina de auditoría incorporada. De ser así incorpore la rutina en el diseño conceptual del sistema.

3. Fase de diseño detallado y programación . Revisar los flujogramas del sistema para observar el seguimiento del diseño general, si se observan cambios, verifiquen que fueron dadas sus aprobaciones apropiadas para los cambios y que los cambios han sido discutidos y aprobados por los grupos de usuarios afectados. Revisar los controles de entrada y salida diseñados dentro del sistema, para comprobar que sean apropiados. Entrevistar a los usuarios clave del sistema para comprobar su comprensión de cómo operará el sistema y evaluar su nivel de entrada en el diseño de los formatos de pantalla y los informes de salida. Evaluar los rastros de auditoría que se programan, en el sistema para rastrear la información fuente clave. Verificar la corrección de los cálculos de los procesos claves. Verificar que el sistema puede identificar y procesar correctamente datos erróneos. Verificar que los procesos de prueba de los programas sean desarrollados durante esta fase. Verificar que se hicieron las correcciones recomendadas para los errores de programación y que las pistas de auditoría recomendados o los módulos de auditoría fueron incorporadas en los programas correctos.

4. Fase de Prueba . La fase de prueba es crucial para determinar que los requerimientos han sido satisfechos y que el sistema se comporta como se anticipaba. Por ende el auditor de sistemas debe participar en forma intensa y revisar la fase. Examinar el plan de prueba, para verificar que sea completo con la evidencia indicada de la participación del usuario, tal como escenario de situaciones de prueba creados por los usuarios y/o aprobación escrita de aceptación de los resultados. Revisar todos los resultados de pruebas en paralelo para comprobar su exactitud. Verificar que la seguridad este funcionando adecuadamente, probando intentos de acceso no permitidos. Examinar comprobando la precisión de los mensajes de error para reconocer los datos erróneos y la resolución de estos errores.

5. Implantación. Esta fase se inicia solo después de una exitosa fase de prueba. Debe tenerse precaución al transferir un nuevo sistema a situación de producción. El auditor de sistemas debe verificar que las aprobaciones necesarias existen antes de implementar el nuevo sistema. Revisar los procedimientos programados que se utilizan para hacer el cronograma y correr el sistema junto con los parámetros del sistema que se utilizan al ejecutar el cronograma de actividades. Revisar la documentación del sistema a fin de asegurarse de que esta completo y que todas las actualizaciones posteriores a la fase de prueba han sido incorporadas. Verificar toda la conversión de datos para asegurarse de que es correcta y esta completa antes de implementar en producción al nuevo sistema.

6. Fase de Post-Implantación. Luego que el nuevo sistema ha estado operando, por lo menos seis meses, el auditor de sistemas independiente de las otras fases de la vida del sistema, revisará lo siguiente: Determinar si el programa ha logrado los requerimientos de los objetivos, se debe prestar especial atención a la utilización y la satisfacción de los usuarios finales, ellos constituirán un indicador excelente. Verificar que se miden, analizan e informan adecuadamente a la gerencia los beneficios identificados con el estudio de factibilidad. Revisar las solicitudes de cambios a los programas que se han realizado, para evaluar el tipo de cambios que se exigen al sistema, el tipo de cambios puede indicar problemas de diseño, programación o interpretación de los requerimientos de usuario.

b. Revisión de aplicaciones de software comprado.

Para tomar la decisión de comprar el producto de un vendedor en lugar de crear una solución interna, debe existir en el estudio de factibilidad, documentación sobre la decisión de "hacer vs. Comprar", esta documentación debe ser analizada para determinar si la decisión de comprar fue apropiada. y considerar lo siguiente respecto a los proveedores: Estabilidad financiera. Número de años de experiencia ofreciendo el producto. Número de sedes de clientes que usen el servicio. Compromiso de servicio. Compromiso de desarrollar o mejorar el producto. Nivel de satisfacción de otros clientes, si es posible visitar sus instalaciones y ver como se utiliza en un ambiente real de producción. Compromiso para la provisión de entrenamiento, documentación y upgrades a los productos. Aceptación de pruebas de productos antes de la compra. Adicionalmente el auditor de sistemas deberá revisar el contrato en los siguientes puntos: Descripción específica de los productos a entregar. Compromisos sobre fechas de entrega de los productos. Compromiso de entrega de los upgrades y entrenamiento. Entregas de licencias y permisos para copiar el software para utilizarlo en esfuerzos de recuperación de desastres.

c. Revisión del Mantenimiento de aplicaciones.

El objetivo de esta revisión es identificar, analizar y evaluar normas, tareas, procedimientos y controles en el proceso de control de cambios a los programas. Las tareas de auditoría en este aspecto son:

Evaluar los estándares y procedimientos para cambios a programas para asegurar su adecuación por medio de examen de la correspondiente documentación, discusiones con personal clave y observaciones.

Probar los procedimientos de control de cambios para asegurar que se explican según se describe en los estándares por medio de discusión y examen de los registros respaldatorios.

Evaluar el proceso de control de cambios para determinar que los objetivos de control fueron cumplidos al analizar los resultados de pruebas y otra evidencia de auditoría.

Determinar la adecuación de la seguridad de la biblioteca de producción para asegurar la integridad de los recursos de producción al identificar y probar controles existentes.

Desde que un sistema es puesto en funcionamiento, se practican cambios, los cuales deben tener en cuenta una metodología para realizar y registrar estos cambios, esta metodología debe incluir:

Procedimientos para autorización de los cambios a los programas de producción. Documentación de programas, las solicitudes de cambio deben ser archivadas con la documentación del programa afectado y debe incluirse la documentación de la razón del cambio (análisis del costo / beneficio) si es necesario.

Rastros de auditoría de cambios, siempre debe llevarse un rastro de auditoría de todos los cambios o manejo de versiones de los programas, esto generalmente lo posee el software de manejo de bibliotecas.

Concordancia del código fuente y el ejecutable, se refiere a que si un programa fuente es compilado nuevamente, el programa ejecutable resultante es igual al programa que esta en producción.

Controles de acceso a los programas de producción, debe existir un riguroso control de acceso a los programas de producción, estos controles generalmente son manejados por el software de acceso al mainframe.  

LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO

¿QUIÉN ESTÁ INVOLUCRADO EN LA CONSTRUCCIÓN DE SISTEMAS?

Los especialistas en sistemas aportarán sus conocimientos específicos orientados a la coordinación y planeación de sistemas, la determinación de los requerimientos y los procedimientos para encontrar buenas soluciones a los problemas organizacionales, así como la responsabilidad técnica sobre el nuevo sistema

¿CÓMO SE ADMINISTRA EL DESARROLLO DE SISTEMAS?

El diseño y desarrollo de un sistema, así como el mantenimiento mayor, debe manejarse como un verdadero proyecto; como tal deben establecerse los procedimientos y medios para lograrlo. Los aspectos que deben ser tomados en cuenta, entre otros, son:

&#61510Definición del grupo de trabajo (Comité de Usuarios)  Designación del Administrador del Proyecto (Representante de la Alta Dirección)  Establecimiento de las actividades a realizar, en detalle  Definición del cronograma de actividades

¿DE DÓNDE PROVIENEN LA IDEA DE LOS SISTEMAS?

El estudio de los sistemas de información se originó como una sub-disciplina de las ciencias de la computación en un intento por entender y racionalizar la administración de la tecnología dentro de las organizaciones. Los sistemas de información han madurado hasta convertirse en un campo de estudios superiores dentro de la administración. La idea fundamentalmente proviene de:

 La necesidad del usuario de una herramienta que le facilite el acceso a la información. La necesidad del administrador para el control de sus recursos.  La necesidad del auditor para llevar a cabo su función de asesoría o consultoría para ver si la administración ha sido eficiente. La necesidad de terceras partes (clientes, proveedores, entidades gubernamentales, entidades financieras etc.)

PANORAMA DEL DESARROLLO DE LOS SISTEMAS

Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso

En la mayor parte de las situaciones dentro de una empresa todas las actividades están muy relacionadas, en general son inseparables, y quizá sea difícil determinar el orden de los pasos que se siguen para efectuarlas.

Las diversas partes del proyecto pueden encontrarse al mismo tiempo en distintas fases de desarrollo; algunos componentes en la fase de análisis, mientras que otros, en etapas avanzadas de diseño.

Las actividades típicas del ciclo de vida son:

1- Estudio de factibilidad.

2- Análisis (de requerimientos).

3- Diseño

4- Implementación

5- Validación y prueba

6 - Operación y mantenimiento

OBJETIVOS DE UN CICLO DE VIDA DE LOS SISTEMAS DE INFORMACION

 Definir las actividades a llevarse a cabo en el desarrollo Lograr congruencia entre los proyectos de desarrollo al interior y exterior de la organización Proporcionar puntos de control y revisión administrativos Organizar las actividades de manera lógica Controlar la calidad del sistema

1. ESTUDIO DE FACTIBILIDAD

Un resultado importante de la investigación preliminar es la determinación de que el sistema solicitado sea factible. En la investigación preliminar existen tres aspectos relacionados con el estudio de factibilidad.

1. Factibilidad Técnica. El trabajo para el proyecto, ¿puede realizarse en el equipo actual, la tecnología existente del software y el personal disponible? Si se necesita nueva tecnología ¿cuál es la posibilidad de desarrollarla?

2. Factibilidad Económica. Que los beneficios (tangibles e intangibles) y horros superen a los costos; que los índices financieros que se calculen sean aceptables, de acuerdo con políticas y estándares generales y específicos; que el proyecto tenga contenido económico y esté contemplado en el presupuesto respectivo. Como mínimo deben calcularse las siguientes razones: a. Tasa Interna de Retorno. b. Valor Neto Presente.c. Período de Recuperación.d. Y, el total de los beneficios netos. Dependiendo de los resultados de este estudio se determinará si se continúa o no con el proyecto.

3. Factibilidad Operacional. Si se desarrolla e implanta, ¿será utilizado el sistema?, ¿existirá cierta resistencia al

cambio por parte de los usuarios que de cómo resultado una disminución de los posibles beneficios de la aplicación? El estudio de factibilidad lo lleva a cabo un pequeño equipo de personas (en ocasiones una o dos) que está familiarizado con técnicas de sistemas de información; dicho equipo comprende la parte de la empresa u organización que participará se verá afectada por el proyecto y es gente experta en los procesos de análisis y diseño de sistemas. En general, las personas que son responsables de evaluar la factibilidad son análisis capacitados o directivos.

2. ANÁLISIS DE SISTEMAS

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas:

1. ¿Qué es lo que hace? 2. ¿Cómo se hace? 3. ¿Con qué frecuencia se presenta? 4. ¿Qué tan grande es el volumen de transacciones o de decisiones? 5. ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? 6. ¿Existe algún problema? 7. Si existe un problema. ¿Qué tan serio es? 8. Si existe un problema. ¿Cuál es la causa de lo que origina?

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa, sus opiniones sobre porque ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Se emplea cuestionarios para obtener esta información cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organización. Así mismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observación en condiciones reales de las actividades de trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad. Conforme se reúnen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema, incluyendo la información que deben producir los sistemas junto con características operacionales tales como controles de procesamiento, tiempos de respuesta y métodos de entrada y salida.

3. DISEÑO DEL SISTEMA.

El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la de desarrollo del software, a la que denominan diseño físico. Los analistas de sistemas comienzan el proceso de diseño identificando los reportes y demás salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisión los datos específicos para cada reporte y salida. Es común que los diseñadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema esté terminado. Lo anterior se efectúa en papel o en la pantalla de una terminal utilizando para ello algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.Los documentos que contienen las especificaciones de diseño representan a éste de muchas maneras (diagramas, tablas y símbolos especiales). La información detallada del diseño se proporciona al equipo de programación para comenzar la fase de desarrollo de software .Los diseñadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. Una vez comenzada la fase de programación, los diseñadores contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseño

Fases del Diseño:

 Elección de una solución de diseño entre las soluciones candidatas.. Evaluación del hardware y software requeridos Diseño e Integración del nuevo sistema

CLASE DE DISEÑO DE SISTEMAS

1. Diseño General. El método comúnmente utilizado es la modelización (actode elaborar una o más representaciones gráficas del sistema).Los modelos de diseño general describen:

 La estructura de los archivos y las bases de datos (diagrama de estructuras de datos) Los métodos y procedimientos de proceso (diagrama de flujo) La estructura de la red informática (diagrama de flujo).

2. Diseño Detallado. Se divide en:

 Diseño Externo. (conjunto de especificaciones de la interfaz del sistema con sus usuarios incluyen entradas, consultas, salidas, diseño de ventanas y transición entre ventanas. Diseño Interno. Especificaciones de aplicación del sistema, los archivos, diseño de la base de datos.

4. IMPLANTACIÓN Y EVALUACIÓN

La implantación es el proceso de verificar e instalar nuevo equipo entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Dependiendo del tamaño de la organización que empleará la aplicación y el riesgo asociado con su uso, puede elegirse comenzar la operación del sistema sólo en un área de la empresa (prueba piloto). Cada estrategia de implantación tiene sus méritos de acuerdo con la situación que se considere dentro de la empresa. Sin importar cuál sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas.

Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones, realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua, los sistemas de información deben mantenerse siempre al día. En este sentido la implantación es un proceso en constante evolución.

La evolución de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

1. Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

2. Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

3. Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.

4. Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

Desafortunadamente la evaluación de sistemas no siempre recibe la atención que merece. Sin embargo, cuando se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes.

5. PRUEBA DE LOS SISTEMAS

Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funcione de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema para que los analistas observen si tratan de emplearlo en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organización implante el sistema y dependa de él.

En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribió los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y, por otra, que el software sea más confiable.

PRODUCCIÓN Y MANTENIMIENTO

Es el soporte “continuado de un sistema después de que se ha puesto en funcionamiento. Incluye el mantenimiento de aplicaciones y mejoras al sistema”. Esta fase incluye actividades como: Corrección de Errores Recuperación de datos por fallas del sistema Adaptación del sistema a nuevas necesidades

Un plan de pruebas permite especificar lo que desea probar y cómo ejecutar dichas pruebas. Un plan de pruebas se puede aplicar a una iteración concreta de su proyecto. Puede tener solo un conjunto de pruebas predeterminado para sus casos de prueba o puede crear una jerarquía de conjuntos de pruebas.

El Plan de Pruebas de Aceptación describe los pasos que se deben seguir para verificar que el sistema construido satisface los requerimientos.

El Plan de Pruebas de Aceptación es uno de los planes de prueba detallados y corresponde al nivel de pruebas de aceptación del sistema o de la solución. Este plan describe clara y completamente como realizar las pruebas.

Las pruebas de aceptación, involucran al usuario final y pretenden comprobar que la solución cumple con el modelo de negocio para el que fue desarrollado. Detección de defectos del producto entregado y planes de acción para corrección de los mismos.