UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO

“AUTOMATIZACIÓN EN EL CONTROL DE LA INFORMACIÓN DE

PRODUCTOS PARA LA EMPRESA TECNOALIMENTOS LTDA.”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN: INGENIERIA DE SISTEMAS INFORMÁTICOS

POSTULANTE: Mónica Miranda Ari

TUTOR METODOLOGICO: M.Sc. Aldo Ramiro Valdez Alvarado
ASESOR: Lic. Celia Tarquino Peralta

LA PAZ – BOLIVIA
2016
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
 DEDICATORIA

Dedicado a las personas más importantes de mi vida, A Juan Miranda Chávez,

Santusa Ari Palma, Verónica Miranda Ari y Marvin Furuya Velarde.
 AGRADECIMIENTOS

Agradecer a Dios por haberme guiado a lo largo de mi carrera por regalarme y

permitirme disfrutar de la vida y por acompañarme en cada paso.

Darle gracias a mis papas Juan Miranda y Santusa Ari por el apoyo incondicional, por
el cariño, la paciencia, por los valores que me han inculcado, por haberme dado la
oportunidad de estudiar pero sobre todo por ser unos padres maravillosos.

A mi hermana Verónica Miranda por su apoyo, su cariño y porque siempre fue y es

mi ejemplo a seguir.

A Marvin Furuya Velarde por haberme tenido paciencia en todo momento, por
motivarme a seguir adelante, por su ayuda incondicional y por ser una parte
importante en mi vida.

Agradecer a mi tutor M.Sc. Aldo Ramiro Valdez, por su colaboración, su paciencia y

sus consejos en la realización del presente Proyecto de Grado.

Agradecer a mi asesora Lic. Celia Tarquino, por su apoyo, sus consejos, por
compartir su conocimiento y por ser una profesional ejemplo a seguir.

También agradecer a la Universidad Mayor de San Andrés por cobijarme en sus aulas
en todo el largo de mi carrera.
 RESUMÉN

En la actualidad la mayoría de las Empresas distribuidoras de productos (insumos,

procesados) los procesos de solicitud, entrega y devolución son de forma manual, es
decir el proceso no está automatizado todo se registra en papeles y la petición de
pedidos se realiza por teléfono e incluso deben apersonarse a la empresa. Lo cual
ocasiona pérdida de productos al no determinar la cantidad exacta de su stock por
cliente, así mismo la pérdida de clientes ante el desabastecimiento de productos lo
que ocasión disconformidad por falta de organización en la entrega de pedidos,
además provoca pérdidas económicas.

Por otra parte si el Gerente de la Empresa quisiera obtener información de los tipos de
productos, productos y stock de productos que se le distribuye a un determinado
cliente el proceso para obtener esta información demoraría y no es fácil de obtener en
ese mismo instante.

Es por eso que se decidió automatizar los procesos e información de la Empresa

Tecnoalimentos Ltda., a través de un sistema web y una aplicación móvil que ayudara
a simplificar el proceso de solicitud de procesos y mejorar el cronograma para
realizar la distribución de pedidos para los clientes con los que cuenta la Empresa.

Así mismo el sistema web y aplicación móvil ayudara de alguna forma, a tener una
idea de la cantidad de pedidos que realizan sus clientes, esto con el fin de dar
prioridad al momento de realizar su cronograma de entrega de pedidos, además de
mantener actualizado los stocks de sus productos y obtener reportes con información
actualizada.
 RESPONSABILIDAD DEL AUTOR

Yo Mónica Miranda Ari doy fe que el presente Proyecto de Grado ha sido

desarrollado por mi persona, en beneficio de la Empresa Tecnoalimentos Ltda. y que
dicho Proyecto de Grado ha sido medio de Defensa para la conclusión de Estudios de
la Carrera de Informática de la Universidad Mayo de San Andrés.
 ÍNDICE
CAPITULO I
MARCO REFERENCIAL
1.1 INTRODUCCIÓN .................................................................................................. 1
1.2 ANTECEDENTES ................................................................................................. 2
1.2.1 ANTECEDENTES DE LA EMPRESA ............................................................... 2
1.2.2 ANTECEDENTES DE SISTEMAS ANTERIORES .......................................... 3
1.3 PLANTEAMIENTO DEL PROBLEMA ............................................................ 4
1.3.1 PROBLEMA CENTRAL ...................................................................................... 4
1.3.2 PROBLEMAS SECUNDARIOS ......................................................................... 4
1.4 OBJETIVOS ........................................................................................................... 5
1.4.1 OBJETIVO GENERAL ........................................................................................ 5
1.4.2 OBJETIVOS ESPECÍFICOS ................................................................................ 5
1.5 JUSTIFICACIÓN .................................................................................................. 6
1.5.1 JUSTIFICACIÓN TÉCNICA ............................................................................... 6
1.5.2 JUSTIFICACIÓN ECONÓMICA ........................................................................ 6
1.5.3 JUSTIFICACIÓN SOCIAL .................................................................................. 6
1.6 LÍMITES Y ALCANCES ...................................................................................... 7
1.6.1 LÍMITES ................................................................................................................ 7
1.6.2 ALCANCES .......................................................................................................... 7
1.7 METODOLOGÍA .................................................................................................. 8
1.8 HERRAMIENTAS DE DESARROLLO DEL SISTEMA ............................... 9
1.9 APORTES ................................................................................................................ 9

CAPITULO II
MARCO TEÓRICO
2.1 INTRODUCCIÓN ................................................................................................ 11
2.2 INGENIERÍA DE SOFTWARE ........................................................................ 11
2.3 METODOLOGÍA SCRUM ................................................................................ 12
2.3.1 MARCO DE TRABAJO ..................................................................................... 13
2.3.2 EQUIPO DE TRABAJO ..................................................................................... 13
2.3.3 TEORÍA DE SCRUM ......................................................................................... 16
2.3.4 EVENTOS DEL SCRUM ................................................................................... 17
2.3.5 ELEMENTOS DEL SCRUM ............................................................................. 17
2.3.6 FASES DEL SCRUM.......................................................................................... 18
2.4 METODOLOGIA DE DESARROLLO MOBILE-D ..................................... 20
2.4.1 INTRODUCCIÓN AL MODELO ...................................................................... 20
2.4.2 FASES DE LA METODOLOGIA...................................................................... 20
2.5 UML WEB ENGINEERING (UWE)................................................................. 28
2.5.1 INTRODUCCION ............................................................................................... 28
2.5.2 ANÁLISIS DE REQUISITO .............................................................................. 29
2.5.3 MODELO DE CONTENIDO ............................................................................. 30
2.5.4 MODELO DE NAVEGACIÓN .......................................................................... 31
2.5.5 MODELO DE PRESENTACIÓN ...................................................................... 32

i
2.5.6 MODELO DE PROCESO ................................................................................... 33
2.6 HERRAMIENTAS DE DESARROLLO .......................................................... 34
2.6.1 JAVA .................................................................................................................... 34
2.6.2 GENEXUS ........................................................................................................... 36
2.6.3 SQL SERVER 2012............................................................................................. 39
2.7 CALIDAD DEL PRODUCTO ............................................................................ 40
2.7.1 CARACTERÍSTICAS DE CALIDAD INTERNA Y EXTERNA ................... 40
2.7.2 METODOLOGÍA WEBQEM (MÉTODO DE EVALUACIÓN DE CALIDAD
DE LA WEB) ................................................................................................................... 47
2.8 SEGURIDAD ........................................................................................................ 51
2.8.1 OWASP ................................................................................................................ 51

CAPITULO III
MARCO APLICATIVO
3.1 ANÁLISIS DE LA METODOLOGÍA DE DESARROLLO .......................... 58
3.1.1 EXPLORACIÓN ................................................................................................. 58
3.1.2 PLANIFICACIÓN .............................................................................................. 58
3.1.3 EJECUCIÓN ........................................................................................................ 59
3.1.4 RETROALIMENTACIÓN ................................................................................. 59
3.2 SITUACIÓN ACTUAL DE LA INSTITUCIÓN ............................................. 60
3.3 REQUERIMIENTOS MÍNIMOS DE HARDWARE Y SOFTWARE......... 60
3.3.1 HARDWARE ...................................................................................................... 60
3.3.2 SOFTWARE ........................................................................................................ 61
3.4 ARQUITECTURA ............................................................................................... 62
3.5 IMPLEMENTACIÓN DE LA METODOLOGÍA DE DESARROLLO ...... 62
3.5.1 EXPLORACIÓN ................................................................................................. 62
3.5.2 PLANIFICACIÓN .............................................................................................. 64
3.5.3 EJECUCIÓN ........................................................................................................ 69

CAPITULO IV
CONTROL DE CALIDAD
4.1 INTRODUCCIÓN .............................................................................................. 101
4.1.1 DEFINICIÓN DE LAS METAS DE EVALUACIÓN Y SELECCIÓN DE
PERFIL DE USUARIO ................................................................................................ 101
4.1.2 DEFINICIÓN DE LOS REQUERIMIENTOS DE CALIDAD ...................... 102
4.1.3 DEFINICIÓN DE CRITERIOS DE PREFERENCIA ELEMENTALES Y
PROCEDIMIENTOS DE MEDICIÓN ........................................................................ 112
4.1.4 DEFINICIÓN DE ESTRUCTURAS DE AGREGACIÓN Y EVALUACIÓN
GLOBAL ....................................................................................................................... 113
4.1.5 ANÁLISIS DE RESULTADOS Y RECOMENDACIONES ......................... 113

CAPITULO V
SEGURIDAD
5.1 INTRODUCCIÓN .............................................................................................. 114

ii
5.1.1 INYECCIÓN...................................................................................................... 114
5.1.2 PÉRDIDA DE AUTENTICACIÓN Y GESTIÓN DE SESIONES ................ 115
5.1.3 REFERENCIA DIRECTA INSEGURA A OBJETOS.................................... 115
5.1.4 AUSENCIA DE CONTROL DE ACCESO A FUNCIONES ......................... 115
5.1.5 UTILIZACIÓN DE COMPONENTES CON VULNERABILIDADES
CONOCIDAS ................................................................................................................ 116

CAPITULO VI
ANÁLISIS COSTO BENEFICIO
6.1 INTRODUCCIÓN .............................................................................................. 117
6.2 MODOS DE DESARROLLO ........................................................................... 117
6.2.1 MODO ORGÁNICO ......................................................................................... 117
6.2.2 MODO SEMIACOPLADO .............................................................................. 118
6.2.3 MODO EMPOTRADO ..................................................................................... 119
6.3 MODELO BÁSICO............................................................................................ 120
6.3.1 COSTO DE DESARROLLO ............................................................................ 122
6.4 VALOR ACTUAL NETO (VAN)..................................................................... 122
6.5 TASA INTERNA DE RETORNO (TIR) ......................................................... 124

CAPITULO VII
CONCLUSIONES Y RECOMENDACIONES
7.1 CONCLUSIONES .............................................................................................. 126
7.2 RECOMENDACIONES.................................................................................... 126

iii
 ÍNDICE DE FIGURAS

Figura 2.1: Ingeniería de Software 12

Figura 2.2: Esquema de la Metodología 13
Figura 2.3: Esquema de la Metodología 20
Figura 2.4: Modelos UWE 29
Figura 2.5: Casos de Uso 30
Figura 2.6: Modelo de Contenido 31
Figura 2.7: Estereotipos de Estructura de Navegación 31
Figura 2.8: Página de Presentación Inicio 33
Figura 2.9: Estructura del Proceso 34
Figura 2.10: Ciclos Diseño-Prototipo y Diseño-Producción 38
Figura 2.11: Componentes de SQL Server 2012 40
Figura 2.12: Características de calidad Interna y Externa 41
Figura 2.13: Cálculo de entradas de punto de función 44
Figura 2.14: Fases de la metodología WebQem 48
Figura 2.15: Procesos de evaluación 51
Figura 2.16: Modelo SDLC genérico 54
Figura 3.1: Arquitectura propuesta para el sistema 62
Figura 3.2: Tareas realizadas por cada uno de los usuarios 67
Figura 3.3: Diagrama Entidad Relación 68
Figura 3.4: Modelo Físico 69
Figura 3.5: Diagrama casos de uso del registro de parámetros 71
Figura 3.6: Diagrama de clases, especificación de parámetros del sistema 72
Figura 3.7: Diagrama de navegación, especificación de parámetros del
Sistema 73
Figura 3.8: Diseño y autenticación de usuarios 73
Figura 3.9: Diseño del menú de opciones 74
Figura 3.10: Pantalla de asignación de roles a un usuario 74
Figura 3.11: Pantalla de gestión de usuarios 74

iv
Figura 3.12: Pantalla de listado de unidad de medida 75
Figura 3.13: Pantalla de ABM de unidad de medida 75
Figura 3.14: Pantalla de listado de tipo de producto 76
Figura 3.15: Pantalla de ABM de tipo de producto 76
Figura 3.16: Pantalla de ABM de producto 76
Figura 3.17: Pantalla de Registro de plantilla 77
Figura 3.18: Diagrama Casos de Uso que representa la generación de
Pedido 78
Figura 3.19: Diagrama de clases para la generación de pedido 79
Figura 3.20: Diagrama de procesos para la generación de pedido 80
Figura 3.21: Diagrama de navegación, pantallas de generación de pedidos 81
Figura 3.22: Pantalla de Registro de pedido manual 81
Figura 3.23: Pantalla de Control de Pedidos 82
Figura 3.24: Pantalla de Aprobación de Pedido 82
Figura 3.25: Diagrama Casos de Uso, recepción de pedido 83
Figura 3.26: Diagrama Casos de Uso, registro de entrega de pedido 84
Figura 3.27: Diagrama de clases, especificación de recepción y entrega de
Pedido 84
Figura 3.28: Diagrama de proceso para la recepción generación de pedido 85
Figura 3.29: Diagrama de navegación de pantallas de recepción y entrega
de pedido 86
Figura 3.30: Registro de recepción del producto 87
Figura 3.31: Diagrama Casos de Uso Proceso de Devolución 88
Figura 3.32: Diagrama de clases de la especificación devolución de
productos 89
Figura 3.33: Diagrama de procesos para la devolución de productos 89
Figura 3.34: Diagrama de navegación, pantallas de la devolución de
productos 90
Figura 3.35: Generación de la devolución de uno o más productos 91
Figura 3.36: Diagrama Casos de Uso, control de Stock y cierre diario 92

v
Figura 3.37: Diagrama de clases, especificación del control de stock y
cierre diario 94
Figura 3.38: Diagrama de navegación, pantallas de control de Stock y
cierre diario 94
Figura 3.39: Control de stock diario 95
Figura 3.40: Cierre diario 95
Figura 3.41: Diagrama Casos de Uso, reportes disponibles 97
Figura 3.42: Diagrama Casos de Uso, consultas disponibles 97
Figura 3.43: Diagrama de clases que especifican las consultas y reportes
del sistema 98
Figura 3.44: Diagrama de navegación, pantallas de consultas y reportes
del sistema 99
Figura 3.45: Consulta de productos existentes 99
Figura 3.46: Reporte formato .pdf de los productos existentes 100
Figura 5.1: Prueba de sql inyección 114
Figura 5.2: Encriptación de Url 115

vi
 ÍNDICE DE TABLAS
Tabla 3.1: Actores que intervienen el Sistema 63
Tabla 3.2: Pila de Productos 66
Tabla 3.3: Planificación 66
Tabla 3.4: Sprint 1 70
Tabla 3.5: Administración de Usuarios 71
Tabla 3.6: Sprint 2 78
Tabla 3.7: Administración de Pedido 79
Tabla 3.8: Procesos de Pedido 79
Tabla 3.9: Sprint 3 83
Tabla 3.10: Sprint 4 87
Tabla 3.11: Proceso de devolución 88
Tabla 3.12: Sprint 5 92
Tabla 3.13: Administración de Productos 93
Tabla 3.14: Cierre Diario 93
Tabla 3.15: Sprint 6 96
Tabla 4.1: Entradas Externas 102
Tabla 4.2: Salidas Externas 103
Tabla 4.3: Consultas Externas 104
Tabla 4.4: Archivos lógicos internos 104
Tabla 4.5: Archivos de interfaz externos 104
Tabla 4.6: Calculo de entradas de punto de función 105
Tabla 4.7: Rangos para evaluar punto de función 105
Tabla 4.8: Factores de ajustes de valor 106
Tabla 4.9: Rangos para evaluar la usabilidad 107
Tabla 4.10: Cuestionario para la valoración de usabilidad 108
Tabla 4.11: Rangos para evaluar la eficiencia 109
Tabla 4.12: Valoración para la eficiencia 109
Tabla 4.13: Rangos para evaluar el mantenimiento 110
Tabla 4.14: Valoración para el mantenimiento 111

vii
Tabla 4.15: Rangos para evaluar la portabilidad 111
Tabla 4.16: Valoración para el mantenimiento 112
Tabla 4.17: Resultados de las características de calidad 113
Tabla 5.1: Ecuaciones del Modelo Básico de COCOMO 81 121
Tabla 5.2: Flujo de caja neto 123

viii
 CAPITULO I

MARCO REFERENCIAL

1.1 INTRODUCCIÓN

En la actualidad la implementación de tecnologías en las actividades que tiene cada

empresa optimiza y mejora el manejo de la información que se genera, lo cual apoya
al crecimiento y desarrollo de la empresa.

Actualmente la empresa Tecnoalimentos Ltda. se encarga de proveer insumos o

productos procesados para distribuirlos directamente al grupo de clientes como son
(Zumos, Ribera, Saboréate, Golden Foods y Servicios Generales), tiene percances en
cuanto se refiere al manejo de la información de la distribución de los insumos que
produce, aunque en los últimos años se trata de automatizar toda la información que
corresponde a la empresa.

Es por eso que se pretende automatizar toda la información que corresponde a los
productos que tiene la empresa Tecnoalimentos Ltda. con un sistema de información
de Automatización en el Control de la Información de Productos que tiene la
empresa, sistema que permita realizar el registro y control de pedidos, entregas y
devoluciones de productos cuya información permitirá satisfacer al cliente y así poder
tomar una buena decisión en cuanto al manejo de sus productos y además se realizará
una aplicación móvil que será usada directamente por el usuario para realizar el
pedido, la recepción de los productos y devoluciones de los mismos por algún motivo
valido, la aplicación móvil ayudara a tener una información oportuna a tiempo y
eficiente.

En este perfil se presenta una propuesta que permitirá satisfacer al cliente y así poder
tomar una buena decisión.
1.2 ANTECEDENTES

1.2.1 ANTECEDENTES DE LA EMPRESA

La Empresa Tecnoalimentos Ltda. es la empresa principal, la cual se encarga de

comprar insumos para poder procesarlos o distribuirlos directamente a las demás
empresas del grupo como son (Zumos, Ribera, Saboréate, Golden Foods y Servicios
Generales).

Existe siempre la posibilidad de que se puedan incrementar las empresas o proyectos

nuevos, además cabe mencionar que cada una de estas empresas cuenta con
sucursales las cuales también pueden ir incrementando, la necesidad que tiene la
empresa es la de poder automatizar y centralizar toda la información que se genera
para realizar un control eficiente del número de productos que distribuye a las demás
empresas.

Es importante identificar que las empresas (Zumos, Ribera, Saboréate, Golden Foods)
tienen computadoras con sistema operativo Windows en el cual se encuentra
instalado un sistema llamado COIPOS.NET sistema contable que se encarga de:

 Captura automática de todos los datos de Sabre por venta de boletos y

emisión de la nota de débito (factura).
 Gestión y control de las cuentas corrientes de cada cliente, con reportes de
cartera y emisión de estados de cuenta.
 Mantenimiento de una base de datos con toda la información de viajes y
servicios prestados a cada uno de los clientes y toda la información históri ca
de su relación con la empresa.
 Definición de condiciones de venta/crédito para cada cliente y automatizado
el control de su cumplimiento al momento de emitir la nota de débito.
 Registro de cobranzas, anticipos, pre pagos y control de saldos por boleto, por
operación o por nota de débito.

2
1.2.2 ANTECEDENTES DE SISTEMAS ANTERIORES

“Sistema de Compras e Inventarios SAMA”, Este proyecto de grado es un estudio

de la empresa Industrias SAMA, dedicada a la producción de gaseosas, como tal
presenta problemas de administración y gestión de recursos monetarios e industriales,
causados esencialmente por la cantidad de información que se genera a diario.
(Choque, 2009)

“Sistema de Información para Control de Producción y Almacenes - SIPCA”,

Este proyecto de grado surge de la necesidad de automatizar ciertos procesos que se
habían incrementado considerablemente y que cada vez era más complicada su
gestión, esto a raíz de la demanda de los productos ofertados por la compañía.

El desarrollo de la aplicación conlleva todo un proceso de desarrollo de software que

consiste en un conjunto de actividades que permite transformar los requerimientos de
los usuarios en un producto software. (Canqui, 2011)

“Sistema de Gestión y Seguimiento de Información para la Unidad de Almacén de

Materiales de Vidrio”, El Instituto de Investigaciones de la Carrera de Química, es
una entidad pública, actualmente cuenta con un almacén de materiales de vidrio que
ofrece servicios a toda la población estudiantil perteneciente a esta, por esta razón es
imprescindible prever la continuidad de materiales químicos y evitar la interrupción
de las tareas para las cuales son necesarias, la unidad de almacenes trabaja de manera
manual en el registro de inventario, salidas e ingresos de materiales, lo que demora en
los procesos de búsqueda de información y por consiguiente retraso en la emisión de
informes solicitados por la unidad de administración. Es por esta razón que el aporte
principal del presente trabajo es el desarrollo e implementación del sistema de gestión
y seguimiento de información para la unidad de almacén de materiales de vidrio
contribuyendo a un mejor manejo y seguimiento de la información a la encargada del
almacén como a los usuarios que facilite el registro, actualización, control del
movimiento de materiales como ser préstamos y devoluciones, además de tener un
seguimiento de ellos y la obtención de un pronóstico de la cantidad óptima de

3
adquisición de los materiales más necesitado y si se solventa los materiales existentes
en cada gestión, además de controlar el ingreso y salida del material de modo que no
se hagan compras insulsas. (Manueco, 2011)

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 PROBLEMA CENTRAL

¿Cómo mejorar el seguimiento de la entrega de pedidos a los clientes y el manejo de

la información de la Empresa Tecnoalimentos Ltda.?

Se definió el problema principal bajo los siguientes problemas que podemos observar
a continuación.

1.3.2 PROBLEMAS SECUNDARIOS

 Desorganización del cronograma en la entrega de productos, lo que ocasiona

el desabastecimiento a los clientes.
 Datos no confiables de los clientes que realizaron las devoluciones, lo que
ocasiona desinformación de la devolución realizada.
 Devolución de productos sin saber el motivo, la cantidad exacta ni el usuario
que realizo el proceso, por lo que genera pérdidas para la empresa.
 Información a destiempo en cuanto a la cantidad recepcionada, pedida y
devuelta por el cliente, por lo que no se tiene un número exacto del stock
disponible por producto.
 Desinformación sobre el stock que maneja cada cliente para realizar el
abastecimiento correspondiente, lo que ocasiona la existencia de clientes
disconformes ante el desabastecimiento de productos.
 Información de pedidos, entregas y devoluciones de productos escasa y
plasmada únicamente en papel, lo que ocasiona desorganización en la
empresa.

4
 Desorganización de la empresa al momento de recibir un pedido, realizar una
entrega o almacenar una devolución, lo que ocasiona pérdida de ingresos para
la empresa.
(Ver Anexo B: Pagina 140: Árbol de Problemas)

1.4 OBJETIVOS

1.4.1 OBJETIVO GENERAL

Desarrollar un sistema web y aplicación móvil para la Automatización en el Control

de la Información de Productos para la Empresa Tecnoalimentos Ltda., lo cual
permitirá mejorar el control y seguimiento de pedidos, entregas y devoluciones de
productos para satisfacer al cliente con información oportuna y eficiente.

1.4.2 OBJETIVOS ESPECÍFICOS

 Planificar un cronograma que permita tener el control de fechas y estados de

pedidos y entregas de acuerdo a la cantidad mínima que de productos por
sucursal.
 Autenticar usuarios, para poder ingresar al sistema.
 Controlar el número de devoluciones y la cantidad exacta y el motivo por el
cual el usuario realiza la devolución.
 Registrar pedidos, entregas y devoluciones de productos mediante una
aplicación móvil.
 Determinar stocks diarios por sucursal, para realizar el abastecimiento
correspondiente.
 Registrar y controlar las cantidades pedidas y entregadas por producto y
sucursal y así obtener un informe real y a tiempo.
 Generar reportes que le permita a la empresa tener una mejor organización de
los procesos que realiza.

(Ver Anexo B: Pagina 141: Árbol de Objetivos)

5
1.5 JUSTIFICACIÓN

1.5.1 JUSTIFICACIÓN TÉCNICA

La Empresa Tecnoalimentos Ltda., actualmente dispone de un Servidor para su base

de Datos e instalación de otras herramientas y computadoras que tienen sistema
operativo Windows las cuales serán reutilizadas y facilitaran la implementación del
sistema, además cabe mencionar que disponen de tablet’s las cuales cuentan con
sistema operativo Android que tiene soporte desde la versión 4.3 donde se accederá a
la aplicación móvil.

1.5.2 JUSTIFICACIÓN ECONÓMICA

El sistema y la aplicación móvil permitirán que la empresa optimice el control que se

debe realizar, el cual consiste en la distribución de productos que realiza la Empresa,
de esta manera se evitara pérdidas en cuanto se refiere a la entrega y retiro de
productos, lo que ocasiona pérdidas económicas para la empresa.

También se requiere de computadoras, tablet`s y un servidor con el cual ya cuenta la

Empresa, como se puede observar el costo será mínimo para la implementación del
sistema.

1.5.3 JUSTIFICACIÓN SOCIAL

Se pretende facilitar el trabajo del personal de la Empresa Tecnoalimentos Ltda y a la

vez del personal de los clientes con un registro intuitivo y fácil de usar tanto para el
sistema y la aplicación móvil, de esa manera reducir el tiempo de los procesos que
implican el registro de pedidos, entregas o devoluciones de productos.

También evitar demoras en cuanto la entrega de pedidos ya que muchas veces un

determinado cliente puede tener varios proveedores y la recepción debería ser lo
más corta posible en cuanto a tiempo se refiere.

6
1.6 LÍMITES Y ALCANCES

1.6.1 LÍMITES

Los límites del Sistema y Aplicación Móvil se describen a continuación:

 No se Garantiza la satisfacción del cliente, ante un posible mal uso del

sistema o aplicación móvil.
 No controlara el desabastecimiento de productos, por problemas en el proceso
de elaboración.
 El sistema y la aplicación móvil no será responsable de las pérdidas
económicas por productos vencidos o en mal estado.
 El control de Disponibilidad de stock por producto, se realizara siempre y
cuando el usuario registre las ventas y devoluciones realizadas.

1.6.2 ALCANCES

Los Alcances del Sistema Web y la Aplicación Móvil de acuerdo a los módulos con
los que cuenta son los que se describen a continuación:

 Facilitar y minimizar el proceso de registro y control para el personal que

estará a cargo del sistema por lo cual se implementará los siguientes módulos:
 Módulo de Registro: Encargado de realizar el registro de la
información necesaria para realizar un pedido, una entrega o una
devolución de un producto.
 Módulo de Procesos: Sera encargado de realizar los pedidos,
entregas y devoluciones de productos de acuerdo a la información que
será registrada en el módulo de registro.
 Módulo de Reportes. Sera el encargado de generar reportes que
permitan al usuario tener una información real de sus productos.

7
  Aplicación Móvil: Sera desarrollado para realizar un pedido, una
recepción de productos y también para registrar una devolución debido
a algún motivo valido.

1.7 METODOLOGÍA

Para realizar el perfil de proyecto de grado se utilizó arboles analíticos, marco lógico
además de aplicar el método científico como afirma (Hernández, 2006)

Se utilizara las siguientes metodologías:

Para el desarrollo del sistema web se usara la metodología Scrum.

Scrum es un modelo de desarrollo ágil caracterizado por:

 Adoptar una estrategia de desarrollo incremental, en lugar de la planificación

y ejecución completa del producto.
 Basar la calidad del resultado más en el conocimiento tácito de las personas
en equipos auto organizados, que en la calidad de los procesos empleados.
 Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una
tras otra en un ciclo secuencial o de cascada. (Palacio, 2014)

Para el desarrollo de la aplicación móvil se utilizara la metodología Mobile-D.

Mobile-D es un Enfoque Ágil para el desarrollo que se caracteriza por:

 Conseguir ciclos de desarrollos muy rápidos en equipos muy pequeños (de no

más de diez desarrolladores).
 Conseguir productos totalmente funcionales en menos de diez semanas.
(Ramírez, 2012).

Para el desarrollo de la documentación se utilizara UWE.

8
1.8 HERRAMIENTAS DE DESARROLLO DEL SISTEMA

Las herramientas para la implementación del sistema que se van a utilizar serán las
siguientes:

Para el desarrollo de la documentación:

 Edraw Max v.7.9: Herramienta para el diseño de diagramas UML.

Para el desarrollo del Software:

 Sistema Operativo Windows

 Gestor de Base de Datos Sql Server 2012.
 Java con Herramienta Case Genexus aplicando Api WorkWithPlus.
 Sistema Móvil: Api Work With for Smart Devices, Gestor de Base de Datos
SqlLite.

1.9 APORTES

Los aportes del Sistema que proveerá será la automatización de los procesos
manuales en el registro, control y obtención de información, los cuales minimizaran y
optimizaran los tiempos de ejecución los cuales ayudaran a la toma de decisiones.

 El personal a cargo del sistema dispondrá de una herramienta automatizada

que cubrirá los requerimientos realizados, para llevar a cabo un óptimo
control de la información de los productos con los que cuenta.
 La empresa Tecnoalimentos Ltda., tendrá una información inmediata gracias
a la aplicación móvil que será capaz de enviar los datos necesarios
directamente a la central.
 El módulo de devoluciones permitirá tener un número exacto de cuantos
productos se devolvieron para ver si cuadra con la cantidad que dispone cada
cliente.

9
 Reportes que emitirá el Sistema con Información correcta que ayude al
gerente en la toma de decisiones.

10
 CAPITULO II

MARCO TEÓRICO

2.1 INTRODUCCIÓN

En este Capítulo se va a desarrollar la teoría de la metodología que va a fundamentar

el proyecto en base al planteamiento del problema que se ha realizado, buscando las
fuentes, documentales que permitan detectar, extraer y recopilar la información de
interés.

2.2 INGENIERÍA DE SOFTWARE

La ingeniería de software es una tecnología con varias capas. Como se aprecia en la

figura 2.1, cualquier enfoque de ingeniería (incluso la de software) debe basarse en un
compromiso organizacional con la calidad. La administración total de la calidad, Six
Sigma y otras filosofías similares alimentan la cultura de mejora continua, y es esta
cultura la que lleva en última instancia al desarrollo de enfoques cada vez más
eficaces de la ingeniería de software. El fundamento en el que se apoya la ingeniería
de software es el compromiso con la calidad. El fundamento para la ingeniería de
software es la capa proceso. El proceso de ingeniería de software es el aglutinante que
une las capas de la tecnología y permite el desarrollo racional y oportuno del software
de cómputo. El proceso define una estructura que debe establecerse para la obtención
eficaz de tecnología de ingeniería de software.

El proceso de software forma la base para el control de la administración de

proyectos de software, y establece el contexto en el que se aplican métodos técnicos,
se generan productos del trabajo (modelos, documentos, datos, reportes, formatos), se
establecen puntos de referencia, se asegura la calidad y se administra el cambio de
manera apropiada. Los métodos de la ingeniería de software proporcionan la
experiencia técnica para elaborar software. Incluyen un conjunto amplio de tareas,

11
como comunicación, análisis de los requerimientos, modelación del diseño,
construcción del programa, pruebas y apoyo.

Los métodos de la ingeniería de software se basan en un conjunto de principios

fundamentales que gobiernan cada área de la tecnología e incluyen actividades de
modelación y otras técnicas descriptivas. Las herramientas de la ingeniería de
software proporcionan un apoyo automatizado o semiautomatizado para el proceso y
los métodos. Cuando se integran las herramientas de modo que la información creada
por una pueda ser utilizada por otra, queda establecido un sistema llamado ingeniería
de software asistido por computadora que apoya el desarrollo de software.
(Pressman, 2010)

Figura 2.1: Ingeniería de Software

Fuente: [Pressman, 2010]

2.3 METODOLOGÍA SCRUM

Es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de

productos complejos desde principios de los años 90. Scrum no es un proceso o una
técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del
cual se emplean varias técnicas y procesos. Scrum muestra la eficacia relativa de las
prácticas de gestión de producto y las prácticas de desarrollo, de modo que podamos
mejorar. (Schwaber & Sutherland, 2013)

Se basa en el principio ágil de desarrollo iterativo e incremental. Al período de

trabajo para desarrollar un incremento de producto se lo denomina “sprint”, y se

12
recomiendan duraciones entre una y cuatro semanas, si bien pueden contemplarse
casos de hasta 60 días. (Palacio & Ruata, 2011)

2.3.1 MARCO DE TRABAJO

El marco de trabajo SCRUM consiste en los Equipos SCRUM y en sus roles, eventos,
artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un
propósito específico y es esencial para el éxito de SCRUM y para su uso.

Las reglas de SCRUM vinculan a los eventos, roles y artefactos, rigiendo las
relaciones e interacciones entre ellos. En la figura 2.2 se muestra los procesos de
Scrum de forma simplificada para su ejecución.

Figura 2.2: Esquema de la Metodología

Fuente: [Juan Palacio, 2006]

2.3.2 EQUIPO DE TRABAJO

El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de

Desarrollo (Development Team), y un Scrum Master. Los Equipos Scrum son auto-
organizados y multifuncionales. Los equipos auto-organizados eligen la mejor forma
de llevar a cabo su trabajo, en lugar de ser dirigidos por otros externos al equipo. Los
equipos multifuncionales tienen todas las competencias necesarias para llevar a cabo
el trabajo sin depender de otros que no son parte del equipo. El modelo de equipo en

13
SCRUM está diseñado para optimizar la flexibilidad, la creatividad y la
productividad.

2.3.2.1 DUEÑO DEL PRODUCTO

Es el responsable de maximizar el valor del producto y del trabajo del Equipo de
Desarrollo. El cómo se lleva esto a cabo varia ampliamente entre distintas
organizaciones, Equipos Scrum, e individuos. El Dueño de Producto es la única
persona responsable de gestionar la Pila de Producto (Product Backlog).

2.3.2.2 EQUIPO DE DESARROLLO

Consiste en los profesionales que desempeñan el trabajo de entregar un Incremento
de producto “Hecho”, potencialmente utilizable, al final de cada Sprint. Sólo los
miembros del Equipo de Desarrollo participan en la creación del Incremento. Los
Equipos de Desarrollo se estructuran y reciben poderes por parte de la organización
para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la
eficiencia y efectividad general del Equipo de Desarrollo. Los Equipos de Desarrollo
tienen las siguientes características:

 Son auto-organizados. Nadie (ni siquiera el Scrum Master) indica al Equipo

de Desarrollo cómo convertir elementos de la Pila de Producto en
Incrementos de funcionalidad potencialmente entregables.
 Los Equipos de Desarrollo son multifuncionales, contando como equipo con
todas las habilidades necesarias para crear un Incremento de pr oducto.
 SCRUM no reconoce títulos para los miembros de un Equipo de Desarrollo,
todos son Desarrolladores. Independientemente del trabajo que realice cada
persona, no hay excepciones a esta regla.

2.3.2.3 SCRUM MASTER

Es el responsable de asegurar que Scrum es entendido y llevado a cabo. Los Scrum
Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la
teoría, prácticas y reglas de Scrum. El Scrum Master es un líder servil, al servicio del
Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a

14
entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El
Scrum Master ayuda a todos a modificar estas interacciones, para maximizar el valor
creado por el Equipo Scrum, como ser:
a) Al Dueño de Producto
 Encontrar técnicas para gestionar la Pila de Producto de manera efectiva.
 Comunicar claramente la visión, los objetivos y los elementos de la Pila de
Producto al Equipo de Desarrollo.
 Enseñar al Equipo Scrum a crear elementos de la Pila de Producto claros y
concisos.
 Entender la planificación a largo plazo del producto en un entorno empírico.
 Entender y practicar la agilidad.
 Facilitar los eventos de Scrum según se requiera o necesite.

b) Al Equipo de Desarrollo
 Entrenar al Equipo de Desarrollo en ser auto organizado y multifuncional.
 Formar y liderar al Equipo de Desarrollo en la creación de productos de alto
valor.
 Eliminar impedimentos al progreso del Equipo de Desarrollo.
 Facilitar los eventos de Scrum según se requiera o necesite.
 Entrenar al Equipo de Desarrollo en el entorno de organizaciones en las que
Scrum aún no ha sido adoptado y entendido por completo.
c) A la organización
 Liderar y entrenar a la organización en su adopción de Scrum.
 Planificar implementaciones de Scrum en la organización.
 Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el
desarrollo empírico de producto.

15
  Causar cambios que incrementen la productividad del Equipo Scrum.

 Trabajar con otros Scrum Masters para incrementar la efectividad de la

aplicación de Scrum en la organización.

2.3.3 TEORÍA DE SCRUM

Scrum se basa en la teoría de control de procesos empírica o empirismo. El

empirismo asegura que el conocimiento procede de la experiencia y de tomar
decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e
incremental para optimizar la predictibilidad y el control del riesgo.

Tres pilares soportan toda la implementación del control de procesos empírico:

transparencia, inspección y adaptación.

2.3.3.1 TRANSPARENCIA
Los aspectos significativos del proceso deben ser visibles para aquellos que son
responsables del resultado. La transparencia requiere que dichos aspectos sean
definidos por un estándar común, de tal modo que los observadores compartan un
entendimiento común de lo que se está viendo.

2.3.3.2 INSPECCIÓN
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de scrum y
el progreso hacia un objetivo, para detectar variaciones. Su inspección no debe ser tan
frecuente como para que interfiera en el trabajo. Las inspecciones son más
beneficiosas cuando se realizan de forma diligente por inspectores expertos, en el
mismo lugar de trabajo.

2.3.3.3 ADAPTACIÓN
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites
aceptables, y que el producto resultante no será aceptable, el proceso o el material que
está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes
para minimizar desviaciones mayores.

16
2.3.4 EVENTOS DEL SCRUM

En Scrum existen eventos predefinidos con el fin de crear regularidad y minimizar la

necesidad de reuniones no definidas en Scrum. Todos los eventos son bloques de
tiempo (time-boxes), de tal modo que todos tienen una duración máxima. Una vez
que comienza un Sprint, su duración es fija y no debe acortarse o alargarse. Los
demás eventos deben terminar siempre que se alcance el objetivo del evento,
asegurando que se emplee una cantidad apropiada de tiempo sin permitir desperdicio
en el proceso.

El Sprint es un bloque de tiempo (time-box) de un mes o menos durante el cual se

crea un incremento de producto “Terminado”, utilizable y potencialmente
desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo
del esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de
la finalización del Sprint previo. Durante el Sprint:

 No se realizan cambios que puedan afectar al Objetivo del Sprint.

 Los objetivos de calidad no disminuyen.
 El alcance debe ser clarificado y renegociado entre el Dueño de Producto y el
Equipo de Desarrollo a medida que se va aprendiendo más.

Cada Sprint se considera como un proyecto con un horizonte no mayor de un mes. Al

igual que los proyectos, los Sprints se usan para lograr algo. Cada Sprint tiene una
definición de qué se va a construir, un diseño y un plan flexible que guiará la
construcción y el trabajo y el producto resultante.

2.3.5 ELEMENTOS DEL SCRUM

2.3.5.1 PRODUCT BACKLOG (LISTA DE PRODUCTO)

Es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única
fuente de requisitos para cualquier cambio a realizarse en el producto. Una Lista de
Producto nunca está completa. El desarrollo más temprano de la misma solo refleja
los requisitos conocidos y mejor entendidos al principio. La Lista de Producto

17
enumera todas las características, funcionalidades, requisitos, mejoras y correcciones
que constituyen cambios a ser hechos sobre el producto para entregas futuras.

Sprint Backlog: es la lista de tareas qué elabora el equipo durante la planificación de

un Sprint. Se asignan las tareas a cada persona y el tiempo qué queda terminarlas. De
esta manera el proyecto se descompone en unidades más pequeñas y se determinar o
ver tareas que no se está avanzando e intentar eliminar el problema.

2.3.5.2 INCREMENTO
Representa los requisitos qué se han completado qué se han en una iteración y qué
son perfectamente operativos. Según los resultados qué se obtengan, el cliente puede
ir haciendo los cambios necesarios y replanteando el proyecto. El Incremento es la
suma de todos los elementos de la Lista de Producto completados durante un Sprint y
el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint, el
nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones
de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum. El
incremento debe estar en condiciones de utilizarse sin importar si el Dueño de
Producto decide liberarlo o no.

2.3.6 FASES DEL SCRUM

Según la descripción que realiza (Schwaber & Beedle, 2001), Scrum se estructura en
tres fases.

2.3.6.1 PRE-GAME
Antes de empezar con el proyecto se deben especificar las tareas que se van a realizar
en las iteraciones y sus prioridades ya qué la arquitectura del Sistema en esta fase es
importante para el apoyo del contexto y necesidades del nuevo software. Las tareas
que se realizan en esta primera fase son:

 Recopilación de requerimientos para conformar el Product Backlog.

 Definición de las fechas de entrega de los Sprint y sus funcionalidades.
 Análisis de riesgo y controles apropiados para los riesgos.

18
 Selección de las herramientas y de la infraestructura de desarrollo.
 Cálculo o estimación del costo de cada iteración.

2.3.6.2 GAME
En esta fase el producto va evolucionando con el desarrollo de los sprints. Durante
esta fase de desarrollan las siguientes tareas:

a) PLANEACIÓN DE SPRINT

Antes de comenzar un Sprint, se lleva a cabo dos reuniones consecutivas, en la

primera se clarifica y se prioriza nuevamente el Product Backlog del producto. En la
segunda reunión se deben considerar como alcanzar los requerimientos y crear el
Backlog del Sprint.

b) DESARROLLO DEL SPRINT

El trabajo se organiza en iteraciones en no más de 30 días. El Sprint es el desarrollo

de la nueva funcionalidad del producto. Esta fase provee la siguiente documentación:
el Sprint Backlog, los responsables y la duración de cada actividad.

c) REVISIÓN DEL SPRINT

Al final de cada iteración se lleva cabo una reunión de revisión en donde se
presenta la nueva funcionalidad del producto, diseño, ventajas, inconvenientes y
esfuerzos del equipo.

2.3.6.3 POST-GAME
Luego de haber culminado todas las iteraciones, resta la revisión final, denominado
Cierre. El cierre, es la última etapa en la que se realiza la preparación operacional,
incluyendo las pruebas y documentación final. (Schwaber & Sutherland, 2013)

19
2.4 METODOLOGIA DE DESARROLLO MOBILE-D

2.4.1 INTRODUCCIÓN AL MODELO

Se trata de método basado en soluciones conocidas y consolidadas: Extreme

Programming (XP), Crystal Methodologies y Rational Unified Process (RUP), XP
para las prácticas de desarrollo, Crystal para escalar los métodos y RUP como base en
el diseño del ciclo de vida. (Ramírez, 2012)

2.4.2 FASES DE LA METODOLOGIA

La metodología cuenta con 5 fases como se observa en la figura 2.3, por las cuales
pasa el producto a realizarse, la línea de producción empieza con la fase de
exploración, después pasa a la fase de Inicialización, luego pasa a la fase de producto
posteriormente a la fase de estabilización y la fase de pruebas.

Figura 2.3: Esquema de la Metodología

Fuente: [Ramírez, 2012]

20
2.4.2.1 EXPLORACIÓN

Se centra la atención a la planificación y a los conceptos básicos del proyecto. Se

realizan los alcances del proyecto y su establecimiento con las funcionalidades donde
se va a llegar.

El propósito de esta fase es la planificación y establecimiento de una buena

planificación, esta fase es muy importante para establecer las bases para una
implementación bien controlada de software, la arquitectura del producto, el proceso
de desarrollo y la selección del medio ambiente.

Se necesita diferentes grupos diferentes puntos de vista de partes interesadas en el

producto para ofrecer una mejor experiencia en la fase de exploración.

Los objetivos de la fase de exploración son:

 Establecer los grupos de actores necesarios en la planificación y el

seguimiento del proyecto de desarrollo de software.
 Definir los alcances y límites del proyecto de desarrollo de software.
 Planificar el proyecto respecto al entorno, el personal y los problemas del
proceso.

Las entradas de la fase de exploración son:

 La propuesta del producto.

 Biblioteca de procesos de Mobile D.
 Contrato.
 Documento de requisitos iniciales.
 Normas y restricciones en caso de que existan.
Las salidas de esta fase son:
 El documento de requisitos iniciales donde se ha definido los requerimientos
iniciales del desarrollo del producto.

21
 Plan de proyecto incluyendo línea de tiempo, el ritmo, las t erminaciones, los
recursos del proyecto, los actores y sus responsabilidades.
 Descripción base del proceso que incluye la línea de base, las actividades de
seguimiento de calidad, documentación, puntos de integración el hardware a
llegar las salidas.
 Plan de Medición y plan de Formación., descripción de la línea de la
arquitectura.

Las funciones del proyecto en la etapa de exploración son:

 Equipo del proyecto.

 Grupo de apoyo.
 Grupo del cliente y el cliente.
 Grupo directivo.
 Grupo de exploración.

2.4.2.2 INICIALIZACIÓN

En la inicialización se configura el proyecto y se preparan todos los recursos

necesarios, se le dedica un día a la planificación y el resto al trabajo y publicación.

El propósito de esta fase es permitir el éxito de las siguientes fases del proyecto
mediante la preparación y verificación de todas las cuestiones fundamentales del
desarrollo a fin de que todos estén en plena disposición de la aplicación de los
requisitos seleccionados por el cliente. Los objetivos de esta fase son:

 Obtener una buena compresión global del producto para el equipo de

desarrollo del proyecto, sobre los requisitos iniciales y la línea de la
arquitectura.
 Preparar los requisitos físicos, técnicos y humanos, así como la comunicación
con el cliente, los planes del proyecto y todas las cuestiones fundamentales de
desarrollo a fin de que todo esté en plena disposición para la implementación.

22
 Las entradas de esta fase son:

 Documento de requisitos Iniciales.

 Plan de proyecto y descripción del proceso base.
 Plan de medición y plan de formación.
 Descripción de la línea de arquitectura.

Las salidas de la fase son:

 Plan de proyecto actualizado.

 La 1ra versión del diseño de software.
 Documento con descripción del diseño.
 Funcionalidad implementada.
 Documento de requisitos iniciales actualizados.
 Desarrollo de notas y la interfaz de usuario.
 Ilustración de cada requisito.
 Pruebas aceptadas de cada requisito.

En la etapa de iniciación los roles son los siguientes:

 Grupo del proyecto.

 Jefe del proyecto.
 Arquitectos del proyecto.
 Grupo de apoyo.
 Grupo del cliente.

2.4.2.3 PRODUCTO

Antes de iniciar el desarrollo de una funcionalidad debe existir una prueba que
verifique su funcionamiento, en esta fase se lleva a cabo toda la implementación de
los módulos.

23
El propósito en la fase de producción es implementar la funcionalidad requerida en el
producto mediante la aplicación del ciclo de desarrollo iterativo e incremental.

Los objetivos de esta fase son:

 Implementar la funcionalidad del producto priorizando los requerimientos del

cliente.
 Centrarse en la funcionalidad básica fundamental para permitir múltiples
ciclos de mejora.

Las entradas de esta fase son:

 Actualizado plan de proyecto y plan de la línea de la arquitectura.

 La 1ra versión de la arquitectura de software y descripción del diseño.
 Planes para la comprobación de los elementos críticos del desarrollo.
 Funcionalidad implementada.
 Métrica de datos.
 Experiencia del equipo de proyecto.
 Historia y tarjetas de tareas.
 Datos sobre los recursos gastados.
 Manuales, especificaciones API y material de apoyo.
 Pruebas unitarias.

Después de cada Iteración la entrada de la siguiente es:

 Los resultados de la iteración anterior.

Los elementos de salida de esta fase son:

 Funcionalidad Implementada.
 Documento de aceptación de pruebas.
 Notas de desarrollo.
 Ilustraciones de Interfaz de Usuario.

24
 Lista de puntos de acción.
 Actualizado plan del proyecto.
 Historia y tarjetas de tareas.
 Conocimiento de los requisitos del sistema y pruebas de aceptación.
 Lista de defectos.
 Documento de requisitos iniciales.
 Informe de estado diario.

La fase de producto usa los mismos roles que las anteriores fases, sin embargo, la
comunicación con el cliente se debe enfatizar con retroalimentación rápida durante la
ejecución de esta fase para lograr resultados satisfactorios. Los roles son:

 Equipo del proyecto.

 Grupo de apoyo.
 Grupo del cliente.
 Grupo directivo.

2.4.2.4 ESTABILIZACIÓN

En esta fase se llega la integración para vincular los módulos separados en una única
aplicación.

El propósito de la fase de estabilización es asegurar la calidad de la implementación

del proyecto.

Los objetivos de la fase de estabilización son:

 Finalizar la implementación del producto.

 Mejorar y garantizar la calidad del producto.
 Finalizar la documentación del proyecto.

Las entradas de la fase de estabilización son:

25
 La funcionalidad implementada del producto.
 Los artefactos de desarrollo relacionado.

Las salidas de esta fase son:

 La funcionalidad implementada de todo el proyecto de todo el software.

 La documentación del producto finalizado.

En la fase de estabilización se tiene las siguientes funciones o roles del equipo de

trabajo:

 Equipo del proyecto.

 Jefe del proyecto.
 Arquitectos del proyecto.
 Grupo de apoyo.
 Grupo del cliente.
 Grupo directivo.

2.4.2.5 PRUEBAS

Se pasa al testeo hasta tener una versión estable del producto según lo establecido por
el cliente. Si es necesario se reparan errores pero no se desarrolla nada nuevo. Una
vez terminado todas las fases se debería contar con una aplicación publicable y
entregable al cliente.

El propósito de la fase de pruebas es ver si el sistema productor implementa la

funcionalidad definida del cliente correctamente, proporcionar la retroalimentación al
equipo de desarrollo de los defectos y errores encontrados en la funcionalidad del
software para ser corregidos estos defectos encontrados.

Los objetivos de la fase de pruebas son:

 Probar el sistema basado en la documentación producida en el proyecto.

26
 Proporcionar información de defectos encontrados.
 Planificar la solución a los defectos encontrados.
 Fijar los errores hallados.
 Producir un sistema libre de errores como sea posible.

Las entradas de esta fase son las siguientes:

 La funcionalidad implementada.
 Documentación de aceptación de pruebas.
 Funcionalidad del usuario definida completamente.
 Descripción de la interfaz de usuario que se utiliza para crear casos de
pruebas.

Las salidas de la fase de pruebas son:

 Un sistema testeado y corregido (versión final).

 Documentación de errores encontrados.
 Informe de pruebas del sistema descripción del proceso de pruebas y los
errores y defectos encontrados en el software.
 Registro de pruebas realizados en el sistema y los resultados obtenidos al
momento de ejecutar el testeo.

En la última etapa, en la fase de prueba se tiene los siguientes roles:

 Equipo del proyecto.

 Grupo de soporte.
 Cliente.
 Grupo directivo.
 Grupo de pruebas del sistema. (Ramírez, 2012)

27
2.5 UML WEB ENGINEERING (UWE)

2.5.1 INTRODUCCION

UWE es una metodología que permite especificar de mejor manera una aplicación
Web en su proceso de creación mantiene una notación estándar basada en el uso de
UM para sus modelos y sus métodos, lo que facilita la transición.

La metodología define claramente la construcción de cada uno de los elementos del

modelo.

En su implementación se deben contemplar las siguientes etapas y modelos:

 Análisis de requisitos. Plasma los requisitos funcionales de la aplicación Web

mediante un modelo de casos de uso.
 Modelo de contenido. Define, mediante un diagrama de clases, los conceptos
a detalle involucrados en la aplicación.
 Modelo de navegación. Representa la navegación de los objetos dentro de la
aplicación y un conjunto de estructuras como son índices, menús y consultas.
 Modelo de presentación. Representa las interfaces de usuario por medio de
vistas abstractas.
 Modelo de proceso. Representa el aspecto que tienen las actividades que se
conectan con cada clase de proceso.

Como se hace notar, UWE provee diferentes modelos que permite describir una
aplicación Web desde varios puntos de vista abstractos, dichos modelos están
relacionados tal como se ilustra en la figura 2.4.

Cada uno de estos modelos se representa como paquetes UML, dichos paquetes son
procesos relacionados que pueden ser refinados en iteraciones sucesivas durante el
desarrollo del UWE.

28
 Figura 2.4: Modelos UWE
Fuente: [Guerrero, 2014]

2.5.2 ANÁLISIS DE REQUISITO

Una de las primeras actividades en la construcción de aplicaciones Web es la

identificación de los requisitos, y en UWE se especifican mediante el modelo de
requerimientos, que involucra el modelado de casos de uso con UML.

El diagrama de casos de uso está conformado por los elementos actor y caso de uso.
Los actores se utilizan para modelar los usuarios de la aplicación Web que para este
caso de estudio son los diferentes tipos de usuarios (anónimo, consultor, tutor,
alumno) que pueden interactuar con el mismo.

Los casos de uso se utilizan para visualizar las diferentes funcionalidades que la
aplicación tiene que proporcionar, como son: crear a un nuevo usuario, identificar al
usuario, realizar una búsqueda, realizar la composición de un nuevo objeto y guardar
el objeto compuesto En la figura 2.5 se ilustra el diagrama de casos de usos.

29
Es de mencionar que para cada etapa del modelado, UWE provee diferentes
estereotipos. La lista de todos los estereotipos que pueden utilizarse en esta etapa se
encuentra el Perfil UWE.

Figura 2.5: Casos de Uso

Fuente: [Guerrero, 2014]

2.5.3 MODELO DE CONTENIDO

El objetivo del modelo de contenido es proporcionar una especificación visual de la

información en el dominio relevante para la aplicación Web.

Este es un diagrama UML normal de clases, por ello se debe pensar en las clases que
son necesarias para el caso de estudio presentado.

En la figura 2.6 se presenta el diagrama de clases para el modelo de contenido. En

particular, la información de los usuarios es modelada por la clase "Perfil Usuario"
donde se almacenan las propiedades que describen a los diferentes tipos de usuarios.

30
 Figura 2.6: Modelo de Contenido
Fuente: [Guerrero, 2014]

2.5.4 MODELO DE NAVEGACIÓN

En una aplicación para la Web es útil saber cómo están enlazadas las páginas.
Aquello significa que se requiere un diagrama de navegación con nodos y enlaces.
Este diagrama se modela con base en el análisis de los requisitos y el modelo de
contenido.

UWE provee diferentes estereotipos para el modelado de navegación, en la figura 2.7

se presentan los usados en este caso de estudio y seguidamente se da una descripción
de cada uno de ellos.

Figura 2.7: Estereotipos de Estructura de Navegación

Fuente: [Guerrero, 2014]

31
Las clases de navegación («navigationClass») representan nodos navegables de la
estructura de hipertexto; los enlaces de navegación («navigationLink») muestran
vínculos directos entre las clases de navegación; las rutas alternativas de navegación
son manejadas por menú («menu»).Los accesos se utilizan para llegar a múltiples
instancias de una clase de navegación («index» o « guidedTour») o para seleccionar
los elementos («query»). Las clases de procesos («processClass») forman los puntos
de entrada y salida de los procesos de negocio en este modelado y la vinculación
entre sí y a las clases de navegación se modela por enlaces de procesos
(«processLink»).

2.5.5 MODELO DE PRESENTACIÓN

El modelo de presentación ofrece una visión abstracta de la interfaz de usuario de una

aplicación Web. Se basa en el modelo de navegación y en los aspectos concretos de la
interfaz de usuario (IU). Describe la estructura básica de la IU, es decir, ¿qué
elementos de interfaz de usuario (por ejemplo, texto, imágenes, enlaces, formularios)
se utilizan para presentar los nodos de navegación?.

Su ventaja es que es independiente de las técnicas actuales que se utilizan para

implementar un sitio Web, lo que permite a las partes interesadas discutir la
conveniencia de la presentación antes de que realmente se aplique.

Una clase de presentación está compuesta de elementos de IU como texto («text»),

enlaces («anchor»), botones («button»), imágenes («image»), formularios («form») y
colecciones de enlaces («anchored collection.

En la figura 2.8 se modela la página de presentación "PaginaInicio". Existe una

representación de texto para el encabezado y un mensaje de presentación. Modela
también un formulario de entrada para que el usuario introduzca clave y contraseña,
así como los botones de "iniciarperfil" y "registrarPerfil".

32
 Figura 2.8: Página de Presentación Inicio
Fuente: [Guerrero, 2014]

2.5.6 MODELO DE PROCESO

La estructura de navegación puede ser extendida mediante clases de procesos que

representan la entrada y la salida de procesos de negocio. El modelo del proceso
representa el aspecto que tienen las acciones de las clases de proceso. En este modelo
se tienen dos tipos de modelos:

2.5.6.1 MODELO DE ESTRUCTURA DEL PROCESO

Que describe las relaciones entre las diferentes clases de proceso.

Es representado por un diagrama de clases donde se describen las relaciones entre las
diferentes clases de proceso. En la Figura 2.9 podemos observar la aplicación del
modelo.

2.5.6.2 MODELO DE FLUJO DEL PROCESO

Que específica las actividades conectadas con cada «processClass».

33
Siguiendo el principio de la utilización de UML se han refinado los requisitos con los
diagramas de actividad UML. Los diagramas de actividades incluyen actividades,
actores responsables de estas actividades (opcional) y elementos de flujo de control.
Ellos pueden ser enriquecidos con flujos de objetos que muestran objetos relevantes
para la entrada o salida de esas actividades. (Guerrero, 2014)

Figura 2.9: Estructura del Proceso

Fuente: [Guerrero, 2014]

2.6 HERRAMIENTAS DE DESARROLLO

2.6.1 JAVA

La principal característica de Java es la de ser un lenguaje compilado e interpretado.

Todo programa en Java ha de compilarse y el código que se genera bytecodes es
interpretado por una máquina virtual. De este modo se consigue la independencia de
la máquina, el código compilado se ejecuta en máquinas virtuales que si son
dependientes de la plataforma.

34
En el diseño de Java se prestó especial atención a la seguridad. Existen varios niveles
de seguridad en Java, desde el ámbito del programador, hasta el ámbito de la
ejecución en la máquina virtual.

Con respecto al programador, Java realiza comprobación estricta de tipos durante la

compilación, evitando con ello problemas tales como el desbordamiento de la pila.
Pero, es durante la ejecución donde se encuentra el método adecuado según el tipo de
la clase receptora del mensaje; aunque siempre es posible forzar un enlace estático
declarando un método como final.

Todas las instancias de una clase se crean con el operador new(), de manera que un
recolector de basura se encarga de liberar la memoria ocupada por los objetos que ya
no están referenciados. La máquina virtual de Java gestiona la memoria
dinámicamente.

Una fuente común de errores en programación proviene del uso de punteros. En Java
se han eliminado los punteros, el acceso a las instancias de clase se hace a través de
referencias.

Además, el programador siempre está obligado a tratar las posibles excepciones que
se produzcan en tiempo de ejecución. Java define procedimientos para tratar estos
errores.

Java también posee mecanismos para garantizar la seguridad durante la ejecución

comprobando, antes de ejecutar código, que este no viola ninguna restricción de
seguridad del sistema donde se va a ejecutar.

También cuenta con un cargador de clases, de modo que todas las clases cargadas a
través de la red tienen su propio espacio de nombres para no interferir con las clases
locales.

Otra característica de Java es que está preparado para la programación concurrente

sin necesidad de utilizar ningún tipo de biblioteca.

35
Finalmente, Java posee un gestor de seguridad con el que poder restringir el acceso a
los recursos del sistema.

A menudo se argumenta que Java es un lenguaje lento porque debe interpretar los
bytecodes a código nativo antes de poder ejecutar un método, pero gracias a la
tecnología JIT, este proceso se lleva a cabo una única vez, después el código en
código nativo se almacena de tal modo que está disponible para la siguiente vez que
se llame. (Belmonte, 2005)

2.6.2 GENEXUS

Genexus es una herramienta inteligente, desarrollada por Artech, cuyo objetivo es

asistir al analista y a los usuarios en todo el ciclo de vida de las aplicaciones.

La idea básica de Genexus es automatizar todo aquello que es automatizable:

normalización de los datos y diseño, generación y mantenimiento de la base de datos
y de los programas de aplicación. De esta manera se evita que el analista deba
dedicarse a tareas rutinarias y tediosas, permitiéndole poner toda su atención en
aquello que nunca un programa podrá hacer: entender los problemas del usuario.
(Artech, 2012)

2.6.2.1 DESARROLLO BASADO EN CONOCIMIENTO Y

METODOLOGÍA INCREMENTAL

En los últimos años se ha hablado mucho en la industria de Knowledge

Management y, dentro de este rótulo se han colocado muchas cosas que están bien
distantes del Desarrollo Basado en Conocimiento a que nos queremos referir aquí.

Generalmente la industria se ha referido a maneras de organizar y/o acceder el

conocimiento para ser utilizado de una forma tradicional por los seres humanos. Se
trata de una versión actualizada, utilizando la tecnología actualmente disponible, de
los libros (y que es de enorme utilidad para toda la humanidad): accedemos a un
cierto conocimiento leyendo un libro y, en nuestra mente, hacemos razonamientos

36
sobre ese conocimiento lo que, eventualmente, determina acciones. Los buscadores
de texto inteligentes que están disponibles desde hace pocos años hacen que este
conocimiento sea cada vez más accesible a los seres humanos.

Como característica general, este conocimiento no es “entendible” por una máquina

y, en consecuencia, no es operable. Adicionalmente, como el razonamiento de los
seres humanos puede lidiar razonablemente (dentro de ciertos límites) con la
ambigüedad y, aún, con la inconsistencia, este conocimiento muchas veces no es
riguroso.

Entonces, es bueno restringir el concepto de conocimiento que utilizaremos en

nuestro Desarrollo Basado en Conocimiento. Se trata de conocimiento que cumple las
siguientes condiciones:

 Riguroso.
 Representable en forma objetiva.
 Operable. (Artech, 2012)

2.6.2.2 EL DESARROLLO INCREMENTAL HECHO REALIDAD

Genexus es una herramienta que parte de las “visiones de los usuarios”; captura su
conocimiento y lo sistematiza en una base de conocimiento. A partir de su base de
conocimiento, Genexus es capaz de diseñar, generar y mantener de manera totalmente
automática la estructura de la base de datos y los programas de la aplicación (los
programas necesarios para que los usuarios puedan operar con sus visiones).

Genexus trabaja con conocimiento puro, lo que le permite realizar varias cosas:
generar programas (software tradicional), entender ese conocimiento de los seres
humanos (no necesita documentación adicional –que nunca estaría actualizada), y
operar automáticamente con ese conocimiento (integrándolo con otro proveniente de
otras fuentes, difundiéndolo, otorgando licencias a terceros para que lo integren a sus

37
aplicaciones). En definitiva, Genexus hace posible el “negocio del conocimiento”,
como un paso adelante respecto al “negocio del software”.

Cuando una aplicación se desarrolla con Genexus la primera etapa consiste en hacer
el Diseño de la misma registrando las visiones de usuarios (a partir de las cuales el
sistema captura y sistematiza el conocimiento).

Posteriormente se pasa a la etapa de Prototipación en donde Genexus genera la base

de datos (estructura y datos) y programas para el ambiente de prototipo. Una vez
generado el Prototipo debe ser puesto a prueba por el analista y los usuarios.

Si durante la prueba del Prototipo se detectan mejoras o errores se retorna a la fase de

Diseño, se realizan las modificaciones correspondientes y se vuelve al Prototipo.
Llamaremos a este ciclo de Diseño/Prototipo.

Una vez que el Prototipo está aprobado, se pasa a la etapa de Implementación, en

donde Genexus genera, también automáticamente, la base de datos y programas para
el ambiente de producción.

En resumen, una aplicación comienza con un Diseño, luego se prototipa, luego se

Implementa o pone en producción y en cualquiera de los pasos anteriores se puede
regresar al Diseño para realizar modificaciones. (Artech, 2012)

A continuación observamos los ciclos de Diseño del Prototipo y Producción en la

Figura 2.10.

Figura 2.10: Ciclos Diseño-Prototipo y Diseño-Producción

Fuente: [Artech, 2012]

38
2.6.3 SQL SERVER 2012

Es un sistema de manejo de bases de datos del modelo relacional, desarrollado por la

empresa Microsoft.

El motor de base de datos es el servicio de aplicación central en el paquete de SQL

Server para almacenar, procesar y proteger datos con SQL Server 2012. El SQL
Server 2012 base de datos del motor es un servicio de Windows que puede utilizar
para almacenar y procesar datos en un formato relacional, como documentos XML, y
los nuevos para el año 2012, como los datos espaciales. La siguiente son las
responsabilidades principales del motor de base de datos:

 Proporcionar un almacenamiento fiable para los datos

 Proporcionar un medio para recuperar rápidamente estos datos
 Proporcionar un acceso consistente a los datos
 Control de acceso a los datos de seguridad de todo
 Hacer cumplir las reglas de integridad de datos para confirmar que los datos
sean fiables y consistentes.
 Cada una de estas responsabilidades se examina con más detalle en capítulos
posteriores de este libro.

Otra característica clave del motor de base de datos ofrece para confirmar el
almacenamiento confiable es el registro de transacciones. El registro de transacciones
que hace un registro de cada cambio que se hace a la base de datos. Otra característica
clave del motor de base de datos ofrece para confirmar el almacenamiento confiable
es el registro de transacciones. El registro de transacciones que hace un registro de
cada cambio que se hace a la base de datos.

A continuación en la Figura 2.11 que ilustra de manera general los componentes más
importantes en un sistema SQLServer.

39
 Figura 2.11: Componentes de SQL Server 2012
Fuente: [2]

2.7 CALIDAD DEL PRODUCTO

El estándar ISO 9126 se desarrolló con la intención de identificar los atributos clave
del software de cómputo. Este sistema identifica seis atributos clave de la calidad:

2.7.1 CARACTERÍSTICAS DE CALIDAD INTERNA Y EXTERNA

El modelo de calidad para la calidad interna y externa ha sido establecido en

categorías de atributos de calidad del software en 6: funcionalidad, confiabilidad,
usabilidad, eficiencia, capacidad de mantenimiento y portabilidad.

A continuación en la Figura 2.12 observamos las Características de Calidad Interna y

Externa

40
 Figura 2.12: Características de calidad Interna y Externa
Fuente: [3]
Está norma describe 6 características:
 Funcionalidad: es la capacidad del software de cumplir y proveer las funciones
para satisfacer las necesidades explícitas e implícitas cuando es utilizado en
condiciones específicas.
 Confiabilidad: es la capacidad del software para asegurar un nivel de
funcionamiento adecuado cuando es utilizando en condiciones específicas, la
confiabilidad se amplía a sostener un nivel especificado de funcionamiento y no
una función requerida.
 Usabilidad: es la capacidad del software de ser entendido, aprendido, y usado en
forma fácil y atractiva. La usabilidad está determinada por los usuarios finales y
los usuarios indirectos del software, dirigidos a todos los ambientes, a la
preparación del uso y el resultado obtenido.
 Eficiencia: la eficiencia del software es la forma del desempeño adecuado, de
acuerdo a al número recursos utilizados según las condiciones planteadas. Se debe
tener en cuenta otros aspectos como la configuración de hardware, el sistema
operativo, entre otros.

41
 Mantenimiento: es la cualidad que tiene el software para ser modificado.
Incluyendo correcciones o mejoras del software, a cambios en el entorno, y
especificaciones de requerimientos funcionales.
 Portabilidad: la capacidad que tiene el software para ser trasladado de un entorno
a otro.

Para obtener los resultados de estas características se hará el uso de:

 Punto de función: para el cálculo de la funcionalidad.

 Tiempo medio entre fallas: para el cálculo de la confiabilidad
 Test de usuario: para el cálculo de la usabilidad, eficiencia, mantenimiento y
portabilidad.

2.7.1.1 PUNTO DE FUNCIÓN

Es una medida de tamaño, de clara significación de negocio publicada por Allan
Albrecht de IBM en 1979, está técnica cuantifica las funciones contenidas en el
software en términos que sean significativos para los usuarios de software. La medida
se relaciona directamente con los requerimientos del negocio que el software está
destinado a abordar. Por lo tanto, se aplica fácilmente a través de una amplia gama de
entornos de desarrollo y en toda la vida de un proyecto de desarrollo, de los requisitos
de primeros definición al uso operacional completa.

Otras medidas comerciales, tales como la productividad del proceso de desarrollo y el

coste por unidad para apoyar el software, también se pueden derivar fácilmente.

La propia medida de punto de función (PF) se deriva en una serie de etapas. El uso de
un conjunto estandarizado de criterios básicos, cada una de las funciones de la
empresa es un índice numérico de acuerdo a su tipo y complejidad. Estos índices se
suman para dar una medida inicial de tamaño que luego se normalizó mediante la
incorporación de una serie de factores relacionados con el software en su conjunto. El
resultado final es un número único llamado el índice de PF que mide el tamaño y la
complejidad del producto de software. (1)

42
La métrica de PF debe usarse de manera efectiva como medio para medir la
funcionalidad que entra a un sistema. Al usar datos históricos, la métrica PF se usa
para:
 Estimar el costo o esfuerzo requerido para diseñar, codificar y probar el software.
 Predecir el número de errores que se encontraran durante las pruebas.
 Prever el número de componentes y/o de líneas fuente proyectadas en el sistema
implementado.

Los puntos de función se derivan usando una relación empírica basada en medidas
contables (directas) del dominio de información del software y en valoraciones
cualitativas de la complejidad del software. Pressman (2010) define los valores de
dominio de información de la siguiente forma:

 Número de entradas externas (EE): cada entrada externa se origina de un usuario

o se transmite desde otra aplicación, y proporciona distintos datos orientados a
aplicación o información de control. Con frecuencia, las entradas se usan para
actualizar ALI. Las entradas deben distinguirse de las consultas, que se cuentan
por separado.
 Número de salidas externas (SE): cada salida externa es datos derivados dentro de
la aplicación que ofrecen información al usuario. En este contexto, salida externa
se refiere a reportes, pantallas, mensajes de error, etc. Los ítems de datos
individuales dentro de un reporte no se cuentan por separado.
 Número de consultas externas (CE): una consulta externa se define como una
entrada en línea que da como resultado la generación de alguna respuesta de
software inmediata en la forma de una salida en línea (con frecuencia recuperada
de un ALI.
 Número de archivos lógicos internos (ALI): cada archivo lógico interno es un
agrupamiento lógico de datos que reside dentro de la frontera de la aplicación y se
mantiene mediante entradas externas.
 Número de archivos de interfaz externos (AIE): cada archivo de interfaz externo
es un agrupamiento lógico de datos que reside fuera.

43
Para el cálculo de PF se usa la siguiente formula:

PF = Conteo Total * [0,65 + 0,01 * ∑(𝑓𝑖) ]

Donde conteo total es la suma de todas las entradas PF obtenidas de la figura 2.13, se
completa los datos y un valor de complejidad asociada a cada conteo para determinar
si una entrada particular es simple, promedio o compleja.

Figura 2.13: Cálculo de entradas de punto de función

Fuente: [Pressman, 2010]

Los (i = 1 a 14) son factores de ajuste de valor (FAV) con base en respuestas a las
siguientes preguntas:

1. ¿El sistema requiere respaldo y recuperación confiables?

2. ¿Se requieren comunicaciones de datos especializadas para transferir información
hacia o desde la aplicación?
3. ¿Existen funciones de procesamiento distribuidas?
4. ¿El desempeño es crucial?
5. ¿El sistema correrá en un entorno operativo existente enormemente utilizado?
6. ¿El sistema requiere entrada de datos en línea?
7. ¿La entrada de datos en línea requiere que la transacción de entrada se construya
sobre múltiples pantallas u operaciones?
8. ¿Los ALI se actualizan en línea?
9. ¿Las entradas, salidas, archivos o consultas son complejos?

44
10. ¿El procesamiento interno es complejo?
11. ¿El código se diseña para ser reutilizable?
12. ¿La conversión y la instalación se incluyen en el diseño?
13. ¿El sistema se diseña para instalaciones múltiples en diferentes organizaciones?
14. ¿La aplicación se diseña para facilitar el cambio y su uso por parte del usuario?

Cada una de estas preguntas se responde usando una escala que varía de 0 (no
importante o aplicable) a 5 (absolutamente esencial). Los valores constantes de la
formula y los factores ponderados que se aplican a los conteos de dominio de
información se determinan de manera empírica.

2.7.1.2 TIEMPO MEDIO ENTRE FALLAS

Los primeros trabajos sobre confiabilidad del software trataban de extrapolar la teoría
matemática de la confiabilidad del hardware a la predicción de la confiabilidad del
software. La mayor parte de modelos relacionados con el hardware se abocan a la
falla debida al uso, en lugar de a la que tiene su origen en los defectos de diseño. En
el hardware, las fallas debidas al uso físico (por ejemplo, los efectos de temperatura,
corrosión y golpes) son más probables que las debidas al diseño.
Desafortunadamente, con el software ocurre lo contrario. En realidad, todas las fallas
del software pueden rastrearse en problemas de diseño o de implementación.
(Pressman, 2010)

Una medida sencilla para calcular la confiabilidad es el tiempo medio entre fallas
(TMEF) qué está dado por la siguiente formula:

TMEF = TMDF + TMDR

Dónde:
TMEF es el tiempo medio entre fallos
TMDF es el tiempo medio de fallos
TMDR es el tiempo medio de reparación

45
Muchos investigadores afirman que el TMEF es una medición más útil que otras
relacionadas con la calidad del software. En pocas palabras, a un usuario final le
preocupan las fallas, no la cuenta total de defectos. Como cada defecto contenido en
un programa no tiene la misma tasa de fallas, la cuenta total de defectos indica muy
poco acerca de la confiabilidad del sistema. Sin embargo, el TMEF puede ser
problemático por dos razones:

 Proyecta un tiempo entre fallas, pero no da una tasa de fallas proyectada

 Mala interpretación, como la vida promedio, cuando no es esto lo que implica.

Una medición alternativa de confiabilidad es la de las fallas en el tiempo (FET):

medición estadística de cuántas fallas tendrá un componente en mil millones de horas
de operación. Por tanto, FET es equivalente a una falla en cada mil millones de horas
de operación.

Además de una medida de la confiabilidad, también debe desarrollarse otra para la

disponibilidad. La disponibilidad del software es la probabilidad de que un programa
opere de acuerdo con los requerimientos en un momento determinado de tiempo, y se
define así:
Disponibilidad = TMDF / TMDF + TMDR

2.7.3 TEST DE USUARIO

Una gestión total de la calidad asume qué cualquier producto contiene debilidades y
problemas. El objetivo de un test de usuario es encontrarlos antes de su lanzamiento
al mercado.

Los objetivos del test parten al entender qué se quiere saber de un determinado
producto y marcan quién debe participar en el test, qué tareas realizar, qué datos
recoger, qué equipo utilizar, qué medir, qué se considera éxito, como analizar la
información, qué hacer con la información una vez analizada y otros.

46
Los objetivos ambiguos son una forma de empezar, pero deben concretarse hasta
establecer la forma de medirlos.

2.7.2 METODOLOGÍA WEBQEM (MÉTODO DE EVALUACIÓN DE

CALIDAD DE LA WEB)

La Metodología WebQem, presenta una propuesta que proporciona

un enfoque cuantitativo y sistemático para evaluar y comparar sitios Web
tanto en la fase operativa como en la etapa del desarrollo. Permite evaluar el grado de
cumplimiento de los factores de calidad descritos en el estándar ISO 9126:
funcionalidad, confiabilidad, usabilidad, eficiencia, capacidad de mantenimiento y
portabilidad. Esta metodología se aplicó con éxito en diversos casos de estudio de
dominios Web, como los expuestos en.

Uno de los objetivos principales de la evaluación y comparación de

calidad de artefactos Web, radica en comprender el grado de cumplimiento de un
conjunto de características y sub características con respecto a los requerimientos de
calidad establecidos. De este modo, otro aporte interesante consiste en la definición
de características, sub características y atributos cuantificables considerando
dominios de aplicaciones Web particulares.

Para lo cual se analizan los indicadores (también llamados criterios de preferencia o

de performance) globales, parciales y elementales obtenidos. El resultado del proceso
de evaluación (y eventualmente de comparación y selección) puede ser interpretado
como el grado de satisfacción de los requerimientos de calidad.

La metodología comprende una serie de fases y actividades, y una serie de métodos,

modelos y herramientas para llevarlas a cabo. Estas fases son:

 Planificación y programación de la evaluación de calidad.

 Definición y especificación de requerimientos de calidad.
 Definición e implementación de la evaluación elemental.

47
 Definición e implementación de la evaluación global.
 Análisis de resultados, conclusión y documentación.

La figura 2.14 muestra una vista general de las fases de la metodología.

Figura 2.14: Fases de la metodología WebQem

Fuente: [Alfonzo, 2012]

A continuación se realiza una síntesis de cada una de las fases:

2.7.2.1 PLANIFICACIÓN Y PROGRAMACIÓN DE LA EVALUACIÓN DE

CALIDAD

Contiene actividades y procedimientos de soporte, con el fin de determinar objetivos

estratégicos, tácticos y operativos. Permite establecer las principales estrategias y
metas del proceso en un contexto organizacional, seleccionar un modelo de proceso

48
de evaluación, asignar métodos, agentes y recursos a las actividades, y realizar nuevas
planificaciones una vez en iniciado el proceso de evaluación.

2.7.2.2 DEFINICIÓN Y ESPECIFICACIÓN DE REQUERIMIENTOS DE

CALIDAD

La misma trata con actividades y modelos para la elicitación, determinación, análisis

y especificación de los requerimientos.

A partir de un proceso de medición orientado a metas, y con el fin de evaluar,

comparar, analizar, y mejorar características y atributos de artefactos Web, los
requerimientos deben responder a necesidades y comportamientos de un perfil de
usuario y dominio determinados. Esta fase culmina con un documento que
jerárquicamente específica a todas las características y atributos cuantificables que
modelan a la calidad, según las necesidades del usuario.

2.7.2.3 DEFINICIÓN E IMPLEMENTACIÓN DE LA EVALUACIÓN

ELEMENTAL

Comprende actividades, modelos, técnicas y herramientas para determinar métricas y

criterios de evaluación para cada atributo cuantificable. Se consideran funciones para
determinar la preferencia elemental, escalas de preferencia, valores críticos, entre
otros. Una vez definidos y consensuados los criterios para medir cada atributo, se
debe ejecutar el
proceso de recolección de datos, computar las métricas y preferencias elementales, y
documentar los resultados.

2.7.2.4 DEFINICIÓN E IMPLEMENTACIÓN DE LA EVALUACIÓN

GLOBAL

Comprende actividades, modelos, y herramientas para determinar los criterios de

agregación de las preferencias de calidad elemental para producir la preferencia
global, para cada sistema seleccionado. Se consideran tipos de funciones de

49
agregación para modelar diferentes relaciones entre atributos y características, a
saber: relaciones de reemplazabilidad, simultaneidad, neutralidad y diferentes niveles
de polarización “y/o” (and/or). Una vez definidos y consensuados los criterios, se
debe llevar a cabo el proceso de cálculo y ranking.

2.7.2.5 ANÁLISIS DE RESULTADOS, CONCLUSIÓN Y

DOCUMENTACIÓN

La misma trata con actividades de análisis y comparación de las preferencias de

calidad elemental, parcial y global, y, asimismo, la justificación de los resultados. Se
utilizan herramientas y mecanismos de documentación para facilitar la interpretación
de los datos y su seguimiento.

A continuación se mencionan los procesos de la metodología, que conforman algunas

de las fases antes mencionadas:

 Definiendo el Dominio y Ente para la Evaluación de la Calidad.

 Definiendo Metas de Evaluación y Seleccionando el Perfil de Usuario.
 Especificando Requerimientos de Calidad para artefactos Web.
 Definiendo Criterios Elementales e Implementando Procedimientos de Medición
(también llamado Determinación de la Preferencia de Calidad Elemental).
 Definiendo las Estructuras de Agregación e Implementando la Evaluación de
Calidad Global.
 Analizando y comparando los Resultados Parciales y Globales.

La figura 2.15, muestra el proceso de evaluación que subyace a la

metodología, incluyendo las fases, etapas, pasos principales, entradas y
salidas. Este modelo está inspirado en el modelo de proceso de la ISO para los
evaluadores. Se resalta de la Figura 2.14, las dos grandes etapas: el
diseño y la implementación de la evaluación elemental. Además, en la fase de
implementación de la evaluación elemental, las métricas seleccionadas se
aplican a la aplicación Web. Algunos valores pueden medirse por la observación,

50
mientras que otros pueden obtenerse automáticamente mediante herramientas
computarizados. (Alfonzo, 2012)

Figura 2.15: Procesos de evaluación

Fuente: Fuente: [Alfonzo, 2012]

2.8 SEGURIDAD

2.8.1 OWASP

El Proyecto de Pruebas OWASP ha estado en desarrollo durante muchos años, el

objetivo es ayudar a entender porque, cuando como probar sus aplicaciones web, y no
tan solo proveer con un simple listado de comprobación o una prescripción de
acciones específicas que deben ser atendidas.

51
Realizar un marco de desarrollo de pruebas a partir del cual otros pudiesen crear sus
propios programas de test, o evaluar los procesos de otros. Escribir el Proyecto de
Pruebas ha demostrado ser una tarea difícil. Ha sido todo un reto conseguir un cierto
consenso y desarrollar el contenido apropiado, que permitiese a la gente aplicar el
contenido y marco de trabajo global aquí descrito, y a la vez también les permitiese
trabajar dentro de su propio entorno y cultura. También ha sido un reto el cambiar el
enfoque de la realización de pruebas sobre aplicaciones web. Ir desde las pruebas de
intrusión a las pruebas integrales en el ciclo de desarrollo del software.

Muchos expertos en la industria y responsables de la seguridad del software en

algunas de las mayores empresas del mundo dan validez al Marco de Pruebas. Este
marco de trabajo tiene por objetivo, más que simplemente resaltar áreas con
carencias, ayudar a las organizaciones a comprobar sus aplicaciones web con el
propósito de construir software fiable y seguro, aunque ciertamente lo primero se
obtiene gracias a muchas de las guías y listados de comprobación del OWASP.

El proyecto OWASP es capaz de colocarse en un plano superior de autoridad y

cambiar la cultura de conocimiento existente, mediante la educación y la
concienciación basadas en el consenso y la experiencia. Para realizar pruebas de
aplicaciones web: el alcance de las pruebas, los principios de una prueba exitosa, y
las técnicas de prueba.

2.8.1.1 ¿QUÉ ES LA COMPROBACIÓN?

Durante el ciclo de vida del desarrollo de una aplicación web, muchas cosas han de
ser probadas. El diccionario Merriam-Webster describe la acción de comprobar (en
inglés, testing) como:

 Poner a prueba o probar

 Pasar una prueba
 Ser asignado un estado o evaluación basado en pruebas.

52
A efectos de este documento, la comprobación o testing es un proceso de
comparación del estado de algo ante un conjunto de criterios. En la industria de la
seguridad, a menudo se realizan pruebas contra un conjunto de criterios mentales que
no están ni bien definidos ni completos. Por esa y otras razones, muchas personas
ajenas a esta industria consideran la comprobación de seguridad como un arte secreto
y arcano. El objetivo de este documento es modificar esa percepción, y hacer más
fácil a las personas sin un conocimiento en profundidad de seguridad cambiar las
cosas.

2.8.1.2 ¿POR QUÉ COMPROBAR?

Ayudar a las organizaciones a entender qué comprende la realización de un programa

de pruebas, y ayudarlas a identificar los pasos necesarios a realizar para construir y
operar dicho programa de pruebas sobre sus aplicaciones web.

Se pretende suministrar una vista lo más amplia posible de los elementos necesarios
requeridos para realizar un programa de seguridad de aplicación web exhaustivo.

2.8.1.3 ¿CUÁNDO COMPROBAR?

La mayor parte de la gente no comprueba el software hasta que ya ha sido creado y se

encuentra en la fase de desarrollo de su ciclo de vida (ej. El código ya ha sido creado
e instanciado en una aplicación web funcional). Esta es generalmente una práctica
muy inefectiva y costosa.

Uno de los mejores métodos para evitar la aparición de bugs de seguridad en

aplicaciones en producción es mejorar el Ciclo de Vida de Desarrollo del Software
(SDLC) como se puede ver en la figura 2.16, incluyendo la seguridad. Si no hay un
SDLC en uso en tu entorno actualmente, es el momento de escoger uno La figura
siguiente muestra un modelo SDLC genérico, así como los costes en incremento
progresivo (estimados) de corregir bugs de seguridad en un modelo de este tipo.

53
 Figura 2.16: Modelo SDLC genérico
Fuente: [Fundación Owasp, 2008]

2.8.1.4 ¿QUÉ DEBE SER COMPROBADO?

Puede ser de gran ayuda pensar en el desarrollo de software como en una

combinación de personas, procesos y tecnología. Si esos son los factores que crean el
software, es lógico que esos sean los factores que deben ser probados. Hoy en día la
mayoría de personas realizan pruebas a la tecnología o el propio software. De hecho,
la mayoría no realiza pruebas al software hasta que ya ha sido creado y está en la fase
de desarrollo de su ciclo de vida (es decir, que el código ha sido creado e instanciado
en una aplicación web en uso). Generalmente, esta es una práctica muy ineficaz y
prohibitiva en coste. Un programa de pruebas efectivo debería tener componentes que
comprueban; Las Personas - para asegurarse de que hay la educación y
concienciación adecuadas; Los Procesos - para asegurarse que hay las políticas y
estándares adecuados, y que las personas saben cómo seguir dichas políticas; La
Tecnología - para asegurarse de que el proceso ha sido efectivo en su
implementación. A menos se adopte un enfoque integral, probar tan solo la
implementación técnica de una aplicación no descubrirá vulnerabilidades
operacionales o de gestión que pudiesen estar presentes. Mediante la realización de
pruebas sobre las personas, políticas y procesos, puedes llegar a prever incidencias o
problemas que más tarde se manifestasen en forma de defectos en la tecnología, y así

54
erradicar bugs de forma temprana e identificar las causas de los defectos. Del mismo
modo que probar solamente algunas de las incidencias técnicas que pueden estar
presentes en un sistema resultará en un punto de vista incompleto e incorrecto de
cómo realizar una evaluación de seguridad. (Fundación Owasp, 2008)

A continuación, vamos a enumerar las 10 vulnerabilidades más comunes del informe

realizado hasta 2013 y vamos a aportar una breve descripción sobre cada una de las
vulnerabilidades:

1. Inyección: este ataque se produce cuando datos no confiables son enviados a

un intérprete (ya sea del sistema operativo, de una base de datos o cualquier
intérprete) como parte de un comando o consulta. Los datos hostiles
introducidos por el atacante pueden engañar al intérprete haciendo que se
ejecuten comandos no intencionados o accediendo a información sobre la que
no se está autorizado. Uno de los ejemplos más significativos de este tipo de
ataque es SQL Injection.
2. Pérdida de autenticación y gestión de sesiones: este tipo de ataque se produce
cuando los mecanismos de la aplicación relacionados con la autenticación,
autorización y control de sesiones son, frecuentemente, implementados de
forma incorrecta o su configuración no se ha realizado de forma correcta. Esto
provoca que un usuario malicioso pueda obtener las credenciales de un
usuario, el identificador de la sesión o, incluso, el identificador de acceso y
hacerse pasar por dicho usuario accediendo a todos sus datos. Uno de los
ejemplos puede ser la gestión de la sesión mediante la propia página.
3. Secuencia de comandos en sitios cruzados (XSS): este tipo de ataque ocurre
cuando se obtienen datos no confiables y se envían directamente al navegador
web. Esto provoca que se puedan ejecutar comandos no deseados en el
navegador del usuario. Estos comandos pueden obtener desde las credenciales
de acceso del usuario como instalar ciertos programas maliciosos.
4. Referencia directa insegura a objetos: este tipo de ataque ocurre cuando no se
controlan los accesos a recursos sobre los que un usuario no debería tener

55
 acceso. En las aplicaciones, la mayoría de las veces, existen distintos usuarios
y cada usuario tiene una serie de recursos sobre los que tiene acceso y otros
sobre los que no debería tener acceso. Un ejemplo podría ser el acceso a una
tabla de base de datos sobre la que un determinado usuario no debería tener
acceso (una tabla de gestión sobre la que sólo el administrador debería tener
acceso).
5. Configuración de seguridad incorrecta: este tipo de ataque ocurre cuando se
han realizado malas configuraciones en las aplicaciones, en los servidores de
las aplicaciones, en las bases de datos o en la configuración del propio sistema
operativo. Es importante tener todo el software bien actualizado con la última
versión disponible (esperando a que no haya vulnerabilidades de día 0) y que
todas las librerías o frameworks que use la aplicación también estén
actualizadas ya que muchos cambios que se realizan en las versiones tienen
que ver con aspectos de seguridad.
6. Exposición de datos sensibles: este tipo de ataque ocurre cuando se puede
acceder de forma fácil a datos de carácter sensible almacenados en la
aplicación. Cuando, por ejemplo, se almacenan las credenciales de los
usuarios sin codificar o si la comunicación del servidor no es segura a la hora
de realizar un pago con una tarjeta de crédito.
7. Ausencia de control de acceso a funciones: este tipo de ataque ocurre cuando
se acceden a funciones del servidor sobre las que un usuario no debería tener
permiso. Cuando, por ejemplo, el servicio de listado de usuario sólo debería
estar disponible por la aplicación pero cualquier usuario puede también
acceder a esta información.
8. Falsificación de peticiones en sitios cruzados: este tipo de ataque ocurre
cuando se realizan peticiones HTTP falsificadas del ordenador de la víctima a
una aplicación web vulnerable.
9. Utilización de componentes con vulnerabilidades conocidas: este tipo de
ataque ocurre cuando se emplean librerías o frameworks que contienen
vulnerabilidades. Es por esto que es importante actualizar estos componentes

56
 o revisar el histórico de revisiones para comprobar las mejoras de seguridad
implementadas.
10. Redirecciones y reenvíos validados: este tipo de ataque ocurre cuando, al re
direccionar al usuario a otra página, no se comprueba que el destino sea
válido. Es por esto que se puede redirigir a un usuario a una página que
contenga contenido malicioso para robar las credenciales de dicho usuario.
(Fundación Owasp, 2008)

57
 CAPITULO III

MARCO APLICATIVO

3.1 ANÁLISIS DE LA METODOLOGÍA DE DESARROLLO

Después de describir la metodología de documentación y desarrollo (UWE, Scrum y

Mobile-D) en el capítulo anterior, se realiza la refactorización de las mismas donde
ser describirá las fases que adoptaremos para el desarrollo del Sistema y Aplicación
Móvil hasta la conclusión de los mismos.

3.1.1 EXPLORACIÓN

En esta fase se debe tomar en cuenta e identificar los siguientes puntos:

 Identificar los actores que intervendrán en el desarrollo, uso del sistema y

aplicación móvil con sus respectivas funciones.
 Describir la lista de requerimientos (funcionales, no funcionales) generales
definidas por el dueño del producto para el desarrollo del sistema y la aplicación
móvil, los cuales se deben cubrir con una o más tareas.

3.1.2 PLANIFICACIÓN

Una vez que se ha realizado la fase de Exploración a continuación se detalla los

puntos de la fase de Planificación:

 Se define la Pila del Producto (Product Backlog) con la lista de tareas que deben
concluirse para finalizar el producto.
 Definir el cronograma de actividades desde el inicio hasta la entrega final del
producto.
 Visualizar los procesos y tareas que tiene cada usuario que participara en el uso
del sistema y aplicación móvil, haciendo uso de diagramas de Casos de Uso
definido en la fase de análisis de requisito de la metodología UWE.

58
 Modelar el diagrama Entidad Relación de la Base de Datos, de acuerdo a los
casos de uso.
 Realizar la transformación del modelo entidad relación al modelo físico.
 Diseñar los diagramas de clases descrito en la fase de contenido de la metodología
UWE para apoyar el desarrollo del producto.

3.1.3 EJECUCIÓN

En la fase de ejecución se desarrollara la lista de requerimientos o tareas de la pila del

producto, divididas en sprints de acuerdo a la prioridad de cada una de las tareas.

El desarrollo de cada uno de los sprints estará apoyado por las fases de la
metodología UWE:

 Diseño de casos de uso para visualizar las diferentes funcionalidades de las tareas
del sprint.
 Describir las historias de usuario, donde se especifica las actividades de los
usuarios.
 Diseño de diagrama de clases para proporcionar una especificación visual de la
información.
 Diseño de diagrama de navegación para identificar el enlace entre páginas.
 Diseño de diagrama de procesos para describir el comportamiento de una clase de
proceso.
 Diseño abstracto de la interfaz de usuario de las tareas del sprint para el modelo
de presentación.
 Realizar la revisión de las tareas a través del despliegue de las capturas de
pantalla para cada una de las tareas del sprint.

3.1.4 RETROALIMENTACIÓN

En esta fase se debe tomar en cuenta los siguientes aspectos:

59
 Realizar la revisión de cada uno de los sprints, en caso de que exista tareas
incompletas se debe crear otro sprint para concluir con todas las tareas
planificadas y aplicar la fase de ejecución.
 Se puede realizar nuevos requerimientos en caso de que exista y adicionar a un
nuevo sprint.

3.2 SITUACIÓN ACTUAL DE LA INSTITUCIÓN

Actualmente la Empresa Tecnoalimentos Ltda, tiene ciertos percances en cuanto al

manejo de la Información que generan sus clientes, lo cual ocasiona pérdidas
económicas y produce insatisfacción por parte de sus clientes.

La Empresa Tecnoalimentos Ltda, tiene alrededor de 12 clientes los cuales a su vez

pueden contar con más de una sucursal.

De los cuales se tiene un historial en documentos en papel acerca de los pedidos que
se han ido realizando en gestiones pasadas.

3.3 REQUERIMIENTOS MÍNIMOS DE HARDWARE Y SOFTWARE

Los requerimientos tanto de Hardware como de Software para la implementación y

visualización para el usuario son:

3.3.1 HARDWARE

3.3.1.1 EQUIPO SERVIDOR

a) Aplicación

 Procesador Core I3, 4 GHz mínimo.

 Memoria RAM 4 GB mínimo.
 Espacio en Disco Duro 20 GB mínimo.

60
 Monitor VGA de 1024 x 768 de resolución.
 Tarjeta de Red con puertos Ethernet.

b) Base de Datos

 Procesador Core I3, 4 GHz mínimo.

 Memoria RAM 4 GB mínimo. La cantidad de memoria RAM varía según la
cantidad de usuarios Web, así como de la cantidad de tareas extras que
ejecute el servidor.
 Disco Duro con 80 GB LIBRES para datos.
 Unidad de CD-ROM o DVD-ROM.
 Monitor VGA de 1024 x 768 de resolución.

3.3.1.2 EQUIPO CLIENTE

a) PC/Notebook/Netbook

 Procesador Core 2 Duo, 2.73 GHz mínimo.

 Memoria RAM 2 GB mínimo.
 Espacio en Disco Duro 20 GB mínimo.
 Tarjeta de Red Ethernet o Wireless

b) Dispositivos Móviles

 Tablet
 Smartphone

3.3.2 SOFTWARE

3.3.2.1 EQUIPO SERVIDOR

 Sistema Operativo Linux (Centos) versión 6.5 mínimo.

 Gestor de Base de Datos 9.1 Recomendado.

61
3.3.2.2 EQUIPO USUARIO

a) PC/Notebook/Netbook

 Sistema Operativo Linux (Centos) versión 6.5 mínimo con entorno Grafico.
 Navegadores Chrome v.41, Firefox v.36.

b) Dispositivos Móviles

 Navegador Web

3.4 ARQUITECTURA

En Base a la arquitectura cliente servidor y el MVC que maneja la herramienta

Genexus, en la Figura 3.1 se muestra la arquitectura propuesta para el Sistema y
aplicación Móvil.

Figura 3.1: Arquitectura propuesta para el sistema

Fuente: Elaboración Propia

3.5 IMPLEMENTACIÓN DE LA METODOLOGÍA DE DESARROLLO

3.5.1 EXPLORACIÓN

A continuación se identifican a los actores que intervienen en el desarrollo y uso del

sistema y aplicación móvil con sus respectivas funciones como se observa en la tabla
3.1.

62
ACTOR FUNCIÓN
Desarrollador Diseño, Análisis y Desarrollo del Sistema.
de Sistemas
Ingeniero de Verifica que el Sistema cumpla con las normas de Calidad en
Control de base a los requerimientos definidos.
Calidad
Personal de Realiza la instalación en base a los requerimientos mínimos del
Instalación e Sistema.
Implementación
Administrador Administra usuarios, roles y permisos del sistema.
del Sistema
(Empresa)
Operador Registra empresa (cliente), productos, aprueba y envía pedidos a
(Empresa) los clientes, además de controlar los pedidos, entregas y
devoluciones.
Repartidor Realiza las entregas de productos bajo la plantilla registrada en
(Empresa) base al pedido realizado por el cliente.
Gerente Encargado de controlar los pedidos entregas y devoluciones de su
(Cliente) empresa, además de los stocks de productos de todas sus
sucursales.
Operador Cumple la tarea de generar plantillas, controlar los pedidos
(Sucursal) entregas y devoluciones, también el encargado de realizar los
cierres diarios de la sucursal a la cual pertenece.
Recepcionista Recepciona los productos del pedido realizado bajo plantilla,
además de registrar las devoluciones realizadas de productos en
mal estado o por fecha de vencimiento de parte del cliente.
Tabla 3.1: Actores que intervienen el Sistema
Fuente: Elaboración Propia

63
A continuación se procede a describir la lista de requerimientos generales definidos
por el dueño del producto para el desarrollo del sistema y la aplicación móvil.

3.5.1.1 REQUERIMIENTOS FUNCIONALES

 Registrar toda la información correspondiente a los diferente s tipos,

productos que produce y provee la Empresa.
 Registrar la Información correspondiente a la cartera de clientes con los
cuales cuenta la Empresa.
 Realizar el control del proceso de pedidos que realizan contantemente los
clientes.
 Realzar el control de cantidades existentes, disponibilidad que se tiene por
producto.
 Automatizar las Plantillas de envió, entrega y devoluciones ante un pedido.

3.5.1.2 REQUERIMIENTOS NO FUNCIONALES

 Sistema Intuitivo para el usuario.

 Procesamiento de Información con respuesta inmediata.
 Ingreso al Sistema desde cualquier navegador.

3.5.2 PLANIFICACIÓN

Se procede a definir la Pila del Producto (Product Backlog) con la lista de tareas
definidas por el Product Owner en la tabla 3.2.

ID DESCRIPCIÓN
1 Diseño de logo
2 Diseño del menú de opciones
3 Diseño y autenticación de usuarios
4 Registro de permisos
5 Registro de roles
6 Registro de usuarios

64
7 Asignación de permisos a un rol
8 Asignación de roles a usuarios
9 Registro de unidades de medida
10 Registro de tipo de producto
11 Registro de producto
12 Registro de cliente
13 Registro de plantilla
14 Generación de pedido automático
15 Generación de pedido manual
16 Control de pedido por parte de la empresa
17 Control de pedido por parte del cliente
18 Revisión de stock del producto para aprobar el pedido
19 Aprobación y envió del pedido
20 Registro de entrega del pedido
21 Registro de la recepción del pedido
22 Control de entrega y recepciones por parte de la empresa
23 Control de la recepción de productos por parte del Cliente
24 Registro de devolución
25 Control de devolución por parte de la empresa
26 Control de devolución por parte del cliente
27 Control stock de productos de la empresa
28 Control stock de productos por cliente
29 Control de tipos de producto por cliente
30 Cierre diario de cada cliente (Inventario)
31 Consulta de productos existentes por cliente/sucursal
32 Consulta de pedidos por cliente/sucursal
33 Consulta de devoluciones por cliente/sucursal
34 Consulta de cartera de clientes
35 Reporte de disponibilidad de productos

65
 36 Reporte de devoluciones por cliente/sucursal
37 Reporte de número de pedidos en un determinado mes y año.
38 Reporte de cartera de clientes
39 Reporte de información por producto
40 Reporte de producto(s) con más venta
Tabla 3.2: Pila de Productos
Fuente: Elaboración Propia

Después de haber definido la pila del producto se realiza el cronograma de

actividades de la duración para la entrega del producto en la tabla 3.3.
Fecha Inicio Fecha Fin Agosto Septiembre Octubre Noviembr
e
16/03/2016

17/09/2016

24/09/2016

01/10/2016

08/10/2016

15/10/2016

22/10/2016

30/10/2016

05/11/2016

12/11/2016
02/08/2016

16/08/2016

20/09/2016

27/09/2016

04/10/2016

11/10/2016

18/10/2016

22/10/2016

01/11/2016

08/11/2016
Análisis y Estudio
sobre la Situación

Requerimientos
Investigación

Actual de la

Producción
Institución

Monitoreo
Actividad

Pruebas y
Puesta en
Sprint 1

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Sprint 6
de

Tabla 3.3: Planificación

Fuente: Elaboración Propia

66
A continuación se muestra los procesos y tareas que tienen en común todos los
actores que participara en el uso del sistema y aplicación móvil, en las figura 3.2.

Figura 3.2: Tareas realizadas por cada uno de los usuarios

Fuente: Elaboración Propia

Después de haber diseñado los diagramas de casos de uso se realiza el modelo del
diagrama Entidad Relación de la Base de Datos como se observa en la figura 3.3.

67
 Figura 3.3: Diagrama Entidad Relación
Fuente: Elaboración Propia

Por último se realiza la transformación del modelo entidad relación al modelo físico
como se ve en la figura 3.4.

68
 Figura 3.4: Modelo Físico
Fuente: Elaboración Propia

3.5.3 EJECUCIÓN

3.5.3.1 SPRINT 1

En el primer Sprint se detalla el proceso de generación de las pantallas principales del

sistema, continuando con el proceso de inserción de toda la información necesaria
para la realización de los procesos de pedidos, entregas, devoluciones.

69
En la tabla 3.4 se muestra la pila de procesos que se desarrolla para el registro de los
parámetros.

ID DESCRIPCIÓN PRIORIDAD TIEMPO ESTADO

HORAS
1 Diseño de logo Muy Alta 5 Concluido
2 Diseño del menú de opciones Muy Alta 7 Concluido
3 Diseño y autenticación de Muy Alta 5 Concluido
usuarios
4 Registro de permisos Alta 4 Concluido
5 Registro de roles Alta 4 Concluido
6 Registro de usuarios Media 7 Concluido
7 Asignación de permisos a un Media 5 Concluido
rol
8 Asignación de roles a Media 5 Concluido
usuarios
9 Registro de unidades de Alta 5 Concluido
medida
10 Registro de tipo de producto Alta 5 Concluido
11 Registro de producto Alta 5 Concluido
12 Registro de cliente Media 7 Concluido
13 Registro de plantilla Muy Alta 10 Concluido
Tabla 3.4: Sprint 1
Fuente: Elaboración Propia

En la figura 3.5 podemos visualizar el diagrama de casos para el proceso de registro

de parámetros.

70
 Figura 3.5: Diagrama casos de uso del registro de parámetros
Fuente: Elaboración Propia

A partir del diagrama de casos de uso de la figura: 3.5 que representa el registro de
parámetros tenemos la siguiente historia de usuario.

Título: Administración de Usuarios

Objetivo: Alta, Modificación y Baja de Usuarios
Actores: Administrador
Episodios:
Alta de tipo de usuario (Administrador, Operador, Repartidor,
Recepcionista), registro de datos personales necesarios.
Modificación de registros correspondientes al usuario.
Baja de un usuario cambiando el estado a inactivo.
Asignación de Roles y Permisos.
Tabla 3.5: Administración de Usuarios
Fuente: Elaboración Propia

71
En la figura 3.6 se observa el diagrama de clases para especificar las tareas del primer
sprint.

Figura 3.6: Diagrama de clases, especificación de parámetros del sistema

Fuente: Elaboración Propia

En la figura 3.7 se observa de diagrama de navegación para identificar el enlace entre

páginas de los procesos identificados en el sprint 1.

72
 Figura 3.7: Diagrama de navegación, especificación de parámetros del sistema
Fuente: Elaboración Propia

Según la revisión de las tareas del primer Sprint se obtuvo los siguientes resultados,
de las tareas definidas en el Sprint 1 que se observan en las figuras: 3.8, 3.9, 3.10,
3.11, 3.12, 3.13, 3.14, 3.15, 3.16, 3.17.

Figura 3.8: Diseño y autenticación de usuarios

Fuente: Elaboración Propia

73
 Figura 3.9: Diseño del menú de opciones
Fuente: Elaboración Propia

Figura 3.10: Pantalla de asignación de roles a un usuario

Fuente: Elaboración Propia

Figura 3.11: Pantalla de gestión de usuarios

Fuente: Elaboración Propia

74
Figura 3.12: Pantalla de listado de unidad de medida
Fuente: Elaboración Propia

Figura 3.13: Pantalla de ABM de unidad de medida

Fuente: Elaboración Propia

75
Figura 3.14: Pantalla de listado de tipo de producto
Fuente: Elaboración Propia

Figura 3.15: Pantalla de ABM de tipo de producto

Fuente: Elaboración Propia

Figura 3.16: Pantalla de ABM de producto

Fuente: Elaboración Propia

76
 Figura 3.17: Pantalla de Registro de plantilla
Fuente: Elaboración Propia

3.5.3.2 SPRINT 2

En el segundo Sprint se detalla la implementación de los procesos que intervienen

para la generación de pedidos.

ID DESCRIPCIÓN PRIORIDAD TIEMPO ESTADO

HORAS
14 Generación de pedido Alta 10 Concluido
automático
15 Generación de pedido manual Alta 10 Concluido
16 Control de pedido por parte Alta 10 Concluido
de la empresa

77
 17 Control de pedido por parte Media 5 Concluido
del cliente
18 Revisión de stock del Media 5 Concluida
producto para aprobar el
pedido
19 Aprobación y envió del Media 8 Concluida
pedido
Tabla 3.6: Sprint 2
Fuente: Elaboración Propia

En las Figuras 3.18 podemos visualizar el diagrama de casos de uso para la

generación de pedido.

Figura 3.18: Diagrama Casos de Uso que representa la generación de Pedido

Fuente: Elaboración Propia

A partir de los casos de uso de la figura: 3.18 tenemos las siguientes historias de
usuario ver tabla: 3.7 y 3.8.

Título: Administración de Pedido

Objetivo: Alta, Modificación y Baja de Pedido
Actores: Administrador, Operador
Episodios:
Adición de Pedido según la Plantilla definida.
Modificación de Pedido, adición o eliminación de un determinado
producto.

78
 Baja de un Pedido, por entrega a destiempo.

Tabla 3.7: Administración de Pedido

Fuente: Elaboración Propia
Título: Procesos de Pedido
Objetivo: Descripción de Generación, Control de Pedido
Actores: Operador, Recepcionista
Episodios:
Generación de Pedido automático a través del stock en base a la cantidad
mínima por producto.
Control de pedidos de la cartera de clientes, con descripción de fechas y
estado de pedido (pendiente, aceptado, entregado, rechazado).
Control de pedidos por parte del cliente, para ver el estado de los pedidos
realizados.
Tabla 3.8: Procesos de Pedido
Fuente: Elaboración Propia

En la figura 3.19 se observa el diagrama de clases para especificar las tareas del sprint
2.

Figura 3.19: Diagrama de clases para la generación de pedido

Fuente: Elaboración Propia

79
En la figura 3.20 se observa de diagrama de procesos para identificar el
comportamiento del proceso de generación de pedido identificados en el sprint 2.

Figura 3.20: Diagrama de procesos para la generación de pedido

Fuente: Elaboración Propia

En la figura 3.21 se observa de diagrama de navegación para identificar el enlace

entre páginas de los procesos identificados en el sprint 2.

80
 Figura 3.21: Diagrama de navegación, pantallas de generación de pedidos
Fuente: Elaboración Propia

Según la revisión de las tareas del Sprint 2 se obtuvo los siguientes resultados como
se observa en las figuras: 3.22, 3.23, 3.24.

Figura 3.22: Pantalla de Registro de pedido manual

Fuente: Elaboración Propia

81
 Figura 3.23: Pantalla de Control de Pedidos
Fuente: Elaboración Propia

Figura 3.24: Pantalla de Aprobación de Pedido

Fuente: Elaboración Propia

82
3.5.3.3 SPRINT 3

En el tercer Sprint se detalla la implementación de los procesos necesarios para la

recepción de productos de una determinada plantilla y el registro de entrega del
pedido que se muestra en la tabla 3.9.

ID DESCRIPCIÓN PRIORIDAD TIEMPO ESTADO

HORAS
20 Registro de entrega del Media 7 Concluido
pedido
21 Registro de la recepción del Media 8 Concluido
pedido
22 Control de entrega y Media 5 Concluido
recepciones por parte de la
empresa
23 Control de la recepción de Media 5 Concluido
productos por parte del
Cliente
Tabla 3.9: Sprint 3
Fuente: Elaboración Propia

En las Figuras 3.25 y 3.26 podemos visualizar el diagrama de casos de uso del
proceso de recepción y entrega de pedido.

Figura 3.25: Diagrama Casos de Uso, recepción de pedido

Fuente: Elaboración Propia

83
 Figura 3.26: Diagrama Casos de Uso, registro de entrega de pedido
Fuente: Elaboración Propia

En la figura 3.27 se observa el diagrama de clases para especificar las tareas del tercer
sprint.

Figura 3.27: Diagrama de clases, especificación de recepción y entrega de pedido

Fuente: Elaboración Propia

En la figura 3.28 se observa de diagrama de procesos para identificar el

comportamiento del proceso de generación de pedido identificados en el sprint 2.

84
 Figura 3.28: Diagrama de procesos para la recepción generación de pedido
Fuente: Elaboración Propia

En la figura 3.29 se observa de diagrama de navegación para identificar el enlace

entre páginas de los procesos identificados en el sprint 3.

85
Figura 3.29: Diagrama de navegación de pantallas de recepción y entrega de pedido
Fuente: Elaboración Propia

Según la revisión de las tareas definidas en el Sprint 3 se obtuvo los siguientes

resultados como se observa en las siguientes figuras: 3.30

86
 Figura 3.30: Registro de recepción del producto
Fuente: Elaboración Propia

3.5.3.4 SPRINT 4

En el cuarto Sprint se detalla la implementación del proceso de generación de

devolución de productos.

ID DESCRIPCIÓN PRIORIDAD TIEMPO ESTADO

HORAS
24 Registro de devolución Alta 5 Concluido
25 Control de devolución por Alta 7 Concluido
parte de la empresa
26 Control de devolución por Media 5 Concluido
parte del cliente
Tabla 3.10: Sprint 4
Fuente: Elaboración Propia

87
En las Figuras 3.31 podemos visualizar el diagrama de casos de uso del proceso de
devolución de productos.

Figura 3.31: Diagrama Casos de Uso Proceso de Devolución

Fuente: Elaboración Propia

A partir de la figura: 3.31 tenemos la siguiente historia de usuario.

Título: Procesos de Devolución

Objetivo: Descripción de Proceso de devolución

Actores: Operador. Repartidor y Recepcionista

Episodios:

1. Registro de devolución de productos por fecha de vencimiento, o por

mal estado de productos.
2. Control de devolución por parte de la Empresa.
3. Control de devolución por parte del cliente.
Tabla 3.11: Proceso de devolución
Fuente: Elaboración Propia

En la figura 3.32 se observa el diagrama de clases para especificar las tareas del sprint
4.

88
 Figura 3.32: Diagrama de clases de la especificación devolución de productos
Fuente: Elaboración Propia

En la figura 3.33 se observa de diagrama de procesos para identificar el

comportamiento del proceso de generación de pedido identificados en el sprint 2.

Figura 3.33: Diagrama de procesos para la devolución de productos

Fuente: Elaboración Propia

89
En la figura 3.34 se observa de diagrama de navegación para identificar el enlace
entre páginas de los procesos identificados en el sprint 4.

Figura 3.34: Diagrama de navegación, pantallas de la devolución de productos

Fuente: Elaboración Propia

Según la revisión de las tareas del cuarto Sprint se obtuvo los siguientes resultados
que se muestra en la figura 3.35.

90
 Figura 3.35: Generación de la devolución de uno o más productos
Fuente: Elaboración Propia

3.5.3.5 SPRINT 5

En el quinto Sprint se detalla la implementación de los procesos de control de stock y

cierre diario que se muestra en la tabla 3.12.

ID DESCRIPCIÓN PRIORIDAD TIEMPO ESTADO

HORAS
27 Control stock de productos de Media 5 Concluido
la empresa
28 Control stock de productos Media 5 Concluido
por cliente

91
 29 Control de tipos de producto Media 5 Concluido
por cliente
30 Cierre diario de cada cliente Alta 7 Concluido
(Inventario)
Tabla 3.12: Sprint 5
Fuente: Elaboración Propia

En la Figura 3.36 podemos visualizar el diagrama de casos de uso de los procesos de

control de stock y cierre diario.

Figura 3.36: Diagrama Casos de Uso, control de Stock y cierre diario

Fuente: Elaboración Propia

A partir de la figura: 3.36 tenemos las siguientes historias de usuario que se muestra
en la tabla 3.13 y 3.14.

92
 Título: Administración de Productos

Objetivo: Verificación de disponibilidad de Productos

Actores: Operador, Recepcionista

Episodios:

1. Verificación de disponibilidad de producto por parte de la Empresa

en cada uno de los clientes.
2. Verificación de tipos de producto que se le provee a cada cliente.
Tabla 3.13: Administración de Productos
Fuente: Elaboración Propia

Título: Cierre Diario

Objetivo: Control de Cantidad de Producto

Actores: Administrador, Operador

Episodios:

1. Verificar cantidad vendida por producto.

2. Verificar cantidad disponible por producto.
3. Actualizar la cantidad existente por día en caso de abastecimiento,
venta o devolución de producto.
Tabla 3.14: Cierre Diario
Fuente: Elaboración Propia

En la figura 3.37 se observa el diagrama de clases para especificar las tareas del sprint
5.

93
 Figura 3.37: Diagrama de clases, especificación del control de stock y cierre diario
Fuente: Elaboración Propia

En la figura 3.38 se observa de diagrama de navegación para identificar el enlace

entre páginas de los procesos identificados en el sprint 5.

Figura 3.38: Diagrama de navegación, pantallas de control de Stock y cierre diario

Fuente: Elaboración Propia

94
Según la revisión de las tareas del quinto Sprint se obtuvo los siguientes resultados
que se muestran en la figura 3.39 y 3.40.

Figura 3.39: Control de stock diario

Fuente: Elaboración Propia

Figura 3.40: Cierre diario

Fuente: Elaboración Propia

95
3.5.3.6 SPRINT 6

En el sexto Sprint se detalla la implementación de las consultas y reportes disponibles

en el sistema reflejado en la tabla: 3.15.

ID DESCRIPCIÓN PRIORIDAD TIEMPO ESTADO

HORAS
31 Consulta de productos Alta 7 Concluido
existentes por cliente/sucursal
32 Consulta de pedidos por Alta 7 Concluido
cliente/sucursal
33 Consulta de devoluciones por Media 5 Concluido
cliente/sucursal
34 Consulta de cartera de Media 7 Concluido
clientes
35 Reporte de disponibilidad de Media 5 Concluido
productos
36 Reporte de devoluciones por Media 5 Concluido
cliente/sucursal
37 Reporte de número de Media 7 Concluido
pedidos en un determinado
mes y año.
38 Reporte de cartera de clientes Media 5 Concluido
39 Reporte de información por Media 5 Concluido
producto
40 Reporte de producto(s) con Media 7 Concluido
más venta
Tabla 3.15: Sprint 6
Fuente: Elaboración Propia

96
En la figura 3.41 y 3.42 podemos visualizar el diagrama de casos de las consultas y
reportes existentes en el sistema.

Figura 3.41: Diagrama Casos de Uso, reportes disponibles

Fuente: Elaboración Propia

Figura 3.42: Diagrama Casos de Uso, consultas disponibles

Fuente: Elaboración Propia

97
En la figura 3.43 se observa el diagrama de clases para especificar las tareas del sprint
6.

Figura 3.43: Diagrama de clases que especifican las consultas y reportes del sistema
Fuente: Elaboración Propia

En la figura 3.44 se observa de diagrama de navegación para identificar el enlace

entre páginas de los procesos identificados en el sprint 6.

98
 Figura 3.44: Diagrama de navegación, pantallas de consultas y reportes del sistema
Fuente: Elaboración Propia

Según la revisión de las tareas del sexto Sprint se obtuvo los siguientes resultados que
se observa en las figuras 3.45 y 3.46.

Figura 3.45: Consulta de productos existentes

Fuente: Elaboración Propia

99
Figura 3.46: Reporte formato .pdf de los productos existentes
Fuente: Elaboración Propia

100
 CAPITULO IV

CONTROL DE CALIDAD

4.1 INTRODUCCIÓN

En este capítulo se describe la calidad que tiene el sistema y la aplicación móvil, el

cálculo de calidad será en base a la norma ISO 9126 bajo la metodología WebQem,
descritas en el capítulo II. Además el objetivo de este capítulo es alcanzar un nivel de
calidad que satisfaga los objetivos propuestos para el sistema y la aplicación móvil.

A continuación se desarrolla las fases de la metodología WebQem:

4.1.1 DEFINICIÓN DE LAS METAS DE EVALUACIÓN Y SELECCIÓN DE

PERFIL DE USUARIO

En esta fase se procede a describir los siguientes puntos.

4.1.1.1 METAS Y ALCANCES

Las metas y alcances que ha definido el cliente o dueño del producto son los
siguientes:

 Registro de Producto.
 Automatizar Proceso de Entrega, devolución de Pedido.
 Obtener información digital a través de un dispositivo de escritorio o móvil.
 Satisfacer al cliente al momento de solicitar un pedido.
 Evitar pérdidas de los productos que se proveen.

4.1.1.2 PERFIL DE USUARIO

Lo perfiles de usuario que se han establecido y que tendrán acceso tanto al sistema
como la aplicación móvil son los siguientes:

 Administrador.

101
  Operador
 Repartidor
 Recepcionista.

4.1.2 DEFINICIÓN DE LOS REQUERIMIENTOS DE CALIDAD

En esta fase se aplica y cumple con las características de calidad interna y externa de
la norma ISO 9126.

4.1.2.1 FUNCIONALIDAD

Aplicando el punto de función se tienes las siguientes tablas 4.1, 4.2, 4.3 ,4.4, 4.5.
 Número de entradas externas
Nro. Entradas Externas Cantidad
1 Adición de tipo de producto 1
2 Registro de producto 1
3 Registro de cliente 1
4 Registro de sucursal 1
5 Registro de plantilla 1
6 Asignación de producto a plantilla 1
7 Realizar pedido 1
8 Aceptar/Rechazar pedido 1
9 Registro de Entrega 1
10 Registro de devolución 1
11 Aceptar/Rechazar devolución 1
12 Cierre diario por parte de la Empresa 1
13 Cierre diario por parte del cliente 1
Total 13
Tabla 4.1: Entradas Externas
Fuente: Elaboración Propia

102
 Número de salidas externas

Nro. Salidas Externas Cantidad

1 Lista de tipos de producto 1
2 Reporte de tipos de producto 1
3 Lista de producto 1
4 Reporte de Productos 1
5 Lista de Clientes 1
6 Reporte de Clientes con número de sucursales 1
7 Lista de sucursales 1
8 Lista de plantillas 1
9 Lista de pedidos 1
10 Reporte de pedidos por estado 1
11 Lista de Entrega de pedidos 1
12 Lista de Devolución de pedidos 1
13 Reporte de cierre diario de la Empresa 1
14 Reporte de cierre diario del cliente 1
Total 14
Tabla 4.2: Salidas Externas
Fuente: Elaboración Propia

 Número de Consultas Externas

Nro. Consultas Externas Cantidad

1 Búsqueda de producto 1
2 Búsqueda de cliente 1
3 Búsqueda de Sucursal 1
4 Búsqueda de Plantilla 1
5 Búsqueda de pedido por fecha 1
6 Búsqueda de pedido por estado 1

103
 7 Búsqueda de entrega por fecha 1
8 Búsqueda de entregas 1
9 Búsqueda de devoluciones 1
Total 9
Tabla 4.3: Consultas Externas
Fuente: Elaboración Propia

 Número de archivos lógicos internos: Se tomó en cuenta la base de datos del

producto y cada tabla cuenta como un archivo.
Nro. Archivos Lógicos Internos Cantidad
1 Tablas de a base de datos 23
Total 23
Tabla 4.4: Archivos lógicos internos
Fuente: Elaboración Propia

 Número de archivos de interfaz externo.

Nro. Archivos de Interfaz Externos Cantidad

1 Conexión con la base de datos 1
2 Conexión con la pantalla 1
3 Visualizador de archivos (reporte) Pdf 1
4 Visualizador de archivos (reporte) Excel 1
Total 4
Tabla 4.5: Archivos de interfaz externos
Fuente: Elaboración Propia

Ahora se procede al cálculo de entradas de puntos de función, como se observa en la

tabla 4.6.

Valor de dominio de información Conteo Factor de ponderación Cantidad

Entradas externas 13 3 39

104
Salidas externas 14 4 56
Consultas externas 9 3 27
Archivos lógicos internos 23 7 161
Archivos de interfaz externos 4 5 20
Conteo Total 303
Tabla 4.6: Calculo de entradas de punto de función
Fuente: Elaboración Propia

Se toma el siguiente criterio para los FAV (factores de ajuste de valor), que se
describen en la tabla 4.7.

Escala Valor
Esencial 5
Significativo 4
Medio 3
Moderado 2
Incidental 1
No Importante 0
Tabla 4.7: Rangos para evaluar punto de función
Fuente: Elaboración Propia

Habiendo definido los rangos, se procede con el cuestionario de Punto de Función,

descrita en la tabla 4.8.

Nro. Factor de Ajuste de Valor Valor

1 ¿El sistema requiere respaldo y recuperación confiables? 5
2 ¿Se requieren comunicaciones de datos especializadas para transferir 3
información hacia o desde la aplicación?
3 ¿Existen funciones de procesamiento distribuidas? 0
4 ¿El desempeño es crucial? 5
5 ¿El sistema correrá en un entorno operativo existente enormemente 5

105
 utilizado?
6 ¿El sistema requiere entrada de datos en línea? 4
7 ¿La entrada de datos en línea requiere que la transacción de entrada se 4
construya sobre múltiples pantallas u operaciones?
8 ¿Los ALI se actualizan en línea? 3
9 Las entradas, salidas, archivos o consultas son complejos? 5
10 ¿El procesamiento interno es complejo? 4
11 ¿El código se diseña para ser reutilizable? 5
12 ¿La conversión y la instalación se incluyen en el diseño? 5
13 ¿El sistema se diseña para instalaciones múltiples en diferentes 5
organizaciones?
14 ¿La aplicación se diseña para facilitar el cambio y su uso por parte del 5
usuario?
Total 58
Tabla 4.8: Factores de ajustes de valor
Fuente: Elaboración Propia

Procediendo al cálculo de PF (Punto de función) se tiene:

PF = Conteo Total * [0,65 + 0,01 * ∑(𝑓𝑖)

PF = 303 * [0,65 + 0,01 * 58] = 372.69

Para el cálculo del valor de la funcionalidad se hace comparación con el valor

máximo qué se podría tener qué seria 70, con lo que se tiene la siguiente relación:

PFmax = 303 * [0,65 + 0,01 * 70] = 409.05

Entonces, el valor de la funcionalidad es:

Funcionalidad = PF / PFmax

Funcionalidad = 372.69/ 409.05 = 0.91

106
Por lo tanto, la funcionalidad es:

Funcionalidad = 91%

4.1.2.2 CONFIABILIDAD

Aplicando la fórmula para el cálculo de tiempo medio entre fallos.

TMEF = TMDF + TMDR

TMEF = 15h + 1.5h = 16.5h

Calculamos la disponibilidad:

disponibilidad = TMDF / TMDF + TMDR

disponibilidad = 15h / 15h + 1.5h = 0.8421 = 90.90 %

Por lo tanto la confiabilidad es:

confiabilidad = 90.90%

4.1.2.3 USABILIDAD
Es un factor qué solo se puede medir indirectamente y está relacionado con el usuario
y con lo amigable qué puede ser el software con el usuario. Para esto se utilizó un
cuestionario y un rango de valores para la evaluación, descritas en las tablas en la
tabla 4.9, 4.10.
Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Tabla 4.9: Rangos para evaluar la usabilidad
Fuente: Elaboración Propia

107
El cuestionario está compuesto de 10 preguntas con la correspondiente valoración del
usuario, donde se puede observar los valores máximos y mínimos obtenidos para
cada pregunta, los valores obtenidos son de un promedio de 10 usuarios.

Nro. Pregunta Min Max Promedio

1 ¿Es fácil de recordar las órdenes y aprender 4 5 4.5
las operaciones básicas?
2 ¿Cómo considera los mensajes qué genera 4 5 4.5
el sistema, son entendibles?
3 ¿Considera usted qué el sistema es una 5 5 5
herramienta útil?
4 ¿Los reportes qué genera son útiles para su 4 5 4.5
trabajo?
5 ¿El sistema le sirve de ayuda para la toma 4 5 4.5
de decisiones?
6 ¿Recomendaría el sistema a otras 4 5 4.5
instituciones similares?
7 ¿Le es fácil orientarse respecto a las 3 5 4,4
acciones qué tiene a su disposición, en un
determinado instante?
8 ¿El sistema le proporciona suficiente 3 5 4.3
información para realizar sus tareas?
9 ¿La velocidad de respuesta del sistema es 4 5 4.5
óptima?
10 ¿El sistema llego a cumplir con todas sus 4 5 4.4
expectativas?
Tabla 4.10: Cuestionario para la valoración de usabilidad
Fuente: Elaboración Propia

En base a estos resultados obtenidos se puede tener una idea cuantitativa de la

usabilidad que tiene el producto, como a continuación podemos observar:

108
Donde:

Pi = Promedio obtenido por respuesta

P1 + P2 + P3 + P4 + P5 + P6 + P7 + P8 + P9 + P10 100
𝑢𝑠𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = *
𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎𝑠 5

4.5 + 4.5 + 5+ 4.5 + 4.5 + 4.5 + 4.4 + 4.3 + 4.5 + 4.4 100
𝑢𝑠𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = *
10 5

Usabilidad = 90.2 %

4.1.2.4 EFICIENCIA

A continuación en la tabla 4.11 se describe los rangos para evaluar la eficiencia.

Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Tabla 4.11: Rangos para evaluar la eficiencia
Fuente: Elaboración Propia

Realizando la valoración de mantenimiento del sistema y aplicación móvil, se tienen

las siguientes apreciaciones como se puede observar en la tabla 4.12.

Factor de ajuste Valor

¿Procesa rápidamente lista de plantillas? 5
¿Procesa rápidamente los pedidos? 5
¿Procesa rápidamente la consulta de clientes? 5
¿Procesa rápidamente devolución de productos? 4
¿Procesa rápidamente cierre diario? 5
Tabla 4.12: Valoración para la eficiencia
Fuente: Elaboración Propia

109
En base a los resultados obtenidos, se puede tener una idea cuantitativa de la
eficiencia del producto que continuación observamos:

Donde:

Vi = Valor obtenido por respuesta

V1 + V2 + V3 + V4 + V5 100
𝑒𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑖𝑎 = *
𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎𝑠 5

5+5+5+4+5 100
𝑒𝑓𝑖𝑐𝑖𝑒𝑛𝑐𝑖𝑎 = * = 96 %
5 5

4.1.2.5 MANTENIMIENTO

Se realiza la valoración a cada sub-atributo con el rango de valores de la tabla 4.13.

Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Tabla 4.13: Rangos para evaluar el mantenimiento
Fuente: Elaboración Propia

Para realizar la valoración del mantenimiento del producto, se tienen las siguientes
apreciaciones como se observa en la siguiente tabla 4.14.

Factor de ajuste Valor

¿Es fácil de analizar una falla o bug? 4
¿Se puede identificar las partes que deben 4
modificarse para resolver el bug o error?
¿Existe la facilidad de realizar cambios? 5
¿Los cambios permiten estabilidad? 5

110
 ¿Los cambios mejoran la facilidad al momento 5
de hacer pruebas?
Tabla 4.14: Valoración para el mantenimiento
Fuente: Elaboración Propia

En base a los resultados obtenidos se puede tener una idea cuantitativa de

mantenimiento como se puede ver:

Donde:

Vi = Valor obtenido por respuesta

V1 + V2 + V3 + V4 + V5 100
𝑚𝑎𝑛𝑡𝑒𝑛𝑖𝑚𝑖𝑒𝑛𝑡𝑜 = *
𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎𝑠 5

4 + 4 + 5+ 5 + 5 100
𝑚𝑎𝑛𝑡𝑒𝑛𝑖𝑚𝑖𝑒𝑛𝑡𝑜 = * = 92 %
5 5

4.1.2.6 PORTABILIDAD

Se realiza la valoración a cada sub-atributo con el rango de valores de la tabla 4.15.

Escala Valor
Excelente 5
Bueno 4
Aceptable 3
Deficiente 2
Pésimo 1
Tabla 4.15: Rangos para evaluar la portabilidad
Fuente: Elaboración Propia

Para realizar la valoración de portabilidad del producto, se tienen las siguientes

apreciaciones como se observa en la siguiente tabla 4.16.

111
 Factor de ajuste Valor
Facilidad de instalación 5
Facilidad de ajustes 4
Facilidad de adaptación a cambios 4
Producto multiplataforma 5
Compatibilidad con diferentes navegadores 5
Tabla 4.16: Valoración para el mantenimiento
Fuente: Elaboración Propia

En base a los resultados obtenidos se puede tener una idea cuantitativa de portabilidad
como se puede ver a continuación:

Donde:

Vi = Valor obtenido por respuesta

V1 + V2 + V3 + V4 + V5 100
𝑝𝑜𝑟𝑡𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = *
𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑟𝑒𝑔𝑢𝑛𝑡𝑎𝑠 5

5+4+4+5+5 100
𝑝𝑜𝑟𝑡𝑎𝑏𝑖𝑙𝑖𝑑𝑎𝑑 = * = 92 %
5 5

4.1.3 DEFINICIÓN DE CRITERIOS DE PREFERENCIA ELEMENTALES

Y PROCEDIMIENTOS DE MEDICIÓN

El resultado final es una preferencia o indicador elemental el cual puede ser

interpretado como el grado o porcentaje del requerimiento satisfecho.

Por lo tanto para los resultados obtenidos de las métricas de la norma ISO 9126 se
establece un resultado final, el cual se describe a continuación en la tabla 4.17.

Escala Valor
Funcionalidad 91%
Confiabilidad 90.90%
Usabilidad 90.20%

112
 Eficiencia 96.00%
Mantenimiento 92.00%
Potabilidad 92.00%
Promedio 92%
Tabla 4.17: Resultados de las características de calidad
Fuente: Elaboración Propia

4.1.4 DEFINICIÓN DE ESTRUCTURAS DE AGREGACIÓN Y

EVALUACIÓN GLOBAL

Se puede apreciar que el usuario final, tendrá una satisfacción del 86.01% al
momento de hacer uso del sistema o la aplicación móvil. Lo cual da una percepción o
noción de que nuestro producto es de calidad.

4.1.5 ANÁLISIS DE RESULTADOS Y RECOMENDACIONES

A continuación se describen los siguientes puntos:

 Como se observó anteriormente el resultado promedio de las características de

calidad nos indica que nuestro producto cuenta con un nivel de calidad
óptimo.
 Para que el Sistema sea de utilidad se debe capacitar a los usuarios del cliente
que intervendrán en el uso del sistema.

113
 CAPITULO V

SEGURIDAD

5.1 INTRODUCCIÓN

En este capítulo se desarrolla las características de seguridad que debe tener el

sistema y la aplicación móvil, tomando en cuenta las vulnerabilidades o riesgos más
comunes de acuerdo al informe recogido por el proyecto abierto de seguridad en
aplicaciones web OWASP descritas en el capítulo II.

Se aplicaran los incisos 1, 2, 4, 7, 9 del proyecto OWASP (que se adecuan al sistema

y aplicación móvil), para garantizar la confidencialidad, integridad y disponibilidad
de la información, donde se consideran los siguientes aspectos:

5.1.1 INYECCIÓN

 Se ha probado sentencias sql inyección desde el login del sistema y aplicación

móvil.

Figura 5.1: Prueba de sql inyección

Fuente: Elaboración Propia

 La Api que se está usando para el desarrollo cuenta con la seguridad ante
posibles entradas de sql inyección.

114
5.1.2 PÉRDIDA DE AUTENTICACIÓN Y GESTIÓN DE SESIONES

 El Sistema cuenta con el control de sesiones, ante un determinado tiempo de

inactividad el usuario debe realizar la autenticación nuevamente con las
credenciales correspondientes.
 Gestión de sesiones por página, solo puede estar autenticado una sesión de un
determinado usuario.
 La Url está encriptada de los datos enviados, ante posibles autenticaciones
fraudulentas.

Figura 5.2: Encriptación de Url

Fuente: Elaboración Propia

5.1.3 REFERENCIA DIRECTA INSEGURA A OBJETOS

 El usuario con rol de administrador es el encargado de asignar permisos y

roles a los usuarios que intervendrán en el sistema y aplicación móvil.
 Opciones del sistema y procesos según tipo de usuario de acuerdo al rol
asignado.

5.1.4 AUSENCIA DE CONTROL DE ACCESO A FUNCIONES

 Seguridad a nivel de roles, en el acceso a funcionalidades del sistema y

aplicación móvil.

115
  Seguridad a nivel de permisos, en los procesos que se tiene en el sistema y
aplicación móvil.

5.1.5 UTILIZACIÓN DE COMPONENTES CON VULNERABILIDADES

CONOCIDAS

 Tanto Genexus como Smart Device cuentan con un framework (Gam y

Advanced Security respectivamente) de seguridad propia de alto nivel, los
cuales se encargan de controlar vulnerabilidades.

116
 CAPITULO VI

ANÁLISIS COSTO BENEFICIO

6.1 INTRODUCCIÓN
Una de las tareas de mayor importancia en la administración de proyectos de software
es la estimación de costos. Si bien es una de las primeras actividades, inmediatamente
posterior al establecimiento de los requerimientos, se ejecuta regularmente a medida
que el proyecto progresa.

La estimación de costos de software tiene dos usos en la administración de proyectos:

 Durante la etapa de planeamiento: Permite decidir cuantas personas son

necesarias para llevar a cabo el proyecto y establecer el cronograma adecuado.
 Para controlar el progreso del proyecto: Es esencial evaluar si el proyecto está
evolucionando de acuerdo al cronograma y tomar las acciones correctivas si
fuera necesario.
6.2 MODOS DE DESARROLLO

En el modelo COCOMO’ 81 uno de los factores más importantes que influye en la

duración y el costo de un proyecto de software es el Modo de Desarrollo. Todo
proyecto corresponde a uno de los siguientes tres modos:

6.2.1 MODO ORGÁNICO

En esta clasificación se encuentran proyectos desarrollados en un ambiente familiar y

estable. El producto a elaborar es relativamente pequeño y requiere pocas
innovaciones tecnológicas en lo que refiere a algoritmos, estructuras de datos e
integración de hardware. La mayoría de las personas conectadas con el proyecto
tienen gran experiencia en sistemas relacionados dentro de la organización, y un
entendimiento acabado de cómo el sistema contribuirá a los objetivos de la
organización.

117
Esto significa que todo el equipo de desarrollo podrá contribuir en las etapas iniciales
del proyecto sin generar confusión en las comunicaciones debido a que todos conocen
que tarea deben realizar. Además, un proyecto clasificado dentro del modo orgánico,
es relativamente flexible en el cumplimiento de los requerimientos, especificaciones
de interface y tiempos de entrega.

Muy pocos proyectos de modo orgánico han desarrollado productos con más de 50
KSLOC de nuevo software. En los casos de productos más extensos, han sido
construidos frecuentemente a partir de software existente. Estas características
permiten decir que los proyectos que se encuentran en este modo tienen una gran
productividad y una pequeña deseconomía de escala. Ejemplos de software que se
encuentran bajo esta clasificación son:

 Modelos de negocios.
 Modelos científicos.
 Sistemas operativos de pequeña escala.

6.2.2 MODO SEMIACOPLADO

Es un modelo para productos de software de tamaño y complejidad media. Las

características de los proyectos se consideran intermedias a las de los modos
Orgánico y Empotrado. Esto implica:

Que el equipo de desarrollo:

 Tiene un nivel intermedio de experiencia y conocimiento del sistema en

desarrollo.
 Está conformado por algunas personas con vasta experiencia y otras
inexpertas en el campo de aplicación.
 Está constituido por personas con amplios conocimientos sólo en algunos
aspectos.

Con respecto al cumplimiento de especificaciones de interface y funcionalidad:

118
  Son sistemas que presentan niveles variados de exigencia, algunas interfaces
rigurosas (auditadas por el gobierno) y otras interfaces muy flexibles
(mensajes de display al operador).

Los productos tienen un tamaño que llega a 300 KSLOC.

Ejemplos de software que se encuentran en esta clasificación son:

 Sistemas de control de producción.

 Sistemas de procesamiento de transacciones.
 Administradores de Bases de Datos.

6.2.3 MODO EMPOTRADO

En esta clasificación están incluidos proyectos de gran envergadura que operan en un

ambiente complejo con altas restricciones de hardware, software y procedimientos
operacionales, tales como los sistemas de tráfico aéreo. Se espera que el software no
sólo conforme las especificaciones sino también que sea estable frente a cambios y
dificultades producidas en el ambiente.

Es decir, estos proyectos no tienen opción de negociar cambios y/o arreglos

provocados por modificaciones en los requerimientos y/o en las especificaciones de
interface. El proyecto dedica un gran esfuerzo para adaptarse a los cambios y
arreglos, en asegurar que el software cumpla verdaderamente las especificaciones y
que los cambios se efectúen correctamente. Esto implica altos costos en los procesos
de Verificación y Validación y en la Administración de la Configuración,
contribuyendo así a la disminución de la productividad y al aumento de las
deseconomías de escala en grandes proyectos.

El equipo que interviene en el proyecto tiene un conocimiento general de los

objetivos del mismo y una moderada experiencia en el tema. En general, el líder del
proyecto destina en las primeras etapas a un grupo pequeño del equipo a las tareas de
análisis, evitando así los problemas acarreados por la sobrecarga de comunicaciones.
Una vez que se completa el diseño global del producto, la mejor estrategia es delegar

119
a un gran equipo de programadores las tareas de diseño detallado, codificación y
testeo.

Ejemplos de software que se encuentran en esta clasificación son:

 Sistemas complejos de procesamiento de transacciones.

 Sistemas operativos de gran escala.

6.3 MODELO BÁSICO

El Modelo Básico de COCOMO’ 81 estima el esfuerzo y el tiempo empleado en el

desarrollo de un proyecto de software usando dos variables predictivas denominadas
factores de costo: el tamaño del software y el modo de desarrollo. Las ecuaciones
básicas son:

Esfuerzo:

PM = A x (KSLOC)𝐵

Dónde:

 PM es el esfuerzo estimado. Representa los meses-persona necesarios para

ejecutar el proyecto
 KSLOC es el tamaño del software a desarrollar en miles de líneas de código.
 A y B son coeficientes que varían según el Modo de Desarrollo (Orgánico,
Semiacoplado, Empotrado).

Cronograma

TDEV = C x (PM)𝐷

Dónde:

 TDEV representa los meses de trabajo que se necesitan para ejecutar el

proyecto.

120
  C y D son coeficientes que varían según el Modo de Desarrollo (Orgánico,
Semiacoplado, Empotrado)

A continuación se desarrolla el análisis del costo del desarrollo, tanto del sistema
como la aplicación móvil y los beneficios que obtendrá la empresa Tecnoalimentos
Ltda. y los clientes con los que cuenta.

Modo de Desarrollo Esfuerzo Cronograma

Orgánico PM=2.4 x (11.038)1.05 = TDEV=2.5 x (29.9)0.38 = 9.1
29.9
Semiacoplado PM=3.0 x (11.038)1.12 = TDEV=2.5 x (44.2)0.35 = 9.4
44.2
Empotrado PM=2.8 x (11.038)1.2 = TDEV=2.5 x (49.9)0.32 = 8.7
49.9
Tabla 5.1: Ecuaciones del Modelo Básico de COCOMO 81
Fuente: [Boehm, 1981]

Para obtener el número de (analistas, programadores, qa) requeridos según el modelo

(Semiacoplado) de nuestro sistema y aplicación móvil se tiene que:

PG = PM/TDEV= 44.2/9.4 = 4.7

El número de programadores que se requiere es de 5.

Ahora para la distribución del tiempo total de desarrollo del sistema colaborativo,
para cada fase se tiene que:

 30 % Análisis y Diseño
 40% Codificación
 30% Pruebas

De donde se tendrá que el tiempo para cada fase será:

 2 Meses Análisis y Diseño

121
  1 Meses Pruebas
 2 Meses Codificación

6.3.1 COSTO DE DESARROLLO

Personal: Analistas y Programadores 3800$

Analistas (300 $ / mes, durante 2 meses): 2 analistas
Programadores (500 $/mes, durante 4 meses): 4 programadores
Pruebas (400 $ / mes, durante 3 meses): 1 qa
Alquiler Equipo (100 $ / mes, durante 9 meses) 900 $
Material: 10$

Costo total de desarrollo: 4710 $

6.4 VALOR ACTUAL NETO (VAN)

El VAN es un indicador financiero que mide los flujos de los futuros ingresos y
egresos que tendrá un proyecto, para determinar, si luego de descontar la inversión
inicial, nos quedaría alguna ganancia. Si el resultado es positivo, el proyecto es
viable.

La fórmula del VAN es:

VAN = BNA – Inversión

Dónde:

El beneficio neto actualizado (BNA) es el valor actual del flujo de caja o beneficio
neto proyectado, el cual ha sido actualizado a través de una tasa de descuento.

La tasa de descuento (TD) con la que se descuenta el flujo neto proyectado, es el la

tasa de oportunidad, rendimiento o rentabilidad mínima, que se espera ganar; por lo
tanto, cuando la inversión resulta mayor que el BNA (VAN negativo o menor que 0)
es porque no se ha satisfecho dicha tasa. Cuando el BNA es igual a la inversión

122
(VAN igual a 0) es porque se ha cumplido con dicha tasa. Y cuando el BNA es mayor
que la inversión es porque se ha cumplido con dicha tasa y además, se ha generado
una ganancia o beneficio adicional.

 VAN > 0 el proyecto es rentable.

 VAN = 0 el proyecto es rentable también, porque ya está incorporado
ganancia de la TD.
 VAN < 0 el proyecto no es rentable.

Entonces para hallar el VAN se necesitan:

 Tamaño de la inversión.
 Flujo de caja neto proyectado.
 Tasa de descuento.

El proyecto como ya se había visto en el punto 5.2.1 tiene una inversión de 4710 $ y
una tasa de descuento (TD) de 14% para 5 años se estima que:

año 1 año 2 año 3 año 4 año 5

Flujo de caja neto 4000 4000 4000 4000 5000

Tabla 5.2: Flujo de caja neto
Fuente: Elaboración propia

Por lo tanto se tiene que:

 El beneficio neto nominal sería de 21000 $ (4000 + 4000 + 4000 + 4000 +

5000)
 La utilidad lógica sería 16290 $ (21000 – 4710), pero este beneficio o
ganancia no sería real (sólo nominal) porque no se estaría considerando el
valor del dinero en el tiempo, por lo que cada periodo debemos actualizarlo a

123
 través de una tasa de descuento (tasa de rentabilidad mínima que esperamos
ganar).

Hallando el VAN:

VAN = 4000 / (1 + 0.14)1 + 4000 / (1 + 0.14)2 + 4000 / (1 + 0.14)3 + 4000 / (1 +

0.14)4 + 5000 / (1 + 0.14)5 – 4710

VAN = 3508 + 3077 + 2700 + 2368 + 2596 – 4710

VAN = 9539 $

6.5 TASA INTERNA DE RETORNO (TIR)

La TIR es la tasa de descuento (TD) de un proyecto de inversión que permite que el

BNA sea igual a la inversión (VAN igual a 0). La TIR es la máxima TD que puede
tener un proyecto para que sea rentable, pues una mayor tasa ocasionaría que el BNA
sea menor que la inversión (VAN menor que 0).

Entonces para hallar la TIR se necesitan:

 Tamaño de inversión.
 Flujo de caja neto proyectado.

Para hallar la TIR hacemos uso de la fórmula del VAN, sólo que en vez de hallar el
VAN (reemplazamos por 0), estaríamos hallando la tasa de descuento:

VAN = BNA – Inversión

0 = 4000 / (1 + i)1 + 4000 / (1 + i)2 + 4000 / (1 + i)3 + 4000 / (1 + i)4 + 5000 / (1 +

i)5 – 4700

TIR = 81%

124
Como el TIR es alto, estamos ante un proyecto empresarial rentable, que supone un
retorno de la inversión equiparable a unos tipos de interés altos que posiblemente no
se encuentren en el mercado. Sin embargo, si el TIR hubiera sido bajo, posiblemente
podríamos encontrar otro destino para el dinero invertido.

125
 CAPITULO VII

CONCLUSIONES Y RECOMENDACIONES

En base a nuestros objetivos planteados, se tiene las siguientes conclusiones y

recomendaciones, las cuales se describen a continuación.

7.1 CONCLUSIONES
Con la implementación del sistema y la aplicación móvil se puede concluirlo
siguiente:

 Se ha logrado mejorar el cronograma del proceso de entrega de pedidos.

 Informar el motivo de las devoluciones realizadas con las cantidades por
producto.
 Facilitar el registro y obtención de información del registro de pedido, entrega
y devolución.
 Recabar información de cantidades existentes de productos por cliente.
 Brindar información que sea de interés para la empresa Tecnoalimentos Ltda .
acerca de clientes, pedidos, entregas, devoluciones, productos, a través de
reportes.

7.2 RECOMENDACIONES
Las recomendaciones que se pueden mencionar y que debe tener en cuenta el cliente
se especifican a continuación:

 Realizar copias de seguridad de la base de datos correspondientes a clientes,

productos, pedidos.
 Informar a los usuarios que harán uso del sistema, sobre la confidencialidad
de las credenciales para el acceso al Sistema.
 En caso de que un usuario ya no sea parte de la empresa o del cliente, el
administrador debería cambiar el estado del usuario a inactivo para que no
realice ningún tipo de operación.

126
 Realizar el cierre diario para mantener la cantidad de producto actualizado
para generar el pedido automático.

127
BIBLIOGRAFÍA

REFERENCIAS BIBLIOGRÁFICAS

Alfonzo, P. (2012) Revisión de modelos para evaluar la calidad de productos Web.

Experimentación en portales bancarios del NEA

Arenas, S. (2012) Desarrollo de la Metodología del Marco Lógico.

Canqui, R. (2011) Sistema de información para control de producción y almacenes

Caso Unidad de Prendas Compañía de Productos Camélidos.

Carballo, Y. (2007) Programación Orientada a Objetos.

Choque, R. (2009) Sistema de información de compras e inventarios SAMA

Fundación Owasp. (2008) Guía de Pruebas Owasp.

Hernández, S. (2006) Metodología de la Investigación.

Manueco, D. (2011) Sistema de gestión y seguimiento para almacén de materiales de

Vidrio caso: Carrera de Química.

Guerrero, J. (2014) UWE en Sistema de Recomendación de Objetos de Aprendizaje.

Aplicando Ingeniería Web: Un Método en Caso de Estudio.

Palacio, J. (2014) Gestión de Proyectos Scrum Manager.

Pressman, R. (2010) Ingeniería del Software un Enfoque Práctico, Séptima Edición.

Ramírez, R. (2012) Métodos para el Desarrollo de Aplicaciones Móvil.

128
REFERENCIAS ELECTRÓNICAS

[1] International Function Point users group. (s.f). About Function Point Analysis.
Obtenido de http://www.ifpug.org/about-ifpug/about-function-point-analysis/.

129
 ANEXOS

- ANEXO A: Árbol de Problemas

- ANEXO B: Árbol de Objetivos

- ANEXO C: Marco Lógico

130
 ANEXO A:

ÁRBOL DE PROBLEMAS

131
 ANEXO B:

ÁRBOL DE OBJETIVOS

132
 ANEXO C:

MARCO LÓGICO

RESUMEN MEDIOS DE SUPUESTOS

NARRATIVO INDICADORES VERIFICACION

Automatizar el Realizar una Se realizara una Uso constante por

Proceso de Registro evaluación cada encuesta al personal parte del personal
y Control de cierto periodo encargado para ver a cargo del
Productos, sobre el proceso de la magnitud en la Sistema y la
desarrollando un control para ver si que favorece la aplicación móvil
Sistema de Calidad los propietarios de usabilidad del para mejorar el
el cual ayude al la Empresa están Sistema y control de
crecimiento y satisfechos con la aplicación móvil en productos y de
estabilidad de la Automatización de el proceso de esta manera
Empresa. sus procesos. Control de ayudar al
productos. crecimiento,
estabilidad de la
Empresa.

Mejorar el control Se espera que Reportes en cuanto El Sistema y la

de la disponibilidad, disminuya los se refiere a la aplicación móvil
envió, devolución reclamos por parte disponibilidad, deben ser
de productos a de los Propietarios envió, informes de administrados por
través de la de la Empresa ante tipos de productos el personal a
Automatización en perdidas, entregas, que requieren los cargo y los

133
el Control de la devoluciones de clientes en el propietarios de la
Información de productos que se momento que se Empresa para
productos para la realiza a los requiera. realizar el uso
Empresa clientes correcto.
Tecnoalimentos
Ltda. Haciendo uso
de Tecnologías Web
y Móvil.

Diseño e
Implementación
-Registro de Realizar prueba El Personal
del módulo de
Información sobre cada uno de Encargado y
Registro (del
correspondiente a los módulos y a Clientes de la
28/02/2016 al
insumos, productos través de esto Empresa deben
13/03/2016).
a través del Módulo generar informes realizar los
de Registro. sobre los resultados procesos de
obtenidos de las registro, entrega,
pruebas realizadas devolución
-Control de envíos, Diseño e para cada uno de los haciendo uso del
devoluciones, stock Implementación módulos. Sistema para
de productos que se del módulo de disponer de

hace a los clientes, Control (del información

el cual se realizara 13/03/2016 al confiable.

mediante el módulo 06//04/2016).

de Control.

-Emisión de
Reportes

134
correspondientes a
Diseño e
los productos,
Implementación
clientes que tiene la
del Módulo de
Empresa, a través
Reportes (del
del Módulo de
06/04/2016 al
Reportes.
29/04/2016).

-Definición del -Diseñador Realizar informes Se deben respetar

Product Backlog. Bs 3500. continuos de las fechas
información acerca establecidas para
-Planificación de -Programador
del avance de los realizar el diseño,
Sprints. Bs 4200.
módulos para implementación y

Ejecución de -Control de observar el proceso la etapa de

Sprints. Calidad Bs 3500. de Implementación pruebas para cada

del Sistema. uno de los
-Control de Calidad. -Monto módulos del
aproximado: Bs Sistema.
-Retroalimentación.
1200.

135
DOCUMENTACIÓN

136