Aplicación web para el apoyo del programa ALIADOS 2013

UNIVERSIDAD ALAS PERUANAS FACULTAD DE INGENIERÍAS Y ARQUITECTURA ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS E

INFORMÁTICA

TESIS

“APLICACIÓN WEB PARA EL APOYO DEL REGISTRO Y MONITOREO DE PLANES DE

NEGOCIO DEL PROGRAMA ALIANZAS RURALES PRODUCTIVAS DE LA SIERRA -

ALIADOS DEL MINISTERIO DE AGRICULTURA – 2013”

PRESENTADO POR EL BACHILLER

MARBIN RUSBELT RAMÍREZ CHÁVEZ

PARA OPTAR EL TÍTULO PROFESIONAL DE INGENIERO DE SISTEMAS E INFORMÁTICA

AYACUCHO - PERÚ

2013

DECLARACIÓN DE DERECHOS DE AUTOR

Esta obra esta publicada bajo la licencia Creative Commons Atribución-

NoComercial-SinDerivadas 2.5 Perú.

Puedes copiar, compartir y referenciar este e-book indicando a “Marbin Rusbelt

Ramírez Chávez” como fuente. (https://www.facebook.com/marbin.ramirez)

Para ver una copia de esta licencia, visita “http://creativecommons.org/licenses/by-nc-

nd/2.5/pe/”

http://creativecommons.org/licenses/by-nc-nd/2.5/pe/


https://www.facebook.com/marbin.ramirez



DEDICATORIA

A Flor y Nilo, mis padres, quienes me brindan su apoyo incondicional.

A Nicolle, mi hermana y mi motivo de superación.

AGRADECIMIENTOS

A Dios, por darme la vida.

Al ingeniero Felix Mendoza, por haber confiado en mí y por su

esmerado asesoramiento.

Al ingeniero Heber Munaylla, por sus enseñanzas y apoyo en las

diferentes etapas de este proyecto.

A los ingenieros Hubner Janampa y Elvira Fernandez, por sus

asesoramientos y apoyo activo para lograr culminar el presente trabajo

de tesis.

A todos mis familiares y amigos que directa o indirectamente

contribuyeron a alcanzar este logro.

INTRODUCCIÓN

En el mundo globalizado que conformamos y que está en constante interrelación con

las empresas e instituciones públicas y privadas, se tiene que hacer frente a los

diversos retos, a la competencia, la utilización de las diversas tecnologías y a las

nuevas tendencias.

Las nuevas herramientas tecnológicas permiten a los investigadores satisfacer todos

los requerimientos y solucionar los problemas que se vienen suscitando, en este caso

se ha escogido la tecnológica Web.

El presente trabajo de investigación “Aplicación web para el apoyo del registro y

monitoreo de planes de negocio del programa Alianzas Rurales Productivas de la

Sierra - ALIADOS del Ministerio de Agricultura – 2013” tiene como objetivo desarrollar

una aplicación web para apoyar a los procesos de Registro y Monitoreo de planes de

negocio, mejorando el control de los Componentes y Actividades del plan de negocio a

través de indicadores como el costo y tiempo utilizando conceptos actuales como

Enfoque de Gestión por Resultados (EGR), Enfoque del Marco Lógico (EML) y la

Gestión del Valor Ganado (EVM), así como contribuir en los procesos de evaluación a

nivel de resultados de los planes cofinanciados por el Programa ALIADOS y reducir de

manera significativa el tiempo necesario para realizar dichos procesos. Logrando de

esta manera un aporte al desarrollo tecnológico en el monitoreo planes de negocio.

La supervisión, el correcto funcionamiento del software y el cumplimiento de los

requisitos del trabajo de investigación será supervisado por la oficina de Coordinación

de Monitoreo, Evaluación e Informática del Programa ALIADOS, quien cumple la

correspondiente función de Oficina de Dirección de Proyectos (PMO), el mismo que

tiene más de 5 años de experiencia cofinanciando proyectos y planes de negocio en el

marco del Sistema Nacional de Inversión Pública.

La estructura del presente trabajo de investigación, consta de cinco capítulos:

Planteamiento Metodológico, Marco Teórico, Construcción de la Herramienta, Análisis

e Interpretación de Resultados, Conclusiones y Recomendaciones.

En el capítulo I se describe el Planteamiento Metodológico, describiendo la situación

actual del Programa de Apoyo a las Alianzas Rurales Productivas de la Sierra –

ALIADOS del Ministerio de Agricultura, definición del problema, las delimitaciones,

justificación e importancia de la investigación, terminando en la descripción de los

métodos y técnicas a ser usados por el investigador.

En el capítulo II se describe el Marco Teórico, describiendo la herramienta o tecnología

a implementar, se desarrolla las variables, además se incluye el desarrollo de los

conceptos relacionados a la Tecnología Web y los procesos en estudio.

En el Capítulo III se muestra la información a la construcción de la herramienta

tecnológica usada en este proyecto, así como el estudio de la factibilidad técnica,

operativa y económica.

En el Capítulo IV se analizarán e interpretarán los resultados obtenidos con el estudio

estadístico de los indicadores descritos en el primer capítulo, permitiendo demostrar la

afirmación o negación de la hipótesis

En el Capítulo V las conclusiones mencionamos de manera específica los resultados

obtenidos en la presente investigación. De la misma manera se indica las

recomendaciones que se consideran adecuadas para la obtener los logros

conseguidos y complementar este proyecto.

TABLA DE CONTENIDOS

DECLARACIÓN DE DERECHOS DE AUTOR II

DEDICATORIA III

AGRADECIMIENTOS IV

INTRODUCCIÓN V

TABLA DE CONTENIDOS VII

ÍNDICE DE GRÁFICOS X

ÍNDICE DE TABLAS XI

CAPÍTULO I PLANTEAMIENTO METODOLÓGICO 14

1.1. Descripción de la Realidad Problemática 14 1.2. Delimitaciones y Definición del Problema 16

1.2.1. Delimitaciones 16 1.2.2. Definición del Problema 18

1.3. Formulación del Problema 19 1.3.1. Problema principal 19 1.3.2. Problemas secundarios 19

1.4. Objetivo de la Investigación 19 1.4.1. Objetivo principal 19 1.4.2. Objetivos secundarios 19

1.5. Hipótesis de la investigación 20 1.5.1. Hipótesis principal 20 1.5.2. Hipótesis secundarios 20

1.6. Variables e Indicadores 20 1.6.1. Variable Independiente 20 1.6.2. Variable Dependiente 20

1.7. Viabilidad de la investigación 21 1.7.1. Viabilidad técnica 21 1.7.2. Viabilidad operativa 21 1.7.3. Viabilidad económica 21

1.8. Justificación e Importancia de la Investigación 22 1.8.1. Justificación 22 1.8.2. Importancia 23

1.9. Limitaciones de la Investigación 23 1.10. Tipo y Nivel de la Investigación 24

1.10.1. Tipo de investigación 24 1.10.2. Nivel de investigación 24

1.11. Método y Diseño de la investigación 25

1.11.1. Método de la investigación 25 1.11.2. Diseño de la investigación 25

1.12. Técnicas e Instrumentos de Recolección de Información 26 1.12.1. Técnicas 26 1.12.2. Instrumentos 26

1.13. Cobertura de Estudio 27 1.13.1. Universo 27 1.13.2. Población 27 1.13.3. Muestra 27

1.14. Cronograma y Presupuesto 28 1.14.1. Cronograma 28 1.14.2. Presupuesto 29

CAPÍTULO II MARCO TEÓRICO 30

2.1. Antecedentes de la Investigación 30 2.1.1. Trabajos de investigación a Nivel Internacional 30 2.1.2. Trabajos de investigación a Nivel Nacional 32

2.2. Marco Histórico 34 2.2.1. Evolución de la web 34 2.2.2. Evolución de la ejecución de la Inversión Pública en el Perú 35

2.3. Marco Conceptual 35 2.3.1. Aplicación web 35 2.3.2. Calidad software 36 2.3.3. Enfoque de Gestión por Resultados 39 2.3.4. Enfoque del Marco Lógico (EML) 42 2.3.5. Programa de Apoyo a las Alianzas Rurales Productivas de la Sierra – ALIADOS 44 2.3.6. Planes de Negocio en el Programa ALIADOS 45 2.3.7. Guía del PMBOK® 5° edición 47 2.3.8. Programación Orientada a Objetos (POO) 47 2.3.9. Patrones de Diseño de Software 47 2.3.10. Presentación y contenido 49 2.3.11. Tecnologías de scripting 50 2.3.12. Librerías y plugins 52 2.3.13. Sistema de gestión de base de datos 52 2.3.14. Desarrollo de proyectos Web 54 2.3.15. Dreamweaver 57 2.3.16. MagicDraw UML 57 2.3.17. Prueba T de Student para muestras relacionadas 57 2.3.18. Prueba de Wilcoxon 58

CAPÍTULO III CONSTRUCCIÓN DE LA HERRAMIENTA 59

3.1. Generalidades 59 3.1.1. Acta de Constitución del Proyecto 62 3.1.2. Plan de Dirección del Proyecto 64 3.1.3. Organización del proyecto 67 3.1.4. Comunicación del proyecto 67

3.2. Estudio de factibilidad 69 3.2.1. Factibilidad Técnica 69 3.2.2. Factibilidad Operativa 70 3.2.3. Factibilidad Económica 70

3.3. Análisis del sistema 77 3.3.1. Requerimientos 82 3.3.2. Definición de los actores del sistema 86

3.3.3. Requerimientos del sistema 86 3.3.4. Listado de casos de uso del sistema (Simplificado) 89 3.3.5. Descripción de casos de uso del sistema 90 3.3.6. Diagrama de casos de uso (Simplificado) 98

3.4. Diseño del sistema 98 3.4.1. Modelo de contenidos 98 3.4.2. Modelo de navegación (Simplificado) 100 3.4.3. Modelo de presentación 102 3.4.4. Modelo de procesos y diagramas de flujo de procesos 106 3.4.5. Diseño de pantallas 113

3.5. Cierre del proyecto 118 3.5.1. Solicitud de cambio Nº 001 118 3.5.2. Informe de monitoreo de riesgos 119 3.5.3. Inspección de calidad Nº 002 120 3.5.4. Acta de aceptación del proyecto 121 3.5.5. Lecciones aprendidas 122

CAPITULO IV ANÁLISIS E INTERPRETACIÓN DE LOS RESULTADOS 123

4.1. Población y muestra 123 4.1.1. Población 123 4.1.2. Muestra 123

4.2. Nivel de confianza y grado de significancia 123 4.3. Tamaño de la muestra representativa 124 4.4. Análisis de resultados 124

4.4.1. Grupo de control 125 4.4.2. Grupo experimental 133

4.5. Prueba de hipótesis 141 4.5.1. Hipótesis de investigación 141 4.5.2. Hipótesis nula 141 4.5.3. Hipótesis estadística 141

4.6. Prueba de estadística utilizada 142 4.6.1. Prueba de hipótesis para el indicador Eficiencia 144 4.6.2. Prueba de hipótesis para el indicador Situación 147 4.6.3. Prueba de hipótesis para el indicador Avance del trabajo 155

CAPITULO V CONCLUSIONES Y RECOMENDACIONES 159

5.1. Conclusiones 159 5.2. Recomendaciones 160

FUENTES DE INFORMACIÓN 161

ANEXOS 163

GLOSARIO DE TÉRMINOS 200

ÍNDICE DE GRÁFICOS

Gráfico 1 EVOLUCIÓN DE LA WEB 34 Gráfico 2 INVERSIÓN PÚBLICA ACUMULADA ÚLTIMOS 12 MESES 35 Gráfico 3 MARCO LÓGICO 42 Gráfico 4 PATRÓN DE DISEÑO DATA TRANSFER OBJECT DIAGRAMA DE CLASE 49 Gráfico 5 COMPARACIÓN GRÁFICA DEL MODELO TRADICIONAL DE APLICACIÓN WEB Y

DEL NUEVO MODELO PROPUESTO POR AJAX 51 Gráfico 6 ORGANIGRAMA DEL PROYECTO 67 Gráfico 7 ACTORES INTERNOS Y EXTERNOS DEL NEGOCIO 84 Gráfico 8 ACTORES DEL SISTEMA 86 Gráfico 9 DIAGRAMA DE CASOS DE USO 98 Gráfico 10 MODELO DE CONTENIDO – REGISTRO DE PLAN DE NEGOCIO 99 Gráfico 11 MODELO DE CONTENIDO – REGISTRO DEL FORMATO PAO 100 Gráfico 12 MODELO DE NAVEGACIÓN 101 Gráfico 13 MODELO DE PRESENTACIÓN - CREAR NUEVO PLAN DE NEGOCIO 103 Gráfico 14 MODELO DE PRESENTACIÓN - REGISTRAR PLAN DE NEGOCIO 104 Gráfico 15 MODELO DE PRESENTACIÓN - BUSCAR PLANES DE NEGOCIO 105 Gráfico 16 MODELO DE PRESENTACIÓN - REGISTRO DEL FORMATO PAO 106 Gráfico 17 MODELO DE ESTRUCTURA DE PROCESOS 107 Gráfico 18 DIAGRAMA DE FLUJO DE PROCESOS – CREAR NUEVO PLAN DE NEGOCIO

110 Gráfico 19 DIAGRAMA DE FLUJO DE PROCESOS – REGISTRAR PLAN DE NEGOCIO 111 Gráfico 20 DIAGRAMA DE FLUJO DE PROCESOS – VER FICHA DE REGISTRO 112 Gráfico 21 DIAGRAMA DE FLUJO DE PROCESOS – REGISTRO DEL FORMATO PAO 112 Gráfico 22 INTERFACE DE INICIO DE SESIÓN 113 Gráfico 23 INTERFACE DE REGISTRO DE NUEVO PLAN DE NEGOCIO 114 Gráfico 24 INTERFACE DE REGISTRO DE PLANES DE NEGOCIO 115 Gráfico 25 BÚSQUEDA Y CAMBIO DE ESTADO DEL PLAN 116 Gráfico 26 INTERFACE DE REGISTRO DEL FORMATO PAO 117

ÍNDICE DE TABLAS

Tabla 1 CRONOGRAMA Y TAREAS DEL DESARROLLO DE LA INVESTIGACIÓN 28

Tabla 2 DIVISIÓN DE LAS CARACTERÍSTICAS DE LA CALIDAD DEL SOFTWARE

SEGÚN EL ISO/IEC 9126 37

Tabla 3 RELACIÓN DE LOS ENTREGABLES DEL PMBOK CON LAS SECCIONES DE LA

TESIS 60

Tabla 4 MATRIZ DE COMUNICACIONES DEL PROYECTO 68

Tabla 5 REQUERIMIENTOS DEL PERSONAL PARA EL DESARROLLO DEL PROYECTO 69

Tabla 6 REQUERIMIENTOS DE SOFTWARE PARA EL DESARROLLO DEL PROYECTO 69

Tabla 7 REQUERIMIENTOS DE HARDWARE PARA EL DESARROLLO DEL PROYECTO 70

Tabla 8 COSTEO DEL PROYECTO 71

Tabla 9 RESUMEN DEL TOTAL DE COSTO 76

Tabla 10 COSTO POR PERSONAL 76

Tabla 11 COSTO POR SOFTWARE 76

Tabla 12 LISTA DE INTERESADOS 82

Tabla 13 MATRIZ DE INFLUENCIA VS PODER 83

Tabla 14 MATRIZ INTERÉS VS PODER 83

Tabla 15 NECESIDADES GENÉRICAS DE LOS ACTORES DEL NEGOCIO 85

Tabla 16 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - ESTADÍSTICA

DESCRIPTIVA 125

Tabla 17 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO – TABLA DE

FRECUENCIAS 126

Tabla 18 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - ESTADÍSTICA

DESCRIPTIVA 127

Tabla 19 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - TABLA DE

FRECUENCIAS 127

Tabla 20 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO -

ESTADÍSTICA DESCRIPTIVA 128


TABLA DE FRECUENCIAS 128

Tabla 22 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - ESTADÍSTICA

DESCRIPTIVA 129

Tabla 23 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - TABLA DE

FRECUENCIAS 129

Tabla 24 TIEMPO EN CALCULAR EL ÍNDICE DEL DESEMPEÑO DEL CRONOGRAMA -




Tabla 26 TIEMPO EN CALCULAR EL PORCENTAJE DE LA VARIACIÓN DEL COSTO -




Tabla 28 TIEMPO EN CALCULAR EL PORCENTAJE DE LA VARIACIÓN DEL

CRONOGRAMA - ESTADÍSTICA DESCRIPTIVA 132


CRONOGRAMA - TABLA DE FRECUENCIAS 132

Tabla 30 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - ESTADÍSTICA

DESCRIPTIVA 133

Tabla 31 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - TABLA DE FRECUENCIAS 134

Tabla 32 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - ESTADÍSTICA

DESCRIPTIVA 135

Tabla 33 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - TABLA DE

FRECUENCIAS 135

Tabla 34 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO-





DESCRIPTIVA 137

Tabla 37 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - TABLA DE

FRECUENCIAS 137










CRONOGRAMA - ESTADÍSTICA DESCRIPTIVA 140


CRONOGRAMA - TABLA DE FRECUENCIAS 140

Tabla 44 TABLA DE PRUEBAS ESTADÍSTICAS CON UN OBJETIVO COMPARATIVO 142

Tabla 45 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - PRUEBA DE

NORMALIDAD 144

Tabla 46 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - PRUEBA T DE STUDENT

PARA MUESTRAS RELACIONADAS 145

Tabla 47 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - PRUEBA DE

NORMALIDAD 147

Tabla 48 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO -

PRUEBA DE WILCOXON (RANGOS) 147

Tabla 49 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO -

PRUEBA DE WILCOXON (ESTADÍSTICOS DE PRUEBA) 148


PRUEBA DE NORMALIDAD 149





Tabla 53 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA -


Tabla 54 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - PRUEBA DE

WILCOXON (RANGOS) 151


WILCOXON (ESTADÍSTICOS DE PRUEBA) 152

Tabla 56 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL CRONOGRAMA -













CRONOGRAMA - PRUEBA DE NORMALIDAD 157


CRONOGRAMA - PRUEBA DE WILCOXON (RANGOS) 157


CRONOGRAMA - PRUEBA DE WILCOXON (ESTADÍSTICOS DE PRUEBA) 158

14

CAPÍTULO I

PLANTEAMIENTO METODOLÓGICO

1.1. Descripción de la Realidad Problemática

En la actualidad las tecnologías de la información y las comunicaciones (TIC)

continúan ejerciendo progresivamente su impacto en todas las esferas de la

vida social. Según el Instituto Nacional de Estadística e Informática (INEI) a

inicios del año 2013, se indicó que el 25.5% de los hogares del país tienen

conexión a internet, es un crecimiento del 8.2% respecto al trimestre del año

anterior. En las zonas urbanas este servicio se incrementó en 8.6% con una

cobertura del 25.9%. Así mismo las velocidades de conexión a internet aún no

logra llegar al promedio mundial donde Corea lidera el acceso más rápido a

internet con 14.2mbps, seguido de Japón con 11.7mbps, en Latinoamérica solo

Chile y México alcanzan el promedio mundial de 3mbps y 3.3mbps

respectivamente, mientras que Perú solo alcanzó 2.0mbps1. A junio del 2012

OSIPTEL informa que el estado peruano cuenta con 467,982 dispositivos

móviles activos (Modém usb, tablets, netbooks con Sim-Card) de un total de

773,506 vendidos entre los diferentes proveedores (Telefónica Móviles,

América Móvil, Nextel y Velatel)2. Sin duda el Perú ha tenido un gran avance

tecnológico en los últimos años, pero aún falta llenar una gran brecha para

lograr una sociedad informática.

Latinoamérica no se ha quedado atrás y ha aplicado la tecnología informática a

los Sistemas Nacionales de Inversión Pública (SNIP). Tal es el caso de

Argentina que a fines del 2002, la Secretaría de Política Económica decidió

implementar un nuevo sistema de información que contemple los proyectos de

inversión pública identificados por los organismos responsables, denominado

1 Diario Gestión. Diario Gestión. [Online].; 2013 [citado 2013 septiembre 25. Disponible en:

http://gestion.pe/economia/mef-confirma-inversion-publica-aumento-9-mayo-2069523. 2 OSITEL. [Dispositivos que acceden a internet a Junio 2012 (Módem USB, Tablets y otros)].;

2012.

http://gestion.pe/economia/mef-confirma-inversion-publica-aumento-9-mayo-2069523

15

BAPIN II, el cual brinda información sobre programas, subprogramas,

proyectos y actividades e incorpora los programas con organismos

internacionales de crédito. Venezuela cuenta con el Sistema de Información de

Inversión Pública (SIIP), herramienta informática que permite registrar y

procesar información actualizada de las iniciativas de inversión durante su ciclo

de vida y permite apoyar la toma de decisiones.1

En el ámbito nacional el Ministerio de economía y finanzas (MEF) también

cuenta con el SNIP, el cual se encarga de certificar la calidad de los Proyectos

de Inversión Pública (PIP).

Actualmente el Estado financia otros proyectos y planes de negocio los cuales

no son registrados ni controlados por el SNIP

Este es el caso del Programa de Apoyo a las Alianzas Rurales Productivas de

la Sierra – ALIADOS del Ministerio de Agricultura que entre los años 2008 y

2013 ha cofinanciado 1740 proyectos en el marco del SNIP. Actualmente está

ingresando a una segunda etapa, donde el principal objetivo será la gestión de

planes de negocio y planes de desarrollo territorial en un aproximado de 1,200

planes entre fines del año 2013 y el 2016, los mismos que no serán registrados

en el SNIP, por lo cual se ha visto afectado por la falta de una herramienta que

cumpla con los requisitos para llevar a cabo sus nuevos objetivos.

Para que ALIADOS cumpla con sus objetivos es necesario llevar un control en

3 procesos de los planes de negocio:

El registro de los planes, como base para realizar los procesos de

Monitoreo, que es la identificación de los desvíos existentes respecto a

lo programado y

la Evaluación; que es la comparación del estado actual y el estado

previsto de los planes de negocio establecidos en la etapa de

planificación.

1 Ortegón E, Pacheco JF. Los Sistemas nacionales de inversión pública en Argentina, Brasil,

México, Venezuela y España como caso de referencia (cuadros comparativos) Santiago de Chile: Instituto Latinoamericano y del Caribe de Planificación Económica; 2005, pp. 15-34, 81-103.

16

1.2. Delimitaciones y Definición del Problema

1.2.1. Delimitaciones

a. Delimitación Espacial

El presente trabajo tendrá como límite espacial a todas las

instituciones que desarrollen, monitoreen y evalúen planes de

negocio. Para efecto de la investigación se desarrolló en el

Programa de Apoyo a las Alianzas Rurales Productivas de la Sierra

– ALIADOS del Ministerio de Agricultura que maneja planes de

negocio desde hace 5 años en los departamentos de Ayacucho,

Apurímac, Huancavelica, Huánuco, Junín y Pasco con sede central

en la ciudad de Ayacucho.

b. Delimitación Temporal

El trabajo se realizará en dos fases:

La primera fase comprende la formulación plan de tesis

iniciado el 01 de agosto del 2013 y la presentación del mismo

el 15 de agosto del 2013.

La segunda fase es el desarrollo de la tesis, el cual inicia el

01 de agosto del 2013 y finaliza con las recomendaciones y

conclusiones el 13 de noviembre del 2013.

Como se describe ambas fases se inician el mismo día ya que la

redacción del plan de tesis se realiza según se establece el alcance,

tiempo, costos, calidad, etc., junto al Programa ALIADOS. Mientras

se espera la aprobación del plan de tesis se inicia la gestión del

proyecto y elaboración de los entregables con lo cual se redacta y

actualiza el borrador de la tesis, tal y como se especifica en el

cronograma del proyecto.

c. Delimitación Social

En el presente trabajo de investigación, se involucra a todo el

personal encargado del registro, monitoreo, evaluación, tomadores

de decisiones y beneficiarios de los de planes de negocio del

Programa de Apoyo a las Alianzas Rurales Productivas de la Sierra

– ALIADOS del Ministerio de Agricultura.

17

d. Delimitación Conceptual

1. Aplicación web

Son aplicaciones que utilizan el internet o intranet como medio

de comunicación entre un cliente y un servidor, en decir una

aplicación software que se codifica en un lenguaje que lo

interpretan los navegadores web. Los principales componentes

de una aplicación web son: El cliente web, el servidor web y el

protocolo.

“El cliente web es un programa con el que interacciona el usuario (Navegador), la misión del cliente es interpretar páginas HTML (…). El servidor web es un programa que está esperando permanentemente las solicitudes de conexión mediante el protocolo HTTP por parte de los clientes.”1

2. Proceso de Registrar los planes de negocio

Es el proceso básico en el cual se registra los datos del plan de

negocio, estos datos se recopilan en una “Ficha de Registro de

Planes de Negocio y Planes de Desarrollo Territorial”.

Todo plan registrado se encuentra en una etapa de Propuesta,

esperando su evaluación para ser aprobada y declarada como

“Viable” o lo contrario “Anulado”. Una vez declarada como

Viable el plan puede pasar a la etapa de Ejecución.

3. Proceso de Monitoreo de Planes de negocio

Se realiza durante la etapa de Ejecución en donde se

comprueba continuamente los Componentes y Actividades

declaradas en el proceso de Registro del plan de negocio, esta

comprobación se realiza a través de la obtención y análisis de

datos o indicadores como el costo y tiempo, con el objetivo de

conocer los resultados de la gestión y definir, si es necesario, la

reprogramación requerida.

1 Luján Mora S. Programación de aplicaciones web: historia, principios básicos y clientes web

San Vicente: Club Universitario; 2002, pp. 48-49.

18

1.2.2. Definición del Problema

El Ministerio de Economía y Finanzas – MEF maneja el sistema

administrativo SNIP el cual se encarga, a través de principios, métodos,

procedimientos y normas técnicas, de certificar los Proyectos de

Inversión Pública (PIP).

El Programa ALIADOS cuenta con una herramienta de gestión de

proyectos, el cual es utilizado en los departamentos de Ayacucho,

Apurímac, Huancavelica, Huánuco, Junín y Pasco para el registro de los

mismos. Estos Proyectos al ser financiados por el Estado son

registrados y certificados por el SNIP.

Actualmente el Programa ALIADOS está ingresando a una segunda

etapa 2013 - 2016, donde deja de lado la evaluación de Proyectos para

centrarse en la Gestión de Planes de Negocio y de Desarrollo Territorial.

Estos planes no serán registrados en el SNIP, es decir, no serán

certificados con los procedimientos y métodos del SNIP. Además se ha

optado por utilizar el Enfoque de Gestión por Resultados - EGR y el

Enfoque del Marco Lógico - EML, utilizando la Matriz del Marco Lógico –

(MML) para Registrar y Monitorear los planes de negocio.

La herramienta informática actual no es capaz de cumplir con las

nuevas necesidades del Programa, por esta razón es vital la

construcción de una nueva herramienta que cuente con las

características necesarias para ayudar al Programa ALIADOS a cumplir

con los objetivos de esta segunda etapa.

19

1.3. Formulación del Problema

1.3.1. Problema principal

¿De qué manera una aplicación web mejorará el registro y monitoreo de

planes de negocio del Programa Alianzas Rurales Productivas de la

Sierra – ALIADOS del Ministerio de Agricultura - 2013?

1.3.2. Problemas secundarios

1. ¿Cómo la operatividad de la aplicación web mejora la eficiencia

del registro de planes de negocio?

2. ¿Cómo la exactitud de la aplicación web mejora la situación de los

planes de negocio?

3. ¿Cómo la exactitud de la aplicación web mejora el avance del

trabajo de los planes de negocio?

1.4. Objetivo de la Investigación

1.4.1. Objetivo principal

Determinar como una aplicación web mejora el registro y monitoreo de

planes de negocio del Programa Alianzas Rurales Productivas de la

Sierra – ALIADOS del Ministerio de Agricultura – 2013.

1.4.2. Objetivos secundarios

1. Determinar como la operatividad de la aplicación web mejora la

eficiencia del registro de planes de negocio.

2. Determinar como la exactitud de la aplicación web mejora la

situación de planes de negocio.

3. Determinar como la exactitud de la aplicación web mejora el

avance del trabajo de los planes de negocio.

20

1.5. Hipótesis de la investigación

1.5.1. Hipótesis principal

La aplicación web mejorará el registro y monitoreo de planes de negocio

del Programa de Apoyo a las Alianzas Rurales productivas de la Sierra

– ALIADOS del Ministerio de Agricultura – 2013.

1.5.2. Hipótesis secundarios

1. La operatividad de la aplicación web mejorará la eficiencia del

registro de planes de negocio.

2. La exactitud de la aplicación web mejorará la situación de los

planes de negocio.

3. La exactitud de la aplicación web mejorará el avance del trabajo

de los planes de negocio.

1.6. Variables e Indicadores

1.6.1. Variable Independiente

Variable Indicadores Índices

X = Aplicación web

X1 = Operatividad X11 = Número de intentos del usuario en realizar una tarea.

X2 = Exactitud X21 = Número de tareas ejecutadas correctamente.

1.6.2. Variable Dependiente


Y = Registro y Monitoreo de planes de negocio

Y1 = Eficiencia Y11 = Tiempo en registrar un plan de negocio.

Y2 = Situación

Y21 = Tiempo en calcular la Variación del costo (CV).

Y22 = Tiempo en calcular el Índice de desempeño del costo (CPI).

Y23 = Tiempo en calcular la Variación del cronograma (SV).

Y24= Tiempo en calcular el Índice de desempeño del cronograma (SPI).

Y3 = Avance del trabajo

Y31 = Tiempo en calcular el Porcentaje de variación del costo (CV%).

Y32 = Tiempo en calcular el Porcentaje de Variación del cronograma (SV%).

21

1.7. Viabilidad de la investigación

1.7.1. Viabilidad técnica

El trabajo de investigación es técnicamente viable ya que el Programa

ALIADOS dispone de los recursos necesarios para el desarrollo del

proyecto como son: infraestructura de hardware, software, red, internet.

Además que se cuenta con el apoyo del equipo de dirección y desarrollo

de proyectos con capacidades para gestionar e implementar el

proyecto.

1.7.2. Viabilidad operativa

El investigador cuenta con el conocimiento necesario para el

manejo de las diversas herramientas de desarrollo del trabajo de

investigación.

El investigador cuenta con el apoyo del Programa ALIADOS,

lugar donde se desarrolla el software. Se dispone de información

y apoyo necesario que ayude al proceso de investigación como:

informes, reportes, planes de negocios cerrados anteriormente,

acceso a internet.

1.7.3. Viabilidad económica

La realización del proyecto de investigación es viable debido a que los

costos son solventados por el Programa ALIADOS.

22

1.8. Justificación e Importancia de la Investigación

1.8.1. Justificación

El presente trabajo de investigación se justifica al encontrar que es de

actualidad y pertinencia debido a la falta de un software para apoyar los

procesos de monitoreo y evaluación de planes de negocios en el Perú,

desarrollando la gestión del proyecto con la Guía PMBOK Quinta

Edición lanzado a inicios del 2013, así mismo la construcción se

realizará con la metodología UWE de la Ingeniería Web. La aplicación

también abordará características fundamentales de los procesos de

monitoreo y evaluación de los planes de negocio basándose en el

Enfoque de Gestión por Resultados, Enfoque del Marco Lógico

utilizando la Matriz del Marco Lógico.

De lograr cumplir con los objetivos, la aplicación web beneficiará a las

empresas, instituciones o programas que gestionen planes de negocio

cofinanciados por entidades estatales, debido a que estás no son

registrados en el SNIP y no cuentan con una herramienta para los

procesos de Registro y Monitoreo, además de lograr un impacto de

modernización sobre gestión de planes de negocio en el Perú.

23

1.8.2. Importancia

El Perú se encuentra en una etapa de crecimiento económico, al mes

de mayo del 2013 se estimó un crecimiento del 9% (S/. 159 millones) en

inversiones públicas1. El estado invierte cuantiosas sumas de dinero

financiando Programas de desarrollo.

Los planes de negocio, financiados por el estado junto a entidades de

asistencia en financiamiento como lo es el Banco Mundial (BM)2, que no

son certificados por el SNIP actualmente no cuentan con una

herramienta para su control.

El presente trabajo propone el desarrollo de una herramienta

especializada en el registro y monitoreo de planes de negocio. La

herramienta estará acompañada por procesos, procedimientos

validados por el Programa ALIADOS, que tiene más de 5 años de

experiencia cofinanciando proyectos y planes de negocio, la misma que

se encargará de supervisar el correcto funcionamiento de la herramienta

y el cumplimiento de los requerimientos establecidos.

1.9. Limitaciones de la Investigación

El presente trabajo de investigación tomará en cuenta 30 planes de negocio

para realizar las pruebas de la aplicación que serán consideradas como

población y muestra.

1 Diario Gestión. En: http://gestion.pe/economia/mef-confirma-inversion-publica-aumento-9-

mayo-2069523. Lima, 2013. 2 El Banco Mundial es uno de los organismos especializados de las Naciones Unidas, que

ofrece créditos, asistencia y recursos personalizados a más de 100 países en desarrollo y en transición.



24

1.10. Tipo y Nivel de la Investigación

1.10.1. Tipo de investigación

De acuerdo al propósito de la investigación, de la problemática y del

objetivo formulado, el tipo de investigación es aplicada, debido a que se

aplicarán los conocimientos adquiridos para aplicarlos al desarrollo de

una aplicación web y cómo influye en los procesos de registro y

monitoreo de planes de negocio en el Programa ALIADOS.

“La investigación aplicada se le denomina también activa o dinámica y se encuentra íntimamente ligada a la anterior ya que depende de sus descubrimientos y aportes teóricos. (…) Es el estudio y aplicación de la investigación a problemas concretos, en circunstancias y características concretas. Esta forma de investigación se dirige a su aplicación inmediata y no al desarrollo de teorías”.1

1.10.2. Nivel de investigación

El nivel de la investigación se inicia con un estudio descriptivo debido a

que se obtiene información de los procesos de registro y monitoreo de

planes de negocio.

“Los estudios descriptivos buscan especificar las propiedades, las características y los perfiles de personas, grupos, comunidades, procesos, objetos o cualquier otro fenómeno que se someta a un análisis”2

1 Tamayo y Tamayo M. El proceso de la investigación. 4th ed. México D.F.: Limusa, S.A. de

C.V.; 2004, pp 43. 2 Hernández Sampieri R, Fernández Callado C, Baptista Lucio P. Metodología de la

investigación. 5th ed. México D.F.: McGraw-Hill, S.A. de C.V.; 2010, 80.

25

1.11. Método y Diseño de la investigación

1.11.1. Método de la investigación

El método de investigación a seguir es el científico, que es utilizado para

comprobar una hipótesis.

“Método de trabajo científico es la sucesión de pasos que debemos dar para descubrir nuevos conocimientos o, en otras palabras, para comprobar o disprobar hipótesis que implican o predican conductas de fenómenos, desconocidos hasta el momento”1

1.11.2. Diseño de la investigación

Por ser la que se acoge más a la naturaleza y el tipo de proyecto de

investigación, se ha seleccionado el diseño de investigación cuasi

experimental, donde al menos una variable es manipulada pero el grupo

de análisis ya se encuentra formado antes de realizar el experimento.

“Los diseños cuasi experimentales también manipulan deliberadamente, al menos, una variable independiente para observar su efecto y relación con una o más variables dependientes. (…)En los diseños cuasi experimentales los sujetos no se asignan al azar a los grupos ni se emparejan, sino que dichos grupos ya están formados antes del experimento (…)”2

Se tiene un objetivo principal (OP) que es comprobar la hipótesis

principal (HP), para lo cual se tiene una muestra conformada por 30

planes de negocio los cuales se usarán para el grupo de control (GC) y

el grupo experimental (GE). Se realiza una evaluación al grupo de

control obteniéndose un primer resultado (O1). Luego realiza la misma

1 Tamayo y Tamayo M. El proceso de la investigación. 4th ed. México D.F.: Limusa, S.A. de

C.V.; 2004, pp 28. 2 Hernández Sampieri R, Fernández Callado C, Baptista Lucio P. Metodología de la

investigación. 5th ed. México D.F.: McGraw-Hill, S.A. de C.V.; 2010, pp. 148.

26

evaluación al grupo experimental, al cual se le administra un estímulo

experimental: aplicación web (X); obteniendo un segundo resultado

(O2). Finalmente se compara los resultados obtenidos en ambas

evaluaciones para obtener una conclusión final (CF.)

1.12. Técnicas e Instrumentos de Recolección de Información

1.12.1. Técnicas

Observación: La observación se utiliza para administrar las

pruebas realizadas con el fin de registrar los resultados

obtenidos.

1.12.2. Instrumentos

Fichas de registro: Son utilizadas para registrar los datos

significativos.

Software de gestión de proyectos: El software de gestión de

proyectos que se utilizará es el Microsoft Project que tiene la

capacidad de ayudar a planificar, organizar y gestionar los

conjuntos de recursos, y de desarrollar estimaciones de

recursos.

Software estadístico: Para realizar los análisis estadísticos se

utilizará el IMB SPSS Statistics Versión 19, que tiene capacidad

para trabajar con grandes bases de datos y un sencillo interface

para la mayoría de los análisis

27

1.13. Cobertura de Estudio

1.13.1. Universo

Para el desarrollo del presente trabajo de investigación se ha tomado

como universo todos los planes de negocios cofinanciados por

instituciones del estado.

1.13.2. Población

La población es conformada por 30 planes de negocio del programa

ALIADOS.

1.13.3. Muestra

Para obtener la muestra se utiliza las fórmulas:

Dónde: = muestra estadística = muestra ajustada

= factor probabilístico (nivel de confianza) = evento favorable

= evento desfavorable = error máximo permitido

= población

Se trabaja con un nivel de confianza del 95% ( ) y con un error

del 3% ( ). Para obtener y se utiliza la fórmula ,

asignando tenemos que .

Reemplazando en la formula obtenemos que y . Debido a que en la muestra ajustada no existe una diferencia

significativa se trabajará con el total de la población (30 planes de

negocio), basándonos en el teorema de Subconjunto propio: “Todo

conjunto es subconjunto de sí mismo”1, de esta manera concluimos que

la muestra se encuentra comprendida por la misma población.

1 Lipschutz S. Teoría de conjuntos y temas afines México D.F.: McGraw-Hill, S.A. de C.V.;

1991, pp 03.

28

1.14. Cronograma y Presupuesto

1.14.1. Cronograma

Tabla 1 CRONOGRAMA Y TAREAS DEL DESARROLLO DE LA INVESTIGACIÓN

29

1.14.2. Presupuesto

A. Primera fase: Aprobación del plan de tesis

Actividad Costo Soles

Materiales de oficina 200.00

Equipos de informática 700.00

Materiales de impresión 100.00

Adquisición de publicaciones 500.00

Fotocopias 100.00

Pago al asesor 2000.00

Asesoría metodológica 100.00

Asesoría técnica 150.00

Revisión y corrección de la redacción y ortografía 100.00

Costo por el total de Formularios Únicos de Trámite (FUTs) 6.00

Total 3, 956.00

B. Segunda fase: Desarrollo de la tesis

Actividad Costo Total Soles

Recolección de información 1,500.00

Iniciación 2,000.00

Planificación 1,500.00

Ejecución

Modelo de contenidos

13, 000.00

Modelo de navegación

Modelo de presentación

Modelo de procesos y Diagrama de flujo de procesos

Desarrollo del modelo

Seguimiento y control 1,200.00

Cierre 800.00

Redacción del borrador, Corrección – Impresión

1,000.00

Presentación y publicación 2,000.00

Total 23,000.00

30

CAPÍTULO II

MARCO TEÓRICO

2.1. Antecedentes de la Investigación

Con relación al tema de estudio, se ha procedido a investigar publicaciones

existentes, consultado, fuentes de información primarias y secundarías. Al

respecto, no se ha encontrado ninguna tesis que aborde bajo el mismo enfoque

la relación de las dos variables involucradas; en consecuencia, se da

testimonio de la autenticidad de esta investigación.

2.1.1. Trabajos de investigación a Nivel Internacional

A. Tesis

“SISTEMA INFORMÁTICO DE MONITOREO Y CONTROL DE

LOS PROYECTOS EN LA FUNDACIÓN PARA LA

COOPERACIÓN Y DESARROLLO COMUNAL EN EL

SALVADOR”. El Salvador 2011.

B. Autores

Gloria Elizabeth Ayala Ayala, Mayela Beatriz Campos López,

Cristina Ivette Cuellar Batres, Liliana María Flores Cruz.

C. Conclusiones

1. Para el desarrollo del sistema informático fue necesario hacer

una investigación previa sobre el manejo y administración de

proyectos sociales en la fundación CORDES así como también

la información de actividades, beneficiarios, responsables y

agencias de cooperación; luego de revisar la información

recopilada se realizó el respectivo análisis y evaluación del

problema.

31

2. Por medio del análisis de la situación actual y utilizando las

técnicas de la caja negra y el diagrama causa-efecto, se han

identificado problemas identificados mediante los siguientes

factores: tiempo, procedimientos, información, planeación y

métodos.

3. Para el análisis se comenzó con la parte de evaluar los

requerimientos proporcionados por la institución y hacer su

respectivo análisis se clasificaron como informáticos,

operativos y de desarrollo del sistema informático.

4. Se elaboró el diseño del sistema de acuerdo a las necesidades

identificadas de la Fundación que fueron identificadas en el

análisis y determinación de requerimientos.

5. Se programaron los módulos del sistema informático según las

especificaciones de diseño, de forma que la aplicación

integrada pudiera funcionar correctamente.

6. Se elaboró el plan de implementación con las especificaciones

necesarias para que el sistema informático pueda ser

implantado en la Fundación CORDES, se consideraron los

elementos necesarios para la implementación del sistema, tal

como: preparación del entorno, capacitación de personal,

pruebas y puesta en marcha del sistema.

7. Se elaboró la documentación necesaria para los usuarios

finales y administrador del sistema, esta información incluye:

Manual del usuario, Manual Técnico y Manual de instalación.

32

2.1.2. Trabajos de investigación a Nivel Nacional

1. Primer trabajo de investigación

D. Tesis

“HERRAMIENTA PARA GESTIÓN DE PROYECTOS BASADA EN

XPDL PARA EL PROYECTO COMPETISOOFT

CONSTRUCCIÓN, PRUEBAS E INTEGRACIÓN”. Lima 2011.

E. Autor

Evelyn Lindsay Ocampo Moreno, Carlos Gonzáles Cajahuanca.

F. Conclusiones

1. Se construyó una herramienta bajo un entorno web, que

permite la administración de proyectos de software.

2. La herramienta desarrollada permite crear la instancia de una

metodología y asociarla a un proyecto específico.

3. Mediante la herramienta se administran proyectos específicos,

además se utilizaron archivos XML como repositorio de datos.

G. Recomendaciones

1. El sistema se encuentra basado en XPDL y XML como

archivos de datos, es entera responsabilidad del administrador

de cuidar los permisos sobre los archivos para evitar daños y

pérdida de datos.

2. El hardware del servidor web debe ser el adecuado para la

ejecución de aplicaciones Java web, esto para brindar tiempos

de respuesta mínimos al usuario.

3. Para el presente trabajo se utilizó el contener web Tomcat ya

que ofrece el rendimiento mínimo para el desarrollo de la

herramienta, sin embargo si se desea utilizar en un ambiente

de producción sugiere utilizar contenedores Web de mejores

prestaciones que Tomcat tales como Glassfish o JBoss que

también es son contenedores gratuitos.

4. Se recomienda desarrollar módulos de costos, esfuerzo, ruta

crítica, manejo del valor devengado y manejo de desviaciones.

33

2. Segundo trabajo de investigación

A. Tesis

“IMPLEMENTACIÓN DE UNA HERRAMIENTA DE GESTIÓN DE

PROYECTOS EN EL ÁREA DE SISTEMAS E INFORMÁTICA DE

UNA EMPRESA DE TELECOMUNICACIONES”. Lima 2012.

B. Autor

Jackeline Rocio Toledo Rosales.

C. Conclusiones

Al final de la implementación del presente trabajo de tesis, se

puede afirmar que la herramienta de gestión de proyectos,

seleccionada por la alta Dirección del área de Sistemas e

Informática y que fue parte de la restricción del proyecto, Project

Server versión 2007 cumplió todas las expectativas, pues hoy

permite la gestión, control y centralización de los proyectos del

área de Sistemas e Informática de una Empresa de

Telecomunicaciones, con ello se puede afirmar que fue una buena

decisión de la Alta Dirección escoger la herramienta de gestión de

proyectos, Project Server versión 2007.

D. Recomendaciones

Se recomienda para implementaciones en general de

herramientas de Tecnologías de Información tener el respaldo de

un Sponsor con alta influencia, en este proyecto el impacto en la

forma de trabajar del personal del área de Sistemas e Informática

era alto por ello se requería la participación e involucramiento de

las personas claves, lo cual se logró dada la influencia del

Sponsor y de la gestión de las comunicaciones hacia todos los

interesados para informar los cambios venideros y las ventajas

que traía consigo.

34

2.2. Marco Histórico

2.2.1. Evolución de la web

“A lo largo del tiempo, las tecnologías web han evolucionado hasta

permitir que los desarrolladores puedan crear nuevas e increíbles

experiencias web. La Web actual es el resultado de los continuos

esfuerzos de una comunidad web abierta que ayuda a definir estas

tecnologías web, tales como HTML5, CSS3 y WebGL, y garantiza que

todos los navegadores web las admitan.”1

A continuación se presenta un gráfico de la evolución web:

Gráfico 1 EVOLUCIÓN DE LA WEB

Fuente: Victor Abarca, Marketing Online. En: http://estoesmarketingonline.es/web2-0-3-0/. España, 2012.

1 Team GC. Evolution of the web. [Online].; 2012 [citado 2013 Octubre 23. Disponible en:

www.evolutionoftheweb.com.

http://estoesmarketingonline.es/web2-0-3-0/

http://estoesmarketingonline.es/web2-0-3-0/

www.evolutionoftheweb.com

35

2.2.2. Evolución de la ejecución de la Inversión Pública en el Perú

La ejecución acumulada en los últimos 12 meses (periodo abril 2012 -

marzo 2013), presenta un incremento en 17% respecto al acumulado

anterior (período abril 2011-marzo 2012), presentándose un nuevo

máximo histórico en los Gobiernos Locales y Gobiernos Regionales.

Gráfico 2 INVERSIÓN PÚBLICA ACUMULADA ÚLTIMOS 12 MESES

Fuente: Portal del Sistema Nacional de Inversión Pública. En:

http://www.snip.gob.pe/index.php/10-snip/acerca-del-snip/196-fbi-closes-in-on-

zombie-pc-gang-2., Lima, 2013.

2.3. Marco Conceptual

2.3.1. Aplicación web

Son aplicaciones que utilizan el internet o intranet como medio de

comunicación entre un cliente y un servidor, en decir una aplicación

software que se codifica en un lenguaje que lo interpretan los

navegadores web.

“Una aplicación web (web-based application) es un tipo especial de aplicación cliente/servidor, donde el cliente (el navegador, explorador o visualizador) como el servidor (servidor web) y el protocolo mediante el que se comunican (HTTP) están estandarizados y no han de ser creados por el programador de aplicaciones”1

1 Luján Mora S. Programación de aplicaciones web: historia, principios básicos y clientes web

San Vicente: Club Universitario; 2002, pp. 47.

http://www.snip.gob.pe/index.php/10-snip/acerca-del-snip/196-fbi-closes-in-on-zombie-pc-gang-2

http://www.snip.gob.pe/index.php/10-snip/acerca-del-snip/196-fbi-closes-in-on-zombie-pc-gang-2

36

2.3.2. Calidad software

Es importante destacar que la calidad de un producto software debe

ser considerada en todos sus estados de evolución a medida que

avanza el desarrollo de acuerdo al ciclo de vida seleccionado para su

construcción (especificaciones, diseño, código, etc.). No basta con

tener en cuenta la calidad del producto una vez finalizado, cuando los

problemas de mala calidad ya no tienen solución o la solución es muy

costosa.

En el caso de la calidad del software, el término es difícil de definir.

Con el fin de concretizar a qué nos referimos con calidad de un

sistema software, este se subdivide en atributos que a su vez puede

subdividirse en atributos aún más concretos especificados en el ISO

9126.

A. ISO/IEC 9126

Es un estándar internacional para la evaluación de la calidad del

software. El modelo de calidad establecido en la primera parte del

estándar, ISO 9126-1, clasifica la calidad del software en un

conjunto estructurado de características y sub-características de

la siguiente manera:

37

Tabla 2 DIVISIÓN DE LAS CARACTERÍSTICAS DE LA CALIDAD DEL SOFTWARE SEGÚN EL

ISO/IEC 9126

Características y sub-características

Descripción

Funcionalidad

Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones son aquellas que satisfacen las necesidades implícitas o explícitas.

Idoneidad Atributos del software relacionados con la presencia y aptitud de un conjunto de funciones para tareas especificadas

Exactitud Atributos del software relacionados con la disposición de resultados o efectos correctos o acordados.

Interoperabilidad Atributos del software que se relacionan con su habilidad para la interacción con sistemas especificados

Seguridad Atributos del software relacionados con su habilidad para prevenir acceso no autorizado ya sea accidental o deliberado, a programas y datos.

Cumplimiento de normas

La adhesión a las normas de aplicación relacionadas, convenciones, reglamentos de las leyes y protocolos.

Fiabilidad Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período establecido

Madurez Atributos del software que se relacionan con la frecuencia de falla por fallas en el software.

Recuperabilidad

Atributos del software que se relacionan con la capacidad para restablecer su nivel de desempeño y recuperar los datos directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado para ello.

Tolerancia a fallos

Atributos del software que se relacionan con su habilidad para mantener un nivel especificado de desempeño en casos de fallas de software o de una infracción a su interfaz especificada.

Usabilidad Un conjunto de atributos relacionados con el esfuerzo necesario para su uso, y en la valoración individual de tal uso, por un establecido o implicado conjunto de usuarios.

Aprendizaje Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones

Comprensión Atributos del software que se relacionan al esfuerzo de los usuarios para reconocer el concepto lógico y sus aplicaciones.

Operatividad Atributos del software que se relacionan con el esfuerzo de los usuarios para la operación y control del software.

Atractividad Capacidad del software de ser atractivo para el usuario

//..

38

..//

Características y sub-características

Descripción

Eficiencia Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas.

Comportamiento en el tiempo

Atributos del software que se relacionan con los tiempos de respuesta y procesamiento y en las tasas de rendimientos en desempeñar su función.

Comportamiento de recursos

La cantidad de recursos utilizados y la duración de dicho uso en el desempeño de su función

Mantenibilidad Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.

Estabilidad Atributos del software relacionados con el riesgo de efectos inesperados por modificaciones.

Facilidad de análisis

Atributos del software relacionados con el esfuerzo necesario para el diagnóstico de deficiencias o causas de fallos, o identificaciones de partes a modificar.

Facilidad de cambio

Atributos del software relacionados con el esfuerzo necesario para la modificación, corrección de falla, o cambio de ambiente.

Facilidad de pruebas

Atributos del software relacionados con el esfuerzo necesario para validar el software modificado.

Portabilidad Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.

Capacidad de instalación

Atributos del software relacionados con el esfuerzo necesario para instalar el software en un ambiente especificado.

Capacidad de reemplazamiento

Atributos del software relacionados con la oportunidad y esfuerzo de usar el software en lugar de otro software especificado en el ambiente de dicho software especificado.

Adaptabilidad

Atributos del software relacionados con la oportunidad para su adaptación a diferentes ambientes especificados sin aplicar otras acciones o medios que los proporcionados para este propósito por el software considerado.

Co-Existencia La capacidad de un producto de software para coexistir con otro software independiente en el entorno común

Fuente: Natalia Juristo y otros. Técnicas de evaluación de software versión 12.0, 2006.

39

2.3.3. Enfoque de Gestión por Resultados

También conocido como Gestión Basada en los Resultados – GBR, es

una estrategia de gestión por la que una organización asegura que sus

procesos, productos y servicios contribuyen al logro de los resultados

deseados (productos, resultado y efecto). Está basada en una

rendición de cuentas claramente definida respecto de los resultados, y

requiere la vigilancia y auto evaluación de los progresos hacia los

resultados, así como la presentación de informes sobre el

rendimiento.1

La gestión por resultados es un modelo de cultura

organizacional, directiva y de gestión. Esto significa que para

su implementación cada una de las personas de la institución

tiene que saber qué se espera lograr, en cuánto tiempo, cuál

es la relación que se debe generar con la población usuaria o

beneficiaria y cómo será medida la gestión institucional y las

personas que trabajan en dicha institución.

La gestión por resultados pone énfasis en los resultados y no

necesariamente en los procedimientos

Esto significa que cada acción que se realiza debe estar orientada por

un objetivo plenamente conocido y divulgado, el cual tiene metas que

deben ser cumplidas en un plazo determinado. Para lograr controlar

estos avances nace la necesidad de monitorear y evaluar lo que se

realiza. La Gestión para resultados toma en cuenta los distintos

elementos del ciclo de gestión como son la planificación, el

presupuesto, la gestión financiera, la gestión de proyectos y la

capacidad de realizar monitoreo y evaluación de las actividades

realizadas, de los productos entregados, de los resultados e impactos

logrados con la intervención.

1 Oficina Regional de la FAO para América Latina y el Caribe. Rol del estado y la sociedad Civil

en la generación de valor público.; 2013, pp. 10.

40

A. Monitoreo con base en resultados

El monitoreo es una actividad continua que usa la recolección

sistemática de datos sobre indicadores específicos, para guiar a

los directores, financiadores y ejecutores de estrategias de

desarrollo con información sobre las dimensiones del progreso en

la consecución de objetivos y la utilización de los fondos

destinados.1

Es necesario establecer que Seguimiento y Monitoreo son

diferentes:

Seguimiento, consiste en registrar toda información

asociada de interés con respecto al desarrollo del

proyecto, con la finalidad de generar reportes sobre el

avance, logro de los resultados y la utilización de los

recursos asignados.

Monitoreo, toma los reportes generados en el seguimiento

con la finalidad de analizarlos y generar una

retroalimentación. En base a lo generado en un

seguimiento continuo, se podrá culminar con el proceso de

monitoreo, el cual podrá incluir acciones de gabinete y ser

complementadas con acciones de campo. Esto formará

parte de un reporte de monitoreo, el cual alimentará la

gestión de conocimiento y aprendizaje.

1 Oficina Regional de la FAO para América Latina y el Caribe. Rol del estado y la sociedad Civil

en la generación de valor público.; 2013, pp. 09.

41

B. Gestión del Valor Ganado (EVM)

La Gestión del Valor Ganado (EVM en inglés) es una técnica de

dirección de proyectos que nos permite controlar el proyecto a

través del presupuesto y cronograma del mismo.

“La Gestión del Valor Ganado es una metodología que combina medidas de alcance, cronograma y recursos para evaluar el desempeño y el avance del proyecto. El EVM establece y monitorea tres dimensiones clave para cada paquete de trabajo y cada cuenta de control: Valor Planificado (PV), Valor Ganado (EV), Costo Real (AC)”1

También se monitorearán las variaciones o desviaciones con

respecto a la línea base aprobada:

a) Variación del cronograma (SV); determina en qué medida

el proyecto está adelantado o retrasado en relación con la

fecha de entrega, en un momento determinado.

b) Variación del costo (CV); es el monto del déficit o superávit

presupuestario en un momento dado, expresado como la

diferencia entre el valor ganado y el costo real.

c) Índice de desempeño del costo (CPI); Se considera la

métrica más crítica del EVM y mide la eficiencia del costo

para el trabajo completado

d) Índice de desempeño del cronograma (SPI); Refleja la

medida de la eficiencia con que el equipo del proyecto está

utilizando su tiempo.

Si bien CV y SV nos valores absolutos que nos indican si las

condiciones son favorables o no, no nos dan idea de la magnitud.

Por esta razón es necesario agregar otras fórmulas y los índices

que nos indican el valor relativo de la situación:

a) Porcentaje de variación del cronograma (SV%); este

porcentaje nos indica cuanto atraso o adelanto se lleva con

respecto al cronograma planeado.

b) Porcentaje de variación del costo (CV%); Nos indica cuan

excedidos o por debajo estamos de la línea de base del

presupuesto.

1 Project Manager Institute. Guía de los Fundamentos para la Dirección de Proyectos (Guía del

PMBOK®). 5th ed. Pensilvania: Project Manager Institute; 2013, pp 243.

42

2.3.4. Enfoque del Marco Lógico (EML)

El Enfoque del Marco Lógico (EML) es una metodología de

planificación, orientada a mejorar la calidad y claridad del diseño,

monitoreo y evaluación de programas o proyectos.

Su principal producto es la Matriz de Marco Lógico, que no es un

documento rígido y puede actualizarse en diferentes etapas de la

implementación de los programas o proyectos. La amplia acogida que

ha recibido el EML entre los planificadores y administradores en los

últimos años, se debe en gran medida a sus virtudes y ventajas sobre

otras herramientas con similares propósitos.

Su énfasis está centrado en la orientación por objetivos, la orientación

hacia resultados definidos en función de los beneficiarios, y el facilitar

la participación y la comunicación entre las partes interesadas.

Gráfico 3 MARCO LÓGICO

Fuente: Oficina Regional de la FAO para América Latina y el Caribe. “Unidad 02 El monitoreo y la evaluación de proyectos, en el marco SIMER”, 2013.

43

A. Matriz del Marco Lógico

La Matriz del Marco Lógico (MML) tiene formato 4 x 4 que permite

a los equipos de proyectos resalten gráficamente los Resultados

de un proyecto y los Componentes que se esperan generar para

los beneficiarios del proyecto. 1

Las columnas de la matriz del marco Lógico suministran la

siguiente información:

1. Un resumen narrativo de los objetivos y actividades.

2. Indicadores (Resultados específicos a alcanzar).

3. Medios de verificación.

4. Supuestos (factores externos que implican riesgos).

Las filas de la matriz presentan información acerca de los

objetivos, indicadores, medios de verificación y supuestos en

cuatro momentos diferentes en la vida del proyecto:

1. Fin al cual el proyecto contribuye de manera significativa

luego de que el proyecto ha estado en funcionamiento.

2. Propósito logrado cuando el proyecto ha sido ejecutado.

3. Componentes/Resultados completados en el transcurso

de la ejecución del proyecto.

4. Actividades requeridas para producir los

Componentes/Resultados.

1 Fondo Multilateral de Inversiones (FOMIN). [Guía práctica para la elaboración de Matriz de

Marco Lógico].; 2008,pp 03.

44

2.3.5. Programa de Apoyo a las Alianzas Rurales Productivas de la

Sierra – ALIADOS

Es parte integrante del Programa de Desarrollo Productivo Agrario

Rural – AGRO RURAL del Ministerio de Agricultura, y se enmarca

dentro de los esfuerzos que realiza el Gobierno Peruano para la

reducción de la pobreza rural.

A. Objetivos

El objetivo central es “Mejorar los activos y las condiciones

económicas de las familias campesinas en el área de intervención

del programa”.

B. Estrategia de inversión

El Programa ALIADOS, actúa bajo un enfoque de demanda en

cuanto a la atención beneficiaria y se apoyará en las fortalezas y

capacidades de las entidades públicas y privadas de promoción

del desarrollo que actúan en el ámbito del programa, promoviendo

sinergias entre estos actores a fin de lograr una mayor efectividad

en la lucha contra la pobreza rural.

ALIADOS, cofinanciará sub proyectos de negocios rurales y

comunitarios, a través de procesos transparentes de asignación

de fondos concursables a los pequeños productores y

comunidades campesinas beneficiarias.

C. Ámbito del proyecto

El ámbito de intervención del Programa ALIADOS, está

constituido por 255 Distritos, ubicados en 43 provincias que

forman parte de los departamentos de Apurímac, Ayacucho,

Huancavelica, Huánuco, Junín y Pasco

45

2.3.6. Planes de Negocio en el Programa ALIADOS

Los planes de negocio son una herramienta imprescindible para

justificar un nuevo proyecto empresarial y describir las acciones y

recursos necesarios para desplegarlo, ya se trate de una nueva

empresa, una nueva línea de negocio.1

“El Plan de Negocio es una herramienta que permite al empresario, empresa o asociación, señalar anticipadamente sus objetivos, asignar recursos, fijar metas, establecer criterios de rendimiento del negocio, tomar decisiones y, finalmente, evaluar el cumplimiento de lo propuesto inicialmente”.2

A. Registro del plan de negocio

1. Ficha de registro de plan de negocio

Es el documento en el que se registran los datos de los

planes de negocio y que contiene: La Identificación,

Justificación, Alternativa, Marco Lógico, Beneficiarios y

Documentos Físicos del plan de negocio.

2. Elaboración de un plan de negocio

Los planes de negocio son elaborados cada vez que se

propone una idea de negocio y sea registrada por el personal

correspondiente. Mientras se registren los datos, los planes

de negocio se encuentran en una etapa de “Propuesta” para

su evaluación y posterior finalización.

La cantidad de planes de negocio que se registran depende a

la eficiencia con que se realiza el proceso.

3. Finalización del registro del plan de negocio

El registro de un plan de negocio es finalizado al ser

declarado como “Viable” o lo contrario “Anulado” según la

evaluación por parte del personal pertinente.

1 Núcleo de capacitación en Políticas Públicas. Ob. cit., pp. 25.

2 AGRORURAL. Plan de Negocio Rural. ALIADOS; 2012, pp. 03.

46

B. Monitoreo del plan de negocio

El monitoreo de un plan de negocio se realiza al ser declarado

como “Viable” y se encuentre en “Ejecución”. En necesario

resaltar que la Ejecución de un plan de negocio se realiza según

la fecha de inicio declarado en el proceso de Registro de del plan

de negocio y no inmediatamente al ser declarado Viable. El

monitoreo comprueba continuamente los Componentes y

Actividades del plan de negocio a través de datos o indicadores

como el costo y tiempo.

1. Plan Anual Operativo (PAO)

Es un formato que sirve de control a la inversión del plan de

negocio. El formato PAO está dividido en 3 grupos:

a) Información; su tarea es brindar información de los

componentes (Declarados en el Registro del plan de

negocio), en el que se encuentra la sección de

Descripción de los componentes.

b) Registro o seguimiento; su objetivo es el de registrar

información referente al Saldo del año anterior (por

Actividades, declarados en el Registro del plan de

negocio) y Metas del PAO (por Actividades).

c) Monitoreo o reportes; destinados a generar reportes

de los datos declarados en el grupo de Registro del

PAO para evaluar el retraso y avance financiero del

plan de negocio. Las secciones de este grupo son:

Metas físicas y financieras (por Actividades), y

Presupuesto por componentes.

2. Elaboración del Plan Anual Operativo

El Plan Anual Operativo es elaborado al realizar el proceso de

monitoreo del plan de negocio, es decir, al encontrarse en la

etapa de Ejecución. La finalización del grupo de registro del

PAO se realiza al declarar como “Concluido”, “Liquidado” o

“Anulado” según la evaluación del plan de negocio por parte

del personal pertinente.

47

2.3.7. Guía del PMBOK® 5° edición

La Guía del PMBOK es el estándar más reconocido para manejar y

administrar proyectos que identifica un subconjunto de fundamentos

de la dirección de proyectos generalmente reconocido como buenas

prácticas.

“La Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK®) - Quinta Edición proporciona pautas para la dirección de proyectos individuales y define conceptos relacionados con la dirección de proyectos. Describe asimismo el ciclo de vida de la dirección de proyectos y los procesos relacionados, así como el ciclo de vida del proyecto.”1

2.3.8. Programación Orientada a Objetos (POO)

La POO es un paradigma de programación (o técnica de

programación) que utiliza objetos e interacciones en el diseño de un

sistema. El proceso es algo impreciso, y por esta causa han surgido

numerosos métodos que proporcionan reglas para la identificación de

clases y las relaciones que existen entre ellas.

2.3.9. Patrones de Diseño de Software

Los Patrones de Diseño son recomendaciones y sirven como modelo

para dar soluciones a problemas comunes en el desarrollo del

software.

Un patrón define una posible solución correcta para un problema de

diseño dentro de un contexto dado, describiendo las casualidades

invariantes de todas las soluciones.

Los patrones bastante usados en el desarrollo de aplicaciones Web

son MVC (Modelo-Vista-Controlador), DAO (Data Access Object) y TO

(Transfer Object).

1 Project Manager Institute. Guía de los Fundamentos para la Dirección de Proyectos (Guía del

PMBOK®). 5th ed. Pensilvania: Project Manager Institute; 2013, pp 28.

48

A. Singleton

Existen escenarios donde la aplicación sólo necesita emplear una

única instancia de una clase, y esta debe ser accedida desde

diferentes partes del sistema pero no permite la posterior

modificación de estas instancias.1

El patrón Singleton proporciona la siguiente solución:

Hacer que la clase provea una instancia de sí misma.

Permitir que otros objetos obtengan esa instancia,

mediante la llamada a un método de la clase.

Declarar el constructor como privado, para evitar la

creación de otros objetos.

B. Model-View-Controller (MVC)

Es un patrón de arquitectura de software que separa los datos y la

lógica de negocio de una aplicación de la interfaz de usuario y el

módulo encargado de gestionar los eventos y las comunicaciones.

Para ello MVC propone la construcción de tres componentes

distintos que son el modelo, la vista y el controlador, es decir, por

un lado define componentes para la representación de la

información, y por otro lado para la interacción del usuario. Este

patrón de diseño se basa en las ideas de reutilización de código y

la separación de conceptos, características que buscan facilitar la

tarea de desarrollo de aplicaciones y su posterior mantenimiento.2

Modelo; Encapsula los datos y la funcionalidad de la

aplicación (lógica que da solución al problema)

Vista; Interfaz de Usuario para el ingreso y presentación

de datos generados por el modelo.

Controlador; Es el que controla el flujo de la aplicación y

administra quién es el responsable de dar solución a un

problema, se comunica con el modelo y la vista.

1 M. G. Patterns in Java: A catalog of reusable design patterns illustrated with UML. 2nd ed.

Nueva York: John Wiley & Sons Ltd.; 2002, pp. 149. 2 Microsoft. Microsoft Developer Network. [Online].; 2003 [citado 2013 octubre 29. Disponible

en: http://msdn.microsoft.com/en-us/library/ff649643.aspx

http://msdn.microsoft.com/en-us/library/ff649643.aspx

49

C. Data Transfer Object (DTO)

Se creó a la necesidad en que los componentes de un sistema

necesitan intercambiar dato. DTO se utilizan a menudo en

conjunción con los objetos de acceso de datos para recuperar

datos de una base de datos. DTOs son objetos simples que no

debe contener la lógica empresarial que requeriría pruebas.1

Gráfico 4 PATRÓN DE DISEÑO DATA TRANSFER OBJECT

DIAGRAMA DE CLASE

Fuente: Eric Gustavo Coronel Castillo, PHP Profesional, 2010.

2.3.10. Presentación y contenido

A. HTML

Es el lenguaje predominante en el desarrollo de páginas web,

proveyendo capacidades para estructuras basadas en texto

denotando tablas, parágrafos, listas entre otras opciones,

complementando estos textos con formularios, imágenes, links y

por tanto, interacción en base a una estructura de elementos

llamados “tags” o “markups” (cuya traducción seria “márgenes”).

Estos siguen algunas reglas sintácticas simples, y son utilizadas

para describir tanto el contenido como la presentación de un

documento.

B. CSS

Se utiliza con un atributo de estilo, que se conecta directamente a

un elemento HTML, y aplica estilos sólo a ese elemento, no

pueden almacenarse en caché y no pueden ser reutilizados como

el estilo aplicado en el listado.2

1 Microsoft. Microsoft Developer Network. [Online].; 2003 [citado 2013 octubre 29. Disponible

en: http://msdn.microsoft.com/en-us/library/ms978717.aspx. 2 Wright T. Learning JavaScript A hand-On guide to the Fundamentals of Modern JavaScript

Nueva Jersey: Pearson Education, Inc.; 2012, pp. 10.

http://msdn.microsoft.com/en-us/library/ms978717.aspx

50

2.3.11. Tecnologías de scripting

A. Scripting en el cliente

1. Javascript

JavaScript es un lenguaje de programación interpretado que se

utiliza principalmente en su forma del lado del cliente (client-

side), implementado como parte de un navegador web

permitiendo mejoras en la interfaz de usuario y páginas web

dinámicas.1

2. Document Object Model

“El DOM es el resumen del documento HTML. Funciona de la misma manera que un esquema para cualquier documento, como un libro, un artículo, una lista de la compra, cualquier cosa con estructura. DOM está compuesto por elementos de nivel superior, los elementos anidados y artículos agrupados en bloques.”2

3. Ajax

“Ajax es el concepto de actualización de una parte de un documento HTML sin tener que recargar toda la página Ajax no es un acrónimo y no representa nada. Muchos piensan que es acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), pero no es así, es sólo una palabra. Ajax puede ser síncrona, y no tiene que ser XML. Puede ser XML, JSON, o incluso HTML. Se trata de los datos que desea pasar hacia y desde el servidor, en la forma que desee.”3

Las tecnologías que forman AJAX son:

XHTML y CSS

XML, XSLT y JSON

XMLHttpRequest, para el intercambio asíncrono de

información.

JavaScript y DOM, para unir todas las demás

tecnologías.

1 Tim Wright – Ob. cit., pp. 22.



51

En el siguiente esquema, la imagen de la izquierda muestra el

modelo tradicional de las aplicaciones web. La imagen de la

derecha muestra el nuevo modelo propuesto por AJAX:

Gráfico 5 COMPARACIÓN GRÁFICA DEL MODELO TRADICIONAL DE APLICACIÓN WEB Y DEL

NUEVO MODELO PROPUESTO POR AJAX

Fuente: Adaptive Path. En: http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications

B. PHP como scripting de servidor

PHP (acrónimo recursivo de PHP: Hypertext Preprocessor) es un

lenguaje de código abierto muy popular especialmente adecuado

para el desarrollo web y que puede ser incrustado en HTML. PHP

es un lenguaje de secuencias de comandos del servidor, y es una

herramienta de gran alcance para hacer páginas web dinámicas e

interactivas rápidamente.1

Lo que distingue a PHP de algo como Javascript del lado del

cliente es que el código es ejecutado en el servidor, generando

HTML y enviándolo al cliente. El cliente recibirá el resultado de

ejecutar el script, el servidor web puede ser incluso configurado

para que procese todos los ficheros HTML con PHP.

1 PHP.net. Centro principal de recursos pata desarrolladores PHP. [Online].; 2013 [citado 2013

septiembre 25. Disponible en: http://us1.php.net/manual/es/intro-whatis.php.

http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications

http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications

http://us1.php.net/manual/es/intro-whatis.php

52

PHP está enfocado principalmente a la programación de scripts

del lado del servidor, por lo que se puede hacer cualquier cosa

que pueda hacer otro programa CGI, como recopilar datos de

formularios, generar páginas con contenidos dinámicos, o enviar y

recibir cookies.

2.3.12. Librerías y plugins

En el desarrollo de aplicaciones web, y debido a la tendencia actual,

es necesario generar contenidos e interfaces cada vez más dinámicas

para el usuario, es decir las “Rich Internet Applications (RIA, en

español Aplicaciones de Internet Enriquecidas)”.1

1. Jquery; es una librería de JavaScript rápida, pequeña y rica en

funciones. Hace las cosas como documento HTML recorrido y

la manipulación, el control de eventos, animación y Ajax.

2. Jquery UI; es un conjunto de características de las

interacciones de interfaz de usuario, efectos, widgets y temas

construidos en sobre la base de la librería jQuery.

3. JqGrid; es un Plugin JavaScript habilitado para AJAX que

proporciona soluciones para representar y manipular datos

tabulares en la web, que se puede integrar con cualquier

tecnología de servidor, incluyendo PHP, ASP, Java Servlets,

JSP, ColdFusion y Perl.

2.3.13. Sistema de gestión de base de datos

Un Sistema de Gestión de Bases de Datos - SGBD (En inglés Data

Base Management System - DBMS) consiste en una colección de

datos interrelacionados y un conjunto de programas para acceder a los

mismos.

Un SGBD permite el almacenamiento, manipulación y consulta de

datos pertenecientes a una base de datos organizada en uno o varios

ficheros. En el modelo más extendido (base de datos relacional) la

base de datos consiste en un conjunto de tablas entre las que se

establecen relaciones.

1 Berners-Lee T. World Wide Web Consortium. [Online].; 2013 [citado 2013 septiembre 28.

Disponible en: http://www.w3.org/2006/rwc/Activity.html.

http://www.w3.org/2006/rwc/Activity.html

53

A. Base de datos relacionales

Es el modelo más utilizado hoy en día. Una base de datos

relacional es básicamente un conjunto de tablas, similares a las

tablas de una hoja de cálculo, formadas por filas (registros) y

columnas (campos).

Las relaciones que se establecen entre los diferentes elementos

de dos tablas en una base de datos relacional pueden ser de tres

tipos distintos:

Relaciones uno a uno, se establecen entre una entidad

de una tabla y otra entidad de otra tabla.

Relaciones uno a varios, se establecen entre varias

entidades de una tabla y una entidad de otra tabla.

Relaciones varios a varios, se establecen entre varias

entidades de cada una de las tablas. Un ejemplo sería una

tabla con retenes de bomberos y otra con espacios

naturales a los que cada uno debe acudir en caso de

incendio.

B. SQL

El lenguaje de consultas SQL (Lenguaje Estructurado de

Consultas) se ha convertido, debido a su eficiencia, en un

estándar para las bases de datos relacionales. A pesar de su

estandarización se han desarrollado, sobre una base común,

diversas versiones ampliadas como las de Oracle o la de

Microsoft SQL server.

En una base de datos relacional, los resultados de la consulta van

a ser datos individuales, tuplas o tablas generados a partir de

consultas en las que se establecen una serie de condiciones

basadas en valores numéricos.

54

C. Microsoft SQL Server

Microsoft® SQL Server™ es un sistema de administración y

análisis de bases de datos relacionales de Microsoft para

soluciones de comercio electrónico, línea de negocio y

almacenamiento de datos. Sus lenguajes para consultas son T-

SQL y ANSI SQL.

SQL Server 2008

SQL Server 2008 está pensado principalmente como un

Sistema de Base de Datos Relacional (RDBMS) brindando

a los usuarios finales capacidades innovadoras de

información, análisis de datos de gran alcance, y la minería

de datos. También cuenta con funciones que soportan

aplicaciones asíncronas de datos, notificación de eventos

por datos, y Filestream, que es un nuevo mecanismo de

almacenamiento de datos para los archivos del sistema, en

lugar de en la base de datos en sí.1

2.3.14. Desarrollo de proyectos Web

En el libro “Web Engineering: The Discipline of Systematic

Development of Web Applications”2 se muestra como diferentes tipos

de metodologías incluyendo las tradicionales pueden ser aplicadas al

caso especial del desarrollo Web. Las metodologías y sus modelos

como diagramas de casos de uso, diagramas de clases e

interacciones y otros pueden ser aplicados, aunque existe también una

fuerte tendencia a la aplicación de modelos ágiles debido a sus

características.

La aplicación de metodologías agiles se convierte en una necesidad

en los proyectos Web, ya que permiten aprovechar los patrones de

diseño y generar ventajas competitivas debido a la velocidad de

reacción y adaptación a las necesidades de los usuarios a la hora de

crear un proyecto.

1 Leiter C, Dan W, Michael C, Albert B. Beginning Microsoft SQL Server 2008 Administration

Indiana: Wiley Publishing Inc.; 2009, pp. 03. Rossi G, Pastor O, Schwabe D, Olsina L. Web Engineering: Modeling and Implementing Web Applications Londres: Springer; 2008, 474 pp.

55

A. Ingeniería web

La Ingeniería convencional no abarca todas las nuevas

características de la tecnología web que crece cada día más, a

partir de esta necesidad se desarrolla la Ingeniería Web.

“Las aplicaciones web modernas son, en toda regla, sistemas de software complejos. Por lo tanto, el desarrollo de aplicaciones web requiere un enfoque de ingeniería metodológicamente sólido. Basado en Ingeniería de Software, Ingeniería Web comprende el uso de métodos sistemáticos y cuantificables para cumplir la especificación, implementación, operación y mantenimiento de aplicaciones Web de calidad.”1

B. UML-based Web Engineering (UWE)

UML-based Web Engineering (UWE – en español Ingeniería Web

basado en UML) surge con la idea de encontrar una forma

estandarizada de construir modelos de análisis y diseño de

sistemas Web en base a los métodos ya existentes, con el

objetivo de utilizar un lenguaje común o al menos definir mapeos

basados en meta-modelos entre los lenguajes existentes. El

Unified Modeling Languague (UML) es elegido por su amplio uso

como lenguaje base para modelos orientados a objetos. En base

a dichos mecanismos se genera UWE principalmente como una

expansión de UML, aunque también es compatible con otras

metodologías y lenguajes.2

El desarrollo de UWE es continuado hoy en día en búsqueda de

asimilar nuevas capacidades de las aplicaciones Web, como ser

transacciones, personalizaciones y aplicaciones asincrónicas.

Sucede que el desarrollo de sistemas Web está en constante

cambio.

UWE está dirigido por la separación de modelos de distintos

asuntos describiendo las diferentes etapas de ingeniería de

requerimientos, análisis, diseño e implementación del proceso de

1 Kappel G, Proll B, Reich S, Retschitzegger W. Web Engineering – The Disipline of Systematic

Development of Web Applications Nueva York: John Wiley & Sons Ltd.; 2006, pp 22. 2 Se puede encontrar más información en: http://uwe.pst.ifi.lmu.de/index.html.

http://uwe.pst.ifi.lmu.de/index.html

56

desarrollo con el objetivo de obtener diferentes vistas de la misma

aplicación Web correspondientes a dichas etapas o asuntos. De

esta manera UWE usa el enfoque del desarrollo dirigido por

modelos (MDD) generando los siguientes modelos:

Modelo de Contenidos

Modelo de Presentación

Modelo de Navegación

Modelo de estructura de procesos y diagramas de flujo de

procesos

La estructura de navegación es modelada de manera separada

del contenido (aunque claramente se deriva de este último) y

representa los diversos caminos de navegación del sistema. El

modelo de presentación apunta a mostrar la representación y los

aspectos de comunicación usuario-maquina mediante un esbozo

de las interfaces.

A su vez se utilizan frecuentemente diagramas de interacción o de

estado para representar aspectos de comportamiento del sistema

Web. Podemos decir que se realiza una separación considerando

etapas de desarrollo, vistas del sistema y aspectos como ser la

estructura y el comportamiento. Este tipo de separación provee

ventajas a la hora de realizar mantenimientos y reingenierías de

sistemas web, y también en la generación de sistemas Web para

distintos contextos y plataformas.

Podemos encontrar una ampliación a esta introducción en el

capítulo 7 del libro “Web Engineering: Modelling and Implementing

Web Applications”1

1 Rossi G, Pastor O, Schwabe D, Olsina L. Web Engineering: Modeling and Implementing Web

Applications Londres: Springer; 2008, pp. 157.

57

2.3.15. Dreamweaver

Adobe Dreamweaver es una herramienta de diseño web y desarrollo

de aplicaciones que proporciona un editor visual y un editor de código

con características estándar como el resaltado de sintaxis, completado

de código y la compresión de código, así como características más

sofisticadas, como la comprobación de sintaxis en tiempo real y la

introspección de código para generar sugerencias de código.

2.3.16. MagicDraw UML

MagicDraw UML es una herramienta CASE desarrollada por No

Magic. La herramienta es compatible con el estándar UML 2.3,

desarrollo de código para diversos lenguajes de programación (Java,

C++ y C#, entre otros) así como para modelar datos. La herramienta

cuenta con capacidad para trabajar en equipo y es compatible con

mayoría de IDEs.

2.3.17. Prueba T de Student para muestras relacionadas

La prueba busca comprobar estadísticamente una diferencia

significativa entre las medias de 2 muestras relacionadas.

Para utilizar la prueba T de Student es necesario comprobar:

1. La Variable dependiente debe ser cuantitativa

2. Las muestras deben seguir una distribución normal

3. Independencia de las observaciones

58

2.3.18. Prueba de Wilcoxon

Es la prueba no paramétrica para comparar la media de dos muestras

relacionadas y determinar si existen diferencias entre ellas. Se utiliza

como alternativa a la prueba T de Student cuando no se puede

comprobar si las muestras cuentan con una distribución normal.1

A. Planteamiento

Se dispone de n pares de observaciones, denominadas Xi, Yi.

El objetivo del test es comprobar si puede dictaminarse que los

valores Xi e Yi son o no iguales.

Para eso se calcula la diferencia de las muestras Xi – Yi, se las

ordena y se les asigna un rango, luego se suman los valores

positivos y negativos.

El valor estadístico T es la suma de rangos (positivo o negativo)

con menor valor, el cual se consulta en la tabla de distribución de

Wilcoxon para comprobar si se rechaza o no la H0.

B. Hipótesis estadísticas de Wilcoxon

H0: ∑ ∑ La suma de rangos positivos y negativos

son iguales (no hay cambios)

Hi: ∑ ∑ La suma de rangos no son iguales (Hay

cambios)

∑ ∑ La suma de rangos negativos es mayor a

la suma de rangos positivos

∑ ∑ La suma de rangos negativos es menor a

la suma de rangos positivos

1 Wilcoxon F. http://sci2s.ugr.es/. [Online].; 2013 [citado el 02 de Noviembre 2013]. Disponible

en: http://sci2s.ugr.es/keel/pdf/algorithm/articulo/wilcoxon1945.pdf

http://sci2s.ugr.es/keel/pdf/algorithm/articulo/wilcoxon1945.pdf

59

CAPÍTULO III

CONSTRUCCIÓN DE LA HERRAMIENTA

3.1. Generalidades

En base a lo desarrollado en el marco teórico hemos logrado comprender los

elementos que componen los conceptos necesarios para la construcción del

software. Buscando alcanzar el objetivo del trabajo generando un impacto en el

contexto de “Monitoreo y evaluación de planes de negocio” la gestión del

trabajo se realizará utilizando la guía PMBOK Quinta Edición, para la

construcción del software se utilizará la metodología UWE (Ingeniería Web

basado en UML), con el uso de la herramienta MagicDraw 17 utilizando el

plugin MagicUWE 1.3.8.1

El software a desarrollar pretende realizar operaciones en el cual intervienen

los Procesos de Monitoreo y Evaluación de planes de negocio del Programa

ALIADOS, el software contará con las siguientes características para cumplir

los objetivos propuestos:

Plataforma WEB.

Microsoft SQL Server 2008, como motor de base de datos.

PHP como Lenguaje de servidor.

Singleton, MVC, Data Transfer Object, como patrones de diseño web.

Jquery, JqGrid, como Frameworks.

La estructura de la tesis no tiene relación con los grupos de procesos y las

áreas de conocimiento de la Guía PMBOK, por lo que se ha generado una

tabla de relación entre los entregables de la Guía PMBOK y las secciones de la

tesis, esto para comprender como se ha realizado la gestión del presente

trabajo:

1 Se puede obtener más información en: http://uwe.pst.ifi.lmu.de/toolMagicUWE.html

http://uwe.pst.ifi.lmu.de/toolMagicUWE.html

60

Tabla 3 RELACIÓN DE LOS ENTREGABLES DEL PMBOK CON LAS SECCIONES DE LA TESIS

Guía PMBOK Quinta Edición Tesis

Grupos de procesos

Áreas de conocimientos

Entregables Sección principal Sub-sección

Iniciación

Integración Acta de constitución del proyecto 3.1. Generalidades 3.1.1. Acta de constitución del proyecto

Interesados Identificación de Interesados 3.3. Análisis del sistema 3.3.1.A. Definición de los actores del negocio

Planificación

Alcance EDT 3.3. Análisis del sistema 3.3.B. Diccionario EDT

Enunciado del alcance 3.3. Análisis del sistema 3.3.A. Enunciado del Alcance

Tiempo Cronograma

1.14. Cronograma y presupuesto

1.14.1. Cronograma

Estimación de recursos y duraciones Anexos Anexo 18

Costos Costeo del proyecto 3.2. Estudio de factibilidad 3.2.3.B. Costo del proyecto

Calidad Matriz de Asignación y responsabilidades de la calidad

3.3. Análisis del sistema 3.3.C. Matriz de Asignación y responsabilidades de la calidad

Recursos humanos

Organigrama del proyecto 3.1. Generalidades 3.1.3. Organización del proyecto

Matriz de Asignación y responsabilidades del personal

Anexos Anexo 19

Comunicaciones Matriz de comunicaciones 3.1. Generalidades 3.1.4. Comunicación del proyecto

Riesgos

Identificación de riesgos cualitativos 3.3. Análisis del sistema 3.3.D. Riesgos cualitativos

Análisis cuantitativo de riesgos Anexos Anexo 20

Plan de respuesta a riesgos Anexos Anexo 21

Adquisiciones Planificación de compras y adquisiciones 3.2. Estudio de factibilidad 3.2.1. Factibilidad técnica

Planificación de contrataciones 3.2. Estudio de factibilidad 3.2.1. Factibilidad técnica

//..

61

..//

Guía PMBOK Quinta Edición Tesis

Grupos de procesos

Áreas de conocimientos

Entregables Sección principal Sub-sección

Planificación Interesados

Clasificación de interesados 3.3. Análisis del sistema 3.3.1.A. Definición de los actores del negocio

Registro de interesados involucrados en el proyecto

Anexos Anexo 29

Estrategia de gestión de interesados 3.3. Análisis del sistema 3.3.1.A. Necesidades genéricas de los actores del negocio

Ejecución Integración Actas de reuniones de coordinación del proyecto

Anexos

Anexo 22 Anexo 23 Anexo 24 Anexo 25

Control y monitoreo

Integración Solicitudes de cambios aprobadas 3.5. Cierre del proyecto Anexos

3.5.1. Solitud de cambio Nº 001 Anexo 28

Calidad Inspección de calidad 3.5. Cierre del proyecto Anexos

3.5.3. Inspección de calidad Nº 002 Anexo 26 Anexo 27

Riesgos Informe de monitoreo de riesgos 3.5. Cierre del proyecto 3.5.2. Informe de monitoreo de riesgos

Cierre Integración Acta de aceptación del proyecto 3.5. Cierre del proyecto

3.5.4. Acta de aceptación del proyecto

Lecciones aprendidas 3.5. Cierre del proyecto 3.5.5. Lecciones aprendidas

62

3.1.1. Acta de Constitución del Proyecto

Para autorizar formalmente la existencia, inicio del proyecto y conferir al

Director del Proyecto la autoridad, para asignar los recursos de la

organización, a las actividades del proyecto.

Nombre del proyecto

Software de monitoreo y evaluación de planes de negocio para el Programa ALIADOS del Ministerio de Agricultura

Descripción del proyecto

El proyecto consiste en desarrollar un software con el fin de evaluar las desviaciones del cronograma, situación, avance financiero y rentabilidad, mejorando de esta manera el monitoreo y evaluación de planes de negocio del Programa ALIADOS. Para el desarrollo del proyecto se deberá de seguir las actividades incluidas en las

etapas definidas en la Gestión de Proyectos, como son:

- Inicio

- Ejecución

- Implementación

- Seguimiento y Control

- Cierre

El desarrollo estará a cargo de un equipo designado por el jefe de proyecto. El proyecto será realizado desde el 21 de agosto hasta el 30 de noviembre. Dándose la construcción del software a principios de septiembre hasta afines de octubre. La gestión y desarrollo del proyecto se realizará en las instalaciones de la oficina central del Programa ALIADOS.

Definición del producto del proyecto

Software El software se desarrollará en plataforma WEB. Se construirá usando las siguientes métodos, metodologías y herramientas:

Metodología UML-based Web Engineering (UWE)

Motor de Base de Datos SQL SERVER

Lenguaje de programación PHP

Patrón de diseño Modelo-Controlador-Vista (MVC)

Framework Jquery Módulos Contará con los siguientes módulos:

Módulo de software de Banco de Planes de negocio o Interface de registro de datos generales de proyecto según esquema

definido por el Programa (Tomando como referencia el Banco de Proyectos del SNIP)

o Interface de registro de marco lógico e indicadores físicos y financieros a nivel de componentes y actividades

o Interface de registro de periodo de ejecución del proyecto o Reportes definidos por el Programa

Módulo de software de Ejecución de Planes de negocio Informes La oficina de Coordinación de Monitoreo, Evaluación e Informática del Programa ALIADOS, que cumple la función de Proyect Management Office (PMO, en español Oficina de gestión de proyectos), solicita un informe por cada Módulo terminado.

//..

63

..//

Alineamientos del proyecto

Programa ALIADOS Proyecto

Objetivo Principal: Mejorar los activos y las condiciones económicas de las familias campesinas en el área de intervención del programa. Estrategia de inversión: ALIADOS promueve el desarrollo de iniciativas productivas mediante la generación y consolidación de nuevos negocios rurales, a través de la elaboración de planes de negocios, y la creación de un fondo concursable para negocios rurales.

Objetivo del proyecto: Desarrollar el software de monitoreo y evaluación de planes de negocio para el Programa de Apoyo a las Alianzas Rurales Productivas de la Sierra - Aliados del Ministerio de Agricultura, gestionando el proyecto con la Guía PMBOK quinta edición, y los alcances de los entregables usando la metodología UML-based Web Engineering (UWE, en español Ingeniería Web Basado en UML), Motor de Base de Datos SQL SERVER 2008, lenguaje de programación PHP, patrón de diseño Modelo-Controlador-Vista (MVC), framework Jquery, con el fin de evaluar el retraso, situación, avance financiero y rentabilidad de la ejecución de planes de negocio.

Objetivos del proyecto

1. Alcance

Cumplir con la elaboración de los siguientes entregables: Gestión del proyecto, perfil del producto, prototipos, producto terminado, código fuente, Base de datos, diccionario de base de datos e informes de la evaluación del producto.

Aprobación de todos los entregables por parte del PMO.

2. Tiempo Asegurar que el proyecto se ejecute en el tiempo estimado.

Cumplir con el cronograma establecido.

3. Costo

Asegurar que las tareas se lleven a cabo dentro de los rangos económicos impuestos – presupuesto (S/. 23, 000.00).

No exceder el presupuesto del proyecto

4. Calidad

Aplicar la metodología UWE en el desarrollo del producto para asegurar que el proyecto satisfaga los requisitos establecidos en los Términos de Referencia (TDR) realizado por el PMO.

Realizar un correcto seguimiento y control.

Finalidad del proyecto

Mejorar y facilitar el monitoreo y evaluación de planes de negocio para el Programa ALIADOS a través del desarrollo de un software en entorno web.

Factores críticos del proyecto

Principales amenazas del proyecto

Los informes no son aprobados por el PMO.

Retraso en el desarrollo del producto; inconvenientes por parte del programador.

Pérdida de información por fallas de las herramientas software y hardware.

Los costos no deben ser superiores al presupuesto establecido, caso contrario se corre el riesgo de cancelar el proyecto.

El producto no llega a cumplir los requisitos esperados por el cliente.

//.

64

..//

Principales oportunidades del proyecto

El desarrollo del producto ayudará a otras organizaciones mejorar el monitoreo y evaluación de los planes de negocio.

Autoridad del proyecto

Autorización Director Ejecutivo Gerente del Proyecto Marbin Rusbelt Ramírez Chávez Oficina de seguimiento y control - PMO Oficina de Coordinación de Monitoreo, Evaluación e Informática

3.1.2. Plan de Dirección del Proyecto

Se describe el cómo los planes subsidiarios de la gestión de los

diferentes grupos de procesos en el marco de la Guía PMBOK Quinta

Edición.

Gestión alcance

El alcance del producto son definidos en los Términos de Referencia (TDR), documento

desarrollado por el Programa ALIADOS.

Para describir los requerimientos y determinar lo que se incluye o no en el proyecto se

desarrollarán los siguientes entregables para la gestión del alcance:

Enunciado del alcance: se describe los criterios, entregables y restricciones del

proyecto.

EDT: describe de manera estructurada lo que se necesita entregar en el proyecto.

Diccionario EDT; describe de manera conceptual cada elemento del EDT.

El Programa ALIADOS es el encargado de evaluar los entregables para su aprobación.

Técnicas y herramientas

Juicio de expertos; es una técnica de valoración de la opinión de expertos en el tema,

considerada en el PMBOK Quinta Edición.

WBS Chart Pro; es una herramienta para la construcción del ETD.

Gestión del tiempo

El presente proyecto se considera como pequeño, por tal motivo la definición de actividades, estimación de recursos de las actividades, estimación de la duración de las actividades, secuenciación de actividades y desarrollar el cronograma se realizan a través de un solo proceso. Para lo cual se realizará los siguientes entregables:

Estimación de recursos y duraciones

Cronograma del proyecto

El Programa ALIADOS es el encargado de evaluar el tiempo de construcción del producto así

como las actividades y sus duraciones.




MS Project; es la herramienta para desarrollar el cronograma.

//..

65

..//

Gestión de costos

El costo del desarrollo del producto es establecido, solventado y controlado por el Programa

ALIADOS, los costos referentes a la redacción, revisión y aprobación de la tesis son

solventadas por el tesista.

El presente proyecto se considera como pequeño, por tal motivo la estimación de costos y

determinación de presupuesto se realizarán a través de un solo proceso.

Para lo cual se desarrollarán los siguientes entregables:

Matriz de los costos del proyecto; en el que se detalla los costos de los mismos así como la utilización de los recursos consumibles y no consumibles.




Gestión de calidad

La calidad se gestionará utilizando la metodología de Ingeniería Web basada en UML (UWE)

usado para el desarrollo de software en plataforma web. Se utilizará el PMBOK Quinta Edición

para la gestión del proyecto, asegurando de esta manera la calidad del producto final.

Matriz de Asignación y Responsabilidades (RAM); para tener un mayor control de la calidad del proyecto.

Desarrollo de prototipos; los cuales serán sometidos a una evaluación utilizando el Juicio de expertos realizado por el Programa ALIADOS.




UML-based Web Engineering (UWE); Metodología que se utilizará para la construcción

del software.

Gestión de recursos humanos

El personal necesario para la realización del proyecto es determinado por la guía PMBOK

Quinta Edición y la metodología UWE.

Debido a la magnitud del proyecto solo es necesario la participación del tesista que realizará

los diferentes roles y funciones necesarias además de contar con la participación del personal

del Programa ALIADOS los cuales cumplen las funciones de evaluadores.

Se generará los siguientes entregables para la gestión de los recursos humanos:

Organigrama del proyecto; describe de manera estructurada los roles del personal.

Matriz de Asignación y Responsabilidades (RAM); la matriz es la participación del

personal con las actividades de desarrollo del proyecto.




El rol que desempeñará el tesista cambia según la actividad que se desarrolla, así como la toda responsabilidad decae sobre él.

//..

66

..//

Gestión de comunicación

Se elaborará una matriz para controlar las reuniones, estas reuniones son necesarias para

reportar el avance de los entregables así como la coordinación de cambios.

Los entregables de esta gestión son las fichas de reuniones el cual contiene la descripción y

algunos detalles de la reunión.




Gestión de riesgos

Los riesgos que amenazan al proyecto son detallados desarrollando los siguientes entregables:

Análisis cualitativos de riesgos; este análisis es necesario para determinar la

prioridad de cada riesgo con respecto a los objetivos del proyecto.

Análisis cuantitativos de riesgos; análisis realizado numéricamente para determinar

el nivel de cada riesgo con respecto a los objetivos del proyecto

Plan de respuesta a riesgos; describe las respuestas, acciones de contingencia y

como se va tratar los riesgos latentes.


Juicio de expertos; es una técnica de valoración de la opinión de expertos en el tema, considerada en el PMBOK Quinta Edición.

Técnicas de recolección de datos como las entrevistas y reuniones

Gestión de adquisiciones

Realizando un análisis de requisitos se determinará los recursos necesarios para el desarrollo

del proyecto así como el costo de los mismos:

Registro de requerimientos; es el registro de todos los recursos necesarios que

intervienen para completar el proyecto.

Registro de adquisiciones; es el registro de los recursos con los que no se cuenta y

que su adquisición es necesaria.


Juicio de expertos; es una técnica de valoración de la opinión de expertos en el tema, considerada en el PMBOK Quinta Edición.

El control de las adquisiciones así como la entrega de los recursos disponibles para llevar a

cabo el proyecto lo realiza el Programa ALIADOS.

Gestión de Interesados

La gestión de los Interesados es una característica implementada en la guía PMBOK Quinta

Edición, para lo cual se desarrollará los siguientes entregables:

Identificación de los Interesados

Clasificación de Interesados; se desarrolló 2 matrices: Influencia vs Poder,

Interés vs Poder.

Registro de los Interesados involucrados en el proyecto

Estrategia de gestión de Interesados


Juicio de expertos; es una técnica de valoración de la opinión de expertos en el

tema, considerada en el PMBOK Quinta Edición.

Se utilizará entrevistas para determinar los Interesados del proyecto, así como el

desarrollo de las matrices y la estrategia de gestión de los Interesados.

67

3.1.3. Organización del proyecto

A través del Plan de Gestión de Recursos Humanos se da a conocer la

estructura con que se lleva a cabo el presente proyecto:

Gráfico 6 ORGANIGRAMA DEL PROYECTO

3.1.4. Comunicación del proyecto

La gestión de comunicación es la encargada de manejar las reuniones

del personal del proyecto, esto a fin de mantener al equipo actualizado y

solicitar la aprobación de los entregables generados en cada gestión

entre otros:

68

Tabla 4 MATRIZ DE COMUNICACIONES DEL PROYECTO

Información Contenido Formato Nivel de Detalle

Responsable de

Comunicar Grupo Receptor

Metodología o Tecnología

Frecuencia de Comunicación

Código de Elemento EDT

Iniciación del proyecto y

planeación del Proyecto

Aceptación del Proyecto

Aceptación del

Proyecto Medio

Jefe del Proyecto

Patrocinador, Gerentes

Funcionales

Documento Digital

Una Sola Vez 1.1. Iniciación

Datos e información sobre el Proyecto.

Acta de constitución

del proyecto

Medio Jefe del Proyecto

Patrocinador, Equipo de Proyecto

Documento Digital

Una sola Vez 1.1.1 Acta de

constitución del proyecto

Planificación detallada del Proyecto: Tiempo, Costo, Calidad, Riesgos.

Planeación del

Proyecto Muy Alto

Jefe del Proyecto


Documento Digital

Una sola Vez 1.2 Planeación

Seguimiento y Control del Proyecto

Inspección de calidad Solicitudes de cambios aprobados Informe de monitoreo de riesgos

Reunión Alto Jefe del Proyecto


Reunión Mensual

1.4. Seguimiento y

Control del Proyecto

Cierre del Proyecto

Lecciones Aprendidas, Actualización de Documentos, Entrega del producto final, Cierre administrativo del Proyecto.

Cierre Del Proyecto

Medio Jefe del Proyecto


Documento Digital

Una Sola Vez 1.5. Cierre del

Proyecto

Acta de Cierre del Proyecto

Acta de Cierre del Proyecto

Alto Jefe del Proyecto

Patrocinador Documento

Digital Una Sola Vez

1.5.2. Acta de cierre del proyecto

69

3.2. Estudio de factibilidad

3.2.1. Factibilidad Técnica

El Programa ALIADOS cuenta con todo lo necesario para el desarrollo

del software los cuales son brindados al investigador.

A continuación se detallan los requerimientos de necesario para el

desarrollo del Software, las tablas son extraídas del Plan de Gestión de

Adquisiciones de la Guía PMBOK:

Tabla 5 REQUERIMIENTOS DEL PERSONAL PARA EL DESARROLLO DEL PROYECTO

Cantidad Descripción

1 Jefe de Proyecto

1 Analista

1 Diseñador

1 Programador

1 Documentador

Tabla 6

REQUERIMIENTOS DE SOFTWARE PARA EL DESARROLLO DEL PROYECTO

Licencias Software Descripción

1 Microsoft Project Para llevar el control del proyecto

1 MagicDraw 17 Herramienta de modelado

Libre MagicUML Plugin para facilitar el uso de la metodología UWE en el MagicDraw.

1 Macromedia

Dreamweaver CS6 Herramienta que brinda entorno un entorno visual para la construcción y codificación del software.

Libre PHP Lenguaje de Programación

1 Microsoft SQL Server

2008 Para la gestión de la Base de datos

2 Windows 7 Para las computadoras utilizadas en el desarrollo del software

1 Windows Server

2003 Sistema Operativo en el cual correrá la aplicación

Integrada al Windows 7

Internet Information Services 7 (ISS)

Servidor web y un conjunto de servicios de Microsoft Windows

1 Microsoft Office Para poder realizar la documentación

1 Nod32 4 Antivirus para proteger los archivos de las PC’s

70

Tabla 7 REQUERIMIENTOS DE HARDWARE PARA EL DESARROLLO DEL PROYECTO

Cantidad Hardware Descripción

2 Servidores

Donde se alojará la Base de Datos: HP Proliant ML115 G5, 1 GB de Memoria RAM, 500 GB de Disco Duro - SATA.

Donde se alojará el software: HP Proliant ML115 G5, 1 GB de Memoria RAM, 500 GB de Disco Duro - SATA.

1 Router Para conectarse al internet

- Cableado de red Para conectar el servidor con los otras PC’s

2 Computadoras Para el desarrollo del software: Intel® Core™ i3-2100 CPU @ 3.10GHz, 2 GB de Memoria RAM, 500 GB de Disco Duro - SATA

1 USB Para el respaldo de los archivos: USB 16 GB HP

1 Impresora Para los reportes, informes y documentación necesarias

- Servicio de internet Para el uso de la aplicación

3.2.2. Factibilidad Operativa

El proyecto es producto de un análisis desde la Oficina de

Administración y del Director Ejecutivo del Programa ALIADOS, que a

través de la Oficina de Coordinación de Monitoreo, Evaluación e

Informática se ha decidido modernizar los procesos de Registro y

Monitoreo de los planes de negocio para ingresar a la segunda etapa

del programa ALIADOS. Esta decisión busca el beneficio del personal

encargado del registro, monitoreo, evaluación de planes de negocio y

los tomadores de decisiones los cuales deberán hacer uso de la nueva

herramienta para mejorar los procesos de Monitoreo y evaluación de

planes de negocio a través de mejor manejo del tiempo y ahorro de

materiales de escritorio. Durante la primera etapa el programa ALIADOS

contaba con el uso de una herramienta informática para los procesos de

registro, monitoreo y evaluación de proyectos, por tal motivo el personal

del programa no necesita de mayor capacitación en el uso de la nueva

herramienta.

3.2.3. Factibilidad Económica

A. Costo por hardware

El Programa ALIADOS cuenta con el hardware necesario para la

construcción del software.

71

B. Costo del proyecto

A continuación se muestra los costos del proyecto extraídos del entregable del Plan de Gestión de Costos de la Guía PMBOK:

Tabla 8 COSTEO DEL PROYECTO

Entregable Actividad

Tipo de Recurso: Personal Tipo de Recurso:

Consumibles Tipo de Recurso: No Consumibles

Nombre del recurso

Unid Costo unit.

Costo Total

Nombre del

recurso

Costo unitario

Costo Total

Nombre del recurso

Unid Costo

unitario Costo Total

Acta de constitución del proyecto

Análisis Situacional Jefe del Proyecto

1 200 200

Determinar Equipo de Trabajo

Jefe del Proyecto

1 200 200

Identificación de los interesados

Identificación de interesados

Jefe del proyecto Analista Coordinador del proyecto

1 1 1

100 100

200

Plan de Gestión de Alcance

Realizar Enunciado del alcance

Jefe del Proyecto

1 200 200

Revisar Enunciado del alcance

Jefe del Proyecto

1 200 200

EDT

Elaborar EDT Jefe del Proyecto Analista

1 1

100 100

200

Elaborar Diccionario EDT

Jefe del Proyecto Analista

1 1

100 100

200

Etapas de Desarrollo

Cronograma Jefe del Proyecto Analista

1 1

150 150

300

Estimar actividades recursos y duraciones

Jefe del Proyecto Analista

1 1

150 150

300

//..

72

..//




Nombre del recurso

Unid Costo unit.

Costo Total

Nombre del

recurso

Costo unitario

Costo Total

Nombre del recurso

Unid Costo


Estimación de Costos

Costeo del Proyecto

Jefe del Proyecto Analista Coordinador del proyecto

1 1 1

150 150

300

Plan de gestión de Riesgos

Registro de Riesgos

Jefe del Proyecto Jefe de calidad

1 1

100 100

Plan de Gestión de Calidad

Establecer responsabilidades

Jefe del proyecto Analista Comité de control de calidad

1 1 1

100 100

200

Desarrollo del RAM


1 1 1

100 100

200

Plan de Gestión de Recursos Humanos

Identificar , establecer y desarrollar RAM del personal

Jefe del proyecto Analista

1 1

150 150

300

Plan de Gestión de Adquisiciones

Planificar compras, adquisiciones y contrataciones


1 1

150 150

300

//..

73

..//




Nombre del recurso

Unid Costo unit.

Costo Total

Nombre del

recurso

Costo unitario

Costo Total

Nombre del recurso

Unid Costo


Plan de gestión de Interesados

Clasificación, registro y estrategia de los interesados

Jefe del proyecto Analista Patrocinador

1 1

100 100

200

Ejecución

Lista de actores del negocio y del sistema

Analista 1 400 400

Listado de casos de uso

Analista 1 500 500

Desarrollo del modelo de contenidos

Analista Diseñador Programador

1 1 1

200 200 100

500

Desarrollo del modelo de navegación

Analista Diseñador

1 1

200 300

500

MagicDraw Enterprice 17

1 5 397.3 5 397.3

Desarrollo del modelo de presentación

Analista Diseñador

1 1

300 200

500

Desarrollo del modelo de estructura de procesos

Analista Programador

1 1

250 250

500

Diagrama de flujo de procesos

Analista Programador

1 1

300 400

700

Desarrollo de la base de datos

Programador 1 400 400

Diccionario de datos

Programador 1 200 200

//..

74

..//




Nombre del recurso

Unid Costo unit.

Costo Total

Nombre del

recurso

Costo unitario

Costo Total

Nombre del recurso

Unid Costo


Ejecución

Prototipos Diseñador Programador Tester

1 1 1

450 450

900

Macromedia Dreamweaver

CS6 1 1 077.3 1 077.3

Producto final

Diseñador Programador Tester Comité de control de calidad

1 1 1 1

400 700 200

1300

Seguimiento y control

Inspección de calidad

Jefe del proyecto Comité de control de calidad

1 1

600 600

Solicitudes de cambios aprobadas

Jefe del proyecto Coordinador del proyecto Comité de control de calidad

1 1 1

400 400 Materiales

de Escritorio

- 100

Informe de monitoreo de riesgos


1 1

250 250

500

//..

75

..//




Nombre del recurso

Unid Costo unit.

Costo Total

Nombre del

recurso

Costo unitario

Costo Total

Nombre del recurso

Unid Costo


Actas de reuniones de control del proyecto

Acta de reunión de aceptación del proyecto

Jefe del proyecto

1 80 80 Materiales de Escritorio

20

Acta de reunión de entrega del primer módulo

Jefe del proyecto


20

Acta de reunión de entrega del segundo módulo

Jefe del proyecto


20

Acta de reunión de cierre del proyecto

Jefe del proyecto


20

Lecciones aprendidas

Documentar lecciones aprendidas

Documentador 1 200 200 Materiales

de Escritorio

- 100

Acta de aceptación del Proyecto

Realizar Acta de aceptación

Jefe del Proyecto

1 200 200

Actualizar Documentos del Proyecto

Jefe del Proyecto Documentador

1 1

200 300

500 Materiales

de Escritorio

- 100

Total Soles 12 720 Total Soles 380 Total Soles 6 474.60

76

La siguiente tabla muestra el total de los costos:

Tabla 9 RESUMEN DEL TOTAL DE COSTO

Descripción Costo Total

Costo de hardware S/. 0.00

Costo de software S/. 6,474.60

Costo por personal S/. 12.720.00

Costo materiales de escritorio S/. 380.00

Total costos pre-operativos S/. 19,574.60

A continuación se muestra el detalle de los costos operativos, cuyas tablas

son extraídas del Plan de Gestión de Adquisiciones

Tabla 10 COSTO POR PERSONAL

Cant. Descripción Mes Mes 1 Mes 2 Mes 3 Precio

unitario Total

1 Jefe de Proyecto 3 • • • S/. 1, 406.70 S/. 4, 220.00

1 Analista 3 • • • S/. 1, 250.00 S/. 3, 750.00

1 Diseñador 2

• • S/. 775.00 S/. 1, 550.00

1 Programador - tester

2

• • S/. 1, 350.00 S/. 2,700.00

1 Documentador 1

• S/. 500.00 S/. 500.00

S/ 12, 720.00

Tabla 11 COSTO POR SOFTWARE

Cantidad Descripción Tipo de licencia

*Costo en dólares Costo total en

soles

1 Magic Draw Enterprice $ 1,999.00 S/. 5,397.30

1 Macromedia

Dreamweaver CS6

Standard $ 399.00 S/. 1,077.30

S/ 6, 474.60

*Precio actual del dólar S/. 2.70

77

3.3. Análisis del sistema

En esta sección se buscará el análisis del sistema para lograr cumplir con los

objetivos propuestos en esta investigación. Es necesario en este punto

presentar parte de los entregables generados por siguiendo La Guía PMBOK

Quinta Edición y que se presentarán más adelante según sea necesario:

A. Enunciado del Alcance

Descripción del Alcance del Producto

Requerimientos Características

Lograr que los componentes del producto cumplan con las especificaciones técnicas requeridas.

El software tiene que ser desarrollado para funcionar en una plataforma web.

Criterios de aceptación del protocolo

Conceptos Criterios de aceptación

Técnicos Que cumpla con las características y requerimientos establecidos por el cliente.

Calidad

Pasar por las técnicas de evaluación de software. Pasar por pruebas de compatibilidad. Lograr el 90% de satisfacción del cliente.

Administrativos Todos los entregables debes ser aprobados por la Oficina de Coordinación de Monitoreo, Evaluación e Informática.

Comerciales Se debe cumplir lo estipulado en el contrato.

Entregables del proyecto

Fases del proyecto Productos entregables

Inicio Acta de Constitución del Proyecto Identificación de los Interesados

Planificación

Plan de dirección del Proyecto Plan de gestión del Proyecto Plan de gestión del Alcance, Tiempo, Calidad, Recursos Humanos, Comunicaciones, Riesgos, Adquisiciones e Interesados

Ejecución Acta de reunión de control del proyecto

Seguimiento y Control Inspección de calidad Solicitudes de cambios aprobados Informes de monitoreo de riesgos

Cierre Lecciones aprendidas Acta de cierre del Proyecto

Restricciones del Proyecto

Internos a la Organización Externos a la Organización

Solo se emplearan los recursos asignados para el desarrollo del proyecto.

El presupuesto empleado no superará lo establecido en la propuesta presentada al Cliente.

El tiempo de finalización del proyecto no debe durar más del tiempo establecido y acordado con el cliente.

78

B. Diccionario EDT

Especificación de paquetes de trabajo del EDT

FASE 1: Gestión del proyecto

1.1. Iniciación

1.1.1. Acta de constitución del proyecto

Documento de gestión que detalla: descripción del proyecto, definición del producto, objetivos del proyecto, finalidad y justificación del proyecto, riesgos y oportunidades del proyecto.

1.1.2. Identificación de Interesados

Lista las personas y organizaciones como clientes, patrocinadores, organización ejecutante y el público, involucrados activamente en el proyecto, o cuyos intereses pueden verse afectados de manera positiva o negativa para la ejecución o conclusión del proyecto.

1.2. Planeación 1.2.1. Plan de dirección del proyecto

Documento formalmente aprobado que define cómo se ejecuta, supervisa y controla un proyecto. Puede ser resumido o detallado y estar compuesto por uno o más planes de gestión de subsidiarios y otros documentos de planificación. Contiene: 1.2.1.1. Plan de Gestión de Alcance 1.2.1.2. EDT. 1.2.1.3. DEDT. 1.2.1.4. Presupuesto. 1.2.1.5. Cronograma. 1.2.1.6. Plan de Gestión de Calidad. 1.2.1.7. Organización del Proyecto. 1.2.1.8. RAM. 1.2.1.9. Plan de Gestión de RR.HH. 1.2.1.10. Plan de Gestión de

Comunicaciones. 1.2.1.11. Plan de Gestión de Riesgos. 1.2.1.12. Plan de Gestión de

Adquisiciones. 1.2.1.13. Plan de Gestión de

Interesados.

1.3. Ejecución

1.3.1. Acta de reunión de control de trabajo del proyecto

Documento que contienen una relación escrita y detallada de lo discutido y acordado con respecto a la ejecución del proyecto.

1.3.2. Base de datos

Desarrollo de la base de datos del software

1.3.3. Diccionario de datos

Documento detallado con la descripción de los elementos de la base de datos

1.3.4. Prototipos Avances del producto final que son revisados por el comité de control de calidad

1.3.5. Producto final

Producto final que contiene los requerimientos establecidos en el TDR así como los cambios realizados durante la construcción

//..

79

..//

Especificación de paquetes de trabajo del EDT

1.4. Seguimiento y control

1.4.1. Inspección de calidad

Documento de que verifica el cumplimiento de la calidad del producto desarrollado

1.4.2. Solicitudes de cambios aprobados

Documentos que registran los cambios acordados y aprobados del producto

1.4.3. Informe de monitoreo de riesgos

Recopila y realiza una evaluación de los riesgos latentes determinando el impacto estimado en la gestión de riesgos con el impacto real.

1.5. Cierre

1.5.1. Lecciones aprendidas

Recopilación de lo aprendido para proyectos futuros.

1.5.2. Acta de cierre del proyecto

Documento que informa de la aceptación del producto final y da por culminado el proyecto.

FASE 2: Gestión del producto

2.1. Análisis de requerimientos

2.1.1. Lista los actores del negocio

Se identifica a los actores del negocio en base a los Interesados

2.1.2. Lista de los actores del sistema

Se identifica a los actores del sistema en base a los Interesados

2.1.3. Lista de los requerimientos del sistema

Lista de las necesidades del sistema teniendo como base los requerimientos planteados por el cliente.

2.2. Análisis del sistema

2.2.1. Listado de casos de uso

Lista de los casos de uso necesarios para cumplir los requerimientos del sistema.

2.2.2. Diagrama de casos de uso

Diagrama UML de los casos de uso.

2.3. Diseño del sistema

2.3.1. Diagramas de los Modelos UWE.

Diagramas de los modelos utilizados para el diseño del sistema basado en la metodología UML-based Web Engineering (UWE): Diagrama de flujo de procesos. Modelo de contenidos. Modelo de navegación. Modelo de presentación. Modelo de estructura de procesos. Diagramas de flujo de procesos.

80

C. Matriz de Asignación y responsabilidades de la Calidad

Personal

Comité de control de calidad

Jefe

de

l P

royecto

Coord

ina

dor

del

pro

yecto

Jefe

de

calid

ad

Econó

mic

o

Contr

ol d

e

Pers

ona

l

Adq

uis

icio

nes

Cam

bio

s

Docum

enta

dor

Acti

vid

ad

es

Acta de constitución del proyecto RP I I I I P A IP

Plan de Gestión de Alcance RP I I I I P A I

EDT RP I I I I P A I

Cronograma RP I I I I P A I

Análisis de Costos y presupuestos RP

P

I

Evaluación económica y financiera RP

P

I

Acti

vid

ad

es

Informe de rendimiento de trabajo RP

A

P RP I

Reunión de coordinación del trabajo A P P P P P R I

Reunión de control del trabajo de proyecto A P P P P P R I

Inspección de calidad A P P P P P R I

Revisión de solicitudes de cambios RP

A P R I

Aprobación de solicitudes de cambios RPS AR R I

Información existente revisada y recopilada RP P P P P P A I

Revisión de Informes de Control de riesgos A I I I I P RP I

Verificación de prototipos y producto final RP I I A I P RP I

A= Responsable, R = Se requiere revisión, I = Se requiere Opinión, S = Se requiere Firma, P = Participa

El detalle del personal se puede revisar en la sección 3.3.1.A.

81

D. Riesgos Cualitativos

Código del

Riesgo Descripción Causa Consecuencia

Tipo de

Riesgo

R01 Disponibilidad de Recursos Humanos

Sobrecarga de trabajo del personal asignado.

Retraso en las actividades del proyecto.

Alta

R02 Disponibilidad de equipos

- Retraso en las actividades del proyecto.

Media

R03 Renuncia del personal clave del proyecto

Oferta laboral en nuevos proyectos.

Cambio de personal. Alta

R04 Pérdida de información

Problemas técnicos.


Muy Alta

R05 Modificación del Cronograma de actividades

Aceptación de solicitudes de Cambio.


Alta

R06

Metodología inadecuada para el desarrollo del producto

Mal planteamiento del proyecto.

Cierre del proyecto. Muy Alta

R07 Solicitudes de cambio aprobadas

Solicitudes de Cambio

Modificación y ampliación del cronograma.

Alta

R08 Desaprobación de entregables



Alta

R09 Bajo rendimiento del personal del proyecto

Clima laboral. Cambio de personal. Media

Teniendo en cuenta estos puntos se procede a realizar el análisis

correspondiente del sistema.

82

3.3.1. Requerimientos

A. Definición de los actores del negocio

A fin de entender claramente los actores externos e internos que

están involucrados en los procesos de estudio del negocio, a

continuación se muestran algunos documentos extraídos del Plan

de Gestión de Interesados.

Tabla 12 LISTA DE INTERESADOS

Rol general Interesados

Patrocinador Administrador

Equipo del

proyecto

Jefe del

Proyecto

Jefe del Proyecto : Ramírez Chávez Marbin Rusbelt Roles:

Analista: Realizar un análisis a la situación

actual de la empresa.

Programador-Tester: Desarrollar el software.

Diseñador: Realizar los diseños gráficos del

software.

Documentador: Registra todos los

documentos y actualizaciones generadas en

durante todo la gestión

Comité de

control de

calidad

Jefe de la Oficina de seguimiento y control - PMO Roles:

Supervisor: Verificar el avance y uso

adecuado de los recursos.

Jefe de calidad: Comprobar que el proyecto

cumpla con los estándares de calidad

establecidos.

Gerentes funcionales Director Ejecutivo

Usuarios

Encargados del registro

Encargados del monitoreo

Encargados del evaluación.

Tomadores de decisiones.

Otros Interesados

Beneficiarios.

Banco Mundial.

Agro Rural.

83

Tabla 13 MATRIZ DE INFLUENCIA VS PODER

Poder sobre el Proyecto

Baja Alta In

flu

en

cia

so

bre

el

pro

yec

to A

lta

Equipo del proyecto Patrocinador.

Gerentes funcionales. B

aja

Usuarios

Otros

Tabla 14 MATRIZ INTERÉS VS PODER

Poder sobre el Proyecto

Bajo Normal Alto

Inte

rés s

ob

re e

l p

roye

cto

A f

avo

r

Comité de calidad

Jefe del Proyecto. Patrocinador.

Gerentes funcionales.

No

rmal

Usuarios

Otros

En

co

ntr

a

84

En base a estos documentos se realiza el siguiente diagrama de

actores internos y externos del negocio:

Gráfico 7 ACTORES INTERNOS Y EXTERNOS DEL NEGOCIO

B. Necesidades genéricas de los actores del negocio

A continuación se muestra la Estrategia de Gestión de Interesados

del Plan de Gestión de Interesados que detalla las necesidades de

los actores del negocio involucrados en la investigación, sus

necesidades, intereses y estrategias necesarias para reducir

obstáculos en el desarrollo del proyecto.

85

Tabla 15 NECESIDADES GENÉRICAS DE LOS ACTORES DEL NEGOCIO

Interesados Interés en el proyecto Impacto Estrategia principal para ganar soporte o reducir

obstáculos

Administrador

Que el proyecto sea

terminado sin exceder los

costos establecidos en el

presupuesto.

Alto

Apoyar y facilitar las

necesidades requeridas por

el proyecto, sobre todo en

el financiamiento.

Director

Ejecutivo

Que el proyecto culmine el

desarrollo del producto y

cumpla con lo establecido

en el TDR.

Alto

Mantenerlo informado sobre

el avance del proyecto y los

problemas encontrados.

Jefe de la

oficina de

Coordinación

de Monitoreo,

Evaluación e

Informática

Que el producto final sea

desarrollado cumpliendo

los requerimientos para el

apoyo del monitoreo y

evaluación de planes de

negocio.

Muy alto

Mantenerlo informado sobre

el avance del proyecto y los

problemas encontrados,

sobretodo en la

construcción del producto.

Encargados

del registro

Encargados

del

monitoreo

Encargados

del

evaluación

Tomadores

de

decisiones

Utilizar el nuevo software

para facilitar el registro,

monitoreo y evaluación de

planes de negocio

Bajo

Incluirlos dentro del análisis

de los procesos de

monitoreo y evaluación de

planes de negocio.

AgroRual

Banco

Mundial.

Finalizar el desarrollo del

producto en el tiempo

establecido.

Medio

Informar continuamente

sobre la perfomance del

proyecto y mostrar los

avances (prototipos) y

versiones BETA.

Beneficiarios

Mejorar los productos que

llevan mucho tiempo para

ser procesados

Bajo

86

3.3.2. Definición de los actores del sistema

Los actores del sistema son aquellos que usan o intervienen de forma

directa con el sistema, a diferencia de los actores del negocio que son

aquellos que están involucrados con los procesos de manera directa o

indirecta.

Gráfico 8 ACTORES DEL SISTEMA

3.3.3. Requerimientos del sistema

A. Requisitos funcionales

Solicitar inicio de sesión para hacer uso del sistema.

Registrar nuevos planes de negocio

Editar planes de negocio

Convertir coordenadas de grados a decimales

Registrar identificación, justificación, alternativa, Marco Lógico,

beneficiarios y documentos físicos del plan de negocio.

Finalizar planes de negocio

Generar una ficha de registro del plan de negocio

Buscar planes de negocio

Registrar un ficha del PAO para cada plan de negocio viable

Mostrar la descripción de los componentes durante el registro de

la ficha PAO

Registrar saldo del año anterior y metas del PAO

87

Generar reportes de metas físicas y financieras, presupuesto por

componente.

Calcular los valores de la variación del costo (CV), el porcentaje

de variación del costo (CV%), la variación del cronograma (SV),

el porcentaje de variación del cronograma (SV%), el índice de

desempeño del costo (CPI) e índice de desempeño del

cronograma (SPI) por actividad y por el total del plan de negocio.

Cambiar el estado de los planes de negocio

B. Requisitos no funcionales

Solo los usuarios registrados pueden hacer uso del sistema.

El administrador debe contar con los permisos necesarios en el

sistema para tener acceso a todos los planes de negocio y

planes en ejecución sin importar la sede.

El sistema no debe dejar ingresar a los usuarios que no cuenten

con permisos para ingresar al menú principal.

El menú principal debe contar con información básica del usuario

e información de su sede de trabajo, así como el jefe de dicha

sede.

El sistema debe permitir cambiar la contraseña del usuario.

El menú principal solo debe mostrar al usuario las opciones en el

que tiene permisos.

El sistema debe permitir a los usuarios registrados y con los

permisos necesarios crear nuevos planes de negocio.


permisos necesarios continuar con el registro de planes

pendientes.


permisos necesarios buscar planes de negocio pendientes.


permisos necesarios tener una lista de los Planes en ejecución

(formato PAO).

Cuando se cree un nuevo plan de negocio el sistema debe

permitir escoger el fondo concursable entre Desarrollo Territorial

o Negocio Rural.

88

El sistema debe obligar a introducir un Título del plan de negocio

antes de registrarlo en la base de datos.

Al crear un nuevo plan de negocio el sistema debe generar un

código único de identificación.

El sistema debe otorgar a los planes de negocio el estado de

Propuesta y debe mantenerse así hasta que se termine con el

registro.

En la interface de registro de los planes de negocio debe mostrar

la información básica del plan, como son: nivel de estudio,

código único, código SNIP, código de idea o propuesta inicial,

nombre/título, oficina regional al que pertenece el Plan.

El registro de los datos de los planes de negocio debe realizarse

por secciones.

Para la ubicación del plan de negocio se debe usar un mapa y

ser guardado en coordenadas.

El sistema debe permitir guardar el avance del registro de los

datos por secciones.

El sistema debe obligar al usuario llenar completamente una

sección antes de guardarla.

Cuando se desee salir del registro, el sistema debe pedir la

verificación de esta acción.

El sistema debe verificar que todos los datos necesarios han

sido registrados antes de generar la ficha de registro.

La interface de ficha de registro debe contar con la opción de

guardar el plan de negocio; que cambia el estado del plan a

Viable, y la opción de cancelar; que devuelve al registro del plan

de negocio.

La interface de planes pendientes debe generar una lista de

todos los planes pendientes de la sede del usuario logeado.

Los usuarios con permisos necesarios para realizar la búsqueda

de planes de negocio deben poder buscar todos los planes de

negocio que se hallan registrado en su propia sede.

La interface de búsqueda de planes de negocio debe contar al

menos 2 opciones de búsqueda: Por título y por código del plan

de negocio.

89

El sistema solo debe permitir a los usuarios registrados y con los

permisos necesarios buscar los planes de negocio que están

establecidos como Propuesta.

El sistema debe permitir al administrador buscar todos los planes

de negocio sin importar su estado y cambiarlo si es necesario.

La interface de Planes en ejecución (formato PAO) debe tener

una lista de todos los planes de negocio terminados de registrar

y que pertenezcan a la sede del usuario logeado.

El sistema no debe permitir la eliminación de ningún plan de

negocio.

3.3.4. Listado de casos de uso del sistema (Simplificado)

Los casos de uso completos se encuentran anexados, se puede

considerar como principales los siguientes casos de uso del sistema:

1. Ingresar al sistema

2. Cambiar contraseña

3. Salir del sistema

4. Crear nuevo plan de negocio

5. Ver lista de planes de negocio pendientes

6. Registrar plan de negocio

7. Registrar Identificación del plan de negocio.

8. Convertir coordenadas de grados a decimales.

9. Registrar Justificación del plan de negocio.

10. Registrar Alternativa del Plan de negocio.

11. Registrar la Matriz del Marco Lógico del plan de negocio.

12. Registrar Beneficiarios del Plan de negocio

13. Registrar Documentos Físicos y aceptar los términos de la ficha

14. Cargar archivos

15. Ver ficha de registro

16. Finalizar registro del plan de negocio

17. Buscar Plan de negocio

18. Cambiar estado del plan de negocio

19. Ver lista de planes en ejecución (formato PAO)

20. Edición del formato PAO

21. Ver la Descripción del plan de negocio en el formato PAO

22. Editar Saldo del año anterior del plan de negocio en el formato PAO

90

23. Editar Metas del PAO del plan de negocio

24. Ver Metas físicas y financieras del plan de negocio en el formato

PAO

25. Ver Presupuesto por componente del plan de negocio en el formato

PAO

3.3.5. Descripción de casos de uso del sistema

C.U: Ingresar al sistema Actores: Registradores, Monitores, Evaluadores,

Tomadores de decisiones, administradores. Nº: 1

Descripción:

Los usuarios pueden ingresar al sistema utilizando su nombre de usuario y su contraseña,

siempre y cuando el usuario este activo y tenga al menos un permiso en las opciones del

menú principal.

Excepción 1:

Si el usuario ingresa un usuario y/o contraseña erróneos, el sistema no le permitirá

logearse y le pedirá verificar los datos antes de volver a intentar ingresar.

Excepción 2:

Si el usuario no tiene ningún permiso en las opciones del menú el sistema no le permitirá

ingresar y mostrará un mensaje.

C.U: Cambiar contraseña Actores: Registradores, Monitores, Evaluadores,


Descripción:

En caso de que el usuario quiera cambiar su contraseña puedo hacerlo ingresando su

contraseña actual, la nueva contraseña y la verificación de la nueva contraseña.

Excepción 1:

El usuario ingresa una contraseña actual incorrecta el sistema no cambiará la contraseña

y mostrará un mensaje en pantalla.

Excepción 2:

El usuario ingresa la verificación de la nueva contraseña diferente a la nueva contraseña.

El sistema mostrara en pantalla un mensaje de error y no cambiará la contraseña

C.U: Salir del sistema Actores: Registradores, Monitores, Evaluadores,


Descripción:

El usuario puede seleccionar la opción “cerrar sesión” para salir del sistema y devolverlo a

la interface de ingreso al sistema.

91

C.U: Crear nuevo Plan de Negocio Actores: Registradores Nº: 4

Descripción:

El usuario selecciona “Registrar nuevo plan” en el menú principal, el sistema direcciona a

la interface de creación de nuevos planes de negocio en donde primero se selecciona el

fondo concursable del plan, el código de idea o propuesta inicial (si es que tiene) y el

nombre o Título del Plan. Después se presiona el botón de guardar nuevo plan, el sistema

verificará los datos ingresados para luego guardarlo y generar un “código del Plan de

negocio único” que se mostrará en pantalla.

Finalmente el sistema direccionará a la interface de registro del plan de negocio.

Excepción 1:

El usuario presiona el botón ”cancelar”, sistema retornará a la interface del menú

principal,

Excepción 2:

El usuario no ingresa nada en el Título del Plan de Negocio, el sistema mostrará un

mensaje de alerta para corregirlo.

C.U: Ver lista de Planes de Negocio

pendientes Actores: Registradores, Monitores Nº: 5

Descripción:

El usuario selecciona “Planes pendientes” del menú principal, el sistema muestra una lista

de todos los planes de negocio sin terminar de registrar de su respectiva sede.

Se puede hacer clic al plan de negocio para pasar a la interface de registro del plan de

negocio.

Excepción :

No existen planes de negocio pendientes en la sede el usuario logeado.

C.U: Registrar plan de negocio Actores: Registradores Nº: 6

Descripción:

El usuario ingresa a la interface de registro de planes de negocio a través de: la creación

de nuevos planes de negocio, búsqueda de planes de negocio y la interface de planes

pendientes.

Se registra los datos e información de los planes de negocio, la interface está dividida en

secciones que deberán ser llenados para finalizar con el registro y cambiar el estado del

plan de negocio.

Excepción 1:

Si se desea salir de la interface de registro de planes de negocio, el sistema muestra un

mensaje en una alerta de confirmación.

Excepción 2:

No se ha llenado todos los datos necesarios para dar por finalizado el registro del plan de

negocio, el sistema mostrará un mensaje pidiendo el registro de los campos que faltan.

92

C.U: Registrar Identificación del plan de negocio. Actores: Registradores Nº: 7

Descripción:

El usuario introduce los datos en la primera sección de la interface de registro de planes

de negocio para después guardar la sección y pasar a la siguiente.

Excepción 1:

El usuario desea salir de la interface, el sistema pedirá la confirmación mediante un

mensaje en una alerta.

Excepción 2:

El usuario no llena todos los campos requeridos, el sistema indicará y pedirá que

complete los campos necesarios para guardar la sección.

C.U: Convertir coordenadas de grados a decimales Actores: Registradores Nº: 8

Descripción:

El usuario ingresa coordenadas en grados presiona el botón de conversión y el sistema

muestra las coordenadas en decimales para registrarlo como localización geográfica del

plan de negocio.

Excepción:

El usuario no ingresa en la latitud o longitud los valores de grados/minutos/segundos, el

sistema tomará los valores como 0 (cero).

C.U: Registrar Justificación del plan de negocio Actores: Registradores Nº: 9

Descripción:

El usuario introduce los datos en la segunda sección de la interface de registro de planes


Excepción 1:



Excepción 2:



C.U: Registrar Alternativa del plan de negocio Actores: Registradores Nº: 10

Descripción:

El usuario introduce los datos en la tercera sección de la interface de registro de planes


Excepción 1:



Excepción 2:

El usuario no llena todos los campos requeridos, el sistema indicará y pedirá al usuario

que complete los campos necesarios para guardar la sección.

93

C.U: Registrar la Matriz del Marco Lógico del

plan de negocio Actores: Registradores Nº: 11

Descripción:

E usuario or introduce los datos en la cuarta sección de la interface de registro de planes


Excepción 1:



Excepción 2:

El usuario no llena todos los campos requeridos, el sistema indicará y pedirá al usuario

que complete los campos necesarios para guardar la sección.

C.U: Registrar Beneficiarios del plan de negocio Actores: Registradores Nº: 12

Descripción:

El usuario introduce los datos en la quinta sección de la interface de registro de planes de

negocio para después guardar la sección y pasar a la siguiente.

Excepción 1:



Excepción 2:



C.U: Registrar Documentos Físicos del

plan de negocio Actores: Registradores Nº: 13

Descripción:

El usuario introduce los datos en la sexta sección de la interface de registro de planes de

negocio para después guardar la sección y pasar a la siguiente.

Excepción 1:



Excepción 2:



94

C.U: Cargar documentos físicos Actores: Registradores Nº: 14

Descripción:

La carga de archivos se realiza dentro del formulario de agregar y editar documentos

físicos.

El usuario presiona el botón para cargar archivos, el sistema muestra una ventana para

buscar y seleccionar un solo archivo, el usuario presiona el botón de guardar y el sistema

carga el archivo. EL sistema muestra un mensaje en pantalla confirmando que el archivo

fue cargado exitosamente.

Excepción:

El archivo no se puede subir al servidor, el sistema mostrará un mensaje indicando la

posible razón del porqué no se pudo subir el archivo.

C.U: Ver ficha de registro Actores: Monitores, Evaluadores, Tomadores

de decisiones, Administradores Nº: 15

Descripción:

El usuario presiona el botón de “ver la ficha de registro” el sistema valida la información

ingresada en todas las secciones y re-direcciona la página a la interface de “Fucha de

registro del plan de negocio”.

Excepción 1:

Se verifica que no se ha ingresado todos los datos necesarios, el sistema muestra una

alerta con un mensaje indicando la sección y subsección en donde no se completó el

registro.

Excepción 2:

El sistema comprueba que la cantidad ingresada en el monto de pre-inversión de la

sección “Alternativa del plan de negocio” es diferente a la suma total de actividades

registradas en la sección “Matriz del Marco Lógico”, el sistema muestra el mensaje

correspondiente en una alerta.

Excepción 3:

El sistema comprueba que no se ha registrado un mínimo de 10 beneficiarios en la

sección “beneficiarios del plan de negocio”, el sistema muestra el mensaje

correspondiente en una alerta.

Excepción 4:

El sistema comprueba que no se ha cargado ningún archivo en la sección “Documentos

físicos”, el sistema muestra el mensaje correspondiente en una alerta

Excepción 5:

El sistema comprueba que no se ha establecido al menos un archivo subido con un

propósito de viabilidad”, el sistema muestra el mensaje correspondiente en una alerta.

95

C.U: Finalizar registro del

plan de negocio

Actores: Monitores, Evaluadores, Tomadores

de decisiones, Administradores Nº: 16

Descripción:

El usuario puede dar por finalizado el registro del plan de negocio mientras se encuentren

en la interface de Ficha de Registro presionando el botón de “Guardar”. El sistema

cambiará el estado del plan de negocio de Propuesta a Viable y re-direcciona la página a

la de menú principal.

Excepción:

El usuario presiona el botón de “Cancelar”, el sistema no cambia el estado del plan de

negocio y re-direcciona la página a la interface de Registro de plan de negocio.

C.U: Buscar Plan de negocio

por código del proyecto

Actores: Registradores, Monitores,

Evaluadores, Tomadores de decisiones,

administradores.

Nº: 17

Descripción:

El usuario selecciona el tipo de búsqueda por: código, título del plan de negocio o

búsqueda personalizada en la interface de búsqueda de plan de negocio. El usuario

ingresa los datos requeridos según la búsqueda seleccionada y el sistema devuelve el

plan encontrado mostrando su código, título y estado.

Excepción 1:

El usuario selecciona búsqueda por código e ingresa el código del plan con un formato

incorrecto, el sistema mostrara un mensaje en pantalla pidiendo la verificación del código.

Excepción 2:

El usuario selecciona búsqueda por título y no ingresa el título del plan, el sistema

mostrara un mensaje en pantalla pidiendo que ingrese el título o parte de él.

Excepción 3:

El sistema no encuentra ninguna coincidencia con la búsqueda seleccionada por el

usuario, muestra un mensaje en pantalla con el mensaje correspondiente.

C.U: Cambiar el estado del plan de negocio Actores: Administradores Nº: 18

Descripción:

El administrador selecciona la opción de “cambiar estado de plan de negocio” en la lista

de planes mostrados en la interface de búsqueda de planes de negocios seguidamente se

muestra una pequeña sección para realizar el cambio. Selecciona el nuevo estado y

presiona “Cambiar”, el estado cambia en pantalla y la sección se oculta.

Excepción:

El administrador presiona cancelar en la sección de cambio de estado del plan de

negocio, la sección se vuelve a ocultar.

96

C.U: Ver lista de planes en

ejecución



administradores.

Nº: 19

Descripción:

El usuario selecciona “Planes en ejecución” del menú principal, el sistema muestra una

lista de todos los planes de negocio en ejecución de su respectiva sede.

Se puede hacer clic al plan de negocio para pasar a la interface de edición del formato

PAO.

Excepción :

No existen planes de negocio en ejecución en la sede el usuario logeado.

C.U: Edición del formato

PAO



Administradores.

Nº: 20

Descripción:

El usuario ingresa a la interface de edición del formato PAO a través de: la búsqueda de

planes de negocio (Solo administradores) y la interface de planes en ejecución.

Se registra y visualiza los datos referentes a la ejecución del plan de negocio según el

formato PAO. La interface está divido en secciones, en la cual la sección principal cuenta

con opciones de selección de periodos y sus pasos críticos, además de una tabla

principal que contiene los componentes y actividades registrados en la Matriz del Marco

Lógico durante la etapa de propuesta del plan de negocio.

Excepción:

No existen planes de negocio en ejecución en la sede del usuario logeado.

C.U: Ver la descripción del

plan de negocio


de decisiones. Nº: 21

Descripción:

El usuario selecciona la primera sección de la interface de edición del formato PAO, luego

selecciona un componente registrado del plan de negocio, el sistema muestra la

descripción de los indicadores, medios de verificación y supuestos.

C.U: Editar Saldo del año anterior del

plan de negocio en el formato PAO


Evaluadores Nº: 22

Descripción:

El usuario selecciona un registro y presiona el botón de Editar, el sistema muestra un

formulario para cambiar los datos e información del registro, después se presiona el botón

de Guardar del formulario, el sistema valida la información y guarda los cambios.

Excepción 1:

El usuario presiona cancelar en el formulario, el sistema oculta el formulario.

Excepción 2:

El sistema encuentra errores al momento de validar la información, muestra un mensaje

en pantalla indicando el campo y su error.

97

C.U: Editar Metas del

PAO del plan de negocio Actores: Registradores, Monitores, Evaluadores Nº: 23

Descripción:

El usuario selecciona un registro y presiona el botón de Editar, el sistema muestra un

formulario para cambiar los datos e información del registro, después se presiona el botón

de Guardar del formulario, el sistema valida la información y guarda los cambios.

Excepción 1:

El usuario presiona cancelar en el formulario, el sistema oculta el formulario.

Excepción 2:

El sistema encuentra errores al momento de validar la información, muestra un mensaje

en pantalla indicando el campo y su error.

C.U: Ver Metas físicas y

financieras del plan de

negocio



Descripción:

El usuario selecciona la cuarta sección de la interface de edición del formato PAO, luego

selecciona una actividad registrada del plan de negocio, el sistema muestra una tabla con

la información detallada de los importes físicos y financieros registrados como resumen

de lo ingresado en la tercera sección (Metas del PAO) por periodos registrados.

C.U: Ver Presupuesto por

componente del plan de

negocio



Descripción:

El usuario selecciona la quinta sección de la interface de edición del formato PAO, el

sistema muestra una tabla con la información del presupuesto general de todos los

componentes registrados en las secciones anteriores (Saldo del año anterior, Metas del

PAO), la tabla se mostrara por periodos registrados.

También se mostrara los valores calculados de la variación del costo (CV), el porcentaje

de variación del costo (CV%), la variación del cronograma (SV), el porcentaje de variación

del cronograma (SV%), el índice de desempeño del costo (CPI) e índice de desempeño

del cronograma (SPI).

98

3.3.6. Diagrama de casos de uso (Simplificado)

El diagrama completo de casos de uso se encuentra en los anexos.

Gráfico 9 DIAGRAMA DE CASOS DE USO

3.4. Diseño del sistema

3.4.1. Modelo de contenidos

El modelo de contenidos permite esbozar la necesidad de datos

persistentes en el sistema. Este modelo será de suma utilidad al

avanzar sobre la implementación del sistema, se ha dividido en 2

diagramas: Contenido de Registro de plan de negocio y Contenido de

Registro del formato PAO.

99

Gráfico 10 MODELO DE CONTENIDO – REGISTRO DE PLAN DE NEGOCIO

100

Gráfico 11 MODELO DE CONTENIDO – REGISTRO DEL FORMATO PAO

3.4.2. Modelo de navegación (Simplificado)

Se puede revisar el modelo de navegación completo en los anexos:

101

Gráfico 12 MODELO DE NAVEGACIÓN

102

3.4.3. Modelo de presentación

El Modelo de Navegación no indica cuáles son las clases de navegación

y de proceso que pertenecen a una página web. Podemos usar un

Diagrama de Presentación con el fin de proveer esta información. Los

modelos de presentación generados son:

1. Inicio de sesión

2. Menú principal


4. Lista de planes pendientes



7. Registro de la identificación

8. Registro de la justificación

9. Registro de la alternativa

10. Registrar matriz del marco lógico

11. Registro de beneficiarios

12. Registro de documentos físicos


14. Buscar planes de negocio

15. Registro del formato PAO

16. Descripción del formato PAO

17. Saldo del año anterior y metas del formato PAO

18. Metas físicas y financieras

19. Presupuesto por componente

A continuación se muestra los principales modelos de presentación, los

demás modelos se pueden revisar en el anexo:

103

Gráfico 13 MODELO DE PRESENTACIÓN - CREAR NUEVO PLAN DE NEGOCIO

104

Gráfico 14 MODELO DE PRESENTACIÓN - REGISTRAR PLAN DE NEGOCIO

105

Gráfico 15 MODELO DE PRESENTACIÓN - BUSCAR PLANES DE NEGOCIO

106

Gráfico 16 MODELO DE PRESENTACIÓN - REGISTRO DEL FORMATO PAO

3.4.4. Modelo de procesos y diagramas de flujo de procesos

Hasta ahora hemos logrado modelar muchas características del sitio

que plantea el proyecto. Para agregar más detalles vamos a describir

cómo serán las acciones de las clases de proceso planteadas. El

Modelo de Procesos abarca:

A. Modelo de estructura de procesos (Simplificado)

Describe las relaciones entre las clases de procesos. A

continuación se muestra el modelo de estructura de los

principales procesos:

107

Gráfico 17 MODELO DE ESTRUCTURA DE PROCESOS

108

B. Diagramas de flujo de procesos

Especifica las actividades conectadas con cada clase de

proceso. Los diagramas de flujo nos ayudan entender cómo se

desarrolla cada proceso del modelo de estructura de procesos.

Los diagramas de procesos generados son:

1. Login


3. Salir del sistema



6. Registrar sección de Identificación

7. Convertir coordenadas de grados a decimales

8. Registrar Localización geográfica

9. Registrar comunidad

10. Registrar sección de Justificación

11. Registrar Actividad productiva y producto promocionado

12. Registrar sección de Alternativa

13. Registrar Hito (periodo)

14. Registrar pasos críticos

15. Registrar sección de la Matriz del marco lógico

16. Registrar Componente

17. Registrar Actividad

18. Registrar sección de los Beneficiarios

19. Registrar sección de Documentos físicos

20. Registrar documentos físicos

21. Cargar archivos


23. Finalizar registro del plan de negocio

24. Cambiar estado del plan de negocio

25. Registro del formato PAO

26. Ver Descripción del formato PAO

27. Saldo del año anterior

28. Metas del formato PAO

29. Metas físicas y financieras

30. Presupuesto por componente

31. Agregar Localización geográfica

109

32. Agregar comunidad

33. Agregar actividad productiva y producto promocionado

34. Agregar Hitos

35. Agregar pasos críticos

36. Agregar componentes

37. Agregar actividades

38. Agregar beneficiarios

39. Agregar documentos

40. Editar Saldo del año anterior

41. Editar Metas del formato PAO

42. Eliminar Localización geográfica

43. Eliminar comunidad

44. Eliminar actividad productiva y producto promocionado

45. Eliminar Hitos

46. Eliminar paso crítico

47. Eliminar Componente

48. Eliminar actividad

49. Eliminar beneficiario

50. Eliminar documento

A continuación se desarrolla los principales diagramas de

flujos, los demás se pueden revisar en los anexos:

110

Gráfico 18 DIAGRAMA DE FLUJO DE PROCESOS – CREAR NUEVO PLAN DE NEGOCIO

111

Gráfico 19 DIAGRAMA DE FLUJO DE PROCESOS – REGISTRAR PLAN DE NEGOCIO

112

Gráfico 20 DIAGRAMA DE FLUJO DE PROCESOS – VER FICHA DE REGISTRO

Gráfico 21 DIAGRAMA DE FLUJO DE PROCESOS – REGISTRO DEL FORMATO PAO

113

3.4.5. Diseño de pantallas

La aplicación se desarrolló en un entorno web, utilizando el programa

Dreamweaver CS6. A continuación se presenta y describe las interfaces

desarrolladas:

En el Gráfico Nº se observa la interface de “Inicio de sesión” que solicita

un usuario y contraseña indispensables para el ingreso al sistema, que

una vez validados procederá a re-direccionar la página al menú

principal.

Gráfico 22 INTERFACE DE INICIO DE SESIÓN

114

En el Gráfico Nº se muestra la interface para registrar un nuevo plan de

negocio.

El código SNIP es un campo creado para futuras necesidades del

Programa ALIADOS, actualmente no es un campo obligatorio y no

cumple ninguna función en el sistema.

Gráfico 23 INTERFACE DE REGISTRO DE NUEVO PLAN DE NEGOCIO

115

En el Gráfico Nº se muestra la interface de Registro de Plan de negocio.

Como se modelo anteriormente, la interface está dividida en 6

secciones las cuales se detallarán más adelante y por defecto carga la

primera sección “Identificación”.

Gráfico 24 INTERFACE DE REGISTRO DE PLANES DE NEGOCIO

116

En el GRÁFICO Nº se muestra la interface de búsqueda y la opción de “Cambiar

estado del Plan de negocio” que solo está disponible para los administradores.

Gráfico 25 BÚSQUEDA Y CAMBIO DE ESTADO DEL PLAN

En el GRÁFICO Nº se muestra la interface de Registro de formato PAO que, igual al

registro de planes de negocio, está dividido en secciones, 5 en total.

Como se ha modelado anteriormente la información mostrada en las secciones

dependen de la selección de Componentes o actividades de la Tabla Principal,

además de seleccionar el periodo que se desea consultar. Todas las secciones

dependen de esta interacción a excepción de la sección “Presupuesto por

componente” que solo depende de la selección del periodo.

117

Gráfico 26 INTERFACE DE REGISTRO DEL FORMATO PAO

118

3.5. Cierre del proyecto

Con la presentación y entrega final del software se da por finalizado el proyecto

por lo que realiza el cierre del mismo. A continuación se muestra algunos

entregables que fueron necesarios para culminar exitosamente con el software

así como finalizar el proyecto:

3.5.1. Solicitud de cambio Nº 001

Tipo de cambio requerido

Acción correctiva

Definición del problema o situación actual

Se detectó algunos problemas de facilidad en el uso de las interfaces y la falta de restricciones para los usuarios.

Descripción detallada del cambio solicitado

El cambio se realizará de la siguiente forma:

Se desarrollará una interface en cual solo se necesitará el fondo concursable y el título del plan para la creación de nuevos planes de negocio para luego pasar a la interface de registro del proyecto.

Se hará uso del frameworks JqGrid para el registro de las secciones que requieran más de un solo registro.

Se utilizará el App “Google Maps” para el registro de la localización del proyecto.

Se agregarán métodos de búsqueda de planes de negocio, los cuales serán: o Búsqueda por código o Búsqueda por título o Búsqueda personalizada

Respecto a los permisos de los usuarios se realizarán los siguientes cambios:

Se integrará el control del acceso a las diferentes interfaces a través de permisos asignados a los usuarios en la Base de Datos.

Solo los usuarios administradores serán capaces de realizar búsquedas a los planes de negocio sin importar sus estados, los demás usuarios tendrán permisos entre:

o Búsqueda de planes pendientes o Búsqueda de planes ejecutados

Razón por la que solicita el cambio

Los cambios se realizarán debido a las interfaces del software que dificultaban su uso, además de no contar con restricciones según el usuario que lo utiliza.

Efectos en el proyecto

Corto plazo Largo plazo

Ninguno Ninguno

Observaciones y comentarios adicionales

La entrega del primer módulo se realizó antes del tiempo establecido, por lo cual la realización de los nuevos cambios se encuentra dentro del tiempo determinado del proyecto.

119

3.5.2. Informe de monitoreo de riesgos

Riesgos actuales potenciales

Revisión y confirmación de probabilidad e impacto estimados inicialmente

Disponibilidad de recursos humanos redujo la probabilidad a 0.3

Disponibilidad de equipos aumentó la probabilidad 0.5

Renuncia del personal y pérdida de información redujo la probabilidad a 0.2

Modificación del cronograma de actividades redujo la probabilidad a 0.3

Uso de metodología inadecuada para el desarrollo del producto redujo la probabilidad a 0.2

Solicitudes de cambios aprobadas y desaprobación de entregables aumentó a 0.4

Bajo rendimiento del personal se redujo a 0.3

Revisión de adecuaciones de respuestas planificadas para los riesgos identificados inicialmente

Se realiza reuniones con el equipo del proyecto para determinar el avance del proyecto así como el control de la calidad del producto

Revisión de planes de contingencia para los riesgos identificados inicialmente

Se realizó un análisis exhaustivo del entregable rechazado mejorando el módulo con la adición de los cambios aprobados.

Se minimizó las posibilidades de reajuste de actividades y del cronograma establecido debido al adelanto de la entrega del primer módulo

Verificación de ejecución de respuestas planificadas

Se generó actas de reuniones para llevar un control de lo acordado.

Riesgos actuales sucedidos

Valoración de impacto real vs impacto estimado

Que el primer módulo desarrollado no cumpla con las expectativas del comité de control de calidad, al inicio la probabilidad del riesgo fue de 0.2 ahora es del 0.4

Incumplimiento de las fechas de entrega con lo cual se modificaría el cronograma de actividades, inicialmente la probabilidad del riesgo fue de 0.4 actualmente es del 0.3

Revisión de planes de contingencia

Se realizará un análisis exhaustivo de los entregables.

Se considerará el reajuste de actividades del cronograma.

Elaboración de planes de emergencia

Se elaborará un reajuste de actividades del cronograma.

Programación de ejecución de planes de contingencia/emergencia

El plan de contingencia se realizó cuando el comité de control de calidad rechazó el primer módulo por falta de facilidad de uso y carencia de un control de permisos, además de establecer una nueva interface dentro del módulo.

Evaluación de necesidades de acciones correctivas o solicitudes de cambio

Las solicitudes de cambios Nº 001 y Nº 002 se detectaron en la entrega del primer módulo, ambos surgen como una actualización del primer módulo frente a características no previstas en la realización del TDR y no como incumplimiento de desarrollo. Las acciones correctivas se realizan dentro del cronograma debido a que la presentación del primer módulo se realizó con anticipación a la fecha establecida, minimizando los impactos en el proyecto.

Nuevos riesgos detectados

Rechazo del primer módulo con las correcciones establecidas

Rechazo del segundo módulo.

120

3.5.3. Inspección de calidad Nº 002

Datos del entregable inspeccionado

Informe de entrega del primer módulo corregido

Primer módulo desarrollado y corregido

Datos de la inspección

Objetivo de la inspección

Verificar que el primer módulo esté completo y cuente con las especificaciones técnicas establecidas.

Comprobar que el desarrollo del primer módulo se realizó utilizando la metodología establecida.

Comprobar que el informé detalle correctamente el desarrollo del primer módulo.

Grupo de inspección

Persona Rol en el proyecto Rol durante la inspección

Observaciones

Oficina de Coordinación de Monitoreo, Evaluación e Informática

Jefe de calidad Supervisor

Resultado de la Inspección Conforme

Lista de defectos a corregir o mejoras a realizar

Responsable Observaciones

Ninguna

Observaciones complementarías

Se ha autorizado el inicio de construcción del segundo módulo

Documentos adjuntos

Ninguno

121

3.5.4. Acta de aceptación del proyecto

Declaración de la aceptación formal

Por la presente, se deja entera constancia de que el presente proyecto “Software de monitoreo y evaluación de planes de negocio para el Programa ALIADOS del Ministerio de Agricultura”, en la responsabilidad de la Oficina de Coordinación de Monitoreo, Evaluación e Informática, ha sido culminado y aceptado por la misma oficina en los tiempos adecuados para su posterior implementación. El proyecto ha comprendido la finalización y entrega de los siguientes entregables:

1. Gestión del Proyecto 1.1. Iniciación

1.1.1. Acta de constitución del proyecto 1.1.2. Identificación de los interesados

1.2. Planificación 1.2.1. Plan de dirección del proyecto

1.2.1.1. Plan de Gestión de Alcance 1.2.1.2. Plan de Gestión de Costos 1.2.1.3. Plan de Gestión de Calidad 1.2.1.4. Plan de Gestión de Recursos Humanos 1.2.1.5. Plan de Gestión de Riesgos 1.2.1.6. Plan de Gestión de Adquisiciones 1.2.1.7. Plan de Gestión de Tiempo 1.2.1.8. Plan de Gestión de Interesados

1.3. Ejecución 1.3.1. Actas de reuniones de coordinación del proyecto

1.4. Control y monitoreo 1.4.1. Inspección de Calidad 1.4.2. Solicitudes de cambios 1.4.3. Informe de Monitoreo de Riesgos

1.5. Cierre 1.5.1. Informe de cierre del proyecto

1.5.1.1. Acta de aceptación del proyecto 1.5.1.2. Relación de lecciones aprendidas generadas

2. Gestión del Producto 2.1. Lista de actores del negocio 2.2. Lista de actores del sistema 2.3. Lista de requerimientos del sistema 2.4. Casos de uso 2.5. Modelo de contenidos 2.6. Modelo de navegación 2.7. Modelo de presentación 2.8. Modelo de procesos 2.9. Diagramas de flujo de procesos 2.10. Base de datos 2.11. Diccionario de datos 2.12. Producto final

3. Componentes del Producto 3.1. Desarrollo del primer módulo 3.2. Desarrollo del segundo módulo 3.3. Código fuente 3.4. Base de datos 3.5. Diccionario de datos

4. Informes del Producto 4.1. Informe del primer módulo 4.2. Informe del segundo módulo

El proyecto fue culminado con éxito y en la fecha establecida.

//..

122

..//

Observaciones adicionales

El proyecto culminó la entrega del primer módulo con anticipación, pero debido a cambios solicitados por el comité de control de calidad el cronograma se realizó según lo planificado.

Aceptado por

Nombre del cliente, Sponsor u otro funcionario Fecha

Administrador 28 de octubre del 2013

Director Ejecutivo 28 de octubre del 2013


28 de octubre del 2013

3.5.5. Lecciones aprendidas

Código Entregable Afectado

Descripción del

Problema Causa

Acción Correctiva

Resultado Obtenido

Lección Aprendida

001

3.1. Desarrollo del primer módulo

Dificultad en el uso del módulo

El desarrollo del módulo no fue lo suficientemente fácil de usar

Desarrollo de interfaces más amigables y fáciles de usar

Se ha conseguido terminar de construir satisfactoriamente el primer módulo.

Comprobar la facilidad de uso de productos futuros a través de pruebas más específicas

002

3.1. Desarrollo del primer módulo

Falta de una interface que muestre los datos de los planes registrados

La interface no fue establecida dentro del TDR ni tomada en cuenta en la gestión de alcance.

Desarrollo de la interface

Se ha conseguido satisfacer las necesidades del Programa.

Ir más allá de las necesidades establecidas por el cliente.

123

CAPITULO IV

ANÁLISIS E INTERPRETACIÓN DE LOS RESULTADOS

4.1. Población y muestra

4.1.1. Población

Teniendo en cuenta el la situación problemática y el objetivo de la

investigación, además de la comprobación de la hipótesis planteada, se

ha identificado como unidad de análisis los las Fichas de Registro de

Planes de Negocio involucrados en el proceso de Registro y monitoreo

de planes de negocio, realizadas en el procesos de control y Monitoreo.

Estos planes son de naturaleza aleatoria, por la diversidad de negocios

que se pueden realizar en los departamentos que son supervisados por

el Programa, los mismos que son aprobados a través de concursos.

También se tiene en consideración las limitaciones de la investigación,

razón por la cual, la población accesible es de 30 planes de negocio.

4.1.2. Muestra

El tipo de muestreo empleado es Aleatorio simple, porque se eligen

tantas unidades de medida como sea necesario para completar el

tamaño de muestra requerido, de tal forma que cada unidad tiene la

probabilidad equitativa de ser incluida en la muestra.

4.2. Nivel de confianza y grado de significancia

La ficha técnica sobre la cual van a ser probados los datos recolectados para la

prueba de hipótesis, está diseñada de la siguiente manera:

Nivel de Confianza: 95%

Significancia: 5%

124

4.3. Tamaño de la muestra representativa

Teniendo en consideración las características de la población, de la muestra,

del nivel de confianza y la significancia, con el propósito de que los resultados

estén respaldados estadísticamente se realiza un muestreo exhaustivo, es

decir se utilizará el total de la población, por lo cual se garantiza una muestra

representativa.

4.4. Análisis de resultados


Y = Registro y Monitoreo de planes de negocio

Y1 = Eficiencia Y11 = Tiempo en registrar un plan de negocio

Y2 = Situación

Y21 = Tiempo en calcular la Variación del costo (CV)

Y22 = Tiempo en calcular el Índice de desempeño del costo (CPI)

Y23 = Tiempo en calcular la Variación del cronograma (SV)

Y24= Tiempo en calcular el Índice de desempeño del cronograma (SPI)

Y3 = Avance del trabajo

Y31 = Tiempo en calcular el Porcentaje de variación del costo (CV%)

Y32 = Tiempo en calcular el Porcentaje de Variación del cronograma (SV%)

125

4.4.1. Grupo de control

A continuación se realizará el análisis estadístico descriptivo de los

datos obtenidos de las muestras, 30 planes de negocio, antes de usar la

aplicación web, es decir la Pre-test, utilizando la herramienta estadística

SPSS.

A. Indicador Eficiencia

1. Índice: Tiempo en registrar un plan de negocio

Tabla 16 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - ESTADÍSTICA DESCRIPTIVA

Tiempo en registrar un plan de negocio

Media 37,00

Mediana 38,00

Moda 38

Desviación estándar 1,000

Varianza 2,000

Rango 5

Mínimo 35

Máximo 40

Suma 1128

En la tabla observamos que el promedio del índice “Tiempo en registrar un plan de

negocio” es de 37 minutos, la mediana es de 38 minutos, que representa el número

medio de todos los tiempos de la muestra; la moda es de 38 minutos, que representa

el tiempo con mayor frecuencia y una desviación estándar de 1, que representa cuan

cercano o alejado se encuentran los datos respecto a la media. También se puede

observar que el tiempo máximo y mínimo empleado en registrar un plan de negocio es

de 40 y 35 minutos respectivamente, obteniendo un rango de 5.

126

En la siguiente tabla se muestra la distribución de frecuencias, el cual no se agrupa en

categorías debido a que la desviación estándar no es significativa.

Tabla 17 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO – TABLA DE FRECUENCIAS

Tiempo en registrar un plan de negocio Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

35 3 10,0 10,0 10,0

36 5 16,0 16,0 26,0

37 6 20,0 20,0 46,0

38 7 23,0 23,0 70,0

39 5 16,0 16,0 86,0

40 4 13,0 13,0 100,0

Total 30 100,0 100,0

127

B. Indiciador Situación

Se realizará el análisis estadístico descriptivo de los índices del

indicador Situación

1. Índice: Tiempo en calcular la variación del costo

Tabla 18 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - ESTADÍSTICA DESCRIPTIVA

Tiempo en calcular la variación del costo

Media 26,00

Mediana 26,00

Moda 26


Varianza 2,000

Rango 6

Mínimo 24

Máximo 30

Suma 799

En la tabla observamos que tanto el promedio como la mediana del índice

“Tiempo en calcular la variación del costo” es de 26 minutos; la moda es de 38

minutos, que representa el tiempo con mayor frecuencia y una desviación

estándar de 1, que representa cuan cercano o alejado se encuentran los datos

respecto a la media. También se puede observar que el tiempo máximo y mínimo

empleado en registrar un plan de negocio es de 30 y 24 minutos respectivamente,

obteniendo un rango de 6.

En la tabla se muestra la distribución de frecuencias, el cual no se agrupa en


Tabla 19 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - TABLA DE FRECUENCIAS

Tiempo en calcular la variación del costo Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

24 3 10,0 10,0 10,0

25 4 13,0 13,0 23,0

26 8 26,0 26,0 50,0

27 7 23,0 23,0 73,0

28 5 16,0 16,0 90,0

30 3 10,0 10,0 100,0

Total 30 100,0 100,0

128

2. Índice: Tiempo en calcular el índice de desempeño del

costo

Tabla 20 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO - ESTADÍSTICA

DESCRIPTIVA

Tiempo en calcular el índice de desempeño del costo

Media 20,00

Mediana 20,00

Moda 22


Varianza 2,000

Rango 5

Mínimo 17

Máximo 22

Suma 605

En la tabla observamos que el promedio del índice “Tiempo en calcular el índice del

desempeño del costo” es de 20 minutos, la mediana es de 20 minutos, que representa

el número medio de todos los tiempos de la muestra; la moda es de 22 minutos, que

representa el tiempo con mayor frecuencia y una desviación estándar de 1, que

representa cuan cercano o alejado se encuentran los datos respecto a la media.

También se puede observar que el tiempo máximo y mínimo empleado en registrar un

plan de negocio es de 22 y 17 minutos respectivamente, obteniendo un rango de 5.

En la siguiente tabla se muestra la distribución de frecuencias, el cual ha sido

agrupado en categorías individuales debido a que la desviación estándar no es

significativa:

Tabla 21 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO - TABLA DE

FRECUENCIAS

Tiempo en calcular el índice de desempeño del costo Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

17 1 3,0 3,0 3,0

18 4 13,0 13,0 16,0

19 8 26,0 26,0 43,0

20 5 16,0 16,0 60,0

22 12 40,0 40,0 100,0

Total 30 100,0 100,0

129

3. Índice: Tiempo en calcular la variación del cronograma


DESCRIPTIVA

Tiempo en calcular la variación del cronograma

Media 25,00

Mediana 26,00

Moda 26


Varianza 7,000

Rango 8

Mínimo 22

Máximo 30

Suma 775

En la tabla observamos que el promedio del índice “Tiempo en calcular la variación del

cronograma” es de 25 minutos, la mediana es de 26 minutos, que representa el

número medio de todos los tiempos de la muestra; la moda es de 26 minutos, que





En la tabla se muestra la distribución de frecuencias, el cual no se agrupa en


Tabla 23 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - TABLA DE FRECUENCIAS


Frecuencia Porcentaje Porcentaje

válido

Porcentaje

acumulado

22 3 10,0 10,0 10,0

23 5 16,0 16,0 26,0

24 4 13,0 13,0 40,0

26 8 26,0 26,0 66,0

28 5 16,0 16,0 83,0

30 5 16,0 16,0 100,0

Total 30 100,0 100,0

130


cronograma


ESTADÍSTICA DESCRIPTIVA

Tiempo en calcular el índice de desempeño del cronograma

Media 22,00

Mediana 23,00

Moda 23 a


Varianza 7,000

Rango 9

Mínimo 17

Máximo 26

Suma 683

a. Existen múltiples modos. Se muestra el valor más pequeño.

En la tabla observamos que el promedio del índice “Tiempo en calcular el índice del

desempeño del cronograma” es de 22 minutos, la mediana es de 23 minutos; la moda

es de 23 minutos, que representa el tiempo con mayor frecuencia y una desviación

estándar de 1.





significativa:

Tabla 25 TIEMPO EN CALCULAR EL ÍNDICE DEL DESEMPEÑO DEL CRONOGRAMA - TABLA DE

FRECUENCIAS

Tiempo en calcular el índice del desempeño del cronograma


válido

Porcentaje

acumulado

17 1 3,0 3,0 3,0

18 1 3,0 3,0 6,0

19 2 6,0 6,0 13,0

20 3 10,0 10,0 23,0

21 4 13,0 13,0 36,0

23 7 23,0 23,0 60,0

25 7 23,0 23,0 83,0

26 5 16,0 16,0 100,0

Total 30 100,0 100,0

131

C. Indicador Avance del trabajo

1. Índice: Tiempo en calcular el porcentaje de la variación

del costo



Tiempo en calcular el porcentaje de la variación del costo

Media 28,00

Mediana 28,00

Moda 28a


Varianza 2,000

Rango 6

Mínimo 25

Máximo 31

Suma 852


En la tabla observamos que tanto el promedio como la mediana del índice “Tiempo en

calcular el porcentaje de la variación del costo” es de 28 minutos; la moda es de 28

minutos, que representa el tiempo con mayor frecuencia y una desviación estándar de

1, que representa cuan cercano o alejado se encuentran los datos respecto a la media.


plan de negocio es de 31 y 25 minutos respectivamente, obteniendo un rango de 6. En

la tabla se muestra la distribución de frecuencias, el cual no se agrupa en categorías

debido a que la desviación estándar no es significativa.

Tabla 27 TIEMPO EN CALCULAR EL PORCENTAJE DE LA VARIACIÓN DEL COSTO - TABLA DE

FRECUENCIAS

Tiempo en calcular el porcentaje de la

variación del costo Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

25 1 3,0 3,0 3,0

26 3 10,0 10,0 13,0

27 4 13,0 13,0 26,0

28 7 23,0 23,0 50,0

29 7 23,0 23,0 73,0

30 6 20,0 20,0 93,0

31 2 6,0 6,0 100,0

Total 30 100,0 100,0

132


del cronograma

Tabla 28 TIEMPO EN CALCULAR EL PORCENTAJE DE LA VARIACIÓN DEL CRONOGRAMA -


Tiempo en calcular el porcentaje de la variación del cronograma

Media 33,00

Mediana 34,00

Moda 33a


Varianza 4,047

Rango 6

Mínimo 30

Máximo 36

Suma 1003


En la tabla observamos que el promedio del índice “Tiempo en calcular el porcentaje

de la variación del cronograma” es de 33 minutos, con una mediana de 34 minutos, la

moda es de 33 minutos, que representa el tiempo con mayor frecuencia y una

desviación estándar de 2.012, que representa cuan cercano o alejado se encuentran

los datos respecto a la media. También se puede observar que el tiempo máximo y

mínimo empleado en registrar un plan de negocio es de 36 y 30 minutos

respectivamente, obteniendo un rango de 6.



significativa:


TABLA DE FRECUENCIAS

Tiempo en calcular el porcentaje de la variación del

cronograma Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

30 3 10,0 10,0 10,0

31 5 16,0 16,0 26,0

33 6 20,0 20,0 46,0

34 6 20,0 20,0 66,0

35 4 13,0 13,0 80,0

36 6 20,0 20,0 100,0

Total 30 100,0 100,0

133

4.4.2. Grupo experimental

A continuación se realizará el análisis estadístico descriptivo de los

datos obtenidos de las muestras, 30 planes de negocio, después de

usar la aplicación web, es decir la Post-test, utilizando la herramienta

estadística SPSS.

A. Indicador Eficiencia


indicador Eficiencia.

1. Índice: Tiempo en registrar un plan de negocio

Al realizar un análisis exhaustivo de los datos conseguidos de

las muestras se obtienen los siguientes resultados:

Tabla 30 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - ESTADÍSTICA DESCRIPTIVA

Tiempo en registrar un plan de negocio

Media 16,00

Mediana 16,00

Moda 16


Varianza 3,000

Rango 7

Mínimo 13

Máximo 20

Suma 491

En la tabla observamos que el promedio del índice “Tiempo en registrar un plan de

negocio” es de 16 minutos, la mediana es de 16 minutos, que representa el número



cercano o alejado se encuentran los datos respecto a la media.



134



significativa:

Tabla 31 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - TABLA DE FRECUENCIAS

Tiempo en registrar un plan de negocio Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

13 2 6,0 6,0 6,0

14 3 10,0 10,0 16,0

15 5 16,0 16,0 33,0

16 7 23,0 23,0 56,0

17 6 20,0 20,0 76,0

19 6 20,0 20,0 96,0

20 1 3,0 3,0 100,0

Total 30 100,0 100,0

135

B. Indiciador Situación


indicador Situación.

1. Índice: Tiempo en calcular la variación del costo

Tabla 32 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - ESTADÍSTICA DESCRIPTIVA

Tiempo en calcular la variación del costo

Media 15,00

Mediana 15,00

Moda 15


Varianza 1,000

Rango 4

Mínimo 13

Máximo 17

Suma 455


costo” es de 15 minutos, la mediana es de 15 minutos, que representa el número



cercano o alejado se encuentran los datos respecto a la media. También se puede

observar que el tiempo máximo y mínimo empleado en registrar un plan de negocio es

de 17 y 13 minutos respectivamente, obteniendo un rango de 4.



significativa:

Tabla 33 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - TABLA DE FRECUENCIAS

Tiempo en calcular la variación del costo Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

13 3 10,0 10,0 10,0

14 6 20,0 20,0 30,0

15 9 30,0 30,0 60,0

16 7 23,0 23,0 83,0

17 5 16,0 16,0 100,0

Total 30 100,0 100,0

136


costo

Tabla 34 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO- ESTADÍSTICA

DESCRIPTIVA

Tiempo en calcular el índice de desempeño del costo

Media 12,00

Mediana 13,00

Moda 12a


Varianza 1,082

Rango 4

Mínimo 10

Máximo 14

Suma 377


En la tabla observamos que el promedio del índice “Tiempo en calcular el índice de

desempeño del costo” es de 16 minutos, la mediana es de 16 minutos, que representa

el número medio de todos los tiempos de la muestra; la moda es de 16 minutos, que







significativa:

Tabla 35 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO - TABLA DE

FRECUENCIAS

Tiempo en calcular el índice

de desempeño del costo Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

10 1 3,0 3,0 3,0

11 3 10,0 10,0 13,0

12 10 33,0 33,0 46,0

13 10 33,0 33,0 80,0

14 6 20,0 20,0 100,0

Total 30 100,0 100,0

137

3. Índice: Tiempo en calcular la variación del cronograma


DESCRIPTIVA


Media 15,00

Mediana 16,00

Moda 14


Varianza 2,000

Rango 4

Mínimo 14

Máximo 18

Suma 477


cronograma” es de 15 minutos, la mediana es de 16 minutos, que representa el

número medio de todos los tiempos de la muestra; la moda es de 14 minutos, que







significativa:

Tabla 37 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - TABLA DE FRECUENCIAS

Tiempo en calcular la variación del cronograma Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

14 8 26,0 26,0 26,0

15 5 16,0 16,0 43,0

16 6 20,0 20,0 63,0

17 4 13,0 13,0 76,0

18 7 23,0 23,0 100,0

Total 30 100,0 100,0

138


cronograma



Tiempo en calcular el índice de desempeño del cronograma

Media 11,00

Mediana 12,00

Moda 11


Varianza 1,000

Rango 4

Mínimo 10

Máximo 14

Suma 355

En la tabla observamos que el promedio del índice “Tiempo en calcular el índice de

desempeño del cronograma” es de 16 minutos, la mediana es de 16 minutos, que

representa el número medio de todos los tiempos de la muestra; la moda es de 16







significativa:

Tabla 39 TIEMPO EN CALCULAR EL ÍNDICE DEL DESEMPEÑO DEL CRONOGRAMA - TABLA DE

FRECUENCIAS

Tiempo en calcular el índice de desempeño del

cronograma Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

10 3 10,0 10,0 10,0

11 10 33,0 33,0 43,0

12 7 23,0 23,0 66,0

13 9 30,0 30,0 96,0

14 1 3,0 3,0 100,0

Total 30 100,0 100,0

139

C. Indicador Avance del trabajo


del costo



Tiempo en calcular el porcentaje de la variación del costo

Media 15,00

Mediana 16,00

Moda 14


Varianza 2,000

Rango 4

Mínimo 14

Máximo 18

Suma 477


de la variación del costo” es de 15 minutos, la mediana es de 16 minutos, que








significativa:

Tabla 41 TIEMPO EN CALCULAR EL PORCENTAJE DE LA VARIACIÓN DEL COSTO - TABLA DE

FRECUENCIAS

Tiempo en calcular el porcentaje de la variación

del costo Frecuencia Porcentaje

Porcentaje

válido

Porcentaje

acumulado

14 8 26,0 26,0 26,0

15 5 16,0 16,0 43,0

16 6 20,0 20,0 63,0

17 4 13,0 13,0 76,0

18 7 23,0 23,0 100,0

Total 30 100,0 100,0

140


del cronograma



Tiempo en calcular el porcentaje de la variación del cronograma

Media 14,00

Mediana 15,00

Moda 13a


Varianza 1,000

Rango 4

Mínimo 13

Máximo 17

Suma 443



de la variación del cronograma” es de 14 minutos, la mediana es de 15 minutos, que








significativa:


TABLA DE FRECUENCIAS

Tiempo en calcular el porcentaje de la

variación del cronograma


válido

Porcentaje

acumulado

13 7 23,0 23,0 23,0

14 6 20,0 20,0 43,0

15 7 23,0 23,0 66,0

16 7 23,0 23,0 90,0

17 3 10,0 10,0 100,0

Total 30 100,0 100,0

141

4.5. Prueba de hipótesis

Una hipótesis en el contexto de la estadística inferencial es una proposición

respecto a uno o varios parámetros, y lo que el investigador hace a través de la

prueba de hipótesis, es determinar si la hipótesis es consistente con los datos

obtenidos en la muestra, para ello, a continuación se formula la hipótesis de

investigación, la hipótesis nula y las correspondientes estadísticas.

4.5.1. Hipótesis de investigación

Hi: La aplicación web mejorará el registro y monitoreo de planes de

negocio del Programa de Apoyo a las Alianzas Rurales productivas de

la Sierra – ALIADOS del Ministerio de Agricultura – 2013.

4.5.2. Hipótesis nula

H0: La aplicación web no mejorará el registro y monitoreo de planes de

negocio del Programa de Apoyo a las Alianzas Rurales productivas de

la Sierra – ALIADOS del Ministerio de Agricultura – 2013.

4.5.3. Hipótesis estadística

Hi: GEX GC

Existe una mejora en el grupo experimental (GE) utilizando la variable

independiente (X) (aplicación web) respecto al grupo de control (GC).

H0: GEX GC

No existe una mejora en el grupo experimental (GE) utilizando la

variable independiente (X) (aplicación web) respecto al grupo de control

(GC)

142

4.6. Prueba de estadística utilizada

El siguiente cuadro de pruebas estadísticas se divide de acuerdo al tipo de

variable, el cuadro es específicamente para investigaciones con un “Objetivo

comparativo”.

Tabla 44 TABLA DE PRUEBAS ESTADÍSTICAS CON UN OBJETIVO COMPARATIVO

Pruebas no paramétricas Pruebas

paramétricas

Variable aleatoria

Variable fija

Normal dicotómica

Nominal politómica

Ordinal Numérica

Estudio Transversal

Muestras independientes

Un grupo X2 Bondad de

Ajuste Binominal

X2 Bondad de Ajuste

X2 Bondad

de Ajuste

T de Student para una muestra

Dos grupos

X2 de Homogenidad Corrección de

Yates Test exacto de

Fisher

X2 de Homogeneidad

U Mann-Withney

T de Student para muestras independientes

Más de 2 grupos

X2 de Homogeneidad

X2 de Homogeneidad

H Kruskal-Wallis

ANOVA con un factor

INTERsujetos

Estudio Longitudinal

Muestras relacionadas

Dos medias

MC Nemar Q de Cochran Wilcoxon T de Student

para muestras relacionadas

Más de dos

medias Q de Cochran Q de Cochran Friedman

ANOVA para medidas repetidas

A continuación se realiza un resumen de las características necesarias para

seleccionar la prueba estadística que sea compatible con la investigación:

a) Tipo de investigación: Aplicada.

b) Nivel de investigación: Descriptivo y correlacional.

c) Diseño de la investigación: Cuasi-experimental.

d) Tipo de datos: Numéricos

e) Total de muestra: n=30; estadísticamente es un valor bajo.

f) Tipo de muestra: Relacional; debido a que se realiza pruebas Pre-Test

y Post-Test a la misma muestra.

143

Según las características de la investigación y utilizando la tabla de pruebas

estadísticas se contrasta que la prueba más compatible es “T de Student para

muestras relacionadas”

La prueba T de Student para muestras relacionadas se restringe a la

comprobación de los siguientes supuestos:

1º. Variable dependiente (Y) debe ser cuantitativa.

2º. Las muestras debe tener una distribución normal.

3º. Independencia de las observaciones.

Si no se cumple los supuestos mencionados no se puede utilizar la prueba T de

Student, en tal caso es necesario utilizar la prueba estadística no paramétrica

equivalente al T de Student para muestras relacionadas, es decir: Prueba de

Wilcoxon.

Según el análisis realizado hasta este punto podemos afirmar que el supuesto

1º y 3º se cumplen, de manera que solo queda comprobar el 2º supuesto: Las

muestras deben tener una distribución normal.

Por tanto se concluye que según las características de la investigación es

necesario utilizar la prueba T de Student para muestras relacionadas,

mientras se compruebe el cumplimiento del 2º supuesto y en caso de no

hacerlo se utilizará la Prueba de Wilcoxon. Todo esto se realizará utilizando el

paquete estadístico SPSS.

144

4.6.1. Prueba de hipótesis para el indicador Eficiencia

A. Índice: Tiempo en registrar un plan de negocio

1. Comprobando la normalidad de la muestra

H0: La muestra proviene de una distribución normal.

Hi: La muestra No proviene de la una distribución normal.

Tabla 45 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - PRUEBA DE NORMALIDAD

Shapiro-Wilk

Estadístico gl Sig.

Grupo de Control ,000 30 ,065

Grupo

Experimental ,000 30 ,081

Al ser la significancia (sig.) mayor a 0.05 en ambas muestras,

podemos concluir en que se acepta la Hipótesis nula: “Las muestras

provienen de una distribución normal”.

145

2. Hipótesis de contraste y Prueba estadística

Hi: La operatividad de la aplicación web mejora el tiempo en

registrar un plan de negocio.

H0: La operatividad de la aplicación web no mejora el tiempo en

registrar un plan de negocio.

El contraste de la hipótesis es Unilateral Derecho ya que se

espera que después de utilizar la aplicación web el tiempo

empleado en registrar un plan de negocio disminuya y se

utilizará la prueba T de Student para muestras relacionadas.

Tabla 46 TIEMPO EN REGISTRAR UN PLAN DE NEGOCIO - PRUEBA T DE STUDENT PARA

MUESTRAS RELACIONADAS

Diferencias emparejadas

t gl Sig. (bilateral) Media

Desviación estándar

Media de error

estándar

95% de intervalo de confianza de la

diferencia

Inferior Superior

GC - GE 21,000 2,000 ,000 20,000 22,000 43,0 29 ,000

Dónde:

GC: Grupo de Control

GE: Grupo Experimental

Media: media de la diferencia de medias de GC y GE.

Desviación estándar: desviación de la diferencia de medias

de GC y GE.

Media de error estándar: media de error estándar de la

diferencia de medias de GC y GE.

t: valor estadístico de contraste.

gl: grados de libertad.

Sig. (bilateral): significancia de la prueba T de Student para

muestras relacionadas.

146

3. Interpretación de resultados

Obteniendo la tabla resultado por el paquete estadístico SPSS

nos toca comprobar que en la Media de la diferencia entre el

GC y GE (21.000) existe una diferencia estadísticamente

significativa debido a la Variable Independiente (operatividad).

El valor estadístico de contraste es de 43.0 con 29 grados de

libertad y una significación (sig.) bilateral de 0.000 (el valor no

es exactamente 0, pero es un número tan bajo que es

preferible mostrarlo de esta manera).

Al ser el contraste planteado Unilateral derecho se divide la

significancia obtenida entre 2 y siendo este menor a 0.05 se

rechaza la Hipótesis Nula, por tanto podemos concluir que

existen diferencias significativas entre las medias del GC y el

GE, es decir que la operatividad de la aplicación web mejora el

tiempo en registrar un plan de negocio.

La prueba T de Student para muestras relacionadas demuestra

estadísticamente que existe una diferencia significativa en el

tiempo necesario para registrar un plan de negocio entre el

grupo de control y el grupo experimental al utilizar la aplicación

web, reduciendo el tiempo promedio de 37 a 16 minutos, es

decir una reducción en promedio de 21 minutos.

147

4.6.2. Prueba de hipótesis para el indicador Situación

A. Índice: Tiempo en calcular la Variación del Costo




Tabla 47 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - PRUEBA DE NORMALIDAD

Shapiro-Wilk



Grupo


Al ser la significancia (sig.) mayor a 0.05 en el grupo de control

(0.051) y menor en el grupo experimental (0.023), podemos

concluir en que se rechaza la Hipótesis nula, es decir: “Las

muestras no provienen de una distribución normal”.


Hi: La exactitud de la aplicación web mejora el tiempo en que

se calcula la variación del costo.

H0: La exactitud de la aplicación web no mejora el tiempo en

que se calcula la variación del costo.



empleado en calcular la variación del costo disminuya y se

utilizará la prueba de Wilcoxon.

Tabla 48 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - PRUEBA DE WILCOXON

(RANGOS)

N

Rango

promedio

Suma de

rangos

GE - GC

Rangos

negativos 30

a 15,00 465,00

Rangos positivos 0b ,00 ,00

Empates 0c

Total 30

148

Tabla 49 TIEMPO EN CALCULAR LA VARIACIÓN DEL COSTO - PRUEBA DE WILCOXON

(ESTADÍSTICOS DE PRUEBA)

GE - GC

Z -4,000

Sig. asintótica

(bilateral) ,000002

Dónde:

Z: es la transformación del valor T de Wilcoxon (valor

estadístico de contraste).

Sig. asintótica (bilateral): es la significación de la prueba.



nos toca comprobar existe una diferencia estadísticamente

significativa debido a la Variable Independiente (exactitud).

La suma de rangos solo se realizó en los rangos negativos, es

decir que todas las muestras experimentales se realizaron en

un menor tiempo que las muestras de control.


significancia obtenida (0,000002) entre 2 y al ser esta menor a

0.05 se rechaza la Hipótesis Nula, por tanto podemos concluir

que existen diferencias significativas entre las muestras del GC

y el GE, es decir que la exactitud de la aplicación web mejora el

tiempo en que se calcula la variación del costo.

La prueba de Wilcoxon demuestra estadísticamente que existe

una diferencia significativa en el tiempo necesario para calcular

la Variación del costo entre el grupo de control y el grupo

experimental al utilizar la aplicación web, reduciendo el tiempo

promedio de 26 a 15 minutos, es decir una reducción en

promedio de 11 minutos.

149

B. Índice: Tiempo en calcular el Índice de desempeño del costo




Tabla 50 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL COSTO - PRUEBA DE

NORMALIDAD

Shapiro-Wilk



Grupo


Al ser la significancia (sig.) menor a 0.05 en ambos grupos, podemos

concluir en que se rechaza la Hipótesis nula, es decir: “Las muestras

no provienen de una distribución normal”.



se calcula el índice de desempeño del costo.


que se calcula el índice de desempeño del costo.



empleado en calcular el porcentaje de la variación del costo

disminuya y se utilizará la prueba de Wilcoxon.


WILCOXON (RANGOS)

N

Rango

promedio

Suma de

rangos

GE - GC

Rangos

negativos 30 15,00 465,00

Rangos positivos 0 ,00 ,00

Empates 0

Total 30

150


WILCOXON (ESTADÍSTICOS DE PRUEBA)

GE - GC

Z -4,000

Sig. asintótica

(bilateral) ,000002

Dónde:
















tiempo en que se calcula el índice de desempeño del costo.



el índice de desempeño del costo entre el grupo de control y el

grupo experimental al utilizar la aplicación web, reduciendo el

tiempo promedio de 22 a 11 minutos, es decir una reducción en


151

C. Índice: Tiempo en calcular la Variación del Cronograma





NORMALIDAD

Shapiro-Wilk



Grupo


Al ser la significancia (sig.) menor a 0.05 en ambos grupos,

podemos concluir en que se rechaza la Hipótesis nula, es decir:

“Las muestras no provienen de una distribución normal”.



se calcula la variación del cronograma.


que se calcula la variación del cronograma.





Tabla 54 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - PRUEBA DE WILCOXON

(RANGOS)

N

Rango

promedio

Suma de

rangos

GE - GC

Rangos

negativos 30 15,00 465,00


Empates 0

Total 30

152

Tabla 55 TIEMPO EN CALCULAR LA VARIACIÓN DEL CRONOGRAMA - PRUEBA DE WILCOXON

(ESTADÍSTICOS DE PRUEBA)

GE - GC

Z -4,000

Sig. asintótica

(bilateral) ,000002

Dónde:
















tiempo en que se calcula la variación del cronograma.



la Variación del cronograma entre el grupo de control y el grupo

experimental al utilizar la aplicación web, reduciendo el tiempo

promedio de 25 a 15 minutos, es decir una reducción en


153

D. Índice: Tiempo en calcular el Índice de desempeño del

cronograma




Tabla 56 TIEMPO EN CALCULAR EL ÍNDICE DE DESEMPEÑO DEL CRONOGRAMA - PRUEBA DE

NORMALIDAD

Shapiro-Wilk



Grupo







se calcula el índice de desempeño del cronograma.


que se calcula el índice de desempeño del cronograma.






WILCOXON (RANGOS)

N

Rango

promedio

Suma de

rangos

GE - GC

Rangos

negativos 30 15,00 465,00


Empates 0

Total 30

154



GE - GC

Z -4,000

Sig. asintótica

(bilateral) ,000002

Dónde:










un menor tiempo que las muestras de control, tal como nos

sugiere el SPSS (a. GE < GC).






tiempo en que se calcula el índice de desempeño del

cronograma.



el índice de desempeño del cronograma entre el grupo de

control y el grupo experimental al utilizar la aplicación web,

reduciendo el tiempo promedio de 20 a 12 minutos, es decir

una reducción en promedio de 8 minutos.

155

4.6.3. Prueba de hipótesis para el indicador Avance del trabajo

A. Índice: Tiempo en calcular el porcentaje de la Variación del

Costo




Tabla 59 TIEMPO EN CALCULAR EL PORCENTAJE DE LA VARIACIÓN DEL COSTO - PRUEBA DE

NORMALIDAD

Shapiro-Wilk



Grupo







se calcula el porcentaje de la variación del costo.


que se calcula el porcentaje de la variación del costo.






WILCOXON (RANGOS)

N

Rango

promedio

Suma de

rangos

GE - GC

Rangos

negativos 30 15,00 465,00


Empates 0

Total 30

156



GE - GC

Z -4,000

Sig. asintótica

(bilateral) ,000002

Dónde:
















tiempo en que se calcula el porcentaje de la variación del

costo.



el porcentaje de la Variación del costo entre el grupo de control

y el grupo experimental al utilizar la aplicación web, reduciendo

el tiempo promedio de 28 a 15 minutos, es decir una reducción

en promedio de 13 minutos.

157

B. Índice: Tiempo en calcular el porcentaje de la Variación del

Cronograma





PRUEBA DE NORMALIDAD

Shapiro-Wilk



Grupo







se calcula el porcentaje de la variación del cronograma.


que se calcula el porcentaje de la variación del cronograma.






PRUEBA DE WILCOXON (RANGOS)

N

Rango

promedio

Suma de

rangos

GE - GC

Rangos

negativos 30 15,00 465,00


Empates 0

Total 30

158


PRUEBA DE WILCOXON (ESTADÍSTICOS DE PRUEBA)

GE - GC

Z -4,000

Sig. asintótica

(bilateral) ,000002

Dónde:










un menor tiempo que las muestras de control, tal como nos

sugiere el SPSS (a. GE < GC).






tiempo en que se calcula el porcentaje de la variación del

cronograma.



el porcentaje de la Variación del cronograma entre el grupo de

control y el grupo experimental al utilizar la aplicación web,

reduciendo el tiempo promedio de 33 a 14 minutos, es decir

una reducción en promedio de 19 minutos.

159

CAPITULO V

CONCLUSIONES Y RECOMENDACIONES

Como conclusiones y recomendaciones obtenidas en el desarrollo se la presente

investigación se tiene:

5.1. Conclusiones

Al realizar el análisis correspondiente a los resultados obtenidos en las pruebas

estadísticas se obtiene que:

1. La operatividad de la aplicación web mejora la eficiencia del registro de

planes de negocio reduciendo el tiempo empleado en este proceso.

2. La exactitud de la aplicación web mejora la situación de planes de

negocio reduciendo el tiempo necesario para calcular los indicadores de

la Gestión de Valor Ganado: Variación del costo (CV), Índice de

desempeño del costo (CPI), la variación del cronograma (SV) e índice

de desempeño del cronograma (SPI).

3. La exactitud de la aplicación web mejora el avance del trabajo de planes

de negocio reduciendo el tiempo necesario para calcular los indicadores

de la Gestión de Valor Ganado: el porcentaje de variación del costo

(CV%) y el porcentaje de variación del cronograma (SV%).

Por tanto se concluye que el uso de la aplicación web si mejora el registro y

monitoreo de planes de negocio en el Programa de Apoyo a las Alianzas

Rurales productivas de la Sierra – ALIADOS del Ministerio de Agricultura.

160

5.2. Recomendaciones

1. Realizar un nuevo análisis contando con una mayor población para obtener

datos estadísticos con menos margen de error en las muestras.

2. Realizar un estudio para mejorar el comportamiento en el tiempo y en los

recursos de las aplicaciones.

3. Implementar un módulo de evaluación de planes de negocio.

4. Implementar una gestión de monitoreo diferente a la Gestión del valor

Ganado (EVM).

5. Tomar como base el presente trabajo para la construcción de un Sistema

de Monitoreo y Evaluación basados en Resultados (SMER).

161

FUENTES DE INFORMACIÓN

LIBROS

1. Hernández Sampieri R, Fernández Callado C, Baptista Lucio P.

Metodología de la investigación. 5th ed. México D.F.: McGraw-Hill, S.A.

de C.V.; 2010.

2. Tamayo y Tamayo M. El proceso de la investigación. 4th ed. México D.F.:

Limusa, S.A. de C.V.; 2004.

3. Lipschutz S. Teoría de conjuntos y temas afines. México D.F.: McGraw-

Hill, S.A. de C.V.; 1991.

4. Luján Mora S. Programación de aplicaciones web: historia, principios

básicos y clientes web San Vicente.: Club Universitario; 2002.

5. Project Manager Institute. Guía de los Fundamentos para la Dirección de

Proyectos (Guía del PMBOK®). 5th ed. Pensilvania: Project Manager

Institute; 2013.

6. M. G. Patterns in Java: A catalog of reusable design patterns illustrated

with UML. 2nd ed. Nueva York: John Wiley & Sons Ltd.; 2002.

7. Wright T. Learning JavaScript A hand-On guide to the Fundamentals of

Modern JavaScript. Nueva Jersey: Pearson Education, Inc.; 2012.

8. Leiter C, Dan W, Michael C, Albert B. Beginning Microsoft SQL Server

2008 Administration. Indiana: Wiley Publishing Inc.; 2013.

9. Kappel G, Proll B, Reich S, Retschitzegger W. Web Engineering – The

Disipline of Systematic Development of Web Applications. Nueva York:

John Wiley & Sons Ltd.; 2006.

10. Rossi G, Pastor O, Schwabe D, Olsina L. Web Engineering: Modeling and

Implementing Web Applications. Londres: Springer; 2008.

162

TESIS

1. Gloria Elizabeth Ayala Ayala, Mayela Beatriz Campos López, Cristina Ivette

Cuellar Batres, Liliana María Flores Cruz. “SISTEMA INFORMÁTICO DE

MONITOREO Y CONTROL DE LOS PROYECTOS EN LA FUNDACIÓN

PARA LA COOPERACIÓN Y DESARROLLO COMUNAL EN EL

SALVADOR”. El Salvador 2011.

2. Evelyn Lindsay Ocampo Moreno, Carlos Gonzáles Cajahuanca.

“HERRAMIENTA PARA GESTIÓN DE PROYECTOS BASADA EN XPDL

PARA EL PROYECTO COMPETISOOFT CONSTRUCCIÓN, PRUEBAS E

INTEGRACIÓN”. Perú 2011.

3. Jackeline Rocio Toledo Rosales. “IMPLEMENTACIÓN DE UNA

HERRAMIENTA DE GESTIÓN DE PROYECTOS EN EL ÁREA DE

SISTEMAS E INFORMÁTICA DE UNA EMPRESA DE

TELECOMUNICACIONES”. Perú 2012.

ARTÍCULOS

1. Oficina Regional de la FAO para América Latina y el Caribe. Rol del estado y

la sociedad Civil en la generación de valor público. Oficina Regional de la

FAO para América Latina y el Caribe; 2013

2. AGRORURAL. Plan de Negocio Rural. ALIADOS; 2012

ARTÍCULOS DE INTERNET

1. Team GC. Evolution of the web. [Online].; 2012 [citado el 2013 Octubre 23.

Disponible En: www.evolutionoftheweb.com.

2. Microsoft. Microsoft Developer Network. [Online].; 2003 [citado el 2013

octubre 29. Disponible En: http://msdn.microsoft.com/en-

us/library/ff649643.aspx.

3. Microsoft. Microsoft Developer Network. [Online].; 2003 [citado el 2013

octubre 29. Disponible En: http://msdn.microsoft.com/en-

us/library/ms978717.aspx.

4. PHP.net. Centro principal de recursos pata desarrolladores PHP. [Online].;

2013 [citado el 2013 septiembre 25. Disponible En:

http://us1.php.net/manual/es/intro-whatis.php.

5. Berners-Lee T. World Wide Web Consortium. [Online].; 2013 [citado el 2013

septiembre 28. Disponible En: http://www.w3.org/2006/rwc/Activity.html.

www.evolutionoftheweb.com





http://us1.php.net/manual/es/intro-whatis.php

http://www.w3.org/2006/rwc/Activity.html

ANEXOS

Anexo 1 MATRIZ DE CONSISTENCIA

Título: “APLICACIÓN WEB PARA EL APOYO DEL REGISTRO Y MONITOREO DE PLANES DE NEGOCIO DEL PROGRAMA ALIANZAS RURALES

PRODUCTIVAS DE LA SIERRA - ALIADOS DEL MINISTERIO DE AGRICULTURA – 2013"

PROBLEMA OBJETIVOS HIPÓTESIS VARIABLES

INDICADORES ÍNDICES MÉTODOS TÉCNICAS INSTRUMENTOS Problema Principal Objetivo General Hipótesis General

¿De qué manera una aplicación web apoyará al registro y monitoreo de planes de negocio del Programa Alianzas Rurales Productivas de la Sierra – ALIADOS del Ministerio de Agricultura - 2013?

Determinar como una aplicación web apoyará al registro y monitoreo de planes de negocio del Programa Alianzas Rurales Productivas de la Sierra – ALIADOS del Ministerio de Agricultura - 2013

La aplicación web mejorará el registro y monitoreo de planes de negocio del Programa de Apoyo a las Alianzas Rurales productivas de la Sierra – ALIADOS del Ministerio de Agricultura – 2013.

INDEPENDIENTE:

Aplicación web

Operatividad Número de intentos del usuario en realizar una tarea.

Tipo de Investigación:

Aplicada Nivel de investigación:

Descriptivo Diseño de la investigación:

Cuasi experimental Universo:

Planes de negocios cofinanciados por instituciones del estado. Población:

30 planes de negocio del programa ALIADOS Muestra:

30 planes de negocio

Observación

Fichas de registro

Software de

gestión de proyectos

Software

estadístico

Exactitud Número de tareas ejecutadas correctamente

DEPENDIENTE:

Registro y Monitoreo de planes de negocio

Eficiencia Tiempo en registrar un plan de negocio

Situación

Tiempo en calcular la Variación del costo (CV). Tiempo en calcular el Índice de desempeño del costo (CPI). Tiempo en calcular la Variación del cronograma (SV) Tiempo en calcular el Índice de desempeño del cronograma (SPI).

Problemas específicos

Objetivos Específicos

Hipótesis específicas

1. ¿Cómo la operatividad de la aplicación web mejora la eficiencia del registro de planes de negocio? 2. ¿Cómo la exactitud de la aplicación web mejora la situación de los planes de negocio? 3. ¿Cómo la exactitud de la aplicación web mejora el avance del trabajo de los planes de negocio?

1. Determinar como la operatividad de la aplicación web mejora la eficiencia del registro de planes de negocio 2. Determinar como la exactitud de la aplicación web mejora la situación de planes de negocio. 3. Determinar como la exactitud de la aplicación web mejora el avance del trabajo de los planes de negocio.

1. La operatividad de la aplicación web mejorará la eficiencia del registro de planes de negocio. 2. La exactitud de la aplicación web mejorará la situación de los planes de negocio. 3. La exactitud de la aplicación web mejorará el avance del trabajo de los planes de negocio.

Avance del trabajo

Tiempo en calcular el Porcentaje de variación del costo (CV%). Tiempo en calcular el Porcentaje de Variación del cronograma (SV%).

Anexo 2 GRUPO DE CONTROL INDICADOR DE EFICIENCIA

Muestra de “Tiempo en registrar un plan de negocio”

Plan Tiempo en registrar un plan de negocio (minutos)

1 36

2 36

3 39

4 40

5 37

6 37

7 38

8 40

9 35

10 38

11 35

12 38

13 36

14 36

15 38

16 39

17 37

18 38

19 37

20 38

21 38

22 39

23 37

24 37

25 36

26 39

27 35

28 39

29 40

30 40

Anexo 3 GRUPO DE CONTROL INDICADOR DE SITUACIÓN

Muestra de “Tiempo en calcular la variación del costo”

Plan Tiempo en calcular la variación del costo (minutos)

1 27

2 24

3 26

4 30

5 30

6 27

7 26

8 25

9 27

10 30

11 25

12 25

13 26

14 28

15 26

16 27

17 25

18 27

19 28

20 28

21 26

22 24

23 27

24 26

25 24

26 27

27 26

28 28

29 28

30 26


Muestra de “Tiempo en calcular el porcentaje de la variación del costo”

Plan Tiempo en calcular el porcentaje de la variación

del costo (minutos)

1 28

2 28

3 30

4 29

5 30

6 29

7 30

8 29

9 30

10 29

11 26

12 29

13 31

14 30

15 28

16 28

17 28

18 27

19 27

20 25

21 29

22 27

23 30

24 26

25 28

26 29

27 26

28 28

29 31

30 27


Muestra de “Tiempo en calcular la variación del cronograma”

Plan Tiempo en calcular la variación del cronograma

(minutos)

1 26

2 28

3 24

4 22

5 22

6 28

7 30

8 23

9 26

10 26

11 23

12 30

13 24

14 30

15 28

16 28

17 26

18 26

19 23

20 23

21 30

22 26

23 22

24 24

25 28

26 30

27 24

28 26

29 23

30 26


Muestra de “Tiempo en calcular el porcentaje de la variación del cronograma”


del cronograma (minutos)

1 33

2 34

3 36

4 30

5 36

6 34

7 30

8 36

9 35

10 31

11 33

12 34

13 31

14 30

15 33

16 35

17 31

18 34

19 33

20 31

21 35

22 33

23 36

24 34

25 35

26 34

27 31

28 36

29 36

30 33

Anexo 7 GRUPO DE CONTROL INDICADOR DE AVANCE DEL TRABAJO

Muestra de “Tiempo en calcular el índice de desempeño del costo”

Plan Tiempo en calcular el índice de desempeño del

costo (minutos)

1 22

2 19

3 20

4 22

5 20

6 18

7 22

8 22

9 18

10 20

11 22

12 17

13 22

14 22

15 20

16 19

17 19

18 22

19 22

20 19

21 20

22 18

23 19

24 22

25 22

26 19

27 22

28 19

29 18

30 19

Anexo 8 GRUPO DE CONTROL INDICADOR DE AVANCE DEL TRABAJO

Muestra de “Tiempo en calcular el índice de desempeño del cronograma”


cronograma (minutos)

1 23

2 21

3 21

4 25

5 26

6 25

7 23

8 26

9 25

10 25

11 26

12 23

13 19

14 20

15 26

16 20

17 26

18 25

19 25

20 21

21 21

22 23

23 18

24 20

25 23

26 17

27 25

28 23

29 23

30 19

Anexo 9 GRUPO EXPERIMENTAL INDICADOR DE EFICIENCIA Muestra de “Tiempo en registrar un plan de negocio”

Plan Tiempo en registrar un plan de negocio (minutos)

1 14

2 17

3 19

4 16

5 17

6 19

7 19

8 19

9 13

10 14

11 19

12 16

13 16

14 20

15 16

16 14

17 15

18 16

19 17

20 15

21 15

22 16

23 17

24 17

25 19

26 13

27 17

28 16

29 15

30 15

Anexo 10 GRUPO EXPERIMENTAL INDICADOR DE SITUACIÓN

Muestra de “Tiempo en calcular la variación del costo”

Plan Tiempo en calcular la variación del costo (minutos)

1 13

2 16

3 15

4 13

5 16

6 14

7 15

8 16

9 13

10 16

11 16

12 14

13 16

14 15

15 17

16 17

17 17

18 17

19 15

20 17

21 16

22 14

23 15

24 15

25 14

26 15

27 14

28 15

29 14

30 15


Muestra de “Tiempo en calcular el porcentaje de la variación del costo”


del costo (minutos)

1 17

2 16

3 18

4 15

5 14

6 14

7 18

8 18

9 16

10 14

11 15

12 14

13 18

14 14

15 14

16 15

17 17

18 15

19 17

20 14

21 18

22 14

23 16

24 15

25 18

26 16

27 17

28 16

29 18

30 16


Muestra de “Tiempo en calcular la variación del cronograma”

Plan Tiempo en calcular la variación del cronograma

(minutos)

1 18

2 16

3 16

4 15

5 14

6 14

7 18

8 18

9 16

10 16

11 17

12 16

13 18

14 14

15 14

16 15

17 17

18 17

19 17

20 14

21 18

22 15

23 16

24 15

25 15

26 14

27 14

28 14

29 18

30 18


Muestra de “Tiempo en calcular el porcentaje de la variación del cronograma”


del cronograma (minutos)

1 16

2 17

3 14

4 16

5 17

6 14

7 17

8 14

9 14

10 16

11 14

12 16

13 13

14 14

15 15

16 15

17 15

18 16

19 16

20 15

21 15

22 13

23 15

24 16

25 15

26 13

27 13

28 13

29 13

30 13

Anexo 14 GRUPO EXPERIMENTAL INDICADOR DE AVANCE DEL TRABAJO

Muestra de “Tiempo en calcular el índice de desempeño del costo”


costo (minutos)

1 13

2 13

3 13

4 10

5 12

6 13

7 14

8 14

9 11

10 13

11 14

12 14

13 14

14 12

15 13

16 12

17 13

18 12

19 12

20 11

21 13

22 13

23 12

24 12

25 12

26 11

27 12

28 13

29 12

30 14

Anexo 15 GRUPO EXPERIMENTAL INDICADOR DE AVANCE DEL TRABAJO

Muestra de “Tiempo en calcular el índice de desempeño del cronograma”


cronograma (minutos)

1 12

2 12

3 13

4 12

5 13

6 11

7 11

8 12

9 11

10 11

11 11

12 13

13 10

14 11

15 10

16 13

17 12

18 14

19 13

20 10

21 11

22 11

23 12

24 13

25 13

26 13

27 11

28 11

29 12

30 13

Anexo 16 RELACIÓN ENTRE ÁREAS DE CONOCIMIENTO Y PROCESOS DE LA GUÍA PMBOK 5º

EDICIÓN

INICIACIÓN PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO Y CONTROL

CIERRE

4. GESTIÓN DE INTEGRACIÓN

4.1. Desarrollar el acta de constitución del proyecto

4.2. Desarrollar el plan para la dirección del proyecto

4.3. Dirigir y gestionar la ejecución del proyecto

4.4. Monitorizar y controlar el trabajo de proyecto 4.5. Realizar el control integrado de cambios

4.6. Cerrar proyecto o fase

5. GESTIÓN ALCANCE

5.1. Planificar el alcance 5.2. Recopilar requisitos 5.3. Definir el alcance 5.4. Crear EDT

5..5. Verificar el alcance 5..6. Controlar el alcance

6. GESTIÓN TIEMPO

6.1. Planificar el tiempo 6.2. Definir las actividades 6.3. Secuenciar las actividades 6.4. Estimar los recursos de las actividades 6.5. Estimar la duración de las actividades 6.6 Desarrollar el cronograma

6.7. Controlar el cronograma

7. GESTIÓN LOS COSTOS

7.1. Planificar los costos 7.2. Estimar los costos 7.3. Determinar el presupuesto

7.4. Controlar los costos

8. GESTIÓN CALIDAD

8.1. Planificar la calidad

8.2. Realizar el aseguramiento de la calidad

8.3. Realizar el control de calidad

9. GESTIÓN RECURSOS HUMANOS

9.1. Desarrollar el plan de recursos humanos

9.2. Adquirir el equipo del proyecto 9.3. Desarrollar el equipo del proyecto 9.4. Dirigir el equipo del proyecto

//..

..//

INICIACIÓN PLANIFICACIÓN EJECUCIÓN SEGUIMIENTO Y CONTROL

CIERRE

10. GESTIÓN DE COMUNICACIÓN

10.1. Planificar las comunicaciones

10.2. Gestionar las comunicaciones

10.3. Informar el desempeño

11. GESTIÓN DE RIESGOS

11.1. Planificar la gestión de riesgos 11.2. Identificar los riesgos 11.3. Realizar el análisis cualitativo de riesgos 11.4. Realizar el análisis cuantitativo de riesgos 11.5. Planificar la respuesta a los riesgos

11.6. Monitorear y controlar los riesgos

12. GESTIÓN DE ADQUISICIONES

12.1. Planificar las adquisiciones

12.2. Efectuar las adquisiciones

12.3. Administrar las adquisiciones

12.4. Cerrar las adquisiciones

13. GESTIÓN INTERESADOS

13.1. Identificar a los interesados

13.2. Planificar los interesados

13.3. Gestionar la participación de los interesados

13.4. Controlar la participación de los interesados

Fuente: Guía PMBOK Quinta Edición, 2013

Anexo 17 GESTIÓN DE ALCANCE - EDT DEL PROYECTO

Anexo 18 GESTIÓN DE TIEMPO – ESTIMACIÓN DE RECURSOS Y DURACIONES

ENTREGABLES ACTIVIDAD

TIPO DE RECURSO: PERSONAL

NOMBRE DE RECURSO

TRABAJO DURACIÓN

Acta de constitución del proyecto

Reunión con el Cliente Patrocinador Jefe del proyecto

2h 2h

4h

Elaboración Jefe del proyecto Jefe de calidad

6h 6h



Jefe del proyecto Coordinador del proyecto Analista

3h 3h

6h

Plan de Gestión de Alcance

Enunciado del alcance Jefe del proyecto Analista Jefe de calidad

6h 6h

Elaborar EDT Jefe del proyecto Analista

5h 5h

Diccionario EDT Jefe del proyecto Analista

8h 8h

Definición del Alcance Jefe del proyecto Analista Jefe de calidad

12h 12h

Plan de Gestión de Tiempo

Definir Actividades Jefe del proyecto Analista

4h 4h

8h

Establecer secuencia de actividades.


2h 2h

4h

Estimar recursos y duraciones


6h 6h

12h

Cronograma de Actividades


4h 4h

8h

Plan de Gestión de Costos

Estimación de Costos Jefe del proyecto Analista

4h 4h

8h

Preparación del presupuesto de Costes


4h 4h

8h

Plan de Gestión de Calidad

Establecer responsabilidades para gestionar la calidad


12h 12h

Elaborar la matriz de Asignación y responsabilidades


4h 4h

Plan de Gestión de Recursos Humanos

Identificar la participación del personal


4h 4h

Establecer responsabilidades


4h 4h

Desarrollar Matriz de Asignación y Responsabilidades


4h 4

Diseñar Organigrama del proyecto


2h 2h

Plan de Gestión de Comunicaciones

Desarrollar Matriz de gestiones de las comunicaciones


10h 10h

//..

..//

ENTREGABLES ACTIVIDAD

TIPO DE RECURSO: PERSONAL

NOMBRE DE RECURSO

TRABAJO DURACIÓN

Plan de Gestión de Riesgos

Identificar Riesgos Jefe del proyecto Analista

4h 4h

Análisis cualitativo y cuantitativo


6h 6h

Planificación de Respuestas a los riesgos


5h 5h

Plan de Gestión de Adquisiciones

Planificación de compras y adquisiciones


8h 8h

Planificación de Contrataciones


8h 8h

Plan de Gestión de Interesados

Clasificar a los Interesados

Patrocinador Jefe del proyecto Analista

4h 4h

Registro de los Interesados involucrados en el Proyecto


4h 4h

Estrategia de gestión de los Interesados


8h 8h

Ejecución

Actas de reuniones de control del proyecto

Jefe del proyecto 10 horas 10 horas

Gestión del producto

Analista Diseñador Programador Comité de control de calidad

9 días 1 día 1 día 1 día

12 días

Desarrollo de la base de datos

Programador 7 días 7 días

Desarrollo del diccionario de datos

Programador 7 días 7 días

Prototipos Diseñador Programador Tester

5 días 22 días 2 días

29 días

Producto final

Diseñador Programador Tester Comité de control de calidad

1 días 5 días 1 días 2 días

7 días

Seguimiento y control

Inspección de calidad Jefe del proyecto Comité de control de calidad

3h 7h

10 horas

Solicitudes de cambios aprobadas

Jefe del proyecto Coordinador del proyecto Comité de control de calidad

2h 4h 4h

10 horas

Informe de monitoreo de riesgos


5h 5h

10 horas

Cierre Lecciones aprendidas

Jefe del proyecto Analista Diseñador Programador

6h 2h 2h

10 horas

Acta de aceptación del proyecto

Jefe del proyecto 10h 10 horas

Anexo 19 GESTIÓN DE RECURSOS HUMANOS – MATRIZ DE ASIGNACIÓN Y RESPONSABILIDADES

Personal

Equipo de Proyecto Interesados

Claves

Jefe

de

l

pro

yecto

Ana

lista

s

Dis

eña

dor

Pro

gra

mad

ore

s

Teste

r

Docum

enta

dor

Patr

ocin

ad

or

Com

ité d

e

contr

ol de

calid

ad

AC

TIV

IDA

DE

S

GE

ST

IÓN

DE

L P

RO

YE

CT

O

Inic

iac

ión

Acta de constitución del proyecto AS

P IRS IR

Identificación de Interesados A PI

P P

Pla

ne

ació

n

Plan de Dirección del proyecto AR PI

P I IRS

Eje

cu

ció

n

Acta de reunión de control de trabajo del proyecto

AR PI

P P P

Seg

uim

ien

to

y c

on

tro

l

Inspección de calidad AR PI I PI P

PS

Solicitudes de cambios aprobados AR P P P I P

PS

Acciones correctivas AR P P P I P I

Informe de monitoreo de riesgos AR P P P I P PS

Cie

rre

Lecciones aprendidas R PS I I I P

Acta de aceptación del proyecto RS P P PS PS

GE

ST

IÓN

DE

L P

RO

DU

CT

O

An

álisis

de

Req

ueri

mie

nto

s

Lista de los actores del negocio R AP

I IR

Lista de los actores del sistema R AP

I IR

Lista de los requerimientos del sistema

R AP

IR

An

álisis

del

sis

tem

a Lista de casos de uso R AP I I

IR

Descripción de casos de uso R AP I I

IR

Diagramas de casos de uso

AP I I

IR

Dis

eñ

o d

el

sis

tem

a

Modelo de contenidos R A PR I IP

Modelo de navegación R A PR IP

Modelo de presentación R A PR IP

Modelo de estructura de procesos R A PR IP

Diagrama de flujo de procesos R A PR IP

A= Responsable, R = Se requiere revisión, I = Se requiere Opinión, S = Se requiere Firma, P =

Participa //.,

..//

Equipo de Proyecto Interesados

Claves

Jefe

de

l

pro

yecto

Ana

lista

s

Dis

eña

dor

Pro

gra

mad

ore

s

Teste

r

Docum

enta

dor

Patr

ocin

ad

or

Com

ité d

e

contr

ol de

calid

ad

AC

TIV

IDA

DE

S

GE

ST

IÓN

DE

L P

RO

DU

CT

O

Base d

e

dato

s

Desarrollo de la base de datos R P I A R

Dic

cio

na

rio

de d

ato

s

Desarrollo del diccionario de datos R AP R

Co

dif

icació

n

Desarrollar de prototipos A

P P P

R RS

Producto final A RI P P P

IRS IRS

A= Responsable, R = Se requiere revisión, I = Se requiere Opinión, S = Se requiere Firma, P =

Participa

Anexo 20 GESTIÓN DE RIESGOS – ANÁLISIS CUANTITATIVO DE RIESGOS

Probabilidad Valor

Impacto Valor

Tipo de Riesgo Valor

Muy improbable

0.1

Bajo

0.1

Muy bajo 0.1

Casi probable 0.2

Moderado 0.2

Bajo 0.2

Probable 0.3

Alto 0.3

Moderado 0.3

Muy Probable 0.4

Alto 0.4

Casi Certera 0.5

Muy alto 0.5

Código Descripción Probabilidad Objetivo Afectado

Impacto Tipo de

Riesgo

R01 Disponibilidad de

Recursos Humanos 0.3

Tiempo 0.2

0.4 Costo

Calidad

0.2

R02 Disponibilidad de

equipos 0.5

Tiempo 0.3

0.3 Costo

Calidad

0.3

R03

Renuncia del

personal clave del

proyecto

0.2

Tiempo 0.3

0.4 Costo

Calidad 0.1

0.4

R04 Pérdida de

información 0.2

Tiempo 0.3

0.5 Costo 0.2

Calidad

0.5

R05

Modificación del

Cronograma de

actividades

0.3

Tiempo 0.3

0.4 Costo 0.1

Calidad

0.4

R06

Metodología

inadecuada para el

desarrollo del

producto

0.2

Tiempo 0.3

0.5 Costo 0.2

Calidad 0.3

0.8

R07 Solicitudes de

cambio aprobadas 0.4

Tiempo 0.3

0.4 Costo 0.1

Calidad

0.4

R08 Desaprobación de

entregables 0.2

Tiempo 0.2

0.4 Costo 0.1

Calidad 0.1

0.4

R09

Bajo rendimiento del

personal del

proyecto

0.3

Tiempo 0.1

0.3 Costo 0.2

Calidad 0.3

0.6

Anexo 21 GESTIÓN DE RIESGOS – PLAN DE RESPUESTA A RIESGOS

Código del

riesgo

Amenaza / Oportunidad

Descripción Causa raíz Consecuencia Tipo Responsable del

riesgo Respuestas planificadas

Tipo de respue

sta

Responsable de la

respuesta

Plan de contingenci

a

R01 Amenaza

Disponibilidad de

Recursos

Humanos

Sobrecarga de trabajo del personal asignado


Alta Jefe del proyecto Reajustar las actividades

Mitigar Jefe del proyecto

Contratación de nuevo personal

R02 Oportunidad Disponibilidad de equipos

Disponibilidad de equipos

Adelanto en las actividades del proyecto.

Media ALIADOS Avance del proyecto


Negociar anticipadamente con el Patrocinador

R03 Amenaza Renuncia del personal clave del proyecto

Oferta laboral en nuevos proyectos

Cambio de personal.

Baja Jefe del proyecto

Incluir cláusulas de penalidades en el contrato



R04 Amenaza Pérdida de

información Problemas técnicos.


Muy Alta

Jefe del proyecto Documentador

Realizar copias de seguridad diarias

Mitigar

Jefe del proyecto Documentador

Reajustar las actividades, costos

R05 Amenaza Modificación del Cronograma de actividades

Aceptación de solicitudes de Cambio.


Alta ALIADOS Comité de control de calidad

Reajustar las actividades

Mitigar Jefe del proyecto Analista


R06 Amenaza

Metodología

inadecuada para

el desarrollo del

producto


Cierre del proyecto.

Muy Alta

Analista Diseñador

Realizar un nuevo análisis

Mitigar Analista Diseñador

Tener una metodología de contingencia

R07 Amenaza Solicitudes de cambio aprobadas

Solicitudes de Cambio

Modificación y ampliación del cronograma.

Alta ALIADOS Comité de control de calidad

Reajustar las actividades

Mitigar Jefe del proyecto Analista


//..

..//

Código del

riesgo

Amenaza / Oportunidad

Descripción Causa raíz Consecuencia Tipo Responsable del riesgo

Respuestas planificadas

Tipo de respuesta

Responsable de la

respuesta

Plan de contingenci

a

R08 Amenaza

Desaprobaci

ón de

entregables



Alta Diseñador Programador

Reunir al equipo del proyecto para realizar un análisis del entregable

Mitigar Equipo de trabajo del proyecto

Análisis exhaustivo del entregable rechazado

R09 Amenaza

Bajo

rendimiento

del personal

del proyecto

Clima laboral.

Cambio de personal.

Media

Equipo del proyecto

Realizar un seguimiento exhaustivo de las actividades desarrolladas por el personal



Anexo 22 ACTA DE REUNIÓN DE COORDINACIÓN DEL PROYECTO Nº 1

Proyecto: Software de monitoreo y evaluación de planes de negocio para el Programa

ALIADOS del Ministerio de Agricultura

Dirigido a: Director Ejecutivo Fecha: 01 de agosto del 2013

Lugar: Oficina de Coordinación de Monitoreo, Evaluación e Informática

Documentación

Que se debe leer previamente Responsable

Términos de Referencia (TDR) Administrador Director Ejecutivo

Que se debe presentar en la reunión Responsable

Acta de reunión Jefe del Proyecto

Agenda

Actividad Responsable

Aceptación del proyecto Administrador Director Ejecutivo

Información y datos del proyecto Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática

Planeación del proyecto Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática

Conclusiones

Ítem Acuerdo Responsable

1 Se ha acordado realizar el Proyecto, el cual estará bajo supervisión directa de la Oficina de Coordinación de Monitoreo, Evaluación e Informática.

Administrador Director ejecutivo Jefe del proyecto

2

Se ha acordado desarrollar el producto en base al TDR, el cual dispone de los siguientes entregables: Módulo de software de Banco de Planes de negocio.

Interface de registro de datos generales de proyecto según esquema definido por el Programa (Tomando como referencia el Banco de Proyectos del SNIP)

Interface de registro de marco lógico e indicadores físicos y financieros a nivel de componentes y actividades

Interface de registro de periodo de ejecución del Plan de negocio

Reportes definidos por el Programa Módulo de software de Ejecución Planes de Negocio.

Jefe del proyecto Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática

3

El desarrollo del producto final cuenta con presupuesto de S/. 20, 000 (Veinte mil nuevos soles), deberá ser construido en un plazo de 2 meses (un módulo por mes) y debe seguir estándares de calidad.





Dirigido a: Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática Fecha: 27 de septiembre del 2013


Documentación


Acta de constitución del proyecto Plan de dirección del proyecto

Director ejecutivo Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática


Presentación del primer informe Jefe del proyecto

Agenda


Presentación del primer informe Jefe del proyecto

Presentación del “Módulo de software de Banco de Planes de negocios”

Jefe del proyecto

Coordinación de la entrega del segundo módulo

Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática

Conclusiones


1 Se ha decidido realizar algunos cambios en las interfaces, así como la implementación de nuevas características (Detallados en el documento de solicitud de cambios Nº 001).


2 Se ha decidido implementar una interface de Ficha de Registro (Detallados en el documento de solicitud de cambios Nº 002).


3

Se ha acordado desarrollar el segundo módulo: “Módulo de software de Ejecución Planes de Negocio”

Debe estar basado en el formato PAO

Descripción del plan

Registro de Saldos del año anterior

Registros de metas del formato PAO

Reportes definidos por el Programa





Dirigido a: Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática Fecha: 25 de octubre del 2013


Documentación


Acta de constitución del proyecto Plan de dirección del proyecto Informe de la entrega del primero Módulo

Director ejecutivo Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática


Presentación del segundo informe Jefe del proyecto

Agenda


Presentación del primer informe con los cambios solicitados

Jefe del proyecto

Presentación del segundo informe Jefe del proyecto

Presentación del “Módulo de software de Ejecución Planes de Negocio”

Jefe del proyecto

Conclusiones


1

Se ha dado el visto bueno a la entrega del primer informe con los cambios solicitados así como el segundo Módulo desarrollado, de esta manera se ha aprobado la entrega del producto final.


2 Se ha establecido una nueva reunión para la entrega final del producto así como el cierre del proyecto.

Director ejecutivo Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática Jefe del proyecto




Dirigido a: Director Ejecutivo Fecha: 28 de octubre del 2013


Documentación


Informe de la entrega del primero Módulo Informe de la entrega del segundo Módulo

Administrador Director ejecutivo Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática


Acta de reunión Jefe del proyecto

Informe del cierre del proyecto Director ejecutivo

Agenda


Entrega del producto final Jefe del proyecto

Cierre del proyecto Administrador Director ejecutivo

Conclusiones


1 Se ha dado el visto bueno al producto final, comprobando que cumple con los requisitos establecidos en el TDR así como los cambios solicitados durante la construcción.

Administrador Director ejecutivo Jefe del proyecto

2 Se aceptó el informe de cierre, culminando con el proyecto y cumpliendo con el contrato (Detallado en el acta de cierre del proyecto).


Anexo 26 INSPECCIÓN DE CALIDAD Nº 001


Informe de entrega del primer módulo

Primer módulo desarrollado



Verificar que el primer módulo esté completo y cuente con las especificaciones técnicas establecidas.

Comprobar que el desarrollo del primer módulo se realizó utilizando la metodología establecida.

Comprobar que el informé detalle correctamente el desarrollo del primer módulo.



Observaciones



Resultado de la Inspección No conforme



Realizar cambios en las interfaces para mejorar la facilidad de uso.

Desarrollar una nueva interface para mostrar un resumen del registro de planes de negocio.

Jefe del proyecto


Las correcciones son establecidas como una actualización del primer módulo frente a características no previstas en la realización del TDR y no como incumplimiento de desarrollo.

Documentos adjuntos

Solicitud de cambio Nº 001

Solicitud de cambio Nº 002

Anexo 27 Inspección de Calidad Nº 003


Informe de entrega del segundo módulo

Segundo módulo desarrollado



Verificar que el segundo módulo esté completo y cuente con las especificaciones técnicas establecidas.

Comprobar que el desarrollo del segundo módulo se realizó utilizando la metodología establecida.

Comprobar que el informé detalle correctamente el desarrollo del segundo módulo.



Observaciones



Resultado de la Inspección Conforme



Ninguna


Se ha autorizado la entrega del producto final.

Documentos adjuntos

Ninguno

Anexo 28 SOLICITUD DE CAMBIO Nº 002

Tipo de cambio requerido

Acción correctiva

Definición del problema o situación actual

Se determinó el desarrollo de una nueva interface de Ficha de Registro

Descripción detallada del cambio solicitado

El cambio se realizará de la siguiente forma:

Se desarrollará una interface denominada “Ficha de Registro” en el cual se mostrará un resumen de los datos ingresados en el Registro del plan de negocio.

La visualización de esta nueva interface solo se podrá realizar al llenar todos los datos necesarios del plan de negocio.

La visualización de esta nueva interface será controlada a través de permisos de usuario

La nueva interface contará con la opción de Finalizar el proyecto, cambiando su estado de Propuesta a Viable.

Razón por la que solicita el cambio

Los cambios se realizarán porque se identificó la falta de una interface de reporte general del registro de planes de negocio.

Efectos en el proyecto

Corto plazo Largo plazo

Ninguno Ninguno

Observaciones y comentarios adicionales

Esta interface no se especifica dentro del TDR, por lo que se considerará como parte de “Reportes definidos por el Programa”.

Revisión del comité de control de cambios

Ejecutada por Jefe de calidad

Resultado de revisión Aprobada

Responsable de aplicar/informar

Jefe del proyecto

Observaciones especiales Ninguna

Anexo 29 GESTIÓN DE STAKEHOLDERS - REGISTRO DE STAKEHOLDERS INVOLUCRADOS EN EL PROYECTO

Identificación Evaluación Clasificación

Nombre Empresa y puesto Ubicación Rol en el proyecto

Requerimientos primordiales

Expectativas principales

Influencia potencial

Interno/ externo

Apoyo/ neutral/ opositor

Administrador ALIADOS – Administradora

Ayacucho Patrocinador Que el proyecto se cumpla exitosamente.

Que se desarrolle el proyecto al tiempo, costo y calidad establecidos.

Fuerte Externo

Jefe del proyecto

Ayacucho Jefe del Proyecto.

Cumplir con el plan del proyecto

Que el cliente esté satisfecho con el proyecto

Mediana Interno Apoyo

Director ejecutivo

ALIADOS – Director ejecutivo

Ayacucho Coordinador del proyecto

Que se desarrolle el software

Que el proyecto sea culminado exitosamente

Fuerte Externo

Jefe de la Oficina de seguimiento y control - PMO

ALIADOS – Jefe de la Oficina de Coordinación de Monitoreo, Evaluación e Informática

Ayacucho Supervisor Jefe de calidad

Cumplir con el plan del proyecto

Que el proyecto sea culminado exitosamente

Fuerte Externo Apoyo

Anexo 30 CASOS DE USO DEL SISTEMA (COMPLETO)

Anexo 31 DIAGRAMA DE LA BASE DE DATOS – REGISTRO

Anexo 32 DIAGRAMA DE LA BASE DE DATOS – REGISTRO DEL FORMATO PAO

GLOSARIO DE TÉRMINOS

Actividad Conjunto de tareas que se realiza con un propósito específico.

Aplicación Una aplicación es un sistema informático que los usuarios utilizan accediendo a un servidor a través de Internet o de una intranet.

Monitoreo Consiste en la observación del curso de uno o más parámetros para detectar eventuales anomalías.

Frameworks

Del inglés "Marco de trabajo" define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.

Eficacia El correcto uso de los recursos

Intranet Es una red de ordenadores de una red de área local (LAN) privada empresarial o educativa que proporciona herramientas de Internet.

Método Es una técnica repetible para la resolución de un problema específico.

Usabilidad Facilidad de uso del sistema para los usuarios

PMBOK Guía para la Gestión de Proyectos, desarrollada por el PMI

PMI Instituto de Gestión de Proyectos

Funcionalidad La correcta ejecución de las tareas

Evaluación La evaluación es la acción de estimar, apreciar, calcular o señalar el valor de algo

MDD Desarrollo dirigido por modelos

Modelo de casos de uso

Modelo formado por casos de usos, actores y relaciones entre ambos, modelo que describe lo que el sistema debería hacer por sus usuarios y bajo qué restricciones.

PMO Oficina de Gestión de Proyectos

Interfaz Se denomina interfaz a cualquier medio que permita la interconexión de dos procesos diferenciados con un único propósito común.

SNIP Sistema Nacional de Inversión Pública, creado por el Ministerio Economía y Finanza (MEF)

Prototipo

Un prototipo es también un modelo de lo real, pero no tan funcional como para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final, proporcionando una retroalimentación temprana por parte de los usuarios acerca del sistema.

Script Un script es un conjunto de instrucciones. Permiten la automatización de tareas, creando pequeñas utilidades.

Aplicación web para el apoyo del programa ALIADOS 2013

Technology

Transcript of Aplicación web para el apoyo del programa ALIADOS 2013