Está en la página 1de 31

AUDITORIA A UN PROYECTOS DE INGENIERIA DE SOFTWARE EN

CADA UNA DE LAS FASES DE PREANALISIS, ANALISIS, DISEÑO,


CONSTRUCCIÓN, IMPLANTACIÓN, PRUEBAS Y ACEPTACION DEL
SISTEMA
TAREA No. 1- 2

ARYARIDEL RIOS DEL VALLE

MARIO ALFONSO ROSERO RIVAS

AUDITORIA DE SISTEMAS A PROYECTOS DE INGENIERIA DE SOFTWARE


PROGRAMA AUDITORIA DE SISTEMAS
UNIVERSIDAD ANTONIO NARIÑO
2011

1
AUDITORIA A UN PROYECTOS DE INGENIERIA DE SOFTWARE EN
CADA UNA DE LAS FASES DE PREANALISIS, ANALISIS, DISEÑO,
CONSTRUCCIÓN, IMPLANTACIÓN, PRUEBAS Y ACEPTACION DEL
SISTEMA
TAREA No. 1- 2

ARYARIDEL RIOS DEL VALLE

MARIO ALFONSO ROSERO RIVAS

Trabajo presentado como requisito de la Materia


Auditoria De Sistemas A Proyectos De Ingeniería De Software

Tutora:
Esp. DORA JANETH ALFONSO COMBITA

AUDITORIA DE SISTEMAS A PROYECTOS DE INGENIERIA DE SOFTWARE


PROGRAMA AUDITORIA DE SISTEMAS
UNIVERSIDAD ANTONIO NARIÑO
2011

2
TABLA DE CONTENIDO

TITULO PÁGINA

- INTRODUCCION 5

1. AUDITORIA DE SISTEMAS A PROYECTOS DE


INGENIERIA DE SOFTWARE 6

1.1 CONCEPTOS GENERALES 6

2. FASES DEL DESARROLLO DE SOFTWARE 6

2.1. ANÁLISIS 6

2.2. DISEÑO 7

2.3. IMPLEMENTACIÓN 7

2.4. MANTENIMIENTO 7

3. AUDITORIA A UN PROYECTO DE INGENIERÍA DE

SOFTWARE 8

3.1. PLANEACIÓN O PREANÁLISIS 8

3.1.1. LA DEFINICIÓN DEL SISTEMA ACTUAL 9

3.1.2. UBICACIÓN GENERAL DEL SISTEMA

3
3.1.3. OBJETIVOS DEL SISTEMA 9

3.1.4. ALCANCE DEL PROYECTO 10

3.1.5. ESTIMATIVOS DE DESARROLLO DEL SISTEMA 11

3.1.6. BENEFICIOS DE LA IMPLANTACIÓN DEL SISTEMA 12

3.1.7. ESTUDIO DE FACTIBILIDAD 12

3.2. FASE DE ANÁLISIS 13

3.2.1. ANÁLISIS DE REQUISISTOS DEL SISTEMA 14

3.2.2. ESPECIFICACIÓN FUNCIONAL DEL SISTEMA (EFS) 16

3.3. FASE DE DISEÑO 17

3.3.1. DISEÑO TÉCNICO DEL SISTEMA 17

3.4. FASE DE CONSTRUCCIÓN 20

3.4.1. DESARROLLO DE LOS COMPONENTES DEL

SISTEMA (DCS) 20

3.4.2. DESARROLLO DE LOS PROCEDIMIENTOS DE

USUARIO (DPU) 22

3.5. FASE DE IMPLANTACIÓN 23

3.5.1. PRUEBAS, IMPLANTACIÓN Y ACEPTACIÓN DEL

SISTEMA (PIA) 23

4
- CONCLUSION 25

- BIBLIOGRAFIA 26

INTRODUCCION

El siguiente trabajo contiene un resumen y los aspectos que se deben tener en


cuenta al auditar un proyecto de Ingeniería de software en cada una de las fases
de Pre-análisis, Análisis, Diseño, Construcción, Implantación, Pruebas y
Aceptación Del Sistema.

5
1. AUDITORIA DE SISTEMAS A PROYECTOS DE INGENIERIA DE SOFTWARE

1.1 CONCEPTOS GENERALES

6
La ingeniería del software es un conjunto de técnica y herramientas para producir
software de alta calidad, fiable, flexible y portable.

Es la forma mediante la cual se describen los diferentes pasos que se deben


seguir para el desarrollo de un software, partiendo desde una necesidad hasta
llegar a la puesta en marcha de una solución y su apropiado mantenimiento.

El ciclo de vida para un software comienza cuando se tiene la necesidad de


resolver un problema, y termina cuando el programa que se desarrolló para
cumplir con los requerimientos, deja de ser utilizado.

Existen varias versiones del ciclo de vida del software entre las cuales se
destacan: el ciclo de vida clásico o en cascada, el modelo en espiral, el desarrollo
de prototipos, el modelo por incrementos y el modelo extremo.

2. FASES DEL DESARROLLO DE SOFTWARE

El ciclo de vida clásico del software siendo uno de los más utilizados tal como lo
plantean diferentes autores, está conformado por las siguientes fases:

2.1. ANÁLISIS

7
En esta etapa se debe entender y comprender de forma detallada cual es la
problemática a resolver, verificando el entorno en el cual se encuentra dicho
problema, de tal manera que se obtenga la información necesaria y suficiente para
afrontar su respectiva solución. Esta etapa es conocida como la del qué se va a
solucionar.

2.2. DISEÑO

Una vez que se tiene la suficiente información del problema a solucionar, es


importante determinar la estrategia que se va a utilizar para resolver el problema.
Esta etapa es conocida bajo el cómo se va a solucionar.

2.3. IMPLEMENTACIÓN

Partiendo del análisis y diseño de la solución, en esta etapa se procede a


desarrollar el correspondiente programa que solucione el problema mediante el
uso de una herramienta computacional determinada.

2.4. MANTENIMIENTO

Una vez instalado un programa y puesto en marcha para realizar la solución del
problema previamente planteado o satisfacer una determinada necesidad, es

8
importante mantener una estructura de actualización, verificación y validación que
permitan a dicho programa ser útil y mantenerse actualizado según las
necesidades o requerimientos planteados durante su vida útil.

3. AUDITORIA A UN PROYECTO DE INGENIERÍA DE SOFTWARE

Antes de comenzar a verificar los aspectos de cada una de estas etapas, es


necesario tener en cuentas unas características de la etapa de PLANEACIÓN O
PREANÁLISIS

3.1. PLANEACIÓN O PREANÁLISIS:

Como auditores de un proyecto de ingeniería de software se debe prestar mucho


cuidado y estar pendiente de esta etapa del desarrollo de un proyecto de software,
porque es donde se transforma inquietudes y requerimientos de información de un
área específica, en un estudio de factibilidad que contiene definición organizada
de los requerimientos, recursos con que se cuenta, las alternativas de desarrollo y
el cronograma de actividades.

Como auditores de un proyecto de ingeniería de software se tendrá el objetivo en


esta etapa de la planeación, de aclarar y comprender la solicitud del proyecto,
determinar alcance del proyecto, lograr un conocimiento general y estructural de
los requerimientos de información, planear alternativas de desarrollo, evaluar
costos y beneficios, determinar factibilidad operativa, técnica y económica y
planear las actividades generales que pueden llegar a surgir durante en un
proyecto de ingeniería de software.

9
Se debe tener en cuenta los siguientes pasos de la Planeación:

a. La Definición del sistema actual.

b. La Ubicación del sistema

c. Los Objetivos del sistema a desarrollar

d. El Alcance del sistema

e. Los Estimativos de desarrollo del sistema

f. El Beneficios del sistema

g. El Estudio de factibilidad

3.1.1. LA DEFINICIÓN DEL SISTEMA ACTUAL

Como auditor dentro de esta fase del proyecto se debe:

- Determinar en forma coherente y estructurada las necesidades de información

- Entender el dominio del problema y el entorno de éste

- Determinar las definiciones técnicas.

3.1.2. UBICACIÓN GENERAL DEL SISTEMA

En esta fase se debe contar con:

- Características generales de la organización: Objeto social, estructura


organizacional, ubicación geográfica, sector, etc.

- Descripción del área: definición de las áreas donde se va a desarrollar el


sistema.

10
3.1.3. OBJETIVOS DEL SISTEMA

En esta etapa se debe determinar:

- Los logros para alcanzar

- Establecer el marco de referencia para el proyecto de desarrollo del S.I.

- Los objetivos cualitativos y/o cuantitativos.

- Verificar si los objetivos reflejan la satisfacción de las necesidades de


información y los beneficios organizacionales y económicos de la empresa.

- Verificar si los objetivos indican las metas a lograr en el desarrollo del sistema

Algunos de los objetivos del sistema pueden ser::

- Minimizar número de errores


- Aumentar precisión en la captura de datos
- Reducción o simplificación de informes
- Integración de los subsistemas del negocio
- Mejorar servicios al cliente
- Acelerar captura de datos
- Reducir tiempo de procesamiento de datos
- Automatizar procedimientos manuales
- Lograr una ventaja competitiva para la organización
- Hacer más rentable algún proceso
- Agregar valor a alguna función de la organización
- Minimizar número de errores

11
- Aumentar precisión en la captura de datos
- Reducción o simplificación de informes
- Integración de los subsistemas del negocio
- Mejorar servicios al cliente
- Acelerar captura de datos
- Reducir tiempo de procesamiento de datos
- Automatizar procedimientos manuales
- Lograr una ventaja competitiva para la organización
- Hacer más rentable algún proceso
- Agregar valor a alguna función de la organización

3.1.4. ALCANCE DEL PROYECTO

Para el proyecto a realizar se debe:

- Revisar la definición de Macro módulos o macro funciones que delimitan el


sistema.

- Evaluar si las funciones o procesos a desarrollar permiten alcanzar los objetivos


que se busca con el proyecto.

- Establecer interacciones entre funciones y procesos

- El alcance puede ser revaluado para comprobar si los objetivos se alcanzan

12
3.1.5. ESTIMATIVOS DE DESARROLLO DEL SISTEMA

Como auditores se debe verificar si el Talento Humano es el apropiado, el


hardware, el software, entre otros.

Hay que evaluar si el Talento Humano es el apropiado, verificando cada uno de


los cargos:

- GERENTE DEL PROYECTO: Usuario con poder de decisión, con visión del
negocio, elabora el presupuesto y coordina los grupos de: usuarios y
analistas programadores.

- AUDITOR Y JEFE DE SISTEMAS: Asesoran y esporádicamente verifican


si se están cumpliendo las especificaciones.

Para realizar la estimación del talento humano el gerente del proyecto se debe
preguntar:

 ¿Quiénes estarán involucrados en él proyecto?


 ¿Qué función tiene cada uno de los integrantes del proyecto
dentro del grupo?

13
 Tiempo de participación en el proyecto, hay que tener en
cuenta que todo proyecto debe tener unos plazos para el
desarrollo de este.

Si en el proyecto se debe estimar hardware, se debe verificar las especificaciones


técnicas de:

 Servidores
 Computadores
 Comunicaciones: tarjeta de red, enrutadores, fibra óptica,
conectores, concentradores, etc.

Lo anterior es un paso bastante de sentido común, si el proyecto utiliza tecnología


en su montaje y puesta en marcha habrá problemas si no se escogen los
elementos adecuados.

También debe hacerse una ESTIMACIÓN DE SOFTWARE, por lo que como


auditores debemos revisar:

 Sistema operacional
 Motor de base de datos
 CASER (procedimientos para simulaciones)
 Herramientas de usuario final

14
3.1.6. BENEFICIOS DE LA IMPLANTACIÓN DEL SISTEMA

Como auditores debemos evaluar los beneficios tangibles e intangibles:

 Tangibles: Tomar los objetivos y cuantificarlos.

 Intangibles: Apoyo a la visión, misión, objetivos y estrategias


de la organización.

3.1.7. ESTUDIO DE FACTIBILIDAD

En cualquier proyecto a realizar relacionados con la ingeniería de software se


debe evaluar la factibilidad económica, técnica y operativa:

 FACTIBILIDAD ECONÓMICA: Existe presupuesto, estudio


costo/beneficio, disposición de la gerencia, voluntad.

15
 FACTIBILIDAD TÉCNICA: Hardware, Software, ubicación de
los equipos, tendido del cable, etc.

 FACTIBILIDAD OPERATIVA: Conocimientos del personal de


sistemas, conocimientos del usuario, usuario dispuesto a
aceptar el cambio.

Una vez finalizada la etapa de pre análisis continuamos realizando un estudio


detallado de un sistema, los requerimientos de los usuarios y su medio ambiente
para inferir las especificaciones para un nuevo sistema.

3.2. FASE DE ANÁLISIS

Aquí el auditor debe buscar las especificaciones que describen las necesidades
del sistema en cuanto a información, esto el auditor debe tratar de recolectar esas
especificaciones fuera del entorno técnico.

La fase de análisis se divide en dos secciones a saber:

16
• Análisis de requisitos del sistema (ARS).
• Especificación funcional del sistema (EFS).

3.2.1. ANÁLISIS DE REQUISISTOS DEL SISTEMA

El auditor deberá identificar los requisitos del sistema, para esto tendrá que
clasificar de acuerdo a la prioridad de cada requisito, y que tan importante es para
el sistema sea este funcional o no.

Para hacer esto el auditor debe verificar los controles existentes del sistema y ver
que controles falta implementar.

Para determinar los requisitos del sistema el auditor debe:

• Determinar quiénes son los usuarios que participan en el proyecto.


• Tomar muestras representativas del universo de usuarios que están
involucrados con el sistema, así posteriormente el auditor podrá evaluar la
muestra y obtendrá resultados que reflejaran las necesidades reales de los
usuarios.
• Informar adecuadamente a los usuarios escogidos dentro de la muestra
representativa que es lo que se va hacer lo que se espera de ellos, para que el

17
proceso de recolección de información sea el más eficiente y muestre los
resultados esperados.
• Verificar la existencia de un plan que detalle cada entrevista donde se
especifique el sitio, hora y fecha de la entrevista, así como los temas a tratar.
• Comprobar que se entreviste a todos los usuarios del sistema que fueron
escogidos por representar todas las unidades del sistema.
• Informar a los entrevistados que es aquello que se tratará en la entrevista
dicha información tendrá preguntas sobre el área o unidad en trabajan y las
necesidades que pueda tener el área para que ellos puedan documentarse y
dar la mayor cantidad de información referente al tema de la entrevista sobre
las necesidades del sistema.

Como resultado de las entrevistas se debe redactar unas conclusiones sobre las
entrevistas realizadas, estas conclusiones deben mostrar el sistema actual y las
necesidades del mismo, producto de las bondades y problemas que existan en el
sistema. Por esta razón el auditor debe entonces comprobar que:

• Exista un modelo del sistema actual que incluya objetivos, entradas y


salidas de cada unidad en el sistema.
• Se han clasificado los problemas de acuerdo a su importancia y prioridad.
• Se ha creado un modelo lógico de datos y de procesos del sistema actual,
que sean correctos y que fueran realizados con las técnicas del área.
• Que los requisitos del sistema estén justificados.
• Los requisitos del sistema deben ser medibles.
• EL comité de la dirección y los usuarios aprueben el catalogo de requisitos
del proyecto.

18
Ahora es posible que durante el transcurso del proyecto surjan cambios en los
requisitos del sistema luego de las entrevistas, razón por la cual el auditor
verificará:

• El procedimiento a cambiar existe y se encuentra debidamente aprobado.


• El cambio general en el proyecto es coherente con los procedimientos de
control.

Teniendo en cuenta que el proyecto será el desarrollo de un nuevo software o


sistema hay que definir la metodología de construcción mostrando las ventajas y
desventajas de la alternativa de construcción escogida, para así escoger la más
adecuada. Por eso el auditor debe inspeccionar que exista:

• Un registro que muestre las diferentes alternativas para desarrollar, y en


caso de no existir otra explicar que no existe.
• Las alternativas expuestas deben ser lógicas al menos en cuanto a
procesos y que tengan relación con los requisitos ya establecidos.
• Entre las alternativas expuestas debe estar si existe un producto que
cumpla con las necesidades requeridas en el mercado, también si el desarrollo
lo puede hacer personal externo a la organización, porque la idea es terminar
escogiendo la mejor alternativa de todas en cuanto a ventajas para la
organización.

19
3.2.2. ESPECIFICACIÓN FUNCIONAL DEL SISTEMA (EFS).

Hay que elaborar en detalle las especificaciones del sistema y lo que se espera de
él. Por lo que se realiza un modelo lógico de procesos y de datos, entonces el
auditor debe comprobar:

• Que sean elaborados los modelos partiendo del análisis de los requisitos
del sistema.
• Que el modelo lógico de procesos se sea realizado en forma adecuada y
que sea correcto técnicamente. Adicionalmente en este modelo se debe tener
en cuenta que debe diferenciarse los procesos manuales y que los usuarios
entenderán dicho modelo.
• Debe haber un diagrama donde se especifique el contexto donde se
muestran los agentes externos con los que el sistema intercambiará
información.
• El modelo lógico de datos debería existir y ser hecho de forma adecuada,
además de ser correcto técnicamente.
• El modelo lógico de datos debe reflejar las entidades con sus atributos del
sistema y claves, como la relación entre ellas.
• El modelo lógico de datos y de procesos deben ser coherentes entre sí, y
estar aprobados por la dirección y los usuarios.
• Si se gestiona en forma automatizada el diccionario de datos y si es
correcto.
• Que se cumplen adecuadamente los procedimientos de cambio.

Se define como interactuará el sistema con los usuarios, razón por la que se
verifica:

20
• Que se documente y se describa adecuadamente la información que usará
el usuario dentro de la aplicación, teclas de función disponibles, botones, etc.
• Que este aprobada la interfaz grafica, tanto por los usuarios como por la
junta del comité de la dirección.

No hay que olvidar los requisitos de seguridad, respaldo, rendimiento entre otros,
por lo que se revisa:

• La información entregada por los usuarios cuando se llevo a cabo las


entrevistas, que esta sea documentada y contrastada con el módulo en
cuestión.

Si bien el proyecto es de desarrollo se debe especificar entonces las pruebas que


debe pasar el nuevo sistema para que este sea aceptado.

3.3. FASE DE DISEÑO

En esta fase habrá un solo módulo en que se debe elaborar el conjunto de


especificaciones físicas del nuevo sistema que servirán de base para la
construcción del mismo

21
3.3.1. DISEÑO TÉCNICO DEL SISTEMA.

Como usuario a partir de las especificaciones funcionales, y teniendo en cuenta el


entorno tecnológico, se debe diseñar la arquitectura del sistema y el esquema
externo de datos. Como auditor hay que definir el mejor control que sea adecuado
y funcional con el entorno tecnológico que fue elegido.

Hay que definir el entorno tecnológico lo más claro posible respetando los
estándares propios del departamento de informática encargado del proyecto.
Entonces como auditores del sistema en desarrollo hay que comprobar que:

• Se encuentre definido todos aquellos elementos que hacen parte del entorno
tecnológico dentro del proyecto.
• Que se encuentren disponibles los elementos disponibles para el desarrollo y
que se estén debidamente estandarizados según los estándares del
departamento de informática y que responden a los requisitos establecidos
en cuanto a seguridad, tiempos de respuesta, etc.

Como se realiza un proyecto de desarrollo deberán existir una serie de actividades


a realizar las cuales se deben descomponer en módulos para su verificación,
razón por lo cual se debe verificar:

22
• Que se documente apropiadamente todas las actividades físicas que debe
realizar el sistema.
• Que exista un catalogo que tenga referenciado todas las funciones
identificadas en el módulo lógico de procesos de la actividades del módulo
de especificación funcional del sistema que hace parte de la fase de análisis.
• Que se han tenido que haber identificado las actividades comunes, así como
las existentes en las librerías generales del área.
• La existencia de un documento con el diseño de la estructura modular del
sistema y que este sea realizado de forma adecuada y que sea correcto.
• El tamaño de los módulos es el adecuado, que se acoplen como debe ser
con una cohesión máxima y facto de acople mínimo.
• Si es necesario los módulos deben estar diseñados para usarse por otras
aplicaciones si es necesario.
• Que se han definido como debe ser los componentes o programas del nuevo
sistema, detallados, modulares, definidos correctamente y siguiendo los
estándares del área.
• Que estén detallados todas las interfaces de control y datos con otros
módulos del sistema. Así como la interfaz de usuario ya definida en la
especificación funcional del sistema que hace parte de la fase de análisis.

La estructura física de datos debe diseñarse adaptando las especificaciones del


sistema al entorno tecnológico. Para lograr esto hay que comprobar lo siguiente:

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


incluye las claves, relaciones, vistas, etc., que fueron definidos en la
especificación funcional del sistema.

23
• Que se tenga en cuenta el entorno tecnológico y los requisitos de
rendimiento para los volúmenes y frecuencias de acceso estimados.

Ahora en caso de incluir algún incumplimiento de las normas este queda


justificado.

Como auditores hay que diseñar pruebas que permitan la verificación del sistema,
por módulos separados, en conjunto, tanto del sistema en general como de los
subsistemas involucrados, por este motivo hay que comprobar:

• La existencia de un plan de pruebas y que se contemple los recursos


necesarios para realizar dichas pruebas.
• Las personas que hacen las pruebas son diferentes a quienes están
involucrados en el desarrollo.
• Para validar cada componente del sistema, incluyendo las pruebas del
sistema, se deben tener en cuenta todas las posibles combinaciones o
condiciones lógicas de ejecución, además de posibles fallos de software base
y de hardware sobre donde se implementa el sistema.
• Se valide todo el sistema en conjunto al integrar todos los componentes.

Esta fase debe concluir teniendo en cuenta las características de:

a) La funcionalidad.

24
b) La facilidad.
c) La confiabilidad.
d) El desempeño.
e) La soportabilidad, la adaptabilidad y la servicialidad.

3.4. FASE DE CONSTRUCCIÓN

Esta fase es necesaria para que los usuarios puedan usar el nuevo sistema
porque aquí es donde se programa, prueba y se ponen en marcha los
componentes del sistema.

3.4.1. DESARROLLO DE LOS COMPONENTES DEL SISTEMA (DCS).

Aquí se realizan y se prueban distintos componentes del sistema tanto separados


como integrados, de igual forma se desarrollan los procedimientos de operación.

Hay que verificar que se los módulos o componentes se desarrollen utilizando


técnicas adecuadas.

Por tal motivo como auditor se debe comprobar que:


• Se tiene creado y se han inicializado, los archivos, bases de datos que
cumplen las especificaciones realizadas en la fase de diseño.
• Se preparen los procedimientos de copias de seguridad.
• Se debe encontrar disponible el acceso a los equipos, los puestos de trabajo,
medios de conectividad, etc.
• Se puede realizar las pruebas de los componentes de forma unitaria o
integrada.

25
• Exista documentos o manuales de operación, para cuando se explote el
sistema.

Como auditores se debe documentar todo aquello que se encuentre referente al


sistema, razón por la cual hay que verificar que:

• Todos los módulos hayan sido desarrollados.


• Se hayan seguido todos los estándares, que se tenga documentado el área
de trabajo, que contenga comentarios suficientes que permitan entender el
sistema, también que su código se encuentre debidamente estructurado.
• Se ha probado cada componente del sistema y se han generado los
informes de prueba y que estos sean satisfactorios.

Obviamente los componentes del sistema deben poder integrarse, los módulos
también deben trabajar correctamente, por eso como auditor hay que comprobar:
• Las pruebas de integración van de acuerdo a lo que se planteo en la fase
de diseño.
• El proyecto debe ser actualizado en caso de que en las pruebas realizadas
se encontraron inconsistencias.
• El equipo de desarrollo es el único que debe participar en las pruebas de
integración.
3.4.2. DESARROLLO DE LOS PROCEDIMIENTOS DE USUARIO (DPU).

Como los usuarios deben y necesitan usar el sistema de forma correcta en este
módulo se debe definir los procedimientos y formación adecuados.

Los usuarios que utilizaran el sistema deberían estar capacitados bien para poder
hacer uso del sistema como debe ser. Por eso hay que comprobar cómo auditor lo
siguiente:

26
• El plan de desarrollo forma parte del plan de proyecto, por lo que debe tener
los procedimientos de usuario donde se incluya los recursos y actividades
necesarias.
• Los procedimientos se realizan después de que se tenga la especificación
funcional del sistema, pero antes de que se implante.

Hay que especificar los perfiles de usuarios del sistema por eso hay que ver que
se realizo la respectiva definición de los perfiles de usuarios para que se implante
y explote el sistema, también que estos usuarios tengan unos perfiles definidos
dentro de un rango de fechas y permisos necesarios.

De igual forma se debe comprobar que:

• Están desarrollados los procedimientos de usuario, que estén plasmados


dentro del manual de usuario, y que estén de acuerdo a lo que se planteo en
la especificación funcional del sistema.
• Cada procedimiento debe especificar lo que se debe hacer, especificando
los recursos a utilizar e indicando el perfil asociado.
• Los manuales de usuario deben estar estandarizados según el área y se
controlan las versiones de los mismos.

Según los perfiles de usuarios creados para el sistema debería seleccionarse el


personal que utilizará el sistema o la formación que se le dará a los mismos.

También hay que verificar:

• Que se ha especificado los recursos que usara de cada usuario.

27
• Se ha planificado el alquiler o adquisición de aquello que necesita el
sistema y con los recursos no disponibles en la organización.

3.5. FASE DE IMPLANTACIÓN.

Aquí es donde los usuarios adoptan el sistema.

3.5.1. PRUEBAS, IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA (PIA).

Hay que verificar que se cumplan los requisitos expuestos en la fase de análisis,
ya que en el momento de ser probado y aceptado se puede implementar el
sistema.

Se debe comprobar lo siguiente:

• Que se tiene los recursos y el entorno adecuado para hacer las pruebas.
• Las pruebas deben permitir verificar que se cumple con las especificaciones
funcionales del sistema y que se interactúa adecuadamente con el entorno.
• Que se actualizo el sistema cuando se encuentre inconvenientes y se
solventen las incidencias encontradas.
• Se revisará el plan de implantación en donde debe estar incluida la
instalación de todos los componentes y la inicialización de los datos,
especificando los recursos necesarios para cada actividad.
• Se debe seguir el plan de pruebas las cuales se realizaran por los usuarios,
se evaluarán los resultados y se procederá a realizar las correcciones para
que sea aprobado.
• Se debe comprobar la instalación de todos los procedimientos auxiliares,
que estén documentados detalladamente y que se capacite al personal.

28
• Una vez verificada la consistencia de la información del sistema nuevo se
procederá a retirar el antiguo, al menos que se requiera dejar el antiguo como
consulta.
• Se firmará un documento por el comité de dirección y por el grupo de
usuarios en donde se manifiesta que el sistema queda instalado
correctamente.
• Se deberá supervisar el desarrollo del trabajo en el nuevo sistema por los
usuarios.
• Por último se debe comprobar que exista un mecanismo de mantenimiento
y los procedimientos a seguir ante cualquier incidente o interrupción, teniendo
en cuenta los tiempos de respuesta máximos.

La finalidad de la fase de Pruebas, Implantación y Aceptación del Sistema, es de


comprobar el funcionamiento correcto del sistema en un entorno de operación,
permitiendo al usuario determinar la aceptación del nuevo sistema ya en el
entorno real. Los usuarios son los que realmente podrán concluir si se cumplieron
los requisitos especificados, por ello, de igual manera se debe contar con un
completo plan de pruebas las cuales una vez ejecutadas, se tendrá en cuentas las
incidencias detectas y se informará al responsable de la implantación el cual
analizará la información y tomará las medidas correctivas para que el nuevo
sistema dé respuesta de acuerdo a las especificaciones establecidas y poder ser
aprobado. Una vez que se verifica que el funcionamiento es el adecuado se
firmará el documento de que el sistema queda instalado correctamente. Por último
se debe comprobar si existe el mecanismo de mantenimiento, en donde se
determine los procedimientos a seguir ante cualquier problema, por lo tanto, se
requiere que todos los usuarios estén familiarizados con él.

CONCLUSIONES

29
El anterior trabajo es una propuesta de los aspectos que el auditor debe tener en
cuentas en las fases de análisis, diseño de un proyecto, fase de construcción,
desarrollo de los componentes del sistema, desarrollo de los procedimientos de
usuario, fase de implantación, pruebas, implantación y aceptación del sistema,
basándonos en el material de apoyo entregado por el tutor e investigaciones en
internet. Hay que resaltar que en las fases vistas en este trabajo, el tema general
son los controles a implementar para que se logre con los objetivos del proyecto
de ingeniería de software.

El software debe ser confiable, se debe mantener y ser flexible para que de esta
manera se disminuyan los costos de mantenimiento, actualizaciones,
perfeccionamiento, por lo menos durante el tiempo de utilización, ya que de
presentarse incidencias, las correcciones pueden resultar muy costosas, de ahí la
importancia de contar con controles durante cada una de las etapas del ciclo de
vida del software.

BIBLIOGRAFIA

30
- Material de apoyo de la materia Auditoria De Sistemas A Proyectos De Ingeniería
De Software

Páginas WEB:

- http://www.virtual.unal.edu.co/cursos/sedes/manizales/4060024/Lecciones/ Cap
itulo%20I/problemas.htm

- http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

- http://www.wiziq.com/tutorial/67020-Presentaci-243-n-de-Auditoria-y-Seguridad

- http://www.google.com.co/search?q=PRUEBAS%2C+IMPLANTACI%C3%93N+Y
+ACEPTACI
%C3%93N+DEL+SISTEMa&hl=es&rlz=1T4ADRA_esCO400CO401&sa=2

31