ESCUELA POLITÉCNICA NACIONAL

Transcripción

1 ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS DESARROLLO DEL PORTAL WEB Y DE LA INTRANET PARA LA EMPRESA SERVICIOS Y LUJOS ONLY CARS SC. PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN ELEANA INÉS JEREZ VILLOTA yeleana3000@hotmail.com EDGAR ANDRÉS TELLO LEÓN andytello@hotmail.com DIRECTOR: MSC. ING. MARCOS RAÚL CÓRDOVA BAYAS raul.cordova@epn.edu.ec Quito, Mayo 2012

2 DECLARACIÓN Nosotros, Eleana Inés Jerez Villota, Edgar Andrés Tello León, declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría; que no ha sido previamente presentada para ningún grado o calificación profesional; y, que hemos consultado las referencias bibliográficas que se incluyen en este documento. A través de la presente declaración cedemos nuestros derechos de propiedad intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normatividad institucional vigente. Eleana Inés Jerez Villota Edgar Andrés Tello León

3 CERTIFICACIÓN Certifico que el presente trabajo fue desarrollado por Eleana Inés Jerez Villota y Edgar Andrés Tello León, bajo mi supervisión. Msc. Ing. Raúl Córdova DIRECTOR DE PROYECTO

4 AGRADECIMIENTO A mi Padre Santo por acompañarme durante todos los días de mi carrera y por colmarme de bendiciones, a la virgen María por darme la oportunidad de empezar y terminar mis estudios profesionales. A mis padres Rosita Elena y José Napoleón por su amor y apoyo incondicional, por su arduo trabajo para brindarnos la mejor educación a mí y a mis hermanos. Eleana.

5 AGRADECIMIENTO Agradezco a Dios por todas las bendiciones recibidas, a mi madre Rocío por todo el sacrificio, el esfuerzo, la dedicación y en especial por todo el amor que me ha brindado incondicionalmente en toda mi vida, a mi padre Edgar por que gracias a su perseverancia, enseñanzas y cariño ha hecho de mi un hombre y un profesional de bien, a mis hermanas Salome y Carol por apoyarme y ayudarme siempre, a mis primos y tíos que me han apoyado a lo largo de mi vida. Andrés.

6 DEDICATORIA Este proyecto está dedicado con todo el amor del mundo a mis padres por su cariño y apoyo durante toda mi vida. Eleana.

7 DEDICATORIA Esta tesis se la dedico a mi madre porque en gran parte este título se lo debo a ella. Andrés.

8 CONTENIDO CAPÍTULO 1: PLANTEAMIENTO DEL PROBLEMA CARACTERIZACIÓN DE LA EMPRESA PLAN ESTRATÉGICO DE LA EMPRESA DESCRIPCIÓN DEL PROBLEMA SITUACIÓN ACTUAL Descripción de los procesos internos de la empresa Proceso de adquisición Proceso de inventario Proceso de facturación La empresa maneja su publicidad de la siguiente manera Estructura organizacional de la empresa Departamento de Abastecimiento y Compras Departamento de Marketing y Ventas Departamento Financiero Departamento de Recursos Humanos JUSTIFICACIÓN DE LA METODOLOGÍA METODOLOGÍA SCRUM Características de Scrum Roles en Scrum Roles "Cerdo" Roles "Gallina" Reuniones en Scrum Daily Scrum Reunión de Planificación del Sprint (Sprint Planning Meeting)....15

9 Reunión de Revisión del Sprint Reunión de Retrospectiva del Sprint Sprint Documentos Product backlog Sprint backlog Burn down chart Pila de Entrega y Gráfica de Trabajo Restante Seguimiento Diario del Sprint Pizarra Física Herramienta colaborativa o de Gestión de Proyecto Hoja de Cálculo JUSTIFICACIÓN DE LA METODOLOGÍA EN FUNCIÓN DE LAS CARACTERÍSTICAS DEL PROYECTO JUSTIFICACIÓN DE CMS Y DE LAS HERRAMIENTAS DE DESARROLLO JUSTIFICACIÓN DE CMS Definición del CMS Joomla Funcionalidad de Joomla Características de Joomla Requisitos del Sistema Justificación del CMS en función de los requerimientos para el sitio web JUSTIFICACIÓN DE LAS HERRAMIENTAS DE DESARROLLO Navegador web Lenguaje de programación Base de datos Otras herramientas... 32

10 CAPÍTULO 2: PRIMERA ITERACIÓN DEL SISTEMA ANÁLISIS DE REQUERIMIENTOS DE NEGOCIO DE LA EMPRESA PRESENTACIÓN DEL EQUIPO DE TRABAJO Y ROLES DESARROLLO DEL PRODUCT BACKLOG PLANIFICACIÓN DEL PRIMER SPRINT AVANCE DIARIO DEL SPRINT ELABORACIÓN DE LA VERSIÓN 1.0 DEL SISTEMA ARQUITECTURA Y BASE DE DATOS DEL SISTEMA Arquitectura del Sistema Diseño de Base de Datos GESTIÓN DE AGENTES COMERCIALES Clientes Insertar Cliente Proveedores Insertar Proveedor GESTIÓN DE PRODUCTOS Tipos de Producto Insertar Tipo de Producto Productos Insertar Producto GESTIÓN DE FACTURACIÓN Facturas de los Clientes Insertar Factura Modificar Factura Facturas de los Proveedores Ingresar Factura de Proveedor PRUEBAS DE LA VERSIÓN 1.0 DEL SISTEMA....64

11 PRUEBAS DE GESTIÓN DE AGENTES COMERCIALES Pruebas de Clientes Pruebas de Proveedores PRUEBAS DE GESTIÓN DE PRODUCTOS PRUEBAS GESTIÓN DE FACTURACIÓN...73 CAPÍTULO 3: SEGUNDA ITERACIÓN DEL SISTEMA REVISIÓN DE LA DOCUMENTACIÓN ANTERIOR REVISIÓN DEL SPRINT ANTERIOR REUNIÓN DE RETROSPECTIVA DEL SPRINT PILA DE ENTREGA Y GRÁFICA DE TRABAJO RESTANTE PLANIFICACIÓN DEL SEGUNDO SPRINT AVANCE DIARIO DEL SPRINT ELABORACIÓN DE LA VERSIÓN 2.0 DEL SISTEMA GESTIÓN DE COBROS Y PAGOS Cobros Buscar Movimientos Ver cobros Insertar Cobro Pagos Buscar Movimientos Ver pagos Insertar pago REPORTES Caja Diaria Buscar Detalles de Cierre de Caja Imprimir Detalles de Cierre de Caja Libro Diario Buscar Movimientos...100

12 Imprimir Movimientos COPIAS SEGURIDAD Hacer copia Crear Copia de Seguridad Restaurar copia Buscar Copias de Seguridad Restaurar Copia de Seguridad Eliminar Copia de Seguridad CREACIÓN DE PÁGINA WEB INFORMATIVA Instalación de Joomla Diseño de sitio web Instalación de plantilla Creación de contenidos Creación de menús Creación de módulos PRUEBAS DE LA VERSIÓN 2.0 DEL SISTEMA PRUEBAS DE GESTIÓN DE COBROS Y PAGOS Pruebas de Cobros Pruebas de Pagos PRUEBAS DE REPORTES PRUEBAS DE COPIAS DE SEGURIDAD PRUEBAS DEL SITIO WEB ANÁLISIS DE RESULTADOS..128 CAPÍTULO 4: CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES GLOSARIO..132 BIBLIOGRAFÍA ANEXOS..138

13 ÍNDICE DE FIGURAS Figura 1.1 Organigrama propuesto de la Empresa... 6 Figura 1.2 Pila de Entrega...19 Figura 1.3 Gráfica de Trabajo Restante 19 Figura 1.4 Ejemplos de Tablero de Sprint 20 Figura 1.5 Ejemplos de hoja de cálculo del Sprint..22 Figura 1.6 Proceso de trabajo del Scrum.22 Figura 2.1 Estructura de Historia de Usuario...35 Figura 2.2 Sprint backlog completo Figura 2.3 Burn down chart.45 Figura 2.4 Arquitectura de 3 capas 48 Figura 2.5 Modelo Conceptual de la Base de Datos..50 Figura 2.6 Modelo Físico de la Base de Datos 51 Figura 2.7 Selección del menú Agentes Comerciales 52 Figura 2.8 Interface Insertar Cliente..53 Figura 2.9 Código Insertar Cliente Figura 2.10 Interface Insertar Proveedor..54 Figura 2.11 Código Insertar Proveedor.54 Figura 2.12 Selección del menú Gestión de Productos.55 Figura 2.13 Interface Insertar Tipo de Producto..56 Figura 2.14 Código Insertar Tipo de Producto.56 Figura 2.15 Interface Insertar Producto.57 Figura 2.16 Código Insertar Producto 57 Figura 2.17 Selección del menú Gestión de Facturación..58 Figura 2.18 Interface Insertar Factura...59 Figura 2.19 Código Insertar Factura..59 Figura 2.20 Interface Modificar Factura 60 Figura 2.21 Código Modificar Factura...61 Figura 2.22 Interface Insertar Factura de Proveedor..62 Figura 2.23 Código Insertar Factura de Proveedor.63 Figura 3.1 Gráfica de Trabajo restante de la entrega.86 Figura 3.2 Sprint backlog completo...90

14 Figura 3.3 Burn down chart.89 Figura 3.4 Selección del menú Gestión de Cobros y Pagos.91 Figura 3.5 Interface Buscar Movimientos Cobros...92 Figura 3.6 Código Buscar Movimientos Cobros..93 Figura 3.7 Interface Ver Cobros.93 Figura 3.8 Código Ver Cobros 94 Figura 3.9 Interface Insertar Cobro 94 Figura 3.10 Código Insertar Cobro.95 Figura 3.11 Interface Buscar Movimientos Pagos...95 Figura 3.12 Código Buscar Movimientos Pagos..96 Figura 3.13 Interface Ver Pagos.96 Figura 3.14 Código Ver Pagos 97 Figura 3.15 Interface Insertar Pago...97 Figura 3.16 Código Insertar Pago..98 Figura 3.17 Selección del menú Reportes 98 Figura 3.18 Interface Detalles Cierre Caja...99 Figura 3.19 Código Detalles Cierre Caja..99 Figura 3.20 Interface Imprimir Detalles Cierre Caja..100 Figura 3.21 Código Imprimir Detalles Cierre Caja.100 Figura 3.22 Interface Buscar Movimientos Libro Diario Figura 3.23 Código Buscar Movimientos Libro Diario..101 Figura 3.24 Interface Imprimir Movimientos Libro Diario Figura 3.25 Código Imprimir Movimientos Libro Diario 102 Figura 3.26 Selección del menú Copia Seguridad 103 Figura 3.27 Interface Crear Copia de Seguridad..103 Figura 3.28 Interface Nueva Copia de Seguridad.104 Figura 3.29 Código Crear Copia de Seguridad.104 Figura 3.30 Interface Buscar Copias de Seguridad..105 Figura 3.31 Código Buscar Copias de Seguridad.105

15 Figura 3.32 Interface Copia de Seguridad Restaurada 106 Figura 3.33 Código Restaurar Copia de Seguridad..106 Figura 3.34 Interface Eliminar Copia de Seguridad..107 Figura 3.35 Código Eliminar Copia de Seguridad.107 Figura 3.36 Instalación de Joomla Pantalla Final.108 Figura 3.37 Plantilla Karinpi Ejemplo página de inicio Figura 3.38 Plantilla Karinpi Posiciones Figura 3.39 Instalación de la plantilla Karinpi Pantalla Final.112 Figura 3.40 Página de inicio del sitio web..115

16 ÍNDICE DE TABLAS Tabla 1.1 Comparación entre características del proyecto y características de Scrum..23 Tabla 1.2 Prioridades para selección del CMS 29 Tabla 1.3 Comparación entre requerimientos del sitio Web y características del CMS Joomla..29 Tabla 2.1 Asignación de roles.34 Tabla 2.2 Historia de Usuario Gestión de Clientes...36 Tabla 2.3 Historia de Usuario Gestión de Proveedores..37 Tabla 2.4 Historia de Usuario Gestión de Productos y Tipos de Producto..37 Tabla 2.5 Historia de Usuario Generación de Factura.38 Tabla 2.6 Historia de Usuario Gestión de Facturas de los Proveedores..39 Tabla 2.7 Historia de Usuario Creación de página web informativa..39 Tabla 2.8 Product Backlog de la versión Tabla 2.9 Estimado Horas disponibles..41 Tabla 2.10 Pila del sprint inicial..42 Tabla 2.11 Objetivo del sprint.44 Tabla 2.12 Descripción de la tabla proveedores Tabla 2.13 Caso de Prueba de Aceptación Prueba Inserción de Cliente.65 Tabla 2.14 Caso de Prueba de Aceptación Prueba Modificación de Cliente...66 Tabla 2.15 Caso de Prueba de Aceptación Prueba Eliminación de Cliente.67 Tabla 2.16 Caso de Prueba de Aceptación Prueba Inserción de Proveedor...68 Tabla 2.17 Caso de Prueba de Aceptación Prueba Modificación de Proveedor..68 Tabla 2.18 Caso de Prueba de Aceptación Prueba Eliminación de Proveedor..69 Tabla 2.19 Caso de Prueba de Aceptación Prueba Inserción de Tipo de Producto 70 Tabla 2.20 Caso de Prueba de Aceptación Prueba Inserción de Producto 71 Tabla 2.21 Caso de Prueba de Aceptación Prueba Búsqueda de Producto..72 Tabla 2.22 Caso de Prueba de Aceptación Prueba Modificación de Producto 73

17 Tabla 2.23 Caso de Prueba de Aceptación Prueba Inserción de Factura 74 Tabla 2.24 Caso de Prueba de Aceptación Prueba Búsqueda de Factura..75 Tabla 2.25 Caso de Prueba de Aceptación Prueba Modificación de Factura..76 Tabla 2.26 Caso de Prueba de Aceptación Prueba Visualización de Factura.77 Tabla 2.27 Caso de Prueba de Aceptación Prueba Inserción de Factura de Proveedor...77 Tabla 3.1 Historia de Usuario Cobros.79 Tabla 3.2 Historia de Usuario Pagos..80 Tabla 3.3 Historia de Usuario Caja Diaria..81 Tabla 3.4 Historia de Usuario Libro Diario.81 Tabla 3.5 Historia de Usuario Respaldo de Información.82 Tabla 3.6 Product Backlog de la versión Tabla 3.7 Pila de Entrega 85 Tabla 3.8 Estimado Horas disponibles..87 Tabla 3.9 Pila del sprint inicial 87 Tabla 3.10 Objetivo del sprint.89 Tabla 3.12 Posiciones y distribución de información en la plantilla 111 Tabla 3.13 Categorías y Artículos del sitio web.113 Tabla 3.14 Menús del sitio web 114 Tabla 3.15 Caso de Prueba de Aceptación Prueba búsqueda de movimientos de cobros Tabla 3.16 Caso de Prueba de Aceptación Prueba de inserción de cobro 117 Tabla 3.17 Caso de Prueba de Aceptación Prueba buscar movimientos de pagos Tabla 3.18 Caso de Prueba de Aceptación Prueba de inserción de pago.119 Tabla 3.19 Caso de Prueba de Aceptación Prueba de búsqueda de cierre de caja..120 Tabla 3.20 Caso de Prueba de Aceptación Prueba búsqueda de movimientos de libro diario 120 Tabla 3.21 Caso de Prueba de Aceptación Prueba de creación de copia de seguridad 121 Tabla 3.22 Caso de Prueba de Aceptación Prueba de restauración de copia de seguridad...122

18 Tabla 3.23 Caso de Prueba de Aceptación Prueba de visualización de datos de la empresa..123 Tabla 3.24 Caso de Prueba de Aceptación Prueba de presentación de catálogo de productos..124 Tabla 3.25 Caso de Prueba de Aceptación Prueba de visualización de información de contacto Tabla 3.26 Caso de Prueba de Aceptación Prueba de envío del formulario de contacto Tabla 3.27 Caso de Prueba de Aceptación Prueba de registro de usuarios.127

19 RESUMEN El presente trabajo muestra el proceso de creación de un portal web y el desarrollo del producto de software LendaSoft y su implantación en la Empresa Servicios y Lujos Only Cars SC. que se dedica a la comercialización de productos de seguridad y tuning para vehículos. Toda esta información se encuentra detallada a lo largo de cuatro capítulos descritos brevemente a continuación: En el primer capítulo se estudia la caracterización de la Empresa, es decir conocer toda su información por ejemplo: Datos informativos, Historia, Plan Estratégico y Estructura organizacional. También se analiza como la Empresa lleva actualmente sus procesos de facturación, inventario y publicidad. Y por último se va a justificar el uso de la metodología Scrum y las herramientas de desarrollo. En el segundo capítulo se explica como se planificó y desarrolló la primera iteración del sistema, aquí está incluido el análisis de requerimientos de negocio, la presentación del equipo de trabajo y sus respectivos roles, y el desarrollo de la pila de producto. Se lleva también un registro del avance diario del sprint donde se especifican que actividades se realizaron a lo largo del mismo. El tercer capítulo detalla la segunda iteración del sistema donde se prosigue con el desarrollo del sistema revisando lo que se hizo en el sprint anterior, planificando el nuevo, y actualizando la pila de producto. Se muestra también las actividades que se ejecutaron para la elaboración del sistema y las pruebas respectivas. Finalmente el cuarto capítulo contiene las conclusiones y recomendaciones.

20 PRESENTACIÓN En el Ecuador el desarrollo de las PYME se ha incrementado en los últimos años, necesitando cada vez más de la utilización de sistemas informáticos que ayuden a automatizar sus procesos, gracias al incremento de sus ventas, clientes y publicidad. El presente proyecto describe la aplicación de esta tendencia al implantar el Sistema LendaSoft en la Empresa Servicios y Lujos Only Cars SC. LendaSoft es una aplicación web desarrollada con el propósito de automatizar el proceso de inventario y facturación de la Empresa, ayudando de esta manera a la Empresa a llevar un control adecuado de sus productos y brindar un servicio de mejor calidad a sus clientes. Como parte del proyecto también se elaboró una página web de carácter informativo donde se pretende incrementar la publicidad de la Empresa, el portal web cuenta con un catálogo de productos, un módulo de registro de los clientes, un módulo de Contáctenos y con módulos de información variada. La metodología de desarrollo seleccionada para la elaboración del sistema es Scrum, ya que brinda distintas facilidades justificadas en su momento en esta tesis.

21 1 CAPÍTULO 1: PLANTEAMIENTO DEL PROBLEMA 1.1 CARACTERIZACIÓN DE LA EMPRESA Servicios y Lujos Only Cars SC. es una empresa dedicada a la venta de accesorios para todo tipo de vehículos entre los cuales están: alarmas, equipo de audio, accesorios de tuning, etc. La empresa cuenta también con la venta de equipos para rastreo, monitoreo, control y localización satelital en tiempo real de vehículos. DATOS DE LA EMPRESA NOMBRE: Servicios y Lujos Only Cars SC. DIRECCIÓN Y TELÉFONOS QUITO DIRECCIÓN MATRIZ: Av. Rodrigo de Chávez Oe y Galte (Frente a Ch-Farina). o Telefax.: o Celular: / o onlycarssat@gmail.com. Historia La empresa, tiene una trayectoria de más de quince años en el mercado automotriz, rigiéndose hasta el año 2010 bajo el nombre de Servilujos a cargo del Sr. Kleber Romero. A partir de febrero del 2011 la empresa pasa a ser propiedad de la Sra. Mirian León adoptando el nombre Servicios y Lujos Only Cars SC. Su crecimiento empresarial es progresivo; aumentando tanto su clientela como sus servicios, adquiriendo así nuevos equipos apoyados en el Sistema de Posicionamiento global GPS y la red celular GSM/GPRS de una operadora local. Se cuenta con la mejor tecnología que Kunansoft 1 desarrolla, el mismo que está 1 Kunansoft: Empresa desarrolladora del software de Rastreo Satelital.

22 2 en continuo estudio y evolución. De esta manera se está ofreciendo a sus clientes una cobertura más amplia. El funcionamiento de la empresa es totalmente autónomo en los campos administrativos, financieros y operativos, no recibe aportaciones gubernamentales y crece sustentada en los ingresos que genera su propia actividad comercial PLAN ESTRATÉGICO DE LA EMPRESA La Empresa tiene un plan estratégico basado en procesos para cumplir sus objetivos y metas. Por motivos informativos se transcribirá la siguiente información tomada de documentos proporcionados por el personal de la empresa: Misión Nuestra misión en Servicios y Lujos Only Cars SC. es ofrecer un efectivo servicio de venta e instalación de equipos de seguridad y audio automotriz, que satisfaga las necesidades y supere las expectativas de nuestro cliente y concesionarios, forjando una relación de confianza y de unión a través de nuestro trabajo, protegiendo sus bienes e intereses; por medio de un sistema de gestión de calidad e innovación de servicio. Visión Servicios y Lujos Only Cars SC. Será la empresa líder en el mercado de venta e instalación de equipos de seguridad y audio automotriz, enfocados en el servicio de calidad, rapidez y confianza; alcanzando reconocimiento a nivel nacional y comprometiéndonos a mantener relaciones amigables con nuestros clientes a corto y largo plazo. Objetivos de la Empresa Fortalecer la empresa mediante alianzas estratégicas generando nuevos vínculos que produzcan una mejora continua aprovechando las ventajas de la tecnología computacional y automotriz. Fomentar la innovación como modo de generar nuevas fuentes de crecimiento y satisfacer las necesidades del cliente.

23 3 Utilizar los recursos disponibles eficientemente para lograr desempeño óptimo de la empresa. Ofrecer seguridad y respaldo al cliente externo del buen funcionamiento de los equipos instalados y del servicio de rastreo satelital. Implementar alta tecnología al proceso de rastreo satelital vehicular, renovando constantemente nuestros programas. Mantener siempre al personal capacitado para responder a las exigencias y necesidades del cliente y concesionarios. Evidenciar el liderazgo en la industria automotriz en seguridad y audio a nivel nacional adquiriendo, implementando y gestionando un sistema de inventario y facturación interno. Renovar permanentemente el stock de artículos para la venta e instalación, estando así delante de nuestra competencia DESCRIPCIÓN DEL PROBLEMA SITUACIÓN ACTUAL Actualmente la empresa brinda a sus clientes varios tipos de productos y servicios para vehículos como: 1. seguridad 2. audio y video 3. iluminación 4. autolujos 5. servicio técnico Descripción de los procesos internos de la empresa Proceso de adquisición Los productos de los cuales dispone la empresa se obtienen a través de pedidos a los diferentes proveedores, mediante llamadas telefónicas o cuando el proveedor oferta directamente su producto a la empresa. Los pedidos pueden ser: regulares o exclusivos. Los pedidos regulares son los que se realizan 2 Plan estratégico de la Empresa Servicios y Lujos Only Cars SC: Información proporcionada por la empresa.

24 4 periódicamente y los exclusivos se realizan en razón de las necesidades que poseen determinados clientes. Normalmente los proveedores son los que transportan sus productos a la empresa, pero en los casos exclusivos mencionados anteriormente, cualquiera de los empleados retira los productos directamente desde las bodegas de los proveedores. Al momento de ingresar la mercadería a la empresa el empleado asignado procede a: Revisar si los productos que llegaron concuerdan con el pedido. Revisar si cada ítem del pedido está completo. Revisar que los precios de los productos concuerden con los señalados en el pedido. Hacer la revisión técnica de los productos. Colocar precios en cada uno de los productos La lista de proveedores se encuentra en un archivo de Excel que contiene las siguientes columnas: nombre, número de teléfono celular, número de teléfono convencional y número de fax de los proveedores. Este archivo no tiene ningún tipo de seguridad, es decir es de libre acceso y se puede editar, añadir y borrar registros, esto es un grave problema ya que se pueden perder estos datos que son esenciales para la obtención de productos. Además no existe en la lista de proveedores un registro que indique el tipo de producto o conjunto de productos que ofrece cada proveedor Proceso de inventario Se procede a registrar la mercadería ingresada, en un cuaderno escolar con los siguientes datos: fecha de ingreso, tipo, marca, cantidad de producto. Este registro permite al personal informarse de qué productos tiene para vender. Por lo tanto no existe un control automático del inventario, lo que ha provocado algunos problemas; no se sabe con exactitud qué productos se encuentran disponibles para vender, tampoco cuales son los productos que se deben adquirir.

25 Proceso de facturación Este tiene por función vender la mercadería a los clientes de la empresa. Cuando se realiza una venta la persona encargada, elimina la cantidad de mercadería vendida, del mismo cuaderno citado en el proceso de inventario, y al final del día se realiza una comparación entre el dinero que hay en caja con el registro de las ventas. La facturación se realiza manualmente esto es causa de inconvenientes ya que no se lleva un registro de los clientes, y los vendedores realizan doble trabajo al llenar totalmente a mano las facturas. Debido a que la facturación se realiza manualmente no se encuentra ligada al inventario La empresa maneja su publicidad de la siguiente manera Existe un espacio contratado por la empresa en las páginas amarillas, en el cual se encuentran los números de teléfono y dirección. Además la empresa logra promocionarse por medio de la recomendación de sus clientes satisfechos. La empresa no cuenta con publicidad electrónica, lo que hace más difícil la ubicación del local en donde se venden los productos y los clientes no conocen de antemano los productos que se ofrecen. Lo expuesto hace que exista la necesidad de automatizar los procesos, para esto se propone un sistema de facturación e inventario además del desarrollo de un sitio web para la empresa Servicios y Lujos Only Cars SC Estructura organizacional de la empresa La empresa al ser pequeña no tiene un organigrama establecido, en base a lo estudiado y analizado de la misma, se ha propuesto el organigrama que se presenta en la Figura 1.1:

26 6 Figura 1.1 Organigrama propuesto de la Empresa Se realizará una breve explicación de lo que realiza cada departamento y sus respectivas áreas: Departamento de Abastecimiento y Compras El departamento de Abastecimiento y Compras es el encargado de realizar las adquisiciones de productos y servicios; en el momento debido, con la cantidad y calidad requerida y a un precio adecuado; identificando y comparando a los proveedores y abastecedores, negociando con los mismos para convenir términos de compra, celebrar contratos y colocar pedidos. Responsable Sra. Mirian León Sr. Bolívar Miranda Objetivos: Área de Compras Obtener productos y servicios en cantidad y con calidad necesarias. Obtener productos y servicios al menor costo. Garantizar el mejor servicio posible y pronta entrega por parte del proveedor. Controlar que la calidad de los productos sea la requerida.

27 7 Proveerse de más de una fuente, en previsión de cualquier emergencia que impida la entrega de un proveedor. Anticipar alteraciones en precios, por diferencias en las cotizaciones monetarias, inflación o escases. Desarrollar y mantener buenas relaciones con los proveedores y desarrollar proveedores potenciales. Área de almacén Tener los productos disponibles en el tiempo que son requeridos. Asegurar la cantidad de productos indispensables. Registrar la entrada y salida de productos en el almacén a través de un control de existencia. Funciones: Área de Compras Realizar solicitudes y órdenes de compra, colocar las mismas con el proveedor seleccionado, recibir la mercancía, pagar y contabilizar los productos. Fijar especificaciones para los productos a adquirir. Asegurar la cantidad de productos indispensables. Controlar que la calidad de los productos sea la requerida. Realizar un "Ciclo de manejo físico de los productos", desde el embarque por el proveedor, transporte, recepción y almacenaje. Área de almacén Realizar un control de existencia de productos, que permita conocer el momento en que deba reabastecerse cierto producto en el almacén. Recibir del Área de Compras una copia de cada pedido efectuado. Almacenar la mercancía comprada en la bodega Departamento de Marketing y Ventas El Departamento de Marketing y Ventas se encarga de colocar los productos y servicios, que la empresa comercializa, en los mercados. Realiza las actividades de marketing y de estudio o prospección de mercados. También las de publicidad.

28 8 Responsables: Sr. Edgar Tello Objetivos: Área de Ventas Realizar estrategias de venta. Planear las ventas. Incrementar las ventas rentables. Optimizar las actividades de ventas. Área de Publicidad Persuadir al público con un mensaje comercial para que tome la decisión de comprar u optar por los productos y servicios que la empresa ofrece. Conocer y comprender al consumidor. Funciones: Área de Ventas Supervisar el trabajo de cada vendedor. Solventar de la mejor manera cualquier problema que se presente con un cliente determinado. Planificar el trabajo de ventas. Coordinar llamadas telefónicas a los clientes. Realizar el pronóstico de ventas por mes. Llevar el acumulado diario de las ventas. Área de Publicidad Gestionar recursos de la empresa que ayuden a promocionar los productos y servicios que se ofrecen. Conducir, canalizar y controlar toda la actividad de comunicación publicitaria de la empresa. Determinar el presupuesto destinado a invertir para promocionar los productos y servicios. Supervisar los resultados que se obtienen a través de la publicidad.

29 Departamento Financiero Se encarga de controlar los recursos económicos financieros de la empresa, asignando fondos necesarios para el correcto funcionamiento de cada área. Responsable: Sra. Mirian León Objetivos: Área de Contabilidad. Instrumentar y operar las políticas, normas, sistemas y procedimientos necesarios para garantizar la exactitud y seguridad en la capacitación y registro de las operaciones financieras, presupuestables y de consecución de metas, vigilando la debida observancia de las leyes, normas y reglamentos aplicables a la organización. Área de Tesorería: Organizar y controlar los flujos de efectivo para el pago de gasto. Recibir, concretar, custodiar y manejar los fondos y valores, validando los ingresos y egresos que sean afines al presupuesto autorizado de la empresa. Funciones: Área de Contabilidad. Mantener el correcto funcionamiento de los sistemas y procedimientos contables de la empresa. Formular estados financieros. Investigar y dar solución a los problemas referentes a la falta de información para el registro contable. Preparar y ordenar la información financiera y estadística para la toma de decisiones de las autoridades superiores. Identificar y analizar los ingresos, egresos y gastos de operación de la empresa.

30 10 Área de Tesorería: Almacenar los soportes de todas las transacciones. Realizar periódicamente boletines de los fondos de la empresa. Aplicar las medidas necesarias para la prevención de errores en cuanto al manejo del efectivo, la caja y los bancos. Brindar la información oportuna sobre la liquidez y de todas las transacciones comerciales y financieras Departamento de Recursos Humanos El departamento de Recursos Humanos se encarga de seleccionar, contratar, formar y retener a los empleados de la empresa. Responsables: Sr. César Miranda Objetivos: Área de gestión del personal: Mantener el registro e información sobre el personal. Administrar el pago de las remuneraciones y el cumplimiento de las leyes sociales para el personal. Funciones Área de gestión del personal: Describir las responsabilidades que definen cada puesto laboral y las cualidades que debe tener la persona que lo ocupe. Evaluar el desempeño del personal. Reclutar al personal idóneo para cada puesto. Capacitar y desarrollar programas, cursos y toda actividad que vaya en función del mejoramiento de los conocimientos del personal. Llevar el control de beneficios de los empleados.

31 JUSTIFICACIÓN DE LA METODOLOGÍA La metodología de desarrollo de software se refiere a un conjunto estandarizado de conceptos, prácticas y criterios que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información. El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por un lado están aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, por otro lado están las centradas en otras dimensiones, como el factor humano o el producto software. Para el desarrollo del sistema de facturación e inventario y del sitio web, de la empresa Servicios y Lujos Only Car SC. se toma en cuenta las siguientes consideraciones: El desarrollo del proyecto conlleva tareas delimitadas como: diseñar la base de datos, diseñar el prototipo, elaborar documentación y realizar pruebas del prototipo. El proceso de desarrollo debe ser supervisado por un Jefe o Director de proyecto. Se deben realizar revisiones mensuales de los avances del proyecto. La empresa se encuentra en continuo crecimiento por lo tanto los requisitos del sistema están sujetos a cambios que no exigen características complejas en su implementación. Los requisitos del sistema planteados por el cliente en este caso la empresa deben pasar por listas de prioridad, elaboradas en conjunto con el equipo de desarrollo y el cliente. La empresa se compromete a colaborar con el desarrollo del proyecto y su disponibilidad de tiempo, para realizarlo. La empresa requiere que el sistema sea desarrollado en el menor tiempo posible. La Gerencia General de la Empresa está de acuerdo en resolver problemas habituales y realizar cambios organizativos, formando equipos auto gestionados y multidisciplinares de trabajo, fomentando una cultura de

32 12 gestión basada en la colaboración y en la facilitación llevada a cabo por líderes al servicio del equipo de desarrollo. El tamaño del equipo de desarrollo es de dos personas. El equipo trabaja en un mismo espacio común para maximizar la comunicación. La dedicación del equipo a desarrollar el proyecto es a medio tiempo. Hay una estabilidad de los miembros del equipo. Se da el compromiso conjunto y colaboración de los miembros del equipo METODOLOGÍA SCRUM Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. Aunque Scrum está enfocado a la gestión de procesos de desarrollo de software, puede ser utilizado en equipos de mantenimiento de software Características de Scrum Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (interesados externos o internos), y el Team que incluye a los desarrolladores. Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el equipo), el equipo crea un incremento de software potencialmente entregable (utilizable). El conjunto de características que forma parte de cada sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar. Los elementos del Product Backlog que forman parte del sprint se determinan durante la reunión de Sprint Planning. Durante esta reunión, el Product Owner identifica los elementos del Product

33 13 Backlog que quiere ver completados y los hace del conocimiento del equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint Backlog, lo que significa que los requisitos están congelados durante el sprint. Scrum permite la creación de equipos auto organizados, y la comunicación verbal entre todos los miembros involucrados en el proyecto. Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes pueden cambiar de idea sobre lo que quieren y necesitan, y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido, y centrándose en maximizar la capacidad del equipo de entregar rápidamente y responder a requisitos emergentes. Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van desde notas amarillas "post-it" y pizarras hasta paquetes de software. Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y requiere muy poco esfuerzo para comenzarse a utilizar Roles en Scrum En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y gallinas. Los 'cerdos' están comprometidos a desarrollar el software de forma regular y frecuente, mientras que todos los demás son 'gallinas' que sólo están involucrados en el proyecto, y si este falla, ellos no son los cerdos, es decir, ellos no fueron los que se comprometieron a hacerlo.

34 Roles "Cerdo" Product Owner (Dueño del Producto) El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el producto backlog. Scrum Master (Facilitador) El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el líder del equipo (porque ellos se autoorganizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan. ScrumTeam (Equipo) El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 5 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (diseñador, desarrollador, etc) Roles "Gallina" Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta. Un aspecto importante de una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa gente participe y entregue retroalimentación con respecto a la salida del proceso a fin de revisar y planear cada sprint Reuniones en Scrum Daily Scrum Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto se llama "daily standup". El scrum tiene unas guías específicas:

35 15 La reunión comienza puntualmente a su hora. A menudo hay castigos acordados por el equipo para quien llegue tarde. Todos son bienvenidos, pero sólo los "cerdos" pueden hablar. La reunión tiene una duración fija de 15 minutos, de forma independiente del tamaño del equipo. Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunión corta). La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días. Durante la reunión, cada miembro del equipo contesta a tres preguntas: Qué has hecho desde ayer? Qué es lo que estás planeando hacer hoy? Has tenido algún problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster recordar estos impedimentos) Reunión de Planificación del Sprint (Sprint Planning Meeting) Al inicio del ciclo Sprint (cada 15 o 30 días), una Reunión de Planificación del Sprint se lleva a cabo. Seleccionar qué trabajo se hará. Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomará hacer el trabajo. Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint. Ocho horas como límite. Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la Reunión de Revisión del Sprint y la Retrospectiva del Sprint Reunión de Revisión del Sprint La Revisión del Sprint brinda una inspección del progreso del proyecto al finalizar cada Sprint, basándose en esta inspección se realizan adaptaciones al proyecto.

36 16 Al fin del Sprint el equipo presenta el incremento del producto que pudo construir y junto al Product Owner (Dueño del Producto) verifican el incremento del mismo, se escuchan las experiencias del equipo que surgieron durante el transcurso del Sprint. Finalmente pueden tomar una decisión con información acerca de qué hacer a continuación; en otras palabras, determinan el mejor curso de acción para poder alcanzar el destino. Durante la reunión, todos ven funcionar la demostración del producto en el entorno del cliente o usuario. A medida que se visualiza el producto, consideran qué funcionalidad podría ser agregada durante el próximo Sprint actualizando el product backlog Reunión de Retrospectiva del Sprint Con el objetivo de mejorar de manera continua su productividad y la calidad del producto que está desarrollando, el equipo analiza cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se comprometió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él esperaba o no: Qué cosas han funcionado bien. Cuáles hay que mejorar. Qué cosas quiere probar hacer en la siguiente iteración. Cuáles son los problemas que podrían impedirle progresar adecuadamente. Notar que esta reunión se realiza después de la reunión de revisión del sprint, para poder incorporar su feedback 3 y cumplimiento de expectativas como parte de los temas a tratar en la reunión de retrospectiva. La retrospectiva del sprint es una reunión en la cual el equipo de desarrollo analiza cómo ha ido el sprint desde todos los puntos de vista. Se realiza esta 3 Feedback: Es el proceso de compartir observaciones y sugerencias, con la intención de recabar información para tomar acciones correctivas para el software.

37 17 reunión básicamente para encontrar cómo se puede mejorar. De esta forma se puede incrementar la productividad, tanto en equipo como individualmente Sprint El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado que la duración de los sprints sea constante y definida por el equipo en base a su propia experiencia. Se puede comenzar con una duración de sprint en particular (dos o tres semanas) e ir ajustándolo en base al ritmo del equipo, aunque sin relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los avances logrados, y deberían entregar un producto con características de utilizable por el cliente. Asimismo se recomienda no cambiar los objetivos del sprint o sprint backlog a menos que la falta de estos cambios amenacen al éxito del proyecto. La constancia hace a la concentración y la mejor productividad del equipo de trabajo Documentos Product backlog El product backlog es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requerimientos, funcionalidades deseables, etc., priorizadas según su retorno sobre la inversión. Es el qué va a ser construido, es abierto y cualquiera puede modificarlo. Contiene estimaciones a groso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y, de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos características tienen el mismo valor de negocio la que requiera menos tiempo de desarrollo tendrá probablemente más prioridad, debido a que su ROI será más alto Sprint backlog El sprint backlog es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es

38 18 mayor de 16 horas, deberá ser divida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno Burn down chart La burn down chart es una gráfica mostrada públicamente que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (en casos en que todo va bien en el sentido de que los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes de ser completados en el Backlog). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará o incluso valdrá cero en algunos tramos Pila de Entrega y Gráfica de Trabajo Restante Al llegar a este punto se han terminado algunos elementos, algunos se han añadido, algunos tienen nuevas estimaciones, y algunos se han caído del objetivo de entrega. El Dueño de Producto es responsable de asegurarse que estos cambios se reflejan en la Pila de Entrega (y más ampliamente, en la Pila de Producto). Además, Scrum incluye una gráfica de Trabajo Restante de la Entrega que muestra el progreso hecho hacia la fecha de entrega. Es análogo a la gráfica de Trabajo Restante del Sprint, pero a un nivel más alto (requisitos). En las Figuras 1.2 y 1.3 se muestran ejemplos de la Pila de Entrega y de la Grafica de trabajo Restante respectivamente.

39 19 Figura 1.2 Pila de Entrega Fuente: La Pila de Entrega contiene los siguientes datos: Item: Es el nombre de los requerimientos hechos por el cliente. Prioridad: Es el valor entre 1 y 5 asignado como prioridad por el cliente. Estimación del Valor: Es el valor entre 1 y 5 asignado por el grupo de desarrollo. Estimación de Esfuerzo Inicial: Es el número de horas estimadas de duración de desarrollo del ítem, realizadas por el grupo desarrollador. Estimación de Esfuerzo nueva: Representa la estimación de esfuerzo inicial definida para cada sprint. Figura 1.3 Gráfica de Trabajo Restante Fuente: Seguimiento Diario del Sprint Para llevar el control del formato y soporte del Sprint se puede utilizar una de las siguientes opciones:

40 20 Pizarra física o pared. Herramienta colaborativa o de gestión de proyectos. Hoja de cálculo Pizarra Física Muchos equipos desarrolladores Scrum también usan una herramienta, que es un tablero de tareas escritas en post-its, que cambian durante el Sprint entre columnas etiquetadas según su estado No empezado, En progreso y Completado varios ejemplos se pueden observar en la Figura 1.4, donde cada columna representa un epic o gran historia del producto, que está descrita en la tarjeta de la parte superior. Debajo de la tarjeta con el epic, de cada columna se despliegan las historias de usuario que lo componen, aquí la tarjeta de cada historia de usuario refleja el avance que la misma está teniendo en la pizarra del equipo, a través de una barra de progreso que actualiza a diario el propietario de producto, pintando sobre la tarjeta de la historia. Figura 1.4 Ejemplos de Tablero de Sprint Fuente: Herramienta colaborativa o de Gestión de Proyecto No siempre es posible dejar todo el detalle del sprint en historias de usuario, modificaciones o estimaciones en manos del volátil papel, también es necesario y cómodo gestionar el proyecto mediante alguna herramienta de software. El listado es extenso y hay soluciones más o menos completas, pagadas y libres por ejemplo: Herramientas para Scrum

41 21 Rally Dev Software BaseCamp HQ XPlanner VersionOne Scrum Desk Scrum'd Banana Scrum ScrumWorks TargetProcess IceScrum Sprintometer Brightgreen TinyPM Assembla Bugzilla GreenHopper Herramientas para gestión de proyectos (pero usadas para Scrum también): Trac TimeXchange TeamBox Agilo Otras herramientas usadas de alguna forma en Scrum: TWiki Dokuwiki Eventum Bugzilla JIRA Conchango Sharepoint PVCS Google Documents XStudio: XQual Studio (XStudio) Hoja de Cálculo: Es una herramienta para gestionar el trabajo de las tareas de cada Sprint cuya funcionalidad es: la gestión y registro del Sprint backlog, la generación de los gráficos de evolución o Esfuerzo o Tareas o Individual Se puede observar un ejemplo en la Figura 1.5.

42 22 Figura 1.5 Ejemplos de hoja de cálculo del Sprint Fuente: Resumiendo Scrum como lo muestra la Figura 1.6 se basa en el equipo, en reuniones diarias presididas por el Scrum master para establecer el estado del proyecto, y en la salida cada 30 días de características del proyecto finalizadas y listas para trabajar, el corazón del Scrum es la iteración, que en cada iteración presenta una mejora del funcionamiento del producto final, en cada iteración se evalúa la tecnología y capacidades requeridas, diariamente se pueden modificar el enfoque si se encuentran nuevas dificultades y tratar de remediarlas, el corazón del Scrum es la productividad. Figura 1.6 Proceso de trabajo del Scrum Fuente:

43 JUSTIFICACIÓN DE LA METODOLOGÍA EN FUNCIÓN DE LAS CARACTERÍSTICAS DEL PROYECTO Se expondrá en la Tabla 1.1 si en realidad la metodología seleccionada satisface o no con todas las necesidades del proyecto. No. Características del proyecto Características de Scrum Resultado de satisfacción SI NO Prioridad alta 1 Se cuenta con dos personas en el equipo de desarrollo. Grupo de desarrollo de seis a nueve personas. 2 Se cuenta con la elaboración de listas de prioridad de los requisitos. Especificación de product backlog, que contiene una lista priorizada de requisitos. 3 El proyecto está sujeto a cambios que exigen características de complejidad media en su implementación. 4 Se deben realizar revisiones mensuales de los avances del proyecto. Prioridad baja 5 Se da el compromiso conjunto y colaboración de los miembros del equipo. Especializado en proyectos de media complejidad. Sprints review cada treinta días, en donde se realizan revisiones de los avances del proyecto. Maximizar el compromiso conjunto y colaboración de los miembros del equipo. Tabla 1.1 Comparación entre características del proyecto y características de Scrum Al analizar la Tabla 1.1, se puede observar que si satisfacen las principales características del proyecto y las de Scrum para el desarrollo del sistema, una de las mismas no cumple pero puede ser suplida de la siguiente manera: Se dividirá las tareas de trabajo, es decir cada integrante del equipo realizará las actividades que se le asignen, cumpliendo así con el requerimiento de Scrum. La realización de este proyecto es de complejidad media, ya que está más orientado al desarrollo de los módulos de facturación e inventario. Se lo puede

44 24 desarrollar de manera ágil incluyendo documentación estrictamente necesaria. Además no se cuenta con mucho presupuesto por parte del cliente. La empresa se encuentra en una etapa de automatización de procesos, por esta razón está sujeta de manera constante a cambios en sus requerimientos, por lo que se justifica la utilización de una metodología ágil como Scrum. 1.4 JUSTIFICACIÓN DE CMS Y DE LAS HERRAMIENTAS DE DESARROLLO JUSTIFICACIÓN DE CMS La empresa Servicios y Lujos Only Cars SC. se encuentra en continuo desarrollo, y siente la necesidad de contar con un espacio digital propio, por lo tanto se requiere: Atender las expectativas de los clientes y mostrar la planificación estratégica de la empresa. Que cuente con tres roles básicos para los usuarios, como son: administrador de todo el sitio, usuario autenticado y usuario visitante. Mostrar una lista completa de los productos y servicios que ofrece la empresa. Que cuente con un formulario de contacto en donde los clientes puedan realizar consultas, solicitudes y además este formulario debe servir de puente para el contacto con potenciales clientes. Que cuente con un módulo dinámico y sencillo de imágenes y texto en donde se puedan visualizar las diferentes ofertas y novedades. Publicar banners con las diferentes promociones de los productos y servicios. Consultar y actualizar permanente y simultáneamente la información del sitio web, sin que se afecte el tiempo de respuesta. Permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción. Que sea de fácil mantenimiento y uso.

45 25 Que cuente con una interfaz de administración que incluya: Administración de usuarios y de módulos. En cada una de éstas secciones, se deberá ofrecer todas las opciones de administración disponibles para cada uno. Que cuente con un módulo de seguridad, que evite el ingreso a usuarios no autorizados a la administración del sitio. Validar automáticamente la información contenida en los formularios de ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos tales como obligatoriedad de campos, longitud de caracteres permitida por campo, manejo de tipos de datos, etc Definición del CMS Joomla Un CMS (Content Management System, en inglés), Sistema de gestión de contenidos, es un sistema de software que permite organizar y facilitar la creación de documentos y otros contenidos. Con frecuencia, un CMS es una aplicación web usada para gestionar sitios web y contenidos web. Joomla es un CMS, de código abierto, opensource, muy fácil de instalar, completamente gratuito y en castellano Funcionalidad de Joomla El funcionamiento de Joomla se lleva a cabo gracias a sus dos principales elementos: La base de datos Mysql: allí es donde se guarda toda la información y la mayor parte de la configuración del sistema, de una forma ordenada y en distintas tablas, cada una de ellas almacena información específica y determinada. Los scripts PHP: son los que ejecutan las acciones de consulta y realizan modificaciones en la base de datos convirtiendo los datos en simples páginas web interpretables por los navegadores de Internet (Browsers) y perfectamente inteligibles para los usuarios navegantes y administradores.

46 Características de Joomla Bajo costo de desarrollo y mantenimiento: El costo de producir y mantener un sitio web con Joomla CMS es muy inferior a otras soluciones. Organización del sitio web: Joomla está preparado para organizar eficientemente los contenidos de un sitio en categorías y artículos, lo que facilita la navegabilidad para los usuarios y permite crear una estructura sólida, ordenada y sencilla para los administradores. Desde el panel administrador de Joomla se puede crear, editar y borrar las categorías y artículos del sitio web. Publicación de Contenidos: Con Joomla CMS se puede crear páginas ilimitadas y editarlas desde un sencillo editor que permite formatear los textos con los estilos e imágenes deseados. Los contenidos son totalmente editables y modificables. Escalabilidad e implementación de nuevas funcionalidades : Joomla ofrece la posibilidad de instalar, desinstalar y administrar componentes y módulos, que agregarán servicios de valor a los visitantes del sitio web, por ejemplo: galerías de imágenes, foros, boletines, clasificados, etc. Seguridad: Joomla es uno de los escasos CMS que cuenta con la suficiente participación activa como para generar soluciones precisas en el menor tiempo posible ante las vulnerabilidades que se vayan descubriendo. Administración de usuarios: Joomla es un sistema comunitario que administra diferentes tipos de usuarios con diferentes privilegios de acceso: administradores que gestionen la Web junto con el WebMaster de la misma (el Super

47 27 Administrador) pero también usuarios anónimos y visitantes de la Web que podrán convertirse en autores, editores y publicar sus propios contenidos. Fácil uso: No se necesitan excesivos conocimientos técnicos básicos para instalar y configurar el sitio y apenas ninguno para añadir o editar contenido. Esto facilita muchísimo el trabajo del WebMaster y posibilita además, el trabajo conjunto de otras personas en la Web. Diseño y aspecto estético del sitio: Es posible cambiar todo el aspecto del sitio web tan solo con un par de clics, gracias al sistema de templates que utiliza Joomla. Soporte: Lo soporta una comunidad de desarrollo sólida y muy dinámica. Administrador de Imágenes: Joomla posee una utilidad para subir imágenes al servidor y usarlas en todo el sitio. Módulos: Los módulos son extensiones o complementos de Joomla que permiten añadir información en diferentes posiciones o zonas de la plantilla, normalmente en la página de inicio. El tipo de módulo más importante es el Menú, es un tipo particular de módulo que facilita la navegabilidad por el sitio y cuya configuración se realiza en un apartado específico que es el administrador de menú. Otros tipos de módulo son los siguientes: o Datos de acceso: permite restringir el acceso de ciertos contenidos confidenciales solo para usuarios registrados. o Buscar: es útil para que los usuarios busquen en el sitio web en un buscador interno, utilizando ciertas palabras claves relevantes a la información que desean encontrar.

48 28 o HTML personalizado: En Joomla se puede crear módulos con contenido personalizado. En un módulo de este tipo se puede mostrar, por ejemplo, un texto o imágenes usando el editor por defecto de Joomla de forma semejante a como se hace en un artículo de noticias. Se puede instalar módulos que muestran distintos tipos de información o que añaden diferentes funcionalidades a una web Joomla como: módulo para visualizar texto e imágenes en forma dinámica, módulo de seguridad, módulo contador de visitas, etc. Publicidad: Es posible hacer publicidad en el sitio usando el Administrador de Banners Actualización de contenidos: La sencillez y la economía empleada en el tiempo a la hora de añadir contenidos, impulsa que su actualización sea mucho más frecuente, su información al día, lo que facilita que los visitantes del sitio acudan con mayor regularidad y lo visiten con relativa frecuencia. Formulario de contacto: Joomla posee un formulario de contacto sencillo que permite a los usuarios realizar preguntas, opiniones, consultas, solicitudes y que además cuenta con validación de campos. También existen formularios que se pueden instalar, el más utilizado es Chrono Forms, con este componente se pueden crear formularios personalizados de forma rápida, valida los datos mediante Java Script Requisitos del Sistema Para poder instalar y usar Joomla con éxito, se debe tener un servidor operativo (Apache es el óptimo), una base de datos (MySQL es la mejor) y un intérprete del lenguaje de programación (PHP es el adecuado), todo ello, configurado para que

49 29 dichas aplicaciones puedan trabajar e interactuar conjuntamente. Las versiones mínimas que podemos utilizar y las recomendadas, se muestran en la Tabla 1.2: Software Versión mínima Recomendada Última PHP MySQL Apache Tabla 1.2 Prioridades para selección del CMS Justificación del CMS en función de los requerimientos para el sitio web A continuación se presenta la Tabla 1.3, que muestra si las funcionalidades y características explicadas acerca del CMS Joomla, se ajustan a las necesidades establecidas con anterioridad para la construcción del sitio web de la empresa Servicios y Lujos Only Cars SC. No. Requerimientos del Sitio Web Características del CMS Joomla Resultado de Satisfacción Requerimientos de mayor prioridad Si No 1 Contar con roles básicos para los usuarios, como son: administrador de todo el sitio, usuario autenticado y usuario visitante.. 2 Publicar información referente a la empresa y a los productos y servicios que ofrece. Cuenta con un módulo para administrar diferentes tipos de usuarios como son: administrador de todo el sitio, usuario autenticado y usuario visitante. Permite crear y publicar páginas ilimitadas y editarlas desde un sencillo editor que permite formatear los textos con los estilos e imágenes deseados. 4 Recibir consultas, solicitudes, y permitir el contacto con clientes. Cuenta con un formulario de contacto que permite a los usuarios realizar consultas, preguntas, opiniones y solicitudes. 5 Realizar promociones por medio Cuenta con un administrador

50 30 del internet. de banners para publicidad. 6 Mantener la información La sencillez y la economía actualizada. empleada en el tiempo a la hora de añadir contenidos, impulsa a mantener la información actualizada. Requerimientos de menor prioridad 1 Permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción. 2 Administrar el sitio sin tener amplios conocimientos técnicos. 3 Contar con un módulo dinámico y sencillo de imágenes y texto en donde se puedan visualizar las diferentes ofertas y novedades. 4 Contar con un módulo de seguridad, que evite el ingreso a usuarios no autorizados a la administración del sitio web. 5 Validar automáticamente la información contenida en los formularios de ingreso. 6 Contar con una interfaz de administración para el sitio web. Ofrece la posibilidad de instalar, desinstalar y administrar componentes y módulos. No se necesitan excesivos conocimientos técnicos para administrar el sitio web. Cuenta con varios módulos para visualizar texto e imágenes en forma dinámica. Cuenta con un módulo de seguridad que impide el acceso de usuarios no autorizados a la administración del sitio web. Cuenta con componentes para validar información contenida en los formularios de ingreso. Cuenta con un panel de control en donde el administrador puede gestionar todo el sitio web. Tabla 1.3 Comparación entre requerimientos del sitio Web y características del CMS Joomla De lo que se puede concluir que Joomla es un gestor de contenido dinámico, personalizable y escalable, que sin tener mucha habilidad técnica es fácil de aprender y de usar; además es un CMS de código abierto, esto significa que su uso es libre de costo (gratis), que se ajusta perfectamente a las necesidades de la empresa, por lo tanto se justifica su utilización para el desarrollo del sitio web.

51 JUSTIFICACIÓN DE LAS HERRAMIENTAS DE DESARROLLO Para automatizar los procesos de la empresa Servicios y Lujos Only Cars SC, se desarrollará un sistema web de facturación e inventario. Un sistema o aplicación web está normalmente estructurado como una aplicación de tres capas Navegador web El navegador web ofrece la primera capa, en los equipos de la empresa se encuentra instalado Mozilla Firefox, así como en los equipos de desarrollo, esto facilitará la implementación de la aplicación y la realización de pruebas, por lo tanto se justifica su utilización Lenguaje de programación Un motor capaz de usar alguna tecnología web dinámica constituye la segunda capa, PHP es el lenguaje de programación seleccionado ya que cuenta con las siguientes características: Lenguaje multiplataforma. Orientado al desarrollo de aplicaciones web dinámicas con acceso a información almacenada en una base de datos. El código fuente escrito en PHP es invisible al navegador web y al cliente ya que es el servidor el que se encarga de ejecutar el código y enviar su resultado HTML al navegador. Esto hace que la programación en PHP sea segura y confiable. Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL. Posee una amplia documentación en su sitio web oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda. Cuenta con una biblioteca nativa de funciones sumamente amplia. Es libre, por lo que se presenta como una alternativa de fácil acceso para todos.

52 32 Además el equipo de desarrollo cuenta con experiencia en el uso de este lenguaje. Todas estas características hacen que se justifique la utilización de PHP como lenguaje de programación en el desarrollo de la aplicación Base de datos Una base de datos constituye la tercera capa. El motor de base de datos seleccionado es MySQL, ya que: El equipo de desarrollo tiene experiencia en el uso de esta herramienta. Se encuentra presente en casi todos los servicios de hosting. Escalabilidad y flexibilidad. Es de alto rendimiento. Tiene un robusto soporte transaccional. Posee facilidad de gestión. Tiene bajo coste al ser gratuita Otras herramientas Servidor web, se utilizará Apache ya que: Soporta los lenguajes perl, python, y PHP que es el que se utilizará para el desarrollo de la aplicación. Permite la configuración de mensajes de errores personalizados y negociación de contenido. Permite autenticación de base de datos. Herramienta CASE para diseño, se utilizará Power Designer ya que: Es una herramienta sencilla de diseño El equipo de desarrollo posee experiencia en el uso de esta herramienta. Herramienta para la construcción y edición de aplicaciones web, se utilizará Macromedia Dreamweaver ya que: Permite crear y editar páginas web. Posee excelentes funcionalidades e integración con otras herramientas. Permite crear sitios de forma totalmente gráfica, y dispone de funciones para acceder al código HTML generado.

53 33 Permite la conexión a un servidor, a base de datos, soporte para programación en ASP, PHP, Javascript, cliente FTP integrado, etc. Gestión y edición de Base de Datos, se utilizará phpmyadmin ya que: Es sencilla, pues proporciona una interfaz gráfica bastante intuitiva de utilizar. Es una herramienta que permite administrar bases de datos MySQL, empleando un navegador, tanto para administrarla local como remotamente. Permite crear o eliminar bases de datos; crear, eliminar o alterar tablas; eliminar, editar o agregar campos; ejecutar consultas SQL, etc. Características de phpmyadmin: o Multiplataforma. o Multilenguaje (más de 50). o Licencia GPL (Licencia Pública General). o Está escrito en PHP. Servidor de aplicaciones Web, se utilizará Zend Server Community Edition ya que: Es un servidor de aplicaciones Web PHP rápido y confiable. Es completamente gratuito, y se puede usar en las fases de desarrollo, prueba y producción; asegurando así un entorno consistente a lo largo de todo el ciclo de vida de la aplicación. Proporciona múltiples capacidades para mejorar tiempos de respuesta en las aplicaciones y minimizar la utilización de recursos. Es fácil de instalar, compatible con Linux, Windows y Mac OS X.

54 34 CAPÍTULO 2: PRIMERA ITERACIÓN DEL SISTEMA 2.1 ANÁLISIS DE REQUERIMIENTOS DE NEGOCIO DE LA EMPRESA PRESENTACIÓN DEL EQUIPO DE TRABAJO Y ROLES El equipo de trabajo y roles se exponen en la Tabla 2.1 y están asignados para las siguientes personas: Scrum Master Product Owner Scrum Team Raúl Córdova Mirian León Eleana Jerez Andrés Tello Tabla 2.1 Asignación de roles Esta metodología pide un mayor compromiso del cliente, para el desarrollo ágil, por lo que tendrá la posibilidad de contribuir más, a través de su representante en las reuniones o él mismo DESARROLLO DEL PRODUCT BACKLOG Para iniciar el desarrollo del Sistema LendaSoft 4, es importante construir el Product Backlog, que será elaborado en base a las historias de usuario que se establecieron conjuntamente con el cliente, en la reunión llamada Sprint Planning Meeting, a la misma asistieron el equipo desarrollador y el cliente. Las historias de usuario son breves y concretas, además son el resultado de escuchar al cliente, están escritas con el vocabulario del negocio del cliente, no con vocabulario técnico, su estructura es simple y se presenta en la Figura LendaSoft: Es el nombre que se ha definido para el sistema de Facturación e Inventario que se desarrollará en este proyecto.

55 35 Figura 2.1 Estructura de Historia de Usuario Fuente: Número: Número de la historia de usuario. Usuario: Indica el rol que desempeña el usuario en la empresa. Nombre de la historia: Nombre descriptivo de la historia de usuario. Prioridad en negocio: Hace referencia a cuán importante es la historia de usuario para el negocio, y puede ser: o 5 o 4: representa prioridad alta, siendo 5 más importante que 4. o 3 o 2: representa prioridad media, siendo 3 más importante que 2. o 1: representa prioridad baja. Riesgo en desarrollo: Muestra un calificador del riesgo, y puede ser: o Alto. o Medio. o Bajo.

56 36 Puntos estimados: Los puntos estimados o puntos de historia (PH) es la medida de estimación utilizada, lo que se intenta es dar un valor del tamaño de la historia esto implica una combinación de: - Complejidad: No es lo mismo implementar un alta en un formulario que, por ejemplo, un algoritmo de inteligencia artificial para un juego. - Esfuerzo: Es una tarea que tengo que repetir en muchos sitios? Me va a llevar mucho tiempo aunque sea una cosa fácil? - Riesgo: Estamos trabajando con una tecnología desconocida? Tiene la gente del equipo experiencia en el negocio? Iteración asignada: Indica la iteración a la que se ha asignado la historia de usuario. Responsable: Indica quién será el responsable del desarrollo e implementación de la historia de usuario. Descripción: Muestra una descripción sintetizada de la historia de usuario. Observaciones del equipo de desarrollo: Representa las limitaciones o condiciones especiales en la historia de usuario, realizadas por el Scrum Team. Desde la Tabla 2.2 hasta la Tabla 2.7 se exponen las tarjetas que representan las historias de usuario, para el desarrollo del sistema LendaSoft: Historia de Usuario Número: 1 Usuario: Vendedor Nombre historia: Gestión de Clientes Prioridad en negocio: 5 Riesgo en desarrollo: Bajo Puntos estimados: 3 Iteración asignada: 1 Responsable: Edgar Andrés Eleana Inés

57 37 Descripción: Como vendedor quiero crear, visualizar, buscar, modificar y eliminar los datos relacionados con mis clientes. Quiero registrar el CI o RUC, el nombre, el teléfono, el móvil, la dirección y el correo electrónico. Observaciones del equipo de desarrollo: - No se puede crear un cliente con el mismo CI/RUC. Tabla 2.2 Historia de Usuario Gestión de Clientes Historia de Usuario Número: 2 Usuario: Almacenista Nombre historia: Gestión de Proveedores Prioridad en negocio: 5 Riesgo en desarrollo: Baja Puntos estimados: 3 Iteración asignada: 1 Responsable: Edgar Andrés Descripción: Como almacenista quiero crear, visualizar, buscar, modificar y eliminar los datos relacionados con los proveedores. Quiero registrar el CI o RUC, el nombre, los teléfonos, el móvil, el fax, la dirección y el correo electrónico Observaciones del equipo de desarrollo: - No se puede crear un proveedor con el mismo CI/RUC. Tabla 2.3 Historia de Usuario Gestión de Proveedores Historia de Usuario Número: 3 Usuario: Almacenista Nombre historia: Gestión de Productos y Tipos de Producto Prioridad en negocio: 4 Riesgo en desarrollo: Baja Puntos estimados: 5 Iteración asignada: 1

58 38 Responsable: Edgar Andrés Descripción: Como almacenista quiero insertar, buscar, modificar, ver y eliminar los productos que ingresen a bodega con su respectivo nombre, proveedor, marca, fecha de ingreso y precio, además quiero clasificarlos según su tipo de producto, y que se emitan alertas cuando el stock esté a punto de agotarse. Quiero insertar, buscar, modificar, ver y eliminar tipos de producto. Observaciones del equipo de desarrollo: - Tipos de Producto: son las cinco categorías principales en las que la Empresa dividió a los productos que comercializa. - No se puede eliminar un tipo de producto que tenga productos asociados. Tabla 2.4 Historia de Usuario Gestión de Productos y Tipos de Producto Historia de Usuario Número: 4 Usuario: Vendedor Nombre historia: Generación de Facturas Prioridad en negocio: 4 Riesgo en desarrollo: Medio Puntos estimados: 5 Iteración asignada: 1 Responsable: Eleana Inés Descripción: Como vendedor quiero generar facturas a mis clientes y buscar estas facturas por CI/RUC del cliente, por número o estado de la factura. Para insertar una nueva factura quiero seleccionar un cliente ya registrado o insertar uno nuevo en ese momento, además de la inserción deseo modificar, visualizar y eliminar facturas de mis clientes. Observaciones del equipo de desarrollo: - El estado de la factura puede ser pagada o sin pagar - No se puede eliminar una factura pagada. - La factura no podrá ser generada si no cuenta con número de factura. - No se puede generar una factura con el mismo número de factura. Tabla 2.5 Historia de Usuario Generación de Factura

59 39 Historia de Usuario Número: 5 Usuario: Almacenista Nombre historia: Gestión de Facturas de los Proveedores Prioridad en negocio: 3 Riesgo en desarrollo: Baja Puntos estimados: 4 Iteración asignada: 1 Responsable: Eleana Inés Descripción: Como almacenista quiero registrar las facturas que me entregan mis proveedores y gestionarlas, es decir llevar un control de las que están y no están pagadas, así como también tener la posibilidad de modificar, ver, eliminar y además buscar las facturas por CI/RUC del proveedor, por número de factura o estado. Observaciones del equipo de desarrollo: - El estado de la factura puede ser pagada o sin pagar - No se puede eliminar una factura pagada. - La factura no podrá ser generada si no cuenta con un código de factura. Tabla 2.6 Historia de Usuario Gestión de Facturas de los Proveedores Historia de Usuario Número: 6 Usuario: Administrador Nombre historia: Creación de página web informativa Prioridad en negocio: 1 Riesgo en desarrollo: Baja Puntos estimados: 5 Iteración asignada: 2 Responsable: Eleana Inés Descripción: Como administrador quiero una página web que tenga la siguiente información: datos acerca de mi empresa, los tipos de producto y productos que ofrezco, imágenes de los mismos, información de contacto y que mis clientes puedan hacer preguntas a través de mi página web, además deseo que mis clientes puedan registrarse en mi sitio web. Observaciones del equipo de desarrollo: - Se registrarán las visitas realizadas a la página. Tabla 2.7 Historia de Usuario Creación de página web informativa

60 40 A partir de las historias de usuario se obtiene la pila de producto o Product Backlog que se expone en la Tabla 2.8, en donde las historias de usuario se ordenan según sus prioridades y necesidades, en esta pila se identificará a cada una de ellas como requerimientos, con los siguientes datos: o N: Indica el número de ítem. Módulo: Representa el nombre del módulo al que pertenece el requerimiento, y puede ser: o Inventario o Facturación o Publicidad o ID: Representa un identificador del requerimiento según el módulo al que pertenezca y el orden en el que se presente. Nivel de prioridad: Representa un indicador de importancia para el cliente, evaluado de la siguiente forma: o 5 o 4: representa prioridad alta, siendo 5 más importante que 4. o 3 o 2: representa prioridad media, siendo 3 más importante que 2. o 1: representa prioridad baja. Nombre: Se refiere al nombre del requerimiento del cliente. Descripción: Explica brevemente la funcionalidad del requerimiento. N Módulo ID Prioridad Nombre Descripción 1 Facturación F1 5 Gestión de Clientes 2 Inventario I1 5 Gestión de proveedores Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de clientes. Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de proveedores. 3 Inventario I2 4 Gestión de tipos Se realiza el ingreso, búsqueda,

61 41 de productos y productos 4 Facturación F2 4 Generación de facturas. 5 Inventario I3 3 Gestión de facturas de los proveedores 6 Publicidad P1 1 Creación de página web informativa modificación, visualización y eliminación de tipos de producto y productos. Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de facturas de los clientes Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de facturas de los proveedores. Se realiza la construcción del sitio web de la Empresa con fines publicitarios. Tabla 2.8 Product Backlog de la versión PLANIFICACIÓN DEL PRIMER SPRINT Aquí se especifican las tareas a realizarse para cumplir con los requerimientos de la pila de producto, elaboradas solo por el equipo de desarrollo y no es necesaria la presencia del representante de la Empresa, estas tareas están en orden de prioridad para el cliente que es importante en Scrum. Como resultado de esta reunión se tiene un estimado de horas disponibles de trabajo propuesta por los integrantes del equipo donde cada uno se compromete a trabajar en este tiempo detallado en la Tabla 2.9. Longitud del Sprint 20 Días estimados Días laborables durante el Sprint Miembros del Equipo Días disponibles durante el sprint Entre lunes y viernes excepto feriados Horas disponibles al día Eleana Jerez Andrés Tello Raúl Córdova Tabla 2.9 Estimado Horas disponibles. Total horas disponibles

62 42 Después de haber determinado el tiempo disponible, se prosigue a seleccionar y organizar los requerimientos del Product Backlog comenzando con el primer elemento de la pila, es decir, el de más alta prioridad para el cliente. El grupo de desarrollo también divide las tareas que va a realizar cada miembro del equipo y el estimado inicial de horas de trabajo dedicadas a realizar cada tarea. Se guardan en un documento funcional llamado Pila del Sprint, detallada en la Tabla Tareas del Sprint Voluntario Esfuerzo estimado inicial (horas) Gestión de Clientes Diseño de Arquitectura del Sistema Andrés 10 Diseño de BDD Eleana 15 Construcción de BDD Eleana 5 Ingresar Cliente Andrés 4 Buscar Cliente Andrés 2 Modificar Cliente Andrés 4 Ver Cliente Andrés 2 Eliminar Cliente Andrés 4 Revisión Raúl 2 Gestión de Proveedores Ingresar Proveedor Andrés 4 Buscar Proveedor Andrés 2 Modificar Proveedor Andrés 4 Ver Proveedor Andrés 2 Eliminar Proveedor Andrés 4 Revisión Raúl 2 Gestión de Productos y Tipos de Producto

63 43 Ingresar Tipos de Producto Andrés 2 Buscar Tipos de Producto Andrés 1 Modificar Tipos de Producto Andrés 2 Ver Tipos de Producto Andrés 1 Eliminar Tipos de Producto Andrés 2 Ingresar Producto Andrés 4 Buscar Producto Andrés 3 Modificar Producto Andrés 4 Ver Producto Andrés 2 Eliminar Producto Andrés 4 Revisión Raúl 2 Generación de Facturas Elaborar Factura Eleana 8 Buscar Factura Eleana 4 Modificar Factura Eleana 8 Ver Factura Eleana 2 Eliminar Factura Eleana 8 Revisión Raúl 2 Gestión de Facturas de los Proveedores Ingresar Factura de Proveedor Eleana 4 Buscar Factura de Proveedor Eleana 2 Modificar Factura de Proveedor Eleana 4 Ver Factura de Proveedor Eleana 2 Eliminar Factura de Proveedor Eleana 4 Revisión Raúl 2 Tabla 2.10 Pila del sprint inicial Total 143

64 AVANCE DIARIO DEL SPRINT Una vez empezado el Sprint, se llevan a cabo reuniones diarias claves en Scrum, en la ejecución de las mismas no han surgido mayores inconvenientes y se han llevado a cabo con normalidad. Como se describió en la sección Seguimiento Diario del Sprint, se utilizará la hoja de cálculo para llevar el control del Sprint. Conforme avanza el desarrollo del sistema, a diario hay que actualizar la pila del sprint, en horas estimadas de la cantidad de trabajo que queda por terminar. Poniendo así énfasis no en término de cuanto se hizo en el pasado (un hecho irrelevante en término de progreso), sino en término de cuanto trabajo queda en el futuro. Para detallar esta información primero es necesario especificar el objetivo del Sprint mostrado en la Tabla El resto de información está descrita en la Figura 2.2, donde se encuentran: los requerimientos escogidos a realizarse en este Sprint con cada una de sus tareas, las personas que voluntariamente aceptaron realizarlas, el tiempo en horas estimado y el avance diario en horas del desarrollo del proyecto. SPRINT 1 OBJETIVO Desarrollar la Gestión de Agentes Comerciales, Productos y Facturación. Tabla 2.11 Objetivo del sprint Después de esta actualización, se suma las horas restantes del equipo en total, y se dibuja el burn down chart. Esta gráfica muestra cada día una nueva estimación de cuanto trabajo queda (medido en personas-hora) para terminar las tareas del equipo, detallada en la Figura 2.3.

65 45 Figura 2.3 Burn down chart 2.4 ELABORACIÓN DE LA VERSIÓN 1.0 DEL SISTEMA Al usar Scrum; el desarrollo del sistema se basa en los requerimientos, que están en la pila del producto, en este Sprint se seleccionaron los cinco de más alta prioridad para el cliente, cuyo desarrollo se tratará en esta sección ARQUITECTURA Y BASE DE DATOS DEL SISTEMA Estas actividades fueron incluidas en la primera tarea del Sprint, ya que marcaron el inicio para el desarrollo de todo el sistema LendaSoft Arquitectura del Sistema Al utilizar una metodología ágil, la arquitectura también se sustenta desde su diseño en este principio, con implementación de patrones que garanticen desacoplamiento de los principales módulos que componen la solución y la selección de un modelo arquitectónico que favorezca la evolución del software.

66 Figura2.2 Sprint backlog completo 46

67 47 Como se muestra en la Figura 2.4 la arquitectura consiste en tres capas: Primera Capa: Presentación o Esta capa es donde se presenta el sistema al usuario, le comunica la información y la captura en un mínimo de proceso. o Se comunica únicamente con la capa de negocio. o Es una interfaz gráfica amigable para el usuario. Segunda Capa: Lógica de Negocio o En esta capa se reciben las peticiones del usuario y se envían las respuestas tras el proceso. o Aquí se establecen todas las reglas de negocio que deben cumplirse. o Se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados. o Se comunica con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de él. o El software implicado en esta capa es el motor PHP y el servidor Web Apache. Tercera Capa: Datos o En esta capa reside la información del cliente y se encarga de acceder a la misma. o Está formada por el motor de BDD MySQL y su gestor phpmyadmin, que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

68 48 Figura 2.4 Arquitectura de 3 capas Al usar Scrum como metodología son bienvenidos los cambios, esto conlleva a que la arquitectura sea diseñada para soportar un conjunto de funcionalidades y requerimientos que sean cambiantes, esta visión de arquitectura está atenta a los mismos y los soporta Diseño de Base de Datos Para crear una base de datos se debe realizar dos tipos de diseño: uno lógico y uno físico. El diseño lógico es un modelo abstracto de la base de datos desde una perspectiva de negocio. Luego de obtener el modelo lógico se genera el modelo físico, donde se define el nombre real de cada columna en la base de datos con su respectivo tipo de dato; el modelo físico viene definido por un motor de base de datos, que en este caso es MySQL. De acuerdo a los requerimientos especificados por la empresa en la sección en donde se realizó el desarrollo del Product Backlog, se ha obtenido el modelo conceptual planteado en la Figura 2.5 y a partir de este se ha conseguido el modelo físico de la base de datos que se presenta en la Figura 2.6, ambos esquemas fueron generados mediante el empleo de la herramienta Power Designer justificada en la sección Otras herramientas.

69 49 A continuación se realiza una explicación detallada de una tabla de la base de datos, en este caso la de proveedores que se muestra en la Tabla 2.12, en donde se especifica el nombre, descripción, atributos, tipos de dato, clave primaria y claves foráneas. Nombre de la tabla Descripción proveedores Contiene los datos de los proveedores. Atributo Tipo de Dato Clave Primaria Clave Foránea Descripción codproveedor varchar(13) Identificador. nombre varchar(50) Nombre completo del proveedor. telefono1 varchar(14) Número de teléfono convencional 1 del proveedor. telefono2 varchar(14) Número de teléfono convencional 2 del proveedor. fax varchar(14) Número de fax del proveedor. móvil varchar(14) Número de teléfono móvil del proveedor. varchar(35) Correo electrónico del proveedor. dirección varchar(200) Dirección del proveedor. borrado varchar(1) Si el proveedor ha sido borrado tiene valor igual a 1 caso contrario es igual a 0. Tabla 2.12 Descripción de la tabla proveedores En el Anexo 1 se encuentra el resto de tablas que conforman la base de datos.

70 codfactura fecha Identifier_1... codfacturac fecha Identifier_1... facturasptmp <pi> Integer Date <pi> codproveedor nombre telefono1 telefono2 fax movil direccion borrado Identifier_1... facturastmp <pi> Integer Date <pi> Pfactutmp_factulineatmp proveedores2 <pi> Variable characters (13) Variable characters (50) Variable characters (14) Variable characters (14) Variable characters (14) Variable characters (14) Variable characters (35) Variable characters (200) Variable characters (1) <pi> Cfacturastmp_factulineatmp numlinea cod_tipo_producto codigo cantidad precio importe dcto Identifier_1... <pi> proveedores_productos2 numlineac cod_tipo_producto codigo cantidad precio importe dcto Identifier_1... factulineaptmp <pi> Integer Integer Variable characters (15) Float Float Float Byte <pi> cod_tipo_producto nombre borrado Identifier_1... codproducto referencia nombre marca stock stock_minimo aviso_minimo fecha_ingreso observaciones precio_compra precio_almacen precio_tienda precio_pvp precio_iva borrado Identifier_1... factulineatmp <pi> <pi> <pi> Integer Integer Variable characters (15) Float Float Float Byte productos tiposproducto_productos Pfactulineatmp_factulinea <pi> Integer Variable characters (50) Variable characters (50) Variable characters (50) Integer Integer Variable characters (1) Date Text Float Float Float Float Float Variable characters (1) tiposproducto <pi> Integer Variable characters (50) Variable characters (1) Cfactulineatmp_factulinea cod_tipo_producto codigo cantidad precio importe dcto proveedores_productos factulineap Integer Variable characters (15) Float Float Float Byte numfactura ciudad cod_tipo_producto codigo cantidad precio importe dcto proveedores_factulineap codproveedor nombre telefono1 telefono2 fax movil direccion borrado Identifier_1... codcliente nombre telefono movil direccion borrado Identifier_1... factulinea Pfacturas_factulinea proveedores <pi> Variable characters (13) Variable characters (50) Variable characters (14) Variable characters (14) Variable characters (14) Variable characters (14) Variable characters (35) Variable characters (200) Variable characters (1) <pi> clientes <pi> Variable characters (13) Variable characters (50) Variable characters (14) Variable characters (14) Variable characters (35) Variable characters (200) Variable characters (1) <pi> Variable characters (13) Variable characters (50) Integer Variable characters (15) Float Float Float Byte Cfacturas_factulinea codfactura fecha iva estado totalfactura fechapago borrado Identifier_1... proveedores_librodiario clientes_librodiario clientes_facturas facturasp <pi> Variable characters (20) Date Byte Variable characters (1) Float Date Variable characters (1) <pi> codfactura numfactura ciudad fecha iva estado totalfactura fechavencimiento borrado Identifier_1 Figura 2.5 Modelo Conceptual de la Base de Datos... proveedores_facturasp facturas_librodiario <pi> proveedores_pagos id fecha tipodocumento numpago total Identifier_1... clientes_cobros facturas facturasp_librodiario <pi> facturas_cobros <pi> Integer Variable characters (13) Variable characters (50) Date Byte Variable characters (1) Float Date Variable characters (1) librodiario facturasp_pagos <pi> Integer Date Variable characters (1) Variable characters (30) Float id importe numdocumento fechacobro observaciones Identifier_1... id importe numdocumento fechapago observaciones Identifier_1... <pi> formapago_librodiario <pi> cobros id denominacion fecha hora archivo Identifier_1... <pi> Integer Float Variable characters (30) Date Text pagos <pi> Integer Float Variable characters (30) Date Text codformapago nombrefp borrado Identifier_1... <pi> formapago_pagos formapago_cobros <pi> tabbackup <pi> Integer Variable characters (50) Date Time Variable characters (40) formapago <pi> Integer Variable characters (40) Variable characters (1) 50

71 51 FK_PFACTUTMP_FACTULINEATMP FK_PFACTULINEATMP_FACTULINEA FK_PFACTURAS_FACTULINEA FK_PROVEEDORES_FACTURASP FK_PROVEEDORES_FACTULINEAP FK_TIPOSPRODUCTO_PRODUCTOS FK_FACTURAS_COBROS FK_FORMAPAGO_LIBRODIARIO FK_PROVEEDORES_LIBRODIARIO FK_CLIENTES_LIBRODIARIO FK_CLIENTES_FACTURAS FK_FORMAPAGO_COBROS FK_FORMAPAGO_PAGOS FK_FACTURASP_PAGOS FK_PROVEEDORES_PAGOS FK_CLIENTES_COBROS FK_CFACTURASTMP_FACTULINEATMP FK_CFACTULINEATMP_FACTULINEA FK_CFACTURAS_FACTULINEA FK_FACTURAS_LIBRODIARIO FK_FACTURASP_LIBRODIARIO FK_PROVEEDORES_PRODUCTOS facturasptmp codfactura fecha int date <pk> factulineaptmp numlinea codfactura cod_tipo_producto codigo cantidad precio importe dcto... int int int varchar(15) float float float tinyint <pk> <fk> facturasp codfactura codproveedor fecha iva estado totalfactura fechapago borrado... varchar(20) varchar(13) date tinyint varchar(1) float date varchar(1) <pk> <fk> factulineap codfactura codproveedor numlinea cod_tipo_producto codigo cantidad precio importe dcto... varchar(20) varchar(13) int int varchar(15) float float float tinyint <fk2> <fk3> <fk1> proveedores codproveedor nombre telefono1 telefono2 fax movil direccion borrado... varchar(13) varchar(50) varchar(14) varchar(14) varchar(14) varchar(14) varchar(35) varchar(200) varchar(1) <pk> tiposproducto cod_tipo_producto nombre borrado... int varchar(50) varchar(1) <pk> productos codproducto codproveedor1 codproveedor2 cod_tipo_producto referencia nombre marca stock stock_minimo aviso_minimo fecha_ingreso observaciones precio_compra precio_almacen precio_tienda precio_pvp precio_iva borrado... int varchar(13) varchar(13) int varchar(50) varchar(50) varchar(50) int int varchar(1) date text float float float float float varchar(1) <pk> <fk2> <fk3> <fk1> facturas codfactura codcliente numfactura ciudad fecha iva estado totalfactura fechavencimiento borrado... int varchar(13) varchar(13) varchar(50) date tinyint varchar(1) float date varchar(1) <pk> <fk> clientes codcliente nombre telefono movil direccion borrado... varchar(13) varchar(50) varchar(14) varchar(14) varchar(35) varchar(200) varchar(1) <pk> pagos id codfactura codproveedor codformapago importe numdocumento fechapago observaciones... int varchar(20) varchar(13) int float varchar(30) date text <pk> <fk1> <fk2> <fk3> cobros id codfactura codformapago codcliente importe numdocumento fechacobro observaciones... int int int varchar(13) float varchar(30) date text <pk> <fk2> <fk3> <fk1> formapago codformapago nombrefp borrado... int varchar(40) varchar(1) <pk> librodiario id coddocumento codformapago codcomercial fecha tipodocumento numpago total... int varchar(20) int varchar(13) date varchar(1) varchar(30) float <pk> <fk5> <fk2> <fk1> tabbackup id denominacion fecha hora archivo... int varchar(50) date time varchar(40) <pk> facturastmp codfactura fecha int date <pk> factulineatmp numlinea codfactura cod_tipo_producto codigo cantidad precio importe dcto... int int int varchar(15) float float float tinyint <pk> <fk> factulinea numlinea codfactura numfactura ciudad cod_tipo_producto codigo cantidad precio importe dcto... int int varchar(13) varchar(50) int varchar(15) float float float tinyint <fk1> <fk2> Figura 2.6 Modelo Físico de la Base de Datos

72 52 Para fines de diseño se ha descompuesto el sistema en las siguientes interfaces: Gestión de Agentes Comerciales. Gestión de Productos. Gestión de Facturación. A continuación se exponen las interfaces mas relevantes del sistema LendaSoft con sus respectivas opciones y operaciones, el resto de interfaces se presentan en el Anexo GESTIÓN DE AGENTES COMERCIALES La interface de Agentes Comerciales se visualiza en la Figura 2.7 y está conformada por las opciones de Clientes y Proveedores, las que permitirán conectarse al sistema a través de la capa de aplicación. En donde se realizarán las operaciones de creación, búsqueda, modificación, visualización y eliminación en la capa de datos. Estas interfaces corresponden a las Historias de Usuario 1 y 2 expuestas en la sección en donde se desarrolló el product backlog. Figura 2.7 Selección del menú Agentes Comerciales

73 Clientes En esta sección se detalla como se desarrolló la opción de Clientes en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Insertar Cliente Para acceder a la interface de Insertar Cliente que se presenta en la Figura 2.8, se procede a seleccionar el menú Agentes Comerciales, el sub menú Clientes y el botón Nuevo Cliente. Figura 2.8 Interface Insertar Cliente El código que permite la inserción de los datos del cliente en la base de datos se visualiza en la Figura 2.9. Figura 2.9 Código Insertar Cliente Proveedores En esta sección se muestra como se desarrolló la opción de Proveedores del sistema, mostrando primero la interface, después la parte del código que ejecuta las operaciones descritas en la Historia de Usuario 2.

74 Insertar Proveedor Para acceder a la interface de Insertar Proveedor que se muestra en la Figura 2.10, se procede a seleccionar el menú Agentes Comerciales, el sub menú Proveedores y el botón Nuevo proveedor. Figura 2.10 Interface Insertar Proveedor El código que permite la inserción de los datos del proveedor en la base de datos se presenta en la Figura Figura 2.11 Código Insertar Proveedor GESTIÓN DE PRODUCTOS La interface de Gestión de Productos que se visualiza en la Figura 2.12 está conformada por las opciones Tipos de Producto y Productos, las que permitirán

75 55 conectarse al sistema por medio de la capa de aplicación. En donde se puede realizar las operaciones de creación, búsqueda, modificación, visualización y eliminación en la capa de datos. Estas interfaces corresponden a la Historia de Usuario Tipos de Producto Figura 2.12 Selección del menú Gestión de Productos En esta sección se expone como se desarrolló la opción de Tipos de Producto en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Insertar Tipo de Producto Para acceder a la interface de Insertar Tipo de Producto que se observa en la Figura 2.13, se procede a seleccionar el menú Gestión de Productos, el sub menú Tipos de Producto y el botón Nuevo tipo de producto.

76 56 Figura 2.13 Interface Insertar Tipo de Producto El código que permite la inserción de los datos de un Tipo de Producto en la base de datos se muestra en la Figura Productos Figura 2.14 Código Insertar Tipo de Producto En esta sección se presenta como se desarrolló la opción de Productos en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Insertar Producto Para acceder a la interface de Insertar Producto que se observa en la Figura 2.15, se procede a seleccionar el menú Gestión de Productos, el sub menú Productos y el botón Nuevo Producto.

77 57 Figura 2.15 Interface Insertar Producto El código que permite la inserción de los datos de un nuevo producto en la base de datos se presenta en la Figura Figura 2.16 Código Insertar Producto

78 GESTIÓN DE FACTURACIÓN La interface Gestión de Facturación que se detalla en la Figura 2.17, está conformada por las opciones: Facturas de los Clientes y Facturas de los Proveedores, las que permitirán conectarse al sistema a través de la capa de aplicación. En donde se puede realizar las operaciones de creación, búsqueda, modificación, visualización y eliminación en la capa de datos. Estas interfaces corresponden a las Historias de Usuario 4 y Facturas de los Clientes Figura 2.17 Selección del menú Gestión de Facturación En esta sección se muestra como se desarrolló la opción Facturas de los clientes en el sistema, mostrando primero la interface, y a continuación el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Insertar Factura Para acceder a la interface de Insertar Factura que se observa en la Figura 2.18, se procede a seleccionar el menú Gestión de Facturación, el sub menú Facturas de los Clientes y el botón Nueva factura.

79 59 Figura 2.18 Interface Insertar Factura El código que permite la inserción de los datos de la factura en la base de datos se muestra en la Figura Figura 2.19 Código Insertar Factura

80 Modificar Factura Para acceder a la interface de Modificar Factura que se expone en la Figura 2.20, hay que ingresar a Facturas, donde se selecciona la que se desea modificar. Figura 2.20 Interface Modificar Factura El código que permite la modificación de los datos de la factura en la base de datos se muestra en la Figura 2.21.

81 Figura 2.21 Código Modificar Factura 61

82 Facturas de los Proveedores En esta sección se muestra como se desarrolló la opción Facturas de los Proveedores en el sistema, mostrando primero la interface, y a continuación el fragmento de código que ejecuta las operaciones descritas en la Historia de usuario Ingresar Factura de Proveedor Para acceder a la interface de Insertar Factura que se observa en la Figura 2.22, se procede a seleccionar el menú Gestión de Facturación, el sub menú Facturas de los Proveedores y el botón Nueva factura. Figura 2.22 Interface Insertar Factura de Proveedor El código que permite la inserción de los datos de la factura del proveedor en la base de datos se presenta en la Figura 2.23.

83 Figura 2.23 Código Insertar Factura de Proveedor 63

84 PRUEBAS DE LA VERSIÓN 1.0 DEL SISTEMA Los casos de prueba de Aceptación se han desarrollado en base a las historias de usuario descritas en la sección en donde se desarrolló el Product Backlog, para comprobar la estabilidad y buen funcionamiento del sistema. Los tipos de pruebas realizadas son de tipo alfa, es decir, hechas por el cliente en ambiente de desarrollo. Se realizaron pruebas de todas las operaciones que puede hacer el sistema, pero se presentan las de más relevancia. Los resultados de las pruebas están registrados desde la Tabla 2.13 hasta la Tabla 2.27, donde se relacionan con la historia de usuario correspondiente. Los datos expuestos en estas tablas se detallan a continuación: Código: Es la identificación única de cada caso de prueba. Historia de (Nro. y Nombre): es la identificación de la historia de usuario a la que se refiere el caso de prueba. Descripción: Muestra una breve explicación de lo que se realiza en el caso de prueba. Condiciones de Ejecución: Se muestran las condiciones previas que se necesitan para que el caso de prueba se realice. Entrada (pasos de ejecución): Es la descripción detallada de los pasos que se ejecutaron en los casos de prueba. Resultado esperado: Es el resultado esperado al realizar el caso de prueba. Resultado Obtenido: Es el resultado que se consigue al realizar el caso de prueba. Acciones Correctivas: Son medidas que se deben tomar para corregir un resultado obtenido si éste es diferente del esperado. Evaluación de la prueba: Se muestra el resultado final del caso de prueba y la evaluación puede ser: o Buena. o Media. o Mala.

85 PRUEBAS DE GESTIÓN DE AGENTES COMERCIALES Las pruebas de Agentes Comerciales están conformadas por las pruebas de gestión de clientes y proveedores, correspondientes a las Historias de usuario 1 y 2 respectivamente Pruebas de Clientes En esta sección se detalla como se realizaron las siguientes pruebas de Gestión de Clientes del sistema: Pruebas de inserción de Cliente. Pruebas de modificación de Cliente. Pruebas de eliminación de Cliente. Caso de Prueba de Aceptación Código: 1 Historia de (Nro. y Nombre): 1 Gestión de Clientes Nombre de Caso de Prueba: Prueba Inserción de Cliente Descripción: Se procede a insertar los siguientes datos de un nuevo cliente: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico y verificar que se almacene en la Base de Datos. Condiciones de Ejecución: El campo de correo electrónico tiene su formato característico, en el campo CI/RUC se ingresan máximo 13 caracteres, ingresar el campo Nombre. Entrada (pasos de ejecución): 1. Acceder a la interface Insertar Cliente. 2. Ingresar los datos correspondientes en los campos: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico. Se ingresaron datos erróneos 3. Dar clic en el botón Aceptar. 4. Se muestran los datos ingresados y se validan que sean correctos. 5. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla de ingreso correcto de datos. Resultado Obtenido: El sistema permitió que se ingresen datos incorrectos. Acciones Correctivas: Realizar las respectivas validaciones en los campos del formulario.

86 66 Evaluación de la prueba: Media No se mostró el resultado esperado, pero se ejecutaron las respectivas acciones correctivas. Tabla 2.13 Caso de Prueba de Aceptación Prueba Inserción de Cliente Caso de Prueba de Aceptación Código: 2 Historia de (Nro. y Nombre): 1 Gestión de Clientes Nombre de Caso de Prueba: Prueba Modificación de Cliente Descripción: Se procede a modificar uno o varios de los siguientes datos de un cliente existente: Nombre, Teléfono, Móvil, Dirección, Correo electrónico y verificar que se realicen los cambios en la Base de Datos. Condiciones de Ejecución: Que el cliente a modificarse exista, el campo de correo electrónico tiene su formato característico. Entrada (pasos de ejecución): 1. Acceder a la interface Clientes. 2. Señalar el cliente que se desea modificar. 3. Modificar uno o varios de los datos correspondientes a los campos: Nombre, Teléfono, Móvil, Dirección, Correo electrónico. Los datos modificados fueron erróneos. 4. Dar clic en el botón Aceptar. 5. Se muestran los datos modificados y se verifican que sean correctos. 6. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos. Resultado Obtenido: El sistema permitió que se ingresen datos erróneos al modificarlos. Acciones Correctivas: Validar que los datos que se modifiquen sean correctos Evaluación de la prueba: Media No se mostró el resultado esperado pero se ejecutaron las acciones correctivas Tabla 2.14 Caso de Prueba de Aceptación Prueba Modificación de Cliente

87 67 Caso de Prueba de Aceptación Código: 3 Historia de (Nro. y Nombre): 1 Gestión de Clientes Nombre de Caso de Prueba: Prueba Eliminación de Cliente Descripción: Se procede a eliminar un cliente seleccionado y verificar que se realice el cambio en la Base de Datos. Condiciones de Ejecución: Que el cliente a eliminarse exista y se muestre en la interface de clientes. Entrada (pasos de ejecución): 1. Acceder a la interface Clientes. 2. Señalar el cliente que se desea eliminar. 3. Eliminar el cliente seleccionado. 4. Dar clic en el botón Aceptar. 5. Se muestra que el cliente ha sido eliminado. 6. Dar clic en Aceptar. Resultado esperado: La eliminación del cliente. Resultado obtenido: Se eliminó al cliente seleccionado. Acciones Correctivas: Ninguna Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.15 Caso de Prueba de Aceptación Prueba Eliminación de Cliente Pruebas de Proveedores Aquí se presenta como se realizaron las siguientes pruebas de Gestión de Proveedores del sistema: Pruebas de inserción de Proveedor. Pruebas de modificación de Proveedor. Pruebas de eliminación de Proveedor.

88 68 Caso de Prueba de Aceptación Código: 4 Historia de (Nro. y Nombre): 2 Gestión de Proveedores Nombre de Caso de Prueba: Prueba Inserción de Proveedor Descripción: Se procede a insertar los siguientes datos de un nuevo proveedor: CI o RUC, Nombre, Teléfono 1, Teléfono 2, Móvil, Fax, Dirección, Correo electrónico y verificar que se almacenen en la Base de Datos. Condiciones de Ejecución: El campo de correo electrónico tiene su formato característico, en el campo CI/RUC se ingresan máximo 13 caracteres, ingresar el campo Nombre. Entrada (pasos de ejecución): 1. Acceder a la interface Insertar Proveedor. 2. Ingresar los datos correspondientes en los campos: CI o RUC, Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico. Se ingresaron datos erróneos. 3. Dar clic en el botón Aceptar. 4. Se muestran los datos ingresados y se verifican que sean correctos. 5. Dar clic en Aceptar Resultado esperado: El despliegue de la pantalla de Ingreso correcto de datos. Resultado obtenido: El sistema permitió el ingreso de datos erróneos. Acciones correctivas: Validar los datos que se ingresan. Evaluación de la prueba: Media No se mostró el resultado esperado pero se ejecutaron las acciones correctivas. Tabla 2.16 Caso de Prueba de Aceptación Prueba Inserción de Proveedor Caso de Prueba de Aceptación Código: 5 Historia de (Nro. y Nombre): 2 Gestión de Proveedores Nombre de Caso de Prueba: Prueba Modificación de Proveedor Descripción: Se procede a modificar uno o varios de los siguientes datos de un proveedor existente: Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico y verificar que se realicen los cambios en la Base de Datos.

89 69 Condiciones de Ejecución: Debe existir el proveedor a modificarse, el campo de correo electrónico tiene su formato característico. Entrada (pasos de ejecución): 1. Acceder a la interface Proveedores. 2. Señalar el proveedor que se desea modificar. 3. Modificar uno o varios de los datos correspondientes a los campos: Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico. Al modificar los datos estos fueron erróneos. 4. Dar clic en el botón Aceptar. 5. Se muestran los datos modificados y se verifican que sean correctos. 6. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos. Resultado obtenido: El sistema permitió que al modificarse los datos éstos fueran erróneos. Acciones Correctivas: Validar los datos modificados Evaluación de la prueba: Media No se mostró el resultado esperado, pero se ejecutaron las acciones correctivas. Tabla 2.17 Caso de Prueba de Aceptación Prueba Modificación de Proveedor Caso de Prueba de Aceptación Código: 6 Historia de (Nro. y Nombre): 2 Gestión de Proveedores Nombre de Caso de Prueba: Prueba Eliminación de Proveedor Descripción: Se procede a eliminar un proveedor seleccionado y verificar que se realice el cambio en la Base de Datos. Condiciones de Ejecución: Que el proveedor a eliminarse exista y se muestre en la interface de proveedores. Entrada (pasos de ejecución): 1. Acceder a la interface Proveedores.

90 70 2. Señalar el proveedor que se desea eliminar. 3. Eliminar el proveedor seleccionado. 4. Dar clic en el botón Aceptar. 5. Se muestra que el proveedor ha sido eliminado. 6. Dar clic en Aceptar. Resultado esperado: La eliminación del proveedor. Resultado obtenido: Se permitió la eliminación del proveedor seleccionado. Acciones Correctivas: Ninguna. Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.18 Caso de Prueba de Aceptación Prueba Eliminación de Proveedor PRUEBAS DE GESTIÓN DE PRODUCTOS En esta sección se detallan las siguientes pruebas: Pruebas de inserción de Tipos de Producto. Pruebas de inserción de Producto. Pruebas de búsqueda de Producto. Pruebas de modificación de Producto. Caso de Prueba de Aceptación Código: 7 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos. Nombre de Caso de Prueba: Prueba Inserción de Tipo de Producto Descripción: Se procede a insertar el nombre de un nuevo tipo de producto y se verifica que se almacene en la Base de Datos. Condiciones de Ejecución: Ingresar datos en el campo Nombre. Entrada (pasos de ejecución): 1. Acceder a la interface Insertar Tipo de Producto. 2. Ingresar el nombre del nuevo Tipo de Producto.

91 71 3. Dar clic en el botón Aceptar. 4. Se muestran los datos ingresados y se verifican que sean correctos. 5. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla de Ingreso correcto del nombre. Resultado obtenido: Se ingresó el nuevo Tipo de Producto Acciones Correctivas: Ninguna Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.19 Caso de Prueba de Aceptación Prueba Inserción de Tipo de Producto Caso de Prueba de Aceptación Código: 8 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos Nombre de Caso de Prueba: Prueba de Inserción de Producto Descripción: Se procede a insertar los siguientes datos de un nuevo producto: Referencia, Nombre, Marca, Stock, Stock mínimo, Fecha de ingreso, Observaciones, Precio de compra, Precio de almacén, Precio de Tienda, PVP, precio con IVA. Y los siguientes datos: Tipo de producto, Proveedor 1, Proveedor 2 y Aviso mínimo se escogen del combo mostrado en la interface y verificar que se almacenen en la Base de Datos. Condiciones de Ejecución: Ingresar el campo Referencia, Descripción, Observaciones y Nombre. Entrada (pasos de ejecución): 1. Acceder a la interface Insertar Producto. 2. Ingresar y escoger los datos descritos anteriormente en sus correspondientes campos. Estos datos fueron erróneos 3. Dar clic en el botón Aceptar. 4. Se muestran los datos ingresados y se verifican que sean correctos. 5. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla de Ingreso correcto de datos. Resultado obtenido: El sistema valida algunos campos pero otros no.

92 72 Acciones Correctivas: Validar todos los campos. Evaluación de la prueba: Media El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas. Tabla 2.20 Caso de Prueba de Aceptación Prueba Inserción de Producto Caso de Prueba de Aceptación Código: 9 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos Nombre de Caso de Prueba: Prueba Búsqueda de Producto Descripción: Se procede a la búsqueda de un producto según el tipo de producto al que pertenece, su referencia o su nombre y se verifica que se muestre el producto seleccionado. Condiciones de Ejecución: Que el producto que se desea encontrar se encuentre registrado en la lista de productos. Entrada (pasos de ejecución): 1. Acceder a la interface Productos. 2. Hacer clic en la lupa de la sección Buscar Producto. 3. Escoger uno o varios criterios de búsqueda en este caso: Tipo de Producto, Referencia o Nombre. 4. Clic en Buscar y escoger el producto seleccionado. 5. Dar clic en Buscar. Resultado esperado: Que se muestre el producto buscado. Resultado obtenido: Se mostró el producto seleccionado. Acciones correctivas: Ninguna Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.21 Caso de Prueba de Aceptación Prueba Búsqueda de Producto

93 73 Caso de Prueba de Aceptación Código: 10 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos Nombre de Caso de Prueba: Prueba Modificación de Producto Descripción: Se procede a modificar uno o varios de los siguientes datos de un producto existente: Referencia, Nombre, Marca, Stock, Stock mínimo, Fecha de ingreso, Observaciones, Precio de compra, Precio de almacén, Precio de Tienda, PVP, precio con IVA. Y los siguientes datos: Tipo de producto, Proveedor 1, Proveedor 2 y Aviso mínimo; se modifican escogiendo los datos mostrados en el combo de la interface y verificar que se realicen los cambios en la Base de Datos. Condiciones de Ejecución: Que el producto a modificarse esté registrado en la lista de productos. Entrada (pasos de ejecución): 1. Acceder a la interface Productos. 2. Señalar el producto que se desea modificar. 3. Modificar uno o varios de los datos descritos anteriormente. Estas modificaciones se ingresaron con datos erróneos. 4. Dar clic en el botón Aceptar. 5. Se muestran los datos modificados y se verifican que sean correctos. 6. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos. Resultado obtenido: El sistema validó algunos campos pero no todos Acciones Correctivas: Validar todos los campos. Evaluación de la prueba: Media El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas correspondientes. Tabla 2.22 Caso de Prueba de Aceptación Prueba Modificación de Producto PRUEBAS GESTIÓN DE FACTURACIÓN En esta sección se detallan las siguientes pruebas: Pruebas de inserción de Facturas de Clientes.

94 74 Pruebas de búsqueda de Facturas de Clientes. Pruebas de modificación de Facturas de Clientes. Pruebas de visualización de Facturas de Clientes. Pruebas de inserción de Factura de Proveedores. Caso de Prueba de Aceptación Código: 11 Historia de (Nro. y Nombre): 4 Generación de Facturas Nombre de Caso de Prueba: Prueba Inserción de Factura Descripción: Se procede a escoger o ingresar un nuevo cliente, luego se inserta el número de factura, luego se agrega uno o varios productos registrados y se verifica que se almacene la información en la Base de Datos. Condiciones de Ejecución: Ingresar el Núm. de Factura, que los productos que se vayan a agregar estén previamente registrados en el sistema. Entrada (pasos de ejecución): 1. Acceder a la interface Insertar Factura. 2. Agregar un cliente. 2.1 Nuevo Cliente: Se ingresan estos datos: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico y clic en Aceptar. Se ingresaron datos erróneos. 2.2 Cliente Registrado: Se hace clic en la lupa, y se escoge uno de los clientes mostrados. 3. Se ingresa el Número de la Factura. 4. Se agrega un producto haciendo clic en la lupa. 5. Se busca y escoge el producto que se desea vender. 6. Se ingresa la cantidad de productos vendidos. 7. Si se realiza un descuento ingresarlo en el campo Dcto. 8. Dar clic en Agregar. 9. Dar clic en Aceptar. Resultado esperado: El ingreso de la nueva factura. Resultado obtenido: Se ingresó la nueva factura con datos erróneos. Acciones correctivas: Se validaron todos los campos del formulario.

95 75 Evaluación de la prueba: Media El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas correspondientes. Tabla 2.23 Caso de Prueba de Aceptación Prueba Inserción de Factura Caso de Prueba de Aceptación Código: 12 Historia de (Nro. y Nombre): 4 Generación de Facturas Nombre de Caso de Prueba: Prueba Búsqueda de Factura Descripción: Se procede a la búsqueda de una factura según los siguientes criterios: el Estado (se refiere a pagada o sin pagar), el Número de Factura, el cliente y se verifica que se muestre la factura seleccionada. Condiciones de Ejecución: Que la factura que se desea encontrar se encuentre registrada en el sistema. Entrada (pasos de ejecución): 1. Acceder a la interface Facturas. 2. Hacer clic en la lupa de la sección CI/RUC de cliente. 3. Escoger el cliente deseado e ir al paso Insertar el Número de Factura e ir al paso Escoger el Estado de Factura e ir al paso Dar clic en Buscar Resultado esperado: Que se muestre la factura buscada. Resultado obtenido: Se mostró la factura buscada. Acciones correctivas: Ninguna Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.24 Caso de Prueba de Aceptación Prueba Búsqueda de Factura

96 76 Caso de Prueba de Aceptación Código: 13 Historia de (Nro. y Nombre): 4 Generación de Facturas Nombre de Caso de Prueba: Prueba Modificación de Factura Descripción: Se procede a modificar uno o varios de los siguientes datos existentes: Ciudad, Fecha, Código de Factura. Se puede modificar el cliente ingresando uno nuevo o añadiendo otro existente. Se pueden agregar nuevos productos existentes en el sistema, se pueden eliminar los productos ya agregados en la factura y se verifica que se realicen los cambios en la Base de Datos. Condiciones de Ejecución: Que la factura esté en estado Sin pagar. Entrada (pasos de ejecución): 1. Acceder a la interface Facturas. 2. Señalar la factura que se desea modificar. 3. Modificar uno o varios de los datos descritos anteriormente. Al modificar los datos éstos fueron erróneos. 4. Dar clic en el botón Aceptar. 5. Se muestran los datos modificados y se verifican que sean correctos. 6. Dar clic en Aceptar. Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos. Resultado obtenido: El sistema permitió que algunos campos modificados se ingresen con datos erróneos. Acciones correctivas: Validar todos los campos del formulario. Evaluación de la prueba: Media El sistema no mostró el resultado esperado pero se ejecutaron las respectivas acciones correctivas. Tabla 2.25 Caso de Prueba de Aceptación Prueba Modificación de Factura

97 77 Caso de Prueba de Aceptación Código: 14 Historia de (Nro. y Nombre): 4 Generación de Facturas Nombre de Caso de Prueba: Prueba Visualización de Factura Descripción: Se procede a visualizar una Factura con todos sus datos: CI/RUC del cliente, Nombre del Cliente, Número de Factura, Ciudad Fecha y el detalle de los productos de la factura. Condiciones de Ejecución: Que la factura esté registrada en el Sistema. Entrada (pasos de ejecución): 1. Acceder a la interface Facturas. 2. Señalar el la factura que se desea visualizar. 3. Hacer clic en la lupa Visualizar. 4. Se muestran los datos de la factura. 5. Dar clic en Aceptar. Resultado esperado: El despliegue de datos de la Factura seleccionada. Resultado obtenido: Se visualizó la factura seleccionada. Acciones correctivas: Ninguna Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.26 Caso de Prueba de Aceptación Prueba Visualización de Factura Caso de Prueba de Aceptación Código: 15 Historia de (Nro. y Nombre): 5 Gestión de Facturas de Proveedores Nombre de Caso de Prueba: Prueba Inserción de Factura de Proveedor Descripción: Se procede a escoger un proveedor, luego se copia el código de la factura, se inserta el número de teléfono del proveedor, la fecha de compra, luego se agrega uno o varios productos que hayan sido vendidos a la empresa por el proveedor ingresado previamente, y se verifica que se almacene la información en la Base de Datos. Condiciones de Ejecución: que el proveedor esté registrado en el sistema, solo se pueden agregar productos del proveedor ingresado en la misma factura.

98 78 Entrada (pasos de ejecución): 1. Acceder a la interface Insertar Factura. 2. Agregar un Proveedor registrado. 3. Se hace clic en la lupa, y se escoge uno de los proveedores registrados. 4. Se ingresa el Código de la factura. 5. Se agrega la Fecha de la factura. 6. Se agrega el teléfono del proveedor. 7. Se agrega un producto haciendo clic en la lupa. 8. Se escoge el producto adquirido. 9. Se ingresa la cantidad de productos del proveedor. 10. Si existe descuento por parte del proveedor ingresarlo en el campo Dcto. 11. Dar clic en Agregar. 12. Si se agrega un nuevo producto regresar al paso 7 caso contrario seguir con el paso Dar clic en Aceptar. Resultado esperado: El ingreso de la nueva factura Resultado obtenido: Se ingresó una nueva factura Acciones correctivas: Ninguna Evaluación de la prueba: Buena Se mostró el resultado esperado. Tabla 2.27 Caso de Prueba de Aceptación Prueba Inserción de Factura de Proveedor

99 79 CAPÍTULO 3: SEGUNDA ITERACIÓN DEL SISTEMA Al iniciar la segunda iteración del sistema es necesario realizar una reunión para revisar el sprint anterior, hacer la retrospectiva del sprint para actualizar la pila del producto y empezar con la nueva iteración del sistema; todo este proceso se describe a continuación. 3.1 REVISIÓN DE LA DOCUMENTACIÓN ANTERIOR REVISIÓN DEL SPRINT ANTERIOR Para llevar a cabo la revisión del sprint, se efectúo una reunión entre el equipo de desarrollo y el cliente donde se inspeccionó el producto de software. El cliente hizo las siguientes observaciones: Cambiar el formato de los formularios de ingreso de proveedores y clientes. Cambiar datos del formato en la presentación de reportes. El grupo desarrollador ha tomado en cuenta estas observaciones. En esta reunión se entregó un prototipo del sistema al cliente que incorporó las interfaces desarrolladas, las mismas que se muestran de la sección a la sección 2.4.4, que fue construido de manera ordenada siguiendo lo acordado y planificado en el sprint dentro del tiempo propuesto, fue aprobado y de buena aceptación por parte del cliente, en el Anexo 3 se encuentra el acta de entrega. En esta reunión también se definieron nuevas historias de usuario, que se muestran desde la Tabla 3.1 hasta la Tabla 3.6, para actualizar la pila de producto, tomando en cuenta el formato explicado en la sección Historia de Usuario Número: 7 Usuario: Vendedor Nombre historia: Cobros Prioridad en negocio: 3 Riesgo en desarrollo: Medio Puntos estimados: 4 Iteración asignada: 2

100 80 Responsable: Edgar Andrés Eleana Inés Descripción: Como vendedor quiero buscar información referente a las facturas emitidas a mis clientes y poder visualizar: el número de factura, el nombre del cliente, el monto que queda pendiente por cobrar y la fecha que se realiza el cobro. Observaciones del equipo de desarrollo: - Se va a visualizar el Estado de la factura que puede ser pagada o sin pagar. - Se pueden registrar: los cobros pendientes, la fecha en la que se realizó el cobro y la forma de pago. Tabla 3.1 Historia de Usuario Cobros Historia de Usuario Número: 8 Usuario: Almacenista Nombre historia: Pagos Prioridad en negocio: 3 Riesgo en desarrollo: Medio Puntos estimados: 4 Iteración asignada: 2 Responsable: Edgar Andrés Eleana Inés Descripción: Como almacenista quiero buscar información referente a las facturas registradas de mis proveedores y poder visualizar: el número de factura, el nombre del proveedor, el monto que queda pendiente por pagar y la fecha que se realiza el pago. Observaciones del equipo de desarrollo: - Se va a visualizar el Estado de la factura que puede ser pagada o sin pagar. - Se pueden registrar: los pagos pendientes, la fecha en la que se realizó el pago y la forma de pago. Tabla 3.2 Historia de Usuario Pagos

101 81 Historia de Usuario Número: 9 Usuario: Administrador Nombre historia: Caja Diaria Prioridad en negocio: 2 Riesgo en desarrollo: Baja Puntos estimados: 3 Iteración asignada: 2 Responsable: Edgar Andrés Descripción: Como administrador quiero buscar por fecha detalles del cierre de caja, como: el valor neto, el valor del iva, el total al contado y poder imprimir los resultados. Observaciones del equipo de desarrollo: Ninguna. Tabla 3.3 Historia de Usuario Caja Diaria Historia de Usuario Número: 10 Usuario: Administrador Nombre historia: Libro Diario Prioridad en negocio: 2 Riesgo en desarrollo: Medio Puntos estimados: 3 Iteración asignada: 1 Responsable: Eleana Inés Descripción: Como administrador quiero buscar por un período determinado de tiempo las ventas y compras efectuadas y que se muestre: la fecha, si es compra o si es venta, el número de la factura, el nombre del agente comercial, la forma de pago y el valor de la venta o compra. Observaciones del equipo de desarrollo: Ninguna. Tabla 3.4 Historia de Usuario Libro Diario

102 82 Historia de Usuario Número: 11 Usuario: Administrador Nombre historia: Respaldo de Información Prioridad en negocio: 1 Riesgo en desarrollo: Baja Puntos estimados: 2 Iteración asignada: 2 Responsable: Eleana Inés Descripción: Como administrador quiero realizar copias de seguridad de toda la información que gestiono, para luego poder restaurarla. Observaciones del equipo de desarrollo: - No se podrá cambiar la fecha y hora en la que se cree una copia de seguridad. Tabla 3.5 Historia de Usuario Respaldo de Información Definidas las nuevas historias de usuario se procedió a actualizar la pila de producto, agregando dos módulos: el Módulo de Reportes con su ID R y el Módulo de Respaldos con su ID RE. La pila quedó como se muestra en la Tabla 3.6. N Módulo ID Prioridad Nombre Descripción 1 Facturación F1 5 Gestión de Clientes 2 Inventario I1 5 Gestión de proveedores 3 Inventario I2 4 Gestión de tipos de productos y productos Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de clientes. Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de proveedores. Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de tipos de producto y productos 4 Facturación F2 4 Generación de Se realiza el ingreso, búsqueda, modificación,

103 83 facturas. 5 Inventario I3 3 Gestión de facturas de los proveedores visualización y eliminación de facturas de los clientes Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de facturas de los proveedores. 6 Facturación F3 3 Cobros Se despliega los cobros realizados a los clientes, los mismos que se pueden modificar. 7 Inventario I4 3 Pagos Se despliega los pagos realizados a los proveedores, los mismos que se pueden modificar. 8 Reportes R1 2 Caja Diaria Se despliega información de las ventas realizadas en un período de tiempo determinado. 9 Reportes R2 2 Libro Diario Se despliega información de las compras y ventas en un período de tiempo determinado. 10 Respaldos RE1 1 Respaldo de Información 11 Publicidad P1 1 Creación de página web informativa Se ejecuta una copia de seguridad el momento que se requiera, para luego ser restaurada. Se realiza la construcción del sitio web de la Empresa con fines publicitarios. Tabla 3.6 Product Backlog de la versión 2.0 La reunión para la revisión del sprint anterior fue llevada a cabo de manera rápida y sin demoras, dando así la pauta para empezar la retrospectiva del sprint REUNIÓN DE RETROSPECTIVA DEL SPRINT Aclarado el concepto y motivo de esta reunión, se la dividió en tres puntos bien definidos y estructurados, que fueron los siguientes:

104 84 Exposición del resultado al implementar las historias de usuario: En este caso se completaron todas las historias, y se analizaron y corrigieron los errores. Análisis de las tareas en las historias de usuario: Aquí se determinó que el tiempo de ejecución superó al estimado, ya que se extendieron las tareas de Diseño de Base de Datos y Revisión del último requerimiento; estas demoras causaron que el sprint se extendiera un día más de lo planificado. Los problemas encontrados fueron: o La subestimación de tiempo al momento de planificar el diseño de la base de datos; en la realidad tomó más tiempo diseñar la Base del que se planificó. o Se detectaron varios retrasos al término de algunas tareas, ya que los desarrolladores dedicaron cuatro horas por día al proyecto y no las seis disponibles. Todos estos problemas se van a tomar en cuenta al momento de iniciar el nuevo sprint para que no sucedan de nuevo. En tercer lugar se realizó una valoración del Sprint: Aquí se destacaron los siguientes aspectos positivos: o o o o Se desarrollaron todas las historias de usuario planteadas en el sprint. Se corrigieron los errores detectados en los casos de prueba. Se llevaron a cabo todas las revisiones de los requerimientos. Se aprendieron nuevas técnicas de programación gracias a la investigación. También se encontraron puntos negativos: o No se pudieron llevar a cabo todas las reuniones del DailyScrum por motivos laborales de los desarrolladores, pero que fueron recompensados los fines de semana.

105 85 o Hubo algo de dificultad en las reuniones con el cliente ya que no contaba con el tiempo disponible necesario para que las mismas se lleven a cabo. Para mejorar el sprint se pueden corregir los aspectos negativos que afortunadamente no influyeron en el desarrollo del sprint PILA DE ENTREGA Y GRÁFICA DE TRABAJO RESTANTE Para elaborar la Pila de entrega que se muestra en la Tabla 3.7, se han tomado muy en cuenta las actualizaciones que se hicieron a la pila de producto, descritas en la revisión del sprint, agregándose las nuevas historias de usuario obtenidas. Item Prioridad Estimación del valor Estimación de esfuerzo inicial Estimación de Esfuerzo nueva Lo que queda de los Sprints 1 2 Gestión de Clientes Gestión de proveedores Gestión de tipos de productos y productos Generación de facturas. Gestión de facturas de los proveedores Cobros Pagos Caja Diaria Libro Diario Respaldo de Información Creación de página web informativa Total Tabla 3.7 Pila de Entrega

106 86 Además se incluye una gráfica del Trabajo Restante que se muestra en la Figura 3.1 en donde se expone el avance del proyecto y lo que falta por terminar. Es análoga a la gráfica del burn down chart pero a nivel más alto (requisitos) en vez de tareas específicas. Figura 3.1 Gráfica de Trabajo restante de la entrega Una vez establecidos esta pila de entrega y el gráfico de trabajo restante se puede proseguir con la planificación del siguiente sprint. 3.2 PLANIFICACIÓN DEL SEGUNDO SPRINT Para planificar el segundo sprint se llevó a cabo la reunión Sprint Planning Meeting descrita en la sección , donde se planificó un estimado de horas disponibles de trabajo propuesta por los integrantes del equipo, donde cada uno se comprometió a trabajar en ese tiempo. El resultado se puede ver detallado en la Tabla 3.8.

107 87 Longitud del Sprint 13 Días estimados Días laborables durante el Sprint De lunes a viernes y feriados Miembros del Equipo Días disponibles durante el sprint Horas disponibles al día Total horas disponibles Eleana Jerez Andrés Tello Raúl Córdova Tabla 3.8 Estimado Horas disponibles. Después de haber determinado el tiempo disponible, el grupo de desarrollo dividió las tareas que va a realizar cada miembro del equipo y el estimado inicial de horas de trabajo dedicadas a realizar cada tarea. Esta información se guarda en la Pila del Sprint, detallada en la Tabla 3.9. Tareas del Sprint Voluntario Esfuerzo estimado inicial (horas) Cobros Buscar movimientos Andrés 3 Ver cobros Andrés 2 Insertar cobro Andrés 4 Revisión Raúl 2 Pagos Buscar movimientos Andrés 3 Ver pagos Eleana 2 Insertar pago Eleana 4 Revisión Raúl 2 Caja Diaria Buscar detalles de cierre de caja Andrés 2 Imprimir detalles de cierra de caja Andrés 1

108 88 Revisión Raúl 2 Libro Diario Buscar movimientos Andrés 2 Imprimir movimientos Andrés 1 Revisión Raúl 2 Respaldo de Información Crear copia Andrés 2 Buscar copia Andrés 2 Restaurar copia Andrés 2 Eliminar copia Andrés 2 Revisión Raúl 2 Creación de página web informativa Instalación de joomla Eleana 1 Diseño del sitio web Eleana 15 Instalación de plantilla Eleana 1 Creación de contenidos Eleana 4 Creación de menús Eleana 2 Creación de módulos Eleana 6 Revisión Raúl 2 Tabla 3.9 Pila del sprint inicial Total AVANCE DIARIO DEL SPRINT Una vez empezado el Sprint, se llevaron a cabo reuniones diarias claves en Scrum, en la ejecución de las mismas no se presentaron mayores problemas y se llevaron a cabo con normalidad.

109 89 Para detallar la información del avance diario del desarrollo del sistema se especificó el objetivo del sprint que se visualiza en la Tabla 3.10 y el sprint backlog detallado en la Figura 3.2. SPRINT 2 OBJETIVO Desarrollar las gestiones de cobros, pagos, reportes y página web informativa. Tabla 3.10 Objetivo del sprint Después de esta actualización, se suman las horas restantes del equipo en total, y se calcula el gráfico del burn down chart. Esta gráfica muestra cada día una nueva estimación de cuanto trabajo queda (medido en personas-hora) para terminar las tareas del equipo, detallada en la Figura 3.3. Figura 3.3 Burn down chart

110 Figura 3.2 Sprint backlog completo 90

111 ELABORACIÓN DE LA VERSIÓN 2.0 DEL SISTEMA En este segundo sprint se concluirá con la elaboración del sistema, la construcción de sus interfaces se detallan a continuación, por motivos de diseño se ha definido las siguientes interfaces: Gestión de Cobros y Pagos. Reportes. Copias Seguridad. A continuación se exponen las interfaces más relevantes del sistema LendaSoft con sus respectivas opciones y operaciones GESTIÓN DE COBROS Y PAGOS La interface de Gestión de Cobros y Pagos se visualiza en la Figura 3.4 y está conformada por las opciones de Cobros y Pagos, las que permitirán conectarse al sistema a través de la capa de aplicación. En donde se realizarán las operaciones de: búsqueda y visualización de movimientos; también la agregación y modificación de los cobros y pagos en la capa de datos. Estas interfaces corresponden a las Historias de Usuario 7 y 8 expuestas en la sección en donde se realizó la revisión del sprint anterior. Figura 3.4 Selección del menú Gestión de Cobros y Pagos

112 Cobros En esta sección se detalla como se desarrolló la opción de Cobros en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Buscar Movimientos Para acceder a la interface de Buscar Movimientos que se presenta en la Figura 3.5, se procede a seleccionar el menú Gestión de Cobros y Pagos, el sub menú Cobros. Se puede buscar por: CI/RUC del cliente, nombre del cliente, estados de factura y período de fechas. Figura 3.5 Interface Buscar Movimientos Cobros El código que permite la búsqueda de los datos de los cobros en la base de datos se visualiza en la Figura 3.6.

113 93 Figura 3.6 Código Buscar Movimientos Cobros Ver cobros Para acceder a la interface de Ver Cobros que se presenta en la Figura 3.7, se procede a seleccionar el menú Gestión de Cobros y Pagos, la opción Cobros. Y en la lista que se presenta de Movimientos escoger el que se desea visualizar con clic en el botón Ver Cobros. Figura 3.7 Interface Ver Cobros

114 94 El código que permite extraer esta información desde la base de datos se muestra en la Figura 3.8. Figura 3.8 Código Ver Cobros Insertar Cobro En la interfaz de la sección anterior se inserta el nuevo cobro llenando primero los datos del formulario y clic en el botón Nuevo cobro como indica la Figura 3.9, luego se puede observar en la rejilla cobros que se agregó uno nuevo. Figura 3.9 Interface Insertar Cobro

115 95 El código que permite la inserción de los datos de los nuevos cobros en la base de datos se presenta en la Figura Figura 3.10 Código Insertar Cobro Pagos En esta sección se detalla como se desarrolló la opción de Pagos en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Buscar Movimientos Para acceder a la interface de Buscar Movimientos que se presenta en la Figura 3.11, se procede a seleccionar el menú Gestión de Cobros y Pagos, la opción Pagos. Se puede buscar por: CI/RUC del proveedor, nombre del proveedor, estados de factura y período de fechas. Figura 3.11 Interface Buscar Movimientos Pagos

116 96 El código que permite la búsqueda de la información de movimientos de los pagos en la base de datos se presenta en la Figura Figura 3.12 Código Buscar Movimientos Pagos Ver pagos Para acceder a la interface de Ver Pagos que se presenta en la Figura 3.13, se procede a seleccionar el menú Gestión de Cobros y Pagos, la opción Pagos. Y seleccionar el pago que se desea visualizar con clic en el botón Ver Pagos. Figura 3.13 Interface Ver Pagos

117 97 El código que permite extraer esta información desde la base de datos se muestra en la Figura Figura 3.14 Código Ver Pagos Insertar pago En la interfaz de la sección anterior se inserta el nuevo pago llenando primero los datos del formulario y clic en el botón Nuevo pago como indica la Figura 3.15, luego se puede observar en la rejilla pagos que se agregó uno nuevo. Figura 3.15 Interface Insertar Pago

118 98 El código que permite ingresar el nuevo pago a la base de datos se muestra en la Figura Figura 3.16 Código Insertar Pago REPORTES La interface de Reportes que se visualiza en la Figura 3.17 está conformada por las opciones Caja Diaria y Libro Diario, las que permitirán conectarse al sistema por medio de la capa de aplicación. En donde se puede realizar las operaciones de búsqueda de movimientos en la capa de datos, e impresiones de los reportes. Estas interfaces corresponden a la Historia de Usuario 9 y 10. Figura 3.17 Selección del menú Reportes Caja Diaria En esta sección se expone como se desarrolló la opción de Caja Diaria en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario 9.

119 Buscar Detalles de Cierre de Caja Para acceder a la interface Detalles Cierre Caja que se observa en la Figura 3.18, se procede a seleccionar el menú Reportes, la opción Caja Diaria, donde automáticamente se genera el cierre de caja de la fecha actual, pero se puede cambiar de fecha y buscar detalles del cierre de caja para esa fecha, haciendo clic en el botón buscar. Figura 3.18 Interface Detalles Cierre Caja El código que permite consultar la información del cierre de caja en la base de datos se muestra en la Figura Figura 3.19 Código Detalles Cierre Caja Imprimir Detalles de Cierre de Caja Para acceder a la interface para imprimir Detalles Cierre Caja que se observa en la Figura 3.20, se procede a seleccionar el menú Reportes, la opción Caja Diaria y clic en el botón Imprimir y luego en el botón Aceptar.

120 100 Figura 3.20 Interface Imprimir Detalles Cierre Caja El código que permite imprimir la información del cierre de caja se muestra en la Figura 3.21 Figura 3.21 Código Imprimir Detalles Cierre Caja Libro Diario En esta sección se expone como se desarrolló la opción de Libro Diario en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Buscar Movimientos Para acceder a la interface Buscar Movimientos que se observa en la Figura 3.22, se procede a seleccionar el menú Reportes, la opción Libro Diario donde se buscan los movimientos por periodo de fechas y clic en el botón Buscar.

121 101 Figura 3.22 Interface Buscar Movimientos Libro Diario El código que permite la búsqueda de datos del Libro Diario en la base de datos se muestra en la Figura Figura 3.23 Código Buscar Movimientos Libro Diario Imprimir Movimientos Para acceder a la interface para imprimir Movimientos de Libro Diario que se observa en la Figura 3.24, se procede a seleccionar el menú Reportes, la opción Caja Diaria y clic en el botón Imprimir que se encuentra al final del reporte de libro diario y luego en el botón Aceptar.

122 102 Figura 3.24 Interface Imprimir Movimientos Libro Diario El código que permite imprimir la información del Libro Diario se muestra en la Figura Figura 3.25 Código Imprimir Movimientos Libro Diario COPIAS SEGURIDAD La interface de Copias Seguridad que se visualiza en la Figura 3.26 está conformada por las opciones Hacer copia y Restaurar copia, las que permitirán conectarse al sistema por medio de la capa de aplicación. En donde se puede realizar las operaciones para crear, buscar, restaurar y eliminar copias de seguridad, en la capa de datos. Estas interfaces corresponden a la Historia de Usuario 11.

123 103 Figura 3.26 Selección del menú Copia Seguridad Hacer copia En esta sección se expone como se desarrolló la opción Hacer copia en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario Crear Copia de Seguridad Para acceder a la interface Crear Copia de Seguridad que se observa en la Figura 3.27, se procede a seleccionar el menú Copias Seguridad, la opción Hacer copia donde se llenan los datos del formulario y se hace clic en el botón Nueva copia de seguridad. Figura 3.27 Interface Crear Copia de Seguridad

124 104 Podemos observar que la copia de seguridad ha sido creada exitosamente como se visualiza en la Figura Figura 3.28 Interface Nueva Copia de Seguridad El código que permite la creación de la copia de seguridad se muestra en la Figura 3.29 Figura 3.29 Código Crear Copia de Seguridad Restaurar copia En esta sección se expone como se desarrolló la opción Restaurar copia en el sistema, mostrando primero la interface, después el fragmento de código que ejecuta las operaciones descritas en la Historia de Usuario 11.

125 Buscar Copias de Seguridad Para acceder a la interface Buscar Copias de Seguridad que se observa en la Figura 3.30, se procede a seleccionar el menú Copias Seguridad, la opción menú Restaurar copia donde se puede buscar las copias de seguridad por un periodo determinado de fechas o por el nombre de la copia de seguridad y se hace clic en el botón Buscar. Figura 3.30 Interface Buscar Copias de Seguridad El código que permite la búsqueda de la copia de seguridad en la base de datos se muestra en la Figura 3.31 Figura 3.31 Código Buscar Copias de Seguridad

126 Restaurar Copia de Seguridad En la misma interface anterior descrita en la sección , una vez encontrada la copia requerida, simplemente se hace clic en el botón Restaurar y se ejecuta la restauración como se observa en la Figura Figura 3.32 Interface Copia de Seguridad Restaurada El código que permite la restauración de la copia de seguridad se muestra en la Figura Figura 3.33 Código Restaurar Copia de Seguridad

127 Eliminar Copia de Seguridad En la misma interfaz descrita en la sección , una vez encontrada la copia requerida, simplemente se hace clic en el botón Eliminar y se ejecuta la eliminación de la copia de seguridad seleccionada como se observa en la Figura Figura 3.34 Interface Eliminar Copia de Seguridad El código que permite la eliminación de la copia de seguridad de la base de datos se muestra en la Figura Figura 3.35 Código Eliminar Copia de Seguridad

128 CREACIÓN DE PÁGINA WEB INFORMATIVA Para llevar a cabo la creación de la página web informativa para la Empresa, se realizaron las tareas que se exponen desde la sección hasta la sección Instalación de Joomla Se instaló Joomla 2.5.0; en la Figura 3.36 se expone la pantalla final que muestra una instalación exitosa del proceso que conlleva algunos pasos, el detalle completo de la instalación se encuentra en el Anexo 4. Figura 3.36 Instalación de Joomla Pantalla Final

129 Diseño del sitio web El sitio web se diseñó en base a los requerimientos proporcionados por la Empresa descritos en la sección en donde se realizó la justificación del CMS; para esto se procedió a seleccionar una plantilla que se acople a las necesidades de la Empresa, tomando en cuenta la distribución de la información y la presentación de imágenes, se escogió a la plantilla Karinpi, un ejemplo de la página de inicio de la plantilla se muestra en la Figura Figura 3.37 Plantilla Karinpi Ejemplo página de inicio

130 110 El personal de la empresa en conjunto con el equipo de desarrollo organizó la información que se debe presentar, para esto se utilizó las posiciones de la plantilla que se muestran en la Figura Figura 3.38 Plantilla Karinpi Posiciones

131 111 De acuerdo a las posiciones de la plantilla se definieron los siguientes módulos, en los cuales se distribuyó la información como se muestra en la Tabla Posición Tipo de Módulo Información Logo HTML personalizado Logo de la empresa. Search Buscar Buscador del sitio web. Mainmenu Menú Inicio, Quiénes somos, Tipos de producto, Rastreo Satelital y Contacto. Slide Show Slide Show Visor de imágenes de tipos de producto, servicios y promociones que ofrece la empresa. Right HTML personalizado Imagen de rastreo satelital. Right Showplus Catálogo de productos. Login Datos de acceso Inicio de sesión al sitio web. Login Vinaora Visitors Counter Contador de visitas. Left HTML personalizado Imagen de cajas acústicas. News HTML personalizado Imagen de alarma inteligente. User 4 HTML personalizado Información e imagen de audio y video. User 5 HTML personalizado Información e imagen de iluminación. User 6 HTML personalizado Información e imagen de autolujos. User 7 HTML personalizado Información e imagen de seguridad. User 8 HTML personalizado Información e imagen de servicio técnico. Copyright HTML personalizado Información de Copyright. Tabla 3.12 Posiciones y distribución de información en la plantilla

132 Instalación de plantilla Se procedió a instalar la plantilla y se obtuvo un mensaje de instalación exitosa que se presenta en la Figura El proceso completo se muestra en el Anexo 4. Figura 3.39 Instalación de la plantilla Karinpi Pantalla Final Creación de contenidos Los contenidos del sitio web se elaboraron en base a la información proporcionada por el personal de la empresa, en la Tabla 3.13 se muestran los contenidos creados. En el Anexo 4 se encuentra el proceso completo de creación de contenidos.

133 113 Categoría Artículos Quiénes somos Historia, Misión, Objetivos, Plan estratégico, Quiénes somos y Visión Inicio Inicio Tipos de Producto Audio y Video, Autolujos, Iluminación, Seguridad y Servicio Técnico. Estructura Organizacional Estructura Organizacional Catálogo de productos Audio y Video logos, Boss, Bunker, Catálogo de productos, Genius, Iluminación, JVC, Kenwood, Nemesis, Pioner y Seguridad logos. Rastreo Satelital Rastreo Satelital, Software de escritorio, Página web y Web celular. Tabla 3.13 Categorías y Artículos del sitio web Creación de menús En la Tabla 3.14 se muestra los menús con sus niveles, creados en el sitio web y su respectivo tipo de elemento de menú. En el Anexo 4 se expone el proceso completo de la creación de menús.

134 Tabla 3.14 Menús del sitio web 114