Sistema de facturación Web para la Cooperativa de Estudiantes COOPESING UD

Texto completo

(1)SISTEMA DE FACTURACIÓN WEB PARA LA COOPERATIVA DE ESTUDIANTES COOPESING-UD. BRIAN CAMILO PIRAGAUTA MESA OSCAR FERNEY CORREA TARAZONA. UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS” BOGOTÁ D.C. COLOMBIA 2018.

(2) SISTEMA DE FACTURACIÓN WEB PARA LA COOPERATIVA DE ESTUDIANTES COOPESING-UD. BRIAN CAMILO PIRAGAUTA MESA 20161678024 OSCAR FERNEY CORREA TARAZONA 20152678112. PROYECTO DE GRADO PRESENTADO COMO REQUISITO PARA OPTAR AL TÍTULO DE INGENIERO EN TELEMÁTICA.. TUTOR-DIRECTOR: NORBERTO NOVOA TORRES. UNIVERSIDAD DISTRITAL “FRANCISCO JOSÉ DE CALDAS” BOGOTÁ D.C. COLOMBIA 2018.

(3) Nota de Aceptación: ____________________________ ____________________________ ____________________________ ____________________________. Tutor. _______________________________ Ing. Norberto Novoa. Presidente Jurado. ______________________________ Ing. Alberto Vanegas. ______________________________. Bogotá D.C, Abril de 2018.

(4) AGRADECIMIENTOS Este proyecto no habría sido posible sin la influencia de muchas personas a las cuales agradezco profundamente por brindarme todo su apoyo en mi proceso académico y en la vida misma. Principalmente agradezco a mi familia que siempre ha estado a mi lado, y han aportado al proceso de formación como estudiante y como una persona íntegra. A la universidad Distrital Francisco José de Caldas por darme la oportunidad de estudiar y ofrecerme las mejores herramientas para adquirir los conocimientos que hacen parte de la vida profesional. A los docentes, que con su paciencia y dedicación, compartieron sus conocimientos para que mi formación profesional y como persona fuera satisfactoria. A mis compañeros de estudio, que me brindaron su ayuda hasta culminar con los objetivos del programa académico, especialmente a Camilo Piragauta, mi compañero de toda la carrera y trabajo de grado, que siempre tuvo la mejor actitud para aclarar las dudas que se presentaban durante nuestra formación. Por último, a todos mis compañeros que iniciaron este proceso conmigo y que también aportaron con sus conocimientos y compartieron su confianza, dentro y fuera de la universidad.. Con todo mi cariño y mi amor para la persona que hace todo en la vida para que yo pueda lograr mis sueños, por motivarme y darme la mano cuando parece que el camino termina, a ella por siempre mi corazón y mi agradecimiento, Mamá. A los profesores que se esmeraron en formar futuros ingenieros. A mis compañeros que siempre estuvieron conmigo en este proceso de formación, y que compartieron de igual manera su conocimiento y su paciencia. A la universidad Distrital Francisco José de Caldas, por darme la oportunidad de ser uno más de sus estudiantes y poder tener una educación de calidad en una de las mejores universidades de nuestro país..

(5) Tabla de contenido AGRADECIMIENTOS ......................................................................................................................4 RESUMEN..........................................................................................................................................8 ABSTRACT ........................................................................................................................................9 INTRODUCCIÓN ........................................................................................................................... 10 1.1 PLANTEAMIENTO DEL PROBLEMA .............................................................................. 11 1.2 JUSTIFICACIÓN .................................................................................................................. 12 1.5 OBJETIVOS.......................................................................................................................... 13 1.5.1 Objetivo General ........................................................................................................... 13 1.5.2 Objetivos específicos ................................................................................................... 13 1.6 ALCANCE ............................................................................................................................. 14 1.6.1. A nivel funcional ..................................................................................................... 14. 1.6.1.1 Modulo configuración ............................................................................................... 14 1.6.1.2 Modulo productos ..................................................................................................... 14 1.6.1.3 Modulo registro empleados ..................................................................................... 15 1.6.1.4 Modulo inventario ...................................................................................................... 15 1.6.1.5 Modulo ventas ........................................................................................................... 15 1.6.1.6 Modulo informes ........................................................................................................ 15 1.6.1.7 Modulo Pedidos......................................................................................................... 16 1.7 DELIMITACIONES .............................................................................................................. 16 1.7.1 Delimitación temporal .................................................................................................. 16 1.7.2 Delimitación geográfica ............................................................................................... 16 1.7.3 Delimitación técnica ..................................................................................................... 16 1.8 FACTIBILIDAD ..................................................................................................................... 17 1.8.1 Factibilidad Técnica ..................................................................................................... 17 1.8.2. Factibilidad Económica.......................................................................................... 18. MARCO DE REFERENCIA ...................................................................................................... 20 2.1 Marco Teórico .................................................................................................................. 20 Un sistema de control de versiones más fiable y eficiente .............................................. 29 Elementos de trabajo ............................................................................................................. 29 Informes de gestión y otras características ........................................................................ 30.

(6) IMPLEMENTACIÓN METODOLOGIA XP ............................................................................. 36 3 .1 PLANIFICACIÓN ............................................................................................................ 36 3.1.1 Historias de usuario ..................................................................................................... 36 3.1.2 División en iteraciones................................................................................................. 37 3.1.3 Plan de entregas .......................................................................................................... 38 3 .2 DISEÑO ........................................................................................................................... 39 3.2.1 Simplicidad .................................................................................................................... 39 3.2.2 Metáfora del sistema.................................................................................................... 39 3.2.3 Tarjetas CRC ................................................................................................................ 40 3.2.4 Solución Rápida ........................................................................................................... 42 3.2.5 No adicione funcionalidad antes de tiempo ............................................................. 43 3.2.6 Refactorización ............................................................................................................. 43 3 .3 DESARROLLO ............................................................................................................... 44 3.3.1 Cliente siempre disponible .......................................................................................... 44 3.3.2 Código siguiendo estándares. .................................................................................... 44 3.3.3 Desarrollar unidad de pruebas primero .................................................................... 45 3.3.4 Desarrollo de código en parejas ................................................................................ 46 3.3.5 Integraciones frecuentes y en parejas ...................................................................... 46 3.3.6 Propiedad colectiva de código ................................................................................... 47 3.3.7 Optimizaciones para el final........................................................................................ 47 3 .4 PRUEBAS ........................................................................................................................ 48 3.4.1 Pruebas de aceptación ................................................................................................ 48 3.5 Cronograma ...................................................................................................................... 63 CONCLUSIONES Y RECOMENDACIONES ............................................................................ 65 4.1 CONCLUSIONES .................................................................................................................... 65 4.2 RECOMENDACIONES........................................................................................................... 66 BIBLIOGRAFIA ............................................................................................................................... 67.

(7) Lista de tablas Tabla 1 Recursos Humanos ............................................................................................ 19 Tabla 2 Recursos Técnicos ............................................................................................. 19 Tabla 3 Costo Total ......................................................................................................... 19 Tabla 4 Diferencia entre LAN y WLAN ............................................................................. 35 Tabla 5 Historias de Usuario - Prioridad .......................................................................... 36 Tabla 6 Historias usuario por Iteración............................................................................. 37 Tabla 7 Historias de usuario por módulo.......................................................................... 38.

(8) RESUMEN La cooperativa Coopesing UD es una organización sin ánimo de lucro, creada para beneficiar en primera instancia a los estudiantes y egresados de la universidad Distrital Francisco José de Caldas – facultad ingeniería en la ciudad de Bogotá-Colombia, ofreciendo alimentos no perecederos a toda la comunidad universitaria. Coopesing UD se basa en una economía solidaria en donde se encuentran formas alternativas de buscar economía, basadas en la solidaridad y el trabajo. Dicho esto, es importante tener los controles necesarios para que la economía solidaria fluya y no se vean afectados los ingresos para cada uno de los colaboradores, por lo cual se hace necesario implementar herramientas de software que se encarguen de la gestión en los turnos de trabajo que en la cooperativa se manejan y de las ventas que cada integrante de la cooperativa realice en su respectiva jornada laboral; así como del inventario en los productos que se comercializan. Con el fin de satisfacer las necesidades de la Cooperativa, es necesario implementar metodologías agiles que permitan el flujo en el desarrollo del sistema, la metodología Extreme Programing (XP) permite un desarrollo rápido de proyectos pequeños y medianos, como lo es en el caso de este proyecto..

(9) ABSTRACT The cooperative Coopesing UD is a non-profit organization, created to benefit in the first instance the students and graduates of the Francisco José de Caldas District University in the city of Bogotá-Colombia, offering non-perishable food to the entire university community. Coopesing UD is based on a solidary economy where alternative ways of looking for an economy are sought, based on solidarity and work. That said, it is important to have the necessary controls so that the solidarity economy flows and the income for each one of the collaborators is not affected, for which it is necessary to implement software tools that are in charge of the management in the work shifts that in the cooperative they are implemented and of the sales that each member of the cooperative makes in their respective working day; as well as the inventory in the products that are commercialized. In order to meet the needs of the Cooperative, it is necessary to implement agile methodologies that allow the flow in the development of the system, the Extreme Programing (XP) methodology allows a rapid development of small and medium projects, as it is in the case of this project..

(10) INTRODUCCIÓN El presente documento describe el proceso de elaboración del sistema de facturación web para la cooperativa de estudiantes coopesing-ud siguiendo los lineamientos de la metodología de desarrollo Extreme Programing. En la última década los sistemas informáticos formaron parte esencial de las organizaciones en su plan de desarrollo, debido a que la información tomo un gran valor como el activo más importante de una compañía. En la actualidad las organizaciones buscan herramientas que permitan obtener ventajas competitivas, sin embargo, las empresas desarrolladoras de software se orientan a ofrecer dichos sistemas a grandes organizaciones, por lo cual las microempresas y pequeños negocios ya se encuentran en desventaja al no tener poder adquisitivo para implementar dichos softwares..

(11) 1.1 PLANTEAMIENTO DEL PROBLEMA. Coopesing tiene el sistema de ventas apoyado con una caja registradora hace 15 años, registrando las ventas que se realizan en la caja, generando informes por cierre de turno en los cuales se indica cual fue el monto vendido por el cajero en turno y cuál es la venta total que se tiene del día; estos informes se generan en tirillas que imprime la caja.. Coopesing no puede llevar un adecuado control del inventario, debido a que la caja registradora no genera informes por producto; además tampoco tiene un control de los empleados que usaron la caja. Es importante mencionar que no se cuenta con una interfaz gráfica para realizar las ventas, se vende mediante códigos que se configuran en la caja. El control de la facturación por transacción es nulo y el inventario se hace totalmente manual contando diariamente los productos en existencia.. Con la implementación de Turing el registro de las ventas se verá optimizado para el cajero, ya que tendrá una interfaz gráfica en la cual puede realizar la búsqueda de los productos para realizar la venta, además los informes se pueden generar en un módulo dedicado específicamente a esta labor, ampliando la cantidad de informes que se pueden generar; junto con el control de inventario, que en este momento se lleva a cabo de una forma manual.. El registro de empleados que inician y terminan turno se registra en el sistema, permitiendo un mejor seguimiento. Además, la opción de ofrecer los productos mediante una red inalámbrica privada, con la finalidad de incrementar la eficiencia de sus procesos de ventas..

(12) 1.2 JUSTIFICACIÓN La razón para crear el sistema de facturación web para la cooperativa de estudiantes coopesing-ud nace en la necesidad de la organización de llevar un control de la información de sus productos, gestionando principalmente el inventario, la facturación de las ventas y las jornadas laborales de cada uno de los colaboradores, teniendo en cuenta que la cooperativa se rige por una economía solidaria, en donde cada uno de los integrantes aporta en el crecimiento del negocio con su propio trabajo y en la aportación de nuevas ideas. Considerando que en el mercado ya existen herramientas que ofrecen estos servicios, para las micro empresas es muy difícil poder implementarlos por temas económicos, ya que los costos de sus licencias e instalación son muy elevados. Es por esto que se realizará este software, el cual se encargará de satisfacer esas necesidades aportando en el desarrollo de estas organizaciones que a nivel nacional componen un gran porcentaje, pero que al día de hoy no cuentan con herramientas que sistematicen la información relevante con la cual puedan realizar análisis de ventas y de esta manera tener una proyección económica..

(13) 1.5 OBJETIVOS 1.5.1 Objetivo General. Se define el objetivo general en base a las necesidades y restricciones conocidas, referentes al sistema a desarrollar. •. Implementar un sistema que permita la gestión de las ventas e inventarios, así como el registro de los empleados y la generación de informes financieros para la cooperativa Coopesing UD.. 1.5.2 Objetivos específicos. •. Desarrollar la arquitectura a nivel de base de datos y desarrollo que sirva como base para la implementación del sistema de ventas.. •. Desarrollar un sistema con registro y control de usuarios y roles, junto con la configuración de los permisos que se tienen dentro de la aplicación.. •. Establecer la comunicación entre la comunidad universitaria y el sistema, mediante el módulo de pedidos a través de una red inalámbrica disponible para realizar compras.. •. Realizar el registro de productos, ventas, inventario y entradas de usuarios, incluyendo el cálculo de cada uno de los respectivos procesos de facturación y stock..

(14) 1.6 ALCANCE. El proyecto consiste en desarrollar e implementar el sistema denominado Turing, bajo la metodología de implementación del desarrollador, con resultados medibles a corto plazo y comprobables en cada una de las etapas del proyecto y basados en el esquema Express.. 1.6.1. A nivel funcional. El sistema contara con dos interfaces principales, una exclusivamente para realizar las ventas, y la otra para la administración del mismo. Además, se podrán configurar roles los cuales tienen permisos solamente a partes específicas de los módulos de la aplicación.. 1.6.1.1 Modulo configuración. En este módulo se administrarán y configurarán las diferentes opciones de autenticación de usuarios, roles y permisos dentro de los componentes del sistema en general.. 1.6.1.2 Modulo productos. Este módulo permite el almacenamiento y administración de los productos que ofrece Coopesing-UD..

(15) 1.6.1.3 Modulo registro empleados. Este módulo gestiona las jornadas laborales de los colaboradores, almacenando un registro de las entradas y salidas de turno de cada uno de ellos.. 1.6.1.4 Modulo inventario. Mediante el módulo de inventarios, se pueden controlar las entradas y salidas de los productos que se encuentran almacenados en la cooperativa, con el fin de tener un control del stock dependiendo la demanda de cada uno de estos.. 1.6.1.5 Modulo ventas. El módulo de ventas permitirá visualizar en la caja los productos con sus respectivos precios y cantidades que se facturan y las cuales afectará el inventario.. 1.6.1.6 Modulo informes. En el módulo de informes se mostrarán los registros almacenados de los módulos anteriores, como son:. Ventas por empleados. Cantidades Cierre Parcial Cierre Total..

(16) 1.6.1.7 Modulo Pedidos. El módulo de pedidos va dirigido principalmente a los clientes de la cooperativa para realizar compras a través de un dispositivo móvil conectado a la red inalámbrica disponible por Coopesing.. 1.7 DELIMITACIONES 1.7.1 Delimitación temporal. El proyecto está destinado a desarrollarse en un periodo de tiempo comprendido entre las fechas del 15 de septiembre de 2017 al 15 de febrero de 2018 (Seis meses). 1.7.2 Delimitación geográfica. Este proyecto será desarrollado únicamente en la cooperativa Coopesing-UD que se encuentra ubicada en el edificio Sabio caldas de la sede de ingeniería de la universidad distrital Francisco José de Caldas.. 1.7.3 Delimitación técnica. Las tecnologías sobre las que se desarrollará este proyecto son: ● Sistema operativo: Windows ● Motor de Base de datos: SQL Server 2016 ● IDE: Microsoft Visual Studio 2015.

(17) 1.8 FACTIBILIDAD. 1.8.1 Factibilidad Técnica. Las características esenciales de los dispositivos con los cuales se debe hacer uso de nuestro sistema de información, deberán poseer la mayoría de las tecnologías utilizadas dentro del desarrollo del sistema. El proyecto es factible porque cuenta con las siguientes herramientas: Características mínimas del computador, para que se pueda dar uso al sistema de información: ● Procesador de 3.0 GHz de velocidad. ● Memoria RAM de 4.00 GB ● Espacio en disco de 512 Mb ● Sistema Operativo Windows (XP o superior). Recursos Adicionales: •. Microsoft Visual Studio 2015.. •. Sistema gestor de Bases de datos sql-server-2016.. •. Impresora de recibos.. •. Router.. •. Caja registradora.. •. Escáner código de barras.. •. Caja registradora.

(18) 1.8.2. Factibilidad Económica. Para la financiación del proyecto se determinó en conjunto con coopesing que tanto los ejecutores como el mismo coopesing destinarán parte de sus recursos para el avance y éxito del proyecto.. Coopesing destinará 700.000 pesos colombianos como pago por la labor de los ejecutores, además de la infraestructura tecnológica, que incluye computador de escritorio, pantalla, teclado, mouse, lector de código de barras, caja para guardar el dinero y router. Los gestores aportaran todo el capital humano para el análisis, desarrollo, pruebas, capacitación e implementación del sistema dentro de las instalaciones de Coopesing. En el estudio de la Factibilidad Económica, determinamos el presupuesto de costos de los recursos técnicos, humanos y materiales tanto para el desarrollo como para la implantación del Sistema.. Además, nos ayudará a realizar el análisis costo-beneficio de nuestro sistema, el mismo que nos permitirá determinar si es factible a desarrollar económicamente el proyecto.. A continuación, se describe los costos del recurso necesario para el desarrollo de nuestro Sistema de Información:.

(19) Tipo. Descripción. Tutor 1. ValorHora $ 40.000. Asesorías para la realización del proyecto, referente a la metodología. Desarrolladores Dos programadores que $ 20.000 realicen la implementación de la solución. Total Recursos Humanos. Cantidad 200. Total $ 8.000.000. 8 horas $ 5.120.000 semanales $ 13.120.000. Tabla 1 Recursos Humanos. Los recursos técnicos serán solventados por la cooperativa, teniendo en cuenta que ya algunos de estos forman parte del inventario general, otros como el router deberán ser adquiridos. Recurso. Descripción. Valor Unitario Computadores Equipo de cómputo para $ 1.300.000 (Servidor el alojamiento del sitio en clientes) el servidor IIS, el cual funcionará como servidor. Lector Código Lector codigo de barras, $ 70.000 de barras para capturar la información de los productos ofrecidos rapidamente. Router Wireless Dispositivo que tendrá $ 82.000 N300 D-link Dir- disponible red Wi Fi, por la 615 cual funcionará el módulo de pedidos.. Cantidad. Total. 1. $ 1.300.000. 1. $ 70.000. 1. $ 82.000. Total Recursos Técnicos. $ 1.452.000 Tabla 2 Recursos Técnicos. Recurso Total Recursos Humanos Total Recursos Técnicos Total Otros recursos TOTAL COSTO. Valor $13.120.000 $ 1.452.000 $ 100.000 $14.672.000. Tabla 3 Costo Total.

(20) MARCO DE REFERENCIA 2.1 Marco Teórico. HTML: HTML es un lenguaje que hace posible presentar información (por ejemplo, investigaciones científicas) en Internet. Lo que ves al visualizar una página en Internet es la interpretación que hace el navegador del código HTML. Para ver el código HTML de una página sólo tienes que pinchar en la opción "Ver" de la barra de menús y elegir "Código fuente" (en Internet Explorer). HTML. es. la. abreviatura. de. "Hypertext. Mark-up. Language",. es. decir,. "Lenguaje de marcado hipertextual": •. Hiper es lo contrario de lineal. En los buenos viejos tiempos -cuando un ratón era un animal que perseguía un gato- los programas de ordenador se ejecutaban de forma lineal: cuando el programa había ejecutado una acción seguía hasta la siguiente línea, y después de ésta a la siguiente, y a la siguiente,... HTML, sin embargo, es diferente: se puede ir donde uno quiera cuando uno quiera. Por ejemplo, no es necesario visitar MSN.com antes de visitar HTML.net.. •. Texto se explica por sí solo.. •. Marcado es lo que haces con el texto. Se marca el texto del mismo modo que en un programa de edición de textos con encabezados, viñetas, negrita, etc.. •. Lenguaje es lo que es HTML. Este lenguaje hace uso de muchos términos en inglés.1. 1 ANDREAS ASTRUP. HTML.net .Tutorial HTML-Leccion2 [en línea] <http://bit.ly/1tELdYK> /[Consultado el 30/11/2017]..

(21) CSS: CSS es el acrónimo de CascadingStyle Sheets (es decir, hojas de estilo en cascada). CSS es un lenguaje de estilo que define la presentación de los documentos HTML. Por ejemplo, CSS abarca cuestiones relativas a fuentes, colores, márgenes, líneas, altura, anchura, imágenes de fondo, posicionamiento avanzado y muchos otros temas. Es posible usar HTML, o incluso abusar del mismo, para añadir formato a los sitios web. Sin embargo, CSS ofrece más opciones y es más preciso y sofisticado. CSS está soportado por todos los navegadores hoy día. La diferencia que hay ente HTML y CSS es que HTML se usa para estructurar el contenido; CSS se usa para formatear el contenido previamente estructurado. CSS fue toda una revolución en el mundo del diseño web. Entre los beneficios concretos de CSS encontramos: • • • •. 2. Control de la presentación de muchos documentos desde una única hoja de estilo; Control más preciso de la presentación; Aplicación de diferentes presentaciones a diferentes tipos de medios (pantalla, impresión, etc.) Numerosas técnicas avanzadas y sofisticadas2.. ANDREAS ASTRUP. HTML.net .Tutorial CSS [en línea] < http://bit.ly/VI5ZsF>/[Consultado el 30/07/2014]..

(22) FRAMEWORK: FrameWork es un concepto sumamente genérico, se refiere a “ambiente de trabajo, y ejecución”, por ejemplo “.Net” es considerado un “FrameWork” para desarrollar aplicaciones (Aplicaciones sobre Windows). En general los FrameWork son soluciones completas que contemplan herramientas de apoyo a la construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de ejecución).3 ASP.NET Es un framework para aplicaciones web desarrollado y comercializado por Microsoft. Es usado por programadores y diseñadores para construir sitios web dinámicos, aplicaciones web y servicios web XML. Apareció en enero de 2002 con la versión 1.0 del .NET Framework, y es la tecnología sucesora de la tecnología Active Server Pages (ASP). ASP.NET está construido sobre el Common Language Runtime, permitiendo a los programadores escribir código ASP.NET usando cualquier lenguaje admitido por el .NET Framework. 4. Ilustración 1 ASP framework. 3. SOA agenda. Que son los frameworks [en línea] <http://bit.ly/Too7ai>/[Consultado el 30/07/2014]. ASP.NET [en línea] <http://goo.gl/R2s4l>/[Consultado el 01/09/2014].. 4.

(23) PROCEDIMIENTOS ALMACENADOS (MOTOR DE BASE DE DATOS) Un procedimiento almacenado de SQL Server es un grupo de una o varias instrucciones Transact-SQL o una referencia a un método de Common Runtime Language (CLR) de Microsoft .NET Framework. Los procedimientos se asemejan a las construcciones de otros lenguajes de programación, porque pueden: •. Aceptar parámetros de entrada y devolver varios valores en forma de parámetros de salida al programa que realiza la llamada.. •. Contener instrucciones de programación que realicen operaciones en la base. de. datos. Entre. otras,. pueden. contener. llamadas. a. otros. procedimientos. •. Devolver un valor de estado a un programa que realiza una llamada para indicar si la operación se ha realizado correctamente o se han producido errores, y el motivo de estos. 5. COMMON LANGUAGE RUNTIME (CLR) .NET Framework proporciona un entorno en tiempo de ejecución denominado Common Language Runtime, que ejecuta el código y proporciona servicios que facilitan el proceso de desarrollo.. Los compiladores y las herramientas exponen la funcionalidad de Common Language Runtime y permiten escribir código con las ventajas que proporciona. 5. Microsoft Developer Network. Procedimientos almacenados [en línea] <http://bit.ly/1rZEYO4/>/ [Consultado el 01/10/2017]. 6. Microsoft Developer Network. Common Language Runtime (CLR) [en línea]. <http://bit.ly/1q0TVjE>/[Consultado el 01/10/2017].

(24) este entorno de ejecución administrado. El código desarrollado con un compilador de lenguaje orientado al tiempo de ejecución se denomina código administrado. 6. Ilustración 2 Common Language Runtime. INTERNET INFORMATION SERVICES (IIS) Internet Information Services o IIS1 es un servidor web y un conjunto de servicios para. el sistema. operativo Microsoft. Windows.. Los. servicios. que. ofrece. son: FTP, SMTP, NNTP y HTTP/HTTPS. Este servicio convierte a una PC en un servidor web para Internet o una intranet, es decir que en las computadoras que tienen este servicio instalado se pueden publicar páginas web tanto local como remotamente. Se basa en varios módulos que le dan capacidad para procesar distintos tipos de páginas. Por ejemplo, Microsoft incluye los de Active Server Pages (ASP) y ASP.NET. También pueden ser incluidos los de otros fabricantes, como PHP3. 7. 7. Internet Information Services(IIS). [en línea] <http://bit.ly/1trQdSv>/[Consultado el 30/11/2017].

(25) METODOLOGÍA EXTREME PROGRAMMING La metodología eXtreme Programming (XP) pretende que el desarrollo de un proyecto de software sea un desarrollo ágil, disciplinado, y aportando soluciones sencillas. XP tiene un enfoque adaptativo en el que la planificación del proyecto progresa a medida que surgen cambios.. Los principios de actuación claves alrededor de los cuales se fundamenta la metodología XP consisten en: • •. Acortar los ciclos de desarrollo. Involucrar al cliente desde el principio hasta el final de cada ciclo.. Las técnicas de trabajo que proporciona XP consiguen minimizar el impacto que los cambios suponen en un proyecto de desarrollo de software.. Ilustración 3 Fases metodología XP. La clave de éxito de esta metodología es la importancia que le dan a las relaciones entre los grupos de desarrollo, promoviendo el trabajo en equipo..

(26) El aprendizaje de los desarrolladores es algo necesario para tener un grupo bien instruido. Otro aspecto que saca adelante a la programación extrema es la realimentación continua que el cliente provee al proyecto. 8 Roles Definidos Por La Metodología Xp Programador: El programador escribe las pruebas unitarias y produce el código del sistema. Cliente: En XP el cliente juega un papel protagónico, es parte del equipo, se encarga de escribir las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio. Gestor (Big boss): Es el encargado de la coordinación, debe ser el vínculo entre clientes y programadores, también crea un ambiente que facilite las actividades del equipo de desarrollo. Encargado de pruebas (Tester): Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de seguimiento (Tracker): Realiza el seguimiento de las estimaciones realizadas y el tiempo que efectivamente se ha dedicado para mejorar futuras estimaciones. Analiza el avance de cada iteración y retroalimenta al grupo.. 8. Metodología Extreme Programming. [en línea] < https://goo.gl/454NJA >/[Consultado el 02/02/2018].

(27) Entrenador (Coach): Guía y vigila que se sigan correctamente las prácticas de XP, es responsable del proceso global. Consultor: Especialista en algún tema específico, externo al grupo de trabajo.. Fases de la metodología XP 1. Planificación a). Se redactan las historias de usuarios.. b). Se crea un plan de entregas.. c). Se controla la velocidad del proyecto.. d). Se divide el proyecto en iteraciones.. e). Al comienzo de cada iteración se traza el plan de iteración. f). Se rota al personal. g). Cada día se convoca una reunión de seguimiento. h). Corregir la propia metodología XP cuando falla. 2. Diseño a). Realizar las cosas de la manera más sencilla. b). Coherencia de los nombres de todo lo que se va a implementar. c). Usar tarjetas CRC. En esta tarjeta se registra los nombres de las clases, sus responsabilidades y con qué otras clases colaboran. d). Soluciones puntuales para reducir riesgos. e). No se añadirá funcionalidad en las primeras etapas. f). Reaprovechar cuando sea posible.

(28) 3. Desarrollo a). El cliente está siempre disponible. b). Se debe escribir código de acuerdo a los estándares. c). Desarrollar la unidad de pruebas primero. d). Todo el código debe programarse por parejas. e) f). Sólo una pareja se encargará de integrar el código Actualizar las versiones de los módulos lo más rápido posible. g). Todo el código es común a todos. h). Dejar las optimizaciones para el final. 4. Pruebas a). Todo el código debe ir acompañado de su unidad de pruebas. b). Todo el código debe pasar las unidades de pruebas antes de ser implantado. c). Crear una unidad de pruebas para protegerse del mismo. d). Se deben ejecutar pruebas de aceptación a menudo y publicar los resultados. e). Las pruebas unitarias 9. TEAM FOUNDATION SERVER (TFS). Team Foundation Server no es símplemente una herramienta para el control de versiones de código fuente: su alcance va mucho más allá, facilitando la gestión completa del ciclo de vida de la aplicación, desde la fase de diseño hasta las pruebas, pasando por la integración continua o la calidad del código. TFS incorpora varios sistemas integrados: por un lado una base de datos en SQL Server que contiene no sólo el código fuente de nuestras aplicaciones sino los 9. Fases de la metodología XP . [en línea] < https://goo.gl/eoqhPR >/[Consultado el 02/02/2018].

(29) elementos de trabajo que posibilitan el seguimiento del desarrollo; los datos se integran en un Data Warehouse de SQL Server Analysis Services que proporciona información sobre el estado del proyecto mediante informes en Reporting Services o Excel; el motor de compilación Team Build permite la compilación desatendida de los proyectos y genera informes de calidad de la compilación; y todo. ello. se. puede. integrar. en. portales. de. colaboración. de Microsoft. Sharepointpara que todo el equipo pueda compartir información, documentos o calendarios asociados al proyecto. El acceso a TFS se realiza desde el add-in Team Explorer incluido en Visual Studio, pero además es posible acceder a los datos a traves de un web propio o a través de la integración con Excel y Microsoft Project. Team Foundation Server es la herramienta definitiva para la gestión completa de todos los aspectos de una aplicación de cualquier tamaño.. Un sistema de control de versiones más fiable y eficiente El código fuente se guarda en una base de datos SQL Server, lo que garantiza su fiabilidad y seguridad. El sistema de versionado de TFS permite la etiquetación del código y la división en ramas que más tarde pueden combinarse de nuevo. Una herramienta de combinación visual facilita la resolución de conflictos en el código.. Elementos de trabajo El sistema de gestión de los proyectos está basado en los elementos de trabajo. Mediante la creación y actualización de diversos tipos de elementos de trabajo (Tarea, Error, Caso de uso, Prueba, Requisito, etc), podrá obtener informes permanentemente actualizados sobre el estado del proyecto: cuántas tareas.

(30) quedan por realizar, los errores detectados y solucionados, los casos de uso cubiertos, etc.. Team. Foundation. Server. incorpora. tres. plantillas. de. proyectos. (Scrum, Agile y CMMI), cada una con sus tipos específicos de elementos de trabajo, para atender a distintos tipos de aplicaciones o escenarios, pero podrá crear sus propias plantillas de proyecto con tipos de elementos de trabajo personalizados para acoplar TFS a su propia metodología de desarrollo. El código fuente puede asociarse a los elementos de trabajo de forma que siempre podrá acceder al código que cubre una determinada tarea. Los elementos de trabajo se consultan y actualizan desde el propio Visual Studio para que no tenga que utilizar herramientas externas mientras desarrolla: todo está dentro de Visual Studio. Informes de gestión y otras características TFS incluye un gran conjunto de informes de Reporting Services y Excel que extraen información sobre el estado de todos los aspectos fundamentales del proyecto: estado de las tareas, errores, pruebas o calidad de las compilaciones. Tanto los informes como el resto de los elementos de TFS son accesibles a través de un web, y además podrá gestionar toda la documentación del proyecto mediante portales de colaboración de Sharepoint que genera el propio Team Foundation Server. Todas estas características y más (como el motor de compilación Team Build, la gestión de laboratorios en máquinas virtuales o la gestión avanzada de permisos.

(31) de los proyectos) convierten a TFS en una herramienta fundamental para la gestión de sus aplicaciones.10 ENTITY FRAMEWORK CODEFIRST Entity framework. Es una tecnología desarrollada por Microsoft, que a través de ADO.NET genera un conjunto de objetos que están directamente ligados a una Base de Datos, permitiendo a los desarrolladores manejar dichos objetos en lugar de utilizar lenguaje SQL contra la Base de Datos. Surgimiento Los arquitectos y programadores de aplicaciones orientadas a datos se han enfrentado a la necesidad de lograr dos objetivos muy diferentes. Deben modelar las entidades, las relaciones y la lógica de los problemas empresariales que resuelven, y también deben trabajar con los motores de datos que se usan para almacenar y recuperar los datos, estos pueden abarcar varios sistemas de almacenamiento, cada uno con sus propios protocolos; incluso las aplicaciones que funcionan con un único sistema de almacenamiento deben equilibrar los requisitos del sistema de almacenamiento con respecto a los requisitos de escribir un código de aplicación eficaz y fácil de mantener. Entity Framework da vida a los modelos conceptuales permitiendo a los programadores consultar las entidades y relaciones en el modelo de dominio (denominado modelo conceptual en Entity Framework ) al tiempo que se basan en Entity Framework para traducir esas operaciones en los comandos específicos del origen de datos.. 10. Team Foundation Server. [en línea] < https://goo.gl/iQEY9x >/[Consultado el 03/02/2018].

(32) Versiones La primera versión de Entity Framework (EFv1) se incluye con. NET Framework 3.5 Service Pack 1 y Visual Studio 2008 Service Pack 1, lanzado el 11 de agosto de 2008. La segunda versión de Entity Framework, llamado Entity Framework 4.0 (EFv4), fue lanzado como parte de. NET 4.0, el 12 de abril de 2010. La tercera versión de Entity Framework, versión 4.1, fue lanzado el 12 de abril de 2011. Una actualización de la versión 4.1 llamada Entity Framework 4.1 Update 1, fue lanzado el 25 de julio de 2011. Que incluye correcciones de errores y nuevos tipos de apoyo. Proveedores de Datos El proveedor EntityClient extiende el modelo de proveedor de ADO.NET teniendo acceso a los datos en lo que respecta a las entidades conceptuales y relaciones. Ejecuta consultas que utilizan Entity SQL Entity SQL proporciona el lenguaje de consultas subyacente que permite a EntityClient comunicarse con la base de datos. Para obtener más información, vea Proveedor de EntityClient para Entity Framework. Entity Framework incluye un proveedor de datos SqlClient actualizado que admite los árboles de comandos canónicos. Para obtener más información, vea Proveedor de datos .NET Framework para SQL Server (SqlClient) para Entity Framework..

(33) Ventajas Entity Framework permite a los programadores trabajar con datos en forma de objetos y propiedades específicos del dominio, por ejemplo, con clientes y direcciones, sin tener que pensar en las tablas de las bases de datos subyacentes y en las columnas en las que se almacenan estos datos. Los desarrolladores de software pueden trabajar en un nivel más alto de abstracción cuando tratan con datos, y puede crear y mantener aplicaciones orientadas a datos con menos código que en las aplicaciones tradicionales, ya que pueden funcionar en términos de un modelo conceptual más centrado en la aplicación, que incluye tipos con herencia, miembros complejos y relaciones. Las asignaciones entre el modelo conceptual y el esquema específico de almacenamiento pueden cambiar sin tener que cambiar el código de la aplicación. Dado que Entity Framework es un componente de .NET Framework, las aplicaciones de Entity Framework se pueden ejecutar en cualquier equipo en el que esté instalado .NET Framework a partir de la versión 3.5 SP11. WIRELESS LOCAL AREA NETWORK (WLAN) Una red de área local inalámbrica (WLAN) es una red que cubre un área equivalente a la red local de una empresa, con un alcance aproximado de cien metros. Permite que las terminales que se encuentran dentro del área de cobertura puedan conectarse entre sí.. 11. Entity Framework. [en línea] < https://goo.gl/DQqj2C>/[Consultado el 03/02/2018].

(34) Principios de las WLAN Las Redes de Área Local Inalámbricas (WLANs), según definición anterior, son un sistema de comunicación que transmite y recibe datos utilizando ondas electromagnéticas (aunque también es posible con luz infrarroja), en lugar del par trenzado, coaxial o fibra óptica utilizado en las LAN convencionales, y que proporciona conectividad inalámbrica de igual a igual (peer to peer), dentro de un edificio o en un área de cobertura. Las WLAN se encuadran dentro de los estándares desarrollados por el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) para redes locales inalámbricas. Las WLANs constituyen en la actualidad una solución tecnológica de gran interés en el sector de las comunicaciones inalámbricas de banda ancha. Estos sistemas se caracterizan por trabajar en bandas de frecuencia exentas de licencia de operación, lo cual dota a la tecnología de un gran potencial de mercado permitiéndole competir con otro tipo de tecnologías de acceso. Sin embargo esto obliga al desarrollo de un marco regulatorio adecuado que permita un uso eficiente y compartido del espectro radioeléctrico disponible de dominio público. Sus características más destacadas son: Movilidad: permite transmitir información en tiempo real en cualquier lugar de la organización o empresa a cualquier usuario. Esto supone mayor productividad y posibilidades de servicio. Facilidad de instalación: al no usar cables, se evitan obras para tirar cable por muros y techos, mejorando así el aspecto y la habitabilidad de los locales, y reduciendo el tiempo de instalación. También permite el acceso instantáneo a usuarios temporales de la red. Flexibilidad: puede llegar donde el cable no puede, superando mayor número de obstáculos, llegando a atravesar paredes. Así, es útil en zonas donde el cableado no es posible o es muy costoso: parques naturales, reservas o zonas escarpadas..

(35) Comparativa entre WLAN y LAN cableadas A continuación, se observa una tabla comparativa entre las WLAN y las LAN cableadas. Cada una tiene unas ventajas e inconvenientes distintos. No obstante, siempre es posible combinar en un mismo entorno una LAN con una WLAN y así aprovecharse de las ventajas que ambas ofrecen:12. Característica. LAN. WLAN. Velocidad. Hasta 1Gbps. Hasta 870 Mbps en el nuevo estándar.. Canal compartido. No. Si. Interferencia. Casi nula. Múltiple. Distancia. Permite abarcar varios. Si nos alejamos del punto. kilómetros. de acceso perdemos conexión. Half – dúplex. Si. No. Estándar actual. 802.3. 802.11n. Transferencia. A través de cable UTP. A través de señales. cat 5 o 6. inalámbricas. Compleja. Sencilla. Instalación. Tabla 4 Diferencia entre LAN y WLAN. 12. Redes WLAN. [en línea] < https://goo.gl/kxknby>/[Consultado el 03/02/2018].

(36) IMPLEMENTACIÓN METODOLOGIA XP 3 .1 PLANIFICACIÓN 3.1.1 Historias de usuario. El cliente como agente activo en el diseño e implementación del proyecto, fue quien redactó las historias de usuario, teniendo en cuenta las premisas que indica la metodología XP, como por ejemplo el bajo nivel de detalle y el uso de la terminología de este. Por lo tanto, las historias de usuario dan una forma general a las funcionalidades del sistema, resaltando que para cada una de estas historias se encuentran requerimientos implícitos en el desarrollo de cada uno de estos escenarios, de esta forma se estimaron los tiempos requeridos para la implementación de cada historia. En la siguiente tabla se muestran las historias de usuario realizadas con la prioridad que el cliente le otorgó a cada una de estas. Para ver con más detalle cada historia ver Anexos A. N Historia 1 2 3 4 5 6 7 8 9 10 11 12 13. Nombre Historia Usuario Registro de Usuario Ingreso al sistema. Prioridad. Configuración de usuarios Registro de productos. Gestión del inventario Importación Masiva de productos Facturación Reporte de horas laboradas por empleado Reporte de productos sin stock Exportación a Excel de reportes Cierre total de caja Cierre parcial de caja Modulo Pedidos Tabla 5 Historias de Usuario - Prioridad. Alta Alta Alta Alta Alta Medio Alta Alta Alta Baja Alta Alta Medio.

(37) 3.1.2 División en iteraciones. El proyecto fue dividido en tres iteraciones, sin embargo las entregas fueron duplicadas, y se definieron seis entregas. Iteración 01 La primera iteración se relaciona con el registro de usuarios, la configuración de estos y la creación de productos, para un total de cuatro historias de usuarios asignados para desarrollar. Iteración 02 Teniendo en cuenta que la segunda iteración requería un poco más de tiempo ya que la complejidad de las historias de usuario así lo requería, se decidió asignar a la segunda iteración un total de cuatro historias, estas hacen parte de la gestión de inventario y todo el flujo de las ventas y la facturación específicamente. Iteración 03 Para la tercera iteración se asignaron cinco historias de usuario, entre las cuales se destacan algunos reportes que no demandaron mucho tiempo, y el módulo de pedidos que fue la parte primordial para esta iteración.. Historias. de. Iteración 1. Iteración 2. Iteración 3. 4. 4. 5. 8. 16. 6. usuario() Semanas. Tabla 6 Historias usuario por Iteración.

(38) 3.1.3 Plan de entregas. Teniendo en cuenta lo que plantea la metodología XP, de que el usuario defina que historias de usuario se implementarán y su grado de importancia para de esta forma generar las entregas, en el proyecto se relacionaron las historias de usuario a los módulos que para el cliente componen la parte funcional del sistema. Las entregas se realizaron por modulo, definiendo como terminado el módulo cuando se cumplieron las funcionalidades que se determinaron para cada uno. Es decir se realizaran 6 entregables, uno por modulo. A continuación en la siguiente tabla se relacionan las historias de usuario que pertenecen a cada módulo definido por el cliente:. N Historia 1 2 3 4 5 6 7 8 9 10 11 12 13. Nombre Historia Usuario Registro de Usuario Ingreso al sistema. Modulo Registro Empleados. Configuración de usuarios Registro de productos. Módulo Configuración Modulo Productos. Gestión del inventario Importación Masiva de productos Facturación Reporte de horas laboradas por empleado Reporte de productos sin stock Exportación a Excel de reportes Cierre total de caja Cierre parcial de caja Modulo Pedidos. Modulo Inventario Modulo Ventas. Modulo Informes. Modulo Ventas. Tabla 7 Historias de usuario por módulo.

(39) Para realizar el cierre del proyecto se verificó cada uno de los cierres propuestos cumpliendo las siguientes actividades: •. Se llevó a cabo una reunión final luego de cada cierre de modulo con acta y aprobación.. •. Una reunión final de entrega total del proyecto y sus módulos.. 3 .2 DISEÑO 3.2.1 Simplicidad. Teniendo en cuenta el enfoque en la simplicidad de la metodología XP, se deben mantener diseños simples, que plasmen el desarrollo exclusivamente de lo que el cliente solicita y para este este proyecto no fue necesario crear una gran cantidad de diagramas, pero si se incluyeron los más importantes, como lo fue el modelo entidad – relación, el diagrama de clases, el patrón de arquitectura que se utilizó fue MVC5 con codefirst, y los elementos gráficos se implementaron tal y como lo definió el usuario. Como consecuencia, el cliente se mostró satisfecho con el diseño y la simplicidad de la interfaz. 3.2.2 Metáfora del sistema. El uso de la metáfora del sistema consiste en una historia que cualquier usuario puede contar de la funcionalidad del sistema; este proyecto como está enfocado al desarrollo de un sistema POS es muy fácil de entender, sin embargo se redacta la siguiente historia: “sistema de software para la gestión de la facturación e inventario que permite llevar un control de las ventas realizadas por cada uno de los trabajadores.”.

(40) 3.2.3 Tarjetas CRC. Las tarjetas CRC (Cargo o Clase, Responsabilidad y Colaboración) Facilitan el diseño del sistema y es una de las partes importantes en la metodología XP, ya que resumen el significado de una clase y permite visualizar las relaciones de estas. Clase : Usuario Responsabilidad Ingresar una cuenta de usuario Actualizar información usuario Eliminar Usuario Asignación de rol. Colaborador UsuarioController.Create UsuarioController.Edit UsuarioController.Delete AspNetRol. Clase : Tercero Responsabilidad Ingresar datos de tercero Actualizar datos de tercero Eliminar Tercero. Colaborador TerceroController.Create TerceroController.Edit TerceroController.Delete. Clase : Ítem Responsabilidad Ingresar datos del producto Actualizar datos del producto Eliminar producto Asigna proveedor. Colaborador ItemController.Create ItemController.Edit ItemController.Delete Tercero. Clase : Factura Detalle Responsabilidad Registrar los productos. Insertar detalle factura por cada Producto. Afectar stock de producto. Colaborador FacturaDetalleController.Create DetalleFactura TR_TRIGGER.

(41) Clase : Factura Responsabilidad Registrar la factura Mostrar subtotal y total Impresión de factura Registrar usuario que realiza factura. Colaborador FacturaController.Create ReportViewer Usuario. Clase : Inventario Detalle Responsabilidad. Colaborador. Ingresar inventario detalle Actualizar el inventario detalle Eliminar inventario detalle Afectar stcok de producto. InventarioDetalleController.Crear InventarioDetalleController.Edit InventarioDetalleController.Delete TR_TRIGGER. Clase : Inventario Responsabilidad. Colaborador. Realizar pedido Actualizar pedido Eliminar pedido Agregar inventario detalle. InventarioController.Create InventarioController.Edit InventarioController.Delete InventarioDetalle. Clase : Agrupacion Responsabilidad Crear agrupación Eliminar agrupación Actualizar agrupación. Colaborador AgrupacionController.Create AgrupacionController.Delete AgrupacionController.Edit. Clase : Opcion Responsabilidad. Colaborador. Ingresar opción Asociar a una agrupación Eliminar Opción Actualizar opción. OpcionController.Create Agrupacion OpcionController.Delete OpcionController.Edit. Clase : Turno Responsabilidad. Colaborador. Ingresar turno Solicitar credenciales. TurnoController.Create ViewPartial.

(42) 3.2.4 Solución Rápida. Uno de los principales motivos para la implementación del POS en la cooperativa, fue llevar un control de las ventas realizadas por cada uno de los trabajadores que hacen parte de la economía solidaria, esto con el fin de establecer las ganancias de cada uno de los colaboradores. Sin embargo esto acarreaba una serie de inconvenientes en las variables de sesión de cada usuario que ingresara al sistema, así que fue necesario dedicar una parte del tiempo a dar una solución rápida a este problema, debido a que es un objetivo en el desarrollo del sistema. Para resolver dicho inconveniente fue necesario almacenar la variable de sesión en base de datos, para que al momento de abrir una nueva pestaña en el explorador o por error cerrarla, no se perdiera esta sesión y tener que volver a ingresar, lo que produciría inconsistencias en el reporte de las horas y las ventas realizadas por cada usuario. Se resolvió que la sesión y el registro en base de datos de la variable, dejara de existir al momento en que el respectivo usuario hiciera un cierre manual de la misma. Otro punto importante que surgió en el desarrollo general del sistema, se relacionó con la apertura de la caja cuando una venta terminara y se mostrara el mensaje de notificación. Dado a que el equipo de desarrollo no tenía experiencia con este mecanismo, se decidió otorgar algunas horas a un integrante del equipo, para el estudio y solución de este inconveniente, lo que resulto satisfactorio, pues al dedicar el tiempo exclusivamente a este requerimiento se logró dar con la solución y de esta forma no afectar de manera drástica los tiempos establecidos para otra historia de usuario..

(43) 3.2.5 No adicione funcionalidad antes de tiempo. La premisa que plantea XP es desarrollar explícitamente lo que el cliente solicita para cada una de las iteraciones. Sin embargo, en las primeras reuniones se había desarrollado un alcance inicial que se componía de los módulos principales de un sistema POS, pero fue necesario añadir un módulo extra de pedidos, que cumpliera con las necesidades de los clientes de realizar compras a través de dispositivos móviles conectados a una red inalámbrica proporcionada por la cooperativa. 3.2.6 Refactorización. Durante el desarrollo del proyecto se presentaron situaciones que no se habían contemplado en el diseño inicial y tuvo lugar a realizar una refactorización que no tomo mayor tiempo y no afectó la lógica del negocio y los tiempos destinados a dichos cambios y nuevas funcionalidades. Una de estas situaciones se refirió a los cierres de caja, tanto parcial como total, ya que en su momento no se tenía claridad acerca de la información que se iba a presentar en los subtotales de las facturas y en la agrupación de estas a cada uno de los usuarios, teniendo en cuenta el tiempo de sesión de cada colaborador. Otra situación presentada y que requirió hacer una refactorización se debió a la gestión del stock, pues inicialmente las cantidades de los productos se sumarian automáticamente cuando se recibiera un pedido o se restaría cuando se facturaba el respectivo ítem en una venta, esto gracias a unos triggers implementados, sin embargo el cliente solicitó que se tuviera la posibilidad de modificar estos valores por medio de una interfaz gráfica y de esta forma llevar un mejor control de las cantidades totales de cada uno de los productos..

(44) 3 .3 DESARROLLO 3.3.1 Cliente siempre disponible. Uno de los pilares de las metodologías agiles es incluir al cliente como un agente activo en el desarrollo del proyecto, sin embargo, esto acarrea una serie de sobrecostos tanto para el equipo desarrollador como para el cliente mismo, teniendo en cuenta el traslado hacia el puesto de trabajo del equipo desarrollador y de la disponibilidad del representante como tal. Si bien este tema fue uno de los grandes limitantes del proyecto, teniendo en cuenta que los representantes de la cooperativa son estudiantes de la universidad Distrital , lo que demanda un gran porcentaje de tiempo por su carga académica, y de la condición de empleados del equipo desarrollador, por lo que se planteó la estrategia de crear un grupo en un aplicación de mensajería instantánea, donde se plasmaban dudas y por allí mismo de ser posible se daba una respuesta, todo esto sin quitarle importancia a las reuniones ya acordadas para ver los avances del desarrollo; cabe resaltar que esta idea permitió una comunicación fluido con el cliente y no se presentaron mayores inconvenientes. 3.3.2 Código siguiendo estándares.. La estandarización del código se tomó en gran medida a las buenas prácticas de desarrollo establecidas para crear aplicaciones en el lenguaje C#, teniendo en cuenta la Nomenclatura, nombres de variables y demás estándares que son importantes en el diseño de software, sin importar la metodología implementada. •. Estándares en Base de Datos : ✓ Las iniciales de las tablas se escribieron en mayúscula. ✓ Los nombres de las tablas deben ser singulares. ✓ Los nombres de los campos de las tablas, debe ser mayúscula su inicial y nombres singulares..

(45) ✓ Las llaves foráneas se deben identificar con los caracteres “id” al final del nombre de la tabla a la cual se encuentra relacionada. Ejemplo : Terceroid. •. Estándares en el código: ✓ Se utilizó Pascal Casing para los nombres de clases y para los nombres de los métodos. ✓ Se utilizó Camel casing para nomenclar variables y parámetros de métodos. ✓ Se deberá utilizar Pascal Case para nomenclar constantes. ✓ Utilizar el prefijo “I” con Pascal Casing para nomenclar Interfaces. ✓ No utilizar caracteres de subrayado (_) para nombres de variables locales.. 3.3.3 Desarrollar unidad de pruebas primero. El planteamiento de la metodología XP, sugiere realizar unidades de prueba antes que escribir el código, sin embargo en este proyecto este consejo no fue tomado y se desarrolló inicialmente las funcionalidades y después de esto los unit test, esto ya que en el momento del desarrollo surgían nuevas funcionalidades o requerimientos técnicos lo que dificultaba al inicio realizar dichas pruebas sin aún tener presente el verdadero objetivo de cada historia. También el modelo relacional en algunos momentos cambio, al ingresar nuevos campos que se requerían guardar en base de datos importantes para generar los respectivos reportes..

(46) Otro factor que no se tomó en cuenta y que no permitieron realizar las pruebas inicialmente, fue la estimación de tiempos para estas, pues no se tocó el tema en las primeras reuniones y por lo tanto retrasaría el desarrollo del proyecto si se hubieran incluido. 3.3.4 Desarrollo de código en parejas. La metodología XP propone que se desarrolle el código en parejas, en un mismo espacio geográfico y en un solo computador. Sin embargo para este proyecto este principio no fue aplicado, ya que se emplearon herramientas que permitieron trabajar sobre una misma versión de código sin problemas de compilación y en diferentes equipos, de igual forma el software fue desarrollado por una sola pareja, teniendo en cuenta el propósito del proyecto y la complejidad de este.. 3.3.5 Integraciones frecuentes y en parejas. Las integraciones frecuentes fue un punto fundamental en el desarrollo del sistema, teniendo en cuenta los principios de la integridad del código, es por esto que se empleó la herramienta Team Foundation Server, que nos facilita el versionamiento del código fuente y una gestión completa del ciclo de vida de la aplicación, desde la fase de diseño hasta las pruebas. Dado que este proyecto fue desarrollado por una sola pareja, la implementación del TFS (Team Foundation Server) fue de gran ayuda, ya que le permitió al equipo desarrollador estar en diferentes puntos geográficos y trabajar directamente sobre el mismo código, la misma versión y sin errores de compilación. Cada cambio realizado por algún desarrollador fue muy sencillo de integrar, ya que bastó con solo realizar “Check in” a las modificaciones o las nuevas funcionalidades y con esto el código ya se encontraba disponible para que el otro desarrollador obtuviera la última versión con los últimos cambios realizados y.

(47) seguir continuando con las correspondientes tareas asignadas. Es recomendable realizar integraciones frecuentemente como lo indica la metodología, y que estas no contengan muchos cambios o componentes, pues al momento en que se presenten errores se dificultará localizarlos en la correspondiente versión.. 3.3.6 Propiedad colectiva de código. Si bien el proyecto fue desarrollado por una sola pareja, la propiedad colectiva del código no presentó mayores inconvenientes teniendo en cuenta que se implementó la herramienta Team Foundation Services, que actúa como un repositorio del código fuente alojado en un servidor, por lo cual, si en el desarrollo de la aplicación hubiese sido necesario integrar un nuevo desarrollador, tan solo habría que brindarle los permisos necesarios para que este descargará el código fuente de la carpeta raíz y de esta forma empezar a desarrollar.. 3.3.7 Optimizaciones para el final. Es necesario realizar optimizaciones técnicas del proyecto en la fase final del desarrollo y evitar trabajar horas extras como lo indica la metodología empleada. Teniendo en cuenta que el equipo desarrollador no solo se dedicó a la realización del sistema como tal, debido a horarios laborales, las horas extras se entienden al aumento de tiempo dedicado a una funcionalidad en particular en la cual ya se había estimado una cierta cantidad de horas. En este aspecto, al final del proyecto se realizaron varias optimizaciones a nivel grafico en los módulos de venta, reportes y gestión del stock, lo que requirió algunas horas más de desarrollo, pero no afectó los tiempos estimados para estos requerimientos..

(48) 3 .4 PRUEBAS 3.4.1 Pruebas de aceptación. La metodología XP sugiere que para cada historia de usuario se debe realizar una respectiva prueba de aceptación. Las pruebas son realizadas por el cliente pero en compañía del equipo desarrollador que a lo largo del proceso los fue guiando y capacitando en el uso de la herramienta. Las siguientes fueron las pruebas realizadas sobre la herramienta teniendo en cuenta las historias de usuario definidas anteriormente: Especificación de Prueba: Registro de Usuario- Historia 1. Descripción En esta historia hay que comprobar el registro de un usuario en el sistema y en la base de datos. Si al introducir un dato del usuario no es correcto se avisa al usuario y no se insertan los datos incorrectos del usuario en la base de datos. También debe comprobar, en el caso de que el registro de usuarios sea correcto, que el proceso de introducción fue satisfactorio y los datos de los usuarios sean almacenados en la base de datos. Registrar un usuario correctamente Descripción El administrador una vez ingresado en el sistema, seleccionará la opción del menú “Configuración”, la opción “Usuarios”, debe dar clic en el botón “Crear Nuevo”, se mostrará un formulario de registro con los datos pertinentes en la creación del nuevo usuario, debe diligenciar el formulario y dar check en el botón de la opción” Activo” Condiciones de ejecución El administrador debe estar en sesión para realizar el registro. Entrada - El administrador introducirá su usuario y clave. - Del menú principal seleccionará “Configuración”. - Se da clic en el botón “Crear Nuevo” - Se mostrará un formulario con los campos principales para la creación de un usuario. - Se diligencian todos los campos mostrados. - Se activa el check de la opción “Activo”. - Selecciona la opción “Registrar”.

(49) -. Se muestra mensaje de confirmación.. Resultado esperado Creación de un usuario activo en la base de datos. Evaluación de la prueba Prueba satisfactoria. Registrar un usuario con errores Descripción Si en el diligenciamiento del formulario de registro de usuario falta un campo obligatorio por completar debe alertar y mostrar un mensaje de los campos que faltan por insertar. Condiciones de ejecución El administrador debe estar en sesión para realizar el registro. Entrada - El administrador introducirá su usuario y clave. - Del menú principal seleccionará “Configuración”. - Se da clic en el botón “Crear Nuevo” - Se mostrará un formulario con los campos principales para la creación de un usuario. - Selecciona la opción “Registrar” - Se muestra mensaje indicando los campos faltantes por diligenciar. Resultado esperado Se muestra alerta con los campos que faltan por diligenciar. Evaluación de la prueba Prueba satisfactoria..

(50) Especificación de Prueba: Ingreso al sistema- Historia 2. Descripción Esta prueba consiste en el ingreso general del sistema por parte de todos los usuarios registrados en la base de datos. Ingreso al sistema correctamente Descripción El usuario una vez visualizado la página principal de la aplicación, ingresa en la opción “Iniciar Sesión”, se muestra un formulario con dos campos que corresponden al Email y la contraseña, se diligencian estos campos, se da clic en el botón “Iniciar Sesión” Condiciones de ejecución El usuario debe estar registrado en la base de datos y debe diligenciar correctamente la contraseña y el respectivo usuario. Entrada - El usuario ingresa a la página principal de la aplicación. - Se mostrará un formulario con dos campos: Usuario y Contraseña. - Se diligencian los dos campos según corresponda al usuario que va a iniciar sesión. - Se da clic en el botón “Iniciar Sesión”. - Se muestra pantalla con los menús asignados al rol correspondiente al usuario. Resultado esperado Ingreso satisfactorio al sistema, con los menús asignados al rol del usuario. Evaluación de la prueba Prueba satisfactoria. Ingreso al sistema con errores Descripción Al momento de ingresar a la pantalla de inicio de sesión y se introducen credenciales no existentes o erróneas se mostrará un mensaje con el error presentado Condiciones de ejecución El usuario debe estar registrado en la base de datos y debe diligenciar usuario o contraseña indebida..

(51) Entrada - El usuario ingresa a la página principal de la aplicación. - Se mostrará un formulario con dos campos: Usuario y Contraseña. - Se diligencian los dos campos con usuario y contraseña incorrectos. - Se da clic en el botón “Iniciar Sesión”. - Se muestra mensaje de error alertando que el usuario o la contraseña son incorrectas. - Se mantiene la pantalla de inicio de sesión. Resultado esperado Mensaje de error con un texto de usuario o contraseña incorrecta. Evaluación de la prueba Prueba satisfactoria.. Especificación de Prueba: Configuración de usuarios - Historia 3. Descripción En esta historia hay que comprobar la configuración del usuario en la asignación de roles por parte del administrador que debe tener la sesión iniciada, igualmente la edición de los datos con los que se registró. Configuración correcta de usuarios Descripción El administrador una vez ingresado en el sistema, seleccionará la opción del menú “Configuración”, la opción “Usuarios”, mostrará un listado de los usuarios registrados en el sistema, el administrador seleccionará el modo de “Edición” de un usuario especifico, seleccionará el botón “Ver Rol”, se mostrará un pop up con los roles creadas hasta al momento y se seleccionará uno de estos, el sistema mostrará un mensaje de confirmación de rol asignado. Condiciones de ejecución El administrador deberá estar dado de alta en el sistema y deben existir roles creados en el sistema. Entrada - El administrador introducirá su usuario y clave. - Del menú principal seleccionará “Configuración”. - Seleccionará la opción “Usuarios” - Dara clic en el icono de “Editar” de un correspondiente usuario..

(52) Seleccionará el botón “Ver Rol” Se mostrará pantalla con los roles activos en el sistema. Se selecciona los roles que serán asignados a ese usuario. Se muestra pantalla de confirmación de rol asignado. Se da clic en la opción “Cerrar”. Se selecciona “Guardar”. Redirecciona a la lista de usuarios registrados en el sistema. Resultado esperado Confirmación de los roles asignados al usuario que se encuentra en edición. Evaluación de la prueba Prueba satisfactoria. -. Especificación de Prueba: Registro de productos - Historia 4 Descripción En esta historia hay que comprobar el registro de los productos que la cooperativa va a ofrecer, con la información relevante como el precio. Introducción correcta de productos Descripción El administrador una vez ingresado en el sistema, seleccionará la opción del menú “Productos”, opción “Reg. Productos”, se mostrará una lista de productos ya registrados y un botón “Crear Nuevo”, se diligencian los datos y se confirma con el botón “Crear” Condiciones de ejecución El operador, administrador deberán estar dados de alta en el sistema. Entrada - El administrador introducirá su usuario y clave. - Del menú principal seleccionará “Productos”. - Selecciona la opción “Reg. Productos” - Da clic en el botón “Crear Nuevo” - Se mostrará un formulario de registro de producto. - Se diligencian los campos obligatorios. - Se confirma la creación con el botón “Crear” - Se visualiza la lista de los productos creados. Resultado esperado Visualización del producto creado en la lista de ítems del sistema. Evaluación de la prueba.