Ingeniera en Informtica Auditoria Computacional

Gua Prctica I Auditoria Computacional

Integrantes:

Docente:

Felipe Carvajal Paulina Muoz Carlos Padilla Mitchel Videla

Arica 2 de Octubre 2012

Ingeniera en Informtica Auditoria Computacional

Por medio del siguiente se presenta el procedimiento para la captura de requerimientos 1) Pre-requisitos del usuario 1 Lo primera forma que se debe hacer es una retroalimentacin de informacin con respecto al marco del problema. 2 La segunda etapa correspondera a la del anlisis en terreno para la observacin de tiempos y desarrollo del proceso de bodega y as conocer los procesos y procedimientos anteriores. 3 La tercera forma de captura de datos correspondera a la realizacin de los medios de recopilacin de datos conocidos, tales como: encuesta, entrevista, anlisis emprico, estado del arte, observacin en terreno, entre otros. En este caso se realizaran entrevistas a personal de gerencia, administrativos y trabajadores de la bodega. 4 En cuarto lugar la utilizacin de encuestas mediante la utilizacin formato de plantillas tipo. 5 Luego de realizar todos los pasos anteriores, el ltimo paso de la captura de requerimientos correspondera a la creacin de un calendario de tareas mediantes carta Gantt para el cumplimiento de hitos en los anlisis posteriores 6 Se dejaran copias sobre la documentacin obtenida durante cada anlisis para la obtencin de datos. 7 Se deben efectuar reuniones con cada uno de los actores involucrados para tener la visin de cada uno de ellos con respeto a la problemtica. Por consiguiente documentar lo analizado. 8 Luego de las reuniones, se debe concretar una reunin con el mandante del proyecto o cliente principal y estructurar un contrato de requerimientos. El contrato de requerimientos debe sealar exactamente lo que el sistema har y a su vez tambin limites y restricciones del sistema, ya que siempre es de vital importancia sealar las cosas que el sistema no es capaz de hacer. Se debe estipular por el mismo contrato las clausulas de cancelacin del contrato, tiempos, y formas de pago que el proyecto tendr. La captura de requerimientos y los procesos que en esto involucre deben efectuarse siempre en los horarios de atencin y laborables de la empresa. Siempre y cuando sea acordado con un previo aviso de anticipacin (mnimo 24 horas). Queda estrictamente prohibido hacer procesos los das de inventario o si en algn momento se presenta algn inconveniente en el rea funcional en cuestin. 2) Anlisis funcional Luego del anlisis de los requerimientos obtenidos a travs de la aplicacin de las encuestas y entrevistas se proceder a la obtencin de procesos de negocios y posterior obtencin de requerimientos para ello se realizara:

Ingeniera en Informtica Auditoria Computacional

Lo primero dentro de esta etapa es retratar de alguna forma clara y a nivel del usuario la toma de requerimientos. Para ello se debe hacer un diagrama de casos de usos, donde se plasme los requerimientos capturados del sistema bodega. Nomenclatura para la realizacin de un diagrama de casos de uso: Los actores o monigotes debe siempre de llevar un nombre nemnico asociado, este debe ser breve, ideal una sola palabra. En caso de fuerza mayor que se deba emplear ms de una palabra se debe usar el guion bajo como separador (_). Las asociaciones deben de ser de lnea continua iniciada en punto uno (p1) a punto dos(p2). Las generalidades deben ser de lnea continua con punta de flecha en el sentido que la generalizacin apunte. Los include y los extend deben ser sealados con lnea discontinua y flecha en sentido del elemento. Se debe a su vez indicar de que tipo es por medio del smbolo <>, (<extend>, <include>). La especificacin de casos de uso se debe realizar siguiente el formato que se presenta a continuacin: Plantilla de Especificacin de casos de usos Nombre: Autor: Fecha: Descripcin: Actores: Precondiciones: Flujo Normal: Excepciones: Pos condicin:

Ingeniera en Informtica Auditoria Computacional

Por consiguiente se debe retratar la estructura de las clases para ello se debe entregar un diagrama lgico o diagrama de clases. Debe seguir la nomenclatura UML estndar, donde cada caja debe estar estructurada por: Nombre de la clase: En maysculas y lo mas nemnico a su funcin. Atributos: Debe quedar especificado todos sus atributos y sus nivele de acceso que ellos posean. Mtodos: Deben quedar especificados todos sus mtodos, el tipo y los datos que involucre. Ejemplo

Modelo fsico del sistema: con el modelado fsico debe quedar especificado la estructura y los elementos contenidos dentro de la base de datos y sus tablas. El diagrama fsico, debe ser entregado de forma clara e impresa, adems de un archivo de power designer. (no se acepta otro software de diseo). Debe quedar explicado: las claves primarias, las migraciones y los enlaces. Tal cual el modelamiento UML lo solicita y lo que la herramienta de diseo permita. Es vlido mencionar que todos los diagramas deben ser presentados impresos en dos copias de igual tenor, y un titulo que indique que tipo de diagrama es. Adems deben ser entregados los archivos de los diagramas, realizados estrictamente en power designer en un medio fsico ptico (cd o dvd). Cada diagrama debe ser entregado en un informe por separado, en donde se incluya una portada, una introduccin y descripcin del diagrama y la situacin retratada, adems de una conclusin, en la cual indique el fin de lo que retrata fielmente el diagrama. Todos aquellos requerimientos obtenidos se definirn sobre diagramas, sobre este tema el formato de diagramacin ser sobre una sola herramienta para plasmar el anlisis que ser power designer.

Ingeniera en Informtica Auditoria Computacional

3) Anlisis orgnico pre programacin / programacin En esta etapa se deber determinar: Equipos ajenos o propios que se utilizaran en el desarrollo Lenguaje de desarrollo Determinacin de guardado y de informes Nomenclatura Procedimiento Gestor de base datos nombre El grupo desarrollador al inicio ya realizo el anlisis y estudios de factibilidades, por lo tanto sabe los elementos y recursos con los cuales el rea de bodega cuenta. As tambin los conoce en particular el rea funcional de informtica de la empresa. Por ello se propone desarrollar el sistema en el lenguaje de programacin php. El sistema debe ser hosteado en un servidor propio que tiene suscrito la empresa, al cual se accede desde un acceso directo ubicado en la parte inferior derecha, de la pagina web corporativa. Este acceso directo despliega una intranet, en la cual se debe mostrar el ingreso al sistema de bodega. Se sugiere un host externo y web, debido a que la base de datos si bien es nica, debe ser accedida de varias bodegas que la misma empresa tiene, de esta forma todos tienen acceso a los datos en el momento que se requieran. Se enuncia que no se pueden cambiar los datos de acceso a servidor, puesto con estos mismo datos se harn los respaldos de la base de datos y por cierto se tiene acceso a los otros sistemas de la empresa. A su vez, cada vez que se desee subir una versin del software debe ser coordinado y realizado en conjunto con el rea de informtica de la empresa. 4) Plan de Pruebas Se llevara a cabo el plan de prueba denominado caja negra el cual estudia al sistema de bodega desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce. Con esto se debern de definir:

Alcance: Para cada caso de prueba, lo identificaremos con el sufijo SD, y el nmero de la prueba que estamos realizando al mdulo

Por ejemplo: Registro de Usuario: SD001. Adems se incluir la fecha, versin de prueba y estrategia.

tems a probar: Se deben de definir cules sern los tems que se evaluaran.

Ingeniera en Informtica Auditoria Computacional

Estrategia Objetivo Tcnica Categorizacin de la configuracin Suspendido Repetido Culminado Tangible Recursos Software Hardware

Las pruebas funcionales se debern realizar siguiente el formato presentado a continuacin.

Pruebas Funcionales Caso de Prueba: Nombre del proceso al cual se le har la prueba. ID: Nmero que se le asigna a la prueba. Versin de Prueba: Versin que corresponda la prueba. Fecha de Prueba: Fecha en la que se realiza la prueba. Estrategia: Caja Negra Datos de Entrada Ejemplo: Campo Rut Datos Incorrectos Azxcv Datos Correctos 12345678-9

Luego se deben de redactar los pasos a seguir en la prueba Pasos a seguir: Ejemplo: (registrarse) 1. Entrar al sistema 2. Men horizontal / Registrarse

Ingeniera en Informtica Auditoria Computacional

3. Click en Registrarse 4. Llenar los campos correctamente 4.1.1.Ingresar Rut 4.1.2.Ingresar Nombre 4.1.3.Ingresar Apellido Paterno 4.1.4.Ingresar Apellido Materno 4.1.5.Ingresar Direccin 4.1.6.Ingresar Fono 4.1.7.Ingresar Contrasea 4.1.8.Repetir Contrasea 4.1.9.Ingresar Email 4.1.10. Click Botn Registrar 5. Usuario registrado

Respuesta Esperada (en el caso del registro) Si el ingreso de los datos en los campos es correcto, se mostrar por pantalla y se podr realizar lo necesitado. De ingresar los datos en forma incorrecta, se desplegar un mensaje indicando que el dato ingresado no es vlido. Si no se ingresa ningn dato o algn campo queda vacio y se hace click en el botn ingresar, aparecer un mensaje indicando el campo est vacio y se deber completar correctamente para continuar con el proceso.

Ingeniera en Informtica Auditoria Computacional

5) Entrega a explotacin manuales y marcha blanca correccin de errores Documentacin Interna Son los comentarios o mensaje que se aaden al cdigo fuente para hacer ms claro el entendimiento. Este tipo de comentarios se mantendrn actualizados conforme se desarrolle el cdigo del sistema, tratando siempre de ser lo ms clara y concisa posible, sin caer en descripciones obvias o innecesarias. Los comentarios deben decirnos qu es lo que hace el programa, para qu sirven las variables (cuando se requiera) y explicar las partes crticas o confusas del programas. Dentro de la documentacin se pueden distinguir, bsicamente, dos tipos de comentarios: Inicial o de prlogo y descriptiva, en ambos casos el formato usado ser siempre //. Todo cdigo activo en el servidor tendr un encabezado, el cual deber estar en comentario multilnea y contendr la siguiente informacin: Ejemplo Grupo Nombre del Proyecto Versin del archivo Fecha en que se inici el archivo ltima fecha de modificacin Descripcin Un ejemplo de lo anterior: <?php /* * Grupo 6 * Sistema de Apoyo * Version: 1.0 * * Iniciado: 11 / 09 / 2012 * Modificado: 30/ 09 / 2012 * Descripcin: Funciones generales utilizadas en todo el sitio.

Ingeniera en Informtica Auditoria Computacional

* */ ... resto del archivo ?> 1.1 Inicial Este tipo de comentarios se realizara siempre principio de cada programa o subprograma. La descripcin inicial incluir, el nombre del autor, la versin del programa (de acuerdo a la notacin indicada anteriormente), una breve descripcin de lo que hace, el nombre del supervisor a cargo 1.2 Descriptiva Los comentarios descriptivos se insertan dentro del cdigo para explicar algn trozo complicado de ste. Se aplicara para describir las porciones de cdigo que no sean obvias, tales como la tarea de un determinado ciclo, funcin o procedimiento, siempre respetando la indentacion del cdigo y al inicio de lo que se desea explicar, tratando de ser lo ms breve pero a la vez descriptivo posible.

Ingeniera en Informtica Auditoria Computacional

Estructuracin de Almacenamiento de Fuentes La estructuracin para el almacenamiento de fuentes ser de una forma ordenada y coordinada en carpetas, para que se pueda tener un fcil acceso a los cdigos fuente del sistema y modificarlos en caso que sea necesario. La estructuracin tendr la siguiente presentacin: c:\ Bodega \php c:\Bodega \php\imagenes c:\ Bodega \php\flash c:\ Bodega \php\frame c:\ Bodega \php\estilo c:\ Bodega \php\index c:\ Bodega \php\registro c:\ Bodega \php\login c:\ Bodega \php\reporte