Monografia Final COIN FINAL Agosto 2019

DESARROLLO DE UN SOFTWARE DE ADMINISTRACIÓN DE PRODUCTOS,
FACTURACIÓN, PAGOS Y CARTERA PARA LA EMPRESA PLÁSTICOS Y
DESECHABLES LIBIA DE AGUA DE DIOS, CUNDINAMARCA.
NAYIBE SORAYA SANCHEZ LEÓN
Investigador Principal
ALEJANDRA ROMERO RUIZ
CRISTIAN OSWALDO LOZADA TOVAR
JOSÉ ALEXANDER AGUILAR GONZÁLEZ
LUIS R. RAMÍREZ LIÉVANO
MELISSA RIVERA GUZMÁN
SORAYA JIMÉNEZ MONTAÑA
Coinvestigadores
INSTITUTO TOLIMENSE DE FORMACION TECNICA
PROFESIONAL “ITFIP”
INGENIERIA Y CIENCIAS AGROINDUSTRIALES
TECNOLOGIA EN GESTION INFORMATICA
ESPINAL TOLIMA
2019
DESARROLLO DE UN SOFTWARE DE ADMINISTRACIÓN DE PRODUCTOS,
FACTURACIÓN, PAGOS Y CARTERA PARA LA EMPRESA PLÁSTICOS Y
DESECHABLES LIBIA DE AGUA DE DIOS, CUNDINAMARCA.
Investigador Principal
ALEJANDRA ROMERO RUIZ
CRISTIAN OSWALDO LOZADA TOVAR
JOSÉ ALEXANDER AGUILAR GONZÁLEZ
LUIS R. RAMÍREZ LIÉVANO
MELISSA RIVERA GUZMÁN
SORAYA JIMÉNEZ MONTAÑA
Coinvestigadores
INSTITUTO TOLIMENSE DE FORMACION TECNICA
PROFESIONAL “ITFIP”
INGENIERIA Y CIENCIAS AGROINDUSTRIALES
TECNOLOGIA EN GESTION INFORMATICA
ESPINAL TOLIMA
2019
Nota de Aceptación
Presidente del Jurado
Jurado
Jurado
AGRADECIMIENTOS
En esta página se agradece a la Magister Nayibe Soraya Sánchez León (Dirección de investigación)
por habernos dedicado el tiempo, el espacio y los esfuerzos necesarios para orientarnos en el
desarrollo y elaboración de la presente monografía.
También agradecemos a las personas que formaron parte importante de este proyecto como los
son los comerciantes de Desechables Libia De Agua De Dios, Cundinamarca, ya que gracias a su
colaboración se pudo lograr el objetivo de brindar una solución tecnológica que permita resolver
la necesidad real.
Y por último agradecemos a nuestros familiares por darnos el apoyo indispensable para poder
seguir el desarrollo del proyecto.

CONTENIDO
1. INTRODUCCIÓN........................................................................................................ 18
1 OBJETIVOS..................................................................................................................... 21
1.1 OBJETIVO GENERAL ........................................................................................... 21
1.2 OBJETIVOS ESPECÍFICOS.................................................................................. 21
2 PLANTEAMIENTO DEL PROBLEMA ...................................................................... 22
2.1 DESCRIPCIÓN DEL PROBLEMA ....................................................................... 22
2.2 HIPÓTESIS DEL PROBLEMA ............................................................................. 23
2.3 DEFINICIÓN DEL PROBLEMA .......................................................................... 23
3 JUSTIFICACIÓN ............................................................................................................ 24
4 MARCO REFERENCIAL DE LA INVESTIGACIÓN ............................................... 27
4.1 ENTIDADES QUE REGULAN EL COMERCIO EN COLOMBIA .................. 28
4.2 FACTURACIÓN ...................................................................................................... 33
4.3 INVENTARIOS ........................................................................................................ 34
5 LA INVESTIGACIÓN EN EL CAMPO DEL DESARROLLO DEL SOFTWARE 39
5.1 MÉTODOS Y/O TÉCNICA PARA IDENTIFICAR LA PROBLEMÁTICA EN
LA INVESTIGACIÓN. .......................................................................................................... 40
5.2 ANÁLISIS DE REQUERIMIENTOS EN LA INGENIERÍA DEL SOFTWARE
44
5.3 ESTUDIO DE FACTIBILIDAD EN EL DESARROLLO DEL SOFTWARE .. 45

5.4 CICLO DE VIDA DEL SOFTWARE .................................................................... 47
5.5 METODOLOGÍAS DE DESARROLLO DEL SOFTWARE .............................. 51
6 MARCO LEGAL DE LA INVESTIGACIÓN .............................................................. 56
6.1 REGLAMENTACIÓN DE TRABAJO DE GRADOS ......................................... 56
6.2 FACTURACIÓN EN ESTABLECIMIENTOS COMERCIALES ...................... 56
6.3 PRESENTACIÓN DE INFORME DE GESTIÓN. ............................................... 57
7 ESTADO DEL ARTE O ANTECEDENTES ................................................................ 59
8 METODOLOGÍA DE LA INVESTIGACIÓN ............................................................. 63
8.1 TIPO DE INVESTIGACIÓN .................................................................................. 63
8.2 POBLACIÓN DE LA INVESTIGACIÓN ............................................................. 63
8.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN .................................... 64
9 MARCO DE TRABAJO PARA EL DESARROLLO ÁGIL DE SOFTWARE:
SCRUM ........................................................................................................................................ 65
9.1 PLANEACIÓN DEL PROYECTO “COIN” ......................................................... 72
9.2 CONFORMACIÓN DEL EQUIPO ........................................................................ 73
9.3 GESTIÓN RIESGOS DEL PROYECTO .............................................................. 74
9.4 ESTUDIO DE FACTIBILIDAD ............................................................................. 96
Factibilidad operativa..................................................................................................... 96
Factibilidad legal. ............................................................................................................ 97
Factibilidad de tiempo. ................................................................................................... 97

9.5 Alcances y limitaciones del proyecto..................................................................... 109
9.5.1 Alcance del proyecto COIN. ........................................................................... 110
9.5.2 Requerimientos funcionales. .......................................................................... 110
10 PLANEACIÓN Y GESTIÓN DEL PROYECTO ................................................... 123
10.1 MODELO CONCEPTUAL DE DATOS .......................................................... 123
10.2 MODELO RELACIONAL ................................................................................ 124
10.3 DICCIONARIO DE DATOS PROYECTO COIN .......................................... 125
10.4 FUNCIONAMIENTO DEL SOFTWARE COIN EXPLICADO A TRAVÉS
DEL LENGUAJE DE MODELADO UNIFICADO (UML). ............................................ 132
11 INTERFAZ GRÁFICA DE LA APLICACIÓN ...................................................... 150
11.1 ESTILO DE PROGRAMACIÓN...................................................................... 150
11.2 ARQUITECTURA DE LA APLICACIÓN ...................................................... 152
11.3 CARACTERÍSTICAS QUE SE REQUIEREN PARA EL
FUNCIONAMIENTO DE COIN ......................................................................................... 153
11.4 COLORES. .......................................................................................................... 154
11.5 ICONOS. .............................................................................................................. 155
11.6 MENÚ. ................................................................................................................. 157
11.7 BOTONES. .......................................................................................................... 158
11.8 MENSAJES DE INFORMACIÓN Y ALERTA .............................................. 159
12 PRUEBAS DEL SOFTWARE APLICADAS A COIN .......................................... 160

12.1 PLAN DE PRUEBAS ......................................................................................... 161
12.2 ALCANCE DEL PLAN DE PRUEBAS DE COIN ......................................... 161
12.3 CRONOGRAMA DEL PLAN DE PRUEBAS ................................................. 162
12.4 Pruebas de software tipo caja negra y caja blanca .......................................... 163
12.5 TESTWARE A UTILIZAR PARA PRUEBAS DEL SOFTWARE COIN ... 166
12.6 RESULTADOS OBTENIDOS DE LAS PRUEBAS. ....................................... 167
12.6.1 Resultados Pruebas unitarias ..................................................................... 167
12.6.2 Resultados de Pruebas De Estrés ............................................................... 170
12.6.3 Resultados De Las Pruebas De Validación................................................ 173
12.6.4 Resultados de las pruebas de seguridad .................................................... 174
12.6.5 Resultados de las pruebas de despliegue ................................................... 175
12.6.6 Resultados De Las Pruebas De Interfaz Grafica ...................................... 178
13 Conclusiones ............................................................................................................... 182
14 Referencias Bibliográficas ......................................................................................... 183
15 Bibliografía ................................................................................................................. 187

LISTA DE TABLAS
Tabla 1 Sprint N°1Determinación De Premisas De COIN ...................................................... 67
Tabla 2 Sprint N°2 Diseño de la base de datos de COIN......................................................... 68
Tabla 3 Sprint N°3 Diseño Y Desarrollo De Módulos ............................................................ 69
Tabla 4 Pila de requerimientos y prioridades de COIN ........................................................... 70
Tabla 5 Probabilidad de presencia de los riesgos..................................................................... 75
Tabla 6 Tabla de nivel de impacto ........................................................................................... 76
Tabla 7 Tabla de probabilidades e impacto.............................................................................. 76
Tabla 8 Tabla del Nivel de Riesgo. .......................................................................................... 77
Tabla 9 Matriz de evaluación de riesgos 001 a 005. ................................................................ 79
Tabla 10 Matriz de evaluación de riesgos 006 a 010. .............................................................. 80
Tabla 14 Matriz de evaluación de riesgos 026-030. ................................................................ 84
Tabla 18 Plan de contingencia para riesgos del 001 al 009. .................................................... 88
Tabla 22. Cronograma de actividades proyecto COIN ............................................................ 99

Tabla 23 Recursos Tecnológicos para el desarrollo de COIN ............................................... 104
Tabla 24 Descripción y cuantificación de los equipos de uso propio (en miles de $). .......... 107
Tabla 25. Papelería y útiles de escritorio (en miles de $) ...................................................... 107
Tabla 26. Gastos de Transporte, Alimentación y otros. ......................................................... 108
Tabla 27 Costo del grupo de producción tecnológica. (En miles de $) ................................. 108
Tabla 28 Diccionario de datos tabla Cliente .......................................................................... 126
Tabla 29 Diccionario de datos tabla Proveedor ..................................................................... 126
Tabla 30 Diccionario de datos tabla Tipo teléfono usuario ................................................... 126
Tabla 31 Diccionario de datos tabla Documento ................................................................. 127
Tabla 32 Diccionario de datos tabla cargo ............................................................................. 127
Tabla 33. Diccionario de datos tabla Departamento .............................................................. 127
Tabla 34 Diccionario de datos tabla municipio...................................................................... 127
Tabla 35 Diccionario de datos tabla pagos ............................................................................ 127
Tabla 36. Diccionario de datos tabla país .............................................................................. 128
Tabla 37 Diccionario de datos tabla categoría ....................................................................... 128
Tabla 38. Diccionario de datos tabla Inventario .................................................................... 128
Tabla 39 Diccionario de datos tabla Artículos ....................................................................... 128
Tabla 40 Diccionario de datos tabla Detalle de Inventario .................................................... 129
Tabla 41 Diccionario de datos tabla marca ............................................................................ 129
Tabla 42 Diccionario de datos tabla Factura .......................................................................... 129
Tabla 43 Diccionario de datos tabla deuda ............................................................................ 130
Tabla 44 Diccionario de datos tabla Detalles de factura ........................................................ 130
Tabla 45 Diccionario de datos tabla Movimiento devolución ............................................... 130

Tabla 46 Diccionario de datos tabla usuario .......................................................................... 131
Tabla 47 Diccionario de datos tabla vigencia usuario ........................................................... 131
Tabla 48 Diccionario de datos tabla Devoluciones ................................................................ 131
Tabla 49 Diccionario de datos tabla teléfono ......................................................................... 132
Tabla 50 Tabla Descripción diagrama de secuencia de COIN. Registrar artículos ............... 140
Tabla 51 Descripción diagrama de secuencia de COIN. Registrar categorías. ...................... 140
Tabla 52 Descripción diagrama de secuencia de COIN. Registrar clientes. .......................... 141
Tabla 53 Diagrama de secuencia de COIN. Registrar proveedores. ...................................... 142
Tabla 54 Descripción diagrama de secuencia de COIN. Registrar usuarios.......................... 143
Tabla 55 Descripción diagrama de secuencia de COIN. Anular pedido................................ 144
Tabla 56 Descripción diagrama de secuencia de COIN. Buscar artículo. ............................. 145
Tabla 57 Descripción diagrama de secuencia de COIN. Generar copia de seguridad. .......... 146
Tabla 58 Descripción diagrama de secuencia de COIN. Generar reportes. ........................... 147
Tabla 59 Descripción diagrama de secuencia de COIN. Devoluciones por cliente............... 148
Tabla 60. Cronograma del plan de pruebas. ........................................................................... 162
Tabla 61. Pruebas de software tipo caja negra y caja blanca. ................................................ 163
Tabla 62. Pruebas del software empleadas. ........................................................................... 165
Tabla 63. Resultados obtenidos de la prueba con la herramienta PHPunit. ........................... 169
TABLA DE ILUSTRACIONES
Ilustración 1. Árbol del problema. ........................................................................................... 23
Ilustración 2. Modelo de Cascada. ........................................................................................... 49
Ilustración 3. Modelo Espiral. .................................................................................................. 51
Ilustración 4. El Sprint. ............................................................................................................ 52
Ilustración 5. Fases de la guía de PMBOK. ............................................................................. 75
Ilustración 6. Recursos de Software necesarios para el desarrollo del producto COIN......... 105
Ilustración 7. Recursos de Software necesarios para el desarrollo del producto COIN......... 106
Ilustración 8. ER, Modelo entidad relación. .......................................................................... 124
Ilustración 9. Modelo relacional base datos COIN. ............................................................... 125
Ilustración 10. Diagrama de caso de uso de COIN. Funciones Generales. ............................ 134
Ilustración 11. Diagrama de caso de uso de COIN. Función Registrar del administrador. ... 135
Ilustración 12. Diagrama de caso de uso de COIN. Función editar del administrador. ......... 135
Ilustración 13. Diagrama de caso de uso de COIN. Consultas del administrador. ................ 136
Ilustración 14. Diagrama de caso de uso de COIN. Realizar pedidos. .................................. 136
Ilustración 15. Diagrama de caso de uso de COIN. Ver estadísticas. .................................... 137
Ilustración 16. Diagrama de caso de uso de COIN. Generar copias de seguridad. ................ 137
Ilustración 17. Diagrama de caso de uso de COIN. Función registrar del empleado. ........... 138
Ilustración 18. Diagrama de caso de uso de COIN. Consultas del empleado. ....................... 138
Ilustración 19. Diagrama de secuencia de COIN. Registrar artículos.................................... 139
Ilustración 20. Diagrama de secuencia de COIN. Registrar categorías. ................................ 140
Ilustración 21. Diagrama de secuencia de COIN. Registrar clientes. .................................... 141
Ilustración 22. Diagrama de secuencia de COIN. Registrar proveedores. ............................. 142

Ilustración 23. Diagrama de secuencia de COIN. Registrar usuarios. ................................... 143
Ilustración 24. Diagrama de secuencia de COIN. Anular pedido. ......................................... 144
Ilustración 25 Diagrama de secuencia de COIN. Buscar artículo. ......................................... 145
Ilustración 26 Diagrama de secuencia de COIN. Generar copia de seguridad. ..................... 146
Ilustración 27. Diagrama de secuencia de COIN. Generar reportes. ..................................... 147
Ilustración 28. Diagrama de secuencia de COIN. Devoluciones por cliente. ........................ 148
Ilustración 29 Paradigmas, reglas y lenguajes en la programación........................................ 152
Ilustración 30 Arquitectura Cliente/Servidor. ........................................................................ 153
Ilustración 31. Paleta de colores............................................................................................. 154
Ilustración 32. Iconos de software Coin Parte 1. ................................................................... 155
Ilustración 33 Iconos de software Coin Parte 2 ..................................................................... 156
Ilustración 34 Iconos de software Coin Parte 3 ..................................................................... 157
Ilustración 35 Menú Rol Administrador del sistema ............................................................ 158
Ilustración 36. Botones de la COIN. ...................................................................................... 158
Ilustración 37. Mensajes de información y alerta de COIN. .................................................. 159
Ilustración 38. Fases de las pruebas del software. ................................................................. 160
Ilustración 39. Plan de pruebas de COIN. .............................................................................. 162
Ilustración 40. Testware a utilizar para pruebas del software COIN. .................................... 167
Ilustración 41. Pruebas unitarias con la herramienta PHPunit. .............................................. 168
Ilustración 42. Pantallazo de prueba con la herramienta PHPunit. ........................................ 168
Ilustración 43. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 100 usuarios. ....... 171
Ilustración 44. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 200 usuarios. ....... 172
Ilustración 45. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 2000 usuarios-1. .. 172
Ilustración 46. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 2000 usuarios-2. .. 172
Ilustración 47. Resultados de las pruebas de validación. ....................................................... 173
Ilustración 48. Resultados de las pruebas de seguridad. ........................................................ 174
Ilustración 49. Resultados de las pruebas de seguridad-2. ..................................................... 175
Ilustración 50. Resultado de las pruebas de despliegue en Opera.......................................... 176
Ilustración 51. Resultados de las pruebas de despliegue en Chrome. .................................... 176
Ilustración 52. Resultados de las pruebas de despliegue en Firefox. ..................................... 177
Ilustración 53. Pruebas de despliegue en dispositivos móviles.............................................. 177
Ilustración 54. Pruebas de interfaz gráfica en ordenadores.................................................... 179
Ilustración 55. Pruebas de interfaz gráfica en ordenadores-2. ............................................... 179
Ilustración 56. Pruebas de interfaz gráfica en ordenadores-3. ............................................... 180
Ilustración 57. Pruebas de interfaz gráfica en dispositivos móviles ...................................... 181
Ilustración 58. Pruebas de interfaz gráfica en dispositivos moviles-2. .................................. 181

GLOSARIO
a) Facturación: Es un documento el cual contiene toda la información principal de la
compraventa de un producto en un determinado establecimiento comercial.
b) Inventarios: Es el consolidado de las operaciones realizadas por los productos o
servicios ofrecidos en una empresa, logrando determinar el funcionamiento realizado por
cada uno de ellos y el proceso que lleva.
c) DIAN: Dirección de Impuestos y Aduanas Nacionales. Esta organización se encarga de
asegurar y proteger la economía pública del país, así como también garantizar su
seguridad fiscal.
d) MINTIC: Ministerio de Tecnologías de la Información y Comunicaciones. Este
ministerio es el encargado de diseñar, administrar y promover los diferentes planes,
programas y proyectos que tengan relación con las TIC (Tecnologías de la Información y
la Comunicación).
e) BANCOLDEX: Banco De Desarrollo Colombiano. Es el encargado del desarrollo de
material tanto financiero como no financiero, que sirvan de apoyo para el crecimiento de
las diferentes empresas establecidas en Colombia.
f) SIIGO: Sistema Integrado de Información Gerencial Operativo, este software sirve de
ayuda para las empresas colombianas, ya que permiten realizar registros detallados de las
diferentes actividades u operaciones que estas realicen.
g) FIDUCOLDEX: Fiduciaria Colombiana de Comercio Exterior. Esta es una sociedad que
busca ser un apoyo para los servicios financieros de la economía en el comercio exterior.
Ayudando a la administración de activos que suplan las necesidades de los clientes de
manera eficiente.
RESUMEN
La información se constituye como uno de los activos más valiosos para toda empresa
puesto que de ella depende la toma de decisiones que puede afectarla o lograr un papel
fundamental en su crecimiento económico.
La implementación del software se dio como solución al problema que se presentaba en
la microempresa Desechables Libia, el cual era el inadecuado uso, procesamiento y
resultados en el sistema de administración de inventarios y facturación. Como marco
metodológico para la ingeniería se hace uso de la SCRUM y sus tres fases. La solución
propuesta, lleva a lograr el resultado más importante de esta investigación, que es el Software
COIN.
Dentro del proceso investigativo y el desarrollo del proyecto permitió: comprender que la
investigación es una acción inherente de las personas, y que a través de la práctica se logra
perfeccionar, teniendo en cuenta lo anterior, se ponen en práctica los conocimientos
adquiridos durante la formación académica. Además de trabajar en un contexto empresarial
adquiriendo experiencia en el desarrollo de software.
Palabras Claves: Factura, inventario, SCRUM, microempresa, software.

ABSTRACT
The information is constituted as one of the most valuable assets for any company since it
depends on the decision making that can affect it or achieve a fundamental role in its economic
growth.
The software implementation was given as a solution to the problem that was presented in the
Libya Disposable microenterprise, which was the improper use, processing and results in the
inventory management and billing system. The SCRUM and its three phases are used as a
methodological framework for engineering. The proposed solution leads to achieving the most
important result of this research, which is the COIN Software.
Within the research process and the development of the project allowed: to understand that
research is an inherent action of people, and that through practice it is possible to improve, taking
into account the above, the knowledge acquired during training is put into practice academic In
addition to working in a business context acquiring experience in software development.
Keywords: Invoice, inventory, SCRUM, microenterprise, software.

1. INTRODUCCIÓN
Las empresas u organizaciones dependen cada día más de la información que manejan, es por
ello que cualquier inconveniente que se presente con esta puede llegar a afectar la operación en
cada uno de los procesos e incluso comprometer vigencia en el mercado.
Tenido en cuenta los avances de las tecnologías de la información y comunicación a nivel
global y la sistematización de los procesos por las grandes empresas, se ha logrado mejorar la
calidad de sus procesos y la atención de los clientes. En Colombia el gobierno nacional en
cabeza del Ministerio de Tecnologías de la Información y las Comunicaciones (MINTIC) ha
generado estrategias para que cada uno de los sectores del país como: Educativo, Industria,
Salud, etc. Incorporen en cada uno de sus procesos las nuevas tecnologías de la información y
comunicación (TIC) con el fin de mejorar y optimizar sus procesos de desarrollo y atención.
Las microempresas o bien conocidas como Mypimes, tienen una gran importancia en la
economía de nuestro país, según un censo realizado por el Departamento Administrativo
Nacional de Estadísticas DANE estas generan alrededor del 67% del empleo y aportan el 28%
del Producto Interno Bruto (PIB). Por eso es importante implementar el uso de las TIC en sus
procesos ya que según (Galeano, 2016), “el desconocimiento de los innumerables beneficios que
pueden generar la incorporación de las TIC en las pequeñas empresas y el miedo a innovar, hace
que estas no sean competitivas en un medio donde se exige la optimización de procesos, la
satisfacción de los clientes en el menor tiempo posible y el aumento de ventas entre muchos
otros aspectos empresariales”.
Por esto la creación de un software para la empresa Plásticos y Desechables Libia, permitirá
un mejor manejo de la información en los procesos de administración de productos, facturación,
pagos y cartera. Ya que en la actualidad estos son realizados de forma manual y son
almacenados en un libro sin ningún control para la preservación de daño o perdida. Esto
conlleva a la desorganización, la falta de precisión en la información y retrasos no intencionales
en la atención a los clientes.
El propósito de esta investigación, es proporcionar a plásticos Libia, una herramienta
tecnológica para la optimización del sistema de información de inventario de productos y
facturación bajo requerimientos específicos, teniendo en cuenta las normas contables y de
inventarios establecidas por el gobierno. Para el proceso de diseño y desarrollo del software, se
aplicó los principios de usabilidad y accesibilidad web.
La usabilidad es considerada según Alarcón, Hurtado, Pardo, Collazos, & Pino en el 2007,
una filosofia donde se debe concentrar en los usuarios. Para desarrollar un software usable es de
gran importancia conocer, trabajar con las personas y usuarios potenciales y poder entender las
tareas de los usuarios para optimizar y mejorar en término de tiempo.
La accesibilidad, según los autores Montero & Martín Fernández en el año 2004, la definen
como: “El atributo de calidad de un producto o servicio web que se refiere a la posibilidad de que
pueda ser accedido y usado por el mayor número posible de personas, indiferentemente de las
limitaciones propias del individuo o de las derivadas del contexto de uso”, y con ello permitir
una fácil y rápida administración, así como la reducción en los costos al hacer más eficientes los
procesos y la disminución en la pérdida de productos. De igual forma ofrece beneficios
intangibles como reducción en el tiempo y calidad de atención.
El desarrollo del software estará concebido, bajo la metodología ágil de desarrollo SCRUM.
La cual dice: “Es un conjunto de prácticas especialmente combinadas para dar soporte a la
creación de productos innovadores y enfocar el trabajo del equipo en producir valor directo para
el cliente final”. (Albaladejo, 2009).

El desarrollo de un software bajo la metodología ágil como es la SCRUM, permite un mayor
control en el ejercicio de producción de la herramienta dentro de un ambiente de trabajo
colaborativo, donde prima la interacción con el cliente, logrando que se priorice el desarrollo de
cada uno de los sprint, para realizar entregas parciales y poder realizar los ajustes en la marcha,
dando como resultado el software que administre los inventarios y facturación de los productos
de la empresa de plásticos Libia.
La siguiente monografía estará compuesta por los siguientes títulos o capítulos: la
introducción, problemática, justificación, objetivos, metodología de desarrollo, marco teórico y
estado del arte, resultados y bibliografía. En donde se expondrán el desarrollo del proyecto,
diseño y producción del software.

1 OBJETIVOS
1.1 OBJETIVO GENERAL
Diseñar, desarrollar e implementar un software de administración de inventarios y facturación
para la empresa Plásticos y Desechables Libia del municipio de Agua de Dios Cundinamarca.
1.2 OBJETIVOS ESPECÍFICOS
a) Identificar los requerimientos funcionales para el desarrollo del software.
b) Determinar la arquitectura y plataforma que mejor se adapte a las necesidades de la
empresa plásticos y desechable Libia.
c) Establecer y diseñar el modelo de datos que permita el almacenamiento de información
sin inconsistencias y redundancia.
d) Establecer la interfaz gráfica del usuario cumpliendo con los principios de usabilidad y
accesibilidad.
e) Establecer el modelo de programación para lograr mayor efectividad y ahorro en el
tiempo de la programación del software.
f) Validar la usabilidad y accesibilidad de COIN con el fin de determinar la eficiencia del
software.
2 PLANTEAMIENTO DEL PROBLEMA
2.1 DESCRIPCIÓN DEL PROBLEMA
La empresa Plásticos y Desechables Libia, ha estado en el mercado desde hace siete años y
hasta el día de hoy, maneja toda su información de forma manual. Esto teniendo en cuenta que
la empresa está en un constante progreso, consiguiendo en una entrada mayor en el sector
productivo del municipio. Lo cual va a generar una mayor dificultad a la hora de manejar la
información manualmente, ocasionando fallas en el control de inventarios.
La empresa a través del tiempo ha adquirido reconocimiento y respeto ante los clientes. Por
ello se hace necesario registrar y controlar la información de inventario, facturas, compras,
ventas y fianzas de una manera más sencilla y precisa, lo cual es una carencia hoy en día.
Otro de los inconvenientes que se presenta en la empresa, es la generación de facturas, ya que
se basan en diferentes formatos de facturación ya preestablecidos. También, se presenta fallas en
el manejo de la información personal de los clientes, como es: el número teléfono, la dirección,
la suma de dinero fiada, los productos adquiridos, etc., la cual por lo general se encuentra en
documentos físicos que son difíciles de acceder y que corren el riesgo de perderse o deteriorarse
con el tiempo.
Por esta razón, se hace necesario desarrollar un software en ambiente web, que permita
almacenar esta información y agilizar los tiempos de consulta. Es importante que la información
de los productos, proveedores, y clientes queden almacenados en una base de datos a la cual se
pueda acceder y ubicar de manera efectiva la información. Para una mayor comprensión sobre la
problemática que se está analizando y proponiendo una solución, se hace uso del árbol de
problemas. Donde, con la utilización de un esquema gráfico mental, se listan las causas y efectos
que ocasionan la problemática. El gráfico se puede apreciar en la ilustración No.1.

2.2 HIPÓTESIS DEL PROBLEMA
Con el desarrollo e implementación del software COIN se espera lograr establecer un mejor
manejo y eficiencia en los procesos de pedidos, facturación y despacho de los productos en la
empresa Plásticos y Desechables Libia de Agua de Dios, Cundinamarca. Así como también un
mejor manejo del dinero para la inversión en cada uno de sus activos.
2.3 DEFINICIÓN DEL PROBLEMA
¿La aplicación COIN, permitirá optimizar, clasificar, ordenar, controlar y brindar mayor
seguridad en los procesos de pedidos, facturación y despacho de los productos ofrecidos por la
empresa Plásticos y Desechables Libia de Agua de Dios, Cundinamarca?
Ilustración 1. Árbol del problema.
Fuente: Los autores

3 JUSTIFICACIÓN
El proyecto está enfocado a implementar estrategias y lineamientos del Ministerio de
Tecnologías de la Información y las Comunicaciones (MINTIC, 2017), los cuales “buscan que
los micro, pequeños y medianos empresarios empiecen a usar la tecnología en todos sus procesos
para ser más productivos, obtener más clientes, ganancias y generar empleo.” De igual menara
cumpliendo con la directiva presidencial N° 04 (Colombia, 2012) la cual consiste en: “La
sustitución de los flujos documentales en papel por soportes y medios electrónicos, sustentados
en la utilización de Tecnologías de la Información y las Telecomunicaciones. Esta estrategia,
además de los impactos en favor del ambiente, tiene por objeto incrementar la eficiencia
administrativa”. Esta directiva se hace extensiva a empresas públicas y privadas, con el fin de
contribuir al mejoramiento del medio ambiente.
Es por eso que sistematizar los procesos de información de cualquier empresa, negocio u
organización, se ha vuelto indispensable ya que esto logra una mayor satisfacción para sus
clientes e incluso para la misma organización. Ya que con la automatización de la información se
alcanza a forjar una empresa mucho más competitiva. Normalmente las empresas pequeñas
manejan toda su información de forma manual y no tienen acceso a herramientas tecnologías.
En muchos casos la utilización de forma tradicional de manejo de la información en las
pequeñas empresas hace que estas no logren los resultados esperados en su gestión
administrativa y financiera. Viéndolo desde un punto de vista tecnológico, se debe atraer a estos
pequeños negocios a la utilización de estas herramientas de software para que el acceso a su
información sea más preciso, seguro y sencillo.
La empresa “Plásticos y Desechables Libia”, está en un constante crecimiento, lo que implica
que se maneje una mayor información en los inventarios, precios, número de existencia de
productos, facturación, clientes, etc. Por ello se crea la necesidad de automatizar y optimizar
todos sus procesos en los cuales la información es vital para el funcionamiento y toma de
decisiones en la empresa, es por eso que se requiere de una herramienta tecnología que permita
regular, ordenar y optimizar el proceso de facturación e inventarios de forma sencilla, confiable y
eficaz para cada una de las personas que laboren y manipulen constantemente la información.
Plásticos y desechables Libia, realiza el promedio mensualmente unas 68 facturas de las cuales
su elaboración tiene una duración de cinco a diez minutos esto varía dependiendo de la cantidad
de productos de la factura. Por otra parte, la verificación y realización de inventarios tiene una
duración de aproximadamente tres días lo cual no ayuda a la toma de decisiones para realizar sus
pedidos en los momentos y tiempos estimados.
Es necesario que esta herramienta en su desarrollo este pensada y sea adaptable para su
implementación en otras empresas, ayudando a cualquiera que necesite administrar el control de
existencias (entradas y salidas) y generación de facturas o reportes en ambos casos.
Esta aplicación servirá de apoyo a las actividades del negocio, se convertirá en una
herramienta útil y fiable a la hora de llevar una contabilidad sistematizada y será un gran
beneficio para los usuarios y clientes en el área de compra y venta de productos que allí se
ofrecen.
Las tareas que se proponen automatizar a través de este software para lograr una mejor
administración de la información e inventario de artículos son las siguientes:
a) Agilizar el proceso de ventas que realizan los empleados.
b) Permitir a los empleados realizar consultas eficientes en cuanto a los precios de los
productos.
c) Registrar a todo el personal que labore o laborará en la empresa para un mayor control de
los movimientos internos que lleven a cabo.
d) Registrar a los clientes con sus datos personales y un identificador que permitirá
consultas rápidas.
e) Conservar y mantener la confidencialidad de toda la información mediante la
autenticación de cualquier usuario que ingrese al sistema.
f) Registrar cualquier artículo nuevo que ingrese a la empresa, así mismo dar de baja
aquellos que no se deseen poner más a la venta o estén ya descontinuados.
g) Hacer el inventario a mano se eliminará, el software será capaz de realizar el inventario
automáticamente y de actualizarse al registrarse una nueva venta o un nuevo pedido. Este
control de artículos permitirá que el administrador realice compras a los proveedores
tomando en cuenta dos aspectos principales, el stock mínimo de cada artículo para poder
ser resurtido y la demanda de los mismos.
h) Contar con un catálogo de proveedores que contenga al día toda la información necesaria
para solicitar un nuevo pedido de artículos.
i) Permitir la actualización de datos de empleados, proveedores, clientes y artículos
registrados.
4 MARCO REFERENCIAL DE LA INVESTIGACIÓN
Este proyecto requiere del conocimiento tanto de temas que permitan el desarrollo del
software en su aspecto técnico, así como el entendimiento de normativas o leyes de contabilidad,
financieros y de la microempresa “Plásticos y Desechables Libia”. Por esta razón se hace
necesario conocer y entender conceptos como el impuesto IVA, entidades que rigen el comercio
en Colombia, facturación, inventarios, identificación de la problemática, análisis de
requerimientos, estudio de factibilidad, ciclo de vida del desarrollo de software, metodología del
desarrollo de software, entre otros. De esta manera se plantean a continuación los temas
anteriormente nombrados.
Toda empresa que esté legalmente establecida en Colombia y el mundo, requiere cumplir con
unos requerimientos que plantea las entidades encargadas de regir dichas organizaciones, ya sean
grandes, medias o pequeñas, logrando de esta manera ser legalizada en el país. La facturación es
uno de los temas centrales en el funcionamiento de la empresa y requiere del cumplimiento
correcto de algunas normativas, así como de una organización adecuada para poder realizar los
inventarios reales de las ventas realizadas a diario por la empresa. Por esta razón, uno de los
requerimientos más importantes en la parte legal de cualquier empresa en Colombia es el
Impuesto IVA.
Impuesto IVA: El impuesto al valor agregado IVA, en términos generales es el valor que
debe ser aumentado por el uso de bienes y servicios ofrecidos por una empresa u organización, la
cual no se encuentra excluida para este tipo de impuesto. Esto es aplicado en la etapa de
producción, importación y distribución del producto o servicio.

“En Colombia son responsables del IVA tanto las personas naturales como jurídicas que
produzcan o vendan bienes o servicios excluidos, además los comerciantes y quienes realicen
actos similares a los de ellos, incluyendo a los importadores”. (Art 437, 2018).
 Personas jurídicas, se es denominado así a aquellas empresas que aplican sus derechos y
deberes de manera propia, ya que asume todas y cada una de las responsabilidades que se
debe cumplir según las normas que rigen este tipo de organización. Es por ello que el
gerente no es responsable por las acciones o sucesos que ocurran en función de la
empresa.
 Personas naturales, es nombrada así a aquella persona que se responsabiliza de manera
propia de todos y cada uno de los derechos y deberes que implica el cargo dentro de la
empresa. En esta persona recae toda responsabilidad ejercida tanto por ella como por sus
empleados y las funciones que realice la empresa que tiene a cargo.
La clasificación de los bienes y servicios ofrecidos en Colombia se establecen asi:
 Gravados: Son todos aquellos bienes y servicios a los cuales se les aplica una tarifa
general del 16% o tarifas diferenciales.
 Exentos: Son todos aquellos bienes y servicios que desde su naturaleza se encuentran
gravados, pero con una tarifa del 0%.
 Excluidos: Son todos aquellos bienes que según la ley no general ningún tipo de
impuesto.
4.1 ENTIDADES QUE REGULAN EL COMERCIO EN COLOMBIA
El comercio que se genera en las diferentes regiones de Colombia es de gran proporción, es
por ello que la forma de comercialización es muy variada y en algunos casos no es la adecuada o
por lo menos no la determinada por la ley colombiana.

Las ventas de los comerciantes en febrero tuvieron un mejor comportamiento que en los
meses precedentes, pero aún no se sabe a ciencia cierta que la mejoría presentada en el segundo
mes del año signifique que en adelante las ventas van a crecer en forma sustancial, según lo dio a
conocer la Federación Nacional de Comerciantes (Fenalco, 2018).
Es por ello que existen algunas entidades que regulan este tipo de comercialización en el país,
las cuales son:
4.1.1.1 Dirección de Impuestos y Aduanas Nacionales – DIAN.
Dirección de Impuestos y Aduanas Nacionales. Es una de las entidades más importantes en
Colombia, la cual busca garantizar y establecer la seguridad fiscal y del orden público en cuanto
a la economía del país. Además de esto cumple funciones como:
a) Brindar respuesta a las diferentes preguntas, dudas o reclamos hechos por las personas
que manejan la mercancía.
b) Supervisar la importación y exportación adecuada de los productos.
c) Implantar sanciones a las diferentes infracciones aduaneras.
d) Asegurar el cumplimiento del régimen cambiario del comercio exterior.
Entre otras funciones que logran hacer del transporte de mercancía y la economía pública del
país procesos mucho más seguros, logrando un mejor funcionamiento y un adecuado
seguimiento de estos procesos en pro al mejoramiento del país.
4.1.1.2 Banco de la república de Colombia.
El Banco de la República es un órgano del Estado de naturaleza única, con autonomía
administrativa, patrimonial y técnica, que ejerce las funciones de banca central. Según la
Constitución, el principal objetivo de la política monetaria es preservar la capacidad adquisitiva
de la moneda, en coordinación con la política económica general, entendida como aquella que
propende por estabilizar el producto y el empleo en sus niveles sostenibles de largo plazo. En
ejercicio de esta función adopta las medidas de política que considere necesarias para regular la
liquidez de la economía y facilitar el normal funcionamiento del sistema de pagos, velando por la
estabilidad del valor de la moneda (Banco de la Republica de Colombia, 2013). Otras de las
funciones que cumple esta entidad son:
a) Realizar préstamos transitorios a las demás entidades bancarias que así lo soliciten y que
sean extrema necesidad.
b) Emitir las monedas y billetes que serán empleados para el desarrollo de la economía del
país.
c) Administrar los dineros que se encuentran invertidos en reservar como la moneda
extranjera, el oro, los derechos especiales de giro, etc.
d) Promover el desarrollo social, científico y cultural del país por medio de organizaciones o
entidades que realicen funciones para el cumplimiento de actividades que enriquezcan
estos aspectos.
En base a estas y otras funciones se logra implantar un crecimiento del país en diferentes
aspectos que permiten mejorar su proceso y obtener mejores resultados para el continuo avance
en el desarrollo.
4.1.1.3 BANCÓLDEX. Banco De Desarrollo Colombiano.
Banco De Desarrollo Colombiano. Es el encargado del desarrollo de material tanto financiero
como no financiero, que sirvan de apoyo para el crecimiento de las diferentes empresas
establecidas en Colombia. Además de ello cumple otras funciones como:
a) Exaltar los diferentes contratos y acciones autorizadas a las entidades bancarias, como por
ejemplo las capacitaciones, las operaciones de crédito y las financiaciones de clientes
exportadores.
b) Realizar de descuentos a los créditos otorgados a otras entidades financieras.
c) Apoyar el sistema que ayuda al aseguramiento de la exportación del crédito.
d) Otorgar garantías y avales a las diferentes entidades financieras.
4.1.1.4 FIDUCOLDEX.
Fiduciaria Colombiana de Comercio Exterior. Esta es una sociedad que busca ser un apoyo
para los servicios financieros de la economía en el comercio exterior. Ayudando a la
administración de activos que suplan las necesidades de los clientes de manera eficiente. Las
funciones de (Fiducoldex, 2018) son:
a) Celebración de contratos de fiducia mercantil, en todos sus aspectos y modalidades, de
acuerdo con las disposiciones que contienen decreto 663 de 1993 mencionado, el Título
XI del libro cuarto del Código de Comercio, el Estatuto Orgánico del Sistema Financiero
y las demás normas complementarias o concordantes, o las que las adicionen o sustituyan.
b) Realización de todas las operaciones, negocios, actos, encargos y servicios propios de la
actividad fiduciaria, que aparecen en el decreto 663 de 1993 y en las demás normas
complementarias o concordantes, o en las que las adicionen o sustituyan.
4.1.1.5 Ministerio de comercio, industria y turismo de Colombia.
Es la entidad principal encargada de administrar las diferentes funciones que están a cargo del
estado, además apoya las actividades relacionadas con la producción de bienes, servicios y
tecnologías. El banco del ministerio cumple con funciones como:
a) Promover la cultura exploradora y la inversión extranjera por medio de planes estratégicos
que apoyen el desarrollo comercial del país.

b) Crear mecanismos que permitan garantizar el control en cuanto a la participación del
sector privado en el comercio.
c) Representar el país en las negociaciones de comercio internacional y exteriores.
4.1.1.6 INVIMA (instituto nacional de vigilancia de medicamentos y alimentos).
Instituto Nacional de Vigilancia de Medicamentos y Alimentos. Es una entidad que protege y
controla la salud individual y colectiva de los colombianos. Regida por las normas sanitarias que
se encuentran asociadas con uso y consumo de alimentos. El (INVIMA, 2018) cumple funciones
como:
a) Fortalecer los mecanismos de articulación y coordinación entre los sujetos responsables de
la inspección, vigilancia y control sanitario con enfoque de riesgo que contribuyan a la
protección y prevención de la salud y al cumplimiento de las políticas de competitividad y
desarrollo.
b) Fomentar y promover la excelencia en la prestación de los servicios, para afianzar la
confianza de la población y el reconocimiento nacional e internacional.
c) Implementar modernas tecnologías de información y de comunicación de acuerdo con las
necesidades de los usuarios, directrices del Gobierno y estándares internacionales.
d) Fortalecer la gestión del conocimiento, capacidades, competencias y mejora de la calidad
de vida laboral de los servidores públicos de la institución.
e) Aumentar la eficiencia en la gestión operacional de los laboratorios del INVIMA, y de la
red nacional; y los sitios de control de primera barrera.
f) Aplicar las acciones de IVC para diseñar e implementar procesos de gestión orientados a
mitigar los efectos de la ilegalidad.

4.2 FACTURACIÓN
Este es uno de los procesos más importantes en cualquier empresa u organización, con el cual
tanto la empresa como el cliente tienen derechos y deberes que logran ser cumplidos o ejercidos
por medio de este documento. Además, es uno de los requisitos principales por la ley para ser
ejercido por cualquier organización legalmente constituida en Colombia. Como se definió
anteriormente la factura es un documento el cual contiene toda la información principal de la
compraventa de un producto en un determinado establecimiento comercial.
Hoy en día existen diferentes tipos de facturas establecidas por las empresas, cada una de ellas
emplean modelos o diseños según los gustos de cada una de ellas. Sin embargo, deben regirse a
una serie de requisitos establecidos por el régimen tributario y las entidades que regulan el
comercio en Colombia.
Una factura de venta según (Gerencie, 2012) en el artículo 617 del estatus tributario debe
contener los siguientes requisitos:
a) Estar denominada expresamente como factura de venta.
b) Apellidos y nombre o razón y NIT del vendedor o de quien presta el servicio.
c) Apellidos y nombre o razón social y NIT del adquirente de los bienes o servicios, junto
con la discriminación del IVA pagado.
d) Llevar un número que corresponda a un sistema de numeración consecutiva de facturas
de venta.
e) Fecha de su expedición.
f) Descripción específica o genérica de los artículos vendidos o servicios prestados.
g) Valor total de la operación.
h) El nombre o razón social y el NIT del impresor de la factura.

i) Indicar la calidad de retenedor del impuesto sobre las ventas.
La factura de venta, la cual es realizada por la venta de un producto o servicio dependiendo la
empresa que lo ofrece. En esta factura se registran una serie de requisitos que fueron establecidos
por el vendedor y el comprador. Además de este tipo de factura, existe la factura de compra la
cual debe cumplir con los mismos requisitos, pero es implantada por el comprador. Se conoce
también la factura rectificada la cual se realiza por la necesidad de corregir algún error o falla
realizada en la factura original. Por último, se tiene la factura recapitulativa en la cual se
realizada el agrupamiento de las facturas anteriormente realizadas para lograr hacer un envió
general.
4.3 INVENTARIOS
Los inventarios es uno de los activos más importantes en cualquier empresa, ya que con ellos
se logra llevar un control de las diferentes acciones realizadas y evaluar el progreso que está
teniendo dicha organización, permitiendo de esta manera que se corrijan muchas de las fallas que
se pueden presentar en las ventas, compras y demás acciones realizadas por los empleados de la
misma.
Según (SIIGO, 2018) define inventario como: relación ordenada, detallada y valorada del
conjunto de bienes o pertenencias que constituyen el patrimonio de una persona, comunidad o
empresa en un momento específico.
La contabilidad que debe llevar toda empresa u organización es respaldada y basada en los
diferentes tipos de inventarios que se logran realizar según los productos y/o servicios que son
ofrecidos por la misma. Gracias a estos se logra realizar un balance económico de la
organización comparando los gastos y las ventas ejercidas y empleando planes de mejora para el
progreso continuo de la empresa.

Las pequeñas empresas como “Plásticos y desechable Libia” realizan sus inventarios de
compra y venta de productos ya terminados, ya que es uno de los procesos más importantes
dentro de la empresa y con el cual les permiten llevar la contabilidad. Por esta razón los
inventarios se han convertido desde hace año en parte esencial para el avance de cualquier
empresa, implantándose además varios tipos, como lo son:
a) Inventario inicial: Este es uno de los inventarios más relevantes en toda empresa, ya que
en este se registran los bienes que posee la empresa en el momento de iniciar el periodo
producción. Está muy ligado con el inventario final, ya que al realizar la comparación
entre estos se puede lograr determinar las ganancias o pérdidas obtenidas por la empresa.
b) Inventario periódico: Este es uno de los inventarios más empleados para la toma de
decisiones en una organización, ya que por lo general se realiza mensualmente y le
permite evaluar los gastos y las ventas realizadas por la empresa en ese lapso de tiempo.
c) Inventario perpetuo: Es el inventario que se realiza de manera constante, se puede decir
que a diario dependiendo la empresa y con el cual se evalúa de manera detallada cada una
de las acciones realizadas con los activos de la organización. Este inventario es muy
empleado para la realización de balances de cualquier tipo, ya que permite un
seguimiento detallado de los ingresos y salidas.
d) Inventario físico: Por decirlo en otras palabras es un inventario real, en donde se cuenta
cada uno de los productos que hacen parte de la empresa, con el fin de conocer el estado
en el que se encuentra cada uno de ellos. Este inventario es realizado en lo general por los
auditores o personal correspondiente.
e) Inventario final: Consta en tomar los inventarios físicos, hasta la última acción
económica realizada por la empresa. Este inventario es ejerce por lo general el último día
del año fiscal para conocer los activos con los que cuenta la empresa al iniciar un nuevo
año fiscal.
f) Inventario de transito: Este es uno de los inventarios que tiene mayor relevancia dentro de
una organización, ya que se realiza con el fin de determinar la mercancía que no ha sido
recibida por la empresa y también la que ha sido perdida por la misma.
g) Inventario máximo: Este inventario es empleado para pronosticar la cantidad de
mercancía requerida para la venta en el siguiente periodo, así como el Stock requerido
que permitirá suplir esta demanda.
h) Inventario mínimo: Es la mínima cantidad de mercancía que debe tener la empresa u
organización para ofrecerle al cliente una conformidad en la compra de sus productos.
i) Inventario en línea: Es el inventario realizado para determinar toda la mercancía que se
encuentra en el proceso de producción por parte de la empresa.
j) Inventario de seguridad o reserva: Son los inventarios que se realizan pensando en la
prevención de la falta de productos dentro de la empresa, logrando de esta manera
proporcionar una conformidad para el cliente.
k) Inventario de ciclo: Este inventario es empleado cuando la empresa u organización
distribuye su mercancía por medio de lotes en los cuales emplea alguno de los dos
métodos tradicionales FIFO o LIFO dependiendo el tipo de empresa.
Gracias a cada uno de estos tipos de inventarios se logra llevar un control adecuado de los
procesos realizados por los activos ya sean productos o servicios que ofrezca la empresa. Cada
uno de estos inventarios cumple funciones específicas y son de gran importancia para las grandes
organizaciones, así como para las PYMES.

Además de los inventarios realizados por las empresas se hace uso también de una serie de
cuentas, las cuales son definidas por (Blueindic blog, 2017) como un conjunto de informes
contables, obligatorios a realizar en Sociedades Mercantiles (Sociedades Limitadas, por ejemplo)
según lo establecido en el Código de Comercio. No obstante, si bien es cierto parte de una
premisa obligatoria de cumplimiento, la realización de las Cuentas Anuales puede ayudar a
Empresarios y Empresas a conocer y analizar sus negocios, con el objetivo de ser capaces de
tomar decisiones acertadas. Algunas de estas son:
a) Compras: A este tipo de cuenta hace parte la adquisición de productos y/o servicios que
serán ofrecidos por la empresa y con los cuales se busca una ganancia económica en el
momento de su venta.
b) Gastos de compras: Esta cuenta se refiere a los gastos realizados en el momento de
adquirir los productos o servicios que más adelante serán vendidos por la empresa. por
ejemplo, gastos de transporte, comidas, etc.
c) Devolución en compras: Esta cuenta hace referencia a la devolución de los productos que
han sido adquiridos o comprados por la empresa y que por alguna razón fueron devueltos
a la organización que se los proporciono.
d) Mercancía en tránsito: Esta cuenta es solo empleada por aquellas empresas que realizan
compras en el exterior, las cuales se hace necesario evidenciar por la suma de dineros que
ha sido empleada para su adquisición.
e) Mercancía en consignación: Esta cuenta se usa cuando la empresa adquiere sus productos
por medio de consignaciones a sus proveedores, en donde se puede establecer que dicho
producto ya ha sido comprado, pero aún está en manos de los proveedores.

f) Ventas: Esta cuenta es la encargada de controlar las ventas de los diferentes productos o
servicios que son ofrecidos por la empresa.
Devolución en ventas: El propósito de esta cuenta es evidenciar todos los productos que han
sido devueltos por los clientes de la empresa por las diferentes razones que puedan llegar a
presentarse.
De esta manera se puede establecer que cada una de las cuentas e inventarios realizados por
las organizaciones, se hacen necesarios para lograr un correcto manejo de los diferentes tipos de
activos que son requeridos para el debido funcionamiento de la empresa.

5 LA INVESTIGACIÓN EN EL CAMPO DEL DESARROLLO DEL SOFTWARE
Para realizar la debida investigación referente al desarrollo del software se hace necesario
establecer la problemática central a la cual se le dará una solución. Para ello se requiere la
elaboración de un proyecto en el cual se establezca cada uno de los requerimientos necesarios
para su elaboración, por esto se requiere de factores esenciales como el conocimiento previo de
las temáticas requeridas para el desarrollo, así como la experiencia y el tiempo empleado.
Luego de establecer dicha problemática se realiza el debido análisis para poder comprender
un poco mejor lo que se quiere solucionar. Una de las definiciones que hace referencia al
problema es, una situación de inconveniencia, insatisfacción, que no puede ser resuelto en forma
autónoma, por los propios afectados (vulnerabilidad). Se puede manifestar por la carencia de
algo bueno, por la existencia de algo malo. También se puede identificar un problema ante una
oportunidad de desarrollo no aprovechada (Cepal, 2016)
Para lograr identificar una problemática se hace necesario encontrar la causa raíz que permite
la existencia del mismo, para ello existen algunos elementos que deben ser tenidos en cuenta:
a) Causas: Estos son los diferentes factores que generan u originan la problemática. Estos
factores pueden ser directos, los cuales se involucrar complemente con la problemática y
los factores indirectos son aquellos que por lo general dan paso a proporcionar los
factores directos de la problemática.
b) Consecuencias: Son los resultados que se obtienen a futuro por aquellas acciones
realizadas en el presente. Estas consecuencias proporcionan un impacto en la empresa
dependiendo de la importancia y los activos que se anejen por cada uno de ellos.
c) Soluciones: Son las diferentes acciones o procesos que se realizan para logran mitigar o
eliminar las causas que pueden llegar a proporcionar una problemática en la
organización.
5.1 MÉTODOS Y/O TÉCNICA PARA IDENTIFICAR LA PROBLEMÁTICA EN LA
INVESTIGACIÓN.
Para la identificación de la problemática central que debe tener el desarrollo de todo proyecto
se hace necesario emplear una serie de técnicas que permiten facilitar este proceso. A
continuación, se nombran las técnicas más relevantes para el desarrollo de proyectos:
Lluvia de ideas: Esta técnica es una de las más empleadas para llagar a la problemática
central la cual quiere ser resulta para el progreso continuo del proceso, en este caso de la
empresa. Esta técnica es también llamada “tormenta de ideas” y se basa en la generación de gran
cantidad de ideas pensadas por el grupo de trabajo para solucionar dicha problemática.
Según (Samsing, 2017) establece 12 técnicas para realizar la lluvia de ideas y obtener
resultados creativos, estas son: promover la diversidad en el grupo, mantener reuniones de 22
minutos (Aproximadamente), establecer el contexto y los objetivos con tiempo, pedir al equipo
que piense en algunas ideas de antemano, decir “NO” a las malas ideas y hacer rápido, promover
un entorno donde tener malas ideas es aceptable, usar los obstáculos en beneficio, hacerse amigo
del silencio, aprender de los fracasos fuera de la sesión de brainstorming, aceptar que quizás es
mejor no tener una reunión, ofrecer un espacio para las propuestas anónimas y prepararse para no
llevar a cabo ninguna idea tras una reunión.
Técnica de grupo nominal: Esta técnica logra facilitar las decisiones tomadas por el equipo
de trabajo, ya que por medio de aspectos relacionados con el boto se logra respetar de manera
determinada las decisiones de cada uno de los integrantes. A esta técnica la conforma 7 etapas:
a) Definición del problema o de las decisiones que se van a tomar.
b) Generación de ideas realizadas silenciosamente por parte del grupo de trabajo.
c) Establecer y registrar cada una de las ideas que se le ocurran para dar solución a la
problemática.
d) Aclare las diferentes ideas que ha propuesto para lograr un mejor entendimiento por parte
del equipo de trabajo.
e) Califique cada una de las ideas proporcionadas por el equipo de trabajo de manera
silenciosa.
f) Digitalice los resultados obtenidos en las calificaciones.
g) Culmine la sesión.
Diagrama de espina de pescado: Esta técnica se emplea para determinar las diferentes
causas que generan la problemática, así como clasificarlas y por último establecer una solución a
cada una de ellas. Además de esto, permite visualizar el efecto que traerá dicho problema, para
esto se deben cumplir los siguientes pasos:
a) Establecer en modo de pregunta cada una de las posibles problemáticas que se
encontraron por el equipo de trabajo.
b) Diagramar el esqueleto de pescado que se utilizara y ubicar en el cuadro de la derecha el
problema encontrado.
c) Establecer las diferentes causas encontradas que generan la problemática.
d) Las causas principales de la problemática deben diagramarse en oblicuas a la flecha
central.
e) Clasificar las causas en el segundo o tercer nivel dependiendo de lo analizado.

ZOPP: Este es un instrumento que permite desarrollar las diferentes etapas que tiene un
proyecto, por medio de herramientas e instrumentos para la correcta planificación del mismo.
Sus objetos principales según (Sinnaps, 2018) son:
a) Realizar una planificación conjunta entre todos, en base a una información realista y
detallada.
b) Promover un nivel de compromiso óptimo entre los interesados del proyecto, así como un
alto grado de motivación al establecer un feedback adecuado con todos.
c) Exponer una información clara y directa de ¿por qué trabajamos en el proyecto? ¿Qué
queremos conseguir al cerrarlo? ¿Qué esperamos?
d) De esta manera, alineamos estrategias tanto dentro del equipo del proyecto como de la
empresa.
e) Fomentar el trabajo bajo un consenso lógico y ordenado.
f) promover un clima de creatividad, cooperación y unión en los miembros del equipo.
g) Establecer una rutina de monitoreo y evaluación continua con indicadores objetivos que
nos miden a tiempo real el funcionamiento del proyecto.
Este método emplea además una serie de etapas las cuales son:
a) Análisis de la participación: Este análisis es realizado a los diferentes factores que se
involucran en el desarrollo del proyecto tales como la estructura, los integrantes, los
materiales, etc.
b) Análisis del problema: En esta etapa se evalúa las diferentes causas que generan la
problemática.
c) Análisis del objetivo: En esta etapa se realiza un árbol de objetivos en el cual se establece
las posibles soluciones a la problemática.
d) Análisis de alternativas: Es la etapa en la cual se identifican las estrategias más relevantes
que logren brindar una solución al problema establecido.
e) Descripción del proyecto: En esta etapa se realiza una Matiz en la cual se planifica el
proyecto por medio de las diferentes estrategias encontradas anteriormente.
f) Supuestos: Determinar las posibles causas de la problemática y determinar las soluciones
para cada una de ellas.
g) Indicadores y métodos de verificación: Es la etapa donde se determina herramientas de
cantidad y calidad para el control del proyecto.
Análisis de Pareto: Este es uno de los métodos gráficos que se emplean para identificar las
causas que generan la problemática, logrando realizar una ponderación para priorizarlas. Según
(minitab 18, 2017) define este método como: un tipo especial de gráfica de barras donde los
valores graficados están organizados de mayor a menor. Utilice un diagrama de Pareto para
identificar los defectos que se producen con mayor frecuencia, las causas más comunes de los
defectos o las causas más frecuentes de quejas de los clientes. Este método tiene como
características las siguientes:
a) Priorización: Es donde se determinan los elementos que según la prioridad que tienen
deben ser manejados.
b) Unificación de criterios: Se crea un objetivo prioritario por parte de cada uno de los
integrantes del grupo de trabajo.
c) Carácter objetivo: La toma de decisiones por parte del equipo de trabajo en base a la
problemática.
5.2 ANÁLISIS DE REQUERIMIENTOS EN LA INGENIERÍA DEL SOFTWARE
Para el desarrollo de todo proyecto se hace necesario una serie de requerimientos o requisitos
que se deben de cumplir para poder dar solución a la problemática ya establecida. Para un mejor
entendimiento se define la palabra requerimiento en el campo del desarrollo del software, según (
Camacho & Torres) como: requerimiento es una especificación de que debería ser
implementado. Son descripciones de cómo el sistema debería comportarse, o de las propiedades
o atributos de un sistema. También pueden ser una limitación en el proceso de desarrollo del
sistema.
Comprendiendo mejor la palabra requerimiento, se puede entender que el análisis de
requerimientos es la evaluación realizada a cada una de aquellas cualidades que necesita cumplir
el software para su correcto funcionamiento y cumpliendo con su objetivo. Estos requerimientos
se dividen en:
a) Requerimientos funcionales: Estos requerimientos hacen referencia a cada una de las
acciones que debe y no debe hacer el sistema para cumplir con las funciones que se
requieren para el alcance de los objetivos. Estos requerimientos se basan en el tipo de
software que se quiere desarrollar, así como también el público al cual va dirigido y el
enfoque que este tenga. Además, describen cada una de las entradas, salidas y
excepciones que este cumple.
b) Requerimientos no funcionales: Son todas aquellas limitaciones o restricciones de los
diferentes servicios que ofrece el sistema. Estos requerimientos por lo general no se
aplican a las funciones que cumple el software sino a propiedades intangibles como lo
son el tiempo de respuesta, el conocimiento de equipo de trabajo, la fiabilidad, la

capacidad de almacenamiento, etc. En base a estas propiedades se logra determinar la
eficiencia de cada uno de los procesos que cumple el sistema.
5.3 ESTUDIO DE FACTIBILIDAD EN EL DESARROLLO DEL SOFTWARE
Para el desarrollo de todo proyecto se hace necesario un estudio de factibilidad que permita
evaluar los diferentes factores que hacen parte del desarrollo. Gracias a ello se aprueba la etapa
de planeación del proyecto y se realizan las mejoras necesarias a cada uno de los factores que
tienen relación con el proyecto. Este estudio de factibilidad cumple con objetivos como:
 Minimizar las fallas o errores en la planeación y el desarrollo del proyecto.
 Optimizar los recursos necesarios y reducir los costos por medio de los recursos que no
se necesitan en el desarrollo y planeación.
 Concluir si es factible el desarrollo del proyecto.
 Asegurar la disponibilidad de los recursos necesarios del proyecto.
El desarrollo de proyecto logra ser factible si cumple con cada uno de los aspectos nombrados
a continuación:
a) Factibilidad operativa: Está determinada por el grado de usabilidad que debe cumplir el
sistema en cada una de sus funciones. Según (Atic, 2017) la factibilidad operativa tiene como
objetivo, comprobar que la empresa u organización será capaz de darle uso al sistema, que
cuenta con el personal capacitado para hacerlo o tiene los recursos humanos necesarios para
mantener el sistema. para esto. Esta consta de tres aspectos:
 La complejidad de uso del nuevo sistema de información por parte de los usuarios que
lo van a emplear.
 El miedo de los usuarios al utilizar el sistema por los cambios negativos que pueda
ocasionar y por la falta de adaptación.

 La posibilidad de que el sistema sea obsoleto por cambios en las normas o demás
causas.
b) Factibilidad técnica: En esta se logra evaluar los diferentes recursos tecnológicos como el
software y hardware que se requieren para el desarrollo, la funcionalidad, el rendimiento y la
calidad del proyecto. Además, se evalúa el personal que tiene la empresa para determinar si
cumple con los conocimientos necesarios para el funcionamiento del software.
Según (Atic, 2017) los conceptos que hay que considerar en la planeación de la
Factibilidad de sistemas técnica es:
 El sistema funciona como corresponde (números de pruebas)
 El sistema está desarrollado para mantenerse cerca de los consumidores.
 Escalas de producción (Ampliación o reducción de producción).
 Complementos que ayuden el desarrollo del proyecto: ¿Existe
la tecnología necesaria?, ¿De dónde se obtendrá la tecnología?, ¿Se puede capacitar al
personal con la nueva tecnología? ¿Hay proveedores alternativos para el sistema?
c) Factibilidad legal: Esta hace referencia a las diferentes normas legales vigentes que debe
cumplir y respetar el desarrollo del software durante su ejecución.
d) Factibilidad económica: Logra que el equipo desarrollado del proyecto identifique y
justifique cada uno de los recursos económicos que se requieren emplean antes, durante y
después de su desarrollo. Con esto se logra determinar los gastos que se tendrán de manera
general en el proyecto y la ganancia que generara este. Estos gastos son aplicados a recursos
tecnológicos, humanos, de transporte, etc.
e) Factibilidad de tiempo: Esta factibilidad es enfocada a establecer si se cuenta con el tiempo
necesario o requerido para el debido desarrollo del proyecto, desde la planeación hasta su
implementación. Por ello se hace necesario del desarrollo del cronograma de actividades, en
donde se especifican de manera detallada e tiempo requerido para cada una de ellas.
5.4 CICLO DE VIDA DEL SOFTWARE
Para el desarrollo del software se hace necesario establecer las diferentes etapas o fases que
este debe tener, desde la inicial hasta la fase final. De esta manera se permite llevar un orden
cronológico dependiendo el cronograma establecido y los requerimientos.
El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial
hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se
requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software
cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se
asegura de que los métodos utilizados son apropiados (CCM, 2017).
En el ciclo de vida del software se busca prevenir la mayor cantidad de erros que se pueden
llegar a presentar dependiendo de los diferentes aspectos relacionados con este. Además, se logra
hacer un énfasis en la calidad que el software debe tener, permitiendo cumplir cada uno de los
parámetros planteados por normas nacionales e internacionales que se enfocan en aspectos como
este.
El proceso que debe cumplirse en el ciclo de vida del software es:
a) Definición de objetivos: La definición de los objetivos permite definir el resultado final del
proyecto.
b) Análisis de los requerimientos y su factibilidad: La identificación, análisis y definición de
cada uno de los requerimientos determinados por el cliente debe ser evaluado para
determinar su factibilidad para el desarrollo.

c) Diseño general: La arquitectura que debe tener el software será en base a sus requisitos
generales.
d) Diseño en detalle: Detallar cada uno de los módulos que contiene el software para un mejor
entendimiento.
e) Programación e implementación: El lenguaje de la programación que va a llevar el software
debe adaptarse a los requerimientos que demanda el cliente o usuario que la implementara.
f) Prueba de unidad: Estas pruebas son realizadas a cada uno de los módulos que contiene la
aplicación de manera individual.
g) Pruebas de integración: Es la integración de cada uno de los módulos que contiene la
aplicación para efectuar su correcto funcionamiento.
h) Prueba beta: Esta prueba se realiza con el fin de verificar que se cumpla con cada uno de los
requerimientos establecidos por el usuario.
i) Documentación: Es la base fundamental del desarrollo del software en donde se plasma toda
la información referente al mismo.
j) Implementación: Inicial con el funcionamiento de la aplicación y el manejo por parte del
usuario final.
k) Mantenimiento: Se realiza para lograr garantizar el correcto funcionamiento de la aplicación
al usuario.
Además de cumplir con cada una de las anteriores fases que se requieren en el ciclo de vida
del software, existe una serie de modelos que permiten desarrollar de manera eficiente, estos son:
Modelo cascada: Este es uno de los modelos más empleados en el ciclo de vida del software,
ya que permite un desarrollo secuencial de cada una de sus fases y actividades requeridas, las
cuales deben ser realizadas una tras otra, lo que implica que hasta no culminar la actividad uno,
no se puede iniciar con el desarrollo de la actividad 2.
Ilustración 2. Modelo de Cascada.
Fuente: Tutorialspoint.
Este modelo maneja principios básicos como:
 La planeación adecuada desde su inicio hasta el fin.
 Establecer el comportamiento que tendrá el sistema.
 La documentación de los resultados obtenidos.
 El correcto diseño del sistema antes de programarlo.
 Testear el sistema antes de iniciar la construcción.
Modelo evolutivo: Este modelo al igual que el anterior es uno de los más empleados en la
actualidad y se basa en desarrollar una versión inicial del software, la cual se va mejorando poco
a poco según los requerimientos del cliente. Para ello se realizan entregas parciales de los
diferentes módulos que debe tener el aplicativo los cuales son revisados cuidadosamente para
seguir con el avance del aplicativo. Este modelo maneja cuatro etapas las cuales son:
 Planeación: Es la etapa en la cual se realiza una evaluación a cada uno de los factores que
intervendrán en el desarrollo del aplicativo. De esta manera se logra determinar si este
desarrollo es factible y cumple con los requerimientos necesarios.
 Análisis del riesgo: Esta es la etapa en la cual se logra identificar los diferentes riesgos
que pueden llegar a presentarse en el desarrollo del software y en donde se debe
determinar los posibles ideales que permitan dar solución a cada una de ellas.
 Construcción y adaptación a la ingeniería: Esta etapa es clave ya que es en donde se
construye, valida e instala el software desarrollado y luego se ofrece el soporte al usuario
final.
 Evaluación del cliente: El cliente que es el usuario final tiene como tarea evaluar el
funcionamiento del software para determinar el cumplimiento de cada uno de los
requisitos establecidos por él.
Modelo espiral: Este modelo es muy similar al de cascada, ya que se realiza en versiones
que van incrementando a medida que se avanza el desarrollo del software, hasta lograr
culminarlo. Las fases que se manejan en este son: Determinar objetivos, análisis de riesgos,
planificación y desarrollo-prueba. Las actividades también son realizadas de manera secuencial
por lo que hasta no culminar la primera no se puede realizar la segunda.

Ilustración 3. Modelo Espiral.
Fuente: Tutorialspoint.
Este modelo maneja principios básicos como son:
 La planeación adecuada antes de iniciar con el desarrollo.
 Examinar y seleccionar la mejor de las alternativas.
 La evaluación de lo aprendido y lo realizado.
 Pensar en que puede haber cambios según lo querido por el cliente.
 Comprender los riesgos que se deben tolerar.
5.5 METODOLOGÍAS DE DESARROLLO DEL SOFTWARE
Las metodologías de desarrollo ayudan a la planeación y control del proyecto. Hoy en día
existen dos tipos de metodologías para el desarrollo del software, las metodologías tradicionales,
también llamadas pesadas y las metodologías agiles que son la más aptas para el desarrollo de
software por el corto periodo de plazo. Para este proyecto se seleccionó la metodología SCRUM.
Esta es una de las metodologías agiles en el desarrollo del software y se enfoca
principalmente en el marco de trabajo para el desarrollo de los procesos, logrando coordinar las
diferentes actividades del grupo de trabajo y de esta manera desarrollar elementos funcionales en
cada una de las etapas que este maneja.
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de
trabajar de equipos altamente productivos (Proyectosagiles, 2018).
Esta metodología ha sido empleada para el desarrollo de este proyecto por una razón
fundamental la cual es el enfoque central en el equipo de trabajo y la flexibilidad de implantación
del cliente en el proceso del desarrollo del software. Logrando de esta manera, una constante
retroalimentación por parte del usuario final y mayor satisfacción del mismo. Así como un
proceso de desarrollo ordenado por parte del equipo de trabajo.
Ilustración 4. El Sprint.
Fuente: Platzi.
Esta metodología cuenta con los siguientes elementos:
 Equipo de trabajo:
El equipo que plantea la metodología SCRUM está determinado por tres tipos de
responsabilidades que se deben implantar para el desarrollo adecuado de las actividades,
entre estas está el propietario del producto, el equipo de desarrollo y el SCRUM master.
Cada uno de ellos puede trabajar de la manera que mejor le parezca, permitiendo
optimizar la productividad, creatividad y flexibilidad del proceso de desarrollo.
 Propietario del producto:
Es la persona encargada de establecer lo que quiere, como lo quiere y las funciones en
cada iteración. Esta persona solo tiene como función la supervisión del desarrollo y de
dirigir el equipo de trabajo.
 Equipo de desarrollo:
Son todos aquellos profesionales que se encargan de desarrollar el software hasta su
completa culminación y funcionamiento adecuado con cada uno de los requerimientos
establecidos por el usuario.
 SCRUM master:
Es aquella persona que tiene mayor conocimiento en el funcionamiento y desarrollo de
la metodología SCRUM. La cual se encargará de explicar al propietario del producto la
planeación del proyecto, así como ayudar al equipo de desarrollo.
 Eventos:
Los eventos en esta metodología tienen como característica principal un tiempo de
duración fijo, por lo cual ninguna actividad puede alargarse o recortarse según el
establecido. Estos eventos son: Sprint (Duración de un mes o menos), planeación del
sprint (Duración de no más de 8 horas), Daily SCRUM (Duración de 15 minutos diarios),
revisión del sprint (Duración de 4 hora por cada sprint de 1 mes) y la retrospectiva del
sprint (Duración de 3 horas por cada sprint de 1 mes).
Esta metodología cuenta con tres actividades que se debe llevar a cabo para el desarrollo del
software:
 Planificación de la iteración: El primer día se realiza la reunión que permita planificar
la iteración. Esta planificación tiene dos partes, la primera que es la selección de
requisitos, lo cual dura máximo 4 horas y la segunda que es la planificación de la
iteración que tiene la misma duración.
 Ejecución de la iteración: En esta reunión el equipo de trabajo inspecciona las
actividades realizadas de cada uno de los miembros pertenecientes para lograr hacer
las respectivas mejoras. Esta reunión dura máximo 15 min. Además, se da respuestas
a preguntas como:
¿Qué he hecho desde la última reunión de sincronización?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?
Durante esta reunión el SCRUM Master se encarga de que se cumplan las diferentes
actividades para el progreso del proyecto, así como de eliminar los obstáculos del mismo.
De igual manera el cliente en conjunto con el equipo de trabajo evalúa los requisitos que
este necesita y si es necesario implanta mejoras o cambios en los mismos.
 Inspección y adaptación: El último día de la iteración se realiza una reunión, la cual
permitirá evaluar la el proceso de iteración. Esta contiene reunión contiene dos partes:
 Demostración. Esta dura máximo 4 horas y es donde el equipo de trabajo
presenta al cliente la culminación del proyecto con cada uno de los requisitos
que este determino. En esta entrega se han retroalimentado cada una de las
mejoras realizadas por el cliente para cumplir con los objetivos deseados.
 Retrospectiva. Tiene una duración de máximo 4 horas y es en donde el
equipo de trabajo analiza su forma de trabajar y presenta algunas iniciativas
que ayudan al mejoramiento del funcionamiento de cada uno de los miembros
del equipo y en el desarrollo de cada proyecto.

6 MARCO LEGAL DE LA INVESTIGACIÓN
Para el desarrollo del marco legal tendremos el reglamento de trabajos de grados en la
institución de educación superior ITFIP, legislación Colombia para la facturación y utilización
de software en establecimientos comerciales con el fin de garantizar su legalidad y cumplir con
las leyes de propiedad intelectual.
6.1 REGLAMENTACIÓN DE TRABAJO DE GRADOS
(ITFIP, 2009) Dentro de su reglamento de trabajo de grado resolución 434 del 23 de
noviembre de 2009, según el artículo 8° Modalidades de trabajo de grado literal a), “Pasantía.
Constituye un ejercicio aplicativo que exige la presencia regular en una empresa u organización,
en el desempeño de un puesto de trabajo o de una tarea específica, acorde al perfil y bajo la
Supervisión de un profesional de la organización y la dirección de un docente de la institución.”
Es decir que contempla el desarrollo de tecnologías como tareas específicas para las
organizaciones o empresas donde se realicen las pasantías.
6.2 FACTURACIÓN EN ESTABLECIMIENTOS COMERCIALES
En Colombia cualquier empresa u organización que tenga una actividad comercial que esté
obligado a realizar facturación está regida por la Ley 1231 de 2008 (Congreso de República de
Colombia, 2008) por la cual se unifica la factura como título valor como mecanismo de
financiación para el micro, pequeño y mediano empresario, y se dictan otras disposiciones. En
su artículo 1° el cual realiza una modifica el artículo 772 del código de comercio colombiano,
define la factura como “un título valor que el vendedor o prestador del servicio podrá librar y
entregar o remitir al comprador o beneficiario del servicio”
La DIAN dirección de impuestos y aduanas nacionales es la encargada de realizar la
vigilancia, verificación y legibilidad de cualquier tipo de facturación.

Para que una factura se considere legal en Colombia y sea considera como un título valor debe
cumplir con los requisitos expuestos en el código de comercio a los cuales hacemos mención a
continuación:
 Estar denominada expresamente como factura de venta.
 Apellidos y nombre o razón y NIT del vendedor o de quien presta el servicio.
 Apellidos y nombre o razón social y NIT del adquirente de los bienes o servicios, junto
con la discriminación del IVA pagado.
 Llevar un número que corresponda a un sistema de numeración consecutiva de facturas
de venta.
 Fecha de su expedición.
 Descripción específica o genérica de los artículos vendidos o servicios prestados.
 Valor total de la operación.
 El nombre o razón social y el NIT del impresor de la factura.
 Indicar la calidad de retenedor del impuesto sobre las ventas.
Cualquier factura que no cumpla con los requisitos mínimos no es considerada como un bien
valor y no tendrá ninguna valides legal con la cual argumentar en caso de alguna reclamación.
6.3 PRESENTACIÓN DE INFORME DE GESTIÓN.
Toda organización o empresas según la ley 603 DE 2000 (COLOMBIA, 2000) estas deben
“realizar un informe anual de gestión y exponer la situación económica, administrativa y jurídica
de la sociedad”. Las entidades o tributarias como la DIAN podrán realizar verificaciones del
cumplimiento de las normar sobre derecho de autor y propiedad intelectual. Es decir que la
empresa deberá reportar el licenciamiento de cada una de las tecnologías que utiliza y requieran
licenciamiento.
Según (Semana, 2016) Al atentar contra los derechos de autor, utilizando software ilegal por
parte de las empresas es considerado como delito en Colombia y está sujeto a investigaciones y
sanciones penales y económicas las cuales verían dependiendo del uso indebido de los
programas
7 ESTADO DEL ARTE O ANTECEDENTES
Para el desarrollo del siguiente proyecto se realizó una indagación sobre las herramientas y
software en el mercado que permitan la integración y control de la información de productos y
facturación de una empresa, para ello se seleccionó los más representativos en el mercado y
realizar un análisis de cada uno de estos que permita conocer sus funcionalidades y costos. Estos
son:
 SIIGO: según (A., s.f.) es “Sistema Integrado de Información Gerencial Operativo, es un
software genérico administrativo que permite llevar unos registros detallado de cada uno
de los registros de la empresa; el mercado objetivo es grandes, medianas y pequeñas
empresas de los sectores industrial, comercial y de servicios.” Este software puede ser
utilizado bajo sistemas operativos Windows, Linux o bajo comunicación por Redes es
decir que permite diversas formas de comunicación con sus bases de datos ofreciendo
diversas formas de conexión.
Se caracteriza por ser un sistema basado en la elaboración de documentos fuentes contando
con módulos como Cartera, Cuentas por pagar, inventarios, Costos de Producción, Activos Fijos,
Pedidos, Compras, Presupuesto, Contabilidad, Nómina y Ventas, permitiendo así un mayor
control de toda la información financiera de la empresa u organización.
Actualmente es utilizado por más de 109.000 empresas en el mercado y sus costos varían
dependiendo los paquetes que se ajusten las necesidades de cada una de las organizaciones, entre
los cuales encontramos.
 SIIGO Emprendedor: Este es el más utilizado para pequeñas empresas, y personas que
requieren gestionar sus negocios el cual tendrá un costo a la actualidad de $112.500 pesos
mensuales que incluye las siguientes funcionalidades.

 Facturación
 Compras y gastos.
 Cuentas por cobrar y por pagar.
 Cotizaciones.
 Inventarios y costeo.
 Gestión de clientes
 SIIGO PYME: Este tipo de licencia esta para medias empresas la cual Permite gestionar
cada una las áreas de la empresa y su costo mensual es De $180.000 pesos. En las cuales
podrá gestionar funciones tales como:
 Facturación
 Compras y gastos.
 Cuentas por cobrar y por pagar.
 Cotizaciones.
 Inventarios y costeo.
 Contabilidad (instalación local).
 SIIGO PLUS: conocido como SIIGO para contadores el cual contempla un periodo de
prueba y su costo mensual es de 385.000 pesos. En los cuales dispondrá de los siguientes
módulos o funciones.
 Contabilidad Multipropósito (NIIF).
 Impuestos.
 Información Exógena.
 Presupuestos.
 Activos Fijos.
 Propiedad Horizontal.
 Generador de informes en Excel.
 Lleva hasta 98 empresas.
 Usuarios ilimitados (misma red)
 SysCafe: Software Integrado de Gestión Empresarial cuenta con característica que
cumplen con los estándares de procesos contables para negocios de grandes o pequeñas
que manejen ventas al público, según el sitio oficial de SysCafe actualmente cuenta con
más de 1500 clientes, de los cuales el 12% son Contadores Públicos Titulados. Este
software está desarrollado por módulos entre los cuales podemos encontrar:
 Gestión comercial
 Contador
 Proceso nómina
 Gestión oficial
 Un software especializado en comercializar café
 Cartera financiera
 P.O.S. y facturación
Este último P.O.S. (Point of sale/punto de venta) y facturación, este módulo realiza
facturación y ventas, controla la administración de documentos comerciales como: Inventarios,
recibos de caja, comprobantes, cheques, informes de recaudo, consulta de artículos, gastos,
estados de caja, etc. Los costos de licencias, implementación y Parametrización del software son
es de un aproximado de $6.500.000 sin gastos de soporte y mantenimiento.
 FacturaCO APP: es un software multiusuario y multiplataforma online que permite
restringir el uso de algunos módulos según el cargo de la persona. se puede usar en

celulares computadores o Tablet. Su interfaz es muy minimalista, entendible y fácil de
manejar, consta de tres colores básicos blanco gris y azul. (APP, s.f.).
Esta herramienta lleva un control de los inventarios de manera ordenada, crea y envía
facturas por email en PDF, registra clientes y también posee un módulo de fidelización de
clientes que consiste en asignar un puntaje a cada cliente dependiendo de la cantidad de dinero
de su factura, el cliente podrá utilizar estos puntos para reclamar premios o canjearlos por más
productos de la empresa.
Cuenta con una versión APP BOX lo cual es una ayuda indispensable cuando se pierde la
conexión a internet el cual almacena la aplicación y la información localmente y permite su
normal funcionamiento, sin paralizar los procesos de ventas, permite realizar pagos en línea y los
informes se exportan en modo xls (el formato de Excel) las facturas son automáticas y se puede
elegir entre imprimirlas tipo tirilla o en una hoja completa.
El costo de esta aplicación varía dependiendo de las características que requieran los usuarios
para aplicación Online tiene un valor máximo de $56.600 mensuales. El costo del APP BOX de
16GB tiene un valor de $1.450.000 y un pago adicional para soporte de $450.000 anuales
8 METODOLOGÍA DE LA INVESTIGACIÓN
Para el desarrollo de proyecto se basará en una investigación de tipo mixta (Cualitativa –
Cuantitativa) con un corte exploratoria – descriptiva- propositiva utilizando métodos y técnicas
de recolección de datos, los cuales se obtendrán de la empresa Plásticos y Desechables Libia del
municipio de Agua de Dios Cundinamarca.
8.1 TIPO DE INVESTIGACIÓN
La investigación basada en la metodología de tipo mixta (Cualitativa – Cuantitativa), en su
corte exploratorio buscara el entendimiento y funcionamiento del sistema de información,
facturación, inventarios y cartera de la empresa plásticos y desechables LIBIA, para establecer la
comprensión de las causas que se generan por la no implementación y sistematización de los
procesos que se lleva a cabo dentro de la organización y así mismo lograr establecer la
problemática de estudio.
Logrando la etapa exploratoria descriptiva se propone por parte del equipo de trabajo
establecer los requerimientos necesarios para proponer el diseño, desarrollo e implementación de
un software para el control y la administración de facturación inventarios y ventas. Con el fin de
ofrecer una alternativa que den solución a la problemática presentada ayudando en presentar un
servicio eficiente y de mejor calidad s sus clientes.
8.2 POBLACIÓN DE LA INVESTIGACIÓN
La investigación se desarrolló en la empresa Plásticos y Desechables Libia del municipio de
Agua de Dios Cundinamarca. Logrando determinar la población como todos los integrantes que
pertenecen a la empresa, lo cuales son el representante legal y sus empleados.

8.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN
Las técnicas empleadas para la recolección de datos fueron las siguientes:
 Entrevistas Formales, las entrevistas se realizaron por medio de preguntas las cuales
estaban diseñadas con el fin de obtener la información precisa por parte de cada uno de
los entrevistados.
 Revisión documental y bibliográfica, con el fin obtener mayor conocimiento del proceso
de facturación ventas e inventarios en Colombia, logrando hacer una revisión de normas
y leyes que regulan facturación e inventarios, esto ayudando a la construcción del marco
teórico y legal del proyecto.
 Observación, es técnica se realizó durante la operatividad de la empresa, esto con el fin
de poder determinar una mayor veracidad del origen del problema obteniendo la
información en tiempo real.
El equipo de trabajo en su totalidad Scrum Team y el propietario del producto, analizan la
información recolectada a través del cada uno de los instrumentos aplicados y las técnicas de
recolección de información, donde se dan respuesta a cada uno de los interrogantes planteados y
se estudian las posibles soluciones tecnológicas, se traza la ruta a seguir con el fin de llevar a una
solución óptima que beneficie el proceso y la micro empresa Plásticos y Desechables Libia
9 MARCO DE TRABAJO PARA EL DESARROLLO ÁGIL DE SOFTWARE: SCRUM
Según la autora del sitio web IDA Dra. (Beatriz Margarita Leal , 2017), las metodologías
agiles permiten un trabajo colaborativo permitiendo un mayor control y capacidad de prevenir
posibles afectaciones al de desarrollo del proyecto y del software mismo.
Esta metodología SCRUM, está conformada por las siguientes fases según (Cruz-Lemus,
2014).
FASE 1. ANÁLISIS DE REQUISITOS
Se analizan cada uno de los requerimientos según las especificaciones del cliente o usuario y
se determinan cada uno de los objetivos del software, es en esta fase donde se realiza la
planificación total del proyecto.
FASE 2. PLANEACION Y GESTIÓN DEL PROYECTO
Se establecen las funcionalidades y actividades a realizar para cada uno de los objetivos y
requerimientos, se establecen costos, y estudios de factibilidad para el desarrollo del proyecto y
realizar los ajustes pertinentes para el cumplimiento de proyecto.
Actividades:
 Realizar requerimientos funcionales y no funcionales
 Realizar estudios de factibilidad.
 Generar el presupuesto del proyecto.
 Matriz de riesgos para el desarrollo del proyecto.
FASE 3. SPRINT PLANNING MEETING.
Se planifica el sprint donde el cliente despeja las dudas del equipo de trabajo y aprueba el
sprint para proceder con el desarrollo de cada módulo del software. Para ello se desarrolla en dos
partes:
Selección de requisitos: Es la iteración es realizada entre cliente y equipo, se seleccionan los
requisitos más prioritarios que se comprometen a completar en la iteración
Planificación de la iteración: Se elabora la lista de tareas o acciones necesarias para la
realización y cumplimiento del sprint, esta activada se realiza de manera constante con todo el
equipo de trabajo.
Actividades:
 Reunión con cliente para selección de prioridades de iteración.
 Identificación del sprint y sus actividades.
 Asignación de tareas según perfiles.
A continuación, se relacionan los Sprint desarrollados de la siguiente manera 1).
Determinación de premisas de COIN, 2). Diseño de la base de datos de COIN, 3). Diseño y
desarrollo de módulos. Ver tablas (1, 2, 3) y el Product Backlog donde se agrupa todos los Sprint
y se estima la cantidad de esfuerzos de cada una de las iteraciones. Ver tabla N°4.
Tabla 1 Sprint N°1Determinación De Premisas De COIN
SPRINT N°1 - DETERMINACION DE PREMISAS DE COIN

días del sprint/esfuerzo (Hrs)
ID.his Requerimiento/Tarea Responsable 1 2 3 4 5 6 7 8 9 10 … … …
0
1 Realización de entrevista al gerente de la empresa SCRUM TEAM Cristian Oswaldo x

Plásticos LIBIA Lozada Tovar, Luis R. Ramírez
Liévano, Alejandra Romero Ruiz
2 Análisis de cada uno de los procesos de al Plásticos Guzmán, Libia Rosa Ruiz x
LIBIA a sistematizar
3 Recopilación de inventarios de productos del Plásticos SCRUM TEAM Cristian Oswaldo x

Libia Lozada Tovar, Luis R. Ramírez
4 Planteamiento de las posibles soluciones del cliente Guzmán, Libia Rosa Ruiz x
5 Establecer alcances y limitaciones de proyecto SCRUM TEAM Cristian Oswaldo x

Lozada Tovar, Luis R. Ramírez
Liévano, Alejandra Romero Ruiz,
6 Realizar búsqueda de software de facturación e José Alexander Aguilar González, x
inventarios para conocer su funcionamiento Soraya Jiménez Montaña, Melissa
Rivera Guzmán
7 Determinación de los módulos del sistema SCRUM TEAM Cristian Oswaldo x

José Alexander Aguilar González
8 Establecer recursos tecnológicos para el desarrollo del x
proyecto
9 Establecer lo colores, tipográfica e iconografía de la SCRUM TEAM Cristian Oswaldo x

aplicación COIN Lozada Tovar, Luis R. Ramírez
José Alexander Aguilar González,
Soraya Jiménez Montaña, Melissa
Rivera Guzmán
Fuente: Elaboración propia.

Tabla 2 Sprint N°2 Diseño de la base de datos de COIN
SPRINT N°2 DISEÑO DE LA BASE DE DATOS DE COIN

días del sprint/esfuerzo (Hrs)
ID.his Requerimiento/Tarea Responsable 1 2 3 4 5 6 7 8 9 10 … … …
1 Determinación de finalidades de la base de datos SCRUM TEAM Cristian Oswaldo x

2 Determinar tablas y campos de la base de datos. SCRUM TEAM Cristian Oswaldo x

3 Diseñar el modelo con la técnica Modelo Entidad Relación SCRUM TEAM Cristian Oswaldo x
4 Crear base de datos en SGBD MySQL SCRUM TEAM Cristian Oswaldo x

5 Identificar el campo los campos con valores únicos en cada SCRUM TEAM Cristian Oswaldo x
registro (Llaves Primarias) Lozada Tovar, Luis R. Ramírez
6 Perfeccionar el diseño SCRUM TEAM Cristian Oswaldo x
8 Ingresar los datos a la base de datos por medio del SGBD SCRUM TEAM Cristian Oswaldo x
Mysql Lozada Tovar, Luis R. Ramírez
Tabla 3 Sprint N°3 Diseño Y Desarrollo De Módulos
SPRINT N° 3 DISEÑO Y DESARROLLO DE MODULOS

ID.his Requerimiento/Tarea Responsable días del sprint/esfuerzo (Hrs)
0 1 2 3 4 5 6 7 8 9 10 20 … …
1 Diseño de interfaz gráfica de COIN SCRUM TEAM Cristian Oswaldo x

2 Desarrollo de Modulo de Devoluciones, reportes, y SCRUM TEAM Cristian Oswaldo X+

tablas Maestras Lozada Tovar, Luis R. Ramírez
3 Desarrollo de Modulo de Login resumen del día y SCRUM TEAM Cristian Oswaldo X+
estadística, Usuarios. Lozada Tovar, Luis R. Ramírez
4 Desarrollo de Módulos Almacén, Compra SCRUM TEAM Cristian Oswaldo X+

5 Desarrollo de Modulo de Ventas, Pago a cartera SCRUM TEAM Cristian Oswaldo X+

6 Desarrollo de los módulos de configuraciones generales SCRUM TEAM Cristian Oswaldo X+

tales como: Configuración de zona, Consultas, Lozada Tovar, Luis R. Ramírez
Herramientas del sistema. Liévano, Alejandra Romero Ruiz
Tabla 4 Pila de requerimientos y prioridades de COIN
DESCRIPCION DE LOS REQUERIMIENTOS PRIORIDAD TOTAL, DIAS ESTIMADOS SPRINT
Realización de entrevista al gerente de la empresa Plásticos LIBIA 1 2 1
Análisis de cada uno de los procesos de al Plásticos LIBIA a sistematizar 1 2 1
Recopilación de inventarios de productos del Plásticos Libia 1 3 1
Planteamiento de las posibles soluciones del cliente 1 5 1
Establecer alcances y limitaciones de proyecto 1 8 1

DESCRIPCION DE LOS REQUERIMIENTOS PRIORIDAD TOTAL, DIAS ESTIMADOS SPRINT
Realizar búsqueda de software de facturación e inventarios para conocer su
1 5 1
funcionamiento
Determinación de los módulos del sistema 1 8 1
Establecer recursos tecnológicos para el desarrollo del proyecto 2 3 1
Establecer lo colores, tipográfica e iconografía de la aplicación COIN 2 2 1
Determinación de finalidades de la base de datos 3 2 2
Determinar tablas y campos de la base de datos. 3 2 2
Diseñar el modelo con la técnica Modelo Entidad Relación 3 3 2
Crear base de datos en SGBD MySQL 3 2 2

Identificar el campo los campos con valores únicos en cada registro (Llaves
3 1 2
Primarias)
Perfeccionar el diseño del modelo de base de datos 3 1 2
Ingresar los datos a la base de datos por medio del SGBD Mysql 2 6 2
Diseño de interfaz gráfica de COIN 4 10 3
Desarrollo de Modulo de Devoluciones, reportes, y tablas Maestras 4 30 + 3
Desarrollo de Modulo de Login resumen del día y estadística, Usuarios. 4 20 + 3
Desarrollo de Módulos Almacén, Compra 4 30 + 3
Desarrollo de Modulo de Ventas, Pago a cartera 4 30 + 3

Desarrollo de los módulos de configuraciones generales tales como: Configuración
4 30 3
de zona, Consultas, Herramientas del sistema.
FASE 4. EJECUCIÓN DE SPRINT
Se realiza la materialización de cada una de las actividades del sprint y entregas al cliente,
Con los lenguajes de programación que se ajusten a las necesidades del desarrollo
solicitado.
En esta fase se desarrollan reuniones diarias con el equipo de trabajo los cuales deben
responder a los siguientes interrogantes:
¿Qué he hecho desde la última reunión de sincronización?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?
FASE 5. INSPECCIÓN E ITERACIÓN
Se realiza la entrega de cada una de las interacciones al cliente realizando las pruebas
necesarias para la satisfacción del usuario final.
Actividades:
 Pruebas de caja negra y caja blanca
 Retroalimentación de cada sprint con el equipo de trabajo.
 Pruebas de satisfacción
9.1 PLANEACIÓN DEL PROYECTO “COIN”
Para el inicio de cualquier proyecto se hace necesario la planificación de los procesos y
actividades que hacen parte de la metodología de desarrollo de software, permitiendo la
conformación de un grupo de trabajo interdisciplinario asignándoles actividades y
responsabilidades a realizar, las herramientas de desarrollo necesarias para la ejecución y
puesta en marcha de la aplicación. El producto COIN se desarrolló bajo la metodología ágil
de desarrollo SCRUM, en la cual el grupo de trabajo ejecuta y desarrolla cada una de las
fases previstas por la metodología.

9.2 CONFORMACIÓN DEL EQUIPO
El equipo de trabajo estará conformado por los siguientes integrantes, cumplirán con un
rol y actividades específicas, para el óptimo desarrollo del proyecto.
LIBIA ROSA RUIZ – CLIENTE. Este rol deberá cumplir con las siguientes funciones:
 Facilitará al equipo de trabajo los requerimientos funcionales.
 Se reunirá con el SCRUM Master para aprobación de las iteraciones.
 Aprobar los diseños de las interfaces graficas de software.
ALEJANDRA ROMERO RUIZ- SCRUM MASTER. Este rol deberá cumplir con las
siguientes funciones:
 Liderar al equipo de trabajo.
 Gestionar las reuniones diarias con el SCRUM TEAM
 Garantizar el cumplimiento de las actividades.
 Corregir errores y problemas en el desarrollo del software junto con el asesor.
 Realizar el levantamiento de los requerimientos del software.
 Realizar el análisis de los requerimientos junto con el SCRUM TEAM.
NAYIBE SORAYA SANCHEZ LEÓN- DIRECTOR DEL PROYECTO. Este rol
tendrá como funciones principales las siguientes:
 Generar un buen ambiente de trabajo dentro del grupo.
 Gestionar reuniones de acuerdo a lo establecido en la metodología SCRUM.
 Verificar el cumplimiento de cada una de las actividades establecidas en el sprint.
 Asesorar en el diseño y elaboración del proyecto.
CRISTIAN OSWALDO LOZADA TOVAR, LUIS RAMÓN RAMÍREZ LIÉVANO,
ALEJANDRA ROMERO RUIZ – PROGRAMADOR. Este rol tendrá como funciones
principales las siguientes:
 Elegir el lenguaje de programación para el desarrollo del software.

 Establecer con el cliente las prioridades de las iteraciones
 Codificar los requerimientos funcionales establecidos por el cliente
MELISSA RIVERA GUZMAN Y LUIS RAMÓN RAMÍREZ LIÉVANO-
DISEÑADOR/PROGRAMADOR. Este rol cumplirá con las siguientes funciones:
 Diseñar el modelo de la base de datos junto al SCRUM master.
 Elaborar los diseños creativos de las interfaces para el software.
 Diseñar el logotipo del software.
 Programador asistente.
9.3 GESTIÓN RIESGOS DEL PROYECTO
Para (Castañeda Fuentes, 2017) la gestión de riesgos es: “identificar, analizar y responder
al riesgo durante el ciclo de vida del proyecto y con el mejor interés de alcanzar los objetivos
del proyecto”.
En todo proyecto es de vital importancia establecer los riesgos que se pueden llegar a
presentar antes, durante y después del desarrollo del proyecto. Además de esto los planes de
contingencia son fundamentales para mitigar en gran medida dichos riesgos que podrían
llegar a ser de gran inconveniente en el alcance de los objetivos.
Por esta razón se emplea la guía PMBOK (Project Management Institute, I., 2013) en
donde se presenta una serie de pautas, normas y estándares para la gestión de proyectos. Esta
guía cuenta con cuatro fases que son fundamentales para su correcta aplicación. Estas son:
Plan de Identificació
Respuerta n
Análisis
Ilustración 5. Fases de la guía de PMBOK.
Para lograr establecer los riesgos que se pueden llegar a presentar en el desarrollo del
proyecto se evaluaron las experiencias que el equipo de desarrollo ha tenido en proyectos
anteriores, así como también la investigación de diferentes fuentes relacionadas con el
proyecto y los eventos en donde el grupo de investigación ha participado; logrando
evidenciar algunos riesgos que se han presentado en los diferentes proyectos.
Además de esto y en base a la guía PMBOK se establece una tabla de probabilidad que
maneja cinco niveles en los cuales se va a lograr medir la probabilidad de que un riesgo
ocurra en el desarrollo del proyecto.
Tabla 5 Probabilidad de presencia de los riesgos.
NIVEL DESCRIPTOR DESCRIPCIÓN

1 Raro El riesgo puede ocurrir sólo en circunstancias
excepcionales.
2 Improbable El riesgo puede ocurrir en algún momento.
3 Posible El riesgo podría ocurrir en algún momento.
4 Probable El riesgo probablemente ocurrirá en la mayoría
de las circunstancias.
5 Casi seguro Se espera que el riesgo ocurra en la mayoría de
las circunstancias
Fuente. La guía PMBOK
El impacto es uno de los aspectos fundamentales a la hora de evaluar los riesgos que
puede llegar a tener un proyecto, este aspecto afecta gran parte del desarrollo como lo es el
tiempo, los objetivos, los costos, los alcances, la calidad, los recursos, etc., por esta razón la
guía PMBOK establece cinco niveles para medir el impacto que puede llegar a tener dicho
riesgo. En la siguiente tabla se pueden observar dichos niveles.
Tabla 6 Tabla de nivel de impacto
NIVEL DESCRIPTOR DESCRIPCIÓN

1 Insignificante Si el hecho llegara a presentarse, tendría
consecuencias o efectos mínimos.
2 Menor Si el hecho llegara a presentarse, tendría bajo
impacto.
3 Moderado Si el hecho llegara a presentarse, tendría mediano
impacto.
4 Mayor Si el hecho llegara a presentarse, tendría alto
impacto.
5 Catastrófico Si el hecho llegara a presentarse, tendría desastrosas
consecuencias.
Es así como se establece una puntuación para cada uno de los riesgos identificados en el
presente proyecto, dicha puntuación es tomada de la tabla de probabilidad vs impacto
proporcionado por la guía PMBOK. De esta forma se obtiene el resultado total de la
probabilidad de que un riesgo ocurra por el impacto que tendría dicho riesgo en cada uno de
los objetivos como son (alcance, tiempo, costo y calidad).
Tabla 7 Tabla de probabilidades e impacto
IMPACTO
Insignificante Menor Moderado Catastrófico
Mayor (4)
(1) (2) (3) (5)
Raro (1)
Improbable
(2)
Posible (3)
Probable
(4)
Casi
seguro (5)
Para clasificar la probabilidad por el impacto de cada uno de los riesgos identificados, se
establece una escala numérica que determina el nivel que representa dicho riesgo en el
proyecto. La escala mencionada se puede apreciar seguido de este párrafo y contiene los
siguientes niveles (muy bajo, bajo, medio, alto y muy alto) en los cuales se ubica cada riesgo
según el total obtenido de probabilidad por impacto. Esto permite crear alertas sobre los
riesgos que poseen un nivel alto y muy alto para así poder actuar sobre ellos.
Tabla 8 Tabla del Nivel de Riesgo.
NIVEL DE RIESGOS PROBABILIDAD POR IMPACTO

Muy Alto >80
Alto 51 - 80
Medio 31 – 50
Bajo 11 – 30
Muy Bajo <10
Desde las tablas x a la x se podrán visualizar cada uno de los riesgos identificados para el
presente proyecto. A su vez se especifica la causa raíz que los ocasiona, los entregables que
pueden ser afectados si ocurre este riesgo, como también la estimación de probabilidad y de
impacto para cada uno de los objetivos afectados (alcance, tiempo, costo, calidad) y finalmente
el nivel del riesgo según la escala de la guía PMBOK.
Una vez se establece el nivel de riesgo que implica cada uno en el proyecto, se toman los
riesgos que arrojan un nivel alto y muy alto para poder actuar sobre ellos y diseñar un plan de
contingencia que permita mitigar el impacto que estos puedan causar.
El plan de contingencia se puede apreciar en las tablas x a la x, allí se asigna cada riesgo
identificado a un responsable; con el fin de ser el encargado de ejecutar el plan de acción
desarrollado y realizar el seguimiento correspondiente para mitigar o contrarrestar el impacto
que este riesgo causa dentro del proyecto una vez se presenta.
Es preciso tener en cuenta que el plan de acción que se desarrolla para cada uno de los
riesgos con el fin de mitigarlos, se les debe realizar un seguimiento continuo por parte del
responsable(s) asignado. Dicho seguimiento debe hacerse cada determinado tiempo, tiempo
que se define por el grupo de trabajo el cual valida el estado y nivel en el que se encuentra este
riesgo evaluado.
A continuación, se presenta una serie de tablas que muestran a detalle la matriz de
evaluación de riesgos por cada una de las fases del desarrollo de software y el plan de
contingencia desarrollado para mitigar dichos impactos.

Tabla 9 Matriz de evaluación de riesgos 001 a 005.
NIVEL
DESCRIPCIÓN ENTREGABLES ESTIMACIÓN OBJETIVO ESTIMACIÓN PROBABILIDAD
CÓDIGO DEL RIESGO CAUSA RAÍZ DE
DEL RIESGO AFECTADOS PROBABILIDAD AFECTADO IMPACTO X IMPACTO
RIESGO
Alcance 4 16
Requerimientos Los Requerimientos no se Tiempo 3 12
Documento de
R-001 incompletos o definieron de manera clara y 4 Costo 3 12 Alto
requerimientos.
ambiguos. completa. Calidad 3 12
Total Probabilidad x Impacto 52
Falta de Alcance 4 16
acompañamiento Tiempo 4 16
Usuarios que no colaboran o no
de los usuarios Documento de
R-002 se comprenden con la definición 4 Costo 3 12 Alto
en el requerimientos.
de los requerimientos Calidad 4 16
levantamiento de
requerimientos. Total Probabilidad x Impacto 60
Alcance 3 6
Las reuniones con el cliente para
Retrasos en la el levantamiento de Tiempo 3 6
Documento de
R-003 especificación de requerimientos se posponen. Las 2 Costo 4 8 Bajo
requerimientos.
requerimientos. especificaciones de las interfaces Calidad 4 8
esenciales no están a tiempo.
Alcance 3 12
Incorporación El cliente no tiene claridad de lo Tiempo 4 16
continúa de que desea. Necesidad nueva por Documento de
R-004 4 Costo 3 12 Alto
nuevos parte del mercado, del gobierno o requerimientos.
requerimientos. del negocio. Calidad 4 16
Alcance 5 10
Modificación Actualización necesaria debido a Tiempo 5 10
Documento de
R-005 continúa de una deficiente definición de 2 Costo 4 8 Medio
requerimientos.
requerimientos. requerimientos inicialmente. Calidad 4 8
NIVEL
CÓDIGO DEL DESCRIPCIÓN ENTREGABLES ESTIMACIÓN OBJETIVO ESTIMACIÓN PROBABILIDAD
CAUSA RAÍZ DE
RIESGO DEL RIESGO AFECTADOS PROBABILIDAD AFECTADO IMPACTO X IMPACTO
RIESGO
Actualización incorrecta Alcance 4 8
Modificaciones de los requerimientos Tiempo 4 8
Documento de
R-006 incorrectas de las debido a la ausencia de 2 Costo 3 6 Bajo
requerimientos.
especificaciones un estudio detallado Calidad 3 6
previo. Total Probabilidad x Impacto 28
El ingeniero de Alcance 4 12
requerimientos entiende Tiempo 3 9
Entendimiento
y documenta de manera Documento de
R-007 errado de los 3 Costo 2 6 Medio
equivocada las requerimientos.
requerimientos Calidad 2 6
necesidades expuestas
por el cliente. Total Probabilidad x Impacto 33
Alcance 3 6
Incorrecta Pobre definición de tipos
definición y de datos e integridad, y Tiempo 3 6
Documento de
R-008 estructuración de poco entendimiento 2 Costo 3 6 Bajo
Diseño Detallado.
los datos sobre la relación o
establecidos. dependencia de estos. Calidad 3 6
Alcance 3 12
Desconocimiento de Tiempo 4 16
Diseño de
todas las interfaces que Documento de
R-009 interfaces 2 Costo 3 12 Alto
pueden afectar la Diseño Detallado.
incompleto
solución Calidad 3 12
Alcance 4 12
Al realizar el diseño se Tiempo 5 15
Subestimación
subestima el software Documento de
R-010 del tamaño de la 3 Costo 4 12 Alto
con respecto a las Diseño Detallado.
aplicación.
necesidades del cliente. Calidad 4 12
NIVEL
RIESGO
No se Define adecuadamente las Alcance 5 20
Falta de interconexiones y recursos Tiempo 5 20
Especificación lógicos entre módulos del sistema Documento de
R-011 4 Costo 3 12 Alto
de la arquitectura de manera apropiada para su Diseño Detallado
lógica. diseño detallado y Calidad 4 16
administración.
Total, Probabilidad x Impacto 68
Alcance 3 9
No se define correctamente el
Falta de Tiempo 3 9
conjunto de dispositivos físicos
Especificación Documento de
R-012 que se va a utilizar para que la 3 Costo 2 6 Bajo
de la arquitectura Diseño Detallado
arquitectura lógica funcione
física Calidad 2 6
correctamente.
Alcance 3 12
Mala interpretación y/o Tiempo 2 8
Desconocimiento
interpretación superficial de los Documento de
R-013 de la lógica de 4 Costo 1 4 Medio
requisitos para hacer el diseño Diseño Detallado
negocio
detallado del sistema Calidad 4 16
Alcance 3 9
Las herramientas CASE que se Tiempo 4 12
Bajo rendimiento
utilizan como apoyo no tienen el Implementación
R-014 de la herramienta 3 Costo 4 12 Medio
rendimiento y las funcionalidades del software.
CASE
esperadas Calidad 3 9
Alcance 3 6
Despliegue incompleto de versión
Manejo de la aplicación, El no despliegue Tiempo 4 8
inadecuado en de la última la versión de la Implementación
R-015 2 Costo 4 8 Bajo
liberación de aplicación, Despliegue de versión del software.
versiones con direccionamiento equivocada Calidad 4 8
a bases de datos.
NIVEL
RIESGO
Alcance 3 6
Limitación del tiempo. Tiempo 4 8
Falta de
Aplicación de malas prácticas de Implementación
R-016 documentación 3 Costo 3 6 Bajo
desarrollo y ausencia de del software.
en código fuente
revisiones Calidad 3 6
Actividades no contempladas. Alcance 5 20
Adición de nuevas actividades.
Modificación Complejidad del desarrollo de Tiempo 4 16
Implementación
R-017 cronograma actividades no estimadas. 3 Costo 5 20 Alto
del software.
actividades Retrasos en la ejecución de
actividades por improvistos Calidad 5 20
indirectos. Total Probabilidad x Impacto 76
Alcance 4 12
No Tiempo 4 12
disponibilidad de El hardware y/o software esencial Implementación
R-018 3 Costo 4 12 Medio
hardware y/o no es entregado a tiempo. del software.
software. Calidad 4 12
El desarrollo de la aplicación Alcance 4 8
tiene un nivel alto de Tiempo 4 8
El Software es
complejidad. El modelado del Implementación
R-019 complejo de 2 Costo 3 6 Bajo
sistema realizado en la fase de del software.
implementar Calidad 3 6
diseño no fue tan claro y
especifica. Total Probabilidad x Impacto 28
Al codificar y comenzar la Alcance 3 9
Compleja la integración se hace evidente que Tiempo 4 12
integración de la especificación está incompleta Implementación
módulos del o contiene requisitos del software.
software contradictorios o hay falencias en Calidad 4 12
el diseño del software. Total Probabilidad x Impacto 42
NIVEL
RIESGO
Alcance 4 12
Retiro de Al ser las únicas personas que Tiempo 4 12
personal con manejan ciertos temas específicos Implementación
conocimiento y y/o complejos generan retraso al del software.
experiencia irse durante el curso de las tareas. Calidad 3 9
La comunicación entre el Alcance 3 6
No hay buena personal del área de desarrollo no Tiempo 4 8
comunicación es el más óptimo y así mismo su Implementación
R-022 2 Costo 3 6 Bajo
y/o sinergia en el sinergia no es la más eficaz para del software.
equipo. el cumplimiento de objetivos en Calidad 3 6
común. Total Probabilidad x Impacto 26
Falta de Alcance 3 6
conocimiento y
Tiempo 4 8
Experiencia El personal no es idóneo o no
Implementación Costo 3 6
R-023 sobre las tareas tiene la experiencia necesaria 2 Bajo
del software.
asignadas y las para el rol asignado. Calidad 3 6
herramientas a
utilizar. Total Probabilidad x Impacto 26
Alcance 4 8
Perdida de la copia de seguridad
de la versión de software actual Tiempo 5 10
Pérdida de Implementación
R-024 causado por virus o por remplazo 2 Costo 4 8 Medio
Backus del software.
de versión sin sacar la copia Calidad 4 8
previamente.
Alcance 3 9
No se definió desde el inicio de la
Alcance de las Tiempo 3 9
fase el alcance debido a que no se Aseguramiento de
pruebas No
R-025 tenía documentación o la que calidad del 3 Costo 2 6 Bajo
definido
existía era muy superficial o software.
completamente. Calidad 2 6
estaba desactualizada
Tabla 14 Matriz de evaluación de riesgos 026-030.
NIVEL
RIESGO
Alcance 4 12
Documentación
Los casos de prueba no quedan
de requisitos Tiempo 4 12
cubiertos en su totalidad, debido a Aseguramiento de
insuficiente,
R-026 que pueden existir cambios y/o calidad del 3 Costo 4 12 Alto
desactualizada,
mejoras que no se encuentran software.
contradictoria o Calidad 5 15
actualizados a la fecha.
ambigua.
Alcance 4 12
No realizar Tiempo 5 15
Alta Inestabilidad del ambiente Aseguramiento de
pruebas en
R-027 Funcionalidades probadas, pero calidad del 3 Costo 4 12 Alto
ambiente
no certificadas al 100%. software. Calidad 4 12
desarrollo
Alcance 4 8
El conjunto de pruebas realizadas
No se realiza no son lo suficientes para Aseguramiento de Tiempo 4 8
R-028 completitud en garantizar la calidad del software calidad del 2 Costo 4 8 Medio
las pruebas. esto sucede por omisión y/o por software. Calidad 4 8
falta de tiempo.
No se le da prioridad para probar Alcance 3 9
las funcionalidades más
No se realiza Tiempo 3 9
importantes y complejas del Aseguramiento de
priorización en Costo 3 9
R-029 software Al final se descubre calidad del 3 Medio
las ejecuciones
defectos bloqueantes los cuales software. Calidad 2 6
de las pruebas
necesita tiempo para ser
solucionados. Total Probabilidad x Impacto 33
Demoras Alcance 4 12
excesivas en la Solución de defectos no Tiempo 5 15
Aseguramiento de
reparación de priorizada por parte de los
R-030 calidad del 3 Costo 3 9 Medio
defectos desarrolladores lo cual retrasa las
encontrados en pruebas.
las pruebas Total Probabilidad x Impacto 45
NIVEL
CÓDIGO DEL DESCRIPCIÓN ENTREGABLES ESTIMACIÓN OBJETIVO ESTIMACIÓN PROBABILIDAD
CAUSA RAÍZ DE
RIESGO DEL RIESGO AFECTADOS PROBABILIDAD AFECTADO IMPACTO X IMPACTO
RIESGO
Problemas con el Alcance 4 12
alistamiento, adecuación Tiempo 5 15
Problemas de y estabilización del
Aseguramiento de Costo 4 12
disponibilidad ambiente donde se
R-031 calidad del 3 Calidad 4 12 Alto
con el ambiente ejecutan las pruebas,
software.
de pruebas. afectando cronogramas y
retrasando el inicio de Total Probabilidad x Impacto 51
cada ciclo.
Retraso causado por Alcance 4 16
Retraso Testing Tiempo 5 20
despliegues los cuales Aseguramiento de
debido a nuevos
R-032 dañan funcionalidades calidad del 4 Costo 4 16 Alto
errores después
ya exitosas, generando software. Calidad 4 16
de despliegues
así nuevos defectos. Total Probabilidad x Impacto 68
Tiempos muertos en Alcance 4 8
subfases iniciales de la Tiempo 3 6
Aseguramiento de
Pobre fase de pruebas que no
R-033 calidad del 2 Costo 3 6 Bajo
Productividad se pueden recuperar por
entregas tardías de
desarrollo. Total Probabilidad x Impacto 26
Ingreso tardío del Alcance 4 8
No hay
personal a los roles Tiempo 5 10
suficientes Aseguramiento de
necesitados. Personal
R-034 recursos y/o calidad del 2 Costo 4 8 Medio
reducido donde se
ingresan software. Calidad 4 8
necesitan más de los
demasiado tarde Total Probabilidad x Impacto 34
asignados.
Por limitación o Alcance 4 12
subestimación del Tiempo 5 15
Capacitación Puesta en
tiempo se realiza una
R-035 superficial a producción del 3 Costo 4 12 Alto
capacitación incompleta
usuarios finales software. Calidad 4 12
sobre el uso de la
aplicación. Total Probabilidad x Impacto 51
NIVEL
RIESGO
La capacidad a nivel de hardware Alcance 3 9
La aplicación no
no es acorde al número de Tiempo 4 12
procesa Puesta en
transacciones solicitadas. La Costo 3 9
R-036 transacciones por producción del 3 Medio
codificación del procedimiento de
segundo como se software. Calidad 3 9
la transacción es poco eficiente en
esperaba.
el tiempo de respuesta. Total Probabilidad x Impacto 39
Alcance 4 16
Fallas del Tiempo 4 16
Inestabilidad de la red y/o Puesta en
hardware limitan
R-037 Internet. Caída o afectación por producción del 4 Costo 4 16 Alto
la funcionalidad
virus de los servidores. software. Calidad 4 16
del software
Especificación superficial de los Alcance 4 16
requisitos básicos para la Tiempo 4 16
Arquitectura Puesta en
arquitectura hardware y software.
R-038 inadecuada por producción del 4 Costo 3 12 Alto
Modificación de la arquitectura
parte del cliente software. Calidad 3 12
con respecto a la definida
inicialmente. Total Probabilidad x Impacto 56
Alcance 3 6
Documentación Generación pobre de documentos Puesta en Tiempo 3 6
R-039 sobre el uso de la necesarios para la instalación y producción del 2 Costo 2 4 Bajo
aplicación. uso efectivo de la aplicación. software. Calidad 2 4
Omisión de validaciones en la Alcance 4 12
Vulnerabilidades fase de pruebas. Ambiente Tiempo 4 12
Puesta en
del software producción como es un ambiente
R-040 producción del 3 Costo 4 12 Alto
presentadas en real se pueden presentar defectos
producción. que no se presentaron en el
ambiente semi-real de pruebas. Total Probabilidad x Impacto 51
CÓDIGO NIVEL
DEL CAUSA RAÍZ DE
RIESGO RIESGO
El personal que Alcance 4 16
va a utilizar el Tiempo 4 16
nuevo software Costo 3 12
Resistencia del
presenta miedo Calidad 3 12
personal para Puesta en
al cambio
R-041 cambiar las producción del 4 Alto
debido a la
prácticas del software.
costumbre de
pasado Total Probabilidad x Impacto 56
utilizar el
anterior
software.
El cliente por el Alcance 5 10
afán de salir a Tiempo 5 10
producción toma Costo 4 8
Software
el riesgo de salir Calidad 5 10
contiene
con defectos Puesta en
numerosos
R-042 existentes en la producción del 2 Medio
errores cuando se
aplicación que software.
entrega al
aún no se han Total Probabilidad x Impacto 38
cliente.
solucionado por
parte del equipo
de desarrollo.
Hallazgo de Alcance 5 10
defectos que no Tiempo 5 10
Presentación de se detectaron Costo 4 8
Puesta en
defectos en previamente o Calidad 5 10
R-043 producción del 2 Medio
ambiente que no se
software.
producción. presentaron en el Total, Probabilidad x
ambiente de 38
Impacto
pruebas.
Tabla 18 Plan de contingencia para riesgos del 001 al 009.
CODIGO AMENAZA/OPORTUNIDAD DECRIPCION NIVEL TIPO DE RESPONSABLE PLAN DE

DEL DEL RIESGO DE RESPUESTA MITIGACION
RIESGO RIESGO
R-001 AMENAZA Requerimientos ALTO MITIGAR PRODUCT OWNER  Los usuarios
incompletos o deben tener
ambiguos. claro lo que
desean.
 Listado de
incógnitas
sobre los temas
que poco claros
en las
reuniones.
 Incorporar los
nuevos
requerimientos
de forma clara
y completa.
R-002 AMENAZA Falta de ALTO MITIGAR SCRUM MASTER  Reuniones

acompañamiento periódicas con
de los usuarios el cliente.
en el  Participación
levantamiento del usuario en
de la definición de
requerimientos. requerimientos.
 Compromiso y
responsabilidad
por parte de los
usuarios.
R-004 AMENAZA Incorporación ALTO MITIGAR PRODUCT OWNER  Realizar
continúa de reuniones
nuevos frecuentes con
requerimientos. el usuario para
que establezca
requisitos.
R-009 AMENAZA Diseño de ALTO MITIGAR SCRUM TEAM  Establecer las

interfaces vistas
incompleto preliminares
del software.
 Desarrollar los
modelos
requeridos para
cada interfaz.
 Evaluar
frecuentemente
la aplicación.

RIESGO RIESGO
R-010 AMENAZA Subestimación ALTO MITIGAR SCRUM MASTER  Ser consciente de
del tamaño de SCRUM TEAM los alcances que
la aplicación. debe tener el
aplicativo.
 Tener claro los
módulos del
desarrollo.
R-011 AMENAZA Falta de ALTO MITIGAR SCRUM TEAM  Definir la

Especificación arquitectura
de la lógica correcta y
arquitectura más eficiente con
lógica. base a la
especificación de
requerimientos.
 Revisión y apoyo
por parte del
líder de
desarrollo.
 Realizar el
diseño de la
arquitectura
lógica teniendo
en cuenta la
arquitectura que
requiere el
cliente.
 Utilizar modelos,
vistas y
diagramas para el
diseño de la
arquitectura
lógica.
R-017 AMENAZA Modificación ALTO MITIGAR SCRUM MASTER  Recibir a tiempo
cronograma los documentos
actividades de diseño.
 Recibir
contextualización
y apoyo por parte
del equipo de
diseño.
 Tener claro el
alcance del
desarrollo de la
aplicación.
 Realizar una
buena planeación
de recursos,
tareas y tiempos
para evitar
posibles
desfases.
 Incluir en la
planeación un
tiempo racional
por si ocurre
imprevistos
indirectos.

RIESGO RIESGO
R-026 AMENAZA Documentación ALTO MITIGAR SCRUM MASTER  Entrega de la
de requisitos SCRUM TEAM última versión
insuficiente, del documento
desactualizada, en la fecha
contradictoria o actual.
ambigua.  Funcionales
deben
informar y
explicar los
cambios que
se den.
 Funcionales
deben entregar
las nuevas
versiones de
los
documentos.
R-027 AMENAZA No realizar ALTO MITIGAR SCRUM TEAM  Realizar las
pruebas en pruebas en un
ambiente ambiente
desarrollo aislado del de
desarrollo.
R-031 AMENAZA Problemas de ALTO MITIGAR SCRUM TEAM  Preestablecer

disponibilidad un ambiente
con el ambiente de pruebas
de pruebas.
tranquilo y
adecuado.
 Coordinar con
anterioridad
las pruebas
pertinentes.
R-032 AMENAZA Retraso Testing ALTO MITIGAR SCRUM TEAM  Establecer con
debido a anterioridad
nuevos errores las pruebas de
después de Testing.
despliegues  Realizar
pruebas a
profundidad en
cada módulo.
R-035 AMENAZA Capacitación ALTO MITIGAR SCRUM TEAM  Mantener
superficial a contacto
usuarios finales frecuente con
los usuarios
finales del
proyecto.
 Mostrar al
usuario los
alcances que
va teniendo la
aplicación.


RIESGO RIESGO
R-037 AMENAZA Fallas del ALTO MITIGAR SCRUM MASTER  Emplear los
hardware limitan SCRUM TEAM equipos
la funcionalidad tecnológicos
del software necesarios
para el
desarrollo del
software.
 Establecer
desde un
inicio los
requerimientos
tecnológicos.
R-038 AMENAZA Arquitectura ALTO MITIGAR SCRUM TEAM  Evaluar la
inadecuada por viabilidad de
parte del cliente cada uno de
los
requerimientos
que tiene el
cliente.
 Plantear o
sugerir
mejoras en los
requerimientos
del usuario.
R-040 AMENAZA Vulnerabilidades ALTO MITIGAR SCRUM TEAM  Establecer los
del software requerimientos
presentadas en del software
producción. desde un
inicio del
desarrollo.
 Evaluar
continuamente
cada módulo
no funcional
desarrollado.
R-041 AMENAZA Resistencia del ALTO MITIGAR SCRUM TEAM  Capacitar al

personal para personal de los
cambiar las aspectos o
prácticas del temáticas
pasado requeridos
para el
desarrollo del
proyecto.
9.3.1.1 Conclusión del análisis de riesgos.
De acuerdo con lo anterior, se pueden definir los márgenes porcentualmente que
representan cada nivel de los riesgos identificados durante la realización del presente
proyecto, estos se encuentran distribuidos de la siguiente manera:
Los riesgos con nivel ALTO son representados por un 34,88%, a dichos riesgos se les
desarrolló el plan de contingencia ya enseñado anteriormente con el fin de evitarlos o
mitigarlos, por otra parte, los riesgos con un nivel MEDIO contienen un porcentaje del
37,21% los cuales pueden ser controlados por el equipo de trabajo para que no afecte durante
el desarrollo y ejecución del proyecto. Finalmente encontramos los riesgos con un nivel
BAJO con un 27,91% que son aceptados por el equipo de trabajo y corregidos durante el
desarrollo del proyecto.
Es así como se determina que la mayor cantidad de riegos se presentan en el nivel MEDIO
lo cual permite su control oportuno por el equipo de trabajo.
9.4 ESTUDIO DE FACTIBILIDAD
Para el desarrollo de cualquier software es indispensable generar los estudios de
factibilidad al iniciar la etapa de planeación del proyecto, pues el análisis de cada uno de los
estudios le permitirán el equipo de trabajo corregir a tiempo los incidentes de tipo operativo,
legal, técnico y económico.
A continuación, se describe el análisis de cada uno de los aspectos realizados por el grupo
de trabajo obteniendo como resultado una factibilidad del 100 % para la puesta en marchas y
desarrollo del proyecto.
Factibilidad operativa. Esta factibilidad determina el componente de recurso humado
disponible y capacidades para el desarrollo del proyecto y se debe dar respuesta a los
siguientes interrogantes que permitirán establecer una mayor viabilidad para el grupo de
trabajo.
¿Los integrantes del equipo de trabajo cuentan con los conocimientos y capacidades para
el desarrollo de software?
¿El equipo de trabajo cuenta con las herramientas necesarias para el desarrollo del
proyecto?
¿El software será agradable y de fácil manejo para el usuario?
Se dan respuesta a cada uno de estos interrogantes por parte del grupo de trabajo y se
concluye que el proyecto presenta factibilidad operativa en un 100%, ya que cuenta con un
recurso humano responsable y comprometido con el desarrollo del proyecto.
Además, se cuenta con el apoyo de la representante legal de la empresa plásticos y
desechables Libia, quien es la encargada de la administración de la empresa, la cual posee
disponibilidad y buena actitud para llevar a buen término el desarrollo del software que dará
solución a la problemática presentada dentro de la empresa.
Factibilidad legal. Para el desarrollo e implementación del proyecto COIN se contempló
las normas, leyes y estatutos vigentes que regulan la venta de productos y servicios ya sean
para las Mypimes o grandes empresas las cuales están descritas en el capítulo del marco legal
del proyecto.
El desarrollo del software COIN permitirá realizar el cobro de los impuestos sobre el valor
agregado del producto lo cual se conoce como IVA. El diseño de la factura cumple con todos
los requisitos exigidos por la Dirección Nacional de Impuesto y Aduanas DIAN.
Por otra parte, para el diseño y construcción del software COIN se están utilizando
herramientas de desarrollo de uso libre, lo cual no implican compra de licenciamiento.
Teniendo así una factibilidad de carácter legal del 100%.
Factibilidad de tiempo. Se presenta una factibilidad de tiempo en el proyecto ya que se
establece en grupo de trabajo un cronograma de actividades teniendo en cuanta cada una de
las fases de la metodología de desarrollo SCRUM, en donde se plantea las actividades en

cada una de las fases asignándose responsabilidades y funciones para el cumplimento y
construcción del producto.
El proyecto tiene una duración de doce meses (12) con fecha de inicio 12 de febrero de
2018 a 03 de febrero de 2019. Esta decisión se tomó ya que durante el desarrollo del software
se presentaron algunos inconvenientes, lo cual implico ampliar el plazo establecido para la
culminación del proyecto. (Ver Tabla 1 Cronograma de actividades).

Tabla 22. Cronograma de actividades proyecto COIN
CRONOGRAMA DE ACTIVIDADES "COIN"
N° Actividades Fecha Inicio Fecha Final Responsables

1. FASE 1. ANÁLISIS DE REQUISITOS
Cristian Oswaldo Lozada Tovar, Luis R.
Realización de entrevista al gerente de la
1.1 12/02/218 17/02/2018 Ramírez Liévano, Alejandra Romero Ruiz
empresa Plásticos LIBIA
Guzmán, Libia Rosa Ruiz
Análisis de cada uno de los procesos de al
Plásticos LIBIA a sistematizar
Recopilación de inventarios de productos del
Plásticos Libia
Planteamiento de las posibles soluciones del
cliente
Establecer alcances y limitaciones de Ramírez Liévano, Alejandra Romero Ruiz,
1.5 24/02/2018 27/02/2018
proyecto José Alexander Aguilar González, Soraya
Jiménez Montaña, Melissa Rivera Guzmán
Realizar búsqueda de software de Alejandra Romero Ruiz Guzmán, Luis R.
1.6 facturación e inventarios para conocer su 17/02/2018 19/02/2018 Ramírez Liévano Y Nayibe Sánchez León
funcionamiento
Establecer recursos tecnológicos para el
1.7 26/02/2018 27/02/2018 Ramírez Liévano, Alejandra Romero Ruiz,
desarrollo del proyecto
Elaborar ficha de propuesta de grado Y
Monografía
2. FASE 2. GESTIÓN DE BACKLOG
2.1 Generar estudios de factibilidad del proyecto 5/03/2018 9/03/2018 Ramírez Liévano, Alejandra Romero Ruiz,
Realizar requerimientos funcionales y no Ramírez Liévano, Alejandra Romero Ruiz,
2.2 12/03/2018 13/03/2018
funcionales José Alexander Aguilar González, Melissa
Rivera Guzmán Y Nayibe Sánchez León
Ramírez Liévano, Alejandra Romero Ruiz,
2.3 Establecer presupuesto general del proyecto 14/03/2018 16/03/2018
José Alexander Aguilar González, Melissa
Rivera Guzmán
Generar matriz de riesgos de cada una de las Ramírez Liévano, Alejandra Romero Ruiz,
2.4 20/03/2018 21/03/2018
fases del proyecto José Alexander Aguilar González, Melissa
3. FASE 3. SPRINT PLANNING MEETING.
Planificación de los sprint y selección de Ramírez Liévano, Alejandra Romero Ruiz,
3.1 22/03/2018 28/03/2018
prioridades José Alexander Aguilar González, Melissa
Rivera Guzmán, Libia Rosa Ruiz
Generación Sprint 1 Determinación de Ramírez Liévano, Alejandra Romero Ruiz,
3.2 22/03/2018 28/03/2018
premisas de "COIN" José Alexander Aguilar González, Melissa
Generación Sprint 2 Determinación de base
de datos de COIN
Rivera Guzmán, Libia Rosa Ruiz Y Nayibe
Sánchez León
Generación Sprint 3 Diseño y desarrollo de Ramírez Liévano, Alejandra Romero Ruiz,
3.4 22/03/2018 28/03/2018
módulos de COIN José Alexander Aguilar González, Melissa
4. FASE 4. EJECUCIÓN DE SPRINT
4.1 Sprint 1 Determinación de premisas de "COIN"
4.1.1 Determinación de lenguaje de programación 2/04/2018 3/04/2018
Rivera Guzmán
Determinación y definición de módulos de Ramírez Liévano, Alejandra Romero Ruiz,
4.1.2 4/04/2018 5/04/2018
COIN José Alexander Aguilar González, Melissa
Alejandra Romero Ruiz, José Alexander
4.1.3 Establecer colores y diseños para COIN 9/04/2018 10/04/2018 Aguilar González, Melissa Rivera Guzmán,
Libia Rosa Ruiz Y Nayibe Sánchez León
4.2 Sprint 2 Determinación de base de datos de COIN
Determinación de finalidades de la base de
4.2.1 11/04/2018 12/04/2018 Ramírez Liévano, Alejandra Romero Ruiz,
datos
Determinar tablas y campos de la base de
4.2.2 13/04/2018 16/04/2018 Ramírez Liévano, Alejandra Romero Ruiz,
datos.
Diseñar el modelo con la técnica Modelo Ramírez Liévano, Alejandra Romero Ruiz,
4.2.3 17/04/2018 19/04/2018
Entidad Relación José Alexander Aguilar González Y Nayibe
Sánchez León
4.2.4 Crear base de datos en SGBD MySQL 19/04/2018 20/04/2018 Ramírez Liévano, Alejandra Romero Ruiz,
4.2.5 Ingresar datos a la BD por medio del SGBD 23/04/2018 28/04/2018 Ramírez Liévano, Alejandra Romero Ruiz,
4.3 Sprint 3 Diseño y desarrollo de módulos de COIN
4.3.1 Diseño de interfaz gráfica de COIN 30/04/2018 4/05/2018 Ramírez Liévano, Alejandra Romero Ruiz
Desarrollo de Modulo de Devoluciones, Cristian Oswaldo Lozada Tovar, Luis R.

4.3.2 7/05/2018 8/06/2018 Ramírez Liévano, Alejandra Romero Ruiz
reportes, y tablas Maestras
Desarrollo de Modulo de Login resumen del Cristian Oswaldo Lozada Tovar, Luis R.
día y estadística, Usuarios.
4.3.4 Desarrollo de Módulos Almacén, Compra 1/08/2018 14/09/2018 Ramírez Liévano, Alejandra Romero Ruiz
Desarrollo de Modulo de Ventas, Pago a Cristian Oswaldo Lozada Tovar, Luis R.
cartera
5. FASE 5. INSPECCIÓN E ITERACIÓN
5.1 Realización de pruebas de validación 26/10/2018 31/10/2018
Realización de ajustes según resultados de Cristian Oswaldo Lozada Tovar, Luis R.
validación
Realización de pruebas de satisfacción del Ramírez Liévano, Alejandra Romero Ruiz,
5.3 17/12/2018 07/01/2018
cliente José Alexander Aguilar González, Melissa
Implementación de software COIN en Cristian Oswaldo Lozada Tovar, Luis R.
empresa LIBIA
Entrega de Monografía del desarrollo de Cristian Oswaldo Lozada Tovar, Luis R.
producto COIN
Factibilidad técnica. Para establecer la factibilidad técnica del proyecto se hace
necesario el análisis de los recursos tecnológicos de hardware y software con lo que cuenta el
grupo de trabajo para el óptimo desarrollo del producto COIN. De igual manera se hace
indispensable que del lado de nuestro Product Owner conocido como cliente cuente con los
recursos técnicos para le implementación y operatividad del software.
A continuación, se describen los recursos de Hardware con los que cuenta el equipo
desarrollador.
Tabla 23 Recursos Tecnológicos para el desarrollo de COIN
EQUIPO CANTIDAD
Computador de escritorio (procesador Intel I7 3770K 3.5

GHZ, memoria RAM DD3 8 Gigas, Disco duro 2TB) para
labores de programación. 1
Portátil Toshiba de 14" 6GB 1TB | L45-C4206S

Modelo L45-C4206S.Procesador Intel CORE i5-
5200U.Memoria RAM de 6GB.Disco duro de 1TB. 1
Gráficos Mobile Intel HD con memoria gráfica compartida.
Pantalla TFT de 14 pulgadas con resolución HD.Sistema
operativo Windows 8.1.
3 puertos USB y Bluetooth incorporado
Computador portátil (procesador AMD E-300 APU 1.30

GHZ, memoria RAM DD3 8 Gigas, Disco duro de 250 gigas)
para realizar documentos, presentar adelantos del software en 1
las diferentes exposiciones.
Computador portátil DELL (procesador Intel CORE i3

2.00Ghz, memoria 6 Gigas, Disco duro de 1 Tera) para
realizar documentos, presentar adelantos del software en las 1
diferentes exposiciones.
Impresora EPSON l220 para imprimir y escanear documentos

1
A continuación, se describen los recursos de Software necesarios para el desarrollo del
producto COIN.
Ilustración 6. Recursos de Software necesarios para el desarrollo del producto COIN.

Lenguaje de marcado usado Lenguaje utilizado Biblioteca multiplataforma
para el desarrollo del sitio y principalmente para la creación de usada para la creación de
aplicativo web, componentes animaciones y elementos visuales componentes animados,
visuales, estructuras, etc. atractivos para el usuario, desplegables, botones y elementos
notificaciones etc. necesarios para el framework
usado.
Editor de texto gratuito usado Software de creación y edición Lenguaje de programación
como apoyo en el desarrollo, de elementos visuales, usado para la Back-end usado para dar
también para realizar backups de los maquetación de ideas, diseño de funcionalidad a todos los
scripts en desarrollo, gracias a su componentes antes de pasarlos a componentes del aplicativo.
robusto desempeño. código.
Herramienta usada para la Software de creación de bases Servidor web multiplataforma
administración, edición y de datos y diagramas entidad usado para la visualización del
visualización de la base de datos relación, usado en la prueba y aplicativo de forma local gracias a
usada en el desarrollo del aplicativo, diseño de la base de datos actual. su compatibilidad con php y bases
brindado por el host elegido. de datos.
Ilustración 7. Recursos de Software necesarios para el desarrollo del producto COIN.
Factibilidad económica: El proyecto presenta una factibilidad teniendo en cuenta el
presupuesto total del desarrollo del proyecto y los beneficios que se dará después de su
implementación.
Para el desarrollo del siguiente proyecto es necesario de los siguientes recursos y costos
del software.
Tabla 24 Descripción y cuantificación de los equipos de uso propio (en miles de $).
EQUIPO CONTRAPARTIDA
(ALUMNOS) TOTAL
Especie
Computador de escritorio (procesador
Intel I7 3770K 3.5 GHZ, memoria RAM
DD3 8 Gigas, Disco duro 2TB) para 1 $ 1.200.000 c/u
labores de programación.
Portátil Toshiba de 14" 6GB 1TB | L45-
C4206S Modelo L45-
C4206S.Procesador Intel CORE i5- 1 $ 1.650.000 c/u
5200U.Memoria RAM de 6GB.
Disco duro de 1TB.Gráficos Mobile
Intel HD con memoria gráfica
compartida. Pantalla TFT de 14 pulgadas
con resolución HD. Sistema operativo
Windows 8.1.3 puertos USB y Bluetooth
incorporado
Computador portátil (procesador AMD

E-300 APU 1.30 GHZ, memoria RAM
DD3 8 Gigas, Disco duro de 250 gigas) 1 $ 1.250.000 c/u
para realizar documentos, presentar
adelantos del software en las diferentes
exposiciones.
Computador portátil DELL (procesador
Intel CORE i3 2.00Ghz, memoria 6
Gigas, Disco duro de 1 Tera) para 1 $ 1.050.000 c/u
realizar documentos, presentar adelantos
del software en las diferentes
exposiciones.
Impresora EPSON l220 para imprimir y
escanear documentos 1 $ 480.000 c/u
TOTAL $
5.630.000.oo
Tabla 25. Papelería y útiles de escritorio (en miles de $)
PAPELERÍA Y ÚTILES DE
ESCRITORIO JUSTIFICACIÓN TOTAL
Resmas de Hojas Carta Para los Documentos $ 30.000

Cartuchos B/N Para los Documentos $ 480.000
Inscripciones a eventos $500.000
nacionales e internacionales
PAPELERÍA Y ÚTILES DE
ESCRITORIO JUSTIFICACIÓN TOTAL
Hospedaje, transporte y Para los gastos propios de los $2.000.000

alimentación para encuentros y ponentes en los encuentros o
congresos de TIC congresos de TIC.
Hosting, Dominio y Bases de Para el almacenamiento de la $360.000
datos información y acceso a la base
de datos del App.
Servicio Internet Consultas Bibliográficas y $ 250.000
Emails
Carpetas Blancas Para los Documentos $ 5.000
Carpetas Azules Oficio Para los Documentos $ 9.000
CDs Entrega de Memorias del $ 25.000
Proyecto
Memorias USB Presentación de la Ponencia $ 60.000
Empastada Trabajos Para la Monografía $ 100.000
TOTAL $3.819.000.oo
Tabla 26. Gastos de Transporte, Alimentación y otros.
GASTOS DE TRANSPORTE, JUSTIFICACIÓN TOTAL

ALIEMENTACION Y OTROS
Transporte espinal -agua de dios – Viajes para levantamiento de $200.000
espinal requerimientos
Alimentación Alimentación para el Scrum $200.000
Team
Otros Gastos de servicio público de $350.000

energía e imprevistos
TOTAL $750.000
Tabla 27 Costo del grupo de producción tecnológica. (En miles de $)
Nombre del Formación Capacitació Duración RECURSOS TOTAL

experto/ Académica n a realizar (Días) Contrapartida
auxiliar Efectivo Especie
Cristian Técnicos Programa 120 $900.000 $
Oswaldo en ción en 10.800.000
Lozada Soluciones HTML 5,
Tovar Web JavaScript,
Mysql, CSS3
Nombre del Formación Capacitació Duración RECURSOS TOTAL
experto/ Académica n a realizar (Días) Contrapartida
auxiliar Efectivo Especie
Luis Ramón
Ramírez
Liévano.
Alejandra
Romero
Ruiz.
José Ingeniero de Dirección de 120 $0 $1.500.0 $6.000.0
Alexander Sistemas Proyectos de 00 00
Aguilar Software y
González Analista de
Sistemas
Soraya Licenciada Redacción 120 $0 $2.800.0 $11.200.
Jiménez en español e documentos, 00 000
Montaña Ingles traducción
TOTAL $
28.000.000
El presupuesto total para el desarrollo de este proyecto es de $ 38.199.000.oo, el cual está
discriminado de la siguiente manera:
Recursos de equipos y Papelería y Útiles De Escritorio $ 9.449.000.oo
Grupo De Producción Tecnológica del software $ 28.000.000.oo
Gastos de transporte, alimentación y otros $ 750.000.oo
Plásticos y desechables Libia, tendrá como benéficos, la reducción de costos en papelería
para la administración de inventarios de igual manera un beneficio intangible como lo es la
reducción de tiempo en la realización de facturas y en la realización de inventarios.
9.5 Alcances y limitaciones del proyecto
En el siguiente capítulo se determinó el alcance del proyecto estableciendo y detallando
los requerimientos funcionales del sistema de información de control de ventas e inventarios
a desarrollarse, denominado “COIN”, dirigido a la empresa “Plásticos y desechables LIBIA”

ubicada en la ciudad de Agua de Dios, Cundinamarca. De igual manera se describe los
requerimientos no funcionales y limitaciones del proyecto.
9.5.1 Alcance del proyecto COIN.
Los alcances del sistema están determinados por los requerimientos funcionales, donde se
realizó la descripción de cada uno de los módulos que comprenderán el software COIN.
9.5.2 Requerimientos funcionales.
Requerimientos funcionales Modulo “Administrador”. Manipulación de datos
Requerimiento 1 - Creación de empleados (RFA001)
El usuario que se logue al sistema bajo el rol de “Administrador”, podrá crear nuevos
usuarios, es decir “Empleados” ingresando todos los datos correspondientes, la contraseña
por defecto del empleado será el número de documento registrado, el cual posteriormente el
usuario podrá cambiar.
 Actividad realizada: Inserción de nuevo registro
 Entidad(es) afectada(as): Empleado
 Rol: Administrador
 Módulo interfaz: “Acceso/Usuarios/Añadir Usuario”
Requerimiento 2 - Creación de proveedores (RFA002)
El usuario que se logue al sistema bajo el rol de “Administrador”, podrá añadir a la lista
nuevos proveedores siempre que sea necesario.
 Entidad(es) afectada(as): Proveedor
 Módulo interfaz: “Compras/Proveedores/Añadir Proveedor”

Requerimiento 3 - Creación de clientes (RFA003)
El usuario que se logue al sistema bajo el rol de “Administrador”, podrá añadir a la lista
nuevos clientes siempre que sea necesario.
 Entidad(es) afectada(as): Cliente
 Módulo interfaz: “Ventas/Clientes/Nuevo Cliente”
Requerimiento 4 – Actualización de perfil (RFA004)
El usuario que se logue al sistema bajo el rol de “Administrador”, tendrá la posibilidad de
actualizar o cambiar datos sus datos de usuario, como la foto de perfil, dirección, teléfono,
correo electrónico y contraseña. así como de las personas relacionadas al sistema de
información, es decir Clientes y Proveedores.
 Actividad realizada: Actualización de registro
 Entidad(es) afectada(as): Empleado, Proveedor, Usuarios
 Módulo interfaz: “Compras/Proveedores/Editar Proveedor”,
 “Acceso/Usuarios/Editar Usuario”
Requerimiento 5 – Creación de nuevos artículos (RFA005)
El usuario que se logue al sistema bajo el rol de “Administrador”, podrá añadir nuevos
artículos que se decida empezar a vender en la empresa.
 Entidad(es) afectada(as): Artículos
 Módulo interfaz: “Almacén/Artículos/Añadir articulo/s”.

Requerimiento 6 – Actualización de Artículos (RFA006)
actualizar los datos referidos a los artículos o productos controlados por el sistema de
información.
 Entidad(es) afectada(as): Artículos
 Módulo interfaz: “Almacén/Artículos/Editar articulo/s”.
Requerimiento 7 – Crear Categorías (RFA007)
crear categorías, las cuales son necesarias para registrar nuevos artículos en el sistema.
 Entidad(es) afectada(as): Categoría
 Módulo interfaz: “Almacén/Categorías/Nueva Categoría”.
Requerimiento 8 – Crear Marcas (RFA008)
crear marcas, las cuales son necesarias para registrar nuevos artículos en el sistema.
 Entidad(es) afectada(as): Marca
 Módulo interfaz: “Almacén/Marcas/Nueva Marca”.
Requerimiento 9 – Registrar inventario (RFA009)
registrar la entrada de productos al inventario de artículos en el sistema.

 Entidad(es) afectada(as): Inventario, detalle inventario
 Módulo interfaz: “Compras/Entradas/Nueva Entrada”.
Requerimiento 10 – Realizar ventas (RFA010)
realizar venta de artículos en el sistema.
 Entidad(es) afectada(as): Inventario, detalle inventario, factura, detalle factura
Módulo interfaz: “Ventas/Nueva Venta”
Requerimiento 11 – Realizar Fianzas (RFA011)
realizar fianzas al momento de realizar una venta de artículos en el sistema.
 Entidad(es) afectada(as): Deuda
Requerimiento 12 – Realizar Pagos de Fianzas (RFA012)
realizar pagos de las fianzas en el sistema.
 Entidad(es) afectada(as): Deuda, Pagos
Módulo interfaz: “Pagos y Cartera/Fianzas/Abonar”

Requerimiento 13 – Realizar Devoluciones (RFA013)
El usuario que valide el ingreso al sistema bajo el rol de “Administrador”, tendrá la
posibilidad de realizar devoluciones en el sistema.
 Entidad(es) afectada(as): Devolución, movimiento devolución
Módulo interfaz: “Devoluciones/Por Cliente/Nueva Devolución”
Requerimiento 14 – Registrar País (RFA014)
registrar, actualizar y listar la tabla maestra de país en el sistema.
 Entidad(es) afectada(as): País
Módulo interfaz: “Tablas Maestras/País”
Requerimiento 15 – Registrar Departamento (RFA015)
registrar, actualizar y listar la tabla maestra de Departamento en el sistema.
 Entidad(es) afectada(as): Departamento
Módulo interfaz: “Tablas Maestras/Departamento”
Requerimiento 16 – Registrar Municipio (RFA016)
registrar, actualizar y listar la tabla maestra de Municipio en el sistema.

 Entidad(es) afectada(as): Municipio
Módulo interfaz: “Tablas Maestras/Municipio”
Requerimiento 17 – Registrar Tipo de Documento (RFA017)
registrar, actualizar y listar la tabla maestra de Documento en el sistema.
 Entidad(es) afectada(as): Documento
Módulo interfaz: “Tablas Maestras/Documento”
Requerimiento 18 – Registrar tipo de Teléfono (RFA018)
registrar, actualizar y listar la tabla maestra de Teléfono en el sistema.
 Entidad(es) afectada(as): Teléfono
Módulo interfaz: “Tablas Maestras/Teléfono”
Requerimiento 19 – Registrar Cargos (RFA019)
registrar, actualizar y listar la tabla maestra de Cargo en el sistema.
 Entidad(es) afectada(as): Cargo
Módulo interfaz: “Tablas Maestras/Cargo”

Requerimientos de tipo Consultas del Administrador
Requerimiento 20 – Informe general de artículos (RFA020)
generar un informe donde visualice la lista completa de los artículos que posee el sistema
hasta la fecha.
 Actividad realizada: Consulta
 Entidad(es) involucrada(as): Artículos, inventario, detalle inventario
 Módulo interfaz: “Reportes/Reporte Kardex”
Requerimiento 21 – Informe individual de artículos (RFA021)
generar un informe detallado e individual de un producto dentro del sistema de información.
 Entidad(es) involucrada(as): Artículos, inventario, detalle inventario
 Módulo interfaz: “Reportes/Reporte Kardex”
Requerimiento 22 – Informe general proveedores (RFA022)
generar un informe general en forma de listado de los proveedores vinculados al sistema de
información.
 Entidad(es) involucrada(as): Proveedores
 Módulo interfaz: “Reportes/Reportes Proveedores”.

Requerimiento 23 – Informe individual proveedores (RFA023)
visualizar un informe individual y detallado de los proveedores vinculados al sistema de
información.
 Entidad(es) involucrada(as): Proveedores
 Módulo interfaz: “Reportes/Reportes Proveedores - detalles”.
Requerimiento 24 – Informe general clientes (RFA024)
generar un informe general y detallado de los clientes vinculados al sistema de información.
 Entidad(es) involucrada(as): Cliente
 Módulo interfaz: “Reportes/Reportes Clientes”.
Requerimiento 25 – Historial de compras clientes (RFA025)
visualizar un historial de las compras realizadas por los clientes vinculados al sistema de
información.
 Entidad(es) involucrada(as): Cliente, factura
 Módulo interfaz: “Reportes/Reportes Clientes opción detalles”.
Requerimientos funcionales complementarios del sistema administrador
Requerimiento 26 – Resumen del día (RFC026)

El sistema tendrá la capacidad de generar un resumen diario que se podrá visualizar en la
interfaz de inicio, una vez el usuario inicie la sesión, en este podrá observar la siguiente
información así: Valor efectuado en compras (producto para inventario), valor efectuado en
ventas, valor ganancias, el articulo mas vendido, el articulo por agotarse y el valor efectuado
en créditos o fianzas a los clientes.
 Actividad realizada: Ejecución
 Entidad(es) involucrada(as): inventario, detalle inventario, facturas, detalle factura,
fianzas, pagos, deuda y devoluciones
 Módulo interfaz: “Resumen del día acoplado a interfaz de inicio, luego del inicio de
sesión”.
Requerimientos funcionales Modulo Rol “Empleado”. Manipulación de datos.
Requerimiento 27 – Realizar ventas (RFA027)
El usuario que se logue al sistema bajo el rol de “Empleado”, tendrá la posibilidad de
realizar venta de artículos en el sistema.
 Entidad(es) afectada(as): Inventario, detalle inventario, factura, detalle factura
 Rol: Empleado
Requerimiento 28 - Creación de clientes (RFA028)
El usuario que se logue al sistema bajo el rol de “Empleado”, podrá añadir a la lista
nuevos clientes siempre que sea necesario.
 Entidad(es) afectada(as): Cliente
 Rol: Empleado
 Módulo interfaz: “Ventas/Clientes/Nuevo Cliente”
Requerimiento 29 – Realizar Fianzas (RFA029)
realizar fianzas al momento de realizar una venta de artículos en el sistema.
 Entidad(es) afectada(as): Deuda
 Rol: Empleado
Requerimiento 30 – Realizar Pagos de Fianzas (RFA030)
realizar pagos de las fianzas en el sistema.
 Entidad(es) afectada(as): Deuda, Pagos
 Rol: Empleado
Módulo interfaz: “Pagos y Cartera/Fianzas/Abonar”
Requerimiento 31 – Realizar Devoluciones (RFA031)
realizar devoluciones en el sistema.
 Entidad(es) afectada(as): Devolución, movimiento devolución
 Rol: Empleado
Módulo interfaz: “Devoluciones/Por Cliente/Nueva Devolución”
Requerimiento 32 – Actualización de perfil (RFA032)

El usuario que inicie sesión al sistema bajo el rol de “Empleado”, tendrá la posibilidad de
actualizar o cambiar datos sus datos de usuario, como la foto de perfil, dirección, teléfono,
correo electrónico y contraseña. Así como de los clientes.
 Entidad(es) afectada(as): Empleado, Proveedor, Usuarios
 Rol: Empleado
 Módulo interfaz: “Compras/Proveedores/Editar Proveedor”,
 “Acceso/Usuarios/Editar Usuario”
Requerimientos funcionales complementarios del sistema administrador
Requerimiento 33 – Resumen del día (RFC033)
El sistema tendrá la capacidad de generar un resumen diario que se podrá visualizar en la
interfaz de inicio, una vez el usuario inicie la sesión, en este podrá observar la siguiente
información así: Valor efectuado en compras (producto para inventario), valor efectuado en
ventas, valor ganancias, el articulo más vendido, el articulo por agotarse y el valor efectuado
en créditos o fianzas a los clientes.
 Actividad realizada: Ejecución
 Entidad(es) involucrada(as): inventario, detalle inventario, facturas, detalle factura,
fianzas, pagos, deuda y devoluciones
 Rol: Empleado
 Módulo interfaz: “Resumen del día acoplado a interfaz de inicio, luego del inicio de
sesión”.
9.5.2.1 Requerimientos no funcionales
Se definen los requerimientos no funcionales manifiestos a las características externas que
necesitan o afectan la calidad del servicio, pero no el funcionamiento del sistema en cuanto a
la respuesta en el tiempo y la capacidad de almacenamiento. A continuación, se describe los
requerimientos No funcionales para la aplicación COIN:
a) Su visualización se limita a versiones Superiores de los navegadores web Internet
Explorer 8 Google Chrome 16 Safari 5.1 y ópera 11.60
b) La disponibilidad del aplicativo depende el Hosting en el que se alojé
c) El rendimiento del aplicativo depende de las características del Hardware y el
software del equipo donde se ejecute
d) Puesto que está programado en web funciona en cualquier sistema operativo, eso lo
hace multiplataforma
e) Proporciona un contenido de fácil comprensión e interpretación lo que lo hace
totalmente usable
9.5.2.2 Limitaciones
Si bien en Colombia se habla de facturas digitales o electrónicas con la expedición del
decreto 2242 en el 2015 y las fechas que se definieron con la Reforma Tributaria en
diciembre del 2016 como mecanismo de anti-evasión. Según el artículo del diario el
tiempo todas las empresas declaradas por la DIAN como grandes contribuyentes están
obligadas a implementar la Factura Electrónica como única forma de registro contable en
sus transacciones. Teniendo en cuenta lo anterior y la naturaleza de Desechables y
plásticos Libia, el proyecto COIN presenta las siguientes limitaciones:
 No realiza conexiones para reportes de facturación a la DIAN.
 Para la implementación de software se requiere adquirir un hosting y dominio, donde
se almacenará la aplicación y la base de datos para poder acceder desde cualquier
dispositivo con acceso a internet.
 El adquirir el servidor será responsabilidad del cliente, así como la administración y
mantenimiento de la base de datos.

 Se quiere de acceso a internet para el cumplimiento de cada una de las funciones que
requiere realizar.
10 PLANEACIÓN Y GESTIÓN DEL PROYECTO
10.1 MODELO CONCEPTUAL DE DATOS
A continuación se describe la concepción del diseño del modelo de la base de datos,
modelo entidad relación para la base de datos que poseerá el software, el modelo se
presentará dividido en dos (2) partes para una mejor comprensión y apreciación debido a su
tamaño, la primera de estas, deja ver las entidades más importantes dentro de la estructura de
la base de datos, es decir, todas aquellas que almacenan información de personas, que a su
vez forman parte esencial del sistema de información actual (Ver ilustración 1ER), el
siguiente gráfico muestra las demás entidades y relaciones que contiene el modelo propuesto,
estas serán las encargadas de almacenar los datos que poseen un movimiento mayor, tales
como la factura, las compras a proveedores, las devoluciones, etc.(ver ilustración 2ER).
Ilustración 8. ER, Modelo entidad relación.
10.2 MODELO RELACIONAL
El modelo relacional para la estructura de base de datos que poseerá el sistema de

facturación y control de inventarios denominado COIN.
Ilustración 9. Modelo relacional base datos COIN.
10.3 DICCIONARIO DE DATOS PROYECTO COIN
En el siguiente apartado se encuentra la descripción de cada una de las tablas de la Base de
Datos de la aplicación COIN, la cual permitirá obtener una mayor comprensión de la
estructura, tablas, atributos y valores.

Tabla 28 Diccionario de datos tabla Cliente
Tabla cliente
ATRIBUTO DESCRIPCION TIPO PK NULL FK
numero_documento Número de varchar x
identificación del (30)
cliente
id_documento Identificación del int (3) x
tipo de documento
nombres Nombre del cliente varchar
(25)
apellidos Apellidos del varchar
cliente (25)
direccion Dirección del Varchar
cliente (100)
Tabla 29 Diccionario de datos tabla Proveedor
Tabla proveedor
numero_documento Número de varchar(30) x
identificación del
proveedor
id_documento identificador único int(3) x
del tipo de
documento
id_departamento identificador del int(3) x
departamento
id_municipio identificador del int(3) x
municipio
nombres Nombres del varchar(25)
proveedor
apellidos Apellidos del varchar(25)
proveedor
direccion Dirección del varchar(100)
proveedor
Tabla 30 Diccionario de datos tabla Tipo teléfono usuario
Tabla tipo_tel
id_tipo_tel Identificador único int(11) x
de la tabla tipo de
teléfono
id_telefono Identificador único int(11) x
del tipo del teléfono
cedula Identificador único varchar(30) x
del usuario al que
pertenece el
teléfono
numero_telefono número del teléfono char(20)
Tabla 31 Diccionario de datos tabla Documento
Tabla documento
id_documento identificador único int(3) x
del documento
tipo_documento nombre del tipo de varchar(40)
documento
Tabla 32 Diccionario de datos tabla cargo
Tabla cargo
id_cargo Identificador Único int (3) x
de cargo
nombre_cargo Nombre del cargo varchar (40)
Tabla 33. Diccionario de datos tabla Departamento
Tabla departamento
id_departamento Identificador del int (3) x
departamento
id_pais identificador del int (3) x
país
nombre_departamento Nombre del varchar
departamento (20)
Tabla 34 Diccionario de datos tabla municipio
Tabla municipio
id_municipio Identificador único int (3) x
de municipio
id_departamento Identificador único int (3) x
de departamento
nombre_municipi Nombre del varchar (20)
o municipio
Tabla 35 Diccionario de datos tabla pagos
Tabla pagos
id_pagos identificador único del Int (11) x

pago
id_deuda identificador único de Int (11) x
la deuda
fecha_pago fecha del sistema en la datetime
cual realiza el pago
valor valor pagado Double
(255,2)
Tabla 36. Diccionario de datos tabla país
Tabla pais
id_pais Identificador único int (3) x
del país
nombre_pais Nombre del país varchar (20)
Tabla 37 Diccionario de datos tabla categoría
Tabla categoria
id_categoria Identificador Único int(11) x
de Categoría
nombre_categoria Nombre de la varchar (40)
categoría del producto
Tabla 38. Diccionario de datos tabla Inventario
Tabla inventario
numero_factura Número de la factura bigint(20) x
numero_documento número del varchar(30) x
documento del
proveedor
fecha_hora fecha y hora del datetime
ingreso de productos
al inventario
valor_total valor total del double(255,2)
ingreso de productos
al inventario
Tabla 39 Diccionario de datos tabla Artículos
Tabla articulo
id_articulo Identificador Único int(11) X
del Articulo
id_marca identificador único de int(11) x
la Marca del Articulo
id_categoria Categoría del int(11) x
Articulo
nombre_articulo Nombre del Articulo varchar (100)
precio Precio del Articulo double(255,2)
Tabla 40 Diccionario de datos tabla Detalle de Inventario
Tabla detalle_inventario
id_detalle identificador único bigint(20) x
del detalle de
inventario
numero_factura identificador único bigint(20) x
del número de
factura
id_articulo identificador único int (11) x
del articulo
cantidad_entrada cantidad de artículos Varchar (100)
entrados
valor_entrada valor del total de los double(255,2)
artículos entrados
cantidad_salida cantidad de artículos Varchar (100)
salidos
valor_salida valor del total de los double(255,2)
artículos salidos
Tabla 41 Diccionario de datos tabla marca
Tabla marca
id_marca Identificador único de int(11) x
marca
nombre_marca Nombre de la marca varchar(40)
del producto
Tabla 42 Diccionario de datos tabla Factura
Tabla factura
id_factura identificador único Bigint (20) x
de la factura
numero_documento número del Varchar (30) x
documento del
cliente
cedula número del Varchar (30) x
documento del
vendedor
fecha_factura fecha de la factura datetime
total Total del valor de la Double
factura (255,2)
Tabla 43 Diccionario de datos tabla deuda
Tabla deuda
id_deuda identificador único de int (11) x
la deuda
id_factura identificador único de bigint(20) x
la factura
numero_cuotas numero de cuotas a varchar(20)
diferir la deuda
fecha_factura fecha de la factura datetime
valor_deuda valor total de la deuda double(255,2)
valor_diferir valor de la deuda a double(255,2)
diferir
Tabla 44 Diccionario de datos tabla Detalles de factura
Tabla datalle_factura
id_detalle Identificador Único bigint(20) x
del detalle del
producto
id_factura Identificador Único de bigint(20) x
la factura
id_articulo Identificador Único int (11) x
del articulo
cantidad Numero de cantidad Varchar (100)
del articulo
valor Valor del producto double(255,2)
Tabla 45 Diccionario de datos tabla Movimiento devolución
Tabla movimiento_devolución
id_movimiento identificador único int(11) x
del movimiento de las
devoluciones
id_devolucion identificador único de int(11) x
la devolución
id_articulo identificador único int(11) x
del articulo
cantidad cantidad de producto varchar(100)
regresado
valor valor de los productos double(255,2)
regresados
Tabla 46 Diccionario de datos tabla usuario
Tabla usuario
cedula identificador único varchar (30) x
del usuario
id_departamento identificador del int(3) x
departamento
id_municipio identificador del int(3) x
municipio
nombres Nombres del usuario varchar(25)
apellidos Apellidos del usuario varchar(25)
direccion Dirección del usuario varchar(100)
correo_electronico Correo Electrónico varchar(50)
del usuario
foto_perfil Foto Perfil del varchar(100)
usuario
contrasena Contraseña del longtext
usuario
Tabla 47 Diccionario de datos tabla vigencia usuario
Tabla vigencia_usuario
id_vigencia Identificador único de int (11) x
la vigencia del
usuario
Cedula numero de varchar (30) x
documento del
usuario
id_cargo identificador del int(3) x
cargo
Estado estado del usuario int(1)
activo o inactivo
Tabla 48 Diccionario de datos tabla Devoluciones
Tabla devolucion
id_devolucion identificador único int (11) x
de la devolución
id_factura identificador unido bigint(20) x
de la factura
fecha_devolucion fecha en que se datetime
realizó la devolución
observaciones observaciones acerca longtext
de la devolución
Total valor total de los double(255,2)
productos regresados
Tabla 49 Diccionario de datos tabla teléfono
Tabla teléfono
id_telefono identificador único Int (11) x
del teléfono
descripcion nombre del tipo de Varchar (40)
teléfono
10.4 FUNCIONAMIENTO DEL SOFTWARE COIN EXPLICADO A TRAVÉS DEL
LENGUAJE DE MODELADO UNIFICADO (UML).
El desarrollo de software su estructura y diseño deben de ser presentados atreves de
modelos que permitan su interpretación y desarrollo del software. Para (Pons , Giandini, &
Pérez, 2010) El Desarrollo de Software Dirigido por Modelos MDD (por sus siglas en
inglés: Model Driven software Development) se ha convertido en un nuevo paradigma de
desarrollo software. MDD promete mejorar el proceso de construcción de software basándose
en un proceso guiado por modelos.
El lenguaje unificado de procesos UML permite modelar, construir y documentar los
elementos que forman un sistema software orientado a objetos (Ferré Grau & Sánchez
Segura, 2008) pero se debe tener en cuenta que UML no define un proceso desarrollo en
específico tan solo es una notación para la estructura del sistema.
A continuación, se describe los diagramas de casos de usos y de secuencia bajo los cuales
se desarrolló el software COIN.

10.4.1.1 Diagramas de caso de uso del software COIN
Según (Ferré Grau & Sánchez Segura, 2008) define el diagrama de casos de usos como
“La relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que
ofrece el sistema en lo que se refiere a su interacción externa.” Este diagrama ayuda a
entender de manera fácil el comportamiento de un sistema su relación con el usuario y el
funcionamiento del software.
Estos diagramas se describen mediante actores o usuarios, los cuales realizaran las
acciones o funciones que se representan por medio de óvalos y sus acciones por medio de una
flecha. El primer diagrama de caso de uso, muestra las funciones generales que el aplicativo
web le permitirá realizar a cada usuario según el rol que desempeñe. El usuario con el rol de
“Administrador” podrá, registrar datos, editar, realizar pedidos, generar consultas, ver las
estadísticas y generar las copias de seguridad de la base de datos, para el rol de “Empleado”
están las funciones de editar algunos datos como los propios, realizar ventas, realizar los
abonos a las deudas de los clientes y generar algunas consultas.

Ilustración 10. Diagrama de caso de uso de COIN. Funciones Generales. Commented [JAVR1]: Registrar abonos, registrar….
Los siguientes diagramas buscan representar más específicamente cuales son las funciones
del rol “Administrador “, el administrador podrá crear o registrar nuevos usuarios y escoger el
rol que desempeñaran (administrador o empleado), también podrá crear proveedores, artículos
y clientes, a su vez tendrá la posibilidad de editar aquellos datos si estos cambian o quedaron
mal escritos.
Ilustración 11. Diagrama de caso de uso de COIN. Función Registrar del administrador.
Ilustración 12. Diagrama de caso de uso de COIN. Función editar del administrador.
Dentro de las consultas que podrá realizar el administrador están, listar o generar el reporte
de todos los usuarios registrados, reporte de los proveedores, artículos, clientes, ventas y la
búsqueda individual de los mismos por medio del nombre o ID.

Ilustración 13. Diagrama de caso de uso de COIN. Consultas del administrador.
Ilustración 14. Diagrama de caso de uso de COIN. Realizar pedidos.
El usuario administrador también podrá ver las estadísticas de las ventas, como el artículo
más vendido, el menos vendido, el cliente que más compra, etc., realizará pedidos y generará
las copias de seguridad de la base de datos.

Ilustración 15. Diagrama de caso de uso de COIN. Ver estadísticas.
Ilustración 16. Diagrama de caso de uso de COIN. Generar copias de seguridad.
Las funciones del empleado son mínimas pero importantes, el empleado es quien será el
encargado de realizar las ventas y registrar los abonos de dinero de los clientes que deben a la
empresa, tendrá la posibilidad de realizar sus propias consultas, generando el informe de los
clientes, artículos y fianzas de forma general e individualmente.

Ilustración 17. Diagrama de caso de uso de COIN. Función registrar del empleado.
Ilustración 18. Diagrama de caso de uso de COIN. Consultas del empleado.
10.4.1.2 Diagramas de secuencia del software COIN
Un diagrama de secuencia muestra cronológicamente como interactúa el software con el
usuario, allí se indican los módulos que formaran parte del programa y sus interacciones en el
tiempo representadas como mensajes dibujados con flechas, estos diagramas son buenos para
mostrar cómo se comunican los objetos entre sí y que mensaje se obtiene de esa
comunicación (Reyes et al., 2017).

En el siguiente apartado se explicarán las funciones principales de COIN graficando los
procesos por medio de diagramas de secuencia para una mejor comprensión.
El usuario con el rol de administrador tendrá el control sobre la creación de cualquier otro
usuario, sea otro administrador o un empleado, registrar artículos, proveedores, categorías y
clientes, habilitar o inhabilitar usuarios, clientes, artículos, categorías y proveedores,
modificar los datos de los usuarios, artículos, categorías, clientes, proveedores, generar los
reportes de los mismos, buscar individualmente cualquier reporte, realizar los pedidos a los
proveedores y hacer las copias de seguridad de la base de datos del software.
Mientras que las funciones del usuario empleado son, realizar el registro de las ventas, el
abono del dinero de los clientes deudores, generar el informe de los clientes, los artículos y
las fianzas general o individualmente.
Ilustración 19. Diagrama de secuencia de COIN. Registrar artículos.

Tabla 50 Tabla Descripción diagrama de secuencia de COIN. Registrar artículos
Nombre: Registrar Artículos
Función: Ilustrar la interacción entre los objetos del sistema de información.
Se muestra la función de registrar artículos que tiene el usuario
administrador, quien se debe ubicar en el módulo Almacén/Artículos

Descripción:
y al dar click en el botón "Añadir Articulo" para luego tener que
llenar un formulario con las características del artículo y guardar.
Ilustración 20. Diagrama de secuencia de COIN. Registrar categorías.
Tabla 51 Descripción diagrama de secuencia de COIN. Registrar categorías.
Nombre: Registrar Categorías
Descripción:
Nombre: Registrar Categorías
Se muestra la función de registrar categorías que tiene el usuario
administrador, quien se debe ubicar en el módulo
Almacén/Categorías y al dar click en el botón "Añadir Categoría”
para luego tener que llenar un formulario con el nombre de la
categoría y guardar.
Ilustración 21. Diagrama de secuencia de COIN. Registrar clientes.
Tabla 52 Descripción diagrama de secuencia de COIN. Registrar clientes.
Nombre: Registrar Clientes

Ilustrar la interacción entre los objetos del sistema de
Función:
información.
Nombre: Registrar Clientes
Se muestra la función de registrar clientes que tiene el usuario
administrador, quien se debe ubicar en el módulo
Ventas/Clientes y al dar click en el botón "Nuevo Cliente”

Descripción:
para luego tener que llenar un formulario con el nombre,
cedula, dirección y teléfono del mismo y guardar.
Ilustración 22. Diagrama de secuencia de COIN. Registrar proveedores .
Tabla 53 Diagrama de secuencia de COIN. Registrar proveedores.
Nombre: Registrar Proveedores

Función:
información.
Descripción:
Nombre: Registrar Proveedores
Se muestra la función de registrar proveedores que tiene el
usuario administrador, quien se debe ubicar en el módulo
Compras/Proveedores y al dar click en el botón "Nuevo
Proveedor” para luego tener que llenar un formulario con el
nombre de la empresa o proveedor, NIT y guardar.
Ilustración 23. Diagrama de secuencia de COIN. Registrar usuarios.
Tabla 54 Descripción diagrama de secuencia de COIN. Registrar usuarios.
Nombre: Registrar Usuarios
Descripción:
Nombre: Registrar Usuarios
Se muestra la función de registrar usuarios que tiene el usuario
administrador, quien se debe ubicar en el módulo Usuarios y al
dar click en el botón "Nuevo usuario" para luego tener que llenar
un formulario con los datos personales del nuevo usuario,
seleccionar su rol dentro de la empresa y guardar.
Ilustración 24. Diagrama de secuencia de COIN. Anular pedido.
Tabla 55 Descripción diagrama de secuencia de COIN. Anular pedido.
Nombre: Anular Pedidos

Función:
información.
Nombre: Anular Pedidos
El diagrama representa el proceso para anular un pedido, para
ello el usuario se debe ubicar en el módulo de
Compras/Pedidos, allí se desplegará un listado de los pedidos

Descripción:
realizados donde con el botón "Anular" podrá cancelar el
pedido.
Ilustración 25 Diagrama de secuencia de COIN. Buscar artículo.
Tabla 56 Descripción diagrama de secuencia de COIN. Buscar artículo.
Nombre: Buscar Articulo

Función:
información.
Descripción:
Nombre: Buscar Articulo
El diagrama representa el proceso para buscar un artículo, el
usuario debe situarse en el módulo de Reportes e ir a Artículos,
tendrá la opción de ver el informe general de los artículos,
descargar el informe, buscar un artículo en específico y ver los
detalles de cada uno.
Para buscar cualquier artículo deberá digitar el nombre o el
código del mismo y el software lo visualizarán.
Ilustración 26 Diagrama de secuencia de COIN. Generar copia de seguridad.
Tabla 57 Descripción diagrama de secuencia de COIN. Generar copia de seguridad.
Nombre: Copias de seguridad

Función:
información.
Descripción:
Nombre: Copias de seguridad
El diagrama representa el proceso para generar las copias de
seguridad, el usuario debe ir al módulo Seguridad y oprimir el
botón “Generar Backup", donde el software generara un
archivo .zip que se podrá descargar y guardar donde el
usuario lo desee.
Ilustración 27. Diagrama de secuencia de COIN. Generar reportes.
Tabla 58 Descripción diagrama de secuencia de COIN. Generar reportes.
Nombre: Generar Reportes

Función:
información.
Descripción:
Nombre: Generar Reportes
El diagrama representa el proceso para generar los reportes,
en el módulo Reportes el usuario encontrará la opción de
generar los reportes de los artículos, los proveedores, los
clientes, los pedidos y las ventas, usando la opción
"descargar" podrá guardar los reportes en formato .pdf.
Ilustración 28. Diagrama de secuencia de COIN. Devoluciones por cliente.
Tabla 59 Descripción diagrama de secuencia de COIN. Devoluciones por cliente.
Nombre: Devoluciones
Descripción:
Nombre: Devoluciones
Para realizar una devolución él usuario debe desplazarse al módulo
de devoluciones, allí debe elegir si es por cliente o por proveedor, a
continuación, debe pulsar el botón “Añadir devolución” y se
mostrara una nueva interfaz con un formulario, que el usuario
llenara con los datos de los artículos a devolver y las razones por
las que se hizo aquella devolución para luego guardar y dejar
registrada la devolución.

11 INTERFAZ GRÁFICA DE LA APLICACIÓN
En el presente capítulo se da a conocer cada uno de los parámetros de diseño, fuentes,
colores iconografía, del diseño de la interfaz gráfica de usuarios también conocidas con GUIs
las cuales son definidas por (Albornoz, Necco, & Montejano) “Es la parte de un programa
que maneja el flujo de datos producido durante el proceso de interacción entre el usuario y la
computadora”.
El diseño de las GIU para el software COIN está estructurado bajo las siguientes premisas:
Primero su diseño está desarrollado bajo la tendencia Material Design by Google la cual es
definida en el sitio oficial como: “un lenguaje visual que sintetiza los principios clásicos del
buen diseño con la innovación de la tecnología y la ciencia”. (Google, s.f.). Esta tendencia se
utiliza teniendo en cuenta que los diseños de Google han innovado en sus presentaciones de
GUI, posicionándose en el mercado tecnológico.
Segundo, el software COIN es un sistema que se adapta a cualquier tipo de pantalla y
resoluciones. Tercero, COIN está diseñado con ayudas, advertencias y mensajes de error
frente a cualquier acción que se ejecute en el sistema. Esto permite ser un software intuitivo y
de fácil manejo. Cuarto, todas sus acciones están cumpliendo con su objetivo establecido de
consultas, registros, actualizaciones, facturación y pagos.
11.1 ESTILO DE PROGRAMACIÓN
Para el desarrollo de COIN, el analista, investigador principal y los desarrolladores, se
determinó aplicar una combinación de paradigmas de programación (programación
multiparadigma). Esto se debió a la complejidad del problema y que la solución propuesta
debe llegar a la entrega de un software de alto nivel y calidad.
Con la aplicación de la programación multiparadigma (Ben-Gurion University of the
Negev, 2017), la construcción del software se hace por medio de la selección de los
paradigmas más convenientes para cada escenario. Se debe tener presente, que no es solo el
paradigma, sino la definición de un conjunto de conceptos, reglas semánticas, lenguajes de
programación y tecnologías que favorecieran la sistematización pensada para las empresas.
Por consiguiente, se trabajaron la programación imperativa y la orientada a objetos (ver
ilustración 10).
La combinación de estos dos paradigmas de programación: la imperativa y orientada a
objetos, ayudan a que cada subprograma tenga un paradigma diferente, logrando una
naturalidad y simpleza en la codificación. Actualmente, se puede trabajar con ambientes de
desarrollo que permiten la utilización de lenguaje de programación que disponen de librerías
que cumplen con funcionalidades muy específicas y que aportan un ahorro de tiempo en la
codificación.
COIN, es un producto que cumple con características como: Seguridad, calidad, eficiencia
y escalabilidad. Esto se logró, con el uso de la programación imperativa, llevando
proporcionar una mayor libertad a los programadores. Permitiendo, más concentración en la
formulación del problema, liberándolo de la administración del algoritmo. El diseño de cada
uno de los módulos que conforman a COIN, ha sido programado de una manera más fácil
para adaptarlos y verificarlos. Su diseño es: breve, elegante, claro y fácil de conservar.
Ilustración 29 Paradigmas, reglas y lenguajes en la programación.
Fuente: Addy Dávila.
11.2 ARQUITECTURA DE LA APLICACIÓN
COIN, es una aplicación distribuida, por lo cual, la arquitectura establecida es
Cliente/Servidor (ver ilustración 11). Donde los usuarios podrán ejecutar el software en
ambiente web, sin necesidad de hacer la instalación en forma local.
La decisión tomada para la utilización de esta arquitectura se debe a la organización de la
información que se procesara en la aplicación web. Ya que la base de datos y su información
estará centralizada. Permitiendo que toda la gestión de la información y las responsabilidades
estén separadas, lo que proporciona que tanto el Cliente como el Servidor, sean objetos
abstractos y que puedan residir en el mismo computador o en computadores diferentes.

Ilustración 30 Arquitectura Cliente/Servidor.
Fuente: Jesús Alfonso Guerra Cedeño. Trabajo de grado desarrollo de un sistema para la
gestión documental de la información de estudiantes con discapacidad intelectual.
Además de utilizar la arquitectura cliente/servidor, dispone de tres capas o niveles. Nivel
1, donde clientes interactúan con los usuarios finales. Nivel 2, los servidores de aplicación
que transforman los datos para los clientes. Y, por último, el Nivel 3 donde los servidores de
la base de datos que guardan los datos para los servidores de aplicación.
11.3 CARACTERÍSTICAS QUE SE REQUIEREN PARA EL
FUNCIONAMIENTO DE COIN
En primera instancia y al tratarse de una aplicación web que está instalada y distribuida en
un host alojado en la nube es totalmente necesario contar con conexión a internet para así
poder acceder a ella desde cualquier sitio y dispositivo. Como segunda característica el
cliente deberá usar la versión más reciente de los siguientes navegadores web (Google
Chrome, Mozilla Firefox, y Opera Stable) ya que es algunos elementos con lo que está hecho
el aplicativo requieren de una compatibilidad para poder ser ejecutados con éxito.
11.4 COLORES.
Para la tendencia Material Design la aplicación del color en las GUI es muy importante a
la hora de establecer los diseños recomiendan, un color primario y uno secundario la cual
representan su marca. Las variantes oscuras y claras de cada color que sean armonioso,
garanticen texto accesible y distingue los elementos y las superficies de la interfaz de usuario
entre sí. (Google, s.f.).
COIN, utiliza la combinación de la paleta de colores verde pastel para sus interfaces,
botones, banners y barras de navegación.
La tonalidad de colores que se aplica en el diseño de la aplicación teniendo en cuenta la
teoría del color expresada por el Ing. (Quispe, 2017) donde la utilización del color verde
inspira crecimiento, renovación, relajación, juventud, orgánico y seguridad muchas de la las
cualidades que identifica a la empresa de plásticos y desechables LIBIA.
Así pues, a continuación, se presenta la paleta de colores de la interfaz gráfica con las que
contará el sistema de información. Ilustración (8).
Ilustración 31. Paleta de colores.
Fuente: Material de diseños.

11.5 ICONOS.
Los iconos del sistema simbolizan acciones, archivos, dispositivos y directorios. Además
de ser la expresión gráfica que permite la identificación visual de funciones del sistema para
los usuarios.
Los iconos implementados el proyecto COIN son tomados y utilizados de las herramientas
dispuestas por la tendencia de diseño de materiales de Google los cuales permite su uso
teniendo en cuenta su respectiva referencia. A continuación, se da a conocer cada uno de los
iconos utilizados en la interfaz del software ilustraciones (9, 10 y 11).
Ilustración 32. Iconos de software Coin Parte 1.

Ilustración 33 Iconos de software Coin Parte 2

Ilustración 34 Iconos de software Coin Parte 3
11.6 MENÚ.
El menú de COIN está diseñado bajo una concepción modular que proporcionan
elementos de navegación responsive a los usuarios y les permite la gestión de cada una de las
funcionalidades del sistema.
Cada uno de los módulos es un componente del sistema con funciones y características
que interactúan entre sí, con relaciones específicas en cada uno de sus contextos, de igual
manera contiene módulos de menú diferentes para cada uno de los usuarios creados en el
sistema, pues cada rol creado para una actividad en específico y no requieren de la totalidad
de los módulos, como se puede observar en las ilustraciones (8 y xx).

Ilustración 35 Menú Rol Administrador del sistema
11.7 BOTONES.
Los botones permiten al usuario realizar y desencadenar una acción dentro del software
con un clic los cuales deben ser fáciles de encontrar dentro de los demás elementos del
software y, las acciones y los estados de los botones deben ser claros para el usuario. El
diseño de los botones de COIN sigue la tendencia de diseño de materiales acordes al esquema
de la interfaz del software de acuerdo a los colores del mismo.
Ilustración 36. Botones de la COIN.

11.8 MENSAJES DE INFORMACIÓN Y ALERTA
Los mensajes son la comunicación del software retornando información al usuario, cuando
se está ejecutando un proceso o una acción; esto deben de informar al usuario sobre una
novedad o evento ocurrido durante la ejecución de algún proceso.
COIN presenta mensajes de informativos, alertas, error, de acuerdo a las posibles fallas y
omisiones y éxito del usuario al ejecutar un proceso.
Ilustración 37. Mensajes de información y alerta de COIN.

12 PRUEBAS DEL SOFTWARE APLICADAS A COIN
Las pruebas de software son realizadas en el momento en el cual se culmina el desarrollo
del aplicativo, ya que son un instrumento que permite conocer el estado de calidad en el que
este se encuentra y por tanto son un factor importante para determinar si se cumplen o no los
requerimientos funcionales del sistema. En estas pruebas se logran evaluar aspectos como lo
son la accesibilidad, el rendimiento, la eficiencia, la usabilidad, la compatibilidad, etc.
Logrando así, desarrollar un software competitivo en el mercado y que sea de gran utilidad
para los usuarios que harán uso de este.
Las pruebas de software contienen una serie de etapas con las cuales se hará mucho más
sencilla la evaluación de cada uno de los módulos, características y requerimientos que
deberá tener el software en el estado de culminación. La primera etapa es el estudio
preliminar, donde se evalúan las principales funcionalidades del producto con el objetivo de
definir el alcance de las pruebas. La segunda etapa es la planificación, donde se programan
los ciclos de prueba y las funcionalidades del software, aquí se genera un plan de ejecución
que resume toda la información de las pruebas ya realizadas, posteriormente está la etapa de
prueba, en la cual se generan y ejecutan las pruebas para una versión determinada del
producto y por ultimo está la evaluación, que es la etapa donde se tiene como objetivo
realizar el informe final de las pruebas, aplicar las mejoras al software de acuerdo a los
resultados y almacenar los elementos del proyecto de prueba para su uso en proyectos
posteriores.
Ilustración 38. Fases de las pruebas del software.

12.1 PLAN DE PRUEBAS
12.1.1.1 Objetivo general
Elaborar el plan de pruebas de software, con el propósito de ejecutarlas en la aplicación
web COIN y así garantizar la calidad del producto desarrollado.
12.1.1.2 Objetivos específicos
 Diseñar las pruebas del software
 Aplicar las pruebas al software COIN
 Verificar las funcionalidades del software COIN
 Realizar el informe final con los resultados de las pruebas para la toma de
decisiones.
12.2 ALCANCE DEL PLAN DE PRUEBAS DE COIN
Junto al equipo de trabajo se logró establecer el plan de pruebas que se van a ejecutar en la
aplicación web COIN. Una de las primeras pruebas a realizar y las cuales tienen un gran
valor en este capítulo son las unitarias, las cuales mediante el Framework PHPunit se lograra
verificara la funcionalidad del código de cada módulo de la aplicación, otros tipos de pruebas
que se aplicaron en este desarrollo fueron las de estrés, validación, seguridad, despliegue,
interfaz gráfica y de campo, para evaluar diferentes aspectos como lo son: el número de
usuarios que soporta, la validación de los campos, la comprobación de cada hipervínculo, la
verificación de usabilidad ante usuarios diferentes al equipo de trabajo.

Ilustración 39. Plan de pruebas de COIN.
12.3 CRONOGRAMA DEL PLAN DE PRUEBAS
Para la ejecución de las pruebas se realizó un cronograma ver tabla N°50, en la cual
describe cada una de las actividades necesarias, así como las fechas estimadas para cumplir
con los objetivos planteados.
Tabla 60. Cronograma del plan de pruebas.
FECHA ACTIVIDAD DESCRIPCIÓN AUTOR
Investigar las diferentes pruebas de

Búsqueda de información Alejandra Romero Ruiz
1/7/2018 software que existen
De toda la información recolectada

Concentración de la
seleccionar la más importante y la Alejandra Romero Ruiz
información
que mejor se adecua al proyecto
25/8/2018
Seleccionar el software necesario

Selección del Testware Alejandra Romero Ruiz
11/9/2018 para hacer las pruebas
Crear un plan de pruebas que

permita realizar las diferentes
Elaboración y diseño del pruebas de software propuestas,
Alejandra Romero Ruiz
plan de pruebas contemplando diferentes aspectos
como los usuarios, ambiente,
29/9/2018 objetivos, etc.
Aplicar cada una de las pruebas
Aplicación del primer ciclo
seleccionadas en la versión inicial Alejandra Romero Ruiz
8/10/2018 de pruebas
del software
Aplicar cada una de las pruebas

Aplicación del segundo ciclo
seleccionadas en la versión final del Alejandra Romero Ruiz
4/3/2019 de pruebas
software
Una vez realizadas todas las

pruebas analizar los resultados
Análisis de los resultados Alejandra Romero Ruiz
obtenidos para conocer el estado
18/3/2019 actual de COIN
Documentación de los Informe final de los resultados de

Alejandra Romero Ruiz
25/3/2019 resultados las pruebas
12.4 Pruebas de software tipo caja negra y caja blanca
Para los diferentes tipos de pruebas de software como lo son las unitarias, de integración,
del sistema, de recuperación, de rendimiento, de seguridad, de despliegue, etc., se logran
clasificar en dos grandes grupos como lo son la caja negra y caja blanca. En la siguiente tabla
se pueden observar los tipos de pruebas que pertenecen a cada una de estas.
Tabla 61. Pruebas de software tipo caja negra y caja blanca.
Prueba de Caja Caja

Descripción
Software Negra Blanca
Generalmente se realizan con acceso al
Pruebas código fuente y en etapas
unitarias tempranas de desarrollo X
Integran los módulos que componen al

Pruebas de sistema y corrigen lo
integración errores asociados a la interfaz. Para ello, X
comúnmente requieren
del acceso al código fuente.
Evalúan los requisitos no funcionales del
Pruebas del sistema, tales como
sistema seguridad, rendimiento, confiabilidad, X X
interconexiones externas,
dispositivos, entre otros.
Se enfocan en las acciones visibles para el
Pruebas de usuario y las salidas
validación del sistema, y se realizan como si se tratara X
del usuario final.
Prueba de Caja Caja
Descripción
Pruebas de Evalúan la habilidad del sistema para

recuperación recuperarse a fallos. X X
Consisten en verificar el rendimiento de

Pruebas de un módulo del sistema o
rendimiento del sistema en sí durante su ejecución. X X
Verifican que los mecanismos de

Pruebas de protección de un sistema
seguridad realmente protegen de intrusiones externas o X X
acciones
malintencionadas.
Miden el desempeño del producto de
Pruebas de software sobre diferentes
despliegue plataformas y entornos de operación. X
Confrontan el software ante situaciones

Pruebas de anormales de sobrecarga
resistencia de datos, memoria y número de X X
interrupciones.
Inicia considerando un volumen normal
de usuarios concurrentes
Pruebas de en el software para posteriormente introducir
picos de carga picos de carga. Al X X
finalizar el pico de carga, el volumen de
usuarios vuelve a la
normalidad.
Determinan el punto de ruptura del sistema
incrementando
Pruebas de estrés
linealmente el número de usuarios. X X
Evalúan el comportamiento del sistema bajo
una cantidad de
peticiones por segundo. Generalmente se
Pruebas de carga
realiza durante las X
últimas fases del desarrollo
Comparan el producto final del software con
Pruebas de los requisitos del
aceptación cliente desde la perspectiva del usuario final. X
Evalúan el comportamiento del software

Pruebas de durante su instalación en
instalación un entorno final. X
Prueba de Caja Caja
Descripción
Verifican que los cambios realizados al
Pruebas de software no producen
regresión efectos negativos. X X
Evalúan que tan fácil es para al usuario final

Pruebas de aprender a utilizar el
facilidad de uso software. X
Evalúan los componentes de la interfaz y la

Pruebas de
interacción del usuario
interfaz gráfica
final con el sistema. X
de usuario
Utilizan el software en un ambiente no

controlado por el usuario
Pruebas alfa final y con la presencia del desarrollador X
Se ejecutan en un ambiente no controlado

por el desarrollador y
Pruebas beta en un sitio seleccionado por el usuario final. X
Se evalúa el software con una población

ajena al desarrollo para determinar su
Pruebas de
usabilidad con personas sin conocimientos X
campo
previos.
Puesto que no es necesario aplicar todas las pruebas existentes para realizar la validación
del software web COIN, el equipo desarrollador y asesor seleccionó las pruebas que según su
criterio profesional son de mayor relevancia para su aplicación ver tabla 52.
Tabla 62. Pruebas del software empleadas.
Prueba de Implementación en el proyecto

software
Pruebas unitarias PHPunit es el framework que ayudara a comprobar el correcto
funcionamiento de cada una de las unidades de código de COIN.
Pruebas de estrés Esta prueba evalúa el número de usuarios que ingresan COIN por
medio de un software especializado, llamado Jmeter. Este software
parte de un conjunto de datos de entrada relativamente pequeño (1
usuario), que se puede incrementar según lo quiera el tester. Después
de alcanzar un número de datos de entrada relativamente alto, se
prueba la funcionalidad del servidor y/o aplicación.
Pruebas de La ejecución de esta prueba consiste en validar cada uno de los
validación campos de la aplicación para intentar encontrar irregularidades en la
misma, así también como validar que los campos alfabéticos no
acepten caracteres numéricos por mencionar un ejemplo.
Pruebas de Al ser una aplicación en web, se requiere de la comprobación de cada

seguridad uno de los hipervínculos para validar que el usuario no puede
ingresar al software sin antes autenticarse, que el usuario no pueda
acceder a la información de otro usuario alterando los hipervínculos y
que los hipervínculos no estén “rotos”.
Pruebas de Con esta prueba se busca comprobar si la aplicación es responsive y
despliegue cómo se comporta gráficamente en los diferentes navegadores como:
Chrome, Firefox, Opera, Dillo, Safari, Midori, Epiphany, Konqueror,
etc… Asi como también en los diversos sistemas operativos como:
MacOS, iOS, Windows, Linux y Android.
Pruebas de Aquí se comprueba que la interfaz gráfica de usuario tiene una
interfaz gráfica de apropiada navegación a través de los diferentes módulos del sistema.
usuario
Pruebas de campo Esta prueba evaluará la usabilidad de la aplicación, dejando a
personas sin conocimientos de su manejo operarla
12.5 TESTWARE A UTILIZAR PARA PRUEBAS DEL SOFTWARE COIN
El Testware son las aplicaciones diseñadas especialmente para el desarrollo de las pruebas
de software, las cuales permiten cumplir con el objetivo del plan de pruebas. Ver tabla de
aplicaciones de test.
Ilustración 40. Testware a utilizar para pruebas del software COIN.
12.6 RESULTADOS OBTENIDOS DE LAS PRUEBAS.
En el siguiente capítulo se describirán los resultados obtenido de cada una de las pruebas a
las que fue sometido el software COIN, a través de las diferentes herramientas disponibles
para la realización de las siguientes: Pruebas unitarias, Pruebas de estrés, Pruebas de
validación, Pruebas de Seguridad. Pruebas de despliegue y finalmente, pruebas de interfaz
gráfica.
12.6.1 Resultados Pruebas unitarias
A continuación se describe el procedimiento para la instalación y configuración de la

herramienta de Test con la cual se realizaron las pruebas para el software COIN, estas
pruebas se realizaron con la herramienta PHPunit con la ayuda de un gestor de paquetes
llamado Composer, posteriormente se debe preparar el entorno en donde se va a trabajar,
configurando el archivo composer.json y estructurado la carpeta raíz donde estarán los tests.
Ilustración 41. Pruebas unitarias con la herramienta PHPunit .
Es de gran importancia que la estructura de la carpeta tests sea idéntica a la de la carpeta

donde se encuentra el código (/src) y debe tener el equivalente de cada archivo del código con
el sufijo “Test”, en el caso de COIN, como ejemplo el archivo login.php su equivalente de
prueba seria loginTest.php, y es en este archivo donde se escribirá la prueba para el login de
COIN.
Luego de escribir las pruebas de cada elemento del software, se deben ejecutar por medio
de la consola, dentro de esta se sitúa la carpeta donde se encuentran las pruebas y por medio
del comando phpunit + el nombre de la prueba, arrojara el resultado de la misma, mostrando
el tiempo de ejecución, la memoria requerida, el número de tests realizados, los aciertos y las
fallas encontradas como se muestra a continuación.
Ilustración 42. Pantallazo de prueba con la herramienta PHPunit .
En la tabla 53 se los resultados obtenidos en donde se detalla el número de la prueba, su
nombre, el número de aciertos y fallas que presentaron.

Tabla 63. Resultados obtenidos de la prueba con la herramienta PHPunit.
No. Test Assertions Failures

1 loginTest.php 1 0
2 carga_categoriasTest.php 1 0
3 carga_datos_basicosTest.php 1 0
4 carga_marcasTest.php 1 0
5 cerrar_sesionTest.php 1 0
6 configuracionTest.php 2 0
7 listar_articulosTest.php 1 0
8 listar_categoriasTest.php 1 0
9 seguridad_funcionesTest.php 2 0
10 verifica_correoTest.php 3 0
11 clientesTest.php 2 0
12 nueva_salidaTest.php 1 0
13 nuevo_clienteTest.php 2 0
14 salidasTest.php 1 0
15 entradasTest.php 2 0
16 nueva_entradaTest.php 1 0
17 nuevo_proveedorTest.php 1 0
18 proveedoresTest.php 1 0
19 articulosTest.php 3 0
20 categoriasTest.php 2 0
21 marcasTest.php 2 0
22 nueva_marcaTest.php 1 0
23 nuevo_articuloTest.php 1 0
24 nueva_categoriaTest.php 2 0

Como se puede observar en la anterior tabla, no se presentaron fallos en el código del
software.
12.6.2 Resultados de Pruebas De Estrés
Se realizaron 5 pruebas de estrés con el software Jmeter (Apache Jmeter 5.0) las cuales
recabaron información acerca de cuantos usuarios a la vez puede soportar COIN y el tiempo
de conexión que requiere cada uno.
La primera prueba se realizó con un usuario virtual en un tiempo de 1 segundo,
posteriormente se realizaron pruebas con una mayor cantidad de usuarios de 10, 100, 200 y
2000 usuarios virtuales al mismo tiempo en 1 segundo, dichas pruebas consistieron en
realizar peticiones al servidor para conocer si el servidor era capaz de soportar la carga
realizada por los usuarios virtuales. Cabe mencionar que ya para los 2000 usuarios se
empezaron a presentar fallos en las peticiones al servidor, esto es debido a los recursos del
actual servidor.
Para la prueba con los 100 usuarios virtuales se realizó una transferencia de información
de 18584 Bytes en promedio con un tiempo de conexión de entre 0 a 2 milisegundos durante
los incrementos de usuarios, la aplicación COIN se comportó con toda normalidad frente a
los resultados obtenidos.
En la prueba con los 200 usuarios virtuales se realizó una transferencia de información de
18584 Bytes en promedio con un tiempo de conexión entre 0 a 8 milisegundos durante los
incrementos de usuarios los resultados están dentro de los parámetros óptimos permitidos.
Ilustración 43. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 100 usuarios.
Ilustración 44. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 200 usuarios.

Ilustración 45. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 2000 usuarios-1.
Para la prueba con los 2000 usuarios virtuales se realizó una transferencia de
información de 18584 Bytes en promedio, donde se presenta un tiempo de conexión más alto
que esta, entre 0 a 2016 milisegundos con los primeros 826 usuarios, posteriormente aumenta
a 2400 ms en promedio, afectando la trasferencia de información a 2709 bytes.
Ilustración 46. Pruebas con el software Jmeter (Apache Jmeter 5.0) con 2000 usuarios-2.

12.6.3 Resultados De Las Pruebas De Validación
Como resultados a esta prueba se examinaron los diferentes módulos que componen al
sistema, validando cada campo y se encontró que en el módulo Almacén/Nuevo artículo,
siendo más precisos en el campo nombre y precio permite colocar números y signos como se
muestra en la ilustración 47.
Ilustración 47. Resultados de las pruebas de validación.

12.6.4 Resultados de las pruebas de seguridad
Para realizar las pruebas de seguridad, se comprobaron los módulos más importantes, o en
los que se pudiera ver comprometida la información de cualquier usuario. Encontrándose una
falla la cual es que se permite almacenar la contraseña, lo cual no es recomendable.
Ilustración 48. Resultados de las pruebas de seguridad.
Otro de los errores detectados en cuanto a seguridad es que el sistema permite ingresar una
contraseña muy fácil como lo es “12345”, por lo cual se puede decir que no hay una
validación rigurosa que obligue al usuario a colocar letras junto con, números, mayúsculas,
minúsculas o signos, como modelo de contraseñas seguras.

Ilustración 49. Resultados de las pruebas de seguridad-2.
12.6.5 Resultados de las pruebas de despliegue
Las pruebas de despliegue se realizaron en diferentes dispositivos y sistemas operativos
utilizando diferentes navegadores, realizándose en los principales como lo son: Chrome,
Firefox, Safari y Opera. Logrando determinar que el rendimiento del aplicativo web es muy
similar entre plataformas, sistemas operativos y dispositivos, sin embargo, hay errores en la
visualización de los elementos al ingresar desde dispositivos con resoluciones diferentes, esto
también pertenece a las pruebas de GUI.

Ilustración 50. Resultado de las pruebas de despliegue en Opera .
Ilustración 51. Resultados de las pruebas de despliegue en Chrome.

Ilustración 52. Resultados de las pruebas de despliegue en Firefox.
Ilustración 53. Pruebas de despliegue en dispositivos móviles.

12.6.6 Resultados De Las Pruebas De Interfaz Grafica
En las pruebas de GUI se demostró que, aunque la aplicación utiliza la técnica de
Responsive Web Desing para aptarse a diferentes resoluciones de pantalla, aún necesita
realizar ajustes para garantizar una mejor experiencia de usuario. Para evaluar estas pruebas
se utilizó la herramienta PageSpeed Insights de Google, la cual dio como resultado
recomendaciones u optimizaciones para mejorar la aplicación COIN y así lograr una mejor
velocidad en todos los dispositivos para este caso en los ordenadores.
Recomendaciones:
 Eliminar el JavaScript y el CSS que bloquean la visualización
 Aprovechar el almacenamiento en cache del navegador
 Optimizar imágenes
 Minificar CSS
 Minificar HTML
 Minificar JavaScript
Optimizaciones ya aplicadas en el software:
 No tiene re direccionamientos
 La compresión está habilitada
 Prioriza el contenido visible
 El servidor responde rápidamente

Ilustración 54. Pruebas de interfaz gráfica en ordenadores.
Ilustración 55. Pruebas de interfaz gráfica en ordenadores-2.

Ilustración 56. Pruebas de interfaz gráfica en ordenadores-3.
A continuación, se detallan la lista de recomendaciones para el uso en los dispositivos
móviles, y los resultados fueron los siguientes:
Recomendaciones:
 Eliminar el JavaScript y el CSS que bloquean la visualización
 Aprovechar el almacenamiento en cache del navegador
 Optimizar imágenes
Optimizaciones ya aplicadas en el software:
 No tiene re direccionamientos
 La compresión está habilitada
 Prioriza el contenido visible
 El servidor responde rápidamente
 El CSS está reducido
 El HTML está reducido
 El JavaScript esta reducido

 Las imágenes están optimizadas
Ilustración 57. Pruebas de interfaz gráfica en dispositivos móviles
Ilustración 58. Pruebas de interfaz gráfica en dispositivos moviles-2.

13 Conclusiones
Realizando el proceso de investigación del proyecto se concluye lo siguiente:
Dentro del proceso investigativo y el desarrollo del proyecto permitió: comprender que la
investigación es una acción inherente de las personas, y que a través de la práctica se logra
perfeccionar, teniendo en cuenta lo anterior, se ponen en práctica los conocimientos
adquiridos durante la formación académica. Además de trabajar en un contexto empresarial
adquiriendo experiencia en el desarrollo de software.
El desarrollo del software COIN, fue desarrollado con una de las tendencias de mayor
relevancia y pertinencia pues, es la que implementa una de las grandes compañías de
desarrollo como lo es Google. Implementado la tecnología y tendencia Diseños de
Materiales y un diseño de la base de datos del software está estructurada y construida para
que permita almacenamiento de información sin inconsistencias y redundancia.
Se logró desarrollaron cada uno de los requerimientos funcionales del sistema,
establecidos por parte del equipo de trabajo y la administradora de la empresa.
El software COIN está desarrollado para mejorar el proceso de inventarios y facturación
de la empresa plásticos y desechables Libia y la preservación de la información, facilitando a
la administración la toma de decisiones.
La implementación de la metodología SCRUM para el desarrollo de proyecto de
ingeniería permite un progreso y retroalimentación para el equipo de trabajo, permitiendo al
cliente conocer y aprobar los avances del proyecto.
La realización de las pruebas unitarias, Pruebas de estrés, Pruebas de validación, Pruebas
de Seguridad. Pruebas de despliegue y finalmente, pruebas de interfaz gráfica
Permitió el equipo desarrollador realizar los ajustes y correcciones del código del software
COIN, atendiendo a las diferentes recomendaciones de los resultados obtenidos.

14 Referencias Bibliográficas
Camacho, A., & Torres, M. (s.f.). Requerimientos Dentro del Desarrollo de Software:
Ingenieria y Administracion. Recuperado el 15 de 11 de 2018, de
https://sophia.javeriana.edu.co/~lcdiaz/ingSw2007-1/Requerimientos_mTorres.pdf
Montero, Y., & Martín Fernández, F. (2004). PROPUESTA DE ADAPTACIÓN DE LA
METODOLOGÍA DE DISEÑO CENTRADO EN EL USUARIO PARA EL
DESARROLLO DE SITIOS WEB ACCESIBLES. Revista Española de
Documentación Científica, 27(3), 332. doi:ISSN 0210-0614
A., S. S. (s.f.). Portal SIIGO. Obtenido de
http://portal.siigo.com/docs/DocView.aspx?DocumentID=%7B2CF85410-7F68-
4081-A701-EE2913E0A5F1%7D&NoHeader=1&NoSubject=1
Alarcón, H., Hurtado, A., Pardo, C., Collazos, C., & Pino, F. (2007).
Integración de Técnicas de Usabilidad y Accesibilidad en el Proceso de Desarrollo de
Software de las MiPyMEs . Avances en Sistemas e Informática, 150.
Albaladejo, X. (15 de 08 de 2009). La web de Scrum en español para la difusión de la
gestión ágil de proyectos. Obtenido de Proyectos Agiles .Org:
https://proyectosagiles.org/2009/08/15/scrum-proceso-trabajo-2-0/
Albornoz, M. C., Necco, C. M., & Montejano, G. A. (s.f.). Modelo de Desarrollo de
Interfaces en Lenguaje Funcional . San Luis, Argentina .
APP, F. (s.f.). FacturaCO APP. Obtenido de http://www.factura.co/es/
Art 437, E. t. (23 de 01 de 2018). Responsables del impuesto. Obtenido de Estatuto tiburatio
nacional.: http://estatuto.co/?e=686
Atic. (2017). Obtenido de Atic: http://www.atic.cl/factibilidad-de-sistemas/
Banco de la Republica de Colombia. (2013). Obtenido de Banco de la Republica de
Colombia: http://www.banrep.gov.co/es/el-banco/que-hacemos
Beatriz Margarita Leal . (2017). IDA. Obtenido de IDA: https://www.ida.cl/blog/estrategia-
digital/metodologia-scrum-en-proyectos-digitales/
Blueindic blog. (2017). Obtenido de Blueindic blog: https://www.blueindic.com/blog/cuales-
son-las-cuentas-anuales-de-una-empresa/
Castañeda Fuentes, I. (2017). Capítulo 11:Gestión de los Riesgos del Proyecto. Recuperado el
19 de 09 de 2018, de
http://dis.unal.edu.co/~icasta/GGP/_Ver_2013_2/2013_11_13_acRiesgo/GGP_2013_
11_20_acRiesgos_Publ.pdf
CCM. (08 de 03 de 2017). Obtenido de CCM: https://es.ccm.net/contents/223-ciclo-de-vida-
del-software
Cepal. (2016). Metodología Para Análisis Y Solución De Problemas. Recuperado el 29 de 04
de 2018, de https://www.cepal.org/ilpes/noticias/paginas/7/35117/03_arbol_1.pdf
COLOMBIA, C. D. (31 de 06 de 2000). LEY 603 DE 27 DE JULIO DE 2000. Bogotá,
Colombia. Recuperado el 29 de 05 de 2018, de
http://legal.legis.com.co/document/legcol/legcol_75992041aa6ef034e0430a010151f0
34/ley-603-de-2000-ley-603-de-
2000?text=articuloprincipal_$norma$%7Cley%20603%20de%202000%20articulo%2
01%7C%7Carticulo_$norma$%7Cley%20603%20de%202000%20articulo%201&typ
e=qe&hi
Colombia, P. d. (03 de 04 de 2012). Directiva Presidencial N°4. EFICIENCIA
ADMINISTRATIVA Y LINEAMIENTOS DE LA POLlTICA CERO PAPEL EN
LAADMINISTRACIÓN PÚBLICA. Bogotá D.C, Colombia. Recuperado el 29 de 05 de
2018, de https://www.mintic.gov.co/portal/604/articles-3647_documento.pdf
Cruz-Lemus, J. P. (2014). Métodos de Investigación en Ingeniería del Software. RaMa.

del Ministerio de Tecnologías de la Información y las Comunicaciones MINTIC,. (06 de
Noviembre de 2016). del Ministerio de Tecnologías de la Información y las
Comunicaciones MINTIC. Obtenido de http://www.mintic.gov.co/portal/604/w3-
article-19775.html
Fenalco. (2018). Obtenido de Fenalco: https://www.dinero.com/noticias/fenalco/156
Ferré Grau, X., & Sánchez Segura, M. (2008). Desarrollo Orientado a Objetos con UML.
Recuperado el 20 de 10 de 2018, de
http://rafaelmellado.cl/material/com3162/complementario/05.pdf
Fiducoldex. (2018). Fiducoldex. Obtenido de Funciones :
https://www.fiducoldex.com.co/seccion/informacion-general
Galeano, J. F. (2016). Importancia de las TIC para la competitividad de las Pymes en
Colombia. Revista Cientifica Universidad Pontificia Bolivariana, 96.
Gerencie. (17 de 03 de 2012). REQUISITOS DE LA FACTURA EN COLOMBIA. Obtenido
de https://contablecolombia.blogia.com/2012/021701-requisitos-de-la-factura-en-
colombia.php
Google. (s.f.). Diseño de Materiales. Recuperado el 06 de 09 de 2018, de
https://material.io/design/introduction/#principles
INVIMA. (2018). Instituto Nacional de Vigilancia de Medicamento. Obtenido de
https://www.invima.gov.co/nuestra-entidad/objetivos-estrategicos.html
ITFIP. (23 de 11 de 2009). Resolución 434 . Espinal , Tolima.
minitab 18. (2017). Obtenido de minitab 18: https://support.minitab.com/es-
mx/minitab/18/help-and-how-to/quality-and-process-improvement/quality-
tools/supporting-topics/pareto-chart-basics/
MINTIC, M. d. (17 de 12 de 2017). Estrategia Gobierno en Línea, Para el orden nacional.
Obtenido de Recuperado en 17 de diciembre de 2017: www.gobiernoenlinea.gov.co.

Pons , C., Giandini, R., & Pérez, G. (2010). DESARROLLO DE SOFTWARE DIRIGIDO
POR MODELOS; Conceptos teóricos y su aplicación práctica. La Plata: Universidad
Nacional de La Plata.
Proyectosagiles. (2018). Obtenido de Proyectosagiles: https://proyectosagiles.org/que-es-
scrum/
Quispe, M. (21 de 10 de 2017). Congreso Internacional de Ingeniera, ciencias
Aereonátuticas y Arquiforo . Obtenido de Psicología y teoría del color en el desarrollo
de aplicaciones web:
http://www.usmp.edu.pe/vision2017/pdf/materiales/Psicologia_y_teoria_del_color_en
_el_desarrollo_de_aplicaciones_Web.pdf
Samsing, C. (17 de 07 de 2017). HubSpot. Obtenido de HubSpot:
https://blog.hubspot.es/marketing/tecnicas-lluvia-de-ideas-creativas
Semana, R. (2016). En Colombia una de cada dos empresas usa software pirata. Semana.
Recuperado el 29 de 05 de 2018, de
https://www.semana.com/tecnologia/articulo/software-pirata-en-colombia-una-de-
cada-dos-empresas-los-usa/477981
SIIGO. (2018). Obtenido de SIIGO: https://www.siigo.com/blog/contador/que-es-un-
inventario/
Sinnaps. (2018). Obtenido de Sinnaps: https://www.sinnaps.com/blog-gestion-
proyectos/metodologia-zopp
15 Bibliografía
Álvarez, R. (s.f.). Lenguajes de lado servidor o cliente. Recuperado en diciembre de 2016, de
http://www.desarrolloweb.com/articulos/239.php}
Enríquez, Juan Gabriel y CASAS, Sandra Isabel. Usabilidad en aplicaciones móviles. 2013.
ISSN: 1852 – 4516.
Genero, M., Cruz-Lemus, J.A., Piattini, M. (2014). Métodos de Investigación en Ingeniería del
Software. RaMa.
Gimson, Loraine. Metodologías ágiles y desarrollo basado en conocimiento. Argentina, 2012,
106h. Trabajo de grado (Especialidad en Ingeniería de software). Universidad
Nacional de La Plata. Facultad de Informática. Disponible en:
http://sedici.unlp.edu.ar/bitstream/handle/10915/24942/Documento_completo__.pdf?
sequence=1
Gómez F., María del Carmen. MATERIAL DIDÁCTICO NOTAS DEL CURSO BASES DE
DATOS. En línea. Editada por: UNIVERSIDAD AUTONOMA METROPOLITANA.
México. Impreso por Publidisa Mexicana S. A. de C.V. 2013. Citado noviembre 22
del 2018. Disponible en:
http://cua.uam.mx/pdfs/conoce/libroselec/Notas_del_curso_Bases_de_Datos.pdf.
Jordi Cabot. LAS MEJORES HERRAMIENTAS PARA MODELAR EN TU NAVEGADOR
DIAGRAMAS UML, ER Y BPMN. Enero 10 del 2018. Disponible en:
https://ingenieriadesoftware.es/herramientas-modelar-diagramas-uml-online-
navegador/
Kendall K. y Kendall J. Análisis y Diseño de Sistemas Octava Edición. México: Prentice Hall.
2011. 600p. ISBN: 978-607-32-0577-1. Disponible en:
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnx
pbmdzaXN0ZW1hc3VwZXU5NzM0ODAzNTl8Z3g6N2RmZjI5N2FhZDFiMTgxO
Q.
López, Patricia y Ruiz, Francisco. INGENIERÍA DEL SOFTWARE I Tema 2 Lenguaje
Unificado de Modelado – UML. [diapositivas en línea]. 2015. 111 diapositivas a color.
Disponible en: http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-
i/materiales-de-clase-1/is1-t02-trans.pdf.
Lucidchart. Qué es el lenguaje unificado de modelado (UML). Recuperado Enero 10 del
2018. Disponible en: https://www.lucidchart.com/pages/es/qu%C3%A9-es-el-
lenguaje-unificado-de-modelado-uml
Maya, Esther. Métodos y técnicas de investigación Una propuesta ágil para la presentación de
trabajos científicos en las áreas de arquitectura, urbanismo y disciplinas afines.
México, Distrito Federa. 2014. 90p. ISBN: 978-97032-5432-3. Disponible en:
http://portal.fa-unam.mx/uploads/8/1/1/0/8110907/_____metodos_y_tecnicas.pdf.
Ministerio de Tecnologías de la Información y las Comunicaciones. Estrategia Gobierno en
Línea, Para el orden nacional. Recuperado en enero 10 del 2018. Disponible
en: http://www.gobiernoenlinea.gov.co
Project Management Institute, Inc. Guía de los fundamentos para la dirección de proyectos
(Guía del PMBOK) cuarta edición. Recuperado el 23 de noviembre del 2018.
Disponible en: https://app.box.com/s/7cb5e4675afb537bf9f4
PMI Project Management Institute. Guía del PMBOK y estándares. Recuperado el 25 de
noviembre del 2018. Disponible en:
https://americalatina.pmi.org/latam/pmbokguideandstandards.aspx
Ruiz, M. H. 2006. Programación Web avanzada. Soluciones rápidas y efectivas para
desarrolladores de sitios. La Habana: Félix Varela.

Shneiderman, B. Plaisant, K., 2004. Designing the User Interface Strategies for Effective
Human-Computer Interaction, Addison Wesley.
Shneiderman, B.; Plaisant, C (2006). Diseño de interfaces de usuario. Estrategias para una
interacción persona-computadora efectiva. México: Addison Wesley.
Universidad Católica. Tipos de Investigación según Grado de Profundidad y Complejidad.
Recuperado el 11 de enero del 2018. Disponible en:
http://publicaciones.ucatolica.edu.co/revista/arquitectura/RevArq_Parametros_para_
Autores_Descripcion_2015.pdf.
Zapata, C. M. Garcés, G. L. Generación Del Diagrama De Secuencias De Uml Desde
Esquemas Preconceptuales. 2008. Revista EIA, ISSN 1794-1237 Número 10, p. 89-
103.

Monografia Final COIN FINAL Agosto 2019

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Monografia Final COIN FINAL Agosto 2019

Загружено:

Авторское право:

Доступные форматы

DESARROLLO DE UN SOFTWARE DE ADMINISTRACIÓN DE PRODUCTOS,

FACTURACIÓN, PAGOS Y CARTERA PARA LA EMPRESA PLÁSTICOS Y

DESECHABLES LIBIA DE AGUA DE DIOS, CUNDINAMARCA.

NAYIBE SORAYA SANCHEZ LEÓN

ALEJANDRA ROMERO RUIZ

CRISTIAN OSWALDO LOZADA TOVAR

JOSÉ ALEXANDER AGUILAR GONZÁLEZ

NAYIBE SORAYA SANCHEZ LEÓN

LUIS R. RAMÍREZ LIÉVANO

MELISSA RIVERA GUZMÁN

SORAYA JIMÉNEZ MONTAÑA

INSTITUTO TOLIMENSE DE FORMACION TECNICA

INGENIERIA Y CIENCIAS AGROINDUSTRIALES

TECNOLOGIA EN GESTION INFORMATICA

FACTURACIÓN, PAGOS Y CARTERA PARA LA EMPRESA PLÁSTICOS Y

DESECHABLES LIBIA DE AGUA DE DIOS, CUNDINAMARCA.

NAYIBE SORAYA SANCHEZ LEÓN

ALEJANDRA ROMERO RUIZ

CRISTIAN OSWALDO LOZADA TOVAR

JOSÉ ALEXANDER AGUILAR GONZÁLEZ

NAYIBE SORAYA SANCHEZ LEÓN

LUIS R. RAMÍREZ LIÉVANO

MELISSA RIVERA GUZMÁN

SORAYA JIMÉNEZ MONTAÑA

INSTITUTO TOLIMENSE DE FORMACION TECNICA

INGENIERIA Y CIENCIAS AGROINDUSTRIALES

TECNOLOGIA EN GESTION INFORMATICA

Presidente del Jurado

desarrollo y elaboración de la presente monografía.

seguir el desarrollo del proyecto.

1.1 OBJETIVO GENERAL ........................................................................................... 21

1.2 OBJETIVOS ESPECÍFICOS.................................................................................. 21

2 PLANTEAMIENTO DEL PROBLEMA ...................................................................... 22

2.1 DESCRIPCIÓN DEL PROBLEMA ....................................................................... 22

2.2 HIPÓTESIS DEL PROBLEMA ............................................................................. 23

2.3 DEFINICIÓN DEL PROBLEMA .......................................................................... 23

4 MARCO REFERENCIAL DE LA INVESTIGACIÓN ............................................... 27

4.1 ENTIDADES QUE REGULAN EL COMERCIO EN COLOMBIA .................. 28

4.2 FACTURACIÓN ...................................................................................................... 33

4.3 INVENTARIOS ........................................................................................................ 34

5 LA INVESTIGACIÓN EN EL CAMPO DEL DESARROLLO DEL SOFTWARE 39

5.1 MÉTODOS Y/O TÉCNICA PARA IDENTIFICAR LA PROBLEMÁTICA EN

5.2 ANÁLISIS DE REQUERIMIENTOS EN LA INGENIERÍA DEL SOFTWARE

5.3 ESTUDIO DE FACTIBILIDAD EN EL DESARROLLO DEL SOFTWARE .. 45

5.5 METODOLOGÍAS DE DESARROLLO DEL SOFTWARE .............................. 51

6 MARCO LEGAL DE LA INVESTIGACIÓN .............................................................. 56

6.1 REGLAMENTACIÓN DE TRABAJO DE GRADOS ......................................... 56

6.2 FACTURACIÓN EN ESTABLECIMIENTOS COMERCIALES ...................... 56

6.3 PRESENTACIÓN DE INFORME DE GESTIÓN. ............................................... 57

7 ESTADO DEL ARTE O ANTECEDENTES ................................................................ 59

8 METODOLOGÍA DE LA INVESTIGACIÓN ............................................................. 63

8.1 TIPO DE INVESTIGACIÓN .................................................................................. 63

8.2 POBLACIÓN DE LA INVESTIGACIÓN ............................................................. 63

8.3 TÉCNICAS DE RECOLECCIÓN DE INFORMACIÓN .................................... 64

9 MARCO DE TRABAJO PARA EL DESARROLLO ÁGIL DE SOFTWARE:

9.1 PLANEACIÓN DEL PROYECTO “COIN” ......................................................... 72

9.2 CONFORMACIÓN DEL EQUIPO ........................................................................ 73

9.3 GESTIÓN RIESGOS DEL PROYECTO .............................................................. 74

9.4 ESTUDIO DE FACTIBILIDAD ............................................................................. 96

Factibilidad legal. ............................................................................................................ 97

Factibilidad de tiempo. ................................................................................................... 97

9.5.1 Alcance del proyecto COIN. ........................................................................... 110

9.5.2 Requerimientos funcionales. .......................................................................... 110

10 PLANEACIÓN Y GESTIÓN DEL PROYECTO ................................................... 123