Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp

UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA
PROYECTO DE GRADO
SISTEMA WEB DE SEGUIMIENTO Y MONITOREO DE
PROYECTOS ORIENTADOS A RESULTADOS
CASO: COLEGIO DE ADMINISTRADORES
DE EMPRESAS DE LA PAZ “CADELP”
PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA
MENCIÓN: INGENIERÍA DE SISTEMAS INFORMÁTICOS
POSTULANTE : VLADIMIR TINTAYA GUACHALLA
TUTOR METODOLÓGICO : M.SC. ALDO RAMIRO VALDEZ ALVARADO
ASESOR : M.SC. RENÉ CASILLA GUTIÉRREZ
LA PAZ – BOLIVIA
2015

Dedicatoria
Esta obra se la dedico a mí querida familia, mi señora madre
Sara Guachalla Franco, mi señor padre Justo Tintaya Cabrera,
mi hermana Melby Libertad Tintaya Guachalla, gracias por todo
su apoyo.
También a mis amigos Katherine Castro y Nelson Aruquipa,
gracias por su orientación.
Con mucho cariño y gratitud.

Agradecimientos
Al director de la Carrera de Informática M.Sc Edgar Clavijo Cárdenas, autoridad ejemplar por su
extraordinaria capacidad de gestión para llevar adelante temas administrativos que favorecen a los
universitarios y docentes de nuestra querida carrera.
Al M.Sc. René Casilla Gutiérrez, un extraordinario profesional cuenta con un alto grado de
paciencia, siempre con los últimos conocimientos tecnológicos y científicos, dispuesto a colaborar
con todos los universitarios que así lo requieran. Su rol como asesor fue fundamental para lograr esta
obra.
Al M.Sc. Aldo Ramiro Valdez Alvarado, profesional excepcional un ejemplo a tomar en cuenta
desarrollo capacidades para llevar adelante temas administrativos en la unidad de Post Grado y
académicos en Pre Grado, cuenta con un alto grado de predisposición, conocimientos, sugerencias
para atender a todos los universitarios que lo requieran, Su rol como docente tutor fue imprescindible
para obtener este trabajo final.
A todo el directorio del Colegio de Administradores de Empresas de La Paz (CADELP), y
administrativos de la institución por la orientación en temas de gestión de proyectos, su predisposición
para lograr este producto de software. Toda mi gratitud para con el M.Sc. Luis Portugal, MBA.
José Luis Palacios y Lic. Patricia Fernández.
Al M.Sc Nelson Aruquipa Arce, por su amistad, paciencia y conocimientos en sobre la Gestión Por
Resultados, su predisposición para ser contraparte en la evaluación del código del sistema de
información fue muy importante.
A la MBA. Katherine Castro Patzi, por su amistad, apoyo moral, su rol como revisora dono rem,
evaluadora de la funcionalidad del software para este producto fue indispensable.
A todos los docentes de la carrera de Informática de nuestra querida universidad, por todos los
conocimientos, servicios y dedicación por transmitir sus experiencias.
Al Sr. Fredy Cadena Ayala por sus consejos para el manejo estético en términos de diseño y colores
fueron muy importantes.
A todos los amigos (as), compañeros(as) que tuve el agrado de conocer durante esta etapa de mi
vida, su compañía e ideas innovadoras fueron muy importantes.

133
Contenido
1. Marco Referencial................................................................................................................1
1.1 Introducción................................................................................................................1
1.2 Antecedentes...............................................................................................................3
1.2.1 Antecedentes de la Institución ........................................................................3
1.2.2 Antecedentes de Sistemas Similares...............................................................3
1.3 Planteamiento del Problema .......................................................................................4
1.3.1 Problema Central ............................................................................................4
1.3.2 Problemas Secundarios ...................................................................................5
1.4 Objetivos.....................................................................................................................5
1.4.1 Objetivo General.............................................................................................5
1.4.2 Objetivos Específicos......................................................................................5
1.5 Justificación ................................................................................................................6
1.5.1 Justificación Económica .................................................................................6
1.5.2 Justificación Social .........................................................................................6
1.5.3 Justificación Técnica.......................................................................................6
1.6 Alcances y Límites .....................................................................................................6
1.6.1 Alcances..........................................................................................................6
1.6.2 Límites ............................................................................................................7
2. Marco Teórico......................................................................................................................8
2.1 Introducción................................................................................................................8
2.2 Ingeniería de Software................................................................................................8
2.3 Ingeniería Web..........................................................................................................11
2.4 Programación Extrema .............................................................................................11
2.4.1 Fase de Planeación........................................................................................12
2.4.2 Fase de Diseño ..............................................................................................14
2.4.3 Fase de Codificación.....................................................................................15
2.4.4 Fase de Pruebas.............................................................................................16

134
2.5 Lenguaje de Modelado Web.....................................................................................17
2.5.1 Modelo de Estructura....................................................................................21
2.5.2 Modelo de Hipertexto ...................................................................................21
2.5.3 Modelo de Presentación................................................................................22
2.6 Modelo Entidad Relación .........................................................................................23
2.7 Modelo Relacional....................................................................................................23
2.8 Conversión del Modelo Entidad Relación................................................................24
2.9 La Gestión por Resultados........................................................................................25
2.10 La Gestión de Proyectos ...........................................................................................26
2.10.1 Fase de Pre inversión ....................................................................................27
2.10.2 Fase de Inversión ..........................................................................................27
2.10.3 Fase de Post inversión...................................................................................28
2.10.4 Medios y Procesos ........................................................................................28
2.11 Tecnología de software.............................................................................................29
3. Marco Aplicativo ...............................................................................................................32
3.1 Introducción..............................................................................................................32
3.2 Desarrollo con la Metodología XP ...........................................................................34
3.3 Fase de Planeación..................................................................................................35
3.3.1 Identificación de Roles y Funciones.............................................................35
3.3.2 Historias de Usuario......................................................................................36
3.3.3 Plan de Entregas............................................................................................48
3.3.4 Iteraciones.....................................................................................................49
3.4 Fase de Diseño..........................................................................................................49
3.4.1 Tarjeta de Clases, Responsabilidades y Colaboración..................................49
3.4.2 Modelo de Estructura....................................................................................53
3.4.3 Modelo Entidad Relación .............................................................................54
3.4.4 Modelo Relacional........................................................................................56
3.4.5 Modelo Hipertexto........................................................................................57
3.4.6 Modelo de Presentación................................................................................64

135
3.4.7 Matriz de procesos por tipos de usuario .......................................................65
3.4.8 Diccionario de datos .....................................................................................67
3.5 Fase de codificación .................................................................................................67
3.5.1 Modelo de presentación................................................................................67
3.5.2 Ejecución del plan de entregas por iteraciones.............................................69
3.6 Fase de pruebas.........................................................................................................81
3.6.1 Pruebas de caja blanca ..................................................................................81
3.6.2 Pruebas de caja negra....................................................................................82
3.6.3 Resultados de las pruebas de aceptación ......................................................83
3.6.4 Resultados de las pruebas de cargado del sistema........................................97
3.6.5 Resultados de las prueba de estrés del sistema .............................................99
3.6.6 Resultados de las prueba SQL inyección....................................................100
4. Calidad, Seguridad y Mantenimiento..............................................................................101
4.1 Calidad....................................................................................................................101
4.1.1 Factibilidad de uso ......................................................................................101
4.1.2 Confiabilidad...............................................................................................102
4.1.3 Funcionalidad..............................................................................................105
4.1.4 Fiabilidad ....................................................................................................109
4.2 Seguridad ................................................................................................................110
4.2.1 Seguridad de la base de datos .....................................................................111
4.2.2 Seguridad en la aplicación ..........................................................................113
4.2.3 Seguridad de comunicación........................................................................115
4.2.4 Seguridad Física..........................................................................................116
4.3 Mantenimiento........................................................................................................117
4.3.1 Mantenimiento correctivo...........................................................................117
4.3.2 Mantenimiento para fines específicos.........................................................117
4.3.3 Mantenimiento para mejoras.......................................................................118
4.3.4 Mantenimiento preventivo..........................................................................118
5. Evaluación Costo - Beneficio...........................................................................................119

136
5.1 Introducción............................................................................................................119
5.2 Cálculo del costo del software con el modelo COCOMO II..................................119
5.3 Cálculo del Valor Neto Actual ...............................................................................126
5.4 Cálculo de la Tasa Interna de Retorno....................................................................126
6. Conclusiones y Recomendaciones ...................................................................................129
6.1 Conclusiones...........................................................................................................129
6.2 Recomendaciones ...................................................................................................130

137
Índice de Figuras
Figura 2.1: Programación extrema .......................................................................................12
Figura 2.2: Modelo de estructura WebML con la herramienta IFML..................................21
Figura 2.3: Modelo de hipertexto IFML...............................................................................22
Figura 2.4: Modelo entidad relación.....................................................................................23
Figura 2.5: Modelo relacional ..............................................................................................24
Figura 2.6: Fases de la gestión de proyecto..........................................................................26
Figura 3.1: Relacionamiento de la gestión de proyectos con la gestión por resultados .......32
Figura 3.2: Combinación metodología, técnicas y herramientas..........................................34
Figura 3.3: Iteraciones por fases XP.....................................................................................49
Figura 3.4: Modelo de estructura o dominio del modelo del sistema...................................53
Figura 3.5: Modelo entidad relación del sistema..................................................................54
Figura 3.6: Modelo relacional obtenido con MySql.............................................................56
Figura 3.7: Modelo hipertexto ingreso al sistema ................................................................57
Figura 3.8: Modelo hipertexto página de inicio ...................................................................58
Figura 3.9: Modelo hipertexto institución, cambio contraseña de usuario...........................58
Figura 3.10: Modelo hipertexto proyecto (fp, i1).................................................................58
Figura 3.11: Modelo hipertexto indicadores de efecto (fp, i3).............................................59
Figura 3.12: Modelo hipertexto componente, actividad (fp, i2)..........................................59
Figura 3.13: Modelo hipertexto indicadores de producto (fp, i3) ........................................60
Figura 3.14: Modelo hipertexto presupuesto (fp, i4)............................................................60
Figura 3.15: Modelo hipertexto notificaciones por tiempo (fp, i5)......................................61
Figura 3.16: Modelo hipertexto notificaciones por inversión (fe, i5) ..................................61
Figura 3.17: Modelo hipertexto seguimiento indicador de efecto (fe, i6)............................62
Figura 3.18: Modelo hipertexto seguimiento indicador producto (fe, i6) ............................62
Figura 3.19: Modelo hipertexto seguimiento, monitoreo actividad (fe, i6, i7) ....................63
Figura 3.20: Modelo hipertexto seguimiento, monitoreo presupuesto (fe, i6 i7).................63
Figura 3.21: Modelo de hipertexto servicios web (fe, i8) ....................................................64

138
Figura 3.22: Modelo de hipertexto proyecto con reporte de resultados (fr).........................64
Figura 3.23: Modelo de Presentación Cliente ......................................................................65
Figura 3.24: Modelo de Presentación Codigo ......................................................................65
Figura 3.25: Codificación acceso al sistema ........................................................................67
Figura 3.26: Codificación inicio e información institucional...............................................68
Figura 3.27: Codificación institución cambio de contraseña usuario...................................68
Figura 3.28: Codificación acceso proyecto (fp, fe, i1).........................................................69
Figura 3.29: Codificación lista de proyectos (fp,fe, i1)........................................................69
Figura 3.30: Codificación alta y modificaciones de proyectos (fp, i1) ................................70
Figura 3.31: Codificación baja de proyecto (fp, i1) .............................................................70
Figura 3.32: Codificación componentes y actividades (fp, fe, i2)........................................71
Figura 3.33: Codificación alta componente (fp, i2)..............................................................71
Figura 3.34: Codificación alta actividad (fp,fe, i2) ..............................................................72
Figura 3.35: Codificación baja componente (fp, i2).............................................................72
Figura 3.36: Codificación lista de indicadores efecto o producto (fp, i3)............................73
Figura 3.37: Codificación alta indicador efecto o producto (fp, i3).....................................73
Figura 3.38: Codificación alta indicador efecto o producto %, T, I, U (fp, i3)....................74
Figura 3.39: Codificación alta indicador efecto o producto cualitativos (fp, i3)..................74
Figura 3.40: Codificación baja indicador de efecto o producto (fp, i3) ...............................75
Figura 3.41: Codificación notificaciones por cuantías (fp, i4).............................................75
Figura 3.42: Codificación altas notificaciones por tiempo (fp, i4).......................................75
Figura 3.43: Codificación baja notificaciones por tiempo (fp, i4) .......................................76
Figura 3.44: Codificación alta notificaciones por presupuesto (fp, i4) ................................76
Figura 3.45: Codificación baja notificaciones por presupuesto (fp, i4) ...............................76
Figura 3.46: Codificación ítems de presupuesto (fp,fe, i5) ..................................................77
Figura 3.47: Codificación alta ítem de presupuesto (fp,fe, i5).............................................77
Figura 3.48: Codificación baja ítem presupuesto (fp, fe , i5)...............................................78
Figura 3.49: Codificación fase de ejecución de proyectos (fe, i6) .......................................78
Figura 3.50: Codificación seguimiento indicador (fe, i6) ....................................................79

139
Figura 3.51: Codificación seguimiento, monitoreo actividades (fe, i6, i7)..........................79
Figura 3.52: Codificación seguimiento presupuesto (fe, i6) ................................................80
Figura 3.53: Codificación seguimiento, monitoreo presupuesto (fe, i7)..............................80
Figura 3.54: Codificación servicio notificaciones (fe, i8)....................................................81
Figura 3.55: Prueba de Caja Blanca inicio de sistema .........................................................82
Figura 3.56: Test de velocidad .............................................................................................97
Figura 3.57: Listado de archivos evaluados en test de velocidad.........................................97
Figura 3.58: Vista en cascada de carga de la página ............................................................98
Figura 3.59: Vista conexion de carga de la página...............................................................98
Figura 3.60: Respuesta y uso de bytes en el sistema............................................................99
Figura 3.61: Prueba de estrés con 100 usuarios en segundos de respuesta ..........................99
Figura 3.62: Prueba SQL inyección ...................................................................................100
Figura 4.2.1: Conceptos de seguridad sobre la información ..............................................110
Figura 4.2.1.1: Procedimientos almacenados en MySql ....................................................112
Figura 4.2.1.2: Resultados de las pruebas SQL inyección .................................................112
Figura 4.2.2.1: Autenticación de cliente y captcha.............................................................113
Figura 4.2.2.2: Determinación de fuerza de contraseña por cambio..................................114
Figura 4.2.2.3: Control de acceso basado en roles RBAC .................................................115
Figura 4.2.3.1: Almacenamiento de logs del sistema en la base de datos..........................116
Figura 5.2.1: Definición del Proyecto en el USC-COCOMO II ........................................122
Figura 5.2.2: Definición de la escala de factores................................................................122
Figura 5.2.3: Definición EAF para el módulo proyecto del sistema en COCOMOII........123
Figura 5.2.4: Definición puntos función y lenguaje de programación COCOMOII..........124
Figura 5.2.5: Definición por tipo de función en COCOMOII............................................124
Figura 5.2.6: Definición costo del módulo proyecto en COCOMOII................................125
Figura 5.2.7: Resultados del proyecto en COCOMOII ......................................................125

140
Índice de Tablas
Tabla 2.1: Comparación de metodologías ágiles y metodologías tradicionales...................10
Tabla 2.2: Historia de usuario...............................................................................................13
Tabla 2.3: Plan de entregas...................................................................................................13
Tabla 2.4: Tarjeta de clases, responsabilidades y colaboración ...........................................15
Tabla 2.5: Unidades de contenido del WebML con la herramienta IFML...........................18
Tabla 2.6: Unidades de vista WebML con la herramienta IFML.........................................18
Tabla 2.7: Unidades de operación WebML con la herramienta IFML. ...............................19
Tabla 2.8: Unidades de flujo WebML con la herramienta IFML.........................................19
Tabla 2.9: Unidades de sesión WebML con la herramienta IFML. .....................................20
Tabla 2.10: Unidades de componente WebML con la herramienta IFML...........................20
Tabla 2.11: Unidades de servicios de componentes WebML con la herramienta IFML. ....20
Tabla 2.12: Equivalencia de modelo ER y MR para su conversión....................................25
Tabla 3.1: Historias de usuario para el desarrollo del proyecto ...........................................36
Tabla 3.2: Plan de entregas y lanzamientos pequeños .........................................................48
Tabla 3.3: Tarjetas de clases, responsabilidades y Colaboradores.......................................50
Tabla 3.4: Atributos del modelo Entidad Relación ..............................................................55
Tabla 4.1: Factibilidad de uso del sistema..........................................................................102
Tabla 4.1.2.1: Márgenes de error del sistema.....................................................................104
Tabla 4.1.3.1: Número de entradas de usuario ...................................................................106
Tabla 4.1.3.2: Número salidas de usuario ..........................................................................106
Tabla 4.1.3.3: Número de peticiones de usuario ................................................................107
Tabla 4.1.3.4: Número de archivos.....................................................................................107
Tabla 4.1.3.5: Número de interfaces externas ....................................................................108
Tabla 4.1.3.6: Factores de complejidad..............................................................................108
Tabla 4.1.3.7: Ajuste de complejidad del producto............................................................108
Tabla 4.1.4.1: Promedio de factores de calidad..................................................................110
Tabla 5.1.1: Diseño temprano de Esfuerzo EAF................................................................120

141
Tabla 5.1.2: Escala de factores SF......................................................................................120
Tabla 5.1.3: Lenguaje de conversión a puntos función......................................................121
Tabla 5.1.4: Pesos complejidad para aplicación.................................................................121
Tabla 5.1.5: Tabla resultante COCOMOII.........................................................................126
Tabla 5.4.1: Costos del proyecto estimado en 24 meses ....................................................127
Tabla 5.4.2: Ingresos del proyecto estimado en 24 meses..................................................127
Tabla 5.4.3: Flujo de caja estimado en 24 meses ...............................................................127

142
Índice de Fórmulas
Fórmula 4.1.1.1: Factibilidad de uso..................................................................................102
Fórmula 4.1.2.1: Probabilidad de que el sistema falle .......................................................103
Fórmula 4.1.2.2: Confiabilidad del módulo i del sistema ..................................................103
Fórmula 4.1.2.3: Probabilidad de que el sistema no falle ..................................................103
Fórmula 4.1.3.1: Funcionalidad aplicando punto función..................................................105
Fórmula 4.1.4.1: Fiabilidad del sistema .............................................................................109
Fórmula 5.2.1: Esfuerzo .....................................................................................................119
Fórmula 5.2.2: Ahorro o gasto relativo ..............................................................................119
Fórmula 5.3.1: Valor neto actual........................................................................................126
Fórmula 5.4.1: Nivel de recuperación de inversión ...........................................................128

Resumen
En este artículo se presenta el resumen del proyecto de grado titulado “Sistema Web de Seguimiento
y Monitoreo de Proyectos Orientados a Resultados” se plantea desarrollar un sistema de información
que apoye en la toma de decisiones para el “Colegio de Administradores Empresas de La Paz
(CADELP)”, esta obra permite reducir la pérdida de tiempo y recursos durante la fase de inversión
de los proyectos para las etapas de programación y ejecución, permitiendo tener más proyectos
exitosos para brindar nuevos servicios a los socios, donde es posible integrar los conceptos de la
gestión por resultados aplicados a los proyectos e integrarlos con la metodología de desarrollo de
software programación extrema XP, este proyecto se limita al seguimiento y monitoreo de proyectos
en función de indicadores de proceso, producto y efecto, fue necesario re factorizar la programación
extrema con las técnicas WebML y apoyarlas con herramientas para el modelado, desarrollo y base
de datos, se demuestra que el producto de esta combinación es un sistema web que funciona y apoya
en la toma de decisiones gracias a las notificaciones y alertas emitidas vía correo electrónico por
desfases que se encuentran entre la programación y ejecución de los proyectos permitiendo aplicar
medidas correctivas y de esta manera obtener proyectos con resultados exitosos para la institución.
Palabras clave: Proyecto, Gestión, Resultados, Indicadores, XP, WebML, CADELP.
Summary
This article summarizes the graduation project entitled " Web Tracking System and Monitoring
Results-Oriented Projects " is presented aims to develop an information system to support decision-
making for the "Association of Business Administrators of La Paz (CADELP) "This work helps
reduce wasted time and resources during the investment phase of the projects for the programming
and implementation stages, allowing to have more successful projects to provide new services to its
members, where it is possible to integrate the management concepts by applied to projects and
integrate with software development methodology Extreme Programming XP results, this project is
limited to tracking and monitoring projects on the basis of process indicators, output and outcome, it
was necessary to re factor the extreme programming techniques WebML and support them with tools
for modeling, database development, it is shown that the product of this combination is a web system
that works and supports decision making by notices and warnings issued via email lag which among
the programming and implementation of projects allowing corrective action and thus obtain projects
with successful results for the institution.
Keywords: Project, Management, Results, Indicators, XP, WebML, CADELP.

1
1. Marco Referencial
1.1 Introducción
El desarrollo y el uso de las Tecnologías de la Información y Comunicación (TIC) en la
WEB, han logrado posesionarse de gran manera, estos son tiempos en los que la mayoría de
las instituciones han logrado automatizar su información.
Para las instituciones, mantener el control de las actividades desarrolladas por su personal,
comprobar la calidad de los servicios y/o productos que brinda, representan una gran
dificultad cuando el personal es numeroso y las mismas se encuentran ubicadas a grandes
distancias y más aún cuando existen varios proyectos ejecutándose simultáneamente.
Los sistemas de gestión en cualquier ámbito institucional, se constituyen como herramientas
verificadoras de los mandatos, requerimientos y respuestas institucionales, también es un
medio que ayuda a visualizar la situación real de la institución, por lo tanto es un insumo
inigualable para la toma de decisiones. La combinación del seguimiento y monitoreo de las
actividades desarrolladas por el personal permiten la obtención de información objetiva en
tiempos relativamente cortos, evitando esfuerzos institucionales adicionales.
Este proyecto, presenta al Sistema web de seguimiento y monitoreo de proyectos orientados
a resultados, como un producto para el Colegio de Administradores de La Paz (CADELP),
mismo que se desarrolló en 8 capítulos que se describen a continuación:
Capítulo I: Marco Referencial, describe el entorno institucional del Colegio de
Administradores de La Paz, se determinan los problemas de manejo de información,
estableciendo los objetivos a lograr una solución, determinando de esta manera los alcances
y límites del proyecto.
Capítulo II: Marco Teórico, hace referencia todas las metodologías y paradigmas que se
aplican para resolver el problema de la institución, donde se enfatiza la aplicación de la
ingeniería de software, principalmente la ingeniería WEB misma que cuenta con métodos de
desarrollo ágil particularmente XP (programación extrema), técnicas como WEBML
(Lenguaje de modelado Web) con su herramienta IFML, el modelo E-R (Modelo entidad

2
relación) y el modelo MR (Modelo Relacional). Todo lo mencionado antes permitirá modelar
aplicando los conceptos de la Gestión por Resultados.
Capitulo III: Marco Aplicativo, Se exponen los resultados de la aplicación de los conceptos
de Gestión por Resultados GxR con la ingeniería de software, principalmente la ingeniería
Web aplicando el método XP (donde se obtienen los roles, historias de usuario, tarjetas CRC,
plan de entregas y pruebas de aceptación), el uso de las técnicas WEBML (se alcanza los
modelos de estructura, hipertexto, presentación) con la herramienta IFML, empleando las
técnicas ER y MR (se logra el modelos de la base de datos físico y lógico), todos los estudios
obtenidos permiten la obtención de producto final un sistema web.
Capítulo IV: Métricas de calidad, se muestran los niveles de calidad logrados tras la
aplicación de la ingeniería de software para el desarrollo del proyecto, aplicando la
metodología WEBSITE-QEM, se enfatiza en la Seguridad como un medio que busca que la
información tenga integridad, fiabilidad y disponibilidad. Para el Mantenimiento preventivo,
correctivo y otros se desarrollaron manuales de usuario y técnico del sistema de información.
Capítulo V: Evaluación Costo – Beneficio, se expresa los niveles de costo que implican el
desarrollo del proyecto y los niveles de beneficio que se consiguen con la implementación
del sistema, aplicando las técnica de estimación COCOMO II y calculando los indicadores
VAN y TIR.
Capítulo VI: Conclusiones y recomendaciones, se expresa las soluciones a los problemas
identificados en el proyecto, tras la implementación del software en la institución. Así mismo
se presentan algunas recomendaciones para las personas que deseen extender, innovar,
mejorar con nuevos paradigmas, metodologías y tecnológicas este trabajo.

3
1.2 Antecedentes
1.2.1 Antecedentes de la Institución
El 4 de septiembre de 1978, un grupo de profesionales tomó la iniciativa de conformar el
Colegio de Administradores de Empresas de Bolivia (CADEB). El primer Directorio del
CADEB fue posesionado mediante Asamblea el 16 de marzo de 1979 y su primera misión
fue la de elaborar y poner a consideración de los socios la aprobación del primer Estatuto.
Este grupo de profesionales como fundadores del CADEB, posteriormente decidieron
constituir al Colegio Departamental de Administradores de Empresas de La Paz, con el
objetivo de contribuir y promover el desarrollo profesional de la Ciencia de la Administración
y el ejercicio de la profesión en los campos públicos y privados del departamento. Es así que
el CADELP fue fundado el 14 de marzo de 1990, siendo refrendada posteriormente con la
Resolución de Prefectura RAP.
El Colegio de Administradores de Empresas de La Paz (CADELP), es una institución que
reúne a los profesionales del área de administración de empresas, la misma trabaja en
proyectos orientados a conseguir mejores servicios y productos para beneficiar a sus
miembros. Actualmente la institución no cuenta con un sistema de información que permita
a los socios realizar el seguimiento y monitoreo de los proyectos en curso.
1.2.2 Antecedentes de Sistemas Similares
En la Universidad Mayor de San Andrés también se desarrollaron sistemas de seguimiento
entre los que podemos destacar a:
Sistema de control y seguimiento a programas operativos anuales (POA) para el
Viceministerio de Biodiversidad, Recursos Forestales y Medio Ambiente. El trabajo hace
referencia al uso de las metodologías XP y la técnica UML. Este proyecto resuelve el
problema de dispersión de información en la institución, desarrollando un sistema, mismo

4
que optimiza los tiempos de respuesta para la elaboración de informes sobre el estado y
desarrollo de los proyectos. [Huanca, 2011]
Sistema de información y seguimiento de proyectos caso: Unidad Desconcentrada Sustentar,
La metodología utilizada para el análisis es RUP conjuntamente con el UML y redes de Petri.
El Sistema es una herramienta para realizar el seguimiento a diferentes proyectos que se
gestiona mediante la Unidad Desconcentrada SUSTENTAR en los diferentes tipos de
proyectos como pequeños, medianos y grandes proyectos en los diferentes sectores a nivel
nacional. [Acho, 2011]
Sistema de Control y seguimiento de proyectos ambientales. Desarrollado con la metodología
ICONIX un modelo evolutivo que se tiene sus raíces en el RUP, aplicando técnicas UML.
La finalidad del trabajo es realizar el seguimiento de los proyectos en ejecución sin importar
las dimensiones del proyecto en la fundación Medio ambiente minería e industria MEDIM
que trabaja con financiamientos de COSUDE. [Escobar, 2011]
1.3 Planteamiento del Problema
El CADELP tiene como mandato institucional, desarrollar y ejecutar proyectos para el
beneficio de sus socios. Existe la necesidad de brindar nuevos productos y servicios a los
socios ello implica la ejecución de proyectos mismos que requieren de seguimiento y
monitoreo con la finalidad de lograr resultados evitando extensión de tiempos y gastos
innecesarios.
1.3.1 Problema Central
¿Cómo mejorar el manejo de la información de los proyectos que lleva adelante el colegio
de administradores de La Paz?

5
1.3.2 Problemas Secundarios
• La información de los proyectos se almacena en archivos Word, Excel y otros, esta
información es parcialmente automatizada, por lo tanto se genera desorden,
disponibilidad limitada y pérdida de tiempo para su organización.
• El presidente de CADELP (gerente), puede tener a su mando varios proyectos, por lo
tanto requiere de profesiones expertos en el área (gerente de proyecto) que lleven adelante
el proyecto, por lo tanto la comunicación entre las partes no siempre será fluida y la
transferencia de información puede tornarse limitada y/o accidentada para la toma de
decisiones.
• Conocer la situación del proyecto, tomando en cuenta la relación programado y ejecutado
es importante para realizar el monitoreo (reprogramación), esta acción se dificulta aún
más si el proceso es manual y/o está en función de los informes que se entregan al final
de las fechas establecidas, está situación genera una pérdida de tiempo, recursos e
inviabiliza la ejecución esperada.
1.4 Objetivos
1.4.1 Objetivo General
Implementar un sistema web para el seguimiento y monitoreo de proyectos, que apoye a la
toma de decisiones inmediatas para el Colegio de Administradores de La Paz.
1.4.2 Objetivos Específicos
• Tener la información de los proyectos organizado y en línea;
• Aplicar conceptos de la gestión por resultados;
• Automatizar el seguimiento y monitoreo a partir de indicadores;
• Notificar y alertar el estado de los proyectos por e-mail;
• Agilizar la reprogramación mediante el monitoreo en términos de tiempo y presupuesto;

6
1.5 Justificación
1.5.1 Justificación Económica
Los socios del CADELP, administradores de empresas generalmente están al mando de los
proyectos en cargos de gerencia y los gerentes y/o responsables de proyectos son los
responsables de llevar adelante la ejecución del mismo, ambos deben tomar decisiones
inmediatas en función de la información de los proyectos, este hecho evita pérdida de
recursos, tiempo, minimiza las multas por retrasos en la presentación de informes a los
beneficiarios y los financiadores.
1.5.2 Justificación Social
Para el CADELP, los nuevos productos y/o servicios conseguidos para el beneficio de los
socios genera un fortalecimiento institucional, mejor imagen corporativa, amplia la cobertura
de sus miembros e innova con herramientas las tecnologías web para que puedan desarrollar
su trabajo en diferentes entornos.
1.5.3 Justificación Técnica
La implementación de sistemas de información para la toma de decisiones, permite a las
organizaciones modernizar, generar y aplicar de nuevos paradigmas de gestión que agilizan
y efectivizan la gestión institucional, permitiéndoles ampliar sus marcos y entornos de
acción. Esta generación acompañada con el desarrollo de las TIC, demostrará una vez más
su carácter multidisciplinario.
1.6 Alcances y Límites
1.6.1 Alcances
• El producto del desarrollo del proyecto es la implementación del Sistema WEB,
considerando conceptos de ingeniería de software, se desarrolla con software libre y se
aplican paradigmas de la gestión por resultados.

7
• Las notificaciones y alertas emitidas por el sistema de información se realizaran vía
internet por medio de correos electrónicos.
• La información detallada de las notificaciones y alertas, solo son accesibles si ingresa el
usuario al sistema, la información es reservada solo para la gerencia de la institución, el
gerente de proyecto y director administrativo en función del proyecto.
1.6.2 Límites
• El desarrollo del sistema se realizara con lenguajes de programación de carácter libre, por
lo tanto el sistema solo funcionara en servidores que soporten servicios compatibles con
la plataforma libre (Linux), donde los servicios deben funcionar de acuerdo a estándares.
• Las notificaciones emitidas por el sistema pueden ser bloqueadas por el usuario o por el
proveedor de servicios de email por lo tanto es recomendable contar con una cuenta de
correo institucional, una cuenta de correo gratuito esta siempre sometida criterios del
proveedor.
• En la gestión por resultados es un paradigma que contempla tres etapas principalmente,
la etapa de pre inversión (son los estudios de necesidad, factibilidad y otros que generan
proyectos a diseño final), la etapa de inversión (es la ejecución de los proyectos con
diseño final y se enfatiza el seguimiento, monitoreo y resultado) y finalmente la post
inversión (que se encarga de dar el mantenimiento y funcionalidad al proyecto). Este
proyecto se en foca en la automatización de la segunda la etapa (inversión) que cuenta
con las fases de programación, ejecución y resultados.
• El desarrollo del sistema se realizara con herramientas de carácter libre PHP, MYSQL,
JQUERY, y otros.

8
2. Marco Teórico
2.1 Introducción
Para el desarrollar un sistema de información es necesario aplicar recursos de ingeniería de
software, la misma destaca el uso de metodologías tradicionales y agiles, la última está
orientada al desarrollo de sistemas Web, por lo tanto se utilizaran métodos de desarrollo en
particular XP (programación extrema), con técnicas que permitirán el modelado aplicando
WEBML (lenguaje de modelado Web con la herramienta IFML), el modelo E-R (Modelo
entidad relación) y el modelo MR (modelo relacional).
Todo lo antes indicado será aplicado para modelar el paradigma gestión por resultados en la
etapa de inversión. El desarrollo del software se realizara con tecnología libre.
2.2 Ingeniería de Software
La definición de ingeniería de software varía de acuerdo a los autores, a continuación se
presenta a los más destacados:
• La ingeniería de software, es la aplicación del enfoque sistemático, disciplinado y
cuantificado al desarrollo, operación y mantenimiento del mismo; es decir es decir la
aplicación de la ingeniería de software. [Pressman, 2020]
• La ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y
cuantificable al desarrollo, operación y mantenimiento del software. [Vliet, 2002]
La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en etapas, el
conjunto de estas etapas se denomina el ciclo de vida y se detallan a continuación:
• Análisis de requisitos, es la exploración de los requisitos de un producto de software,
junto con los clientes que conocen sus necesidades de información, pero hay que tener la
habilidad y experiencia para reconocer requerimientos incompletos, ambiguos o
contradictorios.

9
• Especificación, es la descripción del comportamiento esperado del software una vez
desarrollado. El éxito está en función de la identificación de necesidades de información
de los clientes, para clasificar, priorizar, las necesidades.
• Arquitectura, es la integración estructura, aplicaciones desarrolladas, bases de datos y
herramientas que deben ser conceptualizadas y proyectadas al futuro solucionando los
problemas del momento. Este diseño describe como se construirá la aplicación de
software.
• Programación, es el proceso de traducción de un diseño arquitectónico lógico a un
lenguaje de maquina completamente funcional, donde el grado de complejidad estará en
función del lenguaje de programación y procedimientos a automatizar.
• Prueba, consiste en comprobar que el software realice lo diseñado, para que responda a
la especificación del problema, es recomendable probar los módulos separados y al final
probar el sistema completo.
• Documentación, es la información que concierne al desarrollo de software, pasando por
modelos, para el mantenimiento y/o ampliaciones del sistema en el futuro.
• Mantenimiento, su finalidad es optimizar al sistema para que responda nuevas
especificaciones, corregir errores con la finalidad de mejorar la calidad de los productos,
aumentar la productividad, suministra a los desarrolladores bases para ampliar o reducir
código, permite la estimación de tiempos y costos en función a la complejidad.
La ingeniería de software destaca dos tipos de metodologías por su versatilidad:
• Metodologías de desarrollo de software tradicionales, las metodologías tradicionales
para el desarrollo de software se basan en metodologías, se fundamenta en la división de
procesos en etapas, de manera secuencial. Se caracteriza por proveer un alto grado de
ordenamiento, es más resistente al cambio, al mantener la disciplina se pierde el objetivo
del proyecto y se imponen los procesos minimizando a las personas. Las metodologías
tradicionales, proveen de una exagerada descripción del modelo de software, pero no
indican explícitamente como se debe llevar a cabo las tareas definidas.

10
• Metodologías de desarrollo de software ágil, las metodologías de desarrollo ágil se basan
en métodos de ingeniería de software caracterizados por iteraciones e incrementos, donde
los requerimientos y soluciones evolucionan mediante la colaboración de grupos
organizados y multidisciplinarios. Esta metodología destaca el manifiesto ágil donde se
valora, a la persona e iteraciones, el desarrollo de software de acuerdo a las necesidades
de información del cliente, la colaboración con el cliente, la respuesta a cambios más que
seguir estrictamente lo planificado. Un proceso es ágil sí, es incremental, cooperativo,
sencillo y documentado. Se caracteriza por la simplicidad, documentación necesaria,
donde el análisis es una tarea constante, tiene desarrollo evolutivo, se integra con
facilidad. Existen diferencias marcadas entre las dos corrientes que se detallan en la
siguiente tabla.
Tabla 2.1: Comparación de metodologías ágiles y metodologías tradicionales
Metodología Ágil Metodología tradicional
Basadas en heurísticas provenientes de
prácticas de producción de código.
Basadas en normas provenientes de
estándares seguidos por el entorno.
Preparado para cambios durante el proyecto. Cierta resistencia a los cambios.
Reglas de trabajo impuestas internamente
(por el equipo de trabajo).
Reglas de trabajo impuestas externamente.
Flexibilidad en los contratos debido a la
respuesta de a cambios.
Existe un contrato prefijado.
El cliente es parte del equipo de desarrollo. El cliente interactúa en determinadas etapas.
Grupos pequeños menores a diez integrantes
y trabajando en el mismo lugar.
Grupos grandes y posiblemente distribuidos
trabajando en diferentes áreas.
Pocos artefactos. Más artefactos.
Pocos roles. Más roles.
Menos énfasis en la arquitectura de software. La arquitectura de software es esencial y se
expresa mediante modelos.
Fuente: [Canós, et al, 2003]

11
2.3 Ingeniería Web
La ingeniería web está relacionada con el establecimiento y uso de los principios científicos
de ingeniería, la gestión con enfoque sistémico disciplinado en aplicaciones basadas en web
de alta calidad. Desde la creación de internet a la actualidad, lo más importante en el
desarrollo de aplicaciones web, han sido las herramientas utilizadas para tal fin, la
construcción de aplicaciones web de gran escala se convierte en una actividad de múltiples
fases, involucran la especificación y diseño de la aplicación bajo una variedad de
perspectivas. [Pressman, 2002] La ingeniería Web propone el uso de técnicas de modelado
como WebML (Lenguaje de modelado WEB) misma que tiene al IFML como herramienta.
2.4 Programación Extrema
La ingeniería web, destaca como un método de desarrollo a la programación extrema (XP)
por la agilidad de desarrollo de software y su orientación a los datos. La programación
extrema se diferencia de las metodologías tradicionales principalmente por el énfasis en la
adaptabilidad e iteración con los usuarios. [Beck, 2002]
Los principios más importantes de la programación extrema son la:
• Simplicidad, es la base de la programación extrema, se simplifica el diseño para agilizar
el desarrollo y facilitar el mantenimiento, facilitar este proceso se factoriza del código;
• Comunicación, es muy importante y se la realiza de diferentes maneras, para los
programadores el código comunica mejor si es más simple, para con el cliente debe ser
fluida porque es parte del equipo de desarrollo, el cliente finalmente decide sobre las
características más importantes y debe estar disponible para resolver dudas;
• Retroalimentación, como el cliente es parte del equipo de desarrollo, su evaluación sobre
el estado de proyecto es a tiempo real. XP se caracteriza por realizar ciclos cortos que
generan resultados que retroalimentan y fortalecen su integración al software
minimizando los requerimientos no cumplidos. El código es fuente de retroalimentación
esto ayuda a los programadores a centrarse en los más importante;

12
• Valentía, para afrontar retos como, diseñar y programar para hoy y no para mañana,
condiciones para reconstruir, corregir código cuando sea necesario;
• Respeto, los miembros del equipo se respetan los unos a otros, porque los miembros no
pueden modificar programas que hacen que las pruebas existentes fallen, o que puedan
generar demoras para con sus compañeros, con la finalidad de lograr calidad y el diseño
óptimo para la factorización del código. [Beck, 2004]
La metodología XP realiza entregas pequeñas eso garantiza que en la última entrega se
concluye con el proyecto y minimiza el margen de error.
Figura 2.1: Programación extrema
Fuente: [Pastor, 2008]
2.4.1 Fase de Planeación
La planeación es una fase corta, donde el gerente, clientes y el grupo de desarrolladores
acuerdan el orden que deberán implementarse las historias de usuarios, incluido el plan de
entregas como detalla a continuación:
• Historias de usuario, el primer paso de cualquier proyecto que siga la metodología XP
es definir las historias de usuario con el cliente, las mismas tienen la finalidad que los
casos de uso pero con algunas diferencias. Consta de tres o cuatro líneas escritas por el
cliente en un lenguaje no técnico sin hacer hincapié en los detalles, no es necesario
comentar de algoritmos y diseños, su uso está orientado a la estimación de tiempos para
el desarrollo. Cuando llega el momento de implementar una historia de usuario, el cliente
y los desarrolladores se reúnen para concretar y detallar lo que tiene que hacer dicha

13
historia de usuario. Las historias de usuario se utilizan también para verificar que los
programas cumplan con lo especificado.
Tabla 2.2: Historia de usuario
Nro. 1 Nombre de la Historia de usuario
Nombre de la tarea
Usuario Nro. Iteración asignada
Prioridad (alta, media, baja) Riesgo en desarrollo (alta, media, baja)
Descripción del problema a resolver con la tarea
Fuente: [Wake, 2008]
• Plan de entregas, después de tener definidas las historias de usuario se debe crear un plan
de entregas (Release plan), donde se indiquen las historias de usuario que se crearan en
cada versión del programa y las fechas de sus publicaciones.
Generar un plan de entregas, implica que el cliente y los desarrolladores establezcan
tiempos de implementación ideales para las historias de usuario, la prioridad con la que
serán implementados y las historias que serán implementadas en cada versión.
Terminado el plan de entregas deja claro los siguientes aspectos: los objetivos que deben
cumplir (que son las historias que deben desarrollar en cada versión), el tiempo que se
tarda en su desarrollo y la publicación, el número de personas que trabajar en el desarrollo,
la forma de evaluación para determinar la calidad del trabajo realizado.
Tabla 2.3: Plan de entregas
I. Tarea Funcionalidad Fecha Indicador
1 Tarea 1 … …/…/…… …
• Iteraciones, todo el proyecto según XP debe dividir las iteraciones en aproximadamente
en 3 semanas. Al inicio de cada iteración el cliente debe seleccionar las historias de
usuario definidas en el plan de entrega. También se eligen las historias de usuario que no
pasaron el test de aceptación que se realizó a la conclusión de la iteración anterior. Las

14
historias de usuario elegidas son divididas en tareas que duran entre 1 a 3 días para
asignarlos a los programadores.
• Velocidad del proyecto, es la rapidez con la que se desarrolla el proyecto, su estimación
es sencilla, se debe contar el número de historias de usuario que se deben implementar
en una iteración, así se conocerá el cupo de historias que se pueden desarrollar en las
diferentes iteraciones. Usando la velocidad del proyecto se controla que todas las tareas
se pueden desarrollar en el tiempo que dispone cada iteración.
• Programación en pareja, recomienda la programación en parejas para incrementar la
productividad y la calidad del software desarrollado. Trabajo en pareja significa que los
dos programadores trabajan en el mismo equipo, donde uno de ellos hace hincapié en la
calidad de la función o método que se está implementando y el otro analiza si el método
o función es adecuado y si está bien diseñado. Así el equipo logra código y diseño de
calidad.
• Reuniones diarias, es necesario que los desarrolladores se reúnan diariamente y
expongan las dificultades o problemas, las posibles soluciones de forma conjunta. Esta
actividad debe ser fluida y todos deben tener voz y voto.
2.4.2 Fase de Diseño
• Diseños simples, la metodología sugiere conseguir diseños simples y sencillos. Hay que
procurar hacerlo todo lo menos complicado posible para conseguir un diseño fácilmente
entendible y desarrollable que a la larga costará menos tiempo y esfuerzo desarrollar.
• Riesgos, si surgen problemas potenciales durante el diseño, XP sugiere utilizar una pareja
de desarrolladores para que investiguen y reduzcan al máximo el riesgo que supone ese
problema.
• Funcionalidad extra, nunca se debe añadir funcionalidad extra al programa aun que se
piense que en el futuro será utilizada, la funcionalidad extra es un desperdicio de tiempo
y recursos.

15
• Refactorización, es mejorar y modificar la estructura de los códigos ya creados sin alterar
su funcionalidad, con la finalidad de procurar optimizar su función. Es muy común
reutilizar códigos ya creados y por ello es recomendable la refactorización.
• Tarjetas de clases, responsabilidades y colaboración (C.R.C.), permiten al programador
centrarse en el desarrollo olvidándose de los malos hábitos de la programación procesal
clásica.
Tabla 2.4: Tarjeta de clases, responsabilidades y colaboración
Nombre de la Clase (persona, evento, concepto, pantalla, reporte)
Responsables Colaboradores
Acciones que realizan sus atributos o eventos Clases con las que interactúa para realizar el
trabajo
2.4.3 Fase de Codificación
El cliente como parte del equipo de desarrollo cuenta con una presencia indispensable en las
distintas fases de XP, el momento de codificar una historia de usuario la presencia del cliente
es importante porque son los que crean las historias de usuario y negocian tiempos para la
implementación.
Antes del desarrollo de una historia de usuario el cliente debe especificar detalladamente lo
que esta hará y tendrá que estar presente cuando se realicen los test de verificación para
determinar si comportan de acuerdo a la historia de usuario.
La codificación debe hacerse atendiendo a estándares de codificación, esta buena práctica
mantiene el código consistente, facilitando la comprensión y escalabilidad. XP recomienda
la programación en pareja para lograr un código eficiente y de calidad.
Se puede dividir la funcionalidad que debe cumplir una tarea a programar en pequeñas
unidades, de esta forma se creará los test para cada unidad así poco a poco se logrará que el
desarrollo cumpla con todos los requerimientos especificados.

16
La metodología en esta etapa hace énfasis en el uso de repositorios de código donde las pareja
de programadores publicaran los códigos implementados y/o las correcciones junto con los
resultados de los test, de esta manera los otros grupos de desarrolladores que necesiten
trabajar con este código siempre contarán con la última versión testeada, de esta manera se
mantendrá un código consistente y estandarizado.
Se impulsa el desarrollo colectivo donde todos los programadores están relacionados con
todas las tareas, donde cualquiera puede modificar, ampliar una clase o método de otro
programador si es necesario y actualizar el código en el repositorio. Permitir al resto de los
programadores que realicen cambios en el código no supone riesgo porque, el nuevo código
a ser publicado debe pasar los mismos test de funcionamiento anterior.
La optimización del código siempre se debe dejar para el final, se debe concentrar los
esfuerzos en hacer que funcione correctamente, más adelante se podrá optimizar.
2.4.4 Fase de Pruebas
La finalidad de esta fase es comprobar el funcionamiento del código para que sea
implementando, XP recomienda, crear las aplicaciones que permitan realizar los test en un
entorno de desarrollo específico de prueba, someter a test las distintas clases omitiendo los
métodos triviales.
Se deben crear los test que pasarán los códigos antes de ser implementados, los test no deben
tener dependencia con el código a evaluar, se debe crear el test abstrayéndose del futuro
código, de esta forma aseguramos la independencia del test respecto al código que evalúa. El
uso del test adecuado permite detectar la necesidad de refactorización, esta acción permite
un cambio en la estructura sin alterar la funcionalidad.
Lo antes mencionado permiten evaluar las distintas tareas en las que han sido divididas un
historia de usuario, asegurar el funcionamiento significa la creación de test de aceptación,
este material sirve para comprobar que las distintas historias de usuario comportan de acuerdo
a lo esperado.

17
Los resultados obtenidos por la aplicación de un test a un código deben ser subidos al
repositorio para mantener la última versión, ningún código debe ser subido o actualizado sin
su test superado. A continuación se presenta las fases para el desarrollo de software de XP.
Figura 2.2: Fases e iteraciones de la programación extrema
2.5 Lenguaje de Modelado Web
El lengua de modelado Web (WebML) es una técnica de modelado que permite diseñar el
domino del modelo (para establecer el diseño de la base de datos), establece el modelo de
hipertexto (con unidades) y el modelo de presentación (ayuda a definir el entorno visual
desde el punto de vista del usuario).
WebML, es una técnica de modelado que inspiro a WEBRATIO el desarrollo del lenguaje
de modelado de flujos interactivos estándar (IFML) esta herramienta de modelado cumple
con la filosofía del WEBML, para el modelado de aplicaciones WEB.
WebRatio empresa desarrolladora del IFML cambia los nombres de elementos y
representación visual dentro los proyectos Web con el fin de cumplir con la notación IFML.
El WebML, trabaja con unidades contenedoras, flujos, vista, operaciones, sesiones,
componentes y otros. A continuación se presentan las unidades contenedoras del WebML y
sus pares en IFML

18
Tabla 2.5: Unidades de contenido del WebML con la herramienta IFML.
Área Página alternativa Página master
Fuente: [WEBRATIO, 2015]
También se tiene las unidades de vistas del WebML con su herramienta IFML, estas son de
tipo detalle (simple, múltiple), lista (simple, seleccionable, jerárquica, recursiva jerárquica),
formularios (simple, múltiple), mensaje, calendario, solo funcionan dentro de un contenedor.
Tabla 2.6: Unidades de vista WebML con la herramienta IFML.
Detalles Detalles múltiples Lista simple Lista
Lista de selección Lista jerárquica Lista jerárquica recursiva
Formulario simple Formulario múltiple Mensaje (de unidades operación)

19
El WebML con su herramienta IFML cuenta con unidades de operaciones que permiten
trabajar con las operaciones básicas de la base de datos, estas unidades permiten realizar
altas, bajas y modificaciones, también se considera la representación de procedimientos con
el gestor de base de datos.
Tabla 2.7: Unidades de operación WebML con la herramienta IFML.
Altas Bajas Modificaciones Nombre
WebML con su herramienta IFML prevé la interacción de las unidades de vista con las
unidades de operaciones por medio de flujos de información estos flujos pueden ser de tipo
navegación normal, automática y transporte, también estos flujos pueden responder según el
evento pudiendo ser flujos con respuestas positivas o flujo con respuesta de error.
Tabla 2.8: Unidades de flujo WebML con la herramienta IFML.
Normal Automática Transporte
OK KO Especifica información
WebML con su herramienta IFML también prevé el trabajo con sesiones para que los
usuarios accedan al sistema de acuerdo a los perfiles definidos por los roles y funciones en
los estudios anteriores. A continuación son presentadas en la siguiente tabla.

20
Tabla 2.9: Unidades de sesión WebML con la herramienta IFML.
Inicio de sesión Fin de sesión
WebML con la herramienta IFML considera a las unidades de componentes que permiten
hacer la selección de registro, consultas y proceso con correos electrónicos.
Tabla 2.10: Unidades de componente WebML con la herramienta IFML.
Selecciones Consultas avanzadas E-mail
Finalmente WebML con la herramienta IFML cuenta con las unidades de servicios que
permiten generar servicios para las unidades de componentes. Los servicios pueden estar en
funcionamiento, parado y es posible conocer el estado de cada servicio.
Tabla 2.11: Unidades de servicios de componentes WebML con la herramienta IFML.
Respuestas Servicio operando Servicio cancelado Estado servicio
En conclusión el IFML funciona y aplica la filosofía del WebML y es útil para el modelado.

21
2.5.1 Modelo de Estructura
El modelo de estructura del WebML es representado con el modelo de dominio en el IFML
y este modelo es una extensión del modelo Entidad Relación, que no implica un cambio
trascendental para WebML, los elementos de este modelo son las entidades, atributos y
relaciones y cardinalidad, en ese sentido el IFML tiene la capacidad de generar la estructura
física de la base de datos en gestores libres o con licencia de propietario.
Figura 2.2: Modelo de estructura WebML con la herramienta IFML.
• Entidades, son las estructuras básicas del modelo de estructura WEBML. Cada entidad
se asocia a un conjunto de objetos del mundo real cuyas propiedades se describen por
medio de atributos. Se denotan por un rectángulo con el nombre de la entidad en el tope
seguido de una lista de atributos.
• Atributos, se utilizan para representar las propiedades del mundo real que se manejan en
el sitio web. Un atributo tiene un tipo, escogido por el desarrollador en el momento de
definir los tipos WEBML.
• Relaciones, representan las conexiones de entre las entidades. La relación más simple es
la binaria, a través de la cual se conectan dos entidades. Las relaciones que envuelven
más de dos entidades son llamadas relaciones n-arias y también son soportadas por el
WEBML.
2.5.2 Modelo de Hipertexto
El modelo de hipertexto permite diseñar el modelo de hipertexto con unidades de
contenedoras, vistas, operaciones, flujos, sesiones, componentes y servicios de componente.
El sistema a desarrollar puede ser descrito por uno o más modelos de hipertexto (por ejemplo,

22
distintas vistas de sitios para diferentes tipos de usuarios), la definición de las rutas de
navegación.
El siguiente diagrama está especificado con el IFML, cuenta con una página contenedora.
Que despliega un lista de libros esta página permite adicionar información de la tienda que
debe pasar por un módulo de guardado este módulo puede tener dos resultados uno positivo
y otro negativo que se informa mediante un mensaje, algo similar ocurre con la eliminación.
Figura 2.3: Modelo de hipertexto IFML.
2.5.3 Modelo de Presentación
El modelo de presentación de WEBML, describe los aspectos visuales de las páginas. Este
modelo es interesante, ya que permite “vestir” a un modelo de hipertexto para obtener páginas
Web con la presentación deseada y la vista adecuada para cualquier tecnología.
Cabe notar que IFML no cubre el modelado de la presentación (como la vista, el estilo) del
front-end (del lado del cliente) y tampoco toma en cuenta las especificaciones de gráficos
bidimensionales y tridimensionales basados en computadoras, juegos de video y otras
aplicaciones de alta interactividad. IFML está orientado principalmente a aplicaciones de
negocios de uso intensivo de datos.
Por lo tanto el IFML es una herramienta completamente compatible con los conceptos del
WebML y serán aplicados para el modelado del sistema. El producto IFML está orientado a

23
modelar y representar los contenidos de las interfaces de usuario, patrones de navegación,
eventos de usuario y su interacción, permite establecer la lógica de negocios.
En conclusión el lenguaje IFML y la plataforma de desarrollo model-driven, inspirado en la
filosofía WebML, son absolutamente compatibles. El estándar y la herramienta son
ampliamente aceptados en grandes industrias de Europa y Estados Unidos, así como en
Latinoamérica y Asia.
El enfoque ha ganado una amplia aceptación gracias a las pocas barreras de aprendizaje para
los nuevos técnicos. Las destrezas básicas de modelado son enseñadas generalmente en 6
horas de capacitación, y el programa completo para profesionales certificados requiere un
total de 8 días. [WEBRATIO, 2002]
2.6 Modelo Entidad Relación
El modelo entidad relación (E-R), es solo y exclusivamente una técnica para el diseño de
esquemas que posteriormente debemos de implementar en un gestor de bases de datos
(GDBD). Los elementos más relevantes son las entidades, atributos, relaciones, es
considerado el modelo lógico del sistema.
Figura 2.4: Modelo entidad relación.
2.7 Modelo Relacional
El modelo relacional (MR), es una forma de representación de la organización de la
información que se almacenará en una base de datos. Se trata de un modelo teórico
matemático que proporciona los elementos básicos de modelado (entidades, las relaciones),

24
incluye un conjunto de operadores (definidos en forma de un álgebra relacional) para su
manipulación, evitando las ambigüedades posibles. [Silberschatz, 2002]
En este modelo, la información se representa en forma de relaciones (tablas), donde cada fila
de la tabla se interpreta como una relación ordenada de valores (un conjunto de valores
relacionados entre sí). Formalmente, una relación se define como un conjunto de n - tuplas;
donde una n - Tupla se define a su vez como un conjunto ordenado de valores atómicos (esto
es, no divisibles ni descomponibles en valores más “pequeños”.
Figura 2.5: Modelo relacional
Fuente: [phpMyAdmin, 2002]
El modelo relacional permite a los usuarios incorporar restricciones, las principales son:
• Clave primaria, hace que los atributos con clave primaria sean únicos y obligatorios;
• Unicidad, impide que los valores de los atributos puedan repetirse;
• Obligatoriedad, prohíbe que el atributo no tenga ningún valor;
• Integridad referencial, prohíbe colocar valores en una clave externa que no estén
reflejados en la tabla donde ese atributo es clave primaria;
• Regla de validación, condición que debe de cumplir un dato para ser actualizado.
2.8 Conversión del Modelo Entidad Relación
Conversión del dominio de modelo a modelo entidad relación, para realizar esta tarea se
trabajara con el IFML permite desarrollar el dominio del modelo mismo que es una extensión
del modelo entidad relación, por lo tanto migrar del domino del modelo al modelo entidad

25
relación no representa dificultad, porque existen las librerías que hacen posible este proceso
y la nomenclatura es completamente compatible para su tratamiento. Conversión de modelo
entidad relación a modelo relacional, este proceso implica la aplicación de algunas reglas que
se detallan a continuación en la siguiente imagen
Tabla 2.12: Equivalencia de modelo ER y MR para su conversión
Modelo entidad relación Modelo relacional
Entidad Tabla
Atributo Columna/Campo
Identificador Único Clave Primaria
Relaciones N:M
Nueva tabla con clave primaria la concatenación de las claves de las
entidades que la forman
Relaciones 1:M
Transformar la relación en una tabla si no todos los elementos de la
entidad que participa con muchos tienen asociado un elemento de la
entidad que participa con uno. Propagando la de 1 en la de muchos.
Relaciones 1:1
Si todos los elementos de la entidad de muchos tienen asociado uno
de la entidad de uno
Fuente: [Silberschatz, 2002]
2.9 La Gestión por Resultados
En la última década, las organizaciones estatales y privadas, se encuentran en el debate sobre
la adopción de nuevos paradigmas de gestión que permita la producción de bienes y/o
servicios con mayor efectividad y transparencia. Ese debate identifico que el aspecto central
de la gestión es la generación de “valor” de las acciones o actividades ejecutadas por las
organizaciones. Está claro que la generación de valor público no es la principal motivación
de las organizaciones privadas cuyos modelos de gestión tienen enfoque diferente.
La gestión por resultados (GxR) puede definirse como el modelo que propone la
administración de los recursos (públicos o destinados a generar valor público) centrada en el
cumplimiento de las acciones estratégicas definidas en el plan en un período de tiempo

26
determinado. De esta forma, permite gestionar y evaluar la acción de las organizaciones con
relación a las políticas definidas para atender las demandas de la sociedad, reflejadas a través
de acuerdos de desempeño. [Makón, 2000]
Este enfoque implica un cambio sustancial en la modalidad de gestión: la planificación, la
asignación presupuestaria, el seguimiento, el monitoreo, la evaluación, y la ejecución, que
tradicionalmente ha estado orientada principalmente a ejecutar actividades si visión de
resultados orientada al gasto sin integración con los objetivos. Se entiende por gestión a la
administración de recursos de una entidad para alcanzar sus objetivos.
El concepto de administración, es la integración de los procesos de planeación, organización,
dirección, control y retroalimentación. Por lo tanto la gestión de proyectos no es más que la
orientación del proceso administrativo hacia proyectos puntuales, donde el proyecto es la
conjunción de recursos que plantean la solución a un problema concreto.
2.10 La Gestión de Proyectos
La gestión de proyectos (GP) es la conjunción de actividades, recursos (financieros, técnicos,
humanos, etc.) que apuntan a alcanzar en los plazos previstos y con un presupuesto dado,
objetivos claramente definidos y que son la respuesta o solución ante un problema
identificado. Independientemente de su alcance, nivel de complejidad o incertidumbre los
proyectos pasan por tres fases para su formulación y posterior evaluación. [Albis, 2013]
Figura 2.6: Fases de la gestión de proyecto
Fuente: [Albis, 2002]

27
2.10.1 Fase de Pre inversión
En la etapa de pre inversión es en donde se identifica, formula y evalúa el proyecto, es decir,
es donde se define la factibilidad del mismo. La etapa de pre inversión se divide en tres sub
etapas que son: identificación, formulación y evaluación.
A medida que se avanza sobre esta información, la incertidumbre baja pero se comienza a
incurrir en algunos costos que hacen parte del desarrollo del proyecto. [Albis, 2013]
En la gestión de proyectos en la fase de pre inversión, se deben definir los componentes y las
actividades y para cada uno de ellos se deben establecer los indicadores pertinentes, de tal
manera que el proyecto sea sujeto de seguimiento. También se realiza el presupuesto de
recursos financieros y establece un techo presupuestario máximo, asignando recursos a los
componentes y actividades.
2.10.2 Fase de Inversión
En la inversión o ejecución se realiza la implantación del proyecto. Se genera el cronograma
de inversiones y de trabajo. En esta etapa se debe comparar lo presupuestado y lo ejecutado
para tener el control del proyecto. Se ejecutan las inversiones y se implementa la tecnología
escogida basados en una óptima gestión del recurso humano y con un cuadro organizacional
que permita la administración integrada del proyecto para poder darlo a luz, siendo capaz de
empezar la producción del bien o servicio para el cual fue concebido. El gerente del
proyecto debe estar atento a las necesidades adicionales que surjan durante la
implementación del proyecto. [Albis, 2013]
En la gestión de proyecto en la fase de inversión, los componentes y actividades son sujetos
de verificación usando los indicadores en función de la frecuencia de medición, donde la
línea base es el punto de partida y la meta es el objetivo ya sea de manera ascendente o
descendente. También se ejecutan recursos financieros en función del presupuesto asignado
a las actividades, donde la regla básica es gastar solo lo presupuestado.

28
2.10.3 Fase de Post inversión
Esta etapa es la institucionalización del proyecto. Ya existe el bien o servicio cubriendo la
necesidad, el objetivo fue cumplido. Sin embargo esto no significa que el gerente deba bajar
la guardia sobre el control; por el contrario, debe estar atento a los cambios financieros y de
tiempo, a la calidad, los impactos socioeconómicos, ambientales y a la operación misma del
proyecto. [Albis, 2013]
2.10.4 Medios y Procesos
Para la gestión de un proyecto es necesario establecer componentes, a los mismos se les debe
asignar actividades. Los dos últimos requieren de presupuestos e indicadores para realizar el
seguimiento y el monitoreo.
Los medios, son los recursos económicos son limitados para la ejecución de un proyecto, por
ello es necesario realizar un presupuesto adecuado. Los indicadores son unidades que nos
permiten realizar el seguimiento y el monitoreo del proyecto.
• El presupuesto, el presupuesto constituye una previsión de gastos e ingresos a gestionar
durante un período de tiempo determinado, al que se denomina ejercicio presupuestario.
Recoge un conjunto ordenado de decisiones financieras, sobre la asignación de los gastos
para el cumplimiento de diversos fines y los ingresos con que financiarlos, dando
respuesta a una serie de cuestiones. Es un plan de acción dirigido a cumplir un objetivo,
expresada en valores y términos financieros que debe cumplirse en determinado tiempo
y bajo ciertas condiciones previstas.
• Los Indicadores, los indicadores son una herramienta que muestra indicios o señales de
una situación, actividad o resultado. Los indicadores proporcionan información de
manera simple, precisa y sin ambigüedad. Las características más importantes de un
indicador son: la denominación, definición, fórmula de cálculo, unidad de medida,
información línea base, la meta, el sentido (ascendente, descendente) y la frecuencia de
medición.

29
Procesos, son la gestión de proyectos, son las etapas destinadas a controlar la correcta
ejecución del proyecto las que se toman en cuenta para efectos del presente proyecto son:
• Seguimiento, es la acción mediante la cual se releva, recolecta y almacena información
sobre proyectos, programas y/o planes que tienen la característica dinámica. Algunos
autores utilizan indistintamente los términos seguimiento y monitoreo para definir el
mismo proceso. Sin embargo, en el marco de los alcances del presente trabajo, se
diferenciarán ambos conceptos aunque estén íntimamente vinculados.
• Monitoreo, es un proceso o subsistema del ciclo de gestión que se encarga de analizar los
procesos, productos, resultados y otros, acompañándolos para posibilitar su ajuste en
términos de su ejecución correcta y conclusión óptima o aceptable. El monitoreo, ayuda
(proactivamente) a conducir programas o proyectos y permite garantizar la calidad,
eficacia y sostenibilidad de los mismos. Los datos obtenidos permiten conocer los
avances de los proyectos y programas e indican cuando la forma de conducción requiere
cambios. Además, arrojan insumos para la planificación de nuevas períodos de
programas o proyectos (retroalimentación).
2.11 Tecnología de software
Las herramientas de software que se plantean para el desarrollo del proyecto son necesarias
para el análisis del modelo, diseño e implementación.
Base de Datos, se considera como una serie de datos organizados y relacionados entre sí, los
cuales son recolectados y explotados por los sistemas de información de una empresa o
negocio en particular. Un sistema de bases de datos sirve para integrar los datos. Los
componentes de un sistema gestor de base de datos (SGDB) son los siguientes elementos:
hardware, software, datos, usuarios. Para el proyecto se utilizará como SGDB al MySQL.
• MySql, gestor de bases de datos, importante por su gratuidad, donde es destacable su alto
grado de estabilidad, seguridad, escalabilidad, multiplataforma y compatibilidad con los
lenguajes de programación. La sintaxis que utiliza esta gestor es la del SQL.

30
• phpMyAdmin, interfaz de administración de base de datos, herramienta que se conecta
al gestor de base de datos MySql, cuenta con una interfaz versátil, permite definir y
administrar recursos del gestor de base de datos y diseñar y generar nuevas estructuras
de almacenamiento de información.
Herramientas de programación, los lenguajes de programación se constituyen en
herramientas de desarrollo estos permiten construir instrucciones que puede interpretar un
computador del lado del cliente y del lado del servidor, para el desarrollo de este proyecto se
utilizaran los lenguajes PHP, JavaScript, Jquery, Jquery Validate, RBAC y finalmente un
complemento de maquetación CSS y HTML.
• PHP, lenguaje de programación de uso general PHP es un acrónimo recursivo que
significa Hipertexto Pre-proceso, donde el código se ejecuta del lado del servidor,
diseñado para el desarrollo web de contenido dinámico. Es compatible con las sentencias
HTML, es altamente compatible con hojas de estilo CSS, JavaScript, funciona muy bien
con librerías Jquery y es absolutamente compatible con RBAC.
• JavaScript, es un lenguaje desarrollado por la empresa SUN, sus aplicaciones permiten
la ejecución de programas java en el lado del cliente es de carácter multipropósito,
permite generar objetos HTML e interactúa con hojas de estilo CSS y etiquetas HTML.
• Jquery, es considerada un framework, desarrollada con CSS y JAVASCRIPT permiten
agilizar procesos como la validación de formularios para el ingreso de información en la
base de datos, características estéticas de presentación.
• Jquery validate, es un plugin, desarrollado para la validación de formularios del lado del
cliente combina características CSS y JavaScript con las etiquetas de los formularios del
HTML.
• RBAC, es el control de acceso basado en roles desarrollado en php, ofrece una alternativa
más segura al modelo de súper usuario del tipo "todo o nada". Privilegio mínimo significa
que un usuario dispone exactamente de la cantidad de privilegios necesaria para realizar
un trabajo. La flexibilidad en la configuración de los roles posibilita una variedad de

31
políticas de seguridad. Algunos de los beneficios que RBAC puede ofrecer, en lugar de
cualquier otro método de Control de Accesos pueden son: Administración simplificada
de sistemas, productividad organizacional mejorada, reducción en tiempo muerto de
nuevo empleado, seguridad e integridad mejoradas de sistemas y conformidad reguladora
simplificada.
Herramientas de maquetación, son herramientas que permiten codificar la forma y estilo en
la que se presentara el sistema para interactuar con el usuario final, las que se aplicaran son
HTML y las CSS.
• CSS, son hojas de estilo que se aplican a las etiquetas HTML, puede interactuar con el
PHP, su función es dar formato y estética en la presentación de información de las páginas
WEB, su aplicación está orientada a objetos.
• HTML, lenguaje de marcas de hipertexto, es un estándar que sirve de referencia para la
elaboración de páginas web, define una estructura básica y un código (denominado
código HTML) para la definición de contenido de una página web, como texto, imágenes,
videos, entre otros. Es un estándar a cargo de la W3C, organización dedicada a la
estandarización de casi todas las tecnologías ligadas a la web, sobre todo en lo referente
a su escritura e interpretación.

Capítulo III
Marco Aplicativo

32
3. Marco Aplicativo
3.1 Introducción
El análisis y diseño para el software utiliza conceptos de la Gestión por Resultados (GxR),
que definen la funcionalidad del sistema, en la lógica donde la cadena de procesos, productos,
efectos e impactos tienen a los indicadores por excelencia como herramientas de medición
para cada nivel permitiendo el seguimiento y monitoreo. Se entiende por gestión a la
administración de recursos de una entidad para alcanzar sus objetivos. El concepto de
administración, es la integración de los procesos de planeación, organización, dirección,
control y retroalimentación. Por lo tanto la gestión de proyectos no es más que la orientación
del proceso administrativo hacia proyectos puntuales, donde el proyecto es la conjunción de
recursos que plantean la solución a un problema concreto. Diseñar e implementar un sistema
de seguimiento y monitoreo de proyectos con orientación hacia resultados, implica aplicar la
gestión de proyectos tal que garantice la medición de la ejecución de la cadena de procesos,
productos, efectos e impactos que se enfoquen en cumplimientos y no solo en avances de
actividades o ejecución de gastos.
Figura 3.1: Relacionamiento de la gestión de proyectos con la gestión por resultados
Fuente: [Aruquipa: 1993]

33
Para el desarrollo del sistema de información planteado en el presente proyecto, se aplicaran
metodologías probadas y validas por la ingeniería de software, mismas que se apoyan en
técnicas que permiten el desarrollo de modelos lo donde algunos cuentan con herramientas
para el diseño, para el desarrollo son necesarios los lenguajes de programación combinados
con código de maquetación y de esta manera finalmente obtener él sistema para su
implementación en la institución beneficiaria.
La ingeniería de software hace referencia a las metodologías de desarrollo tradicional y
metodologías de desarrollo ágil, para efectos de desarrollo este proyecto se adoptara el uso
de la metodología programación extrema (XP) es una metodología que cuenta con cuatro
fases básicas para el desarrollo de software de manera ágil, esta se caracteriza por su alto
grado de flexibilidad y relación con los usuarios finales hecho que da lugar al desarrollo de
software exitoso, el desarrollo del presente trabajo es en torno a esta metodología.
Sin embargo es necesario apoyar la metodología XP con técnicas para su presentación y
formalización es así que se aplicaran las técnicas WebML con su herramienta IFML (por lo
tanto se utilizarán unidades IFML con la filosofía WebML), también se usaran las técnicas
de modelado de base de datos entidad relación (ER) para el diseño lógico del sistema y
finalmente se aplicara la técnica de modelado relacional para obtener el modelo de base de
datos físico.
Para el desarrollo del sistema se utilizaran herramientas de programación como PHP que es
un lenguaje multipropósito que se caracteriza por generar código HTML capaz de inter actuar
con lenguajes como JavaScript, librerías Jquery y sus extensiones validate, con la finalidad
de obtener una presentación la estética se usaran hojas de estilo CSS. Para administrar a los
usuarios se utilizara el RBAC.
Para el desarrollo del sistema de información es necesario aplicar conceptos de la gestión por
resultados (GxR), los que permiten establecer el entorno de aplicación en la gestión de
proyectos (GP) en función de sus medios y procesos mismos que nos brindaran lineamientos
necesarios y suficientes para la obtener de resultados. La gestión proyectos cuentan con las

34
fases de Pre Inversión, Inversión y Post Inversión, este proyecto concentra sus esfuerzos en
la fase de inversión como se estableció en los alcances.
Para determinar la forma y el orden de la aplicación de todo lo antes mencionado se presenta
la siguiente figura:
Figura 3.2: Combinación metodología, técnicas y herramientas
Fuente: [Elaboración propia]
3.2 Desarrollo con la Metodología XP
La programación extrema es una metodología de desarrollo de software ágil, la misma cuenta
con cuatro fases: la planificación, diseño, codificación y pruebas. Las fases antes
mencionadas serán fortalecidas con la aplicación de técnicas y herramientas
La etapa de planificación se inicia con la identificación de roles y funciones, luego se
realizaran las historias de usuario, donde las mismas serán planificadas para posteriormente
ser agrupadas y desarrolladas en iteraciones.
La etapa de diseño considera a los resultados de la planificación y toma los conceptos de la
gestión por resultados para definir las tarjeras de colaboración, con las mencionadas se

35
diseñara el modelo de dominio, como este modelo es una extensión del modelo entidad
relación servirá para obtener el modelo relacional, finalmente se diseñara el modelo de
hipertexto donde se define la funcionalidad y el comportamiento del sistema según el modelo
de dominio.
La etapa de codificación toma como información línea base a los modelos de bases de datos
y el modelo de hipertexto para iniciar la ejecución del plan de entregas tomando en cuenta el
modelo de presentación seleccionado por la institución. Se desarrolla la codificación con el
gestor de base de datos MySql y los lenguajes de programación y medios de maquetación
donde el resultado son las pantallas del sistema de información.
Finalmente se realizan las pruebas de aceptación según las iteraciones donde se comprueba
que las historias de usuarios sean resueltas y sean de satisfacción del cliente.
3.3 Fase de Planeación
Es la fase donde se identifican a los usuarios, sus roles y funciones, se asimilan los procesos
y forma de tratamiento de la información, todo lo antes mencionado se almacena en las
historias de usuario, obtenido este material se procede a planificar y priorizar las entregas
estableciendo un orden por iteraciones.
3.3.1 Identificación de Roles y Funciones
El colegio de administradores de empresas (CADELP) es una institución colegiada muy bien
estructurada de manera jerárquica. A continuación se presenta una descripción:
• Directorio, es la instancia máxima para la toma de decisiones en el colegio de
administradores, el mismo es elegido democráticamente por los socios. Es la única
instancia que puede tomar la decisión de llevar adelante o no un proyecto con la finalidad
de beneficiar a los socios.
• Presidente, es la máxima autoridad del directorio, se encarga de hacer cumplir las
decisiones emitidas por el directorio respecto de los proyectos y otras resoluciones. Su

36
función es la de asignar responsabilidades y controlar que las directrices de sus proyectos
se mantengan y se logren desde el punto de vista de procesos.
• Gerente de proyecto, responde sobre sus acciones y decisiones al presidente de
CADELP, se caracteriza por su conocimiento y habilidad técnica en el campo especifico
de sus competencias respecto del proyecto (experto), tiene la habilidad política de influir
en el equipo que acompaña en el desarrollo del proyecto, donde su objetivo principal es
lograr resultados a partir del mismo en función de los procesos.
• Director administrativo, responde sobre sus decisiones al presidente, se caracteriza por
el conocimiento y habilidad técnica para influir en los gerentes de proyecto, respecto de
los medios y procesos para llevar adelante el proyecto.
3.3.2 Historias de Usuario
Conocidos los roles y funciones de los usuarios del sistema se hacen las reuniones donde se
llenan las historias de usuario (HU), donde se determinan las necesidades de información.
Consta de tres o cuatro líneas escritas por el cliente en un lenguaje no técnico sin hacer
hincapié en los detalles. A continuación se presentan las historias obtenidas en la institución
después de las reuniones, mismas son elaboración propia.
La siguiente historia de usuario describe cual el rol del directorio respecto de los proyectos.
Tabla 3.1: Historias de usuario para el desarrollo del proyecto
Nro. 01 Aprobación de proyectos
Tarea : Vista de reporte de proyecto
Usuario : Directorio Iteración : 01
Prioridad: Baja Riesgo : Bajo
El directorio se encarga de autorizar la etapa de inversión de proyectos nuevos y otras
actividades a favor de la institución. Si algún proyecto es aprobado entonces la ejecución del
mismo es encomendada al presidente de la institución. El directorio debe tener acceso a la
información.

37
La siguiente historia de usuario describe cual el rol del presidente respecto del proyecto.
Nro. 02 Proyectos aprobados
Usuario : Presidente Iteración : 01
Institucionalmente soy responsable de la ejecución de la decisión del directorio de implementar
algún proyecto. Me encargo de asignar responsabilidades a las personas que se harán cargo del
proyecto. Requiero de acceso a la información de los proyectos para seguimiento y monitoreo.
A continuación se tiene a la historia del staff respecto del proyecto.
Nro. 03 Registrar, eliminación y modificación de proyecto
Usuario : Directorio, presidente y director administrativo Iteración : 01
Una de las funciones del staff es validar y fiscalizar los medios y procesos que estima el gerente
de proyecto para la ejecución del proyecto por lo tanta deben leer de los datos de los proyectos.
Con esta información se puede ordenar el alto o ajustes del proyecto.
A continuación se tiene a la historia del gerente de proyecto respecto del registro de proyecto.
Nro. 04 Registro de proyecto
Tarea : Alta de proyecto
Usuario : Gerente de proyecto Iteración : 01
Prioridad: Alta Riesgo : Bajo
Me encargo de programar los proyectos nuevos, se requiere de la siguiente información: el
título del proyecto, objetivo principal, beneficiarios, las fechas de inicio y fecha fin,
presupuesto en bolivianos, especificar la contraparte técnica, asignar a un responsable. La
programación se hace con información resultante de la etapa de pre inversión de proyectos.

38
Se tiene la historia donde el gerente de proyecto debe cancelar un proyecto.
Nro. 05 Descartar y ajustar un proyecto
Tarea : Eliminación y modificación de proyecto
Prioridad: Alta Riesgo :Medio
Yo puedo informar sobre las causas y aspectos que justifican la baja de un proyecto y/o
describir las razones por las cuales ya no se hará un seguimiento y/o monitoreo. También puedo
modificar el proyecto, recibir sugerencias del presidente o directorio. Solo son posibles las
operaciones en la fase de programación.
La historia describe que hace el staff respecto de componentes del proyecto.
Nro. 06 Registro, ajuste y borrado de componente
Tarea : Vista de componente
Prioridad: Medio Riesgo : Bajo
Los usuarios de esta historia no realizan las operaciones de alta, baja y modificación. Ellos
deben tener acceso a toda la información de los componentes del proyecto, para analizar la los
elementos y determinar necesidad de ajustes. Acción es válida solo en la fase de programación.
La historia describe que hace el gerente de proyecto respecto de los ajustes del proyecto.
Nro. 7 Registro de componente de proyecto
Tarea : Alta de componente
Prioridad: Alto Riesgo : Alto
Soy el encargado del registro de componentes de un proyecto, cada componente cuenta con un
conjunto con las actividades. Un componente cuenta con una descripción, las fechas de inicio
y fecha de fin. Cada componente debe estar definido entre la fecha de inicio, fin del proyecto.
Solo se pueden adicionar componentes en la fase de programación del proyecto.

39
Esta historia es del ajustes y borrado de componente del proyecto con el gerente de proyecto.
Nro. 8 Ajuste y borrado de componente de proyecto
Tarea : Baja y modificación de componente de proyecto
El ajuste del componente en proyecto sin actividades implica restricciones de proyecto, si tiene
actividades entonces se requiere restricciones de actividad y proyecto. Eliminar un
componente de proyecto implica perder los indicadores de producto y las actividades.
Esta historia es del registro, ajustes y borrado de componente del proyecto con los usuarios.
Nro. 9 Registro, eliminación y ajustes de actividad de componente
Tarea : Vista de reporte de actividades
Prioridad: Medio Riesgo :Medio
Los usuarios de esta historia no son los responsables de la información de actividad del
componente de proyecto, pero deben contar con acceso a la información del proyecto.
Esta historia es del ajustes y borrado de componente del proyecto con el gerente de proyecto.
Nro. 10 Registro de actividad de componente
Tarea : Alta de actividad de componente
Una actividad debe contar con: denominación, fecha de inicio y fin, consideraciones y
responsable. En la fase de programación la actividad debe estar entre las fechas de inicio y fin
de su componente. En la fase de inversión la actividad puede darse de alta en:
- Si componente no inicio, la actividad están entre fechas de inicio y fin de componente;
- Si el componente inicio, la actividad estarán entre la fecha actual y la fecha fin de
componente.
Solo se puede registrar actividades en las etapas de programación e inversión.

40
Esta historia refleja el borrado de componente de proyecto respecto del gerente de proyecto.
Nro. 11 Eliminación de actividad
Tarea : Baja de actividad de componente
Me encargo de la eliminación de una o varias actividades de un componente de proyecto. La
eliminación de una actividad en la fase de programación no tiene restricciones. Sin embargo
la baja tiene tres consideraciones a tomar en cuenta:
- Si el componente no inicio, la baja no representa dificultad;
- Si el componente inicio y la actividad no inicio entonces la baja no representa dificultad;
- Si el componente inicio y la actividad inicio la baja no es posible.
Este proceso solo es posible en las fases de programación, inversión.
Esta historia refleja al gerente de proyecto en la eliminación de componente de proyecto.
Nro. 12 Ajustes de actividad
Tarea : Modificación de actividad
Me encargo de la eliminación de una o varias actividades de un componente de proyecto. La
eliminación de una actividad en la fase de programación no tiene restricciones. Sin embargo
la baja en etapa de inversión tiene tres consideraciones a tomar en cuenta:
- Si el componente no inicio, la baja no representa dificultad;
- Si el componente inicio y la actividad no inicio entonces la baja no representa dificultad;
- Si el componente inicio y la actividad inicio la baja no es posible.
Este proceso de eliminación solo es posible en las fases de programación, inversión.
En la siguiente historia se refleja al staff de la institución respecto de los indicadores de
efecto y producto tomando en cuenta a los puntos de control o hitos que corresponden a cada
indicador.

Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp

Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp

Similar a Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp (20)

Último

Último (20)

Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp