UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIA PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO
SISTEMA DE INFORMACION GEOGRAFICA DEL
MUNICIPIO DE HUATAJATA
Caso: Alcaldía de Huatajata

Postulante: MARCOS FERNÁNDEZ FLORES

Tutor: LIC. GROVER RODRIGUEZ

Revisor: LIC. RAMIRO FLORES ROJAS

La Paz – Bolivia

2014
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

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

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

LICENCIA DE USO

El usuario está autorizado a:

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

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

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

material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

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

A toda mi familia por la paciencia

que me tuvieron y en los momentos más difíciles
de la vida siempre estuvieron a mi lado.
 Agradecimientos

A mi docente Lic. Grover Alex Rodriguez Ramirez por su

comprensión y paciencia la fase de desarrollo.
A mi Docente Lic. Ramiro Flores Rojas por su apoyo
solidario y tiempo dedicado a mi persona.
A mis amigos que siempre me brindaron su apoyo
incondicional.
 RESUMEN

Actualmente el manejo de la información se ha vuelto muy importante en la vida de

todas las instituciones puesto un buen manejo de la misma define el crecimiento de la
entidad.

En este sentido la implementación de sistemas de información geográfico abre un

nuevo modelo para el área tecnológica, debido a que es una herramienta que nos posibilita
referenciar, organizar y analizar datos geográficos.

Por tal motivo se plantea el desarrollo e implementación de un Sistema Geográfico

para el Municipio de Huatajata más específicamente para la Dirección de Planificación
Desarrollo Urbano, Proyectos y Turismo.

Para el desarrollo del presente trabajo se utilizó metodología OOHDM (Método de

Diseño Hipermedia Orientado a Objetos) que propone el desarrollo de sistemas basados en la
Web como una técnica ideal para lograr nuestro objetivo.

En la implementación se utilizaron las herramientas de código abierto como ser el

lenguaje Php 5.2.1, Base de Datos PostgreSQL, Apache, Mapserver, JavaScript, Arc View.

El Sistema de Información Geográfica de Huatajata cumple con el propósito de

manejar proyectos y geo referenciarlos en mapas posibilitando de esta manera a los usuarios
la visualización, consulta de todos los proyectos en ejecución o ejecutados, transmitir
información confiable de la ubicación de las mismas.

También podemos mencionar que la aplicación proporcionara información sobre las

noticias de interés a la comunidad y poder realizar denuncias sobre actos de corrupción que
puedan suceder dentro la institución.
 INDICE

CAPITULO 1 .................................................................................................. 1
MARCO CONCEPTUAL .............................................................................. 1
1.1 INTRODUCCIÓN ........................................................................................ 1
1.2 ANTECEDENTES ....................................................................................... 2
1.2.1 De la Institución ............................................................................... 2
1.2.2 Descripción del Sistema Actual ............................................................................. 2
1.2.3 Antecedentes del proyecto ...................................................................................... 3
1.3 PLANTEAMIENTO DEL PROBLEMA ...................................................................... 4
1.3.1 Diagnóstico del Problema ...................................................................................... 4
1.3.2 Formulación del Problema ..................................................................................... 4
1.3.3 Objetivos ................................................................................................................ 5
1.3.3.1 Objetivo General ................................................................................................... 5
1.3.3.2 Objetivos Específicos ............................................................................................ 5
1.4 ALCANCES Y LIMITES ............................................................................................... 5
1.4.1 Alcances ................................................................................................................. 5
1.4.2 Limites .................................................................................................................... 6
1.5 APORTES ........................................................................................................................ 6
1.6 JUSTIFICACION ........................................................................................................... 7
1.6.1 Social ...................................................................................................................... 7
1.6.2 Técnica ................................................................................................................... 7
1.6.3 Calidad de Software ............................................................................................... 8
1.6.4 Económica .............................................................................................................. 8
1.6.5 Metodología............................................................................................................ 8
1.7 DIAGRAMA DE GANTT ............................................................................................... 8
CAPITULO 2 ................................................................................................ 10
MARCO TEORICO ..................................................................................... 10
2.1 MARCO INSTITUCIONAL ....................................................................... 10
2.2 SISTEMAS DE INFORMACION GEOGRAFICO ........................................ 12
2.2.1 DEFINICIÓN ............................................................................................................. 13
2.2.2 Componentes de un SIG ......................................................................................... 13
2.2.2.1 Hardware ................................................................................................... 14
2.2.2.2 Software..................................................................................................... 14
2.2.2.3 Datos .......................................................................................................... 15
2.2.2.4 Recursos Humanos .................................................................................... 15
2.3 TIPOS DE SIG .............................................................................................................. 15
2.4 SOFTWARE LIBRE .................................................................................................... 17
2.5 SISTEMAS DE GESTION DE BASE DE DATOS .................................................... 19
2.5.1 Base de datos orientada a objetos ......................................................................... 19
2.5.2 Base de Datos Espaciales ..................................................................................... 19
2.6 OOHDM - OBJECT - ORIENTED HYPERMEDIA DESIGN METHOD ............ 20
2.6.2 Fases de OOHDM .................................................................................................. 22
2.6.3.- VENTAJAS Y DESVENTAJAS DE OOHDM .................................................. 32
2.7 HERRAMIENTAS DE DESARROLLO ................................................................... 33
2.7.1 PostgreSQL10 ......................................................................................................... 33
2.7.2 PHP ........................................................................................................................ 34
2.7.3 Apache Tomcat...................................................................................................... 35
2.7.4 Arc View 10 .......................................................................................................... 35
2.8 EVALUACION DE LA CALIDAD DE SISTEMA ................................................... 38
2.8.1 La planificación y programación de la evaluación ................................................. 38
2.8.2 Fase de definición y especificación de requerimientos de calidad ......................... 38
2.8.3 Fase de Definición e Implementación de la Evaluación Elemental ..................... 42
2.8.4 Representación Notacional de los Criterios ........................................................... 43
2.8.5 Tipos de Criterios de Preferencia de Calidad Elemental ........................................ 44
2.8.6 Fase de Evaluación Global ..................................................................................... 45
 2.8.7 El Modelo de Agregación Lógica de Preferencias. ................................................ 46
2.8.8 Análisis de Resultado, Conclusiones y Documentación ........................................ 47
CAPITULO 3 ................................................................................................ 55
MARCO APLICATIVO .............................................................................. 55
3.1 INTRODUCCION.......................................................................................................... 55
3.2. SISTEMA ACTUAL ...................................................................................................... 55
3.3. ESPECIFICACION DE REQUERIMIENTOS .......................................................... 56
3.4 ESPECIFICACION DE ACTORES Y TAREAS ........................................................ 56
3.5 DIAGRAMA PRINCIPAL DE CASO DE USO .......................................................... 57
3.5.1 Descripción de Sub Casos de Uso .......................................................................... 59
3.6 ESPECIFICACION DE UID´S ..................................................................................... 68
3.7 DISEÑO CONCEPTUAL ............................................................................................. 72
3.7.1 Diagrama de Clases ................................................................................................ 72
3.8 DISEÑO NAVEGACIONAL ......................................................................................... 73
3.8.1 Clases Navegacionales Básicas .............................................................................. 73
3.8.2 Esquema de clases navegacionales......................................................................... 75
3.8.3 Esquema de clase navegacional para usuario casual .............................................. 77
3.8.4 Esquema de clase navegacional para usuario editor .............................................. 77
3.8.5 Esquema de clase navegacional para usuario administrador .................................. 78
3.9 ESQUEMA DE CONTEXTO NAVEGACIONAL ...................................................... 79
3.9.1 Diagrama de contexto ............................................................................................. 79
3.10 DISEÑO DE LA INTERFAZ ABSTRACTA .............................................................. 81
3.10.1 Diseño de ADV de la pantalla principal vía Web ............................................... 82
3.10.2 Diseño de ADV Administrador ............................................................................ 82
3.11 IMPLEMENTACION .................................................................................................. 85
3.11.1 Pantallas................................................................................................................ 85
3.12 PRUEBAS ..................................................................................................................... 90
3.12.1 Prueba de caja blanca .......................................................................................... 90
CAPITULO 4 ................................................................................................ 96
METRICAS DE CALIDAD ......................................................................... 96
4.1 CALIDAD DE SOFTWARE ............................................................................. 96
4.3 ANÁLISIS DE COSTOS/BENEFICIO ................................................................ 99
4.3.1 ANÁLISIS DE COSTOS ................................................................................................ 99
4.3.2 ANÁLISIS DE BENEFICIOS......................................................................................... 103
4.3.2.1 valor neto actual ...................................................................................... 104
4.3.2.2 Tasa interno de retorno ............................................................................. 105
CAPITULO 5 .............................................................................................. 106
SEGURIDAD DEL SISTEMA................................................................... 106
5.1 SEGURIDAD DE INGRESO AL SISTEMA ................................................ 106

5.2 SEGURIDAD DEL SISTEMA OPERATIVO ............................................... 106

5.3 POLÍTICA SOBRE COPIAS DE RESPALDO (BACK CUP) ......................... 106

5.4 POLÍTICA SOBRE SEGURIDAD FÍSICA .................................................. 107

5.5 PLAN DE CONTINGENCIAS .................................................................... 107

5.6 FACTOR Y ANÁLISIS DE RIESGO .......................................................... 107

CAPITULO 6 .............................................................................................. 110

CONCLUSIONES Y RECOMENDACIONES......................................... 110
6.1 CONCLUSIONES ....................................................................................................... 110
6.2 RECOMENDACIONES ............................................................................................. 110
BIBLIOGRAFÍA ............................................................................................. 111
 ÍNDICE DE TABLAS

Tabla 1 Fase de Diseño Conceptual de OOHDM 35

Tabla 2 Fase de diseño navegacional de OOHDM 41
Tabla 3 Fase de diseño de interfaz abstracto de OOHDM 44
Tabla 4 Fase de implementación de OOHDM 44
Tabla 5 Árbol de requerimientos de calidad 55
Tabla 6 Modelo Constructivo de Costes 62
Tabla 7 Valores del modelo COCOMO II 64
Tabla 8 Valores de calibrado del modelo COCOMO II 64
Tabla 9 Sub caso de uso administrar usuarios 72
Tabla 10 Sub caso de uso registrar usuarios 73
Tabla 11 Sub caso de uso modificar usuarios 73
Tabla 12 Sub caso de uso modificar usuarios 74
Tabla 13 Sub caso de uso adiciona proyecto 75
Tabla 14 sub caso de uso modifica proyecto 75
Tabla 15 Sub caso de uso elimina proyecto 76
Tabla 16 Sub caso de uso adición de mapa 77
Tabla 17 Sub caso de uso busca mapa 77
Tabla 18 Sub caso de uso visualiza mapa 78
Tabla 19 Sub caso de uso adiciona noticia 79
Tabla 20 Sub caso de uso modifica noticia 79
Tabla 21 Sub caso de uso elimina mapa 80
Tabla 22 Sub caso de uso lee noticia 80
Tabla 23 Computo de las preferencias globales 111
Tabla 24 Cálculo de puntos Función no ajustados 112
Tabla 25 Determinación de complejidad 113
Tabla 26 Coeficientes ab bb y los exponentes cb y db 114
Tabla 27 Costo del software 115
Tabla 28 Costo de elaboración del proyecto 116
Tabla 29 Costo total de elaboración del proyecto 116
Tabla 30 Evaluación de riesgos 121
Tabla 31 Evaluación de riesgos 122
ÍNDICE DE FIGURAS

Figura 1 Diagrama de Gantt 22

Figura 2 Organigrama del Municipio de Huatajata 24
Figura 3 Componentes de un SIG 27
Figura 4 Definición de la clase enlace 24
Figura 5 Diagrama de clases navegacionales 38
Figura 6 Ejemplo de descripción de clases navegacionales 38
Figura 7 Ejemplo de Contexto Navegacional 40
Figura 8 Ejemplo de ADV 2.5 Ingeniería WEB 43
Figura 9 Ejemplo de diagrama de configuración 43
Figura 10 Principales módulos en el proceso evaluación y comparación
usando web-site QEM 52
Figura 11 Taxonomía de tipos criterios elementales 57

Figura 12 Esquema que representa la obtención de la Calidad Global

para cada Sistema Seleccionado a partir de los Indicadores
Elementales 45

Figura 13 Rango de Aceptación de Calidad 60

Figura 14 Diagrama de caso general 71

Figura 15 Diagrama sub caso administra usuarios 72
Figura 16 Diagrama de sub caso administrar proyectos 74
Figura 17 Diagrama de sub caso administrar mapas 76
Figura 18 Diagrama de sub caso administra noticias 78
Figura 19 UID al caso de uso validar usuario 81
Figura 20 UID al caso de uso registrar usuario 81
Figura 21 UID al caso de uso modificar usuario 81
Figura 22 UID al caso de uso eliminar usuario 81
Figura 23 UID al caso de uso adicionar proyecto 82
Figura 24 UID al caso de uso modificar proyecto 82
Figura 25 UID al caso de uso eliminar proyecto 82
Figura 26 UID al caso de uso adición mapa 82
Figura 27 UID al caso de uso busca nombre 83
Figura 28 UID al caso de uso visualiza mapa 83
Figura 29 UID al caso de uso eliminar proyecto 83
Figura 30 UID al caso de uso eliminar proyecto 84
Figura 31 UID al caso de uso eliminar proyecto 84
Figura 32 Diagrama de Clases 85
Figura 33 Nodo usuario 86
Figura 34 Nodo Funcionario 86
Figura 35 Nodo Municipio 87
Figura 36 Nodo Proyecto 87
Figura 37 Nodo mapas 87
Figura 38 Nodo Noticias 88
Figura 39 Diagrama de clases navegacional general para el Sistema
Geográfico Huatajata. 89
Figura 40 Diagrama de clases navegacional usuario casual para el Sistema
Geográfico. Huatajata 90
Figura 41 Diagrama de clases navegacional para el usuario editor del
Sistema Geográfico Huatajata 91
Figura 42 Diagrama de clases navegacional usuario administrador para el
Sistema Geográfico Huatajata 92
Figura 43 Diseño navegacional web para un usuario casual para el Sistema
Geográfico Huatajata 93
Figura 44 Diseño navegacional web para un usuario administrador para el
Sistema Geográfico Huatajata 94
Figura 45 ADV usuario navegante 95
Figura 46 ADV usuario administrador 96
Figura 47 ADV noticia 96
Figura 48 ADV funcionario 97
Figura 49 ADV proyecto 97
Figura 50 Pantalla principal del Sistema de Información Geográfico de
Huatajata 98
Figura 51 Ingreso al módulo de proyectos principal del Sistema de
Información Geográfica de Huatajata 99
Figura 52 Pantalla principal de administración del Sistema de Información
Geográfico de Huatajata 99
Figura 53 Módulo de proyectos principal del Sistema de Información
Geográfico de Huatajata 100
Figura 54 Módulo de adición nuevo proyectos del Sistema de Información
Geográfico de Huatajata 100
Figura 55 Módulo de adición de usuario del Sistema de Información
Geográfico de Huatajata 101
Figura 56 Pantalla para el reporte de proyectos del Sistema de Información
Geográfico de Huatajata 101
Figura 57 Vista de reporte de proyectos del Sistema de Información
Geográfico de Huatajata 102
Figura 58 Vista de mapa de proyectos del Sistema de Información
Geográfico de Huatajata 102
Figura 59 Vista de mapa de proyectos del Sistema de Información
Geográfico de Huatajata 103
Figura 60 Diagrama de flujo de vista de proyectos 104
Figura 61 Diagrama de flujo de adición de usuarios 105
Figura 62 Diagrama de flujo de adición de proyectos 107
 CAPITULO 1

MARCO CONCEPTUAL

1.1 INTRODUCCIÓN

Hoy en día se puede evidenciar que el avance de la informática ha facilitado que

muchas tareas sean más eficientes, eficaces y de mejor calidad. Motivo por el cual muchas
de nuestras instituciones están empezando a utilizar herramientas de nueva tecnología para el
manejo de la información.

Un Sistema de Información Geográfico (SIG) se define como un sistema de

hardware, software y procedimientos elaborados para facilitar la obtención, gestión,
manipulación, análisis, modelado, representación y salida de datos espacialmente
referenciados, para resolver problemas complejos de planificación y gestión en los
Municipios que los utilizan, en nuestro caso en el Municipio de Huatajata.

El Gobierno Autónomo Municipal de Huatajata, es una entidad en formación porque

fue de reciente creación motivo por el cual muchas de sus Direcciones están en plena etapa
de planificación. En la actualidad la Dirección de Catastro no cuenta con ninguna
información referente a la planimetría y catastro de la población.

La finalidad a corto y mediano plazo del Municipio es la de organizar la planimetría

de la mancha urbana, delimitar el territorio del municipio, demarcación de límites con los
demás municipios y comunidades que limita.

En el presente trabajo lo que haremos es un Sistema de Información Geográfico

(SIG) del Municipio de Huatajata orientado a la Web para localizar detalladamente los
límites del Municipio y descripción de la mancha urbana, dicha información será de mucha
utilidad para que se pueda planificar mejor el desarrollo del municipio.

Para lograr nuestro cometido detallaremos la teoría y metodología, así como las
herramientas y tecnologías manipuladas para el desarrollo e implementación del software. El
sistema que implementaremos será usado por un personal previamente capacitado.

1
1.2 ANTECEDENTES

1.2.1 De la Institución

La población de Huatajata, es una de las regiones turísticas muy importantes del

nuevo Estado Plurinacional de Bolivia; está situado a 3.800 metros sobre el nivel del mar. Es
un municipio de reciente creación en el departamento de La Paz. Limita al norte con los
Municipios de Achacachi y Huarina (Provincia Omasuyos), al este con el Municipio de
Huarina (Provincia Omasuyos), al sur con el Lago Titicaca y al oeste con Chua Cocani
(Provincia Omasuyos). Tiene una Superficie Aproximada de 1684 Has. Y un perímetro
lineal de 17,47 km. El Municipio está compuesto por las siguientes comunidades: Huatajata
(Capital), Soncachi Chico, Centro Chilaya, Tajara Grande, Tajara Chico, Tajara Suwañaka,
Chilaya, Chilaya Grande. Sancajahuira y zona Chilaya Chico 1.

La ocupación del suelo se ha realizado en su mayor parte sin realizar políticas

urbanas de ordenamiento territorial el cual involucre acertadamente el riesgo como concepto,
y la incorporación de medidas en temas de prevención y mitigación de la población.

El municipio está expuesto a inundaciones por su ubicación geográfica colindante

con el lago Titicaca en tiempo de lluvia. El municipio es nuevo en todos los ámbitos de una
organización publica, que por el cual aún está en la etapa de organización de toda entidad
pública para el buen desenvolvimiento. Y se están recién elaborando la planificación de sus
departamentos y la elaboración de información respecto a todo lo que se refiere al municipio.

1.2.2 Descripción del Sistema Actual

Como el municipio es de reciente creación motivo por el cual en la actualidad no

existe documentación sobre la Cartografía del municipio, dicha situación no permite una
buena planificación y desarrollo del mismo, impidiendo la administración territorial
eficiente, la información está siendo recién levantada por personal de la Escuela Militar de
Topografía.

1
Gaceta Oficial de Bolivia

2
1.2.3 Antecedentes del proyecto

Los proyectos similares al tema propuesto en la carrera de informática son:

 “Sistema de Información Geográfico, vía Web”: Ministerio de Relaciones Exteriores

y Cultos, Dirección General de Limites y Fronteras y Asuntos Marítimos (Quisbert,
Liuca, Ramiro Zenón). Desarrollado con el objetivo de recabar y administrar la
información de los límites fronterizos del territorio nacional y departamental,
información de los hitos existentes, brindando un portal web para acceso a las
personas interesadas.
 “Sistema de Información Geográfico para la Administración de la red de Agua”
Caso: Cooperativa LIHUAJTAYPI Ltda. (Limachi Guzmán, Sandra Celia).
Desarrollado para mejorar el monitoreo y administración de la información de la red
de distribución de agua potable en la Cooperativa y de este modo ofrecer información
oportuna y un servicio eficiente en el suministro de agua a socios y usuarios.
 “Sistema de Información Geográfico de los Equipamientos del Macro Distrito de
Cotahuma” (Quisbert Arias, Gladys Martha). Desarrollado para proporcionar
información oportuna, automatizada y actualizada de la ubicación y la situación en la
que se encuentran los equipamientos con los que cuenta el Macro Distrito de
Cotahuma, de esta manera obtener un buen flujo de información para realizar la
óptima planificación y conformación de redes de equipamientos para el desarrollo
urbano.
 “Sistema de información Geográfico para Zoonosis” (Casias Márquez, Johann
Stanislao). El objetivo es implementar un sistema de información geográfico que
mejore la toma de decisiones de la institución de Zoonosis, siendo útil para
identificar las zonas donde existe denuncias de casos de rabia, identificar persona
infectadas con rabia, hacer un seguimiento a las personas infectadas y determinar los
medicamentos para remediar la infección.
 “Sistema de Información Geográfico para la Administración Territorial Catastral”
(Flores Pérez, Oscar Ramiro). Desarrollar un sistema de Información Geográfico para
la Administración Catastral, de la Dirección de Catastro y Administración Territorial,

3
 en la Sub Alcaldía de Ovejuyo (Distrito 1) perteneciente al Gobierno Autónomo
Municipal de Palca; que permita la eficiente administración y control en la
información de predios y propietarios, trámites realizados y otros datos necesarios
para la mejora en los procesos catastrales en general.

1.3 PLANTEAMIENTO DEL PROBLEMA

1.3.1 Diagnóstico del Problema

De momento en la institución todas las Direcciones se encuentran en la etapa de

planificación, por tal motivo se continúa coordinando la manera en que se va a trabajar a
futuro al interior e interacción con cada uno de ellas.

La función de la Dirección de Catastro es llevar a cabo las operaciones catastrales de

identificación, localización, registro, cartografía y actualización de los valores catastrales de
inmuebles pertenecientes al área urbana del municipio.

En la actualidad podemos decir que existen una infinidad de problemas a resolver en

el Municipio de Huatajata, cabe resaltar los más importantes de nuestro interés:

 En la actualidad no se cuenta con la cartografía del municipio.

 Las delimitaciones territoriales del municipio no están establecidas y demarcadas
por una autoridad competente.
 De las propiedades e inmuebles del municipio no se tiene un registro técnico.
 Todos los funcionarios no están cabalmente bien ubicados en la institución.
 No se está utilizando a cabalidad las nuevas tecnologías en la institución por no tener
a disposición.

1.3.2 Formulación del Problema

¿De qué manera es posible tener un mapa referencial completo de toda la comunidad,
brindando información exacta de sus recursos y proyectos a los pobladores, para una
adecuada administración que coadyuve en su desarrollo?

4
1.3.3 OBJETIVOS

1.3.3.1 Objetivo General

Desarrollar un Sistema de Información Geográfico del Municipio de Huatajata

que permita visualizar toda la población, brindando información confiable de sus planes para
que su progreso urbano contenga lineamientos necesarios así guiar y proponer el crecimiento
ordenado de la región.

1.3.3.2 Objetivos Específicos

 Desarrollar un Sistema de Información Geográfico para la administración y gestión

territorial del municipio.
 Almacenar toda la información en una base de Datos Relacional – Espacial
Geográfica, para el manejo de proyectos desarrollados por el municipio.
 Desarrollar una interfaz gráfica utilizando los principios de usabilidad.
 Diseñar módulos para la administración de proyectos SIG (altas, bajas,
modificaciones, generación de reportes consulta de información general y
especifica).
 Desarrollar una aplicación WEB que permita la publicación acerca de los proyectos
que se tiene en ejecución el municipio.

1.4 ALCANCES Y LIMITES

1.4.1 Alcances

 Se desarrollara una Base de Datos Relacional – Espacial, porque se contara con la

información necesaria para dicho fin.
 Se generaran manuales de usuario para el conocimiento del SIG para su adecuado
uso del mismo.
 El SIG estará disponible para todos los funcionarios, para realizar consultas pero con
restricciones algunas aplicaciones del sistema.

5
 Se desarrollara una WEB para se pueda explicar en distintas plataformas (Windows,
Linux, etc.,).
 Se tendrá una relación exacta de los límites del Municipio con los diferentes vecinos.

1.4.2 Limites

 Este proyecto será implementado en las oficinas de la Dirección de Catastro del

Municipio de Huatajata.
 El módulo de Proyectos nos mostrara las delimitaciones territoriales, el catastro
urbano y la planimetría del municipio.
 Se definirán restricciones a los usuarios debido a que la información no puede ser
manipulada por personal no autorizado.

1.5 APORTES

Se podrá contar con los siguientes módulos en el SIG.

 Navegación web por la información geográfica espacial.

 Consulta de información de proyectos.
 Noticas actuales del municipio.
 Modificaciones a proyectos.
 Lista de proyectos ejecutados y en ejecución.
 Reportes.

Administración de Usuarios

 Registro de nuevos usuarios.

 Asignación de privilegios a usuarios.
 Modificaciones.
 Bajas del sistema.

6
1.6 JUSTIFICACION

1.6.1 Social

Con la implementación del Sistema de Información Geográfica (SIG) la Dirección de

Catastro del Municipio de Huatajata será la beneficiada en esta entidad ya que podrá
empezar a desarrollar sus actividades utilizando nuevas tecnologías porque en la actualidad
no tiene ninguna información al respecto de esta manera brindar a la ciudadanía soluciones a
futuro.

1.6.2 Técnica

De momento en la Dirección de Catastro no existe ninguna información sobre la

geografía de la población debido a su reciente creación de la institución, que está influyendo
en las actividades de la entidad, tampoco cuenta con herramientas requeridas para un buen
manejo de la información tanto de software como de hardware, pero existe la predisposición
de la alcaldía para la adquisición de los mismos. Siendo así que para el desarrollo del sistema
será necesario contar con los siguientes equipos:

Hardware:

 Una Computadora Core 2 Duo y/o superiores

 Un Plotter de 44” con 1200 ppp y/o similares
 Un Scanner 4200 ppp y/o similares.
 GPS portátil

Software:

 Sistema Operativo Windows 7 profesional o superior

 Gestor de Base de Datos: PostgreSQL
 Plataforma de desarrollo: tecnologías .NET
 Lenguajes de programación: PHP y JavaScript
 Herramientas software GIS, ArcGIS Destop 10

7
  Servidores Web: Apache Tomcat y Mapserver.

1.6.3 Calidad de Software

El Presente proyecto cumplirá con los estándares de Calidad ISO/IEC 9126, que
exigen la funcionalidad, fiabilidad, usabilidad, eficiencia, materialidad y portabilidad del
producto.

1.6.4 Económica

El gasto en la compra de equipos, tendrá sus frutos a futuro siendo una inversión que
cooperara a la institución en la eficiencia y eficacia brindando mejor servicio a la población.
Con la implementación de este nuevo sistema el Municipio de Huatajata a futuro podrá
planificar proyectos y optimizar mejor sus recursos.

1.6.5 Metodología

Se propone desarrollar la metodología OOHDM (Object - Oriented Hypermedia

Design Method) de modo establecer los parámetros necesarios para el desarrollo de un
producto de software optimo que satisfaga todas las necesidades para el cual se lo desarrollo.
También se utilizaran algunas herramientas de RUP por la simplicidad de manejo de esta
herramienta. Así como la utilización de UML (Unitied Modeling Language - Lenguaje
Unificado de Modelado) un popular lenguaje de modelado de sistemas de software. Se trata
de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de
software. Entre otras palabras, UML se utiliza para definir un sistema de software.

1.7 DIAGRAMA DE GANTT

A continuación se presenta la relación de las tareas según el orden en que se ejecutan, el

tiempo de dedicación y las tareas que le preceden: (ver Figura. 1)

8
 ago 2013 sep 2013 oct 2013 nov 2013 dic 2013 ene 2014 feb 2014 mar 2014 abr 2014 may 2014
Id. Nombre de tarea Comienzo Fin Duración
4/8 1/9 8/9 5/1 2/2 9/2 2/3 9/3 6/4 4/5

1 Definir objetivos del proyecto 01/08/2013 12/08/2013 8d

2 Definir tareas a realizar 15/08/2013 23/08/2013 7d

3 Búsqueda de información SIG 02/09/2013 04/10/2013 25d

4 Redacción del programa SIG 08/10/2013 20/11/2013 32d

5 Busqueda insecion de datos SIG 25/11/2013 14/01/2014 37d

6 Elaboracion SIG 20/01/2014 20/03/2014 44d

7 Pruebas-tes de funcionamiento del SIG 01/04/2014 18/04/2014 14d

Instalación del SIG en Municipio de
8 01/05/2014 30/05/2014 22d
Huatajata

Figura 1 Diagrama de Gantt

Fuente: Elaboración propia

9
CAPITULO 2

MARCO TEORICO

2.1 MARCO INSTITUCIONAL

El Gobierno Municipal de Huatajata, es una institución que fue creada el año 2010 de
la localidad del mismo nombre. Limita al Norte con los Municipios de Achacachi y Huarina
(Provincia Omasuyos), al Oeste con Chua Cocani (Provincia Omasuyos), al sur con el Lago
Titicaca y al Este con el municipio de Huarina (Provincia Omasuyos) Municipio está
compuesta por las siguientes comunidades: Huatajata (Capital), Soncachi Chico, Centro
Chilaya, Tajara Grande, Tajara Chico, Tajara Suwañaka, Chilaya, Chilaya Grande,
Sancajahuira y zona Chilaya Chico [Gaceta 2010].

Misión

Consolidar al Gobierno Autónomo Municipal de Huatajata como una institución que

previene y sanciona las irregularidades bajo el concepto de “Cero Tolerancia a la
Corrupción”, transparentando la gestión municipal para crear una cultura ética de verdadero
servicio a la comunidad, eficaz y eficiente en su relación con los ciudadanos.

Visión

Liderar la generación de políticas de transparencia en la gestión pública, apoyando de

manera activa al fortalecimiento institucional del Gobierno Autónomo Municipal de
Huatajata, en la atención de reclamos y denuncias, mejorando la calidad en la prestación de
los servicios municipales, con participación ciudadana, generando acceso a la información,
previniendo y sancionando la corrupción, con servidores públicos municipales transparentes.

Organigrama

En la actualidad el municipio de Huatajata esta estructuralmente organizado como se

muestra en la figura 2.

La Dirección de Planificación de Desarrollo Urbano, Proyectos y Turismo está

compuesto por un responsable de Planificación Urbana de Proyectos y Catastro, por un

10
Responsable de Desarrollo Agropecuario Mejoramiento Genético y un Encargado de
Turismo y Promoción Municipal. Esta dirección es la que se encarga del levantamiento de
catastro y planificación del municipio.

CONCEJO
MUNICIPAL

SECRETARIA ASESOR LEGAL

ALCALDE
MUNICIPAL

SECRETARIA AUDITOR
EJECUTIVA INTERNO

OFICIAL MAYOR
ADMINISTRATI
VO

DIRECCION DE DIRECCION DE PLANIFICACION

EDUCACION SALUD, DE DESARROLLO URBAHO,
DIRECCION CULTURA Y PROYECTOS Y TURISMO
ADMINISTRATIVA DEPORTES
FINACIERA

RESPONSABLE DE RESPONSABLE DE DESARROLLO,

ENCARGADO DE DEFENSORIA PLANIFICACION URBANA AGROPECUARIO, MEJORAMIENTO
RESPONSABLE DE ENCARGADO DE
DE LA NIÑEZ Y ADOLECENCIA GENERO PROYECTOS Y CATASTRO GENETICO
CONTABILIDAD Y DEPORTE SALUD Y
PRESUPUESTO GENERACIONAL
CULTURA

ENCARGADO DE TURISMO Y
PROMOCION MUNICIPAL

ENCARGADO DE TECNICO ENCARGADO DE ENCARGADO DE ENCARGADO

COMPRAS Y ADMINISTRATIVO TESORERIA Y ALMACENES Y INTENDENCIA
COTIZACIONES FINANCIERO RECAUDACIONES ACTIVOS FIJOS MUNICIPAL

PERSONAL DE ASEO
PORTERO
URBANO

ENCARGADO DE
ARCHIVO

Figura 2 Organigrama del Municipio de Huatajata

Fuente: Alcaldía Municipal de Huatajata

11
2.2 SISTEMAS DE INFORMACION GEOGRAFICO

En las últimas décadas las tecnologías de la información y la comunicación (TICs)

han revolucionado el desarrollo, implementación, almacenamiento y distribución de la
información mediante la utilización de diferentes medios. Los Sistemas de Información
Geográfica (SIG) como bases de datos geográficas, han evolucionado rápidamente ligados al
crecimiento de las tecnologías de la información, ofreciendo e integrando cada vez más
aplicaciones técnicas para la gestión y procesamiento de los datos espaciales en el software.

Los SIG ofrecen una gran variedad de utilidades y aplicaciones relacionadas con los
trabajos específicos de ordenamiento urbano y territorial. Por ejemplo, contribuyen en las
tareas de almacenamiento y sistematización de la información de entes públicos y privados
(censos, catastro, bases inmobiliarias, patrimonio público, padrones industriales y
comerciales, redes de infraestructura urbana, etc.); La identificación, cuantificación y
análisis de la distribución espacial de cualquier fenómeno urbanos o de carácter territorial; el
análisis de tendencias espaciales para la definición de lineamientos territoriales; la
evaluación de modificaciones de normas urbanas y trabajos de prospectiva territorial; los
diagnósticos de situación y el diseño de políticas territoriales diversas, desarrollo de planes
de sector, planes parciales, códigos urbanos, entre otras; el control y la gestión de la
información para los procesos de toma de decisión, por ejemplo, el seguimiento geo
referenciada de expedientes.

En la gestión municipal es importante la sistematización y el manejo eficiente de la

información. Los SIG posibilitan la conformación de un sistema flexible de manejo
complejo de la información, con capacidad de integración de fuentes diversas y actualización
permanente.

En este sentido lo que se pretende con este documento es la implementación de un

Sistema de Información Geográfica (SIG) del Municipio de Huatajata para dar solución al
problema de falta de información en relación a su cartografía.

12
2.2.1 Definición

La diversidad de Sistemas de Información Geográfica (SIG) ha dado curso a una gran

variedad de definiciones. Pues generalmente un usuario de un SIG define de acuerdo al uso
que este le dé y a su propia experiencia y habilidad.

 Los sistemas de Información Geográfica (SIG) son, básicamente, herramientas

informáticas que procesan y analizan datos con un potente espacial. Una definición
más completa considera un sistema de información geográfica como un conjunto de
herramientas diseñado para la adquisición, almacenamiento, análisis y representación
de datos espaciales. Una característica fundamental de los SIG es que trabajan con
mapas y, a diferencia de otros programas que también lo hacen, los SIG pueden
realizar operaciones de análisis espacial, bastantes sofisticados en algunos casos,
utilizando los datos espaciales y sus atributos almacenados en el propio sistema, que
permiten obtener nuevos mapas a partir de una única fuente de datos. [Ordoñez
2003].
 Los sistemas de información geográfica se pueden definir como una “Tecnología
integradora que une varias disciplinas con el objetivo común del análisis, creación,
adquisición, almacenamiento, edición, transformación, visualización, distribución,
etc. de Información geográfica”. Los SIG pueden entenderse como una caja de
experimentar, lo que permite al analista o gestor territorial trabajar o plantearse
diferentes escenarios virtuales de una determinada región por una parte lo que se
producirían con la ejecución de ciertas políticas o los que ocurrirían siguiendo
determinadas tendencias. Todo esto hace de los SIG una potente herramienta de
planificación cuando se dispone de una base de datos auto suficiente para los fines
que se plantean. [Gomez 2006].

2.2.2 Componentes de un SIG

En la Figura 3 de detalla los componentes de un SIG:

13
 Figura 3 Componentes de un SIG

Fuente: [Gomez 2006]

2.2.2.1 Hardware

Es la parte física donde se asienta un SIG, este suele estar representado por una
plataforma de computador; aquí son factibles el uso de modestos ordenadores personales,
potentes estaciones de trabajo así como otros entornos informáticos. Asimismo un conjunto
de componentes técnicos: tabletas digitalizadoras, plotter, scanner y unidades de
almacenamiento y procesamiento son requeridos para poder desarrollar la potencia operativa
de los SIG. [Gómez 2006].

2.2.2.2 Software

Es el encargado de realizar las operaciones y manipulación de los datos. El usuario

establece una estrecha relación de comunicación acerca de las operaciones realizadas.
[Gómez 2006].

14
2.2.2.3 Datos

Posiblemente en muchos casos este sea el elemento crucial ya que sobre el son
realizadas todas las operaciones posibles de desarrollar en un SIG, además de ser el aspecto
que requiere un mayor esfuerzo para su implementación en un proyecto SIG. [Gómez 2006].

2.2.2.4 Recursos Humanos

Definido como liveware, Es considerado como el elemento más importante de un

SIG. Siendo representado por las personas encargadas de diseño, implementación y uso de
un SIG. Estas personas son las que deben gestionar y desarrollar las posibilidades que
ofrecen estos sistemas para así producir resultados, soluciones, selecciones, análisis, etc. A
partir de las Base de Datos Espaciales. [Gómez 2006].

2.3 Tipos de SIG

2.3.1 SIG Vectoriales

Un modelo vectorial representa los objetos espaciales codificando sus fronteras, por
lo que las primitivas gráficas en este tipo de SIG son tres: puntos, líneas arcos y polígonos.

Los objetos puntuales se representan mediante un par de coordenadas, los objetos

lineales se definen mediante el trazado de segmentos rectilíneos que se cruzan en vértices,
representándose mediante las coordenadas de estos vértices, y los objetos superficiales se
codifican aproximando sus fronteras mediante segmentos lineales, cuyas coordenadas se
registran.

Una de las capacidades más interesantes de los SIG vectoriales es la posibilidad de

generar topología de una cobertura. Es decir, almacenar además de la geometría de los
elementos, sus relaciones con otros elementos de cobertura.

Los polígonos se emparejan con un punto, llamado label o etiqueta, en el que podrán
reflejarse sus atributos. Como las líneas comunes entre polígonos son compartidas, se puede
tener información sobre qué polígonos son contiguos.

15
 Estas relaciones topológicas de conectividad, dirección, inclusión y contigüidad son
la base de la capacidad analítica de los SIG vectoriales.

2.3.2 SIG Raster

En los SIG matriciales, la única primitiva gráfica es la celda, que no es más que una
unidad de imagen cuyo tamaño regular dependerá de la resolución con que se defina la
cobertura.

En este tipo de codificación al mapa analógico fuente se le superpone una malla de

unidades regulares y en cada unidad se registra el valor de la variable que se está
representando, dando lugar a distintas categorías. Si la malla es de tipo cuadrangular, a las
celdas también se les denomina píxeles.

Las celdas están georreferenciadas respecto a un sistema de coordenadas y éste

definido en un sistema de proyección. Aparentemente el SIG debe almacenar todos y cada
uno de los valores de las celdas, pero como esto supondría un volumen de almacenamiento
enorme, generalmente se utilizan diferentes métodos de compresión.

La precisión de la representación digital del mapa dependerá del tamaño de la celda o

pixel. En los SIG matriciales no existe el concepto de topología de una manera tan clara
como en los SIG vectoriales, en gran medida porque no hace falta ya que la topología está
implícita en la regularidad de la red.

Así, si la malla está constituida por cuadrados, el campo “i,j” (número de fila y
número de columna), se encuentra limitado por los siguientes:

En el SIG está registrado donde se halla cada celda y son contiguas posibilitando
operaciones contiguas, equivalentes a las de inclusión, contigüidad y dirección, etc.

2.3.3 GEOREFERENCIACION

La georeferenciación es el posicionamiento en el que se define la localización de un

objeto espacial (representado mediante punto, vector, área, volumen) en un sistema de

16
coordenadas y datos determinado. Este proceso es utilizado frecuentemente en los Sistemas
de Información Geográfica.

La georeferenciación, en primer lugar, posee una definición tecno-científica, aplicada

a existencia de las cosas en un espacio físico, mediante el establecimiento de relaciones entre
las imágenes de raster o vector sobre una proyección geográfica o sistema de coordenadas.
Por ello la georeferenciación se convierte en central para los modelados de datos realizados
por los Sistemas de Información Geográfica (SIG). [Enrique, 2009]

2.4 SOFTWARE LIBRE

El “software libre” se refiere a la libertad de los usuarios para ejecutar, copiar,

distribuir, estudiar, cambiar y mejorar el software, esta clasificación conlleva a cuatro
libertades para los usuarios de software libre. [Stallman, 2004].

 Libertad 1: la libertad para ejecutar el programa sea cual sea el propósito.

 Libertad 2: la libertad para estudiar el funcionamiento del programa y adaptarlo a
necesidades del usuario.
 Libertad 3: la libertad para redistribuir copias y ayudar así al vecino.
 Libertad 4: la libertad para mejorar el programa y luego publicarlo para el bien de
toda la comunidad.

Software libre es cualquier programa cuyos usuarios gocen de estas libertades. De

modo que se debe ser libre de redistribuir copias con o sin modificaciones, de forma gratuita
o cobrando por su distribución, a cualquiera y en cualquier lugar, gozar de esta libertad
significa, entre otras cosas no tener que pedir permiso ni paga para ello.

Así mismo, se debe ser libre para introducir modificaciones y utilizarlas de forma
privada, ya sea en tu trabajo o en tu tiempo libre, sin siquiera tener que mencionar su
existencia. Si se decide publicar estos cambios, no deberías estar obligado a notificárselo a
ninguna persona ni de ninguna forma en particular.

La libertad para utilizar un programa significa que cualquier individuo u

organización podrán ejecutarlo desde cualquier sistema informático, con cualquier fin y sin

17
la obligación de comunicárselo subsiguientemente ni al desarrollador ni a ninguna entidad en
concreto.

La libertad para redistribuir copias supone incluir las formas binarias o ejecutables
del programa y el código Fuente tanto de las versiones modificadas como de las originales
(la distribución de programas en formato ejecutable es necesaria para su adecuada
instalación en sistemas operativos libres, no pasa nada si no se produce forma ejecutable o
binaria, dado que no todos los lenguajes lo soportan), pero todos debe tener la libertad para
redistribuir tales formas si se encuentra el modo de hacerlo.

Para que las libertades 2 y 4 (la libertad para hacer cambios y para publicar las
versiones mejoradas) adquieran significado, se debe disponer del código fuente del
programa. Por consiguiente, la accesibilidad del código fuente es una condición necesaria
para el software libre [Stallman, 2004].

Para materializar estas libertades, deberán ser irrevocables siempre que no comentan
ningún error, si el desarrollador de software revocara la licencia libre, ese software dejara de
ser libre.

Sin embargo, ciertas normas sobre la distribución de software libre parecen

aceptables siempre que no planteen un conflicto con las libertades centrales. El copyleft, es
la norma que establece que. Al redistribuir el programa, no se debe añadir restricciones que
nieguen a los demás sus libertades centrales. Esta norma no viola dichas libertades, sino que
las protege. De modo que pagar o no por obtener copias de software libre, pero
independientemente de la manera en que las obtenga, siempre se tiene la libertad para copiar,
modificar e incluso vender estas copias.

El software libre no significa que sea “no comercial”. Cualquier programa libre
estará disponible para su uso, desarrollo y distribución comercial, el desarrollo comercial del
software libre ha dejado de ser excepcional y de hecho ese software libre comercial es muy
importante. Las normas sobre el empaquetamiento de una versión modificada son
perfectamente aceptables siempre que no restrinjan efectivamente la libertad para publicar
versiones modificadas. Por la misma razón, serán igualmente aceptables aquellas normas que

18
establezcan que “si distribuyo el programa de esta forma, deberás distribuirlo de la misma
manera”, cabe destacar que esta norma permite decidir si publicar o no el programa.
También hay que admitir la posibilidad de que una licencia exija enviar una copia
modificada y distribuida de un programa a su desarrollador original. [Stallman, 2004].

2.5 SISTEMAS DE GESTION DE BASE DE DATOS

2.5.1 Base de datos orientada a objetos

Los sistemas de base de datos orientado a objetos tienen sus orígenes en los lenguajes
de programación orientado a objetos. La idea principal en ambos casos es que el usuario no
tendrá que batallar con construcciones orientadas al computador tales como registros y
campos, sino más bien debería poder manejar objetos (y operaciones) que se asemejan más
en el mundo real. Por ejemplo en vez de pensar en una tupla DEPTO junto con un conjunto
de tuplas empleado, las cuales incluyen valores de claves ajenas que hacen referencia a esa
tupla DEPTO. El usuario deberá pensar directamente en “objeto” departamento que
contenga en realidad un conjunto de objetos empleado dicho de otro modo es elevar el nivel
de la abstracción [Date 1990]

2.5.2 Base de Datos Espaciales

Las bases de datos espaciales deberán satisfacer los mismos requerimientos que las
alfanuméricas en cuanto a eficiencia, capacidad de acceso multiusuario, baja redundancia,
seguridad, etc. La independencia de los datos respecto al programa de aplicación se hace
aquí más potente, ya que los clientes deben representar gráficamente objetos cuyas
coordenadas están en realidad almacenadas como datos numéricos en la base de datos.
[Gómez 2006].

Una base de datos espacial estará formada por cuatro tipos de información que serán
mencionados de la siguiente manera:

 Posición geográfica (¿Dónde está?).

19
 Atributos (¿qué es?, ¿cómo es?): son datos no espaciales que reflejan las
características del objeto o evento en cuestión, por lo que pueden ser almacenados en
una base de datos no espacial.

 Topología (¿con quién y cómo se relaciona?): define las relaciones espaciales entre
entidades geográficas, por ejemplo, la recta 1 intersecta a la recta 2 o el punto A se
encuentra en el interior del polígono P. pueden ser definidas explícitamente o
calculadas a necesidad.

 Tiempo (¿Cuándo es?, ¿hasta cuándo?): será registrado en toda representación

dinámica de elementos, como puede ser uso de suelo, cobertura vegetal, red viaria,
divisiones administrativas, etc.

Una base de datos espacial puede extender la sintaxis de su lenguaje de consulta para
soportar clausulas geográficas. Por ejemplo, podríamos querer saber qué tipo de objeto se
encuentra en unas determinadas coordenadas o descubrir los objetos de un tipo determinado
que existen en el interior de una zona específica.

2.6 OOHDM - OBJECT - ORIENTED HYPERMEDIA DESIGN

METHOD

OOHDM es una metodología de desarrollo propuesta por Rossi y Schwabe [Rossi

1996] para la elaboración de aplicaciones multimedia. OOHDM está basada en HDM, en el
sentido de que toma muchas de las definiciones, sobre todo en los aspectos de navegación,
planteadas en el modelo de HDM. Sin embargo, OOHDM supera con creces a su antecesor,
ya que no es simplemente un lenguaje de modelado, sino que define unas pautas de trabajo,
centrado principalmente en el diseño, para desarrollar aplicaciones multimedia de forma
metodológica OOHDM ha evolucionado bastante desde su nacimiento. Actualmente está
siendo utilizado por sus autores para el desarrollo de aplicaciones en la web. [Schwabe 2001]

20
2.6.1 Conceptos básicos de OOHDM

OOHDM como ya se ha comentado es una metodología de desarrollo para

aplicaciones multimedia. Antes de comenzar a detallar cada una de las fases que propone, es
necesario resaltar algunas de sus características.

La primera de ellas es que OOHDM está basada en el paradigma de la orientación a

objetos. En esto se diferencia de su antecesor HDM. A la hora de la representación de las
clases y los diagramas, OOHDM utiliza la nomenclatura propuesta por OMT [Rumbaugh
1995].

Como ya se comentó al estudiar EORM en las últimas versiones ya se ha asumido

UML. Otra característica de OOHDM es que, a diferencia de HDM, no sólo propone un
modelo para representar a las aplicaciones multimedia, sino que propone un proceso
predeterminado para el que indica las actividades a realizar y los productos que se deben
obtener en cada fase del desarrollo.

Sin embargo, OOHDM no puede considerarse una metodología en el amplio sentido,

ya que, aunque se detalla el proceso a seguir en lo que sería el diseño de la aplicación, no
toma parte en otras fases como pueden ser la captura de requisitos o el análisis. Según
OOHDM estas fases son idénticas a las que se deben realizar en la propuesta de OMT.

Fundamentalmente OOHDM toma como partida el modelo de clases que se obtiene

en la fase de diseño de objetos de OMT o, en sus últimas versiones, en el análisis del
Proceso Unificado de UML. A este modelo lo denomina modelo conceptual. El proceso
anterior a éste, es decir, el análisis y el diseño de sistemas, sería idéntico al que se realizaría
en el desarrollo de un sistema clásico según OMT o UML.

Partiendo de este modelo conceptual, OOHDM propone ir añadiendo características

que permitan incorporar a esta representación del sistema todos los aspectos propios de las
aplicaciones multimedia. En una segunda etapa de diseño, se parte de ese modelo conceptual
y se añade a éste todos los aspectos de navegación, obteniéndose un nuevo modelo de clases
denominado modelo navegacional. Por último, este modelo sirve como base para definir lo

21
que en el argot de OOHDM se denomina modelo de interfaz abstracta. El modelo de interfaz
abstracta representa la visión que del sistema tendrá cada usuario del mismo.

2.6.2 Fases de OOHDM

En OOHDM se proponen 4 fases de desarrollo:

 Diseño Conceptual
 Diseño Navegacional
 Diseño de Interfaz Abstracto
 Implementación

OOHDM es una mezcla de estilos en desarrollo basado en prototipos, en desarrollo

interactivo y desarrollo incremental. En cada fase se elabora un modelo que recoge los
aspectos que se trabajan en esa fase. Este modelo parte del modelo conseguido en la fase
anterior y sirve como base para el modelo de la siguiente fase.

Fase 1- Diseño Conceptual

Se construye un modelo orientado a objetos OOHDM (Object Oriented Hypermedia

Design Method) que represente el dominio de la aplicación usando las técnicas propias de la
orientación a objetos. La finalidad principal durante esta fase es capturar el dominio
semántico de la aplicación en la medida de lo posible, teniendo en cuenta el papel de los
usuarios y las tareas que desarrollan. En la Tabla 1 se esquematiza esta fase.

Fase Diseño conceptual

Productos Diagrama de Clases, División en subsistemas y relaciones
Herramientas Técnicas de modelado O.O, patrones de diseño
Mecanismos Clasificación, agregación, generalización y especialización
Diseño Modelo semántico de la aplicación

Tabla 1 Fase de Diseño Conceptual de OOHDM

Fuente: [Prentice – hall, 1981].

22
 Debido a la similitud de OOHDM y EORM, y debido a que ambos sistemas parten
del modelo de clases básico del sistema, el resultado de esta primera fase de OOHDM para
nuestro ejemplo sería igual que el de EORM.

Fase 2- Diseño Navegacional

En OOHDM una aplicación se ve a través de un sistema de navegación. En la fase de

diseño navegacional se debe diseñar la aplicación teniendo en cuenta las tareas que el
usuario va a realizar sobre el sistema. Para ello, hay que partir del esquema conceptual
desarrollado en la fase anterior. Hay que tener en cuenta que sobre un mismo esquema
conceptual se pueden desarrollar diferentes modelos navegacionales (cada uno de los cuales
dará origen a una aplicación diferente).

La estructura de navegación de una aplicación hipermedia está definida por un

esquema de clases de navegación específica, que refleja una posible vista elegida. En
OOHDM hay una serie de clases especiales predefinidas, que se conocen como clases
navegacionales: Nodos, Enlaces y Estructuras de acceso, que se organizan dentro de un
Contexto Navegacional. Mientras que la semántica de los nodos y los enlaces son comunes a
todas las aplicaciones hipermedia, las estructuras de acceso representan diferentes modos de
acceso a esos nodos y enlaces de forma específica en cada aplicación.

1. Nodos:

Los nodos son contenedores básicos de información de las aplicaciones hipermedia.

Se definen como vistas orientadas a objeto de las clases definidas durante el diseño
conceptual usando un lenguaje predefinido y muy intuitivo, permitiendo así que un nodo sea
definido mediante la combinación de atributos de clases diferentes relacionadas en el modelo
de diseño conceptual. Los nodos contendrán atributos de tipos básicos (donde se pueden
encontrar tipos como imágenes o sonidos) y enlaces.

23
2. Enlaces:

Los enlaces reflejan la relación de navegación que puede explorar el usuario.

Sabemos que para un mismo esquema conceptual puede haber diferentes esquemas
navegacionales y los enlaces van a ser imprescindibles para poder crear esas vistas
diferentes.

OOHDM hace una definición de clase enlace que contiene un único atributo. Lo
vemos en la figura 4. Su atributo almacenaría la clase a la que se navega por ese enlace. Las
clases enlaces sirven para especificar los atributos de enlaces y estos a su vez para
representar enlaces entre clases nodos o incluso entre otros enlaces. En cualquier caso, el
enlace puede actuar como un objeto intermedio en un proceso de navegación o como un
puente de conexión entre dos nodos.

Enlace

Destino: Clase

Figura 4: Definición de la clase enlace

Fuente: [Prentice – hall, 1981].

3. Estructuras de Acceso:

Las estructuras de acceso actúan como índices o diccionarios que permiten al usuario
encontrar de forma rápida y eficiente la información deseada. Los menús, los índices o las
guías de ruta son ejemplos de estas estructuras. Las estructuras de acceso también se
modelan como clases, compuestas por un conjunto de referencias a objetos que son
accesibles desde ella y una serie de criterios de clasificación de las mismas.

4. Contexto Navegacional:

Para diseñar bien una aplicación hipermedia, hay que prever los caminos que el
usuario puede seguir, así es como únicamente podremos evitar información redundante o que

24
el usuario se pierda en la navegación. En OOHDM un contexto navegacional está compuesto
por un conjunto de nodos, de enlaces, de clases de contexto y de otros contextos
navegacionales. Estos son introducidos desde clases de navegación (enlaces, nodos o
estructuras de acceso), pudiendo ser definidas por extensión o de forma implícita.

5. Clase de Contexto:

Es otra clase especial que sirve para complementar la definición de una clase de
navegación. Por ejemplo, sirve para indicar qué información está accesible desde un enlace y
desde dónde se puede llegar a él. En la figura 5 encontramos el diagrama de clases
navegacionales para nuestro ejemplo. En ella aparecen dos nodos: Datos Identificación y
Datos Descripción. El primero muestra los datos de identificación del bien, que se
describieron en el apartado 2 y en el segundo los datos de descripción. Nótese que han
aparecido dos atributos nuevos de tipo Enlace en estas clases. Son enlaces que indican que
podemos navegar a la clase Menú Muebles desde estos nodos.

Por su parte, esta clase es una estructura de acceso. Vemos entonces como en los
modelos navegacionales aparecen instancias de la clase enlace para representar los enlaces
entre nodos.

MenuMuebles

aDatosBasicos Enlace
aDatoGraficos Enlace
aDatosDescripcion Enlace

O..n

DatosDescripcion DatosIdentificacion
cronologia Cronologia Codigo del bien Codigo
Certeza enumerado Denominacion Cadena
Tipologia Tipologia
Acceso enumerado
Periodohistorico Phistorico
Estilo Estilo Observaciones Cadena
Autor Autor aMenu Enlace
aMenu enlace

Figura 5: Diagrama de clases navegacionales

Fuente: [Prentice – hall, 1981]

25
 Este modelo quedaría demasiado ambiguo por sí solo. Es necesario indicar de qué
clase o clases del modelo conceptual proviene cada una y cuáles son los atributos de la clase
enlace. Por ello, este modelo de clases iría acompañado de una descripción formal de lo que
son. En la figura 6 vemos la descripción formal de dos de estas clases como indica OOHDM.

En el primer ejemplo se describe la clase índice que tenemos, indicando que toma
datos de la clase Bien Mueble del diagrama de clases conceptual. Se describen sus dos
atributos como enlaces y se indica a qué clase navegarían. En el segundo, se describe uno de
los nodos. Aquí se indica que toma los atributos de la clase Bien Mueble del modelo
conceptual y se hace una equivalencia al atributo de esta clase asumido. Por ejemplo, el
Código del nodo es igual al atributo Código de la clase Bien Mueble del modelo conceptual.

La navegación no se encontraría definida sin el otro modelo que propone OOHDM:

el contexto navegacional. Esto es la estructura de la presentación dentro de un determinado
contexto. Los contextos navegacionales son uno de los puntos más criticados a OOHDM
debido a su complejidad de expresión. Se va a plantear un contexto de presentación sencillo
para nuestro sistema de ejemplo. En la figura 6 vemos cómo quedaría.

INDICE BienMueble [VIENE de Bien Mueble: BM]

aDatosbasico:Enlace (DatosBasico)

aDatosDescripcion: Enlace (Datos Descricion)

NODO DatosIdentificacion[VIENE de BienMueble:BM]

Codigo:BM Codigo
Denominacion: BM Denominacion
Acceso: BM Acceso
Observaciones:BM Observaciones
aMenu:Enalce(BienMueble)

Figura 6: ejemplo de descripción de clases navegacionales

Fuente: [Prentice – hall, 1981].

26
 Indice por Por inmueble
inmueble
Por autores
Menu Muebles Indice por autor

Indice por
Por query
query

arqueologicos

otros

Figura 7 Ejemplo de Contexto Navegacional

Fuente: [Prentice – hall, 1981].

Con este contexto se está expresando lo siguiente. Hay una clase principal
denominada Menú Muebles, que es la clase índice del modelo navegacional, y que es la
partida del contexto. En este menú aparecen 3 índices que nos permiten consultar los bienes
a través de los inmuebles, es decir detallar todos los bienes muebles que pertenecen aún
determinado inmueble; a través de los autores, detallando los bienes muebles de un
determinado autor; y a través de queries o sentencias de búsqueda libres, indicamos el
criterio de búsqueda y obtenemos los bienes muebles que la cumplen. Ejecutando cualquiera
de estas opciones llegaríamos a ver los datos de identificación ordenadas por inmuebles, por
autores o por queries de los bienes muebles. Como puede verse, cuando el usuario tiene
posibilidad de ejecutar una sentencia de búsqueda se indica con un cuadro punteado en
negrita en el que se indica el concepto por el que se puede buscar. Cada criterio de búsqueda
genera una vista diferente de los muebles que se representa mediante cajas con el borde
negro continuo. Estas cajas tienen en su borde superior izquierdo un recuadro negro que
indica que hay un orden predefinido para mostrarlo.

Hay casos en los que hay un grupo de elementos caracterizados por algo. Por
ejemplo, los bienes muebles arqueológicos tienen un interés especial para los arqueólogos.
En este caso, vemos que desde el menú nace una flecha que va a los datos de identificación
hacia una caja punteada denominada “arqueológicos”. Esto indica que desde el menú
principal el usuario tendría la opción de ver solo los bienes arqueológicos. Aquí no es

27
necesaria hacer ninguna selección antes de obtener los bienes, por eso no caja índice
intermedia. La opción de “otros” indicaría que se pueden obtener los bienes no
arqueológicos.

Nótese que con sólo dos criterios de búsquedas y trabajando con una sola clase
navegacional, la de datos de identificación, el diagrama resulta bastante complejo de
explicar. Pero además resulta algo ambiguo porque no podemos indicar por qué atributos se
pueden hacer las queries.

Cuando los criterios de recuperación se complican, caso muy común en la mayoría de

las aplicaciones, el contexto navegacional resulta bastante engorroso por la cantidad de
opciones que saldrían. Imaginemos que queremos buscar por: autor, tipología, estilo, período
histórico, ubicación actual y por cualquier combinación de ellos. La cantidad de cajas de
índice que saldría resultarían inviables a la hora de la representación.

TRANSFORMACIÓN NAVEGACIONAL:

Cuando la aplicación se ejecuta en una sola vista, el contexto navegacional tiene

bastante poder semántico como para representar la aplicación, por muy compleja que pueda
salir. Sin embargo, cuando pueden aparecer diferentes contextos de navegación a la vez, se
requiere el uso de transformaciones navegacionales. A través de ellas podemos expresar
concurrencias o navegaciones que se ejecutan a la par. Por ejemplo, imaginemos que nuestra
aplicación variara en su representación para los arqueólogos y el resto de investigadores,
pues habría que representar diferentes contextos navegacionales. En la tabla 2 vemos un
resumen de esta fase.

Fase Diseño navegacional

Productos Nodos, enlaces, estructuras de accesos, contextos navegacionales y
transformaciones
Herramientas Técnicas de modelado O.O, patrones de diseño, diagramas de
estados, Escenarios
Mecanismos Clasificación, agregación, generalización y especialización
Objetivo de diseño Establecer los recorridos que el usuario puede seguir por la aplicación
Tabla 2 Fase de diseño navegacional de OOHDM

Fuente: [Prentice – hall, 1981]

28
Fase 3- Diseño de Interfaz Abstracta

Una vez definida la estructura navegacional, hay que prepararla para que sea
perceptible por el usuario y esto es lo que se intenta en esta fase. Esto consiste en definir qué
objetos de interfaz va a percibir el usuario, y en particular el camino en el cuál aparecerán
los diferentes objetos de navegación, qué objeto de interfaz actuará en la navegación, la
forma de sincronización de los objetos multimedia y el interfaz de transformaciones. Al
haber una clara separación entre la fase anterior y esta fase, para un mismo modelo de
navegación se pueden definir diferentes modelos de interfaces, permitiendo, así que el
interfaz se ajuste mejor a las necesidades del usuario.

Modelos de vistas abstractas de datos (ADVs):

Los modelos de los ADVs no son más que representaciones formales que se usan
para mostrar:

i. La forma en que se estructura la interfaz, para ello se usan las vistas abstractas de
datos. Estos son elementos que tienen una forma y un dinamismo. Son elementos abstractos
en el sentido de que solo representan la interfaz y su dinamismo, y no la implementación, no
entran en aspectos concretos como el color de la pantalla o la ubicación en ésta de la
información. Así, tendremos un conjunto de representaciones gráficas, que gestionan las
estructuras de datos y de control, y un conjunto de aspectos de interfaz, como las entradas
del usuario y las salidas que se le ofrecen.

ii. La forma en que la interfaz se relaciona con las clases navegacionales, para ello se
usan diagramas de configuración. Los diagramas de configuración van a ser grafos dirigidos
que permitirán indicar de qué objetos de navegación toman la información los ADV.

iii. La forma en que la aplicación reacciona a eventos externos, para ello se usan los
ADVs-Charts. Los ADVs-Charts van a ser diagramas bastante similares a las máquinas de
estados, es más en las últimas versiones de OOHDM se usan máquinas de esto. A través de
ellas se puede indicar los eventos que afectan a una ADV y cómo ésta reacciona a ese
elemento. Aplicando esta fase a nuestro ejemplo tendríamos varios ADVs, por ejemplo en la

29
figura 8 mostramos el de la clase Menú y el de la clase Datos Básicos. Nótese como se
representan los enlaces entre una clase y otra. Aunque aquí hemos optado por representar las
Clases navegacionales Datos Identificación y Menú Muebles con un solo ADV cada uno,
esto no tiene porqué ser así. Una clase puede dar origen a uno o más ADV y un ADV pueden
representar a uno o más clases.

ADV DatosIdentificacion

Codigo
Acceso
Observaciones
ADV Menu

ADV Menu

ADVDatosIdentificacion

ADVDatosDescricion

Figura 8: Ejemplo de ADV 2.5 Ingeniería WEB

Fuente: [Prentice – hall, 1981].

Para indicar de qué clase navegacional viene un ADV se usa el diagrama de

configuración. Como ya se ha dicho, es un grafo en el que las fuentes son clases ADVs y los
sumideros clase navegacionales. En la figura 9 vemos parte de este diagrama para el
ejemplo. Con él indicamos que el ADV Datos Identificación descrito proviene de la clase
Datos Identificación.

ADVDatosIdentificacion ADVDatosDescricion

Figura 9: Ejemplo de diagrama de configuración

Fuente: [Prentice – hall, 1981].

30
 Ahora para completar el ejemplo habría que crear la máquina de estados que
representa el dinamismo de cada uno de los ADV. No vamos a recogerlo puesto que el
ejemplo es muy sencillo y no posee un dinamismo que justifique esto. En la tabla 3 vemos
descrita esta fase.

Fase Diseño de interfaz abstracta

Productos Objetos de interfaz abstracta, respuestas a eventos externos y

transformaciones de interfaz

Herramientas ADVs, Diagramas de configuración, ADV-Charts y patrones de

diseño

Mecanismos Mapeado entre los objetos de navegación y los objetos visibles

Objetivo de diseño Modelado de los objetos perceptibles por el usuario y de cómo le

afecta a la aplicación los eventos externos

Tabla 3 Fase de diseño de interfaz abstracto de OOHDM

Fuente: [Prentice – hall, 1981].

Fase 4- Implementación

Una vez obtenido el modelo conceptual, el modelo de navegación y el modelo de

interfaz abstracta, sólo queda llevar los objetos a un lenguaje concreto de programación, para
obtener así la implementación ejecutable de la aplicación. En a tabla 4 vemos un resumen de
esta fase.

Fase Implementación

Productos Aplicación ejecutable

Herramientas El entorno del lenguaje de programación

Mecanismos Los ofrecidos por el lenguaje

Objetivo de diseño Obtener la aplicación ejecutable

Tabla 4 Fase de implementación de OOHDM

Fuente: [Prentice – hall, 1981].

31
 Para terminar, podríamos decir que los puntos claves de OOHDM se encuentran en:

 Contempla los objetos que representan la navegación como vistas de los objetos
detallados en el modelo conceptual.
 Abstrae los conceptos básicos de la navegación: nodos, enlaces e índices y los
organiza mediante el uso de los contextos de navegación, permitiendo así una
organización adecuada de los mismos.
 Separa las características de interfaz de las características de navegación, con las
ventajas que esto supone.

2.6.3.- VENTAJAS Y DESVENTAJAS DE OOHDM

2.6.3.1 Ventajas

 OOHDM posee una notación diagramática completa, que permite representar en

forma precisa elementos propios de las aplicaciones hipermedia, tales como nodos,
anclas, vínculos, imágenes, estructuras de acceso y contextos.
 En cada etapa de la metodología, específicamente en las de análisis y de diseño, el
usuario es considerado un integrante fundamental en la validación del producto
obtenido. Esta interacción ayuda al desarrollador a entender y lograr en cada etapa lo
que el usuario realmente necesita.
 OOHDM genera una cantidad considerada de documentación a través de sus distintas
etapas de desarrollo lo que permite llevar un control del desarrollo de las etapas y
tener la posibilidad real de realizar una rápida detección, corrección de errores y
mantención.
 OOHDM ofrece la posibilidad de crear estructuras de rehúso, tales como los
“esqueletos” o “frameworks”, cuyo principal objetivo es simplificar las áreas de
diseño y disminuir su consumo de recursos.
 OOHDM utiliza una herramienta diagramática llamada UID, la cual es muy útil. Este
instrumento es capaz de representar en forma precisa y con claridad de casos de uso
obtenidos.

32
2.6.3.2 Desventajas

 Si bien es cierto los creadores de OOHDM señalan que la metodología fue creada
principalmente para desarrollar aplicaciones hipermedia de gran extensión. Dicha
orientación ha llevado a los creadores a desarrollar una serie de reglas y pasos para
realizar distintos mapeos entre un diagrama y otro, con el principal objetivo de
simplificar y mecanizar las tareas de cada fase este intento de mecanización, puede
traer como consecuencia el olvido de detalles fundamentales por parte del
desarrollador.
 El diseño navegacional es un tanto tedioso, para resolverlo adecuadamente es
necesario realizar una gran cantidad de diagramas que muchas veces entregan
información similar a la entregada por los UIDs y las ADVs. Esta redundancia de
información podría ser evitada graficando la información en un solo tipo de diagrama
que sea capaz de reunir capacidades de los UIDs, diagramas de contexto y ADVs.

2.7.- HERRAMIENTAS DE DESARROLLO

2.7.1 PostgreSQL10

PostgreSQL es un sistema de gestión de base de datos objeto – relacional, distribuido

bajo licencia BSD y con su código Fuente disponible libremente. Es el sistema de gestión de
base de datos de código abierto más potente del mercado y en sus últimas versiones no tiene
nada que envidiarle a otra base de datos comerciales.

PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de

multihilos para garantizar la estabilidad del sistema. Una falla en uno de los procesos no
afectara el resto y el sistema continuara funcionando.

 Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL como

administrador de bases de datos. La conexión puede ocurrir vía TCP/IP o sockets
locales.
 Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado
de escuchar por un puerto/socket por conexiones entrantes de clientes. También es el

33
 encargado de crear los procesos hijos que se encargaran de autentificar estas
peticiones, gestionar las consultas y mandar los resultados a las aplicaciones clientes.
 Ficheros de configuración: Los 3 ficheros principales de configuración utilizados
por PostgreSQL, postgresql.conf. son: Pg, Pg hba.conf y pg_ ident. conf.
 Procesos hijos postres: Procesos hijos que se encargan de autentificar a los clientes,
gestionar las consultas y mandar los resultados a las aplicaciones clientes.
 PostgreSQL share buffer cache: Memoria compartida usada por PostgreSQL para
almacenar datos en cache.
 Write ahead log (WAL): Componente del sistema encargado de asegurar la
integridad de los datos (recuperación de tipo REDO).
 DISCO: Donde se almacenan los datos y toda la información que PostgreSQL
funcione.

2.7.2 PHP

PHP es un lenguaje de programación interpretado, diseñado originalmente para la

creación de páginas web dinámicas. Es usado principalmente en interpretación del lado del
servidor (Server-Side Scripting) pero actualmente puede ser utilizado desde una interfaz de
línea de comandos o en la creación de otros tipos de programas incluyendo aplicaciones con
interfaz gráfica usando las bibliotecas Qt o GTK+.

PHP es un acrónimo recursivo que significa PHP Hipertext Pre-Processor for Rasmus
Lerdorf en 1994; sin embrago la Implementación principal de PHP es producida ahora por
The PHP Group y sirve como el estándar de facto para PHP al no haber una especificación
formal. Publicado bajo la PHP License, la Free Software Foundation considera esta licencia
como software libre.

PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas

operativos, tales como UNIX (y de ese tipo, como Linux o Mac Os) y Windows, y puede
interactuar con los servidores de web más populares ya que existe en versión CGI, modulo
para apache, e ISAPI.

34
2.7.3 Apache Tomcat

Tomcat es el servidor web más utilizado a la hora de trabajar con java en entornos
web; es una implementación completamente funcional de los estándares de JSP y Servlets.
Tomcat también puede especificarse como el manejador de las peticiones JSP y Servlets
recibidas por servidores Web populares, como el servidor Apache HTTP de la fundación de
software de Apache o el servidor Microsoft Internet Information Server (IIS). Está integrado
en la implementación de referencia Java 2 Enterprise Edition (J2EE) de Sun Microsystems.

Tomcat puede funcionar como servidor web por sí mismo. En sus inicios existió la
percepción de que el uso de Tomcat de forma autónoma era solo recomendable para
entornos de desarrollo y entornos con requisitos mínimos de velocidad y gestión de
transacciones. Hoy en día ya no existe percepción y Tomcat es usado como servidor web
autónomo en entornos con alto nivel de tráfico y alta disponibilidad.

Dado que Tomcat fue escrito en java, funciona en cualquier sistema operativo que
disponga de la máquina virtual java. Dentro de la última versión de Tomcat 7.x se puede
observar las siguientes mejoras.

 Implementado de Servlet 2.5 y JSP 2.1.

 Soporte para Unified Expression Language 2.1.
 Diseñado para funcionar en java SE 5.0 y posteriores.
 Soporte para Comet a través de la interfaz Cometprocessor.

2.7.4 Arc View 10

Arc View es la herramienta SIG más extendida en todo el mundo dadas sus
avanzadas capacidades de visualización, consulta y análisis de información geográfica,
además de las numerosas herramientas de integración de datos desde todo tipo de Fuentes y
herramientas de edición.

Por sí solo, Arc view permite la explotación de toda la información tanto en sistemas
mono usuario con en sistemas departamentales, pero es al integrarse en la arquitectura

35
ArcGis donde se consigue una solución global en el manejo de información geográfica y
escalable según las necesidades del usuario.

Arc View tiene el rango más grande de funcionalidad disponible, construido con una
interfaz del usuario grafica intuitiva, basada en Windows, Arc View es simple, fácil de usar
e incluye ayuda en línea excepcional y una extensa documentación. Arc View puede
personalizarse por diseñadores que usan los idiomas de la programación basados en los
estándares industriales [Machicado, 2004]

Características de Arc View

Calidad del Mapeo:

Usando una extensa colección de elementos del mapa Arc View más que un simple
sistema de mapeo, puede usarse para crear los mapas topográficos y temáticos de alta calidad
para la publicación. Permite ahorrar tiempo y puede crear un estilo consisten en los mapas
usando una lista predefinida de plantillas. Mapas completados pueden imprimirse,
exportarlos. Salvarlos e incluirlos en otras aplicaciones

Manejo y uso de datos extensos:

Arc View lo hace más fácil de integrar con todos los tipos de datos para la
visualización, cartografía, consulta y análisis. Arc View abrió el camino a la habilidad de
leer directamente de los datos más de una década. Es un sistema de integración universal,
Varias herramientas también son incluidas en Arc View para crear, manejar y organizar
datos geográficos, tabulares y metadatos.

Una colección rica de herramientas:

Para edición hacen al Arc View mantiene un ambiente rico en la captura y revisión
de datos. Arc View es un solo, integra una aplicación que puede usarse para todos los
aspectos de un proyecto GIS (captura, mantenimiento, integración, análisis, cartografía y
visualización de los datos).

36
El análisis y geo procesamiento espacial

Con Arc View incluye un juego de análisis del mapa con una herramienta y
procedimientos que lo ayudan a analizar la información geográfica evaluando la
conveniencia y la capacidad, mientras estima y predice e interpreta y entiende la información
espacial.

Personalización de la interfaz del usuario

Fácilmente creando o modificando las barras de herramientas agregando y quitando

botones y artículos del menú.

Alternativamente. Arc View incluye el elemento esencial visual para las aplicaciones
para las personalizaciones del código Fuente. Finalmente, diseñadores pueden usar cualquier
idioma de desarrollo normal como C++, NET. O VB para crear herramientas personalizadas
como aplicaciones, o nuevas funcionalidades.

Funcionalidades

Tales como tener una arquitectura abierta que no se encuentra ligada a una
plataforma específica de hardware pueden ser ejecutados sin problemas en las diferentes
plataformas comerciales disponibles en el mercado, tanto en una PC bajo NT como en
estación de trabajo sistemas UNIX, sin perder funcionalidad, ya que cuenta con la misma
interface y herramientas de trabajo en ambos entornos.

En particular Arc View permite realizar las siguientes funciones:

 Explorar y administra la información geográfica y alfanumérica en múltiples

formatos.
 Visualizar y consultar la información geográfica y alfanumérica.
 Crear y mantener los metadatos de la información catalogada.
 Crear el modelo de datos apropiado a las necesidades de cada usuario.
 Acceder de manera inmediata a servicios de internet a través del servidor de
aplicaciones Arc IMS.

37
2.8.- EVALUACION DE LA CALIDAD DE SISTEMA

Es una metodología cuantitativa para la evaluación y comparación de sitios Web,

cuyo autor es Luis Antonio Olsina. El objetivo es definir y discutir una metodología
cuantitativa, integral, robusta y flexible para la evaluación de la calidad en aplicaciones
centradas en las Web. Esta metodología pretende realizar un aporte a la ingeniería al
proponer un enfoque sistemático, disciplinado y cuantitativo que se adecue a la evaluación,
comparación y análisis de calidad de artefactos Web a menos complejos.

Las fases de la metodología y de los principales pasos y constructores de procesos

que son:

 Planificación y programación de la evaluación de calidad.

 Definición y especificaciones de requerimientos de calidad
 Definición e implementación de la evaluación elemental
 Definición e implementación de la evaluación global
 Validación de métricas

2.8.1 La planificación y programación de la evaluación

La misma contiene actividades procedimiento de soporte, con el fin de determinar

objetivos estratégicos tácticos y operativos. Esto permite establecer las principales
estrategias y metas del proceso en un contexto organizacional, permitiendo seleccionar un
modelo de proceso de evaluación, asignar métodos, agentes y recursos a las actividades.

2.8.2 Fase de definición y especificación de requerimientos de calidad

Trata de las actividades y modelos para la determinación, análisis y especificación de

los requerimientos, a partir de un proceso de medición orientado a metas, con el fin de
evaluar, comparar, analizar, mejorar características y atributos de la usabilidad de artefactos
Web, los requerimientos deben responder a necesidades y comportamientos de un perfil de
usuario y dominios dados.

38
 El proceso de determinación de requerimientos realizado en una mezcla de
estrategias prescriptivas, culmina con un documento (árbol de requerimientos) que
jerárquicamente específica a todas las características y atributos cuantificables que modelas a
la calidad según las necesidades del usuario.

X1
Evaluacion y
Selección del F(X1) IE1
Características y atributos del
comparacion
dominio 100 Web
árbol de requerimientos

Preferencia de calidad
Variables de calidad
% Sn

Criterio elemental
Web S2

Elemental
Web S1, S2,.. Sn IG - Sistema
G(IE1, … , 50% Web S1
METAS IEn)
Preferencia
Puntos de vista Global 0% Web S0
del usuario Ranking Final de
los artefactos
F(Xn) IEn
Xn web
Definición y especificación Evaluación Elemental Evaluación Global definición e
de requerimientos definición e implementación implementación
Figura 10 Principales módulos en el proceso evaluación y comparación usando web-site
QEM

Fuente: [Olsina 1999]

La siguiente tabla muestra el árbol de requerimientos de calidad donde se especifican

las características de usabilidad, funcionalidad, confiabilidad y eficiencia.

1. Usabilidad 2. Funcionalidad

1.1 Comprensibilidad Global del Sitio 2.1 Aspectos de Búsqueda y Recuperación

1.1.1 Esquema de Organización Global 2.1.1 Mecanismo de Búsqueda en el Sitio Web
1.1.1.1 Mapa del Sitio 2.1.1.1 Búsqueda Restringida
1.1.1.2 Tabla de Contenidos 2.1.1.1.1 de Personas
1.1.1.3 Índice Alfabético 2.1.1.1.2 de Cursos
1.1.2 Calidad en el Sistema de Etiquetado 2.1.1.1.3 de Unidades Académicas

39
1.1.3 Visita Guiada Orientada al Estudiante 2.1.1.2 Búsqueda Global
1.1.4 Mapa de Imagen (Campus/Edificio 2.1.2 Mecanismos de Recuperación
1.2 Mecanismos de Ayuda y retroalimentación 2.1.2.1 Nivel de Personalización
en línea 2.1.2.2 Nivel de Retroalimentación en la Recuperación
1.2.1 Calidad de la Ayuda 2.2 Aspectos de Navegación y Exploración
1.2.1.1 Ayuda Explicatoria Orientada al 2.2.1 Navegabilidad
Estudiante 2.2.1.1 Orientación
1.2.1.2 Ayuda de la Búsqueda 2.2.1.1.1 Indicador del Camino
1.2.2 Indicador de Ultima Actualización 2.2.1.1.2 Etiqueta de la Posición Actual
1.2.2.1 Global (de todo el sitio Web)
2.2.1.2 Promedio de Enlaces por Página
1.2.2.2 Restringido (por subsitio o página) 2.2.2 Objetos de Control Navegacional
1.2.3 Directorio de Direcciones 2.2.2.1 Permanencia y Estabilidad en la
1.2.3.1 Directorio E-mail Presentación de los Controles Contextuales (Subsitio)
1.2.3.2 Directorio TE-Fax 2.2.2.1.1 Permanencia de los Controles Contextuales
1.2.3.3 Directorio Correo Postal 2.2.2.1.2 Estabilidad
1.2.4 Facilidad FAQ .2.2.2 Nivel de Desplazamiento
1.2.5 Retroalimentación 2.2.2.2.1 Desplazamiento Vertical
1.2.5.1 Cuestionario 2.2.2.2.2 Desplazamiento Horizontal
1.2.5.2 Libro de Invitados 2.2.3 Predicción Navegacional
1.2.5.3 Comentarios/Sugerencias 2.2.3.1 Enlace con Título (enlace con texto explica
1.3 Aspectos de Interfaces y Estéticos torio)
1.3.1 Cohesividad al Agrupar los Objetos de 2.2.3.2 Calidad de la Frase del Enlace
Control Principales 2.3 Aspectos del Dominio orientados al Estudiante
1.3.2 Permanencia y Estabilidad en la 2.3.1 Relevancia de Contenido
Presentación de los Controles Principales 2.3.1.1 Información de Unidad Académica
1.3.2.1 Permanencia de Controles Directos 2.3.1.1.1 Indice de las Unidades
1.3.2.2 Permanencia de Controles Indirectos 2.3.1.1.2 Sub-sitios de las Unidades
1.3.2.3 Estabilidad 2.3.1.2 Información de Inscripción
1.3.3 Aspectos de Estilo 2.3.1.2.1Información de los Requerimientos de
Ingreso/Admisión
1.3.3.1 Uniformidad en el Color de Enlaces
2.3.1.2.2 Formulario para Rellenar/Bajar
1.3.3.2 Uniformidad en el Estilo Global
2.3.1.3 Información de Carreras
1.3.3.3 Guía de Estilo Global
2.3.1.3.1 Índice de Carreras

40
1.3.4 Preferencia Estética 2.3.1.3.2 Descripción de Carrera
1.4 Misceláneas 2.3.1.3.3 Plan de Carrera/Oferta de Cursos
1.4.1 Soporte a Lenguaje Extranjero 2.3.1.3.4 Descripción de Cursos
1.4.2 Atributo “Qué es lo Nuevo 2.3.1.3.4.1 Comentarios
1.4.3 Indicador de Resolución de Pantalla 2.3.1.3.4.2 Programa.
3. Confiabilidad 2.3.1.3.4.3 Programación Cursos
3.1 No Deficiencia 2.3.1.4 Información de Servicios al Estudiante
3.1.1 Errores de Enlaces 2.3.1.4.1 Indice de Servicios
3.1.1.1 Enlaces Rotos 2.3.1.4.2 Información de Salud
3.1.1.2 Enlaces Inválidos 2.3.1.4.3 Información de Becas
3.1.1.3 Enlaces no Implementados 2.3.1.4.4 Información de Residencias
3.1.2 Errores o Deficiencias Varias 2.3.1.4.5 Información Cultural/Deport.
3.1.2.1 Deficiencias o cualidades ausentes 2.3.1.5 Información de Infraestructura Académica
debido a diferentes navegadores (browsers) 2.3.1.5.1 Información de Bibliotecas
3.1.2.2 Deficiencias o resultados 2.3.1.5.2 Información de Laboratorios
inesperados independientes de browsers 2.3.1.5.3 Información Resultados I+D
(p.ej. errores de búsqueda imprevistos, 2.3.2 Servicios On-line
Deficiencias con marcos (frames), etc.) 2.3.2.1 Información Aranceles, Aprobación de Cursos.
3.1.2.3 Nodos Destinos (inesperadamente) 2.3.2.2 Servicio de Páginas Web
en Construcción 2.3.2.3 Servicio FTP
3.1.2.4 Nodos Web Muertos (sin enlaces de 2.3.2.4 Servicio de Grupo de Noticias
retorno) 4. Eficiencia
4.1 Performancia
4.1.1 Páginas de Acceso Rápido
4.2 Accesibilidad
4.2.1 Accesibilidad de Información
4.2.1.1 Soporte a Versión sólo Texto
4.2.1.2 Legibilidad al desactivar la
Propiedad Imagen del Browser
4.2.1.2.1 Imagen con Título
4.2.1.2.2 Legibilidad Global
4.2.2 Accesibilidad de Ventanas

41
 4.2.2.1 Número de Vistas considerando Marcos (frames)
4.2.2.2 Versión sin Marcos

Tabla 5 Arbol de requerimientos de calidad

Fuente: [Olsina 1999]

2.8.3 Fase de Definición e Implementación de la Evaluación Elemental

Esta fase trata de actividades, modelos, técnicas y herramientas para determinar

métricas y criterios de evaluación para cada atributo cuantificable, se consideran tipos de
criterios elementales, escalas de preferencia, valores críticos y funciones para determinar la
preferencia elemental, entre otros asuntos.

Una vez definidos y consensuados los criterios para medir cada atributo se debe
ejecutar el proceso de recolección de datos, computar las métricas, preferencias elementales
y documentar los resultados.

Criterios de la Evaluación Elemental para Atributos

Para cada atributo cuantificable Ai (u hoja del árbol) debemos asociar y determinar
una variable xi, que tomara un valor real a partir de un proceso de medición (la métrica debe
ser válida). Además, para cada variable xi computada, por medio de un criterio elemental,
producirá una preferencia elemental IEi, este resultado final, elemental, se puede interpretar
como el grado o porcentaje del requerimiento del usuario satisfecho para el atributo Ai. Un
criterio de evaluación elemental ayuda a comprender y especificar como medir atributos
cuantificables, de manera que por medio de un proceso de agregación podamos obtener un
valor numérico global para el producto y evaluar (y que denominaremos la preferencia de
calidad global del producto).

Para cada variable de calidad medica xi, i=1,…n se define una función que representa
al criterio elemental.

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

Xi = Ri ᶓ R

El valor de la preferencia de calidad elemental es también un número real pero

perteneciente al intervalo unitario I, de manera que:

IEi I, i = 1,.., n , I = [0, 1]

En una interpretación rigurosa la preferencia elemental de calidad es el grado de

verdad en la declaración que afirma “el valor de la variable de calidad X satisface
completamente el requerimiento de calidad del i-ésimo criterio elemental”.

Consecuentemente, la preferencia de calidad elemental representa el grado de

satisfacción de un requerimiento o necesidad de usuario. Con frecuencia, en vez de usar el
intervalo unitario es útil emplear la escala porcentual de [0, 100%]. En este sentido se
interpreta a la preferencia como el porcentaje del requerimiento satisfecho. Desde un punto
de vista analítico, el criterio elemental se define como la función:

Fi = Ri ᶓ I en donde IEi = Fi (Xi), Xi min <=Xi <= Xi max

Sea el tiempo ti que representa el tiempo de respuesta promedio (por ejemplo, el

tiempo de respuesta promedio necesitado por el sistema para realizar un tipo de consulta a
una base de datos). Entonces, el criterio elemental para dicho atributo puede ser definido
como:

2.8.4 Representación Notacional de los Criterios

Se pueden identificar al menos cuatro tipos diferentes de notaciones para representar

a los criterios elementales que son los siguientes.

 Notación gráfica (de líneas, barras, etc.)

 Notación en escala de preferencia

43
  Notación de los puntos de coordenadas relevantes
 Notación analítica

2.8.5 Tipos de Criterios de Preferencia de Calidad Elemental

Como indicábamos anteriormente, la elección del tipo de criterio de evaluación

elemental resulta de importancia en consideración de los niveles de precisión, objetividad y
facilidad de uso. El nivel de precisión depende del grado de criticidad de alguno o de todos
los componentes del producto en un proyecto de evaluación.

Dos tipos básicos de criterios elementales son los absolutos y los relativos, dentro de
los primeros se pueden descomponer en criterios con variables continuas, y criterios con
variables discretas.

Un criterio de evaluación elemental absoluto es aquél que se emplea para determinar

la preferencia absoluta de un atributo de un artefacto, y que no está relacionado con
indicadores de otros sistemas comparativos. Un criterio absoluto se diferencia de uno
relativo en que la meta de este último consiste solamente en la determinación de los
indicadores relativos de los sistemas comparados sin evaluar la calidad (o la característica
que corresponda) de cada sistema de un modo individual e independiente.

Por lo tanto, una comparación relativa entre sistemas produce un orden o ranking
relativo, que no puede ser interpretado individualmente dado que no representan el grado de
cumplimiento de los requerimientos absolutos.

1. Criterio de Variable Única

CRITERIO
2. Criterio de Variable Normalizada
ELEMENTAL
3. Criterio Multi-Variable
CRITERIO 4. Criterio de Preferencia Directa
ELEMENTAL 5. Criterio Binario
6. Criterio Multi-Nivel
CRITERIO CRITERIO
7. Criterio Multi-Nivel definido como
ELEMENTAL ELEMENTAL
Subconjunto
CRITERIO
8. Criterio Multi-Variable
ELEMENTAL
9. Criterio Multi de variable única
10. Criterio de Variable Normalizada
11. Criterio estadístico

Figura 11 Taxonomía de tipos criterios elementales

Fuente: [Olsina, 1999]

44
 Un criterio de evaluación elemental absoluto que se emplea para determinar la
preferencia absoluta de un atributo de un artefacto, y que no está relacionado con indicadores
de otros sistemas comparativos.

Un criterio absoluto se diferencia de uno relativo en que la meta de este último

consiste solamente en la determinación de los indicadores relativos de los sistemas
comparados sin evaluar la calidad (o la característica que corresponda) de cada sistema de un
modo individual e independiente.

2.8.6 Fase de Evaluación Global

En la fase de Definición e Implementación de la Evaluación Global se trata con

actividades, modelos, procedimientos y herramientas para determinar los criterios de
agregación de las preferencias de calidad elemental (obtenidas en la fase anterior, a partir del
árbol de requerimientos), para producir la preferencia global para cada sistema de
información interviniente.

Se consideran 17 tipos de funciones lógicas de agregación (que representan

diferentes niveles de polarización “y/o”), para modelar diferentes relaciones entre atributos y
características, como por ejemplo, relaciones de reemplazabilidad, simultaneidad,
neutralidad, simétricas y asimétricas. Al final del proceso se obtiene un valor numérico real
(entre 0 y 100), y se establece un grado entre los sistemas evaluados. A este valor lo
denominamos el indicador de calidad global IGi para el i-ésimo sistema evaluado.

X1 F(X1) IE1
Preferencia de calidad
Variables de calidad

Criterio elemental

Elemental

IG - Sistema
G(IE1, … , IEn)
Preferencia
Global

Xn F(Xn) IEn

Evaluación Elemental Evaluacion Global

Figura 12 Esquema que representa la obtención de la Calidad Global para cada Sistema
Seleccionado a partir de los Indicadores Elementales

Fuente: [Olsina 1999]

45
 Observando el esquema de la figura 12, para n variables asociadas a n atributos
directa o indirectamente cuantificables, la correspondiente función elemental produce n
indicadores o preferencias elementales. Seguidamente, aplicando un mecanismo de
agregación (o composición) paso a paso, las preferencias elementales se pueden agrupar
convenientemente para producir finalmente el indicador o preferencia global. La referencia
de calidad global representa el grado de satisfacción de todos los requerimientos de calidad
explícitos e implícitos.

2.8.7 El Modelo de Agregación Lógica de Preferencias.

Uno de los objetivos de la metodología propuesta Web-site QEM, era el de utilizar

para esta fase, y en consideración de la cantidad de características y atributos intervinientes
en el proceso de evaluación de sitios Web, un modelo de agregación y cálculo existente que
favoreciera a un proceso de evaluación flexible, estructurado, y con fundamentación y
objetividad científica, de manera que proporcionara indicadores de calidad cuantitativos que
pudieran ser usados como base y justificación de las decisiones más óptimas.

El modelo de agregación de atributos, sub características y características (y el

procedimiento de cálculo) basado en LSP es precisamente bien organizado, estructurado,
cuantitativo y robusto. Básicamente, entre las características generales de LSP, podemos
enumerar:

 Es un modelo de agregación y puntaje para evaluar sistemas complejos (el artefacto

consiste de un buen número de subsistemas o componentes, los que a su vez se
descomponen en varios elementos; asimismo, existen diversos tipos de relaciones
entre elementos y subsistemas).
 Sus resultados representan el grado de satisfacción de los usuarios conforme a los
requerimientos de calidad establecidos (la preferencia de calidad del usuario respecto
del producto).
 Es una generalización de los modelos y técnicas de puntaje aditivos y lineales Tiene
sus fundamentos en principios, modelos matemáticos y lógica.

46
2.8.8 Análisis de Resultado, Conclusiones y Documentación

En esta fase se realizan actividades de análisis y comparación de las preferencias de

calidades elementales, parciales, globales y de la misma forma, la justificación de los
resultados. A partir de las metas establecidas y el punto de vista de usuario a evaluar el
proceso culmina con las conclusiones y recomendaciones del caso. Por otra parte. Se utilizan
herramientas y mecanismos de análisis y documentación para facilitar la interpretación de
los datos, su seguimiento y registración.

A continuación podemos mencionar el rango de aceptación del modelo de calidad:

Satisfactorio (%) 60<IE<=100

Insatisfactorio (%) 0 <IE<=40

Marginal (%) 40<IE<=60

Figura 13 Rango de Aceptación de Calidad

Fuente: [Olsina, 1999]

2.9 COSTO BENEFICIO

2.9.1 Cocomo

El modelo provechoso de Costes (COCOMO, por su acrónimo del inglés

COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para
estimación de costes de software. Incluye tres modelos, cada uno ofrece un nivel de

47
 detalle y aproximación, cada vez mayor a medida que avanza el proceso de desarrollo del
software: básico, intermedio y detallado.

Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y a
comienzos de los 80, exponiéndolo detalladamente en su libro “Software Enginering
Economics. [Prentice – hall, 1981].

Pertenece a la categoría de modelos de subestimaciones basados en estimaciones

matemáticas. Está orientado a la magnitud del producto final, midiendo el “tamaño” del
proyecto, en líneas de código principalmente.

2.9.2 Inconvenientes

 Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta
los recursos necesarios para realizarlas.
 Se puede desviar de la realidad si se indica mal el porcentaje de líneas de
comentarios en el código Fuente.
 Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que usen
el método.
 Se miden los costes del producto de acuerdo a su tamaño y otras características, pero
no la productividad.
 La medición por líneas de código no es válida para orientación a objetos.
 Utilizar este modelo puede resultar un poco complicado en comparación con otros
métodos (que también solo estiman).

2.9.3 Atributos

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo –

bajo – nominal – extremadamente alto. Dependiendo de la calificación de cada atributo,
se asigna un valor para usar de multiplicador en la formula (por ejemplo, si para un proyecto
el atributo DATA es calificado como muy alto, el resultado de la formula deber ser
multiplicado por 1000). El valor de cada estimación es de acuerdo a su calificación, se
muestra en la siguiente tabla.

48
 VALOR
ATRIBUTO Muy Muy Extra
bajo Bajo Nominal Alto alto alto
Atributo de software
Fiabilidad 0.01 0.10 1.00 1.15 1.40
Tamaño de base de datos 0.94 1.00 1.08 1.16
Complejidad 0.70 0.85 1.00 1.15 1.30 1.65
Atributos de hardware
Restricciones de tiempo de ejecución 1.00 1.11 1.30 1.66
Restricciones de memoria virtual 1.00 1.06 1.21 1.56
Volatilidad de la máquina virtual 0.87 1.00 1.15 1.30
Tiempo de respuesta 0.87 1.00 1.07 1.15
Atributos de personal
Capacidad de análisis 1.46 1.19 1.00 0.86 0.71
Experiencia en la aplicación 1.29 1.13 1.00 0.91 0.82
Calidad de los programadores 1.42 1.17 1.00 0.86 0.70
Experiencia en la máquina virtual 1.21 1.10 1.00 0.90
Experiencia en el lenguaje 1.14 1.07 1.00 0.95
Atributos del proyecto
Técnicas actualizadas de
programación 1.24 1.10 1.00 0.91 0.82
Utilización de herramientas de
software 1.24 1.10 1.00 0.91 0.83
Restricciones de tiempo de desarrollo 1.22 1.08 1.00 1.04 1.10

Tabla 6 Modelo Constructivo de Costes

Fuente: [Prentice – hall, 1981]

2.9.4 Modelo Detallado

Presenta principalmente dos mejoras respecto al anterior:

 Los factores correspondientes a los atributos son sensibles o dependientes de la fase

sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la
aplicación, utilización de herramientas de software, etc., tiene mayor influencia en
unas fases que en otras, y además van variando de una etapa a otra.
 Establece una jerarquía de tres niveles de productos, de forma que los aspectos que
representan gran variación a bajo nivel, se consideran a nivel modulo, los que

49
 representan pocas variaciones, a nivel de subsistema: y los restantes son considerados
a nivel sistema.

Modelo detallado COCOMO II es usado para:

a. Hacer inversiones o tomar otras decisiones financieras que involucren esfuerzo de

desarrollo de software.
b. Establecer presupuesto y calendarios de proyectos como base para la planificación y
el control.
c. Decidir o negociar entre los costos de software, calendario, funcionalidad,
rendimiento o factores de calidad.
d. Tomar decisiones sobre el costo de software y el manejo de riesgo del calendario.
e. Decidir que partes del sistema software de desarrollar, reutilizaran, subcontrataran o
compraran.
f. Tomar decisiones sobre el software existente que partes se va modificar o incluso
suprimir.

Los objetivos del modelo COCOMO II son

a) Promover estimaciones de costos y calendario precisos tanto para los proyectos

actuales como futuros.
b) Promocionar definiciones cuidadosas y fáciles de comprender de las entradas salidas
del modelo.
c) Promocionar un modelo normativo, que permite distribuir los recursos necesarios
para el desarrollo o mantenimiento efectivo del software.

El esfuerzo se calcula con la siguiente ecuación:

Esfuerzo = A x tamañoE x (πmultiplicador) (1)

Donde E = B + 0.01 x (∑Factor) (2)

Los valores se muestran en la tabla 7

50
 SIMBOLO DESCRIPCION

A Coeficiente de esfuerzo calibrado en 2.94

B Base del exponente de escalamiento, calibrado en 0.91

Tamaño Medida del software en líneas de código Fuente

E Exponente de escalamiento de tipo de proyecto

Multiplicador 17 multiplicadores de esfuerzo

Factor 5 factores

Esfuerzo Esfuerzo del proyecto en meses – persona

Tabla 7 Valores del modelo COCOMO II
Fuente: Modelo COCOMO II IS 101

Los valores del proyecto se calculan con la siguiente ecuación:

TDEV = [ C x esfuerzoF] x [SCED% 100] (3)

Donde F= D0.2 x (E-B) (4)

Los valores de calibrado del modelo COCOMO II se ve en la tabla 8

SIMBOLO DESCRIPCION

B Base del exponente de escalamiento, calibrado en 0.91

C Coeficiente de esfuerzo calibrado en 3.67

D Exponente de escalamiento de tipo de proyecto, utilizando en la

ecuación de esfuerzo

E Exponente de escalamiento de tipo de proyecto utilizado en la

ecuación de esfuerzo

F 5 factores

Esfuerzo Exponente de escalamiento para planificación

Tabla 8 Valores de calibrado del modelo COCOMO II
Fuente: Modelo COCOMO II IS 101

51
Factores de escala
Los factores de escala se utilizan para el cálculo de exponente en la ecuación (1).

Precedentes: Muestra la experiencia previa de la organización desarrolladora con respecto

al tipo de proyectos. Muy bajo significa sin experiencia previa, Extracto alto significa que la
organización está completamente familiarizada con el dominio de la aplicación.

Flexibilidad de desarrollo: Expresa el grado de flexibilidad de proceso de desarrollo. Muy

bajo significa que se utiliza un proceso prescrito por ejemplo. Uso de determinados técnicas,
etapa, actividades o procesos. Extra alto significa que el cliente establece solo metas
generales y los desarrolladores toman decisiones sobre cómo llevar a cabo el proyecto y que
técnicas usar en cada momento.

Arquitectura/Solución de riesgo: Expresa el alcance de análisis de riesgo que se llevar a

cabo. Muy bajo significa que se requieres de poco análisis.

Extracto alto significa que es indispensable un análisis de riesgo completo y muy detallado

Cohesión del equipo/interacción: Expresa el nivel de conocimiento de los miembros del

equipo de desarrollo entre si y como trabajan juntos. Muy bajo significa que las
interacciones podrían ser muy difíciles. Extra alto significa un equipo integrado y efectivo
sin problemas de comunicaciones.

Madurez del proceso: Expresa la madurez del proceso de la institución.

2.9.5 Multiplicadores de esfuerzo

Los multiplicadores se esfuerzo son usados para precisar la estimación inicial de

esfuerzo. Se clasifican en cuatro grandes grupos y cada multiplicador es definido por un
conjunto de niveles en los cuales se establecen determinados valores para la estimación final
los cuales son producto, plataforma, personal y proyecto.

Producto se refiere a los factores del producto considerados en la variación del

esfuerzo requerido para el desarrollar el software, y que es causado por las características del

52
producto mismo. Hay cinco factores de producto y su complejidad tiene una fuerte
influencia en estimación del esfuerzo los cuales son:

RELY: Garantía de funcionamiento requerida al software. Indica las posibles consecuencias

para el usuario en el caso que existan defectos en el producto. Va desde la sola
inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas
(extremadamente alto, software de alta criticidad)

DATA: Tamaño de la base de datos en relación con el tamaño del programa. El valor del
modificador se define por la relación: DIK, donde D corresponde al tamaño de la base de
datos en Byte y K es el tamaño del programa en cantidad de líneas de código.

CPLX : Representa la complejidad del producto.

 De hardware

TIME: limitaciones en el porcentaje del uso de la CPU

STOR: limitaciones en el porcentaje del uso de la memoria

VIRT: volatilidad de la máquina virtual

TURN: tiempo de respuesta requerido

 De personal

ACAP: calificación de los analistas.

AEXP: experiencia del personal en aplicaciones similares.

PCAP: calificación de los programadores

VEXP: experiencia del personal en la máquina virtual

LEXP: experiencia en el lenguaje de programación a usar.

 De proyecto

53
MODP: uso de prácticas modernas de programación

TOOL: uso de herramientas de desarrollo de software

SCED: limitaciones en el cumplimiento de la planificación

54
CAPITULO 3

MARCO APLICATIVO

3.1 INTRODUCCION

El propósito de este capítulo es poner en práctica la metodología propuesta para la

construcción del Sistema de Información Geográfica del Municipio de Huatajata
denominada OOHDM (Hipermedia Design Method Oriented Objects).

El propósito del presente sistema es el de optimizar y mejorar la planificación

catastral del municipio de Huatajata ya que no existe aún todavía información relacionado al
mismo.

3.2. SISTEMA ACTUAL

En el momento la Dirección de Catastro realiza muy poco sus tareas referidas a sus
funciones debido a que cuenta con muy poca información relacionada a esta área, está en
plena formación del departamento, no cuenta con ningún dato referidas a la cartografía del
municipio, su principal preocupación de momento es el de contar con planos de la
comunidad para realizar los proyectos inherentes a la entidad. Podemos mencionar que la
Alcaldía está realizando un convenio con la escuela de topografía para el levantamiento del
mapa del Municipio. Esta dirección ya cuenta con el siguiente personal:

Responsable de Planificación Urbana proyectos y Catastro: Tiene la función de

elaborar la cartografía urbana del municipio, planificar los proyectos estratégicos que
requiere la comunidad a corto, mediano y largo plazo, registrar los predios de equipamiento
con que cuenta el municipio.

Responsable de Desarrollo Agropecuario Mejoramiento Genético: Su trabajo es

el de apoyar a los productores con capacitación que los impulse al mejoramiento de su
producción.

55
 Encargado de Turismo y Promoción Municipal: Está encargado en la promoción
de los atractivos turísticos del municipio, con la realización de eventos que muestren las
bondades de la región.

3.3. ESPECIFICACION DE REQUERIMIENTOS

Por todo lo expuesto anteriormente es urgente que esta entidad cuente con una
herramienta de información geográfica del municipio. Este sistema de información detallara
como tal lo siguiente:

 Será un sitio que proporcionara información al usuario sobre el Municipio de

Huatajata.
 El sistema deberá mostrar los proyectos elaborados, centros de equipamiento
y área verde del municipio, y su superficie.
 El sistema deberá mostrar las coordenadas en las que se encuentra cada
proyecto, equipamiento y área verde del municipio.
 El sistema deberá posibilitar la consulta de información de interés a usuarios
casuales.
 Realizar la búsqueda de información de forma gráfica y se visualice en el
mapa el resultado.
 El sistema deberá administrar el ingreso de los diferentes tipos de usuarios.

3.4 ESPECIFICACION DE ACTORES Y TAREAS

Los actores que intervienen en el Sistema de Información Geográfico de Huatajata

son los siguientes:

1.- Administrador: Sera una persona encargada, de gestionar, siendo la única persona
encargada de autorizada para adicionar, eliminar, y modificar los registros de información
del Sistema de Información Geográfica de Huatajata. Estará encargado de las siguientes
tareas:

 Administrar Usuarios

56
  Administrar mapas
 Administrar proyectos
 Administrar noticias

2.- Editor: Es un usuario registrado para tener acceso al sistema y realizar las siguientes
modificaciones de adición, eliminación y edición en los siguientes módulos:

 Administrar mapas
 Administrar proyectos
 Administrar noticias

3.- Usuario Experto: Es un usuario similar al anterior para tener acceso al sistema y
realizar las tareas de modificaciones de adición, eliminación y edición en los siguientes
módulos:

 Administrar mapas
 Administrar proyectos
 Administrar noticias

4.- Usuario Casual: Sera una persona que se encuentre navegando por la web del sitio,
accediendo a la funcionalidad mínima del sistema, que no implica la almacenar información,
modificar en el sistema. Podrá navegar por todos los links, pudiendo acceder a todos los
proyectos y visualizar la información permitida.

 Ver mapas
 Ver proyectos
 Ver noticias

3.5 DIAGRAMA PRINCIPAL DE CASO DE USO

Una vez definido a los actores que intervendrán, para detallar mejor todo lo
mencionado anteriormente recurriremos a los diagramas de caso de uso para explicar
gráficamente lo que deseamos elaborar en el Sistema.

57
 Administra Valida
usuarios usuarios

Elimina mapa
Visualiza
mapas

Busca por
Administra nombre
Administrador mapas

Adiciona un
mapa

Adiciona
proyecto

Administra
proyectos Elimina
proyecto usuario

Visualiza
Editor proyecto

adiciona
noticia

Administra modifica
noticias noticia

Elimina
Usuario experto noticia

Lee
noticia

Figura 14 Diagrama de caso general

Fuente: Elaboración propia

58
3.5.1 Descripción de Sub Casos de Uso

Caso de uso: Validar Usuario

Actores: Administrador
Resumen: Es realizado por el encargado del programa y este proceso se realiza
mediante el usuario y contraseña del usuario los cuales son verificados por el sistema
Tipo: Primario de mucha importancia
Precondiciones: El usuario debe estar debidamente registrado
Extiende: Administración de usuario y asignación de privilegios
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa su usuario y 1.- Se despliega una pantalla de ingreso al
contraseña para ingresar al sistema. sistema.
2.- El sistema realiza una verificación de los
datos.
3.- Se presenta el menú de opciones según el
tipo de usuario. En este caso administrador.
Excepciones:
5.- Si los datos no son correctos, el sistema no
ingresa mientras no sea el correcto.

Tabla 9 Sub caso de uso administrar usuarios

Fuente: Elaboración propia

Administrar Usuarios

registrar usuario

modificar usuario validar usuario

Administrador

eliminar usuario

Figura 15 Diagrama sub caso administra usuarios

Fuente: Elaboración propia

59
Caso de uso: Registrar Usuario
Actores: Administrador
Resumen: El administrador realiza la adición de datos de los diferentes usuarios según
sus privilegios
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa su usuario y 2.-El sistema despliega una pantalla para
contraseña de manera correcta. Propósito introducir los datos del nuevo usuario.
registrar usuario. 5.- El sistema verifica si todos los datos son
3.-El administrador digita los datos del introducidos.
usuario en el sistema. 6.-El sistema guarda los datos del nuevo
4.- El Administrador selecciona guardar usuario.
datos.
Excepciones:
6.- El administrador se salta algunos 6.- El sistema muestra un mensaje de aviso de
campos. advertencia.

Tabla 10 Sub caso de uso registrar usuarios

Fuente: Elaboración propia

Caso de uso: Modificar Usuarios

Actores: Administrador
Resumen: El administrador cambia los datos de los usuarios a petición
de este, cambiar tipo de privilegio o dar de baja a un usuario
Tipo: Primario de mucha importancia
Precondiciones: iniciar el sistema e ingresar para dicho propósito se deberá realizar la
verificación de datos
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores Respuesta del sistema
1.- El administrador ingresa al sistema, 2.- El sistema despliega una pantalla con los
con el propósito de modificar datos, datos del usuario.
cambiar privilegio o eliminar usuario. 4.-El sistema modifica, cambia privilegio o
3.- El administrador realiza cualquier de elimina usuario.
las acciones anteriores y presiona
guardar.

Tabla 11 Sub caso de uso modificar usuarios

Fuente: Elaboración propia

60
Caso de uso: Elimina Usuario
Actores: Administrador
Resumen: El administrador elimina los datos de los usuarios
Tipo: Primario de mucha importancia
Precondiciones: iniciar el sistema e ingresar para dicho propósito se deberá realizar la
verificación de datos
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores Respuesta del sistema
1.- El administrador ingresa al sistema, 2.- El sistema despliega una lista de los
con el propósito de eliminar datos usuarios.
usuario. 4.-El sistema elimina usuario.
3.- El administrador selecciona usuario y
presiona eliminar.

Tabla 12 Sub caso de uso modificar usuarios

Fuente: Elaboración propia

Administrar Proyecto

Adiciona un
proyecto
Ubica en mapa

Modifica un
Administrador proyecto
Editor
quitar de mapa
Usuario experto

Elimina un proyecto

Visualiza proyectos

usuario

Figura 16 Diagrama de sub caso administrar proyectos

Fuente: Elaboración propia

61
Caso de uso: Adición de proyecto
Actores: Administrador
Resumen: El administrador realiza la adición de datos de un nuevo proyecto
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema 2.-El sistema despliega una pantalla para
de manera correcta. Propósito registrar introducir los datos del nuevo proyecto.
un nuevo proyecto. 4.- El sistema verifica si todos los datos son
3.-El administrador digita los datos del introducidos.
nuevo proyecto en el sistema. Luego 5.-El sistema guarda los datos del nuevo
presiona adicionar. proyecto.
Excepciones:
6.- El administrador se salta algunos 7.- El sistema muestra un mensaje de aviso
campos. de advertencia.

Tabla 13 Sub caso de uso adiciona proyecto

Fuente: Elaboración propia

Caso de uso: Modificación de proyecto

Actores: Administrador
Resumen: El administrador realiza la modificación de datos de un proyecto
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema de 2.-El sistema despliega una lista de proyectos
manera correcta. Propósito modifica un en pantalla para ser modificados.
proyecto 4.- El sistema nos muestra todos los datos del
3.-El administrador debe seleccionar el proyecto a ser modificado.
proyecto que desea modificar. 6.-El sistema guarda los datos del proyecto
5.- El administrador puede modificar modificado.
datos del proyecto.
Excepciones:
7.- El sistema da advertencia

Tabla 14 Sub caso de uso modifica proyecto

Fuente: Elaboración propia

62
Caso de uso: Elimina proyecto
Actores: Administrador
Resumen: El administrador realiza la eliminación de un proyecto
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema de 2.-El sistema nos muestra una lista de
manera correcta. Propósito eliminar un proyectos que pueden ser eliminados.
proyecto. 4.- El sistema nos da una advertencia.
3.-El administrador selecciona el proyecto 5.-El sistema elimina los datos del proyecto.
a ser eliminado.
Excepciones:
6.- El administrador se arrepiente de la 7.- El sistema nos da la posibilidad de
eliminación del proyecto. recuperar el proyecto eliminado.

Tabla 15 Sub caso de uso elimina proyecto

Fuente: Elaboración propia

Administrar mapas

Adiciona un mapa

Modifica mapa
Administrador
Editor
Usuario experto

Elimina mapa

usuario

Visualiza un mapa

Figura 17 Diagrama de sub caso administrar mapas

Fuente: Elaboración propia

63
Caso de uso: Adición de mapa
Actores: Administrador
Resumen: El administrador realiza la adición de datos de un mapa
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema 2.-El sistema despliega una pantalla para
de manera correcta. Propósito registrar introducir los datos del nuevo mapa.
un mapa. 4.- El sistema verifica si todos los datos son
3.-El administrador digita los datos del introducidos.
nuevo mapa en el sistema. Luego 5.-El sistema guarda los datos del nuevo
presiona adicionar. proyecto.
Excepciones:
6.- El administrador se salta algunos 7.- El sistema muestra un mensaje de aviso
campos. de advertencia.

Tabla 16 Sub caso de uso adición de mapa

Fuente: Elaboración propia

Caso de uso: busca nombre

Actores: Administrador, editor, usuario experto, usuario casual
Resumen: Cualquier usuario busca mapa
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema correctamente
Extiende: no existe
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema 2.-El sistema visualiza el mapa del buscado.
de manera correcta. Propósito buscar
mapa

Tabla 17 Sub caso de uso busca mapa

Fuente: Elaboración propia

64
Caso de uso: Visualiza mapa
Actores: Administrador, editor, usuario experto, usuario casual
Resumen: Cualquier usuario visualiza mapa
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema correctamente
Extiende: no existe
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema 2.-El sistema nos muestra el mapa del
de manera correcta. Propósito visualizar municipio.
mapa

Tabla 18 Sub caso de uso visualiza mapa

Fuente: Elaboración propia

Administrar noticia

Adiciona noticia

Modifica noticia
Administrador
Editor
Usuario experto

usuario
Elimina noticia

Lee noticia

Figura 18 Diagrama de sub caso administra noticias

Fuente: Elaboración propia

65
Caso de uso: Adición de noticia
Actores: Administrador
Resumen: El administrador realiza la adición de datos de una noticia
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema 2.-El sistema despliega una pantalla para
de manera correcta. Propósito registrar introducir los datos noticia.
una noticia 4.- El sistema verifica si todos los datos son
3.-El administrador digita los datos del introducidos.
nuevo mapa en el sistema. Luego 5.-El sistema guarda los datos de noticia.
presiona adicionar

Tabla 19 Sub caso de uso adiciona noticia

Fuente: Elaboración propia

Caso de uso: Modificación noticia

Actores: Administrador
Resumen: El administrador realiza la modificación de datos noticia
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema de 2.-El sistema despliega una lista de noticias en
manera correcta. Propósito modifica una pantalla para ser modificados.
noticia 4.- El sistema nos muestra todos los datos de
3.-El administrador debe seleccionar la noticia a ser modificado.
noticia que desea modificar. 6.-El sistema guarda los datos de la noticia
5.- El administrador puede modificar modificado.
noticia.
Excepciones:
7.- El sistema muestra un mensaje de aviso de
advertencia.

Tabla 20 Sub caso de uso modifica noticia

Fuente: Elaboración propia

66
Caso de uso: Elimina noticia
Actores: Administrador
Resumen: El administrador realiza la eliminación de noticia
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema como administrador y habiendo sido validado
correctamente
Extiende: Validación de Usuario
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema de 2.-El sistema nos muestra una lista de noticias
manera correcta. Propósito eliminar que pueden ser eliminados.
noticia 4.- El sistema nos da una advertencia
3.-El administrador selecciona la noticia a 5.-El sistema elimina los datos de la noticia.
ser eliminado.
Excepciones:
6.- El administrador se arrepiente de la 7.- El sistema nos da la posibilidad de
eliminación de la noticia. recuperar noticia eliminada.

Tabla 21 Sub caso de uso elimina mapa

Fuente: Elaboración propia

Caso de uso: Visualiza noticia

Actores: Administrador, editor, usuario experto, usuario casual
Resumen: Cualquier usuario lee noticia
Tipo: Primario de mucha importancia
Precondiciones: Ingresar al sistema correctamente
Extiende: no existe
Curso normal de Eventos
Acción de los Actores: Respuesta del sistema
1.- El Administrador ingresa al sistema de 2.-El sistema nos muestra una lista de noticias
manera correcta. Propósito leer noticia que pueden ser leídos

Tabla 22 Sub caso de uso lee noticia

Fuente: Elaboración propia

67
3.6 ESPECIFICACION DE UID´s

OOHDM utiliza una herramienta llamada UID´s que nos permite representar en
forma rápida y sencilla los casos de uso representados anteriormente. Para obtener un UID´s
desde un caso de uso, la secuencia de información intercambiada entre el usuario y el
sistema debe ser identificada y organizada en las interacciones. Identificar la información de
intercambio es crucial ya que es la base para la definición de los UID´s

UID´s

Validar usuario

ingresa datos verifica datos pantalla

Figura 19 UID al caso de uso validar usuario

Fuente: Elaboración propia

UID´s

Registrar usuario

adicion de datos
validar datos guardar de datos
del usuario

Figura 20 UID al caso de uso registrar usuario

Fuente: Elaboración propia

UID´s

modificar usuario

buscar datos editar datos (nombre,

validar usuario desplegar datos
usuario contenido) y guardar

Figura 21 UID al caso de uso modificar usuario

Fuente: Elaboración propia

68
 UID´s

elimina usuario

valida datos lista de usuarios elimina usuario

Figura 22 UID al caso de uso eliminar usuario

Fuente: Elaboración propia

UID´s

Adicionar proyecto

llenar formulario guardar (nombre,

validar dato
(nombre, datos) datos)

Figura 23 UID al caso de uso adicionar proyecto

Fuente: Elaboración propia

UID´s

modificar proyecto

buscar nombre de editar datos (nombre,

validar usuario desplegar datos
proyecto contenido) y guardar

Figura 24 UID al caso de uso modificar proyecto

Fuente: Elaboración propia

UID´s

Eliminar proyecto

buscar nombre de
validar datos eliminar proyecto
proyecto

Figura 25 UID al caso de uso eliminar proyecto

Fuente: Elaboración propia

69
UID´s
Adicionar mapa

Llenar datos Guardar

Valida datos
(coordenas) corrdenadas

Figura 26 UID al caso de uso adición mapa

Fuente: Elaboración propia

UID´s
Busca nombre

busca
introduce datos Visualiza mapa
(coordenas)

Figura 27 UID al caso de uso busca nombre

Fuente: Elaboración propia

UID´s
visualiza mapa

Selecciona
Visualiza mapa
nombre

Figura 28 UID al caso de uso visualiza mapa

Fuente: Elaboración propia

70
 UID´s

Adicionar noticia

llenar formulario guardar (nombre,

validar dato
(nombre, datos) datos)

Figura 29 UID al caso de uso eliminar proyecto

Fuente: Elaboración propia

UID´s

modificar noticia

buscar titulo de editar datos (nombre,

validar usuario desplegar datos
noticia contenido) y guardar

Figura 30 UID al caso de uso eliminar proyecto

Fuente: Elaboración propia

UID´s

Eliminar noticia

buscar titulo
validar datos eliminar noticia
noticia

Figura 31 UID al caso de uso eliminar proyecto

Fuente: Elaboración propia

71
3.7 DISEÑO CONCEPTUAL

3.7.1 Diagrama de Clases

El diagrama de clases describe la estructura del sistema por medio delas clases,
atributos, sus operaciones y relaciones entre ellas. En la siguiente figura se representa el
modelo conceptual de entidad de clases que intervienen en el Municipio de Huatajata.

nivel
1 id:nivel:int(3)
nombre:char(20)
crear()
modificar()
eliminar()

funcionario
usuario -Id_funcionario : int(10)
id_usuario:int(6) -fe_regusuario : Date
nombre:char(20) 1 -nombre : char(20)
contraseña:char(20) -paterno : char(20)
nivel:int(6)
crear()
1 -materno : char(20)
-direccion : char(20)
modificar() -email : char(20)
eliminar() -telefono : int(8)
-foto : objec t
noticias
+crea()
-Id_noticia : int(10)
+modifica()
-titulo : Char(20)
+elimina() n
-contenido : char(50)
n
-fechapublicacion : Date
-responsable : char(20)
1
municipio
-fotonoticia : Object -Id_municipio : int(10)
+adicionar() -dimension : Date 1
+modificar() -ubicacion : char(20)
-nrohabitantes : char(20) ubicador
+eliminar() -id: int(10)
n -telefonomuni : char(20) Nombre:char(250)
-direccion : char(20) geom (point)
-email : char(20) 1 Latitud:(float)
Longitud: (float)
+adicionar()
Topo1: (char250)
reclamos +modificar() 1 Tipo2: (char250)
id_reclamo(10) +save(latitut:fñoad,ñpngi
ti tulo:char(20) tud;float) point
detal le:char(50)
fecha:date(8)
+crear()
modificar() n
1proyecto
eliminar() -Id_proy : int(10) comunidad
-nombre : Char(20)
1 n -Id.: int(10)
-ubicacion : double(10) -nombre:char(20)
n -fecha_inic : Date .ubicacion:multipolygon
1
financiador -fecha_fin : Date
id_financiador:inte()10 -responsable : char(20)
nombre:char(20) -tipo : int
direccion:char(20) +adicionar()
resp onsable:char(20) +modificar()
Clase:int(10) +eliminar()
+adicionar()
+modificar()
-elimianr()
tipo
+tipo : int
+nombre : char
clase +monto : double
id_claser:inte()10 +crear()
nombre:char(20) 1 +modificar()
monto inicial:double(6) +eliminar()
1 monto modificado:double(6) +devuelve tipo()
monto final:double(6)
resp onsable:char(20)
+adicionar()
+modificar()
-elimianr()

Figura 32 diagrama de Clases

Fuente: Elaboración propia

72
3.8 DISEÑO NAVEGACIONAL

3.8.1 Clases Navegacionales Básicas

Nodo: Usuario
Atributos:
Id_usuario
Nombre
Contraseña
relacionado con: Funcionario Enlace: Id_usuario Ancla: crear
Modificar
Elimina
Aparece en context

Figura 33 Nodo usuario

Fuente: Elaboración propia

Nodo: Funcionario
Atributos:
Id_funcionario
Fe_regusuario
Nombre
Paterno
Materno
Dirección
Email
Teléfono
Foto
Relacionado con: Municipio Enlace: Id_funcionario Ancla: adiciona
Modificar
Elimina
Aparece en context

Figura 34 Nodo Funcionario

Fuente: Elaboración propia

73
Nodo: Municipio
Atributos:
Id: Municipio
ubicación
teléfono
Dirección
Email
Relacionado con: Proyecto Enlace: Id: funcionario Ancla: adiciona
noticias Id: proyecto, Titulo Modificar
Aparece en context

Figura 35 Nodo Municipio

Fuente: Elaboración propia

Nodo: Proyecto
Atributos:
Id: proy
Nombre
Ubicación
Fecha_inic
Fecha_fin
responsable
Tipo
Relacionado con: Municipio Enlace: Id: proy Id: municipio Ancla: adiciona
Tipo Modificar, Elimina
Aparece en context

Figura 36 Nodo Proyecto

Fuente: Elaboración propia

Nodo: mapas
Atributos:
Id_mapa
Nombre
geometria
latitud
longitud
Tipo
Relacionado con: Municipio Enlace: Id comunidad Id: Ancla: adiciona
municipio Tipo Visualiza
Aparece en context

Figura 37 Nodo mapas

Fuente: Elaboración propia

74
Nodo: Noticias
Atributos:
titulo
contenido
fechapublicacion
fotonoticia
Relacionado con: Municipio Enlace: titulo Ancla: adiciona
responsable Modificar, Elimina
Aparece en context

Figura 38 Nodo Noticias

Fuente: Elaboración propia

3.8.2 Esquema de clases navegacionales

El diseño de navegación es expresado en esquemas de clases navegacionales y

esquemas de contextos navegacionales. Se diseña la aplicación teniendo en cuenta a los
usuarios según sus privilegios de estos y objetivos.

A que estructuras el usuario tendrá acceso:

A nodos representados por rectángulos por donde los usuarios podrán navegar para
realizar tareas mediante enlaces conectados por líneas los cuales son los puntos de partida
para el acceso, En la figura 39 representamos el diagrama navegacional general para el
Sistema Geográfico de Huatajata.

75
 Atencion
municipio sig proyectos
cliente
º

vis ualiza
proyectos

Usuario
casu al Vis ualiza
mapas

Vis ualiza
Usuario noticias
registrado

funcionarios editor administrador

Nombre Nombre
co ntraseña contraseña

Edita Edita localiza

noticia proyecto mapa
titulo Id_proyecto
nombre nombre

Figura 39 Diagrama de clases navegacional general para el Sistema Geográfico Huatajata.

Fuente: Elaboración propia

76
3.8.3 Esquema de clase navegacional para usuario casual

En la figura 40 podemos visualizar la representación del esquema de clase

navegacional para un usuario casual, los accesos a la página del sistema de Información
Geográfico Huatajata.

Atencion
municipio sig proyectos
cliente
º

visualiza
proyectos

Usuario Vis ualiza

casual mapas

Visualiza
noticias

Figura 40 Diagrama de clases navegacional usuario casual para el Sistema Geográfico.

Huatajata

Fuente: Elaboración propia

3.8.4 Esquema de clase navegacional para usuario editor

En la figura 41 podemos visualizar la representación del esquema de clase

navegacional para un usuario editor, el cual tiene acceso a los módulos de modificación de
noticias, proyectos los accesos a la página del sistema de Información Geográfico Huatajata.

77
 Atencion
municipio sig proyectos
cliente
º

Vis ualiza
proyecto

funcionarios editor
Vis ualiza
Nombre mapa
contraseña

Vis ualiza
noticias

Edita Edita localiza

noticia proyecto mapa
titulo Id_proyecto
nombre nombre

Figura 41 Diagrama de clases navegacional para el usuario editor del Sistema Geográfico
Huatajata

Fuente: Elaboración propia

3.8.5 Esquema de clase navegacional para usuario administrador

En la figura 42 podemos visualizar la representación del esquema de clase

navegacional para un usuario editor, el cual tiene acceso a los módulos de modificación de
noticias, proyectos y la adición y modificación los niveles de usuarios y a los accesos a la
página del sistema de Información Geográfico Huatajata.

78
 Atencion
mu nicipio sig proyectos
cliente
º

Vis ualiza
proyecto

Vis ualiza
mapa
fu ncionarios administrador

Id_fu ncionario Nombre:

co ntraseña contraseña

Vis ualiza
noticias

Edita Edita localiza

noticia proyecto mapa
titulo Id_proyecto
nombre nombre

Figura 42 Diagrama de clases navegacional usuario administrador para el Sistema

Geográfico Huatajata

Fuente: Elaboración propia

3.9 ESQUEMA DE CONTEXTO NAVEGACIONAL

3.9.1 Diagrama de contexto

En esta sección se presenta el contexto de navegación para el sistema geográfico de

Huatajata aplicación Web mostrando contextos de aplicación dinámica.

79
 En la figura 43 que se presenta el diagrama de contexto del usuario casual desde el
momento q ingresa a la aplicación del municipio de Huatajata.

Sistema de Geográfico de
Huatajata Por nombre
inicio municipio
descripcion

Por nombre
Menu principal proyectos
Atención al descripcion
cliente

sig descripcion
transparencia

noticias

servicios

Figura 43 Diseño navegacional web para un usuario casual para el Sistema Geográfico
Huatajata

Fuente: Elaboración propia

3.9.2 Diagrama de contexto para el usuario administrador

La siguiente figura 44 muestra el diagrama de contexto navegacional para el usuario

administrador.

80
 Proyecto
Menu principal proyectos por nombre

crear

modificar

Usuario registrado eliminar

noticias
<tipo =administrador>

noticias
titulo

funcionario crear

modificar

eliminar
usuario sig
Id_usuario

crear
Mapa por
modificar nombre

eliminar
adiciona

busca

visualiza

Figura 44 Diseño navegacional web para un usuario administrador para el Sistema

Geográfico Huatajata

Fuente: Elaboración propia

3.10 DISEÑO DE LA INTERFAZ ABSTRACTA

Después que la estructura navegacional fue explicado se debe especificar ahora los
aspectos de la interfaz. Esto significa definir la manera en que los objetos aparecerán en la
pantalla sus diferentes las funcionalidades de la aplicación para interactuar con el usuario.

81
3.10.1 Diseño de ADV de la pantalla principal vía Web

Los ADV’S nos ayudaran a ver de qué manera se llevara a cabo la interfaz del
sistema con el usuario en la pantalla principal del Sistema Geográfico de Huatajata.

Index

BANER

proyectos Atencion
municipio sig
al cliente

MENU content
ADV ADV atencion
ADV sig ADV proyectos
municipio al cliente

ADV funcionarioclic ADV funcionario

clic
ADV noticias ADV noticias

Figura 45 ADV usuario navegante

Fuente: Elaboración propia

3.10.2 Diseño de ADV Administrador

La siguiente figura 46 nos muestra el diseño de interfaz del sistema para el usuario
administrador en la pantalla principal del Sistema Geográfico de Huatajata.

82
I ndex

BANER

Inicio y municipio sig Atencion

proyectos
al cliente

MENU content
ADV atencion
ADV inicio ADV municipio ADV sig ADV proyectos
al cliente

clic
crear funcionario ADV crear funcionario

Modificar funcionario clic ADV modificar funcionario

clic
Eliminar funcionario ADV eliminar funcionario

clic
Crear proyecto ADV crear proyecto

clic
Modificar proyecto ADV modificar proyecto

Eliminar proyecto clic ADV eliminar proyecto

clic
Crear noticia ADV crear noticia
clic
Modificar noticia
ADV modificar noticia
clic
Eliminar noticia
ADV eliminar noticia

Figura 46 ADV usuario administrador

Fuente: Elaboración propia

Noticia
Clúster
Clúster

banner

titulo

descripcion

foto

fecha

Figura 47 ADV noticia

Fuente: Elaboración propia

83
 Figura 48 ADV funcionario

Fuente: Elaboración propia

banner

logotipo

Id_proyectp

Nombre

Figura 49 ADV proyecto

Fuente: Elaboración propia

84
3.11 IMPLEMENTACION

A continuación mostraremos la implementación y desarrollo del sistema de

Información Geográfico de Huatajata.

Este módulo es el resultado del análisis y el diseño para generar el código final. Esta
se adapta de acuerdo al lenguaje de programación según las especificaciones del diseño.

3.11.1 Pantallas
Las pantallas fueron diseñadas de acuerdo a la sugerencia y gusto de la entidad
auspiciadora. También se vio la mejor forma de diseñar la navegación utilizando menús,
iconos y animaciones para que muestren el realce de esta pantalla. A continuación veremos
la interfaz final del Sistema de Información Geográfico de Huatajata

Figura 50 Pantalla principal del Sistema de Información Geográfico de Huatajata

Fuente: Elaboración propia

85
Figura 51 Ingreso al módulo de proyectos principal del Sistema de Información Geográfico
de Huatajata

Fuente: Elaboración propia

Figura 52 Pantalla principal de administración del Sistema de Información Geográfico de

Huatajata

Fuente: Elaboración propia

86
 Figura 53 Módulo de proyectos principal del Sistema de Información Geográfico de
Huatajata

Fuente: Elaboración propia

Figura 54 Módulo de adición nuevo proyectos del Sistema de Información Geográfico de

Huatajata

Fuente: Elaboración propia

87
 Figura 55 Módulo de adición de usuario del Sistema de Información Geográfico de
Huatajata

Fuente: Elaboración propia

Figura 56 Pantalla para el reporte de proyectos del Sistema de Información Geográfico de

Huatajata

Fuente: Elaboración propia

88
 Figura 57 Vista de reporte de proyectos del Sistema de Información Geográfico de
Huatajata

Fuente: Elaboración propia

Figura 58 Vista de mapa de proyectos del Sistema de Información Geográfico de Huatajata

Fuente: Elaboración propia

89
Figura 59 Vista de mapa de proyectos del Sistema de Información Geográfico de Huatajata

Fuente: Elaboración propia

3.12 PRUEBAS

3.12.1 Prueba de caja blanca

Esta prueba se puede realizar por dos métodos el pseudocodigo o el proceso DFD,
para el programa se utilizara el proceso DFD que se realizara mediante grafos de flujo del
camino básico, que nos posibilitara el cálculo de la complejidad cliclomatica del software.

Caso de prueba 1: ver contenidos

Primer paso: Convertir los casos de uso en diagramas de flujo, luego realizar las notaciones
de grafos de flujo factorizando.

90
 INICIO

SELECCIONAR
PROYECTO

2
MOSTRAR
PROYECTO

INICIO

Figura 60 Diagrama de flujo de vista de proyectos

Fuente: Elaboración propia

Segundo paso: Calcular los datos

1. El número de nodos N = 2

2. El número de aristas A = 1

3. El número de regiones R = 1

4. El número de nodos predicados NP = 0

Tercer paso: Calcular la complejidad dicromática

1. V(G) = Numero de regiones =1

2. V(G) = A – N + 2 = 1 – 2 + 2 = 1

3. V(G) = NP + 1 = 0 + 1 = 1

La complejidad cliclomática es 1, esto nos dice que existe un camino independiente para
mostrar un proyecto.

Cuarto paso: Hallar el número de caminos independientes

C1(a) = 1 – 2

91
Caso de prueba de camino C1(a)

1. Valor (valor = proyecto)

Selecciona proyecto

2. Visualiza proyecto

Caso de prueba 2: agregar usuarios

Primer paso: Convertir los casos de uso en diagramas de flujo, luego realizar las notaciones
de grafos de flujo factorizando.

INICIO

Inngresar nombre
contraseña y 1
capcha

2
verificacón

Llenado de datos
4

5
Usuario registrado

INICIO

Figura 61 Diagrama de flujo de adición de usuarios

Fuente: Elaboración propia

Segundo paso: Calcular los datos

5. El número de nodos N = 5

92
 6. El número de aristas A = 5

7. El número de regiones R = 1

8. El número de nodos predicados NP = 1

Tercer paso: Calcular la complejidad dicromática

4. V(G) = Numero de regiones =2

5. V(G) = A – N + 2 = 5 – 5 + 2 = 2

6. V(G) = NP + 1 = 2 + 1 = 2

La complejidad cliclomática es 2, esto nos dice que existe un camino independiente para
mostrar un proyecto.

Cuarto paso: Hallar el número de caminos independientes

C1(a) = 1 – 2 – 3 – 4 – 5

Caso de prueba de camino C1(a)

1. valor (nombre = mfernandez contraseña = abc123 capcha = ABD1234)

2. Agrega usuario

3. agrega datos del usuario (nombre, cuenta, pasword, rol)

Usuario adicionado

Caso de prueba 2: agregar proyecto

Primer paso: Convertir los casos de uso en diagramas de flujo, luego realizar las notaciones
de grafos de flujo factorizando.

93
 INICIO

Inngresar nombre
contraseña y
capcha 2

verificacón

5
Acceso autorizado

8
Registro

agregar

editar

Llenado de datos

Proyecto adicionado

INICIO

Figura 62 Diagrama de flujo de adición de proyectos

Fuente: Elaboración propia

Segundo paso: Calcular los datos

9. El número de nodos N = 9

94
 10. El número de aristas A = 11

11. El número de regiones R = 4

12. El número de nodos predicados NP = 3

Tercer paso: Calcular la complejidad cliclomática

7. V(G) = Numero de regiones =4

8. V(G) = A – N + 2 = 11 – 9 + 2 = 4

9. V(G) = NP + 1 = 3 + 1 = 4

La complejidad cliclomática es 4, esto nos dice que existen varios caminos independientes
para mostrar un proyecto.

Cuarto paso: Hallar el número de caminos independientes

C1(a) = 1 – 2 – 3 – 4 – 5 – 9

C2(a) = 1 – 2 – 3 – 4 – 5 – 6 – 9

C3(a) = 1 – 2 – 3 – 4 – 5 – 6 – 7 – 9

C4(a) = 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9

Caso de prueba de camino C4(a)

1. Valor (nombre = mfernandez contraseña = abc123 capcha = ABD1234)

2. Agrega proyecto

Agrega nombre

3. Agrega datos del proyecto (distrito, comunidad, empresa, tipo, costo1, costo2, costo3,
resolución, presupuesto, numero de fases, fecha inicial, fecha entrega)

Proyecto adicionado

95
CAPITULO 4

METRICAS DE CALIDAD

4.1 Calidad de Software

La calidad de software es hacer uso de todos los requerimientos, procedimientos

técnicas e instrumentos, para que el producto cumpla con los estándares predefinidos basado
en ISO 9126 que tiene los siguientes criterios de calidad: Usabilidad, funcionalidad,
confiabilidad y portabilidad juntamente con las fórmulas que se utiliza.

1. Usabilidad
Se refiere al grado en que el software puede ser utilizado por los usuarios, está
compuesto por las siguientes características: facilidad de comprensión, facilidad de
aprendizaje y facilidad de operatividad.

Para conocer el grado de usabilidad del programa se preguntó a los posibles usuarios
del sistema, que están enmarcadas en las características mencionadas anteriormente.

El grado de usabilidad que nosotros obtuvimos es de un 86 % en conclusión podemos

mencionar que el sistema fácil de utilizar.

2. Funcionalidad
Para hallar la funcionalidad del sistema consideramos los siguientes datos:

a) Procedencia: de la información y origen de los datos que utilizando cálculos lineales

corregir los errores que contenga la misma, acerca de las características de los datos
espaciales
b) Exactitud: es la precisión con la que se ha llevado a cabo la representación las
entidades del mundo real, atributos y valores de los mismo (coordenadas x, y, z).
c) Compleción: se refiere a la relación entre objetos de la base de datos y el universo
abstracto de todos los objetos; el propósito es saber si todos elementos que deseamos
representar están en el sistema.

96
 d) Consistencia lógica: hace una descripción de la compatibilidad de los datos con su
entorno y la relación entre los distintos objetos, que no exista redundancia, para que
las tablas estén correctamente normalizadas.
e) Resolución: se refiere a la calidad que se pueda discernir hasta el elemento más
pequeño de la base de datos que puede ser cartografiado y visualizado a diferentes
escalas, gracias al modelo vector nos permite una mejor representación de nuestros
datos en cada mapa.

3. Confiabilidad
Se refiere a la conexión existen entre los diferentes equipos que utilizan el sistema, la
cantidad de tiempo que el sistema se mantiene en funcionamiento en la institución libre
de fallas. Por tanto para poder medir la confiabilidad se aplicó la teoría estadística que
nos permite calcular el porcentaje de confiabilidad, tomándose las siguientes
consideraciones:

a) Se supone que el sistema inicia su trabajo en un tiempo t0 = 0 y se observa hasta que

el sistema falle a esto se llama tiempo t (tiempo de falla)
b) Se designa una variable aleatoria T, el tiempo de trabajo del sistema sin fallas en un
tiempo t será P[T<= t] = F(t) y la probabilidad de funcionamiento del sistema será
P[T> t] = 1 - F(t)
c) Denominaremos confiabilidad del sistema como R(t), m tomaremos en cuenta el
periodo t que es el tiempo en que existe alguna falla, luego aplicaremos la función
exponencial en el cual se tomara el valor punto función.
d) El margen de error lambda es de 1/100 que se calculó realizando 10 ejecuciones en
un mes que se produzca fallas en el sistema.
e) Si calculamos para una gestión (12 meses) juntamente con el valor punto función PF
= 0.87 por tanto podemos mencionar el el sistema tiene un 75% de confiabilidad.

4. Portabilidad

La portabilidad es la facilidad con el que software pueda ser llevado de un entorno a otro y
para ello se toman en cuenta lo siguiente:

97
Adaptabilidad: la capacidad de que el programa pueda ser adaptado a diferentes entornos
sin aplicar acciones o medios diferentes como ser a Windows 7 a Linux

Facilidad de instalación: la capacidad del programa para ser instalado en un ambiente

especificado. Nuestro sistema fue desarrollado en PHP, el cual permita que tenga un acceso
rápido a la aplicación por cuanto no necesita instalación pues se puede acceder mediante el
explorador del internet.

Coexistencia: la capacidad del programa de coexistir con otros programas independientes

dentro un mismo entorno, compartiendo recursos comunes. Pues el sistema coexiste con
otros sistemas existentes en la institución.

El sistema es portable en un 76% por lo tanto podemos mencionar que es medianamente

transportable el sistema

4.2 ANÁLISIS Y COMPARACIÓN DE RESULTADOS PARCIALES Y

GLOBALES

CARACTERISTICA X IE R IER PESO PESOIE

1 Usabilidad 86.23 0,81701 1,435 0,81701 0,3 0,2050

2. Funcionalidad 76.24 0,84701 1,435 0,84701 0,3 0,1665

3. Confiabilidad 75.25 0,77701 1,535 0,77701 0,2 0.1490

5. Portabilidad 76.25 0,89701 1,435 0,89701 0,5 0.0849

TOTAL 0,7866

Tabla 23 Computo de las preferencias globales

Fuente: Elaboración propia

98
 De acuerdo a los resultados de la calidad global realizada al sistema de información
geográfico Huatajata aplicando el modelo Web Site OEM, se puede llegar a la conclusión
que el usuario que visitara nuestro sitio tendrá una satisfacción de un 86%. Este valor está
dentro de los márgenes de satisfacción de acuerdo al modelo utilizado.

4.3 ANÁLISIS DE COSTO/BENEFICIO

El propósito de analizar el costo en relación al beneficio es mostrar a los usuarios y

administradores del sistema que los beneficios son mayores a los costos al implantar este
proyecto, ya que un proyecto se justifica cuando los beneficios de su culminación exceden
sus costos de producción.

4.3.1 Análisis de Costos

Para determinar el costo total del proyecto se tomara en cuenta los siguientes costos:

Costo del software desarrollado, Costo de la implementación del sistema Costo de la

elaboración del proyecto

Costo del software desarrollado: Para determinar este costo se hará uso del modelo
constructivo de coste COCOMO II.

Estimación de puntos de función:

Parámetros de medición Cuenta Factor de Ponderación Total

Número de entradas de usuario 18 4 72
Número de Salidas de Usuario 16 5 80
Número de peticiones de usuario 20 4 80
Numero de archivos 3 10 30
Numero de interfaces externos 0 7 0
TOTAL 262

Tabla 24 Cálculo de puntos Función no ajustados

Fuente: [Presman, 2002]

99
 Calculo de los valores de ajuste de la complejidad tomando los valores de la tabla 25
en el cual se determina la complejidad:

Factor Valor
Copia de seguridad y recuperación 5
Comunicación de datos 5
Proceso distribuido 3
Rendimiento critico 2
Entorno operativo existente 5
Entrada de datos en línea 4
Transacciones de entrada en múltiples 2
pantallas.
Archivos maestros actualizados en 3
línea.
Complejidad de valores del dominio de 2
información
Complejidad del procesamiento interno. 4
Código diseñado para la reutilización. 5
Conversión instalación en diseño 2
Instalaciones múltiples 5
Aplicación diseñada para el cambio 4
∑(Fi) 51

Tabla 25 Determinación de complejidad

Fuente: [Presman, 2002]

Factor de Ajuste = 0.65 + 0.01 + ∑(Fi)

Factor de Ajuste = 0.65 + 0.01 + 51

Factor de Ajuste = 1,16

Calculo de Puntos de Función

El cálculo de puntos de Función se basa en la fórmula:

PF = Cuenta Total* Factor de ajuste

PF = 262*1,16

PF = 303,92 ≈ 304

100
Conversión de los puntos de función a KLDC

LDC = PF*Factor LDC/PF

LDC = 304 * 29

LDC = 8816

KLDC = 8,8

Aplicando las formulas básicas de esfuerzo, tiempo calendario y personal requerido. Las
ecuaciones del COCOMO básico tiene la siguiente forma:

E = ab(KLDC)b1 ecuación 1

D = Cb(E)db ecuación 2

Donde:

E: esfuerzo aplicado en personas por mes

D: Tiempo de desarrollo en meses cronológicos

KLDC: Número estimado de línea de código distribuidas en miles

Proyecto de software ab bb cb db
Orgánico 2,4 1.05 2.5 0.38
Semi-acoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.20 2.5 0.32

Tabla 26 Coeficientes ab bb y los exponentes cb y db

Fuente: [Pressman. 2002]

En la tabla 26 se muestra los tipos de proyectos de software, el cual se elige los semi
– acoplado, ya que son proyectos, con variados nivelas de experiencia, deben satisfacer
requisitos poco medio rígidos, tal es el caso del software desarrollado.

E = 3.0*(8.8)1.12 D = 2.5*(34.27)0.35

101
E = 34,27 D = 8.61

EL personal requerido, es decir el número de programadores se obtiene con la

siguiente formula:

Numero de programadores = E/D

Numero de programadores = 34.27/8,61

Numero de programadores = 3.9 ≈ 4

El salario de un programador aproximadamente oscila entre los 400 $us, cifra que
tomaremos en cuenta para la estimación siguiente:

Costo del software desarrollado = Numero de programadores * salario de un programador

Costo del software desarrollado = Numero de programadores * salario de un programador

Costo del software desarrollado = 4*400

Costo del software desarrollado = 1600 $us

Costo de implementación del sistema: Ya que el software es de distribución libre. Se

cobrar solo por la configuración e instalación como se muestra en la tabla.

Descripción Costo total ($us)

Hosting 30
Configuración del servidor apache 10
Instalación php 20
Instalación postGis 30
Total 90

Tabla 27 Costo del software

Fuente: [Elaboración propia]

Costo de elaboración del proyecto: se refiere a los costos del estudio en la elaboración el
sistema, en la etapa de recopilación y análisis todo esto se presenta en la siguiente tabla

102
 Descripción Costo total ($us)

Análisis y diseño del proyecto 350

Material de escritorio 30

Otros 40

Total 420

Tabla 28 Costo de elaboración del proyecto

Fuente: [Elaboración propia]

Costo total: es la sumatoria de todos los costos anteriores y se detalla en la tabla

Descripción Costo total ($us)

Costo del software desarrollado 1600

Costo de implementación del sistema 90

Costo de elaboración del proyecto 420

Total 2010

Tabla 29 Costo total de elaboración del proyecto

Fuente: [Elaboración propia]

4.3.2 Análisis de beneficios

Los beneficios para un sistema nuevo es un tanto complicado de calcular que los
costos debido a no se ven a priori pero los usuarios serán los que identifiquen las
bondades del nuevo sistema.

Los beneficios para el proyecto serán de tipo intangibles y para analizar se utilizaran
cinco criterios de evaluación.

 Incremento de velocidad en los procesos: Toda la información que se manipule en

el departamento se incrementara notablemente.

103
  Capacidad en el volumen de información: Se podrá llevar a cabo mayor cantidad
de información del que se realizaba normalmente
 Control de procesos: Se conocerá de manera oportuna como esta un proyecto y en
qué fase se encuentra
 Integración de la información: La información se cohesionara notablemente debido
a que estarán plenamente identificados
 Información para la toma de decisiones: toda la documentación generada por el
sistema será de mucho valor cuando se decida qué hacer.

4.3.2.1 Valor neto actual

El valor neto actual (VAN) es un indicador financiero que mide los flujos de los
futuros ingresos y egresos que tendrá el proyecto, para determinar este valor después de
descontar la inversión inicial, nos quedara alguna ganancia podríamos decir que el proyecto
es viable.

El (VAN) también nos permite determinar cuál proyecto es el más rentable entre
varias opciones de inversión incluso, si alguien nos ofrece comprar nuestro negocio, con este
indicador podemos determinar si el precio ofrecido es más por encima o por debajo de lo
que ganaríamos. Su fórmula es:

VAN = BNA - inversión

Donde BNA se refiere al beneficio neto actualizado, valor actual del flujo de caja o
beneficio neto proyectado, el cual ha sido actualizado a través de una tasa de descuento.

La tasa de descuento (TD) con la que se descuenta el flujo neto proyectado, es la tasa
de oportunidad, rendimiento o rentabilidad mínima que se espera ganar, por lo tanto:

VAN > 0  el proyecto es rentable

VAN = 0  el proyecto es rentable, porque ya está incorporado ganancia de la TD

VAN < 0  el proyecto no es rentable

Entonces para hallar el VAN se necesita: Tamaño de la inversión, flujo de caja neto
proyectado, y la tasa de descuento

104
 Para nuestro caso:

VAN = 2010 /(1+ 0.20)1 + 2010/ (1+ 0.20)2+ 2010 /(1+ 0.20)3+2010/ (1+ 0.20)4

+2010 (1+ 0.20)1-2010

VAN = 4001-2010

VAN =1991

Podemos mencionar que nuestro proyecto es viable

4.3.2.2 Tasa interno de retorno

La TIR es la tasa de descuento (TD) de un proyecto de inversión que permite que

BNA sea igual a la inversión (VAN=0). La TIR es la máxima TD que puede tener proyecto
para que sea rentable, pues una mayor tasa ocasionaría que el BNA sea menor que la
inversión.

Entonces para hallar la TIR se necesitan: tamaño de la inversión y flujo de cana neto
proyectado.

Para nuestro caso para hallar la TIR hacemos uso de la formula del VAN

0 = 2010/(1+i)1 + 2010/ (1+i)2 + 2010/ (1+i)3 + 2010/ (1+i)4+ 2010/ (1+i)5- 2010

i = 10%

TIR = 10%
Si esta tasa fuera mayor, el proyecto empezaría a no ser rentable, pues el BNA
empezaría a ser menor que la inversión. Y si la tasa fuera menor el proyecto será cada vez
más rentable, pues al BNA seria cada vez mayor que la inversión.

105
CAPITULO 5

SEGURIDAD DEL SISTEMA

Uno de los aspectos que debemos tomar en cuenta en el desarrollo del sistema de
información de Huatajata es la parte de seguridad, por lo tanto desarrollaremos algunas
estrategias de control para el buen uso de nuestro sistema.

5.1 SEGURIDAD DE INGRESO AL SISTEMA

Para que no puedan hacer mal uso del sistema o ingresar personas no autorizadas
para realizar algunos cambios ya sean estos de publicación noticias, mantenimiento del
mismo se gestionó un módulo de seguridad, para acceder mediante un nombre de usuario y
su contraseña.

También se realiza un control de niveles de usuario, para que puedan tener acceso
irrestricto al sistema o solo con ciertos niveles de privilegio.

Para que la contraseña no pueda ser visualizado se realizó una función de

encriptación MD5 para que no pueda ser visualizada.

También para dar mayor seguridad al sistema las contraseñas de todos los usuarios
deben ser modificados periódicamente.

5.2 SEGURIDAD DEL SISTEMA OPERATIVO

Todos los equipos de la alcaldía deben tener un usuario y contraseña con algunos
privilegios restringidos para que no puedan ingresar al sistema.

Los programas útiles para el uso del sistema solo tendrán los equipos autorizados
para una mejor protección de la información de personal no autorizado.

5.3 POLÍTICA SOBRE COPIAS DE RESPALDO (BACK CUP)

Para que la información este siempre seguro de alguna contingencia no prevista se

debe realizar copias de seguridad periódicas, siendo estas almacenadas en medios de

106
almacenamiento externo, etiquetados por fecha, y guardados de forma adecuada en un lugar
seguro. Donde solo el personal autorizado deberá tener acceso a los mismos.

5.4 POLÍTICA SOBRE SEGURIDAD FÍSICA

Bebido a que la energía no es estable en la población, el equipo que será servidor del
sistema deberá de contar con un estabilizador equipado con Ups. Siendo este equipo ubicado
en un lugar seguro, restringido, ventilado y equipado con un extintor.

5.5 PLAN DE CONTINGENCIAS

Para los accidentes no previstos analizaremos los siguientes posibles riesgos:

Riesgos por parte de la institución

 La frecuencia de cambio del personal.

 Ingreso de personas ajenas al departamento.
 Posible robo de los equipos
 Mal uso de los equipos por el personal asignado al departamento.
 Falta de capacitación en el manejo del sistema
 Mal uso del sistema.

Riesgos tecnológicos

 Robo de información por personas malintencionados

 Des configuración del equipo por parte del personal asignado
 Ataque de virus informáticos
 Perdida de información en la base de datos
 Eliminación de la Base de Datos

5.6 FACTOR Y ANÁLISIS DE RIESGO

Para realizar el análisis de riesgos anteriores consideraremos los siguientes factores:

Muy bajo: Cuando la contingencia se muy poco probable de que suceda.

107
 Bajo: Cuando la contingencia se poco probable de que suceda.

Medio: Cuando la contingencia se casi probable de que suceda.

En la tabla 30 realizaremos un resumen de los tipos de riesgos que ser presenten en

el sistema y clasificar cada uno en un grupo para otorgarle un factor según su probabilidad
de suceso en el sistema.

Nro. Tipo de riesgo Grupo Factor

1 Posible robo de equipo Riesgo de la institución Alto

2 Robo de información Riesgo tecnológico Medio

3 Ingreso de personal no autorizado Riesgo de la institución Alto

4 Fuego Riesgo natural Muy bajo

5 Terremotos Riesgo natural Muy bajo

6 Virus informático Riesgo tecnológico Alto

7 Desconfiguración del equipo Riesgo tecnológico Alto

Tabla 30 Evaluación de riesgos

Fuente: Elaboración propia

En la tabla 31 realizaremos un resumen de las políticas a seguir para prevenir estas

eventualidades que se presentaran a futuro en el sistema, una vez conocido el factor de
riesgo que se presente en el sistema.

108
 Reducción de Riesgos Adecuar los ambientes para salvaguardar los
equipos y la información.

No permitir el ingreso de personal no

autorizado a los ambientes
Supervisión de riesgos Verificar que los ambientes sean seguros.
Robo del
Hardware e Verificar y otorgar credenciales al personal que
información trabaja con el sistema.
Gestión de riesgos Se debe designar un encargado de los
ambientes para resguardar los ambientes.

Las copias de las llaves deben estar

resguardadas

Realizar copias de seguridad periódicamente

Reducción de Riesgos Establecer contraseñas seguras para que no
ingrese personal no autorizado.

Salir adecuadamente del sistema

Acceso no Supervisión de riesgos Verificar que las contraseñas no sean de
autorizado al conocimiento público.
sistema
Cambiar periódicamente el cambio de
contraseña.
Gestión de riesgos Establecer contraseñas de acuerdo a normas de
seguridad.
Reducción de Riesgos El personal debe ser controlado
periódicamente.
Perdida de la
información Resguardar adecuadamente las Backup.
Supervisión de riesgos Verificar que el personal realizo copias de
respaldo periódicamente, así como el sistema
Gestión de riesgos Realizar copias de seguridad según a normas de
seguridad.

Tabla 31 Evaluación de riesgos

Fuente: Elaboración propia

109
CAPITULO 6

CONCLUSIONES Y RECOMENDACIONES

6.1 CONCLUSIONES

Una vez concluido el proyecto Sistema de Información Geográfica de Huatajata

podemos llegar a las siguientes conclusiones:

La incorporación de las tecnologías de la información en las diferentes instituciones

del estado es necesario debido a que facilita el trabajo e integra con el mundo permitiendo
que la información sea global.

El municipio a pesar de ser nuevo concentra gran cantidad de visitantes de diferentes

lugares del mundo, pues podemos mencionar que es una población altamente turístico, y
viendo está afluencia podemos concluir que el sistema será de mucha ayuda a los interesados
en informarse sobre la población.

6.2 RECOMENDACIONES

Como es de su conocimiento que el sistema es un prototipo que solo está enfocado a

una dirección de la institución pues por esto se debe pensar a futuro en:

Elaborar un sistema de contabilidad e inventarios, para que permita mejorar el

manejo de los recursos del sistema.

Como toda institución siempre tiende a crecer seria muy positivo que se realice un
sistema de manejo del personal-

Realizar un sistema administrativo que integre y automatice el manejo de la

información con todas las direcciones.

110
 BIBLIOGRAFÍA

[Gomez, 2006] Gomez Delgado, Montserrat; Barredo Cano, José I. “Sistemas de

información geográfica y evaluación multicentro” (2005)

[Ordoñez, 2003] Ordoñez Celestino, Martinez –Alegria Lopez Roberto “Sistemas de

Información Geografica”, Alfaomega grupo editor S.A. Mexico D.F. (2003)

[Pressman, 2002] Roger Pressman, “Un enfoque a la ingeniería de software”, 2da Edicion:
Prentice Hall-Madrid 2002

[Schwabe 1995] D.Schwabe, G.Rossi. The Object-Oriented Hipermedia Design

Model.Communications of the ACM, 38(8), August, 1995, pp.45-46

[Machicado, 2004] Carlos Alberto Machicado “Actualizaciones en Arc View 2004”

[Cabezas, 2003] Cabezas, C. Y Ayala, R. apuntes del curso sistemas geográficos

[Date, 1990] C.J. Date “Sistema de bases de datos quinta edición“ volumen I Quinta edición

[Olsina, 1999] Dr. Luis Antonio Olsina, “Metodologia Cuantitativa para la evaluación y
comparación de la calidad de Sitios Web”, Tesis Doctoral, La Plata, Novienbre de 1999
Facultad de Ciencias Exactas, Universidad Nacional de la Plata – Argentina

[Amaro. Valverde, 2007] Amaro Calderón, Sarah Damaris, Valverde Rebaza, Jorge Carlos
“metodologías Agiles”, Trujillo – Perú (2007)

[Bosque, 2004]Bosque Sendra, JOaquin; escobar Martinez Francisco “Sistema de

información geográfica practicas con PC ARC/INFO e IDRISI” ADDISON – WESLEY
IBEROAMERICANA (1994)

[Enrique, 2009] Enrique Benito Lopez, Daniel Cimorra Grande “Geolocalizacion y

Georeferenciacion”

111
ANEXO A: ARBOL DE PROBLEMAS

El catastro del municipio no Hay focos de Carencia de políticas y

está bien organizado contaminación no normas propias relacionadas
controlados en el municipio con el ambiente.

La mayoría de
Baja existencia proyectos se Apoyo técnico a las
de planes de ejecutan a comunidades, con
corto, mediano y requerimiento de limitaciones.
largo plazo. las comunidades.

ÀREA DE PLANIFICACIÓN DÉBIL

Recursos humanos, Oficina Municipal de Personal no ha sido

materiales, financieros Planificación no capacitado
y técnicos insuficientes. cumple con rol adecuadamente.
asignado en Código
Municipal

Los vecinos no Los aspectos Ninguna unidad de la

tienen información relacionados con el municipalidad tiene
clara sobre el ambiente no son asignada la función
catastro de su considerados por el relacionada con el aspecto
propiedad Municipio ambiental.
ANEXO B: ARBOL DE OBJETIVOS
Gestión del municipio
eficiente

El catastro del municipio Hay focos de Buenas políticas y normas

está bien organizado contaminación controlados propias relacionadas con el
en el municipio ambiente.

Existencia de
planes de corto, La mayoría de proyectos se Apoyo técnico a las
mediano y largo ejecutan por la alcaldía comunidades
plazo. adecuadas

ÀREA DE PLANIFICACIÓN EFICIENTE

Recursos humanos, El municipio realiza Personal fue

materiales, financieros una buena capacitado
planificación urbana adecuadamente.
y técnicos suficientes.
de la comunidad

Se tiene información El municipio realiza

clara sobre el un mejor control del
catastro medio ambiente
 ANEXO C: MATRIZ MARCO LOGICO
OBJETIVOS INDICADORES VERIFICADORES SUPUESTOS
Proveer al consejo Municipal de El consejo municipal utiliza la Reportes sobre la información El consejo municipal hacen uso de la
información oportuna y confiable para información para la toma de de toma de decisiones del herramienta para el desarrollo de toma
realizar una buena gestión Municipal decisiones municipio de decisiones
Tener información confiable para que la 1.- La mayoría de proyectos se 1.- Informes y monitoreo de los 1.- El consejo está de acuerdo con los
planificación del municipio sea eficiente ejecutan por la alcaldía proyectos de la alcaldía proyectos.
2.- Apoyo técnico a las comunidades 2.- Reportes de las 2.-Las comunidades dan un apoyo a la
adecuadas
3.- Hay focos de contaminación comunidades sobre el apoyo alcaldía.
controlados en el municipio. que reciben. 3.- La población coadyuva en el control
4.- El catastro del municipio está 3.- Informes sobre la de la contaminación
mejor organizado contaminación controlada 4.- Las autoridades del municipio
4.- reportes sobre los el catastro manejan mejor el catastro del municipio
del municipio
1.-Desarrollo de herramienta para la 1.- Incremento en la efectividad en la 1.- Información sobre la toma 1.- La información de la toma de
toma de decisiones estratégicas en toma de decisiones en la de decisiones en la decisiones cumple con los requisitos de
planificación planificación. planificación. calidad, oportunidad y validez.
2.-Desarrollo del personal a la toma de 2.- El 100% del personal capacitado 2.- Reportes y evaluación del 2.- El personal colabora con los
decisiones planificadas para la toma de decisiones. total del personal capacitado. cambios.
3.-Generar mapas del área urbana del 3.- Generar el 100% de mapas 3.- Reportes sobre el avance en 3.- La elaboración de mapas cumple con
municipio Urbanas del municipio. la elaboración de mapas del los requisitos de calidad, oportunidad y
4.-Generar mapas de áreas protegidas del 4.- Generar el 100% de mapas de municipio. validez.
municipio áreas protegidas. 4.- Reportes de mapas de áreas
protegidas
1.- Elaboración de una herramienta para 1.- La herramienta realiza un manejo 1.- Información sobre el manejo Las diferentes áreas del municipio
el manejo de mapas efectivo de mapas. de mapas. participan en la elaboración de datos y
2.- Elaboración de un manual de métodos 2.- EL 100% del manual ayuda en el 2.- Elaboración de informes del la identificación de necesidad de
y fuentes para el procesamiento de la procesamiento de la información. manual del procesamiento de la información
información 3.- El 100% de necesidades de información.
3.- Identificación de necesidades actuales información son satisfechas 3.- Información sobre las
de información necesidades