UNIVERSIDAD TCNICA DE ORURO

FACULTAD NACIONAL DE INGENIERA

INGENIERA DE SISTEMAS E INFORMTICA

PROYECTO DE GRADO DIRIGIDO EN BORRADOR

SISTEMA DE INFORMACIN WEB

GEOREFERENCIADO
PAR A E L D E PAR TAM E N TO D E
M E D I C I N Y TAR I FAS D E E L F E O S . A .

POR: WINDSOR ARNALDO MONTAO CALDERON

TUTOR: ING. RONALD HUANCA CALLE

ENERO, 2015

ORURO BOLIVIA

INDICE GENERAL
Dedicatoria
Agradecimientos
ndice
Resumen

i
ii
iii
iv
NDICE

INTRODUCCIN
ANTECEDENTES
PLANTEAMIENTO DEL PROBLEMA
OBJETO DE ESTUDIO
OBJETIVOS
OBJETIVO GENERAL
OBJETIVOS ESPECFICOS
CAMPO DE ACCIN
IDEA A DEFENDER
CRITERIO DE EVALUACIN DE LA IDEA A DEFENDER
JUSTIFICACIONES
JUSTIFICACIN TCNICA
JUSTIFICACIN SOCIAL
ALCANCES
LIMITACIONES
APORTES
APORTE TERICO
APORTE PRCTICO
APORTE ACADMICO
INGENIERA DEL PROYECTO
CAPTULO I
MARCO TERICO
1.............................................................................................................. MARCO TERICO
1.1

GENERALIDADES

1.2

LA EMPRESA DE LUZ Y FUERZ ELECTRICA DE ORURO S.A.

1.2.1
1.3

DISPOSICIONES GENERALES

QUE ES UN SISTEMA?

1.3.1

SISTEMA DE INFORMACION

1.4

CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN

1.5

INTERNET

1.5.1

APLICACIONES WEB.

1.5.2 VENTAJAS DE LAS APLICACIONES WEB

CAPTULO I
1

MARCO TERICO

1.1

GENERALIDADES

1.2

LA EMPRESA DE LUZ Y FUERZ ELECTRICA DE ORURO S.A.

1.2.1
1.3
1.3.1

DISPOSICIONES GENERALES
QUE ES UN SISTEMA?
SISTEMA DE INFORMACION

1.4

CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN

1.5

INTERNET

1.5.1

APLICACIONES WEB.

1.5.2 VENTAJAS DE LAS APLICACIONES WEB

INTRODUCCIN..........................................................................................................................................
ANTECEDENTES.........................................................................................................................................
PLANTEAMIENTO DEL PROBLEMA........................................................................................................
OBJETO DE ESTUDIO.....................................................................................................
OBJETIVOS....................................................................................................................
OBJETIVO GENERAL.........................................................................................................
OBJETIVOS ESPECFICOS..................................................................................................
CAMPO DE ACCIN....................................................................................................................................
IDEA A DEFENDER......................................................................................................................................
CRITERIO DE EVALUACIN DE LA IDEA A DEFENDER......................................................................
JUSTIFICACIONES......................................................................................................................................
JUSTIFICACIN TCNICA..................................................................................................
JUSTIFICACIN SOCIAL....................................................................................................
ALCANCES...................................................................................................................................................
LIMITACIONES............................................................................................................................................
APORTES.......................................................................................................................................................
APORTE TERICO..........................................................................................................
APORTE PRCTICO........................................................................................................
APORTE ACADEMICO.....................................................................................................
INGENIERIA DEL PROYECTO.................................................................................................................

CAPTULO I.......................................................................................................................................................
1

MARCO TERICO................................................................................................................................
1.1

GENERALIDADES.............................................................................................. 13

1.2

LA EMPRESA DE LUZ Y FUERZ ELECTRICA DE ORURO S.A................................13

1.2.1
1.3

DISPOSICIONES GENERALES.......................................................................13
QUE ES UN SISTEMA?..................................................................................... 14

1.3.1

SISTEMA DE INFORMACION........................................................................14

1.4

CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN......................................15

1.5

INTERNET......................................................................................................... 17

1.5.1

APLICACIONES WEB.................................................................................... 17

1.5.2

VENTAJAS DE LAS APLICACIONES WEB.......................................................18

1.5.3

HIPERTEXTO, MULTIMEDIA, E HIPERMEDIA..................................................18

1.5.4

HIPERTEXTO................................................................................................ 18

1.5.5

MULTIMEDIA................................................................................................ 19

1.5.6

HIPERMEDIA............................................................................................... 19

1.5.7

ARQUITECTURA DE LA WEB........................................................................19

1.5.8

PGINAS ESTTICAS.................................................................................... 21

1.5.9

PGINAS DINMICAS.................................................................................. 21

1.5.10

EL PROTOCOLO........................................................................................... 21

1.5.11

LOCALIZADOR UNIFORME DE RECURSOS (URL).........................................22

1.5.12

LA WORLD WIDE WEB O LA WEB................................................................22

1.5.13

FUNCIONAMIENTO DE LA WEB...................................................................22

1.5.14

NAVEGADORES........................................................................................... 22

1.5.15

HTML.......................................................................................................... 23

1.5.16

PHP............................................................................................................. 24

1.5.17

SERVIDOR APACHE..................................................................................... 25

1.5.18

MYSQL........................................................................................................ 25

1.5.19

JAVASCRIPT................................................................................................. 27

1.6

METODOLOGA................................................................................................. 27

1.6.1

EL PROCESO UNIFICADO DE RATIONAL......................................................27

1.6.2

PROCESO DIRIGIDO POR CASOS DE USO...................................................28

1.6.3

PROCESO ESTA CENTRADO EN LA ARQUITECTURA....................................29

1.6.4

PROCESO ITERATIVO E INCREMENTAL.......................................................31

1.6.5

EL PRODUCTO............................................................................................ 32

1.6.6

FASES DE DESARROLLO DEL SOFWARE......................................................34

1.6.7

RUP AGIL.................................................................................................... 38

CAPTULO II.................................................................................................................................................
2

DETERMINACIN DE REQUERIMIENTOS......................................................................................
2.1

GENERALIDADES.............................................................................................. 40

2.2

DESCRIPCIN DEL NEGOCIO............................................................................40

2.2.1

MODELO DE CASOS DE USO DEL NEGOCIO................................................40

2.2.2

ESPECIFICACION DE ACTORES DEL NEGOCIO.............................................42

2.3

METODO VORD................................................................................................ 44

2.3.1

LLUVIA DE IDEAS........................................................................................ 45

2.3.2

ESTRUCTURACION DE LOS PUNTOS DE VISTA............................................46

2.3.3

JERARQUIA DE LOS PUNTOS DE VISTA........................................................47

2.4

DETERMINACION DE REQUERIMIENTOS...........................................................47

2.4.1

REQUERIMIENTOS FUNCIONALES...............................................................47

2.4.2

REQUERIMIENTOS NO FUNCIONALES.........................................................48

CAPTULO III................................................................................................................................................
3

ANLISIS...............................................................................................................................................
3.1

GENERALIDADES.............................................................................................. 50

3.2

MODELO DE LOS CASOS DE USO DEL SISTEMA................................................50

3.2.1

IDENTIFICACION DE ACTORES....................................................................50

3.2.2

DESCRIPCION DE LOS ACTORES.................................................................51

3.2.3

DESCRIPCION DE LOS CASOS DE USO........................................................54

CAPTULO IV................................................................................................................................................
4

DISEO..................................................................................................................................................
4.1

GENERALIDADES.............................................................................................. 80

4.2

DIAGRAMA DE SECUENCIA...............................................................................80

4.3

DIAGRAMA DE CLASES PERSISTENTES.............................................................84

4.4

DIAGRAMA DE CONTROL..................................................................................85

4.5

DIAGRAMA DE PAQUETES................................................................................. 86

CAPTULO V.................................................................................................................................................
5

IMPLEMENTACIN..............................................................................................................................
5.1

GENERALIDADES.............................................................................................. 88

5.2

DIAGRAMA DE COMPONENTES.........................................................................88

5.3

DIAGRAMA DE DESPLIEGUE..............................................................................89

5.4

MODELO RELACIONAL...................................................................................... 90

5.5

DICCIONARIO DE DATOS..................................................................................91

5.6

INTERFAZ DEL SISTEMA....................................................................................96

CAPITULO VI..............................................................................................................................................102

COSTO DEL SISTEMA........................................................................................................................102

6.1

ESTIMACIN DE COSTO DEL SOFTWARE........................................................102

6.1.1

METODOLOGA DE PUNTOS DE CASOS DE USO (UCP)..............................102

6.1.2

FACTOR DE PESO DE LOS ACTORES INVOLUCRADOS...............................102

6.1.3

FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UAW).................103

6.1.4

PUNTOS DE CASIS DE USO SIN AJUSTAR (UUCP)......................................104

6.1.5

EVALUAR LOS FACTORES DE COMPLEJIDAD TECNICA (TCF)......................104

6.1.6

EVALUAR FACTORES AMBIENTALES (EF)...................................................105

CAPITULO VII.............................................................................................................................................110
7

PRUEBAS DEL SISTEMA...................................................................................................................110

7.1

GENERALIDADES............................................................................................ 110

7.2

METODO DELPHI- PREGUNTA A EXPERTOS.....................................................110

7.2.1

FASE DE PREPARACION............................................................................. 110

7.2.2

FASE DE CONSULTA.................................................................................. 111

7.2.3

FASE DE CONSENSO................................................................................. 112

CAPITULO VI..............................................................................................................................................119
8

CONCLUSIONES Y RECOMENDACIONES.....................................................................................119
8.1

CONCLUSIONES.............................................................................................. 119

8.2

RECOMENDACIONES...................................................................................... 119

INDICE DE FIGURAS
Figura 1-1. Arquitectura Cliente Servidor..................................................................18
Figura 1-2 El RUP guiado por casos de uso.........................................................................27
Figura 1-3 Proceso del Desarrollo.................................................................................... 31
Figura 1-4 Proceso Unificado de Desarrollo de software............................................36
Figura 2-1 Diagrama de Casos de uso del Negocio..................................................39
Figura 2-2 Diagrama Lluvia de Ideas.........................................................................43
Figura 2-3 Jerarqua de los Puntos de Vista...............................................................45
Figura 3-1 Identificacin de actores..........................................................................48
Figura 3-2 Diagrama de Casos de Uso del Sistema...................................................52
Figura 3-3 Pantalla Autentificar Usuario....................................................................53
Figura 3-4 Pantalla Gestionar Usuario.......................................................................55
Figura 3-5 Pantalla Gestionar Usuario Registrar usuario.........................................55
Figura 3-6 Pantalla Gestionar Usuario Actualizar usuario.......................................56
Figura 3-7 Pantalla Gestionar Usuario Eliminar Usuario..........................................56
Figura 3-8 Pantalla Gestionar Usuario cambiar Contrasea....................................57
Figura 3-9 Pantalla Gestionar Cliente........................................................................60
Figura 3-10 Pantalla Gestionar Cliente Registra Cliente..........................................61
Figura 3-11 Pantalla Gestionar Cliente Actualizar Cliente.......................................61
Figura 3-12 Pantalla Gestionar Cliente Eliminar Cliente..........................................62
Figura 3-13 Pantalla Gestionar Cliente Datos Tcnicos...........................................62
Figura 3-14 Pantalla Gestionar Cliente Coordenadas Geo referenciadas................63
Figura 3-15 Pantalla Gestionar Cliente Observaciones Cliente...............................63
Figura 3-16 Pantalla Gestionar Datos Georeferenciados...........................................68
Figura 3-17 Pantalla Gestionar Datos Georeferenciados Coordenadas
Georeferenciadas...................................................................................................... 69
Figura 3-18 Pantalla Gestionar Datos Georeferenciados Actualizar Coordenadas. .69
Figura 3-19 Pantalla Gestionar Datos Georeferenciados Asignar Imagen...............70
Figura 3-20 Pantalla Generar Reporte.......................................................................74
Figura 4-1 Diagrama Gestionar usuario-registrar......................................................78
Figura 4-2 Diagrama Gestionar usuario - Actualizar..................................................79
Figura 4-3 Diagrama Gestionar Usuario- Eliminar.....................................................79
Figura 4-4 Diagrama Gestionar usuario- Cambiar Contrasea..................................80
Figura 4-5 Diagrama Gestionar Cliente - Registrar....................................................80
Figura 4-6 Diagrama Gestionar Cliente -Actualizar....................................................81
Figura 4-7 Diagrama Gestionar Cliente - Eliminar.....................................................81
Figura 4-8 Diagrama de Clases Persistentes.............................................................82
Figura 4-9 Diagrama de Control................................................................................ 83
Figura 4-10 Diagrama de Paquetes...........................................................................84
Figura 5-1 Diagrama de Componentes.................................................................................. 86
Figura 5-2 Diagrama de Despliegue..........................................................................87
Figura 5-3 Modelo Relacional............................................................................................ 88
Figura 5-4 Interfaz gestionar Usuario........................................................................95
Figura 5-5 Interfaz gestionar Usuario: Registrar........................................................95
Figura 5-6 Interfaz gestionar Usuario: Actualizar......................................................96
Figura 5-7 Interfaz gestionar Usuario: Eliminar.........................................................96
Figura 5-8 Interfaz gestionar Usuario: Cambiar Contrasea......................................97
Figura 5-9 Interfaz Gestionar Cliente:........................................................................97

Figura 5-10 Interfaz Gestionar Datos Georeferenciados............................................98

INDICE DE TABLAS
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla
Tabla

2-1 Especificacin Actor del Negocio Gerente General....................................39

2-2 Especificacin Actor del Negocio Superintendente Comercial...................40
2-3 Especificacin Actor del Negocio Supervisor de Medicin y Tarifas............40
2-4 Especificacin Actor del Negocio Administrado.........................................40
2-5 Especificacin Actor del Negocio Personal Administrativo.........................41
2-6 Especificacin Actor del Negocio Tcnico de laboratorio............................41
2-7 Estructuracin de los puntos de vista........................................................44
2-8 Estructuracin de los puntos de vista........................................................44
2-9 Requerimientos Funcionales......................................................................45
2-10 Requerimientos No Funcionales...............................................................46
3-1 Descripcin de Actores - Usuario...............................................................49
3-2 Descripcin de Actores - Administrador.....................................................49
3-3 Descripcin de Actores Gerente general.................................................50
3-4 Descripcin de Actores Superintendente Comercial................................50
3-5 Descripcin de Actores Supervisor de Medicin y Tarifas........................50
3-6 Descripcin de Actores Tcnico de laboratorio........................................51
3-7 Descripcin de Actores Personal Administrativo......................................51
3-8 Descripcin Caso de uso Autentificar Usuario.........................................53
3-9 Descripcin Caso de uso Gestionar Usuario............................................57
3-10 Descripcin Caso de Uso Gestionar Cliente...........................................64
3-11 Descripcin Caso de Uso Gestionar datos Georeferenciados................70
3-12 Descripcin Caso de uso Generar reporte.............................................74
5-1 Tabla Usuario............................................................................................. 89
5-2 Tabla departamento................................................................................... 89
5-3 Tabla cargo................................................................................................. 90
5-4 Tabla Superintendencia.............................................................................. 90
5-5 Tabla ObservacionesCliente.......................................................................90
5-6 Tabla Cliente.............................................................................................. 91
5-7 Tabla categorias......................................................................................... 91
5-8 Tabla datostecnicos.................................................................................... 91
5-9 Tabla Medidor............................................................................................. 92
5-10 Tabla representantelegal..........................................................................92
5-11 Tabla datosgeoreferenciados...................................................................93
5-12 Tabla ImagenesRuta................................................................................. 94

INTRODUCCIN
Con el surgimiento de nuevas tecnologas a nivel mundial y el fenmeno de la globalizacin, los
pases desarrollados y subdesarrollados sin mitigar esfuerzos se integran a este campo
tecnolgico para emplear modernos procesos y maquinaria de ltima generacin para obtener
productos y servicios con altos niveles de calidad.
La aplicacin de nuevos conocimientos en las instituciones y empresas pblicas o privadas en
Bolivia, resultan muy efectivas para la integracin de la informacin y tecnologa, permitiendo
optimizar procesos, toma de decisiones, formulacin de polticas y procedimientos, con el fin de
lograr los objetivos con mayor eficiencia.
Existen empresas de servicio en la ciudad de Oruro dedicadas a la distribucin de gas, agua y
energa elctrica, estas empresas tienden a invertir una parte sustancial de sus ingresos en el rea
tecnolgica como objeto fundamental para el desarrollo de sus actividades, lo cual favorece en
gran medida a la prestacin de servicios ms eficientes y avanzados.
Estas organizaciones por su naturaleza abarcan con la mayor parte del mercado de su rea de
concesin, logrando monopolizar sus servicios y asegurando su rentabilidad empresarial. Algunas
de estas instituciones a pesar de no contar con competidores en el rubro, enfatizan sus
procedimientos a la mejora continua para ofrecer servicios en beneficio al cliente y a sus
accionistas.
ANTECEDENTES
Las innovaciones tecnolgicas surgen a un ritmo acelerado incrementndose en progresin
geomtrica, sin tener en cuenta los lmites geogrficos ni los sistemas polticos. Estas
innovaciones tienden a transformar el nivel de vida de la sociedad y gracias a ello se incrementa
la calidad de produccin de bienes y servicios
La tecnologa ha sido siempre un medio importante para crear nuevos entornos fsicos y humanos
en el desarrollo empresarial, tal es el caso de la empresa de distribucin de energa elctrica de la
ciudad de Oruro administrada por la Empresa Nacional de Energa Elctrica-ENDE.
La Empresa de Luz y Fuerza de Oruro S.A, ELFEOSA, fue constituida un 24 de enero de 1921
con el objeto de realizar todo tipo de negocio relacionado con la provisin y suministro de
2

energa elctrica. En la actualidad presta atencin a ms de 80 mil clientes en su rea de

concesin urbana y rural, de los cuales un 90 por ciento se constituyen en Residencial, comercial
(domsticos, carpinteras, internet, etc.) y un 10 por ciento contempla clientes especiales
(industrias mineras, embotelladoras y otros). La compaa ha generado en las ltimas gestiones
utilidades asegurando la rentabilidad adecuada para la inversin enmarcada en los parmetros
establecidos por la regulacin nacional.
ELFEOSA es una empresa de servicio pblico y tiene por misin: Ser empresa modelo en la
Distribucin de Energa elctrica para Bolivia, con niveles de excelencia en calidad y
confiabilidad; generando ventajas competitivas con una rentabilidad adecuada y manteniendo en
el Departamento de Oruro el liderazgo en la prestacin de servicios.
La compaa desarrolla sus actividades basadas en su estructura organizacional con los procesos
necesarios, determinando su secuencia e interaccin, a travs de sus procedimientos internos y los
establecidos por el ente regulador, asegurndose las operaciones y control de procesos de forma
eficaz.
La organizacin cuenta con cuatro superintendencias: Distribucin, Comercial, Administracin y
Control y Gestin de la calidad. El rea comercial se divide en cuatro departamentos: reclamosODECO, medicin-tarifas, facturacin y clientes domiciliarios.
El rea de medicin y tarifas es fundamental para la empresa, esta rea coordina los aspectos
tcnicos con los clientes internos y externos, coadyuvando el tipo de medidor requeridos por el
cliente de acuerdo a la categora asignada y paralelamente los materiales de instalacin utilizados
para el punto de medicin. Adems, este departamento cuenta con un laboratorio certificado de
acuerdo a las normas elctricas, donde se realizan pruebas, calibraciones, programacin de
medidores y otros aspectos propios del registro de energa elctrica. Sin embargo, tambin esta
rea se dedica a la recoleccin de informacin de medidores en campo, para analizar sus
correspondientes parmetros de uso de servicio tcnico y administrativo.
Existen trabajos desarrollados en diferentes universidades a nivel mundial que cubren las
necesidades del rea de estudio, utilizando tecnologa de inters para el desarrollo de nuestra
investigacin en el rea de medidores y tarifas dependiente de ELFEOSA.

Tal es el caso del proyecto de grado titulado Solucin de Escaneo Georeferenciado de Niveles
de Radiacin No Ionizante Basado en NARDA NBM-520 correspondiente a la Universidad
Industrial de Santander elaborado por los estudiantes Cesar Rodrguez S. y Sergio Muoz S.
utilizando el equipo NARDA-520 para la medicin de radiacin no-ionizante, y un GPS de baja
precisin desarrollan un sistema georeferenciado con propiedades de escaneo que permite
relacionar lecturas de radiacin con la informacin de las coordenadas geogrficas de diferentes
puntos de medicin.
Tambin se cuenta con varios proyectos desarrollados en la facultad nacional de ingeniera
(FNI), carrera de ingeniera de sistemas, entre los cuales se cuenta con el proyecto de grado que
lleva el ttulo: Sistema de Informacin Web para una lnea de asistencia del maltrato de nias,
nios y adolescentes, elaborado por la postulante Lineth Keiko Alanes Zeballos con el objeto de
coadyuvar el control de la informacin de los diferentes tipos de maltrato, las consecuencias y el
ncleo de las mismas, utilizando como metodologas para el desarrollo del software el Rational
Unified Process (RUP), el modelado de aplicaciones Unified Modeling Languaje (UML).
Estos proyectos debido a sus limitaciones no son adaptables a otras reas, tal es el caso del
departamento de medidores y tarifas, puesto que es necesario desarrollar un nuevo sistema que
cumpla con los requerimientos del departamento y pueda integrar informacin georeferenciada y
tecnologa web.
SITUACIN PROBLMICA
La empresa ELFEOSA proporciona el servicio de energa elctrica a todos los usuarios que en
cumplimiento a la norma elctrica, solicitan el suministro de energa y asimismo se encuentran
dentro del rea de concesin de la empresa, ya sea en el sector urbano o rural, teniendo como
alcance en estos ltimos sectores como Japo, Negro Pabelln, Caracollo, Toledo, etc.
De acuerdo a la Noma para la aplicacin de tarifas de distribucin los consumidores se
categorizan en Pequeas Demandas (PD), Medianas Demandas (MD) y Grandes Demandas GD,
lo cual permite que la empresa pueda clasificar a los clientes en dos tipos: a) Clientes Normales,
que contempla aquellos servicio en PD de subcategora residencial, General, Alumbrado Pblico,
b) Clientes especiales, son todo aquellos de categora de MD y GD y en algunos casos de PD
debido a la ubicacin geogrfica en la que se encuentra instalado el punto de suministro de
energa elctrica.
4

Dentro de esta perspectiva, se considera la escasa informacin referente a la ubicacin exacta de

los servicios de energa elctrica correspondientes a clientes especiales, provocando
inconvenientes en las actividades tcnicas y toma de decisiones en el departamento de Medicin
Tarifas y otros dependientes de la superintendencia Comercial de ELFEOSA. De igual manera
se observa insuficientes mecanismos de organizacin de la informacin generada por estos
clientes.
Por consiguiente entre otros problemas tambin se pueden citar:

La supervisin de medidores lleva el control de los parmetros tcnicos de los puntos de

medicin utilizando medios y procedimientos manuales sus caractersticas no proporciona
informacin actualizada y constante.

Para la facturacin mensual de los servicios de clientes especiales, el personal de los

departamentos dependientes de la superintendencia comercial efectan lecturas en campo,
debido al desconocimiento de la ubicacin geogrfica de algunos servicios nuevos o
antiguos, no se las realiza en su totalidad en las fechas establecidas, en consecuencia es
necesario la asignacin de otro da ms y la disposicin de otro

personal para la

conclusin del trabajo, esto retrasa la facturacin mensual.

El personal asignado realiza lecturas de los puntos de medicin en terreno o lugares de

servicios dados de baja, lo cual provoca mayor asignacin de tiempo en la recoleccin de
datos en campo.

Cuando el personal administrativo debe realizar la verificacin de algn servicio elctrico

en terreno, es necesario que acuda al personal tcnico para recabar informacin respecto a
la ubicacin del cliente, esto produce burocracia innecesaria en la comunicacin de
departamento a departamento.

La poca informacin verbal o escrita de referencia de algunos servicios de energa

elctrica, no permite localizar la ubicacin del cliente por las caractersticas propias del
terreno o lugar.

La instalacin de medidores de energa elctrica ejecutado por los tcnicos de laboratorio

de medidores, disean a mano alzada la ubicacin del lugar o puntos de conexin, esto
provoca imprecisin de las diferentes ubicaciones de los puntos de conexin.

Los detalles e informacin sobre los clientes activos y dados de baja estn en medios
impresos, siendo los procedimientos de almacenamiento y actualizacin precarios,
entregando reportes desactualizados a gerencia.

PLANTEAMIENTO DEL PROBLEMA

Cmo integrar la informacin de los servicios de suministro de energa elctrica de los clientes
especiales con el fin de coadyuvar las actividades tcnicas en el departamento de MedicinTarifas y otros dependientes de la superintendencia Comercial de la Empresa De Luz y Fuerza
Elctrica De Oruro S.A.?
OBJETO DE ESTUDIO
El objeto de estudio del proyecto de grado es el desarrollo de un sistema de informacin
georeferenciado en entorno web.
OBJETIVOS
OBJETIVO GENERAL
Implementar un sistema de informacin georeferenciado para integrar la informacin de
servicios de energa de clientes especiales a fin coadyuvar las actividades tcnicas en el
departamento de Medicin-Tarifas de ELFEO S.A.
OBJETIVOS ESPECFICOS
-

Examinar la documentacin y procedimientos del departamento de Medicin - tarifas para

definir el modelo del negocio y determinar los requerimientos del sistema.

Definir el modelo del sistema a fin de estructurar el sistema de informacin de manera

integrada.
Disear el modelo del sistema de informacin para obtener una arquitectura estable y
slida, que permita un manejo eficiente de la informacin.

Implementar un prototipo para evaluar el sistema propuesto y verificar su correcto

funcionamiento.

CAMPO DE ACCIN
El rea de concesin de la empresa ELFEOSA en el departamento de Medicin-Tarifas y otros
dependientes de la superintendencia Comercial de la Empresa De Luz y Fuerza Elctrica De
Oruro S.A. de Medicin y tarifas.
IDEA A DEFENDER
El sistema de informacin georeferenciado integra la informacin de los servicios de energa de
clientes especiales; coadyuvara a las actividades tcnicas en el departamento de Medicin-Tarifas
de ELFEO S.A.
CRITERIO DE EVALUACIN DE LA IDEA A DEFENDER
Mediante el mtodo Delphi consulta a expertos se evala la idea a defender
JUSTIFICACIONES
JUSTIFICACIN TCNICA
Los procedimientos de implementacin del sistema de informacin georeferenciado, se sustentan
en base a las herramientas de tecnologas de informacin y comunicacin con los actualmente
cuenta la empresa, entre los cuales se puede mencionar el firewalls de IBM que proporciona la
seguridad a la red corporativa, la conexin mediante fibra ptica a COTEOR para la transferencia
de informacin y acceso al internet, asimismo el departamento de medidores cuenta con cinco
equipos de escritorio conectados a la red local permitiendo la implementacin de aplicaciones
cliente servidor de esta forma la aplicacin se convertir en ventaja competitiva en cuanto al
desarrollo de las actividades tcnicas propias de la empresa.
Al mismo tiempo la tecnologa web a travs de la red internet, permite acceder a bases de datos
de sistemas geogrficos como el GOOGLE MAP, logrando integrar datos georeferenciados de
clientes especiales en la aplicacin web.

JUSTIFICACIN SOCIAL
El proyecto coadyuva a las actividades de la empresa proporcionado informacin organizada y
requerida que se demanda para los trabajos operativos que el personal tcnico o administrativo
ejecuta en la toma de lecturas de fin de mes en el rea rural o urbano de la ciudad de Oruro,
permitiendo disminuir contratiempos en la ubicacin de puntos de medicin de clientes
especiales y evitando molestias a todos sus clientes.
ALCANCES
El sistema de informacin georeferenciado se caracterizara por:

Facilitar informacin organizada y actualizada a la gerencia de la empresa de luz respecto

a datos de clientes especiales.

La superintendencia comercial cuenta con datos oportunos que coadyuvan en la toma de

decisiones.
El sistema proporciona informacin relevante de datos tcnicos al supervisor de

medidores y tarifas que permiten llevar un mejor control de clientes especiales.

Facilitar a todos los usuarios tcnicos y administrativos informacin concerniente a la

ubicacin geogrfica de estos servicios.

Prever reportes tabulares o grficos de clientes especiales activos y dados de baja.
El sistema de informacin georeferenciado es implementado en entorno web lo que

constituye su funcionamiento en la red intranet de la empresa.

La aplicacin integra informacin recopilando datos e imgenes de otro sistema,
produciendo resultados confiables y precisos.

LIMITACIONES
El sistema cuenta con las siguientes limitaciones:

Solo contempla a clientes especiales.

Proporciona informacin tcnica de los puntos de medicin y no as de trafos, postes, etc.
Mediante el sistema de informacin no se puede guardar mapas geogrficos en el disco
duro u otro dispositivo de almacenamiento.
8

La navegacin por los mapas geogrficos no se los puede realizar sin conexin a internet.

APORTES
APORTE TERICO
Es de gran importancia el presente proyecto pues muestra una herramienta moderna
computarizada, introduciendo nuevas tecnologas y conocimientos en el desarrollo de
aplicaciones web.
APORTE PRCTICO
El desarrollo de la aplicacin georeferenciada, acude al API de JavaScript en su versin 3 de
Google Map y a sus mapas que son solo imgenes que se cargan en el lenguaje html, logrando de
esta manera navegar por todo el globo terrqueo.
APORTE ACADEMICO
El presente proyecto, es una contribucin acadmica a los estudiantes de la carrera de Ingeniera
de sistemas, para el desarrollo de aplicaciones web que permitan recuperar mapas satelitales de
aplicaciones de Sistemas de Informacin Geogrfica (SIG) para la integracin de datos
georeferenciados de inters de estudio.

INGENIERIA DEL PROYECTO

METODOLOGIA,
HERRAMIENTAS Y
METODOS DE
OBJETIVOS ESPECIFICOS

SOLUCION

ACTIVIDADES

Determinar los requerimientos del AUP UML

Recoleccin de

sistema para establecer los

o Diagrama de casos de

documentacin

procedimientos de servicio de

uso.

Realizar entrevista a los

suministro de energa elctrica.

usuarios
Observacin directa del
actual proceso

Analizar los procedimientos y

AUP-UML

Determinacin de

documentacin de clientes

Modelo del negocio

requerimientos funcionales y

especiales para definir el modelo

Mtodo Vord

no funcionales del sistema

del proceso del negocio.

Elaboracin de las grficas

de casos de uso del negocio

Definir el modelo de casos de uso AUP UML

Realizar el diagrama de

a fin de estructurar el modelo del

o Modelo de casos de

modelo de casos de uso del

sistema.

uso del sistema.

sistema

Disear el sistema en entorno web AUP UML

Elaborar los diagramas de

o Diagrama de secuencia secuencia, clases, control y

georeferenciado que permita a los o Diagrama de clases

de paquetes

usuarios un manejo amigable del

o Diagrama de Control

mismo.

o Diagrama de Paquetes

Implementar un prototipo para

AUP UML o

Elaboracin de los

evaluar el sistema propuesto y

Diagrama de

diagramas de componentes y

verificar su correcto

componentes

despliegue

funcionamiento.

o Diagrama de

Diseo de Interfaces

despliegue

Programacin y produccin

o Modelo Relacional

del sw

o Diccionario de Datos

Probar el nuevo sistema

Prueba de caja blanca

Corregir fallas del sistema

Prueba de caja negra

10

11

CAPITULO I
MARCO TEORICO

12

1.1

GENERALIDADES

Este captulo presenta la base terica fundamental relacionada con textos, libros y artculos
tomando en cuenta conceptos bsicos para el desarrollo del Proyecto.
1.2

LA EMPRESA DE LUZ Y FUERZ ELECTRICA DE ORURO S.A.

Elfeo S.A. tiene su origen en 1921 en actividades de distribucin de energa elctrica en el

departamento de Oruro. En el ao 1994, producto de la reforma de la ley de Electricidad 1604,
donde se establece la total separacin de las actividades de generacin, transporte y distribucin
de energa elctrica en Bolivia (Sistema Integrado Nacional).
En la actualidad Elfeo S.A, presta servicios a ms de ochenta mil clientes dentro de su zona de
concesin, siendo la gran mayora de ellos clientes domiciliarios, y sus actividades se extienden
adems de la Capital de Oruro, a diversas provincias y zonas alejadas de los centros econmicos
ms importantes de la regin.
1.2.1

DISPOSICIONES GENERALES

De acuerdo al Reglamento de Servicio Pblico de Suministro de Electricidad (RSPSE) se tienen

las siguientes definiciones:

Acometida.- Son los conductores y accesorios que conectan cualquier punto de la red de

distribucin con el punto de suministro o instalacin del consumidor.

Alta Tensin.- Nivel de tensin igual o superior a sesenta y nueve mil (69.000) voltios.
Baja Tensin.- Nivel de tensin igual o inferior a mil (1.000) voltios.
Media Tensin.- Nivel de tensin superior a mil (1.000) voltios y menor a sesenta y

nueve mil (69.000) voltios.

Punto de Medicin.- Es el punto fsico donde estn conectados los sistemas de medicin.
Punto de Suministro.- Es el punto fsico donde la Acometida se conecta con la red

elctrica del Distribuidor.

Servicio Pblico de Suministro de Electricidad.- Es el servicio de suministro de
electricidad prestado a Consumidores Regulados por un Distribuidor.

La norma para la aplicacin de tarifas de distribucin establece las siguientes definiciones para la
asignacin de categoras de consumidores:

13

Categora pequeas demandas (PD).- En esta categora se clasificaran a aquellos

consumidores conectados en baja tensin o media tensin, cuya potencia mxima es

inferior al lmite establecido para esta categora.

Categora medianas demandas (MD).- En esta categora se clasifican a aquellos
consumidores conectados en baja o media tensin, cuya mxima se encuentra dentro de
los lmites establecidos para esta categora.
En esta categora se incluyen los consumidores cuya demanda de electricidad puede

excluirse del bloque alto, para lo cual se podrn instalar interruptores temporizados.
Categora grandes demandas (GD).- En esta categora se clasifican a aquellos
consumidores conectados en baja, media o alta tensin, cuya potencia mxima es mayor
al lmite superior establecido para la categora de medianas demandas.

1.3

QUE ES UN SISTEMA?

Un sistema es una serie de objetos con determinada relacin entre esos objetos y

entre sus

atributos. Los objetos simplemente son las partes o componentes de un sistema, y pueden ser de
una variedad limitada. Los atributos son las propiedades de los objetos citados antes. Las
relaciones forman la liga del sistema entre s.
1.3.1

SISTEMA DE INFORMACION

Un sistema de informacin es un conjunto de elementos que interacta entre s con el fin de

apoyar las actividades de una empresa.
Un sistema de informacin realiza cuatro actividades bsicas:

1.4

Entrada
Almacenamiento
Proceso de la informacin
Salida de informacin
CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN

Los sistemas de informacin se desarrollan con diversos propsitos, que depende de las
necesidades de la empresa.

14

SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES. Los sistemas de

procesamiento de transacciones (TPS, transaction Processing Systems) son sistemas de
informacin computarizada creados para procesar grandes cantidades de datos
relacionados con transacciones rutinarias de negocios, como las nminas y los

inventarios.
SISTEMA DE AUTOMATIZACION DE LA OFICINA Y SISTEMAS DE TRABAJO
DEL CONOCIMIENTO. Existen dos clases de sistemas en el nivel del conocimiento de
una organizacin. Los sistemas de automatizacin de la oficina (OAS, Office Automation
Systems) apoyan a los trabajadores de datos, quienes por lo general no proporcionan
conocimientos nuevos, sino ms bien analizan la informacin con el propsito de
transformar los datos o manipularlos de alguna manera. Los sistemas de trabajo del
conocimiento (KWS, Knowledge Work Systems) sirven de apoyo a los trabajadores
profesionales, como los cientficos, ingenieros y mdicos en sus esfuerzos de creacin de
nuevo conocimiento y dan a estos la posibilidad de compartirlos con sus organizaciones y

con la sociedad.
SISTEMAS DE INFORMACION GERENCIAL. Los sistemas de informacin gerencial
(MIS, Management Information Systems) no remplazan a los sistemas de procesamiento
de transacciones, ms bien incluyen el procesamiento de transacciones. Los MIS son
sistemas de informacin computarizados cuyo propsito es contribuir a la correcta
interaccin entre los usuarios y las computadoras. Los sistemas de informacin gerencial
dan apoyo en tareas organizacionales mucho ms amplio de los sistemas de
procesamiento de transacciones, como el anlisis y la toma de decisiones. Para acceder a
la informacin, los usuarios de un sistema de informacin gerencial comparten una base
de datos comn, que almacena datos y modelos que ayudan al usuario a interpretar y
aplicar los datos. Los sistemas de informacin gerencial producen informacin que se

emplea en la toma de decisiones.

SISTEMA DE APOYO A LA TOMA DE DECISIONES. Los sistemas de apoyo a la toma
de decisiones (DSS, Decisin Support Systems) constituyen una clase de alto nivel de
sistema de informacin automatizada. Los DSS coinciden con los sistemas de
informacin en que ambos dependen de una base de datos para abastecerse de datos. Sin
embargo difieren en que el DSS pone nfasis en el apoyo de toma de decisiones en todas
sus fases, aunque la decisin definitiva es responsabilidad de la persona encargarla de

15

tomarla. Los sistemas de apoyo de toma de decisiones se ajustan ms al gusto de la

persona o grupo que los utiliza que los sistemas de informacin tradicional.
SISTEMAS EXPERTOS E INTELIGENCIA ARTIFICIAL. La inteligencia artificial (AI,
Artificial Inteligence) se puede considerar como un campo general para los sistemas
expertos. La motivacin principal de la AI ha sido desarrollar mquinas que tengan
comportamiento inteligente. Dos de las lneas de investigacin de la AI son la
comprensin del leguaje natural y el anlisis de la capacidad para razonar un problema
hasta su conclusin lgica.

SISTEMAS EXPERTOS E INTELIGENCIA ARTIFICIAL. La inteligencia artificial (AI,

Artificial Inteligence) se puede considerar como un campo general para los sistemas
expertos. La motivacin principal de la AI ha sido desarrollar mquinas que tengan
comportamiento inteligente. Dos de las lneas de investigacin de la AI son la
comprensin del leguaje natural y el anlisis de la capacidad para razonar un problema
hasta su conclusin lgica.

SISTEMAS DE APOYO A LA TOMA DE DECISIONES EN GRUPO Y SISTEMAS DE

TRABAJO COLABORATIVO APOYADOS POR COMPUTADORA. Estos sistemas
(GDSS, Group Decision Support System) son adecuados para grupos que requieren
trabajar en conjunto para tomar decisiones. Este tipo de sistemas se utilizan en salones
especiales equipados con diversas configuraciones, faculta a los miembros del grupo a
interactuar con apoyo electrnico y la asistencia de un facilitador especial. Los sistemas
de apoyo a la toma de decisiones en grupo tienen el propsito de unir un grupo en la
bsqueda de la solucin de un problema con la ayuda de diversas herramientas como los
sondeos, los cuestionarios, la lluvia de ideas y la creacin de escenarios.

SISTEMAS DE APOYO A EJECUTIVOS. Los sistemas de apoyo a ejecutivos (ESS,

Executive Support System) ayudan a los ejecutivos a organizar sus actividades
relacionadas con el entorno externo mediante grficas y de comunicaciones, que por lo
general se encuentran en salas de juntas o en oficinas corporativas personales. A pesar de
que los ESS dependen de la informacin producida por los TPS y los MIS, ayudan a los
usuarios a resolver problemas de toma de decisiones no estructurada, que no tienen una
aplicacin especfica, mediante la creacin de un entorno que contribuye a pensar en
problemas estratgicos de una manera bien informada.
16

1.5

INTERNET

El Internet (redes interconectadas) es la red de redes de informacin, su evolucin fue y es

vertiginosa con millones de usuarios conectados tratando de encontrar informacin que sea
significativa.
El origen del Internet fue gracias al protocolo de comunicacin HTTP (Hyper Text Transfer
Protocol), es decir que Internet utiliza este protocolo para poder comunicar a usuarios que buscan
informacin, garantiza que cualquier cliente con un navegador estndar pueda conectarse con un
servidor remoto. En la primera etapa de Internet solo existan pginas estticas en HTML
(Hipertext Markup Language, Lenguaje de Marcacin de Hipertexto) las cuales se tratan como
textos planos en formato ASCII con algunas cabeceras para la transmisin. Para poder acceder a
estos documentos se tuvo que crear una direccin nica que se la denomin URL (Uniform
Resource Locutor, Localizador Uniforme de Recursos) que indica tanto la localizacin exacta del
recurso como el protocolo necesario para su transferencia.
Luego se incorporaron lenguajes como el Java o VBScript que permitieron colocar cdigo en
pginas HTML. Esta incorporacin permiti a los desarrolladores a realizar pginas Web
dinmicas, convirtindose en aplicaciones Web, el cdigo incorporado poda manipular datos
dentro de una base de datos, pero todo el cdigo deba estar en la mquina del cliente, siendo una
dificultad, ya que la mquina del cliente se volva muy lenta y consuma muchos recursos. La
siguiente etapa de Internet fue colocar cdigo en el lado del servidor para as, alivianar la
mquina del cliente e incrementar la seguridad, ya que el usuario no debe acceder al cdigo.
1.5.1

APLICACIONES WEB.

Cuando la informtica se introdujo por vez primera en las empresas y organizaciones lo hizo bajo
un modelo cliente / servidor. Los usuarios disponan de una terminal con una pequea pantalla
verde conectada a un servidor donde coexistan los datos y el software. Ms tarde, con la
aparicin del PC, el modelo cambi y la lgica y los datos pasaron a residir completamente en el
PC con los consecuentes problemas de administracin, soporte y coste de las licencias. Esto no
vari demasiado durante bastante tiempo, pero ahora, parece que volvemos al principio. La era
del PC ha terminado para dejar paso a la era Internet y es justamente ah, donde se van a alojar
nuestros programas y datos. Con las aplicaciones Web se recupera el papel del servidor que se
convierte ahora en un servidor Web. Los datos se almacenan en bases de datos accesibles desde
17

un navegador Web o una terminal mvil gracias a la lgica que se ejecuta en el servidor y al
diseo del interfaz que es transferido a dichas terminales.
1.5.2

VENTAJAS DE LAS APLICACIONES WEB

Puesto que el mantenimiento del sistema se concentra en el servidor, el gasto se reduce. En

general, es el proveedor del servicio quien se preocupa de tener la aplicacin siempre disponible
y actualizada a cambio de una cuota fija razonable. Se podran encontrar numerosas ventajas ms,
pero probablemente, la propiedad ms destacada sea la conectividad que proporciona Internet
permitiendo el acceso a la aplicacin desde cualquier punto. Esto permite ahorrar invertir en
costosas infraestructuras de comunicaciones que en muchos casos podran ser sencillamente
imposibles.
1.5.3

HIPERTEXTO, MULTIMEDIA, E HIPERMEDIA.

Hipertexto, hipermedia, multimedia se han convertido en terminologa muy utilizadas en los

ltimos aos en relacin a los medios de aprendizaje y en la Web. A pesar de que existe
diferencia entre estas tres definiciones, es frecuente utilizar los trminos indistintamente.
1.5.4

HIPERTEXTO.

El hipertexto es un enlace que permite saltar a otros documentos o partes del mismo documento,
es decir que el lector no necesariamente est obligado a seguir una estructura secuencial como la
de un libro, sino que puede seguir una estructura no lineal.
Los hipertexto o vnculos pueden ser grficos, imgenes en 3D o texto coloreado. Para
comprobar si un elemento de una pgina es un vnculo, el puntero del ratn cambia de su estado
inicial a un segundo estado en forma de una mano, el elemento es entonces un vnculo.
1.5.5

MULTIMEDIA.

Multimedia es la combinacin o utilizacin de dos o ms medios de forma concurrente. La

multimedia tambin se refiere al uso de la informtica de crear, almacenar y contenido de la
experiencia multimedia. Mientras que la informacin se presenta en varios formatos, la
multimedia realza la experiencia del usuario y la hace ms fcil y ms rpida para tomar la

18

informacin. La presentacin de la informacin en varios formatos no es nada nuevo, pero los

multimedia implican generalmente la presentacin de la informacin en varios formatos digitales.
1.5.6

HIPERMEDIA.

Es la organizacin de informacin textual, grfica y sonora a travs de vnculos que crean

asociaciones entre informacin relacionada dentro del sistema.
Los sistemas hipermedia, en cuanto a su generacin como documentos, son mucho ms
complejos que los sistemas hipertextuales. En un hipertexto se pueden fragmentar los bloques de
texto para ser enlazados, pero en un sistema hipermedia la asociacin de un enlace con o dentro
de un componente multimedia es mucho ms compleja, ya que los datos la mayor parte de las
veces no pueden fragmentarse ni indexarse. Adems, los sistemas hipermedia pueden incorporar
la llamada inteligencia embebida, es decir, son capaces de ejecutar otras aplicaciones o de tomar
decisiones de acuerdo con la actividad que desarrolla el usuario tanto al utilizar los enlaces como
al acceder a los contenedores.
1.5.7

ARQUITECTURA DE LA WEB.

La Web est compuesta por una coleccin de servidores, estos usan el protocolo de transferencia
de hipertexto o HTTP para satisfacer las solicitudes de informacin de las computadoras de los
usuarios finales; estas solicitudes se realizan a travs de programas conocidos como
visualizadores, que permiten que el usuario pueda ver cualquier tipo de informacin. Los
visualizadores fueron diseados bsicamente para interpretar y presentar pginas de informacin
escritas con el lenguaje de composicin de hipertexto o HTML, pero actualmente pueden mostrar
otros tipos de dato.
Los programas de los servidores que responden las solicitudes de los visualizadores se conocen
como servidores HTTP o proceso escucha, ya que estn a la espera de solicitudes a las cuales
responder. Adems de suministrar documentos relativamente estticos, 1a Web puede usar como
un entorno para imp1ementar ap1icaciones funciona1es; estas ap1icaciones usan el HTML para
mostrar 1a interfaz grfica de usuario o GUI, en una pantalla de usuario remoto, mientras que e1
procesamiento se realiza en e1 servidor. Este procesamiento lo llevan a cabo programas que
ejecuta el proceso escucha de http en respuesta a determinadas solicitudes del visualizador. El
19

objetivo fundamental de la Word Wide Web es permitir el acceso directo a grandes volmenes de
informacin y servicios a travs de la Red.
La Web est basada en un protocolo de solicitud/respuesta sin conservacin de estado, el
protocolo de transferencia de hipertexto HTTP. La cadena tpica de sucesos en este modelo es la
siguiente: Un servidor HTTP, espera las solicitudes entrantes en un puerto TCP, un c1iente HTTP,
normalmente un visualizador, abre una conexin de red al puerto del servidor y pide un recurso a
un servidor remoto. Esta solicitud se enva al servidor remoto que a su vez recupera el recurso
solicitado y devuelve al c1iente Web, despus el servidor cierra la conexin de red y presenta al
usuario el recurso devuelto; este puede tener un contenido incrustado, tal como imgenes, lo que
hace que el visualizador realice otras solicitudes correspondientes a los recursos incrustados.
Se Debe sealar que para seleccionar el modelo de una arquitectura, hay que partir del contexto
tecnolgico y organizativo del momento y, que la arquitectura Cliente/Servidor requiere una
determinada especializacin de cada uno de los diferentes componentes que la integran.

Figura 1-1. Arquitectura Cliente Servidor

1.5.8

PGINAS ESTTICAS.

Las pginas estticas son pginas que no presentan efectos especiales. Estas pginas son muy
sencillas de crear, aunque ofrecen pocas ventajas tanto a los desarrolladores como a los visitantes,
ya que slo se pueden presentar textos planos acompaados de imgenes.

20

1.5.9

PGINAS DINMICAS.

Los sitios Web dinmicos ofrecen ciertas ventajas a diseadores de sitios Web. Les facilita el
almacenamiento actualizado de contenidos y a la sincronizacin, el acceso y el proceso de
informacin ya sean texto, imgenes, multimedia en una bases de datos, la apariencia del sitio
Web est definida por un juego de pginas que contienen cdigo ejecutable por el servidor Web
durante una solicitud para esta pgina. En este contexto el archivo puede ser un archivo de texto
plano con scripts interpretados por el servidor web, o un archivo binario compilado que es
ejecutado por el servidor web. En cualquier caso el cdigo en la pgina web hace referencia y
utiliza recursos del servidor que incluyen bases de datos, servicios de correos electrnicos, chat,
foros de discusin y otros.
1.5.10 EL PROTOCOLO.
Los protocolos de computadora definen la manera como tienen lugar las comunicaciones, si una
computadora est enviando informacin a otra y ambas siguen el protocolo de manera apropiada,
el mensaje llega; sin importar que tipo de mquina sean y que sistemas operativos ejecuten. En
esencia en protocolo de computadora es un conjunto de reglas que coordina el intercambio de
informacin.
1.5.10.1 EL PROTOCOLO HTTP.
El HTTP es un protocolo de nivel de aplicacin que se ejecuta en una red TCP/IP. Fue inventado
por Tim Bemers Lee, cuando estaba en el Laboratorio Europeo de Fsica de Partculas. El
objetivo del HTTP era proporcionar un protocolo de aplicacin de red que permitiera a los
investigadores compartir fcil y rpidamente informacin en diferentes formatos, incluyendo
texto, imgenes, sonido y video. El protocolo HTTP tiene varias caractersticas que es importante
comprender:

Es fcil de implementar.
No guarda memoria del estado, toda solicitud HTTP que un cliente hace al

servidor es independiente de cualquier otra solicitud que haga.

Es transitorio, cada solicitud se hace sobre una conexin de red diferente.

21

Es neutral respecto al contenido, el servidor HTTP no necesita saber nada sobre el

material que va a servir.

En resumen se puede decir HTTP es un protocolo sencillo, con algunas
imperfecciones y limitaciones debido a su sencillez, pero esto mismo ha permitido
su adopcin general. Actualmente sin embargo, se han introducido mejoras a la
primera versin de este protocolo.

1.5.11 LOCALIZADOR UNIFORME DE RECURSOS (URL).

Es una cadena que proporciona la direccin de Internet de un sitio Web o un recurso del World
Wide Web, junto con el protocolo mediante el cual se tiene acceso al sitio o al recurso.
1.5.12 LA WORLD WIDE WEB O LA WEB.
La World Wide Web consiste en ofrecer una interfaz simple y consistente para acceder a la
inmensidad de los recursos de Internet. La informacin se ofrece en forma de pginas
electrnicas.
El WWW o simplemente Web, permite saltar de un lugar a otro en funcin a lo que nos interesa,
con pocas ordenes se puede mover por toda la Internet, para entender lo que es la Web se debe
tomar en cuenta lo que es el Hipertexto.
1.5.13 FUNCIONAMIENTO DE LA WEB.
Para acceder a pginas Web es necesario el programa que se usa para leer los documentos de
hipertexto denominado "navegador". Mediante los Navegadores modernos se pueden tener
acceso a hojas de clculo, base de datos, video, sonido y todas las posibilidades ms avanzadas.
1.5.14 NAVEGADORES.
Es una aplicacin software que permite recuperar y visualizar documentos de hipertexto, desde
servidores Web de todo el mundo a travs de Internet. Los ms conocidos son el Explorer de
Microsoft, Chrome, Mozilla Firefox, Safari, Opera, Maxthon, TheWorld, Traveler y el Netscape.
Tienen capacidades diferentes y es importante cuando se crea una pgina Web, adems de un
buen diseo, tener en cuenta la compatibilidad, es decir, programar pginas de modo que las
acepte cualquier Navegador.
22

Conectndose a Internet, con un visualizador Mozilla o Explorer, adems de ver documentos

HTML se puede recibir y enviar correos electrnicos, recibir y enviar NEWS (noticias), etc.
Tambin, se pueden imprimir los documentos visualizados.
1.5.15 HTML.
El lenguaje HTML

se utiliza para el desarrollo de pginas web de internet. La sigla que

corresponde a HTML (Hyper Text Markup Language), es decir, Lenguaje de Marcas de

Hipertexto, que se traduce como Lenguaje de Formato de Documentos para Hipertexto. Gracias a
Internet y a los navegadores web del tipo Internet Explorer, Opera, Firefox o Netscape, el HTML
se ha convertido en uno de los formatos ms populares que existen para la construccin de
documentos.
Se trata de un formato abierto que surgi a partir de las etiquetas SGML (Standard Generalized
Markup Language). Concepto traducido generalmente como Estndar de Lenguaje de Marcado
Generalizado y que se entiende como un sistema que permite ordenar y etiquetar diversos
documentos dentro de una lista. Este lenguaje es el que se utiliza para especificar los nombres de
las etiquetas que se utilizarn al ordenar, no existen reglas para dicha organizacin, por eso se
dice que es un sistema de formato abierto.
EL HTML se encarga de desarrollar una descripcin sobre los contenidos que aparecen como
textos y sobre su estructura, complementando dicho texto con diversos objetos (como
fotografas, animaciones, etc.).
Es un lenguaje muy simple y general que sirve para definir otros lenguajes que tienen que ver
con el formato de los documentos. El texto en l se crea a partir de etiquetas, tambin llamadas
tags, que permiten interconectar diversos conceptos y formatos.
Para la escritura de este lenguaje, se crean etiquetas que aparecen especificadas a travs de
corchetes o parntesis angulares: < y >. Entre sus componentes, los elementos dan forma a la
estructura esencial del lenguaje, ya que tienen dos propiedades (el contenido en s mismo y sus
atributos).
Por otra parte, cabe destacar que el HTML permite ciertos cdigos que se conocen como scripts,
los cuales brindan instrucciones especficas a los navegadores que se encargan de procesar el
23

lenguaje. Entre los scripts que pueden agregarse, los ms conocidos y utilizados son JavaScript y
PHP.
1.5.16 PHP
PHP es el acrnimo de Hipertext Preprocesor, es un lenguaje interpretado de alto nivel embebido
en pginas HTML. La meta de este lenguaje es permitir escribir a los diseadores de pginas
web, paginas dinmicas de una manera rpida y fcil.
Es posible descargar PHP en su ltima versin a travs de la pgina principal www.php.net de
manera gratuita, un mdulo que hace que nuestro servidor web comprenda los scripts realizados
en este lenguaje. Es independiente de plataforma, puesto que existe un mdulo de PHP para casi
cualquier servidor web. Esto hace que cualquier sistema pueda ser compatible con el lenguaje y
significa una ventaja importante, ya que permite portar el sitio desarrollado en PHP de un sistema
a otro sin prcticamente ningn trabajo.
Las caractersticas ms importantes de PHP son: compatibilidad con las bases de datos ms
comunes, como MySQL, Oracle, Informix, y ODBC. Incluye funciones para el envo de correo
electrnico, upload de archivos, crear dinmicamente en el servidor imgenes en formato GIF,
incluso animadas y una lista interminable de utilidades adicionales.
El cdigo PHP debe incluirse dentro del cdigo html de la pgina. Para delimitar la seccin de
cdigo PHP podemos hacerlo de varias formas:
-Usando las etiquetas <?php y <?
-Usando las etiquetas <? y ?>
-Mediante <script languaje="php"></script>
El funcionamiento de las pginas en PHP alojadas en un servidor es el siguiente:
-El navegador del cliente solicita el documento php.
-Llega la solicitud del servidor y el servidor localiza el documento. Debido a la extensin del
documento lanza y ejecuta el intrprete de PHP y ejecuta todo su cdigo.
-Una vez ejecutado el cdigo se genera el resultado en HTML y lo devuelve al servidor para que
lo transfiera al cliente.
24

-El servidor transfiere el resultado en HTML y es mostrado en el navegador del cliente

1.5.17 SERVIDOR APACHE
El servidor HTTP Apache es un servidor web HTTP de cdigo abierto, para plataformas Unix
etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo HTTPy la nocin de
sitio virtual.
El servidor Apache es usado principalmente para enviar pginas web estticas y dinmicas en la
World Wide Web. Muchas de estas webs estn diseadas asumiendo como ambiente de
implantacin a Apache, o que utilizarn caractersticas propias de este servidor web.
Apache es el componente de servidor web en la popular plataforma de aplicaciones LAMP, junto
a MySQL y los lenguajes de programacin PHP/Perl/Python.
Apache es usado para muchas otras tareas donde el contenido necesita ser puesto a disposicin en
una forma segura y confiable. Un ejemplo es al momento de compartir archivos desde una
computadora personal hacia Internet. Un usuario que tiene Apache instalado en su escritorio
puede colocar arbitrariamente archivos en la raz de documentos de Apache, desde donde pueden
ser compartidos
Los programadores de aplicaciones web a veces utilizan una versin local de Apache con el fin
de previsualizar y probar cdigo mientras ste es desarrollado.
1.5.18 MYSQL
MySQL es el servidor de bases de datos relacionales ms popular, desarrollado y proporcionado
por MySQL AB. MySQL AB es una empresa cuyo negocio consiste en proporcionar servicios en
torno al servidor de bases de datos MySQL.

- MySQL es un sistema de administracin de bases de datos.

Una base de datos es una coleccin estructurada de datos. La informacin que puede almacenar
una base de datos puede ser tan simple como la de una agenda, un contador, o un libro de visitas,
tan vasta como la de una tienda en lnea, un sistema de noticias, un portal, o la informacin
25

generada en una red corporativa. Para agregar, acceder, y procesar los datos almacenados en una
base de datos, se necesita un sistema de administracin de bases de datos, tal como MySQL.
- MySQL es un sistema de administracin de bases de datos relacionales
Una base de datos relacional almacena los datos en tablas separadas en lugar de poner todos los
datos en un solo lugar. Esto agrega velocidad y flexibilidad. Las tablas son enlazadas al definir
relaciones que hacen posible combinar datos de varias tablas cuando se necesitan consultar datos.
La parte SQL de "MySQL" significa "Lenguaje Estructurado de Consulta", y es el lenguaje ms
usado y estandarizado para accesar a bases de datos relacionales.
- MySQL es Open Source
Open Source significa que la persona que quiera puede usar y modificar MySQL. Cualquiera
puede descargar el software de MySQL de Internet y usarlo sin pagar por ello. Inclusive,
cualquiera que lo necesite puede estudiar el cdigo fuente y cambiarlo de acuerdo a sus
necesidades. MySQL usa la licencia GPL (Licencia Pblica General GNU), para definir qu es lo
que se puede y no se puede hacer con el software para diferentes situaciones. Sin embargo, si uno
est incmodo con la licencia GPL o tiene la necesidad de incorporar cdigo de MySQL en una
aplicacin comercial es posible comprar una versin de MySQL con una licencia comercial. Para
mayor informacin, ver la pgina oficial de MySQL en la cul se proporciona mayor informacin
acerca de los tipos de licencias.
- Por qu usar MySQL?
El servidor de bases de datos MySQL es muy rpido, seguro, y fcil de usar. Si eso es lo que se
est buscando, se le debe dar una oportunidad a MySQL. Se pueden encontrar comparaciones de
desempeo con algunos otros manejadores de bases de datos en la pgina de MySQL.
El servidor MySQL fue desarrollado originalmente para manejar grandes bases de datos mucho
ms rpido que las soluciones existentes y ha estado siendo usado exitosamente en ambientes de
produccin sumamente exigentes por varios aos. Aunque se encuentra en desarrollo constante,
el servidor MySQL ofrece hoy un conjunto rico y til de funciones. Su conectividad, velocidad, y
seguridad hacen de MySQL un servidor bastante apropiado para accesar a bases de datos en
Internet.
26

- Algunos detalles tcnicos de MySQL

El software de bases de datos MySQL consiste de un sistema cliente/servidor que se compone de
un servidor SQL multihilo, varios programas clientes y bibliotecas, herramientas administrativas,
y una gran variedad de interfaces de programacin (APIs). Puede obtener tambin como una
biblioteca multihilo que puede enlazar dentro de otras aplicaciones para obtener un producto ms
pequeo, ms rpido, y ms fcil de manejar.
1.5.19 JAVASCRIPT.
Es un lenguaje de programacin utilizado para crear pequeos programas encargados de realizar
acciones dentro del mbito de una pgina web. Se trata de un lenguaje de programacin del lado
del cliente, porque es el navegador el que soporta la carga de procesamiento. Su uso se basa
fundamentalmente en la creacin de efectos especiales en las pginas y la definicin de
interactividades con el usuario.
Una de

las ventajas principales que ofrece es la capacidad de reducir el trfico de red

permitiendo la realizacin local de las tareas simples, es decir el lugar de encomendar esas tareas
al servidor y esperar a que pase los resultados al navegador, el navegador puede realizarlas a
nivel local, con lo que el usuario, obtiene sus respuestas en un tiempo ms corto.
1.6
1.6.1

METODOLOGA
EL PROCESO UNIFICADO DE RATIONAL

Los antecedentes histricos ms importantes de RUP, se remontan al modelo espiral de Barry

Boehm y Ken Hartman quien contribuyo de gran manera con Boehm en la investigacin. El ao
1995 Rational Software adquiere una compaa de origen sueco que llevaba el nombre de
Objetory AB fundada por Ivar Jacobson, famoso por incorporar los casos de uso a los mtodos
de desarrollo orientado a objetos.
El Proceso Unificado de Rational (RationalUnifiedProcess en ingls, habitualmente resumido
como RUP) es un proceso de desarrollo de software y junto al Lenguaje Unificado de Modelado
UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y
documentacin de Sistemas Orientados a Objetos. El RUP no es un sistema con pasos
27

firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades

de cada organizacin.
1.6.2

PROCESO DIRIGIDO POR CASOS DE USO

Un software es elaborado para dar servicio a sus usuarios finales. Por tanto para construir un
sistema con xito se debe conocer lo que los futuros usuarios requieren y desean.
El trmino usuario no slo hace referencia a usuarios humanos sino a otros sistemas. En este
sentido, el trmino usuario representa alguien o algo (como otro sistema fuera del sistema en
consideracin) que interacta con el sistema que se est desarrollando. Un ejemplo de interaccin
sera una persona que utiliza un cajero automtico. l (o ella) inserta la tarjeta de plstico,
responde a las preguntas que le hace la mquina en su pantalla, y recibe una suma de dinero. En
respuesta a la tarjeta del usuario y a sus contestaciones, el sistema lleva a cabo una secuencia de
acciones que proporcionan al usuario un resultado importante, en este caso, la retirada del
efectivo.
Una interaccin de este tipo es un caso de uso, un caso de uso es un fragmento de funcionalidad
del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los
requisitos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el
cual describe la funcionalidad total del sistema. Puede decirse que una especificacin funcional
contesta a la pregunta: Qu debe hacer el sistema?.
La estrategia de los casos de uso puede describirse aadiendo tres palabras al final de esta
pregunta: ...para cada usuario? Estas tres palabras albergan una implicacin importante. Obliga
a pensar en trminos de importancia para el usuario y no slo en trminos de funciones que seran
bueno tener. Sin embargo, los casos de uso no son slo una herramienta para especificar los
requisitos de un sistema. Tambin guan su diseo, implementacin, y prueba: esto es, guan el
proceso de desarrollo. Basndose en el modelo de casos de uso, los desarrolladores crean una
serie de modelos de diseo e implementacin que llevan a cabo los casos de uso. Los
desarrolladores revisan cada uno de los sucesivos modelos para que sean conformes al modelo de
casos de uso. Los ingenieros de prueba prueban la implementacin para garantizar que los
componentes del modelo de implementacin implementan correctamente los casos de uso. De
este modo, los casos de uso no slo inician el proceso de desarrollo sino que le proporcionan un
hilo conductor. Dirigido por casos de uso quiere decir que el proceso de desarrollo sigue un hilo
28

avanza a travs de una serie de flujos de trabajo que parten de los casos de uso. Los casos de
uso se especifican, se disean, y los casos de uso finales son la fuente a partir de la cual los
ingenieros de prueba construyen sus casos de prueba.
Aunque es cierto que los casos de uso guan el proceso, no se desarrollan aisladamente. Se
desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso guan la
arquitectura del sistema y la arquitectura del sistema influye en la seleccin de los casos de uso.
Por tanto, tanto la arquitectura del sistema como los casos de uso maduran segn avanza el ciclo
de desarrollo.

Figura 1-2 El RUP guiado por casos de uso.

1.6.3

PROCESO ESTA CENTRADO EN LA ARQUITECTURA

El papel de la arquitectura software es parecido al papel que juega la arquitectura en la

construccin de edificios. El edificio se contempla desde varios puntos de vista: estructura,
servicios, conduccin de la calefaccin, fontanera, electricidad, etc. Esto permite a un
constructor ver una imagen completa antes de que comience la construccin. Anlogamente, la
arquitectura en un sistema software se describe mediante diferentes vistas del sistema en
construccin.
El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms
significativos del sistema. La arquitectura surge de las necesidades de la empresa, como las
perciben los usuarios y los inversores, y se refleja en los casos de uso. Sin embargo, tambin se
ve influida por muchos otros factores, como la plataforma en la que tiene que funcionar el
29

software (arquitectura hardware, sistema operativo, sistema de gestin de base de datos,

protocolos para comunicaciones en red), los bloques de construccin reutilizables de que se
dispone (por ejemplo. un marco de trabajo para interfaces grficas de usuario), consideraciones
de implantacin, sistemas heredados, y requisitos no funcionales (por ejemplo, rendimiento,
fiabilidad). La arquitectura es una vista del diseo completo con las caractersticas ms
importantes resaltadas, dejando los detalles de lado. Debido a que lo que es significativo depende
en parte de una valoracin, que a su vez, se adquiere con la experiencia, el valor de una
arquitectura depende de las personas que se hayan responsabilizado de su creacin. No obstante,
el proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la comprensibilidad,
la capacidad de adaptacin al cambio, y la reutilizacin.
Cmo se relacionan los casos de uso y la arquitectura? Cada producto tiene tanto una funcin
como una forma. Ninguna es suficiente por s misma. Estas dos fuerzas deben equilibrarse para
obtener un producto con xito. En esta situacin, la funcin corresponde a los casos de uso y la
forma a la arquitectura. Debe haber interaccin entre los casos de uso y la arquitectura. Es un
problema del tipo "el huevo y la gallina". Por un lado, los casos de uso deben encajar en la
arquitectura cuando se llevan a cabo. Por otro lado, la arquitectura debe permitir el desarrollo de
todos los casos de uso requeridos, ahora y en el futuro. En realidad, tanto la arquitectura como los
casos de uso deben evolucionar en paralelo.
Por tanto, los arquitectos moldean el sistema para darle una forma. Es esta forma, la arquitectura.
La que debe disearse para permitir que el sistema evolucione, no slo en su desarrollo inicial,
sino tambin a lo largo de las futuras generaciones. Para encontrar esa forma, los arquitectos
deben trabajar sobre la comprensin general de las funciones clave, es decir, sobre los casos de
uso claves del sistema. Estos casos de uso clave pueden suponer solamente entre el 5 y el 10 por
ciento de todos los casos de uso, pero son los significativos, los que constituyen las funciones
fundamentales del sistema. De manera resumida, se puede decir que el arquitecto:

Crea un esquema en borrador de la arquitectura, comenzando por la parte de la

arquitectura que no es especifica de los casos de uso (por ejemplo, la plataforma). Aunque
esta parte de la arquitectura es independiente de los casos de uso, el arquitecto debe
poseer una comprensin general de los casos de uso antes de comenzar la creacin del
esquema arquitectnico.
30

A continuacin, el arquitecto trabaja con un subconjunto de los casos de uso

especificados, con aquellos que representen las funciones clave del sistema en desarrollo.
Cada caso de uso seleccionado se especifica en detalle y se realiza en trminos de

subsistemas.
A medida que los casos de uso se especifican y maduran, se descubre ms de la
arquitectura. Esto, a su vez, lleva a la maduracin de ms casos de uso.

Este proceso contina hasta que se considere que la arquitectura es estable.

1.6.4

PROCESO ITERATIVO E INCREMENTAL

El desarrollo de un producto software comercial supone un gran esfuerzo que puede durar entre
varios meses hasta posiblemente un ao o ms. Es prctico dividir el trabajo en partes ms
pequeas o mini-proyectos. Cada mini-proyecto es una iteracin que resulta en un incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos, al crecimiento
del producto. Para una efectividad mxima, las iteraciones deben estar controladas; esto es, deben
seleccionarse y ejecutarse de una forma planificada. Es por esto por lo que son mini-proyectos.
Los desarrolladores basan la seleccin de lo que se implementar en una iteracin en dos
factores. En primer lugar, la iteracin trata un grupo de casos de uso que juntos amplan la
utilidad del producto desarrollado hasta ahora. En segundo lugar, la iteracin trata los riesgos ms
importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo tal como
quedaron al final de la ltima iteracin. Al ser mini-proyectos, comienzan con los casos de uso y
continan a travs del trabajo de desarrollo subsiguiente anlisis, diseo, implementacin y
prueba. Que termina convirtiendo en cdigo ejecutable los casos de uso que se desarrollaban
en la iteracin. Por supuesto, un incremento no necesariamente es aditivo. Especialmente en las
primeras fases del ciclo de vida, los desarrolladores pueden tener que remplazar un diseo
superficial por uno ms detallado o sofisticado. En fases posteriores, los incrementos son
tpicamente aditivos.
En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes,
crean un diseo utilizando la arquitectura seleccionada como gua, implementan el diseo
mediante componentes, y verifican que los componentes satisfacen los casos de uso. Si una
iteracin cumple con sus objetivos como suele suceder el desarrollo contina con la
31

siguiente iteracin. Cuando una iteracin no cumple sus objetivos, los desarrolladores deben
revisar sus decisiones previas y probar con un nuevo enfoque.
Para alcanzar el mayor grado de economa en el desarrollo, un equipo de proyecto intentar
seleccionar slo las iteraciones requeridas para lograr el objetivo del proyecto. Intentar
secuenciar las iteraciones en un orden lgico. Un proyecto con xito se ejecutar de una forma
directa, slo con pequeas desviaciones del curso que los desarrolladores planificaron
inicialmente. Por supuesto, en la medida en que se aadan iteraciones o se altere el orden de las
mismas por problemas inesperados, el proceso de desarrollo consumir ms esfuerzo y tiempo.
Uno de los objetivos de la reduccin del riesgo es minimizar los problemas inesperados.
1.6.5

EL PRODUCTO

Cada ciclo produce una nueva versin del sistema, y cada versin es un producto preparado para
su entrega. Consta de un cuerpo de cdigo fuente incluido en componentes que puede compilarse
y ejecutarse, adems de manuales y otros productos asociados. Sin embargo, el producto
terminado no slo debe ajustarse a las necesidades de los usuarios, sino tambin a las de todos los
interesados, es decir, toda la gente que trabajar con el producto. El producto software debera ser
algo ms que el cdigo mquina que se ejecuta.
El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales
y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual artefactos
modelados con el Lenguaje Unificado de Modelado. De hecho, incluye todos los elementos que
se ha mencionado en este captulo, debido a que son esos elementos los que permiten a los
interesados clientes, usuarios, analistas, diseadores, programadores, ingenieros de prueba, y
directores especificar, disear, implementar, probar y utilizar un sistema. Es ms, son esos
elementos los que permiten a los usuarios utilizar y modificar el sistema de generacin en
generacin.
Aunque los componentes ejecutables sean los artefactos ms importantes desde la perspectiva del
usuario, no son suficientes por s solos. Esto se debe a que el entorno cambia. Se mejoran los
sistemas operativos, los sistemas de bases de datos y las mquinas que los soportan. A medida
que el objetivo del sistema se comprende mejor, los propios requisitos pueden cambiar. De hecho,
el que los requisitos cambien es una de las constantes del desarrollo de software. Al final, los
desarrolladores deben afrontar un nuevo ciclo, y los directores deben financiarlo. Para llevar a
32

cabo el siguiente ciclo de manera eficiente, los desarrolladores necesitan todas las
representaciones del producto software (Figura 1-3).

Figura 1-3 Proceso del Desarrollo

Existen dependencias entre muchos de los modelos. Como ejemplo, se indican las dependencias
entre el modelo de casos de uso y los dems modelos.
Un modelo de casos de uso, con todos los casos de uso y su relacin con los usuarios.
Un modelo de anlisis, con dos propsitos: refinar los casos de uso con ms detalle y establecer
la asignacin inicial de funcionalidad del sistema a un conjunto de objetos que proporcionan el
comportamiento.
Un modelo de diseo que define: (a) la estructura esttica del sistema en la forma de
subsistemas, clases e interfaces y (b) los casos de uso reflejados como colaboraciones entre los
subsistemas, clases, e interfaces.
Un modelo de implementacin, que incluye componentes (que representan al cdigo fuente) y la
correspondencia de las clases con los componentes.
33

Un modelo de despliegue que define los nodos fsicos (ordenadores) y la correspondencia e los
componentes con esos nodos.
Un modelo de prueba, que describe los casos de prueba que verifican los casos de uso.
Y, una representacin de la arquitectura.
El sistema tambin debe tener un modelo del dominio o modelo del negocio que describa el
contexto del negocio en el que se halla el sistema.
Todos estos modelos estn relacionados. Juntos, representan al sistema como un lodo. Los
elementos de un modelo poseen dependencias de traza hacia atrs y hacia adelante, mediante
enlaces hacia otros modelos. Por ejemplo, haciendo el seguimiento de un caso de uso (en el
modelo de casos de uso) hasta una realizacin de caso de uso (en el modelo de diseo) y hasta un
caso de prueba (en el modelo de prueba). La trazabilidad facilita la comprensin y el cambio.
1.6.6

FASES DE DESARROLLO DEL SOFWARE

RUP se realiza a lo largo de una serie de ciclos que constituyen el ciclo de vida de un producto,
cada ciclo consta de cuatro fases:
Inicio
Elaboracin
Construccin
Transicin
Cada fase se subdivide a la vez en iteraciones, el nmero de iteraciones en cada fase es variable.
Fase de inicio
Durante la fase de inicio se hace un plan de fases, donde se identifican los principales casos de
uso y se identifican los riesgos. Se concreta la idea, la visin del producto, como se enmarca en el
negocio, el alcance del proyecto. El objetivo en esta etapa es determinar la visin del proyecto.
34

Modelado del negocio

En esta fase el equipo se interioriza con el funcionamiento de la empresa, familiarizndose ms
en sus procesos.

Comprender la estructura y la dinmica de la organizacin para la cual el sistema va ser

desarrollado.

Entender el problema actual en la organizacin objetivo e identificar potenciales mejoras.

Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento comn

de la organizacin objetivo.

Requisitos
En esta lnea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales
tienen que comprender y aceptar los requisitos que especifiquemos.

Establecer y mantener un acuerdo entre clientes y otros stakeholders1 sobre lo que el

sistema podra hacer.

Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema.

Definir el mbito del sistema.

Proveer una base para estimar costos y tiempo de desarrollo del sistema.

Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del
usuario.

Fase de elaboracin

1Proveedores, vendedores, etc.

35

La fase de elaboracin, constituye que las iteraciones se orientan al desarrollo de la baseline de la

arquitectura abarcan ms los flujos de trabajo de requerimientos, modelos de negocios, anlisis,
diseo y una parte de implementacin orientado a la baseline de la arquitectura. 2
Anlisis y Diseo
En esta etapa se especifican los requerimientos y se describen sobre cmo se van a implementar
en el sistema.

Transformar los requisitos al diseo del sistema.

Desarrollar una arquitectura para el sistema.

Adaptar el diseo para que sea consistente con el entorno de implementacin.

Fase de construccin
La fase de construccin tiene como finalidad

la

elaboracin de un producto totalmente

operativo. Construir el producto, la arquitectura y los planes, hasta que el producto est listo para
ser enviado a la comunidad de usuarios. En esta etapa todos los componentes, caractersticas y
requisitos deben ser implementados y probados en su totalidad y obtener la capacidad operacional
inicial del producto.
Implementacin
Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems. El
resultado final es un sistema ejecutable.

Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados,

formando el Plan de Integracin.

Cada implementador decide en qu orden implementa los elementos del subsistema.

Si encuentra errores de diseo, los notifica.

2 Autor , pg. 12
36

Se integra el sistema siguiendo el plan.

Pruebas
Este flujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al final del proceso de desarrollo, sino
que debe ir integrado en todo el ciclo de vida.

Encontrar y documentar defectos en la calidad del software.

Generalmente asesora sobre la calidad del software percibida.

Provee la validacin de los supuestos realizados en el diseo y especificacin de

requisitos por medio de demostraciones concretas.

Verificar las funciones del producto de software segn lo diseado.

Verificar que los requisitos tengan su apropiada implementacin.

Etapa de transicin
Se realiza la instalacin del producto en el cliente y se procede al entrenamiento de los usuarios.
Realizar la transicin del producto a los usuarios, lo cual incluye: manufactura, envo,
entrenamiento, soporte y mantenimiento del producto, hasta que el cliente quede satisfecho, por
tanto en esta fase suelen ocurrir cambios. 3
Despliegue
Esta actividad tiene como objetivo producir con xito distribuciones del producto y distribuirlo a
los usuarios. Las actividades implicadas incluyen:

Probar el producto en su entorno de ejecucin final.

Empaquetar el software para su distribucin.

Distribuir el software.

3
37

Instalar el software.

Proveer asistencia y ayuda a los usuarios.

Formar a los usuarios y al cuerpo de ventas.

Migrar el software existente o convertir bases de datos.

Figura 1-4 Proceso Unificado de Desarrollo de software

Fuente:

1.6.7

RUP AGIL

En el presente proyecto se aplicara la metodologa RUP gil, a travs del cual se desarrolla el
mismo procedimiento del RUP clsico con la diferencia de que solo se considera la aplicacin de
algunos diagramas UML de acuerdo a la complejidad del sistema.

38

CAPITULO II
DETERMINACION DE REQUERIMIENTOS

39

1.7

GENERALIDADES

Mediante el modelo de requisitos se desarrolla el trabajo de obtencin de los requerimientos del

departamento de Medicin- tarifas y otros dependientes de la superintendencia comercial con el
objetivo de guiar el desarrollo hacia un sistema correcto y capturar la funcionalidad que ofrecer
desde la perspectiva del usuario.
A travs de los casos de uso y el mtodo VORD se capturan los requerimientos funcionales y no
funcionales para definir las acciones que debe ser capaz de realizar el sistema y las propiedades
con las que debe contar tales como rendimiento, seguridad, disponibilidad, extensibilidad,
usabilidad.
1.8
1.8.1

DESCRIPCIN DEL NEGOCIO

MODELO DE CASOS DE USO DEL NEGOCIO

El modelado del negocio es una tcnica para comprender

los procesos de negocio de la

organizacin que sern considerados en el nuevo sistema en trminos de casos de uso y actores
que corresponden con los procesos del negocio.
El entendimiento de los procesos del negocio permite identificar las necesidades inmediatas de
mejora relacionadas con los sistemas informticos que son el resultado final del sistema en
desarrollo.
A continuacin se presenta el diagrama de modelado de casos de uso del negocio:

40

Realizar reportes

Gerente General

Realizar Controles
Superintendente Comercial

Supervisor Medicion-Tarifas

Realizar Seguimiento

Elaborar Ruta
Personal Administrativo

Tecnico Laboratorio
Realizar Observaciones

Registrar Datos Tecnicos

Cliente

Registrar Cliente

Figura 2-5 Diagrama de Casos de uso del Negocio

41

1.8.2

ESPECIFICACION DE ACTORES DEL NEGOCIO

A continuacin se detalla a los actores que intervienen en el negocio:

Tabla 2-1 Especificacin Actor del Negocio Gerente General

Actor

Gerente General

Descripcin

Es el encargado de dar seguimiento de manera general a todas

las actividades que se desarrollan en la empresa.

Responsabilidade

Es el responsable de autorizar la ejecucin de actividades

dentro de la empresa.

Tabla 2-2 Especificacin Actor del Negocio Superintendente Comercial

Actor

Superintendente Comercial

Descripcin

Es el responsable de dar seguimiento y control de las

actividades que se llevan en el rea comercial de la empresa de
luz.

Responsabilidade

Es el responsable de coordinar con los clientes especiales, y

tomar decisiones respecto al tratamiento de los mismos.

Tabla 2-3 Especificacin Actor del Negocio Supervisor de Medicin y Tarifas

Actor

Supervisor de Medicin y tarifas

Descripcin

Es el encargado del departamento de medicin y tarifas.

Responsabilidade

Es el responsable de coordinar y de llevar a cabo las

actividades en campo de clientes especiales.

42

Tabla 2-4 Especificacin Actor del Negocio Personal Administrativo

Actor

Personal Administrativo

Descripcin

Es el personal administrativo que desempea funciones en el

rea comercial de la empresa.

Responsabilidade

Son los responsables de tomar lecturas en terreno de los puntos

de medicin de acuerdo al rol mensual establecido por la

empresa

Tabla 2-5 Especificacin Actor del Negocio Tcnico de laboratorio

Actor

Tcnico de laboratorio

Descripcin

Es el personal dependiente del departamento de medicin y

tarifas encargados de la parte tcnica de los sistemas de
medicin de energa elctrica.

Responsabilidade

Son los responsable de la calibracin de medidores,

mantenimiento e instalacin tcnica del punto de medicin de

clientes especiales.

1.9

METODO VORD

El mtodo de definicin de Requerimientos orientado a puntos de vista (VORD), recoge

informacin basado en puntos de vista que se enfocan en usuarios involucrados en la
organizacin, estos puntos proyectan las clases de usuarios del sistema.

43

Los puntos de vista que estructuran el ncleo del modelo, son conocidos como puntos de vista
directos .Por el hecho de que no todos los requerimientos son derivados de gente o subsistemas
que interactan con sistemas especificados. Los puntos de vista que respecta a sistemas externos
que tienen influencia en el dominio de la aplicacin tambin son considerados y son llamados
puntos de vista indirectos.
Puntos de vista Directos. Estos corresponden directamente a clientes que reciben servicios del
sistema y envan informacin de datos y de control al sistema. Pueden ser cualquier sistema
usuario/operador u otro subsistema que interacta con el sistema analizado.
Puntos de vista Indirectos. Los puntos de vista indirectos tienen un inters en algunos o todos
los servicios del sistema, pero no interactan directamente con l, estos pueden generar
requerimientos que restringen los servicios entregados a puntos de vista directos.
Los puntos de vista indirectos tienen una importancia en los puntos de vista de la ingeniera
(estos se refieren al diseo e implementacin del sistema), mediante los puntos de vista
organizacional (se refieren a la influencia de organizacin), a puntos de vista externos (se refieren
a la influencia del sistema en el ambiente externo).
Para la determinacin de requerimientos que el rea de medidores y tarifa necesita, es necesario
identificar y documentar los requerimientos funcionales del sistema, es decir las tareas que el
sistema realizara y tambin es necesario determinar los requerimientos no funcionales que llegan
a ser los atributos que el sistema debe tener y as obtenemos el modelo de requisitos.
El primer paso es identificarlos puntos de vista mediante la tcnica de lluvia de ideas

1.9.1

LLUVIA DE IDEAS
Ver reportes
estadsticos
Genera
seguimiento
de control

Gerente General

44

Asignar marcadores
georeferenciados
Supervisor de
Medidores

Ingresa
observaciones

Genera Reportes

Ver ubicaciones
geogrficas

Actualiza datos

Superintendente
Comercial

Integra mapas
georeferenciados

Registra cliente
Ver datos del
cliente
Eliminar cliente
Actualizar Cliente

Ver resumen de
clientes

Autentificar
Usuario

Administrador

Personal
Administrativo
Ver caractersticas
geogrficas

Tcnicos de
laboratorio

Ingresa datos
Tcnicos

Ingresar datos
georeferenciados

Figura 2-6 Diagrama Lluvia de Ideas

1.9.2

ESTRUCTURACION DE LOS PUNTOS DE VISTA

A continuacin se asocian los servicios con las entidades del sistema:

Tabla 2-6 Estructuracin de los puntos de vista

GERENTE

SUPERINTENDENTE

GENERAL

COMERCIAL

ADMINISTRADOR

Lista de servicios

Lista de servicios

Lista de servicios

45

Ver reportes
estadsticos

Ver reportes estadsticos

Ingresar observaciones
Ver resumen de clientes
Ver ubicaciones

Genera reporte
Actualiza datos
Gestionar usuario
Integra mapas

georeferenciados
Ver datos del cliente
Registra clientes

geogrficas

Tabla 2-7 Estructuracin de los puntos de vista

SUPERVISOR

PERSONAL

MEDIDORES-TARIFAS

ADMINISTRATIVO

TECNICOS

Lista de servicios

Lista de servicios

Lista de servicios

Genera seguimiento de control

Genera reportes

Actualiza datos
Asignar marcadores

georeferenciados
Ver ubicaciones geogrficas
Ver reportes estadsticos

1.9.3

Ver datos del cliente

Ver ubicaciones

Ingresa datos tcnicos

Ingresa datos

geogrficas
georeferenciados
Ver resumen de clientes Registra clientes
Ver caractersticas
geogrficas

JERARQUIA DE LOS PUNTOS DE VISTA

Se organiza los puntos de vista en una jerarqua de herencia, para mostrar las partes que tienen en
comn y reutilizar la informacin de los mismos.
En la figura se muestra la jerarqua de puntos de vista para el campo de accin.
TODOS LOS PUNTOS DE VISTA

Personal Elfeosa rea Comercial-Medicin y tarifas

Personal Administrativo
Tcnicos
Gerente Superintendente
General
Comercial
Administrador
Supervisor de Medidores-tarifas
46

Figura 2-7 Jerarqua de los Puntos de Vista

1.10 DETERMINACION DE REQUERIMIENTOS

1.10.1 REQUERIMIENTOS FUNCIONALES
Tabla 2-8 Requerimientos Funcionales

REF.

FUNCION

CATEGO
RIA

R1

Autentificar usuario

Evidente

R2

Gestionar Usuario

Evidente

R3

Gestionar cliente

Evidente

R4

Gestionar datos tcnicos

Evidente

R5

Gestionar datos georeferenciados

Evidente

R6

Asignar marcadores georeferenciados

Evidente

R7

Integrar mapa georeferenciado

Evidente

R8

Generar control

Evidente

R9

Realizar Seguimiento

Evidente

R10

Genera Ruta Geogrfica

Evidente

R11

Generar reporte georeferenciados

Evidente

R12

Generar reporte

Evidente

R13

Generar Observaciones de Campo

Evidente

1.10.2 REQUERIMIENTOS NO FUNCIONALES

Tabla 2-9 Requerimientos No Funcionales

SIM
BOL
O
ATRIBUTO

A1

Seguridad

A2

Usabilidad

DESCRIPCION
Por la importancia de la informacin de los
clientes, la aplicacin debe presentar patrones
de seguridad (contraseas y niveles de
usuarios)
La navegacin se la debe realizar a travs de
navegadores estndar de internet en la red de
la empresa
47

A3
A4
A5
A6

La aplicacin debe carga en tiempos

Rendimiento aceptables acorde a las solicitudes del usuario
Debe estar disponible en los horarios de trabajo
Disponibilidad de acceso de los usuarios
El cdigo debe ser consistente y reutilizable, de
Mantenibilida tal manera que las modificaciones del sistema
d
se las pueda realizar sin mucha dificultad.
El sistema debe presentar un entorno de
Amigabilidad trabajo de fcil manejo para el usuario.

48

CAPITULO III
ANALISIS DEL SISTEMA

49

CAPTULO III
2
2.1

ANLISIS

GENERALIDADES

El presente capitulo tiene la finalidad de generar la arquitectura de objetos para el diseo del
sistema. En este caso para el desarrollo del proyecto se empleara la arquitectura MVC (Modelo,
Vista, Controlador), esta arquitectura se basa en tres aspectos muy importantes: Modelo que
corresponde a la informacin del sistema, Vista correspondiente a la presentacin al usuario y el
Controlador que corresponde al comportamiento del sistema.
2.2
2.2.1

MODELO DE LOS CASOS DE USO DEL SISTEMA

IDENTIFICACION DE ACTORES

Figura 3-8 Identificacin de actores

50

2.2.2

DESCRIPCION DE LOS ACTORES

A continuacin se describen a los actores del caso de uso del sistema.

Tabla 3-10 Descripcin de Actores - Usuario

ACTOR

Usuario

CASO DE USO

Todos

DESCRIPCIN DEL
ACTOR

Representa a todos los actores que tendrn acceso al

sistema: Superintendente comercial, Supervisor de Medicin y
Tarifas, Personal Administrativo, Tcnico de laboratorio

Tabla 3-11 Descripcin de Actores - Administrador

ACTOR

Administrador
Gestionar Usuario, Integrar Mapa georeferenciado y Generar

CASO DE USO

Reporte
Es el actor principal que administra el sistema con acceso
ilimitado y tiene la autoridad para registrar nuevos usuario que

DESCRIPCIN DEL ACTOR podrn acceder al sistema y tiene la autoridad de poder integrar
los mapas georeferenciados de acuerdo a las necesidades del
usuario.

Tabla 3-12 Descripcin de Actores Gerente general

51

ACTOR

Gerente general

CASO DE USO

Generar Reporte

DESCRIPCIN DEL
ACTOR

El actor que solo tendr acceso a generar reportes estadsticos y

reportes grficos.

Tabla 3-13 Descripcin de Actores Superintendente Comercial

ACTOR

Superintendente Comercial

CASO DE USO

Generar Reporte, Realizar Controles

DESCRIPCIN DEL
ACTOR

El actor que solo tendr acceso a generara reportes estadsticos

y reportes grficos para la toma de decisiones respecto al
tratamiento que se dar a clientes especiales.

Tabla 3-14 Descripcin de Actores Supervisor de Medicin y Tarifas

ACTOR

Supervisor de Medicin y Tarifas

Generar

CASO DE USO

reporte,

Generar

Control,

Asignar

Marcadores

Georeferenciados, Realizar Seguimiento, Gestionar datos

Tcnicos, Gestionar Cliente, Gestionar datos georeferenciados y
Generar Ruta Georeferenciada
Es el actor de gran importancia que interacta

todas las

DESCRIPCIN DEL

actividades que se dan en el departamento de medidores,

ACTOR

coordina el registro de nuevos cliente y realiza peridicamente

control de los mismos en sus aspectos tcnicos.

Tabla 3-15 Descripcin de Actores Tcnico de laboratorio

52

Genera Reporte
Georeferenciado

Tcnico de laboratorio
Realizar Seguimiento, Gestionar datos Tcnicos, Gestionar
Tcnico de Laboratorio

Autentificar Usuario

Personal Administrativ o

ACTOR

Cliente, Gestionar datos Georeferenciados, Genera Ruta

CASO DE USO

Generar
Observ aciones de
Campo

Georeferenciada, Generar Observaciones de Campo y Genera

Reporte Geogrfico

Integra Mapa
Georeferenciado

Es el actor que se encarga de ingresar y actualizar la

DESCRIPCIN DEL

informacin tcnica de nuevos clientes especiales e ingresar los

ACTOR

datos tcnicos y georeferenciados recopilados en el lugar del

Campo

Genera

reportes

Georeferenciado
Es el actor que requiere la ubicacin geogrfica mediante los
reportes geogrficos para la correspondiente toma de lecturas de
acuerdo al rol de produccin del mes.

Asignar Marcadores
Georeferenciados

Gernera Control

Ingresa Rol de
Produccion

DESCRIPCION DE LOS CASOS DE USO

Generar Reporte

Gestionar Usuario

uc Casos de uso principales

ACTOR

de

Realizar Seguimiento

DESCRIPCIN DEL

Observaciones

Gestionar datos
Tcnicos

Gerente General

CASO DE USO

Generar

Gestionar Cliente

Personal Administrativo

Superv isor de medicin y

Tarifas

ACTOR

2.2.3

Gestionar datos
Georeferenciadas

Genera Ruta
Georeferenciada

Tabla 3-16 Descripcin de Actores Personal Administrativo

Superintendente
comercial

Administrador

Usuario

punto de suministro instalado.

53

Figura 3-9 Diagrama de Casos de Uso del Sistema

54

Figura 3-10 Pantalla Autentificar Usuario

Tabla 3-17 Descripcin Caso de uso Autentificar Usuario

Caso de uso

Autentificar Usuario

Actores

Usuario

Tipo

Bsico

Propsito

Restringir acceso del usuario al sistema

Este caso de uso es iniciado por el usuario al momento

Resumen

de ingresar al sistema mediante un login (usuario) y una

contrasea (password) que es asignado por el
administrador del sistema.

55

Es necesario haber llenado previamente el formulario

Precondiciones

de registro de usuario y haber generado el usuario y

contrasea.
1. Se presenta esta pantalla al inicio del sistema.
2. El usuario ingresa nombre de usuario y el
password que el encargado del sistema le asigno.
3. El sistema internamente valida los datos.

Flujo principal

4. Una vez validada la informacin el sistema

muestra la ventana principal del sistema con las
opciones habilitadas de acuerdo al rol de usuario
que accede al sistema.
5. Si el usuario elige salir, este se saldr de todo el
sistema dejando sin efecto los datos que ingreso
(password, usuario).

Subflujos

Ninguno
En caso de que el usuario ingrese un nombre de usuario
o password incorrecto, el sistema proporcionara un

Excepciones

mensaje de datos incorrecto, y permitir que el

usuario pueda intentar tres veces y si los datos no son
correcto el sistema se cerrara.

56

Figura 3-11 Pantalla Gestionar Usuario

57

Figura 3-12 Pantalla Gestionar Usuario Registrar usuario

Figura 3-13 Pantalla Gestionar Usuario Actualizar usuario

58

Figura 3-14 Pantalla Gestionar Usuario Eliminar Usuario

Figura 3-15 Pantalla Gestionar Usuario cambiar Contrasea

Tabla 3-18 Descripcin Caso de uso Gestionar Usuario

Caso de uso

Gestionar Usuario

Actores

Todos los usuarios

Tipo

Bsico

Propsito

Resumen

Permite registrar, actualizar, eliminar y cambiar

contrasea de un usuario que acceder al sistema.
Este caso de uso permite habilitar, eliminar y actualizar
los datos de los usuarios que accedern al sistema.
59

Precondiciones

Flujo principal

Haber ingresado con la cuenta y password en la

pantalla principal.
1. El caso de uso comienza cuando el usuario ingresa
al sistema y elige la opcin USUARIO en la
ventana principal.
2. Se desplegara la pantalla GESTIONAR USUARIO
en la cual se podr buscar a los usuarios
registrados mediante nombre, apellidos o nmero
de carnet .
3. El usuario podr desplegar todos los registros
presionado la opcin buscar sin haber ingresado
ningn dato en los campos previos.
4. De

acuerdo a la tarea que se est realizando

(Registrar, Actualizar, Eliminar, Ver datos) el caso

de uso derivara a los siguientes subflujos:

REGISTRAR (S-1)
El administrador ingresa los datos requeridos en
el formulario para registrar un nuevo usuario

que acceder al sistema.

El sistema valida los datos ingresados.
Esta informacin se almacena en la base de

datos.
En caso

de

que

eligiera

la

opcin

CANCELAR la ventana se cerrara sin causar

ningn efecto y volver al pantalla anterior.

ACTUALIZAR (S-2)
El administrador seleccionando esta opcin
modifica los datos (Nombre, Apellido, CI, etc.)

del usuario seleccionado.

El sistema valida los datos ingresados.
Esta informacin se almacena en la base de
60

datos.
ELIMINAR (S-3)
El administrador seleccionando esta opcin

podr dar de baja a un usuario del sistema.

En caso de que eligiera la opcin
CANCELAR

la ventana se cerrara sin

eliminar al usuario seleccionado.

CONTRASEA(S-4)
El usuario elige esta opcin y se desplegara una
ventana en la cual debe ingresar la contrasea

actual y la nueva.
Si el usuario presiona cancel la ventana se cierra

sin causar ningn efecto.

5. En caso de que el usuario elija la opcin salir la
ventana se cerrara y volver a la pgina principal.

Subflujos

(S-1) REGISTRAR, (S-2) ACTUALIZAR, (S-3)

ELIMINAR,(S-4) CONTRASEA.
(S-1),(S-2) Si alguno de los campos no es completado

Excepciones

de manera correcta se presentara el mensaje de error.

(S-1), (S-2), (S-3) solo tiene acceso el administrador
del sistema.

61

Figura 3-16 Pantalla Gestionar Cliente

62

Figura 3-17 Pantalla Gestionar Cliente Registra Cliente

Figura 3-18 Pantalla Gestionar Cliente Actualizar Cliente

63

Figura 3-19 Pantalla Gestionar Cliente Eliminar Cliente

64

Figura 3-20 Pantalla Gestionar Cliente Datos Tcnicos

Figura 3-21 Pantalla Gestionar Cliente Coordenadas Geo referenciadas

65

Figura 3-22 Pantalla Gestionar Cliente Observaciones Cliente

Tabla 3-19 Descripcin Caso de Uso Gestionar Cliente

Caso de uso

Actores

Tipo

Propsito

Gestionar Cliente
Supervisor

de

medicin

y tarifas, Tcnico

de

laboratorio
Bsico
Permite registrar, actualizar, eliminar y ver los datos de
un cliente especial de la base de datos.
Este caso de uso permite gestionar los clientes

Resumen

especiales nuevos y existentes como tambin permite

ingresar

sus

datos

tcnicos

la

informacin

georeferenciada requerida.

Precondiciones

Flujo principal

Haber ingresado al sistema mediante la cuenta y

password correspondiente.
1. El caso de uso comienza cuando el usuario ingresa
al sistema y elige la opcin CLIENTES en la
ventana principal.
2. Se

desplegara

la

pantalla

GESTIONAR

CLIENTES en la cual se podr buscar a los

usuarios

registrados

mediante

Cod_Cliente,

nmero de medidor, C.I. u otros datos personales.

3. El sistema desplegara un listado de los registros
que coinciden con la informacin ingresada para la
66

bsqueda.
4. De

acuerdo a la tarea que se est realizando

(Registrar, Actualizar, Eliminar, Dat. tcnicos, Dat.

Geo) el caso de uso derivara a los siguientes
subflujos:

REGISTRAR NUEVO (S-1)

El usuario elige esta opcin para ingresar un

nuevo cliente en la bases de datos.

Al elegir esta opcin inmediatamente

presenta la pantalla de registrar cliente.

El usuario llena la informacin requerida en el

formulario.
El sistema valida los datos ingresados.
Al elegir GUARDAR, la informacin se

almacena en la base de datos.

El usuario podr elegir el subflujo DATOS

se

TECNICOS en caso de que quiera ingresar esta

-

informacin a continuacin del registro.

Si el usuario elige la opcin CANCELAR la
ventana se cerrara sin causar ningn efecto y

volver al pantalla anterior.

ACTUALIZAR (S-2)
El usuario al elegir esta opcin se le presentara
una pantalla con la informacin del cliente en la
cual

puede

realizar

las

modificaciones

necesarias del cliente seleccionado en el listado

-

de bsqueda.
El sistema valida los datos ingresados.
El usuario tambin podr optar por modificar la
informacin tcnica y georeferenciada a travs
de las opciones DATOS TEC. y DATOS GEO

correspondientes.
Esta informacin se actualiza en la base de
datos.
67

ELIMINAR (S-3)
El usuario al elegir esta opcin podr dar de

baja a un cliente especial del sistema.

El usuario elige esta opcin y no muestra una
ventana en la que se muestran los datos del

personales del cliente especial seleccionado

Si el usuario elige la opcin eliminar el sistema

mostrara el mensaje Desea eliminar el cliente.

En caso de que el usuario elija la opcin
ACEPTAR en registro de este cliente ser dado

de baja.
En caso

de

CANCELAR

que

eligiera

la

opcin

la ventana se cerrara sin

eliminar al usuario seleccionado.

DATOS TECNICOS (S-4)
El usuario elige esta opcin y se desplegara una
ventana en la cual debe ingresar toda la
informacin tcnica del punto de medicin del

cliente.
El usuario llena los datos tcnicos requeridos en

el formulario y presiona aceptar.

La informacin es validada por el sistema y se

almacena en la base de datos.

Si el usuario presiona cancel la ventana se cierra

sin causar ningn efecto.

DATOS GEO (S-5)
El usuario elige esta opcin cuando concluyo
con el registro del nuevo cliente y el ingreso de

los datos tcnicos del mismo.

El sistema presenta un formulario en el cual el
usuario ingresa la informacin que se recolecto

en campo mediante GPS.

Mediante la opcin

CONVERTIR

se

transforman las coordenadas recolectadas en

campo en coordenadas que el google maps

68

soporta.
Mediante el sub flujo VER MAPA se visualiza

el punto ingresado en el mapa georeferenciado.

Con la opcin Aceptar se registra la
informacin

georeferenciada

al

cliente

seleccionado.
Si el usuario elige la opcin Cancelar los

datos sern descartados.

OBSERVACIONES (S-6)
El usuario elige esta opcin y se ejecuta un
nueva pantalla en la q se puede observar datos

del cliente seleccionado.

El usuario selecciona el nivel de atencin y el
tipo de observacin marcado las casillas

correspondientes.
Inmediatamente se habilita la casilla donde

ingresa las observaciones hechas al cliente.

Al presionar GUARDAR la informacin se

almacena en la base de datos.

Si el usuario elige la opcin Cancelar los

datos sern descartados.

5. En caso de que el usuario elija la opcin salir la
ventana se cerrara y volver a la pgina principal.
(S-1) REGISTRAR NUEVO, (S-2) ACTUALIZAR,
Subflujos

(S-3) ELIMINAR, (S-4) DATOS TECNICOS, (S-5)

DATOS GEO, (S-6) OBSERVACIONES.
(S-1), (S-2), (S-4) y (S-5) Si alguno de los campos no
es completado de manera correcta se presentara el
mensaje de error. (S-1), (S-2), (S-3), (S-4), (S-5) solo

Excepciones

tienen acceso el supervisor de medidores, y los tcnicos

de laboratorio.
(S-6) Todos los usuarios tienen accesos a esta opcin.
69

Figura 3-23 Pantalla Gestionar Datos Georeferenciados

70

Figura 3-24 Pantalla Gestionar Datos Georeferenciados Coordenadas Georeferenciadas

Figura 3-25 Pantalla Gestionar Datos Georeferenciados Actualizar Coordenadas

71

Figura 3-26 Pantalla Gestionar Datos Georeferenciados Asignar Imagen

Tabla 3-20 Descripcin Caso de Uso Gestionar datos Georeferenciados

Caso de uso

Gestionar Datos Georeferenciados

Actores

Todos los usuarios

Tipo

Bsico
Permite

Propsito

registrar,

actualizar,

eliminar,

asignar

marcadores y asignar imagen a las ubicaciones

geogrficas de clientes especiales.

Resumen

Este caso de uso permite realizar actualizaciones de las

72

coordenadas geogrficas tomadas por un GPS, asignar

marcadores en el mapa de acuerdo al caso y subir
fotografas de los puntos de medicin

Precondiciones

Flujo principal

Contar por lo menos con un cliente especial registrado

en la base de datos.
1. El caso de uso comienza cuando el usuario ingresa
al

sistema

elige

la

opcin

MAPA

GEOREFERENCIADO en la ventana principal.

2. Se

desplegara

la

pantalla

GESTIONAR

COORDENADAS GEOREFERENCIADAS en
la cual se podr buscar a los Clientes Especiales
registrados en la base de datos
3. El sistema desplegara un listado de los registros
que coinciden con la informacin ingresada para la
bsqueda.
4. De

acuerdo a la tarea que se est realizando

(Registrar, Actualizar, Eliminar, Asig. Imagen) el

caso de uso derivara a los siguientes subflujos:

REGISTRAR (S-1)
El usuario elige esta opcin para ingresar las

coordenadas tomadas por el GPS en terreno

Al elegir esta opcin inmediatamente
presenta

la

pantalla

se

COORDENADAS

GEOREFERENCIADAS
El usuario ingresa la informacin requerida y
mediante la opcin CONVERTIR, transforma

los datos en el formato de Google Map.

El sistema valida los datos ingresados.
Si el usuario elige la opcin VER MAPA podr
73

ver el mapa con las coordenadas ingresadas e

-

identificado por un marcador.

Al elegir GUARDAR, la informacin se

almacena en la base de datos.

En caso que el usuario seleccione cerrar, la

ventana cerrara sin generar ningn efecto.

ACTUALIZAR (S-2)
El usuario al elegir esta opcin se le presentara
la pantalla con la informacin georeferenciada

actual del cliente

El
usuario podr

coordenadas para remplazar las actuales.

Si el usuario elige la opcin VER MAPA, SE

ingresar

las

nuevas

generara una nueva ventana en la que presentara

la ubicacin geogrfica mediante un marcador
-

en el mapa geogrfico.
El usuario al seleccionar la opcin VER MAPA
X-Y, podr visualizar los dos puntos en el mapa

georeferenciado.
Al seleccionar GUARDAR la informacin
actual es remplazada con la nueva y guardada

en la base de datos.
ELIMINAR (S-3)
Cuando el usuario selecciona esta opcin, el
sistema despliega la ventana con el mensaje

ELIMINAR COORDENADA.
El usuario al presionar ACEPTAR

coordenadas son eliminadas de la base de datos.

En caso de que eligiera la opcin

las

CANCELAR la ventana se cerrara sin causar

ningn efectos
ASIG.IMAGEN (S-4)
El usuario elige esta opcin y se desplegara una
ventana en la cual podr cargar una fotografa e

ingresar su descripcin correspondiente

El usuario elegir las opciones IMG.PTO
74

SUMIN. para asignar la fotografa del punto de

-

suministro.
El usuario podr seleccionar IMG.OBS para

asignar fotografas de observaciones tcnicas.

Tambin el usuario podr optar por la opcin
IMG.RUTA

para

asignar

fotografas

correspondientes a las rutas de acceso al punto

-

de suministro.
Mediante la opcin GUARDAR la imagen se

almacenara en la base de datos.

Si el usuario presiona cancel la ventana se cierra

sin causar ningn efecto.

5. En caso de que el usuario elija la opcin salir la
ventana se cerrara y volver a la pgina principal.

Subflujos

(S-1)

REGISTRA,

(S-2)

ACTUALIZAR,

(S-3)

ELIMINAR, ASIG.IMAGEN (S-4).

(S-1),(S-2), Si las coordenadas no son ingresadas de
acuerdo al formato el sistema presentara mensaje de

Excepciones

error. (S-1), (S-2), (S-3), solo tienen acceso el

administrador del sistema, el supervisor de medidores y
los tcnicos de laboratorio.

75

Figura 3-27 Pantalla Generar Reporte

Tabla 3-21 Descripcin Caso de uso Generar reporte

Caso de uso

Actores

Tipo

Propsito

Resumen

Generar reporte
Superintendente, Gerente, Supervisor. Tcnicos de
laboratorio, Personal Administrativo.
Bsico
Permite generar reportes estadsticos mediante tablas o
graficas de barras.
Este caso de uso permite que el usuario pueda generar
reportes de clientes especiales por fechas, por
categoras y por situacin en la que se encuentra el
76

cliente (activo, dado de baja o todos).

Se debe haber ingresado algunos registros de clientes
Precondiciones

en la base de datos para que los reportes no se generen

vacos.
1. Este caso de uso comienza cuando el usuario
decide generar graficas o tablas respecto a clientes
especiales ingresando a la pestaa reportes.
2. El sistema muestra un formulario en el cual se
selecciona el mes y ao.

Flujo principal

3. Al mismo tiempo el usuario selecciona la categora

de los clientes del cual quiere generar el reporte
correspondiente.
4. El usuario puede seleccionar si el reporte solo
contemplara a clientes activos, dados de baja o a
todos los registrados.

Si el usuario selecciona la pestaa GRAFICA, el

sistema generara reportes en graficas de barras de
acuerdo a los parmetros que el usuario selecciono.
Subflujos
En caso de que el usuario selecciona la pestaa
TABLA, el sistema generara datos tabulados de
acuerdo a los parmetros que el usuario requiere.
Excepciones

Todos los datos deben ser ingresados para poder

generar el reporte deseado, caso contrario se emitir un
mensaje seleccione datos, y no se generara ningn
77

reporte.

78

CAPITULO IV
DISEO

79

CAPTULO IV
3
3.1

DISEO

GENERALIDADES

El presente capitulo muestra el desarrollo de la arquitectura del diseo del sistema como
resultado del anlisis realizado en el capitulo anterior y dar continuidad a las reglas del negocio.

80

3.2

DIAGRAMA DE SECUENCIA

Caso de Uso: Gestionar Usuario

Figura 4-28 Diagrama Gestionar usuario-registrar

81

Figura 4-29 Diagrama Gestionar usuario - Actualizar

Figura 4-30 Diagrama Gestionar Usuario- Eliminar

82

Figura 4-31 Diagrama Gestionar usuario- Cambiar Contrasea

Caso de Uso: Gestionar Cliente

Figura 4-32 Diagrama Gestionar Cliente - Registrar

83

Figura 4-33 Diagrama Gestionar Cliente -Actualizar

84

Usuario

IdDatostecnicos: INT
IdCliente: INT
PTS: BOOLEAN
CTS: BOOLEAN
multiplicador: INT
voltaje: INT
ampct: INT
capsmee: INT
propcts: VARCHAR(15)
ptosum: VARCHAR(2)
ptomed: VARCHAR(2)
kw_pta: INT
kw_fpta: INT

DatosTecnicos

Categorias: INT
Nombre: VARCHAR(45)
*

IdUsuario: INT = 'Usuario'

Cuenta: VARCHAR(20)
Password: VARCHAR(45)
Salt : VARCHAR(45)
Nombre: VARCHAR(45)
Ap_paterno: VARCHAR(45)
Ap_Materno: VARCHAR(45)
CI: VARCHAR(8)
CI_expedido: VARCHAR(2)
Rol: VARCHAR(20)
Activo: BOOLEAN
IdCargo: INT
IdDepartamentos: INT

Categorias

#
-

#
-

Departamentos

#
-

Cliente

* -

#
-

Observ acionesCliente

Descripcion: VARCHAR(255)
Estado: VARCHAR(45)
Nivel_atencion: VARCHAR(10)
Tipo_Obs: VARCHAR(20)
IdUsuario: INT
IdCliente: INT
UrlImagen: VARCHAR(200)
Fecha: DATE

IdMedidor: INT = 'Medidor'

CodigoMedidor: VARCHAR(3)
TipoMedidor: VARCHAR(15)
medidor: INT
MultiplicadorInterno: INT
IdCliente: INT

Cargo

Datosgeoreferenciados

DIAGRAMA DE CLASES PERSISTENTES

IdDatosGeoreferenciados: INT = 'DatosGeorefere...

Idcliente: DOUBLE
Latitud: DOUBLE
Longitud: DOUBLE
UrlImagen: VARCHAR(200)
Altura: DOUBLE
Fecha: DATE
Observacion: VARCHAR(50)

RepresentanteLegal

IdImagenesRuta: INT = 'ImagenesRuta'

UrlImagen: VARCHAR(200)
Latitud: DOUBLE
longitud: DOUBLE
Orden: INT
IdCliente: INT

ImagenesRuta

#
1 -

IdCargo: INT
Cargo: VARCHAR(20)

IdRepresentanteLegal: INT
ci: VARCHAR(45)
ci_expedido: VARCHAR(2)
Nombre: VARCHAR(45)
Apellido_Paterno: VARCHAR(45)
Apellido_Materno: VARCHAR(45)
IdCliente: INT

#
*
-

Superintendencia
IdSuperintendencia: INT = 'Superintendencia'
Nombre: VARCHAR(30)

1 -

#
1 -

A continuacin se presenta el diagrama de clases persistentes del sistema.

Medidor

IdCliente: INT = 'Cliente'

Cod_cliente: INT
Empresa: VARCHAR(45)
IdCategoria: INT
Estado: VARCHAR(15)
UrlImagen: VARCHAR(200)
Direccion: VARCHAR(200)

IdDepartamentos: INT = 'Departamentos'

Nombre: VARCHAR(20)
IdSuperintendencia: INT

3.3

class Sistema

Figura 4-34 Diagrama Gestionar Cliente - Eliminar

Figura 4-35 Diagrama de Clases Persistentes

85

+
+
+
+
+
+

+
+
+
+
+
+

+
+
+
+
+
+

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

+
+
+
+
+
+

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

Imagenesruta

1..*

1..*

1..*

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

Cliente

init() : var
indexAction() : var
nuevoAction() : var
editarAction() : var
borrarAction() : var
listarAction() : var
buscarAction() : var

+
+
+
1..*
+
+
+

+
+
+
+
+
1 +
+

Usuario

+
+
+
+
+
+

+
+
+
+
+
+

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

Cargo

init() : var
indexAction() : var
nuevoAction() : var
listarAction() : var
editarAction() : var
borrarAction() : var

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

MedidorController

+
+
+
1 +
+
+

Departamentos

+
+
+

+
1 +
+
+
+
+

+
+
+
1 +
+
+

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

DatosGeoreferenciados

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

Datostecnicos

init() : var
indexAction() : var
nuevoAction() : var
editarAction() : var
borrarAction() : var
listarAction() : var
arrayListaSuperintendencias() : var

init() : var
indexAction() : var
verpuntoAction() : var

MapageoReferenciado

1..*

+
+
+
1 +
+
+
+

Superintendencia

DIAGRAMA DE CONTROL

Categorias

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

Representantelegal

init() : var
indexAction() : var
borrarAction() : var
editarAction() : var
listarAction() : var
nuevoAction() : var

Observ acionescliente

class Controladores

3.4

Figura 4-36 Diagrama de Control

86

3.5

DIAGRAMA DE PAQUETES

Figura 4-37 Diagrama de Paquetes

87

CAPITULO V
IMPLEMENTACIN

88

CAPTULO V
4
4.1

IMPLEMENTACIN

GENERALIDADES

El presente capitulo se desarrollar el modelo del Diseo a travs del diagrama de componentes
que contempla el sistema, consecutivamente se presenta el diagrama de despliegue que representa
la arquitectura del sistema.
4.2

DIAGRAMA DE COMPONENTES

Figura 5- 38 Diagrama de Componentes

89

Sup.Medicion-Tarifas:
Usuario
TCP/IP

Gerente
General:Usuario

Apache
Php
Mysql
Send framework
Jquery
Dojo

deployment despliegue

TCP/IP

Sup.Comercial:
Usuario

TCP/IP

Router

http

http

TCP/IP

TCP/IP

Tecnico:Usuario

TCP/IP

Window s:Serv er

http

Administrador:
Usuario

Pers.Administ.:
Usuario

Router
http

4.3
DIAGRAMA DE DESPLIEGUE

Figura 5-39 Diagrama de Despliegue

90

Google Maps
API

4.4

MODELO RELACIONAL

Figura 5- 40 Modelo Relacional

91

4.5

DICCIONARIO DE DATOS.

A continuacin se especifica el diccionario de datos que pertenece al Modelo de datos del

sistema:
Tabla 5-22 Tabla Usuario

TABLA: usuario
N
CAMPO

TIPO

NUL
O

DESCRIPCION

idUsuario

INT

NO

Autonumrico

cuenta

VARCHAR(20) NO

Cuenta de usuario

password

VARCHAR(45) NO

Contrasea del usuario

salt

VARCHAR(45) NO

Cifrador auxiliar de la contrasea del usuario

nombre

VARCHAR(45) NO

Nombre del usuario

apellido_paterno VARCHAR(45) NO

Apellido paterno del usuario

apellido_matern
o
VARCHAR(45) NO

Apellido materno del usuario

ci

VARCHAR(8)

NO

Cedula de identidad del usuario

ci_expedido

VARCHAR(2)

NO

Lugar de expedido de la Cedula de identidad

10 rol

VARCHAR(20) NO

Rol del Usuario: Administrador, Gerente,

Superintendente, Supervisor, tcnico, personal
administrativo

11 activo

BOOLEAN

NO

Estado del usuario : activo o dado de baja

12 idCargo

INT

NO

id de cargo

13 idDepartamento

INT

NO

id del departamento al que pertenece

Tabla 5-23 Tabla departamento

TABLA:departamento
N
CAMPO

TIPO

NULO DESCRIPCION

idDepartamentos

INT

NO

Autonumrico

nombre

VARCHAR(20)

NO

Nombre del departamento

idSuperintendencia

INT

NO

id de la superintendencia
92

Tabla 5-24 Tabla cargo

TABLA:cargo
N CAMP
O
1

TIPO

idCargo INT

cargo

NUL
O

DESCRIPCION

NO

Autonumrico

VARCHAR(20) NO

Cargo del usuario: Superintendente,

Personal
Administrativo, Tcnico

Supervisor,

Tabla 5-25 Tabla Superintendencia

TABLA:superintendencia
N
CAMPO
1
2

TIPO

idSuperintendenci
a
INT
nombre

NUL
O

DESCRIPCION

NO

Autonumrico

VARCHAR(30) NO

Nombre de la superintendencia : Comercial,

Distribucin y Administracin

Tabla 5-26 Tabla ObservacionesCliente

TABLA:observacionesCliente
N
CAMPO

TIPO

NU
LO DESCRIPCION

descripcion

VARCHAR(255)

NO Descripcin resumida de la observacin realizada

estado

VARCHAR(45)

NO Estado de la observacin : Atendida o Pendiente.

nivel_atencio
n
VARCHAR(10)

Nivel de atencin de la observacin : Alto, Medio

NO y Bajo

Tipo_Obs

VARCHAR(20)

Tipo de observacin del cliente :Datos personales,

datos
NO tcnicos y Datos georeferenciados

idUsuario

INT

NO Id de usuario

idCliente

INT

NO id de cliente

93

urlImagen

VARCHAR(200)

fecha

DATE

SI

Direccin donde se encuentra la fotografa

correspondiente a la observacin realizada
Fecha en que se ingreso la observacin

Tabla 5-27 Tabla Cliente

TABLA:cliente
N
CAMPO

TIPO

NUL
O

DESCRIPCION

idCliente

INT

NO

Autonumrico

cod_cliente INT

NO

Cdigo del cliente especial

empresa

NO

Nombre de la empresa del cliente

idCategoria
s
INT

NO

id de la categora del cliente

estado

NO

Estado del cliente : activo o dado de baja

VARCHAR(45)

VARCHAR(15)

urlImagen

VARCHAR(200) SI

Direccin donde se encuentra la fotografa del

punto de suministro

direccion

VARCHAR(200) NO

Direccin del punto de medicin del cliente

Tabla 5-28 Tabla categorias

TABLA:categoras
N CAMPO

TIPO

NULO

DESCRIPCION

idCategorias

INT

NO

Autonumrico

nombre

VARCHAR(45)

NO

Categora :GD,PD,MD

Tabla 5-29 Tabla datostecnicos

TABLA:datostecnicos
N
CAMPO

TIPO

NULO DESCRIPCION

iddatosTecnico
s
INT

NO

Autonumrico

idCliente

INT

NO

id del cliente

PTS

BOOLEAN

NO

PTS del punto de suministro de energa

94

CTS

BOOLEAN

NO

CTS del punto de suministro de energa

multiplicador

INT

NO

Multiplicador del suministro de energa elctrica

Voltaje

INT

NO

Voltaje del suministro

ampct

INT

NO

Amperios de los CTS

NO

Capacidad del punto de suministro de energa

elctrica

capsmee

INT

propcts

VARCHAR(15) NO

Propiedad de los CTS (propiedad empresa o

cliente)

1
0

ptosum

VARCHAR(2)

NO

Punto de suministro: MT,BT

1
1

ptomed

VARCHAR(2)

NO

Punto de medicin: MT,BT

1
2

kw_pta

INT

NO

Potencia de punta

1
3

kw_fpta

INT

NO

Potencia fuera de punta

Tabla 5-30 Tabla Medidor

TABLA:medidor
N
CAMPO

TIPO

NUL
O

DESCRIPCION

idMedidor

INT

NO

Autonumrico

codigoMedidor

VARCHAR(3)

NO

cdigo del medidor del cliente

tipoMedidor

VARCHAR(15) NO

Tipo de medidor asignado al cliente

medidor

VARCHAR(15) NO

Numero de medidor del cliente

multiplicadorIntern
o
INT

SI

Multiplicador interno del medidor del

cliente

idCliente

NO

id del cliente

INT

Tabla 5-31 Tabla representantelegal

TABLA:representantelegal
95

N
CAMPO

TIPO

NUL
O
DESCRIPCION

ideRepresentantelega
1 l
INT

NO

Autonumrico

2 ci

NO

Cedula de identidad del representante legal

de la empresa

NO

Lugar de expedido de la Cedula de

identidad

3 ci_expedido

VARCHAR(8)
VARCHAR(2)

4 nombre

VARCHAR(45)

NO

Nombre del representante legal de la

empresa

5 apellido_paterno

VARCHAR(45)

NO

Apellido paterno del representante legal

6 apellido_materno

VARCHAR(45)

NO

Apellido materno del representante legal

7 idCliente

INT

NO

Id del cliente

Tabla 5-32 Tabla datosgeoreferenciados

TABLA:datosgeoreferenciados
N
CAMPO

TIPO

NULO DESCRIPCION

iddatosgeoreferenciad
os
INT

NO

Autonumrico

idCliente

NO

id del cliente

NO

Latitud en coordenadas geogrficas de

la
ubicacin
del
punto
de medicin del cliente

NO

Longitud en coordenadas geogrficas de

la ubicacin del punto de medicin del
cliente

6
7

latitud

longitud

urlImagen

altura
fecha

INT

DOUBLE

DOUBLE

VARCHAR(200) SI

Direccin donde se
fotografa
punto de suministro

DOUBLE

SI

Altura en coordenadas geogrficas de la

ubicacin del punto de medicin del
cliente

SI

Fecha en que se tomo los datos

georeferenciados

DATE

encuentra

la
del

96

observacion

VARCHAR(50)

SI

Observacin respecto
georeferenciados

los

datos

Tabla 5-33 Tabla ImagenesRuta

TABLA:imagenesRuta
N
CAMPO

TIPO

NUL
O

DESCRIPCION

INT

NO

Autonumrico

idImagenesRuta

urlImagen

latitud

longitud

VARCHAR(200) NO

Direccin donde se encuentran las

fotografas a considerar de la ruta que lleva
al punto de suministro de energa elctrica
del cliente

DOUBLE

SI

Latitud en coordenadas geogrficas de la

fotografa tomada de algn punto geogrfico
de la ruta hacia el punto de suministro de
energa elctrica del cliente

SI

Longitud en coordenadas geogrficas de la

fotografa tomada de algn punto geogrfico
de la ruta hacia el punto de suministro de
energa elctrica del cliente

DOUBLE

orden

INT

SI

Orden en que las fotos deben ser

consideradas para la trayectoria de la ruta.

idCliente

INT

NO

id del cliente

4.6

INTERFAZ DEL SISTEMA

A continuacin se presentan algunas interfaces del sistema por casos de uso

Caso de uso: Gestionar usuario

97

Figura 5-41 Interfaz gestionar Usuario

Figura 5-42 Interfaz gestionar Usuario: Registrar

98

Figura 5-43 Interfaz gestionar Usuario: Actualizar

Figura 5-44 Interfaz gestionar Usuario: Eliminar

99

Figura 5-45 Interfaz gestionar Usuario: Cambiar Contrasea

En esta interfaz el administrador del sistema podr registrar nuevos usuarios como por ejemplo
tcnicos de laboratorio o personal administrativo, y podr dar de baja a usuarios activos. Los
usuarios que no tengan el rol de administrador del sistema no podrn ingresar a las opciones
mencionadas pero si tendrn acceso a la opcin Cambiar Contrasea en la cual podrn realizar la
modificacin del password en el momento que as lo vena conveniente.
Caso de uso: Gestionar Cliente

Figura 5-46 Interfaz Gestionar Cliente:

100

Mediante esta interfaz los usuarios que tengan el rol de Administrador, Supervisor y tcnicos de
laboratorio podrn registrar nuevos usuarios en la base de datos como tambin podrn dar de baja
a usuarios activos, al mismo tiempo podrn ingresar la informacin tcnica de los puntos de
medicin de clientes especiales, y as mismo la informacin georeferenciada que se tomo en
terreno mediante un GPS.
Todos los usuarios tendrn acceso a la opcin observaciones en la cual podrn ingresar
Informacin relevante que se detecto en terreno con relacin a los aspectos tcnicos o geogrficos
del punto de suministro.
Caso de uso: Gestionar Datos Georeferenciados

Figura 5-47 Interfaz Gestionar Datos Georeferenciados

Mediante este interfaz el usuario de acuerdo al rol con el que ingreso al sistema puede realizar
bsquedas de clientes de acuerdo a la informacin ingresada en los campos solicitados, para as
poder registrar, actualizar o eliminar coordenadas georeferenciadas tomadas en campo mediante
un GPS. Tambin el usuario podr subir fotografas de acuerdo al caso, como ser: fotos del punto
de suministro, fotos de irregularidades tcnicas que se observaron en terreno e imgenes de
observaciones geogrficas del la ruta de acceso al punto de suministro.
101

CAPITULO VI
COSTO DEL SISTEMA

102

CAPITULO VI
5

5.1

COSTO DEL SISTEMA

ESTIMACIN DE COSTO DEL SOFTWARE

Existen muchas variables que deben tomarse en cuenta para la estimacin del costo y del esfuerzo
de la elaboracin del software como ser: aspectos tcnicos, de entorno e incluso aspectos
humanos. Sin embargo en el presente trabajo se aplica la metodologa de los puntos de casos de
uso que proporciona estimaciones con un grado de riesgo aceptable.
5.1.1

METODOLOGA DE PUNTOS DE CASOS DE USO (UCP).

La metodologa se la lleva a cabo mediante una secuencia de pasos a seguir, empezando por
ponderar los casos de uso sin ajustar, es decir que se toma en cuenta a los actores involucrados
(UAW) y los casos de uso (UUCW), posteriormente se evaluaran los factores tcnicos (TCF) y
ambientales (EF) que en su totalidad determinan los casos de uso ajustados y la obtencin del
nmero de horas/hombre para el desarrollo del proyecto.
5.1.2

FACTOR DE PESO DE LOS ACTORES INVOLUCRADOS.

De acuerdo a las caractersticas e interaccin de los actores involucrados en los casos de uso, se
clasifican en las siguientes categoras:( Ver anexo B)
Actor
Simple
Medio
Complejo

Peso o
Factor
1
2
3

103

Actor
Gerente General
Superintendente Comercial
Supervisor Medicin y Tarifas
Administrador
Personal Administrativo
Tcnico de laboratorio

Tipo De
Actor
Complejo
Complejo
Complejo
Complejo
Complejo
Complejo
TOTAL

Factor
3
3
3
3
3
3
18

Tabla 34: Clasificacin de actores en relacin a su peso o factor.

Formula:
UAW = ( cantiad de un tipo de ActorFactor ) .
UAW =18.
5.1.3

FACTOR DE PESO DE LOS CASOS DE USO SIN AJUSTAR (UAW)

Para determinar el nivel de complejidad se cuenta con dos mtodos:
o Basado en transacciones
o Basado en clases de anlisis

Tipo de caso de uso

Descripcin

Factor

Simple

Transacciones =3 o menos
Clases = Menos de 5

Medio

Transacciones =3 o menos
Clases = 5 a 10

10

Complejo

Ms de 7 transacciones
Clases= ms de 10 clases

15

104

Formula
UUCW = ( cantiad de un tipo de Caso de UsoFactor ) .

Tipo de Caso de Facto

Caso de uso
Uso
r
Autentificar usuario
Simple
5
Gestionar Usuario
Simple
5
Gestionar Cliente
Simple
5
Gestionar Datos tcnicos
Simple
5
Gestionar Datos Georeferenciados Simple
10
Integrar Mapa Georeferenciado
Simple
5
Generar Control
Simple
5
realizar Seguimiento
Simple
5
Genera Ruta Geogrfica
Simple
10
Generar reporte Georeferenciado Medio
10
Generar reporte
Medio
10
Generar Observaciones de campo Simple
5
TOTAL
80
UUCW =80.
5.1.4

PUNTOS DE CASIS DE USO SIN AJUSTAR (UUCP)

De acuerdo a la formula
UUCP=UUCW +UAW .

Se tiene:
UUCP=80+18.
UUCP=98.

5.1.5

EVALUAR LOS FACTORES DE COMPLEJIDAD TECNICA (TCF)

De acuerdo al peso correspondientes a los 13 puntos que evalan la complejidad del sistema y
segn la valoracin que se le asigne se determina el TCF .Ver anexo B

105

Factor

Descripcin

Peso

Influencia Resultado

T1
T2

Sistema Distribuido
Objetivos de rendimientos

2
2

2
5

4
10

T3

Eficiencia respecto al usuario final

T4
T5
T6
T7
T8
T9
T10

Procesamiento complejo
Cdigo reutilizable
Instalacin sencilla
Fcil utilizacin
Portabilidad
Fcil de cambiar
Uso concurrente

1
1
0,5
0,5
2
1
1

3
5
4
5
3
4
3

3
5
2
2,5
6
4
3

T11

Caractersticas de seguridad

T12

Accesible por terceros

T13

Se requiere formacin especial

Total

50,50

De acuerdo a la formula
TCF=0,6+ (0,01 ( T 1 T 13 ) ) .
Se tiene:
TCF=0,6+ ( 0,0150.50 ) .
TCF=1.11

5.1.6

EVALUAR FACTORES AMBIENTALES (EF)

Los factores sobres los cuales se realiza la evaluacin son 8 puntos, que estn relacionados con
las habilidades y experiencia de grupo de personas involucradas con el desarrollo del proyecto
(Ver anexo B).
Factor
E1

Descripcin
Familiar con AUP

Peso
1,5

Influencia
3

Resultado
4,5
106

E2

Experiencia en la aplicacin

0,5

0,5

E3

Experiencia orientado a objetos

E4
E5
E6

Capacidad de anlisis
Motivacin
Requisitos estables

0,5
1
2

4
5
3

2
5
6

E7

Trabajadores a tiempo real

-1

-1

E8

Dificultad del lenguaje de programacin

-1

-3

Total

17

De acuerdo a la frmula:
EF=1,4+ (0,03 ( E 1 E8 ) )
Se tiene:
EF=1,4+ (0,0317 )
EF=0.89

CALCULO DE PUNTOS DE CASOS DE USO AJUSTADOS (UCP)

De acuerdo a la formula
UCP=UUCPTCFEF
Se tiene:
UCP=981.110.89

UCP=96.81
CALCULO TOTAL DE HORAS ESTIMADAS-HOMBRE (E)
107

De acuerdo a la formula
E=UCPCF
Se tiene:
E=96.8120

E=1936.20

hrs
( hombre
)

ANALISIS DE RESULTADOS
Para la determinacin del esfuerzo total del proyecto se realiza un nuevo ajuste donde se
considera a todas las actividades relacionadas con el desarrollo del sistema, ponderadas de la
siguiente manera:
-

10 % Anlisis
20 % Diseo
40 % Programacin
15 % Pruebas
15 % Sobrecarga

Aplicando las ponderaciones al total de horas estimadas hombre (E) se tiene los siguientes
resultados:
Actividad
Anlisis
Diseo
Programaci
n
Pruebas
Sobrecarga

Horas Estimadas
(E)
1936,20
1936,20

Porcentaje
E*%
Resultado
%
10%
1936,20*0,10
193,62
20%
1936,20*0,20
387,24

1936,20

40%

1936,20*0,40

774,48

1936,20
1936,20

15%
15%
100%

1936,20*0,15
1936,20*0,15

290,43
290,43
1936,20

108

COSTO

ESTIMADO

DE

EL

SISTEMA

DE

INFORMACION

WEB

GEOREFERENCIADO
Considerando que una persona trabaja 8 horas/da y 24 das/mes de acuerdo a la ley general del
trabajo y considerando un salario de 4800 Bs/mes se tiene la siguiente relacin:
Dnde:

THT= Tarifa Horaria por Trabajo.

Bs
( Mes
)

THT =4800.

hrs
1 dia
hombre
1 mes
8 hrs
THE=1936.20
24 dia

THE=10.084

mes
( hombre
)

Por lo tanto nuestro proyecto ser:

SW =THE( THT )
SW =10.0844800
SW =48403.20

bs
( hombre
)

Equivalente en moneda extranjera (dlares).

SW =48403.20/6.96

SW =6954.50

$ us
( hombre
)

109

CAPITULO VI
PRUEBAS DEL SISTEMA

110

CAPITULO VII
6
6.1

PRUEBAS DEL SISTEMA

GENERALIDADES

En el presente captulo se desarrolla el mtodo Delphi a travs de preguntas a expertos para la

evaluacin de la idea a defender, posterior a ello se realiz pruebas de funcionalidad del sistema
mediante pruebas de caja negra.
6.2

METODO DELPHI- PREGUNTA A EXPERTOS

Mediante el mtodo Delphi se evala la idea defender del proyecto aplicando las tres fases
siguientes: 4

6.2.1

Fase de Preparacin
Fase de Consulta
Fase de Consenso
FASE DE PREPARACION

- Seleccin de expertos: Para la seleccin de las personas que colaboraran en el desarrollo del
mtodo Delphi, se realiz un cuestionario que permite discernir a los expertos que estarn
involucrados en todas las fases ya mencionadas, obteniendo los siguientes resultados:
Ver anexo A1

Expertos
1
2
3
4
5
6
7

Valoracin
ALTO
MEDIO
MEDIO
ALTO
MEDIO
MEDIO
MEDIO

Seleccionado
SI
NO
NO
SI
NO
NO
NO

4 Libro o la direccin de internet

111

8
9
10
11
12
13
14
15
16
17

ALTO
ALTO
MEDIO
ALTO
ALTO
MEDIO
MEDIO
ALTO
MEDIO
ALTO

SI
SI
NO
SI
SI
NO
NO
SI
NO
SI

Tabla COMPLETAR
De acuerdo a la tabla anterior se considera 8 expertos para el desarrollo de las siguientes fases.
- Preparacin del instrumento: Se dise un cuestionario de preguntas con respuestas
dicotmicas para la valoracin de los criterios de los expertos en su primera instancia. Ver anexo
- Decisin de la va de consulta.- Los cuestionarios se entregaran de manera directa en papel
impreso ya que las condiciones fsicas as lo permiten.
6.2.2

FASE DE CONSULTA

- Realizacin de las rondas de consulta.- En primera instancia se entreg el cuestionario 1 (ver

anexo) a nuestro grupo de expertos que colaboran con el proyecto pero previamente se les
presento la documentacin y en algunos casos de manera verbal, las pautas del proyecto.

Primera ronda.- Los resultados del primera encuesta son:

N
Pregunta
1
2
3
4
5
6
7
TOTAL

OPCION
SI
NO
5
3
4
4
6
2
3
5
6
2
5
3
4
4
33
23
112

Anlisis estadstico
De acuerdo a la tabla anterior se tiene un promedio igual a 5, correspondiente a las respuestas
afirmativas que realizaron los expertos, al mismo tiempo se determina la moda igual a 6 que
corresponde a las preguntas 3 y 5 siendo una distribucin bimodal.(Ver Anexo A2 NO)
Estos resultados permiten realizar las modificaciones del cuestionario en su versin 2 para la
segunda ronda.

Segunda ronda
En funcin a los resultados de la primera ronda, se elabor el segundo cuestionario (Ver
Anexo) con las modificaciones pertinentes y se obtuvo los siguientes resultados:
N
Pregunta
1
3
5
6
TOTAL

SI
8
5
7
6
26

OPCION
NO
0
3
1
2
6

Anlisis estadstico
De acuerdo a la tabla anterior se tiene un promedio igual a 7, correspondiente a las respuestas
afirmativas que realizaron los expertos, al mismo tiempo se determina la moda igual a 8 que
corresponde a las preguntas 1 (Ver Anexo).
6.2.3

FASE DE CONSENSO

Construccin del consenso

De acuerdo a los resultados obtenidos en ambas rondas, se puede observar que el nmero de
respuestas afirmativas se incrementa de un 59 % a un 81 % de la primera ronda a las segunda,
siendo este indicador muy valioso en el estudio por tener una variacin del 22 %, al mismo
tiempo se observa que la moda Mo en la segunda ronda correspondiente a la pregunta uno, es

considerada de mayor preferencia para los encuestados. (Anexo A1)

Reporte de resultados
Considerando los aspectos mencionados previamente, se concluye que el mtodo Delphi
reporta la existencia de un acuerdo general grupal, el cual est orientado a la implementacin
113

de un sistema de informacin de acuerdo anlisis estadstico que se valor en ambas rondas.

Por tanto la idea a defender presenta amplia viabilidad de aceptacin.
SEGURIDAD DE SISTEMA
La aplicacin web en su primera instancia de la pantalla principal solicita la auto identificacin
del usuario que pretende ingresar al sistema a travs de una cuenta de usuario y contrasea de
acuerdo al rol del mismo, misma identificacin es constantemente comprobada en los diferentes
mdulos a las cuales el usuario quiere ingresar y de acuerdo a los permisos con los que cuenta
podr navegar en el mdulo deseado o caso contrario se le negara el ingreso.
PRUEBAS DE CAJA NEGRA
Mediante la prueba de caja Negra se evala las entradas que recibe y las salidas o respuestas que
produce el sistema en sus diferentes mdulos sin tomar en cuenta su funcionamiento interno. Es
decir que nos interesa la forma que interacta con el medio ambiente que le rodea a travs de sus
interfaces.
PRUEBA 1: INICIAR SESION

Figura Iniciar sesin Prueba 1

114

CONDICION
DE ENTRADA
CLASES VALIDAS
Cuenta
1: 0..9, a..z, A..Z
Password
1: 0..9, a..z, A..Z

CLASES INVALIDAS
2:otro
2:otro

Evaluacin de clases equivalentes

CLASE DE
EQUIVALEN
CIA
CUENTA

N DE
CASO
1
2

PASSWOR
D

1 Wmontano elfeo2015
2 Wmont
elfeo

RESULTADO
El usuario de acuerdo al rol tiene acceso a
las opciones del men principal.
Acceso denegado

Resultado esperado
El usuario ingresa al sistema si las clases son vlidas tal como se muestra en la figura
Caso contrario el sistema permanece en la pantalla principal.

Figura Resultado Iniciar sesin Prueba 1

PRUEBA 2: NUEVO CLIENTE

115

Figura Nuevo Cliente Prueba 2

CONDICION
DE ENTRADA
Codigo Cliente
NIT
Empresa

categoria
Estado
Imagen del punto de
suminsitro
Fecha de ingreso
Direccin
Nombre
Ap_Paterno
Ap_Materno
C.I.

CLASES VALIDAS
1: 0..9
1: 0..9
1: 0..9, a..z, A..Z

CLASES INVALIDAS
2:Ingreso de letras, otros
2:Ingreso de letras, otros
2:otro.

* BT
* MT
* AT
*Activo
*Baja

2:Ninguna

1: 0..9, a..z, A..Z,:,\

1: 0..9,1: 0..9, a..z, A..Z
1: a..z, A..Z
1: a..z, A..Z
1: a..z, A..Z
1: 0..9

2:otro
2:otro,vacio
2:otro.
2:Ingreso de nmeros, otros
2:Ingreso de nmeros, otros
2:Ingreso de nmeros, otros
2:Ingreso de letras, otros

2:Ninguna

116

* Beni
* Cochabamba
* Chuquisaca
* La Paz
* Oruro
* Pando
* Potos
* Santa Cruz
* Tarija

Exp.

CASO
Codigo
Cliente
NIT
Empresa
categoria
Estado
Imagen del
punto
de suministro
Fecha de
ingreso
Direccin
Nombre
Ap_Paterno
Ap_Materno
C.I:
Exp.
RESULTAD
O

2:Ninguna

CLASE DE EQUIVALENCIA
1
201
1321453
ENTEL S.A.
MT
Activo

2
201XXXX
1321453

ENTEL S.A.
MT
Activo

C:\xampp\htdocs\GELFEO_FINAL\
C:\xampp\htdocs\GELFEO_FINAL\
public\imagenes\imagenesCliente\2134 public\imagenes\imagenesCliente\2134.
.jpg
jpg
2015-03-05 2015-03-XX
Negro Pabellon
Negro Pabellon
JUAN
JUAN
ALVARES
ALVARES
FLORES
FLORES
4561237
4561237
La Paz
La Paz
La informacin no se almacena y el
formulario reporta los mensajes
Datos almacenados correctamente.
correspondientes.

117

118

CAPITULO VI
CONCLUSIONES Y RECOMENDACIONES

119

CAPITULO VI
7
7.1

CONCLUSIONES Y RECOMENDACIONES

CONCLUSIONES

Del objetivo generalxcgfsdgfdgdfg se logr..y como se logro

o se cumpli o como se cumpli
Implementar un sistema de informacin georeferenciado para integrar la informacin de
servicios de energa de clientes especiales para coadyuvar las actividades tcnicas en el
departamento de Medicin-Tarifas de ELFEO S.A.
OBJETIVOS ESPECFICOS
-

Definir el modelo de casos de uso a fin de estructurar el sistema de informacin de

manera integrada.
Disear el modelo del sistema de informacin para obtener una arquitectura estable y
slida, que permita un manejo eficiente de la informacin.

De acuerdo a los objetivos especficos planteados en el presente proyecto, para su cumplimiento

se realizo lo siguiente:
Para el objetivo Examinar la documentacin y procedimientos del departamento de Medicin tarifas para definir el modelo del negocio y determinar los requerimientos del sistema, se realizo
. A travs de..

La aplicacin de mtodos y herramientas para el desarrollo del sistema en la fase de inicio

respecto a la determinacin de requerimientos, permitieron identificar las necesidades
fundamentales del departamento de medicin- tarifas y otros dependientes de la
superintendencia Comercial de la Empresa de Luz y Fuerza de Oruro para el desarrollo de
la aplicacin.

La identificacin de los casos de uso del sistema permiti estructurar consecutivamente

cada fase del proyecto recopilando los artefactos obtenidos en cada captulo.
120

El diseo y construccin de la base de datos se la realizo mediante el modelo relacional,

lo que permiti sistematizar la informacin de los procesos identificados en el campo de
estudio.

La implementacin del prototipo del sistema de informacin georeferenciado en entorno

web permite apreciar la automatizacin de los procesos del sistema de acuerdo a los casos
de uso identificados.

De acuerdo al objetivo General planteado, para su cumplimiento se realiz lo siguiente:

7.2

Se desarroll un sistema de informacin web georeferenciado para el departamento de

Medicin y tarifas de la Empresa de Luz y fuerza de Oruro S.A., logrando integrar mapas
satelitales georeferenciados e informacin tcnica correspondiente a clientes especiales
para coadyuvar a las actividades que el personal del departamento realiza peridicamente.

RECOMENDACIONES

Del objetivo generalxcgfsdgfdgdfg se logr..y como se logro

o se cumpli o como se cumpli
Conclusiones del objetivo general
Para la conclusin del objetivo general, se recomiendo considerar .. tambin el clculos
costos ..
Para los objetivos especficos

A la conclusin de objetivo breve hablas del objetivo, se comiendo utilizar la ingeniera de

requerimientos por .

El presente proyecto es una lnea base para el mejoramiento de la administracin de

clientes que cuentan con el servicio de energa elctrica en sus distintas categoras y
ubicaciones geogrficas de la ciudad de Oruro.

121

BILIOGRAFIA

122

REFERENCIAS BIBLIOGRAFICAS
Pressman R.(1998) Ingeniera del software, Un enfoque prctico,6ta edicin, Espaa,
Ed.McGraw-Hill.
Jacobson I, Booch G., Rumbaugh (2000) El proceso Unificado de Desarrollo de Software,
Madrid, Addison Wesley.

ORDEN ALFABETICO

En Internet
Msc Margarita Garcia, Universidad de Ciencias de la Habana [Febrero 2015], El Metodo Delphi
para la consulta a expertos en la investigacin cientfica, Disponible en
http://bvs.sld.cu/revistas/spu/vol39_2_13/spu07213.htm
REVISTA Libro o la direccin de internet

http://es.wikipedia.org/wiki/Puntos_de_caso_de_uso

123

ANEXOS

124

ANEXO A
INTERFACES DEL SISTEMA
GESTIONAR USUARIO

Este interfaz permite ingresar un nuevo usuario o buscar usuarios que se encuentran en la base de
datos y as poder realizar operaciones tales como actualizar sus datos, borrar un registro o
cambiar la contrasea del mismo.
EDITAR USUARIO

125

Es esta opcin el administrador realizara los cambios necesarios para actualizar la informacin de
un registro.

BORRAR USUARIO

Esta pantalla nos muestra la informacin del usuario antes de ser borrado de la base de datos.

CAMBIAR CONTRASEA
126

En este interfaz los usuarios podrn cambiar sus contraseas cuando lo vena conveniente, en caso
de que no recuerden su contrasea anterior pues debern coordinar con el administrador del
sistema.

CREAR NUEVA SUPERINTENDENCIA

A travs de esta pantalla el usuario tiene la opcin de ingresar nuevas superintendencias.

LISTAR SUPERTINTENDENCIAS
127

Esta pantalla permite editar o borrar las superintendencias con las que cuenta la empresa
ELFEOSA.

GESTIONAR CLIENTE

Esta pantalla permite ingresar un nuevo cliente o buscar clientes que se encuentran en la base de
datos y as poder elegir las opciones de actualizar, eliminar un registro ingresar Datos tcnicos,
128

registrar sus coordenadas georeferenciadas y observaciones que se requieran para su tratamiento

y control del mismo
NUEVO CLIENTE

Este interfaz permite que el usuario pueda ingresar la informacin tcnica del punto de suministro
de acuerdo a las caractersticas presentadas en la firma de contrato.

COORDENADAS GEOREFERENCIADAS

129

Mediante esta pantalla el tcnico puede ingresar las coordenadas georeferenciadas que se
tomaron del punto de suministro en terreno a travs de un GPS, al mismo tiempo se puede
adicionar la fotografa del mismo.

OBSERVACIONES CLIENTE

A travs de esta pantalla el usuario puede ingresar las observaciones realizadas en campo o en
escritorio.

ANEXO B

Peso de los factores sin ajustar (UAW)

Actor

Descripcin

Peso o Factor

130

Otro sistema que interacta con el sistema a

Simple

desarrollar a travs de una interfaz de una

programacin definida y conocida con un API

definido
Otro sistema interactuando mediante un protocolo o
Medio

una persona interactuando a travs de una interfaz

en modo texto (p.e.: TCP/IP, HTTP, FTP).

Una persona que interacta con el sistema por
Complejo

medio de una interfaz grfica de usuario (GUI) o

pgina Web.

Factores de complejidad Tcnica.

Factor

Descripcin

Peso

Influencia Resultado

T1

Sistema Distribuido

n1

2*n1

T2

Objetivos de
rendimientos

n2

2*n2

T3

Eficiencia respecto al
1
usuario final

n3

1*n3

T4

Procesamiento complejo 1

n4

1*n4

T5

Cdigo reutilizable

n5

1*n5

T6

Instalacin sencilla

0,5

n6

0,5*n6

T7

Fcil utilizacin

0,5

n7

0,5*n7

T8

Portabilidad

n8

2*n8

T9

Fcil de cambiar

n9

1*n9

131

T10

Uso concurrente

n10

1*n10

T11

Caractersticas
seguridad

n11

1*n11

T12

Accesible por terceros

n12

1*n12

T13

Se requiere formacin
1
especial

n13

1*n13

de

Escala de los factores de complejidad tcnica

Descripcin
Irrelevante
Medio
esencial

valor (Fi)
De 0 a 2
De 3 a 4
5

Pesos de los factores ambientales

Factor Descripcin
E1
Familiar con AUP

Peso Influencia Resultado

1,5 n1
1,5 * n1

E2

Experiencia en la aplicacin

0,5

n2

0,5 * n2

E3

Experiencia orientado a objetos

n3

1 * n3

E4
E5
E6

Capacidad de anlisis
Motivacin
Requisitos estables

0,5
1
2

n4
n5
n6

0,5 * n4
1 * n5
2 * n6

E7

Trabajadores a tiempo real

-1

n7

E8

Dificultad
del
programacin

-1

n8

lenguaje

de

Escala de estimacin de los factores ambientales

Descripcin
Sin experiencia, sin motivacin,
estabilidad
Promedio
Amplia experiencia, motivacin,
estabilidad

valor (Fi)
De 0 a 2
3
De 4 a 5
132

ANEXO B

CUESTIONARIO
CUESTIONARIO DIRIGIDO AL PERSONAL DE ELFEO S.A.
METODO DELPHI
NOMBRE COMPLETO: ___________________________________
___________
DEPARTAMENTO: ______________________________________

EDAD:
CARGO:

Encierre en un crculo su repuesta.

1) Cuenta con una antigedad mayor o igual a 5 aos en el puesto que
desempea sus funciones?
SI
NO
2) Realizo algn estudio universitario a nivel licenciatura?
SI
NO
3) Cuenta con algn grado acadmico a nivel tcnico?
SI
NO
4) Estuvo en cargos similares pertenecientes a otras instituciones?
SI
NO
5) Usted se capacita por cuenta propia en temas relacionados a su rea?
SI
NO
6) Participo en las capacitaciones que la empresa otorgo recientemente?
SI
NO
GRACIAS POR SU COLABORACIN

Factores de valoracin para los encuestados

Descripci
n

valor

ALTO

MEDIO

Tabla de valoracin para la seleccin de expertos mtodo Delphi.

133

1
2
3
4
5
6

PREGUNTA
Cuenta con una antigedad mayor o igual a 5 aos en el
puesto que desempea sus funciones?
Realizo algn estudio universitario a nivel licenciatura?
Cuenta con algn grado acadmico a nivel tcnico?
Estuvo en cargos similares pertenecientes a otras
instituciones?
Usted se capacita por cuenta propia en temas
relacionados a su rea?
Participo en las capacitaciones que la empresa otorgo
recientemente?
TOTAL PUNTOS

VALO
R
2
2
1
2
1
2
10

134

CUESTIONARIO N 1
Implementar un sistema de informacin georeferenciado para integrar la informacin de
servicios de energa de clientes especiales para coadyuvar las actividades tcnicas en el
departamento de Medicin-Tarifas de ELFEO S.A.

CUESTIONARIO DIRIGIDO AL PERSONAL DE ELFEO S.A.

METODO DELPHI

Encierre en un crculo su repuesta.

1) La implementacin del sistema de informacin en entorno web, mejora
las actividades tcnicas del departamento de Medicin y tarifas?
SI
NO
2) Se disminuirn en los siguientes periodos con los reportes
georeferenciados, las lecturas no realizadas correspondientes a los
servicios de clientes especiales del rea rural por la no ubicacin del punto
de suministro del mismo
SI
NO
3) A travs de los mapas geogrficos que reporta el sistema, el personal
administrativo no tendr dificultades en llegar al lugar exacto donde se
encuentra el punto de medicin del cliente.
SI
NO
135

4) Al momento de realizar el trabajo de campo, los tcnicos que realizarn la

instalacin de nuevos recogern las coordenadas georreferenciadas del
punto geogrfico a travs de un GPS.
SI
NO
5) La referencias Geogrficas que el sistema proporciona, permiten llegar al
punto de medicin del servicio, sin solicitar mayor informacin al cliente
SI
NO
6) El encargado de lecturas de fin de mes podr identificar las rutas de los
servicios dados de baja antes de emprender el viaje al rea rural y as
omitir las mismas evitando gastos operativos a la empresa.
SI
NO
7) Los usuarios ingresaran al sistema para recabar informacin tcnica de
algn cliente en particular desde sus propias computadoras personales
SI
NO

GRACIAS POR SU COLABORACIN

136

Calculo del promedio:

promedio=

( P 1+ P 2+ P 3+ P 4 + P 5+ P 6+ P7)
N

promedio=

(5+ 4+ 6+3+6+ 5+4)

7

promedio=4.71 5

Determinacin de la moda (Mo):

N Pregunta
Fi

1
5

2
4

3
6

4
3

5
6

6
5

7
4

OPCION
7
6
5
4
3
2
1
0

OPCION SI

De acuerdo a la grfica se puede observar que es una distribucin Bimodal por tener dos
preguntas con la misma frecuencia.

137

Segunda ronda.- para el diseo del cuestionario nmero 2, se eliminaron las preguntas que tienen
una frecuencia menor que el promedio del cuestionario 1, obteniendo como resultado el siguiente
cuestionario:

CUESTIONARIO N 2
CUESTIONARIO DIRIGIDO AL PERSONAL DE ELFEO S.A.
METODO DELPHI

Resultados CUESTIONARIO 1
Se tiene un promedio = 5 y la moda = 6, para el presente cuestionario no se
tomaron en cuenta las preguntas que estn por debajo del promedio.
Tabla resumen de resultado
N Pregunta
OPCION

1
SI
NO

2
5
3

3
4
4

4
6
2

5
3
5

6
6
2

7
5
3

Total
4
4

33
23

Se pide que revale sus respuestas de acuerdo a los resultados

preliminares o mantener su respuesta segn lo considere.

Encierre en un crculo su repuesta.

1) La implementacin del sistema de informacin

en entorno web,

mejora las actividades tcnicas del departamento de Medicin y

tarifas?
SI
NO
3) A travs de los mapas geogrficos que reporta el sistema, el personal
administrativo no tendr dificultades en llegar al lugar exacto donde se
encuentra el punto de medicin del cliente.
SI
NO

138

5) La referencias Geograficas que el sistema proporciona, permiten llegar

al punto de medicin del servicio, sin solicitar mayor informacin al
cliente
SI
NO
6) El encargado de lecturas de fin de mes podr identificar las rutas de los
servicios dados de baja antes de emprender el viaje al rea rural y as
omitir las mismas evitando gastos operativos a la empresa.
SI
NO

GRACIAS POR SU COLABORACIN

139

Calculo del promedio:

promedio=

(P 1+ P 3+ P5+ P 6)
N

promedio=

(8+5+7+6)
4

promedio=6.5 7

Determinacin de la moda (Mo):

N Pregunta
Fi

1
8

3
6

5
6

6
5

OPCION
9
8
7
6
5
4
3
2
1
0

OPCION SI

De acuerdo a la grfica se puede observar la Moda es igual al nmero de expertos encuestados.

140