📋 Evaluación N° 1 — Sistemas de Información

Sistema de Gestión
Almacén Lukas

Análisis, Levantamiento de Requisitos y Planificación para digitalizar la gestión del crédito vecinal.

Profesor: Jorge Esteban Cornejo Elgueta
Cristian Salazar
Jefe de Proyecto
Lukas Caballero
Analista de Negocio
Felipe Oria
Analista de Requisitos
Benjamin Acuña
Diseñador de Sistemas
Simón Aros
Desarrollador Backend
01

Antecedentes del Negocio

Resumen de la empresa y su operación comercial (Presentado anteriormente).

Almacén Lukas es un negocio familiar minorista fundado en el año 2015, ubicado en la comuna de Lo Prado. Su propietario, el Sr. Claudio Caballero, atiende a la comunidad vecinal ofreciendo abarrotes y productos de limpieza.

🏪 Empresa
Almacén Lukas
👤 Cliente / Dueño
Claudio Caballero
📍 Ubicación
Lo Prado, RM
💰 Servicio Clave
Crédito Vecinal
02

Procesos del Almacén

El almacén opera con 6 procesos principales. Uno de ellos es el origen del problema.

🛒
1 · Compra a proveedores
Adquisición de abarrotes y productos de limpieza a distribuidores y mayoristas.
📦
2 · Recepción e inventario
Recepción de mercadería, almacenamiento y control de stock disponible.
🏪
3 · Venta retail
Atención directa al cliente en el local, venta al contado.
💰
4 · Crédito vecinal ← AQUÍ ESTÁ EL PROBLEMA
Venta fiada a clientes de confianza. Se registra manualmente en hojas de notas.
💬
5 · Pedidos por WhatsApp
Toma de pedidos a distancia para entrega o retiro en el local.
💵
6 · Control de caja
Gestión de pagos recibidos y conciliación diaria del efectivo.
03

¿Qué es el crédito vecinal?

El servicio diferenciador del almacén — y el que genera el problema.

El crédito vecinal —también conocido como "venta al fiado"— es un sistema de confianza donde un cliente habitual del barrio se lleva productos del almacén sin pagar en el momento. El dueño le anota la deuda, y el cliente la paga más adelante, generalmente a fin de mes.

Es una práctica histórica en los almacenes chilenos. Funciona sobre la confianza y el conocimiento personal. En Almacén Lukas, este servicio es el principal factor de fidelización frente a otros minimarkets.

🤝 Cómo funciona
El vecino lleva productos hoy y los paga cuando pueda.
📅 Cuándo se cobra
Generalmente a fin de mes (sueldo o pensión).
👥 Quiénes acceden
Solo clientes conocidos y de confianza.
📝 Cómo se registra hoy
En hojas sueltas, agendas y la memoria del dueño.
04

El problema en detalle

Lo que ocurre cada fin de mes en el almacén.

En palabras del propio dueño: "Al llegar fin de mes, debo revisar entre todas las hojas de notas y apuntes para encontrar a los clientes que no han pagado y luego ir a cobrarles por WhatsApp."

📝
Desorganización en el registro
No hay un orden claro: no se sabe de inmediato quién debe ni cuánto, provocando pérdidas.
📄
Pérdida de información
Las hojas de papel se deterioran, extravían o dañan con facilidad.
Proceso lento y manual
Cada fin de mes el dueño invierte varias horas revisando apuntes uno a uno.
👁️
Sin visibilidad del estado de cuenta
Es imposible saber rápidamente cuánto debe un cliente específico sin revisar todos los papeles.
05

Antes y después del sistema

Cómo cambia el proceso de crédito vecinal con la solución propuesta.

❌ Hoy — Sin sistema
📝El dueño anota la deuda a mano en una hoja o libreta
🗂️Las hojas se acumulan sin orden durante todo el mes
🔍Al fin de mes revisa todo manualmente buscando morosos
💬Escribe a cada moroso a mano por WhatsApp uno por uno
😰Riesgo de olvidar deudas, perder hojas o equivocar montos
Horas perdidas en un proceso que debería tomar minutos
✅ Con el sistema Local
🖥️El dueño registra el crédito en segundos en su PC
💾El sistema guarda todo automáticamente con fecha y monto
Con un clic ve la lista de morosos actualizada al instante
🤖El sistema genera la información exacta para el cobro
📊Historial completo de cada cliente: deudas y pagos
🎯El fin de mes pasa de horas de trabajo a minutos
06

Objetivo General

La meta principal que define el éxito del proyecto.

El propósito central del equipo de desarrollo se resume en una única meta concreta, enfocada en solucionar el cuello de botella del almacén:

"Desarrollar e implementar un sistema informático de gestión de morosos para el almacén Lukas en un plazo de un semestre académico, con el fin de reducir el tiempo dedicado al registro y cobro de los pedidos fiados en al menos un 80%."

07

Objetivos Específicos

Los pasos cuantificables y medibles para alcanzar la meta general.

1. Identificar los procesos actuales de gestión de crédito y los puntos críticos de pérdida de información mediante entrevistas de licitación con el cliente.
2. Modelar el flujo de procesos utilizando la notación BPMN para estandarizar el registro y cobro de deudas.
3. Estructurar una matriz de requisitos funcionales y no funcionales que garantice la seguridad, portabilidad y usabilidad del sistema.
4. Desarrollar el sistema de gestión utilizando el stack tecnológico propuesto, integrando los módulos de clientes, créditos y pagos.
5. Validar el funcionamiento del sistema y la precisión de los datos mediante pruebas de usuario y capacitación in situ al propietario.
08

Ingeniería de Requisitos

Metodología aplicada para el levantamiento de información.

El proceso de desarrollo sigue los lineamientos del Ciclo de Vida de Desarrollo de Software (CVDS) y aplica los principios definidos por Sommerville (2011).

"Los requisitos son la base sobre la cual se construye todo sistema de software exitoso. El análisis no es un proceso aislado, sino un esfuerzo continuo de comprensión, validación y negociación con los stakeholders."
— Sommerville, 2011

Para esto, el equipo llevó a cabo un proceso de elicitación de requisitos mediante entrevistas estructuradas con el Sr. Claudio Caballero, permitiendo comprender en profundidad la operación y establecer qué debe hacer el sistema (Funcionales) y cómo debe hacerlo (No Funcionales).

09

Requisitos Funcionales

Funciones específicas que el sistema debe ser capaz de ejecutar, ordenados lógicamente.

R.1 - Registrar Cliente
Actor: Propietario
Permite registrar clientes con nombre, RUT, teléfono y dirección.
R.2 - Gestionar Crédito Vecinal
Actor: Propietario
Registro de ventas a crédito con productos y fecha; actualización automática del saldo.
R.3 - Registrar Pago de Deuda
Actor: Propietario
Permite ingresar abonos parciales o totales, actualizando el saldo y el historial.
R.4 - Listar Clientes Morosos
Actor: Propietario
Genera listado actualizado de clientes con deuda mayor a $0, indicando saldo.

* Todos los requisitos se encuentran en estado APROBADO.

10

Requisitos No Funcionales

Atributos de calidad y restricciones tecnológicas para el contexto del Almacén.

🔒 RNF.1 - Seguridad
Autenticación: Acceso mediante usuario/contraseña encriptada. Bloqueo tras 3 intentos.
⚡ RNF.2 - Rendimiento
Tiempo de respuesta: Consultas < 2 s; carga inicial < 5 s; listado de morosos < 3 s.
🖥️ RNF.3 - Usabilidad
Interfaz de Escritorio: Sistema optimizado para uso en el computador del local (PC) con teclado y mouse, garantizando agilidad.
💾 RNF.4 - Confiabilidad
Respaldo de datos: Exportación manual de backup (CSV/JSON) con fecha y hora visible para seguridad ante fallos del hardware.
📂 RNF.5 - Ejecución Local
Arquitectura Local: Sistema standalone que se ejecuta íntegramente en el PC del cliente. Costo cero de hosting y operación sin dependencia de conexión a internet.
11

Análisis: El Modelo Esencial

La lógica pura del negocio sin limitaciones tecnológicas actuales.

El modelo esencial busca capturar las políticas de negocio ignorando cómo se hacen físicamente hoy. Para el Almacén Lukas, la esencia radica en gestionar el crédito vecinal de manera precisa.

El comportamiento fundamental requerido por el sistema es:

1. Registrar la deuda en el instante exacto en que el cliente solicita los productos.
2. Mantener un cálculo matemático exacto del saldo adeudado.
3. Eliminar la dependencia de la memoria humana y de los registros físicos (libretas).

12

Análisis de Flujo y Fronteras

¿Qué automatizará el sistema y qué seguirá haciendo el dueño?

El análisis BPMN evidenció que el cuello de botella (AS-IS) ocurre a fin de mes por la revisión manual de papeles. El sistema se centrará en eliminar este bloqueo definiendo fronteras claras.

🤖 Dentro del Sistema (Automatizado)
Registro centralizado y seguro de clientes (R.1)
Cálculo automático de saldos y créditos (R.2 y R.3)
Generación instantánea de lista de morosos (R.4)
👤 Fuera del Sistema (Labor Manual)
El Cobro vía WhatsApp: El sistema provee la información precisa, pero la acción de contactar al cliente desde su dispositivo la mantendrá el propietario.
13

Modelo de Implantación

Adaptando la lógica a la realidad física del mostrador del almacén.

Una vez definida la lógica (Modelo Esencial), esta debe aterrizar en la realidad tecnológica y ambiental del punto de venta, lo que dictó los Requisitos No Funcionales para un entorno de escritorio.

🖥️ Dispositivo Físico
El dueño operará desde el computador (PC) ubicado en el mostrador. Requiere una interfaz de escritorio clara y atajos de teclado para un registro rápido.
⏱️ Entorno Dinámico
Hay fila de clientes. Consultas menores a 2 segundos para no entorpecer la atención presencial de la tienda.
🔌 Mitigación de Riesgos
Para asegurar la operación continua incluso sin internet, la ejecución será 100% local, con exportaciones manuales de base de datos.
14

Conclusiones

Cierre de la fase de Análisis y Levantamiento de Requisitos.

La primera etapa formal del ciclo de vida de desarrollo ha culminado exitosamente. A través de la elicitación, se tradujo la problemática del registro manual en una arquitectura lógica eficiente.

Resultados clave:

9 Requisitos validados: 4 funcionales núcleo (clientes, crédito, pagos, listados) y 5 no funcionales orientados a una ejecución de escritorio segura y rápida.
Trazabilidad: Cada requisito funcional responde directamente a mitigar un punto crítico del flujo BPMN.
Viabilidad Económica: La decisión de una arquitectura local garantiza cero costos operativos (hosting) y evita dependencias de conexión a internet para el dueño del local.

El proyecto cuenta con una base sólida para avanzar hacia las fases de diseño de bases de datos, interfaces y desarrollo en las evaluaciones subsiguientes.

15

Referencias Bibliográficas

Marco teórico y metodológico utilizado (Normas APA 7ª edición).

Sommerville, I. (2011). Ingeniería del software (9.ª ed.). Pearson Educación.
Pressman, R. S. (2010). Ingeniería del software: Un enfoque práctico (7.ª ed.). McGraw-Hill.
Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. IEEE Computer, 20(4), 10–19.
IEEE/ANSI 830-1998. (1998). IEEE Recommended Practice for Software Requirements Specifications.
Caballero, C. (2026, abril). [Entrevistas de levantamiento de requisitos]. Almacén Lukas, Lo Prado, Santiago.

¡Fin de la Presentación!

En Almacén Lukas buscamos modernizar la gestión con base en una ingeniería de requisitos sólida, asegurando que la tecnología se adapte al negocio local y no al revés.

Siguientes Pasos (Fase 2):

• Diseño de Base de Datos Local
• Prototipado de Interfaces de Escritorio (UI/UX)
• Inicio del Desarrollo de la Aplicación Local

Estamos abiertos a preguntas y comentarios.

C. Salazar · L. Caballero · F. Oria · B. Acuña · S. Aros
1 / 17