MERKONSOLA: TIENDA VIRTUAL PARA LA SOLICITUD DE PEDIDOS ON-LINE CON PAGO ANTICIPADO LUCY PAOLA MARTÍNEZ PÉREZ EIBIN FABÍAN ACOSTA AGUDELO

Transcripción

1 MERKONSOLA: TIENDA VIRTUAL PARA LA SOLICITUD DE PEDIDOS ON-LINE CON PAGO ANTICIPADO LUCY PAOLA MARTÍNEZ PÉREZ EIBIN FABÍAN ACOSTA AGUDELO UNIVERSIDAD LIBRE FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C

2 MERKONSOLA: TIENDA VIRTUAL PARA LA SOLICITUD DE PEDIDOS ON-LINE CON PAGO ANTICIPADO LUCY PAOLA MARTÍNEZ PÉREZ EIBIN FABÍAN ACOSTA AGUDELO Trabajo de grado para optar al título de Ingeniero de Sistemas DIRECTOR FABIAN BLANCO GARRIDO INGENIERO DE SISTEMAS UNIVERSIDAD LIBRE FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS BOGOTÁ D.C

3 Nota de aceptación Firma del presidente del jurado Firma del jurado Firma del jurado Bogotá D.C., Agosto de

4 Dedicatoria Mi tesis la dedico con todo cariño a ti Dios que me diste la oportunidad de vivir y regalarme una familia tan maravillosa. Con mucho aprecio en especial a mis padres Alexander Martínez y Nancy Pérez que me dieron la vida y han estado conmigo en todo momento ofreciendo su apoyo incondicional, por ofrecer la oportunidad de estudiar una carrera para mi futuro y por creer en mí y no dejarme desfallecer en este largo camino. A mi hermana Camila que me apoyo en cada momento y nunca dejo que me diera por vencida en el objetivo de terminar mis estudios. Y a todas las personas que estuvieron apoyándome en todo momento y circunstancias de la realización de la investigación y culminación del trabajo de grado, a todos ellos gracias que sin ustedes a mi lado no lo hubiera conseguido. Lucy Paola Martínez Pérez El fruto del esfuerzo de este trabajo está dedicado en primera instancia a Dios, a la virgen María, a mis queridos padres Héctor Francisco y Blanca Nelly, por su incondicional apoyo y compañía en todos los momentos de mi vida; así como a todas aquellas personas que de alguna u otra forma contribuyeron a que este anhelado objetivo se hiciera realidad. Eibin Fabián Acosta Agudelo 4

5 Agradecimiento Mis agradecimientos están dirigidos a todas las personas que hicieron posible la realización exitosa de esta investigación, principalmente a gradezco a mis padres, a mi hermana por el apoyo incondicional. También doy gracias a mi compañero de proyecto por su paciencia y constancia a la hora de llevar a la realidad nuestra idea. Igualmente a todos nuestros docentes de la Universidad Libre por los conocimientos compartidos y enseñados para mi desarrollo personal y profesional, en especial al Ingeniero Álvaro Rojas director del programa de ingeniería de sistemas por toda su paciencia y comprensión durante mi proceso en la universidad; Igual a la Ingeniera Aura Beatriz Alvarado por su comprensión, paciencia y guía en el trascurso del desarrollo del proyecto Muchas gracias. Lucy Paola Martínez Pérez Mis más sinceros agradecimientos para con Dios, la virgen María, mis padres, mi inmejorable grupo de trabajo, nuestro director del proyecto y al programa de Ingeniería de sistemas de la Universidad Libre, por todos sus invaluables aportes y conocimientos para hacer de mi un mejor hombre y profesional útil para mi familia y la sociedad. Eibin Fabián Acosta Agudelo 5

6 CONTENIDO Pág. INTRODUCCIÓN ASPECTOS PRELIMINARES PLANTEAMIENTO DEL PROBLEMA FORMULACIÓN DEL PROBLEMA JUSTIFICACIÓN OBJETIVOS General Específicos ALCANCE MARCO REFERENCIAL Marco Histórico Marco Teórico Marco Conceptual Marco Tecnológico Marco Legal DISEÑO METODOLÓGICO Método de investigación Universo Instrumentos y análisis Hipótesis 45 6

7 Tipo de investigación Actividades ESTRUCTURA TEMÁTICA GESTIÓN DEL PROYECTO Inicio del Proyecto Organización y Preparación Ejecución del trabajo Cierre del Proyecto MODELO Y ARQUITECTURA DE SOFTWARE Modelo de negocio Arquitectura del Sistema Capa de Presentación Capa lógica de negocio Capa de Datos Módulos del sistema IMPLEMENTACIÓN DE LA METODOLOGÍA SCRUM PRUEBAS DE SOFTWARE PROCESO DE IMPLEMENTACIÓN DEL SOFTWARE DESCRIPCIÓN DEL PRODUCTO DE SOFTWARE 75 CONCLUSIONES 77 RECOMENDACIONES 81 BIBLIOGRAFÍA 82 7

8 INFOGRAFÍA 84 ANEXOS 86 8

9 LISTA DE ANEXOS Pág. ANEXO 1. DISEÑO METODOLOGICO 87 ANEXO 2. ACTA DE COSTITUCIÓN DEL PROYECTO 98 ANEXO 3. WORK BREAKDOWN STRUCTURE (WBS) 112 ANEXO 4. INTEGRACIÓN DE LAS METODOLOGÍAS 122 ANEXO 5. PLAN DE GESTIÓN DE HORARIOS 123 ANEXO 6. PLAN DE GESTIÓN DE RIESGOS 134 ANEXO 7. PLAN DE GESTIÓN DE ADQUISICIONES 141 ANEXO 8. PLAN DE GESTIÓN DE COMUNICACIONES 146 ANEXO 9. SCRUM 154 ANEXO 10. JAVA 2 ENTERPRISE EDITION (J2EE) 160 ANEXO 11. DOCUMENTO ESPECIFICACIÓN REQUISITOS (IEEE830) 166 ANEXO 12. DICCIONARIO DE DATOS 188 ANEXO 13. MÓDULOS DEL SISTEMA 196 ANEXO 14. ACTIVIDADES DEL DESARROLLO DE LOS MÓDULOS 200 ANEXO 15. REVISIÓN DEL PRODUCT BACKLOG 203 ANEXO 16. PRUEBAS DE SOFTWARE 205 ANEXO 17. MANUAL DE USUARIO MERKONSOLA 227 ANEXO 18. MANUAL TÉCNICO Y DE INSTALACIÓN MERKONSOLA 238 ANEXO 19. DIAGRAMACIÓN UML 250 9

10 GLOSARIO Aplicación web. Es un sistema informático que los usuarios utilizan accediendo a un servidor Web a través de internet o de una intranet. Las aplicaciones Web son populares debido a la practicidad del navegador web como cliente ligero. 1 Arquitectura de software Una vista del sistema que incluye los componentes principales del mismo, la conducta de esos componentes según se la percibe desde el resto del sistema y las formas en que los componentes interactúan y se coordinan para alcanzar la misión del sistema. La vista arquitectónica es una vista abstracta, aportando el más alto nivel de comprensión y la supresión o diferimiento del detalle inherente a la mayor parte de las abstracciones. 2 B2C. Es la abreviatura de Business to Consumer, un término que, en comercio electrónico, se emplea para referirse a las transacciones comerciales realizadas a través de Internet, entre las empresas y los consumidores finales. En este tipo de comercio, el consumidor adquiere un bien o servicio a través de Internet, pudiendo realizarse el pago y la entrega del producto o servicio on line u off line. 3 1 Molina Caballero, Joaquín. Implantación de aplicaciones informáticas de gestión. Madrid: Vision Net, s.f. 2 Tomado de: 3 Seoane Balado, Eloy. La nueva era del comercio:comercio electrónico. Ideaspropias, Pagina

11 Comercio electrónico El comercio electrónico consiste en realizar electrónicamente transacciones comerciales; es cualquier actividad en las que las empresas y consumidores interactúan, y realizan negocios entre sí o con las administraciones por medio electrónico. 4 Factura electrónica. Es el documento que soporta transacciones de venta de bienes y/o servicios, que para efectos fiscales debe ser expedida, entregada, aceptada y conservada por y en medios y formatos electrónicos, a través de un proceso de facturación que utilice procedimientos y tecnología de información, en forma directa o a través de terceros, que garantice su autenticidad e integridad desde su expedición y durante todo el tiempo de su conservación, de conformidad con lo establecido en este decreto, incluidos los documentos que la afectan como son las notas crédito. 5 IEEE830. Especificaciones de los requisitos de software. Una especificación de requisitos del software es una descripción completa del comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que describen todas las interacciones que se prevén que los usuarios tendrán con el software. También contiene requisitos no funcionales (o suplementarios). Los requisitos no funcionales son los requisitos que imponen restricciones al diseño o funcionamiento del sistema (tal como requisitos de funcionamiento, estándares de calidad, o requisitos del diseño). 6 4 Tomado de: 5 Tomado de: 6 Tomado de: 11

12 Ingeniería Web. Es la aplicación de metodologías sistemáticas, disciplinadas y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad en la World Wide Web. 7 JSP. Java Server Page Página de Servidor Java. Se refiere a un tipo especial de páginas HTML, en las cuales se insertan pequeños programas que corren sobre Internet (comúnmente denominados scripts), se procesan en línea para finalmente desplegar un resultado final al usuario en forma de HTML. Por lo general dichos programas hacen consultas a bases de datos y dependiendo del resultado que se despliegue será la información que se muestre a cada usuario de manera individual. Los archivos de este tipo llevan la extensión.jsp. 8 Modelo de negocio. Un modelo de negocio explicita el contenido, la estructura y el gobierno de las transacciones designadas para crear valor al explotar oportunidades de negocio. 9 Modelo Vista Controlador. MVC es un patrón de desarrollo que separa la parte lógica de una aplicación de su presentación. Sirve para separar el lenguaje de programación HTML para poder reutilizar componentes fácilmente. El modelo representa las estructuras de datos, típicamente el modelo de clases contendrá funciones para consultar, insertar y actualizar información de la base de 7 Tomado de: 8 Tomado de: 9 Tomado de: 12

13 datos. La vista de información presentada al usuario, una vista puede ser una página web. 10 Pago anticipado. Es aquella forma de pago basada en la adquisición de un ticket con un determinado monto de dinero, cuyo valor adquirido permite ser canjeado por productos en la tienda virtual. Pago contra entrega. Forma de pago que consiste en pagar en efectivo el pedido solicitado en la tienda virtual, una vez que este llega a su destino. Pedido. Petición de compra que un cliente hace a un proveedor para que éste le suministre los bienes o servicios solicitados. Scrum. Scrum es un framework de desarrollo ágil de software. El trabajo es estructurado en ciclos de trabajo llamados sprints, iteraciones de trabajo con una duración típica de dos a cuatro semanas. Durante cada sprint, los equipos eligen de una lista de requerimientos de cliente priorizados, llamados historias de usuarios, para que las características que sean desarrolladas primero sean las de mayor valor para el cliente. Al final de cada sprint, se entrega un producto potencialmente lanzable / distribuible / comerciable. 11 Software libre. El software libre es una cuestión de la libertad de los usuarios de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. 10 Tomado de: 11 Tomado de: 13

14 Más precisamente, significa que los usuarios de programas tienen las cuatro libertades esenciales. 12 Ticket Pago Anticipado. Es un comprobante de pago, que representa un monto de dinero, el cual se puede hacer efectivo o canjeable por productos en la tienda virtual. Tienda virtual. Representa el intento de trasladar la "operativa" comercial habitual de un comercio tradicional a Internet. UML. Unified Modeling Language. Es una de las mejores herramientas para analizar y diseñar sistemas de software que ofrece un lenguaje común. 13 Work Breakdown Structure.(WBS) Desglose jerárquico de tareas - es una descripción del modelo del trabajo a realizar en un proyecto. 12 Tomado de: 13 Tomado de: 14

15 RESUMEN El presente documento pretende dar a conocer el proceso de desarrollo de una aplicación web para el Minimercado Andalucía 14. Dicha aplicación se proyecta como una alternativa de solución viable a la falta de control, inventario y administración de los pedidos realizados a domicilio, con el ánimo de efectuar dicha actividad de forma sistematizada, segura y controlada. En lo referente al diseño metodológico, se utilizó una investigación cuantitativa, debido a que es necesario identificar y definir claramente la problemática en cuestión, así como se establecen objetivos claros; a fin de que puedan ser respaldados por la elaboración e implementación de instrumentos para recolección de información y medición de las variables a través de los resultados obtenidos. En el aspecto propio de la gestión del proyecto (que hace parte del cuerpo del presente documento), se hace uso del ciclo de vida de proyectos propuesto por PMI 15 en su PMBOK 16 como metodología para el desarrollo del proyecto, el cual se complementa de manera conjunta con la metodología de desarrollo Scrum para el producto de software. De esta forma se da consistencia al proyecto, cuyo resultado fue el cumplimiento satisfactorio de los objetivos planteados. Palabras Clave: Pedido, PMI, PMBOK, Software, Metodología. 14 El Minimercado Andalucía se encuentra ubicado en el barrio Andalucía, perteneciente a la localidad Octava de Kennedy de la ciudad de Bogotá D.C. 15 PMI (Project Management Institute): Es el líder mundial sin fines de lucro de miembros de la profesión de gestión de proyectos, con más de medio millón de miembros y personas certificadas en más de 185 países. Tomado de: Us.aspx 16 PMBOK (Project Management Body of Knowledge): Guía de los fundamentos para la dirección de proyectos escrita por el PMI, la cual congrega las buenas prácticas que pueden ser implementadas en el desarrollo de cualquier proyecto en general. 15

16 ABSTRACT This document pretends to show the process of developing a web application for the supermarket Andalucía. This application is projected as a viable alternative solution to the missing of control, inventory management and orders made at home, with the aim of carrying out such activity in a systematic, safe and controlled form. According to methodological design, it was used a quantitative research, because it is necessary to identify and clearly define the issue in question and set clear objectives so that they can be supported by the development and implementation of tools for collecting information and measurement of variables through the results. On the project management (which is part of the body of this document), it is used the life cycle of projects proposed by PMI in PMBOK (Project Management Body of Knowledge), as a methodology for the project, which is complemented with the Scrum development methodology for the software product. This gives consistency to the project, which resulted in the successful fulfillment of the objectives. Keywords: Order, PMI, PMBOK, Software, Methodology 16

17 INTRODUCCIÓN La masificación de Internet sin duda alguna, ha contribuido a que todos los sectores de la industria, comercio y la misma sociedad, tengan un sin número de posibilidades tanto para el desarrollo creciente de negocios como para la diversión, acceso a la información, comunicación y entretenimiento a través de este medio. Uno de los actores mencionados: El comercio, no ha sido ajeno a este salto tecnológico, puesto que esta red mundial de información le ha permitido eliminar las barreras geográficas, ofrecer productos y servicios a una mayor cantidad de clientes potenciales alrededor del globo e incluso la facilidad de buscar y comprar en el momento deseado. Muestra clara de ello son las tiendas virtuales (asociadas al enfoque B2C), cuyo surgimiento se ha difundido de forma exponencial en Internet gracias a las características anteriormente mencionadas. En el contexto especifico con el que se enfrenta este proyecto, se hace mención que la venta de pedidos a domicilio vía telefónica en el Minimercado Andalucía, es una alternativa que le permitió inicialmente expandir su campo de acción y prestar sus servicios a un número mayor de clientes permisibles, favoreciendo el incremento en sus ingresos económicos. A pesar de esta situación, dicho servicio presentaba algunos inconvenientes, que comprometían seriamente la prestación y continuidad del mismo. Esta situación se ha reflejaba en la paulatina pérdida de clientes, y por ende en la disminución de ingresos a causa de algunas deficiencias que afectan la calidad en la prestación del servicio, las cuales causaron continuas molestias a sus clientes. En aras de mejorar las falencias detectadas en la prestación de dicho servicio, se pretende mediante el desarrollo del presente proyecto de grado brindar una 17

18 alternativa viable que contribuya a mejorar dichas deficiencias identificadas en aquel servicio ofertado en esta tienda de barrio. Por ello teniendo en cuenta la gran versatilidad y características favorables que una tienda virtual provee a muchos negocios a nivel mundial, se opta por desarrollar la presente aplicación web con herramientas de software libre y metodologías reconocidas, en aras de aplicar el conocimiento ingenieril a la problemática hallada en dicho contexto, teniendo en cuenta el carácter comunitario para dicho sector de la población, los beneficios propios para el Minimercado e incluso un bajo costo de implementación que facilite su puesta en marcha y funcionamiento continuo. 18

19 1. ASPECTOS PRELIMINARES 1.1. PLANTEAMIENTO DEL PROBLEMA Actualmente los Minimercados de Bogotá, por lo general realizan el registro y facturación de pedidos a domicilio a lápiz y papel. Situación que acarrea consigo inconvenientes, debido a que la manera cómo funciona hasta el día de hoy, no es factible llevar un control, inventario y administración de los pedidos realizados, el cual permita a los Minimercados efectuar dicha actividad de forma organizada, segura y controlada. Otro inconveniente que presenta este servicio vía telefónica, se evidencia en repetidas ocasiones en el registro erróneo del pedido por parte de los empleados encargados de esta actividad, generando de esta manera la insatisfacción y molestia en el cliente cuando recibe su pedido con productos no solicitados por él. Además, se presenta la larga espera en la línea telefónica cuando se hace uso del servicio debido a la gran concurrencia de llamadas en el teléfono del Minimercado. Sumado a las molestias anteriores por los inconvenientes en lo respectivo a los domicilios, se presenta de igual manera otra dificultad asistiendo personalmente a los Minimercados. Esta consiste en que hay ocasiones en las que se generan incomodidades en los clientes, debido a la larga espera para efectuar el pago del correspondiente mercado a causa de la alta concurrencia de usuarios, situación que afecta de gran manera a población de la tercera edad, amas de casa y clientes con apretadas agendas y gran cantidad de compromisos laborales que cuentan con un tiempo limitado para mercar. Siendo aún más critica la realización de tal actividad, en épocas especiales como las de fin de año. Finalmente, esta serie de problemáticas causan pérdidas económicas al Minimercado, puesto que la clientela del establecimiento disminuye gradualmente 19

20 junto con la cantidad de pedidos a domicilio que se realizaban anteriormente, lo cual se espera afecte la estabilidad y funcionamiento del Minimercado en el futuro de seguirse presentado estas situaciones FORMULACIÓN DEL PROBLEMA De qué manera contribuirá una tienda virtual, al mejoramiento de la calidad de vida de los clientes y a la solicitud, registro, facturación de los pedidos a domicilio de víveres y abarrotes del Minimercado Andalucía? 1.3. JUSTIFICACIÓN Desde el punto de vista social, la tienda virtual proporcionara un servicio a la comunidad en general que le ayude en sus necesidades mercantiles, brindando una solución viable frente a las deficiencias e inconvenientes que presenta el servicio actualmente. En lo respectivo a los beneficios que esta alternativa de solución planteada traería para el Minimercado se encuentran: Un mejoramiento en sus procesos de facturación y registro de pedidos a domicilio, ya que la Aplicación contribuirá a transformar la antigua forma de realizar estas actividades de manera manual (Lápiz y papel), desorganizada e ineficiente; por una manera sistematizada, organizada y segura, que servirá de apoyo al Administrador del Minimercado para que pueda tomar decisiones acertadas que le permitan ofrecer un mejor servicio a sus clientes y obtener un mejor provecho y rentabilidad del negocio. Otra ventaja sustancial, radica en que la Aplicación permitirá al Minimercado incrementar su campo de acción, oportunidades de negocio, ventas, promociones 20

21 y ofertas a sus clientes, gracias a las múltiples ventajas que brinda una tecnología de la información como lo es internet. El cliente de igual manera es ampliamente beneficiado, gracias a que: La Aplicación será un medio que contribuya a mejorar las incomodidades en lo referente al registro erróneo del pedido telefónicamente, dado que al realizar dicha acción ya no se necesitara de un intermediario (empleado) que pueda equivocarse en esta actividad, por el contrario la Aplicación es la única que interactúa con el cliente disminuyendo el riesgo de errar cuando se haga el pedido. Vale la pena resaltar que el Aplicativo igualmente permitirá que se subsanen las molestias presentadas cuando se llama al teléfono de Minimercado y este se encuentra ocupado debido a la alta concurrencia de llamadas. Es de vital importancia resaltar el hecho de que Aplicativos de Software orientados a la Web como: Merkonsola, beneficien al cliente puesto el no necesita desplazarse al Minimercado, por el contrario es este último quien se dirige y le brinda sus servicios a través de la Web. Cooperando de esta manera a facilitar la compra del mercado para los usuarios con un tiempo limitado a la hora de realizar esta labor, como para aquellos que buscan desde su ubicación una nueva opción para evadir la larga y demorada espera en la caja, la congestión y la misma inseguridad que genera el desplazarse a la hora de comprar (robo). Las Madres cabeza de Familia son igualmente beneficiadas, puesto que gracias a Merkonsola pueden invertir el tiempo dedicado al mercar, en otros labores ya sean domesticas (aseo del hogar) o labores propias de su condición de madres como por ejemplo el cuidado de los hijos. 21

22 Por último, hay otros factores que avalan, apoyan y sirven de punto de referencia para la evocación y justificación de esta alternativa de solución. En efecto se pueden mencionar: un mejor control de gastos para el cliente, el no desplazamiento físico al Minimercado, e incluso no cargar el mercado. En donde estos dos últimos juegan un papel crucial en personas de la tercera edad y mujeres embarazadas OBJETIVOS General. Implementar una tienda virtual para la solicitud, registro y facturación de pedidos on-line con pago anticipado, empleando software libre en el Minimercado Andalucía Específicos. Identificar las necesidades e intereses de los clientes y del Minimercado. Diseñar la arquitectura del sistema acorde a la interacción de los módulos del proyecto y con base en las necesidades e intereses identificados. Aplicar pruebas de rendimiento de Software para determinar el funcionamiento y calidad del servicio ALCANCE A raíz de la problemática expuesta en la descripción del problema, se plantea la implementación de una tienda virtual, que contribuya a mejorar la solicitud, registro y facturación de los pedidos de víveres y abarrotes en el Minimercado Andalucía. Dicha Aplicación Web, permitirá llevar un control, inventario y 22

23 administración de los pedidos realizados por los usuarios, para ejercer dicha actividad de una manera organizada, segura y controlada para el administrador. En lo referente a gestión de productos, el software facilitara la adición, modificación o supresión de productos, promociones y ofertas presentes en el catálogo de compra. Desde la perspectiva del usuario, se exige que en primera instancia se registre en el sistema, para posteriormente efectuar la selección y solicitud del pedido en línea, con la opción de efectuar el pago con dos alternativas: Pago contra-entrega o Pago Anticipado. Para este último, el aplicativo facilitara al administrador la impresión de tickets de pago anticipado, con la suma de dinero efectuada por el usuario. Es de resaltar que, Merkonsola es una alternativa que busca contribuir al mejoramiento de aquellas situaciones claramente expuestas en la problemática del presente documento ofreciendo sus servicios a la comunidad en general, pero es preciso hacer mención, que esta Aplicación no brinda herramientas o ayudas concretas para que aquellos usuarios con algún tipo de discapacidad especifica de orden motriz, visual, manual u otro, puedan hacer uso del sistema con total comodidad y eficacia. Para concluir, se destaca que el aplicativo web únicamente centra su funcionalidad y servicio en aquellos aspectos que involucran los pedidos a domicilio: Solicitud, registro y facturación de los pedidos de víveres y abarrotes. Adición, modificación o supresión de productos, promociones y ofertas presentes en el catálogo de compra. 23

24 La impresión de tickets de pago anticipado, con la suma de dinero efectuada por el usuario. Entre otros. Más no está relacionado con algún tipo de actividad propia de la gestión del Minimercado como lo son: Facturación de compras presenciales. Contabilidad del Minimercado MARCO REFERENCIAL Marco Histórico. La invención y evolución de las Tiendas Virtuales van de la mano estrechamente del comercio electrónico y su implementación en la Internet. A principio de los años 70 s, aparecieron las primeras relaciones comerciales que utilizaban un ordenador para transmitir datos. Este tipo de intercambio de información, sin ningún tipo de estándar, trajo consigo mejoras de los procesos de fabricación en el ámbito privado, entre empresas de un mismo sector. A medida que la Internet fue ganando usuarios se comenzó a visualizar el gran futuro del sector comercial y su potencial para los negocios en el medio. Dándose inicio así a mediados de 80 s, a la era del folleto electrónico (catalogo), Que apoyado con la ayuda de la televisión, origino una nueva forma de venta, llamada venta directa: consiste en realizar la venta por medio de los pagos de tarjetas de crédito. De esta 24

25 manera, los productos son mostrados con mayor realismo, y con la dinámica de que pueden ser exhibidos resaltando sus características. 17 Esta nueva era del folleto electrónico tenía como fin difundir la imagen, productos (en folletos) y los servicios proporcionados por dicha empresa a los usuarios de la web. De esta forma se concibió la necesidad de la creación de un sitio Web como solución a esta nueva visión de Comerció. De esto, surgió la idea de la Tienda en línea o Tienda Virtual. Las empresas comenzaron a darse cuenta que mientras más información en línea se encontraba sobre sus productos, mayor era el interés de los usuarios por comprarlos. El siguiente paso fue tratar de vender por Internet. 18 Un gran aliciente y empuje que a este evento fueron las condiciones tecnológicas que ayudaron a llegar a esta etapa. En un inicio, las aplicaciones a través de web se limitaban a libros de visitas, búsquedas, llenado de formas y envió de mails, entre otras, pero poco a poco fueron surgiendo nuevas herramientas que permitían mayor interacción con sistemas existentes, como bases de datos y sistemas de cobro por tarjeta. Dadas estas condiciones actualmente se propende en este tipo de aplicaciones (Tiendas Virtuales) aplicar la estrategia comercial B2C (Business to Consumer) Marco Teórico: Comercio Electrónico (E-commerce). El e-commerce ha tomado una gran ventaja a través del tiempo y gran importancia y en el proyecto, pero como 17 Rayport, J. F., Jaworski, B. J. E-commerce. Páginas 20 y Karen, D. C., & Lares, E. A. Sistemas de informacion para los negocios. 25

26 definimos el comercio electrónico ya que ha venido evolucionando y en nuestro país ha tenido una gran acogida ya que existen más de 430 tiendas virtuales en Colombia. Según Jeffrey Rayport el comercio electrónico se puede definir como intercambios mediados por la tecnología entre diversas partes (individuos, organizaciones, o ambos), así como las actividades electrónicas dentro y entre organizaciones que facilitan esos intercambios. 19 Figura: 01 Modelo típico de comercio Electrónico El comercio electrónico tiene algunas características como: o Hay un intercambio de información digitalizada entre las dos partes. o La tecnología tiene la función de mediar entre los entes que intervienen en el comercio electrónico. 19 Rayport, J. F., Jaworski, B. J. E-commerce. 26

27 o El comercio electrónico es un subconjunto del e-bussiness. o Es el uso de tecnologías de información para llevar productos o servicios de una empresa al consumidor final. El comercio electrónico tiene una clasificación de los diferentes enfoques que puede tomar. o Negocio a Negocio (B2B): Son las relaciones comerciales entre organizaciones. o Negocio a Consumidor (B2C): Son los intercambios entre empresas y consumidores finales. Es el comercio tradicional dirigido al consumidor final a través de la web. o Consumidor a Negocio (C2B): En este caso los consumidores son los que definen las condiciones de las transacciones. o Consumidor a Consumidor (C2C): Son las transacciones entre consumidores y en ocasiones intervienen terceros. Qué ventajas tiene el comercio electrónico para el consumidor: o La facilidad de buscar y comprar en el momento. o Mejores precios al eliminar intermediarios. o Poder acceder prácticamente a cualquier producto o servicio desde el hogar. 27

28 o Capacidad de comprar productos desde un mismo lugar. o Establecer una relación con el proveedor. o Bases de datos que permiten hacer comparaciones de lo que otros compran. o Ingeniería de Software. Encontrar técnicas que ayuden al mejoramiento de la calidad y que permiten reducir costos en las soluciones de desarrollo. A través del tiempo la creación de un producto de software era una tarea complicada, y se dio la necesidad de introducir una serie de herramientas y procedimientos que faciliten la creación de un nuevo software. La definición que propuso Fritz Bauer: La ingeniería de software es el establecimiento y uso de principios sólidos de la ingeniería para obtener económicamente un software confiable y que funcione de modo eficiente en máquinas reales. 20 Tabla: 01 Actividades del desarrollo de software Actividad Requisitos Análisis Descripción Se especifican las necesidades del sistema a desarrollar. La especificación de requisitos sirve como base para la negociación entre los desarrolladores y clientes del sistema, y también para planear y controlar el proceso de desarrollo. Se busca comprender los requisitos del sistema con el propósito de estructurar la arquitectura del sistema. 20 Pressman, Roger. Ingeniería del software un enfoque práctico. 28

29 Se transforma la arquitectura obtenida durante el análisis Diseño en una arquitectura especializada, donde se considera el ambiente de implantación particular del sistema. Implementación Se expresa la arquitectura del sistema en una forma aceptable el código. Integración Se combinan los componentes creados de manera independiente para formar el sistema completo. Se verifica y valida el sistema a nivel de componentes Pruebas individuales y de integración. Se busca descubrir cualquier defecto en los requisitos, análisis, diseño, implementación e integración. Las pruebas se hacen a varios niveles, desde funciones sencillas hasta el sistema completo. Se describen los aspectos sobresalientes de los requisitos, Documentación análisis, diseño, implementación, integración y pruebas. Esto servirá para usuarios externos e internos, aquellos encargados de mantener el sistema y extenderlo. Se corrigen errores no encontrados durante el desarrollo y Mantenimiento las pruebas originales del sistema. Se extiende el sistema si surgen nuevas necesidades. Fuente: Weitzenfeld, A. Ingenieria De Software o Ingeniería Web. Uno de los aspecto más tenidos en cuenta, en el desarrollo de sitios web es sin duda alguna el diseño gráfico y la organización estructural del contenido. En la actualidad la web está sufriendo grandes cambios, que han obligado a expertos en el tema a utilizar herramientas y técnicas basadas en la ingeniería del 29

30 software, para poder garantizar el buen funcionamiento y administración de los sitios web. Ahora para garantizar el buen funcionamiento y mantenimiento de los sitios web, este debe contar con ciertos atributos y características que en conjunto forman un concepto muy importante, para alcanzar el éxito en cualquier organización, herramienta, y todo aquello que se pueda considerar como servicio. La ingeniería Web Es el proceso utilizado para crear implantar, y mantener aplicaciones y sistemas Web de alta calidad. El proceso de la ingeniería Web se caracteriza por la inmediatez, evolución y crecimiento continuos, nos lleva a un proceso incremental y evolutivo, que permite que el usuario se involucre activamente, facilitando el desarrollo de productos que se ajustan mucho a lo que se esté buscando y se necesite. o Modelo De Datos Relacional. Es una base de datos que cumple con el modelo relacional, el cual es el modelo más utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten establecer relaciones entre los datos (que están guardados en tablas). Características de una base de datos relacional. o o o o Una base de datos relacional se compone de varias tablas o relaciones. No pueden existir dos tablas con el mismo nombre. Cada tabla es a su vez un conjunto de registros (filas y columnas). La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o foráneas). 30

31 o Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben cumplir con la integridad de datos. Las bases de datos forman hoy en día una parte integrante de nuestra vida cotidiana, hasta tal punto que muchas veces no somos conscientes de estar usando una base datos. Para comenzar nuestras explicaciones sobre las bases de datos, vamos a argumentar algunas explicaciones de este tipo de sistemas. En lo que respecta a las explicaciones siguientes, consideremos que una base de datos es una colección de datos relacionados y que el Sistema de Gestión de Bases de Datos (SGBD) es el software que gestiona y controla el acceso a la base de datos. Una aplicación de bases de datos es simplemente un programa que interactúa con la base de datos para referirnos a una colección de programas de aplicación que interactúan con la base de datos, junto con el SQL y la propia base datos. Para el desarrolla del proyecto se escogió un modelo relacional dada las ventajas que nos provee el modelo relacional dado el tipo de proyecto que se va a desarrollar. Entre estas ventajas se podemos mencionar: o Con este modelo se puede evitar en 100% de la duplicidad de datos. o La normalización que se permite aplicar en estos modelos permite hacer un modelo de bases de datos más compresible y fácil de entender lo cual facilita en un futuro el correcto mantenimiento de la misma. o A pesar de que para aplicar esta modelo se hace necesario tener una herramienta dedicada para administrar la base de datos, en el mercado actual hay múltiples herramientas gratuitas, que me permiten realizar estas tareas sin afectar el rendimiento de la aplicación. 31

32 o Otra gran ventaja que tiene este modelo es la que garantiza la integridad referencial en toda la base de datos, permitiéndonos así eliminar todos los datos dependientes de un dato específico, o evitar borrar el mismo para evitar que hayan inconsistencias en la información. Por último dado que se escogió el modelo relacional la herramienta que se escogió fue PostgreSQL, el cual es un motor de bases de datos relacional con una licencia gratuita que puede llegar a administrar hasta 1000 usuarios simultáneos dependiendo de la maquina en donde se alojé el motor de bases de datos o Atributos de los sistemas y aplicaciones basados en web. En la gran mayoría de las aplicaciones Web se encuentran los siguientes atributos: o Intensidad de red. Una Web App reside en una red y debe satisfacer las necesidades de una variada comunidad de clientes. Una Web App puede residir en Internet, en una Intranet o en una Extranet. o Concurrencia. Un gran número de usuarios puede tener acceso a la Web App al mismo tiempo. En muchos casos, los patrones de uso entre los usuarios finales variarán enormemente. o Carga impredecible. El número de usuarios de la Web App puede variar en órdenes de magnitud de día a día. o Desempeño. Si un usuario de Web App debe esperar demasiado puede decidir irse a cualquier otra parte. o Disponibilidad. Una disponibilidad total es un concepto poco razonable, pero los usuarios de las Web Apps más populares demandan el acceso sobre una 32

33 base de 24/7/365 (24 horas al día, 7 días a la semana, 365 días al año para la disponibilidad del servicio) o Gobernada por los datos. La función primordial de muchas Web Apps es mostrar información, esta viene dada por texto, gráficos, audio y video y además se tiene acceso a bases de datos que no estaban integradas en el entorno Web. o Evolución continúa. Las aplicaciones Web evolucionan de manera continua, lo que implica un soporte continuo de actualización, hasta llegar incluso a actualizaciones minuto a minuto. o Inmediatez. Las Web Apps muestran un tiempo de comercialización de unos cuantos días, de semanas o incluso, con las herramientas modernas, de horas. Los ingenieros Web deben aplicar métodos de planeación, análisis, diseño, implementación y pruebas que han sido adaptados a los apretados tiempos requeridos para el desarrollo de Web Apps. o Seguridad. Es un aspecto muy importante a tener en cuenta puesto que las Web Apps están disponibles mediante el acceso a la red, es difícil limitar la población de usuarios finales que pueden tener acceso a la aplicación. Con la finalidad de proteger el contenido confidencial y ofrecer modos seguros de transmisión de datos, se deben implementar fuertes medidas de seguridad a lo largo de la infraestructura que sustenta una Web App y dentro de la aplicación de la misma. o Estética. Una parte innegable de la apariencia de una Web App es su presentación y la disposición de sus elementos. El éxito de una Web App 33

34 tiene tanto que ver con la estética como con el diseño técnico con el factor añadido que lo último que ve el usuario final es la presentación estética. 21 Aplicaciones en capas. Utilizar aplicaciones compactas causa problemas de integración en sistemas de software complejos como puede ser en una empresa, para resolver estos problemas las aplicaciones se han dividido en tres capas: Que permiten distribuir el trabajo de creación de una aplicación por niveles, así cada grupo de trabajo está totalmente abstraído del resto de niveles. Las tres capas son: o Capa de presentación. Es la que ve el usuario presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso. También se conoce como interfaz gráfica y debe ser entendible y fácil de usar. o Capa de negocio. Allí residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio porque aquí se establecen todas las reglas que deben cumplirse. Se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para la gestión de los datos. 21 Pressman, Roger. Ingeniería del software un enfoque práctico. 34

35 o Capa de datos. Es donde residen los datos y es la encargada de acceder a los mismos, mediante las solicitudes de almacenamiento o recuperación desde la capa de negocio. Figura: 02 Arquitectura en tres capas Fuente: Proyecto ONess. Carlos Sánchez Gonzáles Si se establece una separación entre la capa de presentación y es replicada en cada entorno de usuario, y la capa de negocio, que quedaría centralizada en un servidor de aplicaciones, según el diagrama que podemos ver en la Figura 02 se obtiene una potente arquitectura que nos otorga algunas ventajas: o Centralización de los aspectos de seguridad y transaccionalidad. o Las modificaciones y mejoras sean automáticamente aprovechadas por el conjunto de los usuarios, reduciendo los costes de mantenimiento. o Mayor sencillez de los clientes. 35

36 La distribución en capas más común es la que se muestra en la figura 03, integrando interfaz web y modelo en un mismo servidor aunque conservando su independencia funcional. 22 Figura: 03 Arquitectura web en tres capas Fuente: Proyecto ONess. Carlos Sánchez Marco Conceptual Comercio electrónico. Abarca las cuestiones suscitadas por toda relación de índole comercial, sea o no contractual, estructurada a partir de la utilización de uno o más mensajes de datos o de cualquier otro medio similar. Las relaciones de índole comercial comprenden, sin limitarse a ellas, las siguientes operaciones: toda operación comercial de suministro o intercambio de bienes o servicios; todo acuerdo de distribución; toda operación de representación o mandato comercial; todo tipo de operaciones financieras, bursátiles y de seguros; de construcción de obras; de consultoría; de ingeniería; de concesión de licencias; todo acuerdo de concesión o explotación de un servicio público; de empresa conjunta y otras formas de cooperación industrial o comercial; de transporte de mercancías o de pasajeros por vía aérea, marítima y férrea, o por carretera Tomado de: 23 Tomado de: 36

37 Comercio electrónico de negocio a consumidor. Son negocios en línea que venden a consumidores individuales. Contratación electrónica. Es todo proceso de formación de un contrato que involucre exclusivamente el uso de medios electrónicos. 24 Factura electrónica. Es el documento que soporta transacciones de venta de bienes y/o servicios, que para efectos fiscales debe ser expedida, entregada, aceptada y conservada por y en medios y formatos electrónicos, a través de un proceso de facturación que utilice procedimientos y tecnología de información, en forma directa o a través de terceros, que garantice su autenticidad e integridad desde su expedición y durante todo el tiempo de su conservación, de conformidad con lo establecido en este decreto, incluidos los documentos que la afectan como son las notas crédito. 25 Software libre. Se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software 26 Modelo de negocios. Conjunto de actividades planeadas, diseñadas para producir un beneficio en un mercado. Modelo de negocios del comercio electrónico. Modelo de negocios que trata de usar e impulsar las cualidades únicas de internet y en la www. 24 Tomado de: Tomado de: de2007.pdf 25 Tomado de: Decreto1929de2007.pdf 26 Tomado de: 37

38 Marco Tecnológico. A continuación se hace referencia a las distintas tecnologías que se implementan en Merkonsola, con el fin de brindar una visión clara y concisa de las razones que respaldan el uso de estas herramientas para el proceso de desarrollo. Siendo consecuente con lo anteriormente expuesto, a continuación se explicara de manera más detallada cada una de las capas y las tecnologías usadas en cada una de ellas: o Capa de Presentación: Con motivo de diseñar un entorno grafico agradable y funcional con el que pueda interactuar el usuario final, la interfaz gráfica es desarrollada mediante HTML 4 reglamentada por la W3C 27, el cual es un lenguaje de etiquetas que actualmente predomina en desarrollo de páginas web. Este se compone de elementos los cuales son la estructura básica de este Lenguaje. Estos elementos a su vez, tienen dos propiedades básicas: atributos y contenido. Cada atributo y contenido tiene ciertas restricciones para que se considere válido al documento HTML. Los atributos del elemento están contenidos en la etiqueta de inicio y el contenido está ubicado entre las dos etiquetas. Algunos elementos, no tienen contenido ni llevan una etiqueta de cierre. o Capa Lógica de Negocio: Para esta capa se opta por implementar la plataforma J2EE6 de JAVA, especificada y reglamentada por Sun Microsystems, debido a que es un entorno potente en el 27 La World Wide Web Consortium (W3C) es una comunidad internacional que desarrolla estándares para garantizar el crecimiento a largo plazo de la Web. 38

39 desarrollo de aplicaciones web empresariales. Sumado a esto este Lenguaje ofrece otras ventajas, como el ser diseñado para tener un soporte para trabajo en red por defecto; incluyendo aspectos esenciales tales como la programación con un enfoque orientado a objetos. Conjuntamente permite una ejecución multiplataforma, lo cual facilita a la aplicación ser adaptable a cualquier tipo de cliente que quiera hacer uso de la misma. A pesar que en el mercado actual se ofrecen distintas alternativas con características similares, JAVA es una herramienta que cuenta una licencia GPL 28, lo cual disminuye enormemente los costos de desarrollo. Esta capa posee estrecha relación con la de Presentación, puesto que el código HTML va a ser implementado conjuntamente con Servlets y JSP s, los cuales son alojados en el servidor Apache Tomcat. Este último, es un el servidor de Aplicaciones, que va acorde con las necesidades del proyecto, dado que es un servidor web de licencia gratuita, amplia gama de API s 29, fácil implementación y con gran capacidad para administrar alta concurrencia de usuarios. De igual manera Tomcat por sí mismo es autónomo para funcionar por si solo como servidor, sin tener la necesidad obligatoria de recurrir a más proveedores para complementar los servicios necesarios. 28 Es aquella Licencia creada por la Free Software Foundation, la cual protege la libre distribución, modificación y uso de software. Definición tomada del sitio de Internet: (22/06/2010) 29 Application Programming Interface, Es una agrupación abstracta de métodos o funciones que es implementada en el desarrollo de programas y aplicaciones de software. 39

40 Este servidor brinda total compatibilidad con la plataforma de desarrollo web J2EE6 30 (Servlets y JSP). Adicionalmente presenta la gran ventaja en cuanto a interoperabilidad, ya que Tomcat al ser desarrollado en Java, puede ser implementado en cualquier Sistema Operativo, siempre y cuando este último cuente con la Máquina virtual de Java. o Capa de Datos: En esta capa se hace uso de PostgreSQL v Se opta por este software en especial, puesto que es un sistema de gestión de base de datos relacional, con licencia BSD 31, situación que permite reducir de gran manera los costos. Además de ser software libre, PostgreSQL es favorable para el proyecto puesto que es apto para soportar aplicaciones con alta concurrencia, circunstancia que permite sacar el máximo de rendimiento en una gran cantidad de procesos que pueden estar usando una misma tabla sin generar problemas de rendimiento. De esta manera permite administrar de forma adecuada las múltiples transacciones que soportara la aplicación constantemente. Adicionalmente otra gran ventaja de usar PostgreSQL, radica en esta última cuenta con un soporte de transacciones distribuidas 32, capacidad que tiene un motor de bases de datos de interactuar con sus similares (otros sistemas de gestión), sin afectar su normal funcionamiento. 30 Java 2 Enterprise Edition. Es el estándar de la industria de la computación empresarial Java. Utilizada para crear aplicaciones web de próxima generación para las aplicaciones web empresariales. Traducción tomada del sitio de Internet: (22/06/2010) 31 Berkeley Software Distribution, Licencia que permite el uso del código fuente en software no libre; presenta menos restricciones en comparación con licencias como GPL. 32 Las transacciones distribuidas abarcan dos o más servidores conocidos como administradores de recursos. La administración de la transacción debe ser coordinada entre los administradores de recursos mediante un componente de servidor llamado administrador de transacciones. Definición tomada del sitio de Internet: (22/06/2010) 40

41 Figura: 04 Arquitectura De La Aplicación Marco Legal. La tienda virtual para la solicitud de pedidos on-line con pago anticipado acorde a su contexto, se rige dentro de los siguientes marcos legales establecidos por la ley y demás entidades pertinentes, según: DECRETO 1360 (JUNIO 23 DE 1989) Decreto suscrito por el presidente de la República, tiene como objetivo reglamentar la inscripción de software ante el DNDA 33. Tal como lo establece su artículo 1, el soporte lógico se considera como una creación propia del dominio literario. Situación acorde a la Ley 23 de 1982 y la Ley 44 de 1993, sobre Derechos de Autor y que reafirma tal posición en el artículo 4, el cual expresa que el soporte lógico 34, es considerado como obra inédita, salvo manifestación en contrario hecha por el titular de los derechos de autor. 33 Dirección Nacional de Derecho de Autor, Es la entidad responsable del diseño, dirección, administración y ejecución de las políticas gubernamentales en materia de derecho de autor en Colombia. 34 Acorde con el literal a, artículo 3 del decreto 1360 de 1989 expedido por el presidente de la república de Colombia, el soporte lógico es: La expresión de un conjunto organizado de instrucciones, en lenguaje natural o codificado. 41

42 En la medida de evitar posibles ambigüedades se definen en su artículo 2 las definiciones pertinentes como lo son: Programa de computador, Descripción de programa y Material auxiliar. LEY 44 CONGRESO DE LA REPUBLICA (FEBRERO 5 DE 1993) Esta ley expedida por el congreso de la república, es una modificación a la ley 23 de 1982 y la ley 29 de 1944 elaboradas por el mismo ente en virtud de los derechos de Autor y conexos. La ley 44 de 1993 tiene como objetivo establecer y reglamentar los derechos de autor en Colombia. Por tal motivo en su artículo 3 hace mención de que tipos de obras pueden ser inscritas ante el registro Nacional de Derechos de Autor. Otros aspectos que son estipulados en esta ley, son definidos en el capítulo 5 artículos 68 y 69, los cuales definen que en caso de ejecución con fines comerciales, el utilizador debe remunerar al autor y que porcentaje debe darle como mínimo. LEY 527 CONGRESO DE LA REPUBLICA (AGOSTO 18 DE 1999) Esta ley reglamenta y define los aspectos pertinentes a: mensajes de datos 35, el comercio electrónico 36. Una de las principales razones por las cuales se tiene en cuenta esta ley, radica en que define los conceptos necesarios que permiten una 35 Según el artículo 2 de la ley 527 de 1999 expedida por el congreso de la república de Colombia, los mensajes de datos contemplan: La información generada, enviada, recibida, almacenada o comunicada por medios electrónicos, ópticos o similares, como pudieran ser, entre otros, el Intercambio Electrónico de Datos (EDI), Internet, el correo electrónico, el telegrama, el télex o el telefax. 36 Según el artículo 2 de la ley 527 de 1999 expedida por el congreso de la república de Colombia, el comercio electrónico: Abarca las cuestiones suscitadas por toda relación de índole comercial, sea o no contractual, estructurada a partir de la utilización de uno o más mensajes de datos o de cualquier otro medio similar. Las relaciones de índole comercial comprenden, sin limitarse a ellas, las siguientes operaciones: toda operación comercial de suministro o intercambio de bienes o servicios. 42

43 inequívoca interpretación del comercio electrónico en su artículo 2; situación que tiene estrecha relación el presente proyecto. Además de definir la terminología necesaria, esta provee por medio de sus artículos 26 y 27, aspectos relacionados del Comercio electrónico en materia de contratos de transporte de mercancías y otros documentos requeridos para tal fin. De igual manera designa a la superintendencia de industria y comercio como ente regulador en las actividades de ley propias del esta clase de Comercio y demás situaciones afines, tal cual lo expresa su artículo 41. DECRETO 1929 MINISTERIO DE HACIENDA (MAYO 29 DE 2007) Este decreto provee la reglamentación y regulación concerniente a la factura electrónica 37. En su artículo 1, establece las definiciones pertinentes de esta temática dentro de las cuales se tienen en cuenta los actores involucrados como los son: Facturación Electrónica, Obligado facturar, Adquiriente 38, Tercero y Número de la facturación electrónica. En lo referente al contenido técnico, expedición y control de emisión de la factura electrónica se expresa detalladamente en sus artículos 4,7 y Según el artículo 1 del decreto 1929 de 2007 expedido por el Ministerio de Hacienda de la república de Colombia, la factura electrónica : Es el documento que soporta transacciones de venta de bienes y/o servicios, que para efectos fiscales debe ser expedida, entregada, aceptada y conservada por y en medios y formatos electrónicos, a través de un proceso de facturación que utilice procedimientos y tecnología de información, en forma directa o a través de terceros, que garantice su autenticidad e integridad desde su expedición y durante todo el tiempo de su conservación, de conformidad con lo establecido en este decreto, incluidos los documentos que la afectan como son las notas crédito. 38 Acorde con el artículo 1 del decreto 1929 de 2007 expedido por el Ministerio de Hacienda de la república de Colombia, el adquiriente es: La persona natural o jurídica que como adquirente de bienes o servicios debe exigir factura o documento equivalente y, que tratándose de la factura electrónica, la acepta y conserva para su posterior exhibición, en los términos que se establecen en el presente decreto. 43

44 El primero tiene presente los artículos 3 y 4 estipulados en la resolución de la Dirección de impuestos y Aduanas Nacionales expedida el 28 de Noviembre de 2007, los cuales reglamentan y especifican la numeración de este tipo de factura. Dichos artículos son definitivos en lo referente a la facturación electrónica de una Tienda virtual dado su relación con la Web DISEÑO METODOLÓGICO Método de investigación. Es primordial mencionar que para el proyecto se emplea el método de investigación cuantitativa, dado que el contexto en el cual se desarrolla la propuesta, así lo amerita. Se aplica este tipo de investigación ya que se identifica y define claramente la problemática en cuestión, se establecen objetivos claros y concisos enfocados en precisar una viable alternativa de solución, a fin de que puedan ser respaldados por la elaboración e implementación de instrumentos para recolección de información y medición de las variables, a través de los resultados obtenidos Universo. Muestra, diseño de Variables. Concerniente a la población, se hace énfasis en que son todos aquellos Minimercados de barrio relacionados con la venta de víveres y abarrotes. Para la muestra, se toma específicamente el Minimercado Andalucía ubicado en el barrio que lleva su mismo nombre, zona 8 de la localidad de Kennedy en la ciudad de Bogotá D.C Instrumentos y análisis. Es necesaria la realización de un Estado del Arte y recopilación documental, que brinden una perspectiva clara de los proyectos, investigaciones, soluciones y alternativas afines a esta propuesta. (Ver anexo 1). 44

45 Es de suma importancia la ejecución de la investigación cuantitativa, para obtener una veraz: interpretación, objetividad y metodología que aporte de manera significativa al desarrollo del Proyecto Hipótesis. En razón a la investigación utilizada: investigación aplicada (ingenieril - tecnológica), se enfatiza en el hecho de que no se define una hipótesis comprobable para este proyecto, puesto que no se hace uso del método científico para tal fin. En cambio se pretende hacer uso de teorías y planteamientos con reconocimiento en la industria y en el medio ingenieril, con el fin de aplicarlos al proceso de investigación en aras de cumplir con los objetivos planteados, más no el refutar o comprobar alguna teoría o hipótesis en concreto Tipo de investigación. Es primordial mencionar que para este proyecto se emplea una metodología aplicada (ingenieril - tecnológica), puesto que esta conlleva el uso y aplicación de conocimientos tecnológicos e ingenieriles previamente adquiridos, los cuales pretenden diseñar, innovar y desarrollar productos para las necesidades y exigencias de la sociedad contemporánea. Por ende no se busca comprobar o refutar algún tipo de hipótesis como se mencionó en el anterior apartado Actividades. A continuación se especifican una serie de actividades muy generales, que se tienen en cuenta para la ejecución y cierre satisfactorio del proyecto, que son la base para la identificación de las subtareas o subprocesos que dicha fase del proyecto involucra, los cuales son necesarios para alcanzar los objetivos planteados. Entre estas se encuentran: Levantamiento de Información (Encuestas, Entrevistas, Estudio actual del Minimercado). 45

46 Definición de metodologías (Proyecto y Producto de Software). Definición de los roles del equipo del proyecto. Diseño del sistema y modelo de negocios. Desarrollo del producto de software. Realización de pruebas del software (testing). Documentación del producto de software. Implementación del producto de software. Cierre del proyecto. 46

47 2. ESTRUCTURA TEMÁTICA 2.1. GESTIÓN DEL PROYECTO A continuación se explican cada una de las etapas del ciclo de vida de un proyecto propuesto por la metodología PMBOK, las cuales se desarrollaron para la gestión del presente proyecto Inicio del Proyecto. Tal cual se hacía mención en el resumen del presente documento, se optó por utilizar como metodología de gestión del proyecto el PMBOK propuesto por el PMI. Por tal motivo en la fase inicial del desarrollo del proyecto se elaboró el acta de constitución del proyecto (Ver anexo 2) y la WBS (Ver anexo 3), puesto que son fundamentales para definir los aspectos referentes a las actividades, hitos, costos y tiempo requerido para el cumplimiento de las fases del proyecto Organización y Preparación. En esta fase se establece el plan de ejecución del proyecto que se va a seguir, el cual contempla: actividades y acciones pertinentes que se deben cumplir dentro del tiempo estipulado acorde a lo establecido en el cronograma, los factores inciertos que pueden comprometer el normal desarrollo del proyecto, los recursos necesarios y los canales de comunicación empleados en el equipo de trabajo. Por ello dicho plan está constituido por la gestión de horarios (Ver anexo 5), gestión de riegos (Ver anexo 6), adquisiciones (Ver anexo 7) y comunicaciones (Ver anexo 8). De igual forma debido a la variedad de metodologías, modelos, patrones y demás herramientas utilizadas en el presente del proyecto, se lleva a cabo una integración entre estos últimos, cuyo principal objetivo es definir su estrecha 47

48 relación, así como la forma en que estos orientaran sus esfuerzos de manera convergente para formar un marco de trabajo integro que procure cumplir con los objetivos del proyecto (Ver anexo 4) Ejecución del trabajo. Para el desarrollo del producto de software se ha seleccionado la metodología de desarrollo de software Scrum, la cual se apoya en el lenguaje UML para modelar el sistema y en el estándar IEEE830 para la Especificación de los Requisitos del Software. Estos se detallan con un mayor grado de profundidad en los anexos 9, 11, y Cierre del Proyecto. El cierre del proyecto concluyo una vez se cumplieron a cabalidad los siguientes aspectos: Cumplimiento de los objetivos planteados. Ejecutar en su totalidad las fases previas a la actual (Inicio, Organización y Preparación, Ejecución del trabajo). Implementación del Producto de Software. Realización de pruebas de rendimiento, una vez implementado el Software. Capacitación del Cliente. Aceptación y visto bueno del Cliente MODELO Y ARQUITECTURA DE SOFTWARE Modelo de negocio. En la siguiente figura 05, se muestra el modelo de contexto o de negocio propuesto para el software Merkonsola. Este diagrama se diseñó en función de identificar los actores del sistema, así como la forma en que 48

49 estos últimos interactuarían con los procesos del sistema correspondientes. Para un mayor grado de compresión se elaboró la Tabla 02 referente a las convenciones pertinentes de dicho diagrama. Figura: 05 Modelo de contexto Convenciones: Tabla: 02 Convenciones Actor Cliente Usuarios Proveedores Descripción Minimercado Andalucía Personas que realizan sus compras en el Minimercado Andalucía Son aquellas empresas o personas independientes que suministran los productos que son comercializados por el Minimercado. Son aquellos objetos comercializados por el Minimercado, 49

50 Productos que satisfacen una necesidad de los usuarios, dentro de ellos se destacan: víveres, productos de aseo, legumbres, etc. Propietarios Grupo de desarrollo del proyecto. Contexto del Diagrama El sistema permite al cliente gestionar el catálogo de productos que se oferta a los usuarios, generar los tickets de pago anticipado, necesarios para que los usuarios seleccionen y realicen el pago correspondiente del pedido solicitado. De igual manera el software facilita la gestión de los proveedores del Minimercado que suministran los respectivos productos para la venta a los usuarios Arquitectura del Sistema. La arquitectura del Merkonsola se muestra en la Figura 06, esta última se compone de 3 capas claramente definidas: Capa de Presentación, Lógica de negocio y Datos. De forma muy general se hace énfasis en que la capa de datos permite tanto al cliente como a los usuarios interactuar mediante la GUI (Graphic Unit Interface) que es visualizada mediante un navegador web; por otra parte la capa de lógica de negocio se desarrolló en base a aquellos procesos que son fundamentales y necesarios para alcanzar su misión estratégica de negocio; finalmente la capa de datos, es la base sobre la cual la Aplicación soporta sus estructuras de datos que le permitirá la persistencia de su información. 50

51 Figura: 06 Arquitectura del sistema Capa de Presentación. En el caso concreto de Merkonsola se diseñaron y desarrollaron las JSPs (Java Server Pages), de tal manera que su aspecto brindara un Entorno Grafico atractivo, el cual permitiera una intuitiva y fácil navegabilidad. Por otro lado se tuvo muy en cuenta que las JSPs ofrecieran un alto grado de funcionalidad, con el fin de brindar un balance adecuado entre un aspecto grafico atractivo y una óptima funcionalidad, en aras de proveer al cliente una agradable experiencia en el momento de interactuar con la Aplicación. La figura 07 muestra la JSP de los pagos registrados, en la cual se listan cada uno de ellos con su respectivo: código, tipo, fecha de pago, código del pedido pagado, el cliente que realizo el pago y el estado del pago. 51

52 Figura: 07 Pagos registrados Básicamente estas JSPs permitieron un diseño y desarrollo web rápido de las páginas Web dinámicas independientemente de la plataforma a usar. La tecnología JSP contribuye a aislar la GUI de los contenidos, en favor de cambiar el diseño web en general, sin preocuparse por el contenido dinámico correspondiente. Para ampliar el ámbito de los JSP y su implementación en el proyecto se recomienda ver Anexo Capa Lógica de Negocio. El minimercado Andalucía no contaba con una bitácora de procesos diseña o regida por algún estándar, ni mucho menos tenia algún documento en concreto que permitiera establecer aquellos procesos que involucraba la solicitud de pedidos a domicilio. Por este motivo para el desarrollo de la capa de lógica de negocio se identificaron en primera instancia todos los procesos correspondientes que involucra el registro, solicitud y facturación de pedidos a domicilio del minimercado. Posteriormente se modelaron cada uno de estos procesos mediante el Lenguaje de Modelado Unificado (UML) teniendo muy presente para tal fin los requisitos consignados en el documento IEEE

53 La figura 08 muestra el modelamiento del proceso: Generar orden de pedido en un diagrama de actividades UML. Figura: 08 Proceso generar orden del pedido Especificación de Requisitos del Software (ERS). La metodología de desarrollo Scrum hace énfasis en una herramienta específica y bastante usada para la especificación de los requisitos del software, que de la mano del Lenguaje de Modelado Unificado, son muy útiles para dicho fin. Más exactamente se hace alusión al Product Backlog, con el fin de realizar el proceso de levantamiento de información, en aras de definir el contexto necesario para las iteraciones del ciclo de vida del producto de software. Por ello con el Product Backlog y junto con la realización de algunas encuestas adicionales, se establecieron aquellas necesidades o requisitos solicitados por el cliente con el ánimo de ser complementados mediante la elaboración del estándar 53

54 IEEE830 39, dichos requisitos son satisfechos por el software dentro de sus funcionalidades para la presente aplicación web. En consecuencia a continuación se muestra el Product Backlog tanto para los requisitos funcionales como para los no funcionales como lo detallan las próximas figuras. Para consultar la completa Especificación de Requisitos de Software del Product Backlog con mayor nivel de detalle, se recomienda ver el anexo 11. Requisitos Funcionales. Estos requisitos tal como lo indica su definición genérica, son aquellos que describen el comportamiento de un Sistema, para el presente caso el del software. La siguiente Tabla 03, muestra el Product Backlog que recopila todos los requisitos funcionales recolectados. Tabla: 03 Requisitos funcionales Clase de Requisito Gestión Catálogo Nombre Crear Proveedores, Categorías, Productos y Fabricantes Editar Proveedores, Categorías, Productos y Fabricantes Descripción Debe permitir la creación de los proveedores, categorías, productos y fabricantes. Se encarga de modificar los datos correspondientes a los proveedores, categorías, productos y fabricantes. 39 Es un estándar provisto por la IEEE, el cual define los aspectos pertinentes a la Especificación de Requisitos de Software (ERS) de forma detallada. 54

55 Gestión Clientes Gestión Pedidos Listar Proveedores, Categorías, Productos y Fabricantes Eliminar Proveedores, Categorías, Productos y Fabricantes Crear Clientes Editar Clientes Listar Clientes Eliminar Clientes Editar Pedido Listar Pedidos Eliminar Pedido Permite listar todos los proveedores, categorías, productos y fabricantes; registrados en la base de datos. Se encarga de eliminar los proveedores, categorías, productos y fabricantes que el administrador del sistema requiera. Debe permitir la creación de los clientes; de tal manera que debe solicitar una contraseña de inicio de sesión. Se encarga de modificar los datos correspondientes a los clientes. Permite listar todos los clientes registrados en la base de datos. Se encarga de eliminar los clientes que el administrador del sistema requiera. Se encarga de modificar los datos correspondientes a los pedidos (productos). Permite listar todos los pedidos solicitados por los usuarios junto con su estado. Se encarga de eliminar los pedidos. 55

56 Gestión Pago Gestión Tickets Registro Autentificación y Cuenta Usuario Seleccionar Modalidad Pago Realizar Pago Generar Tickets Imprimir Tickets Eliminar Tickets Registro Usuario Registro Administrador Autentificar Usuario Listar Historial Pedidos Consultar Saldo Disponible El Sistema debe proveer al usuario las modalidades de pago: contra entrega y anticipado. El Sistema permitirá realizar el pago de los pedidos usando pago anticipado o a contra entrega. El Sistema debe generar tickets de pago anticipado. El Sistema permitirá imprimir los tickets de pago anticipado. El Sistema debe proveer la opción de eliminar tickets de pago anticipado. Se encarga de solicitar, editar y actualizar los datos personales del usuario. Se encarga de solicitar, editar y actualizar los datos personales del administrador de la tienda virtual. El sistema debe autentificar los datos de usuario y contraseña necesarios para permitir el acceso a la cuenta de usuario. Permite listar todos los pedidos realizados por el cliente junto con su estado correspondiente. El Sistema debe informar al cliente su saldo anticipado disponible. 56

57 Listar Tickets El sistema debe listar todos los tickets adquiridos por el cliente. Requisitos No Funcionales. A diferencia de los requisitos funcionales, los no funcionales no se basan en el comportamiento del sistema, ya que se centran en otros aspectos fundamentales y que son de gran importancia como: La seguridad, Rendimiento, Portabilidad, etc. Siendo consecuente con lo previamente dicho, enseguida se especifica en la Tabla 04, aquellos requisitos no funcionales. Tabla: 04 Requisitos No Funcionales Clase de Requisito Nombre Descripción Portabilidad Ejecución del software independiente de la plataforma. El software se debe ejecutar en un navegador web, lo cual permite hacer uso del mismo sin importar la plataforma utilizada. Permite que cada vez que se solicite al sistema una determinada Rendimiento Optimización del actividad o tarea, esta se realice tiempo de respuesta. con un tiempo de repuesta aceptable con respecto a la complejidad requerida. Se deben definir perfiles (usuario y Seguridad Autentificación de Usuario administrador) con sus respectivas contraseñas, los cuales establezcan en forma clara los roles y 57

58 Usabilidad / Diseño de Interfaz Navegabilidad Gráfica de Usuario no compleja. Garantizar la Fiabilidad integridad de la información solicitada por el usuario. actividades que pueden realizar cada una de ellos en la tienda virtual. Se debe diseñar una interfaz gráfica de usuario sencilla, que permita al usuario identificar de forma clara las opciones provistas por el software, así como la una navegación que facilite con un mínimo de interacciones cumplir el objetivo deseado por el usuario. El sistema debe garantizar que la información que el usuario solicite sea integra y funcional, es decir, que las actividades y procesos del sistema satisfagan los resultados esperados por el cliente. Diagramación UML. Una vez definidos los requisitos y procesos con los que el software Merkonsola debe cumplir, como siguiente paso se procede a diseñar el Diagrama general de casos de uso. Este último establece el contexto del sistema con base en los actores que interactúan junto con sus funcionalidades. A continuación se muestra dicho Diagrama General en la figura 09. Para consultar en detalle el modelamiento UML de Merkonsola, se puede ver el Anexo 19, el cual contiene el compendio de todos los diagramas realizados para el diseño de la Aplicación web. 58

59 Figura: 09 Diagrama general casos de uso 59

60 Capa de Datos. En el desarrollo correspondiente a la capa de datos de Merkonsola, se identificaron en primera instancia las entidades y sus atributos pertinentes al contexto del problema. Consecutivamente se elaboró el diseño del MER (Modelo Entidad-Relación) debidamente normalizado con cada una de las entidades identificadas previamente. De esta forma se obtuvo el diseño lógico de la Base de datos. Este último se convirtió en un diseño físico, una vez dichas entidades fueron creadas como objetos (tablas) acorde al Diccionario de datos en el Sistema Gestor de Base de Datos Relacional (PostgreSql). Los dos siguientes apartados describen de forma más detallada el proceso de diseño del MER y el diccionario de datos. Diccionario de Datos La elaboración del presente Diccionario junto con el diseño del MER, se realizaron a partir del proceso de levantamiento de información por medio de las encuestas y entrevistas efectuadas, así como de la Especificación de Requisitos del Software (Anexo 11). Para el caso específico del Diccionario de datos, se definieron todas aquellas características lógicas de los datos como lo son: campos de las tablas, tipos de datos, tamaños de datos, descripción, etc. Para consultar el Diccionario de datos más detalladamente, se recomienda ver Anexo 12. Modelo Entidad Relación (MER) En este modelo se relacionaron de forma lógica y normalizada todas las entidades previamente identificadas en las encuestas, entrevistas y el documento IEEE830, como lo muestra la figura

61 Figura: 10 Modelo Entidad Relación 61

62 Módulos del sistema. La siguiente figura 11, muestra los módulos que componen el software, así como aquellos submódulos de los cuales están compuestos. Se recomienda ver Anexo 13, para consultar en detalle la descripción de los módulos. Figura: 11 Módulos del sistema Los módulos presentados anteriormente hacen parte del framework de J2EE, pero no se tomaron en su totalidad los provistos por este último, ya que solo se hizo uso de aquellos que el ámbito de la aplicación requirió, tal cual se muestra en la anterior figura 09. Para consultar la gestión de horarios designada para el desarrollo e integración de los módulos anteriores se puede consultar el Anexo IMPLEMENTACIÓN DE LA METODOLOGÍA SCRUM. A continuación se especifica con un mayor grado de detalle el desarrollo de la metodología Scrum implementada en el proyecto Merkonsola, en aras de definir y 62

63 describir claramente cada uno de los sprints, las fases, resultados y actividades en cada fase. Conforme a lo anteriormente dicho, las tablas 05, 06 y 07 tienen como finalidad mostrar los Sprints y sus fases, cada uno con una duración de 4 semanas, así como con los resultados y actividades correspondientes por cada fase. Tabla: 05 Sprint Nº1 Sprint Nº1 Fase: Planeación (Pre-game) Sub-fase Actividad Resultados / Observaciones Realizar encuestas a los clientes del minimercado. El principal resultado del primer sprint cosiste en: Entradas Realizar entrevista al Product Owner (Propietario Minimercado Andalucía). Socialización y adaptación de Scrum en el equipo de trabajo (TEAM). Product Backlog Planeación Sprint En base a las encuestas, entrevistas y reuniones, definir la primera versión del Product Backlog con los requisitos priorizados del software. Establecer el cronograma de entregas de cada uno de los entregables. Adquirir los recursos necesarios (personales, presupuesto, físicos y tecnológicos). Definir los roles del proyecto, socializar sus funciones y responsabilidades asignadas. Definir los canales de comunicación y resolución de conflictos. Planificar reuniones de revisión de avances a lo largo de todas las fases de la metodología. Adaptar la metodología Scrum al presente proyecto, definiendo: roles, duración del sprint, entregables, responsabilidades, etc. Elaborar la primera versión del Product Backlog, para definir de forma global los requisitos priorizados que el software debe satisfacer. En un principio se dificulto la adaptación de Scrum al grupo de trabajo, debido a que esta última ofrece una forma distinta de desarrollar software comparada con la tradicional, lo cual genero al inicio un cierto grado de resistencia a cambio. 63

64 Fase: Desarrollo (Game) Sub-fase Actividad Resultados / Observaciones Definir la arquitectura del software. Los principales resultados de Realizar el modelamiento (UML) del esta fase fueron: software basado en los requisitos del Product Backlog. Modelamiento UML del software. Aplicar patrones y estándares de Construcción del primer Desarrollo diseño de software. prototipo del software. Sprint Construir el software en base al modelamiento y patrones definidos. Realizar pruebas de software para verificar el cumplimiento de los requisitos registrados en el Product Backlog. Scrum Diario El Scrum diario se realizó de forma presencial, mediante la realización de reuniones cortas (20 min), donde se expusieron los principales inconvenientes y se aportaron soluciones prácticas para resolverlos. Durante esta fase se presentaron algunos problemas en el cumplimiento de los entregables establecidos en el cronograma, debido a que el TEAM recién estaba adoptando la metodología. Por ello el Scrum Master brindo algunas pautas para facilitar dicha situación y no generar retrasos en las entregas. Fase: Cierre (Post-game) Sub-fase Actividad Resultados / Observaciones Revisión del Sprint Revisar la entrega oportuna de los entregables en los tiempos establecidos. Verificar si el prototipo de software cumple con los requisitos del Product Backlog. Detectar los principales inconvenientes presentados. Adaptar los cambios necesarios, para retroalimentar el siguiente sprint. En esta revisión se detectaron y ajustaron inconvenientes en el normal desarrollo de Scrum por: Desconocimiento de la metodología. Resistencia al cambio. Falta de información sobre la misma. Para corregir estos últimos, el Scrum master capacito al TEAM en aquellos detalles o dudas detectadas. 64

65 Entregable Parcial Constatar si el prototipo satisface las necesidades expuestas por el Product Owner. Se obtuvo un prototipo de software con un nivel de madurez bajo, es decir que cumple aproximadamente con un 35% los requisitos solicitados por el Product Owner. Tabla: 06 Sprint Nº2 Sprint Nº2 Fase: Planeación (Pre-game) Sub-fase Actividad Resultados / Observaciones Adaptar al presente Sprint, las recomendaciones y ajustes solicitados por el Scrum Master en el El principal resultado del primer sprint cosiste en: anterior Sprint. Realizar reunión con el Product Entradas Owner, para retroalimentar y depurar el Product Backlog. Registrar recomendaciones expuestas por el equipo de trabajo para agilizar el proceso de desarrollo. Product Backlog Planeación Sprint Registrar nuevos requisitos exigidos por el Product Owner. Refinamiento del Product Backlog, en donde se eliminaron requisitos: redundantes, no necesarios, implícitos, etc. Establecer el nuevo cronograma de entregas de cada uno de los entregables. Planificar reuniones de revisión de avances. Verificar si se requiere recursos adicionales (personal, presupuesto, físicos y tecnológicos). Se elaboró un Product Backlog más refinado y conciso, que permitió agilizar el proceso de desarrollo, debido a que se eliminaron requisitos redundantes e innecesarios que contribuían a perder tiempo y malgastar recursos. Mayor agilidad en la adopción de la metodología, debido a que el TEAM interiorizo y adopto la metodología en el anterior Sprint. 65

66 Fase: Desarrollo (Game) Sub-fase Actividad Resultados / Observaciones Desarrollo Sprint Scrum Diario Fase: Realizar ajustes al modelamiento (UML) debido al refinamiento y adición de los nuevos requisitos del Product Backlog. Revisar la adecuada implementación de los patrones y estándares de diseño de software. Construir el software en base al nuevo modelamiento y patrones definidos. Realizar pruebas de software para verificar el cumplimiento de los requisitos registrados en el Product Backlog. En comparación con el anterior Sprint, las reuniones diarias se realizaron a través de Skype, debido a que por la gran carga de trabajo no era posible que el TEAM, el Product Owner y el Scrum master se encontraran presencialmente. Cierre (Post-game) Los principales resultados de esta fase fueron: Modelamiento UML optimizado. Construcción del segundo prototipo del software. Cabe destacar que durante este segundo sprint de hizo difícil reunir a los stakeholders, debido a su gran cantidad de compromisos con el presente proyecto, así como otros de índole personal. Pero esta situación no repercutió de forma negativa en el normal desarrollo del proyecto, debido a la gran flexibilidad de Scrum y al sentido de pertenencia de cada uno de los stakeholders por cumplir con sus actividades asignadas. Sub-fase Actividad Resultados / Observaciones Revisión del Sprint Realizar una minuciosa revisión que permita detectar si el prototipo de software cumple con los requisitos del Product Backlog exigidos por el Product Owner. Detectar los principales inconvenientes presentados durante el presente sprint. En esta revisión se presentaron las siguientes observaciones: Abandono del Scrum Master. Breve retraso en el cronograma debido al tiempo de adaptación del nuevo Scrum Master al proyecto en curso. Adaptar los cambios necesarios, El nuevo Scrum Master se 66

67 Entregable Parcial para retroalimentar el siguiente sprint. Constatar si el segundo prototipo satisface las necesidades expuestas por el Product Owner. acoplo de forma rápida al proyecto, brindando un enfoque práctico y ágil al proceso. Se obtuvo un prototipo de software con un nivel de madurez medio, es decir que cumple a cabalidad con cerca del 65% de los requisitos. Por ende este prototipo no satisface en su totalidad los requisitos definidos en el Product Backlog. Tabla: 07 Sprint Nº3 Sprint Nº3 Fase: Planeación (Pre-game) Sub-fase Actividad Resultados / Observaciones Adaptar al presente Sprint, las recomendaciones y ajustes solicitados por el nuevo Scrum Se realizó el refinamiento Master en el anterior Sprint. definitivo del Product Entradas Realizar reunión con el Product Owner, para retroalimentar y depurar el Product Backlog. Backlog, de esta manera se elaboró la versión final de dicho documento. Registrar recomendaciones expuestas por el equipo de trabajo para agilizar el proceso de desarrollo. Product Backlog Registrar nuevos requisitos exigidos por el Product Owner. Refinamiento del Product Backlog, en donde se eliminaron requisitos: redundantes, no necesarios, implícitos, etc. Establecer el nuevo cronograma de entregas de cada uno de los El nuevo enfoque aportado por el Scrum Master, permitió que para el tercer sprint se definiera el Product Backlog definitivo, puesto que asesoro ágilmente al TEAM para identificar los requisitos fundamentales a satisfacer. 67

68 Planeación Sprint Fase: Sub-fase Actividad Desarrollo Sprint Scrum Diario entregables. Planificar reuniones de revisión de avances. Verificar si se requiere recursos adicionales (personal, presupuesto, físicos y tecnológicos). Desarrollo (Game) Realizar menores ajustes al modelamiento (UML) debido al refinamiento del Product Backlog. Construir el software en base al modelamiento. Realizar pruebas de software para verificar el cumplimiento de los requisitos registrados en el Product Backlog. En este sprint final las reuniones diarias se realizaron de forma mixta, es decir que se llevaron a cabo la mitad vía Skype y la otra de forma presencial. Resultados / Observaciones Los principales resultados de esta fase fueron: Modelamiento UML definitivo. Construcción del tercer prototipo del software. Fase: Cierre (Post-game) Sub-fase Actividad Resultados / Observaciones Revisión del Sprint Entregable Parcial Verificar que el software cumpla a cabalidad con los requisitos registrados en el Product Backlog definitivo. Constatar si el prototipo final satisface las necesidades expuestas por el Product Owner. En esta revisión es de resaltar que: El Product Owner tuvo mayor disponibilidad de tiempo, por lo cual la relación TEAM-Product Owner favoreció un desarrollo más cercano, que incremento de gran manera la calidad, funcionalidad y expectativas del Product Owner. Finamente terminado este tercer sprint, se obtuvo como resultado una versión final del software Merkonsola, el cual a diferencia de sus anteriores prototipos, 68

69 cumplía con la totalidad de los requisitos y expectativas del Product Owner. Tabla: 08 Implementación Metodología Scrum Fase de Scrum Planeación Actividad Construcción del Product Backlog. Establecer el cronograma de entregas y funciones de cada uno de los prototipos o versiones del software. Constituir los grupos de desarrollo del proyecto, sus funciones y responsabilidades a desempeñar. Identificar y listar los riegos inherentes al proyecto, así como los controles a efectuar para mitigar su impacto. Definir las herramientas de software libre y hardware, más apropiadas para el desarrollo del software. Elaborar un estimado de costos, que permita establecer una estimación clara de la relación costo-benéfico que sea viable para el desarrollo del proyecto. Aplicado en Documento de Especificación de Requisitos (Ver anexo 11). Plan de Gestión de Horarios (ver Anexo 5). Actividades del desarrollo de los módulos (Ver anexo 14 ) Plan de Gestión de Riesgos (Ver anexo 6). Plan de Gestión de Adquisiciones (Ver anexo 7). Acta de Constitución del Proyecto (Ver anexo 2). 69

70 Arquitectura Definir los canales de comunicación y resolución de conflictos, para facilitar un adecuado ambiente de trabajo. Planificar reuniones de revisión durante todas las etapas de la metodología, en la que cada integrante de a conocer posibles cambios o mejoras a realizar para el Backlog. Si son aceptados las recomendaciones propuestas proceder a ajustar el Backlog. Definir los estándares y patrones con los que el producto de software debe cumplir. Examinar el Product Backlog para efectuar un control de cambios que sea necesario, antes de definir la arquitectura del sistema. Definir la arquitectura del sistema en base a al modelo de negocio propuesto, herramientas a emplear y requisitos del cliente. Diseñar los módulos del sistema acorde a los requisitos del cliente y a los módulos proporcionados por el framework definido en la arquitectura de software establecida (J2EE). Plan de Gestión de Comunicaciones (Ver anexo 8). Plan de Gestión de Comunicaciones (Ver Anexo 8). Documento de Especificación de Requisitos (Ver anexo 11). Actividades del desarrollo de los módulos (Ver anexo 14 ) Consultar Numeral de la estructura temática. Esquema de módulos del sistema (Ver Figura 11). 70

71 Congregar al equipo de desarrollo para Plan de Gestión de socializar todo el diseño UML y Comunicaciones arquitectura propuesta para iniciar el (Ver Anexo 8). desarrollo del software. Implementar los estándares y patrones Documento de de diseño definidos en la fase de Especificación de Desarrollo planeación. Requisitos (Ver anexo 11). Desarrollar los módulos diseñados (FrontOffice y BackOffice) mediante Sprints iterativos, hasta verificar Pruebas de Software mediante pruebas de software, que la (Ver Anexo 16). aplicación cumpla con los requisitos exigidos por el cliente. Realizar la implementación del Software. Consultar numeral 2.5 Capacitación del cliente. Manual de usuario Cierre (Ver anexo 17) Fin del proyecto Fin proyecto PRUEBAS DE SOFTWARE La metodología Scrum hace énfasis en que los entregables del producto de software, deben ser evaluados y sometidos a prueba durante su desarrollo y cada vez que el correspondiente sprint termine. Esto se realizó con el fin de verificar si dicho entregable era apto, de tal forma que a lo largo de cada sprint se depuraron progresivamente los errores encontrados hasta llegar al punto de obtener un software maduro y funcional. Este último fue llevado a producción para realizar las 71

72 correspondientes pruebas de rendimiento señaladas en el tercer objetivo propuesto del presente proyecto, con el fin de constatar, verificar y garantizar el apropiado comportamiento del software en su entorno real. Los navegadores web empleados para tal fin se encuentran dentro de los más comunes en el mercado, como lo son: Internet Explorer versión 8 y versión 9, Firefox versión 4 y 5, Opera versión 11.5 y Safari versión 5. Las pruebas realizadas durante cada sprint validaban los casos de prueba planteados, en los cuales se verificaba las diferentes variables de entrada, su adecuado proceso y por ende la salida prevista. Se realizaron múltiples casos de prueba para garantizar que ante cualquier eventualidad que presentara el software, este se comportara de manera apropiada para garantizar al cliente la funcionalidad deseada. En lo correspondiente a las pruebas de rendimiento efectuadas en el entorno de producción, se verifico el tiempo de respuesta de la aplicación a las peticiones http solicitadas, así como la adecuada gestión de concurrencia a usuarios en aras de garantizar alta disponibilidad del servicio. En conclusión los resultados arrojados por las pruebas reportaron un bajo índice de errores, en donde cada vez que se encontraba una inconsistencia, se procedía a corregirlo y ejecutar una nueva prueba hasta alcanzar la funcionalidad requerida. Para consultar las pruebas realizadas ver Anexo PROCESO DE IMPLEMENTACIÓN DEL SOFTWARE Previo al proceso de implementación se recomienda disponer de aquellas adquisiciones mencionadas en el anexo 4, puesto que son indispensables para la 72

73 satisfacer los requisitos de Hardware y Software necesarios para un funcionamiento adecuado de la Aplicación Web. El proceso de implementación de Merkonsola consta de los siguientes pasos: Tabla: 09 Implementación del software Paso Descripción 1 Conocer la dirección IP pública estática asignada por proveedor de servicios de internet (ISP). 2 Abrir puerto 80 TCP en el firewall del equipo servidor, para permitir la salida de paquetes hacia internet. Realizar la configuración NAT, para enmascarar la dirección IP y 3 puerto 80 asignados al servidor web en la LAN, a la dirección IP estática publica proporcionada por el ISP, para acceder al servidor que contiene la aplicación desde internet. 4 Desplegar los archivos.war del BackOffice y FrontOffice en el Gestor de Aplicaciones Web de Apache Tomcat. Crear la base de datos de Merkonsola, para ello se debe en 5 primera instancia crear la base de datos desde la consola psql to postgres y enseguida ejecutar el script correspondiente para crear los objetos sobre los cuales se soporta la aplicación. 6 Inicializar los módulos FrontOffice y BackOffice en el Gestor de Aplicaciones Web de Apache Tomcat. Los anteriores pasos brindan un marco global para la instalación y publicación en internet de Merkonsola, pero se recomienda ver el anexo 18 acerca del manual técnico de instalación, que contiene en detalle los pasos necesarios para su instalación satisfactoria. 73

74 2.6. DESCRIPCIÓN DEL PRODUCTO DE SOFTWARE El desarrollo del software se soporta en J2EE, por lo tanto se usaron algunos de los módulos propios que brinda dicho framework junto con aquellos que fueron propiamente desarrollados en conjunto por el equipo de trabajo, para satisfacer los requisitos propios del cliente y del modelo de negocio. La siguiente tabla 07 muestra los módulos y submódulos desarrollados: Tabla: 10 Módulos y submódulo desarrollados Módulo BackOffice FrontOffice Fuente: Autor Submódulo Gestión Catálogo Gestión Clientes Gestión Pedidos Gestión Pago Gestión Tickets Registro Carrito Compras Catálogo Pago Autentificación y Cuenta de Usuario Merkonsola es un producto orientado a la web, lo cual lo hace portable para funcionar en cualquier plataforma del mercado. Por tanto no necesita ningún tipo de archivo ejecutable para su instalación. De igual forma este software brinda un alto grado de seguridad, ya que desde la misma fase de diseño se garantiza que el acceso a la información se restrinja a los usuarios del Sistema mediante un módulo de autenticación a través usuario y contraseña, acorde con los perfiles y los roles 74

75 establecidos en el mismo para cada tipo de usuario, así como los permisos asignados desde el mismo Sistema Gestor de Base de Datos. Desde el punto de vista gráfico, Merkonsola brinda interfaces graficas sencillas e intuitivas al usuario, que le permitan relacionarse fácilmente con el manejo de las funcionalidades provistas por el software. 75

76 CONCLUSIONES Las siguientes conclusiones surgen a raíz de algunos aspectos fundamentales que a juicio de los autores, es conveniente resaltar respecto al aporte que se pretende brindar con el desarrollo y posterior implementación de Merkonsola. Las TICs 40 como Merkonsola, son cada vez más una necesidad para las PYMES 41 como el Minimercado Andalucía, puesto que son un pilar fundamental en el cual se apoyan y les permite aumentar su productividad, optimizar sus procesos, incrementar sus ganancias, capturar clientes potenciales y expandir su campo de acción al eliminar las barreras geográficas que antes limitaban la oferta de sus servicios a unos pocos clientes. El cambio en el enfoque de empresa jerárquica tradicional, que se basaba en satisfacer las necesidades del cliente interno ha cambiado rotundamente, muestra de ello se hace presente en la implementación de esta nueva estrategia de negocio adoptada por este Minimercado, en donde por medio de la puesta en marcha de esta Aplicación web, se busca orientar todos sus esfuerzos en satisfacer las necesidades de sus clientes externos, siendo estos últimos su principal foco y razón de ser. Para cualquier empresa contemporánea sin importar su magnitud o campo de acción al que pertenezca en la industria, el rubro tecnológico ya no es un lujo sino una indudable necesidad demandada por el mercado mismo, la cual requiere trasladar el negocio a la nube apoyándose en herramientas como Merkonsola, puesto que estas le ofrecen a cualquier empresa, un sin número de oportunidades 40 TICs: Tecnologías de la Información y las Comunicaciones. 41 PYMES: Pequeñas Y Medianas Empresas. 76

77 y ventajas competitivas que aportaran significativamente al crecimiento y expansión del mismo. Merkonsola como alternativa de solución viable a la falta de control, inventario y administración de los pedidos realizados a domicilio, contribuye a la optimización de dicha actividad de forma sistematizada, segura y controlada en favor de mitigar las falencias detectadas y mejorar la calidad del servicio a los usuarios. La implementación de metodologías (PMBOK y Scrum) acordes a las necesidades que demanda este proyecto, se constituyen como base fundamental para crear un plan estratégico que oriente sus esfuerzos de manera convergente a optimizar los recursos, controlar riegos, cumplir los objetivos y satisfacer las necesidades que demanda un contexto como el que afecta al Minimercado Andalucía. Se registró el software ante la Dirección Nacional de Derecho de Autor adscrita al Ministerio del interior y de justicia, con fecha de registro 04- Agosto- 2011, en el libro 13, tomo 29 y partida 433. Se publicó un articulo para el libro: Semilleros: Contando y escribiendo la investigación en ingeniería patrocinado por la facultad de Ingeniería de la Universidad Libre sede Bogotá. A continuación se presenta el desarrollo de los objetivos específicos del proyecto de manera sintética, con el fin de mostrar consistencia en todo el trabajo realizado. El cumplimiento de todos los objetivos específicos, comprueba el cumplimiento del objetivo general. 77

78 Tabla: 11 Cumplimiento Objetivo General OBJETIVO GENERAL CÓMO SE CUMPLIÓ? DÓNDE SE CUMPLIÓ? Implementar una tienda virtual para la solicitud, registro y facturación de pedidos on-line con pago anticipado, en el Minimercado Andalucía empleando software libre. Cumpliendo a cabalidad cada una de las fases de la metodología Scrum, apoyándose con la metodología de gestión de proyectos de PMI, lo cual permitió alcanzar cada uno de los objetivos planteados. A lo largo de todo el proyecto, puesto que en cada una de las fases e iteraciones, se aplicaron las correspondientes metodologías, conocimientos, estándares, patrones y demás herramientas que el proyecto ameritaba para alcanzar el presente objetivo general. Tabla: 12 Cumplimiento Objetivo Especifico 1 OBJETIVO ESPECÍFICO CÓMO SE CUMPLIÓ? DÓNDE SE CUMPLIÓ? Aplicando encuestas y PMI SCRUM Identificar las entrevistas a los necesidades e intereses diferentes actores que Fase I. Fase I. de los clientes y del interactúan con el Inicio del Planeación Minimercado. sistema, con el fin de Proyecto. identificar sus necesidades y requisitos. 78

79 Tabla: 13 Cumplimiento Objetivo Especifico 2 OBJETIVO ESPECÍFICO CÓMO SE CUMPLIÓ? DÓNDE SE CUMPLIÓ? Definiendo la PMI SCRUM Diseñar la arquitectura arquitectura que se del sistema acorde a la ajustara de mejor Fase II. Fase II. interacción de los manera a la eficiente módulos del proyecto y interacción de los Organización Arquitectura en base a las módulos y por ende a y necesidades e intereses la satisfacción de Preparación. anteriormente dichos requisitos mencionados. previamente identificados. Tabla: 14 Cumplimiento Objetivo Especifico 3 OBJETIVO ESPECÍFICO CÓMO SE CUMPLIÓ? DÓNDE SE CUMPLIÓ? Realizando pruebas de PMI SCRUM rendimiento, las cuáles Aplicar pruebas de garantizaron Fase III y Fase III y rendimiento de satisfactoriamente el IV. IV. Software para adecuado determinar el comportamiento y Ejecución Desarrollo funcionamiento y rendimiento de la del trabajo y Cierre. calidad del sistema. aplicación, en términos y Cierre de una alta carga en la demanda del servicio. 79

80 RECOMENDACIONES Las recomendaciones que se plantean a continuación, tienen como objetivo brindar un marco que aporte a la mejora continua del sistema, así como el garantizar una adecuada funcionalidad y uso del mismo. Para evitar imprevistos con el software como la perdida de información, se hace énfasis en la necesidad de leer el manual de usuario (Ver anexo 17) antes de hacer uso del sistema, para familiarizarse en primera instancia con sus funcionalidades y demás características. Para futuras versiones de Merkonsola, es aconsejable desarrollar un módulo adicional al BackOffice y FrontOffice, que se acople a la arquitectura del software y satisfaga demás aspectos técnicos, el cual permita ofrecer una herramienta adicional enfocada a la alta gerencia para la toma de decisiones, que contribuya a mejorar la competitividad, capturar clientes potenciales y finalmente, tomar decisiones gerenciales acertadas frente a las exigencias de un mercado cambiante. Para mejorar la capacidad de respuesta frente a la creciente demanda de recursos generada por el incremento de usuarios concurrentes que hacen uso del software, se recomienda migrar la aplicación a un servidor con mayores prestaciones de hardware, así como el solicitar al proveedor de servicios de internet, un canal de acceso a internet que provea un mayor ancho de banda. 80

81 BIBLIOGRAFÍA BOOCH, G. Rumbaugh, J. The Unified Modeling Language User Guide. Segunda edición CABRERA, G. Montoya, M. Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión CAPOTE, O. Ruiz, N. Rodríguez, J. Carrillo, S.A. Introducción a las Bases de Datos CHAFFEY, D. E-Bussiness and E-Commerce Management. Segunda edición DIAZ, M a. Montero, S. Ingeniería de la Web y Patrones de Diseño DEL BARRIO, L. Del Business al E-Business en Tiempos de Crisis G. W. Hansen. J.V. Hansen. Diseño y Administración de Bases de Datos. Segunda edición GUTIERREZ, A. Comercio Electrónico y Privacidad en Internet JACOBSON, I. Booch, G. Rumbaugh, J. El proceso Unificado de Desarrollo de Software KAREN, D. & Lares, E. Sistemas de Información para los Negocios. Cuarta edición

82 M. PIATINNI. J.A. Calvo. Análisis y Diseño de Aplicaciones Informáticas de Gestión MARTINEZ, A. Comercio Electrónico, Firma Digital y Autoridades de Certificación PRESSMAN, Roger. Ingeniería de Software un Enfoque Práctico. Sexta edición RAYPORT, J. F. & Jaworski, B.J. E-Commerce. Primera edición WEITZENFELD. A. Ingeniería de Software Orientado a Objetos Uml, Java e Internet. Primera edición

83 INFOGRAFÍA APLICACIONES EN CAPAS. Arquitectura en capas. Publicado el 29 de septiembre de Consultado el 10 de Febrero de ARQUITECTURA DEL SERVIDOR APACHE. Descripción de la arquitectura en módulos delo Apache. Explicación y enumeración de las funciones de cada módulo. Publicado el 20 de marzo de Consultado el 10 de Febrero de ARQUITECTURA DE SOFTWARE. Introducción a la arquitectura de software. Publicado en Marzo de Consultado el 15 de octubre de COMERCIO ELECTRÓNICO. Definición de Comercio Electrónico. Consultado el 4 de Agosto de DECRETO Normatividad Comercio electrónico. Publicado 15 de noviembre de Modificado el 14 de abril de Consultado el 20 de Agosto de DESARROLLO ÁGIL DE SOFTWARE. Consultado el 15 de Septiembre de

84 DESARROLLO DE SOFTWARE. Desarrollo de Software Orientado a Objeto usando UML. Consultado el 23 de septiembre de tro.pdf ESTÁNDARES ISO. Consultado el 4 de Noviembre de IEEE 830. Especificaciones de los Requisitos del Software. Publicado en Consultado el 5 de septiembre de JSP. Definición de JSP. Publicado el 12 de Febrero de Consultado el 23 de Agosto de GNU. La definición de software libre. Consultado el 23 de septiembre de LA INVESTIGACIÓN APLICADA A LA INGENIERIA. Consultado el 5 de Abril de /clasificacion.html LENGUAJE UNIFICADO DE MODELADO. Consultado el 4 de junio de

85 MODELO DE NEGOCIO. Modelo de Negocio: El eslabón perdido en la dirección estratégica. Consultado el 25 de Septiembre de MODELO VISTA CONTROLADOR. Consultado el 4 de Julio de html QUÉ ES LA INGENÍERIA WEB? Consultado el 4 de Junio de SCRUM. Como gestionar proyectos con Scrum. Consultado 4 de Julio de SCRUM. The Scrum Guide. Consultado 4 de Julio de SCRUM. Scrum es un grupo de herramientas de gestión. Consultado 4 de Julio de SCRUM. Aplicando Scrum. Modificado Jueves 24 de junio de Consultado el 23 de Octubre de WEB ENGINERING. Community Portal Consultado el 4 de Junio de

86 ANEXOS 86

87 ANEXO 1. DISEÑO METODOLOGICO La encuesta fue realizada a los clientes del Minimercado Andalucía, con el fin de recolectar información para la implementación de un aplicativo web para la solicitud de pedidos a domicilio en el mismo. Esta encuesta fue realizada a 140 personas que habitualmente realizan sus compras allí en el mes de septiembre del FORMATO DE LA ENCUESTA REALIZADA. Figura: 12 Encuesta MERKONSOLA Fuente: autores 87

88 2. ANÁLISIS DE LA ENCUESTA En esta parte se muestra los resultados obtenidos y las conclusiones obtenidas de la encuesta realizada. Pregunta Uno Está satisfecho (a) con la actual forma de realizar sus pedidos a domicilio? Frecuencia Absoluta Frecuencia Relativa Si 7 Si 5% No 133 No 95% Total 140 Total 100% Figura: 13 Pregunta Uno Análisis: Los resultados arrojados en esta pregunta, coinciden claramente con lo expuesto en la justificación del proyecto. Es decir, que los clientes no están satisfechos con 88

89 la actual forma de realizar sus pedidos a domicilio debido a algunas situaciones específicas las cuales son preguntadas en posteriores preguntas de la presente encuesta. Pregunta Dos Cuando realiza sus compras presenciales, Qué es lo que más le molesta de esta actividad? Frecuencia Absoluta Frecuencia Relativa Largas filas 36 Largas filas 26% La inseguridad 37 La inseguridad 26% La demora 63 La demora 45% Otra 4 Otra 3% Total 140 Total 100% Figura: 14 Pregunta Dos 89

90 Análisis: Acorde con los resultados obtenidos para la presente pregunta, se observa que la demora es la principal molestia de los clientes a la hora de realizar sus compras, pero además de ello se concluye que existen otras dos fuertes tendencias como lo son: la inseguridad y las largas filas. Pregunta Tres De las siguientes actividades, Cuáles deja de realizar por hacer sus compras presenciales? Frecuencia Absoluta Frecuencia Relativa Cuidado del Cuidado del hogar 36 hogar 26% Pagar servicios 58 Pagar servicios 41% El trabajo 31 El trabajo 22% Otra 15 Otra 11% Total 140 Total 100% Figura: 15 Pregunta Tres 90

91 Análisis: De los resultados obtenidos en esta pregunta, se concluye que la actividad que más dejan de realizar los usuarios por hacer las compras presenciales es sin duda: Pagar los servicios, situación que estaba contemplada dentro de lo presupuestado. De igual manera sucede con actividades como: cuidado del hogar y el trabajo, los cuales presentan un alto porcentaje. Pregunta Cuatro Cuándo usted realiza un pedido a domicilio, recibe los productos que solicito? Frecuencia Absoluta Frecuencia Relativa Si 34 Si 24% No 106 No 76% Total 140 Total 100% Figura: 16 Pregunta Cuatro 91

92 Análisis: La respuesta más predomínate para este caso: NO, es una clara muestra que sirve de argumento para demostrar la inconformidad por parte de la mayoría de clientes a la hora de recibir productos no solicitados por los mismos. Pregunta Cinco En caso de que haya contestado No, en la anterior pregunta: Con que frecuencia tiene problemas al recibir productos no solicitados por usted en el domicilio? Frecuencia Absoluta Frecuencia Relativa Siempre 35 Siempre 25% Ocasionalmente 71 Ocasionalmente 51% Nunca 34 Nunca 24% Total 140 Total 100% Figura: 17 Pregunta Cinco 92

93 Análisis: En esta pregunta, la mayoría de usuarios respondieron que ocasionalmente presentan problemas al recibir productos. Lo cual indica que se están presentando problemas con dicha situación, en total un 76% de los usuarios encuestados afirman que han tenido algún tipo de inconveniente ya sea con menor o mayor frecuencia. Lo que apoya aún más la necesidad de una alternativa de solución para contribuir a la mejorar en esta problemática. Pregunta Seis Con que frecuencia se encuentra ocupada la línea telefónica cuando usted va a solicitar un pedido a domicilio vía telefónica? Frecuencia Absoluta Frecuencia Relativa Siempre 34 Siempre 24% Ocasionalmente 92 Ocasionalmente 66% Nunca 14 Nunca 10% Total 140 Total 100% Figura: 18 Pregunta Seis 93

94 Análisis: La mayoría de usuarios respondieron que ocasionalmente se encuentra ocupada la línea telefónica cuando va a solicitar un pedido a domicilio vía telefónica. Lo cual indica que un 90% de los usuarios encuestados afirman que han tenido algún tipo de inconveniente ya sea con menor o mayor frecuencia. Lo cual reafirma una vez más lo expuesto en la justificación, respecto a la gran incomodidad que genera al llamar al Minimercado y encontrar el servicio ocupado. Pregunta Siete Le gustaría realizar sus compras desde su casa por Internet? Frecuencia Absoluta Frecuencia Relativa Si 130 Si 93% No 10 No 7% Total 140 Total 100% Figura: 19 Pregunta Siete 94

95 Análisis: Los resultados obtenidos con un 93% de personas que afirman comprarían por internet, permite establecer que el desarrollo e implantación de la Aplicación Web podría llegar a tener acogida y por ende ser utilizado por los clientes, como alternativa a los problemas encontrados en las anteriores preguntas. Pregunta Ocho Cuenta usted con algún tipo de tarjeta débito o crédito? Frecuencia Absoluta Frecuencia Relativa Si 15 Si 11% No 125 No 89% Total 140 Total 100% Figura: 20 Pregunta Ocho Cuenta usted con algún tipo de tarjeta débito o crédito? 11% Si No 89% Fuente: autores 95

96 Análisis: El 89% de los encuestados aseguran que no tienen tarjeta débito o crédito, siendo uno de los ítems más importantes para el proyecto. Puesto que al comprobar que dicho porcentaje es mayoritario, demuestra que el pago anticipado y contra entrega es viable alternativa que favorecería a la adquisición de productos vía Internet, descartando de manera definitiva la implementación de algún tipo de pago con tarjeta de débito o crédito. Pregunta Nueve Cree usted que hace falta un sistema alternativo que facilite realizar pedidos de productos a domicilio? Frecuencia Absoluta Frecuencia Relativa Si 130 Si 93% No 10 No 7% Total 140 Total 100% Figura: 21 Pregunta Nueve 96

97 Análisis: Un 93% de aceptación por parte de los clientes, permite establecer que los usuarios opinan que hace falta un sistema que facilite realizar pedidos de productos a domicilio, concluyendo de esta manera, que es posible la implantación de una Aplicación Web como la propuesta en el proyecto de grado que contribuya a mejorar las inconformidades anteriormente encontradas. 97

98 ANEXO. 2 ACTA DE COSTITUCIÓN DEL PROYECTO 1. INTRODUCCIÓN La masificación de Internet sin duda alguna, ha contribuido a que todos los sectores de la industria, comercio y la misma sociedad, tengan un sin número de posibilidades tanto para el desarrollo creciente de negocios como para la diversión, acceso a la información, comunicación y entretenimiento a través de este medio. Uno de los actores mencionados: El comercio, no ha sido ajeno a este salto tecnológico, puesto que esta red mundial de información le ha permitido eliminar las barreras geográficas, ofrecer productos y servicios a una mayor cantidad de clientes potenciales alrededor del globo e incluso la facilidad de buscar y comprar en el momento deseado. Muestra clara de ello son las tiendas virtuales (asociadas al enfoque B2C), cuyo surgimiento se ha difundido de forma exponencial en Internet gracias a las características anteriormente mencionadas. En el contexto especifico con el que se enfrenta este proyecto, se hace mención que la venta de pedidos a domicilio vía telefónica en el Minimercado Andalucía, es una alternativa que le permitió inicialmente expandir su campo de acción y prestar sus servicios a un número mayor de clientes permisibles, favoreciendo el incremento en sus ingresos económicos. A pesar de esta situación, dicho servicio presentaba algunos inconvenientes, que comprometían seriamente la prestación y continuidad del mismo. Esta situación se ha reflejaba en la paulatina pérdida de clientes, y por ende en la disminución de ingresos a causa de algunas deficiencias que afectan la calidad en la prestación del servicio, las cuales causaron continuas molestias a sus clientes. En aras de mejorar las falencias detectadas en la prestación de dicho servicio, se pretende mediante el desarrollo del presente proyecto de grado brindar una 98

99 alternativa viable que contribuya a mejorar dichas deficiencias identificadas en aquel servicio ofertado en esta tienda de barrio. Por ello teniendo en cuenta la gran versatilidad y características favorables que una tienda virtual provee a muchos negocios a nivel mundial, se opta por desarrollar la presente aplicación web con herramientas de software libre y metodologías reconocidas, en aras de aplicar el conocimiento ingenieril a la problemática hallada en dicho contexto, teniendo en cuenta el carácter comunitario para dicho sector de la población, los beneficios propios para el Minimercado e incluso un bajo costo de implementación que facilite su puesta en marcha y funcionamiento continuo. La iniciativa de este proyecto, surge de las necesidades de los líderes del proyecto de llevar a cabo su trabajo de grado para optar por el título de Ingenieros de Sistemas de la Universidad Libre de Colombia. Después de buscar la opción que más se ajustara a los intereses, conocimientos y a una iniciativa de carácter social para brindarle una solución ingenieril. 2. JUSTIFICACIÓN DEL PROYECTO La concepción, estudio y desarrollo del Merkonsola, se enmarca dentro de 3 puntos de vista claramente definidos que serán abordadas en detalle a continuación: Desde el punto de vista social, la tienda virtual proporcionara un servicio a la comunidad en general que le ayude en sus necesidades mercantiles, brindando una solución viable frente a las deficiencias e inconvenientes que presenta el servicio actualmente. 99

100 En lo respectivo a los beneficios que esta alternativa de solución favorecería desde el punto de vista de la organización (mini mercado) se encuentran: Un mejoramiento en sus procesos de facturación y registro de pedidos a domicilio, ya que la Aplicación contribuirá a transformar la antigua forma de realizar estas actividades de manera manual (Lápiz y papel), desorganizada e ineficiente; por una manera sistematizada, organizada y segura, que servirá de apoyo al Administrador del Mini mercado para que pueda tomar decisiones acertadas que le permitan ofrecer un mejor servicio a sus clientes y obtener un mejor provecho y rentabilidad del negocio. Otra ventaja sustancial, radica en que la Aplicación permitirá al mini mercado incrementar su campo de acción, oportunidades de negocio, ventas, promociones y ofertas a sus clientes, gracias a las múltiples ventajas que brinda una tecnología de la información como lo es internet. Una vez mencionados los dos anteriores enfoques es relevante resaltar el punto de vista del cliente, ya que es un actor ampliamente beneficiado en este proyecto puesto que: La Aplicación será un medio que contribuya a mejorar las incomodidades en lo referente al registro erróneo del pedido telefónicamente, dado que al realizar dicha acción ya no se necesitara de un intermediario (empleado) que pueda equivocarse en esta actividad, por el contrario la Aplicación es la única que interactúa con el cliente disminuyendo el riesgo de errar cuando se haga el pedido. Vale la pena resaltar que el Aplicativo igualmente permitirá que se subsanen las molestias presentadas cuando se llama al teléfono de mini mercado y este se encuentra ocupado debido a la alta concurrencia de llamadas. 100

101 Es de vital importancia resaltar el hecho de que Aplicativos de Software orientados a la Web como: Merkonsola, beneficien al cliente puesto el no necesita desplazarse al mini mercado, por el contrario es este último quien se dirige y le brinda sus servicios a través de la Web. Cooperando de esta manera a facilitar la compra del mercado para los usuarios con un tiempo limitado a la hora de realizar esta labor, como para aquellos que buscan desde su ubicación una nueva opción para evadir la larga y demorada espera en la caja, la congestión y la misma inseguridad que genera el desplazarse a la hora de comprar (robo).las Madres cabeza de Familia son igualmente beneficiadas, puesto que gracias a Merkonsola pueden invertir el tiempo dedicado al mercar, en otros labores ya sean domesticas (aseo del hogar) o labores propias de su condición de madres como por ejemplo el cuidado de los hijos. Por último, hay otros factores que avalan, apoyan y sirven de punto de referencia para la evocación y justificación de esta alternativa de solución. En efecto se pueden mencionar: un mejor control de gastos para el cliente, el no desplazamiento físico al Mini mercado, e incluso no cargar el mercado. En donde estos dos últimos juegan un papel crucial en personas de la tercera edad y mujeres embarazadas OBJETIVO DEL NEGOCIO Implementar una tienda virtual para la solicitud, registro y facturación de pedidos on-line con pago anticipado, empleando software libre en el Minimercado Andalucía Identificar las necesidades e intereses de los clientes y del Minimercado. 101

102 Diseñar la arquitectura del sistema acorde a la interacción de los módulos del proyecto y con base en las necesidades e intereses identificados. Aplicar pruebas de rendimiento de Software para determinar el funcionamiento y calidad del servicio. 3. DESCRIPCIÓN DEL PROYECTO Las necesidades del negocio se en marca en el buscar, clarificar y establecer, aquellos aportes y beneficios que obtendrá la organización con la puesta en marcha y posterior implementación del proyecto una vez culminado y puesto en producción. En este orden de ideas, a continuación se mencionaran cada uno de ellos: o Optimización en los procesos de control, inventario y administración de los pedidos realizados, el cual permita al Minimercado efectuar dicha actividad de forma organizada, segura y controlada. o Mejora en la actual insatisfacción de los clientes, debido al registro y recepción erróneo del pedido con productos no solicitados por este último, dado que esta labor ya no la realizara un empleado si no el Aplicativo web. o Incremento en la fidelización de Clientes, puesto que contribuirá a optimizar aquellos puntos neurálgicos como: línea telefónica ocupada a la hora de realizar un pedido, largas esperas en las filas para pagar el mercado, desplazamiento físico, etc. Que en algunas ocasiones son causantes de la pedida de clientes y repercutiendo de forma directa en la economía de la organización. 102

103 o Se contribuirá a mejorar aquella incomodidad de la línea telefónica cuando se realiza un pedido y esta se encuentra ocupada, es decir un más eficiente manejo de la concurrencia de transacciones generadas por la alta solicitud de pedidos. o Una mayor oportunidad y competitividad del negocio, puesto que la aplicación servirá a la organización, como herramienta para expandir las oportunidades de negocio sacando el máximo provecho a las múltiples ventajas que ofrece internet, obteniendo como beneficios potenciales clientes y una mejor rentabilidad OBJETIVOS DEL PROYECTO Y CRITERIOS DE ÉXITO Los objetivos que se apoyan mutuamente los hitos y los resultados de este proyecto han sido identificados. Con el fin de lograr el éxito en el proyecto de MERKONSOLA, los siguientes objetivos deben estar garantizados en el tiempo designado y las asignaciones determinadas: Identificar factores clave de éxito y depurar al máximo las necesidades finales del cliente partiendo de la formulación del problema. Elaborar modelos y propuestas de solución en dónde se integren la fundamentación teórica del producto final de software y la investigación aplicada. Completar el levantamiento de información de hardware y software requerido. 103

104 Desarrollar el producto final de software aplicando la metodología de desarrollo de desarrollo y cumpliendo con el modelo del negocio propuesto. Aplicar la solución (implementar el software) en el Minimercado Andalucía. Realizar pruebas y entrega de la documentación final del proyecto basándose en los resultados obtenidos orientados al cumplimiento de los objetivos del proyecto REQUERIMIENTOS Este proyecto debe contar con la siguiente lista de requerimientos con el propósito de garantizar el éxito. El levantamiento de información debe realizarse a través de una o varias metodologías de desarrollo de software. Los requisitos del sistema, deben estar documentados en forma explícita y entendible. El software debe optar por desarrollarse bajo una metodología ágil de desarrollo, orientándose más a los resultados que a los procedimientos. Debe optarse por la implementación de herramientas de software de prueba o licencias comunitarias. Las pruebas de software deben estar cobijadas por un modelo de madurez, para que así el ciclo de vida del proyecto como del producto y sus resultados finales, estén bajo estándares. 104

105 La documentación final del proyecto, debe ajustarse al cumplimiento de las metodologías y modelos, incluyendo los resultados y procesos más relevantes del ciclo de vida. El cumplimiento de las tareas, debe ajustarse a los tiempos de entrega y finalización de cada frase. El ciclo de vida del producto, en especial en su fase de desarrollo, debe diferenciarse entre un contexto de desarrollo (Codificación y prueba). Los stakeholders deben tener conocimiento del estado del proyecto secuencial, para reducir la brecha entre el desarrollo y la retroalimentación y así poder realizar ajustes o modificaciones a tiempo LÍMITES Los siguientes límites se contemplaran en el proyecto MERKONSOLA: Por el hecho de optarse por herramientas de software libre, estas deben garantizar un amplio espectro de portabilidad para facilitar el desarrollo en diferentes lugares. Deben existir copias de seguridad en 1 o más equipos diferentes a los del desarrollo para asegurar la existencia y pertenencia de la información. 3.4 SUPUESTOS La siguiente es una lista de supuestos sobre el acuerdo y la firma de este documento, todas las partes reconocen que estas son verdaderas: 105

106 El proyecto MERKONSOLA es un proyecto sin ánimo de lucro, con carácter social. Los patrocinadores del proyecto, a la par, desempeñaran roles a nivel ejecutivo y técnico. Este proyecto cuenta con el pleno apoyo de todos los involucrados desde el inicio hasta el cierre. Los objetivos del proyecto, deben buscar satisfacerse en su totalidad acorde con las expectativas de cada uno de los involucrados. El director del proyecto, será una guía, ayudando a dar consistencia al proyecto. 3.5 OPORTUNIDADES DE NEGOCIO QUE JUSTIFIQUEN EL PROYECTO, INCLUIDO EL RETORNO SOBRE INVERSIÓN. Las oportunidades de negocio buscan establecer aquellos beneficios los cuales recibirá la organización una vez este se encuentre culminado, además debe tener en cuenta el retorno sobre inversión que dicha situación pertinente. Por lo tanto dichos beneficios consisten en: o Una mayor oportunidad y competitividad del negocio, puesto que la aplicación servirá a la organización, como herramienta para expandir las oportunidades de negocio que permitan mejorar la rentabilidad y generar un retorno sobre inversión. 106

107 o Facilitar la captura de potenciales clientes, puesto que el aplicativo permitirá llegar a una mayor cantidad de personas, incrementando las posibilidades de ofertar al cliente gran variedad de productos y servicios. o Mayor reconocimiento a nivel local, nacional e internacional, lo cual aportara una mejor imagen y Good Wheel, lo cual abrirá muchas oportunidades para establecer relaciones de orden estratégico-comercial que beneficien al negocio. o Como se mencionó en anteriores apartados la fidelización de los clientes, con el objetivo mantener y conservar una base de ellos ofreciéndoles productos o servicios de su interés, e intentar atraer a muchos más para expandir el campo de acción y por ende la rentabilidad del negocio. 4. RIESGOS Los siguientes riesgos para el proyecto MERKONSOLA se han identificado. Interrupción potencial de las operaciones durante el despliegue de la solución. Poca factibilidad para establecer reuniones entre los involucrados del proyecto. Romper los paradigmas que destacan a las metodologías tradicionales de desarrollo, sobre metodologías de desarrollo ágil. 5. ENTREGABLES DEL PROYECTO Al finalizar el proyecto MERKONSOLA, debe dar como resultado las siguientes características: 107

108 Software totalmente funcional que pueda ser accesado desde la nube. Aprobación del cliente basado en los estándares de calidad. Documentación de todo ciclo de vida del proyecto y del producto. Manuales de usuario. En la siguiente tabla se resume el cronograma de hitos: Tabla: 15 Resumen del cronograma de hitos Resumen del cronograma de hitos Lista de hitos claves del proyecto en relación con el inicio del proyecto. Hitos del proyecto Fecha objetivo Inicio del proyecto 14/05/2010 Levantar información 11/06/2010 Diseñar planes de gestión 06/07/2010 Elaborar modelos y propuestas 03/08/2010 Desarrollar el producto de Software 09/12/2011 Realizar pruebas de Software y 25/03/2011 correcciones Implementar el producto desarrollado 21/04/2011 Entrega final del proyecto 24/06/ RESUMEN DEL PRESUPUESTO Por ser un proyecto sin ánimo de lucro, el proyecto MERKONSOLA no se ha estimado o acordado que existirá alguna ganancia o utilidad. 108

109 Al ser una oportunidad que brinda el Minimercado de desarrollar un proyecto de grado, los ejecutores del proyecto, siempre optaran por buscar las herramientas y recursos que no implican costos. Los patrocinadores del proyecto y los ejecutores son la misma persona, el presupuesto corre por cuenta de los ejecutores se describe a continuación: Tabla: 16 Presupuesto Lista de componentes de los costos del presupuesto Componentes del proyecto Costo Impresión de documentos y papelería $ Transportes (para las reuniones con el cliente) $ Impresora Térmica $ Horas de trabajo fase de Inicio $ Horas de trabajo fase de Planeación $ Horas de trabajo fase de Ejecución $ Horas de trabajo fase de Control $ Horas de trabajo fase de Cierre $ Total $ REQUERIMIENTOS DE APROBACIÓN DEL PROYECTO El éxito del proyecto MERKONSOLA, se lograra una vez que la implementación del producto final de software evidencie que los clientes del Minimercado Andalucía han mejorado sus experiencias al realizar sus pedidos a domicilios. 8. DIRECTOR DEL PROYECTO Merkonsola ha contado con dos directores del proyecto: 109

110 El primero como se sugirió al ingeniero Beitmantt Geovanni Cárdenas Quintero en la propuesta del proyecto de grado de ser el director del proyecto de grado titulado MERKONSOLA: TIENDA VIRTUAL PARA LA SOLICITUD DE PEDIDOS ON-LINE CON PAGO ANTICIPADO y como fue aprobado por el comité de Currículo en su sesión N 13 del 31 de mayo del El segundo director de proyecto reasignado es el ingeniero Fabián Blanco Garrido en la propuesta del proyecto de grado de ser el director del proyecto de grado titulado MERKONSOLA: TIENDA VIRTUAL PARA LA SOLICITUD DE PEDIDOS ON-LINE CON PAGO ANTICIPADO y como fue aprobado por el comité de Currículo en su sesión N 01 del 25 de enero del Se reafirma de igual forma en este documento, como director oficial del proyecto MERKONSOLA. 110

111 AUTORIZACIÓN Aprobado por los patrocinadores y director del proyecto: Lucy Paola Martínez Pérez Estudiante Ingeniería de Sistemas Patrocinador Eibin Fabián Acosta Agudelo Estudiante Ingeniería de Sistemas Patrocinador Fabián Blanco Garrido Ingeniero de Sistemas Director del proyecto 111

112 ANEXO 3. WORK BREAKDOWN STRUCTURE (WBS) 1. INTRODUCCIÓN La estructura de descomposición de trabajo que aquí se presenta personaliza todo el trabajo necesario para completar este proyecto. 2. ESTRUCTURA JERÁRQUICA Tabla: 17 Estructura jerárquica MERKONSOLA Nivel Código WBS Nombre del elemento 1 1. MERKONSOLA Inicio Elaborar propuesta Identificar metodología de investigación Identificar el problema Identificar objetivos Justificar el proyecto Fundamentar teóricamente Efectuar correcciones Elaborar anteproyecto Profundizar teóricamente Definir tiempos Investigar metodologías Investigar herramientas de software Identificar Stakeholders Recopilar datos básicos Levantar información 112

113 Elaborar WBS Planeación Elaborar plan de comunicaciones Asignar roles a Stakeholders Definir actividades del equipo Elaborar plan de riesgos Identificar los riesgos Formular contingencias Elaborar plan de adquisiciones Listar recursos y servicios Seleccionar proveedores Elaborar cronograma de actividades Definir fechas de entrega Definir actividades Elaborar Requerimientos del proyecto (product backblog) Ejecución Diseñar Estructura Funcionalidad Componentes Definir arquitectura Definir modelo de negocio Definir modelo de datos Definir modelo de presentación Ajustar modelo MVC Diseñar wireframes 113

114 Modelar unidades de función UML Adquirir recursos y servicios Desarrollar el software Ajustar product backblog Revisar secuencialmente Retroalimentar requisitos Formular ajustes Discutir y aprobar ajustes Control Revisar los avances Reuniones frecuentes con el cliente Controlar costos Ajustar actividades al cronograma Efectuar el Scrum diario Refinar el product backblog Finalizar cada Sprint Cierre Realizar pruebas de software Analizar resultados Documentar Hacer recomendaciones Liberar versión final 114

115 3. VISTA DE ESTRUCTURA EN ÁRBOL Figura: 22 Vista de estructura en árbol WBS 115

116 4. DICCIONARIO WBS Tabla: 18 Diccionario WBS Nivel Código WBS Nombre del elemento Definición Tienda Virtual para la 1 1. MERKONSOLA solicitud de pedido online con pago anticipado Inicio Inicio del proyecto Elaborar propuesta Sugerencia de proyecto a trabajar Identificar metodología de investigación Para tener claridad en un ámbito investigativo Identificar el problema Abstraer la necesidad Identificar objetivos Orientar a resultados Justificar el proyecto Argumentar la razón de ser del proyecto Fundamentar teóricamente Argumentar desde diferentes fuentes de información Efectuar correcciones Retroalimentar Elaborar anteproyecto Propuesta más seria y consistente Profundizar teóricamente Consolidar argumentos teóricos Definir tiempos Estimar fechas de inicio y finalización de actividades Investigar metodologías De desarrollo y de 116

117 software Investigar herramientas de software Para documentación, modelado y desarrollo Identificar Stakeholders Definir todos los posibles involucrados en el proyecto Recopilar datos básicos Identificar variables Levantar información Del entorno del problema y los Stakeholders Elaborar WBS Identificar fases, actividades y procesos Planeación Planeación del proyecto Elaborar plan de comunicaciones Establece los parámetros de comunicación Asignar roles a Stakeholders Los diferentes papeles que desempeñaran Definir actividades del equipo Establece compromisos y responsabilidades Elaborar plan de riesgos Contemplar factores negativos Identificar los riesgos Identifica posibles amenazas Formular contingencias Cursos de acción alternativos Elaborar plan de adquisiciones Definir plan de acción para adquirir artículos o servicios Artículos y servicios 117

118 Listar recursos y servicios necesarios para el proyecto Seleccionar proveedores Tanto de artículos como de servicio Elaborar cronograma de actividades Definir actividades con respecto al tiempo Definir fechas de entrega De avances o informes Definir actividades A desarrollar durante el proyecto para el proyecto Elaborar Requerimientos del proyecto (product backblog) Características con las que debe contar el sw Ejecución Ejecución del proyecto Diseñar Análisis y diseño del sistema Estructura Componentes del sw Funcionalidad Lógica del sw Componentes Partes que integran el sw Definir arquitectura Modelo orientado a la web Definir modelo de negocio Módulos del sw Definir modelo de datos Modelo de la base de datos Definir modelo de presentación Interfaces de presentación de los datos Ajustar modelo MVC Consolidación de la arquitectura en un framework Diseñar wireframes Diseño de las interfaces 118

119 Modelar unidades de función UML Diagramas de navegación, secuencia, entre otros Adquirir recursos y servicios Obtener el hw y el sw necesario Desarrollar el software Instalar aplicativos y configurar servicios Ajustar product backblog Desarrollar acorde a los requisitos Revisar secuencialmente Contemplar los avances y su eficiencia Retroalimentar requisitos Reevaluar los requisitos Formular ajustes Etapa orientada a satisfacer la retroalimentación Discutir y aprobar ajustes Aprobar nuevos diseños Control Control del proyecto Revisar los avances Entre los stakeholders Reuniones frecuentes con el cliente Para aprobar entregas de iteraciones como funcionales Controlar costos Ajustarse al presupuesto Ajustar actividades al cronograma Actividades cumplidas dentro de los plazos Efectuar el Scrum diario Seguir metodología, fortalece la comunicación Refinar el product backblog Mejoras potenciales en cada interación nueva 119

120 Finalizar cada Sprint Cerrar cada iteración para concentrarse en una nueva Cierre Cierre del proyecto Realizar pruebas de software Que cumplan con el plan de gestión de calidad Analizar resultados Verificar si se cumplieron los objetivos Documentar Presentar por escrito todos los pormenores del proyecto Hacer recomendaciones Presentar futuras iteraciones o proyectos relacionados Liberar versión final Firmar el documento de aceptación del proyecto 5. GLOSARIO DE TÉRMINOS WBS Arquitectura Diseño conceptual y estructura operacional fundamental de un sistema. Framework Marco de la arquitectura MERKONSOLA. MVC Modelo Vista Controlador. 120

121 Product Backlog Cartera de requisitos. Stakeholders Involucrados en el proyecto. Sprint Iteración. Requisitos Condición necesaria para resolver un problema. UML Modelo de lenguaje unificado. (Unified Modeling Language) 121

122 ANEXO 4. INTEGRACIÓN DE LAS METODOLOGÍAS La tabla 19 permite identificar la integración, según el tipo de investigación, PMI, Scrum, UML, utilizados para cumplir a cabalidad con cada una de las fases de desarrollo del proyecto. Tabla 19. Integración de Metodologías MERKONSOLA Metodología de Investigación Metodología de Desarrollo del Software Gestión del Proyecto Tipo Ingeniería PMBOK Investigación Requisitos SCRUM UML Cuantitativa Levantamiento Inicio Ingenieril Tecnológica de información Product Backlog Casos Uso Organización y Preparación Realización Encuestas Documento IEEE830 Planeación Diagramas Secuencia Ejecución Realización Entrevistas Arquitectura de Software Diagramas Actividades Hipótesis Reuniones Desarrollo Diagramas Actividades Cierre Cierre etc

123 ANEXO 5. PLAN DE GESTIÓN DE HORARIOS 1. INTRODUCCIÓN El cronograma del proyecto es la hoja de ruta sobre cómo será ejecutado. Los horarios son una parte importante en cualquier proyecto, ya que proporcionan al equipo, el patrocinador, y las partes interesadas una imagen del estado de el en un momento dado. El propósito del plan de gestión del cronograma es definir el enfoque del equipo de proyecto que se utilizará en la creación de la programación del proyecto. Este plan incluye cómo el equipo va a supervisar el programa del proyecto y gestionar los cambios después de que el programa base ha sido aprobado. Esto incluye identificar, analizar, documentar, priorizar, aprobar o rechazar, y la publicación de todos los cambios relacionados con la programación. 2. ENFOQUE DE LA ADMINISTRACIÓN DEL CRONOGRAMA El cronograma del proyecto se creará utilizando Microsoft Proyect 2010 comenzando con los entregables señalados en la WBS. La definición de las actividades se identifica en los paquetes de trabajo específicos que se deben realizar para completar cada entregable. La secuencia de las actividades se utilizará para calcular el proyecto. La estimación de la duración de las actividades se utilizará para asignar recursos a paquetes de trabajo a fin de completar el desarrollo del programa. Una vez que el programa preliminar se ha desarrollado, será revisado por el equipo de proyecto y los recursos asignados provisionalmente de las actividades del proyecto. El equipo de proyecto y los recursos deben estar de acuerdo a las asignaciones de los paquetes de propuestas de trabajo, duración y horario. Una vez logrado esto los promotores del proyecto revisarán y aprobarán el programa. 123

124 A continuación se designan como hitos de la programación del proyecto MERKONSOLA: Inicio del proyecto Completar la identificación de las necesidades Elaborar modelos y propuestas Completar el levantamiento de información y de Software y Hardware Desarrollar el producto de Software Implementar el producto desarrollado Realizar pruebas de Software y correcciones Entrega final del proyecto Los roles y responsabilidades para el desarrollo del programa son los siguientes: El director del proyecto será responsable de facilitar la definición de paquete de trabajo, la secuencia y la estimación de la duración y recursos del equipo del proyecto. El equipo del proyecto tiene la responsabilidad de participar en la definición del paquete de trabajo, la secuencia, la duración y estimación de recursos. 124

125 El equipo de proyecto también revisa y valida el calendario propuesto y realiza las actividades asignadas una vez que el programa está aprobado. 3. CONTROL DEL CRONOGRAMA El cronograma del proyecto se revisará y actualizará cuando sea necesario. Los porcentajes de terminación que serán proporcionados por los propietarios de la tarea. El director del proyecto es responsable de programar actualizaciones para el final de cada sprint y exámenes, para determinar los impactos de las variaciones de horario; efectuar cambios de horario y calendario de informes de estado de conformidad con el plan de comunicaciones del proyecto. El equipo del proyecto es responsable de participar al final de cada Sprint y programar actualizaciones, revisiones; comunicar cualquier modificación de inicio efectivo de meta del director de proyecto, y la participación en las actividades del cronograma de resolución de varianza según sea necesario. Los promotores del proyecto deberán mantener la conciencia de la situación del cronograma del proyecto y la revisión, aprobación de las solicitudes de cambio calendario presentado por el director de proyecto. 4. CAMBIOS DE HORARIOS Si cualquier miembro del equipo del proyecto determina que un cambio en el calendario es necesario, el director de proyecto y el equipo se reunirá para revisar y evaluar el cambio. El director y el equipo de proyecto deben determinar que tareas se verán afectadas, la variación potencial y cualquier alternativa o variación de resolución de actividades que puedan recurrir para ver cómo afectan el calendario y los recursos. Una vez que la solicitud de cambio ha sido revisada y aprobada el director de proyecto es responsable de ajustar el calendario y 125

126 comunicar todos los cambios y los impactos en el equipo y promotores del proyecto, y las partes interesadas. 5. ALCANCE DEL CAMBIO Cualquier cambio en el alcance del proyecto, que haya sido aprobado por los promotores del proyecto, será necesario que el equipo evalué el efecto del cambio de ámbito en el calendario actual. Si el director del proyecto determina que el alcance del cambio afecta significativamente la programación del proyecto actual, se puede pedir que el programa vuelva a la línea base en la consideración de las modificaciones que deben hacerse como parte del alcance del proyecto nuevo. Los promotores deben revisar y aprobar la solicitud antes del horario mientras se pueda volver a la línea base. 6. TABLA DE ACTIVIDADES Tabla: 20 Proyección de actividades Actividad Fecha de Fecha de Días hábiles Inicio finalización Inicio del proyecto 10/05/ /05/ Días Levantar información 17/05/ /06/ Días Diseñar planes de gestión 14/06/ /07/ Días Elaborar modelos y 12/07/ /08/ Días propuestas Desarrollar el producto de 04/08/ /12/ Días Software Realizar pruebas de 14/02/ /03/ Días Software y correcciones Implementar el producto desarrollado 02/04/ /04/ Días 126

127 Entrega final del proyecto 06/06/ /06/ Días 7. WBS DE HITOS POR HORA Figura: 23 WBS de hitos por hora 8. DIAGRAMA DE GANTT MERKONSOLA Figura: 24 Diagrama de Grantt 127

128 Figura: 25 Diagrama de Grantt (continuación) 9. ESQUEMA DE INTEGRACIÓN WBS MERKONSOLA Y CRONOGRAMA Tabla: 21 Integración WBS MERKONSOLA y Cronograma Fase de PMI Hitos del cronograma Horas Inicio Inicio del proyecto 187 Levantar información Planeación Diseñar planes de gestión 120 Ejecución Elaborar modelos y propuestas Desarrollar el producto de 476 software Control Realizar pruebas de software y 180 correcciones Cierre Implementar el producto desarrollado 120 Entrega final del proyecto 128

129 9.1 WBS MERKONSOLA POR FASES DE PMI (VISTA DE HORAS Y COSTOS) Figura: 26 WBS MERKONSOLA por fases PMI 9.2 WBS MERKONSOLA POR FASE DE INICIO(VISTA DE HORAS Y COSTOS) Figura: 27 WBS MERKONSOLA Fase de Inicio 129

130 9.3 WBS MERKONSOLA FASE DE PLANEACIÓN (VISTA DE HORAS Y COSTOS) Figura: 28 WBS MERKONSOLA Fase de Planeación 9.4 WBS MERKONSOLA FASE DE EJECUCIÓN(VISTA DE HORAS Y COSTOS) Figura: 29 WBS MERKONSOLA Fase de Ejecución 130

131 9.5 WBS MERKONSOLA FASE DE CONTROL(VISTA DE HORAS Y COSTOS) Figura: 30 WBS MERKONSOLA Fase de Control 9.6 WBS MERKONSOLA FASE DE CIERRE(VISTA DE HORAS Y COSTOS) Figura: 31 WBS MERKONSOLA Fase de Cierre 131

132 10 ANÁLISIS DE COSTOS EN FUNCIÓN DEL TIEMPO Y PRESUPUESTO Sugiriendo una tarifa de $ pesos por hora de trabajo hombre, obtenemos que el costo total del proyecto sea igual a $ pesos, que sumándole $ pesos de otros costos referidos en el Acta de constitución del proyecto, obtenemos que el total de los costos del proyecto sea de $ pesos. 132

133 AUTORIZACIÓN Aprobado por los patrocinadores y director del proyecto: Lucy Paola Martínez Pérez Estudiante Ingeniería de Sistemas Patrocinador Eibin Fabián Acosta Agudelo Estudiante Ingeniería de Sistemas Patrocinador Fabián Blanco Garrido Ingeniero de Sistemas Director del proyecto 133

134 ANEXO 6. PLAN DE GESTIÓN DE RIESGOS 1. INTRODUCCIÓN La gestión de riesgos es uno de los pilares fundamentales que en gran medida contribuye a minimizar el impacto de imprevistos o situaciones fortuitas que pueden comprometer seriamente el normal desarrollo de los proyectos de cualquier orden y envergadura. Por ello el presente plan de riesgos pretende ser una herramienta que aporte al proyecto Merkonsola: la identificación, el control, el monitoreo, la medidas de prevención y la disminución del impacto de los mismos. 2. PRINCIPALES RIESGOS DETECTADOS A continuación se especifican los riesgos de mayor impacto, a juicio de un experto, del director del proyecto y demás integrantes del equipo de desarrollo. Incapacidad o abandono de un integrante del equipo: Dado que ninguno de los integrantes del equipo de trabajo está exento de algún tipo de convalecencia, o bien que este decida por motivos personales o de último momento abandonar el proyecto; es relevante tener una alternativa de solución que permita cubrir las responsabilidades asignadas al recurso humano saliente. Deficiente estimación y planeación de recursos: Sin importar la magnitud del proyecto, de una adecuada estimación y planeación de recursos depende que estos últimos, se encuentren disponibles en el momento adecuado durante el tiempo requerido este así lo amerite. Por ende a pesar de los limitados recursos con los que cuenta este proyecto, se trata de 134

135 compensar dicha falencia con alternativas viables que minimicen costos, como lo es el caso de la implementación de herramientas de software libre. Desfase de cronograma: Sin duda alguna es uno de los principales inconvenientes que se presenta en la gran mayoría de proyectos, debido a que la ocurrencia de otros riesgos incide en el normal cumplimiento de las actividades planteadas en el cronograma. Esta situación se controla en el proyecto Merkonsola mediante el estricto control de aquellos riesgos que a juicio del director del proyecto pueden llegar a afectar de forma tangencial al cronograma. 3. ENFOQUE DE LOS RIESGOS El enfoque dado al plan de gestión de riesgos, se orienta desde un puesto de vista analítico, debido a que se aplica un estricto y detallado análisis prioritario de riesgos acorde al contexto con el cual interactúa Merkonsola, no solo desde su ciclo de vida sino hasta su posterior etapa de implementación y posterior cierre del proyecto. 4. IDENTIFICACIÓN DE RIESGOS Para la correspondiente labor de identificación de riesgos, se utilizaron algunas herramientas recomendadas por el PMI en el capítulo dedicado a la gestión de riesgos del libro PMBOK. 135

136 Herramienta What. If Tabla: 22 Herramienta What If. Qué pasa si? What. If Se legisla una ley que interrumpa el desarrollo del proyecto. Un stakeholder del equipo de desarrollo, abandona el proyecto antes de su presupuestada finalización. Se pierden medios magnéticos con documentación del proyecto. Los requerimientos del Clientes no se satisfacen cuando se entrega el producto al mismo. Se hace una mala planeación del proyecto. No se implementan indicadores a través del proyecto. Riesgo identificado Cancelación total del Proyecto. Retraso en el cronograma actividades del proyecto. Infringir los derechos de autor, al usar información privada. Insatisfacción del cliente, Demandas. Incumplimiento de Actividades, Retraso en el cronograma. No hay medición ni evaluación de los procesos y actividades de cada etapa del proyecto. 136

137 Diagrama de causa y efecto Tabla: 23 Diagrama causa y efecto. Riesgo Causa Efecto Se legisla una ley que interrumpa el desarrollo del proyecto. Un stakeholder del equipo de desarrollo, abandona el proyecto antes de su presupuestada finalización. Se pierden medios magnéticos con documentación del proyecto. Los requerimientos del Clientes no se satisfacen cuando se entrega el producto al mismo. Se hace una mala planeación del proyecto. Determinación del estado. Factores personales. Buscar mejor remuneración económica. Desorden en el almacenamiento de medios magnéticos. Deficiente especificación de los requerimientos. Incorrecta interpretación de las necesidades del Cliente. Personal no capacitado para tal labor. Inadecuada planeación de actividades. Falta de conocimiento Cancelación total del Proyecto. Retraso en el cronograma actividades del proyecto. Infringir los derechos de autor, al usar información privada. Insatisfacción del cliente, Demandas. Incumplimiento de Actividades, Retraso en el cronograma. No hay medición ni 137

138 No se implementan indicadores a través del proyecto en instrumentos de medición o evaluación del proyecto. evaluación de los procesos y actividades de cada etapa del proyecto. Juicio de un experto: El experto elegido para esta tarea cuenta con un amplio conocimiento en gestión de proyectos informáticos y de desarrollo de software, por lo cual aporto inmejorables conocimientos, así como toda su experiencia para establecer el presente plan de gestión de riesgos. 5. PRIORIDAD DE LOS RIESGOS Como se mencionó en la parte inicial del numeral dos del actual plan de gestión de riesgos, la detección realizada a criterio de un experto, del director del proyecto y demás integrantes del equipo de desarrollo, permitió establecer igualmente una priorización en función de la probabilidad de ocurrencia de cada uno de los riesgos identificados como lo muestra la tabla xx, para posteriormente continuar con las fases de control, monitoreo y disminución del impacto de los riesgos. 6. CONTROL Y MONITOREO DE RIESGOS Para el adecuado control y monitoreo de los riesgos se aplicó otra de las herramientas del PMBOK: la lista de Chequeo, en donde se establece el control pertinente a cada uno de ellos, así como la verificación si este fue controlado o no. Hay que aclarar que tanto el control como el constante monitoreo, se realizaron durante cada uno de los Sprints completados de la metodología Scrum. 138

139 Tabla: 24 Lista de Chequeo y Control. Riesgo Control Probabilidad SI Un stakeholder del equipo de desarrollo, abandona el proyecto antes de su presupuestada finalización. Desfase en el cronograma de actividades. Los requerimientos del Clientes no se Satisfacen cuando se entrega el producto al mismo. Se hace una mala planeación del proyecto. No se hace control de calidad en las diferentes fases del Proyecto. No se realiza una eficiente estimación de los recursos humanos, económicos y tecnológicos necesarios para el proyecto. Contar con bitácora de suplentes capacitados. Diseñar planes de contingencia de mitigación de imprevistos. Realización de entrevistas y herramientas de recolección de información. Estimar adecuadamente Recursos. Implementación de Indicadores. Dedicar una adecuada y minuciosa planeación. 0.8 X 0.9 X 0.6 X 0.9 X 0.7 X 0.9 X 139

140 AUTORIZACIÓN Aprobado por los patrocinadores y director del proyecto: Lucy Paola Martínez Pérez Estudiante Ingeniería de Sistemas Patrocinador Eibin Fabián Acosta Agudelo Estudiante Ingeniería de Sistemas Patrocinador Fabián Blanco Garrido Ingeniero de Sistemas Director del proyecto 140

141 ANEXO 7. PLAN DE GESTIÓN DE ADQUISICIONES 1. INTRODUCCIÓN El presente plan de gestión de adquisiciones se realiza en favor de planificar todas aquellas adquisiciones y asuntos afines que se consideran de gran importancia para el exitoso desarrollo del proyecto Merkonsola. Por ello este plan pauta las contrataciones pertinentes, las herramientas de desarrollo de software necesarias, los criterios de decisión de adquisiciones y finalmente su correspondiente proceso de aprobación, etc. 2. SELECCIÓN Y APROBACIÓN DE ADQUISICIONES El grupo de desarrollo del proyecto es el encargado de definir las herramientas de software de desarrollo y demás bienes o servicios necesarios para el cumplimiento de los objetivos planteados en el proyecto. Por otra parte la contratación de las adquisiciones necesarias, deben ser debatidas por todos los integrantes del grupo de desarrollo previo a su aprobación. Hay que tener en cuenta que antes de realizar cualquier tipo de adquisición, se debe en primera instancia solicitar al director del proyecto que brinde su opinión profesional frente a viabilidad e importancia de realizar una determinada adquisición en relación al costo/beneficio que aporta al proyecto. 3. DEFINICIÓN DE ADQUISICIONES En la tabla 23, se muestra la lista de adquisiciones definidas mediante el proceso de selección y aprobación mencionado anteriormente, acorde con los meses presupuestados en los que se considera se debe realizar la obtención de los mismos. 141

142 Tabla: 25 Adquisiciones Adquisición Motivo Fecha Equipo Escritorio Servidor Equipos portátiles para Desarrollo Paquete de ofimática MS Office Home & Student Servidor Apache Tomcat Sistema Gestor de Base de Datos Postgresql Entorno de Desarrollo Integrado Eclipse Herramienta CASE Astah Community Herramienta WBS EDraw En este equipo se alojara la aplicación para su correspondiente implementación y puesta en marcha. En estos equipos son utilizados por los integrantes del grupo de desarrollo para realizar el diseño y codificación de la aplicación. Se utiliza para la correspondiente elaboración de informes y documentos necesarios para la documentación del software. Es solicitado debido a que sobre este se ejecuta la aplicación. Se requiere puesto que sobre este se realiza la creación de la base de datos necesaria para soportar la capa de datos del software. Es necesario debido a que permite codificar, compilar, depurar y probar el código fuente. Son herramientas que permiten el ágil diseño de las aplicaciones, reduciendo el tiempo de desarrollo. Permite el diseño de la WBS necesaria para la planeación de los hitos y actividades a desarrollar durante el ciclo de vida del Enero de 2011 Enero de 2011 Enero de 2011 Febrero de 2011 Febrero de 2011 Febrero de 2011 Febrero de 2011 Febrero de

143 proyecto. Libros y Son utilizados como medio de documentación Manuales para profundizar, ampliar y resolver dudas o conceptos referentes al proceso de desarrollo. Herramienta de Facilita el ágil desarrollo de la capa web o Diseño Web Interfaz gráfica, con la que el cliente final interactúa. Herramienta de Se utiliza con el fin de servir de herramienta mensajería de comunicación entre los stakeholders. Skype Navegadores Su importancia radica en que sobre ellos se Web realizan las pruebas correspondientes que acrediten que el software funciona y se visualiza correctamente en cualquiera de los navegadores más populares del mercado. Dirección IP Se requiere solicitar ante un PSI, una dirección Publica Estática pública estática que permita a la aplicación ser usada por los clientes y el administrador. Febrero de 2011 Febrero de 2011 Marzo de 2011 Mayo de 2011 Junio de LICENCIAMIENTO DE LAS ADQUISICIONES Acorde con lo estipulado en el objetivo final del presente proyecto, se hace uso de herramientas de software libre para realizar el desarrollo de Merkonsola, debido a que no se cuenta con presupuesto suficiente para el licenciamiento de software propietario, con la excepción de aquel software de demostración por un periodo de tiempo limitado de prueba, como lo es el paquete de Microsoft Office Home & Student 2007 licenciado con un periodo de 60 días de prueba, disponible de fábrica con los sistemas operativos de los equipos portátiles de desarrollo. 143

144 5. PROCESO DE APROBACIÓN DE LOS CONTRATOS DE ADQUISICIONES Una vez definidas la lista de adquisiciones a lo largo del tiempo, es pertinente definir el listado de proveedores que pueden satisfacer dicha necesidad. Una vez realizado el anterior paso, se procede a enviar el requisito a satisfacer a cada uno de los proveedores con el fin de obtener sus diferentes propuestas de costos frente a las necesidades demandadas. Una vez que se obtiene respuesta a las diferentes propuestas de los proveedores, se realiza el análisis de costos que más se ajusten a las necesidades del proyecto y al presupuesto estipulado para cada una de ellas teniendo en cuenta el factor costo/beneficio para correspondiente aprobación del contrato indicado. 6. CRITERIOS PARA LA TOMA DE DECISIONES EN LOS CONTRATOS DE LAS ADQUISICIONES Los criterios que influyen en la toma de la adecuada decisión para la adjudicación de los contratos que mejor se ajusten al proyecto, se realizan de acuerdo ha: Presupuesto del proyecto. Proveedor con tiempo y experiencia en el mercado. Facilidades de pago. Cumplimiento Referencias de otros compradores. 144

145 AUTORIZACIÓN Aprobado por los patrocinadores y director del proyecto: Lucy Paola Martínez Pérez Estudiante Ingeniería de Sistemas Patrocinador Eibin Fabián Acosta Agudelo Estudiante Ingeniería de Sistemas Patrocinador Fabián Blanco Garrido Ingeniero de Sistemas Director del proyecto 145

146 ANEXO 8. PLAN DE GESTIÓN DE COMUNICACIONES 1. INTRODUCCIÓN El Plan de Gestión de las Comunicaciones establece el marco de las comunicaciones para el proyecto MERKONSOLA. Servirá como guía para las comunicaciones en toda la vida del proyecto. Este plan identifica y define los roles de las personas involucradas en el proyecto. También incluye una matriz de las comunicaciones la cual nos vale de mapa de las necesidades de comunicación del proyecto. También incluye una guía detallada para la realización de reuniones de información tanto a las normas de comunicación y cómo las reuniones se llevarán a cabo, asegurando reuniones con éxito. Un directorio del equipo del proyecto se incluye para brindar mayor información de contacto de todos los actores implicados en el proyecto. 2. ENFOQUE DE LA GESTIÓN DE LAS COMUNICACIONES El Director del proyecto tendrá un papel proactivo para asegurar una comunicación efectiva en el proyecto MERKONSOLA. Las necesidades de comunicaciones están documentadas en la matriz de comunicaciones presentada en este documento. La matriz de comunicaciones será utilizada como guía para la información que debe comunicarse, que es comunicar, cuando comunicar y a quién comunicar. 3. ROLES Promotores del proyecto Los promotores del proyecto, Paola Martínez y Fabián Acosta quienes han autorizado el proyecto mediante la firma de la carta del proyecto son los responsables de la financiación del proyecto y del éxito. Director del programa 146

147 El gerente del programa Paola Martínez supervisara el proyecto a nivel de la cartera y es propietarios de la mayor parte de los recursos asignados al proyecto. Por ser un proyecto sin ánimo de lucro. Interesados Clave Universidad Libre Fabián Blanco Garrido (Director del Proyecto) Lucy Paola Martínez Pérez (Promotor) Eibin Fabián Acosta Agudelo (Promotor) Minimercado Andalucía Moisés Salvador Castellanos (Cliente) Junta de control de cambios El grupo designado a la revisión de las especificaciones técnicas y los cambios autorizados de diseño, análisis y aplicación está integrado por los miembros de los interesados clave. Cliente El cliente de este proyecto es el señor Moisés Salvador Castellanos. Hasta que el cliente acepte la entrega final del proyecto será informado de la situación del mismo, que de hecho, es participe cuándo se efectúan revisiones y modificaciones a las características del proyecto. 147

148 Director del proyecto El director del proyecto Fabián Blanco Garrido tiene la responsabilidad general para la ejecución del proyecto. El director maneja día a día los recursos, proporciona una guía de proyectos y supervisa e informa sobre las métricas de proyectos tal como se define en el Plan De Gestión de Proyectos. A medida que la persona responsable de la ejecución del proyecto, el director del proyecto es el comunicador principal para el proyecto de distribución de la información de acuerdo con este plan. Equipo del proyecto El equipo del proyecto está compuesto por Paola Martínez y Fabián Acosta, que tienen una función de realizar el trabajo en el proyecto. El equipo del proyecto debe tener una clara comprensión de la obra se complementará, el marco en el que el proyecto se va a ejecutar. Dado que el proyecto de equipo es responsable de completar el trabajo para el proyecto en el que desempeñó un papel clave en la creación del plan de proyecto incluyendo la definición de su cronograma y los paquetes de trabajo. El equipo del proyecto requiere un nivel de detalle de las comunicaciones que se logra a través de interacciones cotidianas con el director del proyecto y otros miembros del equipo junto con las reuniones semanales del equipo. Líder Técnico El jefe técnico Fabián Acosta llevara la responsabilidad de garantizar que todos los aspectos técnicos del proyecto que se abordan se implementan de manera técnicamente correcta. También es responsable de todos los diseños técnicos, supervisión de la aplicación de los diseños de desarrollo, y la generación de documentación. 148

149 4. DIRECTORIO DEL EQUIPO DEL PROYECTO La siguiente tabla presenta la información de contacto para todas las personas identificadas en este plan de gestión de las comunicaciones. Las direcciones de correo electrónico y números de teléfono en esta tabla se utilizarán para comunicarse con estas personas. Tabla: 26 Directorio de contactos Rol Nombre Teléfono Promotores del proyecto Paola Martínez paola928@hotmail.com Fabián Acosta eibinfabian@hotmail.com Director del programa Paola Martínez paola928@hotmail.com Director del proyecto Fabián Blanco fab_blan@hotmail.com Moisés Salvador moises_salv@hotmail.com Involucrados Fabián Blanco fab_blan@hotmail.com en el proyecto Paola Martínez paola928@hotmail.com Fabián Acosta eibinfabian@hotmail.com Cliente Moisés Salvador moises_salv@hotmail.com Equipo del proyecto Paola Martínez paola928@hotmail.com Fabián Acosta eibinfabian@hotmail.com Líder Técnico Fabián Acosta eibinfabian@hotmail.com

150 5. MATRIZ DE COMUNICACIONES La siguiente tabla identifica los requisitos de comunicaciones para el proyecto MERKONSOLA: Tabla: 27 Matriz de Comunicaciones Tipo de comunicación Objetivo de la comunicación Medio Frecuencia Entrevista Propietario Entregable Indicar las Inicio de metas del proyecto proyecto, Conferencias Al inicio Promotores Director y Agenda herramientas skype y del Equipo propietario Acta de y Team proyecto Cliente del reunión metodologías Viewer. Directores proyecto Notas a usar. Reuniones Revisar Conferencias Agenda del avances, skype y Director Acta de equipo proyecciones Team Diarias Director del reunión del y Viewer. Equipo proyecto Notas proyecto dificultades. Reuniones Discutir y Conferencias Agenda técnicas desarrollar skype y Como Director Líder Acta de de diseño los diseños Team sean Líder técnico reunión técnicos. Viewer. necesarias técnico Notas Estado Determinar Conferencias Reporte semanal el estado skype y Semanal Director Director de del semanal de Team Cliente del estado proyecto cada Sprint. Viewer. proyecto del Sprint 150

151 Dar a Reporte conocer el Conferencias Promotores Reporte de estado estado del skype y Al final de Equipo Director de del proyecto en Team cada Cliente del estado proyecto función del Viewer. Sprint Directores proyecto del tiempo y proyecto costos. Fuente: autores 6. DIRECTRICES PARA LAS REUNIONES Agenda de la reunión La agenda de la reunión será la misma para todos los días. El programa integrara al equipo y al director del proyecto, en donde cada miembro del equipo, acorde con la metodología Scrum en un periodo de 20 minutos manifestara lo que se ha hecho, lo que hará y que inconvenientes ha tenido. Acta de reunión El director del proyecto, llevara un seguimiento y control de los avances, proyecciones e inconvenientes que tengan cada uno de los miembros del equipo. Reunión persona presidente El director del proyecto es el responsable de la difusión de la agenda de la reunión y difusión de las anotaciones de la reunión. También se asegura de que la reunión se inicia y termina el tiempo y que todos los presentadores se adhieren a sus plazos asignados. 151

152 Tomador de notas Cada miembro de la reunión se encarga de tomar sus propias notas, así mismo el responsable de llevar su propio seguimiento del equipo de trabajo, más aun cuando sus labores dependen del avance de otros miembros del equipo para la intervención en la reunión. Encargado del tiempo Para el proyecto MERKONSOLA el director del proyecto será quien determine el cumplimiento de las horas de las reuniones y del tiempo asignado a cada miembro del equipo para la intervención en la reunión. 7. TERMINOLOGÍA DEL GLOSARIO DE COMUNICACIÓN Scrum Metodología de desarrollo ágil seleccionada para el desarrollo del producto, cuyas fases se integraron con PMI para el proyecto MERKONSOLA. Director del proyecto En la metodología Scrum, se conoce como el Scrum Master y sus funciones son una extensión de las habituales, pertenecientes al ciclo de vida del proyecto y del producto. Equipo de trabajo Según Scrum el Team, integrado por los desarrolladores, analistas entre otros actores implícitos en el desarrollo. Inicio del proyecto Corresponde al inicio de Scrum y de la planeación del sprint. 152

153 AUTORIZACIÓN Aprobado por los patrocinadores y director del proyecto: Lucy Paola Martínez Pérez Estudiante Ingeniería de Sistemas Patrocinador Eibin Fabián Acosta Agudelo Estudiante Ingeniería de Sistemas Patrocinador Fabián Blanco Garrido Ingeniero de Sistemas Director del proyecto 153

154 ANEXO 9. SCRUM 1. DEFINICIÓN La metodología Scrum es una metodología de desarrollo ágil basada en la conformación de equipos multidisciplinarios que ejecutan su labor durante ciclos no muy largos, en los que se pretende realizar una mejora continua del producto o servicio cada vez que se cumple un ciclo o también denominado sprint. 2. ROLES Scrum presenta los siguientes roles: EQUIPO (TEAM) PROPIETARIO DEL PRODUCTO (PRODUCT OWNER) MAESTRO SCRUM (SCRUM MASTER) 3. EQUIPO (TEAM) También conocido el cerdo (Pig) en cierta bibliografía, su función principal es la de desarrollar el producto o servicio que el cliente solicita (para el presente proyecto el producto es: Merkonsola), este equipo como se mencionó en la definición previamente, está compuesto por integrantes multidisciplinarios que tienen amplios conocimientos para el exitoso desarrollo del producto entregable cada vez que termine un sprint. En cuanto a su organización el equipo no cuenta específicamente con un líder u coordinador del equipo, en contraposición cuenta con un alto grado de autonomía que les permite cumplir con las actividades propuestas de forma independiente. 154

155 4. PROPIETARIO DEL PRODUCTO (PRODUCT OWNER) En algunas ocasiones el propietario del producto suele ser el mismo cliente para quien se realiza el producto como es el caso del proyecto Merkonsola, pero no siempre es así. Es aquel stakeholder que tiene el mayor grado de autoridad debido a que es el encargado de maximizar el retorno sobre la inversión o también conocido como ROI (Return On Investment), que se hace mediante la clasificación de algunas características del producto que son priorizadas en aras de definir su grado de importancia e incidencia sobre el producto. Este rol interactúa con el Equipo (TEAM), de tal forma que es el responsable de constatar los resultados obtenidos del producto durante cada una de los Sprints dados durante 2 o 4 semanas en promedio. 3. MAESTRO SCRUM (SCRUM MASTER) Es aquel rol que contiene profundos conocimientos sobre el manejo, implementación y asesoría en cuanto a Scrum se refiere. De esta forma dicho individuo debe capacitar y guiar a los demás (Equipo y Product Owner) sobre la mejor manera de aplicar esta metodología para alcanzar los objetivos y actividades asignadas. Por ende este rol se debe encargar que todos comprendan y sigan las prácticas de propuestas por Scrum. Finalmente su función no radica en dar orden a los demás respecto a lo que deben hacer, por lo contrario sirve únicamente de apoyo. 4. INICIO SCRUM En la primera fase de Scrum comúnmente el Propietario del producto (Product Owner) como se en previos párrafos se encarga de elaborar una lista priorizada que brinde la visión del producto a realizar. Esta lista se conoce comúnmente como el Cartera del producto (Product Backlog), esta última para términos de desarrollo del software, es el compendio de requisitos que debe cumplir el 155

156 software; a su vez esta lista es la ruta a seguir y a cumplir. El Product Backlog a lo largo de todas los sprints se refina buscando una mejor definición de los requisitos exigidos por el cliente, por ende para la ingeniería de software estos se llevan a casos de uso y otros diagramas, con el fin de definir claramente actividades a realizar por el TEAM o para un más claro entendimiento para el cliente. Figura: 32 Funcionamiento de Scrum Fuente: 5. PLANEACIÓN DEL SPRINT (SPRINT PLANNING) Una vez ya elaborado el Product Backlog se da inicio a la planeación del sprint, este consistente en que previamente al inicio del sprint se debe llevar a cabo una reunión de planeación en los que se definan aspectos importantes como: prioridades más importantes del Product Backlog, en donde se busca hacer bastante énfasis en lo que el propietario del producto realmente desea hacer con él se definan aspectos importantes como: prioridades más importantes del Product. 156

157 6. SCRUM DIARIO (DAILY SCRUM) De forma concreta el Scrum diario se basa en la realización de cortas reuniones o meetings del TEAM, en una hora comúnmente acordada. Con estas reuniones se busca comunicar a los demás integrantes sobre el desarrollo de sus actividades, así como aquellos obstáculos y avances presentados, de forma muy concisa. 7. REFINAMIENTO DEL PRODUCT BACKLOG Este es una de las etapas claves para refinar y garantizar una mejor aproximación en cuanto a los requisitos que el cliente desea satisfacer. Esta etapa en la gran mayoría de ocasiones tarda un 10 % aproximadamente del tiempo total de cada sprint. Durante la ejecución de la presente fase el TEAM y el Product Owner se reúnen para realizar tal labor y acordar un análisis detallado sobre el impacto que puede llegar a tener futuros cambios. 8. FINAL DEL SPRINT Una de las características que es de rescatar de Scrum, es que cada vez que se pacte la fecha de finalización de un sprint, este se termina sin importar si el TEAM termino o no sus labores pactadas. Usualmente durante las primeras iteraciones (sprints) el equipo no alcanza a cumplir dichas labores, pero con el paso de los sprints se tiene presente un mejor manejo del tiempo y de la cantidad de trabajo que estos pueden desarrollar en tal lapso de tiempo, tomando un ritmo adecuado de trabajo. 9. REVISIÓN DEL SPRINT Una vez terminado un sprint se hace necesario realizar una revisión del mismo, en donde el Product Owner y el Team discuten sobre los resultados y actividades del sprint, buscando adaptar y retroalimentarse para dar inicio al siguiente sprint. 157

158 10. RETROSPECTIVA DEL SPRINT Esta etapa complementa en gran medida a la anterior, puesto que su función principal radica en adaptar aquellos aspectos analizados en favor de adaptar procesos que aporten refinamiento de los requisitos y una mejora continúa. En algunas ocasiones el TEAM no realiza esta fase por que se asimila con la anterior, pero el no cumplimiento de las misma, no permite llevar a cabo los ajustes correspondientes para determinar que sirve y que no. 11. INICIO DE SIGUIENTE SPRINT Cumplido lo anterior se da inicio a un nuevo sprint, en donde se efectúa la correspondiente actualización del Producto Backlog por parte del Product Owner acorde con las adaptaciones y retroalimentaciones de las etapas anteriores. De esta forma inicia nuevamente el proceso iterativo desde la fase de inicio ya descrita. 12. CICLO DE VIDA DE SCRUM Scrum de forma genérica cuenta con las siguientes etapas en su ciclo de vida: Pre-Juego (Planeación): El propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (Backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción. Pre-Juego (Montaje o Arquitectura): El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos. 158

159 Juego (Desarrollo): El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum. Pos-Juego (Cierre): Liberación. El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta AMARO CALDERÓN, Sarah. Metodologías Ágiles. Página

160 ANEXO 10. JAVA 2 ENTERPRISE EDITION (J2EE) 1. DEFINICIÓN La plataforma J2EE (Java 2 Enterprise Edition), es la propuesta de SUN para el desarrollo y la implementación de aplicaciones corporativas multinivel. La plataforma J2EE se apoya por completo en el lenguaje Java beneficiándose, por tanto, de sus características. SUN define al lenguaje Java como sencillo, orientado a objetos, seguro, portable y multitarea ARQUITECTURA DE J2EE La arquitectura propuesta por J2EE, busca generar un una plataforma que brinde a los desarrolladores de software las facilidades de trabajar con múltiples capas o niveles, con el ánimo de generar independencia entre ellas y aumentar la tolerancia a fallos. En otras palabras que el fallo en una capa no afecte a las demás. De igual manera esta arquitectura provee: Alta eficiencia en su proceso de desarrollo. Escalabilidad frente a las condiciones cambiantes del negocio. Facilidad de integración entre las capas de la Arquitectura, debido a la gran cantidad de patrones y estándares ofertadas por la misma. En consecuencia la arquitectura de J2EE se muestra en la Figura AUMAILLE, Benjamin. J2EE desarrollo de aplicaciones web. Página

161 Figura: 33 Arquitectura de J2EE Fuente: 3. Capas de la Arquitectura J2EE Capa del Cliente Corresponde a lo que se encuentra en el computador del cliente. Es la interfaz gráfica del sistema y se encarga de interactuar con el usuario. J2EE tiene soporte para diferentes tipos de clientes incluyendo clientes HTML, applets Java y aplicaciones Java. 44 Capa Web Se encuentra en el servidor web y contiene la lógica de presentación que se utiliza para generar una respuesta al cliente. Recibe los datos del usuario desde la capa cliente y basado en éstos genera una respuesta apropiada a la solicitud. J2EE utiliza en esta capa las componentes Java Servlets y JavaServer Pages para crear los datos que se enviarán al cliente Página Página

162 Capa de Negocio Se encuentra en el servidor de aplicaciones y contiene el núcleo de la lógica del negocio de la aplicación. Provee las interfaces necesarias para utilizar el servicio de componentes del negocio. Las componentes del negocio interactúan con la capa de datos y son típicamente implementadas como componentes EJB. 46 Capa de Datos Es responsable del sistema de información de la empresa o Enterprise Information System (EIS) que incluye bases de datos, sistema de procesamiento datos, sistemas legados3.2 y sistemas de planificación de recursos. Esta capa es el punto donde las aplicaciones J2EE se integran con otros sistemas no J2EE o con sistemas legados Componentes Arquitectura J2EE Las aplicaciones J2EE están formadas por varios componentes. Un componente J2EE es una unidad autónoma de software funcional que se monta en una aplicación J2EE con sus clases y archivos relacionados y que se comunica con otros componentes. La especificación J2EE define los siguientes componentes J2EE: Los clientes de aplicaciones y applets, son componentes que se ejecutan en el cliente. Java Servlet y JavaServer Pages (JSP), son los componentes de la tecnología son componentes web que se ejecutan en el servidor Página Página

163 Enterprise JavaBeans (EJB), son los componentes de negocio que se ejecutan en el servidor. Componentes J2EE están escritos en el lenguaje de programación Java y se compilan en la misma forma que cualquier programa en el lenguaje. La diferencia entre los componentes J2EE y "el estándar" clases de Java, es que los componentes J2EE se ensamblan en una aplicación J2EE, se verifica que estar bien formado y, en cumplimiento de la especificación J2EE y se implementan en la producción, donde son dirigidos y gestionados por el servidor J2EE Contenedores de J2EE Un contenedor es un servicio que proporciona la infraestructura necesaria a una componente para ser ejecutada, para proveer sus servicios a un cliente y para dar comunicación con otras componentes. Las componentes de una aplicación J2EE no interactúan directamente entre ellas, sino que deben utilizar los protocolos y métodos dados por el contenedor para ese fin. Un contenedor usualmente provee sus servicios a las componentes como un Java Runtime Environment (JRE). 6. APIs de J2EE La arquitectura J2EE cuenta con un amplio repertorio de APIs (Application Programming Interfaces), que le permiten ofrecer una multitud de beneficios y servicios orientados a satisfacer y sacar el máximo provecho a cada una de las capas que conformar tal arquitectura. Las APIs de la plataforma J2EE se clasifican en la Figura 34 de acuerdo a su tipo contenedor Capítulo

164 Figura: 34 APIs de J2EE Fuente: Dentro de las principales APIs se encuentran: Enterprise JavaBeans Escritos en un lenguaje de programación Java, un Enterprise JavaBean es el componente del lado del servidor que encapsula la lógica de negocio de una aplicación. La lógica de negocio es el código que cumple con el propósito de la aplicación. 49 JSP (JavaServer Pages) Una página JSP es un documento de texto que contiene dos tipos de texto: datos estáticos (que puede ser expresado en cualquier formato basado en texto, tales como HTML, WML y XML) y los elementos de JSP, que determinan cómo se construye la página de contenido dinámico BODOFF, Stephanie. The J2EE tutorial. Página

165 Servlets Es un componente Web concebido como una clase de java que existe en una aplicación web y cuya utilización está gestionada por un contenedor web, en el servidor web. Un Servlet interacciona con un cliente web mediante el protocolo HTTP, a través de un mecanismo de petición/respuesta. Los Servlets permiten extender las posibilidades de un servidor web, aportando la posibilidad de generar contenido dinámico en respuesta a las peticiones de los clientes. 51 JDBC (Java DataBase Connectivity) El API JDBC permite llamar a comandos SQL de los métodos de programación Java. Se utiliza la API de JDBC en un Enterprise Javabean. Con la persistencia gestionada por un contenedor, las operaciones de base de datos de acceso son manejados por el contenedor, y la implementación de Enterprise Javabean no contiene ningún código JDBC o comandos SQL. También puede utilizar la API de JDBC desde un servlet o una página JSP para acceder a la base de datos directamente sin usar un Enterprise Javabean. El API JDBC tiene dos partes: una interfaz de nivel de aplicación utilizada por los componentes de aplicación para acceder a una base de datos y una interfaz de proveedor de servicios para conectar un controlador JDBC para la plataforma J2EE AUMAILLE, Benjamin. J2EE desarrollo de aplicaciones web. Página

166 ANEXO 11. DOCUMENTO ESPECIFICACIÓN REQUISITOS (IEEE830) Especificación de Requisitos del Software: Merkonsola, Según el estándar de IEEE 830. IEEE Std RESUMEN El presente documento, pretende definir y aclarar, todos aquellos aspectos fundamentales relacionados con la etapa de Especificación de Requisitos de la Aplicación Web: Merkonsola, rigiéndose por el estándar de IEEE 830. Los cuales son necesarios para llevar a cabo la Etapa de Diseño del Software. ÍNDICE 1. Introducción 1.1 Propósito. 1.2 Ámbito del Sistema. 1.3 Visión General del Documento. 2. Descripción General 2.1 Perspectiva del Producto. 166

167 2.2 Funciones del Producto. 2.3 Restricciones. 2.4 Suposiciones y Dependencias. 2.5 Requisitos Futuros. 3. Requisitos Específicos. 3.1 Interfaces Externas. 3.2 Funciones. 3.3 Requisitos de Rendimiento. 3.4 Restricciones de Diseño. 3.5 Atributos del Sistema. 1. Introducción La ERS es un factor clave en la satisfacción y la funcionalidad esperada por el Usuario de un Producto de Software. Por tal motivo, el presente documento pretende ser un medio que especifique y defina claramente aquellos requisitos, atributos, restricciones, obligaciones, funciones y contexto con los cuales el Producto de Software deberá cumplir a cabalidad, con motivo de esclarecer ambigüedades que se puedan presentar entre las partes interesadas: Contratista y Contratante. Es por ello, que a continuación se definen cada uno de los aspectos necesarios para el cumplimiento de lo anteriormente dicho. 1.1 Propósito. La ERS, como se hace mención en la introducción de este capítulo, tiene como principal propósito ser un medio que especifique y defina claramente aquellos requisitos, atributos, restricciones, obligaciones, funciones y contexto con los 167

168 cuales el Producto de Software deberá cumplir a cabalidad, con motivo de esclarecer ambigüedades que se puedan presentar. Por ende, dicho documento está dirigido tanto a las dos principales partes involucradas: Contratista y Contratante, como a cualquier otra entidad de orden legal o judicial que pueda requerirlo en caso alguno. 1.2 Ámbito del Sistema. La presente ERS se lleva a cabo para el Software: Merkonsola Virtual. Este último es una Tienda Virtual, la cual permitirá al cliente realizar la compra de productos (víveres y abarrotes) en Internet; usando como medios de pago: Contra-entrega y Pago Anticipado. Así mismo, permitirá al Administrador de la Tienda Virtual, gestionar aspectos como: Catálogo (Productos, Categorías, Fabricantes, Proveedores, Promociones). Clientes. Pedidos (Facturación). Pago (impresión tickets pago anticipado). Es preciso resaltar, que Merkonsola no brinda herramientas o ayudas concretas para que aquellos usuarios con algún tipo de discapacidad específica de orden motriz, visual, manual u otro, puedan hacer uso del sistema con total comodidad y eficacia. 168

169 De la misma manera, este Software centra su funcionalidad y servicio en aquellos aspectos que involucran los pedidos a domicilio: Solicitud, registro y facturación de los pedidos de víveres y abarrotes. Adición, modificación o eliminación de productos, promociones y ofertas presentes en el catálogo de compra. La impresión de tickets de pago anticipado, con la suma de dinero efectuada por el usuario. En cambio no está relacionado con algún tipo de actividad propia de la gestión del Mini mercado como lo son: Facturación de compras presenciales. Contabilidad del Mini mercado. En lo concerniente a los beneficios se encuentran: Un mejoramiento en sus procesos de facturación y registro de pedidos a domicilio. Apoyo al Administrador del Mini mercado para que pueda tomar decisiones acertadas que le permitan ofrecer un mejor servicio a sus clientes y obtener un mejor provecho y rentabilidad del negocio. Incremento el campo de acción, oportunidades de negocio, ventas, promociones y ofertas a sus clientes, gracias a las múltiples ventajas que brinda una Tienda Virtual en Internet. 169

170 La Aplicación sirve contribuye a mejorar las incomodidades en lo referente al registro erróneo del pedidos telefónicamente. 1.3 Visión General del Documento. De manera generalizada en aras de brindar una visión global de la ERS, es preciso hacer mención de los siguientes contenidos: Tabla: 28 Actividades de desarrollo de software Actividad Descripción Se especifican las necesidades del sistema a desarrollar. La especificación de requisitos sirve como base para la Requisitos negociación entre los desarrolladores y clientes del sistema, y también para planear y controlar el proceso de desarrollo. Se busca comprender los requisitos del sistema con el Análisis propósito de estructurar la arquitectura del sistema. Se transforma la arquitectura obtenida durante el Diseño análisis en una arquitectura especializada, donde se considera el ambiente de implantación particular del sistema. Implementación Se expresa la arquitectura del sistema en una forma aceptable el código. Integración Se combinan los componentes creados de manera independiente para formar el sistema completo. 170

171 Se verifica y valida el sistema a nivel de componentes individuales y de integración. Pruebas Documentación Mantenimiento Se busca descubrir cualquier defecto en los requisitos, análisis, diseño, implementación e integración. Las pruebas se hacen a varios niveles, desde funciones sencillas hasta el sistema completo. Se describen los aspectos sobresalientes de los requisitos, análisis, diseño, implementación, integración y pruebas. Esto servirá para usuarios externos e internos, aquellos encargados de mantener el sistema y extenderlo. Se corrigen errores no encontrados durante el desarrollo y las pruebas originales del sistema. Se extiende el sistema si surgen nuevas necesidades. 2. Descripción General. 2.1 Perspectiva del Producto Es importante resaltar que Merkonsola Virtual, es totalmente independiente de otros productos de Software y por lo tanto no requiere de otro Sistema de Información adicional para su funcionamiento. 171

172 Por tanto Merkonsola Virtual de igual forma, no es parte de otro Sistema de Información Mayor. Sin embargo, esto no significa que no pueda interactuar con otro Software, si así se requiere en un futuro. 2.2 Funciones del Producto Tabla: 29 Funciones del Producto Funciones del Producto N Función Función 1 El Sistema permitirá añadir: categorías, productos, fabricantes, proveedores y promociones al catálogo. 2 El Sistema permitirá eliminar: categorías, productos, fabricantes, proveedores y promociones almacenados en el catálogo. 3 El Sistema permitirá editar: categorías, productos, fabricantes, proveedores y promociones del catálogo. 4 El Sistema permitirá filtrar las búsquedas de categorías, productos, fabricantes, proveedores y promociones del catálogo. 5 El Sistema listara las categorías, productos, fabricantes, proveedores y promociones del catálogo. 6 El Sistema permitirá añadir clientes. 7 El Sistema permitirá eliminar clientes. 8 El Sistema permitirá editar clientes. 9 El Sistema permitirá filtrar los clientes. 10 El Sistema listará los clientes. 11 El Sistema listará los pedidos realizados por los clientes. 172

173 12 El Sistema permitirá filtrar los pedidos. 13 El Sistema generara la factura de los pedidos realizados por los clientes. 14 El Sistema permitirá generar la orden de entrega de los pedidos. El Sistema permitirá generar un archivo PDF, con las facturas 15 de los pedidos comprendidos en un determinado periodo de tiempo. 16 El Sistema permitirá generar la factura con la numeración deseada. El Sistema permitirá generar un archivo PDF, con las órdenes 17 de entrega de los pedidos comprendidos en un determinado periodo de tiempo. 18 El Sistema permitirá generar las órdenes de entrega con la numeración deseada. 19 El Sistema permitirá añadir estados del pedido. 20 El Sistema permitirá eliminar estados del pedido. 21 El Sistema permitirá editar estados del pedido. 22 El Sistema permitirá filtrar los estados del pedido. 23 El Sistema listará todos los estados del pedido. 24 El Sistema permitirá filtrar la devolución de los productos. 25 El Sistema listará las devoluciones de los productos. 26 El Sistema permitirá generar tickets de pago anticipado. 27 El Sistema permitirá imprimir tickets de pago anticipado. 28 El Sistema permitirá eliminar tickets de pago anticipado. 29 El Sistema permitirá editar tickets de pago anticipado. 30 El Sistema permitirá filtrar los tickets de pago anticipado. 173

174 2.3 Restricciones. Tabla: 30 Restricciones Restricciones N Restricción Tipo 1 2 Se requiere las interfaces graficas del usuario, se diseñen de tal manera que sean de fácil comprensión y uso acorde a las características de los usuarios. Los requisitos mínimos de hardware, con los que debe cumplir el servidor son: Interfaz Procesador: Core Duo de 2.4 GHz. Espacio Disco: 80 Gb. RAM: 2 GHz. Tarjeta red: 10/100/1000 Mbps Las expedición de las facturas electrónicas debe cumplir con las normas y demás estamentos de Ley, exigidos por la resolución de nov 28 de La Aplicación debe implementar el protocolo: HTTP (Hypertext Transfer Protocol), necesario para la comunicación entre en Servidor Web y los equipos de cómputo del cliente y el administrador de la Aplicación. La Aplicación debe permitir la generación de estadísticas gráficas, que le permitan al Hardware Legal Protocolo Comunicación Control 174

175 administrador llevar un control estadístico de la tienda. Todos los datos de carácter sensible almacenados en el Sistema Gestor de Base 6 de Datos y Tramas de red, deben ser cifrados utilizando el algoritmo de cifrado TDES. EL registro y acceso de los usuarios debe 7 implementar perfiles, los cuales brinden los adecuados privilegios sobre la Aplicación. Seguridad Seguridad 2.4 Superposiciones y Dependencias. A continuación se hará mención de aquellos factores externos y ajenos al Proyecto, que pueden afectar de alguna u otra manera el normal desarrollo del producto de software o a sus requisitos. Tabla: 31 Restricciones Código Descripción Se debe estudiar rigurosamente los cambios realizados en la legislación referente al comercio electrónico, puesto que 1 este imprevisto puede llegar incurrir en la modificación total o parcial del funcionamiento de la Aplicación y/o su uso. El éxito proyecto dependerá en gran medida de la disponibilidad de los recursos tecnológicos y humanos en el 2 momento que se requiera, para un correcto desarrollo del proyecto y garantía del cumplimiento de los objetivos planteados y resultados esperados. 175

176 2.5 Requisitos Futuros. En el presente ítem, se mencionaran aquellas actualizaciones o mejoras, que se podrían analizar e implementar en el Producto de Software en un futuro. Tabla: 32 Requisito Futuro N Requisito Futuro Se requiere las interfaces graficas del usuario, implementen 1 Macromedia Flash para hacer las mismas más amigables y atractivas. 2 Se debe hacer la migración de la Aplicación a una nueva versión del Servidor Web. No se debe imprimir los comprobantes de los tickets de pago 3 anticipado ni órdenes de entrega, deben ser consultados únicamente desde la Aplicación. 4 Se debe permitir el pago de los pedidos mediante tarjetas de crédito y débito. 5 Se debe migrar la Base de Datos de la aplicación a un nuevo Sistema Gestor de Base de Datos (SGBD). La Aplicación debe implementar el protocolo: HTTPS (Hypertext Transfer Protocol Secure), que permita mediante la certificación 6 del servidor, garantizar la integridad y seguridad de los datos durante su trasferencia y que se hace necesaria para la comunicación entre en Servidor Web y los equipos de cómputo del cliente y el administrador de la Aplicación. La Aplicación debe permitir la generación de estadísticas gráficas, 7 que le permitan al administrador llevar un control estadístico de la tienda. 176

177 Todos los datos de carácter sensible almacenados en el Sistema 8 Gestor de Base de Datos y Tramas de red, deben ser cifrados utilizando el Algoritmo de cifrado que demuestre mejores resultados en el mercado. 3. Requisitos Específicos. 3.1 Interfaces Externas. Tabla: 33 Requisitos Interfaces Externas Código Descripción RIE01 La Interfaz Gráfica de Usuario del Front Office debe manejar 4 marcos para organizar la presentación grafica de la información. La Interfaz Gráfica de Usuario del BackOffice debe manejar 2 RIE02 marcos principales para organizar la presentación grafica de la información. La combinación e implementación de los colores en el Diseño Web de la Aplicación, debe regirse por las mejores prácticas de combinación y teoría del color, recomendadas por la comunidad RIE03 CRISTALAB en el enlace: RIE04 Se requiere que la Impresora térmica y el equipo de cómputo del Administrador de la Tienda se comuniquen mediante una interfaz USB. 177

178 3.2 Funciones. Las funciones del ERS, se clasifican acorde con las interfaces de Usuario, de la siguiente manera: BackOffice. Módulo Autenticación Tabla: 34 Requisitos del Módulo Autenticación Código Descripción El módulo Autenticación, debe verificar el usuario y contraseña, de tal manera que si no coinciden (correo electrónico y contraseña) con los datos registrados, se debe RFAUT01 permitir el acceso a un link: Ha olvidado la contraseña?, el cual debe solicitar al Usuario ingresar la dirección de correo electrónico con la que se registró, donde se hará llegar la contraseña correspondiente. El módulo Autenticación debe mostrar un mensaje en pantalla, que permita saber al usuario si existen errores durante la autenticación a causa del ingreso erróneo del RFAUT02 o de la contraseña, o si en cambio el del usuario a autenticar no se encuentra registrado en la base de datos. 178

179 Módulo Catálogo Tabla: 35 Requisitos del Módulo Catálogo Código Descripción El sub módulo Categorías, debe listar las categorías RFCA01 existentes en la base de datos acorde con los siguientes parámetros: ID, Nombre categoría, Descripción, Mostrados y Acciones (añadir, editar o borrar). Cuando se ejecute la acción añadir categoría, se debe solicitar la siguiente información: Nombre categoría, RFCA02 Imagen, mostrado, categoría padre, descripción, meta título, meta palabras. Se deben exigir como campos obligatorios: el Nombre categoría y la Descripción de la misma. Cuando se ejecute la acción editar categoría, se debe editar la siguiente información: Nombre categoría, Imagen, RFCA03 mostrado, categoría padre, descripción, imagen, meta título, meta palabras. Se deben exigir nuevamente como campos obligatorios: el Nombre categoría y la Descripción de la misma. Cuando se ejecute la acción borrar categoría, se debe RFCA04 borrar la categoría en la base de datos y está ya no debe aparecer en la listado de categorías. El sub módulo Categorías, debe mostrar un listado de RFCA05 opciones que permita mostrar las primeras: 20, 50, 100 o 300 categorías. 179

180 Módulo Clientes Tabla: 36 Requisitos del Módulo Clientes Código Descripción El módulo Clientes, debe listar todos los clientes existentes RFCLI01 en la base de datos acorde con los siguientes parámetros: ID, Sexo, Nombres, Apellidos, , Edad, Activado, Registro (desde y hasta), Ultima Conexión y Acciones (añadir, editar o borrar). Cuando se ejecute la acción añadir cliente, se debe solicitar la siguiente información: Sexo, Nombre, Apellidos, RFCLI02 Contraseña, , Fecha Nacimiento, Estado. Se deben exigir como campos obligatorios: Nombres, Apellidos e . Cuando se ejecute la acción editar cliente, se debe editar la siguiente información: ID, Sexo, Nombres, Apellidos, , RFCLI03 Edad, Activado, Registro (desde y hasta), Ultima Conexión. Se deben exigir como campos obligatorios: Nombres, Apellidos e . Cuando se ejecute la acción borrar cliente, se debe borrar RFCLI04 el cliente en la base de datos y está ya no debe aparecer en la listado de clientes. El modulo Clientes, debe permitir seleccionar todos o RFCLI05 aquellos clientes para realizar alguna acción (editar o borrar). 180

181 Módulo Pago Tabla: 37 Requisitos del Módulo Pago Código RFPA01 RFPA02 Descripción El sub módulo impuestos, debe mostrar un listado de opciones que permita mostrar los primeros: 20, 50, 100 o 300 impuestos. El sub módulo Forma pago, debe permitir seleccionar la modalidad de pago a emplear de acuerdo a las tres siguiente opciones: Pago Anticipado, Contra entrega o Ambas. El sub módulo Pago Anticipado, debe permitir generar e imprimir los tickets de pago anticipado. Para la generación los tickets, se debe solicitar la siguiente información: ID Cliente, Monto Anticipado (valor). RFPA03 Para la impresión los tickets, se debe tener en cuenta la siguiente información: Nombre Supermercado, NIT Supermercado, Fecha y Hora Generación Ticket, ID Ticket, Cliente, Monto Ticket (valor), Condiciones y Restricciones. RFPA04 Se deben exigir como campos obligatorios para generación de tickets: ID Cliente, Monto Ticket. El sub módulo Pago Anticipado, debe listar los tickets de pago anticipado acorde con los siguientes parámetros: ID Ticket, ID pedido, Cliente, Monto Ticket, Monto Disponible, Estado, Fecha, Hora. El sub módulo Pago Anticipado, debe permitir el filtrado de 181

182 RFPA05 tickets de pago anticipado por: ID Ticket, ID pedido, Cliente, Monto Ticket, Monto Disponible, Estado, Fecha, Hora. Módulo Pedidos Tabla: 38 Requisitos del Módulo Pedidos Código RFPE01 RFPE02 RFPE03 RFPE04 RFPE05 Descripción El módulo Pedidos, debe listar los pedidos existentes en la base de datos acorde con los siguientes parámetros: ID, Cliente, Total, Modo de Pago, Estado, Fecha y Acciones (Vista pedido). Cuando se ejecute la acción vista pedido, se debe visualizar el pedido acorde con la siguiente información: N Pedido, Estado Pedido, Información del Cliente (nombre cliente, , fecha registro cuenta, total gastos desde el registro), Dirección de envió, Factura (N Factura, Fecha emisión Factura, hora), Información envió (Responsable), Detalles del Pedido (ID pedido, Modo de Pago, Total Artículos, Costo Total), Dirección de Facturación, Artículos (imagen, Nombre artículo, Costo unitario, Cantidad, Total). El módulo Pedidos, debe mostrar un listado de opciones que permita mostrar los primeros: 20, 50, 100 o 300 pedidos. El módulo Pedidos, debe permitir el filtrado de pedidos por: ID, Cliente, Total, Modo de Pago, Estado, Fecha. El módulo Pedidos, debe generar y mostrar valor total 182

183 pedidos realizados. Front Office. Tabla: 39 Requisitos del Front Office Código RFFO01 RFFO02 RFFO03 RFFO04 RFFO05 RFFO06 RFFO07 Descripción El Frontoffice debe contener el sub módulo: Etiquetas, el cual debe listar las metakeywords de los productos más vistos en la tienda. El Frontoffice debe contener el sub módulo: Categorías, el cual debe visualizar todas las categorías de productos y permitir consultar los productos de cada una de ellas. El Frontoffice debe contener el sub módulo: Marcas, el cual debe visualizar todas las marcas y permitir consultar los productos pertenecientes a cada una de ellas. El Frontoffice debe contener el sub módulo: Información, el cual debe permitir consultar al Cliente la información correspondiente a: Entrega, Aviso Legal, Condiciones de Uso, Sobre. El Frontoffice debe contener el sub módulo: Novedades, el cual debe visualizar la descripción de los nuevos productos de la tienda. El Frontoffice debe contener el sub módulo: Contacto, el cual debe permitir al cliente en caso de una inconformidad o sugerencia, comunicarse mediante correo electrónico con el administrador de la tienda. El Frontoffice debe contener el sub módulo: Favoritos, el 183

184 cual debe permitir adicionar la tienda virtual como un marcador en el Browser. RFFO08 El Frontoffice debe contener el sub módulo: Búsqueda, el cual debe permitir buscar en productos. El Frontoffice debe contener el sub módulo: Autenticación, el cual debe verificar el correo electrónico y contraseña del Usuario, de tal manera que si no coinciden (correo RFFO09 electrónico y contraseña) con los datos registrados, se debe permitir el acceso a un link: Ha olvidado la contraseña?, el cual debe solicitar al Usuario ingresar la dirección de correo electrónico con la que se registró, donde se hará llegar la contraseña correspondiente. El sub módulo Autenticación debe mostrar un mensaje en pantalla, que permita saber al usuario si existen errores RFPFO10 durante la autenticación a causa del ingreso erróneo del o de la contraseña, o si en cambio el del usuario a autenticar no se encuentra registrado en la base de datos. 3.3 Requisitos de Rendimiento. Tabla: 40 Requisitos de Rendimiento Código RRE01 RRE02 Descripción El sistema debe soportar como mínimo 60 usuarios simultáneos conectados. El sistema debe soportar como mínimo 1500 transacciones por segundo. 184

185 Se requiere que el consumo de procesador no sobrepase el RRE03 80 % de su capacidad, cuando se alcance las 1500 transacciones por segundo o los 60 usuarios simultáneos. Se requiere que el consumo de RAM no sobrepase el 80 % RRE04 de su capacidad, cuando se alcance las 1500 transacciones por segundo o los 60 usuarios simultáneos. 3.4 Restricciones de Diseño. Tabla: 41 Restricciones de Diseño Código Requerimiento Se requiere que el Lenguaje de modelado a emplear para el RDIS01 diseño de la aplicación sea UML (Unified Modeling Language) versión 2.0. RDIS02 Se requiere adoptar Modelo-Vista-Controlador, como patrón de arquitectura de software de la Aplicación. 3.5 Atributos del Sistema. Tabla: 42 Restricciones Del Sistema Código RDOC01 RCOM02 Requerimiento El grupo de desarrollado debe entregar digitalmente el manual de usuario, en el cual se especifique el funcionamiento de cada una de los módulos de la Aplicación. La Aplicación debe estar en capacidad de ser implementada 185

186 en servidores con sistemas operativos Windows y Linux. La aplicación debe estar en capacidad de ejecutarse los RCOM03 siguientes exploradores: Internet Explorer v8 y Mozilla Firefox v3.4. RCOM04 La Aplicación debe estar en capacidad de ser implementada Servidor de Aplicaciones Apache Tomcat. RCOM05 La aplicación debe estar en capacidad de ser implementada en un sistema gestor de base de datos PostgreSql. 186

187 AUTORIZACIÓN Aprobado por los patrocinadores y director del proyecto: Lucy Paola Martínez Pérez Estudiante Ingeniería de Sistemas Patrocinador Eibin Fabián Acosta Agudelo Estudiante Ingeniería de Sistemas Patrocinador Fabián Blanco Garrido Ingeniero de Sistemas Director del proyecto 187

188 ANEXO 12. DICCIONARIO DE DATOS Tabla: 43 Funcionario Nombre Tabla: funcionario Descripción: Almacena los datos del funcionario administrador de la aplicación. Campo Tamaño Tipo Dato Descripción funcionario_id 10 Numeric Identifica al funcionario user_id 10 Numeric Identifica al usuario primer_nombre 50 Varchar Primer nombre funcionario segundo_nombre 50 Varchar Segundo nombre funcionario primer_apellido 50 Varchar Primer apellido funcionario segundo_apellido 50 Varchar Segundo apellido funcionario nr_identificación 50 Numeric Numero identificación funcionario Tabla: 44 user_apli Nombre Tabla: user_apli Descripción: Contiene los datos de autenticación del administrador de la aplicación. Campo Tamaño Tipo Dato Descripción user_id 10 Numeric Identifica usuario username 15 Varchar Nombre de usuario administrador password 15 Varchar Contraseña usuario administrador Tabla: 45 estados Nombre Tabla: estados Descripción: Contiene los estados de los pedidos, pagos y devoluciones. 188

189 Campo Tamaño Tipo Dato Descripción id_estado 5 Numeric Identifica estado pedido Nombre 10 Varchar Nombre estado pedido Tipo 10 Numeric Tipo de estado Tabla: 46 c_tipo_identificacion Nombre Tabla: c_tipo_identificacion Descripción: Contiene los diferentes tipos de identificación. Campo Tamaño Tipo Dato Descripción c_tipo_identificacion 5 Numeric Identifica el tipo de identificación Nombre 20 Varchar Nombre del tipo de identificación Tabla: 47 c_ticket Nombre Tabla: c_ticket Descripción: Contiene los datos referentes al ticket de pago anticipado. Campo Tamaño Tipo Dato Descripción ticket_id 5 Numeric Identifica el ticket de pago anticipado Monto 20 Numeric Monto del ticket de pago anticipado nr_identificacion Numeric Número de identificación del ticket fecha_expedicion Date Fecha expedición del ticket monto_res Numeric Monto restante del ticket 189

190 Tabla: 48 c_proveedor Nombre Tabla: c_proveedor Descripción: Contiene los datos referentes a los proveedores. Campo Tamaño Tipo Dato Descripción c_proveedor_id 5 Numeric Identifica al proveedor Nombre 20 Varchar Nombre del proveedor Descripción 200 Varchar Descripción del proveedor Metakey 15 Varchar Metapalabras asociadas al proveedor url_image 100 Varchar Ruta de imagen del proveedor Dirección 20 Varchar Dirección del proveedor Ciudad 15 Varchar Ciudad ubicación de proveedor teléfono 15 Numeric Teléfono del proveedor Tabla: 49 c_fabricante Nombre Tabla: c_fabricante Descripción: Contiene los datos referentes a los fabricantes. Campo Tamaño Tipo Dato Descripción c_fabricante_id 5 Numeric Identificación del proveedor Nombre 20 Varchar Nombre del proveedor Descripción 200 Varchar Descripción del proveedor Metakey 15 Varchar Metapalabras asociadas al fabricante url_image 100 Varchar Ruta de imagen del fabricante Dirección 20 Varchar Dirección del fabricante teléfono 15 Numeric Teléfono del fabricante 190

191 Tabla: 50 c_cliente Nombre Tabla: c_cliente Descripción: Contiene los datos referentes a los clientes. Campo Tamaño Tipo Dato Descripción user_id 10 Numeric Identifica al cliente Pnombre 20 Varchar Primer nombre del cliente Snombre 20 Varchar Segundo nombre del cliente nr_identificacion 10 Numeric Un mero de identificación del cliente c_tipo_identificacion 15 Numeric Tipo de identificación del cliente Dirección 20 Varchar Dirección del cliente Tmobil 15 Numeric Teléfono móvil del cliente Tfijo 15 Numeric Teléfono fijo del cliente Metakeys 15 Varchar Metapalabras del cliente Tabla: 51 amd_pago Nombre Tabla: amd_pago Descripción: Contiene los datos referentes a la administración de los pagos. Campo Tamaño Tipo Dato Descripción adm_pago 10 Numeric Identifica el pedido pedido_id 10 Numeric Identifica el pedido Nombre 15 Varchar Nombre del pago Fechapago 10 Date Fecha del pago Saldopagoti 10 Numeric Saldo pago Saldopagofe 10 Numeric Saldo pago Estado 10 Varchar Estado pago 191

192 tipo_pago 10 Numeric Tipo de pago Tabla: 52 amd_productos_pedidos Nombre Tabla: adm_productos_pedido Descripción: Tabla para eliminar grupos repetidos entre productos y pedidos. Campo Tamaño Tipo Dato Descripción productos_pedido_id 10 Numeric Identifica pedido producto_id 10 Numeric Identifica producto adm_producto_id 10 Numeric Identifica adm_producto id_estado 10 Numeric Identifica estado pedido Tabla: 53 amd_producto Nombre Tabla: adm_producto Descripción: Contiene los datos referentes a los productos. Campo Tamaño Tipo Dato Descripción adm_producto_id 10 Numeric Identifica producto c_fabricante_id 10 Numeric Identifica fabricante c_proveedor_id 10 Numeric Identifica proveedor adm_categoria_id 10 Numeric Identifica categoría Nombre 15 Varchar Nombre producto Referencia 10 Varchar Referencia producto referencia_proveedor 10 Varchar Referencia del proveedor Estado 15 Varchar Estado producto Cantidad 10 Numeric Cantidad disponible producto Precio 15 Numeric Precio del producto Iva 10 Numeric IVA asociado al producto 192

193 url_image 100 Varchar Ruta imagen del producto Descripción 200 Varchar Descripción del producto metakeys 15 Varchar Metapalabras asociadas al producto Tabla: 54 amd_pedido Nombre Tabla: adm_pedido Descripción: Contiene los datos referentes a los pedidos. Campo Tamaño Tipo Dato Descripción pedido_id 10 Numeric Identifica el pedido Nridentificacion 10 Numeric Número de identificación del pedido Estado 15 Varchar Estado del pedido fecha_realizacion 10 Date Fecha de realización del pedido Tabla: 55 amd_impuestos_producto Nombre Tabla: adm_impuestos_producto Descripción: Tabla para eliminar grupos repetidos entre impuestos y productos. Campo Tamaño Tipo Dato Descripción adm_producto_id 10 Numeric Identifica producto adm_impuesto_id 10 Numeric Identifica impuesto Tabla: 56 amd_impuesto Nombre Tabla: adm_impuesto Descripción: Contiene los datos referentes a los impuestos. 193

194 Campo Tamaño Tipo Dato Descripción adm_impuesto_id 10 Numeric Identifica el impuesto Nombre 10 Varchar Nombre del impuesto pj_recargo 15 Numeric Recargo del impuesto Tabla: 57 amd_devolucion Nombre Tabla: adm_devolucion Descripción: Contiene los datos referentes a las devoluciones de los productos. Campo Tamaño Tipo Dato Descripción adm_devolucion 10 Numeric Identifica la devolución productos_pedido_id 10 Numeric Identifica pedido id_estado 10 Numeric Identifica estado devolución Causa 200 Varchar Describe la causa de la devolución fecha_devolucion 10 Date Fecha de devolución Tabla: 58 amd_categoria Nombre Tabla: adm_categoria Descripción: Contiene los datos referentes a las categorías. Campo Tamaño Tipo Dato Descripción adm_categoria_id 10 Numeric Identifica categoría adm_categoria_padre_id 10 Numeric Identifica la categoría padre Nombre 15 Varchar Nombre de categoría descripción 200 Varchar Descripción de la categoría 194

195 Tabla: 59 amd_imagen Nombre Tabla: adm_imagen Descripción: Contiene los datos referentes a las imágenes de los productos. Campo Tamaño Tipo Dato Descripción imagen_id 10 Numeric Identifica el nombre de la imagen adm_producto_id 10 Numeric Identifica el producto c_fabricante_id 10 Numeric Identifica fabricante c_proveedor_id 10 Numeric Identifica proveedor nombre_archivo 15 Varchar Nombre de la imagen ruta_repositorio 100 Varchar Ruta de ubicación de la imagen ruta_proyecto 100 Varchar Ruta del ubicación de la aplicación 195

196 ANEXO 13. MÓDULOS DEL SISTEMA Tabla: 60 Application Server Instance Nombre: Módulo Padre: Diagrama: Application Server Instance No aplica Submódulos HTTP Server Web Container EJB Container JDBC Persistence Manager Descripción Gestiona las peticiones HTTP del servidor web. Contiene el entono gráfico con el que interactúa el usuario. Contiene los módulos desarrollados acorde a la lógica de negocio y demás patrones de diseño. Permite la conexión al Sistema Gestor de Base de Datos Relacional. 196

197 Tabla: 61 HTTP Server Nombre: Módulo Padre: Diagrama: HTTP Server Application Server Instance Submódulos HTTP Listener Descripción Escucha todas las peticiones HTTP realizadas desde el navegador del usuario. Tabla: 62 Web Container Nombre: Módulo Padre: Diagrama: Web Container Application Server Instance Submódulos JPS SERVLETS Descripción Componen la capa grafica de la aplicación con la que interactúan los usuarios. Realizar validaciones con base en 197

198 datos capturados por los JSP. XML Realizan procesos de parsing. Tabla: 63 EJB Container Nombre: Módulo Padre: Diagrama: EJB Container Application Server Instance Submódulos Data Access Object FrontOffice BackOffice Descripción Compendio de los patrones de diseño DAO. Tienda virtual, Módulo de lógica de negocio desarrollado en base a los requisitos especificados por el cliente. Módulo de administración de la Tienda virtual, desarrollado en base a los requisitos especificados por el cliente. Tabla: 64 JDBC Persistence Manager Nombre: Módulo JDBC Persistence Manager Application Server Instance 198

199 Padre: Diagrama: Submódulos JDBC Connector Descripción Contiene el puente JDBC necesario para realizar la conexión con el Sistema Gestor de Base de Datos Relacional. Tabla: 65 JDBC Persistence Manager Nombre: Diagrama: Enterprise Information System Resources Submódulos RDBMS Descripción Contiene el conjunto de recursos de almacenamiento de información, necesarios para soportar las estructuras de datos de la aplicación. Dentro de esta se encuentra el Sistema Gestor de Base de Datos Relacional (RDBMS). 199

200 ANEXO 14. ACTIVIDADES DEL DESARROLLO DE LOS MÓDULOS Tabla: 66 Actividades Del Desarrollo De Los Módulos ACTIVIDAD Adquirir Servidor Apache Tomcat. Adquirir Sistema Gestor de Base de Datos Postgresql Adquirir Entorno de Desarrollo Integrado Eclipse Helios. Adquirir herramienta CASE Astah Community Adquirir API JDBC para Postgresql Identificar Módulos de J2EE Diseñar arquitectura del sistema Diseñar Módulos de lógica de negocio Identificar perfiles, roles y usuarios del sistema Identificar Entidades y sus relaciones Diseñar Modelo Entidad Relación Generar Script de la Base de datos Crear Base de Datos Diseñar Diagrama de Casos de uso Diseñar Diagramas de Secuencia Diseñar Diagramas de Actividades Diseñar Diagrama de Componentes Diseñar Diagramas de Clases Diseñar Diagramas de Despliegue Diseñar Diagrama de Paquetes Diseñar Diagrama de Estados Crear JSP de Acceso al BackOffice Crear JSP de submódulo de Gestión Catálogo RESPONSABLE Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Fabián Acosta Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Paola Martínez Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Fabián Acosta Paola Martínez Paola Martínez Paola Martínez Fabián Acosta 200

201 Crear JSP de Gestión Clientes Crear JSP de Gestión Pedidos Crear JSP de submódulo de Gestión Pago Crear JSP de submódulo de Gestión Tickets Crear JSP de Acceso al FrontOffice Crear JSP de submódulo de Registro Crear JSP de submódulo de Carrito Compras Crear JSP de submódulo de Catálogo Crear JSP de submódulo de Pago Crear JSP de submódulo de Autentificación y Cuenta de Usuario Desarrollar Java Scripts de Módulo BackOffice Desarrollar Java Scripts de Módulo FrontOffice Desarrollar Módulo de BackOffice Desarrollar submódulo de Gestión Catálogo Desarrollar submódulo de Gestión Clientes Desarrollar submódulo de Gestión Pedidos Desarrollar submódulo de Gestión Pago Desarrollar submódulo de Gestión Tickets Desarrollar Módulo de FrontOffice Desarrollar submódulo de Registro Desarrollar submódulo de Carrito Compras Desarrollar submódulo de Catálogo Desarrollar submódulo de Pago Desarrollar submódulo de Autentificación y Cuenta de Usuario Realizar pruebas al submódulo de Gestión Catálogo Realizar pruebas al submódulo de Gestión Clientes Fabián Acosta Paola Martínez Paola Martínez Fabián Acosta Fabián Acosta Fabián Acosta Paola Martínez Paola Martínez Paola Martínez Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Fabián Acosta Fabián Acosta Fabián Acosta Fabián Acosta Fabián Acosta Paola Martínez Paola Martínez Paola Martínez Paola Martínez Paola Martínez Paola Martínez Fabián Acosta Paola Martínez 201

202 Realizar pruebas al submódulo de Gestión Pedidos Realizar pruebas al submódulo de Gestión Pago Realizar pruebas al submódulo de Gestión Tickets Realizar pruebas al submódulo de Registro Realizar pruebas al submódulo de Carrito Compras Realizar pruebas al submódulo de Catálogo Realizar pruebas al submódulo de Pago Realizar pruebas al submódulo de Autentificación y Cuenta de Usuario Generación de archivo.war del BackOffice Generación de archivo.war del FrontOffice Generar Script de la Base de datos Implementación del Software Realizar pruebas de rendimiento de software en el entorno real. Fuente. Autores Fabián Acosta Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta Fabián Acosta Paola Martínez Fabián Acosta Fabián Acosta Paola Martínez Fabián Acosta Paola Martínez Fabián Acosta 202

203 ANEXO 15. REVISIÓN DEL PRODUCT BACKLOG La revisión y depuración del Product Backlog se llevó a cabo al final de cada iteración cumplida de la metodología Scrum. Para tal fin se planearon y realizaron reuniones entre los stakeholders (Cliente y Equipo de Desarrollo) con el fin de retroalimentar y optimizar el Product Backlog, lo cual permitió obtener un producto de software maduro y altamente funcional, que posteriormente se llevó a su ambiente de producción una vez cumplida la fase de pruebas de rendimiento. Resultado de las reuniones, se identificaron algunos aspectos por mejorar dentro de los que se destacan: Cerrar la sesión de administrador del sistema automáticamente, cuando se cumpla 20 minutos de inactividad con dicha sesión abierta. Cambiar la etiqueta de la pestaña usuarios a pestaña clientes. Implementar una tercera forma de pago: pago mixto, que facilite pagar una parte del pedido de forma anticipada y el excedente a contra entrega en dinero efectivo. Permitir el almacenamiento de las imágenes de los productos con un tamaño máximo de 1mb. El ticket de pago anticipado debe ser generado mediante un archivo con extensión PDF, más no mediante un pop up del explorador. Mostrar el modulo actual en el que se encuentra cliente o el administrador, durante el desplazamiento por los diferentes pestañas o tabs del menú. Definir la categoría inicio como la única categoría padre de las demás categorías de los productos. 203

204 Listar los estados de pedidos y devoluciones en 2 pestañas diferentes para evitar confusiones. En el formulario de registro de nuevo producto, se debe incluir un checkbox para elegir el cobro de IVA de forma opcional. Una vez cerrada la sesión del administrador o del cliente, y posteriormente se regrese a la página inmediamente anterior de la sesión, el sistema no debe permitir la visualización de la información. Dentro del detalle del pedido especificar el total y el total neto de cada producto. Cuando un cliente haya adquirido varios tickets de pago anticipado y realice el pago de un pedido, se debe realizar el descargue del cobro del pedido, empezando desde los tickets de menor valor a los de mayor valor hasta que cubra el total del valor del pedido. 204

205 ANEXO 16. PRUEBAS DE SOFTWARE El presente documento pretende dar a conocer los casos de prueba realizados a Merkonsola, así como las pertinentes pruebas de rendimiento que se llevaron a cabo una vez el software se llevó a su ambiente de producción, para verificar el tiempo de respuesta de la aplicación a las peticiones http solicitadas, así como la adecuada gestión de concurrencia a usuarios en aras de garantizar alta disponibilidad del servicio. 1. CASOS DE PRUEBA Tabla: 67 Caso de Prueba Verificar Ingreso Sesión Nombre Verificar ingreso sesión Propósito Tiene como objetivo verificar el correcto inicio de sesión de los usuarios. Ingresar a página inicio de sesión Acciones Ingresar usuario Ingresar contraseña Oprimir botón enviar Datos Entrada Usuario Contraseña De ser correctos los datos ingresados, el sistema debe Resultados permitir el acceso a la sesión del usuario, de lo contrario Esperados debe mostrar un mensaje que indique los datos no se encuentran registrados. Cuando se ingresaron los datos (usuario y contraseña) de un Resultados usuario al azar para la presente prueba, el sistema permitió Obtenidos el ingreso a la sesión ningún tipo de problema. 205

206 De igual forma cuando se ingresaron datos los datos de un usuario no registrado, el sistema efectivamente indico que los datos ingresados no se encuentran registrados en el sistema. Tabla: 68. Caso de Prueba Ingresar Categoría Nombre Ingresar categoría Propósito Tiene como objetivo ingresar una nueva categoría Acciones Ingresar al BackOffice Ir a categorías Ir a nueva categoría Ingresar datos de la nueva categoría y presionar guardar Datos Entrada Nombre categoría Descripción Categoría padre Resultados El sistema debe incluir una nueva categoría dentro del Esperados listado de categorías. Resultados El sistema registró satisfactoriamente la categoría recién Obtenidos ingresada dentro del listado de categorías. Tabla: 69 Caso de Prueba Editar Categoría Nombre Editar categoría Propósito Tiene como objetivo editar una categoría Acciones Ingresar al BackOffice Ir a categorías Ir a editar categoría 206

207 Ingresar nuevos datos de la categoría y presionar guardar Datos Entrada Nombre categoría Descripción Categoría padre Resultados El sistema debe editar y actualizar los datos de la categoría. Esperados Resultados El sistema actualizo los datos de la categoría editada de Obtenidos forma correcta. Tabla: 70 Caso de Prueba Eliminar Categoria Nombre Eliminar categoría Propósito Tiene como objetivo eliminar una categoría Acciones Ingresar al BackOffice Ir a categorías Ir a eliminar categoría presionar botón eliminar Datos Entrada categoría a eliminar Resultados El sistema debe la categoría del listado de categorías. Esperados Resultados El sistema elimino la categoría exitosamente. Obtenidos Tabla: 71 Caso de Prueba Ingresar Producto Nombre Ingresar producto Propósito Tiene como objetivo ingresar un nuevo producto Acciones Ingresar al BackOffice 207

208 Ir a categorías Ir a nuevo producto Ingresar datos del nuevo producto y presionar guardar Datos Entrada Nombre producto Descripción Categoría Cantidad Fabricante IVA Proveedor Imagen producto Resultados El sistema debe incluir un nuevo producto dentro del listado Esperados de productos. Resultados El sistema registró satisfactoriamente el producto recién Obtenidos ingresado dentro del listado de productos. Tabla: 72 Caso de Prueba Editar Producto Nombre Editar producto Propósito Tiene como objetivo editar un producto Acciones Ingresar al BackOffice Ir a categorías Ir a editar producto Ingresar nuevos datos del producto y presionar guardar Datos Entrada Nombre producto Descripción Categoría Cantidad 208

209 Fabricante IVA Proveedor Imagen producto Resultados El sistema debe editar y actualizar los datos del producto. Esperados Resultados El sistema actualizo los datos del producto editado de forma Obtenidos correcta. Tabla: 73 Caso de Prueba Eliminar Producto Nombre Eliminar producto Propósito Tiene como objetivo eliminar un producto Acciones Ingresar al BackOffice Ir a categorías Ir a eliminar producto presionar botón eliminar Datos Entrada producto a eliminar Resultados El sistema debe retirar el producto del listado de productos. Esperados Resultados El sistema elimino el producto exitosamente. Obtenidos Tabla: 74 Caso de Prueba Ingresar Fabricante Nombre Ingresar fabricante Propósito Tiene como objetivo ingresar un nuevo fabricante Acciones Ingresar al BackOffice 209

210 Ir a categorías Ir a nuevo fabricante Ingresar datos del nuevo fabricante y presionar guardar Datos Entrada Nombre fabricante Descripción Dirección Teléfono Resultados El sistema debe incluir un nuevo fabricante dentro del Esperados listado de fabricantes. Resultados El sistema registró satisfactoriamente el fabricante recién Obtenidos ingresado dentro del listado de fabricantes. Tabla: 75 Caso de Prueba Editar Fabricante Nombre Editar fabricante Propósito Tiene como objetivo editar un fabricante Acciones Ingresar al BackOffice Ir a categorías Ir a editar fabricante Ingresar nuevos datos del fabricante y presionar guardar Datos Entrada Nombre fabricante Descripción Dirección Resultado El sistema debe editar y actualizar los datos del Esperado fabricante. Resultados El sistema actualizo los datos del fabricante editado de Obtenidos forma correcta. 210

211 Tabla: 76 Caso de Prueba Eliminar Fabricante Nombre Eliminar fabricante Propósito Tiene como objetivo eliminar un fabricante Acciones Ingresar al BackOffice Ir a categorías Ir a eliminar fabricante presionar botón eliminar Datos Entrada fabricante a eliminar Resultados El sistema debe retirar el fabricante del listado de Esperados fabricantes. Resultados El sistema elimino el fabricante exitosamente. Obtenidos Tabla: 77 Caso de Prueba Ingresar Proveedor Nombre Ingresar proveedor Propósito Tiene como objetivo ingresar un nuevo proveedor Acciones Ingresar al BackOffice Ir a categorías Ir a nuevo proveedor Ingresar datos del nuevo proveedor y presionar guardar Datos Entrada Nombre proveedor Descripción Dirección Teléfono Resultados El sistema debe incluir un nuevo proveedor dentro del Esperados listado de proveedores. Resultados El sistema registró satisfactoriamente el proveedor recién 211

212 Obtenidos ingresado del listado de proveedores. Tabla: 78 Caso de Prueba Editar Proveedor Nombre Editar proveedor Propósito Tiene como objetivo editar un proveedor Acciones Ingresar al BackOffice Ir a categorías Ir a editar proveedor Ingresar nuevos datos del proveedor y presionar guardar Datos Entrada Nombre proveedor Descripción Dirección Teléfono Resultados El sistema debe editar y actualizar los datos del proveedor. Esperados Resultados El sistema actualizo los datos del proveedor editado de Obtenidos forma correcta. Tabla: 79 Caso de Prueba Eliminar Proveedor Nombre Eliminar proveedor Propósito Tiene como objetivo eliminar un proveedor Acciones Ingresar al BackOffice Ir a categorías Ir a eliminar proveedor presionar botón eliminar Datos Entrada proveedor a eliminar 212

213 Resultados El sistema debe retirar el proveedor del listado de Esperados proveedores. Resultados El sistema elimino el proveedor exitosamente. Obtenidos Tabla: 80 Caso de Prueba ingresar Cliente Nombre Ingresar cliente Propósito Tiene como objetivo ingresar un nuevo cliente Acciones Ingresar al BackOffice Ir a clientes Ir a nuevo cliente Ingresar datos del nuevo cliente y presionar guardar Datos Entrada Primer Nombre Primer Apellido Segundo Apellido Número de Identificación Dirección Teléfono Fijo Resultados El sistema debe incluir un nuevo cliente dentro del listado Esperados de clientes Resultados El sistema registró satisfactoriamente el cliente recién Obtenidos ingresado dentro del listado de clientes. Tabla: 81 Caso de Prueba Editar Cliente Nombre Editar cliente Propósito Tiene como objetivo editar un cliente 213

214 Acciones Ingresar al BackOffice Ir a clientes Ir a editar cliente Ingresar nuevos datos del cliente y presionar guardar Datos Entrada Primer Nombre Segundo Nombre Primer Apellido Segundo Apellido Tipo de Identificación Número de Identificación Dirección Teléfono Móvil Teléfono Fijo Resultados El sistema debe editar y actualizar los datos del cliente. Esperados Resultados El sistema actualizo los datos del cliente editado de forma Obtenidos correcta. Tabla: 82 Caso de Prueba Eliminar Cliente Nombre Eliminar cliente Propósito Tiene como objetivo eliminar un cliente Acciones Ingresar al BackOffice Ir a clientes Ir a eliminar cliente presionar botón eliminar Datos Entrada proveedor a eliminar Resultados El sistema debe retirar el cliente del listado de clientes. 214

215 Esperados Resultados El sistema elimino el cliente exitosamente. Obtenidos Tabla: 83 Caso de Prueba Efectuar Pago Nombre Efectuar pago Propósito Tiene como objetivo efectuar el pago de un pedido Acciones Ingresar al BackOffice Ir a pago Ir a efectuar pago Seleccionar pedido y elegir forma de pago Datos Entrada Identificación cliente Número de Pedido Forma de pago Resultados El sistema debe efectuar el pago del pedido correspondiente Esperados a través de la forma de pago indicada. Resultados El sistema efectuó satisfactoriamente el pago del pedido Obtenidos solicitado por el usuario. Tabla: 84 Caso de Prueba Generar Ticket Pago Anticipado Nombre Generar Ticket pago anticipado Propósito Tiene como objetivo generar los tickets de pago anticipado Acciones Ingresar al BackOffice Ir a tickets Ingresar id cliente y generar ticket Datos Entrada Identificación cliente 215

216 Monto a adquirir Resultados El sistema debe generar un ticket de pago anticipado que Esperados confirme el monto de dinero adquirido por el usuario. Resultados El sistema genero satisfactoriamente el ticket de pago Obtenidos anticipado. Tabla: 85 Caso de Prueba Imprimir Ticket Pago Anticipado Nombre Imprimir Ticket pago anticipado Propósito Tiene como objetivo imprimir los tickets de pago anticipado Acciones Ingresar al BackOffice Ir a tickets Imprimir ticket Datos Entrada Identificación cliente Monto a adquirir Resultados El sistema debe imprimir un ticket de pago anticipado que Esperados confirme el monto de dinero adquirido por el usuario. Resultados El sistema imprimió satisfactoriamente el ticket de pago Obtenidos anticipado. 2. PRUEBAS DE RENDIMIENTO Las pruebas de rendimiento se diseñaron y aplicaron de tal manera que simularan condiciones reales y variables a las cuales podría estar expuesta la aplicación. Por ello mediante la herramienta JMETER se evaluaron las prestaciones de Merkonsola frente a condiciones de baja, media y alta carga transaccional, en aras de verificar el porcentaje de carga, el porcentaje de memoria usada, la salud y el 216

217 grado de aceptación de carga del servidor. De igual manera se aplicaron pruebas de stress, en las que se duplicaron constantemente el número de usuarios concurrentes hasta verificar su límite de aceptación. En conclusión se hace énfasis en que Merkonsola cumple a cabalidad con las expectativas y requisitos planteados por el cliente y el grupo de desarrollo, ya que su comportamiento refleja el cumplimiento de factores como: la escalabilidad de usuarios, un óptimo tiempo de respuesta, el adecuado consumo de recursos y la garantía de brindar una alta disponibilidad del servicio, tal como lo muestran las siguientes pruebas efectuadas. 2.1 Prueba de Carga Baja La tabla 201 muestra las variables que se definieron para la presente prueba de carga baja. Tabla: 86 Variables Prueba de Carga Baja Variable Valor Usuarios (número de hilos) 15 Periodo de subida 2 Servidor Puerto 80 Método GET Retardo 5000 milisegundos Numero de muestras 801 Ultima muestra 216 Media 312 Desviación 246 Resultado Carga Monitor Healthy 217

218 Figura: 35 Grupo de Hilos Figura: 36 Petición HTTP Figura: 37 Temporizador Constante 218

219 Figura: 38 Resultados del Monitor Figura: 39 Resultados del Monitor 219

220 Figura: 40 Resultados en Árbol Los resultados obtenidos en la prueba de carga baja demuestran un funcionamiento normal conforme a las bajas exigencias de carga en cuanto a peticiones http y stress se refieren, como lo muestran las anteriores figuras. 2.2 Prueba de Carga Media La tabla 202 muestra las variables que se definieron para la presente prueba de carga media. Tabla: 87 Variables Prueba de Carga Media Variable Valor Usuarios (número de hilos) 100 Periodo de subida 2 Servidor Puerto 80 Método GET Retardo 3000 milisegundos 220

221 Numero de muestras 903 Ultima muestra 235 Media 315 Desviación 302 Resultado Carga Monitor Healthy Figura: 41 Grupo de Hilos Figura: 42 Petición HTTP 221

222 Figura: 43 Temporizador Constante Figura: 44 Resultados del Monitor Los resultados obtenidos en la prueba de carga media demuestran un funcionamiento óptimo cuando se incrementa el número de usuarios y peticiones http. Acorde a las anteriores figuras se puede deducir que a pesar de dicho incremento, el software presenta un tiempo de respuesta aceptable y un rendimiento tolerable en cuanto a los recursos computacionales se refiere. 222