[Capte la atencin del lector con un resumen

atractivo. Este resumen es una breve descripcin

del documento. Cuando est listo para agregar
contenido, haga clic aqu y empiece a escribir.]

Auditoria Bus
APP
TSUTIC. Marycruz Santos Escareo
TSUTIC. Daniel Torres Salas
TSUTIC .Hector Daniel Hernandez Zapata

16 DE OCTUBRE DEL 2015

Contenido
1.

Plan de Auditoria ........................................................................................................................ 3

2.

Listas de Comprobacin del rea de desarrollo de software ..................................................... 5

3.

Auditoria de la funcionalidad de la aplicacin mvil Bus App .................................................... 9

4.

INFORME DE AUDITORA .......................................................................................................... 12

5.

Minuta de cierre de auditoria ................................................................................................... 18

Plan de Auditoria

Objetivo: Entrevistar al equipo de trabajo del desarrollo de la aplicacin mvil Bus App con la
finalidad de evaluar el funcionamiento adecuado basado en la normatividad y estndares de
calidad del rea de desarrollo de software, para verificar el cumplimiento de los procesos que se
llevan a cabo.
Auditor Lder:
Marycruz Santos Escareo

Reunin de Apertura
Fecha:18/septiembre/2015

Reunin de Cierre
Fecha: 18/septiembre/2015

Auditores:
Alcance: Este procedimiento es aplicable al sistema de
Hctor Daniel Hernndez Zapata
gestin de la calidad para verificar por medio de auditoras
Daniel Torres Salas
Marycruz Santos Escareo
internas, si se siguen los procedimientos de calidad de manera
eficaz.
Proceso: Designacin del auditor jefe, definicin de objetivos,
alcance y criterios de auditoria, establecimiento del equipo
auditor, revisin de la documentacin d la empresa,
elaboracin del plan de auditoria, preparacin de las
actividades de auditoria, reunin de apertura, ejecucin de
auditoria, reunin de cierre, preparacin del informe de
auditora, aprobacin y comunicado de informe de auditora,
finalizacin de auditoria.
Criterios:

Procedimiento/Actividad
Determinacin del alcance de la

Daniel Torres Salas

auditoria
Estudio de
importantes

Auditor

los

documentos Hctor Daniel Hernndez

Zapata

Auditado
Jefe de oficina de control
interno
Jefe administrativo
Director / Gerente de

Informtica
Acordar el itinerario o programa de Marycruz Santos Escareo Jefe de oficina de control
auditoria
interno
Preparacin
de
listas
de Hctor Daniel Hernndez
Zapata
comprobacin o cuestionarios

Jefe de oficina de control

interno

Realizar auditoria

Daniel Torres Salas

Realizar informe de auditoria

Marycruz Santos Escareo Jefe de oficina de control

interno

Personal del rea de desarrollo,

red fsica y red lgica

Observaciones:

Fecha: 16/OCTUBRE/20015
___________________________________
____________________________
_____________________________
Auditor
Jefe Oficina Control Interno

LISTAS DE COMPROBACIN DEL REA DE DESARROLLO

DE SOFTWARE
AUDITORIA DE LA FASE DE PLANIFICACIN.

Objetivos
El proyecto de desarrollo debe estar aprobado, definido y planificado
formalmente.
Deben designarse un responsable o director del proyecto.
El proyecto debe ser catalogado y, en funcin de sus caractersticas, se debe
determinar el modelo del ciclo de vida que se seguir.
Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo
tcnico que realizara el proyecto y determina el plan del proyecto.
1
2

Se debe Comprobar que :

Exista una orden de aprobacin del proyecto
por un rgano competente.

En el documento de aprobacin estn

definidos de forma clara y precisa los objetivos
del mismo y las restricciones de todo tipo que
deben tenerse en cuenta (temporales,
recursos
tcnicos,
recursos
humanos,
presupuesto, etc.)
Se le ha comunicado al director del proyecto
su nombramiento junto con la informacin
relevante del proyecto.

Se ha catalogado y dimensionado el proyecto

segn las normas establecidas.

Se ha elegido el ciclo de vida ms adecuado al

tipo del proyecto de que se trata.

SI

NO

Observaciones
Se autoriz el
proyecto por el
profesor encargado
de la prctica, pero
no una orden de
aprobacin fsica
No existe
documento de
aprobacin

No existe una
designacin de
roes como tal,
todos los
integrantes del
equipo de
desarrollo se
desenvuelven en
diferentes roles y
actividades
El desarrollo del
proyecto no est
basado en ningn
estndar de calidad
No se cuenta con
un ciclo de vida del
proyecto

Auditoria De La Fase De Anlisis

Objetivos
En el proyecto de desarrollo se utilizara la alternativa ms favorable para conseguir

1
2

que el sistema cumpla los requisitos establecidos

El nuevo sistema debe especificarse de forma completa desde el punto de vista
funcional, contando esta especificacin con la aprobacin de los usuarios

Se debe Comprobar que :

SI

NO

Existe un documento determinan formalmente el grupo

de usuarios que participaran en el proyecto.

12 Existe el catlogo de requisitos que estn justificados.

13 Los requisitos son concretos y cuantificables, de forma

14

que pueda determinarse el grado de cumplimiento al

final del proyecto
Cada requisito tiene una prioridad y est clasificado en
funcional o no funcional.

15 El catlogo de requisitos ha sido revisado y aprobado

constituyendo a partir de este momento del contrato

entre estos y el equipo de desarrollo del proyecto

Observaciones
No existe el
documento
Mostro el
documento de
especificacin de
requerimientos
pero no estn
justificados
Los requisitos
son concretos
No se cuenta con
la clasificacin de
requisitos
Los requisitos no
estn justificados
por lo que no
existe un contrato

Auditora De La Fase De Diseo.

Objetivos
Se debe definir una arquitectura fsica para el sistema coherente con la
especificacin funcional que se tenga y con el entorno tecnolgico elegido.

El entorno tecnolgico debe estar definido de forma clara

Se deben identificar todas las actividades fsicas a realizar por el sistema y

descomponer las mismas de forma modular.

Se debe Comprobar que :

Se han documentado todas las actividades
fsicas que debe realizar el sistema.

Existe el documento con el diseo de la

estructura modular del sistema

Los componentes o programas del nuevo

sistema se han definido con detalle a partir del
diseo modular. La descripcin de los
componentes es suficiente para permitir su
programacin por parte de un programador sin
conocimiento previo del sistema.

11

El mdulo fsico de datos est basado en el MLD

obtenido en el mdulo EFS e incluye todas las
entidades, relaciones, claves, vistas, etc.

12

Tiene en cuenta el entorno tecnolgico y los

requisitos de rendimiento

13

Existe el plan de pruebas y contempla todos los

recursos necesarios para llevarlas a efecto.
Se realizaron pruebas unitarias del sistema
desarrollado
Se realizaron pruebas modulares al sistema
desarrollado

14
15

SI

NO

Observaciones
Si se realizaron
las actividades
pero no est
documentas
Se mostr el
documento con
los prototipos de
los mdulos de la
aplicacin
La descripcin de
los componentes
no es
suficientemente
clara para ser
programado por
alguien que no
conoce el
sistema
Si incluye todas
las entidades
No cuenta con la
propiedad
responsive, para
adaptarse en los
diferentes
resoluciones de
dispositivos
No existe
No se realizaron
pruebas
Se realizaron
pruebas en dos
dispositivos pero
no estn
documentados.

Auditoria De La Fase De Construccin

Objetivos
Los componentes o mdulos deben desarrollarse usando tcnicas de
programacin correctas.
Se debe preparar adecuadamente el entorno de desarrollo y de pruebas as
como los procedimientos de operacin, antes de iniciar el desarrollo.
se debe programar, probar y documentar cada uno de los componentes
identificados en el diseo del sistema.
deben realizarse las pruebas de integracin para asegurar que las interfaces,
entre los componentes o mdulos funcionan correctamente
Se Debe Comprobar Que:

Se han preparado los procedimientos de

copia de seguridad.

Se
han
preparado
los
editores,
compiladores,
herramientas,
etc.
Necesarios.

Estn definidos los distintos perfiles de

usuario requerido para la implantacin y
explotacin del nuevo sistema.

10

Se han desarrollados todos los componentes

y mdulos

11

Se han seguido los estndares de

programacin, documentacin del rea ,
cdigo es estructurado , est bien sangrado
y contiene comentarios suficiente

12

Se han probado cada componente y se ha

generado e informe de prueba. Si los
resultados de las pruebas no san
satisfactorio se modifica el cdigo y se vuelve
a realizar la prueba.

Si

No

Observaciones
No se tienen
procedimientos
de seguridad
Si
se
han
preparado
Si
estn
definidos
los
usuarios de la
aplicacin
Se desarrollaron
los mdulos
Se
program
basndose en
una herramienta
que
utiliza
bloques
de
cdigo
App
Inventor
Se
realizaron
pruebas y se
hicieron
modificaciones
pero no existe
evidencia fsica

13

Las pruebas de integracin se han llevado

acabo segn lo especificado en el plan de
pruebas realizado en el mdulo de diseo

No se cuenta
con un plan de
pruebas

15

han participado los usuarios en las pruebas

de integracin solo debe participar el equipo
de desarrollo

Nada
participa
equipo
desarrollo

ms
el
de

Auditora De La Fase De Implantacin

Objetivo General:
El sistema debe ser aceptado formalmente por los usuarios antes de ser
puesto en explotacin.
El sistema se pondr en explotacin formalmente y pasar a estar en
mantenimiento solo cuando haya sido aceptado y est preparado todo el
entorno en el que se ejecutar.

La aplicacin mvil Bus App no fue implementada

AUDITORIA DE LA FUNCIONALIDAD DE LA APLICACIN

MVIL BUS APP

Objetivos
Se evala la efectividad de los controles existentes y sugerir
nuevos controles de tal forma de fortalecer el control de esta
aplicacin
Identificar analizar y evaluar las fortalezas y debilidades
Evaluar el ambiente de control para determinar si se han
alcanzado los objetivos de la misma

Se debe comprobar que

1

Si

No

Observaciones

Ingreso de los datos al sistema de

La aplicacin no realiza

informacin en funcionamiento

algunos procesos
acorde a los archivos o
informacin que
contiene el sistema

Las funciones de salida de

La aplicacin arroja los

informacin

resultados correctos

El ingreso de los datos, la

La aplicacin cuenta con

aplicacin debe tener adecuados

notificaciones cuando el

mensajes de ayuda con el fin de

usuario ingresa datos

facilitar los ingresos de estos

que no corresponden
aunque los mensajes
aun cuentan con errores

Al ir ingresando los datos el

La aplicacin procesa la

sistema debe ir comparando con

peticin el usuario y le

los registros de archivos maestros

arroja la informacin

para determinar la validez de los

correcta al usuario

datos ingresados
5

En cada campo debe tener el

Los campos que

formato de datos apropiado

contiene la aplicacin
cuenta con las
validaciones para que
solo ingresen datos tipo
texto

La aplicacin no debe permitir que

El usuario solo puede

los datos de los archivos maestros

interactuar con la

puedan ser borrados del sistema

aplicacin en los
procesos que le sean
tiles sin poder acceder
a modificar informacin
o estructura del sistema

Controlar si en el ingreso de los

La aplicacin enviara un

datos hay un rechazo por el

mensaje al usuario

sistema, este datos sea analizado

cuando los datos que

y corregido por el usuario

haya ingresado no sean

correctos( cuando
ingrese un origen igual a
su destino)
8

Transacciones errneas o

La aplicacin an no

incompletas

cuenta con la totalidad

de sus procesos
correctos(enva
mensajes de alarma
cuando el usuario
ingreso correctamente
su origen y destino )

Asegurar la continuidad de los

La aplicacin no

interacciones del usuario despus

funciona en su totalidad

de un proceso

ya que despus de
realizar algunos
procesos no continua
con naturaleza en otros
procesos( cuando el
usuario a realizado
varios procesos la
opcin de salir no
respeta esta indicacin)

bn

Versin: 01

INFORME DE AUDITORA
Fecha de
01/10/2015

Proceso: Desarrollo y
funcionalidad de
Software

emisin:
Fecha de versin: 16-102015

Seccin No.1 DATOS GENERALES DE LA AUDITORA

Procesos

Responsable del proceso

Auditoria de Desarrollo y funcionalidad de Software

Marycruz Santos Escareo

Fecha de apertura

Fecha de cierre

Fecha elaboracin informe

Tipo de auditora

01/10/2015

16/10/2015

12/08/2015

Auditoria Informtica

Auditores
Auditor lder:

Auditados

Marycruz Santos Escareo

Daniel Torres Salas

Hctor Daniel Hernndez Zapata

Daniel Torres Salas

Hctor Daniel Hernndez Zapata

Marycruz Santos Escareo

Objetivo general
Entrevistar al equipo del trabajo con la finalidad de evaluar el funcionamiento adecuado basado en la normatividad y estndares de
calidad del rea de desarrollo de software para verificar el cumplimiento de los procesos que se llevan a cabo en dichas reas.
Alcance
Este procedimiento es aplicable al sistema de gestin de la calidad para verificar por medio de auditoras internas si se siguen los
procedimientos de la calidad de manera eficaz.

Seccin No.2 RESULTADOS DELA AUDITORIA

Hallazgo No 1

No se cuenta con ningn tipo de seguridad proyecto.

Criterio de auditoria

Tipo de hallazgo
NCM: Obs:

No Conformidad Mayor (NCM)

Hallazgo No 2

No se desarroll un plan de riesgos

Criterio de auditoria

Tipo de hallazgo
NC: Obs:
.

Hallazgo No 3

No Conformidad Mayor (NCM)

No se cuenta con un plan de trabajo, ni se baso el Proyecto en un ciclo de vida.
Criterio de auditoria

Tipo de hallazgo
NCM: Obs:
Hallazgo No 4

No Conformidad Mayor (NCM)

No se cuenta con la aprobacion del proyecto ni el nombramiento de los roles
Criterio de auditoria

Tipo de hallazgo
NCM: Obs:
Hallazgo No 5

No Conformidad Mayor (NCM)

Algunos modulos del Sistema no cumplen con la function deceada

Tipo de hallazgo
NCM: Obs:

Criterio de auditoria
No Conformidad Mayor (NCM)

Fortalezas (acciones de mejora)

Es necesario la comunicacin entre el equipo de trabajo de un proyecto de sw para que todos los integrantes estn enterados de la
situacin actual del proyecto ya que cada miembro cuenta con un rol diferente y pues todos necesitan conocer acerca del proyecto
para poder trabajar en equipo.
Oportunidades de mejora (acciones preventivas - identificacin de riesgos)
Desarrollar un buen plan de riesgos durante todo el proceso de desarrollo del proyecto, ya contar con acciones preventivas y
correctivas necesarias para dichos casos de tal manera que no afecten el proceso de desarrollo del sw.

Tipo de hallazgo: NC: No Conformidad Mayor y Obs: Observacin

Versin: 01

INFORME DE AUDITORA
Proceso: Desarrollo y
funcionalidad de
Software

Fecha de
01/10/2015

emisin:
Fecha de versin: 16-102015

Seccin No.3 VALIDACICIN DEL INFORME

AUDITOR

AUDITADO

Nombre:

Marycruz Santos Escareo

Nombre:

Daniel Torres Salas

Fecha:

12/08/2015

Fecha:

12/082015

Firma

Firma
Marycruz Santos Escareo

Daniel Torres Salas

Versin: 01

INFORME DE AUDITORA
Proceso: Desarrollo y
funcionalidad de
Software

Fecha de
01/10/2015

emisin:
Fecha de versin: 16-102015

Seccin No.4 FICHA DE RESUMEN DE LA AUDITORIA

NO CONFORMIDADES
Numeral

REQUISITOS DEL SISTEMA

No.
No.
No.
Detectadas Solucionadas Pendientes
NCM Ncm

1.

NCM

Ncm

NCM Ncm

APROBACIN, PLANIFICACIN Y GESTIN DEL PROYECTO

1.1

Estudio de factibilidad

1.2

Acta de inicio

1.3

Restricciones del Proyecto

1.4

Nombramiento del administrador del

proyecto

1.5

Plan de riesgos

1.6

Ciclo de vida

1.7

Informacin histrica de proyectos

relacionados
Plan de Comunicacin

1.9

Plan de Proyecto(Objetivos, justificacin,

recursos , presupuesto de la Problemtica)

1.10

Minutas de reunions

1.11

Registro de problemtica y soluciones

1.12

Diagrama de Gantt

1.13

Estructura de descomposicin de trabajo

1.8

2.

ANLISIS

2.1

Documento formal donde se aprueba

participantes del proyecto con
nombramiento as como su puesto y
funciones.

2.2

Plan de entrevistas, encuestas y

Observaciones.

2.3

Catlogo de Requisitos (SRS 830)

Versin: 01

INFORME DE AUDITORA
Proceso: Desarrollo y
funcionalidad de
Software

3
3.1

Fecha de
01/10/2015

emisin:
Fecha de versin: 16-102015

DISEO
Seleccin de Elementos de Entornos
(Servidores, contratacin de servicios,
perifricos, sistemas, aplicaciones,
protocolos de comunicaciones, lenguajes
de programacin, gestor de Bases de Datos
y herramientas case)

CONSTRUCCION

4.2

Creacin de Mdulos

10

4.3

Codificacin de Mdulos

10

4.4

Documentacin de Cdigo

4.5

Depuracin de Cdigo

4.6
4.7

Mdulos Funcionales
Plan de pruebas

8
1

0
0

0
0

0
0

2
1

0
0

4.8

Manual de Usuario

10

4.9

Manual Tcnico

10

4.10

Manual de Instalacin

4.11

Paquete de Instalacin

Calificacin del proceso referente al nivel de cumplimiento con la norma, de uno (1) a diez
(10) uno es el tem ms bajo:

Versin: 01

INFORME DE AUDITORA
Proceso: Desarrollo y
funcionalidad de
Software

Fecha de
01/10/2015

emisin:
Fecha de versin: 16-102015

Seccin 5. TRATAMIENTO DE NO CONFORMIDADES

Descripcin de la no conformidad

No
conformidad

Correccin propuesta
(accin inmediata)

Causa Raz

Menor:
Mayor:

No se cuenta con ningn tipo de seguridad

proyecto

Requisito:

Elaborar e implementar medidas de

seguridad tanto fsicas como
lgicas para la proteccin y
rendimiento del sw.

Se desconocen este tipo de

medidas que son de gran
importancia en los proyectos
de sw.

Menor:
Mayor:

No se desarroll un plan de riesgos

Requisito:

Elaborar plan de riegos.

No se llevo una adecuada

documentacion del
proyecto

Plan de accin correctivo

Actividad: Elaborar medidas
de seguridad para el sw.
Fecha: 25/10/2015

Actividad: Implementar estas

medidas de seguridad.
Fecha:20/10/2015

Seguimiento
Abierta:
Cerrada:
Fecha: 25/10/2015

Inicial Aprobada:
Rechazada:
Fecha: 25/10/2015

Actividad: identificar los

posibles riesgos y como
contrarrestarlos
Fecha: 25/10/2015

Seguimiento
Abierta:
Cerrada:
Fecha: 25/10/2015

Inicial Aprobada:

Menor:
Requisito:

Inicial Aprobada:
Rechazada:
Fecha: 25/10/2015

Actividad: elaborar un plan

de gestion de riesgos.
Fecha: 25/10/2015

Mayor:

No se cuenta con un plan de trabajo, ni se baso

el Proyecto en un ciclo de vida

Estado

Rechazada:
Utilizer el diagrama de Gantt
asignando y valorando el tiempo
estimado a las actividades a
desarrollar.

Actividad: crear el
Se carece de informacin
diagrama de Gantt.
de las actividades a realizar
Fecha: 20/11/1015
durante el desarrollo del
proyecto.

Fecha: 30/08/2015
Seguimiento
Abierta:
Cerrada:
Fecha: 25/10/2015

Versin: 01

INFORME DE AUDITORA
Proceso: Desarrollo y
funcionalidad de
Software

Fecha de
01/10/2015

emisin:
Fecha de versin: 16-102015
Inicial Aprobada:

Menor:

Rechazada:
Fecha: 25/10/2015

Mayor:
No se cuenta con la aprobacion del proyecto ni el
nombramiento del director del proyecto.

Requisito:

Menor:

Es necesario contar con la

aprobacion fisica del proyecto
asi como los nombramientos de
director del proyecto

No existe un cliente
como tal

Cerrada:
Fecha: 25/10/2015

Inicial Aprobada:

Mayor:

Algunos modulos del Sistema no cumplen con

la function deceada.

Requisito:

Actividad: crear el
nombramiento como evidencia Seguimiento
Abierta:
Fecha: 25/10/2015

Realizar pruebas heursticas a cada

mdulo del sistema.
Corregir cada uno de los mdulos
fallidos.

No se implementaron las
pruebas heursticas por
mdulos.

Actividad: Realizar pruebas

heursticas
Fecha: 25/10/2015
Actividad: Corregir mdulos
Fecha: 25/10/2015

Rechazada:
Fecha: 25/10/2015
Seguimiento
Abierta:
Cerrada:
Fecha: 25/10/2015

MINUTA DE CIERRE DE AUDITORIA

Lugar: Audiovisual

Fecha: 16-octubre-2015

Hora de inicio: 9:15am

Hora de termino 10:00am

Hora:9:00am

Objetivo de la reunin: reunin de cierre de auditoria

Asistencia
Numero Participantes

Si

Marycruz Santos Escareo

Daniel Torres Salas

Hector Daniel Hernandez Zapata

No

ORDEN DEL DA
1. Bienvenida a los asistentes
2. Resumen de las actividades de la auditora
3. Lectura del reporte de la auditora interna
4. Recomendaciones del equipo auditor
5. Comentarios de los responsables de proceso

Acuerdos

Responsables

Fecha

1.- Realizar
documentacin del
proyecto
2.- Terminar la
funcionalidad de la
totalidad de los
mdulos
3.- Dar seguimiento al
cierre de las acciones
correctivas
documentadas

Hector Daniel Hernandez

25 de octubre del 2015

Daniel Torres Salas

25 de octubre del 2015

Marycruz Santos
Escareo

25 de octubre del 2015