Contenido

Capítulo I: Planeamiento del problema ......................................................................................... 3

1.1 Situación problemática.................................................................................................. 3

1.2 Formulación del problema ............................................................................................ 3

1.3 Objetivo de la investigación .......................................................................................... 3

1.3.1 Objetivo general .................................................................................................... 3

1.4 Justificación de la investigación ................................................................................... 4

1.4.1 Viabilidad operativa .............................................................................................. 5

1.4.2 Viabilidad técnica ................................................................................................. 5

1.4.3 Viabilidad económica ........................................................................................... 5

Capitulo II: Marco Teórico ........................................................................................................... 6

2.1. Antecedentes ................................................................................................................. 6

2.1.1. Antecedente 1........................................................................................................ 6

2.1.2. Antecedente 2........................................................................................................ 6

2.1.3. Antecedente 3........................................................................................................ 7

2.2. Bases Teóricas .............................................................................................................. 8

2.2.1. Amazona Chocolate .............................................................................................. 8

2.2.2. Inteligencia de Negocios ..................................................................................... 10

2.2.3. Metodología Ralph Kimball................................................................................ 11

2.2.4. Metodología Bill Inmon ...................................................................................... 17

2.2.5. Herramienta de desarrollo ................................................................................... 18

 2.3. Terminología ............................................................................................................... 19

2.3.1. Data Warehouse .................................................................................................. 19

2.3.2. Data Mart ............................................................................................................ 20

2.3.3. Base de datos STAGE ......................................................................................... 20

2.3.4. OLTP (On Line Transaction Processing) ............................................................ 21

2.3.5. OLAP (On Line Analyzing Processing) ............................................................. 21

2.3.6. Proceso ETL........................................................................................................ 21

2.3.7. Modelo Multidimensional ................................................................................... 22

Capitulo III: Metodología ........................................................................................................... 24

3.1. Materiales.................................................................................................................... 24

3.1.1. Recurso Humano ................................................................................................. 24

3.1.2. Recurso Tecnológico........................................................................................... 26

3.2. Método ............................................................................................................................. 28

3.3. Plan de Trabajo ................................................................................................................ 34

 Capítulo I: Planeamiento del problema

1.1 Situación problemática

El presente proyecto surge por la necesidad de la empresa de contar con datos estadísticos

sobre las ventas de sus productos de chocolate en las diferentes ferias que participan, con

el fin de poder distribuir de mejor manera su mercadería, evitando costes adicionales por

nuevo empaquetado y daño del producto. Amazona chocolate realiza el registro de venta

de sus productos mediante una hoja de Excel, lo cual dificulta al administrador y al

Gerente General poder distribuir sus productos de la mejor manera.

1.2 Formulación del problema

Inadecuado registro de ventas de la empresa Amazona Chocolate para la distribución de

sus productos de chocolate.

1.3 Objetivo de la investigación

1.3.1 Objetivo general

Implementar un sistema de información utilizando la tecnología de inteligencia de

negocios para generar conocimiento a la empresa sobre la venta de sus productos y la

empresa pueda distribuir de mejor manera su mercadería.

1.3.2 Objetivos específicos

 Integrar los datos de la empresa.

 Elaborar cuadros estadísticos para que la empresa pueda visualizar la información de

sus ventas de una manera sencilla y dinámica.

 Incrementar la efectividad en las ventas de amazona chocolate

 Obtener reportes mensuales sobre la venta de los productos.

 Mejorar la toma de decisiones con respecto a los productos a enviar a cada feria.

1.4 Justificación de la investigación

La importancia de implementar un sistema basado en la inteligencia de negocios son las

siguientes:

 Ayudaría a la empresa a poder distribuir de mejor manera sus productos en las

 diferentes ferias donde participa.

 Lograran poder tener reportes mensuales sobre las ventas de sus productos.

 La empresa podrá conocer que productos son los más aceptados por sus clientes

 Evitará gastos adicionales en productos que no tienen mucha demanda.

 Permitirá a la empresa poder invertir más en productos con mayor demanda.

1.4.1 Viabilidad operativa

El objetivo de proyecto es crear un sistema de información usando la tecnología de

inteligencia de negocios para que pueda permitir a la empresa tener un reporte de ventas y

así lograr mayor eficiencia en la venta de sus productos que distribuye a distintas ferias.

1.4.2 Viabilidad técnica

Para la implementación del sistema de información se cuenta con los siguientes equipos

tecnológicos:

 Una laptop marca LENOVO modelo y50-70 que cuenta con un procesador Intel

Core i7, con una memoria RAM de 16GB y disco duro de 1TB.

 Una laptop marca HP modelo Pavilion que cuenta con un procesador Intel Core i7,

con una memoria RAM de 16GB y disco duro de 1TB

1.4.3 Viabilidad económica

 Capitulo II: Marco Teórico

2.1. Antecedentes

2.1.1. Antecedente 1

Tesis: “IMPLEMENTACIÓN DE BUSINESS INTELLIGENCE PARA

MEJORAR EL FLUJO DE INFORMACIÓN Y LA TOMA DE DECISIONES

EN LA ENCUESTA NACIONAL DE HOGARES ENAHO - INEI”

Autor: Erick Roger Gonzales Segovia

Año: 2016

La tesis se basa en la implementación de la inteligencia de negocio enfocado para

la encuesta nacional de hogares ENAHO-INEI, que permite apoyar la toma de

decisiones y agilizar el flujo de información dentro de la encuesta.

Se uso la Metodologia Kimball que aseguro el desarrollo optimo para el proyecto,

esto logro que puedan obtener un sistema con datos confiables disponibles para el

analisis

Como resultado de la investigación se permitió obtener información en tiempo

real, con data actualizada de las bases de datos transaccionales de una forma

sencilla el cual ayuda a supervidores y jefes encargados.

2.1.2. Antecedente 2

Tesis: “Implementación de un Sistema de Información Ejecutiva utilizando

Inteligencia de Negocios para la eficaz interpretación de Indicadores de Atención

y Afiliación en el Seguro Integral de Salud para la administración de la Red de

Salud de Huarochirí”
 Autor: Ronnal Efrain Andrago Guazumba y Yesibel Melina Palomino Ochoa

Año: 2015

Esta tesis se basa en la construcción de un sistema de información ejecutivo

utilizando inteligencia de negocios, el cual muestra indicadores basados en las

variables de atención y afiliación del SIS para la correcta toma de decisiones en la

administración de la red de salud de Huarochirí.

La construcción e implementación de la aplicación fue realizada bajo la

metodología Ralph Kimball con la implementación técnica de la metodología

Hefesto para el desarrollo del modelo lógico del Datamart.

Se tomo las nueve fases de Kimball, la planificación del proyecto, definición de

requerimientos, diseño físico, modelo dimensional, diseño e implementación del

ETL, implementación, mantenimiento y crecimiento del Datamart, especificación

de aplicaciones de BI en el análisis service de visual y el diseño de la arquitectura

técnica.

Se logro la implementación del sistema de inteligencia de negocios basado en la

metodología hibrida de Kimball y Hefesto para lograr una eficaz interpretación en

el Seguro Integral de Salud (SIS).

2.1.3. Antecedente 3

Tesis: “Implementación de Business Intelligence para mejorar la eficiencia de la

toma de decisiones en la gestión de proyectos”

Autor: Marlene Elisa Carhuaricra Inocente y Jenny Isabel Gonzales Caporal

Año: 2017
 La tesis se basa en la construcción de un sistema basado en inteligencia de

negocios, para una empresa con 15 años de experiencia en la industria de la s

telecomunicaciones e infraestructura de TI.

Para esta tesis se consideró que el estudio que realizaban es de tipo experimental

por lo cual tomaron en cuenta a Hernandez, Fernandez y Baptista, autor el cual

denomina que la investigación puede ser categorizada como transversal y de

campo, al realizar una sola medición de la variable dependiente en las mismas

condiciones donde se evidencia.

Los resultados que se obtuvieron: reducir los tiempos de solución y prevención de

las fallas de los suministros eléctricos, disminuyendo los pagos por compensación

de suministros establecidos por Osinergmin hacia los usuarios del servicio

eléctrico; así como también la obtención de las estadísticas e indicadores de fallas

para una adecuada toma de decisiones.

2.2. Bases Teóricas

2.2.1. Amazona Chocolate

Breve Historia

Amazona Chocolate fue creada en el 2013 con el fin de desarrollar un nuevo

concepto en chocolatería: utilizar cacao de diversos orígenes del Perú y de alta

calidad en sus procesos. La estrategia consistía en enfocarse en el mercado local

aprovechando que en ese momento los conceptos orgánico y saludable estaban

en fase de expansión y también que se consolidaba la gastronomía nacional.

Durante los últimos 4 años se ha ido reinventando los procesos

con packaging sostenible, concepto de biodiversidad y empleando la Educación

al Consumidor, manteniendo siempre el principio orgánico. Desde el 2016 se ha

visto necesario llevar la marca a la internacionalización a mercados que

respondan a nuestros objetivos de calidad, sostenibilidad y biodiversidad. Para

ello se ha logrado la distinción Great Taste en Londres, que obtienen productos

de especialidad asociados justamente a nuestros objetivos. Se busca resaltar

estos factores diferenciadores como estrategia de internacionalización.

Estrategia Amazona chocolate

Visión: Afianzarnos como una marca muy reconocida y respetada de chocolate

de la más alta calidad, tomar el liderazgo en producción nacional e internacional

de chocolate orgánico, posicionar nuestro cacao peruano como una especie única

en el mundo y dar a conocer a nuestros clientes sobre la calidad del cacao

peruano a través de nuestra diversidad de productos.

Misión: Dedicada a producir chocolates de la más alta calidad y con los mejores

orígenes de cacao peruano, trabajamos bajo un sistema de outsourcing para la

fabricación de nuestros productos.

2.2.2. Inteligencia de Negocios

“Las aplicaciones de Business Intelligence (BI) son herramientas de

soporte de decisiones que permiten en tiempo real, acceso interactivo, análisis y

manipulación de información crítica para la empresa. Estas aplicaciones

proporcionan a los usuarios un mayor entendimiento que les permite identificar las

oportunidades y los problemas de los negocios. Los usuarios son capaces de acceder

y apalancar una vasta cantidad de información y analizar sus relaciones y entender

las tendencias que últimamente están apoyando las decisiones de los negocios. Estas

herramientas previenen una potencial pérdida de conocimiento dentro de la empresa

que resulta de una acumulación masiva de información que no es fácil de leer o de

usar”

(CherryTree & Co., 2000)

“Business Intelligence (BI) es un conjunto de conceptos y metodologías

para mejorar la toma de decisiones a través del uso de hechos y sistemas basados

en hechos”

(Gartner Group)

En definitiva, podemos afirmar que la inteligencia de negocio puede

tener dos proyecciones diferentes según se mire desde el punto de vista del

negocio o desde el punto de vista técnico, donde se tienen más en cuenta las

herramientas y las tecnologías por encima de la metodología de uso de la

información en la toma de decisiones del negocio.

 Ilustración 1: Proceso de BI

Fuente: Documentos del curso de BI

2.2.3. Metodología Ralph Kimball

La metodología de Ralph Kimball está enfocada principalmente en la

construcción del Data Warehouse. La metodología conocida como ciclo de vida del

Road Map Dimensional de Negocio establece lo siguiente: “la razón de ser de los

proyectos de Business Intelligence y de muchos otros, es el negocio, por lo tanto,

uno de los puntos importantes es tener claro que las necesidades del negocio son las

que nos guiaran a lo largo de todo el proyecto”. En general se contempla que el

ciclo de vida dimensional del negocio se puede expresar en términos de lo que se

muestra en la siguiente ilustración:

 Ilustración 2: Ciclo de vida de la Metodología Ralph Kimball

Fuente: DataMart Paso a Paso

La metodología cuenta con 11 fases:

i. Planificación del Proyecto

El primer paso es la planeación del proyecto, esto como una buena práctica

usada en prácticamente la mayoría de los proyectos de TI. Esta planeación

contempla los siguientes puntos:

 Evaluación de preparación

 Tener un patrocinador exigente que tenga visión y pasión

por el negocio.

 Tener una fuerte motivación y compromiso con el negocio

para la construcción de su Data Warehouse.

 Identificar si los datos que contienen las operaciones del

negocio realmente cubren los requerimientos del negocio.

 Se debe trabajar con datos limpios y al nivel correcto de

granularidad.

 Relación TI-Negocio.

 Cultura analítica de la compañía.

 Definición del alcance. Se establecen los límites que existirán

alrededor del proyecto. Este alcance es definido en conjunto por TI

y el negocio.

 Justificación. Principalmente es la estimación de los costos y los

beneficios.

ii. Definición de requerimientos del negocio

Para obtener los requerimientos del negocio debemos planear el cómo

obtendremos dichos requerimientos. Existen 2 técnicas principales para la

recolección de requerimientos:

 Las entrevistas

 Las sesiones facilitadoras

Estas se deben realizar principalmente con 3 roles del negocio:

 Representantes del negocio

 Expertos en los sistemas fuente

 Los expertos en la materia

Con la finalidad de obtener información de que es lo que hacen, como lo

hacen y porque lo hacen, y poder relacionar estas respuestas con los datos.
iii. Diseño de la arquitectura técnica

En esta fase se definen los planos que nos permitirán contar con un diseño

integral que tome en cuenta los aspectos técnicos y elementos del Data

Warehouse. Estos elementos son representados por medio de modelos que van

en diferentes niveles de detalle mostrando los requerimientos inmediatos. Este

diseño sigue 8 pasos:

1. Establecer la fuerza de arquitectura: Es conveniente definir a 3 personas en

el diseño de la arquitectura, estas tres personas son: arquitecto técnico,

diseñador del área de desarrollo y desarrollador de aplicaciones.

2. Se colectan los requerimientos del negocio: esto se hace de acuerdo con

las necesidades críticas del negocio, como pueden ser, tiempos,

disponibilidad, performance, etc.

3. Documentación de los requerimientos de arquitectura: se deberán

documentar los hallazgos obtenidos a partir de las entrevistas, enfocado en

los aspectos que pudieran impactar en la arquitectura.

4. Desarrollo del modelo de arquitectura de alto nivel: se clasifican los

requerimientos de acuerdo con los Datos de la organización, accesos de

datos, metadata e infraestructura.

5. Diseño y especificación de los subsistemas: se lleva a mayor cada uno de

los grupos incluidos en el modelo de alto nivel, mostrando las capacidades

y requerimientos específicos de cada sección.

6. Determinar las fases de implementación de la arquitectura: se deben

establecer prioridades para la implementación de las definiciones hechas

 de acuerdo con los requerimientos del negocio.

7. Documentación técnica de la arquitectura: este documento debe contener

la información necesaria para que se lleve a cabo la implementación del

Data Warehouse.

8. Revisión y finalización de la arquitectura técnica: debe ser distribuido por

los miembros de TI y el negocio con la finalizad de que sea

retroalimentado este plan y quede completo para su validación.

iv. Selección de productos e implementación

De acuerdo con lo establecido en la planeación de la arquitectura, se busca por

un producto que encaje con lo mencionado en dicho plan. Para hacer una

buena selección se pueden realizar las siguientes actividades:

 Realizar una matriz de evaluación.

 Hacer una búsqueda en el mercado.

 Reducir opciones al mínimo para realizar evaluaciones detalladas.

 Requerir prototipos.

 Seleccionar productos, instalar prueba y negociar.

v. Modelo dimensional

En el modelado dimensional identificamos las dimensiones que darán

información de carácter cualitativo y los hechos que ofrecen información

cuantitativa sobre el negocio. Para llegar a este modelado se realiza lo

siguiente:
  Se hace una lista de las posibles dimensiones con sus

intersecciones.

 Se identifican los procesos de negocio.

 Se evalúa la granularidad, la consistencia, valores válidos y la

disponibilidad de los atributos.

 Se crea el esquema dimensional.

 Se valida el esquema dimensional.

 Se documenta el modelo.

vi. Diseño físico

El modelado dimensional es traducido a un modelo físico, es muy probable

que el modelado dimensional no se respete del todo puesto que en modelo

físico se deben tomar en cuenta ciertas estrategias que pueden hacer que la

implementación del modelado dimensional en el modelo físico no sea tan

transparente, esto debido a temas de agregación, índices, etc.

vii. Diseño y desarrollo del ETL

Esta parte implica el diseño y desarrollo del proceso de ETL. Para este

proceso primero se deben trabajar las dimensiones. Este proceso se divide en 2

secciones: las dimensiones y los hechos.

viii. Especificación de aplicaciones de BI

De acuerdo con todo lo desarrollado hasta este punto, es necesario generar las

vistas que los usuarios accederán, mediante herramientas de reporteo. Se hace

toda la definición del FRONT-END.

 ix. Desarrollo de la aplicación de BI

El desarrollo de las actividades analíticas definidas se lleva a cabo bajo ciertos

estándares.

x. Implementación

Se lleva todo el desarrollo del Data Warehouse al día a día de las operaciones

para lo cual se requiere educar a los usuarios y ofrecer cierto tiempo de

soporte por cualquier contingencia que pueda ocurrir.

xi. Mantenimiento y crecimiento

Para el mantenimiento se realizan tareas de soporte, soporte técnico,

educación, todo siguiendo un programa de soporte. A demás de que se puede

crecer el proyecto cuando exista la necesidad de hacerlo.

2.2.4. Metodología Bill Inmon

Bill Inmon es una metodología descendente Top-Down (hacia abajo) donde los

data marts se crearán después de haber terminado el Data Warehouse completo de

la organización.

 El desarrollo de un Data Warehouse empresarial se basa en un esquema de

base de datos normalizado. El desarrollo de los Data Marts, se basan en

datos obtenidos del Data Warehouse.

 Un Data Mart mantiene los datos agregados que se relacionan a la unidad

de negocio.

 Un Data Mart se construye mediante la extracción de datos de la data

Warehouse de la empresa. Los data marts no están vinculados entre sí.

 Un Data Mart mantiene una historia limitada, ya que esta se mantiene en el

 data Warehouse de la empresa.

 El diseño de un Data Warehouse para toda la empresa se basa en su

modelo de datos.

Ilustración 3: Ciclo de vida de la metodología Bill Inmon

Fuente: DataMart Paso a Paso

2.2.5. Herramienta de desarrollo

i. Motor de Base de Datos

El motor de base de datos es el servicio principal para almacenar, procesar y

proteger los datos. El motor de base de datos proporciona acceso controlado

y procesamiento de transacciones rápido para cumplir con los requisitos de

las aplicaciones consumidoras de datos más exigentes de la organización.

a. SQL Server 2017

Microsoft SQL Server, es un software que permite el modelamiento de la

relación de la base de datos. Transact-SQL (TSQL) es el lenguaje que se

utiliza para el desarrollo en el motor de base de datos, una

 implementación del estándar “ANSI” del lenguaje SQL, el cual se utiliza

para manejar y obtener DAT (DML), crear, modificar y eliminar tablas,

y definir las relaciones entre ellas (DDL).

ii. Herramienta de BI

a. Power BI

Power BI es una solución destinada a la inteligencia empresarial, que

permite unir diferentes fuentes de datos, modelizar y analizar datos para

después, presentarlos a través de paneles e informes; que puedan ser

consultados de una manera muy fácil, atractiva e intuitiva. Esta

explotación de datos, a través de paneles e informes, permiten además

que puedan ser compartidos por muchos usuarios de una misma empresa

u organización.

b. Tableau Public

Es una herramienta de visualizaciones interactivas de datos, como

objetivo principal poder analizar las bases de datos a través de diferentes

sistemas de representación visual que facilitan el análisis de dichos

datos.

2.3. Terminología

2.3.1. Data Warehouse

“Un Data Warehouse es una copia de los datos transaccionales

 especialmente estructurado para la consulta y el análisis”

(Ralph Kimball, 1992)

2.3.2. Data Mart

“Es un conjunto de datos que son estructurados de una forma que facilite su

posterior análisis. Contiene la información referente a un área, un tema o una

función en particular, con datos relevantes que provienen de las diferentes

aplicaciones operacionales”

(Cabanillas, 2011)

2.3.3. Base de datos STAGE

El uso de una base de datos STAGE no es obligatoria. Sin embargo, es de

bastante ayuda e incluso puede ser una buena práctica para algunos escenarios

donde se necesite.

Algunos escenarios donde se necesite evaluar su uso, es cuando:

 No se dispone a los sistemas fuentes para programar cargas secuenciales o

conocer sus rutinas de registro.

 Se tiene una gran cantidad de fuentes de datos heterogéneas.

 Existe complejidad en conocer el diccionario de datos de los sistemas

fuentes.

 Se desea cargar historia que proviene de diferentes fuentes con diferentes

diccionarios de datos.

 Se tiene que realizar muchas transformaciones previas antes de pasar a un

modelo multidimensional.
2.3.4. OLTP (On Line Transaction Processing)

Representa toda aquella data transaccional que genera una empresa en su

accionar diario, además de las fuentes externas con las que puede llegar a

disponer. Estos sistemas transaccionales pueden ser ERP, CRM, archivos de texto,

hojas de cálculo, etc.

2.3.5. OLAP (On Line Analyzing Processing)

Se basa en populares cubos OLAP, que se construyen agregando, según

los requisitos de cada área o departamento, las dimensiones y los indicadores

necesarios de cada cubo relacional. El modo de creación, explotación y

mantenimiento de los cubos OLAP es muy heterogéneo, en función de la

herramienta final que se utilice.

2.3.6. Proceso ETL

El termino ETL proviene de las siglas Extract-Transform-Load que

significan Extraer, Transformar y Cargar. Es el proceso que permite mover los

datos transaccionales de una organización extraídos desde diversas fuentes,

reorganizarlos y limpiarlos, y cargarlos hacia otra fuente de datos (base de datos,

datamart, data warehouse) para su análisis.

 Extracción: En esta etapa del proceso se extraen los datos desde los

sistemas de origen.

 Transformación: Realiza el proceso de conversión y limpieza de los datos

extraídos en datos congruentes, con el fin de mantener un formato

estándar.

 Carga: En esta última etapa, se cargan los datos transformados en el

 proceso anterior al sistema destino.

2.3.7. Modelo Multidimensional

Genera una base de datos con una facilidad en su navegabilidad. Existe

una reducción en la cantidad de tablas y relaciones. Modela a detalle los procesos

que suceden en una organización, separándolos en mediciones y entornos.

Las métricas son en su mayoría numéricas y se les denomina hechos. Mientras el

entorno se puede ver como un todo, existen registros lógicos de diversas

particularidades que logran describir un hecho.

 Tabla Hechos

Representa los procesos de una Organización, son independientes uno de

otro. Facilita la generación de respuesta rápida a partir de registros

comprimidos. La llave de esa tabla hechos está compuesta por las llaves

primarias de las tablas dimensiones.

 Tabla Dimensión

Esta tabla contiene generalmente una llave simple y atributos que

describen a la dimensión.

 Tabla Tiempo

Cada hecho registrado en la tabla hechos lleva consigo una marca de

tiempo, es decir se evidencia el momento en el que ocurrió el hecho.

Permitiendo el almacenamiento y análisis de la información.

 Esquemas para el desarrollo de modelos multidimensionales:

 Esquema Estrella

Cuenta con un solo objeto en el centro que viene a ser la tabla de hecho

conectada con otros objetos que vienen a ser la tabla dimensiones. En este

caso, solo las tablas dimensiones se van a relacionar con la tabla hechos,

no existirá relación alguna entre las tablas dimensiones.

Ilustración 4: Esquema Estrella

Fuente: Datawarehouse manager

 Esquema Copo de Nieve

Es una extensión del esquema estrella en donde cada una de las puntas de
 la estrella se puede dividir en más puntas. En esta forma de esquema, las

tablas dimensiones si pueden relacionarse con otras.

Ilustración 5: Esquema Copo de Nieve

Fuente: Datawarehouse manager

Capitulo III: Metodología

3.1. Materiales

Para el desarrollo e implementación del proyecto, se utilizará el Hardware, Software y

Personal mencionados a continuación:

3.1.1. Recurso Humano

Como parte de proyecto se necesita personal que cuenten con ciertos roles para

cumplir con los objetivos.

 Recurso Humano

Rol Cantidad

Jefe de Proyecto 1

Especialista de Inteligencia de Negocio 1

Analista/Programador 1

Actividades por emplear de los roles requeridos para el proyecto:

 Jefe de Proyecto

 Colaboración con el cliente en la definición y consecución de objetivos.

 Planificación del proyecto en todos sus aspectos.

 Dirección y coordinación de los recursos empleados en todas las fases.

 Mantenimiento de relaciones con los agentes externos.

 Toma de decisiones de manera situacional.

 Identificación de fallos y adopción de soluciones pertinentes.

 Especialidad de Inteligencia de Negocio

 Identificar las necesidades del cliente, y brindar soluciones que generen

valor a la organización.

 Gestionar el flujo oportuno de información de inteligencia empresarial a

los usuarios.
  Proporcionar soporte técnico para la creación de informes, cuadros de

mando u otras herramientas existentes.

 Crear herramientas o sistemas de inteligencia de negocios, incluyendo

diseño de bases de datos, hojas de cálculo o salidas relacionadas.

 Mantener o actualizar las herramientas de inteligencia de negocios, bases

de datos, cuadros de mando, sistemas o métodos.

 Analista/Programador

 El analista programador debe analizar, desarrollar los requerimientos

mediante el uso de las tecnologías de información, para satisfaces las

necesidades de sus clientes.

 Debe ser capaz de realizar mantenimiento de los sistemas ya existentes y

de las actualizaciones de estos.

 Diseñar cada funcionalidad en base a los tipos de reportes e indicadores.

 Es el encargado de hacer las pruebas de los programas que ha desarrollado

para que estas funcionen debidamente.

 Asiste, capacita a quienes van a usar los sistemas desarrollados.

3.1.2. Recurso Tecnológico

Para el presente proyecto, se emplearán los siguientes recursos, el cual serán

necesarios desde el inicio del proyecto hasta el final.

Recurso Tecnológico

Tipo Nombre Descripción Cantidad

Hardware Laptop Inter Core i7

16 GB de RAM

1 TB de DD 2

15.6 Pulgadas

Software SQL Server 2017 Gestor de Base de Datos 2

Power BI Herramienta de Inteligencia de Negocios 2

Windows 10 Sistema Operativo 2

Microsoft Office Paquete de herramientas de ofimática 2

Descripción del Software que se va a utilizar en el proyecto:

 SQL Server 2017

Microsoft SQL Server, es un software que permite el modelamiento de la

relación de la base de datos. Transact-SQL (TSQL) es el lenguaje que se

utiliza para el desarrollo en el motor de base de datos, una implementación

del estándar “ANSI” del lenguaje SQL, el cual se utiliza para manejar y

obtener data, crear, modificar y eliminar tablas, y definir las relaciones entre

ellas.

 Power BI

Power BI es una solución destinada a la inteligencia empresarial, que permite

unir diferentes fuentes de datos, modelizar y analizar datos para después

presentarlos a través de paneles e informes, que pueden ser consultados de

una manera muy fácil, atractiva e intuitiva. Esta explotación de datos, a

 través de paneles e informes, permiten además que puedan ser compartidos

por muchos usuarios de una misma empresa u organización.

3.2. Método

Para el desarrollo del presente trabajo considerando el tiempo de desarrollo y la magnitud del

proyecto se llega a la conclusión que se debe de trabajar bajo el marco de trabajo SCRUM,

siendo esta una metodología ágil que más se adapta al tipo de proyecto a desarrollar, presentando

los pequeños ciclos de trabajo como sprints.

3.2.1 ¿Qué es Scrum?

Podemos definir Scrum como un “Proceso en el que se aplican de manera regular un conjunto de

buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible

de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio

de la manera de trabajar de equipos altamente productivos.” (Proyectos Agiles, s.f.)

Según Mike Cohen (2013):

 Scrum es un proceso ágil que nos permite centrarnos en ofrecer el más alto valor de

negocio en el menor tiempo.

 Nos permite rápidamente y en repetidas ocasiones inspeccionar software real de

trabajo (cada dos semanas o un mes).

 El negocio fija las prioridades. Los equipos se auto-organizan a fin de determinar la

mejor manera de entregar las funcionalidades de más alta prioridad.

  Cada dos semanas o un mes, cualquiera puede ver el software real funcionando y

decidir si liberarlo o seguir mejorándolo en otro sprint.

Con Scrum, los proyectos software avanzan a través de una serie de iteraciones la cuales son

llamadas "Sprints". Cada "Sprint" tiene una duración de 2-4 semanas y este sprint genera un

entregable de valor al cliente.

Roles:

 Propietario del Producto (Product Owner):

El propietario del producto es el encargado de recopilar y organizar los requisitos del cliente y

justificar el negocio del proyecto, además de maximizar el valor del negocio para el proyecto,

básicamente el propietario del producto simboliza la voz del cliente.

 Scrum Master:

El Scrum Master cumple el rol de facilitador del equipo Scrum, se encarga de que el equipo

cuente con los recursos necesarios para que el producto se desarrolle exitosamente.

El Scrum Master guía al equipo e imparte practicas Scrum a los participantes del proyecto,

elimina stopper en el desarrollo del proyecto y asegura que el proceso Scrum se trabaje

correctamente.

 Equipo Scrum (Scrum Team):

El Equipo Scrum es un grupo de personas que se encargan de entender e interpretar las

necesidades que especifica el Product Owner, también están encargados de estimar historias de

usuario y de desarrollar los entregables del proyecto.

Principios del SCRUM:

 Colaboración estrecha con el cliente.

 Delegación de atribuciones al equipo para que pueda auto organizarse y tomar las

decisiones sobre el desarrollo.

 Predisposición y respuesta al cambio.

 Prefiere el conocimiento tácito de las personas al explícito de los procesos.

 Desarrollo incremental con entregas funcionales frecuentes.

 Comunicación verbal directa entre los implicados en el proyecto.

 Motivación y responsabilidad de los equipos por la autogestión, auto-organización y

compromiso.

 Simplicidad. Supresión de artefactos innecesarios en la gestión del proyecto.

3.2.2 Etapas de scrum

Scrum está basada en 5 etapas, las cuales son:

1. Reunión de Planificación de Sprint.

En esta etapa es en la que se prevé el trabajo que se va a realizar, el plan de trabajo se desarrolla

con todos los integrantes del equipo scrum.

En esta reunión es donde se define la funcionalidad en el incremento que se planea, también

podemos ver como el equipo de desarrollo logrará dicho incremento y como salida de ese trabajo

se tiene el objetivo del sprint.

En esta etapa es muy importante hacerse las siguientes preguntas:

¿Qué va a ser entregado en el incremento resultante del próximo Sprint?

¿Cómo se va a realizar el trabajo seleccionado?

2. Scrum Diario.

Estas son reuniones de 15 minutos, en donde el equipo de desarrollo puede sincronizarse,

presentar dudas, dificultades, avances realizados hasta el momento y así puedan avanzar sin

complicaciones, en esta etapa también se crea el plan para las siguientes 24 horas, con las tareas

que el equipo tiene que realizar.

El Scrum Diario es muy beneficioso, ya que esta mejora las comunicaciones entre el equipo,

eliminan posteriores reuniones, eliminan obstáculos, identifican riesgos, se destaca y promueve

muy rápido la toma de decisiones y mejora el conocimiento global del avance del proyecto por

todas las partes del equipo. Esta reunión es muy importante para la inspección y posterior

adaptación.

En esta reunión se busca que cada miembro del equipo explique:

 Lo que logró las últimas 24 horas.

 Lo que se hará las siguiente 24 horas.

 Si tiene algún problema, explicar sus necesidades.

El equipo es el responsable de esta reunión, no el Scrum Master; y esta reunión no se trata de una

reunión de control o inspección, sino de una reunión informativa y comunicativa entre el equipo

para que así todas las partes estén alineadas y puedan compartir el estado del trabajo, chequear el

ritmo y colaborar en posibles dificultades o impedimentos hallados.

 3. Trabajo de desarrollo durante Sprint.

Una vez el Sprint esté en curso, se debe de asegurar:

 No realizar cambios que tengan como consecuencia afectar el objetivo del sprint.

 No disminuir los objetivos de calidad.

 El alcance se podrá renegociar entre los propietarios del producto y el equipo de

desarrollo, a medida que se vaya aprendiendo.

Cuando un sprint es demasiado largo, este puede sufrir cambios, aumentar la complejidad del

trabajo y aumentar riesgos.

4. Revisión de Sprint

Esta se lleva cada vez finaliza un sprint con el fin de inspeccionar el incremento y realizar

adaptaciones al producto backlog si fuera necesario.

En esta etapa interactúa el equipo Scrum y las partes interesadas para ver los avances realizados

durante el Sprint.

Esta revisión tiene como resultado un Product Backlog revisado que define ítems de mayor valor

o probables para el siguiente sprint. El Product Backlog también está abierto a ajustes para así

más adelante satisfacer nuevas necesidades.

5. Retrospectiva del sprint.

Esta etapa es en la que el equipo scrum se inspecciona e identifica puntos de mejora para poder

ejecutar en el siguiente sprint, esta etapa tiene como propósito:

 Revisar como estuvo el equipo desempeñándose en el sprint.

 Identificar temas que salieron bien, ordenarlos y potenciar mejoras.

  Crear plan para la implementación de mejoras con respecto a como el equipo scrum se

desenvuelve en el trabajo.

Adicionalmente a las 5 etapas del Scrum durante el proyecto, una vez finalizado este, también se

realiza una “Retrospectiva del Proyecto”.

6. Retrospectiva del proyecto.

Consta de 3 etapas las cuales son: Entradas, Herramientas y Salidas, como se muestra en la

Ilustración 3.

Figura 1: Retrospectiva del proyecto

Fuente: (Study, 2016)

Herramientas:

Reunión de retrospectiva del Sprint.

En esta reunión, se determina como las formas necesarias en las que la colaboración y

la eficacia del equipo pueda realizar mejor futuros proyectos.

Se analizan oportunidades positivas y negativas para así poder mejorar. Esta reunión

no tiene un tiempo definido como el Scrum Diario pudiendo realizarse de forma

 presencial o virtual de acuerdo a las necesidades presentadas, y los asistentes a estas

reuniones son: el equipo Scrum, Scrum Master, Product Owner.

Ventajas:

 Obtención de Software con requerimientos exigidos de forma rápida.

 Trabajo con iteraciones rápidas y de corto plazo.

 Gran adaptación al cambio. Ventaja competitiva.

 Creatividad y efectividad del equipo auto administrado y entorno libre de interrupciones.

 Reuniones dedicadas a problemas recientes. Evita estancamiento.

 Ideal para proyectos con requisitos volátiles o no muy claros.

3.3. Plan de Trabajo

Se desarrolló el plan de trabajo haciendo uso de la herramienta MS Project, donde se

especificaron las tareas por cada etapa, en base a la metodología elegida.

Se considera fecha de inicio el día viernes 01/08/2018 y como fecha de fin el día martes

23/11/2018.