UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO
“SISTEMA WEB DE CONTROL DE INVENTARIOS,
MANUFACTURACIÓN Y PRODUCTO FINAL PARA LA EMPRESA
INDUSTRIAL COMERCIAL DE ALIMENTOS INCADEX S.R.L.”
CASO: INCADEX S.R.L.

PARA OPTAR EL TÍTULO DE LICENCIATURA EN INFORMÁTICA

MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS
POSTULANTE: MONICA CARMEN MENDOZA ROQUE
TUTOR METODOLÓGICO: M.Sc. ALDO RAMIRO VALDEZ ALVARADO
ASESOR: M.Sc. CARLOS MULLISACA CHOQUE

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

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

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

LICENCIA DE USO

El usuario está autorizado a:

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

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

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

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

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

Dedico este proyecto a mi madre

Sra. Carmen Paulina Roque Quispe
por confiar en mí, apoyarme y
sobre todo entregar su vida entera
hacia mi persona para ser una mujer de bien.

i
 AGRADECIMIENTOS
Primeramente a Dios por guiarme a iluminarme cuando más lo necesitaba.
A mi madre Carmen Paulina Roque Quispe por el apoyo moral, paciencia, tolerancia en
los momentos difíciles que se presenta en la vida universitaria, motor principal a seguir
siempre adelante.
A mi padre Elías Mendoza Q.E.P.D. por cuidarme desde el cielo y ser mi angelito que
cuida a mis abuelitos, bisabuelitos que ya no están pero iluminan desde el cielo.

A mi tutor, M. Sc. Aldo Valdez Alvarado por su gran paciencia, ayuda y colaboración
desde que pase taller I, consejos claros que marco marcara mi vida por cada enseñanza
consulta realizada en esta gestión.

A mi asesor M. Sc M.Sc. Carlos Mullisaca Choque por la paciencia, el tiempo brindado a

cada consulta, por estar involucrado y por ser mi guía durante el desarrollo del proyecto.

Al Lic. Marco A. Vera Carvajal jefe personal por la confianza infinita, tiempo a la hora de
ingresar a la empresa, paciencia en el detallado de cada proceso a realizar dentro de la
entidad
A la empresa INCADEX S.R.L. por abrirme las puertas a este emprendimiento en esta
oportunidad para realizar el proyecto
Sr. Ceferino Alcon jefe almacenero de agradecida por la orientación y explicación
detallada de almacén entre otras consultas.

A todos mis docentes de la carrera de informática por las enseñanzas que me dieron en
cada materia cursada.

A mis amigos que colaboraron conmigo en diferentes oportunidades.

ii
 RESUMEN

El desarrollo de un sistema web dio lugar a un desprendimiento de muchas ideas al ver la

tecnología avanzar el incidir a las empresa, no es tarea fácil a menos que sean trabajador
o conocedor exclusivo de la entidad para la obtención y proceso de datos vemos en
Bolivia que las diversas empresas no todas mantienen un desarrollo de uso de
tecnologías actualizadas pero cabe destacar que van paso a paso por necesidad utilitaria
optimizando tiempo con el uso de las tecnologías.

El presente proyecto tiene como finalidad apoyar a la empresa INCADEX S.R.L.,

mediante la implementación del sistema que permitirá controlar el almacén (materia
prima), la manufacturación (proceso de elaboración del chocolate) y por último el
producto final una vez concluido el trabajo dentro de la empresa y poder ser expuesto en
venta.

El desarrollo del proyecto está enfocado bajo la metodología ágil de SCRUM y la

metodología de diseño web UWE.

El software obtenido es un producto de calidad de acuerdo a la metodología de

evaluación de calidad de sistemas WEB-SITE QEM.

Finalmente se puede mostrar en las conclusiones que los objetivos planteados fueron
alcanzados y que el producto desarrollado cumple con los requerimientos, funcionales de
la empresa.

iii
 ABSTRACT

The development of a web system resulted in a shedding of many ideas to see technology
advance the impact on companies, it is not easy task unless they are worker or exclusive
knower of the entity for obtaining and processing data we see in Bolivia That the various
companies do not all maintain a development of the use of updated technologies but it is
important to emphasize that they go step by step by necessity utilitarian optimizing time
with the use of the technologies.

The purpose of this project is to support the company INCADEX SRL, through the
implementation of the system that will allow the control of the store (raw material),
manufacturing (chocolate processing) and finally the final product once the work is
completed within The company and be able to be exposed for sale.

The development of the project is focused under the agile methodology of SCRUM and the
UWE web design methodology.

The software obtained is a quality product according to the methodology of quality

evaluation of WEB-SITE QEM systems.

Finally, it can be shown in the conclusions that the objectives were achieved and that the
developed product meets the functional requirements of the company.

iv
 ÍNDICE
Capítulo 1 Marco Referencial.
1.1. Introducción............................................................................................................... 1
1.2. Antecedentes............................................................................................................. 2
1.2.1. Antecedentes Institucionales.................................................................................. 2
1.2.1.1. Organización de la Empresa............................................................................... 3
1.2.1.2. Manejo de Inventarios........................................................................................ 4
1.2.1.3. Producción y Manufacturación del Chocolate.................................................. 5
1.2.1.4. La Producción Final............................................................................................ 6
1.2.2. Proyectos Similares................................................................................................ 6
1.3. Planteamiento del Problema...................................................................................... 8
1.3.1 Problema Central..................................................................................................... 8
1.3.2 Problemas Secundarios........................................................................................... 9
1.4. Definición del Objetivos........................................................................................... 10
1.4.1 Objetivo General...................................................................................................... 10
1.4.2 Objetivos Especificos............................................................................................... 10
1.5. Justificación............................................................................................................... 11
1.5.1 Económica................................................................................................................ 11
1.5.2 Social....................................................................................................................... 11
1.5.3 Tecnológica............................................................................................................. 12
1.6. Alcances y Límites.................................................................................................... 13
1.6.1 Alcances.................................................................................................................. 13
1.6.2 Limites..................................................................................................................... 13
1.7. Aportes..................................................................................................................... 14
1.7.1. Práctico.................................................................................................................. 14
1.7.2. Teórico................................................................................................................... 15
1.8 Metodología............................................................................................................... 15
1.8.1. Metodología de Investigación............................................................................... 15
1.8.2. Metodología de Ingeniería...................................................................................... 15

Capítulo II Marco Teórico

2.1 Ingeniería de Software. ............................................................................................. 17
2.1.1 Etapas del Proceso.................................................................................................. 17

v
2.1.1.1 Análisis de los requerimientos del software......................................................... 18
2.1.1.2 El Análisis de Requisitos del software; cinco áreas............................................... 18
2.1.1.3 Diseño................................................................................................................... 19
2.1.1.4 Generación de Código........................................................................................... 20
2.1.2 Modelos de Proceso de Software............................................................................. 20
2.1.2.1 Modelos Tradicionales.......................................................................................... 20
2.1.2.2 Modelos Evolutivos............................................................................................. 21
2.1.2.3 Modelos Para Sistemas Orientado a Objetos...................................................... 22
2.1.2.4 Procesos Agiles.................................................................................................... 23
2.2 Metodología de Desarrollo Scrum .............................................................................. 23
2.2.1 Herramientas de Metodología.................................................................................. 24
2.2.1.1 Pila de Producto................................................................................................... 24
2.2.1.2 Product Backlog List ............................................................................................ 26
2.2.1.3 Sprints ................................................................................................................... 26
2.2.2 Roles y Responsabilidades...................................................................................... 27
2.2.2.1 Product Owner ...................................................................................................... 27
2.2.2.2 Scrum Master ...................................................................................................... 28
2.2.2.3 Scrum Team ......................................................................................................... 29
2.2.3 Proceso de La Metodología.................................................................................... 31
2.2.3.1 Pre – Game .......................................................................................................... 31
2.2.3.2 Game.................................................................................................................... 32
2.2.3.3 Post – Game .......................................................................................................... 32
2.2.4 Control de Evolución de Proyecto......................................................................... 34
2.3 Ingeniería Web........................................................................................................... 35
2.3.1 Proceso de Ingeniería Web..................................................................................... 37
2.3.3 Seguridad Informática en la Página Web................................................................. 37
2.4 Metodología Uwe....................................................................................................... 39
2.4.1 Fases de la Metodología Uwe................................................................................ 40
2.4.1.1 Análisis de Requisitos.......................................................................................... 40
2.4.1.2 Diseño Conceptual............................................................................................... 42

vi
2.4.1.3. Diseño Navegacional............................................................................................ 43
2.4.1.4 Diseño de Presentación........................................................................................ 45
2.5 Base de Datos............................................................................................................ 47
2.5.1 Base de Datos Relacionales..................................................................................... 48
2.5.1.1. Gestores de Base De Datos Relacionales............................................................ 48
2.5.1.2. Postgresql….......................................................................................................... 48
2.5.2. Orm.......................................................................................................................... 49
2.6 Tecnologías Web…..................................................................................................... 49
2.6.1 Python ..................................................................................................................... 50
2.6.3. Bootstrap ................................................................................................................ 50
2.7. Inventarios................................................................................................................. 50
2.7.1 Clasificación de Inventarios................................................................................... 51
2.7.1.1. Inventario de Materias Primas............................................................................. 51
2.7.1.2. Inventario de Productos En Proceso de Fabricación......................................... 51
2.7.1.3. Inventario de Productos Terminados................................................................... 51
2.7.2. Control Inventarios….............................................................................................. 51
2.7.3. Manufacturación...................................................................................................... 52
2.7.3.1 Compra u Obtención.............................................................................................. 53
2.7.3.2. Recepción……..................................................................................................... 53
2.7.4. Almacenaje……...................................................................................................... 53
2.7.5. Producción……..................................................................................................... 54
2.7.6. Producto Terminado……..................................................................................... 54

Capítulo III Marco Aplicativo.

3.1 Introducción................................................................................................................ 55
3.2 Pre-Game ....................................................................................................................56
3.2.1 Descripción de Usuario............................................................................................56
3.2.2 Product Backlog.......................................................................................................57
3.2.3 Requerimientos de Hardware y Software................................................................64
3.3 Game......................................................................................................................... 65
3.3.1 Desarrollo del Sprint 1: Módulo de Registro Personal........................................... 66
3.3.1.1 Planificación del Sprint 1: Módulo de Personal................................................. 66

vii
3.3.1.2 Especificaciones de Casos de Uso del Sprint 1.................................................. . 68
3.3.1.3 Diseño Navegacional............................................................................................ 71
3.3.1.4 Diseño Presentación............................................................................................. 72
3.3.1.5 Pantalla de Sprint 1............................................................................................. ..72
3.3.1.6 Prueba Unitaria del Sprint 1................................................................................ 74
3.3.2 Desarrollo del Sprint 2: Módulo de Inventario....................................................... .75
3.3.2.1 Planificación del Sprint 2: Modulo Inventario..................................................... 76
3.3.2.2 Especificación de Casos de Uso de Sprint 2......................................................... 78
3.3.2.3 Diseño Navegacional............................................................................................. 87
3.3.2.4 Diseño de Presentación.......................................................................................... 88
3.3.2.5 Pantallas del Sprint 2 …………………………………………………………. 89
3.3.2.6 Prueba unitaria del Sprint 2................................................................................... .90
3.3.3 Desarrollo del Sprint 3: Módulo Manufacturación................................................. . 91
3.3.3.1 Planificación de Sprint 3: Módulo Manufacturación............................................ 91
3.3.3.2 Especificación de Casos de Uso de Sprint 3......................................................... 93
3.3.3.3 Diseño Navegacional Sprint 3: Manufacturación.................................................. 97
3.3.3.4 Diseño Presentación Sprint 3................................................................................. 99
3.3.3.5 Pantallas de Sprint 3 Manufacturación................................................................. 100
3.3.3.6 Prueba Unitaria del Sprint 3................................................................................. 100
3.3.4 Desarrollo del Sprint 4: Módulo Producto Final..................................................... 101
3.3.4.1 Planificación de Sprint 4: Módulo Producto Final............................................... 101
3.3.4.2 Especificación de Casos de Uso del Modelo de Negocio.................................... 103
3.3.4.3 Diagrama de Casos de Uso de Negocio...............................................................108
3.3.4.4 Diagrama de Clases del Modelo de negocio....................................................... 109
3.3.4.5 Diagrama Entidad Relación del modelo de negocio............................................ 110
3.3.4.6 Prueba Modulo 4 Producto Final..........................................................................110
3.4 Fase del Post – Game................................................................................................ 112
3.4.1 Pruebas de Investigacion........................................................................................ 112
3.5 Pruebas de Stress........................................................................................................ 112

Capitulo IV Calidad y Seguridad.

4.1 Calidad del Sotfware.................................................................................................. 115

viii
4.1.1 Web Quality Evaluation Methodology-Web Site QEM.......................................... 115
4.1.1.1 Definición de Implantacion de la Evolución Elemental....................................... 115
4.1.1.2 Criterio de Preferencia de Calidad Elemental...................................................... 115
4.1.1.3 Evaluación Elementales....................................................................................... 116
4.1.1.4 Especificación de Requerimientos de Calidad..................................................... 117
4.1.1.5 Computo de Preferencias Parciales...................................................................... 117
4.2 Seguridad................................................................................................................... 121
4.2.1 Autenticación.......................................................................................................... 121
4.2.2 Encriptar Contraseña............................................................................................... 121
4.2.3 Preparar y Validar Datos......................................................................................... 121
Capítulo V Análisis Costo Beneficio
5.1 Cocomo II................................................................................................................... 126
5.2 Costo del Sistema...................................................................................................... 126
5.2.1 Costo de desarrollo del software............................................................................. 126
5.2.2 Costo de Implementación....................................................................................... 130
5.2.3 Costo de Elaboración del Proyecto......................................................................... 130
5.2.4 Costo Total del Software......................................................................................... 131
5.3 Valor Actual Neto...................................................................................................... 131
5.3.1 Costo / Beneficio..................................................................................................... 133
5.4 Tasa Interna de Retorno............................................................................................. 134

Capítulo VI Conclusiones y Recomendaciones.

6.1 Conclusiones...............................................................................................................136
6.2 Recomendaciones........................................................................................................136

Bibliografía…………………………………………………………………………… 137

Referencias Bibliográficas…………………………………………………………….. 138

Referencias de internet ………………………………………………………………. 139
Anexos………………………………………………………………………………….. 140
Anexo A…………………………………………………………………………….... 141
Anexo B…………………………………………………………………………….. 142
Anexo C………………………………………………………………………….… 143
Anexo D…………………………………………………………………………….. 144

ix
ÍNDICE DE FIGURAS

CAPITULO I 3
Figura.1.1. Organigrama de la Empresa…………..……………………………… 3
CAPITULO II
Figura 2.1. Roles y Responsabilidades……………………………………………. 31
Figura 2.2. Visión general del proceso de la metodología Scrum………………… 33
Figura 2.3: Análisis de caso de uso y su relación………………………………… 41
Figura 2.4. Diagrama de casos de uso de alto nivel del Negocio………………… 42
Figura 2.5: Ejemplo de diagrama de contenido………………………………….. 43
Figura 2.6: Ejemplo de diagrama de navegación ………………………………. 45
Figura 2.7: Diagrama de presentación ………………………………………….. 47
CAPITULO III
Figura 3.1: Modelo de procesos del proyecto…………………………………….. 56
Figura 3.2 Diagrama de casos de uso de usuario ……………………………........ 68
Figura 3.3.Diseño Navegacional………………..………………………………… 71
Figura 3.4: Diagrama de registro de personal………………………....…………. 72
Figura 3.5 Página de Inicio……………………………………………………….. 73
Figura 3.6 Registro de Personal……………………………….......……………… 73
Figura 3.7. Listado de personal……………………..……………………………. 74
Figura 3.8. Registro de Personal……………………………………………….... 74
Figura 3.9.Diagrama de Casos de Uso de Registrar Materia Prima…………….. 76
Figura 3.10. Diagrama de Casos de Uso de Registrar Herramienta……………… 78
Figura 3.11 Modelo de navegación materia prima, herramienta………………... 88
Figura 3.12 Modelo de presentación de Inventarios………………………...….. 89
Figura 3.13 Registro de Materia Prima y Herramientas…………………..……. 90
Figura 3.14. Diagrama de Casos de Uso de Registrar Receta…………………… 93
Figura 3.15. Diseño navegacional del sprint 3……………………………......... 98
Figura 3.16. Diseño de presentación del sprint 3……………………………….. 99
Figura 3.17 Registro de Producto Registro de Receta…………………………. 100
Figura 3.18.Diagrama de Casos de Uso de Registrar Producto Final…………… 103
Figura 3.19. Diagrama de casos de uso de alto nivel del Negocio…………….... 108
Figura 3.20. Diagrama de Clases del Modelo de Negocio……………………… 109
Figura 3.21. Diagrama Entidad Relación del Modelo de Negocio……………… 110
Figura 3.22. Menoría del sistema y carga del CPU…………………………….. 113
Figura 3.23 Capacidad de carga del sistema……………………………………. 114
CAPITULO IV
Figura 4.1: Estructura de agregación de preferencias parciales………………… 116
Figura 4.2: Rango de aceptabilidad de preferencia de calidad…………………. 116

x
ÍNDICE DE TABLAS

CAPITULO I
Tabla 1.1 Registro de Control de Inventarios…………………………………… 4
Tabla 1.2. Secciones de producción y Manufacturación……………………….. 6
CAPITULO II
Tabla 2.1: Elementos de diseño navegacional………………………………….. 44
Tabla 2.2: Estereotipos para el diagrama de presentación……………………… 46
CAPITULO III
Tabla 3.1: Identificación de Roles de Scrum…………………………………… 57
Tabla 3.2. Product Backlog……………………………………………………. 64
Tabla 3.3: Requerimientos de Hardware y Software………………………….. 65
Tabla 3.4: Primer Sprint Backlog……………………………………………… 68
Tabla 3.5. Registro de Usuario………………………………………………… 71
Tabla 3.6: Prueba unitaria - Sprint 1…………………………………………… 75
Tabla 3.7: Segundo Sprint Backlog …………………………………………… 78
Tabla 3.8. Registrar materia prima……………………………………………. 83
Tabla 3.9. Registrar Herramienta………………………………………………. 87
Tabla 3.10: Prueba unitaria - Sprint 2………………………………………… 91
Tabla 3.11: Tercer Sprint Backlog……………………………………………… 93
Tabla 3.12. Registrar Receta………………………………………………….. 97
Tabla 3.13: Prueba unitaria - Sprint 3………………………………………….. 101
Tabla 3.14 Listado de Producto final …………………………………………… 103
Tabla 3.15.Registrar Producto Final…………………………………………….. 107
Tabla 3.16 Pruebas del Producto final………………………………………….. 111
Tabla 3.17: Resumen de pruebas de integridad ………………………………… 112
CAPITULO IV
Tabla 4.1: Computo de las preferencias parciales ……………………………… 119
Tabla 4.2: Calidad global……………………………………………………….. 120
Tabla 4.3 Validación de datos…………………………………………………… 122
Tabla 4.4: Preparar los datos introducidos por el usuario ………………………. 123
CAPITULO V
Tabla 5.1: Coeficientes: a, b c y d COCOMO II ……………………………….. 125
Tabla 5.2: Punto función………………………………………………………… 126
Tabla 5.3: Conversión de puntos función a KLDC……………………………… 127
Tabla 5.4: Costo de elaboración del proyecto…………………………………… 131
Tabla 5.5: Costo total del software……………………………………………… 131
Tabla 5.6: Calculo VAN………………………………………………………… 133
Tabla 5.7: Criterio de interpretación del VAN………………………………….. 133
Tabla 5.8: Calculo de la tasa interna de retorno ………………………………… 135

xi
 Capítulo I

Marco Referencial

1.1. Introducción

En la actualidad toda empresa competitiva incorpora las Tecnologías de Información y

Comunicación (TIC) en el manejo financiero, administrativo y operativo de su información,
buscando facilidades y mejores servicios, ya sea dentro o fuera de su entidad. En general,
permite aumentar la eficacia y eficiencia en las empresas en diferentes ámbitos y más aún si
se intenta mantener un estado estable en el mercado empresarial. Dentro de nuestro entorno
social se puede observar que la importancia de poseer servicios y nuestra información en
Internet, empieza a ser más importante día a día, no solo para promocionar y publicar
información a los clientes sino también para gestionar dentro y fuera de la Institución, ya
sea una tarea de Planificación, Organización, Dirección o Control.

El Control de la información dentro de un Almacén perteneciente a una empresa de

fabricación de Productos, posee importancia dentro de su manufactura y control de
inventario, porque existe la necesidad de conocer la disponibilidad y operatividad de los
materiales, equipos y productos dentro de la empresa. Todo sistema de control debe
permitir facilitar, precisar la información de las diversas existencias disponibles, procesos,
según la oferta y la demanda de producción.

La empresa de Chocolates INCADEX SRL. es una entidad establecida en Bolivia

ofreciendo sus diferentes productos achocolatados, cuenta con diferentes sistemas de
información automatizada dentro de la parte administrativa, su estabilidad laboral impone
una actualización constante del manejo de su información, y le obliga a sí mismo a
involucrarse a las diferentes tecnologías, existen varios campos de sistematización para ser
involucrados, más dan mayor importancia a la calidad de su producción, donde el control
principal del inventariado está definido por la recepción, almacenamiento y movimiento

1
inventariado está definido por la recepción, almacenamiento y movimiento dentro de su
correspondiente almacén hasta el punto de consumo de material y salida de producción.

1.2. Antecedentes

1.2.1. Antecedentes Institucionales

Visión

Tener presencia en el mercado, desarrollando un liderazgo eficiente de ventas mediante una

red de comercialización innovadora en el rubro, certificando la calidad de un producto de
alto nivel que responde a las necesidades de su clientela promedio de un mejoramiento
continuo, de este modo permitiendo a la empresa desarrollarse en el mercado boliviano con
expectativas de crecimiento y expandirse a nuevos mercados nacionales e internacionales.

Misión

La empresa INCADEX S.R.L. se dedica a la elaboración de chocolates y sus derivados,

satisfaciendo las expectativas de sus clientes a través de un compromiso integral que se
fundamenta en la calidad de sus productos, se dedica a la elaboración de chocolates y sus
derivados. La compañía está localizado en La Paz, Bolivia, tiene el principal trabajo en la
elaboración de detalles alimenticios, chocolates y otras actividades de negocios, fundada el
23 de enero de 1978, idea iniciada y trabajada por la familia, actualmente cuenta con un
equipo de trabajo especializado en la elaboración y fabricación de los chocolates.

INCADEX S.R.L. Entre sus productos bombones y tabletas, podemos mencionar:

• Corazón Mediano: Chocolate con un toque de chocolate blanco.

• Caja Corazones: contenido forma de corazón puro chocolate.

• Caja bombones: variados sabores de frutas que están dentro del chocolate.

2
• Caja Preludio: chocolate mezclado con chocolate blanco y chocolate de menta.

• Caja Jellies: Bombones de Chocolate: vainilla, frutilla mora, piña y limón.

• Caja Trinity: chocolate dietético bañado puramente con el chocolate negro.

• Las tabletas: de pasas, maní, jaleas de distintos sabores de fruta.

La variedad aun expande mucho más de lo mencionado claro ejemplo está en la variedad
que existe en la elaboración de cada producto que se trabaja y muestra ante la sociedad,
más de treinta años de trabajo, después se convirtió en la mayor industria de chocolates de
Bolivia. Bombones, tabletas, grageas conforman una lista de más de cien productos que la
empresa elabora hoy en día.

1.2.1.1 Organización De La Empresa

Esta entidad está a cargo de manera general y principal de un gerente, jefe de planta y
subjefe de las diversas secciones establecidas en la unidad empresarial, además que cuenta
con un personal diverso destinados a cargos diferentes que trabajan el orden
correspondiente a cada área destinada de la fabricación, producción y ventas. Ver la figura

Figura.1.1. Organigrama de la Empresa

Fuente: INCADEX S.R.L., 2016

3
1.2.1.2 Manejo de Inventarios

El manejo de Inventarios dentro de la empresa se realiza a través de una computadora con sistema
operativo Windows, tiene instalado Office Excel como herramienta de registro de bienes. Ver tabla
1.1 ejemplo de control de inventarios.

Tabla 1.1 Registro de Control de Inventarios

Fuente: Luna, 1990

La materia prima tiene un ingreso que se registra en notas que posteriormente son trasladadas a
informes realizados en Excel, con la intención de obtener un orden y reporte de lo ingresado, más
existen diferentes inconvenientes como la mala escritura de la nota realizada, antes de ser transcrita,
muchas veces la información de la materia tiene unidades de medida diferentes al Sistema
Internacional SI y provoca un mal registro del mismo. A lo referido a la manera de registrar no
existe correspondencia en los datos referentes a la materia prima, bien tangible o intangible,
producto. Se puede decir que carece de un orden necesario dentro de manejo de información. Existe
materia prima que es recogida de manera periódica y que no está disponible en cualquier momento
o también cuando se adquiere material en grandes cantidades ya sea en periodos largos o cortos.
Los inventarios tienen una rutina muy variada desde que sale del almacén hasta que esta ingresa la
manufacturación siempre será acorde a lo pedido basado siempre en las recetas que tiene la misma
empresa terminando un largo proceso de elaboración vemos el largo listado complicado a la hora de

4
que estos acaben ya que siempre existirá un margen de producto aun no terminado en su
elaboración.

1.2.1.3. Producción y Manufacturación del Chocolate

A lo que corresponde a la manufacturación del chocolate se puede decir que comienza de la

siguiente manera. El material de ingreso para la elaboración del chocolate contiene cacao de
chocolate, leche, azúcar, entre otros materiales que son principales para la producción del chocolate,
inicialmente se prevé el material necesario, donde se intenta calcular cuánto será necesario para un
número definido de producción. Se puede considerar las siguientes divisiones de producción:

Sección 1 Se realiza el Tostado de cacao, Pelado,

Molido, Prensado y la Cocoa.

Sección 2 Preparado del Chocolate.

Se realiza el Templado de Chocolate, que a su

vez existen dos sub secciones: Tableteadora y
Sección 3
Etiquetado de Tabletas

Correspondiente a productos secos bañados en

Chocolate, esta sección debe efectuar el bañado
de grajeas, productos secos (pasas, almendras y

Sección 4 otros), una vez terminado entra a Flopak y

posteriormente sale el producto en Bolsitas para
luego contabilizar las cajas.

5
 Propio a bombonería, hacen diferentes tipos de
productos con cremas o con fondant, referido al
Sección 5
proceso de preparado de chocolate

Tabla 1.2. Secciones de producción y Manufacturación

Fuente: Elaboración propia

1.2.1.4. La Producción Final

La finalidad de elaboración varía de acuerdo a la oferta y la demanda solicitada desde

gerencia, aunque cuentan con intervalos de las cantidades aproximadas por temporadas
(Navidad, Pascua, y otros).

1.2.2. Proyectos Similares

“Sistema De Información Web Contable”

Caso: ACERCATE S.R.L.”

Autor: Edith Carmiña Aguirre Ochoa; 2015

El paradigma del desarrollo ágil á constituido metodologías, lenguajes de programación,

entornos de trabajos, de los cuales muchos son de código abierto, esto hace que el
desarrollo de proyectos de software a medida para entidades emergentes sea viable y hasta
exitoso dependiendo de la innovación y experiencia del personal. Es así que en el desarrollo
del proyecto sistema contable para la empresa “ACERCATE S.R.L” se han implementado.

Sistema “Web para el Control y Seguimiento de los Entes Gestores

Caso: Instituto Nacional De Seguros De Salud INASES”

Autor: José Manuel Loza Troche; 2015

6
Este proyecto hizo un sistema para apoyar las actividades de parte de un diseño de afiliados
de las cajas de seguro y las aportaciones que realiza las personas a la hora de su registro de
procesos. Con el sistema web se pueden registrar afiliados a una única base de datos, de
esta manera se obtendrá la información integra de la población asegurada. También
controla que una persona no se pueda registrar más de una vez y protegerá la información
con seguridad lógica. Dando un servicio más óptimo e eficiente a la hora de pedir su
información personal de los asegurados de las diversas empresas o trabajos de la población
en general optimizando tiempos y protegiendo la información necesaria.

Sistema De Control de Préstamos De Almacenes

Caso: Carrera de Mecánica Industrial Perteneciente a la Escuela Industrial Superior “Pedro

Domingo Murillo”

Autor: Sergio Tito Aranda Guachalla ; 2015

Se desarrolló un sistema de control de préstamos de almacenes, para optimizar el trabajo en

el tiempo de procesos y además llevando un control adecuado de la información. Este
proyecto fue realizado con el modelo de desarrollo de software ágil, denominada Proceso
Unificado Ágil, también conocido como AUP por sus siglas en inglés, esto en cuanto al
análisis del diseño del sistema, también se utilizó la metodología de modelado UWE para la
ingeniería web, basado en UML.

Sistema de Control de Ventas e Inventarios para Almacenes de Aluminios Utilizando

Dispositivos Móviles

Caso: Técnica De Aluminio, Vidrio Y Servicios (Talviser)”

Autor: Grover Gutiérrez Vargas; 2015

7
Este proyecto ha sido desarrollado en las oficinas de TALVISER (Técnica de Aluminio,
Vidrio y Servicios) con el objetivo de automatizar los procesos y optimizar los tiempos de
producción de los procesos que se realizan en la empresa y mediante la tecnología de los
dispositivos móviles se tratara de realizar los procesos en un instante. Para el desarrollo del
proyecto se utilizó la metodología SCRUM, que propone un modelo de proceso
incremental, basado en iteraciones y revisiones continuas de las ventas e inventarios para
almacenes de aluminio mediante el uso de dispositivos que hoy en día hacen más útil en
obtener una información más óptima y rápida en un dispositivo con una información más
actualizada y precisa a la hora de hacer un proceso de recepción a la hora de ventas u/o
control de inventarios correspondientes a la institución.

1.3. Planteamiento del Problema

1.3.1. Problema Central

De la entrevista realizada por el jefe de planta y el responsable del almacén de la empresa

INCADEX S.R.L. se logró identificar: El área del almacén, secciones de elaboración,
proceso y terminado final del producto, funcionando de la siguiente manera:

Primero el ingreso de materia prima utilizado por la empresa es de acuerdo al pedido que la
misma hace, las cantidades pedidas varían de acuerdo al tiempo, precio, calidad que el
proveedor pueda llegar a ofrecer.

El encargado del almacén recibe el material pedido, tomando nota de cada ingreso de venta
hacia la empresa con su respectiva factura, para luego estos datos de ingresos puedan ser
añadidos en una hoja de cálculo manteniendo así el orden de manera que no puedan perder
información alguna desde que ingresa hasta q sale de la unidad de sección.

El uso de los materiales a la hora de ser pedidos para luego ser procesados y tener un
producto acabado son administrados por el jefe del almacén, el mismo da la cantidad
pedida a los responsables de cada sección. El pedido es realizado de manera manual y los

8
reportes que obtiene el jefe de almacén son enviado de forma escrita al jefe de planta el
cual actualizara dicha información. El preparado de chocolate (material principal) lleva un
proceso continuo de mezcladora, refinadora y conching. El proceso del chocolate entre
otros alimentos tiene un determinado tiempo, espacio de preparación, como ser la
bombonería, tableteadora y bombos graneadores. Una vez que el producto termina su
proceso de preparación y moldeado este pasa a un control de calidad: etiquetadora,
envolvedora, flowpack.,el proceso que la misma lleva tiende a ser largo y detallado siempre
velando por la calidad que la empresa brinda en cada uno de los productos a la hora de ser
expuestos en venta .

¿Cómo mejorar el control de inventarios, manufacturación y producto final para la

empresa Industrial, Comercial de alimentos INCADEX S.R.L.?

1.3.2. Problemas Secundarios.

Observando la manera de cómo se maneja el almacén, inventarios se identificaron los

siguientes problemas.

• El control sobre las cantidades de materiales que ingresan y salen de los

almacenes, puede provocar perdida de datos al momento de registrarlos, así afectando el
proceso de salida y emitiendo reportes erróneos

• Al momento de realizar las entradas en los almacenes de INCADEX S.R.L. se

realiza un proceso manual sobre los registros de cada insumo; ocasionando replica, perdida
e inconsistencia de la información de los materiales.

• El proceso de control en los materiales que se procesan es lento y tedioso, debido a

la cantidad de insumos y el registro manual, esto provoca demoras al momento de realizar
los informes. Control manual en la recepción del material prima ocasionando que no se
tenga informes de apoyo para una buena toma de decisiones a la hora de tener el producto
final.

9
• La falta de seguridad en el sistema, que es un proceso manual que realiza la
Agencia, puede provocar gastos insulsos y manejo indebido al presupuesto designado por
departamento.

• No se cuenta con un control de las cantidades sobrantes ya que la cantidad pedida

no siempre es utilizada en su totalidad.

1.4. Definición De Objetivos

1.4.1. Objetivo General

Desarrollar un sistema Web de Control de Inventarios, Manufacturación y Producto Final,

desde la recepción de la materia prima, almacenamiento, elaboración hasta la salida de
producción, para la empresa INCADEX SRL.

1.4.2 Objetivos Especificos

• Analizar y evaluar de forma general la situación actual de gestión en almacenes.

Posteriormente automatizar el proceso de gestión, desarrollo de registro, el procedimiento
de pedido, el registro de ingresos y salidas de los materiales.

• Generar el proceso de ingreso de materiales, asignando a cada insumo, posteriormente

se almacenara un informe detallado del Ingreso en la base de datos, descartando la
transcripción de datos manualmente.

• Implementar diferentes mecanismos de búsquedas de los inventarios, manufacturación y

producto final emitiendo informes, reportes, de información detallada rápida y segura sobre
los insumos en tiempos óptimos.

• Implementar mecanismos de actualización segura en la base de datos. Cuando ingrese o

se realice la entrega de pedido se emitirá el stock real. Actualizando los movimientos que
fueron realizados desde el sistema web.

10
1.5. Justificación

Las justificaciones que se darán a conocer serán en visión acorde a la empresa:

1.5.1 Económica

La falta de organización actualizada hace que implemente nuevas visiones, técnicas de

métodos que logren que la empresa INCADEX S.R.L. sea competitiva ante las demás
demandas mediante la ejecución de tiempo, calidad ,cantidad entrante, mediante un buen
manejo en almacenes inventarios permitirá incrementar los beneficios en la empresa,
mejorando y haciendo un manejo eficiente de la información; reduciendo el tiempo de
elaboración de informes, brindando un mejor control en el stock de materiales, realizando
informes de reportes actualizados, satisfaciendo así las necesidades del usuario. Los
beneficios que se obtendrá del proyecto son los siguientes:

• Disminución del tiempo de trabajo diario al momento de realizar los registros.

• Acortar el manejo de gran cantidad de documentos para el proceso de control en los

almacenes, evitando pérdida y desgaste de estos.

• Reducir los pedidos innecesarios, ahorrando tiempo y dinero, beneficiando al trabajo

diario y la economía de la agencia.

• Priorizaremos más otras funciones que no influyan tanto a un gasto alguno a la hora de
hacer la ejecución del código.

1.5.2. Social

El sistema ayudara al personal de una manera ordenada y precisa a la hora de entrega

correspondiente de los diversos materiales que ingresan al almacén, el proveedor tendrá un
de tiempo ya no tardío sino eficaz para tener un mejor manejo de cada uno de los diversos
materiales.

11
Optimizando las áreas funcionales y movimiento garantizara un suministro continuo y
oportuno de los materiales y medios de producción requeridos para asegurar los servicios
de forma ininterrumpida y rítmica para la empresa dando lugar también a un tiempo
reducido y de gran beneficio para el usuario (jefe de planta).

Los informes y reportes serán de manera inmediata, brindando datos actualizados para el
beneficio de las actividades diarias que realiza la Agencia. El almacenero ya no realizará el
trabajo tedioso de registrar e informar manualmente; al reducir el desgaste humano el
personal aumentara su nivel tanto competitivo como productivo a la hora de obtener los
datos y darlos a conocer al jefe de planta datos que son de aviso de control de inventario o
aviso terminado del proceso de la empresa.

1.5.3 Tecnológica

La tecnología es una herramienta indispensable para las empresas, instituciones o entidades

públicas y privadas, las cuales requieren manejar una gran cantidad de información
importante, para ello una institución debe contar con las herramientas y equipos necesarios.

Cuentan con seis servidores de la cual una está específicamente destinada a ser manejada
por el Jefe de Planta el cual administrara todos los datos de almacén, proceso y acabado del
producto.

Características: Servidor de 2 Gb de RAM, almacenamiento de 80 Gb y una salida online

de 4 Mb. Se realiza el control de ingresos y egresos de forma manual o semiautomática
utilizando Microsoft Excel. La elaboración del proyecto se justifica técnicamente con
equipos de computación, servidor y los recursos necesarios para el desarrollo,
implementación y el normal funcionamiento del sistema.

12
1.6. Alcances Y Límites

1.6.1. Alcances

El presente proyecto tiene como alcances:

• Módulo de Registro Personal

 Registrar personal
 Registrar proveedores
 Noticia

• Módulo de inventarios

 Registrar materia prima: manejo de stock

 Registrar herramientas u/o maquinaria
 Informe de producto por acabar
 aviso de los movimientos
 informe detallado de la materia prima

• Módulo de manufacturación

 Registrar receta
 Procesar receta
 Galería de productos

• Modulo producto terminado

 Registro de producto terminado

1.6.2 Limites

El sistema web a desarrollar tiene los siguientes límites:

13
• Solo podrá ser usado por la empresa INCADEX S.R.L.

• Uso especial para quien supervisa todo tipo de material del almacén, proceso y final del
producto.

• La aplicación web solo podrá ser utilizado por el jefe de área.

• El sistema no generara reportes de los datos para los empleadores.

1.7. Aportes

1.7.1. Práctico

El aporte a la empresa Industrial, Comercial INCADEX S.R.L. se hace con la elaboración

de un Sistema Web de Control de Inventarios ,Manufacturación y Producto final para una
información optima detallada cumpliendo las necesidades del personal de la gestión de
almacenes, secciones de proceso de manufacturación los aportes para el presente proyecto
de grado son:

• Aportes de herramienta de control para la Unidad de Almacenes facilitando el manejo

diario de la información.

• Herramientas que colaboren el flujo de la información de manera rápida y confiable

entre los departamentos de distribución.

• El aporte principal es la creación e implementación de una fusión metodológica agiles

como ser Scrum y uso del modelado UWE

Al momento de ingresar los materiales a los almacenes, estos pasaran a la etapa de

identificación, el aporte principal del sistema es la implementación de un control actualizado
novedoso que con un trabajando de plataforma mixta deberá de priorizar un exactitud
precisa y veras, el desarrollo del sistema tendrá la función principal de agilizar las salidas de

14
los materiales, registrando estos que se les asignó al momento del ingreso, posteriormente
será almacenado en la base de datos del servidor.

1.7.2. Teórico

El aporte principal del proyecto Sistema de Control y manufacturación, y producto final

para la empresa industrial comercial de alimentos INCADEX S.R.L. es la Implementación
del Software el cual contribuirá a un mejor control de almacenes, facilitando el manejo de
información en tiempo real, que actualmente no se tiene .

1.8. Metodología

1.8.1 Metodología de Investigación

El proceso de investigación se aplicara un método científico. Un método científico es un

conjunto de mecanismos que nos ayuda a comprender un problema de la naturaleza. La
elaboración de la investigación necesita de un proceso, donde se sabe que se busca
utilizando métodos, técnicas y procedimientos adecuados.

Existen muchas versiones de métodos o procesos de investigación. El método científico de

Arias Galicia será aplicado al proceso de investigación del proyecto. Arias, 2015.

Se realizara una investigación descriptiva, donde analizaremos las características y rasgos

de la situación. También la investigación explicativa o causal nos facilitara el análisis de
causa y efecto de la relación de nuestras variables.

1.8.2 Metodología de Ingeniería

El elemento principal para la evolución de sistemas y los productos basados en herramientas

computacionales, proponiendo soluciones eficientes y eficaces a los problemas que aquejan
los informáticos. Cumpliendo el modelo de calidad de Software ISO 9126, para el
desarrollo óptimo del sistema se trabajara con una metodología de desarrollo. En las fases de

15
análisis, diseño, implementación y pruebas de la aplicación, se utilizó la metodología ágil de
desarrollo de software Scrum, complementada con las herramientas de modelado web que
proporciona UWE que estará orientado a las aplicaciones que hacen uso intensivo de datos,
control gestión general de almacenes, proceso y terminado final que trabajara y será de gran
ayuda con la gran cantidad de datos, para la implementación del sistema web.

16
 Capítulo II

Marco Teórico

2.1 Ingeniería De Software

El software para muchas personas son solo programas de computadora, sin embargo nos
comenta que son todos aquellos documentos asociados a la configuración de datos que se
necesitan para hacer que estos programas operen de manera adecuada. Estos productos de
software se desarrollan para algún cliente en particular o para un mercado en general. Para el
diseño y desarrollo de proyectos de software se aplican metodologías, modelos y técnicas que
permiten resolver los problemas. En los años 50 no existían metodologías de desarrollo, el
desarrollo estaba a cargo de los propios programadores. De ahí la importancia de contar con
analistas y diseñadores que permitieran un análisis adecuado de las necesidades que se
deberían de implementar. Sommerville ,2005.

El objetivo principal que busca la ingeniería de software es convertir el desarrollo de software

en un proceso formal, con resultados predecibles, que permitan obtener un producto final de
alta calidad y satisfaga las necesidades y expectativas del cliente. La Ingeniería de Software es
un proceso intensivo de conocimiento, que abarca la captura de requerimientos, diseño,
desarrollo, prueba, implantación y mantenimiento. Generalmente a partir de un complejo
esquema de comunicación en el que interactúan usuarios y desarrolladores, el usuario brinda
una concepción de la funcionalidad esperada y el desarrollador especifica esta funcionalidad a
partir de esta primera concepción mediante aproximaciones sucesivas. Este ambiente de
interacción motiva la búsqueda de estrategias robustas para garantizar que los requisitos del
usuario serán descubiertos con precisión y que además serán expresados en una forma
correcta y sin ambigüedad, que sea verificable, trazable y modificable. Gacitúa ,2003.

La ingeniería de software es una disciplina de la ingeniería que comprende todos los aspectos
de la producción de software desde las etapas iniciales de especificación del sistema hasta el
mantenimiento de este después que se utiliza

17
2.1.1 Etapas del Proceso

De acuerdo con Roger Pressman (2002), las etapas metodológicas a llevar a cabo para el
desarrollo de Sistemas de Información, se establecen de la siguiente manera:

2.1.1.1. Análisis de los requisitos del software

El proceso de reunión de requisitos se intensifica .y se centra especialmente en el software.

Dentro del proceso de análisis, es fundamental Que a través de una colección de
requerimientos funcionales y no funcionales, el desarrollador o desarrolladores del software
comprendan completamente la naturaleza de los programas que deben construirse para
desarrollar la aplicación, la función requerida, comportamiento, rendimiento e interconexión.
Es de suma importancia que antes de empezar a codificar los programas, se tenga una
completa y plena comprensión de los requisitos del software. Pressman establece que la tarea
del análisis de requisitos es un proceso de descubrimiento, refinamiento, modelado y
especificación. Se refina en detalle el ámbito del software, y se crean modelos de los
requisitos de datos, flujo de información y control, y del comportamiento operativo. Se
analizan soluciones alternativas y se asignan a diferentes elementos del software. El análisis
de requisitos permite al desarrollador o desarrolladores especificar la función y el rendimiento
del software, indica la interfaz del software con otros elementos del sistema y establece las
restricciones que debe cumplir el software.

2.1.1.2. El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo,
que son:

a) Reconocimiento del problema.-Reconocer los elementos básicos del problema tal y

como los perciben los usuarios finales.

b) Evaluación y síntesis.- Definir todos los objetos de datos observables externamente,

evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del

18
software, entender el comportamiento del software en el contexto de acontecimientos que
afectan al sistema.

c) Modelado.- Crear modelos del sistema con el fin de entender mejor el flujo de datos y
control, el tratamiento funcional y el comportamiento operativo y el contenido de la
información.

d) Especificación. Realizar la especificación formal del software.

e) Revisión. Un último chequeo general de todo el proceso.

2.1.1.3. Diseño

Según Pressman, el diseño del software es realmente un proceso de muchos pasos pero que se
clasifican dentro de uno mismo. En general, la actividad del diseño se refiere al
establecimiento de las estructuras de datos, la arquitectura general del software,
representaciones de interfaz y algoritmos. El proceso de diseño traduce requisitos en una
representación de software.

El diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema de

ingeniería. De acuerdo con Pressman, el objetivo del diseño es producir un modelo o
representación de una entidad que se va a construir posteriormente.

El diseño, es la primera de las tres actividades técnicas que implica un proceso de ingeniería
de software; estas etapas son diseño, codificación y pruebas. Generalmente la fase de diseño
produce un diseño de datos, un diseño arquitectónico, un diseño de interfaz, y un diseño
procedimental.

19
2.1.1.4. Generación de Código

Esta actividad consiste en traducir el diseño, en una forma legible por la máquina. La
generación de código se refiere tanto a la parte de generación de los ambientes virtuales,
como a la parte en la cual se añadirá comportamiento a estos ambientes.

a) Pruebas: Una vez que se ha generado código, comienzan las pruebas del software o
sistema que se ha desarrollado. De acuerdo con Pressman, el proceso de pruebas se centra en
los procesos lógicos internos del software, asegurando que todas las sentencias se han
comprobado, y en los procesos externos funcionales, es decir, la realización de las prueba para
la detección de errores. En el caso de una herramienta de software, es necesario tener etapas
de pruebas tanto para la parte funcional del software, como para la parte aplicativa del mismo.

b) Mantenimiento: El software indudablemente sufrirá cambios, y habrá que hacer algunas

modificaciones a su funcionalidad. Es de suma importancia que el software de calidad pueda
adaptarse con fines de acoplarse a los cambios de su entorno externo. Por medio de la
documentación apropiada y atinada del software se pueden presentar las vías para el
mantenimiento y modificaciones al mismo.

2.1.2 Modelos de Procesos de Software

2.1.2.1 Modelos Tradicionales

El modelo está formado por un conjunto de fases o actividades en las que no tienen en cuenta
la naturaleza evolutiva del software, las cuales son:

a) Ciclo de vida También se le conoce como modelo lineal secuencia o modelo en cascada.
Plantea un enfoque sistemático, secuencial para el desarrollo de software, que comienza en un
nivel de sistemas y continúa con el análisis, diseño, codificación, pruebas y mantenimiento.
Este modelo comprende una primera actividad como lo es La Ingeniería y modelado de

20
sistemas / información, en el cual se establece el sistema de nivel superior y se deben
establecer los requisitos de la empresa en la que se encuentra. Los requisitos se recogen del
sistema con una pequeña parte de análisis y diseño

b) Basado en Prototipos Este paradigma se inicia con la recolección de requerimientos. El

desarrollador y el cliente encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más
definición. Luego aparece un “diseño rápido”. El diseño rápido está centrado en una
representación de los aspectos del software que serán visibles para el usuario-cliente. El
diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente-usuario
y lo utiliza para refinar los requisitos del software a desarrollar. La interacción ocurre cuando
el prototipo satisface las necesidades del cliente, a la vez que permite que el desarrollador
comprenda mejor lo que se necesita hacer.

c) Modelo DRA El Desarrollo Rápido de Aplicaciones (DRA) es un modelo de proceso

del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo
extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del modelo
lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque de construcción
basado en componentes.

2.1.2.2 Modelos Evolutivos

El software al igual que todos los sistemas complejos, evoluciona con el tiempo desarrollando
versiones cada vez más completas y complejas hasta llegar al objetivo deseado incluso
evolucionar más allá durante la fase de la operación. Los requisitos de gestión y de productos
a menudo cambian conforme a que el desarrollo proceda haciendo que el camino que lleva al
producto final no sea real; las estrictas fechas tope del mercado hacen que no sea posible
finalizar un producto completo, por lo que se debe introducir una versión limitada para
cumplir la presión competitiva y de gestión; se comprende perfectamente el conjunto de

21
requisitos de productos centrales o del sistema, pero todavía se tienen que definir los detalles
de extensiones del producto o sistema.

En estas y en otras situaciones similares, los ingenieros del software necesitan un modelo de
proceso que se haya diseñado explícitamente para acomodarse a un producto que evolucione
con el tiempo.

Los modelos que se adaptan a la evolución son:

a) Modelo Espiral

b) Evolutivo

c) Incremental n

d) Modelo de desarrollo concurrente

2.1.2.3 Modelos para Sistemas Orientado a Objetos

Es la construcción de modelos de un sistema por medio de la identificación y especificación

de un conjunto de objetos relacionados, que se comportan y colaboran entre sí de acuerdo a
los requerimientos establecidos para el sistema de objetos.

Son modelos con alto grado de interactividad y solapamiento entre fases, como ser:

a) De agrupamiento

b) Fuente

c) Basado en Componentes

d) Proceso Unificado

22
2.1.2.4 Procesos Agiles

Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de

software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último
momento).

Entre las metodologías ágiles identificadas son:

a) Extreme Programming (XP)

b) Scrum

c) Familia de Metodologías Crystal

d) Feature Driven Development

e) Proceso Unificado Rational, una configuración ágil

f) Dynamic Systems Development Method

g) Adaptive Software Development

h) Open Source Software Development

2.2 Metodología de Desarrollo Scrum

Scrum es una metodología ágil de gestión de proyectos de desarrollo de software, basada en

un proceso de trabajo constante, iterativo e incremental que se utiliza para resolver situaciones
en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan
demasiado, los costes se disparan o la calidad no es aceptable.

23
Creada por Jeff Sutherland en 1993, de las metodologías ágiles, es la más utilizada, según una
encuesta publicada por VersionOne en 2010 realizada a 4770 entrevistados de 91 países. La
misma, revela que el 58% de los encuestados, utiliza Scrum como metodología para la gestión
de proyectos de desarrollo de Software.

VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo

presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo
de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del
Manifiesto ágil. En el desarrollo de software Scrum está considerado como modelo ágil por la
Agile Alliance.

Sus principales características son:

a) Equipos auto dirigidos

b) Utiliza reglas para crear un entorno ágil de administración de proyectos

c) No prescribe prácticas específicas de ingeniería

d) Los requerimientos se capturan como ítems de la lista Product Backlog

e) El producto se construye en una serie de Sprints de un mes de duración

f) Gestión regular de las expectativas del cliente

2.2.1 Herramientas de la Metodología

2.2.1.1 Pila de Producto

La Pila de Producto, o Product Backlog, es un artefacto del marco de trabajo para la gestión
agile de proyectos de desarrollo de software, SCRUM. y que es, en líneas generales, una lista
ordenada u priorizada de las tareas que componen un proyecto de aplicación.

24
Aunque SCRUM no lo define, el formato que más se utiliza para la tarjeta de trabajo que
compone una Pila de Producto es la Historia de Usuario. Sin que haya mayores problemas en
utilizar Casos de Uso, o una lista de tareas.

Lo importante es que el propio esfuerzo de realizar la división en tareas implica una

organización del trabajo y una primera visión del alcance del proyecto. Es decir, qué es lo que
se quiere obtener después de semanas o meses de trabajo.

La Pila de Producto, según Scrum, es propiedad del Dueño del Producto. Es decir el cliente
final o su representante. Esto suena un tanto utópico ya que es muy difícil encontrar a un
cliente que le pueda o quiera dedicar el tiempo y dedicación que requiere una gestión Agile de
un proyecto. Las propiedes dependerán siempre del dueño del producto porque visualizara lo
que desea desde el punto cliente.

Teniendo en cuenta que es un artefacto vivo y que va a sufrir modificaciones tanto de

prioridad como de alcance durante todo el proyecto, se construye una primera Pila de
Producto que comprenda la descripción de las funcionalidades esperadas a alto nivel.

En este momento el Product Backlog empieza a mostrar sus ventajas. Es un punto inicial para
gerencia, si hubiese que presentar una oferta al cliente, en la estimación en tiempo y dinero
del coste del proyecto. Ya que la definición del alcance la genera el propio cliente, o las
personas que más saben sobre lo que quieren que realice la futura aplicación.

Por otra parte, el equipo adquiere la primera visión del proyecto. Cuál es el objetivo y la
motivación que ha llevado al cliente a pensar en que un desarrollo de software puede ser una
ventaja o una solución a sus necesidades. En definitiva, porque es una mejora.

Y el cliente puede observar de forma visual y cómoda todo el trabajo que representa el
construir su proyecto, decidir las funciones que más valor le aportan y detectar que cosas
puede dejar en duda, por si no fuera necesario o interesante de construir.

25
Otra gran ventaja de utilizar Pilas de Producto es que permite encapsular una metodología
Agile, como Scrum, dentro de un proceso formal de gestión de proyectos. Es decir, puedo
cumplir con los artefactos clásicos de toma de requisitos, análisis funcional, análisis técnico,
etc. Y, simultáneamente construir el Product Backlog (aunque con más esfuerzo) para
empezar a desarrollar y a obtener software que funcione de forma iterativa.

2.2.1.2 Product Backlog List

La Product Backlog list es una lista priorizada que define el trabajo que se va a realizar en el
proyecto. Cuando un proyecto comienza es muy difícil tener claro todos los requerimientos
sobre el producto. Sin embargo, suelen surgir los más importantes que casi siempre son más
que suficientes para un Sprint. La Product Backlog List puede crecer y modificarse a medida
que se obtiene más conocimiento acerca del producto y del cliente. Con la restricción de que
solo puede cambiarse entre Sprints. El objetivo es asegurar que el producto definido al
terminar la lista es el más correcto, útil y competitivo posible y para esto la lista debe
acompañar los cambios en el entorno y el producto. Existe un rol asociado con esta lista y es
el de Product Owner. Si alguien quiere realizar cualquier modificación sobre la lista por
ejemplo: agregar o incrementar la prioridad de sus elementos tiene que convencer al Product
Owner.

2.2.1.3 Sprints

Esta herramienta es el procedimiento de adaptación de las cambiantes variables del entorno

(requerimientos, tiempo, recursos, conocimiento, tecnología). Son ciclos iterativos en los
cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante un
Sprint el producto es diseñado, codificado y probado. Y su arquitectura y diseño evolucionan
durante el desarrollo.

El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fácil de recordar y
esté siempre presente en el equipo. Es posible definir una serie de restricciones que el equipo
deba aplicar durante un Sprint.

26
Un Sprint tiene una duración planificada de entre una semana y un mes. No es posible
introducir cambios durante el Sprint, por lo tanto para planificar su duración hay que pensar
en cuanto tiempo puedo comprometerme a mantener los cambios fuera del Sprint.
Dependiendo del tamaño del sistema, la construcción de un release puede llevar entre 3 y 8
Sprints. Por otra parte podrían formarse equipos para desarrollar en forma paralela distintos
grupos de funcionalidad.

El Sprint Backlog Es el punto de entrada de cada Sprint. Es una lista que tiene los ítems de la
Product Backlog List que van a ser implementados en el siguiente Sprint ,cualquier momento
si lo considera necesario para cumplir el objetivo. Pero el Sprint Backlog solo puede ser
modificado por el equipo. Las estimaciones se actualizan cada vez que aparece nueva
información.

2.2.2 Roles y Responsabilidades

Para orquestar este proceso, SCRUM distingue actores con diferentes papeles dentro del
proceso. De forma general, podemos distinguir propietario del producto o Product Owner,
master de scrum o Scrum Mastere, equipo de desarrollo o Scrum Team y cliente o usuario.

2.2.2.1 Product Owner

El Product Owner es la única persona responsable de delinear el producto más valioso posible
para la fecha deseada. Esto se logra gestionando el flujo de trabajo hacia el equipo, que a su
vez se lleva a cabo seleccionando y refinando ítems del Product Backlog. El Product Owner
mantiene el Product Backlog y asegura que todos sepan qué hay en él y cuáles son las
prioridades. El Product Owner puede ser ayudado por otros individuos pero el rol debe ser
ocupado por una única persona.

Ciertamente, el Product Owner no es responsable de todo. El Equipo Scrum completo es

responsable de ser lo más productivo posible, de mejorar sus prácticas, de hacer las preguntas
correctas, de ayudar al Product Owner. El Equipo de Desarrollo es responsable de determinar

27
cuánto trabajo puede ser tomado en un Sprint, y de producir un Incremento de Producto al
finalizar el mismo.

De todas formas, el Product Owner, en Scrum, se encuentra en una posición única. Suele ser
la persona más cercana al “costado del negocio" de todo el proyecto. Es típicamente el
encargado de "sacar el producto" y quien se espera hará el mejor trabajo posible en cuanto a
satisfacer a todas las partes interesadas. El Product Owner lleva adelante esta tarea mediante
la gestión del Product Backlog y asegurándose que el Product Backlog y el avance contra éste
se mantengan visibles.

El Product Owner, al decidir sobre qué debe hacer y qué posponer el Equipo de Desarrollo,
toma las decisiones de alcance versus fechas que llevan al mejor producto posible.

2.2.2.2 Scrum Master

El Scrum Master es un "líder servicial", que ayuda al resto del equipo Scrum a seguir su
proceso. Debe tener una buena comprensión de Scrum y la habilidad de capacitar a otros en
sus sutilezas, trabaja junto al Product Owner para que éste logre crear y mantener el Product
Backlog, junto al equipo de desarrollo para encontrar e implementar las prácticas técnicas que
les permitirán tener un Incremento de producto 'Hecho' al final de cada Sprint. También
trabaja con el Equipo Scrum completo para evolucionar la definición de hecho.

El Scrum Master también es responsable de velar por la remoción de los impedimentos al

avance del equipo. Estos impedimentos pueden ser externos al equipo, como por ejemplo la
falta de apoyo de otro equipo, o internos, como ser que el Product Owner no sepa preparar el
Product Backlog de forma adecuada.

Asi también fomenta el auto organización. Los problemas deben ser resueltos por el equipo
siempre que sea posible. El Scrum Master actúa como coach para el Equipo Scrum, ayudando
a sus miembros a ejecutar el proceso Scrum. Los ayuda a trabajar juntos y a aprender el
framework Scrum, al tiempo que los protege de distracciones tanto internas como externas.

28
Puede facilitar reuniones y ayuda a mantener al equipo Scrum en el buen camino, productivo
y creciendo en sus capacidades, es responsable de asegurar que Scrum sea comprendido e
implementado, tanto dentro como fuera del equipo. Ayuda a personas fuera del equipo a
entender el proceso y a comprender qué interacciones con el equipo son valiosas y cuáles no.

2.2.2.3 Scrum Team

El Scrum Team Es un grupo de personas encargadas de desarrollar e implementar la

funcionalidad pactada. El equipo se auto administra y auto organiza. Las personas que lo
componen, deben utilizar su ingenio para incrementar la funcionalidad cumpliendo con los
requerimientos a lo largo de cada iteración. Los miembros del equipo son responsables del
éxito de cada sprint.

La auto administración y auto organización es un aspecto crucial en Scrum. Es indispensable

que todos los miembros del Team estén comprometidos con su trabajo y para ello es necesario
contar con la motivación de los mismos. En un Team que se auto organiza y auto administra,
no hay una persona encargada de controlar que todos los miembros estén cumpliendo sus
tareas en tiempo y forma. Sino que cada uno de los integrantes es responsable de realizar sus
tareas y además debe asegurarse que el resto de los miembros hagan lo propio con sus tareas
respectivas. El Team debe trabajar en conjunto como un bloque. Sus resultados son producto
del trabajo colectivo y no de esfuerzos individuales.

Idealmente, se recomienda que el Team esté formado por no más de siete personas. A medida
que el Team aumenta en cantidad de personas, aumenta la posibilidad que el Team no
funcione como tal, dado que habrá miembros que perderán la motivación y el compromiso
necesario para el correcto funcionamiento del Team.

En algunas situaciones, cuando se cuente con un Team formado por más de diez personas, es
recomendable dividir este equipo en distintos sub equipos. La subdivisión puede hacerse
según las responsabilidades (un equipo de desarrolladores, un equipo de qa, un equipo de

29
analistas funcionales) o según las necesidades del negocio en sub equipos que incluyan todos
los roles.

Cuando se armen sub equipos formados solamente por desarrolladores, qa o analistas

funcionales, es necesario encontrar una forma para hacer interactuar a los distintos sub
equipos. Para ello puede realizarse, semanalmente, una reunión de Scrum con un
representante de cada subequipo. De esta forma los equipos estarán al tanto de las actividades
de los otros equipos.

La composición del Team es algo que no puede ser absoluta, dado que cada proyecto de
software tiene sus propias características. Es decir algunos proyectos necesitarán mayor
presencia de personas para ocupar ciertos roles que otros. Por ejemplo, en un proyecto
relacionado a data Ming, es necesario contar con algún experto en dicha tecnología y un
administrador de bases de datos, pero en un proyecto empresarial estos roles pueden no ser
necesarios.

Existe la posibilidad que el objetivo de un sprint sea “Encontrar la mayor cantidad de fallas en
el sistema”, con lo cual en ese caso, el Team puede estar formado solamente por personal de
testing el objetivo de este último es averiguar en qué medida una persona se adecua a un
puesto de trabajo determinado es una prueba más del proceso de selección.

También puede ser factible, que el objetivo de un sprint sea “Presentar el diseño de la
refactorización necesaria para utilizar una nueva librería de un tercero”, por lo tanto en ese
caso, es muy probable que el Team esté formado por un grupo de arquitectos, diseñadores y
desarrolladores sin contar con analistas funcionales ni personal de testing. Existen diferentes
técnicas que permiten esta colaboración, desde el Scrum de Scrums hasta equipos de
integración que dedican parte del trabajo trabajo que será trabajado en equipo. Luna, 2000.

30
Una vez que conocimos SCRUM distinguimos actores con diferentes papeles dentro del
proceso. De forma general, podemos distinguir tal como se ve en la Figura 2.1

Figura 2.1. Roles y Responsabilidades

Fuente: T.Zabelava 2000

2.2.3 Proceso de la Metodología

2.2.3.1 Pre – Game

El proceso comienza con la fase de Pre-game, en la que se realiza de forma conjunta con el
cliente una definición sencilla y clara de las características que debe tener el sistema que vaya
a ser desarrollado, definiendo las historias de usuario que van a guiar el proceso de desarrollo
la cual incluye dos sub-fases:

31
• Planning Consiste en la definición del sistema que será construido. Para esto se crea la
lista Product Backlog a partir del conocimiento que actualmente se tiene del sistema. En ella
se expresan los requerimientos priorizados y a partir de ella se estima

el esfuerzo requerido. La Product Backlog List es actualizada constantemente con ítems

nuevos y más detallados, con estimaciones más precisas y cambios en la prioridad de los
ítems.

• Architecture El diseño de alto nivel del sistema se planifica a partir de los elementos
existentes en la Product Backlog List. En caso de que el producto a construir sea una mejora a
un sistema ya existente, se identifican los cambios necesarios para implementar los elementos
que aparecen en la lista Product Backlog y el impacto que pueden tener estos cambios. Se
sostiene una Design Review Meeting para examinar los objetivos de la implementación y
tomar decisiones a partir de la revisión. Se preparan planes preliminares sobre el contenido de
cada release.

2.2.3.2 Game

La fase llamada Game es la parte ágil del Scrum, en esta fase se espera que ocurran cosas
impredecibles. Para evitar el caos Scrum define prácticas para observar y controlar las
variables técnicas y del entorno, así también como la metodología de desarrollo que hayan
sido identificadas y puedan cambiar. Este control se realiza durante los Sprints. Dentro de
variables de entorno encontramos: tiempo, calidad, requerimientos, recursos, tecnologías y
herramientas de implementación. En lugar de tenerlas en consideración al comienzo del
desarrollo, Scrum propone controlarlas constantemente para poder adaptarse a los cambios en
forma flexible.

2.2.3.3 Post – Game

El Post-Game es la fase que contiene el cierre del release. Para ingresar a esta fase se debe
llegar a un acuerdo respecto a las variables del entorno por ejemplo que los requerimientos

32
fueron completados. El sistema está listo para ser liberado y es en esta etapa en la que se
realiza integración, pruebas del sistema y documentación. Vemos que el post-game en los
proyectos debe concluir satisfactoriamente a los días , tiempo establecido el análisis que se da
a conocer es siempre evaluado a todo lo investigado priorisado a detalle en el código dando
lugar al testeo casi exacto que cuan agil surgio la utilidad de la metodología .

El sprint es por tanto el núcleo central que proporciona la base de desarrollo iterativo e
incremental tal como se ve en la Figura 2.1

Figura 2.2. Visión general del proceso de la metodología Scrum

Fuente: Schwaber Beedle, 2006

33
Los elementos que conforman el desarrollo Scrum son:

Las reuniones este elemento es el inicio al desarrollo de uso del Scrum implementando y
ejecutando todo en cuanto a cada reunión se detallara , detalle que será escrito acorde a la
empre u cualquier otra entidad.

Planificación de sprint: Jornada de trabajo previa al inicio de cada sprint en la que se

determina cuál va a ser el trabajo y los objetivos que se deben cumplir en esa iteración.

Reunión diaria: Breve revisión del equipo del trabajo realizado hasta la fecha y la previsión
para el día siguiente.

Revisión de sprint: Análisis y revisión del incremento generado. Pila del producto: lista de
requisitos de usuario que se origina con la visión inicial del producto y va creciendo y
evolucionando durante el desarrollo.

Pila del sprint: Lista de los trabajos que debe realizar el equipo durante el sprint para generar
el incremento previsto.

Incremento: Resultado de cada sprint

2.2.4 Control De Evolución De Proyecto

Scrum controla de forma empírica y adaptable la evolución del proyecto, empleando las
siguientes prácticas de la gestión ágil:

• Revisión de las Iteraciones

Al finalizar cada iteración se lleva a cabo una revisión con todas las personas implicadas en el
proyecto. Este es el periodo máximo que se tarda en reconducir una desviación en el proyecto
o en las circunstancias del producto.

• Desarrollo incremental

34
Durante el proyecto, las personas implicadas no trabajan con diseños o abstracciones. El
desarrollo incremental implica que al final de cada iteración se dispone de una parte del
producto operativa que se puede inspeccionar y evaluar.

• Desarrollo evolutivo

Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e

inestabilidad de requisitos. En Scrum se toma a la inestabilidad como una premisa, y se
adoptan técnicas de trabajo para permitir esa evolución sin degradar la calidad de la
arquitectura que se irá generando durante el desarrollo. El desarrollo Scrum va generando el
diseño y la arquitectura final de forma evolutiva durante todo el proyecto.

• Auto-organización

Durante el desarrollo de un proyecto son muchos los factores impredecibles que surgen en
todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al
gestor de proyectos. En Scrum los equipos son auto-organizados (no autodirigidos), con
margen de decisión suficiente para tomar las decisiones que consideren oportunas.

• Colaboración

Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es
necesaria, porque para que funcione el auto organización como un control eficaz cada
miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y
no según su rol o su puesto.

2.3 Ingeniería Web

La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está
ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la
información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a
realizar todas sus actividades por esta vía.

35
El desarrollo de aplicaciones Web posee determinadas características que lo hacen diferente
del desarrollo de aplicaciones o software tradicional y sistemas de información.

Según S. Murugesan, Y. Deshpande, S., promotores iníciales del establecimiento de la

Ingeniería Web como nueva disciplina, dan la siguiente definición:

Es el proceso utilizado para crear, implantar y mantener aplicaciones y sistemas Web de alta
calidad. Esta breve definición nos lleva a abordar un aspecto clave de cualquier proyecto
como es determinar qué tipo de proceso es más adecuado en función de las características del
mismo. El desarrollo de aplicaciones Web posee determinadas características que lo hacen
diferente del desarrollo de aplicaciones o software tradicional y sistemas de información. La
ingeniería de la Web es multidisciplinar.

2.3.1 Proceso de Ingeniería Web

Según Pressman, las actividades que formarían parte del marco de trabajo incluirían las tareas
abajo mencionadas. Dichas tareas serían aplicables a cualquier aplicación Web,
independientemente del tamaño y complejidad de la misma.

Comunicación con el cliente

La comunicación con el cliente se caracteriza por medio de dos grandes tareas: el análisis del
negocio y la formulación. El análisis del negocio define el contexto empresarial organizativo
para las WebApps y otras aplicaciones de negocio. La formulación es una actividad de
recopilación de requisitos que involucran a todos los participantes.

Planeación: Se crea el plan del proyecto para el incremento de la WebApp. El plan consiste de
una definición de tareas y un calendario de plazos respecto al período establecido para el
desarrollo del proyecto.

Modelado: Las labores convencionales de análisis diseño de la ingeniería del software se

adaptan al desarrollo de las WebApp, se mezclan y luego se funden en una actividad de

36
modelado de la IWeb. El intento es desarrollar análisis rápido y modelos de diseño que
definan requisitos y al mismo tiempo representen una WebApp que los satisfará.

Construcción: Las herramientas y la tecnología IWeb se aplican para construir la WebApp

que se ha modelado. Una vez que se construye el incremento de WebApp se dirige a una serie
de pruebas rápidas para asegurar que se descubran los errores en el diseño.

2.3.2 Herramientas Tecnológicas

Las tecnologías abarcan un amplio conjunto de descripción de contenido y lenguaje de

modelación por ejemplo: HTML, VRML, XML, etc. lenguajes de programación por ejemplo
java, php, jsp, etc. recursos de desarrollo basados en componentes por ejemplo corba, com,
activeX, .net, etc. navegadores, herramientas multimedia, herramientas de auditoría de sitio,
herramientas de conectividad de base de datos, herramientas de seguridad, servidores y
utilidades de servidor, y herramientas de administración y análisis de sitio

2.3.3. Seguridad Informática en la Página Web

El aumento de los servicios de correo electrónico externos, la pérdida de barreras

organizacionales a través del uso de facilidades de acceso remoto; exposiciones de seguridad
tales como virus, negaciones de servicio, intrusiones, accesos no autorizados, nos lleva a la
necesidad de una administración efectiva de la seguridad de la información.

Además la red mundial Internet y sus elementos asociados son mecanismos ágiles que
proveen una alta gama de posibilidades de comunicación, interacción y entretenimiento, tales
como elementos de multimedia, foros, chat, correo, comunidades, bibliotecas virtuales entre
otros que pueden ser accedidos por todo tipo de público. Sin embargo estos elementos deben
contener mecanismos que protejan y reduzcan los riesgos de seguridad alojados, distribuidos
y potencializados a través del mismo servicio de Internet.

La seguridad informática se resume, por lo general, en cinco objetivos principales:

37
• Integridad: garantizar que los datos sean los que se supone que son

• Confidencialidad: asegurar que sólo los individuos autorizados tengan acceso a los
recursos que se intercambian

• Disponibilidad: garantizar el correcto funcionamiento de los sistemas de información

• Evitar el rechazo: garantizar de que no pueda negar una operación realizada.

• Autenticación: asegurar que las entidades que se comunican son los que dicen que son.

Según ROMERO, 2011 las prácticas básicas al desarrollar una aplicación web deben ser:

a) Balancear Riesgo y Usabilidad Si bien la usabilidad y la seguridad en una aplicación

web no son necesariamente mutuamente excluyentes, algunas medidas tomadas para
incrementar la seguridad con frecuencia afectan la usabilidad. Al igual que debemos pensar en
las maneras en que usuarios ilegítimos nos pueden atacar, también debemos considerar la
facilidad de uso para los usuarios legítimos. La recomendación inicial sería tratar de usar
medidas de seguridad que sean transparentes a los usuarios. Por ejemplo, la solicitud de un
nombre de usuario y una contraseña para registrarse en un sistema son procedimientos
esperados y lógicos por parte del usuario.

b) Rastrear el paso de los Datos La medida más importante como desarrollador

preocupado por la seguridad que podemos tomar es mantener conocimiento de los pasos que
ha recorrido la información en todo momento. Conocer de dónde vinieron los datos y hacia
dónde van. En muchas ocasiones lograr esto puede ser complicado, especialmente sin un
conocimiento profundo de cómo funcionan los sistemas Web. En las aplicaciones web,
existen maneras de distinguir los orígenes de los datos y poder así reconocer cuando los datos
pueden ser dignos de confianza y cuando no. Ante todo, debemos recordar que la
desesperación y la paranoia con mucha frecuencia nos dirigen a complicaciones y errores.

38
c) Filtrar Entradas El filtrado es una de las piedras angulares de la seguridad en
aplicaciones web. Es el proceso por el cual se prueba la validez de los datos. Si nos
aseguramos que los datos son filtrados apropiadamente al entrar, podemos eliminar el riesgo
de que datos contaminados y que reciben confianza indebida sean usados para provocar
funcionamientos no deseados en la aplicación.

d) Encriptación Encriptación es el proceso mediante el cual cierta información o texto sin

formato es cifrado de forma que el resultado sea ilegible a menos que se conozcan los datos
necesarios para su interpretación. Es una medida de seguridad utilizada para que al momento
de almacenar o transmitir información sensible ésta no pueda ser obtenida con facilidad por
terceros. Opcionalmente puede existir además un proceso de des encriptación a través del cual
la información puede ser interpretada de nuevo a su estado original, aunque existen métodos
de encriptación que no pueden ser revertidos, la encriptación MD5 (abreviatura de Message-
Digest Algorithm 5, Algoritmo de Resumen del Mensaje 5) es un algoritmo de reducción
criptográfico de 128 bits ampliamente usado el mismo dará lugar a que la contraseña no tenga
consecuentes al momento desde que se trasmite la información hasta que se almacena.

2.4 Metodología UWE

La propuesta de Ingeniería Web basada en UML (UWE (Koch, 2000)) es una metodología
detallada para el proceso de autoría de aplicaciones con una definición exhaustiva del proceso
de diseño que debe ser utilizado. Este proceso, iterativo e incremental, incluye flujos de
trabajo y puntos de control, y sus fases coinciden con las propuestas en el Proceso Unificado
de Modelado.

UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace

especial hincapié en características de personalización, como es la definición de un modelo de
usuario o una etapa de definición de características adaptativas de la navegación en función de
las preferencias, conocimiento o tareas de usuario. Otras características relevantes del proceso

39
y método de autoría de UWE son el uso del paradigma orientado a objetos, su orientación al
usuario, la definición de una meta-modelo (modelo de referencia) que da soporte al método y
el grado de formalismo que alcanza debido al soporte que proporciona para la definición de
restricciones sobre los modelos. Entonces vemos que UWE tiene como objetivo principal el
de detallar su proceso de desarrollo cubriendo todo el ciclo de vida.

2.4.1 Fases de la Metodología UWE

Las fases de la metodología UWE, son procesos o actividades que se utilizan y permiten
identificar las necesidades de las aplicaciones y/o sistema web a desarrollar; cubriendo todo
el ciclo de vida de la aplicación centrando además su atención en aplicaciones personalizadas
o adaptativas. Estas actividades se describen y representan en cuatro fases que son:

2.4.1.1 Análisis de Requisitos

Como en otras metodologías, la primera fase o actividad es la del análisis de requisitos

funcionales, que permite visualizar los procesos y funciones que debe cumplir el sistema web,
esta fase se ve reflejada en los casos de uso.

Trata de diferente forma las necesidades de información, las necesidades de navegación, las
necesidades de adaptación y las de interfaz de usuario, así como algunos requisitos
adicionales. Centra el trabajo en el estudio de los casos de uso, la generación de los glosarios
y el prototipado del interfaz de usuario.

En UWE el modelado requisitos consta de dos partes:

• Los casos de uso de la aplicación y sus relaciones

• Actividades que describen casos de uso en detalle

40
En la siguiente figura 2.3. Se puede observar un ejemplo de diagrama de casos de uso y su
relación.

Figura 2.3: Análisis de caso de uso y su relación

Fuente: M. Gonzales, 2013

En el presente proyecto solo se harán los casos de uso de la aplicación y sus relaciones, ya que
son suficientes para el entendimiento del cliente.

En la siguiente figura 2.4. Se puede observar un ejemplo de diagrama de casos de uso en

detalle.

41
 Figura 2.4. Diagrama de casos de uso de alto nivel del Negocio
Fuente: INCADEX S.R.L. ,2016

Esta fase de análisis de requisitos me ayuda a describir los elementos involucrados que están
descritos en los casos de uso, permitiéndonos aclarar él porque de su existencia, a través de
actores participes y comprendidos con su respectivo rol dentro del negocio.

2.4.1.2 Diseño Conceptual

El diseño conceptual se basa en el análisis de requisitos del paso anterior de análisis de

requisitos el cual nos ayudaba a describir los elementos a través de actores con su respectivo
rol es así que esto incluye los objetos involucrados entre los usuarios y la aplicación. Este
modelo propone construir un modelo de clases con estos objetos, ignorándoos los aspectos de
navegación: Presentación e Interacción, que serán tratados posteriormente. Los principales
elementos de modelado son; las clases, asociaciones y paquetes.

42
En la figura 2.5 se puede observar un ejemplo de diagrama de contenido.

Figura 2.5: Ejemplo de diagrama de contenido

Fuente: [LMU, 2000]

2.4.1.3 Diseño Navegacional

El diseño navegacional no es solo útil para la generación de la documentación de la estructura

de la aplicación sino que también permite mejorar la estructura de navegabilidad. El modelo
de la navegación comprende de:

• El modelo de espacio de navegación que especifica qué objetos pueden ser visitados a
través El modelo de estructura de navegación que define como se alcanzan estos objetos a
través de la Web.

43
• En el proceso de construir el modelo espacial de navegación las decisiones del diseñador
están basadas en el modelo conceptual y los requisitos de la aplicación definidos en el modo
de caso de uso.

• El modelo de estructura de navegación que define como se alcanzan estos objetos a través
de la Web.

• En el proceso de construir el modelo espacial de navegación las decisiones del diseñador

están basadas en el modelo conceptual y los requisitos de la aplicación definidos en el modo
de caso de uso.

Cuando hablamos de un sistema web, es necesario conocer la relación y los enlaces entre las
páginas web, es por eso que en la fase de diseño describen a través de diagramas la
navegación del sistema como muestra la tabla 2.1:

Tabla 2.1: Elementos de diseño navegacional

Fuente: Ingeniería web basada en UML, Instituto de Informática

44
En la figura a continuación se muestra un ejemplo del diseño de navegación:

Figura 2.6: Ejemplo de diagrama de navegación

Fuente: LMU, 2000

2.4.1.4 Diseño de Presentación

Este modelo permite una visión amplia de los procesos de la página web que se representan
en los diagramas de navegación; pueden interpretarse también con las interfaces del sistema
web, para el caso se tiene estereotipos o iconos que ayudan al diseño de los diagramas de
presentación.

45
El diagrama de presentación de la metodología UWE, permite al usuario comprender y
analizar, sobre el área de trabajo al que se someterá con la implantación del sistema. En la
siguiente tabla veremos el uso de cada estereotipo.

Uso de cada estereotipo:

Tabla 2.2: Estereotipos para el diagrama de presentación

Fuente: LMU, 2000

46
En la siguiente figura, se muestra la aplicación de los iconos que pertenecen a los diagramas
de presentación.

Figura 2.7: Diagrama de presentación

Fuente: Ingeniería web basada en UML, Instituto de Informática

2.5 Base de Datos

Según [CAMPS, 2005] una base de datos de un sistema de información es la representación

integrada de los conjuntos de entidades instancia correspondientes a las diferentes entidades
tipo del sistema de información y de sus interrelaciones. Esta representación informática (o
conjunto estructurado de datos) debe poder ser utilizada de forma compartida por muchos
usuarios de distintos tipos.

47
Por lo tanto en otras palabras podemos decir que una base de datos es un conjunto
estructurado de datos que representa entidades y sus interrelaciones.

2.5.1 Base de Datos Relacionales

Una base de datos relacional es un conjunto de tablas que contienen datos provistos en
categorías predefinidas. Cada tabla (que a veces se llaman 'relación') contiene una o más
categorías de datos en columnas. Cada fila contiene una instancia única de datos para las
categorías definidas por las columnas.

2.5.1.1. Gestores de Base de Datos Relacionales

Existe un tipo de software exclusivamente dedicado a tratar con bases de datos relacionales,
conocido como Sistema de Gestión de Bases de Datos Relacionales (SGBDR, o RDBMS del
inglés Relational Database Management System), también llamados manejadores o gestores
de las BDR.

Entre los gestores actuales más populares existen:

• MySQL.

• PostgreSQL.

• Oracle.

• DB2.

• Microsoft SQL Server.

2.5.1.2. PostgreSQL

PostgreSQL sistema de bases de datos relacionales basado en Open Source. Esto quiere decir
que el código fuente del programa está disponible a cualquier persona libre de cargos directos,
permitiendo a cualquiera colaborar con el desarrollo del proyecto o modificar el sistema para

48
ajustarlo a sus necesidades. PostgreSQL está bajo licencia BSD. Un sistema de base de datos
relacionales es un sistema que permite la manipulación de acuerdo con las reglas del ´algebra
relacional. Los datos se almacenan en tablas de columnas y renglones. Con el uso de llaves,
esas tablas se pueden relacionar unas con otras.

PostgreSQL se caracteriza por ser un sistema estable, de alto rendimiento, gran flexibilidad ya
que funcionar la mayoría de los sistemas Unix, además tiene características que permiten
extender fácilmente el sistema. PostgreSQL puede ser integrada al ambiente Windows
permitiendo de esta manera a los desarrolladores, generar nuevas aplicaciones o mantener las
ya existentes. Permite desarrollar o migrar aplicaciones desde Access, Visual Basic, Foxpro,
Visual Foxpro, C/C++ Visual C/C++, Delphi, etc., para que utilicen a PostgreSQL como
servidor de BD; Por lo expuesto PostgreSQL se convierte en una gran alternativa al momento
de decidirse por un sistema de bases de datos.

2.5.2. ORM

Object-Relational mapping, o lo que es lo mismo, mapeo de objeto-relacional, es un modelo

de programación que consiste en la transformación de las tablas de una base de datos, en una
serie de entidades que simplifiquen las tareas básicas de acceso a los datos para el
programador. Los modelos ORM proporcionan grandes ventajas a proyectos que empiezan,
ya que permiten tener acceso a los datos de una manera sencilla y rápida, además de
proporcionar cierta abstracción sobre la base de datos que se encuentra por debajo. Es cierto
que no es la única manera de acceder a los datos, ya que soluciones específicas habitualmente
tendrán mejor rendimiento, ya que no se hace una transformación de las órdenes y de los
datos., finalmente creo que se deben conocer, y tenerlos como alternativa o como sistema
principal. Como siempre, todo depende del uso.

2.6 Tecnologías WEB

Una tecnología web es una tecnología que utiliza todas las tecnologías de inter conectividad
de ordenadores que permite a los usuarios el intercambio, en formato de hipertexto, de todo

49
tipo de datos e información (Texto, imágenes, sonido) y de aplicaciones de software. Soncco,
2008.

2.6.1 Python

Es un lenguaje de programación interpretado cuya filosofía hace hincapié en una sintaxis que
favorezca un código legible. Se trata de un lenguaje de programación multiparadigma, ya que
soporta orientación a objetos, programación imperativa y, en menor medida, programación
funcional. En Python, la definición de funciones se realiza mediante la instrucción.

2.6.3. Bootstrap

Bootstrap fue desarrollado por Mark Otto y Jacob Thornton en Twitter, y lanzado como un
producto de código abierto en agosto de 2011 en GitHub. Bootstrap es un framework para
desarrollar código HTML y CSS más rápido y fácil en el front-end (lado del cliente) de las
páginas web. Bootstrap incluye plantillas HTML y CSS para el diseño, las plantillas tienen
código reutilizable para las caracterizas más importantes de un sitio web como ser la
tipografía, los formularios, los botones, las tablas, los enlaces, los modales, carruseles de
imágenes y muchas otras, así como plugins de JavaScript opcionales. W3schools, 2015.

Con Bootstrap el diseño web es Responsive, es decir se puede diseñar sitios web que se
ajusten automáticamente a sí mismos para que se visualicen bien en todos los dispositivos,
como Smart phones (celulares), tablets, laptops y ordenadores de escritorio. Además bootstrap
es compatible con todos los navegadores modernos (Chrome, Firefox, Internet Explorer,
Safari y Opera). Y se puede descargar libremente desde su pagina oficial.

2.7. Inventarios

El inventario tiene como propósito fundamental proveer a la empresa

de materiales necesarios, para su continuo y regular desenvolvimiento, es decir, el inventario

50
tiene un papel vital para funcionamiento acorde y coherente dentro
del proceso de producción y de esta forma afrontar la demanda.Luna,2001

Los inventarios de una compañía están constituidos por sus materias primas, sus productos en
proceso, los suministros que utiliza en sus operaciones y los productos terminados. Un
inventario puede ser algo tan elemental, complejo, como una combinación de materias primas
que forman parte de un proceso de manufactura. Müller, 2000.

2.7.1 Clasificación de inventarios

2.7.1.1. Inventario de Materias Primas

Lo conforman todos los materiales con los que se elaboran los productos, pero que todavía no
han recibido procesamiento.

2.7.1.2. Inventario de Productos en Proceso de Fabricación

Lo integran todos aquellos bienes adquiridos por las empresas manufactureras o industriales,
los cuales se encuentran en proceso de manufactura. Su cuantificación se hace por la cantidad
de materiales, mano de obra y gastos de fabricación, aplicables a la fecha de cierre.

2.7.1.3. Inventario de Productos Terminados

Son todos aquellos bienes adquiridos por las empresas manufactureras o industriales, los
cuales son transformados para ser vendidos como productos elaborados.

2.7.2. Control inventarios

El control del inventario es uno de los aspectos de la administración bienes tangibles que se
tienen para la venta en el curso ordinario del negocio o para ser consumidos en la producción
de bienes o servicios para su posterior comercialización. Los inventarios comprenden, además
de las materias primas, productos en proceso y productos terminados o mercancías para la
venta, los materiales, repuestos y accesorios para ser consumidos en la producción de bienes

51
fabricados para la venta o en la prestación de servicios; empaques y envases, y los inventarios
en tránsito. La base de toda empresa comercial es la compra y venta de bienes o servicios; de
aquí la importancia del manejo del inventario por parte de la misma. Este manejo contable
permitirá a la empresa mantener el control oportunamente, así como también conocer al final
del período contable un estado confiable de la situación económica de la empresa. Ahora bien,
el inventario constituye las partidas del activo corriente que están listas para la venta, es decir,
toda aquella mercancía que posee una empresa en el almacén valorada al costo de adquisición,
para la venta o actividades productivas. Los diversos aspectos de la responsabilidad sobre los
inventarios afectan a muchos departamentos y cada uno de éstos ejerce cierto grado de control
sobre los productos, a medida que los mismos se mueven a través de los distintos procesos de
inventarios. Todos estos controles que abarcan, desde el procedimiento para desarrollar
presupuestos y pronósticos de ventas y producción hasta la operación de un sistema de costo
Pro el departamento de contabilidad para la determinación de costos de los inventarios,
constituye el sistema del control interno de los inventarios, las funciones generales son:
Planeamiento, compra u obtención, recepción, almacenaje, producción, embarques y
contabilidad . Chauvel, 1995.

2.7.3. Manufacturación

La base para planear la producción y estimar las necesidades en cuanto a inventarios, la

constituye el presupuesto o pronóstico de ventas. Este debe ser desarrollado por el
departamento de ventas. Los programas de producción, presupuestos de inventarios y los
detalles de la materia prima y mano de obra necesaria, se preparan o se desarrollan con vista
al presupuesto de ventas. Aunque dichos planes se basan en estimados, los mismos tendrán
alguna variación con los resultados reales, sin embargo ellos facilitan un control global de las
actividades de producción, niveles de inventarios y ofrecen una base para medir la efectividad
de las operaciones actuales.

52
2.7.3.1. Compra u Obtención

En la función de compra u obtención se distinguen normalmente dos responsabilidades

separadas: Control de producción, que consiste en determinar los tipos y cantidades de
materiales que se quieren. Compras, que consiste en colocar la orden de compra y mantener la
vigilancia necesaria sobre la entrega oportuna del material, un inventario tiene la existencia de
bienes mantenidos para su uso o venta y compra del mismo, satisfaciendo los costos altos y
bajos en cuanto a la obtención del producto. La compra de los productos darán lugar a la
demanda y a una nueva inversión económica en la que beneficiara a la empresa de esta
manera se podrá generar más ingresos.

2.7.3.2. Recepción

Debe ser responsable de lo siguiente:

a) La aceptación de los materiales recibidos, después que estos hayan sido debidamente
contados, inspeccionados en cuanto a su calidad y comparados con una copia aprobada de la
orden de compra.

b) La prelación de informes de recepción para registrar y notificar la recepción y

aceptación.

c) La entrega o envío de las partidas recibidas, a los almacenes (depósitos) u otros lugares
determinados. Como precaución contra la apropiación indebida de activos.

2.7.4. Almacenaje

Las materias primas disponibles para ser procesadas o armadas (ensambladas), así como los
productos terminados, etc., pueden encontrarse bajo la custodia de un departamento de
almacenes. La responsabilidad sobre los inventarios en los almacenes incluye lo siguiente:

a) Comprobación de las cantidades que se reciben para determinar que son correcta.

53
b) Facilitar almacenaje adecuado, como medida de protección contra los elementos y las
extracciones no autorizadas.

c) Extracción de materiales contra la presentación de autorizaciones de salida para

producción o embarque.

2.7.5. Producción

Los materiales en proceso se encuentran, generalmente bajo control físico, control interno de
los inventarios, incluye lo siguiente:

a) La información adecuada sobre el movimiento de la producción y los inventarios.

b) Notificación rápida sobre desperdicios producidos, materiales dañados, etc., de modo

que las cantidades y costos correspondientes de los inventarios. Puedan ser debidamente
ajustados en los registros.

La información rápida y precisa de parte de la fábrica, constituye una necesidad para el

debido funcionamiento del sistema de costo y los procedimientos de control de producción.

2.7.6. Producto terminado

Todos los embarques, incluyéndose aquellas partidas que no forman parte de los inventarios,
deben efectuarse, preferiblemente, a base de órdenes de embarque, debidamente aprobadas y
preparadas independientemente.

Producto terminado realizado por la misma empresa y todas las demás productoras de
alimentos en el caso actual realizan un proceso largo para la conclusión de estos determinando
el envió previo.

54
 Capítulo 3

Marco aplicativo

3.1. Introducción

El presente capítulo, tiene como finalidad describir el desarrollo del Sistema Web de control
de inventarios, manufacturación y producto final para la empresa industrial comercial de
alimentos INCADEX S.R.L. Haciendo uso de la metodología Scrum como se describió en el
anterior capitulo tiene como función la realización del proyecto partiendo de una lista de
tareas a realizar, para la gestión de desarrollo del sistema y la metodología UWE para el
modelado.

Por esta razón el trabajo se ha dividido en una serie de Sprints teniendo como las siguientes
fases: Pre-Game, Game, Post-Game. Gráficamente el modelo a desarrollar en este largo
proceso que se realizara con la ayuda de Scrum ya mencionado en el anterior capitulo, esté
proceso me ayudara a mantener los roles y sprint en orden que daré a conocer a continuación
en la figura 3.1 se puede observar.

Pre – Game Game Post-Game

Planeamiento Pruebas de

Integración
Sprint
Produc Backlog
Backlog

Pruebas de
Diseño de la

55
Arquitectura Sistema
Sprint

Planificación Desarrollo Pruebas

UWE

Figura 3.1: Modelo de procesos del proyecto

Fuente: Elaboración Propia

3.2 Pre-Game

3.2.1 Descripción de Usuario

A continuación se detallas a los usuarios involucrados en este sistema:

ROL NOMBRE

PRODUCT OWNER Lic. Marcos Vera

SCRUM MASTER M. Sc. Aldo Ramiro Valdez Alvarado

Analista

56
 SCRUM Diseñador Mónica Carmen Mendoza Roque

TEAM
Desarrollador

Testeador

STAKEHOLDERS INCADEX S.R.L.

Tabla 3.1: Identificación de Roles de Scrum

Fuente: Elaboración propia

3.2.2 Product Backlog

Para poder empezar a realizar las iteraciones primero necesitamos definir nuestra Lista de
requisitos priorizada (Product Backlog), para esto fue necesario realizar reuniones entre el
cliente (Product Owner), el líder de equipo (Scrum master) y el equipo de desarrollo (Team).
En este caso la función de cliente lo cumplió el Lic. Marcos Vera al asumir las reuniones que
se tuvo brindando asi la información necesaria. Para poder obtener el Product Backlog se
entrevistó al cliente, preguntándole el proceso actual que se tiene para obtener los registros de
todos los inventarios y proceso de elaboración, este de manera verbal ,dijo que el control de
los inventarios eran siempre a base de cada pedido que llegaban y salía del mismo lugar
almacenado a través de reportes que eran notificados por el almacenero u/o proveedor ,el
ingreso de cada materia prima y la salida decía era siempre a base de cantidades que
ordenaban las diversas recetas de proceso actual que se pedían para así obtener un producto
terminado . Se le pregunto también el proceso de elaboración de los productos .Una vez que
los materiales son registrados ya sea de manera verbal o escrita, los pedidos al inicio de
preparado de chocolate son pedidos acorde a las recetas de preparación, los encargados y
responsables de cada sección de trabajo tienen como fin supervisar y enviar datos a la hora de
ya ser procesados. Muchas veces no siempre se llega a lo estimado de lo pedido producto

57
terminado ya sea por el tiempo, espacio y/o personal. Viendo los detalles que el cliente
proporciono se hizo un análisis de como recolectar la información de los beneficiarios, y en
otra reunión se construyó junto al cliente la siguiente lista de requisitos:

Nombre Modulo Importancia Estimación Como Probarlo Notas

Diseño de Base alta 20 horas Ver el servidor la

de dados y Implementación de
arquitectura la base de datos y
la lógica
del sistema

Alta 20 horas Entrar como

administrador,
Autentificación
abrir página de
de Usuarios/
Personal ingresar
Personal
un nuevo
almacenero u/o
personal,
modificar al
personal, eliminar
al personal, y
M1
mostrar el
almacenero u/o

58
 personal por su id
correspondiente

Mostrar Alta 5 días Ver la lista de

Acciones de acciones que nos
Usuarios muestra la misma.

Crear/Actualiza Alta 8dias Usar el registro de

r empleador nuevo empleador y
actualización de
datos de un
empleador, se tiene
éxito cuando hacer
cambios en la base
de datos.

Materia Prima Alta - 20 horas Entrar como

administrador o
Almacenero, abrir
página de Materia
Prima ingresar un
nuevo material,
modificar al
material, eliminar
al material, y
mostrar material

59
 por su id
correspondiente.
Observar todos los
materiales por
defecto en la
página inicial.

Productos. 8 20 horas Entrar como

administrador
o Almacenero,
abrir página de

M2 Productos
ingresar un
nuevo
producto,
modificar al
producto,
eliminar al
producto, y
mostrar
producto por
su id
correspondient
e. Observar
todos los
productos por
defecto en la

60
 página inicial.

Herramientas 8 20 horas Entrar como

administrador o
Almacenero,
abrir página de
Herramientas
ingresar una
nueva
herramienta o
máquina,
modificar la
herramienta o
máquina,
eliminar la
herramienta o
máquina, y
mostrar la
herramienta o
máquina con su
id
correspondiente.
Observar todas
las herramientas
o máquinas por

61
 defecto en la
página inicial.

Manufacturació M3 7 20 horas Entrar, dentro la Necesita

n página se tiene un
el listado de los diagrama
materiales, como UML
ingredientes, los (diagram
productos al que a de
se quiere llegar secuenci
y su respectiva a u otros
receta, para más),
posteriormente para
calcular la establece
cantidad de r el
material se proceso
necesita para de
preparar manufact
determinada uración.
cantidad de
Además
producto.
que
necesita
la
existenci
a de la
base de
datos

62
 materiale
s,
producto
s,
recetas.

Log In 4 10 horas Entrar a la Necesita

página que los
principal por la usuarios
URL el sistema del
solicita que sistema
ingrese ya
username y existan
password, una en la
vez ingresado base de
los datos datos.
validar con la
base de datos
que sea
correcto

Reportes M4 3 10 horas De la página

correspondiente
Producto
hacer onClick

terminado en el botón
reporte, una
cliqueada se
generará un

63
 documento
resultante en
PDF, de la
consulta
observada.

Tabla 3.2. Product Backlog

Fuente elaboración propia

3.2.3 Requerimientos De Hardware Y Software

Para poder desarrollar el proyecto e implementarlo también necesitamos hardware y software,

en la siguiente tabla se mencionan los requerimientos mínimos para el buen desarrollo e
implementación del sistema web.

Requerimiento de hardware PC de escritorio o Laptop, con las

siguientes características:

 Memoria RAM 1gb o Superior

 Espacio disponible en disco

duro 10gb o superior

 Procesador

 Pantalla, teclado, mouse,

impresora

Microsoft Word para la documentación

64
 Navegador en Html5

Requerimiento de software Lector de Pdf

Editor de Planillas de Exel

Que tenga Servidor

Tabla 3.3: Requerimientos de Hardware y Software el desarrollo del proyecto

Fuente: [Elaboración Propia]

3.3 Game

De acuerdo el modelo que se propuso con la metodología SCRUM y UWE en la introducción

de este capítulo, en esta fase se desarrollaran los sprints seleccionando requisitos del product
backlog según su prioridad, posteriormente hacer la planificación, el desarrollo y las pruebas
de cada sprint , las pruebas de desarrollo serán realizadas por el entrevistado el mismo jefe de
planta y responsable de todas las áreas en una buena elaboración de chocolates su proceso
dará a realizar las pruebas que objetivamente se supo desarrollar en los módulos de personal,
inventarios,manufacturacion,producto final ..

Para la planificación solo se usara el sprint backlog el cual es una herramienta de SCRUM,
luego para la parte de desarrollo se hará uso de los diagramas que proporciona la metodología
UWE y codificar si es necesario para obtener incrementos, y al finalizar el sprint se harán las
pruebas unitarias del mismo, todo el proceso de los 4 módulos serán evaluados acorde a lo
que se dijo y se mencionó detallando en cada reunión los diversos requerimiento y procesos
que la misma empresa lleva consigo.

65
3.3.1 Desarrollo del Sprint 1: Módulo de Personal

Según la metodología del Scrum, el inicio del proyecto se realizó con la reunión de
planificación del primer sprint, el sprint número 1. Un factor importante a considerar es que
en esta reunión, al igual que en la mayor parte del proyecto, la comunicación con los usuarios
se realizó de forma irregular debido a la imposibilidad que tienen los doctores para
encontrarse físicamente en el lugar del desarrollo. No obstante, el autor de este proyecto actuó
presente durante todo el desarrollo, el Product Owner, tenía todo el conocimiento necesario
para tomar las decisiones de los usuarios.

3.3.1.1 Planificación del Sprint 1: Módulo Personal

Durante el primer sprint se llevara a cabo los iniciales requerimientos que pertenecen al
módulo de inicio de sesión. En la siguiente tabla se muestran las tareas planificadas para este
Sprint y que fueron concluidas como se muestra a continuación.

Sprint 1: Modulo De Registro de personal

Sprint Duración horas Días de trabajo

1 99 20 días hábiles

SPRINT BACKLOG

Tareas Tipo Hrs/pr Estado

66
Planificación y Desarrollo 30 Hecho
análisis de los hr/pr
requerimientos og
del sprint

Diseño de la Desarrollo 30 Hecho

base de datos hr/pr
para el Sistema og
Web

Diseño Desarrollo 20 hecho

Conceptual hr/pr
og

Diseño Desarrollo 20 Hecho

Navegacional hr/pr
og

Diseño de Desarrollo 7 Hecho

Presentación hr/pr
og

Diseño de la Desarrollo 9 Hecho

interfaz gráfica hr/pr
para la interfaz og

67
 de inicio de
sesión

Seguridad y Desarrollo 10 Hecho

control de hr/pr
acceso al og
sistema

Tabla 3.4: Primer Sprint Backlog

Fuente: Elaboración propia

3.3.1.2 Especificación de Caso de Uso del Sprint 1

A continuación se tiene el caso de uso del primer sprint.

Figura 3.2 Diagrama de Casos de Uso de Usuario

Fuente Elaboración Propia

68
En este sprint se observa el inicio de sesión del usuario en este caso el registro del almacenero
en el momento de ingresar al sistema

NOMBRE 1. MÓDULO DE USUARIO DE PERSONAL

ACTORES Administrador

PROPÓSITO Administrar los almaceneros involucrados en el inventariado

la manufacturación y registro de productos

RESUMEN La creación y administración de responsables de almacén y

plantel responsable del inventario, y la manufacturación con
sus determinadas características

REFERENCIAS NINGUNA
CRUZADAS

FLUJO PRINCIPAL EVENTO ACTOR EVENTO SISTEMA

El administrador ingresa al
sistema a través de la
URL, e ingresando al
sistema mediante el log in
del sistema como
administrador.

69
 El sistema valida los datos una
vez llenado el formulario de Log
In, una vez ingresado los datos
correctos, te envía a la página de
inicio

En la página de inicio
ingresar dentro del menú al
enlace de página de registro
de almacenero.

Direcciona a la página que

contiene un formulario de registro
con un botón de adicionar, para la
creación de un nuevo Almacenero.

Una vez llenado los campos

del formulario, hace click en
el botón adicionar.

Almacena la información enviada

y reenvía al usuario a la página de
listado de administrador.

70
 PRECONDICIÓN Debe de existir la base de datos con la tabla correspondiente a
almacenero

POS CONDICIÓN Creación de personal

PRESUNCIÓN Almacenamiento de datos de forma segura

Tabla 3.5. Registro de Usuario

Fuente: Elaboración Propia

3.3.1.3 Diseño Navegacional

El diseño navegacional muestra las opciones de navegación y procesos que el sistema tendrá
en su desarrollo. Ver figura:

Figura 3.3.Diseño Navegacional

Fuente Elaboración Propia

71
3.3.1.4 Diseño de Presentación

En el diagrama de presentación para el módulo de inicio de sesión se muestra la interfaz

donde el administrador introduce los datos respectivos para ingresar al sistema. Proceso a
realizando.

Figura 3.4: Diagrama de registro de personal

Fuente: Elaboración propia

3.3.1.5 Pantallas Del Sprint 1

A continuación se puede observar la página de inicio a la cual tendrá acceso el administrador

para ver los servicios que ofrece el sistema.

72
 Figura 3.5 Página de Inicio
Fuente Elaboración Propia

Ahora observar la página de inicio a la cual tendrá acceso el administrador para ver los
servicios que ofrece el sistema caso registro de personal.

Registro de personal
d
s
f

Figura 3.6 Registro de Personal

Fuente Elaboración Propia

73
A continuación se muestra el registro de personal y/o listado de empleado.

Figura 3.7. Listado de personal

Fuente Elaboración Propia

Registro de personal Almacenero u otro personal de secciones.

Figura 3.8. Registro de Personal

Fuente Elaboración Propia

3.3.1.6 Prueba Unitaria del Sprint 1

La prueba unitaria a continuación sirve para comprobar que el modulo funcione

correctamente. Ver Tabla 3.6

74
Prueba #1 Modulo de Personal

Descripción El administrador presionara ingresar personal, el almacenero u/o

empleado ingresa al sistema una vez recepcionado con sus datos.

Objetivos 1. Que ingrese al sistema al presionar ingresar

2. Abrir el sistema

Condiciones Conexión a internet desde cualquier medio (Pc, Celular, iPhone,

Tablet).

Resultado esperado Que se habrá satisfactoriamente el sistema

Resultados obtenido El sistema inicia correctamente

Tabla 3.6: Prueba unitaria - Sprint 1

Fuente: Elaboración propia

3.3.2 Desarrollo Del Sprint 2: Módulo De Inventario

El trabajo del sprint 2 avanzo a buen ritmo ajustándose de un modo más aproximado a la
planificación planteada, hecho que acrecentó la motivación. Las reuniones realizadas por el
administrador y almacenero dieron como resultado una organización de ideas de trabajo de
este sprint avanzo a buen ritmo ajustándose de un modo más aproximado.

75
3.3.2.1 Planificación del Sprint 2 Inventario

El proceso de registro de datos en el inventario de la materia prima, herramienta y/o

maquinaria, con sus datos generales darán lugar a un registro de datos.

En esta tabla especificamos el tiempo y registro de las materias primas y registro de

herramientas Ver tabla 3.7

Sprint 2: Registro de Inventario

Sprint Duración Días de trabajo

horas

2 52 10 días hábiles

SPRINT BACKLOG

Tareas Tipo Est. Estado

Listado de materia Desarrollo 4 h/prog. Mostrar la vista de los

prima
materiales

Registro de Materia Desarrollo 7h/prog Mostar formulario y

botón de creación de
Prima
materiales

76
 Modificación de Materia Desarrollo 7 h/prog Mostar formulario para
Prima posterior modificación
del material

Eliminación de Desarrollo 3 h/prog Eliminar su

correspondiente registro de
Materia Prima
BD.

Búsqueda de Materia Desarrollo 5 h/prog Mostrará los campos de

BD. En un formato
Prima
estético.

Listado de herramientas Desarrollo 4 h/prog Mostrar la vista de las

Herramientas existentes

Registro de herramientas Desarrollo 7 h/prog Mostar formulario y botón

de creación de
herramientas

Modificación de Desarrollo 7 h/prog Mostar formulario para

posterior modificación.
herramientas

Eliminación de Desarrollo 3 h/prog Eliminar su

correspondiente registro de
herramientas
BD.

77
 Búsqueda de herramientas Desarrollo 5 h/prog Mostrará los campos de
BD. En un formato
estético.

Tabla 3.7: Segundo Sprint Backlog

Fuente: Elaboración propia

3.3.2.2 Especificación de Casos de Uso de Sprint 2

Visualizamos en los casos de uso el inventario el cual será el que registre los productos
entrantes y salientes del almacén es decir la materia prima y herramientas que procesen el
preparado de chocolate.

Figura 3.9.Diagrama de Casos de Uso de Registrar Materia Prima

Fuente: Elaboración Propia

78
Casos de uso registro de herramientas.

Figura 3.10. Diagrama de Casos de Uso de Registrar Herramienta

Fuente: Elaboración Propia

Así como la materia prima es lo más fundamental para la elaboración de productos, el manejo
proceso de los mismos será mediante las herramientas, registros de la misma explicara en la
siguiente tabla se muestra el Sprint Backlog para este módulo.

NOMBRE 2.1.REGISTRAR MATERIA PRIMA

ACTORES ADMINISTRADOR – ALMACENERO

79
PROPÓSITO Realizar la creación correspondiente de los datos de
materia prima, además de la modificación, eliminación
de materia prima.

RESUMEN Permite adicionar, modificar, eliminar y la búsqueda de

información del almacén.

REFERENCIAS
CRUZADAS

FLUJO PRINCIPAL EVENTO ACTOR EVENTO SISTEMA

Ingresa el usuario a la
pestaña de materia prima

El sistema muestra el
listado de almacenes, con
un botón de crear uno
nuevo, los registros de
almacenes con su
respectivo botón de
eliminar, modificar y vista

Si el usuario presiona en
crear uno nuevo

80
 El sistema muestra la
página correspondiente a
la adición de materia
prima, con un formulario
para llenar seguido de un
botón de guardar

Una vez llenado el

formulario el usuario hace
click en guardar

El sistema responde
enviándole a la página de
listado de almacenes,
donde además contiene un
botón de modificar, un
botón eliminar y un botón
de vista detallada de la
materia prima.

Si el usuario presionar
modificar

El sistema le envía a la
página de creación de
materia prima con los
campos correspondientes

81
 llenados con la
información vigente, y con
el botón guardar.

Una vez que el usuario a

modificado los datos
presiona el botón guardar

Posteriormente le envía a
la página de listado de
materia prima

Si el usuario presiona
eliminar

El sistema envía un
mensaje de que si está
seguro de eliminar el
registro.

En caso de presionar si

El sistema elimina el
registro de la base de
datos.

82
 Si el usuario presiona el
botón de vista

El sistema muestra el
registro la información de
la materia prima según lo
que es esta registrado en la
base de datos.

PRECONDICIÓN Tener creada la base de datos con la tabla

correspondiente a materia prima

POS CONDICIÓN Permitir que los datos estén organizados de manera

eficiente en la base de datos

PRESUNCIÓN Seguridad en los datos.

Tabla 3.8. Registrar materia prima

Fuente: Elaboración Propia

NOMBRE 2.2 REGISTRAR HERRAMIENTA

ACTORES ADMINISTRADOR – ALMACENERO

83
PROPÓSITO Realizar la creación correspondiente de los datos de
herramienta, además de la modificación, eliminación de
herramienta.

RESUMEN Permite adicionar, modificar, eliminar y la búsqueda de

información de la herramienta.

REFERENCIAS
CRUZADAS

FLUJO PRINCIPAL EVENTO ACTOR EVENTO SISTEMA

Ingresa el usuario a la
pestaña de herramienta

El sistema muestra el
listado de almacenes, con
un botón de crear uno
nuevo, los registros de
almacenes con su
respectivo botón de
eliminar, modificar y vista

Si el usuario presiona en
crear uno nuevo

84
 El sistema muestra la
página correspondiente a
la adición de herramienta,
con un formulario para
llenar seguido de un botón
de guardar

Una vez llenado el

formulario el usuario hace
click en guardar

El sistema responde
enviándole a la página de
listado de almacenes,
donde además contiene un
botón de modificar, un
botón eliminar y un botón
de vista detallada de la
herramienta.

Si el usuario presionar
modificar

El sistema le envía a la
página de creación de
herramienta con los
campos correspondientes

85
 llenados con la
información vigente, y con
el botón guardar.

Una vez que el usuario a

modificado los datos
presiona el botón guardar

Posteriormente le envía a
la página de listado de
herramientas

Si el usuario presiona
eliminar

El sistema envía un
mensaje de que si está
seguro de eliminar el
registro.

En caso de presionar si

El sistema elimina el
registro de la base de
datos.

86
 Si el usuario presiona el
botón de vista

El sistema muestra el
registro la información de
la herramienta según lo
que es esta registrado en la
base de datos.

PRECONDICIÓN Tener creada la base de datos con la tabla correspondiente

a herramienta

POS CONDICIÓN Permitir que los datos estén organizados de manera

eficiente en la base de datos

PRESUNCIÓN Seguridad en los datos.

Tabla 3.9. Registrar Herramienta

Fuente: elaboración Propia

3.3.2.3 Diseño Navegacional

El diseño navegacional muestra las opciones de navegación y procesos que el sistema tendrá
en su desarrollo. Ver figura:

87
 Figura 3.11 Modelo de navegación materia prima, herramienta
Fuente Elaboración Propia

3.3.2.4 Diseño de Presentación

En el diagrama de presentación para el módulo de inicio de sesión se muestra la interfaz

donde el administrador introduce los datos respectivos para ingresar al sistema. Proceso a
realizando.

88
 Figura 3.12 Modelo de presentación de Inventarios
Fuente Elaboración Propia

3.3.2.5 Pantallas Del Sprint 2

A continuación se puede observar la página de inicio a la cual tendrá acceso el administrador

para ver los servicios que ofrece el sistema, como también el almacenero podrá acceder al
sistema a través del mismo.

89
 Figura 3.13 Registro de Materia Prima y Herramientas
Fuente Elaboración propia

3.3.2.6 Prueba Unitaria del Sprint 2

La prueba unitaria a continuación sirve para comprobar que el modulo funcione

correctamente. Ver Tabla 3.6

Prueba #2 Modulo de Inventario

Descripción Al presionar ingresar, el administrador ingresa al sistema

Objetivos 1. Que ingrese al sistema al presionar ingresar

2. Abrir el sistema

3. Ingresar a Inventario

90
 Conexión a internet desde cualquier medio (Pc, Celular,
Condiciones
iPhone, Tablet).

Resultado esperado Que se habrá satisfactoriamente el sistema y registre los datos

Resultados obtenido El sistema inicia registra correctamente

Tabla 3.10: Prueba unitaria - Sprint 2

Fuente: Elaboración propia

3.3.3 Desarrollo del Sprint 3: Manufacturación

En este módulo vemos el listado amplio que podría tener nuestras diversas recetas a la hora de
ser registradas, se decía en las reuniones obtenidas que el proceso y tiempo de la preparación,
moldeado y control de calidad será acorde a las recetas ,a continuación veremos el registro
que estas tendrán en su proceso .

3.3.3.1 Planificación de Sprint 3 Manufacturación: Listado de Receta

La planificación que dispone y el intervalo que tenga las recetas siempre serán acorde a lo
pedido, pedido como ser producto terminado destinado y distribuido hacia las diversas
sucursales de venta. La entrevista dio como fruto al orden de registro de cada una de ellas que
primaban a la hora de ser puestos en la mezcla de cada ingrediente.

Sprint 3: Modulo de Listado de Recetas

Sprint Duración horas Días de trabajo

3 53 12 días hábiles

91
 SPRINT BACKLOG

Tareas Tipo Est. Estado

Listado de receta Diseño 4 h/prog. Mostrar la vista de las

recetas

Creación de Recetas Desarrollo 7 h/prog Mostar formulario y

botón de creación de
creación de recetas

Modificación de Desarrollo 7 h/prog Mostar formulario para

Materia recetas posterior modificación
del recetas

Eliminación de Desarrollo 3 h/prog Eliminar su

correspondiente
Recetas
registro de BD.

Búsqueda de Receta Desarrollo 5 h/prog Mostrará los campos de

BD. En un formato
estético.

92
 Proceso de Receta Desarrollo 15 h/prog Mostrará la elaboración
cantidad tiempo de
preparado

Galería de productos Desarrollo 12 h/prog Mostrará la galería

amplia y variada del
producto terminado

Tabla 3.11: Tercer Sprint Backlog

Fuente: Elaboración propia

3.3.3.2 Especificación de Casos de Uso de Sprint 3

A continuación se tiene el caso de uso del primer sprint 3.

Figura 3.14. Diagrama de Casos de Uso de Registrar Receta

Fuente: Elaboración Propia

93
Registro de la gama variada de receta de la empresa:

ACTORES Administrador

PROPÓSITO Realizar la creación correspondiente de los datos de

receta, además de la modificación, eliminación de
receta.

RESUMEN Permite adicionar, modificar, eliminar y la busqueda de

informacion de la receta.

REFERENCIAS
CRUZADAS

FLUJO PRINCIPAL EVENTO ACTOR EVENTO SISTEMA

Ingresa el usuario a la
pestaña de receta

El sistema muestra el
listado de almacenes, con
un botón de crear uno
nuevo, los registros de
almacenes con su
respectivo botón de
eliminar, modificar y vista

94
Si el usuario presiona en
crear uno nuevo

El sistema muestra la
página correspondiente a
la adición de receta, con
un formulario para llenar
seguido de un botón de
guardar

Una vez llenado el

formulario el usuario hace
click en guardar

El sistema responde
enviándole a la página de
listado de almacenes,
donde además contiene un
botón de modificar, un
botón eliminar y un botón
de vista detallada de la
receta.

Si el usuario presionar
modificar

95
 El sistema le envía a la
página de creación de
receta con los campos
correspondientes llenados
con la información
vigente, y con el botón
guardar.

Una vez que el usuario a

modificado los datos
presiona el botón guardar

Posteriormente le envía a
la página de listado de
recetas

Si el usuario presiona
eliminar

El sistema envía un
mensaje de que si está
seguro de eliminar el
registro.

En caso de presionar si

96
 El sistema elimina el
registro de la base de
datos.

Si el usuario presiona
el botón de vista

El sistema muestra el
registro la información
de la receta según lo
que es esta registrado
en la base de datos.

PRECONDICIÓN Tener creada la base de datos con la tabla

correspondiente a receta

POS CONDICIÓN Permitir que los datos estén organizados de manera

eficiente en la base de datos

PRESUNCIÓN Seguridad en los datos.

Tabla 3.12. Registrar Receta

Fuente: Elaboración Propia

3.3.3.3 Diseño Navegacional Sprint 3: Manufacturación

El diseño navegacional muestra las opciones de navegación y procesos que el sistema tendrá
en su desarrollo. Ver figura:

97
Figura 3.15. Diseño navegacional del sprint 3
Fuente elaboración propia

98
3.3.3.4 Diseño de Presentación de Sprint 3: Manufacturación

Figura 3.16. Diseño de presentación del sprint 3

Fuente elaboración propia

En el diagrama de presentación para el módulo de inicio de sesión se muestra la interfaz

donde el administrador introduce los datos respectivos para ingresar al sistema. Proceso a
realizando.

99
3.3.3.5 Pantallas de Sprint 3 Manufacturación

A continuación se puede observar la página de inicio a la cual tendrá acceso el administrador

para ver los servicios que ofrece el sistema, como también el almacenero podrá acceder al
sistema a través del mismo.

Figura 3.17 Registro de Producto Registro de Receta

Fuente Elaboración Propia

3.3.3.6 Prueba Unitaria del Sprint 3

La prueba unitaria a continuación sirve para comprobar que el modulo funcione

correctamente. Ver Tabla 3.12

Prueba #3 Modulo de Registro de Receta

Descripción Al presionar ingresar, el administrador ingresa al sistema

100
 Objetivos 1. Que ingrese al sistema al presionar ingresar

2. Abrir el sistema

Conexión a internet desde cualquier medio (Pc, Celular, iPhone,

Condiciones
Tablet).

Resultado esperado Que se habrá satisfactoriamente el sistema

El sistema inicia correctamente y muestra la galería y sus

Resultados obtenido
diversas recetas

Tabla 3.13: Prueba unitaria - Sprint 3

Fuente: Elaboración propia

3.3.4 Desarrollo del Sprint 4: Modulo del Producto Final

Este desarrollo tuvo reuniones acertadas ya que conocimos más de la producción pero en esta
ocasión terminada es decir el proceso largo que dimos a conocer desde el módulo 1, modulo
2, modulo 3 implicaban una elaboración minuciosa de los chocolates la evaluación fue
realizada acorde a los tiempo y cantidades, la culminación de la misma da ra a conocerse en
un listado de producto termina el cual tendrá un proceso de distribución a las diversas
agencias que tiene la empresa.

3.3.4.1 Planificación del Sprint 4: Producto final

La planificación del módulo 4 dio lugar a un listado general de los productos que ponían fin
a su elaboración y ya estaban evaluados a la salida de la empresa a la venta.a continuación
detallaremos en la siguiente tabla como dio lugar al armado del modulo 4 en el bien de la
empresa:

101
 Sprint 4: Modulo de Listado del Producto Final

Sprint Duración Días de trabajo

horas

4 26 10 días hábiles

SPRINT BACKLOG

Tareas Tipo Est. Estado

Listado de Diseño 4 h/prog. Mostrar la vista de las

producto
producto final

Creación de Desarrollo 7 h/prog Mostar formulario y botón

de creación de producto
producto final
final

Modificación de Desarrollo 7 h/prog Mostar formulario para

posterior modificación del
Producto final
Producto final

Eliminación de Desarrollo 3 h/prog Eliminar su correspondiente

registro de BD.
Producto final

102
 Búsqueda de Desarrollo 5 h/prog Mostrará los campos de
Producto final BD. En un formato estético.

Tabla 3.14 Listado de Producto final

Fuente Elaboración Propia

3.3.4.2 Diagrama de Casos de Uso del Producto Final

Los diagramas de casos de uso del producto final módulo 4 se muestra en la imagen
siguiente:

Figura 3.18.Diagrama de Casos de Uso de Registrar Producto Final

Fuente: Elaboración Propia

103
NOMBRE 4.REGISTRAR PRODUCTO FINAL

ACTORES Administrador – Almacenero

PROPÓSITO Realizar la creación correspondiente de los datos de

producto, además de la modificación, eliminación de
producto.

RESUMEN Permite adicionar, modificar, eliminar y la búsqueda de

información del producto.

REFERENCIAS
CRUZADAS

FLUJO PRINCIPAL EVENTO ACTOR EVENTO SISTEMA

Ingresa el usuario a la
pestaña de producto

El sistema muestra el
listado de almacenes,
con un botón de crear
uno nuevo, los registros
de almacenes con su
respectivo botón de

104
 eliminar, modificar y
vista

Si el usuario presiona en
crear uno nuevo

El sistema muestra la
página correspondiente a
la adición de producto,
con un formulario para
llenar seguido de un
botón de guardar

Una vez llenado el

formulario el usuario hace
click en guardar

El sistema responde
enviándole a la página
de listado de almacenes,
donde además contiene
un botón de modificar,
un botón eliminar y un
botón de vista detallada
del producto.

105
Si el usuario presionar
modificar

El sistema le envía a la
página de creación de
producto con los campos
correspondientes
llenados con la
información vigente, y
con el botón guardar.

Una vez que el usuario a

modificado los datos
presiona el botón guardar

Posteriormente le envía a
la página de listado de
productos

Si el usuario presiona
eliminar

El sistema envía un
mensaje de que si está
seguro de eliminar el
registro.

106
 En caso de presionar si

El sistema elimina el
registro de la base de
datos.

Si el usuario presiona el
botón de vista

El sistema muestra el
registro la información
del producto según lo que
es esta registrado en la
base de datos.

PRECONDICIÓN Tener creada la base de datos con la tabla

correspondiente a producto

POS CONDICIÓN Permitir que los datos estén organizados de manera

eficiente en la base de datos

PRESUNCIÓN Seguridad en los datos.

Tabla 3.15.Registrar Producto Final

Fuente: Elaboración Propia

107
3.3.4.3 Diagrama de Casos de Uso del Negocio

Para mejor entendimiento e interpretación de los requerimientos se hace el uso de casos de

uso del negocio, donde podemos observar el funcionamiento de la empresa a través de los
artefactos que posee.

Figura 3.19. Diagrama de casos de uso de alto nivel del Negocio

Fuente: Elaboración Propia

108
3.3.4.4 Diagrama de Clases del Modelo de Negocio

El diagrama de clases mostrara el modelo de negocio general el mismo incluirá los 4 módulos
existentes pero en visión de negocio:

Figura 3.20. Diagrama de Clases del Modelo de Negocio

Fuente: Elaboración propia

109
3.3.4.5. Diagrama Entidad Relación del Modelo de Negocio

Figura 3.21. Diagrama Entidad Relación del Modelo de Negocio

Fuente: Elaboración Propia

110
3.3.3.6 Prueba Modulo 4 Producto final

El módulo 4 muestra satisfactoriamente el listando de los productos terminados :

Prueba #4 Modulo Producto final y de Negocio

Descripción Al presionar ingresar, el administrador ingresa al

sistema, moduló producto final.

Objetivos 1. Que ingrese al sistema al presionar ingresar

2. Abrir el sistema

3. Lista los productos

4. Actualiza los últimos productos registrados

Condiciones Conexión a internet desde cualquier medio (Pc,

Celular, iPhone, Tablet).

Resultado Que se habrá satisfactoriamente el sistema

esperado

Resultados El sistema inicia correctamente y muestra todos

obtenido los productos terminados en lista.

Tabla 3.16 Pruebas del Producto final

Fuente Elaboración Propia

111
3.4 Fase del Post – Game

3.4.1 Pruebas de Integración

Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del
desarrollo de software una vez que se han aprobado las pruebas unitarias. Únicamente se
refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso,

Modulo Resultado

Incisión de sesión En este módulo se obtuvo 4 en cuentas 4

están conformes
personal

Control de En este módulo de estuvieron 6 encuestados 6

inventarios conformes

Control de En este módulo de estuvieron 2 encuestados 2

manufacturación conformes

Control de En este módulo de estuvieron 1 Encuestados 1

producto final conformes

Tabla 3.17: Resumen de pruebas de integridad

Fuente: Elaboración propia

3.5 Pruebas de Stress

Esta prueba se utiliza normalmente para romper la aplicación. Se va doblando el número de

usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe.

112
Este tipo de prueba se realiza para determinar la solidez de la aplicación en los momentos de
carga extrema y ayuda a los administradores para determinar si la aplicación rendirá lo
suficiente en caso de que la carga real supere a la carga esperada. Estas pruebas fueron
realizadas en Webserver stress tool.

A continuación se muestra el tiempo de conexión de los usuarios al sistema y se puede

observar que el uso de la memoria del sistema puede llegar a 100% de su uso, pero después de
un tiempo medido en segundos, el uso de la memoria va disminuyendo y se puede observar
que al llegar a los 3500 [s], al finalizar una petición el uso de la memoria cae al 0%.

User Simulation: 4 simultaneous users - Click times "per URL"

Figura 3.22. Menoría del sistema y carga del CPU

Fuente: Elaboración propia

La siguiente figura nos muestra la transferencia de datos y el tiempo de respuesta del sistema
a las peticiones del usuario.

La línea roja nos indica los tiempos de petición del usuario, la línea verde nos indica el tiempo
de respuesta del servidor, la línea celeste representa el tiempo de recibo de respuesta del
servidor, y la línea azul representa el tráfico de datos de kb/s del servidor.

113
 Figura 3.23 Capacidad de carga del sistema
Fuente: Elaboración propia

Po lo tanto el sistema web con la simulación realizada con usuarios virtuales, se puede
concluir que la capacidad de tiempo de respuesta es estable con cada usuario, además de que
el servidor es capaz de responder a un máximo de 900 usuarios activos simultáneamente y que
el tiempo y usuarios mínimos aceptables es de que en 30 segundos con la capacidad de 400
usuarios activos simultáneamente.

114
 Capítulo IV

Calidad y Seguridad

4.1 Calidad de Software

En todo sistema es necesario conocer la calidad del mismo, debido a que este es un factor muy
importante para el buen funcionamiento del mismo .En el desarrollo de software, la calidad de
diseño acompaña a la calidad de los requisitos, especificaciones y diseño del sistema. La
calidad de concordancia es un aspecto centrado principalmente en la implementación; si la
implementación sigue al diseño, y el sistema resultante cumple con los objetivos de requisitos
y de rendimiento, la calidad de concordancia es alta.

4.1.1 Web Quality Evaluation Methodology – Web Site QEM

La metodología WEB SITE QEM sirve para la evaluación de calidad de sitios web, cuyo
autor es el perfil de usuario utilizado para la evaluación de calidad es el de licenciado de
producción control de inventarios y fin de cada uno de ellos. Luis Antonio Olsina, 2000.

4.1.1.1 Definición de Implantación de la Evolución Elemental

En esta fase consideramos los diferentes criterios de calidad, valores y rangos críticos,
funciones para determinar la preferencia elemental una vez definidos y consensuados los
criterios para mediar cada atributo, se debe ejecutar el proceso de medición, es decir la
recolección de datos de cómputo de las variables y las preferencias elementales, para
finalmente presentar los resultados.

4.1.1.2 Criterio de Preferencia de Calidad Elemental

Por definición un criterio elemental es una correspondencia del valor de la variable de calidad
Xi en el valor de preferencia o indicador elemental de calidad. En términos generales, el valor
medido de la variable es un número real. X R

115
Estructura de Agregación de Preferencia Parcial

Los valores ponderados en los pesos Pi (0.3, 0.3, 0.2, 0.2) de las características de más alto
nivel, los cuales son útiles para calcular el indicador de calidad global.

Figura 4.1: Estructura de agregación de preferencias parciales

Fuente: Olsina, 1999

4.1.1.3 Evaluaciones Elementales

A partir del árbol de requerimientos y para cada atributo cuantificable Ai, debemos asociar la
variable Xi, que tomara el proceso real a partir de un proceso de medición. Al mismo tiempo,
para el rango de valores para la variable Xi, por medio de un criterio elemental y mencionar el
rango de captación.

Figura 4.2: Rango de aceptabilidad de preferencia de calidad

Fuente: Olsina, 1999

116
4.1.1.4 Especificación de Requerimiento de Calidad

De acuerdo a los perfiles de usuario y con la metodología, se evaluó las características que
son más relevantes.

a) Evaluación global

La evaluación global se realiza con la finalidad de obtener un indicador de calidad de la

aplicación. Aplicando el mecanismo de agregación paso a paso, las preferencias de calidad
elementales deben estructurarse de abajo hacia arriba.

Los valores obtenidos en los IEi, son la base para la evaluación global, recurriendo a LSP
(Logic Scoring of Preference) con la función de la media potencia pesada.

IG(r) = (P1*IE1^r + P2*IE2^r+…….+Pm*IEm)^1/r

−∞ ≤ 𝒓 ≤ +∞ ; 𝟎𝑰𝑬𝒊 ≤ 𝟏

(P1+ P2+….+Pm)=1 ; Pi > 0 ; i=1…m

4.1.1.5 Computo de Preferencias Parciales

En la tabla 4.1, realizamos el cómputo de las preferencias parciales.

CARACTERÍSTICAS X IE Peso Peso *IE

1. Usabilidad 92.5 0.95 0.4 0.3316

1.1.1 Mapa del sitio 100 1 0.6 0.6

1.1.2 Tabla de Contenidos 100 1 0.4 0.4

117
1.2 Ayuda explicativa a los usuarios 60 0.9 0.5 0.4

1.2.1 Lista de personal 100 1 0.5 0.5

1.3 Aspectos de interfaces y 100 1 0.2 0.2

estéticos

1.3.1 Aspectos de estilo 95 0.9 0.3 0.36

1.3.1.1 Uniformidad en el estilo global 90 0.9 0.3 0.27

1.3.1.2 Uniformidad en los formularios 95 0.9 0.2 0.16

2. Funcionalidad 92 0.9 0.4 0.332

2.1.1 Mecanismo de búsqueda en el 95 0.9 0.4 0.32

sitio web

2.1.1.1 Búsqueda del personal 90 0.9 0.4 0.33

2.1.1.2 Búsqueda del Inventario 90 0.9 0.3 0.27

2.1.1.3 Búsqueda de producto 90 08 0.2 0.33

118
 2.1.2.4 Búsqueda de producto final 90 0.8 0.3 0.24

2.2. Interfaz adecuada a las 91 0.9 0.6 0.54

necesidades del medio

2.2.1. Formularios diseñados 100 1 0.4 0.4

especialmente para su uso

3. Confiabilidad 95 0.9 0.1 0.1

3.1 Enlaces rotos 100 1 0.5 0.5

3.2 Enlaces inválidos 90 0.8 0.5 0.4

4. Eficiencia 96 0.9 0.2 0.16

4.1 Paginas de Acceso Rápido 100 1 0.5 0.5

4.2 Accesibilidad 90 0.8 0.5 0.35

Tabla 4.1: Computo de las preferencias parciales

Fuente: Elaboración propia

En la tabla 4.2 realizamos el cómputo de las preferencias para las características de más alto
nivel y calculamos la calidad global.

119
b) Criterio Global

Los resultados de los valores de las preferencias de calidad para las características de más alto
nivel, y valores finales se muestran en la siguiente tabla.

Característica de más alto nivel Preferencia

1. Usabilidad 92.5

2. Funcionalidad 92

3. Confiabilidad 91

4. Eficiencia 96

Calidad Global 92.87

Tabla 4.2: Calidad global

Fuente: Elaboración propia

De acuerdo a la valoración de la calidad del sitio web, aplicando la metodología Web Site
QEM el valor de calidad total del Sistema Web de Control de Inventarios, Manufacturación y
Producto Final es de 92,87%

Por lo tanto, el nivel de aceptabilidad es satisfactoria, porque el valor de 92,87% está en el

rango de 60 a 100%

4.2 Seguridad

La seguridad es un aspecto muy importante en cualquier sistema, el objetivo de la seguridad

es prevenir fuga de información. Los problemas de seguridad de un sistema web, pueden

120
venir de las herramientas que se utilizan para su desarrollo o pueden ser producto de una falla
en el diseño lógico.

4.2.1 Autenticación

Procedimiento informático que permite asegurar que un usuario de un sitio web u otro
servicio similar es auténtico o quien dice ser. Se implementa la autenticación de usuarios tanto
para la empresa INCADEX S.R.L., para determinar que un usuario sea quien dice ser.

4.2.2 Encriptar Contraseña

MD5 es uno de los algoritmos de reducción criptográficos diseñados por el profesor Ronald
Rivest del MIT (Massachusetts Institute of Technology, Instituto Tecnológico de
Massachusetts). Fue desarrollado en 1991 como reemplazo del algoritmo MD4 después de
que Hans Dobbertin descubriese su debilidad. Para encriptar la contraseña del usuario se
utiliza el algoritmo denominado md5 (Message Digest 5), el cual esta implementado en
Python. Con esta función se encripta la contraseña por el usuario al momento de registrarse.

4.2.3 Preparar y Validar Datos

Permite validar los datos introducidos por el usuario con las siguientes reglas que aplicamos
en el proyecto.

Regla Descripción

from urllib.parse import urlparse Función para la conversión de una URL

realizando splitting a una URL

121
 os.path.commonpath(['/usr/lib', En esta función solo podrían regresar caminos
'/usr/local/lib']) válidos.

'/usr'

is_empty Verifica si es vacío o no (TRUE o FALSE)

is_null Verifica si es nulo o no (TRUE o FALSE)

max_size Verifica si es mayor el tamaño o no (TRUE o

FALSE)

min_size Verifica si es menor el tamaño o no (TRUE o

FALSE)

Tabla 4.3 Validación de datos

Fuente elaboración propia

A continuación mostramos las funciones aplicadas a nuestro proyecto.

Regla Funcion Django Example Descripcion

Proteccion Django <style class={{ var Protección de ataque XSS

XSS }}>...</style>

122
Proteccion Django csrf_exempt Protección contra ataques
CSRF CSRF

Proteccion Django Usando extra() y Protección de Ataque de

SQL RawSQL. Injeccion de Codigo SQL
Injection

SSL/HTTPS Django SECURE_PROXY Usando HTTP Strict

_SSL_HEADER , Transport Security
(HSTS)
SECURE_SSL_RE
DIRECT, es una cabecera que
informa al navegador de
SECURE_PROXY
futuras conecciones y a un
_SSL_HEADER,
sitio particular que

SESSION_COOKI siempre debe estar usando

E_SECURE, el protocolo HTTPS

CSRF_COOKIE_S
ECURE

Tabla 4.4: Preparar los datos introducidos por el usuario

Fuente: Elaboración propia

123
 Capítulo V

Análisis Costo Beneficio

5.1 Cocomo II

En todo proyecto es importante tener una planificación o estimación de costos, no solo de los
requerimientos de hadware, costos de tiempo y esfuerzo; COCOMO II, es un método de
estimación de costos y refuerzos de únicamente proyecto de software, que permite por medio
de los módulos planificados en el software.

El Modelo Constructivo de Costes (COCOMO) es un modelo matemático de base emperica,

utilizando para la estimación de costes de software.

Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor,
a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

Para calcular el costo del proyecto se lo realizara haciendo uso del modelo COCOMO II. El
modelo COCOMO, tiene una jerarquía de modelos como ser básico, intermedio y avanzado,
la cual se aplica a tres diferentes tipos de software.

ORGÁNICO: Proyectos relativamente sencillos, menores a 5000 líneas de código, implica

procesamiento de datos, uso de la base de datos se focaliza en transacciones y recuperación de
datos

SEMIACOPLADO: Proyectos intermedios en complejidad y tamaño. La experiencia en ese

tipo de proyectos es variable y las restricciones intermedias.

EMPOTRADO: Proyectos bastantes complejos, en los que apenas se tiene experiencia y en

un entorno de gran innovación técnica.

124
La tabla 5.1 muestra los coeficientes del proyecto de software de acuerdo a los tres modos
expuestos anteriormente.

Proyecto de Software A B c d

Orgánico 2.4 1.05 1.05 0.38

Semi-Acoplado 3.0 1.12 2.05 0.35

Empotrado 3.6 1.20 2.5 0.32

Tabla 5.1: Coeficientes: a, b c y d COCOMO II

Fuente: Pressman, 2002

COCOMO II consta con tres modelos de estimación, los mismos se representan en 3

ecuaciones:

E = a (KLDC) b, persona-mes

D = c (E) d, meses P = E /

D, personas

Dónde:

E: Esfuerzo requerido por el proyecto expresado en persona-mes.

D: Tiempo requerido por el proyecto expresado en meses.

P: Número de personas requeridas para el proyecto.

a, b, c y d: Constantes con valores definidos según cada sub-modelo.

125
KLDC: Cantidad de líneas de código, en miles.

5.2 COSTO DEL SISTEMA

El costo del sistema se lo planteara en tres partes: desarrollo de software, implementación y

elaboración del proyecto.

5.2.1 COSTO DE DESARROLLO DEL SOFTWARE

Para el cálculo del desarrollo del software se tendrá como partida el punto función no
ajustado.

Factor de ponderación

Parámetros Cuenta Simple Medio Complejo Total

N° de Entradas de usuario 15 3 4 6 56

N° de salidas usuario 19 4 4 7 100

N° de peticiones de usuario 22 3 4 5 81

N° de archivos 15 7 10 15 100

Nº de interfaces externas 3 5 7 10 14

Cuenta Total 351

Tabla 5.2: Punto función

Fuente: Elaboración propia

126
Por lo tanto el Punto Función es 351

Este resultado se debe convertir a KLDC (Kilos de Líneas de Código), para ello se utiliza la
siguiente la tabla 5.3

Lenguaje Nivel

Python 30

Javascript 20

Html5 19

css 15

Frameworks Nivel

Django 25

Flask 10

Jinja 9

Jquery 6

Bootstrap 5

Tabla 5.3: Conversión de puntos función a KLDC

Fuente: Pressman, 2002

127
Como el desarrollo del sistema está basado en Python entonces se tiene

Factor LDC/PF = 30

Con el factor LDC/PF = 30 y reemplazando este dato más el punto función no ajustada se
calcula en la siguiente ecuación:

LDC = PF * Factor LDC/PF

LDC = 351 * 30

LDC = 10530

Para convertirlo a KLDC dividimos LDC entre 1000

KLDC = LDC / 1000

KLDC = 10530 / 1000

KLDC = 10.53

A continuación haremos el cálculo del esfuerzo necesario para la programación del sistema,
para ello utilizamos la siguiente ecuación:

E = a (KLDC) b

Para hallar el esfuerzo “E” definimos antes el tipo del proyecto que en nuestro caso es
semiacoplado y utilizamos de los datos de la tabla 5.1. Con esto se reemplaza en la fórmula:

E = a (KLDC) b

E = 3 (10.53) 1.12

E = 41.90 persona-mes

128
Ahora para hallar el tiempo del proyecto usamos los datos de la tabla 5.1, recordando que el
proyecto es de tipo orgánico y reemplazando en la siguiente formula:

D = c (E) d meses

D = 2.05 (41.90) 0.35

D = 7.57 ≈ 7 meses

De aquí concluimos que el proyecto deberá tener un desarrollo de 7 meses.

Para calcular la cantidad en número de programadores se utiliza la siguiente formula,

reemplazando los datos ya encontrados:

P=E/D

P = 41.90 / 7

P = 5.98 ≈ 6 programadores

El salario promedio de un programador oscila entre los 200 a 250 $us, en nuestro caso
tomaremos un promedio de 225$us. A partir de este monto podemos calcular el costo total del
desarrollo del software.

Costo mensual de desarrollo = Nro. De programadores * Salario promedio

Costo mensual de desarrollo = 6 * 225

Costo mensual de desarrollo = 1350 $us

Como el desarrollo de software se lo estima en 7 meses resultado que se lo vio anteriormente,

se tiene:

Costo total del desarrollo = Costo mensual de desarrollo * Nro. De meses

129
Costo total del desarrollo = 1350 * 7

Costo total del desarrollo = 9450 $us

5.2.2 Costo de Implementación

La empresa no cuenta con un área de sistemas actualmente al corriente del trabajo diario pero
si cuenta con una actualización anual para el registro de inventarios por lo cual el costo de
implementación que se tendrá será la configuración de la parte del servidor. El mismo tendrá
un costo de 100Sus.

Costo de Implementación = 100$us

5.2.3 Costo de Elaboración del Proyecto

Los costos de elaboración del proyecto se refieren principalmente a los gastos que se realizan
a lo largo de las diferentes fases de la metodología Scrum y UWE.

Estas las podemos ver expresadas en la tabla 5.4

Detalle Importe ($us)

Análisis y diseño del proyecto 300

Material de escritorio 20

Internet 30

Otros 50

130
 Total 400

Tabla 5.4: Costo de elaboración del proyecto

Fuente: Elaboración propia

Costo de Elaboración del Proyecto = 400$us

5.2.4 Costo Total del Software

El costo total del software se lo obtiene de la sumatoria del costo de: desarrollo,
implementación y elaboración del proyecto. La tabla 5.5 expresa estos resultados.

Detalle Importe ($us)

Costo de desarrollo 9450

Costo de implementación 100

Costo de elaboración del proyecto 400

Total 9950

Tabla 5.5: Costo total del software

Fuente: Elaboración propia

5.3 VALOR ACTUAL NETO

El VAN o valor actual neto es un procedimiento que permite calcular el valor presente de un
determinado número de flujos de caja futuros, originados por una inversión. La metodología
consiste en descontar al momento actual (es decir, actualizar mediante una tasa) todos los
flujos de caja futuros del proyecto. A este valor se le resta la inversión inicial, de tal modo que
el valor obtenido es el valor actual neto del proyecto.

131
La fórmula que utilizaremos para hallar el valor actual neto será:

Dónde:

VAN: Valor Actual Neto

Ganancias: Ingreso de flujo anual Costos: Salidas de flujo anual n: Numero de periodo k: Tasa
de descuento o tasa de interés al préstamo

Los gastos y ganancias que se estiman en un lapso de 4 años los mostramos en la tabla 5.6,
para este caso en particular utilizamos una tasa de descuento del 12% ya que es la tasa actual
de interés del préstamo en las entidades financieras.

Año Costos Ganancias Costos/(1+i)n Ganancias/(1+i)n Resultado

1 9950 0 8883.92 0

2 3100 5970 2471.30 4759.24 2287.94

3 1000 6965 711.78 4957.54 4245.76

4 900 7960 571.96 5058.72 4486.76

∑ 14950 20895 12638.96 14775.5

132
 𝑮𝒂𝒏𝒂𝒏𝒄𝒊𝒂𝒔 𝑪𝒐𝒔𝒕𝒐𝒔 2136.54
𝑽𝑨𝑵 = ∑ 𝒏− ∑
(𝟏 + 𝟎. 𝟏𝟐) (𝟏 + 𝟎. 𝟏𝟐)𝒏

Tabla 5.6: Calculo VAN

Fuente: Elaboración propia

La tabla 5.7 muestra si un proyecto es rentable y de acuerdo a ciertos criterios más el valor del
VAN concluiremos si es rentable o no.

Valor del VAN Interpretación

VAN > 0 El proyecto es rentable

VAN = 0 El proyecto también es rentable, ya que se

incorpora la ganancia de la tasa de interés.

VAN < 0 El proyecto no es rentable.

Tabla 5.7: Criterio de interpretación del VAN

Fuente: Elaboración propia

De aquí concluimos: considerando que el VAN = 2136.54 ≈ 2137 y siguiendo los criterios de
la tabla 5.7 se afirma que nuestro proyecto es rentable ya que 2137 es mayor a 0.

5.3.1 Costo / Beneficio

Para hallar el costo/beneficio de un proyecto se aplica la siguiente ecuación:

Costo/Beneficio = ∑ Ganancias / ∑ Costos

De aquí, reemplazando en la ecuación anterior los valores conocidos de la tabla 5.5

Costo/Beneficio = 14775.5 / 12638.96

133
 Costo/Beneficio = 1.17 $.

Con este resultado interpretamos de la siguiente manera: por cada dólar invertido en el
proyecto de software la institución genera una ganancia de 0.17 $us.

5.4 Tasa Interna De Retorno

Cuando en la fórmula del VAN el valor de “k” es igual a “0” pasa a llamarse TIR (Tasa
Interna de Retorno). La TIR es la rentabilidad que nos proporciona al proyecto.

La ecuación que utilizaremos es la siguiente:

Dónde:

TIR: Tasa Interna de Retorno

Ganancias: Flujo de entrada de un periodo Costos: Flujo de salida de un periodo i: Tasa de

interés al ahorro n: Numero de periodo

La tabla 5.7 muestra una mejor compresión de ecuación TIR y expresando los resultado
encontrados en las misma.

Año Costos Ganancias 𝑮𝒂𝒏𝒂𝒏𝒄𝒊𝒂𝒔 − 𝑪𝒐𝒔𝒕𝒐𝒔

(𝟏 − 𝒊)𝒏

1 9950 0 -11306.81

134
 2 3100 5970 3706.09

3 1000 6965 8753.11

4 900 7960 11772.64

TIR 12925.03

Tabla 5.8: Calculo de la tasa interna de retorno

Fuente: Elaboración propia

El proyecto nos dará una rentabilidad de 12925.03$us.

135
 Capítulo VI

Conclusiones Y Recomendaciones

6.1 Conclusiones

A la conclusión de este proyecto verificamos el cumplimiento de los objetivos planteados al

principio del mismo.

Por tanto se llega a las siguientes conclusiones:

• Se desarrolló el sistema web automatizando en el proceso de gestión que permite

verificar la recepción de los registros de materia prima, almacenamiento, elaboración hasta la
salida de producción para la empresa INCADEX S.R.L.

• Se generó el proceso de ingreso de materiales, asignados a cada insumo en la base de

datos minimizando la transcripción de datos manualmente.

• Se tiene un mecanismo de búsqueda de todos los inventarios, detallada, rápida y segura

sobre los insumos en tiempos óptimos.

• Los mecanismos de seguridad en los productos o al momento de registrarlos aumenta el

grado de actualización segura, dejando contento al administrador a la hora de pedir datos.

6.2 RECOMENDACIONES

Al haber acabado el presente proyecto de grado, titulado Sistema web de control de

inventarios, manufacturación y producto final para la empresa industrial comercial INCADEX
S.R.L, se tiene las siguientes recomendaciones:

• Se recomienda realizar el mantenimiento al sistema web, para mantener el buen

desempeño del sistema y prevenir posibles fallas.

136
• Para asegurar la integridad de los datos e información contenida del sistema, se
recomienda a los usuarios políticos de seguridad, como ser la longitud de las contraseñas, para
evitar el acceso de personas ajenas y maliciosas al sistema.

137
BIBLIOGRAFÍA
Referencias Bibliográficas
[GARCIA, 2013] García Chi Rosa Imelda. Guía Técnica de Ingeniería Web. Instituto
Tecnológico de ciudad Valles 2013.
[CAMPS, 2005] Camps Rafael, Casillas Luis, Costal Dolors. Base de datos. Eureca Media.
Universidad Oberta de Catalunya mayo 2005.
[PERALTA, 2003] Peralta Adriana. Metodología SCRUM. Universidad ORT Uruguay.
Facultad de Ingeniería. 2003.
[PRESSMAN, 2005] Pressman Roger, “Ingeniería del Software”. ed. mcgraw-hill /
interamericana de mexico 2005.
[CANOS, 2000] Canos José, Letelier P. “Metodologías Ágiles en el Desarrollo de
Software”. Universidad Politécnica de Valencia. España 2000.
Tesis y Proyectos
[LOZA, 2015] Vila C. María V. 2004. Sistema Web de Registro y Control– Seguro
INSANESS. Universidad Mayor de San Andrés.
[CORONE, 20016] Copa H. Pablo G. 2004. Sistema Web y Control de afiliación – Caja
Petrolera de Salud. Universidad Mayor de San Andrés.
[CITON, 2006] Citón María Laura. 2006. Método ágil scrum aplicado al desarrollo de un
software de trazabilidad – Universidad de Mendoza
[JEREZ, 2004] Jerez Lugo, Carlos Augusto. 2004. Seguridad para lograr Confiabilidad y
Calidad de los Servicios Digitales en Internet - Universidad de las Américas Puebla.
[BORGHELLO, 2001] Borghello Cristian F. 2001. Seguridad Informática - Implicancias e
Implementación
[NUÑEZ, 2010] Nuñez Jose. 2010. Usabilidad en Metodologías Agiles. Universidad
Politécnica De Madrid.
Sitios Web y Materiales Electrónicos
[ALBALADEJO, 2013] Albaladejo Xavier. Como gestionar proyectos con Scrum. [En
línea] [Disponible en:] <http://www.proyectosagiles.org/que-es-scrum> [Consulta 9 julio
2015]
[GALIANO, 2012] Galiano Francesco. “Desarrollo Ágil de Software”. [En línea]
[Disponible en:] <http://frayu.blogspot.com/2012/09/desarrollo-agilde-software.html>
[Consulta 08 octubre 2015]
[LMU, 2000] LMU – Ludwig-Maximilians-Universität München. UWE – UML – base
Web Engineering. [En línea] [Disponible en:]
<http://uwe.pst.ifi.lmu.de/teachingTutorial.html> [consulta 10 julio 2015]

138
 [LÓPEZ, 2009] López Eliazar. Arquitectura de n capas. [En línea] [Disponible en:]
<https://www.academia.edu/10102692/Arquitectura_de_n_capas> [Consulta 18 septiembre
2015]
[IBM, 2013] IBM Knowledge Center. “Introduction to DB2 for z/OS”. [En línea]
[Disponible en:] <http://www-01.ibm.com/support/knowledgecenter/
SSEPEK_10.0.0/com.ibm.db2z10.doc.intro/src/tpc/db2z_whatisdb2.di ta?lang=es >
[Consulta 19 agosto 2015]
[MICROSOFT, 2008] Microsoft. Database Mirroring Overview. [En línea] [Disponible
en:] <https://technet.microsoft.com/en-us/library/ms189852(v=sql.105) .aspx> [Consulta
20 agosto 2015]
[W3SCHOOLS, 2015] The world's largest web developer site. [En línea] [Disponible en:]
<http://www.w3schools.com/ > [Consulta 16 de octubre de 2015].
[YII2, 2015] Página Oficial de Python. [En línea] [Disponible en:]
<http://www.yiiframework.com/wiki/?tag=yii2> [Consulta 15 de octubre de 2015].
[MARIADB, 2015] Página Oficial de ORM [En línea] [Disponible en:]
<https://mariadb.com> [Consulta 17 de octubre de 2015].
[WEBARCHIVE, 2015] Internet Archive Wayback Machine. Investigación IT – Forks de
MySQL. [En línea] [Disponible en:] <http://web.archive.org/web/
20121203042114/http://investigacionit.com.ar/forks-de-mysql> [Consulta 17 de octubre de
2015].
[ANGELFIRE, 2012] Angelfire. ¿Qué es la Ingeniería de Software?. [En línea]
[Disponible en:] <http://www.angelfire.com/scifi/jzavalar/apuntes/IngSoftware .html>
[Consulta 9 de octubre de 2015]
[ROMERO, 2011] Romero M. Andrés. Aspectos Básicos de la Seguridad en Aplicaciones
Web. [En línea] [Disponible en:] <http://www.seguridad.unam.mx/ documento/ ?id=17>
[Consulta 10 de octubre de 2015].
[TENNESSEE, 2015] The University of Tennesse, Knoxville. [En línea] [Disponible en:]
<https://help.utk.edu/kb/index2.php?func=show&e=1699> [Consulta 19 agosto 2015]
[ECURED, 2015] EcuRed Conocimiento con todos y para todos. Servidor HTTP
Apache. [En línea] [Disponible en:] <http://www.ecured.cu/ Servidor_HTTP_Apache>
[Consulta 23 agosto 2015]
[SONCCO, 2008] Soncco Araujo Lewis M. Tecnología Web. Pontificia Universidad
Católica del Perú. [En línea] [Disponible en:]
<http://es.slideshare.net/MeliVidal/tecnologia-web-5778008> [Consulta 10 de julio de
2015].
[SBS, 2015] Superintendencia de banca, seguros y afp. República del Perú. [En línea]
[Disponible en:] <http://www.sbs.gob.pe/usuarios/categoria/ consulta-deafiliados/250/c-
250> [Consulta 10 de julio de 2015].

139
ANEXOS

140
141
142
143
ANEXO C – MARCO LÓGICO

RESUMEN INDICADORES MEDIOS DE SUPUESTOS

NARRATIVO DE OBJETIVOS VERIFICACIÓ
VERIFICABLES N (MDV)
Fin Disminuir el Sistema web
número de concluido, para
Mejorar el control procesos verificar la
gestionando los datos para manuales en la mejora de los
así empresa. indicadores
Optimizar el tiempo y
tener datos exactos y
rápidos.
Propósito Documento del Voluntad de los
perfil de jefes de la
Controlar los datos de los El tiempo para proyecto de institución.
inventarios almacenados hacer el debido grado
materiales-insumos, control y Voluntad
elaboración y producto seguimiento a los Implementación política de la
final de la empresa datos del almacén, de los módulos empresa.
INCADEX S.R.L.Atreves manufacturación y
de un sistema de producto final será
información óptimo.
Producto: Buen
desempeño del
equipo de
Software informático que Sistemas de desarrollo del
contendrá los siguientes administración de sistema web.
subsistemas: usuarios, módulos Documento del
perfil de Voluntad del
de inventarios, líder de equipo
 Módulo de ingreso de módulo de proyecto de
materiales grado de desarrollo.
reportes
 Módulo de concluidos Los equipos
Seguimiento del
inventarios de (servidores)
El sistema estará cliente al
secciones físicas para
proyecto.
 Módulo de basado en las implementar
seguimiento de bases de datos Pruebas a los todo el sistema
historiales clínicos relacionales. módulos deben
 Módulo de avanzados. funcionar
inventarios correctamente.
Módulo de reportes
Voluntad de los
jefes de planta
y almacén
destinado
también a los
responsables de
cada sección

144
actividades Equipos  Historias de El instituto
computacionales usuario debe proveer
 Recabar información.
 Informes información al
 Reuniones y Personas que
Control de equipo de
entrevistas con conformaran el desarrollo.
avance del
personas del área de equipo de
sistema por el
almacen,manufactura desarrollo Correcto
responsable de
ción, funcionamiento
Persona que los almacenes y
y producto final de los equipos
represente la jefe de planta
computacional
Proceder con el empresa como es
desarrollo de la cliente. Información
aplicación mediante de la
Información de
la metodología ágil bibliografía.
distintas fuentes:
XP
libros, internet y
Análisis.- se crea la otros.
documentación.
Diseño.- se diseña las
partes del sistema.

145
DOCUMENTACIÓN

146