You are on page 1of 96

DESARROLLO DE SISTEMA WEB Y MVIL PARA EL CONTROL DE PROCESOS DEL REA OPERACIONAL EN LA EMPRESA RELIMA AMBIENTAL S.A.

INTEGRANTES:

Oscar Alessandro De Pirola Ardela Miguel ngel Flower Andrade Rosanna Valeria Gmez Pineda Peter Walter Paucar Rodrguez

2012

DEDICATORIA

Dedicado a los alumnos de la promocin de la carrera de Sistemas e Informtica Promocin 2012, a nuestros seres queridos por el apoyo, a nuestros profesores que en estos tres aos de enseanza y apoyo, nos ensearon a enfrentar los problemas de negocios con la calidad y eficiencia que se necesita. A Dios, por permitirnos el suficiente entendimiento para llegar a este punto de la vida, por conceder salud para disfrutar estos momentos y conciencia para discernir lo bueno que hemos recibido. A todos, por el momento en que las palabras fueron suficientes para expresar lo que el alma desea, simplemente queda decir aquello que por si significado extenso y sin lmites es, Gracias.

Pgina 2

INTRODUCCIN

El presente proyecto titulado Desarrollo de Sistema Web y Mvil para el control de procesos del Arrea Operacional en la empresa relima ambiental S.A. dar a conocer las funciones que realiza el rea en mencin en la empresa Relima Ambiental S.A., as como tambin el desarrollo del Sistema Operacional para resolver las incidencias que se vienen presentando.

En la actualidad Relima Ambiental S.A. presenta una serie de problemas en el rea de Control Operacional relacionada con la informacin histrica de los viajes que realizan los vehculos en sus respectivos turnos y servicios, el estado de sus trabajadores, la necesidad de tener informacin solicitada en tiempo real y el control de pesaje de los camiones de recoleccin.

El Sistema Operacional resolver las incidencias mencionadas realizando modificaciones y actualizaciones. Se migrar el sistema desktop, con el que actualmente trabajan, a un sistema web para agilizar los procesos de recoleccin y servicios generales.

Pgina 3

ndice

1.

CAPTULO I: GENERALIDADES DEL PROYECTO ...................................................................... 6 1.1. Situacin Problemtica ................................................................................................. 6 Problema ............................................................................................................... 6 Hiptesis ................................................................................................................ 6

1.1.1. 1.1.2. 1.2.

Alcance .......................................................................................................................... 6 Objetivos Generales: ............................................................................................. 6 Objetivos Especficos: ............................................................................................ 6

1.2.1 1.2.2 1.3. 1.4. 2.

Justificacin e Importancia del Proyecto ...................................................................... 7 Limitaciones .................................................................................................................. 7

CAPTULO II: DESCRIPCIN DE LA EMPRESA ......................................................................... 8 2.1. Marco Referencial ......................................................................................................... 8 Visin de la Empresa ............................................................................................. 8 Misin de la Empresa ............................................................................................ 8 Anlisis FODA ........................................................................................................ 8

2.1.1. 2.1.2. 2.1.3. 2.2. 3.

Organigrama de Relima Ambiental S.A. ...................................................................... 10

CAPTULO III: FUNDAMENTOS TERICOS ........................................................................... 11 3.1. Tecnologas Usadas ..................................................................................................... 11 Java ...................................................................................................................... 11 Visual C# .............................................................................................................. 11 Oracle 11g ........................................................................................................... 11 Android ................................................................................................................ 11

3.1.1. 3.1.2. 3.1.3. 3.1.4. 3.2.

Herramientas Usadas .................................................................................................. 12 Visual Studio 2008 Team Edition......................................................................... 12 Eclipse ndigo ....................................................................................................... 12 Toad para Oracle ................................................................................................. 12 Crystal Reports .................................................................................................... 12

3.2.1. 3.2.2. 3.2.3. 3.2.4. 4. 5.

CAPTULO IV: METODOLOGA ............................................................................................. 13 CAPTULO V: DESARROLLO DEL SISTEMA EN BASE A XP .................................................... 27 5.1. Cuadro de Reuniones .................................................................................................. 27

Pgina 4

5.2. 5.3.

Historias de usuario ..................................................................................................... 29 Cuadro de Requerimientos ......................................................................................... 32 Sistema web ........................................................................................................ 32 Sistema mvil ...................................................................................................... 33

5.3.1. 5.3.2. 5.4. 5.5. 5.6. 5.7. 5.8.

Plan de Entrega ........................................................................................................... 34 Anlisis de Costos ........................................................................................................ 34 Tarjetas de CRC ........................................................................................................... 36 Roles de Equipo ........................................................................................................... 38 Metfora del Sistema .................................................................................................. 39 Metfora del Sistema Web ................................................................................. 39 Metfora Mvil ................................................................................................... 40

5.8.1. 5.8.2. 5.9. 5.10. 5.11. 5.12. 5.12.1. 5.12.2. 6.

Cronograma de actividades......................................................................................... 42 Estndares de programacin .................................................................................. 44 Plan de pruebas ....................................................................................................... 47 Base de datos .......................................................................................................... 56 MER ..................................................................................................................... 56 Diccionario de datos ............................................................................................ 57

CAPTULO VI: MANUAL DE USUARIO .................................................................................. 67 6.1. 6.2. Manual Sistema Web .................................................................................................. 67 Manual de Aplicacin Mvil ........................................................................................ 80

7. 8. 9.

CAPTULO VII: CONCLUSIONES ............................................................................................ 89 CAPTULO VIII: LINKOGRAFA .............................................................................................. 90 CAPTULO IX: ANEXOS ......................................................................................................... 91

Pgina 5

1. CAPTULO I: GENERALIDADES DEL PROYECTO


1.1. Situacin Problemtica
La empresa Relima cuenta con un rea denominada rea Operacional, encargada de gestionar el recorrido de los vehculos recolectores y la informacin generada. Esta informacin es registrada de forma manual y almacenada en archivadores. Actualmente trabajan con un sistema de escritorio que solo contempla una parte del control de los procesos de pesaje, pero en los ltimos tiempos debido al crecimiento que ha tenido la empresa y al manejo actual de la informacin han dado como resultado incongruencia de datos, retrasos en las consultas con respecto a los recorridos e irregularidades en los tiempos trabajados por los empleados de campo. 1.1.1. Problema De qu manera el desarrollo de un Sistema Web y Mvil permitir mejorar los procesos del rea Operacional? 1.1.2. Hiptesis Mediante el desarrollo de un Sistema Web se podr tener un control sobre las rdenes de recoleccin generadas, asimismo un mejor manejo a la hora de asignacin de dichas rdenes dado que la informacin estar centralizada en una sola base de datos y se validar la data ingresada. Mediante el desarrollo de una aplicacin mvil se asistir al empleado de campo para realizar el reporte de su recorrido en tiempo real, as como tambin podr informar de cualquier incidencia que pueda ocurrir durante su transcurso.

1.2. Alcance
1.2.1 Objetivos Generales: Migracin y optimizacin del sistema actual a web con asistencia mvil para la mejoras de los procesos del rea Operacional en la empresa Relima Ambiental S.A. Objetivos Especficos: Centralizar la data de todos los mdulos creados en una sola base de datos. Optimizar el proceso de comprobacin de datos de las fichas de recoleccin. Controlar de forma ms precisa al personal durante sus recorridos mediante el uso de la tecnologa GPS que se implementar en la aplicacin mvil. Tener informacin en tiempo real. Integrar el sistema actual del pesaje en las balanzas con la informacin registrada por los empleados de campo mediante el dispositivo mvil.

1.2.2

Pgina 6

Crear un sistema web para facilitar el manejo de las asignaciones de rdenes de recoleccin a vehculos.

1.3. Justificacin e Importancia del Proyecto


Se opt por migrar el sistema actual a un sistema web ya que estos tipos de sistemas ofrecen las siguientes ventajas: Fcil mantenimiento del sistema ya que al encontrarse centralizado en comparacin al sistema actual, se evitar dar mantenimiento a cada una de las instancias instaladas. Reduccin de los requisitos de funcionamiento debido a que solo se necesitar de un explorador web para poder acceder, aparte de ser independiente del sistema operativo que se use. Flexibilidad y escalabilidad puesto que permitira adaptarse a los cambios que se presenten en el sistema de una manera rpida y sencilla.

Con el uso de una Aplicacin Mvil se le dara a los trabajadores en el campo un medio para poder reportar en tiempo real sus avances y problemas, dando como resultado un mejor control sobre los actos de los empleados en el campo y disminuira el uso de documentos fsicos para la realizacin de los reportes del recorrido.

1.4. Limitaciones
El Sistema no contemplar el mantenimiento de usuarios ni perfiles. El sistema no tendr una interfaz con el rea de RR.HH. para el ingreso de un nuevo personal. El Sistema mvil solo soportar equipos con Sistema Operativo Android. El Sistema no tendr una interfaz con el rea de Facturacin, por el hecho de generar facturas con la informacin entregada por Balanzas. Sistema no contempla el mdulo de Servicios Generales.

Pgina 7

2. CAPTULO II: DESCRIPCIN DE LA EMPRESA


2.1. Marco Referencial
Relima Ambiental S.A. es el resultado de la fusin de dos prestigiosas empresas que unen sus esfuerzos y la ms avanzada tecnologa de punta, para ofrecer un mejor servicio en el cuidado del medio ambiente con calidad y seguridad: El grupo SOLVI de Brasil, especialista desde hace ms de 35 aos en el rubro de limpieza urbana y cuidado del medio ambiente y la empresa peruana Ecovida Ambiental S.A. Durante 15 aos de trayectoria, Relima Ambiental S.A, cuenta con ms de 1500 colaboradores que se dedican al cuidado ambiental y limpieza urbana de 3 ciudades en el Per, atendiendo a 3 millones de personas.

2.1.1. Visin de la Empresa Ser una de las empresas pioneras del rubro de limpieza en la ciudad de Lima. 2.1.2. Misin de la Empresa Brindar los servicios con responsabilidad, puntualidad, seguridad, modernidad, a travs de la eficiencia y eficacia. Promover el desarrollo sostenido a favor del cuidado y preservacin del medio ambiente. Ser una empresa con uno de los mejores ambientes de trabajo, brindando capacitacin continua para el desarrollo y crecimiento de los colaboradores.

2.1.3. Anlisis FODA

Este tipo de anlisis representa un esfuerzo para examinar las interacciones entre las caractersticas particulares de la empresa y el entorno en el cual va a competir. Este anlisis puede ser usado por todos los niveles de la corporacin y diferentes unidades de anlisis como el producto, el mercado, unidad estratgica de negocios, etc. En el anlisis FODA detallaremos las fortalezas y debilidades internas comparndolas de manera objetiva y realista con la competencia y amenazas claves del entorno.

Pgina 8

Fortalezas y Debilidades

Fortalezas En qu aspectos Relima Ambiental S.A sobresale con respecto a sus competidores? Estructura flexible Posicionamiento en el rubro que se desempea Horarios flexibles en sus servicios Gran nmero de servicios ofertados

Debilidades En qu aspectos los competidores superan a Relima Ambiental S.A.? Ganar licitaciones por costos menores. Encontrar al personal adecuado

Oportunidades y Amenazas Oportunidades Cules son las mejores oportunidades que se tiene? Mercado en crecimiento Demanda no estacional Surgimiento de nuevas demandas sobre servicios de limpieza

Amenazas Cules son las mayores amenazas que se enfrenta? Elevada competencia Aumento de servicios privados por parte de las municipalidades Intrusismo en el sector

Pgina 9

2.2. Organigrama de Relima Ambiental S.A.

Pgina 10

3. CAPTULO III: FUNDAMENTOS TERICOS


3.1. Tecnologas Usadas
3.1.1. Java Es un lenguaje de programacin orientado a objetos, desarrollado por Sun Microsystems, es capaz de ser ejecutado independientemente de la plataforma gracias a la Mquina virtual de Java (JVM, Java Virtual Machine) y cuenta con IDEs de desarrollo de carcter gratuito. Este lenguaje fue utilizado en el desarrollo de la aplicacin mvil para Android ya que esta usa Java como su lenguaje para programacin pero es ejecutado en lugar del JVM a travs de su propia mquina virtual llamada DALVIK.

3.1.2. Visual C# Es un lenguaje de programacin orientado a objetos desarrollado y estandarizado por Microsoft como parte de su plataforma .NET, ha estado presente desde la versin del IDE de desarrollo Visual Studio .NET en el ao 2002 hasta la actual Visual Studio 2010. Se opt por este lenguaje para el desarrollo del Sistema Web en general y el servicio web ya que el equipo de programacin maneja ms este lenguaje.

3.1.3. Oracle 11g Es un sistema de gestin de base de datos objeto-relacional (ORDBMS, ObjectRelational Data Base Management System), desarrollado por Oracle Corporation, la versin 11g fue liberada en el 2009. Se us este motor de base de datos debido a que Relima actualmente ya cuenta con sus licencias respectivas.

3.1.4. Android Es un sistema operativo desarrollado para dispositivos mviles cuyo dueo es Google, trabaja bajo una licencia libre de desarrollo y en base al lenguaje de programacin Java. Se eligi este sistema por tener licencia de desarrollo gratuita y ser la distribucin del aplicativo directa al contrario de otros sistemas mviles que restringen la distribucin y cobran licencia por su uso.

Pgina 11

3.2. Herramientas Usadas


3.2.1. Visual Studio 2008 Team Edition Es un entorno de desarrollo integrado (IDE, Integrated Development Environment) para sistemas operativos Windows. Soporta varios lenguajes de programacin tales como Visual C++, Visual C#, Visual J#, ASP.NET y Visual Basic .NET. Este entorno de desarrollo fue elegido debido a que la empresa Relima ya contaba con la licencia sobre la plataforma.

3.2.2. Eclipse ndigo Es un entorno de desarrollo integrado de cdigo abierto multiplataforma capaz de soportar mdulos creados por la comunidad que tiene el proyecto Eclipse. Esta plataforma, tpicamente es usada para el desarrollo de aplicaciones en el lenguaje Java aunque es capaz de soportar otros lenguajes a travs de mdulos. Fue elegido este entorno por ser compatible con las herramientas de desarrollo de Android (ADT, Android Development Tools) que pueden ser encontradas en la pgina oficial de Android por ser de carcter gratuito.

3.2.3. Toad para Oracle Es una aplicacin informtica de desarrollo SQL y administracin de base de datos, considerada una de las herramientas ms tiles para los administradores de Base de datos de Oracle. Esta herramienta fue utilizada para la creacin de la base de datos en Oracle y fue elegida por brindar un entorno propicio para la creacin de la BD y ser la herramienta de administracin y desarrollo actual de Relima para sus base de datos Oracle.

3.2.4. Crystal Reports Es una aplicacin de inteligencia empresarial utilizada para disear y generar informes. Ha estado desde el IDE de desarrollo Visual Studio 2003 hasta Visual Studio 2008 bajo una licencia OEM. Se us la versin 2008 incluida con el IDE Visual Studio 2008 Team Edition por permitir ser usada para aplicaciones desarrolladas bajo el IDE.

Pgina 12

4. CAPTULO IV: METODOLOGA


Se utiliz la metodologa XP (Extreme Programming) para el desarrollo del proyecto debido al tiempo de desarrollo calculado, el nmero de integrantes y la exigencia del cliente para tener prontos resultados. Introduccin a XP XP resalta una serie de valores y principios que deben tenerse en cuenta y practicarlos durante el tiempo de desarrollo que dure el proyecto. Valores Ms que una metodologa, XP se considera una disciplina, la cual est sostenida por valores y principios propios de las metodologas giles. Existen cuatro valores que cumplen su papel como pilares en el desarrollo de las metodologas livianas: La comunicacin. En la metodologa XP es muy importante que exista un ambiente de colaboracin y comunicacin al interior del equipo de desarrollo, as como en la interaccin de ste con el cliente. En XP la interaccin con el cliente es tan estrecha, que es considerado parte del equipo de desarrollo. La simplicidad. Este valor se aplica en todos los aspectos de la programacin extrema. Desde diseos muy sencillos donde lo ms relevante es la funcionalidad necesaria que requiere el cliente, hasta la simplificacin del cdigo mediante la refactorizacin del mismo. La programacin XP no utiliza sus recursos para la realizacin de actividades complejas, slo se desarrolla lo que el cliente demanda, de la forma ms sencilla. La retroalimentacin. Se presenta desde el comienzo del proyecto, ayuda a encaminarlo y darle forma. sta se presenta en los dos sentidos, por parte del equipo de trabajo hacia el cliente, con el fin de brindarle informacin sobre la evolucin del sistema, y desde el cliente hacia el equipo en los aportes a la construccin del proyecto. El coraje. El equipo de desarrollo debe estar preparado para enfrentarse a los continuos cambios que se presentarn en el transcurso de la actividad. Cada integrante debe tener el valor de exponer los problemas o dudas que halle en la realizacin del proyecto. An con estas variaciones, las jornadas de trabajo deben proporcionar el mximo rendimiento.

Pgina 13

Prcticas A partir de los valores se plantea una serie de prcticas que sirven de gua para los desarrolladores en esta metodologa. Una de los aspectos ms importantes para XP son las doce reglas que se plantean, las cuales se caracterizan por su grado de simplicidad y por su enfoque en la practicidad, adems de que cada regla se complementa con las dems. A continuacin se realizar una breve descripcin de cada una de ellas. El desarrollo est dirigido por pruebas. Antes de realizar una unidad de cdigo, es necesario contar con su respectiva unidad de pruebas. El programador realiza pruebas dirigidas al funcionamiento de nuevas adiciones o mdulos al sistema. El cliente con ayuda del Tester se encarga de disear las pruebas de aceptacin, cuyo propsito es verificar que las historias de usuario se hayan implementado correctamente. El juego de la planificacin. Desde el comienzo del desarrollo se requiere que el grupo y el cliente tengan una visin general y clara del proyecto, es decir, deben entender y estar de acuerdo con lo que el otro plantee. En el transcurso del proyecto se realizan diferentes reuniones, con el fin de organizar las tareas e ideas que surgen tanto por parte del cliente como por el equipo. Cliente in-situ. El cliente, o un representante del mismo, deben estar en el sitio de desarrollo para solucionar las preguntas o dudas que se puedan presentar a medida que se realice el proyecto. Programacin en parejas. XP propone que exista una pareja de programadores por monitor y teclado, como medida para aumentar la calidad del cdigo. Esta prctica busca reducir los errores de codificacin, mientras uno de los programadores busca una forma de dar funcionalidad a un mdulo, el otro programador aprueba dicho cdigo y busca la forma de simplificarlo. Entregas pequeas. En la programacin extrema se realizan entregas constantes de mdulos funcionales completos, de tal forma que en todo momento el cliente tiene una parte de aplicacin funcionando. En XP no existe el desarrollo incompleto de una tarea, sta se ejecuta en su totalidad o no se hace. Refactorizacin sin piedad. El cdigo se revisa de forma permanente para depurarlo y simplificarlo, buscando la forma de mejorarlo. La refactorizacin se realiza durante todo el proceso de desarrollo. Integracin contina del cdigo. El cdigo de los mdulos debe ser integrado a cortos plazos de tiempo, preferiblemente no mayores a un da. Esto facilita la bsqueda y la correccin de errores de codificacin e integracin que se presenten en el proceso.

Pgina 14

Diseo simple. Slo se realiza lo necesario para que la aplicacin cumpla con la funcionalidad requerida por el cliente. No es conveniente realizar diseos complejos que posiblemente no aporten soluciones claras al proyecto, y que a la hora de cambiar los requerimientos se conviertan en una gran barrera de tiempo. Utilizacin de metforas del sistema. Para el mejor entendimiento de los elementos del sistema por parte del equipo de desarrollo se acude a la utilizacin de metforas, como una forma de universalizar el lenguaje del sistema. Propiedad colectiva del cdigo. El cdigo no es conocido por una sola persona del grupo de trabajo, esto facilita implementar cambios al programa por parte de otros integrantes del equipo. Convenciones de cdigo. La aplicacin de estndares de programacin al cdigo fuente de la aplicacin, permite que todas las personas que conforman el grupo de trabajo puedan entender y realizar modificaciones al cdigo del sistema.

No trabajar horas extras. Es preferible volver a estimar los tiempos de entrega. Con esta prctica se busca utilizar al mximo el rendimiento y energa del programador. Alcance XP La programacin extrema es conveniente en ciertas situaciones, pero tambin es necesario saber que presenta controversia en otras. Esta metodologa es aplicable con resultados positivos a proyectos de mediana y pequea envergadura, donde los grupos de trabajo no superan 20 personas. Otro aspecto importante en la seleccin de esta metodologa radica en el ambiente cambiante que se presenta en los requerimientos de la aplicacin. La metodologa XP est encaminada hacia los desarrollos que requieren de cambios continuos en el transcurso de un proyecto. La metodologa es recomendada para proyectos en los cuales el costo de cambio no se incremente a medida que transcurre vida del mismo. Los proyectos realizados bajo esta metodologa cumplen con lo estrictamente necesario en su funcionalidad en el momento necesario: hacer lo que se necesita cuando se necesita. En XP no es conveniente precipitarse o adelantarse a las tareas que se han establecido previamente sin el consentimiento del cliente, estos hechos conllevan a inyectar complejidad al sistema, alejndolo del concepto de simplicidad.

Pgina 15

Planeacin La planeacin es la etapa inicial de todo proyecto en XP. En este punto se comienza a interactuar con el cliente y el resto del grupo de desarrollo para descubrir los requerimientos del sistema. En este punto se identifican el nmero y tamao de las iteraciones al igual que se plantean ajustes necesarios a la metodologa segn las caractersticas del proyecto. En este apartado se tendrn en cuenta ocho elementos, los cuales sern: Historias de usuario, velocidad del proyecto, iteraciones, entregas pequeas, reuniones, roles en XP, traslado del personal y ajuste a XP. Historias de Usuario El sistema es desarrollado para el cliente, por lo tanto, el usuario es quien decide que tareas realizar la aplicacin. Este planteamiento se desarrolla a lo largo del proyecto: el cliente es quien decide que hacer. Como primer paso, se debe proporcionar una idea clara de lo que ser el proyecto en s. Las historias de usuario son utilizadas como herramienta para dar a conocer los requerimientos del sistema al equipo de desarrollo. Son pequeos textos en los que el cliente describe una actividad que realizar el sistema; la redaccin de los mismos se realiza bajo la terminologa del cliente, no del desarrollador, de forma que sea clara y sencilla, sin profundizar en detalles. Se puede considerar que las historias de usuario en XP juegan un papel similar a los casos de uso en otras metodologas, pero en realidad son muy diferentes. Las historias de usuario slo muestran la silueta de una tarea a realizarse. Por esta razn es fundamental que el usuario o un representante del mismo se encuentren disponibles en todo momento para solucionar dudas, estas no proporcionan informacin detallada acerca de una actividad especfica. Las historias de usuario tambin son utilizadas para estimar el tiempo que el equipo de desarrollo tomar para realizar las entregas. En una entrega se puede desarrollar una o varias historias de usuario, esto depende del tiempo que demore la implementacin de cada una de las mismas. Velocidad del Proyecto Es una medida de la capacidad que tiene el equipo de desarrollo para evacuar las historias de usuario en una determinada iteracin. Esta medida se calcula totalizando el nmero de historias de usuario realizadas en una iteracin. Para la iteracin siguiente se podr (tericamente) implementar el mismo nmero de historias de usuario que en la iteracin anterior. Cabe recordar que la velocidad del proyecto ayuda a determinar la cantidad de historias que se pueden implementar en las siguientes iteraciones, aunque no de manera exacta. La revisin continua de esta mtrica en el transcurso del proyecto se hace necesaria, ya que las historias varan segn

Pgina 16

su grado de dificultad, haciendo inestable la velocidad de la realizacin del sistema.

Iteraciones En la metodologa XP, la creacin del sistema se divide en etapas para facilitar su realizacin. Por lo general, los proyectos constan de ms de tres etapas, las cuales toman el nombre de iteraciones, de all se obtiene el concepto de metodologa iterativa. La duracin ideal de una iteracin es de una a tres semanas. Para cada iteracin se define un mdulo o conjunto de historias que se van a implementar. Al final de la iteracin se obtiene como resultado la entrega del mdulo correspondiente, el cual debe haber superado las pruebas de aceptacin que establece el cliente para la verificar el cumplimiento de los requisitos. Las tareas que no se realicen en una iteracin son tomadas en cuenta para la prxima iteracin, donde se define, junto al cliente, si se deben realizar o si deben ser removidas de la planeacin del sistema. Entregas Pequeas La duracin de una iteracin vara entre una y tres semanas, al final de la cual habr una entrega de los avances del producto, los cuales debern ser completamente funcionales. Estas entregas deben caracterizarse por ser frecuentes. Reuniones El planeamiento es esencial para cualquier tipo de metodologa, es por ello que XP requiere de una revisin continua del plan de trabajo. A pesar de ser una metodologa que evita la documentacin exagerada, es muy estricta en la organizacin del trabajo. Plan de Entregas Al comenzar el proyecto se realiza una reunin entre el equipo de trabajo y los clientes. En dicha reunin se define el marco temporal de la realizacin del sistema. El cliente expone las historias de usuario a los integrantes de grupo, quienes estimarn el grado de dificultad de la implementacin de cada historia. Las historias de usuario son asignadas a las diferentes iteraciones segn su orden de relevancia para el proyecto. En el proceso de seleccin de las historias de usuario para cada iteracin, se tiene en cuenta que la suma de

Pgina 17

las estimaciones sea aproximada a la velocidad del proyecto de la iteracin pasada. En esta reunin se predicen los tiempos que se utilizaran en la realizacin de las diferentes etapas del proyecto, los cuales no son datos exactos pero proporcionan una base del cronograma. Finalmente a partir de las historias de usuario, el cliente plantea las pruebas de aceptacin con las cuales se comprueba que cada una de stas ha sido correctamente implementada. Inicio de la Iteracin Al comenzar una iteracin se realiza una reunin de la misma, donde se organizan las actividades de programacin a realizar. Las historias de usuario son traducidas a tareas y asignadas a los desarrolladores. Los desarrolladores estiman los tiempos para la realizacin de las tareas. Cada tarea se estima de uno a tres de das de programacin ideales o sin distracciones. Estas estimaciones son ms exactas que las realizadas en la planeacin de entregas, por lo tanto no deben exceder la velocidad de proyecto de la iteracin anterior. De ser as, se consulta con el cliente para determinar que historias de usuario se pospondrn para iteraciones futuras. Reuniones Diarias o stand-up meeting Estas reuniones se realizan al comenzar la jornada laboral. Todo el equipo de desarrollo se rene para exponer los problemas e ideas que se estn presentando, esto con el fin que el equipo en conjunto construya una mejor solucin. Es de vital importancia evitar las discusiones largas, ya que se est utilizando tiempo laboral que puede ser destinado a la construccin del sistema. Tambin debe evitarse las conversaciones separadas, las dudas que se presenten sern solucionadas por el equipo en conjunto. Roles XP En esta metodologa se utiliza el concepto de roles para organizar quienes se encargaran de cada una de las actividades que deben realizarse en el transcurso del proyecto. Cada uno de estos papeles son desempeados por uno o varios integrantes del grupo, sin descartar la posibilidad de rotar los roles entre el equipo durante la realizacin del sistema. El jefe de proyecto tiene como responsabilidad la direccin y organizacin de las reuniones que se realizan durante el proyecto. Es errneo afirmar que entre sus tareas se encuentra decir que hacer, cuando hacer y de revisar cmo se desarrolla el sistema, para ello se cuenta con el apoyo del cliente, el Tracker y los dems miembros del grupo.

Pgina 18

El usuario o cliente determina qu se va a construir en el sistema, adems de decidir el orden en que se entregarn cada segmento del proyecto. Es parte fundamental del equipo XP (se menciona su importancia como una de las prcticas), en todo proyecto debe existir un cliente. Adems, tiene como tarea establecer las pruebas de aceptacin, las cuales determinan si el sistema cumple con los requerimientos del usuario. En el grupo de los programadores se encuentran adems los diseadores y los analistas. Los programadores son quienes construyen el sistema y realizan las pruebas correspondientes a cada mdulo o unidad de cdigo. Cuando surgen dudas o preguntas que afectan decisiones sobre la funcionalidad del sistema (las decisiones tcnicas son solucionadas gracias a las habilidades de los programadores), el programador no debe hacer suposiciones acerca de lo que el cliente quiere; en este caso, debe dirigirse al mismo y aclarar la situacin. El entrenador (coach) es el responsable de que el proceso se realice de forma correcta. Se asegura de que los conceptos de la metodologa se apliquen al proyecto, adems de brindar ayuda continua a los dems integrantes del equipo. El Tester o quien realiza las pruebas, colabora en la realizacin de las pruebas de aceptacin y es quien muestra los resultados de las mismas. En este proceso, ayuda al cliente a disear tales pruebas y a verificar que las pruebas sean aprobadas. El rastreador (Tracker) tiene como tarea observar la realizacin del sistema. Varias veces por semana cuestiona a los integrantes del equipo para anotar sus logros y avances. Traslado de personal Al mover el personal se evitan problemas relacionados con la prdida de conocimiento y cuellos de botella. Todos los miembros del grupo deben tener suficiente conocimiento de la estructura del cdigo de modo tal que se eviten las islas de conocimiento las cuales son susceptibles de generar prdidas de informacin importante. En la medida que todos los programadores entienden todas las partes del programa se evita que unos tengan una carga de trabajo muy alta mientras que otros no tengan mucho trabajo por hacer. La programacin en parejas se convierte en una herramienta muy importante para lograr el objetivo del traslado de personal sin que se pierda el rendimiento. Esto se logra haciendo que un miembro de la pareja se traslade mientas que el otro contine el desarrollo con un nuevo compaero.

Pgina 19

Ajustar XP Todos los proyectos tienen caractersticas especficas por lo cual XP puede ser modificado para ajustarse bien al proyecto en cuestin. Al iniciar el proyecto se debe aplicar XP tal como es, sin embargo no se debe dudar en modificar aquellos aspectos en que no funcione. Eso no quiere decir que los desarrolladores pueden hacer lo que se les antoje. Antes de implementarse un cambio, este debe ser discutido y aprobado por el grupo. Diseo En XP solo se disean aquellas historias de usuario que el cliente ha seleccionado para la iteracin actual por dos motivos: por un lado se considera que no es posible tener un diseo completo del sistema y sin errores desde el principio. El segundo motivo es que dada la naturaleza cambiante del proyecto, el hacer un diseo muy extenso en las fases inciales del proyecto para luego modificarlo, se considera un desperdicio de tiempo. Es importante resaltar que esta tarea es permanente durante la vida del proyecto partiendo de un diseo inicial que va siendo corregido y mejorado en el transcurso del proyecto. Simplicidad en el diseo Una de las partes ms importantes de la filosofa XP es la simplicidad en todos los aspectos. Se considera que un diseo sencillo se logra ms rpido y se implementa en menos tiempo, por lo cual esto es lo que se busca. La idea es que se haga el diseo ms sencillo que cumpla con los requerimientos de las historias de usuario. Sobre los diagramas, se es muy claro que se pueden usar siempre que no tome mucho tiempo en realizarlos, que sean de verdadera utilidad y que se est dispuesto a tirarlos a la basura. En XP se prefiere tener una descripcin del sistema o parte de l, en lugar de una serie de complejos diagramas que probablemente tomen ms tiempo y sean menos instructivos. Metfora del Sistema Se trata de plasmar la arquitectura de sistema en una historia con la cual se le d al grupo de desarrollo una misma visin sobre el proyecto adems de brindarles un primer vistazo muy completo a los nuevos integrantes del grupo para hacer su adaptacin ms rpida. Es muy importante dentro del desarrollo de la metfora darle nombres adecuados a todos los elementos del sistema constantemente, y que estos correspondan a un sistema de nombres consistente. Esto ser de mucha

Pgina 20

utilidad en fases posteriores del desarrollo para identificar aspectos importantes del sistema.

Tarjetas de clase, responsabilidad, colaboracin (CRC cards) La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento procedimental para incorporarse al enfoque orientado a objetos. Cada tarjeta representa una clase con su nombre en la parte superior, en la seccin inferior izquierda estn descritas las responsabilidades y a la derecha las clases que le sirven de soporte. En el proceso de disear el sistema por medio de las tarjetas CRC como mximo dos personas se ponen de pie adicionando o modificando las tarjetas, prestando atencin a los mensajes que stas se transmiten mientras los dems miembros del grupo que permanecen sentados, participan en la discusin obteniendo as lo que puede considerarse un diagrama de clases preliminar. Soluciones puntuales (Spike Solution) En muchas ocasiones los equipos de desarrollo se enfrentan a requerimientos de los clientes (en este caso historias de usuario) los cuales generan problemas desde el punto de vista del diseo o la implementacin. Spike Solution, es una herramienta de XP para abordar este inconveniente. Se trata de una pequea aplicacin completamente desconectada del proyecto con la cual se intenta explorar el problema y propone una solucin potencial. Puede ser burda y simple, siempre que brinde la informacin suficiente para enfrentar el problema encontrado. No solucionar antes de tiempo Los desarrolladores tienden a predecir las necesidades futuras e implementarlas antes. Segn mediciones, esta es una prctica ineficiente, concluyendo que tan solo el 10% de las soluciones para el futuro son utilizadas, desperdiciando tiempo de desarrollo y complicando el diseo innecesariamente. En XP slo se analiza lo que se desarrollar en la iteracin actual, olvidando por completo cualquier necesidad que se pueda presentar en el futuro, lo que supone uno de los preceptos ms radicales de la programacin extrema.

Pgina 21

Refactorizacin (Refactoring) El diseo es una tarea permanente durante toda la vida del proyecto y la refactorizacin concreta este concepto. Como en cualquier metodologa tradicional en XP se inicia el proceso de desarrollo con un diseo inicial. La diferencia es que en las metodologas tradicionales este diseo es tan global y completo como se es posible tomando generalmente mucho tiempo en lograrse y con la creencia de que si se ven forzados a modificarlo ser un fracaso para el grupo de desarrollo. El caso de XP es el opuesto. Se parte de un diseo muy general y simple que no debe tardar en conseguirse, al cual se le hacen adiciones y correcciones a medida que el proyecto avanza, con el fin de mantenerlo tanto correcto como simple. La refactorizacin en el cdigo pretende conservarlo tan sencillo y fcil de mantener como sea posible. En cada inspeccin que se encuentre alguna redundancia, funcionalidad no necesaria o aspecto en general por corregir, se debe rehacer esa seccin de cdigo con el fin de lograr las metas de sencillez tanto en el cdigo en s mismo como en la lectura y mantenimiento. Estas prcticas son difciles de llevar a cabo cuando se est iniciando en XP por varios motivos. En primer lugar debido el temor que genera en los equipos de desarrollo cambiar algo que ya funciona bien sea a nivel de diseo o implementacin. Sin embargo si se cuenta con un esquema de pruebas completo y un sistema de automatizacin para las mismas se tendr xito en el proceso. El otro motivo es la creencia que es ms el tiempo que se pierde en refactoring que el ganado en sencillez y mantenimiento. Segn XP la ganancia obtenida en refactoring es tan relevante que justifica suficientemente el esfuerzo extra en correccin de redundancias y funcionalidades innecesarias. Codificacin La codificacin es un proceso que se realiza en forma paralela con el diseo y la cual est sujeta a varias observaciones por parte de XP consideradas controversiales por algunos expertos tales como la rotacin de los programadores o la programacin en parejas. Adems de los mencionados temas, el lector encontrar a continuacin una descripcin de los siguientes temas: cliente siempre presente, codificar primero la prueba, integracin secuencial e integraciones frecuentes. Cliente siempre presente. Uno de los requerimientos de XP es que el cliente est siempre disponible. No solamente para solucionar las dudas del grupo de desarrollo, debera ser parte de ste. En este sentido se convierte en gran ayuda al solucionar todas las dudas que puedan surgir, especialmente cara a cara, para garantizar que

Pgina 22

lo implementado cubre con las necesidades planteadas en las historias de usuario. Codificar primero la prueba Cuando se crea primero una prueba, se ahorra mucho tiempo elaborando el cdigo que la haga pasar, siendo menor el tiempo de hacer ambos procesos que crear el cdigo solamente. Una de las ventajas de crear una prueba antes que el cdigo es que permite identificar los requerimientos de dicho cdigo. En otras palabras, al escribir primero las pruebas se encuentran de una forma ms sencilla y con mayor claridad todos los casos especiales que debe considerar el cdigo a implementar. De esta forma el desarrollador sabr con completa certeza en qu momento ha terminado, ya que habrn pasado todas las pruebas. Programacin en parejas Todo el cdigo debe ser creado por parejas de programadores sentados ambos frente a un nico computador lo que en principio representa una reduccin de un 50% en productividad, sin embargo, segn XP no es tal la prdida. Se entiende que no hay mucha diferencia, en lo que a la cantidad se refiere, entre el cdigo producido por una pareja bajo estas condiciones que el creado por los mismos miembros trabajando en forma separada, con la excepcin que uno o ambos programadores sean muy expertos en la herramienta en cuestin. Cuando se trabaja en parejas se obtiene un diseo de mejor calidad y un cdigo ms organizado y con menores errores que si se trabajase solo, adems de la ventaja que representa contar con un compaero que ayude a solucionar inconvenientes en tiempo de codificacin, los cuales se presentan con mucha frecuencia. Se recomienda que mientras un miembro de la pareja se preocupe del mtodo que se est escribiendo el otro se ocupe de cmo encaja ste en el resto de la clase. Integracin Secuencial Uno de los mayores inconvenientes presentados en proyectos de software tiene que ver con la integracin, sobre todo si todos los programadores son dueos de todo el cdigo. Para saldar este problema han surgido muchos mecanismos, como darle propiedad de 40 determinadas clases a algunos desarrolladores, los cuales son los responsables de mantenerlas actualizadas y consistentes. Sin embargo, sumado al hecho que esto va en contra de la propiedad colectiva del cdigo no se solucionan los problemas presentados por la comunicacin entre clases.

Pgina 23

XP propone que se emplee un esquema de turnos con el cual solo una pareja de programadores integre a vez. De esta forma se tiene plena seguridad de cul es la ltima versin liberada y se le podrn hacer todas las pruebas para garantizar que funcione correctamente. A esto se le conoce como integracin secuencial. Integraciones Frecuentes Se deben hacer integraciones cada pocas horas y siempre que sea posible no debe transcurrir ms un da entre una integracin y otra. De esta forma se garantiza surjan problemas como que un programador trabaje sobre versiones obsoletas de alguna clase. Es evidente que entre ms se tarde en encontrar un problema ms costoso ser resolverlo y con la integracin frecuente se garantiza que dichos problemas se encuentre ms rpido o an mejor, sean evitados por completo. Estndares y propiedad colectiva del cdigo As como se recomienda que la programacin se haga siempre en parejas ubicadas en un nico computador, tambin se aconseja que estas se vayan rotando no solo de compaero sino de partes del proyecto a implementar, con el fin de que se logre tener una propiedad colectiva del cdigo. Todos y cada uno de los programadores tienen suficiente conocimiento del cdigo de los dems de modo tal que en cualquier momento puedan continuar la codificacin que alguien ms empez sin que represente un traumatismo para nadie. Uno de los principales motivos por los que se promueve esta prctica dentro de la programacin extrema es la posibilidad que brinda de evitar los cuellos de botella. Si una pareja de programadores se retrasa debido a inconvenientes no estimados pueden ser ayudados o reemplazados por otra pareja que al conocer el cdigo no tendr que familiarizarse con l. Para lograr lo anterior se recomienda el establecimiento de estndares en la codificacin, de modo tal que todo el cdigo escrito por el grupo de desarrollo parezca hecho por una sola persona. No se establecen los aspectos especficos a tener en cuenta dentro de estos estndares, sin embargo se aconseja que sean de total aceptacin por parte del equipo.

Pruebas XP enfatiza mucho los aspectos relacionados con las pruebas, clasificndolas en diferentes tipos y funcionalidades especficas, indicando quin, cundo y cmo deben ser implementadas y ejecutadas.

Pgina 24

Del buen uso de las pruebas depende el xito de otras prcticas, tales como la propiedad colectiva del cdigo y la refactorizacin. Cuando se tienen bien implementadas las pruebas no habr temor de modificar el cdigo del otro programador en el sentido que si se daa alguna seccin, las pruebas mostrarn el error y permitirn encontrarlo. El mismo criterio se aplica a la refactorizacin. Uno de los elementos que podra obstaculizar que un programador cambie una seccin de cdigo funcional es precisamente hacer que esta deje de funcionar. Si se tiene un grupo de pruebas que garantice su buen funcionamiento, este temor se mitiga en gran medida. Segn XP se debe ser muy estricto con las pruebas. Slo se deber liberar una nueva versin si esta ha pasado con el cien por ciento de la totalidad de las pruebas. En caso contrario se emplear el resultado de estas para identificar el error y solucionarlo con mecanismos ya definidos. Pruebas unitarias Estas pruebas se aplican a todos los mtodos no triviales de todas las clases del proyecto con la condicin que no se liberar ninguna clase que no tenga asociada su correspondiente paquete de pruebas. Uno de los elementos ms importantes en estas es que idealmente deben ser construidas antes que los mtodos mismos, permitindole al programador tener mxima claridad sobre lo que va a programar antes de hacerlo, as como conocer cada uno de los casos de prueba que deber pasar, lo que optimizar su trabajo y su cdigo ser de mejor calidad. Deben ser construidas por los programadores con el empleo de algn mecanismo que permita automatizarlas de modo tal que tanto su implementacin y ejecucin consuman el menor tiempo posible permitiendo sacarles el mejor provecho EL empleo de pruebas unitarias completas facilitan la liberacin continua de versiones por cuanto al implementar algo nuevo y actualizar la ltima versin, solo es cuestin de ejecutar de forma automtica las pruebas unitarias ya creadas para saber que la nueva versin no contiene errores.

Pruebas de aceptacin Las pruebas de aceptacin, tambin llamadas pruebas funcionales son supervisadas por el cliente basndose en los requerimientos tomados de las historias de usuario. En todas las iteraciones, cada una de las historias de usuario seleccionadas por el cliente deber

Pgina 25

tener una o ms pruebas de aceptacin, de las cuales debern determinar los casos de prueba e identificar los errores que sern corregidos. Las pruebas de aceptacin son pruebas de caja negra, que representan un resultado esperado de determinada transaccin con el sistema. Para que una historia de usuario se considere aprobada, deber pasar todas las pruebas de aceptacin elaboradas para dicha historia. Es importante resaltar la diferencia entre las pruebas de aceptacin y las unitarias en lo que al papel del usuario se refiere. Mientras que en las pruebas de aceptacin juega un papel muy importante seleccionando los casos de prueba para cada historia de usuario e identificando los resultados esperados, en las segundas no tiene ninguna intervencin por ser de competencia del equipo de programadores. Proceso de desarrollo XP Todo proyecto de software en XP inicia con una o varias reuniones con el cliente, en las cuales se da claridad a la necesidad puntual del mismo a travs de las historias de usuario. Estas tambin sirven de base para crear una metfora del sistema con el cual todo el equipo de trabajo tendr una idea general de la aplicacin a implementar. Con base en las historias de usuario se crean las pruebas de aceptacin las cuales deben ser diseadas antes de iniciar la codificacin. Concluida esta etapa, se debe acordar un plan de entregas con el cliente del cual surge el nmero inicial de iteraciones y duracin de las mismas. Esta reunin de entregas puede repetirse en el transcurso del proyecto, siempre que la velocidad del mismo cambie lo suficiente para tener que replantear el plan de entregas o que surjan nuevas historias de usuario que justifiquen la alteracin de dicho plan. Dentro de esta(s) reunin(es) de planeacin de entregas debe considerarse la realizacin de algunos Spike Solution para tener claridad sobre la dificultad y tiempo necesario para implementar determinada historia de usuario. Toda iteracin debe iniciar con una reunin en la que se da claridad a las tareas a desarrollar, basndose en el plan de entregas, la velocidad del proyecto y las historias de usuario sin concluir de la iteracin anterior. De esta reunin se obtiene un plan que sirve de hoja de ruta en el transcurso de la iteracin. Todos los das debe hacerse un reunin corta en la cual se discute el avance de la iteracin basndose en el plan obtenido de la reunin de inicio de iteracin y las tareas concluidas con el cual se acuerda el trabajo del da.

Pgina 26

5. CAPTULO V: DESARROLLO DEL SISTEMA EN BASE A XP


5.1. Cuadro de Reuniones
INTEGRANTES Jos Luis Apaza Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez Jos Luis Apaza Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez TEMA A TRATAR OBSERVACIONES - Se levant informacin de los requerimientos del cliente para generar las historias de usuario y en base a ellos estimar los costos y tiempos. - Se di a conocer la informacin de costos y beneficios el cual fue aprobado por el cliente. - Se entregaron los orgenes de datos fsicos (Excel, Access, etc.) por parte del cliente. - Se present el Modelo Entidad Relacin de la Base de Datos. - Se mostraron los prototipos de sistema y se entreg el plan de entregas. - Se defini el plan de pruebas de aceptacin con el usuario. - Se present el formulario de login en donde se solicit que el usuario tenga como mximo 15 caracteres y que solo puedan ingresar los empleados del rea Operacional. - El usuario evalu el avance realizado y estuvo conforme. - Se observ que al momento de visualizar la data importada se debera mostrar el nombre y cargo del personal de recoleccin. - El cliente pidi modificar el tamao de las fuentes que se visualizaban en el dispositivo as tambin como cambiar el color de algunos controles. FECHA

Requerimientos del Sistema

05/09/2011

Costos de desarrollo e implementacin

12/09/2011

Jos Luis Apaza Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez

Presentacin del anlisis del sistema y definicin de pruebas de aceptacin.

30/09/2011

Miguel Flower Valeria Gmez

Presentacin de avances de ventana de login

05/10/2011

Miguel Flower Valeria Gmez

Presentacin de avance de mantenimientos de tablas maestras Reunin para ver avance del mdulo de programacin vehicular.

12/10/2011

Jos Luis Apaza Miguel Flower Valeria Gmez

25/10/2011

Jos Luis Apaza Peter Paucar Oscar De Pirola

Presentacin de las pantallas del dispositivo mvil al cliente

28/10/2011

Jos Luis Apaza Miguel Flower Valeria Gmez

Presentacin del primer entregable al cliente que incluye: Logueo al sistema, mantenimientos y programacin vehicular.

- Se realizaron las pruebas de aceptacin planificadas las cuales pasaron satisfactoriamente.

28/10/2011

Pgina 27

Jos Luis Apaza Miguel Flower Valeria Gmez Jos Luis Apaza Peter Paucar Oscar De Pirola

Presentacin del avance del mdulo de recoleccin del sistema web. Presentacin del avance del mdulo de recoleccin de la aplicacin mvil Presentacin del segundo entregable al cliente que incluye: Mdulo de Recoleccin Presentacin del avance de mdulo de reportes

- El usuario dio el visto bueno del avance del mdulo. - Se pidi que haya validaciones al momento de ingresar datos, especficamente el ingreso de campos vacos.

14/11/2011

14/11/2011

Jos Luis Apaza Miguel Flower Valeria Gmez Jos Luis Apaza Miguel Flower Valeria Gmez

- Se realizaron las pruebas respectivas, y se logr capacitar al usuario.

18/11/2011

- Modificaciones en el diseo y se solicit dos reportes adicionales.

29/11/2011

Jos Luis Apaza Peter Paucar Oscar De Pirola

Presentacin del avance de mdulo de auxilio mecnico y envo de mensajes de la aplicacin mvil

- Se solicit realizar algunos cambios en el mensaje enviado por correo del mdulo.

29/11/2011

Jos Luis Apaza Peter Paucar Oscar De Pirola

Presentacin del avance del mdulo de justificacin de parada de la aplicacin mvil. Presentacin del tercer entregable al cliente que incluye: Mdulo de reportes y aplicacin mvil Se realizaron las pruebas de integracin de los sistemas web y mvil

- Se dio el visto bueno por parte del usuario.

07/12/2011

Jos Luis Apaza Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez Jos Luis Apaza Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez Jos Luis Apaza Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez Jos Luis Apaza Miguel Flower Valeria Gmez

- Se realizaron las pruebas respectivas y los entregables fueron aceptados.

09/12/2011

- Se realizaron las pruebas respectivas y los mdulos fueron integrados satisfactoriamente.

16/12/2012

Implementacin de Sistema

- El sistema se implement en su totalidad para su funcionamiento real.

22/12/2012

Se hizo la entrega de las fuentes, la documentacin concerniente y se vio el desempeo del sistema.

- Se realizaron ajustes requeridos por el cliente, se entreg los manuales de usuario y cdigo fuente del Sistema.

06/01/2012

Pgina 28

5.2. Historias de usuario


NUMERO HISTORIA: 01 NOMBRE HISTORIA: Login FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 2 semanas DESCRIPCIN: El usuario acceder al sistema mediante una pantalla de logueo donde se le solicitar su usuario y password.

NOTAS:

NUMERO HISTORIA: 02 NOMBRE HISTORIA: Mantenimiento de Tablas Maestras FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 2 semanas

DESCRIPCIN: El sistema debe contar con los formularios de cada tabla maestra que se indica en la Base de Datos

NOTAS: En caso opcional el mantenimiento de la tabla maestra de vehculos debe tener una opcin de exportacin a Excel.

NUMERO HISTORIA: 03 NOMBRE HISTORIA: Importacin de datos FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 1 semana DESCRIPCIN: La importacin ser desde un archivo de Access el cual contar con una pantalla para la importacin de datos. Adems debe tener un formulario de configuracin de rutas.

NOTAS:

Pgina 29

NUMERO HISTORIA: 04 NOMBRE HISTORIA: Mdulo de Programacin Vehicular FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 1 semana DESCRIPCIN: El mdulo debe mostrar el formulario de importacin de Access y una visualizacin de datos importados en otro formulario.

NOTAS:

NUMERO HISTORIA: 05 NOMBRE HISTORIA: Mdulo de Recoleccin FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 3 semanas

DESCRIPCIN: Esto se desarrollar con pantallas semejantes a las fichas fsicas de recoleccin usando la informacin relevante.

NOTAS: Validar informacin con la data importada de la programacin vehicular, adicionar el tema de manejo de incidencias al mdulo.

NUMERO HISTORIA: 06 NOMBRE HISTORIA: Mdulo de Reportes FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 2 semanas

DESCRIPCIN: Los reportes deben mostrar las recolecciones diarias, los pesajes de los detalles de recoleccin.

NOTAS:

Pgina 30

NUMERO HISTORIA: 07 NOMBRE HISTORIA: Mdulo de Recoleccin Mvil FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 2 semanas DESCRIPCIN: El mdulo debe reflejar la mayora de los detalles ms importantes de la ficha de recoleccin de la ficha de recoleccin en el mvil.

NOTAS: Las informaciones ingresadas deben mostrarse en mayscula.

NUMERO HISTORIA: 08 NOMBRE HISTORIA: Mdulo de Reporte de incidencias FECHA: 09/09/2011 USUARIO: Jos Luis Apaza. TIEMPO ESTIMADO: 3 semanas DESCRIPCIN: El mdulo debe ser capaz de reportar fallas mecnicas como tambin informar de retrasos que ocurrieran en el viaje de los camiones de recoleccin.

NOTAS: En caso de fallas mecnicas se debera poder enviar una imagen para ver consultar con los mecnicos si la falla se puede apreciar a simple vista, adems debe poder enviar una alerta al correo de los encargados de turno.

Pgina 31

5.3. Cuadro de Requerimientos


5.3.1. Sistema web

Cdigo de requerimiento

Mdulo / Proceso

Nombre del requerimiento

Descripcin del requerimiento Desarrollo de un componente que permita el ingreso de los datos del usuario, que valide si est registrado o no en la Base de Datos del Sistema. Mantenimiento de fichas de recoleccin vehicular diarias. Especificacin de reportes sobre recoleccin diaria y balanza.

R-01

Proceso de logueo.

Desarrollo de un proceso de validacin del usuario.

R-02

Mdulo de Recoleccin

Desarrollo del mdulo para la gestin de fichas de recoleccin Desarrollo del mdulo para generar reportes Desarrollo del mdulo para la validacin de informacin de la Programacin Vehicular

R-03

Mdulo de Reportes

R-04

Mdulo de Programacin Vehicular

Importacin de la data sobre la programacin vehicular desarrollada en el rea de Planeamiento. Este mdulo se encargar de registrar los dispositivos a travs del ID generado a la hora de la instalacin del APK los cuales sern asignados a un determinado vehculo

R-05

Mdulo de asignacin de dispositivo

Desarrollar un mdulo para asignar los dispositivos a los vehculos

Pgina 32

5.3.2. Sistema mvil Cdigo de Requerimiento Mdulo / Proceso Nombre del Requerimiento Descripcin del Requerimiento Desarrollo de un componente que permita el ingreso de los datos del usuario, que valide si esta registrado o no en la base de datos del sistema.

R-06

Proceso de logueo.

Desarrollo de un proceso de validacin del usuario.

R-07

Registro del recorrido

Desarrollo de un mdulo para el registro de los detalles de los viajes

Desarrollo de un mdulo que permita el ingreso de los datos obtenidos en los cuatro puntos de parada, los cuales son: o Lugar de salida. o Lugar de destino. o Lugar de pesaje. o Salida de pesaje. El mdulo debe ser capaz de enviar la localizacin del vehculo para su visualizacin constante.

R-08

Registro de Incidencias

Desarrollo de mdulo de reporte de incidencias.

Este mdulo estar dividido en dos partes: o Registro de paradas en el cual se registrar en donde el usuario justificar las demoras que haya experimento durante su recorrido. o Auxilio mecnico, en donde el usuario podr emitir un mensaje de auxilio destinado al correo electrnico al encargado de la supervisin.

Pgina 33

5.4. Plan de Entrega


ENTREGA Base de Datos del Sistema FECHA 30/09/2011 28/10/2011 18/11/2011 09/12/2011 09/12/2011 06/01/2012

Sistema Web
1er Entregable Mdulo de mantenimientos y Programacin Vehicular 2do Entregable Mdulo de Recoleccin 3er Entregable Mdulo de Reportes

Aplicacin Mvil
Mdulos de Aplicacin Mvil Cdigo fuente de los sistemas y documentacin concerniente.

5.5. Anlisis de Costos


Inversin de Recursos (Sistema propuesto)
Recursos Roles Salario Mensual Cant. Perodo (Meses) Costo a Nivel del Proyecto

Valeria Gmez Miguel Flower Oscar de Pirola Peter Paucar

Analista Programador Analista Programador Analista Programador Analista Programador Total mensual

S/. 1,200.00 S/. 1,200.00 S/. 1,200.00 S/. 1,200.00 S/. 4,800.00

4 4 4 4 Total

S/. 4,800.00 S/. 4,800.00 S/. 4,800.00 S/. 4,800.00 S/. 19,200.00

Inversin de Requerimientos Tecnolgicos


Hardware Descripcin Cantidad Costo Unitario Costo Total

Smartphone H400

GPS Activo Android 2.3 Cmara 3.0 mpx.

30

S/. 300.00

S/. 9,000.00 S/. 9,000.00 S/. 1,620.00 S/. 10,620.00


Costo Total

OBSERVACION: Sub Total Debido a que la organizacin cuenta con los equipos de cmputo y recursos necesarios, para el funcionamiento sistema, I.G.V no fue requerido ningn tipo de inversin en este aspecto; ofrecindole a la institucin la posibilidad y la ventaja de realizar inversiones en otros requerimientos y necesidades de la Total organizacin. Recursos Descripcin Cantidad Costo Unitario SMART Empresas (i) Claro Plan de Datos 30 S/. 59.00

Sub Total I.G.V Total

S/. 1,770.00 S/. 1,770.00 S/. 318.60 S/. 2,088.60

Pgina 34

Costos Operacionales sin el Sistema Propuesto


Insumo / Gasto Cantidad / Unidad Costo Insumo / Unidad Costo / Mensual

Remuneracin Empleados Gasto de Mantenimiento Sistema Insumos

250 14 N/A

S/. 800.00 S/. 200.00 S/. 0.00 Total mensual

S/. 200,000.00 S/. 2,800.00 S/. 10,000.00 S/. 212,800.00

Costos Operacionales con el Sistema Propuesto (Primer Entregable)


Insumo / Gasto Cantidad / Unidad Costo Insumo / Unidad Costo / Mensual

Remuneracin Empleados Gasto de Mantenimiento Sistema Insumos

250 14 N/A

S/. 800.00 S/. 200.00 S/. 0.00 Total mensual

S/. 200,000.00 S/. 2,800.00 S/. 7,000.00 S/. 209,800.00

Costos Operacionales con el Sistema Propuesto (Segundo Entregable)


Insumo / Gasto Cantidad / Unidad Costo Insumo / Unidad Costo / Mensual

Remuneracin Empleados Gasto de Mantenimiento Sistema Insumos

250 14 N/A

S/. 800.00 S/. 100.00 S/. 0.00 Total mensual

S/. 200,000.00 S/. 1,400.00 S/. 4,000.00 S/. 205,400.00

Costos Operacionales con el Sistema Propuesto (Tercer Entregable)


Insumo / Gasto Cantidad / Unidad Costo Insumo / Unidad Costo / Mensual

Remuneracin Empleados Gasto de Mantenimiento Sistema Insumos Plan de Datos para Mviles Costo de Dispositivos Mviles

250 0 N/A 30

S/. 800.00 S/. 0.00 S/. 0.00 S/. 59.00

S/. 200,000.00 S/. 0.00 S/. 2,000.00 S/. 1,770.00 S/. 10,620.00

Total mensual

S/. 214,390.00

Costos Operacionales con el Sistema Propuesto Implementado


Insumo / Gasto Cantidad / Unidad Costo Insumo / Unidad Costo / Mensual

Remuneracin Empleados Gasto de Mantenimiento Sistema Insumos Plan de Datos para Mviles

250 0 N/A 30

S/. 800.00 S/. 0.00 S/. 0.00 S/. 59.00


Total mensual

S/. 200,000.00 S/. 0.00 S/. 2,000.00 S/. 1,770.00


S/. 203,770.00

Pgina 35

Mes Setiembre Octubre Noviembre Diciembre Enero Febrero Marzo Abril Mayo Junio Julio Agosto

Periodo 1 2 3 4 5 6 7 8 9 10 11 12

Flujo de Fondos -S/. 4,800.00 -S/. 1,800.00 S/. 2,600.00 -S/. 6,390.00 S/. 9,030.00 S/. 9,030.00 S/. 9,030.00 S/. 9,030.00 S/. 9,030.00 S/. 9,030.00 S/. 9,030.00 S/. 9,030.00

TIR VAN

42% S/. 3,065.94

Tasa Interna de Rentabilidad Valor Neto Anual de la Inversin

5.6. Tarjetas de CRC


CLASE USUARIO Responsabilidad o o o o o Se registra usuarios Se validan Cambian su password Se pueden eliminar Se pueden cambiar datos Colaborador

o Personal

CLASE FICHA RECOLECCIN Responsabilidad Colaborador o o o o o o o o o Registra los tiempos Selecciona la balanza Se registra la hora de envi Se registra el solicitante Se registra la posicin Se registra los pesos de las balanzas Se registra el ticket Cargar data Validar data o o o o o o o Usuario Vehculo Balanza Ticket Justificacin de parada Auxilio mecnico Cambio de chofer

Pgina 36

CLASE AUXILIO MECNICO Responsabilidad Colaborador o Llena tipo de auxilio o Describe el suceso o Se registra la hora de envi o Se registra el solicitante o Se registra la posicin o Se manda una imagen del problema o o o Usuario Ficha recoleccin Vehculo

CLASE JUSTIFICACIN DE PARADA Responsabilidad Colaborador o Escribe la razn de la parada o Especifica los tiempos tomados de la parada o Se registra la hora de envi o o Usuario Ficha recoleccin

CLASE PROGRAMACIN VEHICULAR Responsabilidad Colaborador o Se define un recorrido o Se asignan los trabajadores o Se asignan los vehculos o Definen las fechas o Seleccionan el cliente o o o o Sector Vehculo Usuario Cliente

CLASE REPORTE Responsabilidad o Generar reporte o Exportar reporte Colaborador o Ficha recoleccin o Incidencias o Tickets o Movimiento Vehicular

CLASE DISPOSITIVO Responsabilidad Colaborador o Registran al dispositivo o Usuarios

CLASE ASIGNACIN DISPOSITIVO Responsabilidad Colaborador o Dispositivo Se asigna un dispositivo al o Vehculo vehculo o Usuario

Pgina 37

5.7. Roles de Equipo

ROL

DESCRIPCIN Escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. El programador escribe las pruebas unitarias y produce el cdigo del sistema.

RESPONSABLE

Cliente

Relima Ambiental S.A.C.

Programador

Peter Paucar Oscar De Pirola Miguel Flower Valeria Gmez

Tester

Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Proporciona realimentacin al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin. Es responsable del proceso global. Debe proveer guas al equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto, en el que puedan surgir problemas. Es el vnculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin.

Miguel Flower

Tracker

Juan Calla

Coach

Juan Calla

Consultor

Juan Calla

Big Boss

Jos Luis Apaza

Pgina 38

5.8. Metfora del Sistema


5.8.1. Metfora del Sistema Web Login

En la fase del Logueo el operario deber ingresar el Usuario y Password, el sistema deber autenticar si existe en el usuario en la base de datos, de no ser as mostrar un mensaje de informacin que no existe el usuario. En caso contrario acceder al sistema Web. Mantenimientos de Tablas Maestras

El mdulo de mantenimiento de tablas consiste en gestionar la informacin de las tablas maestras, como Registrar, Actualizar, Eliminar, Anular, Buscar. Tambin mostrar una lista de registros paginados por 10 registros en cada pgina de la vista, para seleccionar algn registro y realizar actualizacin u otra transaccin del mantenimiento. Mdulo de Planeamiento Programacin Vehicular

El operario debe importar la informacin de un archivo de Microsoft Access llamado BDRecoleccion.mdb de la tabla R_SECTOR_PERSONAL, pero antes de importar debe definir la ruta de ubicacin del archivo. Para esto hay un formulario en el men de Utilitarios llamado Ruta de Configuracin. Despus de especificar la ruta de configuracin del Access el usuario ir al Men de Planeamiento para importar la informacin del Archivo de Access, para eso hay un formulario indicando los filtros de los datos a importar. Cuando realice la importacin se mostrar un mensaje de confirmacin de la informacin importada, para poder ver la data importada el operario debe ir al formulario de Programacin Vehicular y deber seleccionar mediante una lista desplegable por Ao Turno Regin Mes. Mdulo de Recoleccin Fichas de Control de Recoleccin El mdulo de Recoleccin mostrar las fichas especificadas mediante una lista desplegable del lado izquierdo del operario, en esta ficha ingresar o validar los datos realizados por los trabajadores recolectores. Fichas no Programadas En este formulario se ingresarn las fichas que no fueron programadas en la programacin vehicular del mes.

Cierre de Mes Este Formulario inhabilitar las fichas del mes anterior para llevar un mejor control de desarrollo del servicio de Recoleccin Mdulo de Reportes Generales.

Pgina 39

El Mdulo de Reportes es comprendido por 3 reportes principales. Bsicamente cada reporte comprende 2 tipos de visualizacin. Con detalles Sin detalles

Tambin contiene Filtros de Criterios como: Rango de Fechas, Balanzas, Clientes. Estos Reportes tendrn la opcin de exportacin a diferentes formatos como Excel, PDF, Word, Etc. Reportes de Produccin Cliente Muestra los clientes donde se han realizado los servicios de recoleccin Reporte control de vehculos Muestra los vehculos que han sido registrados por el Centro de Balanza. Reportes de informacin de tickets Muestra los Tickets que han sido generados por el Centro de Balanza.

5.8.2. Metfora Mvil Login El operario deber ingresar el Usuario y Password para poder acceder al sistema mvil Relima lo cual llevar a la pgina de entrada al sistema llamado Informacin del sistema. Informacin del sistema Al ingresar se visualizar el APK identificador del equipo que se genrerar al momento de instalar la aplicacin en el mvil ser enviado y registrado en la Base de Datos. Mapa El Sistema contar con una visualizacin de localizacin del usuario para informacin y gua del operario.

Pgina 40

Detalle de rdenes de recoleccin Este men permitir enviar la informacin requerida para el detalle de los viajes del servicio de recoleccin, este mdulo 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 podra demorar la parada que tomara el vehculo para realizar los ajustes de tiempo que sean convenientes.

Auxilio mecnico 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.

Mens 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 posicin del equipo pasando un determinado tiempo o si se el operario se mueva determinados metros.

Pgina 41

5.9. Cronograma de actividades


Leyenda
Descripcin Oscar De Pirola Miguel Flower Peter Paucar Valeria Gmez Referencia OP MF PP VG

2011
ACTIVIDADES
S1

2012
Noviembre Diciembre
S4 S1 S2 S3

Setiembre
S2 S3 S4 S1

Octubre
S2 S3 S4

Enero
S4 S1

S1

S2

S3

Levantamiento de OP OP informacin y MF MF definicin de VG VG requerimientos. PP PP Creacin de la base OP OP de datos y MF MF desarrollo de VG VG prototipos y plan de PP PP pruebas. Creacin de Ventana Login Programacin de Login Pruebas de Login Desarrollo de interfaces del mdulo de Mantenimientos Programacin de Mdulo de Mantenimientos Pruebas de Mdulo de Mantenimientos Desarrollo de interfaces del mdulo de Programacin Vehicular Programacin de Mdulo de Programacin Vehicular Pruebas de Mdulo de Programacin Vehicular Desarrollo de interfaces del mdulo de Recoleccin MF VG MF VG MF VG MF MF VG VG MF MF VG VG MF MF VG VG

MF MF VG VG

MF MF VG VG MF MF VG VG MF MF MF VG VG VG

Pgina 42

Programacin de Mdulo de Recoleccin

MF MF MF VG VG VG

Pruebas de Mdulo de Recoleccin

MF MF MF VG VG VG

Desarrollo de reportes Creacin de Web Services Creacin de base de datos Interna de Aplicacin Mvil Desarrollo de todas las Interfaces Programacin de Login Pruebas de Login Programacin de Mdulo de Ordenes de Recoleccin Pruebas de Mdulo de Ordenes de Recoleccin Programacin de Mdulo de Mapa de Geolocalizacin Pruebas de Mdulo de Mapa de Geolocalizacin Programacin de Mdulo de Auxilio Mecnico y envo de mensajes Pruebas de Mdulo de Auxilio Mecnico y envo de mensajes Programacin de Mdulo de Justificacin de Parada Prueba de integracin de mdulos de los sistemas Implementacin de Sistema Web y Mvil en Relima Seguimiento y mantenimiento de sistema implementado OP PP OP PP OP PP OP PP OP PP OP PP OP PP OP PP OP PP OP PP OP PP OP PP

MF MF VG VG

OP PP

OP PP

OP PP

OP PP

OP PP OP MF VG PP OP MF VG PP OP MF VG PP

Pgina 43

5.10.

Estndares de programacin

Propsito Cabecera del programa

Gua para desarrollo del programa Comenzar todos los programas con una cabecera descriptiva /*---------------------- Cabecera-------------------------------------------------------------------Nombre Programa: Nombre del programa Nombre: Nombre del programador Fecha : Fecha de creacin del Programa dd-mm-yyyy Descripcin: Descripcin del programa Versin: Versin del programa v.1.00 --------------------------------------------------------------------------------------------------------*/ Provee un resumen del contenido

Formato de cabecera

Lista de contenido

Ejemplo de contenido

/*----------------- Lista de Contenidos---------------------------------------------------------Declaracin de constantes Declaraciones de variables publicas Declaraciones de variables privadas Constructores Propiedades Mtodos pblicos Mtodos privados -------------------------------------------------------------------------------------------------------*/

Instrucciones de reuso

Describe como el programa es usado. Provee un formato para las declaraciones, parmetros, valores, tipos y lmites de los parmetros. Provee advertencias de valores ilegales, sobrecarga de condiciones, u otras condiciones que podran potencialmente resultar en operaciones impropias del programa.

Pgina 44

Ejemplo de reuso

Identificadores

Ejemplo de identificadores

Comentarios

Buen comentario

Instruccin aplicada para: Clculo Matemtico. Propsito: Dividir dos nmeros. Lmites: No se debe dividir entre 0. Contingencias: Se mostrara un mensaje de advertencia detallando el error ocurrido. Uso descriptivo de los nombres de todas las variables, nombre de funciones, constantes y otros identificadores. Todos las variables sern declaradas en minscula y no debe usarse abreviaciones o variables de una sola letra. Ejemplo String descripcin ; /*Los mtodos sern declarados con el prefijo m seguido de underline y el nombre del mtodo como se ve en el siguiente ejemplo: */ m_metodo(){} Documentar el cdigo para que sea legible y entendible con respecto a la operacin. Los comentarios deberan explicar el comportamiento y propsito del cdigo. Al principio de cada mtodo se escribir un comentario describiendo la funcionalidad. Los comentarios debern ser escritos de la siguiente forma: /*Buen comentario*/ Public void m_insertar() { } El comentario no debe estar en la misma lnea que la instruccin.

Mal comentario

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 seccin /*_______________________________ Declaracin de Constantes _________________________________*/

Ejemplo

/*_________________________________ Declaracin de Propiedades _________________________________*/

Pgina 45

Espacios en blanco

Escribir programas con suficiente espacio para que no aparezca conglomerado. Separar cada constructor del programa con al menos un espacio.

Sangra

Identificar cada nivel de las llaves entre una y otra.

int ix = 1; Ejemplo de sangra while (ix > 10) { if (ix == 0) {} } /* La primera letra ser en mayscula , en singular y el nombre de la clase estar relacionada con el contenido*/ Clases Ejemplo : Para una clase relacionada con productos Producto /*El formato del nombre de los paquetes se usar de la siguiente manera:*/

Paquetes

Ejemplo: com.[nombre empresa].[funcionalidad]

Pgina 46

5.11.

Plan de pruebas
Propsito Este documento describe el plan para probar las funcionalidades y caractersticas del los sistemas para la empresa Relima en sus distribuciones Web y Mvil. Este documento est basado sobre los siguientes objetivos: Identificar que la informacin 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 prrafo identifica aquellos elementos que han sido identificados como objetivos de las pruebas. Esta lista representa lo que ser probado. Los detalles de cada prueba sern 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 simultneo en la lectura de registro de las distintas tablas. Verificar el bloqueo realizado durante actualizaciones de registros de las tablas transaccionales Verificar la correcta obtencin de data actualizada.

Pruebas del sistema Las pruebas del sistema estarn divididas en dos bloques distintos uno destinado para el sistema Web y el otro para el Mvil.

Pgina 47

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 vehculos. El mantenimiento de sector. El mantenimiento de dispositivos mviles. La asignacin de dispositivos. El listado de programacin de fichas de control. La importacin de programacin vehicular. Registro de fichas de control de recoleccin. Generacin de reportes. Configuracin de importacin de documentos. La gestin de contraseas.

Sistema Mvil Verificar: Login al sistema. Funcionamiento de los mens. Registro de detalle de recoleccin. Auxilio mecnico. Reporte de paradas. Funcionamiento del mapa con GPS.

Pruebas de la interfaz de usuario Verificar la facilidad de navegacin mediante un ejemplo de pantallazos de las funcionalidades. Verificar que los pantallazos de ejemplo cumplan estndares de GUI.

Pruebas de desempeo Verificar el tiempo de respuesta para acceder a la aplicacin. Verificar el tiempo de respuesta para el proceso de reportes. Verificar el tiempo de respuesta para la carga de datos.

Pgina 48

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 Recoleccin cuente con 10000 registros. Estrategia de pruebas La estrategia de pruebas presenta el alcance recomendado para la prueba de aplicaciones de software. La seccin previa a los requerimientos de pruebas describe que ser probado.

Tipos de pruebas Las consideraciones principales para la estrategia de pruebas son las tcnicas a usarse y los criterios para determinar si la prueba fue completada. Adems de las consideraciones provistas para cada prueba mencionada, las pruebas deberan 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 deberan ser probadas en sistemas separados. Estos sistemas deberan ser probados sin la aplicacin Relima Web (como interface a la data). Revisin exhaustiva sobre el gestor de base de datos a usarse necesita ser realizada para identificar las herramientas y tcnicas que puedan existir para soportar las pruebas a realizarse. Objetivo Asegurar que los mtodos de acceso y los procesos funcionen apropiadamente y sin corrupcin de datos. Tcnicas Invocar cada mtodo de acceso a la BD, intentando con datos vlidos e invlidos. 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.

Pgina 49

Criterio de cumplimiento Todos los mtodos de acceso a la base de datos y procesos funcionan como fueron diseados y sin corrupcin de datos. o Pruebas del sistema Las pruebas sobre la aplicacin deberan enfocarse en requerimientos que puedan ser asociados directamente a casos, y reglas del negocio. Las metas de estas pruebas son verificar la aceptacin, el procesamiento y obtencin de data apropiada, as como la apropiada implementacin de reglas del negocio. Este tipo de pruebas est basado en las tcnicas de caja negra, utilizando para ello la GUI y analizando los resultados. Objetivo Asegurar la navegacin apropiada en la aplicacin; el correcto ingreso de datos, procesamiento y obtencin. Tcnicas Ejecutar cada mdulo plantendose el flujo correspondiente de las acciones que debera realizar teniendo en cuenta los diferentes caminos que puede tomar una accin como al ingresar data errnea que es lo que pasara, si muestra los respectivos mensajes a la hora de ingresar datos, todo esto ser plasmado en un documento que buscar facilitar la verificacin 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 interaccin 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 aplicacin. Adems, las pruebas IU asegura que los objetivos dentro de la IU funcionen como se esperaba y conforme a los estndares de la compaa. Objetivo
Verificar:

a) La navegacin por la aplicacin refleje propiamente las funciones y requerimientos;

Pgina 50

b) los objetos de ventanas y sus caractersticas, como mens medidas posicin, estado y foco sea conforme a lo esperado. Tcnicas Crear modificar las pruebas para cada ventana para verificar apropiadamente la navegacin y los estados de los objetos para cada ventana y objeto de la aplicacin. Criterio de cumplimiento Cada ventana fue verificada exitosamente y aprobada por el cliente. o Pruebas de desempeo Realizar las pruebas que miden los tiempos de respuesta, las tasas de transaccin y otros requerimientos sensibles al tiempo. La meta de las pruebas de desempeo es verificar y validar que los requerimientos de desempeo han sido alcanzados. Este tipo de pruebas es ejecutado muchas veces. Objetivo Validar el tiempo de respuesta para transacciones diseadas o funciones de negocio bajo las siguientes condiciones: a) Volumen normal anticipado, b) Volumen de caso mal anticipado. Tcnicas Usar scripts de carga masiva de datos. Lo scripts deben correr en una sola mquina y debe verse el funcionamiento del sistema en otras mquinas para ver si afecta est el rendimiento. Criterio de cumplimiento Una transaccin / un nico usuario. El cumplimiento exitoso de estas pruebas, es cuando no se encuentran fallas en los tiempos esperados o requerido Mltiples transacciones / mltiples 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, ms all de la carga de trabajo esperada. Adicionalmente, las pruebas evalan las

Pgina 51

caractersticas de desempeo (tiempos de respuestas, tasas de transaccin y otros problemas sensibles a tiempos). Objetivo Verificar el tiempo de respuesta del sistema para transacciones diseada o casos de negocio bajo condiciones de carga de trabajo variada. Tcnicas Pruebas de uso desarrolladas para ciclos de prueba de negocio. Modificar archivos de datos (incrementando el nmero de transacciones) o las pruebas para incrementar el nmero de veces en que una transaccin ocurre. Criterio de cumplimiento Mltiples transacciones / mltiples 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. Mximo (actual o fsicamente capaz) nmero de clientes conectados o simulados. Mltiples usuarios realizando las mismas transacciones contra los mismos datos o cuentas. Tcnicas Pruebas de uso desarrolladas para las pruebas de desempeo. Criterio de cumplimiento Probar recursos limitados, las pruebas debera correr sobre una sola mquina, y la memoria RAM en el servidor debera ser la mnima esperada. El espacio en el disco duro usado por el sistema debera ser

Pgina 52

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 lmites son alcanzados lo que causara que el software falle.las pruebas de volumen adems identifican las cargas continuas de carga o el volumen que el sistema puede manejar por un tiempo dado. Objetivo Verificar que la aplicacin funcione exitosamente bajo los siguientes escenarios de gran volumen: Mximo nmero de clientes conectados, todos realizando la misma funcionalidad de negocio con el peor caso (de desempeo) por un periodo largo de tiempo. Tamao mximo de la BD ha sido alcanzado y mltiples transacciones de consultas y reportes son ejecutados simultneamente. Tcnicas Las pruebas de uso desarrolladas para las pruebas de desempeo. Mltiples clientes deberan ser usados, bien corriendo las mismas pruebas o pruebas complementarias para producir la transaccin del peor caso de volumen por un periodo extendido. Mximo tamao de la base de datos es creado y mltiples clientes lo usan para ejecutar consultas y reportes simultneamente por un periodo extendido. Criterio de cumplimiento Todas las pruebas han sido ejecutadas y los lmites del sistema son alcanzados/excedidos sin que el software falle.

Pgina 53

Recursos Trabajadores

La siguiente tabla muestra las personas asignadas para el equipo de pruebas:

Rol
Test Manager Diseador de pruebas

Responsables
Miguel Flower Oscar De Pirola Jos Luis Apaza Peter Paucar, Valeria Gmez, Miguel Flower, Oscar De Pirola Miguel Flower

Tester

Administrador BD

Sistema Se requieren la siguiente configuracin del sistema: Tres computadoras virtuales (con el software Virtual Box) corriendo Windows Server 2003

Los servidores tendrn 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 sern 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 sern resumidos posteriormente antes de probar, probados, probados condicionalmente o fallidos. En suma, se tendrn los siguientes atributos por cada prueba realizada:

Pgina 54

Estado de la prueba Nmero de la versin 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 sern guardados bajo un control de versiones. Reportes de defectos

En caso de detectarse un defecto se deber documentar dando a conocer el mdulo el que presente las pruebas, las condiciones de hardware y/o navegador usados los cuales sern almacenados en un formato Excel bajo la siguiente plantilla:

Nombre de documento: RP_(mdulo_afectado)_(nombre_del_tester)_(fecha_de_prueba). Cuerpo del documento: Nro. de prueba Tipo Tarea Escenario a probar tem a probar Descripcin del Caso de Prueba Descripcin de los pasos Datos de entrada Resultado Esperado Resultado Real Estado de la prueba Estado del error Tester responsable, Fecha prueba.

Pgina 55

5.12.

Base de datos

5.12.1. MER

Pgina 56

5.12.2. Diccionario de datos


TM_VEHICULO
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_VEHICULO COD_PREFIJO COD_CLIENTE PLACA_VEHICULO IDENT_CREA FEC_REG FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

8 3 5 10 15

PK FK FK

Cdigo nico de la tabla vehculo Define los tipos de vehculo Cdigo nico de la tabla referenciada cliente Placa del vehculo Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_USUARIOS
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_USUARIO USUARIO CLAVE ROL EMPLEADO OBSERVACION IDENT_CREA FEC_REG FLG_ESTADO SUCURSAL

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER VARCHAR2

5 15 15 10 80 80 15

PK

20

Cdigo nico de la tabla usuario Nombre asignado al usuario Clave asignada al usuario Rol del usuario Nombre completo del empleado Comentario sobre el usuario Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad Sede donde opera el usuario

TM_TIPO_RESIDUO
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_RESIDUO DESCRIPCION_RESIDUO

VARCHAR2 VARCHAR2

3 30 15 15

PK

DESCRIPCION_RESIDUO_ VARCHAR2 CORTA IDENT_CREA FEC_REG VARCHAR2 DATE

Cdigo nico de la tabla residuo Descripcin del tipo de residuo Descripcin corta del tipo de residuo Usuario que realiza el registro Fecha en que se inserta el registro

Pgina 57

FLG_ESTADO
CAMPO

NUMBER
TIPO DE DATO

TM_TICKET
LONGITUD INTEGRIDAD

Estado de actividad
DESCRIPCION

SERIE_TICKET COD_TICKET PESO_BRUTO PESO_TARA COD_VEHICULO FEC_REG COD_USUARIO COD_BALANZA PESO_NETO

NUMBER VARCHAR2 NUMBER NUMBER VARCHAR2 DATE VARCHAR2 VARCHAR2 NUMBER

PK 9

FK

5 1

FK FK

Cdigo del ticket Cdigo interno del ticket Peso bruto del vehculo Peso tara del vehculo Cdigo del vehculo Fecha en que se inserta el registro Cdigo del usuario que registra el ticket Cdigo de balanza en donde se gener el ticket Peso neto

TM_SERVICIO
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_SERVICIO

VARCHAR2

3 50 20 15

PK

NOMBRE_SERVICIO VARCHAR2 NOMBRE_SERVICIO_COR VARCHAR2 TA IDENT_CREA FEC_REG FLG_ESTADO VARCHAR2 DATE NUMBER

Cdigo nico de la tabla servicio Nombre del servicio. Nombre corto del servicio Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_SECTOR
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_SECTOR COD_REGION COD_SERVICIO NRO_SECTOR COD_CLIENTE TURNO_SECTOR IDENT_CREA FEC_REG FLG_ESTADO COD_SECTOR_EXT

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER VARCHAR2

6 3 3 12 5 10 15

PK FK FK

Cdigo nico de la tabla sector Cdigo de la regin Cdigo del servicio Nmero del sector Cdigo del cliente Turno asignado al sector Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad Cdigo externo

Pgina 58

TM_RUTA_CONFIGURACION
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_RUTA DESCRIPCION_RUTA NOMBRE_RUTA VERSION_RUTA IDENT_CREA FEC_REG FLG_ESTADO NOMBRE_VERSION NRO_VERSION

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER VARCHAR2 VARCHAR2

3 200 200 50 15

30 2

Cdigo de ruta Ruta de acceso al archivo Nombre del archivo Proveedor para la conexin Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad Descripcin de la versin del archivo Access Cdigo de la versin del archivo Access

TM_REGION
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_REGION NOMBRE_SUCURSAL NOMBRE_SUCURSAL_ CORTA IDENT_CREA FEC_REG FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

3 40 15 15

PK

Cdigo nico de la tabla regin Descripcin de la regin Descripcin corta de la regin Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_PREFIJO_VEHICULO
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_PREFIJO NOMBRE_PREFIJO IDENT_CREA FEC_REG FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

3 40 15

PK

Cdigo nico de la tabla prefijo vehculo Descripcin del prefijo Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

Pgina 59

TM_DEFECTO_VEHICULAR
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_DEFECTO_VEH NOMBRE_DEFECTO

VARCHAR2 VARCHAR2

3 50 15 15

PK

NOMBRE_DEFECTO_CORTO VARCHAR2 IDENT_CREA FEC_REG FLG_ESTADO VARCHAR2 DATE NUMBER

Cdigo nico de la tabla defecto vehicular Descripcin del defecto vehicular Descripcin corta del defecto vehicular Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_PERSONAL
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_PERSONAL COD_TIPO_TRABAJADOR COD_PUESTO APELLIDOS_TRABAJADOR NOMBRES_TRABAJADOR IDENT_CREA FEC_REG


FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE


NUMBER

6 2 10 50 50 15

PK

Cdigo nico de la tabla personal Cdigo del tipo trabajador Cdigo el puesto Apellido del trabajador Nombres del trabajador Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_PROGRAMACION_VEHICULAR
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

PREFIJO_VEHICULAR COD_VEHICULO COD_REGION COD_SERVICIO COD_SECTOR PERIODO AO MES COD_TURNO TIPO_PERSONAL COD_PERSONAL IDENT_CREA FEC_REG FLG_ESTADO FLAG_CIERRE

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER NUMBER

3 8 3 3 6 6 4 2 2 1 4 15

FK FK FK FK FK

Prefijo del vehculo Cdigo del vehculo Cdigo de la regin Cdigo del servicio Cdigo del sector Periodo asignado Ao asignado Mes asignado Cdigo de turno asignado Tipo de personal Cdigo del personal Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad Estado de cierre por mes

Pgina 60

TM_DISPOSITIVO
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_DISPOSITIVO SERIE IDENT_APK IDENT_CREA FEC_REG FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

4 40 40 80

PK

Cdigo nico de la tabla dispositivo Nmero de serie del dispositivo Identificador nico generado en la instalacin del Aplicacin mvil Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_CLIENTES
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_CLIENTE NOMBRE_CLIENTE NOMBRE_CLIENTE_ CORTA NUMERO_CLIENTE RUC_CLIENTE IDENT_CREA FEC_REG FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

5 80 15 8 15 15

PK

Cdigo nico de la tabla cliente Descripcin del cliente Descripcin corta del cliente Numero generado por el ruc Ruc del cliente Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TM_BALANZA
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_BALANZA NOMBRE_BALANZA IDENT_CREA FEC_REG FLG_ESTADO

VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

1 40 15

PK

Cdigo nico de la tabla balanza Nombre de la balanza Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TD_PERSONAL_RECOLECCION
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC COD_PERSONAL IDENT_CREA FEC_REG FLG_ESTADO

NUMBER VARCHAR2 VARCHAR2 DATE NUMBER 6 15

Cdigo de la ficha recoleccin Cdigo del personal Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

Pgina 61

TD_SUPERVISION_FICHA_REC
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC

NUMBER

PK-FK PK 6 10 20 10 80 15

Cdigo de la ficha recoleccin Cdigo correlativo Cdigo de supervisor Kilometraje del vehculo Hora de supervisin Estado de la supervisin Accin tomada a causa de la supervisin Observaciones Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad Lugar donde se realiz la supervisin

SECUENCIAL_SUPERVISION NUMBER COD_SUPERVISOR KILOMETRAJE_VEHICULO HORA_SUPERVISION TIPO_CONFORMIDAD ACCION_TOMADA OBSERVACIONES IDENT_CREA FEC_REG FLG_ESTADO LUGAR_SUPERVISION VARCHAR2 NUMBER VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER VARCHAR2 200

TD_JUSTIFICACION_PARADA
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC SECUENCIA INICIO_PARADA FIN_PARADA MOTIVO IDENT_CREA FEC_REG FLG_ESTADO

NUMBER NUMBER VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER 10 10 2000 80

PK-FK PF

Cdigo de la ficha recoleccin Cdigo correlativo Hora de inicio de parada Hora de fin de parada Motivo de parada Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

Pgina 62

TD_FICHA_RECOLECCION
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC SEC_DETALLE COD_LUGAR_INICIO COD_LUGAR_TERMINO COD_BALANZA HORA_INICIO KILOMETRAJE_INICIO HORA_TERMINO KILOMETRAJE_TERMINO HORA_BALANZA KILOMETRAJE_EN_BALANZA HORA_DESCARGA KILOMETRAJE_DESCARGA TICKET_BALANZA PESO_BRUTO PESO_NETO PESO_TARA IDENT_CREA FEC_REG FLG_ESTADO LATITUD1 LONGITUD1 LOCALIZACION1 LATITUD2 LONGITUD2 LOCALIZACION2

NUMBER NUMBER VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER VARCHAR2 NUMBER VARCHAR2 NUMBER VARCHAR2 NUMBER VARCHAR2 NUMBER NUMBER NUMBER VARCHAR2 DATE NUMBER NUMBER NUMBER VARCHAR2 NUMBER NUMBER VARCHAR2 250 250 15 10 10 10 10 80 80 1 10

PK-FK PK

Cdigo nico de la tabla ficha recoleccin Cdigo correlativo del detalle Lugar de inicio de la recoleccin Lugar de trmino de la recoleccin Cdigo de la balanza Hora de inicio de la recoleccin Kilometraje de inicio Hora de trmino de la recoleccin Kilometraje de termino Hora de pesaje en balanza Kilometraje en balanza Hora de descarga Kilometraje de descarga Cdigo de ticket generado en balanza Peso bruto de vehculo Peso neto Peso tara del vehculo Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad Latitud en balanza Longitud en balanza Localizacin en balanza Latitud en descarga Longitud en descarga Localizacin en descarga

Pgina 63

TD_CAMBIO_CHOFER
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC SECUENCIA_CAMBIO COD_CHOFER_SUST HORA_CAMBIO KILOMETRAJE_CAMBIO LUGAR_CAMBIO IDENT_CREA FEC_REG FLG_ESTADO

NUMBER NUMBER VARCHAR2 VARCHAR2 NUMBER VARCHAR2 VARCHAR2 DATE NUMBER 80 15 6 10

PK-FK PK

Cdigo de la ficha recoleccin Cdigo correlativo Cdigo de chofer sustituto Hora de cambio Kilometraje de cambio Lugar de cambio Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TD_AUXILIO_MECANICO
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC ITEM_AUXILIO COD_DEFECTO_AUX COD_VEHICULO COD_CHOFER

NUMBER NUMBER VARCHAR2 VARCHAR2 VARCHAR2

3 8 6 6 80 10 10 10 10 2500

PK-FK PK FK FK

COD_PERSONA_ATENCION VARCHAR2 LUGAR_LLAMADA_AUX HORA_DEFECTO HORA_LLAMADA HORA_LLEGADA_AUX HORA_TERMINO_AUX IMG_AUXILIO LATITUD LONGITUD LOCALIZACION IDENT_CREA FEC_REG FLG_ESTADO VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER VARCHAR2 VARCHAR2 DATE NUMBER

250 15

Cdigo de ficha recoleccin Cdigo correlativo Cdigo de defecto vehicular Cdigo de vehculo Cdigo de chofer Cdigo de personal que tomo el pedido Lugar desde el envi la llamada de auxilio Hora en el que ocurri la incidencia Hora en que se registr la llamada de auxilio Hora de atencin a la incidencia en el lugar Hora en que se resolvi la incidencia Ruta de la imagen adjunta a la incidencia Latitud Longitud Referencia del lugar de la incidencia Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

Pgina 64

TD_APOYO_SECTOR
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC ITEM_APOYO COD_SECTOR COD_PERS_SOLICITANTE COD_CALLE_INICIO COD_CALLE_FIN HORA_INICIO_APOYO HORA_FIN_APOYO IDENT_CREA FEC_REG FLG_ESTADO

NUMBER NUMBER VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 DATE NUMBER

PK-FK PK 6 200 80 80 10 10 15

Cdigo de ficha recoleccin Cdigo correlativo Cdigo del sector Cdigo del personal solicitante Cdigo de la calle de inicio Cdigo de la calle final Hora de inicio de apoyo Hora fin de apoyo Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

TC_FICHA_RECOLECCION
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_FICHA_REC COD_VEHICULO COD_SECTOR COD_SERVICIO COD_REGION COD_SUCURSAL FECHA TURNO HORA_SALIDA HORA_LLEGADA KILOMETRAJE_SALIDA KILOMETRAJE_LLEGADA

NUMBER VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 VARCHAR2 NUMBER NUMBER 8 6 3 3 3 10 10 10 10

PK FK FK FK FK

Cdigo de ficha recoleccin Cdigo de vehculo Cdigo de sector Cdigo de servicio Cdigo de regin Cdigo sucursal Fecha de asignacin al servicio Turno del servicio Hora de salida del vehculo Hora de llegada del vehculo Kilometraje de salida Kilometraje de llegada Cantidad de combustible consumido Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

CONSUMO_COMBUSTIBLE NUMBER IDENT_CREA FEC_REG FLG_ESTADO TRABAJO TIPO_COMBUSTIBLE FLAG_CIERRE CAMBIO_VEHICULO FLG_IMPORT VARCHAR2 DATE NUMBER VARCHAR2 VARCHAR2 NUMEBR VARCHAR2 NUMBER 10 50 2 25

Detalle del servicio Tipo de combustible Estado de cierre de mes Vehculo de reemplazo en caso de incidencia Estado de importacin

Pgina 65

TB_ASIGNACIONES
CAMPO TIPO DE DATO LONGITUD INTEGRIDAD DESCRIPCION

COD_ASIG COD_VEHICULO COD_DISPOSITIVO IDENT_APK FEC_REG IDENT_CREA FLG_ESTADO

NUMBER VARCHAR2 VARCHAR2 VARCHAR2 DATE VARCHAR2 NUMBER 80 8 4 40

PK PK-FK PK-FK

Cdigo nico que identifica a la tabla asignacin Cdigo de vehculo Cdigo de dispositivo Identificador nico generado en la instalacin de la aplicacin mvil Usuario que realiza el registro Fecha en que se inserta el registro Estado de actividad

Pgina 66

6. CAPTULO VI: MANUAL DE USUARIO


6.1. Manual Sistema Web

Sistema Web Control Operacional


Relima Ambiental S.A

Pgina 67

En el presente documento se detallar las funcionalidades del Sistema Web para el control de viajes de los servicios de recoleccin, mantenimientos de tablas maestras, importaciones de datos desde archivos de Access y como aplicar filtros en los reportes. Requerimiento Recomendado (Hardware) a. Computadora Dual Core, memoria RAM 1 GB. b. Tener instalado un navegador de internet, como por ejemplo: Internet Explorer versin 7 o superior, Mozilla Firefox 7 o superior.

Login
En la fase del Logueo el operario deber ingresar el usuario y password, el sistema autenticar si el usuario existe en la Base de Datos, de no ser as mostrar un mensaje de informacin que no existe el usuario. En caso contrario acceder al sistema Web.

Men Principal
El Men principal mostrar todos los mdulos que deban utilizarse en el sistema. Mantenimiento: Aqu estn las tablas Maestras para su respectivo mantenimiento. Planeamiento: Aqu muestra la importacin y la visualizacin de la data de la Programacin Vehicular. Ejecucin: Aqu aparece el control de Fichas de Recoleccin y cierre de Mes. Datos de Dispositivos: Mantenimiento de dispositivos y la asignacin de dispositivos Reportes Generales: 3 reportes bsicos Seguridad: Incluye el manual y cambio de password.

Pgina 68

Mantenimiento de Tablas Maestras y del Sistema


Men del Formulario Criterios de Insercin

Listado de Registros

Cada formulario de mantenimiento cuenta con una barra de men que contiene 5 controles, Limpiar, Guardar, Modificar, Cancelar, Buscar y Eliminar.

Pgina 69

Cada formulario cuenta con una vista paginada de registros ingresados en la Base de Datos.

Tambin los mantenimientos de las tablas contienen botones de desplazamiento para la comodidad del usuario.

Registrar: El operario deber ingresar los campos que pide el sistema en caso de que no ingrese del todo habr validaciones de advertencia de color rojo indicando que campos faltan. En caso contrario se ingresar el registro en la base de datos y mostrar un mensaje de confirmacin de color verde.

Actualizar:

El operario deber seleccionar primero el registro a actualizar. Si en caso no lo encontrar en la primera vista tiene la opcin de buscarlo en las dems pginas. Una vez seleccionado el registro se cargar la informacin en el formulario y el operario proceder a realizar la modificacin.

Pgina 70

Eliminar: El operario deber seleccionar el registro a eliminar, internamente se capturar el cdigo del registro, cuando seleccione en la opcin Eliminar utilizar el cdigo capturado para eliminar. Una vez eliminado se mostrar un mensaje de confirmacin de color verde. Si surge una excepcin en la Base de Datos se mostrar un mensaje de color rojo informando la excepcin de la eliminacin.

Cancelar: Esta opcin es para salir del formulario en donde se encuentre. Simbolizado por una X en color rojo. Anular: El operario seleccionar el registro y podr cambiar el estado de activo a inactivo mediante los controles (Botones de Opcin) del formulario. Y deber seleccionar la opcin de Modificar (Actualizar). Una vez modificado se mostrar un mensaje de confirmacin de color verde. Si surge una excepcin en la Base de Datos se mostrar un mensaje de color rojo informando la excepcin de la eliminacin. Buscar: Para poder efectuar la bsqueda el operario debe ingresar los criterios de bsqueda en los mismos campos de ingreso de informacin. Al buscar la informacin de los criterios especificados se mostrar en la grilla la lista de registros. Sino encuentra informacin con los criterios especificados se mostrar una barra amarilla informando que no se encontr ninguna informacin con los criterios sealados. Existen controles para validar el ingreso de algunos datos como campos vacos, etc.

Pgina 71

Mdulo de Planeamiento (Programacin Vehicular)


El Mdulo de Planeamiento se divide en 2 Etapas. Configuracin de la ruta de importacin. Aqu se pueden ingresar 2 registros con la ruta de donde se almacenan los archivos de Access. 1. La primera ruta es la direccin del archivo de Datos de Balanza. 2. La segunda ruta es la direccin del archivo de datos de la Programacin Vehicular

Importacin de Datos. En el formulario de importacin aparecern 3 filtros para poder importar los datos: Ao: Muestra el ao actual Mes: Muestra el mes actual Turno: el Operario debe seleccionar que turno a importar Diurno o Nocturno.

Pgina 72

Visualizacin de Datos importados. Este formulario verifica los datos importacin y visualiza la programacin vehicular para el mes actual. Para poder visualizar el listado importado, el operario deber realizar una serie de selecciones en el lado izquierdo del formulario.

La seleccin comienza por la siguiente serie: Ao Regin Turno Mes

A continuacin dar doble clic en el mes. En el Listado se muestran lo siguiente: Vehculo: Cdigo de vehculo asignado. Sector: Cdigo de Sector seleccionado Cdigo: Cdigo del trabajador. Trabajador: Nombre del trabajador. Cargo: Cargo del trabajador.

La importacin de la programacin vehicular se realiza el 1ro de cada mes.

Pgina 73

Mdulo de Ejecucin (Servicios de Recoleccin)


Este mdulo est conforme por una serie de formularios que representan las fichas fsicas que son utilizadas por los trabajadores (recolectores) para el servicio de recoleccin de basura y/o Residuos. Abriendo Ficha de Recoleccin Para abrir una ficha de Recoleccin debe seleccionar una seria de criterios: Ao Regin Turno Mes Da.

A continuacin aparecern unos botones en la parte superior de la pantalla:

Copiar Planeamiento.- Este botn pasa los datos Programados del mdulo de la programacin Vehicular a las Fichas de Recoleccin. Abrir Ficha Recoleccin.- este Botn solo abre la ficha del da seleccionado. Una vez abierto la ficha de recoleccin se mostrar la ficha vaca en caso de que no haya ningn dato en los detalles de la ficha, salvo la cabecera est casi completa. Ficha de Recoleccin Aqu se realizan las Fichas de Recoleccin basados en la programacin vehicular Estas fichas tambin pueden ser modificadas mas no eliminadas. Aqu hay un men especial para Las Fichas de Recoleccin, estas son las Siguientes:

Pgina 74

Nuevo Esta opcin genera una nueva ficha que no ha sido programada pero solo para el mes presente. Guardar Esta opcin guarda la ficha. El formulario tambin tiene validaciones de kilmetros, horas, que primero se debe ingresar antes del ingreso de los detalles de la ficha. Cerrar Esta opcin es para cerrar la ficha de recoleccin. Geolocalizacin Esta opcin muestra la ubicacin del equipo mvil durante el transcurso del servicio de recoleccin asignado. En caso de que no est registrada la posicin del equipo se visualizar la ubicacin de la Empresa Relima.

Detalles de la Ficha de Recoleccin Los Detalles de la Ficha de Recoleccin son la parte ms importante para las fichas. Se tienen 7 tipos de detalle. a. Detalle de ficha de Viajes Son para los viajes de los Servicios de Recoleccin. b. Apoyo a Otro Sector En caso de que se necesite un apoyo adicional se llama a otro vehculo para tal Sector.
Pgina 75

c. Supervisiones Este detalle es para ingresar algn tipo de supervisin en el vehculo. d. Auxilio Mecnico En caso de alguna incidencia en el vehculo se enva una informacin al rea de Control Operacional para solicitar ayuda mecnica. e. Observaciones Generales Aqu solo se detallan algunas observaciones en el vehculo o equipo de recoleccin. f. Cambio de Chofer En caso de un accidente o razones personales puede ocurrir un cambio de chofer de un determinado equipo de Recoleccin. Aqu se detalla la razn. g. Justificacin de Paradas En caso se algn incidente aqu se detalla la razn de alguna demora en su trabajo de recoleccin. Tambin va junto con el detalle de Auxilio Mecnico. Ficha de Recoleccin (No Programados) Este formulario est desarrollado para el registro de fichas de recoleccin no programadas por el rea de Control Operacional en su programacin Vehicular para el presente mes, tambin soporta el registro de fichas para meses pasados.

Las Anteriores especificaciones de las Fichas de Recoleccin Programadas son las mismas en este tipo de Fichas de Recoleccin no Programadas.
Pgina 76

Cierre de Mes Este formulario es para realizar los Cierre de mes de los servicios de Recoleccin cada primera semana de Mes se debe realizar el cierre del mes anterior para tener un mayor control de las Fichas de Recoleccin.

Una vez realizado el Cierre del Mes seleccionado ya no hay regreso para
habilitar el mes cerrado.

Mdulo de Datos Dispositivo


Mantenimiento Dispositivo En este pequeo mdulo solo consiste en registrar los datos del dispositivo para asignarlo a un vehculo posteriormente. Contiene el mismo men de mantenimiento en el Sistema.

Pgina 77

Asignacion de Dispositivos. En este formulario se aplican las Asignaciones de los dispositivos a los vehculos. Para poder operar las fichas de recoleccin desde un mdulo Web.

Mdulo de Reportes
Consiste en 3 tipos de reportes con detalles y sin detalles.

Bsicamente los 3 Reportes tienen este tipo de Estructura. Encaso que no haya datos se mostrar un mensaje de Informacin.

Reporte Produccin por Cliente. Muestra los clientes donde se han realizado algn Servicio de la Empresa. Reporte Control de Vehculos. Muestra los Vehculos que han sido registrados por el Centro de Balanza

Pgina 78

.Reporte informacin de Tickets. Muestra los Tickets que han sido generados por el Centro de Balanza.

Los 3 Reportes tienen la opcin de exportar a documentos tales como PDF, Excel, Word.

Pgina 79

6.2. Manual de Aplicacin Mvil

Aplicacin Mvil Relima Ambiental S.A

Pgina 80

INTRODUCCIN El presente documento es presentado para facilitar el uso a los usuarios del Sistema Mvil Relima creado para la empresa Relima SA para el control de sucesos y manejo de las rdenes asignadas a los trabajadores. El sistema esta creado con la intencin de aprovechar la tecnologa de los Smartphone que en los ltimos aos ha tomado ms importancia en el mercado corporativo dadas las prestaciones tales como el caso de la Geolocalizacin en la que este sistema est basado para dar un mejor control sobre las acciones realizadas por el usuario ya que el trabajo realizado por estos se basa en tiempos y paradas en puntos de recoleccin y desmonte los cuales se podrn corroborar a la vez de proporcionar un mejor servicio en caso de averas o retrasos gracias al sistema. ESPECIFICACIONES TCNICAS
HARDWARE

Para el uso del sistema se necesitara lo siguiente: o o o o o Smartphone Android con pantalla tctil y/o teclado QWERTY. Soporte para GPS y AGPS. Conexin a Redes Inalmbricas (3G/4G). Memoria Interna mnima de 128 MB. Sistema Operativo Android 2.2 o superior. o Cmara Integrada.
SOFTWARE

Sistema Operativo Windows Server 2003 o superior requerido por el WebService El sistema mvil trabaja conjuntamente con un WebService desarrollado en Visual Studio 2010 bajo el lenguaje C# trabajando con el NetFramework 3.5 por lo que ser necesario el servicio de IIS instalado en el Servidor. El sistema trabaja conjuntamente con el sistema Web de Relima por lo cual es necesario la implementacin de ese sistema. PREREQUISITOS DEL SISTEMA o Tener iniciado el Servicio WebServiceRelima en el Servidor. o Haber registrado los datos necesarios para el funcionamiento de envi de correos en el WebServiceRelima. o Tener Levantada la Base de Datos del Sistema Web. o Haber Instalado el APK RelimaAndroid en los dispositivos y haber registrado el cdigo del APK en el Sistema Web a travs del mdulo de asignacin de dispositivos. o Tener salida a Internet a travs de algn proveedor local. o Tener activado el servicio de GPS y de Internet en el dispositivo.

Pgina 81

USO DEL SISTEMA

LOGUEO AL SISTEMA A1

El usuario deber poner su nombre y clave al sistema el cual luego de confirmar con el botn ingresar dar paso a la pantalla de Informacin del Sistema.

Pgina 82

INFORMACION DEL SISTEMA B1

La pgina inicial mostrara si se tiene alguna orden asignada como se ve en la figura superior que es este caso se le asign una orden con el ID 002 as tambin como el nombre del usuario en la parte superior derecha , en el centro de la pantalla se mostrara el ID del APK instalado para que un administrador pueda registrar el dispositivo, se podr salir del sistema a travs del botn Salir del Sistema el cual cerrara la aplicacin ,desde esta pantalla as tambin como tambin en todas las pantallas siguientes se podr acceder a los otros mdulos del sistema a travs del botn men en la parte inferior Izquierda el cual abrir un men para acceder a todos los mdulos del dispositivo como se ve en la siguiente pantalla.

Pgina 83

B2

Como se puede apreciar el Men desplegado permitir acceder a: o rdenes, usado para ingresar al mdulo de Manejo de rdenes de recoleccin o Incidencias, el cual a su vez abrir una ventana donde se podr ingresar a dos tipos de incidencias los cuales seran el de Justificacin de parada y el de Auxilio Mecnico los cuales llevarn a sus mdulos respectivos denominados con el mismo nombre. o Mapa, el cual llevar al mdulo de Localizacin se Usuario. o Informacin, el cual llevar a la pantalla de Informacin del Sistema.

Pgina 84

MANEJO DE RDENES DE RECOLECCION C1

Pgina 85

En este mdulo se proceder a completar la informacin requerida por las pantallas cada vez que se pase por los puntos especficos del recorrido, el formulario se divide en cuatro pantallas uno por cada punto del recorrido, no se podr ingresar ningn tipo de dato si no se tiene asignada una orden, se deber llenar los datos en el orden de las pantallas pasando primero por P1 luego P2,P3 y al final P4, culminando cada pantalla con la respectiva confirmacin de registro presionando el botn de registro como seria en un caso de ejemplo el botn Registrar Recorrido de la pantalla P1, para desplazarse entre las pantallas el usuario podr utilizar las flechas superiores para cmo se ven en la figura C1 , aparte podr ser uso de la pantalla tctil si esta estuviera presente para poder desplazarse con solo deslizar su dedo en la pantalla en el sentido que se desee proceder , al final del recorrido los datos completados en los formularios ser limpiados para prepararse para el siguiente recorrido.

MANEJO DE INCIDENCIAS

JUSTIFICACION DE PARADAS
D1

Pgina 86

El usuario podr reportar cualquier demora que pueda sufrir durante el recorrido para aplicar los ajustes necesarios que se presenten referentes al tiempo perdido durante la interrupcin. Al presionar el rea de escritura de Inicio Parada se abrir una ventana en donde se podr seleccionar la hora desde que comenz la interrupcin, por defecto este marcara la hora actual configurada del dispositivo. Al presionar el rea de escritura de Fin Parada se abrir una ventana en donde se podr seleccionar la hora en que se retom la actividad normal, por defecto este marcara la hora actual configurada del dispositivo. En el rea de Texto correspondiente a Motivo se explicara la razn de la parada del usuario. Al presionar el botn Reportar Parada se enviarn los datos ingresados para concluir el Reporte de parada.

AUXILIO MECANICO
D2

Pgina 87

El usuario en caso de algn desperfecto mecnico o accidente podr reportar por medio de este mdulo sus necesidades especificando el defecto y el lugar en el que se necesita la atencin, aparte de lo especificado se le dar la opciones de adjuntar una imagen al presionar el botn Capturar, el cual permitir tomar una foto o adjuntar una foto de la memoria que ayude con el problema presentado y que se podr apreciar como en la figura D2 en donde la imagen adjuntada es una llanta pinchada, el botn Limpiar borrar la pre visualizacin de la imagen si no se deseara enviar ms la imagen , al presionar el botn Solicitar Auxilio se enviar los datos ingresados al correo de la persona encargada de ver los desperfectos aparte de ser registrados en el sistema.

LOCALIZACIN DE USUARIO
E1

El usuario podr ver su localizacin actual sealizada por un marcador rojo el cual al hacer presionarlo dar la direccin actual, para regular el zoom del mapa se cuenta con dos botones en la parte inferior con el smbolo (-) para alejar el zoom y el smbolo (+) para acercarlo.

Pgina 88

7.

CAPTULO VII: CONCLUSIONES

El sistema desarrollado para Relima Ambiental S.A. ha cumplido con lo requerido por el cliente dando a lugar que se mitiguen muchos de los requisitos diarios que se dan en la empresa, pero se ha visto que an se podra mejorar los procesos que tienen actualmente dando la posibilidad de retomar el proyecto para futuras mejoras. El uso de la tecnologa GPS mejor el flujo del proceso de recoleccin al implementar de modo visual el seguimiento a los recolectores (personal de recoleccin) para tener un mejor control sobre los servicios de recoleccin. Se opt usar la metodologa XP (Xtreme Programming),en la cual el equipo de desarrollo puede adaptar sus tiempos dependiendo del estado que se encuentre el proyecto al no encasillarse un plan al 100% debido a los cambios constantes que el usuario requiera.

Pgina 89

8. CAPTULO VIII: LINKOGRAFA


Links citados a continuacin que han sido utilizados como referencia a lo largo de todo este proyecto.

http://www.extremeprogramming.org/ http://support.microsoft.com/?ln=es-es http://developer.android.com http://www.catedraa.com.ar/cursos/tesis/archivos/formato-tesina.pdf http://www.oracle.com/us/products/database/index.html http://es.wikipedia.org http://www.relima.com.pe/esp/

Pgina 90

9.

CAPTULO IX: ANEXOS

Sistema Actual de Control de Balanza

Pgina 91

Pgina 92

Pgina 93

Pgina 94

Pgina 95

Prototipo de Mantenimientos de Tablas Maestras

Ficha de Control de Recoleccin (Modelo antiguo)

Pgina 96

You might also like