[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
16 DE OCTUBRE DEL 2015
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: Reunión de Apertura Reunión de Cierre Marycruz Santos Escareño Fecha:18/septiembre/2015 Fecha: 18/septiembre/2015 Auditores: Alcance: Este procedimiento es aplicable al sistema de Héctor Daniel Hernández Zapata gestión de la calidad para verificar por medio de auditorías Daniel Torres Salas Marycruz Santos Escareño 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 Determinación del alcance de la auditoria Estudio de importantes
los
Auditor
Daniel Torres Salas
documentos Héctor Daniel Hernández Zapata
Auditado
Jefe de oficina de control interno Jefe administrativo
Acordar el itinerario o programa deMarycruz Santos Escareño Jefe de oficina de control auditoria interno Preparación de listas de Héctor Daniel Hernández Zapata comprobación o cuestionarios
Jefe de oficina de control interno
Realizar auditoria
Daniel Torres Salas
Realizar informe de auditoria
Marycruz Santos Escareño Jefe de oficina de control interno
Personal del área de desarrollo, red física y red lógica
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 2
3
6
Se debe Comprobar que : Exista una orden de aprobación del proyecto por un órgano competente.
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.) Se le ha comunicado al director del proyecto su nombramiento junto con la información relevante del proyecto.
7
Se ha catalogado y dimensionado el proyecto según las normas establecidas.
9
Se ha elegido el ciclo de vida más adecuado al tipo del proyecto de que se trata.
SI
NO
Observaciones Se autorizó el proyecto por el profesor encargado de la práctica, pero no una orden de aprobación física No existe documento de aprobación
No existe una designación 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 ningún estándar de calidad No se cuenta con un ciclo de vida del proyecto
“Auditoria De La Fase De Análisis”
Objetivos
1 2
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
Se debe Comprobar que :
SI
NO
Existe un documento determinan formalmente el grupo de usuarios que participaran en el proyecto.
12 Existe el catálogo de requisitos que están 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 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
Observaciones No existe el documento Mostro el documento de especificación de requerimientos pero no están justificados Los requisitos son concretos No se cuenta con la clasificación de requisitos 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.
3
Se debe Comprobar que : Se han documentado todas las actividades físicas que debe realizar el sistema.
6
Existe el documento con el diseño de la estructura modular del sistema
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.
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. 12 Tiene en cuenta el entorno tecnológico y los requisitos de rendimiento
13 Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto. 14 Se realizaron pruebas unitarias del sistema desarrollado 15 Se realizaron pruebas modulares al sistema desarrollado
SI
NO
Observaciones Si se realizaron las actividades pero no está documentas Se mostró el documento con los prototipos de los módulos de la aplicación La descripción 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 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:
3
Se han preparado los procedimientos de copia de seguridad.
4
Se han preparado los editores, compiladores, herramientas, etc. Necesarios.
9
Están definidos los distintos perfiles de usuario requerido para la implantación y explotación del nuevo sistema.
10 Se han desarrollados todos los componentes y 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
Si
No
Observaciones No se tienen procedimientos de seguridad Si se han preparado Si están definidos los usuarios de la aplicación Se desarrollaron los módulos Se programó basándose en una herramienta que utiliza bloques de código 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.
“App
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 1
Si
No
Observaciones
Ingreso de los datos al sistema de
La aplicación no realiza
información en funcionamiento
algunos procesos acorde a los archivos o información que contiene el sistema
2
3
Las funciones de salida de
La aplicación arroja los
información
resultados correctos
El ingreso de los datos, la
La aplicación cuenta con
aplicación 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
4
Al ir ingresando los datos el
La aplicación procesa la
sistema debe ir comparando con
petición el usuario y le
los registros de archivos maestros
arroja la información
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 aplicación cuenta con las validaciones para que solo ingresen datos tipo texto
6
La aplicación no debe permitir que
El usuario solo puede
los datos de los archivos maestros
interactuar con la
puedan ser borrados del sistema
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
La aplicación 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 erróneas o
La aplicación aún no
incompletas
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
La aplicación no
interacciones del usuario después
funciona en su totalidad
de un proceso
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
Versión: 01
INFORME DE AUDITORÍA Fecha de 01/10/2015
Proceso: Desarrollo y funcionalidad de Software
emisi n: Fecha de versión: 16-102015
Sección No.1 DATOS GENERALES DE LA AUDITORÍA Procesos Responsable del proceso Auditoria de Desarrollo y funcionalidad de Software Fecha de apertura 01/10/2015
Fecha de cierre 16/10/2015 Auditores
Auditor líder:
Marycruz Santos Escareño
Marycruz Santos Escareño Fecha elaboración informe Tipo de auditoría 12/08/2015 Auditoria Informática Auditados Daniel Torres Salas Héctor Daniel Hernández Zapata
Daniel Torres Salas 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. 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 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 Proceso: Desarrollo y funcionalidad de Software
Fecha de 01/10/2015
Versión: 01
emisi n: Fecha de versión: 16-102015
Sección No.3 VALIDACICIÓN DEL INFORME Nombre: Fecha: Firma
AUDITOR Marycruz Santos Escareño 12/08/2015
Marycruz Santos Escareño
Nombre:
AUDITADO Daniel Torres Salas
Fecha: 12/082015 Firma Daniel Torres Salas
Versión: 01
INFORME DE AUDITORÍA Proceso: Desarrollo y funcionalidad de Software
Fecha de 01/10/2015
emisi n: Fecha de versión: 16-102015
Sección No.4 FICHA DE RESUMEN DE LA AUDITORIA NO CONFORMIDADES
Numeral
REQUISITOS DEL SISTEMA
No. No. No. Detectadas Solucionadas Pendientes NCM Ncm NCM
1.
Ncm NCM Ncm
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 Plan de Comunicación
1
0
0
0
1
0
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
1.8
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
INFORME DE AUDITORÍA Proceso: Desarrollo y funcionalidad de Software
3 3.1
4
Fecha de 01/10/2015
Versión: 01
emisi n: Fecha de versión: 16-102015
DISEÑO 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
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ódi o
0
1
0
0
0
1
4.5
De uración de Códi o
5
0
0
0
5
0
4.6 4.7
Módulos Funcionales Plan de pruebas
8 1
0 0
0 0
0 0
2 1
0 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:
INFORME DE AUDITORÍA Proceso: Desarrollo y funcionalidad de Software
Fecha de 01/10/2015
Versión: 01
emisión: Fecha de versión: 16-102015
Sección 5. TRATAMIENTO DE NO CONFORMIDADES Descripción de la no conformidad
No conformidad
Corrección propuesta (acción inmediata)
Causa Raíz
□ Menor: □ Mayor:
No se cuenta con ningún tipo de seguridad proyecto
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.
□ Menor: □ Mayor:
No se desarrolló un plan de riesgos
Requisito:
□ Menor: □
Elaborar plan de riegos.
No se llevo una adecuada documentacion del proyecto
Plan de acción correctivo Actividad: Elaborar medidas de seguridad para el sw. Fecha: 25/10/2015
Requisito:
Inicial
Aprobada:
□ Rechazada:□
Fecha: 25/10/2015 Seguimiento
Actividad: Implementar estas medidas de seguridad. Fecha:20/10/2015
Abierta: □ Cerrada:□ Fecha: 25/10/2015
Actividad: elaborar un plan de gestion de riesgos. Fecha: 25/10/2015
Inicial
Actividad: identificar los posibles riesgos y como contrarrestarlos Fecha: 25/10/2015
Aprobada:
□ Rechazada:□
Fecha: 25/10/2015 Seguimiento
Abierta: □ Cerrada:□ Fecha: 25/10/2015
Inicial
Mayor: No se cuenta con un plan de trabajo, ni se baso el Proyecto en un ciclo de vida
Estado
Aprobada:
□ Rechazada:□ Utilizer el diagrama de Gantt asignando y valorando el tiempo estimado a las actividades a desarrollar.
Actividad: crear el Se carece de información 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
INFORME DE AUDITORÍA Proceso: Desarrollo y funcionalidad de Software
Fecha de 01/10/2015
Versión: 01
emisi n: Fecha de versión: 16-102015 Inicial
No se cuenta con la aprobacion del proyecto ni el nombramiento del director del proyecto.
□ Menor: □ Mayor:
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
Requisito:
Fecha: 25/10/2015 Actividad: crear el nombramiento como evidencia S e g u i m i e n t o Abierta: □ Fecha: 25/10/2015 Cerrada:□ Fecha: 25/10/2015
Inicial
Mayor:
Algunos modulos del Sistema no cumplen con la function deceada.
Aprobada:
□ Rechazada:□
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
Aprobada:
□ 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 reunión: reunión de cierre de auditoria
ssenca
umero
ar c pan es
o
1
Marycruz Santos Escareño
*
2
Daniel Torres Salas
*
3
Hector Daniel Hernandez Za ata
*
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 2.- Terminar la funcionalidad de la totalidad de los módulos 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 Escareño
25 de octubre del 2015
