Especificacin de Gestin y Diseo

Sistema Carta Virtual

Administracin de Restaurants

Profesor a Cargo:
Juan Pablo Zuiga
Integrantes de este Trabajo:
Jonathan Durn
Francisco Mendoza
Claudio Jara
Curso:
Taller de Proyecto de Software - Seccin 379
Fecha:

08 de Junio 2015

Proyecto
ID Documento
Nombre Documento
Autor

SB Administracin de Restaurant
SW-PRJ-01
Estado
En Construccin
Acta de constitucin de proyecto
SoftBuilder
Fecha
01/04/2015

Versin

1.8

Versin

Fecha Revisin

Descripcin de la Revisin

Autor

<1.0>
<1.8>

01-04-2015
08-06-2015

Se crea documento
Modificacin del documento para agregar nuevos
requerimientos.

SoftBuilder
SoftBuilder

Fecha
Aprobacin

Aprobador

Rol/Cargo

Firma

CONTENIDO

PROPSITO ................................................................................................................... 6
DESCRIPCIN DEL USUARIO ........................................................................................... 6
IDENTIFICACIN ........................................................................................................................ 6
ANTECEDENTES......................................................................................................................... 7
ORGANIGRAMA ........................................................................................................................ 8
CONTEXTO PROYECTO ................................................................................................................ 9

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

MENON ............................................................................................................................. 10
EASYPOS .............................................................................................................................. 10
MARCO TERICO CONCEPTUAL ................................................................................... 12
DEFINICIN Y DESCRIPCIN DEL MERCADO OBJETIVO ................................................. 13
SITUACIN ACTUAL ..................................................................................................... 14
IDENTIFICACIN DEL PROBLEMA ................................................................................................. 15
IMPACTO ASOCIADO ................................................................................................................ 15
MISION Y VISION ..................................................................................................................... 16

REQUERIMIENTOS FUNCIONALES ................................................................................ 17

REQUERIMIENTOS DE VENTAS .................................................................................................... 17
REQUERIMIENTOS DE ADMINISTRACIN ....................................................................................... 19

REQUERIEMINTOS DE GESTIN ESTRATGICA................................................................................ 21

REQUERIMIENTOS NO FUNCIONALES........................................................................... 22
PERFORMANCE ...................................................................................................................... 22
SEGURIDAD DE LA INFORMACIN ............................................................................................... 22
RESTRICCIONES ....................................................................................................................... 23
ALCANCES ............................................................................................................................. 24
USABILIDAD ........................................................................................................................... 24
LICENCIAS .............................................................................................................................. 24
COSTOS ASOCIADOS AL PROYECTO .............................................................................. 25
ESTUDIO DE FACTIBILIDAD........................................................................................... 26
CARTA GANTT ............................................................................................................. 27

ANLISIS DE MERCADO ............................................................................................... 28

CICLO DE VIDA Y METODOLOGA DE DESARROLLO ....................................................... 30
VENTAJAS ............................................................................................................................. 30
BPMN PROCESO DE VENTA .......................................................................................... 31
RIESGOS ...................................................................................................................... 32
METODOLOGA DE GESTIN DE RIEGOS ...................................................................................... 33
IDENTIFICACIN Y ANLISIS....................................................................................................... 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 GESTIN DE LOS RIEGOS........................................................................ 44
DS5.4 Administracin de cuentas del usuario ................................................................ 44
DS5.5 Pruebas, vigilancia y monitoreo de la seguridad ................................................. 44
DS5.8 Administracin de llaves criptogrficas ............................................................... 44
DS5.9 Prevencin, deteccin y correccin de software malicioso ................................. 45
DS5.10 Seguridad de la red ............................................................................................ 45
1.1

ANLISIS DE RIESGOS. ........................................................................................ 45

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

MODELO CONCEPTUAL ............................................................................................................ 49
MODELO LGICO .................................................................................................................... 50
MODELO FISICO ................................................................................................................... 51
SISTEMA DE GESTIN DE LA BASE DE DATOS ............................................................... 52
MYSQL................................................................................................................................. 52
CARACTERSTICAS. .................................................................................................................. 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

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: ANLISIS DE RIEGOS................................................................................................................................ 47

IMAGEN 1: ORGANIGRAMA. ............................................................................................................ 8

PROPSITO

En la actualidad, la creciente tecnologa 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 tecnologa en sus procesos que conlleva a una
experiencia o servicio deficientes para los clientes.
Frente a esta situacin, el presente proyecto plantea una solucin orientado a mejorar los
procesos de atencin, pago y administracin a travs de una solucin web, que permitir
a clientes y empleados poder acceder a una rpida atencin, llevando la experiencia del
cliente a altos estndares.

DESCRIPCIN DEL USUARIO

IDENTIFICACIN

La gama de perfiles que se encuentra en el ambiente de restaurant es muy diversa, y

puede variar desde una persona que no posee ningn conocimiento en sistemas
informticos hasta usuarios muy avanzados. Para ofrecer un buen servicio y abarcar la
mayor parte de la poblacin, la aplicacin 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
caractersticas o necesidades.
Adems de los usuarios, tambin se debe considerar a los garzones, quienes son clave, en
el caso que el cliente no requiera (quiera o solicite) ser atendido mediante la opcin del
sistema.

ANTECEDENTES

SoftBuilder tiene sus inicios en el ao 2014 con la unin de tres socios, quienes teniendo
la informtica como visin de futuro forjan una alianza centrada en tres grandes reas de
especializacin: poder de anlisis, gestin de proyectos y desarrollo de sistemas.
Estas reas de especializacin, unido a la calidad de los productos y servicios mediante
una poltica de precios competitiva, amplios conocimientos del mercado tecnolgico y
junto a la aplicacin de conocidos paradigmas de anlisis 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 Administracin
y Contables, entre otros.
Actualmente se cuenta con un excelente equipo de profesionales con verdadera vocacin
de servicio en el rea de la informtica y un exclusivo desarrollo orientado al cliente, lo
cual permite ofrecer un producto integral de muy alta calidad.

ORGANIGRAMA

El organigrama estructural de la empresa:

Imagen 1: Organigrama.

Cargo en el Proyecto
Ingeniero en
Informtica
Ingeniero en
Informtica
Ingeniero en
Informtica

Nombre
Jonathan Durn
Francisco Mendoza
Claudio Jara

Cargo en la
Organizacin

Email

Gerente de
Proyectos
Gerente Comercial

jonathan.duran@softbuilder.cl

Gerente De
Desarrollo

francisco.mendoza@softbuilder.cl
claudio.jara@softbuilder.cl

Tabla 1 : Organigrama.

CONTEXTO PROYECTO

El contexto que se le otorga a este proyecto, radica en utilizar tecnologa de punta que
permita al restaurant sobresalir sobre su competencia a travs 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 bsico de servicio, que
es la atencin de garzn-cliente, el cual hasta el da de hoy se ha realizado siempre de
forma manual.
Una de las principales caractersticas para esta automatizacin, es otorgarle al cliente una
herramienta que le permita navegar y visualizar en lnea, todos los productos que el
restaurant ofrece y que actualmente se encuentran en stock, aadiendo 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 intervencin humana, y se obtiene una atencin ms
rpida, gil y sin porcentaje de error, como los presentados en la actualidad. Por ejemplo:
error del garzn al anotar un pedido, retraso de atencin por perdida de comandas,
cobros adicionales por concepto de cruza de comandas, entre otros.

MARCO REFERENCIAL

El siguiente apartado busca dar a conocer algunos antecedentes empricos con respecto al
producto a desarrollar, la importancia de estos datos radica en la entrega de informacin
sobre diversos productos que ya existen en el mercado, emanados del despliegue de
diversas empresas de desarrollo de software. En primera instancia tenemos a:
MENON

La carta digital MenOn es una aplicacin 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 telfono mvil.
Su caracterstica principal es la generacin de pedidos de mesa y pasarlos directamente a
cocina y solo est limitado a mostrar el men, sin tener mayor gestin en la
administracin.
EASYPOS

EasyPos es una solucin de punto de venta y administracin desarrollada por la empresa

METHODO, que tiene el fin de controlar y administrar el negocio.
Su caracterstica principal es la integracin de varias herramientas
Los dos sistemas se exponen para poder realizar una comparacin y determinar cules son
las caractersticas y requerimientos mnimos que debe tener el sistema, y desde esa base
poder innovar en el sistema a crear (Carta Virtual).
A continuacin se ilustra grficamente una tabla comparativa o Bechmarking:

10

Requerimiento de Ventas
Visualizacin 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 garzn
Transferencias de clientes entre mesas
Eliminacin de transacciones con cdigo de autorizacin
Seleccin de acompaamientos
Pagos individuales y total con o sin cierre de mesa
Manejo de diferentes tipos de pago
Descuentos con cdigo de autorizacin
Modulo de reserva
Eleccin de consumos directamente por clientes
Revisin o consulta de valor consumido, desde cualquier
dispositivo mvil
Adicin y sustraccin de ingredientes opcionales.
SLA de espera mostrado en los dispositivos (opcional)
% de cumplimiento
Requerimiento de Administracin
Cuadratura de caja
Modulo de administracin de usuarios con perfil de ingreso
Modulo de administracin de insumos, recetas y bodegas
Transferencia de insumos entre bodegas
Modulo de administracin de horarios y precios
Incluir instrucciones a los centros de produccin
Control de Stock
Generacin automtica de auditorias
SLA adaptable al nmero de personal disponible
Modulo de dotacin de personal
% de cumplimiento
Requerimiento de Gestin Estratgica
Generacin de reportes
Buscador de datos especficos
% 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

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

50%

70%

Men On

Easy Post

X
X
100%
66%

X
X
100%
79%

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 TERICO CONCEPTUAL

Software: es una palabra que proviene del idioma ingls, pero que gracias a la
masificacin de uso, ha sido aceptada por la Real Academia Espaola. Segn la RAE, el
software es un conjunto de programas, instrucciones y reglas informticas que permiten
ejecutar distintas tareas en una computadora. Definicion.de. (2015). Definicin de
Software. 2015, de Definicion.de Sitio web: http://definicion.de/software/
Tablet: es una computadora (ordenador) porttil ms grande que un Smartphone pero
ms pequea que una Netbook. Se caracteriza por contar con pantalla tctil: esto quiere
decir que para utilizar la Tablet no se necesita mouse (ratn) ni teclado.
Firewall: Un cortafuegos es una parte de un sistema o una red que est diseada 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 trfico 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 prcticas sobre el rea de inters, con el propsito de transferir el
conocimiento de las mejores prcticas y su aplicacin. El Benchmarking es una tcnica
para buscar las mejores prcticas que se pueden encontrar fuera o a veces dentro de la
empresa, en relacin con los mtodos, 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 prcticas segn lo aprendido, realizando los cambios necesarios, no se trata
solamente de copiar una buena prctica, sino que debe de efectuarse una adaptacin a las
circunstancias y caractersticas propias. Muoz, Leiva. (2003). Benchmarking. 2015, de
Wikipedia Sitio web: http://es.wikipedia.org/wiki/Benchmarking

12

DEFINICIN Y DESCRIPCIN DEL MERCADO OBJETIVO

Variables demogrficas
A continuacin se listan las principales variables demogrficas que se utilizaran para
definir el mercado objetivo:

Edad
Se considera que el rango de edad que se apuntara es entre los 18 y 40 aos, ya
que son ms adeptos a la tecnologa, por lo que tendran una aceptacin normal a
la iniciativa de que puedan solicitar por ellos mismo sus consumos a travs del
dispositivo mvil.

Ocupacin
Estudiantes de universidades, institutos profesionales y centros de formacin
tcnica como tambin trabajadores.

Lugar de Residencia
Zona oriente de Santiago especficamente en las comunas de providencia, las
condes, Vitacura y lo Barnechea.

Nivel socioeconmico
ABC1, C2, C3

Incorporando otras variables ms cualitativas al anlisis, 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 caractersticas:
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 aos, que residan en la zona oriente de la ciudad de
Santiago y que tengan nivel socioeconmico medio-alto. Con una segmentacin
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

SITUACIN ACTUAL

Existen varios tipos de servicios en los restaurantes, segn la forma de preparar, presentar
y servir los bebestibles y alimentos.
Actualmente en Chile unos de los servicios ms 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 ms y de mayor tamao, donde llevar la
administracin no es nada simple. Los dueos optan por diferentes modalidades para
aquello, variando segn el presupuesto del restaurant o simplemente las decisiones de
los dueos.
Nos encontramos con la situacin ms tradicional o clsica que es la atencin donde todo
el trabajo lo realiza el personal del restaurant, y por otro lado una un poco ms apegada a
la tecnologa que de igual manera lo realiza el mismo personal pero apoyndose con
alguno de los software de gestin y administracin ya existentes en el mercado para
restaurantes.

14

IDENTIFICACIN DEL PROBLEMA

En la actualidad la creciente tecnologa 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 administracin y gestin existentes de restaurantes que si bien cumplen
con lo requerido, carecen de tecnologa innovadora, como procesos lentos que conllevan
a una experiencia deficiente del servicio para los clientes, asimismo sistemas antiguos y no
actualizables.
Descripcin de la solucin: Para ello plantearemos una solucin orientada a mejorar los
procesos de atencin, pago y administracin a travs de una aplicacin web, que permitir
tanto a los clientes como a los empleados poder acceder a una rpida atencin llevando
su experiencia a altos estndares.
IMPACTO ASOCIADO

La implementacin de la solucin tendr varios impactos tanto en los clientes como en la

administracin del Restaurant.
Uno de ellos ser la innovacin, si bien los clientes ya han visto como los meseros
interactan con software de atencin en restaurantes, esta vez se lograra una nueva
forma de ser atendidos. Utilizando la tecnologa de de dispositivos mviles para
interactuar con ellos de una manera rpida y eficaz.
El cliente tendr opciones que nunca antes ha experimentado. Alguna de estas ser
transferencia y/o separacin de cuentas, consulta de consumo a travs de cualquier
Smartphone, entre muchas caractersticas nuevas, logrando en los consumidores un alto
grado de aceptacin con la calidad y rapidez de atencin. Gracias a esto, el Restaurant
aumentara su prestigio y ser cada vez ms concurrido.
La administracin del Restaurant no se queda atrs, sino todo lo contrario. El sistema
contar con mdulos BackOffice especialmente diseados para ese cometido, que llevar
la contabilidad del negocio de una manera fcil, ordenada y clara, donde los
administradores podrn generar informes, gestionar y administrar de una manera mucho
ms simple y completa.

15

MISION Y VISION

Misin
Satisfacer las necesidades del mercado, integrando soluciones tecnolgicas, con altos
estndares de calidad de servicios, metodologas y flexibilidad. Manteniendo un constante
aprendizaje de nuevas tecnologas con el fin de entregar un servicio de la ms alta calidad.

Visin
Ser lderes en la integracin de tecnologas de punta que permitan a nuestros clientes
optimizar sus procesos de negocios en tiempo real, mejorando la toma de decisiones
operacionales. Implementando tecnologas 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 terico determin cuales son los
requerimientos mnimos que debe tener el sistema para poder igualar las condiciones que
existen actualmente en el mercado. Adicionalmente se implementaran nuevos
requerimientos que generen la innovacin incremental que tendr el sistema.
REQUERIMIENTOS DE VENTAS

Id

<req01>

Versin

Nombre Corto
Requerimiento

Mdulo de ventas

Configuracin
del Requerimiento

Se necesita mdulo de ventas que permita:

<1.0>

1. Acceso al sistema con cuentas diferenciadas con perfil.

2. Visualizacin de las mesas en cada punto de venta.
3. Ventas asociadas a mesas individuales por garzn.
4. Eleccin de consumos directamente por clientes.
5. Varios consumos por mesa.
6. Seleccin de acompaamientos.
7. Adicin y sustraccin de ingredientes.
8. Mostrar el SLA de atencin parametrizado
9. Revisin o consulta del consumo en lnea con el
servidor a travs 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. Eliminacin de transacciones con cdigo de autorizacin.
14. Descuentos con cdigo de autorizacin.
Tabla 3: Requerimientos de ventas.

17

Id

<req02>

Versin

<1.0>

Nombre Corto
Requerimiento

Mdulo de consulta de cliente

Configuracin
del Requerimiento

Se necesita mdulo de consultas de cliente que permita:

1. Logeo con cdigo por parte del cliente.
2. Revisin o consulta del consumo en tiempo real.
3. Mostrar el SLA de atencin parametrizado
Tabla 4: Requerimientos de consulta cliente.

Id

<req03>

Versin

Nombre Corto
Requerimiento

Mdulo de reservas

Configuracin
del Requerimiento

Se necesita mdulo de reservas que permita:

<1.0>

1. Acceso al sistema con cuentas diferenciadas con perfil.

2. Visualizacin de las mesas
3. Registro de reservas.
4. Modificacin de estado de reserva.
Tabla 5: Requerimientos de ventas.

18

Id

<req04>

Versin

Nombre Corto
Requerimiento

Mdulo de caja

Configuracin
del Requerimiento

Se necesita mdulo de caja que permita:

<1.0>

1. Acceso al sistema con cuentas diferenciadas con perfil.

2. Visualizacin de las mesas.
3. Pagos individuales y total de mesas.
4. Impresin de boletas
5. Cuadratura de caja
Tabla 6: Requerimientos de caja.

REQUERIMIENTOS DE ADMINISTRACIN

Id

<req05>

Versin

Nombre Corto
Requerimiento

Mdulo de usuarios

Configuracin
del Requerimiento

Se necesita mdulo 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. bsqueda de usuarios.
5. Asignacin de perfiles
Tabla 7: Requerimientos de usuarios.

19

Id

<req06>

Versin

Nombre Corto
Requerimiento

Mdulo de recetas

Configuracin del
Requerimiento

Se necesita mdulo 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. bsqueda de recetas.
Tabla 8: Requerimientos de recetas.

Id

<req07>

Versin

Nombre Corto
Requerimiento

Mdulo de bodega

Configuracin
del Requerimiento

Se necesita mdulo 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. bsqueda de insumos.
5. Control de Stock
6. Transferencia de insumos entre bodegas.
Tabla 9: Requerimientos de bodega.

20

Id

<req08>

Versin

Nombre Corto
Requerimiento

Mdulo de horarios y precios

Configuracin
del Requerimiento

Se necesita mdulo 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. bsqueda de horarios y precios.
Tabla 9: Requerimientos de horarios y precios.

REQUERIEMINTOS DE GESTIN ESTRATGICA

Id

<req08>

Versin

Nombre Corto
Requerimiento

Mdulo de reportes

Configuracin
del Requerimiento

Se necesita mdulo de auditoras que permita:

<1.0>

1. Acceso al sistema con cuentas diferenciadas con perfil.

2. Generacin de reportes con informacin de ventas.
3. Generacin de reportes de auditoras.
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 simultneos 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 tcnico, logrando mantener la integridad de los datos y mantenindose
activa durante alguna posible falla.
El sistema tendr los las siguientes caractersticas:
Operatividad: la capacidad de la aplicacin para que sus usuarios operen y controlen los
procesos que realiza.
Tolerancia a fallas: es la habilidad que tiene la aplicacin para mantener un nivel
especfico de funcionamiento en caso de fallas.
Rendimiento: especifica qu tan bien o qu tan rpido, debe la aplicacin ejecutar una
funcin dada en trminos de:
Velocidad (tiempo promedio de acceso a datos)
Tiempo (demanda de tiempo real)

SEGURIDAD DE LA INFORMACIN

El sistema debe satisfacer los pilares fundamentales de la seguridad de la informacin:

Confidencialidad: Asegurar que la informacin sea accesible solo para aquellos
usuarios autorizados.
Integridad: Salvaguardar que la informacin y los mtodos de procesamiento sean
exactos y completos.
Disponibilidad: Asegurar que los usuarios autorizados tengan acceso a la informacin
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 Sistema de Administracin con roles de usuario. Este sistema ser de uso

interno por parte del restaurant, y deber filtrar segn cargos el acceso a la
informacin confidencial del restaurant.
o Men virtual en la Tablet, que ser la cara visible frente cliente. Aqu se incluir
una capa de presentacin bsica pero robusta, en donde el cliente solamente
podr realizar una navegacin dentro de la carta y realizar la seleccin de los
productos que desea consumir, con el fin de no permitir la digitacin de datos
con el fin de descartar el ingreso de datos no vlidos.
o Seguridad a nivel de hardware, el cual incluye bloqueo por MAC, para evitar el
acceso de dispositivos indebidos al sistema.

RESTRICCIONES

A continuacin, se listarn puntos los cuales estn considerados como restriccin dentro
del sistema CartaVirtual:

- El sistema se prestar al cliente como un recurso en arriendo, por ende cualquier

intento de modificacin o sustraccin del sistema ser motivo para dar fin al
contrato.

- El sistema no contempla ninguna funcionalidad adicional, salvo las ya establecidas en

el diseo original del sistema. En caso contrario se negociar como proyecto de
modificacin.

- El sistema y su seguridad, est dado para ser trabajado en una plataforma Web bajo
Intranet, y no Internet. Por ende su publicacin 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 sern 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 versin que final, que ser
entregada al cliente.
1- Suministrar un terminal central para la implementacin de la base de datos.
2- Suministrar el producto de software.
3- Suministrar equipos mviles (Tablet).
4- Configuracin de la red inalmbrica.
USABILIDAD

El producto de software debe contar con un alto grado de usabilidad para que sus
usuarios puedan realizar pedidos y administracin de sitio sin dificultad, logrando el xito
de las transacciones.
LICENCIAS

El sistema deber funcionar sin necesidad de adquirir ningn tipo de licencia de ejecucin,
o cualquier otro software especfico. Ser administrado y desarrollado bajo sistemas de
Software Libre GNU, somo son:
- Sistema Operativo Linux - Versin UBUNTU 14.0.
- Lenguaje de Programacin 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 Proyecto
Tiempo de desarrollo del Proyecto

Carta Virtual
12

Meses

Personal Asociado al Proyecto

Programador Freelance
Programador Senior
Analista de Sistemas
Ingeniero de Sistemas

Costo Neto
400.000
600.000

Costo Bruto
Meses en Proyecto
Total
480.000
8 3.840.000
720.000
12 8.640.000

800.000
1.100.000

960.000
1.320.000

1
960.000
1 1.320.000
Costo Total Proyecto 14.760.000

Tiempo de Desarrollo
Tiempo estimado Estudio Proyecto
Costo Mensual Proyecto en 1 ao
Costo de Inversin Anual Min.
Costo Asociado al Proyecto

12 Meses
5 Aos
1.230.000
246.000
20.500

Valor Base UF
Soporte
Software
% Ganancia Mensual
Valor Mensual:

0,82
0,40
0,50
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, UOA, 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 clculo mensual esperado para el producto es de: 1,75 UF * 110 (DE) = 176 UF
mensuales.
Por consiguiente, el costo del proyecto se estara pagando al primer ao 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 ao ingresos y egresos basados en 1 cliente.

Segundo y tercer ao ingresos y egresos basados en 2 cliente.
Cuarto y quinto ao ingresos y egresos basados en 3 cliente.
Costo inicial calculado en base a gastos de desarrollo ms equipamiento.

ESTUDIO DE FACTIBILIDAD

Carta virtual se dirigir al mercado objetivo que tendr las siguientes caractersticas:
Restaurantes del sector oriente de Santiago que carezcan de innovacin tecnolgica o
requieran implementar un software para llevar su negocio.
SoftBuilder pretende atraer clientes mediantes algunas estrategias de marketing y
promocin. De las cuales sern las siguientes:
Visitas en terreno o reuniones: Se visitarn presencialmente restaurantes
consiguiendo reuniones con los administradores o dueos para a travs de una
presentacin formal se les dar a conocer nuestro producto.
Publicidad: SoftBuilder har publicidad a travs de diferentes medios de la web, como
redes sociales, banners publicitarios, pgina web corporativa, entre otros.
Relaciones pblicas: Se crearn relaciones con dueos de restaurantes asistiendo a
eventos de este tipo de negocio e interiorizando en l.
Todo lo anterior ser realizado por personal especializado en Marketing Estratgico
Digital, quienes estarn encargados de ofrecer nuestro producto consiguiendo reuniones
con administrativos o dueos de Restaurantes.

26

CARTA GANTT

27

ANLISIS DE MERCADO

A continuacin se mostrarn los resultados obtenidos de encuestas realizadas a travs de

formularios webs de Google www.google.com/Forms.
1.
Se realiz la siguiente pregunta para as saber cunto porcentaje de las personas
encuestadas asistiran a un restorn en el cual se aplica nueva tecnologa.
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 tecnologa o la encontraban complicada. A continuacin los resultados:

Usted ira a un restaurante con

servicio de autoatencin con
tablet?
16%

84%

Si

No

2.
La siguiente encuesta se realiz para hacerse una idea de saber si implementaran
nuestro producto ponindose en la situacin de dueos de restaurantes.
La mayor parte fue una respuesta positiva ya que les pareca novedoso y til, y la parte
negativa se basaba en que no lo encontraba algo relevante para el negocio.

Si fuera dueo de un
restaurant implementara
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

Ms de 4 veces al Mes

4.
Preguntamos lo siguiente en la encuesta para saber qu tan importante es para la
gente la tecnologa, algo que nos afecta directamente y nos sirve como fundamentos para
luego ofrecer nuestros productos a dueos y administradores de restaurantes.

Consideras que el uso de

tecnologa en un restaurante
hace que ste resulte ms
atractivo ?

26%

74%

Si

No

29

CICLO DE VIDA Y METODOLOGA DE DESARROLLO

Para este proyecto utilizaremos el ciclo de vida y a la vez metodologa de desarrollo

Evolutivo.
El ciclo de vida y modelo de desarrollo evolutivo asume que los requerimientos estn
sujetos a cambios continuos. Esto en nuestro proyecto se ver reflejado en los
requerimientos de cada restorn, ya que el software deber adaptarse a las necesidades
del restorn, teniendo as que incluso desarrollar mejoras o adaptaciones para este.
Por todo lo anterior este es el ciclo de vida y metodologa de desarrollo que mejor se
adapta a nuestro proyecto
Una mejor explicacin en el siguiente esquema.

VENTAJAS

Este modelo o ciclo de vida tiene una gran ventaja para nosotros en comparacin 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 metodologa es estricta en cuanto a que
cada proceso o fase tiene que esperar el trmino 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

Segn la real academia de la lengua espaola (RAE) define riesgo como Riesgo proviene
del italiano risico o rischio que, a su vez, tiene origen en el rabe clsico rizq (lo que
depara la providencia). El trmino hace referencia a la proximidad o contingencia de un
posible dao.(RAE, 2014).
En trminos del Riesgo Tecnolgico se podra definir como: la posibilidad de prdidas
derivadas de un evento relacionado con el acceso o uso de la tecnologa, que afecta el
desarrollo de los procesos del negocio y la gestin de riesgos de la organizacin, al
comprometer o degradar las dimensiones crticas de la informacin (Ej. confidencialidad,
integridad , disponibilidad).
En ese sentido, en COBIT 5 for Risk (COBIT) define el Riesgo de TI como un riego para el
negocio, especficamente el asociado con el uso, propiedad, operacin, involucramiento,
influencia y adopcin 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 Gestin 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

METODOLOGA DE GESTIN DE RIEGOS

Para poder gestionar lo mencionado anteriormente, se utilizara un modelo de gestin de

riegos, que es el ms utilizado y consta de 5 pasos (Identificacin, Anlisis, Planificacin,
Seguimiento y Control) secuenciales e iterativos, paralelamente dos actividades comunes
a ellos: las de documentacin y comunicacin.

33

IDENTIFICACIN Y ANLISIS

Es el paso ms importante en la gestin 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 determinacin de los elementos de riesgos potenciales, se utilizara la identificacin
en base a taxonomas que implica el utilizar una estructura agrupadora de los mismos, se
detallan a continuacin los riegos ms relevantes que se deben tener en consideracin a
lo largo del proyecto, categorizados y priorizados.

N
Misin y
Objetivos

Factor

Indicador

Probabilidad Impacto

Flujo de trabajo

Se prevn cambios significativos en

el flujo de trabajo.

Baja

Media

El proyecto se
adecua a la
organizacin
cliente

El proyecto no se relaciona con la

misin y objetivos de la organizacin
cliente.

Baja

Media

Media

Media

Alta

Alta

Conductores
para la Toma de
Decisiones
3

Estimaciones

Datos histricos

Las estimaciones de tamao,

esfuerzo y costos han sido realizadas
sin seguir un proceso formal y sin
una validacin final.
No se emplean datos histricos
para realizar estimaciones y
determinar niveles esperados de
productividad y calidad

Gerenciamiento
Organizacional

34

Roles y
responsabilidades
organizacionales

Polticas y
estndares

Objetivos de
proyecto

Los individuos en la organizacin

no comprenden sus roles y
responsabilidades ni la de los
dems.
Las polticas y estndares 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
notificacin previa.

Media

Media

Media

Media

No existe un sistema establecido.

Media

Media

Media

Media

Baja

Baja

Baja

Baja

Baja

Baja

Cliente/Usuarios
8

Necesidades de
entrenamiento
de los usuarios

Las necesidades de entrenamiento

de los usuarios no han sido
consideradas.
No se ha realizado una
Justificacin a los
justificacin del sistema a los
usuarios
usuarios o la misma resulta
inadecuada.

10

Presupuesto

11

Restricciones
presupuestarias

12

Controles de
costo

Ingeniera 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 ambigedades y
entendimiento con el cliente.
Los requerimientos expresan
algunas de las necesidades de los
clientes y no han sido validados

35

diferentes tcnicas.

17

Viabilidad

18

Antecedencia

La mayor parte de los

requerimientos no son
tcnicamente implementables tanto
individual como grupalmente.
Solo algunos de requerimientos se
relacionan con actividades y
tecnologas antes implementadas
en industria.

Baja

Media

Baja

Media

Baja

Baja

Media

Alta

Baja

Baja

Diseo
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 solucin
asociada.
Las caractersticas del producto
dificultan la realizacin de pruebas
y el personal que las desarrollar
no ha sido involucrado en el
proceso de diseo.

Cdigo 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 difcilmente alcanzables
comparados con valores histricos
de la industria o la organizacin.

Baja

Media

Uso de un
proceso de
ingeniera

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 mtodos 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 revisin 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
administracin
de proyectos

Planificacin y monitorizacin del

producto y proyecto inexistentes.

Media

Media

33

Comunicacin

Espordicamente se comunican los

objetivos y el estado entre el
equipo y el resto de la
organizacin.

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
Documentacin
de Desarrollo
Identificacin
temprana de
defectos
Seguimiento de
defectos
Proceso de
control de
cambios

Administracin
de Proyectos
32

35

37

36

Autoridad

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

Baja

Media

Prdidas y cambios frecuentes y

poca posibilidad de retencin.

Baja

Alta

Mala combinacin 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
Combinacin de
habilidades del
equipo
Comunicacin
interna del
equipo

Escasa o ninguna experiencia en

proyectos similares, puede ser
hardware, software o en procesos
similares.
No existen plan de entrenamiento
Entrenamiento
o el entrenamiento requerido no
del equipo
est disponible
Escasamente comprometido con
Espritu 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.

Experiencia en la
aplicacin

Mantenimiento
44

Complejidad de
diseo

45

Soporte del
personal

Extremadamente difcil de
mantener.
Personal no disponible, no
experimentado y en un nmero
reducido.

Los riegos identificados y analizados anteriormente pueden impactar directamente en los

objetivos de proyecto, aumentando los costos significativamente, como tambin el
tiempo necesario para lograr los objetivos. Tambin pueden causar una disminucin de la
calidad, no cumpliendo con los estndares necesarios para lograr el objetivo de forma
ptima.
38

IMPACTO

A continuacin 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

Reduccin de
calidad
requiere la
aprobacin

Reduccin del
alcance
inaceptable

Reduccin de
calidad
inaceptable por
el cliente
39

del cliente

PLAN DE RESPUESTA

Para realizar la planificacin o identificar las respuestas a los posibles riesgos, se utilizaran
reuniones peridicas para poder determinar las amenazas y oportunidades que pueden
afectar al xito del proyecto, se debatir peridicamente para dar una respuesta rentable
en relacin al desafo a cumplir, realista dentro del contexto del proyecto, sern
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 direccin del proyecto, a fin de eliminar por
completo la amenaza. El director del proyecto tambin 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 ampliacin del cronograma, el cambio de estrategia o la
reduccin del alcance. La estrategia de evasin ms drstica consiste en anular por
completo el proyecto. Algunos riesgos que surgen en etapas tempranas del proyecto
pueden ser evitados aclarando los requisitos, obteniendo informacin, mejorando la
comunicacin 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 gestin; no lo
elimina. La transferencia de la responsabilidad de un riesgo es ms efectiva cuando se
trata de la exposicin 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,
garantas de cumplimiento, fianzas, certificados de garanta, etc. Pueden emplearse
contratos para transferir a un tercero la responsabilidad de riesgos especficos. 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 ms efectivo que
tratar de reparar el dao despus de ocurrido el riesgo. Ejemplos de acciones tendientes a
mitigar un riesgo son adoptar procesos menos complejos, efectuar ms pruebas o
seleccionar un proveedor ms estable. Por ejemplo, la mitigacin puede requerir la
creacin de un prototipo para reducir el riesgo de pasar de un modelo a escala de un
proceso o producto a uno de tamao real. Cuando no es posible reducir la probabilidad,
una respuesta de mitigacin puede abordar el impacto del riesgo, dirigindose a los
vnculos que determinan su severidad. Por ejemplo, disear 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 direccin 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 aceptacin pasiva no requiere ninguna accin, excepto documentar la
estrategia, dejando que el equipo del proyecto aborde los riesgos conforme se presentan.
La estrategia de aceptacin activa ms comn 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
organizacin 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 explotacin directa
de las respuestas incluyen la asignacin al proyecto de recursos ms talentosos de la
organizacin para reducir el tiempo hasta la conclusin 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 formacin de
asociaciones de riesgo conjunto, equipos, empresas con finalidades especiales o uniones
temporales de empresas, que pueden establecerse con el propsito 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 identificacin y maximizacin 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 adicin de ms recursos a una
actividad para terminar ms 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 gestin de riesgos, se rastrearan los riesgos
identificados, evaluando si se deben seguir respetando las polticas y los procedimientos,
tambin se evaluaran los cambios de cada uno de ellos como tambin si pasan al estado
de obsolescencia.
Al monitorear y controlar los riesgos, se irn identificando nuevos riesgos asociados al
proyecto.
El monitoreo y control de riegos se programara peridicamente y se abordara como punto
de orden del da en cada reunin sobre el estado del proyecto, para mantener actualizado
los procesos y as minimizar posibles amenazas, el da y horario especfico se determina en
el cronograma de proyecto.
MATRIZ DE RIEGOS

20

45

Alto

Nivel de Probabilidad

Medio

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

35
42

37

Alto

Nivel de Impacto
43

RIEGOS EN EL AMBIENTE DEL CLIENTE

PROCESOS COBIT SOBRE GESTIN 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 ADMINISTRACIN DE CUENTAS DEL USUARIO

Garantizar que la solicitud, establecimiento, emisin, suspensin, modificacin 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
informacin de la empresa son acordados contractualmente para todos los tipos de
usuarios. La gerencia debe llevar a cabo una revisin regular de todas las cuentas y los
privilegios asociados.
DS5.5 PRUEBAS, VIGIL ANCIA Y MONITOREO DE LA SEGURIDAD

Garantizar que la implementacin de la seguridad en TI sea probada y monitoreada de

forma pro-activa. La seguridad en TI debe ser re acreditada peridicamente para
garantizar que se mantiene el nivel seguridad aprobado. Una funcin de ingreso al sistema
(login) y de monitoreo permite la deteccin oportuna de actividades inusuales o
anormales que pueden requerir atencin. El acceso a la informacin de ingreso al sistema
est alineado con los requerimientos del negocio en trminos de requerimientos de
retencin y de derechos de acceso.
DS5.8 ADMINISTRACIN DE LLAVES CRIPTOGRFICAS

Determinar que las polticas y procedimientos para organizar la generacin, cambio,

revocacin, destruccin, distribucin, certificacin, almacenamiento, captura, uso y
archivo de llaves criptogrficas estn implantadas, para garantizar la proteccin de las
llaves contra modificaciones y divulgacin no autorizadas.

44

DS5.9 PREVENCIN, DETECCIN Y CORRECCIN DE SOFTWARE MALICIOSO

Garantizar que se cuente con medidas de prevencin, deteccin y correccin (en especial
contar con parches de seguridad y control de virus actualizados) a lo largo de toda la
organizacin para proteger a los sistemas de informacin y a la tecnologa contra software
malicioso (virus, gusanos, spyware, correo basura, software fraudulento desarrollado
internamente, etc.).
DS5.10 SEGURIDAD DE LA RED

Garantizar que se utilizan tcnicas de seguridad y procedimientos de administracin

asociados (por ejemplo, firewalls, dispositivos de seguridad, segmentacin de redes, y
deteccin de intrusos) para autorizar acceso y controlar los flujos de informacin desde y
hacia las redes.

1.1

ANLISIS DE RIESGOS.

45

ID

Mejor Practica Segn Porcentaje

COBIT para Gestin
de
Impacto
de Riesgos
Ocurrencia
B M A B M A

R5.4.1

Solicitud, Establecimiento y
Emisin de Cuentas de
Usuarios

R5.4.2

Suspensin de Cuentas de
Usuarios

R5.4.3

Modificacin de Cuentas
de Usuarios

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 podra 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
suspensin de una cuenta, el no respetar esta
norma podra causar un alto impacto ya que un
usuario el cual es desvinculado y su acceso al
X
sistema no sea suspendido de inmediato, podra
concretar algn tipo de ataque a las
funcionalidades criticas del sistema el cual
pudiera paralizar las ventas. Alto.
Se debe tener la posibilidad de realizar la
modificacin de una cuenta, al no respetar esta
norma podra 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 podra causar un alto impacto al
permitir que todos los usuarios interacten con
todas las funcionalidades pudiendo llegar a
paralizar las ventas en el peor de los casos. Alto

R5.4.6

Revisin regular de todas

las cuentas y los privilegios
asociados

R5.5.1

Ingreso con Login y tablas

de control para auditorias.

Consecuencia

Debe aplicar para todos los usuarios ya que un

X ataque puede ser concretado por cualquier
usuario. Alto

Se debe realizar un monitoreo de forma

peridica 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 podra causar un alto
impacto si se llegase a concretar algn tipo de
ataque a las funcionalidades criticas del sistema
el cual podra paralizar las ventas. Alto
Se debe mantener un registro del ingreso de
todos los usuarios como tambin el historial de
modificaciones sobre la informacin del sistema,
el no respetar esta norma podra causar un
impacto medio si un usuario realiza
modificaciones no autorizadas. Medio

46

R5.8.1

Formato de clave

R5.9.1

Prevencin, deteccin y
correccin de software
malicioso

R5.10.1

Seguridad de la red

Se debe mantener las claves de usuario como

llaves criptogrficas en la base de datos, al no
respetar esta norma podra causar un alto
impacto si un usuario no autorizado accede a las
X
cuentas y hace un uso malicioso de ellas
llegando a concretar algn tipo de ataque a las
funcionalidades criticas del sistema el cual
podra paralizar las ventas. Alto
Se debe hacer uso de un software para proteger
a los sistemas de informacin y a la tecnologa
contra software malicioso, el no respetar esta
X norma podra causar un alto impacto si se
llegase a concretar algn tipo de ataque a las
funcionalidades crticas del sistema el cual
podra paralizar las ventas. Alto
Se deben utilizan tcnicas de seguridad y
procedimientos de administracin asociados
(por ejemplo, firewalls, dispositivos de
seguridad, segmentacin de redes, y deteccin
X de intrusos, el no respetar esta norma podra
causar un alto impacto si se llegase a concretar
algn tipo de ataque a las funcionalidades
criticas del sistema el cual podra paralizar las
ventas. Alto

Tabla 112: Anlisis de Riegos.

47

A continuacin se especifica el impacto que pueden tener los riesgos en la organizacin

dependiendo de su prioridad:
Escala de Impactos en Riesgos
Bajo

Moderado

Alto

Costos

5% - 10%

10%-20%

100%

Consecuencia

Reduccin la calidad
de atencin

Reduccin de las ventas y la

calidad de atencin

Parlisis de
las Ventas

Alcance

Reduccin la calidad
de atencin

Reduccin de las ventas y la

calidad de atencin

Parlisis de
las Ventas

Tabla 13: Matriz de Impacto de Riegos.

Nivel de Probabilidad

Alto

R5.5.1

R5.10.1

Medi
o
R5.4.1

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 LGICO

50

MODELO FISICO

51

SISTEMA DE GESTIN DE LA BASE DE DATOS

MYSQL

MySQL es un sistema de administracin de bases de datos. Una base de datos es una

coleccin estructurada de tablas que contienen datos, esta puede ser desde una simple
lista de compras a una galera de pinturas o el vasto volumen de informacin 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.
CARACTERSTICAS.

Entre las caractersticas disponibles en la ltima versin se puede destacar:

Amplio subconjunto del lenguaje SQL.

Disponibilidad en gran cantidad de plataformas y sistemas (Windows, Linux).
Posibilidad de seleccin de mecanismos de almacenamiento que ofrecen
diferentes velocidades de operacin, soporte fsico, capacidad, distribucin
geogrfica, transacciones.
Transacciones y claves forneas.
Conectividad segura.
Replicacin.
Bsqueda e indexacin de campos de texto.
Adems de un rpido y fcil uso de recursos tales como: Procedimientos
almacenados y desencadenadores (triggers).

PORQUE ELEGIR MYSQL?

Velocidad y Flexibilidad
MySQL es un sistema de administracin 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 estn conectadas por relaciones
definidas que hacen posible combinar datos de diferentes tablas sobre pedido.
Software Libre
MySQL Community Edition es una versin de descarga gratuita de la base de datos de
cdigo abierto ms popular del mundo, que se apoya en una comunidad activa de

52

desarrolladores y entusiastas del cdigo 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 solucin 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 nmero de servidores que tendremos
que manejar, podremos obtener la versin de forma gratuita y el fin de mantener el mejor
servicio y permitiendo un bajo costo de mantencin.
Pandora FMS es una herramienta de monitorizacin que no slo mide sin un parmetro
est bien o mal. Pandora FMS puede cuantificar el estado (bien, mal y valores
intermedios) o almacenar un valor (numrico o alfanumrico) 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,
estadsticas, niveles de adecuacin 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:
Verificacin de la conectividad con la base de datos.
Chequear si el proceso de MYSQL est activo.
Chequeo de memoria del servidor.
Nmero de conexiones TIME_WAIT en el sistema.
Chequeo de espacio en disco del servidor.
Tamao del fichero IBDATA1.
Bsqueda de errores en los logs de la base de datos.

53

Adicionalmente tambin es posible monitorear los siguientes parmetros de rendimiento:

Nmero de conexiones activas MySQL.
Tiempo de actividad del servidor (uptime)
Nmero de conexiones abortadas por que el cliente no cerr correctamente.
Nmero de bytes recibidos por los clientes.
Nmero de bytes enviados por lo clientes.
Nmero de inserciones en la base de datos.
Nmero de bloques sobre tablas en la base de datos al realizar una transaccin.
Tamao total de datos en GB.

54