Tesis Proyecto de Titulo Ingenieria en Informatica Duoc Uc 2016

PROYECTO
RAINBOW SUSHI
Sistema de Pedidos Web
25 DE NOVIEMBRE DE 2016
CARLOS SILVA MAURICIO CEPEDA
PROYECTO PARA OPTAR AL TTULO DE INGENIERA EN INFORMTICA
Proyecto de Titulo Profesor: Rodrigo Pinochet

Contenido
Introduccin.......................................................................................................................................4
Captulo I............................................................................................................................................5
1.1 Descripcin de la Industria.....................................................................................................6
1.2 Empresa donde se Implanta el proyecto................................................................................7
1.2.1 Antecedentes de la empresa............................................................................................7
1.2.2 Organigrama Empresa Rainbow Sushi..........................................................................8
1.3 Estudio situacin actual................................................................................................................9
1.4 Problemtica y necesidad existente:..........................................................................................10
1.4.1 Problemtica....................................................................................................................10
1.4.2 Necesidad Existente........................................................................................................10
1.5 Objetivos....................................................................................................................................11
1.5.1 Objetivo General..............................................................................................................11
1.5.2 Objetivos Especficos:.....................................................................................................11
Captulo II.........................................................................................................................................12
2.1 Plan de gestin de calidad..........................................................................................................13
2.1.1 Calidad Roles y Responsabilidades..............................................................................13
2.1.2 Planificacin de Calidad.................................................................................................14
2.1.3 Aseguramiento de Calidad.............................................................................................15
2.1.4 Control de Calidad...........................................................................................................16
2.1.5 Procesos de Verificacin y Validacin.........................................................................17
2.2 Gestin de Configuracin del Software SCM........................................................................18
2.3 Plan de riesgos, medidas de contingencia y factores de crticos de xito...................................20
2.3.1 Plan de Riesgos...............................................................................................................20
2.3.2 Estrategia de mitigacin y plan de contingencia.........................................................23
2.3.3 Conclusin Plan de Riesgos..........................................................................................28
2.3.4 Factores crticos de xito................................................................................................29
2.4 Proyecto Propuesto....................................................................................................................30
2.4.1 Situacin Actual...............................................................................................................31
2.4.2 Solucin Propuesta.........................................................................................................32
2.5 Metodologa que se utilizar......................................................................................................33
2.5.1 Modelo de Desarrollo......................................................................................................33
1
2.5.2 Seleccin del Modelo......................................................................................................33
2.5.3 Herramienta de soporte para el desarrollo...................................................................33
2.6 Planificacin del Proyecto..........................................................................................................35
2.6.1 Carta Gantt. (Anexos).....................................................................................................35
2.6.2 Planificacin en EDT.......................................................................................................37
2.6.3 Malla Pert..........................................................................................................................40
2.6.4 WBS (Work Breakdown Struture) y/o EDT...................................................................41
2.7 Plan de Implantacin del Proyecto.............................................................................................43
2.7.1 Plan de Operacin del Sistema.....................................................................................43
2.7.2 Plan de Implantacin.......................................................................................................43
2.7.3 Plan de Mantencin.........................................................................................................44
Captulo III........................................................................................................................................45
3.1 Descripcin de Todos los Requerimientos..................................................................................46
3.1.1 Requisitos Funcionales...................................................................................................46
3.1.2 Requisitos No Funcionales.............................................................................................47
3.1.3 Casos de Uso ms Contratos........................................................................................49
3.1.4 Diagrama De Actividad...................................................................................................62
3.1.5 Diagramas de Secuencia................................................................................................62
3.2 Herramientas a Utilizar...............................................................................................................68
3.3 Descripcin plataforma computacional que se utilizar.............................................................70
3.3.1 Hardware..........................................................................................................................70
3.3.2 Software............................................................................................................................71
3.4 Estudio de Factibilidad...............................................................................................................71
3.4.1 Factibilidad Tcnica.........................................................................................................71
3.4.2 Factibilidad Operacional.................................................................................................72
3.4.3 Factibilidad Legal.............................................................................................................73
3.4.4 Factibilidad Econmica...................................................................................................74
3.4.5 Conclusin Estudio de Factibilidad...............................................................................75
Capitulo IV........................................................................................................................................77
4.1 Diagrama de clases...............................................................................................................78
4.2 Diagrama de Base de Datos........................................................................................................79
4.3 Descripcin de todas las tablas que componen la Base de datos...............................................80
4.4 Diagramas de Navegacin..........................................................................................................85
2
4.5 Mapa del sitio.............................................................................................................................86
4.7 Prototipo de Aplicacin..............................................................................................................88
Conclusin......................................................................................................................................104
Bibliografa.....................................................................................................................................105
3
Introduccin
El presente informe detalla los requerimientos, el diseo, la implantacin y

testing de un sistema, que permite a la Empresa RainBow Sushi implementar su
propio servicio de reparto a domicilio online. Esto es, la Empresa facilitar una
interfaz web para sus clientes y as, estos puedan realizar pedidos en Internet. El
proyecto se dividi en dos mdulos: un mdulo administrador, en la cual la
empresa dirige su negocio de pedidos online; una interfaz web para el cliente, en
la que los consumidores del restaurante pueden ingresar e informarse acerca de
los productos que oferta el mismo, para luego gestionar un pedido si as lo
desean; y un mdulo cliente, desde el cual los usuarios al sistema web pueden
realizar compras. Lo anterior estar alojado en un servidor, encargado de mostrar
la informacin del sistema y de proporcionarles las herramientas y servicios
necesarios para su correcto funcionamiento. Tras concluir la construccin del
presente trabajo, se pretende obtener un sistema absolutamente modular, cuya
funcionalidad ser fcilmente extensible. Sin embargo, no se tratar de un sistema
que sea utilizable por cualquier Empresa de venta de Sushi, ya que tendr los
mdulos y usuarios con los que RainBow Sushi trabaja. Ser, por lo tanto, un
sistema creado especialmente para RainBow Sushi.
El producto ofrecido permite programar una entrega de sushi de forma rpida y
oportuna, ofreciendo un servicio al cliente sin contacto directo con el vendedor, y
que se realiza por una aplicacin web que estar disponible en la pgina del local
de sushi. En este caso nuestro cliente se trata de una Empresa llamada Rainbow
Sushi.
El sistema est presente en el sitio web de la Empresa, de forma que cuando
un cliente indique que quiere realizar una solicitud de comida, al acceder al link
correspondiente sea re direccionado al sistema, y que pueda realizar todos los
pedidos que requiera.
4
Captulo I
5
1.1 Descripcin de la Industria
Actualmente la venta de Sushi en Chile es todo un xito, debido a que es una de

las comidas extranjeras ms apetecidas por las personas durante los ltimos
aos, y su forma de entrega, va "Delivery" o despacho a la casa es una
modalidad de compra que atrae a muchos chilenos por su comodidad y rapidez.
En Valparaso actualmente existen alrededor de 100 restaurantes de comida
japonesa, pero el nmero va aumentado conforme se hace popular la experiencia
de probar este plato, que est al alcance de cualquier bolsillo pues los precios van
desde los $3 mil hasta los $30 mil pesos.
Las Empresas de Sushi actualmente cuentan con el mismo sistema de venta: Un
sitio web en donde anunciar sus productos, una pgina en Facebook para realizar
las solicitudes por chat, un telfono con el que se comunican los clientes tambin
para hacer pedidos, y en ocasiones incluyen WhatsApp, la aplicacin mvil que
permitir realizar pedidos a travs del chat del Smartphone.
En general, las cadenas de cualquier otro tipo de comida incluyen en sus sitios
web sistemas especializados para que el cliente pueda realizar la solicitud
directamente all, e incluso pagar en lnea para que tan solo pasados unos minutos
el pedido llegue a su domicilio. Lo anterior no ocurre con las industrias de Sushi,
que llegar como un plato innovador para el paladar del chileno y que a su vez se
van imponiendo de a poco en la venta en lnea de sus productos.
En los ltimos aos la tendencia en el pas por los pedidos delivery se ha
incrementado en ms de un 10% segn cifras de la cadena de comida japonesa
Niu Sushi, impulsado principalmente por un mayor poder adquisitivo de parte de
los clientes y un crecimiento en la oferta gastronmica disponible.
6
1.2 Empresa donde se Implanta el proyecto
Rainbow Sushi es una empresa en el rubro de la venta de sushi con entrega tanto
en el Local Establecido como tambin a domicilio a travs de Delivery. Su duea,
Cecilia Aguilar, parti con este negocio en el ao 2012, lo que hoy en da se
consagro como un local muy concurrido en el centro de Via del Mar, todo se debe
a su gran variedad de productos y precios al alcance de cualquier persona. Los
Delivery son entregados por un repartidor. Este repartidor es contratado por la
empresa; al momento de reclutarlo se le solicita tener una licencia de conducir
clase C. La Moto es de la empresa, por ende, el local cumple la funcin de
mantener el vehculo con el estanque lleno, con sus documentos al da y a la vez
otorgarle el sueldo correspondiente al repartidor. Estos Despachos son gratuitos,
sin embargo, se exige una compra mnima de 8 mil pesos para hacer efectivo el
Delivery.
Tambin es posible consumir el producto dentro del local. Para esto el cliente
puede recurrir al mismo y realizar su solicitud al cajero, quien har el cobro
correspondiente por el producto. Dentro del local existen mesas dedicadas a
quienes deseen consumir la comida all. Este punto de comida a diferencia de su
competencia ha decidido implementar su propio sistema de pedidos online. Otros
locales contratan los servicios de una empresa encargada de hacer el pedido web
tal como lo hace pedido.
La alternativa de elegir el sistema propio fue a causa de que el arrendar
significara pagar mucho dinero en publicidades siendo que la aplicacin ofrece
productos de otras empresas dedicadas al mismo rubro lo cual no garantiza la
preferencia de los consumidores
1.2.1 Antecedentes de la empresa
Nombre Empresa: RainBow Sushi S.A.

Representante: Cecilia Aguilar
Correo Electrnico: ceciliaaguilar@rainbowsushi.cl
Ubicacin: 10 Norte 1117, casi esquina 4 Oriente.
Rubro: Venta de comida japonesa.
7
1.2.2 Organigrama Empresa Rainbow Sushi
Duea
Cecilia Aguilar
Cajera
Yesenia Plaza
Repartidor Repartidor
Cocinero 1 Cocinero 2
1 2
Eduardo Martinez Javier Espinoza Lenin Marin Felipe Tapia
Figura 1.0: Organigrama de la Empresa.
Este organigrama muestra el funcionamiento de la empresa Rainbow Sushi. A

continuacin, se explica la funcin de cada uno de sus empleados:
Duea: Es la encargada de llevar la contabilidad de la empresa, toma las
decisiones y encargada de renovar al personal en caso de la renuncia de uno de
sus trabajadores, ella es la cliente principal de este proyecto.
Cajera: Atiende los pedidos va telefnica, y efecta los pagos en efectivo cuando
el cliente paga en la tienda.
Cocinero 1 y 2: Se encargan de preparar los platos de comida Se requiere
conocimientos de estudio en gastronoma.
Repartidores: Son quienes llevan los pedidos al domicilio del cliente, por lo
general trabajan tiempo Part-time.
1.3 Estudio situacin actual
8
La Empresa RainBow Sushi actualmente cuenta con un sitio web sobre el cual
muestra la variedad de sus productos, hace mencin a sus redes sociales e invita
a los clientes a dirigirse al local ubicado en 10 Norte 1117 con 4 Oriente, Via del
Mar, para hacer su pedido, o bien, realizarlo a travs del chat mediante Facebook
o WhatsApp.
Los repartidores tienen la labor de viajar en una motocicleta repartidora otorgada
por la empresa, hacia todos los sectores dentro de la comuna de Via del Mar
para hacer entrega del pedido al cliente en su domicilio. Cada uno de ellos cuenta
con un SmartPhone propio para guiarse al domicilio utilizando el servicio GPS.
Una vez que el pedido es entregado y pagado, el repartidor debe realizar el viaje
hacia el local nuevamente para entregar el dinero recaudado (en el caso de que
pagara con efectivo) y marcar el pedido como Entregado.
Como se mencion anteriormente, la Empresa cuenta con un local fijo, en donde
los clientes pueden ir de forma directa a realizar la compra de su producto y
pagarlo en efectivo o con tarjeta.
9
1.4 Problemtica y necesidad existente:
1.4.1 Problemtica
En la empresa queda en evidencia una serie de problemas y fallas en su

funcionamiento explicados a continuacin:
La lnea telefnica, siendo una lnea de un nico nmero fijo, comienza a
recibir muchas solicitudes y llamados, y se mantiene ocupada, perdiendo
as los clientes que se quedan en espera.
Al recibir muchas llamadas telefnicas, alguien tiene que dejar su cargo
para atender el telfono, ya sea cocinero o cajero. Esto representara un
problema a la hora de atender una cantidad masiva de clientes.
El repartidor no tiene ninguna forma de dar aviso para indicar el estado del
pedido, por lo que se debe esperar su llegada al local para saber si el
pedido ha sido entregado.
1.4.2 Necesidad Existente
Es preciso que los clientes puedan utilizar otra plataforma de compras, de manera
que la prdida de clientes sea mnima, adems de acelerar el proceso de orden de
compra y llevar un registro ordenado de las ventas.
Es por eso que, a travs de una plataforma web, en donde el cliente pueda
realizar su compra directamente en el sistema, se podr solventar este problema
10
1.5 Objetivos
1.5.1 Objetivo General
Desarrollar un sistema que permita la implantacin de un servicio de

reparto a domicilio para la Empresa gastronmica RainBow Sushi. Este
sistema deber posicionar a las entidades comerciales en Internet y
hacerlas visibles al pblico. Les facilitar las herramientas necesarias
para administrar su sistema de Delivery, adems de un sistema web en
el cual se podr promover productos y ofrecer la venta online de estos.
Todo lo anterior debe lograrse de tal manera, que permita la adquisicin
del servicio, por parte de la Empresa, de manera econmica, es decir,
que sea accesible su implantacin por parte de RainBow Sushi.
1.5.2 Objetivos Especficos:
Crear un sitio web interactivo y fcil de manejar, sin dejar atrs la

proteccin de datos del usuario.
Agregar seguridad por medio de un Login con un registro fcil para el
usuario, y cmodo de entrar, en este caso el Inicio se direccionar con
botn en la pgina ndex.
Se puede realizar Pedidos y pagos online adems de visualizar la gran
variedad del men carta del local Rainbow Sushi.
Ingresar productos al mdulo de cliente con su respectiva categora e
imagen a travs del mdulo administrador.
11
Captulo II
12
2.1 Plan de gestin de calidad
Para realizar este proyecto, no solo se cont con una buena propuesta, sino que
tambin con un buen plan de aseguramiento de calidad. Este se desempea
mediante un plan (plan SQA) que ayude a llevar a cabo el proyecto. Se propone
un plan de control que est presente no solo durante la puesta en marcha del
proyecto, sino que tambin durante toda su construccin.
El propsito del plan SQA es indicar las actividades que permitan asegurar la
calidad del software a desarrollar, indicando como se va a monitorear o revisar el
sistema, aplicando estndares que aporten en la revisin de la elaboracin del
producto tal como se especifica en los mtodos empleados en el ciclo de vida del
software. Esto permite que el responsable utilice estas herramientas para poder
documentarse de los posibles defectos que se puedan presentar durante el
desarrollo del proyecto y as mismo realizar seguimientos de tales defectos con el
fin de poder solucionarlos.
Estndares para el desarrollo de la aplicacin:
Documentacin: Se incluyen Checklist, minutas de reunin y todo lo que
permita mantener informacin sobre el estado actual del sistema.
Reglas y mtodos con respecto al desarrollo: Basndose en el Modelo
Incremental, el sistema RainBow Sushi es construido de acuerdo a los
estndares definidos.
Estndares para la etapa de codificacin: como por ejemplo nomenclatura,
restricciones, reglas de interfaces entre otros puntos.
Estndares para el desarrollo de la aplicacin: Utilizando las herramientas
adecuadas y adaptadas para el correcto funcionamiento del sistema sobre
la plataforma final.
Procedimientos para asegurar la calidad en el desarrollo del sistema.
Acciones correctivas: Esto es, Plan de Riesgos, acorde al sistema RainBow
Sushi.
Reportes: Generar informes de errores, cambios, pruebas,
Plan de pruebas.
Revisiones formales.
2.1.1 Calidad Roles y Responsabilidades
Roles Responsabilidades
1. SQA 1. Monitoriza Gestin de calidad
13
2.- pruebas 2.-Las pruebas sern realizadas por los
desarrolladores del sistema.
3.- Analista Programador 3.- Programador del sistema, con

conocimiento PHP, es responsable de la
codificacin y funcionalidad del
Proyecto
4.-Planificador 4.- Planificador del Proyecto,
responsable de la toma de decisiones y
llevar a cabo el proyecto, segn el
modelo de desarrollo.
2.1.2 Planificacin de Calidad
Propsito Actividad Detalle

Documentaci Monitorear apego de la Procesar la informacin
n documentacin a los adecuada para las diferentes
estndares etapas
Anlisis Enfoque de la etapa de Generacin de la
anlisis a los estndares documentacin necesaria de la
requeridos en el desarrollo etapa especfica y revisar que
se ajuste a los estndares
Diseo Monitorear apego de Generacin de la
diseo a los estndares documentacin necesaria de la
etapa especfica y revisar que
Codificacin Monitorear apego de la Generacin de la
etapa de codificacin a los documentacin necesaria de la
estndares etapa especfica y revisar que
Pruebas Monitorear adherencias Generacin de la
de la etapa de pruebas a documentacin necesaria de la
los estndares etapa especfica y revisar que
Criterios de Proceso de Generacin de la
salida documentacin documentacin necesaria de la
Proceso de anlisis etapa especfica y revisar que
Proceso de diseo se ajuste a los estndares
Proceso de codificacin
Proceso de pruebas
14
2.1.3 Aseguramiento de Calidad
Actividades planificadas y sistemticas relativa a la calidad, para asegurar

que el proyecto emplee todos los procesos necesarios para cumplir con
los requisitos
Registro de actividades de aseguramiento de la calidad
Versin: 1.0
Fecha: 24 de junio de Nombre del Proyecto: Rainbow Sushi sistema de
2015 pedidos Online
Encargado del Mauricio Cepeda
documento
Nombre Proceso o rea Responsables Estado de
del rea o la
proceso actividad
Acceso a Base de Cada 5 das, Mauricio Cepeda Pendiente
Datos administrar
PhpMyAdmin
Recibimiento del Calidad y cuidado Mauricio Cepeda Al da
Log de rendimiento del hardware en los
de hardware y equipos de la
funciones que se empresa
pueden reutilizar y
prologar el uso de
la batera
Revisin de otro Calidad y cuidado Mauricio Cepeda Al da
Ingeniero sobre el del software.
log de rendimiento
Comunicacin Calidad y cuidado Mauricio Cepeda Al da
fluida, constante y del hardware entre
clara en el equipo. el sistema y servidor
web.
15
2.1.4 Control de Calidad
Identifica Resultados especficos del proyecto, para determinar si cumplen

con los estndares pertinentes.
Criterios analizados
ID Criterio Anlisis Aprobad
o
01 El proceso cuenta con un En cada prueba se document el Si
estndar documentado resultado
02 La documentacin del No se detectaron errores Si
estndar es clara y
comprensible
03 Durante la aplicacin del No hay variacin Si
proceso se sigue el
estndar establecido
04 El proceso cuenta con las La utilizacin de las plantillas Si
plantillas pertinentes para ordena y facilita la
la ejecucin de tareas y documentacin
registro de datos obtenidos
05 Todos los involucrados en Cada involucrado tiene Si
el proceso conocen y conocimiento e instructivo de
siguen los estndares seguir los estndares
06 Todos los involucrados en Todos los involucrados conocen Si
el proceso conocen y y aplican plantillas
utilizan las plantillas
07 Los cambios realizados en Los cambios de solicitudes en la Si
los estndares, guas, y documentacin
dems documentacin
obtenida en el proceso son
controlados por el equipo
de control de cambios
16
2.1.5 Procesos de Verificacin y Validacin
2.2 Gestin de Configuracin del Software SCM
El
Figura 1.1: Proceso V&V.
17
objetivo principal del proceso de manejo de control de versiones, es coordinar el
uso y actualizacin del software, asegurndose que se estn trabajando con las
versiones de los cambios (control de cambios), y asegurndose que nada se
pierda (control de retencin).
Este proceso est ajustado para el proyecto de desarrollo actual, y est
relacionado con los documentos de planificacin y descripcin del ciclo de vida
para este proyecto. El proyecto est clasificado como un proyecto con complejidad
media; esfuerzos de desarrollo mayores requieren controles ms rigurosos que los
que se describen aqu.
En esta etapa es primordial para poder realizar un seguimiento al software durante
todo el desarrollo del proyecto.
La gestin de la configuracin del software (SCM) se encarga de:
Control de configuracin: Controlar los cambios del producto.
Estado de componentes: Reportear el estado de los componentes.
Manejo de construccin: Manejar el proceso y herramientas utilizadas para la
construccin.
Control de errores: Asegurar el seguimiento de cada error hasta la fuente de
este.
Durante el ciclo de vida de cualquier proyecto de software son inevitables los
cambios, ya sean a solicitud del usuario, o por nuevos requisitos detectados por
los desarrolladores, este seguimiento se realiza cada vez que se necesite realizar
algn cambio en el desarrollo ya en estado de ejecucin o en funcionamiento, se
reunir la informacin en las siguientes plantillas:
Nombre del Proyecto: Rainbow Sushi Online
Roles en la Gestin de Cambios

Nombre del Encargado Responsabilidades Nivel de autoridad
Rol
Gestin de Carlos Silva Aprobar y rechazar Total
Cambios cambios. Evaluar y
efectuar viabilidad del
cambio y necesidad.
Tipo de cambios: Se describen los tipos de cambios y sus diferencias.

1. Accin Correctiva: Estos cambios no pasan por el proceso de gestin
de cambios, solo son autorizados por el jefe del equipo para realizarse.
2. Accin Preventiva: Estos cambios no pasan por el proceso de gestin
de cambios, solo son autorizados por el jefe del equipo para realizarse.
3. Reparacin de Defecto: Estos cambios no pasan por el proceso
general de gestin de cambios, solo son autorizados por el jefe del
equipo para realizarse.
4. Cambio al plan de Proyecto: Estos cambios deben pasar por el proceso
de gestin de cambios.
18
Proceso de Gestin de Cambios:
Solicitud de Cambios: Se emite la Se formaliza la iniciativa del
solicitud mediante un documento cambio, elaborando la solicitud
en forma clara y precisa. de cambio.
Verificacin de la Solicitud: Se Se analiza en profundidad la
asegura de que se ha entregado solicitud del cambio, con el fin
toda la informacin necesaria para de comprender la solicitud y las
ejecutar la evaluacin del cambio. razones por las que se ha
originado.
Se verifica que en la solicitud de
cambios aparezca toda la
informacin necesaria para
realizar una evaluacin
completa y exhaustiva.
Evaluacin de Impacto: Se evala Se evalan los impactos
cual va a ser el tamao del impacto integrales del cambio en el
del cambio, y si puede generar proyecto.
complicaciones. Se describe en la solicitud del
cambio el impacto que tendr al
realizarse.
Toma de Decisin y re planificacin: Una vez que se evala el
Se decide si la solicitud es impacto del cambio, se toma
aprobada o no. En caso de ser una decisin (aprobacin,
aprobada se re planifica segn sea rechazo, aplazamiento)
necesario.
Implantar el cambio: Se realiza el Se re planifica el proyecto para
cambio y se monitorea el progreso aplicar el cambio aprobado.
de este. Finalmente se reporta el Se comunican los resultados de
proceso del cambio. la nueva planificacin al equipo
de trabajo.
Se monitorea el progreso de las
acciones del cambio.
Concluir el proceso de cambio: Se Se verifica que todo el proceso
asegura de que todo el proceso se se sigui correctamente.
realiz con xito. Se actualizan los documentos
correspondientes.
19
2.3 Plan de riesgos, medidas de contingencia y factores de
crticos de xito.
2.3.1 Plan de Riesgos
RIESGOS
Alcance y Propsito Se evalan los riesgos referentes al
sistema para la Empresa RainBow
Sushi, en el que se encuentran los
planes de mitigacin y los riesgos.
Visin General de los riesgos En este documento se encuentra la
visin general de los riesgos que se
estima que pueden ocurrir a lo largo
del desarrollo del proyecto.
Encargado de Riesgos
Encargado(s) de Riesgos Carlos Silva, Mauricio Cepeda
Responsabilidades Determinar los riesgos probables y
evaluar la manera en la que sern
tratados.
Crear planes de contingencia por
cada riesgo detectado.
Especificar los enfoques a utilizar
para el anlisis de cada riesgo.
Durante la gestin de riesgos se determinarn todos los riesgos que existan para
el proyecto. Se indica la probabilidad de ocurrencia en porcentaje y el impacto que
tendra cada uno en el sistema.
Se indicar el responsable de estas actividades, de qu manera se van a realizar,
las actividades que se necesitan para realizar un anlisis de los riesgos
propuestos y entregar planes de contingencia para cada uno de los riesgos.
El plan de riesgos se ejecuta desde el inicio de la fase de anlisis del proyecto, ya
que los riesgos pueden ocurrir en cualquiera de las fases posteriores, el plan
consiste en determinar los riesgos que se pueden generar, desarrollar planes de
mitigacin y contingencia, y determinar de qu manera ser tratado.
Luego de determinar las actividades y los roles respecto a los riesgos, se anexan
las plantillas con la realizacin de estas actividades.
20
Para cada riesgo se desarrollarn las siguientes actividades:
Estrategia General: Se determina una estrategia que se utilizar en el caso
de la ocurrencia de uno o ms riesgos durante el desarrollo del sistema.
Pasos Especficos: Se llevan a cabo determinados pasos a seguir para
amortiguar el riesgo en caso de ocurrencia.
Factores a Supervisar: Se mantienen los informes sobre cada factor que
pueda generar un riesgo para el sistema.
Enfoque de Supervisin: Se mantienen en permanente supervisin los
factores que, en el momento que sean ejecutados, sea posible detectar
errores a tiempo y poder solucionarlos de forma inmediata.
Plan de Contingencia: Se crea un plan para saber cmo actuar en el caso
que un determinado riesgo haya ocurrido, y segn el grado de severidad se
toman las medidas correspondientes.
Consideraciones Especiales: Se tendrn ciertas consideraciones para
prevenir en su mayor medida los riesgos que implica el levantamiento del
sistema.
La probabilidad del riesgo se da mediante la frecuencia de exposicin al riesgo,

sumado a la gravedad en el caso de que ocurriese.
En cuanto al nmero de prioridad del riesgo (NPR), se divide en 4 grupos para
comprender que tan preponderante es:
Fuente: http://blog.enrimusa.com/que-es-el-numero-de-prioridad-del-riesgo-npr/
LISTADO DE RIESGOS
N RIESGO CATEGORIA PROBABILIDA PRIORIDA FACTORES QUE
D D INFLUYE
1 Revisiones de Equipo de 40% 2 Necesidad de

calidad inadecuadas. Desarrollo inversin de tiempo
21
en etapas ya
realizadas del
proyecto.
2 Retrasos en las Desarrollo 25% 2 Necesidad de
fechas de Trminos y del inversin de tiempo
Entrega. Proyecto en etapas ya
realizadas del
proyecto.
3 Falta de Equipo de 25% 1 Falta de
comunicacin entre Desarrollo comunicacin entre
el Equipo de el Equipo de
Desarrollo. Desarrollo.
4 Diseo de la interfaz Desarrollo 20% 2 Interfaz con
inadecuado. del redundancia, poco
Proyecto intuitiva,
informacin
escasa, etc.
5 Falta de Pruebas. Desarrollo 25% 6 Falta de tiempo en
del las pruebas o poca
Proyecto cantidad de
pruebas, lo que
significara
6 Diseo de la Base de Desarrollo 15% 7 Errores en
Datos inadecuado. del variables,
Proyecto informacin
errnea y otros.
7 Bajo dominio del Desarrollo 10% 2 Los miembros del
lenguaje de del Equipo de
Programacin PHP. Proyecto Desarrollo tienen
poco conocimiento
en el lenguaje de
programacin PHP.
8 Cambios de Equipo de 15% 9 El equipo de
Requerimientos por Desarrollo desarrollo
parte del cliente. determina los
requerimientos en
conjunto con el
cliente. Por lo tanto,
se debe tener
especial cuidado
con los cambios de
estos.
22
2.3.2 Estrategia de mitigacin y plan de contingencia
Mediante la siguiente tabla se evaluar el control de los diferentes riegos involucrados en

este proyecto
Nombre Riesgo: Revisiones de Calidad Inadecuadas

Nmero Riesgo: 1
Estrategia General Pasos Especficos
Realizar pruebas de calidad de forma Realizar actividades de calidad
gradual y concreta, asegurndose de segn fechas establecidas.
realizar el seguimiento de planificacin Realizar pruebas de acuerdo al
del sistema. plan de pruebas establecido.
Supervisin
Factores a Supervisar Enfoque de Supervisin
Revisin de Calidad. Revisar de forma intensiva el
funcionamiento del sistema, de forma
de poder encontrar la mayor cantidad
de errores o potenciales riesgos para
el correcto trabajo del sistema.
Gestin
Plan de Contingencia Consideraciones Especiales
Ejecutar etapas de calidad tantas No.
veces como sea necesario.
Monitorear activamente esta tarea.
Nombre Riesgo: Retrasos en las fechas de Trminos y Entrega.

Nmero Riesgo: 2
Se realizan revisiones de forma Se establecen tiempos de entrega
constante para determinar el avance por cada tarea a desarrollar
de las etapas en desarrollo. Se realizan revisiones a las tareas
realizadas.
Supervisin
Las fechas deben cumplirse y cada Se realizan seguimientos mediante
tarea debe ser entregada y finalizada checklist, sobre los avances del
en el plazo establecido. proyecto.
23
Gestin
Se reducen y/o se omiten tareas La nueva planificacin
menores para otorgarle mayor eventualmente tendr cambios,
prioridad a las tareas retrasadas algunos sern drsticos y se debe
con mayores prioridades. contar con el riesgo de
Se acuerdan nuevos plazos en consecuencias catastrficas.
conjunto con el equipo de
desarrollo.
Nombre Riesgo: Falta de comunicacin entre el Equipo de Desarrollo.

Nmero Riesgo: 3
Mantener constante comunicacin Se acuerdan reuniones con el
dentro del equipo de desarrollo, equipo de desarrollo para dejar
mediante redes sociales, Trello, correo clara la importancia de la
electrnico y otros. comunicacin, resolver dudas y
lograr obtener una confianza para
trabajar en equipo y asegurar el
buen funcionamiento del mismo.
Supervisin
Reuniones y comunicaciones Se debe mantener la comunicacin
peridicas con todo el equipo de peridica, de forma de que si un
desarrollo. miembro tiene algn motivo de fuerza
mayor para comunicarse con el
equipo, se debe mantener al tanto de
la situacin y evitar dejar al miembro
desinformado.
Gestin
En el caso de que fuera imposible Se deben conservar las buenas
contactar a uno o ms miembros relaciones entre los miembros del
del equipo de desarrollo, se deben equipo de desarrollo.
realizar contactos con familiares de
ste para llegar a un acuerdo en
conjunto con el equipo, si el
miembro continuar ejerciendo sus
funciones o si es desvinculado del
grupo.
24
Nombre Riesgo: Diseo de la interfaz inadecuado.
Nmero Riesgo: 4
Asegurar el correcto funcionamiento Se realizan minutas de reunin que
del sistema. contendrn la informacin de forma
Validar los requerimientos iniciales de clara y precisa acerca del diseo de
forma de evitar cambios durante el la interfaz.
desarrollo del sistema.
Supervisin
Diseo de la interfaz. Todos los temas propuestos en
Recordar que la interfaz debe ser reuniones respecto a la interfaz deben
simple, amigable e intuitiva. ser correctamente definidos.
Gestin
Reuniones para analizar el uso y el Cumplir con los requisitos y
diseo de las interfaces por parte especificaciones, tenindolo en
de los usuarios. Realizar los cuenta al momento de realizar los
cambios pertinentes. cambios.
Nombre Riesgo: Falta de Pruebas.

Nmero Riesgo: 5
Establecer tiempo de desarrollo de Uso de cronograma.
cada prueba, las que deben seguir un Establecer fechas.
orden durante la planificacin del
proyecto.
Supervisin
Planificacin de pruebas Realizar las pruebas necesarias.
Gestin
25
Realizar revisiones de los planes
de pruebas antes de ser
ejecutados.
Nombre Riesgo: Diseo de la Base de Datos inadecuado.

Nmero Riesgo: 6
Preocuparse de que el diseo de la Levantamiento de requerimientos
base de datos sea el apropiado para claro y con objetivos especficos.
evitar errores en etapas ms
avanzadas del proyecto.
Supervisin
Revisar la administracin de la base de Poner en marcha el sistema de forma
datos de forma peridica. de que cualquier error o excepcin que
apunte como responsable a la base de
datos, sea corregido de forma
inmediata.
Gestin
Se crea con anterioridad el Manejar de la mejor forma posible
documento de diseo de la base de las bases de datos a nivel de
datos. Se verifica dnde est el equipo.
problema, y en caso de no ser
encontrado se retiene todo el
sistema mientras el equipo de
desarrollo crea una nueva base de
datos para conectarla y
actualizarla.
Nombre Riesgo: Bajo dominio del lenguaje de Programacin PHP.

Nmero Riesgo: 7
Se analiza el conocimiento de cada Se determinan las etapas de
miembro del equipo de desarrollo. desarrollo de forma clara para
Se cuenta con los manuales, tutoriales evitar errores en la planificacin.
y herramientas necesarias para
asegurar el buen funcionamiento y la
correcta codificacin del sistema.
Supervisin
26
Codificacin correcta del sistema. Se determina el buen funcionamiento y
la correcta codificacin del sistema
mediante un enfoque tcnico.
Gestin
Se realizan consultas con expertos Disponer de los manuales
en el rea. necesarios y de un personal
Se obtienen respuestas mediante la externo adecuado para resolver las
bibliografa referente al lenguaje de inquietudes.
programacin PHP.
Nombre Riesgo: Cambios de Requerimientos por parte del cliente.

Nmero Riesgo: 8
Reuniones entre el equipo de Reuniones con el cliente, por medio
desarrollo para asegurarse de que los de contratos y correo electrnico.
requerimientos estn siendo cumplidos La informacin es entregada de
correctamente. forma clara y precisa.
Se establecen documentos que Se mantiene contacto con el cliente
contienen la aprobacin tanto de los para que pueda apreciar los
miembros del equipo como del cliente. avances y el cumplimiento de los
requerimientos.
Supervisin
Acuerdos realizados en reuniones. Los miembros del equipo deben
cumplir con los requerimientos.
Gestin
Se plantea que para realizar Se debe mantener registro de
cambios se debe extender tanto el reuniones.
tiempo de entrega del proyecto Se plantean reas afectadas con el
completo, como de cada fase de cambio de requerimientos.
entrega de los incrementos. Esto
afecta a todas las fechas y se debe
crear una nueva Carga Gantt.
2.3.3 Conclusin Plan de Riesgos
Se debe crear un plan de control de Riesgos de forma preventiva, para cada uno
de los riesgos descritos anteriormente. Se crearon planes de mitigacin para cada
riesgo, con los que se busca bajar el porcentaje de probabilidad de ocurrencia.
27
Tambin se crearon planes de contingencia por cada riesgo con el fin de saber
qu hacer en el caso de que el riesgo ocurriera. De esta manera se ejecuta la
solucin ms adecuada para cada situacin y as mitigar, o al menos bajar el nivel
de impacto que pudiera tener sobre el proyecto.
Siempre se debe tener un plan de contingencia al momento de desarrollo de
proyectos, ya que, si los riesgos llegan a ocurrir, solo ser til saber cmo actuar
en los casos crticos. De esta forma se mitigan los problemas que pueda tener el
proyecto durante el desarrollo, o en el mejor de los casos, se minimizan a gran
escala.
28
2.3.4 Factores crticos de xito
Entre los factores crticos que destacan en el proyecto son:
Estn claramente establecidos el valor y los beneficios de negocio

(aumento de ingresos, reduccin de costos, etc.) que se obtienen al
realizarlo.
Se establecen claramente los objetivos, resultados y productos que hay que
obtener.
Se establecen claramente el alcance y limitaciones del trabajo.
Se realizan, controlan y actualizan planes detallados, en los cuales los hitos
y actividades aparecen bien especificados en el tiempo.
Se escuchan e interpretan las expectativas de todos los usuarios y partes
involucradas y se planifican y gestionan adecuadamente.
Se asignan los recursos adecuados, con las habilidades necesarias, tanto
tcnico como de gestin de proyectos.
Se monitoriza, evala y se obtiene retroalimentacin a lo largo de toda la
ejecucin del proyecto.
Los 4 Factores de xitos en el proyecto se detallan a continuacin en la siguiente

Pirmide.
29
Figura 1.2: xito
2.4 Proyecto Propuesto

El sistema permitir a los clientes realizar sus pedidos de sushi de forma online,
donde tendr la facilidad de acceder a un men que le ofrecer las variedades de
sushi disponibles. Tambin podr realizar el pago de forma online, con distintas
opciones pago, las ms comunes VISA, MasterCard, entre otras.
El sistema incluir el horario de atencin en la pgina principal; mostrar si est
funcionando algn da inhbil, das feriados o alguna fecha especfica en la que
deba permanecer cerrada. De esta manera, no se realizarn despachos hasta el
prximo da de funcionamiento. De cualquier forma, ser posible programar una
entrega cuando el local vuelva a estar atendiendo.
30
2.4.1 Situacin Actual
Figura 1.3: Diagrama BPMN, Situacin Actual.
31
2.4.2 Solucin Propuesta
Figura 1.4: Diagrama BPMN, Solucin Propuesta.
32
2.5 Metodologa que se utilizar
2.5.1 Modelo de Desarrollo
Modelo Incremental
El modelo incremental surgi como una forma de reducir la repeticin del

trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el sistema.
2.5.2 Seleccin del Modelo
La razn por la que es utilizado el modelo Incremental se explica

detalladamente a continuacin:
El sistema que se desarrollar para la Empresa RainBow Sushi contempla
diferentes mdulos que estn asignados para cada usuario que le
corresponda en el mdulo de administracin: visualizacin de detalle del
pedido y lugar de entrega, cambiar estado del producto se da por entregado
o anulado el pedido, gestin de productos, gestin de clientes, Estadsticas
de mejor cliente y producto ms vendido, etc. Si se le entrega al cliente un
producto incremental se podr a la vez poner a prueba el uso que se le d,
y en el caso de que fuera necesario, se adeca conforme a las necesidades
que surjan en el uso del mismo y el sistema se mejora y se adapta a las
necesidades del usuario final.
2.5.3 Herramienta de soporte para el desarrollo
Tcnicas de comunicacin: Para este punto se utiliza el

Brainstorming, ms conocido como tormenta de ideas. Se utiliza este
mtodo durante una o varias reuniones con el cliente. De esta manera se
pueden generar ideas claras para que el cliente sepa cul ser el modelo
final del proyecto, adems de aclarar las dudas o conflictos que hayan
quedado en juicio.
Tcnicas de Aseguramiento de Calidad: El proyecto est dirigido a
un sistema web capaz de obtener las peticiones de cada cliente y enviarlas
a una base de datos. Adems, se debe tener en cuenta de que el cliente
puede tambin realizar el pago de su pedido. Por lo tanto, se debe asegurar
que el sistema tenga los siguientes factores de aseguramiento de calidad:
33
Debe ser confiable, es decir que sea consistente con las
especificaciones, robusto y que sea capaz de estar operativo el
mayor tiempo posible.
Fcil de usar: el grado de efectividad entre interaccin del sistema
y los usuarios.
Seguro: Debe permitir su uso a quienes legtimamente tienen
autorizacin para usarlo.
Funcional: Los requisitos deben ser los especificados con
anterioridad, sin excesos ni defectos.
Eficiente: Debe ser capaz de responder las solicitudes usando la
menor cantidad posible de recursos de hardware.
Interoperable: Debe ser capaz de comunicarse con otras
aplicaciones o servicios en lnea. Por ejemplo: Los medios de pago
que se utilizarn, abarcaran otros sistemas que deben poder
comunicarse entre estos y el sistema a construir.
Adaptable: Debe ser fcil de adaptar a cambios de especificacin.
Tcnicas de Control de Cambios: Se sabe que el control de cambios

es vital en el desarrollo de un sistema. Para utilizar esta tcnica primero se
identifican los cambios que se realizan en cada punto del sistema, se
organizan y se controlan todas las modificaciones que sufra, de forma que
podamos maximizar la productividad y minimizar los errores. El propsito
ser mantener un respaldo de los cambios por si es necesario revertir
alguno de ellos, ya sea por un error o porque se deba habilitar alguna
nueva capacidad.
Para todo lo anterior, se cuenta tanto con documentos que ayuden a respaldar el
avance del desarrollo, as como tambin documentos de CheckList que permiten
determinar cules factores estn pendientes de revisin durante el levantamiento
del proyecto.
34
2.6 Planificacin del Proyecto
2.6.1 Carta Gantt. (Anexos)
35
Figura 1.5: Carta Gantt.
36
2.6.2 Planificacin en EDT.
Figura 1.6: Planificacin EDT, Incremento 1.
37
Figura 1.6.1: Planificacin EDT, Incremento 2.
38
Figura 1.6.2: Planificacin EDT, Incremento 3.
39
2.6.3 Malla Pert
Actividades
Actividad Descripcin Predecesor Duracin

A Toma de requerimientos - 2 SEMANAS
B Fase Anlisis Modulo 1 A 2 SEMANAS
C Fase Anlisis Modulo A A 3 SEMANAS
D Fase de Diseo B,C 4 SEMANAS
E Fase de Codificacin D 6 SEMANAS
F Fase de Pruebas E 4 SEMANAS
Red de Actividades
2
B
3 6 4
2 D E F
Inicio 3 Fin
A
C
Figura 1.7: Red de Actividades
Posibles Rutas:
- Inicio - A B D E F - Fin
- Inicio - A C D E F - Fin
Holgura
Despus de haber calculado los cuatro tiempos de cada actividad, se procedi a

calcular la holgura. La holgura es el tiempo que se puede atrasar una actividad sin
afectar la duracin total del proyecto.
40
Figura 1.8: Holgura
Ruta Crtica
La Ruta Crtica se encuentra como aquella ruta para la cual todas sus actividades
tienen una holgura igual a cero. La ruta crtica corresponde en este caso a:
- Inicio - A C D E F - Fin
2.6.4 WBS (Work Breakdown Struture) y/o EDT
Descomposicin Jerrquica
1. Proyecto de Sistema Web

1.1. Fase de Anlisis
1.1.1. Especificacin Funcional
1.1.2. Requerimientos Funcionales
1.1.3. Requerimientos No Funcionales
1.2. Fase de Diseo
1.2.1. Especificacin de Diseo Funcional
1.2.2. Diseo de Casos de Prueba
1.2.3. Planificacin del Proyecto
41
1.3. Fase de Codificacin
1.3.1. Preparacin de ambiente de desarrollo
1.3.2. Creacin de Base de Datos
1.3.3. Creacin de interfaz de usuario
1.4. Fase de Pruebas
1.4.1. Preparacin del ambiente de Pruebas
1.4.2. Construccin de Plan de Pruebas
1.4.3. Ejecutar Plan de Pruebas
1.4.4. Generar Reportes de pruebas
1.5. Capacitacin del Sistema
1.5.1. Generacin de manuales de usuario
1.5.2. Capacitacin por parte del Consultor
Vista de Desglose
Figura 1.9: Vista de Desglose
42
2.7 Plan de Implantacin del Proyecto
2.7.1 Plan de Operacin del Sistema
El usuario cliente para ingresar al sitio web como requisitos mnimos debe tener un
equipo computacional ya sea una estacin de trabajo de escritorio, un laptop, una
tableta y/o un Smartphone con acceso a internet y por supuesto tener los
conocimientos bsicos de cmo manejar el equipo seleccionado.
Incluyendo videos tutoriales para poder ensear cmo usar el sitio y as
aprovecharlo al mximo.
2.7.2 Plan de Implantacin
La implantacin de este sistema es uno de los procesos ms extensos en el

desarrollo del proyecto, ya que las construcciones de esta aplicacin web existen
variables que influyen directamente en el proceso de la implantacin tales como
son, el lenguaje de programacin, el tipo de modelo de desarrollo a seguir, y la
arquitectura del software. A continuacin, se explicarn dichos puntos nombrados.
El modelo de desarrollo se aplica en la implantacin del modelo incremental, ya
que en sus ventajas este modelo reduce el tiempo de desarrollo inicial, debido a
que implementa la funcionalidad parcial. Tambin provee un impacto ventajoso
frente al cliente, que es la entrega temprana de partes operativas del software.
El modelo proporciona todas las ventajas del modelo en Cascada realimentado,
reduciendo sus desventajas slo al mbito de cada incremento.
Resulta ms sencillo acomodar cambios al acortar el tamao de los incrementos.
El sistema Rainbow Sushi Pedidos Online se construye bajo la plataforma de
programacin PHP con funciones JavaScript, Esta Funcin se utilizar para enviar
mensajes de errores o validar campos que puedan ser nulos o de ingreso de
carcter no numrico en campos que por ley debe ser un nmero.
El equipo de trabajo de Rainbow Sushi tiene la responsabilidad de entregar al
cliente un sistema web funcional en los sistemas operativos nombrados
anteriormente, adems de facilitar videos tutoriales acerca del uso para llevar a
cabo un ptimo manejo por parte del operador de la aplicacin.
.
43
2.7.3 Plan de Mantencin
El equipo de Estudiantes de DUOC UC a cargo de Rainbow Sushi Pedidos Online

se compromete a proporcionar soporte tcnico que corresponde a 3 meses,
despus de la entrega de la implantacin en el portal del sitio web de la Empresa.
El soporte tcnico consiste en:
Asistencia tcnica: Si el cliente presenta un problema o falla con el

sistema, debe comunicarse mediante un correo electrnico o un llamado
telefnico con la descripcin del problema, el cual ser resuelto lo antes
posible por los creadores de la aplicacin.
Nuevas versiones: Mediante pase el tiempo se irn creando nuevas
versiones de la pgina web estas actualizaciones se relacionan
directamente con el diseo de la interfaz de la aplicacin, ya que para los
clientes es cmodo la apariencia y el fcil manejo del sistema de pedidos.
44
Captulo III
45
3.1 Descripcin de Todos los Requerimientos
3.1.1 Requisitos Funcionales
Registrar Cliente:
El cliente debe ingresar sus datos personales y direccin de envo,
este cliente debe ser capaz de llenar todos los datos o de lo contrario
el sistema automticamente se direccionar al campo de texto que
se le solicita ingresar el dato.
Verificar usuario Existente:
Una vez registrado el cliente al momento de loguear el sistema
automticamente debe indagar la base de datos y verificar si el
usuario realmente existe. En caso que olvide su clave se re
direccionar un link para introducir su correo y pueda restablecer
desde all la contrasea.
Seleccionar Productos:
Se Debe seleccionar los productos que se deseen comprar y permitir
que estos se aadan a un carrito de compras, cada producto se
selecciona por la cantidad que desea y esto se le suma el precio de
cada producto o cantidad deseada.
Ejecutar Transaccin:
El Cliente que compra online debe tener una cuenta corriente o
tarjeta de crditos Visa MasterCard, a este cliente el cobro se
relaciona exclusivamente con su tarjeta, y el comprobante podr
verlo de manera online en el portal de cuentas de su tarjeta bancaria.
Re direccionamiento WebPay:
Este Sistema debe re direccionar una pgina WebPay el pago debe
ser vlido, no solo hacer un registro, sino que se haga un depsito
bancario en la cuenta de la empresa, de la misma manera que se
hace el pago de sucursales virtuales de agua, luz, cable internet y
telfono, etc.
Una vez el pedido este anulado por medio de vaciar el carrito el
cliente podr volver a seleccionar productos de su preferencia
Contrasea Encriptado:
46
La contrasea por motivos de seguridad estar encriptada para el
perfil del administrador, ya que es un mtodo seguro para la perfecta
administracin del sistema, ya que si una persona externa al
administrador tiene acceso puede ocasionar daos en la informacin
del cliente, de los productos, y los pedidos a entregar.
Cambiar estado de Entregas:
Una vez que el producto se entrega al cliente, se debe cambiar el
estado a Entregado si el cliente acept el producto. En el caso de que no acept
la recepcin del pedido, que el cliente se encuentre ausente, o que la direccin
sea incorrecta, se debe cambiar el estado a Anulado. Mientras tanto, el estado
se mantendr como Pendiente.
Gestin de productos:
Se desplegar una lista de todos los productos registrados en la
base de datos. Este mdulo consiste en actualizar el precio y el stock, adems de
agregar un nuevo producto al mdulo del cliente con sus respectivos datos y su
respectiva imagen referencial.
Gestin de Clientes
El administrador es el encargado de configurar la cuenta del cliente,
si el cliente no recuerda su contrasea o desea cambiarla debe contactarse con el
administrador por medio del tem contacto de la pgina, en este mdulo se
realizan todo tipo de modificaciones relacionadas con el cliente
3.1.2 Requisitos No Funcionales
Requisitos de Rendimiento:
El sistema deber tener una respuesta mxima de 4 segundos en
cada transaccin que realice el usuario, mientras la conectividad a
internet del usuario sea estable, esto ser notorio para el mismo.
El sistema deber soportar, en una primera instancia, una conexin
simultnea de hasta 300 usuarios en lnea, los cuales se irn
ampliando de acuerdo a las frecuencias de acceso que se tengan.
Requisitos de Seguridad:
Todas las acciones realizadas por cada usuario sern registradas y
archivadas mediante el uso de ficheros log de actividades.
Ser solo el Administrador quien tendr acceso a indicar en el
sistema el stock de sushi, modificar precios y dems funciones.
47
Solo los usuarios registrados y autentificados tendrn disponibles las
opciones de pago en lnea.
La base de datos del sistema se mantendr bajo respaldos de forma
semanal, todos los das domingo a las 02:00 AM, da y hora en la
que el sistema no se ocupa para mayor seguridad. Lo anterior se
realizar para evitar accidentes de manera fortuita o provocada.
Adems, se tendr la posibilidad de hacer un respaldo de manera
automtica si la ocasin as lo amerita.
El sistema ser capaz de responder y detener cualquier tipo de
ataque comn (ya sea Inyeccin SQL o similares) y as evitar el mal
uso de la base de datos.
Requisitos de Fiabilidad:
El sistema tendr una interfaz grfica de fcil uso.
La interfaz ser agradable a la vista del usuario.
La interfaz ser sencilla, funcional e intuitiva para el uso de todos los
usuarios.
El mal uso del sistema por parte del usuario, ya sea errores de
ingreso de datos, errores de consultas, etc.) sern tratados mediante
validaciones y manejo de excepciones por cdigo. Por lo tanto,
tendr tolerancia a fallos.
Requisitos de Disponibilidad:
La disponibilidad del sistema debe ser durante las 24 horas del da,
los 7 das de la semana. Se debe tener en cuenta que el DataCenter
que se utilizar asegura la disponibilidad del sistema en un 99.99%.
Lo anterior puede variar dependiendo del servicio contratado.
Requisitos de Mantenibilidad:
El sistema estar creado y basado en los lenguajes de programacin
PHP y HTML, por lo cual es fcilmente ampliable, ya sea para la
creacin de las nuevas funciones o mdulos, o deshacer algunos
mdulos ya creados, logrando una gran facilidad de cambio.
Requisitos de Portabilidad:
El sistema tendr la capacidad de adaptacin en los distintos
servidores en los que se disponga. Sin embargo, se debe tener en
cuenta que el ambiente en el que fue diseado, bajo los lenguajes
PHP y HTML, deben ser acordes al nuevo ambiente para que
soporte dichos paradigmas. Se podr portar fcilmente desde un
48
servidor de Hosting o Servidor dedicado, mientras se logre soportar
todas las herramientas que usar el cdigo. En caso contrario el
sistema no podr ser migrado.
El sistema ser capaz de adaptarse a los cambios de hardware o
software que se realicen en el equipo del cliente.
El sistema ser capaz de ser reemplazado de forma efectiva, y sin
complicaciones.
Requisitos de Usabilidad:
El sistema ser capaz de ser entendido, aprendido y operado por el
cliente, de forma rpida y efectiva.
Requisitos de Reparabilidad:
El sistema soportar reparaciones o cambios en su cdigo, utilizando
recursos y una cantidad de trabajo limitada y razonable.
3.1.3 Casos de Uso ms Contratos
Diagrama Caso de uso Iniciar Sesin.
Figura 2.0.0: Caso de Uso: Iniciar Sesin
Especificacin de Caso de Uso: Iniciar Sesin

Autor Mauricio Cepeda
Objetivos Asociados Loguear a un usuario en el sistema a travs de nombre
de usuario y contrasea, de esta manera accede al medio
de pago online
Actor Usuario (Cliente)
Descripcin El usuario Ingresa al Portal de Rainbow Sushi pedidos
49
online, luego selecciona un link que lo re direccionar al
portal para visualizar un login. Posterior a esto debe
ingresar su nombre de usuario y contrasea, y presionar
el botn Ingresar.
Una vez ejecutado este botn se re direcciona al portal
con la habilitacin de hacer pedido de forma online.
Precondicin El usuario debe estar registrado en el sistema para poder
acceder. De lo contrario el sistema no le permitir
continuar.
Flujo normal de eventos Paso Accin
1 El usuario confirma su pedido de Rainbow Sushi
para iniciar sesin
2 El Sistema debe desplegar un formulario de login
lo cual indica que debe ingresar:
Usuario
Contrasea
3 El Usuario se logue con los datos solicitados y

pulsa el botn Ingresar
4 El sistema autentificar los datos ingresados
5 El sistema verificara los datos ingresados.
Si son incorrectos volver a pedir nuevamente la
contrasea y se debe renombrar la cuenta del
usuario.
Diagrama Caso de uso Registro de usuario
50
Figura 2.0.1: Caso de Uso: Registro de Usuario
Especificacin de Caso de Uso: Registro de usuario

Autor Mauricio Cepeda
Objetivos Asociados Permitir a un usuario registrarse en el sistema
Actor Usuario (Cliente)
Descripcin Una vez que el usuario haya ingresado a la pgina
principal de Rainbow Sushi aparecer un tem de registro
de usuario
Una vez finalizado el ingreso de datos, el sistema
registrar la cuenta del usuario y podr acceder al sistema
de Rainbow
Sushi Pedidos Online
Precondicin Usuario debe poseer un correo electrnico para poder
registrarse en el sistema.
Flujo normal de eventos Pas Accin

o
1 El caso de uso se inicializa cuando el usuario
selecciona el link de Registrase
51
2 El sistema despliega un formulario de registro
donde se le pedirn los siguientes datos.
Nombre
Email
Nombre de usuario
Contrasea
Direccin de envo
3 El Usuario ingresar los datos solicitados. Una vez

ingresados los datos, presionar el botn
Registrarse
4 El Sistema Validara los datos Ingresados.
Si los datos son incorrectos, volver paso2
Si los datos son correctos, el sistema
registrar una nueva cuenta de usuario.
5 Fin del Caso de uso.
Postcondicin El Sistema Registrara una nueva cuenta de usuario
Diagrama Caso de uso Aadir Carrito
52
Figura 2.0.2: Caso de Uso: Aadir Carrito
Especificacin de Caso de Uso: Aadir Carrito

Autor Carlos Silva
Objetivos Asociados Aadir los productos a comprar al carrito de compras
Descripcin El cliente ingresar al sistema e ir directamente a la
plataforma donde se muestran los productos en venta.
Seleccionar los productos que desea y a travs del
botn Aadir al carrito podr almacenarlos para
posteriormente ingresar con su cuenta de usuario y
comprarlos.
Precondicin La cuenta con la que se acceda debe ser de un usuario
registrado como cliente de la empresa. En caso contrario,
debe registrarse.
o
Diagrama Caso de uso Realizar Pedido
53
Figura 2.0.3: Caso de Uso: Realizar Pedido
Especificacin de Caso de Uso: Realizar Pedido

Autor Carlos Silva
Objetivos Asociados Realizar un pedido a travs del sistema
Descripcin El cliente ingresar al sitio de RainBow Sushi con su
usuario y su clave. Para solicitar un pedido deber ir a su
opcin Realizar Pedido. El sistema desplegar el
asistente de solicitudes en donde se deber definir el o
los productos, la cantidad de cada uno y el medio de
pago.
registrado como cliente de la empresa.
o
1 El caso de uso se inicializa posterior al login del
usuario, cuando se selecciona la opcin Realizar
54
Pedido.
2 El sistema despliega un formulario para emitir la
solicitud, el cual contiene los siguientes campos:
1. Nombre Producto o Productos.
2. Cantidad de cada producto.
3. Medio de Pago.
4. Realizar pedido.
5. Seleccionar forma de recibo del pedido.
6. Generar comprobante de compra.
3 Se ingresan los datos solicitados. Una vez que se
indica el medio de pago, si todo est en orden el
sistema permitir que el usuario realice el pedido y
podr seleccionar el mtodo de recibo del
producto, ya sea con entrega a domicilio o retiro
en el local.
4 El usuario puede modificar los datos antes de
realizar el pedido, o bien desistir de la compra
presionando el botn Volver. Si el pedido se ha
solicitado, el botn Volver ya no estar disponible
y para modificar o desistir de la compra deber
cancelar el pedido en la opcin Listado de
Pedidos y posteriormente solicitar un reembolso.
Todo lo anterior bajo las condiciones puestas por
RainBow Sushi.
5 Finalmente podr generar el comprobante de la
compra.
6 El sistema le indicar que el pedido se ha
realizado con xito y el tiempo que tardar en
recibir el pedido a domicilio o bien el tiempo en el
que estar listo el pedido para su retiro.
55
Diagrama Caso de uso Vaciar Carrito
Figura 2.0.4: Caso de Uso: Vaciar Carrito
Especificacin de Caso de Uso: Vaciar carrito

Autor Carlos Silva
Objetivos Asociados Vaciar el carrito de compras del cliente
Descripcin Una vez que el cliente aade a su carrito de compras los
pedidos que desea comprar, puede eliminarlos para
volver a realizar un pedido distinto.
Precondicin Haber realizado un pedido con anticipacin sin haber
efectuado la compra con el botn Efectuar Compra.
o
1 Seleccionar pedidos y aadir a carrito de compra.
2 Presionar Vaciar Carrito para eliminar los
pedidos aadidos.
56
Diagrama Caso de uso Realizar Pago
Figura 2.0.5: Caso de Uso: Realizar Pago
Especificacin de Caso de Uso: Realizar Pago

Autor Carlos Silva
Objetivos Asociados Se realiza el pago de los productos seleccionados en el
carrito de compras
Descripcin Una vez que los productos estn seleccionados y
agregados en el carrito de compra, el cliente debe
ingresar al sistema con su usuario y clave.
Posteriormente el sistema lo re direccionar al mtodo de
pago elegido para completar su orden.
registrado como cliente de la empresa. En caso contrario,
debe registrarse.
Diagrama Caso de uso Registro Funcionario
57
Figura 2.0.6: Caso de Uso: Registro Funcionario
Especificacin de Caso de Uso: Registrar Funcionario

Autor Carlos Silva
Objetivos Asociados Un administrador del sistema puede registrar o eliminar
un funcionario.
Descripcin El administrador ingresa con su usuario y clave. Dentro
del sistema Admin, se dirige a Listar Funcionarios para
proceder a agregar o eliminar el funcionario, segn
corresponda.
Precondicin La cuenta con la que se acceda debe ser de un
administrador del sitio web.
58
Diagrama Caso de uso Gestionar Clientes
Figura 2.0.7: Caso de Uso: Gestionar Clientes
Especificacin de Caso de Uso: Gestionar Clientes

Autor Carlos Silva
Objetivos Asociados Gestionar los productos en venta
Descripcin Un administrador o funcionario puede aadir, modificar o
eliminar productos en venta dentro del sistema. Para eso
debe ingresar con su cuenta, dirigirse a Gestin de
Clientes y realizar los cambios en el cliente que desee.
funcionario o administrador del sistema.
59
Diagrama Caso de uso Gestionar Productos
Figura 2.0.8: Caso de Uso: Gestionar Productos
Especificacin de Caso de Uso: Gestionar Productos

Autor Carlos Silva
Objetivos Asociados Gestionar los productos en venta
Descripcin Un administrador o funcionario puede aadir, modificar o
eliminar productos en venta dentro del sistema. Para eso
debe ingresar con su cuenta, dirigirse a Gestin de
Productos y realizar los cambios en el producto que
desee.
60
Diagrama Caso de uso Cambiar Estado de Pedido
Figura 2.0.9: Caso de Uso: Cambiar Estado de Pedido
Especificacin de Caso de Uso: Cambiar estado de Pedido

Autor Carlos Silva
Objetivos Asociados Cambiar el estado del pedido
Descripcin Un administrador o funcionario puede cambiar el estado
del pedido dentro del sistema. Para eso debe ingresar
con su cuenta, dirigirse a Cambiar estado del pedido y
realizar los cambios en el estado.
61
3.1.4 Diagrama De Actividad
Figura 2.0.10: Diagrama de Actividad
62
3.1.5 Diagramas de Secuencia
Iniciar Sesin
Figura 2.0.11: Diagrama de Secuencia: Iniciar Sesin
Registro de usuario
Figura 2.0.12: Diagrama de Secuencia: Registro de Usuario
Aadir Carrito
63
Figura 2.0.13: Diagrama de Secuencia: Aadir Carrito
Realizar Pedido
Figura 2.0.14: Diagrama de Secuencia: Realizar Pedido
Vaciar Carrito
64
Figura 2.0.15: Diagrama de Secuencia: Vaciar Carrito
Realizar Pago
Figura 2.0.16: Diagrama de Secuencia: Realizar Pago
Gestin Funcionario
65
Figura 2.0.17: Diagrama de Secuencia: Gestin Funcionario
Gestionar Clientes
Figura 2.0.18: Diagrama de Secuencia: Gestionar Clientes
Gestionar Productos
66
Figura 2.0.19: Diagrama de Secuencia: Gestionar Productos
Cambiar Estado de Pedido
Figura 2.0.20: Diagrama de Secuencia: Cambiar Estado de Pedido
3.2 Herramientas a Utilizar

Herramientas de planificacin
67
Microsoft Project
Es un programa para la administracin de proyectos, desarrollado y

comercializado por Microsoft para asistir a administradores de proyectos en el
desarrollo de planes, asignacin de recursos a tareas, dar seguimiento al
progreso, administrar presupuesto y analizar cargas de trabajo.
Notepad ++
Editor de texto como notepad a diferencia que tiene ms funcionalidades, ya que

tie de color el cdigo cuando se emplean mtodos, es un programa open source
Argo o StarUML
Son herramienta para el modelamiento de software basado en los estndares UML

(Unified Modeling Language).
Bizagi
Es un Sofware gratuito utilizado para diagramar, documentar y simular procesos

BPMN (Business Process Modeling Notation).
Mysql Workbench
68
Es una herramienta visual de diseo de bases de datos que integra desarrollo de
software, Administracin de bases de datos, diseo de bases de datos, creacin y
mantenimiento para el sistema de base de datos MySQL.
XAMPP
Es un entorno de desarrollo web de Windows. Se le permite crear aplicaciones

web con Apache 2, PHP y una base de datos MySQL. Junto, PhpMyAdmin permite
administrar fcilmente las bases de datos
Bootstrap
Framework ocupado en diseo de aplicaciones web basado en html y css, en este

proyecto fue utilizado para tablas responsivas, botones de colores, campo de texto, entre
otros.
3.3 Descripcin plataforma computacional que se utilizar
3.3.1 Hardware
69
Servidor de datos: El servidor est encargado de contener al sitio web Rainbow
Sushi,
almacenando los datos de los usuarios, los datos de los funcionarios, las consultas
o reclamos, etc...
Servidor: Server IBM x3250M4 Xeon
Caractersticas
Procesador: CPU Xeon E5-2680v3 @ 2.5+ GHz
Potencia TDP mxima: 69 W

Arquitectura: 22 nm
Cantidad de Procesadores: 1
Chipset: ServeRAID H1110 SAS/SATA Controller
Memoria: 1 GB (1x1GB, 2Rx8, 1.5V) PC3-12800 CL11
ECC DDR3 2500MHz LP UDIMM, 4 slot, 32 GB mx
Ranuras de expansin: 1 x PCIe 3.0 x8; 1 x PCIe 3.0 x4 para RAID-0,-1
Bahas de discos: cuatro bahias de discos 2.5-inch hot-swap SAS/SATA 46
Almacenamiento instalado: 60GB SSD

1 x Serial
1 x Video (VGA)
2 x RJ-45
6 x USB (2 frontales, 4 traseros)
Interfaz de red: Gigabit Ethernet (GbE) dual
Fuente de alimentacin: 1x 460 W redundant (opcional segunda fuente de poder
PN
94Y6236)
Componentes simple-swap: cuatro unidades 2.5-inch hot-swap SAS
Soporte RAID: ServeRAID H1110 SAS/SATA Controller
Gestin de sistemas: Integrated Management Module (IMM) 2 con IPMI 2.0 y
Serial over
LAN, clave de hardware opcional para presencia remota; IBM Systems Director,
70
ServerGuide
3.3.2 Software
Sistema operativo: Microsoft Windows Server 2012

XAMPP
MySQL.
Navegador Google Chrome
3.4 Estudio de Factibilidad

Alternativa n1: Pagina web desarrollada en PHP y JavaScript el cual consiste en
hacer los pedidos desde la pgina mediante un pago online desde un sistema
externo webpay
Alternativa n2: Aplicacin APK desarrollada en Android la cual tiene

compatibilidad con las versiones antiguas de Android, por lo que el usuario no
tendr problema en instalarla en cualquier dispositivo mvil.
3.4.1 Factibilidad Tcnica
Alternativa 1
En la evaluacin tcnica se tomar en cuenta la tecnologa que es

necesaria para poder acceder de manera fcil y segura al sitio.
Requisitos de Hardware
Computadora de Escritorio o Notebook.

Procesador: Intel CPU Celeron G440 1,6GHz (1155) o superior.
Memoria: 1GB o superior.
Controlador de red: Puerto Ethernet 10/100 o superior
Disco Duro: 80GB o superior.
Monitor: Genrico.
Perifricos: Mouse y teclado genricos.
71
Requisitos de Software
Sistema Operativo: Windows 7 o superior, Unix/Linux, MacOS.

Web Browser: Google Chrome, Mozilla Firefox, Internet Explorer.
Otro:
Conexin a internet. (Incluye Router, cableado y/o seal inalmbrica)
Alternativa 2
Para que la aplicacin funcione correctamente, como mnimo se necesitan
estos requisitos
Requisitos de hardware: El usuario debe poseer un Smartphone.
Requisitos de software: Como mnimo estas versiones de Android o
superior. Versin: Nombre: 2.3.3 2.3.7 Gingerbread 4.0.3 4.0.4 Ice
Cream Sandwich 4.1.x 4.2.x 4.3 Jelly Bean 4.4 KitKat o superior.
3.4.2 Factibilidad Operacional
Para las alternativas n1 y n2 la evaluacin operacional permite saber si

los usuarios que utilizan el sistema y el administrador poseen los
conocimientos adecuados para operar el sistema web que se est
desarrollando. Para cumplir con la capacidad operacional en el caso de los
usuarios se espera que estos tengan los conocimientos bsicos en
computacin o en el uso de un Smartphone como mnimo bsico, teniendo
en cuenta lo anterior se realizara un video tutorial con toda la informacin
necesaria y crear una seccin de preguntas frecuentes para as agilizar las
formas de capacitar al usuario. En el caso de administrador, como ser la
persona que desarrollo el sitio o aplicacin mvil, se dejar un manual corta
palos, adems de un video tutorial, sobre el manejo del software como
administrador.
3.4.3 Factibilidad Legal
Alternativa n1: Todo el software utilizado para el proyecto es de

licencias libres. Por lo tanto, el proyecto es legalmente factible.
72
Alternativa n2: El Software a desarrollar depende de licencias
Pagadas tanto para el desarrollo y la descarga de PlayStore para los
usuarios.
Ambas Alternativas en trminos legales coinciden en la proteccin de

datos personales segn el artculo de ley 19628. El cual al cliente
solamente se le exige sus ms mnimos datos personales tales como
el nombre, apellidos y email, ya que esta entidad comercial es una
empresa de ventas de comida, no debera manejar datos de los
usuarios, debido a personal de esta entidad que podra hacer mal
uso de la informacin otorgada.
Segn la Ley 19223 que consiste en los delitos informticos este
software, no se responsabiliza ya que, una empresa externa se hace
cargo de los pagos y transferencias electrnicas.
73
3.4.4 Factibilidad Econmica
Inversin
74
Alternativa 1
Alternativa 2
75
3.4.5 Conclusin Estudio de Factibilidad
En base a los resultados obtenidos en ambas factibilidades, se puede apreciar que

en la alternativa 1 se obtiene un Valor Actual Neto positivo y una Tasa Interna de
Retorno factible. A diferencia de la alternativa 2 en la cual el VAN arrojo un valor
negativo.
Por lo tanto, se ejecutarn las tareas correspondientes para desarrollar el proyecto
en consecuencia con la alternativa 1.
Se destaca adems que el tiempo de recuperacin de la inversin ser de 2 aos
y 2 meses.
76
Capitulo IV
77
4.1 Diagrama de clases
Figura 2.1.0: Diagrama de Clases
78
4.2 Diagrama de Base de Datos
Figura 2.2.0: Diagrama de Base de Datos
Tabla clientes
Atributo Tipo Tamao Condicin Detalles
id VARCHAR 11 PRIMARY KEY, Identificador
Autoincremento nico de
usuario
Nombre VARCHAR 255 Nombre del
cliente
Apellidos VARCHAR 255 Apellido del
cliente
Usuario VARCHAR 255 Apodo del
cliente e
identificacin
de login
Email VARCHAR 255 Correo
79
Electrnico
cliente
Contrasea VARCHAR 255 Contrasea
Usuario
(Cliente)
Direccincalle VARCHAR 255 Direccin por
defecto
donde ira el
pedido
4.3 Descripcin de todas las tablas que componen la Base de

datos
Productos
Atributo Tipo Tamao Condicin Detalles
id INT 100 PRIMARY KEY, Identificador
Autoincrement de cada tipo
o de Rolls
relleno VARCHAR 200 Relleno y
numero de
cortes de los
Sushi Rolls
descripcin VARCHAR 45 Tipo de Sushi
Rolls
precio INT 20 Precio Unitario
de Sushi Rolls
cada unidad
vara entre 8 y
80
10 cortes
existencias INT 11 Stock de
Productos
Disponible
pedidos
Atributo tipo Tamao Condicin Detalle
Id INT 100 PRIMARY Identificador del
KEY,AUTO pedido, esta id
INCREMENT registra el pedido
ya que en una id
de orden incluye
ms de un
producto
idcliente INT 100 FOREIGN Identificador del
KEY cliente que
solicit el pedido
fecha VARCHAR 100 Fecha que se
realiz el pedido
Estado VARCHAR 100 Estado de la
entrega estos
estados son:
Pendiente,
Entregado y
Anulado.
lineaspedido
Id INT 100 PRIMARY KEY, Item para
AUTO_INCREMENT buscar pagos
efectuados
Idpedido INT 100 FOREIGN KEY Contiene
datos del
Pedido
idproducto INT 100 FOREIGN KEY Contiene
Datos del
Producto
unidades INT 100 Cantidad de
unidades
solicitada de
cada producto
81
imagenesproductos
Id INT 100 PRIMARY KEY, Nmero del
AUTO_INCREMENT producto que
se le aadir
imagen
Idproducto INT 100 FOREIGN KEY Identificador
del producto
imagen VARCHAR 255 Nombre y
formato de la
imagen
titulo VARCHAR 255 Posible Titulo
de imagen
descripcin VARCHAR 255 Posible
descripcin de
imagen
Funcionario
RUT VARCHAR 15 PRIMARY Rut y cuenta
KEY del
Funcionario
Administrado
r
Nombre VARCHAR 45 Nombre
Funcionario
Perfil ENUM administrador Perfil del
funcionario
en este caso
solo se
considera al
administrador
Clave VARCHAR 100 Contrasea
funcionario
Registros
82
Atributo tipo Tamao Condicin Extra Detalle
utc INT 100 Numero de
consulta o
reclamo de
los clientes
de Rainbow
Sushi
anio INT 4 Ao de
actividad
realizada en
el sistema
mes INT 2 Mes de
actividad
realizada en
el sistema
da INT 2 Da de
actividad
realizada en
el sistema
hora INT 2 Hora que se
realiz la
actividad en
el sistema
minuto INT 2 Minuto que
se realiz
actividad en
el sistema
segundo INT 2 Hora reloj
que se
realiz
actividad en
el sistema
ip VARCHAR 255 IP que se
realiz la
transaccin
navegador VARCHAR 255 Navegador
compatible
con el
sistema
pagina VARCHAR 255 Almacena la
pgina
donde se
realiz la
actividad
83
4.4 Diagramas de Navegacin
Diagrama de Navegacin Administrador
Figura 2.3.0: Diagrama de Navegacin (Administrador)
Diagrama de Navegacin Cliente
84
Figura 2.3.1: Diagrama de Navegacin (Cliente)
4.5 Mapa del sitio
Diagrama Perfil Cliente
85
Figura 2.4.0: Diagrama Perfil Cliente
Diagrama Perfil Administrador
86
Figura 2.4.1: Diagrama Perfil Administrador
4.7 Prototipo de Aplicacin

Prototipo Sistema Rainbow Sushi Sistema de pedidos Online
87
Pgina Principal
Figura 2.5.0: Prototipo de Aplicacin: Pgina Principal
Descripcin:
Pgina principal, tambin conocida como index. Esta pgina contiene un template
de navegacin desde el cual se puede acceder a las promociones y catlogo de
productos, entre otros, tales como registro de cliente, preguntas frecuentes y
contacto, adems contiene imgenes interactivas donde se puede visualizar
productos en oferta y horario de atencin del local de comida.
Interfaces que utiliza: formulario ventana principal
88
Registro de Cliente
Figura 2.5.1: Prototipo de Aplicacin: Registro de Cliente
Descripcin:
Esta interfaz consiste en el registro de un nuevo usuario perfil cliente al sistema,
cuya finalidad es realizar pedidos online, se solicita llenar este formulario, para
loguearse y ser re direccionado al medido de pago.
Tablas que utiliza: clientes.
Interfaces que utiliza: formulario de registro
89
Seleccin de Men
Figura 2.5.2: Prototipo de Aplicacin: Seleccin de Men
Descripcin:
Seleccin de men consiste en agrupar los sushis rolls segn su categora en un
men interactivo de fcil uso con imagen e hipervnculo que lleva directo al carrito
de compra.
Interfaces que utiliza: formulario ventana men de seleccin
.
90
Aadir al Carro de compras
Figura 2.5.3: Prototipo de Aplicacin: Aadir al Carrito
Descripcin:
Una vez que el cliente escoge su producto, puede aadir al carrito tantos de los
mismos productos como desee llevar. El precio total se actualizar de forma
automtica esta ventana permite vaciar el carrito para luego volver a seleccionar
producto si lo desea, y confirmar compra para continuar con el pago de los
productos seleccionado, en caso que el cliente desee comprar productos de otra
categora podr hacerlo con el botn continuar compra de esta manera se
direcciona al men de seleccin, sin perder los productos aadidos recientemente.
Tablas que utiliza: productos, imagenesProductos.

Interfaces que utiliza: Formulario de categoras
91
Confirmar Pedido
Figura 2.5.4: Prototipo de Aplicacin: Confirmar Pedido
Descripcin:
En este formulario se le exige al cliente validarse como usuario, por medio se su
nombre de usuario y contrasea, adems puede registrarse en caso que no se
haya registrado en el registro de la pgina principal a diferencia del registro
anterior este registro lo direcciona automticamente al pago del producto en el
momento que se crea la cuenta, en caso que haya olvidado su clave al presionar
olvidaste tu contrasea, se le indicar como restablecerla.
Tablas que utiliza: clientes

Interfaces que utiliza: formulario Login_Pedido
Procesar solicitud
92
Figura 2.5.5: Prototipo de Aplicacin: Procesar Solicitud
Descripcin:
Esta ventana reenva los datos al servidor que contiene el pedido solicitado con la
identificacin del usuario logueado.
Tablas que utiliza: pedidos, lineasPedido, registros.
Interfaces que utiliza: Formulario logCliente
93
Sistema de Pago
Figura 2.5.6: Prototipo de Aplicacin: Sistema de Pago
Descripcin:
El medio de pago ser accesible una vez que el usuario acepte las compras
almacenadas en su carrito, de forma que el sistema lo lleve inmediatamente a este
sitio externo que procesar su pago mediante diversas formas de hacerlo.
Interfaces que utiliza: Sistema Externo WebPay
Administracin de Funcionarios
94
Figura 2.5.7: Prototipo de Aplicacin: Administracin de Funcionarios
Descripcin:
Pantalla en la que solo el administrador del sistema tendr acceso. En ella se
podrn agregar nuevos funcionarios.
Tablas que utiliza: funcionario.

Interfaces que utiliza: Formulario de funcionarios
Listado Producto Pendientes
95
Figura 2.5.8: Prototipo de Aplicacin: Listado Productos Pendientes
Descripcin:
En este mdulo el administrador ve todos los productos que fueron ejecutados con
una transaccin exitosa se listan por la descripcin del producto en este caso el
relleno, y la categora, se indican la cantidad de unidades compradas, donde se
debe entregar, tambin el nombre del cliente. Por defecto estos son productos que
estn en estado de entrega pendiente
Tablas que utiliza: clientes, pedidos, lineaPedidos, productos.
Interfaces que utiliza: Formulario listar Pedidos
96
Cambiar Estado
Figura 2.5.9: Prototipo de Aplicacin: Cambiar Estado
Descripcin:
En este mdulo el estado pendiente del producto se cambia a entregado si el
producto fue recibido conformemente por el cliente, y anulado si fue devuelto o el
cliente se encontraba ausente en su domicilio, al cambiar de estado el producto
desaparece de la lista de entregas de productos.
Tablas que utiliza: pedidos.

Interfaces que utiliza: Formulario cambiar estado entregas
97
Gestin de productos
Figura 2.5.10: Prototipo de Aplicacin: Gestin de Productos
Descripcin:
Un administrador puede aadir, modificar o eliminar productos en venta dentro del
sistema. A la vez, este mdulo permite ingresar un nuevo producto con su
respectiva imagen. Esta imagen y su producto aadido se vern reflejados en el
sistema del cliente tanto como con sus datos asignados y su imagen.
Tablas que utiliza: productos.

Interfaces que utiliza: formulario gestin de productos
Gestin de Clientes
98
Figura 2.5.11: Prototipo de Aplicacin: Gestin de Clientes
Descripcin:
Un administrador puede aadir, modificar o eliminar clientes dentro del sistema.
Para eso debe ingresar con su cuenta, dirigirse a Gestin de Clientes y realizar
los cambios en el cliente que desee. Adems, es posible consultar la contrasea
para recordrsela al cliente cuando la olvide.
Tablas que utiliza: clientes

Interfaces que utiliza: formulario gestin de clientes
Estadsticas
99
Figura 2.5.12: Prototipo de Aplicacin: Estadsticas
Descripcin:
Se ordenan los productos en orden desde el ms comprado y se visualiza un TOP
con los productos ms comprados y el cliente que ms ha comprado. Esto ayuda
a la Empresa a saber que insumos debe tener ms abundante.
Tablas que utiliza: clientes, productos.

Interfaces que utiliza: formulario estadsticas
Cambiar Clave Admin
100
Figura 2.5.13: Prototipo de Aplicacin: Cambiar Clave Admin
Descripcin: Cambia la clave del administrador del sistema por una nueva.
Tablas que utiliza: funcionario.
Interfaces que utiliza: formulario cambio clave administrador
Restablecer contrasea:
101
Figura 2.5.14: Prototipo de Aplicacin: Restablecer Contrasea
Descripcin:
El usuario informa que ha perdido su contrasea y el administrador la resetea,
otorgndole una contrasea aleatoria la cual debe ser cambiada posteriormente.
El usuario debe loguearse con la contrasea temporal para luego cambiarla.
Interfaces que utiliza: formulario restablecer
Cambio Clave Aleatoria
102
Figura 2.5.15: Prototipo de Aplicacin: Cambio de Clave
Descripcin:
El cliente cambia la contrasea aleatoria por una que pueda recordar.
Interfaces que utiliza: formulario cambio clave
103
Conclusin
Tras haber finalizado con el desarrollo de este informe, se concluye que la mayora
de los objetivos planteados en el inicio han sido cumplidos cabalmente. Se logr
construir aplicaciones, tanto para el lado del cliente como para el del
administrador, que poseen interfaces intuitivas y que minimizan los posibles
errores cometidos por los usuarios. Al estar ambas aplicaciones diseadas
pensando en una mquina de estados, el nmero de acciones posibles de los
usuarios en cada mdulo se vio limitado, lo cual se tradujo en una reduccin
importante de los errores que pudiesen realizar stos. Se debe destacar que el
diseo de la aplicacin cliente permite que sta pueda ser utilizada por un usuario
promedio sin capacitacin alguna. Este producto es aplicable slo a la entidad
RainBow Sushi. Sin embargo, su cdigo puede ser usado con fines comerciales
para distribuirlo en reas dedicadas a la gastronoma, y no slo eso, sino que
tambin a cualquier empresa que desee implementar un servicio de reparto a
domicilio, prescindiendo en caso de desearlo, de la aplicacin cliente. La
modularidad y flexibilidad que fueron conseguidas en este trabajo son dos de las
virtudes ms importantes que posee el sistema desarrollado. El sistema fue
creado pensando en un sistema modular, lo cual se traduce en una absoluta
flexibilidad al momento de crear nuevos mdulos que agreguen mayor
funcionalidad al sistema. Estos nuevos mdulos sern absolutamente
independientes de los ya construidos y podrn ser agregados con mucha facilidad
a la aplicacin administrador, tambin a la del cliente en caso que corresponda.
Esta flexibilidad no es slo en cuanto a agregar diferentes mdulos, sino que
tambin al momento de diferenciar los perfiles de los servicios, es decir, ofrecer
diferentes mdulos en cada uno. Algunos perfiles contarn slo con los mdulos
bsicos, mientras que otros podrn contar con un mayor nmero de mdulos que
presenten an ms funcionalidades para la empresa.
104
Bibliografa
Pressman. S Roger, (5ta edicin), Ingeniera del Software.

Roger Pressman (2002). Ingeniera del Software: un enfoque prctico.
Editorial McGraw Hill.
Mtodos giles: una alternativa real y competitiva a los procesos
tradicionales de desarrollo / Sebastin Priolo.
105

Tesis Proyecto de Titulo Ingenieria en Informatica Duoc Uc 2016

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Tesis Proyecto de Titulo Ingenieria en Informatica Duoc Uc 2016

Hochgeladen von

Copyright:

Verfügbare Formate

PROYECTO

Proyecto de Titulo Profesor: Rodrigo Pinochet

El presente informe detalla los requerimientos, el diseo, la implantacin y

Actualmente la venta de Sushi en Chile es todo un xito, debido a que es una de

1.2.1 Antecedentes de la empresa

Nombre Empresa: RainBow Sushi S.A.

Figura 1.0: Organigrama de la Empresa.

Este organigrama muestra el funcionamiento de la empresa Rainbow Sushi. A

1.3 Estudio situacin actual

En la empresa queda en evidencia una serie de problemas y fallas en su

1.4.2 Necesidad Existente

Desarrollar un sistema que permita la implantacin de un servicio de

1.5.2 Objetivos Especficos:

Crear un sitio web interactivo y fcil de manejar, sin dejar atrs la

2.1.1 Calidad Roles y Responsabilidades

3.- Analista Programador 3.- Programador del sistema, con

Propsito Actividad Detalle

Actividades planificadas y sistemticas relativa a la calidad, para asegurar

Identifica Resultados especficos del proyecto, para determinar si cumplen

2.2 Gestin de Configuracin del Software SCM

Figura 1.1: Proceso V&V.

Nombre del Proyecto: Rainbow Sushi Online

Roles en la Gestin de Cambios

Tipo de cambios: Se describen los tipos de cambios y sus diferencias.

La probabilidad del riesgo se da mediante la frecuencia de exposicin al riesgo,

1 Revisiones de Equipo de 40% 2 Necesidad de

Mediante la siguiente tabla se evaluar el control de los diferentes riegos involucrados en

Nombre Riesgo: Revisiones de Calidad Inadecuadas

Nombre Riesgo: Retrasos en las fechas de Trminos y Entrega.

Nombre Riesgo: Falta de comunicacin entre el Equipo de Desarrollo.

Nombre Riesgo: Falta de Pruebas.

Nombre Riesgo: Diseo de la Base de Datos inadecuado.

Nombre Riesgo: Bajo dominio del lenguaje de Programacin PHP.

Nombre Riesgo: Cambios de Requerimientos por parte del cliente.

2.3.3 Conclusin Plan de Riesgos

Entre los factores crticos que destacan en el proyecto son:

Estn claramente establecidos el valor y los beneficios de negocio

Los 4 Factores de xitos en el proyecto se detallan a continuacin en la siguiente

2.4 Proyecto Propuesto

Figura 1.3: Diagrama BPMN, Situacin Actual.

Figura 1.4: Diagrama BPMN, Solucin Propuesta.

2.5.1 Modelo de Desarrollo

El modelo incremental surgi como una forma de reducir la repeticin del

2.5.2 Seleccin del Modelo

La razn por la que es utilizado el modelo Incremental se explica

2.5.3 Herramienta de soporte para el desarrollo

Tcnicas de comunicacin: Para este punto se utiliza el

Tcnicas de Control de Cambios: Se sabe que el control de cambios

Figura 1.6: Planificacin EDT, Incremento 1.

Actividad Descripcin Predecesor Duracin

Despus de haber calculado los cuatro tiempos de cada actividad, se procedi a

2.6.4 WBS (Work Breakdown Struture) y/o EDT

1. Proyecto de Sistema Web

Figura 1.9: Vista de Desglose

2.7.1 Plan de Operacin del Sistema

2.7.2 Plan de Implantacin

La implantacin de este sistema es uno de los procesos ms extensos en el

El equipo de Estudiantes de DUOC UC a cargo de Rainbow Sushi Pedidos Online

Asistencia tcnica: Si el cliente presenta un problema o falla con el

3.1.2 Requisitos No Funcionales

3.1.3 Casos de Uso ms Contratos

Diagrama Caso de uso Iniciar Sesin.

Figura 2.0.0: Caso de Uso: Iniciar Sesin