UNIVERSIDAD CENTRAL DEL ECUADOR … · 3.1 Metodologías tradicionales del desarrollo del...

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGENIERÍA CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERIA INFORMÁTICA

“SISTEMA DE FACTURACION Y CONTROL DE INVENTARIO PARA

ADMINISTRAR NEGOCIOS DE SERVICIOS Y MINORISTAS.”

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO

DE INGENIERO INFORMÁTICO

AUTOR: CARLOS PATRICIO JARAMILLO MORALES

TUTOR: MSc. GUILLERMO ALEXIS ALBUJA PROAÑO

QUITO- 03 DE AGOSTO

2016

ii

DEDICATORIA

Esta tesis se la dedico a mi Dios quién supo guiarme por el buen camino, darme fuerzas

para seguir adelante y no desmayar en los problemas que se presentaban, enseñándome

a encarar las adversidades sin perder nunca la dignidad ni desfallecer en el intento.

A mi padre Hugo Jaramillo, por haberme apoyado en todo momento, por sus consejos,

sus valores, por la motivación constante que me ha permitido ser una persona de bien,

y por siempre estuviste ahí para cumplir nuestro sueño compartido, ser un gran

profesional.

A mi madre Teresa Morales, por darme la vida, quererme mucho, creer en mí y porque

siempre me apoyaste. Mamá gracias por darme una carrera para mi futuro, todo esto te

lo debo a ti.

A mis hermanos Víctor y Gabriel, por estar siempre presentes, acompañándome para

poderme realizar.

A mi novia Andrea Santo por siempre estar a mi lado en las buenas y en las malas; por

su comprensión, paciencia y amor, dándome ánimos de fuerza y valor para seguir a

delante.

.

iii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL

Yo, CARLOS PATRICIO JARAMILLO MORALES en calidad de autor del Proyecto de

Investigación: “SISTEMA DE FACTURACION Y CONTROL DE INVENTARIO

PARA ADMINISTRAR NEGOCIOS DE SERVICIOS Y MINORISTAS”, por la

presente autorizo a la Universidad Central del Ecuador, hacer uso de todos los

contenidos que pertenecen o parte de los que contiene esta obra, con fines estrictamente

académicos o de investigación.

Los derechos que como autores nos corresponden, con excepción de la presente

autorización, seguirán vigentes a nuestro favor, de conformidad con lo establecido en los

artículos 5, 6, 8; 19 y demás pertinentes de la Ley de Propiedad Intelectual y su

Reglamento.

Asimismo, autorizo a la Universidad Central del Ecuador para que realice la

digitalización y publicación de este trabajo de investigación en el repositorio virtual, de

conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación Superior.

Quito, 03 de Agosto de 2016

Carlos Patricio Jaramillo Morales

C.C. 1718210584

0984734982

[email protected]

iv

CERTIFICACIÓN DEL TUTOR

En calidad de Tutor de la investigación “SISTEMA DE FACTURACION Y

CONTROL DE INVENTARIO PARA ADMINISTRAR NEGOCIOS DE

SERVICIOS Y MINORISTAS” desarrollada en su totalidad por el señor egresado

Carlos Patricio Jaramillo Morales con C.C. 1718210584, como requisito previo a la

obtención del Título de Ingeniero Informático, cumple con los requisitos necesarios.

En la ciudad de Quito a los 03 días del mes de Agosto del 2016.

Atentamente,

Ing. Guillermo Alexis Albuja Proaño, MSC.

C.C.: 171245406

0994272056

[email protected]

v

CALIFICACIÓN DEL TRABAJO DE GRADUACIÓN

vii

CONTENIDO

DEDICATORIA ................................................................................................................................... ii

AUTORIZACIÓN DE LA AUTORÍA INTELECTUAL ................................................................... iii

CERTIFICACIÓN DEL TUTOR ....................................................................................................... iv

LISTA DE TABLAS ................................................................................................................................... ix

LISTA DE ILUSTRACIONES ...................................................................................................................... xi

LISTA DE ANEXOS .................................................................................................................................. xi

RESUMEN ......................................................................................................................................... xii

INTRODUCCIÓN ............................................................................................................................... 1

CAPITULO I ....................................................................................................................................... 2

1. PRESENTACIÒN DEL PROBLEMA ........................................................................................ 2

1.1 Planteamiento del Problema ....................................................................................................... 2

1.2 Objetivos de la Investigación ...................................................................................................... 2 1.2.1 Objetivo General..................................................................................................................... 2 1.2.2 Objetivos Específicos ............................................................................................................. 3

1.3 Justificación ................................................................................................................................ 3

1.4 Alcance........................................................................................................................................ 4

1.5 PLATAFORMA, ARQUITECTURA Y HERRAMIENTAS DE DESARROLLO ........................... 5 1.5.1 Plataforma............................................................................................................................... 5 Java Enterprise Edition (JEE) ..................................................................................................... 5 1.5.2 Arquitectura ............................................................................................................................ 5 Modelo Vista Controlador .......................................................................................................... 5

1.6 Herramientas de Desarrollo ....................................................................................................... 5

CAPÍTULO II ...................................................................................................................................... 6

2. MARCO TEÒRICO. ................................................................................................................... 6

2.1 Antecedentes. .............................................................................................................................. 6

2.2 Negocio minorista y de servicio .................................................................................................. 7

2.3 Factura Comercial ...................................................................................................................... 7

2.4 Plataforma .................................................................................................................................. 7 2.4.1 Java Enterprise Edition (JEE) ................................................................................................. 7

2.5 Arquitectura ................................................................................................................................ 8 2.5.1 Aplicaciones Multicapa .......................................................................................................... 8 2.5.2 Lenguaje de programación JAVA. ....................................................................................... 10

viii

2.5.3 Servidor de Aplicaciones Glassfish ...................................................................................... 10 2.5.4 PrimeFaces ........................................................................................................................... 11 2.5.5 JasperReports ........................................................................................................................ 11 2.5.6 iReport .................................................................................................................................. 12 2.5.7 Postgresql ............................................................................................................................. 12

CAPÌTULO III ................................................................................................................................... 14

3. METODOLOGÌA ...................................................................................................................... 14

3.1 Metodologías tradicionales del desarrollo del software .......................................................... 15

3.2 Metodologías Agiles del desarrollo de software ....................................................................... 15

3.3 Metodologías Ágiles vs. Metodologías Tradicionales .............................................................. 16

3.4 Desarrollo iterativo e incremental ............................................................................................ 17 3.4.1 Ventajas ................................................................................................................................ 18 3.4.2 Desventajas ........................................................................................................................... 18

3.5 Etapas del Proceso de Desarrollo de un proyecto ágil............................................................. 19 3.5.1 Análisis ................................................................................................................................. 19 3.5.2 Planificación y Diseño .......................................................................................................... 20 3.5.3 Iteraciones Para la Liberación de la Primera Versión ........................................................... 20 3.5.4 Puesta en Producción ............................................................................................................ 20 3.5.5 Mantenimiento ...................................................................................................................... 20

3.6 Scrum ........................................................................................................................................ 20 3.6.1 El Manifiesto Ágil ................................................................................................................ 21 3.6.2 Elementos de Scrum ............................................................................................................. 22 3.6.3 Eventos de Scrum ................................................................................................................. 23 3.6.4 Herramientas de Scrum ........................................................................................................ 25 3.6.5 Definición de Terminado ...................................................................................................... 26

CAPITULO IV .................................................................................................................................. 28

4. MODELO DEL SISTEMA DE FACTURACION Y CONTROL DE INVENTARIO PARA

ADMINISTRAR NEGOCIOS DE SERVICIOS Y MINORISTAS .................................................. 28

4.1 Sprint 0: Reunión de Análisis y Planificación General del Sistema ......................................... 29 4.1.1 Análisis ................................................................................................................................. 29 4.1.2 Planificación ......................................................................................................................... 35 4.1.3 Lista de Pendientes del Sprint ............................................................................................... 37 4.1.4 Puesta en Producción ............................................................................................................ 37 4.1.5 5.1.4 Mantenimiento ............................................................................................................. 37

4.2 Sprint 1: Modulo de Seguridad. ................................................................................................ 38 4.2.1 Análisis ................................................................................................................................. 38 4.2.2 Planificación ......................................................................................................................... 44 4.2.3 Lista de Pendientes del Sprint ............................................................................................... 45 4.2.4 Puesta en Producción ............................................................................................................ 45

4.3 Sprint 2: Módulo de Compras ................................................................................................... 46 4.3.1 Análisis ................................................................................................................................. 46 4.3.2 Planificación ......................................................................................................................... 49

ix

4.3.3 Puesta en Producción ............................................................................................................ 52 4.3.4 Mantenimiento ...................................................................................................................... 52

4.4 Sprint 3: Módulo de Inventario. ................................................................................................ 52 4.4.1 Análisis ................................................................................................................................. 52 4.4.2 Planificación ......................................................................................................................... 56 4.4.3 Puesta en Producción ............................................................................................................ 58 4.4.4 Mantenimiento ...................................................................................................................... 58

4.5 Sprint 4: Modulo de Ventas. ..................................................................................................... 59 4.5.1 Análisis ................................................................................................................................. 59 4.5.2 Planificación ......................................................................................................................... 63 4.5.3 Puesta en Producción ............................................................................................................ 65 4.5.4 Mantenimiento ...................................................................................................................... 65

4.6 Sprint 5: Módulo de Reportes ................................................................................................... 66 4.6.1 Análisis ................................................................................................................................. 66 4.6.2 Planificación ......................................................................................................................... 69 4.6.3 Puesta en Producción ............................................................................................................ 72 4.6.4 Mantenimiento ...................................................................................................................... 73

4.7 Producto Terminado ................................................................................................................. 73 4.7.1 Lista de Producto .................................................................................................................. 73

CAPÍTULO V .................................................................................................................................... 76

5. CONCLUSIONES Y RECOMENDACIONES ......................................................................... 76

5.1 CONCLUSIONES ..................................................................................................................... 76

5.2 RECOMENDACIONES ............................................................................................................ 77

BIBLIOGRAFÍA ................................................................................................................................ 79

LISTA DE TABLAS Tabla 1 . Comparación de Metodologías de desarrollo de software tradicional y ágil ............... 17

Tabla 3 Requerimientos Funcionales, Planificación General del Sistema, Ingreso al Sistema... 30

Tabla 4 Requerimientos Funcionales, Planificación General del Sistema, Salida del Sistema... 31

Tabla 5 Requerimientos Funcionales, Planificación General del Sistema, Reporteria ............... 32

Tabla 6 Requerimientos No Funcionales, Planificación General del Sistema, Software ............ 33

Tabla 7 Requerimientos No Funcionales, Planificación General del Sistema, Ambiente de

Desarrollo .................................................................................................................................... 33

x

Tabla 8 Requerimientos No Funcionales, Planificación General del Sistema, Base de Datos ... 34

Tabla 9 Requerimientos No Funcionales, Planificación General del Sistema, Informacion

histórica ....................................................................................................................................... 34

Tabla 10 Lista de Producto al iniciar el Sprint 0: Análisis y Planificación General ................... 35

Tabla 11 Requerimientos Funcionales, Módulo de Seguridad, Perfiles de Usuario ................... 39

Tabla 12Requerimientos Funcionales, Módulo de Seguridad, Usuarios. ................................... 40

Tabla 13 Requerimientos Funcionales, Módulo de Seguridad, Recursos por Perfil. .................. 41

Tabla 14 Requerimientos Funcionales, Módulo de Seguridad, Cambio de Contraseña ............. 41

Tabla 15 Requerimientos Funcionales, Módulo de Seguridad, Empleados. ............................... 42

Tabla 16 Requerimientos No Funcionales, Módulo de Seguridad, Sesiones. ............................. 43

Tabla 17 Lista de Producto al iniciar el Sprint 1: Módulo de Seguridades. ................................ 44

Tabla 18 Requerimientos Funcionales, Módulo Compras, Proveedores .................................... 47

Tabla 19 Requerimientos Funcionales, Módulo Compras, Factura de Compra. ......................... 47

Tabla 20 Requerimientos Funcionales, Módulo Compras, Validar Factura. .............................. 49

Tabla 21 Lista de Producto al iniciar el Sprint 1: Módulo de Compras. ..................................... 50

Tabla 22 Lista de Pendientes del Sprint 2: Modulo de Compras ................................................ 51

Tabla 23 Recursos Funcionales, Modulo Inventario, Articulo ................................................... 53

Tabla 24 Recursos Funcionales, Modulo Inventario, Ingreso de Inventario. .............................. 54

Tabla 25 Recursos Funcionales, Modulo Inventario, Mantenimiento de Inventario. ................. 55

Tabla 26 Lista de Producto al iniciar el Sprint 3: Módulo de Inventario. ................................... 56

Tabla 27 Lista de Pendientes del Sprint 3: Modulo Inventario ................................................... 58

Tabla 28 Requerimientos Funcionales, Módulo de Ventas, Clientes .......................................... 60

Tabla 29 Requerimientos Funcionales, Módulo de Ventas, Generación de Orden de Trabajo .. 60

Tabla 30 Requerimientos Funcionales, Módulo de Ventas, Factura de Venta ........................... 61

Tabla 31 Lista de Producto al iniciar el Sprint 4: Módulo de Ventas. ........................................ 63

Tabla 32 Lista de Pendientes del Sprint 4: Modulo de Ventas.................................................... 65

Tabla 33 Requerimientos Funcionales, Módulo de Reportes, Reporte Ejecutivo de Ventas ...... 66

Tabla 34 Requerimientos Funcionales, Modulo de Reportes, Reporte Detalle Ejecutivo de

Ventas .......................................................................................................................................... 67

Tabla 35 Requerimientos Funcionales, Modulo de Reportes, Reporte de Clientes. ................... 68

Tabla 36 Requerimientos Funcionales, Módulo de Reportes, Reporte de Ordenes de Trabajo. . 69

Tabla 37 Lista de Producto al iniciar el Sprint 5: Módulo de Reportes. ..................................... 70

Tabla 38 Lista de Pendientes del Sprint 5: Modulo de Reportes ................................................ 72

xi

Tabla 39 Lista de Producto al finalizar el Sprint 5: Módulo de Reportes ................................... 73

LISTA DE ILUSTRACIONES Ilustración 1 Arquitectura de una aplicación JEE .......................................................................... 9

Ilustración 2 Etapas del proceso de desarrollo de modelo ágil .................................................. 19

Ilustración 3 Visión General del Modelo Scrum .......................................................................... 27

LISTA DE ANEXOS Anexo 1 Diagrama de Procesos de la Actividad del Negocio ...................................................... 82

Anexo 2 Diagrama de Procesos de Seguridades ......................................................................... 83

xii

RESUMEN

“SISTEMA DE FACTURACION Y CONTROL DE INVENTARIO PARA

ADMINISTRAR NEGOCIOS DE SERVICIOS Y MINORISTAS.”

Autor: Carlos Patricio Jaramillo Morales

Tutor: Ing. Guillermo Alexis Albuja Proaño, MSC.

El Sistema de facturación y control de inventario para administrar negocios de servicios y

minoristas, es un sistema web que fue diseñado para administrar de una manera óptima negocios

de servicios y minoristas. El sistema se ha diseñado en un ambiente de código abierto por

requerimientos de la institución para prescindir del licenciamiento de software.

Los negocios de servicios y minoristas requieren un mejor registro de la venta de artículos y

servicios que brindan y agilitan el proceso de facturación, todo eso apoyándose en un óptimo

control de inventarios para así aumentar su productividad y la eficiencia en de los servicios que

prestan.

La facilidad de seguimiento de los procesos mediante el uso de pantallas y reportes generados

por el sistema que permiten conocer la situación financiera y los cambios que experimenta el

negocio a una fecha o periodo determinado, para tomar decisiones oportunas.

PALABRAS CLAVES: /SISTEMA DE FACTURACION /INVENTARIO DE NEGOCIO

/ADMINISTRACION DE INVETARIO /PROCESOS DE CONTROL DE NEGOCIOS

/REPORTES GERENCIALES/ AGILIZAR PROCESOS DEL NEGOCIO.

xiii

ABSTRACT

“BILLING AND INVENTORY CONTROL SYSTEM FOR RETAIL AND SERVICE

BUSINESS MANAGEMENT”

Author: Carlos Patricio Jaramillo Morales

Tutor: Ing. Guillermo Alexis Albuja Proaño, MSC.

The billing and inventory control system for retail and service business management is a web

system that was designed to optimally manage service and retail companies. This system has

been designed in an open-source environment to fulfill institutional requirements and dispense

with software licensing.

Service businesses and retailers demand for a better record of the sale of goods and services

they provide and the expediting of billing processes, both relying on optimal control of

inventories in order to increase productivity and efficiency in the services they provide.

The ease of monitoring processes by using screens and reports generated by the system provides

insight into the financial performance and into the changes the business faces to a certain date or

period, and allows the company to make timely decisions.

KEYWORDS: /FACTURATION SYSTEM /BUSINESS INVENTORY /ADMINISTRATION

OF INVENTORY /CONTROL BUSINESS PROCESSES /MANAGEMENT REPORTS

/STREAMLINE BUSINESS PROCESSES.

I CERTIFY that the above and foregoing is a true and correct translation of the original

document in Spanish.

Anabelle Irene Moncayo Noroña

I.D. 1711174019

CELULAR: 0981547438 COD. 1005-06-665663

1

INTRODUCCIÓN

El llevar a cabo la administración de un negocio desde sus inicios, es una tarea

sumamente agotadora e importante para su buen funcionamiento y su desarrollo, estas

tareas serán los cimientos de una posible gran organización en un futuro, siempre y

cuando las actividades que se realicen ofrezcan una visión y fortalezas necesarias para

lograrlo.

Las metas de un negocio son resultados, situaciones o estados que un negocio pretende

lograr o a los que pretende llegar, en un periodo de tiempo y a través del uso de los

recursos con los que dispone o planea disponer.

En la actualidad para que un negocio crezca es necesario el apoyo de recursos como son

los sistemas informáticos, los cuales ayudaran al negocio en el incremento de la

productividad, disminuyendo la cantidad de trabajadores u horas de trabajos necesarios.

Los negocios generan cantidades de datos y por lo tanto recopilaciones de información,

la cual debe ser veraz, objetiva y precisa, por lo cual se necesita una manera eficiente de

clasificarla y ordenarla, además de que sea fácil de verificar.

Y es por eso hoy en día ya no podemos darnos el lujo de poner en marcha un negocio

sin hacer uso de alguna herramienta tecnológica porque se corre el riesgo de

desaparecer el negocio.

2

CAPITULO I

1. PRESENTACIÒN DEL PROBLEMA

1.1 Planteamiento del Problema

En el Ecuador el principal problema que poseen estos negocios de servicios y minoristas

es que no poseen ningún sistema informático ya se por varios motivos, ya sea por falta

de recursos o desconocimiento del mismos. Y todo su trabajo se realiza de manera

manual o mecánica, por lo cual este inconveniente hace aún más complicado y a su vez

más moroso el proceso de recolección, no solo de la información de los clientes si

no de la facturación de las ventas y de un control adecuado del inventario de los

negocios.

Debido a este reconocimiento es una necesidad la sistematización de los procesos para

administrar un negocio, de tal manera se brindara a sus clientes un mejor servicio y para

tener un eficiente control de las ventas de productos y prestaciones de servicios, que

brinda esto tipo de negocio. Lo cual generara al negocio un crecimiento y un nivel

competitivo en el mercado.

1.2 Objetivos de la Investigación

1.2.1 Objetivo General

Disponer de un sistema de facturación física y control de inventarios para negocios de

servicios y minoristas para su mejor administración.

3

1.2.2 Objetivos Específicos

Identificar datos relevantes del negocio como son clientes, proveedores,

productos y servicios.

Diseñar y construir una base de datos para almacenar información tanto de los

datos relevantes recolectados como los ingresos y egresos del negocio.

Definir la automatización del proceso de facturación y de la administración del

inventario.

Diseñar un sistema que registre las ventas y tener un consolidado total de los

productos vendidos y del dinero recaudado.

Construir reportes gerenciales.

1.3 Justificación

Día a día, los negocios están en búsqueda constante de la excelencia y con ella

conquistar el mercado en el cual se desenvuelven. Para ello deben contar con unos

requisitos legales los cuales se obtienen según el desenvolvimiento que estas

demuestren en su trayectoria de trabajo realizado.

Este éxito en el desarrollo de las diversas labores que constituyen en el negocio se

consigue con la obtención no solo de materiales de calidad unido a una excelente

calidad del personal capacitado para las labores designadas, sino que, se hace

indispensable el uso de la tecnología para agilizar y mejorar los trámites y los procesos

que se desarrollan en el negocio y de esta manera brindar un servicio más rápido y

oportuno a los clientes, aumentando las posibilidades de fidelidad por parte de los

clientes, sumado a la posibilidad de captación de nuevos de ellos mismos.

La mayoría de los negocios minoristas y de servicios no disponen de ayuda o apoyo de

sistemas informáticos para su administración, por varios motivos como

desconocimiento o falta de recursos. Al tener ese apoyo de los sistemas informáticos

permitirá una eficiente administración del negocio para que crezca y sea exitoso.

4

1.4 Alcance

El sistema busca administrar y controlar los procesos desde la compra de artículos que

ingresan al inventario del negocio hasta la facturación física de la venta de los artículos

y la prestación de servicios, con la incorporación de los siguientes módulos:

Módulo de Clientes: Gestiona la información de los clientes.

Módulo de Compras: Gestiona el registro de las facturas que se obtiene

al comprar artículos a los proveedores y validación para su posterior

ingreso al inventario.

Módulo de Empleados: Gestiona la información de los empleados del

negocio.

Módulo de usuarios: gestión de usuarios, asignación y control de

contraseñas, gestión de perfiles de usuario y seguridades del acceso a la

información.

Módulo de Inventario: Gestión de inventario, creación y ubicación de los

artículos, ingreso de artículos al inventario adquiridos a los proveedores

y edición o mantenimiento del inventario.

Módulo de reportes: Elaboración de reportes ejecutivo de ventas

(Factura), reporte ejecutivo de ventas (Producto), reporte de clientes y

reportes de órdenes de trabajo.

Módulo de Venta: Gestiona la generación y registro de facturas físicas,

en el proceso de venta de los productos y/o servicios del negocio.

Pruebas por módulo del sistema.

Capacitación al personal encargado de la Administración General del

Sistema.

Configuración e instalación del Sistema de facturación y control de

inventario para administrar negocios de servicios y minoristas, además

del software necesario para el funcionamiento del sistema en servidor y

estaciones de trabajo.

Entrega de Manuales de Usuario y Técnicos.

5

1.5 PLATAFORMA, ARQUITECTURA Y HERRAMIENTAS DE

DESARROLLO

1.5.1 Plataforma

Java Enterprise Edition (JEE)

1.5.2 Arquitectura

Modelo Vista Controlador

1.6 Herramientas de Desarrollo

El desarrollo de la aplicación se realizó con las siguientes herramientas.

Servidor de aplicaciones Glassfish 1.6

IDE de Desarrollo Netbeans 8.2

Sistema Gestor de Bases de Datos Postgres 9.1

Herramienta para reporteria JasperReport 5.6.0, haciendo el uso del diseñador

iReport 5.6.

6

CAPÍTULO II

2. MARCO TEÒRICO.

2.1 Antecedentes.

El comercio minorista compra productos en grandes cantidades a fabricantes

o importadores, bien directamente o a través de un mayorista. Sin embargo, vende

unidades individuales o pequeñas cantidades al público en general, normalmente, en un

espacio físico llamado tienda.

Los minoristas se encuentran al final de la cadena de suministro. Los responsables de

marketing comprenden el comercio minorista dentro de su estrategia global de

distribución.

Las tiendas pueden estar en zonas residenciales, zonas comerciales o también integradas

en centros comerciales.

La automatización para este tipos de negocios desde la aparición de sistemas

informáticos ha dado soluciones a muchos problemas de administración, contabilidad y

así han logrado mejorar la economía y ventas mediante el uso de aplicaciones

informáticas.

Y en el Ecuador muchos de estos tipos de negocios no poseen este tipo de sistemas para

administrar el negocio ya sea por distintos motivos, entonces esto limita en la

productividad y eficiencia del negocio.

Por lo cual se procederá a crear un sistema para gestionar este tipo de negocios con una

agradable y funcional interfaz gráfica que de acuerdo a una investigación algunos

sistemas similares no poseen esta característica.

https://es.wikipedia.org/wiki/Comercio

https://es.wikipedia.org/wiki/Importaci%C3%B3n

https://es.wikipedia.org/wiki/Mayorista

https://es.wikipedia.org/wiki/Tienda

https://es.wikipedia.org/wiki/Cadena_de_suministro

7

2.2 Negocio minorista y de servicio

Es la empresa comercial o persona en régimen de autónomo que vende productos o

presta servicios al consumidor final. Son el último eslabón del canal de distribución, el

que está en contacto con el mercado.

2.3 Factura Comercial

Gonzales (2014).

Es un documento mercantil que refleja toda la información

de una operación de compraventa. La información

fundamental que aparece en una factura debe reflejar la

entrega de un producto o la provisión de un servicio, junto

a la fecha de devengo, además de indicar la cantidad a

pagar en relación a existencias, bienes de una empresa

para su venta en eso ordinario de la explotación, o bien

para su transformación o incorporación al proceso

productivo, además de indicar el tipo de IVA que se debe

aplicar.

La factura es comprobante que se genera cuando se realiza una venta de productos y/o

prestaciones de servicios, que consta de dos partes la cabecera con los datos del cliente,

total a pagar, datos del negocio y la otra parte es el detalle de la factura el cual consta

de del detalle de cada producto.

2.4 Plataforma

2.4.1 Java Enterprise Edition (JEE)

La plataforma JEE está diseñada y orientada al desarrollo de aplicaciones empresariales

con una arquitectura multicapa, escritas en el lenguaje de programación Java y que

pueden ejecutarse en un servidor de aplicaciones.

https://es.wikipedia.org/wiki/Documento

https://es.wikipedia.org/wiki/Contrato_de_compraventa

https://es.wikipedia.org/wiki/Producto_(marketing)

https://es.wikipedia.org/wiki/Servicio_(econom%C3%ADa)

https://es.wikipedia.org/wiki/Impuesto_sobre_el_Valor_A%C3%B1adido

8

JEE está basado en la plataforma Java Standard Edition (Java SE), posee librerías y

servicios de sistema que ofrecen escalabilidad, accesibilidad, seguridad, integridad,

concurrencia entre otros requerimientos que discierne a las aplicaciones empresariales.

2.5 Arquitectura

2.5.1 Aplicaciones Multicapa

“JEE admite utilizar arquitecturas de n capas distribuidas y se apoya ampliamente en

componentes de software modulares que pueden ser ejecutados en un servidor de

aplicaciones. La especificación de JEE define su arquitectura basándose en los

conceptos de capas generalmente divididas en cuatro capas: la capa cliente, la capa web,

la capa negocio y la capa datos” (Montoro, S. 2013).

En las aplicaciones multicapa cada capa cumple con su respectiva función y están

relacionas entre sí, dependiendo la una de la otra.

2.5.1.1 Capa de Datos

Es la capa responsable de la información de la empresa que puede incluir sistemas de

bases de bases de datos o sistemas de procesamiento datos. En esta capa se tiene el

acceso a los datos almacenados y es donde las aplicaciones JEE se integran con otros

sistemas que no pertenecen al estándar JEE.

2.5.1.2 Capa de Negocio

En esta capa se encuentra la lógica del negocio de la aplicación. Dispone de las

interfaces necesarias para interactuar con la capa de datos y poder recuperar, ingresar,

eliminar y actualizar datos que serán usados para cálculos luego de una petición del

usuario realizada desde el nivel de la capa Web. En esta capa se encuentra en el servidor

de aplicaciones.

9

2.5.1.3 Capa Web

Esta capa se encarga de recibir los datos del usuario desde la capa cliente para generar

una respuesta apropiada a la solicitud. La capa Web no accederá a la capa de datos

directamente sino que existe una comunicación entre la capa Web y la capa de Negocio

de donde obtendrá la información.

2.5.1.4 Capa Cliente

Esta capa contiene la interfaz gráfica del sistema que se encarga de interactuar con el

usuario. En esta capa se definen el diseño y la organización visual de las pantallas.

Ilustración 1 Arquitectura de una aplicación JEE

Fuente: Modificado de: http://17cosas.blogspot.com/

Autor: José Antonio 2009 https://www.blogger.com/profile/05002673145960351147

https://www.blogger.com/profile/05002673145960351147

10

2.5.2 Lenguaje de programación JAVA.

El lenguaje de programación usado en el desarrollo del Sistema De Facturación Y

Control De Inventarios Para Administrar Negocios De Servicios y Minoristas es el

lenguaje JAVA.

JAVA fue creado en el año de 1991 por la compañía Sun Microsystem con la intención

de que un desarrollador pueda programar una sola vez y ejecutar el programa en

cualquier dispositivo "write once, run anywhere", sin importar la arquitectura que este

posea.

Java es un lenguaje de programación concurrente, orientado a objetos, distribuido,

portable y de alto desempeño; hace uso de diferentes bibliotecas conocidas como el API

de Java que ofrecen a los programadores medios para desarrollar aplicaciones.

“Las aplicaciones creadas en Java son compiladas a bytecode y pueden ejecutarse en

una máquina virtual Java (JVM). La JVM es un programa nativo que es ejecutado para

cada plataforma específica capaz de interpretar las instrucciones del Java bytecode. Sun

Microsystem ha creado diferentes máquinas virtuales para las distintas plataformas y

poder dar a java la portabilidad al lenguaje en diferentes arquitecturas” (Arias, C. 2009).

Por eso la gran ventaja de la máquina virtual java es aportar portabilidad al lenguaje de

manera que desde Sun Microsystems se han creado distintas máquinas virtuales java

para diferentes arquitecturas y así un programa .class escrito en un Windows puede ser

interpretado en un entorno Linux.

2.5.3 Servidor de Aplicaciones Glassfish

“Un servidor de aplicaciones es un dispositivo de software que proporciona servicios de

aplicación a las computadoras cliente. Es encargado de gestionar toda la lógica de

negocio y acceso a los datos de la aplicación” (Lopez, M. 2014).

El servidor de aplicaciones concentra toda la gestión de la lógica del negocio y facilita

el acceso de los datos de la aplicación, lo cual brinda un eficiente servicio a las

computadoras cliente.

11

Java EE provee estándares que permiten a un servidor de aplicaciones servir como

"contenedor" de los componentes que conforman dichas aplicaciones. Entre los

componentes que controla el servidor de aplicaciones en Java están los servlets, Java

Server Pages (JSP), Enterpirse Java Beans (EJBs).

Glassfish es un servidor de aplicaciones que implementa la plataforma JavaEE5, por lo

que soporta las últimas versiones de tecnologías como: JSP, JSF, Servlets, EJBs, Java

API para Servicios Web (JAX-WS), Arquitectura Java para Enlaces XML (JAXB),

Metadatos de Servicios Web para la Plataforma Java 1.0, y muchas otras tecnologías.

2.5.4 PrimeFaces

PrimeFaces es una librería de componentes visuales de código abierto basado en el

estándar JSF 2.0 que simplifica la programación de páginas web y ayuda en la mejora

de la visualización a los usuarios finales gracias a sus librerías enriquecidas.

“JSF se puede considerar como una mejora de JSP ya que trabaja por eventos, mientras

que JSP lo hace en base a peticiones y respuestas” (Viñe, E. 2010).

Entre las principales características de Primefaces se pueden destacar.

PrimeFaces soporta la tecnología Ajax que permite un comportamiento

asíncrono del lado del cliente lo que mejora la experiencia del usuario al realizar

peticiones y carga de datos.

La integración con Javascript que permiten invocar procesos del lado del cliente

para aliviar la demanda de peticiones al servidor desde sus componentes.

Soporta CSS, y temas que permiten la creación de diseño en la página y creación

de estilos estándares que facilitan el mantenimiento de las páginas.

2.5.5 JasperReports

JasperReports es una librería de código abierto desarrollado por la comunidad

JasperSoft. Posibilita la creación de reportes con texto enriquecido; toma como fuente

orígenes de datos como JDBC, TableModels, JavaBeans XML, Hibernate y CSV para

presentarlos en un documento que pueda ser imprimible en archivos PDF, HTML, XLS,

12

CSV, y XML. Y permite ser incrustada en cualquier aplicación Java ya que está escrito

en este lenguaje.

2.5.6 iReport

iReport es un diseñador gratuito de reportes desarrollado en Java el cual hace uso de las

librerías de JasperReports. Permite añadir al diseño componentes como imágenes,

tablas, texto estático y dinámico, sub-informes, entre otros. Soporta conexiones con

JDBC, XML, JavaBeans, archivos CSV, Hibernate, XLS, JSON. “Incorpora el uso de

asistentes para la creación de reportes sencillos rápidamente que guían al desarrollador

durante su creación a través de una interfaz amigable e intuitiva” (SourceForce.net).

Todos los parámetros que se agregan al diseño gráfico del reporte, constituye el fichero

JRXML, que es un diseño de informe que es compilado por el propio iReport usando las

librerías de JasperReports, para obtener el archivo de extensión jasper que será usado

para la integración de programas en java.

2.5.7 Postgresql

La definición de PostgreSQL es “Sistema Gestor de Bases de Datos objeto-relacional,

distribuido bajo licencia BSD de código libre desarrollado por la comunidad PGDG

(PostgreSQL Global Development Group). PostgreSQL utiliza un modelo

cliente/servidor y usa multiprocesos en vez de multihilos para garantizar la estabilidad

del sistema. Un fallo en uno de los procesos no afectará el resto y el sistema continuará

funcionando” (Martinez, R. 2010).

Entre las características principales de postgresql están:

Generales

o ES un sistema Gestor de Base de Datos ACID.

o Integridad referencial.

o Replicación asincrónica/sincrónica.

o Copias de seguridad en caliente.

o Unicode.

o Regionalización por columna.

o Acceso encriptado vía SSL.

o Actualización in-situ integrada.

13

o Completa documentación.

o Licencia BSD.

o Disponible para Linux y UNIX en todas sus variantes (AIX, BSD,

HPUX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit.

Programación / Desarrollo

o Funciones/procedimientos almacenados en numerosos lenguajes de

programación, entre otros PL/pgSQL, PL/Perl, PL/Python y PL/Tcl.

o Numerosos tipos de datos y posibilidad de definir nuevos tipos.

o Además de los tipos estándares en cualquier base de datos, tenemos

disponibles, entre otros, tipos geométricos, de direcciones de red, de

cadenas binarias, UUID, XML, matrices, etc.

o Soporta el almacenamiento de objetos binarios grandes (gráficos, videos,

sonido, ...).

o APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, ODBC,

PHP, Scheme, Qt y muchos otros.

SQL

o SQL92, SQL99, SQL2003, SQL2008.

o Llaves primarias y foráneas.

o Controles Check, Unique y Not null.

o Restricciones de unicidad postergables.

o Columnas auto-incrementales.

o Índices compuestos, únicos, parciales y funcionales en cualquiera de los

métodos de almacenamiento disponibles.

o Sub-selects.

o Consultas recursivas.

o Joins.

o Vistas.

o Disparadores (triggers) comunes, por columna, condicionales.

o Reglas.

o Herencia de tablas (Inheritance).

14

CAPÌTULO III

3. METODOLOGÌA

La definición formal de Ingeniería de Software según la IEEE (2004) es “la aplicación

de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y

mantenimiento de Software” (p. 31).

Es aplicar de forma práctica los conocimientos científicos al diseñar y construir

software, asociada con documentación requerida para desarrollar, operar y

mantenimiento del software.

Uno de los objetivos para garantizar la calidad del software ha sido encontrar

procedimientos que faciliten su desarrollo en la búsqueda de mejorar el diseño,

disminución de costos y tiempos de desarrollo, mejorar la organización del equipo de

trabajo y facilitar el mantenimiento de los sistemas; para ello se han establecido

diferentes metodologías.

“La metodología de desarrollo como parte de la ingeniería de software es un framework

que es usado para estructurar, planificar y controlar el proceso de desarrollo de un

sistema de información” (CMS,2009, párr.1).

Se debe tener muy en cuenta el tipo de metodología que se aplicara al proceso de

desarrollo y eso depende del tipo software a desarrollarse y de los requerimientos de los

usuarios.

En este capítulo se busca presentar la selección de la metodología de desarrollo de

software utilizada en la elaboración del “Sistema De Facturación Y Control De

Inventarios Para Negocios Minoristas Y Servicios”. Se describe además las principales

características de los modelos tradicionales y los modelos ágiles.

15

3.1 Metodologías tradicionales del desarrollo del software

Anterior a los años 80, los proyectos de software fracasaban al no presentar los

resultados esperados en calidad y tiempos de entrega, dando lugar a un incremento de

los costos asociados al desarrollo de un proyecto. La creación de metodologías de

desarrollo lograron un orden en la en la forma de desarrollo de un proyecto para así

generar un software de calidad, donde el éxito se lograba a través de una planificación

cuidadosa generalmente en etapas de desarrollo secuenciales y una documentación

estricta en cada una de sus etapas y procesos.

En el desarrollo de software, aquellas metodologías que hacen un mayor énfasis en la

planificación y control del proyecto se denominan metodologías tradicionales.

Entre estas metodologías se puede citar:

RUP (Rational Unified Process)

MSF (Microsoft Solution Framework)

Win-Win Spiral Model

Iconix

3.2 Metodologías Agiles del desarrollo de software

Un inconveniente al momento de realizar un desarrollo de software haciendo uso de

metodologías tradicionales es la adaptación a los cambios, por lo que no son métodos

adecuados cuando se trabaja en un entorno donde los requerimientos no son claros o son

muy variantes en su desarrollo.

Pressman, (2010) afirma:

La ingeniería de software ágil combina una filosofía con un

conjunto de lineamientos de desarrollo. Su filosofía pone

énfasis en la satisfacción del cliente con la entrega rápida de

software incremental, haciendo uso de recursos de equipos

pequeños y muy motivados para realizar el proyecto. El uso

de métodos informales en la recolección de información y un

énfasis en el cliente facilitan el avance en el desarrollo de

16

prototipos que pueden estar al alcance del cliente

rápidamente. Los lineamientos de desarrollo enfatizan la

entrega sobre el análisis y el diseño (aunque estas actividades

no se desalientan) y la comunicación activa entre

desarrolladores y clientes (p.55).

Con las metodologías agiles se busca des complicarse con el proceso de

desarrollos del software, con un mejor trabajo en equipo y con una mejor

satisfacción del cliente.

3.3 Metodologías Ágiles vs. Metodologías Tradicionales

Las metodologías tradicionales proponían un enfoque secundario en relación a las

personas, ya que se enfocaban en los procesos. Consideraban que al tener un proceso

predecible con etapas y tareas bien definidas, el éxito estaba garantizado

independientemente de las personas que cubrieran los roles. En estas metodologías se

realiza toda la planificación antes de que comience el ciclo de desarrollo del producto de

software. Ante una saciedad agitada, seguir la formalidad de la solución documentada

no es lo adecuado cuando se requieren resultados parciales que sean visibles en etapas

tempranas del proyecto. Es donde entra el desarrollo ágil al dar respuestas rápidas,

adaptables y modificables en el tiempo.

Por otra parte, los procesos de desarrollo adaptativos también facilitan la generación

rápida de prototipos y de versiones previas a la entrega final, lo cual agradará al cliente

que observará atentamente como se plasman las ideas en el producto, generando una

alta expectativa sobre su avance y entrega final.

Las diferencias entre estas dos metodologías se pueden resumir en el siguiente cuadro

comparativo.

17

Tabla 1 . Comparación de Metodologías de desarrollo de software tradicional y

ágil

Metodologías Tradicionales Metodologías Agiles

Basadas en normas provenientes de

estándares seguidos por el entorno de

desarrollo.

Basadas en heurísticas provenientes de

prácticas de producción de código.

Cierta resistencia a los cambios. Especialmente preparados para cambios

durante el proyecto.

Impuestas externamente. Impuestas internamente (por el equipo).

Proceso mucho más controlado, con

numerosas políticas/normas.

Proceso menos controlado, con pocos

principios.

El cliente interactúa con el equipo de

desarrollo mediante reuniones.

El cliente es parte del equipo de

desarrollo.

Más artefactos. Pocos artefactos.

Más roles. Pocos roles

Distribuidos.

Grupos pequeños y trabajando en el

mismo sitio.

La arquitectura del software es

esencial y se expresa mediante modelos

Menos énfasis en la arquitectura del

software.

Existe un contrato prefijado No existe contrato tradicional o al

menos es bastante flexible

Fuente: http://masteringenieriasoft.blogspot.com/2012/04/metodologias-de-desarrollo

desoftware.html

3.4 Desarrollo iterativo e incremental

La metodología utilizada para el desarrollo del “Sistema De Facturación Y Control De

Inventarios Para Administrar Negocios De Servicios y Minoristas” en cada una de sus

etapas es la metodología de desarrollo iterativo e incremental, que se acopla con el

http://masteringenieriasoft.blogspot.com/2012/04/metodologias-de-desarrollo

18

modelo de desarrollo ágil denominado Scrum, debido a que la planificación se realiza

en bloques temporales.

El desarrollo iterativo e incremental consiste en desarrollar el producto en iteraciones

que van incrementando valor al producto final, de manera que se obtiene una versión

funcional del producto a la espera de una aprobación por parte del cliente. Cada

iteración se acerca más al producto final a la espera de cumplir con los objetivos

planteados, obtener una mejor calidad del producto y la satisfacción del cliente.

3.4.1 Ventajas

Las principales ventajas que posee el uso de la metodología iterativa e incremental son:

Está centrado en los objetivos más importantes.

Se recibe una retroalimentación del usuario final en cada iteración.

Mejora el conocimiento del negocio en cada iteración.

Existe evidencia del desarrollo del software con el uso de prototipos.

Los errores se evidencian tempranamente disminuyendo el costo asociado a

estos

3.4.2 Desventajas

Se pueden considerar varias desventajas en el uso de la metodología iterativa:

Se requiere una alta participación del usuario, lo que no es fácil de encontrar.

El abuso en el número de iteraciones provoca retardos en la entrega del producto

y altos costos asociados.

Debido a la cantidad de requerimientos el sistema tiende a degradar su

arquitectura si no se considera un tiempo y recursos para la refactorización.

Si no se considera el análisis de requisitos y objetivos en el desarrollo, se puede

perder el horizonte debido a la cantidad de retroalimentación del usuario.

Debido a la gran cantidad de cambios no es posible documentar todos los

cambios en los prototipos.

19

3.5 Etapas del Proceso de Desarrollo de un proyecto ágil

Una característica de la metodología ágil es la de ser iterativa e incremental. Debido a la

filosofía de satisfacción del cliente, un modelo ágil busca lanzar una primera versión del

producto rápidamente para recibir una retroalimentación del cliente e ir formando así un

producto estable en evolución. Las etapas que caracterizan un desarrollo de un proyecto

ágil son las de análisis, planificación y diseño, iteraciones para la liberación de la

primera versión, puesta en producción y mantenimiento.

Ilustración 2 Etapas del proceso de desarrollo de modelo ágil

Fuente: Modificado de: Análisis y Diseño de Sistemas, Kendall & Kendall, 8va.

Edición, 2011

3.5.1 Análisis

Al iniciar el proyecto se analiza las capacidades del equipo, los recursos que se

disponen tanto así en tecnología disponible y recursos humanos, el entorno de trabajo y

la forma de obtención de información sobre lo que el cliente requiere. En esta etapa se

busca obtener toda la información relevante del proyecto en desarrollo.

20

3.5.2 Planificación y Diseño

Luego de haber analizado y obtenido la información suficiente sobre el proyecto o

etapa, se procede a planificar su ejecución con una solución a los requerimientos

presentados en el análisis. Aquí se definirá los objetivos, el alcance, una fecha de

entrega y se establecerá prioridades para cada requisito establecido.

3.5.3 Iteraciones Para la Liberación de la Primera Versión

Las iteraciones constan de ciclos de prueba donde se cuenta con la retroalimentación del

cliente y se realizan las modificaciones al prototipo. Se plasma en un producto inicial

todos los requerimientos planteados en las etapas de análisis y diseño.

3.5.4 Puesta en Producción

En esta fase se libera el producto, se agiliza la retroalimentación del cliente y el trabajo

en cada iteración. El objetivo de cada iteración es crear un incremento que sea funcional

para que el cliente pueda realizar sus observaciones implementando características que

mejoren al software.

3.5.5 Mantenimiento

Luego de liberado el sistema hay que garantizar que este pueda seguir funcionando sin

problemas. En esta etapa es posible continuar agregando características al software con

una actitud más conservadora, donde se consideren cambios que no afecten la estructura

o que puedan afectar su funcionamiento normal.

3.6 Scrum

La metodología Scrum es una metodología ágil de desarrollo de software, creada por

Jeff Sutherland y su equipo de desarrollo a principios de la década de 1990, y

posteriormente, desarrollados por Schwaber y Beedle en el año 2001. Scrum como toda

metodología ágil se basa en los principios del Manifiesto Ágil.

Scrum no es una técnica que busca construir productos, más bien es un marco de trabajo

en el que se pueden emplear varias técnicas que permitan una eficacia relativa en la

21

gestión del producto y su desarrollo; se basa en el control de procesos empírico, donde

las decisiones se toman en base al conocimiento y a la experiencia con un enfoque

incremental.

3.6.1 El Manifiesto Ágil

“En 2001, un grupo de críticos de los modelos de desarrollo de software entre los que se

destacan Mike Beedle, Ken Schwaber y Jeff Sutherland, se reúnen con el afán de tratar

sobre técnicas y procesos para desarrollar software para tomar a los métodos ágiles

como una alternativa a las metodologías formales” (Prentice Hall, fall 2001).

Los principios básicos de Scrum se basan en el manifiesto ágil que valora

principalmente:

Individuos e iteraciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva

Colaboración con el cliente sobre negociación contractual

Respuesta ante el cambio sobre seguir un plan

Los principios en los que se basa el manifiesto ágil son

La mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.

Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.

Los procesos Ágiles aprovechan el cambio para proporcionar ventaja

competitiva al cliente.

Entregamos software funcional frecuentemente, entre dos semanas y dos meses,

con preferencia al periodo de tiempo más corto posible.

Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el

entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

22

El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante

de forma indefinida.

La atención continua a la excelencia técnica y al buen diseño mejora la

Agilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto

organizados.

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a

continuación ajustar y perfeccionar su comportamiento en consecuencia.

3.6.2 Elementos de Scrum

3.6.2.1 El Equipo Scrum (Scrum Team)

El equipo Scrum es el grupo de trabajo conformado por el dueño del producto, el equipo

de desarrollo y el Scrum Master. Todos los miembros del equipo son multifuncionales y

auto-organizados de tal manera que pueden optar por la mejor manera de cumplir con su

trabajo y no basarán sus decisiones y métodos con elementos externos al equipo.

El equipo de Scrum es el encargado de entregas incrementales del producto terminado,

garantizando que estará disponible una versión del producto funcional.

3.6.2.1.1 El Dueño Del Producto (Product Owner)

El dueño del producto es el responsable de obtener el mayor valor del producto final

para todos los implicados. Es una única persona que podría representar los deseos de un

comité en la Lista del Producto (Product Backlog); aquellos que quieran cambiar la

prioridad de un elemento de la Lista deben hacerlo a través del Dueño de Producto.

3.6.2.1.2 El Equipo de Desarrollo (Development Team)

23

El equipo de desarrollo está conformado por profesionales que son los encargados de

entregar un incremento del producto terminado. El equipo de desarrollo trabaja como un

grupo responsable sin tomar en cuenta las habilidades especiales o títulos de cada uno

de los miembros. Las tareas y organización de los miembros para la realización de

incrementos en la Lista del Producto la realiza el equipo mismo.

3.6.2.1.3 El Scrum Master

El Scrum Master es el responsable de hacer cumplir todos los reglamentos de Scrum

que están al servicio del Equipo de Scrum. También está encargado de la comunicación

e interacción entre el Equipo de Scrum y las personas externas para hacer que el

producto terminado tenga mayor valor.

3.6.3 Eventos de Scrum

Los eventos de Scrum son bloques predefinidos de tiempo dentro del desarrollo del

proyecto. Todos los eventos dan la oportunidad de realizar una inspección y una

adecuación si es requerida siempre tratando de completar un producto terminado y

cumpliendo con los tiempos preestablecidos a fin de no desviar su objetivo. El uso de

estos reduce la necesidad de realizar reuniones no establecidas dentro de Scrum.

3.6.3.1 Sprint

El Sprint es la base primordial de Scrum. Es un bloque de tiempo generalmente de un

mes, en donde al finalizar se hace la entrega de un producto terminado que es

potencialmente entregable.

Para poder cumplir con un sprint en el tiempo acordado se debe completar las

actividades que representan más valor al cliente a fin de alcanzar los objetivos

primordiales tempranamente.

No es permitido cambiar los objetivos del sprint ya que esto generaría un descontrol en

la planificación; de ser necesario el dueño del producto es el único que puede cancelar

un sprint, considerando los intereses generales del proyecto.

24

Cuando se anula un sprint se evalúa en la lista de producto los objetivos alcanzados y su

estimación para la reinserción en un nuevo sprint en una reunión de planificación del

nuevo sprint.

3.6.3.2 Reunión de planificación del Sprint (Sprint Planning Meeting)

En esta etapa el equipo completo de Scrum determina las actividades a realizarse y la

Lista de producto que se usará como objetivo del sprint. La duración de una reunión de

planificación generalmente tiene una duración de un día. En esta reunión se define el

incremento y lo que se requiere para cumplir con el objetivo. El equipo de desarrollo

define los alcances y explica al dueño del producto y al Scrum Master su planificación

para lograr el objetivo del sprint.

3.6.3.3 Objetivo del Sprint (Sprint Goal)

En la reunión de planificación el Dueño del Producto propone los requerimientos que

pretende sean un producto terminado. Debido a negociaciones entre el Dueño del

Producto y el Equipo de Scrum se define el objetivo del sprint y la Lista de Producto

que permita alcanzarlo. El objetivo del sprint ayuda al Equipo de Desarrollo a enfocar

sus esfuerzos.

3.6.3.4 Scrum Diario (Dialy Scrum)

Para llevar un control de las actividades realizadas y encontrar inconvenientes que

retrasen el avance del sprint, se realizan reuniones diarias con un tiempo no mayor a 15

minutos. En esta reunión el equipo de desarrollo responde a las siguientes preguntas:

¿Que se realizó para lograr el objetivo del Sprint?

¿Qué se realizará hoy para lograr el objetivo del Sprint?

¿Qué impedimento existe o se ha encontrado para lograr el objetivo del Sprint?

El Scrum Diario ayuda al equipo de desarrollo a tomar decisiones oportunas en la

detección de impedimentos relativos al desarrollo; es una buena oportunidad para

inspeccionar el trabajo realizado y adaptarse a los cambios encontrados.

25

3.6.3.5 Revisión de Sprint (Sprint Review)

Cuando la etapa de desarrollo haya terminado, al finalizar el Sprint se lleva a cabo una

reunión, generalmente de 4 horas, para revisar el incremento en el producto terminado y

la lista de Producto. Los asistentes entre ellos el Equipo de Desarrollo y el Dueño del

Producto, colaboran para determinar cómo se puede agregar valor al producto terminado

y se proyecta un período de tiempo para conseguir una aceptación total de ser requerido.

En esta reunión se explican los elementos de la Lista del Producto que se han terminado

y los que no, los problemas que se encontraron en el proceso de desarrollo y como se

resolvieron.

En este punto la Lista de Producto se evalúa y se añaden elementos para ser resueltos en

el siguiente Sprint. Todo lo que dé valor al producto terminado puede ser considerado.

3.6.3.6 Retrospectiva de Sprint (Sprint Retrospective)

Luego de haberse realizado la revisión del Sprint y antes de la planificación del

siguiente Sprint, se realiza una reunión, generalmente de 3 horas, entre el equipo de

Scrum para revisar las posibles mejoras y su factibilidad para el siguiente Sprint.

Aunque las correcciones y revisiones se pueden realizar durante todo el proceso de

desarrollo en las reuniones diarias, es un evento dedicado a la inspección y adaptación

del producto terminado con énfasis a posibles mejoras para el desarrollo de posteriores

Sprints.

El Scrum Master guía la realización del evento y es partícipe de este, ya que es

responsable del proceso de Scrum. Aquí se evalúa al Equipo de Scrum participante, las

relaciones entre estos, los procesos y las herramientas utilizadas para identificar los

puntos fuertes y elaborar un plan para la inserción de nuevos elementos que faciliten y

ayuden a completar el siguiente Sprint de una forma más efectiva.

3.6.4 Herramientas de Scrum

Para garantizar la transparencia y claridad de los objetivos en el desarrollo de cada

Sprint, el Scrum Master se basa en herramientas que representan trabajo o valor y que

26

permiten a todo el equipo de Scrum tener un conocimiento claro e imparcial de lo que se

desea como producto terminado. La falta de claridad en estas herramientas ocasiona que

se tomen malas decisiones, que se pierda valor al producto y que el proyecto fracase.

3.6.4.1 Lista de Producto (Product Backlog)

Es una lista ordenada definido por el Propietario del Producto, donde constan todos los

requerimientos que el producto terminado debe contener. Esta lista es variable en el

tiempo de acuerdo a lo que necesita el producto para llegar a ser considerado un

producto terminado y que cumpla con las expectativas de valor del cliente.

El refinamiento de esta lista puede realizarse en cualquier momento y ser comunicada a

todo el equipo de Scrum luego de ser medida su factibilidad y sin que interfiera en la

duración del Sprint.

La medición en el seguimiento de la Lista de Producto se puede realizar por lo menos en

cada Revisión del Sprint.

3.6.4.2 Lista de Pendientes del Sprint (Sprint Backlog)

Lo conforman los elementos de la Lista del Producto y un plan de entrega del

incremento del producto. Este lo gestiona el Equipo de Desarrollo y permite llevar un

control de todo lo necesario para alcanzar el objetivo del Sprint. De acuerdo al trabajo a

medida que el Sprint avanza, la Lista de Pendientes del Sprint puede aumentar o

disminuir los requisitos que deben ser cumplidos. La revisión de estos pendientes se la

puede realizar al menos en la Scrum Diario.

3.6.4.3 Incremento

Es la suma de todas las Listas de Producto completadas de un Sprint determinado y los

incrementos de los anteriores a este. El incremento debe estar siempre disponible al

finalizar el Sprint sea liberado o no por el Dueño del Producto.

3.6.5 Definición de Terminado

27

El producto terminado puede entenderse como el producto disponible cuando se ha

completado el trabajo y que se puedan poner posteriormente en producción. Este tiene

lugar luego de que los incrementos realizados cumplan con el objetivo y cumplan con el

criterio de calidad que el Dueño del Producto defina oportunamente. Los estándares que

se establezcan entre cada producto terminado dentro de la Lista de Productos, se

replicará para los productos que posean semejanzas y servirá como guía de la

organización del Equipo de Desarrollo.

El significado de producto terminado debe quedar claro dentro del Equipo de Scrum

para poder cumplir con la entrega del Sprint oportunamente sin provocar retrasos o

cargas de trabajo posteriores.

Ilustración 3 Visión General del Modelo Scrum

Fuente: Modificado de: El Modelo Scrum, Autor: Juan Palacio 2006,

www.navegapolis.net

( http://agilemanifesto.org/iso/es/manifesto.html, tomado al 20 de junio del 2015)

(http://agilemanifesto.org/iso/es/principles.html, tomado al 20 de junio del 2015)

28

CAPITULO IV

4. MODELO DEL SISTEMA DE FACTURACION Y CONTROL DE

INVENTARIO PARA ADMINISTRAR NEGOCIOS DE SERVICIOS Y

MINORISTAS

La metodología Scrum admite realizar un proyecto en corto tiempo basando los

resultados en la satisfacción del cliente al ajustar las expectativas de este en un modelo

de desarrollo de software. Con esta metodología se busca una activa participación entre

el cliente y el grupo desarrollador quienes estarán inmersos en todas las etapas de

desarrollo y con una comunicación constante si se pretende abarcar todos los intereses.

La metodología Scrum deja de lado los formalismos que usan las metodologías

tradicionales en la Ingeniería de Software y divide el desarrollo en etapas o módulos

denominados Sprints, donde se agrupan actividades y procesos a fin de que al

completarlos se pueda observar un sistema integral.

Para el desarrollo del proyecto se ha definido el mismo en pequeños módulos que

pueden considerarse como sub-proyectos denominados Sprint. La división del trabajo

por módulos permite organizar de una forma más eficiente el trabajo. Se ha tomado

cada Sprint como un módulo del sistema con una duración de 1 semana donde cada una

de las fases del desarrollo iterativo e incremental se repetirá para cada una de los

Sprints, esto significa que cada etapa tendrá su análisis, planificación y diseño,

iteraciones para la liberación de la primera versión, puesta en producción y

mantenimiento. La integración de todos los módulos se analizará en la reunión de

planificación inicial y sus resultados se tendrán presentes durante todas las fases del

proyecto y en la planificación de cada uno de los Sprints.

Los Sprints que se desarrollarán en el Sistema de Facturación y Control de Inventarios

para Negocios Minoristas y de Servicios:

29

Sprint 0: Reunión de Análisis y Planificación General del Sistema

Sprint 1: Módulo de Seguridad

Sprint 2: Modulo de Compras

Sprint 3: Modulo de Inventario

Sprint 4: Modulo de Ventas

Sprint 5: Modulo de Reportes

4.1 Sprint 0: Reunión de Análisis y Planificación General del Sistema

La reunión inicial corresponde a lo que se denomina como “Sprint 0”. En esta reunión

se ha definido el equipo de trabajo Scrum, así como las responsabilidades de cada uno

de sus miembros dentro del desarrollo del proyecto. Se ha considerado también un

análisis preliminar de los requisitos que permita orientar al equipo de trabajo con

respecto a la estructura funcional del sistema para entender brevemente las relaciones

entre los procesos del negocio.

4.1.1 Análisis

En esta etapa se registrarán los aspectos más globales de las funcionalidades que deberá

presentar el sistema para que el equipo de trabajo tenga una idea clara del objetivo y el

alcance del proyecto, sin profundizar en aspectos detallados que serán tratados a

profundidad en el desarrollo de cada Sprint.

4.1.1.1 Diagrama de Procesos

Para comprender el funcionamiento de los procesos individuales que realiza un negocio

minorista y de servicios, es necesario reconocer el proceso en general y la intervención

de los principales actores que intervendrán en el sistema.

El diagrama de procesos muestra el grado de complejidad en el alcance de un proyecto,

facilitando la planificación y la elaboración de alternativas ante posibles contingencias.

En esta fase, el diagrama de procesos representa una perspectiva macro de las

actividades que desarrolla cada uno de los actores, y que permite interpretar su rol

dentro de las actividades de ventas de productos y servicios y la interrelación que existe

entre cada actividad.

30

El Diagrama se muestra en el Anexo 1.

4.1.1.2 Análisis de Procesos

El análisis de procesos proporciona un método para examinar la dinámica de las

organizaciones, teniendo como punto de partida el hecho de que llevan a cabo

propósitos con objetivos definidos mediante la ejecución de una secuencia articulada de

actividades.

Según la secuencia de actividades se puede definir los procesos que intervienen en el

funcionamiento de la organización, de acuerdo a las necesidades presentadas por el

cliente. Estos procesos se representan dentro de los requerimientos funcionales del

sistema.

4.1.1.2.1 Requerimientos Funcionales Generales

A continuación se detallan los requerimientos funcionales generales que debe poseer el

sistema a desarrollarse, los mismos fueron definidos en conjunto con el personal

encargado del proyecto por parte del negocio minorista y de servicios Rueda Motors

Lubricadora.

Tabla 2 Requerimientos Funcionales, Planificación General del Sistema, Ingreso al

Sistema.

REQUERIMIENTO FUNCIONAL N-001

Nombre Ingreso al sistema

Fecha 18 de Enero del 2016

Módulo Planificación General del Sistema

Sub-módulo No aplica

Función El usuario debe registrarse para el ingreso al Sistema.

Descripción El usuario deberá ingresar el nombre de usuario, la

contraseña asignada al mismo.

Entrada Nombre de usuario, contraseña.

31

Fuente Usuarios del sistema.

Salida Menú principal del sistema con las opciones habilitadas

para el usuario que ha iniciado sesión.

Acción Permitir el ingreso al sistema a usuarios registrados y

autorizados.

Requerimiento

Crear un usuario dentro del sistema, poseer una contraseña

y estar habilitado. Crear períodos lectivos dentro del

sistema.

Efectos Colaterales

El menú que saldrá para el inicio de sesión exitoso

dependerá de las opciones habilitadas para el perfil del

usuario.

Tabla 3 Requerimientos Funcionales, Planificación General del Sistema, Salida del

Sistema.


Nombre Salida del sistema




Función Salida normal del sistema

Descripción Para salir de cada una de las páginas se deberá confirmar la

salida por medio de un mensaje. Esta opción estará presente

en toda la solución.

Entrada Ninguna


Salida Mensaje de confirmación.

Acción Permitir la salida del sistema a usuarios con sesión abierta.

32

Requerimiento Sesión abierta de un usuario dentro del sistema.

Efectos Colaterales La finalización de la sesión activa implica la salida del

sistema. Los datos no guardados se perderán.

Tabla 4 Requerimientos Funcionales, Planificación General del Sistema,

Reporteria


Nombre Reportería




Función Generación de reportes

Descripción Los reportes se mostrarán en formato PDF para evitar la

manipulación de la información, las hojas serán numeradas

y contemplarán el usuario responsable y fecha en la que son

impresos.

Entrada Información filtrada desde la aplicación.


Salida Archivo en formato PDF.

Acción De acuerdo a los parámetros requeridos en la búsqueda, se

filtrará la información solicitada para presentarla en un

archivo de formato PDF.

Requerimiento Poseer información suficiente para la generación de

reportes.

Efectos Colaterales Ninguno

33

4.1.1.2.2 Requerimientos No Funcionales Generales

Los diferentes aspectos que deben tomar en cuenta en el desarrollo de todo el proyecto

y que no están atados a los datos en sí mismos o funciones a realizar, corresponden a los

requerimientos no funcionales. Estos requerimientos se han definido en la reunión de

planificación del proyecto.

Tabla 5 Requerimientos No Funcionales, Planificación General del Sistema,

Software

REQUERIMIENTO NO FUNCIONAL N-001

Nombre Software




Función Definir el entorno de desarrollo y tipo de

software a utilizar

Descripción El sistema deberá usar herramientas de software libre para

evitar el pago de licenciamientos en todas sus etapas


Ambiente de Desarrollo


Nombre Ambiente de desarrollo




Función Definir el ambiente de desarrollo del software.

34

Descripción El sistema deberá ser desarrollado en ambiente web para

evitar el uso instaladores adicionales a excepción de los

requeridos por la reportería.

Tabla 7 Requerimientos No Funcionales, Planificación General del Sistema, Base

de Datos


Nombre Base de Datos




Función Definir el repositorio de almacenamiento de

información

Descripción El sistema deberá hacer uso de la Base de

Datos Postgresql.


Informacion histórica


Nombre Información histórica




Función Disponibilidad de la información

Descripción El sistema deberá permitir la disponibilidad de información

de distintos tipos de productos y servicios que ofrece el

negocio.

35

4.1.2 Planificación

En esta reunión se toman como base las necesidades de la Lubrimotos y se determinan

las funcionalidades que se incorporarán al producto, además se define lo que se

entregará al terminar el Sprint y cuál es el trabajo necesario para llevar a cabo el

incremento.

Como resultado de la reunión de planificación se entregará el objetivo del Sprint, la

Lista de Producto con la duración del Sprint y la fecha de la reunión para definir la

entrega del primer incremento para su revisión y posterior retroalimentación.

4.1.2.1 Objetivo del Spring

Como objetivos del Sprint 0: Reunión de Análisis y Planificación General del Sistema,

se determinan los siguientes:

Determinación del equipo de trabajo, definición de roles y responsabilidades.

Definición del software y ambiente de desarrollo del software, tomando en

consideración la propuesta del equipo de desarrollo, las necesidades de la

institución y la infraestructura disponible.

Definición de la Base de Datos y versión a utilizar de acuerdo a las necesidades

de la institución y la infraestructura disponible.

Diseño del prototipo de la pantalla inicial del sistema.

Instalación del ambiente de desarrollo.

Instalación del ambiente de pruebas para revisiones posteriores de cada Sprint.

4.1.2.2 Lista de Producto

Tabla 9 Lista de Producto al iniciar el Sprint 0: Análisis y Planificación General

LISTA DE PRODUCTO

Fecha Inicialización: 25 de enero del 2016

Fecha Revisión: 29 de enero del 2016

Nro. Descripción Estado

1 Definición del equipo de trabajo, roles y Pendiente

36

responsabilidades.

2 Selección de equipo servidor en las instalaciones del

negocio para Base de Datos y Servidor de Aplicaciones.

Pendiente

3 Instalación y configuración de Software de Base de

Datos.

Pendiente

4 Instalación y configuración de Software Servidor de

Aplicaciones

Pendiente

5 REQUERIMIENTO FUNCIONAL N-001: Ingreso al

Sistema

Pendiente

6 REQUERIMIENTO FUNCIONAL N-002: Salida del

Sistema

Pendiente

4.1.2.3 El equipo de Scrum

En la planificación de esta etapa se han definido el equipo de trabajo Scrum con sus

roles y responsabilidades en el desarrollo del proyecto. Para la asignación de roles del

equipo Scrum, se ha tomado en consideración que las personas designadas a cada uno

de sus roles posea un completo conocimiento de los procesos que ayuden ágilmente a

definir los requerimientos y que sea capaz de plasmar las necesidades y lo que se espera

del sistema. El equipo Scrum se encuentra conformado por el dueño del producto, el

equipo de desarrollo y el Scrum Master.

Todos los miembros del equipo son multifuncionales y auto-organizados de tal manera

que pueden optar por la mejor manera de cumplir con su trabajo.

4.1.2.3.1 El Dueño del Producto (Product Owner)

El dueño del producto es el responsable de obtener el mayor valor del producto final

para todos los participantes y usuarios del sistema. Para el desarrollo del sistema, se ha

designado al Sra. Ana Rueda, empleado y trabajador del Negocio, quién es el

responsable de manifestar, al equipo de trabajo, los deseos del Negocio en la Lista del

37

Producto. Todo requerimiento, modificación o alcance de cada Sprint será presentado a

través del Dueño de Producto.

4.1.2.3.2 El Equipo de Desarrollo (Development Team)

La programación y diseño del sistema está a cargo del autor del proyecto de titulación.

El equipo de desarrollo es el encargado de realizar todos los requerimientos que se

definan en la Lista de Producto.

4.1.2.3.3 El Scrum Master

El rol de Scrum Master está a cargo del autor del proyecto de titulación, quién es el

responsable de hacer cumplir los reglamentos de Scrum.

4.1.3 Lista de Pendientes del Sprint

En esta etapa no se han agregado tareas adicionales al inicio de la ejecución del Sprint.


Luego de elaboradas las tareas de la Lista de producto y elaboradas las iteraciones a fin

de llegar a un producto estable para revisión, se procede a la actualización de la Base de

Datos y del sistema en el equipo destinado para pruebas de Lubrimotos. El dueño del

producto y sus colaboradores realizarán las observaciones que sean pertinentes ante el

trabajo realizado y de preferencia se revisará la factibilidad de los cambios para que no

afecten la estructura general del sistema.

4.1.5 5.1.4 Mantenimiento

El mantenimiento de la Base de Datos y del servidor de aplicaciones se validará con

cada versión del sistema que se implante en producción. La Base de Datos sufrirá de

modificaciones a lo largo del desarrollo de cada Sprint y se mantendrá de ser posible

información disponible para la realización de pruebas. El servidor de aplicaciones

contendrá siempre la última versión de la aplicación con los cambios solicitados a fin de

que se genere un incremento funcional hasta llegar a un consenso en el funcionamiento

del sistema.

38

4.2 Sprint 1: Modulo de Seguridad.

El módulo de Seguridades permite gestionar el acceso a recursos del sistema. Las

restricciones de usuarios a recursos del sistema se verán reflejadas en los accesos en

módulos de gestión.

En el módulo de seguridad se han tomado en consideración las opciones que un usuario

posee para mantener la integridad de su cuenta de usuario dentro del sistema. El acceso

al sistema por medio de contraseña es el mecanismo empleado para salvaguardar la

información que puede manipular un usuario. Cada usuario es responsable de mantener

la confidencialidad de su cuenta de usuario y su contraseña.

Los usuarios con perfiles de administración poseen acceso a cierta información

confidencial con respecto a otros usuarios, razón por la que es indispensable mantener

un estricto control de acceso.

4.2.1 Análisis

Dentro del módulo de seguridades se ha tomado en consideración algunos

requerimientos tomados en cuenta en la reunión de inicialización del Sprint y

posteriormente ampliados en los Sprints Diarios. Todas las observaciones darán valor a

la Lista de Producto Final y se mostrarán en el listado de requerimientos.

Los procesos se visualizarán en un diagrama de procesos que identifiquen las acciones

realizadas por los usuarios del sistema y la integración de estos en cada proceso.


Para la definición de los procesos se han tomado en consideración los procesos

principales de los usuarios involucrados luego de haber obtenido el acceso exitoso de un

usuario en el sistema.

El Diagrama de Procesos de Seguridades se encuentra en el Anexo 2.

39


De acuerdo al diagrama de procesos diagrama de procesos de la actividad del Negocio,

se pueden definir algunos requerimientos que deben desarrollarse dentro del sistema.

Los requerimientos funcionales se realizan sobre las características que debe poseer el

sistema y los requerimientos no funcionales permiten la una integración óptima con

factores externos.

4.2.1.2.1 Requerimientos Funcionales

A continuación se detallan los requerimientos funcionales que debe poseer el sistema

dentro del Módulo de Seguridad:

Tabla 10 Requerimientos Funcionales, Módulo de Seguridad, Perfiles de Usuario


Nombre Perfiles de usuario

Fecha 1 de febrero del 2016

Módulo Seguridad


Función Registrar perfiles de usuario para dar accesos a recursos

(páginas web) de cada módulo.

Descripción Permite la inserción, búsqueda, edición y eliminación de

perfiles de usuario.

Entrada Nombre del perfil de usuario, vigencia del perfil.

Fuente Administrador del sistema

Salida Visualización de datos de ingreso, actualización, búsqueda

y eliminación. Mensajes de operaciones correctas,

incorrectas y validaciones. Listado de perfiles de usuario

creados.

Acción Ingresar, actualizar y eliminar datos para ser visualizados

en pantalla.

40

Requerimiento Ninguno.

Efectos Colaterales Acceso a diferentes recursos del sistema por cada perfil de

usuario.

Tabla 11Requerimientos Funcionales, Módulo de Seguridad, Usuarios.


Nombre Usuarios


Módulo Seguridad

Sub-módulo No aplica.

Función Ingresar los usuarios que tendrán acceso al sistema y definir

sus accesos.

Descripción Se asigna los perfiles al que pertenece el usuario

Entrada Nombre del usuario, la contraseña, la fecha de creación del

usuario, mail y la vigencia.


Salida Visualización de datos de ingreso, actualización y

búsqueda. Mensajes de operaciones correctas, incorrectas y

validaciones. Listas de usuarios.

Acción Ingresar, actualizar y eliminar datos para ser visualizados

en pantalla. Presenta información sobre los accesos que

posee cada usuario en los módulos de Gestión.

Requerimiento Perfiles de usuario y opcional tener registrado de

empleados.

Efectos Colaterales Según la configuración de cada usuario tendrá acceso a

elegir los módulos asignados.

41

Tabla 12 Requerimientos Funcionales, Módulo de Seguridad, Recursos por Perfil.


Nombre Recursos por Perfil


Módulo Seguridad


Función Asignar los recursos que estarán habilitados a un perfil de

usuario.

Descripción Para cada perfil creado se habilitará los recursos vigentes

necesarios de acuerdo a su actividad y roles que posean.

Entrada Perfil de usuarios, recursos del sistema.


Salida Lista de recursos en el menú a los que el perfil tendrá

acceso en el ingreso al sistema.

Acción Permitir o negar un recurso a un determinado perfil.

Requerimiento El sistema debe poseer recursos y perfiles de usuario

creados previamente.

Efectos Colaterales Los recursos que se habiliten para un determinado perfil de

usuario, serán los que el usuario tendrá acceso en todo el

sistema.

Tabla 13 Requerimientos Funcionales, Módulo de Seguridad, Cambio de

Contraseña


Nombre Cambiar Clave


Módulo Seguridad

42


Función Permitir a un usuario el cambio de contraseña de su cuenta.

Descripción Dentro de una sesión iniciada, cada usuario deberá poder

cambiar su contraseña de ingreso al sistema.

Entrada Dentro de la sesión activa debe ingresar la contraseña

actual, la nueva contraseña y su verificación

Fuente Usuarios.

Salida Mensajes de error o de mensaje exitoso de cambio de

contraseña.

Acción El cambio de contraseña permitirá o negará el acceso al

sistema.

Requerimiento Usuario creado previamente con una contraseña válida, que

el usuario este logueado dentro del sistema y se encuentre

activo.

Efectos Colaterales El cambio de contraseña puede realizarlo el administrador

en caso de que un usuario olvidase su clave de acceso.

Tabla 14 Requerimientos Funcionales, Módulo de Seguridad, Empleados.


Nombre Empleados


Módulo Seguridad


Función Registrar los empleados del negocio.

Descripción En el sistema se deberá registrar los empleados para que se

pueda asignar su perfil de usuario y posteriormente pueda

ingresar al sistema, también se podrá realizar después del

registro la búsqueda, edición y eliminación del empleado

Entrada Se ingresara nombres, teléfono, cedula, ruc, fecha de

43

ingreso, cargo, tipo de contrato, cargo, correo, fecha de baja

del empleado.

Fuente Administración del Sistema

Salida Mensajes de error o de mensaje exitoso que se guardó el

registro.

Acción Ingresar, actualizar y eliminar datos del empleado para ser

visualizados en pantalla.

Requerimiento Se deberá tener previamente creado los cargos y tipo de

contratos para los empleados.

Efectos Colaterales El empleado tendrá acceso a los módulos del sistema

dependiendo de su perfil de usuario asignado.

4.2.1.2.2 Requerimientos No Funcionales

Como requerimientos no funcionales se toman en consideración algunos aspectos de

seguridad necesarios para conservar la integridad de los datos.

Tabla 15 Requerimientos No Funcionales, Módulo de Seguridad, Sesiones.


Nombre Sesiones


Módulo Seguridad


Función Definir el tiempo de una sesión de usuario en el navegador

Descripción El tiempo de una sesión en un navegador deberá ser de 10

minutos. En el caso de que el tiempo de inactividad exceda

este tiempo, se solicitará volver a ingresar la contraseña

desde la página inicial.

44


Para llevar a cabo el Sprint se han establecido los objetivos que se pretenden alcanzar y

la Lista de Producto al iniciar el Sprint.

4.2.2.1 Objetivo del Sprint

Como objetivos del sprint se determinan los siguientes:

Creación de pantalla de perfiles de usuario con acceso a recursos (páginas web)

dinámicamente a fin de la configuración de accesos pueda ser modificable por

administradores del sistema.

Creación de pantalla de recursos (páginas web) y configuración de los accesos a

recursos por perfiles de usuario.

Creación de pantalla de usuarios y asignación de perfiles de usuario.

Creación de pantalla de Cambio de contraseña de usuarios.


De acuerdo a las actividades ejecutadas al finalizar el Sprint 0, se ha agregado a la lista

de producto las actividades correspondientes al Sprint 1: Módulo de Seguridades, y se

ha agregado el estado de las actividades al iniciar el Sprint 1.

Tabla 16 Lista de Producto al iniciar el Sprint 1: Módulo de Seguridades.

LISTA DE PRODUCTO

Fecha Inicialización: 2 de febrero del 2016

Fecha Revisión: 8 de febrero del 2016


1 Definición del equipo de trabajo, roles y

responsabilidades.

Ejecutado

2 Selección de equipo servidor en las instalaciones del Ejecutado

45



Datos.

Ejecutado


Aplicaciones

Ejecutado


Sistema

Ejecutado


Sistema

Ejecutado

7 REQUERIMIENTO FUNCIONAL N-004: Perfiles de

Usuario

Pendiente

8 REQUERIMIENTO FUNCIONAL N-005: Usuarios Pendiente

9 REQUERIMIENTO FUNCIONAL N-006: Recursos por

Perfil

Pendiente

10 REQUERIMIENTO FUNCIONAL N-007: Cambiar

Clave

Pendiente

11 REQUERIMIENTO FUNCIONAL N-008: Empleados Pendiente

4.2.3 Lista de Pendientes del Sprint



Luego de elaboradas las tareas de la Lista de Producto, se procede a la implementación

del sistema en las instalaciones de Lubrimotos en su primera etapa, la implementación

inicial permitirá que posteriormente se pueda verificar el desarrollo incremental del

producto y las revisiones necesarias durante la etapa de mantenimiento.

46

4.3 Sprint 2: Módulo de Compras

Uno de los procesos que se lleva dentro del negocio es adquirir mercadería para la

realización de sus distintas operaciones como son la venta de la mercadería adquirida

con su margen de ganancia y también para utilizar los productos de la mercadería

adquirida en los servicios que brinda el negocio.

4.3.1 Análisis

El negocio requiere que se tenga un registro y administración de la mercadería que se

adquiere a los proveedores lo cual se necesita un módulo de compras que permitirá

controlar el proceso de recepción de los productos, aprobar facturas de proveedores y

administrar las direcciones de los proveedores.


Para el análisis de los procesos en el módulo de compras se ha tomado en consideración

el diagrama de procesos realizado en el Sprint 0: Anexo 1 – Diagrama de procesos de la

actividad del Negocio.


De acuerdo al diagrama de procesos de la actividad del negocio presentados en el Sprint

0, se pueden definir algunos requerimientos que deben desarrollarse dentro del módulo

de Compras. Se ha tomado en consideración los requerimientos funcionales y se han

conservado los requerimientos no funcionales de procesos previos.


De acuerdo a la reunión de planificación y las reuniones mantenidas hasta el inicio del

desarrollo del módulo se han obtenido los siguientes requerimientos:

47

Tabla 17 Requerimientos Funcionales, Módulo Compras, Proveedores


Nombre Proveedores


Módulo Compras


Función Registro de los proveedores del negocio

Descripción Todo proveedor que tenga el negocio deberá ser registrado

en el sistema para posteriormente registrar la factura de

compra.

Entrada Nombre, dirección, teléfono, fax, email, celular, ruc, fecha

de ingreso, fecha de baja y nombre del representante legal.

Fuente Personal del negocio.

Salida Mensaje de registró exitoso o no y lista de proveedores

registrados

Acción Almacenamiento de información en la Base de Datos

Requerimiento Tipo de contribuyente y tipo de proveedor.

Efectos Colaterales Los datos de los proveedores registrados solo se puede

visualizar en la pantalla del sistema no hay opción de

imprimir.

Tabla 18 Requerimientos Funcionales, Módulo Compras, Factura de Compra.


Nombre Factura de Compra


48

Módulo Compras


Función Registra las factura de compras

Descripción Las compras que se realizan a los proveedores tienen sus

respectivas facturas, las cuales se las debe registrar tanto la

cabecera y el detalle de factura, para posteriormente

ingresar los artículos adquiridos al inventario. Se deberá

tener una opción en el ingreso de la factura, para que la

factura que se esté ingresando sea validad o no.

Entrada Para la cabecera de la factura: Proveedor, Serie#1 Factura,

Serie#2 Factura, Periodo contable, Numero de Factura,

Fecha de la factura, Fecha de Ingreso, Fecha de

vencimiento, Estado, Condición de Pago, Numero de

Pedido, Autorización SRI, Validar Factura, Observación,

Costos Adicionales, Subtotal 12%, IVA, descuento total ,

Total.

Para el detalle de la factura: Artículo, cantidad, valor

unitario, porcentaje y valor de descuento, valor total,

observaciones.


Salida Mensaje exitoso o no, de la factura guardada y lista de

facturar registradas.

Acción Almacenamiento de información en la Base de Datos.

Requerimiento Proveedores, Periodo Contable, Tipos de Pago y Artículo.

Efectos Colaterales Los factura registrada solo se puede visualizar en la pantalla

de sistema no hay opción de imprimir.

49

Tabla 19 Requerimientos Funcionales, Módulo Compras, Validar Factura.


Nombre Validar Factura


Módulo Compras


Función Validar la factura que se registró previamente.

Descripción Las facturas registradas anteriormente y que en el campo

validar factura este seleccionado, se deberá realizar

validación de la misma, para posteriormente ingresar en el

inventario los artículos registrados en esa factura.

Entrada Habilitar o deshabilitar la opción Validar Factura.


Salida Mensaje exitoso o no, de la confirmación de que se validó

la factura.

Acción Disminuye el número de facturas por validar.

Requerimiento Factura Registrada.

Efectos Colaterales Una vez validad la factura no se podrá volver a validar.


Para llevar a cabo el Sprint se han definido los objetivos que se pretenden alcanzar y la

lista de producto al iniciar el Sprint.

50



Registrar los Proveedores.

Registrar las Facturas de Compra.

Validar Factura.


De acuerdo a las actividades realizadas al finalizar el Sprint 1: Módulo Seguridad, se ha

agregado a la lista de producto las actividades correspondientes al Sprint 2: Módulo de

Compras.

Tabla 20 Lista de Producto al iniciar el Sprint 1: Módulo de Compras.

LISTA DE PRODUCTO





responsabilidades.

Ejecutado



Ejecutado


Datos.

Ejecutado


Aplicaciones

Ejecutado


Sistema

Ejecutado

51


Sistema

Ejecutado


Usuario

Ejecutado

8 REQUERIMIENTO FUNCIONAL N-005: Usuarios Ejecutado


Perfil

Ejecutado


Clave

Ejecutado

11 REQUERIMIENTO FUNCIONAL N-008: Empleados Ejecutado

12 REQUERIMIENTO FUNCIONAL N-009: Proveedores Pendiente

13 REQUERIMIENTO FUNCIONAL N-010: Factura de

Compra

Pendiente

14 REQUERIMIENTO FUNCIONAL N-011: Validar

Factura

Pendiente

4.3.2.3 Lista de Pendientes del Sprint

Tabla 21 Lista de Pendientes del Sprint 2: Modulo de Compras

LISTA DE PENDIENTES DEL SPRINT





Compra: Se creara una ventana para ingresar artículos

nuevos que no estén registrados en el inventario.

Pendiente

52


Luego de elaboradas las tareas de la Lista de producto del Sprint 2: Módulo Compras,

se procede a realizar la instalación de la actualización y a realizar las pruebas con

usuarios y recibir la retroalimentación correspondiente.

4.3.4 Mantenimiento

Durante la etapa de prueba y verificación del desarrollo se encontraron las siguientes

novedades que se ampliarán a la lista de producto y a los requerimientos:

Incluir un campo del nombre del usuario o empleado del negocio quien ingresa

la factura de compra.

4.4 Sprint 3: Módulo de Inventario.

El proceso que se lleva dentro de la bodega del negocio es el de ingreso y egreso de

artículos, ya sea por motivos de compra, venta o utilización de artículos para brindar

servicios. Toda actividad que está relacionada con artículos y presentaciones de estos,

debe primero ser ingresada en la bodega del negocio para los procesos posteriores por

esta razón la información de artículos debe estar constantemente actualizada.

4.4.1 Análisis

La Bodega del negocio se encarga de llevar un registro actualizado del inventario de

estos artículos y garantizar el stock en el negocio con la finalidad de que esta posea los

artículos necesarios para poder brindar el servicio a los clientes. Por lo cual se requiere

de opciones que le permitan administrar de una manera eficiente el inventario, para ello

solicita una interfaz para el ingreso de artículos al inventario, la creación de artículos y

presentaciones para controlar el inventario. Estos requerimientos se encuentran en los

requerimientos funcionales del sistema.

53


Para el análisis de los procesos en la Modulo de Inventario se ha tomado en

consideración el diagrama de procesos realizado en el Sprint 0: Anexo 1 – Diagrama de

procesos del Negocio.


De acuerdo al diagrama de procesos de la actividad del Negocio presentados en el

Sprint 0, se pueden definir algunos requerimientos que deben desarrollarse dentro del

módulo de Inventario. Se ha tomado en consideración los requerimientos funcionales y

se han conservado los requerimientos no funcionales de procesos previos.




Tabla 22 Recursos Funcionales, Modulo Inventario, Articulo


Nombre Artículos

Fecha 18 de Febrero del 2016

Módulo Inventario


Función Registrar los artículos que el negocio vende.

Descripción Los artículos deben ser registrados previamente, para

proceder con el ingreso de artículos adquiridos a los

proveedores al inventario de bodega. Cada artículo tiene

sus características y se divide en 2 tipos: Producto y

servicio.

Si un artículo registrado es un servicio, este puede tener

54

varios artículos de tipo producto, porqué en el negocio al

prestar un servicio se puede ocupar varios artículos de tipo

producto.

Entrada Nombre, marca, modelo, ubicación, grupo, imagen, unidad,

tipo, código y utilidad.


Salida Mensaje exitoso o no, del registro del artículo y también un

listado de todos los artículos registrados.

Acción Registro de artículos que serán ingresados a la bodega.

Requerimiento Tipos de artículos, grupos, ubicación y unidades.

Efectos Colaterales Identificar bien el tipo de artículo que se registra ya se

producto o servicio. Porque un artículo de tipo producto no

puede tener otros artículos de tipo producto.

Tabla 23 Recursos Funcionales, Modulo Inventario, Ingreso de Inventario.


Nombre Ingreso de Inventario.


Módulo Inventario


Función Ingresar al stock del inventario los artículos que se adquirió

a los proveedores.

Descripción Mediante las facturas de compras que se registraron

previamente en el sistema, se deberá tener un control

previo para que los artículos ingresen al stock del inventario

y mediante el método del promedio ponderado se calculara

55

el precio de venta con su respectiva utilidad del artículo.

Entrada Habilitar o deshabilitar la opción de


Salida Mensaje exitoso o no, del ingreso de los artículos

seleccionados al inventario.

Acción Incrementar el inventario.

Requerimiento Facturas de compras registradas.

Efectos Colaterales Una vez ingresado los artículos al inventario ya no se podrá

realizar su acción contraria.

Tabla 24 Recursos Funcionales, Modulo Inventario, Mantenimiento de Inventario.


Nombre Mantenimiento de Inventario.


Módulo Inventario


Función Actualizar el inventario existente.

Descripción Se podrá modificar el inventario como el valor inicial, valor

de venta, ingresos y egresos también se podrá ingresar

artículos registrados en el sistema en el inventario de cada

artículo por varios motivos que se puedan presentar en el

negocio como una la donación de artículos.

Entrada Artículo, cantidad inicial, valor de venta, ingresos, egresos

y stock


Salida Mensaje exitoso o no, del registro guardado.

56

Acción Insertar, modificar y eliminación de artículos que se

encuentran en el inventario

Requerimiento Artículos ingresados en el sistema.

Efectos Colaterales Solo se puede ingresar los artículos registrados en el

sistema.






Registro de los artículos en el sistema para su posterior ingreso al inventario.

Ingresar los artículos adquiridos por los proveedores con su respectiva factura de

compra.

Insertar, modificar y eliminar artículos que se encuentran dentro del inventario.


De acuerdo a las actividades realizadas al finalizar el Sprint 2: Módulo de Compras, se

ha agregado a la lista de producto las actividades correspondientes al Sprint 3: Módulo

de Inventario.

Tabla 25 Lista de Producto al iniciar el Sprint 3: Módulo de Inventario.

LISTA DE PRODUCTO




57


responsabilidades.

Ejecutado



Ejecutado


Datos.

Ejecutado


Aplicaciones

Ejecutado


Sistema

Ejecutado


Sistema

Ejecutado


Usuario

Ejecutado



Perfil

Ejecutado


Clave

Ejecutado


12 REQUERIMIENTO FUNCIONAL N-009: Proveedores Ejecutado


Compra

Ejecutado


Factura

Ejecutado

15 REQUERIMIENTO FUNCIONAL N-012: Artículos Pendiente

16 REQUERIMIENTO FUNCIONAL N-013:Ingreso de

Inventario

Pendiente

58

17 REQUERIMIENTO FUNCIONAL N-

014:Mantenimiento de Inventario

Pendiente



Tabla 26 Lista de Pendientes del Sprint 3: Modulo Inventario








Terminado


Luego de elaboradas las tareas de la Lista de producto del Sprint 3: Módulo de

Inventario, se procede a realizar la instalación de la actualización y a realizar las

pruebas con usuarios y recibir la retroalimentación correspondiente.

4.4.4 Mantenimiento



Observaciones:

59

En el mantenimiento de inventario se incluirá la opción de búsqueda del

producto por nombre y código.

4.5 Sprint 4: Modulo de Ventas.

El proceso que más interesa a los dueños del negocio es la venta de productos y

prestaciones de sus servicios lo cual debe ser bien gestionado por el sistema para que

exista una administración eficiente del negocio.

4.5.1 Análisis

El negocio requiere que se tenga un registro y administración de las ventas, lo cual se

necesita un módulo de ventas que permita generar órdenes de trabajo o servicio y

facturar la venta de artículos y/o las mismas órdenes de trabajo generadas. También se

debe tener un registro de sus clientes.


Para el análisis de los procesos en la Modulo de Ventas se ha tomado en consideración

el diagrama de procesos realizado en el Sprint 0: Anexo 1 – Diagrama de procesos de la

actividad del Negocio.


De acuerdo al diagrama de procesos de la actividad del negocio presentados en el Sprint

0, se pueden definir algunos requerimientos que deben desarrollarse dentro del módulo

de ventas. Se ha tomado en consideración los requerimientos funcionales y se han

conservado los requerimientos no funcionales de procesos previos.




60

Tabla 27 Requerimientos Funcionales, Módulo de Ventas, Clientes


Nombre Clientes.

Fecha 1 de Marzo del 2016

Módulo Ventas


Función Registrar a los clientes del negocio.

Descripción Los clientes del negocio deben ser registrados para que

posteriormente se generen las órdenes de trabajo y facturas

de venta.

Entrada Nombres, dirección, tipo de cliente, teléfono, celular, fax,

correo, ruc, estado (Activo/Desactivo), fecha de ingreso,

fecha de baja y observaciones.


Salida Mensaje exitoso o no, del registro guardado y listado de los

clientes.

Acción Insertar, modificar y eliminar clientes.

Requerimiento Tipo cliente.

Efectos Colaterales Los datos de los proveedores registrados solo se puede

visualizar en la pantalla del sistema no hay opción de

imprimir.

Tabla 28 Requerimientos Funcionales, Módulo de Ventas, Generación de Orden de

Trabajo


Nombre Generación de Orden de Trabajo o Servicio

61


Módulo Ventas


Función Generar y registrar la orden de trabajo para el cliente con su

respectivo comprobante.

Descripción Cuando el negocio presta servicios se debe registrar y

generar una orden de trabajo, en la cual se detalla los

servicios prestados y productos utilizados. Para que en un

proceso posterior se genere la factura de venta. Y también

se pueda imprimir la orden de trabajo y generar una

proforma.

Entrada Empleado, Año contable, Bien o activo del cliente al que se

aplicara el servicio, Hora de entrada, hora de salida,

Numero de orden, Numero de orden del cliente, Ubicación,

Trabajo adicionales, Detalle de trabajo, Subtotal, IVA,

Total, Cantidad del artículo, Artículo, Precio.


Salida Mensaje exitoso o no, del registro guardado, impresión de

la orden de trabajo y proforma.

Acción Insertar, modificar y eliminar ordenes de trabajo.

Requerimiento Cliente, empleado, bien o activo del cliente, servicios y

artículos.

Efectos Colaterales Se puede confundir la orden de trabajo con la factura de

venta porque los dos tienen total a pagar.

Tabla 29 Requerimientos Funcionales, Módulo de Ventas, Factura de Venta


Nombre Factura de Venta

62


Módulo Ventas


Función Generar y registrar la factura de venta con su respectivo

comprobante.

Descripción El negocio en su proceso de ventas, debe generar y registrar

una factura de venta con su respectivo comprobante,

detallando los artículos y/o servicios a pagar por el cliente.

Debe cargar automáticamente los precios de cada producto

en el detalle de factura y en la cabecera se desplegar el total

de la suma de los productos que se encuentran en el detalle.

También en el proceso de generar la factura de venta se

debe en ella cargar los órdenes de trabajo previamente

generados. Una vez generada la factura no se podrá

eliminar solo se podrá cambiar el estado.

Entrada Empleado, Fecha de emisión, Serie1, Serie2, Numero de

factura de venta, Fecha de vencimiento, Tipo de cobro, Año

contable, Estado, Observaciones, Descuento total,

Porcentaje de descuento, Subtotal 12, IVA, Total, Cantidad

del artículo, Articulo, Valor del artículo, Total del artículo.


Salida Mensaje exitoso o no, del registro guardado, impresión del

comprobante de la Factura de venta.

Acción Disminución el stock del inventario.

Requerimiento Cliente, empleado, servicios, artículos y órdenes de trabajo

si se los genero anteriormente.

Efectos Colaterales Se puede confundir la factura de venta con la orden de

trabajo porque los dos tienen total a pagar.

63






Registro de los clientes.

Generación de Ordenes de trabajo para prestaciones de servicios.

Generación de Factura de venta por el pago de artículos y/o servicios.


De acuerdo a las actividades realizadas al finalizar el Sprint 3: Módulo de Inventario, se

ha agregado a la lista de producto las actividades correspondientes al Sprint 4: Módulo

de Ventas.

Tabla 30 Lista de Producto al iniciar el Sprint 4: Módulo de Ventas.

LISTA DE PRODUCTO

Fecha Inicialización: 2 de Marzo del 2016

Fecha Revisión: 15 de Marzo del 2016



responsabilidades.

Ejecutado



Ejecutado

64


Datos.

Ejecutado


Aplicaciones

Ejecutado


Sistema

Ejecutado


Sistema

Ejecutado


Usuario

Ejecutado



Perfil

Ejecutado


Clave

Ejecutado




Compra

Ejecutado


Factura

Ejecutado

15 REQUERIMIENTO FUNCIONAL N-012: Artículos Ejecutado


Inventario

Ejecutado



Ejecutado

18 REQUERIMIENTO FUNCIONAL N-015: Clientes Pendiente

65

19 REQUERIMIENTO FUNCIONAL N-016: Generación

de Orden de Trabajo.

Pendiente

20 REQUERIMIENTO FUNCIONAL N-017: Facturas

Ventas

Pendiente


Tabla 31 Lista de Pendientes del Sprint 4: Modulo de Ventas




Nro. Descripción.

Estado




Terminado

2 REQUERIMIENTO FUNCIONAL N-015: Clientes:

Crear una pantalla para registrar el activo o bien del

cliente que se le aplicara el servicio.

Pendiente


Luego de elaboradas las tareas de la Lista de producto del Sprint 4: Módulo de Ventas,

se procede a realizar la instalación de la actualización y a realizar las pruebas con

usuarios y recibir la retroalimentación correspondiente.

4.5.4 Mantenimiento

66



Observaciones:

En la pantalla de generación de orden de trabajo y Factura de Venta en la parte

del detalle agregar un campo del stock del producto.

4.6 Sprint 5: Módulo de Reportes

Un reporte es un documento generado por el Sistema que presenta de manera

estructurada y ordenada los datos almacenados de tal manera que se vuelvan útiles para

su interpretación.

4.6.1 Análisis

Para este módulo se generara en el Sistema los reportes más importantes y útiles para

el negocio como Reporte Ejecutivo Ventas, Reporte Detalle Ejecutivo Ventas, Reporte

de Cliente con sus bienes y Reporte de Ordenes de Trabajo.


Dentro de los requerimientos funcionales se encuentran los definidos en la reunión de

planificación del Sprint y alcances definidos en reuniones posteriores.

Tabla 32 Requerimientos Funcionales, Módulo de Reportes, Reporte Ejecutivo de

Ventas


Nombre Reporte Ejecutivo de Ventas


Módulo Reportes


Función Obtener un listado de todas las facturas de venta generadas.

67

Descripción En un rango de fechas se puede conocer todas las facturas

de venta generadas y con un total de lo vendido con un

acceso que da la opción de exportar el reporte a PDF.

Entrada Fecha de Inicio y fecha fin.

Fuente Datos del Sistema

Salida Documento en formato PDF con el listado de todas las

facturas de venta generadas con su total vendido.

Acción Filtrar las facturas de venta por fechas y una suma de los

totales de las mismas.

Requerimiento Facturas de Venta generadas.

Efectos Colaterales Ninguno.

Tabla 33 Requerimientos Funcionales, Modulo de Reportes, Reporte Detalle

Ejecutivo de Ventas


Nombre Reporte Detalle Ejecutivo de Ventas


Módulo Reportes


Función Obtener un listado de todos los artículos vendidos.

Descripción En un rango de fechas se puede conocer el detalle de todos

los artículos vendidos, con un acceso que da la opción de

exportar el reporte a PDF.



68

Salida Documento en formato PDF con el listado del detalle de

todos los artículos vendidos.

Acción Filtrar los productos vendidos por fechas y una suma de los

totales de las mismas.

Requerimiento Facturas de Venta generadas.


Tabla 34 Requerimientos Funcionales, Modulo de Reportes, Reporte de Clientes.


Nombre Reporte de Clientes


Módulo Reportes


Función Obtener un listado de todos los clientes con sus bienes.

Descripción Visualizar los datos de los clientes con sus bienes, con un

acceso que da la opción de exportar el reporte a PDF.

Entrada Ninguno


Salida Documento en formato PDF con el listado de los datos de

los clientes con sus bienes.

Acción Seleccionar todos los clientes.

Requerimiento Clientes registrados.


69

Tabla 35 Requerimientos Funcionales, Módulo de Reportes, Reporte de Ordenes

de Trabajo.


Nombre Reporte de Ordenes de Trabajo.


Módulo Reportes


Función Obtener un listado de todos los Órdenes de Trabajo

generados.

Descripción En un rango de fechas se puede conocer todas las Órdenes

de Trabajo generadas, con un acceso que da la opción de

exportar el reporte a PDF.



Salida Documento en formato PDF con el listado de las Órdenes

de Trabajo generadas.

Acción Filtrar las Órdenes de Trabajo por fecha.

Requerimiento Ordenes de Trabajo generadas.





70



Generar Reporte Ejecutivo de Ventas.

Generar Reporte Detalle Ejecutivo de Ventas.

Generar Reporte De Clientes.

Generar Reporte Ordenes de trabajo.


De acuerdo a las actividades realizadas al finalizar el Sprint 4: Módulo de Ventas, se ha

agregado a la lista de producto las actividades correspondientes al Sprint 5: Módulo de

Reportes.

Tabla 36 Lista de Producto al iniciar el Sprint 5: Módulo de Reportes.

LISTA DE PRODUCTO





responsabilidades.

Ejecutado



Ejecutado


Datos.

Ejecutado


Aplicaciones

Ejecutado


Sistema

Ejecutado

6 REQUERIMIENTO FUNCIONAL N-002: Salida del Ejecutado

71

Sistema


Usuario

Ejecutado



Perfil

Ejecutado


Clave

Ejecutado




Compra

Ejecutado


Factura

Ejecutado



Inventario

Ejecutado



Ejecutado

18 REQUERIMIENTO FUNCIONAL N-015: Clientes Ejecutado



Ejecutado


Ventas

Ejecutado

21 REQUERIMIENTO FUNCIONAL N-018: Reporte

Ejecutivo de Ventas.

Pendiente

22 REQUERIMIENTO FUNCIONAL N-019:Reporte Pendiente

72

Detalle Ejecutivo de Ventas

23 REQUERIMIENTO FUNCIONAL N-020: Reporte de

Clientes

Pendiente


Ordenes de Trabajo.

Pendiente



Tabla 37 Lista de Pendientes del Sprint 5: Modulo de Reportes




Nro. Descripción.

Estado




Terminado

2 REQUERIMIENTO FUNCIONAL N-015: Clientes:

Crear una pantalla para registrar el activo o bien del

cliente que se le aplicara el servicio.

Terminado


Luego de elaboradas las tareas de la Lista de producto del Sprint 5: Módulo de

Reportes, se procede a realizar la instalación de la actualización y a realizar las pruebas

con usuarios y recibir la retroalimentación correspondiente.

73

4.6.4 Mantenimiento



Observaciones:

En el reporte de Clientes detallar bien los bienes que posee el Cliente

4.7 Producto Terminado

Al finalizar las actividades de la Lista de Producto se llega a la evaluación integral de

los módulos y la puesta en producción. Se deja como constancia de las actividades

finalizadas con el cierre de la Lista de Producto.

4.7.1 Lista de Producto

De acuerdo a las actividades realizadas al finalizar el Sprint 5: Módulo de Reportes, se

ha culminado con las actividades de la Lista de Producto.

Tabla 38 Lista de Producto al finalizar el Sprint 5: Módulo de Reportes

LISTA DE PRODUCTO





responsabilidades.

Ejecutado



Ejecutado


Datos.

Ejecutado


Aplicaciones

Ejecutado

74


Sistema

Ejecutado


Sistema

Ejecutado


Usuario

Ejecutado



Perfil

Ejecutado


Clave

Ejecutado




Compra

Ejecutado


Factura

Ejecutado



Inventario

Ejecutado



Ejecutado

18 REQUERIMIENTO FUNCIONAL N-015: Clientes Ejecutado



Ejecutado


Ventas

Ejecutado

75

21 REQUERIMIENTO FUNCIONAL N-018: Reporte

Ejecutivo de Ventas.

Ejecutado

22 REQUERIMIENTO FUNCIONAL N-019:Reporte

Detalle Ejecutivo de Ventas

Ejecutado


Clientes

Ejecutado


Ordenes de Trabajo.

Ejecutado

76

CAPÍTULO V

5. CONCLUSIONES Y RECOMENDACIONES

5.1 CONCLUSIONES

De acuerdo a la forma de trabajo y lo plasmado en el documento se puede concluir que:

De acuerdo a lo planteado en los Objetivos se logró entregar al Negocio

Minorista un sistema que permite agilizar el proceso de facturación tal como se

detalla en la Tabla 28 (Recursos Funcionales, Modulo Ventas, Generación de

Orden de Trabajo) y Tabla 29 (Requerimientos Funcionales, Modulo de Ventas,

Factura de Venta), de una forma fácil y rápida, con un óptimo manejo o

administración del inventario del Negocio tal como se detalla en la Tabla 23

(Recursos Funcionales, Modulo Inventario, Ingreso de Inventario) y Tabla 24

(Recursos Funcionales, Modulo Inventario, Mantenimiento de Inventario).

El sistema también dispone de la información relevante del negocio como la de

los proveedores, clientes e inventario del negocio, detallado en la Tabla 17

(Requerimientos Funcionales, Modulo Compras, Proveedores), Tabla 27

(Requerimientos Funcionales, Modulo de Ventas, Clientes) y Tabla 24

(Requerimientos Funciones, Modulo Inventario, Manteni8miento de Inventario).

También dispone del registro de todos sus ingresos y egresos del negocio,

mediante el registro de las facturas tanto de compra y venta, ingresadas

anteriormente al sistema, en la cual se detalla en la Tabla 18 (Requerimientos

Funcionales, Modulo Compras, Factura Compra) y Tabla 29 (Requerimientos

Funcionales, Modulo de Ventas, Factura de Venta).

El sistema permite generar reportes de consolidación de productos vendidos y

del dinero recaudado, de las ventas realizadas en el negocio, tal como se detalla

en la Tabla 32 (Requerimientos Funcionales, Modulo de Reportes, Reporte

Ejecutivo de Ventas) y la Tabla 33 (Requerimientos Funcionales, Modulo de

Reportes, Reporte Detalle Ejecutivo).

77

La revisión constante y adecuada del producto en cada módulo, elude

dificultades y desviaciones en los objetivos planteados, aunque cada módulo se

considere un producto no terminado.

El trabajo constante y una buena comunicación dio como resultado obtener un

sistema web con una interfaz amigable y útil que permite gestionar la

información diaria de las actividades del negocio, esto permitirá incrementar el

desempeño del personal.

El uso de una metodología ágil motivó al equipo de trabajo en todas las etapas

de desarrollo ya que se mostraron los avances de la programación y se iban

corrigiendo las observaciones oportunamente.

5.2 RECOMENDACIONES

De acuerdo a la implementación de la factura física en el sistema, en la cual se

detalla en la Tabla 29 (Requerimientos Funcionales, Modulo de Ventas, Factura

de Venta), se recomienda la implementación de la facturación electrónica en el

sistema ya que reduce en tiempos y costos en los procesos de compra, venta y

gestión de cobros a clientes y pagos a proveedores. Agiliza procesos de

almacenamiento y consulta de facturas.

De la implementación del ingreso de artículos en el detalle de la factura de

venta, detallado en la Tabla 29 (Requerimientos Funcionales, Modulo de Ventas,

Factura de Venta), se recomienda una adaptación de un a lector de código de

barras al sistema, para la identificación automática de los artículos que ofrezca

el negocio, lo cual mejora la exactitud de los datos y abra una mayor precisión

de la información.

La mayor parte de la información es delicada a la intromisión de personas no

autorizadas, razón por la que se recomienda un minucioso análisis en los perfiles

a los que debe pertenecer un usuario para evitar comportamientos del sistema

inesperados debido a información corrupta.

Se recomienda por seguridad de la información tener la costumbre de cambiar

las contraseñas habitualmente y no proporcionar a otras personas por ningún

motivo.

De acuerdo a la cantidad de información ingresada diariamente, se recomienda

sacar respaldos de la información de la Base de Datos con una alta frecuencia

78

para poder levantar nuevamente el Sistema en casos de daño de hardware,

sistema operativo o factores externos. El respaldo de la aplicación debe contener

instaladores, versionamiento de la aplicación y respaldos de la Base de Datos.

79

BIBLIOGRAFÍA

1. MONTORO, S. (2013). Cómo seleccionar una plataforma de desarrollo para un

proyecto web. Recuperado de http://lapastillaroja.net/2013/10/como-seleccionar-

plataformatecnologica/.

2. BELMONTE, F. (2010). Introducción a la plataforma Java EE. Recuperado de

http://parasitovirtual.com/2010/12/13/introduccion-a-la-plataformajava- ee/.

3. PASTRANA, M. (2011). Arquitectura. Recuperado de

https://manuelpastrana.wikispaces.com/3.+Arquitectura.

4. ESTRUGA, X. (2013). Las cinco etapas de ingeniería de software. Recuperado

de http://proyectosguerrilla.com/blog/2013/02/las-cinco-etapas-en-laingenieria-

del-software/.

5. VIÑE, E. (2010). Introducción a Primefaces. Recuperado de

http://www.adictosaltrabajo.com/tutoriales/introduccion-primefaces/.

6. SANCHEZ, J. (2010). Introducción a RichFaces. Recuperado de

http://www.adictosaltrabajo.com/tutoriales/rich-faces-jsf-intro/.

7. ANÓNIMO. (2011). Adiós JSPbienvenido JavaServer Faces. Recuperado

dehttp://www.javamexico.org/blogs/sr_negativo/adios_jsp_bienvenido_javaserv

er_faces.

8. PRIMETEK. (2010). Documentación. Recuperado de

http://www.primefaces.org/documentation/.

9. BENJA, B. (2016). JasperReports. Recuperado de

https://es.wikipedia.org/wiki/JasperReports.

10. JUNTA DE ANDALUCIA. (2014). IReport. Recuperado de

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/238.

11. SOURCEFORGE.NET. iReport and JasperReports basic concepts. Recuperado

de http://ireport.sourceforge.net/cap3.html.

12. MARTINEZ, R. (2010). Sobre PostgreSQL. Recuperado de

http://www.postgresql.org.es/sobre_postgresql.

13. SOFTWARE FOERVER, R. (2011). Tipos de Licencia. Recuperado de

https://sites.google.com/site/sofwarefoerver/tipos-de-licencia.

http://lapastillaroja.net/2013/10/como-seleccionar-plataformatecnologica/

http://lapastillaroja.net/2013/10/como-seleccionar-plataformatecnologica/

http://parasitovirtual.com/2010/12/13/introduccion-a-la-plataformajava-

https://manuelpastrana.wikispaces.com/3.+Arquitectura

http://www.adictosaltrabajo.com/tutoriales/introduccion-primefaces/

http://www.adictosaltrabajo.com/tutoriales/rich-faces-jsf-intro/

http://www.javamexico.org/blogs/sr_negativo/adios_jsp_bienvenido_j

https://es.wikipedia.org/wiki/JasperReports

http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/238

http://www.postgresql.org.es/sobre_postgresql

https://sites.google.com/site/sofwarefoerver/tipos-de-licencia

80

14. FMARILUIS. (2016). PostgreSQL. Recuperado de

https://es.wikipedia.org/wiki/PostgreSQL.

15. MOSCORRO, A. (2015). Proceso de software y gestión de proyectos de software.

Recuperado de http://slideplayer.es/slide/2758191/.

16. NORIVER. (2012). Desarrollo iterativo e incremental. Recuperado de

http://es.slideshare.net/noriver/desarrollo-iterativo-e-incremental.

17. PEREZ, O. (2008). Fases del Proceso de Desarrollo del Software. Recuperado de

https://sistemasvd.wordpress.com/2008/07/05/.

18. PEREZ, O. (2008). Fases del Proceso de Desarrollo del Software. Recuperado de

https://sistemasvd.wordpress.com/2008/07/05/.

19. SCHENONE, M.(2004). Diseño de una Metodología ágil de Desarrollo de

Software. Recuperado de http://materias.fi.uba.ar/7500/schenone-

tesisdegradoingenieriainformatica.pdf.

20. SANAIS, G.(2016). Desarrollo iterativo y creciente. Recuperado de

https://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente.

21. PROYECTOSAGILES.org.(2014). Desarrollo iterativo e incremental.

Recuperado de http://www.proyectosagiles.org/desarrollo-iterativo-incremental.

22. CENDEJAS, J.(2015). Modelos y metodología para el desarrollo de software.

Recuperado de http://www.eumed.net/tesis doctorales/2014/jlcv/software.htm .

23. JUMMP.(2011). Desarrollo de software. Ciclo de vida iterativo incremental.

Recuperado de https://jummp.wordpress.com/2011/03/31/desarrollo-de-

softwareciclo- de-vida-iterativo-incremental/.

24. KENNETH e. Kendall, Julie e. Kendall. (2011). Análisis y diseño de sistemas.

Octava edición. México: PEARSON EDUCACIÓN.

25. IAN Sommerville. (2011). Ingeniería de Software, 9na Edición. México:

Pearson Educación de México.

26. PALACIO J. (2006). El modelo Scrum : NST-0010.

27. PRESSMAN, R. S. (2010). Ingeniería de Software. México: Mc Graw Hill.

28. CENTERS FOR MEDICARE & MEDICAID SERVICES. (2008). Selecting A

Development Approach. USA: DHHS.

29. IEEE. (2014). Engineering Body of Knowledge. Washington: Jennie Zhu-Mai.

http://slideplayer.es/slide/2758191/

http://es.slideshare.net/noriver/desarrollo-iterativo-e-incremental

https://sistemasvd.wordpress.com/2008/07/05/

https://sistemasvd.wordpress.com/2008/07/05/

https://es.wikipedia.org/wiki/Desarrollo_iterativo_y_creciente

http://www.proyectosagiles.org/desarrollo-iterativo-incremental

http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm

81

ANEXOS

82

Anexo 1 Diagrama de Procesos de la Actividad del Negocio

PROCESO: ATENCION DEL NEGOCIO

SIS

TE

MA

DE

FA

CT

UR

AC

ION

Y C

ON

TR

OL

DE

IN

VE

NT

AR

IO P

AR

A A

DM

INIS

TR

AR

NE

GO

CIO

S D

E S

ER

VIC

IOS

Y M

INO

RIS

TA

S

CLIENTE

EMPLEADO (CAJA)

EMPLEADO

(SERVICIO)

ADMINISTRADOR

PROVEEDOR

PREGUNTA

DISPONIBLIDAD

DE ARTICULOS

QUE NECESITA

INGRESA

CLIENTE AL

NEGOCIO

BUSCA EN EL

SISTEMA LOS

ARTÍCULOS

FACTURA LA

VENTA DE LOS

ARTICULOS

CONFIRMA LA

COMPRA

COMPROBANT

E DE LA

FACTURA

SOLICITA LA

PRESTACION

DE UN

SERVICIO

GENERA LA

ORDEN DE

TRABAJO

EJECUTA LA

ORDEN DE

TRABAJO

COMPROBANT

E DE LA ORDEN

DE TRABAJO

ENTREGA DEL

PEDIDO

SOLICITA

PEDIDO DE

COMPRA

REVISION DE

STOCK DE

INVENTARIO

RECEPCION DEL

PEDIDO

REGISTRO DE

LA FACTURA DE

COMPRA EN EL

SISTEMA

INGRESO DE

LOS ARTICULOS

ADQUIRIDOS

AL INVENTARIO

83

Anexo 2 Diagrama de Procesos de Seguridades

PROCESO: SEGURIDADES S

IST

EM

A D

E F

AC

TU

RA

CIO

N Y

CO

NT

RO

L D

E I

NV

EN

TA

RIO

PA

RA

AD

MIN

IST

RA

R N

EG

OC

IOS

DE

SE

RV

ICIO

S Y

MIN

OR

IST

AS

USUARIO ADMINISTRADOR

INICIO

CREAR UN PERFIL DE

USUARIO

ASIGNAR ACCESO A LOS

RECURSOS AL PERFIL DE

USUARIO

CREAR UN NUEVO

USUARIO

EL USUARIO

POSEE OTRO

PERFIL DE

USUARIO

ABRIR EL NAVEGADOR Y

PÁGINA DEL SISTEMA

INGRESAR CREDENCIALES

AL SISTEMA

VISUALIZACION DEL

MENU PRINCIPAL DEL

SISTEMA

CREDENCIALES

VALIDAS

FIN

ASIGNAR PERFIL DE

USUARIO AL USUARIO

UNIVERSIDAD CENTRAL DEL ECUADOR … · 3.1 Metodologías tradicionales del desarrollo del...

Documents

Transcript of UNIVERSIDAD CENTRAL DEL ECUADOR … · 3.1 Metodologías tradicionales del desarrollo del...