Desarrollo de un sistema informático orientado a la web, para la gestión administrativa y control

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

DESARROLLO DE UN SISTEMA INFORMÁTICO ORIENTADO A LA WEB, PARA LA GESTIÓN ADMINISTRATIVA Y CONTROL DE PRODUCCIÓN DE LA FÁBRICA DE BLOQUES “SAN PEDRITO” DE SANTO DOMINGO; PERIODO 2016-2017

Trabajo de Titulación previo a la obtención del título de Ingeniero de Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software.

Autores: ERIK ADRIAN ANDRADE PAZMIÑO JEFFERSON PEDRO FIGUEROA OCAMPO Director: MG. LUIS JAVIER ULLOA MENESES

Santo Domingo – Ecuador Agosto, 2017

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

HOJA DE APROBACIÓN DESARROLLO DE UN SISTEMA INFORMÁTICO ORIENTADO A LA WEB, PARA LA GESTIÓN ADMINISTRATIVA Y CONTROL DE PRODUCCIÓN DE LA FÁBRICA DE BLOQUES “SAN PEDRITO” DE SANTO DOMINGO; PERIODO 2016-2017

Línea de Investigación: Estudio, Diseño e Implementación de Software.

Autor: ERIK ADRIAN ANDRADE PAZMIÑO JEFFERSON PEDRO FIGUEROA OCAMPO

Luis Javier Ulloa Meneses, Mg.

f.

DIRECTOR DE LA DISERTACIÓN DE GRADO

Jon Azcona Esteban, Mg.

f.

CALIFICADOR

Margareth Viviana Hurtado Quiroz, Mg.

f.

CALIFICADOR

Margoth Elisa Guaraca Moyota, Mg.

f.

DIRECTORA DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Agosto, 2017

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Erik Adrian Andrade Pazmiño portador de la cédula de ciudadanía Nº 2300411457 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legar y académica.

ERIK ADRIAN ANDRADE PAZMIÑO CI 2300411457

iv

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Jefferson Pedro Figueroa Ocampo portador de la cédula de ciudadanía Nº 2350086175 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legar y académica.

JEFFERSON PEDRO FIGUEROA OCAMPO CI 2350086175

v

AGRADECIMIENTO Agradezco a mis padres Janeth Ocampo y Pedro Figueroa por el apoyo incondicional en cada meta que me propongo en la vida y ayudarme en las dificultades encontradas. A mis hermanos Verónica Figueroa, Darwin Figueroa y Lisseth Figueroa por motivarme en seguir con mis objetivos.

A los docentes de la Universidad por impartir los conocimientos necesarios para mi formación académica, por su amistad y confianza brindada en el trascurso de toda la carrera.

Y por el asesoramiento adecuado para el desarrollo del presente proyecto.

A mi mejor amiga Samantha Almeida por su paciencia y motivación en la duración de la carrera, a Ana Martínez por conceder sus conocimientos y complementar mis ideologías.

Jefferson Figueroa

Expreso mi profundo agradecimiento a mis padres por brindarme su incondicional apoyo y consejos, y gracias a su motivación constante, permitieron que culmine con éxito mis estudios universitarios.

A la Pontificia Universidad Católica del Ecuador Sede Santo Domingo y sus docentes que

han

sabido

impartirme

los

conocimientos

necesarios

para

darme

una

íntegra y verdadera formación universitaria que me servirá en mi vida profesional.

Erik Andrade

vi

DEDICATORIA El siguiente trabajo de disertación de grado lo dedico a mis padres por permitirme estudiar el tercer nivel y no dejarme rendir a pesar de las circunstancias presentadas en el lapso de la carrera. A mis tías que influyeron para mi estudio continuo, y a todas las personas que en algún momento se involucraron en mi formación académica y moral.

Jefferson Figueroa

A mis padres, hermanos y amigos.

Erik Andrade

vii

RESUMEN La presente disertación de grado comprende la automatización de los procesos de gestión administrativa y control de producción que se realizan en la Fábrica de Bloques “San Pedrito” de Santo Domingo de los Tsáchilas, mediante la elaboración de un sistema informático orientado a la web, denominado SIGPRO (Sistema Informático para la Gestión Administrativa y Control de Producción). Dicho sistema se desarrolla con la finalidad de reducir el tiempo empleado en los procesos, optimizar los recursos de la empresa y mejorar el control de las actividades que se realizan.

El proyecto se desglosa en tres módulos: administración, producción y ventas. El primero gestiona los usuarios que harán uso del sistema. El segundo módulo se divide en cuatro secciones: materia prima, proveedores, productos y producción. El módulo de ventas contempla los clientes y las ventas. Todos ellos generan reportes y emplean reglas de validación en sus formularios. Además, el sistema genera automáticamente las notificaciones de escasez de stocks.

La investigación relata la elaboración del sistema. Para el desarrollo se emplea la metodología XP y para la separación de las partes del sistema la arquitectura por capas. Se utiliza MariaDB como base de datos, HTML5 con MaterializeCSS para el diseño web, PHP como lenguaje de script y junto con Javascript para la programación y validación de los módulos que componen el sistema, y finalmente HostGator como empresa proveedora de Hosting y Dominio Web.

viii

ABSTRACT This degree dissertation includes the automation of the administrative management and production control processes carried out in the "San Pedrito" Blocks Factory in Santo Domingo de los Tsรกchilas, through the growth of a web-oriented computer system, called SIGPRO (Computer System for Administrative Management and Production Control). This system is developed with the purpose of reducing the time spent in the processes, optimize the resources of the company and improve the control of the activities that are carried out.

The project is broken down into three modules: administration, production and sales.

The first manages the users who will use the system. The second module is divided into four sections: raw materials, suppliers, products and production. The sales module looks at customers and sales. All of them generate reports and use validation rules in their forms. In addition, the system automatically generates notifications of stock shortages.

The research relates the elaboration of the system. For development the XP methodology is used and for the separation of the parts of the system the architecture by layers.

It uses MariaDB as a database, HTML5 with MaterializeCSS for web design, PHP as a scripting language and together with Javascript for programming and validation of the modules that make up the system, and finally HostGator as a provider of Hosting and Web Domain.

ix

ÍNDICE DE CONTENIDOS

1.

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

2.

PLANTEAMIENTO DEL PROBLEMA ......................................................................... 3

2.1. Antecedentes..................................................................................................................... 3 2.2. Problema de investigación ................................................................................................ 4 2.3. Justificación de la investigación ....................................................................................... 5 2.4. Objetivos de investigación ............................................................................................... 6 2.4.1. Objetivo General .............................................................................................................. 6 2.4.2. Objetivos específicos ........................................................................................................ 6 3.

MARCO REFERENCIAL ............................................................................................... 7

3.1. Revisión de la literatura o fundamentos teóricos ............................................................. 8 3.1.1. Ingeniería de Software...................................................................................................... 8 3.1.2. Base de Datos ................................................................................................................. 20 3.1.3. Aplicaciones Web ........................................................................................................... 25 3.1.4. Herramientas de desarrollo web ..................................................................................... 27 3.1.5. Gestión Administrativa................................................................................................... 30 3.1.6. Control de Producción .................................................................................................... 31 4.

METODOLOGÍA DE LA INVESTIGACIÓN .............................................................. 34

4.1. Diseño / Tipo de investigación ....................................................................................... 34 4.1.1. Enfoque de la investigación............................................................................................ 34 4.1.2. Diseño de la investigación .............................................................................................. 34 4.1.3. Tipo de Investigación ..................................................................................................... 34 4.2. Población / Universo ...................................................................................................... 35 4.3. Muestra ........................................................................................................................... 35 4.4. Técnicas e Instrumentos de recogida de datos ............................................................... 35 4.5. Técnicas de Análisis de Datos ........................................................................................ 36 4.6. Metodología de Desarrollo de Software ......................................................................... 36 4.6.1. Análisis de metodologías de desarrollo de software ...................................................... 36 4.6.2. Metodología Extreme Programming (XP) ..................................................................... 42 5.

Resultados ...................................................................................................................... 44

5.1. Análisis y Discusión de los resultados ........................................................................... 44

x

5.1.1. Entrevista realizada al gerente de la Fábrica de Bloques “San Pedrito” ....................... 44 5.1.2. Encuestas realizadas al personal de la Fábrica de Bloques “San Pedrito” ..................... 46 5.1.3. Selección de recursos de desarrollo para la elaboración de la aplicación. ..................... 54 5.1.4. Resultado de la aplicación de la metodología ................................................................ 58 5.1.5. Resultados de la administración de inventarios.............................................................. 81 5.2. Conclusiones .................................................................................................................. 84 5.3. Recomendaciones ........................................................................................................... 85 GLOSARIO DE TÉRMINOS.................................................................................................. 92 ANEXOS ................................................................................................................................. 94

xi

ÍNDICE DE TABLAS Tabla 1. Comparación entre Metodologías. ............................................................................. 17 Tabla 2. Dimensión 1. Alcance de la Metodología (XP y Scrum) .......................................... 37 Tabla 3. Dimensión 2. Grado de agilidad XP .......................................................................... 38 Tabla 4. Dimensión 2. Grado de agilidad Scrum ..................................................................... 39 Tabla 5. Dimensión 3. Valores ágiles ...................................................................................... 40 Tabla 6. Dimensión 4: Caracterización del Proceso de Software ............................................ 41 Tabla 7. Desarrollo de procesos administrativos y control de producción de manera eficiente en la empresa............................................................................................................................ 46 Tabla 8. Conocimiento de inventarios de productos finales. ................................................... 47 Tabla 9. Disponibilidad de inventarios de materia prima. ....................................................... 48 Tabla 10. Necesidad de automatizar el control de producción. ............................................... 49 Tabla 11. Conocimiento del registro de ventas de la empresa. ................................................ 50 Tabla 12. Uso de dispositivos digitales para consultas informáticas. ...................................... 51 Tabla 13. Implementación de un sistema informático para el control de la producción. ........ 52 Tabla 14. Beneficios de la implementación del sistema informático. ..................................... 53 Tabla 15. Comparativa entre PostgreSQL, MariaDB y SQL Server ....................................... 55 Tabla 16. Comparativa entre herramientas para modelado de datos ....................................... 56 Tabla 17. Comparativa entre lenguajes de Script .................................................................... 56 Tabla 18. Tabla comparativa Materialize - Boostrap............................................................... 57 Tabla 19. Plantilla de Historia de Usuario ............................................................................... 59 Tabla 20. Plan de Entregas....................................................................................................... 60 Tabla 21. Plan de Iteraciones ................................................................................................... 61 Tabla 22. Tarjeta CRC - Usuarios............................................................................................ 62 Tabla 23. Tarjeta CRC - Ventas ............................................................................................... 63 Tabla 24. Tarjeta CRC - Producto ........................................................................................... 63 Tabla 25. Tarjeta CRC - Proveedor ......................................................................................... 63 Tabla 26. Tarjeta CRC – Materia Prima .................................................................................. 64 Tabla 27. Tarjeta CRC - Cliente .............................................................................................. 64 Tabla 28. Tarjeta CRC - Producción........................................................................................ 64

xii

ÍNDICE DE FIGURAS Figura 1. Esquema de contenidos del Trabajo de Titulación ..................................................... 7 Figura 2. Etapas del Proceso XP. ............................................................................................. 14 Figura 3. Modelo del proceso Scrum. ...................................................................................... 16 Figura 4. Criterios de comparación en Dimensión 1. .............................................................. 18 Figura 5. Criterios de comparación en Dimensión 2. .............................................................. 18 Figura 6. Criterios de comparación en Dimensión 3. .............................................................. 19 Figura 7. Criterios de comparación en Dimensión 4. .............................................................. 19 Figura 8. Patrón Modelo-Vista-Controlador. ........................................................................... 20 Figura 9. Ejemplo de Diagrama Entidad-Relación de una biblioteca. ..................................... 22 Figura 10. Esquema Cliente/Servidor. ..................................................................................... 25 Figura 11. Arquitectura en tres capas. ..................................................................................... 26 Figura 12. Desarrollo de procesos administrativos y control de producción de manera eficiente en la empresa............................................................................................................................ 46 Figura 13. Conocimiento de inventarios de productos finales. ................................................ 47 Figura 14. Disponibilidad de inventarios de materia prima. .................................................... 48 Figura 15. Necesidad de automatizar el control de producción. .............................................. 49 Figura 16. Conocimiento del registro de ventas de la empresa. .............................................. 50 Figura 17. Uso de dispositivos digitales para consultas informáticas. .................................... 51 Figura 18. Implementación de un sistema informático para el control de la producción. ....... 52 Figura 19. Beneficios de la implementación del sistema informático. .................................... 53 Figura 20. Diseño Físico de la Base de Datos ......................................................................... 65 Figura 21. Diseño Lógico de la Base de Datos ........................................................................ 66 Figura 22. Diseño de interface vista principal ......................................................................... 68 Figura 23. Diseño de interface ingreso al sistema .................................................................. 68 Figura 24. Diseño de interface principal de administración. ................................................... 69 Figura 25. Diseño de interface principal de administración .................................................... 69 Figura 26. Diseño de interface sección materia prima ............................................................. 70 Figura 27. Diseño de interface sección productos ................................................................... 70 Figura 28. Diseño de interface sección producción ................................................................. 71 Figura 29. Diseño de interface sección clientes ....................................................................... 71 Figura 30. Diseño de interface sección ventas ......................................................................... 72 Figura 31. Diseño de interface sección proveedores ............................................................... 72 Figura 32. Diseño de interface sección usuarios ...................................................................... 73 Figura 33. Conexión a la base de datos.................................................................................... 74 Figura 34. Codificación de la conexión a la base de datos ...................................................... 74 Figura 35. Codificación de la Clase Producción ...................................................................... 75 Figura 36. Codificación de las interfaces de administración ................................................... 76 Figura 37. Interfaz principal de ingreso ................................................................................... 77 Figura 38. Codificación del Login de Usuario......................................................................... 77 Figura 39. Interfaz principal de administración (Usuario administrador) ............................... 78 Figura 40. Interfaz principal de administración (Usuario supervisor) ..................................... 78 Figura 41. Codificación del Login de Usuario......................................................................... 79

xiii

Figura 42. Prueba Unitaria de la Clase Producción ................................................................. 80 Figura 43. Prueba Unitaria de la Clase de Producción ............................................................ 80 Figura 44. Notificación en el panel principal........................................................................... 82 Figura 45. Notificación en la sección Materia Prima .............................................................. 82 Figura 46. Información que provee la Notificación – Materia Prima ...................................... 82 Figura 47. Notificación en la sección Productos. .................................................................... 83 Figura 48. Información que provee la Notificación – Productos. ............................................ 83

xiv

ÍNDICE DE ANEXOS

Anexo 1: Carta de Aceptación del Proyecto ............................................................................ 95 Anexo 2: Entrevista realizada al Gerente de empresa ............................................................. 96 Anexo 3: Encuesta aplicada al personal de la empresa............................................................ 99 Anexo 4: Acta de Capacitación en la administración del sistema ......................................... 101 Anexo 5: Carta de Impacto .................................................................................................... 102 Anexo 6: Acta de Entrega-Recepción del Proyecto ............................................................... 103 Anexo 7: Historias de Usuario ............................................................................................... 104 Anexo 8: Pruebas de Aceptación del Sistema........................................................................ 124

1

1. INTRODUCCIÓN En la actualidad, una de las mejores alternativas para las entidades comerciales que requieran llevar un control adecuado de la producción es el empleo de sistemas informáticos dado que los métodos tradicionales de registro resultan obsoletos, poco efectivos, y actualmente no son recomendados. El hacer uso de sistemas informáticos disminuye la carga de trabajo y facilitan enormemente las tareas que se llevan a cabo en las áreas Administrativa y de Producción en una empresa El desarrollo e implementación del Sistema Informático para la Gestión Administrativa y Control de Producción en la Fábrica de Bloques San Pedrito brinda información necesaria a la comunidad acerca de la institución y sus servicios prestados, por otro lado, automatiza y facilita el registro de datos concernientes a las actividades realizadas en la empresa, en cualquier momento que sea requerido y desde cualquier dispositivo que posea acceso a Internet, para su posterior uso en la toma de decisiones por parte de la gerencia, optimizando recursos y tiempo a la institución.

El desarrollo del presente trabajo de grado se ha realizado recabando información bibliográfica que sirva de sustento para la creación del mismo. El material bibliográfico es facilitado por la biblioteca de la “Pontificia Universidad Católica del Ecuador Sede Santo Domingo”, además, se ha empleado destacadas bibliotecas virtuales y lincografía fidedigna. Se somete a un proceso de síntesis y análisis el material recopilado, sustrayendo lo estrictamente necesario evitando en demasía llenar el mismo con formulismos innecesarios.

El presente trabajo se encuentra constituido de forma ordenada de tal manera que facilite su ubicación por medio de las siguientes secciones: En la primera sección se presenta la Introducción previo al desarrollo de las siguientes secciones.

En la segunda sección se presenta el Planteamiento del problema, que consiste en los antecedentes, problemática y justificación de la investigación. Además se exponen los objetivos de la investigación.

En la tercera sección constituida por el Marco Referencial se abordan todas las temáticas necesarias para realizar la presente investigación. Se abordan temáticas acerca de

2

Ingeniería de Software, Bases de datos, Herramientas y aplicaciones web y temáticas acerca de la gestión y control de producción En la cuarta sección se aborda la Metodología de Investigación, en donde se detallara el diseño de la investigación, población, muestra, instrumentos y técnicas de análisis de datos, elección de metodologías de desarrollo de software entre otros.

En la quinta sección se realiza el análisis y discusión de los datos, además, se ofrecen las conclusiones y recomendaciones que se han obtenido con el desarrollo de la presente investigación.

3

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Antecedentes La presente investigación se ha realizado en la Fábrica de Bloques San Pedrito, una empresa con 11 años en funcionamiento que se encarga de proporcionar los principales insumos para las construcciones de edificaciones de propósito general, buscando siempre ofrecer un producto de calidad a sus clientes. Dichos productos son bloques de las diferentes medidas para cada tipo de espacio de construcción en las obras, así como también ofrece adoquines vehiculares y peatonales.

La Fábrica de Bloques se creó a partir del apoyo de Monseñor Emilio Lorenzo Sthele, previamente existía la fábrica llamada “Santa Rosa” cuya administración fue otorgada a la Sra. Janeth Ocampo, luego de la partida del Monseñor Sthele hacia Alemania, la Sra. Ocampo decide emprender su propia empresa, creándose de este modo la Fábrica de Bloques “San Pedrito” el 20 de mayo del 2005. El 15 de julio de 2010 se crea una extensión que es donde actualmente opera, ubicada frente al Parque de la Juventud.

A fecha de realizar la presente investigación, la situación actual de la empresa consiste en que la administración lleva a cabo de forma manual los registros de las actividades que se realizan a diario en la misma, como por ejemplo: administrar los inventarios con demanda dependiente, los proveedores u otros elementos que intervienen en el proceso de elaboración de productos finales y su posterior comercialización. Esta forma de administración retrasa los procesos internos de la empresa y es susceptible la pérdida de la información.

Además, la empresa no posee presencia en Internet, es decir, no cuenta con un sitio web que por medio de éste administre sus procesos, brinde información acerca de la empresa, y de forma paralela dé a conocer la variedad de productos finales que son comercializados. Ello deriva en que las personas desconozcan la empresa y la gerencia administre sus procesos de forma manual.

4

2.2. Problema de investigación El presente proyecto de investigación responderá a la siguiente problemática: ¿Se mejorará la gestión administrativa y control de producción con el desarrollo e implementación de un sistema informático para la Fábrica de Bloques “San Pedrito”?

La Fábrica de Bloques “San Pedrito” es una empresa que se dedica a la elaboración y comercialización de productos finales destinados al sector de la construcción. A diferencia de otras entidades comerciales, ésta empresa no cuenta con un sitio web que brinde información a su clientela, además, la entidad lleva un control manual (se realizan anotaciones en un cuaderno) de todos los procesos que se ejecutan en la misma, como es la administración de inventarios de materias primas y de productos finales, el registro de la producción diaria, de los proveedores, de los clientes y de las ventas que se realizan.

Es evidente la ausencia de un sistema informático orientado a la web que unifique tanto la parte destinada a los clientes como la sección definida para la administración del sistema informático, el cual realice el control y el registro digital de las actividades antes mencionadas De acuerdo con Díaz, Pérez, & Florido (2015) la Internet es un medio que ayuda a la visibilidad de las instituciones, brindando la facilidad de contactar con todo mundo, no debe ser visto solo como una herramienta tecnológica. Y lo más relevante de todo es que la información está disponible y es accesible las 24 horas al día, todo el año (p. 13).

Tomando en cuenta este panorama, la presente investigación permitirá a responder las siguientes preguntas directrices: ¿Qué metodología se ajusta a los requerimientos de usuario para un rápido y eficiente despliegue del sistema? ¿Cuáles son los recursos y elementos necesarios para el desarrollo del sistema informático orientado a la web? ¿De qué manera un sistema informático facilita el manejo y administración de los inventarios en la empresa? ¿Cómo facilitar el proceso de la toma de decisiones en la empresa?

5

2.3. Justificación de la investigación Esta investigación está relacionada con el objetivo 4 del Plan Nacional del Buen Vivir el cual establece: “Fortalecer las capacidades y potencialidades de la ciudadanía” en la política 4.6 “Promover la interacción recíproca entre la educación, el sector productivo y la investigación científica y tecnológica, para la transformación de la matriz productiva y la satisfacción de necesidades”. Con ello se pretende dar un impulso tecnológico a la empresa en estudio y contribuir con la aplicación de conocimientos digitales a la misma.

Actualmente, las empresas hacen uso de varias herramientas tecnológicas con la finalidad de asegurar una cuota en el mercado, a través de estrategias que involucren dichas herramientas, amplíen sus servicios, optimicen sus procesos y mejoren la producción. La continua evolución tecnológica ha sido una condicionante para que muchas empresas hagan su migración a un mundo digital.

Es importante destacar que la inversión en tecnología añade un valor agregado a las instituciones, dado que su ausencia hace que la operación en las mismas no se realice de manera eficaz, por tal motivo, gracias al apoyo de herramientas informáticas, cualquier empresa puede tener una ventaja competitiva frente a otras empresas que se dediquen a la misma labor.

De igual manera, según Morejón, Collazo, Roque, & Iglesias (2014) con el empleo de sistemas informáticos los procesos en una empresa se automatizan, se optimiza el tiempo y se disminuyen costos de operación (p. 89). Las microempresas se desenvuelven en una sociedad tan competitiva por lo cual buscan maximizar ganancias y minimizar pérdidas. Éste es el caso de la Fábrica de Bloques San Pedrito, que siendo una empresa familiar, busca mejorar el control de sus procesos, optimizando tiempo y recursos.

Al ser la Fábrica de Bloques “San Pedrito” una entidad comercial, la base de su funcionamiento es el control de los productos, de esta manera surge la necesidad de manejar una herramienta tecnológica que controle el inventario de la organización. Es de vital importancia llevar un adecuado control de los inventarios en la entidad, de este modo, la gerencia cuenta con más información y se agiliza el proceso de toma de decisiones.

Las razones que determinan la importancia y justifican el desarrollo del sistema informático son: registrar y controlar los procesos o actividades que antes se realizaban manualmente, dado que a través del aplicativo se busca la optimización de tiempo, recursos y

6

procesos actuales, permitiendo conocer en tiempo real la información administrativa por parte de la gerente-propietaria y administrador de la Fábrica de Bloques San Pedrito.

El sistema es orientado a la web por razones de que el 47,6% en la área urbana de la población del Ecuador (Instituto Nacional de Estadísticas y Censos, 2013) hace uso del internet para buscar información de cualquier tipo, entonces teniendo información de la Fábrica como ubicación y precios los clientes pueden contactarse con la misma.

2.4. Objetivos de investigación 2.4.1.

Objetivo General Implementar un sistema orientado a la web para la gestión administrativa y control de

inventario de la Fábrica de Bloques “San Pedrito” en el periodo 2016-2017 2.4.2. Objetivos específicos 

Definir el tipo de metodología de desarrollo de software que se ajuste a los requerimientos para el desarrollo del sistema informático.



Determinar los recursos de desarrollo de software para la construcción de la base de datos, codificación y despliegue del aplicativo.



Diseñar interfaces amigables con el usuario para el manejo y control del sistema informático.



Desarrollar un sistema informático con generación de reportes para la toma de decisiones referente a la información de los inventarios que se manejan en la empresa.

7

3. MARCO REFERENCIAL Conceptos Básicos Desarollo de Software

Ciclo de vida del software Paradigma orientado a objetos

Características de POO Valores XP Programación Extrema

Matodologías tradicionales Metodologías Ágiles

Ingeniería de Software Metodologías de desarrollo

Principios de Scrum

¿Por qué usar métodos ágiles?

Comparación metodologías de desarrollo Modelado

Etapas del proceso XP

Scrum

Valores de Scrum

Ágil vs Tradicional

Proceso Scrum

Método 4-DAT

Patrón MVC

No-SQL Lenguaje SQL

MySQL WorkBench

Diagrama EntidadRelación

Power Designer

Base de datos

MariaDB Sistema Informático Orientado a la Web

Sistema Gestor de Base de Datos

PostgreSQL

Normalización

Microsoft SQL Server Cliente/Servidor

Arquitectura aplicación web Modelo en tres capas Aplicaciones Web Estáticas Tipos de aplicaciones Web Dinámicas HTMLS Y CSS Front-End

Editores de Código

JavaScript

Lenguajes de Programación Marco Referencial

PHP

Herramientas de desarrollo web

Back-End

JSP

ASP.NET Responsive Web Design Diseño Web

MaterializeCSS Frameworks de Diseño Bootstrap

Administración

Gestión Gestión Administrativa

Ventas

Control Proceso Administrativo Gestión y Control

Materia Prima Costo de producción

Mano de obra Costos indirectos de manufactura

Control de Producción

Tipos de inventarios Inventario Producción en proceso y producto terminado

Figura 1. Esquema de contenidos del Trabajo de Titulación

Inventarios con demanda dependiente Inventarios con demanda independiente

8

3.1. Revisión de la literatura o fundamentos teóricos 3.1.1. Ingeniería de Software El desarrollo de software es una tarea que debe ser llevada a cabo de manera profesional, cumpliendo con los propósitos del negocio. Por ello es que la Ingeniería de Software al ser un conjunto de métodos, técnica y/o herramientas, ayuda a desarrollar proyectos de manera profesional aplicando buenas prácticas apropiadas acorde al ciclo de vida del software, es por medio de la Ingeniería de Software que se captan los requerimientos, se plantea el diseño, se realizan pruebas y se despliegue el software asegurando en cada momento mantener la calidad, cumpliendo con la satisfacción del usuario final (Arias, 2015, pp. 74-75) 3.1.1.1. Desarrollo de software 3.1.1.1.1 Conceptos básicos Programa: es un software de aplicación y está conformado por varios factores con un mismo fin, siendo así un conjunto de instrucciones interrelacionadas entre sí para cumplir un objetivo específico en momentos determinados (Moreno, 2013, p. 22).

Variable: según Moreno (2013) las variables son espacios de memoria en el cual puede almacenar, borrar o modificar valores del tipo que se desee para su posterior uso durante la ejecución de un programa y gracias a este reservo de memoria un programa puede realizar operaciones con distintos valores guardados (p. 9).

Vector: conocido también como array permite hacer referencia a un conjunto de variables utilizando diferentes dimensiones en un mismo nombre y para localizar cada valor que se encuentre dentro del array se itera (Thierry, 2013, p. 23) Método: de acuerdo con Flórez (2012) los métodos son servicios incluidos en la clase y pueden ser visibles y utilizables del exterior de acuerdo a la seguridad del método, retorno de información, nombre del método y parámetros (pp. 26-27).

3.1.1.1.2 Ciclo de vida del software Comunicación: en esta fase se hace la recolección de requerimientos por parte del jefe de proyecto hacia el cliente, con el objetivo de que todos los integrantes del grupo de desarrollo estén informados de lo que se requiere y posteriormente realizar una planificación para el

9

despliegue del sistema. En esta sección se especifican los requerimientos para realizar las características y funciones del sistema. (Piattini, García, Rodríguez y Pino, 2012, pp. 184-185) Planeación: es la parte donde se clasifica y se especifican las tareas a realizar en el proceso de desarrollo de software para trabajar de manera óptima y eficaz teniendo como objetivo la calidad de software. De acuerdo con Sommerville citado en Rosado, Quintero y Meneses (2012) divide los trabajos, evalúa el esfuerzo, recursos requeridos para el desarrollo e implementación (p. 26).

Modelado: se manifiesta una perspectiva de cómo estará formado el sistema que se desea emplear junto con sus relaciones y si es necesario se reformula el bosquejo con más detalles, según Holmes & Kendall citado en Rosado et al. (2012) para una mejor comprensión de la problemática se apoya de documentación de los requerimientos os cuales ayudan a modular la problemática (p. 26).

Construcción: en esta sección se codifica el sistema utilizando los recursos necesarios como lenguajes de programación e iteraciones en el desarrollo, junto con las pruebas de cada módulo dependiendo de la metodología empleada (Báez y Suárez, 2013, pp. 50-51).

Despliegue: Una vez culminado el desarrollo del sistema con sus respectivas pruebas se pasa a la etapa de entrega del mismo al o los clientes, conocido también como transición y el consumidor examina el sistema para comprobar sus requerimientos (Báez y Suárez, 2013, p.

55).

3.1.1.1.3 Paradigma orientada a objetos Según López (2013) el paradigma orientado a objetos es una metodología de desarrollo que abarca estándares, teorías y métodos donde la organización de sus componentes es mediante objetos, en los cuales cada uno de estos es perteneciente a una clase. Siendo así un modo de organizar el pensamiento de los desarrolladores. La programación orientada a objetos (POO) es un paradigma de desarrollo y su metodologías es muy parecida a como hacemos las cosas acumulado sus iteraciones y objetos para el cumplimiento de un objetivo (p. 222).

3.1.1.1.3.1 Características de POO Abstracción: se basa en la recolección de características de los comportamientos de un objeto, y estos a su vez sirven como un modelo para realizar acciones, dar información, cambiar

10

de estado y comunicarse con otros objetos, siendo así uno de los procesos claves para el análisis y diseño orientado a objetos.

Encapsulamiento: permite agrupar todas las variables y métodos de un objeto en una sola clase con un mismo método de abstracción, a esto se le puede llamar como una caja negra, ya que se podrá hacer uso de sus características y comportamiento sin la necesidad de conocer como está estructurada internamente.

Modularidad: cuando se habla de modularidad se refiere al dividir algo complejo en partes sencillas conocido como módulos para un funcionamiento relacionado y dar solución al problema.

Principio de ocultación: varias veces se puede requerir del uso de estados o valores de variables para un proceso interno y estos no se desean que puedan ser modificados por externos, para esto surge la ocultación permitiendo el acceso solo a los métodos que estén dentro del mismo módulo (Pérez, Programación orientada a objetos y programación estructurada, 2015, p. 13).

Polimorfismo: significa varias formas y esta característica es una de las que ayuda a una ágil codificación por el motivo de que cuando se envían diferentes tipos de datos a una misma función, esta interpreta lo que debe hacer según los valores recibidos teniendo comportamientos diferentes a objetos distintos (López, 2013, p. 386).

Herencia: en ciertos casos existe la posibilidad de que una clase tenga los mismos estados y métodos o con varios agregados, en este caso se hace uso de la herencia ayudando a no escribir otra vez todo el código, sino solo heredar conocida como clase hija, por medio de la herencia se hace de una manera más sencilla la parte de polimorfismo.

Recolección de basura: también conocido como garbage collector es un método de POO que automáticamente destruye el valor en memoria asociada a todos los objetos que ya no tengan referencia, gracias a esto el desarrollador no debe preocuparse por la asignación o liberación de memoria (Pérez, 2015, p. 14).

3.1.1.2. Metodologías de desarrollo Todo el proceso de elaboración de software no es una tarea fácil como aparenta, es más, al realizarlo de una manera profesional se involucra una serie de etapas que en el

11

desarrollo de software no solo se limita a la codificación del mismo, sino que a la par se encuentra la parte documental que es el sustento de cualquier proyecto de software, y que brinda estandarización y normas que aseguran la calidad del mismo.

Es así que las Metodologías de Desarrollo surgen como herramienta de apoyo para los equipos de desarrollo de software. Las Metodologías de Desarrollo según Avison & Fitzgerald mencionado por Amaya (2013) son el conjunto de pasos ordenados, herramientas y documentos de apoyo que brindan soporte al desarrollador en su carrera por construir nuevos sistemas, de igual manera le permitirá planificarlo, gestionarlo, evaluarlo, etc., conforme se vaya avanzando en las fases que contenga una metodología en específico (p. 112).

3.1.1.2.1 Metodologías tradicionales Las metodologías tradicionales o metodologías formales fueron las primeras en ser utilizadas en los inicios del desarrollo de software por el motivo de que este se veía escaso de alguna que guiara su proceso, y estas, en un principio (y aún se mantienen así) aportaron a llevar un desarrollo ordenado de los proyectos. Este tipo de metodología según Brito y Héctor (2015) impone una disciplina rigurosa y se preocupa de llevar una planificación organizada del proyecto para posteriormente comenzar con el desarrollo del software (p. 27).

Las metodologías formales o disciplinadas tienden a exagerar el control de los procesos llevados a cabo en el trascurso o desarrollo del proyecto. Algunos ejemplos destacados de este tipo de metodología son: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), Capability Maturity Model Integration (CMMI), que se centran en llevar una alta estandarización y un lenguaje común con respecto a los componentes de un sistema (Gutiérrez, 2013, p. 53).

3.1.1.2.2 Metodologías ágiles Las metodologías de desarrollo ágil son modelos de desarrollo de software que tienen sus inicios muy recientes, aproximadamente en el año 2001, en donde un conjunto de expertos al ver que las metodologías tradicionales no satisfacían por completo o no servían en cuanto a nuevos problemas aparecieron al desarrollar software, resuelven establecer las bases de lo que hoy son las metodologías ágiles, las cuales ayudan a una entrega rápida e incremental del proyecto, siendo esta una alternativa a los modelos de desarrollo tradicional (Rosado et al., 2012, p. 25).

12

Este tipo de metodología al ser funcional en ambientes donde los requerimientos son cambiantes, simplifica el trabajo engorroso que se lleva a cabo en los modelos formales y elimina documentación innecesaria, culminando el proyecto en periodos más cortos. De acuerdo con Álvarez, de las Heras y Lasa (2012) la filosofía en que se basan los métodos ágiles es el Manifiesto Ágil. Con respecto a este último se puede destacar cuatro pilares fundamentales tales como valorar más el software que funciona, valorar a individuos y sus iteraciones, valorar más la colaboración con el cliente y valorar más la repuesta al cambio.

3.1.1.2.3 Programación Extrema La programación extrema o Extreme Programming –XP- por sus siglas en inglés, fue desarrollado por Kent Beck. Es uno de los métodos ágiles más renombrado, conocido y preferido para el desarrollo ágil de software. Es utilizado en proyectos pequeños o medianos con equipos de trabajo entre 2 a 10 miembros (Navarro, Fernández, & Morales, 2013, p. 34).

De acuerdo con Rosado et al. (2012) este tipo de metodología se centra en la simplicidad, la colaboración del cliente, el trabajo en conjunto, la reutilización de código entre otras afines al Manifiesto Ágil. XP hace uso de las buenas prácticas y su filosofía se basa en cuatro principios fundamentales los cuales son: 

Entregas de prototipos



Semana de 40 horas laborales



Colaboración activa del cliente



Programación en parejas

3.1.1.2.3.1 Valores XP Los valores en los que se basa la programación extrema son cinco, los cuales trabajando en conjunto logran un desarrollo ágil y eficaz del software, y al aplicarlos en un equipo de trabajo se provee una guía para el mejoramiento continuo del mismo. Los principios y prácticas de XP están asentados en valores tales como la comunicación, la retroalimentación, simplicidad, respeto y valentía (Measey, 2015, pp. 125-126). A continuacion se mencionan los valores XP con una breve descripción de cada uno según el autor previamente mencionado.

Comunicación: muchas de las prácticas de XP dependen de la comunicación empezando en tareas como la Planeación y Estimación que deben realizarse en conjunto. Aquí

13

no se emplean documentos en una sola vía como método de comunicación, simplemente diálogos verbales, derivando en realizar menos documentación en contraposición al modelo cascada. Se incita al equipo a programar en parejas, coadyuvar y a realizar pruebas unitarias.

Retroalimentación: una constante variación en lo requerimientos por parte del cliente requiere que se realicen retroalimentaciones cuando sea necesario. Como XP trabaja con iteraciones cortas, el equipo comúnmente recibe retroalimentación del cliente. Las pruebas unitarias muestran información del estado del código respecto a las salidas previstas, en cambio las pruebas de funcionalidad muestran la posición actual del desarrollo del proyecto.

Simplicidad: el éxito consiste en hacer algo lo más simple posible para que funcione.

Es decir, enfocarse solo en las características que realmente son necesarias en cada iteración, de este modo se cumple con el desarrollo veloz. Los equipos XP resuelven solo las necesidades actuales, no agregan funcionalidades o características adicionales previstas a futuro, pues esta predicción conllevaría a realizar trabajo extra (test, etc.) aumentando el costo y la complejidad.

Respeto: es el armazón que contiene a los demás valores, pues un equipo sin respeto está a la deriva. El respeto asegura la entrega de manera efectiva. El respeto se relaciona con la valoración a los individuos y las iteraciones, un pilar del Manifiesto Ágil. Respetándose uno mismo y a los demás miembros del equipo XP se promulga un ambiente de trabajo que produce confianza y valora cada contribución que una persona hace al equipo de trabajo.

Coraje: el coraje o valentía dentro de un equipo XP implica una de decisión frente algún evento o suceso. Coraje para aceptar los cambios o retos, coraje para empezar con un nuevo diseño, valentía al enfrentarse a errores y corregirlos, a la mejora continua del código tras cada retroalimentación. El coraje o valentía no se lo puede tomar como un valor por separado, puesto que se tomaría acciones precipitadas y negligentes. El aplicar los valores previos conlleva acciones valientes.

3.1.1.2.3.2 Etapas de la Metodología XP Es importante señalar que el flujo del proyecto en XP no se va a parecer a ningún otro desarrollado bajo esta metodología debido a la naturaleza misma de XP. De acuerdo con Navarro et al. (2013) XP posee cinco etapas o fases tales como la Exploración, Planeación, Iteración, Productionizing y Mantenimiento. Claro está, esto es lo ideal (XP versión original), así como lo explica de igual forma Kent Beck, pero este ciclo de vida puede reajustarse. Es así

14

que existen adaptaciones de las etapas de desarrollo, como se mencionan en Rosado et al.

(2012) en donde XP se ejecuta en cuatro fases que son: Planeación, Diseño, Desarrollo y Pruebas.

La Planeación consiste en recoger aquellas características o requisitos que sean necesarios y funcionales para el sistema. La etapa de Diseño sirve para evaluar las historias de usuario y construcción de tarjetas CRC. Después en la etapa de Codificación o Desarrollo es en donde se produce la codificación de la información, aquí se trabaja en conjunto con el cliente donde este resolverá cualquier duda con respecto a la funcionalidad del sistema o del negocio.

Para finalizar se realizan Pruebas por cada característica del sistema (pruebas unitarias) que las realizan los programadores (Rosado et al., 2012, pp. 25-26).

Figura 2. Etapas del Proceso XP. Fuente: Rosado, A., Quintero, A., & Meneses, C. (2012). Desarrollo ágil de software aplicando programación extrema. Ingenio, 5(1), 24-29. Obtenido de http://revistas.ufpso.edu.co/index.php/ringenio/article/view/23/10

3.1.1.2.4 Scrum Scrum pertenece a la familia de metodologías ágiles, por lo cual se garantiza que el trabajo no rechace modificaciones o mejoras una vez avanzado el proyecto. Para que Scrum funcione hace falta técnica y comunicación por parte del equipo de desarrollo para cumplir con los objetivos de una organización (Lee, 2012, pp. 367-368). Cabe recalcar que Scrum se practicó mucho antes de que el Manifiesto Ágil sea declarado y por ende deje por sentado las bases de la Metodología Ágil. Scrum se introdujo en el año 1995, y posteriormente se añadió

15

a la gama de metodologías ágiles dado que compartía la misma línea conceptual. Scrum simplifica la gestión del proyecto con procesos sencillos (Iqbal & Javed, 2014, p. 296).

Scrum da paso a la creatividad del equipo desarrollador, basándose en la administración propia. Las iteraciones son otra característica esencial en los modelos ágiles de desarrollo. En el caso de Scrum, las iteraciones se las denominan Sprints, las cuales poseen una duración pequeña y que además aseguran resultados de alta calidad. Actualmente se está empleando muy a menudo Scrum debido a su confiabilidad y gran desempeño en proyectos de alta complejidad (Álvarez et al., 2012, p. 39).

3.1.1.2.4.1 Principios de Scrum Como se ha mencionado anteriormente, Scrum es un marco de desarrollo que emplea la iteración y la entrega incremental de productos. De acuerdo a lo mencionado en la Scrum Alliance Organization (2016) por parte de los creadores de Scrum, Jeff Sutherland y Ken Schwaber, este framework se basa en tres pilares fundamentales que guían su buen desarrollo: 

Transparencia: como su nombre lo indica, todos los aspectos y procesos que se involucran deben ser visibles a todos los partes interesadas en los resultados.



Inspección: las inspecciones que se llevan a cabo en cada Sprint deben ser realizadas por personas cualificadas, estas inspecciones deben ser oportunas para comprobar el correcto avance de un producto.



Adaptación: si algún proceso se está desviando fuera de lo aceptable, entonces se determina realizar un ajuste que minimice la desviación de los objetivos.

3.1.1.2.4.2 Valores de Scrum Scrum emplea valores como la apertura, el coraje, compromiso, el enfoque y respeto para llevar una gestión eficiente del proyecto. Los principios Scrum cobran vida generando confianza entre los miembros cuando los valores se cumplen dentro del equipo Scrum, El equipo de trabajo que emplee Scrum se compromete a cumplir con las metas del grupo, posee el valor de enfrentarse a desafíos difíciles, se centran en cumplir con el trabajo y objetivos del equipo, posee apertura a nuevos retos que se presenten en el trabajo y existe respeto recíproco entre cada miembro del equipo logrando competencia e independencia (Scrum Alliance Organization, 2016)

16

3.1.1.2.4.3 Etapas del proceso Scrum Todo el proceso de desarrollo en Scrum se centra en el sprint. El proceso empieza con la recolecta de datos en lo que se denomina lista de productos o product backlog. Conforme se crea un product backlog se crea a la par un sprint backlog o lista de pendientes del sprint. Cada sprint se desarrolla mientras que de manera simultánea se realizan los daily meeting o reuniones Scrum diarias. Las reuniones tienen como finalidad examinar el avance del proyecto y los problemas que se susciten en el desarrollo del sprint. El proceso termina con la finalización del sprint, entregando de este modo un producto terminado (Ghani, Bt, Azham, Izzaty, & Ryul, 2014, p. 294).

Figura 3. Modelo del proceso Scrum.

Fuente: Ghani, I., Bt, A., Azham, Z., Izzaty, N., & Ryul, S. (2014). Integrating Security into Agile Models: Scrum, Feature-Driven Development (FDD), and eXtreme Programming (XP). En I. Ghani, W. Nasir, & M. Nazir, Advances in Systems Analysis, Software Engineering, and High Performance Computing : Handbook of Research on Emerging Advancements and Technologies in Software Engineering (págs. 293-308). Hershey: IGI Global

3.1.1.2.5 ¿Por qué utilizar metodologías ágiles?

Las metodologías ágiles se adaptan con facilidad a los cambios en los requerimientos por parte del cliente diferenciándose con los métodos tradicionales, en los cuales se debe especificar previamente y tener claro los requerimientos del sistema. Cómo y cuándo debe emplearse metodologías ágiles, Wadhwa & Sharma (2015) nos indica que es conveniente aplicarlas cuando se requieran implementar nuevos cambios al software, lo que se traduce en libertad para los desarrolladores al momento de realizar algún cambio en el mismo, esto no implicaría perden gran parte de los avances, solo se retrasa una pequeña parte del avance mas no todo el proyecto, como sucedía con los modelos convencionales (p. 373).

17

3.1.1.2.6 Comparación entre metodologías de desarrollo Las Metodologías de desarrollo de software son parte fundamental en la Ingeniería de Software dado que estas conforman un marco de trabajo para el desarrollo de un proyecto, asegurando que a través del cumplimiento de cada una de las etapas que la componga se obtenga un desarrollo exitoso del mismo. La correcta elección de entre una gama amplia de metodologías de desarrollo se debe realizar de una manera minuciosa, atendiendo a la naturaleza del proyecto, a la especificación de requerimientos, tiempo, magnitud del proyecto, tamaño del equipo de desarrollo entre otros aspectos importantes que condicionarán nuestra operación.

3.1.1.2.6.1 Metodología Ágil vs Metodología Tradicional Tabla 1.

Comparación entre Metodologías.

Criterios Enfoque de desarrollo Requerimientos.

Adaptabilidad Retroalimentación Pruebas

Metodología Ágil Modelo incremental f Requerimientos mejor especificado por parte del usuario a Rápida respuesta y bienvenida al cambio c Integración continua d

c

Enfoque proactivo para prevenir errores

Metodología Tradicional Enfoque Lineal y Secuencial e Requerimientos descritos al inicio del proyecto e inalterables e Cumplimiento del plan especificado. No se adapta a circunstancias cambiantes. b El feedback se obtiene en el punto más alejado del proyecto. c Enfoque reactivo para corregir errores c

Nota: Fuente: a Brito, K., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. USA: Editorial Académica Española., b Cusick, J. (2013). Durable Ideas in Software Engineering: Concepts, Methods and Approaches from My Virtual Toolbox. New York: Bentham E-Books., c G. Cobb, C. (2015). The Project Manager´s Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken: John Wiley & Sons., d Measey, P. (2015). Agile Foundations : Principles, practices and frameworks. Swindon: The British Computer Society., e Morien, R. (2014). Back to the Basics: In Support of Agile Development. En I. Ghani, W. Nasir, & M. Nazir, Advances in Systems Analysis, Software Engineering, and High Performance Computing : Handbook of Research on Emerging Advancements and Technologies in Software Engineering (págs. 279-292). f Hershey: IGI Global., Warren, C. (2013). Engineering Safe and Secure Systems. Norwood: Artech House.

Como se observa, se ha realizado una comparación entre Metodologías Tradicionales y Metodologías Ágiles, y atendiendo a la Volatilidad de los requerimientos de usuario y Capacidad de adaptabilidad al cambio, se procedió a elegir una Metodología Ágil que asegure el cumplimento de estos parámetros en primera instancia. Por otro lado, dado que las Metodologías Ágiles poseen un amplio abanico de opciones para elegir, según criterios preestablecidos se elegirán las metodologías a examinar haciendo uso de la herramienta de evaluación analítica de Metodologías Ágiles, el 4-DAT.

18

3.1.1.2.6.2 Herramienta de comparación 4-DAT La Herramienta de evaluación 4-DAT o Four Dimensional Analytical Tool, consiste en una técnica propuesta y desarrollada por Qumer y Henderson (2006) para examinar o realizar una medición de la agilidad y capacidad de adaptabilidad de los Métodos Ágiles. Esta herramienta concibe a los Métodos de Desarrollo de Software en cuatro dimensiones. Aquí, en estas dimensiones, se analizan los métodos donde solamente una dimensión es de carácter cuantitativo, las demás son de aspecto cualitativo pero que consiste en criterios de aceptación o cumplimiento por parte de las Metodologías.

Dimensión 1. Caracterización del alcance del Método: en esta dimensión se compara elementos clave de los Métodos Ágiles que se elijan. Compara las metodologías en un nivel alto.

Figura 4. Criterios de comparación en Dimensión 1.

Fuente: Qumer, A., & Henderson-Sellers, B. (2006). Measuring agility and adoptability of agile methods: a 4dimensional analytical tool. En N. Guimarães, P. Isaías , & A. Goikoetxea, Proceedings of the IADIS International Conference on Applied Computing (págs. 503-507). San Sebastian: IADIS

Dimensión 2. Caracterización de la Agilidad: aquí se especifican una serie de características referentes a la agilidad basadas en los trabajos de Qumer y Henderson (2006).

En esta dimensión se mide el grado de agilidad de un método tanto a nivel de proceso como a nivel de prácticas. Esta dimensión es cuantitativa.

Figura 5. Criterios de comparación en Dimensión 2.

Fuente: Qumer, A., & Henderson-Sellers, B. (2006). Measuring agility and adoptability of agile methods: a 4dimensional analytical tool. En N. Guimarães, P. Isaías , & A. Goikoetxea, Proceedings of the IADIS International Conference on Applied Computing (págs. 503-507). San Sebastian: IADIS

19

Dimensión 3. Caracterización de los Valores Ágiles: se realiza una comparación entre una serie de parámetros que tiene relación con los valores ágiles propuestos en el Manifiesto Ágil. En específico se analizan 6 valores ágiles, donde el quinto es propuesto por Koch (2005) y el último es propuesto por Qumer y Henderson (2006)

Figura 6. Criterios de comparación en Dimensión 3.

Fuente: Qumer, A., & Henderson-Sellers, B. (2006). Measuring agility and adoptability of agile methods: a 4dimensional analytical tool. En N. Guimarães, P. Isaías , & A. Goikoetxea, Proceedings of the IADIS International Conference on Applied Computing (págs. 503-507). San Sebastian: IADIS

Dimensión 4. Caracterización de los procesos de Software: en esta dimensión existe una serie de componentes referentes al proceso de software dividiendo el proceso en dos grandes grupos: Proceso de ingeniería de productos y Proceso de Gestión de procesos.

Figura 7. Criterios de comparación en Dimensión 4.

Fuente: Qumer, A., & Henderson-Sellers, B. (2006). Measuring agility and adoptability of agile methods: a 4dimensional analytical tool. En N. Guimarães, P. Isaías , & A. Goikoetxea, Proceedings of the IADIS International Conference on Applied Computing (págs. 503-507). San Sebastian: IADIS

3.1.1.3. Modelado 3.1.1.3.1 Patrón MVC El patrón Modelo-Vista-Controlador es una arquitectura de diseño que es muy frecuentada al realizar aplicaciones con interfaces gráficas de usuario. La característica principal es la separación de los datos, el modelo y la lógica de negocio. Al realizar esta separación se hace uso del principio del Modelo de Capas, al separar la Vista del Modelo y el Controlador que las relaciona, manteniéndose de este modo la integridad e independencia entre

20

las divisiones o capas. Son varias las ventajas que trae el emplear este tipo de patrón, como por ejemplo diseñar varias vistas para un mismo modelo, los cambios se replican fácilmente en las interfaces, facilidad de sustitución de interfaces entre otras (Camarena, Trueba, Martínez y López, 2012, p. 240).

Figura 8. Patrón Modelo-Vista-Controlador.

Fuente: Camarena, J., Trueba, A., Martínez, M., & López, M. (2012). Automatización de la codificación del patrón modelo vista controlador (MVC) en proyectos orientados a la web. Ciencia, 19(3), 239-250. Obtenido de http://cienciaergosum.uaemex.mx/index.php/ergosum/article/view/796/576

3.1.2. Base de Datos La base de datos se puede definir con un conjunto de información relacionada, agrupada o estructurada de acuerdo con los requerimientos que se han obtenido en el Análisis. Los aspectos a tomar en cuenta en las bases de datos son la velocidad que tendrá para acceder a los datos almacenados, el tamaño de los datos y la facilidad de accesos de la información. Para un diseño de la base de datos se utiliza el diagrama Entidad-Relación que está compuesto por entidades, relaciones y atributos. Son dibujos que ayudan al entendimiento relacional.

(Sigüenza, 2015, pp. 33-37) 3.1.2.1. NO-SQL El NoSQL (Not Only SQL) es una nueva forma de realizar las bases de datos que en los últimos años ha adquirido gran importancia, entre los principales gestores de base de datos de este tipo tenemos a Redis, Cassandra y MongoDB. Difieren de las clásicas bases de datos relacionales en su estructura como en el tipo de relaciones que manejan y la forma como interactúan los datos. Las bases de datos NoSQL se emplean comúnmente cuando se manejan grandes volúmenes de datos (Fernández, 2013, p. 180).

21

3.1.2.2. Lenguaje SQL SQL o Lenguajes de Consulta Estructurada (Structured Query Language) es un lenguaje para la gestión de base de datos ayudando a que los sistemas sean dinámicos permitiendo interactuar con los usuario y fue estipulado por D. D. Chamberli en la última década de los 70 en el cual se lo conocía como SEQUEL (Structured English Query Language) diseñado acoplado con el prototipo de bases de datos relacional System R. de IBM, luego comenzaron a salir varias firmas comerciales para SQL como consecuencia de esto el Instituto de Normalización Americano ANSI estableció una normativa en la cual los productos acepten a SQL embebido (Pérez, MySQL Diseño, Programación y Administración de Bases de Datos, 2015, p. 32).

DML: Según López, Castellano y Ospino (2013) DML (Data Manipulation Languaje) lenguaje de manipulación de datos permite realizar cuatro operaciones en la base de datos como seleccionar utilizando SELECT, INSERT para insertar un registro, UPDATE que actualiza datos y DELETE para borrarlos (p. 16).

DDL: El lenguaje de definición de datos (Data Difinition Language) las sentencias dentro de este lenguaje son CREATE, DROP, ALTER y RENAME las cuales hacen las acciones de crear, borrar, alterar y cambiar de nombre a objetos (Reinosa, Maldonado, Muñoz, Damiano y Abrutsky, 2014, p. 106).

DCL: el Lenguaje de control de datos (Data Control Language) permite al administrador gestionar a los usuarios el acceso a los datos de la base de datos, esto gracias a las sentencias GRANT y REVOKE que son de ayuda para auditoría de la base de datos (López et al., 2013, p. 17).

3.1.2.3. Diagrama entidad relación Este modelo consiste en representar el problema mediante un diagrama, el cual fue propuesto por Peter P. Chen a mediados de los años 70 con el fin de realizar una representación conceptual de los datos y las relaciones existentes, siendo así una manera sencilla de representar el mundo real agrupados en entidades donde cada una de estas representa la información de personas, cosas, etc. Las entidades se las representa mediante rectángulos con una sola línea si es una entidad fuerte y con doble línea en caso de ser una entidad débil con su nombre dentro y solo pueden estar una vez en todo el diagrama. Y para realizar una correspondencia entre las

22

entidades se usan las relaciones emitidas mediante correspondencia o participación para poder identificar si es una entidad fuerte o débil (López et al., 2013, pp. 42-44)

Figura 9. Ejemplo de Diagrama Entidad-Relación de una biblioteca.

Fuente: Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo

3.1.2.3.1 MySQL Workbench Workbeanch es una herramienta para el modelado, diseño, desarrollo, generación y administración de base de datos, además incorpora todos los componentes necesarios para realizar los modelos entidad relación y a partir de estos generar el script mysql, caso contrario, en el que se desee codificar, el software incluye auto-completado, color de resaltado en sintaxis, reutilización de fragmentos sql e historial de ejecución (Oracle Corporation, 2016) 3.1.2.3.2 PowerDesigner SAP PowerDesigner es una herramienta de pago para la gestión de datos y base de datos. Es un software robusto que permite realizar modelos de la arquitectura de la empresa, gestionar y visualizar el impacto de los cambios en la misma, entre otras características.

Soporta varios tipos de modelado de datos, admite alrededor de 80 SGBD Relacionales, ofrece herramientas para el diseño, manipulación, visualización de metadatos, y características de Bussiness Intelligent (SAP SE, 2014).

3.1.2.4. Sistemas Gestores de Base de datos 3.1.2.4.1 MariaDB MariaDB es un SGBD del tipo no privativa, es decir, que es open-source (software desarrollado y distribuido libremente). MariaDB fue desarrollada por los fundadores originales

23

de MySQL, además, se trata de un reemplazo directo a MySQL (actualmente de Oracle) garantizando permanecer open-source. Al ser un fork directo de MySQL, posee una alta compatibilidad con este último dado que posee las mismas estructuras, interfaces, bibliotecas, etc., lo que facilita poder cambiar de un servidor por otro directamente. Es escalable, robusto, posee grandes mejoras respecto a MySQL y muchas más herramientas que lo hacen muy versátil al usarlo (MariaDB Foundation, 2016).

3.1.2.4.2 PostgreSQL Este sistema es considerado como el más avanzado en el mundo por su gestión de base de datos objeto-relacional, multiusuario, centralizado y de propósito general. Tiene características útiles cuando concibe una herramienta de mapeo de objeto relacional (ORM) para servir como intermediario entre la base de datos y el modelo orientado a objetos. Incluye comportamientos para el manejo de las colecciones de registros en los campos de las tablas o más conocido como Non-First Normal Form. (Pérez & Ávila, 2014, pp. 3-4) 3.1.2.4.3 Microsoft SQL Server SQL Server es la base de datos de tipo relacional de la línea de productos para desarrollo de Microsoft. Ésta es una base de datos de licencia privativa caracterizada por usar el lenguaje Transact-SQL, que mueve las sentencias y peticiones al servidor. Posee varias ediciones, con limitaciones y funcionalidades extras dependiendo de la edición seleccionada. Hasta la edición Microsoft SQL Server 2014 sólo era posible su uso en estaciones de trabajo Windows, por otro lado, la versión SQL Server 2016 amplía su uso a sistemas Linux y MacOS (Microsoft, 2016).

3.1.2.5. Normalización Como lo menciona Reinosa et al. (2014) la normalización es uno de los parámetros más importantes en el diseño de base de datos y se lo puede definir como el modelado de la base de datos relacional, su estructura relacional válida, como está estructurada los datos por el concepto de atributo, que estos no poseen una estructura interna, eliminación de redundancia de datos, facilita el control de la manipulación de datos y tiene una estructura lógica que sea fácil de mantener y entender (pp. 64-65).

24

3.1.2.5.1 Primera forma normal En esta primera forma normal hace referencia a que los componentes sean atĂłmicos, en otras palabras que no tengan grupos repetidos como un atributo o conjunto de atributos con datos mĂşltiples, y para eliminar esta cuestiĂłn se puede optar por agregar una nueva entidad relacionada a la afectada (PiĂąeiro, 2013, pp. 51-52).

3.1.2.5.2 Segunda forma normal De acuerdo con LĂłpez et al. (2013) Un diseĂąo se encuentra en la segundo forma normal si cumple con la primera forma y cada uno de los atributos de una entidad corresponde directamente con la principal, esto quiere decir que si tenemos una entidad dĂŠbil la cual tiene la clave de otra entidad fuerte, esta entidad dĂŠbil no debe tener los atributos de la entidad fuerte (p. 76).

3.1.2.5.3 Tercera forma normal Para cumplir con el diseĂąo de la tercera forma normal ademĂĄs de cumplir con la segunda forma no debe tener dependencia transitiva, lo que quiere decir es que si un atributo de la entidad depende de otro atributo que no es la clave primaria, entonces no estĂĄ cumpliendo con la tercer forma y para solucionarlo se debe crear otra entidad teniendo como clave primaria al atributo de dependencia (PiĂąeiro, 2013, p. 54) 3.1.2.5.4 Forma normal de Boyce, Codd (FNBC) De igual manera de las formas normales mencionadas anteriormente, FNBC requiere que se cumpla la tercera forma formal y al mismo tiempo todo determinista es clave primaria, caso contrario quiere decir que una no cumple por el motivo de que un atributo puede estar en varias de una misma clave, y para la soluciĂłn se debe separar la que no es determinista (PiĂąeiro, 2013, pp. 55-56).

3.1.2.5.5 Cuarta forma normal De acuerdo con PiĂąeiro (2013) se encarga de los atributos multivaluados, esto significa que ocasionan problemas en el mantenimiento de las relaciones a las cuales representa, por ejemplo una relaciĂłn R (X, Y, Z) donde đ?‘‹ → đ?‘Œ y đ?‘‹ → đ?‘? se encuentra doble dependencia, para solucionarlo se crean relaciones independientes como R (X, Y) y R (X, Z) (pp. 56-57).

25

3.1.3. Aplicaciones Web 3.1.3.1. Arquitectura de aplicaciones web 3.1.3.1.1 Cliente/Servidor La arquitectura Cliente/Servidor es el modelo más empleado respecto al desarrollo de aplicaciones informáticas. Así como nos explica Cusick (2013) actualmente muchos de los sistemas, en especial la mayoria de las aplicaciones web, se desarrollan bajo este tipo de arquitectura cliente/servidor. La característica principal de esta arquitectura es la separación en capas (capa cliente y capa servidor) en donde la capa del cliente realiza peticiones de informacion o servicios a la capa del servidor y este envia la respuesta al cliente, es más, pueden comunicarse con otros clientes o servidores (p. 139).

Figura 10. Esquema Cliente/Servidor.

Fuente: López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & De Castro, V. (2012). Desarrollo Web en entorno servidor. Madrid: Ra-Ma

3.1.3.1.2 Modelo en tres capas Es una variante del modelo cliente/servidor en el cual se añade una capa intermediaria entre el cliente y el servidor. En otras palabras, la parte del servidor se divide en dos (servidor de aplicaciones y servidor de datos) consiguiendo de este modo compartir la carga de trabajo.

En esta arquitectura la capa del cliente se dedica a la presentación de información y envío de peticiones de recursos a la capa siguiente que es la capa del servidor de aplicaciones, en esta capa se procesa la lógica del negocio, es decir sirve de nexo entre la capa de presentación y la capa de datos, esta última normalmente es un servidor de datos que proporciona los datos que el servidor de aplicación solicita. (Ferrer, 2014, pp. 23-24)

26

Figura 11. Arquitectura en tres capas.

Fuente: Ferrer, J. (2014). Implantación de aplicaciones web. Madrid: Ra-Ma

3.1.3.2. Tipos de aplicaciones web 3.1.3.2.1 Estáticas Las aplicaciones web estáticas se caracterizan por ser básicamente informativas o de solo lectura, es decir que se limitan a presentar información de forma permanente al usuario final, además no poseen una interacción directa con el usuario final. En este tipo de web estático, las páginas poseen links o enlaces que redirigen al usuario hacia otras páginas web.

Debido a su incapacidad para la interacción entre usuario y página visitada las web estáticas poseen un enfoque netamente informativo. Los foros de ayuda en línea son un claro ejemplo de web estática. (Zofío, 2013, p. 7) 3.1.3.2.2 Dinámicas.

Las web dinámicas se caracterizan principalmente por soportar interactividad con el usuario final. Son comúnmente denominadas aplicaciones web por el motivo de la interacción del usuario con los datos que se generan en la página. Debido a que existe una comunicación fluida entre la aplicación y el usuario, la información que se presenta a este último es a partir de peticiones que el usuario realice a la aplicación, de este modo se mantiene actualizada la información mostrada. Empleando la web dinámica se puede gestionar base de datos, enviar formularios, jugar en línea, chatear, etc. (Zofío, 2013, p. 7).

27

3.1.4. Herramientas de desarrollo web 3.1.4.1. Editores de código 3.1.4.1.1 SublimeText 3 SublimeText es un editor de texto y de código fuente que destaca por su solidez, elegancia, flexibilidad y alto rendimiento a la hora de su ejecución. Está disponible en su página oficial para su descarga y evaluación de forma gratuita, además ofrece una versión de pago para su uso continuo, aunque la versión de prueba no posee una fecha límite de vencimiento y funciona completamente. Algunas de las características principales son su amplia documentación y soporte por parte de su equipo de desarrollo, modo libre de distracciones, carga de plugins, fácil organización e intercambio entre proyectos, restauración y guardado instantáneo de los cambios, soporte multiplataforma entre otros. (Sublime Text, 2016) 3.1.4.1.2 NotePad ++ Notepad++ es un editor de código de acceso libre escrito en C++ que funciona únicamente bajo entornos del sistema operativo Windows debido al uso combinado de la API Win32 y STL, con lo que se consigue que su ejecución sea más rápida y el tamaño del programa se reduzca. Esto deriva en un uso eficiente de los recursos y de la energía del computador contribuyendo de este modo al medio ambiente, así aseguran en su página oficial. Notepad++ surge como reemplazo al clásico Block de Notas y trae consigo un amplio soporte para una gran cantidad de lenguajes. Posee una interfaz muy personalizable, vistas múltiples y soporte de pestañas en la apertura de documentos, zoom, autocompletar entre otros.

3.1.4.2. Lenguajes de Programación 3.1.4.2.1 Front-End 3.1.4.2.1.1 HTML5 y CSS HTML

es el acrónimo de HyperText Markup Language, es un lenguaje de

programación diferente a los comunes, dado que no emplea instrucciones sino un conjunto de etiquetas que organiza el documento final, lo cual deriva en la flexibilidad al interactuar con la Web. HTML5 (evolución del HTML) proporciona estructura, estilo y funcionalidad, lo cual se ve reflejado en el navegador en donde se ejecuta (Gauchat, 2013, p. 25).

28

Pero no basta con tener un documento bien estructurado, también debe incluirse el formato o diseño para que sea vistoso y amigable con el usuario final, al fin y al cabo, es este último el que lo utilizará y dependiendo de su presentación el usuario permanecerá en el aplicativo. Es así como nos menciona Gauchat (2013) que se debe combinar estos dos aspectos, el diseño (funcionalidad) y la estructura (organización), de este modo HTML se fusiona con CSS, combinando la estructura que la pone HTML y los estilos o presentacion que los coloca CSS. Las hojas de estilo o CSS ayudan a enriquecer el aspecto visual de una aplicación web eligiendo entre una multitud de opciones de presentación como colores, tipos y tamaños de letra, etc. (p. 57) 3.1.4.2.1.2 JavaScript Para el desarrollo web de un sitio o aplicación es necesario hacer uso de lenguajes de programación orientado a la web. Uno de los leguajes es JavaScript el cual es orientado a objetos, permite realizar funciones. JavaScript mejora la apariencia y funcionalidad de una aplicación web, permite mostrar mensajes de alerta hacia el usuario, además otra de las funcionales es que puede extender librerías de C++. (Sprimont, Ricci, & Nicastro, 2014, 77) 3.1.4.2.2 Back-End 3.1.4.2.2.1 PHP PHP es el acrónimo de Php Hypertext Preprocessor, es un lenguaje de programación open-source frecuentemente utilizado para desarrollar aplicaciones enfocadas a la web. PHP es un lenguaje muy flexible del lado del servidor dado que provee un entorno de desarrollo capaz de manejar gran cantidad de transacciones y procesamiento de documentos en línea de forma rápida. Otra características importante es que brinda soporte para el paradigma orientado a objetos (Ali & Agarwal, 2016, p. 593).

3.1.4.2.2.2 JSP JavaServer Pages permite el desarrollo y despliegue de aplicaciones web dinámicas de forma rápida. El formar parte de la plataforma Java asegura la independencia de sistema operativo en donde se ejecute la aplicación web (Oracle, 2016). De acuerdo con López et al.

(2012) este lenguaje es semejante a PHP respecto a embeber parte del código Java con código HTML. Su interpretación varía cuando el módulo que ejecuta la página JSP verifica el código

29

Java, éste se transforma en un servlet, se carga en memoria del servidor, se ejecuta y se envía al cliente (p. 18).

3.1.4.2.2.3 ASP.NET Es la tecnología de Microsoft para el desarrollo de aplicaciones web de lado del servidor. ASP.NET pertenece al framework .NET de Microsoft, y al formar parte de éste tiene acceso a todas las funcionalidades que el framework admita. El lenguaje en el que se codifique una aplicación ASP.NET debe ser compatible con el Common Language Runtime (CLR), como por ejemplo VBScript, C# entre otros, de este modo las características como seguridad, herencia que el CLR posea, se replican en la aplicación (Microsoft, 2016).

3.1.4.3. Diseño web El diseño web es la forma de aplicar estructuras y técnicas que hacen posible que las páginas de una aplicación web se vinculen y muestren información. Para el diseño, muchos sitios en internet ofrecen plantillas pre-fabricadas, pero en muchos casos, los amantes del diseño prefieren aplicar sus propios estilos, ya sea pagando por un trabajo a la medida o realizándolos ellos mismos. La parte del diseño y contenido hablan por el aplicativo web. Si está bien diseñado, se denotará el profesionalismo, cuidado y dedicación que se dio al diseño, y por ende, dará una sensación más realista al usuario final (Mavlanova, Benbunan, Koufaris, & Lang, 2015, p. 22).

3.1.4.3.1 Responsive Web Design El Responsive Web Design (RWD) es una metodología de combinación de diseños, plantillas y una exigente forma de uso de los script se cascada CSS con el fin de que los dispositivos de los usuarios que interactúen con un sitio en el que se haya elaborado con RWD no pierdan la información que están revisando ya que lo que busca RWD es que todo sitio web se adapte a los diferentes tipos de pantallas que pueden existir. EL uso de esta metodología posibilita el mantenimiento en un futuro, elimina la creación de otro sitio web para móviles, ya que el mismo sitio web se adapta al dispositivo sin perder la confiablidad de la información, y los compones se moverán en el sitio para la interacción con los usuarios (Manso, Cañizares y Febles, 2016, pp. 103-104)

30

3.1.4.3.2 Frameworks de diseño 3.1.4.3.2.1 Materialize Materializecss es un framework de diseño web basado en el modelo Material Design de Google. Materialize ofrece componentes HTML, CSS, JS que brindan un diseño moderno y adaptativo al front-end de los sitios web. Facilita una amplia documentación y ejemplos de código para quienes estén iniciándose con el framework. Con la aplicación de los principios de Material Design se consigue desarrollar aplicaciones universales y mejorar la experiencia de usuario. De igual forma se presenta elementos mejor diseñados y más agradables basándose en una perspectiva Material (espacio-movimiento) del mundo (Materialize, 2016).

3.1.4.3.2.2 Bootstrap Es el más popular para el diseño y construcción de aplicaciones web. Contiene una serie de herramientas como HTML, CSS Y Javascript que facilita el desarrollo adaptativo y móvil.

Está disponible en su página oficial para su descarga gratuita. Posee un amplio soporte y documentación por parte del equipo desarrollador, además agiliza el diseño front-end de la aplicación, está diseñado para soportar varios dispositivos, reduce la carga de trabajo y posee varias características, funcionalidades y componentes personalizables. (Bootstrap, 2016) 3.1.5. Gestión Administrativa 3.1.5.1. Administración La administración es función más importante en cualquier organización por ser el método más efectivo para garantizar la permanecía y competitividad con otras empresas, además está enfocada en realizar los objetivos con máxima calidad, para lo cual cuenta con técnicas y procesos para lograr mayor efectividad, simplificación y rapidez en los labores ahorrando tiempo y costo (Münch, 2014, p. 21).

3.1.5.2. Gestión La gestión es el conjunto de acciones, trámites interrelacionados con otras para alcanzar un objetivo en específico emitido por la gerencia o personal que está dispuesto para realizar este tipo de tareas y en algunos casos según las políticas de la empresa se opta por la realización de informes con respecto a cada una de las gestiones realizadas (Martínez, 2012, p. 11).

31

3.1.5.3. Ventas Según Blanco (2012) las ventas son acciones emitidas por organizaciones que ofrecen un servicio o un bien al público a lo cual se le determina demanda, y para asegurar que las personas compren sus productos o adquieran sus servicios se deben emplear métodos para alcanzar el su mercado meta y ya que los demandantes cada día son más exigentes, la organización deben realizar un mejora de sus producto o aumentar el portfolio (pp. 27-18).

3.1.5.4. Control El control es la acción de conducir los actos sujetos predeterminados patrones, con el fin de lograr los resultados deseados, en otras palabras el control es adaptar los eventos para concebir los planes planteados o comprobación de los mismos, los cuales pueden ser objetivos (Montes, Montilla, y Mejía, 2014, p. 45).

3.1.5.5. Proceso Administrativo Según Münch (2014) la administración está compuesta por varias etapas con el fin de aplicar métodos, principios y técnicas de gestión, dividida en la fase estructural en la cual se determina la mejor forma de obtener unos fines u objetivos y la fase operacional que se encarga de realizar lo que se estableció es la fase de estructura, finalmente en las etapas de este proceso se encuentra la planeación que se encarga de los escenarios futuros, organización enfocada al diseño y determinación de la estructura, procesos y métodos, integración donde se eligen y se obtienen los recursos para poner en marcha las operaciones, dirección en la que se ejecutan todas las fases por medio de conducción y orientación de recurso y el control (pp. 24-25).

3.1.6. Control de Producción 3.1.6.1. Costo de Producción 3.1.6.1.1 Materia Prima Son productos que la empresa adquiere para realizar una posterior transformación física o químicamente, estas materias pueden ser directas cuando se puede identificar y cuantificar, y caso contrario son materia prima indirecta, teniendo como resultado un producto final que se le ofrece a un grupo destinado al cual se adquirió (García, 2014, p. 70).

32

3.1.6.1.2 Mano de Obra Según García (2014) la mano de obra es el empeño humano para realizar el proceso de transformación de las materias primas en productos finales, este talento es remunerado, y si el trabajador manipula directamente con el proceso de producción se considera mano de obra directa y los que no, es mano de obra indirecta como por ejemplo el personal de mantenimiento (p. 75).

3.1.6.1.3 Costos indirectos de manufactura Los costos indirectos de manufacturación o costos indirectos de fábrica son todos aquellos objetos que se encuentran relacionados con el producto en elaboración y productos terminados, con el detalle de que no se atribuyen de una manera económica factible, como por ejemplo lubricantes y suministros de limpieza es decir están relacionados y son importantes pero no influyen el costo de producción (Horngren, Datar y Rajan, 2012, p. 37).

3.1.6.2. Inventario De acuerdo con García (2014) el concepto de inventario se lo puede definir como la lista de bienes materiales y derechos que pertenecen a una persona, comunidad o empresa la cual se caracteriza por estar ordenada y clara, por otro lado García menciona que los inventarios son bienes con lo que cuenta la empresa para la producción de uno o varios productos, estos inventarios se pueden clasificar en materia prima, producción en proceso y productos terminados (p. 274).

3.1.6.2.1 Tipos de Inventarios en función de la demanda 3.1.6.2.1.1 Inventarios con demanda independiente En este tipo de inventarios la demanda se halla bajo la influencia de las condiciones del mercado. Por lo general son inventarios de productos terminados y son característicos de inventarios comerciales (Silador, Naranjo, Marrero, Utrera, & Rodríguez, 2015, p. 3). El sistema de administración más empleado en este tipo de inventarios es el de revisión continua que combinado con el modelo de cantidad económica de orden se determinan lineamientos cuando las existencias llegan al punto de re-pedido, realizando un pedido con una cantidad razonable (Leal & Oliva, 2012, p. 12).

33

3.1.6.2.1.2 Inventarios con demanda dependiente Los productos en los inventarios con demanda dependiente son aquellos que se emplearán en la elaboración de productos terminados, caracterizándose porque su demanda se halla condicionada por la cantidad de producto final que debe elaborarse (Silador et al., 2015, p. 3). La manera de administrar este tipo de inventarios según Leal y Oliva (2012) es empleando sistemas de Planeación de Requerimientos de Materiales (MRP por sus siglas en inglés) en donde se realizan los pedidos de acuerdo a la necesidad que el Plan Maestro de Producción notifique (p. 13).

3.1.6.2.2 Producción en proceso y productos terminados Los productos en proceso son los materiales a los que se les ha realizado una transformación pero que aún no se han completado todo su proceso para poder ser un producto terminado a los cuales se les define como todos los artículos sometidos al procese y que cubren con los requerimientos de calidad (García, 2014, pp. 274-275).

34

4.

METODOLOGÍA DE LA INVESTIGACIÓN

4.1. Diseño / Tipo de investigación 4.1.1. Enfoque de la investigación La presente investigación posee un enfoque mixto por el motivo particular de la problemática expuesta anteriormente. Los métodos mixtos de acuerdo con Hernández, Fernández & Baptista (2014) son la agrupación de procesos metódicos y experimentales en donde se recolecta y analiza tanto datos cuantitativos como cualitativos (p. 534). Conforme a ello, se emplea el método cuantitativo al emplear encuestas para la recolección de información que arrojarán resultados cuantificables acerca de la productividad de la empresa. Además, se aplicará el enfoque cualitativo que permitirá profundizar el estudio y tener una idea general del funcionamiento de la institución en estudio mediante la aplicación de una entrevista a la Gerente de la misma.

4.1.2. Diseño de la investigación El diseño de investigación que se ha elegido para el desarrollo del presente es el diseño no experimental teniendo como objeto o motivación de uso el no realizar manipulaciones con las variables sino un estudio de las mismas como tal, además, dentro de este diseño, se usará el tipo transversal por lo que la información que se recabe se lo hará en un solo momento la que servirá de base para el desarrollo del presente documento.

4.1.3. Tipo de Investigación Para el desarrollo del estudio del presente proyecto se hará uso de diferentes tipos de investigación como investigación descriptiva, aplicada y de campo.

4.1.3.1. Investigación Descriptiva La investigación descriptiva brinda la posibilidad de especificar las características y propiedades más relevantes del objeto de estudio que se esté sometiendo al análisis recolectando información sobre las variables, mas no especifica cómo se relacionan éstas Hernández, Fernández, & Baptista, 2014, p. 92). De este modo se agrupa de forma global las causas y consecuencias que generan la problemática en la empresa. Las características se detallan por medio de encuestas y entrevistas que servirán para la recolección de información.

35

4.1.3.2. Investigación Aplicada La investigación aplicada permitirá hacer uso de los conocimientos adquiridos durante el proceso de formación profesional y posteriormente plasmarlos en la elaboración del sistema el cual permitirá mejorar la productividad y la operatividad general de la empresa objeto de estudio.

4.1.3.3. Investigación de Campo Aquí se procederá a asistir a la empresa para recopilar datos directamente de la persona que entiende todo el funcionamiento y operatividad de la mima que es la Gerente. Esto, a través de una temática estructura se enfatizará en conocer los datos más relevantes del funcionamiento de los procesos emitidos en la institución y de esta manera dirigir el desarrollo de la propuesta.

4.2. Población / Universo La población es un grupo de entes o individuos que componen el universo, comparten características relevantes o comunes entre ellos y que serán objeto de estudio (Hernández et al., 2014, p. 174) La población que se toma en cuenta en la presente investigación compete al personal de la Fábrica de Bloques “San Pedrito” ubicada en Santo Domingo de los Colorados, la cual cuenta con 3 personas, distribuidas en una gerente, supervisor y un operario.

4.3. Muestra La muestra es un subgrupo delimitado y representativo de la población del cual se recolectarán datos (Hernández, 2014, p. 173). De acuerdo a varios investigadores, si la población es menor a 30-40 individuos, no es necesario determinar muestra y los instrumentos se aplican a toda la población (Posso, 2009). Considerando lo anteriormente mencionado, en la presente investigación, la muestra es igual a la población, es decir tres personas.

4.4. Técnicas e Instrumentos de recogida de datos Para la presente investigación se hará el uso de técnicas como: Encuesta, las cuales abarcaran preguntas correspondientes al instrumento cuestionario que ayudarán a la recolección de la información necesaria para el estudio de la problemática, las cuales se las realizará a todo el personal de la fábrica.

36

La Entrevista, que se encuentra organizada previo un análisis de las preguntas que ayudarán a dirigir la misma, se acudirá a la institución y se le aplicará a la persona con mayor conocimiento del proceso de producción, en este caso, la Gerente de la misma.

Como instrumento para la recolección de la información en torno a la Encuesta se optó por el desarrollo de un cuestionario conformado por preguntas cerradas para facilitar la representación de los datos; y en la Entrevista se empleó la Guía del Entrevistador compuesta por preguntas abiertas.

4.5. Técnicas de Análisis de Datos Para el análisis de los datos recabados por las encuestas se hará uso de la técnica de tabulación de datos y por medio de estadísticas representar la información plasmándola gráficamente para su posterior interpretación, por otro lado, las entrevistas o reuniones que se realicen con el cliente servirán para plasmar las funcionalidades del sistema (requerimientos) que serán representadas a través de historias de usuario las cuales son propias de la metodología XP.

4.6. Metodología de Desarrollo de Software 4.6.1. Análisis de metodologías de desarrollo de software Previamente, en la sección 3.1.1.2.6 se especifica el empleo de Metodologías Ágiles para el desarrollo del presente proyecto frente a los Métodos Tradicionales. A continuación, en se aborda la comparativa entre dos métodos ágiles: XP y Scrum. Se ha realizado la selección de estas dos metodologías atendiendo a la naturaleza del proyecto y su alcance; su comparativa se realiza empleando la herramienta de análisis 4-DAT (4-Dynamic Analytical Tool).

Es importante destacar que en un principio el método 4-DAT realiza la comparación a través de cuatro dimensiones (alcance de la metodología, caracterización de agilidad, valores ágiles y caracterización del proceso de software), pero es una herramienta bastante flexible dado que se permite añadir o eliminar dimensiones, o de igual forma elementos de las dimensiones, siempre y cuando se consideren necesarias (Ávila & Meneses, 2013, p. 18).

En base a ello, los criterios de las dimensiones que a continuación se especifican fueron extraídos de Qumer & Henderson-Sellers (2006), además, se realizará las actualizaciones de algunos campos del modelo original indicando su origen.

37 Tabla 2.

Dimensión 1. Alcance de la Metodología (XP y Scrum) Criterio

XP

Scrum

Tamaño del proyecto

Pequeños y medianos

Pequeños, medianos y grandes

Tamaño del equipo

2-10 a

3-9 b

Estilo de desarrollo

Iterativo, rápido

Iterativo, rápido

Estilo de codificación

Limpio y simple

No especificado

Entorno Tecnológico

Rápido feedback

No especificado

Entorno Físico

Mismo lugar y distribuidos

No especificado

Cultura de Negocio

Colaborativo y cooperativo

No especificado

Mecanismo de Abstracción

Paradigma Orientado a objetos

Paradigma Orientado a objetos

Nota. Fuente: a Navarro, A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo de software. Prospectiva, 11(2), 30-39. Obtenido de https://dialnet.unirioja.es/servlet/articulo?codigo=4752083.

b

Scrum

Alliance Organization. (2016). The Scrum Guide. Obtenido de https://www.scrumalliance.org/why-scrum/scrum-guide

38 Tabla 3.

Dimensión 2. Grado de agilidad XP Características de Agilidad a

XP

FY

b

SD

c

LS

d

LG

e

RS

Total

(i) Fases Exploración

1

1

0

1

1

4

Planeación

1

1

0

1

1

4

Iteración

1

1

0

1

1

4

Producción

1

1

1

1

1

5

Mantenimiento

1

0

0

1

1

3

Muerte

0

1

0

0

0

1

Total

5

5

1

5

5

21

Grado de agilidad

5/6

5/6

1/6

5/6

5/6

Juego de la planificación

1

1

0

1

1

4

Entregas cortas

1

1

0

1

1

4

Metáforas

0

1

1

0

0

2

Diseño Simple

1

1

1

1

1

5

Testeo

1

1

0

1

1

4

Refactorización

1

1

1

1

1

5

Programación en parejas

1

0

0

1

1

3

Propiedad Colectiva del código

1

0

0

1

1

3

Integración continua

1

1

1

1

1

5

Semanas de 40 horas laborales

0

0

0

1

0

1

Cliente en el sitio

1

0

0

1

1

3

Uso de estándares de codificación

1

1

1

1

1

5

Total

10

8

5

11

10

44

Grado de agilidad

10/12

8/12

5/12

11/12

10/12

21/30

(ii) Prácticas

44/60

Nota. a Flexibilidad. b Velocidad. c Eficiencia. d Aprendizaje. e Adaptabilidad. Fuente: Qumer, A., & Henderson-Sellers, B. (Julio, 2006). Comparative Evaluation of XP and Scrum using de 4D Analytical Tool (4-DAT). Trabajo presentado en European and Mediterranean Conference on Information Systems (EMCIS). Alicante, España. Obtenido de http://emcis2016.emcis.eu/Emcis_archive/EMCIS/EMCIS2006/Proceedings/Contributions/C70/CRC/EMCISAsif%20ED ITED%20Paper_final.pdf

39 Tabla 4.

Dimensión 2. Grado de agilidad Scrum Características de Agilidad Scrum

a

FY

b

SD

c

LS

d

LG

e

RS

Total

(i) Fases Pre-juego (Planificar)

1

1

0

1

1

4

Desarrollo

1

1

0

1

1

4

Post-juego (Cierre)

0

1

0

0

0

1

Total

2

3

0

2

2

9

Grado de agilidad

2/3

3/3

0/3

2/3

2/3

Scrum Master

1

1

0

1

1

4

Equipo Scrum

1

1

0

1

1

4

Lista de Productos (Product Backlog)

1

1

0

1

1

4

Sprint

1

1

0

1

1

4

Reunión de Planificación

1

1

0

1

1

4

Reunión Scrum diaria

1

1

0

1

1

4

Revisión del Sprint

1

1

0

1

1

4

Total

7

7

0

7

7

28

Grado de agilidad

7/7

7/7

0/7

7/7

7/7

9/15

(ii) Prácticas

28/35

Nota. a Flexibilidad. b Velocidad. c Eficiencia. d Aprendizaje. e Adaptabilidad. Fuente: Qumer, A., & Henderson-Sellers, B. (Julio, 2006). Comparative Evaluation of XP and Scrum using de 4D Analytical Tool (4-DAT). Trabajo presentado en European and Mediterranean Conference on Information Systems (EMCIS). Alicante, España. Obtenido de http://emcis2016.emcis.eu/Emcis_archive/EMCIS/EMCIS2006/Proceedings/Contributions/C70/CRC/EMCISAsif%20ED ITED%20Paper_final.pdf

40 Tabla 5.

Dimensión 3. Valores ágiles Valores Ágiles

XP

Scrum

1.- El juego de la planificación

1.- Equipo Scrum

iteraciones sobre los procesos y

2.- Propiedad Colectiva

2.- Reunión de planificación

herramientas

3.- Cliente en el sitio

3.- Reuniones Scrum diarias

Valorar

las

personas

y

las

4.- Programación en parejas Valorar el software funcional

1.- Entregas pequeñas

1.- Sprint

sobre documentación exhaustiva

2.- Testeo

2.- Revisión del sprint

3.- Integración continua Valorar la colaboración con el

1.- Juego de planificación

1.- Lista de productos

cliente sobre un contrato de

2.- Cliente en el sitio

2.- Reunión de planificación

Valorar la respuesta al cambio

1.- Metáforas

1.- Revisión del sprint

sobre seguir una planificación

2.- Diseño simple

2.- Reunión de planificación

negocio

3.- Refactorización 4.- Uso de estándares de codificación Mantener el proceso ágil

-

1.- Revisión del sprint 2.- Reuniones Scrum diarias

Mantener la rentabilidad de los

-

-

procesos

Nota. Fuente: Qumer, A., & Henderson-Sellers, B. (Julio, 2006). Comparative Evaluation of XP and Scrum using de 4D Analytical Tool (4-DAT). Trabajo presentado en European and Mediterranean Conference on Information Systems (EMCIS).

Alicante, España.

Obtenido de http://emcis2016.emcis.eu/Emcis_archive/EMCIS/EMCIS2006/Proceedings/Contributions/C70/CRC/EMCISAsif%20ED ITED%20Paper_final.pdf

41 Tabla 6.

Dimensión 4: Caracterización del Proceso de Software Proceso de software

XP

Scrum

Proceso de desarrollo

1.- Entregas cortas

1.- Equipo Scrum

2.- Metáfora

2.- Lista de Productos

3.- Diseño simple

3.- Sprint

4.- Testeo

4.- Revisión del Sprint

5.- Refactorización 6.- Programación en parejas 7.- Propiedad Colectiva 8.- Integración Continua 9.- Cliente en el sitio 10.- Estándares de codificación Proceso de Administración del

1.- Juego de planificación

1.- Scrum Master 2.- Reunión de planificación

proyecto

3.- Reuniones Scrum diarias la

No especificado

No especificado

Proceso de Administración del

No especificado

No especificado

Proceso

de

Control

de

Configuración del software

proceso

Nota. Fuente: Qumer, A., & Henderson-Sellers, B. (Julio, 2006). Comparative Evaluation of XP and Scrum using de 4D Analytical Tool (4-DAT). Trabajo presentado en European and Mediterranean Conference on Information Systems (EMCIS).

Alicante, España.

Obtenido de http://emcis2016.emcis.eu/Emcis_archive/EMCIS/EMCIS2006/Proceedings/Contributions/C70/CRC/EMCISAsif%20ED ITED%20Paper_final.pdf

Como conclusión de los apartados anteriores, los autores concluyen que de acuerdo a la herramienta de análisis 4-DAT, la mejor metodología de desarrollo de software que se ajusta al desarrollo del presente proyecto es la Metodología Programación Extrema tomando en cuenta el criterio de que esta metodología se enfoca más en el desarrollo del producto que a la gestión del proyecto, como es el caso de Scrum. Además, es importante recalcar que como parámetros de aceptación se cumple con la mayoría de especificaciones propias de XP, como por ejemplo la colaboración con el cliente, el tamaño del equipo de desarrollo (2 integrantes), la dimensión del proyecto (mediano) y tiempo de desarrollo (corto).

42

4.6.2. Metodología Extreme Programming (XP) 4.6.2.1. Etapas y actividades de la Metodología XP 4.6.2.1.1 Planeación Es la primera etapa en donde se comienza a detallar a grandes rasgos lo que se quiere del software. Se empieza con la comunicación entre el equipo de desarrollo y el cliente, detallando las especificaciones o requerimientos necesarios para que sean implementados en la primera iteración del sistema. Esta breve especificación de requerimientos del sistema se lo realiza a través de las Historias de Usuario, que vienen a reemplazar a una especificación de requerimientos formal (SRS) y a los casos de uso. Las historias de usuario son escritas o detalladas por el cliente en un lenguaje informal con ayuda de los técnicos, estos realizan estimaciones sobre las historias y negocian las entregas de las mismas.

4.6.2.1.2 Diseño El diseño es la segunda etapa del proceso XP, es aquí en donde se realizan las metáforas o pequeños prototipos de cómo va a ser el sistema. El diseño del software es simple, algo característico de la metodología, además, como es bien conocido que XP hace uso del paradigma orientado a objetos, se realizan las tarjetas CRC o tarjetas Clase-ResponsabilidadColaborador, que son tarjetas que especifican las clases más importantes que se usarán en la codificación del sistema, además, se especifican las responsabilidades de estas clases y a su vez se identifican aquellas clases que servirán de colaboradoras o aquellas que se les asignaran tareas.

4.6.2.1.3 Codificación La etapa de codificación es en donde se procede a crear o transformar en código lo recabado o especificado en las historias de usuario por parte del cliente. Gracias a la retroalimentación e integración continua se consigue un código más simple, probado y funcional. La programación en parejas es una de las buenas prácticas que se emplean en la metodología XP por el simple motivo de que dos cabezas piensan mejor que una. XP motiva al trabajo en equipo, es así que en esta etapa se sientan dos desarrolladores en una estación de trabajo para la escritura del código, bien uno describe los métodos y procesos y el otro prueba y analiza si estas funcionalidades son adecuadas, coherentes y necesarias.

43

Conforme se avance en el proyecto, estas funciones que cumplen las personas encargadas del desarrollo pueden ser intercambiadas (conforme se realicen iteraciones o entregas) si así lo amerita el equipo de desarrollo. Esta forma particular de trabajo apoya la noción de Propiedad Colectiva del Código que es otra de las buenas prácticas características de XP, en el cual se evidencia el trabajo colectivo y la no dependencia de una persona, es decir, el código no es propiedad de quien lo escribe, sino de cada miembro que participe en el desarrollo del mismo, además, cada miembro del equipo puede mejorar o añadir características al código en cualquier momento.

4.6.2.1.4 Pruebas Las pruebas que se realicen en la metodología Programación Extrema son de dos tipos: Pruebas Unitarias y Pruebas de Aceptación. Las pruebas unitarias son aquellas que se realizan en el momento de la codificación, es decir, los desarrolladores ejecutan las pruebas para testear la funcionalidad del código escrito. Estas pruebas pueden ser automatizadas. Por otro lado, las pruebas de aceptación son aquellas que el cliente ejecuta para probar la funcionalidad que se entrega hasta ese momento. Estas pruebas se basan en lo descrito por las historias de usuario, es decir, si las historias cumplen con los criterios de aceptación se denomina que la historia de usuario pasó la prueba. Es una medida que sirve para identificar el cumplimiento de la historias de usuario y llevar un control de los avances que se realizan.

4.6.2.1.5 Finalización El proceso XP es iterativo, es decir que se repiten las etapas anteriormente mencionadas conforme se realicen iteraciones. El proceso muere cuando el proyecto llega a una etapa en las que el cliente ya no trae más historias de usuario para que el equipo las implemente en el sistema. Puede darse dos escenarios en esta etapa: el primero es la finalización exitosa del proyecto en la cual se cumplen a cabalidad todas las funcionalidades y expectativas del cliente; por otro lado, el segundo escenario sucede cuando existe un cierre abrupto del proyecto debido a que no se cuentan con los recursos necesarios para su ejecución o el proyecto ya no es viable.

44

5. Resultados 5.1. AnĂĄlisis y DiscusiĂłn de los resultados 5.1.1. Entrevista realizada al gerente de la FĂĄbrica de Bloques “San Pedritoâ€?

Como resultado de la aplicaciĂłn de la entrevista (Ver Anexo 2). Que se la realizĂł a la Sra. Janeth Ocampo gerente propietario de la FĂĄbrica de Bloques “San Pedritoâ€? se obtuvo: 1. ÂżCuĂĄntas personas estĂĄn involucradas para el proceso de producciĂłn?

InterpretaciĂłn: Actualmente para la producciĂłn estĂĄn involucradas 2 personas, supervisor y operario 2. ÂżCuĂĄles son los materiales utilizados para la producciĂłn de productos finales?

InterpretaciĂłn: Cementos, Polvo de piedra, Arena, Grava, y Chasqui.

3. ÂżCuĂĄl es el proceso que se realiza para la elaboraciĂłn de los productos finales?

InterpretaciĂłn: Se hace uso de dos tipos de carretilla aproximadamente una de 11 carretillas m3 y otra de 10 carretillas m3. Si es bloque pesado se usa 4 carretillas de Polvo de piedra, 1,2 carretillas de Arena, 0,8 carretillas de Graba y un saco de cemento de 50kg por lo cual en el de medidas 10 Ă— 20 Ă— 40 cm3 se obtiene 85 bloques, los de 15 Ă— 20 Ă— 40 cm3 son de 65 bloques y el de 20 Ă— 20 Ă— 40 cm3 se obtiene X cantidades, para los livianos se usan las mismas cantidades de materia prima y cantidades producidas por saco de cemento, con la excepciĂłn que en vez de Polvo de piedra, se utiliza Chasqui.

4. ÂżQuĂŠ mĂŠtodos se emplean para situar el costo a cada uno de sus productos elaborados?

InterpretaciĂłn: Calculan por paladas con el dato de que 200 paladas es 1 m3, y obtienen el porcentaje de la materia prima utilizada por cantidad producida. Debido al grado de error que podrĂ­a presentar se cambiĂł a cĂĄlculo por carretilla quedando una fĂłrmula para el bloque pesado de 10 Ă— 20 Ă— 40 cm3 de:

đ??śđ?‘œđ?‘ đ?‘Ąđ?‘œđ??ľđ?‘™đ?‘œđ?‘žđ?‘˘đ?‘’ =

$ đ??śđ?‘’đ?‘šđ?‘’đ?‘›đ?‘Ąđ?‘œ + (

4 1,2 0,8 ) Ă— $ đ?‘ƒđ?‘œđ?‘™đ?‘Łđ?‘œ + ( ) Ă— $ đ??´đ?‘&#x;đ?‘’đ?‘›đ?‘Ž + ( ) Ă— $ đ??şđ?‘&#x;đ?‘Žđ?‘Łđ?‘Ž 11 11 11 đ?‘?đ?‘Žđ?‘›đ?‘Ąđ?‘–đ?‘‘đ?‘Žđ?‘‘

45

5. ¿Cómo manejan el control o registro de la producción diaria en la empresa?

Interpretación: Se lo lleva en un cuaderno, anotando la fecha y la cantidad de cementos y de productos producidos en el día.

6. Actualmente ¿Cómo se lleva el registro de las ventas realizadas en la empresa?

Interpretación: Este registro se lo maneja de la misma forma que el registro de producción diaria, anotando la cantidad del producto vendido.

7. Cuenta la empresa con algún medio de información digital que anuncie a sus clientes acerca de los productos que se comercializan.

Interpretación:

Sólo

con

publicidad

de

página

amarillas

Link:

http://www.amarillasinternet.com/bloquerapedrito/ 8. ¿Qué reportes cree usted que debe emitir el sistema y qué elementos debe contener?

Interpretación: Cantidad en m3 de materia prima disponible para la producción, productos finales de cada medida disponibles para la venta, y las ventas realizadas.

5.1.1.1. Conclusión de la entrevista realizada al Gerente de la Fábrica de Bloques “San Pedrito” De acuerdo con los resultados recabados en la entrevista realizada a la GerentePropietario del establecimiento se ha determinado que dos personas (supervisor, operario) intervienen en el proceso de producción; la Gerente interviene en la parte administrativa. En base a ello se determinan las personas que harán uso del sistema. Además, se recabó información acerca de los diversos productos ofrecidos y materiales empleados en su elaboración, así como las medidas y cantidades necesarias para su fabricación. Esta información ha sido de vital importancia dado que con ello y su fórmula correspondiente se determina la producción diaria que se realiza en la empresa.

46

5.1.2. Encuestas realizadas al personal de la Fábrica de Bloques “San Pedrito” A través de la aplicación de las encuestas (Ver Anexo 3) realizadas al personal de la Fábrica de Bloques “San Pedrito” se recabó información necesaria para la continuación del presente proyecto, los resultados de las mismas se muestran a continuación.

1. ¿Cree usted que los procesos administrativos y de control de producción se los realiza con facilidad y de una manera adecuada?

Tabla 7.

Desarrollo de procesos administrativos y control de producción de manera eficiente en la empresa.

OPCIÓN

FRECUENCIA

PORCENTAJE

SI

0

0,0 %

NO

3

100,0 %

TOTAL

3

100 %

Nota. Datos obtenidos de la investigación de campo.

120,0 100,0 100,0 80,0 60,0 40,0 20,0 0,0 0,0 SI

NO

¿Cree usted que los procesos administrativos y de control de producción se los realiza con facilidad y de una manera adecuada?

Figura 12. Desarrollo de procesos administrativos y control de producción de manera eficiente en la empresa.

Fuente: Investigación de campo.

Análisis e Interpretación: de los datos recabados en la encuesta aplicada al personal de la Fábrica de Bloques San Pedrito, tenemos que el 100% de los encuestados consideran que los procesos de administración y control de producción no se efectúan de una manera eficiente, lo cual concierta con la problemática presente en la institución y que se analizó previamente.

47

2. ¿Conoce diariamente qué cantidad existe en el inventario de productos finales para realizar las respectivas ventas?

Tabla 8.

Conocimiento de inventarios de productos finales.

OPCIÓN

FRECUENCIA

PORCENTAJE

SI

2

66,7 %

NO

1

33,3 %

TOTAL

3

100 %

Nota. Datos obtenidos de la investigación de campo.

70,0

66,7

60,0 50,0

40,0

33,3

30,0 20,0 10,0 0,0 SI

NO

¿Conoce diariamente qué cantidad existe en el inventario de productos finales para realizar las respectivas ventas?

Figura 13. Conocimiento de inventarios de productos finales.

Fuente: Investigación de campo.

Análisis e Interpretación: con los resultados obtenidos en la segunda pregunta de la encuesta, se determina que el 66,7 % de los encuestados admiten saber cuánto hay en existencia en el inventario de productos finales para su comercialización, el 33,3 % restante desconoce o no sabe cuento existe en el inventario de productos finales.

De acuerdo con el análisis realizado se determina que, aunque exista una mayoría respecto al conocimiento del inventario de productos finales, la determinación de las cantidades de este último no se realiza de una manera adecuada y necesita automatizarse para agilizar y facilitar el trabajo a la gerencia de la empresa

48

3. ¿Conoce diariamente qué cantidad está disponible en el inventario de materia prima para la producción?

Tabla 9.

Disponibilidad de inventarios de materia prima.

OPCIÓN

FRECUENCIA

PORCENTAJE

SI

0

0,0 %

NO

3

100,0 %

TOTAL

3

100 %

Nota. Datos obtenidos de la investigación de campo.

120,0

100,0 100,0

80,0

60,0

40,0

20,0 0,0

0,0 SI

NO

¿Conoce diariamente qué cantidad está disponible en el inventario de materia prima para la producción?

Figura 14. Disponibilidad de inventarios de materia prima.

Fuente: Investigación de campo.

Análisis e Interpretación: tomando en cuenta los datos adquiridos a través de la encuesta aplicada, se determina que el 100% de los encuestados desconoce la cantidad exacta de materia prima con que se cuenta antes o después de emplearla para la elaboración de los productos finales. Al no tener certeza de las cantidades de materia prima existente la gerencia desconoce qué y cuanto material se emplea diariamente para la elaboración de los distintos productos que ofrece la empresa, siendo ésta una de las problemáticas que la presente investigación junto a la gerencia de la empresa quiere dar solución.

49

4. ¿Cree usted que es necesario automatizar el control de producción mediante el uso de un sistema informático orientado a la web?

Tabla 10.

Necesidad de automatizar el control de producción.

OPCIÓN

FRECUENCIA

PORCENTAJE

SI

3

100,0 %

NO

0

0,0 %

TOTAL

3

100 %

Nota. Datos obtenidos de la investigación de campo.

120,0 100,0 100,0 80,0 60,0 40,0 20,0 0,0 0,0 SI

NO

¿Cree usted que es necesario automatizar el control de producción mediante el uso de un sistema informático orientado a la web?

Figura 15. Necesidad de automatizar el control de producción.

Fuente: Investigación de campo.

Análisis e Interpretación: según los resultados obtenidos en la encuesta, se afirma que el 100% de las personas encuestadas considera que es necesario automatizar los procesos de control de producción en la institución con la finalidad de desarrollar un sistema informático orientado a la web que permita realizar éstas actividades a los usuarios que administrarán el sistema de una manera fácil, rápida y eficiente. Asimismo, se provee a la gerencia de la empresa una herramienta para la gestión administrativa de gran utilidad que ayudará en la toma de decisiones.

50

5. ¿Cree usted que es necesario llevar un registro de ventas que permita conocer lo expendido en un tiempo determinado?

Tabla 11.

Conocimiento del registro de ventas de la empresa.

OPCIÓN

FRECUENCIA

PORCENTAJE

SI

3

100,0 %

NO

0

0,0 %

TOTAL

3

100 %

Nota. Datos obtenidos de la investigación de campo.

120,0 100,0 100,0

80,0 60,0 40,0 20,0 0,0 0,0 SI

NO

¿Cree usted que es necesario llevar un registro de ventas que permita conocer lo expendido en un tiempo determinado?

Figura 16. Conocimiento del registro de ventas de la empresa.

Fuente: Investigación de campo.

Análisis e Interpretación: a través de los resultados obtenidos por medio de la encuesta aplicada, se determina que el 100% de los encuestados considera que es necesario llevar un correcto registro de las ventas realizadas en la fábrica que permita conocer lo expedido en un tiempo determinado, de este modo se pueda conocer todos los detalles correspondientes acerca de las ventas realizadas (tipo de producto, cantidad, datos del cliente, etc.) con su respectiva fecha. Por medio de los reportes que generará el sistema, la gerencia conoce a detalle todo acerca de las ventas que se realicen en la empresa.

51

6. ¿Ha utilizado usted algún tipo de dispositivo digital con acceso a internet para realizar consultas informáticas?

Tabla 12.

Uso de dispositivos digitales para consultas informáticas.

OPCIÓN

FRECUENCIA

PORCENTAJE

SI

2

66,7 %

NO

1

33,3 %

TOTAL

3

100 %

Nota. Datos obtenidos de la investigación de campo.

66,7

70,0 60,0 50,0 40,0

33,3

30,0 20,0 10,0 0,0 SI

NO

¿Ha utilizado usted algún tipo de dispositivo digital con acceso a internet para hacer transacciones informáticas?

Figura 17. Uso de dispositivos digitales para consultas informáticas.

Fuente: Investigación de campo.

Análisis e Interpretación: de acuerdo con los datos recabados con las encuestas, se determina que el 66,7% de los encuestados si han manejado algún tipo de dispositivo digital con acceso a internet para realizar consultas en la web y un 33,3% no lo ha hecho. En base al análisis, la mayoría de los encuestados tienen facilidad y se desenvuelven de manera fluida con el uso de estos dispositivos con lo cual no presentarán mayores inconvenientes para administrar el sistema propuesto.

52

7. Según su criterio ¿Está usted de acuerdo con la implementación de un sistema que permita llevar el control de la producción que se realiza en la empresa?

Tabla 13.

Implementación de un sistema informático para el control de la producción.

OPCIÓN

FRECUENCIA

PORCENTAJE

En desacuerdo

0

0,0 %

Ni de acuerdo, ni en

0

0,0 %

Totalmente de acuerdo

3

100,0 %

TOTAL

3

100 %

desacuerdo

Nota. Datos obtenidos de la investigación de campo.

120 100 100

80

60

40

20 0

0

En desacuerdo

Ni de acuerdo, ni en desacuerdo

0 Totalmente de acuerdo

Según su criterio ¿Está usted de acuerdo con la implementación de un sistema que permita llevar el control de la producción que se realiza en la empresa?

Figura 18. Implementación de un sistema informático para el control de la producción.

Fuente: Investigación de campo.

Análisis e Interpretación: con los datos obtenidos a través de la presente encuesta, se concluye que el 100% de los encuestados está totalmente de acuerdo con la implementación de un sistema que permita llevar la gestión administrativa y el control de la producción dentro de la empresa, de este modo los procesos que se manejan en la fábrica se realizarán de una manera eficiente y se optimizará el tiempo y los recursos empleados para estas actividades.

53

8. ¿Qué servicios cree usted que aportaría mayor valor a la empresa al realizar la implementación del sistema informático?

Tabla 14.

Beneficios de la implementación del sistema informático.

OPCIÓN

FRECUENCIA

PORCENTAJE

Facilitar el control de

1

33,3 %

Ahorrar tiempo y dinero

0

0,0 %

Mejorar el control de

2

66,7 %

3

100 %

producción

inventarios TOTAL Nota. Datos obtenidos de la investigación de campo.

66,7

70,0 60,0 50,0 40,0

33,3

30,0 20,0 10,0 0,0

0,0

0,0 Facilitar el control de producción

Ahorrar tiempo y dinero

Mejorar el control de inventarios

Otros

¿Qué servicios cree usted que contribuirían con la empresa al realizar la implementación del sistema informático?

Figura 19. Beneficios de la implementación del sistema informático.

Fuente: Investigación de campo.

Análisis e Interpretación: con los resultados obtenidos de las encuestas aplicadas al personal de la Fábrica de Bloques se determina que el 33,3% de los encuestados considera que los servicios que se mejorarán será facilitar el control de producción, por otra parte, el 66,7% restante considera que se mejorará el control de inventarios que se maneja internamente en la institución, que actualmente se los realiza manualmente y de manera poco eficiente.

54

5.1.2.1. Conclusión de las encuestas realizadas al personal Después de realizar el análisis respectivo de las encuestas aplicadas al personal de la Fábrica de Bloques “San Pedrito” se determina la necesidad de contar con un sistema informático que sirva de apoyo y automatice los procesos de administrar y controlar la producción y registre las posteriores ventas, actividades que se realizan en la empresa de forma manual. Con el desarrollo del sistema orientado a la web se pretende agilizar y mejorar los procesos de gestión administrativa y control de producción y dar solución a la problemática de la empresa.

5.1.3. Selección de recursos de desarrollo para la elaboración de la aplicación.

La selección de los recursos de software que se emplea en la presente investigación se ha realizado a través de la comparación de diferentes herramientas de desarrollo, se ha efectuado el análisis correspondiente de las mismas considerando la magnitud y dimensión de la presente investigación. Cada característica que se describa y que se corresponda afín al presente trabajo de investigación definirá la herramienta o recursos adecuados para el desarrollo de la aplicación.

5.1.3.1. Selección del Web Hosting Para la ejecución final del sistema informático, la gerencia de la organización en colaboración con los desarrolladores de la presente investigación, luego de un profundo análisis de empresas proveedoras de servicios web (dominio y alojamiento web), y atendiendo a la problemática y necesidades de la empresa, se llega al acuerdo de contratar los servicios de la empresa HostGator, empresa líder en el mercado por ofrecer amplios, flexibles y económicos planes de suscripción, aparte de ofrecer un excelente servicio de hosting, ofrece la posibilidad de adquirir un dominio web para el acceso de la aplicación web desde la World Wide Web (WWW). De este modo, el acceso al sistema SIGPRO se realizará de manera on-line a través de la dirección www.bloquerasp.com

55

5.1.3.2. Base de datos Tabla 15.

Comparativa entre PostgreSQL, MariaDB y SQL Server Características Desarrollo Mantenimiento Tipo de Software y Licencia Plataforma de ejecución

Prestaciones

Web Hosting

a

b

c

PostgreSQL Michael Stonebraker (University of California at Berkeley) The PostgreSQL Global Development Group

MariaDB Desarrolladores originales de MYSQL

SQL Server Microsoft

The MariaDB Foundation

Microsoft

Software Open-source.

Licencia BSD

Software Open-source.

Licencia GNU

Multiplataforma

Multiplataforma

Software Privativo.

Licencia Microsoft EULA Entornos Windows

Amplio soporte para claves foráneas, triggers, administración de privilegios y compatible con la mayoría de tipos de datos de SQL: 2008. Es robusta y fiable, su entorno y esquema de trabajo es compleja, son necesarias configuraciones extras para su uso. El consumo de recursos es moderado La cobertura de Web Hosting que la soporte es inferior a MySQL, además, su costo por alojamiento es relativamente costoso respecto a este último.

La base de datos más popular en el mundo Posee facilidad de desarrollo, una amplia documentación y soporte, su configuración es fácil y su implementación sencilla. Es rápida, robusta y escalable.

Consume pocos recursos y es veloz en procesar y dar respuesta a las peticiones

Consume una enorme cantidad de recursos, son necesarias herramientas extras para su uso y requiere conocimientos previos en el lenguaje T-SQL.

Al ser un fork de MySQL, posee una amplia cobertura en empresas proveedoras de Hosting, además, su alojamiento es económico con características favorables.

Con relación a los Web Hosting, posee un alto precio por alojamiento.

Nota: Fuente: a The PostgreSQL Global Development Group. (2016). About PostgreSQL. Obtenido de https://www.postgresql.org/about, b MariaDB Foundation. (2016). About MariaDB. Obtenido de https://mariadb.org/about/, c Microsoft Corporation. (2017). Microsoft SQL Server. Obtenido de https://msdn.microsoft.com/eses/library/mt590198(v=sql.1).aspx

Con relación a las características descritas previamente en la tabla comparativa, la base de datos que se acopla adecuadamente a la presente investigación y que ha sido seleccionada para el desarrollo de la aplicación es MariaDB. La compatibilidad con el Web Hosting es una condicionante determinante que afecta directamente en la elección de la base de datos. Por otro lado, tanto su costo por uso, su rapidez, usabilidad, escalabilidad y experiencia que se tiene en el manejo de ésta, fueron factores que igualmente han influido en la selección.

56

5.1.3.3. Herramientas de modelado de datos Tabla 16.

Comparativa entre herramientas para modelado de datos Características Plataforma de ejecución Tipo de Licencia Usabilidad

Prestaciones

a

b

MySQL Workbench Herramienta Multiplataforma

SAP PowerDesigner Ejecución sólo en entornos Windows

Software de uso libre Facilidad de navegación y uso del software  Modificación y actualización de modelos y base de datos  Exportación e Importación de scripts SQL  Forward Engineering y Reverse Engineering  Diagramas ER y Modelo Físico de Datos

Software comercial (de pago) Manejo complejo debido a su robustez    

Modificación y actualización de modelos y base de datos Exportación e importación de scripts SQL Forward Engineering y Reverse Engineering Modelo Físico, Lógico y Conceptual de Datos

a Nota: Fuente: Oracle Corporation.

(2017).

MySQL Workbench Manual.

Obtenido de https://dev.mysql.com/doc/workbench/en/, b SAP SE. (2015). SAP PowerDesigner 16.5 SP5 - Quick Reference. Obtenido de https://help.sap.com/saphelp_pd1655_quickref/helpdata/en/d9/4fb27ab10140a48e500fefec569c0d/frameset.htm

Respecto a la herramienta que se ha empleado para el modelado de datos, se selecciona el software MySQL Workbench. De acuerdo con las características descritas en la tabla comparativa, el ser una herramienta de uso libre y ejecutarse en varias plataformas fueron las principales razones de su elección. Además, se tomaron en cuenta otras características como la facilidad de modelar la base de datos y exportación del diccionario de datos.

5.1.3.4. Herramientas de desarrollo web 5.1.3.4.1 Lenguajes de Script Tabla 17.

Comparativa entre lenguajes de Script Característica Licencia Plataforma Pre-requisitos

Formas desarrollo

de

Servidores Web

[a] [b]

ASP.Net

[c] [d]

PHP

Comercial Entornos Windows * .NET Framework * Servidor web * Editor d7e código

Libre Multiplataforma Servidor web y editor de texto.

* Web Forms * MVC * Web Pages 1 Servidor IIS (Internet

* Programación Estructurada * Soporte para el paradigma orientado a objetos Apache, Ngix, Lighttp,

[e]

JSP Libre Multiplataforma * Infraestructura de Java (JDK) * Servidor web. * IDE para desarrollo y despliegue de aplicaciones Java Completa integración del paradigma orientado a objetos Servidor web

57 soportados

Information Services)

LiteSpeed Web Server, entre otros

Usabilidad

Entorno cómodo de desarrollo. Comparte las funcionalidades que admita el framework .NET

El más popular para el desarrollo web en el mundo. Es rápido, flexible, sintaxis simple y sencilla

compatible con Servlet (Apache Tomcat, Glassfish, Microsoft IIS, etc.)

Conocimientos previos en Java y estructura de servlet, Entorno seguro, versátil, portable y de alto rendimiento

Nota: 1 Aunque está diseñado específicamente para trabajar con el servidor web IIS (Internet Information Services), puede ser ejecutado en otros servidores web. Fuente: [a] López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & De Castro, V. (2012). Desarrollo Web en entorno servidor. Madrid: Ra-Ma., [b] Microsoft Corporation. (2012). ASP.NET 4.5 y Visual Studio 2012. Obtenido de https://msdn.microsoft.com/library/hh420390(v=vs.110).aspx, [c] The PHP Group. (2016).

General Installation Considerations. Obtenido de http://php.net/manual/en/install.general.php, [d] The PHP Group. (2016).

Installation on Unix systems. Obtenido de http://php.net/manual/en/install.unix.php, [e] Oracle Corporation. (2016).

JavaServer Pages Overview. Obtenido de http://www.oracle.com/technetwork/java/overview-138580.html

El lenguaje de scripting del lado del servidor que se ha elegido para la codificación de la aplicación es PHP debido a su simpleza, versatilidad y experiencia en el desarrollo web que se tiene con esta potente herramienta. Además, posee una amplia documentación y soporte por parte de la comunidad del software libre. Otra importante razón es el Web Hosting compatible con PHP, que son más económicos respecto a otros que soporten otro tipo de lenguaje.

5.1.3.4.2 Framework Front-End Tabla 18.

Tabla comparativa Materialize - Boostrap a

    

Materialize CSS MaterializeCSS es un framework de diseño web que utiliza el enfoque Material Design que emplea Google en sus proyectos.

Consigue un diseño de UI más minimalista, sencillo, estilizado y funcional en múltiples plataformas.

Materialize no emplear librerías y plugins secundarios.

Ofrece características responsivas que acoplan la interfaz de la aplicación web al dispositivo en donde se ejecuta.

Además ofrece un conjunto de componentes que no se encuentran disponibles en Boostrap.

b

    

Boostrap Boostrap es el framework front-end más popular en el mundo del diseño de aplicaciones web.

Posee una amplia comunidad de desarrollo que brinda soporte y documentación necesaria para su uso.

Boostrap brinda capacidades adicionales con el sistema grid que maneja.

Ofrece un amplio set de componentes y opciones respecto a otros.

Se centra principalmente en el manejo de sitios web en plataformas móviles, pero se amplía sus capacidades a dispositivos de mayor tamaño.

Nota: Fuente: a Materialize. (2016). Sobre Materialize. Obtenido de http://materializecss.com/about.html, b Bootstrap.

(2016). About Bootstrap. Obtenido de http://getbootstrap.com/about/

El framework que se ha seleccionado para el desarrollo del front-end de la aplicación web es MaterializeCSS debido a su sencillez, simplicidad de código y facilidad de uso. Además, al incorporar la filosofía de diseño de Material Design de Google, ofrece estilos y efectos visuales atractivos para el usuario (enfocado en el usuario). Con MaterializeCSS se agiliza el desarrollo

58

del proyecto dado que proporciona varios componentes personalizables y se unifica la experiencia del usuario en cualquier plataforma.

5.1.4. Resultado de la aplicación de la metodología 5.1.4.1. Fase de Planeación La fase de Planificación en Metodología XP es la primera de cinco etapas que conforman el proceso XP. Es aquí donde se elaboran las historias de usuario que especifica el cliente y que representan las funcionalidades del sistema; con las primeras historias se arranca el desarrollo y conforme a las iteraciones se irán especificando las necesarias. De igual forma se especifica el Plan de Entregas y el Plan de Iteraciones que se llevará a cabo en el proyecto.

5.1.4.1.1 Historias de Usuario Las Historias de Usuario en Metodología XP sirven para realizar la especificación de funcionalidades que va a poseer el sistema y que serán implementadas en el desarrollo del mismo, esto a manera de requerimientos o requisitos, pero no siéndolos completamente. En metodologías ágiles son el método más empleado para exponer requisitos y son la alternativa al documento de Especificación de Requerimientos de Software (SRS) y Casos de Uso. Entre las características principales de las Historias de Usuario tenemos que son independientes, negociables (modificables), valorables (entregan valor al usuario), cuantificables (costo y esfuerzo), pequeñas y comprobables.

Las Historias de Usuario no lo son “todo” dado que no especifica de forma tajante un requerimiento, sino que son placeholder o contenedores para especificar un requisito. A continuación se presenta un modelo o plantilla de Historia de Usuario (XP) utilizada en el presente proyecto, describiendo cada apartado que lo conforman. Para realizar las estimaciones se empleó la serie Fibonacci en el rango de 1, 2, 3, 5, 8.

A continuación, se presenta una plantilla de Historia de Usuario con una breve descripción de las partes que la componen. La especificación de las Historias de Usuario empleadas en la presente investigación se encuentra en el apartado Anexos (Ver Anexo 7)

59 Tabla 19.

Plantilla de Historia de Usuario

Historia de usuario Número: (identificador de historia de usuario)

Nombre: (nombre de historia de usuario)

Usuario: (usuario -perfil- que especifica la historia de usuario ) Prioridad en negocio: Alta/Media/Baja Riesgo en desarrollo: Alta/Media/Baja

Iteración asignada: (número de iteración asignada) Puntos estimados: (estimación realizada por el equipo de desarrollo)

Descripción: - Características de lo que se pide (funcionalidad del sistema)

Observaciones: (alguna acotación, apunte o criterio de aceptación) Fuente: Los autores.

5.1.4.1.2 Plan de Publicaciones (Release Planning) El Plan de Publicaciones o Release Plan en la Metodología XP comprende las fechas o tiempo estimado que se empleará en el desarrollo e implementación de las historias de usuario descritas y en qué entrega o “release” programada previamente se verán funcionales. Es decir, se agrupa un conjunto de historias de usuario a desarrollar y la entrega asignada para dicho conjunto de historias de usuario. Bajo las normativas de la Metodología XP, en el presente proyecto se establece dos entregas, cada entrega con un tiempo de duración de 4 semanas respectivamente, cumpliendo de este modo con los parámetros del Release Plan de XP. A continuación se expone el Plan de Iteraciones y la agrupación de Historias de Usuario por Módulos correspondiente al desarrollo del presente proyecto:

60 Tabla 20.

Plan de Entregas Tiempo estimado Módulo

Módulo de Administración

Historias de Usuario

Semanas

X

Modificar Usuarios

X

Restablecer Contraseña

2 semanas

X

Registro de proveedores

X

Modificación de proveedores

X 2 semanas

2

X

Reporte Usuarios

Modificar materia prima

X X

Registro de productos finales

X

Modificar productos finales

X

Registrar producción diaria

X

Modificación de producción diaria

X

Reporte de proveedores Reporte de materia prima

2 semanas

X X

Reporte de productos finales

X

Reporte de producción

X

Registro de Clientes

X

Modificación de Clientes

X

Registro de Ventas Módulo de Ventas

1

Crear Usuarios

Ingresar materia prima

Módulo de Producción

Release Asignada

Modificación de Ventas

X 2 semanas

X

Reporte de Clientes

X

Reporte de Ventas

X

Fuente: Los autores.

5.1.4.1.3 Plan de Iteraciones Las iteraciones son aquellas repeticiones de procesos que se realizan generalmente en un periodo de tiempo corto, con la finalidad de retroalimentar y alcanzar una meta u objetivo.

Las iteraciones son fundamentales en la Metodología XP dado que al comienzo de cada ciclo de iteración se seleccionan las historias de usuario descritas en el Release Plan y que serán implementadas según el orden correspondiente. Es decir, se estiman o estipulan qué o cuántas historias de usuario se realizarán en cada iteración programada. Cada proyecto desarrollado bajo la Metodología XP se divide en iteraciones, en el caso de la presente investigación se dividió en cuatro iteraciones, con días laborales de 3,5 horas y semanas de 5 días laborales

61 Tabla 21.

Plan de Iteraciones

Módulo

Historias

Iteración Asignada 1

Módulo de Administración

H

D

7

2

Modificar Usuarios

X

7

2

Restablecer Contraseña

X

10,5

3

Reporte Usuarios

X

10,5

3

X

3,5

1

X

3,5

1

Ingresar materia prima

X

10,5

3

Modificar materia prima

X

3,5

1

Registro de productos finales

X

10,5

3

Modificar productos finales

X

3,5

1

X

7

2

X

3,5

1

X

3,5

1

X

7

2

X

7

2

X

7

2

Modificación de producción diaria Reporte de proveedores Reporte de materia prima Reporte de productos finales Reporte de producción

Fuente: Los autores.

4

X

Registrar producción diaria

Módulo de Ventas

3

Crear Usuarios

Registro de proveedores Modificación de proveedores

Módulo de Producción

2

Tiempo estimado

Registro de Clientes

X

7

2

Modificación de Clientes

X

3,5

1

Registro de Ventas

X

7

2

Modificación de Ventas

X

3,5

1

Reporte de Clientes

X

7

2

Reporte de Ventas

X

7

2

Semanas

2 sem

2 sem

2 sem

2 sem

62

5.1.4.3. Fase de Diseño La fase de diseño en Metodología XP se caracteriza por ser sencilla y simple, sin hacer uso de diagramas UML o equivalentes complejos, siempre tomando en cuenta hacerlo lo menos complejo posible, con ello se ahorra esfuerzo y tiempo que se empleará en el desarrollo. Es en esta fase en donde se especifican las Tarjetas CRC que servirán de guía para el desarrollo y modelado de la base de datos y del sistema en su conjunto 5.1.4.3.1 Tarjetas CRC Las Tarjetas CRC o Tarjetas Clase-Responsabilidad-Colaborador ayudan al desarrollador a tener una concepción orientada a objetos de la realidad que se va a modelar y programar. De este modo, empleando esta técnica de diseño se representan los sistemas con una orientación a objetos en vez de la concepción procedural antigua. La especificación de estas tarjetas es sencilla, se expone en la parte superior la Clase a la que pertenece el objeto, en una columna a la izquierda se detallan las Responsabilidades que tiene a cargo dicha clase, y en otra columna a la derecha los Colaboradores o clases colaboradoras que ayudan a la clase principal a cumplir sus objetivos y responsabilidades 5.1.4.3.1.1 Especificación de Tarjetas CRC

Tabla 22.

Tarjeta CRC - Usuarios Tarjeta CRC Número: 1

Clase: classUser

Responsabilidades

Colaboradores

Crear usuarios Actualizar usuarios Eliminar usuarios

classConectar

Fuente: Los autores.

63 Tabla 23.

Tarjeta CRC - Ventas Tarjeta CRC Número: 2

Clase: classVenta

Responsabilidades

Colaboradores

Ingresar venta Actualizar venta Eliminar venta

classConectar classProducto classCliente

Fuente: Los autores.

Tabla 24.

Tarjeta CRC - Producto Tarjeta CRC Número: 3

Clase: classProducto

Responsabilidades

Colaboradores

Ingresar producto Actualizar producto Eliminar producto

classConectar classMateria

Fuente: Los autores.

Tabla 25.

Tarjeta CRC - Proveedor Tarjeta CRC Número: 4

Clase: classProveedor

Responsabilidades

Colaboradores

Crear proveedor Actualizar proveedor Eliminar proveedor

classConectar classUsuario

Fuente: Los autores.

64 Tabla 26.

Tarjeta CRC – Materia Prima Tarjeta CRC Número: 5

Clase: classMateria

Responsabilidades

Colaboradores classConectar classUsuario classProveedor

Ingresar materia prima Actualizar materia prima (add/update) Eliminar materia prima

Fuente: Los autores.

Tabla 27.

Tarjeta CRC - Cliente Tarjeta CRC Número: 6

Clase: classCliente

Responsabilidades

Colaboradores

Ingresar cliente Actualizar cliente Eliminar cliente

classConectar classUsuario

Fuente: Los autores.

Tabla 28.

Tarjeta CRC - Producción Tarjeta CRC Número: 7

Clase: classProduccion

Responsabilidades

Colaboradores

Ingresar producción Actualizar producción Eliminar producción

classConectar classUsuario classMateria classProducto

Fuente: Los autores

5.1.4.3.2 Diseño de la base de datos 5.1.4.3.2.1 Diseño Físico de la Base de Datos

Figura 20. Diseño Físico de la Base de Datos Fuentes: Los autores

65 65

5.1.4.3.2.2 Diseño Lógico de la Base de datos

66

Figura 21. Diseño Lógico de la Base de Datos Fuente: Los autores

66

67

5.1.4.3.2.3 Diccionario de datos El diccionario de datos (Ver Documentos Complementarios adjuntos en el CD – Diccionario de Datos) especifica todos los datos que pertenecen a un sistema de una forma organizada. En otras palabras, es un repositorio de los datos o elementos que conforman el sistema, se listan cada uno de ellos con los detalles y descripciones de los mismos. Se especifica el nombre de la tabla, nombre de las variables, el tipo de dato, tipo de claves entre otros. La finalidad del diccionario de datos es servir de guía para que el analista comprenda todos los flujos de entrada, salida y cálculos que se realicen, además de precisar los datos que se manejan en el sistema evitando de esta forma las ambigüedades 5.1.4.3.2.4 Script de la base de datos El script de la base de datos (Ver Documentos Complementarios adjuntos en el CD – Script de la Base de Datos) es un archivo, generalmente con extensión .sql, en donde se encuentra escrito en código del lenguaje SQL las sentencias e instrucciones que dan vida y mueven la base de datos de un sistema informático que lo emplee. Es un archivo adicional e independiente del modelado de la base de datos. Aquí se encuentra especificado la creación de las tablas, las relaciones entre ellas, los disparadores, views o vistas codificadas y operaciones de inserción, actualización y eliminación de datos según corresponda.

5.1.4.3.3 Diseño de Interfaces El diseño de interfaces facilita en gran medida el trabajo del desarrollador, dado que haciendo un trabajo en conjunto, se puede especificar las primeras vistas y prototipos de cómo quedaría la parte visual que interactuaría con el usuario final que haga uso del sistema. El diseño y maquetación de las interfaces en el presente proyecto se lo realizó gracias al empleo de Mockpus Tools o Herramientas Mockups especializadas en esta tarea, tal es el caso del software Balsamiq.

68

5.1.4.3.3.1 Interfaces Externas Página principal.

Figura 22. Diseño de interface vista principal Fuente: Los autores.

Login de Usuario.

Figura 23. Diseño de interface ingreso al sistema Fuente: Los autores

69

5.1.4.3.3.2 Interfaces Administrador/Supervisor Sección Administración principal – Usuario Administrador

Figura 24. Diseño de interface principal de administración.

Fuente: Los autores.

Sección Administración principal – Usuario Supervisor

Figura 25. Diseño de interface principal de administración Fuente: Los Autores

70

Sección Materia Prima

Figura 26. Diseño de interface sección materia prima Fuente: Los autores.

Sección Productos.

Figura 27. Diseño de interface sección productos Fuente: Los autores.

71

Sección Producción

Figura 28. Diseño de interface sección producción Fuente: Los autores.

Sección Clientes

Figura 29. Diseño de interface sección clientes Fuente: Los autores.

72

Sección Ventas

Figura 30. Diseño de interface sección ventas Fuente: Los autores.

Sección Proveedores

Figura 31. Diseño de interface sección proveedores Fuente: Los autores.

73

Sección Usuarios

Figura 32. Diseño de interface sección usuarios Fuente: Los autores.

5.1.4.4. Fase de Codificación La etapa de Codificación en Programación Extrema es en donde se escribe el código de todas las funcionalidades del sistema detalladas en las historias de usuario por parte del cliente, éste último es de vital importancia en esta etapa dado que él es quien crea las historias de usuario y negocia el tiempo de desarrollo e implementación de las mismas, además, el cliente cubre ciertos aspectos que no se detallan en las historias de usuario y conoce lo que estas deben hacer. Su colaboración se continúa con las pruebas que se realicen para verificar que las historias de usuario cumplen con lo acordado.

A continuación se presenta la codificación de los puntos más importantes del sistema:

74



Conexión a la base de datos

Figura 33. Conexión a la base de datos Fuente: Los autores

Figura 34. Codificación de la conexión a la base de datos Fuente: Los autores

75



Administración de la producción

Figura 35. Codificación de la Clase Producción Fuente: Los autores

76



Administración de Usuarios

Figura 36. Codificación de las interfaces de administración Fuente: Los autores

5.1.4.4.1 Codificación de las interfaces de Usuario A continuación se presentan las principales interfaces de usuario de acuerdo al diseño previo que se ha realizado de las mismas:

77



Login de Usuario

Figura 37. Interfaz principal de ingreso Fuente: Sistema SIGPRO

Figura 38. Codificación del Login de Usuario Fuente: Los autores

78



Interfaces principales de administración

Figura 39. Interfaz principal de administración (Usuario administrador) Fuente: Sistema SIGPRO

Figura 40. Interfaz principal de administración (Usuario supervisor) Fuente: Sistema SIGPRO

79

Figura 41. Codificaciรณn del Login de Usuario Fuente: Los autores

80

5.1.4.5. Fase de Pruebas 5.1.4.5.1 Pruebas Unitarias Las pruebas unitarias de acuerdo con la Metodología XP las realiza el desarrollador en el momento, es decir, conforme se vayan codificando las funcionalidades del sistema, se valida y testea cada parte del código que se escriba, estas pruebas no necesariamente se deben documentar y además pueden ser automatizadas de acuerdo al lenguaje de programación seleccionado. A continuación se presentan dos ejemplos de pruebas unitarias automatizadas de las clases principales del sistema informático.

Figura 42. Prueba Unitaria de la Clase Producción Fuente: Sistema SIGPRO

Figura 43. Prueba Unitaria de la Clase de Producción Fuente: Sistema SIGPRO

81

5.1.4.5.2 Pruebas de Aceptación Las pruebas de aceptación en la presente disertación de grado se han realizado a través de la agrupación de historias de usuario que concuerden con el módulo en que se encuentren, para comprobar la funcionalidad que describen a través del test respectivo. En total se ha realizado cuatro pruebas de aceptación que se detallan en la sección de anexos (Ver Anexo 8) 5.1.4.6. Fase de Finalización La última fase o también conocida como muerte del proceso en XP, es la etapa en donde el cliente no especifica más historias de usuario y el equipo de desarrollo no tiene que realizarlas o incluirlas en el sistema. En esta etapa, el sistema se encuentra integrado completamente y su funcionalidad es total. Con ello se consigue satisfacer por completo los requerimientos que el cliente ha especificado.

En esta etapa se realiza la última documentación del sistema, es decir, como artefacto o entregable se generó los respectivos manuales, como el técnico y el de usuario final. Con la entrega de los mencionados documentos se pretende dar una guía para que el usuario haga un correcto uso de las funcionalidades que posee el sistema. Como complemento de ello, se capacitó al personal de la institución en el uso y manejo del sistema SIG-PRO 5.1.5. Resultados de la administración de inventarios.

De acuerdo con la información proporcionada por parte de la empresa, ésta hace uso de inventarios con demanda dependiente. Por tal motivo, se ha realizado a manera de alertas que notifiquen al usuario del sistema cuando los niveles de inventarios tanto de materia prima como de productos elaborados sean inferiores al stock definido. A continuación se muestra el funcionamiento de las alertas:

82

Figura 44. Notificación en el panel principal Fuente: Sistema SIGPRO

Figura 45. Notificación en la sección Materia Prima Fuente: Sistema SIGPRO

Figura 46. Información que provee la Notificación – Materia Prima Fuente: Sistema SIGPRO

83

Figura 47. Notificación en la sección Productos.

Fuente: Sistema SIGPRO

Figura 48. Información que provee la Notificación – Productos.

Fuente: Sistema SIGPRO

84

5.2. Conclusiones 

Con el desarrollo e implementación del sistema informático se ha automatizado los procesos de gestión administrativa y de control de producción que se realizaban manualmente, además, todas las actividades que se realizan en la empresa se registran de forma digital y están a disposición inmediata para la toma de decisiones por parte de la gerencia.



La metodología de desarrollo de software seleccionada –XP- al ser ágil permitió planificar, diseñar, testear y construir un software a la medida, de acuerdo a los requerimientos especificados por parte de la empresa, adaptándose a los cambios que surgían conforme se avanzaba en el presente proyecto.



Se determina de acuerdo al tipo de negocio y procesos que se manejan en la empresa, que la mejor manera de administrar inventarios con demanda dependiente es a través de la Planeación de Requerimientos de Materiales (MRP por sus siglas en inglés) a través de un sistema de notificaciones que alerta la variación de los inventarios en entornos irregulares de demanda.



El framework de diseño MaterializeCSS resulta ser una excelente herramienta para el diseño de interfaces web gracias a su filosofía de diseño que incorpora Material Design. Con respecto al apartado visual, maneja una amplia gama de colores, efectos, transiciones, entre otros aspectos que armonizan la usabilidad de la aplicación por parte del usuario.



En relación al lenguaje de programación, PHP, que se ha seleccionado, éste permite convertir de manera eficiente los procesos que se realizan a diario en la empresa (la lógica del negocio) y que el cliente nos ha proporcionado información de los mismos. El desarrollo con PHP es versátil, rápido y cuenta con una amplia gama de funcionalidades nativas que agilizaron el desarrollo del sistema.

85

5.3. Recomendaciones 

Seleccionar la metodología de desarrollo de software considerando aspectos importantes del proyecto como son: la naturaleza de los requerimientos, dimensión del proyecto, disponibilidad de recursos entre otros.



Realizar un correcto levantamiento de la información respecto a los procesos y funcionamiento de la empresa para poder diseñar la lógica del negocio y posteriormente realizar la respectiva codificación de la misma.



Diseñar previamente las interfaces de usuario permitirá establecer la distribución correcta de las partes que componen el sistema y por ende seleccionar un framework de diseño que simplifique el manejo al usuario final.



Las herramientas de desarrollo de software deben seleccionarse de acuerdo a los requerimientos especificados por parte de la empresa, tomando en cuenta varios aspectos como su versatilidad, eficiencia, simplicidad y costo por uso.

86

Lista de Referencias Fuentes de Información Bibliográficas Ali, S., & Agarwal, U. (2016). A Standard Program To Classify Books/Documents According To Colon Scheme of Classification Ed. 6. Using Php Environment. Indian Journal of Applied

Research,

6(4),

592-593.

Obtenido

de

http://worldwidejournals.in/ojs/index.php/ijar/article/view/2277 Álvarez, A., de las Heras, R., & Lasa, C. (2012). Métodos Ágiles y Scrum. Madrid: Anaya.

Amaya, Y. (2013). Metodologías ágiles en el desarrollo de aplicaciones para dispositivos móviles. Estado actual. Revista de Tecnología, 12(2), 111-124. Obtenido de http://m.uelbosque.edu.co/sites/default/files/publicaciones/revistas/revista_tecnologia/ volumen12_numero2/12Articulo_Rev-Tec-Num-2.pdf Arias, A. (2015). Aprende sobre la Ingeniería de Software. Middletown: IT Campus Academy. Ávila, E., & Meneses, A. (2013). Delfdroid y su comparación evaluativa con XP y Scrum mediante el método 4-DAT. Revista Cubana de Ciencias Informáticas, 7(1), 16-23.

Obtenido de http://scielo.sld.cu/pdf/rcci/v7n1/rcci03113.pdf Báez, C., & Suárez, M. (2013). Proceso de desarrollo de Software. Boyacá: Búhos Editores Ltda.

Blanco, F. (2012). Dirección de ventas. Bogotá: Ediciones de la U. Bootstrap. (2016). About Bootstrap. Obtenido de http://getbootstrap.com/about/ Brito, K., & Héctor, K. (2015). Selección de Metodologías de Desarrollo para Aplicaciones Web. USA: Editorial Académica Española.

Camarena, J., Trueba, A., Martínez, M., & López, M. (2012). Automatización de la codificación del patrón modelo vista controlador (MVC) en proyectos orientados a la web.

Ciencia,

19(3),

239-250.

Obtenido

de

http://cienciaergosum.uaemex.mx/index.php/ergosum/article/view/796/576 Cusick, J. (2013). Durable Ideas in Software Engineering: Concepts, Methods and Approaches from My Virtual Toolbox. New York: Bentham E-Books.

87

Díaz, J., Pérez, A., & Florido, R. (2015). Sitio Web para la Intranet del Instituto Nacional de Ciencias Agrícolas en Internet. Cultivos Tropicales, 36(2), 13-17. Obtenido de http://scielo.sld.cu/pdf/ctr/v36n2/ctr02215.pdf Fernández, A. (2013). Python 3 al descubierto. México: Alfaomega.

Ferrer, J. (2014). Implantación de aplicaciones web. Madrid: Ra-Ma. Flórez, H. (2012). Programación orientada a objetos usando Java. Bogotá D. C.: ECOE Ediciones.

G. Cobb, C. (2015). The Project Manager´s Guide to Mastering Agile: Principles and Practices for an Adaptive Approach. Hoboken: John Wiley & Sons.

García, J. (2014). Contabilidad de costos. México D. F.: McGrawHill.

Gauchat, J. (2013). El gran libro de HTML5, CSS3 & Javascript. Barcelona: Marcombo.

Ghani, I., Bt, A., Azham, Z., Izzaty, N., & Ryul, S. (2014). Integrating Security into Agile Models: Scrum, Feature-Driven Development (FDD), and eXtreme Programming (XP). En I. Ghani, W. Nasir, & M. Nazir, Advances in Systems Analysis, Software Engineering, and High Performance Computing : Handbook of Research on Emerging Advancements and Technologies in Software Engineering (págs. 293-308). Hershey: IGI Global.

Gutiérrez, F. (2013). Integración de AMD y Métodos de Desarollo de Software. Revista Digital Tecnología, Investigación y Academia, 1(1), 49-56.

Hernández, R., Fernández, C., & Baptista, M. (2014). Metodología de la Investigación.

México: McGrawHill.

Horngren, C., Datar, S., & Rajan, M. (2012). Contabilidad de costos: Un enfoque gerencial.

México D. F.: Pearson.

Iqbal, U., & Javed, A. (2014). Review-Scrum (R-Scrum) Introduction Of Model Driven Architecture (MDA) in Agile Methodology. International Journal of Scientific & Technology Research, 3(11), 296-302. Obtenido de http://www.ijstr.org/finalprint/nov2014/Review-scrumr-scrum-Introduction-Of-Model-Driven-Architecturemda-In-Agile-Methodology.pdf

88

Leal, A., & Oliva, K. (2012). Criterios para la gestión de los sistemas de inventarios. Revista Tecnocientífica

URU,

2(3),

11-19.

Obtenido

de

http://200.35.84.134/ojs-

2.4.2/index.php/rtcu/article/viewFile/37/33 Lee, R. (2012). The Success Factors of Running Scrum: A Qualitative Perspective. Journal of Software

Engineering

and

Applications,

5(6),

367-374.

doi:http://dx.doi.org/10.4236/jsea.2012.56043 López, I., Castellano, M., & Ospino, R. (2013). Base de Datos. México D. F.: Alfaomega.

López, L. (2013). Metodología de la programación Orientada a Objetos (Segunda ed.).

México: Alfaomega.

López, M., Vara, J., Verde, J., Sánchez, D., Jiménez, J., & De Castro, V. (2012). Desarrollo Web en entorno servidor. Madrid: Ra-Ma. Manso, Y., Cañizares, R., & Febles, J. (2016). Diseño web adaptativo para la plataforma educativa ZERA. Revista Cubana de Ciencias Informáticas, 10(2), 100-115. Obtenido de http://www.redalyc.org/articulo.oa?id=378345292008 MariaDB Foundation. (2016). About MariaDB. Obtenido de https://mariadb.org/about/ Martínez, C. (2012). Administración de Organizaciones. Bogotá: Facultad de Ciencias Económicas.

Materialize. (2016). Sobre Materialize. Obtenido de http://materializecss.com/about.html Mavlanova, T., Benbunan-Fich, R., Koufaris, M., & Lang, G. (2015). The Effect of Positive and Negative Signals on Perceived Deceptiveness of Websites in Online Markets.

Journal of Theoretical and Applied Electronic Commerce Research, 10(1), 19-24. doi:10.4067/S0718-18762015000100003 Measey, P. (2015). Agile Foundations : Principles, practices and frameworks. Swindon: The British Computer Society.

Microsoft Corporation. (2012). ASP.NET 4.5 y Visual Studio 2012. Obtenido de https://msdn.microsoft.com/library/hh420390(v=vs.110).aspx Microsoft Corporation. (2016). ASP.NET and Visual Studio for Web. Obtenido de https://msdn.microsoft.com/en-us/library/dd566231.aspx

89

Microsoft

Corporation.

(2017).

Microsoft

SQL

Server.

Obtenido

de

https://msdn.microsoft.com/es-es/library/mt590198(v=sql.1).aspx Montes, C., Montilla, O., & Mejía, E. (2014). Control y evaluación de la gestión organizacional. Bogotá: Alfaomega.

Moreno, J. (2013). Programación. Bogotá: Ra-ma.

Morien, R. (2014). Back to the Basics: In Support of Agile Development. En I. Ghani, W. Nasir, & M. Nazir, Advances in Systems Analysis, Software Engineering, and High Performance Computing : Handbook of Research on Emerging Advancements and Technologies in Software Engineering (págs. 279-292). Hershey: IGI Global.

Münch, L. (2014). Administación: gestión oraganizacional, enfoques y proceso administrativo.

Naucalpan de Juárez: Pearson.

Navarro , A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el desarrollo

de

software.

Prospectiva,

11(2),

30-39.

Obtenido

de

Overview.

Obtenido

de

https://dialnet.unirioja.es/servlet/articulo?codigo=4752083 Oracle

Corporation.

(2016).

JavaServer

Pages

http://www.oracle.com/technetwork/java/overview-138580.html Oracle

Corporation.

(2016).

MySQL

Workbench.

Obtenido

de

http://www.mysql.com/products/workbench/ Oracle

Corporation.

(2017).

MySQL

Workbench

Manual.

Obtenido

de

https://dev.mysql.com/doc/workbench/en/ Pérez, E., & Ávila, R. (2014). Metodología para el diseño de una base de datos de modelo CAD basado en STEP. Revista de Arquitectura e Ingeniería, 8(3), 1-12. Recuperado el 15 de Julio de 2016, de http://www.redalyc.org/pdf/1939/193933034002.pdf Pérez, M. (2015). MySQL Diseño, Programación y Administración de Bases de Datos. San Bernardino: Paperback.

Pérez, M. (2015). Programación orientada a objetos y programación estructurada. San Bernardino: Paperback.

90

Piattini, M., García, F., Rodríguez, I., & Pino, F. (2012). Calidad de Sistemas de Información.

México D. F.: Alfaomega.

Piñeiro, J. (2013). Base de datos relacionales y modelado de datos. Madrid: Paraninfo.

Posso, M. (2009). Metodología para el trabajo de grado ( tesis y proyectos ). Ibarra: Cámara Ecuatoriana del Libro - Núcleo de Pichincha.

Qumer, A., & Henderson-Sellers, B. (2006). Measuring agility and adoptability of agile methods: a 4-dimensional analytical tool. En N. Guimarães, P. Isaías , & A. Goikoetxea, Proceedings of the IADIS International Conference on Applied Computing (págs. 503507). San Sebastian: IADIS. Qumer, A., & Henderson-Sellers, B. (Julio, 2006). Comparative Evaluation of XP and Scrum using de 4D Analytical Tool (4-DAT). Trabajo presentado en European and Mediterranean Conference on Information Systems (EMCIS). Alicante, España.

Obtenido

de

http://emcis2016.emcis.eu/Emcis_archive/EMCIS/EMCIS2006/Proceedings/Contribu tions/C70/CRC/EMCISAsif%20EDITED%20Paper_final.pdf Reinosa, E., Maldonado, C., Muñoz, R., Damiano, L., & Abrutsky, M. (2014). Base de Datos.

México: Alfaomega.

Rosado, A., Quintero, A., & Meneses, C. (2012). Desarrollo ágil de software aplicando programación

extrema.

Ingenio,

5(1),

24-29.

Obtenido

de

http://revistas.ufpso.edu.co/index.php/ringenio/article/view/23/10 SAP SE. (2014). Simplify Complex Architectures and See the Potential Impact of New Technologies. Obtenido de https://www.sap.com/documents/2014/07/a047a0a2-217c0010-82c7-eda71af511fa.html SAP SE. (2015). SAP PowerDesigner 16.5 SP5 - Quick Reference. Obtenido de https://help.sap.com/saphelp_pd1655_quickref/helpdata/en/d9/4fb27ab10140a48e500 fefec569c0d/frameset.htm Scrum

Alliance

Organization.

(2016).

The

Scrum

https://www.scrumalliance.org/why-scrum/scrum-guide

Guide.

Obtenido

de

91

Silador, E., Naranjo, M., Marrero, M., Utrera, A., & Rodríguez, E. (2015). Propuesta de modelo matemático de gestión de inventario. Caso Servi Cupet Punta Gorda, Cienfuegos, Cuba.

UNIANDES

EPISTEME,

2(4),

1-13.

Obtenido

de

http://186.46.158.26/ojs/index.php/EPISTEME/article/view/167/110 Sprimont, P., Ricci, D., & Nicastro, L. (2014). New Web Technologies for astronony. Revista Mexicana

de

Astronomía

y

Astrofísica,

45,

75-78.

Obtenido

de

http://www.redalyc.org/articulo.oa?id=57132995026 Sublime Text. (2016). Some things users love about Sublime Text. Obtenido de https://www.sublimetext.com/ The

PHP

Group.

(2016).

General

Installation

Considerations.

Obtenido

de

Obtenido

de

http://php.net/manual/en/install.general.php The

PHP

Group.

(2016).

Installation

on

Unix

systems.

http://php.net/manual/en/install.unix.php The PostgreSQL Global Development Group. (2016). About PostgreSQL. Obtenido de https://www.postgresql.org/about/ Thierry, G. (2013). Java 7 Bases del lenguaje y de la programación orientada a objetos.

Barcelona: Ediciones ENI. Wadhwa, M., & Sharma, N. (2015). Review of Agile Software Development Methodologies.

Advances in Computer Science and Information Technology, 2(4), 370-374. Obtenido de http://www.krishisanskriti.org/vol_image/04Jul201511075614%20%20%20%20%20 %20%20%20Nidhi%20sharma%20%20%20%20%20%20%20%20%20%20%20%20 %20%20%20%20370-374.pdf Warren, C. (2013). Engineering Safe and Secure Systems. Norwood: Artech House.

Zofío, J. (2013). Aplicaciones Web. Madrid: Macmillan Profesional

92

GLOSARIO DE TÉRMINOS ASP.NET Es un framework o entorno de desarrollo de aplicaciones web dinámicas que lo comercializa Microsoft. Su funcionamiento se centra en el framework .NET de Microsoft que permite desarrollar las aplicaciones en lenguajes de programación como C#, VB.Net entre otros.

Boostrap Es un framework de diseño para el desarrollo de aplicaciones web. Provee un conjunto de componentes tales como plantillas, botones, esquema de colores, iconos u otros que extienden su funcionalidad y aspecto visual.

BSD (Licencia) Berkeley Software Distribution (BSD), es s un tipo de licencia de software libre permisiva en donde se comparte por igual, además posee menos restricciones que otras licencias del tipo GPL EULA (Licencia) End User License Agreement (EULA) es una licencia de software en el cual existe un acuerdo entre el licenciante (propietario del software) y el licenciatario (usuario final), en donde se especifica una serie de términos para el correcto uso del software.

Forward Engineering Este término hace referencia a realizar Ingeniería hacia adelante, es decir, que se construye un modelo en alto nivel a partir de una especificación o detalles en bajo nivel.

Framework Un framework es un marco de trabajo en donde se agrupan práctica, conceptos u otros criterios que sirven de apoyo para la resolución de un problema en particular GNU (Licencia) La General Public License (GNU) es el tipo de licencia más popular y usada en el mundo del software libre y open source en donde el usuario final posee la capacidad de modificar, compartir y usar el software en cuestión. Esta licencia garantiza que el software sea libre y que ningún tercero trate de apropiarse del mismo.

HTML5 Es un lenguaje de programación diferente a los demás dado que no utiliza sentencias u otras instrucciones que los lenguajes convencionales emplean, sino más bien un conjunto de etiquetas que especifican la ubicación de los elementos en una página web.

93

MaterializeCSS Framework de diseño web que se basa en la filosofía de diseño web “Material Design” que promulga Google. Posee varios componentes tales como iconos más estilizados, plantillas, efectos, tipografía, etc, que derivan en un apartado visual más simple y mejor presentado.

Paradigma El concepto de paradigma en el campo de sistemas hace referencia al conjunto de prácticas, herramientas que sirven para describir un modelo.

PHP PHP Prepocesor Hypertext es un lenguaje de script open source que se ejecuta de lado del servidor, muy empleado en el desarrollo de aplicaciones web dinámicas.

Open Source (software) Open Source hace referencia al software que es de código abierto y se comercializa libremente.

La principal características es su libre acceso al código fuente del software.

Reverse Engineering Éste término se refiere al proceso de realizar Ingeniería inversa, es decir, obtener la parte principal (código) a partir de un product terminado Web Hosting El servicio de Web Hosting permite a los individuos en particular crear sus aplicaciones web y hacerlas accesibles a través de Internet.

94

ANEXOS

95

Anexo 1: Carta de Aceptaciรณn del Proyecto

96

Anexo 2: Entrevista realizada al Gerente de empresa

PONTIFICIA UNIVERSIDAD CATOLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS

Entrevista dirigida al Gerente de la Fábrica de Bloques “San Pedrito” La presente Entrevista tiene como objetivo recopilar información acerca de los procesos correspondientes a la gestión administrativa y control de producción que manejan en la institución objeto de estudio, con la finalidad de especificar requerimientos iniciales para el desarrollo del proyecto.

Fecha y Hora: Lugar de la entrevista: Nombre del entrevistado: Cargo: Resumen de la entrevista:

97

1. ¿Cuántas personas están involucradas para el proceso de producción? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 2. ¿Cuáles son los materiales utilizados para la producción de productos finales? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 3. ¿Cuál es el proceso que se realiza para la elaboración de los productos finales? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 4. ¿Qué métodos se emplean para situar el precio a cada uno de sus productos elaborados? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

98

5. ¿Cómo manejan el control o registro de la producción diaria en la empresa? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 6. Actualmente ¿Cómo se lleva el registro de las ventas realizadas en la empresa? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 7. Cuenta la empresa con algún medio de información digital que anuncie a sus clientes acerca de los productos que se comercializan. ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ 8. ¿Qué reportes cree usted que debe emitir el sistema y qué elementos debe contener? ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________

99

Anexo 3: Encuesta aplicada al personal de la empresa PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO ESCUELA DE SISTEMAS.

Encuesta dirigida al personal administrativo y operativo de la Fábrica “San Pedrito” Instrucciones: la información que proporcione será de gran importancia, leer cuidadosamente las siguientes preguntas y marque con una “X” la opción que crea correcta 1. ¿Cree usted que los procesos administrativos y de control de producción se los realiza con facilidad y de una manera adecuada? ☐ SI

☐ NO

2. ¿Conoce diariamente qué cantidad existe en el inventario de productos finales para realizar las respectivas ventas? ☐ SI

☐ NO

3. ¿Conoce diariamente qué cantidad está disponible en el inventario de materia prima para la producción? ☐ SI

☐ NO

4. ¿Cree usted que es necesario automatizar el control de producción mediante el uso de un sistema informático orientado a la web? ☐ SI

☐ NO

100

5. ¿Cree usted que es necesario llevar un registro de ventas que permita conocer lo expendido en un tiempo determinado? ☐ SI

☐ NO

6. ¿Ha utilizado usted algún tipo de dispositivo digital con acceso a internet para hacer transacciones informáticas? ☐ SI

☐ NO

7. Según su criterio ¿Está usted de acuerdo con la implementación de un sistema que permita llevar el control de la producción que se realiza en la empresa? ☐En desacuerdo

☐Ni de acuerdo, ni en desacuerdo ☐Totalmente de acuerdo

8. ¿Qué servicios cree usted que contribuirían con la empresa al realizar la implementación del sistema informático?

Facilitar el control de producción

☐

Ahorrar tiempo y recursos.

☐

Mejorar el control de inventarios

☐

101

Anexo 4: Acta de Capacitaciรณn en la administraciรณn del sistema

102

Anexo 5: Carta de Impacto

103

Anexo 6: Acta de Entrega-Recepciรณn del Proyecto

104

Anexo 7: Historias de Usuario Historia de Usuario – Crear Usuarios Historia de usuario Número: 1

Nombre: Crear Usuarios

Usuario: Administrador Prioridad en negocio: Alta

Iteración asignada: 1

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder crear usuarios para poder administrar el sistema.

- Quiero poder seleccionar el perfil e ingresar los datos básicos necesarios para que se identifique a cada usuario.

Observaciones: mostrar un mensaje o notificación que indique que la transacción se ha realizado exitosamente.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cédula, teléfono o correo inválido en el formulario de registro, cuando el Administrador cambie de campo, entonces el sistema muestra un mensaje de error alertando del inconveniente

Escenario 3: 

En caso que se ingrese una contraseña no segura en el formulario de registro, cuando el administrador pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando el formato correcto de la contraseña.

105 Historia de Usuario – Modificar Usuario Historia de usuario Número: 2

Nombre: Modificar Usuarios

Usuario: Administrador Prioridad en negocio: Alta

Iteración asignada: 1

Riesgo en desarrollo: Media

Puntos estimados: 3

Descripción: - Quiero poder modificar o actualizar el perfil y los datos ingresados correspondientes a los usuarios registrados en el sistema para que se actualice la información de los mismos.

- Quiero que la actualización de información se realice con interfaces amigables para simplificar el proceso de administración de usuarios.

Observaciones: se debe mostrar una notificación que indique que la transacción se realizó con éxito. Se debe validar los usuarios registrados para evitar redundancias.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso de ingresar un número de cédula ya registrado, cuando el Administrador del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que la “Cédula ya existe”

Escenario 3: 

En caso que se ingrese una cédula, teléfono o correo inválido en el formulario de modificación, cuando el Administrador cambie de campo, entonces el sistema muestra un mensaje de error alertando del inconveniente.

Escenario 4: 

En caso que se ingrese una contraseña no segura en el formulario, cuando el Administrador pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando el formato correcto

106 Historia de Usuario – Restablecimiento de contraseña Historia de usuario Número: 3

Nombre: Restablecimiento de contraseña

Usuario: Administrador y Supervisor Prioridad en negocio: Alta

Iteración asignada: 1

Riesgo en desarrollo: Media

Puntos estimados: 8

Descripción: - Quiero poder restablecer la contraseña a través del correo para poder tener acceso al sistema en caso que no recuerde la anterior.

Observaciones: el restablecimiento de la contraseña se realizará a través de correo electrónico registrado previamente.

Escenario 1: 

En caso que no se recuerde la contraseña, cuando el Administrador/Supervisor del sistema pulse en la opción de “Olvidó su contraseña”, entonces el sistema mostrará un formulario de restauración de contraseña solicitando el correo con el cual se registró para reenviar la contraseña al mismo.

107 Historia de Usuario – Reporte de Usuarios.

Historia de usuario Número: 4

Nombre: Reporte de Usuarios

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 1

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder observar los usuarios que se encuentren registrados en el sistema de forma detallada (fecha de registro, nombre, nombre usuario, identificador, etc)

Observaciones: la generación del reporte debe contener elementos gráficos y ser en formato .pdf

Escenario 1: 

En caso de solicitud de reporte de usuarios, cuando el Administrador del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado, mostrando los usuarios registrados en el sistema en formato .pdf.

108 Historia de Usuario – Ingreso de proveedores Historia de usuario Número: 5

Nombre: Ingreso de proveedores

Usuario: Administrador Prioridad en negocio: Alta

Iteración asignada: 2

Riesgo en desarrollo: Media

Puntos estimados: 3

Descripción: - Quiero poder ingresar los proveedores para registrar la procedencia de la materia prima que voy a adquirir

Observaciones: se deben validar los datos y se debe mostrar una alerta indicando su registro exitoso.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador del sistema pulse el botón de “Ingresar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cédula, teléfono o nombre inválido en el formulario de registro, cuando el administrador cambie de campo, entonces el sistema alerta del error cometido

109 Historia de Usuario – Modificación de proveedores Historia de usuario Número: 6

Nombre: Modificación de proveedores

Usuario: Administrador Prioridad en negocio: Alta

Iteración asignada: 2

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder modificar los datos ingresados de los proveedores para registrar la procedencia de la materia prima que voy a adquirir - Se debe realizar la respectiva validación de los campos a modificar.

Observaciones: Debe mostrar una alerta indicando su actualización exitosa. Los cambios deben reflejarse automáticamente.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador del sistema pulse el botón de “Actualizar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese un

proveedor ya existente en el sistema, cuando el

Administrador del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que el “Proveedor ya existe” Escenario 3: 

En caso que se ingrese una cédula, teléfono o nombre inválido en el formulario de registro, cuando el Administrador cambie de campo, entonces el sistema alerta del error cometido

110 Historia de Usuario – Ingreso de materia prima Historia de usuario Número: 7

Nombre: Ingresar materia prima

Usuario: Administrador / Supervisor Prioridad en negocio: Alta

Iteración asignada: 2

Riesgo en desarrollo: Media

Puntos estimados: 5

Descripción: - Quiero poder ingresar la materia prima con todos sus campos correspondientes (nombre, precio, cantidad, fecha ingreso, etc.)

Observaciones: Dependiendo del tipo de materia prima se manejarán m3 y unidades como formas de medición. Se debe validar los campos a rellenar y mostrar una alerta indicando del ingreso exitoso.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de “Ingresar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cantidad, precio o stock inválido en el formulario de registro, cuando el Administrador/Supervisor cambie de campo, entonces el sistema alerta del error cometido.

111 Historia de Usuario – Modificación de materia prima Historia de usuario Número: 8

Nombre: Modificación de materia prima

Usuario: Administrador / Supervisor Prioridad en negocio: Alta

Iteración asignada: 2

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder modificar o actualizar información referente a la materia prima que sean del mismo tipo y actualizar nuevas cantidades fácilmente.

Observaciones: debe mostrar un mensaje o notificación alertando al usuario del cambio o actualización que se ha realizado. Se debe validar los campos a rellenar.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de “Actualizar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una materia prima ya existente en el sistema, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que el “Material ya existe”

Escenario 3: 

En caso que se desee actualizar sólo la cantidad del material registrado, cuando el Administrador/Supervisor del sistema pulse el botón “Agregar”, el sistema mostrará una pequeña ventana en el que se ingrese la nueva cantidad, registrando automáticamente los cambios realizados.

Escenario 4: 

En caso que se ingrese una cantidad numérica inválida en el formulario de modificación, cuando el Administrador/Supervisor pulse el botón de “Actualizar”, entonces el sistema alerta del error asociado

112 Historia de Usuario – Registro de productos finales Historia de usuario Número: 9

Nombre: Registro de productos finales

Usuario: Administrador Prioridad en negocio: Alta

Iteración asignada: 2

Riesgo en desarrollo: Media

Puntos estimados: 8

Descripción: - Quiero poder registrar los productos finales que serán aquellos que se comercializarán al público en general, detallar características principales del producto (como los componentes que lo conforman) Observaciones: de acuerdo a la fórmula ingresada indicar el costo de venta.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de “Ingresar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese un producto final con las mismas características y que ya exista en el sistema, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que el “Producto ya existe”

Escenario 3: 

En caso que se ingrese una cantidad numérica inválida en el formulario de registro, cuando el Administrador/Supervisor pulse el botón de “Ingresar”, entonces el sistema alerta del error asociado.

Escenario 4: 

En caso que se desee ingresar los materiales empleados en cada producto, cuando el Administrador/Supervisor desee ingresarlos, entonces el sistema debe permitir seleccionar las materias primas empleadas y registradas previamente.

113 Historia de Usuario – Modificación de productos finales Historia de usuario Número: 10

Nombre: Modificación de productos finales

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 2

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder modificar o actualizar información referente a los productos finales - Quiero que se administren los inventarios de materia prima para que se disminuyan de acuerdo a la cantidad que se emplea para la elaboración de productos finales Observaciones: Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito. Los inventarios deben disminuir de acuerdo a la formula. Este proceso debe ser automático.

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de “Actualizar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una materia prima ya existente en el sistema, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que el “Producto ya existe”

Escenario 3: 

En caso que se desee actualizar sólo la cantidad del material registrado, cuando el Administrador/Supervisor del sistema pulse el botón “Agregar”, el sistema mostrará una pequeña ventana en el que se ingrese la nueva cantidad, registrando automáticamente los cambios realizados.

Escenario 4: 

En caso que se ingrese una cantidad numérica inválida en el formulario de modificación, cuando el Administrador/Supervisor pulse el botón de “Actualizar”, entonces el sistema alerta del error asociado.

114 Historia de Usuario – Registrar la producción diaria Historia de usuario Número: 11

Nombre: Registrar la producción diaria

Usuario: Administrador / Supervisor Prioridad en negocio: Alta

Iteración asignada: 3

Riesgo en desarrollo: Media

Puntos estimados: 3

Descripción: - Quiero poder registrar la producción diaria de los productos desarrollados en el día para saber cuánto produzco diariamente.

Observaciones: permitir llevar un control por fecha de registro. Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de “Ingresar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cantidad inválida, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema alerta del error cometido.

115 Historia de Usuario – Modificación de producción diaria.

Historia de usuario Número: 12

Nombre: Modificación de producción diaria

Usuario: Administrador / Supervisor Prioridad en negocio: Alta

Iteración asignada: 3

Riesgo en desarrollo: Media

Puntos estimados: 5

Descripción: - Quiero poder modificar y/o actualizar los datos referentes a la producción diaria que se ha registrado previamente en el sistema.

Observaciones: Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de “Actualizar”, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cantidad inválida, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema alerta del error cometido.

116 Historia de Usuario – Reporte de Proveedores Historia de usuario Número: 13

Nombre: Reporte de Proveedores

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 3

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero que se muestre o evidencie a manera de reporte el total de proveedores que se encuentran registrados en el sistema y que proporcionan materia prima a la fábrica.

Observaciones: el reporte debe realizarse en formato .pdf y debe contener elementos gráficos.

Escenario 1: 

En caso de solicitud de reporte de proveedores, cuando el Administrador del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado en pdf, mostrando los proveedores que se ha registrado en el sistema.

Historia de Usuario – Reporte de materia prima Historia de usuario Número: 14

Nombre: Reporte de materia prima

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 3

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero que se genere un reporte indicando cuanto tengo de materia prima disponible para la producción de productos finales.

Observaciones: el reporte debe realizarse en formato .pdf y debe contener elementos gráficos.

Escenario 1: 

En caso de solicitud de reporte de materia prima, cuando el Administrador del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado, mostrando las materias primas registradas en el sistema en formato .pdf.

117 Historia de Usuario – Reporte de productos finales Historia de usuario Número: 15

Nombre: Reporte de productos finales

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 3

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero que se muestre un reporte que me indique con cuanto cuento de productos finales en inventario para su comercialización.

Observaciones: el reporte debe realizarse en formato .pdf y debe contener elementos gráficos.

Escenario 1: 

En caso de solicitud de reporte de productos, cuando el Administrador/Supervisor del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado, mostrando la información solicitada en formato .pdf.

Historia de Usuario – Reporte de Producción Historia de usuario Número: 16

Nombre: Reporte de la producción

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 3

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero que se muestre o evidencie a manera de informe la producción que se ha realizado en la empresa con facilidad de manejo temporal Observaciones: el reporte debe realizarse en formato .pdf y debe contener elementos gráficos.

Escenario 1:

 En caso de solicitud de reporte de producción, cuando el Administrador del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado, mostrando la producción que se ha registrado en el sistema en formato .pdf

118 Historia de Usuario – Registro de Clientes Historia de usuario Número: 17

Nombre: Registro de Clientes

Usuario: Administrador / Supervisor Prioridad en negocio: Alta

Iteración asignada: 4

Riesgo en desarrollo: Media

Puntos estimados: 5

Descripción: - Quiero poder registrar los clientes en el sistema para poder realizar las ventas correspondientes.

Observaciones: el ingreso debe validar los campos de registro. Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cédula o número telefónico inválido en el formulario de registro, cuando el Administrador/Supervisor del sistema cambie de campo, entonces el sistema alertará del error cometido

Escenario 3: 

En caso que se ingrese una cédula ya existente en el sistema, cuando el Administrador/Supervisor pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que la “Cédula ya existe”

119 Historia de Usuario – Modificación de Clientes Historia de usuario Número: 18

Nombre: Modificación de Clientes

Usuario: Administrador / Supervisor Prioridad en negocio: Alta

Iteración asignada: 4

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder modificar la información de los clientes que se encuentren registrados en el sistema para actualizar la información de los mismos y realizar las ventas posteriores.

- Quiero que se gestione o controle la información dependiente de esta sección del sistema

Observaciones: la modificación debe validar los campos de registro. Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema mostrará un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se modifica una cédula o teléfono y son inválidos en el formulario de registro, cuando el Administrador/Supervisor pulse el botón de confirmación, entonces el sistema alertará del error cometido

Escenario 3: 

En caso que se ingrese un Cliente ya existente en el sistema, cuando el Administrador/Supervisor pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que ya existe

120 Historia de Usuario - Registro de Ventas Historia de usuario Número: 19

Nombre: Registro de Ventas

Usuario: Administrador / Supervisor Prioridad en negocio: Media

Iteración asignada: 4

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder llevar un registro de ventas realizadas para poder controlarlas en la empresa - Quiero que se gestione los inventarios de productos finales conforme se vayan realizando ventas.

- Quiero que se posibilite el ingreso de nuevos clientes si no se encuentran registrados en el sistema

Observaciones: el registro se llevará por fechas, debe facilitar la elección del cliente o consumidor final.

Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se ingrese una cantidad inválida en el formulario de registro, cuando el Administrador/Supervisor del sistema cambie de campo, entonces el sistema alertará del error cometido

Escenario 3: 

En

caso

que

no

se

encuentre

el

cliente

en

el

sistema,

cuando

el

Administrador/Supervisor del sistema quiera elegir una opción en la lista de clientes, entonces el sistema permitirá seleccionar “Consumidor Final” o permitirá el registro del nuevo cliente.

121 Historia de Usuario – Modificación de Ventas Historia de usuario Número: 20

Nombre: Modificación de Ventas

Usuario: Administrador / Supervisor Prioridad en negocio: Media

Iteración asignada: 4

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero poder modificar la información de las ventas registradas en el sistema previamente para actualizar la información correspondiente de estas últimas.

Observaciones: la modificación debe validar los campos de registro. Mostrar un mensaje de alerta o notificación indicando que la transacción se realizó con éxito

Escenario 1: 

En caso que se dejen en blanco los campos obligatorios del formulario, cuando el Administrador/Supervisor del sistema pulse el botón de confirmación, entonces el sistema muestra un mensaje de alerta indicando que se rellene el campo indicado.

Escenario 2: 

En caso que se modifique una cantidad y ésta sea inválida en el formulario de registro, cuando el Administrador/Supervisor del sistema cambie de campo, entonces el sistema alertará del error cometido

122 Historias de Usuario – Reporte de Clientes Historia de usuario Número: 21

Nombre: Reporte de Clientes

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 4

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero que se genere un reporte general que indique cuantos clientes se encuentran registrados en el sistema para poder gestionar la información respecto a ellos.

- Quiero que se genere un reporte individual por cliente respecto a ventas para poder visualizar los productos que más compran.

Observaciones: el reporte debe contener elementos gráficos. Además debe permitir elegir el rango de tiempo en el reporte individual y debe realizare en formato .pdf

Escenario 1 

En caso de solicitud de reporte de productos, cuando el Administrador del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado, mostrando la información solicitada en formato .pdf.

123 Historia de Usuario – Reporte de Ventas Historia de usuario Número: 22

Nombre: Reporte de Ventas

Usuario: Administrador Prioridad en negocio: Media

Iteración asignada: 4

Riesgo en desarrollo: Baja

Puntos estimados: 3

Descripción: - Quiero que se genere un reporte que indique cuantas ventas se han realizado, para poder gestionar la información de las ventas que se han realizado en la empresa.

Observaciones: el reporte debe contener elementos gráficos, con opción de elegir rangos de tiempo y exportarse en formato .pdf

Escenario 1

 En caso de solicitud de reporte de productos, cuando el Administrador del sistema pulse la opción de Reporte, entonces el sistema abrirá una nueva ventana con el reporte solicitado, mostrando la información solicitada en formato .pdf

124

Anexo 8: Pruebas de Aceptación del Sistema Prueba de Aceptación – Administración de Usuarios

Prueba de funcionalidad ID Caso de prueba: 01

Nombre caso de prueba: Administración de Usuarios

Módulo/sección a evaluar: Módulo Administración (Sección usuarios)

Historia de usuario asociada: 1-2-3-4

Descripción: Se testea el correcto funcionamiento del Módulo Administración –Sección Usuarioscomprobando que todas las validaciones se cumplan y se satisfagan los criterios de aceptación de las historias de usuario involucradas en el test.

Pre-condiciones  El usuario principal (Administrador) debe estar logueado Pasos y condiciones de ejecución  El usuario designado ingresa al módulo de administración de usuarios  Se despliega el formulario de ingreso de usuarios en donde se coloca toda la información, y se dará click en “Ingresar”  La modificación y/o actualización de la información de los usuarios registrados se podrá realizar y los cambios se reflejarán automáticamente  El restablecimiento de la contraseña del usuario registrado se realizará desde la ventana de Login a través del correo electrónico ingresado.  Los cambios se guardarán con éxito

Resultado esperado.  Se guardan todos los datos correspondientes al registro  El sistema muestra una notificación informando que la transacción se realizó exitosamente

Exitoso Estado de prueba Errores asociados: Ninguno Post-condiciones: El Usuario registrado puede acceder al sistema

X

Falló

125 Prueba de Aceptación – Administración de Proveedores y Materia Prima

Prueba de funcionalidad ID Caso de prueba: 02

Nombre caso de prueba: Administración de Proveedores y Materia Prima

Módulo/sección a evaluar: Módulo de Producción (Sección Proveedores – Materia Prima)

Historia de usuario asociada: 5-6-7-8-13-14

Descripción: Se testea el correcto funcionamiento del Módulo de Producción –Sección Proveedores y Materia Prima- comprobando que todas las validaciones se cumplan y se satisfagan los criterios de aceptación de las historias de usuario involucradas en el test. En el apartado de Proveedores el Administrador del sistema procederá a ingresar los proveedores de la materia prima que se adquiera ingresando los datos correspondientes en el formulario de registro. Por otro lado, en el apartado de Materia Prima, tanto Administrador como Supervisor podrán ingresar los datos correspondientes al material adquirido seleccionando el correspondiente proveedor, igualmente se registran los detalles de cada material ingresado.

Pre-condiciones  El usuario designado (Administrador/Supervisor) según corresponda debe estar logueado en el sistema.

Pasos y condiciones de ejecución  El usuario designado (Administrador) ingresa a la sección de Proveedores  Se despliega una lista de los proveedores registrados en el sistema y la opción de ingresar un Nuevo Proveedores. Se abre el formulario de ingreso de proveedores en donde se coloca toda la información, y se dará clic en “Ingresar”  De igual forma, el usuario designado (Administrador/Supervisor) se dirige a la sección Materia prima  Se despliega una lista de los materiales registrados en el sistema y la opción de ingresar un Nuevo Material. Se rellena el formulario de registro colocando los datos respectivos y se procede a pulsar el botón “Ingresar”  La modificación y/o actualización de la información tanto de la materia prima como de los proveedores registrados se podrá realizar y los cambios se reflejarán automáticamente.  Los cambios se guardarán con éxito en ambos escenarios  Sólo el usuario Administrador posee la opción de imprimir reportes de proveedores y materia prima.

Resultado esperado.  Se guardan todos los datos correspondientes al registro de Proveedores y Materia Prima  El sistema muestra una notificación informando que la transacción se realizó exitosamente  Se imprimen los reportes en formato .pdf y contienen elementos gráficos.

Exitoso Estado de prueba

Falló

X

Errores asociados: Ninguno Post-condiciones: Los registros realizados se guardan en la base de datos y se validan para su posterior uso.

126 Prueba de Aceptación – Administración Productos y Producción

Prueba de funcionalidad ID Caso de prueba: 03

Nombre caso de prueba: Administración de Proveedores y Materia Prima

Módulo/sección a evaluar: Módulo de Producción (Sección Productos – Producción)

Historia de usuario asociada: 9-10-11-12-1516

Descripción: Se comprueba el funcionamiento del Módulo de Producción –Sección Productos y Produccióntesteando todas sus funcionalidades y cumpliendo los criterios de aceptación de las historias de usuario involucradas. En el apartado de Productos, el Administrador/Supervisor del sistema procederá a ingresar los datos correspondientes al producto fabricado y seleccionando los materiales empleados en el mismo y que se hallan en el formulario de registro. Por otro lado, en el apartado de Producción, el usuario designado podrá ingresar los datos correspondientes a la producción diaria seleccionando el producto determinado y la fecha correspondiente.

Pre-condiciones  El usuario designado (Administrador/Supervisor) según corresponda debe estar logueado en el sistema.

Pasos y condiciones de ejecución  El usuario designado (Administrador) ingresa a la sección de Producción  Se despliega los productos registrados en el sistema y la opción de ingresar un Nuevo Producto. Se abre una ventana modal junto al formulario de ingreso de productos en donde se coloca toda la información, se seleccionará los materiales empleados, y se pulsa el botón “Ingresar”  De igual forma, el usuario designado (Administrador/Supervisor) en la sección Producción podrá registrar la producción diaria que se realice en la empresa  Se despliega el formulario de registro colocando los datos respectivos y se procede a pulsar el botón “Ingresar”  La modificación y/o actualización de la información tanto de los productos como de la producción estarán validados y los cambios se reflejarán automáticamente.  Los cambios se guardarán con éxito en ambos escenarios  Sólo el usuario Administrador posee la opción de imprimir reportes individuales de los productos y reportes generales de productos y producción Resultado esperado.  Se guardan todos los datos correspondientes al registro de Proveedores y Materia Prima  El sistema muestra una notificación informando que la transacción se realizó exitosamente  Se imprimen los reportes en formato .pdf y contienen elementos gráficos.

Exitoso Estado de prueba

Falló

X

Errores asociados: Ninguno Post-condiciones: Los registros realizados se guardan en la base de datos y se validan para su posterior uso.

127 Prueba de Aceptación - Administración Clientes y Ventas

Prueba de funcionalidad ID Caso de prueba: 04

Nombre caso de prueba: Administración de Ventas

Módulo/sección a evaluar: Módulo de Ventas (Sección Clientes – Ventas)

Historia de usuario asociada: 17-18-19-20-21-22

Descripción: Se pone a prueba el funcionamiento del Módulo de Ventas –Sección Clientes y Ventacomprobando la correcta ejecución de cada una de sus partes y cumpliendo los criterios de aceptación de las historias de usuario involucradas. En el apartado de Clientes, el Administrador/Supervisor del sistema procederá a registrar los clientes en el sistema rellenándolos campos del formulario de registro. Por otro lado, en el apartado de Ventas, el usuario Administrador/Supervisor podrá registrar las ventas realizadas y la fecha correspondiente.

Pre-condiciones  El usuario designado (Administrador/Supervisor) según corresponda debe estar logueado en el sistema.

Pasos y condiciones de ejecución  El usuario designado (Administrador/Supervisor) ingresa a la sección de Clientes  Se presentan los clientes registrados en el sistema y la opción de ingresar un Nuevo Cliente. Aparecerá una ventana modal junto con el formulario de ingreso de clientes en donde se coloca toda la información correspondiente a ellos y se pulsa el botón “Ingresar”  De forma similar, cuando el usuario designado se dirija a la sección Ventas, se presentan las ventas registradas hasta el momento en el sistema y la opción de ingresar una Nueva Venta en donde se coloca toda la información correspondiente a la venta, se podrá seleccionar el cliente o escoger “Consumidor Final”; además, contará con la opción de registrar el cliente en caso que no se encuentre en la lista.

Posterior a ello, se pulsa el botón “Ingresar”  La modificación y/o actualización de la información tanto de los clientes como de las ventas estarán validados y los cambios se reflejarán automáticamente.  Los cambios se guardarán con éxito en ambos escenarios  Tanto usuario Administrador como Supervisor tienen habilitada la opción de reportes individuales en la sección Clientes. Sólo el usuario Administrador tiene habilitado la opción de imprimir reportes generales tanto de Clientes como de Ventas Resultado esperado.  Se guardan todos los datos correspondientes al registro de Clientes y Ventas  El sistema muestra una notificación informando que la transacción se realizó exitosamente  Se imprimen los reportes en formato .pdf y contienen elementos gráficos.

Exitoso Estado de prueba

Falló

X

Errores asociados: Ninguno Post-condiciones: Los registros realizados se guardan en la base de datos y se validan para su posterior uso.