Proyecto de Tesis Sistema Restaurant

54 

Loading.... (view fulltext now)

Loading....

Loading....

Loading....

Loading....

Texto completo

(1)

Especificación de Gestión y Diseño

Especificación de Gestión y Diseño

Sistema Carta Virtual

Sistema Carta Virtual

Administración de Restaurants

Administración de Restaurants

Profesor a Cargo: Profesor a Cargo:  Juan Pablo Zuñiga  Juan Pablo Zuñiga

Integrantes de este Trabajo: Integrantes de este Trabajo:  Jonathan Durán  Jonathan Durán Francisco Mendoza Francisco Mendoza

(2)

08 de Junio 2015 08 de Junio 2015

Versión

Versión Fecha Fecha Revisión Revisión Descripción Descripción de de la la Revisión Revisión AutorAutor <1.0>

<1.0> 01-04-2015 01-04-2015 Se Se crea crea documento documento SoftBuilderSoftBuilder <1.8>

<1.8> 08-06-2015 08-06-2015 Modificación Modificación del del documento documento para para agregar agregar nuevosnuevos requerimientos. requerimientos. SoftBuilder SoftBuilder Fecha Fecha  Aprobación  Aprobación  Aprobador

 Aprobador Rol/Cargo Rol/Cargo FirmaFirma

Proyecto

Proyecto SBSB – – Administración de Restaurant Administración de Restaurant ID Documento

ID Documento SW-PRJ-01SW-PRJ-01 EstadoEstado En ConstrucciónEn Construcción VersiónVersión 1.81.8 Nombre Documento

Nombre Documento Acta de constitución de proyectoActa de constitución de proyecto Autor

(3)

08 de Junio 2015 08 de Junio 2015

Versión

Versión Fecha Fecha Revisión Revisión Descripción Descripción de de la la Revisión Revisión AutorAutor <1.0>

<1.0> 01-04-2015 01-04-2015 Se Se crea crea documento documento SoftBuilderSoftBuilder <1.8>

<1.8> 08-06-2015 08-06-2015 Modificación Modificación del del documento documento para para agregar agregar nuevosnuevos requerimientos. requerimientos. SoftBuilder SoftBuilder Fecha Fecha  Aprobación  Aprobación  Aprobador

 Aprobador Rol/Cargo Rol/Cargo FirmaFirma

Proyecto

Proyecto SBSB – – Administración de Restaurant Administración de Restaurant ID Documento

ID Documento SW-PRJ-01SW-PRJ-01 EstadoEstado En ConstrucciónEn Construcción VersiónVersión 1.81.8 Nombre Documento

Nombre Documento Acta de constitución de proyectoActa de constitución de proyecto Autor

(4)

CONTENIDO

CONTENIDO

PROPÓSITO

PROPÓSITO ... ... 66 DESCRIPCIÓN

DESCRIPCIÓN DEL DEL USUARIO USUARIO ... 6... 6

IDENTIFICACIÓN IDENTIFICACIÓN... ... ... 6... 6 ANTECEDENTES ANTECEDENTES... ... ... 7... 7 ORGANIGRAMA ORGANIGRAMA ... 8 ... 8 CONTEXTO PROYECTO CONTEXTO PROYECTO... ... ... ... 99 MARCO

MARCO REFERENCIAL ...REFERENCIAL ... 10... 10 M

MENÚENÚOONN ... 10 ... 10

EEASYASYPPOSOS ... 10 ... 10

MARCO TEÓRICO

MARCO TEÓRICO CONCEPTUAL ...CONCEPTUAL ... 12... 12 DEFINICIÓN Y DESCRIPCIÓN

DEFINICIÓN Y DESCRIPCIÓN DEL MERCADO OBJETIVO ... 13DEL MERCADO OBJETIVO ... 13 SITUACIÓN

SITUACIÓN ACTUAL ...ACTUAL ... ... 1414

IDENTIFICACIÓN DEL PROBLEMA

IDENTIFICACIÓN DEL PROBLEMA... ... 15... 15 IMPACTO ASOCIADO IMPACTO ASOCIADO ... ... ... ... 1515 MISION Y VISION MISION Y VISION... ... ... 16... 16 REQUERIMIENTOS FUNCIONALES REQUERIMIENTOS FUNCIONALES ... 17... 17 REQUERIMIENTO

REQUERIMIENTOS DE S DE VENTASVENTAS ... ... . . 1717 REQUERIMIENTO

REQUERIMIENTOS S DE DE ADMINISTRACIÓADMINISTRACIÓNN ... 19 ... 19

R

REQUERIEMINTOS DEEQUERIEMINTOS DEGGESTIÓN ESTRATÉGICAESTIÓN ESTRATÉGICA... 21... 21

REQUERIMIENTOS NO

REQUERIMIENTOS NO FUNCIONALES...FUNCIONALES... 22... 22 P

PERFORMANCEERFORMANCE ... 22 ... 22

SSEGURIDAD DE LA INFORMACIÓNEGURIDAD DE LA INFORMACIÓN ... ... ... ... 2222 RESTRICCIONES RESTRICCIONES... ... ... 23... 23 A ALCANCESLCANCES... ... ... 24... 24 USABILIDAD USABILIDAD ... 24 ... 24 LICENCIAS LICENCIAS... ... ... 24... 24 COSTOS ASOCIADOS

COSTOS ASOCIADOS AL AL PROYECTO PROYECTO ... 25... 25 ESTUDIO DE

ESTUDIO DE FACTIBILIDAD...FACTIBILIDAD... 26... 26 CARTA GANTT

(5)

ANÁLISIS DE

ANÁLISIS DE MERCADO ...MERCADO ... 28... 28 CICLO DE VIDA

CICLO DE VIDA Y METODOLOGÍA DE Y METODOLOGÍA DE DESARROLLO DESARROLLO ... 30... 30 V

VENTAJASENTAJAS ... 30 ... 30

BPMN PROCESO

BPMN PROCESO DE DE VENTA VENTA ... 31... 31 RIESGOS ...

RIESGOS ... ... 3232 M

METODOLOGÍA DEETODOLOGÍA DEGGESTIÓN DEESTIÓN DERRIEGOSIEGOS ... ... ... ... 3333

IIDENTIFICACIDENTIFICACIÓN YÓN Y AANÁLISISNÁLISIS... ... . 34. 34

IIMPACTOMPACTO ... 39 ... 39

P

PLAN DE RESPUESTALAN DE RESPUESTA... ... ... 40... 40

M

MONITOREO YONITOREO YCCONTROL LOSONTROL LOSRRIESGOSIESGOS... ... 43... 43

M

MATRIZ DEATRIZ DERRIEGOSIEGOS ... ... ... ... 4343

R

RIEGOS EN ELIEGOS EN ELAAMBIENTE DELMBIENTE DELCCLIENTELIENTE... ... 44... 44

P

PROCESOSROCESOSCOBITCOBIT SOBRE SOBREGGESTIÓN DE LOSESTIÓN DE LOSRRIEGOSIEGOS... ... ... 4444

DS5.4 Administración de

DS5.4 Administración de cuentas del cuentas del usuario usuario ... ... 44... 44 DS5.5 Pruebas,

DS5.5 Pruebas, vigilancia y vigilancia y monitoreo de la monitoreo de la seguridaseguridad d ... . . 4444 DS5.8

DS5.8 Administración de llaves Administración de llaves criptográficas criptográficas ... ... 44... 44 DS5.9 Prevención, detección y

DS5.9 Prevención, detección y corrección de software malicioso ...corrección de software malicioso ... . . 4545 DS5.10 Seguridad de la red ...

DS5.10 Seguridad de la red ... ... ... 4545

1.1

1.1 ANÁLISIS DE RIESGOS. ...ANÁLISIS DE RIESGOS. ... 45... 45 MODELO DE

MODELO DE BASE DE BASE DE DATOS ...DATOS ... 49... 49 M

MODELOODELOCCONCEPTUALONCEPTUAL... ... . 49. 49

M

MODELO LÓGICOODELO LÓGICO... ... ... 50... 50

M

MODELOODELOFISICO ... 51FISICO ... 51

SISTEMA DE GESTIÓN DE L

SISTEMA DE GESTIÓN DE LA BASE DE DATOS ... 52A BASE DE DATOS ... 52 M

MYYSSQLQL... ... ... 52... 52

C

CARACTERÍSTICASARACTERÍSTICAS. ... 52. ... 52

¿P

¿PORQUE ELEGIRORQUE ELEGIRMMYYSSQLQL? ? ... ... . . 5252

MECANISMOS

(6)

TTABLAABLA5:5: RREQUERIMIENTOS DE VENTASEQUERIMIENTOS DE VENTAS. . ... .... 1818

TTABLAABLA6:6: RREQUERIMIENTOS DE CAJAEQUERIMIENTOS DE CAJA. . ... ... 1919 TTABLAABLA7:7: RREQUERIMIENTOS DE USUARIOSEQUERIMIENTOS DE USUARIOS. . ... .. 1919

TTABLAABLA8:8: RREQUERIMIENTOS DE RECETASEQUERIMIENTOS DE RECETAS. . ... .... 2020

TTABLAABLA10:10: RREQUERIMIENTOS DE HORARIOS Y PRECIOSEQUERIMIENTOS DE HORARIOS Y PRECIOS. . ... ... 2121

TTABLAABLA11:11: RREQUERIMIENTOS DE REPORTESEQUERIMIENTOS DE REPORTES. . ... ... 2121

TTABLAABLA12:12: AANÁLISIS DENÁLISIS DERRIEGOSIEGOS... .... 4747

(7)

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.

(8)

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.

(9)

ORGANIGRAMA

El organigrama estructural de la empresa:

Imagen 1: Organigrama.

Tabla 1 : Organigrama.

Cargo en el Proyecto Nombre Cargo en la

Organización

Email Ingeniero en

Informática

Jonathan Durán Gerente de

Proyectos

 jonathan.duran@softbuilder.cl Ingeniero en

Informática

Francisco Mendoza Gerente Comercial francisco.mendoza@softbuilder.cl Ingeniero en

Informática

Claudio Jara Gerente De

Desarrollo

(10)

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.

(11)

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

(12)

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%

(13)

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

(14)

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.

(15)

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.

(16)

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.

(17)

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.

(18)

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.

(19)

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.

(20)

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

(21)

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.

(22)

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.

(23)

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.

(24)

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.

(25)

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.

(26)

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 Proye cto 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 Me nsual Proye cto e n 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%

(27)

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

(28)
(29)

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 ?

(30)

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 ?

(31)

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

(32)

31

BPMN PROCESO DE VENTA

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

(33)

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.

(34)

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.

(35)

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

(36)

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

(37)

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

(38)

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.

(39)

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

(40)

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

(41)

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

(42)

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:

(43)

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

(44)

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 N iv e l d e P ro b a b ili d a d 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

(45)

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

(46)

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.

(47)

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

Ingreso con Login y tablas

Se debe mantener un registro del ingreso de todos los usuarios como también el historial de modificaciones sobre la información del sistema,

(48)

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

(49)

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.

N iv e l d e P ro b a b ili d a d Alto Medi o 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

(50)

49

MODELO DE BASE DE DATOS

MODELO CONCEPTUAL

(51)

50

MODELO LÓGICO

(52)

51

MODELO FISICO

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.

(53)

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.

(54)

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.

Figure

Actualización...

Referencias

Actualización...

Related subjects :