UNIVERSIDAD DE LAS AMÉRICASFACULTAD DE INGENIERÍA Y NEGOCIOS
SISTEMA WEB DE GESTIÓN Y CONTROL DE LA INFORMACIÓN COMERCIAL DE SCHOPDOG (CRONOS WEB).
ADRIÁN NICOLÁS VILCHES URRAJORGE ANDRÉS ORELLANA UGARTE
2013
UNIVERSIDAD DE LAS AMÉRICASFACULTAD DE INGENIERÍA Y NEGOCIOS
SISTEMA WEB DE GESTIÓN Y CONTROL DE LA INFORMACIÓN COMERCIAL DE SCHOPDOG (CRONOS WEB).
Trabajo de titulación presentado en conformidad a los requisitos Para obtener el título de Ingeniero de Ejecución en Informática.
Profesor guía: Sra. Consuelo Castillo
ADRIÁN NICOLÁS VILCHES URRAJORGE ANDRÉS ORELLANA UGARTE
2013
AGRADECIMIENTOS
Nos gustaría que estas líneas sirvieran para expresar nuestras más profundas y sinceros agradecimientos a
todas aquellas personas que con su ayuda han colaborado en la realización del presente trabajo, en
especial a la profesora Consuelo Castillo, por la orientación, el seguimiento y la supervisión continúa de
este proyecto, pero sobre todo por la motivación y el apoyo recibido a lo largo del proyecto.
Quisiéramos hacer extensiva nuestra gratitud a nuestros compañeros del Ingeniería por brindarnos fuerza y apoyo. También queremos dar las gracias a Braulio
Gutiérrez, Jefe de sistema de la Compañía Rap S.A y a Claudio Escalona, Jefe de Control y Gestión de Rap S.A
por su colaboración en el suministro de los datos e información necesaria para la realización de la parte
empírica de este proyecto.
Un agradecimiento muy especial merece la comprensión, paciencia y el ánimo Recibidos de nuestras familias y
amigos.
A todos ellos, muchas gracias.
DEDICATORIA
Dedico este trabajo principalmente a Dios, por regalarme la vida y las cosas que creo que no me merezco…, por
permitirme llegar hasta este momento tan importante de mi formación profesional.
A mis padres, quienes a lo largo de mi vida han velado por mi bienestar y educación siendo mi apoyo en todo
momento, también a mis hermanos por ser parte importante en mi existencia y brindándome su apoyo
siempre.
Gracias a esas personas importantes en mi vida, que siempre estuvieron para brindarme todo su apoyo,
ahora regreso una pequeña parte de todo lo inmenso que me han entregado.
A mi compañero.Jorge Orellana, por brindarme su respeto y amistad,
Estar ahí en las dificultades y alegrías, durante todo este proceso de universidad, superando obstáculos para
alcanzar un objetivo en común.
A una gran persona que conocí en los últimos semestres de mi carrera, y que aún así me deslumbra con su gran
amor y apoyo incondicional...Fabiola ReinosoTe amo.
Y en especial a mi abuela Analía Castillo, Tomado de su mano emprendí mi aprendizaje de esta vida…te doy las
gracias por tu amor y estar siempre a mi lado cuando
más te necesito, sentir tus manos, tu cariño y tu amor aun desde los cielos…
Adrian Vilches Urra.
DEDICATORIA
El presente trabajo va dedicado principalmente a mis padres Marta Ugarte Ormazábal y Jorge Orellana Santis quienes a lo largo de toda mi vida me han brindado su
apoyo, educación y el amor que un hijo pueda tener.
A mi hermana Romina Orellana que también ha sido un apoyo fundamental en mi crecimiento y educación.
Gracias a esas personas importantes en mi vida que también me ayudaron en todo momento brindándome una palabra de aliento en los momentos difíciles de la
vida
A mis compañeros, amigos y hermanos de universidad Nicolás Vilches y Fabiola Reinoso por brindarme todo su
respeto y amistad, por entregarme su apoyo en los momentos difíciles que pase durante este proceso.
Gracias a mi familia que en todo momento me brindó su cariño y apoyo durante mi carrera y también quiero dar
gracias a una persona que fue muy importante para mí y que me dejó justo en el momento más difícil de mi
carrera y de mi vida, para ti va dedicado este trabajo,
para que veas que en la vida se pueden hacer muchas cosas a la vez sin dejar de lado nada.
Jorge Orellana Ugarte.
RESUMEN
El presente trabajo de titulación tiene por objetivo consolidar el desarrollo de un proyecto de
ingeniería, aplicando los conocimientos adquiridos durante los cuatro años de estudio en la
carrera de Ingeniería de Ejecución en Informática en la Universidad de las Américas,
identificando, analizando y resolviendo el problema de extracción y manipulación de la
información, que existe en el área de gestión de la oficina central de la cadena de restaurant
“Schopdog”, debido a que actualmente la compañía cuanta con un software llamado RESTÓ ,
que es un sistema cerrado, que no cubre todas las necesidades y exigencias de la compañía,
cuenta con diferentes módulos para administrar la información, pero carece de un módulo de
gestión que permita generar reportes de información que apoye una efectiva toma de
decisiones de la compañía.
En este contexto, se describe y sintetiza la forma en la cual se llevó a cabo el desarrollo del
proyecto de software. Este se realizó considerando su objetivo principal de desarrollar e
implementar una plataforma web que integre al sistema actual de la compañía anteriormente
mencionada. Realizando la consolidación de la información referente a las ventas gestionadas
por esta plataforma, mediante el despliegue de indicadores. Para ello fue necesario analizar
cada uno de los procesos que implica el desarrollo de un sistema informático, partiendo del
análisis de factibilidades, continuando con los requerimientos, el diseño, el desarrollo y
finalizando con la implementación. Se espera que el sistema facilite la gestión, el seguimiento
y control de la información de todos los locales a lo largo del país, mediante la plataforma
web, logrando alcanzar las metas estratégicas de negocio de la empresa.
En este proyecto se presentarán las etapas fundamentales que explican la aplicación de cada
etapa del prototipo, inicialmente se analizará la situación actual de la compañía describiendo la
problemática y la carencia de un modulo de gestión presente en el sistema actual de la
compañía. Con lo anterior se presenta y se describe una solución a la problemática, luego de
eso se lleva a cabo las diferente etapas que componen el desarrollo y la integración del
prototipo del proyecto, abarcando análisis, objetivos fijados por el cliente, riesgos existentes,
metodología a implementar, la construcción de un nuevo modelo de datos basado en consultas
históricas de sistema actual, y por ultimo culminando en un diseño amigable al cliente.
SUMMARY
The present work aims titration consolidate the development of an engineering project,
applying the knowledge acquired during the four years of study at the Engineering Computer
Run at University of the Americas, identifying, analyzing and solving the problem extraction
and manipulation of information that exists in the area of office management chain restaurant
"Schopdog", because at present the company whatever with a software called RESÓ, which is
a closed system that does not cover all the needs and requirements of the company, has
different modules for managing information, but lacks a management module that can
generate reports information to support effective decision -making of the company.
In this context, describes and summarizes the way in which they carried out the software
development project. This was done considering its main objective to develop and implement
a web platform that integrates the company's current system mentioned above. Performing the
consolidation of information concerning sales managed by this platform, through the
deployment of indicators. It was necessary to analyze each of the processes involved in the
development of a computer system, from the analysis of feasibility, continuing with the
requirements, design, development and ending with implementation.lllllllllllllllllllllllllllllllllll
System is expected to facilitate the management, monitoring and control of all local
information throughout the country, via the web platform, achieving strategic business goals
of the company. L…………………………………………………………………………llllll
In this project we present the main steps that explain the creation of each prototype stage,
initially analyze the current situation of the company describing the problem and the lack of a
management module present in the current system of the company. With the above is
presented and describes a solution to the problem , after that is done the different stages that
comprise the development and integration of the prototype of the project, covering analysis,
customer objectives, risks, methodology implement the construction of a new data model
based on historical queries current system, and finally culminating in a customer friendly
design .
Tabla de contenidoCAPÍTULO 1 ANÁLISIS E INICIO DEL PROYECTO..................................................................14
1.1 Descripción de la empresa...............................................................................................141.2 Análisis de la Situación Actual........................................................................................151.3 Descripción del Problema a Resolver..............................................................................211.4 Propuesta Solución al Problema....................................................................................23
1.4.1 Desarrollo externo AXOFT......................................................................................251.4.2 Desarrollo Interno.....................................................................................................26
1.5 Objetivos..........................................................................................................................281.5.1 Objetivo General.......................................................................................................281.5.2 Objetivos Específicos...............................................................................................28
1.6 Alcances y Limitaciones del Proyecto.............................................................................291.6.1 Los Alcances.............................................................................................................291.6.2 Limitaciones.............................................................................................................29
1.7 Justificación.....................................................................................................................301.8 Área a impactar................................................................................................................311.9 Requerimientos y Restricciones......................................................................................32
1.9.1 Levantamiento de Requerimientos Funcionales.......................................................321.9.2 Levantamiento de requerimientos no funcionales....................................................381.9.3 Levantamiento de Restricciones...............................................................................40
1.10 Planificación..................................................................................................................41CAPÍTULO 2 ESTADO DEL ARTE..................................................................................................42
2.1 Software Similares...........................................................................................................422.2 Tecnología.......................................................................................................................45
2.2.1 ReportViewer............................................................................................................452.2.2 Microsoft Chart.........................................................................................................462.2.3 Comparación y elección...........................................................................................47
CAPÍTULO 3 HERRAMIENTAS Y METODOLOGÍAS................................................................48
3.1 Arquitectura de solución..................................................................................................483.2 Entorno Tecnológico.......................................................................................................50
3.2.1 Herramientas.............................................................................................................503.2.2 Hardware de desarrollo e implementación...............................................................543.2.3 Justificación de Herramientas...................................................................................54
3.3 Metodologías...................................................................................................................553.3.1 Análisis comparativo de las metodologías...............................................................553.3.2 Cascada.....................................................................................................................563.3.3 Espiral.......................................................................................................................583.3.4 Incremental...............................................................................................................60
CAPÍTULO 4 APLICACIÓN DE LA METODOLOGÍA.................................................................63
4.1 Selección de la metodología............................................................................................634.2 Aplicación de la metodología..........................................................................................66
4.2.1 Primera Iteración: Construcción Modelo de Datos.................................................684.2.2 Segunda Iteración: Desarrollo de informes e Indicadores........................................724.2.3 Tercera iteración: Creación y administración de Mantenedores..............................87
4.3 Arquitectura del Diseño...................................................................................................97
4.3.1 Arquitectura..............................................................................................................97CAPÍTULO 5 PROTOTIPO DE INTERFACES GRÁFICAS Y ANÁLISIS DE FACTIBILIDAD...............................................................................................................................................................100
5.1 Prototipo de Interfaz......................................................................................................1005.2 Análisis de Factibilidad.................................................................................................103
5.2.1 Técnica....................................................................................................................1035.2.2 Operacional.............................................................................................................1045.2.3 Legal.......................................................................................................................1045.2.4 Económica..............................................................................................................105
5.3 Matriz de riesgo del proyecto........................................................................................1075.4 Análisis FODA..............................................................................................................1085.5 Evaluación y Elección de las Alternativas de Solución.................................................1095.6 Beneficios esperados del proyecto.................................................................................110
5.6.1 Cualitativos.............................................................................................................1105.6.2 Cuantitativos...........................................................................................................110
CAPÍTULO 6 CONCLUSIONES......................................................................................................111
ANEXO I..............................................................................................................................................112
ANEXO II.............................................................................................................................................117
ANEXO III...........................................................................................................................................122
Índice de FigurasFigura 1.1: Caso de Uso - Proceso de Negocio – Ventas..........................................................15Figura 1.2: Registro de Ventas Actual.......................................................................................17Figura 1.3: Caso de Uso – Generación de Reportes Actual......................................................18Figura 1.4: Proceso Generación Reportes Actual......................................................................20Figura 1.5: Problemática a Resolver..........................................................................................22Figura 1.6: Diagrama de obtención actual de la información....................................................22Figura 1.7: Diagrama de solución al problema de consolidación, en un ambiente web............23Figura 1.8: Área a impactar.......................................................................................................31Figura 2.1: Vista del Sistema actual de la compañía.................................................................43Figura 3.1: Núcleo del entorno de desarrollo............................................................................55Figura 3.2: Modelo de ciclo de vida en cascada........................................................................56Figura 3.3: Modelo de ciclo de vida en espiral..........................................................................58Figura 3.4: Modelo de ciclo de vida incremental......................................................................60Figura 4. 1: Procesos de la metodología Evolutiva - Incremental.............................................64Figura 4. 2: Modelo E-R: Acceso a plataforma CRONOS Web...............................................69Figura 4. 3: Modelo E-R: Principales Tablas CRONOS Web...................................................70Figura 4. 4: Comprobación de datos..........................................................................................71Figura 4. 5: Caso de Uso - Listados de locales y ventas............................................................74Figura 4. 6: Flujo - Listados de Locales y Ventas.....................................................................76Figura 4. 7: Caso de Uso - Indicadores: Reportes tipo gráfico y tabla......................................77Figura 4. 8: Flujo - Indicadores: Reportes tipo gráfico y tabla..................................................79Figura 4. 9: Caso de Uso - Dashboard.......................................................................................80Figura 4. 10: Flujo - Dashboard.................................................................................................82Figura 4. 11: Informe compañía................................................................................................83Figura 4. 12: Scripts Sistema Actual.........................................................................................84Figura 4. 14: Scripts Sistema Propio.........................................................................................85Figura 4. 13: Scripts Sistema Actual.........................................................................................85Figura 4. 15: Scripts Sistema Propio.........................................................................................86Figura 4. 16: Caso de Uso - Administración MultiEmpresa.....................................................89Figura 4. 17: Flujo Administración MultiEmpresa....................................................................91Figura 4. 18: Caso de Uso – Administración MultiUsuario y MonoUsuario............................92Figura 4. 19: Flujo – Administración MultiUsuario y MonoUsuario........................................94Figura 4. 20: Actualización de la Información..........................................................................95Figura 4. 21: Arquitectura Cliente/Servidor..............................................................................97Figura 4. 22: Capas de la Plataforma.........................................................................................98Figura 5. 1: Vista-Listado de Locales......................................................................................100Figura 5. 3: Vista-Reporte de Ventas Tipo Gráfico.................................................................101Figura 5. 2: Vista-Reporte de Ventas Tipo Tabla....................................................................101Figura 5. 5: Vista-Reportes de Ventas Acumuladas Tipo Gráfico..........................................102Figura 5. 4: Vista-Reportes de Ventas Acumuladas Tipo Tabla.............................................102
Índice de TablasTabla 1-1: Flujo de Ventas........................................................................................................16Tabla 1-2: Proceso Generación de Reportes Actual..................................................................19Tabla 1-3: Comparación soluciones de desarrollo.....................................................................27Tabla 1-4: Requerimiento – Modelo de Datos..........................................................................32Tabla 1-5: Requerimiento - Roles de usuario............................................................................33Tabla 1-6: Requerimiento - Vistas de roles...............................................................................34Tabla 1-7: Requerimiento -Creación de indicadores.................................................................35Tabla 1-8: Requerimiento - Exportación a Excel......................................................................35Tabla 1-9: Requerimiento - Generación Dashboard..................................................................36Tabla 1-10: Requerimiento - Generación de mantenedores......................................................37Tabla 1-11: Requerimiento - Generación de Listados...............................................................37Tabla 1-12: Requerimiento - Banner personalizado..................................................................38Tabla 1-13: Requerimiento - Formato de la plataforma............................................................38Tabla 1-14: Requerimiento -Respaldo del equipo de servidor..................................................39Tabla 1-15: Requerimiento - Acceso de usuario.......................................................................40Tabla 1-16: Requerimiento - Eliminación de datos...................................................................40Tabla 1-17: Planificación...........................................................................................................41Tabla 2-1: Comparación de software.........................................................................................44Tabla 2-2: Comparación de Controles.......................................................................................47Tabla 3-1: comparación de metodologías..................................................................................62Tabla 4- 1: Flujo - Listado de Ventas........................................................................................75Tabla 4- 2: Indicadores: Reportes tipo gráfico y tabla..............................................................78Tabla 4- 3: Indicadores: Dashboard...........................................................................................81Tabla 4- 4: Flujo Administración MultiEmpresa.......................................................................90Tabla 4- 5: Administración de MultiUsuario y MonoUsuario..................................................93Tabla 5- 1: Recursos de Hardware requeridos.........................................................................103Tabla 5- 2: Recursos de Software requeridos..........................................................................103Tabla 5- 3: Costos de recursos Hardware................................................................................105Tabla 5- 4: Costos de Recursos Software................................................................................106Tabla 5- 5: Costos de Recurso Humano..................................................................................106Tabla 5- 6: Costos de Recursos Humanos...............................................................................107Tabla 5- 7: Especificaciones de las soluciones de desarrollo..................................................109
13
INTRODUCCIÓN
En la actualidad las aplicaciones web, son una gran herramienta para mejorar la comunicación
y entregar información entre los miembros de una empresa. Esta herramienta permite que los
usuarios puedan acceder a un servidor web a través de internet o de una intranet mediante un
navegador. Logrando obtener la información de manera más rápida, clara y precisa, para una
futura toma de decisiones.
Es importante también mencionar que una aplicación o plataforma Web puede contener
elementos que permiten una comunicación activa entre el usuario y la información. Esto hace
que el usuario acceda a los datos de modo interactivo, debido a que la aplicación responderá a
todas sus acciones.
Estas características ha llevado a la compañía RAP S.A. SCHOPDOG a desarrollar un sistema
web, que logre satisfacer la necesidad de gestionar en forma óptima y en tiempo real la
información referente a las ventas de los locales.
Actualmente RAP S.A. SCHOPDOG, cadena de restaurant es administrada y a la vez cliente
del software RESTÓ, así como muchos exponentes en este rubro. RESTÓ es una plataforma
desktop que realiza la centralización de los movimientos comerciales de sus ventas, pero éste
sistema carece de un modulo de gestión de la información. Por tanto no permite mantener la
información unificada en tiempo real e impidiendo la extracción de ésta desde la extranet,
generando una dependencia en el personal dentro de la red de la compañía para poder
compartir y acceder a esta información.
La propuesta de solución aborda el desarrollo e implementación de un prototipo basado en una
plataforma web que consolide y facilite una optimización al tiempo de extracción de la
información desde cualquier punto externo a la red de la compañía, así otorgando
independencia y autonomía para la generación de reportes e indicadores con la información
referente a las transacciones que actualmente se ingresan a la plataforma desktop.
14
CAPÍTULO 1 ANÁLISIS E INICIO DEL PROYECTO
1.1 Descripción de la empresa.
Rap S.A. SCHOPDOG®, es una cadena de un restaurante con estilo y personalidad propios,
sus locales comienza sus operaciones en el año 1987, con una gran idea, formar restaurantes
únicos que unieran tres objetivos: rapidez, precios altamente competitivos y una atención
personalizada de primera línea. Todo bajo un cálido e innovador ambiente retro, que hoy en
día se destaca en cada uno de nuestros locales.
Un crecimiento sostenido ha permitido a SCHOPDOG® en la actualidad, tener más de treinta
y cinco locales en Santiago y Regiones.
Los locales se distinguen por:
Tener Atención a la mesa - Rapidez en el servicio - Una amplia y atractiva oferta de productos
- Un ambiente único con estética y decoración retro - Productos de excelente calidad y a
precios convenientes.
MISIÓN SCHOPDOG®
Cautivar al cliente con un AMBIENTE diferente y ENTRETENIDO, ofreciendo BUENA
COMIDA Y EXCELENTE SERVICIO a un precio atractivo.
VISIÓN SCHOPDOG®
En SCHOPDOG® el objetivo, es buscar el equilibrio entre lo mejor de dos mundos: la
eficiencia de la comida rápida, con la calidad de la comida hecha en casa.
Con la actitud de servicio y disposición para el trabajo en equipo lograremos que cada uno de
los clientes de SCHOPDOG® sienta que su visita es una experiencia excepcional.
15
1.2 Análisis de la Situación Actual
RAP S.A. SCHOPDOG se divide en varias áreas, entre ella se encuentra el área de gestión,
que es la encargada de llevar el control y el manejo de las transacciones e información de
manera de colaborar para mejores resultados económicos de la compañía.
Actualmente la compañía cuenta con un software llamado RESTÓ que tiene por objetivo,
apoyar operativamente el uso de la aplicación en los locales de venta y la central, como se
muestra en la figura 1.1, reforzando los procedimientos internos, que fueron modificados
producto del acomodo de diferentes operaciones desde el antiguo sistema de ventas a la nueva
aplicación RESTÓ.
Figura 1.1: Caso de Uso - Proceso de Negocio – Ventas
uc CASO DE USO: PROCESO DE NEGOCIO ACTUAL - VENTAS
PROCESO DE VENTAS
CLIENTECAJERO
REGISTRAR VENTA
HACER PEDIDO
GENERA BOLETA
GENERAR COMANDA
VENTA MANUAL «extend»
«include»
16
Tabla 1-1: Flujo de Ventas
Nombre Proceso de Ventas
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe el proceso de ventas actual de la compañía
Actores: Cliente, Cajero
Función: Hacer pedido, registrar venta, generar boleta y comanda
Precondiciones: Sin precondición
Flujo Normal: 1. El cliente hará el pedido al cajero2. El cajero toma el pedido y registra la venta en el sistema3. El cajero genera boleta y comanda
Flujo Excepcional: En el caso de no haber sistema, se realiza una venta manual que al final del día se ingresará al sistema.
RESTÓ facilita la implementación y operación de las ventas de los distintos locales,
integrando una interfaz amigable a sus clientes, técnicamente se ha empleado con gran éxito
en diversas empresas tales como:
Sushi House Nuria Bariloche Boost Café París Rincón Brasileiro Entre otros
17
Figura 1.2: Registro de Ventas Actual
Descripción: Inicialmente el cajero ingresa al sistema con su usuario y contraseña, se verifica
si esta correcto y si funciona el sistema de ventas, el cliente hace pedido al cajero, este último
lo ingresa al sistema, este genera la comanda, número de transacción y la boleta de la venta,
entregándosela al cliente.
Así mismo en el momento de generar la comanda, el número de transacción y la boleta
paralelamente es respaldado en la base de datos local ubicada en la sucursal.
En el caso de que el sistema presente fallas y no se puede utilizar, se generara una boleta
manual con el detalle de la venta, para al final del día o cuando se restablezca el sistema,
ingresar y respaldar las transacciones que se hicieron durante el día.
18
Con la plataforma se resuelven las necesidades administrativas, operativas y logísticas del
negocio gastronómico en forma totalmente integrada con el back office, lo que implica que
cada operación que se realiza va a permitir una auditoría y control de procesos.
Actualmente al generar un reporte se efectúan procesos ordenados y no documentados (que
solamente el encargado conoce), ingresando a una herramienta externa que se conecta a la
base de datos de RESTÓ, ya que esté carece de un modulo de gestión, esta herramienta se
ejecuta y muestra la información requerida, ésta se exporta a Excel u otro formato para los
respectivos filtros y ordenamiento de los datos. Estos son comparados manualmente por la
persona encargada que efectúa comprobaciones de la información extraída desde los locales,
(ver figura 1.3).
Figura 1.3: Caso de Uso – Generación de Reportes Actual
.
uc PROCESO DE NEGOCIO ACTUAL: GENERACION DE REPORTES
GENERACION DE REPORTES
ANALISTA
Extraer Información Exportar Excel
Filtar y Oredenar Reporte
Comparar Información
Generar Herramientas
Externas
«extend»
19
Tabla 1-2: Proceso Generación de Reportes Actual
Nombre Proceso de Generación de Reportes
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe el proceso de generación de reportes actual
de la compañía.
Actores: Analista
Función: Generar herramientas externas, extraer información, exportar a Excel, filtrar y ordenar reporte, comparar información
Precondiciones: Sin precondición
Flujo Normal: 1. El actor genera las herramientas externas para la obtención de la información2. el actor extrae la información desde la base de datos3. El actor puede optar a exportar la información a Excel o solo visualiza cuando
hace la consulta4. Si opta por la exportación a Excel, filtra y ordena el reporte5. El actor compara información
Flujo Excepcional: si al generar las herramientas externas no da resultado las obtención de la información se deberá recurrir al departamento de soporte
20
Figura 1.4: Proceso Generación Reportes Actual
Descripción: El proceso de generación de reportes inicia con la manipulación de las
herramientas externas al sistema actual, solicitando el rango de fecha y hora de la cual se
requiere la información, este proceso conlleva a mucho tiempo de espera para la obtención de
la información requerida. Luego de esto se copia a una planilla Excel, esta es filtrada,
ordenada y modificada para así comprobar y comparar dicha información. Este proceso se
reitera cada vez que se requiere un reporte.
Todo este proceso se ejecuta dentro de la red de la compañía.
Todo lo mencionado debería incluirse en un modulo de gestión dentro del sistema actual pero
como carece de este y está la obligación de ejecutar el proceso descrito anteriormente.
21
1.3 Descripción del Problema a Resolver
Según los antecedentes antes descritos se presentan un problema en un proceso crítico del
área de gestión, el resultado de este proceso se utiliza para tomar decisiones acerca del negocio
de manera oportuna. El problema se sitúa en el sistema actual, éste no es capaz de cubrir todas
las necesidades de la compañía, así también en el escaso conocimiento del proceso de
extracción de datos, y de su tratamiento para poder obtener los resultados solicitados por la
gerencia del área. En la extracción y el tratamiento de los datos hay una persona encargada
para este proceso, los cuales tienen toda la responsabilidad de extraer y recopilar la
información, por lo cual también no permite llevar un control a distancia de la información,
carece de un acceso seguro y factible desde la extranet.
Este proceso de extracción de datos no está ajeno a errores, debido a que no es un proceso
autónomo. A demás estos procesos no están documentados para poder ser realizados por otras
personas, es decir, estos dependen exclusivamente del personal encargado.
Todos los informes entregados, se realizan con las herramientas alternativas del sistema actual
“Restó”, ya que éste no cuenta con un modulo de control de gestión que entregue reportes del
estado actual de la compañía, entre otras funciones requeridas por el cliente; al realizar la
entrega de los datos, la persona encargada del proceso aplica filtros a estas planillas, utilizando
un criterio que solo el encargado conoce y nadie más realiza en el área. Una vez aplicados los
filtros se realiza una serie de cálculos, con los cuales obtendrá los datos para poder generar los
gráficos o resúmenes solicitados por la gerencia del área comercial.
En resumen, los principales problemas son:
No contar con el modelo de datos debidamente documentado.
Estos informes son extraídos con herramientas externas al sistema actual y no existe
documentación de este proceso.
Dependencia de la persona encargada de estos informes
La data no es de libre demanda según las necesidades del negocio.
Carece de un acceso desde la extranet.
22
Figura 1.5: Problemática a Resolver
Todo lo anterior, no permite consolidar la información de toda la compañía, generando
desventajas al momento de tomar de decisiones oportunas, es decir, existe una gran
dependencia en la manera de compartir los registros para los agentes autorizados externos a la
compañía.
Figura 1.6: Diagrama de obtención actual de la información
23
1.4 Propuesta Solución al Problema
En base a la problemática planteada anteriormente, se construirá un nuevo modelo de datos en
base a consultas históricas de las herramientas externas al sistema Restó, integrada en la
propuesta de implementación de una aplicación web denominada CRONOS, que contenga el
modulo de gestión de la información y así permita optimizar el tiempo de extracción de datos
e información desde cualquier punto externo a la red de la compañía (Extranet).
Figura 1.7: Diagrama de solución al problema de consolidación, en un ambiente web
24
Las funcionalidades y características principales del prototipo, serán presentados por modulo
de necesidades.
Módulo 1:
Crear nuevo modelos de datos, a través de consultas históricas.
Poblamiento de tablas, con las ventas de la compañía, siguiendo las políticas del
negocio.
Crear paralelamente a este sistema un módulo de gestión de la información
Módulo 2:
Consolidar la información en una única base de datos local propietaria.
Consulta de reportes especializados en control de gestión.
Presentar indicadores relevantes para el negocio, con el fin de detectar
tempranamente posibles inconvenientes en los locales.
Módulo 3:
Optimizar el tiempo de extracción de datos e información desde cualquier punto
externo a la red de la compañía (Extranet).
Otorgar independencia y autonomía para la generación de reportes.
Realizar mantención y control de usuarios.
25
Para obtener este resultado, se analizan dos opciones de desarrollo, descritas a continuación:
1.4.1 Desarrollo externo AXOFT
El desarrollo con la empresa externa Axoft Chile, filial de Axoft Argentina, provee más
experiencia dado que realizó el desarrollo de la plataforma RESTÓ, además de ser una empresa
líder desarrolladora del software para gestión de empresas, que implementa sistemas
informáticos para la gestión considerando todas las necesidades de su restaurant, operativas,
logísticas y estratégicas.
Es una empresa que solo entrega el servicio ERP cerrado, al no realizar personalización de
nuevos requerimientos para las empresas, no genera reportes de libre demanda
Ventajas y desventajas
Comprar un software comercial de algún proveedor representa un conjunto de detalles, en el
sentido de que cuenta con lo último en tecnología y además de estándares industriales a la hora
de la elaboración del producto. No se tienen los costos del mantenimiento del producto a largo
plazo y los proveedores son los responsables de esta tarea.
Aunque en algunos casos el software es caro y difícil de personalizar, en otros casos son
soluciones cerradas que no pueden ser modificadas, representan alternativas de muy rápida
implementación.
El software comercial requiere licenciamiento y generalmente está basado en procesos que
representan la visión o estándares que se manejan en la industria, que no necesariamente
reflejan la realidad del usuario final. Esta puede considerarse como una limitación a la hora de
la implementación final. Finalmente si el proveedor deja el negocio, descontinúa el producto o
es comprado por otra compañía, es posible que no se cuente con algún tipo de soporte para el
producto adquirido.
En este caso también es necesario analizar y plantearse estas situaciones a la hora de tomar
una decisión.
26
1.4.2 Desarrollo Interno
Realizar insourcing, es decir, todo el proceso relacionado con la plataforma es realizada por el
personal interno de la empresa. Al realizar el desarrollo internamente se puede obtener
resultados a medida.
Ventajas y desventajas
Al ser desarrollado por la misma empresa, el software puede modificarse o migrar a otras
plataformas tecnológicas, cuenta con las herramientas y personal necesario para la ejecución
de nuevas especificación y la mantención a un bajo costo para la compañía.
El desarrollo interno generalmente empieza desde "cero", entendiendo que se conocen las
necesidades y que es posible hacerlo, el desarrollo podría resultar largo y tedioso. Debido a
que no se llega a tener el compromiso real por parte de la empresa para con el equipo
encargado del desarrollo y que quizás el software desarrollado en casos no sigue las mejores
prácticas de desarrollo, por no contar con la experiencia necesaria en desarrollo de proyectos y
porque a pesar de ser una tarea que requiere casi un 100% de dedicación, la misma debe ser
compartida con las funciones propias de las personas del área informática en la empresa. Lo
cual lleva a demorar el desarrollo del proyecto y esto incrementa el costo del mismo.
27
Tabla 1-3: Comparación soluciones de desarrollo
Desarrollo Externo Desarrollo Interno
NuevosRequerimientos
Adquirir nuevo servicio completo (no es posible
modificar)
Posibilidad de desarrollar nuevos módulos
Externa + costos de servicios (Soporte Técnico) Bajo costo considerado en el
desarrollo del software Mantenimiento de
plataforma
Costo de desarrollo Costo elevado para la compañía
Dentro de los márgenes de gastos de la compañía
Integración a otros sistemas
Software privado sin acceso al código fuente y acceso
restringido
Software con libertad de modificar - propietario del
código fuente
Licencias Software + llaves mensuales Sin Costo
Puntos relevantes de la propuesta:
Mantener la solución principal propuesta anteriormente.
Desarrollar bajo .NET Framework 4.0.
Los requerimientos pueden ser especificados en su totalidad, pueden ser modificados, ya que no implica restricción al desarrollo.
Plataforma y base de datos alojados en servidores internos.
Mantenimiento de módulos.
Nuevos requerimientos después de la implementación son integrados (escalabilidad).
28
1.5 Objetivos
1.5.1 Objetivo General
Desarrollar e implementar un prototipo funcional que se integre a la base de datos de
RESTÓ, realizando la consolidación de la información referente a la compañía de libre
acceso a los datos para la generación de indicadores y reportes.
1.5.2 Objetivos Específicos
Análisis
Determinar los requerimientos necesarios para el desarrollo de la plataforma.
Definir funcionalidades de la plataforma.
Diseño
Diseñar el modelo de la base de datos.
Desarrollar los indicadores tipo prototipos y presentarlos al cliente.
Construcción del prototipo
Sincronizar las aplicaciones (desktop y web).
Otorgar autonomía en los reportes de gestión de libre demanda para la toma de
decisiones.
Implementar el prototipo.
29
1.6 Alcances y Limitaciones del Proyecto
1.6.1 Los Alcances
Desarrollar una plataforma web, que realice la consolidación de la información relacionadas
con las ventas y transacciones almacenados y administrados por RESTÓ. La finalidad es
lograr documentar y extraer la información requerida, del módulo de ventas del sistema
actualmente insertado en la compañía.
Desarrollar indicadores que permitan obtener los datos más relevantes para los usuarios,
presentados mediante reportes de tipo gráfico y tabla.
Desarrollar mantenedores para generar una buena administración, esto será desarrollado
dependiendo de la vista de usuario.
1.6.2 Limitaciones
Las limitaciones del proyecto son:
No contar con la documentación del modelo de datos del sistema actual.
La sincronización de las bases de datos. Para lograr esto se establecerán
interfaces de comunicación de la aplicaciión. En el proyecto solo se realizará la
interfaz de comunicación de la plataforma web.
El ingreso de los datos asociados a la planificación y gestión de la información
será realizado mediante la plataforma Restó, por ende la plataforma web solo
visualizará estos datos.
30
1.7 Justificación
Con este proyecto se pretende desarrollar una herramienta de gestión de la información,
satisfaciendo la necesidad que nos ha problema el sistema RESTÓ, debido que actualmente
carece de un módulo con estas características, RESTÓ solo funciona en plataforma desktop, lo
que no permite obtener una información actualizada y en tiempo real desde la extranet. Por
este motivo se realiza el desarrollo de una nueva plataforma web, que agilice el proceso de
gestión y control de los reportes de gestión de libre demanda que requiere la alta gerencia,
permitiendo integrar y compartir la información en tiempo real, entre la oficina central y los
locales, mejorando la gestión interna de las transacciones y movimientos que contiene el
software RESTÓ. Además de facilitar la labor de los supervisores y los administradores,
permitiendo tener un control remoto de los estados de la compañía.
31
1.8 Área a impactar
El impacto que se logra alcanzar, es aplicar gestión de la información y controlar los procesos involucrados en la empresa. Cómo así
también a las entidades relacionadas.
En la Figura 1.8 se muestra el Organigrama de la empresa y las áreas a impactar.
Figura 1.8: Área a impactar
Franquicias
Ximena Núñez
Patricia Rodríguez
FinanzasMarketing Negocios Operaciones Contabilidad
Braulio Gutiérrez
Aldo Antillo
Juan Escobedo
Sistemas
Marco Morales
Héctor Morales
RR. HH.
Hernán Valenzuela
GerenciaGeneral
Claudio Escalona
Control y Gestión
32
1.9 Requerimientos y Restricciones
1.9.1 Levantamiento de Requerimientos Funcionales
A continuación se describirán los requerimientos funcionales para el desarrollo de la
plataforma cronos Web, obtenidos en conjunto con el cliente (RAP S.A SCHOPDOG).
1.9.1.1 Modelo de Datos
Se obtiene el requerimiento del modelo de datos relacional.
Tabla 1-4: Requerimiento – Modelo de Datos
Requerimiento Descripción
Construir Modelo de Datos Relacional
Se Solicita el modelamiento de la base de datos relacional, que mantendrá los datos obtenidos desdeRESTÓ. Solicitudes Especificas:
Especificar nombres nuevos de las tablas, para identificación de las tablas principales de la base de datos de Restó, para lograr la sincronización.
Alcance
El alcance que tendrá el desarrollo del modelo de datos, está relacionada con las
funcionalidades principales de CRONOS Web, que es facilitar la obtención de
indicadores. Obteniendo los datos que actualmente son alojados en las bases de datos
locales de los usuarios, permitiendo unificar la información.
Se añadirán procedimientos que permitan optimizar el cálculo de la información que
reflejan los indicadores.
33
1.9.1.2 Roles de usuarios
Se obtiene el requerimiento de desarrollo de Roles de usuarios, que tendrá la plataforma,
entregado por el cliente. Tabla 1-5: Requerimiento - Roles de usuario
Requerimiento Descripción
Se solicita el diseño de tres Roles de usuarios, que permitan
la visualización de los indicadores dependiendo de su jerarquía.
A continuación se describen las Roles de usuarios a desarrollar:
Diseñar vista de
MultiEmpresa: Rol perteneciente a los desarrolladores de la compañía Rap S.A. Schopdog
usuarios
MultiUsuario: Rol perteneciente a alta gerencia de la compañía Rap S.A. Schopdog
MonoUsuario: Rol perteneciente a los supervisores
Alcance
El alcance de los Roles de usuarios define la visualización de la información
correspondiente a cada tipo de usuario, dependiendo del Rol, tendrá acceso a los
niveles inferiores, se describe a continuación la funcionalidad de los Roles:
MultiEmpresa (Superior): Permite la utilización de mantenedores para
generar una buena administración, además de obtener la información completa
de las locales asociadas al software. Uso interno de Rap S.A.
MultiUsuario (Media): Permite la obtención de reportes relacionados con
todos los locales.
34
MonoUsuario (Inferior): Permite la obtención de reportes relacionados con
los locales designados.
1.9.1.3 Creación de roles
Se obtiene el requerimiento de creación de roles, para el uso de la plataforma, entregado por el
cliente.
Tabla 1-6: Requerimiento - Vistas de roles
Requerimiento Descripción
Creación de roles
Se solicita la creación de roles, para ser asignadas a los usuarios.
Determinando la función que el usuario presenta dentro de la Empresa.
Alcance
El alcance de la creación de roles, es establecer un conjunto de funciones que puede
realizar un cierto grupo de usuarios, limitando el acceso a la información que podrá
visualizar (depende de las vistas de usuario), un usuario solo puede pertenecer a un rol.
Existirán roles genéricos y especializados, estos dependerán de la información que
permita presentar a su personal. Los roles solo serán administrador por los miembros de
Rap S.A. con autorización.
35
1.9.1.4 Generación de indicadores
Se obtiene los requerimientos de la generación de los indicadores que serán presentados
mediante la plataforma, entregados por el cliente.
Tabla 1-7: Requerimiento -Creación de indicadores
Requerimiento Descripción
Generación de Se solicita la generación de indicadores, que proporcionenindicadores la información relevante para cada local, administrado por RESTÓ.
Alcance
El alcance corresponde a la generación de indicadores que serán presentados mediante
la plataforma web. Estos serán desarrollados en tipo de gráfico y tabla, dependiendo de
la información que sea requerida.
1.9.1.5 Exportación a Excel
Se presenta al cliente la opción de realizar la exportación de la información entregada por los
indicadores.
Tabla 1-8: Requerimiento - Exportación a Excel
Requerimiento Descripción
Exportación a Se solicita la posibilidad de realizar la exportación de Excel La información entregada por cada indicador.
Alcance
El alcance de la exportación a Excel, corresponde a la información presentada por cada
indicador, esta será en formato de tabla. Por ende no se exportarán los gráficos ya que
estos pueden ser guardados como imagen.
36
1.9.1.6 Generación de Dashboard
Se obtiene el requerimiento, de desarrollar un Dashboard, con los indicadores más importantes
para los proyectos, entregado por el cliente.
Tabla 1-9: Requerimiento - Generación Dashboard
Requerimiento Descripción
Se solicita la generación de un Dashboard o resumen de los Gráficos más importantes de los Locales.
Generación de Dashboard Se establecen los siguientes gráficos como predeterminados:
Curva de Avance.
Evolución general de todos los locales.
Evolución general de cada local.
Alcance
El alcance de la generación de Dashboard, será resumir la información clave de cada
local administrado por Resto, mediante la entrega de cuatro gráficos. Además de
permitir realizar la exportación de la información mediante tabla. Los usuarios podrán
generar sus propios Dashboard a través de la interfaz que se implementara en el
proyecto posteriormente.
37
1.9.1.7 Generación de mantenedores
Se obtiene el requerimiento, de generar mantenedores para una mejor administración,
entregado por el cliente.
Tabla 1-10: Requerimiento - Generación de mantenedores
Requerimiento Descripción
Generación de Se solicita la generación de mantenedores, para obtener una Mantenedores mejor administración de la plataforma.
Alcance
El alcance de la generación de mantenedores, es desarrollar mantenedores que
permitan gestionar una correcta administración, serán desarrollados para las vistas de
usuario MultiEmpresa y MultiUsuario.
1.9.1.8 Generación de listados
Se obtiene el requerimiento, de generar listados con los datos principales de los locales.
Tabla 1-11: Requerimiento - Generación de Listados
Requerimiento Descripción
Generación de Se solicita la generación de listados con los datos relevantes de los locales administrados.
listados
Alcance
El alcance de la generación de mantenedores, es desarrollar mantenedores que
permitan gestionar una correcta administración, serán desarrollados para las vistas de
usuario MultiEmpresa y MultiUsuario.
38
1.9.2 Levantamiento de requerimientos no funcionales
1.9.2.1 Banner personalizado
Se obtiene el requerimiento banner personalizado, entregado por el cliente.
Tabla 1-12: Requerimiento - Banner personalizado
Requerimiento Descripción
Banner personalizado Se solicita la personalización del bannerque presenta la Plataforma.
Alcance
El alcance del banner personalizado, es diseñar un banner personalizado para cada
local. Para lograr esto es necesario que cada que en cada banner se identifique con el
lugar específico del local presentado.
1.9.2.2 Formato de la plataforma
Se obtiene el requerimiento formato de la plataforma, entregado por el cliente.
Tabla 1-13: Requerimiento - Formato de la plataforma
Requerimiento Descripción
Formato de la Se solicita realizar un formato adecuado para la plataforma Plataforma, manteniendo la gama de colores de RESTÓ.
Alcance
El alcance del formato de la plataforma, es realizar el diseño acorde a los colores
determinados por Restó. Para posteriormente aplicar el formato final a toda la
plataforma.
39
1.9.2.3 Respaldo del equipo servidor
Se plantea el requerimiento de mantener un respaldo del equipo servidor.
Tabla 1-14: Requerimiento -Respaldo del equipo de servidor
Requerimiento Descripción
Respaldo del equipo servidor
Se indica la posibilidad de obtener algún método que permita respaldar
el software y los datos almacenados en el equipo servidor.
Alcance
El alcance del respaldo de servidor, es implementar el método de espejo que permita
realizar el respaldo completo de esté en otro servidor de similares características,
además de utilizar ups para mantener continua la funcionalidad en caso de falla
eléctrica. La finalidad principal es poder restaurar el estado del sistema en caso de que
ocurra una falla irrecuperable en el equipo servidor.
40
1.9.3 Levantamiento de Restricciones
1.9.3.1 Acceso de Usuario
Se obtiene la restricción de acceso de los usuarios.
Tabla 1-15: Requerimiento - Acceso de usuario
Requerimiento Descripción
Acceso deLos usuarios del software no podrán acceder sin una Identificación proporcionada por una
Usuario combinación de usuario y contraseña.
Alcance
El alcance del acceso de usuarios, es validar que el usuario que ingresa corresponde a
un usuario registrado. La administración de los usuarios será responsabilidad de los
administradores de Rap S.A Schopdog.
1.9.3.2 Eliminación de datos
Se obtiene la restricción de acceso de los usuarios.
Tabla 1-16: Requerimiento - Eliminación de datos
Requerimiento Descripción
Eliminación deEliminación de los datos ingresados al sistema será de responsabilidad del usuario
Datos con privilegios en el software
Alcance
El alcance de la eliminación de datos, queda sujeta a los usuarios que poseen
privilegios de realizar la eliminación de información importante, estos privilegios serán
41
determinados por el rol que se asigne al usuario. Sin embargo se realizará un log con
los datos del usuario que ha eliminado información.
1.10 Planificación
Tabla 1-17: Planificación
Nombre Etapa Descripción y Resultados Esperados Fechas Comienzo y Fin
Análisis
Diseño
Implementación
Análisis del problema/solución
Obtención de los requerimientos
Creación de modelos de acuerdo a los requerimientos
Diseño y creación del modelo de Datos.
Creación de Procedimientos almacenados.
Desarrollo de las interfaces especificadas por el cliente.
Integración de software
Programación ( SQL / .NET )
Entrega
05/08/2013 – 26/08/2013
09/09/2013
30/09/2013
21/10/2013
28/10/2013
04/11/2013
11/11/2013
11/11/2013
25/11/2013
42
CAPÍTULO 2 ESTADO DEL ARTE
Este capítulo permite justificar el desarrollo del proyecto (apartado 2.1), además de especificar
la tecnología que se utilizará en el desarrollo de la plataforma (apartado 2.2).
2.1 Software Similares
Actualmente en el mercado se pueden encontrar diferentes tipos de software en el ambiente
web que cumplen con algunas de las características que posee la plataforma CRONOS Web. A
continuación se describirán algunos de estos.
Lanix ERP
Lanix ERP es un sistema de administración, orientado a la Pyme y a la mediana empresa. Está
desarrollado con tecnología de punta y lenguaje Java, que le permite trabajar de manera
natural en Web. Es multiplataforma y multi-base de datos, lo que le otorga gran agilidad y
flexibilidad respecto a la competencia. Se comercializa en base a dos modalidades: full web,
es decir, en modalidad de arriendo; y de manera local, montado en las instalaciones del cliente
mediante licencias de usuario.
Manager ERP
Manager ERP es un Software de Gestión Empresarial que provee a sus clientes una
herramienta de gestión para la administración de su negocio, integrando las funciones de
ventas, existencia, abastecimiento, contabilidad, tesorería, activo fijo, recursos humanos, CRM
y Producción, entre otros; todo esto sobre una plataforma flexible y escalable.
Openbravo
Es una solución ERP basada en “la nube” que se distribuye gratis bajo licencia opensource.
Está pensada para Pymes (negocio particular o empresa de hasta 50 trabajadores). Openbravo
ofrece módulos y paquetes ERP para integrar la Gestión de compras y almacenes, Gestión de
proyectos y servicios, Gestión comercial, Contabilidad, Gestión económico-financiera,
Gestión avanzada de clientes o CRM, Inteligencia de negocio o BI. Desde su lanzamiento ya
se han realizado unas 2.000.000 de descargas, lo que habla del interés que despierta esta
43
solución en el mercado. Su modelo de negocio se basa en el canal indirecto y cuenta con unos
100 partners (vendors) en todo el mundo. Aparte de la solución opensource tienen una versión
comercial para grandes empresas llamada Openbravo Professional Edition.
RESTÓ
Restô es un sistema de gestión que brinda una solución integral para los puntos críticos del
negocio gastronómico, tanto para un restaurante pequeño como para una gran cadena. Cuenta
con módulos específicos para cada área: salón, caja, delivery, cocina, stock, administración
entre otros.
TANGO Punto de Venta, por su parte, apunta principalmente a la gestión de puntos de venta
de indumentaria. Recientemente incluyo nuevas funcionalidades, como una opción para
gestionar gift cards y el módulo “Promociones” que permite generar y manejar cualquier
promoción de forma centralizada permitiendo establecer las condiciones desde un sistema
central para todas las sucursales.
Figura 2.9: Vista del Sistema actual de la compañía
En conclusión, la mayoría del software antes mencionado cumple con la característica de ser
desarrollados para un ambiente web y de facilitar la entrega de la información del estado real
44
de la compañía a todos los agentes involucrados. Sin embargo, el desarrollo de la plataforma
CRONOS Web, es principalmente debido a que se necesita obtener la consolidación y
sincronización de la información que existe actualmente en la plataforma Resto, sin alterar el
comportamiento de los usuarios. Además de mantener el proceso de organización que utiliza
la plataforma desktop. Por este motivo solo se logrará la interacción de ambas plataformas,
mediante un desarrollo elaborado a la medida, que permita satisfacer requerimientos que
escapan a los cubiertos por el o los software de tipo empaquetados.
Tabla 2-18: Comparación de software
Lanix ERP Manager ERP
Openbravo RESTÓ Cronos Web
Empresa Pyme. Pyme. Pyme.
Pyme, Mediana y Grandes Empresas.
Pyme, Mediana y Grandes Empresas.
Libre acceso a los datos
No, Solo presta Servicio.
No, Solo presta Servicio.
No, Solo presta Servicio.
No, Solo presta Servicio.
Si, Modelo de Datos propiedad de la empresa.
Nuevos requerimientos
No, Software Cerrado.
No, Software Cerrado.
No, Software Cerrado.
No, Software Cerrado.
Si, creación de nuevos módulos
Web
Si, software local y web.
No, software local.
Si, software web.
No, software local.
Si, software web.
LicenciasPago de Servicio + Licencia mensual.
Pago de Servicio + Licencia mensual.
No, licencia opensource.(Gratuita)
Pago de Servicio + Licencia mensual.
No, propiedad de la Empresa.
2.2 Tecnología
45
En la actualidad existen diferentes tecnologías de desarrollo de software. En el proyecto se
utilizará la tecnología de Microsoft .NET. El motivo de la utilización de esta tecnología y no
de otras es básicamente porque la empresa trabaja bajo la plataforma de ambiente Microsoft.
Esta tecnología está compuesta de varios lenguajes de programación que se ejecutan bajo el
.NET Framework. Es además un entorno completamente orientado a objetos y que es capaz
de ejecutarse bajo cualquier plataforma.
El .NET Framework es el corazón y marco de trabajo de la ejecución de la tecnología .NET.
Algunos de los lenguajes que soporta son: ASP.NET, C#, C++ controlado, VB.NET, entre
otros.
Para el desarrollo de los indicadores que son presentados en la plataforma web a desarrollar, se
analizaron dos controles que posee .NET Framework 4.0 (Visual Studio 2010), estos son
descritos a continuación:
2.2.1 ReportViewer
Permite realizar el diseño de informes en aplicaciones desarrolladas bajo .NET Framework.
Los informes son de fácil diseño, debido a que se realiza la captura de los datos mediante un
dataset, que establece conexión directa con la base de datos. Este controlador permite la
simplicidad de arrastrar y soltar a través del diseñador de informes incluidos en Visual Studio
2010.
El control ReportViewer ofrece los siguientes beneficios:
46
Procesos de datos eficientes. El motor de informes integrado en ReportViewer puede
realizar operaciones como el filtrado, clasificación, agrupación y agregación.
Soporta una variedad de formas para presentar los datos. Se puede presentar los datos
como listas, tablas, gráficos y otros.
Añade atractivo visual. Puede especificar las fuentes, colores, estilos de borde, etc.
Permite la interactividad en los informes. Se puede tener secciones plegables, el mapa
del documento, marcadores, etc., ordenación interactiva en el informe.
Soporta impresión y vista preliminar.
Soporta la exportación a Excel, Word y PDF.
2.2.2 Microsoft Chart
Permite realizar el diseño de gráficos mediante enlaces con la base de datos y/o código fuente.
El control Microsoft Chart ofrece los siguientes beneficios:
Creación de n series dependiendo de los datos a graficar.
Puede especificar las fuentes, colores, estilos de borde, títulos, etc.
Escalabilidad.
Permite optimización.
2.2.3 Comparación y elección
47
En tabla 2.1, se realiza la comparación de los puntos más significativos de los indicadores tipo gráficos.
Tabla 2-19: Comparación de Controles
Características Dataset Código Series Exportación Estilos Diseño Control Fuente Dinámicas Rápido
ReportViewer X
X X X
Chart X X X
X
X - Característica que posee el control
El control ReportViewer, ofrece una buena presentación y fácil incorporación al desarrollo, sin
embargo este control no permite la creación de series dinámicas para los gráficos. Esto es a
causa de que al definir el dataset de ReportViewer, se establece la cantidad de series que serán
creadas en el gráfico. A diferencia de Microsoft Chart, que utiliza series dinámicas para la
creación de los gráficos, es decir, sus series son diseñadas mediante código fuente. Por este
motivo se selecciona el control Microsoft Chart, que es manipulable y permite realizar
escalabilidad, mejorando la entrega de la información.
La plataforma web a desarrollar requiere de dos tipos de indicadores, estos son de tipo gráficos
y de tipo tablas, por lo cual para realizar el desarrollo de los gráficos se utilizará el control
Microsoft Chart, además se utilizará en el desarrollo de las tablas el control Microsoft Table,
ya que estos dos controles son manipulados mediante código fuente, permitiendo utilizar la
misma información obtenida desde la base de datos.
Además de utilizar la tecnología .NET, se utilizará Jquery que es una biblioteca de JavaScript
que permite el manejo de eventos, animación, e interacciones Ajax, con esta biblioteca se
entrega una mayor performance a la plataforma web, liberando de trabajo al servidor, es decir,
la mayor parte del trabajo la realiza el browser del usuario.
CAPÍTULO 3 HERRAMIENTAS Y METODOLOGÍAS
48
3.1 Arquitectura de solución.
Para resolver esto se desarrollará una estructura (cliente/servidor), que proporcionará a los
usuarios la información requerida, que se mantendrá alojada en un servidor web, permitiendo
que los usuarios puedan consultar en forma autónoma la información, también permitiendo
actualizar y/o descargar la información guardada en la web, con esto se logra tener la
información unificada y consolidada para la toma de decisiones oportunas.
El modelo de capas tiene como destino final ayudar a construir componentes físicos a partir
de los niveles lógicos, estos niveles están conformados por varios componentes, por tanto
pueden suplir a muchos servicios. Estos niveles pueden ser o serán los que siguen: nivel
usuario, proporcionan la interfaz visual que los clientes utilizarán para ver la información y los
datos. En este nivel, los componentes son responsables de solicitar y recibir servicios de otros
componentes del mismo nivel o del nivel de servicios de negocio. Es muy importante destacar
que, a pesar de que las funciones del negocio residen en otro nivel, para el usuario es
transparente la forma de operar. Nivel de negocio Como los servicios de usuario no pueden
contactar directamente con el nivel de servicios de datos, es responsabilidad de los servicios
de negocio hacer de puente entre estos. Los objetos de negocio proporcionan servicios que
completan las tareas de negocio tales como verificar los datos enviados por el cliente. Antes de
llevar a cabo una transacción en la base de datos.
Los componentes de los servicios de negocio también nos sirven para evitar que el usuario
tenga acceso directo a la base de datos, lo cual proporciona mayor seguridad en la integridad
de ésta.
Sus capas son:
Capa de presentación
Capa de lógica de negocio
Capa de datos
Más adelante en el capítulo 4 “Diseño’’, en Arquitectura del proyecto se dará énfasis y detalles de cada capa. Las ventajas principales:
49
Es el desarrollo se puede llevar a cabo en varios niveles y, en caso de que
sobrevenga algún cambio.
En el diseño de sistemas informáticos actuales se suele usar las arquitecturas
multilineal o Programación por capas.
Además, permite distribuir el trabajo de creación de una aplicación por niveles;
cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma
que basta con conocer la API que existe entre niveles. API (Application
Programming Interface)
Es el conjunto de funciones y procedimientos o métodos que ofrece cierta
biblioteca para ser utilizado por otro software como una capa de abstracción.
Fuente Bibliográfica: http://infoaventuras.blogspot.com/2004/09/modelo-3-capas.html3.2 Entorno Tecnológico
50
Realizar una buena elección del entorno tecnológico para el desarrollo e implementación del
sistema, se rige por la idea de disminuir la ocurrencias de problemas que puedan surgir durante
el proceso de desarrollo (mal funcionamiento de hardware, indisponibilidad de los servidores
que soportan el ambiente de desarrollo) y errores en el sistema ya en funcionamiento.
3.2.1 Herramientas
Las herramientas elegidas para el desarrollo e implementación del sistema son las siguientes:
Sistema Operativo:
Windows Seven Ultimate (Equipo desarrollo)
Windows Server 2008 Standard (Equipo servidor)
Lenguaje de Programación:
SPX.
C#.
HTML y JavaScript.
SQL.
Servidor HTTP: IIS
Software de desarrollo: Visual Studio 2010 (con Microsoft Team Foundation Server).
Base de Datos: SQL Server 2005.
Hardware de desarrollo e implementación.
Navegador web: Internet Explorer y Mozilla FireFox (navegadores para desarrollo).
51
Los entornos de desarrollo, pruebas e implementación son idénticos en lo que respecta a la
tecnología.
A continuación se justificará la elección de cada uno de los componentes del entorno
seleccionado:
Sistema Operativo
La elección de un SO (sistema operativo), como elemento básico e imprescindible, es
una decisión estratégica a la hora de construir cualquier software. En este caso la
elección fue utilizar el SO de Microsoft debido que el cliente trabaja actualmente sobre
la plataforma Microsoft.
Las características que justifican la elección:
Conocimiento profundo del sistema, desde el punto de vista de administración
de sistemas, lo que facilita las labores de desarrollo, pruebas e implementación,
y no menos mencionable el mantenimiento.
Integración comprobada con el resto de los componentes (lenguajes de
programación, base de datos y herramientas de desarrollo).
En conclusión la elección de los sistemas operativos Windows Seven Ultimate y Windows
Server 2008 Standard, implica un riesgo mínimo de error en la ejecución y el servicio.
Lenguaje de Programación
Al igual que una buena elección de un SO, la selección de los lenguajes de
programación a utilizar vienen dada por la naturaleza del proyecto, además de una
buena complementación entre estos lenguajes.
A continuación se explicará cada uno de los lenguajes a utilizar.
52
ASPX
Lenguaje base para el desarrollo de la plataforma web, esta extensión contiene
principalmente las etiquetas HTML o XHTML estático, y también etiquetas de
Controles Web que se procesan del lado del cliente requerido por la página web.
También es conocida como la interfaz gráfica del usuario.
C#
Este lenguaje es conocido como el Code Behind, de la clase ASPX, este lenguaje
permite desarrollar en código fuente los procedimientos relacionados con la lógica del
negocio. Trabaja a nivel servidor.
HTML y JavaScript
El lenguaje HTML es un formato simple para la creación de formularios o archivos de
hipertexto, que pueden ser visualizados en diferentes browsers. Es complementado con
el lenguaje JavaScript, que permite el desarrollo de aplicaciones cliente/servidor, este
último lenguaje facilita el uso de objetos, creando una página más dinámica, además de
permitir realizar validaciones que serán ejecutadas en el cliente, utilizando un conjunto
de utilidades y funciones que facilitan la producción de código denominada JQuery,
además de la utilización de Ajax que es una tecnología asíncrona, es decir, los datos
adicionales se solicitan al servidor y se cargan en segundo plano sin interferir con la
visualización ni el comportamiento de la página.
SQL
El lenguaje SQL, es de acceso a bases de datos relacionales que permite especificar
diversos tipos de operaciones en ellas. Una de sus características es el manejo del
álgebra y el cálculo relacional que permiten efectuar consultas con el fin de recuperar
de forma sencilla información de interés de bases de datos, así como hacer cambios en
ella.
53
Servidor HTTP
Se utilizará el servidor IIS7, para aplicaciones basadas en el ambiente Microsoft,
proporcionando las herramientas y funciones necesarias para administrar de forma
sencilla un servidor web seguro.
Software de desarrollo
Para el desarrollo de la plataforma se utilizará el software Visual Studio 2010 Ultimate,
que es un conjunto de herramientas, que simplifica el desarrollo de aplicaciones
escalables de alta calidad con la utilización de la tecnología .NET. Además de utilizar
Team Foundation Server, que permite realizar el desarrollo en conjunto con varios
programadores conectados al servidor donde se aloja la plataforma en desarrollo.
Base de Datos
Se utilizará el administrador SQL Server 2005, para alojar la base de datos de
CRONOS Web, algunas características son:
Soporte de transacciones.
Soporta procedimientos almacenados.
Incluye también un entorno gráfico de administración, que permite el uso de comandos
DDL y DML gráficamente.
Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en el
servidor y los terminales o clientes de la red sólo acceden a la información.
Además permite administrar información de otros servidores de datos.
54
3.2.2 Hardware de desarrollo e implementación Navegador web
Para el desarrollo de la plataforma se utilizarán dos navegadores o browsers, estos son:
Internet Explorer: será utilizado como browser principal para la plataforma, debido que
la visualización de los componentes Gantt de planificación son compatibles con este
browser, es decir la compatibilidad de la plataforma será del 100%.
Mozilla FireFox: será utilizado para la depuración de la plataforma, es decir permite
utilizar el complemento FireBug, que permite encontrar y controlar las fallas de la
plataforma a nivel cliente.
3.2.3 Justificación de Herramientas
La justificación de las herramientas escogidas es únicamente por requerimiento del cliente,
Ya que el entorno de trabajo del cliente es Microsoft, presenta convenios de soporte y
licencias con esa compañía. El cual se brinda seguridad e integración con la empresa.
55
3.3 Metodologías
3.3.1 Análisis comparativo de las metodologías
La elección de una metodología debe considerar varios factores que permitan estructurar,
planificar y controlar el proceso de desarrollo de software, dependiendo de los requerimientos
establecidos por el cliente.
La metodología es el núcleo del entorno de desarrollo (Ver Figura 3.1) y con esto permite que:
La organización mantenga un equipo de desarrollo (Hardware, Software y Humano).
Procedimientos de gestión
Influyen y determinan el soporte automatizado de Software y Hardware.
Coordinan y guían a los desarrolladores en el uso de las técnicas.
Soporte automatizado.
Para obtener un buen núcleo en el desarrollo del proyecto, se analizan las siguientes metodologías:
Figura 3.10: Núcleo del entorno de desarrollo
56
3.3.2 Cascada
La metodología en cascada es un proceso de desarrollo secuencial, en el que se ve fluir
hacia abajo (como una cascada) cada una de las fases que componen el ciclo de vida
del software, descritas en la Figura 3.2, es decir, se ordena rigurosamente cada etapas
del ciclo, de forma que el inicio de una etapa dependerá de la finalización de la etapa
anterior.
Figura 3.11: Modelo de ciclo de vida en cascada
57
Fuente Bibliográfica:
http://opinadeti.wordpress.com/2011/03/12/introduccion-a-las-metodologias-agiles-ciclos-de-vida-de-desarrollo-de-software-i/
A continuación se presentarán las ventajas y desventajas de esta metodología:
Ventajas
Es apropiado para proyectos estables y donde los diseñadores establezcan
totalmente las áreas de problema del sistema, produciendo un diseño correcto antes
de que comience la implementación de la metodología.
Es un modelo en el que todo está bien organizado y no se mezclan las fases. Es
simple y fácil de usar.
Debido a la rigidez del modelo es fácil de gestionar ya que cada fase tiene
entregables específicos y un proceso de revisión. Las fases son procesadas y
completadas de una a la vez.
Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala
implementación del modelo, lo cual hace que lo lleve al fracaso.
Difícilmente un cliente va a establecer al principio todos los requerimientos
necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que es
muy restrictivo y no permite movilizarse entre fases.
58
Los resultados no son visibles progresivamente, el producto se ve cuando ya está
finalizado completamente, provocando en el cliente una gran inseguridad, por no
poder ver los avances del producto.
59
3.3.3 Espiral
Esta metodología está compuesta por varios bucles en forma de espiral, donde cada bucle
representa un conjunto de actividades (Ver Figura 3.3). La atención principal de este modelo
se centra en la evaluación y reducción de los riesgos del proyecto. Al ser dividida en varios
bucles proporciona más facilidad de cambio durante el proceso de desarrollo, es decir, si el
cliente requiere realizar mejoras en el software, se vuelven a evaluar las nuevas alternativas y
riesgos, y se realiza otra vuelta a la espiral, así hasta que llegue un momento en el que el
producto (software) esté finalizado.
Figura 3.12: Modelo de ciclo de vida en espiral
Fuente Bibliográfica:
http://epilef7147.blogspot.com/2010/08/modelo-en-espiral.html
60
A continuación se presentarán las ventajas y desventajas de esta metodología:
Ventajas
Reduce riesgos del proyecto.
Incorpora objetivos de calidad.
Integra el desarrollo con el mantenimiento.
Posibilita realizar mejorar y toma de nuevos requerimientos, ya que no es rígido ni
estático.
Permite entregas tempranas del software.
Desventajas
Genera mucho trabajo adicional.
Es necesario tener un nivel alto de experiencia y habilidad en los análisis de riesgos.
Esto lo convierte en un modelo costoso.
No funciona bien para proyectos pequeños.
61
3.3.4 Incremental
Esta metodología combina elementos del modelo en cascada con la filosofía interactiva de
construcción de prototipos. Esta filosofía se basa en construir incrementando las
funcionalidades del programa, aplicando secuencias lineales de forma escalonada mientras
progresa el tiempo de la planificación, cada secuencia lineal produce un incremento del
software (ver Figura 3.4).
Cuando se utiliza este modelo, el primer incremento es a menudo un producto esencial, solo
con los requisitos básicos. Se centra en la entrega de un producto operativo con cada
incremento. Las primeras entregas son versiones incompletas del producto final, pero
proporcionan al cliente una plataforma con funcionalidad precisa y expuesta a evaluación.
Figura 3.13: Modelo de ciclo de vida incremental
62
A continuación se presentarán las ventajas y desventajas de esta metodología:
Ventajas
Se genera un software operativo de forma rápida y en etapas tempranas del ciclo de vida del software.
Es más flexible, por lo que reduce el costo en el cambio de alcances y requisitos.
Es más fácil de probar y depurar en una iteración más pequeña.
Cada iteración es un hito gestionado fácilmente.
Desventajas
Se requiere definir los incrementos y distribuir en ellos las tareas de forma proporcionada.
Cada fase de una iteración es rígida y no se superpone con otras.
Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido.
63
Tabla 3-20: comparación de metodologías
Características AvanceLineal.
Mejoras y Nuevos
Requerimientos.
Comunicacióncon el cliente.
Evaluación Primeras etapas.
Riesgo del Proyecto.
Metodología
Cascada
Secuencial,Requiere de
mayor experiencia en
proyectos.
Restrictivo, no permite
movilizarse entre faces.
El cliente debe tener paciencia, ya que la aplicación sólo estará disponible en un estado muy avanzado del proyecto.
Los Progresos no son visibles progresivamente, inseguridad del cliente.
Alto.
Espiral
Secuencial, Inicio de una
etapa, dependerá de la
finalización de la otra.
Si, posibilita mejoras y nuevos requerimientos, no es rígido
Requiere comunicación permanente con el cliente, es necesario que esté al tanto de lo realizado y lo pendiente, debe ser gran conocedor del sistema.
Entregas tempranas del software.
Medio.
Incremental
Si, Cada iteración es gestionada fácilmente.
Si, Ventaja de Flexibilidad,
reduce costos en alcances y requisitos.
Los clientes no tienen que esperar hasta tener el sistema completo. El primer incremento satisface los requisitos más críticos.
Entrega de Versiones incompletas, SW operativo de forma rápida en etapas tempranas.
Bajo.
64
CAPÍTULO 4 APLICACIÓN DE LA METODOLOGÍA
4.1 Selección de la metodología
Para el desarrollo del proyecto se utilizará la Metodología Evolutiva-Incremental. Esta
metodología se compone de la metodología evolutiva, que se basa en desarrollar una versión
del software inicial, sometiéndola a pruebas y comentarios del cliente, mediante esto se
realizan las afinaciones necesarias a través de diferentes versiones. Las actividades de
especificación, desarrollo y validación se entrelazan, con una rápida retroalimentación entre
estas. Se complementa con las bases de la metodología incremental, que permite realizar
iteraciones en el desarrollo de las versiones. Obteniendo un proceso más manejable y
reduciendo el impacto en los costos.
Además de permitir alterar o rehacer los requisitos, debido que solo afecta a una parte del
sistema. En definitiva, facilita la incorporación de nuevos requerimientos durante el desarrollo.
Los procesos que se utilizarán son los siguientes (ver Figura 4.1):
Especificación Inicial: Definición del problema y especificación inicial a base de los
requerimientos definidos.
Diseño del Software: es el desarrollo en base a un proceso con énfasis en la rapidez de
la liberación.
Implementación, uso y evaluación: es la implementación y uso, en un ambiente de
exploración y monitoreo de nuevos requerimientos.
Re-especificación: es la redefinición del desarrollo en base a los nuevos
requerimientos.
65
Ventajas
Se genera un software operativo de forma rápida y en etapas tempranas del ciclo de vida del software.
Es más flexible, por lo que reduce el costo en el cambio de alcances y requisitos.
Es más fácil de probar y depurar en una iteración más pequeña.
Cada iteración es un hito gestionado fácilmente.
Desventajas
Se requiere definir los incrementos y distribuir en ellos las tareas de forma proporcionada.
Cada fase de una iteración es rígida y no se superpone con otras.
Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido.
Figura 4. 1: Procesos de la metodología Evolutiva - Incremental
66
En resumen, si comparamos las metodologías antes nombradas (Ver tabla 3.1). La
metodología en cascada no aplicaría para el desarrollo del software, porque los requerimientos
deben ser completamente establecidos al inicio del desarrollo. En cambio la metodología en
espiral, permite modificar o incluir nuevos requerimientos sin alterar la funcionalidad del
modelo, además de realizar entregas tempranas del proyecto, pero debido que es necesario
poseer una alta experiencia en la identificación de riesgos, aumenta el costo y el tiempo
invertido. Por el contrario, la metodología incremental es la más cercana a cumplir con los
requisitos que se necesitan, los cuales son: obtener entrega de versiones, requerimientos
incompletos, bajo costo y menor tiempo. También otorga la ventaja de la revisión parcial de
los avances por parte de los expertos del negocio.
4.2 Aplicación de la metodología.
67
La aplicación de la metodología consiste en la construcción de una implementación parcial
que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente,
incorporarlos al sistema.
El software evoluciona con el tiempo (Los requisitos del usuario y del producto suelen
cambiar conforme se desarrolla el mismo).En esas u otras situaciones similares los
desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una
evolución temporal o progresiva, donde los requisitos construye una serie de grandes
versiones sucesivas de un producto.
El modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio
del proyecto, los requerimientos son cuidadosamente examinados, y sólo esos que son bien
comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen
una implementación parcial del sistema que recibe sólo estos requerimientos.
La metodología consta de tres iteraciones ya que en un proyecto pequeño alcanza a cubrir la
totalidad de los requerimientos.
Primera Iteración: Construcción del modelo de datos
Criterio de término: Para el término de esta iteración se enviarán los nuevos
informes con los datos extraídos a los expertos del negocio (Control de Gestión
de la compañía) para el análisis y verificación de los datos obtenidos desde el
nuevo sistema. Estos a su vez envían la confirmación que la información es
fidedigna, para la toma de decisiones de la compañía (Ver figura 4.4).
Segunda Iteración: Desarrollo de informes e Indicadores.
68
Criterio de Termino: Para el término de esta iteración el departamento de control
y gestión analizó la información y otorgo la validación para la creación de nuevos
indicadores y reportes.
Tercera Iteración: Creación y administración de mantenedores
Criterio de término: Para el término de esta iteración se cercioró que las
instrucciones de cada proceso del mantenedor progresaran correctamente con los
criterios estipulados anteriormente (especificación inicial), se indago con pruebas
de cada mantenedor y se evaluó cada uno por separado.
A continuación se presentarán un enfoque modular de las iteraciones de la metodología
escogida.
4.2.1 Primera Iteración: Construcción Modelo de Datos.
69
Especificación Inicial.
No contar con la documentación del modelo de datos del sistema actual, por motivo que el
software es un ERP cerrado, del cual el cliente adquiere el servicio.
Por lo tanto se construirá un nuevo modelo de datos, que integre a la base de datos del sistema
actual RESTÓ, en base a las consultas históricas de las herramientas externas creadas para
resolver la extracción de los datos.
Diseño.
70
El objetivo de este modelo es presentar el sistema con sus respectivas entidades y mostrar
cómo se relaciona cada una de ellas (ver figura 4.2). Se presentarán y detallarán las tablas más
importantes del proceso.
Principales Tablas.
A continuación, se presenta una breve descripción de las principales Tablas de la plataforma.
C_AVANCE_PROYECTADOid_sucursalfecha_avance_realporcentaje
C_AVANCE_REALid_sucursalfecha_avance_realmonto
C_AVANCE_RMENSUALid_sucursalfecha_avancemonto
C_AVANCEPMENSUALid_sucursalfecha_avancemonto
C_CIUDADid_cuidadciudad
C_COMUNAid_comunaid_ciudadcomuna
C_ENCARGADOid_encargadoid_usuarioid_sucursal
C_MENUid_menumenumultiLocalmonoLocalorden
C_MESid_mesmes
C_ROLid_rolrol
C_ROL_SUBMENUid_submenuid_rol
C_SUBMENUid_submenuid_menunombre_submenumultiLocalmonoLocalrutaorden
C_SUCURSALid_sucuralnombre_sucursaldirecciontelefonoemailcodigo_sucursalid_comunaid_ciudad
C_USUARIOid_usuariologinpasswordid_rolnombretelefono
C_VENTA_DIARIAid_ventaid_sucursalmonto
C_VENTA_MENSUALid_ventaid_sucursalid_mesmonto
Figura 4. 2: Modelo E-R: Acceso a plataforma CRONOS Web
71
C_SUCURSAL: En esta tabla se alojarán los datos de ubicación y de contacto de cada local.
C_ENCARGADO: En esta tabla se alojarán los datos del usuario asignado, para la
administración de las sucursales.
C_VENTA_DIARIA: En esta tabla se alojarán los datos de las ventas realizadas en cada
local, identificando la sucursal y la fecha asociada.
C_AVANCE_REAL: En esta tabla se alojarán los datos de ventas, respecto a la fecha real
desfasado un día, para realizar un análisis de ésta.
C_AVANCE_PROYECTADO: En esta tabla se alojarán los datos de ventas proyectadas
para cada sucursal.
Implementación, uso y evaluación.
C_AVANCE_PROYECTADOid_sucursalfecha_avance_realporcentaje
C_AVANCE_REALid_sucursalfecha_avance_realmonto
C_ENCARGADOid_encargadoid_usuarioid_sucursal
C_SUCURSALid_sucursalnombre_sucursaldirecciontelefonoemailcodigo_sucursalid_comunaid_ciudad
C_VENTA_DIARIAid_ventaid_sucursalmonto
Figura 4. 3: Modelo E-R: Principales Tablas CRONOS Web
72
Se verificó la información mediante comparaciones de datos, extraídos del sistema actual de
la compañía y los datos de prueba extraídos desde el nuevo modelo, generado con las
consultas históricas almacenadas en las herramientas externas creadas para resolver los
problemas de información, respecto a la toma de decisiones (Ver figura 4.4).
Figura 4. 4: Comprobación de datos
Criterio de término: Para el término de esta iteración se enviarán los nuevos informes con los
datos extraídos a los expertos del negocio (Control de Gestión de la compañía) para el análisis
y verificación de los datos obtenidos desde el nuevo sistema. Estos a su vez envían la
confirmación que la información es fidedigna, para la toma de decisiones de la compañía (Ver
figura 4.4).
73
Se enviaron los datos de las ventas actualizadas, ventas proyectadas y ventas acumuladas de
cada local. Se tomó información de las ventas de todo el año 2012, se verificó mes a mes si la
información era correcta teniendo una aprobación conforme a lo requerido. Así también se
elaboraron nuevas consultas a la nueva base de datos reafirmando la claridad de la
información.
Re-especificación El diseño presentado no es el definitivo, esté está diseñado para acomodarse a una evolución
temporal o progresiva donde existan redefiniciones del desarrollo en base a nuevos
requerimientos.
4.2.2 Segunda Iteración: Desarrollo de informes e Indicadores.
Especificación Inicial.
Actualmente la extracción de los informes de gestión dentro de la compañía, son mediantes
herramientas externas al sistema, ya que el sistema actual carece de un módulo de gestión
para la generación de reportes y como es un software cerrado los analistas están obligados a
utilizar estas herramientas. Por esta razón se requiere una manera más práctica, eficiente e
independiente de la actual. También otorgando la factibilidad de insertarles nuevos
requerimientos en la evolución de este.
Por lo tanto se construirá una nueva herramienta de informes, que integre la información del
sistema actual con la capacidad de integrarle más requerimientos según sea necesario.
74
Diseño
El objetivo de este diseño es presentar a los expertos del negocio un sistema claro y eficiente
al momento de obtener la información. Otorgándoles la capacidad de consultar en todo
momento la situación del negocio.
Tipo de Reportes:
Ventas Diarias: El reporte contendrá las ventas de un determinado local, junto con su
meta para la fecha que corresponda.
Ventas Acumuladas: el Reporte contendrá las ventas acumuladas de un determinado
local, además tendrá las metas de ventas para las fechas correspondientes.
A continuación se exhibirán el diseño de casos de uso de la segunda iteración.
4.2.2.1 Casos de uso
El diseño de los casos de uso, permite describir las actividades que el usuario puede
realizar en la plataforma. Estos serán utilizados posteriormente en el desarrollo del
proyecto. Para el diseño de los casos de uso se utilizará el software Architect
Enterprise 9, para el diseño de flujo se utilizará Bizagi Process Modeler.
75
Caso de Uso - Listados de ventas
uc CASO DE USO: REPORTES DE VENTAS
VISUALIZAR REPORTE DE VENTAS
VISUALIZAR REPORTE DE VENTAS LOCALES
ASIGNADOS
SUPERVISOR
GERENCIA
REPORTES DE VENTAS
DESARROLLADORVARIOS LOCALES UN SOLO LOCAL
«extend» «extend»
Figura 4. 5: Caso de Uso - Listados de locales y ventas
76
Tabla 4- 1: Flujo - Listado de Ventas
Descripción: Inicialmente los actores ingresan al sistema, se valida la vista de usuario según
roles asignado a cada uno, dependiendo del rol se podrán visualizar los reportes de ventas.
Rol gerencia: visualiza reportes de todos los locales de la compañía
Rol supervisor: visualiza reportes de locales asignados
Figura 4. 6: Flujo - Listados de Locales y Ventas
Nombre Listado de Locales y Ventas
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe las actividades que el usuario puede realizar con los listados de ventas.
Actores: Desarrollador, Gerencia, Supervisor.
Función: Visualizar Reporte de Ventas.
Precondiciones: Los usuarios gerencia y supervisor tienen que estar debidamente registrados en Cronos Web para poder ingresar a la aplicación.
El actor supervisor solo puede ver los locales asignados.Flujo Normal:
1. Los actores ingresaran al sistema.2. Los actores elegirán el local, en caso de ser supervisor se mostraran los locales
que tiene asignados.3. Los actores visualizaran el reporte de ventas de los locales.
Flujo Excepcional: En el caso que los actores no puedan visualizar el reporte de ventas, se deberá recurrir al departamento de soporte para solucionar el inconveniente.
77
4.2.2.2 Indicadores
En este caso de uso se describe las actividades que el usuario puede realizar con los
indicadores.
Caso de Uso - Indicadoresuc CASO DE USO: INDICADORES - REPORTES TIPO GRAFICO Y TABLA
SUPERVISOR
GERENCIA
Visualizar Indicadores
Visualizar Reporte Tipo Gráfico
Exportar Excel
Filtrar Reportes
REPORTES TIPO TABLA Y GRAFICO
DESARROLLADOR
Visualizar Reporte Tipo Tabla
«include» «include»
«extend»
Figura 4. 7: Caso de Uso - Indicadores: Reportes tipo gráfico y tabla
78
Tabla 4- 2: Indicadores: Reportes tipo gráfico y tabla
Nombre Indicadores: Reportes tipo gráfico y tabla
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe las actividades que el usuario puede realizar con los indicadores.
Actores: Desarrollador, Gerencia, Supervisor.
Función: Visualizar reporte tipo gráfico, visualizar reporte tipo tabla, exportar, filtrar y ordenar
Precondiciones: Los actores gerencia y supervisor tienen que estar debidamente registrados en Cronos Web para poder ingresar a la aplicación.
Flujo Normal: 1. Los actores ingresaran al sistema2. Los actores visualizaran el tipo de reporte, puede ser tabla o gráfico3. Los actores exportaran(optativo) a Excel los reportes seleccionados4. Los actores filtraran y ordenaran reportes
Flujo Excepcional: En el caso que los actores no puedan visualizar el reporte requerido, se deberán cerrar cesión y volver a ingresar, si sigue el problema recurrir al departamento de soporte para solucionar el inconveniente.
79
Descripción: Inicialmente los actores ingresan al sistema, seleccionan el local, accediendo al
tipo de reporte que desean consultar, estos reportes serán:
Tipo tabla: se despliega un listado de transacciones de cada uno o varios locales optando a la
posibilidad de exportarlos en formato Excel.
Tipo gráfico: se despliega y visualiza un esquema en forma gráfica del comportamiento y
variación de la venta, optando la posibilidad de seleccionar más de un local.
4.2.2.3 Dashboard
En este caso de uso se describe las actividades que el usuario puede realizar con el Dashboard
de los locales. Obtiene los gráficos más importantes para el seguimiento de los locales
administrados por RESTÓ.
80
Caso de Uso - Dashboard
uc CASO DE USO: DASHBOARD
SUPERVISOR
GERENCIA
Visualizar Dashboard
Exportar Excel
DASHBOARD
DESARROLLADOR«include»
Figura 4. 9: Caso de Uso - Dashboard
81
Descripción: Inicialmente se visualiza la vista correspondiente al rol de ingreso, otorgando las
funciones asignadas a éste.
Rol gerencia: visualiza reportes de todos los locales de la compañía
Rol supervisor: visualiza reportes de locales asignados
Figura 4. 10: Flujo - Dashboard
Tabla 4- 3: Indicadores: Dashboard
Nombre Indicadores: Reportes tipo gráfico y tabla
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe las actividades que el usuario puede realizar
con el Dashboard de los locales. Obtiene los gráficos más importantes para el seguimiento
de los locales administrados por RESTÓ.
Actores: Desarrollador, Gerencia, Supervisor.
Función: Visualizar Dashboard, exportar a Excel
Precondiciones: Los actores gerencia y supervisor tienen que estar debidamente registrados en Cronos Web para poder ingresar a la aplicación.
Flujo Normal: 1. Los actores ingresaran al sistema2. Los actores visualizaran Dashboard3. Los actores exportaran(optativo) a Excel el reporte
Flujo Excepcional: En el caso que los actores no puedan visualizar Dashboard, deberán cerrar cesión y volver a ingresar, si sigue el problema recurrir al departamento de soporte para solucionar el inconveniente.
82
Implementación, uso y evaluación:
Los reportes extraídos de la aplicación web, fueron verificados por los expertos del negocio,
aplicando comparaciones con los demás ya existentes, además las consultas ya habían sido
cercioradas en la iteración anterior (Primera Iteración: Construcción Modelo de Datos).
(Ver Figura 4.4)
Criterio de Termino: Para el término de esta iteración el departamento de control y gestión
analizó la información y otorgo la validación para la creación de nuevos indicadores y
reportes.
Pruebas de los informes hacia la compañía, cerciorados por los expertos del negocio junto al departamento de control y Gestión.
Figura 4. 11: Informe compañía.
83
Descripción Figura 4.11: Inicialmente se visualiza la vista correspondiente de las ventas
diarias y acumuladas de cada local.
Descripción: figuras 4.12, 4.13, Se visualiza los correspondientes script hacia el sistema
actual.
Figura 4. 12: Scripts Sistema Actual
Figura 4. 13: Scripts Sistema Actual
84
Figura 4. 14: Scripts Sistema Propio
Re-especificación:
De igual manera que la Primera Iteración, el itinerario presentado no es el definitivo, esté está
diseñado para acomodarse a una evolución temporal o progresiva donde existan redefiniciones
del desarrollo en base a nuevos requerimientos de reportes según la alta gerencia de la
compañía.
Figura 4. 15: Scripts Sistema Propio
85
4.2.3 Tercera iteración: Creación y administración de Mantenedores
Especificación Inicial
Crear un diseño solución e implementación de un componente del software que permita la
reutilización de código, rehusó de funciones, objetos, que se construyen una sola vez y luego
se clonan, construidos a partir de un modelo común.
La creación y administración de un mantenedor es necesaria para hacer alguna modificación
del programa sin necesidad de ingresar directamente al código (componente del software).
Este permitirá agregar, modificar y eliminar registros específicos dentro de la base de datos,
dentro de las aplicaciones que se repetirán con alguna frecuencia son:
Mantenedores simples: aplicaciones de inserción, modificación y borrado de
registros en tablas sin referencias externas y uní-registro en pantalla, por ejemplo,
administración de perfil.
Mantenedores compuestos: aplicaciones de inserción, modificación y borrado de
registros en tablas relacionadas, tipo padre - hijo con pantallas más complejas, del tipo
de encabezado – detalle; grillas multiregistros y pantallas con múltiples pestañas
Módulo de control de acceso: módulo consistente en aplicaciones estándares para el
control de acceso a los programas y datos del sistema en construcción. Constituye un
grupo de rutinas y tablas que permiten habilitar acceso o no a los objetos que formen
parte del sistema.
Aplicaciones transaccionales: aplicaciones de procesamiento masivo sobre tablas de
transacciones, que utilizan tablas maestras y/o de estatus. La estructura de estos
programas son muy similares, independientes de las tablas involucradas. Corresponde
a recorridos masivos, cálculos, copia, etc.
86
Diseño
A continuación se presentaran las herramientas construidas que permitirá la generación
automática de código reutilizando programas, objetos y funciones basadas en estándares esto
es, que contienen toda la experiencia probadas en la empresa, la lógica asociada a la aplicación
que se está construyendo incorporando formatos, acceso de datos, lógica de presentación, etc.,
es decir todo aquello es predecible ya que fue pensado y hecho alguna vez y que no requiere
más que reemplazar las secciones variables por la tupla de valores que se está trabajando en
cada caso particular:
Mantenedor Compuesto
Mantenedor Simple
Mantenedor de Software
87
4.2.3.1 Administración MultiEmpresa (Mantenedor Compuesto)
Caso de Uso – Administración MultiEmpresa
uc CASO DE USO ADMINISTRACION MULTIEMPRESA
ADMINISTRACION MULTI EMPRESA
DESARROLLADOR
Administrar Mantenedor de
Usuarios
Administrar Mantenedor de
Locales
Administar Mantenedor de
Recursos Compartidos
Administrar Mantenedor de
Niveles y Subniv eles
Cambiar Contraseña
Ver Perfil
Administrar Mantenedor de Roles
Cambiar Usuario
«include»
«extend»
Figura 4. 16: Caso de Uso - Administración MultiEmpresa
88
Tabla 4- 4: Flujo Administración MultiEmpresa
89
Nombre Administración MultiEmpresa
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe las actividades que el usuario puede realizar
en la administración MultiEmpresa.
Actores: Desarrollador
Función: Administrar mantenedores de usuarios, locales, recursos compartidos, niveles y subniveles, cambiar contraseña (cambiar usuario) y ver perfil.
Precondiciones: Sin precondición
Flujo Normal: 1. El actor ingresará al sistema2. Se verificará su rol3. El actor visualizara mantenedores4. El actor cambiará contraseña y vera su perfil o el de los demás usuarios
Flujo Excepcional: En el caso que el actor no pueda visualizar los mantenedores y hacer modificaciones, deberá cerrar cesión y volver a ingresar.
90
Descripción: Inicialmente el usuario ingresa al sistema validando su rol correspondiente.
91
Se muestra en pantalla el mantenedor compuesto que contiene todos las administraciones de la
plataforma, tales como: administración de locales y de usuarios, administración de recursos
compartidos, entre otros (Ver figura 4.17).
4.2.3.2 Administración MultiUsuario y MonoUsuario (Mantenedor Simple)
Caso de Uso - Administración MultiUsuario y MonoUsuario
92
Figura 4. 18: Caso de Uso – Administración MultiUsuario y MonoUsuario
Tabla 4- 5: Administración de MultiUsuario y MonoUsuario
Nombre Administración MultiUsuario y MonoUsuario
Fecha 11 de Noviembre 2013
Descripción: En este caso de uso se describe las actividades que el usuario puede realizar
en la administración de la vista MultiUsuario y MonoUsuario.
Actores: Gerencia, Supervisor.
Función: Modificar datos personales (editar perfil, cambiar contraseña), ver perfil.
Precondiciones: Los actores deberán estar debidamente registrados en la base de datos para poder ingresar y hacer modificaciones a su perfil.
Flujo Normal: 1. Los actores ingresaran al sistema.2. Se verificarán los roles correspondientes.3. Los actores visualizarán su perfil.4. Los actores podrán editar su perfil optando a la modificación de datos personales.
como también y contraseña.5. Los Actores verán su perfil modificado y actualizado.
Flujo Excepcional: En el caso de que los actores no puedan ingresar al sistema y no puedan ver su perfil, deberán cerrar cesión y volver a ingresar. Si el problema persiste se deberá recurrir al departamento de soporte para crear usuarios y contraseñas nuevas.
93
Descripción: Inicialmente los usuarios ingresan al sistema validando su rol correspondiente.
Se visualizará en pantalla el mantenedor simple que contiene la administración multi y mono
usuario (Ver figura 4.19). Los usuarios podrán editar su perfil, modificando datos personales
como también podrán optar al cambio de contraseña.
Figura 4. 19: Flujo – Administración MultiUsuario y MonoUsuario
94
4.2.3.3 Actualización de la información
Los datos actuales de la compañía están almacenados en la base de datos del sistema actual
RESTÓ, mediante herramientas se logró sincronizar la información de este, almacenándola en
la nueva base de datos mencionada anteriormente (Primera Iteración), que corresponde a la
nueva plataforma que gestionara los datos.
A continuación se presentara el flujo de la actualización de la información:
Figura 4. 20: Actualización de la Información
Descripción: Inicialmente la base de datos nueva se debe comunicar y sincronizar con la base
de datos actual, para luego rectificar los datos, almacenarlos, verificarlos y respaldarlos, si
95
existe el respaldo se cagará a la base de datos de la nueva plataforma, en el caso de que no
exista respaldo se deben verificar las consultas y la comunicación.
Criterio de término:
Para el término de esta iteración se cercioró que las instrucciones de cada proceso del
mantenedor progresaran correctamente con los criterios estipulados anteriormente
(especificación inicial), se indago con pruebas de cada mantenedor y se evaluó cada uno por
separado.
Re-especificación
Observando estos pasos vemos que el código fuente puede ser reutilizado manteniendo la
estructura que es idéntica y conservando la mayoría del código, generalizando solamente
aquello que difiere entre una tabla y otra, a saber, los nombres de los campos claves y no
claves (usuario y rol).
Una nueva especificación seria integrar una aplicación de lectura y carga tipo batch-input de
registros en un medio externo hacia alguna tabla dentro del sistema
96
4.3 Arquitectura del Diseño
4.3.1 Arquitectura
Para el desarrollo de la plataforma, se utilizará la Arquitectura Cliente/Servidor. Esta
permite distribuir las tareas entre los proveedores de recursos o servicios, llamados servidores,
y los demandantes, llamados clientes.
Al realizar el desarrollo con esta arquitectura la capacidad de proceso está repartida entre los
clientes y los servidores (Ver Figura 4.21), aunque son más importantes las ventajas de tipo
organizativo, debido a la centralización de la gestión de la información y la separación de
responsabilidades, lo que facilita y clarifica el diseño del sistema.
Figura 4. 21: Arquitectura Cliente/Servidor
97
Esta arquitectura, permite realizar la programación en capas, el objetivo principal de esta
programación es separar la lógica del negocio de la lógica del diseño. La principal ventaja de
este estilo de desarrollo es que permite llevar a cabo varias capas, en caso de que se requiera
algún cambio solo se modificará la capa requerida sin afectar a las demás capas.
En el desarrollo de la plataforma se establecerán cuatro capas (Ver Figura 4.22), estas son:
Capa de presentación
Esta capa es la que ve el usuario (también se la denomina "capa de usuario"), es la que
presenta al usuario la información solicitada, siendo la interfaz gráfica y la que
interactúa con los diferentes tipos de usuarios. Esta capa se comunica únicamente con
la capa de negocio.
Figura 4. 22: Capas de la Plataforma
98
Capa de lógica de negocio
Esta capa es donde residen los programas que se ejecutan, se reciben las peticiones del
usuario y se envían las respuestas tras el proceso. Esta capa establece todas las reglas
del negocio que deben cumplirse, además se comunica con la capa de presentación,
para recibir las solicitudes y presentar los resultados, y con la capa de acceso a datos,
para solicitar la información necesaria. También se consideran aquí los programas de
plataforma.
Capa de acceso a datos
Esta capa es la encargada de acceder y obtener los datos desde la capa de datos.
Mediante el uso de LINQ (componente de Visual Studio), utilizando Data Transfer
Object (DTO) y Data Access Object (DAO). Además esta capa se comunica con la
capa lógica para obtener solicitudes y entregar la información para ser utilizada.
Capa de datos
Esta capa es donde se alojan los datos. Está formada por las bases de datos que realizan
todo el almacenamiento, recibe solicitudes de almacenamiento o recuperación de
información desde la capa de acceso a datos.
99
CAPÍTULO 5 PROTOTIPO DE INTERFACES GRÁFICAS Y ANÁLISIS DE FACTIBILIDAD
5.1 Prototipo de Interfaz
A continuación, se presentarán los diseños de las interfaces gráficas propuestas del prototipo funcional basado en una plataforma web.
Figura 5. 1: Vista-Listado de Locales
100
Figura 5. 3: Vista-Reporte de Ventas Tipo Gráfico
Figura 5. 2: Vista-Reporte de Ventas Tipo Tabla
101
Figura 5. 5: Vista-Reportes de Ventas Acumuladas Tipo Gráfico
Figura 5. 4: Vista-Reportes de Ventas Acumuladas Tipo Tabla
102
5.2 Análisis de Factibilidad
5.2.1 Técnica
Técnicamente el desarrollo e implementación es factible. Se busca aprovechar las plataformas
disponibles en la empresa (hardware y software). Se cuenta con los recursos técnicos y
materiales, además de los conocimientos y la experiencia que se requiere para un desarrollo
exitoso. En caso de necesitar nuevos recursos técnicos, la empresa realizará la adquisición de
estos.Tabla 5- 1: Recursos de Hardware requeridos
Recursos de Hardware
Equipo Características
Desarrollo* Intel core 2 Quard Q8300* 3GB de memoria RAM * 320GB de Disco Duro
Servidor de * Intel core 2 Quard Q8300 Aplicaciones * 6GB de memoria RAM
* 6 TB de Disco Duro Otros * Terminales de acceso exterior vía VPN
* Clustering de servicio de dominio ActiveDirectory
Tabla 5- 2: Recursos de Software requeridos
Recursos de Software
Tipo Software
Sistema * Windows Seven Ultimate (Equipo de desarrollo).Operativo * Windows Server 2008 Standard (Equipo Servidor).Desarrollo * Visual Studio 2010 con Microsoft Team Foundation * Office 2010
Base de Datos
* SQL Server 2005
5.2.2 Operacional
103
Operacionalmente es factible. La empresa ha realizado reuniones internas, con el fin de
verificar la factibilidad operacional de la incorporación de una nueva plataforma web, la
plataforma desktop actual debe realizar pruebas de regularización del software, logrando una
sincronización óptima con la nueva plataforma web, ya que es un alto impacto para los
usuarios autorizados de la compañía.
Para la utilización de la plataforma web, no es necesario saber computación avanzada. A pesar
de esto se realizarán las siguientes medidas:
Existirá en la misma plataforma web, documentación y manuales de uso de las
herramientas, videos tutoriales y repuestas a las preguntas realizadas por los usuarios.
Se realizará una capacitación a los usuarios (Clientes del software RESTÓ).
5.2.3 Legal
Legalmente es factible, ya que no existe ningún impedimento legal para el desarrollo de la
plataforma.
Todas las licencias de los software utilizados son originales. Además la empresa
proporcionara la información necesaria para efectuar el desarrollo y la documentación de los
reportes. El código fuente de la plataforma desarrollada será de propiedad de los mismos
desarrolladores de la compañía.
104
5.2.4 Económica
Económicamente es factible, debido que los costos asociados al proyecto (gastos estructurales,
hardware, software, etc.) se encuentran ya disponibles para su utilización.
A continuación en las siguientes tablas se presentan los costos asociados a los recursos
utilizados para el desarrollo del proyecto.
Tabla 5- 5: Costos de Recurso Humano
Tabla 5- 3: Costos de recursos Hardware
Recursos de Hardware
Recursos Costo Original
Costo ObservacionesAnualEquipo de
$ 450.000.- $ 0.-El costo queda como valor cero, debido
Desarrollo interno que la empresa ya disponía del recursoEquipo para
$ 800.000.- $ 0.- El costo queda como valor cero, debidoServidor que la empresa ya disponía del recurso
Total Costo R. Hardware $ 0.-
Tabla 5- 4: Costos de Recursos Software
Recursos de Hardware
Recursos Costo Original
Costo ObservacionesAnualLicencia Visual
$ 323.999.- $ 0.-
El costo queda como valor cero, debido que la empresa ya disponía del recurso
Studio 2010Ultimate
Licencia SQL
$ 720.000.- $ 0.-El costo queda como valor cero, debido que la empresa ya disponía del recurso
Server 2005 Licencia Windows 7
$126.290.- $ 0.-El costo queda como valor cero, debido que la empresa ya disponía del recurso
Profesional Licencia Windows 7
$ 463.190.- $ 0.-
El costo queda como valor cero, debido que la empresa ya disponía del recurso
Server 2008Standard
Total Costo R. Hardware $ 0.-
105
Recurso Humano
Cantidad Recurso CostoObservaciones
1 $ 323.999.-UF 0,072 Costo por Hora
Hombre
Total costo Mes UF 19,44Costo Total Mes =(( CHH*9)*30)
Total costo R. Humano UF 116,64
Costo Total Proyecto =(( CTM*6). Costo Aproximado a un proyecto de 6 meses.
Tal como se describe en las tablas 5.3 y 5.4, los recursos de hardware y de software son sin
costos para el proyecto, debido que estos son heredados de otros proyectos anteriores, además
si se considera la infraestructura, ésta ya se encuentra establecida y en actividad. El costo total
del proyecto es de UF 116,64.- aproximado, que es descrito en la tabla 5.5.
5.3 Matriz de riesgo del proyecto
En la mayoría de las tareas del área de la ingeniería, existen riesgos. Un buen proyecto de
software, puede fracasar debido a los riesgos existentes, es por esto que es fundamental en la
ingeniería de software, poder identificar los riesgos para posteriormente poder realizar planes
de mitigación para estos.
A continuación se presenta en la tabla 3.19 los riesgos asociados al desarrollo de este proyecto.
Tabla 5- 6: Costos de Recursos Humanos
Probabilidad
Riesgo
Baja Media Alta Mitigación
Errores en el servidor de SQL
X buscar soporte o reemplazar el servidor
Errores de inconsistencia en al bases de datos creada para realizar el
X
Levantar solicitud para revisión de inconsistencia al área de sistemas de Rap S.A.
106
proyectoNo contar con toda la información requerida por parte del proveedor del sistema actual
X
Recurrir a las consultas históricas de las herramientas externas creadas por la compañía
No contar con el modelo de datos X
Construir a base de las consultas históricas un nuevo modelo de datos consistentes con el sistema
5.4 Análisis FODA
El análisis FODA (Fortalezas, Oportunidades, Debilidades, Amenazas), es una herramienta
empleada ampliamente en la administración moderna. Consiste básicamente en descubrir
cuáles son los factores ambientales internos (fortalezas y debilidades) y cuáles son los
externos (oportunidades y amenazas) que favorecen o amenazan la realización de un
determinado proyecto, cualquiera sea su naturaleza.
A continuación se realiza el análisis FODA del proyecto:
Fortalezas
La plataforma web entregará resultados actuales y en tiempo real sobre la
gestión y avances de las metas proyectadas, además de un análisis paso a paso
al momento de evaluar y tomar decisiones oportunas para el negocio,
igualmente eliminado la dependencia del personal encargado de los reportes.
Oportunidades
La buena gestión que ha presentado la plataforma desktop en diferentes
empresas, permite la adhesión de nuevos usuarios (clientes).
Debilidades
107
El nuevo modelo de datos, puede no haber considerado todas las necesidades
del modelo original, por no conocer el modelo de datos del sistema actual.
Amenazas
Los administradores de los locales (usuarios), pueden buscar otra solución para
cubrir sus necesidades. Debido que deberán utilizar la nueva herramienta.
5.5 Evaluación y Elección de las Alternativas de Solución
Al realizar la evaluación entre las opciones de solución que se plantearon en el capítulo 1, se
obtiene el siguiente cuadro:
Tabla 5- 7: Especificaciones de las soluciones de desarrollo
ProbabilidadDesarrollo Externo Desarrollo InternoRiesgo
Utilización de tecnologíaVersión 2.0 Versión 2.0
.NET FrameworkCosto de
$4.158.400._ $2.666.664._desarrollo
Mantenimiento de Datos de contratoIndefinido
plataforma 6 mesesrequerimientos
EspecíficosEspecíficos + modificaciones
posteriores a bajo costoalojamiento de
Plataforma Externa + costos Interna + costo
y base de datos consolidados mantenciónNuevos Costo adicional +
Costo Horas hombreRequerimientos costo Horas Hombre
El desarrollo externo permite a la empresa desatender todo lo relacionado a la nueva
plataforma, pero sin embargo al analizar las especificaciones de esta solución a un corto plazo,
los costos son muy elevados en comparación con el desarrollo interno. Además el desarrollo
108
externo no ofrece una tecnología actualizada. En cambio el desarrollo interno permite control
total sobre la plataforma y la base de datos, con lo cual, se puede realizar incorporación y/o
modificaciones de requerimientos, y mejoras de la plataforma manteniendo la calidad y los
costos.
En resumen, la solución más adecuada para satisfacer la necesidad de la empresa, es realizar el
desarrollo internamente.
109
5.6 Beneficios esperados del proyecto
5.6.1 Cualitativos
Facilitar la labor de los administradores de los locales y los supervisores, permitiendo el
control en forma remota del comportamiento diario de las transacciones realizadas en cada
local.
Permitir integrar y compartir información en línea, entre la oficina central, los locales y los
usuarios autorizados que se encuentren fuera de la red de la compañía, mejorando la gestión
interna de la empresa y permitiendo la participación de toda la cadena de abastecimiento
(cliente, proveedores y subcontratistas), así también en el departamento de control de calidad
verificando el control de producción.
Facilitar la visualización de la información, entregándola en forma clara y precisa para la toma
de decisiones, fomentando el mejoramiento continuo.
5.6.2 Cuantitativos
Generar y administrar información histórica de las transacciones de cada local, para ser
consultada en forma ágil cuando se requiera, ahorrando tiempos de espera para obtener la
información requerida, obteniéndolos en tan solo segundos.
110
CAPÍTULO 6 CONCLUSIONES
El desarrollo de este proyecto se realizó siguiendo la metodología Evolutiva-Incremental, la
cual permitió poder desarrollar cada una de las etapa en forma completa y satisfactoria, ya que
permite realizar re-especificaciones en las versiones de desarrollo, logrando obtener como
resultado la
Versión final del prototipo de la plataforma web, cubriendo por completo las necesidades
presentadas por el cliente. También se logró cumplir con los objetivos específicos llevando a
cabo el cumplimiento del objetivo general del proyecto.
Además, durante el análisis y solución del problema, se pudo apreciar que las empresas deben
hacer todo lo posible para garantizar al máximo la continuidad del negocio, por lo que queda
claro que la principal garantía que deben cubrir está ligada estrechamente al factor económico.
Por este motivo las empresas de a poco están tomando conciencia de que una gestión correcta
permite disminuir los costos.
La finalidad principal de haber realizado el desarrollo del proyecto, es garantizar una mejor
utilización de los recursos invertidos por cada empresa, y esto se logra debido a que la
plataforma web realiza la consolidación de la información y la presenta mediante indicadores,
que facilitan a los usuarios y especialmente a la alta gerencia obtener una mejor visión de los
errores cometidos y realizar una correcta toma de decisiones que permitan establecer acciones
correctivas para reducir el impacto del costo de aquellos errores.
Sin duda, la plataforma web posee la gran ventaja de encontrarse en la nube y ser desarrollada
mediante capas, lo que posibilita que en un futuro se realice la migración completa de la
plataforma desktop al ambiente web, permitiendo al usuario un mejor uso del sistema y una
mejor gestión de sus sucursales.
111
ANEXO IREQUERIMIENTOS DE LA PLATAFORMA
CRONOS WEB
112
DOCUMENTACIÓN DE REQUERIMIENTOS
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTOSISTEMA WEB DE GESTIÓN Y CONTROL DE LA INFORMACIÓN COMERCIAL DE SCHOPDOG (CRONOS WEB)
SWGCICS
NECESIDAD DEL PROYECTO U OPORTUNIDAD DE APROVECHAR: Describir las limitaciones de la situación actual y las razones por las cuáles se emprende el proyecto.
Generar un módulo de gestión que permita obtener acceso libre a la información de la compañía
OBJETIVO DEL PROYECTO: Describir los objetivos del proyecto Desarrollar e implementar un prototipo funcional que se integre a la base de datos
de RESTÓ, realizando la consolidación de la información referente a la compañía
generando libre acceso a los datos gestionados por esta plataforma, mediante el
despliegue de indicadores y reportes.
REQUERIMIENTOS FUNCIONALES: Describir los requerimientos funcionales del proyecto.
EMPRESA
PRIORIDAD
REQUERIMIENTOS
CÓDIGO
REQUERIMIENTO
DESCRIPCIÓN
RAP S.A
Muy alto RF-001 Construir y validar modelo de datos
relacional.
Se Solicita el modelamiento de la base de datos relacional, que mantendrá los datos obtenidos desde RESTÓ.
Muy alto RF-002 Roles de Usuario
Se solicita el diseño de tres Roles de usuarios, que permitan la visualización de los indicadores dependiendo de su jerarquía.
Muy alto RF-003 Creación de Roles3 tipos.
Se solicita la creación de roles, para ser asignadas a los usuarios. Determinando la función que el usuario presenta dentro de la Empresa.
113
RAP S.A.
Muy alto RF-004
Generación de indicadores tipo:
Grafico
Tabla
Se solicita la generación de indicadores, que proporcionen la información relevante para cada local, administrado por RESTÓ.
Muy alto RF-005 Exportación a Excel Se solicita la posibilidad de realizar la exportación de la información entregada por cada indicador.
Muy alto RF-006 Generación de mantenedores
Se solicita la generación de mantenedores, para obtener una mejor administración de la plataforma.
Muy alto RF-007Generación de
listados de las ventas diarias y acumuladas
Se solicita la generación de listados con los datos relevantes de los locales administrados.
REQUERIMIENTOS NO FUNCIONALES: Describir los requerimientos no funcionales del proyecto
EMPRESA PRIORIDAD CÓDIGOREQUERIMIENTOS
REQUERIMIENTO DESCRIPCIÓN
RAP S.A.
Medio RNF-001 Banner personalizadoSe solicita la personalización del banner que presenta la Plataforma.
Muy alto RNF-002Formato de la
plataforma
Se solicita realizar un formato adecuado para la Plataforma, manteniendo la gama de colores de RESTÓ.
Muy alto RNF-003 Respaldo del equipo servidor
Se indica la posibilidad de obtener algún método que permita respaldar el software y los datos almacenados en el equipo servidor.
114
RESTRICCIONES: Describir las Restricciones del proyecto
EMPRESA PRIORIDAD
CÓDIGOREQUERIMIENTOS
REQUERIMIENTO DESCRIPCIÓN
RAP S.A.
Muy alto RES-001 Validación Acceso de Usuario
Los usuarios del software no podrán acceder sin una Identificación proporcionada por una combinación de usuario y contraseña.
Muy alto RES-002 Eliminación de Datos
Eliminación de los datos ingresados al sistema será de responsabilidad del usuario con privilegios en el software
115
Carta de aceptación de Requerimientos
116
ANEXO IIPRESENTACIÓN DE LA PLATAFORMA
CRONOS WEB
117
Figura Anexo 2.1: Interfaz – Inicio.
Figura Anexo 2.2: Interfaz – Listado de sucursales.
118
Figura Anexo 2.3: Interfaz – Datos sucursal.
Figura Anexo 2.4: Interfaz – Datos sucursal Reportes.
119
Figura Anexo 2.5: Interfaz – Gráfico Ventas sucursal.
Figura Anexo 2.6: Interfaz – Tabla Ventas sucursal.
120
Figura Anexo 2.7: Interfaz – Exportación a Excel datos tablas.
Figura Anexo 2.8: Excel
121
ANEXO IIIPRESENTACIÓN COTIZACIÓN SISTEMA RESTÓ
(VERSIÓN ACTUAL)
