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.

Capítulo I

Marco Referencial

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.

Capítulo II

Marco Teórico

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 … …/…/…… …

Fuente: [Wake, 2008] • 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

Fuente: [Wake, 2008] 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 extremaFuente: [Wake, 2008]

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. Fuente: [WEBRATIO, 2015]

• 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. Fuente: [WEBRATIO, 2015]

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. Fuente: [WEBRATIO, 2015]

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.

41

Nro. 13 Registro, eliminación, modificación de indicador de efecto o producto e hito

Tarea : Vista de reporte de indicadores de efecto o producto



Los usuarios de esta historia no realizan estas operaciones. Para el seguimiento y monitoreo

del proyecto, en el modelo de gestión por resultados para proyecto se toman en cuenta los

indicadores de efecto (corresponden al proyecto) y de producto (corresponden a un

componente) y ambos indicadores cuentan con hitos. Los indicadores pueden ser tipo índice,

porcentaje, tasa, unidades definidas por el usuario y cualitativos.

Esta historia refleja que acciones considera el gerente de proyecto para la emisión de los indicadores de producto y efecto del proyecto.

Nro. 14 Registro de indicador de efecto o producto e hito

Tarea : Alta de indicador de efecto o producto



Soy el encargado de registrar los indicadores de efecto o producto e hitos de control.

Dependiendo el tipo de indicador su tratamiento debe varia como se explica a continuación :

- El indicador puede ser porcentaje o tasa debe contar un nombre, fórmula, valor línea base, meta, aceptabilidad positiva, negativa;

- El indicador tipo índice debe contar con nombre, fórmula, valor línea base, meta, aceptabilidad positiva y negativa, y deben estar entre -1 y 1;

- El indicador tipo unidad y debe contar con nombre, fórmula, unidades, valor línea base, meta, aceptabilidad positiva y negativa;

- El indicador cualitativo debe contar con nombre, orientación (ascendente o descendente), (valor y definición) y definir si es línea base o meta.

Para cada indicador se debe almacenar los hitos o puntos de control, en función del tipo. El

alta de indicadores es posible solo en la fase programación del proyecto sin restricciones.

Esta historia refleja que acciones que se deben considerar para la actualización o eliminación de los indicadores de producto y efecto del proyecto.

42

Nro. 15 Eliminación o actualización de indicador de efecto o producto e hito

Tarea : Baja o actualización de indicador de efecto o producto e hito



Estoy encargado de la actualización y baja un indicador de efecto o producto con sus hitos de

control se debe tomar en cuenta las siguientes consideraciones:

- Si el indicador de efecto o producto que es de tipo (%, índice, tasa, unidad, cualitativo) no cuenta con hitos de control, la modificación baja o modificación se realiza sin restricciones.

- Si el indicador de efecto o producto que es de tipo (%, índice, tasa, unidad, cualitativo) cuenta con hitos de control, primero debe eliminar los hitos del indicador para que habilite la eliminación o modificación del indicador.

Eliminar o modificar un indicador puede significar que desestima la fase de pre inversión.

Esta historia refleja la necesidad de crear cuantías con puntos de notificación del proyecto.

Nro. 16 Registro, eliminación y modificación de cuantías de tiempo y presupuesto

Tarea : Vista de reporte de indicadores de efecto o producto



Los usuarios de esta historia no son responsables de este tipo de operaciones con las cuantías de

tiempo y presupuesto para las notificaciones. Sin embargo deben contar con acceso a la

información de proyecto para la toma de decisiones. Se debe notificar por correo electrónico.

Esta historia refleja cómo crear una cuantía como punto de notificación del proyecto

Nro. 17 Registro de cuantías de tiempo y presupuesto

Tarea : Alta de hito para indicador de efecto o producto



El gerente de proyecto es el encargado de adicionar uno o varias cuantías de tiempo y presupuesto

para la emisión futura de notificaciones (lo que ocurra primero), esto solo posible en la fase de

programación.

43

Esta historia refleja cómo ajustar o eliminar una cuantía de notificación del proyecto.

Nro. 18 Ajuste y eliminación de cuantías de tiempo y presupuesto

Tarea : Modificación de hito de indicador de efecto o producto



El usuario puede modificar solo los tiempos y las cantidades de ejecución presupuestarias para

emisión de la notificación. El gerente de proyecto puede de dar de baja cuantías de tiempo y

presupuesto, es solo posible en la fase de programación de proyecto.

Esta historia refleja cómo ajustar o eliminar una cuantía de notificación del proyecto.

Nro. 19 Registro, baja, modificación de ítem en presupuesto de proyecto

Tarea : Vista de reporte de ítems de presupuesto



Los usuarios de esta historia no son responsables de las transacciones de ítems de presupuesto

de proyecto, se debe usar el plan de cuentas de la institución. Sin embargo deben contar con

acceso a toda la información de los proyectos.

Esta historia indica que se considera para registrar un ítem de presupuesto de proyecto.

Nro. 20 Registro de ítem en presupuesto de proyecto

Tarea : Adición de ítem de presupuesto



Me hago cargo del alta de ítem de presupuesto del proyecto según el plan de cuentas (PC) de la

institución. Si existen dudas sobre el PC debe consultarlo con el director administrativo y sub sanar

la dificultad administrativa. El alta de ítem es posible en programación e inversión de proyecto está

sujeto a la disponibilidad del saldo disponible, el valor monetario debe ser mayor o igual a cero.

Esta historia expresa factores a considerar para borrar un ítem de presupuesto de proyecto.

44

Nro. 21 Eliminar y actualizar ítem en presupuesto de proyecto

Tarea : Baja de ítem de presupuesto de proyecto



Me encargo de borrar un ítem de presupuesto de un proyecto. La baja de ítem de presupuesto

de proyecto en programación no tiene restricciones, pero en inversión debe considerar:

- Es posible si el ítem de presupuesto de proyecto no tiene ninguna ejecución presupuestaria. - No es posible si el ítem de presupuesto de proyecto, cuenta con registro de ejecución.

La modificación de ítem de presupuesto, significa que el saldo disponible puede incrementar

o disminuir en el ítem. Se puede hacer ajustes o eliminar en fase de programación y ejecución.

Esta historia indica cómo se hace el seguimiento físico del proyecto.

Nro. 22 Seguimiento de avance físico

Tarea : Vista de reporte de seguimiento físico



Los usuarios de esta historia no se encargan de reportar el seguimiento, pero realizan el

seguimiento con la información reportada por el gerente de proyecto. El sistema deberá

notificar el seguimiento reportado por el gerente de proyecto durante la ejecución.

La historia explica la necesidad de reportar el seguimiento físico del proyecto.

Nro. 23 Registro de seguimiento de avance físico

Tarea : Alta de seguimiento físico



Soy el encargado de reportar el comportamiento de las actividades, indicadores que se realiza

según lo programado en un proyecto. El sistema de información deberá notificar la necesidad

de emisión de algún reporte un día antes, para que se envié la información evitando retrasos.

45

La historia explica la necesidad del seguimiento del presupuesto de proyecto.

Nro. 24 Seguimiento de ejecución de presupuesto

Tarea : Vista de ejecución financiera por ítems



Los usuarios de esta historia no son responsables del reportar esta inforamción. Pero requieren

de acceso a toda la información financiera para el monitoreo.

La historia explica la necesidad de reportar el seguimiento del presupuesto de proyecto.

Nro. 25 Registro de ejecución presupuestaria de proyecto

Tarea : Alta de seguimiento presupuestario de proyecto



Me encargo de reportar las inversiones realizadas del proyecto. El seguimiento de la ejecución

del ítem de presupuesto se realiza registrando el monto invertido y un descargo (factura u otro

documento financiero valido), solo en la fase de inversión.

La historia explica cómo se hace el monitoreo físico de proyecto.

Nro. 26 Monitoreo físico de proyecto

Tarea : Ninguna


Prioridad: Bajo Riesgo : Bajo

El staff de la institución puede sugerir medidas correctivas (monitoreo) solo en la fase

inversión. Los usuarios pueden aportar con sugerencias tomando en cuenta el seguimiento

físico del proyecto, si existieran desfases entre lo programado & lo ejecutado, en los ámbitos:

- Indicadores de efecto y producto, cuentan con hitos que se deben reportar según programación.

- Actividades, a la finalización del tiempo programado el sistema solicitara saber el cumplimiento.

46

La historia explica cómo se hace el monitoreo financiero de proyecto.

Nro. 27 Monitoreo financiero de proyecto

Tarea : Ninguna



Cualquiera de los usuarios pueden sugerir medidas correctivas (monitoreo) solo en la fase

inversión. Los usuarios pueden aportar con sugerencias tomando en cuenta el seguimiento

financiero del proyecto, por desfases entre lo programado & lo ejecutado.

La historia explica cómo se hace el monitoreo físico de proyecto.

Nro. 28 Registro de monitoreo físico en proyecto

Tarea : Alta, baja y modificación de actividad en fase inversión



El gerente de proyecto aplica el monitoreo que realizo el presidente de la institución los ajustes

en el proyecto (son considerados reprogramación) en los tiempos de las actividades. Estos

ajustes pueden significar la baja de una actividad, modificación de rango de tiempos o el

registro de una nueva actividad. Solo es posible en la fase de inversión.

La historia explica cómo se hace el monitoreo financiero de proyecto.

Nro. 29 Registro de monitoreo financiero en proyecto

Tarea : Alta, baja y modificación de ítems de presupuesto en fase de inversión

Usuario : Director administrativo Iteración : 07


El gerente de proyecto es el encargado de aplicar el monitoreo que realizo el presidente de la

institución los ajustes en el proyecto (son considerados reprogramación) los ítems de recursos

financieros del proyecto. Estos ajustes pueden significar la baja, modificación o el registro de

un nuevo ítem del presupuesto. Este proceso solo es posible en la fase de inversión.

47

La historia explica que se debe de notificar y porque medios el proyecto.

Nro. 30 Notificaciones del proyecto

Tarea : Crear servicios de verificación de proyecto, envío de correos electrónicos



Se necesitan notificaciones por correo electrónico con carácter proactivo del proyecto.

- La notificación, se utiliza para informar de manera previa un futuro suceso; básicamente futuros comienzos y finalizaciones del proyecto, componentes, actividades, vencimiento de plazo de reporte de indicadores, etc.

- Sólo será enviado al gerente de proyecto y no así a todos los involucrados. Su accionar o su activación depende de los datos o información de la programación, no de la ejecución o seguimiento.

- No es un acto administrativo controlado y por consiguiente es un recordatorio proactivo y no genera responsabilidades.

- Para garantizar que las notificaciones sean efectivas la institución recomienda a sus funcionarios el uso del correo electrónico institucional.

La historia explica cuando se deben emitir alertas del proyecto.

Nro. 31 Alertas del proyecto

Tarea : Crear servicios de verificación de proyecto, envío de correos electrónicos

Usuario : Todos los usuarios del proyecto Iteración : 08


Se necesitan notificaciones por correo electrónico con carácter de monitoreo del proyecto.

- Se utiliza para informar de manera posterior la ocurrencia de un suceso (ya sea que sucedió o no sucedió dependiendo del caso), básicamente vencimiento de plazos sin reportes, diferencias considerables entre programados y ejecutados, etc.

- Su accionar o activación depende de la programación como de ejecución o seguimiento. - Es considerado como un acto administrativo, pues se trata de una reacción del sistema ante

un evento fuera de lo común o que no estuviera previsto que suceda así. - Es una medida reactiva que motiva otra medida correctiva de manera oportuna y temprana

solo en fase de inversión. - Para asegurar que las alertas sean efectivas la institución recomienda a sus funcionarios el

uso del correo electrónico institucional.- Las notificaciones deben enviarse con prioridad al directorio, presidente, director

administrativo y gerente de proyecto.

48

3.3.3 Plan de Entregas

Con las historias de usuario es necesario planificar y establecer las entregas y lanzamiento.

Tabla 3.2: Plan de entregas y lanzamientos pequeños

I. Tarea Funcionalidad Fecha Indicador

1 Desarrollo del interfaz de usuario

para altas, bajas, modificaciones y

vistas (ABMV) módulo proyecto,

fase programación.

Transacciones con MySql

gestor de base de datos

(SGDB) aplicando los

modelos de diseño.

17/09/2015 Módulo proyecto

funcionando para

historias 1 al 5

2 Desarrollo del interfaz de usuario

ABMV módulo de componentes y

actividades fase de programación.

Transferencias con el SGDB

aplicado modelos de diseño.

30/10/2015 Módulo componentes

actividades, para las

historias 6 al 12

3 Desarrollo ABMV módulo de

indicadores de efecto y producto

con sus hitos. Fase programación.

Transacciones con SGDB con

indicadores porcentaje, tasa,

índice, unidades y cualitativo.

15/09/2015 Módulo operando

para historias de

usuario 13 al 15

4 Programar los ABMV de

Notificaciones por cuantía de

tiempo y ejecución presupuestaria

Almacenamiento en SGDB

Aplicando las restricciones

presupuestarias y tiempo.

15/10/2015 Módulo programado,

para las historias de

usuario 16-18

5 Desarrollo del interfaz para las

ABMV módulo de presupuesto,

fases programación y ejecución.


aplicar las restricciones

presupuestarias.

30/10/2015 Módulo presupuesto

realizando, para

historias 19-21

6 Desarrollo interfaz AV módulo

seguimiento físico (cumplimiento

actividad e hitos) y seguimiento

ejecución presupuesto.


aplicar restricciones

diseñadas seguimiento físico y

financiero fase ejecución.

17/11/2015 Módulo seguimiento

funcionando, para

historias de usuario

22-25

7 E monitoreo es humano basado en

el seguimiento, significa realizar

ABM de tiempos presupuestos,

para fase de ejecución.

Guardar registros de

reprogramación que sufren las

actividades y los presupuestos.

25/11/2015 Módulo proyecto

funcionando para


26-29

8 Activar servicios de notificación y

alertas, por programación y

condiciones de alertas, fase de

ejecución

Envío de correo electrónico

con información sobre

proyecto en términos de

notificaciones o alertas.

15/12/2015 Servicios activos del

lado del servidor.


30 -31

Fuente: [Elaboración propia]

49

3.3.4 Iteraciones

Las historias de usuario y el plan de entregas definen el número y orden de iteraciones

necesarias para el avance el proyecto, a la conclusión de cada iteración se obtiene respuesta

a un conjunto de historias de usuario resuelto, que nos permite hacer un lanzamiento pequeño

del sistema. La forma en la que se ejecutan las iteraciones se la presenta a continuación.

Semanas

Agosto Septiembre Octubre Noviembre Diciembre

Nro. Fases XP 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

1 Planificación

2 Diseño

3 Codificación

4 Pruebas

Figura 3.3: Iteraciones por fases XP Fuente: [Elaboración propia]

3.4 Fase de Diseño

Se recomienda la simplicidad, siempre costará menos tiempo implementar un diseño simple

que uno complejo, por lo que a través de esta herramienta se aconseja siempre realizar las

cosas de la manera más sencilla posible. El mejor diseño es el más sencillo que funcione con

todos los casos de prueba. La idea es reemplazar los aspectos complicados del sistema por

soluciones equivalentes más simples. Es así que se recomienda el uso de las tarjetas CRC,

modelo de estructura, modelo entidad relación, modelo relacional y los diagramas hipertexto,

que respondan a las historias de usuario.

3.4.1 Tarjeta de Clases, Responsabilidades y Colaboración

La técnica de elaboración de tarjetas de clases, responsabilidades y colaboración (CRC)

propone una forma de trabajo, preferentemente grupal, para encontrar los objetos del dominio

de la aplicación, sus responsabilidades y cómo colaboran con otros para realizar tareas. Las

tarjetas CRC permiten al programador concentrar esfuerzos en la programación tomando en

cuenta las historias de usuario. Se aplican los conceptos GxR para la etapa de inversión.

50

Tabla 3.3: Tarjetas de clases, responsabilidades y Colaboradores

Clase : Usuario

Responsabilidades Colaboradores

Define perfiles y estado de los usuarios - Lista, Adiciona, Actualiza, Desactiva. Todas fases de la etapa de inversión.

- Perfiles y roles definidos; - Usuario con cuenta de correo electrónico

activa.

Clase : Perfil


Es un grupo de acciones a las que puede acceder el usuario - Lista, Adiciona, Actualiza, Elimina. Todas las fases de la etapa de inversión.

- Enlaces validos definidos en la clase acceso; - Clave primaria de usuario previamente

registrado con cuenta de correo electrónico valido.

Clase : Acceso


Son los enlaces validos de navegabilidad. - Lista, Adición, Actualización, Eliminación. Solo en la fase de programación.

- Listado estructurado y ordenado de las carpetas, archivos en el servidor.

Clase : Proyecto


Establece la fase en la etapa de inversión, entre fase de programación, ejecución o resultados. - Lista, Adiciona, Actualiza, Elimina. Solo en la fase de programación.

- Proyecto aprobado por la institución (diseño final, en etapa de pre inversión);

- Usuarios habilitados (gerente de proyectos); - Categoría programática de la institución.

Clase : Indicador de efecto


Define la forma de cálculo y las unidades de la medición del proyecto completo - Lista, Adiciona, Actualiza, Elimina. Solo en la fase de programación.

- Indicadores obtenidos en proyecto a diseño final.

51

Clase : Componente de proyecto


Define el objetivo de un grupo de actividades en tiempo determinado y permite definir indicadores de producto. - Lista, Adiciona, Actualiza, Elimina. Solo en la fase de programación.

- Rango de tiempos definidos en la clase proyecto.

Clase : Indicadores de producto


Define la forma de cálculo y las unidades de la medición del componente, que está sujeto al cumplimiento de las actividades que la conforman. - Lista, Adiciona, Actualiza, Elimina. Solo en la fase de programación.

- Indicadores de productos que se estimaron obtener en proyecto a diseño final.

Clase : Ítem indicador cualitativo


Define una lista cualitativa y las unidades de la medición, sujetos a la definición del usuario. - Lista, Adiciona, Actualiza, Elimina. Solo en la fase de programación.

- Indicadores de productos que se estimaron obtener en proyecto a diseño final.

Clase : Hito


Define tiempo y establece un valor de referencia en función de la línea base y la meta del indicador, para ser evaluado posteriormente. - Lista, Adiciona, Actualiza, Elimina. - Recibe estado de indicador en un tiempo. Solo en la fase de programación y ejecución.

- Indicadores de efecto y producto que se obtuvieron en proyecto a diseño final.

52

Clase : Actividad


Define las acciones se deben realizar específicamente dentro de un componente en un rango de tiempos. - Lista, Adiciona, Actualiza, Elimina. - Seguimiento (cumplió/no cumplió). Solo en la fase de programación y ejecución.

- Se requiere de un componente definido en el proyecto.

Clase : Ítem presupuesto


Define la composición presupuestaria del proyecto - Lista, Adiciona, Actualiza, Elimina. - Seguimiento financiero por ítem Solo en la fase de programación y ejecución.

- Techo presupuestario del proyecto. - Plan de cuentas institucional. - Calculo saldo disponible del proyecto. - Calculo saldo disponible por ítem

presupuesto

Clase : Seguimiento ítem presupuesto


Define los niveles de inversión según la programación de ítems de presupuesto. - Lista, Adiciona, Actualiza, Elimina. Solo en la fase de ejecución.

- Ítem de presupuesto; - Cálculo de saldo en ítem.

Clase : Notificaciones por cuantía tiempo


Define notificaciones en función del tiempo Fase de ejecución en la etapa de inversión.

- Tiempo del servidor sincronizado con zona horaria de Bolivia.

Clase : Notificaciones por cuantía presupuesto ejecutado


Define notificaciones en función del presupuesto - Lista, Adiciona, Actualiza, Elimina. Fase de ejecución en la etapa de inversión.

- Tiempo del servidor sincronizado con zona horaria de Bolivia.

53

3.4.2 Modelo de Estructura

El modelo de estructura es de la técnica WebML, sus elementos son entidades, atributos y

relaciones. Se aplicara la herramienta IFML modelando el domino o modelo de estructura.

EL modelo es una representación de lógica de la base de datos establece 13 tablas cada uno

con sus atributos en función de las tarjetas CRC, historias de usuario y el GxR.

Figura 3.4: Modelo de estructura o dominio del modelo del sistema Fuente: [Elaboración propia]

54

3.4.3 Modelo Entidad Relación

El modelo entidad relación 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 por lo tanto es

un modelo lógico. Este modelo es una derivación del modelo de estructura.

Figura 3.5: Modelo entidad relación del sistema Fuente: [Elaboración propia]

55

Tabla 3.4: Atributos del modelo Entidad Relación

Entidad/Relación Atributos

Usuario {id_usr, UserName, password, email}

Perfil {oid, denominacion}

Accesos {oid, perfilID,enlace}

Proyecto {id_proy, cod_proy_inst, denominacion, objetivo_principal,

beneficiarios, fecha_inicio, fecha_fin, fuente_financiamiento,

presupuesto, contraparte_tecnica, id_usr_gerente,

id_categoria_programatica, prg, id_usr, fhs}

Indicador {id_ind, id_proy, id_com, tipo_indicador, denominación,

formula_nominal, unidad, línea_base, meta, aceptabilidad_maxima,

aceptabilidad_minima, riesgo, id_usr, fhs}

Componente {id_com, id_proy, denominación, fecha_inicio, fecha_fin,

consideraciones, id_usr, fhs}

Actividad {id_act, id_com, denominación, fecha_inicio, fecha_fin,

consideraciones, responsable, std, id_usr, fhs}

Item_indicador_

cualitativo

{ id_item_ind_cua, id_ind, orden,ítem, significado_item, id_usr,

fhs}

hito_indicador { id_hit_ind, id_ind, fecha, valor_esperado, valor_real, is_usr, fhs}

item_presupuesto {id_pto, id_proy, id_plan_cuentas, item, presupuesto, prg, id_usr,

fhs}

seguimiento_item

_presupuesto

{ id_seg_itm_pto, id_pto, inersion,descargo, observciones, id_usr,

fhs}

notificaciones_x_tmp {id_a, id_proy, fecha, id_usr, fhs}

notificaciones_x_ppto {id_a, id_proy, cantidad, id_usr, fhs}


La tabla antes presentada describe el modelo entidad relación para el sistema de información.

56

3.4.4 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 (MySql). Se trata de un modelo teórico

matemático que proporciona los elementos básicos de modelado (entidades, las relaciones).

El siguiente modelo es el resultado de llevar el modelo entidad relación al modelo relacional

o modelo físico con el diseñador de base de datos que tiene el sistema gestor de base de datos.

Figura 3.6: Modelo relacional obtenido con MySql Fuente: [Elaboración propia]

57

3.4.5 Modelo Hipertexto

Permite representar del comportamiento del sistema utilizando contenedores, unidades

navegación, composición, cuenta con enlaces, servicios, funciones y procedimientos con

información que fluirá entre los módulos en términos de entrada y salida como lo establece

el WebML, para el diseño de este modelo se utilizará la herramienta IFML. Se especifican

los modelos de ingreso al sistema, proyectos, indicadores de efecto y producto, hitos

indicadores, seguimiento de indicadores, componentes, actividades, seguimiento de

actividades, presupuesto, seguimiento de presupuesto, notificaciones y alertas según se

estableció en gráfico de iteraciones, los diseños de este modelo son de autoría propia .

Ingreso al sistema, se requiere de información del usuario, una cuenta de correo electrónico,

contraseña y la resolución del captcha. La información es enviada a la base de datos a la tabla

de usuarios donde se verifica si el usuario existe, si existe el usuario se pasa a los servicios

de acceso, caso contrario se retorna a la página de ingreso. Si el usuario está registrado en la

base de datos la información del usuario para al servicio de acceso si todo es correcto se

permite el ingreso al sistema, caso contrario retorna a la página de ingreso.

Figura 3.7: Modelo hipertexto ingreso al sistema Fuente: [Elaboración propia]

Inicio, es la primera página donde se encuentra los lineamientos institucionales del CADELP,

la página cuenta con un menú con enlaces que permiten salir del sistema, ir institución para

acceder a información del usuario y proyecto. A continuación se presenta en la siguiente

figura.

58

Figura 3.8: Modelo hipertexto página de inicio Fuente: [Elaboración propia]

Institución, permite ver la información del usuario y la actualización de la contraseña.

Figura 3.9: Modelo hipertexto institución, cambio contraseña de usuario Fuente: [Elaboración propia]

Proyectos fase de programación, son los proyectos por ejecutar.

Figura 3.10: Modelo hipertexto proyecto (fp, i1) Fuente: [Elaboración propia]

59

Indicadores de efecto, permite definir los medios de medición del proyecto con los hitos.

Figura 3.11: Modelo hipertexto indicadores de efecto (fp, i3) Fuente: [Elaboración propia]

Componente, define un grupo de actividades, el mismo cuenta con indicadores de producto.

Figura 3.12: Modelo hipertexto componente, actividad (fp, i2) Fuente: [Elaboración propia]

60

Indicadores de producto, permite definir los medios de medición del componente del

proyecto, estos indicadores especifican productos concretos puede definir hitos de control.

Figura 3.13: Modelo hipertexto indicadores de producto (fp, i3) Fuente: [Elaboración propia]

Presupuesto, define ítems de presupuesto del proyecto, en función del monto límite del

proyecto según la etapa de pre inversión.

Figura 3.14: Modelo hipertexto presupuesto (fp, i4) Fuente: [Elaboración propia]

61

Notificaciones por tiempo, permite definir puntos de notificación en función del tiempo

dentro del rango de ejecución del proyecto.

Figura 3.15: Modelo hipertexto notificaciones por tiempo (fp, i5) Fuente: [Elaboración propia]

Notificaciones por ejecución de presupuesto, define puntos de notificación presupuestal.

Figura 3.16: Modelo hipertexto notificaciones por inversión (fe, i5) Fuente: [Elaboración propia]

62

Fase de ejecución, esta fase aplica el seguimiento y monitoreo definidos en programación.

Seguimiento de indicadores de efecto, es la solicitud del estado de indicador mediante una

notificación sobre el estado actual de los hitos de cada indicador en función de la

programación del proyecto.

Figura 3.17: Modelo hipertexto seguimiento indicador de efecto (fe, i6) Fuente: [Elaboración propia]

Seguimiento de indicadores de producto, es la solicitud del estado de indicador mediante

una notificación sobre el estado actual de los hitos de cada indicador en función de la

programación del proyecto.

Figura 3.18: Modelo hipertexto seguimiento indicador producto (fe, i6) Fuente: [Elaboración propia]

63

En las dos últimas figuras antes detalladas se solicitó el estado del hito de cada indicador esta

información es útil para realizar el seguimiento y también aporta al monitoreo físico y

financiero para realizar medidas correctivas en el proyecto tal que se aseguren los resultados

de los productos y efectos.

Seguimiento y monitoreo de actividad, solicitud de estado de actividad al final del tiempo.

Figura 3.19: Modelo hipertexto seguimiento, monitoreo actividad (fe, i6, i7) Fuente: [Elaboración propia]

Seguimiento y monitoreo de presupuesto, solicitud de inversión por ítems del presupuesto.

Figura 3.20: Modelo hipertexto seguimiento, monitoreo presupuesto (fe, i6 i7) Fuente: [Elaboración propia]

64

Servicios web, son acciones del servidor en función de condiciones de fase programación

definidas para el proyecto.

Figura 3.21: Modelo de hipertexto servicios web (fe, i8) Fuente: [Elaboración propia]

Presentación de resultados, se realiza a la conclusión de la fase de inversión en la gestión

de proyectos, en esta fase solo es obtiene del sistema los resultados de la fase de ejecución y

el estado real de los indicadores misma que puede ser información base para la etapa de post

inversión para la posible evaluación si amerita al caso. Los proceso de seguimiento y

monitoreo ya no se ejecutan.

Figura 3.22: Modelo de hipertexto proyecto con reporte de resultados (fr) Fuente: [Elaboración propia]

3.4.6 Modelo de Presentación

El modelo de presentación permite definir el formato de presentación del sistema, tipos de

letra, colores, posición de los mensajes, alineación y otros que se presenta a continuación.

65

Figura 3.23: Modelo de Presentación Cliente Fuente: [Elaboración propia]

Para definir el modelo de presentación es necesario establecer una hoja de estilos CSS.

Figura 3.24: Modelo de Presentación Codigo Fuente: [Elaboración propia]

Estos estilos pueden ser heredados reutilizando el código de presentación en todo el sistema.

3.4.7 Matriz de procesos por tipos de usuario

El siguiente cuadro que especifica el nivel de acceso al sistema de información en función

del tipo de cliente tomando en cuenta todos los módulos, en función de los roles.

66

Acciones \ Funciones ��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��!��

��

��

��

��!��

��!��

��!��

��

��

��

��

��

��

��

��

��

��

��

��"��

��"��

��"��

��"��

��"��

��"��

��"��

��

��

��"��

��

��

��#��"��

��

��

67

3.4.8 Diccionario de datos

Se presenta el diccionario de datos generado con el modelo relacional donde se describen las

tablas de la base de datos tomando en cuenta los campos, tamaño, tipo de dato y su

descripción para establecer las relaciones y los campos claves. La información más detallada

de este punto se encuentra en Anexos A (Manual técnico).

3.5 Fase de codificación

El desarrollo de la fase de codificación implica la aplicación de todos los modelos obtenidos

en la fase de diseño del XP, los mismos serán programados con herramientas de

programación (PHP, JavaScript, Jquery), medios de maquetación (Html5, CSS), y librerías

(Jquery-Validate, RBAC).

3.5.1 Modelo de presentación

El modelo de presentación está orientado básicamente del lado del cliente por ejemplo los

formularios de ingreso de información deben recibir información según formato de los

atributos definidos en las tablas del gestor de base de datos MySql y de acuerdo a los

requerimientos de funcionalidad del modelo gestión de proyectos para resultados.

Fuente: [Elaboración propia] Figura 3.25: Codificación acceso al sistema

68

Cumplidos los requisitos de la anterior página, el sistema deriva al cliente a la página de

inicio donde el RBAC asigna los accesos según el perfil de usuario.

La página de inicio es donde nos presenta información institucional y cambiar la contraseña

del usuario, acceder a los proyectos y salir del sistema de información web.

Fuente: [Elaboración propia] Figura 3.26: Codificación inicio e información institucional

Si el cliente desea con el botón institución, tiene la opción de cambio de su contraseña, donde

el sistema envía un correo electrónico informando que la transacción fue realizada.

Figura 3.27: Codificación institución cambio de contraseña usuario Fuente: [Elaboración propia]

69

3.5.2 Ejecución del plan de entregas por iteraciones

Según la gestión por resultados en los proyectos existen las etapas de pre inversión, inversión

y post inversión. Según los modelos de diseño solo se está automatizando la etapa de

inversión con las fases de programación (fp), ejecución (fe) y presentación de resultados

(fpr), se especifica según las iteraciones (i) definidas en el plan de entregas, donde se muestra

como se hace las altas, bajas, modificaciones y vistas (ABMV). A continuación se presenta

la pantalla donde están organizados por grupos los proyectos según la fase.

Figura 3.28: Codificación acceso proyecto (fp, fe, i1) Fuente: [Elaboración propia]

Se presenta a los proyectos de la fase de programación que cuenta con interfaz de usuario

para realizar altas, bajas, modificaciones y vistas (ABMV) del módulo de proyecto.

Figura 3.29: Codificación lista de proyectos (fp,fe, i1) Fuente: [Elaboración propia]

Las altas y modificaciones de proyectos presentan la misma estructura para recibir

información.

70

Figura 3.30: Codificación alta y modificaciones de proyectos (fp, i1) Fuente: [Elaboración propia]

La baja de proyectos es solo posible en la fase de programación y se presenta a continuación.

Figura 3.31: Codificación baja de proyecto (fp, i1)Fuente: [Elaboración propia]

71

Se implementó el desarrollo del interfaz de usuario para la vista de los componentes del

proyecto y sus actividades con un listado de tiempos.

Figura 3.32: Codificación componentes y actividades (fp, fe, i2) Fuente: [Elaboración propia]

Se presentan los dos formularios para altas y modificaciones de componentes y actividades,

donde la estructura es la misma, cabe resaltar que las ABMV del componente solo es posible

en la fase programación, pero las ABMV de las actividades son posibles en las fases de

programación y ejecución.

Figura 3.33: Codificación alta componente (fp, i2) Fuente: [Elaboración propia]

La adición y modificación de actividad está en función del rango de tiempo del componente.

72

Figura 3.34: Codificación alta actividad (fp,fe, i2) Fuente: [Elaboración propia]

La baja de un componente y actividad es similar, la baja de un componente implica la baja

de un conjunto de actividades y la baja de actividad solo implica perder la actividad.

Figura 3.35: Codificación baja componente (fp, i2) Fuente: [Elaboración propia]

Las vistas de indicadores de efecto y producto en términos de presentación son similares

73

Figura 3.36: Codificación lista de indicadores efecto o producto (fp, i3) Fuente: [Elaboración propia]

Los formularios y validación son variables según el tipo de indicador y sus hitos.

Figura 3.37: Codificación alta indicador efecto o producto (fp, i3) Fuente: [Elaboración propia]

Formulario alta de indicadores de efecto o producto para porcentaje, índice, unidades y tasa

74

Fuente: [Elaboración propia] Figura 3.38: Codificación alta indicador efecto o producto %, T, I, U (fp, i3)

Formulario alta de indicadores de efecto o producto tipo cualitativo para el proyecto.

Figura 3.39: Codificación alta indicador efecto o producto cualitativos (fp, i3) Fuente: [Elaboración propia]

75

Formulario alta de indicadores de efecto o producto para porcentaje, índice, unidades y tasa

Figura 3.40: Codificación baja indicador de efecto o producto (fp, i3) Fuente: [Elaboración propia]

La vista de programación de notificaciones por tiempo y ejecución presupuestaria.

Figura 3.41: Codificación notificaciones por cuantías (fp, i4) Fuente: [Elaboración propia]

Las altas y las modificaciones tienen el mismo formato para establecer las notificaciones.

Figura 3.42: Codificación altas notificaciones por tiempo (fp, i4) Fuente: [Elaboración propia]

76

La baja de una notificación por tiempo se la hace bajo confirmación solo fase programación.

Figura 3.43: Codificación baja notificaciones por tiempo (fp, i4) Fuente: [Elaboración propia]

Se tiene también el alta o la modificación de notificaciones por ejecución presupuestaria para

el proyecto, solo es posible en la fase de programación.

Figura 3.44: Codificación alta notificaciones por presupuesto (fp, i4) Fuente: [Elaboración propia]

Para la baja de una cuantía por ejecución presupuestaria se requiere una confirmación, solo

es posible en la fase de programación de proyecto.

Figura 3.45: Codificación baja notificaciones por presupuesto (fp, i4) Fuente: [Elaboración propia]

77

Interfaz para las ABMV del módulo de presupuesto, fases de programación y ejecución.

Figura 3.46: Codificación ítems de presupuesto (fp,fe, i5) Fuente: [Elaboración propia]

Se presenta el formulario de altas y modificaciones para el registro e ítems de presupuesto

para la programación del proyecto que está en función del saldo.

Figura 3.47: Codificación alta ítem de presupuesto (fp,fe, i5) Fuente: [Elaboración propia]

78

Las bajas son posibles sin restricción si el proyecto está en fase de programación. Las bajas

no son posibles si existe ejecución en algún ítem de presupuesto en la fase de ejecución.

Figura 3.48: Codificación baja ítem presupuesto (fp, fe , i5) Fuente: [Elaboración propia]

La fase de ejecución de proyecto, es una etapa en las que se hace hincapié en los procesos de

seguimiento y monitoreo. Se hace el seguimiento de los indicadores de efecto y producto,

actividades, también se hace una recopilación de la ejecución presupuestaria.

El monitoreo es la aplicaciones de medidas correctivas por parte de la alta gerencia de la

institución. Estos procesos solo se aplican en la fase de ejecución de proyecto, como se

presenta a continuación.

Figura 3.49: Codificación fase de ejecución de proyectos (fe, i6) Fuente: [Elaboración propia]

El seguimiento de indicadores significa reportar el estado de los hitos según lo programado.

79

Figura 3.50: Codificación seguimiento indicador (fe, i6) Fuente: [Elaboración propia]

El seguimiento de actividad significa reportar el cumplimiento o no de la actividad. El

monitoreo de actividades significa adicionar, ajustar o eliminar actividades programadas.

Figura 3.51: Codificación seguimiento, monitoreo actividades (fe, i6, i7) Fuente: [Elaboración propia]

80

El seguimiento de ítems de presupuesto significa reportar el nivel de ejecución

presupuestaria. Se indica el monto invertido que corresponde a ítem de presupuesto se puede

adjuntar el documento oficial de descargo.

Figura 3.52: Codificación seguimiento presupuesto (fe, i6) Fuente: [Elaboración propia]

El monitoreo de presupuesto significa adicionar, ajustar o eliminar ítems del presupuesto

programado, según la disponibilidad de saldo en el proyecto y los ítems de presupuesto.

Figura 3.53: Codificación seguimiento, monitoreo presupuesto (fe, i7) Fuente: [Elaboración propia]

81

Las notificaciones y/o alertas son servicios web que funcionan solo en fase de ejecución, se

ejecutan según la programación de proyecto, componente, actividad.

Figura 3.54: Codificación servicio notificaciones (fe, i8) Fuente: [Elaboración propia]

3.6 Fase de pruebas

XP enfatiza la realización de un sinfín de pruebas a lo largo del proyecto, con el fin de

asegurar en todo momento la realización de lo planteado con el diseño. En este proceso no

solo participa el equipo de desarrollo, también es importante el aporte del cliente.

3.6.1 Pruebas de caja blanca

XP prevé el desarrollo de la metodología la aplicación de pruebas de caja blanca para la

codificación del sistema el desarrollador verifico que cada uno de los módulos del sistema

comporte de acuerdo a los diseños de la base de datos y los modelos de hipertexto, también

que cada módulo desarrollado comporte de acuerdo a las historias de usuario. XP plantea el

uso de las pruebas de flujo de información como un medio de verificación sobre el

comportamiento correcto del sistema.

A continuación se presenta una prueba de caja blanca para el ingreso al sistema.

82

Figura 3.55: Prueba de Caja Blanca inicio de sistema Fuente: [Elaboración propia]

En el formulario de inicio valida los tres campos utilizando Jquery-Validate si la información

cumple los requisitos se habilita él envió de la información luego verifica el servidor, el

captcha, la cuenta, la contraseña, la activación y el no bloqueo, si cumple rbac envía al inicio.

3.6.2 Pruebas de caja negra

Son pruebas que enfatizan tiempos de respuesta y la capacidad transacciones.

83

3.6.3 Resultados de las pruebas de aceptación

Permite confirmar que las historias de usuarios fueron respondidas, se especifican, criterios

condicionales, de entrada, procesos, resultados esperados y un criterio de aceptación.

La primera iteración es del módulo de proyectos a continuación se presentan las siguientes

pruebas de aceptación, que responden a las historias del 1 al 5.

La vista de proyecto es un requerimiento de las historias de usuario 1, 2, 3 para el directorio,

presidente y director administrativo cada uno tiene la necesidad de acceso a la información.

Vista Proyecto

El sistema reporta información detallada del proyecto para las fases de programación,

inversión y los resultados en una pantalla emergente que surge haciendo clic en el proyectos.

Condiciones de Ejecución:

- Se requiere de información almacenada en la base de datos;

- El gerente de proyecto solo puede observar los proyectos que le corresponden;

- El directorio, gerente general y director administrativo observan todos los proyectos.

Entrada:

- Clic en el enlace del proyecto deseado

Pasos de ejecución:

- Clic en enlace de proyectos;

- Elegir uno de los grupos de proyectos (programación, ejecución, resultados);

- Clic en un proyecto.

Resultado Esperado: Pantalla emergente con la información del proyecto

Evaluación de la Prueba:

- Aceptada por los usuarios

El alta de proyecto es un requerimiento de las historias de usuario 4 definida por el gerente

de proyecto, es el encargado de registrar el proyecto definir cómo debe comportar los medios

y procesos para que el proyecto tenga buenos resultados.

84

Alta Proyecto

Es el registro de un proyecto nuevo en el sistema de información mediante un formulario que

valida la información detallada de un proyecto, solo para la fase de programación.


- Se requiere de información línea base de un proyecto aprobado por el directorio;

Entrada: Clic en el enlace Adicionar en el grupo de proyectos programados.


- Llenar los campos requeridos en el formulario de registro de proyecto;

- Verificar que la información este completa (no debe existir observaciones rojas);

- Clic botón Enviar.

Resultado Esperado: Proyecto nuevo está en el listado de proyectos programados.

Evaluación de la Prueba: Aceptada por los usuarios

La modificación de proyecto es un requerimiento de las historias de usuario 5.

Modificación Proyecto

Es la actualización de información de un proyecto que existe en el sistema de información

mediante un formulario que valida la información detallada, solo fase de programación.


- Se requiere información de proyecto almacenada en la base de datos;

- Se requiere tener definidos los cambios del proyecto a actualizar.

Entrada: Clic enlace Modificar en el grupo de proyectos programados.


- Actualizar los campos requeridos en el formulario de modificación de proyecto;

- Verificar que la información este completa (no debe existir observaciones rojas);

- Clic botón Enviar.

Resultado Esperado: Proyecto modificado en el listado de proyectos programados.


85

La eliminación de proyecto es un requerimiento de las historias de usuario 5.

Eliminación Proyecto

El sistema permite al gerente de proyecto eliminar un proyecto en la fase de programación.


- Se requiere información de proyecto almacenada en la base de datos;

- Proyecto debe estar en el grupo de proyectos programados.

Entrada: Tener definido el proyecto a eliminar y la autorización del directorio.


- Clic en el enlace Eliminar en el grupo de proyectos programados.

- Mensaje emergente solicitando confirme la eliminación;

- Clic botón Aceptar.

Resultado Esperado: Proyecto eliminado no figura en el listado de proyectos programados.


La segunda iteración corresponde a los componentes y las actividades se presentan las

siguientes pruebas de aceptación, que responde a las historias del 6 al 12.

La prueba de aceptación de la historia de usuario 6, 9 una vista de componentes y actividades.

Listado componentes y actividades

Cada proyecto cuenta con uno o varios componentes, cada componente puede contar con una

o más actividades. El sistema presenta un listado de los componentes y actividades por

proyecto en las fases de programación y ejecución.

Condiciones de Ejecución: Requiere información de proyecto, componente y actividad en DB.

Entrada: Clic enlace Componente en el grupo de proyectos programados o en ejecución.

Pasos de ejecución: Clic botón componente.

Resultado Esperado: Listado de componentes y actividades organizados por fecha.

Evaluación de la Prueba: Aceptada por los usuarios.

86

La prueba de aceptación de la historia de usuario 7, 10 alta de componente o actividad.

Alta componente o actividad

Registrar un componente en un proyecto significa crear un grupo de actividades para conseguir

uno o varios productos. Registrar una actividad para un componente es definir una acción.


- Se requiere proyecto registrado en la fase de programación; - Alta de componente en programación, alta de actividad en programación y ejecución.

Entrada: Información del nuevo componente o actividad de proyecto.


- Ingresar con el enlace adicionar componente o actividad; - Completar el formulario con información valida requerida; Click botón enviar.

Resultado Esperado: Componente o actividad nueva en lista.

Evaluación de la Prueba: Aceptada por los usuarios.

Prueba de aceptación de la historia de usuario 8,12 modificación de componente o actividad.

Modificación componente o actividad

Modificar un componente significa incidir en un grupo de actividades para conseguir uno o

varios productos. Modificar una actividad es ajustar una acción para lograr el componente.


- Se requiere información del componente o actividad de proyecto; - Modifica componente en programación y actividad en programación y ejecución.

Entrada: Información del componente o actividad para actualizar en el sistema.


- Clic sobre enlace modificar del componente o actividad deseado; - Actualizar información valida de componente o actividad; Clic Enviar.

Resultado Esperado:

- Componente o actividad actualizada en listado. Evaluación de la Prueba:


87

Prueba de aceptación de la historia de usuario 8,11 eliminación de componente o actividad.

Baja componente o actividad

Eliminar un componente en un proyecto significa borrar un grupo de actividades para

conseguir uno o varios productos. Borrar una actividad en componente limita acción de logro.


- Se requiere información del componente o actividad de proyecto en la base de datos; - Solo es posible eliminar en componente en la fase de programación; - Solo es posible eliminar la actividad en las fases de programación y ejecución.

Entrada: Tener definido que componente o actividad que será eliminado.


- Clic en el enlace de eliminación del componente o actividad deseada; - Confirmar la eliminación del componente o actividad.

Resultado Esperado: Componente o actividad no está en listado.


La tercera iteración corresponde al módulo de indicadores de efecto o producto con sus hitos

se presentan las siguientes pruebas de aceptación, que responde a las historias del 13 al 15.

Se tiene a la prueba de aceptación de la historia de usuario 13 donde se pide la vista.

Listado de indicadores de efecto o producto e hitos

Un proyecto cuenta con indicadores de efecto y los componentes cuentan con indicadores de

producto, ambos indicadores son medios de medición estos cuentan con hitos de control.

Condiciones de Ejecución: Se requiere información de indicadores e hitos en la base de datos.

Entrada: Necesidad de ver los indicadores de efecto o producto.


- Clic sobre indicadores de efecto del proyecto;

- Clic en indicadores de producto del componente.

Resultado Esperado: Listado de indicadores de efecto o producto con hitos.


88

Se tiene la aceptación de la historia de usuario 14 donde se espera el alta del registro.

Adición de indicador de efecto o producto e hito

Adicionar un indicador de efecto o indicador de producto implica agregar un medio de

medición, estos medios cuentan con hitos de control para el seguimiento y monitoreo.

Condiciones de Ejecución: Se requiere información de indicador e hitos definidos.

Entrada: Registrar indicador de efecto o producto e hitos.


- Clic enlace indicador de efecto o indicador de producto;

- Clic en adicionar indicador de efecto, producto e hito;

- Llenar formulario de indicador de efecto y producto e hitos; Enviar información.

Resultado Esperado: Indicador de efecto o producto con hito en el listado


Se tiene la aceptación de la historia de usuario 15 donde hay la modificación del registro.

Modificación de indicador de efecto o producto e hito

Modificar un indicador de efecto o indicador de producto implica modificar un medio de



- Se requiere información de indicador e hitos definidos en la base de datos;

- Solo en la fase de programación.

Entrada: Definir el indicador que se desea actualizar sea de efecto o producto.


- Clic en modificar indicador efecto o producto e hito;

- Actualizar formulario de indicador de efecto y producto e hitos con información valida;

- Enviar información.

Resultado Esperado: Indicador de efecto o producto con hito actualizado en el listado.


89

Se tiene la aceptación de la historia de usuario 15 donde se realiza la baja del registro.

Baja de indicador de efecto o producto e hito

Dar de Baja un indicador de efecto o indicador de producto implica borrar un medio de



- Se requiere información de indicador e hitos en base de datos

- Solo fase de programación.

Entrada: Definir el indicador de efecto, producto e hito que se desea eliminar.


- Clic en eliminar del indicador efecto, producto e hito;

- Confirmar la eliminación; Enviar información.

Resultado Esperado: Indicador o hito fuera del listado.


La cuarta iteración corresponde a los módulos de notificaciones por cuantías de tiempo y cuantías por ejecución de presupuesto, corresponden historias de usuario 16 al 18.

Se presenta la vista de notificaciones de tiempo o presupuesto para la historia 16.

Listado de notificaciones por cuantía de tiempo o presupuesto

Un proyecto puede contar con notificaciones programadas por cuantías de tiempo o ejecución

presupuestaria, los servicios se activaran dependiendo que ocurra primero.

Condiciones de Ejecución: Estar en la fase de programación o ejecución.

Entrada: Necesidad de ver las notificaciones programadas.


- Clic enlace notificaciones;

- Clic enlace notificaciones por tiempo o ejecución presupuestaria;

Resultado Esperado: Notificación por cuantías de tiempo o ejecución presupuestaria en lista.


90

Se presenta la vista de notificaciones de tiempo o presupuesto para la historia 17.

Alta notificación por cuantía de tiempo o presupuesto

Adicionar una o varias notificaciones por cuantías de tiempo o ejecución presupuestaria,

implica programar los servicios que se activaran dependiendo que ocurra primero.


- Se requiere conocer los tiempos o cantidades de ejecución presupuestaria;


Entrada: Contar con la definición de la cuantía por tiempo o presupuesto.



- Clic en enlace notificaciones por tiempo o presupuesto;

- Llenar formulario con el tiempo o presupuesto; Enviar información.

Resultado Esperado: Notificación en listado.


Se presenta la modificación de notificaciones de tiempo o presupuesto para la historia 18.

Modificar notificación por cuantía de tiempo o presupuesto

Modificar una notificación por cuantías de tiempo o ejecución presupuestaria, implica

reprogramar los servicios que se activaran dependiendo que ocurra primero.


- Se requiere conocer los tiempos o cantidades de ejecución presupuestaria;


Entrada: Definir el tiempo o cantidad de ítem presupuestario que desea actualizar.



- Clic en notificaciones por cuantía tiempo o presupuesto; Clic enlace modificar;

- Llenar formulario con información valida; Enviar información.

Resultado Esperado: Notificación de tiempo o ejecución presupuestaria actualizada en lista.


91

Se presenta la baja de notificaciones de tiempo o presupuesto para la historia 18.

Baja notificación por cuantía de tiempo o presupuesto

Dar de baja una notificación por cuantías de tiempo o ejecución presupuestaria, implica

eliminar una notificación programada para que activen los servicios.


- Se requiere conocer el tiempo o cantidad de ejecución presupuestaria;


Entrada: Definir si desea eliminar una notificación por tiempo o ejecución presupuestaria.


- Clic enlace notificaciones por tiempo o ejecución presupuestaria;

- Clic en eliminar el registro deseado;

- Confirmar la eliminación;


Resultado Esperado: Notificación borrada del listado de tiempo o ejecución presupuestaria.


La quinta iteración corresponde a módulo de ejecución de presupuesto que responde a las

historias del 19 al 21.

Es la prueba de aceptación de la vista de ítems de presupuesto de proyecto de la historia 19.

Listado de ítems de presupuesto

Un proyecto normalmente cuenta con un techo financiero para su ejecución, el mismo se debe

distribuir en ítems de presupuesto para realizar un seguimiento y monitoreo.

Condiciones de Ejecución: Se requiere información de presupuesto e ítems en la base de datos.

Entrada: Necesidad de ver la distribución presupuestaria del proyecto por ítems.

Pasos de ejecución: Clic enlace presupuesto del proyecto;

Resultado Esperado: Retorno listado de ítems de presupuesto del proyecto.


92

Es la prueba de aceptación del alta de ítems de presupuesto de proyecto de la historia 20.

Alta ítem presupuesto de proyecto

Dar de alta un ítem de presupuesto de proyecto significa distribuir el techo presupuestario, para

hacer el seguimiento y monitoreo.


- Los ítems se adicionan en razón de existencia de saldo en el techo presupuestario;

- Solo fase de programación y ejecución.

Entrada: Conocer que ítem del presupuesto se desea guardar.


- Clic enlace presupuesto del proyecto deseado;

- Clic en adicionar ítem de presupuesto;

- Llenar formulario de ítem de presupuesto con información valida; Enviar información.

Resultado Esperado: Ítem de presupuesto en el listado del presupuesto de proyecto.



Modificación ítem de presupuesto de proyecto

Modificar un ítem de presupuesto de proyecto significa redistribuir el techo presupuestario,

para hacer el seguimiento y monitoreo.


- Se requiere información ítem de presupuesto definidos en la base de datos,

- Solo en la fase de programación y programación.

Entrada: Saber que ítem de presupuesto que desea actualizar.


- Clic enlace presupuesto;

- Clic en modificar ítem deseado;

- Llenar formulario de ítem de presupuesto; Enviar información.

Resultado Esperado: Ítem de presupuesto actualizado en el listado.


93


Baja ítem de presupuesto de proyecto

Eliminar un ítem de presupuesto de proyecto significa generar saldo en el techo presupuestario

del proyecto, solo es posible si no existe ejecución financiera.


- Se requiere información de ítem de presupuesto en base de datos.

- Solo fase de programación y (ejecución si no existe ejecución).

Entrada: Definir el ítem de presupuesto que se desea eliminar.


- Clic enlace presupuesto de proyecto;

- Clic en eliminar el ítem de presupuesto deseado;

- Confirmar la eliminación;


Resultado Esperado: Ítem de presupuesto fuera del listado del presupuesto del proyecto.


La sexta iteración es de seguimiento de hitos, actividades y presupuesto historias 22 al 25.

La prueba de usuario corresponde a la vista de seguimiento para la historia 22.

Listado de estado de hitos, actividades

Sistema solicita a gerente de proyecto el estado de los hitos de los indicadores y las actividades.


- Se requiere hitos de indicador, actividades, ítems de presupuesto en la base de datos;

- Solo posible en la fase de ejecución.

Entrada: Necesidad de conocer la situación actual del proyecto.

Pasos de ejecución: Clic enlace indicador, componente, presupuesto;

Resultado Esperado: Listado de indicadores e hitos, actividades , ejecución de ítem;


- Aceptada por los usuarios.

94

La prueba de usuario corresponde a la vista de seguimiento para la historia 23.

Registro de hitos, actividades

Sistema espera reporte de los hitos de indicadores del proyecto.


- Se requiere hitos de indicador, actividades en la base de datos;


Entrada: Conocer el estado de los hitos de indicador y/o si tuvo éxito la actividad.


- Clic enlace de hito de indicador o clic en actividad;

- Llenar la información solicitada.

- Enviar formulario.

Resultado Esperado:

- Listado de indicadores e hitos de indicador o actividades.



La prueba de usuario de seguimiento ejecución presupuestaria historia 24.

Listado de estado ejecución de ítem presupuestario

El sistema solicita el estado ejecución presupuestaria todo en la fase de ejecución.


- Se requiere ítems de presupuesto en la base de datos;


Entrada: Necesidad de conocer la situación actual del proyecto.


- Clic enlace presupuesto;

Resultado Esperado:

- Listado ejecución presupuestaria de ítem;



95

La prueba de usuario corresponde al registro de seguimiento para la historia 25.

Alta estado ejecución de ítem presupuestario

El alta de un hito, actividad o ejecución presupuestaria significa que se está informado sobre

la situación actual del proyecto para que se pueda hacer el monitoreo.


- Contar con ejecución presupuestaria e imagen de factura o recibo oficial;

- Solo ejecución.

Entrada:

- Tener definido el alta de ítem de presupuesto.


- Clic enlace presupuesto del proyecto deseado;

- Clic en adicionar ítem de presupuesto;

- Llenar formulario de ítem de presupuesto con información valida;


Resultado Esperado:

- Ítem de presupuesto en el listado del presupuesto de proyecto.



La séptima iteración corresponde al módulo de monitoreo de procesos, producto y efectos

las siguientes pruebas de aceptación son de las historias del 26 al 29.

Las historias 26, 27 hacen referencia a vistas de las actividades, indicadores y ejecución

presupuestaria, resueltas en las iteraciones 2, 3 y 5. Donde el monitoreo es un proceso de

revisión humano en función de los criterios de los ejecutivos del colegio de administradores,

en función de sus decisiones será posible realizar una acción de monitoreo para la aplicación

de medidas correctivas en las actividades ajustando tiempos y en el presupuesto ajustando

los ítems de presupuesto, con la finalidad de lograr resultados positivos en el proyecto.

96

Las historias 28, 29 hacen referencia a vistas de las actividades, indicadores y ejecución

presupuestaria, en términos de ajustes fueron resueltas en las iteraciones 2, 3 y 5. Donde la

aplicación de medidas correctivas en las actividades ajustando tiempos y en el presupuesto

ajustando los ítems de presupuesto tienen reglas en función de su temporalidad, con la

finalidad de lograr resultados positivos en el proyecto.

La octava iteración corresponde a módulo de servicios que emite notificaciones y alertas a

los usuarios entorno de un proyecto en particular con las historias 30 al 31.

Servicios de notificaciones y alertas

Los servicios son programas que se activan del lado del servidor en función de la programación

del proyecto en las actividades, componentes, hitos de indicadores de efecto y producto, las

cuantías programadas por tiempo o inversión presupuestaria.


- Proyecto en fase de ejecución;

- Usuarios destino de email en la base de datos;

- Contar con información de proyecto para enviar notificaciones;

- Contar con desfase de indicadores para la emisión de alertas;

- Solo es posible en la fase de ejecución de proyecto.

Entrada:

- Programación de proyecto.


- Revisión de eventos cada hora en la base de datos para el envió de correo electrónico

a los usuarios entorno del proyecto;

Resultado Esperado:

- Clientes del sistema informados con notificaciones y alertas en el correo electrónico.



A continuación los resultados de una pruebas de estrés

97

3.6.4 Resultados de las pruebas de cargado del sistema

La velocidad de carga del sistema web depende de muchos factores externos, el más

importante y con alto grado de impacto es la optimización de las páginas del sistema, donde

la responsabilidad es de diseñadores y desarrolladores. Se presenta a continuación la prueba:

Figura 3.56: Test de velocidad Fuente: [Elaboración propia]

Se observa que el tiempo de lectura, la carga completa Kb. La cabecera respuesta usa el

mismo socket desde el host determinado. No existe compresión para texto, existe compresión

de imágenes, el contenido no es estático, existe un uso efectivo de JavaScript y CSS.

Figura 3.57: Listado de archivos evaluados en test de velocidad Fuente: [Elaboración propia]

A continuación se muestra los datos antes explicados en formato gráfico.

98

Figura 3.58: Vista en cascada de carga de la páginaFuente: [Elaboración propia]

Se puede observar también la vista de conexión de los objetos del sistema donde el consuma

promedio es de 5kb que nos muestra un alto grado eficiencia.

Figura 3.59: Vista conexion de carga de la página Fuente: [Elaboración propia]

La evaluación de desempeño indica que la respuesta de JavaScript es la más lenta, le siguen

las imágenes, a continuación las sentencias HTML y las hojas de estilo usan menos recursos.

99

Figura 3.60: Respuesta y uso de bytes en el sistemaFuente: [Elaboración propia]

3.6.5 Resultados de las prueba de estrés del sistema

Loadimpact, permite medir la carga de usuarios simultáneos que puede soportar el

alojamiento web. Para efectos de prueba del servidor y la aplicación se realizó la siguiente

prueba donde la prueba de stress está realizada con 100 usuarios simultáneos accediendo a

www.cadelp.hol.es (la línea verde es el número de usuarios y la línea azul los segundos de

respuesta). Se puede observar que el sistema está razonablemente optimizado, el sistema

aguanta bien la carga tomando en cuenta que es un hosting compartido y gratuito.

Figura 3.61: Prueba de estrés con 100 usuarios en segundos de respuesta Fuente: [Elaboración propia]

100

3.6.6 Resultados de las prueba SQL inyección

Inyección SQL es un método de infiltración de código intruso que se vale de una

vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas

para realizar operaciones sobre una base de datos.

El origen de la vulnerabilidad radica en el incorrecto chequeo y/o filtrado de las variables

utilizadas en un programa que contiene, o bien genera, código SQL. La inyección SQL se da

cuando, de alguna manera, se inserta o "inyecta" código SQL invasor dentro del código SQL

programado, a fin de alterar el funcionamiento normal del programa y lograr así que se

ejecute la porción de código "invasor" incrustado, en la base de datos.

El sistema de información fue sometido a las pruebas de SQL inyección con el OWASP

Figura 3.62: Prueba SQL inyección Fuente: [Elaboración propia]

El sistema supero la prueba de inyección SQL sin problemas y los resultados son

satisfactorios por lo tanto el sistema puede resolver este tipo de ataques sin problema.

Capítulo IV

Calidad, Seguridad y Mantenimiento

101

4. Calidad, Seguridad y Mantenimiento

4.1 Calidad

Se aplica la metodología de evaluación de calidad de sitios Web (WEBSITE-QEM).Esta

metodología tiene como objetivo la evaluación, comparación y análisis de calidad de sistemas

de información orientados a la Web. Donde se analiza sus fases, modelos, métodos,

procedimientos, criterios y herramientas aplicadas a las actividades. Las principales

contribuciones de esta metodología son:

• El enfoque integral, sistémico, disciplinado y cuantitativo, para evaluar y comparar

artefacto web, tanto en la fase operativa del ciclo de vida como en la fase de desarrollo;

• Conjunto de modelos, métodos, procedimientos, criterios y herramientas a ser utilizado

en las diferentes fases y actividades. Los mismos pueden ser empleados en el marco

conceptual en un modelo de proceso de evaluación estandarizado;

• Contribuir potencialmente a comprender y mejorar la calidad en el diseño y rediseño de

aplicaciones centradas en la web. Esta declaración está motivada en la metodología de

evaluación de calidad propone un riguroso y sistemático uso de principios y practicas

establecidas por la ingeniería de software aplicados en la web;

• El empleo de un marco conceptual para validar métricas en la web, se validan

teóricamente varias métricas empleadas (orientadas a la valoración antes que a sistemas

de predicción);

4.1.1 Factibilidad de uso

Conjunto de atributos relacionados con el esfuerzo necesario para su uso y valoración

individual de tal uso, por establecimiento o implicado conjunto de usuarios.

• Capacidad de comprensión (FC), es la capacidad del producto software que permite al

usuario entender si el software es adecuado.

• Capacidad de ser aprendido (FA), capacidad del producto software que permite al usuario

aprender sobre su aplicación.

102

• Capacidad de ser operado (FO), capacidad del producto software que permite al usuario

operarlo y controlarlo.

Fórmula 4.1.1.1: Factibilidad de uso

��

��

��

��

��

��

Donde:

��: Módulo i esimo del sistema

� : Número total de módulos del sistema

Fuente: [Olsina, 1999]

Los resultados de la evaluación de los criterios de factibilidad son los siguientes.

Tabla 4.1: Factibilidad de uso del sistema

Usuarios\Factibilidad de ser Comprendido Aprendido Operado

Directorio 98,65 97,87 99,11

Presidente 99,00 98,50 99,30

Gerente Proyecto 99,41 98,99 97,98

Director administrativo 99,65 98,43 99,76

Promedio 99,18 98,45 99,04

Factibilidad de Uso es 98,89%


La usabilidad resultante de los usuarios del sistema es del 98.89 % por lo tanto el nivel de

usabilidad es aceptable.

4.1.2 Confiabilidad

La confiabilidad de un sistema de información es muy importante para determinar la calidad.

Este análisis se basa en la operación de puntos discretos de tiempo. El sistema web falla si

uno de sus componentes falla, esto es en el caso de que el sistema presente sus componentes

en serie por lo cual se tiene la siguiente formula.

103

Fórmula 4.1.2.1: Probabilidad de que el sistema falle

� � ��Donde:

� : La probabilidad falla total del sistema

�� : Probabilidad de falla módulo i esimo



Por lo tanto el sistema falla si y solo si todos sus componentes fallan. Esto quiere decir que

cada módulo tiene una confiabilidad.

Fórmula 4.1.2.2: Confiabilidad del módulo i del sistema

� � � � ��Donde:

�: La confiabilidad del módulo i

�� : Probabilidad de falla módulo i esimo


Entonces la confiabilidad del módulo i es inversamente proporcional a la probabilidad de

error, por lo tanto la confiabilidad del sistema está dada por la siguiente fórmula.

Fórmula 4.1.2.3: Probabilidad de que el sistema no falle

� � ��

� � ��

�� }*100

Donde:

�: Confiabilidad del módulo i



104

Para el análisis del sistema de información web es necesario especificar que el sistema

actualmente cuenta con ocho módulos que se describirán en orden con (Ri) sucesivamente.

La probabilidad de fallo es solo viable por un corte del servicio de comunicación vía internet

o falta de mantenimiento en los servidores, cabe resaltar que el sistema tubo una serie de

pruebas de caja blanca y caja negra que establecen un nivel alto de confiabilidad.

Los módulos del sistema de información son

• R1 Módulo de proyecto;

• R2 Módulo de componente y actividad;

• R3 Módulo de indicadores de efecto o producto con hitos de control;

• R4 Módulo de notificaciones por cuantías de tiempo y ejecución presupuestaria;

• R5 Módulo de presupuesto;

• R6 Módulo de seguimiento físico y financiero;

• R7 Módulo monitoreo físico y financiero;

• R8 Módulo de servicios web.

Donde la probabilidad de operación con error y sin error está dado por el siguiente vector qie

corresponde a todos los módulos del sistema de información detallado anteriormente:

Tabla 4.1.2.1: Márgenes de error del sistema

��

��

��


Aplicando las formula de confiabilidad se tiene:

CS = {1-[(1-R1) + (1- R2) + (1-R3) + (1-R4) + (1-R5) + (1-R6)+ (1-R7) + (1-R8)]} * 100 =

CS= {1-[(1-0,996) + (1-0,992) + (1-0,997) + (1- 0,997) + (1-0,998) + (1- 0,999) + (1-0,999)

+ (1-0,996)]} * 100 =

105

CS= [1-(0,004+0,008+0,003+0,003+0,002+0,001+0,001+0,004)]*100 =

CS= (1-0,026)*100=97,4 %.

Por lo tanto se concluye que el sistema web tiene una confiabilidad del 97,4 %, información

favorable para el producto de software.

4.1.3 Funcionalidad

La métrica de punto función, se usa de manera efectiva como medio para medir la

funcionalidad que entrega el sistema.

Se empleando datos históricos, el PF se usa para:

• Estimar costo y el esfuerzo requerido para diseñar, codificar y probar el software.

• Predecir el número de errores que se encontraran durante la prueba.

• Estimar el número de componentes, de líneas de código en el sistema implementado.

Para determinar la funcionalidad se deben medir el número de entradas del usuario, salidas

del usuario, peticiones, archivos, interfaces externas.

Las funciones son aquellas que satisfacen las necesidades implícitas y/o explicitas.

Para calcular se utiliza la fórmula:

Fórmula 4.1.3.1: Funcionalidad aplicando punto función

��

��

�Donde:

�� : Funciones del módulo i


Fuente: [COSMIC, 1982]

106

• Número de entradas de usuario, representa cada entrada de control de usuario que llega

desde la frontera externa y que proporciona diferentes datos de aplicación.

Tabla 4.1.3.1: Número de entradas de usuario

Nro. Descripción de entrada Cantidad

1 Registro e ingreso al sistema 4

2 Registro de proyecto 1

4 Registro de indicadores de efecto e hitos de control 3

6 Registro de componente 1

8 Registro de indicadores de producto e hitos 3

10 Registro de actividad 1

12 Registro de cuantías por tiempo para notificaciones 3

14 Registro de cuantías por ejecución financiera para notificaciones 3

16 Registro de ítems de presupuesto 5

18 Registro de estado de hitos de indicador de efecto 1

19 Registro de estado de hitos de indicador de producto 1

20 Registro de cumplimiento de actividad 1

21 Registro de ejecución financiera por ítem 2

Total 29

• Número de salidas de usuario, representa cada salida de información referente a la

aplicación del sistema web.

Tabla 4.1.3.2: Número salidas de usuario

Nro. Descripción de salida Cantidad

1 Notificación de validación de formularios ingreso de información 59

2 Reporte de proyectos, componentes, actividades, indicadores y otros. 16

5 Confirmación de eliminaciones 12

Total 87

107

• Número de peticiones de usuario, representa cada combinación, entrada /salida única,

donde una entrada causa y genera una salida inmediata, es decir una respuesta del

software.

Tabla 4.1.3.3: Número de peticiones de usuario

Nro. Descripción de entrada Cantidad

1 Actualización de registro de proyecto 6

2 Actualización de indicador de efecto e hitos de control 3

3 Actualización de registro de componente 1

4 Actualización de indicador de producto e hitos 3

5 Actualización de registro de actividad 1

6 Actualización de cuantías por tiempo para notificaciones 3

7 Actualizar cuantías por ejecución financiera para notificaciones 3

8 Actualización de registro de ítems de presupuesto 5

9 Actualización de registro de ejecución financiera por ítem 2

Total 27

• Número de archivos, es cada archivo maestro lógico, es decir es un grupo lógico de datos

que puede ser parte de una gran base de datos o un archivo independiente.

Tabla 4.1.3.4: Número de archivos

Nro. Descripción de archivos Cantidad

1 Reporte de proyecto en programación 1

2 Reporte de proyecto en ejecución 1

3 Reporte de resultados del proyecto 1

Total 3

• Número de interfaces externa, todas las interfaces legibles por la máquina que se utilizan

para transmitir información a otro sistema, por ejemplo archivos de datos.

108

Tabla 4.1.3.5: Número de interfaces externas

Nro. Descripción de interfaces Cantidad

1 Front end 1

2 Back end 1

3 Notificaciones y alertas por correo electrónico 2

Total 4

Los criterios desarrollados deben ponderarse como baja, media, alta según [Pressman, 2003]:

Tabla 4.1.3.6: Factores de complejidad

Factores de medida Complejidad ResultadosFactor Cuenta Simple Media Alta Total

Número de entradas 29 * 3 4 6 = 174Número de salidas 87 * 4 5 7 = 435Número de peticiones 27 * 3 4 6 = 162Número de archivos 3 * 7 10 15 = 30Número de interfaces externas 4 * 5 7 10 = 40

Total 841

Tabla 4.1.3.7: Ajuste de complejidad del producto

N. Característica 0 1 2 3 4 5 X 1 Requiere el sistema de copias de seguridad y recuperación x 5

2 Requiere de comunicación de datos x 5

3 Existen funciones de procesamiento distribuido x 5

4 El rendimiento es crítico x 5

5 Sera ejecutado el sistema en un entorno existente y fuerte x 5

6 Se requiere entrada de datos en línea x 5

7 Se requiere entrada de datos interactiva en varias pantallas x 4

8 Se actualizan los datos maestros en forma interactiva x 5

9 Son complejas las entradas, salidas, peticiones de archivos x 4

10 Es complejo el procesamiento interno x 5

11 Se ha diseñado código reutilizable x 5

12 Están incluidas en el diseño la conversión e instalación x 4

13 Se ha diseñado sistema instalación en varias instituciones x 5

14 Se ha diseñado el sistema para facilitar cambios del usuario x 5

Total 67

109

Aplicando los datos obtenidos en las anteriores tablas se calcular el punto función máximo y

el punto función real para estimar el nivel de funcionalidad más próximo a la realidad.

Calculando el punto función con la variable de ajuste se tiene:

�� 1110,12

Calculando el punto función máximo se tiene:

��

Por lo tanto la funcionalidad es:

��

� � ��

Por lo tanto la funcionalidad del sistema representa el 97,77%, teniendo en cuenta el punto

función máximo. Lo que nos indica que el sistema cumple con los requisitos funcionales de

forma satisfactoria.

4.1.4 Fiabilidad

La fiabilidad es una característica importante porque existe la reutilización de código, para

su estimación se toma en cuenta la frecuencia y magnitud de los errores.

Fórmula 4.1.4.1: Fiabilidad del sistema

� � � � � ��

Donde:

� : La fiabilidad


Aplicando la fórmula, donde la cantidad de líneas estimada con el COCOMOII es de 28,594.

�� !�"�" � #� � #$%& '()� � #$$ � (( (*�

110

En conclusión el sistema de tiene un nivel de calidad de 98,54 % como se muestra en la

siguiente tabla.

Tabla 4.1.4.1: Promedio de factores de calidad

Detalle Resultado de la evaluación

Factibilidad de uso 99,04

Confiabilidad 97,40

Funcionalidad 97,77

Fiabilidad 99,96

Total de calidad 98,54


4.2 Seguridad

La seguridad en un sistema de información concentra sus esfuerzos en mantener la integridad,

confiabilidad y confidencialidad las tres antes mencionadas deben resguardas la información.

• Integridad, el contenido y significado de información no debe ser alterado transferencia.

• Confiabilidad, el servicio debe estar disponible en todo momento.

• Confidencialidad, impedir el acceso a personas, sistemas u otros que no sean autorizadas.

Figura 4.2.1: Conceptos de seguridad sobre la información Fuente: [Elaboración propia]

Este proyecto considera que el sistema de información debe ser seguro en la base de datos,

aplicación, comunicación y seguridad física.

111

4.2.1 Seguridad de la base de datos

Realizar operaciones como la lectura o almacenamiento de información implica realizar un

enlace con un gestor de bases de datos, para la administración segura es necesario realizar el:

• Control de accesos y privilegios para la manipulación de información, la conexión a un

servidor MySQL se aceptará o rechazará basándose en su identidad. Si la información de

identidad es correcta, el servidor acepta la conexión, y entra en espera peticiones, caso

contrario el acceso es denegado.

Los programas del sistema de información de este proyecto se conectan con el gestor de

base de datos por medio de la librería conectar.php, donde existe la función fconectar()

que se encarga de especificar el nombre del servidor, el usuario, la contraseña y la base de

datos con la que se desea trabajar.

• Cifrado de información sensible en la base de datos, los sistemas de información siempre

requieren el aseguramiento de la información sensible en la base de datos para ellos es

necesario aplicar algoritmos de encriptación como MD5, SHA1, SHA2.

Para asegurar las contraseñas de acceso al sistema se aplicó en método de encriptación

SHA2 con un procedimiento almacenado usr_verifica donde se combina una longitud con

la clave a encriptar este resultado se guarda en la tabla usuario en la columna contraseña.

• Supervisión de las entradas que solicitan información, significa que se debe guardar las

transacciones realizadas en el gestor de base de datos almacenando en una tabla la fecha

y hora, tipo de conexión, y la consulta realizada.

Para controlar las transacciones en el sistema de información se habilito el general_log en

MySql, también se almacena en todas las tablas el usuario, fecha y hora de transacción.

• Procedimientos almacenados, son funcionalidades del MySQL 5.0 o superior. Un

procedimiento almacenado es un conjunto de comandos SQL almacenados en el servidor.

112

Para realizar las transacciones el sistema trabaja con procedimientos almacenados, con el

comando CALL son llamados con el PHP, mejorando la seguridad y tiempo de respuesta.

Figura 4.2.1.1: Procedimientos almacenados en MySqlFuente: [Elaboración propia]

• Pruebas de inyección, son ataques de vulnerabilidad por errores de programación.

El sistema fue sometido a pruebas de SQL inyección resultados fueron satisfactorios.

Figura 4.2.1.2: Resultados de las pruebas SQL inyección Fuente: [Elaboración propia]

113

4.2.2 Seguridad en la aplicación

Los errores en la codificación de la interfaz de usuario con los servidores generan espacios

que pueden ser aprovechados por los spywars, robots y hackers y crakers, es necesario

prevenir estos ataques con:

• Autenticación de cliente y captcha, la autenticación del cliente es un mecanismo de

control de acceso del usuario, el capcha es una adivinanza trivial fácil de resolver.

En el sistema utiliza mecanismos de control en el formulario de inicio del sistema y se

controlan el cumplimiento de las mismas dentro del sistema, se validan los campos con la

librería Jquery-validate, se genera una imagen captcha que con la librería capcha.php cada

minuto, la sesión solo puede estar activa por 10 minutos sin actividad luego se cierra

automáticamente para prevenir accesos no deseados.

Figura 4.2.2.1: Autenticación de cliente y captcha Fuente: [Elaboración propia]

• Activación de cuenta y recuperación de contraseña por correo electrónico, son medios

de validación del usuario del sistema para asegurar la comunicación con el cliente.

El sistema requiere que el nuevo cliente tenga disponible y activa una cuenta de correo

electrónico, es el único medio que permite su activación, esta cuenta es necesaria para

enviar notificaciones y alertas. Cuando se realiza el cambio de contraseña se utiliza este

correo electrónico para notificarlo y finalmente el correo permite recuperar la contraseña.

114

• Validar la fuerza de la contraseña, es importante utilizar contraseñas seguras, es decir

aquellas que tienen como mínimo más de 10 caracteres de longitud y se alternan entre

números, signos y letras.

Si el usuario cambia su contraseña el sistema se asegura que la fuerza de la contraseña

sea fuerte o muy fuerte como se muestra en la siguiente imagen.

Figura 4.2.2.2: Determinación de fuerza de contraseña por cambio Fuente: [Elaboración propia]

• Aplicación de Tokens para formularios, son variables codificadas enviadas desde los

formularios. Si coincide con lo esperado se realiza la transacción caso contrario no.

El sistema cuenta con el control tokens en todos los módulos, por medio del archivo

enc.php donde la función tokens() de transacciones activa las directivas de seguridad.

• El control de acceso basado en roles (RBAC) es una función de seguridad para controlar

el acceso de usuarios. Mediante la aplicación de atributos de seguridad a procesos y

usuarios, RBAC puede dividir las capacidades en función de roles en la institución.

El modelo de seguridad decide qué papel debe ser autorizado a los usuarios, mediante la

asignación de ese papel a la autorización.

115

Figura 4.2.2.3: Control de acceso basado en roles RBAC Fuente: [Elaboración propia]

El sistema cuenta con un módulo RBAC que se encarga de controlar las acciones de cada

uno de los usuario, los roles que están en un rectángulo y las funcionalidades del sistema que

están en óvalos esta funcionalidad se encuentra en el archivo btn.php y sus funciones de

acceso por niveles que se almacenan en la base de datos en la tabla pfl_btn en MySql.

4.2.3 Seguridad de comunicación

La comunicación entre el cliente y el servidor es necesaria y los medios de comunicación

como el servicio de internet es indispensable el modelo TCP/IP es el modelo de red que se

usa actualmente. La capa de red se encarga

Modelo TCP/IP

Aplicación Nivel perceptible, se establece sesión, se asigna sintaxis y cifrado.

Transporte Nivel de conexión punto a punto, define la calidad de servicio costo beneficio

Red Establece las rutas, conecta nodos inmediatamente adyacentes y funciona con

aspectos mecánicos, físicos, electrónicos y ópticos

116

Este proyecto funciona sobre la capa de aplicación, en el sistema se utilizan sesiones para

establecer la comunicación con el cliente, existe un cifrado de los enlaces con la librería

enc.php y la función url() y la información que se envía con el token funcion enc(), denc().

Las capas de transporte es de libre elección del cliente, el sistema funciona perfectamente

con conexiones DIALUP, ADSL, WIMAX, 2G, 3G, 3G+ LTE de las compañías de

telecomunicaciones como ENTEL, VIVA, TIGO, BOLIVIA TEL, COTAS distribuyen en

servicio y el cliente decide en función de sus necesidades y su disponibilidad económica.

El sistema puede realizar el control de las transacciones remotas con el cliente por medio de

la captura del tipo de usuario, transacción y fecha.

Figura 4.2.3.1: Almacenamiento de logs del sistema en la base de datos Fuente: [Elaboración propia]

4.2.4 Seguridad Física

Consiste en la aplicación de barreras físicas y procedimientos de control, como medidas de

prevención y contramedidas ante amenazas a los recursos e información confidencial. Esto

se refiere a los controles y mecanismos de seguridad dentro y alrededor del centro de cómputo

así como los medios de acceso remoto y desde el mismo implementados para proteger el

hardware y medios de almacenamiento de datos donde se desataca a los:

• Desastres naturales, incendios accidentales, tormentas, inundaciones y humedad;

• Desastres del entorno, electricidad, humo, temperaturas extremas;

• Amenazas ocasionadas por el ser humano, disturbios, sabotajes internos y externos

deliberados.

117

Las amenazas por desastres naturales y entorno en infraestructura son administradas por el

proveedor de web hosting con el que tiene contrato la institución, los encargado del web

hosting hacen copias de seguridad y la imagen de los servicios para mantenerlos disponibles.

Las amenazas ocasionadas por el ser humano es el eslabón que hasta este momento no se

puede controlar, lamentablemente los seres humanos tienen hábitos no recomendables para

almacenar sus claves de acceso, asignar palabras seguras en sus claves y otros factores que

no se puede controlar en sistemas cliente servidor. Por lo tanto el sistema de información

solo puede asegurar un 99,9 % de seguridad desde el punto de vista tecnológico el 0.01% es

una tarea en la que se debe de trabajar en términos de cultura humana y manejo de

información.

4.3 Mantenimiento

Su finalidad optimizar al sistema para que responda nuevas especificaciones, corregir errores,

aumentar la productividad. Las operaciones de mantenimiento son inevitables cuando se

construyen sistemas de información basados en computadores debido a la evolución en el

tiempo de las tecnologías y paradigmas de manejo de información por ello es necesario

evaluar, controlar y ajustar aspectos técnicos inminentemente.

4.3.1 Mantenimiento correctivo

Independientemente de cuán bien sea diseñado, desarrollado y probado un sistema, ocurrirán

errores inevitablemente, por ejemplo la falta de una característica requerida de un usuario.

Para resolver estos eventos futuros que con seguridad ocurrirán este proyecto tiene disponible

el manual técnico en el Anexo A que contiene información técnica referente a la ubicación

de los archivos, los programas, librerías, estructura de base de datos y el diccionario de datos.

4.3.2 Mantenimiento para fines específicos

Este tipo de mantenimiento se refiere a la creación de características nuevas o a la adaptación

de las existentes según lo requieren los cambios en la organización o los usuarios. El personal

118

técnico podrá resolver estos requerimientos específicos consultando el Anexo B para

verificar la funcionalidad, también puede usar el manual técnico en el Anexo A que contiene

información técnica para realizar los ajustes específicos necesarios.

4.3.3 Mantenimiento para mejoras

Se trata de la extensión o el mejoramiento del desempeño del sistema, por ejemplo la

conversión de los sistemas de texto al interfaz gráfico. El personal técnico podrá mantener

el sistema apoyándose en la información del manual técnico en el Anexo A que contiene

información técnica referente al sistema con la ubicación de los archivos.

4.3.4 Mantenimiento preventivo

Este tipo de mantenimiento es uno de los más frecuentes y generan costos nuevos, su

finalidad es evitar serios problemas en el sistema, un ejemplo el no funcionamiento en nuevas

plataformas de sistemas operativos o navegadores y otras que generan la actualización de la

tecnología. El personal técnico podrá mantener el sistema apoyándose en la información del

manual técnico en el Anexo A para actualizar las librerías

Capítulo V

Evaluación Costo, Beneficio

119

5. Evaluación Costo - Beneficio

5.1 Introducción

Los costos asociados con el sistema deben ser calculados para determinar el costo total del

proyecto con los modelos COCOMOII, VAN y el TIR.

5.2 Cálculo del costo del software con el modelo COCOMO II

El modelo constructivo de costos (COCOMO® II) es un modelo que permite estimar el

costo, el esfuerzo y el tiempo en la planificación de un proyecto de software. Utilizado

frecuentemente para la configuración de los presupuestos y programas de proyectos.

Fórmula 5.2.1: Esfuerzo

+�, ��-� � � �� +�� .��/��Donde:

KSLOC : Cantidad de línea de código

+�� : Factor de ajuste de esfuerzo derivado de los drivers

+ : exponencial E, explica el ahorro o gasto relativo

Fuente: [Boehm, 1998]

La estimación de ahorro o gasto relativo de la anterior formula se obtiene con la formula

Fórmula 5.2.2: Ahorro o gasto relativo

+ � � ��

��

Donde:

�� : Factores de escalamiento


Se requiere aplicar las tablas de diseño temprano de esfuerzo EAF, la escala de factores SF,

la conversión a puntos función de los lenguajes de programación y los pesos de ponderación

por módulo SLOC que se describen a continuación en las siguientes tablas.

120

Tabla 5.1.1: Diseño temprano de Esfuerzo EAF

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto P

rod

uct

o

RELY Se requiere confiabilidad software

DATA Tamaño de la base de datos

CPLX La complejidad del producto

RUSE Obligatorio reutilización

DOCU Partir de documentación a las necesidades del ciclo de vida

Pla

tafo

rma TIME Restricción de ejecución por tiempo

STOR Principal Almacenamiento restricción

PVOL Volatilidad de plataforma

Per

son

al

ACAP Capacidad de análisis

PCAP Capacidad Programador

PCON Personal continuo

AEXP Experiencia en aplicaciones

PEXP Experiencia en plataforma

LTEX Experiencia en el lenguaje de herramienta

Pro

yect

o

TOOL El uso de herramientas de software (HERRAMIENTA)

SITE Desarrollo múltiple de sitios

Usu

ari

o

SCED Desarrollo del Cronograma Obligatorio

User1 Otras caaracteristicas definidas por el usuario


A continuación se presenta la escala de factores para el cálculo con el modelo COCOMOII

Tabla 5.1.2: Escala de factores SF

Scale Factors Very Low Low Nominal High Very High Extra High

PREC Precedentes

FLEX Flexibilidad para el Desarrollo

RESL Arquitectura / Resolución de Riesgos

TEAM Equipo de Cohesión (TEAM)

PMAT Madurez de Procesos (PMAT)


121

Tabla 5.1.3: Lenguaje de conversión a puntos función

Language SLOC / UFP

Ada 71

AI Shell 49

APL 32

Assembly 320

Assembly (Macro) 213

ANSI/Quick/Turbo Basic 64

Objet-oriented 29

Basic – Interpreted 128

C 128

C++ 29

… …


Para conversión de las líneas de código a puntos función se utiliza la tabla 5.1.3.

Tabla 5.1.4: Pesos complejidad para aplicación

Complejidad – Peso

Tipo de función Bajo Medio Alto

Archivos Lógica Interna 7 10 15

Externo Archivos Interfaces 5 7 10

Entradas externas 3 4 6

Salidas externas 4 5 7

Consultas 3 4 6


Es necesario establecer los pesos de cada módulo tomando en cuenta la tabla 5.1.4

122

Para la estimación se aplicara el software USC-COCOMO2, primero se define la escala de

factores SF para todo el proyecto, se establece por módulo el EAF, SLOC, Costo/Mes y el

software se encarga de hacer la estimación por módulo y proyecto.

Se define el nombre del proyecto en este caso Seguimiento y Monitoreo de Proyectos para

Resultados (SyM PxR), y se define la estimación en post arquitectura.

Figura 5.2.1: Definición del Proyecto en el USC-COCOMO II Fuente: [Elaboración propia]

Se define la escala de factores para todo el proyecto donde la referencia de proyectos

precedentes, la flexibilidad de desarrollo, la arquitectura y resolución como alto con un

incremento del 50%, la cohesión del equipo de trabajo como alto y la madurez de los proceso

estimado es extra alto, Donde la escala de factores SF es 7,69.

Figura 5.2.2: Definición de la escala de factores Fuente: [Elaboración propia]

123

A continuación se debe estableces los parámetros por módulo el diseño temprano de esfuerzo

EAF, también se establece la conversión de puntos función y los pesos de complejidad SLOC

y finalmente se establece el costo por mes en $ para el modulo. Se describirá el proceso para

el modulo proyecto del sistema de información presente.

Se establece los parámetros de diseño temprano de esfuerzo EAF para el modulo proyecto,

donde se establece las características del producto RELY, DATA, DOCU, CPLX y RUSE

como nominales, sobre la plataforma el TIME, STROR y PVOL son nominales, en cuanto al

personal ACAP, PCAP, PCON, APEX, LTEX PLEX son altos, sobre el proyecto TOOL

SITE son nominales y los usuarios USR1 y USR2 son nominales.

Figura 5.2.3: Definición EAF para el módulo proyecto del sistema en COCOMOII Fuente: [Elaboración propia]

Se establece el lenguaje para la conversión a puntos función y orientado a objetos

124

Figura 5.2.4: Definición puntos función y lenguaje de programación COCOMOII Fuente: [Elaboración propia]

Se procede a establecer los pesos de complejidad del módulo proyecto del sistema donde se

determina que la cantidad de entradas como alto y una cantidad de 3, las salidas son 3 y altas,

los archivos utilizados son 5 en un nivel alto, las interfaces del módulo son 3 de nivel

promedio y las consulta realizadas son 6 el resultado del software nos da un total de 171

puntos función y un total de línea de código SLOC de 4959 como se puede observar.

Figura 5.2.5: Definición por tipo de función en COCOMOII Fuente: [Elaboración propia]

125

La etapa final de este proceso es la definición del costo por mes del módulo en LABOR Rate.

Figura 5.2.6: Definición costo del módulo proyecto en COCOMOII Fuente: [Elaboración propia]

El proceso se lo debe realizar en todos los módulos del sistema de información y el software

se encarga de estimar el costo, esfuerzo y tiempo.

El sistema tienen 11 módulos se obtuvieron los siguientes resultados, el total de líneas de

código estimado es de 28594 con una carga laboral de 152 horas por mes.

Figura 5.2.7: Resultados del proyecto en COCOMOII Fuente: [Elaboración propia]

Por lo tanto se tiene como resultado de la aplicación del software, el tiempo estimado real de

11 meses el nivel de productividad es de 692 líneas, el costo en dólares norte americanos es

de 10201,91.- $, la cantidad de personas requeridas es de 4. Asumiendo un nivel optimista.

126

Tabla 5.1.5: Tabla resultante COCOMOII

Estimación Tiempo Costo Personas

Optimista 11 10201,91 3,8

Normal 11,8 12752,38 4,4

Pesimista 12,6 15940,48 5,1

Fuente: [Elaboración Propia]

5.3 Cálculo del Valor Neto Actual

Es un indicador financiero que mide los flujos de los futuros ingresos y egresos que tendrá el

proyecto, para determinar si luego de desconectar la versión inicial, nos quedaría alguna

ganancia. Si el VAN es mayor o igual a cero entonces es viable caso contrario no.

El VAN permite determinar cuál proyecto es el más rentable entre varias opciones de

inversión.

Fórmula 5.3.1: Valor neto actual

0�1 � 21� � ��3Donde:

21� : Beneficio neto actualizado

��3 : Inversión en el desarrollo


La tasa de descuento (TD) con la que se descuenta el flujo neto proyectado, es la tasa de

oportunidad, rendimiento o rentabilidad mínima, que se espera ganar, por lo tanto cuando la

inversión resulta mayor que BNA el VAN es negativo. Si el VAN e igual o mayor a BNA

entonces es aceptable y rentable.

5.4 Cálculo de la Tasa Interna de Retorno

El TIR es la máxima tasa de descuento que puede tener un proyecto, para su cálculo se

requiere conocer el tamaño de inversión y el flujo de caja neto proyectado.

127

Para el cálculo del VAN es necesario establecer la tabla de costos para 24 meses del proyecto.

Tabla 5.4.1: Costos del proyecto estimado en 24 meses


La fórmula de VAN requiere para su cálculo de la tasa de interés de ahorro por mes definido

por las ASFI que actualmente es 1,073 % por mes.

Aplicando la fórmula del VNA(tasa;valor1;[valor2];...) de Microsoft Excel se tiene Bs

89.038,36 VNA para el proyecto.

Tabla 5.4.2: Ingresos del proyecto estimado en 24 meses


Aplicando la fórmula del VNA(tasa;valor1;[valor2];...) de Microsoft Excel se tiene Bs

100.986,2 VNA para el proyecto. Por lo tanto el VAN de ingresos es mayor al VAN costos

que hace viable al proyecto.

Tabla 5.4.3: Flujo de caja estimado en 24 meses


��

��

��

��

��

��

��

�� !"�!� ��

#��

$�%��"��

&��'��% � ��

��

��(� ��)��

*��

+,+�- ��)� ��

��

��

��

��

��

��

��

� � � � � � � � ��

��

��

��

��

128

Aplicando la fórmula del TIR(valores, [estimación]) de Microsoft Excel se tiene 2,417% que

es superior a la Tasa de interés de 1,073% en un 200%, por lo tanto este hecho hace rentable

al proyecto respecto de mantener la inversión en el banco, también el TIR es 2,417% >0 y

esto significa que se debe llevar adelante el proyecto por su rentabilidad.

Tomando en cuenta la relación de beneficios y costos del proyecto se tienes

Fórmula 5.4.1: Nivel de recuperación de inversión

��3��

�2 � � ��

Donde:

� : ahorro

2 : Inversión


Realizando el cálculo se obtienes 3,18 Bs.

�

��

��

��

Restando 1Bs invertido a la utilidad 3,18Bs. se tiene 2,18Bs. de ganancia, por los tanto es

rentable.

Capítulo VI

Conclusiones y Recomendaciones

129

6. Conclus iones y Recomendaciones

6.1 Conclusiones

Este proyecto es producto de la aplicación del método científico donde fue necesario

combinar metodologías, técnicas y herramientas con los conceptos de la gestión por

resultados orientados a los proyectos, logrando responder los objetivos específicos

planteados inicialmente en el presente trabajo de la siguiente manera:

• Tener la información de los proyectos organizado y en línea;

El sistema web permite la organización y la disponibilidad de los proyectos que lleva adelante

la institución tras la implementación de los módulos: proyecto, componente, actividad y

presupuesto, en la dirección www.smpr.cadelp.com

• Aplicar conceptos de la gestión por resultados;

El sistema web comporta de acuerdo a los conceptos de la Administración de Proyectos

tomando en cuenta los conceptos de la Gestión por Resultados con los módulos: indicadores

de efecto (proyecto), indicadores de producto (componente) para alcázar los impactos

definidos inicialmente en el proyecto.

• Automatizar el seguimiento y monitoreo de indicadores;

El sistema web ayuda al personal gerencial en la toma de decisiones con la información base

que generan los módulos de: seguimiento físico (estado de indicadores de efecto y producto,

estados de actividades) y seguimiento financiero (estado de ejecución presupuestaria por

ítems).

• Notificar y alertar el estado de los proyectos por e-mail;

Este producto cuenta con dos servicios web: el servicio web de notificaciones (se encarga del

en vio de email a los usuarios entorno del proyecto con información preventiva, informativa)

y el servicio web de alertas (se encarga de enviar alertas por desfases considerables en los

indicadores de producto y efecto o no reportar el estado final de las actividades)

130

• Agilizar la reprogramación mediante el monitoreo en términos de tiempo y presupuesto;

El sistema permite reprogramar las actividades y el presupuesto por ítems en la fase de

ejecución de proyecto si el monitoreo de la institución lo considera necesario, con la finalidad

de lograr resultados positivos en el proyecto.

Por los tanto se logró “Implementar un Sistema Web para el Seguimiento y Monitoreo de

Proyectos Orientados a Resultados”, que apoya en la toma de decisiones inmediatas para el

Colegio de Administradores de La Paz”, solucionando los problemas existentes de manera

satisfactoria y exitosa.

6.2 Recomendaciones

Concluido el presente proyecto de grado se plantean las siguientes recomendaciones:

• Con la finalidad de mejorar la seguridad se recomienda adicionar el alquiler del hosting

el protocolo de comunicación HTTPS para que el sistema funcione más seguro en un

entorno de internet compartido;

• Utilizar cuentas institucionales de correo electrónico para evitar que las notificaciones y

alertas sean enviadas a la carpeta de spams o correo no deseado;

• Establecer nuevas políticas en la institución para que los usuarios que utilicen el sistema

alcancen una motivación que contribuya en las buenas prácticas profesionales;

• Vincular el sistema de información con el sistema contable de la institución;

• Adicionar el módulo de notificaciones por SMS de telefonía con números cortos;

• Generar uno o varios web servicie y aplicaciones compatibles con Android Apple

Windows y Mozilla para interactuar con el sistema de información en equipos móviles;

• Asignar un módulo de georreferenciación de los proyectos para desplegar indicadores

regionales;

• Realizar un back tracking del modelo para optimizarlo.

ANEXO A

Manual Técnico

Manual Técnico

SISTEMA WEB DE SEGUIMIENTO Y MONITOREO DE PROYECTOS ORIENTADOS A RESULTADOS

(SMPR)

La Paz – Bolivia

Noviembre, 2015

44

Contenido 1.� Manual de usuario ....................................................................................................................... 1�

1.1� Bienvenida ........................................................................................................................ 1�

1.2� Prefacio ............................................................................................................................. 1�

2.� Requerimientos del Sistema ......................................................................................................... 2�

2.1� Introducción ...................................................................................................................... 2�

2.2� Requerimientos de conocimientos del usuario .................................................................... 2�

2.3� Requerimientos mínimos tecnológicos ............................................................................... 2�

2.4� Servicios necesarios ........................................................................................................... 3�

3.� Cómo instalar el sistema WEB..................................................................................................... 4�

3.1� Programas y Base de datos ................................................................................................. 4�

3.2� Programas en el servidor .................................................................................................... 4�

3.2.1� Organización de archivos ...................................................................................... 4�

3.2.2� Contenido por directorio del sistema ...................................................................... 5�

3.2.3� Funciones de los archivos programados ................................................................. 6�

3.2.4� Ubicación de librerías externas ............................................................................ 32�

3.2.5� Copia de Seguridad ............................................................................................. 32�

3.3� Base de datos en el servidor ............................................................................................. 34�

3.3.1� Modelo de la Base de datos ................................................................................. 35�

3.3.2� Diccionario de datos ............................................................................................ 35�

3.3.3� Procedimientos almacenados ............................................................................... 41�

3.3.4� Copia de seguridad .............................................................................................. 41�

3.3.5� Restaurar Base de datos ....................................................................................... 41�

3.4� Configuración del archivo conectar .php .......................................................................... 42�

4.� Preguntas Frecuentes ................................................................................................................. 43�

4.1� Sobre el sistema ............................................................................................................... 43�

1

1. Manual de usuario

1.1 Bienvenida

Bienvenidos al manual de usuario del Sistema Web de Seguimiento y Monitoreo de Proyectos para

Resultados en este documento usted encontrara toda la información necesaria para operar el

sistema.

1.2 Prefacio

Capítulo I: Se brinda una bienvenida al usuario, se presenta un prefacio del manual, se realiza una

introducción del sistema.

Capítulo II: Se expresan los requerimientos de conocimientos del usuario, requerimientos mínimos

tecnológicos, servicios necesarios. Requerimientos que son necesarios procesos de instalación,

sacar copias de seguridad, restaurar el funcionamiento, adicionar un nuevo módulo o ajustar el

sistema de información.

Capitulo III: Se explica cómo instalar el sistema, los programas y la base de datos, los programas

en el servidor y su funcionalidad, donde se expresa la ubicación, funcionalidad y copia de

seguridad, en la base de datos, se muestra el modelo, el diccionario de datos, copia de seguridad

proceso de restauración.

Capítulo IV: Se presenta las preguntas más frecuentes que surgen el momento de trabajar con el


2

2. Requerimientos del Sistema

2.1 Introducción

El sistema de información web para el seguimiento y monitoreo de proyectos para resultados

(SMPR) es una herramienta para la toma decisiones que tiene requerimientos en cuanto se refieres

a los usuarios, equipos, sistemas operativos, navegadores y mecanismos de acceso.

2.2 Requerimientos de conocimientos del usuario

Para brindar soporte y mantenimiento del sistema de información es necesario un perfil en términos

de conocimientos en:

• Enlace FTP, este protocolo de comunicación permite una conexión con la carpeta del sistema

de información.

• Manejo de PhPMyadmin, capacidades para crear base de datos, cambiar el collage de la base

datos a Spanis1, importación de la base de datos e instalar los procedimientos almacenados.

• Instalar CRON, activar los servicios de notificaciones configurando la ejecución del servicio cada

hora.

• Activar copias de seguridad de folders, el proveedor de Web Hosting brinda la posibilidad de

hacer copias de seguridad, estos deben ser activados.

• Activar copias de seguridad en la base de datos, configurar la copia de seguridad periódica de la

base de datos y se envía la misma a un correo electrónico.

2.3 Requerimientos mínimos tecnológicos

Se requiere de un servidor DNS, servidor Apache, servidor de base de datos MySql.

También se puede alquilar un Web Hosting con servidores Apache, phpMyadmin, MySql y Linux.

Se requiere de un navegador web:

- Internet Explorer superior a la versión 10 o superior

- Edge versión 8 o superior

- Mozilla desde la versión 10 o superior

- Opera versión 10 o superior

- Safari versión 13 o superior

3

- Chrome versión 11 o superior

2.4 Servicios necesarios

El usuario necesita de servicios de conexión de internet para el acceso de al SMPR en Bolivia las

empresas que brindan estos servicios son:

- ENTEL (ADSL, WIMAX, 2G, 3G, 3G+, LTE)

- TIGO (WIMAX, 3G, 3G+, LTE)

- VIVA (WIMAX, 3G, 3G+, LTE)

- COTEL(DIALUP, ADSL)

- COTAS(ADSL, WIMAX)

El usuario tiene la libertad de elegir su proveedor y el servicio que mejor se acomode a sus

bolsillos, la velocidad mínima requerida es de 120kbps se recomienda conexiones ADSL o 3G+ o

superior

4

3. Cómo instalar el sistema WEB

3.1 Programas y Base de datos

El sistema de información fue desarrollado con software libre. Para la programación se utilizó PHP,

JavaScript, HTML, CSS. El medio para almacenar información es el gestor de base de datos MySql,

para la administración del gestor de base de datos se utiliza phpMyadmin.

3.2 Programas en el servidor

Los programas y librerías desarrollados en este proyecto son ejecutados del lado del servidor esta

información es enviada al cliente mediante el protocolo http.

3.2.1 Organización de archivos

�� Carpeta ��

�� ini ��

�� slr ��

�� ins ��

�� ins_org ��

�� ins_usr ��

�� ins_proy_com ��

�� proy_ind ��

� ins_proy_ppto !��

"� Proy !��

�#� proy_pre_inv !��

�� proy_inv $%��

�� proy_post_inv !�� %��

�� com_ind ��

�� Alertas &�� '��

�� proy_ind_ (��

�� proy_indico (��

�� ins_proy_com_ �� %��

� � com_ind_ )��%��

�"� proy_ind_hito *��

�#� com_ind_hito *��

�� ins_proy_ppto_ (��%��

�� ins_proy_ppto_eje_ $%��'��

�� Index.php !+��

�� Very.php ��,��+��

5

3.2.2 Contenido por directorio del sistema

Nro Carpeta Archivo y enlace Funcionalidad

1 ini ../ini/index.php Inicio archivo menú principal del sistema

2 slr ../slr/index.php Salir del sistema de información

3 ins ../ins/index.php Información institucional

4 ins_org ../ins_org/ Estructura organizacional

5 ins_org ../ins_usr/ Usuarios del sistema de información

6 ins_usr add_usr.php Adicionar usuarios

7 ins_usr mod_usr.php Modificar usuarios

8 ins_usr psw_usr.php Cambio de contraseña de usuario

9 ins_usr grb_del_usr.php Eliminar usuarios

10 ins_proy_com index.php Programación de componentes y actividades

11 ins_proy_com a_proy_con.php Adicionar Componentes

12 ins_proy_com m_proy_con.php Modificar Componentes

13 ins_proy_com grb_del_proy_con.php Eliminar Componentes

14 ins_proy_com ../ins_proy_com_act/add_proy_com_act.php Adicionar Actividades

15 ins_proy_com ../ins_proy_com_act/mod_proy_com_act.php Modificar Actividades

16 ins_proy_com ../ins_proy_com_act/del_proy_com_act.php Eliminar Actividades

17 proy_ind ../proy_ind/ Indicador Efecto

18 proy_ind a_ind.php Adicionar Indicador de efecto

19 proy_ind m_ind.php Modificar Indicador de efecto

20 proy_ind e_ind.php Eliminar Indicador de efecto

21 proy_ind ../proy_ind_hito/a_indh.php Adicionar Hito de indicador de efecto

22 proy_ind ../proy_ind_hito/m_indh.php Modificar Hito de indicador de efecto

23 proy_ind ../proy_ind_hito/e_indh.php Eliminar Hito de indicador de efecto

24 ins_proy_ppto index.php Programación ítem de presupuesto

25 ins_proy_ppto add_pto.php Adicionar ítem de presupuesto

26 ins_proy_ppto mod_pto.php Modificar ítem de presupuesto

27 ins_proy_ppto grb_del_proy_pto.php Eliminar ítem de presupuesto

28 proy ../proy/ Acceso a proyectos según fase

29 proy_pre_inv index.php Lista de proyectos en programación

30 proy_pre_inv a_proy.php Adicionar Proyecto

31 proy_pre_inv m_proy.php Modificar proyecto

32 proy_pre_inv e_proy.php Eliminar proyecto

33 proy_inv index.php Lista de proyectos en fase de ejecución

34 proy_post_inv index.php Lista de proyectos con resultados

35 proy_post_inv ../tcpdf/examples/resultados.php Reporte PDF

36 com_ind ../com_ind/ Lista de indicadores producto

37 com_ind a_ind.php Adicionar Indicador de producto

6

Nro Carpeta Archivo y enlace Funcionalidad

38 com_ind m_ind.php Modificar Indicador de producto

39 com_ind e_ind.php Eliminar Indicador de producto

40 com_ind ../com_ind_hito/a_indh.php Adicionar Hito de indicador de producto

41 com_ind ../com_ind_hito/m_indh.php Modificar hitos de indicador de producto

42 com_ind ../com_ind_hito/e_indh.php Eliminar hitos de indicador de producto

43 alertas index.php Lista de cuantías por tiempo y presupuesto

44 alertas ../alertasxejec/a_aejepro.php Adicionar cuantía ejecución presupuestaria

45 alertas ../alertasxejec/m_aejeper.php Modificar cuantía por ejecución presupuestaria

46 alertas ../alertasxejec/grb_del_eje.php Eliminar por ejecución presupuestaria

47 alertas ../alertasxtmp/a_atmppro.php Adicionar cuantía por tiempo transcurrido

48 alertas ../alertasxtmp/m_atmp.php Modificar por ejecución de tiempo

49 alertas ../alertasxtmp/grb_del_atmppro.php Eliminar por ejecución de tiempo

50 proy_ind_ ../proy_ind_/ Indicador efecto

51 proy_ind_ a_stdhit.php Reportar estado de hito indicador de efecto

52 proy_indico a_stdhit.php Reportar estado de hito indicador producto

53 ins_proy_com_ index.php Lista de componentes y actividades

54 ins_proy_com_ ../ins_proy_com_act_/add_act_.php Adicionar actividades como reprogramación

55 ins_proy_com_ ../ins_proy_com_act_/mod_act_.php Modificar actividades como reprogramación

56 ins_proy_com_ ../ins_proy_com_act_/del_act_.php Eliminar actividades como reprogramación

57 ins_proy_com_ ../ins_proy_com_act_/e.ph Evaluar cumplimiento de actividad

58 ins_proy_ppto_ index.php Lista de ítems de presupuesto de proyecto

59 ins_proy_ppto_ add_pto.php Adicionar presupuesto en ejecución

60 ins_proy_ppto_ mod_pto.php Modificar presupuesto en ejecución

61 ins_proy_ppto_ grb_del_proy_pto.php Eliminar presupuesto en ejecución

62 ins_proy_ppto_ ../ins_proy_ppto_eje_/ Lista de ejecución por ítem

63 ins_proy_ppto_eje_ a_eje.php Adicionar ejecución

64 ins_proy_ppto_eje_ m_eje.php Modificar ejecución

65 ins_proy_ppto_eje_ e_eje.php Eliminar ejecución

3.2.3 Funciones de los archivos programados

Con la finalidad de brindar información sobre los archivos codificados se presenta las tablas donde

se describen las entras procesos y salidas. Según la siguiente estructura

7

Autenticación

Institución

- Estructura organizacional

- Usuarios (ABMV)

o Cambio de contraseña(M)

Proyecto en programación (ABMV)

- Indicadores de efecto (ABMV)

o Hitos indicadores de efecto(ABMV)

- Componentes (ABMV)

o Indicadores de producto(ABMV)

� Hitos de indicadores de producto(ABMV)

o Actividades(ABMV)

- Presupuesto (ABMV)

- Notificaciones (AVMV)

Proyecto en ejecución

- Seguimiento de hitos de indicadores de efecto(A)

- Seguimiento de hitos de indicadores de producto(A)

- Actividades(A)

- Presupuesto

Ejecución de presupuesto(A)

Proyecto en ejecución

- Reporte final en PDF.

8

index.php

Página de inicio, su función recibir y enviar información autenticación para ingreso al sistema.

Entrada: Cuenta, Contraseña Captcha

Procesos:

- Validar información en formulario con jquery validate - Usuario, diferente de vacío, mínimo seis caracteres; - Contraseña, diferente de vacío, mínimo seis caracteres; - Captcha, diferente de vacío, deben ser 4 caracteres.

Salidas: Si información correcta se envía a ../lib/index.php y verifica la información.

../lib/index.php

Página de control de acceso y asignación de roles a los usuarios.

Entrada: Cuenta, Contraseña Captcha recibida del formulario index.php

Procesos:

- Validar, que los 4 caracteres del formulario coincidan con la imagen; - Verificar, que la cuenta exista en la base de datos procedimiento almacenado verifica; - Verificar, que la cuenta no esté bloqueada procedimiento almacenado verifica; - Verificar, que la cuenta este activa procedimiento almacenado verifica; - Verificar, que la contraseña de la cuenta coincida procedimiento almacenado verifica.

Salidas: Si información correcta asignar roles a la cuenta y mandar a la página de inicio

../ini/index.php; Si la información es incorrecta se envía a página de autenticación nuevamente,

denegado acceso.

../ini/index.php

Página inicio, función desplegar información institucional y acceso a los módulos del sistema

Entrada: id(Sesión, Usuario, Perfil, Roles)

Procesos:

- Se consulta la tablas usuarios, pfl-btn par adeteminar accesos - Generar enlaces encriptados y se almacenan en la base de datos tabla url; - Selección de tabla ins para obtener la información de institución.

Salidas: Página Web con información institucional y menú principal de navegación para

acceder a los módulos del sistema de información.

9

../slr/index.php

Página para cerrar el sistema, su función cancelar la sesión, anular los privilegios.

Entrada: id (Sesión , Usuario, pfl-btn, url)

Procesos:

- Borrar la sesión del usuario; - Borrar los accesos de navegación de la tabla url;

Salidas: Se envía a página de autenticación del sistema de información.

../ins/index.php

Módulo institución del sistema de información.

Entrada: id(Sesión, Usuario, institución)

Procesos:

- Se consulta la tabla ins_org para obtener información institucional; - Se activan accesos para estructura organizacional y usuario plf_btn;

Salidas: Página lista para operar con la información de la institución.

../ins_org/index.php

Organigrama estructura tipo árbol de la institución y sus funcionarios responsables.

Entrada: id (Sesión, Usuario, institución, pfl)

Procesos:

- Se realiza una consulta en las tablas ins_org, pfl, usr;

Salidas: Página con lista de estructura institucional y los responsables en los cargos.

../ins_usr/index.php

Lista de usuarios del sistema.

Entrada: id (Sesión, Usuario)

Procesos:

- Se consulta las tablas usr, pfl; - Se tiene un listado de usuarios; - Accesos para realizar altas, bajas y modificaciones, bloqueos, y cambio de contraseña.

Salidas: Lista de usuarios con operaciones activadas.

10

../ins_usr/ add_usr.php

Permite el registro de un nuevo usuario al sistema de información.


Procesos:

- Se realiza una consulta de los roles disponibles en la institución; - Se valida nombre, diferente a vacío, entre 3 a 50 caracteres; - Se valida apellido paterno, diferente a vacío, entre 3 a 50 caracteres; - Se valida apellido materno, diferente a vacío, entre 3 a 50 caracteres; - Se valida una cuenta de correo electrónico, diferente de vacío, formato de e-mail; - Se confirma la cuenta de correo electrónico, ser igual al de correo electrónico anterior; - Se elige un rol para el nuevo usuario, es necesario elegir un rol para el usuario; - Se activa un token de transacción para la cuenta.

Salidas: Si la información requerida es correcta enviar ../ins_usr/grb_add_usr.php.

../ins_usr/grb_add_usr.php

Permite guardar el registro usuario en la base de datos.


Procesos:

- Se verifica, que el token sea válido y habilita transacción; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se guarda la información en la tabla usuario con el procedimiento add_usr; - Envía un email al nuevo usuario función emailr();

Salidas: Usuario nuevo en listado, sistema esperando activación de nuevo usuario.

../ins_usr/mod_usr.php

Permite la actualización de información de un usuario existente.


Procesos:

- Se recupera la información del cliente de la tabla usuario y verifica token; - Se valida nombre, diferente a vacío, entre 3 a 50 caracteres; - Se valida apellido paterno, diferente a vacío, entre 3 a 50 caracteres; - Se valida apellido materno, diferente a vacío, entre 3 a 50 caracteres; - Se valida una cuenta de correo electrónico, diferente de vacío, formato de e-mail; - Se confirma la cuenta de correo electrónico, ser igual al de correo electrónico anterior; - Se elige un rol para el nuevo usuario, es necesario elegir un rol para el usuario;

Salidas: Si información requerida es correcta enviar a ../ins_usr/grb_mod_usr.php.

11

../ins_usr/grb_mod_usr.php



Procesos:

- Se verifica, que el token sea válido y se habilita la transacción; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se actualiza la información en la tabla usuario con el procedimiento almacenado mod_usr.

Salidas: Usuario actualizado en listado de usuarios.

../ins_usr/psw_usr.php

Permite el cambio de contraseña del usuario.


Procesos:

- Se solicita token de transacción; - Se verifica campo cuenta actual, diferente de vacío, este entre 6 a 50 caracteres; - Se verifica contraseña, diferente de vacío, este entre 6 a 50 caracteres; - Se verifica contraseña nueva, diferente de vacío, entre 6 a 50 caracteres, fuerza alta; - Se verifica caracteres captcha, solo 4 caracteres y deben coincidir con la imagen;

Salidas: Si información correcta se envía a página ../ins_usr/grb_usr_psw.php para grabado.

../ins_usr/grb_usr_psw.php



Procesos:

- Se verifica, que el token sea válido y activa la transacción; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se actualiza la información en la tabla usuario con el procedimiento almacenado; - Se desactiva el token de transacción; - Se envía un email al usuario informando del cambio de contraseña; - Se cierra la sesión para el usuario que realizo el cambio de contraseña.

Salidas: Usuario con nueva contraseña debe ingresar con su nueva clave nuevamente y se

envía un correo electrónico informando del cambio de contraseña.

-

12

../proy/index.php

Página de presentación de proyectos por fase.


Procesos:

- Se activan enlaces para el acceso a los proyectos por fases consultando la tabla pfl-btn

Salidas: Se presenta la página con acceso a proyectos en programación, ejecución y resultados.

../proy_pre_inv/index.php

Se listan los proyectos que no empezaron según la fecha actual del servidor.

Entrada: id (Sesión, Usuario, Proyecto)

Procesos:

- Se consulta a tabla de proyecto que corresponden al usuario donde la fecha de inicio del

proyecto sea mayor a la fecha actual;

Salidas: Se presenta un listado con los proyectos que están en programación y las operaciones

de altas, bajas y modificaciones para todos sus módulos dependientes. -

../proy_pre_inv/a_proy.php

Adición de nuevo proyecto en la fase de programación.

Entrada: id (Sesión, Usuario), información de proyecto aprobado por directorio para ejecutar

Procesos:

- Se activa token para transacción; - Se valida el código CADELP, diferente de vacío, más de 5 caracteres y menos de 30; - Se valida la denominación de proyecto, diferente de vacío y entre 3 y 150 caracteres; - Se valida el objetivo principal, diferente de vacío y entre 3 y 250 caracteres; - Se valida beneficiarios, diferente de vacío y entre 3 y 250 caracteres; - Se valida la fecha inicio y fecha, deben existir fechas seleccionadas; - Se valida las fuentes de financiamiento, diferente de vacío y entre 3 150 caracteres; - Se valida el presupuesto del proyecto, valor mayor o igual a 0; - Se valida la contraparte técnica, diferente de vacío y entre 5 a 150 caracteres; - Se valida el área acción, se debe seleccionar un área.

Salidas: Si informaciones correcta se envía información al archivo ../proy/grb_add_proy.php.

13

../ins_usr/grb_add_proy.php

Permite guardar el registro del proyecto nuevo.


Procesos:

- Se verifica, que el token sea válido y se autoriza la transacción; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se guarda la información en la tabla proyecto con el procedimiento almacenado proy_add.

Salidas: Proyecto nuevo en listado, listo para completar información en los otros módulos.

../proy_pre_inv/m_proy.php

Modificación de información del proyecto.


Procesos:

- Se activa token para transacción; - Se consulta la tabla proyecto, y se carga la información sus campos; - Se valida el código CADELP, diferente de vacío, más de 5 caracteres y menos de 30; - Se valida la denominación de proyecto, diferente de vacío y entre 3 y 150 caracteres; - Se valida el objetivo principal, diferente de vacío y entre 3 y 250 caracteres; - Se valida beneficiarios, diferente de vacío y entre 3 y 250 caracteres; - Se valida la fecha inicio y fecha, deben existir fechas seleccionadas; - Se valida las fuentes de financiamiento, diferente de vacío y entre 3 150 caracteres; - Se valida el presupuesto del proyecto, valor mayor o igual a 0; - Se valida la contraparte técnica, diferente de vacío y entre 5 a 150 caracteres;

Salidas: Si información correcta se envía información al archivo ../proy/grb_mod_proy.php.

../ proy_pre_inv/grb_mod_proy.php

Permite guardar el registro del proyecto nuevo.


Procesos:

- Se verifica, que el token sea válido; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se verifica, que la cantidad de objetos sean los mismos que envió el servidor; - Se guarda la información en la tabla proyecto con procedimiento almacenado proy_mod.

Salidas: Proyecto actualizado en listado, listo para funcionar con otros módulos.

14

../proy_pre_inv/e_proy.php

Eliminación de proyecto.


Procesos:

- Se verifica, que el token sea válido y la confirmación; - Se ejecuta procedimiento almacenado del_proy de borrado de registro de proyecto.

Salidas: Listado de proyectos en programación sin el proyecto ../proy_pre_inv/index.php. -

-

-

../proy_ind/index.php

Lista de indicadores de efecto e hitos del proyecto.

Entrada: id (Sesión, Usuario, Proyecto, indicador, hito)

Procesos: Se consulta las tablas indicador e hito en función del proyecto;

Salidas: Se presenta una lista de indicadores de efecto e hitos listos para realizar transacciones.-

-

../proy_ind/a_ind.php

Se adiciona indicador de efecto del proyecto.


Procesos:

- Se activa token para transacción; Se valida el tipo de indicador, campo obligatorio; - Se valida la denominación de indicador, diferente de vacío y entre 3 y 150 caracteres; - Se valida el valor de la línea base, diferente de vacío, tipo número real; - Se valida el valor de la meta, diferente de vacío, tipo número real; - Se valida el valor de aceptabilidad positivo, necesario y entre rangos línea base y meta; - Se valida el valor de aceptabilidad negativa, necesario y entre rangos línea base y meta.

Salidas: Si información correcta se envía información al archivo ../proy_ind/grb_add_ind.php

../proy_ind/grb_add_ind.php

Permite guardar el registro indicador de efecto de proyecto.


Procesos:

- Se verifica, que el token sea válido y se habilita la transacción; - Se verifica, que los campos y guarda en tabla indicador con procedimiento proyind_add1;

Salidas: Indicador nuevo en listado en la página ../proy_ind/index.php

15

../proy_ind/m_ind.php

Modificación de indicador de efecto del proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Indicador)

Procesos:

- Se activa token para transacción; - Se consulta la tabla indicador y se carga la información en el formulario; - Se valida el tipo de indicador, campo obligatorio; - Se valida la denominación de indicador, diferente de vacío y entre 3 y 150 caracteres; - Se valida el valor de la línea base, diferente de vacío, tipo número real; - Se valida el valor de la meta, diferente de vacío, tipo número real; - Se valida el valor de aceptabilidad positivo, necesario y entre rangos línea base y meta; - Se valida el valor de aceptabilidad negativa, necesario y entre rangos línea base y meta.

Salidas: Si información correcta envía información al archivo ../proy_ind/grb_mod_ind.php.

../proy_ind/grb_mod_ind.php

Permite guardar la actualización del registro indicador de efecto de proyecto.


Procesos:

- Se verifica, que el token sea válido; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se guarda la información en tabla indicador con procedimiento proyind_add2.

Salidas: Indicador actualizado en listado en la página ../proy_ind/index.php

../proy_ind/e_ind.php

Se elimina indicador de efecto del proyecto.


Procesos:

- Se verifica, que el token sea válido; - Se verifica la confirmación de la transacción; - Se ejecuta procedimiento almacenado proyind_del en el mysql.

Salidas: Indicador borrado en el listado en la página ../proy_ind/index.php

16

../proy_ind_hito/a_indh.php

Adicionar hito al indicador de efecto del proyecto.


Procesos:

- Se activa token para transacción; - Se consulta la tabla indicador, hito en función del proyecto; - Se valida la fecha de remisión de información del hito; - Se estima el valor esperado en la fecha seleccionada;

Salidas: Información completa se envía a la página ../proy_ind_hito/grb_add_indh.php -

../proy_ind_hito/grb_add_ind_hit.php

Almacenar hito de indicador de efecto del proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Indicador, Hito)

Procesos:

- Se verifica, que el token sea válido y habilita la transacción; - Se verifica que los campos sean diferentes de vacío; - Se ejecuta procedimiento almacenado proyindhito_add para guardar la información.

Salidas: Hito de indicador nuevo en listado en la página ../proy_ind/index.php.

../proy_ind_hito/m_indh.php

Modificar hito al indicador de efecto del proyecto.


Procesos:

- Se activa token para transacción; - Se consulta la tabla indicador, hito en función del proyecto; - Se valida la fecha de remisión de información del hito; - Se estima el valor esperado en la fecha seleccionada;

Salidas: Información completa se envía a la página ../proy_ind_hito/grb_mod_indh.php

17

../proy_ind_hito/grb_mod_indh.php

Salvar hito de indicador de efecto del proyecto.


Procesos:

- Se verifica, que el token sea válido y habilita la transacción; - Se verifica que los campos sean diferentes de vacío; - Se ejecuta procedimiento almacenado proyindhito_mod para guardar la información.

Salidas: Hito de indicador nuevo en listado en la página ../proy_ind/index.php.

../proy_ind_hito/e_indh.php

Eliminar hito de indicador de efecto del proyecto.


Procesos:

- Se verifica, que el token sea válido; - Se verifica la confirmación de la transacción; - Se ejecuta procedimiento almacenado proyindhito_del en el mysql.

Salidas: Indicador borrado en el listado en la página ../proy_ind/index.php.

../ins_proy_com/index.php

Listado de componentes y actividades de proyecto.


Procesos: Se consulta las tablas componente, actividad en función del proyecto;

Salidas: Listado de componentes y actividades organizados listo para transacciones.

Salidas: Listado de componentes y actividades organizados por fechas.

../ins_proy_com/a_proy_con.php

Adición de componente para proyecto.


Procesos:

- Se activa, que el token; - Se verifica el componente, diferente de vacío, cantidad de caracteres entre 15 y 50; - Se verifica la existencia y que las fechas de inicio y fin de componente estén en rango;

Salidas: Información correcta se envía a página ../proy_com/grb_add_proy_con.php.

18

../proy_com/grb_add_proy_con.php

Salvar componente para proyecto.

Entrada: id (Sesión, Usuario, Proyecto, componente)

Procesos:

- Se verifica, que el token sea válido y activa la transacción; - Se verifica que los campos requeridos sean diferentes de vacio; - Se ejecuta procedimiento almacenado proy_com_add en el mysql.

Salidas: Componente nuevo en listado en la página ../ins_proy_com/index.php

../ins_proy_com/m_proy_con.php

Modificación de componente para proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Componente)

Procesos:

- Se activa, que el token; - Se recupera la información del componente de la tabla componente - Se verifica el componente, diferente de vacío, cantidad de caracteres entre 15 y 50; - Se verifica la existencia y que las fechas de inicio y fin de componente estén en rango;

Salidas: Información correcta se envía a página ../proy_com/grb_mod_proy_con.php.

../proy_com/grb_mod_proy_con.php

Salvar componente para proyecto.


Procesos:

- Se verifica, que el token sea válido - Se activa la transacción; - Se verifica que los campos requeridos sean diferentes de vacío; - Se ejecuta procedimiento almacenado proy_com_mod en el mysql.

Salidas: Componente actualizado en listado en la página ../ins_proy_com/index.php

19

../ins_proy_com/grb_del_proy_con.php

Eliminación de componente de proyecto.


Procesos:

- Se verifica, que el token sea válido y habilita la transacción; - Se verifica que los campos sean diferentes de vacío;- Se ejecuta procedimiento almacenado proy_com_del para guardar la información.

Salidas: Componente borrado en listado en la página ../ins_proy_com/index.php.

../ins_proy_com_act/add_proy_com_act.php

Adición de actividad en componente de proyecto.


Procesos:

- Se activa, que el token; - Se verifica que la actividad, diferente de vacío, cantidad de caracteres entre 15 y 50; - Se verifica rango de fechas de actividad este dentro el rango de fechas de componente; - Se verifica que consideraciones y responsable sean diferentes de vacío.

Salidas: Información correcta se envía a página ../ins_proy_com_act/grb_add_con_act.php.

../ins_proy_com_act/grb_add_co_act.php

Salvar adición de actividad en componente de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Componente, Actividad)

Procesos:

- Se verifica, que el token sea válido; - Se activa la transacción; - Se verifica que los campos requeridos sean diferentes de vacío;- Se ejecuta procedimiento almacenado proy_com_act_add en el mysql

Salidas: Información correcta se envía a página ../ins_proy_com/index.php

20

../ins_proy_com_act/mod_proy_com_act.php

Modificación de actividad en componente de proyecto.


Procesos:

- Se activa, que el token; - Se recupera toda la información del registro de la actividad, - Se verifica que la actividad, diferente de vacío, cantidad de caracteres entre 15 y 50; - Se verifica rango de fechas de actividad este dentro el rango de fechas de componente; - Se verifica que consideraciones y responsable sean diferentes de vacío.

Salidas: Información correcta se envía a página ../ins_proy_con_act/grb_mod_con_act.php.

../ins_proy_con_act/grb_mod_con_act.php

Guardar adición de actividad en componente de proyecto.


Procesos:

- Se verifica, que el token sea válido; - Se activa la transacción; - Se verifica que los campos requeridos sean diferentes de vacío;- Se ejecuta procedimiento almacenado proy_com_act_mod en el mysql

Salidas: Información correcta se envía a página ../ins_proy_com/index.php

../ins_proy_com_act/del_act_com_act.php

Eliminación de actividad en componente de proyecto.


Procesos:

- Se verifica, que el token sea válido y habilita la transacción; - Se verifica la confirmación del cliente; - Se ejecuta procedimiento almacenado proy-com_act_del para guardar la información.

Salidas: Actividad borrado en el listado en la página ../ins_proy_com/index.php.

21

../com_ind/index.php

Lista de indicadores de producto e hitos de componente de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Componente, Indicador, Hito)

Procesos:

- Se consulta las tablas indicador e hito en función del componente de proyecto;

Salidas: Se presenta una lista de indicadores de efecto e hitos listos para realizar transacciones.-

-

../com_ind/a_ind.php

Se adiciona indicador de producto de componente de proyecto.


Procesos:

- Se activa token para transacción; Se valida el tipo de indicador, campo obligatorio; - Se valida la denominación de indicador, diferente de vacío y entre 3 y 150 caracteres; - Se valida el valor de la línea base, diferente de vacío, tipo número real; - Se valida el valor de la meta, diferente de vacío, tipo número real; - Se valida el valor de aceptabilidad positivo, necesario y entre rangos línea base y meta; - Se valida el valor de aceptabilidad negativa, necesario y entre rangos línea base y meta.

Salidas: Si información correcta se envía información al archivo ../com_ind/grb_add_ind.php

../com_ind/grb_add_ind.php

Permite guardar el registro indicador de producto de componente de proyecto.


Procesos:

- Se verifica, que el token sea válido y se habilita la transacción; - Se verifica campos y guarda en la tabla indicador con el procedimiento proyind2_add

Salidas: Indicador nuevo en listado en la página ../com_ind/index.php

22

../com_ind/m_ind.php

Modificación de indicador de producto de componente de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Indicador, Componente)

Procesos:

- Se activa token para transacción; - Se consulta la tabla indicador y se carga la información en el formulario; - Se valida el tipo de indicador, campo obligatorio; - Se valida la denominación de indicador, diferente de vacío y entre 3 y 150 caracteres; - Se valida el valor de la línea base, diferente de vacío, tipo número real; - Se valida el valor de la meta, diferente de vacío, tipo número real; - Se valida el valor de aceptabilidad positivo, necesario y entre rangos línea base y meta; - Se valida el valor de aceptabilidad negativa, necesario y entre rangos línea base y meta.

Salidas: Si información correcta envía información al archivo ../com_ind/grb_mod_ind.php.

../com_ind/grb_mod_ind.php

Permite guardar la actualización indicador de producto componente de proyecto.

Entrada: id (Sesión, Usuario, Indicador, Componente)

Procesos:

- Se verifica, que el token sea válido; - Se verifica, que los campos solicitados sean diferentes de vacío; - Se guarda la información en tabla indicador con procedimiento proyind2_mod.

Salidas: Indicador actualizado en listado en la página ../com_ind/index.php

../com_ind/e_ind.php

Se elimina indicador de producto del componente de proyecto.


Procesos:

- Se verifica, que el token sea válido; - Se verifica la confirmación de la transacción; - Se ejecuta procedimiento almacenado proyind2_del en el mysql.

Salidas: Indicador borrado en el listado en la página ../com_ind/index.php

23

../com_ind_hito/a_indh.php

Adicionar hito al indicador de producto del componente de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Indicador, Componente)

Procesos:

- Se activa token para transacción; - Se consulta la tabla indicador, hito en función del componente; - Se valida la fecha de remisión de información del hito; - Se estima el valor esperado en la fecha seleccionada;

Salidas: Información completa se envía a la página ../com_ind_hito/grb_add_indh.php -

../ com_ind_hito/grb_add_indh.php

Almacenar hito de indicador de producto de componente del proyecto.


Procesos:

- Se verifica, que el token sea válido y habilita la transacción; - Se verifica que los campos sean diferentes de vacío; - Se ejecuta procedimiento almacenado proyindhito_add para guardar la información.

Salidas: Hito de indicador nuevo en listado en la página ../ com_ind_hito /index.php.

../ com_ind_hito/m_indh.php

Modificar hito al indicador de producto de componente del proyecto.


Procesos:

- Se activa token para transacción; - Se consulta la tabla indicador, hito en función del componente; - Se valida la fecha de remisión de información del hito; - Se estima el valor esperado en la fecha seleccionada;

Salidas: Información completa se envía a la página ../com_ind_hito/grb_mod_indh.php

24

../com_ind_hito/grb_mod_indh.php

Salvar hito de indicador de producto de componente del proyecto.


Procesos:

- Se verifica, que el token sea válido y habilita la transacción; - Se verifica que los campos sean diferentes de vacío; - Se ejecuta procedimiento almacenado proyindhito_del para guardar la información.

Salidas: Hito de indicador nuevo en listado en la página ../com_ind_hito/index.php.

../com_ind_hito/e_indh.php

Eliminar hito de indicador de efecto del proyecto.


Procesos:

- Se verifica, que el token sea válido; - Se verifica la confirmación de la transacción; - Se ejecuta procedimiento almacenado proyindhito_del en el mysql.

Salidas: Indicador borrado en el listado en la página ../com_ind_hito/index.php.

../ ins_proy_ppto/index.php

Lista de ítems de presupuesto de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Item_presupuesto)

Procesos: Se consulta las tablas ítem_presupuesto en función del proyecto;

Salidas: Se presenta el listado de los ítems de proyecto y los accesos para las operaciones.

../ ins_proy_ppto/add_pto.php

Adición de ítem de presupuesto de proyecto.


Procesos:

- Se activa token para transacción; - Se consulta tablas ítem_proyecto y proyecto se calcula el saldo disponible programable; - Se valida el plan de cuentas; - Se valida el valor estimado para el ítem;

Salidas: Información completa se envía a la página ../proy_ppto/grb_add_proy_ppto.php.

25

../ ins_proy_ppto/grb_add_proy_pto.php

Guardar de ítem de presupuesto de proyecto.


Procesos:

- Se verifica, que el token sea válido; - Que los campos necesarios sean diferentes de vacío; - Se ejecuta procedimiento almacenado proy_ppto_add en el mysql.

Salidas: Ítem nuevo en listado de presupuesto ../ins_proy_ppto/index.php.

../ ins_proy_ppto/mod_pto.php

Modificación de ítem de presupuesto de proyecto.


Procesos:

- Se activa token para transacción; - Se consulta tablas ítem_proyecto y proyecto se calcula el saldo disponible programable; - Recuperar la información de item de presupuesto, - Se valida el plan de cuentas; - Se valida el valor estimado para el ítem.

Salidas: Información completa se envía a la página ../ins_proy_ppto/grb_mod_proy_ppto.php.

../ ins_proy_ppto/grb_mod_proy_pto.php

Guardar de ítem de presupuesto de proyecto.


Procesos:

- Se verifica, que el token sea válido; - Que los campos necesarios sean diferentes de vacío; - Se ejecuta procedimiento almacenado proy_ppto_mod en el mysql.

Salidas: Ítem actualizado en listado de presupuesto ../ins_proy_ppto/index.php.

26

../ ins_proy_ppto/grb_del_proy_pto.php

Eliminación de ítem de presupuesto de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Ítem presupuesto)

Procesos:

- Se verifica, que el token sea válido; - Se verifica la confirmación de la transacción; - Se ejecuta procedimiento almacenado proy_ppto_del en el mysql.

Salidas: Ítem borrado en listado de presupuesto ../ins_proy_ppto/index.php.

../alertas/index.php

Lista de cuantías de tiempo y presupuesto.


Procesos: Se consulta proyecto, alertastmp y alertasppto.

Salidas: Se presentan dos listas con las cuantías de ejecución presupuestaria y tiempos más

operaciones como altas, bajas y modificaciones.

../alertasxejec/a_aejepro.php

Adición de cuantía por ejecución presupuestaria.


Procesos:

- Se activa token para transacción; Se consulta tabla proyecto; - Se toma el máximo de presupuesto del proyecto y se la divide por diferentes criterios; - Se valida el criterio elegido.

Salidas: Información completa se envía a la página ../alertasxejec/grb_add_eje.php.

../ alertasxejec/grb_add_eje.php

Guardar cuantías de alertas proyecto.


Procesos:

- Se verifica, que el token sea válido y se habilita transacción; - Se ejecuta procedimiento almacenado aler_eje_add en el mysql.

Salidas: Alerta en listado de alertas ../alertas/index.php.

27

../alertasxejec/m_aejepro.php

Adición de cuantía por ejecución presupuestaria.


Procesos:

- Se activa token para transacción; Se consulta tabla proyecto; - Se toma el máximo de presupuesto del proyecto y se la divide por diferentes criterios; - Se valida el criterio elegido.

Salidas: Información completa se envía a la página ../alertasxejec/grb_mod_eje.php.

../ ins_proy_ppto/grb_mod_eje.php



Procesos:

- Se verifica, que el token sea válido y se habilita transacción; - Se ejecuta procedimiento almacenado aler_eje_mod en el mysql.


../alertasxejec/grb_del_eje.php

Eliminación de cuantía por ejecución presupuestaria.


Procesos:

- Se verifica, que el token sea válido; - Se verifica la confirmación de la transacción; - Se ejecuta procedimiento almacenado aler_eje_del en el mysql.

Salidas: Alerta borrada del listado de alertas ../alertas/index.php.

../alertasxtmp/a_aejeper.php

Adición de cuantía por tiempo transcurrido en el proyecto.


Procesos:

- Se activa token para transacción; Se consulta tabla proyecto; - Se toma rango de fechas de proyecto y se la divide por diferentes criterios; - Se valida el criterio elegido.

Salidas: Información completa se envía a la página ../alertasxtmp/grb_add_eje.php

28

../ alertasxtmp/grb_add_eje.php



Procesos:

- Se verifica, que el token sea válido y se habilita transacción; - Se ejecuta procedimiento almacenado aler_tmp_add en el mysql.


../alertasxtmp/m_aejeper.php

Modificación de cuantía por tiempo transcurrido en el proyecto.


Procesos:

- Se activa token para transacción; Se consulta tabla proyecto; - Se toma rango de fechas de proyecto y se la divide por diferentes criterios; - Se valida el criterio elegido.

Salidas: Información completa se envía a la página ../alertasxtmp/grb_mod_eje.php.

../alertasxtmp/grb_mod_eje.php


Entrada: id (Sesión, Usuario, Proyecto, Alerta_tmp)

Procesos:

- Se verifica, que el token sea válido y se habilita transacción; - Se ejecuta procedimiento almacenado aler_tmp_mod en el mysql.


../alertasxtmp/grb_del_atmppro.php

Eliminación de cuantía por tiempo transcurrido en el proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Alertatmp)

Procesos: Se verifica, que el token sea válido;

- Se verifica la confirmación de la transacción; - Se ejecuta el procedimiento almacenado aler_tmp_del en phpmyadmin

Salidas: Alerta borrada del listado de alertas ../alertas/index.php.

29

../proy_inv/index.php

Lista de proyectos en fase de ejecución.


Procesos:

- Se activan enlaces para el acceso a los proyectos en fase de ejecución en la tabla pfl-btn

Salidas: Se presenta listado de proyectos en ejecución, se activan enlaces de seguimiento.

../proy_ind_/index.php

Lista de indicadores de efecto del proyecto.


Procesos:

- Se consultan las tablas indicador e hitos; - Se adiciona el estado del hito; - Se valida el valor elegido.

Salidas: Lista de hitos habilitados para ser reportados en la página ../proy_ind/eje.php.

../proy_ind_/a_stdhit.php



Procesos:

- Se consultan la tabla hito; - Se recibe el valor del hito; - Se valida el valor elegido.

Salidas: Información correcta enviar a ../proy_ind_/grb_stdhit.php.

../proy_ind_/grb_stdhit.php



Procesos:

- Se consultan la tabla hito; - Guardar el registro con el update hito_indicador en mysql;

Salidas: Información correcta enviar a ../proy_ind_/index.php.

30

../ ins_proy_com_/index.php

Lista de componentes y actividades en ejecución.

Entrada: id (Sesión, Usuario, Proyecto, Componente, Atividad)

Procesos:

- Se consulta las tablas componente, actividad.

Salidas: Se presenta listado de componentes y actividades para su reporte o reprogramación.

../ins_proy_com/e.ph

Reportar el estado de la actividad a la conclusión del tiempo.


Procesos:

- Se consulta actividad y se solicita el estado de las actividades concluidas.

- Se ejecuta grb_act determinando estado de actividad

Salidas: Lista para verificar el cumplimiento o no de la actividad.

../proy_indo_/a_stdhit.php

Lista de indicadores de producto del proyecto.


Procesos:

- Se consultan la tabla hito; - Se recibe el valor del hito; - Se valida el valor elegido.

Salidas: Información correcta enviar a ../proy_ind_/grb_stdhit.php.

../proy_indo_/grb_stdhit.php

Lista de indicadores de producto del proyecto.


Procesos:

- Se consultan la tabla hito; - Guardar el registro en la con el procedimiento almacenado grb_eje en mysql;

Salidas: Información correcta enviar a ../proy_indo_/index.php.

31

../ins_proy_ppto_/index.php

Lista de ítems de presupuesto de proyecto.

Entrada: id (Sesión, Usuario, Proyecto, Item_presupuesto,Ejecucion_ppto)

Procesos:

- Se consulta la tabla presupuesto y ejecución_ppto.

Salidas: Lista de ítems de presupuesto y niveles de ejecución.

../ins_proy_ppto_eje_/index.php

Lista de ejecuciones presupuestarias por ítem.

Entrada: id (Sesión, Usuario, Proyecto, Ítem presupuesto, Seguimiento_item_presupuesto)

Procesos:

- Se consulta las tablas ítems de presupuesto y Seguimiento_item_presupuesto.

Salidas: Lista de ítems de proyecto y el detalle de su programación y ejecución.

../ ins_proy_ppto_eje_/a_eje.php

Adición de ejecución de ejecución presupuestaria para ítem de presupuesto.

Entrada: id (Sesión, Usuario, Proyecto, Ítem presupuesto, Ejecución presupuesto)

Procesos:

- Se activa token para transacción; Se consulta tabla ítem_presupuesto, ejecución_ppto; - Se valida que el valor este entre 0 y rango máximo de saldo; - Se valida la existencia de un archivo tipo imagen como descargo financiero; - Se permite llenar un detalle entre 3 a 100 caracteres.

Salidas: Si información es correcta entonces enviar ../ ins_proy_ppto_eje_/grb_a_eje.php

../ ins_proy_ppto_eje_/grb_a_eje.php

Adición de ejecución de ejecución presupuestaria para ítem de presupuesto.

Entrada: id (Sesión, Usuario, Proyecto, Ítem presupuesto, Ejecución presupuesto)

Procesos:

- Se verifica token para y se habilita la transacción; - Se verifica que los campos solicitados sean diferentes de vacio; - Se redimensiona la imagen; - Se ejecuta el procedimiento almacenado proy_ppto_eje_add en el mysql.

Salidas: Si información es correcta entonces enviar ../ ins_proy_ppto_eje_/index.php

32

../proy_post_inv/index.php

Lista de proyectos con resultados finales.


Procesos: Se consulta la tabla proyecto y verifica que proyecto esté concluido.

Salidas: Se presenta un listado de proyectos concluidos y puede generar un reporte pdf.

../tcpdf/examples/resultados.php

Reporte completo en formato PDF.


Procesos: Se consulta la tabla proyecto, componente, actividad, indicador, hito, presupuesto.

Salidas: Se presenta un informe completo en formato pdf que es descargable e imprimible.

3.2.4 Ubicación de librerías externas

�� Carpeta ��

�� Lib )�-��'��

�� Li )�-��'��%.��

�� X )�-��'��/.��

�� Pchart )�-��'��+��

�� Tcpdf )�-��'��,�0��!12�

3.2.5 Copia de Seguridad

Acceder al cPanel; Debes ingresar en el navegador, ya sea Internet Explorer, Mozilla Firefox, o el que utilices, y tipear: http://tudominio.com/cpanel.

33

Clic en la opción “Respaldo”.

Podrás elegir entre hacer un backup completo o un backup parcial del directorio home, de las bases

de datos MySQL o de las redirecciones de e-mail y filtros configurados. En este caso vamos a

mostrar un ejemplo de backup completo, de esta manera se generará un archivo tar de todos los

archivos y configuraciones de tu sitio de web. Vos podes elegir la opción que más te convenga.

Elegir el destino del respaldo. Eligiendo la opción “Directorio Home”, el archivo aparecerá en el directorio home de tu cuenta. De esta manera podrás descargarlo a tu computadora desde un programa FTP o desde el administrador de archivos de tu cPanel.

A la cuenta de e-mail que ingreses en la opción “Correo electrónico/Email”, llegará un aviso cuando se finalice el backup.

Clic en “Generar Respaldo”.

34

Ahora aparecerá un mensaje indicando que el backup se ha iniciado. Simplemente deberás esperar

a que te llegue el mail automático informándote de la finalización del proceso. El tiempo que tarde

dependerá de la cantidad y peso de archivos contenidos en tu cuenta de hosting.

El mail te llegará desde la dirección [email protected], con asunto “Full Backup Completed”.

Debajo de todo del campo de texto del mail aparecerá el nombre del archivo generado y la

ubicación, por ejemplo: “pkgacctfile is: /home/usuario/backup-9.16.2010_14-30-48_htest.tar.gz”.

De esta manera queda finalizado el backup de tu cuenta de hosting. Felicitaciones!

3.3 Base de datos en el servidor

El sistema fue desarrollado con el gestor de base de datos MySql el mismo compotar de acuerdo a

un modelo, diccionario de datos, del cual se puede hacer copias de seguridad con el Cpanel y

restaurarlo si existiera algún incidente.

35

3.3.1 Modelo de la Base de datos

3.3.2 Diccionario de datos

Se presenta el diccionario de datos generado con el modelo relacional donde se describen las tablas

de la base de datos tomando en cuenta los campos, tamaño, tipo de dato y su descripción para

establecer las relaciones y los campos claves.

Nombre tabla: Usuario Fecha de creación: 05/03/2015

Descripción: Contiene la información de los clientes del sistema, para autentificación.

Campo Tamaño Tipo de dato Descripción

id_usr 11 int Identificador único de usuario

36

userName 50 varchar Nombre completo del usuario

password 25 varchar Contraseña de acceso

email 25 varchar Correo electrónico del usuario

perfil 11 int Perfil del usuario en el sistema

Relaciones: - perfil

Campos Clave: 3 id_usr 3 e-mail 3 password

Nombre tabla: Perfil Fecha de creación: 05/03/2015

Descripción: Son los perfiles con los del usuario para realizar transacciones en el sistema


oid 11 int Identificador de perfil de usuario

denominacion 50 varchar Denominación del perfil de usuario

Relaciones: Ninguna Campos Clave: oid

Nombre tabla: Accesos Fecha de creación: 05/03/2015

Descripción: Son los accesos a los que tiene derecho el usuario bajo un perfil


oid 11 int Identificador del enlace

id_perfil 11 int Identificador del perfil

enlace 250 varchar Enlace URL permitido

Relaciones: id_perfil Campos Clave: oid, enlace

Nombre tabla: Proyecto Fecha de creación: 05/03/2015

Descripción: Contiene la información de los proyectos que ejecuta la institución CADELP

Campo Tamañ

o

Tipo de dato Descripción

id_proy 20 bigint Identificador único de proyecto

id_ins 11 int Identificador de institución

cod_proy_inst 100 varchar Código de proyecto en la institución

denominacion 200 varchar Denominación del proyecto

37

objetivo_principal 250 varchar Objetivo del proyecto

beneficiarios 200 varchar Beneficiarios del proyecto

fecha_inicio date Fecha de inicio del proyecto

fecha_fin date Fecha de finalización del proyecto

fuente_

financiamiento

150 varchar Descripción de las fuentes de financiamiento para

el desarrollo del proyecto

presupuesto double Monto techo presupuestario del proyecto

contraparte_

tecnica

200 varchar Contra parte técnica del proyecto

id_usr_gerente 11 int Identificador de gerente de proyecto

id_categoria_

programatica

11 int Identificador de categoría programática de la

institución

prg 11 int Fase del proyecto

id_usr 11 ind Identificador usuario que registra proyecto

fhs timestamp Fecha y hora transacción en servidor

Relaciones:

3 id_usr

Campos Clave:

3 id_proy

Nombre tabla: Componente Fecha de creación: 05/03/2015

Descripción: Son los componentes del proyecto que se desean lograr con las actividades


id_com 20 bigint Identificador único de componente

id_proy 11 int Identificador único de proyecto

denominacion 150 varchar Denominación del componente

fecha_inicio date Fecha de inicio del componente

fecha_fin date Fecha finalización de componente

consideraciones 250 varchar Consideraciones sobre el componente

prg 11 int Estado del componente

id_usr 11 int Identificador de usuario


Relaciones: 3 id_proy

Campos Clave: 3 id_com

Nombre tabla: Actividad Fecha de creación: 05/03/2015

38

Descripción: Son las actividades del componente que generan productos


Id_act 11 int Identificador único de actividades

Id_com 11 int Identificador único de componente

denominacion 150 varchar Denominación de la actividad

Fecha_inicio date Fecha de inicio de la actividad

Fecha_fin date Fecha de finalización de la actividad

consideraciones 250 varchar Consideraciones para la actividad

responsable 150 varchar Responsable(s) de la actividad

prg 11 int Estado de fase de la actividad

std 11 int Actividad lograda con éxito si/no

Id_usr 11 int Identificador del usuario


Relaciones: 3 id_com

Campos Clave: 3 id_act

Nombre tabla: Indicador Fecha de creación: 05/03/2015

Descripción: Son los indicadores de efecto del proyecto e indicadores de producto de componente


id_ind 20 bigint Identificador único de indicador


id_com 11 int Identificador único de componente

tipo_indicador 11 int Tipo (%,Tasa, Índice, Unidades, Cualitativo)

denominacion 150 varchar Denominación del indicador

formula_nominal 100 varchar Descripción de fórmula de cálculo indicador

unidad 50 varchar Definición de unidad del indicador

línea_base float Valor línea base del indicador

meta float Valor meta del indicador

aceptabilidad

maxima

float Valor aceptable máximo del indicador para

no entrar en zona de riesgo o error

aceptabilidad

minima

float Valor aceptable mínimo del indicador para

no entrar en zona de riesgo o error

riesgo float Valor de riesgo del indicador

línea_basec 11 int Valor línea base cualitativo

39

meta 11 int Valor meta cualitativo



Relaciones: 3 id_proy 3 id_com 3 tipo_indicador

Campos Clave: 3 id_indicador

Nombre tabla: Hito Fecha de creación:

Descripción: Son los puntos de control del indicador de efecto o producto


id_hit_ind 11 int Identificador único de hito de indicador

id_ind 11 int Identificador único de indicador

fecha date Fecha evaluación de hito de indicador

valor_esperado float Valor esperado en el hito

valor_real float Valor reportado por cliente



Relaciones:3 id_ind

Campos Clave:3 id_hit_ind

Nombre tabla: item_indicador_cualitativo Fecha de creación:

Descripción: Son los ítems definidos para indicadores tipo cualitativo


id_item_ind_usr 11 int Identificador único de ítem cualitativo

id_ind 11 int Identificador único de indicador

orden 11 Int Orden de los ítems cualitativos

item 50 varchar Definición de ítem cualitativo

significado_item 150 varchar Significado de ítem cualitativo



Relaciones:3 id_ind

Campos Clave:3 id_item_ind_usr

Nombre tabla: ítem_presupuesto Fecha de creación:

Descripción: Son los ítems del presupuesto del proyecto

40


Id_pto 20 bigint Identificador único de ítems de presupuesto

Id_proy 11 int Identificador único de proyecto

Id_plan_cuentas 11 int Identificador de plan de cuentas

item 150 varchar Descripción del ítem de presupuesto

presupuesto float Monto que se estima invertir

prg 11 int Estado del item



Relaciones: 3 id_proy

Campos Clave: 3 id_pto

Nombre tabla:

seguimiento_item_presupuesto

Fecha de creación:

Descripción: Es el seguimiento de la ejecución de los ítems de presupuesto


id_seg_ite,_pto 11 int Identificador único de ejecución

id_pto 11 int Identificador único de ítem de presupuesto

detalle 100 varchar Descripción de la inversión

inversión float Monto invertido del presupuesto de ítem

archivo longblob Imagen normal de documento de transacción

archivog blob Imagen reducida documento de transacción

nom_arch 100 varchar Nombre del archivo

tip_arch 25 varchar Tipo de extensión de la imagen

fecha date Fecha del documento de transacción



Relaciones:3 id_pto

Campos Clave:3 id_seg_ite

Nombre tabla: notificaciones_x_tiempo Fecha de creación:

Descripción: Son las cuantías por tiempo para envió de notificaciones


id_a 11 int Identificador único de cuantía de tiempo

41


fecha date Fecha de envió de notificación por cuantía



Relaciones:� id_proy

Campos Clave:� id_a

3.3.3 Procedimientos almacenados

En DVD adjunto a este documento se tienen los procedimientos almacenados que deben ejecutar.

3.3.4 Copia de seguridad

Para crear un respaldo completo, realice los siguientes pasos:

- Seleccione Copias de seguridad en la primera página. - Pulse Directorio principal, Bases de datos MySQL o Email Forwarders and Filters

(Redireccionadores y filtros de correo electrónico) para seleccionar la porción de su sitio a respaldarse.

- Pulse el enlace o botón apropiado en la página siguiente para almacenar la información necesaria en su computadora o servidor web.

El tipo del archivo de respaldo dependerá en el tipo de porción de su sitio que usted va a guardar en su computadora. Para obtener una lista de respaldos y sus tipos de archivo.

3.3.5 Restaurar Base de datos

Ingrese al Cpanel inicie el PhpMyadmin importe en la base de datos la última copia de seguridad

de la base de datos

42

3.4 Configuración del archivo conectar .php

Es necesario ajustar este archivo para establecer conexión del programa con el MySql, con la

información actualizada de la base de datos.

43

4. Preguntas Frecuentes

4.1 Sobre el sistema

¿Cuáles son los mejores proveedores de web hosting a contratar?

Los proveedores más reconocidos son BlueHost, HostMonsters, RapidGastor, pero usted

puede contratar el proveedor deseado en hosting nacionales siempre y cuando cumplan con

los requerimientos mínimos.

¿Qué información me es útil para ampliar con uno o más módulos en el sistema?

Existe información en los incisos 3.1 al 3.3 existe información sobre los archivos y la base

de datos.

¿Dónde están las librerías del sistema?

Encontrará información al respecto en el punto 3.2.3.

¿Cómo activar los servicios del sistema de información?

Ejecute los comandos CRON en el servidor Linux y ejecute el archivo reporte.php en la

carpeta notificaciones.

ANEXO B

Manual Usuario Administrador

Manual de Usuario

Administrador

SISTEMA WEB DE SEGUIMIENTO Y MONITOREO DE PROYECTOS ORIENTADOS A RESULTADOS

(SMPR)

La Paz – Bolivia

Noviembre, 2015

Contenido

1. Manual de usuario ................................................................................................................ 1

1.1 Bienvenida .................................................................................................................. 1

1.2 Prefacio ....................................................................................................................... 1

2. Requerimientos del Sistema ................................................................................................. 2

2.1 Introducción ................................................................................................................ 2

2.2 Requerimientos de conocimientos del usuario ........................................................... 2

2.3 Requerimientos de usuario ......................................................................................... 2

2.4 Requerimientos mínimos tecnológicos ....................................................................... 2

2.5 Servicios necesarios.................................................................................................... 3

3. Como usar el producto ......................................................................................................... 4

3.1 Acceso al sistema ....................................................................................................... 4

3.2 Ingreso al sistema ....................................................................................................... 4

3.3 Inicio del sistema ........................................................................................................ 5

3.4 Institución ................................................................................................................... 6

3.5 Institución - Estructura ............................................................................................... 6

3.6 Institución - Usuarios ................................................................................................. 7

3.6.1 Institución – Usuarios – Adicionar ................................................................. 7

3.6.2 Institución – Usuarios – Modificar ................................................................. 8

3.6.3 Institución – Usuarios - Eliminar .................................................................... 8

3.7 Proyecto ...................................................................................................................... 9

3.8 Proyecto - Programación ............................................................................................ 9

3.8.1 Proyecto – Programación - Adición ............................................................. 10

3.8.2 Proyecto – Programación – Reporte de proyecto ......................................... 11

3.8.3 Proyecto – Programación - Modificación ..................................................... 12

3.8.4 Proyecto – Programación - Eliminación ....................................................... 13

3.9 Proyecto – Programación – indicadores de efecto y producto ................................ 13

3.9.1 Proyecto – Programación – indicadores – Adición ...................................... 14

3.9.2 Proyecto – Programación – indicador – Reporte ......................................... 15

3.9.3 Proyecto – Programación – Indicador - Eliminación .................................. 16

3.9.4 Proyectos – Programación – Indicador – Modificación .............................. 16

3.9.5 Proyecto – Programación – Indicador – Hitos – Adición ............................. 17

3.9.6 Proyecto – Programación – Indicador– Hitos – Modificación .................... 17

3.9.7 Proyecto – Programación – Indicador – Hito – Eliminación ....................... 18

3.10 Proyecto – Programación – Componente ................................................................. 18

3.10.1 Proyecto – Programación – Componente – Adición .................................... 19

3.10.2 Proyecto – Programación – Componente – Modificación ............................ 19

3.10.3 Proyecto – Programación – Componente – Eliminación .............................. 20

3.10.4 Proyectos – Programación – Adición de Actividad ...................................... 20

3.10.5 Proyecto – Programación – Actividad – Modificación ................................ 21

3.10.6 Proyecto – Programación – Actividad – Eliminación .................................. 21

3.11 Proyecto – Programación - Ítem presupuesto .......................................................... 22

3.11.1 Proyecto – Programación – Ítem presupuesto – Adición ............................. 22

3.11.2 Proyecto – Programación – Ítem presupuesto – Modificación ..................... 23

3.11.3 Proyecto – Programación – Ítem presupuesto – Eliminación ....................... 23

3.12 Proyecto – Ejecución – Notificaciones por Cuantías ............................................... 24

3.12.1 Proyecto – Ejecución – Notificación por Cuantías de tiempo ...................... 24

3.12.2 Proyecto – Ejecución – Notificación por Cuantía financiera ....................... 25

3.13 Proyecto – Ejecución – Seguimiento Físico – Financiero ........................................ 25

3.13.1 Proyecto – Ejecución – Seguimiento Indicador ........................................... 26

3.13.2 Proyecto – Ejecución – Seguimiento Actividad ........................................... 26

3.13.3 Proyecto – Ejecución – Seguimiento Ítem presupuesto ............................... 27

3.13.4 Proyecto – Ejecución - Adición de ejecución presupuestaria ....................... 27

3.13.5 Proyecto – Ejecución - Modificación de ejecución presupuestaria .............. 28

3.13.6 Proyecto – Ejecución - Eliminación de ejecución presupuestaria ................ 28

3.14 Proyecto – Ejecución – Notificación y Alertas ........................................................ 29

3.14.1 Proyecto – Ejecución – Envío de E-mail por notificación o alertas ............. 29

3.15 Proyecto – Resultados – Página Proyectos –Reporte final en PDF .......................... 29

4. Preguntas Frecuentes ......................................................................................................... 30

4.1 Sobre el sistema ........................................................................................................ 30

1

1. Manual de usuario

1.1 Bienvenida

Bienvenidos al manual de usuario del Sistema Web de Seguimiento y Monitoreo de Proyectos para

Resultados en este documento usted encontrara toda la información necesaria para operar el

sistema.

1.2 Prefacio

Capítulo I: Se brinda una bienvenida al usuario, se presenta un prefacio del manual, se realiza una

introducción del sistema.

Capítulo II: Se expresan los requerimientos del sistema en cuanto refiere al usuario, requerimientos

mínimos en equipos, servicios necesarios y los mecanismos de acceso.

Capitulo III: Se explica cómo usar el producto software, tomando en cuenta que solo se está

trabajando la etapa de inversión de proyecto, esta etapa funciona con tres fases, programación,

ejecución, resultados. En la fase de programación se prepara el proyecto para su ejecución, en la

fase se realiza el seguimiento y monitoreo físico y financiero para obtener información para que se

haga el monitoreo mediante la reprogramación de tiempos en las actividades y presupuesto.

Capítulo IV: Se presenta las preguntas más frecuentes que surgen el momento de trabajar con el


2

2. Requerimientos del Sis tema

2.1 Introducción

El sistema de información web para el seguimiento y monitoreo de proyectos para resultados

(SMPR) es una herramienta para la toma decisiones que tiene requerimientos en cuanto se refieres

a los usuarios, equipos, sistemas operativos, navegadores y mecanismos de acceso.

2.2 Requerimientos de conocimientos del usuario

El SMPR fue diseñado para personas interesadas en la gestión de proyecto, por los tanto se requiere

conocimientos de conceptos como proyecto, componente, actividades, presupuesto indicadores de

producto, indicadores de efecto para alcanzar los impactos.

• Proyecto, es una idea de algo que se piensa hacer y para la cual se establece un modo

determinado y un conjunto de medios necesarios, se miden con indicadores de efecto.

• Componente, es un elemento que hace posible un proyecto, se mide con indicadores de producto,

también es un conjunto de actividades.

• Actividades, es un elemento que pertenece a un componente, conseguir las actividades significa

que existe cumplimiento.

• Presupuesto, es la distribución de recursos financieros en ítems que deben ser ejecutados para

conseguir el proyecto.

• Indicadores de efecto, son medios para medir el efecto del proyecto, estos indicadores pueden ser

de tipo porcentaje, tasa, índice, otras unidades, cualitativos.

• Indicadores de producto, son medios para medir el producto del componente que pertenece al

proyecto, estos indicadores pueden ser de tipo porcentaje, tasa, índice, otras unidades, cualitativos.

2.3 Requerimientos de usuario

El SMPR es una herramienta que tiene la bondad de enviar notificaciones vía correo electrónico,

por lo tanto cualquier usuario del sistema necesita obligatoriamente una cuenta de correo

electrónico, es recomendable que la cuenta de correo electrónico sea institucional.

2.4 Requerimientos mínimos tecnológicos

El usuario del SMPR puede acceder a su información en el sistema por medio de un:

- Computador con sistema operativo (Windows, Linux, MacOs)

3

- Tableta o teléfono inteligente con sistemas operativos (Android, Mozilla, MacOs)

Se requiere de un navegador web:

- Internet Explorer superior a la versión 10 o superior

- Edge versión 8 o superior

- Mozilla desde la versión 10 o superior

- Opera versión 10 o superior

- Safari versión 13 o superior

- Chrome versión 11 o superior

2.5 Servicios necesarios

El usuario necesita de servicios de conexión de internet para el acceso de al SMPR en Bolivia las

empresas que brindan estos servicios son:

- ENTEL (ADSL, WIMAX, 2G, 3G, 3G+, LTE)

- TIGO (WIMAX, 3G, 3G+, LTE)

- VIVA (WIMAX, 3G, 3G+, LTE)

- COTEL(DIALUP, ADSL)

- COTAS(ADSL, WIMAX)

El usuario tiene la libertad de elegir su proveedor y el servicio que mejor se acomode a sus

bolsillos, la velocidad mínima requerida es de 120kbps se recomienda conexiones ADSL o 3G+ o

superior

4

3. Como usar el producto

3.1 Acceso al sistema

Este producto requiere de un navegador web instalado y el servicio de internet conectado, lo único

que deben hacer es abrir el navegador de su preferencia y digitar la dirección

www.smpr.cadelp.com (1)

3.2 Ingreso al sistema

Para trabajar con el sistema de información es necesario que los clientes tengan una cuenta activa

en el sistema, la clave de acceso y debe resolver la adivinanza de seguridad trivial captcha.

(1) Cuenta de usuario, es no vacío, mayor a 6 caracteres y tipo correo electrónico;

(2) Clave de acceso, es no vacío, mínimo 8 caracteres alfa numéricos y símbolos;

23

54

6

7

9

10 11

8

1

1

5

(3) Enlace de cambio de imagen captcha;

(4) Se espera la copia de los 4 caracteres de la imagen captcha;

(5) Botón de envió de formulario, solo funciona si todos los campos están en verde;

(6) Botón de limpiar, hace un vaciado de todos los campos del formulario de acceso;

(7) Mensaje y entorno rojo por error acompañados de la descripción del problema;

(8) Mensaje que describe la información requerida en el campo del formulario;

(9) Imagen captcha con cuatro caracteres alfa numéricos que cambian cada 60 segundos;

(10) Imagen de correcto, si la información cumple con reglas de validación;

(11) Enlace para recuperar la contraseña en caso de pérdida u olvido

3.3 Inicio del sistema

Es la página que permite acceder al información de la institución, proyecto o salir.

(1) Cabecera del sistema de información;

(2) Fecha actual del sistema;

(3) Nombre del usuario en el sistema;

(4) Información institucional, donde se destaca la misión, visión, y objetivos;

21

3

4

5 6 7 8

9

6

(5) Botón de la página de inicio;

(6) Botón institución, permite el acceso a las estructura de la institución, e información del usuario;

(7) Botón de proyectos, permite el acceso a proyectos programados, en ejecución y con resultados;

(8) Botón de salir, cierra el sistema y la sesión del usuario;

(9) Número de proyectos programados, ejecución, resultados y dispositivo.

3.4 Institución

Este módulo permite tener acceso a la estructura organización e información del usuario

(1) Institución, haciendo clic se puede observar toda la información de la institución;

(2) Botón estructura, permite observar la estructura organizacional de la institución;

(3) Botón usuarios, permite observar la información del usuario;

(4) Botones del menú principal;

3.5 Institución - Estructura

Este módulo permite tener observar la estructura de la organización, en esta árbol de se presenta a

los usuarios por rol,

1

4

2 3

1 3

2

7

(1) Estructura organizacional de CADELP, se observa personas asignadas en cada rol;

(2) Botón usuario, permite observar la lista de usuarios de la institución;

(3) Botón menú principal, permite el cambio de módulo en el sistema.

3.6 Institución - Usuarios

(1) Lista de usuarios de CADELP;

(2) Usuario de CADELP, si hace clic en el nombre aparecen todos los datos del usuario;

(3) Botón modificar usuario, permite la actualización de información del usuario;

(4) Botón adicionar, permite agregar un nuevo usuario al sistema;

(5) Botones de institución; (6) Botones de menú principal.

3.6.1 Institución – Usuarios – Adicionar

Todos los campos son obligatorios, el sistema de oficio manda un enlace encriptado para la

activación del nuevo cliente por medio de su correo electrónico.

1

65

4

3

2

1

5

4

23

8

(1) Campos obligatorios para el registro de un nuevo usuario, si hay fallos se marca bien y si hay

errores se marca mal más el error;

(2) Botón enviar, se activa si y solo sí todos los campos cumplen con las reglas de validación;

(3) Botón limpiar, reinicia el formulario y lo pone en blanco;

(4) Botón usuarios, permite retornar al listado de usuarios de la institución;

(5) Botones de menú, periten el cambio de módulo en el sistema.

3.6.2 Institución – Usuarios – Modificar

(1) Campos obligatorios para la modificación;


(3) Botón limpiar, reinicia el formulario y lo pone en blanco;


3.6.3 Institución – Usuarios - Eliminar

1

4

2 3

1

4

23

9

(1) Campos obligatorios para la modificación;


(3) Botón reponer, rellena el formularios con los datos de inicio;


3.7 Proyecto

(1) Módulo de proyectos;

(2) Botones con tres grupos de proyectos, los proyectos sin iniciar (programación), los que están

en ejecución, y los proyectos que concluyeron y están con resultados;

(3) Menú principal, cambio de módulos;

(4) Contador de proyectos, en lila 1 programado, en celeste 2 ejecutando y cian 1 concluido.

3.8 Proyecto - Programación

(1) Lista de proyectos en fase de programación, clic en el texto y se despliega el contenido;

(2) Indicadores de efecto de proyecto;

1

4

3

2

1

8

7

10

(3) Componentes del proyecto;

(4) Presupuesto de proyecto.

(5) Notificaciones por cuantías de proyecto.

(6) Adicionar nuevo proyecto.

(7) Botones de proyectos en programación, ejecución y con resultados finales.

3.8.1 Proyecto – Programación - Adición

(1) Es el código CADELP; (2) Se espera la denominación del proyecto;

(3) Solo el objetivo principal del proyecto; (4) Descripción corta de los beneficiarios;

(5) Fecha de inicio del proyecto, se debe elegir del calendario;

(6) Fecha de fin del proyecto, se debe elegir del calendario;

1

15

14

2

3

4

5 6

7

8

9

10

11

12 13

11

(7) Calendario de selección de fecha;

(8) Fuente(s) de financiamiento(s), pueden ser recursos propios y/o externos;

(9) El techo presupuestario es el límite de recursos disponible para el proyecto;

(10) Contra parte técnica, personal de la institución que hace seguimiento;

(11) Categoría programática según las áreas de trabajo de la institución;

(12) Botón enviar, se activa si todos los campos cumplen con las reglas de validación;

(13) Botón limpiar, resetea el formulario;

(14) Botón Programación, retorna al listado de proyectos programados;

(15) Menú principal, para cambio de módulo.

3.8.2 Proyecto – Programación – Reporte de proyecto

(1) Reporte del proyecto;

(2) Modificar proyecto, permite actualizar datos del proyecto;

(3) Eliminar, permite borrar el proyecto y sus dependencias componentes, actividades, indicadores,

presupuestos y cuantías para el seguimiento;

(4) Cerrar reporte en pantalla y volver al listado de proyectos programados;

1

2 3

4

12

3.8.3 Proyecto – Programación - Modificación

(1 al 10) son información recuperada que se puede modificar;

(11) Botón de enviar, se activa si los campos cumplen con las validaciones;

(12) Solo el objetivo principal del proyecto;

(13) Botón Programación, retorna al listado de proyectos programados;

(14) Menú principal, para cambio de módulo.

1

14

13

2

3

4

5 67

8

9

10

11 12

13

3.8.4 Proyecto – Programación - Eliminación

(1) Aceptar, confirma la eliminación del proyecto y sus dependencias;

(2) Cancelar eliminación;

(3) Botón de eliminación, permite borrar el proyecto;

(4) Cerrar pantalla de dialogo;

3.9 Proyecto – Programación – indicadores de efecto y producto

En el sistema de información se mide a los proyecto con indicadores de efecto los que pueden ser

tipo porcentaje, tasa, índice, unidades, cualitativos, cada uno debe contar con hitos o puntos de

control que deben ser reportados según las fechas programadas en la etapa de ejecución del

proyecto.

32

1

4

1

2

4

67

3

14

(1) Lista de indicadores e hitos;

(2) Botón adicionar indicador, permite definir una unidad de medida;

(3) Botón adicionar hito, permite establecer un punto de control;

(4) Botón modificar hito, permite cambiar la fecha de reporte de hito;

(5) Botón eliminar hito, permite cambiar la fecha de reporte de hito;

(6) Botón programación, permite retornar a la lista de proyectos programados;

(7) Botones de menú principal para cambio de módulo.

3.9.1 Proyecto – Programación – indicadores – Adición

(1) Combo box de selección de tipo de indicador;

(2) Se escribe el nombre del indicador;

(3) Se espera la fórmula de cálculo del indicador;

(4) Cifra línea base del indicador;

(5) Cifra meta del indicador;

(6) Aceptabilidad máxima de la meta (se activa con la línea base y la meta llenos);

(7) Aceptabilidad mínima de la meta (se activa con la línea base y la meta llenos);

(6 y 7) se define el área de confort del indicador

(8) Botón enviar, se activa si los campos cumplen con las validaciones;

(9) Botón limpiar, se resetea los campos del 1 al 7;

(10) Botón indicador efecto, permite retornar a la lista de indicadores del proyecto;

12

3

4

5

6

7 8 9

10

11

15


Esta forma de registro funciona para indicadores tipo porcentaje, tasa, índice y unidades

(1) Combo box de selección de tipo de indicador; (2) Se escribe el nombre del indicador;

(3) Se define el orden para almacenar al indicador; (4) Se escribe un concepto como valor;

(5) Se define el valor o concepto; (6) Se elimina un indicador;

(7) Se elige en la columna cuál de los valores es línea base;

(8) Se elige en la columna cuál de los valores de la meta;

(9) Indicadores, permite el retorno a la lista de indicadores de efecto;


3.9.2 Proyecto – Programación – indicador – Reporte

2

1

3

4 5

9

87

6

10

1

2

3

4

16

(1) Información del indicador;

(2) Botón modificar, abre un formulario para actualizar la información del indicador;

(3) Botón eliminar, abre un mensaje de confirmación para borrar el indicador;

(4) Cierra el reporte del indicador;

3.9.3 Proyecto – Programación – Indicador - Eliminación

(1) Mensaje de confirmación de eliminación del indicador;

(2) Botón aceptar, confirma borrado de indicador;

(3) Botón cancelar, se cancela el borrado de indicador;

(4) Cierra el reporte del indicador;

3.9.4 Proyectos – Programación – Indicador – Modificación

(1) Combo box de selección de tipo de indicador; (2) Se escribe el nombre del indicador;

(3) Se espera la fórmula de cálculo del indicador; (4) Cifra línea base del indicador;

(5) Cifra meta del indicador;

1

23

4

1

2

3 4

7

56

89

10

11

17

(6) Aceptabilidad máxima de la meta (se activa con la línea base y la meta llenos);

(7) Aceptabilidad mínima de la meta (se activa con la línea base y la meta llenos);

(6 y 7) se define el área de confort del indicador

(8) Botón enviar, se activa si los campos cumplen con las validaciones;

(9) Botón limpiar, se resetea los campos del 1 al 7;

(10) Botón indicador efecto, permite retornar a la lista de indicadores del proyecto;


3.9.5 Proyecto – Programación – Indicador – Hitos – Adición

(1) Selección fecha; (2) Botón enviar formulario; (3) Botón limpiar formulario;

(4) Cifra línea base del indicador;

3.9.6 Proyecto – Programación – Indicador– Hitos – Modificación

(1) Calendario de Selección fecha; (2) Fecha de hito; (3) Botón enviar formulario;

12 3

4

1

2

3 4

5

18

(4) Botón limpiar formulario; (4) Retornar a lista de indicador de efecto.

3.9.7 Proyecto – Programación – Indicador – Hito – Eliminación

(1) Mensaje de confirmación de eliminación; (2) Acepta eliminar; (3) Cancela la eliminación;

3.10 Proyecto – Programación – Componente

(1) Lista de componentes y actividades; (2) Permite adicionar nuevo componente; (3) Da curso a

modificar el componente; (4) Permite eliminar el componente y todas sus actividades dependientes;

(5) Permite adicionar nueva actividad en el componente; (6) Permite modificar la actividad; (7)

Permite eliminar la actividad; (8) Retorna al proyecto en fase de programación.

32

1

1

23

6

45

7

8

19

3.10.1 Proyecto – Programación – Componente – Adición

(1) Campo para recibir el nombre del componente; (2) Elegir fecha inicio de componente; (3)

Seleccionar fecha fin de componente; (4) Anotación de consideraciones; (5,6) Botones de envió y

limpiar formulario; (7) Retorno a listado de componentes y actividades.

3.10.2 Proyecto – Programación – Componente – Modificación

(1) Actualizar campo nombre del componente; (2) Elegir fecha inicio de componente; (3)

Seleccionar fecha fin de componente; (4) Anotación de consideraciones; (5) Botón envió;(6)

Calendario; (7) Retorno a listado de componentes y actividades.

1

23

4

5 6

7

1

23

45

6

7

20

3.10.3 Proyecto – Programación – Componente – Eliminación

(1) Información para la confirmación; (2) Confirma eliminación; (3) Cancela borrado.

3.10.4 Proyectos – Programación – Adición de Actividad

(1) Información de actividad; (2) Selecciona fecha de inicio de actividad; (3) Elije fecha fin de

actividad; (4) Consideraciones sobre la actividad; (5) Responsable; (6) Botones de envió y limpiar;

(7) Calendario de selección; (8) Botón de retorno lista de componentes y actividades.

1

2

3

1

2 3

4

5

6

7

8

21

3.10.5 Proyecto – Programación – Actividad – Modificación

(1) Actualice información de actividad; (2) Selecciona fecha de inicio de actividad; (3) Elije fecha

fin de actividad; (4) Actualice consideraciones sobre la actividad; (5) Responsable; (6) Botones de

envió y limpiar; (7) Calendario de selección; (8) Botón retorno lista de componentes y actividades.

3.10.6 Proyecto – Programación – Actividad – Eliminación

(1) Información para la confirmación;

(2) Confirma eliminación; (3) Cancela borrado.

1

2 3

4

5

6

7

8

1

23

22

3.11 Proyecto – Programación - Ítem presupuesto

(1) Lista de ítems de presupuesto; (2) Permite registrar un nuevo ítem; (3) Permite modificar el

ítem de presupuesto; (4) Permite eliminar el ítem seleccionado; (5) Retorna lista de proyectos.

3.11.1 Proyecto – Programación – Ítem presupuesto – Adición

(1) Seleccione el objeto de gasto; (2) Combo de selección de grupo; (3) Elija el subgrupo; (4)

Defina la partida; (5) Describa el ítem; (6) Anote el monto presupuestado; (7) Botones de

operaciones; (8) Retorna al listado de presupuesto del proyecto.

2

13 4

5

1

2

3

4

5

6 7

8

23

3.11.2 Proyecto – Programación – Ítem presupuesto – Modificación

(1) Seleccione el objeto de gasto a modificar; (2) Combo de selección de grupo; (3) Elija el

subgrupo; (4) Defina la partida; (5) Describa el ítem; (6) Anote el monto presupuestado; (7)

Botones de operaciones; (8) Retorna al listado de presupuesto del proyecto.

3.11.3 Proyecto – Programación – Ítem presupuesto – Eliminación

(1) Información para la confirmación; (2) Confirma eliminación; (3) Cancela borrado.

1

2

45

7

3

6

8

21

3

24

3.12 Proyecto – Ejecución – Notificaciones por Cuantías

(1) Lista de notificaciones por cuantías definidas nivel de ejecución presupuestaria; (2) Adición

normal y por cuantía; (3) Modificación y eliminación de ítem de cuantía; (4) Lista de notificaciones

de tiempo. (5) Adición normal o por cuantía; (6) Modificación y eliminación de cuantía; (7)

Retorno a programación de proyectos.

3.12.1 Proyecto – Ejecución – Notificación por Cuantías de tiempo

(1) Combo box de selección de cuantías sugeridas por el sistema; (2) Botones enviar y limpiar; (3)

Retorno listado de notificaciones.

7

6

5

3 2

4

1

1

3

2

25

3.12.2 Proyecto – Ejecución – Notificación por Cuantía financiera

(1) Combo box de selección de cuantías sugeridas por el sistema por ejecución presupuestaria

acumulada; (2) Botones enviar y limpiar; (3) Retorno listado de notificaciones.

3.13 Proyecto – Ejecución – Seguimiento Físico – Financiero

Se hace seguimiento físico (actividades e indicadores de impacto, efectos) y el seguimiento

financiero (ejecución financiera de los ítems). Se pueden reprogramar actividades y presupuesto.

(1) Lista de proyectos en ejecución; (2) Indicadores de efecto a reportar; (3) Componentes permite

reportar actividades e indicadores de producto; (4) Permite reportar ejecución presupuestaria; (6)

Permite ver la lista de notificaciones por cuantías.

2

3

1

13 4 52

26

3.13.1 Proyecto – Ejecución – Seguimiento Indicador

(1) Lista de indicadores e hitos; (2) gráfico por indicador e hitos; (3) hito por reportar para que

llegue la fecha; (4) Hito sin reportar, se espera que reporte hito anterior; (5) Hito habilitado para

reportar; (6) Hito reportado; (7) Retorno a lista de proyectos en ejecución.

3.13.2 Proyecto – Ejecución – Seguimiento Actividad

16

5

4

3

2

7

1

2

3

4

5

6

27

(1) Lista de componentes y actividades; (2) Adición de actividad; (3) Modificar y eliminar

actividad; (4) Reportar cumplimiento de actividad; (5) Ingreso a indicadores de efecto para

reportar; (6) Retorno a lista de proyectos en ejecución.

3.13.3 Proyecto – Ejecución – Seguimiento Ítem presupuesto

(1) Lista ítems de presupuesto; (2) Gráfico; (3) Modificar y eliminar ítem; (4) Adicionar ítem; (5)

Retorno a lista de proyectos en ejecución.

3.13.4 Proyecto – Ejecución - Adición de ejecución presupuestaria

1

2

3

4

5

1

2

34

5

6

28

(1) Seleccionar fecha factura; (2) Detalle; (3) Monto invertido; (4) Examinar archivo (foto de la

factura); (5) Botones de envío y limpiar ,(6) Retorno a lista de proyectos en ejecución.

3.13.5 Proyecto – Ejecución - Modificación de ejecución presupuestaria

(1) Seleccionar fecha; (2) Detalle; (3) Monto invertido; (4) foto de factura; (5) Habilita cambio; (5)

Buscar archivo nuevo a subir; (6) Botones de envío y limpiar (7) Retorno lista de presupuesto.

3.13.6 Proyecto – Ejecución - Eliminación de ejecución presupuestaria

(1) Información de la ejecución presupuestaria a eliminar; (2) Confirma borrado; (3) Cancela.

1

2

3

5

4

6

7

1

23

29

3.14 Proyecto – Ejecución – Notificación y Alertas

Las notificaciones y alertas son enviadas por correo electrónico estos son unos servicios.

3.14.1 Proyecto – Ejecución – Envío de E-mail por notificación o alertas

(1) Asunto del e-mail enviado por el sistema; (2) Detalle auto generado por el servidor.

3.15 Proyecto – Resultados – Página Proyectos –Reporte final en PDF

(1) Reporte del proyecto con el botón reporte en proyectos resultado; (2) Archivo PDF.

1

1

2

2

30

4. Preguntas Frecuentes

4.1 Sobre el sistema

¿Por qué no me llega el correo electrónico de activación de cuenta?

Busque en su correo electrónico en las capetas de spam, correo no deseado, para evitar ese

problema se recomienda el uso de cuentas de correo institucional.

¿Qué hago si olvide mi contraseña?

En la pantalla de inicio existe un enlace que le permite recuperar la contraseña debe enviar su

correo electrónico y completar el captcha de seguridad

¿No logro activar mi cuenta en el sistema?

Debe abrir el correo electrónico que tiene como asunto Activación de Cuenta CADELP, en el

mensaje existe un enlace que activa la cuenta del sistema.

¿Por qué no tengo acceso a toda la información como el administrador?

En la institución cada funcionario tiene su rol definido en ese entendido el sistema funciona en

términos de roles y sus acciones son las necesarias en el sistema.

¿Puedo cambiar de rol en el sistema?

Si, debe consultar con el administrador del sistema

¿A quiénes llegan los correos del sistema?

A todos los comprometidos en el proyecto.

¿Puedo asumir más de dos roles en el sistema?

Si, para ello debe comunicarse con el administrador y crear una cuenta nueva con el rol deseado

¿Es posible bloquear a los usuarios cuando terminan su trabajo?

Si existe necesidad de bloquear a algún usuario el administrador tiene acceso para esa operación.

Documentos

Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp

Education

Transcript of Sistema de seguimiento_y_monitoreo_de_proyectos_orientados_resultados_cadelp