Proyecto de Tesis Sistema Restaurant

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:

1

08 de Junio 2015

Proyecto ID Documento Nombre Documento Autor

SB – Administración de Restaurant SW-PRJ-01 Estado En Construcción Acta de constitución de proyecto SoftBuilder Fecha 01/04/2015

Versión

1.8

Versión

Fecha Revisión

Descripción de la Revisión

Autor

<1.0> <1.8>

01-04-2015 08-06-2015

Se crea documento Modificación del documento para agregar nuevos requerimientos.

SoftBuilder SoftBuilder

Fecha Aprobación

Aprobador

Rol/Cargo

Firma

2

08 de Junio 2015

Proyecto ID Documento Nombre Documento Autor

SB – Administración de Restaurant SW-PRJ-01 Estado En Construcción Acta de constitución de proyecto SoftBuilder Fecha 01/04/2015

Versión

1.8

Versión

Fecha Revisión

Descripción de la Revisión

Autor

<1.0> <1.8>

01-04-2015 08-06-2015

Se crea documento Modificación del documento para agregar nuevos requerimientos.

SoftBuilder SoftBuilder

Fecha Aprobación

Aprobador

Rol/Cargo

Firma

2

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 REQUERIMIENTOS DE VENTAS ................................................................................................... . 17 REQUERIMIENTOS REQUERIMIENTOS DE ADMINISTRACIÓN ADMINISTRACIÓN ....................................................................................... 19

REQUERIEMINTOS DE GESTIÓN ESTRATÉGICA................................................................................ 21 REQUERIMIENTOS NO FUNCIONALES................................... 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.......................... FACTIBILIDAD............................................................................. ................................................................. .............. 26 CARTA GANTT ............................................ ............................................................................................. ................................................................. ................ 27

3

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 DENTIFICACIÓ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 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 L A 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

4

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

5

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.

6

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.

7

ORGANIGRAMA

El organigrama estructural de la empresa:

Imagen 1: Organigrama.

Cargo en el Proyecto Ingeniero en Informática Ingeniero en Informática Ingeniero en Informática

Nombre Jonathan Durán Francisco Mendoza Claudio Jara

Cargo en la Organización

Email

Gerente de Proyectos Gerente Comercial

[email protected]

Gerente De Desarrollo

[email protected] [email protected]

Tabla 1 : Organigrama.

8

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.

9

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:

10

Requerimiento de Ventas Visualización de las mesas en cada punto de venta Varios consumos por mesa Acceso al sistema con cuentas diferenciadas con perfil Ventas asociadas a mesas individuales por garzón Transferencias de clientes entre mesas Eliminación de transacciones con código de autorización Selección de acompañamientos Pagos individuales y total con o sin cierre de mesa Manejo de diferentes tipos de pago Descuentos con código de autorización Modulo de reserva Elección de consumos directamente por clientes Revisión o consulta de valor consumido, desde cualquier dispositivo móvil Adición y sustracción de ingredientes opcionales. SLA de espera mostrado en los dispositivos (opcional) % de cumplimiento Requerimiento de Administración Cuadratura de caja Modulo de administración de usuarios con perfil de ingreso Modulo de administración de insumos, recetas y bodegas Transferencia de insumos entre bodegas Modulo de administración de horarios y precios Incluir instrucciones a los centros de producción Control de Stock Generación automática de auditorias SLA adaptable al número de personal disponible Modulo de dotación de personal % de cumplimiento Requerimiento de Gestión Estratégica Generación de reportes Buscador de datos específicos % de cumplimiento % de cumplimiento total

Menú On

Easy Post

X

X X X X X X X X X X

X X X X X X

Carta Virtual X X X X X X X X X X X X X

47%

67%

Menú On

Easy Post

X X X

X

X X X X X X X

50%

70%

Menú On

Easy Post

X X 100% 66%

X X 100% 79%

X

X X 100% Carta Virtual X X X X X X X X X X 100% Carta Virtual X X 100% 100%

Tabla 2: Benchmarking comparativo.

11

MARCO TEÓRICO CONCEPTUAL

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/ 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. E l 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

12

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. 13

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.

14

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.

15

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.

16

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

Versión

Nombre Corto Requerimiento

Módulo de ventas

Configuración del Requerimiento

Se necesita módulo de ventas que permita:

<1.0>

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.

17

Id

Versión

<1.0>


Módulo de consulta de cliente


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

Versión


Módulo de reservas


Se necesita módulo de reservas que permita:

<1.0>

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.

18

Id

Versión


Módulo de caja


Se necesita módulo de caja que permita:

<1.0>

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

Versión


Módulo de usuarios


Se necesita módulo de usuarios que permita:

<1.0>

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.

19

Id

Versión


Módulo de recetas


Se necesita módulo de recetas que permita:

<1.0>

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

Versión


Módulo de bodega


Se necesita módulo de bodega que permita:

<1.0>

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.

20

Id

Versión


Módulo de horarios y precios


Se necesita módulo de bodega que permita:

<1.0>

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

Versión


Módulo de reportes


Se necesita módulo de auditorías que permita:

<1.0>

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.

21

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: 22

o

o

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. 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. 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. 23

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.

24

COSTOS ASOCIADOS AL PROYECTO

El costo asociado al proyecto es el siguiente: Costos Asociados al Proye cto Tiempo de desarrollo del Proyecto

Carta Virtual

Meses

12

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.100.000

1.320.000

Ingeniero de Sistemas

1

1 1.320.000 Costo Total Proyecto

Tiempo de Desarrollo Tiempo estimado Estudio Proyecto Costo Me nsual Proye cto e n 1 año Costo de Inversión Anual Min. Costo Asociado al Proyecto

960.000

14.760.000

12 Meses 5 Años 1.230.000 246.000 20.500

Valor Base UF

0,82

Soporte

0,40

Software

0,50

% Ganancia Mensual Valor Mensual:

3,5% 1,75

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 .

25

CONCEPTO Ingresos Egresos Flujo de caja

Costo Inicial

-20.000.000

VAN TIR

1 4.800.000 1.500.000 3.300.000

2 9.600.000 2.000.000 7.600.000

3 9.600.000 2.000.000 7.600.000

4 14.400.000 3.500.000 10.900.000

5 14.400.000 3.500.000 10.900.000

55.814.079 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.

26

CARTA GANTT

27

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:

¿Usted iría a un restaurante con servicio de autoatención con tablet? 16%

84%

Si

No

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.

¿Si fuera dueño de un restaurant implementaría nuestro sistema de carta Virtual ? 25% 75%

Si

No

28

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.

Cuantas veces al mes van a un restaurant 11% 15%

24% 20%

30%

1 vez al Mes

2 veces al Mes

3 veces al Mes

4 veces al Mes

Más de 4 veces al Mes

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.

¿Consideras que el uso de tecnología en un restaurante hace que éste resulte más atractivo ?

26%

74%

Si

No

29

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

30

BPMN PROCESO DE VENTA

31

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).

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.

32

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.

33

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º Misión y Objetivos

Factor

Indicador

Probabilidad Impacto

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

Media

Media

Alta

Alta

Conductores para la Toma de Decisiones 3

Estimaciones

4

Datos históricos

Las estimaciones de tamaño, esfuerzo y costos han sido realizadas sin seguir un proceso formal y sin una validación final. No se emplean datos históricos para realizar estimaciones y determinar niveles esperados de productividad y calidad

Gerenciamiento Organizacional

34

5

Roles y responsabilidades organizacionales

6

Políticas y estándares

7

Objetivos de proyecto

Los individuos en la organización no comprenden sus roles y responsabilidades ni la de los demás. Las políticas y estándares no se encuentran definidos o no son seguidos. Los objetivos de proyecto no han sido definidos o no son medibles.

Baja

Baja

Media

Media

Baja

Baja

Baja

Media

Media

Alta

Escaso presupuesto asignado. Asignaciones presupuestarias en duda o sujetas a cambiar sin notificación previa.

Media

Media

Media

Media

No existe un sistema establecido.

Media

Media

Media

Media

Baja

Baja

Baja

Baja

Baja

Baja

Cliente/Usuarios 8

9

Necesidades de entrenamiento de los usuarios

Las necesidades de entrenamiento de los usuarios no han sido consideradas. No se ha realizado una Justificación a los justificación del sistema a los usuarios usuarios o la misma resulta inadecuada.

10

Presupuesto

11

Restricciones presupuestarias

12

Controles de costo

Ingeniería del Producto 13

Estabilidad

14

Completitud

15

Claridad

16

Validez

Muchos de los requerimientos se modifican durante el desarrollo del sistema. Muchos de los requerimientos del cliente no han sido detectados o no se encuentran documentados apropiadamente; existen muchas faltas de definiciones. Los requerimientos se encuentran especificados pero existen grandes problemas de ambigüedades y entendimiento con el cliente. Los requerimientos expresan algunas de las necesidades de los clientes y no han sido validados

35

diferentes técnicas.

17

Viabilidad

18

Antecedencia

La mayor parte de los requerimientos no son técnicamente implementables tanto individual como grupalmente. Solo algunos de requerimientos se relacionan con actividades y tecnologías antes implementadas en industria.

Baja

Media

Baja

Media

Baja

Baja

Media

Alta

Baja

Baja

Diseño 19

Funcionalidad

20

Dificultad

21

Posibilidad de desarrollar pruebas

Los algoritmos y modelos seleccionados no satisfacen muchos de los requerimientos funcionales. Muchos de los algoritmos y modelos presentan una alta complejidad y no todos los requerimientos tienen una solución asociada. 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.

Código y Pruebas Unitarias 22

Pruebas unitarias

Las pruebas unitarias no han sido estimadas ni planificadas.

Media

Media

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

Uso de un proceso de ingeniería

Proceso de desarrollo no establecido.

Media

Media

Requerimientos de Calidad

23

Proceso de desarrollo 24

36

definido

25

El proceso de desarrollo se adecua al proyecto

26

Compromiso con el proceso

El proceso de desarrollo no se adecua a las necesidades de proyecto o no esta soportado por los métodos y herramientas seleccionado. Los cambios a los compromisos en cuanto a alcance, contenidos y calendario son realizados sin participar a los involucrados.

Media

Media

Media

Media

Sistema de aseguramiento de la calidad o procesos no establecidos.

Media

Media

Inexistente.

Baja

Baja

Proceso de revisión de pares no incorporado.

Media

Media

No se ha definido un proceso para realizar el seguimiento de defectos.

Media

Media

No se ha definido un proceso de control de cambios.

Baja

Media

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

Actitud

El administrador de proyectos está escasamente comprometido con éxito del proyecto.

Baja

Alta

27 28 29 30 31

Enfoque de aseguramiento de la calidad Documentación de Desarrollo Identificación temprana de defectos Seguimiento de defectos Proceso de control de cambios

Administración de Proyectos 32

35

37

36

Autoridad

El administrador de proyectos no posee formalmente la autoridad para ejercer un liderazgo efectivo.

Baja

Media

Pérdidas y cambios frecuentes y poca posibilidad de retención.

Baja

Alta

Mala combinación de disciplinas.

Baja

Media

Confusa o inexistente.

Baja

Baja

Baja

Baja

Media

Media

Baja

Alta

Baja

Baja

Baja

Media

Alta

Alta

Equipo de Proyecto 37

38

39

40

41

42

43

Disponibilidad de los miembros del equipo Combinación de habilidades del equipo Comunicación interna del equipo

Escasa o ninguna experiencia en Experiencia en la proyectos similares, puede ser aplicación hardware, software o en procesos similares. No existen plan de entrenamiento Entrenamiento o el entrenamiento requerido no del equipo está disponible Escasamente comprometido con Espíritu y actitud éxito del proyecto y poco del equipo cohesivo. Baja productividad, los hitos no Productividad son alcanzados y las entregas se del equipo realizan con demoras.

Mantenimiento 44

Complejidad de diseño

45

Soporte del personal

Extremadamente difícil de mantener. Personal no disponible, no experimentado y en un número reducido.

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. 38

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%

20%-40%

5%

5%-10%

10%-20%

Costos

Tiempo

Alcances Área menor del alcance Mayor área afectada del alcance afectada

Calidad

Aplicaciones se ven afectadas

Reducción de calidad requiere la aprobación

Reducción del alcance inaceptable

Reducción de calidad inaceptable por el cliente 39

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 40

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:

41

• 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.

42

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

20

4

45

Alto

N iv e l P

e

d

Medio o

r b a b il id a d

Bajo

5 14 16 21 33 40

7 15 19 28 39 43 Bajo

3 10 12 22 25 29 32 1 8 18 23 36 44

6 11 13 24 27 30 41 2 17 31 34 38 Medio

9

35 42

37

Alto

Nivel de Impacto 43

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.

44

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.

45

ID

Mejor Practica Según Porcentaje COBIT para Gestión de Impacto de Riesgos Ocurrencia B M A B M A

R5.4.1

Solicitud, Establecimiento y Emisión de Cuentas de Usuarios

X

R5.4.2

Suspensión de Cuentas de Usuarios

X

R5.4.3

Modificación de Cuentas de Usuarios

X

R5.4.4

Privilegios de Usuario

R5.4.5

Procedimientos aplican para todos los usuarios, incluyendo administradores

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. 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 X 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. 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. 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 X 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

X

X

X

Debe aplicar para todos los usuarios ya que un X ataque puede ser concretado por cualquier usuario. Alto

X

R5.4.6

Revisión regular de todas las cuentas y los privilegios asociados

X

R5.5.1

Ingreso con Login y tablas de control para auditorias.

X

Consecuencia

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 X 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 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

46

R5.8.1

Formato de clave

X

R5.9.1

Prevención, detección y corrección de software malicioso

X

R5.10.1

Seguridad de la red

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 X 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 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 X 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 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 X 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.

47

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.

Alto N iv e l d e

R5.5.1 o

r

P

R5.10.1

Medi o il

b

a

b id a

R5.4.1 d

R5.4.3

Bajo

Bajo

Medio

R5.4.4 R5.4.6

R5.4.5

R5.4.2 R5.9.1

R5.8.1

Alto

Nivel de Impacto Tabla 14: Matriz de Riegos.

48

MODELO DE BASE DE DATOS MODELO CONCEPTUAL

49

MODELO LÓGICO

MODELO LÓGICO

50

MODELO FISICO

MODELO FISICO

51

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:

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

52

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.

53

Proyecto de Tesis Sistema Restaurant

Recommend Documents