Auditoria

16 DE OCTUBRE DEL 2015

[Capte la atención del lector con un resumen

atractivo. Este resumen es una breve descripción

del documento. Cuando esté listo para agregar

contenido, haga clic aquí y empiece a escribir.]

Auditoria Bus APP

TSUTIC. Marycruz Santos Escareño TSUTIC. Daniel Torres Salas TSUTIC .Hector Daniel Hernandez Zapata

Contenido 1. Plan de Auditoria ........................................................................................................................ 3

2. Listas de Comprobación del área de desarrollo de software ..................................................... 5

3. Auditoria de la funcionalidad de la aplicación móvil Bus App .................................................... 9

4. INFORME DE AUDITORÍA .......................................................................................................... 12

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

Plan de Auditoria

Objetivo: Entrevistar al equipo de trabajo del desarrollo de la aplicación móvil Bus App con la

finalidad de evaluar el funcionamiento adecuado basado en la normatividad y estándares de

calidad del área de desarrollo de software, para verificar el cumplimiento de los procesos que se

llevan a cabo.

Auditor Líder: Marycruz Santos Escareño

Reunión de Apertura Fecha:18/septiembre/2015

Reunión de Cierre Fecha: 18/septiembre/2015

Auditores: Héctor Daniel Hernández Zapata Daniel Torres Salas Marycruz Santos Escareño

Alcance: Este procedimiento es aplicable al sistema de

gestión de la calidad para verificar por medio de auditorías

internas, si se siguen los procedimientos de calidad de manera

eficaz.

Proceso: Designación del auditor jefe, definición de objetivos, alcance y criterios de auditoria, establecimiento del equipo auditor, revisión de la documentación d la empresa, elaboración del plan de auditoria, preparación de las actividades de auditoria, reunión de apertura, ejecución de auditoria, reunión de cierre, preparación del informe de auditoría, aprobación y comunicado de informe de auditoría, finalización de auditoria. Criterios:

Procedimiento/Actividad Auditor Auditado

Determinación del alcance de la

auditoria

Daniel Torres Salas

Jefe de oficina de control interno

Director / Gerente de

Informática

Estudio de los documentos importantes

Héctor Daniel Hernández Zapata

Jefe administrativo

Acordar el itinerario o programa de auditoria

Marycruz Santos Escareño

Jefe de oficina de control interno Preparación de listas de

comprobación o cuestionarios

Héctor Daniel Hernández Zapata


Realizar auditoria Daniel Torres Salas

Personal del área de desarrollo, red física y red lógica

Realizar informe de auditoria Marycruz Santos Escareño


Observaciones:

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

LISTAS DE COMPROBACIÓN DEL ÁREA DE DESARROLLO DE SOFTWARE

“AUDITORIA DE LA FASE DE PLANIFICACIÓN”.

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 función de sus características, 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

técnico que realizara el proyecto y determina el plan del proyecto.

1 Se debe Comprobar que : SI NO Observaciones

2 Exista una orden de aprobación del proyecto por un órgano competente.

Se autorizó el proyecto por el

profesor encargado de la práctica, pero

no una orden de aprobación física

3 En el documento de aprobación están definidos de forma clara y precisa los objetivos del mismo y las restricciones de todo tipo que deben tenerse en cuenta (temporales, recursos técnicos, recursos humanos, presupuesto, etc.)

No existe documento de aprobación

6 Se le ha comunicado al director del proyecto

su nombramiento junto con la información

relevante del proyecto.

No existe una designación de roes como tal,

todos los integrantes del

equipo de desarrollo se

desenvuelven en diferentes roles y

actividades

7 Se ha catalogado y dimensionado el proyecto

según las normas establecidas.

El desarrollo del proyecto no está basado en ningún estándar de calidad

9 Se ha elegido el ciclo de vida más adecuado al

tipo del proyecto de que se trata.

No se cuenta con un ciclo de vida del proyecto

“Auditoria De La Fase De Análisis”

Objetivos

En el proyecto de desarrollo se utilizara la alternativa más favorable para conseguir

que el sistema cumpla los requisitos establecidos

El nuevo sistema debe especificarse de forma completa desde el punto de vista

funcional, contando esta especificación con la aprobación de los usuarios

1 Se debe Comprobar que : SI NO Observaciones

2 Existe un documento determinan formalmente el grupo de usuarios que participaran en el proyecto.

No existe el documento

12 Existe el catálogo de requisitos que están justificados.

Mostro el

documento de especificación de requerimientos pero no están justificados

13 Los requisitos son concretos y cuantificables, de forma que pueda determinarse el grado de cumplimiento al final del proyecto

Los requisitos

son concretos

14 Cada requisito tiene una prioridad y está clasificado en

funcional o no funcional.

No se cuenta con la clasificación de

requisitos

15 El catálogo de requisitos ha sido revisado y aprobado

constituyendo a partir de este momento del “contrato”

entre estos y el equipo de desarrollo del proyecto

Los requisitos no están justificados

por lo que no existe un contrato

“Auditoría De La Fase De Diseño”.

Objetivos

Se debe definir una arquitectura física para el sistema coherente con la

especificación funcional que se tenga y con el entorno tecnológico elegido.

El entorno tecnológico debe estar definido de forma clara

Se deben identificar todas las actividades físicas a realizar por el sistema y

descomponer las mismas de forma modular.

Se debe Comprobar que : SI NO Observaciones

3 Se han documentado todas las actividades físicas que debe realizar el sistema.

Si se realizaron las actividades pero no está documentas

6 Existe el documento con el diseño de la estructura modular del sistema

Se mostró el

documento con los prototipos de los módulos de la

aplicación

9 Los componentes o programas del nuevo sistema se han definido con detalle a partir del diseño modular. La descripción de los componentes es suficiente para permitir su programación por parte de un programador sin conocimiento previo del sistema.

La descripción de los componentes

no es suficientemente clara para ser

programado por alguien que no

conoce el sistema

11 El módulo físico de datos está basado en el MLD obtenido en el módulo EFS e incluye todas las entidades, relaciones, claves, vistas, etc.

Si incluye todas

las entidades

12 Tiene en cuenta el entorno tecnológico y los requisitos de rendimiento

No cuenta con la propiedad

responsive, para adaptarse en los

diferentes resoluciones de

dispositivos

13 Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto.

No existe

14 Se realizaron pruebas unitarias del sistema desarrollado

No se realizaron pruebas

15 Se realizaron pruebas modulares al sistema desarrollado

Se realizaron

pruebas en dos dispositivos pero

no están documentados.

“Auditoria De La Fase De Construcción “

Objetivos

Los componentes o módulos deben desarrollarse usando técnicas de

programación correctas.

Se debe preparar adecuadamente el entorno de desarrollo y de pruebas así

como los procedimientos de operación, antes de iniciar el desarrollo.

se debe programar, probar y documentar cada uno de los componentes

identificados en el diseño del sistema.

deben realizarse las pruebas de integración para asegurar que las interfaces,

entre los componentes o módulos funcionan correctamente

Se Debe Comprobar Que: Si No Observaciones

3 Se han preparado los procedimientos de

copia de seguridad.

No se tienen

procedimientos de seguridad

4 Se han preparado los editores,

compiladores, herramientas, etc.

Necesarios.

Si se han

preparado

9 Están definidos los distintos perfiles de

usuario requerido para la implantación y

explotación del nuevo sistema.

Si están

definidos los usuarios de la aplicación

10 Se han desarrollados todos los componentes

y módulos

Se desarrollaron los módulos

11 Se han seguido los estándares de

programación, documentación del área ,

código es estructurado , está bien sangrado

y contiene comentarios suficiente

Se programó

basándose en una herramienta que utiliza bloques de código “App Inventor”

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 código y se vuelve

a realizar la prueba.

Se realizaron

pruebas y se hicieron modificaciones pero no existe evidencia física

13 Las pruebas de integración se han llevado

acabo según lo especificado en el plan de

pruebas realizado en el módulo de diseño

No se cuenta

con un plan de pruebas

15 han participado los usuarios en las pruebas

de integración solo debe participar el equipo

de desarrollo

Nada más

participa el equipo de desarrollo

“Auditoría De La Fase De Implantación”

Objetivo General:

El sistema debe ser aceptado formalmente por los usuarios antes de ser

puesto en explotación.

El sistema se pondrá en explotación formalmente y pasará a estar en

mantenimiento solo cuando haya sido aceptado y esté preparado todo el

entorno en el que se ejecutará.

La aplicación móvil Bus App no fue implementada

AUDITORIA DE LA FUNCIONALIDAD DE LA APLICACIÓN MÓVIL BUS APP

Objetivos

Se evalúa la efectividad de los controles existentes y sugerir

nuevos controles de tal forma de fortalecer el control de esta

aplicación

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 Si No Observaciones

1 Ingreso de los datos al sistema de

información en funcionamiento

La aplicación no realiza

algunos procesos

acorde a los archivos o

información que

contiene el sistema

2 Las funciones de salida de

información

La aplicación arroja los

resultados correctos

3 El ingreso de los datos, la

aplicación debe tener adecuados

mensajes de ayuda con el fin de

facilitar los ingresos de estos

La aplicación cuenta con

notificaciones cuando el

usuario ingresa datos

que no corresponden

aunque los mensajes

aun cuentan con errores

4 Al ir ingresando los datos el

sistema debe ir comparando con

los registros de archivos maestros

para determinar la validez de los

datos ingresados

La aplicación procesa la

petición el usuario y le

arroja la información

correcta al usuario

5 En cada campo debe tener el

formato de datos apropiado

Los campos que

contiene la aplicación

cuenta con las

validaciones para que

solo ingresen datos tipo

texto

6 La aplicación no debe permitir que

los datos de los archivos maestros

puedan ser borrados del sistema

El usuario solo puede

interactuar con la

aplicación en los

procesos que le sean

útiles sin poder acceder

a modificar información

o estructura del sistema

7 Controlar si en el ingreso de los

datos hay un rechazo por el

sistema, este datos sea analizado

y corregido por el usuario

La aplicación enviara un

mensaje al usuario

cuando los datos que

haya ingresado no sean

correctos( cuando

ingrese un origen igual a

su destino)

8 Transacciones erróneas o

incompletas

La aplicación aún no

cuenta con la totalidad

de sus procesos

correctos(envía

mensajes de alarma

cuando el usuario

ingreso correctamente

su origen y destino )

9 Asegurar la continuidad de los

interacciones del usuario después

de un proceso

La aplicación no

funciona en su totalidad

ya que después de

realizar algunos

procesos no continua

con naturaleza en otros

procesos( cuando el

usuario a realizado

varios procesos la

opción de salir no

respeta esta indicación)

bn

INFORME DE AUDITORÍA

Versión: 01

Proceso: Desarrollo y funcionalidad de Software

Fecha de emisión: 01/10/2015

Fecha de versión: 16-10-2015

Sección No.1 DATOS GENERALES DE LA AUDITORÍA

Procesos Responsable del proceso

Auditoria de Desarrollo y funcionalidad de Software Marycruz Santos Escareño

Fecha de apertura Fecha de cierre Fecha elaboración informe Tipo de auditoría

01/10/2015 16/10/2015 12/08/2015 Auditoria Informática

Auditores Auditados

Auditor líder: Marycruz Santos Escareño Daniel Torres Salas

Daniel Torres Salas Héctor Daniel Hernández Zapata

Héctor Daniel Hernández Zapata Marycruz Santos Escareño

Objetivo general

Entrevistar al equipo del trabajo con la finalidad de evaluar el funcionamiento adecuado basado en la normatividad y estándares 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 gestión de la calidad para verificar por medio de auditorías internas si se siguen los procedimientos de la calidad de manera eficaz.

Sección No.2 RESULTADOS DELA AUDITORIA

Hallazgo No 1 No se cuenta con ningún tipo de seguridad proyecto.

Tipo de hallazgo Criterio de auditoria

NCM: Obs: No Conformidad Mayor (NCM)

Hallazgo No 2 No se desarrolló un plan de riesgos


NC: Obs: No Conformidad Mayor (NCM) .

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



Hallazgo No 4 No se cuenta con la aprobacion del proyecto ni el nombramiento de los roles



Hallazgo No 5 Algunos modulos del Sistema no cumplen con la function deceada



Fortalezas (acciones de mejora)

Es necesario la comunicación entre el equipo de trabajo de un proyecto de sw para que todos los integrantes estén enterados de la situación 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 - identificación 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: Observación

INFORME DE AUDITORÍA Versión: 01




Sección No.3 VALIDACICIÓN DEL INFORME

AUDITOR AUDITADO

Nombre: Marycruz Santos Escareño Nombre: Daniel Torres Salas

Fecha: 12/08/2015 Fecha: 12/082015

Firma Marycruz Santos Escareño

Firma Daniel Torres Salas





Sección No.4 FICHA DE RESUMEN DE LA AUDITORIA

Numeral

REQUISITOS DEL SISTEMA

NO CONFORMIDADES

No. Detectadas

No. Solucionadas

No. Pendientes

NCM Ncm NCM Ncm NCM Ncm

1. APROBACIÓN, PLANIFICACIÓN Y GESTIÓN DEL PROYECTO

1.1 Estudio de factibilidad 1 0 0 0 1 0

1.2 Acta de inicio 1 0 0 0 1 0

1.3 Restricciones del Proyecto 1 0 0 0 1 0

1.4 Nombramiento del administrador del proyecto

0

1

0

0

0

1

1.5 Plan de riesgos 1 0 0 0 1 0

1.6 Ciclo de vida 1 0 0 0 1 0

1.7 Información histórica de proyectos relacionados

1

0

0

0

1

0

1.8 Plan de Comunicación 1 0 0 0 1 0

1.9 Plan de Proyecto(Objetivos, justificación, recursos , presupuesto de la Problemática)

8

0

0

0

8

0

1.10 Minutas de reunions

1

0

0

0

1

0

1.11 Registro de problemática y soluciones 1 0 0 0 1 0

1.12 Diagrama de Gantt 1 0 0 0 1 0

1.13 Estructura de descomposición de trabajo 1 0 0 0 1 0

2. ANÁLISIS

2.1 Documento formal donde se aprueba participantes del proyecto con nombramiento así como su puesto y funciones.

0

1

0

0

0

1

2.2 Plan de entrevistas, encuestas y Observaciones.

1

0

0

0

1

0

2.3 Catálogo de Requisitos (SRS 830) 0 1 0 0 0 1





3 DISEÑO

3.1 Selección de Elementos de Entornos (Servidores, contratación de servicios, periféricos, sistemas, aplicaciones, protocolos de comunicaciones, lenguajes de programación, gestor de Bases de Datos y herramientas case)

1

0

0

0

1

0

4 CONSTRUCCION

4.2 Creación de Módulos 10 0 0 0 0 0

4.3 Codificación de Módulos 10 0 0 0 0 0

4.4 Documentación de Código 0 1 0 0 0 1

4.5 Depuración de Código 5 0 0 0 5 0

4.6 Módulos Funcionales 8 0 0 0 2 0

4.7 Plan de pruebas 1 0 0 0 1 0

4.8 Manual de Usuario 10 0 0 0 0 0

4.9 Manual Técnico 10 0 0 0 0 0

4.10 Manual de Instalación 1 0 0 0 1 0

4.11 Paquete de Instalación 5 0 0 0 0 0

Calificación del proceso referente al nivel de cumplimiento con la norma, de uno (1) a diez (10) uno es el ítem más bajo:





Sección 5. TRATAMIENTO DE NO CONFORMIDADES

Descripción de la no conformidad No

conformidad Corrección propuesta

(acción inmediata) Causa Raíz Plan de acción correctivo Estado

No se cuenta con ningún tipo de seguridad

proyecto

Mayor: □ Menor: □

Requisito:

Elaborar e implementar medidas de

seguridad tanto físicas como lógicas para la protección y

rendimiento del sw.

Se desconocen este tipo de medidas que son de gran

importancia en los proyectos de sw.

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

Actividad: Implementar estas medidas de seguridad. Fecha:20/10/2015

Inicial Aprobada:

□ Rechazada:□ Fecha: 25/10/2015

Seguimiento

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

No se desarrolló un plan de riesgos


Requisito:

Elaborar plan de riegos.

No se llevo una adecuada documentacion del

proyecto

Actividad: elaborar un plan de gestion de riesgos. Fecha: 25/10/2015

Actividad: identificar los posibles riesgos y como contrarrestarlos Fecha: 25/10/2015

Inicial Aprobada:


Seguimiento


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


Requisito:

Utilizer el diagrama de Gantt asignando y valorando el tiempo

estimado a las actividades a desarrollar.

Se carece de información de las actividades a realizar

durante el desarrollo del proyecto.

Actividad: crear el diagrama de Gantt. Fecha: 20/11/1015

Inicial Aprobada:


Seguimiento






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


Requisito:

Es necesario contar con la aprobacion fisica del proyecto

asi como los nombramientos de director del proyecto

No existe un cliente como tal

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

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

Seguimiento


Algunos modulos del Sistema no cumplen con la function deceada.


Requisito:

Realizar pruebas heurísticas a cada

módulo del sistema.

Corregir cada uno de los módulos fallidos.

No se implementaron las pruebas heurísticas por

módulos.

Actividad: Realizar pruebas heurísticas Fecha: 25/10/2015

Actividad: Corregir módulos Fecha: 25/10/2015

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

Seguimiento


MINUTA DE CIERRE DE AUDITORIA

Lugar: Audiovisual Fecha: 16-octubre-2015 Hora:9:00am

Hora de inicio: 9:15am Hora de termino 10:00am

Objetivo de la reunión: reunión de cierre de auditoria Asistencia

Numero Participantes Si No

1 Marycruz Santos Escareño *

2 Daniel Torres Salas *

3 Hector Daniel Hernandez Zapata *

ORDEN DEL DÍA

1. Bienvenida a los asistentes

2. Resumen de las actividades de la auditoría

3. Lectura del reporte de la auditoría interna

4. Recomendaciones del equipo auditor

5. Comentarios de los responsables de proceso

Acuerdos Responsables Fecha 1.- Realizar documentación del proyecto

Hector Daniel Hernandez 25 de octubre del 2015

2.- Terminar la funcionalidad de la totalidad de los módulos

Daniel Torres Salas 25 de octubre del 2015

3.- Dar seguimiento al cierre de las acciones correctivas documentadas

Marycruz Santos Escareño

25 de octubre del 2015

Education

Auditoria