facultad de ingeniería de sistemas y electrónica

121
1 Facultad de Ingeniería de Sistemas y Electrónica Carrera Profesional de Ingeniería de Sistemas e Informática Informe de Suficiencia Profesional para optar el Título Profesional de Ingeniero de Sistemas e Informática “ANÁLISIS, DESARROLLO E IMPLEMENTACIÓN DEL MÓDULO DE CONSUMOS ADVANCE REAL ESTATE - REAL PLAZA” Bachilleres: Jhon Edson Tello Lumbreras Lima – Perú 2016

Upload: others

Post on 15-Oct-2021

3 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Facultad de Ingeniería de Sistemas y Electrónica

1

Facultad de Ingeniería de Sistemas y Electrónica

Carrera Profesional de Ingeniería de Sistemas e Informática

Informe de Suficiencia Profesional para optar el Título Profesional de Ingeniero de Sistemas e

Informática

“ANÁLISIS, DESARROLLO E IMPLEMENTACIÓN DEL MÓDULO DE

CONSUMOS ADVANCE REAL ESTATE - REAL PLAZA”

Bachilleres:

Jhon Edson Tello Lumbreras

Lima – Perú 2016

Page 2: Facultad de Ingeniería de Sistemas y Electrónica

2

Page 3: Facultad de Ingeniería de Sistemas y Electrónica

3

Facultad de Ingeniería de Sistemas y Electrónica

Carrera Profesional de Ingeniería de Sistemas e Informática

Informe de Suficiencia Profesional para optar el Título Profesional de Ingeniero de Sistemas e

Informática

“ANÁLISIS DESARROLLO E IMPLEMENTACIÓN DEL MÓDULO DE

CONSUMOS ADVANCE REAL ESTATE - REAL PLAZA”

Bachilleres:

Jhon Edson Tello Lumbreras

Lima – Perú 2016

Page 4: Facultad de Ingeniería de Sistemas y Electrónica

4

Dedicatoria Dedico el presente trabajo para optar el título profesional en ingeniaría de sistemas a mis padres, quienes estuvieron día a día recalcándome la importancia de los estudios para desarrollarse y tener éxito en la vida.

Page 5: Facultad de Ingeniería de Sistemas y Electrónica

5

Agradecimientos A dios por darme buenos padres. A mi madre por enseñarme que con mucha perseverancia se llega lejos y jamás darse por vencido. A mi padre por brindarme los valores que se necesitan en el día a día. A mis hermanas Carol y Jade por darme el amor y cariño que se necesita siempre para poder continuar con mis metas.

Page 6: Facultad de Ingeniería de Sistemas y Electrónica

6

Resumen

El presente documento detalla el análisis desarrollo e implementación de un módulo que gestione de forma automática los consumos básicos como agua y electricidad para la empresa Real Plaza, el cual solo está disponible en la intranet de la empresa.

El documento en mención se encuentra dividido en cuatro capítulos, las cuales en cada uno de ellos se explican las actividades llevadas en cada una de las fases del módulo de consumos.

En el primer capítulo de este documento se define el objetivo general, los objetivos específicos, el alcance, limitaciones, justificación y estado del arte para dar solución a la problemática planteada. En el segundo capítulo se sustenta las metodologías y tecnologías que se aplicaron en el proyecto y la importancia de su uso. En el tercer capítulo se presenta el diseño de la solución propuesta. En el cuarto capítulo se describen y justifica la viabilidad del proyecto y finalmente se mencionan conclusiones para trabajos futuros relacionados al tema planteado en el presente informe de suficiencia profesional.

En las principales funcionalidades del sistema se encuentran:

• El módulo realizará el tratamiento de la información y los cálculos respectivos. • El módulo alertará mediante correos excesos en los consumos de agua y electricidad. • El módulo generará de forma automática sustentos de todos los locatarios. • El módulo enviará correos a los locatarios si su tarifa ha cambiado debido a los excesos en

los consumos en el periodo en curso.

Page 7: Facultad de Ingeniería de Sistemas y Electrónica

7

Carta de la empresa

Page 8: Facultad de Ingeniería de Sistemas y Electrónica

8

Contenido CAPÍTULO 1 ..................................................................................................................................... 14

ASPECTOS GENERALES.............................................................................................................. 14

1.1 Definición del Problema ...................................................................................................... 14

1.1.1 Descripción del Problema ................................................................................................ 14

1.1.2 Formulación del Problema .............................................................................................. 15

1.2 Definición de Objetivos ....................................................................................................... 15

1.2.1 Objetivo General ............................................................................................................. 15

1.2.2 Objetivos Específicos ....................................................................................................... 15

1.2.3 Alcance y Limitaciones .................................................................................................... 16

1.2.4 Justificación ..................................................................................................................... 16

1.2.5 Estado del Arte ................................................................................................................ 16

CAPÍTULO 2 ..................................................................................................................................... 21

MARCO TEÓRICO ........................................................................................................................... 21

2.1 Fundamento Teórico ........................................................................................................... 21

2.2 Metodología Proceso Unificado de Rational – RUP ............................................................ 21

2.3 Modelo UML ........................................................................................................................ 23

2.3.1 Diagrama de caso de uso ................................................................................................ 23

2.3.2 Diagrama de clases .......................................................................................................... 24

2.3.3 Diagrama de secuencia ................................................................................................... 24

2.3.4 Diagrama de componentes ............................................................................................. 25

2.4 Metodología de desarrollo NCapas .................................................................................... 25

2.5 Lenguajes de desarrollo ...................................................................................................... 28

2.5.1 Lenguaje C#: .................................................................................................................... 28

2.6 SQL Server 2012 .................................................................................................................. 30

2.7 Tipos de energía .................................................................................................................. 35

2.8 Alícuotas .............................................................................................................................. 35

2.9 Pliego tarifario ..................................................................................................................... 35

CAPÍTULO 3 ..................................................................................................................................... 37

DESARROLLO DE LA SOLUCIÓN ............................................................................................... 37

3.1.1 Organigrama de la empresa Real Plaza ........................................................................... 37

3.2 Análisis de la solución .......................................................................................................... 38

3.2.1 Inicio ................................................................................................................................ 38

3.2.1.1 Documento visión ............................................................................................................ 38

3.2.1.2 Especificación de requerimientos ................................................................................... 38

3.3 Elaboración .......................................................................................................................... 49

Page 9: Facultad de Ingeniería de Sistemas y Electrónica

9

3.3.1 Diagrama Work Down Structure ..................................................................................... 49

3.3.2 Organigrama del proyecto .............................................................................................. 50

3.3.3 Matriz de interés StakeHolder ......................................................................................... 50

3.3.4 Plan de comunicaciones .................................................................................................. 51

3.3.5 Plan de riesgos................................................................................................................. 52

3.3.7 Plan de contingencia ....................................................................................................... 53

3.3.8 Diagrama de caso de uso ................................................................................................ 54

3.3.9 Diseño y funcionalidad de interfaces – Mockup .............................................................. 55

3.4 Construcción ........................................................................................................................ 68

3.4.1 Diagrama de clases .......................................................................................................... 68

3.4.2 Modelo de base de datos físico ...................................................................................... 69

3.4.3 Diagrama de secuencia ................................................................................................... 70

3.4.4 Diagrama de componentes ............................................................................................. 75

3.4.5 Pruebas ............................................................................................................................ 76

3.4.6 Mapa de comportamiento nivel Hardware ..................................................................... 76

CAPÍTULO 4 ..................................................................................................................................... 77

RESULTADOS .................................................................................................................................. 77

4.1 Resultados de los objetivos ................................................................................................. 77

4.1.1 Presupuesto..................................................................................................................... 89

4.1.1.1 Flujo de caja ..................................................................................................................... 89

4.1.1.2 Flujo de caja RRHH .......................................................................................................... 91

4.1.1.3 Flujo de caja del proyecto ............................................................................................... 92

4.1.1.4 Flujo de sueldos ............................................................................................................... 93

4.1.1.5 Flujo de ingresos y egresos ............................................................................................. 93

4.1.1.6 VAN TIR ............................................................................................................................ 94

CONCLUSIONES ............................................................................................................................. 95

RECOMENDACIONES.................................................................................................................... 96

Page 10: Facultad de Ingeniería de Sistemas y Electrónica

10

Índice de Figuras

Fig. 1 Árbol de problema de la empresa Real Plaza. ......................................................................... 14 Fig. 2 Interface de registro de consumos. ........................................................................................... 18 Fig. 3 Interface de reporte de consumos. ............................................................................................ 18 Fig. 4 Fases de la metodología UML. .................................................................................................. 21 Fig. 5 Diagrama de caso de uso........................................................................................................... 24 Fig. 6 Diagrama de clases. ................................................................................................................... 24 Fig. 7 Diagrama de secuencia.............................................................................................................. 25 Fig. 8 Diagrama de componentes. ...................................................................................................... 25 Fig. 9 Arquitectura 3 Capas 3 niveles. ................................................................................................. 26 Fig. 10 Arquitectura 3 Niveles. ............................................................................................................ 28 Fig. 11 Aplicación web Clásica vs Ajax. ................................................................................................ 30 Fig. 12 Tablas relacionales. ................................................................................................................. 32 Fig. 13 Tabla primera forma normal. .................................................................................................. 33 Fig. 14 Tabla y entidades. .................................................................................................................... 33 Fig. 15 Tabla segunda forma normal. ................................................................................................. 34 Fig. 16 Tabla y entidades. .................................................................................................................... 34 Fig. 17 Tercera forma normal .............................................................................................................. 34 Fig. 18 Organigrama de la empresa Real Plaza. ................................................................................. 37 Fig. 19 Diagrama WBS Real Plaza. ...................................................................................................... 49 Fig. 20 Organigrama del proyecto consumos. .................................................................................... 50 Fig. 21 Diagrama de caso de uso Real Plaza. ...................................................................................... 54 Fig. 22 Interface de registro de alícuotas. ........................................................................................... 55 Fig. 23 Interface de registro de pliego tarifario. ................................................................................. 55 Fig. 24 Interface de Registro automático - Electricidad. ..................................................................... 56 Fig. 25 Interface principal de registro automático - Agua. ................................................................. 56 Fig. 26 Interface de registro de datos OLD. ......................................................................................... 57 Fig. 27 Interface relacionar. ................................................................................................................ 57 Fig. 28 Interface de visualización de historial...................................................................................... 58 Fig. 29 Interface principal de registro de consumos manual. ............................................................. 58 Fig. 30 Interface de generación de plantillas. ..................................................................................... 58 Fig. 31 Modelo de plantilla generada. ................................................................................................ 59 Fig. 32 Interface de registro de individual de consumos - Electricidad. .............................................. 59 Fig. 33 Interface de registro individual de consumos -Agua. .............................................................. 60 Fig. 34 Interface de registro de consumos masivo - Agua - Electricidad. ............................................ 60 Fig. 35 Interface de registro de fecha de cierre de consumos. ............................................................ 61 Fig. 36 Interface de visualización y reporte de consumos. .................................................................. 61 Fig. 37 Modelo de alerta de fecha límite para el registro de consumos. ............................................ 62 Fig. 38 Modelo de alerta de inmuebles con registros pendientes. ...................................................... 62 Fig. 39 Interface de visualización y generación de sustentos. ............................................................. 63 Fig. 40 Interface de registro de listas masivas. ................................................................................... 63 Fig. 41 Modelo de sustento eléctrico. .................................................................................................. 64 Fig. 42 Modelo de sustento agua. ....................................................................................................... 64 Fig. 43 Modelo de alerta primer aviso. ............................................................................................... 65 Fig. 44 Modelo de alerta segundo aviso. ............................................................................................ 66 Fig. 45 Modelo de alerta tercer aviso. ................................................................................................. 67 Fig. 46 Diagrama de clases. ................................................................................................................. 68

Page 11: Facultad de Ingeniería de Sistemas y Electrónica

11

Fig. 47 Modelo de Base de datos físico. .............................................................................................. 69 Fig. 48 Diagrama de secuencia registro de alícuotas.......................................................................... 70 Fig. 49 Diagrama de secuencia de registro de pliego tarifario. .......................................................... 70 Fig. 50 Diagrama de secuencia Registrar consumos – Electricidad. ................................................... 71 Fig. 51 Diagrama de secuencia Registrar consumos – Agua. .............................................................. 71 Fig. 52 Diagrama de secuencia Relacionar - Ver Historial. ................................................................. 72 Fig. 53 Diagrama de secuencia de envío de alertas. ........................................................................... 72 Fig. 54 Diagrama de secuencia de generación de plantilla y carga consumos masivos. .................... 73 Fig. 55 Diagrama de secuencia de registro consumo individual. ........................................................ 73 Fig. 56 Diagrama de secuencia de registro de fecha cierre................................................................. 74 Fig. 57 Diagrama de secuencia generación de reporte. ...................................................................... 74 Fig. 58 Diagrama de secuencia de envío de alerta de consumos excedidos. .................................... 75 Fig. 59 Diagrama de componentes. .................................................................................................... 75 Fig. 60 Diagrama de componentes. .................................................................................................... 76 Fig. 61 Diagrama Gantt Real Plaza. .................................................................................................... 77 Fig. 62 Organigrama del proyecto consumos. .................................................................................... 78 Fig. 63 Interface de registro de alícuotas. ........................................................................................... 80 Fig. 64 Interface de registro de pliego tarifario. ................................................................................. 80 Fig. 65 Interface de registro de consumos automático. ...................................................................... 81 Fig. 66 Interface Popup de registro de datos OLD. .............................................................................. 81 Fig. 67 Interface de visualización de historial...................................................................................... 82 Fig. 68 Interface de registro de sustento de consumo. ....................................................................... 82 Fig. 69 Interface de registro de relacionar. ......................................................................................... 83 Fig. 70 Interface de generación de plantillas. ..................................................................................... 83 Fig. 71 Registrar consumo individual - Electricidad............................................................................. 84 Fig. 72 Registrar consumo individual - Agua. ...................................................................................... 84 Fig. 73 Interface de carga de consumo masivo - Electricidad - Agua. ................................................. 85 Fig. 74 Interface de Registro de fecha cierre. ...................................................................................... 85 Fig. 75 Interface de Generación reporte. ............................................................................................. 86 Fig. 76 Interface de registro de lista masiva. ...................................................................................... 86 Fig. 77 Excel del reporte. ..................................................................................................................... 87 Fig. 78 Curva - Análisis costo vs tiempo.............................................................................................. 91 Fig. 79 Ingresos y egresos del proyecto. .............................................................................................. 96

Índice de Tablas

Tabla 1 Tabla del árbol de problemas de la empresa Real Plaza. ....................................................... 15 Tabla 2 Evolución de la base de datos relacional. ............................................................................... 31 Tabla 3 Tabla de tarifas de pliego tarifario. ........................................................................................ 36 Tabla 4 Tabla de requerimientos funcionales. .................................................................................... 38 Tabla 5 Tabla de requerimientos no funcionales. ............................................................................... 39 Tabla 6 Tabla de actores. .................................................................................................................... 39 Tabla 7 CU01 Registrar alícuotas ........................................................................................................ 40 Tabla 8 CU02 Registrar pliego tarifario ............................................................................................... 40 Tabla 9 CU03 Registrar consumos - Electricidad ................................................................................. 41 Tabla 10 CU04 Registrar consumos - Agua ......................................................................................... 42 Tabla 11 CU05 Registrar datos OLD .................................................................................................... 42

Page 12: Facultad de Ingeniería de Sistemas y Electrónica

12

Tabla 12 CU06 Relacionar ................................................................................................................... 43 Tabla 13 CU07 Ver Historial ................................................................................................................ 43 Tabla 14 CU08 Enviar alertas .............................................................................................................. 44 Tabla 15 CU09 Generar plantilla ......................................................................................................... 44 Tabla 16 CU10 Registrar consumo individual - Electricidad ................................................................ 45 Tabla 17 CU11 Registrar consumo individual - Agua .......................................................................... 45 Tabla 18 U12 Cargar consumo masivo - Electricidad - Agua .............................................................. 46 Tabla 19 CU13 Registrar fecha cierre .................................................................................................. 46 Tabla 20 CU14 Generar reporte .......................................................................................................... 46 Tabla 21 CU15 Enviar alerta consumo excedido ................................................................................. 47 Tabla 22 CU16 Registrar sustento ....................................................................................................... 48 Tabla 23 CU16 Mantener lista masiva. .............................................................................................. 48 Tabla 24 Matriz de interés – StakeHolder. .......................................................................................... 50 Tabla 25 Plan de comunicaciones. ...................................................................................................... 51 Tabla 26 Matriz de riesgos del proyecto. ............................................................................................ 52 Tabla 27 Leyenda de Riesgos e impacto. ............................................................................................. 52 Tabla 28 Plan de contingencia - GDH (Gestión del desarrollo humano). ........................................... 53 Tabla 29 Plan de contingencia - Finanzas. .......................................................................................... 53 Tabla 30 Cuadro comparativo de los procesos del área de operaciones. .......................................... 79 Tabla 31Flujo de caja - Materiales e insumos ..................................................................................... 89 Tabla 32Flujo de caja – Equipos .......................................................................................................... 89 Tabla 33 Flujo de caja - Licencias ........................................................................................................ 90 Tabla 34 Matriz de análisis costo vs tiempo. ...................................................................................... 90 Tabla 35 Flujo de caja - Recursos Humanos. ....................................................................................... 91 Tabla 36 Flujo de caja – egresos. ........................................................................................................ 92 Tabla 37 Sueldos por hora de los colaboradores................................................................................. 93 Tabla 38 Flujo de caja ingresos y egresos. .......................................................................................... 93 Tabla 39 Ingresos y egresos del proyecto............................................................................................ 94 Tabla 40 Glosario de términos............................................................................................................. 97

Page 13: Facultad de Ingeniería de Sistemas y Electrónica

13

Introducción A continuación se detalla en líneas generales el desarrollo del módulo de consumos web para la empresa Real Plaza S.R.L., el actual modulo desarrollado se asemeja a los siguientes sistemas desarrollados tales como:

o DISEÑO DE UN SISTEMA DE CONTROL DEL CONSUMO DE ENERGÍA ELÉCTRICA EN LAS COMUNIDADES CAMPESINAS - PONTIFICIA UNIVERSIDAD CATOLICA DEL PERU

o SISTEMA PARA LA GESTIÓN DEL USO DE LA ENERGÍA EN INSTITUCIONES PÚBLICAS – ESCUELA POLITÉCTNICA DE LA UNIVERSIDAD DE SAO PAULO

Para el desarrollo del módulo se empleó la metodología RUP el cual fue la opción más idónea pues el proyecto tuvo un prolongado tiempo de vida. Basándonos en la complejidad de la problemática (Deficiencia en los procesos que realiza el área de operaciones) se optó por la realización de un módulo que automatice los principales flujos de trabajo de área en mención.

El objetivo del presente documento, plasmar en una estructura cada fase o paso realizado para lograr la finalidad del módulo “Mejorar los procesos y tiempos del área de operaciones” de ayuda con las principales fuentes como:

o Real plaza – Área de operaciones o Osinergmin. o Wikipedia. o Microsoft. o Craig Larman – RUP.

Page 14: Facultad de Ingeniería de Sistemas y Electrónica

14

CAPÍTULO 1

ASPECTOS GENERALES

En el siguiente capítulo se realiza la descripción y formulación del problema. Se define el objetivo general, los objetivos específicos, el alcance, limitaciones, justificación y estado del arte.

1.1 Definición del Problema

1.1.1 Descripción del Problema

Descripción de la empresa:

Real Plaza es una empresa abocada en el rubro retail (Venta masiva de productos y servicios), fuertemente posicionada en todo el Perú. Tiene como principales clientes a:

• Saga Falabella. • Plaza Vea. • Renzo costa. • Ripley. • Oeschle. • KFC.

Problema:

El exceso de recursos y el lento flujo de trabajo en el área de operaciones que se encarga de recaudar la información de los consumos básicos a los locatarios se ha incrementado debido a la gran cantidad de la demanda, de tal manera que afecta a las áreas asociadas como Gestión Inmobiliaria - GI al realizar la facturación y los trámites respectivos.

Con la finalidad de identificar el problema central, se ha utilizado la técnica del árbol de problemas, cuyo gráfico se muestra a continuación.

Fig. 1 Árbol de problema de la empresa Real Plaza.

Fuente: (Elaboración propia).

Page 15: Facultad de Ingeniería de Sistemas y Electrónica

15

Tabla 1 Tabla del árbol de problemas de la empresa Real Plaza. TABLA DEL ÁRBOL DE PROBLEMAS

Descripción del problema: Deficiencia en los procesos que realiza el área de operaciones del centro comercial real plaza.

Causas Afectos • No cuenta con un proceso

automatizado. • Retraso y errores en el tratamiento

de información. • La demanda se ha incrementado. • Envío de información inválida al

locatario. • Desorganización en el área de

operaciones. • Sobrecarga de trabajo acumulado en

el área de GI. • Exceso de recursos en el área de

operaciones. Fuente: (Elaboración propia).

Idea de investigación:

¿Es posible desarrollar y adicionar un nuevo módulo en el sistema Advance, que permita reducir los tiempos y recursos en el flujo de trabajo del área de operaciones y asociados para la empresa Real Plaza?

1.1.2 Formulación del Problema Deficiencia en los procesos que realiza el área de operaciones en el centro comercial Real Plaza.

1.2 Definición de Objetivos

1.2.1 Objetivo General Analizar desarrollar e implementar un módulo web que se adicione al sistema de Información Advance ya existente y permita gestionar los consumos básicos de los locatarios de los centros comerciales del Real Plaza, utilizando la metodología Proceso Unificado de Rational – RUP.

1.2.2 Objetivos Específicos • Recaudar la información necesaria del área de operaciones para estimar los tiempos y

recursos para el análisis desarrollo e implementación del proyecto. • Desarrollar un plan de proyecto para el desarrollo del módulo de consumos. • Modelar mediante UML los procesos fundamentales del área de consumos. • Realizar el diseño de los prototipos del módulo de consumos. • Modelar mediante UML los diagramas lógico y físico del módulo. • Realizar las pruebas funcionales del módulo propuesto y realizar un registro de evidencias.

Page 16: Facultad de Ingeniería de Sistemas y Electrónica

16

1.2.3 Alcance y Limitaciones Alcances:

• El módulo realizará los cálculos respectivos para el tratamiento de los datos y convertirlos en información valida y exacta.

• El módulo validará la información ingresada al sistema de consumos básicos.

• El módulo generará reportes masivos PDF de los consumos de todos los locatarios y serán almacenados en una File Server para su posterior envío a los locatarios.

• El módulo alertará mediante un correo electrónico la fecha límite para el ingreso de los consumos a los asistentes de gerente de Mall.

• El módulo modificará automáticamente la cláusula de los consumos del contrato del locatario si es que se ha excedido por 3 veces su consumo normal por el tiempo que dure su contrato.

Limitaciones:

• El sistema no controlará que la información sea ingresada en la fecha correspondiente. • El sistema no recaudara la información de consumos de forma automática.

1.2.4 Justificación Con la culminación del proyecto se consiguió fluidez en el área de operaciones y actualmente brinda información correcta y confiable a área de GI (Gestión Inmobiliaria) con varios días de anticipación para poder realizar la facturación respectiva y los cobros por parte del área de cobranzas, a su vez se redujo recursos y por ende el presupuesto en el área de operaciones.

1.2.5 Estado del Arte En este punto se mencionan dos sistemas de información, que fueron desarrolladas para gestionar de forma eficiente los consumos eléctricos, los cuales se mencionan a continuación.

SISTEMA PARA LA GESTIÓN DEL USO DE LA ENERGÍA EN INSTITUCIONES PÚBLICAS – ESCUELA POLITÉCTNICA DE LA UNIVERSIDAD DE SAO PAULO

Resumen:

A continuación se presenta el desarrollo de un sistema de información para la gestión de energía en las entidades públicas. El sistema ContaLuzWeb es un instrumento de apoyo para los colaboradores públicos en el proceso de control y la toma de decisiones con respecto al consumo y despacho de energía eléctrica.

El Sistema planteado es adaptable a cualquier entidad pública o privada, de servicio o de producción. Obteniendo los resultados de forma estadística sean térmicos o eléctricos inclusive identificado por área puede analizarse la información obtenida, obtener un registro, comparar los

Page 17: Facultad de Ingeniería de Sistemas y Electrónica

17

indicadores según las áreas para que finalmente el equipo de gestión de energía de la entidad competente tome las medidas necesarias. Gracias al equipo de apoyo para el sistema ContaLuzWeb fue posible el desarrollo del programa llamado PureUSP, el cual ha permitido lograr incitar el uso adecuado de la energía en la universidad de San Pablo y consecuentemente aumentar eficacia de los recursos(ANEEL, 2006).

Objetivo general:

El principal objetivo del presente proyecto es de desarrollar un sistema de información para la gestión de la energía eléctrica en las entidades públicas. El desarrollo del sistema ContaLuzWeb está basado en las principales necesidades de los funcionarios públicos como el proceso de control y toma de decisiones con respecto al consumo de electricidad, teniendo como principal objetivo a las entidades detentoras quienes tienen gran número de consumidores(Gimenes y Saidel, 2004).

Metodología:

El sistema fue desarrollado en tres fases, donde la primera abarco la identificación de los perfiles de los usuarios; tomando en consideración que no todos los usuarios poseerían la misma formación técnica con respecto al área de energía, que a la larga generará algunos percances con respecto a la interpretación de las factura. Entonces la solución para los percances detectados fue generar interfaces que sean intuitivas y fácil de usar, de esta forma evitando cometer errores por parte del usuario final (Kurahassi, 2004).

Para lograr el requisito se eligió la opción de diseñar los formularios de tal manera que se asemejen visualmente a las facturas de las concesionarias. Los datos más recurrentes en las facturas de energía varían según los tipos de encuadramiento tarifario. El orden de las mismas en las facturas sufren una variación según la concesionaria correspondiente del tal forma que sistema web presenta distintas formas en la entrada de dato. Esta táctica tiene un impacto directo en la operatividad del sistema en mención el cual disminuye la carga al interpretar las facturas (Kurahassi, 2004).

Etapas:

La segunda fase estuvo abocada solo en el análisis del ambiente de trabajo. Con la finalidad de asegurar su viabilidad en los registro de datos de los futuros usuarios, también garantizas la funcionalidad del sistema de información por medio el internet (Kurahassi, 2004).

Después del registro de datos, el sistema de información debe procesar la data para realizar reportes gerenciales. Y de la misma forma en una tercera etapa se definiría y se categorizarían los informes de la información relevante para la toma de decisiones en el proceso de gestión de la energía eléctrica (Kurahassi, 2004).

Según las conclusiones de la fase de especificación y modelamiento, con el objetivo de permitir las manutenciones de facturas y la fácil manipulación de la base de datos para la generación de informes para el personal no técnico, el sistema de información fue diseñado basado en la tecnología Microsoft(ASP con BD Access) debido a los bajos costos y al fácil desarrollo del producto, en comparación con otros sistemas web las cuales utilizan tecnologías más complejas el cual requiere de personal más sofisticado para el desarrollo (Kurahassi, 2004).

Page 18: Facultad de Ingeniería de Sistemas y Electrónica

18

Finalizando la construcción del sistema de información se ejecutaron las pruebas necesarias y validaciones. Se registraron facturas de las universidades y se generaron reportes e informes obteniendo los resultados esperados. Actualmente el sistema cuenta con consolidados desde el año 1998(Kurahassi, 2004).

Prototipos:

Fig. 2 Interface de registro de consumos.

Fuente: (http://www.scielo.cl/).

Fig. 3 Interface de reporte de consumos.

Fuente: (http://www.scielo.cl/).

Page 19: Facultad de Ingeniería de Sistemas y Electrónica

19

Conclusiones:

1. La universidad de San Pablo actualmente está dando uso al sistema de información ContaLuzWeb revelando que la herramienta es idónea y esencial para la gestión de las entidades públicas las cuales ya denotaron resultados positivos con la reducción de los consumos de energía eléctrica permitiendo evaluar el uso adecuado de la electricidad (Kurahassi, 2004).

2. Se puede contemplar que existen entidades en Brasil las cuales no necesariamente deben ser publicas pueden adoptar la herramienta para gestionar su consumo de energía, debido a que dichas instituciones cuentas con gran cantidad de clientes las cuales también pueden dar uso al sistema de información ContaLuzWeb (Kurahassi, 2004).

3. Gracias a el desarrollo del sistema de información se considera que es posible implantar en cualquier ambiente siempre y cuando esta sea estudiada para ajustar el sistema a los requerimientos del establecimiento debido a que cada institución cuenta con distintos procesos, con respecto a la reutilización del marco conceptual, es sumamente independiente a la tecnología utilizada de tal manera que los criterios establecidos en el sistema se verán reforzados (Kurahassi, 2004).

DISEÑO DE UN SISTEMA DE CONTROL DEL CONSUMO DE ENERGÍA ELÉCTRICA EN LAS COMUNIDADES CAMPESINAS - PONTIFICIA UNIVERSIDAD CATOLICA DEL PERU

Resumen:

En los centros poblados alejados a la ciudad la energía es escasa debido a que solo cuenta con pequeños generadores de electricidad, por lo cual se debe tener conocimiento del máximo valor de potencia que puede generar, razón por la cual existe la necesidad de crear un sistema que controle el consumo de electricidad. El sistema en mención está constituido por subsistemas de regularizaciones, medidores y unidades de procesamiento para de esta forma lograr el control de consumos de cada usuario, para el correcto funcionamiento la medición debe ser ininterrumpida de tal manera que se logrará obtener los consumos reales de manera exacta. Por consiguiente el sistema de control permite conocer la potencia suministrada. (Mario, 2009).

Objetivo General:

Elaborar un sistema el cual que controle el consumo de energía eléctrica en las comunidades campesinas utilizando tecnologías como circuitos y conversores, de tal forma que contribuiría de forma eficiente con el desarrollo de los centros poblados (Mario, 2009).

Page 20: Facultad de Ingeniería de Sistemas y Electrónica

20

Objetivos específicos:

• Se debe realizar un estudio adecuado de las diversas tecnologías existentes en la actualidad el cual serviría como principal sustento para optar por la mejor opción y dar inicio al proyecto. (Mario, 2009).

• Indagar sobre las formas de medición ayudara a contribuir a seleccionar la forma de medición más idónea para el objetivo propuesto (Mario, 2009).

• Es de primordial importancia que la elección dispuesta en este proyecto sea la mejor alternativa tecnológica con respecto a las otras alternativas presentes en el mercado, no obstante se debe tener en cuenta que la eficacia debe ser igual o mayor, manteniéndose bajo el presupuesto planteado (Mario, 2009).

Planteamiento de solución:

Según lo mencionado anteriormente es necesario el uso de dispositivos eléctricos para lograr la medición de la energía consumida de forma óptima, el cual asumirá la tarea de controlar que el punto consumidor no sobre pase el límite establecido de consumo el cual en un caso contrario se realizara la suspensión del servicio (Mario, 2009).

Una vez seleccionado los elementos a utilizar y teniendo el conocimiento correspondiente de cada uno de los componentes, se obtiene una mayor visión del principal producto a desarrollar recalcando de esta manera la importancia del proyecto con respecto al problema en mención, para finalmente elaborar un diagrama de bloques el cual nos brindara una perspectiva técnica del sistema (Mario, 2009).

Conclusiones:

1. En la actualidad existen distintas formas y tecnologías para brindar energía eléctrica a los diferentes usuarios, pero existen pocas herramientas para controlar las mismas y mediante el sistema de control desarrollado es posible el control de consumos (Mario, 2009).

2. Ciertas tecnologías como medidores provistos por empresas en el rubro dado y que a la vez cuentan con sistemas son una buena alternativa para los zonas como estas (Mario, 2009).

3. Según las pruebas realizadas el comportamiento de los dispositivos instalados fueron positivos el cual proporciono información valida y confiable, esto conlleva a afirmar que el sistema de control de consumo de energía eléctrica será sumamente adaptable la solución del problema dado (Mario, 2009).

4. Gracias a la implementación del sistema se puede afirmar que esta alternativa puede ser aplicable a las viviendas de cualquier zona para controlar sus consumos, de esta manera poder controlar mejor la energía eléctrica consumida (Mario, 2009).

Page 21: Facultad de Ingeniería de Sistemas y Electrónica

21

CAPÍTULO 2

MARCO TEÓRICO En el presente capítulo se nombran las tecnologías, metodologías y conceptos que se utilizaron en el desarrollo del módulo de consumos del sistema Advance, la selección de la metodología idónea y las herramientas a usar para dar solución al problema en mención.

2.1 Fundamento Teórico

2.2 Metodología Proceso Unificado de Rational – RUP La Metodología de Proceso Unificado Rational (RUP) es una de las principales metodologías para el desarrollo de software, mediante el UML brindan facilidades de análisis y presentan procedimientos para modelar cualquier negocio el cual en conjunto presentan un solo enfoque. La metodología RUP tiene tres perspectivas: (Rumbaugh, 1999):

• Una perspectivas dinámica que muestra las fases del modelo sobre el tiempo • Una perspectiva estática que muestra las actividades del proceso que se representan. • Una perspectiva practica que surge buenas practicas a utilizar durante el proceso

La metodología RUP combina las perspectivas estáticas y dinámicas en un mismo diagrama el cual origina que los procesos estudiados sean más difícil de comprender, por esta razón es recomendable distribuir las perspectivas para lograr una mejor entendimiento (Krutchen, 2000).

Entre las principales características de la metodología RUP se encuentran las cuatro fases, no obstante existen diferentes modelos como el de cascada en el cual las fases se asemejan con las actividades del proceso, la metodología RUP se encuentra enfocada primordialmente al análisis (Krutchen, 2000):

Fig. 4 Fases de la metodología UML.

Fuente: (http://www.scielo.cl/).

Page 22: Facultad de Ingeniería de Sistemas y Electrónica

22

• Inicio: El principal objetivo de esta fase es lograr comprender el funcionamiento del negocio. Para esto es necesario tener identificado correctamente los actores y caso de uso correspondientemente sus interacciones. La información recaudada servirá para poder medir el impacto que tendrá el sistema sobre el negocio (Krutchen, 2000).

• Elaboración: los objetivos de esta fase son importantes pues se logra comprender el problema a profundidad, nos ayudara a construir una idea del sistema, se logrará tener un plan de proyecto para mantener bajo control los percances durante el desarrollo. finalmente se debe tener los principales requerimientos del sistema y los casos de uso para de esta manera desarrollar una descripción concreta del plan de desarrollo (Krutchen, 2000).

• Construcción: En esta fase básicamente eta dedicada a desarrollar la arquitectura del sistema y su desarrollo, con la finalización de esta fase lograremos tener el producto final y en completo funcionamiento para realizar su migración del ambiente de desarrollo a producción (Krutchen, 2000).

• Transición: En esta fase comprende solo la migración de la aplicación o sistema del ambiente de desarrollo hacia el ambiente de producción para el usuario final, por otro lado en esta fase dejan de lado los modelos y el análisis del sistema. Con la culminación de esta fase se debe tener la aplicación en el ambiente real y funcionando en su totalidad (Krutchen, 2000).

Inicio

• Documento Visión El documento Visión es la principal herramienta para lograr detectar el problema principal. El siguiente documento es de primordial importancia pues es donde se define los principales alcances y a su vez la justificación del sistema a desarrollar (Krutchen, 2000).

• Especificación de requerimientos. El uso de las especificación de requerimientos es sumamente importante pues es donde se describen cada uno de los casos de uso de forma detallada, de tal manera que podremos comprender las interacciones que puedan tener con los actores. Por otro lado la especiación de requerimientos pueden ser no funcionales y son aquellas que no obligan a al sistema a realizar algunas funciones (Krutchen, 2000).

Page 23: Facultad de Ingeniería de Sistemas y Electrónica

23

Elaboración

• Diagrama de caso de uso

Construcción (Documento de arquitectura con las siguientes vistas)

• Vista lógica o Diagrama de clases

• Vista de Implementación o Diagrama de secuencia

• Vista física o Mapa de comportamiento a nivel de hardware.

Resulta menos complejo aplicar la perspectiva dinámica y estática debido a que no existen asociaciones entre los flujos de trabajo entre sí. Si bien existen etapas en la metodología RUP los flujos de trabajo pueden permanecer presentes en cada una de ellas pero cada vez con menos intensidad, no obstante es necesario recalcar que la principal carga de trabajo se encuentra en el flujo de trabajo el modelado de negocio, desarrollo de los requerimientos y en los procesos de pruebas y despliegue (Krutchen, 2000).

Principales características:

• Forma disciplinada de asignar tareas y responsabilidades. • Pretende implementar las mejores prácticas en Ingeniería de Software. • Desarrollo iterativo. • Administración de requisitos. • Uso de arquitectura basada en componentes. • Control de cambios. • Modelado visual del software.

2.3 Modelo UML

2.3.1 Diagrama de caso de uso El caso de uso es un elemento de alta importancia para lograr comprender los procesos desde la perspectiva del usuario. Mediante el uso de esta herramienta se pude lograr obtener los requerimientos funcionales del sistema para tener una vista global de todo el flujo de trabajo, dicha herramienta se vale de estereotipos llamados caso de uso y actores los cuales guardan relación entre sí mismos (Fernando Berzal 2004).

Page 24: Facultad de Ingeniería de Sistemas y Electrónica

24

Fig. 5 Diagrama de caso de uso.

Fuente: (Fernando Berzal, 2004).

2.3.2 Diagrama de clases El diagrama de clases nos muestra una estructura sólida de un sistema, es decir podemos obtener los atributos (propiedades) de las clases y sus respectivas categorías, como ejemplo podemos tomar una computadora de escritorio la cual tiene directamente relación con el modelo marca y precio las cuales vendrían a ser sus atributos (Fernando Berzal 2004).

Fig. 6 Diagrama de clases.

Fuente: (Fernando Berzal, 2004).

2.3.3 Diagrama de secuencia Para lograr representar la relación directa entre los objetos y las clases, una de las herramientas más idóneas es el diagrama de secuencia pues muestra las interacciones entre los objetos dando una visión clara de sus funciones y flujos con respecto al tiempo (Fernando Berzal 2004).

Page 25: Facultad de Ingeniería de Sistemas y Electrónica

25

Fig. 7 Diagrama de secuencia.

Fuente: (Fernando Berzal, 2004).

2.3.4 Diagrama de componentes Un diagrama de componentes describe la organización de los componentes físicos de un sistema de información (Fernando Berzal 2004).

Fig. 8 Diagrama de componentes.

Fuente: (Fernando Berzal, 2004).

2.4 Metodología de desarrollo NCapas El desarrollo en capas es una arquitectura básica de cliente servidor en el que el objetivo principal es la independización de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto consiste en separar la capa de datos de la capa de presentación al usuario (oscarhdzmtz, 2013).

Con este estilo de desarrollo combinado con los niveles es posible lograr una estructura flexible, pues permite la modificación de elementos dentro de las capas de forma independiente el cual es un punto a favor debido a que se puede solucionar inconvenientes en las capas específicas y no en todas las demás (oscarhdzmtz, 2013).

Page 26: Facultad de Ingeniería de Sistemas y Electrónica

26

Fig. 9 Arquitectura 3 Capas 3 niveles.

Fuente: (Elaboración propia).

Capas y niveles:

Capa de presentación: la principal función de esta capa es la de recaudar la información que el usuario ingrese como algún tipo parámetro o información para realizar alguna petición, la cual específicamente esta capa solo tiene comunicación con la capa de negocio. Una de las principales características de la capa en mención es la de tener un aspecto agradable y fácil de usar para el usuario pues es la cara del sistema (Oscarhdzmtz, 2013).

Capa de negocio: la principal función de esta capa es de recibir las peticiones de la capa vista o capa presentación para consiguientemente realizar los procesos correspondientes a la lógica de negocio y finalmente solicitar o realizar el almacenamiento de datos invocando a la capa de datos. Esta capa también está encargada de realizar las devoluciones de las respuestas desde la capa datos. (Oscarhdzmtz, 2013).

Capa de datos: la principal función de esta capa es de enlazar y acceder a la información de la base de datos. La cual está constituida por N gestores de base de datos y se encargan de recepcionar las peticiones de lectura o escritura de datos desde la capa de negocio, por otro lado todas las capas pueden establecerse en una misma computadora física o en distintas computadoras físicas las cuales llamamos niveles. Cabe resaltar que si la necesidad lo amerita se puede separar la base de datos en distintas computadoras físicas y todas recibir las peticiones desde la capa de negocio sin percance alguno (Oscarhdzmtz, 2013).

Page 27: Facultad de Ingeniería de Sistemas y Electrónica

27

Diferencia entre capas y niveles:

Los términos “capas” y “niveles” no son los mismo no similares bajo el contexto de una arquitectura de capas y niveles.

El término "capa" hace referencia a la forma como una solución es segmentada desde el punto de vista lógico.

Por ejemplo:

1. Presentación.

2. Lógica de Negocio.

3. Datos.

En cambio, el término "nivel" corresponde a la forma en que las capas lógicas se encuentran distribuidas de forma física.

Por ejemplo:

1. Una solución de tres capas (presentación, lógica del negocio, datos) que residen en una solo computadora (Presentación + lógica + datos). Se dice que la arquitectura de la solución es de tres capas y un nivel (oscarhdzmtz, 2013).

2. Una solución de tres capas (presentación, lógica del negocio, datos) que residen en dos computadores (presentación + lógica por un lado; lógica + datos por el otro lado). Se dice que la arquitectura de la solución es de tres capas y dos niveles (oscarhdzmtz, 2013).

Arquitectura en 3 niveles:

Generalmente en la arquitectura de tres niveles existe un nivel intermediario, es decir que en esta arquitectura se cumple que siempre existirá un usuario el cual vendría a ser el cliente quien realiza las peticiones desde la web mediante la capa de presentación, por otro lado tenemos al nivel intermedio quien sería el servidor de aplicaciones encargado de recepcionar las peticiones del usuario desde la capa cliente y realizar la lógica de negocio para finalmente solicitar la información a la capa datos. Finalmente tenemos el servidor de base de datos encargado de recepcionar y proporcionar información a la capa de negocio. Por otro lado una arquitectura de dos niveles consta solo de una interacción de entre cliente y el servidor donde la dinámica es la siguiente: la base de datos pude brindar información directa a la vista el cual estaría alojado en el mismo dispositivo físico que el servidor de aplicaciones. Finalmente podemos concluir que en una arquitectura de tres niveles cada una de ellas tiene independencia entre sí por ende brinda una mayor seguridad de información pues cada una de ellas pueden contar con una configuración de seguridad independiente, cabe resaltar que el rendimiento de cada uno de los servidores será mayor gracias a que cada uno se encarga de sus funciones específicas (Oscarhdzmtz, 2013).

Page 28: Facultad de Ingeniería de Sistemas y Electrónica

28

Fig. 10 Arquitectura 3 Niveles.

Fuente: (http://www.academia.edu)

2.5 Lenguajes de desarrollo

2.5.1 Lenguaje C#: Mediante este lenguaje de programación es posible desarrollar y diseñar cualquier tipo de sistema de información siempre y cuando este labore bajo un NET Framework, una de la principales características de este lenguaje es la programación orientada a objetos y la robustez en su arquitectura de desarrollo, la cual nos permite un ágil uso con estilos similares al lenguaje C (msdn.microsoft.com, 2008). Entity framework: Es una forma de representar los datos en de objetos, es decir el desarrollo con Entity Framework está orientado a datos el cual permite el acceso a la misma de forma más rápida y dinámica. Para trabajar con esta tecnología es necesario realizar un mapeo de la base de datos en la aplicación y realizar las transacciones cotidianas desde la misma aplicación mediante el LINQ (msdn.microsoft.com, 2009). Es un conjunto de interfaces de programación de aplicaciones de acceso a datos de Microsoft con .NET Framework, el cual utiliza la versión de ADO.NET donde se incluye con el .NET Framework 3.5. Fue lanzado como actualización separada junto con el Service Pack 1 para el .NET Framework, después del lanzamiento del .NET Framework 3.5 y el Visual Studio 2008. Actualmente una nueva versión del Entity Framework (v 4.0) será liberada junto al Visual Studio 2010 y el .NET Framework 4.0. (msdn.microsoft.com, 2009). LINQ: Es una herramienta muy útil cuando se trata de realizar algún tipo de transacción apuntando a algún motor de base de datos, objetos, etc. El cual mediante el uso de sus propias funciones es capaz de realizar las mismas consultas que se realizarían con un procedimiento almacenado convencional (David B, 2009).

Page 29: Facultad de Ingeniería de Sistemas y Electrónica

29

Expresiones lambda: Mediante el uso de esta herramienta podemos realizar consultas más directas a las operaciones realizadas por el LINQ o algún objeto en específico, el uso de esta herramienta nos permite emplear expresiones conocidas como el where, join, select, etc. (David B, 2009).

HTML: Sigla en inglés de HyperText Markup Language (lenguaje de marcas de hipertexto), el cual nos permite la estandarización de el desarrollo de páginas o sistemas web, el cual es interpretada por los distintos navegadores existentes de tal forma que puede renderizar imágenes, textos y estilos entro otros. (Wide Web Consortium, 2009).

CSS: Hoja de estilo en cascada o CSS (siglas en inglés de cascading style sheets) es uno de los principales lenguajes utilizados para brindar estilos y formas a las web desarrolladas, esta herramienta es fácilmente interpretada por los navegadores (Wide Web Consortium, 2009).

JavaScript: Es un lenguaje de programación el cual es fácilmente interpretado por los exploradores, es un lenguaje orientado a objetos y no está fuertemente tipada (Wide Web Consortium, 2009).

Es un lenguaje el cual su principal característica reside que es utilizada en el lado cliente, de tal forma que nos permite realizar web más dinámicas sin sobrecargar al servidor de aplicaciones. Po otro lado cabe resaltar que el JavaScript también puede ser usado e invocado desde el lado servidor. (Wide Web Consortium, 2009).

Ajax: El Ajax depende de ciertas tecnologías para su correcto funcionamiento, tales como el HTML oXHTML, CSS, JavaScript, DOM, XML, XSLT, y el objeto XMLHttpRequest. Al utilizar estas tecnologías con el modelo AJAX, es posible lograr aplicaciones web capaces de actualizarse continua y automáticamente sin tener que volver a renderizar la página. Esto crea aplicaciones más rápidas y con mejor respuesta para el usuario (Miguel A, 2013).

El principal propósito de desarrollar aplicaciones con JavaScript es asemejar dichas aplicaciones a las de escritorio donde el servidor de aplicaciones no se vea sobrecargado por la cantidad de peticiones que recibe, y estas sean atendidas por el mismo cliente (Miguel A, 2013).

Page 30: Facultad de Ingeniería de Sistemas y Electrónica

30

Fig. 11 Aplicación web Clásica vs Ajax.

Fuente: (http://jesusnoseq.github.io/php1h/#/37).

2.6 SQL Server 2012 Microsoft SQL Server es una herramienta para la gestión de información, mediante el uso de tablas relaciones las cuales tienen la capacidad de almacenar cierta información de algún negocio en específico. (Microsoft Corporation, 2010).

Microsoft SQL Server 2012 está basado en la versiones anteriores pero con mejoras implementadas, la cual proporciona una mayor confiabilidad y un mejor rendimiento con respecto al almacenamiento de datos y el tratamiento de la misma. Una de sus principales características es mantener la integridad de la información almacenada. (Microsoft Corporation, 2010).

Características:

• Servicio núcleo del almacenamiento, procesamiento y seguridad de los datos.

• Bases de datos relacionales para procesamiento de transacciones en línea.

• Tablas para almacenamiento de datos, índices, vistas y procedimientos almacenados.

Base de datos relacional:

Una base de datos relacional cuenta con distintas tablas relacionadas entre sí mediante uno o varios atributos en específico, el cual ayuda a organizar y mantener una base de datos libre de inconsistencias. (Edgar Frank Codd)

Page 31: Facultad de Ingeniería de Sistemas y Electrónica

31

En las bases de Codd se definían los objetivos de este modelo:

• Independencia física. La forma de almacenar los datos, no debe influir en su manipulación lógica

• Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser modificadas por que se modifiquen elementos de la base de datos.

• Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los usuarios y aplicaciones.

• Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las tablas)

• Sencillez.

Evolución de la base de datos relacional:

Tabla 2 Evolución de la base de datos relacional.

Fuente: (Microsoft, 2005).

Tablas:

Una de la principal característica de las base de datos relacional es el uso de tablas relacionadas entre sí, las cuales tienen una forma gráfica rectangular. Estas tablas contienen filas o tuplas las cuales vienen a ser la información almacenada y a su vez estas tablas contienen atributos las cuales son denominadas columnas, algunas de ellas pueden tener alguna propiedad tal como una llave primaria es decir un atributo con tuplas no repetidas. (Jorge Sánchez, 2004).

Page 32: Facultad de Ingeniería de Sistemas y Electrónica

32

Fig. 12 Tablas relacionales.

Fuente: (Jorge Sánchez, 2004).

Terminología relacional: Fuente: (Jorge Sánchez, 2004).

• Tupla. Cada fila de datos de una tabla. • Atributo. Cada columna de una tabla. • Grado. Número de atributos de la tabla. • Cardinalidad. Número de tuplas de una tabla. • Dominio. Conjunto válido de valores representables por un atributo.

Tipos de tablas:

Persistentes

Sólo pueden ser borradas por los usuarios:

• Tablas. Son las tablas convencionales las cuales son creadas por los desarrolladores indicando sus atributos de forma manual. (Jorge Sánchez, 2004).

• Vistas. Son tablas también creadas por el desarrollador el cual su principal finalidad es la de almacenar información de consultas de otras tablas o de otras base de datos, si la información del origen cambia en la vista también la información será modificada. (Jorge Sánchez, 2004).

• Instantáneas. Son vistas creadas exactamente de la misma forma anterior, también almacenan los datos que muestran de la consulta que dio lugar a esa vista. Por otro lado este tipo de vista solo se encarga de almacenar y modificar la información gracias al sistema que se ocupa de refrescarlas cada cierto tiempo. (Jorge Sánchez, 2004).

Temporales

Son aquellas tablas de uso temporal que son usualmente utilizadas en procedimientos almacenados las cuales tienen la siguiente nomenclatura: @mitabla. (Jorge Sánchez, 2004).

Formas normales:

Una de las principales y mejores técnicas para el análisis de una base de datos relacional es aplicando la técnica de normalización planteada por Codd y continuada por otros autores (Jorge Sánchez, 2004).

Page 33: Facultad de Ingeniería de Sistemas y Electrónica

33

Para lograr una buena normalización es importante recalcar que se debe seguir el orden de las fases para dicho procedimiento, motivo por el cual se puede obtener una segunda forma normal previamente habiendo realizado la primera forma normal de forma correcta. (Jorge Sánchez, 2004).

Este procedimiento es sumamente lógico e intuitivo, y a continuación se muestra un ejemplo hasta la tercera forma normal que es la más recomendada. (Jorge Sánchez, 2004).

• Primera forma normal: Podemos saber que una tabla se encuentra en la primera forma normal si un atributo permite que una fila tenga más de un valor. (Jorge Sánchez, 2004).

Fig. 13 Tabla primera forma normal.

Fuente: (Jorge Sánchez, 2004).

• Segunda forma normal: en esta segunda etapa solo ocurre si es que la tabla se encuentra

en una primera forma normal y además cada uno de los atributos dependen de los atributos con propiedad clave. Si alguna tupla dependiera de algún atributo que no sea clave esta debería formar parte de una tabla adicional y de esta manera tendiéramos una segunda forma normal. (Jorge Sánchez, 2004).

Fig. 14 Tabla y entidades.

Fuente: (Jorge Sánchez, 2004).

Del ejemplo de la figura N° 14 podemos resaltar que la nota depende de manera funcional al código de curso, entonces podemos decir que estos dos atributos pueden ser separados a una segunda tabla donde tuvieran un vínculo en común con el alumno en este caso el número de DNI (Jorge Sánchez, 2004).

Page 34: Facultad de Ingeniería de Sistemas y Electrónica

34

Fig. 15 Tabla segunda forma normal.

Fuente: (Jorge Sánchez, 2004).

• Tercera forma normal: Para lograr este nivel de forma normal es necesario tener la tabla en la primera y segunda forma normal, además los atributos que no dependan de algún otro atributo que sea clave en la tabla decimos que esta puede ser separada en otra tabla independiente. (Jorge Sánchez, 2004).

Fig. 16 Tabla y entidades.

Fuente: (Jorge Sánchez, 2004).

Como podemos observar en la figura N° 16 las columnas código de provincia y provincia no dependen de ningún atributo, entonces pueden ser separadas en una tabla distinta como se muestra a continuación (Jorge Sánchez, 2004).

Fig. 17 Tercera forma normal

.

Fuente: (Jorge Sánchez, 2004).

Page 35: Facultad de Ingeniería de Sistemas y Electrónica

35

2.7 Tipos de energía Energía activa: la energía activa es aquella generada por receptores cotidianos como licuadoras, lámparas o televisores, etc. Estos receptores para funcionar necesitan producir calor o trabajo mecánico y a esta dinámica se le denomina energía activa la cual su unidad de medida por defecto es el kwh (http://www2.osinergmin.gob.pe/).

Energía reactiva: la energía reactiva es generada por los distintos receptores tal como motores, transformadores entre otros. Estos dispositivos para lograr un funcionamiento correcto necesitan generar campos magnéticos durante la petición y devolución de la misma, esta dinámica produce que la energía desaparezca, y a su vez se genera un consumo de energía suplementario la cual es aprovechada por los dispositivos como motores o trasformadores y a todo este flujo tiene como denominación energía reactiva y es medida en kvArh. (http://www2.osinergmin.gob.pe/).

Potencia de generación: la potencia de generación es la cantidad máxima que puede recibir un circuito eléctrico, es decir es un rango de valor asignado a un receptor en el cual se cumple lo siguiente: mientras más energía reactiva es consumida menor es la potencia de generación por ende el consumo en dinero es menor. (http://www2.osinergmin.gob.pe/).

2.8 Alícuotas Osinergmin es un organismo público encargado de mantener regularizadas las tarifas de los consumos mediante la gerencia de regularización llamada GART (Gerencia adjunta de regularización tarifaria) bajo las disposiciones del marco normativo de los sectores eléctricos e hidrocarburos. (http://www2.osinergmin.gob.pe/).

Las empresas reguladas están autorizadas a cobrar a los clientes de los servicios públicos regulados del Sector Energía las tarifas que fija OSINERGMIN (http://www2.osinergmin.gob.pe/).

Los montos facturados por energía eléctrica así como del cargo fijo, se determinan por los siguientes componentes: (http://www2.osinergmin.gob.pe/).

• La opción tarifaria (MT2, BT3, BT5B, etc.) • La cantidad de días entre la lectura anterior y la actual. • El consumo registrado. • El pliego o los pliegos tarifarios vigentes en el periodo de lectura del medidor.

(http://www2.osinergmin.gob.pe/).

2.9 Pliego tarifario Tarifas dictadas por la entidad responsable Osinergmin, la cual se da solo pueden dar uso las empresas autorizadas para realizar los cobros respectivos según las tarifas establecidas sobre los consumos recolectados de sus proveídos. (http://www2.osinergmin.gob.pe/).

Page 36: Facultad de Ingeniería de Sistemas y Electrónica

36

Tabla 3 Tabla de tarifas de pliego tarifario. TARIFA MT4:

TARIFA CON SIMPLE MEDICIÓN DE ENERGÍA ACTIVAY CONTRATACIÓN O MEDICIÓN DE UNA POTENCIA 1E1P

Cargo Fijo Mensual S/./mes Cargo por Energía Activa ctm. S/./kW.h Cargo por Potencia Activa de generación para Usuarios: Presentes en Punta S/./kW-mes Presentes Fuera de Punta S/./kW-mes Cargo por Potencia Activa de redes de distribución para Usuarios: Presentes en Punta S/./kW-mes Presentes Fuera de Punta S/./kW-mes

Cargo por Energía Reactiva que exceda el 30% del total de la Energía Activa ctm. S/./kVar.h

TARIFA BT4:

TARIFA CON SIMPLE MEDICIÓN DE ENERGÍA ACTIVA Y CONTRATACIÓN O MEDICIÓN DE UNA POTENCIA 1E1P

Cargo Fijo Mensual S/./mes Cargo por Energía Activa ctm. S/./kW.h Cargo por Potencia Activa de generación para Usuarios: Presentes en Punta S/./kW-mes Presentes Fuera de Punta S/./kW-mes Cargo por Potencia Activa de redes de distribución para Usuarios: Presentes en Punta S/./kW-mes Presentes Fuera de Punta S/./kW-mes

Cargo por Energía Reactiva que exceda el 30% del total de la Energía Activa ctm. S/./kVar.h

TARIFA BT5: TARIFA CON DOBLE MEDICIÓN DE ENERGÍA 2E

a) Usuarios con demanda máxima mensual de hasta 20kW Cargo Fijo Mensual S/./mes Cargo por Energía Activa en Punta ctm. S/./kW.h Cargo por Energía Activa Fuera de Punta ctm. S/./kW.h Cargo por Exceso de Potencia en Horas Fuera de Punta S/./kW-mes

b) Usuarios con demanda máxima mensual de hasta 20kW en HP y 50kW en HFP

Cargo Fijo Mensual S/./mes Cargo por Energía Activa en Punta ctm. S/./kW.h Cargo por Energía Activa Fuera de Punta ctm. S/./kW.h

Fuente: (http://www2.osinergmin.gob.pe/).

Page 37: Facultad de Ingeniería de Sistemas y Electrónica

37

CAPÍTULO 3

DESARROLLO DE LA SOLUCIÓN En este capítulo se identifica el problema crítico y sus objetivos para la mitigación de la misma, se define los requerimientos funcionales y no funcionales y finalmente identificamos y describimos los actores y caso de uso.

3.1.1 Organigrama de la empresa Real Plaza A continuación se detalla el organigrama general de la empresa real plaza, teniendo como principal jerarquía la Vise presidencia de Administración, finanzas y GDH (Gestión del desarrollo humano).

Fig. 18 Organigrama de la empresa Real Plaza.

Fuente: (Elaboración propia).

Gerencia general

VP de administración, finanzas y GDH

Gerente de gestión y de

sarrollo humano

Asitente de gerencia

Asitente administrativa

Asistente administrativa

Analista de cultura y clima

Asistente de cultura y clima

Coordinador de compensaciones

Coordinador de desarrollo y capacitación

Asistente de capacitación

Jefe de atracción y selección

Gerencia de administración y

finanzas

Sub gerencia de interligencia

comercial

Inteligencia comercial

Sub gerencia de planeamiento y

finanzas

Jefe corporativo de planeamiento

y finanzas

Tesorería

Planeamiento

Jefe corporativo de créditos y

cobranzas

Gerencia de TI

Jefe de infraestructura

Infraestructura Service desk

Jefe de proyectos

Equipo de desarrollo

Gestor de proyectos 1

Gestor de proyectos 2

Gestor de proyectos 3

VP de desarrollo y contrucción

VP de diseño y operaciones

Page 38: Facultad de Ingeniería de Sistemas y Electrónica

38

3.2 Análisis de la solución

3.2.1 Inicio

3.2.1.1 Documento visión Actualmente, el área de operaciones recolecta de forma manual la información de consumos de agua y electricidad, la cual es necesaria para la generación de facturas.

Por el modo de trabajo manual se presentan diversas problemáticas con la información, las cuales se solucionarán automatizando el proceso de recolección de información.

• Objetivos o Automatizar el flujo de trabajo en el área de operaciones. o Implementar alertas que ayuden a recolectar información de consumos en la

fecha correcta. o Reducir las incidencias por errores en los cálculos de los consumos de agua y

electricidad. • Áreas involucradas

o Operaciones corporativo. o Operaciones Mall. o Gestión inmobiliaria. o Cobranzas.

3.2.1.2 Especificación de requerimientos Requerimientos funcionales

A continuación se detalla los requerimientos funcionales los cuales darán solución a la deficiencia en el área de operaciones mediante la automatización de sus principales flujos de trabajo.

Tabla 4 Tabla de requerimientos funcionales. Referencia Requerimiento RF01 El módulo contempla la inserción rápida y fácil de los consumos de un periodo y

Mall determinado. RF02 Permite sustentar los consumos recaudados mediante la generación de

reportes PDF. RF03 Permite la inserción y previa validación de datos OLD, es decir los datos

recogidos del Log en caso el medidor presente algún error. RF04 Permite enviar de forma individual y masiva los registros de consumos. RF05 Permite la generación de plantillas Excel para la carga masiva de consumos de

agua y electricidad. RF06 Permite el registro de fechas de cierre y días límite de ingreso de los consumos

de agua y electricidad. RF07 El módulo permite el registro, modificación y eliminación de los pliegos

tarifarios según el tipo de consumo, inmueble y periodo. RF08 Permite el registro y modificación de las alícuotas según el Mall determinado y

periodo RF09 El modulo permite personalizar una lista masiva de clientes, los cuales serán

tomados en cuenta para la generación masiva de los sustentos de los consumos

Page 39: Facultad de Ingeniería de Sistemas y Electrónica

39

eléctricos y agua. RF10 Permite la carga de consumos de forma individual mediante una ventana

emergente. RF11 Permite la carga masiva de consumos mediante una ventana emergente en la

cual se adjunta el documento Excel. RF12 El módulo enviara correos masivos a los responsables de la carga de los datos 3

días útil antes de que se cumpla la fecha límite de la carga de información. RF13 El módulo cuenta con un trabajo automático - JOB el cual genera reportes (PDF)

de forma masiva los cuales son almacenados en un FileServer. RF14 El módulo alertara al locatario que ha excedido por primera vez sus consumos

habituales. RF15 El módulo alertara al locatario que ha excedido por segunda vez sus consumos

habituales, además indicara si excede por tercera vez su tarifa se actualizara a una más elevada.

RF16 El módulo cambia la tarifa estipulada en el contrato si el locatario ha excedido por tercera vez sus consumos habituales en el periodo en curso.

3 Fuente: (Elaboración propia).

Requerimientos no funcionales

Tabla 5 Tabla de requerimientos no funcionales. Referencia Requerimiento RNF01 Las interfaces del módulo de consumos son fácil e intuitivo de usar. RNF02 El modulo puede ser usado desde cualquier navegador sin complicaciones ni

distorsiones al respecto a los objetos. RNF03 El módulo funciona desde cualquier sistema operativo. RNF04 Los mensajes son fácil de entender y comprender. RNF05 El tiempo de espera para realizar una transacción es corta.

Fuente: (Elaboración propia).

Actores

A continuación se describe las funciones de cada uno de los actores del módulo propuesto.

Tabla 6 Tabla de actores. Actor Descripción Gerente de Mall Encargado de velar por el envío de la información de consumos a

tiempo. Asistente de gerente Mall

Encargado de recaudar la información de consumos de todos los locales pertenecientes a su Mall.

Asistente corporativo de operaciones

• Encargado de validar que la información enviada por los asistentes de Mall sea correcta.

• Registra información como alícuotas y pliego tarifario.

• Envío de información a GI.

Asistente de registros

Registro de información.

Gestión inmobiliaria Encargado de facturar Cobranzas Encargado de cobrar según información de GI.

Fuente: (Elaboración propia).

Page 40: Facultad de Ingeniería de Sistemas y Electrónica

40

Caso de uso

A continuación se describe cada caso de uso del módulo propuesto.

CU01 Registrar alícuotas

Tabla 7 CU01 Registrar alícuotas CU01 Registrar alícuotas Descripción El caso de uso permite el registro de las alícuotas Actores Asistente corporativo de operaciones. Precondición El usuario debe estar correctamente autentificado y tener acceso

al menú de operaciones. Flujo básico • El caso comienza cuando usuario ingresa al menú de

registro de alícuotas. • El sistema muestra la interfaz de registro de alícuotas. • El usuario selecciona los filtros. • Se ingresan las alícuotas para su registro. • El usuario presiona el botón guardar.

Post condición Las alícuotas se registran en la BD con estado Activo y se bloquean los campos para el ingreso de alícuotas.

Flujo alterno Editar alícuotas • El usuario selecciona los filtros.

• El usuario presiona el botón buscar. • El usuario presiona el botón modificar. • El sistema desbloquea los controles para el ingreso de las

alícuotas. • El usuario ingresa las alícuotas. • El usuario presiona guardar.

Post condición El sistema inserta las nuevas alícuotas en la BD y actualiza las alícuotas anteriores con estado inactivo.

Fuente: (Elaboración propia).

CU01 Registrar pliego tarifario

Tabla 8 CU02 Registrar pliego tarifario CU02 Registrar pliego tarifario Descripción El caso de uso permite el registro de los pliegos tarifarios. Actores Asistente corporativo de operaciones. Precondición El usuario debe estar correctamente autentificado y tener acceso

al menú de operaciones. Flujo básico • El caso comienza cuando usuario ingresa al menú de

registro de pliego tarifario. • El sistema muestra la interfaz de registro de pliego

tarifario. • El usuario selecciona los filtros correspondientes. • Se ingresan los pliegos tarifarios para su registro. • El usuario presiona el botón guardar.

Post condición Los pliegos tarifarios se registran en la BD, se listan los pliegos

tarifarios registrados. Flujo alterno Editar pliego tarifario • El usuario selecciona los filtros.

Page 41: Facultad de Ingeniería de Sistemas y Electrónica

41

• El usuario presiona el botón buscar. • El usuario presiona el link editar de la lista de pliegos

tarifarios. • Los datos se posicionan en las cajas de texto. • El usuario modifica los montos. • El usuario presiona el botón guardar.

Post condición Los pliegos tarifarios se guardan en la BD, los pliegos tarifarios anteriores cambian a estado inactivo.

Flujo alterno - Fuente: (Elaboración propia).

CU03 Registrar consumos - Electricidad

Tabla 9 CU03 Registrar consumos - Electricidad CU03 Registrar consumos - Electricidad Descripción El caso de uso permite el registro de consumos eléctricos. Actores Asistente de gerente Mall. Precondición El usuario debe estar correctamente autentificado y tener acceso

al menú de operaciones. Flujo básico • El usuario ingresa al menú de recolección de

información/registro automático. • El usuario selecciona el tipo de consumo eléctrico. • El usuario selecciona el inmueble. • El usuario selecciona el periodo. • El usuario ingresa la información en los campos de texto

de: Carga regular, carga adicional y carga de emergencia. • El usuario presiona el botón enviar.

Post condición Los consumos son registrados en la BD, los datos son mostrados en la lista.

Flujo alterno Enviar Masivo • El usuario ingresa al menú de recolección de

información/registro automático. • El usuario selecciona el tipo de consumo. • El usuario selecciona el inmueble. • El usuario selecciona el periodo. • El usuario ingresa la información en los campos de texto

de: Carga regular, carga adicional y carga de emergencia. • El usuario presiona el botón enviar masivo. • El sistema envía todos los datos de la lista de forma

masiva. Post condición Los consumos son registrados en la BD, los datos son mostrados

en la lista. Flujo alterno -

Fuente: (Elaboración propia).

Page 42: Facultad de Ingeniería de Sistemas y Electrónica

42

CU04 Registrar consumos - Agua

Tabla 10 CU04 Registrar consumos - Agua CU04 Registrar consumos - Agua Descripción El caso de uso permite el registro de consumos de agua. Actores Asistente de gerente Mall. Precondición El usuario debe estar correctamente autentificado y tener acceso

al menú de operaciones. Flujo básico • El usuario ingresa al menú de recolección de

información/registro automático. • El usuario selecciona el tipo de consumo lectura agua. • El usuario selecciona el inmueble. • El usuario selecciona el periodo. • El usuario ingresa la información en los campos de texto

de: Carga regular. El usuario presiona el botón enviar.

Post condición Los consumos son registrados en la BD, los datos son mostrados en la lista.

Flujo alterno Enviar Masivo • El usuario ingresa al menú de recolección de

información/registro automático. • El usuario selecciona el tipo de consumo. • El usuario selecciona el inmueble. • El usuario selecciona el periodo. • El usuario ingresa la información en los campos de texto

de: Carga regular. • El usuario presiona el botón enviar masivo. • El sistema envía todos los datos de la lista de forma

masiva Post condición Los consumos son registrados en la BD, los datos son mostrados

en la lista. Flujo alterno

Fuente: (Elaboración propia).

CU05 Registrar datos OLD

Tabla 11 CU05 Registrar datos OLD CU05 Registrar Datos OLD Descripción El caso de uso permite el registro de datos OLD. Actores Asistente de gerente Mall. Precondición • El usuario debe estar correctamente autentificado y

tener acceso al menú de operaciones. • Los consumos marcados por los medidores deben ser

menor al último registro. Flujo básico • El usuario selecciona los filtros correspondientes.

• El presiona buscar, el sistema lista los datos. • El usuario selecciona Datos OLD. • El sistema muestra una ventana Popup. • El usuario ingresa los consumos OLD. • El usuario presiona el botón guardar.

Page 43: Facultad de Ingeniería de Sistemas y Electrónica

43

Post condición El sistema registra los consumos OLD en la BD. Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU06 Relacionar

Tabla 12 CU06 Relacionar CU06 Relacionar Descripción El caso de uso permite relacionar los consumos con el locatario. Actores Asistente de gerente Mall. Precondición • El usuario debe estar correctamente autentificado y

tener acceso al menú de operaciones. • El locatario debe haber cambiado su razón social o

renovado su contrato. Flujo básico • El usuario selecciona los filtros correspondientes.

• El presiona buscar, el sistema lista los datos. • El usuario selecciona relacionar. • El sistema muestra una ventana Popup. • El sistema muestra los consumos del locatario antes de

cambiar su razón social o renovar su contrato. • El usuario presiona RELACIONAR.

Post condición El sistema registra los consumos con el nuevo contrato del

locatario Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU07 Ver Historial

Tabla 13 CU07 Ver Historial CU07 Ver Historial Descripción El caso de uso permite mostrar el historial de observaciones. Actores Asistente corporativo de operaciones. Precondición • El usuario debe estar correctamente autentificado y

tener acceso al menú de operaciones. Flujo básico • El usuario debe encontrarse en la interface de reporte.

• El usuario selecciona los filtros correspondientes. • El presiona buscar, el sistema lista los datos. • El usuario selecciona historial. • El sistema muestra una ventana Popup. • El sistema muestra el historial de consumos del locatario.

Post condición - Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

Page 44: Facultad de Ingeniería de Sistemas y Electrónica

44

CU08 Enviar de alertas

Tabla 14 CU08 Enviar alertas CU08 Enviar de alertas Descripción JOB que permite el envío de alertas de consumos sin ingresar. Actores • Gerente corporativo de operaciones.

• Asistente corporativo de operaciones. • Gerente de MALL • Asistente de gerente de MALL.

Precondición • Deben existir al menos 1 locatario con cargas pendientes de registro.

Flujo básico • El JOB verifica si existen locatarios sin consumos registrados en el periodo en curso.

• El sistema envía un correo con un listado de los MALL y locatario con registro de consumos pendientes.

Post condición - Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU09 Generar plantilla

Tabla 15 CU09 Generar plantilla CU09 Generar plantilla Descripción El caso de uso permite la generación de una plantilla para la

carga masiva. Actores Asistente de gerente de MALL. Precondición EL usuario debe estar correctamente autentificado en el sistema. Flujo básico • El usuario ingresa al menú de registro manual.

• EL sistema muestra la pantalla de registro manual. • El usuario presiona el botón plantilla. • El sistema muestra un Popup con filtros. • El usuario selecciona los filtros correspondientes. • El usuario presiona el botón generar plantilla. • El sistema descarga un archivo Excel con el formato para

el ingreso de consumos. Post condición - Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

Page 45: Facultad de Ingeniería de Sistemas y Electrónica

45

CU10 Registrar consumo individual - Electricidad

Tabla 16 CU10 Registrar consumo individual - Electricidad CU10 Registrar consumo individual - Electricidad Descripción El caso de uso permite el registro de consumo eléctrico de forma

individual. Actores Asistente de gerente de MALL. Precondición EL usuario debe estar correctamente autentificado en el sistema. Flujo básico • El usuario ingresa al menú de registro manual

• El sistema muestra la interface de registro manual. • El usuario presiona el botón carga data. • El usuario presiona el botón de opción INDIVIDUAL. • El usuario selecciona el tipo de lectura eléctrica. • El sistema muestra filtros y campos de texto para el

ingreso de los consumos. • El usuario ingresa la información. • El usuario presiona el botón guardar. • El sistema muestra un mensaje del registro.

Post condición Los consumos son registrados en la BD, el Popup se cierra. Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU11 Registrar consumo individual - Agua

Tabla 17 CU11 Registrar consumo individual - Agua CU11 Registrar consumo individual - Agua Descripción El caso de uso permite el registro de consumo de agua de forma

individual. Actores Asistente de gerente de MALL. Precondición EL usuario debe estar correctamente autentificado en el sistema. Flujo básico • El usuario ingresa al menú de registro manual

• El sistema muestra la interface de registro manual. • El usuario presiona el botón carga data. • El usuario presiona el botón de opción INDIVIDUAL. • El usuario selecciona el tipo de lectura agua. • El sistema muestra filtros y campos de texto para el

ingreso de los consumos. • El usuario ingresa la información. • El usuario presiona el botón guardar. • El sistema muestra un mensaje del registro.

Post condición Los consumos son registrados en la BD, el Popup se cierra. Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

Page 46: Facultad de Ingeniería de Sistemas y Electrónica

46

CU12 Cargar consumo masivo - Electricidad - Agua

Tabla 18 U12 Cargar consumo masivo - Electricidad - Agua CU12 Cargar consumo masivo - Electricidad - Agua Descripción El caso de uso permite el registro de consumo de agua y

electricidad de forma masiva. Actores Asistente de gerente de MALL. Precondición EL usuario debe estar correctamente autentificado en el sistema. Flujo básico • El usuario ingresa al menú de registro manual

• El sistema muestra la interface de registro manual. • El usuario presiona el botón carga data. • El usuario presiona el botón de opción MASIVO. • El usuario adjunta un archivo Excel. • El sistema valida el formato del archivo y su extensión. • El usuario presiona el botón registrar. • El sistema muestra un mensaje del registro.

Post condición Los consumos son registrados en la BD, el Popup se cierra. Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU13 Registrar fecha cierre

Tabla 19 CU13 Registrar fecha cierre CU13 Registrar fecha cierre Descripción El caso de uso permite el registro de las fechas de cierre. Actores Asistente corporativo de operaciones. Precondición EL usuario debe estar correctamente autentificado en el sistema. Flujo básico • El ingresa al menú de fecha de cierre.

• El usuario selecciona un año. • El usuario selecciona las fechas del calendario. • El usuario presiona GRABAR

Post condición Las fechas son registradas en la BD. Flujo alterno Editar fechas • El usuario presiona X para eliminar una fecha.

• El usuario selecciona otra fecha. • El sistema valida que no exista más de una fecha del

mismo mes en el mismo año. • El usuario presiona GRABAR.

Post condición Las fechas son registradas en la BD. Flujo alterno -

Fuente: (Elaboración propia).

CU14 Generar reporte

Tabla 20 CU14 Generar reporte CU14 Generar reporte Descripción El caso de uso permite generar un reporte de consumos. Actores • Asistente corporativo de operaciones.

Page 47: Facultad de Ingeniería de Sistemas y Electrónica

47

• Asistente de gerente de MALL. • Gerente de MALL. • Gerente de Operaciones.

Precondición El usuario debe estar correctamente autentificado. Flujo básico • El usuario ingresa al menú de reporte

• El sistema muestra la interface del reporte. • El usuario selecciona los filtros correspondientes. • El usuario presiona el botón buscar. • El usuario muestra la información solicitada. • El usuario presiona el botón EXPORTAR. • El sistema descarga un archivo Excel con los consumos

registrados. Post condición - Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU15 Enviar alerta consumo excedido

Tabla 21 CU15 Enviar alerta consumo excedido CU15 Enviar alerta consumo excedido Descripción El caso de uso permite el envío de alertas de excesos en

consumos. Actores Asistente de gerente Mall. Precondición • El usuario debe estar correctamente autentificado y

tener acceso al menú de operaciones. • Las cargas deben exceder +-15%. • El locatario no debió exceder por más de 3 veces su

consumo en lo que dure su contrato. Flujo básico • El usuario selecciona los filtros correspondientes.

• El presiona buscar, el sistema lista los datos. • El usuario ingresa los consumos. • El usuario presiona enviar.

El sistema envía alerta (Primera, Segunda, Tercera) al gerente de MALL, Locatario.

Post condición - Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

Page 48: Facultad de Ingeniería de Sistemas y Electrónica

48

CU16 Registrar sustento

Tabla 22 CU16 Registrar sustento CU16 Registrar sustento Descripción El caso de uso permite registrar un sustento siempre y cuando el

locatario se ha excedido en su consumo en +- 15%. Actores Asistente de gerente Mall. Precondición • El usuario debe estar correctamente autentificado y

tener acceso al menú de operaciones. • Las cargas deben exceder +-15%.

El locatario no debió exceder por más de 3 veces su consumo en lo que dure su contrato.

Flujo básico • El usuario selecciona los filtros correspondientes. • El presiona buscar, el sistema lista los datos. • El usuario presiona SUSTENTO. • El usuario selecciona un tipo de motivo e ingresa una

observación. • El usuario presiona GRABAR.

Post condición El sustento se registra en la BD. Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

CU17 Mantener lista masiva

Tabla 23 CU16 Mantener lista masiva. CU16 Mantener lista masiva Descripción Caso de uso permite el registro de locatarios para la generación

de sustentos masivos. Actores Asistente corporativo de operaciones. Precondición • El usuario debe estar correctamente autentificado.

• Debe existir locatarios en la BD. Flujo básico • El usuario ingresa al menú de sustentos.

• El usuario presiona el botón mantener lista. • El usuario selecciona los filtros correspondientes. • El usuario presiona buscar. • El sistema lista los locatarios. • El usuario selecciona a los locatarios que desea incluir en

la lista masiva. • El usuario presiona el botón GRABAR. • El sistema muestra un mensaje de registro.

Post condición Los locatarios se registran en la BD. Flujo alterno - Post condición - Flujo alterno -

Fuente: (Elaboración propia).

Page 49: Facultad de Ingeniería de Sistemas y Electrónica

49

3.3 Elaboración

3.3.1 Diagrama Work Down Structure

En el siguiente grafico WBS se muestran cada uno de los hitos y el detalle de cada uno de ellos:

• Elaboración de la propuesta de solución fase en la cual se identifica el problema. • Levantamiento de información fase en la cual se obtiene la información necesaria para

iniciar con el análisis y dar solución al problema detectado. • En la tercera etapa corresponde al análisis respectivo según la información recaudada

en la fase anterior y culmina con la aprobación de la gerencia de TI (Tecnología de la información).

• Fase de desarrollo donde se construye el modulo según el análisis propuesto. • Fase en la cual el modulo desarrollado se somete a distintas pruebas unitarias y

pruebas con el usuario para la conformidad de la misma. • Finalmente se inicia la implementación del módulo en producción.

Fig. 19 Diagrama WBS Real Plaza.

Fuente: (Elaboración propia).

Consumos Real Estate - Real Plaza

1.1 Propuesta de solución

1.1.1 Elaboración de propuesta de solución

1.1.2 Obtener aprobación del

usuario

1.1.3 Obtener aprobación de la

gerencia de TI

1.2 Levantamiento de información

1.2.1 Entrevistas al usuario

1.2.2 Elaboración de requerimientos

funcionales

1.2.3 Elaboracion de Propuesta de solución

final

1.2.4 Aprobacion de la propuesta de solucion

final

1.3 Análisis

1.3.1 Elaboración de cronograma de

actividades

1.3.2 Aprobación de cronograma de

actividades por la gerencia de TI

1.4 Desarrollo

1.4.1 Construcción del producto

1.4.2 Elaboración de registro de evidencias

1.4.3 Pase a certificación

1.5 Certificación

1.5.1 Pruuebas unitarias

1.5.2 Elaboración de registro de pruebas

unitarias

1.5.3 Obtener aprobación del usuari

final

1.5.4 Elaboración de certificación de pase a

producción

1.6 Implementación

1.6.1 Realizar pase a producción

Page 50: Facultad de Ingeniería de Sistemas y Electrónica

50

3.3.2 Organigrama del proyecto En el siguiente organigrama se detalla jerárquicamente los involucrados en el proyecto de consumos, iniciando desde la gerencia general hasta el equipo de desarrollo y calidad, posteriormente queda involucrado el personal de infraestructura quien tiene la responsabilidad de habilitar los ambientes de producción.

Fig. 20 Organigrama del proyecto consumos.

Fuente: (Elaboración propia).

3.3.3 Matriz de interés StakeHolder El siguiente cuadro representa el grado de interés que tiene cada uno de los involucrados del proyecto con respecto a las estrategias de la empresa y lograr los objetivos trazados y culminar el proyecto.

Tabla 24 Matriz de interés – StakeHolder. Grado de interés

Bajo Alto

Pode

r

Bajo • Analista de Calidad • Gerente de Mall • Gestor de proyectos

Alto • Asistente de Operaciones

• Gerente de TI • Gerente de Operaciones • VP De Administración y Finanzas

Fuente: (Elaboración propia).

VP de administración, finanzas y GDH

Gerencia de tecnología de la

información

Gestor de proyectos

Equipo de desarrollo Calidad

Jefe de infraestructura

Administrador de redes

Administrador de servidores

Page 51: Facultad de Ingeniería de Sistemas y Electrónica

51

3.3.4 Plan de comunicaciones En la siguiente matriz se detalla el plan de comunicaciones especificando el tipo de comunicación y el objetivo principal, el medio con el cual será trasmitido y la frecuencia que tendrá, finalmente la audiencia principal y el encargado de trasmitir la información y documentación necesaria.

Tabla 25 Plan de comunicaciones. Tipo de

Comunicación Objetivo de la Comunicación Medio Frecuen

cia Audiencia Encargado Entregable

Reunión inicial

-Introducir y explicar el Proyecto.

Reunión 1 vez

-Sponsor del Proyecto

Gestor de proyecto

-Agenda

-Presentar al equipo de Proyecto

- Gerente de TI - Equipo de Proyecto

-Acta de Constitución

-Ver los objetivos, alcances, requerimientos del Proyecto

-Stakeholders -Acta de Reunión

Reunión Técnica de

Diseño

Discutir y desarrollar soluciones de diseño técnico para el proyecto

Reunión Varias Equipo de Proyecto

Gestor de proyecto

-Agenda

-Acta de Reunión

Reunión de Estado del Proyecto

Repasar e Informar el estado del Proyecto con el equipo

Reunión Mensual

Equipo de Proyecto

Gestor de proyecto

-Informe de Seguimiento -Agenda -Acta de Reunión

Reportes del Estado del Proyecto

Reportar el estado del Proyecto incluyendo actividades, progreso, costos y puntos claves

Reunión Mensual

-Sponsor del Proyecto

Gestor de proyecto

-Reporte de Estado del Proyecto

-Equipo de Proyecto

-Stakeholders

Fuente: (Elaboración propia).

Page 52: Facultad de Ingeniería de Sistemas y Electrónica

52

3.3.5 Plan de riesgos En la siguiente matriz de riesgos se muestra las probabilidades y las posibles amenazas que podrían presentarse durante el desarrollo del proyecto, las cuales tendrían un impacto determinado mostrado en la leyenda de riesgos.

Tabla 26 Matriz de riesgos del proyecto.

Fuente: (Elaboración propia).

Tabla 27 Leyenda de Riesgos e impacto.

Fuente: (Elaboración propia).

Finanzas Externo

RiesgosNivel de

consideración Despido/Renuncia Sanción Cancelación del proyecto No provee a tiempo Falta AtrasosGestor 8 4 2 - - 4 4Desarrollador 5 3 2 - - 5 5Analista de calidad 2 2 2 - 2 3 5Equipos 8 - - - 3 - -Insumos 2 - - - 3 - -VP de Adm. Y finanzas 10 - - 2 - 2 -

Recusos Humanos DesarrolloProbabilidad de amenaza

Page 53: Facultad de Ingeniería de Sistemas y Electrónica

53

3.3.7 Plan de contingencia En los siguientes cuadros de calidad se detallan los riesgos que más impacto podrían tener en el proyecto y su acción de mitigación para prevenir posibles retrasos, de la mano con una acción de contingencia para contrarrestar el retraso de las variables más afectadas según el tipo de riesgo.

Tabla 28 Plan de contingencia - GDH (Gestión del desarrollo humano). ID riesgo

Recu

rsos

Hum

anos

1 Descripción del riesgo Renuncia del personal de trabajo:

Dentro del proyecto uno de los grandes riesgos es que un personal renuncie cuando ello está encaminado, esto afectaría en el tiempo estimado del proyecto. Teniéndose que contratar a un personal idóneo para el puesto, capacitarlo y este personal tendría que ser hábil, audaz, ponerse al corriente y encajar en el tiempo exacto del proyecto.

Acción de mitigación Incentivar al colaborador con bonos y actividades de integración. Recalcar siempre la línea de carrera que existe en la empresa Real plaza.

Acción de contingencia

Se debe realizar la transmisión de conocimientos a todos los integrantes del equipo, para no generar indispensabilidad de ningún colaborador.

Variable más afectada Tiempo y costo Fuente: (Elaboración propia).

Tabla 29 Plan de contingencia - Finanzas. ID riesgo

Recu

rsos

Hum

anos

2 Descripción del riesgo Cancelación del proyecto:

Esta decisión solo es tomada y ordenada por la vise presidencia del área competente (sponsor), El principal motivo es la reducción de costos y el mismo beneficio si es que la realización del proyecto lo realizara una empresa tercera.

Acción de mitigación Cumplir con el proyecto en la fecha pactada.

Acción de contingencia Se debe desarrollar y proponer un mejor plan para mejorar el presupuesto y un mayor beneficio para la empresa para asegurar la continuidad del proyecto.

Variable más afectada Tiempo, presupuesto, alcance. Fuente: (Elaboración propia).

Page 54: Facultad de Ingeniería de Sistemas y Electrónica

54

3.3.8 Diagrama de caso de uso Fig. 21 Diagrama de caso de uso Real Plaza.

Fuente: (Elaboración propia).

Env iar Inf ormación

(from Use Cases)

Env iar alerta consumo excedido

(from Use Cases)

Registrar Datos OLD

(from Use Cases)

Relacionar

(from Use Cases)

<<extend>>

<<extend>>

<<extend>>

Registrar Sustento

(from Use Cases)

<<include>>

Generar Plantilla

(from Use Cases)

Registrar Consumos Agua

(from Use Cases)<<extend>>

Registrar Consumos Electricidad

(from Use Cases)

<<extend>>

Cargar Consumo Masiv o - Agua - Electricidad

(from Use Cases)

<<include>>Registrar Consumos Indiv idual -

Agua(from Use Cases)

Registrar Consumos Indiv idual - Electricidad

(from Use Cases)

Registrar Alícuotas

(from Use Cases)

Registrar Pliego Tarif ario

(from Use Cases)

Registrar Fecha Cierre

(from Use Cases)

Generar Reporte

(from Use Cases)

Asistente Corporativ o de Operacines

(from Actors)

Asistente de Gerente de Mall

(from Actors)

Ver Historial

(from Use Cases)

Registrar Observ ación

(from Use Cases)

Env iar Alertas

(from Use Cases)

<<include>>

Generar sustento masiv o

(from Use Cases)Sistema

(from Actors)

<<include>>

Page 55: Facultad de Ingeniería de Sistemas y Electrónica

55

3.3.9 Diseño y funcionalidad de interfaces – Mockup Registro de alícuotas

Formulario mediante el cual se permitirá la búsqueda, registro, modificación y exportación de las alícuotas según inmueble, año, mes.

Fig. 22 Interface de registro de alícuotas. Operaciones/Registro de alícuotas

Fuente: (Elaboración propia).

Registro de pliego tarifario

Formulario mediante el cual se permitirá la búsqueda, y registro de los pliegos tarifarios según inmueble, año y mes.

Fig. 23 Interface de registro de pliego tarifario. Operaciones/Registro de pliego tarifario

Fuente: (Elaboración propia).

Recolección de información – Electricidad

Formulario principal mediante el cual se permitirá la búsqueda por tipo de consumo, inmueble, año, mes, nombre comercial y local de los locatarios con estado pendiente de registro de consumos de electricidad, también incluye las funcionalidades de:

• Eliminar. • Datos OLD. • Sustentar.

Page 56: Facultad de Ingeniería de Sistemas y Electrónica

56

• Enviar. • Aprobar. • Observar. • Historial. • Relacionar. • Mensaje (Error).

Fig. 24 Interface de Registro automático - Electricidad. Operaciones/Recolección de información/Registro automático

Fuente: (Elaboración propia).

Recolección de información - Agua

Formulario principal mediante el cual se permitirá la búsqueda por tipo de consumo, inmueble, año, mes, nombre comercial y local de los locatarios con estado pendiente de registro de consumos de electricidad.

Fig. 25 Interface principal de registro automático - Agua. Operaciones/Recolección de información/Registro automático

Fuente: (Elaboración propia).

Page 57: Facultad de Ingeniería de Sistemas y Electrónica

57

Recolección de información - Datos OLD

Ventana modal Popup mediante el cual permite el registro de la última carga registrada por el medidor en caso existiera alguna falla.

Fig. 26 Interface de registro de datos OLD. Operaciones/Recolección de información/Registro automático/Datos OLD

Fuente: (Elaboración propia).

Recolección de información - Relacionar

Ventana modal Popup mediante el cual permite asociar a algún locatario a su contrato anterior en caso realice algún cambio en su razón social.

Fig. 27 Interface relacionar. Operaciones/Recolección de información/Registro automático/Relacionar

Fuente: (Elaboración propia).

Recolección de información - Registro automático – Historial

Ventana modal Popup mediante el cual permite la visualización de los sustentos ingresados por:

• Gerente Mall. • Operaciones Mall. • Gerente corporativo. • Asistente corporativo de operaciones.

Page 58: Facultad de Ingeniería de Sistemas y Electrónica

58

Fig. 28 Interface de visualización de historial. Operaciones/Recolección de información/Registro automático/Historial

Fuente: (Elaboración propia).

Recolección de información - Registro manual

Formulario mediante el cual permite el registro de los consumos de forma manual.

Fig. 29 Interface principal de registro de consumos manual. Operaciones/Recolección de información/Registro automático/Manual

Fuente: (Elaboración propia).

Recolección de información - Registro manual – Plantilla

Ventana modal Popup el cual permite la generación de plantilla para la carga masiva de consumos.

Fig. 30 Interface de generación de plantillas. Operaciones/Recolección de información/Registro manual/Plantilla

Fuente: (Elaboración propia).

Page 59: Facultad de Ingeniería de Sistemas y Electrónica

59

Recolección de información - Registro manual - Plantilla Excel

Formato de plantilla que será generada por la interface de generación de plantilla.

Fig. 31 Modelo de plantilla generada. Operaciones/Recolección de información/Registro manual/Plantilla

Fuente: (Elaboración propia).

Recolección de información - Registro manual - Carga data individual electricidad

Ventana modal Popup mediante el cual se realiza la carga individual de los consumos eléctricos del locatario.

Fig. 32 Interface de registro de individual de consumos - Electricidad. Operaciones/Recolección de información/Registro manual/Carga data

Fuente: (Elaboración propia).

Page 60: Facultad de Ingeniería de Sistemas y Electrónica

60

Recolección de información - Registro manual - Carga data individual agua

Ventana modal Popup mediante el cual se realiza la carga individual de los consumos de agua del locatario.

Fig. 33 Interface de registro individual de consumos -Agua. Operaciones/Recolección de información/Registro manual/Carga data

Fuente: (Elaboración propia).

Recolección de información - Registro manual - Carga manual agua masiva

Ventana modal Popup mediante el cual se realiza la carga masiva de los consumos de agua y electricidad del locatario.

Fig. 34 Interface de registro de consumos masivo - Agua - Electricidad. Operaciones/Recolección de información/Registro manual/Carga data

Fuente: (Elaboración propia).

Page 61: Facultad de Ingeniería de Sistemas y Electrónica

61

Registro de fechas de cierre de consumos

Interface mediante el cual permite el registro de las fechas de cierre de ingreso de consumos en los 18 Mall.

Fig. 35 Interface de registro de fecha de cierre de consumos. Operaciones/Registro fecha cierre

Fuente: (Elaboración propia).

Reporte de consumos

Interface que permite generar reporte de los consumos ya ingresados según los filtros seleccionados como:

• Tipo de consumo. • Inmueble. • Año. • Mes. • Nombre comercial. • Local.

Fig. 36 Interface de visualización y reporte de consumos. Operaciones/Recolección de información/Reporte

Fuente: (Elaboración propia).

Page 62: Facultad de Ingeniería de Sistemas y Electrónica

62

Alerta de información de fecha limite – Malls

Formato de aviso de la fecha de cierre para el registro de consumos enviado a los encargados de Mall.

Fig. 37 Modelo de alerta de fecha límite para el registro de consumos. Correo electrónico

Fuente: (Elaboración propia).

Alerta de información de fecha limite - Corporativo

Formato de aviso de los inmuebles que aun cuentan con registros inconclusos, enviados a los encargados de Mall Operaciones corporativo.

Fig. 38 Modelo de alerta de inmuebles con registros pendientes. Correo electrónico

Fuente: (Elaboración propia).

Page 63: Facultad de Ingeniería de Sistemas y Electrónica

63

Sustentos

Interface que permite la descarga de documentos PDF con los sustentos de agua y electricidad del locatario seleccionado.

Fig. 39 Interface de visualización y generación de sustentos. Operaciones/Sustento

Fuente: (Elaboración propia).

Mantener lista de sustentos

Ventana modal Popup que permite buscar, y guardar una lista de locatarios serán tomados en cuanta para la generación de sus respectivos sustentos de agua y electricidad en una ruta File Server.

Fig. 40 Interface de registro de listas masivas. Operaciones/Sustento/Mantener lista masiva

Fuente: (Elaboración propia).

Page 64: Facultad de Ingeniería de Sistemas y Electrónica

64

Modelo de sustentos - Electricidad.

Fig. 41 Modelo de sustento eléctrico.

Fuente: (Elaboración propia).

Modelo de sustentos - Agua.

Fig. 42 Modelo de sustento agua.

Fuente: (Elaboración propia).

Page 65: Facultad de Ingeniería de Sistemas y Electrónica

65

Modelo Carta primer aviso

Tiene lugar cuando el locatario se ha excedido su consumo habitual de electricidad por primera vez.

Fig. 43 Modelo de alerta primer aviso.

Fuente: (Elaboración propia).

Page 66: Facultad de Ingeniería de Sistemas y Electrónica

66

Modelo Carta segundo aviso

Tiene lugar cuando el locatario se ha excedido su consumo habitual de electricidad por segunda vez.

Fig. 44 Modelo de alerta segundo aviso.

Fuente: (Elaboración propia).

Page 67: Facultad de Ingeniería de Sistemas y Electrónica

67

Modelo Carta tercer aviso

Tiene lugar cuando el locatario se ha excedido su consumo habitual de electricidad por tercera vez e informándole que su contrato ha cambiado según las tarifas establecidas.

Fig. 45 Modelo de alerta tercer aviso.

Fuente: (Elaboración propia).

Page 68: Facultad de Ingeniería de Sistemas y Electrónica

68

3.4 Construcción

3.4.1 Diagrama de clases Fig. 46 Diagrama de clases.

Fuente: (Elaboración propia).

Page 69: Facultad de Ingeniería de Sistemas y Electrónica

69

3.4.2 Modelo de base de datos físico Fig. 47 Modelo de Base de datos físico.

Fuente: (Elaboración propia).

Page 70: Facultad de Ingeniería de Sistemas y Electrónica

70

3.4.3 Diagrama de secuencia Registrar alícuotas

Fig. 48 Diagrama de secuencia registro de alícuotas.

Fuente: (Elaboración propia).

Registrar pliego tarifario

Fig. 49 Diagrama de secuencia de registro de pliego tarifario.

Fuente: (Elaboración propia).

Page 71: Facultad de Ingeniería de Sistemas y Electrónica

71

Registrar consumos – Electricidad

Fig. 50 Diagrama de secuencia Registrar consumos – Electricidad.

Fuente: (Elaboración propia).

Registrar consumos - Agua

Fig. 51 Diagrama de secuencia Registrar consumos – Agua.

Fuente: (Elaboración propia).

Page 72: Facultad de Ingeniería de Sistemas y Electrónica

72

Relacionar – Ver historial

Fig. 52 Diagrama de secuencia Relacionar - Ver Historial.

Fuente: (Elaboración propia).

Enviar de alertas

Fig. 53 Diagrama de secuencia de envío de alertas.

Fuente: (Elaboración propia).

Page 73: Facultad de Ingeniería de Sistemas y Electrónica

73

Generar plantilla - Cargar consumo masivo

Fig. 54 Diagrama de secuencia de generación de plantilla y carga consumos masivos.

Fuente: (Elaboración propia).

Registrar consumo individual

Fig. 55 Diagrama de secuencia de registro consumo individual.

Fuente: (Elaboración propia).

Page 74: Facultad de Ingeniería de Sistemas y Electrónica

74

Registrar fecha cierre

Fig. 56 Diagrama de secuencia de registro de fecha cierre.

Fuente: (Elaboración propia).

Generar reporte

Fig. 57 Diagrama de secuencia generación de reporte.

Fuente: (Elaboración propia).

Page 75: Facultad de Ingeniería de Sistemas y Electrónica

75

Enviar alerta consumo excedido

Fig. 58 Diagrama de secuencia de envío de alerta de consumos excedidos.

Fuente: (Elaboración propia).

3.4.4 Diagrama de componentes Fig. 59 Diagrama de componentes.

Fuente: (Elaboración propia).

Page 76: Facultad de Ingeniería de Sistemas y Electrónica

76

3.4.5 Pruebas Anexo N° 1.

3.4.6 Mapa de comportamiento nivel Hardware Fig. 60 Diagrama de componentes.

Fuente: (Real Plaza TI, 2012).

Page 77: Facultad de Ingeniería de Sistemas y Electrónica

77

CAPÍTULO 4

RESULTADOS

4.1 Resultados de los objetivos Objetivo N° 1: Recaudar la información necesaria del área de operaciones para estimar los tiempos y recursos para el análisis desarrollo e implementación del proyecto.

En base a la información recaudada en el capítulo 3, se ha logrado la estimación de los tiempos y los recursos para llevar a cabo la finalización exitosa de proyecto en mención el cual tuvo una duración de 102 días útiles e inicio el 01 de abril del 2015 hasta el 31 de Agosto del 2015.

Fig. 61 Diagrama Gantt Real Plaza.

Fuente: (Elaboración propia).

Page 78: Facultad de Ingeniería de Sistemas y Electrónica

78

Objetivo N° 2: Desarrollar un plan de proyecto para el desarrollo del módulo de consumos.

El plan del proyecto desarrollado sugiere la organización jerárquica de del personal para el análisis desarrollo e implementación del módulo propuesto, mostrado a continuación.

Fig. 62 Organigrama del proyecto consumos.

Fuente: (Elaboración propia).

• VP de Administración y finanzas:

Principal sponsor del proyecto, y es el principal interesado de en la finalización del proyecto propuesto.

• Gerencia de tecnología de la información:

StakeHolder encargado de velar por la finalización exitosa del proyecto.

• Gestor de proyecto:

Encargado de asistir a las reuniones, captar la información necesaria e identificar los actores y caso de uso del módulo propuesto.

• Equipo de desarrollo:

Encargado del desarrollo de cada uno de los formularios del módulo propuesto.

• Calidad:

Encargado de velar por que el modulo propuesto no muestre errores y se realice el pase a producción de forma correcta.

• Infraestructura (Jefe de infraestructura, Administrador de redes y Administrador de servidores):

Encargados de realizar el pase a producción del módulo propuesto.

VP de administración, finanzas y DH

Gerencia de tecnología de la

información

Gestor de proyecto

Equipo de desarrollo Calidad

Jefe de infraestructura

Administrador de redes

Administrador de servidores

Page 79: Facultad de Ingeniería de Sistemas y Electrónica

79

Objetivo N° 3: Modelar mediante UML los procesos fundamentales del área de consumos.

Se han modelado procesos de operaciones, por ende el diagrama de caso de uso generado muestra el WorkFlow actual ya optimizando y los tiempos en cada proceso se han reducido considerablemente, tal como se muestra en el siguiente cuadro.

Tabla 30 Cuadro comparativo de los procesos del área de operaciones. Descripción Flujo de trabajo sin sistema Flujo de trabajo con sistema Recolección y registro de la información levantada desde los medidores hasta el envío al área de operaciones corporativo.

3 días útiles. 1 día útil.

Validación de consumos recaudados. Validado por encargados de al rea de operaciones al recibir la datos.

Validado por el sistema registrar los datos.

Tratamiento de los datos para generar información. 7 días útiles 1 día útil. Generación de reportes de consumos totales de todos los locatarios en los MALL

2 días útiles 3 minutos.

Generación de sustentos de consumos para los locatarios 2 días útiles. 5 minutos. Alertas de registro de consumos antes de la fecha de cierre. No había. Envía alertas. Calidad de información para los sustentos y reportes. Muy bajo. Alto.

Fuente: (Elaboración propia).

Page 80: Facultad de Ingeniería de Sistemas y Electrónica

80

Objetivo N° 4: Realizar el diseño de los prototipos del módulo de consumos.

Gracias a los prototipos realizados, se logró el diseño final en el sistema de cada una de las pantallas del módulo propuesto, tal como se muestra en las siguientes imágenes.

Registro de Alícuotas

Fig. 63 Interface de registro de alícuotas. Operaciones/Registro de alícuotas

Fuente: (Elaboración propia).

Registro de pliego tarifario

Fig. 64 Interface de registro de pliego tarifario. Operaciones/Registro de pliego tarifario

Fuente: (Elaboración propia).

Page 81: Facultad de Ingeniería de Sistemas y Electrónica

81

Registro de consumos automático

Fig. 65 Interface de registro de consumos automático. Operaciones/Recolección de información/Registro Automático

Fuente: (Elaboración propia).

Registrar datos OLD

Fig. 66 Interface Popup de registro de datos OLD. Operaciones/Recolección de información/Registro Automático/Datos OLD

Fuente: (Elaboración propia).

Page 82: Facultad de Ingeniería de Sistemas y Electrónica

82

Historial

Fig. 67 Interface de visualización de historial. Operaciones/Recolección de información/Registro Automático/Historial

Fuente: (Elaboración propia).

Sustentar

Fig. 68 Interface de registro de sustento de consumo. Operaciones/Recolección de información/Registro Automático/Sustento

Fuente: (Elaboración propia).

Page 83: Facultad de Ingeniería de Sistemas y Electrónica

83

Relacionar

Fig. 69 Interface de registro de relacionar. Operaciones/Recolección de información/Registro Automático/Relacionar

Fuente: (Elaboración propia).

Generar plantilla

Fig. 70 Interface de generación de plantillas. Operaciones/Recolección de información/Registro Manual/Plantilla

Fuente: (Elaboración propia).

Page 84: Facultad de Ingeniería de Sistemas y Electrónica

84

Registrar consumo individual - Electricidad

Fig. 71 Registrar consumo individual - Electricidad. Operaciones/Recolección de información/Registro Manual/Carga data - Individual

Fuente: (Elaboración propia).

Registrar consumo individual - Agua

Fig. 72 Registrar consumo individual - Agua. Operaciones/Recolección de información/Registro Manual/Carga data - Individual

Fuente: (Elaboración propia).

Page 85: Facultad de Ingeniería de Sistemas y Electrónica

85

Cargar consumo masivo - Electricidad - Agua

Fig. 73 Interface de carga de consumo masivo - Electricidad - Agua. Operaciones/Recolección de información/Registro Manual/Carga data - Masivo

Fuente: (Elaboración propia).

Registrar fecha cierre

Fig. 74 Interface de Registro de fecha cierre. Operaciones/Registro de fecha cierre

Fuente: (Elaboración propia).

Page 86: Facultad de Ingeniería de Sistemas y Electrónica

86

Generar reporte

Fig. 75 Interface de Generación reporte. Operaciones/Recolección de información/Reporte

Fuente: (Elaboración propia).

Mantener lista masiva

Fig. 76 Interface de registro de lista masiva. Operaciones/Sustento/Mantener lista masiva

Fuente: (Elaboración propia).

Page 87: Facultad de Ingeniería de Sistemas y Electrónica

87

Objetivo N° 5: Modelar mediante UML el diagrama de clases

Al diseñar un modelo de diagrama de clases, se consiguió mantener información segura confiable y fácil de obtener tal como se muestra en la imagen.

Fig. 77 Excel del reporte.

Fuente: (Elaboración propia).

Page 88: Facultad de Ingeniería de Sistemas y Electrónica

88

Objetivo N° 6: Durante la realización de las pruebas funcionales y unitarias se cumplieron con los objetivos propuestos para el correcto funcionamiento en producción:

• Se hallaron controles de texto sin validación de cantidad máxima de caracteres. • Se hallaron controles sin validar solo números. • Se hallaron registros sin bitácora incorporada. • Se hallaron reglas de validación sin cumplir. • Se hallaron nomenclaturas de variables sin cumplir. • Se hallaron variables sin usar.

Las cuales fueron levantadas de forma inmediata, así mimo estas pruebas contribuyeron a eliminar el número de incidencias en producción para finalmente generar un documento con los registros de evidencias correspondientes a las pruebas realizadas.

Page 89: Facultad de Ingeniería de Sistemas y Electrónica

89

4.1.1 Presupuesto

4.1.1.1 Flujo de caja En las siguientes tablas se detallan los materiales, equipos, licencias y los respectivos ingresos y egresos generados para el correcto desarrollo del proyecto de Consumos.

Se especifican los materiales, insumos y sus respectivas cantidades y precios unitarios las cuales se utilizaron durante el desarrollo del proyecto.

Tabla 31Flujo de caja - Materiales e insumos

Fuente: (Elaboración propia)

Se especifican los precios y cantidades de los equipos que se utilizaron de forma activa en cada una de las fases del proyecto tal como análisis, desarrollo y calidad.

Tabla 32Flujo de caja – Equipos

Fuente: (Elaboración propia)

Page 90: Facultad de Ingeniería de Sistemas y Electrónica

90

Se detallan las licencias y sus precios de las herramientas que se adquirieron para el desarrollo satisfactorio del proyecto.

Tabla 33 Flujo de caja - Licencias

Fuente: (Elaboración propia)

Tabla de gastos acumulado de los 5 meses que duro el proyecto.

Tabla 34 Matriz de análisis costo vs tiempo.

Fuente: (Elaboración propia).

Page 91: Facultad de Ingeniería de Sistemas y Electrónica

91

4.1.1.2 Flujo de caja RRHH En el siguiente cuadro se detalla el flujo de caja en los 5 meses que duro proyecto, se detallan el sueldo mensual del colaborador según su cargo y se especifica su porcentaje de participación en el proyecto según el mes correspondiente, finalmente se muestra el grafico del análisis del costo vs tiempo.

Tabla 35 Flujo de caja - Recursos Humanos.

Fuente: (Elaboración propia).

Fig. 78 Curva - Análisis costo vs tiempo.

Fuente: (Elaboración propia).

TOTAL

6,000 6,000 1 GP 100% 6,000.00 100% 6,000.00 10% 600.00 0% - 0% - 12,600.00 4,000 4,000 1 AD 0% - 20% 800.00 100% 4,000.00 50% 2,000.00 10% 400.00 7,200.00 4,000 4,000 1 AD 0% - 20% 800.00 100% 4,000.00 50% 2,000.00 10% 400.00 7,200.00 2,500 2,500 1 DE 0% - 0% - 100% 2,500.00 10% 250.00 0% - 2,750.00 2,500 2,500 1 QA 0% - 50% 1,250.00 0% - 100% 2,500.00 0% - 3,750.00

6,000.00 8,850.00 11,100.00 6,750.00 800.00 33,500.00

Mes-4Mes-3DESARROLLO Y PRUEBAS

Mes-5

TOTALES

Mes-2Mes-1IMPLEMENTACIÓN

Sueldo C. Empresa Cant. CargosINICIO ANÁLISIS Y DISEÑO

- 5,000.00

10,000.00 15,000.00 20,000.00 25,000.00 30,000.00 35,000.00 40,000.00

Mes 1 Mes 2 Mes 3 Mes 4 Mes 5

Curva S - Análisis costo vs tiempo

Page 92: Facultad de Ingeniería de Sistemas y Electrónica

92

4.1.1.3 Flujo de caja del proyecto Se detalla de forma general los egresos de materiales, equipos, licencias y sueldos de los colaboradores y se genera un total en cada uno de los meses que duro el proyecto, finalmente se calcula los montos acumulados del mes 1 al mes 5 que es la duración del proyecto.

Tabla 36 Flujo de caja – egresos.

Fuente: (Elaboración propia).

Page 93: Facultad de Ingeniería de Sistemas y Electrónica

93

4.1.1.4 Flujo de sueldos En la siguiente tabla se detalla los sueldos de los colaboradores involucrados en los principales flujos de trabajo del a rea de operaciones, las cuales fueron tomadas en horas hombre para la determinación del sueldo neto que percibe cada colaborador en su desempeño

Tabla 37 Sueldos por hora de los colaboradores.

Fuente:(Elaboración propia). .

4.1.1.5 Flujo de ingresos y egresos En la siguiente tabla se detallan los ingresos y egresos durante y después del proyecto, donde se percibe la reducción de costos en el área de operaciones desde el mes 6, y desde el mes 10 el valor de la inversión de retorno inicia su incremento a través del tiempo, logrando como objetivo la reducción de costos de operaciones mediante la adquisición de personal operativo de empresas externas.

Tabla 38 Flujo de caja ingresos y egresos.

Fuente:(Elaboración propia).

Recurso Humanos Sueldo (S/.) Sueldo x Hora (S/.) Horas Sueldo Horas (S/.) Días Monto por Días (S/.) Nro. Trabajadores Costo Total por colaboradores (S/.)Asistente de operaciones 2800.00 11.67 8 93.33 30 2800.00 1 2800.00

Registrador de información 2200.00 9.17 8 73.33 30 2200.00 7 15400.00

Total de monto del sueldo por participación de horas de los colaboradores 4037.50 21 S/. 15,400.00

mes-1 mes-2 mes-3 mes-4 mes-5 mes-6 mes-7 mes-8 mes-9 mes-10 totalIngresos 15400.00 15400.00 15400.00 15400.00 15400.00 - Egresos 35,707.41 8,850.00 11,100.00 6,750.00 800.00 63,207.41 Flujo Neto -35,707.41 -8,850.00 -11,100.00 -6,750.00 -800.00 15,400.00 15,400.00 15,400.00 15,400.00 15,400.00 13,792.59 Acumulado -35,707.41 -44,557.41 -55,657.41 -62,407.41 -63,207.41 -47,807.41 -32,407.41 -17,007.41 -1,607.41 13,792.59

FLUJO DE CAJA INGRESOS Y EGRESOS

Page 94: Facultad de Ingeniería de Sistemas y Electrónica

94

4.1.1.6 VAN TIR Tabla 39 Ingresos y egresos del proyecto.

Fuente: (Elaboración propia).

Según el análisis de retorno de inversión del proyecto consumos, queda determinado su viabilidad y se recomienda su ejecución ya que el cálculo del VAN determinan un monto de S/. 9,982.30. y el TIR una cifra mayor al 10%.

Page 95: Facultad de Ingeniería de Sistemas y Electrónica

95

CONCLUSIONES

• Gracias a la recolección de información obtenida del área de operaciones se logró establecer un perímetro del problema, a la vez se logró estimar de forma efectiva y a un 100% los recursos y tiempos necesarios para la culminación exitosa del proyecto.

• La elaboración del plan de proyecto fue de vital importancia para alcanzar la culminación exitosa del módulo planteado en un tiempo de 102 días útil, debido a que se contemplaron los riesgos, recursos y tiempos para cada una de las tareas planteadas.

• Con la realización de los modelos de caso de uso del área de operaciones se logró una mejor comprensión del flujo que realiza el área en mención, de tal manera que se pudieron identificar y documentar todos los requerimientos funcionales del proyecto.

• Con la elaboración de los prototipos o interfaces Mockup y la aprobación de cada una de las pantallas con los usuarios finales involucrados, garantizamos su fácil uso y su máximo rendimiento, actualmente es usado por más de 44 usuarios.

• El desarrollo del diagrama de clases contribuyó a mapear de forma gráfica la estructura del sistema y poder acoplar las nuevas clases con las ya existentes, de tal manera que el impacto del nuevo módulo fue casi nulo con respecto a los módulos relacionados.

• Las pruebas funcionales y unitarias fueron de vital y alta importancia antes del pase a producción, las cuales aseguraron el correcto funcionamiento del módulo propuesto, actualmente solo llegan no más de 2 incidencias por mes del módulo de consumos.

Page 96: Facultad de Ingeniería de Sistemas y Electrónica

96

RECOMENDACIONES • El módulo desarrollado podrá recaudar la información de forma automática

obteniendo los datos de los archivos planos que generarán los nuevos medidores que se incorporaran en cada MALL.

Fig. 79 Ingresos y egresos del proyecto.

Fuente: (Elaboración propia).

Page 97: Facultad de Ingeniería de Sistemas y Electrónica

97

Tabla 40 Glosario de términos. Termino Descripción Locatario Persona natural o jurídica dueño de marca quien ha rentado un local

por un tiempo determinado. GI Área de gestión inmobiliaria encargado de realizar la facturación de los

locatarios. Módulo En la programación, los módulos suelen estar (no necesariamente)

organizados jerárquicamente en niveles, de forma que hay un módulo principal que realiza las llamadas oportunas a los módulos de nivel inferior.

Consumo Cantidad de energía o agua consumida por el locatario el cual es obtenido desde los medidores.

Capas Arquitectura de desarrollo. Gestor de proyectos Encargado de levantar la información y velar por la culminación de la

misma Modal PopPup Ventana emergente web. Mockup Interfaces de prototipo.

Fuente: (Elaboración propia).

Page 98: Facultad de Ingeniería de Sistemas y Electrónica

98

Anexo 1 Registro de evidencias.

Page 99: Facultad de Ingeniería de Sistemas y Electrónica

99

Bibliografía

Craig Larman (2005). Applying UML and patterns: an introduction to object-oriented analysis and design and the unified process.

Fernando Berzal (2004). EL lenguaje de modelo unificado Grady Booch, Jim Rumbaugh e Ivan Jacobson.

Jorge Sánchez (2004). Bases de datos relacionales.

Mario Alfonso Ordinola Castillo (2009).Diseño de un sistema de control de consumos de energía eléctrica en las comunidades campesinas, recuperado el 07 de febrero de 2015 de http://tesis.pucp.edu.pe/

IBM Rational Application Developer for WebShepre. Recuperado el 07 de febrero de 2015, de http://www-01.ibm.com/software/awdtools/developer/application/

Agencia Nacional de Energía Eléctrica. Manual para Elaboración de Programas de Eficiencia Energética (2006). Recuperado el 07 de febrero de 2015, de www.aneel.gov.br.

Miguel Ángel Álvarez (2013). Nociones básicas sobre AJAX en jQuery. Recuperado el 07 de febrero de 2015, de http://www.desarrolloweb.com/articulos/entendiendo-ajax-jquery.html

Organismo supervisor de la inversión en energía y minería: Actas resoluciones y tarifas electicas (2015), de http://www2.osinergmin.gob.pe/

Definición del lenguaje de programación C#. Recuperado de https://msdn.microsoft.com/es-pe/library/kx37x362.aspx

Definición de HTML. Recuperado de https://es.wikipedia.org/wiki/HTML

Definición de CSS. Recuperado de https://es.wikipedia.org/wiki/Hoja_de_estilos_en_cascada

Definición de Entity Framework. https://es.wikipedia.org/wiki/ADO.NET_Entity_Framework

Page 100: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 1 de 22

CONTROL DE VERSIONES

Versión Elaborado por Aprobado por Fecha Motivo

1 Sergio Martínez Jiménez 11/08/2015 Versión Inicial

Page 101: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 2 de 22

1. DATOS DEL PROYECTO:

Código del Proyecto Nombre del Proyecto

PROY-ADV-082015-001 ADVANCE REAL ESTATE - CONSUMOS

2. DATOS DEL REQUERIMIENTO:

Codigo del Requerimiento

Descripción del Requerimiento

3. DATOS DE PARTICIPANTES:

Nombre de participantes Rol Área

Sergio Martínez Analista de Calidad TI

4. AMBIENTE DE PRUEBAS

Marcar con una “X” el casillero correspondiente del ambiente que será utilizado para las pruebas

QA X Desarrollo Ambas

Señale las actividades realizadas para la habilitación del ambiente de pruebas

Page 102: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 3 de 22

Actividades Si / No Comentarios adicionales sobre la actividad

Data

Replica de data de producción al ambiente de pruebas

SI

Alteración de datos sensible

SI

Software y Hardware

Replica de estructura de BD de producción al ambiente de pruebas

SI

Replica de estructura de componentes de producción al ambiente de pruebas

SI

Otros requerimientos (Indique requerimientos adicionales que se deban realizar para la habilitación del ambiente)

No aplica No

5. LISTADO DE CASOS DE PRUEBA FUNCIONAL (Para ser validados por el Usuario)

Los escenarios considerados para los casos de prueba funcionales son los siguientes:

Page 103: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 4 de 22

Código del Caso de Prueba

Caso de Uso Escenario Tipo de Prueba

Se ejecutó pruebas? (*)

Motivo por el cual no se ejecutó la

prueba

CU01E01 CU01: Verificar menu E01: verificar menú - Verificar la opcion de

menu sustento en el menu operaciones Prueba Funcional

SI

CU01E02 CU01: Verificar menu

E02: verificar menú - Verificar la

deshabilitación de la opcion Facturacion de

servicios en el menu de Facturacion

Prueba Funcional

SI

CU01E03 verificar recoleccion de

informacion registro automatico

E02: verificar recoleccion de informacion

registro automatico - consumos Prueba Funcional

SI

CU01E04 Recoleccion de Informacion –

Registro Automatico

E02: Recoleccion de Informacion – Registro

Automatico - verificar la implementacion de

las columnas de Tarifa y Cliente

Prueba Funcional

SI

CU01E05 CU01: Verificar el registro del

pliego tarifario

E03: verificar el registro del pliego tarifario

– cantidades Prueba Funcional

SI

CU01E06

CU01: Verificar el registro de

alícuotas

E04: Verificar el registro de alícuotas –

cantidades Prueba Funcional

SI

CU01E07 CU01: Verificar facturación

automatica-

E04: Verificar facturación automatica-

servicio de agua y electricidad Prueba Funcional

SI

CU01E08 CU01: Verificar facturación

automatica-

E04: Verificar facturación automatica-

Generar liquidaciones Prueba Funcional

SI

CU02E01

CU02: Verificar sustentos a

solicitud

Verificar sustentos a solicitud - exportacion

de documentos a solicitud Prueba Funcional

SI

CU02E01 CU02: Verificar sustentos a

solicitud

Verificar sustentos a solicitud – verificar

cantidades de liquidacion Prueba Funcional

Page 104: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 5 de 22

Código del Caso de Prueba

Caso de Uso Escenario Tipo de Prueba

Se ejecutó pruebas? (*)

Motivo por el cual no se ejecutó la

prueba

Verificar sustentos a solicitud Verificar sustentos a solicitud -

CU02E02 CU02: Verificar sustentos a

solicitud

verificar sustentos a solicitud - agregar o

retirar clientes del proceso automático de

GENERACION DE SUSTENTO MASIVO

Prueba Funcional

SI

CU02E03 CU02: Verificar sustentos a

solicitud

CU02: Verificar sustentos a solicitud

Proceso automático de generaración

masiva archivos de sustento por Inmueble.

Prueba Funcional

SI

(*) Desarrollo indicará en esta sección: SI: Se ejecutó pruebas - NO: Se ejecutó pruebas

6. DETALLE DE LOS CASOS DE PRUEBA FUNCIONAL (Para ser validados por el Usuario) <Los casos de prueba funcionales deben encontrarse especificados de tal forma que pueda ser entendible por el usuario>

Page 105: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 6 de 22

6.1 CU01E01 - CU01: Verificar Menu E01: Verificar la opcion de menu sustento en el menu operaciones

Puntos de

Control:

Verificar Menu

Datos

utilizados:

USR:RP0073, Perfil:56

Flujo Básico

Paso Instrucción Resultados

Esperados

Resultados Obtenidos

1

En el sistema

ingresamos al

menú

OPERACIONES

-Se verifica

que se agrego

el Sub menú

Sustento

6.1 CU01E01 - CU01: Verificar Menu E01: Deshabilitación de la opcion Facturacion de servicios en el menu de Facturacion

Page 106: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 7 de 22

Puntos de

Control:

Verificar Menu

Datos

utilizados:

USR:RP0073, Perfil:56

Flujo Básico

Paso Instrucción

Resultados

Esperados

Resultados Obtenidos

2

En el sistema

ingresamos al

menú

FACTURACION

y verificamos

que no se

encuentra el

Sub Menú

Facturacion

de servicios

- Se verifica

que se

deshabilito el

Sub menú

Facturacion de

Servicios

6.2 CU01E02 - CU01: Verificar recoleccion de informacion registro automatico E02: verificar recoleccion de informacion registro automatico - consumos

Page 107: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 8 de 22

Puntos de

Control:

Verificar recoleccion de informacion registro automatico

Datos

utilizados:

USR:RP0073, Perfil:56

Flujo Básico

Paso

Instrucción

Resultados

Esperados Resultados Obtenidos

3

En el sistema

eleigimos el

menú

recoleccion

de

información y

le damos clic

en reporte

Del Inmueble

Real plaza

Chiclayo – local

LC-118 que

tomaremos

para el calculo

de la

liquidacion

Verificamos que

nos muestra las

cantidades o

los consumos

registrados en

el menú

recolección dei

nformacion

registro

automatico

6.2 CU01E02 - CU01: Recoleccion de Informacion – Registro Automatico E02: Recoleccion de Informacion – Registro Automatico - verificar la

implementacion de las columnas de Tarifa y Cliente

Page 108: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 9 de 22

Puntos de

Control:

Recoleccion de Informacion – Registro Automatico

Datos

utilizados:

USR:RP0073, Perfil:56

Flujo Básico

Paso Instrucción

Resultados

Esperados

Resultados Obtenidos

4

En el sistema

eleigimos el

menú

Operaciones

RECOLECCIÓN

DE

INFORMACIÓN

> REGISTRO

AUTOMÁTICO

Verificamos que

aparece la

columna Tarifa

y Cliente

6. Flujo Básico

6.3 CU01E02 - CU01: Verificar el registro del pliego tarifario E03: Verificar el registro del pliego tarifario – cantidades

Page 109: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 10 de 22

Puntos de

Control:

Verificar el registro del pliego tarifario

Datos

utilizados:

USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Resultados

Esperados Resultados Obtenidos

1

En el sistema

eleigimos el

menú

Operaciónes y

clic en la opcion

Registro del

pliego

Tarifario del

Inmueble Real

plaza Chiclayo

Cantidades que

tomaremos

como

referencia para

el calculo de la

liquidacion

Verificamos que

el sistema

muestra el

todas las

cargas

registradas y

también

muestra los

botones editar

y eliminar

6. Flujo Básico

6.3 CU01E02 - CU01: Verificar el registro de alícuotas E03: Verificar el registro de alícuotas – cantidades

Page 110: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 11 de 22

Puntos de

Control:

Verificar el registro de alícuotas

Datos

utilizados:

USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Resultados

Esperados Resultados Obtenidos

1

En el sistema

eleigimos el

menú

Operaciónes y

clic en la opcion

Alicuotas del

Inmueble Real

plaza Chiclayo

Cantidades que

tomaremos

como

referencia para

el calculo de la

liquidacion

Verificamos que

el sistema

muestra la

cantidades

registradas

6. Flujo Básico

Page 111: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 12 de 22

6.4 CU01E02 - CU01: Verificar Registro de pliego tarifario.E04: Verificar Registro de pliego tarifario.

Puntos de Control: Verificar Registro de pliego tarifario.

Datos utilizados: USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Resultados

Esperados Resultados Obtenidos

1

En el menú

operaciones

sub menú

registro de

pliego tarifario.

Seleccionadmos

inmueble y el

periodo, botón

buscar para

listar lso

resultados

según filtro.

Verificamos

que se listen

todos lso datos

registrados

previa

seleccione de

filtros, en caso

contrario no

existan datos

se mostrara un

texto centra

diciendo “Sin

datos para

mostrar”.

6. Flujo Básico

Page 112: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 13 de 22

6.4 CU01E02 - CU01: Verificar sustentos a solicitud E04: Verificar sustentos a solicitud - exportacion de documentos

Puntos de

Control:

Verificar sustentos a solicitud

Datos

utilizados:

USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Resultados

Esperados Resultados Obtenidos

1

En el menú

Operaciones

y el sub menú

SUSTENTO

elegimos tipo

de consumo

“Lectura de

energía

electrica”

Inmuele “Real

plaza Chiclayo”

Año “2015” y

mes de octubre

Y local “LC-

118” y clic en

el botón

“Buscar” y clic

en el botón

sustento de la

grilla

Verificamos que el

sistema muestra en

una grilla la liquidación

generada

recientemente del

contrato ”13” local “LC-

118” con los campos

Inmuble, cliente, local,

nombre comercial,

periodo, consumo y

descarga un archivo

PDF con nombre

SUSTENTO_PERIODO_CONTRATO

_NOMBRECOMERCIAL”

6. Flujo Básico

Page 113: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 14 de 22

6.4 CU01E02 - CU01: Verificar sustentos a solicitud E04: Verificar sustentos a solicitud – Carga Regular BT5

Puntos de

Control:

Verificar sustentos a solicitud

Datos

utilizados:

USR:RP0073, Perfil:11

Paso

Instrucción

Resultad

os

Esperado

s

Resultados Obtenidos

Tomamos como

referencia el

consumo del

contrato para

verificar las

cantidades de la

liquidacion

teniendo la

formula de

carga regular

BT5= Cargo fijo + energía activa + electrificación rural + alumbrado público + aire acondicionado

por consumo

siendo el

resutado de la

liquidacon de

carga regular

774.99

Page 114: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 15 de 22

Verificar sustentos a solicitud

USR:RP0073, Perfil:11

Resultados Obtenidos

Page 115: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 16 de 22

6.4 CU01E02 - CU01: Verificar sustentos a solicitud E04: Verificar sustentos a solicitud – Carga Adicional BT5

Puntos de

Control:

Verificar sustentos a solicitud

Datos

utilizados:

USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Resultados

Esperados Resultados Obtenidos

1

6. Flujo Básico

Page 116: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 17 de 22

Puntos de

Control:

Verificar sustentos a solicitud

Datos

utilizados:

USR:RP0073, Perfil:11

Flujo Básico

Resultados Obtenidos

6. Flujo Básico

Page 117: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 18 de 22

6.4 CU01E02 - CU01: Verificar registro de lista masiva E04: Verificar registro de lista masiva

Puntos de

Control:

Verificar registro de lista masiva

Datos

utilizados:

USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Resultados

Esperados Resultados Obtenidos

1

- En el sistema

Ingresamos al

menú

Operaciones

sub Menu

sustento Clic en

el botón

mantener

Lista masiva

elegimos real

plaza Chiclayo

y clic en buscar

Verificamos que

el sistema

muestra una

ventana con

dos partes

clientes

disponibles y

clientes en lista

de envio

masivo y nos

permitirá

mover clientes

6. Flujo Básico

6.3 CU01E02 - CU01: Verificar registro de fecha cierre E04: Verificar registro de fecha cierre.

Page 118: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 19 de 22

Puntos de Control: Verificar registro de fecha cierre.

Datos utilizados: USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Res. Esperados Resultados Obtenidos

1

Seleccionam

os el menú

operaciones

y sub menú

registro de

fecha cierre,

se mostrara

un filtro con

los años

disponibles y

12

calendarios

para

seleccionar 1

fecha por

cada mes.,

Seleccionamos 1

fecha por cada

mes luego

presionamos el

botón grabar

para registrar

las fecha de

cierre en la base

de datos.

6. Flujo Básico

Page 119: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 20 de 22

6.4 CU01E02 - CU01: Verificar Registro de cargas individual E04: Verificación de registro de consumos individual.

Puntos de Control: Verificar registro de cargas individual

Datos utilizados: USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Res. Esperados Resultados Obtenidos

1

Seleccionam

os el menú

operaciones

y sub menú

registro

automatico

se abrirá

una ventana

moda

popup.

Seleccionamos

tipo de

consumo,

inmueble,

cliente, local,

nombre

comercial y

periodo.

Insertamos los

datos

corresopndiente

s y guardar.

6. Flujo Básico

Page 120: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 21 de 22

6.5 CU01E02 - CU01: Verificar registro de carga masiva Excel. E04: Verificar registro de carga masiva Excel.

Puntos de Control: Verificar registro de carga masiva Excel.

Datos utilizados: USR:RP0073, Perfil:11

Flujo Básico

Paso Instrucción Res. Esperados Resultados Obtenidos

1

Seleccionam

os el menú

operaciones

y sub menú

registro

automatico

/pestaña

masiva.

Seleccionamos

el archivo Excel

y presionamos

el botón

registrar, para

guardar los

consumos en la

BD.

6. Flujo Básico

Page 121: Facultad de Ingeniería de Sistemas y Electrónica

PLAN DE PRUEBAS

Tecnología de la Información

Jefatura --

Clasificación de la Información: Confidencial / Uso Interno

Plan de pruebas Página 22 de 22

1. DISCREPANCIAS / ACUERDOS Enunciar las discrepancias encontradas en la ejecución de las pruebas

Item Descripción

1 Ninguno

2. ESPECIFICACIONES DEL USUARIO

Periodo de Tiempo de Puesta en Producción:

Fecha Inicio: 31.08.2015 Fecha Fin: 31.08.2015