ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/4768/1/CD-4383.pdf · DESARROLLO...

ESCUELA POLITÉCNICA NACIONAL

FACULTAD DE INGENIERÍA DE SISTEMAS

DESARROLLO DEL PORTAL WEB Y DE LA INTRANET PARA LA

EMPRESA SERVICIOS Y LUJOS ONLY CARS SC.

PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN

ELEANA INÉS JEREZ VILLOTA

[email protected]

EDGAR ANDRÉS TELLO LEÓN

[email protected]

DIRECTOR: MSC. ING. MARCOS RAÚL CÓRDOVA BAYAS

[email protected]

Quito, Mayo 2012

DECLARACIÓN

Nosotros, Eleana Inés Jerez Villota, Edgar Andrés Tello León, declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría; que no ha sido previamente presentada para ningún grado o calificación profesional; y, que hemos consultado las referencias bibliográficas que se incluyen en este documento.

A través de la presente declaración cedemos nuestros derechos de propiedad intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional, según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por la normatividad institucional vigente.

Eleana Inés Jerez Villota Edgar Andrés Tello León

CERTIFICACIÓN

Certifico que el presente trabajo fue desarrollado por Eleana Inés Jerez Villota y Edgar Andrés Tello León, bajo mi supervisión.

Msc. Ing. Raúl Córdova

DIRECTOR DE PROYECTO

AGRADECIMIENTO

A mi Padre Santo por acompañarme durante todos los días de mi carrera y por

colmarme de bendiciones, a la virgen María por darme la oportunidad de empezar

y terminar mis estudios profesionales. A mis padres Rosita Elena y José Napoleón

por su amor y apoyo incondicional, por su arduo trabajo para brindarnos la mejor

educación a mí y a mis hermanos.

Eleana.

AGRADECIMIENTO

Agradezco a Dios por todas las bendiciones recibidas, a mi madre Rocío por todo

el sacrificio, el esfuerzo, la dedicación y en especial por todo el amor que me ha

brindado incondicionalmente en toda mi vida, a mi padre Edgar por que gracias a

su perseverancia, enseñanzas y cariño ha hecho de mi un hombre y un

profesional de bien, a mis hermanas Salome y Carol por apoyarme y ayudarme

siempre, a mis primos y tíos que me han apoyado a lo largo de mi vida.

Andrés.

DEDICATORIA

Este proyecto está dedicado con todo el amor del mundo a mis padres por su

cariño y apoyo durante toda mi vida.

Eleana.

DEDICATORIA

Esta tesis se la dedico a mi madre porque en gran parte este título se lo debo a

ella.

Andrés.

CONTENIDO

CAPÍTULO 1: PLANTEAMIENTO DEL PROBLEMA…………………..……………1

1.1. CARACTERIZACIÓN DE LA EMPRESA………………….…………………...1

1.1.1. PLAN ESTRATÉGICO DE LA EMPRESA……………………..………2

1.2. DESCRIPCIÓN DEL PROBLEMA………………………………………………3

1.2.1. SITUACIÓN ACTUAL……………………………..………...……………3

1.2.1.1. Descripción de los procesos internos de la empresa…………3

1.2.1.1.1. Proceso de adquisición…………………………………...3

1.2.1.1.2. Proceso de inventario……………………………………..4

1.2.1.1.3. Proceso de facturación……………………………………5

1.2.1.1.4. La empresa maneja su publicidad de la siguiente manera…………………………………………………………….5

1.2.1.2. Estructura organizacional de la empresa………………………5

1.2.1.2.1. Departamento de Abastecimiento y Compras………....6

1.2.1.2.2. Departamento de Marketing y Ventas…………………..7

1.2.1.2.3. Departamento Financiero………………………………...9

1.2.1.2.4. Departamento de Recursos Humanos………………...10

1.3. JUSTIFICACIÓN DE LA METODOLOGÍA……………………………………11

1.3.1. METODOLOGÍA SCRUM………………………………………………..12

1.3.1.1. Características de Scrum……………………………………….12

1.3.1.2. Roles en Scrum………………………………………………….13

1.3.1.2.1. Roles "Cerdo"…………………………………………….14

1.3.1.2.2. Roles "Gallina"……………………………………………14

1.3.1.3. Reuniones en Scrum…………………………………………….14

1.3.1.3.1. Daily Scrum……………………………………………….14

1.3.1.3.2. Reunión de Planificación del Sprint (Sprint Planning Meeting)……………………………………………………...….15

1.3.1.3.3. Reunión de Revisión del Sprint…..…………………….15

1.3.1.3.4. Reunión de Retrospectiva del Sprint…………………..16

1.3.1.4. Sprint………………………………………………………………17

1.3.1.5. Documentos………………………………………………………17

1.3.1.5.1. Product backlog………………………………………….17

1.3.1.5.2. Sprint backlog…………………………………………….17

1.3.1.5.3. Burn down chart..………………………………………...18

1.3.1.5.4. Pila de Entrega y Gráfica de Trabajo Restante……....18

1.3.1.6. Seguimiento Diario del Sprint…………………………………..19

1.3.1.6.1. Pizarra Física……………………………………………..20

1.3.1.6.2. Herramienta colaborativa o de Gestión de Proyecto...20

1.3.1.6.3. Hoja de Cálculo…………….…………………………….21

1.3.2. JUSTIFICACIÓN DE LA METODOLOGÍA EN FUNCIÓN DE LAS

CARACTERÍSTICAS DEL PROYECTO…………………………………..23

1.4. JUSTIFICACIÓN DE CMS Y DE LAS HERRAMIENTAS DE DESARROLLO…………………………………………………………………..24

1.4.1. JUSTIFICACIÓN DE CMS……………………………………………….24

1.4.1.1. Definición del CMS Joomla……………………………………..25

1.4.1.1.1. Funcionalidad de Joomla…………………………….....25

1.4.1.1.2. Características de Joomla………………………………26

1.4.1.1.3. Requisitos del Sistema………………………………….28

1.4.1.2. Justificación del CMS en función de los requerimientos para el sitio web……………………………………………………………….29

1.4.2. JUSTIFICACIÓN DE LAS HERRAMIENTAS DE DESARROLLO…....31

1.4.2.1. Navegador web…………………………………………………..31

1.4.2.2. Lenguaje de programación……………………………………..31

1.4.2.3. Base de datos……………………………………………………32

1.4.2.4. Otras herramientas………………………...……………………32

CAPÍTULO 2: PRIMERA ITERACIÓN DEL SISTEMA……………………………..34

2.1. ANÁLISIS DE REQUERIMIENTOS DE NEGOCIO DE LA EMPRESA…...34

2.1.1. PRESENTACIÓN DEL EQUIPO DE TRABAJO Y ROLES…………34

2.1.2. DESARROLLO DEL PRODUCT BACKLOG…………………………34

2.2. PLANIFICACIÓN DEL PRIMER SPRINT…...……………...……………......41

2.3. AVANCE DIARIO DEL SPRINT………..……………………………………...44

2.4. ELABORACIÓN DE LA VERSIÓN 1.0 DEL SISTEMA……………………..45

2.4.1. ARQUITECTURA Y BASE DE DATOS DEL SISTEMA…………….45

2.4.1.1. Arquitectura del Sistema………………………………………..45

2.4.1.2. Diseño de Base de Datos……………………………………….48

2.4.2. GESTIÓN DE AGENTES COMERCIALES…………………………..52

2.4.2.1. Clientes……………………………………………………………53

2.4.2.1.1. Insertar Cliente…………………………………………...53

2.4.2.2. Proveedores……………………………………………………...53

2.4.2.2.1. Insertar Proveedor……………………………………….54

2.4.3. GESTIÓN DE PRODUCTOS…………………………………………..54

2.4.3.1. Tipos de Producto……………………………………………….55

2.4.3.1.1. Insertar Tipo de Producto……………………………….55

2.4.3.2. Productos…………………………………………………………56

2.4.3.2.1. Insertar Producto…………………………………………56

2.4.4. GESTIÓN DE FACTURACIÓN………………………………………...58

2.4.4.1. Facturas de los Clientes………………………………………...58

2.4.4.1.1. Insertar Factura…………………………………………..58

2.4.4.1.2. Modificar Factura………………………………………...60

2.4.4.2. Facturas de los Proveedores……………………………...……62

2.4.4.2.1. Ingresar Factura de Proveedor………………….……..62

2.5. PRUEBAS DE LA VERSIÓN 1.0 DEL SISTEMA………………………..…..64

2.5.1. PRUEBAS DE GESTIÓN DE AGENTES COMERCIALES…….…..65

2.5.1.1. Pruebas de Clientes……………………………………………..65

2.5.1.2. Pruebas de Proveedores…………………………………….....67

2.5.2. PRUEBAS DE GESTIÓN DE PRODUCTOS…………………………70

2.5.3. PRUEBAS GESTIÓN DE FACTURACIÓN…………………………...73

CAPÍTULO 3: SEGUNDA ITERACIÓN DEL SISTEMA…………………………...79

3.1. REVISIÓN DE LA DOCUMENTACIÓN ANTERIOR………………….……..79

3.1.1. REVISIÓN DEL SPRINT ANTERIOR…………………………………79

3.1.2. REUNIÓN DE RETROSPECTIVA DEL SPRINT…………………….83

3.1.3. PILA DE ENTREGA Y GRÁFICA DE TRABAJO RESTANTE……..85

3.2. PLANIFICACIÓN DEL SEGUNDO SPRINT………………………………….86

3.3. AVANCE DIARIO DEL SPRINT……………………………………………….88

3.4. ELABORACIÓN DE LA VERSIÓN 2.0 DEL SISTEMA…………………......91

3.4.1. GESTIÓN DE COBROS Y PAGOS……………………………………91

3.4.1.1. Cobros……………………………………………………............92

3.4.1.1.1. Buscar Movimientos……………………………………..92

3.4.1.1.2. Ver cobros………………………………………………...93

3.4.1.1.3. Insertar Cobro…………………………………………….94

3.4.1.2. Pagos……………………………………………………………95

3.4.1.2.1. Buscar Movimientos……………………………………..95

3.4.1.2.2. Ver pagos………………………………………..............96

3.4.1.2.3. Insertar pago……………………………………………..97

3.4.2. REPORTES………………………………………………………………98

3.4.2.1. Caja Diaria………………………………………………………..98

3.4.2.1.1. Buscar Detalles de Cierre de Caja……………………..99

3.4.2.1.2. Imprimir Detalles de Cierre de Caja……………………99

3.4.2.2. Libro Diario……………………………………………………...100

3.4.2.2.1. Buscar Movimientos……………………………...........100

3.4.2.2.2. Imprimir Movimientos…………………………………..101

3.4.3. COPIAS SEGURIDAD…………..…………………………………….102

3.4.3.1. Hacer copia……………………………………………………..103

3.4.3.1.1. Crear Copia de Seguridad…………………………….103

3.4.3.2. Restaurar copia…………………………………………………104

3.4.3.2.1. Buscar Copias de Seguridad………………………….105

3.4.3.2.2. Restaurar Copia de Seguridad………………………..106

3.4.3.2.3. Eliminar Copia de Seguridad………………………….107

3.4.4. CREACIÓN DE PÁGINA WEB INFORMATIVA…………………….108

3.4.4.1. Instalación de Joomla………………………………………….108

3.4.4.2. Diseño de sitio web…………………………………………….109

3.4.4.3. Instalación de plantilla…………………………………………112

3.4.4.4. Creación de contenidos………………………………………..112

3.4.4.5. Creación de menús…………………………………………….113

3.4.4.6. Creación de módulos…………………………………………..115

3.5. PRUEBAS DE LA VERSIÓN 2.0 DEL SISTEMA…………………………..116

3.5.1. PRUEBAS DE GESTIÓN DE COBROS Y PAGOS………………..116

3.5.1.1. Pruebas de Cobros…………………………………………….116

3.5.1.2. Pruebas de Pagos……………………………………………..118

3.5.2. PRUEBAS DE REPORTES…………………………………………..119

3.5.3. PRUEBAS DE COPIAS DE SEGURIDAD…………………………..121

3.5.4. PRUEBAS DEL SITIO WEB………………………………………..…123

3.6. ANÁLISIS DE RESULTADOS………………………………………………..128

CAPÍTULO 4: CONCLUSIONES Y RECOMENDACIONES…………………….130

4.1. CONCLUSIONES………………………………………………………….......130

4.2. RECOMENDACIONES……………………………..…………………………131

GLOSARIO……………………………………………………………………………..132

BIBLIOGRAFÍA……………………………………………………………………......136

ANEXOS………………………………………………………………………………..138

ÍNDICE DE FIGURAS

Figura 1.1 Organigrama propuesto de la Empresa……………….………………..…6

Figura 1.2 Pila de Entrega……………………………………………..……………….19

Figura 1.3 Gráfica de Trabajo Restante………………………………………………19

Figura 1.4 Ejemplos de Tablero de Sprint……………………………………………20

Figura 1.5 Ejemplos de hoja de cálculo del Sprint…………………………………..22

Figura 1.6 Proceso de trabajo del Scrum…………………………………………….22

Figura 2.1 Estructura de Historia de Usuario………………………………………...35

Figura 2.2 Sprint backlog completo…………………...………………………………46

Figura 2.3 Burn down chart…………………………………………………………….45

Figura 2.4 Arquitectura de 3 capas……………………………………………………48

Figura 2.5 Modelo Conceptual de la Base de Datos………………………………..50

Figura 2.6 Modelo Físico de la Base de Datos………………………………………51

Figura 2.7 Selección del menú Agentes Comerciales………………………………52

Figura 2.8 Interface Insertar Cliente…………………………………………………..53

Figura 2.9 Código Insertar Cliente…..………………………………………………...53

Figura 2.10 Interface Insertar Proveedor……………………………………………..54

Figura 2.11 Código Insertar Proveedor……………………………………………….54

Figura 2.12 Selección del menú Gestión de Productos…………………………….55

Figura 2.13 Interface Insertar Tipo de Producto……………………………………..56

Figura 2.14 Código Insertar Tipo de Producto……………………………………….56

Figura 2.15 Interface Insertar Producto……………………………………………….57

Figura 2.16 Código Insertar Producto…………………………………………………57

Figura 2.17 Selección del menú Gestión de Facturación…………………………..58

Figura 2.18 Interface Insertar Factura………………………………………………...59

Figura 2.19 Código Insertar Factura…………………………………………………..59

Figura 2.20 Interface Modificar Factura………………………………………………60

Figura 2.21 Código Modificar Factura………………………………………………...61

Figura 2.22 Interface Insertar Factura de Proveedor………………………………..62

Figura 2.23 Código Insertar Factura de Proveedor………………………………….63

Figura 3.1 Gráfica de Trabajo restante de la entrega……………………………….86

Figura 3.2 Sprint backlog completo….………………………………………………..90

Figura 3.3 Burn down chart…………………………………………………………….89

Figura 3.4 Selección del menú Gestión de Cobros y Pagos……………………….91

Figura 3.5 Interface Buscar Movimientos Cobros…………………………………...92

Figura 3.6 Código Buscar Movimientos Cobros……………………………………..93

Figura 3.7 Interface Ver Cobros……………………………………………………….93

Figura 3.8 Código Ver Cobros…………………………………………………………94

Figura 3.9 Interface Insertar Cobro……………………………………………………94

Figura 3.10 Código Insertar Cobro…………………………………………………….95

Figura 3.11 Interface Buscar Movimientos Pagos…………………………………...95

Figura 3.12 Código Buscar Movimientos Pagos……………………………………..96

Figura 3.13 Interface Ver Pagos……………………………………………………….96

Figura 3.14 Código Ver Pagos…………………………………………………………97

Figura 3.15 Interface Insertar Pago…………………………………………………...97

Figura 3.16 Código Insertar Pago……………………………………………………..98

Figura 3.17 Selección del menú Reportes……………………………………………98

Figura 3.18 Interface Detalles Cierre Caja…………………………….……………..99

Figura 3.19 Código Detalles Cierre Caja……………………………………………..99

Figura 3.20 Interface Imprimir Detalles Cierre Caja………………………………..100

Figura 3.21 Código Imprimir Detalles Cierre Caja………………………………….100

Figura 3.22 Interface Buscar Movimientos Libro Diario…..……………………….101

Figura 3.23 Código Buscar Movimientos Libro Diario……………………………..101

Figura 3.24 Interface Imprimir Movimientos Libro Diario…..……………………...102

Figura 3.25 Código Imprimir Movimientos Libro Diario……………………………102

Figura 3.26 Selección del menú Copia Seguridad…………………………………103

Figura 3.27 Interface Crear Copia de Seguridad…………………………………..103

Figura 3.28 Interface Nueva Copia de Seguridad………………………………….104

Figura 3.29 Código Crear Copia de Seguridad…………………………………….104

Figura 3.30 Interface Buscar Copias de Seguridad………………………………..105

Figura 3.31 Código Buscar Copias de Seguridad………………………………….105

Figura 3.32 Interface Copia de Seguridad Restaurada……………………………106

Figura 3.33 Código Restaurar Copia de Seguridad………………………………..106

Figura 3.34 Interface Eliminar Copia de Seguridad………………………………..107

Figura 3.35 Código Eliminar Copia de Seguridad………………………………….107

Figura 3.36 Instalación de Joomla 2.5.0 “Pantalla Final”………………………….108

Figura 3.37 Plantilla Karinpi “Ejemplo página de inicio”…………………………...109

Figura 3.38 Plantilla Karinpi “Posiciones”…………………………………………...110

Figura 3.39 Instalación de la plantilla Karinpi “Pantalla Final”…………………….112

Figura 3.40 Página de inicio del sitio web…………………………………………..115

ÍNDICE DE TABLAS

Tabla 1.1 Comparación entre características del proyecto y características de

Scrum……………………………………………………………………………………..23

Tabla 1.2 Prioridades para selección del CMS………………………………………29

Tabla 1.3 Comparación entre requerimientos del sitio Web y características del

CMS Joomla……………………………………………………………………………..29

Tabla 2.1 Asignación de roles………………………………………………………….34

Tabla 2.2 Historia de Usuario “Gestión de Clientes”………………………………...36

Tabla 2.3 Historia de Usuario “Gestión de Proveedores”…………………………..37

Tabla 2.4 Historia de Usuario “Gestión de Productos y Tipos de Producto”……..37

Tabla 2.5 Historia de Usuario “Generación de Factura”…………………………….38

Tabla 2.6 Historia de Usuario “Gestión de Facturas de los Proveedores”………..39

Tabla 2.7 Historia de Usuario “Creación de página web informativa”……………..39

Tabla 2.8 Product Backlog de la versión 1.0…………………………………………40

Tabla 2.9 Estimado Horas disponibles………………………………………………..41

Tabla 2.10 Pila del sprint inicial………………………………………………………..42

Tabla 2.11 Objetivo del sprint………………………………………………………….44

Tabla 2.12 Descripción de la tabla proveedores..…………………………………...49

Tabla 2.13 Caso de Prueba de Aceptación “Prueba Inserción de Cliente”……….65

Tabla 2.14 Caso de Prueba de Aceptación “Prueba Modificación de Cliente”…...66

Tabla 2.15 Caso de Prueba de Aceptación “Prueba Eliminación de Cliente”…….67

Tabla 2.16 Caso de Prueba de Aceptación “Prueba Inserción de Proveedor”…...68

Tabla 2.17 Caso de Prueba de Aceptación “Prueba Modificación de

Proveedor”………………………………………………………………………………..68

Tabla 2.18 Caso de Prueba de Aceptación “Prueba Eliminación de

Proveedor”………………………………………………………………………………..69

Tabla 2.19 Caso de Prueba de Aceptación “Prueba Inserción de Tipo de

Producto”…………………………………………………………………………………70

Tabla 2.20 Caso de Prueba de Aceptación “Prueba Inserción de Producto”……71

Tabla 2.21 Caso de Prueba de Aceptación “Prueba Búsqueda de Producto”…..72

Tabla 2.22 Caso de Prueba de Aceptación “Prueba Modificación de

Producto”…………………………………………………………………………………73

Tabla 2.23 Caso de Prueba de Aceptación “Prueba Inserción de Factura”………74

Tabla 2.24 Caso de Prueba de Aceptación “Prueba Búsqueda de Factura”……..75

Tabla 2.25 Caso de Prueba de Aceptación “Prueba Modificación de Factura”…..76

Tabla 2.26 Caso de Prueba de Aceptación “Prueba Visualización de Factura”….77

Tabla 2.27 Caso de Prueba de Aceptación “Prueba Inserción de Factura de

Proveedor”…………………………………………………………………………….....77

Tabla 3.1 Historia de Usuario “Cobros”……………………………………………….79

Tabla 3.2 Historia de Usuario “Pagos”………………………………………………..80

Tabla 3.3 Historia de Usuario “Caja Diaria”…………………………………………..81

Tabla 3.4 Historia de Usuario “Libro Diario”………………………………………….81

Tabla 3.5 Historia de Usuario “Respaldo de Información”………………………….82

Tabla 3.6 Product Backlog de la versión 2.0…………………………………………83

Tabla 3.7 Pila de Entrega………………………………………………………………85

Tabla 3.8 Estimado Horas disponibles………………………………………………..87

Tabla 3.9 Pila del sprint inicial…………………………………………………………87

Tabla 3.10 Objetivo del sprint………………………………………………………….89

Tabla 3.12 Posiciones y distribución de información en la plantilla………………111

Tabla 3.13 Categorías y Artículos del sitio web…………………………………….113

Tabla 3.14 Menús del sitio web………………………………………………………114

Tabla 3.15 Caso de Prueba de Aceptación “Prueba búsqueda de movimientos de

cobros”………………………………………………………………………………..…116

Tabla 3.16 Caso de Prueba de Aceptación “Prueba de inserción de cobro”……117

Tabla 3.17 Caso de Prueba de Aceptación “Prueba buscar movimientos de

pagos”…………………………………………………………………………………...118

Tabla 3.18 Caso de Prueba de Aceptación “Prueba de inserción de pago”…….119

Tabla 3.19 Caso de Prueba de Aceptación “Prueba de búsqueda de cierre de

caja”……………………………………………………………………………………..120

Tabla 3.20 Caso de Prueba de Aceptación “Prueba búsqueda de movimientos de

libro diario”………………………………………………………………………………120

Tabla 3.21 Caso de Prueba de Aceptación “Prueba de creación de copia de

seguridad”………………………………………………………………………………121

Tabla 3.22 Caso de Prueba de Aceptación “Prueba de restauración de copia de

seguridad”……………………………………………………………………………....122

Tabla 3.23 Caso de Prueba de Aceptación “Prueba de visualización de datos de la

empresa”………………………………………………………………………………..123

Tabla 3.24 Caso de Prueba de Aceptación “Prueba de presentación de catálogo

de productos”…………………………………………………………………………..124

Tabla 3.25 Caso de Prueba de Aceptación “Prueba de visualización de

información de contacto”……………………………………………………………...126

Tabla 3.26 Caso de Prueba de Aceptación “Prueba de envío del formulario de

contacto”………………………………………………………………………………...126

Tabla 3.27 Caso de Prueba de Aceptación “Prueba de registro de usuarios”….127

RESUMEN

El presente trabajo muestra el proceso de creación de un portal web y el

desarrollo del producto de software LendaSoft y su implantación en la Empresa

Servicios y Lujos Only Cars SC. que se dedica a la comercialización de productos

de seguridad y tuning para vehículos.

Toda esta información se encuentra detallada a lo largo de cuatro capítulos

descritos brevemente a continuación:

En el primer capítulo se estudia la caracterización de la Empresa, es decir

conocer toda su información por ejemplo: Datos informativos, Historia, Plan

Estratégico y Estructura organizacional. También se analiza como la Empresa

lleva actualmente sus procesos de facturación, inventario y publicidad. Y por

último se va a justificar el uso de la metodología Scrum y las herramientas de

desarrollo.

En el segundo capítulo se explica como se planificó y desarrolló la primera

iteración del sistema, aquí está incluido el análisis de requerimientos de negocio,

la presentación del equipo de trabajo y sus respectivos roles, y el desarrollo de la

pila de producto. Se lleva también un registro del avance diario del sprint donde

se especifican que actividades se realizaron a lo largo del mismo.

El tercer capítulo detalla la segunda iteración del sistema donde se prosigue con

el desarrollo del sistema revisando lo que se hizo en el sprint anterior, planificando

el nuevo, y actualizando la pila de producto. Se muestra también las actividades

que se ejecutaron para la elaboración del sistema y las pruebas respectivas.

Finalmente el cuarto capítulo contiene las conclusiones y recomendaciones.

PRESENTACIÓN

En el Ecuador el desarrollo de las PYME se ha incrementado en los últimos años,

necesitando cada vez más de la utilización de sistemas informáticos que ayuden a

automatizar sus procesos, gracias al incremento de sus ventas, clientes y

publicidad. El presente proyecto describe la aplicación de esta tendencia al

implantar el Sistema LendaSoft en la Empresa Servicios y Lujos Only Cars SC.

LendaSoft es una aplicación web desarrollada con el propósito de automatizar el

proceso de inventario y facturación de la Empresa, ayudando de esta manera a la

Empresa a llevar un control adecuado de sus productos y brindar un servicio de

mejor calidad a sus clientes.

Como parte del proyecto también se elaboró una página web de carácter

informativo donde se pretende incrementar la publicidad de la Empresa, el portal

web cuenta con un catálogo de productos, un módulo de registro de los clientes,

un módulo de Contáctenos y con módulos de información variada.

La metodología de desarrollo seleccionada para la elaboración del sistema es

Scrum, ya que brinda distintas facilidades justificadas en su momento en esta

tesis.

1

CAPÍTULO 1: PLANTEAMIENTO DEL PROBLEMA

1.1 CARACTERIZACIÓN DE LA EMPRESA

Servicios y Lujos Only Cars SC. es una empresa dedicada a la venta de

accesorios para todo tipo de vehículos entre los cuales están: alarmas, equipo de

audio, accesorios de tuning, etc. La empresa cuenta también con la venta de

equipos para rastreo, monitoreo, control y localización satelital en tiempo real de

vehículos.

DATOS DE LA EMPRESA

NOMBRE: Servicios y Lujos Only Cars SC.

DIRECCIÓN Y TELÉFONOS QUITO

DIRECCIÓN MATRIZ:

· Av. Rodrigo de Chávez Oe 2-288 y Galte (Frente a Ch-Farina).

o Telefax.: 2660 443.

o Celular: 088 757 585 / 087 569 504.

o e-mail: [email protected].

Historia

La empresa, tiene una trayectoria de más de quince años en el mercado

automotriz, rigiéndose hasta el año 2010 bajo el nombre de Servilujos a cargo del

Sr. Kleber Romero.

A partir de febrero del 2011 la empresa pasa a ser propiedad de la Sra. Mirian

León adoptando el nombre Servicios y Lujos Only Cars SC.

Su crecimiento empresarial es progresivo; aumentando tanto su clientela como

sus servicios, adquiriendo así nuevos equipos apoyados en el Sistema de

Posicionamiento global GPS y la red celular GSM/GPRS de una operadora local.

Se cuenta con la mejor tecnología que Kunansoft1 desarrolla, el mismo que está

1 Kunansoft: Empresa desarrolladora del software de Rastreo Satelital.

2

en continuo estudio y evolución. De esta manera se está ofreciendo a sus clientes

una cobertura más amplia.

El funcionamiento de la empresa es totalmente autónomo en los campos

administrativos, financieros y operativos, no recibe aportaciones gubernamentales

y crece sustentada en los ingresos que genera su propia actividad comercial.

1.1.1 PLAN ESTRATÉGICO DE LA EMPRESA

La Empresa tiene un plan estratégico basado en procesos para cumplir sus

objetivos y metas. Por motivos informativos se transcribirá la siguiente

información tomada de documentos proporcionados por el personal de la

empresa:

“Misión

Nuestra misión en Servicios y Lujos Only Cars SC. es ofrecer un efectivo servicio

de venta e instalación de equipos de seguridad y audio automotriz, que satisfaga

las necesidades y supere las expectativas de nuestro cliente y concesionarios,

forjando una relación de confianza y de unión a través de nuestro trabajo,

protegiendo sus bienes e intereses; por medio de un sistema de gestión de

calidad e innovación de servicio.

Visión

Servicios y Lujos Only Cars SC. Será la empresa líder en el mercado de venta e

instalación de equipos de seguridad y audio automotriz, enfocados en el servicio

de calidad, rapidez y confianza; alcanzando reconocimiento a nivel nacional y

comprometiéndonos a mantener relaciones amigables con nuestros clientes a

corto y largo plazo.

Objetivos de la Empresa

Fortalecer la empresa mediante alianzas estratégicas generando nuevos vínculos

que produzcan una mejora continua aprovechando las ventajas de la tecnología

computacional y automotriz.

Fomentar la innovación como modo de generar nuevas fuentes de crecimiento y

satisfacer las necesidades del cliente.

3

Utilizar los recursos disponibles eficientemente para lograr desempeño óptimo de

la empresa.

Ofrecer seguridad y respaldo al cliente externo del buen funcionamiento de los

equipos instalados y del servicio de rastreo satelital.

Implementar alta tecnología al proceso de rastreo satelital vehicular, renovando

constantemente nuestros programas.

Mantener siempre al personal capacitado para responder a las exigencias y

necesidades del cliente y concesionarios.

Evidenciar el liderazgo en la industria automotriz en seguridad y audio a nivel

nacional adquiriendo, implementando y gestionando un sistema de inventario y

facturación interno.

Renovar permanentemente el stock de artículos para la venta e instalación,

estando así delante de nuestra competencia. ’’2

1.2 DESCRIPCIÓN DEL PROBLEMA

1.2.1 SITUACIÓN ACTUAL

Actualmente la empresa brinda a sus clientes varios tipos de productos y servicios

para vehículos como:

1. seguridad

2. audio y video

3. iluminación

4. autolujos

5. servicio técnico

1.2.1.1 Descripción de los procesos internos de la empresa

1.2.1.1.1 Proceso de adquisición

Los productos de los cuales dispone la empresa se obtienen a través de pedidos

a los diferentes proveedores, mediante llamadas telefónicas o cuando el

proveedor oferta directamente su producto a la empresa. Los pedidos pueden ser:

regulares o exclusivos. Los pedidos regulares son los que se realizan

2 Plan estratégico de la Empresa Servicios y Lujos Only Cars SC: Información proporcionada por la empresa.

4

periódicamente y los exclusivos se realizan en razón de las necesidades que

poseen determinados clientes.

Normalmente los proveedores son los que transportan sus productos a la

empresa, pero en los casos exclusivos mencionados anteriormente, cualquiera de

los empleados retira los productos directamente desde las bodegas de los

proveedores.

Al momento de ingresar la mercadería a la empresa el empleado asignado

procede a:

· Revisar si los productos que llegaron concuerdan con el pedido.

· Revisar si cada ítem del pedido está completo.

· Revisar que los precios de los productos concuerden con los señalados en

el pedido.

· Hacer la revisión técnica de los productos.

· Colocar precios en cada uno de los productos

La lista de proveedores se encuentra en un archivo de Excel que contiene las

siguientes columnas: nombre, número de teléfono celular, número de teléfono

convencional y número de fax de los proveedores. Este archivo no tiene ningún

tipo de seguridad, es decir es de libre acceso y se puede editar, añadir y borrar

registros, esto es un grave problema ya que se pueden perder estos datos que

son esenciales para la obtención de productos. Además no existe en la lista de

proveedores un registro que indique el tipo de producto o conjunto de productos

que ofrece cada proveedor.

1.2.1.1.2 Proceso de inventario

Se procede a registrar la mercadería ingresada, en un cuaderno escolar con los

siguientes datos: fecha de ingreso, tipo, marca, cantidad de producto. Este

registro permite al personal informarse de qué productos tiene para vender.

Por lo tanto no existe un control automático del inventario, lo que ha provocado

algunos problemas; no se sabe con exactitud qué productos se encuentran

disponibles para vender, tampoco cuales son los productos que se deben adquirir.

5

1.2.1.1.3 Proceso de facturación

Este tiene por función vender la mercadería a los clientes de la empresa. Cuando

se realiza una venta la persona encargada, elimina la cantidad de mercadería

vendida, del mismo cuaderno citado en el proceso de inventario, y al final del día

se realiza una comparación entre el dinero que hay en caja con el registro de las

ventas.

La facturación se realiza manualmente esto es causa de inconvenientes ya que

no se lleva un registro de los clientes, y los vendedores realizan doble trabajo al

llenar totalmente a mano las facturas. Debido a que la facturación se realiza

manualmente no se encuentra ligada al inventario.

1.2.1.1.4 La empresa maneja su publicidad de la siguiente manera

Existe un espacio contratado por la empresa en las páginas amarillas, en el cual

se encuentran los números de teléfono y dirección. Además la empresa logra

promocionarse por medio de la recomendación de sus clientes satisfechos.

La empresa no cuenta con publicidad electrónica, lo que hace más difícil la

ubicación del local en donde se venden los productos y los clientes no conocen de

antemano los productos que se ofrecen.

Lo expuesto hace que exista la necesidad de automatizar los procesos, para esto

se propone un sistema de facturación e inventario además del desarrollo de un

sitio web para la empresa Servicios y Lujos Only Cars SC.

1.2.1.2 Estructura organizacional de la empresa

La empresa al ser pequeña no tiene un organigrama establecido, en base a lo

estudiado y analizado de la misma, se ha propuesto el organigrama que se

presenta en la Figura 1.1:

6

Figura 1.1 Organigrama propuesto de la Empresa

Elaborado por los autores

Se realizará una breve explicación de lo que realiza cada departamento y sus

respectivas áreas:

1.2.1.2.1 Departamento de Abastecimiento y Compras

El departamento de Abastecimiento y Compras es el encargado de realizar las

adquisiciones de productos y servicios; en el momento debido, con la cantidad y

calidad requerida y a un precio adecuado; identificando y comparando a los

proveedores y abastecedores, negociando con los mismos para convenir términos

de compra, celebrar contratos y colocar pedidos.

Responsable

· Sra. Mirian León

· Sr. Bolívar Miranda

Objetivos:

Área de Compras

· Obtener productos y servicios en cantidad y con calidad necesarias.

· Obtener productos y servicios al menor costo.

· Garantizar el mejor servicio posible y pronta entrega por parte del

proveedor.

· Controlar que la calidad de los productos sea la requerida.

7

· Proveerse de más de una fuente, en previsión de cualquier emergencia que

impida la entrega de un proveedor.

· Anticipar alteraciones en precios, por diferencias en las cotizaciones

monetarias, inflación o escases.

· Desarrollar y mantener buenas relaciones con los proveedores y desarrollar

proveedores potenciales.

Área de almacén

· Tener los productos disponibles en el tiempo que son requeridos.

· Asegurar la cantidad de productos indispensables.

· Registrar la entrada y salida de productos en el almacén a través de un

control de existencia.

Funciones:

Área de Compras

· Realizar solicitudes y órdenes de compra, colocar las mismas con el

proveedor seleccionado, recibir la mercancía, pagar y contabilizar los

productos.

· Fijar especificaciones para los productos a adquirir.

· Asegurar la cantidad de productos indispensables.

· Controlar que la calidad de los productos sea la requerida.

· Realizar un "Ciclo de manejo físico de los productos", desde el embarque

por el proveedor, transporte, recepción y almacenaje.

Área de almacén

· Realizar un control de existencia de productos, que permita conocer el

momento en que deba reabastecerse cierto producto en el almacén.

· Recibir del Área de Compras una copia de cada pedido efectuado.

· Almacenar la mercancía comprada en la bodega.

1.2.1.2.2 Departamento de Marketing y Ventas

El Departamento de Marketing y Ventas se encarga de colocar los productos y

servicios, que la empresa comercializa, en los mercados. Realiza las actividades

de marketing y de estudio o prospección de mercados. También las de publicidad.

8

Responsables:

· Sr. Edgar Tello

Objetivos:

Área de Ventas

· Realizar estrategias de venta.

· Planear las ventas.

· Incrementar las ventas rentables.

· Optimizar las actividades de ventas.

Área de Publicidad

· Persuadir al público con un mensaje comercial para que tome la decisión

de comprar u optar por los productos y servicios que la empresa ofrece.

· Conocer y comprender al consumidor.

Funciones:

Área de Ventas

· Supervisar el trabajo de cada vendedor.

· Solventar de la mejor manera cualquier problema que se presente con un

cliente determinado.

· Planificar el trabajo de ventas.

· Coordinar llamadas telefónicas a los clientes.

· Realizar el pronóstico de ventas por mes.

· Llevar el acumulado diario de las ventas.

Área de Publicidad

· Gestionar recursos de la empresa que ayuden a promocionar los productos

y servicios que se ofrecen.

· Conducir, canalizar y controlar toda la actividad de comunicación

publicitaria de la empresa.

· Determinar el presupuesto destinado a invertir para promocionar los

productos y servicios.

· Supervisar los resultados que se obtienen a través de la publicidad.

9

1.2.1.2.3 Departamento Financiero

Se encarga de controlar los recursos económicos financieros de la empresa,

asignando fondos necesarios para el correcto funcionamiento de cada área.

Responsable:

· Sra. Mirian León

Objetivos:

Área de Contabilidad.

· Instrumentar y operar las políticas, normas, sistemas y procedimientos

necesarios para garantizar la exactitud y seguridad en la capacitación y

registro de las operaciones financieras, presupuestables y de consecución

de metas, vigilando la debida observancia de las leyes, normas y

reglamentos aplicables a la organización.

Área de Tesorería:

· Organizar y controlar los flujos de efectivo para el pago de gasto.

· Recibir, concretar, custodiar y manejar los fondos y valores, validando los

ingresos y egresos que sean afines al presupuesto autorizado de la

empresa.

Funciones:

Área de Contabilidad.

· Mantener el correcto funcionamiento de los sistemas y procedimientos

contables de la empresa.

· Formular estados financieros.

· Investigar y dar solución a los problemas referentes a la falta de

información para el registro contable.

· Preparar y ordenar la información financiera y estadística para la toma de

decisiones de las autoridades superiores.

· Identificar y analizar los ingresos, egresos y gastos de operación de la

empresa.

10

Área de Tesorería:

· Almacenar los soportes de todas las transacciones.

· Realizar periódicamente boletines de los fondos de la empresa.

· Aplicar las medidas necesarias para la prevención de errores en cuanto al

manejo del efectivo, la caja y los bancos.

· Brindar la información oportuna sobre la liquidez y de todas las

transacciones comerciales y financieras.

1.2.1.2.4 Departamento de Recursos Humanos

El departamento de Recursos Humanos se encarga de seleccionar, contratar,

formar y retener a los empleados de la empresa.

Responsables:

· Sr. César Miranda

Objetivos:

Área de gestión del personal:

· Mantener el registro e información sobre el personal.

· Administrar el pago de las remuneraciones y el cumplimiento de las leyes

sociales para el personal.

Funciones

Área de gestión del personal:

· Describir las responsabilidades que definen cada puesto laboral y las

cualidades que debe tener la persona que lo ocupe.

· Evaluar el desempeño del personal.

· Reclutar al personal idóneo para cada puesto.

· Capacitar y desarrollar programas, cursos y toda actividad que vaya en

función del mejoramiento de los conocimientos del personal.

· Llevar el control de beneficios de los empleados.

11

1.3 JUSTIFICACIÓN DE LA METODOLOGÍA

La metodología de desarrollo de software se refiere a un conjunto estandarizado

de conceptos, prácticas y criterios que es usado para estructurar, planear y

controlar el proceso de desarrollo en sistemas de información.

El desarrollo de software no es una tarea fácil. Prueba de ello es que existen

numerosas propuestas metodológicas que inciden en distintas dimensiones del

proceso de desarrollo. Por un lado están aquellas propuestas más tradicionales

que se centran especialmente en el control del proceso, por otro lado están las

centradas en otras dimensiones, como el factor humano o el producto software.

Para el desarrollo del sistema de facturación e inventario y del sitio web, de la

empresa Servicios y Lujos Only Car SC. se toma en cuenta las siguientes

consideraciones:

· El desarrollo del proyecto conlleva tareas delimitadas como: diseñar la

base de datos, diseñar el prototipo, elaborar documentación y realizar

pruebas del prototipo.

· El proceso de desarrollo debe ser supervisado por un Jefe o Director de

proyecto.

· Se deben realizar revisiones mensuales de los avances del proyecto.

· La empresa se encuentra en continuo crecimiento por lo tanto los requisitos

del sistema están sujetos a cambios que no exigen características

complejas en su implementación.

· Los requisitos del sistema planteados por el cliente en este caso la

empresa deben pasar por listas de prioridad, elaboradas en conjunto con

el equipo de desarrollo y el cliente.

· La empresa se compromete a colaborar con el desarrollo del proyecto y su

disponibilidad de tiempo, para realizarlo.

· La empresa requiere que el sistema sea desarrollado en el menor tiempo

posible.

· La Gerencia General de la Empresa está de acuerdo en resolver problemas

habituales y realizar cambios organizativos, formando equipos auto

gestionados y multidisciplinares de trabajo, fomentando una cultura de

12

gestión basada en la colaboración y en la facilitación llevada a cabo por

líderes al servicio del equipo de desarrollo.

· El tamaño del equipo de desarrollo es de dos personas.

· El equipo trabaja en un mismo espacio común para maximizar la

comunicación.

· La dedicación del equipo a desarrollar el proyecto es a medio tiempo.

· Hay una estabilidad de los miembros del equipo.

· Se da el compromiso conjunto y colaboración de los miembros del equipo.

1.3.1 METODOLOGÍA SCRUM

Scrum es un marco de trabajo para la gestión y desarrollo de software basada en

un proceso iterativo e incremental utilizado comúnmente en entornos basados en

el desarrollo ágil de software.

Aunque Scrum está enfocado a la gestión de procesos de desarrollo de software,

puede ser utilizado en equipos de mantenimiento de software.

1.3.1.1 Características de Scrum

Scrum es un modelo de referencia que define un conjunto de prácticas y roles, y

que puede tomarse como punto de partida para definir el proceso de desarrollo

que se ejecutará durante un proyecto. Los roles principales en Scrum son el

ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de

proyecto, el ProductOwner, que representa a los stakeholders (interesados

externos o internos), y el Team que incluye a los desarrolladores.

Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es

definida por el equipo), el equipo crea un incremento de software potencialmente

entregable (utilizable). El conjunto de características que forma parte de cada

sprint viene del Product Backlog, que es un conjunto de requisitos de alto nivel

priorizados que definen el trabajo a realizar. Los elementos del Product Backlog

que forman parte del sprint se determinan durante la reunión de Sprint Planning.

Durante esta reunión, el Product Owner identifica los elementos del Product

13

Backlog que quiere ver completados y los hace del conocimiento del equipo.

Entonces, el equipo determina la cantidad de ese trabajo que puede

comprometerse a completar durante el siguiente sprint. Durante el sprint, nadie

puede cambiar el Sprint Backlog, lo que significa que los requisitos están

congelados durante el sprint.

Scrum permite la creación de equipos auto organizados, y la comunicación verbal

entre todos los miembros involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los

clientes pueden cambiar de idea sobre lo que quieren y necesitan, y que los

desafíos impredecibles no pueden ser fácilmente enfrentados de una forma

predictiva y planificada. Por lo tanto, Scrum adopta una aproximación pragmática,

aceptando que el problema no puede ser completamente entendido o definido, y

centrándose en maximizar la capacidad del equipo de entregar rápidamente y

responder a requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum,

que van desde notas amarillas "post-it" y pizarras hasta paquetes de software.

Una de las mayores ventajas de Scrum es que es muy fácil de aprender, y

requiere muy poco esfuerzo para comenzarse a utilizar.

1.3.1.2 Roles en Scrum

En Scrum se definen varios roles, estos están divididos en dos grupos: cerdos y

gallinas.

Los 'cerdos' están comprometidos a desarrollar el software de forma regular y

frecuente, mientras que todos los demás son 'gallinas' que sólo están

involucrados en el proyecto, y si este falla, ellos no son los cerdos, es decir, ellos

no fueron los que se comprometieron a hacerlo.

14

1.3.1.2.1 Roles "Cerdo"

Product Owner (Dueño del Producto)

El Product Owner representa la voz del cliente. Se asegura de que el

equipo Scrum trabaja de forma adecuada desde la perspectiva del negocio.

El Product Owner escribe historias de usuario, las prioriza, y las coloca en

el producto backlog.

Scrum Master (Facilitador)

El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es

eliminar los obstáculos que impiden que el equipo alcance el objetivo del

sprint. El ScrumMaster no es el líder del equipo (porque ellos se auto-

organizan), sino que actúa como una protección entre el equipo y cualquier

influencia que le distraiga. El ScrumMaster se asegura de que el proceso

Scrum se utiliza como es debido. El ScrumMaster es el que hace que las

reglas se cumplan.

ScrumTeam (Equipo)

El equipo tiene la responsabilidad de entregar el producto. Un pequeño

equipo de 5 a 9 personas con las habilidades transversales necesarias

para realizar el trabajo (diseñador, desarrollador, etc).

1.3.1.2.2 Roles "Gallina"

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse

en cuenta. Un aspecto importante de una aproximación ágil es la práctica de

involucrar en el proceso a los usuarios, expertos del negocio y otros interesados

(stakeholders). Es importante que esa gente participe y entregue

retroalimentación con respecto a la salida del proceso a fin de revisar y planear

cada sprint.

1.3.1.3 Reuniones en Scrum

1.3.1.3.1 Daily Scrum

Cada día de un sprint, se realiza la reunión sobre el estado de un proyecto. Esto

se llama "daily standup". El scrum tiene unas guías específicas:

15

· La reunión comienza puntualmente a su hora. A menudo hay castigos

acordados por el equipo para quien llegue tarde.

· Todos son bienvenidos, pero sólo los "cerdos" pueden hablar.

· La reunión tiene una duración fija de 15 minutos, de forma independiente

del tamaño del equipo.

· Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la

reunión corta).

· La reunión debe ocurrir en la misma ubicación y a la misma hora todos los

días.

Durante la reunión, cada miembro del equipo contesta a tres preguntas:

· ¿Qué has hecho desde ayer?

· ¿Qué es lo que estás planeando hacer hoy?

· ¿Has tenido algún problema que te haya impedido alcanzar tu objetivo?

(Es el papel del ScrumMaster recordar estos impedimentos).

1.3.1.3.2 Reunión de Planificación del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint (cada 15 o 30 días), una “Reunión de Planificación del

Sprint” se lleva a cabo.

· Seleccionar qué trabajo se hará.

· Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo

que tomará hacer el trabajo.

· Identificar y comunicar cuánto del trabajo es probable que se realice

durante el actual Sprint.

· Ocho horas como límite.

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la “Reunión de Revisión

del Sprint” y la “Retrospectiva del Sprint”.

1.3.1.3.3 Reunión de Revisión del Sprint

La Revisión del Sprint brinda una inspección del progreso del proyecto al finalizar

cada Sprint, basándose en esta inspección se realizan adaptaciones al proyecto.

16

Al fin del Sprint el equipo presenta el incremento del producto que pudo construir

y junto al Product Owner (Dueño del Producto) verifican el incremento del mismo,

se escuchan las experiencias del equipo que surgieron durante el transcurso del

Sprint. Finalmente pueden tomar una decisión con información acerca de qué

hacer a continuación; en otras palabras, determinan el mejor curso de acción para

poder alcanzar el destino.

Durante la reunión, todos ven funcionar la demostración del producto en el

entorno del cliente o usuario. A medida que se visualiza el producto, consideran

qué funcionalidad podría ser agregada durante el próximo Sprint actualizando el

product backlog.

1.3.1.3.4 Reunión de Retrospectiva del Sprint

Con el objetivo de mejorar de manera continua su productividad y la calidad del

producto que está desarrollando, el equipo analiza cómo ha sido su manera de

trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se

comprometió al inicio de la iteración y por qué el incremento de producto que

acaba de demostrar al cliente era lo que él esperaba o no:

· Qué cosas han funcionado bien.

· Cuáles hay que mejorar.

· Qué cosas quiere probar hacer en la siguiente iteración.

· Cuáles son los problemas que podrían impedirle progresar adecuadamente.

Notar que esta reunión se realiza después de la reunión de revisión del sprint, para

poder incorporar su feedback3 y cumplimiento de expectativas como parte de los

temas a tratar en la reunión de retrospectiva.

La retrospectiva del sprint es una reunión en la cual el equipo de desarrollo

analiza cómo ha ido el sprint desde todos los puntos de vista. Se realiza esta

3 Feedback: Es el proceso de compartir observaciones y sugerencias, con la intención de recabar

información para tomar acciones correctivas para el software.

17

reunión básicamente para encontrar cómo se puede mejorar. De esta forma se

puede incrementar la productividad, tanto en equipo como individualmente.

1.3.1.4 Sprint

El Sprint es el período en el cual se lleva a cabo el trabajo en sí. Es recomendado

que la duración de los sprints sea constante y definida por el equipo en base a su

propia experiencia. Se puede comenzar con una duración de sprint en particular

(dos o tres semanas) e ir ajustándolo en base al ritmo del equipo, aunque sin

relajarlo demasiado. Al final de cada sprint, el equipo deberá presentar los

avances logrados, y deberían entregar un producto con características de

utilizable por el cliente. Asimismo se recomienda no cambiar los objetivos del

sprint o sprint backlog a menos que la falta de estos cambios amenacen al éxito

del proyecto. La constancia hace a la concentración y la mejor productividad del

equipo de trabajo.

1.3.1.5 Documentos

1.3.1.5.1 Product backlog

El product backlog es un documento de alto nivel para todo el proyecto. Contiene

descripciones genéricas de todos los requerimientos, funcionalidades deseables,

etc., priorizadas según su retorno sobre la inversión. Es el qué va a ser

construido, es abierto y cualquiera puede modificarlo. Contiene estimaciones a

groso modo, tanto del valor para el negocio, como del esfuerzo de desarrollo

requerido. Esta estimación ayuda al product owner a ajustar la línea temporal y,

de manera limitada, la prioridad de las diferentes tareas. Por ejemplo, si dos

características tienen el mismo valor de negocio la que requiera menos tiempo de

desarrollo tendrá probablemente más prioridad, debido a que su ROI será más

alto.

1.3.1.5.2 Sprint backlog

El sprint backlog es un documento detallado donde se describe el cómo el equipo

va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen

en horas con ninguna tarea de duración superior a 16 horas. Si una tarea es

18

mayor de 16 horas, deberá ser divida en otras menores. Las tareas en el sprint

backlog nunca son asignadas, son tomadas por los miembros del equipo del

modo que les parezca oportuno.

1.3.1.5.3 Burn down chart

La burn down chart es una gráfica mostrada públicamente que mide la cantidad

de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint.

Dibujando una línea que conecte los puntos de todos los Sprints completados,

podremos ver el progreso del proyecto. Lo normal es que esta línea sea

descendente (en casos en que todo va bien en el sentido de que los requisitos

están bien definidos desde el principio y no varían nunca) hasta llegar al eje

horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos

pendientes de ser completados en el Backlog). Si durante el proceso se añaden

nuevos requisitos la recta tendrá pendiente ascendente en determinados

segmentos, y si se modifican algunos requisitos la pendiente variará o incluso

valdrá cero en algunos tramos.

1.3.1.5.4 Pila de Entrega y Gráfica de Trabajo Restante

Al llegar a este punto se han terminado algunos elementos, algunos se han

añadido, algunos tienen nuevas estimaciones, y algunos se han caído del objetivo

de entrega. El Dueño de Producto es responsable de asegurarse que estos

cambios se reflejan en la Pila de Entrega (y más ampliamente, en la Pila de

Producto). Además, Scrum incluye una gráfica de Trabajo Restante de la Entrega

que muestra el progreso hecho hacia la fecha de entrega. Es análogo a la gráfica

de Trabajo Restante del Sprint, pero a un nivel más alto (requisitos). En las

Figuras 1.2 y 1.3 se muestran ejemplos de la Pila de Entrega y de la Grafica de

trabajo Restante respectivamente.

19

Figura 1.2 Pila de Entrega

Fuente: http://assets.scrumfoundation.com/downloads/3/scrumprimer_es.pdf?1285932063

La Pila de Entrega contiene los siguientes datos:

· Item: Es el nombre de los requerimientos hechos por el cliente.

· Prioridad: Es el valor entre 1 y 5 asignado como prioridad por el cliente.

· Estimación del Valor: Es el valor entre 1 y 5 asignado por el grupo de

desarrollo.

· Estimación de Esfuerzo Inicial: Es el número de horas estimadas de

duración de desarrollo del ítem, realizadas por el grupo desarrollador.

· Estimación de Esfuerzo nueva: Representa la estimación de esfuerzo

inicial definida para cada sprint.

Figura 1.3 Gráfica de Trabajo Restante Fuente: http://assets.scrumfoundation.com/downloads/3/scrumprimer_es.pdf?1285932063

1.3.1.6 Seguimiento Diario del Sprint

Para llevar el control del formato y soporte del Sprint se puede utilizar una de las

siguientes opciones:

20

· Pizarra física o pared.

· Herramienta colaborativa o de gestión de proyectos.

· Hoja de cálculo.

1.3.1.6.1 Pizarra Física

Muchos equipos desarrolladores Scrum también usan una herramienta, que es un

tablero de tareas escritas en post-its, que cambian durante el Sprint entre

columnas etiquetadas según su estado “No empezado”, “En progreso” y

“Completado” varios ejemplos se pueden observar en la Figura 1.4, donde cada

columna representa un “epic” o gran historia del producto, que está descrita en la

tarjeta de la parte superior.

Debajo de la tarjeta con el epic, de cada columna se despliegan las historias de

usuario que lo componen, aquí la tarjeta de cada historia de usuario refleja el

avance que la misma está teniendo en la pizarra del equipo, a través de una barra

de progreso que actualiza a diario el propietario de producto, pintando sobre la

tarjeta de la historia.

Figura 1.4 Ejemplos de Tablero de Sprint Fuente: http://2.bp.blogspot.com/-G_zrSqnCsL0/TyhQg6ojwiI/AAAAAAAAGf0/TkZhwzxscqE/s400/taskboard.jpg

1.3.1.6.2 Herramienta colaborativa o de Gestión de Proyecto

No siempre es posible dejar todo el detalle del sprint en historias de usuario,

modificaciones o estimaciones en manos del volátil papel, también es necesario y

cómodo gestionar el proyecto mediante alguna herramienta de software.

El listado es extenso y hay soluciones más o menos completas, pagadas y libres

por ejemplo:

Herramientas para Scrum

21

· Rally Dev Software

· BaseCamp HQ

· XPlanner

· VersionOne

· Scrum Desk

· Scrum'd

· Banana Scrum

· ScrumWorks

· TargetProcess

· IceScrum

· Sprintometer

· Brightgreen

· TinyPM

· Assembla

· Bugzilla

· GreenHopper

Herramientas para gestión de proyectos (pero usadas para Scrum también):

· Trac

· TimeXchange

· TeamBox

· Agilo

Otras herramientas usadas de alguna forma en Scrum:

· TWiki

· Dokuwiki

· Eventum

· Bugzilla

· JIRA

· Conchango

· Sharepoint

· PVCS

· Google

Documents

· XStudio: XQual

Studio

(XStudio)

1.3.1.6.3 Hoja de Cálculo:

Es una herramienta para gestionar el trabajo de las tareas de cada Sprint cuya

funcionalidad es:

· la gestión y registro del Sprint backlog,

· la generación de los gráficos de evolución

o Esfuerzo

o Tareas

o Individual

Se puede observar un ejemplo en la Figura 1.5.

22

Figura 1.5 Ejemplos de hoja de cálculo del Sprint Fuente: http://www.navegapolis.net/files/cis/plantilla_sprint.xls

Resumiendo Scrum como lo muestra la Figura 1.6 se basa en el equipo, en

reuniones diarias presididas por el Scrum master para establecer el estado del

proyecto, y en la salida cada 30 días de características del proyecto finalizadas y

listas para trabajar, el corazón del Scrum es la iteración, que en cada iteración

presenta una mejora del funcionamiento del producto final, en cada iteración se

evalúa la tecnología y capacidades requeridas, diariamente se pueden modificar

el enfoque si se encuentran nuevas dificultades y tratar de remediarlas, el corazón

del Scrum es la productividad.

Figura 1.6 Proceso de trabajo del Scrum

Fuente: http://www.epidataconsulting.com/tikiwiki/img/wiki_up/ScrumLargeLabelled.png

23

1.3.2 JUSTIFICACIÓN DE LA METODOLOGÍA EN FUNCIÓN DE LAS

CARACTERÍSTICAS DEL PROYECTO

Se expondrá en la Tabla 1.1 si en realidad la metodología seleccionada satisface

o no con todas las necesidades del proyecto.

No. Características del proyecto Características de Scrum Resultado de

satisfacción SI NO Prioridad alta

1 Se cuenta con dos personas en el equipo de desarrollo.

Grupo de desarrollo de seis a nueve personas.

Ö

2 Se cuenta con la elaboración de listas de prioridad de los requisitos.

Especificación de product backlog, que contiene una lista priorizada de requisitos.

Ö

3 El proyecto está sujeto a cambios que exigen características de complejidad media en su implementación.

Especializado en proyectos de media complejidad.

Ö

4 Se deben realizar revisiones mensuales de los avances del proyecto.

Sprints review cada treinta días, en donde se realizan revisiones de los avances del proyecto.

Ö

Prioridad baja 5 Se da el compromiso conjunto y

colaboración de los miembros del equipo.

Maximizar el compromiso conjunto y colaboración de los miembros del equipo.

Ö

Tabla 1.1 Comparación entre características del proyecto y características de Scrum Elaborado por los autores

Al analizar la Tabla 1.1, se puede observar que si satisfacen las principales

características del proyecto y las de Scrum para el desarrollo del sistema, una de

las mismas no cumple pero puede ser suplida de la siguiente manera: Se dividirá

las tareas de trabajo, es decir cada integrante del equipo realizará las actividades

que se le asignen, cumpliendo así con el requerimiento de Scrum.

La realización de este proyecto es de complejidad media, ya que está más

orientado al desarrollo de los módulos de facturación e inventario. Se lo puede

24

desarrollar de manera ágil incluyendo documentación estrictamente necesaria.

Además no se cuenta con mucho presupuesto por parte del cliente.

La empresa se encuentra en una etapa de automatización de procesos, por esta

razón está sujeta de manera constante a cambios en sus requerimientos, por lo

que se justifica la utilización de una metodología ágil como Scrum.

1.4 JUSTIFICACIÓN DE CMS Y DE LAS HERRAMIENTAS DE

DESARROLLO

1.4.1 JUSTIFICACIÓN DE CMS

La empresa Servicios y Lujos Only Cars SC. se encuentra en continuo desarrollo,

y siente la necesidad de contar con un espacio digital propio, por lo tanto se

requiere:

· Atender las expectativas de los clientes y mostrar la planificación

estratégica de la empresa.

· Que cuente con tres roles básicos para los usuarios, como son:

administrador de todo el sitio, usuario autenticado y usuario visitante.

· Mostrar una lista completa de los productos y servicios que ofrece la

empresa.

· Que cuente con un formulario de contacto en donde los clientes

puedan realizar consultas, solicitudes y además este formulario debe

servir de puente para el contacto con potenciales clientes.

· Que cuente con un módulo dinámico y sencillo de imágenes y texto en

donde se puedan visualizar las diferentes ofertas y novedades.

· Publicar banners con las diferentes promociones de los productos y

servicios.

· Consultar y actualizar permanente y simultáneamente la información del

sitio web, sin que se afecte el tiempo de respuesta.

· Permitir en el futuro el desarrollo de nuevas funcionalidades, modificar

o eliminar funcionalidades después de su construcción.

· Que sea de fácil mantenimiento y uso.

25

· Que cuente con una interfaz de administración que incluya:

Administración de usuarios y de módulos. En cada una de éstas

secciones, se deberá ofrecer todas las opciones de administración

disponibles para cada uno.

· Que cuente con un módulo de seguridad, que evite el ingreso a

usuarios no autorizados a la administración del sitio.

· Validar automáticamente la información contenida en los formularios de

ingreso. En el proceso de validación de la información, se deben tener

en cuenta aspectos tales como obligatoriedad de campos, longitud de

caracteres permitida por campo, manejo de tipos de datos, etc.

1.4.1.1 Definición del CMS Joomla

Un CMS (Content Management System, en inglés), Sistema de gestión de

contenidos, es un sistema de software que permite organizar y facilitar la

creación de documentos y otros contenidos. Con frecuencia, un CMS es una

aplicación web usada para gestionar sitios web y contenidos web.

Joomla es un CMS, de código abierto, opensource, muy fácil de instalar,

completamente gratuito y en castellano.

1.4.1.1.1 Funcionalidad de Joomla

El funcionamiento de Joomla se lleva a cabo gracias a sus dos principales

elementos:

· La base de datos Mysql: allí es donde se guarda toda la información y la

mayor parte de la configuración del sistema, de una forma ordenada y en

distintas tablas, cada una de ellas almacena información específica y

determinada.

· Los scripts PHP: son los que ejecutan las acciones de consulta y realizan

modificaciones en la base de datos convirtiendo los datos en simples

páginas web interpretables por los navegadores de Internet (Browsers) y

perfectamente inteligibles para los usuarios navegantes y administradores.

26

1.4.1.1.2 Características de Joomla

· Bajo costo de desarrollo y mantenimiento:

El costo de producir y mantener un sitio web con Joomla CMS es muy

inferior a otras soluciones.

· Organización del sitio web:

Joomla está preparado para organizar eficientemente los contenidos de un

sitio en categorías y artículos, lo que facilita la navegabilidad para los

usuarios y permite crear una estructura sólida, ordenada y sencilla para los

administradores. Desde el panel administrador de Joomla se puede crear,

editar y borrar las categorías y artículos del sitio web.

· Publicación de Contenidos:

Con Joomla CMS se puede crear páginas ilimitadas y editarlas desde un

sencillo editor que permite formatear los textos con los estilos e imágenes

deseados. Los contenidos son totalmente editables y modificables.

· Escalabilidad e implementación de nuevas funcionalidades :

Joomla ofrece la posibilidad de instalar, desinstalar y administrar

componentes y módulos, que agregarán servicios de valor a los visitantes

del sitio web, por ejemplo: galerías de imágenes, foros, boletines,

clasificados, etc.

· Seguridad:

Joomla es uno de los escasos CMS que cuenta con la suficiente

participación activa como para generar soluciones precisas en el menor

tiempo posible ante las vulnerabilidades que se vayan descubriendo.

· Administración de usuarios:

Joomla es un sistema comunitario que administra diferentes tipos de

usuarios con diferentes privilegios de acceso: administradores que

gestionen la Web junto con el WebMaster de la misma (el Super

27

Administrador) pero también usuarios anónimos y visitantes de la Web que

podrán convertirse en autores, editores y publicar sus propios contenidos.

· Fácil uso:

No se necesitan excesivos conocimientos técnicos básicos para instalar y

configurar el sitio y apenas ninguno para añadir o editar contenido. Esto

facilita muchísimo el trabajo del WebMaster y posibilita además, el trabajo

conjunto de otras personas en la Web.

· Diseño y aspecto estético del sitio:

Es posible cambiar todo el aspecto del sitio web tan solo con un par de

clics, gracias al sistema de templates que utiliza Joomla.

· Soporte:

Lo soporta una comunidad de desarrollo sólida y muy dinámica.

· Administrador de Imágenes:

Joomla posee una utilidad para subir imágenes al servidor y usarlas en

todo el sitio.

· Módulos:

Los módulos son extensiones o complementos de Joomla que permiten

añadir información en diferentes posiciones o zonas de la plantilla,

normalmente en la página de inicio. El tipo de módulo más importante es el

Menú, es un tipo particular de módulo que facilita la navegabilidad por el

sitio y cuya configuración se realiza en un apartado específico que es el

administrador de menú. Otros tipos de módulo son los siguientes:

o Datos de acceso: permite restringir el acceso de ciertos contenidos

confidenciales solo para usuarios registrados.

o Buscar: es útil para que los usuarios busquen en el sitio web en un

buscador interno, utilizando ciertas palabras claves relevantes a la

información que desean encontrar.

28

o HTML personalizado: En Joomla se puede crear módulos con

contenido personalizado. En un módulo de este tipo se puede

mostrar, por ejemplo, un texto o imágenes usando el editor por

defecto de Joomla de forma semejante a como se hace en un

artículo de noticias.

Se puede instalar módulos que muestran distintos tipos de información o

que añaden diferentes funcionalidades a una web Joomla como: módulo

para visualizar texto e imágenes en forma dinámica, módulo de seguridad,

módulo contador de visitas, etc.

· Publicidad:

Es posible hacer publicidad en el sitio usando el Administrador de Banners

· Actualización de contenidos:

La sencillez y la economía empleada en el tiempo a la hora de añadir

contenidos, impulsa que su actualización sea mucho más frecuente, su

información al día, lo que facilita que los visitantes del sitio acudan con

mayor regularidad y lo visiten con relativa frecuencia.

· Formulario de contacto:

Joomla posee un formulario de contacto sencillo que permite a los usuarios

realizar preguntas, opiniones, consultas, solicitudes y que además cuenta

con validación de campos. También existen formularios que se pueden

instalar, el más utilizado es Chrono Forms, con este componente se

pueden crear formularios personalizados de forma rápida, valida los datos

mediante Java Script.

1.4.1.1.3 Requisitos del Sistema

Para poder instalar y usar Joomla con éxito, se debe tener un servidor operativo

(Apache es el óptimo), una base de datos (MySQL es la mejor) y un intérprete del

lenguaje de programación (PHP es el adecuado), todo ello, configurado para que

29

dichas aplicaciones puedan trabajar e interactuar conjuntamente. Las versiones

mínimas que podemos utilizar y las recomendadas, se muestran en la Tabla 1.2:

Software Versión mínima Recomendada Última

PHP 4.3.0 5.0.0 5.4.0

MySQL 3.23 5.0 5.5.23

Apache 1.3 2.2 2.2.21

Tabla 1.2 Prioridades para selección del CMS Elaborado por los autores

1.4.1.2 Justificación del CMS en función de los requerimientos para el sitio web

A continuación se presenta la Tabla 1.3, que muestra si las funcionalidades y

características explicadas acerca del CMS Joomla, se ajustan a las necesidades

establecidas con anterioridad para la construcción del sitio web de la empresa

Servicios y Lujos Only Cars SC.

No. Requerimientos del Sitio Web

Características del CMS Joomla

Resultado de Satisfacción

Requerimientos de mayor prioridad Si No

1 Contar con roles básicos para los usuarios, como son: administrador de todo el sitio, usuario autenticado y usuario visitante. .

Cuenta con un módulo para administrar diferentes tipos de usuarios como son: administrador de todo el sitio, usuario autenticado y usuario visitante.

Ö

2 Publicar información referente a la empresa y a los productos y servicios que ofrece.

Permite crear y publicar páginas ilimitadas y editarlas desde un sencillo editor que permite formatear los textos con los estilos e imágenes deseados.

Ö

4 Recibir consultas, solicitudes, y permitir el contacto con clientes.

Cuenta con un formulario de contacto que permite a los usuarios realizar consultas, preguntas, opiniones y solicitudes.

Ö

5 Realizar promociones por medio Cuenta con un administrador Ö

30

del internet. de banners para publicidad. 6 Mantener la información

actualizada. La sencillez y la economía empleada en el tiempo a la hora de añadir contenidos, impulsa a mantener la información actualizada.

Ö

Requerimientos de menor prioridad

1 Permitir en el futuro el desarrollo de nuevas funcionalidades, modificar o eliminar funcionalidades después de su construcción.

Ofrece la posibilidad de instalar, desinstalar y administrar componentes y módulos.

Ö

2 Administrar el sitio sin tener amplios conocimientos técnicos.

No se necesitan excesivos conocimientos técnicos para administrar el sitio web.

Ö

3 Contar con un módulo dinámico y sencillo de imágenes y texto en donde se puedan visualizar las diferentes ofertas y novedades.

Cuenta con varios módulos para visualizar texto e imágenes en forma dinámica.

4 Contar con un módulo de seguridad, que evite el ingreso a usuarios no autorizados a la administración del sitio web.

Cuenta con un módulo de seguridad que impide el acceso de usuarios no autorizados a la administración del sitio web.

Ö

5 Validar automáticamente la información contenida en los formularios de ingreso.

Cuenta con componentes para validar información contenida en los formularios de ingreso.

Ö

6 Contar con una interfaz de administración para el sitio web.

Cuenta con un panel de control en donde el administrador puede gestionar todo el sitio web.

Ö

Tabla 1.3 Comparación entre requerimientos del sitio Web y características del CMS Joomla Elaborado por los autores

De lo que se puede concluir que Joomla es un gestor de contenido dinámico,

personalizable y escalable, que sin tener mucha habilidad técnica es fácil de

aprender y de usar; además es un CMS de código abierto, esto significa que su

uso es libre de costo (gratis), que se ajusta perfectamente a las necesidades de la

empresa, por lo tanto se justifica su utilización para el desarrollo del sitio web.

31

1.4.2 JUSTIFICACIÓN DE LAS HERRAMIENTAS DE DESARROLLO

Para automatizar los procesos de la empresa Servicios y Lujos Only Cars SC, se

desarrollará un sistema web de facturación e inventario.

Un sistema o aplicación web está normalmente estructurado como una aplicación

de tres capas.

1.4.2.1 Navegador web

El navegador web ofrece la primera capa, en los equipos de la empresa se

encuentra instalado Mozilla Firefox, así como en los equipos de desarrollo, esto

facilitará la implementación de la aplicación y la realización de pruebas, por lo

tanto se justifica su utilización.

1.4.2.2 Lenguaje de programación

Un motor capaz de usar alguna tecnología web dinámica constituye la segunda

capa, PHP es el lenguaje de programación seleccionado ya que cuenta con las

siguientes características:

· Lenguaje multiplataforma.

· Orientado al desarrollo de aplicaciones web dinámicas con acceso a

información almacenada en una base de datos.

· El código fuente escrito en PHP es invisible al navegador web y al cliente

ya que es el servidor el que se encarga de ejecutar el código y enviar su

resultado HTML al navegador. Esto hace que la programación en PHP sea

segura y confiable.

· Capacidad de conexión con la mayoría de los motores de base de datos

que se utilizan en la actualidad, destaca su conectividad con

MySQL y PostgreSQL.

· Posee una amplia documentación en su sitio web oficial, entre la cual se

destaca que todas las funciones del sistema están explicadas y

ejemplificadas en un único archivo de ayuda.

· Cuenta con una biblioteca nativa de funciones sumamente amplia.

· Es libre, por lo que se presenta como una alternativa de fácil acceso para

todos.

32

· Además el equipo de desarrollo cuenta con experiencia en el uso de este

lenguaje.

Todas estas características hacen que se justifique la utilización de PHP como

lenguaje de programación en el desarrollo de la aplicación.

1.4.2.3 Base de datos

Una base de datos constituye la tercera capa. El motor de base de datos

seleccionado es MySQL, ya que:

· El equipo de desarrollo tiene experiencia en el uso de esta herramienta.

· Se encuentra presente en casi todos los servicios de hosting.

· Escalabilidad y flexibilidad.

· Es de alto rendimiento.

· Tiene un robusto soporte transaccional.

· Posee facilidad de gestión.

· Tiene bajo coste al ser gratuita.

1.4.2.4 Otras herramientas

Servidor web, se utilizará Apache ya que:

· Soporta los lenguajes perl, python, y PHP que es el que se utilizará para el

desarrollo de la aplicación.

· Permite la configuración de mensajes de errores personalizados y

negociación de contenido.

· Permite autenticación de base de datos.

Herramienta CASE para diseño, se utilizará Power Designer ya que:

· Es una herramienta sencilla de diseño

· El equipo de desarrollo posee experiencia en el uso de esta herramienta.

Herramienta para la construcción y edición de aplicaciones web, se utilizará

Macromedia Dreamweaver ya que:

· Permite crear y editar páginas web.

· Posee excelentes funcionalidades e integración con otras herramientas.

· Permite crear sitios de forma totalmente gráfica, y dispone de funciones

para acceder al código HTML generado.

33

· Permite la conexión a un servidor, a base de datos, soporte para

programación en ASP, PHP, Javascript, cliente FTP integrado, etc.

Gestión y edición de Base de Datos, se utilizará phpMyAdmin ya que:

· Es sencilla, pues proporciona una interfaz gráfica bastante intuitiva de

utilizar.

· Es una herramienta que permite administrar bases de datos MySQL,

empleando un navegador, tanto para administrarla local como

remotamente.

· Permite crear o eliminar bases de datos; crear, eliminar o alterar tablas;

eliminar, editar o agregar campos; ejecutar consultas SQL, etc.

· Características de phpMyAdmin:

o Multiplataforma.

o Multilenguaje (más de 50).

o Licencia GPL (Licencia Pública General).

o Está escrito en PHP.

Servidor de aplicaciones Web, se utilizará Zend Server Community Edition ya que:

· Es un servidor de aplicaciones Web PHP rápido y confiable.

· Es completamente gratuito, y se puede usar en las fases de desarrollo,

prueba y producción; asegurando así un entorno consistente a lo largo de

todo el ciclo de vida de la aplicación.

· Proporciona múltiples capacidades para mejorar tiempos de respuesta en

las aplicaciones y minimizar la utilización de recursos.

· Es fácil de instalar, compatible con Linux, Windows y Mac OS X.

34

CAPÍTULO 2: PRIMERA ITERACIÓN DEL SISTEMA

2.1 ANÁLISIS DE REQUERIMIENTOS DE NEGOCIO DE LA

EMPRESA

2.1.1 PRESENTACIÓN DEL EQUIPO DE TRABAJO Y ROLES

El equipo de trabajo y roles se exponen en la Tabla 2.1 y están asignados para

las siguientes personas:

Scrum Master

Raúl Córdova

Product Owner

Mirian León

Scrum Team

Eleana Jerez

Andrés Tello

Tabla 2.1 Asignación de roles Elaborado por los autores

Esta metodología pide un mayor compromiso del cliente, para el desarrollo ágil,

por lo que tendrá la posibilidad de contribuir más, a través de su representante en

las reuniones o él mismo.

2.1.2 DESARROLLO DEL PRODUCT BACKLOG

Para iniciar el desarrollo del Sistema LendaSoft4, es importante construir el

Product Backlog, que será elaborado en base a las historias de usuario que se

establecieron conjuntamente con el cliente, en la reunión llamada Sprint Planning

Meeting, a la misma asistieron el equipo desarrollador y el cliente. Las historias de

usuario son breves y concretas, además son el resultado de escuchar al cliente,

están escritas con el vocabulario del negocio del cliente, no con vocabulario

técnico, su estructura es simple y se presenta en la Figura 2.1.

4 LendaSoft: Es el nombre que se ha definido para el sistema de Facturación e Inventario que se desarrollará

en este proyecto.

35

Figura 2.1 Estructura de Historia de Usuario

Fuente: http://rupcajamenor.files.wordpress.com/2008/07/historia-de-usuario9.jpg

· Número: Número de la historia de usuario.

· Usuario: Indica el rol que desempeña el usuario en la empresa.

· Nombre de la historia: Nombre descriptivo de la historia de usuario.

· Prioridad en negocio: Hace referencia a cuán importante es la historia de

usuario para el negocio, y puede ser:

o 5 o 4: representa prioridad alta, siendo 5 más importante que 4.

o 3 o 2: representa prioridad media, siendo 3 más importante que 2.

o 1: representa prioridad baja.

· Riesgo en desarrollo: Muestra un calificador del riesgo, y puede ser:

o Alto.

o Medio.

o Bajo.

36

· Puntos estimados: Los puntos estimados o puntos de historia (PH) es la

medida de estimación utilizada, lo que se intenta es dar un valor del

tamaño de la historia esto implica una combinación de:

- Complejidad: No es lo mismo implementar un alta en un formulario

que, por ejemplo, un algoritmo de inteligencia artificial para un juego.

- Esfuerzo: ¿Es una tarea que tengo que repetir en muchos sitios?

¿Me va a llevar mucho tiempo aunque sea una cosa fácil?

- Riesgo: ¿Estamos trabajando con una tecnología desconocida?

¿Tiene la gente del equipo experiencia en el negocio?

· Iteración asignada: Indica la iteración a la que se ha asignado la historia

de usuario.

· Responsable: Indica quién será el responsable del desarrollo e

implementación de la historia de usuario.

· Descripción: Muestra una descripción sintetizada de la historia de usuario.

· Observaciones del equipo de desarrollo: Representa las limitaciones o

condiciones especiales en la historia de usuario, realizadas por el Scrum

Team.

Desde la Tabla 2.2 hasta la Tabla 2.7 se exponen las tarjetas que representan las

historias de usuario, para el desarrollo del sistema LendaSoft:

Historia de Usuario

Número: 1 Usuario: Vendedor

Nombre historia: Gestión de Clientes

Prioridad en negocio: 5 Riesgo en desarrollo: Bajo

Puntos estimados: 3 Iteración asignada: 1

Responsable: Edgar Andrés – Eleana Inés

37

Descripción:

Como vendedor quiero crear, visualizar, buscar, modificar y eliminar los datos relacionados con mis clientes. Quiero registrar el CI o RUC, el nombre, el teléfono, el móvil, la dirección y el correo electrónico.

Observaciones del equipo de desarrollo:

- No se puede crear un cliente con el mismo CI/RUC.

Tabla 2.2 Historia de Usuario “Gestión de Clientes” Elaborado por los autores

Historia de Usuario

Número: 2 Usuario: Almacenista

Nombre historia: Gestión de Proveedores

Prioridad en negocio: 5 Riesgo en desarrollo: Baja


Responsable: Edgar Andrés

Descripción:

Como almacenista quiero crear, visualizar, buscar, modificar y eliminar los datos relacionados con los proveedores. Quiero registrar el CI o RUC, el nombre, los teléfonos, el móvil, el fax, la dirección y el correo electrónico


- No se puede crear un proveedor con el mismo CI/RUC.

Tabla 2.3 Historia de Usuario “Gestión de Proveedores” Elaborado por los autores

Historia de Usuario


Nombre historia: Gestión de Productos y Tipos de Producto



38


Descripción:

Como almacenista quiero insertar, buscar, modificar, ver y eliminar los productos que ingresen a bodega con su respectivo nombre, proveedor, marca, fecha de ingreso y precio, además quiero clasificarlos según su tipo de producto, y que se emitan alertas cuando el stock esté a punto de agotarse. Quiero insertar, buscar, modificar, ver y eliminar tipos de producto.


- Tipos de Producto: son las cinco categorías principales en las que la Empresa dividió a los productos que comercializa.

- No se puede eliminar un tipo de producto que tenga productos asociados. Tabla 2.4 Historia de Usuario “Gestión de Productos y Tipos de Producto”


Historia de Usuario


Nombre historia: Generación de Facturas

Prioridad en negocio: 4 Riesgo en desarrollo: Medio


Responsable: Eleana Inés

Descripción:

Como vendedor quiero generar facturas a mis clientes y buscar estas facturas por CI/RUC del cliente, por número o estado de la factura. Para insertar una nueva factura quiero seleccionar un cliente ya registrado o insertar uno nuevo en ese momento, además de la inserción deseo modificar, visualizar y eliminar facturas de mis clientes.


- El estado de la factura puede ser “pagada” o “sin pagar” - No se puede eliminar una factura pagada. - La factura no podrá ser generada si no cuenta con número de factura. - No se puede generar una factura con el mismo número de factura.

Tabla 2.5 Historia de Usuario “Generación de Factura” Elaborado por los autores

39

Historia de Usuario


Nombre historia: Gestión de Facturas de los Proveedores




Descripción:

Como almacenista quiero registrar las facturas que me entregan mis proveedores y gestionarlas, es decir llevar un control de las que están y no están pagadas, así como también tener la posibilidad de modificar, ver, eliminar y además buscar las facturas por CI/RUC del proveedor, por número de factura o estado.


- El estado de la factura puede ser “pagada” o “sin pagar” - No se puede eliminar una factura pagada. - La factura no podrá ser generada si no cuenta con un código de factura.

Tabla 2.6 Historia de Usuario “Gestión de Facturas de los Proveedores” Elaborado por los autores

Historia de Usuario

Número: 6 Usuario: Administrador

Nombre historia: Creación de página web informativa




Descripción:

Como administrador quiero una página web que tenga la siguiente información: datos acerca de mi empresa, los tipos de producto y productos que ofrezco, imágenes de los mismos, información de contacto y que mis clientes puedan hacer preguntas a través de mi página web, además deseo que mis clientes puedan registrarse en mi sitio web.


- Se registrarán las visitas realizadas a la página. Tabla 2.7 Historia de Usuario “Creación de página web informativa”


40

A partir de las historias de usuario se obtiene la pila de producto o Product

Backlog que se expone en la Tabla 2.8, en donde las historias de usuario se

ordenan según sus prioridades y necesidades, en esta pila se identificará a cada

una de ellas como requerimientos, con los siguientes datos:

o N: Indica el número de ítem.

· Módulo: Representa el nombre del módulo al que pertenece el

requerimiento, y puede ser:

o Inventario

o Facturación

o Publicidad

o ID: Representa un identificador del requerimiento según el módulo al que

pertenezca y el orden en el que se presente.

· Nivel de prioridad: Representa un indicador de importancia para el cliente,

evaluado de la siguiente forma:

o 5 o 4: representa prioridad alta, siendo 5 más importante que 4.

o 3 o 2: representa prioridad media, siendo 3 más importante que 2.

o 1: representa prioridad baja.

· Nombre: Se refiere al nombre del requerimiento del cliente.

· Descripción: Explica brevemente la funcionalidad del requerimiento.

N Módulo ID Prioridad Nombre Descripción

1 Facturación F1 5 Gestión de Clientes

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de clientes.

2 Inventario I1 5 Gestión de proveedores

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de proveedores.

3 Inventario I2 4 Gestión de tipos Se realiza el ingreso, búsqueda,

41

de productos y productos

modificación, visualización y eliminación de tipos de producto y productos.

4 Facturación F2 4 Generación de facturas.

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de facturas de los clientes

5 Inventario I3 3 Gestión de facturas de los proveedores

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de facturas de los proveedores.

6 Publicidad P1 1 Creación de página web informativa

Se realiza la construcción del sitio web de la Empresa con fines publicitarios.

Tabla 2.8 Product Backlog de la versión 1.0 Elaborado por los autores

2.2 PLANIFICACIÓN DEL PRIMER SPRINT

Aquí se especifican las tareas a realizarse para cumplir con los requerimientos de

la pila de producto, elaboradas solo por el equipo de desarrollo y no es necesaria

la presencia del representante de la Empresa, estas tareas están en orden de

prioridad para el cliente que es importante en Scrum.

Como resultado de esta reunión se tiene un estimado de horas disponibles de

trabajo propuesta por los integrantes del equipo donde cada uno se compromete

a trabajar en este tiempo detallado en la Tabla 2.9.

Longitud del Sprint 20 Días estimados

Días laborables durante el Sprint Entre lunes y viernes excepto feriados

Miembros del Equipo

Días disponibles durante el sprint

Horas disponibles al día

Total horas disponibles

Eleana Jerez 20 6 120 Andrés Tello 20 6 120

Raúl Córdova 6 2 12 Tabla 2.9 Estimado Horas disponibles.


42

Después de haber determinado el tiempo disponible, se prosigue a seleccionar y

organizar los requerimientos del Product Backlog comenzando con el primer

elemento de la pila, es decir, el de más alta prioridad para el cliente. El grupo de

desarrollo también divide las tareas que va a realizar cada miembro del equipo y

el estimado inicial de horas de trabajo dedicadas a realizar cada tarea. Se

guardan en un documento funcional llamado Pila del Sprint, detallada en la Tabla

2.10.

Tareas del Sprint

Voluntario

Esfuerzo estimado

inicial (horas)

Gestión de Clientes

Diseño de Arquitectura del Sistema Andrés 10

Diseño de BDD Eleana 15

Construcción de BDD Eleana 5

Ingresar Cliente Andrés 4

Buscar Cliente Andrés 2

Modificar Cliente Andrés 4

Ver Cliente Andrés 2

Eliminar Cliente Andrés 4

Revisión Raúl 2

Gestión de Proveedores

Ingresar Proveedor Andrés 4

Buscar Proveedor Andrés 2

Modificar Proveedor Andrés 4

Ver Proveedor Andrés 2

Eliminar Proveedor Andrés 4

Revisión Raúl 2

Gestión de Productos y Tipos de Producto

43

Ingresar Tipos de Producto Andrés 2

Buscar Tipos de Producto Andrés 1

Modificar Tipos de Producto Andrés 2

Ver Tipos de Producto Andrés 1

Eliminar Tipos de Producto Andrés 2

Ingresar Producto Andrés 4

Buscar Producto Andrés 3

Modificar Producto Andrés 4

Ver Producto Andrés 2

Eliminar Producto Andrés 4

Revisión Raúl 2

Generación de Facturas

Elaborar Factura Eleana 8

Buscar Factura Eleana 4

Modificar Factura Eleana 8

Ver Factura Eleana 2

Eliminar Factura Eleana 8

Revisión Raúl 2

Gestión de Facturas de los Proveedores

Ingresar Factura de Proveedor Eleana 4

Buscar Factura de Proveedor Eleana 2

Modificar Factura de Proveedor Eleana 4

Ver Factura de Proveedor Eleana 2

Eliminar Factura de Proveedor Eleana 4

Revisión Raúl 2

Total 143

Tabla 2.10 Pila del sprint inicial Elaborado por los autores

44

2.3 AVANCE DIARIO DEL SPRINT

Una vez empezado el Sprint, se llevan a cabo reuniones diarias claves en Scrum,

en la ejecución de las mismas no han surgido mayores inconvenientes y se han

llevado a cabo con normalidad.

Como se describió en la sección 1.3.1.6 Seguimiento Diario del Sprint, se utilizará

la hoja de cálculo para llevar el control del Sprint.

Conforme avanza el desarrollo del sistema, a diario hay que actualizar la pila del

sprint, en horas estimadas de la cantidad de trabajo que queda por terminar.

Poniendo así énfasis no en término de cuanto se hizo en el pasado (un hecho

irrelevante en término de progreso), sino en término de cuanto trabajo queda en el

futuro.

Para detallar esta información primero es necesario especificar el objetivo del

Sprint mostrado en la Tabla 2.11. El resto de información está descrita en la

Figura 2.2, donde se encuentran: los requerimientos escogidos a realizarse en

este Sprint con cada una de sus tareas, las personas que voluntariamente

aceptaron realizarlas, el tiempo en horas estimado y el avance diario en horas del

desarrollo del proyecto.

SPRINT 1

OBJETIVO Desarrollar la Gestión de Agentes Comerciales, Productos y Facturación.

Tabla 2.11 Objetivo del sprint Elaborado por los autores

Después de esta actualización, se suma las horas restantes del equipo en total, y

se dibuja el burn down chart. Esta gráfica muestra cada día una nueva

estimación de cuanto trabajo queda (medido en personas-hora) para terminar las

tareas del equipo, detallada en la Figura 2.3.

45

Figura 2.3 Burn down chart


2.4 ELABORACIÓN DE LA VERSIÓN 1.0 DEL SISTEMA

Al usar Scrum; el desarrollo del sistema se basa en los requerimientos, que están

en la pila del producto, en este Sprint se seleccionaron los cinco de más alta

prioridad para el cliente, cuyo desarrollo se tratará en esta sección.

2.4.1 ARQUITECTURA Y BASE DE DATOS DEL SISTEMA

Estas actividades fueron incluidas en la primera tarea del Sprint, ya que marcaron

el inicio para el desarrollo de todo el sistema LendaSoft.

2.4.1.1 Arquitectura del Sistema

Al utilizar una metodología ágil, la arquitectura también se sustenta desde su

diseño en este principio, con implementación de patrones que garanticen

desacoplamiento de los principales módulos que componen la solución y la

selección de un modelo arquitectónico que favorezca la evolución del software.

46

Fig

ura

2.2

Sp

rin

t b

ackl

og

co

mp

leto

Ela

bora

do p

or lo

s au

tore

s

47

Como se muestra en la Figura 2.4 la arquitectura consiste en tres capas:

· Primera Capa: Presentación

o Esta capa es donde se presenta el sistema al usuario, le comunica la

información y la captura en un mínimo de proceso.

o Se comunica únicamente con la capa de negocio.

o Es una interfaz gráfica “amigable” para el usuario.

· Segunda Capa: Lógica de Negocio

o En esta capa se reciben las peticiones del usuario y se envían las

respuestas tras el proceso.

o Aquí se establecen todas las reglas de negocio que deben

cumplirse.

o Se comunica con la capa de presentación, para recibir las solicitudes

y presentar los resultados.

o Se comunica con la capa de datos, para solicitar al gestor de base

de datos almacenar o recuperar datos de él.

o El software implicado en esta capa es el motor PHP y el servidor

Web Apache.

· Tercera Capa: Datos

o En esta capa reside la información del cliente y se encarga de

acceder a la misma.

o Está formada por el motor de BDD MySQL y su gestor phpMyAdmin,

que realizan todo el almacenamiento de datos, reciben solicitudes

de almacenamiento o recuperación de información desde la capa de

negocio.

48

Figura 2.4 Arquitectura de 3 capas Elaborado por los autores

Al usar Scrum como metodología son bienvenidos los cambios, esto conlleva a

que la arquitectura sea diseñada para soportar un conjunto de funcionalidades y

requerimientos que sean cambiantes, esta visión de arquitectura está atenta a los

mismos y los soporta.

2.4.1.2 Diseño de Base de Datos

Para crear una base de datos se debe realizar dos tipos de diseño: uno lógico y

uno físico. El diseño lógico es un modelo abstracto de la base de datos desde una

perspectiva de negocio. Luego de obtener el modelo lógico se genera el modelo

físico, donde se define el nombre real de cada columna en la base de datos con

su respectivo tipo de dato; el modelo físico viene definido por un motor de base de

datos, que en este caso es MySQL. De acuerdo a los requerimientos

especificados por la empresa en la sección 2.1.2 en donde se realizó el desarrollo

del Product Backlog, se ha obtenido el modelo conceptual planteado en la Figura

2.5 y a partir de este se ha conseguido el modelo físico de la base de datos que

se presenta en la Figura 2.6, ambos esquemas fueron generados mediante el

empleo de la herramienta Power Designer justificada en la sección 1.4.2.4 Otras

herramientas.

49

A continuación se realiza una explicación detallada de una tabla de la base de

datos, en este caso la de proveedores que se muestra en la Tabla 2.12, en donde

se especifica el nombre, descripción, atributos, tipos de dato, clave primaria y

claves foráneas.

Nombre de la tabla proveedores

Descripción Contiene los datos de los proveedores.

Atributo Tipo de Dato Clave Primaria

Clave Foránea

Descripción

codproveedor varchar(13) Ö Identificador.

nombre varchar(50) Nombre completo del proveedor.

telefono1 varchar(14) Número de teléfono convencional 1 del proveedor.

telefono2 varchar(14) Número de teléfono convencional 2 del proveedor.

fax varchar(14) Número de fax del proveedor.

móvil varchar(14) Número de teléfono móvil del proveedor.

email varchar(35) Correo electrónico del proveedor.

dirección varchar(200) Dirección del proveedor.

borrado varchar(1) Si el proveedor ha sido borrado tiene valor igual a 1 caso contrario es igual a 0.

Tabla 2.12 Descripción de la tabla proveedores Elaborado por los autores

En el Anexo 1 se encuentra el resto de tablas que conforman la base de datos.

50

Pfac

tutm

p_fa

ctul

inea

tmp

Pfac

tulin

eatm

p_fa

ctul

inea

Pfac

tura

s_fa

ctul

inea

prov

eedo

res_

fact

uras

p

prov

eedo

res_

fact

ulin

eap

tipos

prod

ucto

_pro

duct

os

fact

uras

_cob

ros

form

apag

o_lib

rodi

ario

prov

eedo

res_

libro

diar

io

clie

ntes

_lib

rodi

ario

clie

ntes

_fac

tura

s

form

apag

o_co

bros

form

apag

o_pa

gos

fact

uras

p_pa

gos

prov

eedo

res_

pago

s

clie

ntes

_cob

ros

Cfac

tura

stmp_

fact

ulin

eatm

pCf

actu

linea

tmp_

fact

ulin

ea

Cfac

tura

s_fa

ctul

inea

fact

uras

_lib

rodi

ario

fact

uras

p_lib

rodi

ario

prov

eedo

res_

prod

ucto

spr

ovee

dore

s_pr

oduc

tos2

fact

uras

ptm

p

codf

actu

rafe

cha

<pi>

Inte

ger

Date

<M>

<M>

Iden

tifie

r_1

...

fact

ulin

eapt

mp

num

linea

cod_

tipo_

prod

ucto

codi

goca

ntid

adpr

ecio

impo

rtedc

to

<pi>

Inte

ger

Inte

ger

Varia

ble

char

acte

rs (1

5)Fl

oat

Floa

tFl

oat

Byte

<M>

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

fact

uras

p

codf

actu

rafe

cha

iva

esta

doto

talfa

ctur

afe

chap

ago

borra

do

<pi>

Varia

ble

char

acte

rs (2

0)Da

teBy

teVa

riabl

e ch

arac

ters

(1)

Floa

tDa

teVa

riabl

e ch

arac

ters

(1)

<M>

<M>

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

fact

ulin

eap

cod_

tipo_

prod

ucto

codi

goca

ntid

adpr

ecio

impo

rtedc

to

Inte

ger

Varia

ble

char

acte

rs (1

5)Fl

oat

Floa

tFl

oat

Byte

<M>

<M>

<M>

<M>

<M>

prov

eedo

res

codp

rove

edor

nom

bre

tele

fono

1te

lefo

no2

fax

mov

ilem

ail

dire

ccio

nbo

rrado

<pi>

Varia

ble

char

acte

rs (1

3)Va

riabl

e ch

arac

ters

(50)

Varia

ble

char

acte

rs (1

4)Va

riabl

e ch

arac

ters

(14)

Varia

ble

char

acte

rs (1

4)Va

riabl

e ch

arac

ters

(14)

Varia

ble

char

acte

rs (3

5)Va

riabl

e ch

arac

ters

(200

)Va

riabl

e ch

arac

ters

(1)

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

tipos

prod

ucto

cod_

tipo_

prod

ucto

nom

bre

borra

do

<pi>

Inte

ger

Varia

ble

char

acte

rs (5

0)Va

riabl

e ch

arac

ters

(1)

<M>

Iden

tifie

r_1

...

prod

ucto

s

codp

rodu

cto

refe

renc

iano

mbr

em

arca

stock

stock

_min

imo

aviso

_min

imo

fech

a_in

gres

oob

serv

acio

nes

prec

io_c

ompr

apr

ecio

_alm

acen

prec

io_t

iend

apr

ecio

_pvp

prec

io_i

vabo

rrado

<pi>

Inte

ger

Varia

ble

char

acte

rs (5

0)Va

riabl

e ch

arac

ters

(50)

Varia

ble

char

acte

rs (5

0)In

tege

rIn

tege

rVa

riabl

e ch

arac

ters

(1)

Date

Text

Floa

tFl

oat

Floa

tFl

oat

Floa

tVa

riabl

e ch

arac

ters

(1)

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

fact

uras

codf

actu

ranu

mfa

ctur

aci

udad

fech

aiv

aes

tado

tota

lfact

ura

fech

aven

cim

ient

obo

rrado

<pi>

Inte

ger

Varia

ble

char

acte

rs (1

3)Va

riabl

e ch

arac

ters

(50)

Date

Byte

Varia

ble

char

acte

rs (1

)Fl

oat

Date

Varia

ble

char

acte

rs (1

)

<M>

Iden

tifie

r_1

...

clie

ntes

codc

lient

eno

mbr

ete

lefo

nom

ovil

emai

ldi

recc

ion

borra

do

<pi>

Varia

ble

char

acte

rs (1

3)Va

riabl

e ch

arac

ters

(50)

Varia

ble

char

acte

rs (1

4)Va

riabl

e ch

arac

ters

(14)

Varia

ble

char

acte

rs (3

5)Va

riabl

e ch

arac

ters

(200

)Va

riabl

e ch

arac

ters

(1)

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

pago

s

id impo

rtenu

mdo

cum

ento

fech

apag

oob

serv

acio

nes

<pi>

Inte

ger

Floa

tVa

riabl

e ch

arac

ters

(30)

Date

Text

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

cobr

os

id impo

rtenu

mdo

cum

ento

fech

acob

roob

serv

acio

nes

<pi>

Inte

ger

Floa

tVa

riabl

e ch

arac

ters

(30)

Date

Text

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

form

apag

o

codf

orm

apag

ono

mbr

efp

borra

do

<pi>

Inte

ger

Varia

ble

char

acte

rs (4

0)Va

riabl

e ch

arac

ters

(1)

<M>

<M>

<M>

Iden

tifie

r_1

...

libro

diar

io

id fech

atip

odoc

umen

tonu

mpa

goto

tal

<pi>

Inte

ger

Date

Varia

ble

char

acte

rs (1

)Va

riabl

e ch

arac

ters

(30)

Floa

t

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

tabb

acku

p

id deno

min

acio

nfe

cha

hora

arch

ivo

<pi>

Inte

ger

Varia

ble

char

acte

rs (5

0)Da

teTi

me

Varia

ble

char

acte

rs (4

0)

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

fact

uras

tmp

codf

actu

rac

fech

aIn

tege

rDa

te<M

><M

>

Iden

tifie

r_1

...

fact

ulin

eatm

p

num

linea

cco

d_tip

o_pr

oduc

toco

digo

cant

idad

prec

ioim

porte

dcto

<pi>

Inte

ger

Inte

ger

Varia

ble

char

acte

rs (1

5)Fl

oat

Floa

tFl

oat

Byte

<M>

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

fact

ulin

ea

num

fact

ura

ciud

adco

d_tip

o_pr

oduc

toco

digo

cant

idad

prec

ioim

porte

dcto

Varia

ble

char

acte

rs (1

3)Va

riabl

e ch

arac

ters

(50)

Inte

ger

Varia

ble

char

acte

rs (1

5)Fl

oat

Floa

tFl

oat

Byte

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

prov

eedo

res2

codp

rove

edor

nom

bre

tele

fono

1te

lefo

no2

fax

mov

ilem

ail

dire

ccio

nbo

rrado

<pi>

Varia

ble

char

acte

rs (1

3)Va

riabl

e ch

arac

ters

(50)

Varia

ble

char

acte

rs (1

4)Va

riabl

e ch

arac

ters

(14)

Varia

ble

char

acte

rs (1

4)Va

riabl

e ch

arac

ters

(14)

Varia

ble

char

acte

rs (3

5)Va

riabl

e ch

arac

ters

(200

)Va

riabl

e ch

arac

ters

(1)

<M>

<M>

<M>

<M>

<M>

<M>

<M>

<M>

Iden

tifie

r_1

...

F

igu

ra 2

.5 M

od

elo

Co

nce

ptu

al d

e la

Bas

e d

e D

ato

s

Ela

bora

do p

or lo

s au

tore

s

51

FK_P

FAC

TU

TM

P_F

AC

TU

LIN

EA

TM

PFK

_PFA

CT

ULI

NE

AT

MP

_FA

CT

ULI

NE

A

FK_P

FAC

TU

RA

S_F

AC

TU

LIN

EA

FK_P

RO

VE

ED

OR

ES

_FA

CT

UR

AS

P

FK_P

RO

VE

ED

OR

ES

_FA

CT

ULI

NE

AP

FK_T

IPO

SP

RO

DU

CT

O_P

RO

DU

CT

OS

FK_F

AC

TU

RA

S_C

OB

RO

S

FK_F

OR

MA

PA

GO

_LIB

RO

DIA

RIO

FK_P

RO

VE

ED

OR

ES

_LIB

RO

DIA

RIO

FK_C

LIE

NT

ES

_LIB

RO

DIA

RIO

FK_C

LIE

NT

ES

_FA

CT

UR

AS

FK_F

OR

MA

PA

GO

_CO

BR

OS

FK_F

OR

MA

PA

GO

_PA

GO

S

FK_F

AC

TU

RA

SP

_PA

GO

S

FK_P

RO

VE

ED

OR

ES

_PA

GO

S

FK_C

LIE

NT

ES

_CO

BR

OS

FK_C

FAC

TU

RA

ST

MP

_FA

CT

ULI

NE

AT

MP

FK_C

FAC

TU

LIN

EA

TM

P_F

AC

TU

LIN

EA

FK_C

FAC

TU

RA

S_F

AC

TU

LIN

EA

FK_F

AC

TU

RA

S_L

IBR

OD

IAR

IOFK_F

AC

TU

RA

SP

_LIB

RO

DIA

RIO

FK_P

RO

VE

ED

OR

ES

_PR

OD

UC

TO

S

fact

uras

ptm

p

codf

actu

rafe

cha

int

date

<pk>

fact

ulin

eapt

mp

num

linea

codf

actu

raco

d_tip

o_pr

oduc

toco

digo

cant

idad

prec

ioim

porte

dcto

...

int

int

int

varc

har(1

5)flo

atflo

atflo

attin

yint

<pk>

<fk>

fact

uras

p

codf

actu

raco

dpro

veed

orfe

cha

iva

esta

doto

talfa

ctur

afe

chap

ago

borra

do...

varc

har(2

0)va

rcha

r(13)

date

tinyi

ntva

rcha

r(1)

float

date

varc

har(1

)

<pk>

<fk>

fact

ulin

eap

codf

actu

raco

dpro

veed

ornu

mlin

eaco

d_tip

o_pr

oduc

toco

digo

cant

idad

prec

ioim

porte

dcto

...

varc

har(2

0)va

rcha

r(13)

int

int

varc

har(1

5)flo

atflo

atflo

attin

yint

<fk2

><f

k3>

<fk1

>

prov

eedo

res

codp

rove

edor

nom

bre

tele

fono

1te

lefo

no2

fax

mov

ilem

ail

dire

ccio

nbo

rrado

...

varc

har(1

3)va

rcha

r(50)

varc

har(1

4)va

rcha

r(14)

varc

har(1

4)va

rcha

r(14)

varc

har(3

5)va

rcha

r(200

)va

rcha

r(1)

<pk>

tipos

prod

ucto

cod_

tipo_

prod

ucto

nom

bre

borra

do...

int

varc

har(5

0)va

rcha

r(1)

<pk>

prod

ucto

s

codp

rodu

cto

codp

rove

edor

1co

dpro

veed

or2

cod_

tipo_

prod

ucto

refe

renc

iano

mbr

em

arca

stoc

kst

ock_

min

imo

avis

o_m

inim

ofe

cha_

ingr

eso

obse

rvac

ione

spr

ecio

_com

pra

prec

io_a

lmac

enpr

ecio

_tie

nda

prec

io_p

vppr

ecio

_iva

borra

do...

int

varc

har(1

3)va

rcha

r(13)

int

varc

har(5

0)va

rcha

r(50)

varc

har(5

0)in

tin

tva

rcha

r(1)

date

text

float

float

float

float

float

varc

har(1

)

<pk>

<fk2

><f

k3>

<fk1

>

fact

uras

codf

actu

raco

dclie

nte

num

fact

ura

ciud

adfe

cha

iva

esta

doto

talfa

ctur

afe

chav

enci

mie

nto

borra

do...

int

varc

har(1

3)va

rcha

r(13)

varc

har(5

0)da

tetin

yint

varc

har(1

)flo

atda

teva

rcha

r(1)

<pk>

<fk>

clie

ntes

codc

lient

eno

mbr

ete

lefo

nom

ovil

emai

ldi

recc

ion

borra

do...

varc

har(1

3)va

rcha

r(50)

varc

har(1

4)va

rcha

r(14)

varc

har(3

5)va

rcha

r(200

)va

rcha

r(1)

<pk>

pago

s

id codf

actu

raco

dpro

veed

orco

dfor

map

ago

impo

rtenu

mdo

cum

ento

fech

apag

oob

serv

acio

nes

...

int

varc

har(2

0)va

rcha

r(13)

int

float

varc

har(3

0)da

tete

xt

<pk>

<fk1

><f

k2>

<fk3

>

cobr

os

id codf

actu

raco

dfor

map

ago

codc

lient

eim

porte

num

docu

men

tofe

chac

obro

obse

rvac

ione

s...

int

int

int

varc

har(1

3)flo

atva

rcha

r(30)

date

text

<pk>

<fk2

><f

k3>

<fk1

>

form

apag

o

codf

orm

apag

ono

mbr

efp

borra

do...

int

varc

har(4

0)va

rcha

r(1)

<pk>

libro

diar

io

id codd

ocum

ento

codf

orm

apag

oco

dcom

erci

alfe

cha

tipod

ocum

ento

num

pago

tota

l...

int

varc

har(2

0)in

tva

rcha

r(13)

date

varc

har(1

)va

rcha

r(30)

float

<pk>

<fk5

><f

k2>

<fk1

>

tabb

acku

p

id deno

min

acio

nfe

cha

hora

arch

ivo

...

int

varc

har(5

0)da

tetim

eva

rcha

r(40)

<pk>

fact

uras

tmp

codf

actu

rafe

cha

int

date

<pk>

fact

ulin

eatm

p

num

linea

codf

actu

raco

d_tip

o_pr

oduc

toco

digo

cant

idad

prec

ioim

porte

dcto

...

int

int

int

varc

har(1

5)flo

atflo

atflo

attin

yint

<pk>

<fk>

fact

ulin

ea

num

linea

codf

actu

ranu

mfa

ctur

aci

udad

cod_

tipo_

prod

ucto

codi

goca

ntid

adpr

ecio

impo

rtedc

to...

int

int

varc

har(1

3)va

rcha

r(50)

int

varc

har(1

5)flo

atflo

atflo

attin

yint

<fk1

><f

k2>

F

igu

ra 2

.6 M

od

elo

Fís

ico

de

la B

ase

de

Dat

os

Ela

bora

do p

or lo

s au

tore

s

52

Para fines de diseño se ha descompuesto el sistema en las siguientes interfaces:

· Gestión de Agentes Comerciales.

· Gestión de Productos.

· Gestión de Facturación.

A continuación se exponen las interfaces mas relevantes del sistema LendaSoft

con sus respectivas opciones y operaciones, el resto de interfaces se presentan

en el Anexo 2.

2.4.2 GESTIÓN DE AGENTES COMERCIALES

La interface de Agentes Comerciales se visualiza en la Figura 2.7 y está

conformada por las opciones de Clientes y Proveedores, las que permitirán

conectarse al sistema a través de la capa de aplicación. En donde se realizarán

las operaciones de creación, búsqueda, modificación, visualización y eliminación

en la capa de datos. Estas interfaces corresponden a las Historias de Usuario 1 y

2 expuestas en la sección 2.1.2 en donde se desarrolló el product backlog.

Figura 2.7 Selección del menú Agentes Comerciales Elaborado por los autores

53

2.4.2.1 Clientes

En esta sección se detalla como se desarrolló la opción de Clientes en el sistema,

mostrando primero la interface, después el fragmento de código que ejecuta las

operaciones descritas en la Historia de Usuario 1.

2.4.2.1.1 Insertar Cliente

Para acceder a la interface de Insertar Cliente que se presenta en la Figura 2.8,

se procede a seleccionar el menú Agentes Comerciales, el sub menú Clientes y el

botón Nuevo Cliente.

Figura 2.8 Interface Insertar Cliente


El código que permite la inserción de los datos del cliente en la base de datos se

visualiza en la Figura 2.9.

Figura 2.9 Código Insertar Cliente


2.4.2.2 Proveedores

En esta sección se muestra como se desarrolló la opción de Proveedores del

sistema, mostrando primero la interface, después la parte del código que ejecuta

las operaciones descritas en la Historia de Usuario 2.

54

2.4.2.2.1 Insertar Proveedor

Para acceder a la interface de Insertar Proveedor que se muestra en la Figura

2.10, se procede a seleccionar el menú Agentes Comerciales, el sub menú

Proveedores y el botón Nuevo proveedor.

Figura 2.10 Interface Insertar Proveedor Elaborado por los autores

El código que permite la inserción de los datos del proveedor en la base de datos

se presenta en la Figura 2.11.

Figura 2.11 Código Insertar Proveedor Elaborado por los autores

2.4.3 GESTIÓN DE PRODUCTOS

La interface de Gestión de Productos que se visualiza en la Figura 2.12 está

conformada por las opciones Tipos de Producto y Productos, las que permitirán

55

conectarse al sistema por medio de la capa de aplicación. En donde se puede

realizar las operaciones de creación, búsqueda, modificación, visualización y

eliminación en la capa de datos. Estas interfaces corresponden a la Historia de

Usuario 3.

Figura 2.12 Selección del menú Gestión de Productos Elaborado por los autores

2.4.3.1 Tipos de Producto

En esta sección se expone como se desarrolló la opción de Tipos de Producto en

el sistema, mostrando primero la interface, después el fragmento de código que

ejecuta las operaciones descritas en la Historia de Usuario 3.

2.4.3.1.1 Insertar Tipo de Producto

Para acceder a la interface de Insertar Tipo de Producto que se observa en la

Figura 2.13, se procede a seleccionar el menú Gestión de Productos, el sub menú

Tipos de Producto y el botón Nuevo tipo de producto.

56

Figura 2.13 Interface Insertar Tipo de Producto Elaborado por los autores

El código que permite la inserción de los datos de un Tipo de Producto en la base

de datos se muestra en la Figura 2.14.

Figura 2.14 Código Insertar Tipo de Producto Elaborado por los autores

2.4.3.2 Productos

En esta sección se presenta como se desarrolló la opción de Productos en el

sistema, mostrando primero la interface, después el fragmento de código que


2.4.3.2.1 Insertar Producto

Para acceder a la interface de Insertar Producto que se observa en la Figura 2.15,

se procede a seleccionar el menú Gestión de Productos, el sub menú Productos y

el botón Nuevo Producto.

57

Figura 2.15 Interface Insertar Producto Elaborado por los autores

El código que permite la inserción de los datos de un nuevo producto en la base

de datos se presenta en la Figura 2.16.

Figura 2.16 Código Insertar Producto Elaborado por los autores

58

2.4.4 GESTIÓN DE FACTURACIÓN

La interface Gestión de Facturación que se detalla en la Figura 2.17, está

conformada por las opciones: Facturas de los Clientes y Facturas de los

Proveedores, las que permitirán conectarse al sistema a través de la capa de

aplicación. En donde se puede realizar las operaciones de creación, búsqueda,

modificación, visualización y eliminación en la capa de datos. Estas interfaces

corresponden a las Historias de Usuario 4 y 5.

Figura 2.17 Selección del menú Gestión de Facturación Elaborado por los autores

2.4.4.1 Facturas de los Clientes

En esta sección se muestra como se desarrolló la opción Facturas de los clientes

en el sistema, mostrando primero la interface, y a continuación el fragmento de

código que ejecuta las operaciones descritas en la Historia de Usuario 4.

2.4.4.1.1 Insertar Factura

Para acceder a la interface de Insertar Factura que se observa en la Figura 2.18,

se procede a seleccionar el menú Gestión de Facturación, el sub menú Facturas

de los Clientes y el botón Nueva factura.

59

Figura 2.18 Interface Insertar Factura Elaborado por los autores

El código que permite la inserción de los datos de la factura en la base de datos

se muestra en la Figura 2.19.

Figura 2.19 Código Insertar Factura Elaborado por los autores

60

2.4.4.1.2 Modificar Factura

Para acceder a la interface de Modificar Factura que se expone en la Figura 2.20,

hay que ingresar a Facturas, donde se selecciona la que se desea modificar.

Figura 2.20 Interface Modificar Factura Elaborado por los autores

El código que permite la modificación de los datos de la factura en la base de

datos se muestra en la Figura 2.21.

61

Figura 2.21 Código Modificar Factura Elaborado por los autores

62

2.4.4.2 Facturas de los Proveedores

En esta sección se muestra como se desarrolló la opción Facturas de los

Proveedores en el sistema, mostrando primero la interface, y a continuación el

fragmento de código que ejecuta las operaciones descritas en la Historia de

usuario 5.

2.4.4.2.1 Ingresar Factura de Proveedor

Para acceder a la interface de Insertar Factura que se observa en la Figura 2.22,

se procede a seleccionar el menú Gestión de Facturación, el sub menú Facturas

de los Proveedores y el botón Nueva factura.

Figura 2.22 Interface Insertar Factura de Proveedor Elaborado por los autores

El código que permite la inserción de los datos de la factura del proveedor en la

base de datos se presenta en la Figura 2.23.

63

Figura 2.23 Código Insertar Factura de Proveedor Elaborado por los autores

64

2.5 PRUEBAS DE LA VERSIÓN 1.0 DEL SISTEMA

Los casos de prueba de Aceptación se han desarrollado en base a las historias de

usuario descritas en la sección 2.1.2 en donde se desarrolló el Product Backlog,

para comprobar la estabilidad y buen funcionamiento del sistema. Los tipos de

pruebas realizadas son de tipo alfa, es decir, hechas por el cliente en ambiente

de desarrollo. Se realizaron pruebas de todas las operaciones que puede hacer

el sistema, pero se presentan las de más relevancia. Los resultados de las

pruebas están registrados desde la Tabla 2.13 hasta la Tabla 2.27, donde se

relacionan con la historia de usuario correspondiente. Los datos expuestos en

estas tablas se detallan a continuación:

· Código: Es la identificación única de cada caso de prueba.

· Historia de (Nro. y Nombre): es la identificación de la historia de

usuario a la que se refiere el caso de prueba.

· Descripción: Muestra una breve explicación de lo que se realiza en

el caso de prueba.

· Condiciones de Ejecución: Se muestran las condiciones previas

que se necesitan para que el caso de prueba se realice.

· Entrada (pasos de ejecución): Es la descripción detallada de los

pasos que se ejecutaron en los casos de prueba.

· Resultado esperado: Es el resultado esperado al realizar el caso de

prueba.

· Resultado Obtenido: Es el resultado que se consigue al realizar el

caso de prueba.

· Acciones Correctivas: Son medidas que se deben tomar para

corregir un resultado obtenido si éste es diferente del esperado.

· Evaluación de la prueba: Se muestra el resultado final del caso de

prueba y la evaluación puede ser:

o Buena.

o Media.

o Mala.

65

2.5.1 PRUEBAS DE GESTIÓN DE AGENTES COMERCIALES

Las pruebas de Agentes Comerciales están conformadas por las pruebas de

gestión de clientes y proveedores, correspondientes a las Historias de usuario 1 y

2 respectivamente.

2.5.1.1 Pruebas de Clientes

En esta sección se detalla como se realizaron las siguientes pruebas de Gestión

de Clientes del sistema:

· Pruebas de inserción de Cliente.

· Pruebas de modificación de Cliente.

· Pruebas de eliminación de Cliente.

Caso de Prueba de Aceptación

Código: 1 Historia de (Nro. y Nombre): 1 Gestión de Clientes

Nombre de Caso de Prueba: Prueba Inserción de Cliente

Descripción: Se procede a insertar los siguientes datos de un nuevo cliente: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico y verificar que se almacene en la Base de Datos.

Condiciones de Ejecución: El campo de correo electrónico tiene su formato característico, en el campo CI/RUC se ingresan máximo 13 caracteres, ingresar el campo Nombre.

Entrada (pasos de ejecución):

1. Acceder a la interface “Insertar Cliente”.

2. Ingresar los datos correspondientes en los campos: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico. Se ingresaron datos erróneos

3. Dar clic en el botón “Aceptar”.

4. Se muestran los datos ingresados y se validan que sean correctos.

5. Dar clic en “Aceptar”.

Resultado esperado: El despliegue de la pantalla de ingreso correcto de datos.

Resultado Obtenido: El sistema permitió que se ingresen datos incorrectos.

Acciones Correctivas: Realizar las respectivas validaciones en los campos del formulario.

66

Evaluación de la prueba: Media

No se mostró el resultado esperado, pero se ejecutaron las respectivas acciones correctivas.

Tabla 2.13 Caso de Prueba de Aceptación “Prueba Inserción de Cliente” Elaborado por los autores



Nombre de Caso de Prueba: Prueba Modificación de Cliente

Descripción: Se procede a modificar uno o varios de los siguientes datos de un cliente existente: Nombre, Teléfono, Móvil, Dirección, Correo electrónico y verificar que se realicen los cambios en la Base de Datos.

Condiciones de Ejecución: Que el cliente a modificarse exista, el campo de correo electrónico tiene su formato característico.


1. Acceder a la interface “Clientes”.

2. Señalar el cliente que se desea modificar.

3. Modificar uno o varios de los datos correspondientes a los campos: Nombre, Teléfono, Móvil, Dirección, Correo electrónico. Los datos modificados fueron erróneos.


5. Se muestran los datos modificados y se verifican que sean correctos.


Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos.

Resultado Obtenido: El sistema permitió que se ingresen datos erróneos al modificarlos.

Acciones Correctivas: Validar que los datos que se modifiquen sean correctos


No se mostró el resultado esperado pero se ejecutaron las acciones correctivas

Tabla 2.14 Caso de Prueba de Aceptación “Prueba Modificación de Cliente” Elaborado por los autores

67



Nombre de Caso de Prueba: Prueba Eliminación de Cliente

Descripción: Se procede a eliminar un cliente seleccionado y verificar que se realice el cambio en la Base de Datos.

Condiciones de Ejecución: Que el cliente a eliminarse exista y se muestre en la interface de clientes.


1. Acceder a la interface “Clientes”.

2. Señalar el cliente que se desea eliminar.

3. Eliminar el cliente seleccionado.


5. Se muestra que el cliente ha sido eliminado.


Resultado esperado: La eliminación del cliente.

Resultado obtenido: Se eliminó al cliente seleccionado.

Acciones Correctivas: Ninguna

Evaluación de la prueba: Buena

Se mostró el resultado esperado.

Tabla 2.15 Caso de Prueba de Aceptación “Prueba Eliminación de Cliente” Elaborado por los autores

2.5.1.2 Pruebas de Proveedores

Aquí se presenta como se realizaron las siguientes pruebas de Gestión de

Proveedores del sistema:

· Pruebas de inserción de Proveedor.

· Pruebas de modificación de Proveedor.

· Pruebas de eliminación de Proveedor.

68


Código: 4 Historia de (Nro. y Nombre): 2 Gestión de Proveedores

Nombre de Caso de Prueba: Prueba Inserción de Proveedor

Descripción: Se procede a insertar los siguientes datos de un nuevo proveedor: CI o RUC, Nombre, Teléfono 1, Teléfono 2, Móvil, Fax, Dirección, Correo electrónico y verificar que se almacenen en la Base de Datos.

Condiciones de Ejecución: El campo de correo electrónico tiene su formato característico, en el campo CI/RUC se ingresan máximo 13 caracteres, ingresar el campo Nombre.


1. Acceder a la interface “Insertar Proveedor”.

2. Ingresar los datos correspondientes en los campos: CI o RUC, Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico. Se ingresaron datos erróneos.


4. Se muestran los datos ingresados y se verifican que sean correctos.

5. Dar clic en “Aceptar”

Resultado esperado: El despliegue de la pantalla de Ingreso correcto de datos.

Resultado obtenido: El sistema permitió el ingreso de datos erróneos.

Acciones correctivas: Validar los datos que se ingresan.


No se mostró el resultado esperado pero se ejecutaron las acciones correctivas.

Tabla 2.16 Caso de Prueba de Aceptación “Prueba Inserción de Proveedor” Elaborado por los autores



Nombre de Caso de Prueba: Prueba Modificación de Proveedor

Descripción: Se procede a modificar uno o varios de los siguientes datos de un proveedor existente: Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico y verificar que se realicen los cambios en la Base de Datos.

69

Condiciones de Ejecución: Debe existir el proveedor a modificarse, el campo de correo electrónico tiene su formato característico.


1. Acceder a la interface “Proveedores”.

2. Señalar el proveedor que se desea modificar.

3. Modificar uno o varios de los datos correspondientes a los campos: Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico. Al modificar los datos estos fueron erróneos.





Resultado obtenido: El sistema permitió que al modificarse los datos éstos fueran erróneos.

Acciones Correctivas: Validar los datos modificados


No se mostró el resultado esperado, pero se ejecutaron las acciones correctivas.

Tabla 2.17 Caso de Prueba de Aceptación “Prueba Modificación de Proveedor” Elaborado por los autores



Nombre de Caso de Prueba: Prueba Eliminación de Proveedor

Descripción: Se procede a eliminar un proveedor seleccionado y verificar que se realice el cambio en la Base de Datos.

Condiciones de Ejecución: Que el proveedor a eliminarse exista y se muestre en la interface de proveedores.


1. Acceder a la interface “Proveedores”.

70

2. Señalar el proveedor que se desea eliminar.

3. Eliminar el proveedor seleccionado.


5. Se muestra que el proveedor ha sido eliminado.


Resultado esperado: La eliminación del proveedor.

Resultado obtenido: Se permitió la eliminación del proveedor seleccionado.

Acciones Correctivas: Ninguna.



Tabla 2.18 Caso de Prueba de Aceptación “Prueba Eliminación de Proveedor” Elaborado por los autores

2.5.2 PRUEBAS DE GESTIÓN DE PRODUCTOS

En esta sección se detallan las siguientes pruebas:

· Pruebas de inserción de Tipos de Producto.

· Pruebas de inserción de Producto.

· Pruebas de búsqueda de Producto.

· Pruebas de modificación de Producto.


Código: 7 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos.

Nombre de Caso de Prueba: Prueba Inserción de Tipo de Producto

Descripción: Se procede a insertar el nombre de un nuevo tipo de producto y se verifica que se almacene en la Base de Datos.

Condiciones de Ejecución: Ingresar datos en el campo Nombre.


1. Acceder a la interface “Insertar Tipo de Producto”.

2. Ingresar el nombre del nuevo Tipo de Producto.

71




Resultado esperado: El despliegue de la pantalla de Ingreso correcto del nombre.

Resultado obtenido: Se ingresó el nuevo Tipo de Producto




Tabla 2.19 Caso de Prueba de Aceptación “Prueba Inserción de Tipo de Producto” Elaborado por los autores


Código: 8 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos

Nombre de Caso de Prueba: Prueba de Inserción de Producto

Descripción: Se procede a insertar los siguientes datos de un nuevo producto: Referencia, Nombre, Marca, Stock, Stock mínimo, Fecha de ingreso, Observaciones, Precio de compra, Precio de almacén, Precio de Tienda, PVP, precio con IVA. Y los siguientes datos: Tipo de producto, Proveedor 1, Proveedor 2 y Aviso mínimo se escogen del combo mostrado en la interface y verificar que se almacenen en la Base de Datos.

Condiciones de Ejecución: Ingresar el campo Referencia, Descripción, Observaciones y Nombre.


1. Acceder a la interface “Insertar Producto”.

2. Ingresar y escoger los datos descritos anteriormente en sus correspondientes campos. Estos datos fueron erróneos




Resultado esperado: El despliegue de la pantalla de Ingreso correcto de datos.

Resultado obtenido: El sistema valida algunos campos pero otros no.

72

Acciones Correctivas: Validar todos los campos.


El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas.

Tabla 2.20 Caso de Prueba de Aceptación “Prueba Inserción de Producto” Elaborado por los autores



Nombre de Caso de Prueba: Prueba Búsqueda de Producto

Descripción: Se procede a la búsqueda de un producto según el tipo de producto al que pertenece, su referencia o su nombre y se verifica que se muestre el producto seleccionado.

Condiciones de Ejecución: Que el producto que se desea encontrar se encuentre registrado en la lista de productos.


1. Acceder a la interface “Productos”.

2. Hacer clic en la lupa de la sección Buscar Producto.

3. Escoger uno o varios criterios de búsqueda en este caso: Tipo de Producto, Referencia o Nombre.

4. Clic en “Buscar” y escoger el producto seleccionado.

5. Dar clic en “Buscar”.

Resultado esperado: Que se muestre el producto buscado.

Resultado obtenido: Se mostró el producto seleccionado.

Acciones correctivas: Ninguna



Tabla 2.21 Caso de Prueba de Aceptación “Prueba Búsqueda de Producto” Elaborado por los autores

73



Nombre de Caso de Prueba: Prueba Modificación de Producto

Descripción: Se procede a modificar uno o varios de los siguientes datos de un producto existente: Referencia, Nombre, Marca, Stock, Stock mínimo, Fecha de ingreso, Observaciones, Precio de compra, Precio de almacén, Precio de Tienda, PVP, precio con IVA. Y los siguientes datos: Tipo de producto, Proveedor 1, Proveedor 2 y Aviso mínimo; se modifican escogiendo los datos mostrados en el combo de la interface y verificar que se realicen los cambios en la Base de Datos.

Condiciones de Ejecución: Que el producto a modificarse esté registrado en la lista de productos.


1. Acceder a la interface “Productos”.

2. Señalar el producto que se desea modificar.

3. Modificar uno o varios de los datos descritos anteriormente. Estas modificaciones se ingresaron con datos erróneos.





Resultado obtenido: El sistema validó algunos campos pero no todos

Acciones Correctivas: Validar todos los campos.


El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas correspondientes.

Tabla 2.22 Caso de Prueba de Aceptación “Prueba Modificación de Producto” Elaborado por los autores

2.5.3 PRUEBAS GESTIÓN DE FACTURACIÓN

En esta sección se detallan las siguientes pruebas:

· Pruebas de inserción de Facturas de Clientes.

74

· Pruebas de búsqueda de Facturas de Clientes.

· Pruebas de modificación de Facturas de Clientes.

· Pruebas de visualización de Facturas de Clientes.

· Pruebas de inserción de Factura de Proveedores.


Código: 11 Historia de (Nro. y Nombre): 4 Generación de Facturas

Nombre de Caso de Prueba: Prueba Inserción de Factura

Descripción: Se procede a escoger o ingresar un nuevo cliente, luego se inserta el número de factura, luego se agrega uno o varios productos registrados y se verifica que se almacene la información en la Base de Datos.

Condiciones de Ejecución: Ingresar el Núm. de Factura, que los productos que se vayan a agregar estén previamente registrados en el sistema.


1. Acceder a la interface “Insertar Factura”.

2. Agregar un cliente.

2.1 Nuevo Cliente: Se ingresan estos datos: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico y clic en “Aceptar”. Se ingresaron datos erróneos.

2.2 Cliente Registrado: Se hace clic en la lupa, y se escoge uno de los clientes mostrados.

3. Se ingresa el Número de la Factura.

4. Se agrega un producto haciendo clic en la lupa.

5. Se busca y escoge el producto que se desea vender.

6. Se ingresa la cantidad de productos vendidos.

7. Si se realiza un descuento ingresarlo en el campo “Dcto”.

8. Dar clic en “Agregar”.


Resultado esperado: El ingreso de la nueva factura.

Resultado obtenido: Se ingresó la nueva factura con datos erróneos.

Acciones correctivas: Se validaron todos los campos del formulario.

75



Tabla 2.23 Caso de Prueba de Aceptación “Prueba Inserción de Factura” Elaborado por los autores



Nombre de Caso de Prueba: Prueba Búsqueda de Factura

Descripción: Se procede a la búsqueda de una factura según los siguientes criterios: el Estado (se refiere a pagada o sin pagar), el Número de Factura, el cliente y se verifica que se muestre la factura seleccionada.

Condiciones de Ejecución: Que la factura que se desea encontrar se encuentre registrada en el sistema.


1. Acceder a la interface “Facturas”.

2. Hacer clic en la lupa de la sección CI/RUC de cliente.

3. Escoger el cliente deseado e ir al paso 6.

4. Insertar el Número de Factura e ir al paso 6.

5. Escoger el Estado de Factura e ir al paso 6.

6. Dar clic en “Buscar”

Resultado esperado: Que se muestre la factura buscada.

Resultado obtenido: Se mostró la factura buscada.




Tabla 2.24 Caso de Prueba de Aceptación “Prueba Búsqueda de Factura” Elaborado por los autores

76



Nombre de Caso de Prueba: Prueba Modificación de Factura

Descripción: Se procede a modificar uno o varios de los siguientes datos existentes: Ciudad, Fecha, Código de Factura. Se puede modificar el cliente ingresando uno nuevo o añadiendo otro existente. Se pueden agregar nuevos productos existentes en el sistema, se pueden eliminar los productos ya agregados en la factura y se verifica que se realicen los cambios en la Base de Datos.

Condiciones de Ejecución: Que la factura esté en estado Sin pagar.



2. Señalar la factura que se desea modificar.

3. Modificar uno o varios de los datos descritos anteriormente. Al modificar los datos éstos fueron erróneos.





Resultado obtenido: El sistema permitió que algunos campos modificados se ingresen con datos erróneos.

Acciones correctivas: Validar todos los campos del formulario.


El sistema no mostró el resultado esperado pero se ejecutaron las respectivas acciones correctivas.

Tabla 2.25 Caso de Prueba de Aceptación “Prueba Modificación de Factura” Elaborado por los autores

77



Nombre de Caso de Prueba: Prueba Visualización de Factura

Descripción: Se procede a visualizar una Factura con todos sus datos: CI/RUC del cliente, Nombre del Cliente, Número de Factura, Ciudad Fecha y el detalle de los productos de la factura.

Condiciones de Ejecución: Que la factura esté registrada en el Sistema.



2. Señalar el la factura que se desea visualizar.

3. Hacer clic en la lupa “Visualizar”.

4. Se muestran los datos de la factura.


Resultado esperado: El despliegue de datos de la Factura seleccionada.

Resultado obtenido: Se visualizó la factura seleccionada.




Tabla 2.26 Caso de Prueba de Aceptación “Prueba Visualización de Factura” Elaborado por los autores


Código: 15 Historia de (Nro. y Nombre): 5 Gestión de Facturas de Proveedores

Nombre de Caso de Prueba: Prueba Inserción de Factura de Proveedor

Descripción: Se procede a escoger un proveedor, luego se copia el código de la factura, se inserta el número de teléfono del proveedor, la fecha de compra, luego se agrega uno o varios productos que hayan sido vendidos a la empresa por el proveedor ingresado previamente, y se verifica que se almacene la información en la Base de Datos.

Condiciones de Ejecución: que el proveedor esté registrado en el sistema, solo se pueden agregar productos del proveedor ingresado en la misma factura.

78


1. Acceder a la interface “Insertar Factura”.

2. Agregar un Proveedor registrado.

3. Se hace clic en la lupa, y se escoge uno de los proveedores registrados.

4. Se ingresa el Código de la factura.

5. Se agrega la Fecha de la factura.

6. Se agrega el teléfono del proveedor.

7. Se agrega un producto haciendo clic en la lupa.

8. Se escoge el producto adquirido.

9. Se ingresa la cantidad de productos del proveedor.

10. Si existe descuento por parte del proveedor ingresarlo en el campo “Dcto”.

11. Dar clic en “Agregar”.

12. Si se agrega un nuevo producto regresar al paso 7 caso contrario seguir con el paso 13.


Resultado esperado: El ingreso de la nueva factura

Resultado obtenido: Se ingresó una nueva factura




Tabla 2.27 Caso de Prueba de Aceptación “Prueba Inserción de Factura de Proveedor” Elaborado por los autores

79

CAPÍTULO 3: SEGUNDA ITERACIÓN DEL SISTEMA

Al iniciar la segunda iteración del sistema es necesario realizar una reunión para

revisar el sprint anterior, hacer la retrospectiva del sprint para actualizar la pila del

producto y empezar con la nueva iteración del sistema; todo este proceso se

describe a continuación.

3.1 REVISIÓN DE LA DOCUMENTACIÓN ANTERIOR

3.1.1 REVISIÓN DEL SPRINT ANTERIOR

Para llevar a cabo la revisión del sprint, se efectúo una reunión entre el equipo de

desarrollo y el cliente donde se inspeccionó el producto de software. El cliente

hizo las siguientes observaciones:

· Cambiar el formato de los formularios de ingreso de proveedores y clientes.

· Cambiar datos del formato en la presentación de reportes.

El grupo desarrollador ha tomado en cuenta estas observaciones.

En esta reunión se entregó un prototipo del sistema al cliente que incorporó las

interfaces desarrolladas, las mismas que se muestran de la sección 2.4.2 a la

sección 2.4.4, que fue construido de manera ordenada siguiendo lo acordado y

planificado en el sprint dentro del tiempo propuesto, fue aprobado y de buena

aceptación por parte del cliente, en el Anexo 3 se encuentra el acta de entrega.

En esta reunión también se definieron nuevas historias de usuario, que se

muestran desde la Tabla 3.1 hasta la Tabla 3.6, para actualizar la pila de

producto, tomando en cuenta el formato explicado en la sección 2.1.2.

Historia de Usuario


Nombre historia: Cobros



80


Descripción:

Como vendedor quiero buscar información referente a las facturas emitidas a mis clientes y poder visualizar: el número de factura, el nombre del cliente, el monto que queda pendiente por cobrar y la fecha que se realiza el cobro.


- Se va a visualizar el Estado de la factura que puede ser “pagada” o “sin pagar”.

- Se pueden registrar: los cobros pendientes, la fecha en la que se realizó el cobro y la forma de pago.

Tabla 3.1 Historia de Usuario “Cobros” Elaborado por los autores

Historia de Usuario


Nombre historia: Pagos




Descripción:

Como almacenista quiero buscar información referente a las facturas registradas de mis proveedores y poder visualizar: el número de factura, el nombre del proveedor, el monto que queda pendiente por pagar y la fecha que se realiza el pago.


- Se va a visualizar el Estado de la factura que puede ser “pagada” o “sin pagar”.

- Se pueden registrar: los pagos pendientes, la fecha en la que se realizó el pago y la forma de pago.

Tabla 3.2 Historia de Usuario “Pagos” Elaborado por los autores

81

Historia de Usuario


Nombre historia: Caja Diaria




Descripción:

Como administrador quiero buscar por fecha detalles del cierre de caja, como: el valor neto, el valor del iva, el total al contado y poder imprimir los resultados.


Ninguna.

Tabla 3.3 Historia de Usuario “Caja Diaria” Elaborado por los autores

Historia de Usuario


Nombre historia: Libro Diario




Descripción:

Como administrador quiero buscar por un período determinado de tiempo las ventas y compras efectuadas y que se muestre: la fecha, si es compra o si es venta, el número de la factura, el nombre del agente comercial, la forma de pago y el valor de la venta o compra.


Ninguna.

Tabla 3.4 Historia de Usuario “Libro Diario” Elaborado por los autores

82

Historia de Usuario


Nombre historia: Respaldo de Información




Descripción:

Como administrador quiero realizar copias de seguridad de toda la información que gestiono, para luego poder restaurarla.


- No se podrá cambiar la fecha y hora en la que se cree una copia de seguridad. Tabla 3.5 Historia de Usuario “Respaldo de Información”


Definidas las nuevas historias de usuario se procedió a actualizar la pila de

producto, agregando dos módulos: el Módulo de Reportes con su ID R y el

Módulo de Respaldos con su ID RE. La pila quedó como se muestra en la Tabla

3.6.

N Módulo ID Prioridad Nombre Descripción

1 Facturación F1 5 Gestión de Clientes

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de clientes.

2 Inventario I1 5 Gestión de proveedores

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de proveedores.

3 Inventario I2 4 Gestión de tipos de productos y productos

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de tipos de producto y productos

4 Facturación F2 4 Generación de Se realiza el ingreso, búsqueda, modificación,

83

facturas. visualización y eliminación de facturas de los clientes

5 Inventario I3 3 Gestión de facturas de los proveedores

Se realiza el ingreso, búsqueda, modificación, visualización y eliminación de facturas de los proveedores.

6 Facturación F3 3 Cobros Se despliega los cobros realizados a los clientes, los mismos que se pueden modificar.

7 Inventario I4 3 Pagos Se despliega los pagos realizados a los proveedores, los mismos que se pueden modificar.

8 Reportes R1 2 Caja Diaria Se despliega información de las ventas realizadas en un período de tiempo determinado.

9 Reportes R2 2 Libro Diario Se despliega información de las compras y ventas en un período de tiempo determinado.

10 Respaldos RE1 1 Respaldo de Información

Se ejecuta una copia de seguridad el momento que se requiera, para luego ser restaurada.

11 Publicidad P1 1 Creación de página web informativa

Se realiza la construcción del sitio web de la Empresa con fines publicitarios.

Tabla 3.6 Product Backlog de la versión 2.0 Elaborado por los autores

La reunión para la revisión del sprint anterior fue llevada a cabo de manera rápida

y sin demoras, dando así la pauta para empezar la retrospectiva del sprint.

3.1.2 REUNIÓN DE RETROSPECTIVA DEL SPRINT

Aclarado el concepto y motivo de esta reunión, se la dividió en tres puntos bien

definidos y estructurados, que fueron los siguientes:

84

· Exposición del resultado al implementar las historias de usuario:

En este caso se completaron todas las historias, y se analizaron y

corrigieron los errores.

· Análisis de las tareas en las historias de usuario:

Aquí se determinó que el tiempo de ejecución superó al estimado, ya que

se extendieron las tareas de Diseño de Base de Datos y Revisión del

último requerimiento; estas demoras causaron que el sprint se extendiera

un día más de lo planificado.

Los problemas encontrados fueron:

o La subestimación de tiempo al momento de planificar el diseño de la

base de datos; en la realidad tomó más tiempo diseñar la Base del

que se planificó.

o Se detectaron varios retrasos al término de algunas tareas, ya que

los desarrolladores dedicaron cuatro horas por día al proyecto y no

las seis disponibles.

Todos estos problemas se van a tomar en cuenta al momento de iniciar el

nuevo sprint para que no sucedan de nuevo.

· En tercer lugar se realizó una valoración del Sprint:

Aquí se destacaron los siguientes aspectos positivos:

o Se desarrollaron todas las historias de usuario planteadas en el

sprint.

o Se corrigieron los errores detectados en los casos de prueba.

o Se llevaron a cabo todas las revisiones de los requerimientos.

o Se aprendieron nuevas técnicas de programación gracias a la

investigación.

También se encontraron puntos negativos:

o No se pudieron llevar a cabo todas las reuniones del DailyScrum por

motivos laborales de los desarrolladores, pero que fueron

recompensados los fines de semana.

85

o Hubo algo de dificultad en las reuniones con el cliente ya que no

contaba con el tiempo disponible necesario para que las mismas se

lleven a cabo.

Para mejorar el sprint se pueden corregir los aspectos negativos que

afortunadamente no influyeron en el desarrollo del sprint.

3.1.3 PILA DE ENTREGA Y GRÁFICA DE TRABAJO RESTANTE

Para elaborar la Pila de entrega que se muestra en la Tabla 3.7, se han tomado

muy en cuenta las actualizaciones que se hicieron a la pila de producto, descritas

en la revisión del sprint, agregándose las nuevas historias de usuario obtenidas.

Estimación de Esfuerzo nueva

Lo que queda de los Sprints

Item Prioridad Estimación del valor

Estimación de esfuerzo

inicial

1 2

Gestión de Clientes 5 3 48 48 0 Gestión de proveedores

5 3 18 18 0

Gestión de tipos de productos y productos

4 5 27 27 0

Generación de facturas.

4 5 32 32 0

Gestión de facturas de los proveedores

3 4 18 18 0

Cobros 3 4 14 11 11 Pagos 3 4 14 11 11 Caja Diaria 2 3 8 5 5 Libro Diario 2 3 8 5 5 Respaldo de Información

1 2 6 10 10

Creación de página web informativa

1 5 24 31 31

Total 216 216 73 Tabla 3.7 Pila de Entrega Elaborado por los autores

86

Además se incluye una gráfica del Trabajo Restante que se muestra en la Figura

3.1 en donde se expone el avance del proyecto y lo que falta por terminar. Es

análoga a la gráfica del burn down chart pero a nivel más alto (requisitos) en vez

de tareas específicas.

Figura 3.1 Gráfica de Trabajo restante de la entrega


Una vez establecidos esta pila de entrega y el gráfico de trabajo restante se

puede proseguir con la planificación del siguiente sprint.

3.2 PLANIFICACIÓN DEL SEGUNDO SPRINT

Para planificar el segundo sprint se llevó a cabo la reunión “Sprint Planning

Meeting” descrita en la sección 1.3.1.3.2, donde se planificó un estimado de horas

disponibles de trabajo propuesta por los integrantes del equipo, donde cada uno

se comprometió a trabajar en ese tiempo. El resultado se puede ver detallado en

la Tabla 3.8.

87

Longitud del Sprint 13 Días estimados

Días laborables durante el Sprint De lunes a viernes y feriados

Miembros del Equipo

Días disponibles durante el sprint

Horas disponibles al día

Total horas disponibles

Eleana Jerez 13 6 78 Andrés Tello 13 6 78 Raúl Córdova 7 2 14

Tabla 3.8 Estimado Horas disponibles. Elaborado por los autores

Después de haber determinado el tiempo disponible, el grupo de desarrollo dividió

las tareas que va a realizar cada miembro del equipo y el estimado inicial de

horas de trabajo dedicadas a realizar cada tarea. Esta información se guarda en

la Pila del Sprint, detallada en la Tabla 3.9.

Tareas del Sprint Voluntario Esfuerzo estimado inicial (horas)

Cobros

Buscar movimientos Andrés 3

Ver cobros Andrés 2

Insertar cobro Andrés 4

Revisión Raúl 2

Pagos


Ver pagos Eleana 2

Insertar pago Eleana 4

Revisión Raúl 2

Caja Diaria

Buscar detalles de cierre de caja Andrés 2

Imprimir detalles de cierra de caja Andrés 1

88

Revisión Raúl 2

Libro Diario


Imprimir movimientos Andrés 1

Revisión Raúl 2

Respaldo de Información

Crear copia Andrés 2

Buscar copia Andrés 2

Restaurar copia Andrés 2

Eliminar copia Andrés 2

Revisión Raúl 2

Creación de página web informativa

Instalación de joomla Eleana 1

Diseño del sitio web Eleana 15

Instalación de plantilla Eleana 1

Creación de contenidos Eleana 4

Creación de menús Eleana 2

Creación de módulos Eleana 6

Revisión Raúl 2

Total 73

Tabla 3.9 Pila del sprint inicial Elaborado por los autores

3.3 AVANCE DIARIO DEL SPRINT

Una vez empezado el Sprint, se llevaron a cabo reuniones diarias claves en

Scrum, en la ejecución de las mismas no se presentaron mayores problemas y se

llevaron a cabo con normalidad.

89

Para detallar la información del avance diario del desarrollo del sistema se

especificó el objetivo del sprint que se visualiza en la Tabla 3.10 y el sprint

backlog detallado en la Figura 3.2.

SPRINT 2

OBJETIVO

Desarrollar las gestiones de cobros, pagos, reportes y página web informativa.

Tabla 3.10 Objetivo del sprint Elaborado por los autores

Después de esta actualización, se suman las horas restantes del equipo en total,

y se calcula el gráfico del burn down chart. Esta gráfica muestra cada día una

nueva estimación de cuanto trabajo queda (medido en personas-hora) para

terminar las tareas del equipo, detallada en la Figura 3.3.

Figura 3.3 Burn down chart


90

F

igu

ra 3

.2 S

pri

nt

bac

klo

g c

om

ple

to

Ela

bora

do p

or lo

s au

tore

s

91

3.4 ELABORACIÓN DE LA VERSIÓN 2.0 DEL SISTEMA

En este segundo sprint se concluirá con la elaboración del sistema, la

construcción de sus interfaces se detallan a continuación, por motivos de diseño

se ha definido las siguientes interfaces:

· Gestión de Cobros y Pagos.

· Reportes.

· Copias Seguridad.

A continuación se exponen las interfaces más relevantes del sistema LendaSoft

con sus respectivas opciones y operaciones.

3.4.1 GESTIÓN DE COBROS Y PAGOS

La interface de Gestión de Cobros y Pagos se visualiza en la Figura 3.4 y está

conformada por las opciones de Cobros y Pagos, las que permitirán conectarse al

sistema a través de la capa de aplicación. En donde se realizarán las

operaciones de: búsqueda y visualización de movimientos; también la agregación

y modificación de los cobros y pagos en la capa de datos. Estas interfaces

corresponden a las Historias de Usuario 7 y 8 expuestas en la sección 3.1.1 en

donde se realizó la revisión del sprint anterior.

Figura 3.4 Selección del menú Gestión de Cobros y Pagos


92

3.4.1.1 Cobros

En esta sección se detalla como se desarrolló la opción de Cobros en el sistema,



5.4.1.1.1 Buscar Movimientos

Para acceder a la interface de Buscar Movimientos que se presenta en la Figura

3.5, se procede a seleccionar el menú Gestión de Cobros y Pagos, el sub menú

Cobros. Se puede buscar por: CI/RUC del cliente, nombre del cliente, estados de

factura y período de fechas.

Figura 3.5 Interface Buscar Movimientos Cobros


El código que permite la búsqueda de los datos de los cobros en la base de datos

se visualiza en la Figura 3.6.

93

Figura 3.6 Código Buscar Movimientos Cobros


5.4.1.1.2 Ver cobros

Para acceder a la interface de Ver Cobros que se presenta en la Figura 3.7, se

procede a seleccionar el menú Gestión de Cobros y Pagos, la opción Cobros. Y

en la lista que se presenta de Movimientos escoger el que se desea visualizar con

clic en el botón Ver Cobros.

Figura 3.7 Interface Ver Cobros


94

El código que permite extraer esta información desde la base de datos se muestra

en la Figura 3.8.

Figura 3.8 Código Ver Cobros


5.4.1.1.3 Insertar Cobro

En la interfaz de la sección anterior se inserta el nuevo cobro llenando primero los

datos del formulario y clic en el botón Nuevo cobro como indica la Figura 3.9,

luego se puede observar en la rejilla cobros que se agregó uno nuevo.

Figura 3.9 Interface Insertar Cobro


95

El código que permite la inserción de los datos de los nuevos cobros en la base

de datos se presenta en la Figura 3.10.

Figura 3.10 Código Insertar Cobro


3.4.1.2 Pagos

En esta sección se detalla como se desarrolló la opción de Pagos en el sistema,




Para acceder a la interface de Buscar Movimientos que se presenta en la Figura

3.11, se procede a seleccionar el menú Gestión de Cobros y Pagos, la opción

Pagos. Se puede buscar por: CI/RUC del proveedor, nombre del proveedor,

estados de factura y período de fechas.

Figura 3.11 Interface Buscar Movimientos Pagos


96

El código que permite la búsqueda de la información de movimientos de los pagos

en la base de datos se presenta en la Figura 3.12.

Figura 3.12 Código Buscar Movimientos Pagos


5.4.1.2.2 Ver pagos

Para acceder a la interface de Ver Pagos que se presenta en la Figura 3.13, se

procede a seleccionar el menú Gestión de Cobros y Pagos, la opción Pagos. Y

seleccionar el pago que se desea visualizar con clic en el botón Ver Pagos.

Figura 3.13 Interface Ver Pagos


97

El código que permite extraer esta información desde la base de datos se muestra

en la Figura 3.14.

Figura 3.14 Código Ver Pagos


5.4.1.2.3 Insertar pago

En la interfaz de la sección anterior se inserta el nuevo pago llenando primero los

datos del formulario y clic en el botón Nuevo pago como indica la Figura 3.15,

luego se puede observar en la rejilla pagos que se agregó uno nuevo.

Figura 3.15 Interface Insertar Pago


98

El código que permite ingresar el nuevo pago a la base de datos se muestra en la

Figura 3.16.

Figura 3.16 Código Insertar Pago


3.4.2 REPORTES

La interface de Reportes que se visualiza en la Figura 3.17 está conformada por

las opciones Caja Diaria y Libro Diario, las que permitirán conectarse al sistema

por medio de la capa de aplicación. En donde se puede realizar las operaciones

de búsqueda de movimientos en la capa de datos, e impresiones de los reportes.

Estas interfaces corresponden a la Historia de Usuario 9 y 10.

Figura 3.17 Selección del menú Reportes


3.4.2.1 Caja Diaria

En esta sección se expone como se desarrolló la opción de Caja Diaria en el



99

3.4.2.1.1 Buscar Detalles de Cierre de Caja

Para acceder a la interface Detalles Cierre Caja que se observa en la Figura 3.18,

se procede a seleccionar el menú Reportes, la opción Caja Diaria, donde

automáticamente se genera el cierre de caja de la fecha actual, pero se puede

cambiar de fecha y buscar detalles del cierre de caja para esa fecha, haciendo clic

en el botón buscar.

Figura 3.18 Interface Detalles Cierre Caja


El código que permite consultar la información del cierre de caja en la base de

datos se muestra en la Figura 3.19.

Figura 3.19 Código Detalles Cierre Caja


3.4.2.1.2 Imprimir Detalles de Cierre de Caja

Para acceder a la interface para imprimir Detalles Cierre Caja que se observa en

la Figura 3.20, se procede a seleccionar el menú Reportes, la opción Caja Diaria y

clic en el botón Imprimir y luego en el botón Aceptar.

100

Figura 3.20 Interface Imprimir Detalles Cierre Caja


El código que permite imprimir la información del cierre de caja se muestra en la

Figura 3.21

Figura 3.21 Código Imprimir Detalles Cierre Caja


3.4.2.2 Libro Diario

En esta sección se expone como se desarrolló la opción de Libro Diario en el




Para acceder a la interface Buscar Movimientos que se observa en la Figura 3.22,

se procede a seleccionar el menú Reportes, la opción Libro Diario donde se

buscan los movimientos por periodo de fechas y clic en el botón Buscar.

101

Figura 3.22 Interface Buscar Movimientos Libro Diario


El código que permite la búsqueda de datos del Libro Diario en la base de datos


Figura 3.23 Código Buscar Movimientos Libro Diario


3.4.2.2.2 Imprimir Movimientos

Para acceder a la interface para imprimir Movimientos de Libro Diario que se

observa en la Figura 3.24, se procede a seleccionar el menú Reportes, la opción

Caja Diaria y clic en el botón Imprimir que se encuentra al final del reporte de libro

diario y luego en el botón Aceptar.

102

Figura 3.24 Interface Imprimir Movimientos Libro Diario


El código que permite imprimir la información del Libro Diario se muestra en la

Figura 3.25.

Figura 3.25 Código Imprimir Movimientos Libro Diario


3.4.3 COPIAS SEGURIDAD

La interface de Copias Seguridad que se visualiza en la Figura 3.26 está

conformada por las opciones Hacer copia y Restaurar copia, las que permitirán

conectarse al sistema por medio de la capa de aplicación. En donde se puede

realizar las operaciones para crear, buscar, restaurar y eliminar copias de

seguridad, en la capa de datos. Estas interfaces corresponden a la Historia de

Usuario 11.

103

Figura 3.26 Selección del menú Copia Seguridad


3.4.3.1 Hacer copia

En esta sección se expone como se desarrolló la opción Hacer copia en el



3.4.3.1.1 Crear Copia de Seguridad

Para acceder a la interface Crear Copia de Seguridad que se observa en la Figura

3.27, se procede a seleccionar el menú Copias Seguridad, la opción Hacer copia

donde se llenan los datos del formulario y se hace clic en el botón Nueva copia

de seguridad.

Figura 3.27 Interface Crear Copia de Seguridad


104

Podemos observar que la copia de seguridad ha sido creada exitosamente como

se visualiza en la Figura 3.28.

Figura 3.28 Interface Nueva Copia de Seguridad


El código que permite la creación de la copia de seguridad se muestra en la

Figura 3.29

Figura 3.29 Código Crear Copia de Seguridad


3.4.3.2 Restaurar copia

En esta sección se expone como se desarrolló la opción Restaurar copia en el



105

3.4.3.2.1 Buscar Copias de Seguridad

Para acceder a la interface Buscar Copias de Seguridad que se observa en la

Figura 3.30, se procede a seleccionar el menú Copias Seguridad, la opción menú

Restaurar copia donde se puede buscar las copias de seguridad por un periodo

determinado de fechas o por el nombre de la copia de seguridad y se hace clic en

el botón Buscar.

Figura 3.30 Interface Buscar Copias de Seguridad


El código que permite la búsqueda de la copia de seguridad en la base de datos

se muestra en la Figura 3.31

Figura 3.31 Código Buscar Copias de Seguridad


106

3.4.3.2.2 Restaurar Copia de Seguridad

En la misma interface anterior descrita en la sección 3.4.3.2.1, una vez

encontrada la copia requerida, simplemente se hace clic en el botón Restaurar y

se ejecuta la restauración como se observa en la Figura 3.32.

Figura 3.32 Interface Copia de Seguridad Restaurada


El código que permite la restauración de la copia de seguridad se muestra en la

Figura 3.33.

Figura 3.33 Código Restaurar Copia de Seguridad


107

3.4.3.2.3 Eliminar Copia de Seguridad

En la misma interfaz descrita en la sección 3.4.3.2.1, una vez encontrada la copia

requerida, simplemente se hace clic en el botón Eliminar y se ejecuta la

eliminación de la copia de seguridad seleccionada como se observa en la Figura

3.34.

Figura 3.34 Interface Eliminar Copia de Seguridad


El código que permite la eliminación de la copia de seguridad de la base de datos


Figura 3.35 Código Eliminar Copia de Seguridad


108

3.4.4 CREACIÓN DE PÁGINA WEB INFORMATIVA

Para llevar a cabo la creación de la página web informativa para la Empresa, se

realizaron las tareas que se exponen desde la sección 3.4.4.1 hasta la sección

3.4.4.6.

3.4.4.1 Instalación de Joomla

Se instaló Joomla 2.5.0; en la Figura 3.36 se expone la pantalla final que muestra

una instalación exitosa del proceso que conlleva algunos pasos, el detalle

completo de la instalación se encuentra en el Anexo 4.

Figura 3.36 Instalación de Joomla 2.5.0 “Pantalla Final”


109

3.4.4.2 Diseño del sitio web

El sitio web se diseñó en base a los requerimientos proporcionados por la

Empresa descritos en la sección 1.4.1 en donde se realizó la justificación del

CMS; para esto se procedió a seleccionar una plantilla que se acople a las

necesidades de la Empresa, tomando en cuenta la distribución de la información y

la presentación de imágenes, se escogió a la plantilla Karinpi, un ejemplo de la

página de inicio de la plantilla se muestra en la Figura 3.37.

Figura 3.37 Plantilla Karinpi “Ejemplo página de inicio”


110

El personal de la empresa en conjunto con el equipo de desarrollo organizó la

información que se debe presentar, para esto se utilizó las posiciones de la

plantilla que se muestran en la Figura 3.38.

Figura 3.38 Plantilla Karinpi “Posiciones”


111

De acuerdo a las posiciones de la plantilla se definieron los siguientes módulos,

en los cuales se distribuyó la información como se muestra en la Tabla 3.12.

Posición Tipo de Módulo Información

Logo HTML personalizado Logo de la empresa.

Search Buscar Buscador del sitio web.

Mainmenu Menú Inicio, Quiénes somos, Tipos de producto,

Rastreo Satelital y Contacto.

Slide Show Slide Show Visor de imágenes de tipos de producto,

servicios y promociones que ofrece la

empresa.

Right HTML personalizado Imagen de rastreo satelital.

Right Showplus Catálogo de productos.

Login Datos de acceso Inicio de sesión al sitio web.

Login Vinaora Visitors Counter Contador de visitas.

Left HTML personalizado Imagen de cajas acústicas.

News HTML personalizado Imagen de alarma inteligente.

User 4 HTML personalizado Información e imagen de audio y video.

User 5 HTML personalizado Información e imagen de iluminación.

User 6 HTML personalizado Información e imagen de autolujos.

User 7 HTML personalizado Información e imagen de seguridad.

User 8 HTML personalizado Información e imagen de servicio técnico.

Copyright HTML personalizado Información de Copyright.

Tabla 3.12 Posiciones y distribución de información en la plantilla


112

3.4.4.3 Instalación de plantilla

Se procedió a instalar la plantilla y se obtuvo un mensaje de instalación exitosa

que se presenta en la Figura 3.39. El proceso completo se muestra en el Anexo 4.

Figura 3.39 Instalación de la plantilla Karinpi “Pantalla Final”


3.4.4.4 Creación de contenidos

Los contenidos del sitio web se elaboraron en base a la información

proporcionada por el personal de la empresa, en la Tabla 3.13 se muestran los

contenidos creados. En el Anexo 4 se encuentra el proceso completo de creación

de contenidos.

113

Categoría Artículos

Quiénes somos Historia, Misión, Objetivos, Plan estratégico, Quiénes somos y Visión

Inicio Inicio

Tipos de Producto Audio y Video, Autolujos, Iluminación, Seguridad y Servicio Técnico.

Estructura Organizacional Estructura Organizacional

Catálogo de productos Audio y Video logos, Boss, Bunker, Catálogo de productos, Genius, Iluminación, JVC, Kenwood, Nemesis, Pioner y Seguridad logos.

Rastreo Satelital Rastreo Satelital, Software de escritorio, Página web y Web celular.

Tabla 3.13 Categorías y Artículos del sitio web


3.4.4.5 Creación de menús

En la Tabla 3.14 se muestra los menús con sus niveles, creados en el sitio web y

su respectivo tipo de elemento de menú. En el Anexo 4 se expone el proceso

completo de la creación de menús.

11

4

Tab

la 3

.14

Men

ús

del

sit

io w

eb

Ela

bora

do p

or lo

s au

tore

s

115

3.4.4.6 Creación de módulos

Se crearon los módulos para cada una de las posiciones en la plantilla como se

indico en la Tabla 3.12, en donde se describe la información definida para cada

posición, en la Figura 3.40 se visualiza el resultado final de la página de inicio del

sitio web. La construcción de todos los módulos que conforman el sitio web se

expone en el Anexo 4.

Figura 3.40 Página de inicio del sitio web


116

3.5 PRUEBAS DE LA VERSIÓN 2.0 DEL SISTEMA

Los casos de prueba de Aceptación se han desarrollado en base a las historias de

usuario descritas en la sección 3.1.1, para comprobar la estabilidad y buen

funcionamiento del sistema. Los tipos de pruebas realizadas son de tipo beta,

es decir, hechas por el cliente en la empresa. Se realizaron pruebas de todas las

operaciones que puede hacer el sistema, pero se presentan las de más

relevancia. Los resultados de las pruebas están registrados desde laTabla 3.14

hasta la Tabla 3.23.

3.5.1 PRUEBAS DE GESTIÓN DE COBROS Y PAGOS

Las pruebas de la sección Gestión de Cobros y Pagos están conformadas por las

pruebas de gestión de Cobros y Pagos, correspondientes a las Historias de

usuario 7 y 8 respectivamente.

3.5.1.1 Pruebas de Cobros

En esta sección se detalla como se realizaron las siguientes pruebas de Cobros

del sistema:

· Pruebas de búsqueda de movimientos.

· Pruebas de inserción de cobros.

Caso de Prueba de Aceptación Código: 16 Historia de (Nro. y Nombre): 7 Cobros

Nombre de Caso de Prueba: Prueba búsqueda de movimientos de cobros

Descripción: Se procede a buscar los movimientos de los cobros por el CI/RUC o nombre del cliente, por estado de la factura o por un determinado período de tiempo.

Condiciones de Ejecución: Que el cliente esté registrado en el sistema, y que el cliente tenga registrada por lo menos una factura.


1. Acceder a la interface “Buscar Movimientos”.

2. Ingresar un nombre de un cliente en el campo correspondiente.

3. Ingresar Fecha de inicio.

4. Ingresar Fecha de fin.

5. Dar clic en el botón “Buscar”.

117

6. Se muestran los movimientos del cliente.

Resultado esperado: El despliegue de la pantalla de los movimientos del cliente.

Resultado Obtenido: El sistema no muestra todos los movimientos del cliente escogido.

Acciones Correctivas: Realizar las respectivas operaciones de conexión con la base de datos para que muestre los datos.


No se mostró el resultado esperado, pero se ejecutaron las respectivas acciones correctivas.

Tabla 3.14 Caso de Prueba de Aceptación “Prueba búsqueda de movimientos de cobros”


Caso de Prueba de Aceptación Código: 17 Historia de (Nro. y Nombre): 7 Cobros

Nombre de Caso de Prueba: Prueba de inserción de cobro

Descripción: Se procede a ingresar un nuevo cobro, dentro del cual se registra el monto y el tipo de pago, éste puede ser cheque, efectivo o tarjeta. Y que se actualice el saldo pendiente.

Condiciones de Ejecución: Que el estado de la factura sea “Sin Pagar”.


1. Acceder a la interface “Ver Cobros”.

2. Ingresar la cantidad del importe.

3. Ingresar la forma de pago.

4. Dar clic en el botón “Nuevo cobro”.

Resultado esperado: que se haya ingresado el ítem del nuevo cobro y actualizado el saldo pendiente.

Resultado Obtenido: El sistema no actualizó el saldo pendiente.

Acciones Correctivas: Validar que efectivamente se actualice el saldo pendiente, revisando el código fuente que permite realizar esta acción.



Tabla 3.15 Caso de Prueba de Aceptación “Prueba de inserción de cobro”


118

3.5.1.2 Pruebas de Pagos

En esta sección se detalla como se realizaron las siguientes pruebas de Pagos

del sistema:

· Pruebas de búsqueda de movimientos.

· Pruebas de inserción de pagos.


Código: 18 Historia de (Nro. y Nombre): 8 Pagos

Nombre de Caso de Prueba: Prueba buscar movimientos de pagos

Descripción: Se procede a buscar los movimientos de los pagos por el CI/RUC o nombre del proveedor, por estado de la factura o por un determinado período de tiempo.

Condiciones de Ejecución: Que el proveedor conste en el sistema y tenga registrada por lo menos una factura.


1. Acceder a la interface “Buscar Movimientos”.

2. Ingresar un nombre de un proveedor en el campo correspondiente.

3. Ingresar Fecha de inicio.

4. Ingresar Fecha de fin.


6. Se muestran los movimientos del proveedor.

Resultado esperado: El despliegue de la pantalla de los movimientos del proveedor.

Resultado obtenido: No se muestran todos los movimientos del proveedor.

Acciones Correctivas: Realizar las respectivas correcciones en el código fuente, correspondiente a la parte de movimientos del proveedor.


No se mostró el resultado esperado, pero se realizaron las acciones correctivas.

Tabla 3.16 Caso de Prueba de Aceptación “Prueba buscar movimientos de pagos”


119


Código: 19 Historia de (Nro. y Nombre): 8 Pagos

Nombre de Caso de Prueba: Prueba de inserción de pago

Descripción: Se procede a ingresar un nuevo pago, dentro del cual se registra el monto y el tipo de pago, éste puede ser cheque, efectivo o tarjeta. Y que se actualice el saldo pendiente.

Condiciones de Ejecución: Que el estado de la factura del proveedor sea “Sin Pagar”.


1. Acceder a la interface “Pagos”.

2. Ingresar la cantidad del importe.

3. Ingresar la forma de pago.

4. Dar clic en el botón “Nuevo pago”.

Resultado esperado: que se haya ingresado el ítem del nuevo pago y actualizado el saldo pendiente.

Resultado obtenido: El sistema no actualizó el saldo pendiente.

Acciones correctivas: Validar que efectivamente se actualice el saldo pendiente, revisando el código fuente que permite realizar esta acción.



Tabla 3.17 Caso de Prueba de Aceptación “Prueba de inserción de pago”


3.5.2 PRUEBAS DE REPORTES

Las pruebas de la sección de reportes están conformadas por las pruebas de

gestión de Caja Diaria y Libro Diario, correspondientes a las Historias de usuario 9

y 10 respectivamente. Aquí se describen las pruebas:

· Prueba de búsqueda de cierre de caja

· Prueba búsqueda de movimientos de libro diario

120


Código: 20 Historia de (Nro. y Nombre): 9 Caja Diaria

Nombre de Caso de Prueba: Prueba de búsqueda de cierre de caja.

Descripción: Se procede a ingresar la fecha en la que se quiere consultar el cierre de caja, luego se muestra el detalle.

Condiciones de Ejecución: Que existan movimientos en la fecha ingresada.


1. Acceder a la interface “Caja Diaria”.

2. Ingresar fecha de cierre.

3. Clic en el botón Buscar.

Resultado esperado: Que se muestre los detalles de cierre de caja para la fecha ingresada.

Resultado obtenido: El sistema mostró los detalles de cierre de caja en la fecha ingresada.



El sistema mostró el resultado esperado.

Tabla 3.18 Caso de Prueba de Aceptación “Prueba de búsqueda de cierre de caja”



Código: 21 Historia de (Nro. y Nombre): 10 Libro Diario

Nombre de Caso de Prueba: Prueba búsqueda de movimientos de libro diario

Descripción: Se procede a buscar los movimientos de ventas y compras que se realizaron en el sistema en un período determinado de tiempo.

Condiciones de Ejecución: Que existan movimientos en el período de tiempo determinado.


1. Acceder a la interface “Libro diario”.

121

2. Ingresar fecha de inicio.

3. Ingresar fecha de fin.

4. Clic en el botón Buscar.

Resultado esperado: Que se muestren las compras y ventas efectuadas en el periodo de tiempo ingresado.

Resultado obtenido: Se mostraron las compras y ventas efectuadas en el período de tiempo ingresado.




Tabla 3.19 Caso de Prueba de Aceptación “Prueba búsqueda de movimientos de libro diario”


3.5.3 PRUEBAS DE COPIAS DE SEGURIDAD

Las pruebas de la sección de Copias de Seguridad están conformadas por las

pruebas de creación y restauración de copias de seguridad, correspondientes a la

Historia de usuario 11. Aquí se describen las pruebas:

· Prueba de creación de copia de seguridad.

· Prueba de restauración de copia de seguridad.


Código: 22 Historia de (Nro. y Nombre): 11 Respaldo de la información

Nombre de Caso de Prueba: Prueba de creación de copia de seguridad

Descripción: Se procede a crear una nueva copia de seguridad.

Condiciones de Ejecución: Ninguna en particular.


1. Acceder a la interface “Crear copia de seguridad”.

2. Ingresar el nombre de la copia de seguridad.

3. Hacer clic en el botón “Nueva copia de seguridad”.

122

Resultado esperado: Que la copia de seguridad se haya creado correctamente.

Resultado obtenido: Se creó la copia y mostró el mensaje de creación exitosa.




Tabla 3.20 Caso de Prueba de Aceptación “Prueba de creación de copia de seguridad”



Código: 23 Historia de (Nro. y Nombre): 11 Respaldo de la información

Nombre de Caso de Prueba: Prueba de restauración de copia de seguridad

Descripción: Se procede a restaurar una copia creada anteriormente.

Condiciones de Ejecución: Que exista en el sistema la copia de seguridad que se va a restaurar.


1. Acceder a la interface “Buscar copias de seguridad”.

2. Ingresar fecha de inicio.

3. Ingresar fecha de fin.

4. Ingresar el nombre de la copia a restaurar.


6. Seleccionar la copia de seguridad a restaurar.

7. Dar clic en el botón “Restaurar”.

Resultado esperado: Que la copia de seguridad seleccionada sea restaurada.

Resultado obtenido: Se restauró la copia de seguridad y mostró el mensaje de restauración exitosa.




Tabla 3.21 Caso de Prueba de Aceptación “Prueba de restauración de copia de seguridad”


123

3.5.4 PRUEBAS DEL SITIO WEB

Se llevaron a cabo las siguientes pruebas, correspondientes a la Historia de

usuario 6.

· Prueba de visualización de datos de la empresa.

· Prueba de presentación de catálogo de productos.

· Prueba de visualización de información de contacto.

· Prueba de envío del formulario de contacto.

· Prueba de registro de usuarios.


Código: 24 Historia de (Nro. y Nombre): 6 Creación de página web informativa.

Nombre de Caso de Prueba: Prueba de visualización de datos de la empresa

Descripción: Se procede a verificar que la información del menú Quiénes somos se visualice en el sitio web.

Condiciones de Ejecución: Ingresar al sitio web


1. Hacer clic en el menú Quiénes somos.

2. Visualizar información mostrada.


4. Seleccionar el sub menú Historia.



7. Seleccionar sub menú Plan Estratégico.




11. Seleccionar la opción Misión.


124



15. Seleccionar la opción Visión.




19. Seleccionar la opción Objetivos.



22. Seleccionar sub menú Estructura Organizacional.


Resultado esperado: Que en todas las opciones se muestre la información requerida.

Resultado obtenido: El menú Quiénes somos, el sub menú Historia, el sub menú Plan estratégico mostraron información errónea

Acciones correctivas: Crear los artículos correspondientes y enlazar al menú y a los sub menús.


No se mostró el resultado esperado, pero se ejecutaron las acciones correctivas

Tabla 3.22 Caso de Prueba de Aceptación “Prueba de visualización de datos de la empresa”



Código: 25 Historia de (Nro. y Nombre): 6 Creación de página web informativa

Nombre de Caso de Prueba: Prueba de presentación de catálogo de productos

Descripción: Se procede a verificar que se visualicen imágenes de los productos que ofrece la empresa, así como información de los mismos.

Condiciones de Ejecución: Que esté creado el módulo de catálogo de productos


1. Visualizar el slide de los productos en el módulo Catálogo de productos.

125

2. Hacer clic en cualquier imagen del slide.

3. Hacer clic en el enlace de Seguridad.

4. Hacer clic en la imagen de cualquier marca.

5. Visualizar las imágenes de los productos.


7. Hacer clic en el enlace de Audio y Video.

8. Hacer clic en la imagen de cualquier marca.



11. Hacer clic en el enlace de Iluminación.



14. Hacer clic en el enlace de Autolujos.

15. Visualizar información de los productos.


17. Hacer clic en el enlace de Servicio Técnico.

18. Visualizar información de Servicio Técnico.

Resultado esperado: Que se visualice correctamente la información y las imágenes de los productos.

Resultado obtenido: Se visualizaron todas las imágenes e información de los productos.


Evaluación de la prueba: Buena.


Tabla 3.23 Caso de Prueba de Aceptación “Prueba de presentación de catálogo de productos”


126



Nombre de Caso de Prueba: Prueba de visualización de información de contacto

Descripción: Se procede a visualizar los datos de contacto de la empresa.

Condiciones de Ejecución: Que el enlace del menú Contacto esté activo.


1. Acceder al menú “Contacto”.

2. Visualizar la información.

Resultado esperado: Que se muestre la información de contacto de la empresa.

Resultado obtenido: Se mostró la información de contacto de la empresa.


Evaluación de la prueba: Buena.


Tabla 3.24 Caso de Prueba de Aceptación “Prueba de visualización de información de contacto”




Nombre de Caso de Prueba: Prueba de envío de formulario de contacto

Descripción: Se procede a llenar los datos del formulario para luego recibir la confirmación de envío de la información.

Condiciones de Ejecución: Que el enlace del menú Contacto esté activo. Y que se encuentre configurado correctamente el correo electrónico del servidor en Joomla.


1. Acceder al menú “Contacto” de la página de inicio.

2. Clic en el enlace Formulario de contacto.

3. Ingresar el nombre.

4. Ingresar el correo electrónico.

127

5. Ingresar un asunto.

6. Ingresar un mensaje.

7. Marcar el check Envíeme copia.

8. Dar clic en “Enviar”.

Resultado esperado: Que los datos se hayan registrado correctamente.

Resultado obtenido: No se recibió confirmación de que los datos se registraron correctamente.

Acciones Correctivas: Configurar correctamente el correo electrónico en Joomla.



Tabla 3.25 Caso de Prueba de Aceptación “Prueba de envío del formulario de contacto”




Nombre de Caso de Prueba: Prueba de registro de usuarios

Descripción: Se procede a verificar que el registro de usuarios en el sitio web se realice correctamente.

Condiciones de Ejecución: Que esté creado el módulo de Datos de acceso.


1. Clic en el enlace Crear una cuenta.

2. Ingresar Nombre

3. Ingresar usuario.

4. Ingresar contraseña.

5. Confirmar contraseña.

6. Ingresar dirección de correo electrónico.

7. Confirmar dirección de correo electrónico.

128

8. Clic en el botón Registrar.

9. Leer información acerca de la activación de la cuenta.

10. Ingresar a la cuenta de correo registrada.

11. Hacer clic en el link para activar la cuenta.

12. Ingresar usuario.

13. Ingresar contraseña.

14. Dar clic en botón Identificarse.

15. Visualizar mensaje Hola, usuario.

Resultado esperado: Que los datos se hayan registrado correctamente y que se inicie sesión con el usuario registrado.

Resultado obtenido: El usuario se registró e inició sesión correctamente.




Tabla 3.26 Caso de Prueba de Aceptación “Prueba de registro de usuarios”


3.6 ANÁLISIS DE RESULTADOS

Parte de este análisis es la implementación del sistema Lendasoft, que se llevó a

cabo según lo descrito en el Anexo 5.

Se concluyeron los dos sprints planificados, en el segundo sprint la línea del

gráfico down chart está por debajo del ideal, a diferencia del primero que está

sobre el ideal; esto quiere decir que el segundo sprint se concluyó antes de lo

planificado, lo cual es satisfactorio ya que se contó con más tiempo para realizar

tareas de afinamiento.

Existieron algunos problemas a lo largo del desarrollo, como la aplicación de las

acciones correctivas de los casos de prueba para corregir los errores encontrados

en el sistema LendaSoft y en el portal web; también en algunas tareas del primer

sprint se utilizó más tiempo del planificado; no se pudieron llevar a cabo todas las

reuniones diarias recomendadas por Scrum; sin embargo todos estos problemas

se solucionaron sin inconvenientes.

129

Se cumplieron con los objetivos de cada sprint y las estimaciones fueron buenas

de acuerdo a lo requerido por la empresa.

El sistema quedó implantado y funcionando en la Empresa, a la que le

corresponde completar el inventario de sus productos y luego registrarlos en el

sistema. El equipo de desarrollo realizó una entrega formal del sistema LendaSoft

y del portal Web, que quedó registrada en las actas de entrega que se encuentran

en los Anexos 3 y 6. Además se hizo una Entrevista de satisfacción de entrega

del sistema LendaSoft y portal Web al cliente, cuyo resultado fue de un 90% de

satisfacción. El detalle tanto de las preguntas realizadas y el análisis del

resultado se encuentran en el Anexo 7.

130

CAPÍTULO 4: CONCLUSIONES Y RECOMENDACIONES

4.1 CONCLUSIONES

· Se escogió Scrum como metodología principalmente por la compatibilidad

de sus características con las características del proyecto como se muestra

en la Tabla 1.1 y en base a los siguientes parámetros: planificación,

flexibilidad para cambios, análisis de requerimientos, documentación,

control del proyecto, comunicación interna entre los integrantes del equipo

de desarrollo y comunicación con el cliente.

· Durante el desarrollo del proyecto se logró comprobar que la

implementación y ejecución correcta de Scrum es un proceso minucioso,

donde los integrantes del equipo desarrollador tienen que cumplir con sus

responsabilidades y acrecentar sus habilidades, a través de la práctica

contínua, logrando así cumplir correctamente con sus roles.

· En las reuniones que se realizaron a lo largo del proyecto se brindó

especial atención a los cambios de requerimientos y a la necesidad de

feedback constante que surgían por parte del cliente, siendo estas

actividades claves para la obtención de un producto de software funcional

al terminar los sprints.

· En el momento en el que se realizó los casos de prueba alfa y beta se pudo

detectar fallas en el sistema que se lograron corregir antes de entregar el

producto final al cliente.

· La buena participación del Dueño del Producto, a pesar de su poca

disponibilidad de tiempo, y la comunicación que mantuvo con el equipo de

desarrollo, garantizó que en cada Sprint se trabajara sólo en aquellas

funcionalidades que realmente le interesaban, resolviendo necesidades

reales y evitando así la programación de código innecesario.

· Para el desarrollo de la aplicación web LendaSoft se utilizó Apache como

servidor Web, MySQL como base de datos y PHP como lenguaje de

programación, estas herramientas al ser de código abierto, fáciles de

instalar y del conocimiento del equipo de desarrollo hicieron que la

implementación del sistema sea rápida y que se puedan realizar las

pruebas necesarias en cada sprint para la obtención del producto final.

131

· Para la construcción del portal web se utilizó el sistema gestor de

contenidos Joomla es dinámico, personalizable y escalable, fácil de

aprender y de usar; además es un CMS de código abierto.

· La aplicación de la metodología Scrum en este proyecto fue la apropiada

ya que permitió:

o Gestionar cambios en los requerimientos del cliente por medio de la

actualización de la pila de producto.

o Administrar el control de ejecución y duración de tiempos, a diario,

de las tareas planificadas para cada sprint.

o Priorizar el orden de realización de las tareas según la necesidad del

cliente.

4.2 RECOMENDACIONES

· Para las empresas de desarrollo de software que experimenten por primera

vez con Scrum, se recomienda dar al equipo de desarrollo espacio y

herramientas para que se gestionen ellos mismos.

· Se recomienda a la Empresa Servicios y Lujos Only Cars SC. la compra de

un hosting y la mejora de sus equipos de HW, para poder subir el portal

web a internet.

· Para futuras mejoras del sistema LendaSoft, se recomienda agregar un

módulo de seguridad que permita el ingreso al sistema de nuevos usuarios.

· Para desarrollar proyectos con Scrum se recomienda el uso del CMS

Joomla para la construcción de sitios web gracias a su flexibilidad y fácil

manejo.

132

GLOSARIO

Artículo en Joomla.- Un "artículo" en Joomla es el apartado donde se introducirá

el contenido que se quiere publicar en la web.

Backlog del producto.- El Backlog del Producto (o "backlog") contiene los

requerimientos del sistema, expresados como una lista priorizada de elementos

del backlog del producto.

Backlog del sprint.- Define el trabajo de un sprint, representado por un conjunto

de tareas que deben completarse para cumplir los objetivos del sprint, y por un

conjunto de elementos seleccionados del backlog del producto.

Categoría en Joomla.- Es un contenedor o clasificador que permite organizar la

información del sitio web.

Elemento del backlog del producto.- En Scrum, un elemento del backlog del

producto ("PBI", "elemento del backlog", o "elemento") es una unidad de trabajo lo

suficientemente pequeña para que el equipo pueda completarla en un sprint

(iteración).

Entrega.- Una entrega es la transición de un incremento potencialmente

productivo del producto en algo que los clientes usen rutinariamente.

Esfuerzo para un elemento del backlog del producto.- Algunas personas

estiman es esfuerzo de los elementos del backlog del producto en días ideales,

aunque otras personas prefieren unidades de estimación menos concretas. Las

unidades alternativas pueden ser puntos de historia, puntos de función, o

"tamaños de remera" (1 para pequeño, 2 para medio, etc.).

Feedback.- Feedback o retroalimentación es un mecanismo mediante el cual la

información sobre la salida del sistema se vuelve a él convertida en una de sus

entradas, esto se logra a través de un mecanismo de comunicación de retorno, y

tiene como fin alterar de alguna manera el comportamiento del sistema.

Firefox.- Mozilla Firefox es un navegador de Internet libre y de código abierto

descendiente de Mozilla Aplication suite, desarrollado por la Corporación Mozilla,

la Fundación Mozilla y un gran número de voluntarios externos.

133

GPL.- La Licencia Pública General de GNU o más conocida por su nombre en

inglés GNU General Public License o simplemente sus siglas del inglés GNU

GPL, es una licencia creada por la Free Software Foundation en 1989 (la primera

versión), y está orientada principalmente a proteger la libre distribución,

modificación y uso de software.

GPRS.- (General Packet Radio Services) es una técnica de conmutación de

paquetes, que es integrable con la estructura actual de las redes GSM. Esta

tecnología permite una velocidad de datos de 115 kbs. Sus ventajas son

múltiples, y se aplican fundamentalmente a las transmisiones de datos que

produzcan tráfico "a ráfagas", es decir, discontinuo.

GPS.- El SPG o GPS (Global Positioning System: sistema de posicionamiento

global) o NAVSTAR-GPS []es un sistema global de navegación por satélite

(GNSS) que permite determinar en todo el mundo la posición de un objeto, una

persona o un vehículo con una precisión hasta de centímetros (si se utiliza GPS

diferencial), aunque lo habitual son unos pocos metros de precisión.

Gráfico de Burndown.- Los gráficos de Burndown muestran el trabajo restante

en el tiempo. El trabajo restante es el eje Y y el tiempo es el eje X. El trabajo

restante debería subir y bajar y eventualmente tener una tendencia descendente.

Gráfico de burndown de la entrega.- En Scrum, el gráfico de burndown de la

entrega brinda una visión "general" sobre el progreso de la entrega. Muestra

cuánto trabajo queda hacer al principio de cada sprint, para una única entrega. El

alcance de este gráfico es una única entrega; sin embargo, un gráfico de

burndown del producto abarca todas las entregas.

Gráfico de burndown del producto.- En Scrum, el gráfico de burndown del

producto es una vista "general" del progreso del proyecto. Muestra cuánto trabajo

restante hay al comienzo de cada sprint.

GSM.- El sistema global para las comunicaciones móviles (GSM) es un sistema

estándar, libre de regalías, de telefonía móvil digital.

Impedimentos.- Un impedimento es cualquier cosa que le impida al equipo

desempeñarse lo más eficientemente posible.

134

Miembro del equipo.- Un miembro del equipo es cualquier persona que está

trabajando en las tareas del sprint para cumplir el objetivo del sprint.

Módulo de joomla.- Los módulos son extensiones o complementos de Joomla

que permiten añadir bloques de información secundaria en diferentes posiciones o

zonas de la plantilla, normalmente en la zona periférica: columnas laterales,

encabezamiento y pie de página.

PYME.- La pequeña y mediana empresa (conocida también por el acrónimo

PYME, lexicalizado como pyme) es una empresa con características distintivas, y

tiene dimensiones con ciertos límites ocupacionales y financieros prefijados por

los Estados o regiones.

Reunión de planificación del sprint.- La reunión de planificación del sprint es

una negociación entre el equipo y el dueño del producto sobre lo que el equipo

hará durante el siguiente sprint.

Reunión de retrospectiva del sprint.- La reunión de retrospectiva del sprint se

realiza al final de cada sprint, después de la reunión de demo del sprint. El equipo

y el ScrumMaster se juntan para discutir lo que salió bien y lo que necesita

mejorarse en el próximo sprint. El dueño del producto no asiste a esta reunión.La

retrospectiva del sprint está acotdada a 3 horas.

Reunión diaria de Scrum.- Una reunión diaria de 15 minutos en donde cada

miembro del equipo responde 3 preguntas: ¿Qué hice desde la última reunión de

Scrum?, ¿Qué voy a hacer para la próxima reunión de Scrum?, ¿Qué me impide

realizar mi trabajo lo más eficientemente posible?.

Rol de Dueño del Producto.- En Scrum, hay una única persona que tiene la

autoridad final representando los intereses del cliente, priorizando el backlog y

respondiendo preguntas sobre los requerimientos. Esta persona debe estar

disponible para el equipo en cualquier momento, especialmente durante la

reunión de planificación del sprint y durante la reunión de demo del sprint.

Rol de ScrumMaster.- El ScrumMaster es una facilitador para el equipo y para el

Dueño del Producto. En vez de gestionar al equipo, el ScrumMaster trabaja para

asistir tanto al equipo como al Dueño del Producto.

135

Scrum.- Scrum es un marco de trabajo para la gestión y desarrollo de software

basada en un proceso iterativo e incremental utilizado comúnmente en entornos

basados en el desarrollo ágil de software.

Sprint.- Sprint en Scrum es el término que denomina a una iteración que está

acotada en el tiempo, usualmente entre 2 y 4 semanas, durante la cual el Equipo

trabaja para convertir items del Backlog Del Producto en un Incremento Del

Producto potencialmente productivo.

Tarea del sprint.- En Scrum, una tarea del sprint (o tarea) es una unidad de

trabajo generalmente entre 4 y 16 horas. Los miembros del equipo se asignan

voluntariamente las tareas. Actualizan la estimación de horas restantes de forma

diaria, influenciando así el gráfico de burndown del sprint.

Velocidad.- En Scrum, la velocidad es cuánto esfuerzo del backlog del producto

el equipo puede manejar en un sprint. Esto puede estimarse viendo los sprints

pasados, asumiendo que la composición del equipo y la duración del sprint se

mantienen constante.

136

BIBLIOGRAFÍA

TESIS:

1) ARELLANO MONCAYO, Fabricio Gerardo. Desarrollo e Implantación del

Sistema de Reservación de Laboratorios para el Laboratorio de la Facultad

de Ingeniería de Sistemas. QUITO/EPN/2011.

2) MORA TERÁN, Karina Alexandra. Desarrollo e Implementación del Portal

Web de la Facultad de Ingeniería de Sistemas de la EPN.

QUITO/EPN/2009.

3) ROCHA RAMIREZ, Luis Enrique; VILLAGRAN PALACIO, Alejandro

Patricio. Desarrollo de un Sistema de Simulación Tridimensional de Planos

Digitales para Empresas de Construcción. QUITO/EPN/2009

LIBROS:

4) PRESSMAN, Roger. “Ingeniería de Software un enfoque práctico”. Quinta

Edición, McGrawHill, España, 2002.

5) SCHWABER, Ken. “Agile Project Management with Scrum”. Microsoft

Press, Estados Unidos, 2004.

6) PALACIO, Juan. “Flexibilidad con Scrum”. Editorial – Lulu, 2008.

7) KNIBERG, Henrik. “Scrum y XP desde las Trincheras”. Editorial – Lulu,

2007.

8) COHN, Mike. “Agile Estimating and Planning”. Prentice Hall PTR, 2005.

9) SHORE, James; WARDEN, Shane. “The Art of Agile Development”.

Cambridge University Press, 2004.

10) MARTIN, Robert C. “Agile Software Development, Principles, Patterns,

and Practices”. Prentice Hall, 2002.

11) AMBLER, Scott. “The Object Primer” Tercera Edición, Cambridge

University Press, 2004.

137

PUBLICACIONES EN INTERNET:

12) SILVA, Rene. Herramientas para consultas PHP en la Web [en línea].

[Consulta: mayo 2012]. Disponible en Internet:

< http://www.eresseasolutions.com/tutoriales/desarrollo-de-aplicaciones-

web-basadas-en-php/las-herramientas/>

13) SANCHEZ, Carlos. Aplicaciones en capas [en línea]. [Consulta: mayo

2012]. Disponible en Internet:

< http://oness.sourceforge.net/proyecto/html/ch03s02.html>

14) CALLE, Fani. Arquitectura 3 capas [en línea]. [Consulta: mayo 2012].

Disponible en Internet:

< http://www.slideshare.net/Decimo/arquitectura-3-capas>

15) COMUNIDAD JOOMLA. Manual de Instalación para Joomla! 1.5 [en línea].


< http://comunidadjoomla.org/component/content/article/147-manual-de-

instalacion-para-joomla-15x.html?showall=1>

16) SUEIRAS, Edita. ¿Qué es Joomla? [en línea]. [Consulta: mayo 2012].

Disponible en Internet:

<http://www.lasticenelaula.es/portal/index.php?option=com_content&view=

article&id=6:ique-es-joomla&catid=22:descarga&Itemid=17>

17) RAINER. ¿Por qué elegir Joomla para montar su sitio Web? [en línea].


< http://www.hanantek.com/porque-elegir-joomla>

18) LUISELICIO. Modelo Físico y Lógico de una Base de Datos en Power

Designer [en línea]. [Consulta: mayo 2012]. Disponible en Internet:

< http://www.youtube.com/watch?v=eST2fUM_Q7I>

138

ANEXOS

ANEXO 1: Tablas que conforman la BDD del Sistema LendaSoft (Anexo Digital).

ANEXO 2: Interfaces de la versión 1.0 del Sistema LendaSoft (Anexo Digital).

ANEXO 3: Acta de entrega de la versión 1.0 del Sistema (Anexo Impreso).

ANEXO 4: Creación de página Web informativa (Anexo Digital).

ANEXO 5: Manual de implementación del Sistema Lendasoft (Anexo Digital).

ANEXO 6: Acta de entrega de la versión 2.0 del Sistema (Anexo Impreso).

ANEXO 7: Entrevista al usuario y resultado sobre el nivel de satisfacción del

Sistema LendaSoft y portal Web (Anexo Digital).

ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/4768/1/CD-4383.pdf · DESARROLLO...

Documents

Transcript of ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/4768/1/CD-4383.pdf · DESARROLLO...