Sistema Web de Residuos Sólidos PRESENTADO POR Jose Remigio Leandro

Esta obra está licenciada bajo la Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional. Para ver una copia de esta licencia, visita http://creativecommons.org/licenses/by-nc-sa/4.0/.

UNIVERSIDAD NACIONAL

“JOSÉ FAUSTINO SÁNCHEZ CARRIÓN”

FACULTAD DE INGENIERÍA INDUSTRIAL, SISTEMAS E INFORMÁTICA

ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA INFORMÁTICA

TESIS

Sistema Web de Residuos Sólidos

PRESENTADO POR:

REMIGIO LEANDRO, JOSÉ EDWAR

PARA OPTAR EL TÍTULO DE INGENIERO INFORMÁTICO

ASESOR:

ING. MEYHUAY FIDEL, JUAN CARLOS

HUACHO – PERÚ

2014

ii

DEDICATORIA

A Dios por haberme permitido

llegar hasta este punto y haberme dado

salud.

A mi familia por haberme

apoyado en todo momento.

A mi madre Tadita en especial

ser una fuente inagotable de

inspiración.

iii

AGRADECIMIENTOS

En primer lugar quiero mencionar a mi familia,

por su apoyo incondicional tanto en el aspecto

personal como profesional y por su amor que me

hace más fuerte y me impulsa a seguir adelante.

En segundo lugar me gustaría agradecer a mi

asesor el Ing. Meyhuay Fidel, Juan Carlos por

brindarme la oportunidad de recurrir a su capacidad

y experiencia, importante para el correcto desarrollo

de esta tesis.

En tercer lugar quiero señalar a mis amigos y

compañeros, que nunca han dejado de apoyarme e

incentivarme a seguir adelante.

iv

ÍNDICE GENERAL

DEDICATORIA ..........................................................................................................................................ii

AGRADECIMIENTOS ................................................................................................................................. iii

ÍNDICE GENERAL ................................................................................................................................. iv

ÍNDICE DE FIGURAS ........................................................................................................................... vii

ÍNDICE DE TABLAS .............................................................................................................................. ix

RESUMEN .............................................................................................................................................. xi

INTRODUCCIÓN ...................................................................................................................................... xii

CAPÍTULO I ....................................................................................................................................... 13

1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA ......................................... 13

1.2. FORMULACIÓN DE PROBLEMA ............................................................................ 15

1.2.1. PROBLEMA GENERAL ...................................................................................... 15

1.2.2. PROBLEMA ESPECÍFICO ................................................................................. 16

1.3. OBJETIVO DE LA INVESTIGACIÓN ...................................................................... 16

1.3.1. OBJETIVO GENERAL ........................................................................................ 16

1.3.2. OBJETIVO ESPECÍFICOS .................................................................................. 16

1.4. JUSTIFICACIÓN DE LA INVESTIGACIÓN ........................................................... 17

1.4.1. JUSTIFICACIÓN TEÓRICA ............................................................................... 17

1.4.2. JUSTIFICACIÓN PRÁCTICA ............................................................................ 18

CAPÍTULO II ...................................................................................................................................... 20

2.1. ANTECEDENTES DE LA INVESTIGACIÓN .......................................................... 20

2.2. BASES TEÓRICAS ..................................................................................................... 23

2.2.1. SISTEMA WEB...................................................................................................... 23

2.2.2. METODOLOGÍA RATIONAL UNIFIED PROCESS ....................................... 36

2.2.3. CONTROL DE RESIDUOS .................................................................................. 65

2.3. DEFINICIÓN DE TÉRMINOS .................................................................................... 66

2.4. HIPÓTESIS DE LA INVESTIGACIÓN ..................................................................... 70

2.4.1. HIPÓTESIS GENERAL ........................................................................................ 70

2.4.2. HIPÓTESIS ESPECIFICA ................................................................................... 70

CAPÍTULO III ..................................................................................................................................... 71

3.1. DISEÑO METODOLÓGICO ....................................................................................... 71

v

3.1.1. TIPO DE INVESTIGACIÓN ................................................................................ 71

3.1.2. NIVEL DE INVESTIGACIÓN ............................................................................. 71

3.2. POBLACIÓN Y MUESTRA ......................................................................................... 72

3.2.1. POBLACIÓN .......................................................................................................... 72

3.2.2. MUESTRA .............................................................................................................. 72

3.3. OPERACIONALIZACIÓN DE VARIABLES E INDICADORES ........................... 73

3.3.1. IDENTIFICACIÓN DE VARIABLES ................................................................. 73

3.3.2. OPERACIONALIZACIÓN DE VARIABLES .................................................... 73

3.4. TÉCNICAS DE RECOLECCIÓN DE DATOS .......................................................... 74

3.5. TÉCNICAS PARA EL PROCESAMIENTO DE LA INFORMACIÓN .................. 74

CAPÍTULO IV ..................................................................................................................................... 75

4.1. ANÁLISIS ....................................................................................................................... 75

4.1.1. ANÁLISIS DE ENTREVISTAS ........................................................................... 75

4.1.2. REQUERIMIENTOS ............................................................................................ 76

4.1.3. ANÁLISIS DEL SISTEMA ................................................................................... 77

4.1.4. DIAGRAMA DE CLASES: ................................................................................... 86

4.2. DISEÑO .......................................................................................................................... 88

4.2.1. ARQUITECTURA DEL SISTEMA ..................................................................... 88

4.2.3. DISEÑO DE INTERFAZ GRAFICA ................................................................. 109

4.2.4. DIAGRAMA DE DESPLIEGUE ........................................................................ 117

4.3. IMPLEMENTACIÓN ................................................................................................. 118

4.3.1. FASE 1: PREPARAR UN AMBIENTE OPERACIONAL Y UNO DE

PRUEBA SEPARADOS ...................................................................................................... 118

4.3.2. FASE 2: OFRECER CAPACITACIÓN A LOS USUARIOS,

ADMINISTRADORES Y TÉCNICOS .............................................................................. 119

4.3.3. FASE 3: REALIZAR LA CONVERSIÓN DE DATOS Y EL CAMBIO DE

SISTEMA .............................................................................................................................. 120

4.3.4. FASE 4: EFECTUAR UNA EVALUACIÓN LUEGO DE LA INSTALACIÓN

DEL SISTEMA ..................................................................................................................... 120

4.3.5. FASE 5: PRESENTAR UN REPORTE FINAL A LA ADMINISTRACIÓN 120

4.4. CONSTRUCCIÓN ....................................................................................................... 121

4.4.1. MÓDULOS DEL SISTEMA ............................................................................... 121

CAPÍTULO V .................................................................................................................................... 125

5.1. ANÁLISIS DE RIESGOS ............................................................................................ 125

5.1.1. IDENTIFICACIÓN DE RIESGOS .................................................................... 126

vi

5.1.2. IDENTIFICACIÓN DE PROBABILIDAD DE OCURRENCIA .................... 130

5.1.3. SEVERIDAD DE LAS CONSECUENCIAS ..................................................... 130

5.1.4. MATRIZ DE EVALUACIÓN DE RIESGOS ................................................... 130

5.1.5. CATEGORÍA DE IMPORTANCIA DEL RIESGO......................................... 131

5.1.6. EVALUACIÓN DE RIESGOS ........................................................................... 131

5.1.7. RESULTADOS DE ESTIMACIÓN DE RIESGOS .......................................... 136

5.2. EVALUACIÓN DEL SISTEMA ................................................................................ 141

5.2.1. FACTIBILIDAD ECONÓMICA – ANÁLISIS COSTO FINANCIERO ....... 141

5.2.2. FACTIBILIDAD TÉCNICA ............................................................................... 145

5.2.3. FACTIBILIDAD OPERATIVA ......................................................................... 145

5.2.4. FACTIBILIDAD ORGANIZACIONAL ........................................................... 146

5.3. ANÁLISIS E INTERPRETACIÓN DE RESULTADOS ......................................... 147

5.3.1. PRUEBA DE HIPÓTESIS .................................................................................. 147

5.3.2. ANÁLISIS DE FIABILIDAD DEL INSTRUMENTO DE MEDICIÓN ........ 148

5.3.3. PRUEBA CHI CUADRADO PARA LA HIPÓTESIS PRINCIPAL ............. 149

5.3.4. PRUEBA DE HIPÓTESIS PARA LAS HIPÓTESIS ESPECIFICAS ............ 151

5.4. TABLA DE TIEMPOS (ANTES Y DESPUÉS) DE LA IMPLEMENTACIÓN. .. 155

CONCLUSIONES .............................................................................................................................. 158

RECOMENDACIONES ...................................................................................................................... 159

FUENTES BIBLIOGRÁFICAS ............................................................................................................. 160

FUENTES ELECTRÓNICAS ................................................................................................................ 161

ANEXOS .......................................................................................................................................... 162

ANEXO N° 1 Reporte de Generación de Informe de Residuos Sólidos. ................................. 162

ANEXO N° 2 Encuesta para la toma de tiempos antes y después de la implementación web. . 163

ANEXO N° 3 MATRIZ DE CONSISTENCIA ......................................................................... 164

ANEXO N° 4 ENCUESTA ....................................................................................................... 165

ANEXO N° 5 MODELO DE ENTREVISTA ........................................................................... 166

vii

ÍNDICE DE FIGURAS

Figura 1. Actividades de ciclo de vida clásico o en cascada de desarrollo de sistemas. .................. 28

Figura 2. Desarrollo de sistemas por el método en espiral. ............................................................. 30

Figura 3. Arquitectura en tres niveles de un SGBD. ......................................................................... 32

Figura 4 ............................................................................................................................................. 35

Figura 5 ............................................................................................................................................. 36

Figura 6: Historia de RUP.................................................................................................................. 36

Figura 7: Los Casos de Uso integran el trabajo. ............................................................................... 38

Figura 8: Trazabilidad a partir de los Casos de Uso. ......................................................................... 38

Figura 9: Evolución de la arquitectura del sistema. ......................................................................... 40

Figura 11: Una iteración RUP. .......................................................................................................... 42

Figura 12: Esfuerzo en actividades según fase del proyecto. .......................................................... 43

Figura 13: Estructura de RUP. .......................................................................................................... 45

Figura 14: Ciclos, releases, baseline. ................................................................................................ 46

Figura 15: Fases e hitos en RUP ....................................................................................................... 46

Figura 16: Distribución típicas de esfuerzo y tiempo. ...................................................................... 47

Figura 17: Distribución típica de recursos humanos. ....................................................................... 47

Figura 18: Relación entre roles, actividades, artefactos .................................................................. 54

Figura 19: Detalle de un workflow mediante roles, actividades y artefactos .................................. 54

Figura 20: Diagrama de Caso de Uso del Sistema. .......................................................................... 78

Figura 21: Diagrama de Caso de Uso Gestionar punto de Almacenamiento. ................................. 79

Figura 22: Diagrama de Caso de Uso Gestionar Residuos Generados. .......................................... 80

Figura 23: Diagrama de Caso de Uso Gestionar Transporte Interno. ............................................. 81

Figura 24: Diagrama de Caso de Uso Gestionar Disposición Final. .................................................. 82

Figura 25: Diagrama de Caso de Uso Generar Informe de Generación de Residuos. ...................... 84

Figura 26: Diagrama de Clases ......................................................................................................... 86

Figura 27: Arquitectura Web. ........................................................................................................... 88

Figura 28: Modelo Vista Controlador ............................................................................................... 89

Figura 29: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Registrar. ..................... 90

Figura 30: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Editar. .......................... 91

Figura 31: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Listar. ........................... 91

Figura 32: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Eliminar. ...................... 92

Figura 33: Diagrama de Secuencia: Gestionar Residuo Sólido Registrar. ........................................ 92

Figura 34: Diagrama de Secuencia: Gestionar Residuo Sólido Editar. ............................................. 93

Figura 35: Diagrama de Secuencia: Gestionar Residuo Sólido Listar. .............................................. 93

Figura 36: Diagrama de Secuencia: Gestionar Residuo Sólido Eliminar........................................... 94

Figura 37: Diagrama de Secuencia: Registrar Protección Personal. ................................................ 94

Figura 38: Diagrama de Secuencia: Registrar EPS/EC. ..................................................................... 95

Figura 39: Diagrama de Secuencia: Registrar Fuente de Generación. ............................................. 95

Figura 40: Diagrama de Secuencia: Registrar Peligrosidad. ............................................................. 96

Figura 41: Diagrama de Secuencia: Registrar Punto de Almacenamiento. ..................................... 96

file:///D:/Tesis/PLAN_DE_TESIS%20version%202%20%20-%20copia.docx%23_Toc366287882

viii

Figura 42: Diagrama de Secuencia: Registrar Reaprovechamiento. ............................................... 97

Figura 43: Diagrama de Secuencia: Gestionar Transporte Interno Registrar. ................................. 97

Figura 44: Diagrama de Secuencia: Gestionar Transporte Interno Editar. ...................................... 98

Figura 45: Diagrama de Secuencia: Gestionar Transporte Interno Listar. ....................................... 98

Figura 46: Diagrama de Secuencia: Gestionar Transporte Interno Eliminar. ................................... 99

Figura 47: Diagrama de Secuencia: Gestionar Disposición Final Registrar. .................................... 99

Figura 48: Diagrama de Secuencia: Gestionar Disposición Final Editar. ........................................ 100

Figura 49: Diagrama de Secuencia: Gestionar Disposición Final Listar. ......................................... 100

Figura 50: Diagrama de Secuencia: Gestionar Disposición Final Eliminar. ................................... 101

Figura 51: Diagrama de Secuencia: Generar Informe de Generación de Residuos. ...................... 101

Figura 52: Modelo Físico de Datos. ................................................................................................ 102

Figura 53: Pantalla de Punto de Almacenamiento Listar. .............................................................. 110

Figura 54: Pantalla de Punto de Almacenamiento Nuevo / Editar. ............................................... 110

Figura 55: Pantalla de Residuos que Almacena. ............................................................................ 110

Figura 56: Pantalla de Residuos Generados Listar ......................................................................... 111

Figura 57: Pantalla de Residuos Generados Nuevo/Editar (Parte 1). ............................................ 111

Figura 58: Pantalla de Residuos Generados Nuevo/Editar (Parte 2). ............................................ 111

Figura 59: Pantalla de Peligrosidad de Residuo Generado. ........................................................... 112

Figura 60: Pantalla de Fuente de Generación de Residuo Generado. .......................................... 112

Figura 61: Pantalla de Registro de EPS/EC. .................................................................................... 112

Figura 62: Pantalla de registro de Protección Personal. ................................................................ 113

Figura 63: Pantalla de Registro de Almacenamiento. .................................................................... 113

Figura 64: Pantalla de Registro de Disposición Final Interno. ........................................................ 113

Figura 65: Pantalla de Registro de Reaprovechamiento. ............................................................... 114

Figura 66: Pantalla de Transporte Interno Listar. .......................................................................... 114

Figura 67: Pantalla de Transporte Interno Nuevo/ Editar. ............................................................ 115


Figura 69: Pantalla de Ingreso a Almacén Temporal. .................................................................... 115

Figura 70: Pantalla de Disposición Final Listar. .............................................................................. 116

Figura 71: Pantalla de Disposición Final Nuevo/Editar. ................................................................. 116


Figura 73: Pantalla de Filtros del Reporte. ..................................................................................... 117

Figura 74: Pantalla del Reporte en PDF. ......................................................................................... 117

Figura 75: Pantalla del Reporte en Excel. ....................................................................................... 117

Figura 76: Diagrama de Despliegue. .............................................................................................. 118

Figura 77: Integración del Sistema de Residuos Sólidos al Sistema de Gestión Ambiental. .......... 122

ix

ÍNDICE DE TABLAS

Tabla N° 1 Lista de requerimientos funcionales............................................................................... 76

Tabla N° 2: Lista de requerimientos no funcionales. ....................................................................... 77

Tabla N° 3: Lista de Actores del Sistema. ......................................................................................... 77

Tabla N° 4: Listado de Diagrama de Casos de Uso. .......................................................................... 78

Tabla N° 5: Caso de Uso Nº 1. .......................................................................................................... 79





Tabla N° 10: Matriz de Trazabilidad. ................................................................................................ 85

Tabla N° 11: Especificación de Clases del Sistema. .......................................................................... 87

Tabla N° 12: Nomenclatura. ............................................................................................................. 90

Tabla N° 13 Tabla de Residuos Generados ..................................................................................... 103

Tabla N° 14 Tabla de Almacenamiento Final Interno..................................................................... 104

Tabla N° 15 Tabla de Peligrosidad. ................................................................................................. 104

Tabla N° 16 Tabla de Grupo de Residuo. ........................................................................................ 104

Tabla N° 17 Tabla de Fuente de Generación. ................................................................................. 105

Tabla N° 18 Tabla de Protección Personal. .................................................................................... 105

Tabla N° 19 Tabla de Punto Almacenamiento. .............................................................................. 106

Tabla N° 20 Tabla de Residuos Almacenamiento Interno. ............................................................. 106

Tabla N° 21 Tabla de Residuo Generado Almacenamiento. .......................................................... 107

Tabla N° 22 Tabla de Transporte Final. .......................................................................................... 108

Tabla N° 23 Tabla de Transporte Interno Residuo. ........................................................................ 108

Tabla N° 24 Tabla de Transporte Interno. ...................................................................................... 109

Tabla N° 25 Tabla de Transporte Final Residuo. ............................................................................ 109

Tabla N° 26 Identificación de probabilidad de ocurrencia. ............................................................ 130

Tabla N° 27 Severidad de las consecuencias. ................................................................................. 130

Tabla N° 28 Matriz de evaluación de riesgos. ................................................................................ 130

Tabla N° 29 Categoría de importancia del riesgo. ......................................................................... 131

Tabla N° 30: Costo de Plataforma de Hardware. ........................................................................... 141

Tabla N° 31: Costo de Plataforma de Software. ............................................................................. 141

Tabla N° 32: Costo de Recursos Humanos. .................................................................................... 141

Tabla N° 33: Resumen de Costos de Implementación. .................................................................. 142

Tabla N° 34: Cuadro costo por Mantenimiento. ............................................................................ 142

Tabla N° 35: Cuadro de Ingresos por Ahorros. ............................................................................... 142

Tabla N° 36: Cuadro Flujo de Caja Económico. .............................................................................. 143

Tabla N° 37 Resumen del procesamiento de los casos. ................................................................. 148

Tabla N° 38 Estadísticos de fiabilidad. ........................................................................................... 148

Tabla N° 39 Estadísticos total-elemento. ....................................................................................... 149


x

Tabla N° 41 Contingencia Disponibilidad de la Información * Optimo Sistema. ........................... 149

Tabla N° 42 Pruebas de chi-cuadrado. ........................................................................................... 150


Tabla N° 44 Tabla de contingencia Optimo Control * Rapidez de Petición. .................................. 152



Tabla N° 47 Tabla de contingencia Disponibilidad de la Información * Registro Optimo. ............ 153



Tabla N° 50 Tabla de contingencia Tiempo Generación Reporte * Optimo Sistema. .................... 154


xi

RESUMEN

El presente trabajo de investigación consiste en el análisis, diseño e

implementación de un sistema web de Residuos Sólidos basado en la Metodología

Rational Unified Process (RUP) para la compañía de minas Buenaventura S.A.C.

El objetivo de la investigación fue Implementar un Sistema Web basado en la

Metodología RUP. Dicha implementación ayudara a la empresa a optimizar el

control de Residuos Sólidos. El problema, por otro lado surge de la inquietud de la

empresa por hacer un diagnóstico de la situación actual en la que se encuentra, al

considerar inadecuado la forma como se estaba llevando a cabo el control de

residuos sólidos dentro de la organización. La investigación se realizó en base a la

metodología de estudio, obteniendo información de diversas fuentes, como

documentos internos de la empresa, entrevistas, encuestas, observaciones y

revisión bibliográfica. Se analizaron dos variables a lo largo de la investigación, que

son: (i) Sistema Web y (ii) Optimizar el control de los Residuos Sólidos.

Como resultado de la investigación se logró aceptar la hipótesis alternativa

que afirma que: “La Implementación de un Sistema Web basado en la

Metodología RUP permitirá Optimizar el Control de Residuos Sólidos de la

compañía de Minas Buenaventura S.A.C.” por lo que queda comprobada la

Hipótesis General planteada en el presente trabajo de investigación.

Lo anterior favoreció para la formulación de conclusiones, las cuales

pretenden ayudar a optimizar el control de residuos sólidos.

xii

INTRODUCCIÓN

El Perú es un país con importantes inversiones en la minería. Las empresas

mineras deben cumplir con los compromisos, disposiciones legales referentes al

medio ambiente y responsabilidad social que están enmarcas en la Ley General de

residuos sólidos LEY Nº 27314 (Ley General de Residuos Sólidos, 2008).

Durante muchos años la minería ha enfrentado una serie de conflictos sociales

conocidos por todos nosotros, estos conflictos sociales han ocasionado pérdidas

materiales, perdidas económicas y hasta pérdida de vidas humanas (Diario El

Comercio, 2012).

Se ha detectado que gran parte de estos conflictos es ocasionado por el temor al

daño ambiental, como lo menciona el reporte de la defensoría del pueblo del año

2012. Donde se encontró 238 conflictos sociales, de los cuales 149 están

relacionados al sector minero que representan el 62 % de todos los conflictos

ocurridos. Y para enero del 2013 de los 147 conflictos socio ambientales registrados

durante este mes el 72,8% (107 casos) corresponde a conflictos relacionados a la

actividad minera, le siguen los conflictos por actividades hidrocarburíferas con

14,3% (21 casos) (DEFENSORÍA DEL PUEBLO, 2013).

La implementación de nuevas tecnologías de información generaría un mejor

control de los residuos sólidos, que aliviarían sustancialmente los problemas

latentes en área de medio ambiente de la Compañía de Minas Buenaventura S.A.C.

obteniendo información oportuna y consistente para la toma de decisiones.

Sistema Web de Residuos Solidos

13

CAPÍTULO I

PLANTEAMIENTO DEL PROBLEMA

1.1. DESCRIPCIÓN DE LA REALIDAD PROBLEMÁTICA

Hacia el final de los 1990’s las computadoras ya no eran herramientas sólo

para especialistas técnicos; ellas se convirtieron en parte integral del ambiente

de trabajo usadas por las personas a todo nivel de la organización. Debido al

extendido rol de las computadoras, las organizaciones tenían más información

disponible que antes y los procesos organizacionales fueron cada vez más

facilitados por la tecnología computacional. Los problemas de administrar la

información se convirtieron extremadamente complejos, y los desafíos de hacer

un uso adecuado de la información y la tecnología a fin de apoyar la eficiencia

y eficacia organizacional se volvieron aspectos cruciales. Debido a estos

factores, los desafíos enfrentados por los especialistas en Sistemas de

Información crecieron en tamaño, complejidad, e importancia. Adicionalmente,

los Sistemas de Información como un campo prestaron creciente atención al


14

uso de las tecnologías de computación como un medio para la comunicación y

la toma de decisiones colaborativas en las organizaciones. (The Association for

Computing (ACM), 2005)

En un mercado global, el reto que enfrenta toda organización, por el cambio

profundo de su entorno es hacerse competitiva, para lo cual tiene que adoptar

un nuevo patrón tecnológico. Este patrón tecnológico que impera a nivel

mundial se compone de dos vertientes, la microelectrónica y la

informatización. La siendo la ultima una organización flexible y horizontal,

abierta e interconectada con base en la información.

La compañía minera Buenaventura S.A.C. lleva trabajando más de 60 años

en el país en la explotación, tratamiento y exploración de minerales de todo

tipo, y como toda actividad humana produce residuos sólidos entre otros, que

pueden ser perjudiciales para el medio ambiente y el entorno que los rodea.

Durante años el control de tales residuos ha sido llevado a cabo de manera

manual por los empleados, utilizando muchos recursos en el proceso.

Eso sucede porque la compañía minera Buenaventura no cuenta con un

sistema de información para el control de residuos sólidos, considerando que

control según la Real academia española (REA) se refiere a la regulación,

manual o automática, sobre un sistema. Esto ocasiona que aquellos usuarios

que forman parte del proceso ambiental y que se encuentran monitoreando los

residuos que se genera, tengan que apersonarse físicamente al establecimiento

de cada unidad minera para recibir las fichas técnicas que luego serán

completadas de manera manual y procesadas posteriormente para la emisión de

los reportes a las autoridades pertinentes. Realizándose este proceso de manera


15

periódica.

Esta situación genera incertidumbre dentro y fuera de la organización,

trayendo consigo pérdidas de tiempo en la recolección de la información e

incluso económicas por multas y penalizaciones impuestas por las autoridades

reguladoras como el Organismo Supervisor de la Inversión en Energía y

Minería (OSINERGMIN) según lo dispuesto por el Artículo 1º de la Ley Nº

27699 –Ley Complementaria de Fortalecimiento Institucional de

OSINERGMIN.

En la actualidad se requiere el uso de tecnologías de información para ser

competitivos. La implementación de un Sistema de Información para el control

de residuos sólidos es imperante en un mercado globalizado y de un constante

cambio.

Entre los beneficios más resaltantes de este tipo de soluciones tecnológicas

es la agilidad en la toma de decisiones basada en información actualizada y

mayor rapidez en el proceso de la emisión de reportes.

1.2. FORMULACIÓN DE PROBLEMA

1.2.1. PROBLEMA GENERAL

¿En qué medida la Implementación de un Sistema Web

basado en la Metodología Rational Unified Process permitirá

Optimizar el Control de Residuos Sólidos de la Compañía de

Minas Buenaventura S.A.C. - Lima?


16

1.2.2. PROBLEMA ESPECÍFICO

¿En qué medida la determinación del nivel de Control de

los Residuos Sólidos permitirá conocer la situación actual

de la Compañía de Minas Buenaventura S.A.C. - Lima?

¿En qué medida el Diseño y Desarrollo de un Sistema Web

basado en la Metodología Rational Unified Process

permitirá Optimizar el Control Residuos Sólidos de la

Compañía de Minas Buenaventura S.A.C. - Lima?

¿En qué medida la Evaluación del Sistema Web de

Residuos Sólidos permitirá conocer la Optimización del

Control de la Compañía de Minas Buenaventura S.A.C. -

Lima?

1.3. OBJETIVO DE LA INVESTIGACIÓN

1.3.1. OBJETIVO GENERAL

Implementar un Sistema Web basado en la Metodología

Rational Unified Process para Optimizar el Control de

Residuos Sólidos de la Compañía de Minas Buenaventura

S.A.C. – Lima.

1.3.2. OBJETIVO ESPECÍFICOS

Determinar el nivel de Control de los Residuos Sólidos que

permita conocer la situación actual de la Compañía de

Minas Buenaventura S.A.C. – Lima.


17

Diseñar y Desarrollar un Sistema Web basado en la

Metodología Rational Unified Process que permita

Optimizar el Control de Residuos Sólidos de la Compañía

de Minas Buenaventura S.A.C.

Evaluar el Sistema Web de Residuos Sólidos que permita

conocer la Optimización del Control de la Compañía de

Minas Buenaventura S.A.C.

1.4. JUSTIFICACIÓN DE LA INVESTIGACIÓN

1.4.1. JUSTIFICACIÓN TEÓRICA

Esta investigación se basa en la teoría y conceptos de

control y manejo de residuos sólidos. La generación de residuos

y la necesidad de su adecuada gestión, constituyen uno de los

retos ambientales más relevantes de las sociedades modernas. Se

trata de un problema que debe ser considerado de forma íntegra,

por el creciente volumen y por la diversidad de tipos de residuos

y procesos donde se producen. (Ferrando, 2007).

Por otra parte este trabajo de investigación está basado en el

modelo de Gestión Ambiental que propone la norma

internacional ISO 14001 que se estructura en cinco grandes

módulos (Políticas Ambientales, Planificación, Implementación

y operación, Verificación y por ultimo Revisión por la

dirección). Esta norma tiene el propósito de apoyar la


18

aplicación de un plan de manejo ambiental en cualquier

organización del sector público o privado. Fue creada por la

Organización Internacional para Normalización (International

Organization for Standardization - ISO), una red internacional

de institutos de normas nacionales que trabajan en alianza con

los gobiernos, la industria y representantes de los consumidores.

((FAO), 2012)

Conocimientos en análisis, diseño e implementación de

sistemas de información (Fernadez, 2005), calidad de software,

seguridad de la información, Tecnología web, etc.

El Sistema se Desarrollará con el patrón arquitectónico

MVC (Modelo, Vista y Controlador) teniendo como base

conceptos de la Programación Orientada a Objetos (POO) y

finalmente uso del Lenguaje Unificado de Modelamiento

(UML).

1.4.2. JUSTIFICACIÓN PRÁCTICA

El Perú es un país con importantes inversiones en la minería.

Las empresas mineras deben cumplir con los compromisos,

disposiciones legales referentes al medio ambiente y

responsabilidad social que están enmarcas en la Ley General de

residuos sólidos LEY Nº 27314 (Ley General de Residuos

Sólidos, 2008).


19

Durante muchos años la minería ha enfrentado una serie de

conflictos sociales conocidos por todos nosotros, estos

conflictos sociales han ocasionado pérdidas materiales, perdidas

económicas y hasta pérdida de vidas humanas. (Diario El

Comercio, 2012).

Se ha detectado que gran parte de estos conflictos es

ocasionado por el temor al daño ambiental, como lo menciona

el reporte de defensoría del pueblo del año 2012. Donde se

encontró 238 conflictos sociales de los cuales 149 están

relacionados al sector minero que representan el 62 % de todos

los conflictos ocurridos. Y para enero del 2013 de los 147

conflictos socio ambientales registrados durante este mes el

72,8% (107 casos) corresponde a conflictos relacionados a la

actividad minera; le siguen los conflictos por actividades

hidrocarburíferas con 14,3% (21 casos) (DEFENSORÍA DEL

PUEBLO, 2013).

La presente investigación tiene por finalidad la

implementación de un sistema web con el propósito de

optimizar el control de los residuos sólidos y disponibilidad de

la información que ayude a la toma de decisiones oportuna.


20

CAPÍTULO II

MARCO TEORICO

2.1. ANTECEDENTES DE LA INVESTIGACIÓN

La generación de residuos está ligada al modelo de desarrollo actual de la

sociedad y constituye uno de los principales problemas ambientales a los que

se enfrenta el mundo. Los diferentes indicadores medio ambientales reflejan

una realidad: cada vez se generan más residuos.

Es importante mencionar que todos los recursos disponibles en el mercado

se convertirán en residuos en algún momento y todas las actividades

productivas generan una forma de residuos. Algunos impactos ambientales

fácilmente identificables debido a la generación de residuos son: la ocupación

de terrenos, el impacto visual debido a la alteración paisajística o los malos

olores. Sin embargo, existen muchos otros impactos de los que gran parte de la

sociedad no es consciente de su recuperación, ni se preocupa por sus

consecuencias, entre dichos impactos destacan los efectos sobre el medio

natural: degradación, contaminación de aguas superficiales y acuíferos,


21

contaminación atmosférica, etc.

Desde la década de los 70, aparecen los primeros informes y

estudios que alertan de las incompatibilidades existentes entre modelos de

desarrollo y la preservación de los recursos naturales.

Es destacable en el año 1872, en el que publicaciones como “A Blue

print for Suvival” (Manifiesto por la supervivencia) publicada por la revista

“The Ecologist”, o el informe al Club de Roma “The Limits to growth” (Los

límites al crecimiento) ven la luz provocando un gran impacto social.

Dichas publicaciones plantean argumentos interesantes:

Un modelo de crecimiento indefinido, no puede ser sustentado por una serie de

recursos finitos (“A Blue print for Survival”).

Si las tendencias en la población mundial, industrialización, contaminación,

producción de alimentos, agotamiento de recursos, continúan sin cambios, los

límites al crecimiento en este planeta serian alcanzados aproximadamente en

los próximos 100 años. El resultado más probable sería una rápida e

incontrolada reducción en la población y capital industrial (“The Limits to

growth”).

Es posible alterar estas tendencias al crecimiento y establecer una condición de

estabilidad económica y ecológica que sea sostenible en el futuro. El estado de

equilibrio global podría ser diseñado de formas que las necesidades materiales

básicas de cada persona sobre la tierra sean satisfechas con igualdad de

oportunidades para realizar el potencial humano de sus individuos (“The Limits

to growth”).


22

A pesar de que estos informes se equivocaron en muchas de sus

predicciones, la línea general de su planteamiento era muy válida y suscito una

gran controversia y una visión por parte de los gobiernos y las instituciones

internacionales.

Las ideas que se consolidan en los comienzos de los años 70, continúan su

evolución y se concretan en varios aspectos importantes defendidos hoy en día

con carácter general entre los que destacan el referido sostenibilidad o

sustentabilidad del desarrollo.

A un que el informe del Club Roma ya se ha hablado de sostenibilidad, la

primera vez que toma carta de naturaleza oficial, es en 1980 en la llamada

“Estrategia de conservación mundial”, realizada por la Unión Internacional por

la conservación de la Naturaleza (IUCN), el Fondo Mundial para la Naturaleza

(WWF) y el Programa de las Naciones Unidas para el Medio Ambiente

(UNEP).

La definición del concepto más utilizado surge del documento elaborado en

1987 por la comisión Mundial de Naciones Unidas sobre Medio Ambiente y

Desarrollo (UNCED) conocido como informe BRUNDTLAND que lleva como

título “Nuestro Futuro Común”.

Según dicho documento, desarrollo sostenible es “el desarrollo que satisface

las necesidades actuales sin comprometer la capacidad de las generaciones

futuras de satisfacer las suyas”.


23

El concepto de desarrollo sostenible será, por tanto, el pilar sobre el que se

desarrollaran las políticas medioambientales en relación con la utilización de

los recursos naturales y los residuos.

2.2. BASES TEÓRICAS

2.2.1. SISTEMA WEB

2.2.1.1. LA INFORMACIÓN

Los recursos básicos de una organización han sido cambiados a lo

largo de los años, así la información y el conocimiento han llegado a

ser, en nuestros días, recursos estratégicos tan valiosos como lo fueron

en la era industrial, el capital y el trabajo.

2.2.1.2. LOS SISTEMAS DE INFORMACIÓN

Antes de comenzar con una detallada descripción del

funcionamiento de los sistemas de información, analizaremos primero

el término sistema. Un sistema es un conjunto de elementos que

interaccionan entre si de una manera ordenada, para lograr un objetivo

común. (Gonzáles., 2005).

De esta forma un Sistema de Información (SI) se define como un

sistema capaz de recoger, almacenar y procesar datos para, después de

un análisis, obtener información útil y necesaria para la organización en

la que está inmerso. (A., 1993).

Un Sistema de Información comprende toda la cadena de operación


24

que empieza en la observación y recolección de datos, pasando por su

almacenamiento y análisis, hasta el uso efectivo de la información

derivada en un proceso de toma de decisiones. (Pet, 2002).

2.2.1.3. TIPOS DE SISTEMAS DE INFORMACIÓN

2.2.1.3.1. Sistema de procesamiento transacciones (TPS):

Una transacción es cualquier suceso o actividad que afecta a toda la

organización como por ejemplo puede ser una reserva, hacer un pedido,

gestionar una entrega de una mercadería, realizar un inventario, etc.

Dado que estos sucesos ocurren un número elevado al día, aportan

un gran volumen de información que debe ser manejado por los

empleados de nivel operacional. Son datos rápidamente alterables pero

muy poco variables, lo que hace que los procedimientos para

gestionarlos puedan ser descritos con precisión. (Gonzáles., 2005)

Son estas características hicieron que fuera posible diseñar e

implementar rutinas que se encargasen de estos trabajos repetitivos, lo

que dio lugar a este tipo de sistemas. De esta manera las TPS

sustituyeron las tareas rutinarias administrativas como cálculo,

clasificación, ordenamiento, etc. Que se efectuaban anteriormente de

manera manual.

2.2.1.3.2. Sistema de información administrativa o gerencial (MIS):

Proporciona información para los procesos de decisión

administrativas. Son procesos que se presentan de manera regular y

necesitan de cierta información de soporte, basada en los datos

almacenados como consecuencia del procesamiento de transacciones.


25

(Gonzáles., 2005)

Se trata de situaciones de decisión bien estructuradas: se sabe

cuándo se va plantear esa situación y la información que se necesita

para tomar la decisión es fácilmente identificable. Como ha de

presentarse la información con cierta regularidad, los MIS generan

informes de manera periódica, con un formato prediseñado y un

contenido establecido con anterioridad, en función de las necesidades

de la información requerida por los directivos.

2.2.1.3.3. Sistemas de apoyo a la toma de decisión (DSS):

También son conocidos como Sistemas para el soporte de

Decisiones. Proporcionan información a los representantes de la

organización para apoyar a la toma de decisiones sobre situaciones

particulares de naturaleza no recurrente. Este tipo de decisiones se

denomina no estructurada y queda caracterizada por que “no existe

procedimientos claros para tomarla y tampoco es posible identificar con

anticipación todos los factores que deben de considerarse en la

decisión” (J.A., 1992).

Los DSS son por lo tanto sistemas con una flexibilidad mayor que

los anteriores, porque la información que han de presentar no se conoce

previamente y puede ir variando a medida que la situación va

avanzando. Son sistemas altamente interactivos que utilizan gráficos y

diagramas para ayudar a visualizar las consecuencias de las decisiones

tomadas. Una extensión de los DSS son los sistemas de Inteligencia

Artificial, tan bien denominados sistemas basados en conocimientos o

sistemas expertos. Suelen ser utilizados para resolver aquellos


26

problemas que no tienen solución algorítmica y que deben ser

resueltos mediante la intuición y experiencia de un especialista.

2.2.1.3.4. Sistema de información ejecutivos (ERP):

Estos sistemas dan soporte a las decisiones que debe tomar el nivel

ejecutivo, decisiones estratégicas, que suelen ser de largo alcance, no

rutinarias, complejas, no estructuradas y críticas para la supervivencia

de la empresa. La información que muestran estos sistemas no se centra

en detalles, si no que se presenta de manera consolidad y resumida en

niveles muy generales.

Se han mencionado distintos tipos de sistemas de información, cada

uno dando soporte a las necesidades de cada sector de la organización,

la tendencia actual en las grandes empresas es unificar los sistemas de

todos los departamentos en un único sistema, son los denominados ERP

que por sus siglas en inglés (Enterprise Resource Planning),

Planificación de recursos empresariales, Facilitando la comunicación la

comunicación entre departamentos al compartir por completo la

información, pudiéndose conocer el estado de un determinado dato

desde cualquier punto de la empresa a lo largo de todo el proceso de

transformación que sufre desde su entrada hasta su salida. Con estos

sistemas se evita la duplicidad de los datos y la posible inconsistencia

de la información derivada de los errores que pueden producirse al

trabajar desde distintos sistemas (base de datos diferentes) con la misma

información.

Los ERP ofrecen en forma de módulos una solución para cada

organización; si bien su implementación es costosa (en tiempo y dinero)


27

y exige en mayor grado que en las demás SI un cambio en la manera de

trabajar de los empleados, presentando beneficios en todas las áreas de

la organización.

2.2.1.4. DESARROLLO DE SISTEMAS DE INFORMACIÓN

El éxito de la integración de un SI en una organización depende en

gran manera de que el trabajo de construcción e implementación del

mismo este planificado inteligentemente. El desarrollo de sistemas

comprende en análisis y diseño de los mismos. El análisis es el proceso

que determina que es lo que el sistema debe de hacer; engloba las tareas

de investigación del funcionamiento de la organización, el diagnostico

de problemas y la presentación de posibles mejoras del sistema. El

diseño establece como han de realizarse los procedimientos para que el

sistema cumpla con su objetivo. Todo este proceso ha de llevarse a cabo

siguiendo unas pautas. El ciclo de vida tiene como propósito plantear,

ejecutar y controlar las distintas etapas y acciones necesarias en el

desarrollo de sistemas. Existen diversos modelos de ciclo de vida, es

decir, diferentes maneras de ver el proceso de desarrollo de los SI. En

esta sección se verán cuatro de ellos como:

2.2.1.4.1. Ciclo de vida clásico o en cascada:

Esta estrategia suele utilizarse cuando el sistema no es de gran

complejidad y puede ser manejable como proyecto, cuando los

requerimientos del sistema pueden predecirse fácilmente. Consiste en

una sucesión de etapas en cadena o cascada por las que pasa el sistema


28

de información desde que es concebido hasta que comienza a usarse,

que se puede visualizar a continuación.

Figura 1. Actividades de ciclo de vida clásico o en cascada de desarrollo de

sistemas.

2.2.1.4.2. Análisis estructurado:

Este método trata de superar el problema que surge al intentar

comprender de manera genérica un sistema complejo y demasiado

grande. En estas condiciones la solución pasa por dividir el sistema en

subsistemas más o menos independientes, denominados componentes

de forma que el conjunto de todos ellos formen un modelo de nuestro

sistema.

El modelo del desarrollo por análisis estructurado incorpora

elementos tanto de análisis como de diseño. El análisis estructurado se

encarga de concretar que hará la aplicación sin pararse a establecer

como se realizará. Se describe el sistema concentrándose en los

elementos lógicos involucrados (datos, procesos), sin referirse a la parte

física que pueda ser necesaria (hardware, comunicaciones, personal),


29

para realizar esta descripción, el analista se sirve de distintos elementos,

como son la descripción gráfica, los diagramas de flujo y el diccionario

de datos.

2.2.1.4.3. Método de prototipos:

El prototipo debe ser construido en poco tiempo, usando los

programas adecuados y no se debe utilizar muchos recursos.

El diseño rápido se centra en una representación de aquellos

aspectos del software que serán visibles para el cliente o el usuario

final. Este diseño conduce a la construcción de un prototipo, el cual es

evaluado por el cliente para una retroalimentación; gracias a ésta se

refinan los requisitos del software que se desarrollará. La interacción

ocurre cuando el prototipo se ajusta para satisfacer las necesidades del

cliente. Esto permite que al mismo tiempo el desarrollador entienda

mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

2.2.1.4.4. Modelo en espiral:

Combina las principales ventajas del modelo de ciclo de vida clásico

y las del modelo de construcción de prototipos, añadiendo un nuevo

elemento: el análisis de riesgo. Este modelo puede describirse tal y

como se muestra en la siguiente figura; se entiende el camino seguido

en el desarrollo del sistema como una espiral, construida por distintos

ciclos, que atraviesan a medida que va avanzando el desarrollo, las

cuatro actividades principales de este método: planificación, análisis de

riesgo, ingeniería y evaluación del cliente.


30

Figura 2. Desarrollo de sistemas por el método en espiral.

2.2.1.5. MODELO DE DATOS:

En cualquier sistema de información se emplea grandes cantidades

de recursos para la recolección, clasificación, procesamiento e

intercambio de datos mediante procedimientos preestablecidos para la

obtención de objetos específicos.

Para resolver estos problemas y trabajar de manera más eficiente

surgieron las bases de datos y sistemas de gestión de base de datos

(SGDBs).

Un conjunto de datos estructurados según cierto esquema de una

base de datos, el lenguaje de definición de esquemas y el lenguaje de

manipulación de datos (consultas y actualizaciones) forma el sistema de

gestión de base de datos.

Dentro del campo de la computación, una base de datos es un

conjunto de datos y sus relaciones, almacenados con la mínima

redundancia y de forma que se pueda acceder a ellos eficientemente por


31

parte de varias aplicaciones y usuarios, un sistema de gestión de base

de datos (SGDB) es una aplicación que permite a los usuarios definir,

crear y mantener la base de datos, proporcionando acceso controlado a

la misma. La definición consiste en especificar los tipos de datos, las

estructuras y las restricciones para los datos que se van a almacenar. La

creación es el proceso de almacenamiento de los datos concretos sobre

algún medio de almacenamiento controlado por el SGDB. El

mantenimiento incluye funciones tales como consultar la base de datos

para recuperar datos específicos, actualizar la base o generar informes a

partir de los datos.

La utilización de estos SGDBs presenta una serie de ventajas:

Capacidad: no se van a duplicar ficheros.

Rapidez: al utilizar estructuras ordenadas y bien diseñadas.

Facilidad de trabajo: reusabilidad de los datos.

Actualización: al no estar duplicados se puede actualizar con

facilidad.

Menor redundancia.

Eliminación de inconsistencias.

Compartición de ficheros.

Seguridad y chequeo de errores.

Aunque también tiene sus inconvenientes:

Mayor complejidad.

Mayor tamaño.

Mayor coste.


32

Mayor vulnerabilidad a fallos.

2.2.1.6. ESTRUCTURA DE BASE DE DATOS

Hay tres características importantes relacionadas al enfoque de las

bases de datos: la separación entre los programas y los datos que se

puede denominar como abstracción de datos, el empleo de un catálogo

para almacenar el esquema de la base de datos y el soporte de múltiples

vistas de usuarios.

El esquema propuesta por el grupo ANSI/SPARC (American

National Standard Institute/ System Planning and Requeriment

Committee) en 1975 es una arquitectura en tres niveles (Figura 4.3)

que ayuda a conseguir estas tres características.

Figura 3. Arquitectura en tres niveles de un SGBD.

2.2.1.7. TIPOS DE MODELOS DE BASES DE DATOS

Modelo de Tabla: Su definición puede no responder estrictamente a un

modelo; consiste de una lista de datos de dos dimensiones, en la cual

http://definicion.de/lista/


33

todos los elementos de una columna determinada son similares y todos

los valores de una fila tienen relación entre sí.

Modelo Jerárquico: La información se organiza en una estructura de

tipo árbol, anidados de forma que cada elemento pueda ramificarse en

muchos otros, que deberán poder ordenarse de alguna forma.

Modelo de Red: Estructura la información utilizando dos

construcciones fundamentales, llamadas récords (registros) y sets

(conjuntos); los primeros contienen campos y los últimos definen

relaciones entre los registros de uno a muchos (ejemplo: un cliente,

muchos productos comprados).

Esquema de Estrella: Consta generalmente de una tabla principal, a la

se asocian muchas otras. Un ejemplo común es almacenar los datos de

un paciente en una tabla, que a la vez se relacionará con otra donde

consten todas sus consultas, y con otra en la que se registran sus

reclamos o sus cambios de planes de cobertura, y así sucesivamente.

2.2.1.8. MODELO DE DATOS ENTIDAD- RELACION (E/R)

Cuando se utiliza una base de datos para gestionar información, se

está plasmando una parte del mundo real en una serie de tablas,

registros y campos ubicados en un ordenador; creándose un modelo

parcial de la realidad. Antes de crear físicamente estas tablas en el

ordenador se debe realizar un modelo de datos.

Se suele cometer el error de ir creando nuevas tablas a medida que

se van necesitando, haciendo así el modelo de datos y la construcción

http://definicion.de/red/

http://definicion.de/tabla/


34

física de las tablas simultáneamente. El resultado de esto acaba siendo

un sistema de información parcheado, con datos dispersos que terminan

por no cumplir adecuadamente los requisitos necesarios.

Entidades y Relaciones

El modelo de datos más extendido es el denominado

ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una

situación real a partir de la cual se definen entidades y relaciones entre

dichas entidades:

Entidad.- Objeto del mundo real sobre el que queremos almacenar

información (Ej: una persona). Las entidades están compuestas

de atributos que son los datos que definen el objeto (para la entidad

persona serían DNI, nombre, apellidos, dirección,...). De entre los

atributos habrá uno o un conjunto de ellos que no se repite; a este

atributo o conjunto de atributos se le llama clave de la entidad, (para la

entidad persona una clave seria DNI). En toda entidad siempre hay al

menos una clave que en el peor de los casos estará formada por todos

los atributos de la tabla. Ya que pueden haber varias claves y

necesitamos elegir una, lo haremos atendiendo a estas normas:

Que sea única.

Que se tenga pleno conocimiento de ella.- ¿Por qué en las

empresas se asigna a cada cliente un número de cliente?

Que sea mínima, ya que será muy utilizada por el gestor de base de

datos.


35

Relación.- Asociación entre entidades, sin existencia propia en el

mundo real que estamos modelando, pero necesaria para reflejar las

interacciones existentes entre entidades. Las relaciones pueden ser de

tres tipos:

Relaciones 1-1.- Las entidades que intervienen en la relación se

asocian una a una (Ejemplo: la entidad HOMBRE, la entidad MUJER y

entre ellos la relación MATRIMONIO).

Relaciones 1-n.- Una ocurrencia de una entidad está asociada con

muchas (n) de otra (Ejemplo: la entidad EMPERSA, la entidad

TRABAJADOR y entre ellos la relación TRABAJAR-EN).

Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades

de la relación, puede estar asociada con muchas (n) de la otra y

viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos

la relación MATRÍCULA).

Representación gráfica de Entidades y Relaciones

Para asimilar fácilmente un diseño de datos cuando se emplea el

modelo E/R se utilizan los siguientes elementos gráficos:

Figura 4


36

La utilización de estos elementos dará como resultado lo que se

denomina el esquema entidad-relación de la base de datos. Los

ejemplos que se incluyen en el apartado anterior, gráficamente

quedarían como sigue:

Figura 5

2.2.2. METODOLOGÍA RATIONAL UNIFIED PROCESS

2.2.2.1. HISTORIA

La Figura 6 ilustra la historia de RUP. El antecedente más

importante se ubica en 1967 con la Metodología Ericsson (Ericsson

Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo

basada en componentes, que introdujo el concepto de Caso de Uso.

Figura 6: Historia de RUP.


37

Posteriormente en 1995 Rational Software Corporation adquiere

Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory

Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational

(Rational Approach) adoptando UML como lenguaje de modelado.

Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y

James Rumbaugh, Rational Software desarrolló e incorporó diversos

elementos para expandir ROP, destacándose especialmente el flujo de

trabajo conocido como modelado del negocio. En junio del 1998 se

lanza Rational Unified Process.

2.2.2.2. CARACTERÍSTICAS ESENCIALES

Los autores de RUP destacan que el proceso de software propuesto

por RUP tiene tres características esenciales: está dirigido por los Casos

de Uso, está centrado en la arquitectura, y es iterativo e incremental.

2.2.2.2.1. Proceso dirigido por casos de uso

Según (Kruchten P. , 2000), los Casos de Uso son una técnica de

captura de requisitos que fuerza a pensar en términos de importancia

para el usuario y no sólo en términos de funciones que sería bueno

contemplar. Se define un Caso de Uso como un fragmento de

funcionalidad del sistema que proporciona al usuario un valor añadido.

Los Casos de Uso representan los requisitos funcionales del sistema.

En RUP los Casos de Uso no son sólo una herramienta para

especificar los requisitos del sistema. También guían su diseño,

implementación y prueba. Los Casos de Uso constituyen un elemento


38

integrador y una guía del trabajo como se muestra en la Figura 2.

Figura 7: Los Casos de Uso integran el trabajo.

Los Casos de Uso no sólo inician el proceso de desarrollo sino que

proporcionan un hilo conductor, permitiendo establecer trazabilidad

entre los artefactos que son generados en las diferentes actividades del

proceso de desarrollo.

Como se muestra en la Figura 8, basándose en los Casos de Uso se

crean los modelos de análisis y diseño, luego la implementación que los

lleva a cabo, y se verifica que efectivamente el producto implemente

adecuadamente cada Caso de Uso. Todos los modelos deben estar

sincronizados con el modelo de Casos de Uso.

Figura 8: Trazabilidad a partir de los Casos de Uso.


39

2.2.2.2.2. Proceso centrado en la arquitectura:

La arquitectura de un sistema es la organización o estructura de sus

partes más relevantes, lo que permite tener una visión común entre

todos los involucrados (desarrolladores y usuarios) y una perspectiva

clara del sistema completo, necesaria para controlar el desarrollo

(Kruchten P. , 2000).

La arquitectura involucra los aspectos estáticos y dinámicos más

significativos del sistema, está relacionada con la toma de decisiones

que indican cómo tiene que ser construido el sistema y ayuda a

determinar en qué orden. Además la definición de la arquitectura debe

tomar en consideración elementos de calidad del sistema, rendimiento,

reutilización y capacidad de evolución por lo que debe ser flexible

durante todo el proceso de desarrollo. La arquitectura se ve influenciada

por la plataforma software, sistema operativo, gestor de bases de datos,

protocolos, consideraciones de desarrollo como sistemas heredados.

Muchas de estas restricciones constituyen requisitos no funcionales

del sistema.

En el caso de RUP además de utilizar los Casos de Uso para guiar el

proceso se presta especial atención al establecimiento temprano de una

buena arquitectura que no se vea fuertemente impactada ante cambios

posteriores durante la construcción y el mantenimiento.

Cada producto tiene tanto una función como una forma. La función

corresponde a la funcionalidad reflejada en los Casos de Uso y la forma


40

la proporciona la arquitectura. Existe una interacción entre los Casos de

Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura

cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de

todos los Casos de Uso requeridos, actualmente y en el futuro. Esto

provoca que tanto arquitectura como Casos de Uso deban evolucionar

en paralelo durante todo el proceso de desarrollo de software.

En la Figura 9 se ilustra la evolución de la arquitectura durante las

fases de RUP. Se tiene una arquitectura más robusta en las fases finales

del proyecto. En las fases iniciales lo que se hace es ir consolidando la

arquitectura por medio de baselines y se va modificando dependiendo

de las necesidades del proyecto.

Figura 9: Evolución de la arquitectura del sistema.

Es conveniente ver el sistema desde diferentes perspectivas para

comprender mejor el diseño por lo que la arquitectura se representa

mediante varias vistas que se centran en aspectos concretos del sistema,

abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el

llamado modelo 4+1 de la arquitectura (Kruchten P. A., 1995), el cual

recibe este nombre porque lo forman las vistas lógica, de

implementación, de proceso y de despliegue, más la de Casos de Uso

que es la que da cohesión a todas.

Architecture

Inception Elaboration Construction Transition

tiempo

ArchitectureArchitecture


tiempo


41

Al final de la fase de elaboración se obtiene una baseline de la

arquitectura donde fueron seleccionados una serie de Casos de Uso

arquitectónicamente relevantes (aquellos que ayudan a mitigar los

riesgos más importantes, aquellos que son los más importantes para el

usuario y aquellos que cubran las funcionalidades significativas)

Durante la construcción los diversos modelos van desarrollándose

hasta completarse. La descripción de la arquitectura sin embargo, no

debería cambiar significativamente (abajo a la derecha) debido a que la

mayor parte de la arquitectura se decidió durante la elaboración. Se

incorporan pocos cambios a la arquitectura (indicados con mayor

densidad de puntos en la figura inferior derecha) (Jacaboson, 2000).

2.2.2.2.3. Proceso iterativo e incremental:

Según (Jacaboson, 2000) el equilibrio correcto entre los Casos de

Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la

función en el desarrollo del producto, lo cual se consigue con el tiempo.

Para esto, la estrategia que se propone en RUP es tener un proceso

iterativo e incremental en donde el trabajo se divide en partes más

pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos

de Uso y arquitectura se vaya logrando durante cada mini proyecto, así

durante todo el proceso de desarrollo. Cada mini proyecto se puede ver

como una iteración (un recorrido más o menos completo a lo largo de

todos los flujos de trabajo fundamentales) del cual se obtiene un

incremento que produce un crecimiento en el producto.

Una iteración puede realizarse por medio de una cascada como se


42

muestra en la Figura 11. Se pasa por los flujos fundamentales

(Requisitos, Análisis, Diseño, Implementación y Pruebas), también

existe una planificación de la iteración, un análisis de la iteración y

algunas actividades específicas de la iteración. Al finalizar se realiza

una integración de los resultados con lo obtenido de las iteraciones

anteriores.

Figura 10: Una iteración RUP.

El proceso iterativo e incremental consta de una secuencia de

iteraciones. Cada iteración aborda una parte de la funcionalidad total,

pasando por todos los flujos de trabajo relevantes y refinando la

arquitectura. Cada iteración se analiza cuando termina. Se puede

determinar si han aparecido nuevos requisitos o han cambiado los

existentes, afectando a las iteraciones siguientes. Durante la

planificación de los detalles de la siguiente iteración, el equipo también

examina cómo afectarán los riesgos que aún quedan al trabajo en curso.

Toda la retroalimentación de la iteración pasada permite reajustar

los objetivos para las siguientes iteraciones. Se continúa con esta

dinámica hasta que se haya finalizado por completo con la versión


43

actual del producto.

RUP divide el proceso en cuatro fases, dentro de las cuales se

realizan varias iteraciones en número variable según el proyecto y en

las que se hace un mayor o menor hincapié en los distintas actividades.

En la Figura 12 se muestra cómo varía el esfuerzo asociado a las

disciplinas según la fase en la que se encuentre el proyecto RUP.

Figura 11: Esfuerzo en actividades según fase del proyecto.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se

enfocan hacia la comprensión del problema y la tecnología, la

delimitación del ámbito del proyecto, la eliminación de los riesgos

críticos, y al establecimiento de una baseline de la arquitectura.

Durante la fase de inicio las iteraciones hacen ponen mayor énfasis


44

en actividades modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de

la baseline de la arquitectura, abarcan más los flujos de trabajo de

requerimientos, modelo de negocios (refinamiento), análisis, diseño y

una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del

producto por medio de una serie de iteraciones.

Para cada iteración se selecciona algunos Casos de Uso, se refina su

análisis y diseño y se procede a su implementación y pruebas. Se realiza

una pequeña cascada para cada ciclo. Se realizan tantas iteraciones

hasta que se termine la implementación de la nueva versión del

producto.

En la fase de transición se pretende garantizar que se tiene un

producto preparado para su entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las

disciplinas, pero que dependiendo de la fase el esfuerzo dedicado a una

disciplina varía.

2.2.2.3. ESTRUCTURA DEL PROCESO

El proceso puede ser descrito en dos dimensiones o ejes (Rational

Software Corporation., 1998):

Eje horizontal: Representa el tiempo y es considerado el eje de los

aspectos dinámicos del proceso. Indica las características del ciclo de


45

vida del proceso expresado en términos de fases, iteraciones e hitos. Se

puede observar en la Figura 13 que RUP consta de cuatro fases: Inicio,

Elaboración, Construcción y Transición. Como se mencionó

anteriormente cada fase se subdivide a la vez en iteraciones.

Eje vertical: Representa los aspectos estáticos del proceso. Describe el

proceso en términos de componentes de proceso, disciplinas, flujos de

trabajo, actividades, artefactos y roles.

Figura 12: Estructura de RUP.

2.2.2.4. ESTRUCTURA DINÁMICA DEL PROCESO. FASES E

ITERACIONES

RUP se repite a lo largo de una serie de ciclos que constituyen la

vida de un producto. Cada ciclo concluye con una generación del

producto para los clientes. Cada ciclo consta de cuatro fases: Inicio,

Elaboración, Construcción y Transición. Cada fase se subdivide a la vez


46

en iteraciones, el número de iteraciones en cada fase es variable.

Figura 13: Ciclos, releases, baseline.

Cada fase se concluye con un hito bien definido, un punto en el

tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar

las metas clave antes de pasar a la siguiente fase, ese hito principal de

cada fase se compone de hitos menores que podrían ser los criterios

aplicables a cada iteración. Los hitos para cada una de las fases son:

Inicio - Lifecycle Objectives, Elaboración - Lifecycle Architecture,

Construcción - Initial Operational Capability, Transición - Product

Release. Las fases y sus respectivos hitos se ilustran en la Figura 15.

Figura 14: Fases e hitos en RUP

ciclo de desarrollo ciclo de evolución

generación(release final de

un ciclo de desarrollo)

release(producto al final de

una iteración)

base line(release asociada

a un hito)

ciclo de desarrollo ciclo de evolución

generación(release final de

un ciclo de desarrollo)

release(producto al final de

una iteración)

base line(release asociada

a un hito)

tiempo

Objetivos(Vision)

Arquitectura CapacidadOperacional

Inicial

Releasedel Producto


tiempo

Objetivos(Vision)

Arquitectura CapacidadOperacional

Inicial

Releasedel Producto



47

La duración y esfuerzo dedicado en cada fase es variable

dependiendo de las características del proyecto. Sin embargo, la

Figura 16 ilustra porcentajes frecuentes al respecto. Consecuente con

el esfuerzo señalado, la Figura 17 ilustra una distribución típica de

recursos humanos necesarios a lo largo del proyecto.

Inicio Elaboración Construcción Transición

Esfuerzo 5 % 20 % 65 % 10%

Tiempo

Dedicado 10 % 30 % 50 % 10%

Figura 15: Distribución típicas de esfuerzo y tiempo.

Figura 16: Distribución típica de recursos humanos.

Inicio: Durante la fase de inicio se define el modelo del negocio y el

alcance del proyecto. Se identifican todos los actores y Casos de Uso, y

se diseñan los Casos de Uso más esenciales (aproximadamente el 20%

del modelo completo). Se desarrolla, un plan de negocio para

determinar que recursos deben ser asignados al proyecto.


48

Los objetivos de estaa fase según (Kruchten P. , 2000) son:

Establecer el ámbito del proyecto y sus límites.

Encontrar los Casos de Uso críticos del sistema, los escenarios

básicos que definen la funcionalidad.

Mostrar al menos una arquitectura candidata para los escenarios

principales.

Estimar el coste en recursos y tiempo de todo el proyecto.

Estimar los riesgos, las fuentes de incertidumbre.

Los resultados de la fase de inicio deben ser según (Rational Software

Corporation., 1998):

Un documento de visión: Una visión general de los requerimientos

del proyecto, características clave y restricciones principales.

Modelo inicial de Casos de Uso (10-20% completado).

Un glosario inicial: Terminología clave del dominio.

Lista de riesgos y plan de contingencia.

Plan del proyecto, mostrando fases e iteraciones.

Modelo de negocio, si es necesario

Prototipos exploratorios para probar conceptos o la arquitectura

candidata.

Al terminar la fase de inicio se deben comprobar los criterios de

evaluación para continuar:

Todos los interesados en el proyecto coinciden en la definición del

ámbito del sistema y las estimaciones de agenda.

Entendimiento de los requisitos, como evidencia de la fidelidad de


49

los Casos de Uso principales.

Las estimaciones de tiempo, coste y riesgo son creíbles.

Comprensión total de cualquier prototipo de la arquitectura

desarrollado.

Los gastos hasta el momento se asemejan a los planeados.

Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o

repensarlo profundamente.

Elaboración: El propósito de la fase de elaboración es analizar el

dominio del problema, establecer los cimientos de la arquitectura,

desarrollar el plan del proyecto y eliminar los mayores riesgos.

En esta fase se construye un prototipo de la arquitectura, que debe

evolucionar en iteraciones sucesivas hasta convertirse en el sistema

final. Este prototipo debe contener los Casos de Uso críticos

identificados en la fase de inicio. También debe demostrarse que se han

evitado los riesgos más graves.

Los objetivos de esta fase según (Kruchten P. , 2000) son:

Definir, validar y cimentar la arquitectura.

Completar la visión.

Crear un plan fiable para la fase de construcción. Este plan puede

evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.

Demostrar que la arquitectura propuesta soportará la visión con un

coste razonable y en un tiempo razonable.

Al terminar deben obtenerse los siguientes resultados según


50

(Rational Software Corporation., 1998):

Un modelo de Casos de Uso completa al menos hasta el 80%: todos

los casos y actores identificados, la mayoría de los casos desarrollados.

Requisitos adicionales que capturan los requisitos no funcionales y

cualquier requisito no asociado con un Caso de Uso específico.

Descripción de la arquitectura software.

Un prototipo ejecutable de la arquitectura.

Lista de riesgos y caso de negocio revisados.

Plan de desarrollo para el proyecto.

Un caso de desarrollo actualizado que especifica el proceso a seguir.

Un manual de usuario preliminar (opcional).

En esta fase se debe tratar de abarcar todo el proyecto con la

profundidad mínima. Sólo se profundiza en los puntos críticos de la

arquitectura o riesgos importantes.

En la fase de elaboración se actualizan todos los productos de la fase

de inicio.

Los criterios de evaluación de esta fase son los siguientes:

La visión del producto es estable.

La arquitectura es estable.

Se ha demostrado mediante la ejecución del prototipo que los

principales elementos de riesgo han sido abordados y resueltos.

El plan para la fase de construcción es detallado y preciso. Las

estimaciones son creíbles.


51

Todos los interesados coinciden en que la visión actual será

alcanzada si se siguen los planes actuales en el contexto de la

arquitectura actual.

Los gastos hasta ahora son aceptables, comparados con los

previstos.

Si no se superan los criterios de evaluación quizá sea necesario

abandonar el proyecto o replanteárselo considerablemente.

Construcción: La finalidad principal de esta fase es alcanzar la

capacidad operacional del producto de forma incremental a través de las

sucesivas iteraciones. Durante esta fase todos los componentes,

características y requisitos deben ser implementados, integrados y

probados en su totalidad, obteniendo una versión aceptable del

producto.

Los objetivos concretos según (Kruchten P. , 2000) incluyen:

Minimizar los costes de desarrollo mediante la optimización de

recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.

Conseguir una calidad adecuada tan rápido como sea práctico.

Conseguir versiones funcionales (alfa, beta, y otras versiones de

prueba) tan rápido como sea práctico.

Los resultados de la fase de construcción según (Rational Software

Corporation., 1998) deben ser:

Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e

Implementación).

Arquitectura íntegra (mantenida y mínimamente actualizada)


52

Riesgos Presentados Mitigados

Plan del Proyecto para la fase de Transición.

Manual Inicial de Usuario (con suficiente detalle)

Prototipo Operacional – beta

Caso del Negocio Actualizado


El producto es estable y maduro como para ser entregado a la

comunidad de usuario para ser probado.

Todos los usuarios expertos están listos para la transición en la

comunidad de usuarios.

Son aceptables los gastos actuales versus los gastos planeados.

Transición: La finalidad de la fase de transición es poner el producto

en manos de los usuarios finales, para lo que se requiere desarrollar

nuevas versiones actualizadas del producto, completar la

documentación, entrenar al usuario en el manejo del producto, y en

general tareas relacionadas con el ajuste, configuración, instalación y

facilidad de uso del producto.

En (Kruchten P. , 2000) se citan algunas de las cosas que puede incluir

esta fase:

Prueba de la versión Beta para validar el nuevo sistema frente a las

expectativas de los usuarios

Funcionamiento paralelo con los sistemas legados que están siendo

sustituidos por nuestro proyecto.

Conversión de las bases de datos operacionales.


53

Entrenamiento de los usuarios y técnicos de mantenimiento.

Traspaso del producto a los equipos de marketing, distribución y

venta.

Los principales objetivos de esta fase son:

Conseguir que el usuario se valga por sí mismo.

Un producto final que cumpla los requisitos esperados, que funcione

y satisfaga suficientemente al usuario.

Los resultados de la fase de transición según (Rational Software

Corporation., 1998) son:

Prototipo Operacional.

Documentos Legales.

Línea de Base del Producto completa y corregida que incluye todos

los modelos del sistema.

Descripción de la Arquitectura completa y corregida.


El usuario se encuentra satisfecho.

Son aceptables los gastos actuales versus los gastos planificados.

2.2.2.5. ESTRUCTURA ESTÁTICA DEL PROCESO. ROLES,

ACTIVIDADES, ARTEFACTOS Y FLUJOS DE TRABAJO

Un proceso de desarrollo de software define quién hace qué, cómo y

cuándo. RUP define cuatro elementos los roles, que responden a la

pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?,


54

los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo

de las disciplinas que responde a la pregunta ¿Cuándo? (ver Figura 18 y

19) (Rational Software Corporation., 1998).

Figura 17: Relación entre roles, actividades, artefactos

Figura 18: Detalle de un workflow mediante roles, actividades y artefactos.

Roles: Un rol define el comportamiento y responsabilidades de un

individuo, o de un grupo de individuos trabajando juntos como un

equipo. Una persona puede desempeñar diversos roles, así como un

mismo rol puede ser representado por varias personas.


55

Las responsabilidades de un rol son tanto el llevar a cabo un conjunto

de actividades como el ser el dueño de un conjunto de artefactos. RUP

define grupos de roles, agrupados por participación en actividades

relacionadas. Estos grupos son (Rational Software Corporation, 2002)

Analistas:

Analista de procesos de negocio.

Diseñador del negocio.

Analista de sistema.

Especificador de requisitos.

Desarrolladores:

Arquitecto de software.

Diseñador

Diseñador de interfaz de usuario

Diseñador de cápsulas.

Diseñador de base de datos.

Implementador.

Integrador.

Gestores:

Jefe de proyecto

Jefe de control de cambios.

Jefe de configuración.

Jefe de pruebas

Jefe de despliegue


56

Ingeniero de procesos

Revisor de gestión del proyecto

Gestor de pruebas.

Apoyo:

Documentador técnico

Administrador de sistema

Especialista en herramientas

Desarrollador de cursos

Artista gráfico

Especialista en pruebas:

Especialista en Pruebas (tester)

Analista de pruebas

Diseñador de pruebas

Otros roles:

Stakeholders.

Revisor

Coordinación de revisiones

Revisor técnico

Cualquier rol

Actividades: Una actividad en concreto es una unidad de trabajo que

una persona que desempeñe un rol puede ser solicitado a que realice.

Las actividades tienen un objetivo concreto, normalmente expresado en

términos de crear o actualizar algún producto.


57

Artefactos: Un producto o artefacto es un trozo de información que es

producido, modificado o usado durante el proceso de desarrollo de

software. Los productos son los resultados tangibles del proyecto, las

cosas que va creando y usando hasta obtener el producto final.

Un artefacto puede ser cualquiera de los siguientes según (Rational

Software Corporation, 2002) :

Un documento, como el documento de la arquitectura del software.

Un modelo, como el modelo de Casos de Uso o el modelo de diseño.

Un elemento del modelo, un elemento que pertenece a un modelo

como una clase, un Caso de Uso o un subsistema.

Flujos de trabajo : Con la enumeración de roles, actividades y

artefactos no se define un proceso, necesitamos contar con una

secuencia de actividades realizadas por los diferentes roles, así como la

relación entre los mismos. Un flujo de trabajo es una relación de

actividades que nos producen unos resultados observables. A

continuación se dará una explicación de cada flujo de trabajo.

Modelado del negocio: Con este flujo de trabajo pretendemos llegar a

un mejor entendimiento de la organización donde se va a implantar el

producto. Los objetivos del modelado de negocio según (Rational

Software Corporation, 2002) son:

Entender la estructura y la dinámica de la organización para la cual

el sistema va ser desarrollado (organización objetivo).

Entender el problema actual en la organización objetivo e identificar

potenciales mejoras.


58

Asegurar que clientes, usuarios finales y desarrolladores tengan un

entendimiento común de la organización objetivo.

Derivar los requisitos del sistema necesarios para apoyar a la

organización objetivo.

Para lograr estos objetivos, el modelo de negocio describe como

desarrollar una visión de la nueva organización, basado en esta visión

se definen procesos, roles y responsabilidades de la organización por

medio de un modelo de Casos de Uso del negocio y un Modelo de

Objetos del Negocio. Complementario a estos modelos, se desarrollan

otras especificaciones tales como un Glosario.

Requisitos: Este es uno de los flujos de trabajo más importantes, porque

en él se establece qué tiene que hacer exactamente el sistema que

construyamos. En esta línea los requisitos son el contrato que se debe

cumplir, de modo que los usuarios finales tienen que comprender y

aceptar los requisitos que especifiquemos.

Los objetivos del flujo de datos Requisitos según (Rational Software

Corporation, 2002) son:

Establecer y mantener un acuerdo entre clientes y otros

stakeholders sobre lo que el sistema podría hacer.

Proveer a los desarrolladores un mejor entendimiento de los

requisitos del sistema.

Definir el ámbito del sistema.

Proveer una base para la planeación de los contenidos técnicos de

las iteraciones.


59

Proveer una base para estimar costos y tiempo de desarrollo del

sistema.

Definir una interfaz de usuarios para el sistema, enfocada a las

necesidades y metas del usuario.

Los requisitos se dividen en dos grupos. Los requisitos funcionales

representan la funcionalidad del sistema. Se modelan mediante

diagramas de Casos de Uso. Los requisitos no funcionales representan

aquellos atributos que debe exhibir el sistema, pero que no son una

funcionalidad específica. Por ejemplo requisitos de facilidad de uso,

fiabilidad, eficiencia, portabilidad, etc.

Para capturar los requisitos es preciso entrevistar a todos los

interesados en el proyecto, no sólo a los usuarios finales, y anotar todas

sus peticiones. A partir de ellas hay que descubrir lo que necesitan y

expresarlo en forma de requisitos.

En este flujo de trabajo, y como parte de los requisitos de facilidad

de uso, se diseña la interfaz gráfica de usuario. Para ello habitualmente

se construyen prototipos de la interfaz gráfica de usuario que se

contrastan con el usuario final.

Análisis y Diseño: El objetivo de este flujo de trabajo es traducir los

requisitos a una especificación que describe cómo implementar el

sistema. Los objetivos del análisis y diseño según (Rational Software

Corporation, 2002) son:

Transformar los requisitos al diseño del futuro sistema.


60

Desarrollar una arquitectura para el sistema.

Adaptar el diseño para que sea consistente con el entorno de

implementación, diseñando para el rendimiento.

El análisis consiste en obtener una visión del sistema que se

preocupa de ver qué hace, de modo que sólo se interesa por los

requisitos funcionales. Por otro lado el diseño es un refinamiento del

análisis que tiene en cuenta los requisitos no funcionales, en definitiva

cómo cumple el sistema sus objetivos.

Al principio de la fase de elaboración hay que definir una

arquitectura candidata: crear un esquema inicial de la arquitectura del

sistema, identificar clases de análisis y actualizar las realizaciones de

los Casos de Uso con las interacciones de las clases de análisis. Durante

la fase de elaboración se va refinando esta arquitectura hasta llegar a su

forma definitiva. En cada iteración hay que analizar el comportamiento

para diseñar componentes. Además si el sistema usará una base de

datos, habrá que diseñarla también, obteniendo un modelo de datos.

El resultado final más importante de este flujo de trabajo será el

modelo de diseño. Consiste en colaboraciones de clases, que pueden ser

agregadas en paquetes y subsistemas.

Otro producto importante de este flujo es la documentación de la

arquitectura de software, que captura varias vistas arquitectónicas del

sistema.


61

Implementación: En este flujo de trabajo se implementan las clases y

objetos en ficheros fuente, binarios, ejecutables y demás. Además se

deben hacer las pruebas de unidad: cada implementador es responsable

de probar las unidades que produzca. El resultado final de este flujo de

trabajo es un sistema ejecutable.

En cada iteración habrá que hacer lo siguiente:

Planificar qué subsistemas deben ser implementados y en qué orden

deben ser integrados, formando el Plan de Integración.

Cada implementador decide en qué orden implementa los elementos

del subsistema.

Si encuentra errores de diseño, los notifica.

Se prueban los subsistemas individualmente.

Se integra el sistema siguiendo el plan.

La estructura de todos los elementos implementados forma el

modelo de implementación. La integración debe ser incremental, es

decir, en cada momento sólo se añade un elemento. De este modo es

más fácil localizar fallos y los componentes se prueban más a fondo. En

fases tempranas del proceso se pueden implementar prototipos para

reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable

desde el principio, probar tecnologías o diseñar la interfaz de usuario.

Los prototipos pueden ser exploratorios (desechables) o evolutivos.

Estos últimos llegan a transformarse en el sistema final.

Pruebas: Este flujo de trabajo es el encargado de evaluar la calidad del

producto que estamos desarrollando, pero no para aceptar o rechazar el


62

producto al final del proceso de desarrollo, sino que debe ir integrado

en todo el ciclo de vida.

Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos

según (Rational Software Corporation, 2002) son:

Encontrar y documentar defectos en la calidad del software.

Generalmente asesora sobre la calidad del software percibida.

Provee la validación de los supuestos realizados en el diseño y

especificación de requisitos por medio de demostraciones concretas.

Verificar las funciones del producto de software según lo diseñado.

Verificar que los requisitos tengan su apropiada implementación.

Las actividades de este flujo comienzan pronto en el proyecto con el

plan de prueba (el cual contiene información sobre los objetivos

generales y específicos de las prueba en el proyecto, así como las

estrategias y recursos con que se dotará a esta tarea), o incluso antes con

alguna evaluación durante la fase de inicio, y continuará durante todo el

proyecto.

El desarrollo del flujo de trabajo consistirá en planificar que es lo

que hay que probar, diseñar cómo se va a hacer, implementar lo

necesario para llevarlos a cabo, ejecutarlos en los niveles necesarios y

obtener los resultados, de forma que la información obtenida nos sirva

para ir refinando el producto a desarrollar.

Despliegue: El objetivo de este flujo de trabajo es producir con éxito

distribuciones del producto y distribuirlo a los usuarios. Las actividades


63

implicadas incluyen:

Probar el producto en su entorno de ejecución final.

Empaquetar el software para su distribución.

Distribuir el software.

Instalar el software.

Proveer asistencia y ayuda a los usuarios.

Formar a los usuarios y al cuerpo de ventas.

Migrar el software existente o convertir bases de datos.

Este flujo de trabajo se desarrolla con mayor intensidad en la fase de

transición, ya que el propósito del flujo es asegurar una aceptación y

adaptación sin complicaciones del software por parte de los usuarios.

Su ejecución inicia en fases anteriores, para preparar el camino, sobre

todo con actividades de planificación, en la elaboración del manual de

usuario y tutoriales.

Gestión del proyecto: La Gestión del proyecto es el arte de lograr un

balance al gestionar objetivos, riesgos y restricciones para desarrollar

un producto que sea acorde a los requisitos de los clientes y los

usuarios.

Los objetivos de este flujo de trabajo son:

Proveer un marco de trabajo para la gestión de proyectos de

software intensivos.

Proveer guías prácticas realizar planeación, contratar personal,

ejecutar y monitorear el proyecto.


64

Proveer un marco de trabajo para gestionar riesgos.

La planeación de un proyecto posee dos niveles de abstracción: un

plan para las fases y un plan para cada iteración.

Configuración y control de cambios: La finalidad de este flujo de

trabajo es mantener la integridad de todos los artefactos que se crean en

el proceso, así como de mantener información del proceso evolutivo

que han seguido.

Entorno: La finalidad de este flujo de trabajo es dar soporte al proyecto

con las adecuadas herramientas, procesos y métodos. Brinda una

especificación de las herramientas que se van a necesitar en cada

momento, así como definir la instancia concreta del proceso que se va

a seguir.

En concreto las responsabilidades de este flujo de trabajo incluyen:

Selección y adquisición de herramientas

Establecer y configurar las herramientas para que se ajusten a la

organización.

Configuración del proceso.

Mejora del proceso.

Servicios técnicos.

El principal artefacto que se usa en este flujo de trabajo es el caso de

desarrollo que específica para el proyecto actual en concreto, como se

aplicará el proceso, que productos se van a utilizar y cómo van a ser

utilizados. Además se tendrán que definir las guías para los distintos


65

aspectos del proceso, como pueden ser el modelado del negocio y los

Casos de Uso, para la interfaz de usuario, el diseño, la programación, el

manual de usuario.

2.2.3. CONTROL DE RESIDUOS

Residuos sólidos (Montes, 2001): Los residuos sólidos son producto

inevitables de toda actividad humana, los procesos modernos de

producción están generando cantidades ingentes de residuos, que en su

mayor parte no son útiles para los productos.

Gestión de residuos sólidos (Montes, 2001): La gestión de residuos

sólidos tiene como objetivo la optimización de las inversiones y de los

costes operativos necesarios para reducir la cantidad de los residuos y el

impacto ambiental que puedan producir hasta límites que se consideren

aceptables de acuerdo con los conocimientos actuales.

Clasificación de los residuos (Ochoa, 2008, pág. 153) : Según el sector

productor se clasifican en residuos del sector primario (agrícolas,

ganaderos, silvicultores, forestales y mineros), residuos del sector

secundario (industriales y energéticos) y residuos del sector terciario

(distribución, servicios, consumo).

Residuos Mineros (Ferrando, 2007) : Son aquellos residuos producidos

durante la prospección, extracción, valorización, eliminación y

almacenamiento de recursos minerales, así como de la explotación de

canteras.


66

Sistema de Información (Fernadez, 2005) : Un sistema es un conjunto

de componentes que interaccionan entre sí para lograr un objetivo

común. A un que existe una gran variedad de sistemas la mayoría de

ellos pueden representarse a través de un modelo formado por cinco

bloques básicos: elementos de entrada, elementos de salida, sección de

transformación, mecanismos de control y objetivos.

En la actualidad, la Información y la tecnología de la Información

forman parte de los cinco recursos con los que los ejecutivos crean y/o

modelan una organización, junto con el personal, dinero, material y

maquinaria.

2.3. DEFINICIÓN DE TÉRMINOS

Almacén: Un almacén básicamente es un espacio, recinto, edificio, o

instalación donde se suele guardar la mercancía entre otras cosas.

Almacenamiento: Es el acondicionamiento de los residuos de acuerdo a

su naturaleza física, química y biológica, considerando sus

características de peligrosidad, su incompatibilidad con otros residuos,

así como las reacciones que pueden ocurrir con el material del

recipiente que lo contiene.

Almacenamiento Central: Lugar o instalación donde se consolida y

acumula temporalmente los residuos provenientes de las diferentes

fuentes de la empresa o institución generadora, en contenedores para su

posterior tratamiento, disposición final u otro destino autorizado.


67

Almacenamiento intermedio: Lugar o instalación que recibe

directamente los residuos generados por la fuente, utilizando

contenedores para su almacenamiento, y posterior evacuación hacia el

almacenamiento central.

Clasificación de Residuos: Es la tipología de residuos basado en una

descripción cualitativa del origen, pueden ser domésticos, industriales,

hospitalarios, forestales, etc.

Disposición final: La acción de depósito permanente de los residuos

sobre el suelo, en condiciones seguras para evitar daños al ambiente.

Gestión de Residuo: Es el proceso de recolección, transporte,

procesamiento, tratamiento, reciclaje o disposición de material de

desecho, generalmente producida por la actividad humana, en un

esfuerzo por reducir efectos perjudiciales en la salud humana y la

estética del entorno, aunque actualmente se trabaja para reducir los

efectos perjudiciales ocasionados al medio ambiente y recuperar los

recursos del mismo.

Peligrosidad de Residuos: Es la clasificación de residuo peligroso que,

en función de sus características que puede presentar riesgo a la salud

pública o causar efectos adversos al medio ambiente; la peligrosidad

pueden ser: corrosiva, reactiva, explosiva, toxica, inflamable y

patogénica.

Punto de Acopio: Es donde se reúne en cantidad algún material.

http://es.wikipedia.org/wiki/Transporte

http://es.wikipedia.org/wiki/Tratamiento_de_residuos

http://es.wikipedia.org/wiki/Reciclaje


68

Medio Ambiente: Medio ambiente, conjunto de elementos abióticos

(energía solar, suelo, agua y aire) y bióticos (organismos vivos) que

integran la delgada capa de la Tierra llamada biosfera, sustento y hogar

de los seres vivos.

Modelo Vista Controlador (MVC): Es un patrón o modelo de

abstracción de desarrollo de software que separa los datos de una

aplicación, la interfaz de usuario, y la lógica de negocio en

tres componentes distintos. Es el más utilizado en aplicaciones web, ya

que facilita la funcionalidad, mantenibilidad y escalabilidad del

sistema, de forma simple y sencilla.

Reporte: Un reporte es un Documento, generado por el Sistema, que

nos presenta de manera Estructurada y/o Resumida, datos relevantes

guardados o generados por la misma aplicación de tal manera que se

vuelvan útiles.

Reciclaje: El reciclaje consiste en someter de nuevo una materia o un

producto ya utilizado a un ciclo de tratamiento total o parcial para

obtener una materia prima o un nuevo producto.

Recuperación: Acciones que permiten rescatar la materia útil para las

operaciones a fin de generar menos residuos.

Reutilización: Acciones que permiten de volver a emplear un producto

para darle una segunda vida, con el mismo uso u otro diferente.

Relleno Sanitario: Un relleno sanitario es un lugar destinado a la

disposición final de desechos o basura, en el cual se toman múltiples

http://www.monografias.com/trabajos6/elsu/elsu.shtml

http://www.monografias.com/trabajos14/problemadelagua/problemadelagua.shtml

http://www.monografias.com/trabajos/aire/aire.shtml

http://www.monografias.com/trabajos15/origen-tierra/origen-tierra.shtml

http://www.monografias.com/trabajos14/ecologia-sist/ecologia-sist.shtml#BIOSFERA

http://es.wikipedia.org/wiki/Datos

http://es.wikipedia.org/wiki/Interfaz_de_usuario

http://es.wikipedia.org/wiki/L%C3%B3gica_de_negocio

http://es.wikipedia.org/wiki/Componentes

http://es.wikipedia.org/wiki/Materia_prima

http://es.wikipedia.org/wiki/Basura


69

medidas para reducir los problemas generados por otro método de

tratamiento de la basura como son los tiraderos, dichas medidas son,

por ejemplo, el estudio meticuloso de impacto ambiental, económico y

social desde la planeación y elección del lugar hasta la vigilancia y

estudio del lugar en toda la vida del vertedero.

Tecnología: Es un medio que incorpora aquellos conocimientos

prácticos y técnicos, que sirven al hombre a mejorar las condiciones

naturales para hacer su vida más útil y placentera.

Tratamiento de residuos: Es la transformación del residuo para mitigar

el impacto que genera o puede generar cuando es extraído. Los tipos de

tratamiento pueden ser: físico-químico, biológico, térmico o de relleno

de seguridad.

WWW: La World Wide Web es un sistema de distribución de

información en hipertexto o hipermedios enlazados y accesibles a través

de Internet. Con un navegador, un usuario visualiza sitios web

compuestos de páginas web que pueden contener texto, imágenes,

videos u otros contenidos multimedia y navega a través de ellas usando

hiperenlaces.

http://es.wikipedia.org/wiki/Tiradero

http://es.wikipedia.org/wiki/Impacto_ambiental


70

2.4. HIPÓTESIS DE LA INVESTIGACIÓN

2.4.1. HIPÓTESIS GENERAL

La Implementación de un Sistema Web basado en la

Metodología Rational Unified Process permitirá Optimizar

el Control de Residuos Sólidos de la compañía de Minas

Buenaventura S.A.C. – Lima.

2.4.2. HIPÓTESIS ESPECIFICA

La Determinación del Nivel de Control de los Residuos

Sólidos permitirá conocer la situación actual de la

Compañía de Minas Buenaventura S.A.C. – Lima.

El Diseño y Desarrollo de un Sistema Web basado en la

Metodología Rational Unified Process permitirá Optimizar

el Control de Residuos Sólidos de la Compañía de Minas

Buenaventura S.A.C. – Lima.

La Evaluación del Sistema Web de Residuos Sólidos

permitirá conocer la Optimización del Control de la

Compañía de Minas Buenaventura S.A.C. – Lima.


71

CAPÍTULO III

METODOLOGÍA

3.1. DISEÑO METODOLÓGICO

3.1.1. TIPO DE INVESTIGACIÓN

De acuerdo al propósito de la investigación, naturaleza y al objetivo

de predecir un comportamiento especifico, reúne las condiciones

suficientes para ser catalogada como una Investigación Aplicada y Pre

Experimental.

3.1.2. NIVEL DE INVESTIGACIÓN

En primera instancia será una investigación explicativo

experimental ya que se describirá fenómenos, situaciones, contextos o

eventos y luego experimental ya que se pretende establecer la causas y

efecto de los eventos.


72

3.2. POBLACIÓN Y MUESTRA

3.2.1. POBLACIÓN

La población objetivo de la investigación estará constituida por todo

el personal de la compañía minera Buenaventura.

El tamaño de la población es exactamente 923 individuos hasta la

fecha.

La población se puede clasificar entre personal directamente e

indirectamente involucrado en el proceso de gestión de residuos.

3.2.2. MUESTRA

Los datos se van a recolectar mediante una encuesta, la cual se

diseñara. Tamaño de muestra: Se muestra a continuación la fórmula que

se empleara para calcular dicha cifra.

Sabiendo que:

Probabilidad de éxito (p) = 95%

Probabilidad de fracaso (q) = 5%

Nivel de confianza es de 95% Z=1.96

N es el tamaño de la población = 923

“e” es precisión (error máx. admisible en términos de proporción) = 5%


73

“n” es el tamaño de nuestra muestra = 68

El tamaño de la población pertenece al número total del personal de la

minera Buenaventura.

( )

3.3. OPERACIONALIZACIÓN DE VARIABLES E INDICADORES

3.3.1. IDENTIFICACIÓN DE VARIABLES

Variable independiente (X):

X: Sistema Web.

Variable dependiente (Y):

Y: Optimizar el Control de los Residuos Sólidos.

3.3.2. OPERACIONALIZACIÓN DE VARIABLES

3.3.2.1. INDICADORES DE LA VARIABLE INDEPENDIENTE

Exactitud.

Amigabilidad.

Portabilidad.

Flexibilidad.

3.3.2.2. INDICADORES DE LA VARIABLE DEPENDIENTE

Rapidez.

Eficiencia.


74

Disponibilidad.

3.4. TÉCNICAS DE RECOLECCIÓN DE DATOS

La información necesaria para llevar a cabo este trabajo de investigación, se

obtendrá de la siguiente manera utilizando los diferentes instrumentos de

recolección de información:

Análisis documental: Con el fin de obtener datos fundamentales del

problema de investigación para este trabajo en estudio se revisara las fuentes

escritas (Textos, tesis, revista, internet, etc.)

Encuestas: Mediante cuestionarios de preguntas cerradas de opción

múltiple, se obtendrán información de profesionales calificados que conozcan

el proceso de negocio (Ver ANEXO N° 4).

Entrevistas: Serán realizados a los jefes de área para conocer más sobre en

el proceso ambiental de manejo de residuos (Ver ANEXO N° 5).

3.5. TÉCNICAS PARA EL PROCESAMIENTO DE LA

INFORMACIÓN

Los datos obtenidos en las encuestas (Ver ANEXO N° 6) serán procesados

y analizados por medios electrónicos como el SPSS que es un programa

estadístico informático, teniendo en cuenta su capacidad para trabajar con

grandes bases de datos y una sencilla interface para la mayoría de los análisis.

El procesamiento de datos ser llevará a cabo en un primer momento

ordenando y clasificando la información en programas como Ms-Word, Ms-

Excel.


75

CAPÍTULO IV

DESARROLLO

4.1. ANÁLISIS

4.1.1. ANÁLISIS DE ENTREVISTAS

Mediante la realización de entrevistas (Ver ANEXO N° 5)

a los jefes de área entre otros, se pudo recolectar información

sobre el proceso ambiental de manejo de residuos.

Dicha información recolectada nos sirvió para identificar los

requerimientos funcionales y no funcionales como también

plasmar en casos de uso del sistema lo que el sistema debería

hacer junto con los actores que intervienen en el proceso.


76

4.1.2. REQUERIMIENTOS

4.1.2.1. LISTA DE REQUERIMIENTOS FUNCIONALES

Nº Código de

requerimiento

Nombre del

Requerimiento Descripción del Requerimiento

1 RF-01

Puntos de

almacenamiento y

contenedores

Registro, edición y eliminación de

puntos de almacenamiento y

contenedores teniendo en cuenta su

clasificación respectiva.

2

RF-02

Transporte de

Residuos Sólidos

Registro, edición y eliminación del

transporte de residuos sólidos,

teniendo en cuenta los tipos de

transporte y la relación que tiene

este con la compañía a la cual

pertenece.

Registro del transporte y disposición

final.

3 RF-03

Fuentes de

Generación de

Residuos Sólidos

Registro y Actualización de las

Fuentes de generación de Residuos

Sólidos.

5 RF-04 Residuos Sólidos

Registro, edición y eliminación de

residuos sólidos. Protección del

personal y el manejo del residuo.

6 RF-05 Reportes

Elaboración de Reportes para la

entidad correspondiente: Informe de

Generación de Residuos.

Tabla N° 1 Lista de requerimientos funcionales.

4.1.2.2. LISTA DE REQUERIMIENTOS NO FUNCIONALES

Código. Requerimiento No Funcional.

RNF-01 Servidor Multi Plataforma (Windows, Linux.)

RNF-02 Cliente Web (Explorer, Firefox, Netscape, Chrome.)

RNF-03 Multi Conexión

RNF-04 Seguridad


77

RNF-05 Multi Base de Datos (PostgreSql, Mysql, Oracle, SQL

Server)

RNF-06 Realizado utilizando Software Libre (Java, Ajax, Apache)

RNF-07 Localizable.

RNF-08 Sistema Standard de importación exportación de datos.

RNF-09 Definición de seguridad por roles

RNF-10 Auditoría.

RNF-11 Navegabilidad

Tabla N° 2: Lista de requerimientos no funcionales.

4.1.3. ANÁLISIS DEL SISTEMA

4.1.3.1. CASOS DE USO

Los casos de uso son una manera formal de capturar y expresar la

iteración y el diálogo entre los usuarios del sistema llamados actores y

el propio sistema. Los casos de uso expresan lo que el sistema debería

hacer, sin preocuparse en el cómo lo hará.

4.1.3.1.1. Actores

Un actor representa un rol de un usuario que interactúa con el sistema.

A continuación se describe a los actores del sistema propuesto.

Actor Descripción

Usuario

Administrador

Es el usuario que tiene todos los privilegios sobre el

sistema.

Usuario Medio

Ambiental

Es el usuario del sistema en este caso son los empleados

de las empresas minera que se encuentran laborando en

los procesos medio ambientales.

Usuario Invitado Este tipo de usuario solo tiene permiso de lectura, mas no

puede modificar ningún registro.

Sistema El sistema que se está desarrollando.

Tabla N° 3: Lista de Actores del Sistema.


78

4.1.3.2. LISTADO DE DIAGRAMA DE CASOS DE USO

Nº Caso de Uso

1 Caso de uso Nº 1 – Gestionar Punto de Almacenamiento.

2 Caso de uso Nº 2 – Gestionar Residuos Generados.

3 Caso de uso Nº 3 – Gestionar Transporte Interno.

4 Caso de uso Nº 4 – Gestionar Disposición Final.

5 Caso de uso Nº 5 – Generar Informe de Generación de Residuos.

Tabla N° 4: Listado de Diagrama de Casos de Uso.

4.1.3.3. DIAGRAMA DE CASOS DE USO

Figura 19: Diagrama de Caso de Uso del Sistema.


79

4.1.3.4. DETALLE DE LOS REQUISITOS

4.1.2.4.1. Caso de uso nº 1 – Gestionar Punto de Almacenamiento.

Figura 20: Diagrama de Caso de Uso Gestionar punto de Almacenamiento.

Pre condición Haber ingresado al S.

Post condición Listado de Puntos de almacenamientos.

Actor(es): Usuario: U, Sistema: S.

Objetivo: Registrar Puntos de Almacenamientos.

Referencias

Cruzadas:

RF-01.

Pasos: 1. U: Ingresa S.

2. S: Muestra opciones del Menú.

3. U: Selecciona opción Punto de Almacenamiento.

4. S: Muestra página Listado de Puntos de

Almacenamientos.

5. U: Da clic en botón Nuevo.

6. S: Muestra pop up Registro de Punto de

Almacenamiento.

7. U: Realiza lo siguiente:

7.1. Selecciona y/o registra los datos necesarios.

7.2. Da clic en botón Guardar.

8. S: Realiza lo siguiente.

8.1. Guarda los datos registrados en la tabla

rs_punto_almacenamiento.

8.2. Muestra mensaje “Se guardó satisfactoriamente”. Tabla N° 5: Caso de Uso Nº 1.


80

4.1.2.4.2. Caso de uso nº 2 – Gestionar Residuos Generados.

Figura 21: Diagrama de Caso de Uso Gestionar Residuos Generados.

Pre condición Haber ingresado al Sistema.

Post condición Listado de Residuos Generados.


Objetivo: Registrar Residuos Generados.

Referencias

Cruzadas:

RF-03,RF-04


81



3. U: Selecciona opción Residuo Generado.

4. S: Muestra página Listado de Residuos Generados.

5. U: Da clic en botón Nuevo

6. S: Muestra pop up Registrar Residuo Generado, con

las siguientes Pestañas.

Datos Generales.

Fuente de Generación.

Protección del Personal.

Empresa Prestadora de Servicio y

Comercializadora.

Peligrosidad.

Punto de Almacenamiento.

Reaprovechamiento.

7. U: Da clic en pestaña Datos Generales.

8. U: Realiza lo siguiente:

8.1. Ingresa y/o selecciona los datos requeridos.



9.1. Guarda los Datos en los siguientes campos.

9.2. Muestra mensaje “Se guardó

satisfactoriamente”. Tabla N° 6: Caso de Uso Nº 2.

4.1.2.4.3. Caso de uso nº 3 – Gestionar Transporte Interno.

Figura 22: Diagrama de Caso de Uso Gestionar Transporte Interno.

Pre condición: Haber ingresado al S.

Post condición: Listado de Transportes Internos.



82

Objetivo: Registrar el transporte que traslado el residuo generado al

punto de almacenamiento interno o central.

Referencias

Cruzadas:

RF-02



3. U: Selecciona opción Transporte Interno.

4. S: Muestra página Listado de Transporte Interno.

5. U: Da clic en botón nuevo.

6. S: Muestra pop up Registro de Transporte Interno.

7. U: Realiza lo siguiente.

7.1. Registra y/o selecciona los datos correspondientes.


8. S: Realiza lo siguientes.

8.1. Guarda los datos en la siguiente tabla.

8.2. Muestra mensaje “Se guardó satisfactoriamente”. Tabla N° 7: Caso de Uso Nº 3.

4.1.2.4.4. Caso de uso nº 4 – gestionar disposición final.

Figura 23: Diagrama de Caso de Uso Gestionar Disposición Final.

Pre condición: Haber ingresado al S

Post condición: Listado de Disposición Final.


Objetivo: Registrar la Disposición Final.


83

Referencias

Cruzadas:

RF-02



3. U: Selecciona opción Disposición Final.

4. S: Muestra página Listado de Disposición Final.

5. U: Da clic en botón Nuevo.

6. S: Muestra pop up registro de Disposición Final.

7. U: Realiza lo siguiente.

7.1. Ingresa y/o selecciona los datos correspondientes.



8.1. Guarda datos en las siguientes tablas.

8.2. Muestra mensaje “Se guardó satisfactoriamente”.

Flujo

Alternos:

Del Paso 6: Editar Disposición Final

9. U: Selecciona una Disposición Final y da clic en botón

Editar

10. Repetir del Paso 7 hasta el Paso 9.


11.1. No realiza verifica alguna.

11.2. Muestra mensaje “Se guardó

satisfactoriamente”.

Del Paso 7: Eliminar Disposición Final

12. U: Selecciona una Disposición Final y da clic en botón

Eliminar

13. S: Realiza lo siguiente

13.1. No realiza verificación alguna

13.2. Muestra mensaje “Se eliminó

satisfactoriamente”

Escenarios : Escenario 1: U registra transporte Final

Escenario 2: U edita transporte Final

Escenario 3: U elimina transporte Final

Tabla N° 8: Caso de Uso Nº 4.

4.1.2.4.5. Caso de uso nº 5 – Generar Informe de Generación de

Residuos.


84

Figura 24: Diagrama de Caso de Uso Generar Informe de Generación de Residuos.

Pre condición: Haber ingresado al S.

Haber registrado residuos generados.

Haber registrado la disposición final del residuo.

Post condición: Obtención de informe de generación de residuos para el

año seleccionado.

Actor(es) Usuario: U, Sistema: S.

Objetivo Genera informe de generación de Residuos.

Referencias

Cruzadas

RF-06

Pasos 1. U: Ingresa S.


3. U: Selecciona opción Informe de Generación de

Residuos.

4. S: Muestra página Informe de Generación de

Residuos.

5. U: Realiza lo siguiente

5.1. Selecciona residuo e ingresa el año

5.2. Da clic en botón Generar

6. S: realiza lo siguiente

6.1. Muestra mensaje “Generando Reporte”. Al

término de la generación muestra cuadro de

dialogo para guardar reporte en PC.

7. Los datos que muestra el reporte se encuentran en el

ANEXO N° 1


85

Cursos

Alternos

Del Paso 11.1: Si no hay información para los filtros

seleccionados, S muestra mensaje “No existe

información para filtros seleccionados”

Escenarios Escenario 1: U genera reporte de Informe de Generación

de Residuos

Restricciones Cuando U no seleccione y/o ingrese un campo

obligatorio, S muestra mensaje “Campo Obligatorio”

Se permitirá la opción de exportar el reporte a

formato PDF, Word y Excel

Tabla N° 9: Caso de Uso Nº 5.

4.1.3.5. MATRIZ DE TRAZABILIDAD:

Para confirma que los casos de uso presentados satisfacen los

requerimientos funcionales especificados, se realizara la matriz de

trazabilidad. Se marcara con un “X” cuando el caso de uso satisface un

requerimiento.

Casos de Uso

CU01 CU02 CU03 CU04 CU05

Req

uer

imie

nto

s F

un

cion

ale

s

RF-01 X

RF-02 X X

RF-03 X

RF-04 X

RF-05 X

Tabla N° 10: Matriz de Trazabilidad.


86

4.1.3.6. DIAGRAMA DE PROCESOS

4.1.4. DIAGRAMA DE CLASES:

Las clases que conforma el sistema y las relaciones que existen entre ellas

son las siguientes:

Figura 25: Diagrama de Clases

Clasificación de

Residuos

Registro de EPS/EC

Registro de Puntos

de Almacenamiento

Registro de

RRSS

Registro de Ingreso

a Puntos

Almacenamiento

Registro de

Transporte

Interno y

Disposición Final • Datos Generales

• Fuentes de Generación (n)

• Protección del Personal (n)

• Almacenamiento

Intermedio (n)

Emisión de

Reportes

A

A


87

4.1.3.1. ESPECIFICACIÓN DE LAS CLASES DEL SISTEMA

A continuación se explicara cada una de las clases que conforman el sistema:

Clases. Descripción.

Residuo Generado Clase que representa a un residuo sólido y sus propiedades.

Grupo Clase que representa a un grupo de residuos sólidos,

clasificados por colores según el tipo de residuo y su

peligrosidad.

Fuente Generación Clase que representa a una fuente de generación de residuos

sólidos en una determinada actividad.

Unidad Residuo Clase que representa a una unidad de medida de un residuo

sólido.

Clase Residuo Clase que representa a una clase de residuo sólido según su

composición como por ejemplo Peligroso, Inflamable,

Doméstico, etc.

Residuo

Reaprovechamiento

Clase que representa a un reaprovechamiento de un residuo

según sus propiedades.

Residuo

Almacenamiento

Interno

Clase que representa a un tipo de almacenamiento final

interno de un residuo.

Almacenamiento

Final Interno

Clase que representa a un tipo de almacenamiento final

interno.

Asigna Disposición

Interna Residuo

Generado

Clase que representa a una asignación de disposición interna

de un residuo sólido.

Tipo Clase que representa a un tipo de residuo sólido.

Protección Personal Clase que representa a un tipo de protección y sus riesgos de

este mismo para el personal.

Transporte Final

Externa

Clase que representa a un tipo de transporte final externo.

Peligrosidad Clase que representa a un tipo de peligrosidad.

Asigna Residuo

Generado

Peligrosidad

Clase que representa a una asignación de residuo sólido y su

peligrosidad.

Transporte Final Clase que representa a un tipo transporte final.

Punto de

Almacenamiento

Clase que representa a un Punto donde se almacenará de

manera temporal un residuo.

Transporte Interno Clase que representa a un tipo de transporte interno.

Tabla N° 11: Especificación de Clases del Sistema.


88

4.2. DISEÑO

4.2.1. ARQUITECTURA DEL SISTEMA

4.2.1.1. ARQUITECTURA WEB

La arquitectura web empleada es la siguiente:

Front-end: Framework ExtJs, CSS3 (Cascading Style Sheets), Java

Script.

Middle-tier: La conforman el servidor de aplicaciones apache-tomcat-

7 , que corren en sistema operativo Windows, sobre este corren nuestras

aplicaciones desarrolladas con tecnología Java (Servlets, JSP y Java

Beans).

Back-end: Un servidor con un sistema operativo Windows Server

2008 donde corra un Sistema de Gestión de Bases de Datos (SGBD)

Microsoft SQL Server 2008 R2 Enterprise Edición y un Lenguaje de

programación Java

Figura 26: Arquitectura Web.


89

4.2.1.2. PATRÓN DE DISEÑO

Un patrón de diseño es una solución estándar para resolver un

problema de software conocido, que ha sido aprobado y reutilizado.

En el presente trabajo de investigación se empleara el patrón de

diseño Modelo Vista Controlador (MVC). Este patrón de diseño separa

los datos y la lógica de negocio de una aplicación de la interfaz de

usuario y el modulo encargado de gestionar los eventos y las

comunicaciones.

Para ello MVC propone la construcción de tres componentes

distintos que son el modelo, la vista y el controlador.

Figura 27: Modelo Vista Controlador

4.2.1.3. DIAGRAMA DE INTERACCIÓN

Un diagrama de secuencia o de interacción es un diagrama que

se centra en ordenar en el tiempo la comunicación que existe entre los

objetos.


90

Nomenclatura:

Sufijo Descripción

GUI Interfaz

CONTROL Controlador

BD Base de Datos Tabla N° 12: Nomenclatura.

4.2.2.7.1. Diagrama de secuencia: CU n° 1.1 Gestionar Punto de

Almacenamiento - Registrar

Figura 28: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Registrar.

4.2.2.7.2. Diagrama de secuencia: CU N° 1.2 Gestionar Punto de

Almacenamiento - Editar.


91

Figura 29: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Editar.


Almacenamiento Listar.

Figura 30: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Listar.


Almacenamiento - Eliminar


92

Figura 31: Diagrama de Secuencia: Gestionar Punto de Almacenamiento Eliminar.

4.2.2.7.5. Diagrama de secuencia: CU N° 2.1 Gestionar Residuo

Sólido - Registrar.

Figura 32: Diagrama de Secuencia: Gestionar Residuo Sólido Registrar.


93

4.2.2.7.6. Diagrama de secuencia: CU n° 2.2 gestionar residuo

sólido - editar.

Figura 33: Diagrama de Secuencia: Gestionar Residuo Sólido Editar.

4.2.2.7.7. Diagrama de secuencia: CU N° 2.3 Gestionar Residuo

Sólido Listar.

Figura 34: Diagrama de Secuencia: Gestionar Residuo Sólido Listar.


94

4.2.2.7.8. Diagrama de secuencia: CU n° 2.4 gestionar residuo sólido

- eliminar.

Figura 35: Diagrama de Secuencia: Gestionar Residuo Sólido Eliminar.

4.2.2.7.9. Diagrama de secuencia: CU N° 2.5 Registrar Protección

Personal.

Figura 36: Diagrama de Secuencia: Registrar Protección Personal.


95

4.2.2.7.10. Diagrama de secuencia: CU N° 2.6 Registrar EPS/EC.

4.2.2.7.11. Diagrama de secuencia: CU N° 2.7 Registrar Fuente de

Generación.

Figura 38: Diagrama de Secuencia: Registrar Fuente de Generación.

Figura 37: Diagrama de Secuencia: Registrar EPS/EC.


96

4.2.2.7.12. Diagrama de secuencia: CU N° 2.8 Registrar Peligrosidad.

Figura 39: Diagrama de Secuencia: Registrar Peligrosidad.

4.2.2.7.13. Diagrama de secuencia: CU N° 2.9 Registrar Punto de

Almacenamiento.

Figura 40: Diagrama de Secuencia: Registrar Punto de Almacenamiento.


97

4.2.2.7.14. Diagrama de secuencia: CU N° 2.10 Registrar

Reaprovechamiento.

Figura 41: Diagrama de Secuencia: Registrar Reaprovechamiento.

4.2.2.7.15. Diagrama de secuencia: CU n° 3.1 Gestionar transporte

interno - registrar.

Figura 42: Diagrama de Secuencia: Gestionar Transporte Interno Registrar.


98

4.2.2.7.16. Diagrama de secuencia: CU N° 3.2 Gestionar Transporte

Interno - Editar.

Figura 43: Diagrama de Secuencia: Gestionar Transporte Interno Editar.

4.2.2.7.17. DIAGRAMA DE SECUENCIA: CU N° 3.3 Gestionar

Transporte Interno Listar.

Figura 44: Diagrama de Secuencia: Gestionar Transporte Interno Listar.


99

4.2.2.7.18. Diagrama de secuencia: CU N° 3.4 Gestionar Transporte

Interno - Eliminar.

Figura 45: Diagrama de Secuencia: Gestionar Transporte Interno Eliminar.

4.2.2.7.19. Diagrama de secuencia: CU N° 4.1 Gestionar Disposición

Final Registrar.

Figura 46: Diagrama de Secuencia: Gestionar Disposición Final Registrar.


100


Final - Editar.

Figura 47: Diagrama de Secuencia: Gestionar Disposición Final Editar.


Final - Listar.

Figura 48: Diagrama de Secuencia: Gestionar Disposición Final Listar.


101


Final Eliminar.

Figura 49: Diagrama de Secuencia: Gestionar Disposición Final Eliminar.

4.2.2.7.23. Diagrama de secuencia: CU N° 5 Generar Informe de


Figura 50: Diagrama de Secuencia: Generar Informe de Generación de

Residuos.


102

4.2.2.8. MODELO FÍSICO DE DATOS

Figura 51: Modelo Físico de Datos.

4.2.2.9. ESPECIFICACIÓN DEL MODELO FÍSICO DE DATOS.

rs_residuo_generado

Nombre Columna. Descripción.

rs_residuo_generado_id Identificador autogenerado correlativo

rs_clase_residuo_id Identificador de la clase del residuo

rs_grupo_residuo_id

Identificador del grupo al que pertenece el

residuo

Nombre Nombre del residuo

Descripción Datos que describen el residuo generado

Componentes Químicos

Datos de los componentes químicos del residuo

generado

Color Color referencial que toma el residuo

Ph Potencial de hidrogeno que tiene el residuo

Temperatura Temperatura que toma el residuo

Creado Fecha en la cual se creó el registro

creado_por Identificador del usuario que creo el registro

Actualizado Fecha de la última actualización del registro

actualizado_por

Identificador del usuario que realizo el último

cambio

propietario_id Identificador del usuario que creo el registro


103

Estado Identificador del estado: 1=Activo; 0=Inactivo

fb_uea_pe_id Identificador de la UEA

volumen_recipiente Volumen del recipiente contenedor del residuo

Material Nombre del material que contiene el residuo

Recipiente Recipiente del residuo

numero_recipiente Cantidad del recipientes utilizados

id_eps_tratamiento Identificador de la eps que atiende el residuo

descripcion_metodo Descripción del método a utilizar para el residuo

fb_codigo_tratamiento_id Identificador del tratamiento

cantidad_tratamiento Cantidad que se está tratando

descripcion_actividad Descripción de la actividad

cantidad_minimizacion Cantidad mensual de minimización

rs_unidad_residuo_id Unidad del residuo

ma_ea_id Identificador del instrumento ambiental

Peligrosidad

Identificador que indica si tiene peligrosidad:

1=SI; 0=NO

Reciclable

Identificador que indica si tiene reciclaje: 1=SI;

0=NO

almacenamiento_temporal

Identificador que indica si tiene almacén

temporal: 1=SI; 0=NO

almacenamiento_final

Identificador que indica si tiene almacén final:

1=SI; 0=NO

herramientas_recojo Datos de las herramientas de recojo utilizadas

equipos_seguridad Datos de los equipos de seguridad Tabla N° 13 Tabla de Residuos Generados

rs_almacenamiento_final_interno

Nombre Columna Descripción

rs_almacenamiento_

final_interno_id Identificador autogenerado correlativo

Nombre

Nombre del punto de disposición final

interna

Dirección

Dirección del punto de disposición final

interno

numero_autorizacion_relleno Número de autorización del relleno

fb_ubigeo_id Identificador del ubigeo

Descripción

Datos de descripción del punto de

disposición final interna


utm_norte Coordenada utm norte

utm_este Coordenada utm este

utm_altitud Coordenada utm altitud

utm_zona Identificador de la zona

utm_datum Identificador del datum

Volumen

Cantidad del volumen que soporta el punto

de disposición final interna

Peso

Cantidad del pese que soporta el punto de

disposición final interna


104

Latitud

Coordenadas referenciales para el google

earth latitud

Longitud

Coordenadas referenciales para el google

earth longitud

Tipo

Identificador del tipo disposición final

interna: 1=Relleno Sanitario; 2=Relleno de

Seguridad; 3=Comercialización;

4=Compostera; 5=Relleno no Peligroso




propietario_id Fecha en la cual se creó el registro

actualizado_por

Identificador del usuario que realizo el último

cambio

Estado

Identificador del punto de disposición final

interna Tabla N° 14 Tabla de Almacenamiento Final Interno.

rs_peligrosidad


rs_peligrosidad_id Identificador autogenerado correlativo

nombre Nombre de la peligrosidad del residuo

estado Identificador del estado: 1=Activo

codigo Fecha en la cual se creó el registro

creado Identificador del usuario que creo el registro

creado_por Fecha de la última actualización del registro

actualizado

Identificador del usuario que realizo el

último cambio

actualizado_por Identificador del usuario que creo el registro

propietario_id Identificador del usuario que creo el registro Tabla N° 15 Tabla de Peligrosidad.

rs_grupo_residuo


rs_grupo_residuo_id Identificador autogenerado correlativo

Nombre Nombre del grupo de residuo




actualizado_por


último cambio


Código Código del grupo de residuo Tabla N° 16 Tabla de Grupo de Residuo.


105

rs_fuente_generacion


rs_fuente_generacion_id Identificador autogenerado correlativo

fb_area_id

Identificador del área donde se produce el

residuo

actividad_generadora Nombre de la actividad generadora

Insumos

Descripción de los insumos que contiene el

residuo

rs_residuo_generado_id Identificador del residuo generado




actualizado_por


último cambio


rs_residuo_tipo_id Identificador del tipo de residuo

Anio Año de la actividad generadora Tabla N° 17 Tabla de Fuente de Generación

rs_proteccion_personal


rs_proteccion_personal_id Identificador autogenerado correlativo


descripcion_trabajo

Descripción del trabajo que necesita la

protección

numero_personal

Número de personas que realizan el

trabajo

descripcion_riesgos

Descripción del riesgo en la realización del

trabajo

descripcion_medidas_seguridad

Descripción de las medidas de seguridad

para la elaboración del trabajo

creado Fecha en la cual se creó el registro

creado_por

Identificador del usuario que creo el

registro

actualizado

Fecha de la última actualización del

registro

actualizado_por


último cambio

propietario_id


registro Tabla N° 18 Tabla de Protección Personal.

rs_punto_almacenamiento


rs_punto_almacenamiento_id Identificador autogenerado correlativo

nombre Nombre del punto de almacenamiento

numero_autorizacion_relleno

Número de autorización del punto de

almacenamiento


106

fb_ubigeo_id Identificador del ubigeo

descripcion Descripción del punto de almacenamiento


creado_por


registro

actualizado


registro

propietario_id


último cambio

actualizado_por


registro


utm_norte Coordenado utm norte

utm_este Coordenado utm este

utm_altitud Coordenado utm altitud

utm_zona Identificador de la zona

utm_datum Identificador del datum

volumen

Cantidad en volumen de lo que puede

contener el punto de almacenamiento

peso

Cantidad en peso de lo que puede contener

el almacén temporal

latitud Coordenada google earth latitud

longitud Coordenada google earth longitud

estado

Identificador del estado del almacén

temporal Tabla N° 19 Tabla de Punto Almacenamiento.

rs_residuo_almacenamiento_interno


rs_residuo_almacenamiento_

interno_id Identificador autogenerado correlativo


rs_almacenamiento_final_

interno_id

Identificador del punto de disposición

final interna


creado_por


registro

actualizado


registro

actualizado_por


último cambio

propietario_id


registro Tabla N° 20 Tabla de Residuos Almacenamiento Interno.

rs_residuo_generado_almacenamiento


rs_residuo_generado_

almacenamiento_id Identificador autogenerado correlativo


107


rs_punto_almacenamiento_id Identificador del punto de almacenamiento


creado_por


registro

Actualizado


registro

actualizado_por


último cambio

propietario_id


registro Tabla N° 21 Tabla de Residuo Generado Almacenamiento.

rs_transporte_final


rs_transporte_final_id Identificador autogenerado correlativo

fecha_llegada Fecha en la que llega el transporte

tipo_vehiculo Descripción del tipo de vehículo

pertenencia

Identificador del tipo de pertenencia del

vehículo: 1=Propio; 2=Alquilado; 3=Otro

numero_placa Número de la placa

axo_fabricacion Año de fabricación del vehículo

numero_ejes Número de ejes del vehículo

Capacidad Capacidad del vehículo

Color Color del vehículo


creado_por


registro


actualizado_por


último cambio

propietario_id


registro

minuto_llegada Minuto de llegado del vehículo

hora_llegada Hora de llegada del vehículo

numero_guia Número de la guía asignado al vehículo

rs_punto_almacenamiento_id

Identificador del punto de almacenamiento

interno

fb_eps_ec_id

Identificador de la EPS/EC que se encargar

de la disposición final externa

rs_almacenamiento_

final_interno_id

Identificador del punto de disposición final

interna

tipo_disposicion_final

Identificador del tipo de disposición final:

1=Interna; 2=Externa

tipo_origen

Identificador del tipo de origen: 1=punto de

acopio; 2=almacén temporal

tipo_residuo

Identificador que indica el tipo de residuo:

1=Peligroso; 2=No peligroso


108

epsEc_transporte


del transporte

Manifiesto Dirección del archivo del manifiesto Tabla N° 22 Tabla de Transporte Final.

rs_transporte_interno_residuo


rs_transporte_interno_

residuo_id Identificador autogenerado correlativo

rs_transporte_interno_id Identificador del transporte interno


Volumen Volumen del residuo que es transportado

Peso Peso del residuo que es transportado


creado_por


registro


actualizado_por


último cambio

propietario_id


registro

Cantidad Cantidad del residuo que es transportado

unidad_residuo Unidad del residuo que es transportado Tabla N° 23 Tabla de Transporte Interno Residuo.

rs_transporte_interno


rs_transporte_interno_id Identificador autogenerado correlativo

fecha_llegada Fecha en la que llega el transporte

fb_eps_ec_id


del transporte interno

tipo_vehiculo Descripción del tipo de vehículo

Pertenencia

Identificador del tipo de pertenencia del

vehículo: 1=Propio; 2=Alquilado; 3=Otro

numero_placa Número de la placa

axo_fabricacion Año de fabricación del vehículo

numero_ejes Número de ejes del vehículo

Capacidad Capacidad del vehículo

Color Color del vehículo

equipos seguridad

Equipos de seguridad con los que cuenta el

vehículo


creado_por


registro


actualizado_por


último cambio


109

propietario_id


registro

minuto_llegada Minuto de llegado del vehículo

hora_llegada Hora de llegada del vehículo


rs_punto_almacenamiento_id

Identificador del punto de almacenamiento

interno

tipo_residuo

Identificador que indica el tipo de residuo:

1=Peligroso; 2=No peligroso Tabla N° 24 Tabla de Transporte Interno.

rs_transporte_final_residuo


rs_transporte_final_residuo_id Identificador autogenerado correlativo

rs_transporte_final_id Identificador del transporte interno


Volumen Volumen del residuo que es transportado

Peso Peso del residuo que es transportado


creado_por


registro


actualizado_por


último cambio

propietario_id


registro

Cantidad Cantidad del residuo que es transportado

unidad_residuo Unidad del residuo que es transportado Tabla N° 25 Tabla de Transporte Final Residuo.

4.2.3. DISEÑO DE INTERFAZ GRAFICA

Los prototipos del sistema cumple con los requerimientos funcionas

y no funcionales aprobados por los usuarios finales.

A continuación se mostrara las pantallas de los prototipos, divididos

por caso de uso, de tal manera se asegure el cumplimiento de los

requerimientos.


110

4.2.3.1. PANTALLAS: Caso de uso Nº 1 Gestionar Punto de

Almacenamiento.

Figura 52: Pantalla de Punto de Almacenamiento Listar.

Figura 53: Pantalla de Punto de Almacenamiento Nuevo / Editar.

Figura 54: Pantalla de Residuos que Almacena.

4.2.3.2. PANTALLAS: Caso de uso Nº 2 – Gestionar Residuos

Generados.


111

Figura 55: Pantalla de Residuos Generados Listar

Figura 56: Pantalla de Residuos Generados Nuevo/Editar (Parte 1).

Figura 57: Pantalla de Residuos Generados Nuevo/Editar (Parte 2).


112

Figura 58: Pantalla de Peligrosidad de Residuo Generado.

Figura 59: Pantalla de Fuente de Generación de Residuo Generado.

Figura 60: Pantalla de Registro de EPS/EC.


113

Figura 61: Pantalla de registro de Protección Personal.

Figura 62: Pantalla de Registro de Almacenamiento.

Figura 63: Pantalla de Registro de Disposición Final Interno.


114

Figura 64: Pantalla de Registro de Reaprovechamiento.

4.2.3.3. PANTALLAS: Caso de uso Nº 3 – Gestionar Transporte

Interno.

Figura 65: Pantalla de Transporte Interno Listar.


115

Figura 66: Pantalla de Transporte Interno Nuevo/ Editar.


Figura 68: Pantalla de Ingreso a Almacén Temporal.


116

4.2.3.4. PANTALLAS: Caso de uso Nº 4 – Gestionar Disposición

Final.

Figura 69: Pantalla de Disposición Final Listar.

Figura 70: Pantalla de Disposición Final Nuevo/Editar.



117

4.2.3.5. PANTALLAS: Caso de uso Nº 5 – Generar Informe de


Figura 72: Pantalla de Filtros del Reporte.

Figura 73: Pantalla del Reporte en PDF.

Figura 74: Pantalla del Reporte en Excel.

4.2.4. DIAGRAMA DE DESPLIEGUE

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje

Unificado de Modelado que se utiliza para modelar el hardware

utilizado en las implementaciones de sistemas y las relaciones entre sus

componentes.


118

Figura 75: Diagrama de Despliegue.

4.3. IMPLEMENTACIÓN

4.3.1. FASE 1: PREPARAR UN AMBIENTE OPERACIONAL

Y UNO DE PRUEBA SEPARADOS

Se entiende por ambiente o plataforma la combinación específica de

hardware y software que nos permite correr un sistema, por ambiente

operacional, la plataforma donde corre el sistema actual y por ambiente

de test o de prueba, la plataforma utilizada para desarrollar y dar

mantenimiento a los sistemas.

El tener el ambiente operacional y el de prueba separados permite

proteger el sistema y evitar problemas que pudieran dañar los datos o

interrumpir las operaciones durante las tareas de prueba.


119

La plataforma operacional del sistema de información incluye las

configuraciones de hardware y software apropiadas, utilidades del

sistema, recursos de telecomunicaciones y otros componentes. A esta

plataforma operacional sólo tienen acceso los usuarios bajo un control

estricto. Los analistas de sistemas y programadores no tienen acceso.

El ambiente de test está reduciendo a una estación de trabajo o a un

servidor que contiene copias de los programas y procedimientos, así

como de los archivos de datos de prueba.

4.3.2. FASE 2: OFRECER CAPACITACIÓN A LOS

USUARIOS, ADMINISTRADORES Y TÉCNICOS

A los usuarios se les ofreció una visión general del sistema y los

términos o palabras clave; los procedimientos de inicio y apagado del

sistema; el menú principal y los submenús; las funciones principales del

sistema; una guía para sacar adelante los problemas que se presenten y

una lista de preguntas frecuentes.

Al equipo de TI se les capacito en la arquitectura del sistema y su

documentación, la resolución de problemas y en el entrenamiento de los

usuarios y del personal administrativo.

A los administradores, entre otros se les capacito en la obtención de

los objetivos del negocio, los principales reportes que ofrece el sistema

y como requerir mejoras al mismo.


120

4.3.3. FASE 3: REALIZAR LA CONVERSIÓN DE DATOS Y

EL CAMBIO DE SISTEMA

Es una parte importante de la implantación o instalación del sistema

y que consiste en cargar en el nuevo sistema los datos existentes.

El proceso de cambio del sistema consiste en poner en línea el nuevo

sistema y en retirar el anterior si es que lo hubiese. Puede realizarse de

forma directa o en paralelo como fue el caso.

4.3.4. FASE 4: EFECTUAR UNA EVALUACIÓN LUEGO DE

LA INSTALACIÓN DEL SISTEMA

Una vez instalado el sistema, debe permitir observar la calidad del

nuevo sistema de información de forma integral. Se pone énfasis en

determinar si el sistema efectivamente cumple ciertos requisitos,

permite lograr los objetivos de los usuarios y produce los beneficios

para los cuales fue aprobado.

Para lo cual se procedió a realizar una encuesta como se muestra en

el ANEXO N° 2 y su posterior análisis que se muestra en el siguiente

capítulo.

4.3.5. FASE 5: PRESENTAR UN REPORTE FINAL A LA

ADMINISTRACIÓN

Se realizó un reporte final que incluyo las versiones definitivas de


121

toda la documentación del sistema, las modificaciones o mejoras a

realizar a futuro que fueron detectadas, la recapitulación de los

presupuestos y cronogramas utilizados durante la instalación y los

resultados correspondientes a la evaluación final.

4.4. CONSTRUCCIÓN

4.4.1. MÓDULOS DEL SISTEMA

En esta sección se mencionara los módulos que conforman el sistema

web:

Generación de Residuos Sólidos.

Registro de Puntos de Almacenamientos.

Registro de Disposición Final Interna.

Registro de Transporte y Disposición Final.

Ingreso a Almacén Temporal.

Generación reporte de declaración de manejo de residuo.

Generación de Informe de generación de residuo.

Las cuales se encuentran integrados a los demás sistemas como se

muestra a continuación:


122

Figura 76: Integración del Sistema de Residuos Sólidos al Sistema de Gestión

Ambiental.

Generación de Residuos Sólidos.

Este módulo tiene como finalidad el registro de los diferentes tipos de

residuos sólidos considerando si es peligroso y/o reciclable. Asimismo

se registrara a que punto de almacenamiento temporal, almacenamiento

interno y empresa comercializadora y/o empresa prestadora de servicios

está asociado dicho residuo.

Las funcionalidades que presenta este módulo son: consultar, editar,

eliminar.

Registro de Puntos de Almacenamientos.

Este módulo tiene como finalidad permitir a los usuarios registrar

nuevos puntos de almacenamientos para los diferentes residuos sólidos,

con su respectiva ubicación en coordenadas. Asimismo, permitirá

consultar los diferentes residuos sólidos almacenados en dicho punto de


123

almacenamiento.


eliminar.

Registro de Disposición Final Interna.


nuevos puntos de disposición final interna para los diferentes residuos

sólidos, con su respectiva ubicación en coordenadas y capacidad de

almacenamiento. Asimismo, permitirá consultar los diferentes residuos

sólidos almacenados en dicho punto de disposición final interna.


eliminar.

Registro de Transporte y Disposición Final.


nuevos puntos de disposición final para los diferentes residuos sólidos,

con su respectivo origen desde donde fue transportado y la fecha de la

misma. Asimismo, permitirá consultar los diferentes residuos sólidos

almacenados en dicho punto de disposición final.


eliminar.

Ingreso a Almacén Temporal.



124

nuevos almacenes temporales para los diferentes residuos sólidos, con

su respectiva empresa prestadora de servicios y la fecha del ingreso.

Asimismo, permitirá consultar los diferentes residuos sólidos

almacenados en dicho almacén temporal.


eliminar.

Generación Reporte de Declaración de Manejo de Residuos.

Este módulo tiene como finalidad permitir a los usuarios generar

reportes de declaración para los diferentes residuos sólidos.

Generación de Informe de Generación de Residuos.

Este módulo tiene como finalidad permitir a los usuarios generar

reportes de todos los residuos sólidos de manera periódica.


125

CAPÍTULO V

DISCUSIÓN, CONCLUSIÓN Y RECOMENDACIONES

5.1. ANÁLISIS DE RIESGOS

Un riesgo es una variable del proyector que pone en peligro o impide el

éxito del mismo. Es la probabilidad de que un proyecto experimente sucesos no

deseables, como retrasos en las fechas, excesos de costos o la cancelación

directa (Capers, 2000).

El propósito del análisis de riesgo es identificar los riesgos que se pueda

presentar en el desarrollo del proyecto, analizarlos, calcular la exposición y en

base a ello priorizar, para establecer estrategias de control.

Se pretende seleccionar e implementar las medidas o salvaguardas para

conocer, prevenir, reducir o controlar los riesgos identificados, y así reducir al

mínimo su potencial o posibles perjuicios para la implementación (MAGERIT,

2006).


126

5.1.1. IDENTIFICACIÓN DE RIESGOS

Riesgos de planificación:

Planificación optimista, en lugar de realista.

Un retraso en una tarea produce retrasos en cascada en otras

tareas.

La fecha final ha cambiado sin ajustarse al alcance del producto

o a los recursos disponibles.

Los procesos poco conocidos llevan más tiempo de lo esperando

en el diseño y en la implementación.

Riesgos en la organización y gestión:

El proyecto carece de un promotor efectivo en los superiores.

Los despidos y la reducción de los recursos humanos reducen la

capacidad del equipo.

El presupuesto varía el plan del proyecto.

La dirección toma decisiones que reducen la motivación del

equipo de desarrollo.

Las tareas no técnicas encargadas a terceros necesitan más

tiempo del esperado.

Riesgos en el entorno de desarrollo:

La infraestructura de desarrollo no está disponible en el

momento necesario.

La infraestructura de desarrollo está disponible pero no es el

adecuado.

Las herramientas de desarrollo no están disponibles en el


127

momento deseado.

Las herramientas de desarrollo no funcionan como se esperaba.

Curva de aprendizaje para la nueva herramienta de desarrollo es

más larga de lo esperado.

Riesgos de los Usuarios Finales:

Los usuarios finales insisten en nuevos requerimientos.

En el último momento, a los usuarios finales no les gusta el

producto, por lo que hay que volver a diseñarlo y a construir.

Los usuarios no participan en el desarrollo del software.

La comunicación con el usuario es más lenta de lo esperado.

El usuario final no acepta el software entregado, incluso aunque

cumpla con todas las especificaciones.

Riesgos en los requisitos:

Los requisitos cambian constantemente.

Los requisitos no sean definidos correctamente.

Se añaden requisitos extras pero no se quitan otros.

Riesgo en el Producto:

Los módulos propensos a tener errores necesitan más pruebas de

las planificadas.

El desarrollo de funcionalidades de software erróneas requiere

volver a diseñarlas e implementarlas.

El desarrollo de una interfaz de usuario poco amigable requiere

volver a diseñarla y a implementarla.

El trabajo con un entorno de software desconocido causa


128

problemas no previstos.

El trabajo con un hardware desconocido causa problemas no

previstos.

Depender de una tecnología que aún está en fase de desarrollo

alarga la planificación.

Riesgos por Fuerzas Mayores:

EL producto depende de las normativas del gobierno, que

pueden cambiar de forma inesperada.

El producto depende de estándares técnicos provisionales que

pueden cambiar de forma inesperada.

Riesgo del Personal:

La contratación tarda más de lo esperado.

Los miembros del equipo no se comprometen en el proyecto.

La falta de motivación reduce la productividad.

La falta de especialización necesaria aumenta la necesidad de

repetir el trabajo.

El personal necesita tiempo adicional para acostumbrarse a

trabajar con herramientas o entornos nuevos.

El personal necesita un tiempo adicional para acostumbrarse a

trabajar con hardware nuevo.

El personal contratado abandona el proyecto antes de su

finalización.

La incorporación de nuevo personal de desarrollo al proyecto ya

avanzado, reducen la eficiencia de los miembros del equipo


129

existentes.

Los miembros de los equipos no trabajan bien juntos.

Miembros problemáticos de un equipo no son apartados,

influyendo negativamente en la motivación del resto del equipo.

Se necesitan personas para el proyecto con habilidades muy

específicas y no se encuentran.

Las personas claves solo están disponibles una parte del tiempo.

No hay suficiente personal disponible para el proyecto.

El personal trabaja más lento de lo esperado.

Riesgos de diseño e implementación:

Un diseño demasiado sencillo no cubre las funcionalidades

principales por lo que hay volver a diseñar e implementar.

Un mal diseño implica volver a diseñar e implementar.

La utilización de metodologías desconocidas deriva en un

periodo extra de formación.

El producto esta implementado en un lenguaje de bajo nivel y la

productividad es menor de la esperada.

Riesgos en los Procesos:

La burocracia produce un progreso más lento del esperado.

La falta de un seguimiento exacto del progreso hace que se

desconozca que el proyecto esté retrasado hasta que está muy

avanzado.


130

5.1.2. IDENTIFICACIÓN DE PROBABILIDAD DE

OCURRENCIA

Indicador de

Probabilidad Descripción

1 No se espera que ocurra durante la vida del proyecto.

2 Se espera que ocurra no más de una vez durante la vida

del proyecto.

3 Se espera que ocurra varias veces durante la vida del

proyecto.

4 Se espera que ocurra continuamente durante la vida del

proyecto. Tabla N° 26 Identificación de probabilidad de ocurrencia.

5.1.3. SEVERIDAD DE LAS CONSECUENCIAS

Indicador de

Severidad Descripción

1 No casusa impacto relevante en el proyecto.

2

Causa ligero impacto en el proyecto, retrasos en los

tiempos del proyecto no mayores a 2 semanas y

montos no mayores a 5 000 soles.

3

Impacto moderado en el proyecto, retrasos en los

tiempos de proyecto no mayores a 5 semanas y montos

no mayores a 10 000 soles.

4

Alto impacto en la vida del proyecto, retrasos mayores

a 5 semanas o indefinidos, alto grado de incertidumbre

y perdidas mayores a 30 000 soles. Tabla N° 27 Severidad de las consecuencias.

5.1.4. MATRIZ DE EVALUACIÓN DE RIESGOS

Probabilidad de

Ocurrencia

Severidad de las Ocurrencias

1 2 3 4

1 IV IV IV III

2 IV IV III II

3 IV III II I

4 III II I I Tabla N° 28 Matriz de evaluación de riesgos.


131

5.1.5. CATEGORÍA DE IMPORTANCIA DEL RIESGO

Numero Categoría Descripción

I Inaceptable.

El riesgo debe ser reducido o, si es posible

eliminado. Situaciones donde peligra la

continuidad o viabilidad del proyecto. Debe de

ser mitigado con controles de gestión y/o de

ingeniería hasta un rango de riesgos de III o IV.

II Indeseable

Implementación de planes de continuidad del

negocio. Se debe tomar medidas de prevención

y control en cada etapa del proyecto. Debe ser

mitigado con controles de gestión y/o de

ingeniería hasta un rango de riesgo de III o IV.

III

Aceptable

con

controles.

Medidas de prevención, contingencia y control

periódico en todas las etapas del proyecto.

Implementación de planes de continuidad del

negocio.

IV Aceptable

como está.

Medidas de prevención y contingencia.

Aplicación de planes de continuidad del

negocio. Tabla N° 29 Categoría de importancia del riesgo.

5.1.6. EVALUACIÓN DE RIESGOS

N° Riesgo

Probabilidad de

ocurrencia.

Severidad de las

Consecuencias.

1 2 3 4 1 2 3 4

1 Planificación optimista, en

lugar de realista. X X

2

Un retraso en una tarea

produce retrasos en cascada

en otras tareas. X X

3

La fecha final ha cambiado

sin ajustarse al alcance del

producto o a los recursos

disponibles.

X X

4

Los procesos poco

conocidos llevan más

tiempo de lo esperando en el

diseño y en la

implementación.

X X

5

El proyecto carece de un

promotor efectivo en los

superiores. X X


132

6

Los despidos y la reducción

de los recursos humanos

reducen la capacidad del

equipo.

X X

7 El presupuesto varía el plan

del proyecto. X X

8

La dirección toma

decisiones que reducen la

motivación del equipo de

desarrollo.

X X

9

Las tareas no técnicas

encargadas a terceros

necesitan más tiempo del

esperado.

X X

10

La infraestructura de

desarrollo no está disponible

en el momento necesario. X X

11

La infraestructura de

desarrollo está disponible

pero no es el adecuado. X X

12

Las herramientas de

desarrollo no están

disponibles en el momento

deseado.

X X

13

Las herramientas de

desarrollo no funcionan

como se esperaba. X X

14

Curva de aprendizaje para la

nueva herramienta de

desarrollo es más larga de lo

esperado.

X X

15 Los usuarios finales insisten

en nuevos requerimientos. X X

16

En el último momento, a los

usuarios finales no les gusta

el producto, por lo que hay

que volver a diseñarlo y a

construir.

X X

17

Los usuarios no participan

en el desarrollo del

software. X X

18

La comunicación con el

usuario es más lenta de lo

esperado. X X

19

El usuario final no acepta el

software entregado, incluso

aunque cumpla con todas las

especificaciones.

X X


133

20 Los requisitos cambian

constantemente. X X

21 Los requisitos no sean

definidos correctamente. X X

22 Se añaden requisitos extras

pero no se quitan otros. X X

23

Los módulos propensos a

tener errores necesitan más

pruebas de las planificadas. X X

24

El desarrollo de

funcionalidades de software

erróneas requiere volver a

diseñarlas e implementarlas.

X X

25

El desarrollo de una interfaz

de usuario poco amigable

requiere volver a diseñarla

y a implementarla.

X X

26

El trabajo con un entorno de

software desconocido causa

problemas no previstos. X X

27

El trabajo con un hardware

desconocido causa

problemas no previstos. X X

28

Depender de una tecnología

que aún está en fase de

desarrollo alarga la

planificación.

X X

29

EL producto depende de las

normativas del gobierno,

que pueden cambiar de

forma inesperada.

X X

30

El producto depende de

estándares técnicos

provisionales que pueden

cambiar de forma

inesperada.

X X

31 La contratación tarda más

de lo esperado. X X

32

Los miembros del equipo no

se comprometen en el

proyecto. X X

33 La falta de motivación

reduce la productividad. X X

34

La falta de especialización

necesaria aumenta la

necesidad de repetir el

trabajo.

X X


134

35

El personal necesita tiempo

adicional para

acostumbrarse a trabajar con

herramientas o entornos

nuevos.

X

X

36

El personal necesita un

tiempo adicional para

acostumbrarse a trabajar con

hardware nuevo.

X X

37

El personal contratado

abandona el proyecto antes

de su finalización. X X

38

La incorporación de nuevo

personal de desarrollo al

proyecto ya avanzado,

reducen la eficiencia de los

miembros del equipo

existentes.

X X

39

Los miembros de los

equipos no trabajan bien

juntos. X X

40

Miembros problemáticos de

un equipo no son apartados,

influyendo negativamente

en la motivación del resto

del equipo.

X X

41

Se necesitan personas para

el proyecto con habilidades

muy específicas y no se

encuentran.

X X

42

Las personas claves solo

están disponibles una parte

del tiempo. X X

43 No hay suficiente personal

disponible para el proyecto. X X

44 El personal trabaja más

lento de lo esperado. X X

45

Un diseño demasiado

sencillo no cubre las

funcionalidades principales

por lo que hay volver a

diseñar e implementar.

X X

46

Un mal diseño implica

volver a diseñar e

implementar. X X

47

La utilización de

metodologías desconocidas

deriva en un periodo extra

de formación.

X X


135

48

El producto esta

implementado en un

lenguaje de bajo nivel y la

productividad es menor de

la esperada.

X X

49

La burocracia produce un

progreso más lento del

esperado. X X

50

La falta de un seguimiento

exacto del progreso hace

que se desconozca que el

proyecto esté retrasado

hasta que está muy

avanzado.

X X


136

5.1.7. RESULTADOS DE ESTIMACIÓN DE RIESGOS

N° Riesgo Probabilidad

de ocurrencia.

Severidad de

las

Consecuencias.

N° Categoría Acciones que deben

tomarse.

1 Planificación optimista, en lugar

de realista. 2 3 III

Aceptable con

controles.

Implementación de planes

de continuidad del

negocio.

2

Un retraso en una tarea produce

retrasos en cascada en otras

tareas. 2 3 III

Aceptable con

controles.

Priorizar según

importancia.

3

La fecha final ha cambiado sin

ajustarse al alcance del producto o

a los recursos disponibles. 2 3 III

Aceptable con

controles.

Planificar el alcance del

proyecto junto con el

equipo de desarrollo.

4

Los procesos poco conocidos

llevan más tiempo de lo esperando

en el diseño y en la

implementación.

3 2 III Aceptable con

controles.

Reuniones semanales con

los usuarios finales.

5

El proyecto carece de un

promotor efectivo en los

superiores. 2 4 II Indeseable.

Involucrar más a cada

miembro del equipo.

6

Los despidos y la reducción de los

recursos humanos reducen la

capacidad del equipo. 2 3 III

Aceptable con

controles.

Planificar los recursos a

emplear.

7 El presupuesto varía el plan del

proyecto. 1 4 III

Aceptable con

controles.


emplear.

8

La dirección toma decisiones que

reducen la motivación del equipo

de desarrollo. 2 3 III

Aceptable con

controles.


miembro del equipo.

137

9

Las tareas no técnicas encargadas

a terceros necesitan más tiempo

del esperado. 2 3 III

Aceptable con

controles.

Búsqueda de expertos con

anticipación.

10

La infraestructura de desarrollo no

está disponible en el momento

necesario. 3 2 III

Aceptable con

controles.


emplear.

11

La infraestructura de desarrollo

está disponible pero no es el

adecuado. 2 2 IV

Aceptable

como está.


emplear.

12

Las herramientas de desarrollo no

están disponibles en el momento

deseado. 1 3 IV

Aceptable

como está.


emplear.

13 Las herramientas de desarrollo no

funcionan como se esperaba. 2 3 III

Aceptable con

controles.


emplear.

14

Curva de aprendizaje para la

nueva herramienta de desarrollo

es más larga de lo esperado. 2 3 III

Aceptable con

controles.

Planificación de

capacitaciones en el uso

de herramientas.

15 Los usuarios finales insisten en

nuevos requerimientos. 3 3 II Indeseable.

Priorizar requerimientos

según importancia.

16

En el último momento, a los

usuarios finales no les gusta el

producto, por lo que hay que

volver a diseñarlo y a construir.

3 4 I Inaceptable. Reuniones periódicas con


17 Los usuarios no participan en el

desarrollo del software. 3 4 I Inaceptable.

Reuniones periódicas con


18 La comunicación con el usuario es

más lenta de lo esperado. 3 2 III

Aceptable con

controles.



19

El usuario final no acepta el

software entregado, incluso

aunque cumpla con todas las

especificaciones.

2 4 II Indeseable. Reuniones periódicas con


138

20 Los requisitos cambian

constantemente. 3 2 III

Aceptable con

controles.



21 Los requisitos no sean definidos

correctamente. 2 2 IV

Aceptable

como está.



22 Se añaden requisitos extras pero

no se quitan otros. 3 3 II Indeseable.

Priorizar requerimientos

según importancia.

23

Los módulos propensos a tener

errores necesitan más pruebas de

las planificadas. 2 3 III

Aceptable con

controles.

Planificar las pruebas de

software con anticipación.

24

El desarrollo de funcionalidades

de software erróneas requiere

volver a diseñarlas e

implementarlas.

2 2 IV Aceptable

como está.

Planificación en el diseño

e implementación de

proyecto.

25

El desarrollo de una interfaz de

usuario poco amigable requiere

volver a diseñarla y a

implementarla.

3 3 II Indeseable.

Desarrollo de prototipos

con anticipación y su

posteríos validación por

los usuarios.

26

El trabajo con un entorno de

software desconocido causa

problemas no previstos. 2 3 III

Aceptable con

controles.

Planificación de


de herramientas.

27

El trabajo con un hardware

desconocido causa problemas no

previstos. 1 2 IV

Aceptable

como está.

Planificación de


de herramientas.

28

Depender de una tecnología que

aún está en fase de desarrollo

alarga la planificación. 1 2 IV

Aceptable

como está.

Planificación de las

herramientas a emplear en

el proyecto.

29

EL producto depende de las

normativas del gobierno, que

pueden cambiar de forma

inesperada.

2 4 II Indeseable.

Revisión periódica de las

publicaciones del

gobierno respecto al

proyecto.

30 El producto depende de 1 2 IV Aceptable Planificación de los

139

estándares técnicos provisionales

que pueden cambiar de forma

inesperada.

como está. estándares técnicos a

emplearse en el proyecto.

31 La contratación tarda más de lo

esperado. 1 2 IV

Aceptable

como está.


emplear.

32 Los miembros del equipo no se

comprometen en el proyecto. 2 2 IV

Aceptable

como está.


miembro del equipo.

33 La falta de motivación reduce la

productividad. 2 3 III

Aceptable con

controles.


miembro del equipo.

34

La falta de especialización

necesaria aumenta la necesidad de

repetir el trabajo. 2 2 IV

Aceptable

como está.


anticipación.

35

El personal necesita tiempo

adicional para acostumbrarse a

trabajar con herramientas o

entornos nuevos.

1 3 IV Aceptable

como está.

Planificación de


de herramientas.

36

El personal necesita un tiempo

adicional para acostumbrarse a

trabajar con hardware nuevo. 1 2 IV

Aceptable

como está.

Planificación de


de herramientas.

37

El personal contratado abandona

el proyecto antes de su

finalización. 2 3 III

Aceptable con

controles.


miembro del equipo.

38

La incorporación de nuevo

personal de desarrollo al proyecto

ya avanzado, reducen la

eficiencia de los miembros del

equipo existentes.

2 2 IV Aceptable

como está.

Planificación de


de herramientas.

39 Los miembros de los equipos no

trabajan bien juntos. 2 2 IV

Aceptable

como está.


miembro del equipo.

40 Miembros problemáticos de un

equipo no son apartados, 2 2 IV

Aceptable

como está.


miembro del equipo.

140

influyendo negativamente en la

motivación del resto del equipo.

41

Se necesitan personas para el

proyecto con habilidades muy

específicas y no se encuentran. 2 2 IV

Aceptable

como está.


anticipación.

42 Las personas claves solo están

disponibles una parte del tiempo. 3 3 II Indeseable.


todo el equipo.

43 No hay suficiente personal

disponible para el proyecto. 1 3 IV

Aceptable

como está.

Planificación de


de herramientas.

44 El personal trabaja más lento de lo

esperado. 2 2 IV

Aceptable

como está.


todo el equipo.

45

Un diseño demasiado sencillo no

cubre las funcionalidades

principales por lo que hay volver

a diseñar e implementar.

3 3 II Indeseable.



proyecto.

46 Un mal diseño implica volver a

diseñar e implementar. 2 3 III

Aceptable con

controles.



proyecto.

47

La utilización de metodologías

desconocidas deriva en un periodo

extra de formación. 1 4 III

Aceptable con

controles.



proyecto.

48

El producto esta implementado en

un lenguaje de bajo nivel y la

productividad es menor de la

esperada.

1 3 IV Aceptable

como está.



proyecto.

49 La burocracia produce un

progreso más lento del esperado. 2 3 III

Aceptable con

controles.


todo el equipo.

50

La falta de un seguimiento exacto

del progreso del proyecto

avanzado. 3 3 II Indeseable.

Implementación de un

diagrama de Gantt.


141

5.2. EVALUACIÓN DEL SISTEMA

5.2.1. FACTIBILIDAD ECONÓMICA – ANÁLISIS COSTO

FINANCIERO

5.2.1.1. COSTOS INICIALES

Costo de Plataforma de Hardware

Equipo Características Cantidad Costo

Unidad Total s./

Laptop

Cpu : i5

Memoria: Ddr3 4 Gb

Disco duro: 500 Gb

2 2800 5600

Servidor

IBM

Procesador Intel Xeon

(3.1GHz) |Memoria

6GB DDR3.

Disco duro 500GB

SATA.

1 3500 3500

Total : 9100

Tabla N° 30: Costo de Plataforma de Hardware.

Costo de Plataforma de Software

Producto Licencia Cantidad Costo Total s./

Sistema

Operativo

Windows

Seven Home

Premium

2 250 500

Base de

Datos

Windows

Server 2008

R2. 64 Bits.

1 3000 3000

Total : 3500 Tabla N° 31: Costo de Plataforma de Software.

Costo de Recursos Humanos

Rol Tiempo

(Meses) Cantidad

Costo

Unitario por

Mes

Costo

total

Jefe De

proyecto 4 1 3000 12000

Analista

Programador 4 1 2000 8000

Total : 20 000 Tabla N° 32: Costo de Recursos Humanos.


142

Resumen de Costos de Implementación

Recursos Costo Total s./

Costo de Plataforma de Hardware 9100

Costo de Plataforma de Software 3500

Costo de Recursos Humanos 20000

Total 32 500 Tabla N° 33: Resumen de Costos de Implementación.

5.2.1.2. COSTOS POR MANTENIMIENTO

Recurso/Actividad Año Cantidad Por Año Costo Unitario

Por año Total

Mantenimiento de

Sistema 1 2 1000 2000

Mantenimiento de PC 1 2 100 200

Otros 1 2 100 200

Total: 2400 Tabla N° 34: Cuadro costo por Mantenimiento.

5.2.1.3. INGRESOS POR AHORROS

Los ahorros económicos se obtienen en la reducción del personal en

el las unidades mineras en el proceso medio ambiental de monitoreo de

residuos sólidos. Mediante el sistema web propuesto se pretende cubrir

dichos procesos y agilizarlos.

Descripción Años Cantidad Costo Unitario Mensual Total

Ingeniero

Ambiental a

tiempo

completo.

1 2 3000 72 000

Personal

Administrativo. 1 1 1200 14 400

Total: 86400 Tabla N° 35: Cuadro de Ingresos por Ahorros.


143

5.2.1.4. FLUJO DE CAJA ECONÓMICO

Conceptos Años

0 1 2 3 4

Ingresos

Ingresos por Ahorro 86 400 86 400 86 400 86 400

Total de Ingresos 86 400 86 400 86 400 86 400

Egresos

Inversión de la Implementación 32 500

Costos por Mantenimiento

2 400 2 400 2 400 2 400

Total de Egresos 32 500 2 400 2 400 2 400 2 400

Total 84 000 84 000 84 000 84 000 Tabla N° 36: Cuadro Flujo de Caja Económico.

Figura 78: Cuadro Flujo de Caja Económico.

5.2.1.5. ANÁLISIS DE FACTIBILIDAD

5.2.1.5.1. Valor Actual Neto

Para determinar la viabilidad del proyecto, se debe estudiar en

cuantos años se recuperar la inversión realizada inicialmente y si esta

inversión es retornada en un periodo de año fijo previamente.

0

1

2

3

4

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

Total deIngresos Total de

EgresosTotal

0

1

2

3

4


144

Para esto emplearemos la VAN (Valor Actual Neto) que permite calcular

el valor presente de un determinado monto.

representa los flujos de caja en cada periodo t.

es el valor del desembolso inicial de la inversión.

es el número de períodos considerado.

El tipo de interés es k. Si el proyecto no tiene riesgo, se tomará

como referencia el tipo de la renta fija, de tal manera que con el VAN se

estimará si la inversión es mejor que invertir en algo seguro, sin riesgo

específico. En otros casos, se utilizará el coste de oportunidad es 15%.

( ( ) ) ( ( ) )

353 260.025

El proyecto será viable porque el Valor Actual Neto es 353 260

mayor a 0. Demostrando que financieramente el proyecto es factible.

5.2.1.5.2. Tasa de Interés de Retorno

Mide el rendimiento de los fondos invertidos. Representa la máxima

tasa de interés que puede pagarse por los fondos a invertir sin obtener

ganancias. La tasa interna de retorno se calcula de la siguiente forma:

es el Flujo de Caja en el periodo t.

http://es.wikipedia.org/wiki/Coste_de_oportunidad

http://es.wikipedia.org/wiki/Flujo_de_Caja


145

es el número de periodos.

es el valor de la inversión inicial.

Remplazando obtenemos:

El proyecto es rentable porque la tasa refleja el costo de oportunidad

del capital de (15%) es menor que la TIR (257%).

Lo anterior demuestra que financieramente el proyecto es factible.

5.2.2. FACTIBILIDAD TÉCNICA

Para determinar la viabilidad de la solución analizaremos si las

tecnologías usadas justifican las capacidades técnicas requeridas bajo las

estrategias de hardware y software.

5.2.2.1. ESTRATEGIA DE HARDWARE

El hardware necesario para la implementación de esta solución es

accesible y de bajo costo en el mercado, habiendo una gran gama de

opciones en marcas y modelos.

5.2.2.2. ESTRATEGIA DE SOFTWARE

El software a utilizar son en parte es software gratuito como el

lenguaje de programación Java y licenciado como el administrador de

base de datos SQL Server 2008 r2, cabe resaltar que la empresa ya

cuenta con licencia, así que no ocasionaría un gasto extra.

5.2.3. FACTIBILIDAD OPERATIVA

Para determinar la aceptabilidad de la solución y el grado de

satisfacción del usuario, respecto a la funcionalidad de la solución


146

propuesta, se consideró la necesidad y deseo de un cambio en la forma de

cómo se estaba llevando a cabo los procesos de monitoreo de residuos,

expresada por los usuarios y el personal involucrado. Esto llevo a la

aceptación de la solución propuesta, por lo amigable y sencillo de la

solución, cubriendo todos sus requerimientos, expectativas y

proporcionando la información en forma oportuna y confiable. Basado en

entrevistas y conversaciones los usuarios finales consideraron lo

siguiente:

La navegabilidad de las ventanas del sistema es ágil y amigable.

La usabilidad de la solución es satisfactoria.

La escalabilidad de sistema es flexible.

Esto se traduce a una solución de fácil manejo y comprensión,

bastante intuitivo ya que posee la misma apariencias que soluciones de

escritorio. La adaptabilidad para cualquier mejora continua de la solución

es un factor importante que se tomó en cuenta.

5.2.4. FACTIBILIDAD ORGANIZACIONAL

Como parte de su constante innovación, se tiene contemplada la

necesidad de la implementar este tipo de soluciones a las diferentes áreas

de la empresa.

Como se menciona en el plan estratégico de la organización al 2020. La

misma que se centra en la implementación de sistemas de información y

el uso de tecnología de punta.


147

5.3. ANÁLISIS E INTERPRETACIÓN DE RESULTADOS

Para la realización de este estudio se aplicaron encuestas al personal

involucrado en el proceso ambienta (Ver ANEXO N° 6).

A continuación se mostrara los resultados obtenidos a través de los

cuestionarios en cuanto a la Optimización del Control de Residuos

Sólidos de la Compañía de Minas Buenaventura S.A.C que son de gran

utilidad para responder a las preguntas del presente trabajo de

investigación.

El criterio que se empleó para interpretar los resultados de la

encuesta fue la escala de Likert donde:

Totalmente en desacuerdo 1

En desacuerdo. 2

Ni acuerdo ni desacuerdo. 3

De acuerdo. 4

Totalmente de acuerdo. 5

5.3.1. PRUEBA DE HIPÓTESIS

La prueba de hipótesis determina si la hipótesis es congruente con

los datos obtenidos en la muestra (Ver ANEXO N° 6).

A continuación plateamos la hipótesis alternativa y la hipótesis nula.

Hipótesis Alternativa:

Hi = La Implementación de un Sistema Web basado en la Metodología

Rational Unified Process permitirá Optimizar el Control de Residuos

Sólidos de la compañía de Minas Buenaventura S.A.C. – Lima.

Hipótesis Nula:


148

Ho = La Implementación de un Sistema Web basado en la Metodología

Rational Unified Process no permitirá Optimizar el Control de Residuos

Sólidos de la compañía de Minas Buenaventura S.A.C. – Lima.

5.3.2. ANÁLISIS DE FIABILIDAD DEL INSTRUMENTO DE

MEDICIÓN

N %

Casos

Válidos 68 100,0

Excluidosa 0 ,0

Total 68 100,0

a. Eliminación por lista basada en todas las variables del procedimiento.

Tabla N° 37 Resumen del procesamiento de los casos.

Alfa de Cronbach N de elementos

0,842 20 Tabla N° 38 Estadísticos de fiabilidad.

El alfa de Cronbach es 0,842, se considera que valores del alfa superiores

a 0,7 son suficientes para garantizar la fiabilidad de la escala.

Estadísticos total-elemento

Media de

la escala

si se

elimina el

elemento

Varianza

de la

escala si

se elimina

el

elemento

Correlación

elemento-

total

corregida

Correlaci

ón

múltiple

al

cuadrado

Alfa de

Cronbac

h si se

elimina el

elemento

Edad 72,70 31,844 ,666 . ,798

Sexo 74,10 37,878 ,615 . ,817

Nivel de Instrucción 72,20 34,233 ,680 . ,812

Tiempo Generación

Reporte 72,80 37,289 ,768 . ,802

Disponibilidad de la

Información 72,90 38,767 ,470 . ,822

Tiempo Consulta

Residuos Solidos 72,50 33,167 ,568 . ,817


149

Acceso a la

Información 71,30 40,900 ,181 . ,832

Registro Optimo 70,10 45,656 -,554 . ,857

Rapidez de Consultas 71,10 38,767 ,470 . ,822

Acceso Remoto a la

Información 70,40 41,600 ,087 . ,834

Transparencia de las

operaciones 61,50 61,167 ,110 . ,835

Manejo de Errores 71,20 38,400 ,572 . ,819

Amigabilidad del

Sistema 71,50 34,500 ,908 . ,799

Navegabilidad 71,30 38,233 ,438 . ,823

Optimo Control 71,40 41,600 ,087 . ,834

Optimo Sistema 71,10 39,878 ,293 . ,829

Tiempo Registro

Residuo Solido 71,80 37,289 ,768 . ,812

Rapidez de Petición 71,00 38,000 ,581 . ,818

Flexibilidad 71,10 45,878 -,585 . ,858

Acceso 73,30 31,789 ,632 . ,812 Tabla N° 39 Estadísticos total-elemento.

5.3.3. PRUEBA CHI CUADRADO PARA LA HIPÓTESIS

PRINCIPAL

Se presenta el resumen del procesamiento de los casos:

Casos

Válidos Perdidos Total

N Porcentaje N Porcentaje N Porcentaje


Información * Optimo

Sistema

68 100,0% 0 0,0% 68 100,0%


Optimo Sistema Total

De acuerdo. Totalmente

de acuerdo.

Disponibilidad de

la Información

De acuerdo. 20 12 32

Totalmente

de acuerdo. 8 20 28

Total 28 32 68 Tabla N° 41 Contingencia Disponibilidad de la Información * Optimo Sistema.


150

Valo

r

gl

Sig

. asintó

tica

(bilateral)

Sig

. exacta

(bilateral)

Sig

. exacta

(unilateral)

Chi-cuadrado de Pearson ,278a 1 ,598

Corrección por continuidad b

,000 1 1,000

Razón de verosimilitudes ,275 1 ,599

Estadístico exacto de Fisher 1,000 ,548

Asociación lineal por lineal ,250 1 ,617

N de casos válidos 68

a. 4 casillas (100,0%) tienen una frecuencia esperada inferior a 5. La frecuencia mínima esperada

es 1,60.

b. Calculado sólo para una tabla de 2x2.

Tabla N° 42 Pruebas de chi-cuadrado.

La columna titulada "Sig" (Significado). Esta es la información más

importante en la tabla. Te indica si el análisis de chi-cuadrado fue

significativo, es decir, si los resultados se deben a la variable predictora o

al azar. Si el sig. es inferior a 5, se considera significativo, lo que

significa que hay menos de cinco posibilidades de cada 100 que los

resultados se deban a la casualidad.

INTERPRETACIÓN: Se concluye que existe relación entre ambas

variables, entonces se rechaza la hipótesis nula, la que afirma que La

Implementación de un Sistema Web basado en la Metodología

Rational Unified Process no permitirá Optimizar el Control de

Residuos Sólidos de la compañía de Minas Buenaventura S.A.C. –

Lima por lo que queda comprobado la Hipótesis General planteada en el

presente trabajo de investigación.


151

5.3.4. PRUEBA DE HIPÓTESIS PARA LAS HIPÓTESIS

ESPECIFICAS

IDENTIFICACIÓN DE VARIABLES

Variable independiente (X):

X: Sistema Web.

Variable dependiente (Y):

Y: Optimizar el Control de los Residuos Sólidos.

INDICADORES DE LA VARIABLE INDEPENDIENTE

Exactitud.

Amigabilidad.

Portabilidad.

Flexibilidad.

INDICADORES DE LA VARIABLE DEPENDIENTE

Rapidez.

Eficiencia.

Disponibilidad.

Resumen del procesamiento de los casos

Casos



Optimo Control *

Rapidez de Petición 68 100,0% 0 0,0% 68 100,0%



152

Tabla de contingencia Optimo Control * Rapidez de Petición

Recuento

Rapidez de Petición Total

De

acuerdo.

Totalmente

de acuerdo.

Optimo Control


Totalmente de

acuerdo. 20 14 34

Total 34 34 68 Tabla N° 44 Tabla de contingencia Optimo Control * Rapidez de Petición.

Pruebas de chi-cuadrado

V

alor

gl

Sig

. asintó

tica

(bilateral)

Sig

. exacta

(bilateral)

Sig

. exacta

(unilateral)

Chi-cuadrado de Pearson 1,111a 1 ,292

Corrección por continuidadb ,000 1 1,000

Razón de verosimilitudes 1,500 1 ,221

Estadístico exacto de Fisher 1,000 ,500

Asociación lineal por lineal 1,010 1 ,317


a. 4 casillas (100,0%) tienen una frecuencia esperada inferior a 5. La

frecuencia mínima esperada es ,50.

b. Calculado sólo para una tabla de 2x2. Tabla N° 45 Pruebas de chi-cuadrado.



Determinación del Nivel de Control de los Residuos Sólidos

permitirá conocer la situación actual de la Compañía de Minas

Buenaventura S.A.C. – Lima por lo que queda comprobado la

Hipótesis Especifica planteada en el presente trabajo de investigación.


153


Casos




Información *

Registro Optimo

68 100,0% 0 0,0% 68 100,0%


Tabla de contingencia Disponibilidad de la Información * Registro

Optimo

Recuento

Registro Optimo Total

De

acuerdo.

Totalmente

de acuerdo.


Información


Totalmente de

acuerdo. 23 12 35

Total 38 30 68 Tabla N° 47 Tabla de contingencia Disponibilidad de la Información * Registro Optimo.


Valo

r

gl

Sig

. asintó

tica

(bilateral)

Sig

. exacta

(bilateral)

Sig

. exacta

(unilateral)


Corrección por

continuidadb

1,300 1 ,23


Estadístico exacto de Fisher ,19 ,12



a. 4 casillas (100,0%) tienen una frecuencia esperada inferior a 5.

La frecuencia mínima esperada es 1,60. Tabla N° 48 Pruebas de chi-cuadrado.


variables, entonces se rechaza la hipótesis nula, la que afirma que El

Diseño y Desarrollo de un Sistema Web basado en la Metodología


154

Rational Unified Process permitirá Optimizar el Control de

Residuos Sólidos de la Compañía de Minas Buenaventura S.A.C. –

Lima por lo que queda comprobado la Hipótesis Especifica planteada en

el presente trabajo de investigación.


Casos



Tiempo Generación

Reporte * Optimo Sistema 68 100,0% 0 0,0% 68 100,0%


Tabla de contingencia Tiempo Generación Reporte * Optimo Sistema

Recuento

Optimo Sistema Total

De acuerdo. Totalmente

de acuerdo.

Tiempo Generación

Reporte

10 a 5 min 15 13 28

Menos de 5 min 23 17 40

Total 38 30 68 Tabla N° 50 Tabla de contingencia Tiempo Generación Reporte * Optimo Sistema.


Valo

r

gl

Sig

. asintó

tica

(bilateral)

Sig

. exacta

(bilateral)

Sig

. exacta

(unilateral)


Corrección por continuidadb ,980 1 ,324


Estadístico exacto de Fisher ,200 ,167



a. 4 casillas (100,0%) tienen una frecuencia esperada inferior a 5.

La frecuencia mínima esperada es 1,20. Tabla N° 51 Pruebas de chi-cuadrado.


155



Evaluación del Sistema Web de Residuos Sólidos permitirá conocer

la Optimización del Control de la Compañía de Minas

Buenaventura S.A.C. – Lima por lo que queda comprobado la Hipótesis

Especifica planteada en el presente trabajo de investigación.

5.4. TABLA DE TIEMPOS (ANTES Y DESPUÉS) DE LA

IMPLEMENTACIÓN.

Los datos mostrados a continuación son el promedio de tiempos en

minutos en realizar diferentes actividades antes y después de la

implementación del sistema web, estos datos se recolectaron mediante una

encuentras realizada a la muestra, empleado para ello la herramienta de

Google Form como se muestra en el ANEXO N° 2.

Tabla de tiempos (Antes

y después) en minutos.

Antes Después

Registrar de Residuo Sólido. 15 3

Registrar de Puntos de almacenamiento. 10 2

Registrar de Transporte final. 8 2

Registrar de EPS/EC. 8 1

Modificar Residuo Generado. 8 1

Modificar Puntos de almacenamiento 10 3

Modificar Transporte final. 10 3

Consultar Residuo generado. 11 2

Consultar Puntos de almacenamiento. 11 2

Consultar Transporte final. 11 2

Consultar EPS/EC. 12 2

Eliminar Residuo Generado. 12 1


156

Eliminar Puntos de almacenamiento 10 1

Eliminar Transporte final. 11 1

Generar Informe de Generación de

Residuos. 10 2

Emisión de reportes. 30 2 Tabla N° 52 Tabla de tiempos (Antes y después)

Figura 79: Grafico de tiempos (Antes y después)

El promedio y la mediana general en realizar dichas actividades se

muestran a continuación en la siguiente tabla:

Antes (Min.) Después (Min.)

Promedio 11.6875 1.875

Mediana 10.5 2 Tabla N° 53 Promedio y mediana de tiempos (Antes y después)

0

5

10

15

20

25

30R

egi

stra

r d

e R

esid

uo

Só

lido

.

Re

gist

rar

de

Pu

nto

s d

e…

Re

gist

rar

de

Tra

nsp

ort

e…

Re

gist

rar

de

EP

S/EC

.

Mo

dif

icar

Res

idu

o…

Mo

dif

icar

Pu

nto

s d

e…

Mo

dif

icar

Tra

nsp

ort

e f

inal

.

Co

nsu

ltar

Res

idu

o…

Co

nsu

ltar

Pu

nto

s d

e…

Co

nsu

ltar

Tra

nsp

ort

e f

inal

.

Co

nsu

ltar

EP

S/EC

.

Elim

inar

Re

sid

uo

…

Elim

inar

Pu

nto

s d

e…

Elim

inar

Tra

nsp

ort

e fi

nal

.

Gen

erar

Info

rme

de…

Emis

ión

de

rep

ort

es.

Antes

Después


157

Figura 80: Promedio y mediana de tiempos (Antes y después)

Interpretación: El realizar una actividad antes de la implementación

del sistema web en promedio lleva 11.68 minutos con una mediana de 10.5,

luego de la implementación del sistema web los tiempos se reducen a 1.87

minutos en promedio y teniendo una media de 2 minutos. Lo que significa que

luego de la implementación del sistema web, las actividades realizadas por el

personal tomaron menos tiempo en realizarse, logrando de esta forma

optimizar el Control de Residuos Sólidos.

05

1015

Promedio

Mediana

Después (Min.)

Antes (Min.)


158

CONCLUSIONES

Como consecuencia del trabajo realizado se ha llegado a las siguientes

conclusiones:

Se pudo establecer los objetivos planteados al iniciar este trabajo de

investigación, teniendo como resultado final la implementación y correcto

funcionamiento del sistema web de residuos sólidos.

El sistema web desarrollado ayudara al personal de la compañía de minas

Buenaventura a optimizar el proceso de control de residuos sólidos.

Se logró optimizar el proceso de control de residuos sólidos. Dicha mejora

permitió agilizar las labores del personal de la unidad minera. Reduciendo el

tiempo en el registro de los residuos generados y la generación de reportes de los

mismos.

Se logró el análisis, diseño e implementación del sistema de web de

residuos sólidos y el desarrollo del modelo físico de datos que soporta la solución

realizada, que permite almacenar la información que se obtendrá de dicho sistema.

La participación de los usuarios ha sido clave para el éxito del desarrollo del

sistema. La evaluación previa de los prototipos del sistema por parte de los

usuarios, permitió eliminar tiempos perdidos en la fase de construcción del

producto de software por modificaciones en la interfaz o en las funcionalidades.

El adecuado análisis de riesgo permitió que se pudiera llevar a cabo el

desarrollo e implementación del sistema web dentro de los tiempos establecidos y

los costos previstos.


159

RECOMENDACIONES

Debido a que la metodología RUP promueve el desarrollo incremental de

los proyectos, las mejoras que se proponen en esta sección son totalmente viables.

Integrar el sistema web de residuos sólidos a los demás sistemas de gestión

ambiental de la compañía de minas Buenaventura.

Implementar reportes dinámicos, para una mayor visualización de la

información y aprovechamiento de la misma.

El manejo de roles de acceso por modulo tanto de solo lectura y el de

manipulación de datos.

Generar una versión móvil para una mayor accesibilidad mediante tabletas

y Smartphone.


160

FUENTES BIBLIOGRÁFICAS

A., M. (1993). Concepción y diseño de base de datos. Del modelo E/R al

modelo relacional. Madrid.

Capers, J. (2000). Assessment and control of Software Risk, upper saddle

river. En J. Capers.

Fernadez, V. (2005). Desarrollo de Sistemas de Información. En V. Fernadez,

Desarrollo de Sistemas de Información (pág. 11). Lima: Cargraphics.

Ferrando, M. (2007). Gestion y minimizacion de residuos. Madrid: FC

Editorial.

Gonzáles., J. A. (2005). Sistemas de Información Medioambiental. En J.

Taboada, & J. Cotos, Sistemas de Información Medioambiental (pág. 3). Madrid:

Gesbiblo.

J.A., S. (1992). Analisis y Diseño de sistemas de Información . Mexico DF.

Jacaboson, I. B. (2000). El Proceso Unificado de Desarrollo de Software.

Addison Wesley .

Kruchten, P. (2000). The Rational Unified Process: An Introduction. Addison

Wesley .

MAGERIT. (2006). Metodologia de Análisis y Gestión de Riesgos de los

Sistemas de Información. Madrid.

Montes, J. (2001). Medio Ambiente y desarrollo Sostenible. Madrid: Comillas.

Ochoa, M. (2008). Ciudades ambientalmente sostenibles. Rosario:

Universidad del Rosario.

Pet, V. (2002). Sistema de Información con capacidad de análisis y

multicriterio para ayuda ala toma de decisiones en la gestion de los medios aéreos.

Santiago de Compostela.

Rational Software Corporation. (2002). Product: Rational Software

Corporation.

Rational Software Corporation. (1998). Rational Unified Process. Best

Practices for Software Development Teams.

The Association for Computing (ACM). (2005). Currículo de Computación.


161

FUENTES ELECTRÓNICAS

(FAO), L. O. (2012). La Organización de las Naciones Unidas para la

Alimentación y la Agricultura (FAO) . Obtenido de

http://www.fao.org/docrep/007/ad818s/ad818s08.htm

Ley General de Residuos Sólidos. (08 de Junio de 2008). Recuperado el 24 de

Enero de 2013, de Ministerio de Energia y Minas:

http://www.minem.gob.pe/minem/archivos/file/DGAAM/legislacion/Ley%2027314%

20Ley%20General%20de%20Residuos%20S%C3%83%C2%B3lidos.pdf

Compañia de Minas Buenaventura S.A.A. (07 de Junio de 2012).

Buenaventura - Cronologia. Recuperado el 20 de Enero de 2013, de

http://www.buenaventura.com/

DEFENSORÍA DEL PUEBLO. (31 de Enero de 2013). DEFENSORÍA DEL PUEBLO.

Recuperado el 24 de Febrero de 2013, de DEFENSORÍA DEL PUEBLO:

http://www.defensoria.gob.pe/conflictos-sociales/objetos/paginas/6/52reporte-

mensual-conflictos-sociales-107-enero-2013.pdf

Diario El Comercio. (01 de Diciembre de 2012). elcomercio.pe. Recuperado el

24 de febrero de 2013, de elcomercio.pe:

http://elcomercio.pe/actualidad/1523617/noticia-defensoria-pueblo-conflictos-

sociales-dejaron-24-muertos-durante-2012

OSINERGMIN. (Diciembre de 2012). Osinergmin. Recuperado el Enero de

2013, de

http://srvapp03.osinerg.gob.pe:8888/snl/normaPortalGeneral.htm?_formAction=sho

w&_id=119


162

ANEXOS

ANEXO N° 1 Reporte de Generación de Informe de Residuos Sólidos.


163

ANEXO N° 2 Encuesta para la toma de tiempos antes y después de la implementación

web.

Link: http://goo.gl/sdkfKJ


164

ANEXO N° 3 MATRIZ DE CONSISTENCIA

TÍTULO: Sistema Web de Residuos Sólidos

PROBLEMA OBJETIVO HIPÓTESIS MARCO TEÓRICO VARIABLES INDICADORES METODOLOGÍA

FORMULACIÓN PROBLEMA PRINCIPAL OBJETIVO GENERAL HIPÓTESIS GENERAL

Sistema Web.

Metodología

Rational Unified

Process.

Control de

Residuos Sólidos.

INDEPENDIENTE

X: Sistema de

Web

X1:Exactitud

X2:Flexibilidad

X3: Portabilidad.

X3: Amigabilidad.

Tipo de Investigación:

Aplicada y Pre

Experimental.

Diseño de Investigación:

Explicativo Experimental.

Población: Compañía de

Minas Buenaventura

S.A.C. -Lima

Muestra: 68 Individuos.

Técnicas:

Análisis Documental

Observación

Encuestas

Instrumentos:

Plan Estratégico y Plan

Operativo de la Compañía

de Minas Buenaventura

S.A.C.

¿En qué medida la Implementación de un Sistema Web basado en la Metodología Rational Unified Process permitirá Optimizar el Control de Residuos Sólidos de la Compañía de Minas Buenaventura S.A.C. - Lima?

Implementar un Sistema Web basado en la Metodología Rational Unified Process para Optimizar el Control de Residuos Sólidos de la Compañía de Minas Buenaventura S.A.C. – Lima.

La Implementación de un Sistema Web basado en la Metodología Rational Unified Process permitirá Optimizar el Control de Residuos Sólidos de la compañía de Minas Buenaventura S.A.C. – Lima.

PROBLEMAS ESPECÍFICOS OBJETIVOS ESPECÍFICOS HIPÓTESIS ESPECÍFICAS DEPENDIENTE

Y:Optimización

del Control de

Residuos Sólidos

Y1: Disponibilidad

Y2: Rapidez

Y3: Eficiencia.

¿En qué medida la determinación del nivel de Control de los Residuos Sólidos permitirá conocer la situación actual de la Compañía de Minas Buenaventura S.A.C. - Lima?

Determinar el nivel de Control de los Residuos Sólidos que permita conocer la situación actual de la Compañía de Minas Buenaventura S.A.C. – Lima.

La Determinación del Nivel de Control de los Residuos Sólidos permitirá conocer la situación actual de la Compañía de Minas Buenaventura S.A.C. – Lima.

¿En qué medida el Diseño y Desarrollo de un Sistema Web basado en la Metodología Rational Unified Process permitirá Optimizar el Control Residuos Sólidos de la Compañía de Minas Buenaventura S.A.C. - Lima?

Diseñar y Desarrollar un Sistema Web basado en la Metodología Rational Unified Process que permita Optimizar el Control de Residuos Sólidos de la Compañía de Minas Buenaventura S.A.C.

El Diseño y Desarrollo de un Sistema Web basado en la Metodología Rational Unified Process permitirá Optimizar el Control de Residuos Sólidos de la Compañía de Minas Buenaventura S.A.C. – Lima.

¿En qué medida la Evaluación del Sistema Web de Residuos Sólidos permitirá conocer la Optimización del Control de la Compañía de Minas Buenaventura S.A.C. - Lima?

Evaluar el Sistema Web de Residuos Sólidos que permita conocer la Optimización del Control de la Compañía de Minas Buenaventura S.A.C.

La Evaluación del Sistema Web de Residuos Sólidos permitirá conocer la Optimización del Control de la Compañía de Minas Buenaventura S.A.C. – Lima.


165

ANEXO N° 4 ENCUESTA

1. Sexo:

a.) Masculino. b.) Femenino.

2. Edad:

a.) Menor de 20 años. b.) 20 a 30 años. c.) 30 a 40 años. d.) Mayor de 40 años.

3. Nivel de Instrucción:

a.) Primaria. b.) Secundaria. c.) Universidad. d.) Maestría

4. ¿Desde qué dispositivo accede a internet normalmente?

a.) Smartphone. b.) Computadora de Escritorio. c.) Laptop. d.) Tablet.

5. Cuanto tiempo emplea actualmente en la generación de reportes de generación de residuo. a.) Más de 20 min. b.) 10 a 20 min. c.) 10 a 5 min. d.) Menos de 5 min.

6. Cuanto tiempo le emplea actualmente en el registro de los diferentes residuos sólidos. a.) Más de 20 min. b.) 10 a 20 min. c.) 10 a 5 min. d.) Menos de 5 min.

7. Cuanto tiempo le emplea en la consulta de los residuos sólidos generados. a.) Más de 20 min. b.) 10 a 20 min. c.) 10 a 5 min. d.) Menos de 5 min.

Ley

end

a.

Totalmente en desacuerdo 1

En desacuerdo. 2

Ni acuerdo ni desacuerdo. 3

De acuerdo. 4

Totalmente de acuerdo. 5

Marca con una (X)

Preguntas Escala

1 2 3 4 5

8 ¿La disponibilidad de la información sobre los residuos generados es inmediata?

9 ¿La rapidez con la que se consulta la información sobre los residuos generados es la adecuada?

10 ¿El acceso a la información sobre la generación de residuos sólidos es el más óptimo?

11 ¿El registro de los residuos generados y sus respectivos puntos de almacenamiento se hacen de manera óptima?

12 ¿Puede acceder de manera remota a la información respecto a la generación de residuos sólidos?

13 ¿El nivel de transparencia de las operaciones del sistema crees que es el más

indicado?

14 ¿Las respuestas de las peticiones al sistema son de manera inmediata?

15 ¿El manejo de errores y excepciones es el correcto?

16 ¿La navegación por el sistema fue de una manera intuitiva?

17 ¿Considera amigable las interfaces del sistema?

18 ¿Se sintió cómodo en la navegación del sistema web?

19 ¿Crees que se realiza de manera adecuada el control de residuos sólidos actualmente?

20 ¿Se sintió cómodo con el sistema web?


166

ANEXO N° 5 MODELO DE ENTREVISTA

1. Datos de identificación del puesto de trabajo

Departamento:

Nombre del puesto:

Persona entrevistada:

Antigüedad en el puesto:

Dirección laboral:

Teléfono laboral:

2. Datos sobre la entrevista

Analista:

Fecha de realización:

3. Organigrama del puesto

Nombre del puesto del que depende o superior jerárquico:

Nombre y nº de puesto/s que dependen de él o subordinados:

4. Resumen del puesto

5. Funciones básicas incluidas en el puesto de trabajo

N° Funciones básicas

1

2

3

6. Tareas incluidas en cada función básica

Descripción de cada una de las tareas incluidas en el puesto: Cada tarea deberá ir incluida

en su función correspondiente.

Duración y frecuencia de la tarea: Porcentaje de tiempo que se dedica a cada una de las

tareas que se han descrito y frecuencia con que se lleva a cabo (diario, semanal, mensual o

anual).

Función Nº tarea Duración Frecuencia

7. Experiencia previa

8. Responsabilidad


167

ANEXO N° 6 MATRIZ DE DATOS DE ENCUESTA


168

MIEMBROS DEL JURADO EVALUADOR

____________________________________ __________________________________

Ing. ALEJANDRO MANUEL SALAZAR SANTIBÁNEZ Ing. ANA DORIS MAGDALENA BARRERA LOZA

PRESIDENTE SECRETARIO

____________________________________ __________________________________

Ing. JORGE MARTÍN FIGUEROA REVILLA Ing. JUAN CARLOS MEYHUAY FIDEL

VOCAL ASESOR

Sistema Web de Residuos Sólidos PRESENTADO POR Jose Remigio Leandro

Documents

Transcript of Sistema Web de Residuos Sólidos PRESENTADO POR Jose Remigio Leandro