Proyecto de Grado · Ingeniería Industrial y de Sistemas

Prototipo de aplicación web para la gestión
de información de órdenes de trabajo para
la empresa Rectificaciones Cordova

Jorge Luis Cordova Rojas

Docente guíaMgs. Heber Tito Zúñiga Morales

Contenido

Agenda de la exposición

1Introducción

2Objetivos

3Metodología

4Diagnóstico

5Casos de uso

6Análisis y diseño

7Arquitectura y tecnologías

8Demostración del sistema

9Seguridad

10Costo-beneficio

11Conclusiones

12Recomendaciones

Contexto

La empresa: Rectificaciones Cordova

Taller referente en Santa Cruz, reconocido por la calidad y precisión de su rectificación de motores y por su personal técnico calificado.

1996Fundación

30Años de trayectoria

+20 milÓrdenes de trabajo

El corazón del negocio

Una reputación construida orden a orden: cada trabajo se documenta en una orden de trabajo —cliente, motor, piezas, repuestos y trabajos ejecutados—.

Fachada de Rectificaciones Cordova — Desde 1996 · Santa Cruz

Rectificaciones Cordova es un taller con casi 30 años de trayectoria y un nombre reconocido en Santa Cruz: los clientes vuelven y llegan por recomendación gracias a la calidad y precisión de su trabajo y a su personal técnico calificado. Se dedica a recuperar las medidas y el funcionamiento original de las piezas internas del motor: block, cigüeñal, eje de leva, bielas y culatas. El corazón administrativo del negocio es la orden de trabajo, donde se registra qué cliente trae qué motor, qué piezas ingresan, qué repuestos se usan y qué trabajos se ejecutan. Pero, a medida que el taller creció, ese volumen de información se volvió difícil de manejar con métodos manuales: la calidad del trabajo en el motor no fue acompañada por la gestión de la información. (~50 s)

Planteamiento del problema

Información dispersa, control limitado

Deficiencias en la sistematización y consulta de la información de las órdenes de trabajo de la empresa.

1Procesos manuales

Papel y planillas dispersas: pérdida, duplicidad y poca trazabilidad.

2Conocimiento empírico

Todo vive en la cabeza del personal; sin repositorio digital centralizado.

3Decisiones sin datos

Sin indicadores ni reportes a la mano, planificar y decidir se hace a ciegas.

Aquí está el contraste que quiero subrayar: es una empresa reconocida por la calidad de su trabajo, pero esa misma excelencia no se refleja en cómo administra su información. Hoy la gestión de las órdenes es totalmente manual y con herramientas no integradas; funciona, pero cuesta centralizar la información y hacer un seguimiento eficiente. El problema central que aborda la tesis es concreto: las deficiencias en la sistematización y consulta de la información de las órdenes de trabajo; dicho de otra forma, hoy no existe una aplicación web que gestione esa información. Y es un problema real y cotidiano: un error al anotar a mano —o no tener la información a la mano cuando se necesita— significa retrabajo, demoras en la entrega y un cliente molesto. Detrás del problema hay tres factores: primero, los procesos manuales —papel y planillas dispersas que generan pérdida y duplicidad de datos y poca trazabilidad—; segundo, la dependencia del conocimiento empírico, que vive en la cabeza del personal y no en un repositorio digital centralizado; y tercero, la falta de información para decidir: sin indicadores ni reportes a la mano, planificar y tomar decisiones —qué priorizar, a quién contratar— se hace a ciegas. La consecuencia de todo esto se ve en la operación: retrasos, falta de indicadores confiables y menor competitividad. En un mercado cada vez más competitivo, no tener una plataforma centralizada significa perder oportunidades estratégicas. De ahí surge la necesidad de un prototipo de aplicación web que no solo digitalice el papel, sino que sea el pilar de la eficiencia y la excelencia operativa de Rectificaciones Cordova. (~55 s)

NO SE LEE EN VOZ ALTA — ejemplos por si el tribunal pide aterrizar las causas:

Procesos manuales (papel y planillas dispersas → pérdida, duplicidad y poca trazabilidad; el sistema lo reemplaza):

Transcripción repetida de datos del cliente y del motor en cada orden y en la planilla → duplicidad y errores al recopiar.
Copia física única: la orden vive en un solo bloc, en un solo lugar → no se puede consultar desde otro punto ni por dos personas a la vez; si el bloc no está a mano, nadie accede al dato.
Inconsistencia entre copias: el papel dice una cosa y el Excel otra → no hay una fuente única de verdad.
Llenado a mano ilegible o con campos incompletos → errores de interpretación y datos faltantes.
Sin rastro de cambios: el papel no registra quién modificó qué ni cuándo → ninguna trazabilidad.

Conocimiento empírico (info que existe pero vive en la cabeza/papel → dependencia de la persona; el sistema la libera):

Estado/avance de una orden: "¿en qué va el motor del cliente X?" hoy solo lo sabe el operario que lo trabaja → el sistema lo hace consultable por cualquiera.
Historial de un cliente/motor recurrente: qué se le hizo antes, qué piezas y repuestos llevó → centralizado, no en la memoria de quien lo atendió.
Detalle técnico de los trabajos y medidas hechos a una pieza → queda en la OT (trabajos ejecutados), no se pierde si el técnico no está.
Ubicar una orden antigua en el archivo físico (FILO): hoy depende de quien conoce la lógica del archivo → búsqueda directa en el sistema.
El procedimiento de gestión de la OT: hoy se transmite verbalmente al personal nuevo, sin procedimiento documentado → el flujo queda encapsulado en la herramienta.

Decisiones sin datos (no hay indicadores consolidados → a ciegas; el sistema pone el dato a la vista, NO decide):

¿Cuántas órdenes hay en proceso / pendientes / atrasadas ahora mismo? Hoy hay que contar papeles → permite priorizar qué empujar.
¿Cuánto tarda en promedio un trabajo / cuáles están demorados? → el sistema registra los estados con fecha y hora (HistorialEstadoOT).
¿Qué tipo de trabajo es el más frecuente? Volumen por tipo de pieza/proceso → dato disponible. (Cuidado: es el dato, no la decisión de contratar.)
¿Qué clientes traen más trabajo y con qué frecuencia? → identificar clientes clave.
¿Qué órdenes están terminadas y pendientes de entrega o cobro? → a qué cliente llamar para cerrar.

Objetivos

La meta y el camino

Objetivo general

Elaborar un prototipo de aplicación web de gestión de información de órdenes de trabajo para la empresa Rectificaciones Cordova

Siete objetivos específicos

1Diagnosticarla situación

2Elaborarlos requerimientos del sistema

3Analizarcon UML

4Diseñarsistema y BD

5Desarrollarel prototipo

6Evaluarseguridad

7Costo–beneficiode implementar

Metodología

ICONIX, orientada a casos de uso

Etapas de ICONIX

Metodología semi-ágil: equilibra simplicidad y estructura.
Va del caso de uso a las pruebas con trazabilidad.
Apoyada en UML: dominio, robustez y secuencia.

Capítulo III · Diagnóstico

La orden de trabajo

Anverso de una orden de trabajo física — Anverso

Reverso de una orden de trabajo física — Reverso

Este es el corazón del proceso actual: la orden de trabajo en papel. En el anverso se anota el cliente, el motor y los trabajos a realizar; en el reverso, el pedido de repuestos. Todo a mano. Como ven, la información es valiosa pero queda dispersa, difícil de leer y de consultar, y no se puede cruzar ni respaldar. Esta hoja es la evidencia del problema y el punto de partida de todo el proyecto: digitalizarla sin perder nada de lo que el personal ya registra. (~45 s)
(Truco: pulsa siguiente una vez para ampliar las fotos —el título se oculta y el fondo se atenúa, y aparecen anotaciones señalando cliente y motor y los trabajos a realizar en el anverso, y el pedido de repuestos en el reverso—; vuelve a pulsar para pasar a la siguiente diapositiva.)

Del papel al sistema

Seguimiento de trabajos realizados

Pantalla de registro de trabajos de la OT en el sistema — Registro de trabajos

Pantalla de seguimiento por operario en el sistema — Seguimiento por operario

Digitalización inicial

La orden de trabajo en Excel

La orden de trabajo gestionada en una planilla de Excel — OT en Excel

Antes de llegar al sistema, se intentó ordenar la información en Excel. Ayudó, pero seguía siendo un proceso manual: sin validaciones, difícil de consultar y propenso a errores, y sin trazabilidad real. De ahí la necesidad de una aplicación a la medida del taller. (~25 s)
(Q&A — no se lee: si dicen «pero esto ya estaba sistematizado», responder que digitalizar ≠ sistematizar: Excel es papel digital, sin validaciones, sin integridad/relaciones entre datos, sin trazabilidad, sin estados ni roles. Que lo intentaran confirma la necesidad real; tocó techo y por eso una app a la medida.)
(Truco: pulsa siguiente una vez para ampliar la captura —el título se oculta y el fondo se atenúa—; vuelve a pulsar para pasar a la siguiente diapositiva.)

Capítulo IV–V · Casos de uso

Casos de uso

Diagrama general de casos de uso

Derivados de los requisitos funcionales y no funcionales (Cap. IV).
14 casos de uso vinculados a los requisitos.
Dos actores: Gerente y Personal administrativo.
Cubren clientes, motores, OT, piezas, repuestos, trabajos, movimientos, historial, reportes y usuarios.

Nº	Caso de uso
1	Gestionar clientes
2	Gestionar motores
3	Gestionar órdenes de trabajo
4	Gestionar piezas de OT
5	Gestionar repuestos de OT
6	Gestionar trabajos ejecutados
7	Gestionar movimientos de custodia
8	Consultar órdenes de trabajo
9	Ver historial de actividades y estado
10	Visualizar reportes y dashboard
11	Gestionar usuarios
12	Gestionar catálogos
13	Iniciar sesión
14	Cerrar sesión

A partir del diagnóstico definí los requisitos funcionales y no funcionales (Cap. IV), y de ellos derivé 14 casos de uso. Este diagrama general los muestra todos, con sus dos actores: el gerente general y el personal administrativo. Los casos cubren todo el flujo del taller: gestión de clientes, motores, órdenes de trabajo, piezas, repuestos, trabajos ejecutados, movimientos de custodia, historial, reportes y la administración de usuarios. Cada caso de uso quedó trazado a un requisito. (~50 s)
(Q&A — no se lee: si piden la norma / IEEE 830, 3 frases: 1) Estructura vs. redacción: IEEE 830 gobierna la estructura de la ERS (propósito, alcance, RF/RNF, atributos de calidad, trazabilidad); "Como… quiero… para…" es la redacción (historia de usuario, coherente con ICONIX) — distintas y compatibles. 2) Derogación a favor: 830-1998 fue reemplazada por ISO/IEC/IEEE 29148 (2011); la usé como referencia académica más difundida y 29148 conserva los mismos atributos de calidad, así que mi ERS sigue compatible. 3) Trazabilidad: cada RF se mapea a un caso de uso (ID ↔ requerimiento), de ahí salen los 14 CU. Detalle completo en los anexos IEEE 830.)
(Truco: pulsa siguiente una vez para ampliar el diagrama —el título se oculta— y mostrar la tabla de los 14 casos a la derecha; vuelve a pulsar para avanzar.)

Capítulo V · Caso de uso 3

Ejemplo de caso de uso: Gestionar órdenes de trabajo

Actores

Principal: Personal administrativo · Secundario: Gerente general.

Precondiciones

Usuario autenticado · sesión vigente · cliente(s) registrados.

Postcondiciones

OT creada / actualizada / anulada · relaciones ClienteOT con rol y observación · motor vinculado sin huérfanos · piezas y repuestos por sus casos «extend» (CU4/CU5) · registro en el historial.

Reglas de negocio clave

R1 · ≥1 cliente y motor R6 · código único y secuencial R8 · no se eliminan: se anulan y quedan trazadas

Frecuencia de uso: Alto (uso diario).

Flujo normal

El usuario solicita registrar una nueva orden de trabajo.
Incorpora uno o varios clientes, con su rol y observación.
Selecciona un motor existente o registra uno nuevo en el momento.
Indica fecha de ingreso, fecha de compromiso (opcional) y observaciones.
El sistema valida obligatoriedad, consistencia y formato de los datos.
El usuario confirma el registro.
El sistema almacena la OT, le asigna código y estado Pendiente, y vincula clientes y motor.
El sistema registra la acción en el historial de actividad.

+ 8 flujos alternativos: cliente duplicado, motor nuevo durante la OT, motor duplicado, sin fecha de compromiso, validación fallida, cancelación, actualización de OT…

Puntos de extensión («extend»): Registrar piezas en OT → CU4 · Registrar repuestos en OT → CU5.

Para aterrizar lo anterior, desarrollo en detalle el caso de uso más importante del sistema: Gestionar órdenes de trabajo, que es el corazón del prototipo. El actor principal es el personal administrativo y el secundario, el gerente. Como precondiciones, el usuario debe estar autenticado y deben existir clientes registrados. El flujo normal es: el usuario solicita una nueva OT, agrega uno o varios clientes con su rol y observación, selecciona un motor existente o registra uno nuevo, ingresa fechas y observaciones, el sistema valida, el usuario confirma y el sistema guarda la orden con un código y el estado inicial Pendiente, dejando todo registrado en el historial. Además contemplé ocho flujos alternativos —por ejemplo, cliente duplicado, registro de un motor nuevo durante la creación de la OT, validación fallida o cancelación— y reglas de negocio como que toda OT necesita al menos un cliente y un motor, que el código es único y secuencial, y que las órdenes no se eliminan: se anulan y quedan trazadas. Este flujo crea la cabecera de la orden; el registro de piezas y repuestos ocurre como puntos de extensión «extend», gestionados en detalle por sus propios casos de uso (CU4 y CU5), para mantener cada caso cohesivo. Es un caso de uso diario. (~55 s)

— Respaldo (Q&A · no se lee en voz alta): La tabla que se ve (Actores · Precondiciones · Postcondiciones · Flujo normal · Reglas) se llama «Descripción del Caso de Uso» — así la nombra la ERS de la tesis (Cap. IV/V, bajo IEEE 830); sinónimos válidos: especificación, narrativa o plantilla de caso de uso. Significado de sus campos: actor principal = quien inicia el caso; secundario = participa sin iniciarlo (el gerente); precondiciones = lo que debe ser cierto antes; postcondiciones = el estado garantizado después; flujo normal = el «curso básico» sin errores; flujos alternativos = los desvíos (cliente duplicado, validación fallida…); reglas de negocio = restricciones del dominio (R1, R6, R8); puntos de extensión «extend» = dónde el caso invoca a otros casos (piezas→CU4, repuestos→CU5).

Capítulo V · ICONIX en acción

Trazabilidad ICONIX del caso

Diagrama de caso de uso de Gestionar órdenes de trabajo

1 · Diagrama de caso de uso

Diagrama de robustez de Gestionar órdenes de trabajo

2 · Análisis de robustez

Diagrama de secuencia de Gestionar órdenes de trabajo

3 · Diagrama de secuencia

Y aquí está lo valioso de ICONIX: es el mismo caso de uso atravesando todos los artefactos de forma trazable. Del diagrama de caso de uso derivé el análisis de robustez, que me dejó ver los objetos del curso básico —la pantalla de gestión, el control que valida los datos, y las entidades OrdenTrabajo, Motor y ClienteOT (la cabecera de la OT)—. De ahí salió el diagrama de secuencia, que ordena los mensajes entre las capas interfaz, controlador y modelo: solicitar la inicialización, agregar clientes, asociar o crear el motor, confirmar y registrar en el historial. En la secuencia se ven además los mensajes agregarPiezasOT y agregarRepuestosOT hacia :PiezasOT y :RepuestosOT: son los puntos de extensión «extend» donde se invocan los casos CU4 y CU5, cuya gestión detallada vive en sus propios casos. Así, un solo caso de uso se propaga sin perder coherencia desde el requisito hasta el diseño. El prototipo navegable de esta misma pantalla lo verán funcionando en el video de la demostración. (~40 s)
(Truco: pulsa siguiente para ampliar cada diagrama uno por uno —el título y los rótulos se ocultan— y avanzar entre ellos; un último siguiente pasa a la diapositiva del modelo de dominio.)

— Respaldo (Q&A · cómo leer cada diagrama, no se lee en voz alta):

1) Diagrama de caso de uso (vista del usuario: qué hace, no cómo). El monigote es el actor (un rol, no una persona); los óvalos son casos de uso y el óvalo verde central («Gestionar OT») es el caso base. La línea continua actor–caso es una asociación (comunicación: el actor usa esa función; no lleva flecha). La flecha punteada «include» (hacia Crear OT y Buscar OT) = el caso base siempre ejecuta ese sub-caso (obligatorio, reutilizable); apunta hacia el caso incluido. La flecha punteada «extend» (Ver, Modificar, Eliminar, Consultar estado, Registrar piezas/repuestos) = sub-caso opcional/condicional que añade comportamiento; apunta hacia el caso base. Los « » son estereotipos (etiquetan el tipo de relación). Regla de oro: include = siempre · extend = a veces (por eso piezas/repuestos son «extend»).

2) Análisis de robustez (puente análisis↔diseño de ICONIX: descubre los objetos). Hay tres tipos de objeto (estereotipos de Jacobson): frontera/boundary = círculo con una barra a la izquierda = pantallas (pGestionarOT, pErrorIngresoDatos, pGestionOTs — la «p» es de pantalla); control = círculo con una flecha circular encima = lógica/validación (Validar datos, Crear OT, Mensaje: Errores); entidad/entity = círculo liso = datos del dominio (OrdenTrabajo, Motor, ClienteOT). Las líneas son comunicación y sus rótulos son los mensajes/acciones (registrarOrdenTrabajo(...), verificar(datosOT); «Datos válidos / no válidos» es una bifurcación; «asociar motor», «vínculo cliente-orden»). Reglas que respeté: el actor solo habla con fronteras; las fronteras con controles; solo el control toca entidades. Prohibido: frontera↔frontera, entidad↔entidad y actor↔entidad directos.

3) Diagrama de secuencia (el «cómo» en el tiempo: orden de mensajes). Los rectángulos de arriba son los objetos / líneas de vida; el prefijo «:» significa «una instancia de esa clase» (:Cliente = un objeto Cliente). Los estereotipos los clasifican igual que en robustez: <<Interfaz>> = frontera, <<Controlador>> = control, el resto entidades. La línea vertical punteada es la línea de vida; el rectángulo vertical estrecho es la barra de activación (el objeto ejecutando algo). La flecha continua con punta sólida es un mensaje síncrono (llamada a un método que espera respuesta: agregarCliente(idCliente, rol, obs), crearOT(datosOT)); la flecha de regreso (más fina) es el retorno (returnClientes()); un mensaje al mismo objeto es una auto-llamada (verificarExistencia). Lo que va entre paréntesis son los parámetros. Se lee de arriba (primero) a abajo (después). Los mensajes agregarPiezasOT/agregarRepuestosOT son los «extend» (CU4/CU5), y loguearAccion hacia :HistorialActividad / :HistorialEstadoOT cumple la postcondición «registro en historial».

Capítulo V · Análisis

Modelo de dominio

El análisis me permitió entender el negocio como un conjunto de entidades relacionadas. El modelo de dominio define las claves: el cliente trae un motor, que origina una orden de trabajo; esa orden se compone de piezas, a cada pieza se le asignan trabajos ejecutados y repuestos, y todo movimiento de custodia queda registrado. Este modelo responde a cuatro preguntas: quién interviene, qué pieza, qué repuesto y qué movimiento. (~45 s)

— Respaldo (Q&A · cómo leer el diagrama, no se lee en voz alta): El modelo de dominio es una vista conceptual del negocio (nivel de análisis): aún no tiene tipos de dato ni métodos. Cada rectángulo es una clase/concepto del dominio con su nombre arriba y sus atributos clave debajo (Orden de Trabajo, Motor, Cliente en OT, Cliente, Catálogos, Pieza OT, Tipo de Pieza, Movimiento, Trabajo Ejecutado, Repuestos OT…). Las líneas son asociaciones (relaciones) y el texto sobre cada línea es el nombre/rol de la relación («se compone de», «se le asignan», «corresponde a», «afecta a», «solicita», «representa a», «se basa en», «pertenece a», «requiere»…). Los números en los extremos son la multiplicidad (cardinalidad) y se leen en el extremo opuesto: 1 = exactamente uno; 0..* = cero o muchos (opcional, varios); 1..* = uno o muchos (al menos uno). Ejemplos: «Orden de Trabajo se compone de 0..* Pieza OT» (una OT puede tener cero o muchas piezas); «Pieza OT se le asignan 1..* Trabajo Ejecutado» (al menos un trabajo por pieza); «Motor corresponde a 1 Catálogo de Modelos». A diferencia del diagrama de clases, aquí interesa el negocio, no la implementación.

Capítulo V · Diseño

Diagrama de clases

Diagrama de clases conceptual

Del modelo de dominio derivé el diagrama de clases conceptual, con sus atributos y métodos siguiendo el patrón MVC. Aquí se ve el sistema completo: la orden de trabajo como entidad central, el cliente y su motor, las piezas con sus trabajos y repuestos, y las clases de historial y movimiento que dan trazabilidad a cada cambio. Diseñé priorizando la simplicidad y la integridad de la información. (Avanzo una vez para ampliar el diagrama y leerlo mejor.) (~30 s)

— Respaldo (Q&A · cómo leer el diagrama, no se lee en voz alta): El diagrama de clases es el nivel de diseño: el mismo dominio pero ya con tipos y comportamiento. Cada caja es una clase con tres compartimentos: (1) el nombre; (2) los atributos con su tipo (nombre: Tipo — p. ej. codigoOT: String, fechaIngreso: Date, cantidad: Int, esPrincipal: Boolean); y (3) las operaciones/métodos, que terminan en () y llevan su tipo de retorno (crearOT(): void, anularOT(): void). void significa que el método no devuelve valor. Los atributos idX: Long son los identificadores (clave primaria y claves foráneas) que dan la integridad referencial. Las líneas son asociaciones con su multiplicidad (1, 0..*, 1..*), igual que en el modelo de dominio. Diferencias frente al dominio: aquí se añaden los tipos de dato, los métodos (comportamiento) y clases técnicas como Usuario, HistorialEstadoOT, HistorialActividad y Movimiento, que dan trazabilidad. Sigue el patrón MVC (estas clases son el «Modelo»).

Capítulo VI · Implementación

Arquitectura en 3 capas

Cada capa con una responsabilidad clara y la tecnología elegida para cumplirla.

Presentación

Interfaz de usuario

React — UI por componentes, reactiva y fluida.

TypeScript — tipado que atrapa errores.

→

Lógica / Aplicación

Reglas de negocio y API REST

Laravel — orquesta la lógica y expone la API.

Sanctum — autenticación por tokens segura.

→

Datos

Persistencia e integridad

PostgreSQL — integridad y consultas eficientes.

Separación de responsabilidades → base escalable y mantenible.

Capítulo VII · Seguridad

Seguridad de la información

Confidencialidad

Autenticación con Laravel Sanctum, usuarios con roles y permisos, manejo seguro de sesiones.

Integridad

Validaciones en backend, restricciones en la base de datos e historial de cambios.

Disponibilidad

Información centralizada y accesible en tiempo real; base para respaldos.

Gestión de usuarios y roles

C · I · D

La seguridad la abordé en sus tres pilares. Confidencialidad: autenticación con Laravel Sanctum, usuarios con roles y permisos —administrativo y gerente— y manejo seguro de sesiones. Integridad: validaciones en el backend, restricciones en la base de datos e historial de cambios que evita alteraciones silenciosas. Disponibilidad: la información está centralizada y accesible en tiempo real, y queda lista para implementar respaldos. Estos tres pilares no son arbitrarios: se alinean con la norma ISO/IEC 27001:2022, que cito en el marco normativo de la tesis. El prototipo aplica las buenas prácticas básicas —cifrado de contraseñas y control de accesos— y su diseño es escalable a una certificación futura. Como mejora propongo doble factor y copias automáticas. (~45 s)

(Si insinúan que «solo es descriptivo»:) La autenticación y el control de accesos sí se probaron —es el Caso de Prueba 1 y la validación de usuarios activos—, así que no es solo descriptivo. Lo que no hice es un pentest formal, y es correcto: eso corresponde a la fase de endurecimiento en producción, no al alcance de un prototipo. Que un prototipo dedique un capítulo a la seguridad y cubra los tres pilares de la ISO 27001 ya está por encima del estándar de un prototipo.

Capítulo IX · Evaluación económica

Relación costo–beneficio

Bs 9.000Inversión total

Bs 16.000Beneficio anual

1,78Relación B/C

78%ROI primer año

6,7 mesesPeriodo de recuperación

Costos · Bs 9.000

Desarrollo 7.200 · Hosting 600 · Capacitación 400 · Mantenim. 300 · Indirectos 500

Beneficios · Bs 16.000/año

Tiempo 8.400 · Errores 3.600 · Trazabilidad 1.500 · Papelería 1.000 · Decisiones 1.500

Por cada boliviano invertido, 1,78 Bs de retorno — bajo riesgo, alta rentabilidad.

¿Es conveniente esta inversión? Sí. Con una inversión total de 9.000 bolivianos —8.500 de costos directos y 500 de indirectos— el sistema genera beneficios anuales estimados de 16.000 bolivianos, casi el doble. Esto da una relación beneficio-costo de 1,78 —por cada boliviano invertido se recuperan 1,78—, un ROI del 78% en el primer año y un periodo de recuperación de apenas 6,7 meses. Los beneficios provienen de cinco fuentes: el ahorro de tiempo administrativo (8.400, la mayor), menos errores y retrabajos (3.600), mejor trazabilidad (1.500), ahorro en papelería (1.000) y apoyo a la toma de decisiones (1.500). Todo estimado con criterios conservadores a partir de entrevistas y observación directa del taller. Si el tribunal pide el detalle, lo tengo en las diapositivas de respaldo. Es un proyecto de bajo riesgo y alta rentabilidad. (~50 s)

Capítulo X

Conclusiones

Los siete objetivos, cumplidos

1Se diagnosticó la situación: pérdida y dispersión

2Se elaboraron los requerimientos (IEEE 830)

3Se analizó con UML: 14 CU + dominio

4Se diseñó el sistema: 3 capas · BD normalizada

5Se desarrolló el prototipo

6Se evaluó la seguridad

7Se determinó la rentabilidad

Se elaboró el prototipo de aplicación web que sistematiza y permite consultar la información de las órdenes de trabajo resolviendo la deficiencia que originó el proyecto. Además, resultó técnica y económicamente viable y sienta una base sólida y escalable para la transformación digital del taller.

Cierro retomando los mismos siete pasos de los objetivos, porque cada objetivo quedó cumplido: uno, se diagnosticó la situación y se confirmó la pérdida y dispersión de la información; dos, se elaboraron los requerimientos bajo la norma IEEE 830; tres, se analizó con UML —catorce casos de uso y el modelo de dominio—; cuatro, se diseñó el sistema en tres capas con la base de datos normalizada; cinco, se desarrolló el prototipo con React, Laravel y PostgreSQL; seis, se evaluó con catorce pruebas exitosas; y siete, se determinó que es rentable. En síntesis, se concluye que se elaboró el prototipo que sistematiza y permite consultar la información de las órdenes de trabajo —centraliza los registros, asegura su trazabilidad y mejora la disponibilidad de la información—, resolviendo la deficiencia que originó el proyecto; y, además, resultó técnica y económicamente viable —B/C 1,78, ROI 78 % y recuperación en 6,7 meses—, sentando una base sólida y escalable para la transformación digital del taller. (~45 s)

P: ¿Por qué solo 14 pruebas? R: El número no es arbitrario: diseñé un caso de prueba por cada uno de los 14 casos de uso del Capítulo V, así que cubren la funcionalidad completa del alcance con trazabilidad requerimiento ↔ resultado. Y no fue un solo tipo de prueba: la estrategia tuvo dos fases —pruebas unitarias y de integración— (interacción entre módulos, estados, restricciones y consistencia de datos). Las 14 fueron exitosas.

P: ¿Por qué no hizo pruebas de carga/rendimiento ni mediciones de tiempo? R: Por el alcance de un prototipo, no un sistema en producción. Las pruebas no funcionales —carga, estrés, rendimiento, % de disponibilidad— requieren un despliegue real con concurrencia y volumen de datos, condiciones que el prototipo no tiene; por eso los RNF se validaron de forma cualitativa y esas pruebas quedan para la fase de implementación (están en mis recomendaciones). En cuanto a los tiempos del costo-beneficio, no se midieron instrumentalmente porque el sistema aún no está en uso diario: se estimaron con entrevistas y observación directa, de forma conservadora. (Si mencionan que la metodología hablaba de pruebas de carga y rendimiento: reconócelo como enfoque general; al delimitarse a prototipo se ejecutaron las unitarias y de integración, y las de carga/rendimiento se reservan a producción.)

Trabajo futuro

Una hoja de ruta a futuro

Tres horizontes para consolidar el sistema como herramienta integral de gestión.

0–6 meses

Corto plazo

Puesta en producción (despliegue en la nube).
Capacitación continua del personal.
Módulo de costos y precios (rentabilidad por OT).
Doble factor y respaldos automáticos.

6–18 meses

Mediano plazo

Módulo de planificación semanal.
IA para estimar tiempos y costos por tipo de motor.
Evolucionar clientes hacia un CRM.

+18 meses

Largo plazo

Integración con facturación electrónica.
Analítica predictiva de demanda y cargas.

Finalmente, propongo un camino de evolución en tres horizontes. A corto plazo: poner el sistema en producción —desplegarlo en la nube—, capacitación continua para asegurar el uso correcto, reforzar la seguridad con doble factor y respaldos automáticos —y notificaciones internas—, y un módulo de costos y precios que vincule tiempos, repuestos y trabajos por tipo de motor para evaluar la rentabilidad por orden y del negocio —una recomendación que ya planteo en la tesis—. A mediano plazo: un módulo de planificación semanal, la incorporación de inteligencia artificial para estimar automáticamente tiempos y costos por tipo de motor a partir del historial de órdenes —aprovechando las más de veinte mil ya registradas—, y evolucionar la gestión de clientes hacia un CRM. Y a largo plazo: integrar la facturación electrónica y una analítica predictiva de demanda y cargas de trabajo. Así el sistema se consolida como una herramienta integral de gestión. (~40 s)

Proyecto de Grado · Ingeniería Industrial y de Sistemas

Prototipo de aplicación web para la gestión
de información de órdenes de trabajo para
la empresa Rectificaciones Cordova

Jorge Luis Cordova Rojas

Docente guíaMgs. Heber Tito Zúñiga Morales

Anexo · Diagnóstico

FODA de la empresa

FortalezasInterno

Experiencia y prestigio (desde 1996)
Personal técnico calificado
Cierto orden físico de documentos

OportunidadesExterno

Digitalización de procesos
Mejorar trazabilidad y servicio
Base para decisiones con datos

DebilidadesInterno

Registro 100% manual
Sin sistema centralizado
Información dispersa y duplicada

AmenazasExterno

Pérdida de competitividad
Errores y retrasos
Dependencia del conocimiento del personal

Anexo · IEEE 830

Especificación de requisitos (Cap. IV)

Estructura de la ERS

Propósito y alcance del sistema
Descripción general: perspectiva, funciones, usuarios, restricciones, suposiciones y dependencias, requisitos futuros
Requisitos específicos: funcionales (RF) y no funcionales (RNF)
Atributos de calidad y casos de uso

Fiabilidad Usabilidad Mantenibilidad Seguridad Escalabilidad

43Requisitos funcionales

5Requisitos no funcionales

14Casos de uso

1998ANSI/IEEE 830

Trazabilidad — cada caso de uso mapeado a su requerimiento funcional

Anexo · Requisitos

Requerimientos del sistema

Módulo	RF	Qué cubre
Clientes	4	registrar · editar · consultar · inactivar
Motores	4	registrar · editar · consultar · inactivar
Órdenes de trabajo	4	crear · editar · cambiar estado · consultar
Piezas de OT	3	registrar · editar/eliminar · consultar
Repuestos de OT	3	registrar · actualizar estado · consultar
Trabajos ejecutados	3	registrar · actualizar · consultar
Movimientos de custodia	3	registrar · responsables/cantidades · consultar
Búsqueda y consulta de OT	4	buscar · filtrar · por criterios · ver detalle
Historial	2	ver/consultar actividades y cambios de estado
Reportes y dashboard	3	operativos · administrativos · dashboard
Usuarios	3	crear · editar/inactivar · roles y permisos
Catálogos	3	marcas/modelos · trabajos/repuestos · inactivar
Sesión	4	iniciar y cerrar sesión (admin y gerente)
Total	43	13 módulos → trazados a los 14 casos de uso

5 requisitos no funcionales

Disponibilidad 24 h · 365 días
Seguridad de la información sensible
Usabilidad: interfaz amigable y fácil
Respuesta rápida en consultas y operaciones
Layout adaptable a escritorio (móvil a futuro)

Atributos de calidad

Fiabilidad Usabilidad Mantenibilidad Seguridad Escalabilidad

Restricción de diseño: stack JavaScript/TypeScript · código escalable y flexible.

La ERS sigue la estructura de IEEE 830 (RF/RNF, atributos de calidad, trazabilidad CU↔RF). Cada RF se redacta como historia de usuario (Como… quiero… para…), coherente con ICONIX — la norma no prescribe una redacción específica.

(Diapositiva de respaldo, fuera del flujo hablado.) La uso si el tribunal pide ver los requerimientos en detalle. El Capítulo IV define 43 requisitos funcionales, agrupados aquí en 13 módulos que corresponden a los 14 casos de uso, y 5 requisitos no funcionales con sus atributos de calidad.

P: ¿El formato "Como… quiero… para…" es IEEE 830? R: No, y conviene ser preciso: ese formato es el de historia de usuario, que viene del enfoque ágil, no de IEEE 830. Lo que sí es IEEE 830 en mi Capítulo IV es la estructura de la ERS (propósito, alcance, descripción general, RF y RNF, atributos de calidad) y sus cualidades —no ambigüedad, verificabilidad y trazabilidad—. IEEE 830 no prescribe una redacción concreta (los ejemplos clásicos usan "el sistema deberá…", pero admite otras formas, incluso organizar por casos de uso). Por eso elegí la historia de usuario: es compatible con la norma y coherente con que ICONIX está orientada a casos de uso, ya que captura el requisito con su actor y su propósito y cada uno se traza a un caso de uso. En resumen: estructura y atributos de calidad = IEEE 830; la redacción = historia de usuario; las dos cosas conviven sin contradicción.

P: ¿43 requisitos funcionales no son demasiados para un prototipo? R: Cubren el flujo completo del taller sin huecos: cada módulo corresponde a un caso de uso y cada caso de uso tiene su prueba (las 14 pruebas exitosas). Son acciones concretas (registrar, editar, consultar, inactivar…), por eso el conteo es alto pero el alcance está acotado.

P: ¿Y los requisitos no funcionales son medibles? R: Al ser un prototipo se validaron de forma cualitativa con las pruebas funcionales; en producción se cuantificarían (p. ej. respuesta < 2 s, % de disponibilidad). Ver la diapositiva «norma vs tesis».

Anexo · IEEE 830

¿Qué exige la norma y cómo la cumplí?

IEEE 830 recomienda	En mi tesis
ERS estructurada (SRS)	Capítulo IV completo con la plantilla del estándar
Requisitos no ambiguos	RF expresados por rol/actor con su propósito
Requisitos verificables	14 casos de prueba unitarios, todos exitosos
Requisitos trazables	Cada caso de uso mapeado a su requerimiento funcional

(Diapositiva de respaldo, fuera del flujo hablado.) Respuestas preparadas para las preguntas más difíciles sobre la norma:

P: ¿Por qué historias de usuario ("Como… quiero… para…") y no enunciados "el sistema deberá…"? R: ICONIX es una metodología orientada a casos de uso; la historia de usuario captura el requisito junto con su actor y su propósito, y cada una se traza a un caso de uso. Es una variante de redacción válida, no una omisión de la norma.

P: ¿Por qué los RF no están numerados (RF-01, RF-02…)? R: La trazabilidad se garantiza por la tabla de casos de uso (ID ↔ requerimiento funcional); reconozco que un esquema RF-NN explícito lo haría aún más directo y es una mejora sencilla.

P: Los RNF parecen poco medibles ("respuesta rápida", "disponibilidad 24/365"). R: Al tratarse de un prototipo, los atributos de calidad se validaron de forma cualitativa con las pruebas funcionales; en producción se cuantificarían (p. ej. respuesta < 2 s, % de disponibilidad).

P: IEEE 830 está derogada, ¿no debería usar ISO/IEC/IEEE 29148? R: Correcto, 830-1998 fue reemplazada en 2011; la usé como la referencia académica más difundida para estructurar la ERS, y 29148 conserva los mismos atributos de calidad (claridad, no ambigüedad, verificabilidad, trazabilidad), por lo que la especificación sigue siendo compatible.

P: ¿Por qué el marco conceptual define MEAN, MERN, MongoDB, Express o Node si el sistema no las usa? R: Documentan el ecosistema de desarrollo web que evalué antes de elegir mi arquitectura. De hecho, de la familia MERN conservé React en el frontend, y descarté Mongo a favor de PostgreSQL (integridad referencial) y Node/Express por Laravel. Definir los stacks justifica por qué elegí esa combinación y no una pila JavaScript pura. (Si aprietan:) Es justo; los acotaría estrictamente a las tecnologías implementadas en una revisión.

P: Su capítulo de seguridad es descriptivo, ¿hicieron pruebas o un pentest? R: Tres puntos. (1) La autenticación y el control de accesos sí se probaron —Caso de Prueba 1 y validación de usuarios activos—, no es solo descriptivo. (2) La seguridad la abordé por diseño en los tres pilares (confidencialidad, integridad, disponibilidad) alineados con ISO/IEC 27001:2022: profundidad adecuada para un prototipo. (3) No hice un pentest formal porque corresponde a la fase de endurecimiento en producción; lo dejo explícito como mejora (doble factor y respaldos automáticos). Que un prototipo dedique un capítulo a la seguridad ya está por encima del estándar.

Anexo · Validación

Validación del sistema

Verificación

¿Construí el sistema correctamente?

Que funcione sin errores y cumpla la especificación → 14 casos de prueba (unitarias y de integración), todos exitosos.

Validación

¿Construí el sistema correcto?

Que resuelva la necesidad real del taller → lo confirma el usuario real.

Cómo se validó el prototipo

Demo / aceptación del gerente Checklist de requisitos cumplidos Retroalimentación del personal 14 pruebas (unitarias + integración)

(Diapositiva de respaldo, fuera del flujo hablado.) La uso si el tribunal pregunta por la validación del sistema.

P: ¿Cómo validó que el sistema realmente resuelve el problema? R: Distingo dos cosas. La verificación —"¿lo construí bien?"— la cubren las 14 pruebas funcionales, todas exitosas. La validación —"¿es el sistema correcto?"— la confirma el usuario real: presenté el prototipo al gerente y al personal administrativo, revisamos contra la checklist de requisitos que cada función esperada estuviera cubierta, y recogí su retroalimentación. El prototipo reproduce el flujo completo de la orden de trabajo que hoy llevan en papel, así que la propia comparación con su proceso real es la mejor prueba de que resuelve su necesidad. Aclaro que los Bs 16.000 de beneficio anual son una proyección a partir de los tiempos observados, no una medición post-despliegue: se confirmarán al implementar el sistema.

P: ¿Y la validación de los requisitos no funcionales? R: Al ser un prototipo se validaron de forma cualitativa con las pruebas; en producción se cuantificarían (respuesta < 2 s, % de disponibilidad).

P: ¿Por qué solo 14 pruebas y no de carga/rendimiento? R: Las 14 son una por cada caso de uso (cobertura funcional completa, con trazabilidad) e incluyen dos fases: unitarias e integración. Las pruebas de carga y rendimiento exigen un entorno de producción con concurrencia y volumen reales, fuera del alcance del prototipo; quedan reservadas para la fase de implementación.

Anexo · Casos de uso

¿Por qué piezas y repuestos no están en el flujo de CU3?

Caso de uso	Responsabilidad
CU3 · Gestionar OT	Cabecera de la orden: cliente(s) con rol, motor, fechas, estado e historial
CU4 · Gestionar piezas de OT	Alta / edición / baja de las piezas que ingresan — relación «extend» con CU3
CU5 · Gestionar repuestos de OT	Alta / edición / baja de los repuestos a usar — relación «extend» con CU3

Separación de responsabilidades: cada caso de uso queda cohesivo y trazable; piezas y repuestos cuelgan de CU3 por «extend».

(Diapositiva de respaldo, fuera del flujo hablado.) La uso si el tribunal nota que las piezas y repuestos aparecen en unos artefactos y no en otros.

P: ¿Por qué su diagrama de secuencia agrega piezas y repuestos, pero su análisis de robustez y su flujo normal no los mencionan? R: Es una decisión de diseño, no una omisión. CU3 «Gestionar órdenes de trabajo» gestiona la cabecera de la OT (cliente, motor, fechas, estado, historial); el manejo de piezas y repuestos son casos de uso propios —CU4 y CU5— enlazados a CU3 por la relación «extend», para que cada caso quede cohesivo. La robustez modela el curso básico; por eso solo muestra OrdenTrabajo, Motor y ClienteOT. En la secuencia sí se ven los mensajes agregarPiezasOT y agregarRepuestosOT: son los puntos de extensión donde se invocan esos casos. Su gestión detallada (editar, quitar, validar cantidades) vive en CU4 y CU5.

P: ¿Y eso no rompe la trazabilidad de ICONIX? R: Al contrario: muestra la trazabilidad. El mismo caso atraviesa caso de uso → robustez → secuencia, y los puntos «extend» conectan con sus casos derivados. El modelo de dominio y el diagrama de clases reflejan la composición completa (OT → piezas → trabajos y repuestos).

Anexo · Evaluación económica

¿De dónde salen los Bs 9.000?

Costos directos	Bs
Desarrollo del sistema (240 h × Bs 30/h)	7.200
Hosting en la nube (Render, 7 USD/mes)	600
Capacitación (8 h × Bs 50/h)	400
Mantenimiento inicial (10 h/año × Bs 30/h)	300
Subtotal directos	8.500

Costos indirectos	Bs
Consumo eléctrico y conectividad	150
Curva de aprendizaje (10 h × Bs 12,50 + margen)	250
Documentación y material impreso	100
Subtotal indirectos	500

Inversión total = 8.500 directos + 500 indirectos = Bs 9.000

Bs 30/h desarrollo 240 h de trabajo tc 6,96 Bs/USD (BCB) Sin licencias (open source) Usa equipos existentes

(Diapositiva de respaldo, fuera del flujo hablado.) La uso si el tribunal pregunta de dónde salen los costos.

P: ¿Cómo estimaste el costo de desarrollo de Bs 7.200? R: Por horas × tarifa. Estimé unas 240 horas repartidas en análisis (30), diseño (25), backend (80), frontend (70) e integración de base de datos y pruebas (35), a una tarifa de Bs 30/h de desarrollador freelance para microempresa en el mercado boliviano 2025.

P: ¿Por qué el costo es tan bajo / no hay licencias ni servidores? R: El stack es código abierto (Laravel, React, PostgreSQL), así que no se pagan licencias; el hosting en la nube (Render, 7 USD/mes ≈ Bs 600/año al tc oficial del BCB de 6,96) reemplaza la compra de un servidor físico, y la empresa ya cuenta con las computadoras, por lo que no se contempla infraestructura nueva.

P: ¿Y los costos indirectos? R: Son menores y conservadores: consumo eléctrico e Internet de las pruebas (150), la curva de aprendizaje del personal —≈10 horas a Bs 12,50 más un margen— (250) y la impresión de manuales (100). En total Bs 500.

Anexo · Evaluación económica

¿De dónde salen los Bs 16.000?

Beneficio (Bs/año)	Base de cálculo	Bs
Reducción de tiempos en gestión de órdenes	−60 % ≈ 2,7 h/día × Bs 12,50/h × 250 días	8.400
Disminución de errores y retrabajos	2 errores/mes × Bs 150 c/u	3.600
Mejora en trazabilidad y control	Bs 125/mes (pérdidas y confusiones en taller)	1.500
Ahorro en insumos de papelería	≈ Bs 80/mes en formularios y archivo físico	1.000
Apoyo a la toma de decisiones	1 h/mes del gerente × Bs 125 (reportes automáticos)	1.500
Total beneficios anuales		16.000

B/C = 16.000 / 9.000 = 1,78 · ROI = (16.000 − 9.000) / 9.000 = 77,8 % ≈ 78 % · Payback = 9.000 / 16.000 ≈ 6,7 meses

(Diapositiva de respaldo, fuera del flujo hablado.) La uso si el tribunal pregunta de dónde salen los beneficios.

P: ¿Cómo validaste los beneficios económicos? R: Con entrevistas al gerente y observación directa del proceso. Medí que la gestión administrativa consume ≈5 horas diarias y desglosé actividad por actividad cuánto se reduce con el sistema (tabla 9.4 de la tesis), valoré la hora del personal administrativo en Bs 12,50, usé la frecuencia histórica de errores (≈2/mes) y el gasto real de papelería. Son estimaciones conservadoras.

P: ¿No están sobreestimados los beneficios? R: No; al contrario. El ahorro de tiempo se calculó tarea por tarea e incluye actividades que NO se reducen (por ejemplo la coordinación telefónica), por eso queda en 60 % y no más. Cada cifra parte del lado bajo del rango observado.

P: El B/C 1,78 compara un beneficio anual con una inversión de una sola vez, ¿es justo? R: Es el retorno del primer año. Los costos recurrentes posteriores (hosting ≈600 + mantenimiento) son pequeños frente a los Bs 16.000/año, así que en los años siguientes el beneficio neto se mantiene alto. Y la inversión se recupera en menos de 7 meses.

Prototipo de aplicación web para la gestiónde información de órdenes de trabajo parala empresa Rectificaciones Cordova

Agenda de la exposición

La empresa: Rectificaciones Cordova

El corazón del negocio

Información dispersa, control limitado

1Procesos manuales

2Conocimiento empírico

3Decisiones sin datos

La meta y el camino

Objetivo general

ICONIX, orientada a casos de uso

La orden de trabajo

Seguimiento de trabajos realizados

La orden de trabajo en Excel

Casos de uso

Ejemplo de caso de uso: Gestionar órdenes de trabajo

Actores

Precondiciones

Postcondiciones

Reglas de negocio clave

Flujo normal

Trazabilidad ICONIX del caso

Modelo de dominio

Diagrama de clases

Arquitectura en 3 capas

Presentación

Lógica / Aplicación

Datos

Seguridad de la información

Confidencialidad

Integridad

Disponibilidad

Relación costo–beneficio

Costos · Bs 9.000

Beneficios · Bs 16.000/año

Conclusiones

Una hoja de ruta a futuro

Corto plazo

Mediano plazo

Largo plazo

Prototipo de aplicación web para la gestiónde información de órdenes de trabajo parala empresa Rectificaciones Cordova

FODA de la empresa

FortalezasInterno

OportunidadesExterno

DebilidadesInterno

AmenazasExterno

Especificación de requisitos (Cap. IV)

Estructura de la ERS

Requerimientos del sistema

5 requisitos no funcionales

Atributos de calidad

¿Qué exige la norma y cómo la cumplí?

Validación del sistema

Verificación

Validación

Cómo se validó el prototipo

¿Por qué piezas y repuestos no están en el flujo de CU3?

¿De dónde salen los Bs 9.000?

¿De dónde salen los Bs 16.000?

Prototipo de aplicación web para la gestión
de información de órdenes de trabajo para
la empresa Rectificaciones Cordova

Prototipo de aplicación web para la gestión
de información de órdenes de trabajo para
la empresa Rectificaciones Cordova