Universidad Mayor de San Andrés: Facultad de Ciencias Puras Y Naturales Carrera de Informática

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA
“SISTEMA WEB DE CONTROL Y SEGUIMIENTO DE

OBRAS MUNICIPALES PARA LA SUBALCALDÍA DE
OVEJUYO D-I MUNICIPIO DE PALCA”
Proyecto de Grado para obtener el Título de Licenciatura en Informática
Mención Ingeniería de Sistemas Informáticos
POR: FRANKLIN PATRICIO RIVERO GONZALES

TUTOR METODOLÓGICO: M. SC. ALDO RAMIRO VALDEZ ALVARADO
ASESORA: PH. D. JAVIER HUGO REYES PACHECO
LA PAZ – BOLIVIA
2017
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.
LICENCIA DE USO
El usuario está autorizado a:
a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.

b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este

material, sin la autorización correspondiente.
TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
Dedicatoria:
El presente proyecto va dedicado especialmente:
A dios por darme fuerzas para seguir adelante e

iluminarme siempre que se presente una
barrera.
A mis padres, por el apoyo, cariño, amor,

paciencia, comprensión y siempre
incentivándome a seguir adelante.
A mi hermana y hermano por darme su

comprensión, cariño e incentivándome a mirar
hacia delante.
Agradecimientos:
 A dios, por bendecirme para llegar hasta donde he llegado, porque hiciste realidad
este sueño tan anhelado.
 A mis padres Luciano Rivero y Ascencia Gonzales, por apoyarme en todo momento,
por los valores que me han inculcado, y por haberme dado la oportunidad de tener
una excelente educación en el transcurso de mi vida.
 A mis hermanos Jhoset Cristian y Julia, por ser parte importante de mi vida y
representar la unidad familiar.
 A mi cuñado Jhimy Romero, por brindarme su apoyo en los momentos más difíciles.
 A mis sobrinos Jhefer y Frabricio, por sacarme una sonrisa en los momentos más
tristes de mi vida.
 A mi tutor M. Sc.Aldo Ramiro Valdez Alvarado por haberme guiado y dado la
enseñanza para concluir el presente proyecto de grado.
 A mi Asesor Ph. D. Javier Hugo Reyes Pacheco, por brindarme su tiempo, y por
guiarme paso a paso durante todo el proceso.
 A mi tío Felix Sejas, por brindarme su apoyo incondicional, por darme un buen
consejo y hacerme sentir que soy capaz de alcanzar todas mis metas, gracias por tu
apoyo tío.
 A mis tíos y primos, por sus palabras de motivación, por apoyarme en los
momentos más difíciles de mi vida.
 A los docentes de mi carrera, por haber compartido conmigo sus conocimientos y
sobre todo su amistad.
 A mis compañeros y amigos que siempre me han prestado un gran apoyo moral y
humano, necesarios en los momentos difíciles de este trabajo.
¡Muchas Gracias a todos!!

RESUMEN
EL presente proyecto de grado se pretende automatizar los procesos que realiza la unidad
de ejecución de proyectos de la Subalcaldía de Ovejuyo D-I Municipio de Palca, los
proceso que realiza esta unidad son la documentación de los proyectos, seguimiento de las
obras, entrega de obras, registro de técnicos y vecinos. En los últimos años habido
problema en el control y seguimiento que se realiza a las obras en ejecución, esto a causa de
la gran cantidad de obras que existe en la Subalcaldía.
Para dar solución a estos problemas se propuso el desarrollo e implementación de un

sistema web denominado “SISTEMA WEB DE CONTROL Y SEGUIMIENTO DE
OBRAS MUNICIPALES PARA LA SUBALCALDIA DE OVEJOYO D-I MUNICIPIO
DE PALCA”.
La metodología empleada en el presente proyecto es OpenUP, que brinda un desarrollo ágil

de software orientado a la web dividido en cuatro etapas: Inicio, Elaboración, Construcción
y Transición, cabe desatacar que para un mejor trabajo se fusiona con el uso de ingeniería
web UML-UWE, que es una herramienta comprensible y entendible.
Para el desarrollo del sistema se utilizaron lenguajes como PHP y JavaScript, para la
administración e base de datos es bajo el entorno MySQL, utilizando el servidor Apache
XAMPP.
Para determinar la calidad del sistema web se hace uso de la metodología Web SiteQEM, y
en cuanto a la seguridad se contempla por niveles (aplicación, base de datos y servidor).
Finalmente se determina los costos y beneficios que se obtendrán con el desarrollo del
sistema web, utilizando COCOMO II y el cálculo del Valor Actual neto (VAN) y la Taza
Interna de Retorno (TIR).
SUMMARY
The present degree project is intended to automate the processes carried out by the project
execution unit of the Ovejuyo Sub-Municipality of the Municipality of Palca. The process
carried out by this unit is the documentation of the projects, monitoring of the works,
delivery of works, registration of technicians and neighbors. In recent years there has been
a problem in the control and monitoring that is carried out on the works in execution, this
because of the great amount of works that exists in the Sub-Office.
To solve these problems, the development and implementation of a web system called
“SISTEMA WEB DE CONTROL Y SEGUIMIENTO DE OBRAS MUNICIPALES
PARA LA SUBALCALDIA DE OVEJOYO D-I MUNICIPIO DE PALCA” was proposed.
The methodology used in the present project is OpenUP, which provides an agile
development of web-oriented software divided into four stages: Start, Development,
Construction and Transition, it should be noted that for a better job is merged with the use
of UML web engineering -UWE, which is a comprehensible and understandable tool.
For the development of the system, languages such as PHP and JavaScript were used for
the administration of the database under the MySQL environment, using the Apache
XAMPP server.
In order to determine the quality of the web system, the Web SiteQEM methodology is
used, and in terms of security it is contemplated by levels (application, database and
server).
Finally the costs and benefits that will be obtained with the development of the web system
are determined, using COCOMO II and the calculation of the Net Present Value (VAN)
and the Internal Return Cup (TIR).
ÍNDICE
CAPÍTULO 1 ........................................................................................................................ 1
MARCO INTRODUCTORIO............................................................................................. 1
1.1. INTRODUCCIÓN ......................................................................................................... 1
1.2. ANTECEDENTES ........................................................................................................ 2
1.2.1. ANTECEDENTES INSTITUCIONALES ................................................................. 2
1.2.1.1. REDACCIÓN DEL CRONOGRAMA ANUAL DE PROYECTOS ..................... 3
1.2.1.2. ACTIVACIÓN DE PROYECTO ............................................................................ 4
1.2.1.3. VERIFICACIÓN DE LA SOLICITUD DE OBRA ................................................ 4
1.2.1.4. SOLICITUD DE COTIZACIÓN ............................................................................ 5
1.2.1.5. CRONOGRAMA DE ACTIVIDADES .................................................................. 6
1.2.1.6. SEGUIMIENTO DE LA OBRA ............................................................................. 6
1.2.1.7. ACATA DE ENTREGA DEFINITIVA .................................................................. 7
1.2.1.8. INAUGURACIÓN DE LA OBRA ......................................................................... 8
1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES ................................................ 9
1.3. PLANTEAMIENTO DEL PROBLEMA ...................................................................... 9
1.3.1. PROBLEMA CENTRAL ......................................................................................... 10
1.3.2. PROBLEMAS SECUNDARIOS ............................................................................. 10
1.4. DEFINICIÓN DE OBJETIVOS .................................................................................. 11
1.4.1. OBJETIVO GENERAL ........................................................................................... 11
1.4.2. OBJETIVOS ESPECÍFICOS ................................................................................... 11
1.5. JUSTIFICACIÓN ........................................................................................................ 11
1.5.1. JUSTIFICACIÓN ECONÓMICA ............................................................................ 12
1.5.2. JUSTIFICACIÓN SOCIAL ..................................................................................... 12
1.5.3. JUSTIFICACIÓN TECNOLÓGICA ....................................................................... 12
1.6. ALCANCES Y LÍMITES ........................................................................................... 13
1.6.1. ALCANCES ............................................................................................................. 13
1.6.2. LÍMITES .................................................................................................................. 14
1.7. APORTES ................................................................................................................... 14
1.7.1. PRÁCTICO .............................................................................................................. 14
1.7.2. TEÓRICO ................................................................................................................. 15
1.8. METODOLOGÍA ........................................................................................................ 16
CAPÍTULO 2 ...................................................................................................................... 17
MARCO TEÓRICO ........................................................................................................... 17
2.1. INGENIERIA DE SOFTWARE ................................................................................. 17
2.1.1. EL PROCESO DEL SOFTWARE ........................................................................... 18
2.1.1.1. MODELOS DEL PROCESO DEL SOFTWARE ................................................. 20
2.1.2. DESARROLLO AGIL ............................................................................................. 21
2.1.2.1. EL MANIFIESTO ÁGIL ...................................................................................... 23
2.2. METODOLOGÍA ÁGIL DE DESARROLLO: OPEN UP ......................................... 24
2.2.1. ROLES ..................................................................................................................... 26
2.2.2. CARACTERÍSTICAS DE OPEN UP ...................................................................... 27
2.2.3. PRINCIPIOS DE OPEN UP .................................................................................... 27
2.2.4. CICLO DE VIDA DE OPEN UP ............................................................................. 28
2.2.5. FASES Y ACTIVIDADES DE OPEN UP .............................................................. 29
2.3. INGENIERÍA WEB .................................................................................................... 30
2.4. METODOLOGÍA PARA EL DESARROLLO WEB: UWE ..................................... 32
2.4.1. FASES DE UWE ...................................................................................................... 32
2.4.2. ACTIVIDADES DE MODELADO DE UWE ......................................................... 34
2.4.2.1. ANÁLISIS DE REQUISITOS .............................................................................. 34
2.4.2.2. MODELO DE CONTENIDO ............................................................................... 36
2.4.2.3. ESTRUCTURA DE NAVEGACIÓN ................................................................... 36
2.4.2.4. MODELO DE PRESENTACIÓN ......................................................................... 38
2.5. HERRAMIENTAS DE DESARROLLO DE SOFTWARE ....................................... 39
2.5.1. FRAMEWORK LARAVEL .................................................................................... 39
2.5.2. FRAMEWORK BOOTSTRAP ................................................................................ 40
2.5.3. SISTEMA GESTOR DE BASE DE DATOS MYSQL ........................................... 40
CAPÍTULO 3 ...................................................................................................................... 41
MARCO APLICATIVO .................................................................................................... 41
3.1. INTRODUCCIÓN ....................................................................................................... 41
3.2. FASE DE INICIO ......................................................................................................... 42
3.2.1. IDENTIFICACIÓN DE LOS INTERESADOS ....................................................... 42
3.2.2. DESCRIPCIÓN DE LA POSIBLE SOLUCIÓN ..................................................... 43
3.2.3. VISIÓN GENERAL DEL SISTEMA ...................................................................... 46
3.3. FASE DE ELABORACIÓN ....................................................................................... 51
3.3.1. ARQUITECTURA ................................................................................................... 51
3.3.1.1. ARQUITECTURA DE LA APLICACIÓN .......................................................... 51
3.3.1.2. REQUERIMIENTOS TECNOLÓGICOS ............................................................. 52
3.3.2. ANÁLISIS ................................................................................................................ 52
3.3.2.1. MODELO DE REQUERIMIENTOS .................................................................... 52
3.3.2.2. CASOS DE USO ................................................................................................... 56
3.3.2.3. IDENTIFICACIÓN DE ACTORES ..................................................................... 61
3.3.2.4. MODELO DE CONTENIDO ............................................................................... 67
3.3.3. DISEÑO ................................................................................................................... 69
3.3.3.1. MODELO DE NAVEGACIÓN ............................................................................ 69
3.3.3.2. MODELO DE PRESENTACIÓN (MAQUETACIÓN) ....................................... 72
3.3.3.3. DIAGRAMA ENTIDAD – RELACIÓN .............................................................. 76
3.3.3.4. INTERFAZ DEL SISTEMA ................................................................................. 79
3.4. FASE DE TRANSICIÓN ............................................................................................ 83
3.4.1. PRUEBAS DEL SISTEMA ..................................................................................... 83
3.4.1.1. CASOS DE PRUEBA ........................................................................................... 83
3.4.2. PRUEBAS DE STRESS........................................................................................... 88
3.4.2.1. LOAD IMPACT .................................................................................................... 89
CAPÍTULO 4 ...................................................................................................................... 91
CALIDAD Y SEGURIDAD ............................................................................................... 91
4.1. INTRODUCCIÓN ....................................................................................................... 91
4.2. CALIDAD ................................................................................................................... 91
4.2.1. METODOLOGÍA WEB SITEQEM ........................................................................ 91
4.2.1.1. DEFINICIÓN DE LOS REQUERIMIENTOS DE CALIDAD ............................ 91
4.2.1.2. EVALUACIÓN ELEMENTAL ............................................................................ 92
4.2.1.3. EVALUACIÓN GLOBAL ..................................................................................... 96
4.3. SEGURIDAD ............................................................................................................... 97
4.3.1. RESTRICCIÓN DE SESIONES .............................................................................. 97
4.3.2. CONTROL DE INGRESO AL SISTEMA .............................................................. 98
4.3.3. SEGURIDAD DE LA BASE DE DATOS .............................................................. 98
CAPÍTULO 5 ...................................................................................................................... 99
ANALISIS COSTO BENEFICIO ..................................................................................... 99
5.1. INTRODUCCIÓ .......................................................................................................... 99
5.2 COSTO DE SOFTWARE ............................................................................................ 99
5.2.1. PUNTO DE FUNCIÓN ............................................................................................ 99
5.2.2. PUNTO DE FUNCIÓN SIN AJUSTAR .................................................................. 99
5.2.3. CALCULO DE ESFUERZO .................................................................................. 101
5.2.4 COSTO TOTAL DEL SOFTWARE ....................................................................... 104
5.3. FACTIBILIDAD ECONOMICA .............................................................................. 105
5.3.1 CALCULO DEL RETORNO DE INVERSION ..................................................... 105
5.3.1.1. VAN (Valor Actual Neto) ................................................................................... 105
5.3.1.2. TIR (Tasa Interna de Retorno)............................................................................. 106
5.3.1.3. BENEFICIO/COSTO .......................................................................................... 106
CAPÍTULO 6 .................................................................................................................... 107
CONCLUSIONES Y RECOMENDACIONES ............................................................. 107
6.1. CONCLUSIONES ..................................................................................................... 107
6.2. RECOMENDACIONES ........................................................................................... 108
BIBLIOGRAFÍA .............................................................................................................. 110
ÍNDICE DE FIGURAS
Figura 1.1 Cronograma anual de proyectos ............................................................................ 3

Figura 1.2 Carta de solicitud de obra ...................................................................................... 4
Figura 1.3 Búsqueda de proyectos .......................................................................................... 5
Figura 1.4 Hoja de cotización ................................................................................................. 5
Figura 1.5 Cronograma de Actividades .................................................................................. 6
Figura 1.6 Hoja de ruta ........................................................................................................... 7
Figura 1.7 Acta de entrega definitiva ..................................................................................... 7
Figura 1.8 Almacenamiento de la documentación de proyectos ............................................ 8
Figura 2.1 Capas de la ingeniería de software ...................................................................... 17
Figura 2.2 Proceso de desarrollo Open Up ........................................................................... 25
Figura 2.3 Ciclo de vida de Open Up .................................................................................. 29
Figura 2.4 Fases de UWE ..................................................................................................... 33
Figura 2.5 Modelos de UWE ................................................................................................ 34
Figura 2.6 Diagrama de casos de uso ................................................................................... 35
Figura 2.7 Modelo de contenido ........................................................................................... 36
Figura 2.8 Estereotipo de estructura de navegación ............................................................. 37
Figura 2.9 Clases de navegación .......................................................................................... 37
Figura 2.10 Pagina de presentación ...................................................................................... 39
Figura 3.1 Arquitectura del sistema ...................................................................................... 51
Figura 3.2 Casos de uso general ........................................................................................... 57
Figura 3.3 Casos de uso de registro de proyecto modelo ..................................................... 58
Figura 3.4 Casos de uso de solicitud de obras ...................................................................... 59
Figura 3.5 Casos de uso de publicación de obras ................................................................. 60
Figura 3.6 Caso de uso para el seguimiento de obras ........................................................... 60
Figura 3.7 Caso de uso para el control de obras ................................................................... 61
Figura 3.8 Diagrama de Clases ............................................................................................. 68
Figura 3.9 Modelo de navegacion para el registro de proyectos modelo ............................. 69
Figura 3.10 Modelo de navegacion para el registro de solicitud de obras ........................... 70
Figura 3.11 Modelo de navegacion para la publicacion de obras ........................................ 70
Figura 3.12 Modelo de navegacion para el seguimiento de obras ....................................... 71
Figura 3.13 Modelo de navegacion para el control de obras ................................................ 71
Figura 3.14 Modelo de presentacion para el registro de proyecto modelo .......................... 72
Figura 3.15 Modelo de presentacion para la solicitud de obras ........................................... 73
Figura 3.16 Modelo de presentacion para la publicacion de obras ...................................... 74
Figura 3.17 Modelo de presentacion para el seguimiento de obras ..................................... 75
Figura 3.18 Modelo de presentacion para el control de obras .............................................. 76
Figura 3.19 Diagrama entidad relacion ................................................................................ 77
Figura 3.20 Modelo relacional.............................................................................................. 78
Figura 3.21 Login de usuario ................................................................................................ 79
Figura 3.22 Pantalla de Inicio ............................................................................................... 79
Figura 3.23 Registro de Proyectos ........................................................................................ 80
Figura 3.24 Listado de proyectos ......................................................................................... 80
Figura 3.25 Registro de solicitud.......................................................................................... 81
Figura 3.26 Listado de solicitudes ........................................................................................ 81
Figura 3.27 Reporte de proyectos ......................................................................................... 82
Figura 3.28 Estadísticas por categorías ................................................................................ 82
Figura 3.29 Diseño de construcción- prueba de estrés I ....................................................... 89
Figura 3.30 Diseño de construcción- prueba de estrés II ..................................................... 90
Figura 4.1 Login de Usuario ................................................................................................. 97
Figura 4.2 Control de ingreso al sistema .............................................................................. 98
ÍNDICE DE TABLAS
Tabla 2.1 Tabla metodologías agiles vs tradicionales .......................................................... 23

Tabla 2.2 Principios del manifiesto ágil ............................................................................... 24
Tabla 2.3 Descripción de roles de equipo de trabajo Open Up ............................................ 27
Tabla 2.4 Características de Open Up .................................................................................. 28
Tabla 2.5 Actividades de acuerdo a la fase de Open Up ...................................................... 30
Tabla 3.1 Relación fases Open Up y herramientas UWE..................................................... 42
Tabla 3.2 Descripción de los interesados ............................................................................. 43
Tabla 3.3 Problemas relacionados al Alcalde ....................................................................... 44
Tabla 3.4 Problemas relacionados al Oficial Mayor Técnico .............................................. 44
Tabla 3.5 Problemas relacionados al Supervisor de Obras .................................................. 45
Tabla 3.6 Problemas relacionados a la Secretaria ................................................................ 45
Tabla 3.7 Problemas relacionados a los Dirigentes .............................................................. 46
Tabla 3.8 Solución propuesta al registro de proyectos modelos .......................................... 47
Tabla 3.9 Solución propuesta al registro de solicitudes de obras ......................................... 47
Tabla 3.10 Solución propuesta al registro de solicitudes de obras ....................................... 48
Tabla 3.11 Solución propuesta al Seguimiento de obras ...................................................... 49
Tabla 3.12 Solución propuesta al control de obras ............................................................... 49
Tabla 3.13 Solución propuesta a la generación de reportes ................................................. 50
Tabla 3.14 Solución propuesta a la administración del sistema ........................................... 50
Tabla 3.15 Requerimientos funcionales para la administración de proyectos modelo ........ 53
Tabla 3.16 Requerimientos funcionales para el registro obras solicitadas ........................... 54
Tabla 3.17 Requerimientos funcionales para la publicación de obras ................................. 54
Tabla 3.18 Requerimientos funcionales para el seguimiento de obras................................. 55
Tabla 3.19 Requerimientos funcionales para el control de obras ......................................... 55
Tabla 3.20 Requerimientos funcionales para la generación de reportes .............................. 56
Tabla 3.21 Identificación de los actores con el sistema ....................................................... 62
Tabla 3.22 Especificación de registro de proyectos modelo ................................................ 63
Tabla 3.23 Especificación de solicitud de obras................................................................... 64
Tabla 3.24 Especificación de publicación de obras .............................................................. 65
Tabla 3.25 Especificación de seguimiento de obras ............................................................. 66
Tabla 3.26 Especificación de control de obras ..................................................................... 67
Tabla 3.27 Caso de prueba para el registro de proyectos modelo ........................................ 84
Tabla 3.28 Caso de pruevas para la solicitud de obras ......................................................... 85
Tabla 3.29 Caso de prueba para publicacion de obras ......................................................... 86
Tabla 3.30 Caso de prueba para el seguimiento de obras ..................................................... 87
Tabla 3.31 Caso de prueba para el control de obras ............................................................. 88
Tabla 4.1 Resultado de criterio de Ussblilidad ..................................................................... 93
Tabla 4.2 Resultado de criterio de Funcionabilidad ............................................................. 94
Tabla 4.3 Resultado de criterio de Confiabilidad ................................................................. 95
Tabla 4.4 Resultado de criterio de Eficiencia ....................................................................... 96
Tabla 4.5 Resultado de Calidad Global ................................................................................ 96
Tabla 5.1 Componentes para calcular punto de función .................................................... 100
Tabla 5.2 Calculo de punto de función sin ajustar ............................................................. 101
Tabla 5.3 Tabla de factor LDC ........................................................................................... 102
Tabla 5.4 Relación de Valores (Cocomo) .......................................................................... 103
Tabla 5.5 Costo de elaboración del proyecto ..................................................................... 104
CAPÍTULO 1
MARCO INTRODUCTORIO
1.1. INTRODUCCIÓN
La tecnología ha ido avanzando de manera muy acelerada, haciendo que los procesos
administrativos sean más factibles y rápidas. Uno de los usos más vanguardistas que se ha
dado en los últimos años es en el apoyo a las operaciones y gestiones que realizan las
empresas e instituciones tanto públicas como privadas.
Algunas instituciones públicas manejan información digital, la información digital es una

forma moderna de visualizar, analizar y conocer los datos que son muy valiosos para las
instituciones, puesto que de ella depende la toma de decisiones que puede afectar en el
manejo administrativo.
Las instituciones públicas en La Paz, con el trascurrir del tiempo hacen uso de tecnologías
que les facilite la administración y mantener una buena organización, para que el acceso a la
información sea de manera muy segura y organizada.
La Sub alcaldía de Ovejuyo, maneja su presupuesto de forma autónoma con el objetivo

principal de mantener una gestión transparente, una buena organización interna, una buena
atención así a los vecinos y sobre todo agilizar los trámites que se realizan en la institución.
Para tal efecto, El presente documento se propone un sistema de información para una mejor
planificación del control y seguimiento de Obras Municipales, esto como análisis de los
problemas que afectan a los diferentes Municipios de nuestro país.
Las principales fuentes de información para este proyecto son: La unidades Despacho del
Sub-Alcalde, unidad de ejecución de proyectos y secretaria.
Este sistema web ayudara de gran manera a la unidad de ejecución de proyectos ya que
permitirá visualizar todas las obras concluidas e inconclusas, así también aquellas obras que
están en proceso, también brindara información detallada a los vecinos de las comunidades
que conforma este distrito.
1
1.2. ANTECEDENTES
1.2.1. ANTECEDENTES INSTITUCIONALES
El D-I Municipio de Palca, se encuentra al sur de la ciudad de La Paz, este distrito es

perteneciente a la Alcaldía de Palca de la primera sección, provincia Murillo.
Esta institución pública cuenta con instalaciones propias, una oficina central ubicada en la
Calle 62, Zona Ovejuyo, en estas instalaciones están concentradas todas las unidades, como
los trámites catastrales, tramites de construcción de vivienda, aprobación de proyectos,
quejas y toda la atención así a los vecinos.
La Sub alcaldía de Ovejuyo cuenta con las siguientes dependencias:
 Despacho del Sub alcalde

 Unidad de ejecución de proyectos
 Departamento de trámites catastrales
 Recaudación de impuestos
 Secretaria
La participación en las actividades de los barrios de parte de los vecinos del Distrito I es muy
alta, debido a que han tenido que organizarse para poder contar con los servicios básicos e
infraestructura adecuada, esta participación se aplica a través de asambleas que son
convocadas por los dirigentes, elegidos por la misma junta vecinal.
Cada Zona o Comunidad tiene un dirigente que los representa ante la Sub-Alcaldía de
Ovejuyo, ellos son los que realizan trámites para la aprobación de diferentes obras.
La prioridad de la Sub alcaldía es impulsar el desarrollo urbano y rural en su Municipio,

mediante la ejecución de obras establecidas en el POA vecinal, estas están relacionadas con
las siguientes Obras:
 Apertura de caminos.
 Empedrado
 Programas de riego.
2
 Alcantarillado.
 Construcción de puentes.
 Construcción de escuelas.
 Construcción de sedes sociales.
 Áreas verdes.
 Arquitectura urbana.
 Equipamiento
 Mantenimiento de los mismos.
En la actualidad los procesos institucionales que se llevan a cabo en la Sub alcaldía de

Ovejuyo son realizados de manera manual.
Los dirigentes de cada zona deben realizar varios procedimientos para que su solicitud sea
aprobada por la Sub alcaldía.
La unidad de ejecución de proyectos, realiza una serie de procesos para la aprobación,

ejecución y conclusión de las obras, estos procesos son los siguientes:
1.2.1.1. REDACCIÓN DEL CRONOGRAMA ANUAL DE PROYECTOS
La unidad de ejecución de proyectos comandado por el oficial mayor, realizan un cronograma

anual de posibles proyectos que se ejecutaran durante el año, estos proyectos son destinados
a cada comunidad de acuerdo al POA que le corresponde.
Figura 1.1 Cronograma anual de proyectos

Fuente: Elaboración propia
3
1.2.1.2. ACTIVACIÓN DE PROYECTO
Para que un proyecto se active, un dirigente de una comunidad debe enviar una carta dirigida
al Sub-Alcalde, con la firma y sello de los dirigentes de la comunidad, en esta carta se
detallara el tipo de obra que requiere la comunidad.
La recepción de dicha carta se realiza en secretaria, esta carta es enviada inmediatamente al

oficial mayor de la unidad de ejecución de proyectos.
Figura 1.2 Carta de solicitud de obra

1.2.1.3. VERIFICACIÓN DE LA SOLICITUD DE OBRA
La solicitud de Obra que llega a la institución mediante una carta por parte de los dirigentes,
pasa por un proceso de análisis. En primera instancia se verifica si el proyecto que se está
solicitando se encuentra registrado en el cronograma anual de proyectos, posteriormente pasa
por un estudio, que es realizado por los técnicos, que verifican si realmente es necesario que
se ejecute la obra solicitada. En la figura 1.3 podrá observar donde se verifica la obra.
4
Figura 1.3 Búsqueda de proyectos
1.2.1.4. SOLICITUD DE COTIZACIÓN
La unidad de ejecución de proyectos tiene técnicos que realizan la cotización detallada de la

obra que se ejecutara, pero antes de que se realice la cotización, el proyecto debe tener el
visto bueno del oficial mayor de la unidad de ejecución de proyectos y del Sub-Alcalde.
En la figura 1.4 se muestra la hoja de cotización, en esta cotización se detalla el código del
proyecto, nombre de la comunidad donde se ejecutara el proyecto, tipo de obra, descripción
de los materiales y/o equipos y costos por unidad.
Figura 1.4 Hoja de Cotización

5
1.2.1.5. CRONOGRAMA DE ACTIVIDADES
Luego de pasar por los puntos mencionados se realiza un cronograma de actividades de la

obra.
El cronograma de actividades es de mucha importancia para el oficial mayor de la unidad de

ejecución de proyectos ya que en aquí se detallara el tiempo que se demorara cada actividad
y sobre todo el tiempo estimado en que se demorara en finalizar la obra.
Figura 1.5 Cronograma de actividades

1.2.1.6. SEGUIMIENTO DE LA OBRA
El seguimiento de la obra es realizada por un técnico, quien es designado por el oficial mayor
de la unidad de ejecución de proyectos, este técnico deberá brindar información detallada del
avance de la obra.
El seguimiento es realizado en tres ocasiones durante la ejecución de la obra, este técnico

deberá verificar el proceso que sigue la obra de acuerdo con el cronograma de actividades.
La información obtenida del control de la obra es registrada en una hoja de ruta donde se
detalla el avance y los problemas que tiene, esta hoja es entregada al oficial mayor de la
unidad de ejecución de proyectos. En la figura 1.6 podrá observar la hoja de seguimiento.
6
Figura 1.6 Hoja de ruta
1.2.1.7. ACATA DE ENTREGA DEFINITIVA
En el acta de entrega se detalla el nombre de la comunidad, nombre del supervisor de obras,

nombre del fiscal de obra, monto ejecutado, avance de obra, fecha de inicio, fecha de
conclusión, etc. En la figura 1.7 podremos ver con más detalle el acta de entrega.
Figura 1.7 Acta de entrega definitiva

7
1.2.1.8. INAUGURACIÓN DE LA OBRA
La inauguración de la obra es realizada por parte de las zonas y/o comunidades juntamente
con la Sub alcaldía.
La Sub alcaldía envía un comunicado a los dirigentes de la comunidad para fijar la fecha de
inauguración, los dirigentes juntamente con los vecinos realizan una serie de actividades para
recibir al Sub-Alcalde y los técnicos que hicieron posible la conclusión de la obra.
El sistema que maneja la unidad de ejecución de proyectos es manual, en el caso de

aprobación, ejecución y conclusión de los proyectos, apoyándose también en el uso
herramientas ofimáticas, en este caso Microsoft Word.
El almacenamiento de toda la documentación es realizada en empastados; archivadores,

libros y folders.
En ocasiones hubo dificultad de activar proyectos que se paralizaron por diferentes razones,
esto debido a que no había documentación guardada y si había se extravió.
Figura 1.8 Almacenamiento de la documentación de proyectos

8
1.2.2. ANTECEDENTES DE PROYECTOS SIMILARES
La Sub alcaldía de Ovejuyo D-I Municipio de Palca, no cuenta con antecedentes de proyectos
similares desarrollados anteriormente, sin embargo, existen proyectos de grado que
contemplan Sistema de Control y Seguimiento de Obras Municipales, desarrollados en la
Cerrera de Informática de la Universidad Mayor de San Andrés y otros lugares, a
continuación, mencionaremos los proyectos:
El proyecto de Ibarra (2007) titulado Sistema de información para el control y

seguimiento de proyectos vía web; Caso Gobierno Municipal de Mecapaca. Plantea un
sitio web de publicación de los proyectos municipales y todo el proceso administrativo del
Gobierno Municipal de Mecapaca sin profundizar en el seguimiento de los proyectos en
ejecución no dotando de información como: el estado en el que se encuentra el proyecto, la
información de las empresas que trabajan con el Municipio, maquinas con las que cuenta,
información del personal encargado del proyecto y otros.
El proyecto de Pérez (2011) titulado Sistema de Seguimiento y Control de ejecución de

obras de proyectos municipales aplicando el método balanced scorecard; Caso Gobierno
Municipal de Chacarilla. Aplica el concepto de gobierno electrónico y la implementación
de la metodología Balanced Scorecard para el Municipio de Chacarilla, para mejorar
específicamente al control y seguimiento de un proyecto ya aprobado y que se encuentre en
el P.O. A. MUNICIPAL.
El proyecto de Avalos (2007) titulado Sistema de Información Geográfico de Control y

Seguimiento de Obras Municipales; Caso Sub-Alcaldía de Cotahuma. El sistema se
implementó para la toma de decisiones de las obras Municipales en base a los datos espaciales
y alfanuméricos del control y seguimiento de las mismas, que se está desarrollando en base
a las necesidades de la Sub-Alcaldía “Cotahuma”.
1.3. PLANTEAMIENTO DEL PROBLEMA
La Sub alcaldía de Ovejuyo D-I Municipio de Palca tiene mucha responsabilidad en la

ejecución de Proyectos, actualmente no cuenta con una herramienta tecnológica que provea
9
información adecuada de la administración de calidad de operación de las Obras. En un
comienzo no se veía la necesidad de una herramienta tecnológica, pero con el paso de los
años y la creciente ejecución de proyectos se ha vuelto engorroso el control y seguimiento de
las Obras.
1.3.1. PROBLEMA CENTRAL
Tomando en cuenta lo anteriormente descrito podemos plantear la siguiente pregunta: ¿Cómo

obtener información detallada de los proyectos que están en proceso de aprobación, ejecución
y conclusión, de manera que se brinde información eficiente y verídica a la Sub alcaldía de
Ovejuyo D-I Municipio de Palca?
1.3.2. PROBLEMAS SECUNDARIOS
Identificamos los siguientes problemas:
 La excesiva documentación que se tiene en la institución, haciendo que se demore en el

acceso a la información de las Obras concluidas e inconclusas.
 El trámite de aprobación de proyectos es tardío, provocando el retardo en la ejecución de
las Obras.
 Dificultad en el seguimiento de los proyectos debido a la distancia que existe entre la
oficina de la Sub alcaldía y la localización de los proyectos que están en ejecución.
 Los dirigentes de las comunidades no pueden realizar su reclamo sobre la obra al instante,
primero deben ir a las instalaciones para realizar su reclamo. En algún caso se vio que las
comunidades quedaban un poco alejadas de las instalaciones. Esto provoca que su
reclamo sea atendida de manera tardía.
 No se tiene los datos personales de los técnicos que están destinados en la ejecución de
un determinado proyecto, los vecinos tiene escasa información del técnico que realiza el
seguimiento de la obra.
 No cuenta con los datos personales de los dirigentes de cada comunidad o zona,
provocando la deficiente coordinación respecto a las actividades que se realizan entre la
Sub alcaldía y los dirigentes.
10
 El incumplimiento en el cronograma de trabajo por parte de los contratistas, debido a que
no se realiza un control y seguimiento adecuado por parte de la Sub alcaldía.
1.4. DEFINICIÓN DE OBJETIVOS
1.4.1. OBJETIVO GENERAL
Implementar un Sistema Web de Control y Seguimiento de Obras Municipales para la Sub

alcaldía de Ovejuyo D-I Municipio de Palca, que provea a las autoridades instancias técnicas
responsables operacionales de base de información de manera eficiente y verídica para la
toma de decisiones.
1.4.2. OBJETIVOS ESPECÍFICOS
 Se llevará a cabo la automatización de los documentos que ingresan a la institución

pública, de los proyectos que está en aprobación y los que están en ejecución.
 Obtener información oportuna y en tiempo real del estado en el que se encuentra la
aprobación de los proyectos.
 Se facilitara el seguimiento y control de los proyectos haciendo el uso del INTERNET
como una herramienta de comunicación entre los participantes en las Obras.
 Se brindada un espacio para que los dirigentes puedan realizar sus reclamos de
manera rápida, así sus reclamos sean atendidas en menor tiempo posible.
 Implementar el registro de datos personales de los técnicos, estos datos podrán ser
accesibles tanto para el Municipio como para los vecinos.
 Realizar un registro, donde se extraerá los datos necesarios de los dirigentes para una
mejor coordinación entre el Municipio y los dirigentes de cada Zona y/o Comunidad.
 Elaborar un informe específico donde se verificara el avance que tiene el contratista,
de acuerdo al cronograma de actividades.
1.5. JUSTIFICACIÓN
El proyecto se justifica económicamente, socialmente y tecnológicamente por las siguientes

razones:
11
1.5.1. JUSTIFICACIÓN ECONÓMICA
El proyecto económicamente es factible, esto a través del Sistema Web la cual automatiza el
tiempo de acceso a la información, reduce de gran manera el manejo de la documentación,
además aminora los gastos económicos en la planificación de las Obras, haciendo que las
Obras se ejecuten entiempo establecido.
Con la información que ingrese a la institución se analizara la implementación de proyectos

y refacción de las mismas, realizando una inversión oportuna.
Un sistema que facilite la gestión de los presupuesto es de mucha necesidad, se tendrá

información más precisa y al alcance de la unidad y Sub-Alcalde al momento que así lo
necesite.
1.5.2. JUSTIFICACIÓN SOCIAL
El Sistema ayudara agilizando el manejo de la documentación a la unidad de ejecución de

proyectos, reduciendo el tiempo en la aprobación, ejecución y conclusión de los proyectos.
Los dirigentes de las zonas o Comunidades se beneficiarán con el sistema ya que el sistema
minimizara los trámites de solicitud de Obras y brindara información rápida y confiable.
También los dirigentes podrán realizar reclamos de una determinada obra.
1.5.3. JUSTIFICACIÓN TECNOLÓGICA
El uso de la tecnología en las instituciones públicas toma un rol muy importante, algunas
instituciones no hacen el uso de tecnologías quedando al margen de la evolución tecnología,
las tecnologías deben ser aprovechar al máximo.
Considerando este contexto, el presente proyecto de justifica tecnológicamente por los

siguientes aspectos:
 El sistema web automatizara la documentación existente garantizando el acceso a la

información de manera eficaz y transparente.
 El sistema web es una herramienta de apoyo, para la gestión de aprobación, ejecución y
conclusión de proyectos.
12
 El sistema también será adaptable y accesible mediante dispositivos móviles, facilitara el
uso de la misma, desde cualquier lugar, comunidad y en cualquier momento.
1.6. ALCANCES Y LÍMITES
Los alcances definen los módulos que comprende el sistema web y límites denota los
aspectos que no se considerara.
1.6.1. ALCANCES
El proyecto de grado que se está realizando es para implementar un sistema de control y

seguimiento de las Obras Municipales y abarca los siguientes módulos:
Módulo de administración del sistema
 Login de usuarios.
 Acceso por niveles de usuario.
 Seguridad del sistema.
 Copia de seguridad del sistema.
Módulo de administración de proyectos
 Registro de proyectos en proceso de aprobación.

 Registro de proyectos en ejecución.
 Registro de proyectos concluidos.
 Modificación de los datos.
Módulo de administración de técnicos
 Registro de los técnicos.

 Modificación de datos.
 Baja de técnico.
 Acceso a información del técnico.
Módulo de administración de los dirigentes
 Registro de los dirigentes.
13
 Modificación de datos.
 Baja de dirigentes.
 Acceso a información de dirigentes.
Módulo de control y seguimiento
 Registro de los avances.

 Registro de los seguimientos.
 Modificación de los datos.
 Eliminación.
Módulo de reclamos
 Ingreso usuario y contraseña

 Registro del reclamo.
 Publicación de los reclamos.
Módulo de búsqueda
 Búsqueda de dirigentes por nombre.

 Búsqueda de proyectos por nombre y gestión.
1.6.2. LÍMITES
El presento proyecto no toma en cuenta aspectos como:
El manejo contable del Gobierno Municipio de Palca.
El manejo de planillas de sueldos de las empresas que realizaran una determinada Obra.
La elaboración de proyectos en la etapa de Pre-inversión.
1.7. APORTES
1.7.1. PRÁCTICO
El aporte práctico que ofrecerá el sistema será la automatización de los procesos rutinarios,
minimizar y optimizar el tiempo de ejecución generando información que facilite a la toma
de decisiones.
14
El Sistema brindara al usuario contar con una herramienta de automatización a la medida de
sus requerimientos, para un óptimo control de la información correspondiente a la ejecución
de los proyectos.
Informes y reportes que emitirá el sistema con información correcta que ayude al
departamento de aprobación y ejecución de proyecto en la toma de decisiones.
El módulo de registro facilitara al administrador en el almacenamiento de los datos que

correspondientes a los técnicos y dirigentes.
El módulo de control y seguimiento permitirá reportar la información requerida por el usuario

a través del administrador además de verificar el cumplimiento de la planificación de los
proyectos en ejecución.
El módulo de reclamos brindara permitirá a los dirigentes acortar tiempo en la respuesta y

minimizar el tiempo de atención del reclamo.
El modulo búsqueda permitirá realizar la búsqueda de los usuarios de manera más fácil y
rápida
1.7.2. TEÓRICO
El aporte teórico del proyecto es el uso de la metodología de desarrollo de software:
Metodología Open Up, nos ayudara en el desarrollo de software. Esta metodología nos
permitirá sincronizar intereses, compartir conocimientos, equilibrar las prioridades para
maximizar los beneficios, centrarnos en la arquitectura de forma temprana para minimizar el
riesgo y organizar el desarrollo.
UWE (UML Web Engineering), Esta herramienta personaliza el sistema, realiza la

definición de un modelo de usuarios o una etapa de definición de características adaptativas
de la negación en función de las preferencias, conocimiento o tareas de usuarios. Está
herramienta será un buen complemento a la metodología para su mejor desarrolló e
implementación.
Además, la conjunción de ambas metodologías en el proceso de desarrollo del sistema
15
permitirá una visión nueva de implementar sistemas y aplicaciones web.
1.8. METODOLOGÍA
La metodología que se utilizara en el desarrollo del presente proyecto son los siguientes:
La metodología que se utiliza es Open Up, es una metodología para el desarrollo de software
basado en RUP, que aplica las ventajas del desarrollo incremental e iterativo en su ciclo de
vida, OPENUP tiene un enfoque de filosofía ágil, teniendo en cuenta la naturaleza
colaborativa del desarrollo de software.
Faces o ciclos de vida:
 Inicio
 Elaboración
 Construcción
 Transición
Se utilizara la herramienta del Lenguaje Unificado de Modelado (UML), es el lenguaje

más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management
Group), para modelar el análisis y desarrollo del software.
Para la implementación del sistema, se ara el uso de las siguientes herramientas:
AJAX (Asynchronous JavaScript and XML), que involucra: HTML, JavaScript, CSS y PHP,
nos ayudarán al diseño e implementación de una Tecnología Web.
Como motor de Base de Datos se utilizara MySql debido a la enorme información y para su
manejo se utilizara el Lenguaje Estructurado de Consultas SQL.
16
CAPÍTULO 2
MARCO TEÓRICO
2.1. INGENIERIA DE SOFTWARE
La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y

cuantificable al desarrollo, operación y mantenimiento de software; es decir, la aplicación de
la ingeniería al software (Pressman, 2010).
La ingeniería de software es una tecnología con varias capas. Como se aprecia en la Figura
2.1., cualquier enfoque de ingeniería (incluso la de software) debe basarse en un compromiso
organizacional con la calidad. La administración total de la calidad, Six Sigma y otras
filosofías similares alimentan la cultura de mejora continua, y es esta cultura la que lleva en
última instancia al desarrollo de enfoques cada vez más eficaces de la ingeniería de software.
El fundamento en el que se apoya la ingeniería de software es el compromiso con la calidad
(Pressman, 2010).
Figura 2.1 Capas de la ingeniería de software

Fuente: (Pressman, 2010)
El fundamento para la ingeniería de software es la capa proceso. El proceso de ingeniería de

software es el aglutinante que une las capas de la tecnología y permite el desarrollo racional
y oportuno del software de cómputo. El proceso define una estructura que debe establecerse
para la obtención eficaz de tecnología de ingeniería de software. El proceso de software
forma la base para el control de la administración de proyectos de software, y establece el
contexto en el que se aplican métodos técnicos, se generan productos del trabajo (modelos,
17
documentos, datos, reportes, formatos, etc.), se establecen puntos de referencia, se asegura
la calidad y se administra el cambio de manera apropiada (Pressman, 2010).
Los métodos de la ingeniería de software proporcionan la experiencia técnica para elaborar

software. Incluyen un conjunto amplio de tareas, como comunicación, análisis de los
requerimientos, modelación del diseño, construcción del programa, pruebas y apoyo. Los
métodos de la ingeniería de software se basan en un conjunto de principios fundamentales
que gobiernan cada área de la tecnología e incluyen actividades de modelación y otras
técnicas descriptivas (Pressman, 2010).
Las herramientas de la ingeniería de software proporcionan un apoyo automatizado o

semiautomatizado para el proceso y los métodos. Cuando se integran las herramientas de
modo que la información creada por una pueda ser utilizada por otra, queda establecido un
sistema llamado ingeniería de software asistido por computadora que apoya el desarrollo de
software (Pressman, 2010).
2.1.1. EL PROCESO DEL SOFTWARE
Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a

crearse algún producto del trabajo. Una actividad busca lograr un objetivo amplio (por
ejemplo, comunicación con los participantes) y se desarrolla sin importar el dominio de la
aplicación, tamaño del proyecto, complejidad del esfuerzo o grado de rigor con el que se
usará la ingeniería de software. Una acción (diseño de la arquitectura) es un conjunto de
tareas que producen un producto importante del trabajo (por ejemplo, un modelo del diseño
de la arquitectura). Una tarea se centra en un objetivo pequeño pero bien definido (por
ejemplo, realizar una prueba unitaria) que produce un resultado tangible (Pressman, 2010).
En el contexto de la ingeniería de software, un proceso no es una prescripción rígida de cómo

elaborar software de cómputo. Por el contrario, es un enfoque adaptable que permite que las
personas que hacen el trabajo (el equipo de software) busquen y elijan el conjunto apropiado
de acciones y tareas para el trabajo. Se busca siempre entregar el software en forma oportuna
y con calidad suficiente para satisfacer a quienes patrocinaron su creación y a aquellos que
18
lo usarán (Pressman, 2010).
La estructura del proceso establece el fundamento para el proceso completo de la ingeniería

de software por medio de la identificación de un número pequeño de actividades estructurales
que sean aplicables a todos los proyectos de software, sin importar su tamaño o complejidad.
Además, la estructura del proceso incluye un conjunto de actividades sombrilla que son
aplicables a través de todo el proceso del software. Una estructura de proceso general para la
ingeniería de software consta de cinco actividades: (Pressman, 2010).
Comunicación. Antes de que comience cualquier trabajo técnico, tiene importancia crítica
comunicarse y colaborar con el cliente (y con otros participantes). Se busca entender los
objetivos de los participantes respecto del proyecto, y reunir los requerimientos que ayuden
a definir las características y funciones del software (Pressman, 2010).
Planeación. Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto de

software es un viaje difícil, y la actividad de planeación crea un “mapa” que guía al equipo
mientras viaja. El mapa —llamado plan del proyecto de software— define el trabajo de
ingeniería de software al describir las tareas técnicas por realizar, los riesgos probables, los
recursos que se requieren, los productos del trabajo que se obtendrán y una programación de
las actividades (Pressman, 2010).
Modelado. Ya sea usted diseñador de paisaje, constructor de puentes, ingeniero aeronáutico,

carpintero o arquitecto, a diario trabaja con modelos. Crea un “bosquejo” del objeto por hacer
a fin de entender el panorama general —cómo se verá arquitectónicamente, cómo ajustan
entre sí las partes constituyentes y muchas características más—. Si se requiere, re- fina el
bosquejo con más y más detalles en un esfuerzo por comprender mejor el problema y cómo
resolverlo. Un ingeniero de software hace lo mismo al crear modelos a fin de entender mejor
los requerimientos del software y el diseño que los satisfará (Pressman, 2010).
Construcción. Esta actividad combina la generación de código (ya sea manual o auto-
matizada) y las pruebas que se requieren para descubrir errores en éste (Pressman, 2010).
Despliegue. El software (como entidad completa o como un incremento parcialmente
19
terminado) se entrega al consumidor que lo evalúa y que le da retroalimentación, misma que
se basa en dicha evaluación (Pressman, 2010).
Estas cinco actividades estructurales genéricas se usan durante el desarrollo de programas

pequeños y sencillos, en la creación de aplicaciones web grandes y en la ingeniería de
sistemas enormes y complejos basados en computadoras. Los detalles del proceso de
software serán distintos en cada caso, pero las actividades estructurales son las mismas
(Pressman, 2010).
Para muchos proyectos de software, las actividades estructurales se aplican en forma iterativa
a medida que avanza el proyecto. Es decir, la comunicación, la planeación, el modelado, la
construcción y el despliegue se ejecutan a través de cierto número de repeticiones del
proyecto. Cada iteración produce un incremento del software que da a los participantes un
subconjunto de características y funcionalidad generales del software. Conforme se produce
cada incremento, el software se hace más y más completo (Pressman, 2010).
2.1.1.1. MODELOS DEL PROCESO DEL SOFTWARE
Modelo de la Cascada
El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque

sistemático y secuencial para el desarrollo del software, que comienza con la especificación
de los requerimientos por parte del cliente y avanza a través de planeación, modelado,
construcción y despliegue, para concluir con el apoyo del software terminado(Pressman,
2010).
Modelos de proceso incremental
El modelo incremental combina elementos de los flujos de proceso lineal y paralelo

estudiados. El modelo incremental aplica secuencias lineales en forma escalonada a medida
que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de
software susceptibles de entregarse de manera parecida a los incrementos producidos en un
flujo de proceso evolutivo (Pressman, 2010).
20
El Modelo Espiral
El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el

riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas
intensivos en software. Tiene dos características distintivas principales. La primera es el
enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su
implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos
de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones
factibles y mutuamente satisfactorias (Pressman, 2010).
Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas
evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo o
prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del
sistema cuya ingeniería se está haciendo (Pressman, 2010).
2.1.2. DESARROLLO AGIL
En la ingeniería de software es vital definir los caminos a seguir para conseguir el éxito. Y
para esto existen diferentes metodologías para aplicar de acuerdo con el proyecto que se
desarrolle (Muriel, 2012).
Existen dos grandes familias de metodologías, éstas son:
 Metodologías ágiles
 Metodologías tradicionales.
Entonces, podemos aplicar una metodología diferente para cada proyecto, la problemática es
definir cuál usar (Muriel, 2012).
Es importante tener en cuenta que el uso de un método ágil no se aplica para todos los
proyectos. Sin embargo, una de las principales ventajas de los métodos ágiles es su peso
inicialmente ligero y por eso las personas que no están acostumbradas a seguir procesos
encuentran estas metodologías bastante agradables (Muriel, 2012).
A continuación he definido esquemáticamente las principales diferencias de las metodologías
21
ágiles ("ligeras") con respecto a las tradicionales ("pesadas") (Muriel, 2012).
Metodologías Ágiles Metodologías Tradicionales
Basadas en heurísticas Basadas en normas provenientes

provenientes de prácticas de de estándares seguidos por el
producción de código. entorno de desarrollo.
Especialmente preparadas Cierta resistencia a los cambios.

para cambios durante el
proyecto.
Impuestas internamente (por Impuestas externamente.

el equipo).
Proceso menos controlado, Proceso mucho más controlado,

con pocos principios. con numerosas políticas/normas.
No existe contrato tradicional Existe un contrato prefijado.

o al menos es bastante
flexible.
El cliente es parte del equipo El cliente interactúa con el equipo

de desarrollo. de desarrollo mediante reuniones.
Grupos pequeños (se Grupos grandes y posiblemente

recomienda <10 integrantes) y distribuidos.
trabajando en el mismo sitio.
Pocos artefactos. Más artefactos.
Pocos roles. Más roles.
22
Menos énfasis en la La arquitectura del software es
arquitectura del software. Se esencial y se expresa mediante
va definiendo en el desarrollo. modelos desde el principio.
Tabla 2.1 Tabla metodologías agiles vs tradicionales

Fuente: (Muriel, 2012)
2.1.2.1. EL MANIFIESTO ÁGIL
Un Grupo de 17 expertos se reunieron en el año 2011, para plantear las bases de las
metodologías Agiles. Definiendo un conjunto de principios sobre cómo enfocar el desarrollo
de una manera más ágil en contraposición con el modelo en cascada, que fue considerado el
más rápido y con mayor dependencia normativa, de la documentación y la planificación. Este
grupo de personas promulgo unos valores sobre una nueva manera de gestionar y realizar los
proyectos de desarrollo.
A continuación se detallara los 12 principios:
Principios del manifiesto ágil
La principal prioridad es satisfacer al cliente a través de la entrega

temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías

del desarrollo. Los procesos ágiles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos

semanas y dos meses, con preferencia al período de tiempo más
corto posible.
Los responsables del negocio y los desarrolladores trabajamos

juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay
23
que darles el entorno y el apoyo que necesitan, y confiarles la
ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al

equipo de desarrollo y entre sus miembros es la conversación cara
a cara.
El software funcionando es la medida principal de progreso.
Los procesos ágiles promueven el desarrollo sostenido. Los

promotores, desarrolladores y usuarios debemos mantener un
ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño

mejora la agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no

realizado, son esencial.
Las mejores arquitecturas, requisitos y diseños emergen de

equipos auto-organizados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más

efectivo para, a continuación, ajustar y perfeccionar su
comportamiento en consecuencia.
Tabla 2.2 Principios del manifiesto Ágil

Fuente: (Wikipedia, 2016)
2.2. METODOLOGÍA ÁGIL DE DESARROLLO: OPEN UP
Existen diversos modelos para el proceso de desarrollo de software, cada uno con sus
diferentes enfoques y características. En este caso hablaremos acerca de Open Up (Unified
Process), este modelo tiene su origen junto con Rational Unified Process (RUP) de IBM, era
la versión genérica y de dominio público de esta, llamada entonces Basic Unified Process y
fue donada a la fundación Eclipse Process Framework en 2005 y renombrada como Open Up
24
en 2006. Este modelo es iterativo e incremental y contiene solo los componentes básicos de
un proyecto (OpenUp, 2014).
Open Up Es un modelo de proceso que aplica enfoques interactivos e incrementales dentro

de un ciclo de vida estructurado, apropiado para proyectos pequeños y de bajos recursos
aplicable a un conjunto amplio de plataformas y aplicaciones de desarrollo (OpenUp, 2014).
Open UP es un proceso mínimo y suficiente, lo que significa que solo el contenido

fundamental y necesario es incluido. Por lo tanto no provee lineamientos para todos los
elementos que se manejan en un proyecto pero tiene los componentes básicos que pueden
servir de base a procesos específicos. La mayoría de los elementos de Open UP están
declarados para fomentar el intercambio de información entre los equipos de desarrollo y
mantener un entendimiento compartido del proyecto, sus objetivos, alcance y avances
(OpenUp, 2014).
Su proceso puede ser personalizado y extendido para distintas necesidades que se presenten,
que aparecen a lo largo del ciclo de vida del desarrollo de software, dado que su modelo de
desarrollo es incremental iterativo es capaz de producir distintas versiones, además, una de
sus mayores ventajas es que puede ser fácilmente acoplado para proyectos pequeños
(OpenUp, 2014).
Figura 2.2 El proceso de desarrollo Open Up

Fuente: (OpenUp, 2014)
25
2.2.1. ROLES
Los roles de Open Up representan a las labores y habilidades necesarias de un equipo, las
cuales se describen a continuación.
Representa al cliente y el usuario final, se refiere a la

obtención de requerimientos de los interesados, por medio
de comprender el problema a resolver capturando y
ANALISTA
creando las prioridades de los requerimientos.
Es el responsable del diseño de arquitectura de software,

tomando las decisiones técnicas claves, las cuales
limitaran el conjunto de diseño y la implementación del
ARQUITECTO
proyecto.
Es el que tiene la responsabilidad del desarrollo de una

parte del sistema o el sistema completo dependiendo de la
magnitud del mismo, se encarga del diseño ajustándolo a
la arquitectura y de la implementación de pruebas
DESARROLLADOR
unitarias y de integración para los componentes.
Dirige la planificación del proyecto en colaboración con
LÍDER DE las partes interesadas y el equipo, coordina las
PROYECTO interacciones de los interesados, manteniendo al equipo

del proyecto enfocado en los objetivos del mismo.
Representan al grupo que está interesado en el proyecto,

cuyas necesidades deberán ser satisfechas por el proyecto
en curso. Este papel lo puede jugar cualquier persona que
puede ser materialmente afectada por los objetivos del
STAKEHOLDERS proyecto.
26
Es el responsable de las actividades básicas y de realizar
las pruebas, se encarga de la identificación, definición,
implementación y conducción de las pruebas necesarias.
TESTER
Así como el ingreso de pruebas y el análisis de resultados.
Tabla 2.3 Descripción de Roles de equipo de trabajo Open Up

2.2.2. CARACTERÍSTICAS DE OPEN UP
Las características fundamentales de open up son las siguientes:
Características de Open Up
Iterativo e Incremental
Basado en casos de uso
Gerencia de requerimientos
Centrado en la arquitectura
Proceso configurable
Modelo visual
Basado en componentes
Tabla 2.4 Características de Open Up

2.2.3. PRINCIPIOS DE OPEN UP
Los principios básicos de la metodología open up son los siguientes:
Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve

prácticas que impulsan un ambiente de equipo saludable, facilitan la colaboración y
desarrollan un conocimiento compartido del proyecto (OpenUp, 2014).
27
Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el
proyecto. Este principio promueve prácticas que permiten a los participantes de los proyectos
desarrollar una solución que maximice los beneficios obtenidos por los participantes y que
cumple con los requisitos y restricciones del proyecto (OpenUp, 2014).
Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el

desarrollo (OpenUp, 2014).
Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo. Este principio

promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación
temprana y continua de los participantes del proyecto, permitiendo demostrarles incrementos
progresivos en la funcionalidad a los clientes (OpenUp, 2014).
2.2.4. CICLO DE VIDA DE OPEN UP
La estructura del ciclo de vida del proyecto se divide en cuatro fases: Inicio, Elaboración,
Construcción y Transición. El ciclo de vida del proyecto proporciona las partes interesadas
y los miembros del equipo con la visibilidad y la toma puntos a lo largo del proyecto. Esto
permite una supervisión efectiva, y le permite hacer las decisiones en los momentos
oportunos. Un plan de proyecto define el ciclo de vida, y el resultado final es una aplicación
en libertad (OpenUp, 2014).
El ciclo de vida del proyecto proporciona stakeholders con gestión, transparencia y

mecanismos de dirección para la financiación del control del proyecto, alcance, exposición
de riesgos, valores dados y otros aspectos del proceso (OpenUp, 2014).
Cada iteración entrega un incremento del producto, que da una oportunidad para que los
stakeholders comprendan que valores se han dado y que tan buen camino lleva el proyecto.
Esto también da al equipo de desarrollo la oportunidad de hacer cambios al proyecto para
optimizar el resultado (OpenUp, 2014).
Uno de los objetivos del ciclo de vida del proyecto es enfocarse en dos propósitos
principales de los stakeholders: reducción de riesgos y creación de valores o producto
(OpenUp, 2014).
28
Figura 2.3 Ciclo de vida de Open Up
2.2.5. FASES Y ACTIVIDADES DE OPEN UP
Open Up consta de cuatro fases las cuales son: fase de inicio, fase de elaboración, fase de
construcción y la fase de transición, Open Up también cuenta con seis actividades estas son:
identificar los requerimientos, arquitectura, análisis, diseño, implementación y pruebas, estas
actividades se implementan juntamente con las fases, de manera que las tareas se encuentren
organizadas, cada disciplina se incluye con las tareas y cada tarea se relaciona con otros
elementos y definiciones de las actividades.
Fases Actividades Definición
Identificar los Esta actividad define el inicio del proyecto, la
Inicio requerimientos. identificación de interesados, la descripción de

posibles soluciones y la visión general del sistema.
Esta actividad crea una arquitectura sólida de
Arquitectura elementos tecnológicos para el sistema.
Análisis Esta actividad analiza los requerimientos

arquitectónicos.
29
Elaboración Esta actividad adapta el diseño para que coincida
Diseño con el entorno de implementación.
Esta actividad explica cómo implementar una
Construcción Implementación solución técnica que se ajusta en el proyecto de los

trabajos dentro de la arquitectura y es compatible
con los requisitos.
Esta actividad es la especificación de un conjunto

de pruebas de entrada, condiciones de ejecución y
resultados esperados, identificados con la finalidad
Transición Pruebas
de obtener una evaluación de algún aspecto
particular de un escenario.
Tabla 2.5 Actividades de acuerdo a las fases de Open Up

2.3. INGENIERÍA WEB
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas y

cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad
en la World Wide Web (IWeb, 2010).
La ingeniería web se debe al crecimiento desenfrenado que está teniendo la Web está
ocasionando un impacto en la sociedad y el nuevo manejo que se le está dando a la
información en las diferentes áreas en que se presenta ha hecho que las personas tiendan a
realizar todas sus actividades por esta vía (IWeb, 2010).
Desde que esto empezó a suceder el Internet se volvió más que una diversión y empezó a ser
tomado más en serio, ya que el aumento de publicaciones y de informaciones hizo que la
Web se volviera como un desafío para los (Ingeniería del software) ingenieros del software,
a raíz de esto se crearon enfoques disciplinados, sistemáticos y metodologías donde tuvieron
en cuenta aspectos específicos de este nuevo medio (IWeb, 2010).
30
Uno de los aspectos más tenidos en cuenta, en el desarrollo de sitios web es sin duda alguna
el diseño gráfico y la organización estructural del contenido. En la actualidad la web está
sufriendo grandes cambios, que han obligado a expertos en el tema a utilizar herramientas y
técnicas basadas en la ingeniería del software, para poder garantizar el buen funcionamiento
y administración de los sitios web (IWeb, 2010).
Para tener artefactos de calidad, a esa misma se le debe planificar, programar y controlar, es
decir la calidad no podrá ser agregada a un artefacto web o a cualquier otro producto, al final
del proceso de desarrollo, si no que se deberá implementar durante todo el ciclo de vida del
desarrollo. Para finalizar el resultado de un proceso de calidad, podría arrojar
recomendaciones para introducir mejoras, y la decisión final podría consistir en lanzar una
nueva versión del sitio web o en modificar algunos atributos ausentes o pobremente
diseñados (IWeb, 2010).
Cabe destacar que la ingeniería de la web hace una diferencia entre un sitio web y un
aplicativo, ya que la ingeniería de la web no se dedica a la construcción de sitios web si no a
la construcción de aplicativos web, la principal característica que los distingue (aplicativos
de sitios web) es que los sitios web son sitios en la web en donde se publica contenido
generalmente estático o un muy bajo nivel de interactividad con el usuario, mientras que los
aplicativos son lugares con alto contenido de interactividad y funcionalidades que bien
podrían ser de un software convencional, el aplicativo web más sencillo seria uno que
contenga formularios y subiendo de nivel encontramos los que realizas conexión con bases
de datos remotas, y administradores de contenidos entre otras (IWeb, 2010).
Entonces la ingeniería de la Web es la aplicación de metodologías sistemáticas, disciplinadas

y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones de alta calidad
en la World Wide Web. En este sentido, la ingeniería de la Web hace referencia a las
metodologías, técnicas y herramientas que se utilizan en el desarrollo de aplicaciones Web
complejas y de gran dimensión en las que se apoya la evaluación, diseño, desarrollo,
implementación y evolución de dichas aplicaciones (IWeb, 2010).
31
2.4. METODOLOGÍA PARA EL DESARROLLO WEB: UWE
UWE es un proceso del desarrollo para aplicaciones Web enfocado sobre el diseño
sistemático, la personalización y la generación semiautomática de escenarios que guíen el
proceso de desarrollo de una aplicación Web. UWE describe una metodología de diseño
sistemática, basada en las técnicas de UML, la notación de UML y los mecanismos de
extensión de UML (UWE, 2015).
Es una herramienta que nos permitirá modelar aplicaciones web, utilizada en la ingeniería
web, prestando especial atención en sistematización y personalización (sistemas
adaptativos). UWE es una propuesta basada en el proceso unificado y UML pero adaptados
a la web (UWE, 2015).
En el marco de UWE es necesario la definición de un perfil UML (extensión) basado en

estereotipos con este perfil se logra la asociación de una semántica distinta a los diagramas
del UML puro, con el propósito de acoplar el UML a un dominio específico, en este caso, las
aplicaciones Web (UWE, 2015).
UWE está especializada en la especificación de aplicaciones adaptativas, y por tanto hace

especial hincapié en características de personalización, como es la definición de un modelo
de usuario o una etapa de definición de características adaptativas de la navegación en
función de las preferencias, conocimiento o tareas de usuario (UWE, 2015).
2.4.1. FASES DE UWE
UWE cubre todo el ciclo de vida de este tipo de aplicaciones centrando además su atención
en aplicaciones personalizadas o adaptativas (UWE, 2015).
 Captura, análisis y especificación de requisitos: Durante esta fase, se adquieren, reúnen y

especifican las características funcionales y no funcionales que deberá cumplir la aplicación
web (UWE, 2015).
Trata de diferente forma las necesidades de información, las necesidades de navegación, las
necesidades de adaptación y las de interfaz de usuario, así como algunos requisitos
32
adicionales. Centra el trabajo en el estudio de los casos de uso, la generación de los glosarios
y el prototipado de la interfaz de usuario (UWE, 2015).
 Diseño del sistema: Se basa en la especificación de requisitos producido por el análisis de
los requerimientos (fase de análisis), el diseño define cómo estos requisitos se cumplirán, la
estructura que debe darse a la aplicación web (UWE, 2015).
 Codificación del software: Durante esta etapa se realizan las tareas que comúnmente se
conocen como programación; que consiste en llevar a código fuente, en el lenguaje de
programación elegido, todo lo diseñado en la fase anterior (UWE, 2015).
 Pruebas: Se utilizan para asegurar el correcto funcionamiento de secciones de código (UWE,
2015).
 La Instalación o Fase de Implementación: Proceso por el cual los programas desarrollados
son transferidos apropiadamente al computador destino, inicializados, y, eventualmente
configurados; con el propósito de ser utilizados por el usuario final. Esto incluye la
implementación de la arquitectura, de la estructura del hiperespacio, del modelo de usuario,
de la interfaz de usuario, de los mecanismos adaptativos y las tareas referentes a la integración
de todas estas implementaciones (UWE, 2015).
Mantenimiento: Es el proceso de control, mejora y optimización del software ya

desarrollado e instalado, que también incluye depuración de errores y defectos que puedan
haberse filtrado de la fase de pruebas de control (UWE, 2015).
Figura 2.4 Fases de UWE

Fuente: (UWE, 2015)
33
2.4.2. ACTIVIDADES DE MODELADO DE UWE
UWE es una metodología que permite especificar de mejor manera una aplicación Web en
su proceso de creación mantiene una notación estándar basada en el uso de UML (Unified
Modeling Language) para sus modelos y sus métodos, lo que facilita la transición (Ucán,
2014).
UWE provee diferentes modelos que permite describir una aplicación Web desde varios
puntos de vista abstractos, dichos modelos están relacionados. Cada uno de estos modelos se
representa como paquetes UML, dichos paquetes son procesos relacionados que pueden ser
refinados en iteraciones sucesivas durante el desarrollo del UWE (Ucán, 2014).
Figura 2.5 Modelos de UWE

Fuente: (Ucán, 2014)
2.4.2.1. ANÁLISIS DE REQUISITOS
Una de las primeras actividades en la construcción de aplicaciones Web es la identificación

de los requisitos, y en UWE se especifican mediante el modelo de requerimientos, que
involucra el modelado de casos de uso con UML (Ucán, 2014).
DIAGRAMA DE CASOS DE USO
El diagrama de casos de uso está conformado por los elementos actor y caso de uso. Los
actores se utilizan para modelar los usuarios de la aplicación Web que para este caso de
34
estudio son los diferentes tipos de usuarios (anónimo, consultor, tutor, alumno) que pueden
interactuar con el mismo (Ucán, 2014).
Los casos de uso se utilizan para visualizar las diferentes funcionalidades que la aplicación
tiene que proporcionar, como son: crear a un nuevo usuario, identificar al usuario, realizar
una búsqueda, realizar la composición de un nuevo objeto y guardar el objeto compuesto
(Ucán, 2014).
En la figura 2.6 se ilustra el diagrama de casos de usos para la aplicación web. Es de

mencionar que para cada etapa del modelado, UWE provee diferentes estereotipos (Ucán,
2014).
Figura 2.6 Diagrama de casos de uso

El caso de uso "Realizar Búsqueda" es del estereotipo explorar («browsing»). Modela la

búsqueda de los objetos de aprendizaje por medio de las características de los objetos y de
los usuarios para que el sistema pueda proporcionar una recomendación personalizada (Ucán,
2014).
35
2.4.2.2. MODELO DE CONTENIDO
El objetivo del modelo de contenido es proporcionar una especificación visual de la

información en el dominio relevante para la aplicación Web (Ucán, 2014).
Este es un diagrama UML normal de clases, por ello se debe pensar en las clases que son
necesarias para el caso de estudio presentado (Ucán, 2014).
En la figura 2.7 se presenta el diagrama de clases para el modelo de contenido. En particular,

la información de los usuarios es modelada por la clase "Perfil Usuario" donde se almacenan
las propiedades que describen a los diferentes tipos de usuarios (Ucán, 2014).
Figura 2.7 Modelo de contenido

2.4.2.3. ESTRUCTURA DE NAVEGACIÓN
En una aplicación para la Web es útil saber cómo están enlazadas las páginas. Ello significa
que se requiere un diagrama de navegación con nodos y enlaces. Este diagrama se modela
con base en el análisis de los requisitos y el modelo de contenido (Ucán, 2014).
36
UWE provee diferentes estereotipos para el modelado de navegación, en la figura 5 se
presentan los usados en este caso de estudio y seguidamente se da una descripción de cada
uno de ellos (Ucán, 2014).
Figura 2.8 Estereotipos de estructura de navegación

Las clases de navegación («navigationClass») representan nodos navegables de la estructura

de hipertexto; los enlaces de navegación («navigationLink») muestran vínculos directos entre
las clases de navegación; las rutas alternativas de navegación son manejadas por menú
(«menu»). Los accesos se utilizan para llegar a múltiples instancias de una clase de
navegación («index» o «guidedTour») o para seleccionar los elementos («query»). Las clases
de procesos («processClass») forman los puntos de entrada y salida de los procesos de
negocio en este modelado y la vinculación entre sí y a las clases de navegación se modela
por enlaces de procesos («processLink») (Ucán, 2014).
En la figura 5, las clases de navegación "Inicio y Perfil Usuario" representan nodos

navegables de la estructura de hipertexto y se consideran relevantes para la navegación. Los
enlaces de navegación "navigation Link" y "process Link" muestran vínculos directos entre
las clases de navegación y representan posibles pasos a seguir por el usuario y, por lo tanto,
estos vínculos tienen que ser dirigidos (Ucán, 2014).
37
Figura 2.9 Clases de navegación
2.4.2.4. MODELO DE PRESENTACIÓN
El modelo de presentación ofrece una visión abstracta de la interfaz de usuario de una

aplicación Web. Se basa en el modelo de navegación y en los aspectos concretos de la interfaz
de usuario (IU). Describe la estructura básica de la IU, es decir, ¿qué elementos de interfaz
de usuario (por ejemplo, texto, imágenes, enlaces, formularios) se utilizan para presentar los
nodos de navegación? Su ventaja es que es independiente de las técnicas actuales que se
utilizan para implementar un sitio Web, lo que permite a las partes interesadas discutir la
conveniencia de la presentación antes de que realmente se aplique (Ucán, 2014).
Una clase de presentación está compuesta de elementos de IU como texto («text»), enlaces
(«anchor»), botones («button»), imágenes («image»), formularios («form») y colecciones de
enlaces («anchored collection»). La figura 2.7 muestra un ejemplo de la clase de presentación
para la clase de navegación Inicio (Ucán, 2014).
38
En la figura 2.10 se modela la página de presentación "PaginaInicio". Existe una
representación de texto para el encabezado y un mensaje de presentación. Modela también
un formulario de entrada para que el usuario introduzca clave y contraseña, así como los
botones de "iniciarperfil" y "registrarPErfil" (Ucán, 2014).
Figura 2.10 Página de presentación

2.5. HERRAMIENTAS DE DESARROLLO DE SOFTWARE
2.5.1. FRAMEWORK LARAVEL
Laravel es un framework de código abierto para desarrollar aplicaciones y servicios web con
PHP 5. Su filosofía es desarrollar código PHP de forma elegante y simple.
Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis elegante y
expresiva para crear código de forma sencilla y permitiendo multitud de funcionalidades.
Intenta aprovechar lo mejor de otros frameworks y aprovechar las características de las
últimas versiones de PHP.
39
Gran parte de Laravel está formado por dependencias, especialmente de Symfony, esto
implica que el desarrollo de Laravel dependa también del desarrollo de sus dependencias.
2.5.2. FRAMEWORK BOOTSTRAP
Es un framework o conjunto de herramientas de Código abierto para diseño de sitios y

aplicaciones web. Contiene plantillas de diseño con tipografía, formularios, botones, cuadros,
menús de navegación y otros elementos de diseño basado en HTML y CSS, así como,
extensiones de JavaScript opcionales adicionales.
2.5.3. SISTEMA GESTOR DE BASE DE DATOS MYSQL
MySQL es un sistema de gestión de bases de datos relacional desarrollado bajo licencia dual
GPL/Licencia comercial por Oracle Corporation y está considerada como la base datos open
source más popular del mundo, y una de las más populares en general junto a Oracle y
Microsoft SQL Server, sobre todo para entornos de desarrollo web.
MySQL es un sistema de administración relacional de bases de datos. Una base de datos

relacional archiva datos en tablas separadas en vez de colocar todos los datos en un gran
archivo. Esto permite velocidad y flexibilidad. Las tablas están conectadas por relaciones
definidas que hacen posible combinar datos de diferentes tablas sobre pedido.
40
CAPÍTULO 3
MARCO APLICATIVO
3.1. INTRODUCCIÓN
El objetivo del siguiente capítulo es el de aplicar todo lo referente a los fundamentos

técnicos, dando a desglosar la metodología Open Up y todos los pasos que implican para
llevar a cabo el proceso de desarrollo de software, a la par se hará el uso de UWE (UML-
Based Web Engineering) que nos permite modelar aplicaciones web.
Open Up
UWE
Fases Artefactos
Inicio del proyecto No aplica
Inicio Administración y planeación Prototipo
Casos de uso críticos No aplica
Arquitectura Entorno de desarrollo
Análisis de
Requerimientos
requerimientos
Elaboración Modelo de contenido

Análisis y diseño Modelo de navegación
Modelo de presentación
Herramientas No aplica
Implementación No aplica
Construcción
Resultado de lo obtenido No aplica
41
Calidad de lo desarrollado No aplica
Pruebas del sistema No aplica
Transición Validar construcción No aplica
Gestión de proyectos No aplica
Tabla 3.1 Relación fases Open Up y herramientas UWE

3.2. FASE DE INICIO
A continuación se realiza el identificado de los interesados (usuarios) y su relación con el

sistema a implementar además de describir de manera general sobre el funcionamiento del
mismo aplicando la metodología anteriormente mencionada.
3.2.1. IDENTIFICACIÓN DE LOS INTERESADOS
Los interesados o Stakeholders (denominados roles en Open Up) es preponderante, ya que

de esta manera se podrá detallar la descripción y las responsabilidades de cada uno de ellos,
a continuación se detalla la identificación de los interesados en la siguiente tabla:
Nombre Responsabilidades Descripción
Le interesa ver sobre el avance de

Sub-Alcalde las distintas obras en ejecución Son los miembros
mediante reportes del directorio, los

cuales
Oficial
Es el encargado de Registrar y interactuarán con
mayor
publicar posibles Obras a ejecutarse. el sistema
técnico
42
Tarea en la cual consiste en verificar
Supervisor
sobre el avance y motivo de retraso
de Obras
de las obras.
Usuaria que registras las solicitudes

Secretaria
de obras de las distintas poblaciones
Personas que
Personas que coadyuvaran con el
retroalimentan al sistema
Dirigentes control de obras, dando a conocer
sobre las observaciones y
observaciones de las mismas.
retrasos.
Tabla 3.2 Descripción de los interesados

3.2.2. DESCRIPCIÓN DE LA POSIBLE SOLUCIÓN
Luego de la identificación de los interesados, se procede a la descripción de la posible

solución, que es un resumen acerca de los problemas que tiene la directiva.
A continuación se muestra la tabla con los problemas a resolver involucrando al Sub-Alcalde:
Para Sub-Alcalde
Es parte de la directiva, al que le interesa

Quien
más los reportes de avance de obras.
Sistema Web de Control y Seguimiento

El
de Obras Municipales.
Que Ver el avance de obras.
43
Administrará todas las obras a ejecutarse
Nuestro Producto
durante un POA.
Tabla 3.3 Problemas relacionados al Sub-Alcalde

A continuación se muestra la tabla con los problemas a resolver involucrando al Oficial

Mayor Técnico:
Para Oficial Mayor Técnico
Es parte de la directiva del grupo, el

Quien encargado de registrar las posibles obras
a ejecutarse.

El
Que Elaborar las posibles obras modelo.
Registrará las posibles obras a

Nuestro Producto
ejecutarse.
Tabla 3.4 Problemas relacionados al Oficial Mayor Técnico

A continuación se muestra la tabla con los problemas a resolver involucrando al Supervisor

de Obras:
Para Supervisor de obras
Es parte de la directiva del grupo,

Quien
verifica el avance de las obras.
44
El
Se encargará de realizar un control

Que
adecuado a las obras en ejecución.
Registrará el avance de todas las obras

Nuestro Producto
en ejecución.
Tabla 3.5 Problemas relacionados al Supervisor de Obras

A continuación se muestra la tabla con los problemas a resolver involucrando a la Secretaria:
Para Secretaria
Es parte de la directiva del grupo,

Quien
registrar las solicitudes de obras.

El
Se encargará de registrar las solicitudes

Que
de obras de las poblaciones aledañas.
Registrará todas las peticiones de obras

Nuestro Producto para poder elevar a una evaluación y su
posterior aprobación.
Tabla 3.6 Problemas relacionados a la Secretaria

A continuación se muestra la tabla 3.7 con los problemas a resolver involucrando a los
Dirigentes:
45
Para Dirigentes
Es parte de la directiva de la población,

Quien
que coadyuva con el control.

El
Se encargará de verificar la correcta

Que
ejecución de la obras.
Registrará todas las observaciones y

Nuestro Producto
retrasos de las obras.
Tabla 3.7 Problemas relacionados a los Dirigentes

3.2.3. VISIÓN GENERAL DEL SISTEMA
La visión general del sistema abarca las características que tendrá el sistema web además de
considerar necesidades de la directiva y describe las posibles soluciones que propone el
proyecto a desarrollar.
Necesidad Registro de proyectos modelo
Prioridad Alta
La elaboración de proyectos modelo se lleva a

cabo antes de que las poblaciones puedan
Características solicitar obras, debido a las distancias no se
tiene la información a la mano para poder hacer
la solicitud de una obra.
46
Se realiza el registro de los modelos de
proyectos, para posteriormente publicarlos en la
Solución sugerida página de la Alcaldía de tal manera que los
dirigentes ya puedan elegir entre los proyectos
modelo para su comunidad.
Tabla 3.8 Solución propuesta al registro de proyectos modelos

Se muestra a continuación la solución propuesta al registro de solicitudes de obras:
Necesidad Registro de solicitudes de obras
Prioridad Alta
El registro de solicitudes de obras es la

parte en que la secretaria hace la
recepción las solicitudes de obras, de
Características
manera documentada los cuales
llegaban a perderse de la misma
secretaria.
Se realiza el desarrollo del módulo de

registro de solicitudes para tener a la
Solución sugerida mano toda la información de las mismas
y posteriormente poder aprobar o
desaprobar dichas obras.
Tabla 3.9 Solución propuesta al registro de solicitudes de obras

Se muestra a continuación la solución propuesta a la publicación de obras aprobadas:
47
Necesidad Publicación de obras
Prioridad Media
La publicación de obras aprobadas se la

realiza en un tablero de la alcaldía, lo
Características
que no permite una rápida información
a las comunidades interesadas.
Se realiza la publicación de las obras

aprobadas y desaprobadas en la página
Solución sugerida
de la alcaldía para una brindar
información eficaz a las comunidades.
Tabla 3.10 Solución propuesta al registro de solicitudes de obras

Luego de realizar la solución propuesta a la publicación de obras se procede al siguiente paso

que se muestra en la tabla descrita a continuación:
Necesidad Seguimiento de obras
Prioridad Media
Los informes que realiza sobre las obras

el supervisor de obras le lleva tiempo y
Características gasto de papelería, el cual dificulta la
organización de los reportes para el
correcto seguimiento de las obras.
Se realiza la implementación de un
Solución sugerida
módulo de registro de seguimiento de
48
obras además de ofrecer reportes de
avance de las mismas.
Tabla 3.11 Solución propuesta al Seguimiento de obras

Se muestra la solución propuesta al control de obras en la tabla descrita a continuación:
Necesidad Control de obras
Prioridad Media
El control de obras por parte de los

dirigentes es muy tediosa ya que se tiene
que hacer presente en oficinas de la
Características
alcaldía para realizar el reclamo u
observación lo que conlleva tiempo para
el dirigente.
Se realiza un formulario de reclamos y

observaciones a la obras por parte de los
Solución sugerida
dirigentes a través de un cuenta en la
página de la alcaldía.
Tabla 3.12 Solución propuesta al control de obras

Luego de realizar la solución propuesta al control de obras se procede al siguiente
paso que se muestra en la tabla descrita a continuación:
Necesidad Generación de reportes
Prioridad Alta
49
Los distintos reportes que se realizan
para elevar informes toman tiempo al
Características
revisar la documentación realizada en
folders.
Se desarrolla un módulo de reporte

como: el listado de obras aprobadas,
Solución sugerida listado de obras desaprobadas, avance
de la obras, estado actual de las obras,
cancelación de obras, etc.
Tabla 3.13 Solución propuesta a la generación de reportes

Por último se procede al siguiente paso que se muestra en la tabla descrita a continuación:
Necesidad Administración del sistema
Prioridad Media
El sistema debe contar con un acceso,

Características administración y
seguridad
Se realiza la implementación de un
módulo de administración del sistema,
Solución sugerida
que cuente con un inicio de sesión para
el personal, y la seguridad del sistema.
Tabla 3.14 Solución propuesta a la administración del sistema

50
3.3. FASE DE ELABORACIÓN
A continuación se aplica el modelado con UWE para el análisis de requisitos y la arquitectura

del sistema, además de tener el prototipo del sistema web propuesto.
3.3.1. ARQUITECTURA
La arquitectura del sistema se realiza previamente al análisis y diseño, se define como la

descripción del contenido del sistema, el proceso y los componentes a utilizar en su
desarrollo.
3.3.1.1. ARQUITECTURA DE LA APLICACIÓN
La arquitectura de la aplicación sigue el patrón MVC (Modelo–Vista-Controlador) de

Laravel
Figura 3.1 Arquitectura del sistema

Fuente: Laravel Book
Al realizar una petición (Request) mediante la vista, desde una interfaz, ésta es enrutada hacia
un controlador, vista o modelo dependiendo de cómo se la programe, generalmente es
51
apuntada hacia un controlador el cual procesa la petición para posteriormente pedir datos al
modelo el cual interactúa con la base de datos y devuelve los resultados al controlador para
que el controlador pueda mandar a la vista y esta lo muestre al usuario.
3.3.1.2. REQUERIMIENTOS TECNOLÓGICOS
Los requerimientos tecnológicos para el desarrollo e implementación del sistema se detallan

a continuación:
 Una computadora (personal o de escritorio), tablet o dispositivo móvil.

 Un servidor web o hosting (que contendrá la el gestor de base de datos MYSQL y el
sistema implementado con el framework Laravel).
 Acceso a Internet.
 Navegador Web, para la visualización del sistema.
3.3.2. ANÁLISIS
Etapa en la cual se realiza todo el modelado del sistema tomando los requerimientos de los
interesados y aplicando los diagramas UWE.
3.3.2.1. MODELO DE REQUERIMIENTOS
Los requerimientos fueron elaborados en consenso con los implicados con el sistema a
desarrollar. A continuación se muestran los resultados de los requerimientos detallados en
las siguientes tablas:
A continuación se presenta el modelo de requerimientos para el registro de proyectos

modelos:
Código de
Prioridad Descripción
requerimiento
Registro de proyectos
RPM-01 Alta
modelo
52
Modificación de
RPM-02 Alta
proyectos modelo
Baja de proyectos
RPM-03 Alta
modelo
Acceso a listado de
RPM-04 Media
proyectos modelo
Tabla 3.15 Requerimientos funcionales para la administración de proyectos modelo

Para el módulo de registro de solicitudes de obras:
Código de
requerimiento
Registro de solicitud
SO-01 Alta
de obras
Registro de datos de la
SO-02 Alta
comunidad solicitante
Registro del dirigente

SO-03 Alta
representante
Modificación de
SO-04 Media
solicitud de obras
53
Baja de solicitud de
SO-05 Media
obras
Tabla 3.16 Requerimientos funcionales para el registro obras solicitadas

Para el módulo de publicación de obras:
Código de
requerimiento
Publicación de obras
PO-01 Alta
aceptadas
Publicación de obras
PO-02 Alta
rechazadas
Búsqueda de obras y
PO-03 Baja su estado de
aceptación
Tabla 3.17 Requerimientos funcionales para la publicación de obras

Para el módulo de seguimiento de obras:
Código de
requerimiento
Registro de avance de
SEO-01 Alta
obras
54
Registro de retraso de
SEO-02 Alta
obras y motivos
Búsqueda de obras y
SEO-03 Baja
su estado de avance
Tabla 3.18 Requerimientos funcionales para el seguimiento de obras

Para el módulo de control de obras:
Código de
requerimiento
Registro de
CO-01 Alta observaciones a obras
en ejecución
Registro de
CO-02 Alta sugerencias a obras en
ejecución
Búsqueda de obras y su
CO-03 Baja
estado de avance
Tabla 3.19 Requerimientos funcionales para el control de obras

Para el módulo de reportes:
55
Código de
requerimiento
Reporte de Obras
REP-01 Alta
solicitadas
Reporte de Obras
REP-02 Alta
aprobadas
Reporte de obras
REP-03 Alta
rechazadas
Reporte de Obras y su
REP-04 Alta
respectivo avance
Reporte de Obras
REP-05 Alta
canceladas
Tabla 3.20 Requerimientos funcionales para la generación de reportes

3.3.2.2. CASOS DE USO
Permite graficar las actividades de los actores y sus relaciones sobre el sistema, describiendo
los pasos a seguir en cada proceso que interviene los respectivos actores, de tal forma que
se pueda interpretar de forma sencilla en la etapa de desarrollo del software.
a) CASOS DE USO PRINCIPAL
Se muestra a continuación el caso de uso principal definido con los módulos presentados
anteriormente:
56
Figura 3.2 Caso de uso general
b) CASOS DE USO SECUNDARIOS

De acuerdo a lo especificado en el caso de uso general se muestra los casos de uso
secundarios, que de acuerdo a las actividades que realizan los actores que intervienen en el
sistema.
REGISTRO DE PROYECTOS MODELO
A continuación se muestra el caso de uso para el registro de proyectos modelo.
57
Figura 3.3 Caso de uso de registro de proyectos modelo
SOLICITUD DE OBRAS
A continuación se muestra el caso de uso para la solicitud de obras por parte de los dirigentes
de comunidades. Aquí podremos ver como interactúa con el sistema el dirigente de las
comunidades
58
En la figura 3.4 se muestra la solicitud de obras
Figura 3.4 Caso de uso de solicitud de obras

PUBLICACIÓN DE OBRAS
A continuación se muestra el caso de uso para la publicación de obras. Aquí viremos como
el oficial mayor técnico y el supervisor de la obra interactúa con el sistema.
En la figura 3.5 se muestra la publicación de obras.
59
Figura 3.5 Caso de uso de publicación de obras
SEGUIMIENTO DE OBRAS
A continuación se muestra el caso de uso para el seguimiento de obras.
Figura 3.6 Caso de uso para el seguimiento de obras

60
CONTROL DE OBRAS
A continuación se muestra el caso de uso para el control de obras.
Figura 3.7 Caso de uso para el control de obras

3.3.2.3. IDENTIFICACIÓN DE ACTORES
La identificación de actores es primordial, ya que son los que interactúan con el sistema. A
continuación se detalla la descripción de los actores identificados:
Actores Definición
Interesado en la generación de los distintos

Sub-Alcalde
tipos de reportes.
Oficial Mayor Encargado de administrar los proyectos

Técnico modelos a ejecutarse.
Encargado de Supervisar y evaluar obras,

Supervisor de Obras además de darle el seguimiento
correspondiente.
61
Es la encargada de recibir y registrar las
Secretaria
posibles obras a ser ejecutadas.
Encargados de solicitar obras, además de

Dirigentes llevar a cabo el control de las obras en
ejecución.
Tabla 3.21 Identificación de los actores con el sistema

a) ESPECIFICACIONES DE CASOS DE USO
Las especificaciones de casos de uso proporcionan detalles textuales y detallados de un caso

de uso. A continuación se realiza la especificación de los casos de uso expuestos
anteriormente.
i) ESPECIFICACIÓN DE CASO DE USO (REGISTRO DE PROYECTOS MODELO)
Se muestra a continuación la especificación de caso de uso que corresponde al registro de

proyectos modelo:
Nombre Registro de Proyectos Modelo
Código A-01
Actor(es) Oficial Mayor Técnico y Supervisor de Obras
Precondición Autenticación
1. El actor inicia sesión.

2. Para el registro de proyectos modelo se llena el
formulario con los datos del proyecto modelo, presiona el
Escenario Básico
botón de “Guardar”, posteriormente se validan los datos
llenados en el formulario y se almacena en la base de
datos.
62
3. Para la modificación de datos de proyectos modelo,
accede al listado de proyectos modelo presiona el botón
de “Editar” lo cual devuelve el formulario con los datos
previamente guardados, se modifican los datos necesarios
y luego se presiona el botón de “Guardar”, esta acción
actualiza la información en la base de datos.
4. Para la eliminación de proyectos modelo, ingresa al
listado de proyectos modelo, oprime el botón “Eliminar”
y confirma la eliminación
oprimiendo la opción “si”, se identifica al proyecto y se
elimina el registro en la base de datos.
5. Para la revisión de proyectos por parte del Supervisor
basta con ir al listado de los proyectos para poder
visualizar toda la información necesaria de cada proyecto.
6. El actor sale del Sistema mediante la opción “cerrar
sesión”.
Post-condición Los datos son almacenados en la base de datos.
Tabla 3.22 Especificación de registro de proyectos modelo

ii) ESPECIFICACIÓN DE CASO DE USO (SOLICITUD DE OBRAS)
Se muestra a continuación la especificación de caso de uso que corresponde a la solicitud de

obras:
Nombre Solicitud de Obras
Código A-02
Actor(es) Dirigentes, Secretaria y Oficial Mayor Técnico
63
1. Dirigentes se apersonan a Secretaria para solicitar

el registro de una solicitud de obra.
2. Secretaria se autentica en el sistema.
3. Secretaria llena los datos necesarios para la solicitud
de obra, presiona el botón de “Guardar” la
información es validada y guardada en la base de
datos.
4. Si existe una modificación en el Proyecto el Oficial
Mayor Técnico es el encargado de realizar las
Escenario Básico
modificaciones al proyecto dentro de un formulario,
para posteriormente ser actualizada la información en
la base de datos.
5. El rechazo o aceptación de la obra es evaluada por
el Oficial Mayor Técnico, se va guardando la
información para posteriormente ser publicada y
notificada a los dirigentes.
6. Los actores salen del Sistema mediante la opción
“cerrar sesión”.
Tabla 3.23 Especificación de solicitud de obras

iii) ESPECIFICACIÓN DE CASO DE USO (PUBLICACIÓN DE OBRAS)
Se muestra a continuación la especificación de caso de uso que corresponde a la publicación

de obras:
64
Nombre Publicación de Obras
Código A-03
Actor(es) Oficial Mayor Técnico y Supervisor de Obras

2. Oficial Mayor Técnico procede a evaluar las obras
solicitadas y listar las aceptada y rechazadas.
3. Presiona el botón de “Publicar Obras Aceptas” para
ser visualizadas en la página de la Alcaldía.
4. Presiona el botón de “Publicar Obras Rechazadas”

Escenario Básico
para ser visualizadas en la página de la Alcaldía.
5. El Supervisor de Obras Verifica mediante un listado
las obras Rechazadas y Aceptadas para poder hacerles
el seguimiento correspondiente.
6. Los actores salen del Sistema mediante la opción
“cerrar sesión”.
Tabla 3.24 Especificación de publicación de obras

iv) ESPECIFICACIÓN DE CASO DE USO (SEGUIMIENTO DE OBRAS)
Se muestra a continuación la especificación de caso de uso de seguimiento de obras.
Nombre Control de Obras
Código A-05
65
Actor(es) Dirigentes
1 El actor inicia sesión en la página de la Alcaldía.
2. Procede a registrar en un formulario el avance de

una obra en específica, da en “Guardar” y los datos
son validados y almacenados en la base de datos para
su posterior revisión.
3. Procede a registrar en un formulario el retaso u
Escenario Básico
observación de una obra en específica, da en
“Guardar” y los datos son validados y almacenados en
la base de datos.
4. El actor procede a buscar una obra en específica

para ver el avance registrado y el estado en la que se
encuentra para informarse.
Tabla 3.25 Especificación de seguimiento de obras

v) ESPECIFICACIÓN DE CASO DE USO (CONTROL DE OBRAS)
Se muestra a continuación la especificación de caso de uso que corresponde al control de

obras:
Nombre Control de Obras
Código A-05
66
Actor(es) Dirigentes
1. El actor inicia sesión en la página de la Alcaldía.
2. Procede a registrar en un formulario el avance de

una obra en específica, da en “Guardar” y los datos son
validados y almacenados en la base de datos para su
posterior revisión.
3. Procede a registrar en un formulario el retaso u
Escenario Básico
observación de una obra en específica, da en “Guardar”
y los datos son validados y almacenados en la base de
datos.
4. El actor procede a buscar una obra en específica para

ver el avance registrado y el estado en la que se
encuentra para informarse.
Tabla 3.26 Especificación de control de obras

3.3.2.4. MODELO DE CONTENIDO
El modelo de contenido es la que describe mediante un diagrama de clases los modelos

(tablas) con sus respectivos atributos y métodos que serán asociados al modelo.
Laravel cuenta con una librería ORM llamado Eloquent, que es el encargado de interactuar
con la base de datos mediante los modelos, considerando este punto se presenta el modelo de
contenido del sistema:
67
Figura 3.8 Diagrama de Clases
68
3.3.3. DISEÑO
La etapa de diseño comprende la presentación de modelos, la interfaz y las pantallas del

sistema. Se realiza la elaboración del sistema con las herramientas necesarias para su
implementación.
3.3.3.1. MODELO DE NAVEGACIÓN
Muestra de qué manera se enlazan las páginas, para así tener una mejor idea de la estructura
del sistema; de acuerdo a los módulos especificados se muestran los modelos de presentación
a continuación.
a) MODELO DE NAVEGACIÓN PARA EL REGISTRO DE PROYECTOS

MODELO
A continuación se presenta el modelo de navegación correspondiente al registro de proyectos

modelo:
Figura 3.9 Modelo de navegación para el registro de proyectos modelo

b) MODELO DE NAVEGACIÓN PARA LA SOLICITUD DE OBRAS

Se presenta a continuación el modelo de navegación correspondiente al registro de solicitudes
de obras:
69
Figura 3.10 Modelo de navegación para el registro de solicitudes de obras
c) MODELO DE NAVEGACIÓN PARA LA PUBLICACIÓN DE OBRAS
Se presenta a continuación el modelo de navegación correspondiente a la publicación de

obras:
Figura 3.11 Modelo de navegación para la publicación de obras

70
d) MODELO DE NAVEGACIÓN PARA EL SEGUIMIENTO DE OBRAS
Se presenta a continuación el modelo de navegación correspondiente al seguimiento de
obras:
Figura 3.12 Modelo de navegación para el seguimiento de obras

e) MODELO DE NAVEGACIÓN PARA EL CONTROL DE OBRAS

Se presenta a continuación el modelo de navegación correspondiente al control de obras:
Figura 3.13 Modelo de navegación para el control de obras

71
3.3.3.2. MODELO DE PRESENTACIÓN (MAQUETACIÓN)
El modelo de presentación provee información acerca de los procesos y la estructura de una

página web, en otras palabras, una representación esquemática de los objetos visibles al
usuario, utilizando la información de los modelos definidos anteriormente.
a) MODELO DE PRESENTACIÓN PARA EL REGISTRO DE PROYECTOS

MODELO
A continuación se muestra el modelo de presentación para el registro de proyectos modelo:
Figura 3.14 Modelo de presentación para el registro de proyectos modelo

72
b) MODELO DE PRESENTACIÓN PARA SOLICITUD DE OBRAS
A continuación se muestra el modelo de presentación para la solicitud de obras:
Figura 3.15 Modelo de presentación para la solicitud de obras

73
c) MODELO DE PRESENTACIÓN PARA LA PUBLICACIÓN DE OBRAS
A continuación en la figura 3.16 se muestra el modelo de presentación para la publicación de

obras:
Figura 3.16 Modelo de presentación para la publicación de obras

d) MODELO DE PRESENTACIÓN PARA EL SEGUIMIENTO DE OBRAS
A continuación en la figura 3.17 se muestra el modelo de presentación para el seguimiento

de obras:
74
Figura 3.17 Modelo de presentación para el seguimiento de obras
e) MODELO DE PRESENTACIÓN PARA EL CONTROL DE OBRAS

A continuación en la figura 3.18 se muestra el modelo de presentación para el control de
obras:
75
Figura 3.18 Modelo de presentación para el control de obras
3.3.3.3. DIAGRAMA ENTIDAD – RELACIÓN
De acuerdo a las especificaciones y los requisitos planteados se hizo el diseño del diagrama
entidad relación. En la figura 3.19 se muestra el diagrama E-R
76
Figura 3.19 Diagrama entidad relación
77
De la misma manera se realizó el modelo relacional, para el siguiente paso a tablas, que se
visualiza a continuación:
Figura 3.20 Modelo relacional

78
3.3.3.4. INTERFAZ DEL SISTEMA
La interfaz del sistema está desarrollada con el leguaje de modelado de datos HTML y en
colaboración con hojas de estilo para darle color, forma, tamaño y posición de los elementos
web utilizados en el sistema.
Pantalla de interfaz de usuario para el login o inicio de sesión de los miembros registrados al
sistema, verificando el código y contraseña de usuario, respectivamente.
Figura 3.21 Login de usuarios

Pantalla de inicio, visualiza los contenidos y opciones directas o los diferentes contenidos y
operaciones del sistema.
Figura 3.22 Pantalla de Inicio

79
Registro de Proyectos, visualiza el formulario de registro de proyectos los cuales serán
puestos a consideración de las diferentes comunidades, para su posterior solicitud y o
implementación.
Figura 3.23 Registro de Proyectos

Visualización de Proyectos, se genera el listado de proyectos agregados con anterioridad, los

cuales podrán ser visualizados, editados y eliminados.
Figura 3.24 Listado de Proyectos

80
Registro de Solicitudes, una vez publicados los proyectos se verificar y registran las
solicitudes de las autoridades de determinadas comunidades, para un proyecto específico.
Figura 3.25 Registro de Solicitud

Proyectos aprobados, una vez aprobada la solicitud de un proyecto, se visualiza el mismo,

para darle el seguimiento respectivo en lo que respecta a los insumos, actividades y las
responsabilidades del mismo.
Figura 3.26 Listado de Solicitudes

81
Reportes, para visualizar el seguimiento de los proyectos, se presenta el extracto de los
mismos en reportes de una determinada gestión, comunidad y categoría respectiva.
Figura 3.27 Reporte de Proyectos

Estadísticas, para poder desglosar las operaciones y acciones del sistema, se visualizan las
mismas en cuadros estadísticos acorde a determinadas directrices, como las comunidades,
categorías y proyectos.
Figura 3.28 Estadísticas por categorías

82
3.4. FASE DE TRANSICIÓN
La fase de transición es la última de Open Up en el desarrollo de un proyecto, la que abarca

las pruebas del sistema y la entrega del producto a los usuarios finales.
3.4.1. PRUEBAS DEL SISTEMA
Luego de haber desarrollado el sistema, se procede a realizar las pruebas de los

procedimientos que implementaron.
3.4.1.1. CASOS DE PRUEBA
Los casos de prueba, permitirá verificar y documentar los resultados obtenidos al realizar las
pruebas correspondientes al sistema, módulo por módulo.
A continuación se muestra el caso de prueba para el registro de proyectos modelo:
Caso de prueba: Registro de Proyectos Modelo
Registro de los proyectos modelo, con

Descripción
los datos correspondientes.
Verificar la funcionalidad de los

Objetivo del caso de prueba formularios de
registro y la visualización proyectos.
Tipo Funcional
Precondiciones Inicio de sesión.
Procedimiento de prueba
Actor Respuesta del sistema
1. El actor inicia sesión. 1. El sistema valida el inicio de sesión.

2. Selecciona ”Registrar 2. El sistema muestra el formulario de
proyecto”. registro de
83
3. Llena el formulario y proyectos.
oprime el botón “Guardar”. 3. Valida y almacena los datos.
4. El sistema muestra el listado de los
proyectos almacenados
Resultado Obtenido
Intentos Sin observaciones
Cumple No se encontraron fallas
Tabla 3.27 Caso de prueba para el registro de proyectos modelo

A continuación se muestra el caso de prueba para solicitud de obras:
Caso de prueba: Solicitud de Obras
Solicitud de Obras por parte de

Descripción
dirigentes comunales.
Verificar la funcionalidad de los

Objetivo del caso de prueba formularios de
registro de solicitudes de obras.
Tipo Funcional
Inicio de sesión.
Precondiciones
Proyectos modelo registrados
84
1. El sistema valida el inicio de sesión.
1. El actor inicia sesión. 2. El sistema muestra el formulario de
2. Selecciona ”solicitud de registro de
obra”. solicitud de obra.
3. Llena el formulario y 3. Valida y almacena los datos.
oprime el botón “Guardar”. 4. El sistema muestra el listado de las
solicitudes
Resultado Obtenido
Tabla 3.28 Caso de prueba para la solicitud de obras

A continuación se muestra el caso de prueba para la publicación de obras:
Caso de prueba: Publicación de Obras
Publicación de obras aceptadas y

Descripción
rechazadas.
Verificar la funcionalidad de
Objetivo del caso de prueba
publicación de obras.
Tipo Funcional
Inicio de sesión.
Precondiciones Proyectos Modelo registrados
Solicitudes de Obras registrados
85

2. Selecciona ”publicación de
2. Muestra el listado de Obras
Obras”.
solicitadas.
3. Aprueba o Rechaza la Obra
3. Empieza a publicar las obras
de acuerdo al presupuesto y
rechazadas y aceptadas.
otras variantes.
Resultado Obtenido
Tabla 3.29 Caso de prueba para publicación de obras

A continuación se muestra el caso de prueba para el seguimiento de obras:
Caso de prueba: Seguimiento de Obras
Descripción Seguimiento de obras en ejecución.
Verificar la funcionalidad el registro de

seguimiento de obras.
Tipo Funcional
Inicio de sesión.
Precondiciones
Obras en Ejecución
86

2. Selecciona ”Obra en
2. Muestra el listado de Obras
ejecución”.
solicitadas.
3. Introduce los datos de
3. Guarda la información re4specto a las
observaciones a obras en
obras en ejecución.
ejecución.
Resultado Obtenido
Tabla 3.30 Caso de prueba para el seguimiento de obras

A continuación se muestra el caso de prueba para el control de obras:
Caso de prueba: Control de Obras
Descripción Control de Obras en ejecución.
Verificar la funcionalidad del control de

obras.
Tipo Funcional
87
Inicio de sesión.
Precondiciones
Obras en ejecución
1. El actor inicia sesión. 1. El sistema valida el inicio de sesión.

2. Selecciona ”la Obra en 2. Despliega el formulario de Reclamos
ejecución”. y Observaciones.
3. Llena el formulario de 3. Guarda toda la información referente
observación hacia una obra en al reclamo u observación de una obra e
ejecución. ejecución.
Resultado Obtenido
Tabla 3.31 Caso de prueba para el control de obras

3.4.2. PRUEBAS DE STRESS
Dentro de la pruebas de rendimiento de software se realizan o se encuentran las pruebas de

estrés son las que evalúan y ponen aprueba la robustez y la confiabilidad del software
sometiéndolo a condiciones de uso extremas. Entre estas condiciones se incluyen el envió
excesivo de peticiones y la ejecución en condiciones de hardware limitadas. Para aplicaciones
web, una posible condición extrema puede ser el acceso de un enorme número de usuarios
en poco tiempo.
El objetivo de las pruebas de estrés es saturar el programa hasta un punto de quiebre donde
aparezcan defectos potencialmente peligrosos, no para decir que el sistema no funciona, lo
88
que se intenta es mejorar el sistema reduciendo riesgos que puedan dar origen a una caída del
sistema.
3.4.2.1. LOAD IMPACT
Impacto de carga ofrece pruebas y presentación de informes de carga como un servicio en

línea para el comercio electrónico y de negocio a negocio (B2B) sitios en todo el mundo.
¿Qué es Load Impact?
Impacto de carga ofrece una solución simple pero esencial para startups y empresas que
buscan a escala. Impacto de carga proporciona servicios de pruebas de carga en-demanda
que se puede acceder desde el navegador.
Impacto de carga es uno de esos servicios que permite al usuario generar carga de diversas
partes del mundo para llevar a cabo una prueba de esfuerzo en su sitio web.
El proyecto fue sometido a pruebas de estrés con la pagina Load Impact y los resultados de
muestran en la siguiente imagen.
Figura 3.29 Diseño de construcción- prueba de estrés I

89
Figura 3.29 Diseño de construcción- prueba de estrés II
En la imagen anterior se muestra los resultados que Load Impact emite en cuanto al sistema.
Se observa que indican el rendimiento del mismo en un instante donde existen más de 25
usuarios conectados, los resultados indican que el sistema funciona y responde bastante bien
cuando existe esta saturación de usuarios conectados, este resultado servirá para mejorar el
sistema, de esta forma cumplir con las expectativas del usuario en su totalidad
90
CAPÍTULO 4
CALIDAD Y SEGURIDAD
4.1. INTRODUCCIÓN
La calidad y seguridad del software es una de las etapas fundamentales para la

implementación del mismo, ya que en este proceso se evalúa el funcionamiento adecuado,
de acuerdo a lo planificado y establecido, siguiendo procedimientos para la seguridad del
mismo.
4.2. CALIDAD
La calidad del sistema visualiza mediante el funcionamiento óptimo del mismo, en este
entendido se determinara la calidad del software mediante el modelo de calidad Web-site
QEM.
4.2.1. METODOLOGÍA WEB SITEQEM
La metodología Web-site QEM fue desarrollada por Luis Olsina, con el propósito de aportar
una estrategia eficaz para evaluar y analizar la calidad de las WebApps (Aplicaciones Web).
Está basada en un modelo Jerárquico de requerimientos de calidad, partiendo de las
características de alto nivel prescritas en la norma ISO-9126 [Olsina, 1999]
4.2.1.1. DEFINICIÓN DE LOS REQUERIMIENTOS DE CALIDAD
Se definen las metas para la evaluación de calidad:
 Compatibilidad del sistema en los diferentes navegadores

 Compatibilidad del sistema en los diferentes dispositivos: PC, tablet, móvil.
 Lograr una interfaz amigable entre el administrador del mismo y el receptor de los
diferentes contenidos.
Los perfiles de usuario se detallan a continuación:
 Administrador: el cual tiene accesos a todos los módulos del sistema

 Oficial mayor de Proyectos: Con acceso al módulo de proyectos.
91
 Oficial mayor de área: Con acceso a su proyecto designado para el seguimiento
respectivo.
 Autoridad: Con acceso a información de un proyecto en cuestión.
4.2.1.2. EVALUACIÓN ELEMENTAL
En esta etapa se evaluara todos los puntos del árbol de características. Dándoles valores para
el puntaje elemental entre los tres niveles de aceptabilidad, esto es, insatisfactorio
(De 0 a 40%), marginal (desde 40 a 60%), y satisfactorio (desde 60 a 100%).
Calcularemos la usabilidad del sistema web.
Características y Subcaracterísticas Valor IEi
1. Usabilidad 91.6
1.1. Comprensibilidad Global del Sitio 90.4
1.1.1. Esquema de Organización Global 89.3
1.1.1.1. Mapa del Sitio 90
1.1.1.2. Tabla de Contenidos 91
1.1.1.3. Índice Alfabético 87
1.1.2. Calidad en el Sistema de Etiquetado 91.5
1.1.2.1. Etiquetado Textual 90
1.1.2.2. Etiquetado con Iconos 93
1.2. Mecanismos de Ayuda y Retroalimentación 90.8
1.2.1. Calidad de la Ayuda 90
1.2.1.1. Ayuda Explicatoria Orientada al Usuario 90
92
1.2.2. Indicador de Ultima Actualización 91.5
1.2.2.1. Global (de todo el sitio Web) 90
1.2.2.2. Restringido (por subsitio o página) 93
1.3. Aspectos de Interfaces y Estéticos 93.7
1.3.1. Cohesividad al Agrupar los Objetos deControl Principales 100
1.3.2. Permanencia y Estabilidad en la Presentación de los controles 90.7

principales
1.3.2.1. Permanencia en Controles Directos 90
1.3.2.2. Permanencia en Controles Indirectos 87
1.3.2.3. Estabilidad 95
1.3.3. Aspectos de Estilo 100
1.3.3.1. Uniformidad en el Color de Enlaces 100
1.3.3.2. Uniformidad en el Estilo Global 100
1.3.3.3. Guía de Estilo Global 100
1.3.4. Preferencia Estética 90
Tabla 4.1 Resultado de criterio de Usabilidad

Calcularemos dándonos valores la funcionabilidad del sistema web.
2. Funcionalidad 92.7
2.1. Aspectos de búsqueda y Recuperación 91.3
93
2.1.1. Mecanismo de Búsqueda en el Sitio Web 90
2.1.1.1. Búsqueda Restringida 90
2.1.1.2. Búsqueda Global 90
2.1.2. Mecanismos de Recuperación 92.5
2.1.2.1. Nivel de Personalización 90
2.1.2.2. Nivel de Retroalimentación a la Recuperación 95
2.2. Aspectos de Navegación y Exploración 96.5
2.2.1. Navegabilidad 93
2.2.1.1. Orientación 95
2.2.1.2. Promedio de enlaces por Pagina 91
2.2.2. Objetos de Control Navegacional 100
2.2.2.1. Nivel de Desplazamiento 100
2.2.2.1.1. Desplazamiento Vertical 100
2.2.2.1.2. Desplazamiento Horizontal 100
2.3. Aspectos del Dominio relacionados alPersonal Técnico 90.3
2.3.1. Relevancia del Contenido 90.3
2.3.1.1. Registro de Socios y Movilidades 92
2.3.1.2. Reporte de Ingresos, Egresos y Deudas 89
2.3.1.3. Historial del Socio 90
Tabla 4.2 Resultado de criterio de Funcionalidad

94
Calcularemos la confiabilidad del sistema web, dándonos valores.
3. Confiabilidad 91.3
3.1. No deficiencia 91.3
3.1.1. Errores de Enlaces 95
3.1.1.1. Enlaces Rotos 100
3.1.1.2. Enlaces Inválidos 100
3.1.1.3. Enlaces no Implementados 85
3.1.2. Errores o Deficiencias Varias 87.5
3.1.2.1. Deficiencias o cualidades ausentes debido aluso de 90

diferentes navegadores
3.1.2.2. Paginas Muertas 85
3.1.2.2.1. Paginas sin Respuesta 85
Tabla 4.3 Resultado de criterio de Confiabilidad

Calcularemos la eficiencia de la página web, dándonos valores.
4. Eficiencia 92.5
4.1. Performancia 90
4.1.1. Páginas de Acceso Rápido 90
4.2. Accesibilidad 95
95
4.2.1. Accesibilidad de Información 95
4.2.1.1. Soporte a Versión solo Texto 90
4.2.1.2. Legibilidad al desactivar la Propiedad Imagendel 100

Navegador
4.2.1.2.1. Imagen con Texto 100
4.2.1.2.2. Legibilidad Global 100
4.2.2. Accesibilidad de Ventanas 95
4.2.2.1. Numero de Vistas considerando Marcos(frames) 95
4.2.2.2. Versión sin Marcos 95
Tabla 4.4 Resultado de criterio de Eficiencia

4.2.1.3. EVALUACIÓN GLOBAL
Una vez realizado los resultados de cada uno de los criterios, se obtiene:
Criterio Porcentaje % Aceptabilidad
Usabilidad 91.6 Satisfactorio
Funcionalidad 92.7 Satisfactorio
Confiabilidad 91.3 Satisfactorio

Eficiencia 92.5 Satisfactorio
Calidad Global 92.03 Satisfactorio
Tabla 4.5 Resultado de calidad global

96
Donde la calidad global es de 86.4 el cual es satisfactorio en cuanto al porcentaje de
aceptabilidad, cuyo rango es de 60 a 100 %. Lo cual refleja un sistema de calidad satisfactoria
para su utilización.
4.3. SEGURIDAD
La seguridad informática se enfoca en la protección de la infraestructura computacional y

todo lo relacionado con esta, incluyendo la información contenida. Una técnica de seguridad
informática es un mecanismo o herramienta que se utiliza para fortalecer la
confidenciabilidad, la integridad y/o disponibilidad de un sistema informático.
Según [Duran, 2010], menciona que si no hacemos nada o no tenemos en cuenta sólidos
principios de seguridad entonces tenemos un gran riesgo de que nos ocurra un incidente de
seguridad. La seguridad informática se trata del manejo de este riesgo.
4.3.1. RESTRICCIÓN DE SESIONES
Se establece políticas de seguridad del sistema solo permitiendo usuarios que se encuentren
validados en el servidor. Para las cuentas de usuario se utilizan sesiones de PHP, dichas
cuentas están almacenadas en la Base de datos, con encriptación sha1. Cuando el usuario
ingresa su password este se encripta antes de enviarlo al servidor, para poder ingresar a
su módulo respectivo.
Figura 4.1 Login de Usuarios

Fuente: elaboración propia
97
4.3.2. CONTROL DE INGRESO AL SISTEMA
Se establecen filtros de seguridad, cuando un usuario registrado intente ingresar a páginas

que no son de su competencia, el sistema le prohíbe entrar, ya que las sesiones tienen
información sobre los niveles de usuarios que existen.
La propia seguridad controlada en cada nivel por una sesión de usuario que evita la
manipulación no autorizada de las páginas. Al encontrarse estas páginas programadas sobre
PHP solo permiten ver el código HTML y no el código de los componentes que realizan los
accesos.
Figura 4.2 Control de ingreso al sistema

Fuente: elaboración propia
4.3.3. SEGURIDAD DE LA BASE DE DATOS
La seguridad en la base de datos está administrada por MySQL quien proporciona controles
de usuarios y passwords.
En la actualidad, la configuración en servidores de pago como locales permite la copia de

seguridad de la base de datos, en un lapso de tiempo establecido, en caso de un ataque, que
ocasionara la perdida de información.
98
CAPÍTULO 5
ANALISIS COSTO BENEFICIO
5.1. INTRODUCCIÓ
Este capítulo demuestra la estimación de costos y beneficios que se espera obtener con el
desarrollo e implementación del presente sistema.
Se utilizará el modelo COCOMO II que permite realizar estimaciones en función a la

envergadura del software y varios factores de costo.
Se realizará paralelamente el cálculo de rentabilidad basándose en el modelo VAN/TIR en

base a su rentabilidad.
5.2 COSTO DE SOFTWARE
Para realizar la estimación de costo de software se aplicará el método algorítmico de

aproximación COCOMO II orientado a los puntos de función ajustados, los cuales deberán
ser calculados.
5.2.1. PUNTO DE FUNCIÓN
Un punto de función permite establecer una medida a la funcionalidad de cada componente,

módulo y característica desde la perspectiva del usuario.
Según la metodología debemos considerar los siguientes aspectos:
5.2.2. PUNTO DE FUNCIÓN SIN AJUSTAR
Se deben tomar en cuenta estos componentes para este cálculo:
COMPONENTE DETALLE
Entradas de datos y que actualizan

Entradas de Usuario
datos internos
Salidas de Usuario Procesos que muestran datos
99
Procesos que consisten en la
Peticiones de Usuario
combinación de entradas y salidas
Datos lógicos agrupados parte de una

Archivos
base de datos
Número de interfaces no legibles por

Interfaces Externas
el usuario
Tabla 5.1 Componentes para calcular punto de función

Fuente: Elaboración Propia
Unas ves halladas los componentes, se deben agrupar junto con el factor de ponderación lo
que dará:
Factores de ponderación
Parámetros de
Baja Media Alta
medición
# Fi Total # Fi Total # Fi Total
Entradas de Usuario
4x4 16 7x5 35 10 x 3 30
(Inputs)
Salidas de Usuario
3x6 18 7x5 50 15 x 3 45
(Outputs)
Peticiones de
2x5 10 5x4 20 10 x 3 30
Usuario (Queries)
100
Archivos Lógicos
1x5 5 2x5 10 4x3 12
Internos (Archivos)
Interfaces Externas
1x5 5 1x5 5 2x4 8
(Interfaces)
Total 54 120 125
PFNA (∑ 𝐹𝑎𝑐𝑡𝑜𝑟𝑒𝑠) 299
Tabla 5.2 Calculo de punto de función sin ajustar

Por tanto, se tiene el valor de los puntos de función sin ajustar, que es de 299, que se obtiene
de la sumatoria de los factores de ponderación.
5.2.3. CALCULO DE ESFUERZO
Para obtener el esfuerzo estimado debemos considerar también el costo por línea de código
en función al lenguaje de programación que en este caso es PHP, para eso consultamos la
siguiente tabla:
Lenguaje Factor LDC/PF
Assembler 320
C++ 128
JAVA 53
Visual Basic 30
Visual C++ 29
101
PHP 29
Power Builder 16
Tabla 5.3 Tabla de factor LDC

Y aplicamos la fórmula:
𝐿𝐷𝐶 = 𝑃𝐹𝐴 ∗ 𝐹𝐴𝐶𝑇𝑂𝑅 𝐿𝐷𝐶 ⁄𝑃𝐹
Donde:
LDC: Líneas de Código
PFA: Puntos Función Ajustados
Factor LDC/PF: Líneas de código por punto función
Entonces:
𝐿𝐷𝐶 = 299 ∗ 29
𝐿𝐷𝐶 = 8671
A continuación se convierte el LDC en miles de líneas de código, de la siguiente manera:
𝐾𝐿𝐷𝐶 = 8571/1000
𝑲𝑳𝑫𝑪 = 8.571
Por lo tanto el tamaño del software es de 8.571 líneas de código, las cuales tomamos en
cuenta para calcular el esfuerzo nominal.
Esfuerzo nominal
A continuación realizaremos el cálculo de esfuerzo necesario para la programación del

sistema para ello utilizamos la siguiente ecuación.
𝐸 = 𝑎 (𝐾𝐿𝐷𝐶)b
Con la tabla 5.4 se definirá que tipo de proyectos es.
102
PROYECTO DE
a b c d
SOFTWARE
Orgánico 2.4 1.05 1.05 0.38
Semi-Acoplado 3.0 1.12 2.5 0.35
Empotrado 3.6 1.20 2.5 0.32
Tabla 5.4 Relación de Valores (Cocomo)

Para hallar el esfuerzo primero determinamos el tipo de proyecto, verificamos con nuestro
𝐿𝐷𝐶 y comparamos con la tabla 5.4. Usamos los datos del tipo que es nuestro proyecto.
𝐸 = 2.4 (8.571)1.05
𝐸 = 22.90 persona mes
Esfuerzo del tiempo del proyecto
Para hallar el tiempo de proyecto usamos los datos de la tabla 5.1, ya que nuestro proyecto
es de tipo orgánico tenemos:
𝐷 = (𝐸)d
𝐷 = 1.05 (22.90)0.38
𝐷 = 3.45 meses
D=3.45≅ 3 personas
Esfuerzo de personal del proyecto
Para calcular la cantidad en número de programadores se utiliza la siguiente formula:
𝑃=𝐸/𝐷
Remplazando los datos ya obtenidos tenemos:
𝑃 = 22.90 / 3.45
103
𝑃 = 6.63 ≅ 7 personas
5.2.1.2. COSTO DE DESARROLLO
Para calcular el costo total de desarrollo consideramos 3 factores:
Considerando que el salario de un programador es de 4000
𝐶𝑜𝑠𝑡𝑜𝑇𝑜𝑡𝑎𝑙 = 𝑁𝑑𝑒𝐷𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑎𝑑𝑜𝑟𝑒𝑠 ∗ 𝑇𝐷𝐸𝑉 ∗ 𝑆𝑎𝑙𝑎𝑟𝑖𝑜
𝐶𝑜𝑠𝑡𝑜𝑇𝑜𝑡𝑎𝑙 = 3 ∗ 7 ∗ 4000
𝑪𝒐𝒔𝒕𝒐𝑻𝒐𝒕𝒂𝒍 = 𝟖𝟒𝟎𝟎𝟎𝑩𝒔.
5.2.1.3 COSTO DE ELABORACIÓN DEL PROYECTO
El costo de elaboración del proyecto viene dado por los costos del estudio del sistema, por
tanto se tiene lo siguiente:
Descripción Costo Total (Bs.)
Análisis y diseño del

proyecto 1200
internet 300
Material de escritorio 150
Otros 120
Total 1770
Tabla 5.5 Costo de elaboración del proyecto

5.2.4 COSTO TOTAL DEL SOFTWARE
El costo total del software se lo obtiene de la sumatoria del costo de: desarrollo y elaboración
del proyecto.
104
𝐶𝑜𝑠𝑡𝑜𝑇𝑜𝑡𝑎𝑙𝐷𝑒𝑙𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 𝐷𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜 + Elaboración
𝐶𝑜𝑠𝑡𝑜𝑇𝑜𝑡𝑎𝑙𝐷𝑒𝑙𝑆𝑜𝑓𝑡𝑤𝑎𝑟𝑒 = 84000 + 1770
𝑪𝒐𝒔𝒕𝒐𝑻𝒐𝒕𝒂𝒍𝑫𝒆𝒍𝑺𝒐𝒇𝒕𝒘𝒂𝒓𝒆 = 𝟖𝟓𝟕𝟕𝟎𝑩𝒔.
5.3. FACTIBILIDAD ECONOMICA
5.3.1 CALCULO DEL RETORNO DE INVERSION
5.3.1.1. VAN (Valor Actual Neto)
Es un indicador financiero que mide el flujo de los ingresos y egresos futuros que tendrá un
proyecto, para determinar si luego de descontar la inversión inicial queda una ganancia. El
procedimiento permite calcular el valor presente de un determinado número de flujos de caja
futuros (ingresos menos egresos), además se descuenta un tipo de interés igual para todo el
periodo considerado.
La fórmula que permite calcular el VAN es:

𝑛
𝐹2
𝑉𝐴𝑁 = ∑ − 𝐼0
(1 + 𝑖)𝑡
𝑡=0
Donde:
𝑉𝐴𝑁= Valor Actual Neto
𝑡 = Periodo
𝑛 = Numero de Periodos
𝑖 = Tasa de retorno o descuento
𝐼0 = Costos exigidos durante el periodo t
Con un 12% de ingreso:
Año 0 Año 1 Año 2 Año 3 Año 4
Flujo Neto -𝟖𝟓𝟕𝟕𝟎 20000 30000 35000 40000
105
20000 30000 35000 40000
𝑉𝐴𝑁 = + + + − 85770
(1 + 0.12)1 (1 + 0.12)2 (1 + 0.12)3 (1 + 0.12)4
𝑽𝑨𝑵 = 𝟔𝟑𝟑𝟓
5.3.1.2. TIR (Tasa Interna de Retorno)
Representa la rentabilidad que se obtiene al vencimiento del proyecto. Este método considera
que una inversión es aconsejable se la TIR resultante es igual o superior a la tasa exigida por
el inversor, si es menor el proyecto debe de rechazarse.
Teniendo en cuenta que el promedio de vida de un software es de 5 años y el tipo de descuento

que se aplica a proyectos de inversión con riesgos similares es mayor o igual 12%, con tales
datos se realizan los siguientes cálculos utilizando la fórmula:
𝑛
𝐵𝑡
𝑉𝐴𝑁 = ∑ − 𝐼0 = 0
(1 + 𝑖)𝑡
𝑡=0
20000 30000 35000 40000

1
+ 2
+ 3
+ − 85770𝐵𝑠 = 0
(1 + 𝑖) (1 + 𝑖) (1 + 𝑖) (1 + 𝑖)4
𝒊 = 𝟎. 𝟏𝟓
Es decir, el TIR es igual al 15.09%, que es la tasa máxima con la que se debe trabajar para
que el proyecto sea rentable. También se puede considerar que El TIR es mayor a la tasa de
retorno con la que se hizo el cálculo del VAN (12%), de tal manera que el proyecto es rentable
y brindara beneficios en los años estipulados
5.3.1.3. BENEFICIO/COSTO
Para obtener el costo beneficio del proyecto vamos a utilizar la siguiente formula:
𝑛 𝑉𝑡
𝐵 ∑𝑡=0 (1 + 𝑖)𝑡
=
𝐶 ∑𝑛 𝐶𝑡
𝑡=0 (1 + 𝑖)𝑡
Reemplazando:
106
𝐵 125000
= = 𝟏, 𝟒𝟓
𝐶 85770
Una vez obtenido el resultado, este será interpretado de la siguiente manera:
Si (VAN > 0) Se producirán ganancias
Si (VAN < 0) Se producirán perdidas
Si (VAN = 0) Ni perdidas ni ganancias
Esto indica que el costo total invertido tendrá una ganancia de 45 centavos de boliviano por
cada uno invertido.
107
CAPÍTULO 6
CONCLUSIONES Y RECOMENDACIONES
6.1. CONCLUSIONES
El sistema permitió automatizar el proceso de datos obteniendo la información de forma

rápida, eficaz y confiable con la generación de los reportes, trayendo como beneficio una
mejor toma de decisiones en la Sub alcaldía de Ovejuyo.
 Se digitalizó la documentación concerniente a las obras en ejecución y conclusión,

también se aseguró su permanencia, evitando perdidas.
 El sistema brindara a los dirigentes información rápida del estado que se encuentra su
proyecto solicitado.
 La información de los seguimientos y controles que se realiza, será visible para los
vecinos y dirigentes en tiempo real, haciendo el uso del INTERNET como una
herramienta de comunicación.
 El sistema brinda un espacio donde se registrara los reclamos que realizan los dirigentes,
podrán ingresar al sistema mediante su correo y su contraseña.
 El sistema brindara información detallada de los técnicos que trabajan en la unidad de
ejecución de proyectos, también brindara información de los dirigentes de cada zona y/o
comunidad.
 El sistema está diseñado en una estructura modular que permite agregar o quitar
componentes individuales, sin que se vea afectado el funcionamiento del mismo.
La seguridad del sistema permite el ingreso seguro y confiable a la aplicación evitando que
intrusos puedan acceder al mismo.
La interfaz de usuario se diseñó de forma amigable, utilizando la información necesaria en

las pantallas con el propósito de que el usuario puede interactuar con el sistema sin dificultad;
también fueron considerados los mecanismos de validación, para evitar que se ingresen datos
erróneos, garantizando seguridad de la información almacenada.
108
6.2. RECOMENDACIONES
Se considera necesario incorporar alternativas de solución a corto plazo para el incremento

de la seguridad de la información de las Obras, dentro de éstas se sugieren entre otras,
archivos físicos adecuados, ubicación adecuada para dichos archivos y protección por parte
del personal de seguridad hacia la información manejada a través de documentos
institucionales.
Es necesario tener un nivel de contraseña seguro con una longitud mínima de 14 caracteres
de la forma; caracteres numéricos y alfanuméricos, para evitar que intrusos quieran acceder
a la cuenta.
El sistema deberá ser promocionado para que otros usuarios puedan acceder y así informarse
de las obras que la Municipalidad está ejecutando en el cantón.
109
BIBLIOGRAFÍA
(Aguilar, 2012) F. E. Sistema de Información para el Seguimiento y

Monitoreo de la Documentación en la Caja Nacional de
Salud. Universidad Mayor de San Andrés. Carrera de
Informática.
(Avante, 2016) Comparativa de metodologías agiles vs tradicionales.

Recuperado de: http://www.avante.es/comparativa-
metodologias-agiles-vs-tradicionales/
(DWJQ, 2016) DESARROLLO WEB. Obtenido de Manual de Jquery:

http://www.desarrolloweb.com/manuales/manual-jquery
(Gallego, 2016) A. J. Laravel 5, The PHP Framework for Web Artisans.
(Gilfillan, 2008) I. G (2008) La Boblia de MySQL. Editorial Anaya

Multimedi
(Gómez, 2000), L, M, O, A, M, S. COCOMO, UN MODELO DE

ESTIMACION DE PROYECTOS DE
SOFTWARE.
(IWeb, 2010) L.J. Ingeniería Web. Recuperado de:

http://upolijenny.blogspot.com/2010/12/ingenieria-web.html
(Muriel, 2012) Metodologías Agiles vs Tradicionales. Recuperado de:

http://juanmurielc.blogspot.com/2012/05/metodologias-
agiles-vs-tradicionales.html
(OpenUp, 2014) Open Up, Metodología Open Up. Recuperado de:

http://openup.blogspot.es/1392789077/metodologia-open-up/
(Pressman, 2010) Pressman, R., (2010). “Ingeniería de Software, un Enfoque

Práctico”, Séptima Edición. Editorial McGraw Hill.
110
(Rossi, Pastor, Gustavo Rossi, Oscar Pastor, Daniel Schwabe, Luis Olsina
Schwabe, Olsina (2010) Web Engineering: Modelling and Implementing Web
2010) Applications. Editorial Springer
(Pineda, 2011) Pineda, “Diseño e Implementación de una Tecnología para el

Desarrollo de Aplicaciones Enfocada en la Utilización de las
Metodologías Agiles”, Medellín, 2011.
(Schmuller, 2000) Schmuller, “Aprendiendo UML en 24 horas”, México, 2000.

(UWE, 2015) Quiroga, A., Metodología UWE UML (UML-Based Web
Engineering). Recuperado de:
http://proyectogradoingenieriasistemas.blogspot.com/2015/0
3/metodologia-uwe-uml-uml-based-web.html
(Ucán, 2014) Ucán-Pech, J., (2014). UWE en Sistema de Recomendación

de Objetos de Aprendizaje. Aplicando Ingeniería Web: Un
Método en Caso de Estudio. Revista Latinoamericana de
Ingeniería de Software.
(Wikipedia, 2016) Manifiesto Ágil. Recuperado de:

https://es.wikipedia.org/wiki/Manifiesto_ágil
111
ANEXOS
ANEXO A – ÁRBOL DE PROBLEMA
SISTEMA WEB DE CONTROL Y SEGUIMIENTO DE OBRAS MUNICIPALES PARA LA SUBALCALDÍA DE
OVEJUYO D-I MUNICIPIO DE PALCA
El incumplimiento en
Dada la distancia que Crear susceptibilidad el cronograma de
se encuentra sobre las obras trabajo
El control y Provee escasa Poca información El trámite de

seguimiento de Obras información de las de los técnicos aprobación de
es escasa Obras así a los vecinos que están a cargo proyectos es tardía
de una Obra
No tener herramienta tecnológica

que provea información
adecuada de la administración de
Retraso en la entrega
calidad de operación de las
de Obras
Obras
Información tardía de
Excesiva documentación que Mala asignación de los la aprobación de los
existe en el Municipio técnicos en las obras proyectos
ANEXO B – ÁRBOL DE OBJETIVOS
SISTEMA WEB DE CONTROL Y SEGUIMIENTO DE OBRAS MUNICIPALES PARA LA SUBALCALDÍA DE
OVEJUYO D-I MUNICIPIO DE PALCA
Información de los Proveer información Garantizar la Tener una Facilidad en el

técnicos que están a la población sobre conclusión de organización seguimiento y
destinados a un la licitación y Obras en la fecha institucional eficiente control de las
proyecto especifico ejecución de establecida y confiable Obras
proyectos
Sistema que brinde instancias

técnicas responsables operacionales
de base de información de manera
eficiente para la toma de decisiones
Almacenar información Digitalización de Realizar el

del proceso de aprobación todos los Extraer información
seguimiento y
y ejecución de las Obras documentos que necesaria de los técnicos
control adecuado de
comprenden la y de los dirigentes.
un proyecto
ejecución de
proyectos

Universidad Mayor de San Andrés: Facultad de Ciencias Puras Y Naturales Carrera de Informática

Cargado por

Información del documento

Descripción original:

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 Andrés: Facultad de Ciencias Puras Y Naturales Carrera de Informática

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

“SISTEMA WEB DE CONTROL Y SEGUIMIENTO DE

POR: FRANKLIN PATRICIO RIVERO GONZALES

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

El presente proyecto va dedicado especialmente:

A dios por darme fuerzas para seguir adelante e

A mis padres, por el apoyo, cariño, amor,

A mi hermana y hermano por darme su

¡Muchas Gracias a todos!!

Para dar solución a estos problemas se propuso el desarrollo e implementación de un

La metodología empleada en el presente proyecto es OpenUP, que brinda un desarrollo ágil

Figura 1.1 Cronograma anual de proyectos ............................................................................ 3

Tabla 2.1 Tabla metodologías agiles vs tradicionales .......................................................... 23

Algunas instituciones públicas manejan información digital, la información digital es una

La Sub alcaldía de Ovejuyo, maneja su presupuesto de forma autónoma con el objetivo

1.2.1. ANTECEDENTES INSTITUCIONALES

El D-I Municipio de Palca, se encuentra al sur de la ciudad de La Paz, este distrito es

La Sub alcaldía de Ovejuyo cuenta con las siguientes dependencias:

 Despacho del Sub alcalde

La prioridad de la Sub alcaldía es impulsar el desarrollo urbano y rural en su Municipio,

En la actualidad los procesos institucionales que se llevan a cabo en la Sub alcaldía de

La unidad de ejecución de proyectos, realiza una serie de procesos para la aprobación,

1.2.1.1. REDACCIÓN DEL CRONOGRAMA ANUAL DE PROYECTOS

La unidad de ejecución de proyectos comandado por el oficial mayor, realizan un cronograma

Figura 1.1 Cronograma anual de proyectos

La recepción de dicha carta se realiza en secretaria, esta carta es enviada inmediatamente al

Figura 1.2 Carta de solicitud de obra

1.2.1.3. VERIFICACIÓN DE LA SOLICITUD DE OBRA

1.2.1.4. SOLICITUD DE COTIZACIÓN

La unidad de ejecución de proyectos tiene técnicos que realizan la cotización detallada de la

Figura 1.4 Hoja de Cotización

Luego de pasar por los puntos mencionados se realiza un cronograma de actividades de la

El cronograma de actividades es de mucha importancia para el oficial mayor de la unidad de

Figura 1.5 Cronograma de actividades

1.2.1.6. SEGUIMIENTO DE LA OBRA

El seguimiento es realizado en tres ocasiones durante la ejecución de la obra, este técnico

1.2.1.7. ACATA DE ENTREGA DEFINITIVA

En el acta de entrega se detalla el nombre de la comunidad, nombre del supervisor de obras,

Figura 1.7 Acta de entrega definitiva

El sistema que maneja la unidad de ejecución de proyectos es manual, en el caso de

El almacenamiento de toda la documentación es realizada en empastados; archivadores,

Figura 1.8 Almacenamiento de la documentación de proyectos

El proyecto de Ibarra (2007) titulado Sistema de información para el control y

El proyecto de Pérez (2011) titulado Sistema de Seguimiento y Control de ejecución de

El proyecto de Avalos (2007) titulado Sistema de Información Geográfico de Control y

1.3. PLANTEAMIENTO DEL PROBLEMA

La Sub alcaldía de Ovejuyo D-I Municipio de Palca tiene mucha responsabilidad en la

1.3.1. PROBLEMA CENTRAL

Tomando en cuenta lo anteriormente descrito podemos plantear la siguiente pregunta: ¿Cómo

1.3.2. PROBLEMAS SECUNDARIOS

Identificamos los siguientes problemas:

 La excesiva documentación que se tiene en la institución, haciendo que se demore en el

1.4. DEFINICIÓN DE OBJETIVOS

1.4.1. OBJETIVO GENERAL

Implementar un Sistema Web de Control y Seguimiento de Obras Municipales para la Sub

1.4.2. OBJETIVOS ESPECÍFICOS

 Se llevará a cabo la automatización de los documentos que ingresan a la institución