Ostion PDF

Implementación de un Sistema de
Infórmación para la Gestión del

restaurant “El Ostión”
Integrantes:
Emanuel Córdova Montiel
Adrian Barahona Ortiz
Jasiel Elimas López Jiménez
Materia:
Verificación y validación de software
Docente:
Alejandro López Jiménez
Comalcalco, Tabasco noviembre 2019

Resumen
Este proyecto ha surgido como principal propósito fundamental de aumentar la

productividad, mejorar y automatizar los procesos del restaurante familiar “El
Ostion”; ubicado en la ranchería Oriente, primera sección en el municipio de
Paraíso. A consecuencia de una mala administración de las ventas, ya que éstas,
se anotaban en libretas por el personal y de forma manual, generando de tal forma
redundancia en la información de las ventas, de los clientes y de los productos, así
mismo, pérdidas de las ventas por parte de los empleados.
Como solución se propuso desarrollar e implementar un sistema de información, en
este caso, un sistema web. Éste sistema de información está desarrollado con
tecnologías web: PHP, Javascript; como Sistema Gestor de Base de Datos: MySQL.
El proyecto está dividido en fases, que constituyen a la metodología en Cascada.
En la primera fase, Análisis, es la fase donde se recopilaron las necesidades del
cliente y por consiguiente se determinaron los requerimientos del cliente; también
se determinaron los posibles riesgos que podrían repercutir en el desarrollo de todo
el proyecto. En la segunda fase, Diseño, se especificaron todos los escenarios que
tiene el sistema de información, es decir, el modelado. En la tercera fase,
Implementación, es la ejecución de tener el sistema de información corriendo en el
ambiente u ordenador. En la etapa cuarta fase, Verificación, es verificar que el
sistema haya cumplido con los requisitos del cliente, es decir, que el sistema de
información haya sido desarrollado correctamente en función de los requerimientos
del cliente y cumpla las necesidades del éste.
El sistema de información está compuesto de 5 módulos: Clientes, Productos,
Ventas, Proveedores y Usuarios.
Introducción
Hoy en día las empresas se esfuerzan para tener una mayor participación en el
mercado, lo que ha originado el desarrollo de aplicaciones donde se puede registrar
el crecimiento de las empresas y las preferencias de los consumidores, estas
aplicaciones mejoran el control administrativo mediante un seguimiento preciso de
todas las transacciones que se realicen dentro de un negocio en tiempo real
proporcionando reportes detallados de ventas que permiten a los administradores
ordenar fácilmente la cantidad correcta de productos en el momento adecuado ,
esto permite al negocio o a las empresas mejorar el servicio al cliente reduciendo el
tiempo necesario para terminar una transacción. Los sistemas de ventas tienen la
capacidad de ser personalizados para cumplir con las necesidades específicas de
un negocio por ejemplos las organizaciones de venta al menudeo pueden localizar
rápidamente los precios de venta y costos actuales de todos los productos, y los
hoteles pueden vincular fácilmente las cuentas del restaurante con los cargos de
una habitación, unas tiendas de ropa pueden incluir todos los elementos que ofrece
y organizarlos ya sea por marca o por precio, etc. En años recientes el mercado ha
incrementado y se han generado diversidad de negocios en todos los rubros,
prácticamente obligando a las empresas a ofrecer una mejor atención no solo
limitándose a la venta del producto sino también a considerar mayor comodidad y
mejor atención al cliente, esto depende mucho del sistema con el que cuente la
empresa, un sistema rápido y sencillo es lo que se busca en la actualidad.
Índice General
CAPITULO 1. MODELO CONTEXTUAL ........................................................................ 7

1.1 Antecedentes ................................................................................................... 8
1.1.1 Nombre de la Empresa ........................................................................... 8
1.1.2 Giro ......................................................................................................... 8
1.1.3 Dirección ................................................................................................. 8
1.1.4 Historia .................................................................................................... 8
1.2 Planteamiento del problema........................................................................... 8
1.2.1 Definición del problema ........................................................................... 8
1.2.2 Delimitaciones de la Investigación .......................................................... 9
1.2.3 Preguntas de investigación ..................................................................... 9
1.3 Objetivos .......................................................................................................... 9
1.3.1 Objetivo General ..................................................................................... 9
1.3.2 Objetivos específicos ............................................................................ 10
1.4 Justificación .................................................................................................. 10
CAPITULO 2. MARCO TEORICO. ....................................................................... 12
2.1 Marco referencial.................................................................................... 13
2.2 Marco conceptual ................................................................................... 13
2.3.1 SRI. ....................................................................................................... 13
2.3.2 Reforma tributaria.................................................................................. 13
2.3.3 Comprobantes de venta. ....................................................................... 13
2.3.8 Código abierto (Opensource) ................................................................ 18
2.3.9 Web Services. ....................................................................................... 19
2.3.10 PDF. .................................................................................................... 19
2.3.11 XML. .................................................................................................... 19
2.3.12 Windows Microsoft Windows .............................................................. 20
2.3 Marco Tecnológico................................................................................. 14
2.3.1 PHP ....................................................................................................... 14
2.3.2 JavaScript ............................................................................................. 16
2.3.3 JQuery................................................................................................... 16
2.3.5 SublimeText .......................................................................................... 17
2.4 Marco Legal ............................................................................................... 20
CAPITULO 3 Aplicación de la metodología y desarrollo ................................. 21
3.1 Modelo de Negocios .................................................................................. 22
3.2 Modelo de Requerimientos .......................... ¡Error! Marcador no definido.
3.2.1 Requerimientos Funcionales .................... ¡Error! Marcador no definido.
3.2.2 Requerimientos No Funcionales .............. ¡Error! Marcador no definido.
3.3 Modelo de Casos de Uso ............................. ¡Error! Marcador no definido.
Diagrama General de Caso de uso ....................... ¡Error! Marcador no definido.
Casos de uso ........................................................... ¡Error! Marcador no definido.
Caso de Uso: Gestionar producto ........................ ¡Error! Marcador no definido.
Diagrama de Caso de Uso: Agregar un nuevo producto .... ¡Error! Marcador no
definido.
Diagrama de Caso de Uso: Editar un nuevo producto .... ¡Error! Marcador no
definido.
Diagrama de Caso de Uso: Eliminar un producto ........... ¡Error! Marcador no
definido.
Diagrama de Caso de Uso: Consultar un producto ............ ¡Error! Marcador no
definido.
Caso de Uso: Gestionar ventas ............................ ¡Error! Marcador no definido.
Diagrama de Caso de Uso. Gestionar ventas ...... ¡Error! Marcador no definido.
Caso de Uso: Registrar empleado .................... ¡Error! Marcador no definido.
Caso de Uso: Consultar reporte de ventas .......... ¡Error! Marcador no definido.
Diagrama de Caso de Uso: Consultar reporte de ventas ¡Error! Marcador no
definido.
3.4 Modelo arquitectónico............................................................................... 49
Diagramas secuenciales .................................... ¡Error! Marcador no definido.
Diagrama de secuencia: Agregar un producto .... ¡Error! Marcador no definido.
Diagrama de secuencia: Editar un producto ....... ¡Error! Marcador no definido.
Diagrama de secuencia: Consultar un producto . ¡Error! Marcador no definido.
Diagrama de secuencia: Eliminar un producto ¡Error! Marcador no definido.
Diagrama de secuencia: Registrar empleado ...... ¡Error! Marcador no definido.
Diagrama de secuencia: Gestión de ventas......... ¡Error! Marcador no definido.
Diagrama de secuencia: Consultar reporte de ventas .... ¡Error! Marcador no
definido.
3.5 Tabla de costos .......................................................................................... 49
3.6 Contrato de Desarrollo de Software ......................................................... 50
3.7 Normalización de Base de Datos ................ ¡Error! Marcador no definido.
CAPITULO 4 Pruebas y resultados. ................................................................... 54
4.1 Encuadre de requerimientos. ................................................................... 25
4.2 Matriz de requerimientos .......................................................................... 26
4.3 Pruebas....................................................................................................... 55
4.3.1 Prueba de Aceptación ........................................................................... 55
4.3.2 Prueba de Desempeño ......................................................................... 59
4.3.3 Prueba de Integración ........................................................................... 62
1.Introducción ................................................................................................. 64
2.Mecanismos de Verificación ........................................................................ 64
3.Criterios de Verificación ............................................................................... 65
4Resultados de la Verificación del Plan de Pruebas de Integración............... 65
4.3.4 Prueba de Interfaces y contenidos ........................................................ 66
1. Introducción .............................................................................................. 70
2. Mecanismos de Verificación ..................................................................... 70
3. Criterios de Verificación ............................................................................ 70
Resumen de resultados. ................................................................................ 10
4.3.5 Prueba unitarias e integración ............................................................... 10
1.Introducción ................................................................................................. 13
2.Mecanismos de Verificación ........................................................................ 13
3.Criterios de Verificación ............................................................................... 14
4.Procedimiento utilizando para realizar pruebas. .......................................... 14
4.3.6 Prueba Usabilidad ................................................................................. 17
4.3.7 Prueba de Rendimiento......................................................................... 22
4.3.8 Prueba unitaria ...................................................................................... 26
1. Introducción.................................................................................................... 31
2. Mecanismos de Verificación........................................................................... 32
3. Criterios de Verificación ................................................................................. 32
5. Procedimiento al utilizar Phpmyadmin como herramienta para ejecutar las
pruebas. ................................................................................................................ 32
CAPITULO 5 Conclusiones y trabajos futuros ................................................. 35
CAPITULO 1
MODELO CONTEXTUAL
1.1 Antecedentes
1.1.1 Nombre de la Empresa
El Ostión Gulión
1.1.2 Giro
Productor de alimentos
1.1.3 Dirección
Ranchería Oriente 1ª sección, Paraíso, Tabasco.
1.1.4 Historia
El Restaurant El Ostión Gulion se crea en la Ranchería Oriente 1ra Sección Paraíso

Tabasco se estableció el día 25 de Febrero del año 2000 a cargo del Propietario
Norma Díaz Córdova, inicio en una palapa muy pequeña donde empezó a vender
lo que era Marisco como Pescados; Camarón, Pulpos entre otros su demanda hizo
que se fuera extendiendo con otras palapas juntas, con el tiempo se fue
estableciendo firmemente como Lugar Turístico donde la familia puede venir a pasar
el rato y disfrutar de una tarde agradable. Aquí puedes encontrar un sin fin de
Mariscos para todo tipo de gustos, aunque no del todo les ha ido bien vino una crisis
económica y una administración donde empezó a decaer con falta de marisco y
otras cosas con el paso del tiempo, se lograron a volver establecer
económicamente, aunque los problemas no se han ido del todo, el restaurant sigue
activo para que vengan a disfrutar de los ricos platillos que se les ofrece.
1.2 Planteamiento del problema
1.2.1 Definición del problema
Hoy en día, los restaurantes que se encuentran en nivel mediano y pequeño

persisten con la problemática que se relaciona con un atraso en el ámbito
tecnológico, los métodos de gestión y su forma de producir, vender y administrar.
Actualmente las empresas que poseen este giro de negocio llevan cada proceso de
manera manual, por esa parte la información, como las ventas, tiene un mal
majamiento por parte del empleado con lo cual se encarecen sus procesos. Todo
esto contiene errores por el procesamiento manual de la información, con lo cual no
es aprovechado correctamente el uso de las tecnologías. Tal es el caso del
restaurante familiar el Ostión, donde sus procesos son realizados de manera
manual. Esto afecta principal y directamente a los clientes ya que hay mucha
perdida de información a causa de los procesos que se llevan manualmente.
1.2.2 Delimitaciones de la Investigación
1.2.2.1 Alcances
• Desarrollar e implementar un sistema informático con una base de datos, donde se

almacenará la información que es proporcionada a través del sistema.
• El sistema recabará la información de clientes como sus datos personales
• la información de cada uno de los productos y servicios que dicha empresa ofrece
se guardaran.
• la utilización de la plataforma será por medio de un servidor web
• permitira la interacción del sistema con el usuario.
1.2.2.2 Limitaciones
• El tiempo estimado para la terminación del producto finalizara.
• Que el sistema no cumpla con las expectativas que se establecieron al inicio de

la elaboración.
• Que las herramientas y metodologías predeterminas no sean lo suficiente para

el desempeño del producto.
• Por falta de infraestructura no se pueda concretar la realización del producto .
1.2.3 Preguntas de investigación

¿Cómo puede un restaurante agilizar u optimizar sus procesos a través de un
sistema especializado y orientado a la administración del mismo?
1.3 Objetivos
1.3.1 Objetivo General
Diseñar e Implementar un sistema web para el apoyo de la toma de

decisiones, en la cual ayude a gestionar la información de los clientes y productos,
se obtenga datos personales y datos del producto de manera clara y concisa.
Mediante el uso de las tecnologías de desarrollo web: PHP, JavaScript y
CodeIgniter.
1.3.2 Objetivos específicos
• Diseñar el sistema de manera intuitiva para el usuario, además que le brinde o

facilite el uso de su información de manera rápida y eficiente.
• Utilizar las herramientas a adecuadas que ayuden a controlar la información
apropiadamente.
• Optimizar la base de datos de manera que la información sea fácil de manejar.
• Realizar consultas SQL que aporten a la reducción de tiempo de espera final
para el usuario.
• Optimizar el tiempo de respuesta a través del framework CodeIgniter.
1.4 Justificación
La pérdida de información es muy común cuando la información se encuentra

en formatos físicos a su vez esta información puede ser errónea o fácil de manipular.
Un sistema de ventas garantiza que dicha información este resguardada y lista para
ser utilizada en cualquier momento. Esto nos permite realizar operaciones veloces
y consultas concretas facilitando la información de manera rápida y precisa.
1.5 metodologia utilizada

1.5.1 metodologia de investigación
Metodología cualitativa
Como metodología cualitativa se conoce aquella que trata de temas y materias
que no pueden ser cuantificados, es decir, que no pueden ser trasladados a datos
numéricos.
Los datos, en este sentido, se obtienen a partir de la observación directa, a través
de entrevistas, investigación y análisis. De allí que la metodología cualitativa
aplique procedimientos interpretativos y analíticos para el abordaje de su objeto de
estudio.
Es el tipo de metodología más usual en los campos de las ciencias sociales y
humanísticas.
1.5.2 Tipo de investigación

Investigación Exploratoria
Las investigaciones de tipo exploratorias ofrecen un primer acercamiento al

problema que se pretende estudiar y conocer.
La investigación de tipo exploratoria se realiza para conocer el tema que se
abordará, lo que nos permita “familiarizarnos” con algo que hasta el momento
desconocíamos.
Los resultados de este tipo de tipo de investigación nos dan un panorama o

conocimiento superficial del tema, pero es el primer paso inevitable para
cualquier tipo de investigación posterior que se quiera llevar a cabo.
1.5.3 cascada
El modelo en cascada es un proceso de desarrollo secuencial, en el que el
desarrollo de software se concibe como un conjunto de etapas que se
ejecutan una tras otra. Se le denomina así por las posiciones que ocupan
las diferentes fases que componen el proyecto, colocadas una encima de otra, y
siguiendo un flujo de ejecución de arriba hacia abajo, como una cascada.
El modelo de desarrollo en cascada se originó en la industria y la construcción,

donde los cambios a posteriori son caros y difíciles de implementar. Cuando estás
creando un producto material, realizar cambios en lo ya construido es mucho más
difícil que en un programa informático. En el mundo del software, todavía no se
habían implantado otras metodologías de desarrollo por lo que se adaptó el
modelo en cascada que se utilizaba en otros sectores.
CAPITULO 2. MARCO
TEORICO.
2.1 Marco referencial
ROBERTO CARLOS ESPINOZA RIVAS, JUAN CARLOS LEON QUIÑONEZ. (2015).
“IMPLEMENTACIÓN DE SISTEMA PARA RESTAURANTES PARA GESTIÓN DE PEDIDOS Y
FACTURACIÓN ELECTRÓNICA (AMBIENTE MÓVIL & SISTEMA ADMINISTRABLE DESDE UNA
PC)”. (Tesis de INGENIERIA). UNIVERSIDAD POLITECNICA SALESIANA
CARLOS XAVIER BURGOS CANDO. (2015). “DESARROLLO DE UN SISTEMA WEB

PARA LA GESTIÓN DE PEDIDOS EN UN RESTAURANTE. APLICACIÓN A UN CASO DE
ESTUDIO.”. (Tesis de INGENIERIA). ESCUELA POLITECNICA NACIONAL
PEDRO DAVID FLORES JIMENEZ. (2013). “SISTEMA DE SOFTWARE DE GESTIÓN DE

COMIDA GOURMET PARA RESTAURANTES, UTILIZANDO HERRAMIENTAS DE
SOFTWARE LIBRES.”. (Tesis de INGENIERIA). PONTIFICIA UNIVERSDAD DEL
ECUADOR
2.2 Marco conceptual

2.3.1 SRI.
“El Servicio de Rentas Internas (SRI) es una entidad técnica y autónoma que tiene
la responsabilidad de recaudar los tributos internos que la Ley establece, para poder
consolidar en el Ecuador la cultura tributaria por parte de los contribuyentes sin
excepción. El SRI ejecuta la política tributaria en el país en lo que se refiere a los
impuestos internos.” (Servicios Ecuador, 2010).
2.3.2 Reforma tributaria.
El Ecuador posee una normativa la cual indica quién o quienes tienen la obligación
de pagar impuestos, indicando el porqué de ello como también el monto que debe
cancelar por ese concepto, la reforma tributaria cambia varios aspectos de la
estructura tributaria (impuestos a las personas y/o empresas) basándose, a través
de ella, el aumentar o disminución dela cantidad de dinero que recibirá el estado por
el concepto de pago de impuestos.
2.3.3 Comprobantes de venta.
Son documentos autorizados previamente por el SRI, que respaldan las

transacciones efectuadas por los contribuyentes en la transferencia de bienes o por
la prestación de servicios o la realización de otras transacciones gravadas con
tributos, a excepción de los documentos emitidos por las instituciones del Estado
que prestan servicios administrativos y en los casos de los trabajadores en relación
de dependencia. El Servicio de Rentas Internas autoriza tres tipos de documentos.
Estos son:
a) Comprobantes de Ventas se debe entregar cuando se transfieren bienes, se

prestan servicios o se realizan transacciones gravadas con tributos. Los tipos de
comprobantes de venta son:
• Facturas: Destinadas a sociedades o personas naturales que tengan derecho a

crédito tributario y en operaciones de exportación.
• Notas de venta -RISE: Son emitidas exclusivamente por contribuyentes inscritos
en el Régimen Simplificado.
• Liquidaciones de compra de bienes y prestación de servicios: Las emiten
sociedades personas naturales y sucesiones indivisas en servicios
o adquisiciones de acuerdo a las condiciones previstas en el Reglamento de
Comprobantes de Venta, Retención y Documentos Complementarios vigente
• Tiquetes emitidos por máquinas registradoras y boletos o entradas a
espectáculos públicos: Se emiten en transacciones con usuarios finales, no
identifican al comprador, únicamente en la emisión de tiquete si se requiere
sustentar el gasto deberá exigir una factura o nota de venta -RISE
• Otros documentos autorizados: Emitidos por Instituciones Financieras,
Documentos de importación y exportación, tickets aéreos, Instituciones del
Estado en la prestación de servicios administrativos: sustenta costos y gastos y
crédito tributario siempre que cumpla con las disposiciones vigentes.
b) Documentos Complementarios: Son documentos complementarios a los

comprobantes de venta cuya finalidad es la siguiente:
• Notas de crédito: se emiten para anular operaciones, aceptar devoluciones

y conceder descuentos o bonificaciones.
• Notas de débito: se emiten para cobrar intereses de mora y para recuperar
costos y gastos, incurridos por el vendedor con posterioridad a la emisión
del comprobante.
• Guías de remisión: sustenta el traslado de mercaderías dentro del territorio
nacional.
2.3 Marco Tecnológico

2.3.1 PHP
PHP (acrónimo de “PHP: Hypertext Processor”) es un lenguaje de “código abierto”
integrado, de alto nivel, embebido en páginas HTML y ejecutado en el servidor. Este
lenguaje se caracteriza porque solo es interpretado, pero no complicado y es
embebido en el código HTML,
lo que le da una alto rendimiento y potencia. A diferencia de otros lenguajes como
JavaScript
PHP es un lenguaje script que se ejecuta en el servidor Web, de tal manera que,
solamente el resultado de su ejecución es enviado al cliente web (navegador).
Tomando en cuenta lo escrito anteriormente podemos decir que, el código fuente
escrito en PHP no aparecerá en el código fuente de la página web que muestra en
el navegador. Viendo el lenguaje desde el punto de vista del programador podemos
decir que es un lenguaje con una sintaxis similar a C; se puede usar entres campos:
el primero el más tradicional es en los scripts del lado del servidor, el segundo es
la ejecución de script en la línea de comandos del sistema operativo (Linux o
Windows); y el tercero en el desarrollo de aplicaciones de interfaz gráfica con PHP-
GTK.
Funcionamiento.
• Enviamos una petición al servidor, ejemplo www.ibrugor.com/blog/index.php
• El servidor recibe la petición y busca la página a entregar.
• Si la página contiene la extensión “.php”, el intérprete de PHP la procesa.
• El servidor ejecuta el código PHP de la página y prepara el resultado final, el HTML.
• Se envía la página HTML al cliente final.
Ventajas
• Lenguaje multiplataforma.
• Fácil de aprender.
• Orientado para desarrollar aplicaciones web donde la información esté en una base de
datos.
• Buena integración con la mayoría de conectores a base de datos. MySQL, PostgreSQL,
Oracle, etc.
• Lenguaje modular.
• Mucha documentación debido a su gran popularidad y una gran comunidad. (Web
Oficial php.net).
• Programación orientada a objetos.
• Lenguaje de código libre y gratuito.
• Biblioteca muy amplia de funciones nativas.
Desventajas
• Se necesita instalar un servidor web.
• Se realiza todo el trabajo en la parte del servidor, por esto, si se tienen muchas
peticiones, el rendimiento de nuestra aplicación podría verse afectado

sensiblemente.
• Al mezclar HTML + PHP, dificulta la legibilidad de nuestro código.
• Seguridad. Como es un lenguaje de código abierto, todas las personas pueden ver el
código fuente, y si hay errores, la gente puede utilizar estas debilidades de
codificación.
• Difícil de mantener.
2.3.2 JavaScript
JavaScript es un lenguaje de programación que se utiliza principalmente para crear

páginas web dinámicas. Una página web dinámica es aquella que incorpora efectos
como texto que aparece y desaparece, animaciones, acciones que se activan al
pulsar botones y ventanas con mensajes de aviso al usuario. Técnicamente,
JavaScript es un lenguaje de programación interpretado, por lo que no es necesario
compilar los programas para ejecutarlos. En otras palabras, los programas escritos
con JavaScript se pueden probar directamente en cualquier navegador sin
necesidad de procesos intermedios. A pesar de su nombre, JavaScript no
guarda ninguna relación directa con el lenguaje de programación Java. Legalmente,
JavaScript es una marca registrada de la empresa Sun Microsystems.
Ventajas
• Ligero de carga.
• Fácil de integrar.
• Cientos de aplicaciones disponibles para uso
• Puede agregar interactividad a elementos web.
• Compatible con la gran mayoría de los navegadores modernos incluyendo iPhone,
móviles & PS3.
Desventajas
• No es tan extenso en recursos.
• Sistemas complejos pueden no funcionar tan bien.
• Opciones de 3D limitadas.
• Usuarios pueden deshabilitar JavaScript en su navegador.
2.3.3 JQuery
JQuery es una biblioteca gratuita de JavaScript, cuyo objetivo principal es simplificar

las tareas
de creación de páginas web responsivas, acordes a lo estipulado en la Web, la cual
funciona
en todos los navegadores modernos. Por otro lado, se dice que JQuery ayuda a que
nos
concentremos de gran manera en el diseño del sitio, al abstraer por completo todas
las
características específicas de cada uno de los navegadores.
2.3.4 Sql
SQL es un potente sistema de base de datos objeto-relacional de código abierto.

Cuenta con más de 15 años de desarrollo activo y una arquitectura probada que se
ha ganado una sólida reputación de fiabilidad e integridad de datos. Se ejecuta en
los principales sistemas operativos que existen en la actualidad como:
• Linux.
• UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64).
• Windows.
Ventajas
• Ampliamente popular - Ideal para tecnologías Web.
• Fácil de Administrar.
• Su sintaxis SQL es estándar y fácil de aprender.
Footprint bajo de memoria, bastante poderoso con una configuración adecuada.

• Multiplataforma.
• Capacidades de replicación de datos.
• Soporte empresarial disponible
• Desventajas
• En comparación con MySQL es más lento en inserciones y actualizaciones, ya que
• cuenta con cabeceras de intersección que no tiene MySQL.
• Soporte en línea: Hay foros oficiales, pero no hay una ayuda obligatoria.
• Consume más recursos que MySQL.
• La sintaxis de algunos de sus comandos o sentencias no es nada intuitiva.
2.3.5 SublimeText
Sublime Text es un editor de código multiplataforma, ligero y con pocas

concesiones. Es una herramienta concebida para programar sin distracciones. Su
interfaz de color oscuro y la riqueza de coloreado de la sintaxis, centra nuestra
atención completamente.
Sublime Text permite tener varios documentos abiertos mediante pestañas, e
incluso emplear varios paneles para aquellos que utilicen más de un monitor.
Dispone de modo de pantalla completa, para aprovechar al máximo el espacio visual
disponible de la pantalla. El programa cuenta “de serie”
con 22 combinaciones de color posibles, aunque se pueden conseguir más. Para
navegar por
el código cuenta con Minimap, un panel que permite moverse por el código de forma
rápida.
Ventajas
• Es un programa muy rápido en su ejecución. Todo en él funciona de manera
extremadamente veloz.
• Es muy ligero. Ocupa apenas siete megabytes, por lo que no consume casi recursos al
computador.
Permite codificar en casi cualquier lenguaje.

• Tiene gran cantidad de paquetes que mejoran enormemente sus prestaciones.
• Permite configurar cada aspecto casi del programa y adaptarles absolutamente a
• nuestras necesidades
• Es multiplataforma. Funciona tanto en Windows como en Linux como en entorno Mac.
• Tiene todas las posibilidades de ayuda al codificar que se le pueden pedir a un editor.
• Tiene posibilidades incluso de depurar y ejecutar el código sin salir del editor.
Desventajas
• La fundamental es que es difícil de aprender y configurar al principio al ser un editor de
texto con filosofía de editor clásico (como vim), lo que puede resultar dificultoso para
usuarios acostumbrados a herramientas más visuales o a aquellas personas que
están
empezando en el mundo del desarrollo de aplicaciones o páginas web.
• Aún posee algunos fallos, aunque no mayores que otros productos más veteranos.
2.3.6 Código abierto (Opensource)
“El software de código abierto es aquel que se distribuye bajo una licencia
que permite su uso, modificación y redistribución. Como su nombre lo indica, el
requisito principal para que una aplicación sea considerada bajo esta categoría es
que el código fuente se encuentre disponible. Esto permite estudiar el
funcionamiento del programa y efectuar modificaciones con el fin de mejorarlo
y/o adaptarlo a algún propósito específico”.(Abax Asesores, 2007).
2.3.7 Web Services.
“El término Web Services describe una forma estandarizada para la integración de
aplicaciones WEB mediante el uso de XML, SOAP, WSDL y UDDI sobre los
protocolos de la Internet. XML es usado para describir los datos, SOAP se ocupa
para la transferencia de los datos, WSDL se emplea para describir los servicios
disponibles y UDDI se ocupa para conocer cuáles son los servicios disponibles. Uno
de los usos principales es permitir la comunicación entre las empresas y entre las
empresas y sus clientes. Los Web Services permiten a las organizaciones
intercambiar datos sin necesidad de conocer los detalles de sus respectivos
Sistemas de Información”.(Mario Saffirio, 2006).
2.3.8 PDF.
“Las siglas PDF corresponden a la expresión inglesa Portable File Document

("fichero de documento trasladable"). Como su nombre implica, es un formato de
datos que se puede usar para describir documentos. Adobe, la firma que desarrolló
el PDF, comercializa programas capaces de crear, editar y ver ficheros en formato
PDF. Dado que las especificaciones de este formato de ficheros están públicamente
disponibles, muchas compañías han desarrollado sus propios programas para
usar PDF. En el ámbito de la pre impresión, el formato PDF se usa cada
vez más para intercambiar información entre distintas aplicaciones.”(Laurens
Leurs, 2000)
2.3.9 XML.
“XMLsonlas siglas del Lenguaje de Etiquetado Extensible. La expresión se forma a

partir del acrónimo de la expresión inglesa extensible Markup Language. Se
trata también de un lenguaje estándar que posee una Recomendación del World
Wide Web Consortium: Extensible Markup Languajes (XML)
(http://www.w3.org/TR/REC-xml/). Con la palabra "Extensible" se alude a la no
limitación en el número de etiquetas, ya que permite crear aquellas que sean
necesarias”.(María Jesús La marca La puente, 2013).Figura 2.5Ejemplo de
estructura de un archivo XML. Nota: Esquema de un documento XML, obtenido de
IBM developerWorks (Julio 2011).
2.3.10 Windows Microsoft Windows
es un sistema operativo, es decir, un conjunto de programas que posibilita la

administración de los recursos de una computadora. Este tipo de sistemas
empieza a trabajar cuando se enciende el equipo para gestionar el hardware a partir
desde los niveles más básicos.Es importante tener en cuenta que los sistemas
operativos funcionan tanto en las computadoras como en otros dispositivos
electrónicos que usan microprocesadores (teléfonos móviles, reproductores de
DVD, etc.).
2.4 Marco Legal
Herramienta Tipo de Licencia Descripción
Sublime Text Licencia Pública General Editor de texto y de código

GNU (GNU General Public fuente, se puede usar en
License GPL). diferentes tipos de
Licencia: Software plataforma (Windows, Linux,
propietario, bajo este tipo de Mac OS X), ya que es muy
licencia el software tiene ligero y dinámico al usarlo,
limitadas las posibilidades de como también brinda la
modificarlo y de distribuir ayuda de instalar paquetes
copias. Por otra parte implica de Plugins, esquemas de
adquirir una licencia con un colores, themes.
coste para el uso el uso de
este tipo de software.
JQuery Licencia MIT. JQuery es una biblioteca
Este tipo de licencia no tiene multiplataforma de
restricción alguna y se puede JavaScript, que permite la
incluir en los proyectos, simplificación del desarrollo
siempre que el encabezado de un proyecto, enfocado
de derechos de autor para la visualización del
permanezca intacto. usuario.
SQL Licencia SQL. Es un sistema gestor de base
Versión 9.4 de datos de clase
Licencia: otorga los permisos empresarial, cuanta con
para usar, copiar, modificar, y múltiples versiones
distribuir este software y su disponible, los datos son
documentación para objeto-relacional. Tiene
CAPITULO 3 Aplicación
de la metodología y
desarrollo
3.1 Metodología de desarrollo
La metodología utilizada para la realización de este proyecto fue la de cascada, ya que esta
se apega mas a las necesidades del proyecto.
3.1.1 Análisis
restaurante familiar “El Ostion”; ubicado en la ranchería Oriente, primera
sección en el municipio de Paraíso. A consecuencia de una mala
administración de las ventas, ya que éstas, se anotaban en libretas por el
personal y de forma manual, generando de tal forma redundancia en la
información de las ventas, de los clientes y de los productos, así mismo,
pérdidas de las ventas por parte de los empleados.
3.1.2 Problemática
Actualmente las empresas que poseen este giro de negocio llevan cada
proceso de manera manual, por esa parte la información, como las ventas,
tiene un mal majamiento por parte del empleado con lo cual se encarecen sus
procesos. Todo esto contiene errores por el procesamiento manual de la
información, con lo cual no es aprovechado correctamente el uso de las
tecnologías. Tal es el caso del restaurante familiar el Ostión, donde sus
procesos son realizados de manera manual. Esto afecta principal y
directamente a los clientes ya que hay mucha perdida de información a causa
de los procesos que se llevan manualmente.
3.1.3 Solución
Un sistema de ventas garantiza que dicha información este resguardada y lista
para ser utilizada en cualquier momento. Esto nos permite realizar operaciones
veloces y consultas concretas facilitando la información de manera rápida y
precisa.
3.1.4 Planeación de riesgo
FORMA 1: Planeación adecuada
ELEMENTO Conc Plan Inic Term Int/$ Int/T Int/C Motivos
PREPARACION DE UN PLAN DETALLADO PARA EL DISEÑO,

1 SI SI SI NO NO SI SI
IMPLEMENTACION Y OPERACIÓN DEL SISTEMA.
PARTICIPACIÓN DE LOS USUARIOS EN EL DESARROLLO DEL

2 SI SI SI NO NO SI NO
PLAN Y ACUERDO CON EL PLAN FINAL DOCUMENTADO.
ORIENTACIÓN PARA ASEGURAR QUE EL PERSONAL DEL
SISTEMA Y LOS USUSARIOS SERAN ADECUADAMENTE
3 SI SI SI SI NO NO NO
ENTRENADOS EN LA TECNOLOGIA DE INFORMACIÓN
SELECCIONADA.
PROCEDIMIENTOS ESTABLECIDOS PARA LA MEJORA Y
4 MODIFICACIÓN CONTINUA DEL PLAN CONFORME CAMBIEN NO NO NO NO NO NO NO
LAS NECESIDADES Y LA TECNOLOGÍA INFORMÁTICA.
INCLUSIÓN DE TODOS LOS PARTICIPANTES DEL SISTEMA

5 SI SI SI SI NO SI SI
FORMA 2:
DENTRO DEL PROCESO DEAdministración
PLANEACIÓN DELde datos.
SISTEMA
USO APROPIADO Y ALCANCE DE UNA METODOLOGIA DE
6 SI SI SI NO NO NO SI
DESARROLLO.
TOTALES 1 1 1 4 0 3 3
INCIDENCIA DE RIESGO 5 4 0.7 2 0 1.2 1.2
IMPACTO AL PROYECTO
TOTAL DE IMPACTO DEL PROYECTO 14.1

RESPONSABILIDAD DE
1 SI NO NO NO NO NO SI
LA
ADMINISTRACION FORMALIZADA.
FUNCION
INDEPENDIENTEPARA
2 ESTABLECIDA SI SI SI SI SI NO NO
ADMINISTRAR LA BASE DE DATOS.
METODO FORMAL
ESTABLECIDO
PARA RESOLVER
3 NO NO NO NO NO NO NO
DEFINICIONES,
SIMBOLOGIA, MANEJO Y USO
DE DATOS.
USO DE DICCIONARIO DE
DATOS
COMO HERRAMIENTA
4 SI SI SI SI NO NO NO
DE
DOCUMENTACIÓN PARA
LA
DEFINICIÓN DE LA BASE.
ACTIVIDADES DE
ADMINISTRACIÓN
SE LA BASE DE
5 SI SI SI NO SI NO NO
DATOS
RESTRINGIDAS A LAS
NECESARIAS A SU FUNCION.
TOTALES 1 2 2 3 2 0 1
INCIDENCIA DE RIESGO 1 1.6 1.4 1.5 0.8 0 0.4
IMPACTO AL PROYECTO
FORMA 3: Entrada correcta de datos

DOCUMENTACIÓN DE REGLAS DE
1 VALIDACIÓN PARA CADA ELEMENTO SI SI SI SI NO NO NO
DEFINIDO EN LA BASE DE DATOS.
DOCUMENTACIÓN DE LAS REGLAS
2 DE VALIDACIÓN EN EL DICCIONARIO SI SI SI SI NO NO NO
DE DATOS.
DOCUMENTACIÓN DE LOS
PROCEDIMIENTOS PARA CAPTURA O
ENTRADA DE DATOS CONOCIDOS Y
3 SI SI SI NO NO SI NO
ENTENDIDOS POR LOS
RESPONSABLES DIRECTOS DE LA
FUNCIÓN.
PROCEDIMIENTOS ESTABLECIDOS
DE RESTRICCIÓN A LA ENTRADA DE
4 SI NO NO NO NO SI SI
DATOS PARA PERSONAL
AUTORIZADO.
TOTALES 0 1 1 2 0 2 1
INCIDENCIA DE RIESGO 0 0.8 0.7 1 0 0.8 0.4
IMPACTO AL PROYECTO
FORMA 5: Integridad de los medios informàticos

TOTAL DE IMPACTO DE PROYECTO 3.7
INVENTARIO E
1 IDENTIFICACION DE LOS SI SI NO NO SI NO NO
RECURSOS INFORMATICOS
AREA O PERSONAL
RESPONSABLE POR LA
2 SEGURIDAD DE LOS SI SI SI SI NO NO NO
MEDIOS Y RECURSOS
INFORMATICOS
PROCEDIMIENTOSDE
RESPALDO Y
RECUPERACION DE LOS
3 RECURSOS INFORMATICOS NO SI SI NO NO SI SI
PREPARADOS Y
DISPONIBLES EN LUGARES
REMOTOS
PROTECCION DE LOS
RECURSOS INFORMATICOS
4 SI NO NO NO NO SI SI
DE CONDICIONES DE
ENTORN0 Y AMBIENTALES
TOTALES 1 1 2 3 1 2 2
INCIDENCIA DE RIESGO 1 0.8 1.4 1.5 0.4 0.8 0.8
IMPACTO AL PROYECTO
3.1.5 Encuadre de requerimientos.
Requerimiento Caso de Uso

Estatus
registro de todos los empleados.
Se requiere un módulo para llevar el
Se requiere un módulo de ventas que No se hizo caso de uso.
registre el nombre del producto, la Cancelado
descripción de ese producto, el precio y Gestionar ventas.
la cantidad. Así mismo que calcule el
total a pagar y calcular cambio.
Se requiere un módulo para consultar
Completado
las ventas que se han hecho ya sea Consultar reporte de
diariamente, semanalmente, ventas.
quincenalmente, mensualmente.
Se requiere de un módulo especial,
donde se enlisten todos los productos
que ofrece el restaurante, así mismo
Completado
que pueda dar opción de eliminar, editar Gestionar producto.
o agregar ese producto en caso de que
se haya agotado tal producto o se
requiera agregar un nuevo producto.
Completado
3.1.5.1 Matriz de requerimientos
NO FECHA ESTATUS CATEGORIA DESCRIPCIÓN COMPONENTE FECHA V
1 20/10/2018 O Funcional Registrar Administración 15/11/2018
datos de
empleados
2 20/10/2018 O Funcional Realizar Ventas 16/11/2018
ventas
3 20/10/2018 O Funcional Consultar Ventas 18/11/2018
ventas
4 20/10/2018 O Funcional Consultar Administración 19/11/2018
productos
5 25/10/2018 O No- Usar SGBD Administración
Funcional
6 25/10/2018 M No- Usar HTML5 y Interfaz
Funcional PHP 7
Documento de visión
En el restaurant el Ostión, los administradores nos han reportado

que tienen problemas para organizar a su personal, así como las
mesas del local. Esto hace que los pedidos se atrasen, se confundan y
no exista un protocolo a seguir para estas situaciones.
Por lo tanto, empezamos con los stakeholders

identificados:
• Administradores
• Meseros
• Gerentes
• Desarrolladores
• Clientes
• Inversionistas
• Analistas
Fronteras del sistema
Ilustración 1Diagrama General de Casos de Uso

Restricciones
Quedan definidas como restricciones todo aquello que no entre en nuestra responsabilidad
de elaborar ya sea porque se sale de lo establecido en el contrato o por alguna otra razón
debidamente estipulada.
• Modificaciones luego de la entrega final

• Libre difusión del código
• Pagar dos días hábiles después de entregado el proyecto
• Integrar al equipo de trabajo a personal no calificado o evaluado por el gerente del
proyecto.
Problema
El restaurant tiene el inconveniente de que sus mesas no son gestionadas de la
manera correcta, muchas veces dos meseros son asignados a la misma mesa, por
lo que a veces confunden los pedidos o tardan en traerlo.
Nosotros proponemos un sistema que pueda gestionar a los empleados del
restaurant, así como sus roles. también crear un menú digital para agilizar los
pedidos, englobando de esta manera todo lo requerido para gestionar un restaurant.
Características
• Ventana principal de login.
• Gestión de empleados
• Gestión de menú digital
• Cobro en efectivo o con tarjeta
• Intuitivo y fácil de usar
• Orientado a tabletas
• Creación de reporte de ventas por periodos.
Planteamiento
Hoy en día, los restaurantes que se encuentran en nivel medio y pequeño persisten
en la problemática de los atrasos en el ámbito tecnológico, los métodos de gestión
y su forma de producir, vender y administrar están presentando problemas al no
poder competir con las tecnologías actuales. Ahora las empresas de este giro
realizan sus operaciones de manera manual, por eso existe mucha perdida de
información, tiempo y producción. Esto nos lleva a proponer y generar cambios para todos
ellos.
3.1.5.2 Análisis de requerimiento

3.1.5.3 Requerimientos Funcionales
RF01: Se requiere un módulo para llevar el registro de todos los empleados que colaboren en el
restaurante.
RF02: Se requiere un módulo de ventas que registre el nombre del producto, la descripción de ese
producto, el precio y la cantidad. Así mismo que calcule el total a pagar y calcular cambio.
RF03: Se requiere un módulo para consultar las ventas que se han hecho ya sea diariamente,
semanalmente, quincenalmente, mensualmente.
RF04: Se requiere de un módulo especial, donde se enlisten todos los productos que ofrece el
restaurante, así mismo que pueda dar opción de eliminar, editar o agregar ese producto en caso
de que se haya agotado tal producto o se requiera agregar un nuevo producto.
RF01: Se requiere un módulo para llevar el registro de todos los empleados que colaboren en el
restaurante.
RF02: Se requiere un módulo de ventas que registre el nombre del producto, la descripción de ese
producto, el precio y la cantidad. Así mismo que calcule el total a pagar y calcular cambio.
RF03: Se requiere un módulo para consultar las ventas que se han hecho ya sea diariamente,
semanalmente, quincenalmente, mensualmente.
RF04: Se requiere de un módulo especial, donde se enlisten todos los productos que ofrece el
restaurante, así mismo que pueda dar opción de eliminar, editar o agregar ese producto en caso
de que se haya agotado tal producto o se requiera agregar un nuevo producto.
3.1.5.4
Requerimientos No Funcionales
Software
RNF01: Sistema Gestor de Base de datos
Se utiliza el sistema gestor de base de datos relacional Oracle. Se implementa debido a su
seguridad y al eficiente manejo de grandes volúmenes de datos. Se utiliza la versión 7.
RNF02: IDE (Entorno de Desarrollo Integrado)
Se desarrolla el proyecto utilizando el IDE Netbeans, en la versión 8.0.2 para la aplicación de
escritorio.
Hardware
RNF03: El sistema de información se instalará en 1 computadora cliente, cuenta procesador
Core I3 CPU 3.5 GHz, 4 GB de memoria RAM y usa el sistema operativo Windows 7.
3.1.6 Plan de pruebas

3.2 Diseño
3.2.1 Diseño de procesos propuestos
3.2.2 Diagramas secuenciales
Diagrama de secuencia: Agregar un producto

Diagrama de secuencia: Editar un producto
Diagrama de secuencia: Consultar un producto

Diagrama de secuencia: Eliminar un producto
Diagrama de secuencia: Registrar empleado

Diagrama de secuencia: Gestión de ventas
Diagrama de secuencia: Consultar reporte de ventas
3.2.3 Casos de uso
Caso de Uso: Gestionar producto

Descripción Se encarga de gestionar los productos, es decir, si se
desea eliminar, agregar editar o eliminar un producto
del menú en caso de que vaya agregar un nuevo
producto o un producto que ya no se encuentre
disponible, es decir, se haya agotado.
Precondiciones El cajero debe tener clave del acceso al sistema para
poder hacer cambios a los productos.
Condiciones de éxito • Que el cajero elimine con éxito el producto
agotado.
• Que el cajero edite satisfactoriamente el producto.
• Que el cajero agregue un nuevo producto y se
registre con éxito.
Condiciones de • Que no se encuentre en línea la base de datos
fracaso para hacer dichos cambios.
Actores primarios • Cajero
• Administrador
Disparador • Cajero
Eventos normales 1. El sistema despliega el formulario para iniciar

sesión.
2. El cajero ingresa su nombre de usuario y
contraseña.
3. El cajero selecciona el módulo de Gestión de
Producto.
4. El sistema despliega la lista de todos los
productos.
5. El cajero procede hacer alguna modificación.
Excepción 2(a) Que el nombre de usuario y contraseña no
se capturen correctamente.
2(b) Que la base de datos no esté en línea.
Diagrama de Caso de Uso: Agregar un nuevo producto
Diagrama de Caso de Uso: Editar un nuevo producto

Diagrama de Caso de Uso: Eliminar un producto
Diagrama de Caso de Uso: Consultar un producto

Caso de Uso: Gestionar ventas
Descripción Se encarga de registrar las ventas, calcular el total a
pagar.
Precondiciones • Tener datos del producto.
Condiciones de éxito • Registrar exitosamente el producto en la base de
datos.
Condiciones de • Que se capturen mal los datos de la venta o
fracaso producto.
• Que la base de datos no esté disponible.
Actores primarios • Cajero
• Administrador
Disparador • Cajero
Eventos normales 1. El cajero selecciona el modulo Gestión de Ventas.

2. El sistema despliega la interfaz con los campos
para ingresar los datos del producto.
3. El sistema calcula el total a pagar.
4. La base de datos almacena la venta.
5. Se cierra la base de datos
6. La interfaz muestra el total a pagar.
Excepción 2(a). Que se capturen mal los datos del producto.
4(a). Que la base de datos no esté disponible.
Diagrama de Caso de Uso. Gestionar ventas
Caso de Uso: Registrar empleado

Descripción Se encarga de registrar un nuevo empleado, con sus
datos personales.
Precondiciones • Se debe contar con los datos personales del
empleado.
Condiciones de éxito • Registrar exitosamente el nuevo empleado.
Condiciones de • Que se capturen mal los datos personales.
fracaso
Actores primarios • Administrador
Disparador • Administrador
Eventos normales 1. El administrador selecciona el modulo Registrar

nuevo empleado
2. El sistema despliega el formulario
3. El administrador captura los datos del empleado
4. Se guardan los datos.
Excepción 3(a). El administrador capture mal los datos.
4(a). La base de datos no esté disponible.
Caso de Uso: Consultar reporte de ventas

Descripción Se encarga de hacer una consulta de los reportes de
venta. El reporte puede hacerse diariamente,
semanalmente, quincenalmente o mensualmente.
Precondiciones • Se debe contar con el nombre de usuario y la
contraseña para poder acceder correctamente al
sistema.
Condiciones de éxito • Mostrar exitosamente las consultas.
Condiciones de • Que la base de datos donde se encuentran las
fracaso ventas no esté en línea.
Actores primarios • Administrador
Disparador • Administrador
Eventos normales 1. El administrador debe autentificarse en el sistema.

2. El sistema despliega el sistema de inicio de sesión
3. El administrador ingresa nombre de usuario y
contraseña.
4. La base de datos valida los datos si son correctos.
5. El administrador selecciona el modulo Reporte de
Ventas.
6. El sistema despliega la interfaz de reporte de
ventas
7. El administrador selecciona el tipo de periodo.
8. La base de datos muestra los datos de la venta.
Excepción 3(a). Se ingresen correctamente los datos.
8(a). Que la base de datos se encuentre
disponible.
Diagrama de Caso de Uso: Consultar reporte de ventas
3.3 Diseño de base de datos

3.3.1 Diagrama entidad relación
3.3.2 Modelo relacional
3.3.3 Diccionario de datos
Proveedor
Campo Tipo Tamaño Descripción
id Int 10 Llave primaria
Nombre Varchar 200 Es el nombre del proveedor
Contacto Varchar 200 La manera para contactarlo
Teléfono Varchar 20 El numero telefónico
Dirección Text 50 El domicilio del proveedor
Id_usuario Int 50 Llave foránea
Productos

Id Int 10 Llave primaria
Descripción Text 200 Una breve descripción del producto
Precio Decimal 10.00 El costo del producto
Cantidad Int 4 La existencia del producto
Status Int 10 Como se encuentra el producto
Id_usuario Int 50 Llave foránea
Id_proveedor int 50 Llave foranea
cliente
RFC Varchar 15 Registro federal del contribuyente
Nombre Varchar 50 El nombre del cliente
Teléfono Carhcar 15 El numero telefónico del cliente
Dirección Text 200 El domicilio del cliente
Id_usuario int 50 Llave foranea
Usuario
Nombre Varchar 50 El nombre del usuario del sistema
Correo Varchar 100 El email del contacto
Usuario Varchar 15 El usuario del usuario del sistema
Pasword Varchar 100 La contraseña del usuario
Rol Varchar 10 El rol que cumple el usuario
Ventas
No_venta Int 1000 El folio de la venta
Fecha Date 8 Cuando se hizo la venta

Monto Decimal 10.00 El total de la venta
Id_cliente Int 50 Llave foránea
Id_usuario int 50 Llave foranea
3.3.4 Mapa de navegación
3.3.5 Diseño de interface

3.3.6 Modelo de Negocios
3.3.7 Modelo arquitectónico
LOGIN
PLATILLOS EMPLEADOS VENTAS
3.3.8 Tabla de costos

Análisis: Costo de inversión
Tabla 1: Desglose de la inversión del proyecto
Inversión fija
Renta de local 9,000
Imprevistos 1,800
SubTotal 10,800
Inversión semifija
Agendas 400
Poststicks 100
Plumas 20
Renta telefónica 1,170
Internet 12,000
SubTotal 13,690
Inversión diferida
Curso de JAVA 600
Capacitaciones 6,000
Seguridad 3,000
SubTotal 9,600
Capital de trabajo
Medios de almacenamiento 3,000
Salarios 90,000
Manejador de base de datos: SQL
10,000
Server
SubTotal 103,000
TOTAL 137,090
3.4 Contrato de Desarrollo de Software
REUNIDOS
En Comalcalco, Tabasco a 22 de noviembre de 2018
DE UNA PARTE:
SoftTec (en adelante, EMPRESA DESARROLLADORA), con domicilio en Sánchez Magallanes 148 Alt, Col.
Centro, Cárdenas Tabasco, CP. 86500, en su nombre y representación C. Emanuel Córdova Montiel, actuando
en calidad de Líder de Proyecto.
Y DE OTRA:
EL Ostión Gulion (en adelante, EMPRESA CLIENTE), con domicilio en Ranchería Oriente 1ra Sección, 86600,
de Paraíso Tabasco, en su nombre y representación Sra. Norma Díaz Córdova, actuando en calidad de
Propietaria.
Los contratantes se reconocen recíprocamente, en el carácter en que intervienen, plena capacidad jurídica
para contratar y en el caso de representar a terceros, cada uno de los intervinientes asegura que, el poder con
el que actúa no ha sido revocado ni limitado, y que es bastante para obligar a sus representados en virtud de
este CONTRATO DE DESARROLLO DE SOFTWARE y a tal objeto:
EXPONEN:
I. Que, EMPRESA DESARROLLADORA de conformidad con su objeto social, se dedica a la programación e
integración de sistemas de software.
II. Que, EMPRESA CLIENTE está interesada en contratar a EMPRESA DESARROLLADORA un sistema de
software con los requisitos y estipulaciones acordados en este contrato.
III. Que, en base a lo anterior, ambas partes acuerdan la suscripción del presente contrato que se regirá de
acuerdo con los siguientes:
PACTOS Y ESTIPULACIONES:
PRIMERA. - DEFINICIONES
Por mantenimiento correctivo se entiende en este contrato el definido en el estándar técnico de mantenimiento
de software IEEE 1219-1998: “Modificaciones realizadas a un producto de software después de su entrega
para corregir fallos descubiertos”.
Por mantenimiento adaptativo o perfectivo, en este contrato se entiende el así definido en el mismo estándar
técnico de mantenimiento de software IEEE 1219-1998: “Modificaciones realizadas a un producto de software
después de su entrega para adaptar su funcionamiento a nuevas condiciones del entorno de operación, o para
ampliar o modificar su funcionamiento”.
SEGUNDA. - OBJETO
El objeto del presente contrato es el desarrollo por parte de EMPRESA DESARROLLADORA del sistema de
software del proyecto denominado “Sistema de Gestión de Restaurante Ostión Gulion”.
TERCERA CICLO DE DESARROLLO

La construcción del sistema de software objeto de este contrato se llevará a cabo de forma iterativa e
incremental, de forma que EMPRESA DESARROLLADORA ejecutará ciclos de programación sucesivos, y al
final de cada uno entregará según las estipulaciones del apartado CUARTO la parte desarrollada.
La descripción de las funcionalidades y requisitos que debe cumplir cada entrega parcial del producto las
acordarán las partes en contratos anexos a este acuerdo marco.
Cada contrato anexo incluirá:
a) Información identificativa: Fecha, referencia al presente contrato y a su condición de anexo del mismo.
b) Descripción de los requisitos funcionales que deben realizarse o modificarse, indicando para cada uno
los criterios que se emplearán para validar la parte que se ha realizado.
c) Fecha límite para la entrega del software según las estipulaciones del apartado CUARTO.
d) Precio y forma de pago convenido por las partes por el desarrollo e integración en los equipos de
producción del producto de software desarrollado.
e) Condiciones de penalización o garantía que pudieran resultar aplicables por retrasos en la entrega del
producto de software desarrollado.
f) Cuando proceda, indicación de si se trata de la última fase de desarrollo prevista por EMPRESA
CLIENTE, y que, por tanto, tras su entrega y validación según Las estipulaciones CUARTA Y QUINTA
de este contrato, se dará fin al mismo.
CUARTA. - ENTREGA DE LOS PRODUCTOS DE SOFTWARE.

Al final de cada iteración o ciclo de programación EMPRESA DESARROLLADORA procederá a la entrega del
sistema.
A los efectos y finalidad de este contrato, por entrega se entiende:
a) Integración e instalación en estado de funcionamiento correcto, por parte de EMPRESA

DESARROLLADORA del software desarrollado, sobre los equipos de hardware de producción, que
para tal fin EMPRESA CLIENTE tendrá disponibles y accesibles telemática y físicamente para el
personal técnico de EMPRESA DESARROLLADORA.
b) Entrega de EMPRESA DESARROLLADORA a EMPRESA CLIENTE, en formato digital, todos los
productos y subproductos de software desarrollados: código fuente, ejecutables en su caso, y
documentación desarrollada: diseño, análisis, pruebas...
Se considerará por entregada una parte del sistema cuando se encuentre instalada y en condiciones de operar
sin errores aparentes, y entregados en formato digital los productos y sub-productos de software generados
en el ciclo de desarrollo.
QUINTA. - VALIDACIÓN DE LAS ENTREGAS PARCIALES.
Tras la entrega de cada parte del sistema, EMPRESA CLIENTE dispondrá de 10 días naturales para realizar
las pruebas de verificación y validación que estime oportunas.
Si durante las pruebas encontrara errores o deficiencias, lo notificará por escrito a EMPRESA
DESARROLLADORA, para que proceda a contrastarlos y subsanarlos.
Si fuera necesario subsanar errores, EMPRESA DESARROLLADORA una vez realizados los arreglos,
procederá a una nueva entrega.
Si los errores detectados afectan a funcionalidades básicas para el funcionamiento de “Sistema de Gestión de
Restaurante Ostión Gulion”, e implican que no puede ponerse en explotación el subsistema desarrollado, la
fecha de la entrega con los errores subsanados es la que se computará como fecha de entrega válida, y tras
la cual EMPRESA CLIENTE dispondrá nuevamente de 10 días naturales para realizar pruebas de verificación
y validación.
Si pasados 10 días naturales tras la entrega EMPRESA CLIENTE no indicara problemas o deficiencias, se
entenderá que la entrega ha sido validada por EMPRESA CLIENTE.
SEXTA. - PROPIEDAD INTELECTUAL
Corresponden a EMPRESA CLIENTE cualesquiera derechos de explotación derivados de la Ley de Propiedad
Intelectual, tanto del sistema programado, como de los subsistemas que lo integran, y que igualmente hayan
sido desarrollados por EMPRESA DESARROLLADORA, así como de todos los subproductos: documentación
técnica de análisis y diseño, documentación de planificación y pruebas, etc.
EMPRESA DESARROLLADORA garantiza que los trabajos y servicios prestados a EMPRESA CLIENTE por
el objeto de este contrato no infringen ni vulneran los derechos de propiedad intelectual o industrial o
cualesquiera otros derechos legales o contractuales de terceros.
SÉPTIMA. - GARANTÍA
Una vez entregada y validada cada parte, se iniciará un periodo de garantía del correcto funcionamiento y
adecuación a los requisitos de rendimiento y calidad de 3 meses.
La garantía cubrirá el servicio de mantenimiento correctivo por parte de EMPRESA DESARROLLADORA, con
un tiempo de respuesta a las notificaciones de incidencias inferior a las 36 horas laborables desde la
notificación, y un tiempo de reparación acorde al esfuerzo técnico necesario para su reparación.
La garantía no cubre operaciones de mantenimiento adaptativo o perfectivo.
OCTAVA. - RESOLUCIÓN DEL CONTRATO
El presente contrato quedará resuelto al producirse alguna de las siguientes causas:
a) Entrega y validación de la parte del desarrollo consignada como última en el contrato de requisitos de
dicha parte.
b) Por decisión de EMPRESA CLIENTE. Si la resolución por esta causa y la comunicación a EMPRESA
DESARROLLADORA se produjera a mitad de un ciclo de programación, la resolución se llevará a
cabo al finalizar el mismo.
c) Incumplimiento de las obligaciones correspondientes a cada parte. La resolución por esta causa podrá
dar lugar a indemnización por daños y perjuicios causados por el incumplimiento.
d) Por hallarse cualquiera de las partes en un supuesto de caso fortuito o fuerza mayor.
Si el contrato se resuelve anticipadamente sin producir la entrega del sistema de software en su totalidad o en
la forma dispuesta en este contrato, ambas partes colaborarán de buena fe y en especial EMPRESA
DESARROLLADORA para facilitar, bien la contratación de una nueva entidad que dé continuidad a los
trabajos, o bien para que EMPRESA CLIENTE pueda continuar con los trabajos, y en cualquiera de los casos
facilitar la transferencia del conocimiento y sub-productos generados.
A la resolución del contrato, EMPRESA DESARROLLADORA, con independencia de las entregas parciales
hayan realizado, entregará a EMPRESA CLIENTE todos los productos y documentación del software
producidos, con un sistema de clasificación y acceso que permita identificar las versiones de cada componente
conforme a cada versión del sistema construido.
NOVENA. - GENERAL
Personal: cada parte asume, a título exclusivo el carácter de patrono o empresario de su personal empleado
para la ejecución del presente contrato.
Interlocutores válidos: para llevar a cabo las comunicaciones necesarias durante la ejecución del contrato se
nombran como interlocutores válidos:
POR EMPRESA CLIENTE.

[D. Dña]. [Nombre]
[Domicilio]
Teléfono: [Nº teléfono]
e-mail: [e-mail]
POR EMPRESA DESARROLLADORA

Emanuel Córdova Montiel
Cárdenas, Tabasco.
Teléfono: 9371542592
e-mail: emacordovamontiel@hotmil.com
Efecto: El presente contrato surtirá efecto a partir de la fecha de su firma.

Cesión del contrato: Las partes no pueden ceder, transferir ni delegar el presente contrato o alguna de sus
obligaciones, ni subrogar a terceros en cualquier forma válida en derecho, ni gravar o hipotecar alguno de los
derechos contemplados en el contrato, sin la previa conformidad escrita de la otra parte.
Contrato completo: El presente contrato, incluidos los anexos que irán generando los documentos de requisitos
con las firmas de aceptación de las partes, constituyen el total del contrato entre las partes sobre el objeto del
mismo, y sustituye, deroga y deja sin efecto cualquier otro acuerdo referido al mismo objeto a que hubieren
llegado las partes con anterioridad a la fecha de la firma.
Nulidad o anulabilidad: La declaración de cualquiera de estas estipulaciones como nula, inválida o ineficaz no
afectará a la validez o eficacia de las restantes, que continuarán vinculando a las partes.
La renuncia de una parte a exigir en un momento determinado el cumplimiento de uno de los pactos acordados
no implica una renuncia con carácter general ni puede crear un derecho adquirido para la otra parte.
Exención de responsabilidad: ninguna de las partes será responsable por incumplimiento o retraso de sus
obligaciones si la falta de ejecución o retraso fuera consecuencia de caso fortuito o fuerza mayor.
DÉCIMA. - FIRMAS
Leído que fue el presente instrumento por las partes intervinientes del mismo, y aceptando los términos y
condiciones estipulados, por su plena y libre voluntad, lo firman en todas y cada una de sus 6 fojas útiles en
un número de 4 tantos, en la ciudad de Comalcalco Tabasco a los 14 días del mes de diciembre del año 2008.
Empresa Cliente Empresa Desarrolladora
Nombre: Norma Díaz Córdova Nombre: Emanuel Córdova Montiel

Cargo: Propietaria Cargo: Líder de Proyecto
Testigos
Nombre: Nombre:
Domicilio: Domicilio:
CAPITULO 4
Pruebas y
resultados.
4.3 Pruebas
4.3.1 Prueba de Aceptación
4.3.1.1 Plan de Prueba de aceptación
23/11/2019
28/11/2019
4.3.2 Prueba de Desempeño
4.3.2.1 Plan de prueba
28/11/2019
4.3.2.2 Reporte
Informe de las pruebas de rendimiento

Se aplicaron pruebas de estabilidad al sistema con 3 usuarios virtuales simultaneos, teniendo en
cuenta que los resultados que debe arrojar para considerar un rendimiento optimo son:
-transferencia de datos no mayor a 20 mb
-que no se creen cuellos de botella
▼ Test Name
Test Run Name

Test run description
Test result name 2019_10_21_7_37_59_200_pr_os
Test File name pr_os.ssconfig
Script last modified domingo, 20 de octubre de 2019 09:09:24 p. m.
▼ Test Settings
Load pattern Steady Load - 3 VUs

Complete after (hh:mm:ss) 3 Per VU iterations
Warm-up time (s) 0
▼ Test Run Information
Start time oct.-21 2019 07:37:59

End time oct.-21 2019 07:39:17
Test run duration 00:01:17
▼ Overall Result
Completion Status Completed

Pass/Fail Status Passed
Max User Load 3
Total sent (KB) 606.918
Total received (KB) 16,332.888
KB sent/sec 7.803
KB received/sec 209.996
▼ Test Iterations
Avg. Iteration time (s) 21.029

Iterations started 9
Iterations passed 9
▼ Requests
Avg. response time (s) 0.159

Requests/sec 10.53
Number of URLs 96
Total requests issued 819
Request errors 0
Request timeouts 0
Con esta prueba podemos darnos cuentas que el software esta trabajando perfectamente, solo
observamos un error en el tiempo de respuesta de una petición que se hizo en el minuto 4
4.3.3 Prueba de Integración

28/11/2019
4.3.3.1 Reporte
Informe de Pruebas de Integración del Proyecto de

Sistema de Ventas para el restaurante El Ostion
1. Introducción
Este documento tiene como fin demostrar con evidencia que la prueba de integración aplicada al
sistema de ventas para el restaurante El Ostion ha sido completada con cada uno de sus casos de
prueba. Por otra parte, demuestra como verificado y completado cada uno de los puntos
anteriores que se especificaron en el plan de pruebas de integración.
2. Mecanismos de Verificación
Para aplicar cada uno de los casos de prueba se fue realizando y gestionando un tiempo de
duración por cada caso de prueba que se aplicó al proyecto. En función de los datos de entrada
y de sus respectivas salidas esperadas se llevo a cabo cada uno de los casos de prueba definidos.
3. Criterios de Verificación
Para verificar cada uno de los casos de prueba se consideraron como “cumplidos”, es decir, que
los resultados esperados por cada una de las salidas esperadas de los casos de prueba eran los
mismo que los que el sistema de ventas mostraba, entonces cumplen con el criterio que se había
aplicado o definido.
4. Resultados de la Verificación del Plan de Pruebas de Integración

Reporte de Verificación
Plan de Pruebas de
Integración
Lugar: Instituto Tecnológico
Fecha: 10-10-2019 Duración: 1 hora y 35 minutos.
28/11/2019
Superior de Comalcalco.
Participantes:
Nombr Puesto
e
Emanuel Córdova Montiel Analista
Jasiel Elimas Diseñador
Elemento a verificar Descripción de defecto
Introducción Cumple con el criterio aplicado
Objetivos Cumple con el criterio aplicado
Casos de prueba Cumple con el criterio aplicado
Descripción de la
integración de componentes Cumple con el criterio aplicado
Requerimientos de ambiente
• Recursos de Sistema
Cumple con el criterio aplicado
• Herramientas
4.3.4 Prueba de Interfaces y contenidos
1. Introducción
Las actividades de esta etapa consisten en hacer revisiones precisas de la forma en que
se despliegan las páginas del sitio, en este caso, el sistema de ventas. Por ejemplo,
verificar la diagramación del sistema en diferentes navegadores o clientes web, asi como
también el despliegue de las imágenes, y más que nada verificar el contenido.El
documento se divide en dos partes, en la primera parte se muestra los casos de pruebas
para verificar el contenido y en la segunda
parte verificar las interfaces del mismo.
2. Objetivos
A continuación se listan los objetivos que deberá alanzar la prueba.
• Comprobar que los casos de prueba detecten errores en el sistema.
4.3.4.2 Reporte
Informe de Pruebas de Interfaces y Contenido del

Proyecto de Sistema de Ventas para el restaurante El
Ostion
1. Introducción
Este documento tiene como fin demostrar con evidencia de los resultados obtenidos al aplicar la
prueba de interfaces y contenido. Para la ejecución de la prueba no se requirieron algunas
herramientas para probar las interfaces y posteriormente, el contenido.
Para aplicar cada uno de los casos de prueba se fue realizando y gestionando un tiempo de
duración por cada caso de prueba que se aplicó al proyecto. En función de los datos de entrada
y de sus respectivas salidas esperadas se llevo a cabo cada uno de los casos de prueba definidos.
Para verificar cada uno de los casos de prueba se consideraron como “cumplidos”, es decir, que
los resultados esperados por cada una de las salidas esperadas de los casos de prueba eran los
mismo que los que el sistema de ventas mostraba, entonces cumplen con el criterio que se había
4. Procedimiento utilizando herramientas.
Para ejecutar los casos de prueba se utilizó dos herramientas mencionadas en el plan de pruebas,
una herramienta para comprobar si habían enlaces rotos en la navegación del sistema y para el
contenido.
Para comprobar que los enlaces funcionen correctamente, se dirige la pagina de la herramienta
W3C. Es un servicio de la W3C para encontrar si existe algún error en los enlaces.
Como segundo paso, en el campo de texto, se escribe o se ingresa la URL del sistema, sitio web,
etc. En este caso, la dirección completa del sistema de ventas.
https://elostionrestaurant.000webhostapp.com/sistema/
Finalmente, al consultar los posibles errores, el servicio muestra cada uno de los enlaces
mostrando una lista de los posibles enlaces con mayor probabilidad de estar rotos.
Como segunda herramienta, para la prueba de interfaces, entrara en uso la herramienta de Google,
PageSpeed Insights.
Para utilizar la herramienta solo basta con ingresar de igual manera, la URL del sistema.
Como se muestra en la captura de pantalla, muestra un puntaje, solo que este puntaje, es evaluado
de acuerdo a como se despliega el sistema de ventas desde un terminal móvil. Cabe señalar, que
el sistema de ventas ni fue diseñado para adaptarse a dispositivos móviles ni mucho menos para
administrar el sistema de ventas desde uno. Por lo tanto, los errores y advertencias mostradas por
la herramienta son muy altas.
Ahora, para verificar los resultados de los datos de como se despliega el sistema desde un
ordenador.
Como se muestra en la captura, la diferencia es muy alta a la prueba que se obtuvo desde un
dispositivo móvil por lo tanto, el sistema de ventas se despliega de excelente forma en un ordenador.
1. Resultados obtenidos.
Errores
Caso de prueba Resultados Observaciones
encontrados
Se puede utilizar a
Verificación de Cumple con el un más un formato
Ninguno
ortografía y redacción. criterio. de fuente más
legible.
Se recomienda
utilizar nombres
cortos para algunos
Cumple con el
Verificación de enlaces. Ninguno ficheros como las
criterio.
fuentes que se
utilizan
remotamente.
Se recomienda
Verificación de imágenes. Cumple con el utilizar formatos de
Ninguno
criterio. imágenes
modernos.
Verificación que todos No cumple con el Los formularios Es necesario realizar
los formularios estén criterio. requieren validarse una validación de
validados. de longitud. cada
Instituto Tecnológico Superior de Página 8

Comalcalco, 2019
c Instituto Tecnológico Superior de Comalcalco
uno de los inputs del

sistema con sus
respectivos
formulario, ya que el
usuario puede
sobrepasar el tamaño
de caracteres
establecidos en la
base de datos.
Todos los inputs

Verificación de campos
tienen su tipo de
(texto, contraseña,
Cumple con el caja de texto, es
emails, fecha) se acepten Ninguno
criterio decir, para entradas
entradas correctas.
de fecha, de tipo
date.
Consistencia en la Cumple con el Se considera un
Ninguno
diagramación. criterio. buen diseño.
El ancho es
Ancho de la Cumple con el
Ninguno adaptable al
diagramación. criterio.
tamaño.
Las reglas CSS para
Verificar que las
que cada uno de los
interfaces se
diseños se
desplieguen Cumple con el
Ninguno desplegarán
correctamente en los criterio.
correctamente en
distintos navegadores
cada uno de los
web.
navegadores web.
1. Resumen de resultados.
Plan de Pruebas de Interfaces y
Contenido
Fecha: 10-10-2019
28/11/2019
Duración: 2 horas y 40 minutos.
Participantes:
Nombr Puesto
e
4.3.5 Prueba unitarias e integración

1. Introducción
Este documento tiene como propósito mostrar una visión de como desarrollar un
plan de pruebas para un proyecto de
software. En este caso, un plan de pruebas para seguridad. En este documento se
muestran qué módulos del sistema se van a probar para verificar si son seguros
así como el sistema en general, como es un sistema basado en web, se hará una
prueba para verificar que las transacciones sean seguras, como por ejemplo, que
las contraseñas de los usuarios sean encriptadas y así mismo que las conexiones
que se realicen sean encriptadas.
2. Objetivos
A continuación, se listan los objetivos que deberá alanzar la prueba.
• Verificar que cada uno de los usuarios se les habilite cada opción (editar,
eliminar, actualizar) según su rol en el
sistema.
• Comprobar que las conexiones del sistema sean seguras.
4.3.5.2 Reporte
Informe de Pruebas de Interfaces y Contenido del

Proyecto de Sistema de Ventas para el restaurante El Ostion
1. Introducción
Este documento tiene como fin demostrar con evidencia de los resultados
obtenidos al aplicar la prueba de seguridad. Las pruebas de seguridad son
una de las pruebas principales que deben de aplicarse a un software
desarrollado.
Para aplicar cada uno de los casos de prueba se fue realizando y gestionando
un tiempo de duración por cada caso de prueba que se aplicó al proyecto. En
función de los datos de entrada y de sus respectivas salidas esperadas se
llevo a cabo cada uno de los casos de prueba definidos.
Para verificar cada uno de los casos de prueba se consideraron como
“cumplidos”, es decir, que los resultados esperados por cada una de las
salidas esperadas de los casos de prueba eran los mismo que los que el
sistema de ventas mostraba, entonces cumplen con el criterio que se había
4. Procedimiento utilizando para realizar pruebas.

Como caso de prueba, se tienen que validar que las conexiones al sistema sean
encriptadas, para ello, se puede desde el cuadro de búsqueda del navegador o
también utilizando una herramienta. A continuación, se va a utilizar un servicio
basado en web para verificar que el sistema utilice un protocolo encriptado, https.
De igual forma, en el campo de texto se agrega o escribe la URL del sistema.

A continuación se muestra el resultado obtenido.
Como segundo caso, las contraseñas de cada uno de los usuario del sistema deben de estar
encriptadas con algún hash de contraseña.
1. Resumen de resultados.
Plan de Pruebas de
Seguridad
Fecha: 10-10-2019
28/11/2019 Duración: 1 hora.
Participantes:
Nombr Puesto
e
Roles de los usuarios Cumple con el criterio aplicado
Entorno de la prueba Cumple con el criterio aplicado
4.3.6 Prueba Usabilidad

28/11/2019
4.3.6.2 Reporte
Infórme de las pruebas de Usabilidad

Luego de realizar la prueba de usabilidad vimos como los usuarios hacían uso de las
diferentes funciones del sistema, como agregar clientes, proveedores, platillos y realizar
ventas.
Menú principal
Luego de acceder al menú principal el vendedor tiene la posibilidad de acceder a consultar
el menú del restaurant
Búsqueda de productos
En este modulo el usuario mira los productos que hay en el menú y puede ver sus codigos
para luego pasar al modulo de ventas.
Búsqueda de cientes
Pedidos
Ahora el usuario realiza la búsqueda de los productos que desea y los agrega a la lista,
cuando termina de agregar los productos el sistema genera automáticamente un pdf con la
cuenta total a pagar.
Salida del sistema

4.3.7 Prueba de Rendimiento

28/11/2019
4.3.7.2 Reporte
Informe de las pruebas de rendimiento

Se aplicaron pruebas de estabilidad al sistema con 3 usuarios virtuales simultaneos,
teniendo en cuenta que los resultados que debe arrojar para considerar un rendimiento
optimo son:
-transferencia de datos no mayor a 20 mb
-que no se creen cuellos de botella
▼ Test Name
Test Run Name

Test run description
Test result name 2019_10_21_7_37_59_200_pr_os
Test File name pr_os.ssconfig
Script last modified domingo, 20 de octubre de 2019 09:09:24 p. m.
▼ Test Settings
Load pattern Steady Load - 3 VUs

Complete after (hh:mm:ss) 3 Per VU iterations
Warm-up time (s) 0
▼ Test Run Information
Start time oct.-21 2019 07:37:59

End time oct.-21 2019 07:39:17
Test run duration 00:01:17
▼ Overall Result
Completion Status Completed

Pass/Fail Status Passed
Max User Load 3
Total sent (KB) 606.918
Total received (KB) 16,332.888
KB sent/sec 7.803
KB received/sec 209.996
▼ Test Iterations
Avg. Iteration time (s) 21.029

Iterations started 9
Iterations passed 9
▼ Requests
Avg. response time (s) 0.159

Requests/sec 10.53
Number of URLs 96
Total requests issued 819
Request errors 0
Request timeouts 0
Con esta prueba podemos darnos cuentas que el software esta trabajando perfectamente,
solo observamos un error en el tiempo de respuesta de una petición que se hizo en el
minuto 4
4.3.8 Prueba Unitaria

28/11/2019
28/11/2019
4.3.8.1 Reporte
Informe de Pruebas de Integración del Proyecto de Sistema

de Ventas para el restaurante El Ostion
1. Introducción
Este documento tiene como fin demostrar con evidencia de los resultados
obtenidos al aplicar la prueba unitaria, cabe señalar, que la prueba solo se
aplicó al modulo de productos y al modulo de ventas; específicamente a
verificar los procedimientos almacenados de MySQL, ya que, son los que
realizan las funciones principales al realizar una venta. Desde PHP se llamó el
procedimiento almacenado.
Para aplicar cada uno de los casos de prueba se fue realizando y gestionando
un tiempo de duración por cada caso de prueba que se aplicó al proyecto. En
función de los datos de entrada y de sus respectivas salidas esperadas se llevo
a cabo cada uno de los casos de prueba definidos.
Para verificar cada uno de los casos de prueba se consideraron como
“cumplidos”, es decir, que los resultados esperados por cada una de las salidas
esperadas de los casos de prueba eran los mismo que los que el sistema de
ventas mostraba, entonces cumplen con el criterio que se había aplicado o
definido.
5. Procedimiento al utilizar Phpmyadmin como

herramienta para ejecutar las pruebas.
Phpmyadmin tiene funciones tanto para crear procedimientos almacenados como
para también ejecutar y editar el procedimiento creado. Solo en esta caso, se está
utilizando Phpmyadmin para probar los procedimientos almacenados, ya que no hay
una herramienta para hacer o realizar pruebas unitarias a éstos. Para ello, se dirige
o se accede directamente a éste desde Phpmyadmin. Para estos casos de prueba,
se va probar el procedimiento almacenado que es encargado de procesar los datos
de la venta.
Posteriormente, se ejecuta el procedimiento almacenado, cabe destacar, que al instante

de que se ejecuta el procedimiento almacenado, éste pedirá parámetros, como por ejemplo
en este caso como el código del usuario, el código de cliente y un token de inicio de
sesión. Estos parámetros son necesarios para poder llevar a cabo al procesar una venta,
sin embargo, esto solo ocurre de forma transparente.
Resultados de la Verificación del Plan de Pruebas Unitarias.
Plan de Pruebas de
Integración
Fecha: 10-11-2019 Duración: 2 horas.
Participantes:
Nombr Puesto
e
Jasiel Elimas Diseñador
Entorno de la prueba Cumple con el criterio aplicado
Datos de la prueba Cumple con el criterio aplicado
CAPITULO 5 Conclusiones y trabajos futuros
Reporte de estatus
REPORTE DE ESTATUS
Proyecto: El Ostión
Emanuel Córdova Montiel-Adrián Barahona
Ortiz- Jasiel Elimas López Jiménez.
Nombre del Implementación de un Restaurant El
Cliente
proyecto sistema de ventas Ostion
Retraso Fecha de
% de Avance Retraso(%)
(tiempo) consulta
Modelo de desarrollo integral CMMI.
KPA’S del nivel 2 aplicadas al proyecto.
consumidas
Total de horas reales Total de horas
Dinero
Dinero gastado estimadas
estimado
ACTIVIDADES
HORAS REALES HORAS
NOMBRE
CONSUMIDAS ESTIMADAS
Entrevista con el cliente 72 horas 48 horas
Requerimientos funcionales 120 horas 72 horas

Revisión SQA
Sistema de Ventas para el restaurant El Ostión Número <01b>
Revisión Fecha: 28/Nov /2019

Clave Revisión: 01b
Proyecto: Sistema de ventas
Cliente: Restaurant El Ostión Gulión
Tipo de Revisión: Revisión del plan de proyecto
Entregable RevisionSQA V1.0

Revisado:
Fecha: Nov/23/2019 12:00 - 1:00 pm, Nov/26/2019 10:00 - 12:00
Revisión del plan de proyecto. (Diagrama de Gantt
Modelo de desarrollo integral CMMI.

KPA’S del nivel 2 aplicadas al
proyecto.
Revisó: Emanuel Córdova Montiel
Desarrolló: Adrián Barahona Ortiz
Status del corregido

Producto:
Resultado de Revisión
NOTA 1: Cada punto será corregido de acuerdo a la prioridad

asignada: [P1]Prioridad1. Es indispensable que sea corregido.
[P2]Prioridad2. Es indispensable que sea corregido, sólo si la gerencia de

Producción está de acuerdo con que se corrija (si no es contraproducente para
lograr el éxito del proyecto)
[P3]Prioridad3. Hay que tomarlo en cuenta para futuros proyectos, aunque si

el
Líder de Proyecto lo desea puede corregirlo desde este
proyecto.
Clave Hallazgos / Responsable Prioridad Fecha Estatus

artefacto Recomendaciones Compromiso
revisado
01 Se encontró que Adrián Prioridad 24/11/2019 Por corregir

Barahona 2
algunos requerimientos
llevaron más tiempo Ortiz
completarlos que lo
planeado.
02 El módulo de ventas Emanuel Prioridad 24/11/2019 Corregido

Córdova 3
requirió más tiempo de
planeado para Montiel
desarrollarlo.
03 Al no detectar un riesgo Adrián Prioridad 24/11/2019 Corregido

Barahona 3
la implementación del
Ortiz
sistema de ventas se
retrasó.
Conclusiones
"Buenas Prácticas" Identificadas

El objetivo de esta sección consiste en ir identificando buenas prácticas implementadas
en los proyectos, e irlas aprovechando para armar una base de conocimientos que
permita mejorar el proceso de la empresa.
a
Buena Práctica Disciplina / Fecha Autor

Área
Hacer una revisión de la Administración 26/mayo/2019 Emanuel

planeación del proyecto cada De Córdova
semana y documentar los Requerimientos Montiel
contratiempos.
Hacer un encuadre de los Administración 26/mayo/2019 Emanuel

requerimientos con la fecha para De Córdova
completarlos. Requerimientos Montiel
Documentar los posibles riesgos Administración 26/mayo/2019 Jasiel

que puedan afectar al proyecto. de riesgos Lopez
Jimenez

Ostion PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ostion PDF

Cargado por

Copyright:

Formatos disponibles

Implementación de un Sistema de

Infórmación para la Gestión del

Comalcalco, Tabasco noviembre 2019

Este proyecto ha surgido como principal propósito fundamental de aumentar la

CAPITULO 1. MODELO CONTEXTUAL ........................................................................ 7

El Restaurant El Ostión Gulion se crea en la Ranchería Oriente 1ra Sección Paraíso

1.2 Planteamiento del problema

1.2.1 Definición del problema

Hoy en día, los restaurantes que se encuentran en nivel mediano y pequeño

1.2.2 Delimitaciones de la Investigación

• Desarrollar e implementar un sistema informático con una base de datos, donde se

• El tiempo estimado para la terminación del producto finalizara.

• Que el sistema no cumpla con las expectativas que se establecieron al inicio de

• Que las herramientas y metodologías predeterminas no sean lo suficiente para

• Por falta de infraestructura no se pueda concretar la realización del producto .

1.2.3 Preguntas de investigación

Diseñar e Implementar un sistema web para el apoyo de la toma de

1.3.2 Objetivos específicos

• Diseñar el sistema de manera intuitiva para el usuario, además que le brinde o

La pérdida de información es muy común cuando la información se encuentra

1.5 metodologia utilizada

1.5.2 Tipo de investigación

Las investigaciones de tipo exploratorias ofrecen un primer acercamiento al

Los resultados de este tipo de tipo de investigación nos dan un panorama o

El modelo de desarrollo en cascada se originó en la industria y la construcción,

CARLOS XAVIER BURGOS CANDO. (2015). “DESARROLLO DE UN SISTEMA WEB

PEDRO DAVID FLORES JIMENEZ. (2013). “SISTEMA DE SOFTWARE DE GESTIÓN DE

2.2 Marco conceptual

2.3.2 Reforma tributaria.

2.3.3 Comprobantes de venta.

Son documentos autorizados previamente por el SRI, que respaldan las

a) Comprobantes de Ventas se debe entregar cuando se transfieren bienes, se

• Facturas: Destinadas a sociedades o personas naturales que tengan derecho a

b) Documentos Complementarios: Son documentos complementarios a los

• Notas de crédito: se emiten para anular operaciones, aceptar devoluciones

2.3 Marco Tecnológico

peticiones, el rendimiento de nuestra aplicación podría verse afectado

JavaScript es un lenguaje de programación que se utiliza principalmente para crear

móviles & PS3.

JQuery es una biblioteca gratuita de JavaScript, cuyo objetivo principal es simplificar

SQL es un potente sistema de base de datos objeto-relacional de código abierto.

Footprint bajo de memoria, bastante poderoso con una configuración adecuada.

Sublime Text es un editor de código multiplataforma, ligero y con pocas

Permite codificar en casi cualquier lenguaje.

• La fundamental es que es difícil de aprender y configurar al principio al ser un editor de

2.3.6 Código abierto (Opensource)

2.3.7 Web Services.

“Las siglas PDF corresponden a la expresión inglesa Portable File Document

“XMLsonlas siglas del Lenguaje de Etiquetado Extensible. La expresión se forma a

2.3.10 Windows Microsoft Windows

es un sistema operativo, es decir, un conjunto de programas que posibilita la

2.4 Marco Legal

Herramienta Tipo de Licencia Descripción

Sublime Text Licencia Pública General Editor de texto y de código

3.1.4 Planeación de riesgo

FORMA 1: Planeación adecuada

ELEMENTO Conc Plan Inic Term Int/$ Int/T Int/C Motivos

PREPARACION DE UN PLAN DETALLADO PARA EL DISEÑO,

PARTICIPACIÓN DE LOS USUARIOS EN EL DESARROLLO DEL

INCLUSIÓN DE TODOS LOS PARTICIPANTES DEL SISTEMA

ELEMENTO Conc Plan Inic Term Int/$ Int/T Int/C Motivos

ELEMENTO Conc Plan Inic Term Int/$ Int/T Int/C Motivos

FORMA 5: Integridad de los medios informàticos