Gestion Proyecto JCAMP

ESCUELA SUPERIOR POLITÉCNICA DE CHIMBORAZO
FACULTAD DE INFORMÁTICA Y ELECTRÓNICA

ESCUELA DE INGENIERÍA EN SISTEMAS
“APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE

INVENTARIOS Y CUENTAS POR COBRAR “
PRESENTADO POR:
Tipán Mirian (5982)
Jiménez Jorge (6087)
Tasna Cecilio (6097)
Tubón Alexander (6214)
Quinatoa María José (6216)
Riobamba - Ecuador
Contenido
INTRODUCCIÓN ................................................................................................................................. 5
EXPLORACIÓN ................................................................................................................................... 6
CAPÍTULO 1 ........................................................................................................................................ 7
ESTRATEGIA DE INNOVACIÓN .................................................................................................. 7
Antecedentes ...................................................................................................................................... 7
Técnica Brainstorming ....................................................................................................................... 7
¿Cómo se utiliza? ........................................................................................................................... 8
Aplicación .......................................................................................................................................... 8
Objetivo ............................................................................................................................................. 9
CAPÍTULO 2 ...................................................................................................................................... 10
PLAN DE NEGOCIOS.................................................................................................................... 10
Nombre de la Empresa ..................................................................................................................... 10
Misión .............................................................................................................................................. 10
Visión .............................................................................................................................................. 10
Objetivos .......................................................................................................................................... 10
Políticas (Para orientación de las decisiones empresariales) ............................................................ 10
Estrategias (para cumplir misión y visión) ....................................................................................... 10
Proceso de Negocio ......................................................................................................................... 11
Modelo de negocio........................................................................................................................... 11
CAPÍTULO 3 ...................................................................................................................................... 13
Diseño y herramientas tecnológicas ................................................................................................. 13
Lenguaje de Programación Java ....................................................................................................... 13
Ventajas y Desventajas ................................................................................................................ 13
Base de datos Mysql ........................................................................................................................ 14
API REST ........................................................................................................................................ 14
Características .............................................................................................................................. 14
Ventajas ....................................................................................................................................... 15
1.1.1. Desventajas .................................................................................................................. 15

Arquitectura del Sistema .................................................................................................................. 15
CAPÍTULO 4 ...................................................................................................................................... 17
METODOLOGÍA XP ...................................................................................................................... 17
Esquema .......................................................................................................................................... 17
Valores XP ....................................................................................................................................... 17
Características .................................................................................................................................. 18
Roles ................................................................................................................................................ 18
Alcance en el proyecto ..................................................................................................................... 18
CAPÍTULO 5 ...................................................................................................................................... 19
PLANIFICACIÓN ........................................................................................................................... 19
LA METODOLOGÍA XP EN LA ORGANIZACIÓN .................................................................... 19
APLICACIÓN DE LA METODOLOGÍA ....................................................................................... 19
T-SHIRT ...................................................................................................................................... 20
Requerimentación ............................................................................................................................ 20
Análisis ........................................................................................................................................ 20
Requerimientos ............................................................................................................................ 20
Historias de usuario ......................................................................................................................... 22
Historias técnicas ......................................................................................................................... 23
Plan de entrega ................................................................................................................................. 24
Tabulación de puntos de esfuerzo estimados ............................................................................... 24
Plan de entrega ............................................................................................................................. 29
PLAN DE GESTIÓN DEL PROYECTO ............................................................................................ 33
1. PLAN PARA LA DIRECCIÓN DEL PROYECTO ................................................................ 33
2. PLAN DE GESTIÓN DE INTEGRACIÓN ............................................................................. 37
3. PLAN DE GESTIÓN DE ALCANCE ..................................................................................... 47
2.1. Declaración del Alcance ........................................................................................................... 47
2.2. Gestión de los requisitos ....................................................................................................... 52
2.3. Estructura de desglose de trabajo .................................................................................... 57
3. PLAN DE GESTIÓN DE TIEMPO ......................................................................................... 59

3.1. Gestión del tiempo ............................................................................................................... 59
4. PLAN DE GESTIÓN DE COSTO ........................................................................................... 65
5. PLAN DE GESTIÓN DE LA CALIDAD ................................................................................ 69
5.1. Gestión de la Calidad ........................................................................................................... 69
6. PLAN DE GESTIÓN DE RECURSOS HUMANOS .............................................................. 75
6.1. Recursos Humanos ........................................................................................................... 75
6.2. Organización del proyecto................................................................................................ 79
7. PLAN DE GESTIÓN DE COMUNICACIONES .................................................................... 80
7.1. Requisitos de Comunicación ............................................................................................ 80
7.2. Matriz de Comunicación .................................................................................................. 80
7.3. Canales de Comunicación ................................................................................................ 81
7.4. Distribución de la información ......................................................................................... 81
8. PLAN DE GESTIÓN DE RIESGOS ....................................................................................... 83
8.1. Introducción ..................................................................................................................... 83
8.2. Propósito .......................................................................................................................... 83
8.3. Gestión del riesgo ............................................................................................................. 83
8.3.1. Plan de gestión de los riegos ........................................................................................ 83
8.3.2. Identificación de los riegos ........................................................................................... 85
8.3.3. Registro de riesgos ....................................................................................................... 86
8.3.4. Análisis cualitativo de riesgos identificados ................................................................. 94
8.3.5. Planificar la respuesta a los riesgos .............................................................................. 95
9. PLAN DE GESTIÓN DE ADQUISICIONES ......................................................................... 97
10. PLAN DE GESTIÓN DE INTERESADOS ....................................................................... 100
10.1. Registro Preliminar .................................................................................................... 100
10.2. Gestión de los interesados .......................................................................................... 102
10.3 Registro de Incidentes .................................................................................................... 103
10.4 Solicitudes de cambio .................................................................................................... 104

INTRODUCCIÓN
En este trabajo, se va a establecer el plan de Dirección de Proyecto que estará constituido de los
siguientes puntos:
 Fase de Exploración
 Plan para la dirección del Proyecto
 Acta de Constitución del Proyecto
 Plan de Gestión del Alcance
 Plan de Gestión del Tiempo
 Plan de Gestión de los Costos
 Plan de Gestión de la Calidad
 Plan de Gestión de los Recursos Humanos
 Plan de Gestión de las Comunicaciones
 Plan de Gestión de los Riesgos
 Plan de Gestión de los Interesados
EXPLORACIÓN
La compra y venta de productos y servicios en todas sus categorías han evolucionado a
través de los años y mucho más con el aumento de teléfonos inteligentes y su cotización
accesible en el mercado; si bien aplicaciones de uso común como redes sociales,
servicios de streaming y juegos complementan sus actividades con servicios de compra
y venta constante de productos o servicios (aquellos que sirven dentro del entorno de
cada una), existen aplicaciones dedicadas al comercio electrónico a través de sus
plataformas y gracias a esto se han abierto paso en el mercado empresas como: mercado
libre, wish, olx, amazon o e-bay.
Sin embargo, a través del tiempo tanto consumidores como vendedores han empezado a
encontrar algunas alternativas interesantes a la hora de realización compras/ventas a
través de un aplicativo móvil. Partiendo de los consumidores, la posibilidad de tener
descuentos importantes por su fidelidad en compras dentro de la aplicación, incluso
manejando un sistema de reputación que permita sustituir a las costosas membresías y le
otorgue beneficios exclusivos. Por parte de los vendedores, llega un momento en medio
de su prosperidad que no ven llegar cuando un producto va cayendo en obsolescencia de
consumo, o cuando un producto está teniendo una buena acogida, perdiendo en ganancias
en cualquiera de los escenarios planteados, además, y el problema más grave y con mayor
tendencia en este tipo de mercados “flexibles” es la gran cantidad de problemas por
cuentas que no se cancelan a tiempo y producen pérdidas significativas que afectan a la
evolución de la empresa o emprendimiento.
Hay un punto importante a considerar y es que, por lo general estos distribuidores ya

cuentan con una base importante de clientes y ellos se han convertido en distribuidores
consolidados, lo que les hace resistirse a la idea de la comercialización electrónica
completamente, sin embargo, algo tentativo para ellos sería el brindarles una aplicación
que permita sustentar sus necesidades a la hora de tomar control sobre sus cuentas por
cobrar.
Dadas estas consideraciones, se plantea el desarrollo de un sistema web y aplicativo

móvil basado en una arquitectura web REST (que ha marcado tendencia por su
flexibilidad en implementación y las empresas de comercio electrónico ya están
aprovechando de sus ventajas) para un sistema web y móvil para el control de inventarios
y cuentas por cobrar.
6
CAPÍTULO 1
ESTRATEGIA DE INNOVACIÓN
Antecedentes
En una sociedad en constante cambio y continua evolución como en la que nos
encontramos quedarse parado supone una regresión. Si el panorama está cambiando y
seguimos haciendo lo mismo lo más probable es que nuestra empresa esté abocada al
fracaso y a la desaparición. En este sentido, innovar se ha convertido en una necesidad,
llegando a considerarse como el verdadero motor de la empresa.[1]
La innovación potencia la creación de nuevos conocimientos, nuevas ideas y estrategias
que mejoren los productos, servicios y procesos en una compañía. Todo ello asegura la
competitividad y continuidad del negocio en el mercado, por lo que es clave para su
crecimiento. Gestionar esta creación de nuevas ideas requiere de técnicas y métodos
para potenciar la creatividad y la innovación. Entre las más importantes están:
Design Thinking. Es una metodología centrada en las personas. A través de ella se
analizan los retos, necesidades y sus posibles soluciones tecnológicamente factibles y
comercialmente viables.
Lego Serious Play. Este método que utiliza el juego como herramienta para compartir
información, positiva o negativa, que en otras circunstancias no se distribuiría. Gracias
al ambiente de una actividad dinámica se tratan diferentes temas de negocio, estrategias,
problemáticas y más.
Brainstorming. Se trata de una técnica grupal para generar el mayor número de ideas
o soluciones posibles en un tiempo determinado, para luego analizarlas y separar las
mejores.
Scamper. Consiste en un listado de preguntas preestablecidas cuya formulación de
respuestas impulsa la creatividad de los trabajadores.
Sensibilización. Se propone algún reto para ver qué sucede con los colaboradores al
momento de enfrentarlo, desarrollar soluciones o analizar los obstáculos.[2]
Técnica Brainstorming
Es una herramienta de trabajo grupal que facilita el surgimiento de nuevas ideas sobre
un tema o problema determinado. La lluvia de ideas es una técnica de grupo para
generar ideas originales en un ambiente relajado.
Esta herramienta fue creada en el año 1941, por Alex Osborne, cuando su búsqueda de
ideas creativas resulto en un proceso interactivo de grupo no estructurado que generaba
más y mejores ideas que las que los individuos podían producir trabajando de forma
independiente; dando oportunidad de sugerir sobre un determinado asunto y
7
aprovechando la capacidad creativa de los participantes. Esta técnica en específico nos
permite:
 Plantear y resolver los problemas existentes
 Plantear posibles causas
 Plantear soluciones alternativas
 Desarrollar la creatividad
 Discutir conceptos nuevos
 Superar el conformismo y la monotonía
¿Cómo se utiliza?
o Se define el tema o el problema.
o Se nombra a un conductor del ejercicio
o Antes de comenzar la “tormenta de ideas”, explicara las reglas.
o Se emiten ideas libremente sin extraer conclusiones en esta etapa.
o Se listan las ideas
o No se deben repetir
o No se critican
o El ejercicio termina cuando ya no existen nuevas ideas
o Se analizan, evalúan y organizan las mismas, para valorar su utilidad en

función del objetivo que pretendía lograr con el empleo de esta técnica.[3]
Aplicación
De la aplicación de la técnica de Brainstorming se determinaron cada uno de los
campos:
Tema: Aplicaciones e-commerce
Conductor del ejercicio: María José Quinatoa
Reglas: Cada uno da una crítica al sistema de control de cuentas por cobrar e inventarios
sin tiempo determinado.
Ideas:
o “Las cuentas por cobrar son un problema que lleva años sin poder dar una
solución definitiva, sin embargo, se podría utilizar algún tipo de
comprobante con validez legal en nuestro medio que permita de alguna
forma ayudar a estos comerciantes o distribuidores” (Quinatoa, María José)
8
o “Los productos cualesquiera que estos sean, deberían cancelarse en un solo
pago para evitar este tipo de inconvenientes” (Jiménez, Jorge)
o “Los inventarios deberían proporcionar más que números, deberíamos

enfocarnos más en establecer tendencias a partir de estos datos y generar
interés para el distribuidor” (Tasna, Cecilio)
o “Las cuentas por cobrar pueden ser un verdadero dolor de cabeza, tal vez
lo mejor sea que este comercio termine por evolucionar al comercio 100%
electrónico y dependa de un servicio como paypal, esa ha sido una base
para empresas consolidadas como e-bay y amazon” (Tipán, Mirian)
o “Las cuentas por cobrar pueden ser muy fáciles de sobrellevar con los
instrumentos legales que permitan garantizar el pago de la deuda de los
acreedores” (Tubón, Alexander)
o “Se podría tratar de investigar sobre qué comprobantes o documentos

legales específicos pueden ser de ayuda para los distribuidores o
comerciantes” (Salazar, Alex)
Ideas repetidas: Ninguna.

Crítica a las ideas: Ninguna.
Nuevas ideas a partir de otras: Las letras de cambio y los pagarés son los documentos
con base legal para garantizar el cobro de valores pendientes.
Evaluación y solución: Se llegó al acuerdo completo del grupo de considerar este punto
muy importante:
o “Las cuentas por cobrar son un problema que lleva años sin poder dar una
solución definitiva, sin embargo, se podría utilizar algún tipo de
comprobante con validez legal en nuestro medio que permita de alguna
forma ayudar a estos comerciantes o distribuidores” (Punto clave:
comprobante con validez legal para el cobro de valores adeudados)
Dado esto se obtuvieron como posible solución dos documentos importantes, pagarés
o letras de cambio, sin embargo, la que directamente se relaciona con el comerciante es
el pagaré, motivo por el cual se trabajará con este último.
Objetivo
A partir de los puntos considerados y su análisis, el equipo de trabajo se propone a:

 Diseñar e implementar un sistema de pagaré electrónico para la aplicación móvil y
web.
9
CAPÍTULO 2
PLAN DE NEGOCIOS
Nombre de la Empresa
J-CAMP S.L.: Empresa de control de inventarios y cuentas por cobrar mediante una
aplicación móvil
Misión
Somos un equipo líder y emprendedores con responsabilidad social, comprometidos
en brindar soluciones de adquisición permanente en la aplicación web y móvil
apoyando las necesidades de todas las empresas del Ecuador que realizan el control de
inventarios y cuentas por cobrar.
Visión
Llegar a ser la Aplicación líder de su mercado en imagen, optimización, creatividad y
calidad de servicio enfocando su esfuerzo hacia el cliente, anticipándose a sus
necesidades, desarrollando a su personal y otorgando accesibilidad constante a sus
usuarios, a través de la utilización de medios tecnológicos, atención personalizada, y
control de cuentas por cobrar.
Objetivos
 Dar a conocer a los clientes cada uno de los servicios que la empresa de desarrollo
de la aplicación web y móvil ofrece.
 Satisfacer a los clientes en los servicios adquiridos.
 Brindar servicios a los clientes dependiendo de las necesidades de control de pagos

que lo requieran.
 Utilizar medios tecnológicos para ofrecer los servicios de calidad en los procesos
de cuentas por cobrar personalizada al cliente.
Políticas (Para orientación de las decisiones empresariales)

Las políticas de la empresa J-CAMP tantos internos como externas se detallará en el
capítulo V de los Artículos 1 hasta 19 en el cual está previsto por la ley de la contraloría
general del estado que por ende se desglosa todas las políticas establecidas para una
compañía o empresa.
Estrategias (para cumplir misión y visión)
 Se ofrecerá productos con óptima calidad respetando todos los estándares y

normas establecidas por la ISO 9000.
10
 Satisfacer las necesidades de otras empresas, otorgando accesibilidad constante
a los usuarios que hoy en día lo necesitan.
 Tipos de mercados nacionales como internacionales que utilizan tecnologías

requeridas para un mejor desarrollo de trabajos de una empresa.,
 Tener programas económicos de software para empresas que recién están

iniciando sus actividades empresariales.
Proceso de Negocio
Modelo de negocio
Para realizar el modelo de negocio de nuestra empresa denominada “J-CAMP”

se utilizará mediante el modelo de Lean Canvas a continuación se detallará los
siguientes detalles:
11
12
CAPÍTULO 3
Diseño y herramientas tecnológicas
Lenguaje de Programación Java
Java es un lenguaje de programación y una plataforma informática comercializada por
primera vez en 1995 por Sun Microsystems. Hay muchas aplicaciones y sitios web que
no funcionarán a menos que tenga Java instalado y cada día se crean más. Java es rápido,
seguro y fiable. Desde portátiles hasta centros de datos, desde consolas para juegos
hasta súper computadoras, desde teléfonos móviles hasta Internet, Java está en todas
partes. [4]
Ventajas y Desventajas
Ventajas Desventajas
1. La principal característica de Java es 4. Al tratarse de un lenguaje interpretado,
que es independiente de la el rendimiento en la ejecución de
plataforma (multiplataforma). Esto programas suele ser un poco menor.
significa que cuando estás
5. Aunque java es un lenguaje
programando en Java, no necesitas
relativamente sencillo de manejar, no es
conocer a priori el tipo de ordenador
recomendado implementarlo con
o el sistema operativo para el que
personas que apenas se unen a este
estás programando.
mundo, ya que Java se basa en una
2. El lenguaje Java es orientado a filosofía de programación (la
objetos. El paradigma de orientación a objetos) que es una
programación orientada a objetos evolución de otras formas de entender
supuso un gran avance en el la programación más sencilla de
desarrollo de aplicaciones, ya que es enseñar e implementar
capaz de acercar la forma de
6. Su sintaxis comparada con C# o Python
programar a la forma de pensar del
parece para algunos bastante engorrosa
ser humano.
y al contrario que su semejante en
3. El lenguaje Java es relativamente .NET, C#, es un lenguaje que
fácil de aprender comparado con evoluciona muy lentamente.
otros.
[5]
13
Base de datos Mysql
MySQL es un sistema de administración de bases de datos (Database Management
System, DBMS) para bases de datos relacionales. Así, MySQL no es más que una
aplicación que permite gestionar archivos llamados de bases de datos. MySQL, como
base de datos relacional, utiliza múltiples tablas para almacenar y organizar la
información. MySQL fue escrito en C y C++ y destaca por su gran adaptación a
diferentes entornos de desarrollo. [6]
Características
 El principal objetivo de MySQL es velocidad y robustez.
 Soporta gran cantidad de tipos de datos para las columnas.
 Gran portabilidad entre sistemas puede trabajar en distintas plataformas y sistemas

operativos.
 Aprovecha la potencia de sistemas multiproceso, gracias a su implementación

multadillo.
 Flexible sistema de contraseñas (passwords) y gestión de usuarios, con un muy

buen nivel de seguridad en los datos. [7]
API REST
REST es una arquitectura, para otras es un patrón de diseño, para otras un API. ¿Qué es
REST exactamente? REST o Representational State Transfer es un ESTILO de
Arquitectura a la hora de realizar una comunicación entre cliente y servidor.
Ilustración 1 Funcionamiento de una API Rest [8]

Características
Por su escalabilidad. Este protocolo destaca por su escalabilidad. Gracias a la

separación entre el cliente y el servidor, el producto se puede escalar con un equipo de
desarrollo sin que ello represente muchas dificultades.
Por su flexibilidad y portabilidad. Con el requisito imprescindible de que los datos de
cada una de las peticiones sean enviados de forma correcta, es posible realizar una
migración de un servidor a otro o practicar cambios en la base de datos en todo
14
momento.
Por su independencia. Debido a la separación entre el cliente y el servidor, el protocolo
facilita que los desarrollos de las diferentes partes de un proyecto se puedan dar de
manera independiente.
Ventajas
Separación cliente/servidor. Al ser sistemas independientes (solo se comunican con
un lenguaje de intercambio como JSON) puedes desarrollarlos proyectos autónomos,
equipos autónomos. Al cliente le da igual cómo está hecha la API y al servidor le da
igual qué vas a hacer con los datos que te ha proporcionado.
Independencia de tecnologías / lenguajes. Puedes desarrollar en cualquier tipo de
tecnología o lenguaje con la que te sientas a gusto o con la que puedas acortar tus
tiempos de desarrollo.
Fiabilidad, escalabilidad, flexibilidad. Al final solo te tienes que preocupar que el
nexo cliente / servidor esté correcto. Puedes hacer cambios en tu servidor, lenguajes,
bases de datos, etc. y mientras devuelvas los datos que toca todo irá correctamente.
Experiencia de usuario. Aunque eso depende más de cómo está hecha la parte del
cliente, teóricamente el desarrollo de sitios web basados en un API puede dar mejor
desempeño que uno tradicional.
1.1.1. Desventajas
En las API REST no mantenemos estado y eso hace que tengas que montar una
infraestructura propia para poder conservar el conjunto de la aplicación. Generalmente
mandarás un token que indique quién eres al servidor y qué has realizado ya en tu
aplicación.
Requiere más conocimientos, te obliga a salir de la zona de confort a la que quizás
estemos. Aparte de conocer tus lenguajes, bases de datos, librerías, necesitarás aprender
acerca del protocolo HTTP.
Arquitectura del Sistema

La arquitectura del sistema permite tener una visión global del sistema que se va a
desarrollar.
Para el desarrollo del Sistema se ha establecido utilizar la arquitectura cliente-servidor
en el que el objetivo primordial es la separación de la lógica de negocios de la lógica de
diseño; un ejemplo básico de esto consiste en separar la capa de datos de la capa de
presentación al usuario. Con el objetivo primordial es la escalabilidad permitiendo que
cada capa pueda ser desarrollada, mejorada, gestionada y desplegada de forma
independiente. Esta arquitectura permite crear sistemas automáticos que cooperan entre
sí para intercambiar información, servicios, recursos, etc. Es decir, los objetivos de cada
capa son independientes.
15
Para presentar de mejor manera esta arquitectura se diseñó el diagrama de paquetes
como se muestra en la Ilustración 2 y de manera más detallada el diagrama de
Componentes Ilustración 3, en StarUML (lenguaje unificado modelado).
Ilustración 2: Diagrama de Paquetes
Ilustración 3: Diagrama de Componentes
16
CAPÍTULO 4
METODOLOGÍA XP
La programación extrema (XP) es el enfoque más utilizado del desarrollo de software ágil.
Aunque las primeras actividades con las ideas y los métodos asociados a XP ocurrieron al final
de la década de 1980 Una variante de XP llamada XP industrial [IXP] se propuso en una época
más reciente. IXP mejora la XP y tiene como objetivo el proceso ágil para ser usado
específicamente en organizaciones grandes.
Esquema
Ilustración 2 Esquema XP
Valores XP
XP define un conjunto de valores que establecen el fundamento para todo trabajo
realizado como parte de XP. Cada uno de estos valores se usa como un motor para
actividades, acciones y tareas específicas de XP.
Ilustración 3 Valores XP
17
Características
 Se considera al equipo de proyecto como el principal factor de éxito del proyecto.
 Software que funciona por encima de una buena documentación.
 Interacción constante entre el cliente y el equipo de desarrollo.
 Planificación flexible y abierta.
 Rápida respuesta a cambios.
Roles
 Cliente: responsable de definir y conducir el proyecto, así como sus objetivos.
 Programadores: estiman tiempos de desarrollo de cada actividad y programan el

proyecto.
 Tester: Encargado de Pruebas.
 Tracker: Encargado de Seguimiento.
 Coach: Entrenador. Su papel es guiar y orientar al equipo.
 Big Boss: Gestor del proyecto, gerente del proyecto, debe tener una idea general
del proyecto y estar familiarizado con su estado. [9]
Alcance en el proyecto
El software de libros se hará de acuerdo con los requerimientos establecidos por el

cliente. Tanto para la comercialización del producto y como para el cobro por los
mismo, como los informes generados por la aplicación.
18
CAPÍTULO 5
PLANIFICACIÓN
LA METODOLOGÍA XP EN LA ORGANIZACIÓN
Extreme Programming se centra en potenciar las relaciones interpersonales del equipo
de desarrollo como clave del éxito mediante el trabajo en equipo, el aprendizaje
continuo y el buen clima de trabajo.
Para el desarrollo del sistema se hará uso de esta metodología, por las siguientes
razones:
 El usuario es parte fundamental en el desarrollo del sistema debido a que es quien
debe retroalimentar el sistema web para que cumpla con los objetivos de la
institución y satisfaga las necesidades de estas.
 Al ser un sistema web, al finalizar cada módulo se realizarán entregables, los

mismos que serán supervisados por el usuario, sujetándose a cambios y mejoras.
 Al iniciar el proyecto no todos los requisitos están bien establecidos por parte del
cliente por lo cual el sistema debe ser flexible y aceptar modificaciones durante su
desarrollo.
APLICACIÓN DE LA METODOLOGÍA
Para el desarrollo del Sistema J-PAYMENT, el equipo de trabajo concordó en el uso de
la metodología de desarrollo de software XP, cuyo principal objetivo es maximizar el
retorno de la inversión para la institución, y se obtuvieron dos entregables que son el
Plan de entrega y la Planificación, siendo el primero una lista priorizada con los
requisitos que se han definido conjuntamente con el Cliente, la planificación realizada
por iteraciones y cada uno tendrá un número determinado de historias de usuario o
historias técnicas a realizar.
Persona Rol
Ing. Ligia Niama Cliente
Ing. Alejandra Oñate Coach
Ing. Ligia Niama
Ing. Alejandra Oñate Big Boss
Alexander Tubón Programadores
María José Quinatoa Programadores
Jorge Jiménez Programadores
Cecilio Tasna Programadores
Mirian Tipán Programadores
19
Alex Salazar Programadores
Tabla 1. Roles del proyecto
Los roles descritos en la tabla 1 son los definidos en base a la metodología XP. Teniendo
en total cuatro roles; como Cliente tenemos a la Ing. Ligia Niama quien financia el
desarrollo sistema web interactivo, dos Coach que conoce del proceso a informatizar,
finalmente un Programador conformado por seis personas, encargados de implementar
la solución propuesta mediante la utilización de diferentes herramientas tecnológicas.
T-SHIRT
Para el desarrollo del sistema J-PAYMENT se realizó la estimación del
proyecto, con el objetivo de realizar una planificación bien elaborada, y llevar
un control adecuado sobre el desarrollo de las actividades a realizar. En cada
Iteración es necesario calcular la estimación de cada una de ellas, por lo cual el
equipo de desarrollo hizo uso del método denominado T-Shirt.
La medición de las camisetas será basada en las letras: S, M, L, XL. Cada una
de las letras tendrá asignada la duración de tamaño de un sprint. Para los puntos
estimados es importante mencionar que cada punto tiene una equivalencia de 1
hora de trabajo.
Estas tallas se encuentran detalladas en la siguiente tabla:
Tallas Puntos Estimados
S 1–5
M 6 – 12
L 13 – 20
XL +20
Tabla 2. Método T-shirt
Requerimentación
Análisis
Para la planificación del proyecto inicialmente se realizó un análisis de requerimientos,
estos fueron considerados a partir de las ideas que surgieron en el equipo de trabajo y
como resultado del empleo de la técnica de innovación de Brain Storming.
Requerimientos
Con el objetivo de identificar el número de requerimientos funcionales y requerimientos
no funcionales se realizó una recopilación de todas ellas, con las cuales debe contar el
sistema J-PAYMENT:
Se obtuvieron un total de 35 requerimientos de los cuales se tienen:
 31 requerimientos Funcionales:
20
1. Ingresar un nuevo cliente deudor
2. Modificar un cliente deudor
3. Buscar un cliente por CI
4. Buscar un cliente por Nombre
5. Eliminar un cliente deudor
6. Generar reporte de cliente
7. Ingresar producto a inventario
8. Modificar producto en inventario.
9. Buscar producto de inventario por código.
10. Buscar producto de inventario por nombre.
11. Eliminar producto de inventario.
12. Generar reporte de producto en inventario.
13. Buscar producto por descripción.
14. Buscar producto por categoría
15. Ingresar un pedido.
16. Notificar pedido
17. Aprobar pedido.
18. Buscar un pedido por stock
19. Buscar un pedido por fecha.
20. Eliminar un pedido.
21. Generar reporte de pedido
22. Integración de cada uno de los módulos al sistema interactivo final.
23. Descargar reportes.
24. Listar clientes.
25. Listar productos en inventario.
26. Listar productos en venta.
27. Listar pedidos.
28. Notificar productos escasos en inventarios.
29. Notificar productos fuera de stock.
30. Darme de alta en el sistema con datos personales
31. Entrar al sistema por credenciales.
 4 requerimientos no funcionales:
1. Disponibilidad
2. Rendimiento
3. Usabilidad
4. Seguridad
21
Disponibilidad: al poseer una aplicación web y alojar la aplicación móvil en un
servidor web con una base de datos en un servidor externo, el sistema estará disponible
24/7.
Rendimiento: al desarrollar cada uno de los módulos, también se realizarán sus
respectivas pruebas de aceptación, esto debido a que el sistema entero deberá correr de
manera óptima en computadores de medianos recursos y de manera sobresaliente en
computadores de bajos recursos.
Seguridad: se aplicará seguridades al sistema mediante la utilización de roles para los
usuarios, cada uno poseerá un nombre de usuario y una clave de acceso.
Usabilidad: el sistema poseerá una interfaz de usuario simple y que pueda ser
comprobada por los tutores tras cada iteración.
Estos requerimientos no funcionales serán tomados en cuenta para brindar calidad y un
alto nivel de satisfacción a los usuarios del sistema J-PAYMENT.
Historias de usuario
Los requerimientos presentados con anterioridad son aquellos que dan garantía en las
diferentes funciones y características que tendrá el aplicativo web/móvil J-PAYMENT
final. Estas serán descritas a continuación con denominación de historias de usuario y
que serán desarrolladas una vez que empiecen a ser efectuadas.
1. Como comerciante deseo poder ingresar un nuevo cliente
2. Como comerciante deseo poder modificar un cliente deudor
3. Como comerciante deseo poder buscar un cliente por CI
4. Como comerciante deseo poder buscar un cliente por Nombre
5. Como comerciante deseo poder eliminar un cliente deudor
6. Como comerciante deseo poder generar un reporte de cliente deudor
7. Como comerciante deseo poder ingresar un producto a inventario
8. Como comerciante deseo poder modificar un producto en inventario.
9. Como comerciante deseo poder buscar un producto de inventario por
código.
10. Como comerciante deseo poder buscar un producto de inventario por
nombre.
11. Como comerciante deseo poder eliminar un producto de inventario.
12. Como comerciante deseo poder generar un reporte de un producto en
inventario.
13. Como cliente deseo poder buscar un producto en venta por nombre
14. Como cliente deseo poder buscar un producto en venta por comerciante
15. Como cliente deseo poder buscar un producto en venta por código
22
16. Como comerciante deseo poder ser notificado por un pedido.
17. Como comerciante deseo poder aprobar un pedido.
18. Como comerciante deseo poder buscar un pedido por código.
19. Como cliente deseo poder buscar un pedido por código.
20. Como comerciante deseo poder buscar un pedido por cliente.
21. Como comerciante deseo poder buscar un pedido por fecha.
22. Como cliente deseo poder buscar un pedido por fecha.
23. Como comerciante deseo poder eliminar un pedido.
24. Como cliente deseo poder eliminar un pedido.
25. Como comerciante deseo poder generar un reporte de un pedido.
26. Como cliente deseo poder generar un reporte de un pedido.
27. Como cliente deseo poder descargar los reportes generados.
28. Como comerciante deseo poder descargar los reportes generados.
29. Como comerciante deseo poder listar clientes.
30. Como comerciante deseo poder listar productos en inventario.
31. Como cliente deseo poder listar productos en venta.
32. Como cliente deseo poder listar pedidos.
33. Como comerciante deseo poder listar pedidos.
34. Como comerciante deseo poder ser notificado por productos escasos en
inventarios.
35. Como comerciante deseo poder ser notificado por productos fuera de stock.
36. Como comerciante deseo poder darme de alta en el sistema con datos
personales
37. Como cliente deseo poder darme de alta en el sistema con datos personales
38. Como comerciante deseo poder entrar al sistema por credenciales.
39. Como cliente deseo poder entrar al sistema por credenciales.
Historias técnicas
Existen otro tipo de requerimientos de carácter técnico que son desarrollados, sin
embargo, no cuentan como requerimientos específicos por un cliente, estos son los
llamados requerimientos técnicos o a su vez, acorde a la metodología como: historias
técnicas las cuales se presentan a continuación:
1. Como desarrollador necesito realizar el diseño de la base de datos.
2. Como desarrollador necesito realizar la implementación de la base de datos.
3. Como desarrollador necesito establecer el estándar de codificación.
4. Como desarrollador necesito definir la arquitectura del sistema.
5. Como desarrollador necesito definir el estándar de la interfaz de usuario.
23
Plan de entrega
Para el desarrollo del sistema J-PAYMENT, se definieron 31 requisitos funcionales y 4
requisitos no funcionales, los cuales fueron convertidos en historias de usuario
identificadas con una denominación de tipo HU-02, donde el 02 es el número de dicha
historia e historias técnicas denominadas como HT-03. El plan de entrega, representado
en la siguiente tabla, contiene los requerimientos del sistema los cuales se encuentran
priorizados, dentro de este se encuentran las mencionadas historias de usuario y las
historias técnicas cada uno con su prioridad y con un total de 550 puntos estimados.
Tabulación de puntos de esfuerzo estimados
ID Detalle Puntos Equivalencia

estimados T-shirt
Módulo: Historias Técnicas
HT-01 Como desarrollador necesito realizar el diseño de la base 20 L
de datos.
HT-02 Como desarrollador necesito realizar la implementación 20 L
de la base de datos.
HT-03 Como desarrollador necesito establecer el estándar de 20 L
codificación.
HT-04 Como desarrollador necesito definir la arquitectura del 20 L
sistema.
HT-05 Como desarrollador necesito definir el estándar de la 20 L
interfaz de usuario.
Módulo: Comerciante
HU-01 Como comerciante deseo poder ingresar un nuevo 20 L
cliente
HU-02 Como comerciante deseo poder modificar un cliente 10 M
deudor
HU-03 Como comerciante deseo poder buscar un cliente deudor 10 M
por CI
HU-04 Como comerciante deseo poder buscar un cliente deudor 20 L
por Nombre
HU-05 Como comerciante deseo poder eliminar un cliente 10 M
deudor
HU-06 Como comerciante deseo poder generar un reporte de 20 L
cliente deudor
24
HU-07 Como comerciante deseo poder ingresar un producto a 20 L
inventario
HU-08 Como comerciante deseo poder modificar un producto 10 M
en inventario.
HU-09 Como comerciante deseo poder buscar un producto de 10 M
inventario por código.
HU-10 Como comerciante deseo poder buscar un producto de 10 M
inventario por nombre.
HU-11 Como comerciante deseo poder eliminar un producto de 20 L
inventario.
HU-12 Como comerciante deseo poder generar un reporte de un 10 M
producto en inventario.
HU-13 Como comerciante deseo poder ser notificado por un 20 L
pedido.
HU-14 Como comerciante deseo poder aprobar un pedido. 10 M
HU-15 Como comerciante deseo poder buscar un pedido por 5 S
código.
HU-16 Como comerciante deseo poder buscar un pedido por 20 L
cliente.
HU-17 Como comerciante deseo poder buscar un pedido por 10 M
fecha.
HU-18 Como comerciante deseo poder eliminar un pedido. 10 M
HU-19 Como comerciante deseo poder generar un reporte de un 10 M
pedido.
HU-20 Como comerciante deseo poder descargar los reportes 5 S
generados.
HU-21 Como comerciante deseo poder listar clientes. 10 M
HU-22 Como comerciante deseo poder listar productos en 10 M
inventario.
HU-23 Como comerciante deseo poder listar pedidos. 20 L
HU-24 Como comerciante deseo poder ser notificado por 5 S
productos escasos en inventarios.
HU-25 Como comerciante deseo poder ser notificado por 10 M
productos fuera de stock.
25
HU-26 Como comerciante deseo poder darme de alta en el 5 S
sistema con datos personales
HU-27 Como comerciante deseo poder entrar al sistema por 10 M
credenciales.
Módulo: Cliente
HU-28 Como cliente deseo poder buscar un producto en venta 20 L
por nombre
HU-29 Como cliente deseo poder buscar un producto en venta 10 M
por comerciante
HU-30 Como cliente deseo poder buscar un producto en venta 10 M
por código
HU-31 Como cliente deseo poder buscar un pedido por código. 10 M
HU-32 Como cliente deseo poder buscar un pedido por fecha. 10 M
HU-33 Como cliente deseo poder eliminar un pedido. 10 M
HU-34 Como cliente deseo poder generar un reporte de un 20 L
pedido.
HU-35 Como cliente deseo poder descargar los reportes 5 S
generados.
HU-36 Como cliente deseo poder listar productos en venta. 10 M
HU-37 Como cliente deseo poder listar pedidos. 5 S
HU-38 Como cliente deseo poder entrar al sistema por 5 S
credenciales.
HU-39 Como cliente deseo poder darme de alta en el sistema 5 S
con datos personales
TOTAL DE PUNTOS ESTIMADOS 550
Tabla 3. Estimaciones
Tabulación de prioridad
Con el fin de conocer la prioridad de cada una de las historias de usuario del sistema y
ubicarlas en la planificación de manera correcta (alta, media, baja), se analizaron cada
una de ellas y se asignó la prioridad correspondiente:
ID Detalle Prioridad
HT-01 Como desarrollador necesito realizar el diseño de Alta

la base de datos.
26
HT-02 Como desarrollador necesito realizar la Alta
implementación de la base de datos.
HT-03 Como desarrollador necesito establecer el Alta
estándar de codificación.
HT-04 Como desarrollador necesito definir la Alta
arquitectura del sistema.
HT-05 Como desarrollador necesito definir el estándar Alta
de la interfaz de usuario.
HU-01 Como comerciante deseo poder ingresar un nuevo Alta
cliente
HU-02 Como comerciante deseo poder modificar un Alta
cliente deudor
HU-03 Como comerciante deseo poder buscar un cliente Alta
deudor por CI
HU-04 Como comerciante deseo poder buscar un cliente Alta
deudor por Nombre
HU-05 Como comerciante deseo poder eliminar un Alta
cliente deudor
HU-06 Como comerciante deseo poder generar un Alta
reporte de cliente deudor
HU-07 Como comerciante deseo poder ingresar un Alta
producto a inventario
HU-08 Como comerciante deseo poder modificar un Alta
HU-09 Como comerciante deseo poder buscar un Alta
producto de inventario por código.
HU-10 Como comerciante deseo poder buscar un Alta
producto de inventario por nombre.
producto de inventario.
reporte de un producto en inventario.
HU-13 Como comerciante deseo poder ser notificado por Alta
un pedido.
27
HU-14 Como comerciante deseo poder aprobar un Alta
pedido.
HU-15 Como comerciante deseo poder buscar un pedido Alta
por código.
por cliente.
por fecha.
pedido.
reporte de un pedido.
HU-20 Como comerciante deseo poder descargar los Alta
reportes generados.
HU-21 Como comerciante deseo poder listar clientes. Alta
HU-22 Como comerciante deseo poder listar productos Alta
en inventario.
HU-23 Como comerciante deseo poder listar pedidos. Alta
HU-26 Como comerciante deseo poder darme de alta en Alta
el sistema con datos personales
HU-27 Como comerciante deseo poder entrar al sistema Alta
por credenciales.
Módulo: Cliente
HU-28 Como cliente deseo poder buscar un producto en Alta
venta por nombre
venta por comerciante
venta por código
HU-31 Como cliente deseo poder buscar un pedido por Alta
código.
28
HU-32 Como cliente deseo poder buscar un pedido por Alta
fecha.
HU-33 Como cliente deseo poder eliminar un pedido. Alta
HU-34 Como cliente deseo poder generar un reporte de Alta
un pedido.
HU-35 Como cliente deseo poder descargar los reportes Alta
generados.
HU-36 Como cliente deseo poder listar productos en Alta
venta.
HU-37 Como cliente deseo poder listar pedidos. Alta
HU-38 Como cliente deseo poder entrar al sistema por Alta
credenciales.
HU-39 Como cliente deseo poder darme de alta en el Alta
Tabla 3: Tabulación de la prioridad y responsabilidad de Historias de usuario
En la tabla detallada anteriormente se encuentran todas las historias de usuario que

facilitan el desarrollo del sistema, en estos se encuentran las prioridades que permitirán
gestionar la aplicación de manera eficiente y sencilla.
Plan de entrega
El plan se lo realiza en base a la metodología ágil XP con el fin de completar los
objetivos de requisitos para la iteración, con la intención de mostrar al cliente un avance
del producto al finalizar cada iteración. Siguiendo la metodología el trabajo se realizará
en parejas, por cuanto cada pareja deberá justificar un trabajo conjunto de 20 horas
semanales que es lo que se trabajará por cada iteración.
En este apartado se muestran las historias de usuarios descritas en la sección de
requerimientos, ordenadas por la prioridad determinada por el cliente, asignando una
fecha de inicio y una fecha de entrega la misma en la que dichas historias se culminarán,
además de su respectiva valoración en función de puntos de esfuerzo.
Cada Iteración contará con sus respetivas tareas asignadas de acuerdo con su
estimación, esto dio como resultado 9 Iteraciones en total, que serán desarrollados para
el sistema. Los detalles en la tabla 4:
HU/HT Descripción Inicio Fin Puntos
Estimados
Iteración 1
HT-01 Como desarrollador necesito realizar 21/11/2019 27/11/2019 20
29
el diseño de la base de datos.
HT-03 Como desarrollador necesito 21/11/2019 27/11/2019 20
establecer el estándar de codificación.
HT-04 Como desarrollador necesito definir la 21/11/2019 27/11/2019 20
arquitectura del sistema.
Iteración 2
HT-02 Como desarrollador necesito realizar 28/11/2019 04/12/2019 20
la implementación de la base de datos.
HT-05 Como desarrollador necesito definir el 28/11/2019 04/12/2019 20
estándar de la interfaz de usuario.
HU-06 Como comerciante deseo poder 28/11/2019 04/12/2019 20
generar un reporte de cliente deudor.
Iteración 3
ingresar un nuevo cliente
modificar un cliente deudor
HU-03 Como comerciante deseo poder buscar 05/12/2019 11/12/2019 10
un cliente deudor por CI
un cliente deudor por Nombre
Iteración 4
eliminar un cliente deudor
ingresar un producto a inventario.
HU-10 Como comerciante deseo poder b 12/12/2019 18/12/2019 10
generar un reporte de un producto en
inventario.
modificar un producto en inventario.
Iteración 5
eliminar un producto de inventario.
30
un pedido por fecha.
generar un reporte de un pedido.
un pedido por cliente.
Iteración 6
HU-21 Como comerciante deseo poder listar 02/01/2020 08/01/2020 5
clientes.
un producto de inventario por código.
productos en inventario.
HU-34 Como cliente deseo poder generar un 02/01/2019 08/01/2020 20
reporte de un pedido.
HU-36 Como cliente deseo poder listar 02/01/2020 08/01/2020 10
productos en venta.
HU-39 Como cliente deseo poder darme de 02/01/2019 08/01/2020 5
alta en el sistema con datos personales
HU-38 Como cliente deseo poder entrar al 02/01/2020 08/01/2020 5
sistema por credenciales.
Iteración 7
eliminar un pedido.
HU-33 Como cliente deseo poder eliminar un 09/01/2020 15/01/2020 10
pedido.
HU-37 Como cliente deseo poder listar 09/01/2020 15/01/2020 5
pedidos.
pedidos.
HU-35 Como cliente deseo poder descargar 09/01/2020 15/01/2020 5
los reportes generados.
HU-24 Como comerciante deseo poder ser 09/01/2020 15/01/2020 5
notificado por productos escasos en
inventarios.
31
un pedido por código.
Iteración 8
descargar los reportes generados.
HU-26 Como comerciante deseo poder darme 16/01/2020 22/01/2020 5
de alta en el sistema con datos
personales
HU-27 Como comerciante deseo poder entrar 16/01/2020 22/01/2020 10
al sistema por credenciales.
notificado por un pedido.
aprobar un pedido.
notificado por productos fuera de
stock.
Iteración 9
HU-31 Como cliente deseo poder buscar un 23/01/2020 29/01/2020 10
pedido por código.
pedido por fecha.
producto en venta por comerciante
producto en venta por código
producto en venta por nombre
Tabla 4. Plan de entrega
32
PLAN DE GESTIÓN DEL PROYECTO
1. PLAN PARA LA DIRECCIÓN DEL PROYECTO

El Plan para la Dirección del Proyecto está compuesto de los diferentes planes que constituyen
la planificación del proyecto. Es un documento central que define la base para la elaboración
del proyecto. Define la manera en que el proyecto será planificado, ejecutado, monitoreado y
controlado, hasta su cierre. Éste se desarrolla a través de una serie de procesos teniendo en
cuenta siempre las actualizaciones necesarias a efectuar, las cuales son controladas y
aprobadas por el comité de control de cambios luego.
NOMBRE DEL PROYECTO
“APLICACIÓN WEB Y MÓVIL PARA EL CONTROL
DE INVENTARIOS Y DE CUENTAS POR COBRAR “
PROCESOS DE GESTIÓN DE PROYECTOS: Descripción detallada de los procesos de gestión de

proyectos que han sido seleccionados por el equipo de proyecto para gestionar el proyecto.
NIVEL DE MODO HERRAMIE
PROCES INPUT OUTPUTS
IMPLANT DE NTAS Y
O ACIÓN S
TRABAJ TÉCNICAS
O
Desarrollar el Al inicio -Contrato Reuniones -Acta de Plantillas
Acta de del -Enunciado entre el Constitución
Constitución proyecto del trabajo Gerente del del Proyecto
del Proyecto del proyecto
Proyecto
Planificar Al inicio del -Acta de Reuniones -Plan de Plantillas
el Alcance proyecto. Se Constitució del equipo Gestión del
puede n del del proyecto Alcance del
actualizar Proyecto Proyecto
-Enunciado
del Alcance
del Proyecto
-Plan de
Gestión
del
Proyecto
Crear EDT Al inicio -Plan de Reuniones -EDT Plantillas
del Gestión del equipo de EDT,
proyecto del del proyecto Descomposición
Alcance del trabajo
del
Proyecto
Desarrollar Al inicio -Enunciado Reuniones -Cronograma Plantillas
Cronogram del del Alcance del equipo del proyecto
a proyecto. del del proyecto -Ruta crítica del
Proyecto proyecto
33
Determinar Al inicio -Enunciado Reuniones -Plan de Suma de
el del del Alcance del equipo gestión de costos.
Presupuesto proyecto del de dirección costos
Proyecto del proyecto
Planificar Al inicio -Enunciado Reuniones -Plan de Plantillas

la Calidad del del Alcance del equipo Gestión de
proyecto del de dirección Calidad
Proyecto del proyecto -Métrica
de
Calidad
Planificar Al inicio -Plan de Reuniones -Roles y Organigramas y
la gestión del Gestión del equipo Responsabilidade descripción de
de RRHH proyecto del del proyecto s cargos
proyecto -Organigrama
del Proyecto
Planificar las Al inicio - Reuniones -Plan de Análisis de
Comunicacione del Enunciado del equipo gestión de las requisitos de
s proyecto del del proyecto comunicacione comunicaciones.
Alcance s Tecnologías
del proyecto para las
comunicaciones
Planificar Al inicio -Plan de Identifica -Plan de Reuniones de
la Gestión del Gestión r riesgos. gestión de planificación.
de proyecto, del riesgos
Riesgos actualizabl proyecto
e
Planificar Al inicio -Plan de Planificar -Plan de Tipos de
las del gestión del adquisiciones gestión de las contrato,
Adquisicion proyecto proyecto Solicitar adquisiciones análisis de
es presupuestos proveedores
Negociar
cotizaciones
Firmar
contrato
Dirigir y Durante -Plan de Reuniones -Entregables Metodología
gestionar la todo el gestión del de -Solicitudes de PMI
Ejecución proyect proyecto información cambio
del o -Solicitudes del estado implementadas
Proyecto de cambio del proyecto -Informe de
aprobadas rendimiento
del
trabajo
Monitorear Durante -Plan de Reuniones -Acciones Metodología
y Controlar todo el gestión del de correctivas PMI
el Trabajo proyect proyecto coordinació
del o - n Reuniones
Proyecto Información de
sobre el información
rendimiento
del estado
del trabajo
del proyecto
Cerrar Al finalizar -Plan de Reuniones -Transferencia Metodología
el el proyecto gestión del del equipo del producto PMI
proyect proyecto del proyecto
o
34
ENFOQUE DE TRABAJO: Descripción detallada del modo en que se realizará el trabajo del proyecto
para lograr los objetivos del proyecto.
El proyecto se planificará de tal forma que las partes involucradas en el desarrollo del mismo conozcan
las partes y procesos necesarios para poder completar el proyecto satisfactoriamente. A continuación,
se indica la forma de realización del proyecto:
1. El equipo de trabajo planifica de forma general el proyecto

2. Se determina el alcance.
3. Se generan el cronograma de actividades.
4. Se asignan roles dentro del equipo de trabajo.
5. Se programan reuniones semanales para monitoreo del proyecto y retroalimentación de los
procesos.
6. Se validan los entregables al finalizar cada uno.
PLAN DE GESTIÓN DE CAMBIOS: Descripción de la forma en que se monitorearán y controlarán

los cambios, incluyendo el qué, quién, cómo, cuándo, dónde.
Los cambios se gestionarán de tal forma que se puedan evaluar, aplicar e informar correcta y
efectivamente:
1. Solicitud realizada (Por personal involucrado en el proyecto)
2. Evaluación del cambio.
3. Aceptación del cambio o escalamiento del mismo.
4. Comunicación del cambio
5. Realización del cambio
6. Modificación de la planificación y líneas base
Aplicación del cambio e informe a los interesados
GESTIÓN DE LÍNEAS BASE: Descripción de la forma en que se mantendrá la integridad, y se

usarán las líneas base de medición de performance del proyecto, incluyendo el qué, quién, cómo,
cuándo, dónde.
Quincenalmente, en cada reunión de seguimiento se presentarán los documentos del estado actual del
proyecto en donde debe estar la siguiente información:
1. Tiempo planificado y tiempo real
2. Cumplimiento del cronograma
3. Cumplimiento de objetivos de calidad
De acuerdo a la anterior información se generará lo siguiente:
1. Pronóstico de tiempo
COMUNICACIÓN ENTRE EQUIPO: Descripción detallada de las necesidades y técnicas de

comunicación entre los miembros del proyecto.
NECESIDADES DE TÉCNICAS DE COMUNICACIÓN A
COMUNICACIÓN UTILIZAR
Planeación del proyecto Reuniones por parte del equipo del trabajo.
Los documentos generados de estas reuniones se
comunicarán mediante medio impreso y correo
electrónico.
Coordinación de las actividades del proyecto Reuniones por parte del equipo del trabajo.
Los documentos generados de estas reuniones se
comunicarán mediante medio impreso y correo
electrónico.
Estado del proyecto Reuniones por parte del equipo del trabajo. Los
documentos
generados de estas reuniones se comunicarán
mediante medio impreso y correo electrónico.
35
Rendimiento del proyecto Reuniones por parte del equipo del trabajo. Los
documentos
generados de estas reuniones se comunicarán
mediante medio impreso y correo electrónico.
REVISIONES DE GESTIÓN: Descripción detallada de las revisiones claves de gestión que

facilitarán el abordar los problemas no resueltos y las decisiones pendientes.
TIPO DE REVISIÓN ALCANCE OPORTUNIDAD
DE CONTENIDO (Forma en que se (Momentos,
GESTIÓN (Puntos a tratar en la desarrollará la frecuencias, o
(Tipo de reunión en reunión de revisión
la cual se realizará la reunión.) eventos.)
de gestión)
revisión de gestión)
Reuniones Revisión de planes y Reunión presidida por el Todos los
semanales actas. Gerente de Proyecto, miércoles de cada
asisten los miembros del semana del mes.
equipo.
Reuniones mensuales Revisión del Reunión presidida por el Fin de mes

estado del Gerente de Proyecto,
proyecto. asisten los miembros del
equipo.
Reuniones con cliente Agenda según Reunión solicitada por Programación

y miembros del solicitud del cliente, asiste el del cliente
equipo del proyecto cliente, Gerente de proyecto y
los miembros del equipo
LÍNEA BASE Y PLANES SUBSIDIARIOS: Definición de planes subsidiarios que se adjuntan
LÍNEA BASE PLANES SUBSIDIARIOS

ADJUN ADJU
DOCUM TIPO DE
TO NTO
ENTO PLAN
(SI/NO) (SI/NO
)
ALCANCE SI PLAN DE GESTIÓN DE ALCANCE SI
PLAN DE GESTIÓN DE SI
REQUISITOS
TIEMPO SI PLAN DE GESTIÓN DE COSTOS SI

PLAN DE GESTIÓN DE CALIDAD SI
COSTO SI PLAN DE RECURSOS HUMANOS SI

COMUNICACIONES
PLAN DE GESTIÓN DE RIESGOS SI
ADQUISICIONES
Ilustración 2: Plan para la dirección del proyecto
36
2. PLAN DE GESTIÓN DE INTEGRACIÓN
PLAN DE GESTIÓN DE INTEGRACIÓN
Proyecto “APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE INVENTARIOS Y DE

CUENTAS POR COBRAR “
Preparado por: Jorge Jiménez – Líder del equipo de desarrollo Fecha 31/01/2019
Revisado por: Equipo del Proyecto Fecha 31/01/2019
Aprobado por: María José Quinatoa – Gerente del Proyecto Fecha 31/01/2019
ACTA DE CONSTITUCIÓN – J-CAMP S.L.
PROYECTO: “APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE

INVENTARIOS Y DE CUENTAS POR COBRAR “
NOMBRE DEL DOCUMENTO:
FECHA DE CREACIÓN: 8 de noviembre de 2019
AUTORES:
JIMENEZ RIVADENEYRA JORGE ANTONIO (6087)
QUINATOA GUANO MARÍA JOSÉ (6216)
TASNA TISALEMA CECILIO KURICAMAC (6097)
TIPÁN GUAMAN MIRIAN PATRICIA (5982)
TUBÓN USCA BRANDON ALEXANDER (6214)
REVISIÓN:
37
DESCRIPCIÓN DEL PROYECTO
Nuestro proyecto se denomina “APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE
INVENTARIOS Y DE CUENTAS POR COBRAR “, consiste en el desarrollo de una aplicación web y
móvil nativa para el control de inventarios de microempresas distribuidoras de cualquier tipo de
productos y la gestión en el control de cuentas por cobrar de las mismas, esto se realizará mediante la
metodología XP utilizando lenguajes de programación Java , Dart, base de datos MySQL, toolkit de
Flutter y REST como protocolo de intercambio y manipulación de datos en los servicios de internet.
La aplicación será desarrollada en el periodo Noviembre 2019 – Enero 2020 en la ciudad de Riobamba.
DESCRIPCIÓN DEL PRODUCTO

Nuestro producto se denominará “J-PAYMENT” consiste en un aplicativo tanto web y móvil para el
control de inventarios y de cuentas por cobrar de las microempresas distribuidoras de productos a nivel
nacional.
OBJETIVOS
❏ Dar a conocer a nuestros potenciales clientes las ventajas y beneficios organizacionales y
financieros que obtendrían al formar parte de nuestra tecnología de gestión de inventarios y
control de cobros.
❏ Desarrollar software de calidad mediante la adecuación de procesos y buenas prácticas para
mejorar la posición competitiva y los procesos de negocios de nuestros clientes.
❏ Realizar la planificación y definir una serie de actividades con su respectiva duración y
aportación para lograr así definir el tiempo estimado del proyecto.
❏ Calcular el presupuesto del proyecto.
CRITERIOS DE ÉXITO
 El punto clave del desarrollo del proyecto consiste en la sección de control de cuentas por
cobrar, módulo que facilitará el proceso de cobro de las entidades distribuidoras con sus
comerciantes respectivos, debido a que una de las principales causas de cierre y quiebre de las
organizaciones distribuidoras es la gestión de sus cuentas por cobrar.
 El manejo de licencias anuales a un valor accesibles asegurará que la adquisición del producto
software sea más flexible y cómodo para las empresas distribuidoras interesadas en gestionar
sus procesos de cobros.
 Un aplicativo web que administre y controle el inventario de las empresas distribuidoras

influenciará en el control del proceso de cobros, ya que de esta manera la empresa distribuidora
tendrá conciencia exacta acerca de cuantos productos han sido solicitados por los comerciantes
para su posterior venta.
38
REQUISITOS DE APROBACIÓN DEL PROYECTO
Con el objetivo de identificar el número de requerimientos funcionales y requerimientos no
funcionales se realizó una recopilación de todas ellas, con las cuales debe contar el sistema J-
PAYMENT:
Se obtuvieron un total de 31 requerimientos funcionales y 4 no funcionales que se detalla a
continuación.
 31 requerimientos Funcionales:
32. Ingresar un nuevo cliente deudor
33. Modificar un cliente deudor
34. Buscar un cliente por CI
35. Buscar un cliente por Nombre
36. Eliminar un cliente deudor
37. Generar reporte de cliente
38. Ingresar producto a inventario
39. Modificar producto en inventario.
40. Buscar producto de inventario por código.
41. Buscar producto de inventario por nombre.
42. Eliminar producto de inventario.
43. Generar reporte de producto en inventario.
44. Buscar producto por descripción.
45. Buscar producto por categoría
46. Ingresar un pedido.
47. Notificar pedido
48. Aprobar pedido.
49. Buscar un pedido por stock
50. Buscar un pedido por fecha.
51. Eliminar un pedido.
52. Generar reporte de pedido
53. Integración de cada uno de los módulos al sistema interactivo final.
54. Descargar reportes.
55. Listar clientes.
56. Listar productos en inventario.
57. Listar productos en venta.
58. Listar pedidos.
39
59. Notificar productos escasos en inventarios.
60. Notificar productos fuera de stock.
61. Darme de alta en el sistema con datos personales
62. Entrar al sistema por credenciales.
 4 requerimientos no funcionales:
1. Disponibilidad
2. Rendimiento
3. Usabilidad
4. Seguridad
FINALIDAD DEL PROYECTO

Nuestro proyecto tiene como fin brindar un beneficio importante a las empresas distribuidoras de
cualquier tipo de productos a nivel nacional, ya que busca principalmente gestionar el proceso de cobros
de sus cuentas por cobrar.
ENTREGABLES PRINCIPALES
El resultado del producto o servicio final de nuestro proyecto es una aplicación web y una aplicación
móvil para la gestión de inventarios y para la parte de los cobros de las cuentas por cobrar.
JUSTIFICACIÓN DEL PROYECTO
El proceso de cobranza de las organizaciones dedicadas a la distribución de cualquier tipo de productos,
suele ser un proceso complicado de gestionar debido a que se debe esperar que los comerciantes
contratados ejecuten exitosamente una venta, por este motivo se los suele brindar de plazos para que
vendan los productos solicitados.
Sin embargo, dicho plazo suele tornarse muchas veces en meses, y debido a la gran cantidad de
distribuidores y cotas, se suele reducir el grado de presión ejercido por parte de la or ganización
distribuidora con sus comerciantes contratados para efectuar el proceso de cobranza. Pasando a
generarse muchas veces cuentas incobrables.
Las cuentas por cobrar representan un crédito y una manera fácil de obtener productos que las
microempresas ofrece a sus clientes, sin más garantía que la promesa de pago oral o escrito, en un corto
plazo determinado por la empresa o entre mutuo acuerdo entre el comerciante y el distribuidor.
Un sistema de cuentas por cobrar es parte fundamental para que los procesos de cobro se lleven a cabo,
evitando que las cuentas incobrables sean mayores a las estimadas, para así tener un beneficio y que las
microempresas puedan evidenciar de manera más clara y especifica los problemas que presentan en la
cobranza y poder mejorar el procedimiento de cobro que aplica las empresas a sus clientes.
PRINCIPALES INTERESADOS
Nuestro proyecto abastecerá problemas de cobros de las cuentas donde los principales interesados son
las siguientes personas:
40
NOMBRE ROL
Ing. Alejandra Oñate Consultor

Gerente de empresas Cliente
(Ing. Ligia Niama)
María José Quinatoa Gerente del proyecto
Jorge Jiménez Desarrollador
Alexander Tubón Desarrollador
Alex Salazar Desarrollador
Cecilio Tasna Desarrollador
María Quinatoa Desarrollador
Miriam Tipan Desarrollador
Empresas desarrolladoras Competencia
de software
RIESGOS INICIALES
Análisis de FODA
Fortalezas
 Conocimiento del medio informativo y redes para promocionar e informar sobre nuestro producto.
 Somos un equipo con muchas ganas de trabajar para brindar un mejor servicio en los inventarios y
cobros de las cuentas de las microempresas.
 Somos un equipo con experiencia en el desarrollo de proyectos de páginas similares.
 Tener una gran pasión y vocación para poder iniciar con este proyecto.
Oportunidades
 Grandes tendencias a las cuentas por cobrar vía online.
 En el mercado existe la necesidad de realizar las cuentas por cobrar de forma online, mediante
comprobantes electrónicos, ya que este sistema solo existe en otros países.
 Posibilidad de incrementar más cliente a través de este producto.
 Poder evidenciar de manera más clara y especifica los problemas que presentan en la cobranza de
los productos.
Debilidades
 Falta de reconocimiento de la empresa dentro del mercado.
 Poco capital de inversión.
41
 Irresponsabilidad al momento de trabajar en equipo sobre este proyecto.
 Falta de experiencia en las áreas de administración, economía y mercadotecnia.

Amenazas
 Posible entrada de nuevos competidores al mercado.
 Desconfianza inicial de los consumidores al ser una nueva empresa.

 Posible saturación del mercado debido por la existencia de muchas ofertas.
DURACIÓN E HITOS
Para el desarrollo del sistema J-PAYMENT se realizó la estimación del proyecto, con el objetivo de
realizar una planificación bien elaborada, y llevar un control adecuado sobre el desarrollo de las
actividades a realizar. En cada Iteración es necesario calcular la estimación de cada una de ellas, por lo
cual el equipo de desarrollo hizo uso del método denominado T-Shirt, la siguiente tabla muestra los
detalles los puntos de esfuerzos estimados.
ID Detalle Puntos
estimados
HT-01 Como desarrollador necesito realizar el diseño de la base 20
de datos.
HT-02 Como desarrollador necesito realizar la implementación 20
de la base de datos.
HT-03 Como desarrollador necesito establecer el estándar de 20
codificación.
HT-04 Como desarrollador necesito definir la arquitectura del 20
sistema.
HT-05 Como desarrollador necesito definir el estándar de la 20
interfaz de usuario.
HU-01 Como comerciante deseo poder ingresar un nuevo 20
cliente
HU-02 Como comerciante deseo poder modificar un cliente 10
deudor
HU-03 Como comerciante deseo poder buscar un cliente deudor 10
por CI
42
HU-04 Como comerciante deseo poder buscar un cliente deudor 20
por Nombre
HU-05 Como comerciante deseo poder eliminar un cliente 10
deudor
HU-06 Como comerciante deseo poder generar un reporte de 20
cliente deudor
HU-07 Como comerciante deseo poder ingresar un producto a 20
inventario
HU-08 Como comerciante deseo poder modificar un producto 10
en inventario.
HU-09 Como comerciante deseo poder buscar un producto de 10
inventario por código.
HU-10 Como comerciante deseo poder buscar un producto de 10
inventario por nombre.
HU-11 Como comerciante deseo poder eliminar un producto de 20
inventario.
HU-12 Como comerciante deseo poder generar un reporte de un 10
HU-13 Como comerciante deseo poder ser notificado por un 20
pedido.
HU-14 Como comerciante deseo poder aprobar un pedido. 10
HU-15 Como comerciante deseo poder buscar un pedido por 5
código.
cliente.
fecha.
HU-18 Como comerciante deseo poder eliminar un pedido. 10
HU-19 Como comerciante deseo poder generar un reporte de un 10
pedido.
HU-20 Como comerciante deseo poder descargar los reportes 5
generados.
HU-21 Como comerciante deseo poder listar clientes. 10
HU-22 Como comerciante deseo poder listar productos en 10
inventario.
43
HU-23 Como comerciante deseo poder listar pedidos. 20
HU-24 Como comerciante deseo poder ser notificado por 5
HU-25 Como comerciante deseo poder ser notificado por 10
HU-26 Como comerciante deseo poder darme de alta en el 5
HU-27 Como comerciante deseo poder entrar al sistema por 10
credenciales.
HU-28 Como cliente deseo poder buscar un producto en venta 20
por nombre
por comerciante
por código
HU-31 Como cliente deseo poder buscar un pedido por código. 10
HU-32 Como cliente deseo poder buscar un pedido por fecha. 10
HU-33 Como cliente deseo poder eliminar un pedido. 10
HU-34 Como cliente deseo poder generar un reporte de un 20
pedido.
HU-35 Como cliente deseo poder descargar los reportes 5
generados.
HU-36 Como cliente deseo poder listar productos en venta. 10
HU-37 Como cliente deseo poder listar pedidos. 5
HU-38 Como cliente deseo poder entrar al sistema por 5
credenciales.
HU-39 Como cliente deseo poder darme de alta en el sistema 5
con datos personales
TOTAL DE PUNTOS ESTIMADOS 550
PRESUPUESTO
Estimación del Presupuesto
Total, de puntos estimados: 760
Relación de puntos: 1 𝑝𝑢𝑛𝑡𝑜 = 1 ℎ𝑜𝑟𝑎
Cantidad de horas por semana por pareja: 20 horas
Cantidad de parejas: 3
44
Cantidad de horas por mes: 20 ℎ𝑜𝑟𝑎𝑠 ∗ 3 ∗ 4 = 240 ℎ𝑜𝑟𝑎𝑠
𝑇𝑜𝑡𝑎𝑙𝑑𝑒ℎ𝑜𝑟𝑎𝑠
Tiempo de desarrollo:
𝐻𝑜𝑟𝑎𝑠𝑝𝑜𝑟𝑚𝑒𝑠
760ℎ𝑜𝑟𝑎𝑠
= 3.2 𝑚𝑒𝑠𝑒𝑠
240ℎ𝑜𝑟𝑎𝑠
Salario Mensual por persona: $550
PRESUPUESTO RECURSO HUMANO
En el desarrollo de un proyecto es necesario saber cuál es el recurso humano con el que contamos para
poder llevar a cabo el mismo, así como importante saber cuáles son los honorarios que percibirá cada
una de las personas involucradas y las habilidades y destrezas del equipo de trabajo.
Para determinar el presupuesto con el que cuenta el equipo de trabajo, se necesita determinar el salario
que se ocupara para realizar el proyecto, por ello se basó en la investigación de (Sarmiento, 2017) para
obtener el salario de un Ing. En Sistemas en Ecuador, el cual el autor lo define en $1100 las 8 horas,
pero el grupo al estipular un horario de trabajo de 4 horas define el salario para los cálculos respectivos
dependiendo del cargo que ellos ocupen dentro de la empresa.
NOMBRE ROL SALARIO SALARIO

UNITARIO * Tiempo
Ing. Alejandra Consultor N/S N/S
Oñate
Ing. Ligia Niama Cliente N/S N/S
Jorge Jiménez Desarrollador $300,00 $1200,00
Alexander Tubón Desarrollador $355,00 $1420,00
Alex Salazar Marketing $300,00 $1200,00
Cecilio Tasna Desarrollador $320,00 $1280,00
María Quinatoa Gerente $400,00 $1600,00
Mirian Tipan Desarrollador $328,00 $1312,00
∑ 𝑠𝑎𝑙𝑎𝑟𝑖𝑜 $8012,00
El gasto que incurre el pago de los salarios de los desarrolladores durante el desarrollo del proyecto es
de $8012,00.
45
PRESUPUESTO EQUIPOS Y SERVICIOS.
Es importante saber cuál va a ser el presupuesto que el equipo de trabajo va a tener entre equipos y
servicios, pues estos recursos van a ser utilizados para poder realizar el proyecto y tener el valor de
presupuesto que vaya a ser sumado al presupuesto total del proyecto.
Para la consideración del presupuesto que se necesitaría en equipos y servicios, el equipo de trabajo
sumo los gastos de servicios y depreciación de equipos que se necesitaría en el periodo de duración del
proyecto.
PRESUPUESTO FINAL
Descripción  Total 
Presupuesto  equipos $ 5550,00
Presupuesto RRHH  $ 8012,00
Total:  $ 13562,00
SPONSOR
Nuestro proyecto es autorizado por la ingeniera Ligia Niama y la ingeniera Alejandra Oñate.
DIRECTOR DEL PROYECTO
María José Quinatoa
46
3. PLAN DE GESTIÓN DE ALCANCE
2.1. Declaración del Alcance
DECLARACIÓN DEL ALCANCE
Proyecto “APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE INVENTARIOS

Y DE CUENTAS POR COBRAR “
Preparado por: Jorge Jiménez – Líder del equipo de desarrollo Fecha 20/11/2019
1. ALINEAMIENTOS DEL PROYECTO

OBJETIVOS ESTRATÉGICOS DE LA PROPÓSITO DEL PROYECTO
ORGANIZACIÓN
2.1 Operación continua y uniforme. Con el
1.1 Desarrollar software de calidad, en tiempo y
sistema de control se evitarán perjuicios
bajo presupuesto que ayude al control del sector
generados por pérdidas de inventarios y
administrativo de las empresas distribuidoras y
administración de pagos, ayudando al aparato
comerciantes del Ecuador.
económico del país.
2.2 Mayor poder adquisitivo. Una vez
implementado el sistema, y viéndose gestionado
1.2 Gestionar el control de pagos y actividad
y mejorado el proceso de cobranza, los clientes
financiera de las empresas distribuidoras.
de dichas empresas se verán en la capacidad de
mejorar su poder de adquisición
2.3 Mejor Supervisión y capacidad de control.
Al manejarse con un sistema que permita zanjar
1.3 Organizar el control de inventarios y
la cuestión inventarios, las empresas
productos diferidos de las empresas
distribuidoras podrán dedicar sus esfuerzos sobre
distribuidoras.
otros sectores de su órgano productivo
empresarial.
2. OBJETIVOS DEL PROYECTO
3.1 Poner en marcha el sistema de control de pagos y gestión de inventarios, bajo un presupuesto
máximo de 13562,00 USD.
3.2 Concluir exitosamente con las fases y planes de gestión establecidos por la guía de gestión de
47
proyectos de PMBOK 5ta Edición.
3.3 Desarrollar la primera versión del sistema para la cliente Ing. Ligia Niama, gerente de la empresa
distribuidora de libros CIEAL.
3. FACTORES CRÍTICOS DE ÉXITO DEL PROYECTO
4.1 Lograr distribuir la herramienta de software propuesta a la mayor cantidad de distribuidores del
mercado a nivel nacional.
4.2 Diseño y desarrollo del producto software de acuerdo con los requerimientos establecidos por las
partes interesadas.
4.3 Manejo en términos y normas de calidad correspondientes al desarrollo de software (ISO 9001,
ISO 25000).
4. DESARROLLO DE LA PROPUESTA
DESCRIPCIÓN DEL PRODUCTO DEL PROYECTO
Con el propósito de identificar las características, funcionalidades del sistema, soporte técnico y
servicio post venta, entre otros. Se procede a realizar la descripción del producto obtenido una vez
concluido el proyecto.
El proceso consiste en la interacción de dos partes interesadas, la primera parte son las entidades
(distribuidoras) de productos (sea cual sea) a nivel nacional, y la segunda los conocidos como
proveedores de dichas entidades, que no son más que gente encargada de hacer llegar dichos
productos de las empresas expendedoras (mediadores), hacia un posible sector del
mercado(demanda).
Para alcanzar este propósito se establecerá un producto software con 2 contemplaciones importantes,
la gestión del inventario de productos de las empresas distribuidoras, y los productos solicitados a las
mismas por parte de los clientes que posean y el complemento de este proceso al efectuar el cobro de
sus productos solicitados por los mismos una vez transcurrida su venta.
DESCRIPCIÓN DE LOS ENTREGABLES DEL PROYECTO
ENTREGABLE DESCRIPCIÓN
Para el diseño
La arquitectura escogida para la implementación
del sistema de control de inventarios y pagos es
Arquitectura del sistema de n capas, debido a su facilidad de acoplamiento
entre capas y acoplamiento con el desarrollo
móvil como parte inherente del proyecto
Para el manejo de la interfaz del usuario dividida
Modelo Vista Controlador en 2 categorías, la categoría web y móvil, se ha
optado por el modelo, vista, controlador, debido
48
a que la estructura controladora permitirá la
administración y control de las dos vistas
presentes en el sistema. la del computador y la del
aplicativo móvil.
Se ha optado por manejar la base de datos
MySQL gracias a que es considerada como la
Base de Datos
más estable y segura en cuanto al acoplamiento
entre capas de comunicación y almacenamiento.
Para el desarrollo de la aplicación se ha optado
hacer referencia a las metodologías ágiles, siendo
la de eXtremme Programming la identificada
Metodología Ágil XP como la más adecuada debido a sus iteraciones de
software funcional semanal, a diferencia de las
demás metodologías ágiles como SCRUM que
propone software funcional en intervalo mensual.
Listado de Hardware y Software requerido Para el desarrollo de la aplicación se ha
identificado como tecnología requerida en primer
lugar un IDE de desarrollo adecuado para el
proceso de gestión de inventarios, siendo el IDE
de Java mediante su Plataforma de Trabajo o
Framework WordPress identificado como
óptimo. Para el aplicativo móvil se optó por hacer
uso de Flutter.
Requerimiento de adquisiciones
Consiste en un documento que identifica las
licencias respectivas que serán proporcionadas a
las entidades distribuidoras como parte del
Hardware y Software del Sistema Cliente / servicio, esto incluye claves, credenciales,
Servidor ayudas al usuario y manuales, de igual manera
consta de un documento que indica los
requerimientos mínimos del dispositivo móvil
para su correcto funcionamiento.
Este anexo consiste en un servicio de
capacitación explicando el funcionamiento de las
Servicio de Programación y Capacitación
dos partes del sistema, tanto la web como la
móvil, y un conjunto de buenas prácticas para
49
lograr un mejor aprovechamiento, así como un
documento donde constan todos los procesos
técnicos que abarcan el sistema, conocido como
manual técnico.
Implementación
El software que al final cumpla con los objetivos
El producto final
y metas establecidas.
Arranque del Sistema
Consiste en un proceso en el que se pondrá a
prueba el grado de acoplamiento adecuado entre
la parte web con la móvil, mediante la
Pruebas de comunicación entre herramientas herramienta identificada como controlador, ya
que este último es el encargado de recolectar
información proporcionada tanto por la acción
web como la acción móvil.
Una vez desarrollado el sistema y puesto en
explotación, según las políticas de la empresa y
las del departamento de desarrollo, se facilitará
Soporte técnico asistido un soporte técnico asistido gratuito de 3 meses,
periodo durante el cual, el equipo desarrollador
se verá en la obligación de socorrer al usuario
sobre cualquier cuestión si así éste lo requiere.
Cierre
Una vez concluido el proceso y obtenido un
producto software funcional, el usuario obtendrá
un informe en el que se presente el total de
Informe de pruebas aprobadas del sistema de funcionalidades implementadas exitosamente,
control además de un control de pruebas realizadas en el
mismo para garantizar así el correcto grado
operacional del mismo según el grado de calidad
propuesto.
El usuario tendrá a su disponibilidad 2 manuales,
uno técnico enfocado hacia un sector informático
Manuales técnicos y de usuario del sistema en caso de que se requiera seguir trabajando sobre
las funcionalidades del sistema con otro equipo,
y un manual de usuario enfocado netamente al
50
consumidor, donde estarán plasmadas
instrucciones para el uso y funcionamiento del
sistema.
RESPONSABLES DE APROBACIÓN FORMAL DE LOS ENTREGABLES DEL
PROYECTO
Responsable Rol
María José Quinatoa Guano Gerente del Proyecto
Jorge Antonio Jiménez Rivadeneira Líder del equipo de desarrollo
5. CONTEXTO DEL PROYECTO
LÍMITES Y EXCLUSIONES DEL PROYECTO
El sistema únicamente está en la capacidad de notificar el plazo de tiempo que el mediador dispone
para efectuar el pago del material solicitado al distribuidor, mas no ninguna vía de obligar al mediador
de efectuar el valor deudor.
El sistema no puede garantizar que una vez concluida la fecha límite de pago, el mediador procederá
a cancelar el valor debido.
RESTRICCIONES
Por políticas de la empresa y manejo de capital, el sistema no incluye ningún módulo mediante el
cual un cliente de nuestros usuarios distribuidores pueda efectuar el pago directamente a los mismos.
El sistema en su versión móvil no está diseñado para todo tipo de dispositivos móviles (véase la
sección de requerimiento de adquisiciones).
GESTIÓN DE LOS CAMBIOS EN EL ALCANCE Y APROBACIONES
Los cambios en el alcance se deberán notificar para ser adecuados hasta como máximo durante la
fase de planificación del proyecto, esto debido a que resultaría difícil tener que cambiar, modificar o
agregar nuevos aspectos al proyecto durante el desarrollo, donde el tiempo juega un papel clave a la
hora de cumplir con lo previsto y planificado, en concordancia además con los planes de gestión
correspondientes.
Para efectuar un cambio en el alcance se deberá convocar a una reunión oportuna con el equipo
completo de J-CAMP, además de contar con la presencia de nuestra consultora y cliente para la
formalización del cambio. Si este es aprobado en conjunto durante dicha reunión se redactará un
documento legal que, una vez aprobado, se archivará y comenzará la adecuación de el o los cambios
previstos.
El documento de referencia que se tendrá en cuenta para la formalización de los cambios en el alcance
se encuentra en la sección correspondiente a la “Gestión de los Interesados” en el apartado de
“Solicitudes de Cambio”
GESTIÓN DE CAMBIOS QUE NO REQUIEREN REVISIÓN PARA SER APROBADOS
51
Los únicos cambios que se formalizarán simplemente a través del documento legal de “Solicitud de
los cambios” sin previa aprobación, son aquellos que provengan del equipo de trabajo, de nuestra
consultora y/o cliente, esto se encuentra ya acordado y no puede sujetarse a cambio alguno.
PLANES QUE SON AFECTADOS AL HABER CAMBIOS EN EL ALCANCE
Para la toma de decisiones en la aceptación de algún cambio en el alcance es necesario tener en cuenta
los planes que necesariamente deberán ser analizados para su correspondiente actualización:
- Plan de Gestión del Tiempo: Lo que se encuentra planificado y organizado acorde a un
cronograma ya establecido, no se puede cumplir en el tiempo previsto si se ha alterado la
organización de las actividades a realizarse.
- Plan de Gestión del Alcance: Es el primero en ser afectado en su composición.
- Plan de Gestión de la Integración: La gestión de la integración comprende un apartado
dedicado al alcance en el proyecto.
- Plan de Gestión del Costo: Cualquier cambio en la estructura de un proyecto genera nuevos
costos o recorte de aquellos que estaban previstos.
FACTORES QUE, PARA EFECTOS DE PLANIFICACIÓN, SE CONSIDERARÁN
VERDADERAS, SIN LA NECESIDAD DE PRUEBAS O EVIDENCIA FÍSICA (asunciones)
 La versión actual del sistema es la 1.0.0
 Para la fase de levantamiento del sistema, se cuenta con un servidor y una base de datos local
 Los manuales tanto técnicos como de usuario cuentan con la información suficiente y
detallada para lograr independencia de los lectores.
2.2. Gestión de los requisitos

PLAN DE GESTIÓN DE REQUISITOS

Preparado por: Jorge Jiménez –Líder del equipo de desarrollo Fecha 20/11/2019
RECOPILACIÓN DE REQUISITOS
1.- Entrevistas al cliente.
2.- Entrevista personal con los Proveedores.
PRIORIZACIÓN DE REQUISITOS
Para la priorización de requerimientos utilizaremos un listado de todos los requerimientos clasificándolos
en una escala del 1 al 10 donde consideraremos el poder (Capacidad de cada interesado en hacer cumplir
52
su requerimiento) y el impacto (Cuanto puede afectar el requerimiento al proyecto), el porcentaje de
influencia en la calificación total será de 60% y 40% respectivamente. Dicha calificación será la que
determine la priorización de requerimientos, por ejemplo:
Ítem Interesado Requisito Poder Impacto Clasificación Observaciones
1 Jefe de la Una aplicación web 9 9 9 Requerimiento 1
empresa para el inventario de de alta
distribuidora productos importancia
2 Jefe de Aplicación móvil 10 9 9 Requerimiento 2
empresa para realizar el cobro de alta
distribuidora de las cuentas importancia
3 Jefe de Desarrollar el 9 9 9 Requerimiento 3
proyecto proyecto de de alta
inventario y control importancia
de cobros de las
cuentas
4 Cliente Generar reportes de 8 9 9 Requerimiento 4
los productos de alta
distribuidos importancia.
5 Comerciante Ingresar un nuevo 9 9 9 Requerimiento 5
cliente de alta
importancia
6 Comerciante Modificar un cliente 9 8 9 Requerimiento 6
deudor de alta
importancia
7 Comerciante Buscar un cliente 10 9 9.5 Requerimiento 7
deudor por CI de alta
importancia
8 Comerciante Buscar un cliente 8 8 8 Requerimiento 8
deudor por Nombre de alta
importancia
9 Comerciante Eliminar un cliente 9 9 8 Requerimiento 9
deudor de alta
importancia
10 Comerciante Generar un reporte 9 10 8 Requerimiento 10
del cliente deudor de alta
importancia
53
11 Comerciante Ingresar un producto 9 8 Requerimiento 11
a inventario de alta
importancia
12 Comerciante Modificar un 9 9 9 Requerimiento 12
producto a de alta
inventario importancia
13 Comerciante Buscar un producto 10 9 9.4 Requerimiento 13
por inventario por de alta
código importancia
14 Comerciante Buscar un producto 9 9 8 Requerimiento 14
por inventario por de alta
nombre importancia
15 Comerciante Eliminar un 9 8 9 Requerimiento 15
producto del de alta
16 Comerciante Generar un reporte 9 9 9 Requerimiento 16
de un producto en de alta
17 Cliente Buscar u producto en 10 9 9.5 Requerimiento 17
venta por nombre de alta
importancia
18 Cliente Buscar u producto en 9 8 9 Requerimiento 18
venta por de alta
comerciante importancia
19 Cliente Buscar u producto en 9 8 9 Requerimiento 19
venta por código de alta
importancia
20 Comerciante Deseo poder ser 9 8 9 Requerimiento 20
notificado por un de alta
pedido importancia
21 Comerciante Deseo poder aprobar 9 9 9 Requerimiento 21
un pedido de alta
importancia
22 Comerciante Buscar un pedido 10 9 9.4 Requerimiento 22
por código de alta
importancia
54
23 Cliente Buscar un pedido 10 9 9.4 Requerimiento 23
por código de alta
importancia
24 Comerciante Buscar un pedido 9 9 8 Requerimiento 24
por cliente de alta
importancia
25 Comerciante Buscar un pedido 9 9 9 Requerimiento 25
por fecha de alta
importancia
26 Cliente Deseo poder buscar 9 9 9 Requerimiento 26
un pedido por fecha de alta
importancia
27 Comerciante Deseo poder 10 8 9 Requerimiento 27
eliminar un pedido de alta
importancia
28 Cliente Deseo poder 9 9 Requerimiento 28
eliminar un pedido de alta
importancia
29 Comerciante Deseo poder generar 10 9 9.4 Requerimiento 29
un reporte del pedido de alta
importancia
30 Cliente Deseo poder generar 9 10 9.5 Requerimiento 30
un reporte del pedido de alta
importancia
31 Cliente Deseo poder 9 9 9 Requerimiento 31
descargar los de alta
reportes generados importancia
32 Comerciante Deseo poder 8 9 9 Requerimiento 32
descargar los de alta
reportes generados importancia
33 Comerciante Deseo poder listar 9 9 9 Requerimiento 33
cliente de alta
importancia
34 Comerciante Deseo poder listar 9 8 9.2 Requerimiento 34
producto en venta de alta
importancia
55
35 Cliente Deseo poder listar 9 8 9 Requerimiento 35
producto en venta de
alta6importancia
37 Cliente Deseo poder listar 9 9 9 Requerimiento 37
pedidos de alta
importancia
38 Comerciante Deseo poder listar 9 10 9 Requerimiento 38
pedidos de alta
importancia
39 Comerciante Deseo poder ser 9 10 9.5 Requerimiento 39
notificado por de alta
productos escasos en importancia
inventarios
40 Comerciante Deseo poder ser 9 9 9 Requerimiento 40
notificado por de alta
productos fuera del importancia
stock.
41 Comerciante Deseo poder darme 10 9 9 Requerimiento 41
de alta en el sistema de alta
con datos personales importancia
42 Cliente Deseo poder darme 8 8 8 Requerimiento 42
de alta en el sistema de alta
con datos personales importancia
43 Comerciante Deseo poder entrar 10 9 9 Requerimiento 43
al sistema por de alta
credenciales importancia
44 Cliente Deseo poder entrar 9 10 10 Requerimiento 44
al sistema por de alta
credenciales importancia
CONTROL DE CAMBIOS EN LOS REQUISITOS
En concordancia con el cambio en el alcance del proyecto, se deberá referenciar a ese apartado para la
gestión de los cambios en los requisitos.
56
PRIORIZACIÓN DE LOS REQUISITOS
Para la priorización de los requisitos, en primera instancia se acordará con el equipo de desarrollo y la
cliente para su desarrollo, posteriormente el equipo analizará la propuesta y la aceptará o reformulará
hasta hallar un acuerdo entre ambas partes.
MÉTRICAS DEL PRODUCTO
Se han establecido dos métricas específicas para medir:

1. Velocidad en el desarrollo del producto: A través de la medición del número de historias de
usuario/técnicas planificadas para ser desarrolladas tras cada iteración sobre el número real de
historias de usuario/técnicas desarrolladas en la iteración correspondiente.
2. Calidad del producto: A través de la medición del número de pruebas de aceptación aplicadas
a las Tareas de Ingeniería de las historias de usuario/técnicas en cada iteración sobre el número
de pruebas de aceptación exitosas de las tareas de ingeniería de las historias de usuario/técnicas
propuestas en la iteración correspondiente.
2.3. Estructura de desglose de trabajo
Esquema EDT
A continuación, se puede observar el Esquema EDT determinado para el proyecto:
57
58
3. PLAN DE GESTIÓN DE TIEMPO
3.1. Gestión del tiempo
PLAN DE GESTIÓN DE TIEMPO

Preparado por: Cecilio Tasna – Analista de sistemas Fecha 22/11/2019
Persona(s) autorizada(s) a solicitar cambio en cronograma:

Nombre Cargo Ubicación
Cecilio Tasna Analista de sistemas Riobamba
Jorge Jiménez Líder del equipo de desarrollo Riobamba
Mirian Tipan Líder de documentación Riobamba
Alexander Tubón Líder de calidad Riobamba
María José Quinatoa Gerente del proyecto Riobamba
Persona(s) que aprueba(n) requerimiento de cambio de cronograma:
Ing. Ligia Niama Gerente empresa CIEAL Riobamba
Ing. Alejandra Oñate Seguimiento y Control Riobamba
Razones aceptables para cambios en cronograma del Proyecto:

 Solicitud de cambio de alcance por parte del Cliente.
 Situación socioeconómica del país.
 Huelgas y revueltas populares.
 Atrasos ocasionados por el desconocimiento de las tecnologías utilizadas.
 Accidentes de trabajo.
59
Describir cómo calcular y reportar el impacto en el proyecto por el cambio en cronograma
(tiempo, costo, calidad, etc.):
1. Indicar en el informe a la persona responsable del mismo y fecha de ocurrencia del problema.
2. Descripción del problema indicando el grado de urgencia.
3. Impacto de este sobre el proyecto (Costo, Calidad, tiempo y alcance).
4. Descripción de las alternativas de solución detallando el impacto en las diferentes áreas (costo,
calidad, tiempo y alcance).
5. Recomendación en la selección de la alternativa de solución.
6. Documentos que lo sustenten.
7. El informe será entregado a la persona correspondiente para ser analizado en reunión de trabajo
con la finalidad de discutir las alternativas, seleccionar la mejor con los ajustes necesarios.
Describir cómo los cambios al cronograma serán administrados:

La administración del Alcance se efectuará de la siguiente manera:
1. Designación de Responsabilidades:
- Planificación. Alexander Tubón
- Ejecución. Cecilio Tasna
- Seguimiento y Control Alejandra Oñate, Ligia Niama.
2. Modalidad de Cambios:
a) Cuando las solicitudes sean realizadas por los desarrolladores se procederá de la siguiente
manera: Cada semana se recibirán las solicitudes de cambio en el cronograma, las cuales
deben serpresentadas por el representante de los desarrolladores. Las solicitudes de
cambio deberán presentarse, a más tardar, a los 5 días de que se produce el
inconveniente que genera el retraso en la entrega del entregable.Estas solicitudes serán
revisadas por el equipo de proyecto para evaluar, en primera instancia, si es un cambio
“viable” según el plan de gestión del alcance, Las solicitudes de cambio de cronograma
comenzarán a revisarse los días sábados de cada semana, teniendo un plazo máximo de
5 días para dar respuesta a la solicitud. La solicitud de cambio será aprobada con la
firma del Gerente de Proyecto.
b) Cuando las solicitudes son realizadas por las personas autorizadas del equipo del
proyecto, se procederá de la siguiente manera: El líder de calidad, después de evaluar la
causa de demora en cronograma debido a un inconveniente, informará al Gerente de
Proyecto la necesidad de realizar un cambio en el cronograma. El Gerente del Proyecto,
junto con el equipo de proyecto, evaluará la situación para determinar la criticidad del
60
cambio. Dependiendo de la misma se procederá de la siguiente manera:
b.1) En caso el problema que genera la solicitud de cambio del cronograma afecte el alcance
del proyecto o sobrepase los límites de cronograma establecidos en el plan de gestión
del proyecto, entonces se deberá presentar el formato N° FGPR-007-A al Gerente
General para que tome la decisión de aprobar o rechazar la propuesta. Si la propuesta
es aprobada, esta es presentada al Gerente del proyecto para su evaluación y
negociación. El Gerente General tiene un plazo máximo de 2 días para tomar la decisión
de aprobar o rechazar la propuesta.
3.2. Actividades (Desglose EDT)
A continuación, se detalla todas las listas de actividades por paquetes de trabajo desde el EDT:
3.2.1. Inicio
3.2.1.1. Desarrollar el acta de constitución
3.2.2. Planificación
3.2.2.1. Plan de Gestión del Proyecto
3.2.2.2. Gestión de la Integración
3.2.2.3. Gestión del alcance (Recopilar requisitos, definir alcance, crear EDT)
3.2.2.4. Gestión del tiempo (Definir actividades, estimar recursos y duración,
cronograma)
3.2.2.5. Gestión de costos (Estimar costos, preparar presupuesto)
3.2.2.6. Gestión de calidad
3.2.2.7. Gestión de RRHH
3.2.2.8. Gestión de Comunicaciones (Comunicaciones)
3.2.2.9. Gestión de Riesgos (Identificar riesgos, planificar respuesta, análisis de
riesgos)
3.2.2.10. Gestión de adquisiciones
3.2.2.11. Gestión de interesados
3.2.3. Ejecución
3.2.3.1. Exploración
3.2.3.2. Planificación técnica
3.2.3.3. Diseño
3.2.3.4. Codificación
3.2.4. Seguimiento y Control
3.2.4.1. Controlar cronograma
3.2.4.2. Dar seguimiento al proyecto
61
3.2.4.3. Controlar el trabajo o actividades
3.2.5. Evaluación
3.2.5.1. Validación
3.2.5.2. Verificación
3.2.6. Cierre del Proyecto
3.3. Secuencia de actividades
A continuación, se visualiza el diagrama de actividades:
3.4. Recursos para las actividades
Los recursos que pueden prestarse para el desarrollo de las actividades del proyecto son
presentados a través del siguiente esquema RBS:
62
3.5. Duración de las actividades
Inicio
Comprobar la viabilidad RRHH 2 semanas
Comprobar la viabilidad Económica 2 semanas
Identificar interesados 2 semanas
Desarrollar el acta de constitución 4 semanas
Planificación
Realizar el plan de Gestión del Proyecto 3 semanas
Realizar la gestión de la Integración 2 semanas
Realizar la Gestión de interesados 2 semanas
Realizar la Gestión del alcance 2 semanas
Realizar la Gestión del tiempo 2 semanas
Realizar la Gestión de costos 2 semanas
Realizar la Gestión de calidad 2 semanas
Realizar la Gestión de RRHH 2 semanas
Realizar la Gestión de las Comunicaciones 2 semanas
Realizar la Gestión de Riesgos 2 semanas
Realizar la Gestión de adquisiciones 2 semanas
Ejecución
Realizar la Planificación técnica 2 semanas
Poner en marcha la Fase de Diseño 9 semanas
63
Poner en marcha la Fase de Codificación 9 semanas
Seguimiento y Control
Controlar el cronograma 9 semanas
Dar seguimiento al proyecto 9 semanas
Controlar el trabajo o actividades 9 semanas
Evaluación
Efectuar pruebas de Validación 9 semanas
Efectuar pruebas de Verificación 9 semanas
Cierre del Proyecto
3.6. Cronograma de actividades (GANTT)
Mes
Id Tarea Inicio
Noviembre Diciembre Enero
01 Identificar interesados 2 sem 04/11/2019
Desarrollar el acta de
02 4 sem 04/11/2019
constitución
Realizar el plan de Gestión
03 3 sem 11/11/2019
del Proyecto
Realizar la gestión de la
04 2 sem 18/11/2019
Integración
Realizar la Gestión de
05 2 sem 18/11/2019
interesados
Realizar la Gestión del
06 2 sem 25/11/2019
alcance
Realizar la Gestión del
07 2 sem 02/12/2019
tiempo
Realizar la Gestión de costos
08 2 sem 09/12/2019
09 2 sem 16/12/2019
calidad
Realizar la Gestión de RRHH
10 2 sem 23/12/2019
Realizar la Gestión de las
11 2 sem 02/01/2020
Comunicaciones
12 2 sem 09/01/2020
Riesgos
13 2 sem 16/01/2020
adquisiciones
Realizar la Planificación
14 2 sem 20/01/2020
técnica
Poner en marcha la Fase de
15 9 sem 20/01/2020
Diseño
Poner en marcha la Fase de
16 9 sem 23/01/2020
Codificación
17 Controlar el cronograma 9 sem 27/01/2020
Dar seguimiento al proyecto 9 sem
18 27/01/2020
Controlar el trabajo o 9 sem
19 31/01/2020
actividades
Efectuar pruebas de 9 sem
20 31/01/2020
Validación
Efectuar pruebas de 9 sem
21 4/02/2020
Verificación
64
4. PLAN DE GESTIÓN DE COSTO
PLAN DE GESTIÓN DE COSTO

Preparado por: Cecilio Tasna – Analista de sistemas Fecha 23/11/2019
Persona(s) autorizada(s) a solicitar cambios en el costo:

Cecilio Tasna Analista de sistemas Riobamba
Jorge Jiménez Líder del equipo de desarrollo Riobamba
Mirian Tipan Líder de documentación Riobamba
Líder de calidad / Líder del
Alexander Tubón proyecto Riobamba
María José Quinatoa Gerente del proyecto Riobamba
Persona(s) que aprueba(n) requerimientos de cambios en costo contractual:
Ing. Ligia Niama Gerente empresa CIEAL Riobamba
Persona(s) que aprueba(n) requerimiento de cambio de costo interno ofrecido:
Gerente de Proyecto.
Razones aceptables para cambios en el Costo del Proyecto:
 Adecuación en el Alcance del Proyecto (cambios)
 Ampliaciones en el Alcance del Proyecto
 Incremento de los costos de los desarrolladores
 Cambios en las fechas de entrega (aceleraciones)
 Otros debidamente sustentados.
65
Describir como calcular e informar el impacto en el proyecto por el cambio en el costo (tiempo,
calidad, etc.):
1. Persona que solicita el cambio.
2. Descripción de las características de la situación que requiere una solicitud de cambio de costos.
3. Impacto de este sobre el proyecto (Costo, Calidad, tiempo y alcance).
4. Descripción de las alternativas de solución detallando el impacto en las diferentes áreas (costo,
calidad, tiempo y alcance).
5. Recomendación en la selección de la alternativa de solución (Propuesta).
6. Documentos que los sustenten.
7. El tiempo máximo de respuesta que tiene el o las personas encargadas para dar la aprobación.
Describir cómo serán administrados los cambios en el costo:

Los cambios en el costo se denominarán presupuestos adicionales o deductivos, según sea el caso. La
persona autorizada a solicitar cambios en el costo deberá elevar su solicitud a la persona autorizada para
aprobar el cambio propuesto, sustentando su pedido en forma documentada. Sólo procederán presupuestos
adicionales si se demuestra que éstos son necesarios e imprescindibles para lograr el alcance del proyecto
y que sean originado por omisiones o defectos en la formulación del alcance. Las modificaciones al
alcance que no cumplan con este requisito podrán ser aprobadas sólo si cuentan con la autorización del
responsable del proyecto. Caso contrario no se modificará el costo del proyecto, siendo de responsabilidad
del equipo de trabajo los mayores costos en que éste incurra.
El procedimiento a seguir para aprobar un presupuesto adicional o un deductivo será el siguiente:
1. Dentro de los siete días calendario posteriores al hecho que determine una modificación del costo
del proyecto, la persona autorizada a solicitar cambios en el costo deberá sustentar su pedido,
indicando las causas que originaron el adicional o el deductivo, debiendo acompañar,
necesariamente, una propuesta de la modificación del presupuesto precisando los montos y el
sustento analítico necesario. Esta documentación deberá ser presentada a la persona autorizada
para aprobar el cambio propuesto.
2. La persona autorizada para aprobar el cambio propuesto, dentro de los cinco días calendario
posteriores a la recepción de la solicitud, deberá analizar el pedido y, de encontrarlo conforme en
forma total o parcial, deberá emitir la orden de proceder, autorizando el cambio del costo.
Una vez emitida la orden de proceder, será responsabilidad del equipo de trabajo actualizar los
documentos que se vean afectados por dicha orden de proceder.
Nombre del Proyecto Siglas de Proyecto

“APLICACIÓN WEB Y MÓVIL PARA EL
CONTROL DE INVENTARIOS Y DE J-PAYMET
66
TIPOS DE ESTIMACIÓN DEL PROYECTO:
TIPO DE ESTIMACIÓN MODO DE FORMULACIÓN NIVEL DE PRECISIÓN
Presupuesto de recurso humano Para determinar el presupuesto El nivel de precisión es de

con el que cuenta el equipo de 50%
trabajo, se necesita determinar el
salario que se ocupara para
realizar el proyecto, por ello se
basó en la investigación de
(Sarmiento, 2017) para obtener el
salario de un Ing. En Sistemas en
Ecuador, el cual el autor lo define
en $1100 las 8 horas, pero el
grupo al estipular un horario de
trabajo de 4 horas define el salario
para los cálculos respectivos en
$550.
Para la consideración del
El nivel de precisión es de
Presupuesto Equipos y Servicios presupuesto que se necesitaría en 75%
equipos y servicios, el equipo de
trabajo sumo los gastos de
servicios y depreciación de
equipos que se necesitaría en el
periodo de duración del proyecto.
Presupuesto Final Para la consideración del
presupuesto final es necesario El nivel de precisión es de
calcular el valor total de los dos 60%
recursos antes mencionados así
para poder determinar el
presupuesto de nuestro proyecto.
Determinar el Presupuesto
UNIDADES DE MEDIDA A UTILIZAR, PARA ESTIMAR Y TRABAJAR CADA TIPO DE
RECURSO
Tipo de Recurso Unidades de Medidas Valor Total
Humano
Cliente $0
Desarrollador 1 $ 1420
67
Equipos y Servicios
Computadoras 7 $ 4900
Celulares 6 $ 1200
Memoria USB 3 $ 45
Disco Duro Externo 1 $ 185,75
Total $ 6.331,75
68
5. PLAN DE GESTIÓN DE LA CALIDAD
5.1.Gestión de la Calidad
PLAN DE GESTIÓN DE LA CALIDAD

Preparado por: María José Quinatoa – Gerente del Proyecto Fecha 23/11/2019
GESTIÓN DE CALIDAD DEL PROYECTO
PLANIFICAR LA CALIDAD
El Plan de gestión de calidad describe cómo el equipo de dirección del proyecto implementará la política
de calidad de la organización ejecutante. Es un componente o un plan subsidiario del plan para la
dirección del proyecto. El plan de gestión de calidad proporciona entradas al plan general para la
dirección del proyecto y aborda el control de calidad, el aseguramiento de la calidad y métodos de mejora
continua de los procesos del proyecto. (PMBOK, 2008).
En vista de que J-CAMP S.L. es una empresa dedicada al desarrollo de software, se propone el uso de
un plan de gestión de calidad, que le permita asegurarse y controlar de manera eficaz y eficiente la
calidad.
Gracias al plan de gestión de calidad el equipo del proyecto tendrá un parámetro más para verificar el
desarrollo de las actividades y en caso de haberse presentado alguna dificultad, se contará con una
documentación exhaustiva sobre su origen, causas, consecuencias y acciones que debieron realizarse
para evitar que interfiera con el normal desarrollo de las demás actividades del proyecto, de manera que
continuamente se estén mejorando los procesos, mediante la divulgación de los resultados a todos los
involucrados durante el proceso de desarrollo del proyecto.
ASEGURAMIENTO DE LA CALIDAD
Es responsabilidad del Líder de Calidad (rol perteneciente a Alexander Tubón) ejecutar el
Aseguramiento de Calidad durante todo el Proyecto, revisa el Planeamiento de los procesos del
proyecto contra lo ejecutado, plantea acciones preventivas o correctivas según sean necesario. Se
informa semanalmente en las reuniones de previstas al Gerente, Cliente y al Equipo del Proyecto.
REALIZAR CONTROL DE CALIDAD

Nuestra consultora (Ing. Alejandra Oñate) es responsable de la ejecución del Control de Calidad. Se
revisan los entregables de los proyectos conforme se vayan presentando, se emiten las observaciones o
conformidades en la reunión semanal de calidad. Se definen dos procedimientos para el Control de
69
Calidad:
 Revisión de Contenidos y
 Revisión de Forma.
Control de Calidad del Contenido: Se revisan la calidad de los entregables, para lo cual nuestra
consultora se asesora con el equipo de J-CAMP. Las observaciones que se puedan formular se
informan en las reuniones semanales.
Control de Calidad de Redacción y Formato: Nuestra consultora revisa la redacción de los
documentos entregables, las observaciones que se puedan formular, se informan en las reuniones
semanales.
NORMAS DE CALIDAD NECESARIAS PARA REALIZAR EL CONTROL DE CALIDAD

Para validación y análisis de las características requeridas por el proyecto, las siguientes normas deberán
servir como referencia:
Normas ISO (Organización Internacional para la Estandarización)
ISO – 9001: se basa en principios de gestión incluyendo una atención centrada en el cliente, motivación
e implicación de los responsables de las empresas, gestión de procesos y mejorar continua.
ISO – 25000: centrada en dos procesos principales: especificación de requisitos de calidad del software
y evaluación de la calidad del software. Éstas 5 áreas son referentes de la ISO - 25000
- ISO 2500n: gestión de calidad
- ISO 2501n: modelo de calidad: compuesto entre otros por fiabilidad, seguridad, mantenibilidad y
usabilidad.
- ISO 2502n: medición de calidad
- ISO 2503n: requisitos de calidad
- ISO 2504n: evaluación de calidad
70
MÉTRICAS DE CALIDAD
Previamente se declararon 2 métricas de calidad en la “gestión de los requisitos” dentro del “Plan de
Gestión del Alcance” para producto software, estos fueron establecidos como:
- Velocidad en el desarrollo del producto
- Calidad del producto
Sin embargo, nunca se estableció un valor indicador en específico, mínimo o requerido para el control en
el cumplimiento con estas métricas establecidas por el equipo de desarrollo.
Para la velocidad en el desarrollo del proyecto: No podrá ser inferior al 75% debido al compromiso y
responsabilidad del equipo con la cliente y consultora; este número es establecido a su vez debido a la
experiencia del equipo en proyectos de desarrollo afines.
Para la calidad del producto: No podrá ser inferior al 90% debido a que, para el producto, el margen
de error debe ser mínimo y en concordancia con el número de pruebas que se plantean realizar, es un
número bastante aceptable.
MEJORAS DEL PROCESO

Las herramientas base para la supervisión de la calidad son los Histogramas aplicados a las métricas de
calidad definidas, a partir de las cuales se proponen mejoras a estos procesos, conforme se va
desarrollando el mismo.
Es responsabilidad del Líder del Calidad proponer mejoras de Calidad, estas propuestas se realizan en las
reuniones semanales correspondientes.
VERIFICACIÓN DE CALIDAD DE LOS ENTREGABLES
ENTREGABLE PROCEDIMIENTO
Para el Diseño
Arquitectura del sistema Verificar que la arquitectura escogida para la
implementación del sistema J-PAYMENT es
adecuada para las prestaciones a las que tendrá que
someterse.
Modelo Vista Controlador El modelo MVC que se estableció como base para
el diseño del desarrollo debe cumplir con su función
en la organización de los archivos del producto y
además servir para la mejora de la distribución de
carga y responsabilidades en el mismo.
71
Base de Datos La base de datos MySQL a través de su herramienta
de gestión de Workbench permite realizar un
seguimiento y control tanto de su diseño,
implementación e implantación, por lo tanto, nos
servirá de mucho a la hora de controlar el uso y
funcionamiento de la base de datos en operación.
Metodología Ágil XP La metodología XP provee herramientas que
permiten la mejora en el desenvolvimiento de las
actividades que se vayan a realizar, entre ellas están
los valores que esta propone y que se tomarán como
referencia para cuidar la integridad del trabajo
realizado a través de esta metodología.
Listado de Hardware y Software requerido Netbeans IDE permite la realización de pruebas
unitarias a través de su módulo de J-Unit que nos
ayudará en el control de las pruebas de aceptación
de las historias de usuario/técnicas planteadas.
Flutter al trabajar con el lenguaje de programación
en Dart, permite realizar una inspección mejorada
del código en busca de errores sintácticos y de
estándares de manera oportuna.
Para el manejo de adquisiciones
El documento deberá presentarse íntegramente cada
Hardware y Software del Sistema Cliente / Servidor semana para verificar sus cambios y actualizaciones
y determinar el mejor manejo de este.
Los pagarés deberán estar validados en contraste
Pagarés con los que se usen en nuestro medio, esto es en la
República del Ecuador.
La capacitación parte desde aquella que se realiza
con el equipo de desarrollo tras cada iteración, todos
los miembros del equipo de trabajo conocen de los
Servicio de Programación y Capacitación
procesos que deben cumplirse, de manera que las
capacitaciones a usuarios del sistema J-PAYMENT
pueda ser realizada con soltura.
Implementación
El producto final Deberá cumplir con los objetivos y metas
72
establecidas, al igual que sus parámetros para
establecer su calidad.
Arranque del Sistema
La comunicación entre capas al momento de
realizar la integración no deberá tener problemas y
Pruebas de comunicación entre herramientas
en caso de haberlo deberá ser reportado de manera
oportuna.
El soporte técnico garantizado de 3 meses deberá
ser corroborado con la métrica de calidad a la que
Soporte técnico asistido
este se encuentre sometido en el desarrollo del
aplicativo.
Término de Obra
Las pruebas que se realizan dentro de la métrica de
Informe de pruebas aprobadas del sistema de calidad del producto deberán ser documentadas y
control puestas a conocimiento público para su
consideración.
En correspondencia con el grado de mantenibilidad
que se desea también aplicar al producto en
Manuales técnicos y de usuario del sistema desarrollo, se realizará la documentación
exhaustiva de este en cada iteración y será
comprobada y corroborada por nuestra asesora.
5.2. El Sistema de Gestión de la Calidad
DESCRIPCIÓN DEL SISTEMA DE GESTIÓN DE CALIDAD DEL PROYECTO
ESTRUCTURA ORGANIZACIONAL
 Gerente de Proyecto
 Consultora
 Líder de Calidad
 Equipo de Proyecto
ROLES Y RESPONSABILIDADES
(Roles y responsabilidades relacionados a los procesos y procedimientos de gestión de calidad)
ROLES A C RESPONSABILIDADES
Gerente de x x  Es el responsable de la Generación del Plan de Gestión
Proyecto
de Calidad.
73
 Responsable de la aprobación de las actividades de
aseguramiento y control de calidad.
 Definir el equipo de la calidad y sus roles.

Equipo de control x x  Conformado por el Supervisor de Calidad y el analista
de Calidad
de calidad Plantear las acciones para el aseguramiento
de la calidad
 Efectuar el control de calidad para los entregables del
producto y del proyecto
 Asesorar en aspectos de calidad al Gerente de

Proyecto y al equipo de Proyecto
Líder de Calidad x  Asesora al equipo del proyecto en temas de calidad
específicas.
Equipo de Proyecto x  Son responsables de guardar las normas de calidad
para los procesos del proyecto y la generación de
entregables.
74
6. PLAN DE GESTIÓN DE RECURSOS HUMANOS
6.1. Recursos Humanos
PLAN DE RECURSOS HUMANOS
Proyecto “APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE INVENTARIOS Y

DE CUENTAS POR COBRAR “
Preparado por: María José Quinatoa – Gerente del Proyecto Fecha 23/11/2019
Rol en el proyecto Gerente del Proyecto

Función/responsabilidad principal
 El Gerente del Proyecto será responsable de la ejecución y entrega del proyecto.
 Reporta directamente al Gerente de la empresa J-CAMP S.L.
 Es el responsable de la definición del Personal que integra el equipo de proyecto de su
organización y gestión.
 Es el responsable de la definición del proyecto y de la asignación de recursos al mismo.
 Da soporte a las tareas de estimación y definición de las actividades contenidas en los
planes.
 Realiza la revisión y aprobación.
Competencias requeridas / responsabilidades
 Capacidad de liderazgo
 Habilidades interpersonales
 Habilidades para resolver problemas
 Habilidades para organizar: la planificación, la fijación de objetivos y análisis
 Habilidades de confrontación: flexibilidad, creatividad, paciencia, persistencia
 Habilidades de trabajo en equipo: empatía, motivación y espíritu de cuerpo
 Medir el clima laboral, el progreso y el rendimiento
 Comunicarse con eficacia, oralmente y por escrito
 Delegar con eficacia
 Gestionar el cambio
Disponibilidad
Duración del proyecto
Descripción del puesto a Externo / Número Fecha Ingreso Fecha Retiro Tiempo
requerir Interno estimado requerido
75
Gerente del Proyecto interno 1 28/10/2019 23/01/2020
Evento disparador Sincronización prevista
Renuncia Inmediato con la designación de reemplazo por el
Gerente de la empresa J-CAMP S.L.
Enfermedad Inmediato con la designación de reemplazo por el
Gerente de la empresa J-CAMP S.L.
Notas
A tiempo parcial
ROL EN EL PROYECTO Desarrollador

 Su principal responsabilidad es definir y mantener el código fuente de uno o varios
componentes, garantizando que cada componente implemente la funcionalidad correcta.
 Tiene responsabilidad por la integridad de uno o más subsistemas de implementación y de
sus contenidos a lo largo del desarrollo.
 Asegurarse que el código generado esté libre de errores por medio de la ejecución de
pruebas unitarias del código construido.
 Desarrollador curioso
 Atención al detalle
 Pasión proactiva
 Adaptación al cambio
 Comunicación EE: eficaz y eficiente
 Comprender el código ajeno
Disponibilidad
Descripción del Externo / Número Fecha Ingreso Fecha Tiempo

puesto a requerir Interno estimado Retiro requerido
Supervisor de Montaje interno 1 28/10/2019 23/01/2020
Renuncia Inmediato con la designación de reemplazo
por el Gerente del Proyecto
Enfermedad Inmediato con la designación de reemplazo
por el Gerente de Proyecto
Notas
76
A tiempo parcial
ROL EN EL PROYECTO Líder de calidad

 Debe ser alguien con conocimientos de programación y análisis.
 Que sea capaz, utilizando los requerimientos, de desarrollar una suite de tests que verifiquen
que el software cumple con los requerimientos.
 El líder de calidad es el último responsable de que las características funcionan tal y como
se han especificado en los requerimientos.
 Capacidad de síntesis, objetividad y agilidad para tomar decisiones.
 Debe ser ordenado y meticuloso en la inspección y elaboración de registros.
 Capacidad y habilidad en la planeación de la documentación necesaria para asegurar y
controlar la calidad del producto.
 Capacidad de aprender y adaptarse a los cambios ofreciendo mejoras continuas.
 Debe ser seguro para tomar decisiones bajo presión.
Disponibilidad

Analista de Calidad interno 1 28/10/2019 23/01/2020
Notas
A tiempo parcial
ROL EN EL PROYECTO Líder de documentación

 Alguien con conocimientos técnicos.
 Capaz de entender los requerimientos.
 Generar la documentación necesaria.
77
 Organizar el contenido a escribir y marcar la línea a seguir en cuanto a documentación.
 Espíritu emprendedor e innovador
 Sostenibilidad y compromiso social
 Lengua Extranjera
 Comunicación eficaz oral y escrita
 Trabajo en equipo
 Uso solvente de los recursos de información
 Aprendizaje autónomo
Disponibilidad

Asegurador de interno 1 28/10/2019 23/01/2020
Calidad
Notas
A tiempo parcial
ROL EN EL PROYECTO Analista de Sistemas

 Es el encargado del diseño del sistema: Análisis general, análisis detallado, diagrama
conceptual, diseño y generación de la base de datos y normalización de la misma,
documento de flujo de operación y especificaciones funcionales.
 Los analistas de sistemas utilizan tecnologías de la información y comunicación (TIC)
para ayudar a las empresas a trabajar de forma más rápida y eficiente.
 Investigan un problema y luego diseñan o adaptan un sistema informático para mejorar el
funcionamiento de la empresa.
 Los analistas de sistemas realizan un estudio detallado de la empresa, sus procedimientos
y las necesidades de las personas que utilizan sus sistemas.
78
 Los analistas reúnen información hablando con el personal de todas las categorías dentro
de la organización.
 Los analistas de sistemas suelen actualizar o rediseñar un sistema antiguo en lugar de
introducir uno totalmente nuevo.
 Los analistas podrían estar involucrados en la planificación o ejecución.
 Cuando el proyecto está terminado, los analistas examinan cuidadosamente el nuevo
sistema para asegurarse de que cumple con sus funciones y de que los usuarios están
satisfechos con este.
Disponibilidad
Jefe de Adquisiciones interno 1 28/10/2019 23/01/2020
Notas
A tiempo parcial
6.2. Organización del proyecto
79
7. PLAN DE GESTIÓN DE COMUNICACIONES
PLAN DE GESTIÓN DE
COMUNICACIONES
Preparado por: Mirian Tipan – Líder de Documentación Fecha 13/01/2020
La comunicación en nuestro proyecto son vías muy importantes. Al igual que en la

planificación del proyecto, se deben establecer expectativas y tanto el equipo del proyecto
como las partes interesadas del cliente tienen que cumplir con sus responsabilidades para que
la comunicación se desarrolle sin problemas. Si bien un proyecto no se iniciaría sin un Plan de
Proyecto en marcha, el Plan de Comunicación de un Proyecto no se discute tan fácilmente,
pero debería.
7.1. Requisitos de Comunicación
Para este proyecto hemos determinado que las partes demandantes de comunicación son:
 Equipo de Proyecto.
 Ejecutivo del proyecto.
 Líder de Proyecto.
 Gerente del proyecto
 Coordinador de Proyecto.
 Usuario.
7.2. Matriz de Comunicación
MATRIZ DE COMUNICACIONES
Interesados Responsable del Tipo de Método de Frecuencia de

equipo de comunicaciones comunicación a ser comunicación
comunicarse con utilizado (Correo (semanal,
el interesado electrónico, quincenal,
informe, etc.) mensual)
Equipo del Líder del Proyecto Avance y estado del Reunión Diario
Proyecto proyecto, problemas Teléfono
enfrentados y
acciones correctivas.
Usuario Requerimientos y Correo electrónico Semanal
Ejecutivo del restricciones Teléfono
Proyecto (Líder aplicables al
de proyecto.
desarrolladores)
80
Equipo del Información de Correo electrónico Quincenal
Líder del proyecto, cambios, logros y Teléfono
Proyecto coordinador del problemas no Reuniones
proyecto solucionados del
proyecto.
Gerente del Líder del proyecto, Dar una solución a Correo electrónico Mensual
proyecto usuario, los problemas y Reuniones
cambios durante el
ciclo del proyecto
Líder del proyecto Inquietudes, Correo electrónico Diario
Coordinador del y Usuario consultas. Teléfono
proyecto Información de
cambios.
Coordinador del Información de Correo electrónico Mensual
Usuario proyecto gestión de la empresa Teléfono
(procesos,
responsabilidades,
jerarquía, etc.)
7.3. Canales de Comunicación
Para nuestro proyecto se han definido específicamente los siguientes canales de
comunicación:
Canales formales:
 Internet: desde el cual podrán proceder a su descarga e instalación, además que
se brinda asesoría desde la empresa ubicada en la ciudad de Riobamba.
Para los clientes que deseen pagar las cuentas de su compra tendrán que
comunicarse con la empresa mediante redes sociales que lleven el nombre de la
empresa en donde encontraran información necesaria para poderlos atender lo más
pronto posible.
 Reuniones: Estás serán realizadas principalmente cuando se quiere comunicar o
brindar nuevas soluciones de gran importancia para el proyecto o cuando se deba
discutir un tema. Si bien no es necesario que todas las partes se presenten siempre
a una reunión, sí se requiere informar vía correo electrónico sobre quienes se han
reunido y los temas que han discutido.
Canales informales:
 Teléfono Móvil: Este canal se utilizará de forma auxiliar, debido a que los clientes
y los coordinadores del proyecto principalmente no responden cuando se requiera
una respuesta inmediata. Aun así, este medio no formaliza ningún tipo de
requerimiento o acuerdo.
7.4. Distribución de la información
Anteriormente, en la matriz de comunicaciones de nuestro proyecto, se han definido
informes que deben ser entregados periódicamente. Además de esto, todos los informes
generados por el equipo de proyecto serán almacenados en un computador específico y
81
hacer revisar el avance del proyecto semanalmente a los coordinadores del proyecto.
Por otro lado, en caso de requerir o transmitir cualquier tipo de información relacionada
con el proyecto, se debe enviar un correo electrónico o en las redes sociales a quien
corresponda.
Para que la comunicación mutua entre los interesados del proyecto se considera lo
siguiente:
 Las distintas partes deben tener las redes sociales como Facebook, WhatsApp para
poder enviar mensajes de alguna duda sobre el proyecto.
 Las partes deben informar de al menos 1 número de teléfono móvil que dispongan
para ser contactados en forma inmediata.
 Las reuniones serán concretadas en un lugar acordado por las partes de forma
anticipada, dependiendo de la ubicación y disponibilidad de cada una de ellas, y
siempre y cuando todas las partes participantes estén de acuerdo.
82
8. PLAN DE GESTIÓN DE RIESGOS
PLAN DE GESTIÓN DE LA CALIDAD

Preparado por: Mirian Tipan – Líder de Documentación Fecha 20/01/2020
8.1. Introducción
Uno de los términos de cumplimiento de plazos, costes, alcance funcional y calidad final
de los proyectos es la Gestión de Riesgos.
Implantar una Gestión de Riesgos adecuada será un elemento decisivo a la hora de
asegurar el éxito del Proyecto, mediante la identificación y el análisis anticipado de los
riesgos potenciales que puedan afectar al Proyecto, y la elaboración de los planes de
contingencia adecuados, con el fin de evitarlos o minimizar el impacto en el Proyecto, en
caso de que finalmente el riesgo sea identificado y verificado.
Una perspectiva más amplia es la de explotar las oportunidades o posibilidades favorables
para el proyecto de tal forma que se convierte en una importante extensión del proceso de
planeación, especialmente en cuanto al diseño del proyecto y el plan base.
8.2. Propósito
Alcance
El contorno del análisis de riesgos cubre todo el desenvolvimiento de nuestro proyecto,
desde su fase inicial hasta el cierre de este; es necesario, durante el desarrollo del proyecto
revisar y actualizar los contenidos del análisis de riesgos en el eventual caso, de que se
detecten nuevos riegos que no fueron identificados en el plan inicial del proyecto, si no
que fueron apareciendo conforme el desarrollo de este.
El plan de gestión de riesgos que se describe en este documento deberá ser aplicado en
todas las fases del Proyecto.
8.3. Gestión del riesgo
La Gestión de riesgos es un enfoque estructurado para manejar una amenaza, a través de
una secuencia de actividades humanas que incluyen evaluación de riesgo, estrategias de
desarrollo para manejarlo y mitigación del riesgo utilizando recursos gerenciales.
8.3.1. Plan de gestión de los riegos
Para análisis y gestión de los riesgos expuestos se fundamentarán en acciones que
permitirán que el riesgo tenga un menor impacto y que se reduzca su nivel para lo
cual se iniciara con la identificación, análisis, priorización y hoja de gestión de
83
riesgos. Con las acciones mencionadas se tomará en cuenta los criterios de valor
para realizar el estudio de cada riesgo.
Impacto y probabilidad
Identificación Descripción Probabilidad Impacto Exposición al riesgo
% Probabi Valor Impacto Valor Exposición Valor

lidad
R1-Proyecto Mala recopilación 80% ALTA 3 CRITICO 4 ALTA 12
de información
para los requisitos
funcionales.
R2- Proyecto Mala planificación 75% ALTA 3 CRITICO 4 ALTA 12
de los recursos a
ocupar y tiempo
requerido para el
proyecto
R3- Proyecto Incumplimiento 80% ALTA 3 CRITICO 4 MEDIA 12
de la planificación
establecida por los
integrantes de
equipo de
desarrollo.
R4- Proyecto Errores en la 70% ALTA 3 ALTO 3 MEDIA 9
estimación del
presupuesto.
R5-Técnico Ataques a la 20% BAJO 1 ALTO 3 ALTA 3
infraestructura de
las
microempresas.
R6- Proyecto Abandono de un 55% MEDIA 2 ALTO 3 BAJA 6
miembro del
equipo de trabajo.
R7- Técnico Fallo en el 40% MEDIA 2 MODERA 2 MEDIA 4
hardware a DO
emplear.
R8- Técnico Escasez de 40% MEDIA 2 BAJO 1 ALTA 12
respaldo en la
información del
Sistema.
R9- Proyecto Falta de 50% MEDIA 3 MODERA 2 ALTA 6
conocimiento en DO
la tecnología a ser
implementada en
el Sistema.
R10-Negocio Incomprensión 10% BAJA 1 BAJO 1 BAJA 1
entre los
integrantes de
desarrollo.
R11- Negocio Excesivo trámite 10% BAJA 1 BAJO 1 BAJA 1
burocrático.
R12- Técnico Suspensión 10% BAJA 1 BAJO 1 BAJA 1
parcial de las
actividades de la
institución.
Criterios de valoración de los riesgos

84
Los riesgos fueron priorizados para conocer qué riesgo tendrá mayor impacto
negativo dentro del sistema, para ello se estableció criterios de valoración por
colores donde el color verde representa una exposición al riesgo bajo, el color
amarillo que representa una exposición media y color rojo que representa una
exposición alta en el desarrollo del sistema.
EXPOSICIÓN AL VALOR COLOR

RIESGO
BAJA 1o2 1
MEDIA 3o4 2
ALTA Mayor a 6 3
8.3.2. Identificación de los riegos

El proyecto se ha enfocado en la identificación de riesgos los cuales han arrojado
como resultado 12 riesgos, los cuales han sido clasificados de la siguiente manera:
6 Riesgos del Proyecto, 4 Riesgos Técnicos y 2 riesgos de negocio al tener
diferentes tipos de riesgos.
ID DESCRIPCIÓN EXPOSICIÓN VALOR PRIORIDAD
RIESGO
R1 Mala recopilación de ALTA 12 1
información para los
requisitos funcionales.
R2 Mala planificación de los ALTA 12 1
recursos a ocupar y tiempo
requerido para el proyecto
R3 Incumplimiento de la ALTA 12 1
planificación establecida
por los integrantes de
equipo de desarrollo.
R4 Errores en la estimación ALTA 9 2
del presupuesto.
R5 Ataques a la BAJA 3 3
infraestructura de las
microempresas.
R6 Abandono de un miembro MEDIA 6 3
del equipo de trabajo.
R7 Fallo en el hardware a MEDIA 4 4
emplear.
R8 Escasez de respaldo en la MEDIA 12 3
información del Sistema.
R9 Falta de conocimiento en MEDIA 6 5
la tecnología a ser
implementada en el
Sistema.
R10 Incomprensión entre los BAJA 1 5
integrantes de desarrollo.
R11 Excesivo trámite BAJA 1 5
burocrático.
85
R12 Suspensión parcial de las BAJA 1 5
actividades de la
institución.
8.3.3. Registro de riesgos
HOJA DE GESTIÓN DEL RIESGO

ID. DEL RIESGO: R01 FECHA: 20-01-2020
Probabilidad: Alta Impacto: Crítico Exposición: Alta Prioridad: 1
Valor: 3 Valor: 4 Valor: 12
DESCRIPCIÓN: Mala recolección de información para los requisitos funcionales.
REFINAMIENTO:
Causas:
● Falta de comunicación con el cliente
● Visión de los desarrolladores diferente que la del cliente
● Dificultad del cliente para relacionar sus necesidades con los requerimientos dados
Dificultad del desarrollador de capturar la información relevante de los requisitos
Consecuencias:
● Incremento en los costos de desarrollo
● Retraso del proyecto
● Difícil mantenimiento del software
● Mala calidad del software
REDUCCIÓN:
● Interacción con el cliente en cada fase del desarrollo para ir validando los requerimientos
● Documentar cada requisito e ir controlando el cumplimiento del mismo.
SUPERVISIÓN:
● Grado de compromiso del equipo de desarrollo en el proyecto
● Mejor relación del equipo desarrollador con el cliente
● Comprobar el cumplimiento de los estándares de documentación
● Verificar la correcta adaptación de los nuevos cambios al proyecto
GESTIÓN:
● Flexibilidad adaptando los nuevos cambios sin afectar los avances desarrollados
● Estimar nuevos costos por los cambios a realizar
● Realizar cambios con el menor costo posible
● Mantener el funcionamiento individual y en conjunto de los requerimientos establecidos
por el cliente en todo momento.
ESTADO ACTUAL:
Fase de reducción iniciada ✔
Fase de supervisión iniciada
Gestionando el riesgo

Probabilidad: Alta Impacto: Crítico Exposición: Alta Prioridad: Alta
DESCRIPCIÓN: Mala planificación de los recursos a ocupar y tiempo requerido para el
proyecto
REFINAMIENTO:
86
Causas:
● Falta de conocimiento del modelo matemático para el proceso de estimación de esfuerzo.
● Demasiada percepción de funcionamiento del sistema sin considerar posteriores cambios.
Consecuencias:
● Bajo rendimiento del software.
● Insatisfacción del cliente.
● Suspensión del desarrollo del software.
REDUCCIÓN:
● Replantear la estimación de esfuerzo mediante métodos matemáticos diferentes para
analizar el más adecuado.
● Dar más atención a establecer estimaciones de tiempo y esfuerzo por parte del equipo de
desarrollo ya que de esto depende el éxito del proyecto.
SUPERVISIÓN:
● Monitorear constantemente los recursos existentes ya sean de hardware o software.
● Analizar si es adecuado el replanteamiento de estimación de esfuerzo dependiendo el nivel
de afección.
● Verificar la correcta adaptación de los nuevos cambios al proyecto.
● Refactorizar constantemente cada parte del sistema para evitar un mayor contratiempo a
posteriori.
GESTIÓN:
● Llegar a un acuerdo con el cliente sobre el incremento del costo y la fecha de entrega del
proyecto por los nuevos cambios a realizar.
● Mantener informado constantemente al cliente de los cambios que puede existir en cuanto
a tiempo y esfuerzo de desarrollo, para que así se mantenga al tanto de las dificultades a
las que se enfrenta el proyecto.
ESTADO ACTUAL:

Probabilidad: Alta Impacto: Crítico Exposición: Alta Prioridad: Alta
DESCRIPCIÓN: Incumplimiento de la planificación establecida por los integrantes de equipo
de desarrollo.
REFINAMIENTO:
Causas:
● Falta de interés en el proceso de desarrollo del sistema.
● Problemas personales
● No comprender la estructura ni el funcionamiento del proyecto.
● Falta de coordinación de roles entre los miembros del equipo de desarrollo.
Consecuencias:
● Sobrecarga de trabajo para próximas iteraciones respecto a la que está en curso.
● Insatisfacción y falta de confianza por parte del cliente
● Agotar presupuesto económico antes de concluir con el proyecto
● Suspensión del desarrollo del software.
REDUCCIÓN:
87
● Establecer parámetros de cumplimiento estrictos para los integrantes del equipo de
desarrollo como por ejemplo excluir de la iteración en curso a los que incumplen la
planificación.
● Autoevaluar los conocimientos que poseen los integrantes del equipo para reforzar con lo
necesario a quienes tengan dificultad de aprendizaje.
SUPERVISIÓN:
● Monitorear constantemente las tareas a realizar en cada iteración de desarrollo del proyecto.
● Actualizar constantemente los requisitos del proyecto para ver el alcance al que se va a
llegar en el tiempo establecido.
● Analizar si es adecuado el replanteamiento de estimación de esfuerzo dependiendo el nivel
de afección.
● Verificar la correcta adaptación de los nuevos cambios al proyecto.
GESTIÓN:
● Mantener actualizada la documentación para verificar el avance del proyecto de acuerdo
a la planificación.
● Llevar un seguimiento continuo en el desarrollo de cada requerimiento.
ESTADO ACTUAL:

Probabilidad: Alta Impacto: Crítico Exposición: Prioridad: Alta
Valor: 3 Valor: 3 Media
Valor: 9
DESCRIPCIÓN: Errores en la estimación del presupuesto.
REFINAMIENTO:
Causas:
● Poca incursión en los detalles de diseño con el cliente.
● Estandarización del diseño de las interfaces con respecto a normas generales o criterios
personales.
Consecuencias:
● Desacuerdos con el cliente.
● Retrasos en el proyecto.
REDUCCIÓN:
● Analizar detalladamente los aspectos de diseño con el cliente.
● Manejar una interfaz amigable e intuitiva de las interfaces.
SUPERVISIÓN:
Involucrar frecuentemente al cliente en las etapas de diseño.
Proponer con el cliente ciertos estándares en el diseño de las interfaces en correspondencia con
lo que el cliente requiere.
GESTIÓN:
Corregir detalladamente errores en la compatibilidad del diseño del proyecto
Implementar constantemente diseños secundarios de las interfaces
ESTADO ACTUAL:
88
Probabilidad: baja Impacto: critico Exposición: media Prioridad: Baja
DESCRIPCIÓN: Ataques a la infraestructura de las microempresas.
REFINAMIENTO:
Causas:
● Problemas políticos, de seguridad nacional.
Consecuencias:
● Suspensión parcial o total del proyecto.
● Aumento de presupuesto del proyecto.
REDUCCIÓN:
 Implementar mayores normas de seguridad
SUPERVISIÓN:
 Como desarrolladores del proyecto no podemos hacer nada en este caso
GESTIÓN:
 Como desarrolladores del proyecto no podemos hacer nada en este caso
ESTADO ACTUAL:

Probabilidad: Baja Impacto: B a j o Exposición: Prioridad: M e d i a

Valor: 2 Valor: 3 Baja
Valor:
DESCRIPCIÓN: Abandono de un miembro del 6 de trabajo.
equipo
REFINAMIENTO:
Causas:
 Calamidad doméstica.
 Accidente fatal del integrante del proyecto.
Consecuencias:
 Retrasos en la entrega del proyecto.
 Afectación de costos.
REDUCCIÓN:
 Manejar personal de respaldo en caso de situaciones inesperadas.
 Compenetrarse y apoyar a los miembros del equipo en situaciones familiares difíciles.
89
SUPERVISIÓN:
 Mantener un ambiente muy sociable y agradable dentro del equipo de trabajo.
 Manejarse constantemente como un equipo de trabajo y no como un grupo, en base al apoyo y
comprensión.
GESTIÓN:
 Reestructurar la forma de trabajo del equipo de desarrollo.
 Reasignar tareas en base a las necesidades del equipo de trabajo para mantener el equilibrio
laboral.
ESTADO ACTUAL:

Probabilidad: Baja Impacto: Exposición: Baja Prioridad: Media
Valor: 1 Baja Valor: 1
Valor: 1
DESCRIPCIÓN: Fallo en el hardware a emplear.
REFINAMIENTO:
Causas:
● Dispositivos de almacenamiento atrofiados.
● Factores ambientales
● Accidentes Laborales
Consecuencias:
● Incremento en los costos de desarrollo.
● Suspensión temporal del proyecto.
● Retraso del proyecto
REDUCCIÓN:
● Mantener información respaldada del software del sistema en desarrollo.
● Mantener las normas de seguridad vigentes en el entorno de trabajo.
SUPERVISIÓN:
● Subir un respaldo cada día del avance del proyecto.
GESTIÓN:
● Comprar un nuevo equipo.
● Recuperar copia de seguridad.
● El jefe del proyecto puede volver asignar recursos y reajustar la planificación.
ESTADO ACTUAL:

Probabilidad: Impacto: Bajo Exposición: Alto Prioridad:
Media Valor: 1 Valor: 12 Media
Valor: 2
90
DESCRIPCIÓN: Escasez de respaldo en la información del Sistema.
REFINAMIENTO:
Causas:
● Servidores con pocos recursos.
● Muchas peticiones de la aplicación.
● Fallas hardware.
Consecuencias:
● Bajo rendimiento del software.
● Insatisfacción del cliente.
● Suspensión del servicio del software.
REDUCCIÓN:
 Como desarrolladores de software no hay nada que se pueda hacer en este caso.
SUPERVISIÓN:
● Monitorear constantemente los recursos, que posee el hardware.
GESTIÓN:
● Usar técnicas que permitan que nuestro sistema salte el error (try-cath)
● Aumentar capacidad de dispositivos hardware que estén al alcance de los desarrolladores.
ESTADO ACTUAL:

Probabilidad: Media Impacto: Exposición: Alto Prioridad: Media

Valor: 3 Moderado Valor: 6
Valor:
DESCRIPCIÓN: Falta de 2
conocimiento en la tecnología a ser implementada en el Sistema.
REFINAMIENTO:
Causas:
 El equipo de desarrollo tiene poca experiencia.
 Los integrantes del equipo tienen pocos conocimientos en las herramientas que se está
desarrollando el proyecto.
 No existe capacitación para el equipo de desarrollo.
 Falta de tiempo para familiarizarse con las herramientas de desarrollo.
Consecuencias:
 Retraso del proyecto
 Incremento de los costos en el desarrollo
 Incremento de costos en la capacitación del equipo de desarrollo.
 Pérdida de tiempo en iteraciones poco complicadas.
 Mala calidad del software
 Cliente poco satisfecho
REDUCCIÓN:
 Conocer las capacidades de cada integrante del equipo de desarrollo.
 Comunicación con el equipo de trabajo.
 Elegir una metodología de desarrollo que sea flexible a cambios.
91
SUPERVISIÓN:
 Compromiso del equipo de desarrollo en el proyecto.
 No asignar trabajo adicional a nos integrantes del equipo desarrollo.
 Cumplir con la planificación planteada.
 Verificar la correcta adaptación de los nuevos cambios al proyecto.
GESTIÓN:
 Comunicación con los integrantes del equipo de desarrollo.
 Reajuste de la planificación.
 Tener toda la documentación de cada iteración terminada.
 Realizar cambios con el menor costo.
ESTADO ACTUAL:

Probabilidad: Baja Impacto: Baja Exposición: Baja Prioridad: Baja

DESCRIPCIÓN: Incomprensión entre los integrantes de desarrollo.
REFINAMIENTO:
Causas:
 Los miembros del equipo tienen puntos de vista diferentes.
 Los desarrolladores tienen una visión diferente al del cliente.
 Poca comunicación entre los integrantes del equipo.
 Poca colaboración en el desarrollo del proyecto por parte de los integrantes.
 Poca motivación por parte del equipo de desarrollo.
Consecuencias:
 Retraso del proyecto
 Aumento de la carga de trabajo.
 Retiro de algún integrante del equipo de desarrollo.
 Cliente poco satisfecho.
REDUCCIÓN:
 Comunicación con el equipo de trabajo.
 Crear grupos de motivación para el equipo de trabajo.
 Respetar los horarios establecidos en la planificación.
SUPERVISIÓN:
 Compromiso en el equipo de trabajo.
 Tener un buen ambiente entre integrantes de desarrollo.
 Mejor relación del equipo de desarrollador con el cliente
92
GESTIÓN:
 Tener toda la documentación y backup de todo el desarrollo del proyecto.
 Flexibilidad adaptando los nuevos cambios sin afectar los avances desarrollados.
 Dialogar con el cliente y llegar a un acuerdo sobre los cambios a realizar.
 Mejorar la comunicación entre los integrantes del equipo.
ESTADO ACTUAL:

Probabilidad: Baja Impacto: Baja Exposición: Baja Prioridad:
Valor: 1 Valor: 1 Valor: 1 Baja
DESCRIPCIÓN: Excesivo trámite burocrático.
REFINAMIENTO:
Causas:
 Las políticas de gestión del departamento fueron cambiadas durante el desarrollo del proyecto.
 Los desarrolladores no tienen conocimiento de las políticas del departamento.
 El reglamento ya cumplía con la vigencia establecida.
 El proyecto tardo más del tiempo planificado.
Consecuencias:
 Suspensión temporal del proyecto
 Incremento de los costos en el desarrollo
 Suspensión indefinida del proyecto.
REDUCCIÓN:
 Identificar claramente la necesidad del cliente.
 Comunicación frecuente con el cliente en cada avance del proyecto.
SUPERVISIÓN:
 Compromiso del equipo de desarrollo para cumplir con la planificación sin retrasos.
 Comprobar el cumplimiento de los estándares de documentación.
 Tener en cuenta los reglamentes de la institución a la hora de la planificación del proyecto.
GESTIÓN:
 Tener toda la documentación y backup del avance del proyecto.
 Flexibilidad a la hora de adaptar los nuevos cambios.
 Estimar nuevos costos por los cambios a realizar.
 Dialogar con el cliente y llegar a un acuerdo sobre los cambios a realizar de acuerdo con las
nuevas políticas de gestión.
 Nueva asignación de recursos y reajuste de planificación.
ESTADO ACTUAL:
93

Probabilidad: Baja Impacto: Baja Exposición: Baja Prioridad:
Valor: 1 Valor: a Valor: 1 Baja
DESCRIPCIÓN: Suspensión parcial de las actividades de la institución.
REFINAMIENTO:
Causas:
● Decretos de gobierno Nacional y local.
● Huelga o marcha dentro de la institución.
Consecuencias:
● Replanificación del proyecto.
REDUCCIÓN:
● Llevar una buena comunicación con el equipo de desarrollo.
SUPERVISIÓN:
● Como desarrollador del sistema no se puede hacer nada al respecto
GESTIÓN:
● Replanificación del proyecto.
● Reorganización para lograr trabajar en el proyecto.
ESTADO ACTUAL:
8.3.4. Análisis cualitativo de riesgos identificados

ID DESCRIPCIÓN Acciones Preventivas Acciones Correctivas
RIESGO
R1 Mala recopilación de Convocar al cliente Implementar cambios de
información para los para recopilar los requisitos.
requisitos funcionales. nuevamente la
información de los
requisitos.
R2 Mala planificación de los Realizar una Implementar el cambio de
recursos a ocupar y tiempo replanificación de los la planificación.
requerido para el proyecto requerimientos
R3 Incumplimiento de la Hacer reuniones diarias Realizar todas las tareas
planificación establecida para no retrasar de lo requeridas.
por los integrantes de planificado
equipo de desarrollo.
R4 Errores en la estimación Realizar de manera Implementar una
del presupuesto. adecuada el herramienta Cocomo II,
presupuesto mediante que es muy utilizado para
alguna herramienta. sacar las estimaciones
R5 Ataques a la Revisar toda la parte Implementar nuevas
infraestructura de las tecnológica de las tecnologías de seguridad
microempresas. microempresas.
R6 Abandono de un miembro Estar seguro de Retraso en la ejecución de
del equipo de trabajo. pertenecer al proyecto las actividades
planificadas para el
94
proyecto. 
R7 Fallo en el hardware a Revisar todos los Implementar nuevos
emplear. equipos necesarios para equipos.
el desarrollo.
R8 Escasez de respaldo en la Asegurar que el cliente Cambiar de proyecto si el
información del Sistema. esté dispuesto a ayudar cliente no desee apoyar.
con la información.
R9 Falta de conocimiento en Retraso en el desarrollo Designar responsables
la tecnología a ser del proyecto y las para investigar sobre las
implementada en el actividades tecnologías y compartir
Sistema. planificadas. con el equipo trabajo
R10 Incomprensión entre los Defectos en el sistema Socialización entre las
integrantes de desarrollo. y en la organización, partes acorde con la
insatisfacción de metodología propuesta.
alguna de las partes
R11 Excesivo trámite Retraso en la entrega Negociación con el
burocrático. de la siguiente cliente y replanificación.
iteración.
R12 Suspensión parcial de las Replanificación del Reorganización para
actividades de la proyecto. lograr trabajar en el
institución. proyecto.
8.3.5. Planificar la respuesta a los riesgos

Id. Responsable Fecha de Estado Observaciones
Terminación
 Jorge Jiménez
 María José Quinatoa
 Alexander Tubón Negociación con el cliente
R1 Fin del Proyecto Iniciado
 Cecilio Tasna y replanificación.
 Mirian Tipan
 Jorge Jiménez
Realizar de manera
 Alexander Tubón
R2 Fin del Proyecto Iniciado correcta el tiempo
 Cecilio Tasna estimado del proyecto
 Mirian Tipan
 Jorge Jiménez
 Mirian Tipan
 Jorge Jiménez
 María José Quinatoa Realizar de manera
R4 Fin del Proyecto Iniciado correcta el tiempo
estimado del proyecto
 Cecilio Tasna
95
 Mirian Tipan
R5 Cliente Ing. Ligia Niama Fin del Proyecto Iniciado Negociación con el cliente
 Jorge Jiménez
 María José Quinatoa Retraso en la ejecución de
 Alexander Tubón las actividades
 Cecilio Tasna planificadas para el
proyecto. 
 Mirian Tipan
 Jorge Jiménez
R7 Fin del Proyecto Iniciado Negociación con el cliente
 Cecilio Tasna
 Mirian Tipan
Hay que asegurar que el

cliente esté dispuesto a
R8 Cliente Ing. Ligia Niama
ayudar con la
información.
 Jorge Jiménez
 María José Quinatoa Designar responsables
 Alexander Tubón para investigar sobre las
 Cecilio Tasna tecnologías y compartir
con el equipo trabajo
 Mirian Tipan
 Jorge Jiménez
Socialización entre las
R10 Fin del Proyecto Iniciado partes acorde con la
 Cecilio Tasna metodología propuesta.
 Mirian Tipan
 Jorge Jiménez
 Mirian Tipan
Reorganización para
R12 Gobierno Fin del Proyecto Iniciado lograr trabajar en el
proyecto.
96
9. PLAN DE GESTIÓN DE ADQUISICIONES
Una de las necesidades o requerimientos del presente proyecto tiene que ver con la búsqueda
de servicios de hosting y de dominio para la aplicación web y los servicios web que necesiten
ser exportados y consumidos dentro de la aplicación independientemente de su plataforma de
desarrollo.
Recursos para la adquisición
Para este proyecto los responsables de realizar las labores de compra y contratación son:
 El Gerente del Proyecto en la parte de subcontratos, es quien aprueba las
subcontrataciones; y
 El Líder de calidad, quien ejecuta las compras y adquisiciones solicitadas por el
Gerente del Proyecto en este caso el líder de calidad solicita respuestas de los
vendedores y selecciona a los mismos.
 El Líder de calidad y el Gerente del Proyecto realizan las Solicitudes de compra los
días martes y viernes, asimismo se encargan de realizar la inspección, evaluación y
aceptación de los trabajos contratados y cierre de los contratos.
Productos y servicios a contratar
 Servicios de hosting y de dominio
 Servicio de internet.
 Equipos de computación.
 Suministros de muebles y equipos de oficina.
Procedimiento para la gestión de adquisiciones
N. PROCEDIMIENTO EN EL PROCEDIMIENTO EN EL ÁREA
PROYECTO PARA SOLICITUD DE LOGÍSTICA PARA REALIZAR ORDEN
COMPRA DE COMPRA
El líder de calidad elabora la solicitud de Se debe elaborar la orden de compra
compra. Este documento describe el correspondiente. Este documento debe
producto a pedir, cantidad en unidades a describir claramente la fecha, nombre
pedir. Luego de evaluar el comprador de la completo del proveedor, persona de
empresa a los proveedores regresa una contacto si es posible, número de teléfono,
1 plantilla para tomar la decisión técnica y descripción completa del producto a pedir,
económica del proveedor que mejor se cantidad en unidades a pedir, precio y
ajuste a los requerimientos del proyecto. La monto total. La orden de compra debe ser
plantilla debe ser autorizada por el Líder de confeccionada por el comprador de la
calidad con el Visto Bueno del Gerente del empresa y debe ser autorizada previamente
Proyecto. por el Gerente del Proyecto.
97
Cuando el borrador que llega viene con un Si la orden de compra es por un monto
solo concursante, dicho documento se mayor a los 5,000 dólares debe ser ratificada
2 regresa para que vuelvan a cotizar, mínimo por el Gerente General.
3 ofertantes.
Toda compra de urgencia, se solicita por Para materiales de urgencia y con montos
3 email, para que se disponga de caja chica. menores de 200 dólares se maneja a través
de la caja chica.
Toda compra que supere los 2,000 dólares Una vez confeccionada, se procede al envío
y que no éste dentro del presupuesto, debe de la orden de compra al proveedor, la
4
generarse nueva Planificación misma debe ser confirmada en el número
correspondiente.
5 Se confirma vía telefónica con la persona de
contacto, el recibo de la orden, la fecha y el
lugar de entrega para el producto.
6 Se archiva el original de la orden de compra
por consecutivo. La copia se deja en el
departamento de documentación.
98
Matriz de adquisiciones
PRODUCTO O TIPO DE PROCEDIMIENTO DE FORMA DE PERSONA MANEJO DE CRONOGRAMA DE ADQUISICIONES

SERVICIO A RESPONSABL REQUERIDAS
CONTRAT CONTRATACIÓN CONTACTAR MÚLTIPLES
E DE LA
ADQUIRIR O PROVEEDORES COMPRA PROVEEDOR Planif. Solic. Selecc. Admin. Cerrar
ES Contrat Resp. Proveed. Contrato Contrato
Del al Del al Del al Del al Del al
-Solicitud de servicios.
Servicios de -Revisión de del hosting y Solicitud de
Precio
hosting y dominios. información
Fijo Líder de calidad Lista de 14/10/19 17/10/19 21/10/19 21/10/19 24/10/19
dominios -Confirmación hosting y mediante
dominio. llamadas Proveedores
-Firma de Contrato. telefónicas y
-Pago de Honorarios correo
terminado el servicio. electrónico.
Proveedor predefinido.
Suministros de
Precio Líder de
equipos de Proveedor
computación Fijo documentación Proveedor 14/10/19 15/10/19 16/10/19 16/10/19 16/10/19
predefinido.
único
Proveedor predefinido.
Suministros de Precio Fijo
muebles y Proveedor
equipos de predefinido. Líder de Proveedor único 14/10/19 17/10/19 18/10/19 21/10/19 21/10/19
oficina documentación
Proveedor predefinido. Líder de calidad
Servicio de
Precio
internet Proveedor Proveedor
Fijo único 14/10/19 29/10/19 29/10/19 29/10/19 05/11/19
predefinido.
10. PLAN DE GESTIÓN DE INTERESADOS
10.1. Registro Preliminar
REGISTRO DE LOS INTERESADOS

Preparado por: Alexander Tubón –Líder de calidad Fecha 20/11/2019
Código: RI-001 Versión: 1.0.0
100
Nombres Informaci Influencia
Organizació Requerimientos
y Cargo ón de Influencia sobre Tipo de Interés
n sobre el producto
Apellidos contacto I P E S C
alejandra. Fase Inicio,
Alejandra onate@es Desarrollo móvil Planificación,
ESPOCH Docente F F F F F Control del proceso
Oñate poch.edu. nativo y web. Ejecución, Supervisión
ec y control y cierre
Automatización de
Económico (Mayor
ligia.niam los procesos de
Ligia producción y mejora en la
CIEAL Gerente a@espoch gestión en la F F
Niama gestión de cuentas por
.edu.ec empresa que
cobrar)
representa.
Cumplimiento de los
objetivos planteados
Fase Inicio,
para el proyecto a
J-CAMP Planificación, Logro de objetivos
Desarrolladores tiempo, bajo F F F F F
S.A. Ejecución, Supervisión estratégicos
presupuesto y con un
y control y cierre
nivel adecuado de
calidad.
Otros Económico (Mayor
distribuidores y producción y mejora de los
F Fase de cierre
comerciantes de procesos de gestión de
Ecuador cuentas por cobrar)
Otros
desarrolladores y
Económico (Explotación de
empresas de
sus productos y soluciones
desarrollo que C Fase de cierre
tecnológicas por sobre la
trabajan con
competencia)
sistemas de
gestión afines.
Usuarios del Ser más productivo a la hora
F
sistema de efectuar sus compras.
Nomenclatura:
Influencia (Fases del proyecto):
I: Inicial, P: Planificación, E: Ejecución, S: Seguimiento, C: Cierre, F: Favorable, C: Contraria
101
10.2. Gestión de los interesados
PLAN DE GESTIÓN DE LOS
INTERESADOS
Preparado por: Alexander Tubón – Líder del Proyecto / Líder de Fecha 20/11/2019
calidad
CONTEXTO DEL PROYECTO

1. Registro de Interesados
El registro correspondiente se ha establecido con código RI-001 Versión 1.0.0 en el denominado
“Registro Preliminar” por favor referirse al documento correspondiente para su revisión.
2. Análisis de los interesados
El análisis de los interesados se lo ha realizado a través de una matriz de Poder / Interés:

GRADO DE INTERÉS
BAJO ALTO
ALTO Clientes de los usuarios distribuidores del Usuarios distribuidores

sistema J-PAYMENT del sistema J-PAYMENT
GRADO DE PODER
(Gerente empresa
CIEAL: Ing. Ligia
Niama)
BAJO Otros desarrolladores y empresas de
desarrollo que trabajan con sistemas de
gestión afines. Otros distribuidores y
(LÓGICA SOFTWARE, Lógica.ec – comerciantes del Ecuador
Desarrollo de Software, Technology
Firts, Inc., Kooper, DisruptiveLogic,
ITSOLUTIONS)
3. Nivel de compromiso de los interesados

La clasificación de los niveles de compromiso de los interesados (Inconsciente, resistente, neutral, apoyo,
líder) se encuentra predispuesto a continuación:
- Ing. Alejandra Oñate: Apoyo al control general de los procesos a implementarse y seguimiento
de estos.
- Ing. Ligia Niama: Apoyo en brindar información relevante y delicada de las actividades a ser
automatizadas para asegurar su correcta implementación.
4. Cómo identificar las interrelaciones y las superposiciones entre los interesados

- Reuniones periódicas tanto con la ing. Alejandra Oñate y la cliente ing. Ligia Niama para
socializar propuestas y llegar a mutuos acuerdos.
5. Cómo elabora las necesidades de información de los interesados
El registro correspondiente se ha establecido con código RI-001 Versión 1.0.0 en el denominado
“Registro Preliminar” por favor referirse al documento correspondiente para su revisión.
6. Cómo la información requerida por los interesados será entregada y su frecuencia
- Reuniones semanales para evaluar las actividades desarrolladas tras cada iteración producto de
la aplicación del método Scrum tanto con la ing. Alejandra Oñate y la cliente ing. Ligia Niama.
7. Cómo se actualizará este documento a medida que avance la ejecución del proyecto
- En caso de llegar a la formulación de un nuevo registro o modificar un existente, este será
establecido con un código y versión nuevas que servirán de referencia.
10.3 Registro de Incidentes

La gestión de la participación de los interesados puede dar lugar al desarrollo de un registro de
incidentes. Este registro se actualiza a medida que se identifican nuevos incidentes y se
resuelven los incidentes actuales, el modelo se detalla a continuación:
REGISTRO DE INCIDENTES
CÓDIGO …
versión #.#
PROYECTO:
GERENTE:
PREPARADO FECH
POR: A
REVISADO POR: FECH
A
NÚMERO:
DENOMINACIÓN
DEL INCIDENTE:
103
1. DESCRIPCIÓN DEL INCIDENTE
(Qué fue lo ocurrido, cuáles fueron las causas, quienes participaron, reacciones y efectos inmediatos)
2. IMPACTO QUE PODRÍA GENERAR EL INCIDENTE

(Cómo afecta el incidente ocurrido a los objetivos del proyecto)
3. ROLES INVOLUCRADOS EN EL INCIDENTE

(Interesados en el proyecto que participaron en el incidente)
Nombres y apellidos Rol Organización
4. ACCIONES TOMADAS PARA RESOLVER EL INCIDENTE

(Estrategias, actividades o coordinaciones, entre otras, realizadas para resolver el incidente)
5. ACUERDOS TOMADOS PARA RESOLVER EL INCIDENTE

(Acuerdos, compromisos, etc., tomados entre las partes, formales y oficiales para resolver y superar el incidente)
6. FACILITADOR DEL INCIDENTE

(Nombres, apellidos, rol e información de contacto –si corresponde– de la persona que actuó como facilitador)
7. RECOMENDACIONES PARA FUTUROS PROYECTOS

(Pautas que deberían considerarse a futuro para evitar o minimizar que ocurran incidentes similares)
RELACIÓN DE ANEXOS
(si aplica)
ANEXO 1
ANEXO 2
10.4 Solicitudes de cambio

Las solicitudes de cambio a su vez permitirán establecer ciertos correctivos que promuevan la
participación de todos y cada uno de los involucrados en el proyecto, esta solicitud se detallará
incluyendo acciones correctivas o preventivas aplicables al propio proyecto o la interacción con
los interesados afectados y se registrará en un documento que oficializará los requerimientos de
cambios dentro del proyecto, y este se presenta a continuación:
104
CONTROL DE CAMBIOS
Fecha solicitud:
Solicitante: _________________________________________________________
Descripción: _________________________________________________________
Razón: _________________________________________________________
Prioridad del Cambio Tipo de Cambio

Crítica Alta Media Baja Mayor Medio Menor
Impacto requerimiento de cambio

Costos Entregables Carga de trabajo Recursos Proyecto Cronograma Otros
Estado del Requerimiento de Cambio

Aprobado Rechazado Postergado Fecha Responsable Fecha Implementación
Observaciones y Recomendaciones: _______________________________________________________

______________________________________________________________________________________
______________________________________________________________________________________
______________________________________________________________________________________
Elaborado por: ____________________________
105

Gestion Proyecto JCAMP

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Gestion Proyecto JCAMP

Cargado por

Copyright:

Formatos disponibles

ESCUELA SUPERIOR POLITÉCNICA DE CHIMBORAZO

FACULTAD DE INFORMÁTICA Y ELECTRÓNICA

“APLICACIÓN WEB Y MÓVIL PARA EL CONTROL DE

Tipán Mirian (5982)

Jiménez Jorge (6087)

Tasna Cecilio (6097)

Tubón Alexander (6214)

Quinatoa María José (6216)

ESTRATEGIA DE INNOVACIÓN .................................................................................................. 7

Técnica Brainstorming ....................................................................................................................... 7

¿Cómo se utiliza? ........................................................................................................................... 8

Nombre de la Empresa ..................................................................................................................... 10

Políticas (Para orientación de las decisiones empresariales) ............................................................ 10

Estrategias (para cumplir misión y visión) ....................................................................................... 10

Proceso de Negocio ......................................................................................................................... 11

Diseño y herramientas tecnológicas ................................................................................................. 13

Lenguaje de Programación Java ....................................................................................................... 13

Ventajas y Desventajas ................................................................................................................ 13

Base de datos Mysql ........................................................................................................................ 14

API REST ........................................................................................................................................ 14

1.1.1. Desventajas .................................................................................................................. 15

Alcance en el proyecto ..................................................................................................................... 18

LA METODOLOGÍA XP EN LA ORGANIZACIÓN .................................................................... 19

APLICACIÓN DE LA METODOLOGÍA ....................................................................................... 19

Historias de usuario ......................................................................................................................... 22

Historias técnicas ......................................................................................................................... 23

Plan de entrega ................................................................................................................................. 24

Tabulación de puntos de esfuerzo estimados ............................................................................... 24

Plan de entrega ............................................................................................................................. 29

PLAN DE GESTIÓN DEL PROYECTO ............................................................................................ 33

1. PLAN PARA LA DIRECCIÓN DEL PROYECTO ................................................................ 33

2. PLAN DE GESTIÓN DE INTEGRACIÓN ............................................................................. 37

3. PLAN DE GESTIÓN DE ALCANCE ..................................................................................... 47

2.1. Declaración del Alcance ........................................................................................................... 47

2.2. Gestión de los requisitos ....................................................................................................... 52

2.3. Estructura de desglose de trabajo .................................................................................... 57

3. PLAN DE GESTIÓN DE TIEMPO ......................................................................................... 59

4. PLAN DE GESTIÓN DE COSTO ........................................................................................... 65

5. PLAN DE GESTIÓN DE LA CALIDAD ................................................................................ 69

5.1. Gestión de la Calidad ........................................................................................................... 69

6. PLAN DE GESTIÓN DE RECURSOS HUMANOS .............................................................. 75

6.1. Recursos Humanos ........................................................................................................... 75

6.2. Organización del proyecto................................................................................................ 79

7. PLAN DE GESTIÓN DE COMUNICACIONES .................................................................... 80

7.1. Requisitos de Comunicación ............................................................................................ 80

7.2. Matriz de Comunicación .................................................................................................. 80

7.3. Canales de Comunicación ................................................................................................ 81

7.4. Distribución de la información ......................................................................................... 81

8. PLAN DE GESTIÓN DE RIESGOS ....................................................................................... 83

8.1. Introducción ..................................................................................................................... 83

8.2. Propósito .......................................................................................................................... 83

8.3. Gestión del riesgo ............................................................................................................. 83

8.3.1. Plan de gestión de los riegos ........................................................................................ 83

8.3.2. Identificación de los riegos ........................................................................................... 85

8.3.3. Registro de riesgos ....................................................................................................... 86

8.3.4. Análisis cualitativo de riesgos identificados ................................................................. 94

8.3.5. Planificar la respuesta a los riesgos .............................................................................. 95

9. PLAN DE GESTIÓN DE ADQUISICIONES ......................................................................... 97

10. PLAN DE GESTIÓN DE INTERESADOS ....................................................................... 100

10.1. Registro Preliminar .................................................................................................... 100

10.2. Gestión de los interesados .......................................................................................... 102

10.3 Registro de Incidentes .................................................................................................... 103

10.4 Solicitudes de cambio .................................................................................................... 104