Software para el Gestionamiento de

Negocios Enfocados en Sándwiches

Modelo de Construcción y Pruebas de
Software
Versión [1.0]
[Este documento es la plantilla base para elaborar el documento Modelo de
Construcción y pruebas de Software. Los textos que aparecen entre paréntesis
rectos son explicaciones de que debe contener cada sección. Dichos textos se
deben seleccionar y sustituir por el contenido que corresponda. Para actualizar la
tabla de Contenido, haga clic con el botón derecho del ratón sobre cualquier línea
del contenido de la misma y seleccione Actualizar campos, en el cuadro que
aparece seleccione Actualizar toda la tabla y haga clic en el botón Aceptar]

Historia de revisiones
Fecha Versión Descripción Autor
[15/04/2024] [1.0] Primera versión del documento, Damian Alejandro
en donde se especifican las
bases de la construcción del
software.

Modelo de Construcción y pruebas de Software Página 1 de 33

 Contenido
[NOMBRE DEL PROYECTO] 1
MODELO DE DISEÑO CONSTRUCCIÓN DE SOFTWARE 1
VERSIÓN [1.0] 1
HISTORIA DE REVISIONES 1
CONTENIDO 2
1. INTRODUCCIÓN 3
1.1. PROPÓSITO 3
1.2. ALCANCE 3
1.3. DEFINICIONES, SIGLAS Y ABREVIATURAS. 3
1.4. REFERENCIAS 3
1.5. VISIÓN GENERAL 3
2. DISEÑO DE CASOS DE USO 3
2.1. DISEÑO DEL CASO DE USO [NOMBRE DEL CASO DE USO 1] 3
2.1.1. Diagrama de paquetes 3
2.1.2. Diagrama de Interacción 3
2.1.3. Diseño de Flujo de eventos 3
2.1.4. Requerimientos especiales o de implementación 4
2.2. DISEÑO DEL CASO DE USO [NOMBRE DEL CASO DE USO 2] 4
3. DISEÑO DE OBJETOS 4
3.1. [OBJETO 1] 4
3.2. [OBJETO 2] 4
4. DISEÑO DE SUBSISTEMAS 4
4.1. SUBSISTEMAS ESPECÍFICOS 4
4.1.1. [Nombre del Subsistema Específico 1] 4
4.1.2. [Nombre del Subsistema Específico 2] 5
4.2. SUBSISTEMAS DE SOPORTE 5
4.2.1. [Nombre del Subsistema de soporte 1] 5
4.2.2. [Subsistema de soporte 2] 5
5. REVISIÓN DE LA INTERFAZ DE USUARIO 5
5.1. FORMATOS INDIVIDUALES DE INTERFAZ DE PANTALLA 6
5.2. CONTROLES Y ELEMENTOS DE DISEÑO DE INTERFAZ DE PANTALLA 6
5.3. FORMA DE NAVEGACIÓN DE INTERFAZ DE PANTALLA 6
5.4. FORMATOS DE IMPRESIÓN 6
6. DISEÑO DE DATOS 6
6.1. MODELO DE DATOS DEL NÚCLEO 6
6.2. MODELO DE DATOS GENERAL 6
6.3. ESPECIFICACIÓN DE LA DISTRIBUCIÓN DE DATOS 7

7. PLAN DE PRUEBAS DE SOFTWARE………………………………………………………… 8

ALCANCE DE LAS PRUEBAS 8
ELEMENTOS DE PRUEBAS 8
NUEVAS FUNCIONALIDADES A PROBAR 8
PRUEBAS DE REGRESIÓN 9

Modelo de Construcción y pruebas de Software Página 2 de 33

 FUNCIONALIDADES A NO PROBAR 9
ENFOQUE DE PRUEBAS (ESTRATEGIA) 9
CRITERIOS DE ACEPTACIÓN O RECHAZO 9
CRITERIOS DE ACEPTACIÓN O RECHAZO 9
CRITERIOS DE SUSPENSIÓN 9
CRITERIOS DE REANUDACIÓN 9
ENTREGABLES 9
RECURSOS 10
REQUERIMIENTOS DE ENTORNOS – HARDWARE 10
REQUERIMIENTOS DE ENTORNOS – SOFTWARE 10
HERRAMIENTAS DE PRUEBAS REQUERIDAS 11
PERSONAL 11
ENTRENAMIENTO 12
PLANIFICACIÓN Y ORGANIZACIÓN 12
PROCEDIMIENTOS PARA LAS PRUEBAS 12
MATRIZ DE RESPONSABILIDADES 13
CRONOGRAMA 13
PREMISAS 14
DEPENDENCIAS Y RIESGOS 14

Modelo de Construcción y pruebas de Software Página 3 de 33

1. Introducción
Este documento tiene como objetivo proporcionar una guía completa y fácil de
usar para la implementación exitosa de un sistema de venta de sándwiches
eficiente y efectivo. Dedicar tiempo al diseño del software garantiza que la
solución propuesta, en este caso, el software de venta de sándwiches, se
desarrolle de manera reflexiva y eficaz.

El diseño de software es fundamental para evitar problemas como errores en

los pedidos, demoras en la entrega o deterioro en la calidad del producto final.
La documentación detallada de procesos y procedimientos facilita la
comunicación y la negociación entre los diversos interesados en el proyecto,
incluidos los propietarios del negocio, los empleados y los proveedores de
servicios.

La actividad de arquitectura de software y diseño detallado resulta en un

documento de diseño de software que describe claramente las interacciones en
el software y la trazabilidad de los elementos diseñados hacia los requisitos
específicos del negocio de venta de sándwiches. Este documento no solo es
útil durante la fase de desarrollo del software, sino también para futuras
actualizaciones y mejoras, así como para el mantenimiento continuo del
sistema.

1.1. Propósito
Este documento tiene el propósito de presentarlo a los usuarios en
este caso restaurante y colaboradores, una forma en la que puedan
simplificar las tareas demandantes desde la adquisición de insumos
para el restaurante de sándwiches hasta el revisar el inventario
constantemente conforme los pedidos se realicen y dejar solo activas
las opciones de cocina que se pueden preparar conforme a los insumos
de inventario.

1.2. Alcance
Este software de sandwichería facilitará los procesos que a todo
gerente y cocinero les demora, ahorrando tiempo en la gestión de
crear una órden de preparación de alimentos en donde previamente el
software cuente con la capacidad de revisar en inventario si existe la
cantidad suficiente de ingredientes para la elaboración de los
sándwiches, además de mantenerse al día con los lotes y fechas de
caducidad de los insumos que requiere el platillo. A parte de los básico
que conlleva un software punto de venta que es la creación de órden y
cobro ya sea con efectivo o otro medio digital, este sistema contará
con la capacidad de saber que insumos se va a necesitar adquirir y al
cuanto tiempo para evitar la escasez de los mismos, con la finalidad de
que no se deje de elaborar estos sándwiches.

1.3. Definiciones, siglas y abreviaturas.

Modelo de Construcción y pruebas de Software Página 4 de 33

 POS: Punto de Venta.
SKU: Stock Keeping Unit (Unidad de Mantenimiento de Inventario).
CRM: Customer Relationship Management (Gestión de Relaciones con
el Cliente).
KDS: Kitchen Display System (Sistema de Visualización de Cocina).
API: Application Programming Interface (Interfaz de Programación de
Aplicaciones).
EMV: Europay, Mastercard, and Visa (Estándar de Tarjetas de Crédito y
Débito).
NFC: Near Field Communication (Comunicación de Campo Cercano).
QR: Quick Response (Respuesta Rápida).
UI: User Interface (Interfaz de Usuario).

1.4. Referencias
Para la realización del proyecto utilizaremos la plataforma Odoo que es
una plataforma de código abierto que ofrece una amplia gama de
aplicaciones empresariales, incluido un software de punto de venta.
Con ayuda de este nos encargaremos de realizar el software para el
restaurante de sándwiches.

1.5. Visión general

Este programa de punto de venta ofrece un catálogo virtual que
permite a los vendedores navegar y buscar productos por nombre o
ID. Además, proporciona información detallada sobre costos,
ingredientes y preparación para agilizar las ventas. Los vendedores
también pueden agregar notas, quitar ingredientes o modificar la
preparación de los productos según las preferencias del cliente. Una
vez realizado el pedido, el sistema permite agregar órdenes de
compra adicionales y finalizar el proceso de pago, aceptando tanto
efectivo como transferencias digitales. Al finalizar el día, el sistema
facilita el cierre de caja, mostrando las ventas y el total recaudado,
así como los insumos que necesitan reponerse o desecharse debido a
su próxima caducidad. Además, permite ingresar nuevos insumos
al inicio de cada día para la preparación de alimentos.

2. Diseño de Casos de Uso

Algunas de las funciones que va a incluir el software punto de venta
del restaurante de sándwiches:

Administrar Menú: Permite al personal del restaurante agregar,

modificar o eliminar artículos del menú, como diferentes tipos de
sándwiches, bebidas, acompañamientos, etc.

Gestionar Pedidos: Facilita la gestión de los pedidos de los clientes.

Incluye tomar pedidos, modificarlos si es necesario, cancelar pedidos si

Modelo de Construcción y pruebas de Software Página 5 de 33

 el cliente lo solicita y marcar los pedidos como listos para su
preparación y entrega.

Administrar Inventario: Permite al personal del restaurante registrar la

entrada y salida de ingredientes y otros productos necesarios para
preparar los sándwiches. También incluye actualizar el inventario para
mantener un registro preciso de los niveles de stock.
1.6. Diseño del Caso de Uso Sandwichería
1.1.1. Diagrama de paquetes

1.1.2. Diagrama de Interacción

S

Modelo de Construcción y pruebas de Software Página 6 de 33

 1.1.3. Diseño de Flujo de eventos
El software punto de venta (POS) para sandwiches se compone de
varios subsistemas y objetos de diseño, incluyendo la interfaz de
usuario para la interacción con el cliente, la gestión de pedidos para
procesar solicitudes, el control de inventario para mantener
actualizada la disponibilidad de productos, el procesamiento de pagos
para facilitar transacciones financieras, la gestión de clientes para
administrar información de clientes y programas de fidelización, y la
administración y configuración para la configuración del sistema y la
gestión de productos. Estos subsistemas interactúan entre sí para
realizar acciones como agregar productos al carrito, calcular el total

Modelo de Construcción y pruebas de Software Página 7 de 33

 de la compra y actualizar inventarios, facilitando así la operación
eficiente del negocio de sandwiches.

1.1.4. Requerimientos especiales o de implementación

El desarrollo de un software punto de venta (POS) para una
sandwichería requiere cumplir con una serie de requisitos no
funcionales para garantizar su eficacia y usabilidad. Esto incluye
asegurar una interfaz intuitiva y fácil de usar, un rendimiento óptimo
que maneje cargas de trabajo variables, una alta fiabilidad que
minimice los fallos, medidas de seguridad robustas para proteger los
datos confidenciales, la capacidad de escalar conforme el negocio
crezca, compatibilidad con diferentes dispositivos hardware, flexibilidad
para adaptarse a las necesidades específicas del negocio, y facilidad de
mantenimiento y actualización. Al cumplir con estos requisitos, el POS
asegura una experiencia eficiente tanto para el personal como para los
clientes de la sandwichería.

3. Diseño de Objetos
1.7. Clase Ingrediente:
Propiedades:
-nombre: cadena
-precio: decimal
-existencias: entero
Métodos:
-obtenerNombre(): cadena
-obtenerPrecio(): decimal
-ObtenerExistencias(): enteró

1.8. Clase Sandwich:

Propiedades:
-nombre: cadena
-ingredientes: lista ingredientes
-precioTotal: decimal
-existencias: entero
Métodos:
-obtenerNombre(): cadena
-agregarIngrendiente(Ingrediente:Ingrediente)
-calcularPrecioTotal():
-obtenerIngredientes(): lista ingredientes
-obtenerPrecioTotal(): decimal

1.10 Clase Cliente:

Propiedades:
-ID: entero

Modelo de Construcción y pruebas de Software Página 8 de 33

 -pago: decimal
-metodoPago: cadena

Métodos:
-obtenerPago(): decimal
-obtenerMetodoPago(): cadena

1.11 Clase Empleado:

Propiedades:
-ID: entero
-nombre: cadena
-salario: decimal
-usuario: cadena
-contraseña: cadena
-antigüedad: entero/fecha
-dirección: cadena
-status: booleano
-tiempoUso: decimal

Métodos:
-obtenerID(): entero
-obtenerNombre(): cadena
-ObtenerSalario(): decimal
-obtenerAntiguedad(): enteró/fecha
-obtenerDireccion(): cadena
-obtenerUsuario(): cadena
-obtenerTiempoUso(): decimal

1.12 Clase Gerente hereda de Empleado:

Métodos adicionales
-altaEmpleado(empleado:Empleado, gestorEmpleados:GestorEmpleados)
-bajaEmpleado(empleado:Empleado, gestorEmpleados:GestorEmpleados)
-altaProducto(producto:Producto, gestorProductos:GestorProductos)
-bajaProducto(producto:Producto, gestorProductos:GestorProductos)
-registrarMerma(id_producto: entero, cantidad: entero)
-obtenerMerma(id_producto: entero) entero

1.13 Clase GestorEmpleados:

Propiedades:
-empleados: lista de Empleados

Métodos:
-agregarEmpleado(empleado:Empleado)
-eliminarEmpleado(empleado:Empleado)

1.14 Clase GestorProductos:

Modelo de Construcción y pruebas de Software Página 9 de 33

 Propiedades:
-productos: lista de productos

Métodos:
-agregarProducto(producto:Producto)
-eliminarProducto(producto:Producto)

1.15 Clase Productos:

Propiedades:
-ID: entero
-nombre: cadena
-precio: decimal
-existencias: entero

Métodos:
-obtenerID(): entero
-obtenerNombre(): cadena
-ObtenerPrecio(): decimal
-obtenerExistencias(): enteró
-establecerPrecio(nuevo_precio: decimal)
-aumentarExistencias(cantidad: entero)
-reducirExistencias(cantidad: entero)

1.16 Clase Almacen:

Propiedades:
-nombre: cadena
-inventario: diccionario de productos(clave: id del Producto,
valor: Producto)
-mermas: diccionario de productos(clave: id del Producto,
valor: entero)

Métodos:
-obtenerNombre(): cadena
-agregarProducto(producto: Producto)
-eliminarProducto(id_producto: entero)
-obtenerProducto(id_producto: entero): Producto
-listarProductos(): lista Productos
-registrarMerma(id_producto: entero, cantidad: entero)
-obtenerMerma(id_producto: entero) entero

1.17 Clase Menu:

Propiedades:
-sandwiches: lista de sándwiches (nombre: nombre del
sandwich, precio: sandwich)
-categorías: lista de cadenas

Modelo de Construcción y pruebas de Software Página 10 de 33

 Métodos:
-agregarSandwich(sandwich: Sandwich, categoría: cadena)
-eliminarSandwich(nombre_Sandwich:Sandwich)
-obtenerSandwich(nombre_Sandwich:Sandwich): Sandwich
-listarSandwich(): lista de cadenas
-listarSandwichesCategoria(categoria: cadena): lista de cadenas

1.18 Clase Reportes:

Métodos:
-generarReporteInventario(menu: Menu): cadena
-generarReporteVentas(ventas: lista de ventas): cadena
-generarReporteClientes(clientes: lista de clientes): cadena

1.19 Clase Pedido:

Propiedades:
-no_pedido: entero
-productos: lista de productos
-cliente: Cliente
-fecha_hora: fecha y hora
-estado: cadena

Métodos:
-agregarProducto(producto: Producto)
-eliminarProducto(producto: Producto)
-obtenerTotal(): decimal
-cambiarEstado(nuevo_estado: cadena)

4. Diseño de Subsistemas
1.9. Subsistemas Específicos
1.1.5. [Gestión de ventas y Pedidos]
Propósito:
- Este subsistema se crea para manejar toda la lógica que relaciona la
creación y administración de ventas y pedidos para la sandwichera.
Función:
● Módulo de punto de venta (POS)
○ Como entrada recibe el pedido a realizar y la salida es la
cantidad de insumos existentes.
○ Se encarga también de ingresar o regresar (en caso de que ya
exista en la bd) el cliente que se está atendiendo.
○ Gestión de caja, como entrada es la cantidad de dinero de
dinero que ingresa y egresa de la caja registradora.
○

Subordinados:

Modelo de Construcción y pruebas de Software Página 11 de 33

 Dependencias:

GestionAlmacenMenu()
Subsistema del Naturaleza de Características
que depende interacción
Gestión de Virtual a la base de datos Se recibe la cantidad de
inventario y insumos seleccionada y
productos regresa la cantidad que
hay en stock.

PagosMenu()
Subsistema del Naturaleza de Características
que depende interacción
Gestión de ventas y Consumo de API Muestra y selecciona la
pedidos forma de pago en caso de
que sea con tarjeta

Recursos:
● Servidor
○ Este equipo se debe adquirir antes de desplegar el sistema en
el negocio, con las características anteriormente mencionadas
y el tiempo de uso será permanente por el tiempo que
funcionen sus componentes internos.
● IPS
○ También se debe concretar el contrato con el proveedor de
servicio de internet antes del despliegue para poder realizar

Modelo de Construcción y pruebas de Software Página 12 de 33

 las pruebas necesarias y verificar que todo trabaje
correctamente, tiempo de uso indefinido.
● Switch
○ Este equipo se debe adquirir conforme se vaya suministrando
las máquinas que irán conectadas al servidor para usar el
sistema, el tiempo de uso será permanente por el tiempo que
funcionen sus componentes internos.
● Equipo punto de venta (mostrador):
○ Este equipo debe adquirirse antes de la inauguración de la
tienda física para que pueda hacer uso del sistema, el tiempo
de uso será permanente por el tiempo que funcionen sus
componentes internos.
● Equipo punto de venta (movil):
○ Este equipo debe adquirirse antes de la inauguración de la
tienda física para que pueda hacer uso del sistema, también
depende si la tienda estará equipada para poder tomar
pedidos a clientes que no tengan que ingresar al
establecimiento, el tiempo de uso será permanente por el
tiempo que funcionen sus componentes internos.
● Terminal Pago con tarjeta:
○ Este equipo debe debe de adquirirse al momento de cerrar el
convenio con el banco que estará a cargo de todas las
transacciones del negocio, el cuál también estará conectado al
sistema y el tiempo de uso será permanente por el tiempo que
funcionen sus componentes internos.

Interfases:

Interacción Método de Reglas de la

interacción interacción

ExistenciasInventario() Relacional Recibe como parámetro

la cantidad seleccionada
para preparar un pedido
y devuelve la cantidad
de insumos en stock,
dando como error
cuando la cantidad en
stock marque “cero”.
MetodosPago() Consumo de API Se hace un request para
OpenPay verificar que el sistema
esté en línea y
funcionando, a partir de
ahí se selecciona el
método de pago con
tarjeta (débito o crédito)

Modelo de Construcción y pruebas de Software Página 13 de 33

 y regresa el tipo de
transacción hecha.

1.1.6 [Gestión de inventarios y productos]

Propósito:
- El propósito de este subsistema es encargarse de la gestión de
inventario y productos disponibles así como de proveedores para la
sandwichería.
Función:
● Módulo de inventario:
○ Se encarga de almacenar y administrar todos los insumos
relacionados con los productos que ofrece la sandwichería.
● Módulo de proveedores:
○ Se encarga de gestionar la relación con los proveedores.,
registrando todo lo relacionado al producto que proveen,
ejemplo: nombre, dirección, costo, cantidad surtida, etc.

Subordinados:

Dependencias:

Modelo de Construcción y pruebas de Software Página 14 de 33

 ProveedorRegistro()
Subsistema del Naturaleza de Características
que depende interacción
Gestión de Virtual a la base de datos Se debe corroborar que el
inventario y proveedor no exista ya en
productos la base de datos y que no
tenga conflictos con las
categorías de los
productos

Recursos:

● Servidor
○ Este equipo se debe adquirir antes de desplegar el sistema en
el negocio, con las características anteriormente mencionadas
y el tiempo de uso será permanente por el tiempo que
funcionen sus componentes internos.
● Switch
○ Este equipo se debe adquirir conforme se vaya suministrando
las máquinas que irán conectadas al servidor para usar el
sistema, el tiempo de uso será permanente por el tiempo que
funcionen sus componentes internos.
● Equipo de gerencia:
○ Este equipo debe adquirirse al momento de contratar al
encargado del establecimiento para que pueda gestionar la
administración del mismo, el tiempo de uso será permanente
por el tiempo que funcionen sus componentes internos.
● Equipo almacén:
○ Este equipo debe adquirirse antes de la inauguración de la
tienda física para que pueda hacer uso del sistema, el tiempo
de uso será permanente por el tiempo que funcionen sus
componentes internos.
● Escáner:
○ Este equipo debe adquirirse antes de la inauguración de la
tienda física para que pueda hacer uso del sistema, el tiempo
de uso será permanente por el tiempo que funcionen sus
componentes internos.

Interfases:

Interacción Método de Reglas de la

interacción interacción

CategoriaProductos() Relacional Recibe como parámetros

DisponibilidadProductos()
toda la información del
los productos que están
ingresando al almacén,
como resultado modifica
la cantidad de existencia
de los mismo
Relacional Le indica al punto de
venta la cantidad exacta

Modelo de Construcción y pruebas de Software Página 15 de 33

 del insumo necesario
para preparar el pedido,
en caso de que no
encuentre existencias
manda un mensaje de
error al punto
inhabilitando de
momento la opción de
seleccionar ese insumo
hasta el momento que
sea resurtido.
ProveedorRegistro() Relacional Debe corroborar el
estado del proveedor en
la BD, en caso de que no
exista, solicita toda la
información relacionada
a este para poder
almacenarlo y
posteriormente asignarle
su respectiva categoría,
si ya existe el proveedor
pasa de largo de esta
interfaz.

5. Revisión de la Interfaz de Usuario

Aquí, se traducen los requisitos y las pautas de interfaz de usuario en un diseño
concreto que sea coherente con el entorno tecnológico definido y que cumpla
con las necesidades del usuario final.

Este proceso implica varios pasos:

1. Análisis de Requisitos y Pautas de Interfaz de Usuario: Se revisan los

requisitos del sistema y cualquier pauta o directriz de diseño de interfaz
de usuario que se deba seguir.
2. Diseño Detallado: Se comienza a diseñar la interfaz de usuario en
detalle, teniendo en cuenta los requisitos y las pautas. Esto incluye la
creación de esquemas de diseño, mockups o wireframes, y la definición
de los elementos de la interfaz de usuario, como botones, campos de
entrada, menús desplegables, etc.
3. Navegación entre Ventanas: Se diseña la navegación entre las diferentes
pantallas o ventanas de la aplicación, asegurándose de que sea intuitiva
y fácil de entender para el usuario.
4. Gestión de Eventos: Se define cómo se gestionarán los eventos
relacionados con los objetos de la interfaz de usuario. Por ejemplo, qué
sucede cuando un usuario hace clic en un botón o introduce datos en un
campo de texto.

Modelo de Construcción y pruebas de Software Página 16 de 33

 5. Validación por parte del Usuario: En casos donde se realicen
modificaciones significativas en la interfaz de usuario, es importante
validarla con usuarios reales para asegurarse de que cumple con sus
necesidades y expectativas. Esto puede hacerse a través de pruebas de
usabilidad o grupos de enfoque.
6. Opcional: Prototipado: Si se ha realizado un prototipo de la interfaz de
usuario antes, este puede servir como punto de partida para el diseño
detallado. Sin embargo, si se realizan cambios significativos, puede ser
necesario crear un nuevo prototipo.

1.10. Formatos individuales de interfaz de pantalla

2. Transaction Screen (Pantalla de Transacción):
2.1. Formato General: La pantalla de transacción suele tener un diseño
dividido en secciones claramente definidas para mostrar
información relacionada con la transacción en curso.
2.2. Elementos Comunes: Puede incluir campos de entrada para datos
relevantes, botones de acción para realizar operaciones como
guardar, cancelar o enviar, así como áreas para mostrar mensajes
de estado o errores.
3. WorkPanel (Panel de Trabajo):
3.1. Formato General: El panel de trabajo es una pantalla que
proporciona un espacio amplio y flexible para que los usuarios
realicen tareas complejas o múltiples.
3.2. Elementos Comunes: Puede contener varias secciones o pestañas
para organizar diferentes aspectos de la tarea, herramientas de
navegación para acceder a funciones específicas, y áreas para
mostrar resultados o información relevante.
4. WebPanel (Panel Web):
4.1. Formato General: El panel web es una pantalla diseñada para ser
utilizada en un entorno web, por lo que suele seguir las
convenciones de diseño web y ser responsiva.
4.2. Elementos Comunes: Puede incluir encabezados con menús de
navegación, áreas de contenido dinámico que se actualizan sin
recargar la página, y elementos interactivos como botones y
formularios.
5. Pantallas Importantes del Sistema:
5.1. Formato General: Las pantallas más importantes del sistema
suelen tener un diseño cuidadosamente estructurado y centrado en
las funciones clave del sistema.
5.2. Elementos Comunes: Dependiendo de la función de la pantalla,
puede incluir elementos como gráficos, tablas de datos, controles
de filtro y opciones de configuración.

En el caso de pantallas de tipo Transaction, WorkPanel y WebPanel, los

formatos generales suelen incluir los siguientes elementos:

Modelo de Construcción y pruebas de Software Página 17 de 33

 1. Encabezado: Este elemento suele contener el nombre de la pantalla o
transacción, así como otros elementos como botones de ayuda, menús
de opciones y/o indicadores de estado.
2. Barra de menús o navegación: En algunas aplicaciones, se incluye
una barra de menús o navegación que permite al usuario acceder a
diferentes secciones o funcionalidades del sistema.
3. Área de contenido: Este es el espacio principal de la pantalla, donde se
muestra la información relevante para el usuario. En el caso de pantallas
de tipo Transaction, esta área suele contener formularios o campos de
entrada de datos. En el caso de pantallas de tipo WorkPanel o
WebPanel, esta área suele contener listados, tablas o gráficos con
información relevante.
4. Pie de página: En algunas aplicaciones, se incluye un pie de página
que contiene información adicional como copyright, versión del sistema,
enlaces a términos y condiciones, etc.

En el caso de pantallas más importantes del sistema, es recomendable seguir

los siguientes formatos generales:

1. Pantallas de inicio: Estas pantallas deben ser atractivas y fáciles de

entender, con un diseño limpio y una navegación intuitiva. Deben incluir
elementos como un logo, un menú de navegación y un área de
contenido principal que destaque la información más relevante.
2. Pantallas de registro y acceso: Estas pantallas deben ser sencillas y
fáciles de usar, con un diseño claro y conciso que guíe al usuario a
través del proceso de registro o acceso. Deben incluir campos de
entrada de datos como nombre de usuario, contraseña y correo
electrónico, así como botones para enviar y cancelar.
3. Pantallas de perfil: Estas pantallas deben permitir al usuario ver y
editar su información personal, como nombre, correo electrónico,
contraseña y preferencias. Deben incluir campos de entrada de datos y
botones para guardar y cancelar los cambios.
4. Pantallas de búsqueda: Estas pantallas deben permitir al usuario
buscar información específica dentro del sistema, con campos de
entrada de datos como palabras clave, filtros y opciones de ordenación.
Deben incluir botones para iniciar la búsqueda y mostrar los resultados.
5. Pantallas de resultados: Estas pantallas deben mostrar los resultados
de una búsqueda o consulta, con una lista o tabla de elementos que
cumplan con los criterios de búsqueda. Deben incluir opciones de
ordenación, filtrado y paginación, así como botones para acceder a los
detalles de cada elemento.

5.3. Controles y elementos de diseño de interfaz de pantalla

6. Características de los Controles y Elementos de Diseño:

Modelo de Construcción y pruebas de Software Página 18 de 33

 Botones: Permiten a los usuarios realizar acciones específicas.
Pueden tener etiquetas descriptivas y/o iconos para indicar su
función. Las características incluyen tamaño adecuado para
facilitar su selección, retroalimentación visual para indicar el
estado activo o desactivado, y consistencia en el estilo para
mantener la coherencia visual.

Campos de Entrada: Permiten a los usuarios ingresar datos. Deben

ser lo suficientemente grandes para mostrar la información
ingresada y deben incluir etiquetas descriptivas para indicar qué
tipo de información se espera. Pueden incluir validaciones para
asegurar la entrada de datos correcta.

Menús Desplegables: Proporcionan opciones seleccionables en

una lista desplegable. Deben tener una etiqueta clara que indique
su propósito y mostrar todas las opciones disponibles de manera
clara y concisa.

Casillas de Verificación y Botones de Radio: Permiten a los

usuarios seleccionar opciones de una lista. Deben ser fáciles de
identificar y seleccionar, y proporcionar retroalimentación visual
clara cuando se seleccionan.

Íconos: Proporcionan una representación visual de funciones o

acciones. Deben ser reconocibles y representativos de su función, y
deben utilizarse de manera coherente en todo el sistema.

7. Disposición de los Controles y Elementos de Diseño:

Los controles deben estar organizados de manera lógica y

coherente para facilitar la comprensión y la navegación del usuario.

Se pueden agrupar elementos relacionados visualmente, utilizando

espacios en blanco, líneas divisorias u otros elementos de diseño
para separar secciones.

La disposición debe seguir las convenciones de diseño

establecidas y tener en cuenta la jerarquía visual para resaltar la
importancia relativa de los elementos.

8. Gestión de Eventos Relacionados con los Controles:

Cada control debe tener asociada una acción específica que se

activa cuando se interactúa con él.

Se deben manejar eventos como clics, cambios de estado (por

ejemplo, activado/desactivado) y entradas de teclado de manera

Modelo de Construcción y pruebas de Software Página 19 de 33

 adecuada para garantizar una experiencia de usuario fluida y
coherente.

Se pueden utilizar técnicas como la validación de datos en tiempo

real y la retroalimentación visual para mejorar la interacción del
usuario y proporcionar una experiencia más intuitiva.

8.1. Forma de navegación de interfaz de pantalla

Navegación Lineal: Este enfoque implica que los usuarios avancen

de una pantalla a la siguiente de manera secuencial, siguiendo un
flujo predefinido. Por ejemplo, en un proceso de registro, el usuario
podría avanzar de una pantalla a otra ingresando información paso
a paso.

Navegación por Menús: Se utiliza un menú principal o menús

secundarios para permitir a los usuarios acceder a diferentes
secciones o funciones de la aplicación. Esto puede ser útil en
aplicaciones con múltiples características o secciones

8.2. Formatos de impresión

9. Formatos de Impresión:

Formato de Papel: Este es el formato más común y básico, donde

la información se imprime en papel físico. Puede incluir diferentes
tamaños de papel según las necesidades del usuario.

Formato PDF: La salida se genera en formato PDF, lo que permite la

distribución electrónica de los documentos y asegura una
visualización consistente en diferentes dispositivos y plataformas.

Formato de Archivo de Texto: La información se genera en un

archivo de texto simple, que puede ser abierto y editado fácilmente
en diferentes aplicaciones.

Formato de Archivo CSV (Valores Separados por Comas): Este

formato es útil para la exportación de datos tabulares que pueden
ser abiertos y editados en hojas de cálculo como Excel.

10. Formato General para cada Tipo de Objeto que se Imprime:

10.1. Reporte (Report):

Encabezado: Incluye el título del reporte y cualquier

información relevante como la fecha de generación, el autor,
etc.

Modelo de Construcción y pruebas de Software Página 20 de 33

 Cuerpo del Reporte: Contiene la información detallada que
se quiere comunicar, organizada en secciones lógicas y
claramente etiquetadas.

Pie de Página: Puede incluir información adicional como

notas, referencias, o un número de página.

Estilo Visual: Debe ser claro y fácil de leer, con un diseño

limpio y profesional. Se pueden utilizar gráficos o tablas
para resumir datos complejos.

10.2. Procedimiento (Procedure):

Título o Nombre del Procedimiento: Identifica claramente el

procedimiento que se está documentando.

Descripción del Procedimiento: Explica paso a paso cómo

llevar a cabo el procedimiento, con instrucciones claras y
concisas.

Pasos Numerados o Enumerados: Organiza el

procedimiento en una secuencia lógica de pasos que deben
seguirse para completar la tarea.

Notas o Advertencias: Pueden incluirse para resaltar puntos

importantes o advertencias sobre posibles problemas o
riesgos.

Estilo Visual: Debe ser claro y fácil de seguir, con una

estructura lógica y consistente.

10.3. Listados Importantes del Sistema:

Encabezado: Puede incluir el título del listado y cualquier

información relevante sobre el contenido.

Cuerpo del Listado: Contiene la lista de elementos,

organizados de manera clara y fácil de entender.

Formato de Presentación: Puede variar dependiendo del

tipo de lista (por ejemplo, lista de clientes, productos,
transacciones, etc.). Se pueden incluir columnas con
información detallada y filtros para facilitar la búsqueda.

Pie de Página: Puede incluir información adicional como

totales, resúmenes o notas.

Modelo de Construcción y pruebas de Software Página 21 de 33

 Estilo Visual: Debe ser limpio y fácil de leer, con un diseño
que facilite la identificación y navegación de la información.

6. Diseño de Datos
El sistema hace uso de “listas enlazadas” y “arreglos” para llevar un
maneja controlado y eficaz del flujo de datos constante que emplea el
sistema, con ellos garantizamos que exista una fácil manipulación y acceso a
la información, minimizando el tiempo de búsqueda y maximizando la
eficiencia en el procesamiento de datos. También nos apoyaremos en el uso
de “diccionarios” para almacenar información adicional necesaria para el
funcionamiento del sistema, como puede ser el inventariado de ingredientes,
precios de los productos, etc.
También se tienen que mencionar las particularidades tecnológicas, como
pueden ser las integraciones adicionales, que se conforman por la integración
de OPENPAY, para poder realizar los cobros por tarjeta.
En cuanto a la base de datos que maneja el sistema, esta tiene sus bases en
MySQL, la cual véase la simpleza en la elaboración de los sandwiches, realiza
el aumento y decremento de los datos, conforme son especificados en las
funciones de los métodos, presentes en los objetos del sistema.
Por último debemos mencionar, el POS de tipo restaurante que es en el cual
se sostiene nuestro software, con el podemos agilizar mucho el proceso del
manejo de datos.
10.4. Modelo de Datos del Núcleo
Pese a que se necesita de la participación de todos los elementos
presententes en el software, para su correcto funcionamiento, es no es
impedimento para identificar aquellos, que sostienen al software, los cuales
no son dependientes principales, de otro elemento, si no, complementados,
estos son:
Empleado:
Datos: ID, Nombre, Dirección, Salario, Usuario, Contraseña, Antigüedad,
Usuario, Status, Tiempo de Uso.
Cliente:
Datos: ID, Pago, Método Pago.
Pedido:
Datos: Número Pedido, Productos, Cliente, Fecha_Hora, Estado.
Sandwich:
Datos: Nombre, Ingredientes, Precio Total, Existencias.
Almacén:
Datos: Nombre, Inventario, Mermas.
Reportes:
Datos: Reporte Datos Inventario, Reporte Datos Empleados, Reporte Datos
Ventas.

Modelo de Construcción y pruebas de Software Página 22 de 33

 10.5. Modelo de Datos General
En este apartado tenemos a los datos complementarios, los cuales sirven de
soporte, para los datos del núcleo, gracias a los complementarios podemos
manipular y manejar la información principal de forma eficiente, para que asi
nuestro software funcione correctamente. Estos son:
Menú:
Datos: Sandwiches (lista de Sándwiches), Categorías.
Gestor Empleados:
Datos: Empleados (lista de Empleados)
Gerente:
Datos: ID, Nombre, Dirección, Salario, Usuario, Contraseña, Antigüedad,
Usuario, Status, Tiempo de Uso.
Ingrediente:
Datos: Nombre, Precio, Existencias.
Gestor Productos:
Datos: Productos (lista de Productos)
Productos:
Datos: ID, Nombre, Precio, Existencias.

10.6. Especificación de la Distribución de Datos

Se hará uso de un Punto de Venta (POS) para gestionar las transacciones y el
flujo de información en el restaurante. El “POS” actuará como el punto
central donde se registran los pedidos, se procesan los pagos y se actualiza el
inventario de productos.
El “POS” estará ubicado en el mostrador del restaurante para facilitar el
acceso al personal y a los clientes. Estará equipado con hardware
especializado, como lo pueden ser una impresora de recibos, una terminal de
tarjetas, con ellas agilizaremos el proceso de toma de pedidos y el cobro de
los mismos.

Modelo de Construcción y pruebas de Software Página 23 de 33

 En términos de distribución de datos, el “POS” estará conectado a una base
de datos centralizada que almacenará la información de los pedidos, los
clientes, los productos, reportes y otros datos relevantes para el
funcionamiento del sistema de gestión de sándwiches. Esta base de datos
estará alojada en un servidor seguro en las instalaciones del restaurante o en
la nube, dependiendo de las necesidades del negocio, pero se prevé que sea
un almacenamiento local.
El POS se comunicará de manera bidireccional con la base de datos central,
enviando información sobre los pedidos realizados, los productos vendidos y
los pagos procesados, y recibiendo actualizaciones sobre el estado de los
pedidos, el inventario de productos y otras informaciones relevantes para la
operación del restaurante.
El Arquitecto trabajará en conjunto con el Especialista Técnico para configurar,
mantener el POS y la base de datos central, garantizando que se cumplan los
requisitos de rendimiento, seguridad y escalabilidad del sistema de gestión de
sándwiches. Juntos, diseñarán una infraestructura tecnológica sólida y
confiable que respalde las operaciones del restaurante y proporcione una
experiencia óptima tanto para el personal como para los clientes.
Sin mencionar las operaciones de mantenimiento del sistema, véase los
respaldos semanales, realizadas a la base de datos, donde la información
respaldada, sera almacenada tanto por el restaurante como por el equipo de
desarrollo. De la misma manera las operaciones de mantenimiento de los
datos incluyen la limpieza de archivos basura y optimizaciones en el
funcionamiento del sistema. De esta forma se garantiza que el sistema opere
de manera adecuada.

7. PLAN DE PRUEBAS DE SOFTWARE

Resumen ejecutivo
Este plan de pruebas de software se enfoca en garantizar que Odoo versión 17
cumple con las necesidades operativas de una sandwichería, haciendo especial
énfasis en el módulo de Punto de Venta (POS) junto con las funcionalidades de
ventas, inventario y compras.

Alcance de las pruebas

Módulos de Punto de Venta, ventas, inventario y compras.

Nuevas Funcionalidades a Probar:

Elementos de pruebas

Nuevas funcionalidades a probar

- Control de inventario actualizado en tiempo real desde el POS.

Modelo de Construcción y pruebas de Software Página 24 de 33

 - Integración del Punto de Venta con dispositivos móviles para la toma de
órdenes.

Pruebas de regresión
- Procesamiento de transacciones y descuentos en el POS.
- Actualizaciones de inventario tras cada venta.

Funcionalidades a no probar
- Módulos específicos para industrias no relacionadas como
manufactura o construcción, asumiendo que no se aplican en la
operación de una sandwichería.
- Riesgos asumidos por no probar estos módulos incluyen la falta
de funcionalidades no esenciales para el negocio.

Enfoque de pruebas (estrategia)

- Pruebas funcionales centradas en la interacción entre el POS y los

otros módulos para asegurar una experiencia de usuario fluida y
eficiente.
- Pruebas de desempeño para evaluar la estabilidad y rapidez del
POS, especialmente durante horas de alta demanda.
- Configuraciones a probar incluyen diferentes escenarios de venta
y tipos de pago.

Criterios de aceptación o rechazo

- Todas las pruebas unitarias deben ser completadas con éxito.
- Un mínimo del 95% de los casos de prueba deben resultar
exitosos para considerar el sistema como estable.
- Cobertura completa de todas las funciones críticas del POS y
módulos relacionados.

Criterios de suspensión
- Las pruebas se suspenderán si más del 20% de los casos de
prueba fallan, indicando problemas sistemáticos.
-

Criterios de reanudación
- La reanudación de las pruebas dependerá de la resolución de
estos problemas y de una revisión exitosa de los cambios
implementados.

Modelo de Construcción y pruebas de Software Página 25 de 33

Entregables
- Documentación completa del plan de pruebas.
- Casos de prueba específicos y diseño de estos.
- Registros de errores y reportes de incidencias.
- Evidencias de las pruebas realizadas

Recursos

- Requerimientos de Entornos – Hardware: Equipos para POS,

servidores de aplicación, estaciones de trabajo para testers.
- Requerimientos de Entornos – Software: Instalación de Odoo 17
con módulo de POS, acceso a entornos de prueba, bases de
datos.
- Herramientas de Pruebas Requeridas: Herramientas de
automatización adaptadas al entorno de POS.

Requerimientos de entornos – Hardware

​ Servidores de Aplicación:
- Servidor dedicado para la instancia de Odoo, que puede ser
tanto en local como en la nube. Se recomienda un servidor
con al menos 16 GB de RAM y un procesador de 4 núcleos
para soportar múltiples sesiones simultáneas y
operaciones de back-end en tiempo real.
​ Bases de Datos:

Servidor de base de datos separado con PostgreSQL, optimizado

para altas transacciones y consultas rápidas. Se sugiere un
servidor con al menos 16 GB de RAM y almacenamiento SSD para
mejorar el rendimiento de las operaciones de base de datos.

​ Equipos de PC para los Testers:

PCs o laptops con al menos 8 GB de RAM, procesador Intel i5 o

superior, y espacio suficiente en disco duro para instalar todas las
herramientas necesarias. Es importante que estos equipos operen
bajo sistemas operativos actualizados y estables como Windows
10 o una distribución reciente de Linux.

​ Conectividad a la Red:
- Conexión a internet de alta velocidad (al menos 100 Mbps
de bajada) para garantizar la conectividad con servidores
en la nube y facilitar el acceso remoto seguro a los
entornos de prueba.

Modelo de Construcción y pruebas de Software Página 26 de 33

 - Red local confiable y segura, con configuraciones de
firewall adecuadas para proteger los datos sensibles y
soportar el tráfico interno necesario para las pruebas.
​ Dispositivos de Punto de Venta:
- Terminales de POS que incluyan pantallas táctiles,
impresoras de recibos, lectores de tarjetas y cajones de
dinero. Estos dispositivos deben ser compatibles con el
software de Odoo y capaces de integrarse de manera
efectiva con el sistema central.

Requerimientos de entornos – Software

​ Sistemas Operativos:
- Ubuntu 20.04 LTS o superior en las máquinas de los testers
y en los servidores de aplicación y base de datos. Esta
versión de Ubuntu ofrece un entorno estable y seguro, con
actualizaciones a largo plazo que garantizan la
compatibilidad y el rendimiento.
​ Odoo 17:
- Instalación de la última versión de Odoo 17 con todos los
módulos necesarios habilitados, incluyendo el Punto de
Venta, Ventas, Inventario y Compras.
​ Base de Datos:
- PostgreSQL como sistema de gestión de base de datos,
con la última versión estable para garantizar la
compatibilidad y el rendimiento óptimo.
​ Herramientas de Pruebas:
- Software de automatización de pruebas como Selenium,
QTP, o herramientas específicas para Odoo si están
disponibles.
- Herramientas para la gestión de pruebas, como TestRail o
JIRA, para organizar y seguir el progreso de las pruebas.
​ Accesos a Sistemas en Entorno de Pruebas:
- Acceso configurado para los entornos de prueba
separados de la producción, con credenciales seguras para
los testers.

Herramientas de pruebas requeridas

Gestión de Configuraciones y Versiones:
- Git/GitHub: Para control de versiones y gestión de código fuente.
Facilita el seguimiento de cambios, colaboración entre
desarrolladores y testers, y respaldo del trabajo realizado

Modelo de Construcción y pruebas de Software Página 27 de 33

Personal

​ Líder de Pruebas (1)

- Rol: Coordinar y supervisar todas las actividades de
pruebas. Responsable de la planificación, ejecución y
revisión de los resultados de las pruebas, además de la
comunicación con el equipo de desarrollo y la gestión del
equipo de pruebas.
​ Analistas de Pruebas (5)
- Rol: Ejecutar pruebas manuales según los casos de prueba
definidos, documentar los resultados de las pruebas,
identificar defectos y colaborar estrechamente con
desarrolladores para su resolución.
​ Especialistas en Automatización de Pruebas (2)
- Rol: Diseñar, desarrollar y mantener scripts de
automatización. Estos especialistas trabajarán
principalmente con herramientas como Odoo Robot
Framework y Selenium para asegurar que las pruebas
repetitivas se automatizan, lo que aumenta la eficiencia del
proceso de pruebas.
​ Ingeniero de Pruebas de Rendimiento (1)
- Rol: Especializado en pruebas de carga y rendimiento
utilizando herramientas como JMeter. Esencial para
asegurar que el sistema pueda manejar la demanda
operativa en condiciones de alto tráfico, especialmente
relevante para el módulo de Punto de Venta.
​ Analista de Seguridad (1)
- Rol: Realizar pruebas de seguridad para identificar
vulnerabilidades dentro del sistema utilizando herramientas
como OWASP ZAP. Este rol es crucial para proteger datos
sensibles de clientes y transacciones financieras.

Entrenamiento

​ Entrenamiento en Odoo 17 y Módulos Específicos

- Objetivo: Comprender a fondo la funcionalidad y las
características de Odoo 17, con un enfoque especial en el
módulo de Punto de Venta y otros módulos relevantes.

Duración: 2 semanas (inicial).

​ Entrenamiento en Herramientas de Automatización

Objetivo: Capacitación en Odoo Robot Framework y Selenium para

los especialistas en automatización, asegurando que puedan
escribir y mantener scripts de pruebas efectivamente.

Modelo de Construcción y pruebas de Software Página 28 de 33

 Duración: 1 semana.

​ Entrenamiento en Pruebas de Rendimiento y Seguridad

Objetivo: Formación en JMeter para pruebas de rendimiento y

OWASP ZAP para pruebas de seguridad, dirigido a los ingenieros
de rendimiento y analistas de seguridad.

Duración: 1 semana para cada tipo de entrenamiento.

​ Sesiones Continuas de Actualización y Mejora

- Objetivo: Sesiones periódicas para mantener al equipo
actualizado sobre las últimas prácticas, herramientas y
actualizaciones en el campo de pruebas de software.
- Frecuencia: Trimestral o según necesidad.

Planificación y organización

Procedimientos para las pruebas

Para garantizar una ejecución eficiente y sistemática de las pruebas en el
entorno de Odoo versión 17 utilizado en una sandwichería, es fundamental
seguir una metodología estructurada de pruebas.

Matriz de responsabilidades

​ Preparación de Pruebas:
● Definición de Alcance: Determinar las áreas del sistema que serán
objeto de pruebas, incluyendo nuevas funcionalidades y pruebas
de regresión.
● Planificación de Recursos: Asignar los recursos necesarios, tanto
humanos como técnicos.
● Desarrollo de Casos de Prueba: Crear detallados casos de prueba
basados en los requisitos funcionales y no funcionales del
sistema.
● Configuración del Entorno de Pruebas: Establecer y configurar el
entorno de pruebas para simular condiciones reales de operación
con datos de prueba adecuados.
​ Ejecución de Pruebas:
● Realización de Pruebas Manuales y Automatizadas: Ejecutar los
casos de prueba manualmente y mediante scripts automatizados
para maximizar la cobertura y eficiencia.
● Monitorización y Registro: Supervisar el proceso de pruebas,
registrar los resultados de las pruebas y documentar los
problemas encontrados.

Modelo de Construcción y pruebas de Software Página 29 de 33

 ● Análisis de Resultados: Evaluar los resultados de las pruebas para
determinar la calidad del software y identificar áreas de mejora.
​ Gestión de Defectos:
● Registro de Defectos: Utilizar una herramienta de seguimiento de
defectos para registrar y gestionar los problemas identificados.
● Priorización y Asignación: Priorizar los defectos según su
gravedad y asignarlos para corrección.
● Verificación de Correcciones: Revisar las correcciones
implementadas y realizar pruebas de regresión para asegurar que
no se introduzcan nuevos problemas.
​ Revisión y Reporte:
● Revisión de Pruebas: Llevar a cabo reuniones de revisión para
evaluar el progreso de las pruebas y ajustar el plan según sea
necesario.
● Reporte de Estado: Preparar informes de estado regulares que
resuman los avances, problemas pendientes y métricas de
pruebas.
- Evaluación de Calidad: Determinar si el software cumple
con los criterios de aceptación establecidos y está listo
para el despliegue.
​ Finalización:
- Documentación Final: Compilar toda la documentación
relacionada con las pruebas, incluyendo resultados,
problemas detectados y no resueltos, y lecciones
aprendidas.
- Retrospectiva del Proyecto: Realizar una sesión
retrospectiva con el equipo para discutir lo que funcionó
bien y lo que podría mejorarse en futuros proyectos de
pruebas.
​ Metodologías de Pruebas Utilizadas:
- Pruebas Ágiles: Implementar un enfoque ágil para las
pruebas, integrando pruebas continuas en el ciclo de
desarrollo para permitir ajustes rápidos y mejora continua.
- TDD (Test Driven Development): Utilizar desarrollo guiado
por pruebas para asegurar que todas las nuevas
funcionalidades sean probadas completamente desde el
principio.
- BDD (Behavior Driven Development): Aplicar desarrollo
guiado por comportamiento para facilitar la comunicación
entre desarrolladores, testers y stakeholders, y asegurar
que el sistema cumple con las expectativas del negocio.

Modelo de Construcción y pruebas de Software Página 30 de 33

Cronograma (Gantt)

Premisas
​ Metodología de Pruebas:
● Se seguirá una metodología ágil para las pruebas de software,
permitiendo iteraciones rápidas y flexibilidad en la adaptación a
cambios.
​ Disponibilidad de Recursos:
● Se asume que el equipo de pruebas tendrá acceso a los recursos
necesarios, incluyendo hardware, software y personal, según lo
descrito en el plan de pruebas.
​ Uso de Herramientas de Pruebas:
● Se utilizarán las herramientas especificadas en el plan de pruebas,
incluyendo Odoo Robot Framework, Selenium WebDriver, TestRail,
JIRA, entre otras, para facilitar la ejecución y gestión de las
pruebas.
​ Colaboración con el Equipo de Desarrollo:

Modelo de Construcción y pruebas de Software Página 31 de 33

 - Se espera una estrecha colaboración entre el equipo de
pruebas y el equipo de desarrollo de software para la
identificación y resolución rápida de problemas
encontrados durante las pruebas.
​ Tiempo Estimado:
- Las estimaciones de duración de las actividades se basan
en la experiencia previa y en un entendimiento general del
proyecto, pero pueden estar sujetas a cambios a medida
que se avanza en el proceso de pruebas.
​ Cobertura de Pruebas:
- Se espera una cobertura exhaustiva de pruebas, tanto
funcionales como no funcionales, para garantizar la calidad
y fiabilidad del software en todos los aspectos relevantes
para una sandwichería.
​ Priorización de Defectos:
- Los defectos encontrados durante las pruebas serán
priorizados según su impacto en la funcionalidad y la
criticidad del sistema, con el fin de asegurar que los
problemas más importantes sean abordados primero.
​ Comunicación y Reporte:
- Se establecerá una comunicación clara y regular entre el
equipo de pruebas, el equipo de desarrollo y los
stakeholders, con informes periódicos sobre el progreso de
las pruebas y los problemas identificados.

Dependencias y Riesgos
​ Dependencias con Desarrollos:
- Probabilidad: Alta
- Impacto: Alto
- Descripción: Retrasos en el desarrollo de funcionalidades
pueden afectar el inicio oportuno de las pruebas
correspondientes.
- Plan de Mitigación/Contingencia: Establecer una
comunicación constante entre el equipo de desarrollo y
pruebas para identificar y abordar proactivamente cualquier
retraso en el desarrollo. Priorizar las pruebas en función de
la disponibilidad de funcionalidades desarrolladas.
​ Dependencias con Otros Proyectos:
- Probabilidad: Media
- Impacto: Medio
- Descripción: Interferencias o recursos compartidos entre
diferentes proyectos pueden afectar la disponibilidad de
recursos para las pruebas de software.
- Plan de Mitigación/Contingencia: Coordinar los recursos de
manera efectiva entre los diferentes proyectos para

Modelo de Construcción y pruebas de Software Página 32 de 33

 garantizar que las actividades de pruebas no se vean
afectadas negativamente. Establecer un plan de
contingencia para reasignar recursos en caso de
emergencia.
​ Disponibilidad de Recursos:
- Probabilidad: Alta
- Impacto: Alto
- Descripción: Escasez de recursos humanos o técnicos
puede retrasar o dificultar la realización de las pruebas de
software según lo planeado.
- Plan de Mitigación/Contingencia: Realizar una planificación
detallada de recursos y asegurar la disponibilidad
anticipada de los mismos. Mantener una lista de personal
alternativo y tener acuerdos con proveedores externos en
caso de necesidad.
​ Restricciones de Tiempo:
- Probabilidad: Alta
- Impacto: Alto
- Descripción: Presiones de tiempo pueden resultar en una
ejecución apresurada de las pruebas, lo que podría
comprometer la calidad del proceso de pruebas y del
software final.
- Plan de Mitigación/Contingencia: Establecer un cronograma
realista y revisarlo regularmente para ajustar las fechas
según sea necesario. Priorizar las actividades de pruebas
según su importancia y criticidad.

Referencias
● Equipo de Desarrollo (2023).Plan proyecto S.G.N.S.
Enunciado de Proyecto de Ingeniería de Software.pdf
● Equipo de Desarrollo (2023).Especificaciones de requisitos del S.G.N.S basado en
IEEE-830. formato_ieee830_Especificación de requisitos de software (1).pdf
● Equipo de Desarrollo (2023).Descripcion Arquitectura del Software S.G.N.S.
Descripcion_Arq_2.pdf .
● Equipo de Desarrollo (2023).Formato Plan Administración del Proyecto S.G.N.S
Plan_administracion_proyectos.pdf .

Modelo de Construcción y pruebas de Software Página 33 de 33