You are on page 1of 8

Revisin del ciclo de vida del desarrollo de Aplicaciones, adquisicin o mantenimiento.

El Objetivo de esta revisin es identificar, analizar y evaluar los requerimientos del usuario, riesgos, exposiciones a ellos
y los controles en aplicaciones especficas durante la fase de desarrollo, adquisicin 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 aplicacin e identificar
las reas que exigen controles al hacer entrevistas con miembros claves del proyecto.

Determinar y clasificar los principales riesgos y exposicin a riesgos de la aplicacin, 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 aplicacin por referencia a
fuentes confiables y por medio de discusiones con miembros del equipo del proyecto.

Asesorar al equipo del proyecto respecto del diseo de la aplicacin y la implantacin 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 adquisicin de las aplicaciones para asegurarse de que
se implantan los controles, se satisfacen los requerimientos de los usuarios y se sigue la metodologa mas
adecuada en cada caso, esto permite asegurarse que las aplicaciones son eficaces y eficientes, al realizar
reuniones peridicas con miembros del equipo del proyecto y al hacer exmenes de la documentacin y los
productos en sus diversas etapas.

a. Revisin de desarrollo de sistemas.


Cuando se revisa el proceso de desarrollo de sistemas, se espera que el auditor de sistemas obtenga la documentacin
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. Tambin, 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 estn
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 documentacin 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 realizaran 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 solucin con los sistemas vigentes. De no ser as
corroborar la razonabilidad de la evaluacin de las soluciones alternativas. Determinar si finalmente se
eligi la solucin mas apropiada.
2. Definicin de requerimientos. El auditor de sistemas debe obtener el documento de definicin 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 representacin. Verificar que la gerencia aprob la
iniciacin del proyecto y el costo del proyecto. Revisar los diagramas de flujo de datos y el diseo
conceptual para asegurarse de que se trata las necesidades del usuario. Revisar el diseo 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
aplicacin es apropiada para el uso de una rutina de auditora incorporada. De ser as incorpore la
rutina en el diseo conceptual del sistema.
3. Fase de diseo detallado y programacin. Revisar los flujogramas del sistema para observar el
seguimiento del diseo 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 diseados dentro del sistema, para

comprobar que sean apropiados. Entrevistar a los usuarios clave del sistema para comprobar su
comprensin de cmo operar el sistema y evaluar su nivel de entrada en el diseo de los formatos de
pantalla y los informes de salida. Evaluar los rastros de auditora que se programan, en el sistema para
rastrear la informacin fuente clave. Verificar la correccin de los clculos de los procesos claves.
Verificar que el sistema puede identificar y procesar correctamente datos errneos. 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 programacin y que las pistas de auditora
recomendados o los mdulos de auditora 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 participacin del usuario, tal como escenario de situaciones de
prueba creados por los usuarios y/o aprobacin escrita de aceptacin 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
precisin de los mensajes de error para reconocer los datos errneos y la resolucin de estos errores.
5. Implantacin. Esta fase se inicia solo despus de una exitosa fase de prueba. Debe tenerse precaucin
al transferir un nuevo sistema a situacin de produccin. 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 parmetros del
sistema que se utilizan al ejecutar el cronograma de actividades. Revisar la documentacin 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 conversin de datos para asegurarse de que es correcta
y esta completa antes de implementar en produccin al nuevo sistema.
6. Fase de Post-Implantacin. 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
atencin a la utilizacin y la satisfaccin de los usuarios finales, ellos constituirn 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 diseo, programacin o interpretacin de los requerimientos de usuario.
b. Revisin de aplicaciones de software comprado.
Para tomar la decisin de comprar el producto de un vendedor en lugar de crear una solucin interna, debe existir en el
estudio de factibilidad, documentacin sobre la decisin de "hacer vs. Comprar", esta documentacin debe ser
analizada para determinar si la decisin de comprar fue apropiada. y considerar lo siguiente respecto a los
proveedores: Estabilidad financiera. Nmero de aos de experiencia ofreciendo el producto. Nmero de sedes de
clientes que usen el servicio. Compromiso de servicio. Compromiso de desarrollar o mejorar el producto. Nivel de
satisfaccin de otros clientes, si es posible visitar sus instalaciones y ver como se utiliza en un ambiente real de
produccin. Compromiso para la provisin de entrenamiento, documentacin y upgrades a los productos. Aceptacin de
pruebas de productos antes de la compra. Adicionalmente el auditor de sistemas deber revisar el contrato en los
siguientes puntos: Descripcin especfica 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 recuperacin de desastres.
c.

Revisin del Mantenimiento de aplicaciones.

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

Evaluar los estndares y procedimientos para cambios a programas para asegurar su adecuacin por
medio de examen de la correspondiente documentacin, discusiones con personal clave y
observaciones.

Probar los procedimientos de control de cambios para asegurar que se explican segn se describe en
los estndares por medio de discusin 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 auditora.

Determinar la adecuacin de la seguridad de la biblioteca de produccin para asegurar la integridad de


los recursos de produccin al identificar y probar controles existentes.

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

Procedimientos para autorizacin de los cambios a los programas de produccin. Documentacin de


programas, las solicitudes de cambio deben ser archivadas con la documentacin del programa
afectado y debe incluirse la documentacin de la razn del cambio (anlisis del costo / beneficio) si es
necesario.

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

Concordancia del cdigo 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 produccin.

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

LOS SISTEMAS COMO CAMBIO ORGANIZACIONAL PLANEADO


QUIN EST INVOLUCRADO EN LA CONSTRUCCIN DE SISTEMAS?
Los especialistas en sistemas aportarn sus conocimientos especficos orientados a la coordinacin y planeacin de
sistemas, la determinacin de los requerimientos y los procedimientos para encontrar buenas soluciones a los
problemas organizacionales, as como la responsabilidad tcnica sobre el nuevo sistema
CMO SE ADMINISTRA EL DESARROLLO DE SISTEMAS?
El diseo 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:
&#61510Definicin del grupo de trabajo (Comit de Usuarios)
 Designacin del Administrador del Proyecto (Representante de la Alta Direccin)
 Establecimiento de las actividades a realizar, en detalle
 Definicin del cronograma de actividades
DE DNDE PROVIENEN LA IDEA DE LOS SISTEMAS?
El estudio de los sistemas de informacin se origin como una sub-disciplina de las ciencias de la computacin en un

intento por entender y racionalizar la administracin de la tecnologa dentro de las organizaciones. Los sistemas de
informacin han madurado hasta convertirse en un campo de estudios superiores dentro de la administracin. La idea
fundamentalmente proviene de:
 La necesidad del usuario de una herramienta que le facilite el acceso a la informacin.
 La necesidad del administrador para el control de sus recursos.
 La necesidad del auditor para llevar a cabo su funcin de asesora o consultora para ver si la
administracin 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
explotacin y el mantenimiento de un producto de software, abarcando la vida del sistema desde la definicin de los
requisitos hasta la finalizacin de su uso
En la mayor parte de las situaciones dentro de una empresa todas las actividades estn muy relacionadas, en general
son inseparables, y quiz sea difcil 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 anlisis, mientras que otros, en etapas avanzadas de diseo.
Las actividades tpicas del ciclo de vida son:
1- Estudio de factibilidad.
2- Anlisis (de requerimientos).
3- Diseo
4- Implementacin
5- Validacin y prueba
6 - Operacin 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 organizacin
 Proporcionar puntos de control y revisin administrativos
 Organizar las actividades de manera lgica
 Controlar la calidad del sistema
1. ESTUDIO DE FACTIBILIDAD
Un resultado importante de la investigacin preliminar es la determinacin de que el sistema solicitado sea factible. En
la investigacin preliminar existen tres aspectos relacionados con el estudio de factibilidad.

1. Factibilidad Tcnica. El trabajo para el proyecto, puede realizarse en el equipo actual, la tecnologa existente del
software y el personal disponible? Si se necesita nueva tecnologa cul es la posibilidad de desarrollarla?
2. Factibilidad Econmica. Que los beneficios (tangibles e intangibles) y horros superen a los costos; que los ndices
financieros que se calculen sean aceptables, de acuerdo con polticas y estndares generales y especficos; que el
proyecto tenga contenido econmico y est contemplado en el presupuesto respectivo.
Como mnimo deben calcularse las siguientes razones:
a. Tasa Interna de Retorno.
b. Valor Neto Presente.
c. Perodo de Recuperacin.
d. Y, el total de los beneficios netos.
Dependiendo de los resultados de este estudio se determinar si se contina 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 cmo resultado una disminucin de los posibles beneficios de la aplicacin?
El estudio de factibilidad lo lleva a cabo un pequeo equipo de personas (en ocasiones una o dos) que est
familiarizado con tcnicas de sistemas de informacin; dicho equipo comprende la parte de la empresa u organizacin
que participar se ver afectada por el proyecto y es gente experta en los procesos de anlisis y diseo de sistemas.
En general, las personas que son responsables de evaluar la factibilidad son anlisis capacitados o directivos.
2. ANLISIS DE SISTEMAS
El aspecto fundamental del anlisis 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. Cmo se hace?
3. Con qu frecuencia se presenta?
4. Qu tan grande es el volumen de transacciones o de decisiones?
5. Cul es el grado de eficiencia con el que se efectan las tareas?
6. Existe algn problema?
7. Si existe un problema. Qu tan serio es?
8. Si existe un problema. Cul 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 informacin cuando no es posible entrevistar, en
forma personal, a los miembros de grupos grandes dentro de la organizacin.
As mismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin 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 renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar
las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto
con caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y mtodos de
entrada y salida.
3. DISEO DEL SISTEMA.
El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir
con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con
frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo del software, a la que denominan
diseo fsico. Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas
que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada

reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan que aparezca
cuando el sistema est terminado. Lo anterior se efecta 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 diseo representan a ste de muchas maneras (diagramas,
tablas y smbolos especiales). La informacin detallada del diseo se proporciona al equipo de programacin para
comenzar la fase de desarrollo de software .
Los diseadores son los responsables de dar a los programadores las especificaciones de software completas y
claramente delineadas. Una vez comenzada la fase de programacin, los diseadores contestan preguntas, aclaran
dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseo
Fases del Diseo:
 Eleccin de una solucin de diseo entre las soluciones candidatas..
 Evaluacin del hardware y software requeridos
 Diseo e Integracin del nuevo sistema

CLASE DE DISEO DE SISTEMAS


1. Diseo General. El mtodo comnmente utilizado es la modelizacin (acto
de elaborar una o ms representaciones grficas del sistema).Los modelos de diseo general describen:
 La estructura de los archivos y las bases de datos (diagrama de estructuras de datos)
 Los mtodos y procedimientos de proceso (diagrama de flujo)
 La estructura de la red informtica (diagrama de flujo).
2. Diseo Detallado. Se divide en:
 Diseo Externo. (conjunto de especificaciones de la interfaz del sistema con sus usuarios incluyen
entradas, consultas, salidas, diseo de ventanas y transicin entre ventanas.
 Diseo Interno. Especificaciones de aplicacin del sistema, los archivos, diseo de la base de datos.
4. IMPLANTACIN Y EVALUACIN
La implantacin es el proceso de verificar e instalar nuevo equipo entrenar a los usuarios, instalar la aplicacin y
construir todos los archivos de datos necesarios para utilizarla. Dependiendo del tamao de la organizacin que
emplear la aplicacin y el riesgo asociado con su uso, puede elegirse comenzar la operacin del sistema slo en un
rea de la empresa (prueba piloto). Cada estrategia de implantacin tiene sus mritos de acuerdo con la situacin que
se considere dentro de la empresa. Sin importar cul 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 aos. 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 informacin deben mantenerse siempre al da. En este sentido la implantacin es un proceso en
constante evolucin.
La evolucin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de
cualquiera de las siguientes dimensiones:

1. Evaluacin operacional: Valoracin de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo
de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin.

2. Impacto organizacional: Identificacin y medicin de los beneficios para la organizacin en reas tales como
finanzas, eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin
externo e interno.
3. Opinin de loa administradores: evaluacin de las actividades de directivos y administradores dentro de la
organizacin as como de los usuarios finales.
4. Desempeo del desarrollo: La evaluacin de proceso de desarrollo de acuerdo con criterios tales como tiempo y
esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos.
Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo.
Desafortunadamente la evaluacin de sistemas no siempre recibe la atencin que merece. Sin embargo, cuando se
conduce en forma adecuada proporciona mucha informacin 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 despus 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
organizacin 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 ms confiable.
PRODUCCIN Y MANTENIMIENTO
Es el soporte continuado de un sistema despus de que se ha puesto en funcionamiento. Incluye el mantenimiento
de aplicaciones y mejoras al sistema.
Esta fase incluye actividades como:
 Correccin de Errores
 Recuperacin de datos por fallas del sistema
 Adaptacin del sistema a nuevas necesidades

Un plan de pruebas permite especificar lo que desea probar y cmo ejecutar dichas pruebas. Un plan de pruebas se
puede aplicar a una iteracin concreta de su proyecto. Puede tener solo un conjunto de pruebas predeterminado para
sus casos de prueba o puede crear una jerarqua de conjuntos de pruebas.
El Plan de Pruebas de Aceptacin describe los pasos que se deben seguir para verificar que el sistema construido
satisface los requerimientos.

El Plan de Pruebas de Aceptacin es uno de los planes de prueba detallados y corresponde al nivel de pruebas de
aceptacin del sistema o de la solucin. Este plan describe clara y completamente como realizar las pruebas.

Las pruebas de aceptacin, involucran al usuario final y pretenden comprobar que la solucin cumple con el modelo de
negocio para el que fue desarrollado. Deteccin de defectos del producto entregado y planes de accin para correccin
de los mismos.

You might also like