Proyecto de Tesis Sistema Restaurant
54
1 Especificación de Gestión y Diseño Sistema Carta Virtual Administración de Restaurants Profesor a Cargo: Juan Pablo Zuñiga Integrantes de este Trabajo: Jonathan Durán Francisco Mendoza Claudio Jara Curso: Taller de Proyecto de Software - Sección 379 Fecha:
description
Proyecto de Tesis Sistema Restaurant
Transcript of Proyecto de Tesis Sistema Restaurant
1
Especificación de Gestión y Diseño Sistema Carta Virtual Administración de Restaurants
Profesor a Cargo: Juan Pablo Zuñiga
Integrantes de este Trabajo:
Jonathan Durán Francisco Mendoza
Claudio Jara
Curso: Taller de Proyecto de Software - Sección 379
Fecha:
2
08 de Junio 2015
Versión Fecha Revisión Descripción de la Revisión Autor
<1.0> 01-04-2015 Se crea documento SoftBuilder
<1.8> 08-06-2015 Modificación del documento para agregar nuevos requerimientos.
SoftBuilder
Fecha
Aprobación
Aprobador Rol/Cargo Firma
Proyecto SB – Administración de Restaurant
ID Documento SW-PRJ-01 Estado En Construcción Versión 1.8
Nombre Documento Acta de constitución de proyecto
Autor SoftBuilder Fecha 01/04/2015
3
CONTENIDO
PROPÓSITO ................................................................................................................... 6
DESCRIPCIÓN DEL USUARIO ........................................................................................... 6
IDENTIFICACIÓN ........................................................................................................................ 6
ANTECEDENTES ......................................................................................................................... 7
ORGANIGRAMA ........................................................................................................................ 8
CONTEXTO PROYECTO ................................................................................................................ 9
MARCO REFERENCIAL .................................................................................................. 10
MENÚON ............................................................................................................................. 10
EASYPOS .............................................................................................................................. 10
MARCO TEÓRICO CONCEPTUAL ................................................................................... 12
DEFINICIÓN Y DESCRIPCIÓN DEL MERCADO OBJETIVO ................................................. 13
SITUACIÓN ACTUAL ..................................................................................................... 14
IDENTIFICACIÓN DEL PROBLEMA ................................................................................................. 15
IMPACTO ASOCIADO ................................................................................................................ 15
MISION Y VISION ..................................................................................................................... 16
REQUERIMIENTOS FUNCIONALES ................................................................................ 17
REQUERIMIENTOS DE VENTAS .................................................................................................... 17
REQUERIMIENTOS DE ADMINISTRACIÓN ....................................................................................... 19
REQUERIEMINTOS DE GESTIÓN ESTRATÉGICA................................................................................ 21
REQUERIMIENTOS NO FUNCIONALES........................................................................... 22
PERFORMANCE ...................................................................................................................... 22
SEGURIDAD DE LA INFORMACIÓN ............................................................................................... 22
RESTRICCIONES ....................................................................................................................... 23
ALCANCES ............................................................................................................................. 24
USABILIDAD ........................................................................................................................... 24
LICENCIAS .............................................................................................................................. 24
COSTOS ASOCIADOS AL PROYECTO .............................................................................. 25
ESTUDIO DE FACTIBILIDAD........................................................................................... 26
CARTA GANTT ............................................................................................................. 27
4
ANÁLISIS DE MERCADO ............................................................................................... 28
CICLO DE VIDA Y METODOLOGÍA DE DESARROLLO ....................................................... 30
VENTAJAS ............................................................................................................................. 30
BPMN PROCESO DE VENTA .......................................................................................... 31
RIESGOS ...................................................................................................................... 32
METODOLOGÍA DE GESTIÓN DE RIEGOS ...................................................................................... 33
IDENTIFICACIÓN Y ANÁLISIS ....................................................................................................... 34
IMPACTO .............................................................................................................................. 39
PLAN DE RESPUESTA ................................................................................................................ 40
MONITOREO Y CONTROL LOS RIESGOS ........................................................................................ 43
MATRIZ DE RIEGOS ................................................................................................................. 43
RIEGOS EN EL AMBIENTE DEL CLIENTE ......................................................................................... 44
PROCESOS COBIT SOBRE GESTIÓN DE LOS RIEGOS........................................................................ 44
DS5.4 Administración de cuentas del usuario ................................................................ 44
DS5.5 Pruebas, vigilancia y monitoreo de la seguridad ................................................. 44
DS5.8 Administración de llaves criptográficas ............................................................... 44
DS5.9 Prevención, detección y corrección de software malicioso ................................. 45
DS5.10 Seguridad de la red ............................................................................................ 45
1.1 ANÁLISIS DE RIESGOS. ........................................................................................ 45
MODELO DE BASE DE DATOS ....................................................................................... 49
MODELO CONCEPTUAL ............................................................................................................ 49
MODELO LÓGICO .................................................................................................................... 50
MODELO FISICO ................................................................................................................... 51
SISTEMA DE GESTIÓN DE LA BASE DE DATOS ............................................................... 52
MYSQL ................................................................................................................................. 52
CARACTERÍSTICAS. .................................................................................................................. 52
¿PORQUE ELEGIR MYSQL? ....................................................................................................... 52
MECANISMOS DE MONITOREO .................................................................................... 53
TABLA 1 : ORGANIGRAMA. ........................................................................................................................................ 8
TABLA 2: BENCHMARKING COMPARATIVO. ................................................................................................................. 11
TABLA 3: REQUERIMIENTOS DE VENTAS. .................................................................................................................... 17
TABLA 4: REQUERIMIENTOS DE CONSULTA CLIENTE. ..................................................................................................... 18
5
TABLA 5: REQUERIMIENTOS DE VENTAS. .................................................................................................................... 18
TABLA 6: REQUERIMIENTOS DE CAJA. ........................................................................................................................ 19
TABLA 7: REQUERIMIENTOS DE USUARIOS. ................................................................................................................. 19
TABLA 8: REQUERIMIENTOS DE RECETAS. ................................................................................................................... 20
TABLA 10: REQUERIMIENTOS DE HORARIOS Y PRECIOS. ................................................................................................. 21
TABLA 11: REQUERIMIENTOS DE REPORTES. ............................................................................................................... 21
TABLA 12: ANÁLISIS DE RIEGOS................................................................................................................................ 47
IMAGEN 1: ORGANIGRAMA. ............................................................................................................ 8
6
PROPÓSITO
En la actualidad, la creciente tecnología ha dado soporte para que distintos dispositivos
puedan ser utilizados en diversas clases de negocios. Sin embargo los restaurant
mantienen procesos lentos por la falta de tecnología en sus procesos que conlleva a una
experiencia o servicio deficientes para los clientes.
Frente a esta situación, el presente proyecto plantea una solución orientado a mejorar los
procesos de atención, pago y administración a través de una solución web, que permitirá
a clientes y empleados poder acceder a una rápida atención, llevando la experiencia del
cliente a altos estándares.
DESCRIPCIÓN DEL USUARIO
IDENTIFICACIÓN
La gama de perfiles que se encuentra en el ambiente de restaurant es muy diversa, y
puede variar desde una persona que no posee ningún conocimiento en sistemas
informáticos hasta usuarios muy avanzados. Para ofrecer un buen servicio y abarcar la
mayor parte de la población, la aplicación deberá ser intuitiva y visualmente llamativa
para los usuarios con bajos conocimientos; y a su vez robusta y segura para los usuarios
que poseen mayores conocimientos, con el fin de ofrecer un servicio adecuado a sus
características o necesidades.
Además de los usuarios, también se debe considerar a los garzones, quienes son clave, en
el caso que el cliente no requiera (quiera o solicite) ser atendido mediante la opción del
sistema.
7
ANTECEDENTES
SoftBuilder tiene sus inicios en el año 2014 con la unión de tres socios, quienes teniendo
la informática como visión de futuro forjan una alianza centrada en tres grandes áreas de
especialización: poder de análisis, gestión de proyectos y desarrollo de sistemas.
Estas áreas de especialización, unido a la calidad de los productos y servicios mediante
una política de precios competitiva, amplios conocimientos del mercado tecnológico y
junto a la aplicación de conocidos paradigmas de análisis y desarrollo de sistemas, lleva a
que SoftBuilder, a pesar de su corto lapso de vida, se posicione en un buen lugar dentro
del mercado nacional, con sistemas que prestan un valor agregado a los mercados en el
cual se ofrecen los productos, tales como: Retails, Resturants, Oficinas de Administración
y Contables, entre otros.
Actualmente se cuenta con un excelente equipo de profesionales con verdadera vocación
de servicio en el área de la informática y un exclusivo desarrollo orientado al cliente, lo
cual permite ofrecer un producto integral de muy alta calidad.
8
ORGANIGRAMA
El organigrama estructural de la empresa:
Imagen 1: Organigrama.
Tabla 1 : Organigrama.
Cargo en el Proyecto Nombre Cargo en la Organización
Ingeniero en Informática
Jonathan Durán Gerente de Proyectos
Ingeniero en Informática
Francisco Mendoza Gerente Comercial [email protected]
Ingeniero en Informática
Claudio Jara Gerente De Desarrollo
9
CONTEXTO PROYECTO
El contexto que se le otorga a este proyecto, radica en utilizar tecnología de punta que
permita al restaurant sobresalir sobre su competencia a través de un servicio eficiente, lo
que se traducirá en un mayor aumento de clientes y por consiguiente de sus ventas y
utilidades. Para esto, surge la necesidad de automatizar el proceso básico de servicio, que
es la atención de garzón-cliente, el cual hasta el día de hoy se ha realizado siempre de
forma manual.
Una de las principales características para esta automatización, es otorgarle al cliente una
herramienta que le permita navegar y visualizar en línea, todos los productos que el
restaurant ofrece y que actualmente se encuentran en stock, añadiendo un detalle de lo
que contiene dicho producto. Una vez que el cliente tenga claro lo que quiere solicitar,
podrá mediante la herramienta, realizar el pedido de dichos productos.
Con esto se logra minimizar la intervención humana, y se obtiene una atención más
rápida, ágil y sin porcentaje de error, como los presentados en la actualidad. Por ejemplo:
error del garzón al anotar un pedido, retraso de atención por perdida de comandas,
cobros adicionales por concepto de cruza de comandas, entre otros.
10
MARCO REFERENCIAL
El siguiente apartado busca dar a conocer algunos antecedentes empíricos con respecto al
producto a desarrollar, la importancia de estos datos radica en la entrega de información
sobre diversos productos que ya existen en el mercado, emanados del despliegue de
diversas empresas de desarrollo de software. En primera instancia tenemos a:
MENÚON
La carta digital MenúOn es una aplicación construida por la empresa de desarrollo
llamada REDSHIO2E, la cual funciona bajo conectividad web y es accesible desde distintos
soportes como un Tablet, computador o teléfono móvil.
Su característica principal es la generación de pedidos de mesa y pasarlos directamente a
cocina y solo está limitado a mostrar el menú, sin tener mayor gestión en la
administración.
EASYPOS
EasyPos es una solución de punto de venta y administración desarrollada por la empresa
METHODO, que tiene el fin de controlar y administrar el negocio.
Su característica principal es la integración de varias herramientas
Los dos sistemas se exponen para poder realizar una comparación y determinar cuáles son
las características y requerimientos mínimos que debe tener el sistema, y desde esa base
poder innovar en el sistema a crear (Carta Virtual).
A continuación se ilustra gráficamente una tabla comparativa o Bechmarking:
11
Requerimiento de Ventas Menú On Easy Post Carta
Virtual
Visualización de las mesas en cada punto de venta
X X X
Varios consumos por mesa
X X
Acceso al sistema con cuentas diferenciadas con perfil X X X
Ventas asociadas a mesas individuales por garzón
X X X
Transferencias de clientes entre mesas
X X X
Eliminación de transacciones con código de autorización
X X
Selección de acompañamientos
X X X
Pagos individuales y total con o sin cierre de mesa
X X
Manejo de diferentes tipos de pago
X X X
Descuentos con código de autorización
X X X
Modulo de reserva
X
Elección de consumos directamente por clientes
X
Revisión o consulta de valor consumido, desde cualquier dispositivo móvil
X
Adición y sustracción de ingredientes opcionales.
X
SLA de espera mostrado en los dispositivos (opcional)
X
% de cumplimiento 47% 67% 100%
Requerimiento de Administración Menú On Easy Post Carta
Virtual
Cuadratura de caja
X X X
Modulo de administración de usuarios con perfil de ingreso X X X
Modulo de administración de insumos, recetas y bodegas X X X
Transferencia de insumos entre bodegas
X X
Modulo de administración de horarios y precios
X X X
Incluir instrucciones a los centros de producción
X X
Control de Stock
X X X
Generación automática de auditorias
X
SLA adaptable al número de personal disponible
X
Modulo de dotación de personal
X
% de cumplimiento 50% 70% 100%
Requerimiento de Gestión Estratégica Menú On Easy Post Carta
Virtual
Generación de reportes
X X X
Buscador de datos específicos
X X X
% de cumplimiento 100% 100% 100%
% de cumplimiento total 66% 79% 100%
Tabla 2: Benchmarking comparativo.
12
MARCO TEÓRICO CONCEPTUAL
Software: “es una palabra que proviene del idioma inglés, pero que gracias a la
masificación de uso, ha sido aceptada por la Real Academia Española. Según la RAE, el
software es un conjunto de programas, instrucciones y reglas informáticas que permiten
ejecutar distintas tareas en una computadora”. Definicion.de. (2015). Definición de
Software. 2015, de Definicion.de Sitio web: http://definicion.de/software/
Tablet: es una computadora (ordenador) portátil más grande que un Smartphone pero
más pequeña que una Netbook. Se caracteriza por contar con pantalla táctil: esto quiere
decir que para utilizar la Tablet no se necesita mouse (ratón) ni teclado.
Firewall: “Un cortafuegos es una parte de un sistema o una red que está diseñada para
bloquear el acceso no autorizado, permitiendo al mismo tiempo comunicaciones
autorizadas. Se trata de un dispositivo o conjunto de dispositivos configurados para
permitir, limitar, cifrar, descifrar, el tráfico entre los diferentes ámbitos sobre la base de
un conjunto de normas y otros criterios”. Ingham, Kenneth. (2002). Cortafuegos. 2015, de
Wikipedia Sitio web: http://es.wikipedia.org/wiki/Cortafuegos
GNU: GNU es un sistema operativo tipo Unix desarrollado por y para el Proyecto GNU.
Está formado en su totalidad por software libre
Benchmarking: Consiste en tomar "comparadores" o Benchmarks a aquellos productos,
servicios y procesos de trabajo que pertenezcan a organizaciones que evidencien
las mejores prácticas sobre el área de interés, con el propósito de transferir el
conocimiento de las mejores prácticas y su aplicación. El Benchmarking “es una técnica
para buscar las mejores prácticas que se pueden encontrar fuera o a veces dentro de la
empresa, en relación con los métodos, procesos de cualquier tipo, productos o servicios,
siempre encaminada a la mejora continua y orientada fundamentalmente a los clientes”.
El benchmarking implica aprender de lo que está haciendo el otro y entonces adaptar sus
propias prácticas según lo aprendido, realizando los cambios necesarios, no se trata
solamente de copiar una buena práctica, sino que debe de efectuarse una adaptación a las
circunstancias y características propias. Muñoz, Leiva. (2003). Benchmarking. 2015, de
Wikipedia Sitio web: http://es.wikipedia.org/wiki/Benchmarking
13
DEFINICIÓN Y DESCRIPCIÓN DEL MERCADO OBJETIVO
Variables demográficas
A continuación se listan las principales variables demográficas que se utilizaran para
definir el mercado objetivo:
Edad
Se considera que el rango de edad que se apuntaría es entre los 18 y 40 años, ya que son más adeptos a la tecnología, por lo que tendrían una aceptación normal a la iniciativa de que puedan solicitar por ellos mismo sus consumos a través del dispositivo móvil.
Ocupación
Estudiantes de universidades, institutos profesionales y centros de formación técnica como también trabajadores.
Lugar de Residencia
Zona oriente de Santiago específicamente en las comunas de providencia, las condes, Vitacura y lo Barnechea.
Nivel socioeconómico
ABC1, C2, C3
Incorporando otras variables más cualitativas al análisis, se segmentara el mercado
objetivo para brindar una oferta de mayor valor. Esto repercutirá positivamente en la
rentabilidad del negocio.Para ello se contemplara las siguientes características:
Costumbres Intereses Estilo de vida Comportamiento de compra
Por lo tanto, el mercado objetivo que apuntara el proyecto será:
Hombres y mujeres de entre 18 y 40 años, que residan en la zona oriente de la ciudad de
Santiago y que tengan nivel socioeconómico medio-alto. Con una segmentación
determinada por sus costumbres, intereses, estilo de vida y comportamiento de compra ,
siendo la zona oriente de Santiago donde existen costumbres, intereses y estilos de vida
orientados a la vida nocturna y a su vez existe un mayor grado de comportamientos de
compras.
14
SITUACIÓN ACTUAL
Existen varios tipos de servicios en los restaurantes, según la forma de preparar, presentar
y servir los bebestibles y alimentos.
Actualmente en Chile unos de los servicios más utilizados es el “Servicio Emplatado”
donde el mesero trae el plato preparado desde la cocina, a veces tapados con
“campanas”, y los sirve al comensal por la derecha.
Los restaurantes en Chile cada vez son más y de mayor tamaño, donde llevar la
administración no es nada simple. Los dueños optan por diferentes modalidades para
aquello, variando según el presupuesto del restaurant o simplemente las decisiones de
los dueños.
Nos encontramos con la situación más tradicional o clásica que es la atención donde todo
el trabajo lo realiza el personal del restaurant, y por otro lado una un poco más apegada a
la tecnología que de igual manera lo realiza el mismo personal pero apoyándose con
alguno de los software de gestión y administración ya existentes en el mercado para
restaurantes.
15
IDENTIFICACIÓN DEL PROBLEMA
En la actualidad la creciente tecnología ha dado soporte para que distintos dispositivos
puedan ser utilizados en diversas clases de negocios.
Nosotros hemos observando que en los restaurantes se mantienen de alguna manera con
los software de administración y gestión existentes de restaurantes que si bien cumplen
con lo requerido, carecen de tecnología innovadora, como procesos lentos que conllevan
a una experiencia deficiente del servicio para los clientes, asimismo sistemas antiguos y no
actualizables.
Descripción de la solución: Para ello plantearemos una solución orientada a mejorar los
procesos de atención, pago y administración a través de una aplicación web, que permitirá
tanto a los clientes como a los empleados poder acceder a una rápida atención llevando
su experiencia a altos estándares.
IMPACTO ASOCIADO
La implementación de la solución tendrá varios impactos tanto en los clientes como en la
administración del Restaurant.
Uno de ellos será la innovación, si bien los clientes ya han visto como los meseros
interactúan con software de atención en restaurantes, esta vez se lograra una nueva
forma de ser atendidos. Utilizando la tecnología de de dispositivos móviles para
interactuar con ellos de una manera rápida y eficaz.
El cliente tendrá opciones que nunca antes ha experimentado. Alguna de estas será
transferencia y/o separación de cuentas, consulta de consumo a través de cualquier
Smartphone, entre muchas características nuevas, logrando en los consumidores un alto
grado de aceptación con la calidad y rapidez de atención. Gracias a esto, el Restaurant
aumentara su prestigio y será cada vez más concurrido.
La administración del Restaurant no se queda atrás, sino todo lo contrario. El sistema
contará con módulos BackOffice especialmente diseñados para ese cometido, que llevará
la contabilidad del negocio de una manera fácil, ordenada y clara, donde los
administradores podrán generar informes, gestionar y administrar de una manera mucho
más simple y completa.
16
MISION Y VISION
Misión
Satisfacer las necesidades del mercado, integrando soluciones tecnológicas, con altos
estándares de calidad de servicios, metodologías y flexibilidad. Manteniendo un constante
aprendizaje de nuevas tecnologías con el fin de entregar un servicio de la más alta calidad.
Visión
Ser líderes en la integración de tecnologías de punta que permitan a nuestros clientes
optimizar sus procesos de negocios en tiempo real, mejorando la toma de decisiones
operacionales. Implementando tecnologías flexibles y escalables, que reducen costos,
mejora el control operativo y la rentabilidad del negocio.
17
REQUERIMIENTOS FUNCIONALES
El estudio de mercado realizado y resumido en el marco teórico determinó cuales son los
requerimientos mínimos que debe tener el sistema para poder igualar las condiciones que
existen actualmente en el mercado. Adicionalmente se implementaran nuevos
requerimientos que generen la innovación incremental que tendrá el sistema.
REQUERIMIENTOS DE VENTAS
Id <req01> Versión <1.0>
Nombre Corto Requerimiento
Módulo de ventas
Configuración del Requerimiento
Se necesita módulo de ventas que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Visualización de las mesas en cada punto de venta. 3. Ventas asociadas a mesas individuales por garzón. 4. Elección de consumos directamente por clientes. 5. Varios consumos por mesa.
6. Selección de acompañamientos.
7. Adición y sustracción de ingredientes.
8. Mostrar el SLA de atención parametrizado
9. Revisión o consulta del consumo en línea con el servidor a través del celular del cliente.
10. Transferencias de clientes entre mesas.
11. Solicitud de pago individual o total con o sin cierre de mesa. 12. Manejo de diferentes tipos de pago.
13. Eliminación de transacciones con código de autorización. 14. Descuentos con código de autorización.
Tabla 3: Requerimientos de ventas.
18
Id <req02> Versión <1.0>
Nombre Corto Requerimiento
Módulo de consulta de cliente
Configuración del Requerimiento
Se necesita módulo de consultas de cliente que permita:
1. Logeo con código por parte del cliente.
2. Revisión o consulta del consumo en tiempo real. 3. Mostrar el SLA de atención parametrizado
Tabla 4: Requerimientos de consulta cliente.
Id <req03> Versión <1.0>
Nombre Corto Requerimiento
Módulo de reservas
Configuración del Requerimiento
Se necesita módulo de reservas que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Visualización de las mesas
3. Registro de reservas.
4. Modificación de estado de reserva.
Tabla 5: Requerimientos de ventas.
19
Id <req04> Versión <1.0>
Nombre Corto Requerimiento
Módulo de caja
Configuración del Requerimiento
Se necesita módulo de caja que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Visualización de las mesas.
3. Pagos individuales y total de mesas.
4. Impresión de boletas
5. Cuadratura de caja
Tabla 6: Requerimientos de caja.
REQUERIMIENTOS DE ADMINISTRACIÓN
Id <req05> Versión <1.0>
Nombre Corto Requerimiento
Módulo de usuarios
Configuración del Requerimiento
Se necesita módulo de usuarios que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Insertar, Modificar usuarios.
3. Cambiar estado de usuarios.
4. búsqueda de usuarios.
5. Asignación de perfiles
Tabla 7: Requerimientos de usuarios.
20
Id <req06> Versión <1.0>
Nombre Corto Requerimiento
Módulo de recetas
Configuración del Requerimiento
Se necesita módulo de recetas que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Insertar, Modificar recetas.
3. Cambiar estado de recetas.
4. búsqueda de recetas.
Tabla 8: Requerimientos de recetas.
Id <req07> Versión <1.0>
Nombre Corto Requerimiento
Módulo de bodega
Configuración del Requerimiento
Se necesita módulo de bodega que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Insertar, Modificar insumos.
3. Cambiar estado de insumos
4. búsqueda de insumos.
5. Control de Stock
6. Transferencia de insumos entre bodegas.
Tabla 9: Requerimientos de bodega.
21
Id <req08> Versión <1.0>
Nombre Corto Requerimiento
Módulo de horarios y precios
Configuración del Requerimiento
Se necesita módulo de bodega que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Insertar, Modificar horarios y precios.
3. Cambiar estado de horarios y precios
4. búsqueda de horarios y precios.
Tabla 9: Requerimientos de horarios y precios.
REQUERIEMINTOS DE GESTIÓN ESTRATÉGICA
Id <req08> Versión <1.0>
Nombre Corto Requerimiento
Módulo de reportes
Configuración del Requerimiento
Se necesita módulo de auditorías que permita:
1. Acceso al sistema con cuentas diferenciadas con perfil. 2. Generación de reportes con información de ventas. 3. Generación de reportes de auditorías.
Tabla 10: Requerimientos de reportes.
22
REQUERIMIENTOS NO FUNCIONALES
PERFORMANCE
El producto de software no tendrá mucha demanda con respecto a las transacciones, ya
que los restaurant cuentan con un cupo limitado de clientes simultáneos y este numero de
transacciones no es significativa para su funcionamiento, por lo tanto no se requiere un
alto rendimiento con respecto a la capacidad de carga, tiempo o volumen de
transacciones por minuto , pero si debe ser tolerante a fallas, superar cualquier
inconveniente técnico, logrando mantener la integridad de los datos y manteniéndose
activa durante alguna posible falla.
El sistema tendrá los las siguientes características:
Operatividad: la capacidad de la aplicación para que sus usuarios operen y controlen los
procesos que realiza.
Tolerancia a fallas: es la habilidad que tiene la aplicación para mantener un nivel
específico de funcionamiento en caso de fallas.
Rendimiento: especifica qué tan bien o qué tan rápido, debe la aplicación ejecutar una
función dada en términos de:
Velocidad (tiempo promedio de acceso a datos)
Tiempo (demanda de tiempo real)
SEGURIDAD DE LA INFORMACIÓN
El sistema debe satisfacer los pilares fundamentales de la seguridad de la información:
Confidencialidad: Asegurar que la información sea accesible solo para aquellos usuarios autorizados.
Integridad: Salvaguardar que la información y los métodos de procesamiento sean exactos y completos.
Disponibilidad: Asegurar que los usuarios autorizados tengan acceso a la información y bienes asociados cuando lo requieran.
Para lograr este cometido, el sistema incorporará diversas capas de seguridad, tanto a nivel de Software como de Hardware entre las que se encuentran:
23
o Sistema de Administración con roles de usuario. Este sistema será de uso
interno por parte del restaurant, y deberá filtrar según cargos el acceso a la información confidencial del restaurant.
o Menú virtual en la Tablet, que será la cara visible frente cliente. Aquí se incluirá
una capa de presentación básica pero robusta, en donde el cliente solamente podrá realizar una navegación dentro de la carta y realizar la selección de los productos que desea consumir, con el fin de no permitir la digitación de datos con el fin de descartar el ingreso de datos no válidos.
o Seguridad a nivel de hardware, el cual incluye bloqueo por MAC, para evitar el
acceso de dispositivos indebidos al sistema.
RESTRICCIONES
A continuación, se listarán puntos los cuales están considerados como restricción dentro
del sistema CartaVirtual:
- El sistema se prestará al cliente como un recurso en arriendo, por ende cualquier intento de modificación o sustracción del sistema será motivo para dar fin al contrato.
- El sistema no contempla ninguna funcionalidad adicional, salvo las ya establecidas en
el diseño original del sistema. En caso contrario se negociará como proyecto de modificación.
- El sistema y su seguridad, está dado para ser trabajado en una plataforma Web bajo
Intranet, y no Internet. Por ende su publicación en la web será completamente responsabilidad del cliente.
- El sistema no considera el uso de otras alternativas de base de datos.
- Los productos presentados en CartaVirtual serán de exclusiva responsabilidad del
cliente, por ende SoftBuilder no se hace responsable de lo expuesto ante el cliente.
- Se ejecutará solamente en navegadores que hayan sido auditados y aprobados por
SoftBuilder para el correcto funcionamiento del sistema, en caso contrario no se asegura su correcto funcionamiento.
24
ALCANCES
CartaVirtual tiene los siguientes alcances, que debe contar la versión que final, que será
entregada al cliente.
1- Suministrar un terminal central para la implementación de la base de datos.
2- Suministrar el producto de software.
3- Suministrar equipos móviles (Tablet).
4- Configuración de la red inalámbrica.
USABILIDAD
El producto de software debe contar con un alto grado de usabilidad para que sus
usuarios puedan realizar pedidos y administración de sitio sin dificultad, logrando el éxito
de las transacciones.
LICENCIAS
El sistema deberá funcionar sin necesidad de adquirir ningún tipo de licencia de ejecución,
o cualquier otro software específico. Será administrado y desarrollado bajo sistemas de
Software Libre GNU, somo son:
- Sistema Operativo Linux - Versión UBUNTU 14.0.
- Lenguaje de Programación PHP 5 con Symfony MVC.
- Motor de base de datos MySQL Community Server.
25
COSTOS ASOCIADOS AL PROYECTO
El costo asociado al proyecto es el siguiente:
Dentro de las comunas que pertenecen al sector oriente de Santiago, dentro de las cuales
podemos nombrar: LA REINA, LAS CONDES, ÑUÑOA, PROVIDENCIA, VITACURA, existen un
total de 1.100 restaurants. (Dato informado desde http://www.censodecomercio.cl/)
Para ello, la demanda esperada será de 110 restaurants.
Por ende el cálculo mensual esperado para el producto es de: 1,75 UF * 110 (DE) = 176 UF
mensuales.
Por consiguiente, el costo del proyecto se estaría pagando al primer año del proyecto.
Valores Calculados en base a UF: 24.909,55 del 01 de junio 2015.
Costos Asociados al Proyecto Carta Virtual
Tiempo de desarrollo del Proyecto 12 Meses
Personal Asociado al Proyecto
Costo Neto Costo Bruto Meses en Proyecto Total
Programador Freelance 400.000 480.000 8 3.840.000
Programador Senior 600.000 720.000 12 8.640.000
Analista de Sistemas 800.000 960.000 1 960.000
Ingeniero de Sistemas 1.100.000 1.320.000 1 1.320.000
Costo Total Proyecto 14.760.000
Tiempo de Desarrollo 12 Meses
Tiempo estimado Estudio Proyecto 5 Años
Costo Mensual Proyecto en 1 año 1.230.000
Costo de Inversión Anual Min. 246.000
Costo Asociado al Proyecto 20.500 Valor Base UF 0,82
Soporte 0,40
Software 0,50
% Ganancia Mensual 3,5%
Valor Mensual: 1,75
26
CONCEPTO Costo Inicial 1 2 3 4 5
Ingresos 4.800.000 9.600.000 9.600.000 14.400.000 14.400.000
Egresos 1.500.000 2.000.000 2.000.000 3.500.000 3.500.000
Flujo de caja -20.000.000 3.300.000 7.600.000 7.600.000 10.900.000 10.900.000
VAN
55.814.079
TIR
24%
Primer año ingresos y egresos basados en 1 cliente.
Segundo y tercer año ingresos y egresos basados en 2 cliente.
Cuarto y quinto año ingresos y egresos basados en 3 cliente.
Costo inicial calculado en base a gastos de desarrollo más equipamiento.
ESTUDIO DE FACTIBILIDAD
Carta virtual se dirigirá al mercado objetivo que tendrá las siguientes características:
Restaurantes del sector oriente de Santiago que carezcan de innovación tecnológica o requieran implementar un software para llevar su negocio.
SoftBuilder pretende atraer clientes mediantes algunas estrategias de marketing y promoción. De las cuales serán las siguientes:
Visitas en terreno o reuniones: Se visitarán presencialmente restaurantes consiguiendo reuniones con los administradores o dueños para a través de una presentación formal se les dará a conocer nuestro producto.
Publicidad: SoftBuilder hará publicidad a través de diferentes medios de la web, como redes sociales, banners publicitarios, página web corporativa, entre otros.
Relaciones públicas: Se crearán relaciones con dueños de restaurantes asistiendo a
eventos de este tipo de negocio e interiorizando en él.
Todo lo anterior será realizado por personal especializado en Marketing Estratégico
Digital, quienes estarán encargados de ofrecer nuestro producto consiguiendo reuniones
con administrativos o dueños de Restaurantes.
27
CARTA GANTT
28
ANÁLISIS DE MERCADO
A continuación se mostrarán los resultados obtenidos de encuestas realizadas a través de
formularios webs de Google www.google.com/Forms.
1. Se realizó la siguiente pregunta para así saber cuánto porcentaje de las personas
encuestadas asistirían a un restorán en el cual se aplica nueva tecnología.
La mayor parte de las respuestas fue positiva, donde las personas que respondieron
negativamente eran por lo general personas mayores que su fundamento se basaba en no
interesarle la tecnología o la encontraban complicada. A continuación los resultados:
2. La siguiente encuesta se realizó para hacerse una idea de saber si implementarían
nuestro producto poniéndose en la situación de dueños de restaurantes.
La mayor parte fue una respuesta positiva ya que les parecía novedoso y útil, y la parte
negativa se basaba en que no lo encontraba algo relevante para el negocio.
84%
16%
¿Usted iría a un restaurante con servicio de autoatención con
tablet?
Si No
75%
25%
¿Si fuera dueño de un restaurant implementaría nuestro sistema de carta
Virtual ?
Si No
29
3. Esta encuesta si bien no se relaciona directamente con nuestro producto, podemos
saber lo importante que es para la gente la existencia de restaurantes y tener como
antecedentes la concurrencia a ellos.
4. Preguntamos lo siguiente en la encuesta para saber qué tan importante es para la
gente la tecnología, algo que nos afecta directamente y nos sirve como fundamentos para
luego ofrecer nuestros productos a dueños y administradores de restaurantes.
24%
30% 20%
15%
11%
Cuantas veces al mes van a un restaurant
1 vez al Mes 2 veces al Mes
3 veces al Mes 4 veces al Mes
Más de 4 veces al Mes
74%
26%
¿Consideras que el uso de tecnología en un restaurante
hace que éste resulte más atractivo ?
Si No
30
CICLO DE VIDA Y METODOLOGÍA DE DESARROLLO
Para este proyecto utilizaremos el ciclo de vida y a la vez metodología de desarrollo
“Evolutivo”.
El ciclo de vida y modelo de desarrollo evolutivo asume que los requerimientos están
sujetos a cambios continuos. Esto en nuestro proyecto se verá reflejado en los
requerimientos de cada restorán, ya que el software deberá adaptarse a las necesidades
del restorán, teniendo así que incluso desarrollar mejoras o adaptaciones para este.
Por todo lo anterior este es el ciclo de vida y metodología de desarrollo que mejor se
adapta a nuestro proyecto
Una mejor explicación en el siguiente esquema.
VENTAJAS
Este modelo o ciclo de vida tiene una gran ventaja para nosotros en comparación con
otros. Ya que si lo comparamos por ejemplo con el ciclo de vida Cascada este es muy
estructurado para nuestro proyecto ya que su metodología es estricta en cuanto a que
cada proceso o fase tiene que esperar el término de la anterior para comenzar, y esta no
incorpora requerimientos que se hayan presentado en el transcurso del proyecto
31
BPMN PROCESO DE VENTA
32
RIESGOS
Según la real academia de la lengua española (RAE) define riesgo como “Riesgo proviene
del italiano risico o rischio que, a su vez, tiene origen en el árabe clásico rizq (“lo que
depara la providencia”). El término hace referencia a la proximidad o contingencia de un
posible daño.”(RAE, 2014).
En términos del Riesgo Tecnológico se podría definir como: la posibilidad de pérdidas
derivadas de un evento relacionado con el acceso o uso de la tecnología, que afecta el
desarrollo de los procesos del negocio y la gestión de riesgos de la organización, al
comprometer o degradar las dimensiones críticas de la información (Ej. confidencialidad,
integridad , disponibilidad).
En ese sentido, en COBIT 5 for Risk (COBIT) define el Riesgo de TI como un riego para el
negocio, específicamente el asociado con el uso, propiedad, operación, involucramiento,
influencia y adopción de TI dentro de una empresa. (Steven A. Babb, et al., 2013: 17).
Los objetivos de este punto, es aumentar la probabilidad y el impacto de eventos
positivos, y disminuir la probabilidad y el impacto de eventos negativos.
En base a esto la Gestión de Riesgos en la etapa del proyecto debe ser enfatizada y
considerada como una actividad clave en todo tipo de proyectos y, particularmente, en
proyectos de desarrollo de software.
33
METODOLOGÍA DE GESTIÓN DE RIEGOS
Para poder gestionar lo mencionado anteriormente, se utilizara un modelo de gestión de
riegos, que es el más utilizado y consta de 5 pasos (Identificación, Análisis, Planificación,
Seguimiento y Control) secuenciales e iterativos, paralelamente dos actividades comunes
a ellos: las de documentación y comunicación.
34
IDENTIFICACIÓN Y ANÁLISIS
Es el paso más importante en la gestión de riesgos ya que si no se determina
correctamente no es posible desarrollar e implementar anticipadamente respuestas
apropiadas a los problemas que puedan surgir en el proyecto.
En la determinación de los elementos de riesgos potenciales, se utilizara la identificación
en base a taxonomías que implica el utilizar una estructura agrupadora de los mismos, se
detallan a continuación los riegos más relevantes que se deben tener en consideración a
lo largo del proyecto, categorizados y priorizados.
Nº Factor Indicador Probabilidad Impacto
Misión y Objetivos
1 Flujo de trabajo Se prevén cambios significativos en
el flujo de trabajo. Baja Media
2
El proyecto se adecua a la
organización cliente
El proyecto no se relaciona con la misión y objetivos de la organización
cliente. Baja Media
Conductores para la Toma de Decisiones
3 Estimaciones
Las estimaciones de tamaño, esfuerzo y costos han sido realizadas
sin seguir un proceso formal y sin una validación final.
Media Media
4 Datos históricos
No se emplean datos históricos para realizar estimaciones y
determinar niveles esperados de productividad y calidad
Alta Alta
Gerenciamiento Organizacional
35
5 Roles y
responsabilidades organizacionales
Los individuos en la organización no comprenden sus roles y
responsabilidades ni la de los demás.
Baja Baja
6 Políticas y estándares
Las políticas y estándares no se encuentran definidos o no son
seguidos. Media Media
7 Objetivos de
proyecto Los objetivos de proyecto no han sido definidos o no son medibles.
Baja Baja
Cliente/Usuarios
8 Necesidades de entrenamiento de los usuarios
Las necesidades de entrenamiento de los usuarios no han sido
consideradas. Baja Media
9 Justificación a los
usuarios
No se ha realizado una justificación del sistema a los usuarios o la misma resulta
inadecuada.
Media Alta
10 Presupuesto Escaso presupuesto asignado. Media Media
11 Restricciones
presupuestarias
Asignaciones presupuestarias en duda o sujetas a cambiar sin
notificación previa. Media Media
12 Controles de
costo No existe un sistema establecido. Media Media
Ingeniería del Producto
13 Estabilidad Muchos de los requerimientos se
modifican durante el desarrollo del sistema.
Media Media
14 Completitud
Muchos de los requerimientos del cliente no han sido detectados o no
se encuentran documentados apropiadamente; existen muchas
faltas de definiciones.
Baja Baja
15 Claridad
Los requerimientos se encuentran especificados pero existen grandes
problemas de ambigüedades y entendimiento con el cliente.
Baja Baja
16 Validez Los requerimientos expresan
algunas de las necesidades de los clientes y no han sido validados
Baja Baja
36
diferentes técnicas.
17 Viabilidad
La mayor parte de los requerimientos no son
técnicamente implementables tanto individual como grupalmente.
Baja Media
18 Antecedencia
Solo algunos de requerimientos se relacionan con actividades y
tecnologías antes implementadas en industria.
Baja Media
Diseño
19 Funcionalidad Los algoritmos y modelos
seleccionados no satisfacen muchos de los requerimientos funcionales.
Baja Baja
20 Dificultad
Muchos de los algoritmos y modelos presentan una alta complejidad y no todos los
requerimientos tienen una solución asociada.
Media Alta
21 Posibilidad de
desarrollar pruebas
Las características del producto dificultan la realización de pruebas y el personal que las desarrollará
no ha sido involucrado en el proceso de diseño.
Baja Baja
Código y Pruebas Unitarias
22 Pruebas unitarias Las pruebas unitarias no han sido
estimadas ni planificadas. Media Media
Requerimientos de Calidad
23 Calidad
Los requerimientos de calidad se encuentran documentados pero
son difícilmente alcanzables comparados con valores históricos
de la industria o la organización.
Baja Media
Proceso de desarrollo
24 Uso de un proceso de ingeniería
Proceso de desarrollo no establecido.
Media Media
37
definido
25
El proceso de desarrollo se
adecua al proyecto
El proceso de desarrollo no se adecua a las necesidades de
proyecto o no esta soportado por los métodos y herramientas
seleccionado.
Media Media
26 Compromiso con
el proceso
Los cambios a los compromisos en cuanto a alcance, contenidos y
calendario son realizados sin participar a los involucrados.
Media Media
27 Enfoque de
aseguramiento de la calidad
Sistema de aseguramiento de la calidad o procesos no establecidos.
Media Media
28 Documentación
de Desarrollo Inexistente. Baja Baja
29 Identificación temprana de
defectos
Proceso de revisión de pares no incorporado.
Media Media
30 Seguimiento de
defectos No se ha definido un proceso para
realizar el seguimiento de defectos. Media Media
31 Proceso de control de
cambios
No se ha definido un proceso de control de cambios.
Baja Media
Administración de Proyectos
32 Enfoque de
administración de proyectos
Planificación y monitorización del producto y proyecto inexistentes.
Media Media
33 Comunicación
Esporádicamente se comunican los objetivos y el estado entre el
equipo y el resto de la organización.
Baja Baja
34 Experiencia El administrador de proyectos no
posee experiencia. Baja Media
35 Actitud El administrador de proyectos está
escasamente comprometido con éxito del proyecto.
Baja Alta
38
36 Autoridad El administrador de proyectos no posee formalmente la autoridad
para ejercer un liderazgo efectivo. Baja Media
Equipo de Proyecto
37 Disponibilidad de
los miembros del equipo
Pérdidas y cambios frecuentes y poca posibilidad de retención.
Baja Alta
38 Combinación de habilidades del
equipo Mala combinación de disciplinas. Baja Media
39 Comunicación
interna del equipo
Confusa o inexistente. Baja Baja
40 Experiencia en la
aplicación
Escasa o ninguna experiencia en proyectos similares, puede ser
hardware, software o en procesos similares.
Baja Baja
41 Entrenamiento
del equipo
No existen plan de entrenamiento o el entrenamiento requerido no
está disponible Media Media
42 Espíritu y actitud
del equipo
Escasamente comprometido con éxito del proyecto y poco
cohesivo. Baja Alta
43 Productividad
del equipo
Baja productividad, los hitos no son alcanzados y las entregas se
realizan con demoras. Baja Baja
Mantenimiento
44 Complejidad de
diseño Extremadamente difícil de
mantener. Baja Media
45 Soporte del
personal
Personal no disponible, no experimentado y en un número
reducido. Alta Alta
Los riegos identificados y analizados anteriormente pueden impactar directamente en los
objetivos de proyecto, aumentando los costos significativamente, como también el
tiempo necesario para lograr los objetivos. También pueden causar una disminución de la
calidad, no cumpliendo con los estándares necesarios para lograr el objetivo de forma
óptima.
39
IMPACTO
A continuación se especifica el impacto que pueden tener los riesgos en el proyecto
dependiendo de su prioridad:
Escala de Impactos en Riesgos Negativos
Objetivos del proyecto
Bajo / .10
Moderado / .20
Alto /.40
10% 10%-20% Costos
20%-40%
Tiempo
5% 5%-10% 10%-20%
Alcances
Área menor del alcance afectada
Mayor área del alcance afectada
Reducción del alcance inaceptable
Aplicaciones se ven afectadas
Reducción de calidad requiere la aprobación
Reducción de calidad inaceptable por el cliente
Calidad
40
del cliente
PLAN DE RESPUESTA
Para realizar la planificación o identificar las respuestas a los posibles riesgos, se utilizaran
reuniones periódicas para poder determinar las amenazas y oportunidades que pueden
afectar al éxito del proyecto, se debatirá periódicamente para dar una respuesta rentable
en relación al desafío a cumplir, realista dentro del contexto del proyecto, serán
acordadas por todas las partes involucradas y cada uno de los riesgos quedara cargo del
responsable correspondiente.
Cuando se identifiquen riegos negativos o que causen una amenaza al proyecto se llevara
a cabo una de las siguientes acciones, cual será elegida por el equipo proyecto:
• Evitar.
Evitar el riesgo implica cambiar el plan para la dirección del proyecto, a fin de eliminar por
completo la amenaza. El director del proyecto también puede aislar los objetivos del
proyecto del impacto de los riesgos o cambiar el objetivo que se encuentra amenazado.
Ejemplos de lo anterior son la ampliación del cronograma, el cambio de estrategia o la
reducción del alcance. La estrategia de evasión más drástica consiste en anular por
completo el proyecto. Algunos riesgos que surgen en etapas tempranas del proyecto
pueden ser evitados aclarando los requisitos, obteniendo información, mejorando la
comunicación o adquiriendo experiencia.
• Transferir.
Transferir el riesgo requiere trasladar a un tercero todo o parte del impacto negativo de
una amenaza, junto con la propiedad de la respuesta. La transferencia de un riesgo
simplemente confiere a una tercera persona la responsabilidad de su gestión; no lo
elimina. La transferencia de la responsabilidad de un riesgo es más efectiva cuando se
trata de la exposición a riesgos financieros. Transferir el riesgo casi siempre implica el
41
pago de una prima de riesgo a la parte que asume el riesgo. Las herramientas de
transferencia pueden ser bastante diversas e incluyen, entre otras, el uso de seguros,
garantías de cumplimiento, fianzas, certificados de garantía, etc. Pueden emplearse
contratos para transferir a un tercero la responsabilidad de riesgos específicos. Por
ejemplo, cuando un comprador dispone de capacidades que el vendedor no posee, puede
ser prudente transferir contractualmente al comprador parte del trabajo junto con sus
riesgos correspondientes. En muchos casos, el uso de un contrato de margen sobre el
costo puede transferir el costo del riesgo al comprador, mientras que un contrato de
precio fijo puede transferir el riesgo al vendedor.
• Mitigar.
Mitigar el riesgo implica reducir a un umbral aceptable la probabilidad y/o el impacto de
un evento adverso. Se Adoptará acciones tempranas para reducir la probabilidad de
ocurrencia de un riesgo y/o su impacto sobre el proyecto, a menudo es más efectivo que
tratar de reparar el daño después de ocurrido el riesgo. Ejemplos de acciones tendientes a
mitigar un riesgo son adoptar procesos menos complejos, efectuar más pruebas o
seleccionar un proveedor más estable. Por ejemplo, la mitigación puede requerir la
creación de un prototipo para reducir el riesgo de pasar de un modelo a escala de un
proceso o producto a uno de tamaño real. Cuando no es posible reducir la probabilidad,
una respuesta de mitigación puede abordar el impacto del riesgo, dirigiéndose a los
vínculos que determinan su severidad. Por ejemplo, diseñar redundancia en un sistema
puede permitir reducir el impacto causado por un fallo del componente original.
• Aceptar.
Esta estrategia se adopta debido a que rara vez es posible eliminar todas las amenazas de
un proyecto. Esta estrategia indica que el equipo del proyecto ha decidido no cambiar el
plan para la dirección del proyecto para hacer frente a un riesgo, o no ha podido
identificar ninguna otra estrategia de respuesta adecuada. Esta estrategia puede ser
pasiva o activa. La aceptación pasiva no requiere ninguna acción, excepto documentar la
estrategia, dejando que el equipo del proyecto aborde los riesgos conforme se presentan.
La estrategia de aceptación activa más común consiste en establecer una reserva para
contingencias, que incluya la cantidad de tiempo, medios financieros o recursos
necesarios para abordar los riesgos.
Cuando se identifiquen riegos positivos o que generen una oportunidad al proyecto se
llevara a cabo una de las siguientes acciones:
42
• Explotar.
Esta estrategia puede seleccionarse para los riesgos con impactos positivos, cuando la
organización desea asegurarse de que la oportunidad se haga realidad. Esta estrategia
busca eliminar la incertidumbre asociada con un riesgo positivo particular, asegurando
que la oportunidad definitivamente se concrete. Algunos ejemplos de explotación directa
de las respuestas incluyen la asignación al proyecto de recursos más talentosos de la
organización para reducir el tiempo hasta la conclusión o para ofrecer un costo menor que
el planificado originalmente.
• Compartir.
Compartir un riesgo positivo, implica asignar todo o parte de la propiedad de la
oportunidad a un tercero mejor capacitado para capturar la oportunidad en beneficio del
proyecto. Algunos ejemplos de acciones para compartir incluyen la formación de
asociaciones de riesgo conjunto, equipos, empresas con finalidades especiales o uniones
temporales de empresas, que pueden establecerse con el propósito expreso de tomar
ventaja de la oportunidad, de modo que todas las partes se beneficien a partir de sus
acciones.
• Mejorar.
Esta estrategia se utiliza para aumentar la probabilidad y/o los impactos positivos de una
oportunidad. La identificación y maximización de las fuerzas impulsoras clave de estos
riesgos de impacto positivo pueden incrementar su probabilidad de ocurrencia. Algunos
ejemplos de mejorar las oportunidades incluyen la adición de más recursos a una
actividad para terminar más pronto.
• Aceptar.
Aceptar una oportunidad consiste en tener la voluntad de tomar ventaja de ella si se
presenta, pero sin buscarla de manera activa.
43
MONITOREO Y CONTROL LOS RIESGOS
Para evaluar la efectividad del proceso de gestión de riesgos, se rastrearan los riesgos
identificados, evaluando si se deben seguir respetando las políticas y los procedimientos,
también se evaluaran los cambios de cada uno de ellos como también si pasan al estado
de obsolescencia.
Al monitorear y controlar los riesgos, se irán identificando nuevos riesgos asociados al
proyecto.
El monitoreo y control de riegos se programara periódicamente y se abordara como punto
de orden del día en cada reunión sobre el estado del proyecto, para mantener actualizado
los procesos y así minimizar posibles amenazas, el día y horario específico se determina en
el cronograma de proyecto.
MATRIZ DE RIEGOS
Nivel d
e Pro
bab
ilidad
Alto
20 4 45
Medio
3 6 9 10 11
12 13
22 24
25 27
29 30
32 41
Bajo
5 7 1 2 35 37
14 15 8 17 42
16 19 18 31
21 28 23 34
33 39 36 38
40 43 44
Bajo Medio Alto
Nivel de Impacto
44
RIEGOS EN EL AMBIENTE DEL CLIENTE
PROCESOS COBIT SOBRE GESTIÓN DE LOS RIEGOS
COBIT se organiza en torno a 34 procesos que se agrupan en cuatro áreas: Planear y
Organizar (PO), Adquirir e Implantar (AI), Entregar y dar Soporte (DS) y Mantener y Evaluar
(ME). Dentro del área DS encontramos el proceso DS5 que se encarga de Asegurar la
Seguridad de los Sistemas el cual incluye:
DS5.4 ADMINISTRACIÓN DE CUENTAS DEL USUARIO
Garantizar que la solicitud, establecimiento, emisión, suspensión, modificación y cierre de
cuentas de usuario y de los privilegios relacionados, sean tomados en cuenta por la
gerencia de cuentas de usuario. Debe incluirse un procedimiento que describa al
responsable de los datos o del sistema como otorgar los privilegios de acceso. Estos
procedimientos deben aplicar para todos los usuarios, incluyendo administradores
(usuarios privilegiados), usuarios externos e internos, para casos normales y de
emergencia. Los derechos y obligaciones relacionados al acceso a los sistemas e
información de la empresa son acordados contractualmente para todos los tipos de
usuarios. La gerencia debe llevar a cabo una revisión regular de todas las cuentas y los
privilegios asociados.
DS5.5 PRUEBAS, VIGILANCIA Y MONITOREO DE LA SEGURIDAD
Garantizar que la implementación de la seguridad en TI sea probada y monitoreada de
forma pro-activa. La seguridad en TI debe ser re acreditada periódicamente para
garantizar que se mantiene el nivel seguridad aprobado. Una función de ingreso al sistema
(login) y de monitoreo permite la detección oportuna de actividades inusuales o
anormales que pueden requerir atención. El acceso a la información de ingreso al sistema
está alineado con los requerimientos del negocio en términos de requerimientos de
retención y de derechos de acceso.
DS5.8 ADMINISTRACIÓN DE LLAVES CRIPTOGRÁFICAS
Determinar que las políticas y procedimientos para organizar la generación, cambio,
revocación, destrucción, distribución, certificación, almacenamiento, captura, uso y
archivo de llaves criptográficas estén implantadas, para garantizar la protección de las
llaves contra modificaciones y divulgación no autorizadas.
45
DS5.9 PREVENCIÓN, DETECCIÓN Y CORRECCIÓN DE SOFTWARE MALICIOSO
Garantizar que se cuente con medidas de prevención, detección y corrección (en especial
contar con parches de seguridad y control de virus actualizados) a lo largo de toda la
organización para proteger a los sistemas de información y a la tecnología contra software
malicioso (virus, gusanos, spyware, correo basura, software fraudulento desarrollado
internamente, etc.).
DS5.10 SEGURIDAD DE LA RED
Garantizar que se utilizan técnicas de seguridad y procedimientos de administración
asociados (por ejemplo, firewalls, dispositivos de seguridad, segmentación de redes, y
detección de intrusos) para autorizar acceso y controlar los flujos de información desde y
hacia las redes.
1.1 ANÁLISIS DE RIESGOS.
46
ID Mejor Practica Según COBIT para Gestión
de Riesgos
Porcentaje de
Ocurrencia Impacto Consecuencia
B M A B M A
R5.4.1 Solicitud, Establecimiento y
Emisión de Cuentas de Usuarios
X X
Se debe mantener siempre activa la posibilidad de crear una cuenta de usuario, el no respetar esta norma podría causar un impacto leve al no poder asignar a un usuario a sus labores de inmediato. Bajo.
R5.4.2 Suspensión de Cuentas de
Usuarios X X
Se debe tener la posibilidad de realizar la suspensión de una cuenta, el no respetar esta norma podría causar un alto impacto ya que un usuario el cual es desvinculado y su acceso al sistema no sea suspendido de inmediato, podría concretar algún tipo de ataque a las funcionalidades criticas del sistema el cual pudiera paralizar las ventas. Alto.
R5.4.3 Modificación de Cuentas
de Usuarios X
X
Se debe tener la posibilidad de realizar la modificación de una cuenta, al no respetar esta norma podría causar un impacto leve al no poder asignar cambio a las labores o privilegios de un usuario. Bajo.
R5.4.4 Privilegios de Usuario X
X
Se debe mantener el acceso al sistema con limitantes ya que solo los usuarios administradores deben ingresar a las funcionalidad criticas del sistema, el no respetar esta norma podría causar un alto impacto al permitir que todos los usuarios interactúen con todas las funcionalidades pudiendo llegar a paralizar las ventas en el peor de los casos. Alto
R5.4.5
Procedimientos aplican para todos los usuarios,
incluyendo administradores
X X Debe aplicar para todos los usuarios ya que un ataque puede ser concretado por cualquier usuario. Alto
R5.4.6 Revisión regular de todas
las cuentas y los privilegios asociados
X X
Se debe realizar un monitoreo de forma periódica de todas las cuentas con privilegios de acceso, revisando el historial de cambios para evitar cualquier acceso no autorizado , el no respetar esta norma podría causar un alto impacto si se llegase a concretar algún tipo de ataque a las funcionalidades criticas del sistema el cual podría paralizar las ventas. Alto
R5.5.1 Ingreso con Login y tablas de control para auditorias.
X X
Se debe mantener un registro del ingreso de todos los usuarios como también el historial de modificaciones sobre la información del sistema, el no respetar esta norma podría causar un impacto medio si un usuario realiza modificaciones no autorizadas. Medio
47
R5.8.1 Formato de clave X X
Se debe mantener las claves de usuario como llaves criptográficas en la base de datos, al no respetar esta norma podría causar un alto impacto si un usuario no autorizado accede a las cuentas y hace un uso malicioso de ellas llegando a concretar algún tipo de ataque a las funcionalidades criticas del sistema el cual podría paralizar las ventas. Alto
R5.9.1 Prevención, detección y corrección de software
malicioso X X
Se debe hacer uso de un software para proteger a los sistemas de información y a la tecnología contra software malicioso, el no respetar esta norma podría causar un alto impacto si se llegase a concretar algún tipo de ataque a las funcionalidades críticas del sistema el cual podría paralizar las ventas. Alto
R5.10.1 Seguridad de la red X X
Se deben utilizan técnicas de seguridad y procedimientos de administración asociados (por ejemplo, firewalls, dispositivos de seguridad, segmentación de redes, y detección de intrusos, el no respetar esta norma podría causar un alto impacto si se llegase a concretar algún tipo de ataque a las funcionalidades criticas del sistema el cual podría paralizar las ventas. Alto
Tabla 112: Análisis de Riegos.
48
A continuación se especifica el impacto que pueden tener los riesgos en la organización dependiendo de su prioridad:
Escala de Impactos en Riesgos
Bajo Moderado Alto
Costos 5% - 10% 10%-20% 100%
Consecuencia Reducción la calidad
de atención Reducción de las ventas y la
calidad de atención Parálisis de las Ventas
Alcance Reducción la calidad
de atención Reducción de las ventas y la
calidad de atención Parálisis de las Ventas
Tabla 13: Matriz de Impacto de Riegos.
Nivel d
e Pro
bab
ilidad
Alto
Medio
R5.5.1 R5.10.1 R5.4.4 R5.4.5
R5.4.6
Bajo
R5.4.1 R5.4.3 R5.4.2 R5.8.1
R5.9.1
Bajo Medio Alto
Nivel de Impacto
Tabla 14: Matriz de Riegos.
49
MODELO DE BASE DE DATOS
MODELO CONCEPTUAL
50
MODELO LÓGICO
51
MODELO FISICO
52
SISTEMA DE GESTIÓN DE LA BASE DE DATOS
MYSQL
MySQL es un sistema de administración de bases de datos. Una base de datos es una
colección estructurada de tablas que contienen datos, esta puede ser desde una simple
lista de compras a una galería de pinturas o el vasto volumen de información de un
restaurant. Para agregar, acceder y procesar datos se necesita un administrador como
MySQL Community Server. Los administradores de bases de datos juegan un papel central
como aplicaciones independientes o como parte de otras aplicaciones.
CARACTERÍSTICAS.
Entre las características disponibles en la última versión se puede destacar:
Amplio subconjunto del lenguaje SQL.
Disponibilidad en gran cantidad de plataformas y sistemas (Windows, Linux).
Posibilidad de selección de mecanismos de almacenamiento que ofrecen diferentes velocidades de operación, soporte físico, capacidad, distribución geográfica, transacciones.
Transacciones y claves foráneas.
Conectividad segura.
Replicación.
Búsqueda e indexación de campos de texto.
Además de un rápido y fácil uso de recursos tales como: Procedimientos almacenados y desencadenadores (triggers).
¿PORQUE ELEGIR MYSQL?
Velocidad y Flexibilidad
MySQL es un sistema de administración relacional de bases de datos. Una base de datos
relacional archiva datos en tablas separadas en vez de colocar todos los datos en un gran
archivo. Esto permite velocidad y flexibilidad. Las tablas están conectadas por relaciones
definidas que hacen posible combinar datos de diferentes tablas sobre pedido.
Software Libre
“MySQL Community Edition es una versión de descarga gratuita de la base de datos de
código abierto más popular del mundo, que se apoya en una comunidad activa de
53
desarrolladores y entusiastas del código abierto” ORACLE. (2015). MySQL Server
Community. 01/06/2015, de ORACLE Sitio web: http://dev.mysql.com/
Es gracias a esto, que se pueden recudir los costos sobre el software que estamos
utilizando, y el cual ofreceremos como solución final a nuestro cliente.
MECANISMOS DE MONITOREO
Para poder tener un correcto funcionamiento del motor de la base de datos, utilizaremos
un software llamando Pandora FMS, que para el número de servidores que tendremos
que manejar, podremos obtener la versión de forma gratuita y el fin de mantener el mejor
servicio y permitiendo un bajo costo de mantención.
Pandora FMS es una herramienta de monitorización que no sólo mide sin un parámetro
está bien o mal. Pandora FMS puede cuantificar el estado (bien, mal y valores
intermedios) o almacenar un valor (numérico o alfanumérico) durante meses si es
necesario.
Pandora FMS permite medir rendimientos, comparar valores entre diferentes sistemas y
establecer alertas sobre umbrales.
“Pandora FMS trabaja sobre la base de datos, de forma que puede generar informes,
estadísticas, niveles de adecuación de servicio (SLA) y medir cualquier cosa que
proporcione o devuelva un dato. Es decir, Pandora FMS puede medir cualquier cosa:
sistemas operativos, servidores, aplicaciones, hardware. Todo ello integrado en una
arquitectura abierta y distribuida” Sitio web: http://pandorafms.com/
Los puntos que monitorizaremos son:
Verificación de la conectividad con la base de datos.
Chequear si el proceso de MYSQL está activo.
Chequeo de memoria del servidor.
Número de conexiones TIME_WAIT en el sistema.
Chequeo de espacio en disco del servidor.
Tamaño del fichero IBDATA1.
Búsqueda de errores en los logs de la base de datos.
54
Adicionalmente también es posible monitorear los siguientes parámetros de rendimiento:
Número de conexiones activas MySQL.
Tiempo de actividad del servidor (uptime)
Número de conexiones abortadas por que el cliente no cerró correctamente.
Número de bytes recibidos por los clientes.
Número de bytes enviados por lo clientes.
Número de inserciones en la base de datos.
Número de bloques sobre tablas en la base de datos al realizar una transacción.
Tamaño total de datos en GB.
