escuela politÉcnica nacionalbibdigital.epn.edu.ec/bitstream/15000/4768/1/cd-4383.pdf · desarrollo...
TRANSCRIPT
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
EDGAR ANDRÉS TELLO LEÓN
DIRECTOR: MSC. ING. MARCOS RAÚL CÓRDOVA BAYAS
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
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
Puntos estimados: 3 Iteración asignada: 1
Responsable: Edgar Andrés
Descripción:
Como almacenista quiero crear, visualizar, buscar, modificar y eliminar los datos relacionados con los proveedores. Quiero registrar el CI o RUC, el nombre, los teléfonos, el móvil, el fax, la dirección y el correo electrónico
Observaciones del equipo de desarrollo:
- No se puede crear un proveedor con el mismo CI/RUC.
Tabla 2.3 Historia de Usuario “Gestión de Proveedores” Elaborado por los autores
Historia de Usuario
Número: 3 Usuario: Almacenista
Nombre historia: Gestión de Productos y Tipos de Producto
Prioridad en negocio: 4 Riesgo en desarrollo: Baja
Puntos estimados: 5 Iteración asignada: 1
38
Responsable: Edgar Andrés
Descripción:
Como almacenista quiero insertar, buscar, modificar, ver y eliminar los productos que ingresen a bodega con su respectivo nombre, proveedor, marca, fecha de ingreso y precio, además quiero clasificarlos según su tipo de producto, y que se emitan alertas cuando el stock esté a punto de agotarse. Quiero insertar, buscar, modificar, ver y eliminar tipos de producto.
Observaciones del equipo de desarrollo:
- Tipos de Producto: son las cinco categorías principales en las que la Empresa dividió a los productos que comercializa.
- No se puede eliminar un tipo de producto que tenga productos asociados. Tabla 2.4 Historia de Usuario “Gestión de Productos y Tipos de Producto”
Elaborado por los autores
Historia de Usuario
Número: 4 Usuario: Vendedor
Nombre historia: Generación de Facturas
Prioridad en negocio: 4 Riesgo en desarrollo: Medio
Puntos estimados: 5 Iteración asignada: 1
Responsable: Eleana Inés
Descripción:
Como vendedor quiero generar facturas a mis clientes y buscar estas facturas por CI/RUC del cliente, por número o estado de la factura. Para insertar una nueva factura quiero seleccionar un cliente ya registrado o insertar uno nuevo en ese momento, además de la inserción deseo modificar, visualizar y eliminar facturas de mis clientes.
Observaciones del equipo de desarrollo:
- El estado de la factura puede ser “pagada” o “sin pagar” - No se puede eliminar una factura pagada. - La factura no podrá ser generada si no cuenta con número de factura. - No se puede generar una factura con el mismo número de factura.
Tabla 2.5 Historia de Usuario “Generación de Factura” Elaborado por los autores
39
Historia de Usuario
Número: 5 Usuario: Almacenista
Nombre historia: Gestión de Facturas de los Proveedores
Prioridad en negocio: 3 Riesgo en desarrollo: Baja
Puntos estimados: 4 Iteración asignada: 1
Responsable: Eleana Inés
Descripción:
Como almacenista quiero registrar las facturas que me entregan mis proveedores y gestionarlas, es decir llevar un control de las que están y no están pagadas, así como también tener la posibilidad de modificar, ver, eliminar y además buscar las facturas por CI/RUC del proveedor, por número de factura o estado.
Observaciones del equipo de desarrollo:
- El estado de la factura puede ser “pagada” o “sin pagar” - No se puede eliminar una factura pagada. - La factura no podrá ser generada si no cuenta con un código de factura.
Tabla 2.6 Historia de Usuario “Gestión de Facturas de los Proveedores” Elaborado por los autores
Historia de Usuario
Número: 6 Usuario: Administrador
Nombre historia: Creación de página web informativa
Prioridad en negocio: 1 Riesgo en desarrollo: Baja
Puntos estimados: 5 Iteración asignada: 2
Responsable: Eleana Inés
Descripción:
Como administrador quiero una página web que tenga la siguiente información: datos acerca de mi empresa, los tipos de producto y productos que ofrezco, imágenes de los mismos, información de contacto y que mis clientes puedan hacer preguntas a través de mi página web, además deseo que mis clientes puedan registrarse en mi sitio web.
Observaciones del equipo de desarrollo:
- Se registrarán las visitas realizadas a la página. Tabla 2.7 Historia de Usuario “Creación de página web informativa”
Elaborado por los autores
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.
Elaborado por los autores
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
Elaborado por los autores
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
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
...<p
i>
fact
uras
tmp
codf
actu
rac
fech
a<p
i>In
tege
rDa
te<M
><M
>
Iden
tifie
r_1
...<p
i>
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
...<p
i>
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
...<p
i>
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
Elaborado por los autores
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
Elaborado por los autores
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
ejecuta las operaciones descritas en la Historia de Usuario 3.
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
Caso de Prueba de Aceptación
Código: 2 Historia de (Nro. y Nombre): 1 Gestión de Clientes
Nombre de Caso de Prueba: Prueba Modificación de Cliente
Descripción: Se procede a modificar uno o varios de los siguientes datos de un cliente existente: Nombre, Teléfono, Móvil, Dirección, Correo electrónico y verificar que se realicen los cambios en la Base de Datos.
Condiciones de Ejecución: Que el cliente a modificarse exista, el campo de correo electrónico tiene su formato característico.
Entrada (pasos de ejecución):
1. Acceder a la interface “Clientes”.
2. Señalar el cliente que se desea modificar.
3. Modificar uno o varios de los datos correspondientes a los campos: Nombre, Teléfono, Móvil, Dirección, Correo electrónico. Los datos modificados fueron erróneos.
4. Dar clic en el botón “Aceptar”.
5. Se muestran los datos modificados y se verifican que sean correctos.
6. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos.
Resultado Obtenido: El sistema permitió que se ingresen datos erróneos al modificarlos.
Acciones Correctivas: Validar que los datos que se modifiquen sean correctos
Evaluación de la prueba: Media
No se mostró el resultado esperado pero se ejecutaron las acciones correctivas
Tabla 2.14 Caso de Prueba de Aceptación “Prueba Modificación de Cliente” Elaborado por los autores
67
Caso de Prueba de Aceptación
Código: 3 Historia de (Nro. y Nombre): 1 Gestión de Clientes
Nombre de Caso de Prueba: Prueba Eliminación de Cliente
Descripción: Se procede a eliminar un cliente seleccionado y verificar que se realice el cambio en la Base de Datos.
Condiciones de Ejecución: Que el cliente a eliminarse exista y se muestre en la interface de clientes.
Entrada (pasos de ejecución):
1. Acceder a la interface “Clientes”.
2. Señalar el cliente que se desea eliminar.
3. Eliminar el cliente seleccionado.
4. Dar clic en el botón “Aceptar”.
5. Se muestra que el cliente ha sido eliminado.
6. Dar clic en “Aceptar”.
Resultado esperado: La eliminación del cliente.
Resultado obtenido: Se eliminó al cliente seleccionado.
Acciones Correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.15 Caso de Prueba de Aceptación “Prueba Eliminación de Cliente” 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
Caso de Prueba de Aceptación
Código: 4 Historia de (Nro. y Nombre): 2 Gestión de Proveedores
Nombre de Caso de Prueba: Prueba Inserción de Proveedor
Descripción: Se procede a insertar los siguientes datos de un nuevo proveedor: CI o RUC, Nombre, Teléfono 1, Teléfono 2, Móvil, Fax, Dirección, Correo electrónico y verificar que se almacenen en la Base de Datos.
Condiciones de Ejecución: El campo de correo electrónico tiene su formato característico, en el campo CI/RUC se ingresan máximo 13 caracteres, ingresar el campo Nombre.
Entrada (pasos de ejecución):
1. Acceder a la interface “Insertar Proveedor”.
2. Ingresar los datos correspondientes en los campos: CI o RUC, Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico. Se ingresaron datos erróneos.
3. Dar clic en el botón “Aceptar”.
4. Se muestran los datos ingresados y se verifican que sean correctos.
5. Dar clic en “Aceptar”
Resultado esperado: El despliegue de la pantalla de Ingreso correcto de datos.
Resultado obtenido: El sistema permitió el ingreso de datos erróneos.
Acciones correctivas: Validar los datos que se ingresan.
Evaluación de la prueba: Media
No se mostró el resultado esperado pero se ejecutaron las acciones correctivas.
Tabla 2.16 Caso de Prueba de Aceptación “Prueba Inserción de Proveedor” Elaborado por los autores
Caso de Prueba de Aceptación
Código: 5 Historia de (Nro. y Nombre): 2 Gestión de Proveedores
Nombre de Caso de Prueba: Prueba Modificación de Proveedor
Descripción: Se procede a modificar uno o varios de los siguientes datos de un proveedor existente: Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico y verificar que se realicen los cambios en la Base de Datos.
69
Condiciones de Ejecución: Debe existir el proveedor a modificarse, el campo de correo electrónico tiene su formato característico.
Entrada (pasos de ejecución):
1. Acceder a la interface “Proveedores”.
2. Señalar el proveedor que se desea modificar.
3. Modificar uno o varios de los datos correspondientes a los campos: Nombre, Teléfono1, Teléfono2, Móvil, Fax, Dirección, Correo electrónico. Al modificar los datos estos fueron erróneos.
4. Dar clic en el botón “Aceptar”.
5. Se muestran los datos modificados y se verifican que sean correctos.
6. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos.
Resultado obtenido: El sistema permitió que al modificarse los datos éstos fueran erróneos.
Acciones Correctivas: Validar los datos modificados
Evaluación de la prueba: Media
No se mostró el resultado esperado, pero se ejecutaron las acciones correctivas.
Tabla 2.17 Caso de Prueba de Aceptación “Prueba Modificación de Proveedor” Elaborado por los autores
Caso de Prueba de Aceptación
Código: 6 Historia de (Nro. y Nombre): 2 Gestión de Proveedores
Nombre de Caso de Prueba: Prueba Eliminación de Proveedor
Descripción: Se procede a eliminar un proveedor seleccionado y verificar que se realice el cambio en la Base de Datos.
Condiciones de Ejecución: Que el proveedor a eliminarse exista y se muestre en la interface de proveedores.
Entrada (pasos de ejecución):
1. Acceder a la interface “Proveedores”.
70
2. Señalar el proveedor que se desea eliminar.
3. Eliminar el proveedor seleccionado.
4. Dar clic en el botón “Aceptar”.
5. Se muestra que el proveedor ha sido eliminado.
6. Dar clic en “Aceptar”.
Resultado esperado: La eliminación del proveedor.
Resultado obtenido: Se permitió la eliminación del proveedor seleccionado.
Acciones Correctivas: Ninguna.
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.18 Caso de Prueba de Aceptación “Prueba Eliminación de Proveedor” 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.
Caso de Prueba de Aceptación
Código: 7 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos.
Nombre de Caso de Prueba: Prueba Inserción de Tipo de Producto
Descripción: Se procede a insertar el nombre de un nuevo tipo de producto y se verifica que se almacene en la Base de Datos.
Condiciones de Ejecución: Ingresar datos en el campo Nombre.
Entrada (pasos de ejecución):
1. Acceder a la interface “Insertar Tipo de Producto”.
2. Ingresar el nombre del nuevo Tipo de Producto.
71
3. Dar clic en el botón “Aceptar”.
4. Se muestran los datos ingresados y se verifican que sean correctos.
5. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de la pantalla de Ingreso correcto del nombre.
Resultado obtenido: Se ingresó el nuevo Tipo de Producto
Acciones Correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.19 Caso de Prueba de Aceptación “Prueba Inserción de Tipo de Producto” Elaborado por los autores
Caso de Prueba de Aceptación
Código: 8 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos
Nombre de Caso de Prueba: Prueba de Inserción de Producto
Descripción: Se procede a insertar los siguientes datos de un nuevo producto: Referencia, Nombre, Marca, Stock, Stock mínimo, Fecha de ingreso, Observaciones, Precio de compra, Precio de almacén, Precio de Tienda, PVP, precio con IVA. Y los siguientes datos: Tipo de producto, Proveedor 1, Proveedor 2 y Aviso mínimo se escogen del combo mostrado en la interface y verificar que se almacenen en la Base de Datos.
Condiciones de Ejecución: Ingresar el campo Referencia, Descripción, Observaciones y Nombre.
Entrada (pasos de ejecución):
1. Acceder a la interface “Insertar Producto”.
2. Ingresar y escoger los datos descritos anteriormente en sus correspondientes campos. Estos datos fueron erróneos
3. Dar clic en el botón “Aceptar”.
4. Se muestran los datos ingresados y se verifican que sean correctos.
5. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de la pantalla de Ingreso correcto de datos.
Resultado obtenido: El sistema valida algunos campos pero otros no.
72
Acciones Correctivas: Validar todos los campos.
Evaluación de la prueba: Media
El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas.
Tabla 2.20 Caso de Prueba de Aceptación “Prueba Inserción de Producto” Elaborado por los autores
Caso de Prueba de Aceptación
Código: 9 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos
Nombre de Caso de Prueba: Prueba Búsqueda de Producto
Descripción: Se procede a la búsqueda de un producto según el tipo de producto al que pertenece, su referencia o su nombre y se verifica que se muestre el producto seleccionado.
Condiciones de Ejecución: Que el producto que se desea encontrar se encuentre registrado en la lista de productos.
Entrada (pasos de ejecución):
1. Acceder a la interface “Productos”.
2. Hacer clic en la lupa de la sección Buscar Producto.
3. Escoger uno o varios criterios de búsqueda en este caso: Tipo de Producto, Referencia o Nombre.
4. Clic en “Buscar” y escoger el producto seleccionado.
5. Dar clic en “Buscar”.
Resultado esperado: Que se muestre el producto buscado.
Resultado obtenido: Se mostró el producto seleccionado.
Acciones correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.21 Caso de Prueba de Aceptación “Prueba Búsqueda de Producto” Elaborado por los autores
73
Caso de Prueba de Aceptación
Código: 10 Historia de (Nro. y Nombre): 3 Gestión de Tipos de Producto y Productos
Nombre de Caso de Prueba: Prueba Modificación de Producto
Descripción: Se procede a modificar uno o varios de los siguientes datos de un producto existente: Referencia, Nombre, Marca, Stock, Stock mínimo, Fecha de ingreso, Observaciones, Precio de compra, Precio de almacén, Precio de Tienda, PVP, precio con IVA. Y los siguientes datos: Tipo de producto, Proveedor 1, Proveedor 2 y Aviso mínimo; se modifican escogiendo los datos mostrados en el combo de la interface y verificar que se realicen los cambios en la Base de Datos.
Condiciones de Ejecución: Que el producto a modificarse esté registrado en la lista de productos.
Entrada (pasos de ejecución):
1. Acceder a la interface “Productos”.
2. Señalar el producto que se desea modificar.
3. Modificar uno o varios de los datos descritos anteriormente. Estas modificaciones se ingresaron con datos erróneos.
4. Dar clic en el botón “Aceptar”.
5. Se muestran los datos modificados y se verifican que sean correctos.
6. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos.
Resultado obtenido: El sistema validó algunos campos pero no todos
Acciones Correctivas: Validar todos los campos.
Evaluación de la prueba: Media
El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas correspondientes.
Tabla 2.22 Caso de Prueba de Aceptación “Prueba Modificación de Producto” 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.
Caso de Prueba de Aceptación
Código: 11 Historia de (Nro. y Nombre): 4 Generación de Facturas
Nombre de Caso de Prueba: Prueba Inserción de Factura
Descripción: Se procede a escoger o ingresar un nuevo cliente, luego se inserta el número de factura, luego se agrega uno o varios productos registrados y se verifica que se almacene la información en la Base de Datos.
Condiciones de Ejecución: Ingresar el Núm. de Factura, que los productos que se vayan a agregar estén previamente registrados en el sistema.
Entrada (pasos de ejecución):
1. Acceder a la interface “Insertar Factura”.
2. Agregar un cliente.
2.1 Nuevo Cliente: Se ingresan estos datos: CI o RUC, Nombre, Teléfono, Móvil, Dirección, Correo electrónico y clic en “Aceptar”. Se ingresaron datos erróneos.
2.2 Cliente Registrado: Se hace clic en la lupa, y se escoge uno de los clientes mostrados.
3. Se ingresa el Número de la Factura.
4. Se agrega un producto haciendo clic en la lupa.
5. Se busca y escoge el producto que se desea vender.
6. Se ingresa la cantidad de productos vendidos.
7. Si se realiza un descuento ingresarlo en el campo “Dcto”.
8. Dar clic en “Agregar”.
9. Dar clic en “Aceptar”.
Resultado esperado: El ingreso de la nueva factura.
Resultado obtenido: Se ingresó la nueva factura con datos erróneos.
Acciones correctivas: Se validaron todos los campos del formulario.
75
Evaluación de la prueba: Media
El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas correspondientes.
Tabla 2.23 Caso de Prueba de Aceptación “Prueba Inserción de Factura” Elaborado por los autores
Caso de Prueba de Aceptación
Código: 12 Historia de (Nro. y Nombre): 4 Generación de Facturas
Nombre de Caso de Prueba: Prueba Búsqueda de Factura
Descripción: Se procede a la búsqueda de una factura según los siguientes criterios: el Estado (se refiere a pagada o sin pagar), el Número de Factura, el cliente y se verifica que se muestre la factura seleccionada.
Condiciones de Ejecución: Que la factura que se desea encontrar se encuentre registrada en el sistema.
Entrada (pasos de ejecución):
1. Acceder a la interface “Facturas”.
2. Hacer clic en la lupa de la sección CI/RUC de cliente.
3. Escoger el cliente deseado e ir al paso 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.
Acciones correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.24 Caso de Prueba de Aceptación “Prueba Búsqueda de Factura” Elaborado por los autores
76
Caso de Prueba de Aceptación
Código: 13 Historia de (Nro. y Nombre): 4 Generación de Facturas
Nombre de Caso de Prueba: Prueba Modificación de Factura
Descripción: Se procede a modificar uno o varios de los siguientes datos existentes: Ciudad, Fecha, Código de Factura. Se puede modificar el cliente ingresando uno nuevo o añadiendo otro existente. Se pueden agregar nuevos productos existentes en el sistema, se pueden eliminar los productos ya agregados en la factura y se verifica que se realicen los cambios en la Base de Datos.
Condiciones de Ejecución: Que la factura esté en estado Sin pagar.
Entrada (pasos de ejecución):
1. Acceder a la interface “Facturas”.
2. Señalar la factura que se desea modificar.
3. Modificar uno o varios de los datos descritos anteriormente. Al modificar los datos éstos fueron erróneos.
4. Dar clic en el botón “Aceptar”.
5. Se muestran los datos modificados y se verifican que sean correctos.
6. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de la pantalla con la modificación correcta de los datos.
Resultado obtenido: El sistema permitió que algunos campos modificados se ingresen con datos erróneos.
Acciones correctivas: Validar todos los campos del formulario.
Evaluación de la prueba: Media
El sistema no mostró el resultado esperado pero se ejecutaron las respectivas acciones correctivas.
Tabla 2.25 Caso de Prueba de Aceptación “Prueba Modificación de Factura” Elaborado por los autores
77
Caso de Prueba de Aceptación
Código: 14 Historia de (Nro. y Nombre): 4 Generación de Facturas
Nombre de Caso de Prueba: Prueba Visualización de Factura
Descripción: Se procede a visualizar una Factura con todos sus datos: CI/RUC del cliente, Nombre del Cliente, Número de Factura, Ciudad Fecha y el detalle de los productos de la factura.
Condiciones de Ejecución: Que la factura esté registrada en el Sistema.
Entrada (pasos de ejecución):
1. Acceder a la interface “Facturas”.
2. Señalar el la factura que se desea visualizar.
3. Hacer clic en la lupa “Visualizar”.
4. Se muestran los datos de la factura.
5. Dar clic en “Aceptar”.
Resultado esperado: El despliegue de datos de la Factura seleccionada.
Resultado obtenido: Se visualizó la factura seleccionada.
Acciones correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.26 Caso de Prueba de Aceptación “Prueba Visualización de Factura” Elaborado por los autores
Caso de Prueba de Aceptación
Código: 15 Historia de (Nro. y Nombre): 5 Gestión de Facturas de Proveedores
Nombre de Caso de Prueba: Prueba Inserción de Factura de Proveedor
Descripción: Se procede a escoger un proveedor, luego se copia el código de la factura, se inserta el número de teléfono del proveedor, la fecha de compra, luego se agrega uno o varios productos que hayan sido vendidos a la empresa por el proveedor ingresado previamente, y se verifica que se almacene la información en la Base de Datos.
Condiciones de Ejecución: que el proveedor esté registrado en el sistema, solo se pueden agregar productos del proveedor ingresado en la misma factura.
78
Entrada (pasos de ejecución):
1. Acceder a la interface “Insertar Factura”.
2. Agregar un Proveedor registrado.
3. Se hace clic en la lupa, y se escoge uno de los proveedores registrados.
4. Se ingresa el Código de la factura.
5. Se agrega la Fecha de la factura.
6. Se agrega el teléfono del proveedor.
7. Se agrega un producto haciendo clic en la lupa.
8. Se escoge el producto adquirido.
9. Se ingresa la cantidad de productos del proveedor.
10. Si existe descuento por parte del proveedor ingresarlo en el campo “Dcto”.
11. Dar clic en “Agregar”.
12. Si se agrega un nuevo producto regresar al paso 7 caso contrario seguir con el paso 13.
13. Dar clic en “Aceptar”.
Resultado esperado: El ingreso de la nueva factura
Resultado obtenido: Se ingresó una nueva factura
Acciones correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 2.27 Caso de Prueba de Aceptación “Prueba Inserción de Factura de Proveedor” 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
Número: 7 Usuario: Vendedor
Nombre historia: Cobros
Prioridad en negocio: 3 Riesgo en desarrollo: Medio
Puntos estimados: 4 Iteración asignada: 2
80
Responsable: Edgar Andrés – Eleana Inés
Descripción:
Como vendedor quiero buscar información referente a las facturas emitidas a mis clientes y poder visualizar: el número de factura, el nombre del cliente, el monto que queda pendiente por cobrar y la fecha que se realiza el cobro.
Observaciones del equipo de desarrollo:
- Se va a visualizar el Estado de la factura que puede ser “pagada” o “sin pagar”.
- Se pueden registrar: los cobros pendientes, la fecha en la que se realizó el cobro y la forma de pago.
Tabla 3.1 Historia de Usuario “Cobros” Elaborado por los autores
Historia de Usuario
Número: 8 Usuario: Almacenista
Nombre historia: Pagos
Prioridad en negocio: 3 Riesgo en desarrollo: Medio
Puntos estimados: 4 Iteración asignada: 2
Responsable: Edgar Andrés – Eleana Inés
Descripción:
Como almacenista quiero buscar información referente a las facturas registradas de mis proveedores y poder visualizar: el número de factura, el nombre del proveedor, el monto que queda pendiente por pagar y la fecha que se realiza el pago.
Observaciones del equipo de desarrollo:
- Se va a visualizar el Estado de la factura que puede ser “pagada” o “sin pagar”.
- Se pueden registrar: los pagos pendientes, la fecha en la que se realizó el pago y la forma de pago.
Tabla 3.2 Historia de Usuario “Pagos” Elaborado por los autores
81
Historia de Usuario
Número: 9 Usuario: Administrador
Nombre historia: Caja Diaria
Prioridad en negocio: 2 Riesgo en desarrollo: Baja
Puntos estimados: 3 Iteración asignada: 2
Responsable: Edgar Andrés
Descripción:
Como administrador quiero buscar por fecha detalles del cierre de caja, como: el valor neto, el valor del iva, el total al contado y poder imprimir los resultados.
Observaciones del equipo de desarrollo:
Ninguna.
Tabla 3.3 Historia de Usuario “Caja Diaria” Elaborado por los autores
Historia de Usuario
Número: 10 Usuario: Administrador
Nombre historia: Libro Diario
Prioridad en negocio: 2 Riesgo en desarrollo: Medio
Puntos estimados: 3 Iteración asignada: 1
Responsable: Eleana Inés
Descripción:
Como administrador quiero buscar por un período determinado de tiempo las ventas y compras efectuadas y que se muestre: la fecha, si es compra o si es venta, el número de la factura, el nombre del agente comercial, la forma de pago y el valor de la venta o compra.
Observaciones del equipo de desarrollo:
Ninguna.
Tabla 3.4 Historia de Usuario “Libro Diario” Elaborado por los autores
82
Historia de Usuario
Número: 11 Usuario: Administrador
Nombre historia: Respaldo de Información
Prioridad en negocio: 1 Riesgo en desarrollo: Baja
Puntos estimados: 2 Iteración asignada: 2
Responsable: Eleana Inés
Descripción:
Como administrador quiero realizar copias de seguridad de toda la información que gestiono, para luego poder restaurarla.
Observaciones del equipo de desarrollo:
- No se podrá cambiar la fecha y hora en la que se cree una copia de seguridad. Tabla 3.5 Historia de Usuario “Respaldo de Información”
Elaborado por los autores
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
Elaborado por los autores
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
Buscar movimientos Andrés 3
Ver pagos Eleana 2
Insertar pago Eleana 4
Revisión Raúl 2
Caja Diaria
Buscar detalles de cierre de caja Andrés 2
Imprimir detalles de cierra de caja Andrés 1
88
Revisión Raúl 2
Libro Diario
Buscar movimientos Andrés 2
Imprimir movimientos Andrés 1
Revisión Raúl 2
Respaldo de Información
Crear copia Andrés 2
Buscar copia Andrés 2
Restaurar copia Andrés 2
Eliminar copia Andrés 2
Revisión Raúl 2
Creación de página web informativa
Instalación de joomla Eleana 1
Diseño del sitio web Eleana 15
Instalación de plantilla Eleana 1
Creación de contenidos Eleana 4
Creación de menús Eleana 2
Creación de módulos Eleana 6
Revisión Raúl 2
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
Elaborado por los autores
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
Elaborado por los autores
92
3.4.1.1 Cobros
En esta sección se detalla como se desarrolló la opción de Cobros en el sistema,
mostrando primero la interface, después el fragmento de código que ejecuta las
operaciones descritas en la Historia de Usuario 7.
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
3.4.1.2 Pagos
En esta sección se detalla como se desarrolló la opción de Pagos en el sistema,
mostrando primero la interface, después el fragmento de código que ejecuta las
operaciones descritas en la Historia de Usuario 8.
5.4.1.2.1 Buscar Movimientos
Para acceder a la interface de Buscar Movimientos que se presenta en la Figura
3.11, se procede a seleccionar el menú Gestión de Cobros y Pagos, la opción
Pagos. Se puede buscar por: CI/RUC del proveedor, nombre del proveedor,
estados de factura y período de fechas.
Figura 3.11 Interface Buscar Movimientos Pagos
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
3.4.2.1 Caja Diaria
En esta sección se expone como se desarrolló la opción de Caja Diaria en el
sistema, mostrando primero la interface, después el fragmento de código que
ejecuta las operaciones descritas en la Historia de Usuario 9.
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
3.4.2.2 Libro Diario
En esta sección se expone como se desarrolló la opción de Libro Diario en el
sistema, mostrando primero la interface, después el fragmento de código que
ejecuta las operaciones descritas en la Historia de Usuario 10.
3.4.2.2.1 Buscar Movimientos
Para acceder a la interface Buscar Movimientos que se observa en la Figura 3.22,
se procede a seleccionar el menú Reportes, la opción Libro Diario donde se
buscan los movimientos por periodo de fechas y clic en el botón Buscar.
101
Figura 3.22 Interface Buscar Movimientos Libro Diario
Elaborado por los autores
El código que permite la búsqueda de datos del Libro Diario en la base de datos
se muestra en la Figura 3.23.
Figura 3.23 Código Buscar Movimientos Libro Diario
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
3.4.3.1 Hacer copia
En esta sección se expone como se desarrolló la opción Hacer copia en el
sistema, mostrando primero la interface, después el fragmento de código que
ejecuta las operaciones descritas en la Historia de Usuario 11.
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
3.4.3.2 Restaurar copia
En esta sección se expone como se desarrolló la opción Restaurar copia en el
sistema, mostrando primero la interface, después el fragmento de código que
ejecuta las operaciones descritas en la Historia de Usuario 11.
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
El código que permite la eliminación de la copia de seguridad de la base de datos
se muestra en la Figura 3.35.
Figura 3.35 Código Eliminar Copia de Seguridad
Elaborado por los autores
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”
Elaborado por los autores
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”
Elaborado por los autores
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”
Elaborado por los autores
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
Elaborado por los autores
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”
Elaborado por los autores
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
Elaborado por los autores
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
Elaborado por los autores
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.
Entrada (pasos de ejecución):
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.
Evaluación de la prueba: Media
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”
Elaborado por los autores
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”.
Entrada (pasos de ejecución):
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.
Evaluación de la prueba: Media
No se mostró el resultado esperado pero se ejecutaron las acciones correctivas.
Tabla 3.15 Caso de Prueba de Aceptación “Prueba de inserción de cobro”
Elaborado por los autores
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.
Caso de Prueba de Aceptación
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.
Entrada (pasos de ejecución):
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.
5. Dar clic en el botón “Buscar”.
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.
Evaluación de la prueba: Media
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”
Elaborado por los autores
119
Caso de Prueba de Aceptación
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”.
Entrada (pasos de ejecución):
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.
Evaluación de la prueba: Media
No se mostró el resultado esperado pero se ejecutaron las acciones correctivas.
Tabla 3.17 Caso de Prueba de Aceptación “Prueba de inserción de pago”
Elaborado por los autores
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
Caso de Prueba de Aceptación
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.
Entrada (pasos de ejecución):
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.
Acciones Correctivas: Ninguna
Evaluación de la prueba: Buena
El sistema mostró el resultado esperado.
Tabla 3.18 Caso de Prueba de Aceptación “Prueba de búsqueda de cierre de caja”
Elaborado por los autores
Caso de Prueba de Aceptación
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.
Entrada (pasos de ejecución):
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.
Acciones Correctivas: Ninguna.
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 3.19 Caso de Prueba de Aceptación “Prueba búsqueda de movimientos de libro diario”
Elaborado por los autores
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.
Caso de Prueba de Aceptación
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.
Entrada (pasos de ejecución):
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.
Acciones Correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 3.20 Caso de Prueba de Aceptación “Prueba de creación de copia de seguridad”
Elaborado por los autores
Caso de Prueba de Aceptación
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.
Entrada (pasos de ejecución):
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.
5. Dar clic en el botón “Buscar”.
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.
Acciones Correctivas: Ninguna
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 3.21 Caso de Prueba de Aceptación “Prueba de restauración de copia de seguridad”
Elaborado por los autores
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.
Caso de Prueba de Aceptación
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
Entrada (pasos de ejecución):
1. Hacer clic en el menú Quiénes somos.
2. Visualizar información mostrada.
3. Hacer clic en el menú Quiénes somos.
4. Seleccionar el sub menú Historia.
5. Visualizar información mostrada.
6. Hacer clic en el menú Quiénes somos.
7. Seleccionar sub menú Plan Estratégico.
8. Visualizar información mostrada.
9. Hacer clic en el menú Quiénes somos.
10. Seleccionar sub menú Plan Estratégico.
11. Seleccionar la opción Misión.
12. Visualizar información mostrada.
124
13. Hacer clic en el menú Quiénes somos.
14. Seleccionar sub menú Plan Estratégico.
15. Seleccionar la opción Visión.
16. Visualizar información mostrada.
17. Hacer clic en el menú Quiénes somos.
18. Seleccionar sub menú Plan Estratégico.
19. Seleccionar la opción Objetivos.
20. Visualizar información mostrada.
21. Hacer clic en el menú Quiénes somos.
22. Seleccionar sub menú Estructura Organizacional.
23. Visualizar información mostrada.
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.
Evaluación de la prueba: Media
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”
Elaborado por los autores
Caso de Prueba de Aceptación
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
Entrada (pasos de ejecución):
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.
6. Hacer clic en cualquier imagen del slide.
7. Hacer clic en el enlace de Audio y Video.
8. Hacer clic en la imagen de cualquier marca.
9. Visualizar las imágenes de los productos.
10. Hacer clic en cualquier imagen del slide.
11. Hacer clic en el enlace de Iluminación.
12. Visualizar las imágenes de los productos.
13. Hacer clic en cualquier imagen del slide.
14. Hacer clic en el enlace de Autolujos.
15. Visualizar información de los productos.
16. Hacer clic en cualquier imagen del slide.
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.
Acciones Correctivas: Ninguna.
Evaluación de la prueba: Buena.
Se mostró el resultado esperado.
Tabla 3.23 Caso de Prueba de Aceptación “Prueba de presentación de catálogo de productos”
Elaborado por los autores
126
Caso de Prueba de Aceptación
Código: 26 Historia de (Nro. y Nombre): 6 Creación de página web informativa
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.
Entrada (pasos de ejecución):
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.
Acciones Correctivas: Ninguna.
Evaluación de la prueba: Buena.
Se mostró el resultado esperado.
Tabla 3.24 Caso de Prueba de Aceptación “Prueba de visualización de información de contacto”
Elaborado por los autores
Caso de Prueba de Aceptación
Código: 27 Historia de (Nro. y Nombre): 6 Creación de página web informativa
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.
Entrada (pasos de ejecución):
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.
Evaluación de la prueba: Media
El sistema no mostró el resultado esperado pero se ejecutaron las acciones correctivas correspondientes.
Tabla 3.25 Caso de Prueba de Aceptación “Prueba de envío del formulario de contacto”
Elaborado por los autores
Caso de Prueba de Aceptación
Código: 28 Historia de (Nro. y Nombre): 6 Creación de página web informativa
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.
Entrada (pasos de ejecución):
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.
Acciones Correctivas: Ninguna.
Evaluación de la prueba: Buena
Se mostró el resultado esperado.
Tabla 3.26 Caso de Prueba de Aceptación “Prueba de registro de usuarios”
Elaborado por los autores
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].
[Consulta: mayo 2012]. Disponible en Internet:
< 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].
[Consulta: mayo 2012]. Disponible en Internet:
< 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).