Universidad Mayor de San Andres

UNIVERSIDAD MAYOR DE SAN ANDRES
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMATICA
PROYECTO DE GRADO
“SISTEMA DE INFORMACION PARA EL CONTROL Y
SEGUIMIENTO DE PROYECTOS DISTRITALES
GEOREFERENCIADOS VIA WEB”
CASO: DIRECCION DE TIC’S Y DESARROLLO ORGANIZACIONAL DEL
GOBIERNO AUTONOMO MUNICIPAL DE EL ALTO
PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA

MENCION: INGENIERIA DE SISTEMAS INFORMATICOS
POSTULANTE : WILMER MENDOZA TRUJILLO
TUTOR METODOLOGICO : LIC. FREDDY MIGUEL TOLEDO PAZ
REVISOR : LIC. JAVIER REYES PACHECO
LA PAZ-BOLIVIA
1
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.
2016
DEDICATORIA
A mi madre Agustina Trujillo.

Por el gran amor y la devolución que tienes a tus hijo, por el apoyo ilimitado e incondicional
que siempre me has dado, por tener siempre la fortaleza de salir adelante sin importar los
obstáculos, por haberme formado como un hombre de bien, y por ser la mujer que me dio la
vida y me enseño a vivirla… no hay palabras en este mundo para agradecerte, muchas
gracias mama.
A mi padre Timoteo Mendoza.
Por el valor y el coraje que has tenido para levantarte ante cualquier adversidad, por las
enseñanzas que me has dado, y por darme ánimos siempre diciéndome lo orgulloso que te
sientes de tus hijos, muchas gracias, papa.
A mis Abuelos
Pablo Mendoza (QEPD), Agustina López (QEPD), Mateo Trujillo (QEPD),
por cuidarme, por acompañarme en mi vida, por su apoyo incondicional y cariño hasta el
último momento de sus días.
A mis hermanos, Carmen Elizabeth, Jorge Luis y Fran Freddy, y a mi sobrinita Abigail por
estar conmigo y apoyarme siempre, los quiero mucho.
2
AGRADECIMIENTOS
A Dios
A mi tutor Lic. Freddy Miguel Toledo agradecerle por sus enseñanzas, contribuciones,
correcciones y valiosas sugerencias para la conclusión de este proyecto.
A mi revisor Lic. Javier Reyes Pacheco de igual manera agradecerle por su apoyo,
colaboración y correcciones para la conclusión de este proyecto.
A mi gran amigo y compañero Ing. Edy Felix Tarqui Guarachi, por toda su colaboración y
tiempo brindado para el desarrollo del sistema.
A Lic. Luis Escobar S. Director de Tics y Desarrollo Organizacional, por darme la

oportunidad de poder realizar este proyecto en la dirección de sistemas.
A todos mis amigos y funcionarios de la Dirección de Tecnologías de la Información (TICs) y

la Dirección de Ordenamiento Territorial y Planificación Estratégica (DOTPE). Por sus
Enseñanzas, Apoyo, Colaboración y sobre todo su amistad.
3
RESUMEN
El desarrollo de este trabajo se estructura a partir del marco referencial, en el, se da a conocer
los antecedentes de la institución y la problemática existente en el mismo, que llevaron a la
necesidad de desarrollar un sistema informático. Al mismo tiempo, se indican los objetivos,
las diferentes justificaciones, entre otros aspectos.
El capítulo II, hace referencia al marco teórico, el cual es base principal para sustentar la
investigación, para ello se seleccionaron los aspectos más importantes de la metodología y
herramientas que se utilizaran. Los aspectos más relevantes de este acápite son los Sistemas de
Información Geográfica (SIG), la metodología de desarrollo RUP con el lenguaje UML,
herramientas de desarrollo de software, etc.
En el siguiente capítulo, se da énfasis a todo lo que significa el proceso de desarrollo de

software desde los requerimientos del usuario hasta la prueba final del sistema. Cada una de
las actividades que son necesarias para la transformación de los requisitos del usuario en un
sistema software, son detalladas de acuerdo a la metodología utilizada (RUP).
Antes de finalizar el trabajo se pone a prueba el software, se determina la calidad del mismo y
se presenta un análisis de costos.
Finalmente, se presentan las conclusiones del proyecto y las recomendaciones para los
trabajos futuros; incluyendo además la bibliografía y los diferentes anexos.
4
INDICE GENERAL
DEDICATORIA i
AGRADECIMIENTOS ii
RESUMEN iii
CAPITULO 1
MARCO REFERENCIAL
1.1. INTRODUCCION…………………………………………………………………... 1
1.2. ANTECEDENTES………………………………………………………………….. 2
1.2.2. Antecedentes de sistemas similares……………………………………….. 3
1.3. PLANTEAMIENTO DEL PROBLEMA..………………………….………………. 3
1.3.1. Problemas específicos……… ..…………………………………………… 4
1.4. FORMULACION DEL PROBLEMA………………………………………….…… 4
1.5. OBJETIVOS………………………………………………………………………… 5
1.5.1. Objetivo General……..……………………………………………………. 5
1.5.2. Objetivos Específicos…………………………………………………….. 5
1.6. JUSTIFICACION …………………………………………………………….. 5
1.6.1. Justificación Social………………………………………………………… 5
1.6.2. Justificación Técnica…..…………..………………………………………. 6
1.6.3. Justificación Económico…………….……………………………………. 6
1.7. METODOLOGIA, TECNICAS Y HERRAMIENTAS……………………….……. 6
1.8. ALCANCES Y APORTES……………………………………...…………………... 7
1.8.1. Alcances……………..……………….……………………………………. 7
1.8.1. Aportes………………….…………….……………………………………. 7
CAPITULO 2
MARCO TEÓRICO
2.1. INTRODUCCION……..……………………………………………………………....9
2.2. MARCO INSTITUCIONAL………………………………………………………… 9
2.2.1. Misión……………………………………………..……………………….. 9
2.2.2. Visión……………………………………..……………………………….. 10
2.2.3. Objetivos de la institución…………………………………………………. 10
2.2.4. Funciones y atribuciones…………………………..………………………. 11
2.3. SISTEMAS DE INFORMACION (SI)……………………………………………… 11
2.3.1. Definiciones……………………………….……………………………….. 11
2.3.2. Componentes o elementos de un S.I.……………………………………… 11
2.3.3. Actividades que realiza un S.I.……………………………………………. 13
5
2.4. SISTEMAS DE INFORMACION GEOGRAFICA (SIG)…………………………. 14
2.4.1. Definición...……………………………………….……………………….. 15
2.4.2. Importancia del SIG…………………………..……………………………. 14
2.4.3. Componentes de un SIG……..……………………………………………. 17
2.4.3.1. Hardware…. ……………………………………………………. 17
2.4.3.2. Software………………..………………………………………… 17
2.4.3.3. Datos………………………...…………………………………… 18
2.4.3.4. Recursos humanos…………….…………………………………. 18
2.4.4. Tipos de SIG. …………………………………………….………………. 19
2.4.4.1. Modelo vectorial………………………………..……………….. 19
2.4.4.2. modelo raster…………………………………………..…………. 20
2.4.5. Ventajas del SIG…………………………………………………………… 21
2.4.6. Tareas de un SIG…………………..……………………………………… 21
2.5. PROCESO DE DESARROLLO DE SOFTWARE………………………………… 24
2.5.1. Proceso de unificad de desarrollo (RUP)………………………………… 24
2.5.1.1. Fases de flujos de trabajo …………………………………….. 25
2.5.2. Lenguaje unificado de modelado UML……………….………………….. 28
2.6. ARQUITECTURA CLIENTE/ SERVIDOR………………………………………... 33
2.7. HERRAMIENTAS DE DESARROLLO DE SOFTWARE………………………… 34
2.7.1. Lenguaje de programación php…………………………………………… 34
2.7.2. Framework CodeIgniter php…….………………………………………… 36
2.7.3. Gestor de base de datos Postgresql……………………………….………. 37
2.7.4. Postgis…………………………………………………………………….. 39
2.7.5. Mapserver………………………………………………….……………… 39
2.8. PRUEBAS DEL SOFTWARE………………………………………………………. 40
2.8.1. Prueba de caja negra…………………………………………………..…… 41
2.8.2. Prueba de caja blanca…………..………………………………………......41
2.9. CALIDAD Y METRICAS DE SOFTWARE………………………………………. 42
2.9.1. Calidad de software……………………………………………………….. 42
2.9.2. Métricas de software………………………………………………………. 42
2.9.2.1. Métricas de calidad…………………..………………………….. 43
2.9.2.2. Norma iso 9126………………………………………………….. 43
2.10. ANALISIS ECONOMICO DEL SOFTWARE……………………………………. 50
2.10.1. Modelo de estimación empírica………………………………………….. 49
2.10.1.1. modelo cocomo II…………………………….………………… 50
2.11. SEGURIDAD………………………………………………………………………. 51
2.11.1. Seguridad a nivel sistema operativo………….………………………….. 52
2.11.2. Seguridad a nivel de base de datos……………………….………………. 53
2.11.3. Seguridad a nivel de software…………………………….………………. 54
2.11.4. Seguridad en el desarrollo del software………………………………….. 55
6
CAPITULO 3
MARCO APLICATIVO
3.1. INTRODUCCION………………………………………………………………….. 56
3.1.1. Análisis de la situación Actual…………………………………………… 56
3.2. PLAN DE DESARROLLO PARA EL SISTEMA………………………………….. 60
3.3. MODELO DEL NEGOCIO……………………………………………………….. 61
3.3.1. Modelo de casos de Uso del negocio……………………………………… 61
3.3.2. Descripción de los actores del negocio……………………………………. 65
3.3.3. Descripción de los casos de uso del negocio…………………………….. 66
3.4. REQUERIMIENTOS…………………………………………………..…………... 67
3.4.1. Funciones del sistema…………………………………………………….. 67
3.4.2. Atributos del sistema…………………………………………………….. 68
3.4.3. Modelado de casos de uso del sistema…………..……………………….. 69
3.5. ANALISIS…………………………………………………………………………... 77
3.5.1. Diagramas de Secuencia del Sistema…………………………………….. 77
3.5.2. Contrato de Operaciones………………………………………………….. 80
3.6. DISEÑO…...………………………………………………………………………... 83
3.6.1. Casos de Uso real.…..………………………………………………………83
3.6.2. Modelo de Comportamiento……………………………………………….. 93
3.6.2.1. Diagramas de Secuencia…………………………………………. 93
3.6.3. Diagrama de Componentes.…….………………………………………….. 96
3.6.4. Diagrama de Paquetes...….…….………………………………………….. 97
3.6.5. Diagrama de Despliegue...……………………………………………..…. 98
3.6.6. Diagrama Navegacional….…….………………………………………….. 98
3.6.7. Diagrama de Clases…..….…….……………………………..…………… 100
3.6.8. Diagrama Entidad - Relación……………………………………………... 100
3.6.9. Diseño de la Interfaz del Sistema..……………………………………….. 100
3.7. PRUEBAS……….………………………………………………………………….. 113
3.7.1 Prueba de Caja Blanca…..…………………………………………...…… 113
3.7.2 Prueba de Caja Negra………..……………………………………………. 121
CAPITULO 4
METRICA DE CALIDAD
4.1. FACTORES DE CALIDAD...…………..…………………………………...…....... 120
4.1.1. Funcionalidad del sistema…….………………………………………… 120
4.1.2. Confiabilidad del sistema….……….……………………………………. 122
4.1.3. Mantenimiento del sistema……………………...…………...…………… 123
7
4.1.4. Portabilidad del sistema………………………………………….............. 124
4.1.5. Usabilidad…………………………………………………………...……. 125
4.1.6. Eficiencia…………………………………………………………...…….. 125
CAPITULO 5
COSTO
5.1. INTRODUCCION……………..…………………………………………………. 126
5.2. COSTO DE ELABORACION DEL PROYECTO……………………………….. 127
5.3. COSTO TOTAL…………………………………………………………………… 128
CAPITULO 6
SEGURIDAD DEL SISTEMA

6.1. SEGURIDAD DEL SISTEMA..……………………………………………………129
CAPITULO 7
CONCLUSIONES Y RECOMENDACIONES
7.1. CONCLUSIONES..…………………………………………………...…………….131
7.2. RECOMENDACIONES..…………………………………………………...………132
ANEXOS
Anexo 1 Árbol de Objetivos..…………………………………………………... 134
Anexo 2 Árbol de Problemas..…………………………………………………... 135
Anexo 3 Informes – resúmenes de los proyectos..……………………………… 136
Anexo 4 SIG-mapas temáticos-proyectos en ejecución..…… ………………… 138
8
INDICE DE FIGURAS
CONTENIDO
Pág.
Figura 2.1. Estructura Organizacional…………………………………………………...9
Figura 2.2. Componentes de un Sistema de Información……………………………...13
Figura 2.3. Definición simplificada de un SIG…………………………………………15
Figura 2.4. Ejemplo de uso del SIG………………………………………………….....16
Figura 2.5. Componentes de un SIG……………………………………………….…...16
Figura 2.6. Modelo Vectorial y raster…………………………………………………..19
Figura 2.7. Estructura del RUP…………………………………………………............25
Figura 2.8. Descripción de los elementos de un modelo de casos de uso……………..29
Figura 2.9. Elementos de un diagrama de secuencia…………………………………..30
Figura 2.10. Modelo de diagrama de colaboración……………………………………...30
Figura 2.11. Elementos de un diagrama de Clases ………………………………………31
Figura 2.12. Elementos de un diagrama de estados……………………………………..31
Figura 2.13. Representación de un diagrama de actividad………………………………32
Figura 2.14. Modelo Cliente Servidor…………………………………………………...33
Figura 2.15. Arquitectura Cliente/ Servidor..……………………………………………34
Figura 2.16. Pruebas de Software……...………………………………………………...41
Figura 2.17. Atributos que abarcan las características de la norma ISO 9126………….44
Figura 3.1. Proceso de Contratación…………………………………………………...58
Figura 3.2. Proceso de Fiscalización y Supervisión de Obras…………………………59
Figura 3.4. Hoja de Seguimiento de Proyectos………………………………………...60
Figura 3.5. Cronograma de Actividades………………………………………………..60
9
Figura 3.6. Registro y consolidación de un proyecto………………………….……….62
Figura 3.7. Elaborar el proyecto…………………………………………………........ 63
Figura 3.8. Seguimiento del proyecto………………………………………………….63
Figura 3.9. Control y seguimiento del Proyecto……………………………………….64
Figura 3.10. Fiscalizar y Supervisar Obras……………………………………………..64
Figura 3.11. Diagrama de casos de uso general…………………………………………69
Figura 3.12. DCU Registro de Proyectos………………………………………………..71
Figura 3.13. DCU Proceso Administrativo…………………………………………….. 73
Figura 3.14. DCU Supervisión y Conclusión………………………………………….. 74
Figura 3.15. Diagrama de secuencia de acceso al sistema …………………………….. 76
Figura 3.16. Diagrama de secuencia Registro de Proyectos…………………………… 77
Figura 3.17. Diagrama de secuencia Proceso administrativo………………………….. 77
Figura 3.18. Diagrama de secuencia Supervisión y Conclusión………………………. 78
Figura 3.19. Diagrama de secuencias Consultas internas y externas………………….. 78
Figura 3.20. Casos de uso real-Ingreso al sistema …………………………………….. 83
Figura 3.21. Casos de uso real-Registro de Proyectos………………………………… 84
Figura 3.22. Casos de uso real-Ubicación Georeferencial ………………………………85
Figura 3.23. Casos de uso real-Proceso Administrativo……………………………….. 86
Figura 3.24. Casos de uso real-Proceso Administrativo-registro……………………… 87
Figura 3.25. Casos de uso real- Supervisión y conclusión ……………………………... 88
Figura 3.26. Casos de uso real-Supervisión y conclusión-registro…………………….. 89
Figura 3.27. Pantalla de caso de uso real: Consultas e información……………………90
Figura 3.28. Pantalla de caso de uso real: Portal de consultas externas……………….. 91
Figura 3.29. Pantalla de caso de uso real: Lista de Proyectos…………………………..92
Figura 3.30. Diagrama de secuencia-Acceso al sistema………………………………..93
10
Figura 3.31. Diagrama de secuencia-Registro de Proyectos……………………………94
Figura 3.32. Diagrama de secuencia-Proceso Administrativo………………………… 94
Figura 3.33. Diagrama de secuencia-Supervisión y Conclusión……………………… 95
Figura 3.34. Diagrama de secuencia-Consultas e informes……………………………. 95
Figura 3.35. Diagrama de Componentes de un formulario de proyecto………………. 96
Figura 3.36. Diagrama de Componentes de los proyectos …………………………….. 96
Figura 3.37. Diagrama de Paquetes…………………………………………………...... 97
Figura 3.38. Diagrama de despliegue del sistema……………………………………… 97
Figura 3.39. Diagrama navegacional del sistema………………………………………. 98
Figura 3.40. Diagrama de Clases…………………………………………………......... 99
Figura 3.41. Diagrama Entidad-Relación………………………………………………100
Figura 3.42. Interfaz de Usuario: Ingreso al sistema…………………………… ……...101
Figura 3.43. Interfaz de Usuario: Registro de Usuarios………………………………..102
Figura 3.44. Interfaz de Usuario: Ficha técnica de usuario…………………………….102
Figura 3.45. Interfaz de Usuario: Panel de control……………………………………..103
Figura 3.46. Interfaz de Usuario: Registro de Proyecto………………………………..103
Figura 3.47. Interfaz de Usuario: Ubicación georeferencial…………………………...104
Figura 3.48. Interfaz de Usuario: Ficha técnica-primera fase………………………….104
Figura 3.49. Interfaz de Usuario: Proceso Administrativo…………………………….105
Figura 3.50. Interfaz de Usuario: Ficha técnica-segunda fase…………………………105
Figura 3.51. Interfaz de Usuario: Supervisión y conclusión…………………………...106
Figura 3.52. Interfaz de Usuario: Supervisión y conclusión…………………………...106
Figura 3.53. Interfaz de Usuario: Ficha técnica-tercera fase…………………………...107
Figura 3.54. Interfaz de Usuario: Lista de proyectos distritales………………………..107
Figura 3.55. Interfaz de Usuario: Buzón de mensajes………………………………….108
11
Figura 3.56. Interfaz de consultas………………………………………………………108
Figura 3.57. Interfaz de consultas: lista de proyectos………………………………… 109
Figura 3.58. Interfaz de consultas: datos del proyectos………………………………..112
Figura 3.59. Interfaz de consultas: Reporte del proyecto…………………………….. 112
Figura 3.60. Interfaz de consultas: Sad municipal……………………………………..112
Figura 3.61. Interfaz de consultas: Visor municipal de obras…………………………113
Figura 3.62. Diagrama de uso general………………………………………………….113
Figura 3.63. Grafo de métrica…………………………………………………............ 113
Figura 3.64. Prueba de caja negra-acceso al sistema…………………………………. 116
Figura 3.64. Prueba de caja negra-registro de proyectos………………………………117
Figura 4. Interfaz de usuario-ubicación del proyecto………………………………136
Figura 4.1. Interfaz de usuario-resumen de proyectos por distrito...…………………136
Figura 4.2. Interfaz de Usuario-Reporte resumen por tipo……………………………137
Figura 4.3. SIG-pantalla Qgis Visor de Mapa…………...……………………………138
Figura 4.4. SIG-pantalla Qgis conexión con la base de datos..………………………138
Figura 4.4. SIG-PgAdmin base de Datos Espacial…………...………………………139
12
INDICE DE TABLAS
CONTENIDO
Pág.
Tabla 2.1. Clasificación y métricas del Software……………………………………..42
Tabla 2.2. Calculo del punto función-factor de ponderación………………………… 45
Tabla 2.3. Formulación de preguntas para calcular la usabilidad…………………… 49
Tabla 2.4 Coeficientes COCOMO…………………………………………………... 51
Tabla 2.5. Manejo de Costos…………………………………………………............ 52
Tabla 3.1. Grupo de curso normal de eventos (CU del modelado del negocio)…….. 66
Tabla 3.2. Atributos del sistema ……………………………………………………...68
Tabla 3.3. Curso normal de eventos (CU general) ………………………………….. 70
Tabla 3.4. Curso normal de eventos (CU consultas e información) …………………70
Tabla 3.5. Curso normal de eventos (CU administrador) ……………………………72
Tabla 3.6. Curso normal de eventos (CU Proceso Administrativo) ………………… 73
Tabla 3.7. Curso normal de eventos (CU supervisión de obras) ……………………. 75
Tabla 3.8. Caso de uso real: Acceso al sistema……………………………………… 83
Tabla 3.9. Caso de uso real: Registro de proyectos………………………………….. 85
Tabla 3.10. Caso de uso real: Proceso Administrativo……………………………….. 87
Tabla 3.11. Caso de uso real: supervisión y conclusión del proyecto…………………89
Tabla 3.12. Caso de uso real: consultas e información……………………………….. 91
Tabla 3.13. Caso de uso real: lista de proyectos………………………………………. 92
Tabla 3.14. Matriz de complejidad ciclomatica………………………………………..115
Tabla 4.1. Entrada de datos para el cálculo de funcionalidad………………………..118
13
Tabla 4.2. Entradas para el cálculo de funcionalidad………………………………...119
Tabla 4.3. Valores de ajuste de complejidad…………………………………………120
Tabla 4.4. Ajustes de complejidad del punto función………………………………..119
Tabla 4.5. Información requerida por el IMS……………………………………...119
Tabla 4.6. Evaluación de preguntas para calcular la usabilidad ………………….. 125
Tabla 5.1. Coeficientes ab y cb y los exponentes bb y db…………………………126
Tabla 5.2. Costo elaboración del proyecto…………………………………………127
Tabla 5.3. Costo Total del proyecto………………………………………………...128
14
CAPITULO 1
MARCO REFERENCIAL
1.1. INTRODUCCION
Hoy en día la mayoría de las instituciones ya sean privadas o públicas, cuentan con sistemas
informáticos, puesto que conocen las diversas ventajas y necesidades que pueden satisfacer
dicho sistemas. En concreto, un sistema informático nos permite almacenar, procesar y/o
acceder a la información cualquiera que sea este, de una manera más rápida, oportuna y
actualizada.
Sin embargo, a lo largo del tiempo fueron naciendo nuevas demandas en cuento a
información, por ejemplo la localización de ciertos objetos en un mapa cartográfico
(información cartográfica), que los sistemas de información comunes no podían satisfacer.
Tales demandas hicieron que surgieran los Sistemas de Información Geográfica (S.I.G.)
trayendo consigo bastas posibilidades como la obtención, gestión, manipulación, análisis,
modelado, representación y salida de datos espacialmente referenciados para la toma de
decisiones. La aplicación de los sistemas de Información Geográfica es tan extensa que la
mayor parte de los datos que maneja una administración municipal pueden ser geo
referenciados directa o indirectamente, por lo que su gestión, análisis y explotación pueden
realizarse con un sistema de estas características.
Actualmente la Ciudad de El Alto cuenta con 14 Distritos Municipales dentro su jurisdicción,

Las Sub alcaldías tienen como función primordial la de gestionar y supervisar la ejecución de
los proyectos inscritos en el Programa Operativo Anual (POA), dicha tarea es realizada
posterior a la aprobación del POA por el Honorable Consejo Municipal de El Alto, hasta su
cumplimiento.
En tal sentido, las Sub alcaldías Municipales de la ciudad de El Alto tienen la necesidad de
contar con un sistema informático que facilite y mejore el control y seguimiento de los
proyectos distritales inscritas en el POA. Son denominados proyectos menores a aquellos que
tienen un monto presupuestado menor o igual a 200000 Bs, dichos proyectos están a cargo de
las Sub-alcaldías, y aquellos proyectos que sobrepasan el monto mencionado se ejecutan en la
15
Alcaldía Central, para ser más preciso en la Dirección de Proyectos. Dentro de los proyectos
distritales o menores quedan contemplados las obras, compras; dotaciones, equipamientos y
servicios.
1.2. ANTECEDENTES
El Gobierno Autónomo Municipal de El Alto (GAMEA) como institución pública, tiene como
una de sus finalidades la satisfacción de las necesidades de la población y mejorar sus
condiciones de vida. Para lograr dicha finalidad necesita crear y constituir una estructura
organizativa funcional que le permita responder de forma efectiva a las demandas de la
población.
En su calidad de Máxima Autoridad Ejecutiva (MAE) dentro el Gobierno Municipal de El

Alto tiene la responsabilidad de plantear políticas, planes y programas de carácter estratégico
que tengan impacto sustancial en la población del Municipio de El Alto a través de una gestión
municipal orientada a resultados a partir del análisis de la realidad y escenarios aplicando las
normas como la Ley N° 1178 de Administración y Control Gubernamentales. Es así que la
Dirección de Desarrollo Organizacional y Tic’s a través de sus unidades dependientes tiene
como función en implementar sistemas que coadyuven con el desarrollo del municipio de El
Alto a través de sus diferentes direcciones.
En la actualidad el manejo de información a través de las redes de computación genera

múltiples ventajas, tanto a nivel de la administración pública (regionalización, planificación
redes, desarrollo regional y urbano, etc.), como también a nivel comercial. Para que este
manejo sea efectivo y ágil las empresas e instituciones públicas han visto la necesidad de la
introducción de los SIG. Se dice que son herramientas, por que ayudan a la información de
elementos de juicio para la toma de decisiones luego de que se han aprovechado sus funciones
de captura, almacenamiento, refinamiento análisis y visualización de la información.
Con respecto al presente proyecto a desarrollarse en dicha dirección se ha realizado un estudio

e investigación con respecto al tema sobre la realidad por la cual se manejan los proyectos,
dejando ver varias deficiencias en la ejecución física y financiera en la mayoría de las
mismas, y por consiguiente la desconfianza que tiene la población con la alcaldía municipal.
16
Esto se debe por diferentes aspectos internos como la corrupción, la falta de presupuesto como
también la forma arcaica de manejar la información que genera un ámbito burocrático dentro
de la institución.
1.2.2. Antecedentes de sistemas similares
En la carrera de informática de la UMSA existen varios proyectos de grado que contemplan el

control y seguimiento en diferentes áreas, entre estos citaremos algunos:
 “SISTEMA DE INFORMACION GEOGRAFICO DEL CONTROL Y

SEGUIMIENTO DE OBRAS MUNICIPALES” (SUB-ALCALDIA DE
COTAHUMA) Avalos Mendoza, Edith Roxana - 2007, en este proyecto de grado
apreciamos la implementación de un sistema de información geográfica para una
mejor gestión sobre el control y seguimiento del estado de las obras municipales de la
Sub-Alcaldía de Cotahuma para lograr una oportuna toma de decisiones y un adecuado
desarrollo de las obras del macro distrito.
 “CONTROL Y SEGUIMIENTO FISICO FINANCIERO DE EJECUCION DE
PROYECTOS GMLP CASO: MALLASA” Alanoca Alanoca, Wilma - 2007, en
este proyecto apreciamos la implementación de un sistema de información para el
control y seguimiento físico financiero de ejecución de proyectos para el Gobierno
Municipal de Mallasa, que permitirá disponer información oportuna, para la adecuada
toma de decisiones.
 “SISTEMA DE CONTROL Y SEGUIMIENTO DE PROYECTOS Caso:
OFICIALIA MAYOR DE PROTECCION SOCIAL, Dirección de Educación -
GAMEA”, este proyecto implanta un producto de software para el Control y
Seguimiento de proyectos en el área de educación que optimice el desarrollo de los
mismos, solucionando problemas relacionados con el monitoreo y control en la
Dirección de Educación GAMEA.
1.3. PLANTEAMIENTO DEL PROBLEMA
Para la adjudicación de los diferentes proyectos distritales es importante la ejecución del POA
(dentro del cual se encuentran los proyectos menores de nuestro interés) y ello contempla dos
aspectos muy importantes la ejecución financiera y física de los mismos. Y, dicho sea de paso
17
estos dos aspectos son algunos de los parámetros para medir la eficiencia y eficacia de la
institución. Entonces se hace imprescindible el control y seguimiento de los proyectos.
En la actualidad cada una de las unidades; proyectos, licitación, supervisión y fiscalización,

por las que atraviesan cada uno de los proyectos, realizan de manera independiente el
seguimiento y control de los proyectos en hojas de cálculo de Excel. Esta información, es
posteriormente centralizada por un operador para la emisión de informes, reportes estadísticos
y consiguientemente la toma de decisiones. Por esta situación es que la información no se la
obtiene de manera inmediata, fiable y oportuna.
Por lo tanto no se tiene mucha información precisa y fiable con respecto a los diferentes
proyectos municipales que se están ejecutando en los diferentes distritos municipales de la
Urbe Alteña.
Actualmente no se cuenta con un sistema automatizado para el control y seguimiento de

proyectos menores. Tanto el control como el seguimiento se realizan de manera manual
registrándolos como archivos y carpetas.
1.3.1. Problemas específicos
Después de haber realizado un estudio sobre la situación actual con respecto a las obras
municipales a continuación se detallan los diferentes problemas identificados:
 No se tiene un acceso inmediato a la información referente a los proyectos.

 La centralización manual de la información genera errores en los datos, además que
existe una pérdida de tiempo.
 Falta de control de los recursos humanos que invierten en la ejecución de los
proyectos, haciendo conocer la eficiencia de los mismos.
 Demora en la emisión de reportes estadísticos actualizados: por estado, ejecución
física y financiera, por tal situación la toma de decisiones es tardía.
 En cuanto a las obras, existe la necesidad de localizarlos geográficamente,
permitiendo así conocer donde se requiere mayor atención.
18
1.4. FORMULACION DEL PROBLEMA
Debido a la descentralización de las Sub alcaldías en el municipio de El Alto, existe

información que no está debidamente registrada ni ordenada. La poca información que existe
digitalizada se encuentran en varios archivos sin clasificar y a consecuencia de esto existen
proyectos distritales que no son debidamente ordenados y en su gran mayoría son proyectos
que no se pueden ser supervisados. Es necesario centralizar toda esa información a través de
un sistema, realizando el registro de todos los proyectos que se están ejecutando de parte de
las sub alcaldías municipales, que facilite y mejore el control y seguimiento de los proyectos
distritales previa aprobación en el POA de tal manera que a través de este sistema se permita
disponer de información oportuna rápida y actualizada con respecto a la ejecución de los
proyectos distritales a través de reportes, Fichas técnicas para una adecuada toma de
decisiones en cuanto a la ejecución física y financiera de los proyectos.
1.5. OBJETIVOS
1.5.1. Objetivo general
“Desarrollar un sistema de Información vía Web para realizar el Control y Seguimiento de

Proyectos Distritales del Municipio de El Alto, de modo que permita disponer información
oportuna, rápida y actualizada, para una adecuada toma de decisiones en cuanto a la ejecución
física y financiera de los proyectos”.
1.5.2. Objetivos específicos
 Implementar una base de datos para el registro de todas las actividades involucradas en
la ejecución de los proyectos, de tal manera permitir realizar el seguimiento respectivo
de las mismas.
 Desarrollar módulos para el control y seguimiento de los proyectos.
 Desarrollar módulos para poder administrar permisos de accesos al sistema para los
diferentes usuarios.
 Elaborar el diseño de informes y reportes estadísticos para proporcionar información
que ayuden a la toma de decisiones.
 Capacitar al personal para el buen funcionamiento del Sistema
19
1.6. JUSTIFICACION
1.6.1. Justificación social
La necesidad de un control social sobre los proyectos que ejecuta el Gobierno Autónomo
Municipal de El Alto es evidente, debido al alto compromiso que se tienen con las juntas de
vecinos de la urbe alteña, en gran medida por las malas experiencias del pasado, es en este
sentido que el Software a desarrollar beneficiara tanto a la institución como también a la
población alteña en general.
Con la implantación del sistema los usuarios finales; funcionarios de las Sub-Alcaldías
responsables de los proyectos, realizaran de manera más fácil, adecuada, ordenada y
responsable el control y seguimiento de los diferentes proyectos correspondientes a su distrito
municipal, contribuyendo así a una administración eficiente y eficaz.
Asimismo, la población en general de la ciudad de el alto tendrá a su disposición información

actualizada de los proyectos que se están ejecutando permitiendo así la transparencia
administrativa, pues ellos también serán participes de dar seguimiento y control a los
proyectos de su Distrito Municipal.
1.6.2. Justificación Técnica
El sistema informático de control y seguimiento de proyectos, beneficia a la institución con el

manejo adecuado y responsable de la información, para tal hecho establece nuevas políticas de
orden y de manejo de proyectos. La forma en la que dará a conocer informes previos en base a
reportes dará significancia en el orden y en el tiempo de ejecución.
1.6.3. Justificación Económica
El sistema tiende a incrementar el grado de eficiencia y el desempeño de las funciones que

cumple el personal de las diferentes Sub-Alcaldías encargadas del seguimiento y control de las
obras, logrando optimizar el uso de los recursos humanos y tiempo.
20
1.7. METODOLOGIA, TECNICAS Y HERRAMIENTAS
La metodología que se utilizara para el desarrollo del proyecto es la Metodología RUP

(proceso Unificado Racional) que es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para
el análisis, implementación y documentación de sistemas orientados a objetos.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías

adaptables al contexto y necesidades de cada organización.
Sus principales características principales (Proceso iterativo e incremental) hicieron que esta
metodología sea usada por varios desarrolladores de software. En el presente proyecto no se
hará la excepción.
La técnica que utilizaremos para el desarrollo será la Web 3.0 donde la implementación deberá
ser una optimización de recursos tanto en imagen y en código para un mejor acceso en la Web.
En cuanto a las herramientas trabajaremos para la programación PHP5, gestor de base de
Datos PostgreSQL 9.1 o superiores con su extensión PostGIS.
1.8. ALCANCES Y APORTES
1.8.1. Alcances
En cuanto al alcance del proyecto, será el diseño y la implementación de un sistema de control

y seguimiento físico y financiero de ejecución de proyectos, brindando información
actualizada de cada proyecto, emisión de reportes y la capacitación del personal de las sub
alcaldías municipales en el manejo del sistema automatizado.
El presente proyecto, se limitara básicamente al desarrollo del objetivo principal y los

objetivos específicos:
 Geográficamente se pretende llegar a nivel municipal, ya que los proyectos que se

encuentran en ejecución se encuentran en toda la jurisdicción municipal de la ciudad
de El Alto.
 Módulo de Autentificación (Login).
21
 Módulo de Registro de Proyectos
 Módulo de Seguimiento de Proyectos
 Módulo de Supervisión de obras
 Módulo de reportes (Informes, Mapas, georeferenciacion)
 Módulo de Alertas tempranas.
1.8.2. Aportes
Los aportes del sistema son:
 El principal aporte a la institución es el software del sistema de información, que

apoyara las sub alcaldías municipales, automatizando los procesos y reportes,
manejando la información de manera oportuna y segura, esto con el fin de mejorar el
tiempo de respuesta y servicio a la población alteña en general.
 El sistema de información será una herramienta útil ya que para su desarrollo se
emplea métodos que permitirán una mayor capacidad a los cambios, facilitando la
operación y mantenimiento del software.
 Se entregara la documentación del proyecto con el manual de usuario a la unidad
interesada para las actualizaciones o desarrollo de nuevos proyectos.
22
CAPITULO 2
MARCO TEORICO
2.1. INTRODUCCION
El marco teórico constituye el sustento que fundamenta el problema de investigación y que se

elabora a partir de conceptos y teorías ya existentes en fuentes diversas.
Es decir, dando una pequeña descripción de los conceptos fundamentales de las herramientas y
técnicas que contribuyen en el desarrollo e implementación del software.
2.2. Marco institucional
La Dirección de Tics y Desarrollo Organizacional se encuentra en la avenida 6 de marzo,

calle 13 primer piso, Secretaria Municipal de Planificación del desarrollo en instalaciones del
G.A.M.E.A. zona 12 de octubre, la estructura organizacional de la dirección es la siguiente
(Ver figura 2.1)
Figura 2.1. Estructura Organizacional
FUENTE: [GAMEA, 2015]

2.2.1. Misión
Implementar estrategias orientadas a la mejora continua, administrando los recursos
informáticos de la plataforma tecnológica y coadyuvar a la racionalización y optimización de
los procesos e instrumentos de gestión interna administrativa de las unidades organizacionales
de la institución para consolidar la capacidad organizativa del Gobierno Autónomo Municipal
de El Alto.
23
2.2.2. Visión
Coadyuvar en el proceso de evaluación sobre el grado de cumplimiento de las funciones de las

unidades organizacionales del GAMEA. Realizando la actualización a los reglamentos
específicos de los sistemas de administración que establecen la Ley N° 1178 de
Administración y Control Gubernamentales en coordinación con las unidades
organizacionales responsables de su aplicación.
2.2.3. Objetivos
 Realizar software a medida y de acuerdo a requerimiento de las diferentes unidades
del GAMEA.
 Realizar el mantenimiento permanente de los equipos de computación y la
actualización de los sistemas informáticos, transmisión, comunicación así como
velar por el bien funcionamiento de los mismos.
 Formular especificaciones técnicas y supervisar que estas se encuentren bien
elaboradas para luego dar el respectivo visto bueno.
 Evaluar e implementar soluciones informáticas que nos tengan a la par del avance
tecnológico y mejoren de este modo el desempeño de las actividades.
 Desarrollar y ejecutar sistemas de información y aplicaciones informáticas que
ayuden en el mejor desempeño de las labores en el GAMEA.
 Administrar y realizar mantenimiento a todas las bases de datos de información
dentro del GAMEA.
 Otras funciones asignadas por la autoridad competente.
2.2.4. Funciones y Atribuciones de la Dirección
 Desarrollar estrategias que permitan la implementación del modelo de gestión

tecnológica del Gobierno Autónomo Municipal de El Alto.
 Gestionar y desarrollar proyectos orientados a impulsar la Sociedad de la
información y reducir la brecha digital en el Municipio de El Alto a través del uso y
aplicación de las tecnologías de información y comunicación en todos los sectores
y ámbitos.
24
 Realizar el análisis, diseño e implantación del diseño organizacional en el marco
del Reglamento Específico del Sistema de Organización Administrativa (RE-SOA)
del GAMEA.
 Brindar asistencia técnica en temas de desarrollo organizacional a las unidades
organizacionales del GAMEA.
 Elaborar e implantar el Manual de Organización y Funciones (MOF), Manual de
Procesos y Procedimientos (MPP) y otros manuales que permitan operativizar los
sistemas de administración que establece la Ley Nº 1178 de Administración y
Control Gubernamentales en el GAMEA.
 Desarrollar, implantar y administrar la infraestructura de la red de datos y
comunicaciones que permitan la transmisión de información.
 Brindar asistencia y soporte técnico informático, adecuado, a todas las unidades
organizacionales del Gobierno Autónomo Municipal de El Alto.
 Gestionar la actualización o adecuación de los reglamentos específicos de los
sistemas de administración de la Ley Nº 1178 de Administración y Control
Gubernamentales.
 Capacitar al personal del GAMEA en aplicaciones informáticas en torno al uso de
las tecnologías de información y comunicación.
 Promover el desarrollar de sistemas y aplicaciones informáticas para mejorar los
servicios, utilizando técnicas, herramientas, y metodologías de última generación.
 Otras funciones asignadas por autoridad competente.
2.3. SISTEMAS DE INFORMACION (SI)
2.3.1. Definiciones
 “Un sistema de información automatizado o basado en computadoras, es la integración

de hardware, software, personas, procedimientos y datos. Todos estos elementos se
conjugan, trabajando juntos, para proporcionar información básica para la conducción
de la empresa. Esta información hace posible que las empresas lleven a cabo sus tareas
con mayor calidad y facilidad”. [RENA, 2008]
25
 “Un sistema de información es un conjunto de elementos que interactúan entre si con
el fin de apoyar las actividades de una empresa o negocio. Los elementos que
interactúan entre si son: personas, hardware, software y datos”. [PERALTA, 2007].
2.3.2. Componentes o elementos de un SI
Los elementos de un sistema de información son:
 Personas: Son los que utilizan el SI. Se pueden dividir en dos grandes grupos: los
usuarios finales y los especialistas o profesionales.
Los usuarios finales son aquellos que operan o interaccionan directamente con el
sistema e incluso, quienes reciben reportes o información generada por el sistema.
Entre los profesionales se encuentran: los analistas de sistemas, programadores,
administradores del sistema y los capacitadores.
 Hardware: Consiste en los equipos, dispositivos y medios necesarios que constituyen
la plataforma física mediante la cual, el sistema de información puede funcionar. Se
incluyen aquí, por supuesto, los que permiten las comunicaciones y los enlaces de red.
Estos recursos son por ejemplo, computadoras, monitores, impresoras, disquetes o
componentes de almacenamiento de información externos, disco óptico, papel de
impresión, cableado de red, y otros.
 Software o programas: Son el componente lógico, es decir, los programas, las rutinas
e instrucciones que conforman el sistema de información.
 Datos: Unidades de información que son almacenadas y generadas en el transcurrir de
la labor de la empresa. Los datos son almacenados en las denominadas bases de datos o
bases de conocimientos. [RENA, 2008].
26
Figura 2.2. Componentes de un Sistema
FUENTE: [RENA, 2008]
2.3.3. Actividades que realiza un SI
Un Si realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida

de información
 Entrada de Información: Es el proceso mediante el cual el SI toma los datos que

requiere para procesar la información. Las entradas pueden ser manuales o
automáticas. Las manuales son aquellas que se proporcionan en forma directa por
el usuario, mientras que las automáticas son datos o información que provienen o
son tomando de otros sistemas o módulos. Este último se denomina interfaces
automáticas.
 Procesamiento de Información: Es la capacidad del SI para efectuar cálculos de

acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden
efectuarse con datos introducidos recientemente en el sistema o bien con datos que
están almacenados. Esta características de los sistemas permite la transformación
de datos fuente en información que puede ser utilizada para la toma de decisiones,
lo que hace posible entre otras cosas, que un tomador de decisiones genere una
27
proyección financiera a partir de los datos que contiene un estado de resultados o
un balance general de una año base.
 Almacenamiento de Información: El almacenamiento es una de las actividades o

capacidades más importantes que tiene una computadora, ya que a través de esta
propiedad el sistema puede recordar la información guardada en la sección o
proceso anterior. Esta información suele ser almacenada en estructuras de
información denominados archivos. La unidad típica de almacenamiento son los
discos magnéticos o discos duros, los discos duros, los discos flexibles y los discos
compactos (CD-ROM).
 Salida de Información: La salida es la capacidad de un SI para mostrar la

información procesada o bien datos de entrada al exterior. Las unidades típicas de
salida son las impresoras, terminales, cintas magnéticas, la voz, los graficadores y
los plotters, entre otros. Importante aclarar que la salida de un SI puede constituir la
entrada de otro SI o modulo. En este caso también existe una interfaz automática
de salida. Por ejemplo, el sistema de control de clientes tiene una interfaz
automática de salida con el sistema de contabilidad, ya que genera las pólizas
contables de los movimientos procesales de los clientes. [IZAMORAR, 2015].
2.4. SISTEMAS DE INFORMACION GEOGRAFICA (SIG)
2.4.1. Definición
“Un SIG se define como un conjunto de métodos, herramientas y datos que están diseñados
para actuar coordinada y lógicamente para capturar, almacenar, analizar, transformar y
presentar toda la información geográfica y de sus atributos con el fin de satisfacer múltiples
propósitos. Los SIG son una nueva tecnología que permite gestionar y analizar la información
espacial y que surgió como resultado de la necesidad de disponer rápidamente de información
para resolver problemas y contestar a preguntas de modo inmediato. Existen otras muchas
definiciones de SIG, algunas de ellas acentúan su componente de base de datos, otras sus
funcionalidades y otras enfatizan el hecho de ser una herramienta de apoyo en la toma de
28
decisiones, pero todas coinciden en referirse a un SIG como un sistema integrado para trabajar
con información espacial, herramienta esencial para el análisis y toma de decisiones en
muchas áreas vitales para el desarrollo. Toda la generación de nueva información que puede
proveer un SIG depende significativamente de la información que posee la base de datos
disponible. La calidad de esta base de datos y sus contenidos determinan la cantidad y calidad
de los resultados obtenidos del SIG. [CARBONA Y MONSALVE, 2009]
Fig. 2.3. Definición simplificada de un SIG
FUENTE: [MENDOZA, 2009]
2.4.2. Importancia del SIG
Las soluciones para muchos problemas frecuentemente requieren acceso a varios tipos de
información que solo pueden ser relacionados por geografía o distribución espacial. Solo la
tecnología SIG permite almacenar y manipular información usando geografía y para analizar
patrones, relaciones y tendencias en la información, todo para contribuir a tomar mejores
decisiones. [CARBONA Y MONSALVE, 2009]
En general, un SIG debe tener la capacidad de dar respuesta a las siguientes preguntas:
 Localización: ¿Qué hay en…? Dónde está el Objeto A?

 Condición: ¿Dónde hay…? ¿Cuál es el camino más corto..?
 Evolución: ¿Qué ha cambiado desde…?
 Patrones: ¿Qué patrón existe…?
 Modelamiento: ¿Qué pasa si…?
29
Figura 2.4 Ejemplo de Uso de un SIG
2.4.3. Componentes de un SIG
Un SIG en funcionamiento integra cinco componentes clave: hardware, software, datos,

personal y métodos. [CARBONA Y MONSALVE, 2009]
Figura 2.5. Componentes de un SIG
30
2.4.3.1. Hardware
Este componente representa el soporte físico del SIG. Está conformado por las computadoras
donde se desarrollan las distintas tareas de administración y operación del sistema, por los
servidores donde se almacenan los datos y se ejecutan ciertos procesos, por los periféricos de
entrada (como mesas digitalizadoras, scanner, dispositivos de lectura de archivos, etc.), los
periféricos de salida (como los monitores, impresoras, plotter, etc.) y todos los componentes
de la red informática. [CARBONA Y MONSALVE, 2009].
2.4.3.2. Software
Este componente representa el soporte lógico del sistema. Está conformado no sólo por el
software y las aplicaciones SIG, sino también por los sistemas operativos, los sistemas de
administración de bases de datos (RDBMS), los lenguajes de programación necesarios para el
mantenimiento y desarrollo de las aplicaciones y otros programas especializados, como para el
procesamiento de imágenes satelitales, de dibujo (CAD), paquetes estadísticos, etc.
A nivel de software SIG, actualmente pueden encontrarse una gran variedad de productos, con
distintos fines, capacidades, tipos de datos que pueden trabajar, simplicidad de operación y
aprendizaje, niveles de costos, etc. Según los distintos usuarios del sistema, deberán definirse
y adquirirse los software SIG adecuados para cada puesto de trabajo. [CARBONA Y
MONSALVE, 2009]
2.4.3.3. Datos
Queda representado físicamente por una base de datos almacenada en un servidor, en el caso
de sistemas corporativos o por un conjunto de archivos almacenados en el puesto de trabajo,
en el caso de SIG pequeños u orientados a un proyecto específico.
La base de datos contiene el conjunto de datos que representan (a través de un modelo) el

espacio geográfico sobre el cual la organización actúa y se dirigen sus políticas y decisiones.
La BD queda conformada por elementos gráficos, que definen la geometría de los elementos
geográficos y atributos, que son las características de dichos elementos. Los elementos
gráficos quedan definidos por coordenadas que, a la vez que definen la forma y dimensiones,
31
permiten ubicar desde un punto de vista absoluto (coordenadas geográficas o proyectivas en
un sistema real) los elementos e identificar sus relaciones respecto de los demás elementos
(topología). [CARBONA Y MONSALVE, 2009]
2.4.3.4. Recursos humanos
Los recursos humanos que administrarán y utilizarán el SIG son otro componente del sistema,
tan importante cuanto los demás. Sin embargo, la preparación de este componente no resulta
tan sencilla como los componentes técnicos. Trabajar con los recursos humanos, conformar los
equipos, producir cambios en sus hábitos de trabajo, brindar capacitación y obtener resultados
en los procesos de trabajo, son tareas difíciles de llevar adelante y la importancia y esfuerzos
que se dediquen en este sentido no deben ser subestimados.
Al diseñar e implementar un SIG, deben identificarse claramente los distintos roles de los
recursos humanos clave. Además de los usuarios finales, normalmente es imprescindible la
conformación de áreas que sirvan de soporte especializado al sistema, donde pueden
encontrarse programadores, analistas de sistemas, administradores de bases de datos,
especialistas en cartografía, etc.
La capacitación es el medio para gestionar adecuadamente los recursos humanos y obtener los
cambios necesarios para su adecuado funcionamiento, debe ser vista como un “proceso” en el
que se adquieren “nuevos conocimientos, habilidades y actitudes” y no simplemente como
“cursos de operación” de aplicativos. [CARBONA Y MONSALVE, 2009]
2.4.4. Tipos de SIG
La mayoría de los elementos que existen en la naturaleza pueden ser representados mediante
formas geométricas (puntos, líneas o polígonos, esto es, vectores) o mediante celdillas con
información (raster). Son formas de ilustrar el espacio intuitivo y versátil, que ayudan a
comprender mejor los elementos objeto de estudio según su naturaleza. [JIMDO].
En función de la forma de representar el espacio de la que hacen uso podemos clasificar los
SIGs en dos grandes modelos o formatos:
32
Figura 2.6. Modelo vectorial y raster
FUENTE: [CIAF]
La elección de un modelo u otro dependerá de si las propiedades topológicas son importantes

para el análisis. Sí es así, el modelo de datos vectorial es la mejor opción, pero su estructura
de datos, aunque muy precisa, es mucho más compleja y esto puede ralentizar el proceso. Por
ello, si el análisis que nos interesa no requiere acudir a las propiedades topológicas, es mucho
más rápido, sencillo y eficaz el uso del formato raster.
También es más fácil decantarse por una estructura de datos vectorial cuando hay que reflejar
más de un atributo en un mismo espacio. Usar un formato raster nos obligaría a crear una capa
distinta para cada atributo. [JIMDO].
2.4.4.1. Modelo vectorial
El modelo vectorial constituye una codificación de los datos geográficos en la que se

representa una variable geográfica por su geometría, independientemente de su escala y son
almacenados con un formato digital fácilmente convertible en un dibujo; las porciones del
territorio y su representación digital suelen constituir una lista de coordenadas de puntos y
vértices que definen la geometría de los elementos. Su codificación se realiza a través de una
base de datos de tipo relacional asociada a la representación gráfica. El modelo vectorial, por
contraposición al modelo ráster, es una representación de objetos discretos o discontinuos: una
carretera es un objeto discreto, una casa, una torre eléctrica, etc. Los objetos en este modelo se
representan mediante primitivas geométricas con una serie de atributos asociadas a dichas
33
geometrías. Esa es precisamente la gran ventaja del modelo vectorial, frente al ráster que tan
sólo puede tener un valor por celda, es decir un único atributo, un conjunto de datos vectorial
puede tener (al menos teóricamente) infinitos atributos asociados a una geometría. El modelo
vectorial se sirve normalmente de tres elementos geométricos para representar la realidad:
Punto, Línea y Polígono. El punto se emplea para representar elementos que por su escala no
es posible o deseable representar mediante un polígono, es la simple localización de un
fenómeno. Las torres de electricidad, los vértices geodésicos, pozos, etc. se suelen representar
mediante puntos. Aunque también se pueden utilizar para simplificar información a
determinadas escalas, por ejemplo para representar núcleos de población en un mapa del
mundo. La línea o polilínea se emplea para representar elementos lineales como: vías de
comunicación, la hidrografía, curvas de nivel, líneas eléctricas, etc. Al igual que los puntos
también se utilizan para simplificar entidades que pueden ser polígonos a escalas grandes El
polígono representa superficies como parcelas, ámbitos de bienes protegidos, núcleos de
población, etc. Es la geometría que transmite una mayor cantidad de información, por lo que
también admite operaciones de análisis más complejas. [JIMDO]
2.4.4.2. Modelo Raster
El modelo RÁSTER supone la existencia de un área de estudio sobre la cual se sobrepone un

sistema de cuadrículas, donde cada unidad se denomina celda y tienen la misma forma.
Simplificando un poco las cosas, una imagen que abrimos en Photoshop es un conjunto de
datos ráster. Es decir, básicamente, los conjuntos de datos ráster son matrices (filas y
columnas) de celdas, cada una de ellas con un valor asignado, estas celdas se representan
gráficamente mediante píxeles, lo que hace que en apariencia se asemejen bastante a una
imagen digital corriente y moliente. En efecto, un conjunto de datos ráster puede representar
colores (como en el caso de las ortofotos), pero también puede almacenar valores relativos a
usos del suelo, temperaturas, etc.
Los datos ráster se almacenan en múltiples formatos, desde los más comunes como TIFF o
JPG que solo permiten almacenar valores enteros en el rango del 0 al 255, a formatos
específicos para almacenar datos precisos con decimales. El tamaño de la celda va ligado a la
cantidad o detalle de la información que se almacena, esta relación se denomina resolución y
es inversamente proporcional al tamaño de la celda, es decir, a mayor tamaño de celda, menor
34
resolución, a menor tamaño de celda, más celdas serán necesarias para representar un mismo
fenómeno. Un ejemplo claro lo tenemos en las ortofotografías digitales, en las que se suele
citar la resolución: de 1 metro, de 0,5 m., etc. esto significa que un píxel o celda en la imagen
corresponde con 1 metro en la realidad en el primer caso, y con 0,5 m. en el segundo.
[JIMDO].
2.4.5. Ventajas del SIG
 Manejo de información, ya sea para la elaboración de las investigaciones o en su

defecto para la actualización de la información, empleando las metodologías
usualmente manejadas por un SIG.
 El desarrollo del análisis espacial, multidisciplinariamente nos permitirá elaborar
diversos modelos de desarrollo a favor de nuestra gestión.
 La manipulación de la información y utilización sobre ellas es de acuerdo a la
habilidad del administrador para obtener su mejor comunicación. [CITES, 2009]
2.4.6. Tareas de un SIG
Los sistemas de información geográficos de propósitos generales esencialmente realizan cinco

procesos o tareas: [ESIGSON’S, 2009]
 Entrada de información: Antes de que los datos geográficos se puedan utilizar en un

SIG, los datos se deben convertir en un formato digital conveniente. El proceso de
convertir datos de los mapas de papel en archivos electrónicos se llama digitalizar.
La tecnología moderna de los SIG puede automatizar este proceso completamente para
los proyectos grandes usando tecnología de exploración; trabajos más pequeños pueden
requerir digitalización manual (usando una tabla digitalizadora). Muchos tipos de datos
geográficos ya existen en formatos compatibles con SIG. Estos datos pueden ser
obtenidos de proveedores de datos y ser cargados directamente en un SIG.
 Manipulación: Es probable que los tipos de datos requeridos para un proyecto

determinado de SIG necesiten ser transformados o manipulados de una cierta manera
para hacerlos compatibles con su sistema. Por ejemplo, la información geográfica está
35
disponible en diversas escalas (como líneas centrales de calles; límites menos
detallados para censos; y códigos postales en un nivel regional). Antes de que esta
información pueda ser integrada, debe ser transformada a la misma escala (grado de
detalle o de exactitud). Esto podía ser una transformación temporal para los propósitos
de la visualización o permanente requerido para el análisis. La tecnología de SIG
ofrece muchas herramientas para manipular datos espaciales y para no tomar en cuenta
datos innecesarios:
 Gerencia: Para los proyectos pequeños de GIS puede ser suficiente salvar la
información geográfica como archivos simples. Sin embargo, cuando los volúmenes de
datos llegan a ser grandes y el número de los usuarios de datos se convierte en más que
unos cuantos, es a menudo mejor utilizar un sistema de administración de base de
datos para ayudar a guardar, ordenar, y manejar los datos. Un DBMS no es nada más
que el software para manejar una base de datos.
Hay muchos diversos diseños de DBMS, pero en los SIG el diseño relacional ha sido el
más útil. En el diseño relacional, los datos son almacenados conceptualmente como
una colección de tablas. Los campos comunes en diversas tablas se utilizan para hacer
una conexión entre ellos.
Este diseño asombrosamente simple se ha utilizado tan extensamente sobre todo

debido a su flexibilidad y robustez en aplicaciones dentro y fuera de los SIG.
 Consultas y análisis: Una vez que se tiene un SIG en funcionamiento con su

respectiva información geográfica, es posible comenzar a hacer preguntas simples por
ejemplo:
¿Qué poblaciones están en peligro en caso de contingencia volcánica?

¿Cuáles son las rutas de evacuación?
¿Dónde se encuentran los refugios para damnificados?
Y preguntas analíticas por ejemplo:
¿Cuál es la ruta de evacuación más corta?
¿Cuáles son los albergues más cercanos a San Mateo Ozolco?
36
Un GIS proporciona capacidades simples de interrogación con el uso del mouse y
herramientas sofisticadas de análisis para recuperar la información oportunamente a los
encargados y a los analistas por igual. La tecnología SIG realmente hace lo suyo
cuando se utiliza para analizar datos geográficos para buscar modelos y tendencias y
para emprender escenarios de alcance supuestos, pero los dos siguientes son
especialmente importantes.
Análisis de Proximidad
¿Cuántas localidades se encuentran a menos de 10 kilómetros del cráter?

¿Cuál es el número total de rutas de evacuación que tiene una población?
¿Qué proporción de la población debe ser evacuada en caso de contingencia?
Para contestar a tales preguntas, la tecnología de SIG utiliza un buffering llamado de

proceso para determinar el lazo de la proximidad entre las características.
Análisis Del Recubrimiento
La integración de diversas capas de datos implica un proceso llamado recubrimiento.

Esto podría ser una operación visual, pero las operaciones analíticas requieren una o
más capas de datos para ser ensambladas físicamente. Este recubrimiento, o
ensamblaje espacial, puede integrar los datos sobre suelos, colinas, vegetación, o
información de terrenos con el gravamen de impuesto.
Existen diferentes métodos de consulta dentro de un SIG y diferentes modos de

desplegar los resultados. Ya sea, obtener información espacial o atributos de una BD, o
a través de una consulta alfanumérica obtener un resultado gráfico o alfanumérico o de
una consulta grafica obtener un resultado gráfico o estadístico.
 Visualización: Para muchos tipos de operaciones geográficas el resultado final se

visualiza lo mejor posible como una correspondencia gráfica.
Los mapas son muy eficientes para guardar y comunicar la información geográfica.
Mientras que los cartógrafos han usado los mapas por milenios, un SIG proporciona
37
nuevas herramientas para ampliar el arte y la ciencia de la cartografía. Las
visualizaciones con correspondencia se pueden integrar con los informes, las vistas
tridimensionales, las imágenes fotográficas, y otras salidas como multimedia. La
tecnología actual de los SIG nos permite personalizar el software de manipulación de
datos dependiendo de las necesidades del usuario final. [ESIGSON’S, 2009]
2.5. PROCESO DE DESARROLLO DE SOFTWARE
2.5.1. Proceso Unificado de desarrollo (RUP)
El proceso unificado de Rational es un proceso de desarrollo de software “sin embargo es más

que un simple proceso; es un marco de trabajo genérico que puede especializarse para una
gran variedad de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyectos”.[JABORU,
2000].
RUP destaca tres características esenciales:
 Proceso dirigido por casos de uso: Dirigido por casos de uso quiere decir que el
proceso sigue un hilo – avanza a través de una serie de flujos de trabajos que parten
de los casos de uso. Un caso de uso es un fragmento de funcionalidad del sistema
que proporciona al usuario un resultado importante. Todos los casos de uso juntos
constituyen el modelo de casos de uso e cual describe la funcionalidad de todo el
sistema. Sin embargo, los casos de uso no solo son una herramienta para
especificar requisitos. También guían su diseño, implementación, y prueba; estos
guían el proceso de desarrollo.
 Proceso centrado en la arquitectura software: La arquitectura en un sistema de
software se describe mediante diferentes vistas de sistema en construcción. La
arquitectura es una vista del diseño con las características más importantes
resaltadas, dejando los detalles de lado – o más bien, dejando los detalles para
vistas o modelos de niveles más bajos -.
38
 Iterativo e incremental: Es práctico dividir en partes más pequeñas o en mini
proyectos, cada mini proyecto es una mini iteración que resulta en un incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos, al
creciendo de producto. La iteración reconoce que los usuarios y sus requisitos no
pueden definirse completamente al principio. Típicamente se refinan en iteraciones
sucesivas.
En síntesis, con RUP se tienen los mecanismos de asignar de manera disciplinada las tareas y
responsabilidades. Su objetivo principal es asegurar la producción de calidad dentro de los
plazos establecidos. [JABORU, 2000].
2.5.1.1. Fases y flujos de trabajo
RUP divide el proceso en cuatro fases dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se hace un mayor o menor hincapié en las
distintas actividades. En la siguiente figura se muestra cada una de las fases y flujos de
trabajo:
Fig. 2.7. Estructura del RUP
FUENTE: [JABORU, 2000]
39
 FASES DE TRABAJO
Durante la fase de inicio o gestación, se desarrolla una descripción del producto
final a partir de una buena idea y se presenta un análisis del negocio para el
producto. Esencialmente esta fase corresponde a obtener los siguientes artefactos:
modelo de casos de uso que describan las principales funciones del sistema y la
arquitectura inicial; esbozo que muestra los subsistemas más primordiales.
Además, se identifican y priorizan los riesgos más importantes, se planifica en
detalle la fase de elaboración, y se estima el proyecto de manera aproximada.
Durante la fase de elaboración, se especifican en detalle la mayoría de los casos
de uso del producto y se diseña la arquitectura del sistema. La relación entre la
arquitectura del sistema y el propio sistema es primordial.
La arquitectura se expresa en forma de vistas de todos los modelos del sistema, los
cuales juntos representan al sistema. Esto implica que existen varias
arquitectónicas del modelo de casos de uso, de modelos de análisis, del modelo de
diseño, de modelo de implementación y modelo de despliegue.
Durante la fase de construcción se crea el producto. En esta fase, gran parte del
trabajo es la programación y pruebas; se documenta tanto el sistema construido
como el manejo del mismo (manual del usuario). Al mismo tiempo en esta fase se
proporciona un producto construido junto con la documentación.
Finalmente, en la fase de transición del producto se convierte en versión beta. En
la versión beta un número reducido de usuarios con experiencia prueba el producto
e informa de defectos y deficiencias, los desarrolladores corrigen el/los problemas
e incorporan algunas de las mejoras sugeridas. [JABORU, 2000]
 FLUJOS DE TRABAJO
Modelado del negocio
Para capturar los requisitos y construir un sistema correcto es necesario poseer un
firme conocimiento del contexto en que se emplazara el sistema. Para ellos el
modelo de negocio y de dominio serían los apropiados. El modelo de negocio es
una técnica para comprender los procesos de negocio de una organización, por lo
que no será útil de tratarse otro tipo de sistemas diferentes a este. En cambio, el
40
modelo de dominio se centra en la captura de cosas u objetos que existen, o los
eventos que suceden en el entorno en el que trabaja el sistema. Este último se ajusta
a cualquier tipo de sistemas.
Captura de requisitos
Un punto fundamental en el proceso de desarrollo de software. La captura de
requisitos es el proceso de averiguar lo que se debe construir, en este sentido los
artefactos que resultan son:
 Especificación de requerimientos funcionales y no funcionales
 Modelo de casos de uso: contiene a actores y casos de uso
 Descripción de los casos de uso más relevantes del sistema
 Esbozos de interfaces de usuario
 Glosario de términos
Análisis
Este flujo de trabajo tiene como propósito principal analizar los requisitos descritos
en la captura de requisitos, mediante su refinamiento y estructuración. El objetivo
de esto es: (1) lograr una comprensión mas precisa de los requerimientos, y (2)
obtener una descripción de los requisitos que sea fácil de mantener y que nos ayude
a dar estructura al sistema en su conjunto – incluyendo su arquitectura.
Los artefactos a realizarse son:
 Modelo de análisis: diagrama de clases

 Descripción de interacciones: diagrama de colaboración
Diseño
En el diseño modelamos el sistema y encontramos su forma para que soporte todos

los requisitos (incluyendo los requisitos no funcionales y otras restricciones). Una
entrada esencial en el diseño es el resultado en el análisis, esto es, el modelo de
análisis. Resultados a obtener:
 Diagrama de clases completo

 Modelos de interacción: Diagramas de secuencia
 Modelos de despliegue: diagrama de despliegue
41
Implementación
En la implementación empezamos con el resultado del diseño e implementamos el
sistema en términos de componentes, es decir: ficheros de código fuente, scripts,
ficheros de código binario, ejecutables, etc.
Prueba
En el Flujo de trabajo de la prueba verificamos el resultado de la implementación
probando cada construcción, para luego hacer la entrega final del producto a los
clientes. [JABORU, 2000]
2.5.2. Lenguaje Unificado de modelado (UML)
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y

documentar los elementos que forman un sistema software orientado a objetos. Sea convertido
en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los
tres métodos mas usados de orientación a objetos: Grade Booch, James Rumbaugh e Ivar
Jacobson. Estos autores fueron contratados por la Empresa Racional Software. Para crear una
notación unificada en la que se basa la construcción de sus herramientas CASE. [Bouch,
1999].
Sin embargo no dice que modelos crear ni cuando se debería de crear, esta es la tarea del
proceso de desarrollo de software.
UML es un lenguaje para documentar; cubre toda la documentación de todas las decisiones de
análisis, diseño e implementación que debe realizarse al desarrollar un sistema, proporciona un
lenguaje para modelar las actividades de planificación de proyectos.
El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar

para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos
diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos
usados para el diseño orientado a objetos, ahora los modeladores sólo tienen que aprender una
única notación. UML se puede usar para modelar distintos tipos de sistemas: sistemas de
42
software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve
diagramas en los cuales modelar sistemas. [LAR, 2000].
 Diagrama de Casos de Uso
Un caso de uso es una descripción de las acciones de un sistema desde el punto de vista del
usuario. Para los desarrolladores de sistemas, esta es una herramienta muy valiosa, puesto
que es una técnica para especificar la funcionalidad y el comportamiento de un sistema
mediante su iteración con los usuarios y/o otros sistemas. Es decir ayuda a obtener los
requerimientos desde el punto de vista de os usuarios.
Fig.2.8. Descripción de los elementos de un modelo de casos de uso:
Actor, es una entidad externa del sistema que de alguna

manera participa en la historia del caso de uso.
Caso de Uso, se representa mediante una elipse.
Asociación, elemento que conecta el actor con el caso de uso.
Extensión, un caso de uso extiende al original dado que

agrega otros pasos a la secuencia del caso de uso existente.
Inclusión, Si los pasos en una situación dentro de un caso de

uso son los mismos que los de otro, entonces podemos
adicionar otro caso de uso que incluya los pasos similares.
FUENTE: [QUICENO, 2010]
 Diagrama de Secuencia
Describe el comportamiento dinámico del sistema de información haciendo énfasis en la

secuencia de los mensajes intercambiados por los objetos.
43
Fig.2.9. Elementos de un diagrama de secuencia
En un diagrama de secuencia los

objetos se colocan de izquierda a
derecha en la parte superior. Cada
parte de vida de un objeto es una
línea discontinua que se desplaza
hacia abajo del objeto.

 Diagrama de Colaboración
Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa
las interacciones entre objetos organizados alrededor de los objetos y sus vinculaciones. A
diferencia de diagrama de secuencia, un diagrama de colaboraciones muestra las relaciones
entre los objetos, no la secuencia en el tiempo en que se producen los mensajes.
Fig.2.10. Modelo de diagrama de colaboración
En un diagrama de colaboración,
para representar un mensaje,
dibujara una flecha cerca de la
línea de asociación que apuntara
al objeto receptor. El tipo de
mensaje se mostrara cerca de la
flecha.
 Diagrama de Clases
Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones y las

relaciones entre estos; los diagramas de clases muestran el diseño del sistema desde un
punto de vista estático.
44
Fig.2.11. Elementos de un diagrama de Clases
 Diagrama de Estados
Representan la secuencia de estados por los que un objeto o una interacción entre objetos
pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo
que en conjunto se puede denominar, una máquina de estados.
Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento
se dice que ha sufrido una transición; existen varios tipos de transición entre objetos;
simples (normales y reflexivas) y complejas.
Fig.2.12. Elementos de un diagrama de estados
Simbologia
El icono para el estado es un rectángulo

de vértices redondeados, y el símbolo
de una transición es una línea continua
y una punta de flecha
45
 Diagramas de Actividad,
El diagrama de actividad del UML, es muy parecido a los viejos diagramas de flujo. Le
muestra los pasos (conocidos como actividades) así como de decisiones y bifurcaciones.
Es útil para mostrar lo que ocurre en un proceso de negocios e operación.
Fig.2.13. Representación de un diagrama de actividad
A cada actividad se presenta por un

rectángulo angosto con las esquinas
redondeadas. Una flecha representa la
transición de una a otra actividad. Cuenta
con un punto inicial y final.
 Diagrama de Componentes
Muestra un conjunto de componentes y sus relaciones. Un componente de software es una

parte física de un sistema, y se encuentra en la computadora, no en la mente del analista.
Puede tomarse como un componente: una tabla, archivo de datos, ejecutables, documentos,
y etc.
Existen tres tipos de componentes:
 Componentes de distribución, conforman el fundamento de los sistemas ejecutables

(p.e. DLL, ejecutables, controles ActiveX).
 Componentes para trabajar en el producto, a partir de los cuales se han creado los
componentes de distribución (archivos de bases de datos y de códigos).
 Diagrama de plataformas o despliegue
Ilustra la forma en que luce un sistema físicamente cuando sea conjugado. Muestra la
configuración de los componentes de hardware los procesos, los elementos de
procesamiento en tiempo de ejecución y los objetos que existen en tiempo de ejecución.
46
En este tipo de diagramas intervienen nodos, asociaciones de comunicación, componente
dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes.
2.6. ARQUITECTURA CLIENTE/SERVIDOR
La arquitectura cliente/servidor permite al usuario en una máquina, llamada el cliente, requerir

algún tipo de servicio de una maquina a la que está unida, llamado servidor, mediante una red
como una LAN (Red de Área Local) o una WAN (Red de Área Mundial). Estos servicios
pueden ser peticiones de datos de una base de datos, de información contenida en archivos o
los archivos en sí mismos, o peticiones de imprimir datos en una impresora asociada.
Un modelo Cliente Servidor, es un Sistema distribuido entre múltiples procesadores donde hay
clientes que solicitan servicios y servidores que los proporcionan.
En el modelo cliente-servidor, el cliente envía un mensaje solicitando un determinado servicio

a un servidor a un servidor (hace una petición), y este envía uno o varios mensajes con la
respuesta (provee el servicio) [Ver Figura 2.18]. En un sistema distribuido cada máquina
puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.
Fig. 2.14 Modelo Cliente-Servidor
FUENTE: [WEB05]
Los servidores hardware tienen fundamentalmente dos funciones, bien “servidores de

aplicaciones”, que alojan distintos tipos de programas que pueden llamarse desde y ejecutarse
en los terminales, bien “servidores de bases de datos”, que alojan archivos con datos que
pueden ser consultados y/o editados y modificados en las maquinas terminales o clientes; así
también pueden ser servidores de ambos tipos simultáneamente.
47
Si se trata de una red de área local, la interconexión entre el o los servidores y los clientes es
directa, mediante un sistema de cable o red inalámbrica; si es una red corporativa distribuida o
a través de Internet (ver figura 2.19), la interconexión es indirecta, y la alternativa más común
es mediante un modem y vía telefónica.
Una aplicación cliente/servidor típica es un servidor de base de datos al que varios usuarios
realizan consultas simultáneamente. El proceso cliente realiza una consulta, el proceso
servidor le envía las tablas resultantes de la consulta y el proceso cliente las interpreta y
muestra el resultado en pantalla. Los sistemas distribuidos pueden consistir en diversos
servidores que alojen datos, de forma que el cliente no tiene por qué conocer exactamente
donde se encuentran, simplemente hace una petición de servicio, y es el sistema servidor
encargado de localizarlos y proporcionar el resultado de la consulta al usuario que hizo la
petición.
Fig. 2.15 Arquitectura Cliente/Servidor
FUENTE: [WEB05]
2.7. HERRAMIENTAS DE DESARROLLO DE SOFTWARE
2.7.1. Lenguaje de programación PHP
PHP es un lenguaje de programación de uso general de código del lado del

servidor originalmente diseñado para el desarrollo web de contenido dinámico. Fue uno de los
48
primeros lenguajes de programación del lado del servidor que se podían incorporar
directamente en el documento HTML en lugar de llamar a un archivo externo que procese los
datos. El código es interpretado por un servidor web con un módulo de procesador de PHP que
genera la página Web resultante. PHP ha evolucionado por lo que ahora incluye también una
interfaz de línea de comandos que puede ser usada en aplicaciones gráficas independientes.
Puede ser usado en la mayoría de los servidores web al igual que en casi todos los sistemas
operativos y plataformas sin ningún costo.
PHP se considera uno de los lenguajes más flexibles, potentes y de alto rendimiento conocidos
hasta el día de hoy, lo que ha atraído el interés de múltiples sitios con gran demanda de tráfico,
como Facebook, para optar por el mismo como tecnología de servidor.
Fue creado originalmente por Rasmus Lerdorf en 1995. Actualmente el lenguaje sigue siendo
desarrollado con nuevas funciones por el grupo PHP. Este lenguaje forma parte del software
libre publicado bajo la licencia PHP, que es incompatible con la Licencia Pública General de
GNU debido a las restricciones del uso del término PHP. [MANRRIQUE, 2012]
Características de PHP
PHP presenta 4 grandes características:
 Velocidad: PHP no solo es rápido al ser ejecutado sino que no genera retrasos en la
máquina, por esto no requiere grandes recursos del sistema. PHP se integra muy bien
junto a otras aplicaciones, especialmente bajo ambientes Unix.
 Estabilidad: PHP utiliza su propio sistema de administración de recursos y posee de
un sofisticado método de manejo de variables, conformando un sistema robusto y
estable.
 Seguridad: PHP maneja distintos niveles de seguridad, estos pueden ser configurados
desde el archivo .ini
 Simplicidad: Usuarios con experiencia en C y C++ podrán utilizar PHP rápidamente.
Además PHP dispone de una amplia gama de librerías, y permite la posibilidad de
agregarle extensiones. Esto le permite su aplicación en múltiples áreas, tales como
encriptado, gráficos, XML y otras.
49
Ventajas adicionales de PHP
 PHP corre en (casi) cualquier plataforma utilizando el mismo código fuente,

 La sintaxis de PHP es similar a la del C, por esto cualquiera con experiencia en
lenguajes del estilo C podrá entender rápidamente PHP.
 PHP es completamente expandible y modificable. Está compuesto de un
sistema principal, un conjunto de módulos y una variedad de extensiones de
código.
 Muchas interfaces distintas para cada tipo de servidor. PHP actualmente se
puede ejecutar bajo Apache, IIS, AOLServer, Roxen yTHTTPD. Otra
alternativa es configurarlo como módulo CGI.
 Permite la interacción con gran cantidad de motores de bases de datos tales
como MySQL, MS SQL, Oracle, Informix, PostgreSQL, etc.
 PHP es Open Source, (código abierto ) esto significa que no depende de
ninguna compañía comercial y que no requiere de licencias. [MANRRIQUE,
2012]
2.7.2. Framework CodeIgniter php
Codeigniter es un framework para el desarrollo de aplicaciones en php que utiliza el MVC.

Permite a los programadores Web mejorar la forma de trabajar y hacerlo a mayor velocidad.
Al igual que cualquier framework está pensado para gente que tiene un dominio, al menos
medio, del lenguaje de programación PHP. Siempre hay que controlar PHP “a pelo” para
empezar a trabajar de forma eficiente con este framework (o cualquier otro). [ADWE, 2012]
Ventajas al utilizar Codeigniter
 Las páginas se procesan más rápido, el núcleo de CodeIgniter es bastante ligero.
 Es sencillo de instalar, basta con subir los archivos al ftp y tocar un archivo de
configuración para definir el acceso a la bd.
 Reutilización de código, desarrollo ágil.
 Existe abundante documentación en la red.
50
 Facilidad de edición del código ya creado.
 Facilidad para crear nuevos módulos, páginas o funcionalidades.
 Acceso a librerías públicas y clases. Entre otras, hay librerías para el login, paginador,
calendarios, fechas,….
 Estandarización del código. Fundamental cuando hay que tocar código hecho por otra
persona o cuando trabaja más de una persona en un mismo proyecto.
 URLs amigables con SEO. Hoy en día creo que nadie duda de la importancia del
posicionamiento web.
 Separación de la lógica y arquitectura de la web, el MVC.
 CodeIgniter es bastante menos rígido que otros frameworks. Define una manera de
trabajar, pero podemos seguirla o no (esto puede convertirse en un inconveniente
también). [ADWE, 2012]
2.7.3. Gestor de base de datos PostgreSQL
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo

licencia BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases
de datos de código abierto más potente del mercado y en sus últimas versiones no tiene nada
que envidiarle a otras bases de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilospara

garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el
sistema continuará funcionando.
A continuación se menciona los componentes más importantes en un sistema PostgreSQL.

[ENCALADA, GUAMAN, PUJOTA, 2012]
 Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL como

administrador de bases de datos. La conexión puede ocurrir via TCP/IP ó sockets
locales.
51
 Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el encargado de
escuchar por un puerto/socket por conexiones entrantes de clientes. Tambien es el
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 configuracion: Los 3 ficheros principales de configuración utilizados por
PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf
 Procesos hijos postgres: Procesos hijos que se encargan de autentificar a los clientes,
de gestionar las consultas y mandar los resultados a las aplicaciones clientes
 PostgreSQL share buffer cache: Memoria compartida usada por POstgreSQL para
almacenar datos en caché.
 Write-Ahead Log (WAL): Componente del sistema encargado de asegurar la
integridad de los datos (recuperación de tipo REDO)
 Kernel disk buffer cache: Caché de disco del sistema operativo.
 Disco: Disco físico donde se almacenan los datos y toda la información necesaria para
que PostgreSQL funcione
Ventajas
 Ampliamente popular - Ideal para tecnologías Web.

 Fácil de Administrar.
 Su sintaxis SQL es estándar y fácil de aprender.
 Footprint bajo de memoria, bastante poderoso con una configuración adecuada.
 Multiplataforma.
 Capacidades de replicación de datos.
 Soporte empresarial disponible.
Desventajas
 Sin experticia, configurar llega a ser un caos.

 Es fácil de vulnerar sin proteccion adecuada.
 El motor MyISAM es instalado por defecto y carece de capacidades de
integridad relacional.
52
 InnoDB genera mucho footprint en memoria al indizar.
 El toolset empresarial tiene un costo adicional por suscripción anual.
 Realizar revisiones llegar a ser una labor manual y tediosa para el DBA.
 Reducida cantidad de tipos de datos.
2.7.4. Postgis
PostGIS es un módulo que añade soporte de objetos geográficos a la base de datos objeto-
relacional PostgreSQL, convirtiéndola en una base de datos espacial para su utilización en
Sistemas de Información Geográfica. Se publica bajo licencia pública general de GNU.
Postgis ha sido desarrollado por la empresa canadiense Refraction Research, especializada en

productos “Open Source” entre los que habría que citar a Udig. PostGIS es hoy en dia un
producto veterano que ha demostrado versión a versión su eficiencia. En relación con otros
productos, PostGIS ha demostrado ser muy superior a la extensión geográfica de la nueva
versión de MySQL, y a juicio de muchos, es muy similar a la versión geográfica de la
archiconocida Oracle.
Un aspecto que tenemos que tener en cuenta es que PostGIS ha sido certificado en 2006 por el
Open Geospatial Consortium (OGC) lo que garantiza la intemporalidad con otros sistemas
también interoperables. PostGIS almacena la informacion geográfica en una columna del tipo
GEOMETRY, que es diferente del homónimo “GEOMETRY” utilizado por PostgreSQL,
donde se pueden almacenar la geometría en formato WKB (Well-Known Binary), aunque
hasta la versión 1.0 se utilizaba la forma WKT (Well-Known Text). [WIKI]
2.7.5. Mapserver
MapServer es un entorno de desarrollo en código abierto (Open Source Initiative) para la

creación de aplicaciones SIG en Internet/Intranet con el fin de visualizar, consultar y
analizar información geográfica a través de la red mediante la tecnología Internet Map
Server (IMS). MapServer no es un SIG completo, pero tampoco aspira a serlo.[WIKI].
Características
Sus características principales son:
 Se ejecuta bajo plataformas Linux/Apache y Windows (MS4W)
53
 Formatos vectoriales soportados: ESRI shapefiles, PostGIS, ESRI
ArcSDE, GML y otros muchos vía OGR.
 Formatos raster soportados: JPG, PNG, GIF, TIFF/GeoTIFF, EPPL7 y otros
vía GDAL.
 Fuentes TrueType
 Configuración "al vuelo" vía parámetros GET pasados por URL
 MapScrip proporciona una API para poder acceder a las funcionalidades de
MapServer mediante lenguajes de programación como PHP, Java, Perl, Python,
Ruby o C#.
 Soporte de estándares interoperables y conformes con Open Geospatial
Consortium, como WMS, SLD, WFS, WCS y SOS.
Funcionamiento del Programa
Su funcionamiento básico está configurado en un fichero de texto, que tiene la

extensión ".map". En este fichero, los datos del mapa se organizan en capas, a su vez
dividida en una o más clases, donde en cada una de las cuales se pueden definir
diferentes estilos visuales. Esta estructura permite la generación de mapas con una
definición de estilos muy flexible, que también puede depender de la escala del mapa.
El formato salida de MapServer, dependiendo de la solicitud, puede ser gráfico (mapa,

leyenda, escala, métricas, visión general) o alfanumérico (el resultado de una consulta
de datos alfanuméricos o espacial). El archivo ".map" también incluye la posibilidad de
fusionar la producción de una plantilla de HTML MapServer, para generar una página
web de lectura fácil y agradable.[WIKI].
2.8. PRUEBAS DEL SOFTWARE
El objetivo de la prueba es descubrir errores en el software. Es necesario crear buenos casos de

prueba (aquel que tiene una alta probabilidad de mostrar errores aun no descubiertos).
Una prueba tiene éxito si descubre un error no detectado hasta entonces.
Cualquier producto software se puede probar de dos formas:
54
2.8.1. Pruebas de caja negra
Permiten obtener conjuntos de condiciones de entrada que ejecuten todos los requisitos
funcionales de un programa.
Las pruebas de caja negra no son una alternativa a las técnicas de prueba de caja blanca. Es un
enfoque complementario.
Las pruebas de caja negra intentan hallar errores tales como:
Funciones incorrectas o ausentes

Errores de interfaz
Errores en estructuras de datos o en accesos a BD externas
Errores de rendimiento
Errores de inicialización y de determinación
2.8.2. Pruebas de caja blanca
Llamado también pruebas estructurales o prueba de caja transparente, esta se basa en la lógica
interna del codigo del sistema. Las pruebas contemplan los ditintos cambios que se pueden
generar gracias a las estructuras condicionales, a los distintos estados del mismo, etc.
[ANONIMO, 2011]
Figura 2.16. Pruebas de Software
FUENTE: [OSL2]
55
2.9. CALIDAD Y METRICAS DE SOFTWARE
2.9.1. Calidad de software
La calidad de software es un conjunto de cualidades que los caracterizan y determinan su

utilidad y existencia. Es imprescindible tener en cuenta tanto la obtención de la calidad como
su control durante todas las etapas del ciclo de vida de software.
El objetivo que persigue la calidad en los sistemas está orientado a:
 Mejorar la calidad del producto

 Proveer técnicas aplicadas para automatizar el manejo de datos
 Realizar una planeación eficaz de los sistemas
 Validad y controlar formalmente la calidad del trabajo realizado
 Cumplir los objetivos de la organización en cuanto a productividad de sub-
sistemas de cómputo.
2.9.2. Métricas de software
Es una aplicación continua de mediciones en el proceso de desarrollo de software y sus

productos, para suministrar información relevante a tiempo de tal manera mejorar tanto los
procesos como los productos.
Las métricas de software se clasifican según los criterios de:
Tabla 2.1 Clasificación de métricas de software
Métricas que definen la medición de la complejidad: volumen,

De complejidad
tamaño, anidaciones y configuración.
Métricas que definen la calidad del software: exactitud,
De calidad
estructuración o modularidad, prueba y mantenimiento.
Métricas que intentan valorar o medir las actividades de
De competencia productividad de los programadores con respeto a su certeza,
rapidez, eficiencia y competencia.
De desempeño Métricas que miden la conducta de módulos y sistemas de un
56
software bajo la supervisión del SO o hardware.
Métricas de experimentación y de preferencia: estilo de
Estilizadas
convenciones, limitaciones, etc.
FUENTE: [PEREIRA]
2.9.2.1. Métricas de calidad
El proceso del software y las métricas del producto son una medida cuantitativa que permite a
la gente del software tener una visión profunda de la eficacia del proceso del proceso del
software. Las métricas son también utilizadas para desarrollar los remedios y mejorar el
proceso de software. [PRESSMAN 2003]
Existen varios modelos que permiten medir la calidad del software [APR, 2015]:
 Modelo MCCALL(1977), describe la calidad como un concepto elaborado

mediante relaciones jerárquicas entre factores de calidad, en base a tres
criterios: características operativas, capacidad de cambios y adaptabilidad a
nuestros entornos.
 Modelo de FURPS(1987), desarrollado por Hewlett-Packard (HP), se utiliza
para establecer métricas de calidad para todas las actividades del proceso de
desarrollo de un software, inclusive de un sistema de información.
 Modelo de DROMEY(1996), resalta el hecho de que la calidad del producto es
altamente determinada por los componentes del mismo (Incluyendo
documentos de requerimientos, guías de usuarios, diseños y código).
 Normas ISO 9000: ISO/IEC 9126, es la que se utilizara para medir la calidad
del presente software.
 Modelo sistemático de calidad (MOSCA), entre otras.
2.9.2.2. Norma iso 9126
ISO 9126 es un estándar internacional para la evaluación del Software, fue originalmente
desarrollado en 1991 para proporcionar un esquema para la evaluación de calidad del
software.
57
La normativa define seis características de la aplicación, estas seis características son dividas
en un número de sub- características, las cuales representan un modelo detallado para la
evaluación de cualquier sistema informático.[WIKI].
Fig. 2.17. Atributos que abarcan las características de la norma ISO 9126
FUENTE: [PEREIRA]
Funcionalidad
La funcionalidad permite proveer funciones que cumplen las necesidades explicitas e

implícitas cuando es utilizado en condiciones especificadas.
La funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante

otras medidas directas como el punto función.
La métrica punto función (PFs), es una métrica orientada a la función y sugiere un

acercamiento a la medida de productividad. Los puntos de función se obtienen utilizando una
relación empírica basada en medidas cuantitativas del dominio de información de software y
valorizaciones subjetivas de la complejidad del software.
La fórmula para calcular la funcionalidad esta dad de la siguiente forma:
PF=CT* (X+Y*∑𝑭𝒊 )
58
Dónde:
CT = Suma de todas las entradas PFs obtenidas.

X = Nivel de confiabilidad del sistema
Y = Nivel de error igual a 0.01
Fi(i=1 a 14) = Valores de ajuste de complejidad, según las respuestas a catorce
preguntas [PRESSMAN 2003].
Para determinar la funcionalidad del sistema primero se debe determinar la variable CT a
partir de cinco características del dominio de información.
 Número de entradas de usuario

 Numero de salida de usuario
 Número de peticiones de usuario (Consultas)
 Numero de archivos o ficheros lógicos internos
 Numero de interfaces externas o ficheros lógico externo
Luego, con la información anterior se calcula la suma de todas las entradas PFs(CT), tal como
se muestra en la tabla 2.2:
Tabla 2.2. Calculo del punto función-factor de ponderación
Parámetros de Complejidad
peso Total
medición Baja Media Alta
Número de entradas
? * 3 4 6 = ?
usuario
Número de Salidas
? * 4 5 7 = ?
usuario
Fichero Lógico interno ? * 7 10 15 = ?
Fichero lógico externo ? * 5 7 10 = ?
Consultas ? * 3 4 6 = ?
Total(∑)=CT = ?
FUENTE: [PRESSMAN]
59
Para obtener el cálculo del factor de ajuste que está dado por: Fi, el grado de influencia se
evalúa en un rango de 0 a 5.
0= La característica no está presente o no influye si está presente

1= La característica tiene una influencia incidental
2= La característica tiene un influencia moderada
3= La característica tiene una influencia promedio
4= La característica tiene una influencia significativa
5= La característica tiene una influencia fuerte, es esencial
Esta valoración se utiliza para calificar a las 14 preguntas siguientes:
1. ¿Requiere el sistema copias de seguridad y de recuperación fiables?

2. ¿Requiere comunicación de datos?
3. ¿Existen funciones de procesamiento distribuido?
4. ¿Es critico el rendimiento?
5. ¿Se ejecutara el sistema en un entorno operativo existente y fuertemente
utilizado?
6. ¿Requiere el sistema entrada de datos interactiva?
7. ¿Requiere la entrada de datos interactiva que las transacciones de entrada se
lleven a cabo sobre múltiples pantallas u operaciones?
8. ¿Se actualizan los archivos maestros de forma interactiva?
9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?
10. ¿Es complejo el procesamiento interno?
11. ¿Se ha diseñado en código para ser reutilizable?
12. ¿Están incluidas en el diseño la conversión y la instalación?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en
diferentes organizaciones?
14. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser
fácilmente utilizada por el usuario?
60
Una vez obtenida la funcionalidad del sistema observamos en que rango se encuentra el valor
calculado de acuerdo a los siguientes valores:
Optima (301-> +)
Buena (201 -> 300)
Suficiente (101 -> 200)
Deficiente (0 -> 100)
Y determinamos así la funcionalidad es óptima, buena, suficiente o deficiente.
Portabilidad
El esfuerzo requerido para transferir el programa desde un hardware y/o un entorno de sistema
del software en un ambiente operacional. Es decir la fiabilidad con que el software puede ser
llevado de un entorno a otro, facilidad de ajuste y la facilidad de adaptación al cambio.
La portabilidad tiene que ver con las variaciones no solo de hardware físico sino más
generalmente de la maquina hardware-software, la que realmente programamos y que incluye
el sistema operativo, el sistema de ventanas y otras herramientas fundamentales. Muchas de
las incompatibilidades existen entre las plataformas son injustificadas, y convierte a la
portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el
software.
La portabilidad tiene la siguiente formula:
P=1 – (EP / EI)
Dónde: P = Portabilidad
EP = Esfuerzo para portar
EI = Esfuerzo para implementar
Mantenibilidad
La facilidad de mantenimiento es la facilidad con la que se puede corregir un programa si se

encuentra un error, se puede adaptar si su entorno cambia, o mejorar si un cliente desea un
cambio de requisitos. Se pueden considerar como atributos de este aspecto:
61
 Exactitud y claridad en la documentación
 Modularidad, acoplamiento
 Facilidad de lectura
 Simplicidad
La madurez del software se calcula de la siguiente manera:
IMS = MT – (FA + FC + FD)/MT
Dónde:MT = Numero de módulos en versión actual

FA = Numero de módulos en versión actual que se ha cambiado
FC = Numero de módulos en versión actual que se añadió
FD = Numero de módulos en versión anterior que se han borrado en la versión
actual
Usabilidad
Llamado también facilidad de uso (FU), esta métrica nos muestra el coste de aprender a
manejar al producto, se lo calcula de la siguiente manera.
FU = [(∑𝒙𝒊 / n) * 100] / n
Donde (xi) es el valor asignado a una de las preguntas de la tabla 2.2. y n es el número de
preguntas. La escala de evaluación es:
Valor Escala
Pésimo 1
Malo 2
Regular 3
Bueno 4
Muy Bueno 5
62
Tabla 2.3. Formulación de preguntas para calcular la usabilidad
Nro. Preguntas Evaluación ( )

¿El sistema satisface los requerimientos de manejo de
1 ?
información?
2 ¿Las salidas del sistema están de acuerdo a sus requerimientos? ?
3 ¿Cómo considera el ingreso de datos al sistema? ?
4 ¿Cómo considera los formularios que elabora el sistema? ?
5 ¿El sistema facilita el trabajo que realiza? ?
Total ∑ = ?
FUENTE: [PEREIRA]
Eficiencia
Conjunto de atributos que se relacionan con el nivel de performance del software y la cantidad
de recursos usados, bajo las condiciones establecidas:
 En tiempo de atributos que miden la respuesta y tiempos de procesamiento de las

funciones
 En recursos atributos que miden la cantidad de recursos usados y la duración de tal uso
en la ejecución de las funciones.
Confiablidad
Capacidad del software de mantener su nivel de performance bajo las condiciones establecidas
por un periodo de tiempo:
 Madurez atributos que se relacionan con la frecuencia de fallas por defectos en el

software.
 Tolerancia a las fallas atributos que miden la habilidad de mantener el nivel
especificado de performance en caso de fallas del software.
 Recuperación atributos que miden la capacidad de restablecer el nivel de performance
y recuperar datos en caso de falla, y el tiempo y esfuerzo necesario para ello.
63
La confiabilidad del software se mide de la siguiente manera:
R(t) = 𝒆⋋𝒕
Dónde:R(t) = Confiabilidad del sistema
= Error de tasa constante de fallas
ʈ = tiempo de operación del sistema
2.10. ANALISIS ECONOMICO DEL SOFTWARE
2.10.1. Modelos de estimación empírica
Un modelo de estimación para el software por computadora utiliza formulas derivadas

empíricamente para predecir los datos. Según Basili describe cuatro modelos de recursos:
modelo simple-variable estático (ej. COCOMO), modelos multi-variables estáticos, modelos
multi-dinamicos variables y modelos teóricos.
2.10.1.1. Modelo Cocomo II
El modelo constructivo de Costos (Constructive Cost Model) fue desarrollado por B.W.
Boehm a finales de los 70 y comienzos de los 80, que está orientada a las líneas de código.
Existe una jerarquía de los modelos COCOMO: Básico, intermedio y avanzado la cual se plica
a tres tipos diferentes de software. [BWB, 1990].
 Orgánico: Proyectos relativamente sencillos, menores de 50.00 líneas de código. Se

tiene experiencia en proyectos similares y se encuentran en entorno estable.
 Semiacoplado: Proyectos intermedios en complejidad y tamaño. La experiencia de
este tipo de proyectos es variable y las restricciones intermedias.
 Empotrado: Proyectos bastante complejos en los que apenas se tiene experiencia y en
un entorno de gran innovación técnica. Se trabaja con unos requisitos muy restrictivos
y de gran volatilidad.
Dado que solo se empleara una variable para la estimación (la línea de código) se empleara
COCOMO básico ya que es modelo uni variable estático, con lo que se obtiene una valoración
64
objetiva del esfuerzo realizado. Este proyecto será considerado como software orgánico ya que
posee menos de 50.000 líneas de código.
La ecuación del esfuerzo de COCOMO básico tiene la siguiente formula:
E=Esfuerzo=a KLDC b (personas por mes)
Donde KLDC es el número de líneas de código, distribuidas en millares para el proyecto.
La ecuación del tiempo de desarrollo es:
T= Tiempo de duración del desarrollo = c Esfuerzod (meses)
Por su parte los coeficientes a,b,c y d se obtienen empíricamente del estudio de una serie de
proyectos y sus valores son:
Tabla 2.4. Coeficiente COCOMO
Proyectos de Software A b c d
Orgánico 2,4 1,05 2,5 0,38
Semicopado 3,0 1,12 2,5 0,35
Empotrado 3,6 1,20 2,5 0,32
FUENTE: [BWB, 1990]
En el desarrollo de un sistema se han codificado 8,2 miles de líneas de código.
Esfuerzo realizado = 2,4 * 8,2 1,05 = 21,9 personas-mes
T = 2,5*21,9 0,38 = 8,1 mes [BWB, 1990]
Nro. De personas para desarrollar el proyecto = E/T = 21,9/8,1 = 3 personas.
2.11. SEGURIDAD
La seguridad es uno de los aspectos más importantes y conflictivos en el uso de Intranet. El

objetivo de la Seguridad Computacional es el de detectar, prevenir, detener y corregir las
violaciones de seguridad que involucra la transmisión de información [HIJ, 2000].
65
Para el desarrollo del sistema se desarrollara un entorno de seguridad para proteger la
información enviada por el servidor hacia el cliente y viceversa, de esta manera evitar el uso
no autorizado de las funciones que ofrece el sistema, dotando al mismo de servicios de
seguridad [HIJ, 2000].
2.11.1. Seguridad a nivel sistema operativo

Cuando usted es un usuario de la computadora, la seguridad es un gran problema. Los
desarrolladores de sistemas operativos de saber que la seguridad del sistema también es
importante. Es por eso que todos los sistemas operativos han incorporado características de
seguridad que hacen que sea segura tanto para navegar por la internet, asi como mantener a los
usuarios no autorizados utilicen su ordenador.
La seguridad de sistema operativo se basa en dos principios:
 El sistema operativo proporciona acceso a una serie de recursos, directa o
indirectamente, como los archivos en un disco local, las llamadas privilegiados del
sistema, la información personal sobre los usuarios, y los servicios ofrecidos por los
programas que se ejecutan en el sistema.
 El sistema operativo es capaz de distinguir entre algunos solicitantes de estos recursos
que están autorizados – o se permite – para acceder a los recursos, y otros que no están
autorizados – o prohibido. Aunque algunos sistemas solo puede distinguir entre
privilegiados y no privilegiados, los sistemas suelen tener una forma de identidad
solicitante, tales como un nombre de usuario.
Además de permitir que el / no permitir modelo de seguridad, un sistema operativo con un alto
nivel de seguridad también se ofrecen opciones de auditoria. Esto permitirá el seguimiento de
las solicitudes de acceso a recursos tales como “que ha estado leyendo este archivo”.
La seguridad del sistema operativo más se puede dividir en dos subsecciones en lo que
respecta a los solicitantes:
 Seguridad Interna – un programa en ejecución. En algunos sistemas, un programa una
vez que se ejecuta no tiene limitaciones. Sin embargo, más comúnmente, el programa
tiene una identidad que se guarda y se utiliza para comprobar todas sus solicitudes de
recursos.
66
 Seguridad Externa – una nueva solicitud desde fuera de la computadora como un log-
in en una consola conectada o algún tipo de conexión de red. Para establecer la
identidad, puede haber un proceso de autenticación.
A menudo, un nombre de usuario debe ser citado y cada usuario puede tener una contraseña.
Otros métodos de autenticación, tales como tarjetas magnéticas o los datos biométricos podrán
utilizarse en su lugar. El algunos casos, especialmente con las conexiones de una red, los
recursos se puede acceder si autentificación en absoluto.
La seguridad del sistema operativo ha sido durante mucho tiempo una preocupación por los
datos altamente sensibles celebra en equipos de carácter personal, comercial, e incluso
militares. Es por eso que los programadores del sistema operativo que preste especial atención
a la seguridad de los sistemas operativos que están desarrollando. Ellos quieren asegurarse de
que los datos delicados contenida en un sistema se mantiene como privado y solo se le permite
ser visto por aquellos que están autorizados a hacerlo [Computacion V, 2009].
2.11.2. Seguridad e nivel de Base de Datos

Es la capacidad del sistema para proteger Datos, Servicios y Recursos de usuarios no
autorizados. El fin de la seguridad es garantizar la protección o estar libre de todo peligro y/o
daño, y que en cierta manera es infalible.
 Confidencialidad: nos dice que los objetos de un sistema han de ser accedidos
únicamente por elementos autorizados a ello, y que esos elementos autorizados no van
a convertir esa información en disponible para otras entidades.
 Integridad: Significa que los objetos solo pueden ser modificados por elementos
autorizados, y de una manera controlada.
 Disponibilidad: indica que los objetos del sistema tienen que permanecer accesibles a
elementos autorizados; es el contrato de la negación de servicio.
¿De qué nos queremos proteger?
A continuación se presenta una relación de los elementos que potencialmente pueden
amenazar a nuestro sistema.
Personas
 Pasivos: aquellos que husmean por el sistema pero no lo modifican y/o destruyen.
 Activos: aquellos que dañan el objetivo atacado o lo modifican en su favor.
67
Describiremos algunos ataques que realizan las personas:
o Personal
o Ex empleados
o Curiosos
o Hackers
o Terroristas
Amenazas Lógicas
o Software incorrecto
o Herramientas de seguridad
o Puertas traseras
o Canales cubiertos
o Virus
o Gusanos
o Caballos de Troya
Encriptación
La mayor parte de bases de datos contiene la información sensible, propia, y/o probada.
Esto puede incluir información de cliente, salarios de empleado, registros pacientes,
números de la tarjeta de crédito. La llave al mantenimiento de esta información en una
manera segura es la confidencialidad – y las empresas que no pueden asegurar la seguridad
(el valor) para la vergüenza del riesgo confidencial de la información, penas financieras, y a
veces aun el negocio mismo.
2.11.3. Seguridad a nivel del Software

La seguridad del software aplica los principios de la seguridad de la información al desarrollo
de software. Esto se refiere a la seguridad de información contra el acceso desautorizado y la
modificación de información, se está en una fase de procesamiento, almacenamiento o
tránsito.
68
2.11.4. Seguridad en el desarrollo del Software
Sin importar el tipo de software que se construya, siempre se debe considerar la seguridad
como una prioridad para continuar con el desarrollo del sistema y así evitar factores externos
que se puedan dañar el trabajo.
En este contexto se define “política de seguridad” como el conjunto de requisitos destinados a
la protección de los recursos informáticos tanto físicos como lógicos durante la operación
normal del mismo.
Las políticas de seguridad son el paso al despliegue de la “arquitectura de seguridad” y los
“planes de prevención, contención y recuperación”, por arquitectura de seguridad se entiende
el conjunto de soluciones tecnológicas destinadas a asegurar los recursos a proteger físicos y
lógicos, locales y en red; mientras que los planes de prevención hacen referencia al conjunto
de normas y medidas que mantienen y regulan el nivel de seguridad en los mismo.
69
CAPITULO 3
MARCO APLICATIVO
3.1. INTRODUCCION
En este capítulo se hará énfasis a todo lo que significa el proceso de desarrollo de software;
desde los requerimientos del usuario hasta la prueba final del sistema. Cada una de las
actividades que son necesarias para la transformación de los requisitos del usuario en un
sistema software, serán detalladas de acuerdo a la metodología utilizada (RUP).
Recordemos que RUP tiene 4 fases –Inicio, elaboración, construcción y transición– y seis
flujos de trabajos importantes –Modelado del negocio, requisitos, análisis, diseño,
implementación y prueba–, los últimos acontecen en cada fase unos con más intensidad que
otros, por ejemplo en la fase inicial tendrá mayor relevancia el modelado del negocio.
En cada flujo de trabajo se obtendrá un producto denominado artefacto, el cual puede ser un
modelo, un elemento de un modelo, o un documento, que el transcurso del desarrollo del
software fueron perfeccionados, y las cuales mostraremos en este trabajo de manera extensiva
y comprensiva.
Previo a lo mencionado con anterioridad, se describirá de manera sucinta la situación actual de
cómo se realiza el control y seguimiento de los proyectos en las 14 sub-alcaldías del Gobierno
Autónomo Municipal de El Alto.
3.1.1. Análisis de la situación actual

Actualmente el Municipio de El Alto cuenta con 14 Distritos Municipales, y las Sub-alcaldías
Municipales son instituciones desconcentradas de la Alcaldía Central (GAMEA), y cada una
de ella tiene como función primordial la de gestionar y supervisar la ejecución de los
proyectos menores inscritos en el Programa Operativo Anual (POA), dicha tarea es realizada
posteriormente a la aprobación del POA por el Honorable Consejo Municipal de El Alto,
hasta su cumplimiento.
Los proyectos menores son aquellos que tienen un monto presupuestado menor o igual a
300.000 Bs, dichos proyectos están a cargo de las Sub-alcaldías, y aquellos proyectos que
sobrepasan el monto mencionado se llegan a ejecutar en la alcaldía central (G.A.M.E.A.).
70
Dentro de los proyectos menores quedan contemplados las obras, compras (como las
dotaciones, equipamientos, etc.), y servicios. Cada una de estas tiene su particularidad en
algunos aspectos, y en otros es equivalente.
En seguida, se resumen los pasos más importantes por la que atraviesa un proyecto.
Paso 1: Inicio del Proceso

 Inscripción del proyecto. Las unidades solicitantes (DTB’s) inscriben sus proyectos al
comité de vigilancia y a su vez las Sub-alcaldías inscriben sus proyectos en la Unidad
de Planificación del Gobierno Municipal de El Alto.
 Proyecto consolidado. Es aquel proyecto que se encuentra inscrito en el POA, y este es
aprobado por el Honorable Consejo Municipal de El Alto, dando así la facultad de que
las Sub-alcaldías ejecuten dichos proyectos inmediatamente. Además cabe destacar
que cada uno de los proyectos retorna con un código asignado denominado SISIN, el
nombre del proyecto exacto y con un presupuesto designado, en una hoja de Excel.
 Elaboración del proyecto. Intervienen los proyectistas y topógrafos.
Una vez elaborado el proyecto, el proyectista solicita la certificación presupuestaria a

Dirección de Finanzas (DFM) del GAMEA, con el propósito de constatar la existencia del
monto presupuestado para el proyecto, luego se deriva a la Oficialía Menor Administrativa
Financiera (OMeAF) de cada Sub-alcaldía Municipal, para su inicio de proceso de
contratación (Unidad de licitaciones).
Paso 2: Proceso Administrativo

Cuando el proyecto se trata de una compra, el proceso de contratación de una empresa es por
ítem, por ejemplo: el proyecto “Enlosetado de la calle 3(Dotación de materiales)” tiene los
ítems: cemento, áridos, losetas, etc. La conclusión de este tipo de proyectos se concreta con la
entrega de todos los ítems al interesado.
En la siguiente figura muestra un bosquejo de cómo se realiza el proceso de contratación
71
Figura 3.1 Proceso de Contratación
FUENTE: [Elaboración Propia]
El paso siguiente corresponde al seguimiento y ejecución de las obras de parte de las Sub-
alcaldías municipales, la unidad de Fiscalización de obras (UFSO) que es la que se encarga de
realizar dichas actividades.
72
Paso 3: Proceso de Supervisión y Fiscalización de las OBRAS
Figura 3.2 Proceso de Fiscalización y supervisión de Obras
Cada una de las unidades por la que atraviesa un cierto proyecto registra las eventualidades
más relevantes de cada uno en hojas de cálculo en Excel. Por ejemplo en la unidad de
licitaciones se registra la fecha de publicación en SICOES, empresa adjudicada, monto
adjudicado, etc.
En la unidad de Fiscalización y supervisión de obras se registra la empresa adjudicada, fecha

de adjudicación, fecha de inicio de obra, supervisor, etc.
Posteriormente toda la información generada en cada unidad es centralizada y organizada, tal
y como se muestra en la siguiente figura.
73
Figura 3.4. Hoja de seguimiento de proyectos
3.2. PLAN DE DESARROLLO PARA EL SISTEMA

Esta fase está destinada para la planificación de actividades del Proceso Unificado de
Desarrollo, también dirigido a la comprensión de los requerimientos de los usuarios y define la
idea principal y visión del proyecto. A continuación se muestra el plan de desarrollo de
software planteado.
Figura 3.5. Cronograma de Actividades
74
Se han identificado los casos de uso del negocio a partir de sus objetivos planteados en el
proyecto, estos procesos de describen a continuación:
 Registro de Proyectos: Este proceso describe el registro de los proyectos clasificando
el tipo de proyecto como Obra, Bienes, Servicios, estos proyectos previamente
aprobados por el consejo municipal de El Alto.
 Registro del Proceso Administrativo: Este proceso describe el registro netamente
Administrativo de los proyectos.
 Registro Supervisión y Conclusión: Este proceso describe el seguimiento
correspondiente en cuanto al avance físico y financiero de los proyectos registrados.
 Seguimiento de Proyectos (Geo-espacial o Lista): Este proceso describe el
seguimiento correspondiente en cuanto a los proyectos registrados.
Especifica la ubicación del proyecto tanto referencial como geográfico, que están
ubicadas en el Municipio de El Alto.
 Control de Proyectos: Este proceso describe el control que ejerce el responsable de
proyectos en el transcurso del seguimiento de proyecto hasta su conclusión, realizando
las distintas revisiones y observaciones del proyecto.
 Búsqueda de Proyectos (Lista o Geo-espacial): Este proceso se encarga de buscar
proyectos, y realizar consultas vecinales, desplegando información con respecto al
proyecto buscado detallando el estado actual del proyecto como también la ubicación
del mismo. También de encargar de clasificar a los proyectos de acuerdo a su estado
actual del proyecto, inicial, en ejecución, concluidos, observados.
Los involucrados para el manejo del sistema serán los técnicos municipales designados por su
sub alcaldía municipal.
3.3. MODELO DEL NEGOCIO

El modelado del negocio es una técnica para comprender los procesos de una organización en
este caso de la Sub-alcaldía del Distrito Municipal 6 de la ciudad de El Alto, Dichos procesos
son descritos en términos de casos de uso del negocio y actores de negocio que se
corresponden con los procesos del negocio de los clientes, respectivamente.
75
A continuación se muestran los modelos de casos de uso del negocio que son detectados en la
Sub-alcaldía 6, y que se tomara como base en el presente proyecto, ya que todas la Sub-
alcaldías Municipales de la Ciudad de El Alto tienen la misma modalidad en la ejecución de
proyectos menores.
3.3.1. Modelo de Casos de Uso

El modelado de negocio detallado identifica los procesos más importantes del contexto del
sistema, describiendo procesos exactos relacionados con actores y casos de uso encontrados
que se muestran a continuación.
 Caso de Uso: Registro y consolidación de un proyecto
Figura 3.6. Diagrama de casos de uso del negocio:

Registro y consolidación de un proyecto
FUENTE: [ELABORACION SAD-6]
76
 Caso de Uso: Elaborar el proyecto
Figura 3.7. Diagrama de casos de uso del negocio
Elaborar el proyecto

 Caso de Uso: Licitar y Adjudicar Proyecto
Figura 3.8 Diagrama de casos de uso de negocio
Seguimiento del proyecto
77
 Caso de uso: Seguimiento del proyecto
Control y Seguimiento del proyecto

 Caso de Uso: Fiscalizar y Supervisar obras
Fiscalizar y Supervisar Obras
78
3.3.2. Descripción de los actores del negocio
Los actores que intervienen en los casos de uso de negocio son:
- Unidad Solicitante: Son los beneficiarios directos de la ejecución de los proyectos.

Representados por las juntas vecinales por ejemplo.
- Comité de Vigilancia: Es la persona que se encarga de fiscalizar al Gobierno
Autónomo Municipal de El Alto – GAMEA. Interviene inscribiendo el proyecto en la
Dirección de Ordenamiento Territorial y Planificación Estratégica - DOTPE del
GAMEA, previa inscripción por las juntas vecinales.
- Repartición Externa (GAMEA): Este caso de uso hace referencia a las unidades del
GAMEA por la que atraviesa el proyecto antes de llegar al Consejo Municipal de El
Alto para su respectiva aprobación.
- Proyectista o responsable del proyecto: Es la persona encargada de elaborar el
proyecto en coordinación con las OTB’s.
- Topógrafo: Es la persona encargada de realizar el levantamiento topográfico.
- Técnico de SICOES: Es la persona encargada de realizar la publicación en SICOES
vía Internet, registrar y decepcionar las propuestas de las empresas, además de la
apertura de sobres.
- Comisión de calificación: Es un grupo de personas que se encarga de evaluar las
propuestas de las empresas, aprobar o desaprobar los mismos.
- Asesoría Jurídica: Es la unidad que se encarga de elaborar el contrato para la empresa
que se adjudica al proyecto.
- Todas las unidades: Se refiere a todas las unidades que intervienen en la ejecución de
los proyectos, tal como: Licitaciones SICOES, unidad de proyectos, Seguimientos,
fiscalización y supervisión de obras.
- Técnico en computación: Es la persona encargada de centralizar la información
referente al seguimiento realizado en cada unidad de los proyectos, para luego emitir
reportes estadísticos.
- Encargada de seguimientos: Es la persona asignada para realizar el seguimiento de
los proyectos en las reparticiones externas del GAMEA.
- Fiscal de Obras: Es la persona encargada de fiscalizar la ejecución de las obras.
79
- Supervisor de Obras: Es la persona que se encarga de supervisar la ejecución de las
obras.
-
3.3.3. Descripción de los casos de uso de negocio
A continuación se describirá algunos de los casos de uso del negocio más relevante, a través
del curso normal de eventos.
Tabla 3.1 Grupo de curso normal de eventos (Casos de uso del modelado del negocio)
CASO DE USO Publicación del Proyectos
ACTORES Técnico de SICOES
DESCRIPCION Publicación del proyecto en SICOES por internet
CURSO NORMAL DE EVENTOS
Acción de los Actores
1. El caso de uso inicia cuando el proyecto es remitido de la unidad de proyectos a la
unidad de licitaciones para su publicación
2. El técnico de SICOES designa un código denominado ANPE al proyecto en caso de
que sean proyectos mayores a 300000 bs.
3. Publicar en el SICOES y mesa de partes de cada una de las Sub-alcaldías municipales.
En la publicación se establece un cronograma a la cual deben regirse las empresas
CASO DE USO Registrar empresas proponentes ,evaluación de propuestas, y
posterior adjudicación de contrato con la empresa seleccionada
ACTORES Técnico de SICOES, Comisión de calificación
DESCRIPCION Publicación de cierto proyecto y adjudicación de empresa
1. El caso de uso inicia cuando una empresa desea presentar su propuesta para un
proyecto en particular.
2. El técnico de SICOES decepciona los documentos y envía las propuestas de las
empresas a la comisión de calificación
3. La comisión de calificación evalúa en 2 días las propuestas de las empresas, luego
80
envían un informe al técnico de SICOES donde se declara si el proyecto se adjudica o
queda desierta.
4. Si el proyecto ha sido adjudicado, el técnico de Sicoes envía el mismo a asesoría
jurídica para la elaboración del contrato en caso de tratarse de una obra. Para una
compra el tratamiento es diferente.
CASO DE USO Fiscalizar y Supervisar Obras
ACTORES Comisión de Calificación, Técnico de SICOES
DESCRIPCION Adjudicar empresa
1. El caso inicia cuando el proyecto es remitido de la unidad de seguimientos a la unidad
de fiscalización y supervisión de obras.
2. El fiscal decide dar inicio a la ejecución de la obra: designando un supervisor y
proporcionando a la empresa el memorándum de inicio de obra correspondiente.
3. El fiscal realiza el seguimiento de las obras, de acuerdo a los informes; avance físico y
financiero, que le brindan los supervisores.
4. Por su parte el supervisor controla que la obra se ejecute físicamente, subsanando
cualquier tipo de contratiempos que pueden suceder en el transcurso de la ejecución.
FUENTE: [ELABORACION PROPIA]
3.4. REQUERIMIENTOS
En esta fase se analizan los requerimientos de información con respecto a obras y proyectos en
el municipio de el alto de parte de las juntas de vecinos que son los más interesados, para que
así conjuntamente con la alcaldía central puedan tener y optar por una mejor tomar de
decisiones con respecto a los proyectos en ejecución.
Los requerimientos son parte fundamental del desarrollo de cualquier tipo de software. En este
contexto, existen dos diferentes tipos de requerimientos; los funcionales y los no funcionales
llamados también atributos del sistema. Los requerimientos funcionales o funcionales del
sistema expresan lo que el sistema debe hacer, en cambio los atributos del sistema son sus
cualidades.
81
3.4.1. Funciones del Sistema
F1. Realizar la migración y el registro de información de proyectos a una base de datos
donde se centralizaran todos los proyectos en ejecución y por ejecutar en el municipio
del Alto, los directos encargados de realizar dicho registro y seguimiento son las sub-
alcaldías municipales dependientes del GAMEA.
F2. Clasificar los proyectos en obras, bienes y servicios.
F3. Realizar la Geo localización del proyecto donde se va a ejecutar la(s) obra(s)
F4. Clasificar el tipo de geometría al que pertenece la obra, línea, punto, polígono.
F5. Registrar información generada dentro el proceso administrativo: datos de
licitación y adjudicación, empresa adjudicada.. etc.
F6. Registrar información generada por la unidad de fiscalización y supervisión de
obras: avance físico y financiero, como también el estado actual de la obra.
F7. Ubicar físicamente en un visor de mapas todos los proyectos en ejecución en el
municipio de El Alto, con su respectiva leyenda de información.
F8. Consultas internas de parte de la institución Sub-alcaldías.
F9. Consultas externas de parte de las organizaciones sociales, Juntas vecinales.
F10. Despliegue de reportes: históricos, Estadísticos.
F11. Búsquedas.
3.4.2. Atributos del Sistema
Los atributos del sistema (denominados también requisitos no funcionales) se muestran en la
siguiente tabla:
Tabla 3.2 Atributos del Sistema
Atributos Detalles y restricciones de frontera
(detalle) Ingreso al sistema con un usuario y contraseña.
Seguridad en el acceso al (detalle) Encriptación en la claves
sistema (detalle) Permitir al administrador, la creación de nuevos
perfiles de usuario, formularios que el vea conveniente.
(detalle) Mantener uniformidad en cada uno de los elementos
Interfaz gráfica de usuario incorporados en la pantalla como: botones, menú, cuadros,
etc., ya sea en la forma y color.
Tiempo de respuesta (restricción de frontera) Cuando se realicen las búsquedas, el
82
resultado de la misma demorara 3 segundos como máximo.
Funcionamiento en un entorno de red.
Acceso al sistema desde varios clientes, manteniendo la
Operatividad consistencia e integridad en los datos.
Fuerte definición de restricción y de responsabilidad en la
modificación de los datos.
Plataforma del sistema (detalle) Windows, Linux
operativo
3.4.3. Modelado de casos de uso del sistema
En esta etapa (captura de requisitos) los casos de uso son imprescindibles, ya que la mayoría
de las actividades como el análisis, diseño y prueba se llevan a cabo partiendo de los casos de
uso, como se detalla en una de las características de la metodología RUP (proceso dirigido por
casos de uso). Asimismo los casos de uso proporcionan un medio sistemático e intuitivo de
capturar requisitos funcionales centrándose en cada uno de los usuarios.
 Diagrama de casos de uso generales
Figura 3.11 Diagrama de casos de uso general
“Sistema de Información para el control y Seguimiento de Proyectos”
SISTEMA
FUENTE [ELABORACION PROPIA]
83
Tabla 3.3 Curso normal de eventos (CU general)
CASO DE USO Acceso al sistema
ACTOR Técnico Administrador
DESCRIPCIÓN Ingresar al sistema
Acción del Actor Respuesta del sistema
1. El caso de uso inicia cuando el usuario 2. Petición de identificador y contraseña del
desea acceder al sistema. usuario.
3. Registra su correspondiente 5. Despliegue de la pantalla principal del
identificador y contraseña. sistema de acuerdo a los privilegios que tiene
4. Presiona el Botón “Aceptar” el usuario.
6. fin
Tabla 3.4. Curso normal de eventos (CU Consultas e información)
CASO DE USO Consultas e información
ACTORES Unidad Solicitante, Juntas Vecinales, Usuario
DESCRIPCIÓN Proveer a las juntas vecinales, unidades solicitantes de
información sobre el proyecto de su interés.
Acción del actor Respuesta del Sistema
1. El caso de uso inicia cuando las juntas
vecinales, unidades solicitantes del 2. Despliega la interfaz gráfica para realizar la
GAMEA quieran conocer el estado del búsqueda correspondiente.
proyecto de su interés e ingresan al
sistema como invitados 4. Realiza la búsqueda correspondiente y
despliega la información solicitada.
3. El usuario invitado realiza la selección
del distrito municipal, la urbanización, y el 5. Muestra el, los proyectos buscados,
proyecto. detallando el estado actual del proyecto(s),
Presiona el botón “buscar” o en su defecto como también en la fase donde se encuentra.
84
“enter”.
6. Muestra información Distrital, como
8. El usuario invitado podrá realizar también a sus autoridades.
consultas en línea con su distrito
Municipal. 7. Muestra en un visor mapas todos los
proyectos distritales en ejecución dentro la
jurisdicción de El Alto.
9. El sistema enviara el mensaje al buzón de

mensajes del distrito municipal seleccionado.
 Diagrama de casos de Uso (Administrador)

Figura 3.12 Diagrama de casos de uso
Registro de Proyectos
SISTEMA
85
Tabla 3.5 Curso normal de eventos (CU administrador)
CASO DE USO Migrar, Realizar Registro de Proyectos
ACTOR Archivo Excel, administrador (iniciador)
DESCRIPCIÓN Migrar, realizar el registro de proyectos de archivos Excel, a la
base de datos.
1. El caso de uso inicia cuando se tienen 4. Despliega la interfaz gráfica para realizar el
los proyectos aprobados por el consejo registro del proyecto a través de formularios
municipal de El Alto. de registro
2. Para ello el administrador ingresa al 7. El sistema realiza el almacenamiento de
sistema. dicha información a una base de datos, si
3. Selecciona del Menú la opción: existiera un error como una duplicidad en el
Primera Fase, seleccionar “Registro de código sisin, el sistema rechazara el registro
Proyecto”. pidiendo que se verifique dicha información,
5. El administrador realiza el registro del caso contrario se registrara correctamente, y se
proyecto. mostrara una ficha técnica del proyecto
6. El administrador realiza la localización registrado.
del proyecto.
8. El administrador visualiza los datos
insertados 10. El sistema realiza acciones de
9. El administrador puede realizar acciones modificación, actualización de información, y
de modificación, actualización de luego muestra esa información en una ficha
información con respecto al proyecto y a técnica.
la infraestructura georefencial.
86
 Diagrama de Casos de Uso (Segunda Fase de Registro)
Figura 3.13 Diagrama de casos de uso: Proceso Administrativo

Tabla 3.6 Curso normal de eventos (CU Proceso Administrativo)
CASO DE USO Proceso Administrativo
Una vez realizado el proceso de registro de los proyectos, se
DESCRIPCIÓN realiza el registro con respecto al proceso administrativo, como
el tema de la contratación de la empresa adjudicada a la obra.
1. Para ello el administrador ingresa al 3. Despliega la interfaz gráfica para realizar
sistema. dicha acción.
2. Selecciona del Menú la opción: 5. El sistema realiza la búsqueda de dicho
Segunda Fase, selecciona “Proceso proyecto en la base de datos central. El sistema
administrativo”. mostrara la interfaz donde podrá realizar el
4. Para el registro, el administrador registro del proyecto.
selecciona el código SISIN del proyecto, 7. Realiza la verificación y la validación de
proyecto que en una anterior oportunidad información.
ya fue registrado en la primera fase. 8. Realiza el almacenamiento de Información de
87
6. El administrador realiza el registro y la dicho proyecto a la base de datos.
actualización de información. 9. Despliega una interfaz gráfica donde se
10. El administrador elige las opciones muestra una ficha técnica de la información
que ofrece el sistema. registrada correspondiente al proyecto x,
12. El administrador al no tener más también se observa un menú donde existe la
observación da por concluido el proceso opción de poder modificar, actualizar
administrativo del proyecto buscado. información del proyecto.
11. Realiza la validación de datos,
actualización, modificación de información. Y
despliega una ficha técnica del proyecto.
 Diagrama de Casos de Uso (CU tercera fase de registro)
Figura 3.14 Diagrama de casos de uso. Supervisión y Conclusión del proyecto
SISTEMA
88
Tabla 3.7 Curso normal de eventos (CU supervisión de Obras)
CASO DE USO Supervisión y conclusión del proyecto
Una vez concluido con el proceso administrativo se realiza
DESCRIPCIÓN
el registro de información y supervisión de las obras.
Acción de los actores Respuesta del Sistema
1. El caso de uso inicia cuando el 3. Despliega la interfaz gráfica para realizar
administrador ingresa al sistema. dicha acción.
2. Selecciona del Menú la opción: 5. El sistema realiza la búsqueda de dicho
Tercera Fase, selecciona “supervisión y proyecto en la base de datos central. El
Conclusión”. sistema mostrara la interfaz donde se podrá
4. Para el registro, control y seguimiento realizar el registro, supervisión y control de las
de las obras, el administrador selecciona el obras de dicho proyecto.
código SISIN del proyecto. 7. Realiza la verificación y la validación de
6. En caso de no existir ningún error, el información.
administrador podrá realizar las acciones 8. Realiza el almacenamiento de Información
de registro, seguimiento de los proyectos. de dicho proyecto a la base de datos.
10. El administrador visualiza los datos 9. Despliega una interfaz gráfica donde se
insertados muestra una ficha técnica de la información
11. El administrador registra alguna registrada correspondiente al proyecto x,
observación si es que existiese. también se observa un menú donde existe la
12. El administrador elige las opciones que opción de poder modificar, actualizar
ofrece el sistema. información del proyecto.
15. El administrador realiza el registro de También podrá imprimir las infraestructuras
según al monto de la planilla (avance del proyecto.
financiero) para el avance físico de la 13. Realiza la acción seleccionada por el
Obra. administrador.
16. En caso de no tener ninguna 14. El sistema muestra la interfaz gráfica para
observación con respecto al avance físico la supervisión de las obras.
de la obra el administrador será realizando
89
el registro del avance hasta que este se
encuentre concluido, finalizado.
3.5. ANALISIS
En el análisis se logra profundizar el estudio de cada uno de los casos de uso planteados en la
captura de requisitos. El objetivo es identificar las clases del mundo real cuyos objetos son
necesarios para ejecutar el caso de uso y describir su comportamiento a través de la
interacción de dichos objetos.
En resumen, las tareas a realizarse en esta etapa son: identificación de clases y descripción de
la interacción de objetos. Cada una de estas tareas se efectúa de manera paralela. Las técnicas
usadas en cada tarea con diagrama de clases inicial (o modelo conceptual) y diagramas de
interacción: secuencia y colaboración (se prescindirá de este último).
3.5.1. Diagramas de Secuencia del Sistema
Los diagramas de secuencia muestran la manera gráfica los eventos u operaciones del sistema,
como es que este responde a alguna determinada operación y con los Diagramas de
Colaboración se tiene un enfoque más claro de la relación entre las operaciones, lo cual nos
ayudara en la etapa de implementación del sistema.
Cada diagrama de secuencia, representa un determinado escenario de un caso de uso, que
tuvieron que ser trabajadas en el curso normal de eventos, perteneciente a la etapa de la
captura de requisitos.
 Diagrama de Secuencia del Sistema para el caso de Uso: Acceso al Sistema
Figura 3.15 Diagrama de secuencia: Acceso al Sistema
90
 Diagrama de Secuencia del Sistema para el caso de Uso: Registro de Proyectos
Figura 3.16. Diagrama de secuencia: Registro de Proyectos
 Diagrama de Secuencia del Sistema para el caso de Uso: Proceso Administrativo

Figura 3.17. Diagrama de secuencia: Proceso Administrativo
91
 Diagrama de Secuencia del Sistema para el caso de Uso: Supervisión y Conclusión
Figura 3.18. Diagrama de secuencia: Supervisión y Conclusión del proyecto

 Diagrama de Secuencia del Sistema para el caso de Uso: Informes y Consultas
Figura 3.19. Diagrama de secuencia: Consultas e información
92
3.5.2. Contrato de Operaciones
 Contrato de Operaciones para el caso de uso: Acceso al sistema
Contrato CO1: Conexión al sistema (dirección, base de datos)
Operación Conexión al sistema(dirección: string, base de datos: string)
Referencia cruzada Caso de uso: Acceso al sistema
Precondición Ninguna
Postcondicion  Interfaz del sistema
Contrato CO2: Valida Datos (usuario, clave)

Operación Valida Datos(usuario: string, clave: string)
Precondición Usuario y clave deben existir
Postcondicion  Verifica usuario
Contrato CO3: Accede al Sistema ()

Operación Accede al Sistema()
Precondición Datos Validos
Postcondicion  Usuario autentificado paso a ser verdad
 Pantalla principal del sistema
 Contrato de Operaciones para el caso de uso: Registro de Proyecto

Contrato CO1: Registrar ()
Operación Registrar()
Referencia cruzada Caso de uso: Registro de Proyectos
Precondición Usuario autentificado. Registra proyectos
Postcondicion  Valida datos, verifica si tiene permisos para escribir
 Verifica si no existe el mismo proyecto
 Se registra el proyecto en la Base de datos
Contrato CO2: modificar (código SISIN)

Operación modificar(código: string)
Precondición Usuario autentificado. Registra proyectos
 Verifica si no existe el mismo proyecto
93
 Se registra el proyecto en la Base de datos
Contrato CO3: Registrar Ubicación (código SISIN)

Operación Registrar Ubicación (código: string)
Precondición Usuario autentificado. Realiza la ubicación geográfica del
proyecto
Postcondicion  Verifica la autentificación
 Registra la longitud y latitud del proyecto
 Contrato de Operaciones para el caso de uso: Proceso Administrativo

Contrato CO1: Get_Proy_sisin (codigo)
Operación Get_Proy_sisin (código: string)
Referencia cruzada Caso de uso: Proceso Administrativo
Precondición Técnico, Administrador autentificado
 Busca el proyecto en la base de datos
 Muestra en pantalla el proyecto buscado

 Se registra la información del proyecto en la Base de
datos

 Realiza la modificación de información del proyecto
buscado.
94
 Contrato de Operaciones para el caso de uso: Supervisión y Conclusión del
proyecto
Contrato CO1: Get_Proy_sisin (codigo)
Operación Get_Proy_sisin (código: string)
Referencia cruzada Caso de uso: Supervisión y Conclusión
 Muestra en pantalla el proyecto buscado

 Se registra la información del proyecto en la Base de
datos correspondiente a la tercera fase.

 Realiza la modificación de información del proyecto
buscado.
Contrato CO4: Avances (código SISIN)

Operación Registrar Avance (código: string)
 Se registra la información con respecto al avance
físico y financiero del proyecto.
 Contrato de Operaciones para el caso de uso: consultas e información

Contrato CO1: Buscar (distrito, urbanización, estado del proyecto)
95
Operación Buscar (distrito: int, urbanizacion: int, estado del proyecto:
int)
Referencia cruzada Caso de uso: Informes y Consultas
Precondición Invitados, Juntas vecinales, Organizaciones Sociales
Postcondicion  Acceso libre
 Muestra en pantalla información seleccionada
Contrato CO1: Abrir_proyectos ()

Operación Abrir_proyectos()
Postcondicion  Muestra en pantalla todos los proyectos según
requerimiento del visitante.
 Se despliegan los proyectos son según el distrito y
urbanización seleccionado.
Contrato CO2: proyecto ()

Operación proyecto()
Postcondicion  Despliega y genera informe de la información
alfanumérica del proyecto
Contrato CO3: Abrir_sad ()

Operación Abrir_sad ()
Postcondicion  Despliega plantilla web donde se muestra
información distrital.
Contrato CO4: Abrir_visor_municipal ()

Operación Abrir_visor_municipal ()
Postcondicion  Despliega Visor Municipal donde se muestra todos
los proyectos registrados.
 Despliega información con respecto al estado actual
del proyecto, como también el avance físico y
96
financiero de las mismas
3.6. DISEÑO
3.6.1. Casos de Uso real
Un caso real de uso describe el diseño concreto del caso de uso a partir de una tecnología
particular de entrada y salida, así como de su interpretación global. Por ejemplo, si interviene
una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas en
cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz.
Figura 3.20. Pantalla de caso de uso real de Acceso al Sistema

Tabla 3.8. Caso de uso real: Acceso al Sistema
CASO DE USO Acceso al sistema
DESCRIPCIÓN Ingresar al Sistema
RESUMEN Obtiene datos del usuario que ha ingresado
1. El caso de uso inicia cuando el usuario 3. Muestra la pantalla de acceso al Sistema
desea acceder al sistema. 6. Verifica si los datos son los correctos, y
97
2. Ingresa la dirección del sistema muestra el mensaje de bienvenida, según el rol
4. Introduce su cuenta (A) y su clave (B) del sistema
5. Presiona el Botón “Ingresar” (C)
Debe ser funcionario Municipal y tener cuenta
PRECONDICIÓN
en el sistema
Mostrar opciones del sistema de acuerdo al rol
POSTCONDICIÓN
que tenga
Figura 3.21. Pantalla de caso de uso real de – Registro de Proyectos
98
Figura 3.22. Pantalla de caso de uso real de – Registro de Ubicación Geo referencial del
proyecto

Tabla 3.9. Caso de uso real: Registro de Proyectos
CASO DE USO Registro de Proyectos
ACTOR Técnico Administrativo
DESCRIPCIÓN Registrar un nuevo proyecto
RESUMEN Genera una lista del proyecto nuevo
1. El caso de uso inicia cuando el usuario 2. El sistema despliega el formulario de
Activa el formulario para proyectos proyectos nuevos.
nuevos (A).
3. Registra información correspondiente al 7. Verifica si los datos son los correctos.
proyecto en curso (B).
4. Posteriormente realiza la ubicación geo 8. El sistema almacena los datos
referencial del proyecto a través de un correspondientes en la Base de Datos.
visor municipal, y se registra información
correspondiente a la infraestructura, obra
(C).
99
5. Presiona el Botón “Guardar” realiza el
guardado de la información georeferencial
(D).
6. Posteriormente revisa si los datos están
correctos y hace clic en “Guardar”(E).
PRECONDICIÓN
en el sistema
Registrar el proyecto que se hará el
POSTCONDICIÓN
seguimiento
Figura 3.23. Pantalla de caso de uso real de: Proceso Administrativo
100
Figura 3.24. Pantalla de caso de uso real de: Proceso Administrativo-registro

Tabla 3.10. Caso de uso real: Proceso Administrativo
CASO DE USO Proceso Administrativo
DESCRIPCIÓN Registrar Información con respecto al tema administrativo
del proyecto
RESUMEN Genera informe del proyecto buscado
1. El caso de uso inicia cuando el usuario 2. El sistema despliega un formulario de
101
Activa del menú “Segunda Fase” (A). búsqueda.
3. El Administrador ingresa el Código 4. Realiza la búsqueda del proyecto en la Base
SISIN del proyecto, para su posterior de Datos.
registro. (B). 5. Despliega por pantalla el proyecto buscado
6. para ingresar al formulario de registro, 7. El sistema despliega el formulario de
el administrador hace clic en la imagen, o Proceso Administrativo correspondiente al
en todo caso en el nombre del proyecto. proyecto buscado.
(C). 10. Verifica si los datos son correctos.
8. Registra información Administrativa del 11. El sistema almacena los datos
proyecto (D). correspondientes en la Base de Datos.
9. Posteriormente revisa si los datos están
correctos y hace clic en “Guardar”(E).
PRECONDICIÓN
en el sistema
Registrar información correspondiente para su
POSTCONDICIÓN
control y seguimiento.
Figura 3.25. Pantalla de caso de uso real de – Supervisión y Conclusión
102
Figura 3.26. Pantalla de caso de uso real de: Supervisión y Conclusión-registro
Tabla 3.11. Caso de uso real: Supervisión y Conclusión del proyecto

CASO DE USO Supervisión y Conclusión del proyecto
DESCRIPCIÓN Registrar Información con respecto al Seguimiento y
Supervisión de Obras del proyecto
RESUMEN Genera informe del proyecto buscado
1. El caso de uso inicia cuando el usuario 2. El sistema despliega un formulario de
Activa del menú “Segunda Fase” (A). búsqueda.
3. El Administrador ingresa el Código 4. Realiza la búsqueda del proyecto en la Base
SISIN del proyecto, para su posterior de Datos.
registro. (B). 5. Despliega por pantalla el proyecto buscado.
6. para ingresar al formulario de registro, 7. El sistema despliega el formulario de
el administrador hace clic en la imagen, o correspondiente a la supervisión y conclusión
103
en todo caso en el nombre del proyecto. del proyecto buscado.
(C). 10. Verifica si los datos son correctos.
8. Registra información Administrativa del 11. El sistema almacena los datos
proyecto (D). correspondientes en la Base de Datos.
9. Posteriormente revisa si los datos están 12. El sistema Despliega el formulario de
correctos y hace clic en “Guardar” (E). avances de Obra.
13. Registra el avance Físico y Financiero 15. Verifica si los datos son correctos.
del Proyecto. 11. El sistema almacena los datos
14. revisa si los datos son los correctos y correspondientes en la Base de Datos.
hace clic en “Guardar”.
PRECONDICIÓN
en el sistema
Registrar información correspondiente para su
POSTCONDICIÓN
control y seguimiento.

Figura 3.27. Pantalla de caso de uso real de: Consultas e Información
104
Tabla 3.12. Caso de uso real: Consultas e Información
CASO DE USO Informes y consultas
ACTOR Organizaciones Sociales, Juntas Vecinales
DESCRIPCIÓN Ingresar al Sistema como invitados
RESUMEN Acceso al sistema de parte de personal interna , externa
1. El caso de uso inicia cuando se quiere 3. Despliega por pantalla un formulario de
ingresar al sistema como invitado. consulta.
2. hace clic en “Ingresar como invitado”
(A).
PRECONDICIÓN ninguna
Mostrar información con respecto a los
POSTCONDICIÓN proyectos que se están ejecutando en el
Municipio de El Alto
Figura 3.28. Pantalla de caso de uso real de –Portal de consultas Externas
105
Figura 3.29. Pantalla de caso de uso real de –Lista de proyectos

Tabla 3.13. Caso de uso real: lista de proyectos
CASO DE USO Consultas e información
ACTOR Organizaciones Sociales, Juntas Vecinales
DESCRIPCIÓN Ingresar al Sistema como invitados
RESUMEN Acceso al sistema de parte de personal interna , externa
1. El usuario invitado selecciona Distrito 3. Despliega por pantalla información con
Municipal al que pertenece (A) respecto al proyecto, como también
2. Luego Selecciona una o todas las información distrital.
Urbanizaciones del distrito Municipal ya
seleccionado (B).
3. luego selección el tipo del proyecto (C),
y hace clic en “Buscar Proyecto” (D)
PRECONDICIÓN Ninguna
106
Mostrar información con respecto a los
POSTCONDICIÓN proyectos que se están ejecutando en el
Municipio de El Alto
3.6.2. Modelo de Comportamiento

3.6.2.1. Diagramas de Secuencia
Los Diagramas de secuencia muestran de manera gráfica de los eventos y operaciones del
sistema, como es que este corresponde a alguna determinada operación.
 Diagrama de Secuencia para el Caso de Uso: Acceso al Sistema
Figura 3.30. Diagrama de Secuencia: Acceso al Sistema
107
 Diagrama de Secuencia para el Caso de Uso: Registro de Proyectos
Figura 3.31. Diagrama de Secuencia: Registro de Proyectos
 Diagrama de Secuencia para el Caso de Uso: Proceso Administrativo

Figura 3.32. Diagrama de Secuencia: Proceso Administrativo
108
 Diagrama de Secuencia para el Caso de Uso: Supervisión y Conclusión
Figura 3.33. Diagrama de Secuencia: Supervisión y Conclusión

 Diagrama de Secuencia para el Caso de Uso: Consultas e Informes
Figura 3.34. Diagrama de Secuencia: Consultas e Informes
109
3.6.3. Diagrama de Componentes
Figura 3.35. Diagrama de Componentes de Formulario de Proyectos

Figura 3.36. Diagrama de Componentes de los Proyectos
110
3.6.4. Diagrama de Paquetes
Figura 3.37. Diagrama de Paquetes del sistema

3.6.5. Diagrama de Despliegue
Figura 3.38. Diagrama de Despliegue del sistema
111
3.6.6. Diagrama Navegacional
El Diagrama navegacional a presentar del Sistema de Información para el Control y
Seguimiento de Proyectos Distritales Georefenciados Vía Web del “Gobierno Municipal de El
Alto”, al estar orientado a un diseño Web presenta el diagrama navegacional de los usuarios
que utilizaran el sistema.
Vemos a continuación el siguiente esquema en la siguiente figura
Figura 3.39. Diagrama de Navegacional del sistema
112
3.6.7. Diagrama de Clases
El sistema se ha logrado modelar de acuerdo al siguiente diagrama de clases que se muestra a
continuación en la siguiente figura.
Figura 3.40. Diagrama de Clases
113
3.6.8. Diagrama Entidad – Relación
El diagrama o modelo entidad-relación es una herramienta para el modelado de datos que
permite representar las entidades relevantes de un sistema de información así como sus
interrelaciones y propiedades.
Figura 3.41. Diagrama Entidad-Relación del Sistema
3.6.9. Diseño de la Interfaz del Sistema

En el presente proyecto luego de optimizar los puntos mencionados en los anteriores capítulos,
logrando así este objetivo después de varias iteraciones a través del ciclo de vida de RUP. Se
logró obtener el producto requerido por el cliente. A continuación se presentan los diseños
finales con los que el proyecto llego a su conclusión, los podemos observar de forma
detallada.
114
MODULO DEL ADMINISTRADOR
Figura 3.42 Interfaz de Usuario: Ingreso al Sistema
115
Figura 3.43. Interfaz de Usuario: Registro de usuarios
Figura 3.44. Interfaz de Usuario: Ficha técnica Usuario
116
MODULOS DEL PROYECTO
Este módulo está disponible desde intranet, internet, y está destinado solo para
administradores “Sub alcaldías Municipales”.
Figura 3.45. Interfaz de Usuario: Panel de control

Figura 3.46. Interfaz de Usuario: Registro de Proyectos
117
Figura 3.47. Interfaz de Usuario: Ubicación georeferencial del proyecto

Figura 3.48. Interfaz de Usuario: Ficha técnica - primera fase
118
Figura 3.49. Interfaz de Usuario: Proceso Administrativo

Figura 3.50. Interfaz de usuario: Ficha Técnica del Proyecto-segunda fase
119
Figura 3.51. Interfaz de usuario: Formulario de registro Supervisión y Conclusión
Figura 3.52. Interfaz de usuario: Formulario de registro Monto Planilla
120
Figura 3.53. Interfaz de usuario: Ficha Técnica del Proyecto-Tercera fase
Figura 3.54. Interfaz de usuario: Listado de Proyectos Distritales
121
Figura 3.55. Interfaz de usuario: Buzón de mensajes

MODULO DE CONSULTAS E INFORMACION
El ingreso a este módulo se lo hace vía internet, donde las personas ajenas a la alcaldía como
ser las juntas vecinales podrán realizar consultas acerca del avance físico y financiero de sus
proyectos, como también realizar consultas en línea con sus autoridades municipales.
Figura 3.56. Interfaz de consultas
122
Donde podrá seleccionar el distrito Municipal al que pertenece, de igual manera debe
seleccionar la urbanización y el estado del proyecto de su interés.
El municipio de El Alto se encuentra conformada en la actualidad por 14 distritos municipales,
14 Sub alcaldías Municipales, existe un módulo para cada sub alcaldía municipal donde se
podrá acceder a información, comunicación distrital.
Figura 3.57. Interfaz de consultas – lista de proyectos
Lista de proyectos, en base a los seleccionado en el portal de consulta
123
Figura 3.58. Interfaz de consultas – Datos del Proyecto
Datos generales del proyecto, donde se puede apreciar información importante y resumida
referente al proyecto seleccionado.
124
Figura 3.59. Interfaz de consultas – Reporte del proyecto
Ficha técnica del proyecto que muestra información detallada y del avance físico financiero
del proyecto.
125
Figura 3.60. Interfaz de consultas – Sad municipal
Servicio Distrital
Panel de Control (Menú de Opciones): Se muestra una serie de
Opciones clasificadas en dos módulos como ser: Jurisdicción distrital, urbanizaciones, Gaceta
Informativa, Consultas al municipio y Novedades.
126
Figura 3.61. Interfaz de consultas – Visor Municipal de Obras
3.7. PRUEBAS
3.7.1. Pruebas de Caja Blanca
En este tipo de prueba, observamos todo el código con la noción de probar el
desenvolvimiento del sistema recorrido por cada uno de los casos presentados por los
algoritmos que se utilizaron en la codificación, es decir son casos de prueba que se aplica al
código fuente.
En las pruebas de caja blanca se consideran lo siguiente:
 Se realizaran las pruebas utilizando el conocimiento del funcionamiento interno del
código.
127
 Las pruebas de caja blanca solo se pueden realizar por programadores.
La aplicación del caso de prueba de caja blanca se lo realiza utilizando métrica de complejidad
dicromática el cual brinda la cantidad aproximada de casos de prueba que se deben aplicaren
el código fuente como se muestra en la siguiente figura.
Diagrama de flujo de procedimiento del funcionamiento del sistema y el grafo de complejidad

métrica, veamos a continuación:
Figura 3.62. Diagrama de Uso General Figura 3.63. Grafo de métrica
FUENTE: [ELABORACION PROPIA] FUENTE: [ELABORACION PROPIA]
128
Tabla 3.14. Matriz de complejidad ciclomatica
Conexión A B C D E F G H I Sumatoria
de nodos SUM
A 1 1-1=0
B 1 1 2-1=1
C 1 1-1=0
D 1 1 1 2-1=1
E 1 2-1=1
F 1 1-1=0
G 1 1-1=0
H 1 1-1=0
I
SUM=3+1=4
Complejidad Ciclo matica de acuerdo a:
V(G)=A-N+2 V(G)=P+1
Dónde:
N= Numero de Nodos. A= Numero de aristas P= Numero de Nodos Predicados
N=9 A=11 P=3
Remplazando los valores tenemos:
V(G) = 11-9+2 V(G) = 3+1
V(G) = 4 V(G) = 4
El valor de V(G) = 4 nos indica que son cuatro los casos de pruebas que deben de ejecutarse y
diseñar para garantizar que se cubren las sentencias del programa.
Sacamos caminos independientes:
Camino 1: A – B – I
Camino 2: A – B – C – D – I
Camino 3: A – B – C – D – E – H – I
Camino 4: A – B – C – D – F – G – H – I
129
3.7.2. Prueba de Caja Negra
La prueba de caja negra consiste en probar cada una de las funciones del sistema que fueron
especificadas en el capítulo III.
Con este tipo de prueba se debe buscar que las funciones sean operativas, además se debe
agotar al sistema de tal manera buscar la mayor cantidad de errores.
Son pruebas sobre la interfaz del software

A continuación se muestran algunas pruebas relevantes.
 Prueba de autentificación
Si el usuario que desea ingresar al sistema es el correcto desplegara la interfaz gráfica
de ingreso, Bienvenida al usuario, caso contrario se mostrara un mensaje de acceso
denegado.
Figura 3.64. Prueba caja negra - Acceso al sistema
Ingreso Exitoso
Ingreso Fallido
 Validación de un Formulario
En la siguiente figura se muestra la validación del formulario correspondiente al proceso
administrativo. A la culminación de un buen registro se despliega la ficha técnica, caso
contrario se mostraran mensajes de alerta describiendo el error de la información
correspondiente.
130
Figura 3.64. Prueba de caja negra – Registro de Proyectos
Registro exitoso
Error en el registro
131
CAPITULO 4
METRICA DE CALIDAD
4.1. FACTORES DE CALIDAD
La evaluación de productos Web no es una tarea sencilla. Es difícil considerar todas las
características y atributos deseables y obligatorios en una aplicación o sitio web si no se
cuenta con un modelo de calidad que permita especificar ordenadamente dichas características
y atributos. Se pueden destacar varios trabajos que tratan de definir modelos y criterios de
calidad para productos de software. Algunos de ellos podemos destacar como el ISO 9126,
IEEE1061.
4.1.1. Funcionalidad
El Punto Función es una métrica orientada a la función del software y del proceso por el cual
se desarrolla. Se centra en la funcionalidad o utilidad del programa, los puntos de función se
calculan realizando una serie de actividades, comenzando por determinar los siguientes
números.
 Números de entrada de usuario: Se cuenta cada entrada del usuario que proporcione
al software diferentes datos orientados a la aplicación.
 Número de salida del usuario: En este contexto las salidas se refieren a informes,
pantalla, mensajes de error, etc.
 Números de peticiones al usuario: Una petición está definida como una entrada
interactiva que resulta de la generación de algún tipo de respuesta en forma de salida
interactiva.
 Número de archivos: se cuenta cada archivo maestro lógico,
 Numero de interfaces externas: se cuentan todas las interfaces legibles por la
maquina por ejemplo: archivos de datos, en cinta o discos que son utilizados para
transmitir información a otro sistema.
De acuerdo a lo mencionado tenemos los siguientes resultados:
Tabla 4.1. Entrada de datos para el cálculo de funcionalidad
Entradas de usuario 25
Salidas de usuario 19
Consultas de usuario 15
132
Número de Archivos 19
Interfaces externas 2
Los puntos de función se calculan rellenando la tabla 4.2 con los datos obtenidos,
considerando un factor de ponderación medio.
Tabla 4.2. Entradas para el cálculo de funcionalidad
Parámetros de Factor de
Cuenta Total
medición ponderación medio
Número de entradas
25 * 4 = 100
de usuario
Número de salidas de
19 * 5 = 95
usuario
Número de consultas
15 * 4 = 60
de usuario
Numero de archivos 19 * 10 = 190
Numero de interfaces 2 * 7 = 14
Cuenta Total 459
La relación que permite calcular los puntos de función es la siguiente:
𝑷𝑭 = 𝑪𝒖𝒆𝒏𝒕𝒂 𝑻𝒐𝒕𝒂𝒍 ∗ (𝑮𝒓𝒂𝒅𝒐 𝒅𝒆 𝒄𝒐𝒏𝒇𝒊𝒂𝒃𝒊𝒍𝒊𝒅𝒂𝒅 + 𝒕𝒂𝒔𝒂 𝒅𝒆 𝒆𝒓𝒓𝒐𝒓 ∗ 𝑭𝒊 )
 PF = Medida de Funcionalidad.
 Cuenta Total = es la suma de valor de las entradas, salidas, peticiones, interfaces
externas y archivos.
 Grado de Confiabilidad = Es la confiabilidad estimada del sistema.
133
 Tasa de error = Probabilidad subjetiva estimada del dominio de la información, este
error estimado es de 1%.
 Fi = Son valores de ajuste de complejidad que toman los valores de la tabla 4.4 y que
dan respuesta a las preguntas de la tabla 4.4.
Tabla 4.3. Valores de ajuste de complejidad
Sin importancia 0
Incidencia 1
Moderado 2
Medio 3
Significativo 4
Esencial 5
Tabla 4.4. Ajustes de complejidad del punto función
Sin
ESCALA Incidental Moderado Medio Significativo Esencial
importancia
Factor 0 1 2 3 4 5
1. ¿Requiere el sistema
copias de seguridad y x
recuperación fiable?
2. ¿Se requiere
comunicación de x
datos?
3. ¿Existe funciones de
procesamiento x
distribuido?
4. ¿Es critico el
x
rendimiento?
5. ¿Sera ejecutado el x
134
sistema en un entorno
operativo existente y
frecuentemente
utilizado?
6. ¿Requiere el sistema
entrada de datos x
interactivos?
7. ¿Requiere la entrada
de datos interactivo que
las transiciones de
x
entrada se lleven a cabo
sobre múltiples o
variadas operaciones?
8. ¿Se actualizan los
archivos maestros de x
forma interactiva?
9. ¿Son complejas las
entradas, las salidas, los x
archivos o peticiones?
10. ¿Es complejo el
procesamiento interno?
11. ¿Se ha diseñado el
código para ser x
reutilizable?
12. ¿Están incluidos en
el diseño la conversión X
y la instalación?
13. ¿Se ha diseñado el
sistema para soportar
X
múltiples instalaciones
en diferentes
135
organizacionales?
14. ¿Se ha diseñado la
aplicación para facilitar
los cambios y para ser X
fácilmente utilizados
por el usuario?
( ) 50
A continuación calculamos el valor de PF:
= ∗( + ∗ )
= ∗( + ∗ )
=
Si consideramos el máximo valor de ajuste de complejidad como ∑ = , se tiene:

= ∗( + ∗ )
=
Entonces si ∑ es considerada como el 100%, la relación obtenida entre los puntos será:
= =
Por lo tanto, la funcionalidad o utilidad del sistema es del 85% lo que significa que el software
se desenvuelve satisfactoriamente.
4.1.2. Confiabilidad del Sistema
La confiabilidad es la capacidad del software de mantener su nivel de performance o
rendimiento bajo las condiciones establecidas por un periodo de tiempo.
La confiabilidad del Software se la mide de la siguiente manera:
𝑹(𝒕) = 𝒆−𝝀𝝉
Dónde:
R(t)= Confiabilidad del Sistema
136
λ= Error de tasa constante de fallas
t= Tiempo de operación del sistema (meses)
La tasa de error o la probabilidad de error que pueda tener el sistema es del 0.5%.
Si consideramos un tiempo de 12 meses para el funcionamiento del sistema.
Entonces:
( )= −
( )= −− ∗
( )=
Por lo tanto la confiabilidad del sistema es del 94.189%, lo que significa en términos de 12
meses el sistema mantendrá un rendimiento óptimo.
4.1.3. Mantenimiento del Sistema
Para el cálculo de esta estabilidad del sistema, es decir índice de madurez del software (IMS),
se establecerá los cambios que ocurrieron con cada versión del producto. Para los cual el IMS
se determina con la siguiente información.
MT = Número de módulos en la versión actual.
Fc = Número de módulos en la versión actual que se ha cambiado.
Fa = Número de módulos en la versión actual que se han añadido.
Fd = Número de módulos en la versión actual que se han eliminado.
El índice de madurez del software se calcula la siguiente manera:
𝑴𝑻 − (𝑭𝒄 + 𝑭𝒂 + 𝑭𝒅)
𝑴=[ ]
𝑴𝑻
En el sistema se obtuvieron los siguientes valores como muestra la tabla 4.5 para la
información requerida para el IMS.
Tabla 4.5. Información Requerida por el IMS
Información Valores Obtenidos
MT 6
Fc 1
Fa 0
Fd 0
FUENTE [Elaboración propia]
137
Ahora calculamos el índice de madurez del software sustituyendo los valores de la tabla 5.6
los cuales son resultados obtenidos en el sistema.
IMS = [6 – (1 + 0 + 0)] / 6
IMS = 0,83
Tomando en cuenta la escala siguiente se concluye que el IMS obtenido tiene una estabilidad
alta al final de la evolución en las versiones logradas.
75 % <= IMS <= 100 % Optima.
50 % <= IMS <= 75 % Buena.
25 % <= IMS <= 50 % Suficiente.
0 % <= IMS <= 25 % Deficiente.
Entonces: IMS = 0.83 => índice de madurez alcanzando es del 83%, este se encuentra en un
rango satisfactorio.
4.1.4. Portabilidad del sistema
La portabilidad se refiere al esfuerzo necesario para transferir el programa de un entorno ya
sea de hardware y/o software a otro, es una característica deseables de todo software.
La portabilidad tiene la siguiente formula:
𝑬𝑷
𝑷 = [𝟏 − ]
𝑬𝑰
Dónde:
P= Portabilidad
EP = Esfuerzo para portar
EI = Esfuerzo para implementar
Consideremos que el esfuerzo para portar y para implementar es de 10 y 40 respectivamente
de un rango entre el 1-100.
Entonces, P = 1-(10/40)
P = 0.75
Lo que significa que el sistema posee la característica de la portabilidad. Se ha comprobado de
manera práctica, que el sistema es portable.
138
4.1.5. Usabilidad
La usabilidad o facilidad de uso (FU), se calcula de la siguiente manera.
∑ 𝒙𝒊
𝒏 ∗ 𝟏𝟎𝟎
𝑭𝑼 =
𝒏
En la tabla 4.7., se calcula ∑ , utilizando la escala de evaluación:
Tabla 4.6. Evaluación de preguntas para calcular la usabilidad

Nro. Preguntas Evaluación (xi)
¿El sistema satisface los requerimientos de manejo de
1 4
información?
2 Las salidas del sistema están de acuerdo a sus requerimientos? 4
3 ¿Cómo considera el ingreso de datos del sistema? 4
4 ¿Cómo considera los formularios que elabora el sistema? 4
5 ¿El sistema facilita el trabajo que realiza? 5
21

Calculando FU:
FU= [(21/5)*100]/5
FU= 84%
Por lo tanto, la facilidad de uso es del 84%.
4.1.6. Eficiencia
La eficiencia es el conjunto de atributos que se relacionan con el nivel de performance del
software y de la cantidad de recursos usados, bajo las condiciones establecidas, en tiempo y en
recursos.
El sistema se considera eficiente por la óptima utilización de los recursos.
139
CAPITULO 5
COSTOS
5.1. INTRODUCCION
Para calcular el costo del proyecto se lo realizara haciendo uso del modelo COCOMO II. El
modelo COCOMO tiene una jerarquía de modelos como ser: básico, intermedio y avanzado, la
cual se aplica a tres diferentes tipos de software.
 ORGANICO: Proyectos relativamente sencillos, menores a 5000 lineas de código,
implica procesamiento de datos, uso de la base de datos se focaliza en transacciones y
recuperación de datos.
 SEMIACOPLADO: Proyectos intermedios en complejidad y tamaño. La experiencia
en este tipo de proyectos es variable y las restricciones intermedias.
 EMPOTRADO: Proyectos bastantes complejos, en los que apenas se tiene
experiencia y en un entorno de gran innovación técnica.
Para el sistema que se está desarrollando se utilizara el modelo COCOMO en su nivel básico
semi-acoplado.
Aplicando de las formulas básicas de esfuerzo, tiempo calendario y personal requerido.
Las ecuaciones de COCOMO básico tiene la siguiente forma:
= ∗( )∗ (Ecuación 1)
= ∗( ) (Ecuación 2)
Dónde:
E= Esfuerzo aplicado en personas por mes.
D= Tiempo de desarrollo.
KLDC= Número estimado de líneas de código distribuidas (en miles).
Tabla 5.1. Coeficientes ab y cb y los exponentes bb y db
Proyecto de Software
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
FUENTE [PRE, 2000]
140
Los proyectos de software semi-acoplados, los proyectos intermedios (en tamaño y
complejidad) en los que equipos, con variados niveles de experiencia, deben satisfacer
requisitos poco y medio regidos, tal es el caso del software desarrollado.
= ∗( ) = =
= ∗( ) = =
El personal requerido, en este caso es el número de programadores, se obtiene con la siguiente

formula:
Numero de programadores = E / D
Numero de Programadores = 57,6 / 10,3
Numero de Programadores=5.59 = 6 programadores
El salario de un programador puede oscilar entre 700 $us, cifra que será tomada en cuenta para
la estimación siguiente:
Costo del software desarrollado = 6*700
Costo del software desarrollado = 4200 $us.
5.2. COSTO DE ELABORACION DEL PROYECTO

Los costos de elaboración del proyecto se refieren a los costos del estudio del sistema, en la
etapa de análisis y recopilación principalmente, estos costos se representan en la siguiente
tabla.
Tabla 5.2. Costo elaboración del proyecto
DETALLE IMPORTE ($us)
Análisis y diseño de sistema 2000
Bibliografía 200
Material de escritorio 300
Internet 350
Otros 300
TOTAL 3150
FUENTE [Elaboración Propia]
141
5.3. COSTO TOTAL
El costo es la sumatoria del costo del software desarrollado, costo de elaboración del proyecto,
detallados en la siguiente tabla.
Tabla. 5.3. Costo Total del proyecto

DETALLE IMPORTE($US)
Costo del Software Desarrollado 4200
Costo de Elaboración del Proyecto 3150
TOTAL 7350
FUENTE [Elaboración Propia]
De acuerdo al análisis demostrado mediante costos de COCOMO el presente proyecto de

Grado tiene un Costo Total de 7.350 $us.
142
CAPITULO 6
SEGURIDAD DEL SISTEMA
6.1. SEGURIDAD DEL SISTEMA
La seguridad de la información es el conjunto de medidas preventivas y reactivas de

las organizaciones y de los sistemas tecnológicos que permiten resguardar y proteger
la información buscando mantener la confidencialidad, la disponibilidad e integridad de la
misma.
El concepto de seguridad de la información no debe ser confundido con el de seguridad

informática, ya que este último sólo se encarga de la seguridad en el medio informático, pero
la información puede encontrarse en diferentes medios o formas, y no solo en medios
informáticos.
Para el hombre como individuo, la seguridad de la información tiene un efecto significativo

respecto a su privacidad, la que puede cobrar distintas dimensiones dependiendo de la cultura
del mismo.
El campo de la seguridad de la información ha crecido y evolucionado considerablemente a

partir de la Segunda Guerra Mundial, convirtiéndose en una carrera acreditada a nivel
mundial. Este campo ofrece muchas áreas de especialización, incluidos la auditoría de
sistemas de información, planificación de la continuidad del negocio, ciencia forense digital y
administración de sistemas de gestión de seguridad, entre otros.[HIJ, 2000].
 Seguridad a nivel Sistema Operativo

Se tiene un servidor LENOVO con el S.O. Ubuntu 14.2 y sus configuraciones
necesarias de red segura, como cortafuego activado, ssh y seguridad en IP.
 Seguridad a nivel Base de Datos

A nivel de base de datos se aplica la seguridad de copias de seguridad, acceso y
permiso a cuentas de usuario.
143
 Seguridad a nivel Software
Al ser un sistema web privado, se tiene un acceso de usuario (Login). Y un código de
seguridad para evitar acceso a personas no autorizadas al sistema.
A continuación se detalla los tipos de usuario.
Tabla. 5.3. Categorización de Niveles de Acceso

NIVEL USUARIO ATRIBUCIÓN
0 Organizaciones Sociales Consultas, Reportes, seguimiento de
proyectos
1 Administrador Registrar, Modificar, Actualizar todos los
módulos, Modulos SIG
2 Técnico Administrador Registrar, Modificar, Actualizar, Modulo
de Proyectos
3 Responsables, Autoridades Seguimiento de Proyectos por distrito,
Municipales Municipal
144
CAPITULO 7
CONCLUSIONES Y RECOMENDACIONES
7.1. CONCLUSIONES
El objetivo principal de este proyecto de grado, era desarrollar e implementar un “Sistema de
Información para el control y seguimiento de Proyectos Distritales vía Web”, con el objetivo
de apoyar el fortalecimiento del municipio de el Alto del Departamento de La Paz, con la
puesta en marcha del presente proyecto se llegó a su conclusión satisfactoria logrando alcanzar
los objetivos específicos propuestos y cumpliendo los diferentes requerimientos del
Municipio:
 El Municipio de El Alto cuenta con un portal web dinámico para difundir información
rápida, fiable y actualizada con respecto a los diferentes proyectos municipales que se
tienen en ejecución en el Municipio de El Alto.
 Con el desarrollo del sistema, la información generada por parte de la institución fue
centralizada, permitiendo un seguimiento físico y presupuestario para establecer el
estado del proyecto mediante reportes generados por el sistema.
 Con el desarrollo del sistema las máximas autoridades municipales podrán disponer de
información detallada y al instante con respecto a todos los proyectos que se están
ejecutando en el municipio de El Alto.
 Teniendo en cuenta el control a los proyectos que realiza el sistema, se puede conocer
el cumplimiento de fechas y el presupuesto de los proyectos que se ejecutan.
 Se creó una interfaz basada en la Web que permite la comunicación directa entre la
institución y la población alteña en general, ejemplo: (Chat, Consultas en línea, Correo
electrónico).
145
 Con la implementación del sistema, no es necesario ir en busca de información
recorriendo distancias considerables de un punto a otro. Dicha información se tendrá
disponible en el mismo portal web donde realizara la búsqueda del proyecto a través de
diferentes tipos de búsqueda como ser por el distrito municipal, el nombre de la
urbanización o también introduciendo del código sisin del proyecto buscado.
 Se automatizo la búsqueda de información mediante la creación de un módulo de

búsqueda de proyectos.
 El sistema estará disponible las 24 horas del día, donde la población alteña podrán
acceder al portal web, y podrá realizar diferentes consultas vecinales.
 A través del portal web se podrá ver la ubicación geo referencial del proyecto, obras
que son ejecutados por las sub alcaldías municipales, obras que ya fueron aprobados
dentro del poa anual.
 Se desarrolló un sistema mediante la metodología ágil RUP, la cual gracias a su ciclo

de vida permitió realizar iteraciones, lo cual favoreció el que se pueda atender a las
unidades ejecutoras de buena manera y sin perder tiempo, tomando en cuenta que el
trabajo fue realizado de manera individual.
 El desarrollo del sistema logro apoyarse eficientemente en las herramientas de

modelado que nos brinda el Lenguaje de Modelado Unificado UML, con el cual se
especificó el análisis y diseño del sistema.
7.2. RECOMENDACIONES
Una vez concluido el proyecto de grado se recomienda como nuevos trabajos de investigación
lo siguiente
 Implementar módulos que también hagan el seguimiento financiero a las direcciones
de finanzas, licitaciones, contrataciones.
146
 Implementar el módulo de personal, el cual pueda adaptarse y contribuir al presente
Proyecto de Grado.
 Realizar el mantenimiento del sistema en un determinado tiempo de (3 meses) para ver
el buen funcionamiento, en el almacenamiento de información y procesos concurrentes
como consultas, registro, etc.
 El presente proyecto puede aplicarse en varios municipios convirtiéndose en un aporte
para el estado Boliviano por la cual pueda controlar de manera transparente confiable y
centralizada los recursos asignados a los diferentes municipios.
No obstante ninguno de los incluidos en el software es definido, esto posibilita las

actualizaciones periódicas de acuerdo al avance en la utilización de las mismas o se podría
considerar implementar nuevos módulos para fortalecer y ampliar las necesidades que plantee
a la institución, de tal manera que este trabajo sirva como base para considerar nuevos
proyectos.
147
ANEXO
ANEXO 1
ARBOL DE OBJETIVOS
La Información La información estará Información Mantener la

será tomada en a disposición de los automatizada, confianza en la
su totalidad usuarios y población disponible y institución
alteña en general confiable
INFORMACION ACTUALIZADA, DISPONIBLE Y CONFIABLE PARA

REALIZAR EL PROCESO DE CONTROL Y SEGUIMIENTO DE
PROYECTOS EN EL MUNICIPIO DE EL ALTO
El personal La institución Buenas Buen manejo de

cuenta con una posee condiciones de la información
información información servicio de obtenida
actualizada confiable comunicación y
de la información
148
ANEXO 2
ARBOL DE PROBLEMAS
Reportes estadísticos
Toma de imprecisos o no
decisiones tardía actualizados
No se conoce
geográficamente la
Falta de información Datos no Molestia de la demanda insatisfecha
oportuna e inmediata fiables población en cuento a las obras
DEFICIENTE CONTROL Y SEGUIMIENTO DE LOS

PROYECTOS DISTRITALES
Descentraliz Posibles errores Demora en la Falta de En el aspecto

ación de la en la ejecución de los disponibilida de obras, no se
información centralización proyectos d de la cuenta con un
manual del información mapa que
seguimiento de muestre las
los proyectos obras
El acceso a la
información
para la
ciudadanía es
limitada
149
ANEXO 3
INFORMES – RESUMENES DE LOS PROYECTOS
Figura 4 [Interfaz de Usuario – Ubicación del proyecto]

Fuente: [Elaboración propia]
Figura 4.1 [Interfaz de Usuario – Resumen de proyectos por distritos]

150
Figura 4.2 [Interfaz de Usuario – Reporte resumen por tipo]
151
ANEXO 4
SIG – MAPAS TEMATICOS – PROYECTOS EN EJECUCION
Figura 4.3 [SIG – Pantalla Qgis Visor de Mapa]

Figura 4.4 [SIG – Pantalla Qgis conexión con la base de datos]

152
Figura 4.4 [SIG –PgAdmin base de Datos espacia ]
153
BIBLIOGRAFIA
 [ANONIMO, 2011]: “capacitación y guía para el desarrollo de Software ” disponible
en : [http://materias.fi.uba.ar/7548/PruebasSoftware.pdf
 [APR, 2015]: “Calidad del Software, métricas y Fiabilidad de aplicaciones”
 [CIEZAS, 2010]: “Sistemas de Información Geográfica”, disponible en:
https://langleruben.wordpress.com
 [CARBONA Y MONSALVE, 2009]: “Sistemas de Información Geográfica”,
disponible en : [http://www.monografias.com/trabajos/gis/gis.shtml]
 [CITES, 2009]: “Sistemas de Información Geográfico”, disponible en:
[https://sites.google.com/site/sigarcgis/4-modelo-vector--raster/ventajas-y-
desventajas].
 [ESIGSON’S, 2009]: “Tareas del SIG”, disponible en:
[https://esigson.wordpress.com/tipos-de-sistemas-de-informacion_mapa-conceoptual]
 [ENCALADA, GUAMAN, PUJOTA, 2012]: “Postgres”, disponible en la web en :
[http://es.slideshare.net/AlexPujota/sgbd-postgresql]
 [GAMEA, 2015] : “Manual de Organización y Funciones”. Gobierno Autónomo
Municipal de El Alto.
 [HIJ, 2000]: Highsmith, Jim, Adaptative Software Development a Collaborative
Approach to Managing, Dorset House, 2000.
 [IZAMORAR, 2015]: “Actividades Básicas de un Sistema de Información”,
disponible en: http://izamorar.com/actividades-basicas-de-un-sistema-de-informacion
 [JABORU, 2000]; “El lenguaje unificado de modelado”, Jacobson, Booch y
Rumbaugh, 2000
 [JIMDO]: “tipologías de Sistemas de Información Geográfica”, disponible en :
[http://arqueo-gis.jimdo.com/tipos-de-sig/]
 [LAR, 2000] Larmman Grain, 1999:”UML y Patrones introducción al análisis
Orientado a objetos”, Edición Prentice may, México.
 [MANRRIQUE, 2012]: “Lenguaje de Programación PHP”, disponible en:
[http://www.monografias.com/trabajos38/programacion-php/programacion-php.shtml]
154
 MENDOZA, 2009]: “Introducción a los Sistemas de Información Geográfica”, Ing.
Sc. Fernando Mendoza Jara, disponible en :
http://www.slideshare.net/fermenja/unidad-i-1-intro-sig-09
 [PERALTA, 2008]: “Sistemas de Información”, disponible:
[http://www.monografias.com]
 [PRESSMAN, 2003]: “Ingenieria de Software”, Roger S. Pressman, McGrawHill,
2003.
 [QUICENO, 2010]: “Lenguaje Unificado UML”, disponible en :
[http://thales.cica.es/rd/glinex/practicas-glinex05/informatica/uml/practica.pdf]
 [RENA 2008]: “Sistemas de Información”, disponible:
http://www.rena.edu.ve/cuartaEtapa/Informatica/Tema10.html
 [TICONA, 2007]: “Sistema de gestión de la información Geo referenciada caso unida
de Catastro INRA”, Ronald Ticona. 2007
 [WEB05]: “La estructura de internet”, disponible en la web:
[www.kalipedia.com/kalipediamedia/ingeniería/m…]
 [WIKI]: http://es.wikipedia
 [OOHDM, 2011]: disponible en [https://oohdm.wordpress.com/2011/02/01/hello-
world/]
155

Universidad Mayor de San Andres

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Universidad Mayor de San Andres

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRES

FACULTAD DE CIENCIAS PURAS Y NATURALES

PARA OPTAR AL TITULO DE LICENCIATURA EN INFORMATICA

POSTULANTE : WILMER MENDOZA TRUJILLO

TUTOR METODOLOGICO : LIC. FREDDY MIGUEL TOLEDO PAZ

REVISOR : LIC. JAVIER REYES PACHECO

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

El usuario está autorizado a:

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

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

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

A mi madre Agustina Trujillo.

A Lic. Luis Escobar S. Director de Tics y Desarrollo Organizacional, por darme la

A todos mis amigos y funcionarios de la Dirección de Tecnologías de la Información (TICs) y

En el siguiente capítulo, se da énfasis a todo lo que significa el proceso de desarrollo de

SEGURIDAD DEL SISTEMA

Anexo 2 Árbol de Problemas..…………………………………………………... 135

Anexo 3 Informes – resúmenes de los proyectos..……………………………… 136

Anexo 4 SIG-mapas temáticos-proyectos en ejecución..…… ………………… 138

Figura 2.1. Estructura Organizacional…………………………………………………...9

Figura 2.2. Componentes de un Sistema de Información……………………………...13

Figura 2.3. Definición simplificada de un SIG…………………………………………15

Figura 2.4. Ejemplo de uso del SIG………………………………………………….....16

Figura 2.5. Componentes de un SIG……………………………………………….…...16

Figura 2.6. Modelo Vectorial y raster…………………………………………………..19

Figura 2.7. Estructura del RUP…………………………………………………............25

Figura 2.8. Descripción de los elementos de un modelo de casos de uso……………..29

Figura 2.9. Elementos de un diagrama de secuencia…………………………………..30

Figura 2.10. Modelo de diagrama de colaboración……………………………………...30

Figura 2.11. Elementos de un diagrama de Clases ………………………………………31

Figura 2.12. Elementos de un diagrama de estados……………………………………..31

Figura 2.13. Representación de un diagrama de actividad………………………………32

Figura 2.14. Modelo Cliente Servidor…………………………………………………...33

Figura 2.15. Arquitectura Cliente/ Servidor..……………………………………………34

Figura 2.16. Pruebas de Software……...………………………………………………...41

Figura 3.1. Proceso de Contratación…………………………………………………...58

Figura 3.2. Proceso de Fiscalización y Supervisión de Obras…………………………59

Figura 3.4. Hoja de Seguimiento de Proyectos………………………………………...60

Figura 3.5. Cronograma de Actividades………………………………………………..60

Figura 3.7. Elaborar el proyecto…………………………………………………........ 63

Figura 3.8. Seguimiento del proyecto………………………………………………….63

Figura 3.9. Control y seguimiento del Proyecto……………………………………….64

Figura 3.10. Fiscalizar y Supervisar Obras……………………………………………..64

Figura 3.11. Diagrama de casos de uso general…………………………………………69

Figura 3.12. DCU Registro de Proyectos………………………………………………..71

Figura 3.13. DCU Proceso Administrativo…………………………………………….. 73

Figura 3.14. DCU Supervisión y Conclusión………………………………………….. 74

Figura 3.15. Diagrama de secuencia de acceso al sistema …………………………….. 76

Figura 3.16. Diagrama de secuencia Registro de Proyectos…………………………… 77

Figura 3.17. Diagrama de secuencia Proceso administrativo………………………….. 77

Figura 3.18. Diagrama de secuencia Supervisión y Conclusión………………………. 78

Figura 3.19. Diagrama de secuencias Consultas internas y externas………………….. 78

Figura 3.20. Casos de uso real-Ingreso al sistema …………………………………….. 83

Figura 3.21. Casos de uso real-Registro de Proyectos………………………………… 84

Figura 3.22. Casos de uso real-Ubicación Georeferencial ………………………………85

Figura 3.23. Casos de uso real-Proceso Administrativo……………………………….. 86

Figura 3.24. Casos de uso real-Proceso Administrativo-registro……………………… 87

Figura 3.25. Casos de uso real- Supervisión y conclusión ……………………………... 88

Figura 3.26. Casos de uso real-Supervisión y conclusión-registro…………………….. 89

Figura 3.27. Pantalla de caso de uso real: Consultas e información……………………90

Figura 3.28. Pantalla de caso de uso real: Portal de consultas externas……………….. 91

Figura 3.29. Pantalla de caso de uso real: Lista de Proyectos…………………………..92

Figura 3.30. Diagrama de secuencia-Acceso al sistema………………………………..93