taller de infraestructura informe iii

Especificacin de Gestin y Diseo Sistema Carta Virtual Administracin de Restaurants

Taller de Infraestructura Alumnos: Claudio Jara

Francisco Mendoza Jonathan Durn

Proyecto SB Administracin de Restaurant

ID Documento SW-PRJ-01 Estado En Construccin Versin 1.5

Nombre Documento Acta de constitucin de proyecto

Autor SoftBuilder Fecha 01/04/2015

2

Contenido.

1 INTRODUCCIN. ................................................................................................................ 5

2 ALCANCE. .......................................................................................................................... 5

3 OBJETIVOS. ........................................................................................................................ 5

3.1 OBJETIVOS GENERALES. .............................................................................................................. 5

3.2 OBJETIVOS ESPECFICOS. ............................................................................................................. 6

4 DEFINICIN DEL PROBLEMA. .............................................................................................. 6

5 JUSTIFICACIN. .................................................................................................................. 6

6 PLANIFICACIN ESTRATGICA. ........................................................................................... 7

6.1 INFORMACIN DE LA COMPAA. ................................................................................................. 7

6.1.1 Antecedentes, Productos y Actividades. ........................................................................ 7

6.1.2 Organigrama. ................................................................................................................ 8

6.2 CLIENTES.................................................................................................................................. 9

6.3 PLAN ESTRATGICO DE LA COMPAA. ........................................................................................ 10

6.3.1 Misin. ......................................................................................................................... 10

6.3.2 Visin. .......................................................................................................................... 10

6.3.3 Valores. ........................................................................................................................ 10

6.4 PLAN ESTRATGICO DE LA COMPAA. ........................................................................................ 11

6.4.1 Qu tan Fuerte es la Competencia? ........................................................................... 11

MENON ......................................................................................................................................... 11

EASYPOS .......................................................................................................................................... 11

7 PLAN TCTICO. ................................................................................................................ 13

8 PLAN OPERACIONAL. ....................................................................................................... 14

9 ACUERDO DE NIVELES OPERACIONAL Y DE SERVICIOS. ...................................................... 14

9.1 DISPONIBILIDAD. ..................................................................................................................... 14

9.2 CONTINUIDAD ........................................................................................................................ 15

9.3 GESTIN DE INCIDENCIAS Y PETICIONES DE SERVICIO. .................................................................... 15

9.4 PENALIZACIONES POR INCUMPLIMIENTO. .................................................................................... 16

9.5 FINALIZACIN. ........................................................................................................................ 17

10 ELECCIN DE DISEO DE COMUNICACIONES Y DE SERVIDORES. ..................................... 17

11 ELECCIN DE BASE DE DATOS. ...................................................................................... 18





3

11.1 MYSQL .............................................................................................................................. 18

11.2 PORQUE ELEGIR MYSQL? .................................................................................................... 19

12 INTEGRACIN DE DATOS. ............................................................................................. 19

13 GESTIN DE ADQUISICIONES ........................................................................................ 20

14 COSTOS Y GANANCIAS .................................................................................................. 23

7 PLAN DE IMPLEMENTACIN ............................................................................................. 24

7.1 OBJETIVO ............................................................................................................................... 24

7.2 PREPARACIN ......................................................................................................................... 24

7.2.1 Prerrequisitos de Hardware ......................................................................................... 24

7.2.2 Prerrequisitos de Red ................................................................................................... 24

7.2.3 Prerrequisitos de software........................................................................................... 25

7.3 VALIDACIONES POSTERIORES. .................................................................................................... 25

8 RIESGOS .......................................................................................................................... 26

8.1 METODOLOGA DE GESTIN DE RIESGOS. .................................................................................... 27

8.2 IDENTIFICACIN Y ANLISIS. ...................................................................................................... 28

8.3 IMPACTO. .............................................................................................................................. 33

8.4 PLAN DE RESPUESTA. ............................................................................................................... 34

8.5 MONITOREO Y CONTROL DE RIESGOS. ........................................................................................ 36

8.6 MATRIZ DE RIEGOS. ................................................................................................................. 37

8.7 RIESGOS EN EL AMBIENTE DEL CLIENTE. ...................................................................................... 38

8.7.1 Procesos COBIT sobre la gestin de riesgos. ............................................................... 38

5- DS5.4 Administracin de cuentas del usuario ............................................................... 38

6- DS5.5 Pruebas, vigilancia y monitoreo de la seguridad ................................................ 38

7- DS5.8 Administracin de llaves criptogrficas ............................................................. 38

8- DS5.9 Prevencin, deteccin y correccin de software malicioso ................................ 38

9- DS5.10 Seguridad de la red ............................................................................................ 39

8.8 ANLISIS DE RIESGOS ............................................................................................................... 39

8.9 MATRIZ DE RIESGOS. ............................................................................................................... 41

15 CONCLUSIN. ............................................................................................................... 43

16 BIBLIOGRAFA. .............................................................................................................. 46

TABLA 1 : ORGANIGRAMA. ................................................................... ERROR! MARCADOR NO DEFINIDO.

TABLA 2 : BENCHMARKING COMPARATIVO ............................................... ERROR! MARCADOR NO DEFINIDO.

TABLA 3 : DISPONIBILIDAD. ........................................................................................................... 14

TABLA 4 : TIEMPOS DE RESPUESTA Y RESOLUCIN ............................................................................... 15





4

TABLA 5 : NIVELES DE INCUMPLIMIENTO ........................................................................................... 16

TABLA 6 : COMPENZACIONES ......................................................................................................... 16

IMAGEN 1: ORGANIGRAMA. ................................................................. ERROR! MARCADOR NO DEFINIDO.





5

1 Introduccin.

En la actualidad, la creciente tecnologa ha dado soporte para que distintos dispositivos mviles,

tales como celular o Tablet, puedan ser utilizados en diversas clases de negocios. Sin embargo el

negocio de Restaurant, an mantiene su atencin de persona a persona, provocando en ciertas

oportunidades una atencin deficiente ante la cara del cliente lo que conlleva a una experiencia o

servicio deficiente.

El presente proyecto mejorara productos existente en el mercado optimizando 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.

2 Alcance.

El alcance del proyecto se puede resumir en 4 puntos bsicos con los que debe contar la solucin a

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

3 Objetivos.

3.1 Objetivos Generales.

Desarrollar una plataforma que permita integrar todo el proceso de negocio que se ve inmiscuido

en un restaurant. Identificando la lnea de produccin (mdulo de catering), incluyendo un

sistema de recetas y stock. Sistema de Administracin para el personal del Restaurant. Y para los

clientes, un mdulo de auto-atencin, que le permita conocer cules son los productos que estn

actualmente en la carta y as poder realizar una solicitud de estos directamente a la cocina.

Para finalizar el proceso, el cliente puede pedir a travs de su mdulo de auto-atencin, que se

realice el pago de su servicio, realizando una notificacin directamente al mdulo de caja.





6

3.2 Objetivos especficos.

Desarrollar mdulo de Catering para manejo de recetas.

Implementar mdulo de Stock para las recetas.

Desarrollar mdulo de Administracin e Informes para Administradores.

Desarrollar mdulo de Caja.

Cuadraturas y cierres de Caja.

Investigar, analizar y desarrollar mdulo de auto-atencin de formato Tablet para clientes (Men Virtual), que permitira a su vez:

o Seleccin de Producto para consumo. o Consultar valores de los productos consumidos. o Adicin o sustraccin de ingredientes opcionales en el plato. o Visualizacin de costos por grupo de personas. o Pre-cancelacin de cuenta sin cierre de mesa.

Desarrollar mdulo de consultas de costos por mesa.

Investigar mtodos de pago, para ser efectuados directamente por el cliente.

Proponer nuevo mtodo de reserva de mesas a travs de la pgina corporativa.

Elaborar sistema de cambio de cliente entre mesas.

Seguridad de la informacin mediante perfiles de usuario.

Mdulo de dotacin de Personal.

4 Definicin del Problema.

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.

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, pero de igual

forma al no tener un sistema que automatice la atencin, manteniendo la utilizacin de papel al

tomar la orden, no se eliminara la posibilidad de cometer diferentes tipos de errores de tipeo o de

perdida, impactando directamente en la calidad de atencin del cliente.

5 Justificacin.

Frente a la situacin especificada en la descripcin del problema, el presente proyecto plantea una

solucin orientada a mejorar los procesos de fabricacin, atencin, pago y administracin a travs





7

de una plataforma web, que permitir a clientes y empleados poder acceder a una rpida

atencin, llevando la experiencia del cliente a nuevos estndares. Es para ello, que se ha realizado

una investigacin en el marco de los sistemas orientados a restaurants que existen actualmente en

el mercado, identificando as, cuales son los procesos que deben ser integrados en una sola

plataforma y as sacar el mayor provecho de toda la lnea del negocio.

6 Planificacin Estratgica.

6.1 Informacin de la Compaa.

6.1.1 Antecedentes, Productos y Actividades.

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,

Restaurants, 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.





8

6.1.2 Organigrama.

El organigrama estructural de la empresa:

Imagen 1: Organigrama.

Tabla 1 : Organigrama.

Cargo en el Proyecto Nombre Cargo en la Organizacin

Email

Ingeniero en Informtica

Jonathan Durn Gerente de Proyectos

[email protected]


Francisco Mendoza Gerente Comercial [email protected]


Claudio Jara Gerente De Desarrollo

[email protected]





9

6.2 Clientes.

Los clientes que se abarcaran, son las principales cadenas de restaurant, ubicados en la Zona

Oriente, de la Regin Metropolitana. Que necesiten reforzar su capacidad de administracin y

gestin sobre la atencin de clientes, y as obtener un mayor ingreso por concepto de atenciones,

que lo cual se ver reflejado en sus utilidades.

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.

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





10

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.

6.3 Plan Estratgico de la Compaa.

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

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

6.3.3 Valores.

SoftBuilder, pretende tener como principales valores:

Calidad.





11

Innovacin.

Excelencia de Procesos.

6.4 Plan Estratgico de la Compaa.

6.4.1 Qu tan Fuerte es la Competencia?

Dentro del mercado, existe variadas empresas de desarrollo que poseen sistemas de gestin de

restaurant, para ello apuntaremos a una forma distinta de comercializar el producto y as lograr

una entrada al mercado de forma competitiva.

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 REDSHIO2E que funciona bajo

conectividad web y es accesible desde distintos soportes como un Tablet, cualquier ordenador o

un 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

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 especificados anteriormente se exponen para poder realizar una comparacin y

determinar cules son las caractersticas y requerimientos mnimos que debe tener el sistema a

crear (Carta Virtual), y desde esa base poder innovar.

A continuacin se ilustra grficamente una tabla comparativa o Bechmarking:





12

Requerimiento de Ventas Men On Easy Post Carta

Virtual

Visualizacin 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 garzn

X X X

Transferencias de clientes entre mesas

X X X

Eliminacin de transacciones con cdigo de autorizacin

X X

Seleccin de acompaamientos

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 cdigo de autorizacin

X X X

Mdulo de reserva

X

Eleccin de consumos directamente por clientes

X

Revisin o consulta de valor consumido, desde cualquier dispositivo mvil

X

Adicin y sustraccin de ingredientes opcionales.

X

SLA de espera mostrado en los dispositivos (opcional)

X

% de cumplimiento 47% 67% 100%

Requerimiento de Administracin Men On Easy Post Carta

Virtual

Cuadratura de caja

X X X

Mdulo de administracin de usuarios con perfil de ingreso X X X

Mdulo de administracin de insumos, recetas y bodegas X X X

Transferencia de insumos entre bodegas

X X

Mdulo de administracin de horarios y precios

X X X

Incluir instrucciones a los centros de produccin

X X

Control de Stock

X X X

Generacin automtica de auditorias

X

SLA adaptable al nmero de personal disponible

X

Mdulo de dotacin de personal

X


Requerimiento de Gestin Estratgica Men On Easy Post Carta

Virtual

Generacin de reportes

X X X

Buscador de datos especficos

X X X


% de cumplimiento total 66% 79% 100%

Tabla 2: Benchmarking comparativo.





13

7 Plan tctico.

El siguiente plan tctico detalla los objetivos que se utilizarn para llevar a cabo dicho proyecto, el

cual se subdividir en 4 tems:

1.- Desarrollo: La fase de desarrollo de la plataforma Carta Virtual, est considerada en 3 fases, las

cuales estarn disponibles como lo indican la siguiente gua:

Fase 1: Fin de Primer Semestre 2015.

Fase 2: Fin de Segundo semestre 2015.

Fase 3: Fin de Primer Semestre 2016. Cada fase est constituida por un grupo de procesos previamente identificados, los cuales sern detallados en el siguiente apartado.

2.- Presupuestos: Los costos asociados al proyecto estn basados en las adquisicin de Hardware,

que es parte fundamental del sistema tal como:

Servidor: que permitir la instalacin del sistema de forma "stand alone".

Access Point: que permitir el acceso de los dispositivos mviles a la plataforma.

Tablet: este tem ser variable segn el nmero de dispositivos que requiera el cliente. El

modelo de negocio que se quiere adaptar es a travs de leasing.

Impresoras trmicas: Sern los puntos de salida de las solicitudes de los clientes, y se

deben encontrar en puntos estratgicos dentro del restaurant, como por ejemplo: Cocina

Caliente, Cocina Fra, Cocina de Sushi, Bar, etc.

3.- Recursos: Para la implementacin del sistema se considera un servicio de instalacin que ser

bsicamente un Tcnico en Redes, que permita realizar el cableado y la configuracin de los

dispositivos al enrutador. Adems de un tcnico en sistemas que estar a cargo de la instalacin y

configuracin del servidor y el acceso desde las tablet.

4.- Financiamiento: Con el fin de obtener una entrada en el mercado de forma rpida y masiva, se

est buscando un modelo de negocio que permita proveer todo lo necesario al cliente (desde el

servidor hasta las Tablet) en modo de arriendo, realizando una inversin inicial realmente

importante, pero que se ver retribuido a travs de la masificacin del producto.





14

8 Plan Operacional.

Dentro del plan operacional contaremos con los siguientes puntos, los cuales sern clave para

llevar a cabo el proyecto de forma satisfactoria:

Se contar con 3 analistas de sistemas, los cuales realizarn estarn a cargo de todo el

ciclo de vida del proyecto. Contando adems con el apoyo de ciertos profesionales

dependiendo de la necesidad tales como: Diseadores, Tcnicos en Redes, Ingenieros de

Software. Etc. Los cules sern incluidos dentro del costo final del proyecto.

Para el desarrollo del sistema se optarn un paradigma conocido dentro del desarrollo de

sistemas tal como es: eXtremme Programming.

Se llevarn a cabo reuniones semanales para ver el progreso de avance, y se generar una

minuta dentro de los cuales todo el personal estar inmiscuido.

9 Acuerdo de Niveles Operacional y de Servicios.

9.1 Disponibilidad.

El sistema Carta Virtual tendr asociada un soporte tcnico remoto y presencial para asegurar la

correcta disponibilidad de acuerdo a la siguiente tabla:

Tarea % de disponibilidad Horario del servicio

Soporte 99,99%* Lunes a Sbados 09:00 a 04:00 am

*En relacin al horario de atencin del cliente

Tabla 3: Disponibilidad.

Los servicios prestados se ofrecern con la disponibilidad citada anteriormente.





15

9.2 Continuidad

SoftBuilder se compromete a restablecer el servicio los niveles de servicio ofertados, ante la

materializacin de una contingencia grave en un plazo no superior a 24 horas desde el momento

del siniestro.

9.3 Gestin de Incidencias y Peticiones de Servicio .

La prestacin del servicio de soporte puede estar sujeta a incidentes muy complejos que pueden

comprometer el mantenimiento de unos niveles de servicio adecuados. En este sentido y para

evitar que estos incidentes impacten en la menor medida posible en la prestacin del servicio, se

establecen unos criterios de priorizacin de incidentes que permitan ofrecer unos tiempos de

respuesta y resolucin correctos. Estos criterios de priorizacin quedan recogidos en 2 tipos:

Normal y crticos.

Normales: Incidentes que no implican la interrupcin total del sistema o que no comprometen la

seguridad del mismo en cualquiera de sus parmetros.

Crticos: Incidentes que implican la detencin total del sistema o que pueden comprometer la

seguridad del mismo Por lo que respecta, a los tiempos de respuesta y resolucin se han

establecido los siguientes niveles de servicio:

Tarea Nivel Tiempo de Respuesta Tiempo de Resolucin

Peticiones

24 horas 72 horas

Incidencia Normal Nivel 1 6 horas 12 horas

Nivel 2

24 horas

Nivel 3

72 horas

Incidencia Critica Nivel 1 2 horas 6 horas

Nivel 2

12 horas

Nivel 3

24 horas

Tabla 4: Tiempos de Respuesta y Resolucin.

La gestin de incidencias y Peticiones de Servicio estar disponible en el siguiente horario de

soporte: De lunes a sbados desde las 9:00 hasta las 04:00 horas.





16

9.4 Penalizaciones por Incumplimiento.

Todas las desviaciones a la baja en el nivel de cumplimiento del servicio estarn asociadas a una

compensacin por parte de SoftBuilder al cliente. Para establecer la compensacin se definen dos

niveles de incumplimiento: leve y grave.

Incumplimiento Desviacin leve Desviacin grave

T. de respuesta excedido Incidencia normal

Entre 4 y 6 horas Ms de 6 horas

T. de respuesta excedido Incidencia critica

Entre 4 y 6 horas Ms de 6 horas

% de disponibilidad inferior al ofertado

Entre 99,98% y 85,00%

Menor que 85,00%

Tabla 5: Niveles de Incumplimiento.

Siempre que los niveles de servicio no sean cumplidos, SoftBuilder deber compensar al cliente.

Las compensaciones por incumplimiento del servicio quedan recogidas a continuacin.

T. de respuesta excedido Incidencia normal

1% de descuento en prxima factura.

Mximo 10% acumulable



T. de respuesta excedido Incidencia critica





% de disponibilidad inferior al ofertado





Tabla 6: Compensaciones.

Por otra parte, la reiteracin de incumplimientos tanto leves como graves tendr penalizaciones

adicionales. En el caso de que se den ms 3 incumplimientos leves en el plazo de una semana,

sern considerados a todos los efectos como un incumplimiento grave. En el caso de que se den





17

ms de 3 incumplimiento graves en el plazo de un mes, SoftBuilder compensar con un mes de

servicio gratuito al cliente.

9.5 Finalizacin.

El acuerdo de nivel de servicio tendr validez durante todo el periodo de tiempo que dure la

prestacin del sistema.

10 Eleccin de Diseo de Comunicaciones y de S ervidores.

La arquitectura bsica que se requiere para cada cliente en el cual ser implementado el sistema,

ser como se muestra a continuacin:

- Servidor Stand Alone en cada Cliente, en el cual se montar un servidor Ralis y un servidor de

base de datos MySQL.

- Servicio de internet con el fin de realizar monitoreo a travs de internet.

- Access Point con el fin de acceder desde los dispositivos de auto-atencin mvil.

- Cajas y Puntos de Venta asociados al sistema para cobros.





18

11 Eleccin de Base de Datos.

Carta Virtual utilizara el siguiente sistema de gestin de base de datos:

11.1 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 Server. Los administradores de bases

de datos juegan un papel central como aplicaciones independientes o como parte de otras

aplicaciones.





19

Caractersticas.

Entre las caractersticas disponibles en las ltimas versiones se puede destacar:

Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente.

Disponibilidad en gran cantidad de plataformas y sistemas.

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.

11.2 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 es software de fuente abierta. Fuente abierta significa que es posible para cualquier

persona usarlo y modificarlo. Cualquier persona puede bajar el cdigo fuente de MySQL y usarlo

de forma gratuita.

12 Integracin de Datos.

Si bien "Carta Virtual" est orientada para ser el ERP de Administracin, dentro de las

consideraciones se realizar un modelo de integracin con sistemas de compras o facturacin, las

cuales ya estn previamente instalados en cliente. Para ello se levantar una estructura de

Servicios Web, que sern correctamente documentados y publicados, con el fin de importar o

exportar datos relevantes para empresa, y que no sean necesarios de duplicar entre los sistemas.





20

13 Gestin de Adquisiciones

Objetivo

Realizar una revisin exhaustiva del desarrollo del software que se ha realizado, con el fin de que

ste no presente errores, o bien sean los menores posibles, al momento de realizar la instalacin

en el cliente final.

Alcance

La empresa contratista deber realizar un levantamiento formal de las actuales y posibles futuras

falencias que el desarrollo presenta, sin realizar ningn tipo de modificacin sobre dicho sistema.

Todos los errores encontrados sern informados en formato confidencial al Jefe de Proyecto, el

cual posteriormente evaluar la mitigacin de dichos errores.

Requisitos

Segn Carta Gantt este proceso debe ser iniciado una vez que la versin preliminar del aplicativo

CartaVirtual de SoftBuilder se encuentre completo.

Criterios de Evaluacin de Proveedores.

N Requisito Criterio de aceptacin Entregable

1 Experiencias Anteriores Contar con un mnimo de

casos de xito comprobables.

Para esta verificacin de experiencia, deber entregar la relacin de empresas en las cuales brind ste tipo de servicio, los CV del personal a laborar en el proyecto y contactos para la verificacin de dicha contrastacin.

2 Organizacin del

Proyecto

Deber asignar un ingeniero responsable de proyecto in

situ, el cual deber coordinar el plan de trabajo.

Descripcin de funciones del equipo del Proyecto, Organigrama funcional.

3 Plan de Operaciones Debe incluir plan de

cumplimiento de operacional.

Incluir plan de contingencia, y mostrar su plan de servicio.





21

Criterio de Riesgos bsicos a Detectar

El proveedor debe tener la potestad de poder analizar al menos, las siguientes posibles falencias

dentro del sistema, aadiendo siempre en base a su experiencia, nuevos mtodos de hacking en

los cuales el sistema tenga facilidad de caer.

Listado de Proveedores a Evaluar:

Se ha realizado una investigacin en la cual es posible contar con los siguientes proveedores:

1.- http://www.pentest.cl/

2.- http://www.nartex.cl/index.php/pentesting

3.- http://execve.cl/pentesting/





22

Objetivo

Organizar todas las operaciones que se realizan en el negocio, expresndolas en trminos

monetarios llevando un registro en forma clara y precisa y as proporcionar informacin financiera

muy valiosa para la toma de decisiones.

Razones para llevar la contabilidad al da:

No llevar la contabilidad al da puede generarnos prdidas. Apuntar cada movimiento a nivel de

tesorera, cada gasto y cada ingreso supone disponer de informacin detallada que nos permitir

saber si hemos cobrado, por ejemplo, las facturas de una venta. De no hacerlo pueden generarse

problemas tales como no recibir ese cobro y dejar pasar el tiempo para formalizar una

reclamacin y emprender, en caso de que fuera necesario, las acciones judiciales que procedan.

Si por si eso fuera poco, no llevar la contabilidad de forma ordenada puede suponer pagar un

mayor nmero de impuestos de lo que corresponde en un principio, en una situacin normal. Esto

se debe a que Hacienda puede reclamar la presentacin de los documentos exigidos (que

deberamos tener preparados) y, de no tenerlos, puede suponer una multiplicacin de los

impuestos a pagar.

Alcance

La empresa contratista deber mantener un orden estricto en el archivo y clasificacin de la

documentacin. Tambin debe tener registros consistentes y aplicar las normas y principios

contables de manera rigurosa. Todo lo anterior y cualquier habilidad, talento y actividad que

realice para la empresa debe estar orientada a entregar informacin financiera oportuna,

confiable y til.

Criterios de Evaluacin de Proveedores.

N Requisito Criterio de aceptacin Entregable

1 Experiencias Anteriores Contar con un mnimo de

clientes.

Para esta verificacin de experiencia, deber entregar la relacin de empresas en las cuales brind ste tipo de servicio, los CV del personal a laborar y contactos para la verificacin de dicha contratacin.





23

2 Organizacin del

Proyecto

Deber asignar un ingeniero responsable de proyecto in

situ, el cual deber coordinar el plan de trabajo.

Descripcin de funciones del equipo del Proyecto, Organigrama funcional.

3 Plan de Operaciones Debe incluir plan de

cumplimiento de operacional.

Incluir plan de contingencia, y mostrar su plan de servicio.

14 Costos y Ganancias

Costos Asociados al Proyecto Carta Virtual

Tiempo de desarrollo del Proyecto 12 Meses

Personal Asociado al Proyecto

Costo Neto Costo Bruto Meses en Proyecto Equivalente en HH Total

Programador Freelance 400.000 480.000 15 2.400 Horas 7.200.000

Programador Senior 800.000 960.000 16 2.560 Horas 15.360.000

Ingeniero de Sistemas 1.200.000 1.440.000 1 160 Horas 1.440.000

Costo Total Proyecto 24.000.000

Tiempo de Desarrollo 18 Meses

Tiempo estimado Duracin proyecto 5 Aos

Costo Mensual Proyecto 1.333.333

Costo de Inversin Anual Min. 266.667

Costo Asociado al Proyecto 22.222 Valor Base 0,89

% Ganancia Anual 35%

Valor Mensual: 1,21





24

7 Plan de implementacin

7.1 Objetivo

Abordar todos los prerrequisitos y validaciones posteriores para la correcta implementacin del

sistema en el ambiente del cliente, bajando los posibles riesgos y as lograr el correcto

cumplimiento del objetivo en los plazos previamente definidos por el cliente y softbuilder.

7.2 Preparacin

7.2.1 Prerrequisitos de Hardware

Equipos

Los equipos remotos que utilizaran Carta Virtual deben contar con requisitos mnimos de

hardware tales como:

1gb de ram

20gb de disco duro

Pantalla vga

Procesador Pentium 4

Servidor

Los servidores deben contar con los siguientes requisitos mnimos:

2 gb de ram

Disco duro de 1 tb

Pantalla vga

Hora sincronizada con la hora local del chile.

Router

Se debe contar con al menos un router.

7.2.2 Prerrequisitos de Red

Claves

Se debe contar con todos los usuarios y claves necesarios para poder utilizar los servicios

del servidor con las claves de acceso a instalaciones.

Puerto

Se debe contar con las opciones de habilitacin y deshabilitacion de puertos.





25

7.2.3 Prerrequisitos de software

Sistema operativo

Se debe contar con sistema operativo activado en cada terminal, como tambin en los

servidores.

Licencias

Las licencias de todo el software deben estar activadas al da de la implantacin.

programas

Se deben contar con los siguientes programas tanto en los equipos remotos como en los

servidores:

Notepad++

Winrar

7.3 Validaciones Posteriores.

Capacitacin de personal

Se har la entrega de un manual de usuario, y de forma grupal se entrenara tanto a los

garzones como los administrativos en el uso del sistema, ser una capacitacin breve que

no tomara ms de 10 minutos en las cuales se har entrega de los conocimientos

necesarios tanto para poder realizar una venta como tambin ingresar productos y realizar

mantenciones.





26

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





27

8.1 Metodologa de Gestin de Riesgos.

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.





28

8.2 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 Factor Indicador Probabilidad Impacto

Misin y Objetivos

1 Flujo de trabajo Se prevn cambios significativos en el flujo de trabajo.

Baja Media

2

El proyecto se adecua a la organizacin cliente

El proyecto no se relaciona con la misin y objetivos de la organizacin cliente.

Baja Media

Conductores para la Toma de Decisiones

3 Estimaciones

Las estimaciones de tamao, esfuerzo y costos han sido realizadas sin seguir un proceso formal y sin una validacin final.

Media Media

4 Datos histricos

No se emplean datos histricos para realizar estimaciones y determinar niveles esperados de productividad y calidad

Alta Alta

Gerenciamiento Organizacional

5 Roles y responsabilidades organizacionales

Los individuos en la organizacin no comprenden sus roles y responsabilidades ni la de los dems.

Baja Baja

6 Polticas y estndares

Las polticas y estndares no se encuentran definidos o no son seguidos.

Media Media





29

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 Justificacin a los usuarios

No se ha realizado una justificacin 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 notificacin previa.

Media Media

12 Controles de costo No existe un sistema establecido. Media Media

Ingeniera 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 ambigedades y entendimiento con el cliente.

Baja Baja

16 Validez

Los requerimientos expresan algunas de las necesidades de los clientes y no han sido validados diferentes tcnicas.

Baja Baja

17 Viabilidad La mayor parte de los requerimientos no son tcnicamente implementables tanto individual como grupalmente.

Baja Media

18 Antecedencia

Solo algunos de requerimientos se relacionan con actividades y tecnologas antes implementadas en industria.

Baja Media





30

Diseo

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 solucin asociada.

Media Alta

21 Posibilidad de desarrollar pruebas

Las caractersticas del producto dificultan la realizacin de pruebas y el personal que las desarrollar no ha sido involucrado en el proceso de diseo.

Baja Baja

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

Baja Media

Proceso de desarrollo

24 Uso de un proceso de ingeniera definido

Proceso de desarrollo no establecido. Media Media

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 mtodos 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 Documentacin de Desarrollo

Inexistente. Baja Baja





31

29 Identificacin temprana de defectos

Proceso de revisin 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

Administracin de Proyectos

32 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

35 Actitud El administrador de proyectos est escasamente comprometido con xito del proyecto.

Baja Alta

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

Prdidas y cambios frecuentes y poca posibilidad de retencin.

Baja Alta

38 Combinacin de habilidades del equipo

Mala combinacin de disciplinas. Baja Media

39 Comunicacin interna del equipo

Confusa o inexistente. Baja Baja

40 Experiencia en la aplicacin

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

Media Media





32

disponible

42 Espritu 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 diseo

Extremadamente difcil de mantener. Baja Media

45 Soporte del personal

Personal no disponible, no experimentado y en un nmero reducido.

Alta Alta

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.





33

8.3 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% Costos

20%-40%

Tiempo

5% 5%-10% 10%-20%

Alcances

rea menor del alcance afectada

Mayor rea del alcance afectada

Reduccin del alcance inaceptable

Aplicaciones se ven afectadas

Reduccin de calidad requiere la aprobacin del cliente

Reduccin de calidad inaceptable por el cliente

Calidad





34

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





35

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:

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





36

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.

8.5 Monitoreo y Control de 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.





37

8.6 Matriz de Riegos.

Nivel d

e Pro

bab

ilidad

Alto

20 4 45

Medio

3 6 9 10 11

12 13

22 24

25 27

29 30

32 41

Bajo

5 7 1 2 35 37

14 15 8 17 42

16 19 18 31

21 28 23 34

33 39 36 38

40 43 44

Bajo Medio Alto

Nivel de Impacto





38

8.7 Riesgos en el Ambiente del Cliente.

8.7.1 Procesos COBIT sobre la gestin de riesgos.

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:

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

6- DS5.5 Pruebas, vigilancia 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.

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

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





39

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

8.8 Anlisis de Riesgos

ID Mejor Practica Segn COBIT para Gestin de Riesgos

Porcentaje de Ocurrencia

Impacto Consecuencia

B M A B M A

R5.4.1 Solicitud, Establecimiento y Emisin de Cuentas de Usuarios

X X

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.

R5.4.2 Suspensin de Cuentas de Usuarios

X X

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

R5.4.3 Modificacin de Cuentas de Usuarios

X

X

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.

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





40

R5.4.6 Revisin regular de todas las cuentas y los privilegios asociados

X X

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

R5.5.1 Ingreso con Login y tablas de control para auditorias.

X X

Se debe mantener un registro del ingreso de todos los usuarios como 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

R5.8.1 Formato de clave X X

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

R5.9.1 Prevencin, deteccin y correccin de software malicioso

X X

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

R5.10.1 Seguridad de la red X X

Se deben utilizan tcnicas de seguridad y procedimientos de administracin asociados (por ejemplo, firewalls, dispositivos de seguridad, segmentacin de redes, y deteccin 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 32: Anlisis de Riegos.





41

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.

8.9 Matriz de Riesgos.

N

ivel de P

rob

abilid

ad

Alto

Medio

R5.5.1 R5.10.1 R5.4.4 R5.4.5

R5.4.6

Bajo

R5.4.1 R5.4.3 R5.4.2 R5.8.1

R5.9.1





42

Bajo Medio Alto

Nivel de Impacto

Tabla 14: Matriz de Riegos.





43

15 Granja de Servidores

Para la demostracin de la granja de servidores, se utilizar la siguiente estructura que ser

montada y emulada en el software VMWare, el cual emular la instalacin real y final que se

realizar en el cliente.

Descripcin de los Servidores:

Servidor de DNS

Procesador Intel Core I5 4210U CPU @1,70 GHZ

RAM 768 MB DDR3

Disco Duro 20 GB

Sistema Operativo / Versin CentOS Linux 7 Kernel 3.10 x64 - Minimal

Motor de Ejecucin Bind 9.9.4-18 x64

IP 192.168.0.100

Host www.cartavirtual.cl





44

Servidor Base de datos


RAM 1 GB DDR3

Disco Duro 40 GB


Motor BD / Versin MariaDB 5.5.41

IP 192.168.0.102

Servidor de Aplicaciones


RAM 1 GB DDR3

Disco Duro 20 GB

Sistema Operativo / Versin Windows Server 2008 R2

Motor de Ejecucin Internet Information Server 8

IP 192.168.0.101

Servidores Opcionales:

Servidor de Correo


RAM 512 GB DDR3

Disco Duro 10 GB


Motor de Ejecucin Postfix

IP 192.168.0.103

Servidor de Aplicaciones


RAM 512 GB DDR3

Disco Duro 10 GB


Motor de Ejecucin OpenLDAP

IP 192.168.0.104





45

16 Conclusin.

A modo de conclusin la implementacin de Carta Virtual 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 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.





46

17 Bibliografa.

La planificacin de la Gestin, 2013.

https://blog.udemy.com/la-planificacion-en-la-gestion-planes-estrategicos-tacticos-y-operativos/

MySql. http://es.wikipedia.org/wiki/MySQL

taller de infraestructura informe iii

Documents