PART IV: DISCUSSION AND EVALUATION OF THE STUDY
11. REFLECTIONS ON THE RESEARCH PROCESS AND EVALUATION OF THE
Login
El operario deberá ingresar el Usuario y Password para poder acceder al sistema móvil Relima lo cual llevará a la página de entrada al sistema llamado Información del sistema.
Información del sistema
Al ingresar se visualizará el APK identificador del equipo que se genrerará al momento de instalar la aplicación en el móvil será enviado y registrado en la Base de Datos.
Mapa
El Sistema contará con una visualización de localización del usuario para información y guía del operario.
Detalle de órdenes de recolección
Este menú permitirá enviar la información requerida para el detalle de los viajes del servicio de recolección, este módulo se dividirá en cuatro formularios de ingreso de datos para comodidad y facilidad del operario. Reporte de Paradas
En esta ventana el operario ingresará el problema que ha tenido y el tiempo que podría demorar la parada que tomaría el vehículo para realizar los ajustes de tiempo que sean convenientes.
Auxilio mecánico
En esta ventana el operario podrá mandar una llamada de auxilio que será envida al correo del responsable de turno aparte de ser registrada en el sistema, se escribirá el problema ocurrido y se podrá adjuntar una foto del problema si fuese necesario.
Menús
Un menú será mostrado al presionar el menú del dispositivo que permitirá navegar por las partes del sistema y podrá ser llamado en todas la ventanas del sistema menos el login.
Procesos Background
Mientras exista una orden asignada al dispositivo se mandará las actualizaciones de posición del equipo pasando un determinado tiempo o si se el operario se mueva determinados metros.
5.9. Cronograma de actividades Leyenda Descripción Referencia Oscar De Piérola OP Miguel Flower MF Peter Paucar PP Valeria Gómez VG ACTIVIDADES 2011 2012
Setiembre Octubre Noviembre Diciembre Enero
S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 Levantamiento de información y definición de requerimientos. OP MF VG PP OP MF VG PP Creación de la base de datos y desarrollo de prototipos y plan de pruebas. OP MF VG PP OP MF VG PP Creación de Ventana Login MF VG Programación de Login MF VG Pruebas de Login MF VG Desarrollo de interfaces del módulo de Mantenimientos MF VG MF VG Programación de Módulo de Mantenimientos MF VG MF VG Pruebas de Módulo de Mantenimientos MF VG MF VG Desarrollo de interfaces del módulo de Programación Vehicular MF VG MF VG Programación de Módulo de Programación Vehicular MF VG MF VG Pruebas de Módulo de Programación Vehicular MF VG MF VG Desarrollo de interfaces del módulo de Recolección MF VG MF VG MF VG
Programación de Módulo de Recolección MF VG MF VG MF VG Pruebas de Módulo de Recolección MF VG MF VG MF VG Desarrollo de reportes MF VG MF VG Creación de Web Services OP PP Creación de base de datos Interna de Aplicación Móvil OP PP Desarrollo de todas las Interfaces OP PP OP PP Programación de Login OP PP Pruebas de Login OP PP Programación de Módulo de Ordenes de Recolección OP PP OP PP Pruebas de Módulo de Ordenes de Recolección OP PP OP PP Programación de Módulo de Mapa de Geolocalización OP PP Pruebas de Módulo de Mapa de Geolocalización OP PP Programación de Módulo de Auxilio Mecánico y envío de mensajes OP PP OP PP Pruebas de Módulo de Auxilio Mecánico y envío de mensajes OP PP OP PP Programación de Módulo de Justificación de Parada OP PP Prueba de integración de módulos de los sistemas OP MF VG PP Implementación de Sistema Web y Móvil en Relima OP MF VG PP Seguimiento y mantenimiento de sistema implementado OP MF VG PP
5.10. Estándares de programación
Propósito Guía para desarrollo del programa
Cabecera del
programa Comenzar todos los programas con una cabecera descriptiva
Formato de cabecera
/*--- Cabecera--- ---
Nombre Programa: Nombre del programa Nombre: Nombre del programador
Fecha : Fecha de creación del Programa dd-mm-yyyy Descripción: Descripción del programa
Versión: Versión del programa v.1.00
--- ---*/
Lista de
contenido Provee un resumen del contenido
Ejemplo de contenido
/*--- Lista de Contenidos--- ---
Declaración de constantes
Declaraciones de variables publicas Declaraciones de variables privadas Constructores Propiedades Métodos públicos Métodos privados --- ---*/ Instrucciones de reuso
Describe como el programa es usado. Provee un formato para las declaraciones, parámetros, valores, tipos y límites de los parámetros.
Provee advertencias de valores ilegales, sobrecarga de condiciones, u otras condiciones que podrían potencialmente resultar en operaciones impropias del programa.
Ejemplo de reuso
Instrucción aplicada para: Cálculo Matemático. Propósito: Dividir dos números.
Límites: No se debe dividir entre 0.
Contingencias: Se mostrara un mensaje de advertencia detallando el error ocurrido.
Identificadores Uso descriptivo de los nombres de todas las variables, nombre de
funciones, constantes y otros identificadores.
Ejemplo de identificadores
Todos las variables serán declaradas en minúscula y no debe usarse abreviaciones o variables de una sola letra.
Ejemplo
String descripción ;
/*Los métodos serán declarados con el prefijo “m” seguido de underline y el nombre del método como se ve en el siguiente ejemplo: */
m_metodo(){…}
Comentarios
Documentar el código para que sea legible y entendible con respecto a la operación.
Los comentarios deberían explicar el comportamiento y propósito del código.
Buen comentario
Al principio de cada método se escribirá un comentario describiendo la funcionalidad.
Los comentarios deberán ser escritos de la siguiente forma: /*Buen comentario*/
Public void m_insertar() { }
Mal comentario
El comentario no debe estar en la misma línea que la instrucción. Public void m_insertar() { /*Mal comentario*/
}
Secciones mayores
Precede a programa de mayor envergadura por un bloque de comentarios que describe el proceso que se ha hecho en la siguiente sección
Ejemplo /*_______________________________ Declaración de Constantes _________________________________*/ /*_________________________________ Declaración de Propiedades _________________________________*/
Espacios en blanco
Escribir programas con suficiente espacio para que no aparezca conglomerado.
Separar cada constructor del programa con al menos un espacio.
Sangría Identificar cada nivel de las llaves entre una y otra.
Ejemplo de sangría int ix = 1; while (ix > 10) { if (ix == 0) {} } Clases
/* La primera letra será en mayúscula , en singular y el nombre de la clase estará relacionada con el contenido*/
Ejemplo :
Para una clase relacionada con productos Producto
Paquetes
/*El formato del nombre de los paquetes se usará de la siguiente manera:*/
Ejemplo:
5.11. Plan de pruebas
Propósito
Este documento describe el plan para probar las funcionalidades y características del los sistemas para la empresa Relima en sus distribuciones Web y Móvil. Este documento está basado sobre los siguientes objetivos:
Identificar que la información existente del proyecto y los componentes de software sean probados.
Listar los requerimientos recomendados de prueba.
Recomendar y describir las estrategias a ser empleadas.
Identificar los recursos requeridos y estimar los esfuerzos de las pruebas.
Listar los elementos a entregar de las actividades de pruebas.
Alcances
Este plan de pruebas aplica para la las pruebas unitarias del sistema bajo la forma de caja negra en concordancia a lo requerido por el cliente.
Requerimientos de pruebas
La lista que prosigue este párrafo identifica aquellos elementos que han sido identificados como objetivos de las pruebas. Esta lista representa lo que será probado. Los detalles de cada prueba serán determinados posteriormente mientras los casos de prueba sean identificados y los scripts sean desarrollados.
Pruebas de integridad de datos y BD
Verificar el acceso a la BD de Relima.
Verificar el acceso simultáneo en la lectura de registro de las distintas tablas.
Verificar el bloqueo realizado durante actualizaciones de registros de las tablas transaccionales
Verificar la correcta obtención de data actualizada.
Pruebas del sistema
Las pruebas del sistema estarán divididas en dos bloques distintos uno destinado para el sistema Web y el otro para el Móvil.
Sistema Web Verificar: Login/Logout al sistema. Mantenimiento de clientes. Mantenimiento de regiones. El mantenimiento de servicios.
El mantenimiento de tipos de residuos.
El mantenimiento de prefijos.
El mantenimiento de vehículos.
El mantenimiento de sector.
El mantenimiento de dispositivos móviles.
La asignación de dispositivos.
El listado de programación de fichas de control.
La importación de programación vehicular.
Registro de fichas de control de recolección.
Generación de reportes.
Configuración de importación de documentos.
La gestión de contraseñas. Sistema Móvil
Verificar:
Login al sistema.
Funcionamiento de los menús.
Registro de detalle de recolección.
Auxilio mecánico.
Reporte de paradas.
Funcionamiento del mapa con GPS. Pruebas de la interfaz de usuario
Verificar la facilidad de navegación mediante un ejemplo de pantallazos de las funcionalidades.
Verificar que los pantallazos de ejemplo cumplan estándares de GUI. Pruebas de desempeño
Verificar el tiempo de respuesta para acceder a la aplicación.
Verificar el tiempo de respuesta para el proceso de reportes.
Pruebas de carga
Verificar la respuesta del sistema cuando tiene 10 usuarios accediendo al sistema.
Pruebas de stress
Verificar la respuesta del sistema cuando tiene 10 peticiones de reportes filtrados por un mes.
Pruebas de volumen
Verificar el tiempo de respuesta cuando la tabla Recolección cuente con 10000 registros.
Estrategia de pruebas
La estrategia de pruebas presenta el alcance recomendado para la prueba de aplicaciones de software. La sección previa a los requerimientos de pruebas describe que será probado.
Tipos de pruebas
Las consideraciones principales para la estrategia de pruebas son las técnicas a usarse y los criterios para determinar si la prueba fue completada.
Además de las consideraciones provistas para cada prueba mencionada, las pruebas deberían ser únicamente ejecutadas usando bases de datos conocidas y controladas en entornos seguros.
o Pruebas de integridad de datos y BD
La base de datos y los procesos de bases de datos deberían ser probadas en sistemas separados. Estos sistemas deberían ser probados sin la aplicación Relima Web (como interface a la data). Revisión exhaustiva sobre el gestor de base de datos a usarse necesita ser realizada para identificar las herramientas y técnicas que puedan existir para soportar las pruebas a realizarse.
Objetivo
Asegurar que los métodos de acceso y los procesos funcionen apropiadamente y sin corrupción de datos.
Técnicas
Invocar cada método de acceso a la BD, intentando con datos válidos e inválidos.
Inspeccionar la base de datos para asegurar que la data ha sido poblada como se esperaba, que todos los eventos ocurran apropiadamente, o revisar la data retornada para asegurar que la data correcta fue obtenida.
Criterio de cumplimiento
Todos los métodos de acceso a la base de datos y procesos funcionan como fueron diseñados y sin corrupción de datos.
o Pruebas del sistema
Las pruebas sobre la aplicación deberían enfocarse en requerimientos que puedan ser asociados directamente a casos, y reglas del negocio. Las metas de estas pruebas son verificar la aceptación, el procesamiento y obtención de data apropiada, así como la apropiada implementación de reglas del negocio. Este tipo de pruebas está basado en las técnicas de caja negra, utilizando para ello la GUI y analizando los resultados.
Objetivo
Asegurar la navegación apropiada en la aplicación; el correcto ingreso de datos, procesamiento y obtención.
Técnicas
Ejecutar cada módulo planteándose el flujo correspondiente de las acciones que debería realizar teniendo en cuenta los diferentes caminos que puede tomar una acción como al ingresar data errónea que es lo que pasaría, si muestra los respectivos mensajes a la hora de ingresar datos, todo esto será plasmado en un documento que buscará facilitar la verificación de estos y dará a conocer su resultado.
Criterio de cumplimiento
Todas las pruebas planificadas fueron ejecutadas
Todos los defectos de pruebas han sido manejados.
El cliente ha estado conforme con los procesos. o Pruebas de la interfaz de usuario (IU)
Verifica la interacción del usuario con el software. La meta de las pruebas de IU es asegurar que la interfaz de usuario provea al usuario el acceso apropiado para acceder y navegar por las funciones de la aplicación. Además, las pruebas IU asegura que los objetivos dentro de la IU funcionen como se esperaba y conforme a los estándares de la compañía.
Objetivo
Verificar:
a) La navegación por la aplicación refleje propiamente las funciones y requerimientos;
b) los objetos de ventanas y sus características, como menús medidas posición, estado y foco sea conforme a lo esperado.
Técnicas
Crear modificar las pruebas para cada ventana para verificar apropiadamente la navegación y los estados de los objetos para cada ventana y objeto de la aplicación.
Criterio de cumplimiento
Cada ventana fue verificada exitosamente y aprobada por el cliente. o Pruebas de desempeño
Realizar las pruebas que miden los tiempos de respuesta, las tasas de transacción y otros requerimientos sensibles al tiempo. La meta de las pruebas de desempeño es verificar y validar que los requerimientos de desempeño han sido alcanzados. Este tipo de pruebas es ejecutado muchas veces.
Objetivo
Validar el tiempo de respuesta para transacciones diseñadas o funciones de negocio bajo las siguientes condiciones:
a) Volumen normal anticipado, b) Volumen de caso mal anticipado.
Técnicas
Usar scripts de carga masiva de datos.
Lo scripts deben correr en una sola máquina y debe verse el funcionamiento del sistema en otras máquinas para ver si afecta está el rendimiento.
Criterio de cumplimiento
Una transacción / un único usuario. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran fallas en los tiempos esperados o requerido
Múltiples transacciones / múltiples usuarios. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran fallas en los tiempos aceptables.
o Pruebas de carga
Las pruebas de carga miden las situaciones en las que el sistema se somete a variaciones en su carga de trabajo para evaluar la habilidad del sistema para continuar funcionando adecuadamente, más allá de la carga de trabajo esperada. Adicionalmente, las pruebas evalúan las
características de desempeño (tiempos de respuestas, tasas de transacción y otros problemas sensibles a tiempos).
Objetivo
Verificar el tiempo de respuesta del sistema para transacciones diseñada o casos de negocio bajo condiciones de carga de trabajo variada.
Técnicas
Pruebas de uso desarrolladas para ciclos de prueba de negocio.
Modificar archivos de datos (incrementando el número de transacciones) o las pruebas para incrementar el número de veces en que una transacción ocurre.
Criterio de cumplimiento
Múltiples transacciones / múltiples usuarios. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran fallas en los tiempos aceptables.
o Pruebas de stress
Las pruebas de stress intentan encontrar errores debido a bajos recursos o competencia por recursos. La baja memoria o espacio del disco pueden revelar defectos en el software que no aparecen bajo condiciones normales.
Objetivo
Verificar que el sistema y el software funcionan apropiadamente y sin errores bajo las siguientes condiciones de stress:
Poca o sin memoria disponible en el servidor.
Máximo (actual o físicamente capaz) número de clientes conectados o simulados.
Múltiples usuarios realizando las mismas transacciones contra los mismos datos o cuentas.
Técnicas
Pruebas de uso desarrolladas para las pruebas de desempeño.
Criterio de cumplimiento
Probar recursos limitados, las pruebas debería correr sobre una sola máquina, y la memoria RAM en el servidor debería ser la mínima esperada.
temporalmente reducido para restringir el espacio disponible para que la base d datos crezca.
o Pruebas de volumen
Determina si el sistema puede trabajar con grandes cantidades de datos, indicando cuando los límites son alcanzados lo que causaría que el software falle.las pruebas de volumen además identifican las cargas continuas de carga o el volumen que el sistema puede manejar por un tiempo dado.
Objetivo
Verificar que la aplicación funcione exitosamente bajo los siguientes escenarios de gran volumen:
Máximo número de clientes conectados, todos realizando la misma funcionalidad de negocio con el peor caso (de desempeño) por un periodo largo de tiempo.
Tamaño máximo de la BD ha sido alcanzado y múltiples transacciones de consultas y reportes son ejecutados simultáneamente.
Técnicas
Las pruebas de uso desarrolladas para las pruebas de desempeño.
Múltiples clientes deberían ser usados, bien corriendo las mismas pruebas o pruebas complementarias para producir la transacción del peor caso de volumen por un periodo extendido.
Máximo tamaño de la base de datos es creado y múltiples clientes lo usan para ejecutar consultas y reportes simultáneamente por un periodo extendido.
Criterio de cumplimiento
Todas las pruebas han sido ejecutadas y los límites del sistema son alcanzados/excedidos sin que el software falle.
Recursos
Trabajadores
La siguiente tabla muestra las personas asignadas para el equipo de pruebas:
Rol Responsables
Test Manager Miguel Flower
Diseñador de pruebas Oscar De Piérola José Luis Apaza
Tester
Peter Paucar, Valeria Gómez, Miguel Flower, Oscar De Piérola
Administrador BD Miguel Flower
Sistema
Se requieren la siguiente configuración del sistema:
Tres computadoras virtuales (con el software Virtual Box) corriendo Windows Server 2003
Los servidores tendrán lo siguiente:
Memoria RAM 1028 MB.
Internet Explorer 8 y Firefox 9.
IIS levantado y configurado para levantar el sistema bajo un acceso directo.
Emulador Android con el sistema operativo 2.2 Froyo con el sistema ya pre cargado.
Entregables
Plan de pruebas
El plan definirá todos los casos de prueba y los resultados esperados, los cuales serán asociados a cada caso de prueba.
Registros de pruebas realizadas
Servirá para identificar los casos de prueba y hacer seguimiento del estado de cada caso de prueba. Los resultados de las pruebas serán resumidos posteriormente antes de probar, probados, probados condicionalmente o fallidos. En suma, se tendrán los siguientes atributos por cada prueba
Estado de la prueba
Número de la versión probada
Persona que realizó la prueba
Fecha y hora de la prueba
Notas y observaciones de la prueba
Será responsabilidad del Tester actualizar el estado de la prueba en los registros. Los resultados de las pruebas serán guardados bajo un control de versiones.
Reportes de defectos
En caso de detectarse un defecto se deberá documentar dando a conocer el módulo el que presente las pruebas, las condiciones de hardware y/o navegador usados los cuales serán almacenados en un formato Excel bajo la siguiente plantilla:
Nombre de documento:
RP_(módulo_afectado)_(nombre_del_tester)_(fecha_de_prueba).
Cuerpo del documento:
- Nro. de prueba - Tipo
- Tarea
- Escenario a probar - Ítem a probar
- Descripción del Caso de Prueba - Descripción de los pasos
- Datos de entrada - Resultado Esperado - Resultado Real - Estado de la prueba - Estado del error - Tester responsable, - Fecha prueba.
5.12. Base de datos 5.12.1. MER
5.12.2. Diccionario de datos
TM_VEHICULO
CAMPO TIPO DE
DATO LONGITUD INTEGRIDAD DESCRIPCION
COD_VEHICULO VARCHAR2 8 PK Código único de la tabla
vehículo
COD_PREFIJO VARCHAR2 3 FK Define los tipos de vehículo
COD_CLIENTE VARCHAR2 5 FK Código único de la tabla
referenciada cliente
PLACA_VEHICULO VARCHAR2 10 Placa del vehículo
IDENT_CREA VARCHAR2 15 Usuario que realiza el
registro
FEC_REG DATE Fecha en que se inserta el
registro
FLG_ESTADO NUMBER Estado de actividad
TM_USUARIOS
CAMPO TIPO DE
DATO LONGITUD INTEGRIDAD DESCRIPCION
COD_USUARIO VARCHAR2 5 PK Código único de la tabla
usuario
USUARIO VARCHAR2 15 Nombre asignado al usuario
CLAVE VARCHAR2 15 Clave asignada al usuario
ROL VARCHAR2 10 Rol del usuario
EMPLEADO VARCHAR2 80 Nombre completo del
empleado
OBSERVACION VARCHAR2 80 Comentario sobre el usuario
IDENT_CREA VARCHAR2 15 Usuario que realiza el
registro
FEC_REG DATE Fecha en que se inserta el
registro
FLG_ESTADO NUMBER Estado de actividad
SUCURSAL VARCHAR2 20 Sede donde opera el usuario
TM_TIPO_RESIDUO
CAMPO TIPO DE
DATO LONGITUD INTEGRIDAD DESCRIPCION
COD_RESIDUO VARCHAR2 3 PK Código único de la tabla