Screenshots

ESRE

ANTEPROYECTO

INTRODUCCIÓN

Este proyecto tiene como objetivo principal crear un software de remates rurales que permita a las empresas realizar remates y gestionar sus operaciones de manera efectiva y eficiente.

Los remates rurales son una realidad en muchos países, especialmente en aquellos donde la agricultura y la ganadería son actividades económicas importantes. Estas transacciones implican la venta de tierras, animales, equipos y otros activos agrícolas, y pueden ser complejas y difíciles de llevar a cabo. En este sentido, se hace necesario contar con herramientas que faciliten estas operaciones y permitan a los Agricultores y Ganaderos realizar sus actividades de manera más eficiente y efectiva.

Con este objetivo, nos hemos propuesto desarrollar un software específico para remates rurales. Este software tiene como finalidad ayudar a los agricultores y ganaderos a planificar y realizar sus remates de manera más sencilla y rápida, utilizando tecnología de vanguardia y herramientas innovadoras. Además, también queremos que este proyecto sea una oportunidad para aprender a crear nuestra propia empresa, desde la planificación hasta la implementación de los planes y la satisfacción del cliente.

El software que desarrollaremos tendrá varias funcionalidades que lo harán muy útil para los usuarios. Algunas de las características clave incluyen:

• Una interfaz fácil de usar e intuitiva, que permita a los usuarios navegar por el sistema sin dificultades.
• La capacidad de registrar y administrar información de los lotes, incluyendo detalles sobre la tierra, los cultivos, el ganado y el equipo.
• Herramientas de análisis y seguimiento, que permitan a los usuarios evaluar el desempeño de sus remates y tomar decisiones informadas.
• Integración con sistemas de pago y facturación, para facilitar la gestión.
• Opciones de personalización, para adaptarse a las necesidades específicas de cada usuario.

Además, también estamos planeando ofrecer servicios adicionales, como capacitación y soporte técnico, para garantizar que los usuarios puedan aprovechar al máximo el potencial del software.

En resumen, nuestro objetivo es crear un software de alta calidad que facilite las operaciones de remates rurales y apoye a los agricultores y ganaderos en su trabajo diario. Al mismo tiempo, también queremos aprender y mejorar nuestras habilidades en programación y emprendimiento, para poder aplicarlas en futuros proyectos y contribuciones a la sociedad.

PROPÓSITO DEL ESRE

El concepto del ESRE (Análisis de Requisitos de Sistemas) es una fase crucial en el desarrollo de software, ya que se encarga de recopilar, analizar y documentar los requisitos del sistema desde la perspectiva del usuario y del empresario. En este documento, se presentará una descripción completa de lo que se realizará en el sistema, considerando tanto las necesidades como los requisitos del usuario, así como los requisitos funcionales y no funcionales. También se describe el comportamiento externo del sistema, incluyendo los requisitos funcionales y no funcionales.

Introducción

El objetivo principal de este estudio es definir los requisitos del sistema de manera clara y precisa, para que se pueda diseñar y desarrollar un software que cumpla con las expectativas de los usuarios y del empresario. En este sentido, se busca identificar las necesidades y requisitos del sistema, así como los elementos que lo componen y cómo interactúan entre sí.

Descripción del sistema

El sistema que se va a desarrollar es un software de gestión de remates rurales, destinado a facilitar la organización y gestión de remates en el ámbito rural. El sistema permitirá a los usuarios realizar diversas tareas relacionadas con los remates, tales como la gestión de lotes, la creación de inventarios, la gestión de pagos y la generación de reportes.

Requisitos funcionales

Los requisitos funcionales del sistema son aquellos que se refieren a las funciones y características que debe tener el software para cumplir con las necesidades de los usuarios. A continuación, se presentan algunos de los requisitos funcionales del sistema:

• Gestión de lotes: el sistema debe permitir la creación, modificación y eliminación de lotes, así como la asignación de números de lote y la gestión de los mismos.
• Creación de inventarios: el sistema debe permitir la creación de inventarios de bienes y productos, así como la gestión de stocks y la actualización automática de los inventarios cuando se realizan ventas o compras.
• Generación de reportes: el sistema debe permitir la generación de reportes detallados de las ventas, compras, inventarios y otros aspectos relevantes para la gestión de remates rurales.

Requisitos no funcionales

Los requisitos no funcionales del sistema son aquellos que se refieren a las características y atributos del software que no están directamente relacionados con las funciones específicas del sistema, pero que son igualmente importantes para su correcto funcionamiento. A continuación, se presentan algunos de los requisitos no funcionales del sistema:

• Seguridad: el sistema debe garantizar la seguridad de los datos y la privacidad de la información de los usuarios, mediante la autenticación y autorización de acceso, así como la criptografía de datos sensibles.
• Usabilidad: el sistema debe ser fácil de usar y navegar, con una interfaz intuitiva y amigable para los usuarios, así como la posibilidad de personalizar la experiencia de usuario.
• Escalabilidad: el sistema debe ser capaz de manejar un gran volumen de datos así como la posibilidad de escalar el sistema en el futuro si es necesario.

Especificación de requerimientos

En la Especificación de Requisitos, tomamos en cuenta la información que se requiere para que el sistema funcione de manera efectiva. Esto incluye detalles sobre los usuarios, sus necesidades y preferencias, así como las características y funcionalidades que esperan del sistema. También consideramos las entradas y salidas del sistema, los flujos de trabajo y procesos empresariales que apoyará, y cualquier integración o compatibilidad con otros sistemas o herramientas.

Una vez que tenemos una comprensión clara de los requisitos, creamos dos tipos de documentación: un Manual del Usuario y uno técnico.

• El Manual del Usuario está diseñado para ser fácil de seguir y entender para los usuarios finales, proporcionándoles instrucciones paso a paso sobre cómo usar el sistema, junto con capturas de pantalla y ejemplos para ayudarles a navegar por la interfaz. Por otro lado
• El manual técnico está escrito para los desarrolladores, proporcionándoles especificaciones técnicas detalladas y diagramas de arquitectura para ayudarles a comprender cómo funciona el sistema.

Ambos documentos se crean siguiendo un formato estandarizado, utilizando plantillas y estilo que aseguran la coherencia y claridad a lo largo de todo el documento. Esto ayuda a garantizar que tanto el Manual del Usuario como el técnico sean fáciles de leer y entender, y que proporcionen toda la información necesaria para que los usuarios y los desarrolladores puedan interactuar con éxito con el sistema.

El manual técnico incluye las siguientes secciones:

• Arquitectura: Descripción de la tecnología subyacente utilizada para construir el sistema, incluyendo lenguajes de programación, marcos, bases de datos y servidores.
• Modelo de Datos: Detalles de las estructuras de datos y relaciones utilizadas por el sistema, incluyendo diagramas de entidades-relaciones y flujo de datos.
• Pruebas: Incluye casos de prueba y escenarios utilizados para validar la función y rendimiento del sistema, junto con herramientas y metodologías de prueba empleadas.

Al crear ambos documentos, aseguramos que todos los interesados tengan acceso a la información que necesitan para interactuar con el sistema de manera exitosa. **El Manual del Usuario **proporciona a los usuarios finales una guía sencilla e intuitiva para utilizar el sistema, mientras que **el manual técnico **ofrece a los desarrolladores una comprensión completa de los componentes internos del sistema y sus especificaciones técnicas. Siguiendo un formato estandarizado y utilizando plantillas y estilo coherentes ayuda a garantizar que ambos documentos sean fáciles de leer y entender, y que proporcionen toda la información necesaria para una interacción exitosa con el sistema.

Verificación de los requerimientos

La verificación de los requerimientos es un proceso clave en el desarrollo de software, ya que se encarga de evaluar si el producto desarrollado cumple con las expectativas y necesidades de los usuarios. Esta etapa es fundamental para asegurarse de que el sistema a desarrollar sea el adecuado y satisfaga las necesidades del usuario.

Para llevar a cabo la verificación de los requerimientos, se deben tener en cuenta las características del producto y compararlas con las necesidades expresadas por el usuario. Se debe analizar cuidadosamente cada uno de los requisitos y evaluar si el sistema desarrollado puede cumplirlos.

Algunas preguntas que se pueden hacer durante la verificación de los requerimientos son:

1. ¿El sistema permite realizar las tareas que el usuario necesita?
2. ¿El sistema tiene las características que el usuario ha solicitado?
3. ¿El sistema es fácil de usar?
4. ¿El sistema es compatible con otros sistemas o herramientas que el usuario utiliza?
5. ¿El sistema es seguro y protege la privacidad del usuario?

Es importante mencionar que la verificación de los requerimientos no solo se enfoca en las características del sistema, sino también en su capacidad para resolver problemas y mejorar los procesos del negocio. Es decir, se evalúa si el sistema es capaz de agregar valor al negocio y mejorar la experiencia del cliente.

Si durante la verificación de los requerimientos se identifican desacuerdos entre las características del sistema y las necesidades del usuario, es necesario realizar cambios y ajustes en el sistema hasta que se cumplan los requisitos establecidos. En algunos casos, esto puede implicar volver a diseñar parte del sistema o incluso comenzar desde cero.

En conclusión, la verificación de los requerimientos es una etapa crucial en el desarrollo de software que ayuda a asegurarse de que el sistema a desarrollar sea el adecuado y satisfaga las necesidades del usuario. Al evaluar cuidadosamente las características del producto y compararlas con las necesidades expresadas por el usuario, se puede garantizar que el sistema sea útil, fácil de usar y agregue valor al negocio.

Las técnicas de uso de un documento ESRE

Las herramientas utilizadas son el método de entrevistas, observación entre muchos otros. Algunos ejemplos son:

• Método de entrevistas: Este método consiste en realizar entrevistas semi-estructuradas a diferentes grupos de personas relacionadas con el ámbito laboral, en nuestro caso empresas. Estas entrevistas buscan obtener información sobre la percepción que tienen estos grupos sobre la calidad del trabajo, los problemas que enfrentan, las fortalezas y debilidades del centro, entre otros aspectos relevantes.
• Observación: La observación es otra técnica utilizada en un estudio ESRE. Nos permite observar el lugar, los espacios físicos, el comportamiento de los empleados, entre otros aspectos, para identificar patrones y tendencias en su vida cotidiana.
• **Análisis de documentos: **También se realiza un análisis de documentos como planes de trabajo, informes de evaluación, registros de asistencia, entre otros, para obtener información sobre la estructura y organización del centro, así como sobre las políticas y prácticas educativas que se llevan a cabo.
• **Cuestionarios: **Se pueden distribuir cuestionarios entre trabajadores y empresas para recopilar información cuantificable sobre sus opiniones y percepciones sobre diferentes aspectos de la empresa.
• **Análisis de datos secundarios: **Podemos utilizar datos secundarios disponibles en línea o en fuentes externas, como estadísticas oficiales, reportes de evaluación externa, entre otros, para complementar la información obtenida a través de otras técnicas.

Estas técnicas, entre otras, nos permiten recopilar información valiosa sobre la situación del trabajador o empresa y analizarla de manera objetiva y rigurosa. El resultado de este análisis puede ser utilizado para identificar fortalezas y debilidades.

Casos de uso

El caso de uso se refiere los diagramas de las acciones que se realizarán para llevar a cabo cierto proceso los personajes que se usan en estos diagramas se les da el nombre de actores.

IDENTIFICACIÓN DEL PRODUCTO

Se espera la creación de un programa capaz de crear, ofertar y gestionar lotes para subastas rurales, con accesos múltiples y en simultáneos. Habiendo en este diferentes roles con privilegios particulares para cada uno. Siendo que un cliente no podrá crear ni gestionar los lotes pero un administrador si. De esta misma manera habrá permisos que solo un rol o varios podrán acceder pero no todos. Se espera que el software además cuente con una interfaz amigable e intuitiva para el usuario.

CONTENIDO DEL ESRE

En esta sección realizaremos un resumen de las partes más importantes que contiene nuestro documento y proyecto en general. Desde objetivos a distintas etapas del mismo

1. Acerca de la empresa: logo, objetivos, localidad, proyectos, presentación, entrevistas, análisis inversiones y parte comercial.
2. Anteproyecto: objetivos, acerca del software, diagramas, diseños, entre otros.
3. Proyecto: Análisis, diseños, diagramas, logros, pruebas, conclusiones, entre otros
4. Anexos: Equipo, manuales (usuario y técnico), entrevistas, bitácora, entre otros

PRESENTACIÓN DEL CLIENTE

Remates del Campo es una empresa dedicada a la organización de remates rurales, que ha experimentado un crecimiento significativo en recientes años. Sin embargo, esta expansión ha llevado aparejada la aparición de problemas en la gestión de remates, información de lotes, pagos, gestión de empleados y otras actividades. Para mantenerse competitivo en el mercado, la dirección de la empresa ha decidido informatizar sus procesos mediante la creación de una plataforma/aplicación en línea y local.

PRESENTACIÓN DEL PROBLEMA

La competencia en el mercado de remates rurales es cada vez más intensa y la empresa necesita modernizarse para mantenerse competitiva. Se requiere una plataforma/aplicación en línea y local que permita a compradores y vendedores acceder a información sobre los remates, participar en ellos de manera local y remota, realizar pagos electrónicos y gestionar lotes, empleados y procesos internos de la empresa. También se deben definir diferentes roles de usuario para controlar el acceso a la información y funciones de la plataforma.

LOGIN

DESCRIPCIÓN

El sistema debe permitir a los usuarios realizar un Login dentro del programa. El proceso debe tener los siguientes pasos:

1. Una vez que el usuario está en la ventana de “Login” debe rellenar los campos de “usuario” y “contraseña”.
2. Presiona el botón de “Iniciar” y verifica los datos.
   1. Si los datos son correctos da acceso al resto del software.
   2. Si los datos son incorrectos el sistema muestra “Datos incorrectos vuelva a intentarlo”.
   3. Si el Usuario presiona el botón “Modo Invitado” da acceso a cierta parte del software.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 2

DESCRIPCIÓN

El sistema debe permitir al Usuario dar de alta a uno o varios artículos.

Los pasos a seguir son:

1. El usuario rellena con datos los campos y le da a “guardar”
2. El sistema verifica los datos:
   1. Si los datos son inválidos el sistema muestra el mensaje “Caracteres invaldios” y pinta de color rojo los campos que corresponden
   2. si los datos son correctos el sistema muestra el mensaje “Articulo Guardado” y termina.
   3. El usuario presiona el botón “Cancelar” cancela el proceso y termina.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 3

DESCRIPCIÓN

El sistema debe permitir la baja lógica del artículo. Los pasos a seguir son:

1. El usuario presiona el botón “Eliminar”:
   1. Si el usuario presiona el botón “Cancelar”, termina el proceso.
2. El sistema da de baja el artículo:
   1. Si no se puede dar de baja el artículo el sistema muestra el mensaje “No se pudo eliminar el artículo” y termina.
   2. Si el sistema puede dar de baja el artículo muestra el mensaje “Artículo Eliminado”
3. El sistema cierra la ventana, termina.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 4

DESCRIPCIÓN

El sistema debe permitir modificar los artículos.

Los pasos a seguir son:

1. El Usuario modifica los campos y le da a guardar.
   1. Si el usuario presiona el botón “Cancelar” termina el proceso.
   2. Si los datos ingresados son inválidos el sistema muestra “Caracteres inválidos” y pinta de rojo los campos correspondientes.
   3. Si los caracteres son correctos sigue el proceso.
2. El sistema verifica los datos:
   1. Si el sistema no pudo modificar el artículo el sistema muestra el mensaje “No se pudo modificar el artículo”.
3. El sistema envía los datos a la base de datos
4. El sistema muestra el mensaje “Articulo Guardado”.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 5

DESCRIPCIÓN

El sistema debe mostrar los artículos.

Proceso:

1. El sistema carga los artículos
   1. El sistema no pudo cargar los artículos y muestra el mensaje “Error de conexión, vuelva a intentarlo más tarde”.
   2. “Cancelar”, termina el proceso.
2. Termina.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 7

DESCRIPCIÓN

El sistema debe poder dar de alta uno o varios lotes.

Los pasos a seguir son:

1. El Usuario selecciona mediante el botón “Seleccionar” los artículos que quiere agregar al lote
2. El usuario presiona el botón “Crear Lote”.
   1. Cancelar, termina el proceso.
3. El sistema crea el lote y lo envía a la base de datos.
   1. Si el sistema no puede crear el lote el sistema muestra el mensaje “No se pudo crear el Lote”.
4. El sistema muestra el mensaje “Lote creado”.
5. El sistema cierra la ventana.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 8

DESCRIPCIÓN

El sistema debe ser capaz de dar de baja de lógica uno o varios lotes.

Los pasos a seguir son:

1. El usuario presiona el botón “Eliminar”
   1. Cancelar, termina el proceso.
2. El sistema da de baja lógica al lote
   1. Si no se puede dar de baja lógica el lote el sistema muestra el mensaje “No se pudo eliminar el lote”
3. El sistema muestra “Lote Eliminado”
4. Cierra la ventana y termina.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 9

DESCRIPCIÓN

El sistema debe ser capaz de modificar los lotes.

Los pasos a seguir son:

1. El usuario modifica los campos y le da al botón de guardar:
   1. Si los caracteres son invalidos el sistema muestra el mensaje “Caracteres invalidos” y pinta de color rojo los campos correspondientes.
   2. Cancelar, termina el proceso.
2. El sistema verifica los datos:
   1. El sistema no pudo modificar el lote el sistema muestra el mensaje “No se pudo modificar el artículo”
3. El sistema envía los datos a la base de datos.
4. El sistema muestra el mensaje “lote Guardado”.

DIAGRAMA DE ACTIVIDAD

NOMBRE DEL PROCESO IDENTIFICADO 11

DESCRIPCIÓN

El sistema debe poder mostrar los Lotes.

Proceso:

1. El sistema carga los lotes:
   1. Si el sistema no encuentra ningún Lote.
   2. El sistema no pudo cargar los Lotes.
2. Termina.

DIAGRAMA DE ACTIVIDAD

ACTORES INVOLUCRADOS

Los actores identificados en los procesos de la empresa son, empleados, compradores y vendedores, véase glosario para definición.

LISTA DE NECESIDADES

1. Permitir a los clientes y vendedores acceder a información sobre los remates y participar en los remates.
2. Realización de pagos de manera electrónica y segura.
3. Gestión de lotes.
4. Gestión de empleados.
5. Seguimiento de los procesos internos de la empresa.
6. Roles de usuarios como administrador, empleado, comprador, vendedor y rematador los cuales otorgan diferentes niveles de acceso a la información y funciones.
7. Requeriría un registro de clientes.
8. Registro de pagos y comisiones a los proveedores.
9. Seguridad en los datos de los usuarios y de la empresa.
10. Herramienta de reportes la cual permite generar informes y estadísticas de los remates.
11. Gestionar las subastas.
12. Catálogo de productos.
13. Programación de remates.
14. Registro (Historial) de remates y el seguimiento de los remates realizados en la empresa incluyendo los detalles de los lotes, compradores, precios de venta.
15. Soporte técnico.
16. Registro de proveedores.
17. Monitoreo de ventas de proveedor, permitir al proveedor monitorear las ventas de sus bienes durante y después del remate.

OBJETIVOS

1. Permitir acceso a información sobre remates a compradores
2. Permitir acceso a participar a los remates a compradores
3. Realizar pagos de manera segura y confiable
4. Gestionar lotes
5. Listar lotes filtrando por fecha y tipo
6. Gestionar empleado
7. Listar empleados filtrando por C.I.
8. Listar acciones de los empleados
9. Listar acciones de los empleados filtrando por fecha
10. Crear Etiqueta de administrador, empleado, comprador, vendedor y rematador
11. Gestionar comprador
12. Listar comprador filtrando por C.I.
13. Listar pagos y comisiones
14. Listar pagos y comisiones filtrando por fecha
15. Implementar métodos de seguridad para los datos de la empresa y clientes.
16. Listar estadísticas de remates para compradores
17. Gestionar remate
18. Listar productos
19. Posibilidad de programación de horario de remate
20. Listar remates y sus atributos
21. Listar remates y sus atributos filtrando por fecha
22. Listar remates dentro de la empresa y sus atributos
23. Listar remates dentro de la empresa y sus atributos filtrando por fecha
24. Brindar soporte técnico
25. Gestionar vendedor
26. Listar vendedor filtrando por C.I.
27. Listar ventas del vendedor
28. Listar los lotes del vendedor
29. Gestionar Artículos

MATRIZ DE TRAZABILIDAD DE OBJETIVOS Y NECESIDADES

MATRIZ DE TRAZABILIDAD DE OBJETIVOS Y NECESIDADES.

OBJ/ NEC	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18
OBJ1	X
OBJ2	X
OBJ3		X
OBJ4			X
OBJ5			X
OBJ6				X
OBJ7				X
OBJ8					X
OBJ9					X
OBJ10						X
OBJ11							X
OBJ12							X
OBJ13								X
OBJ14								X
OBJ15									X
OBJ16										X
OBJ17										X
OBJ18											X
OBJ19												X
OBJ20													X
OBJ21														X
OBJ22															X
OBJ23																X
OBJ24																X
OBJ25																	X
OBJ26																	X
OBJ27																	X
OBJ28																	X
OBJ29																	X
OBJ30				X

Fig 51 - Matriz de Trazabilidad

PRIORIZACIÓN DE REQUERIMIENTOS

En esta sección se realiza un ordenamiento de los requerimientos según su prioridad. Estas prioridades pueden ser: Alta, Media y Baja. Donde cada una significa:

• Alta: Imprescindible
• Media: Deseable
• Baja: Poco deseable

PRIORIDAD ALTA

RF01	Requerir autenticación
RF02	Baja de Lotes
RF04	Listado de lotes
RF05	Alta de empleado
RF06	Baja de empleado
RF08	Listado de empleado
RF09	Alta de comprador
RF10	Baja de comprador
RF12	Listado de comprador
RF13	Alta de remate
RF14	Baja de remate
RF16	Listado de remate
RF17	Alta de vendedor
RF18	Baja de vendedor
RF20	Listado de vendedor
RF21	Alta de artículos
RF22	Baja de artículos
RF24	Listado de artículos
RF25	Alta de lotes
RF26	Encriptación de contraseñas
RF30	Alta de pagos
RF31	Baja de pagos
RF33	Listado de pagos
RF34	Listado de estadísticas de remates para clientes
RF36	Listado de ventas del proveedor
RF37	Listado de lotes del proveedor
RF39	Listado de acciones de los empleados
RF42	Listado de pagos y comisiones
RF45	Permitir acceso a información sobre remates a clientes
RF46	Permitir acceso a participar a los remates a clientes
RF47	Crear Etiqueta de administrador, empleado, comprador, vendedor y rematador
RF48	Realizar pagos de manera segura

Fig 52 - Matriz de prioridad alta

PRIORIDAD MEDIA

RF03	Modificación de lotes
RF07	Modificación de empleado
RF11	Modificación de comprador
RF15	Modificación de remate
RF19	Modificación de vendedor
RF23	Modificacion de articulos
RF28	Realizar consultas mediante correo electrónico
RF32	Modificación de pagos
RF44	Posibilidad de programación de horario de remate

Fig 53 - Matriz de prioridad Media

PRIORIDAD BAJA

RF27	Proporcionar FAQ
RF29	Listado de lotes con filtro
RF35	Listado de proveedores con filtro
RF38	Listado de empleado con filtro
RF40	Listado de acciones de los empleados con filtro
RF41	Listado de Clientes con filtro
RF43	Listado de pagos y comisiones con filtro
RF49	Listado de remate con filtro

Fig 54 - Matriz de prioridad Baja

LISTA DE REQUERIMIENTOS

1. Requerir autenticación
2. Baja de lotes
3. Modificación de lotes
4. Listado de lotes
5. Alta de empleado
6. Baja de empleado
7. Modificación de empleado
8. Listado de empleado
9. Alta de comprador
10. Baja de comprador
11. Modificación de comprador
12. Listado de comprador
13. Alta de remate
14. Baja de remate
15. Modificación de remate
16. Listado de remate
17. Alta de vendedor
18. Baja de vendedor
19. Modificación de vendedor
20. Listado de vendedor
21. Alta de artículos
22. Baja de artículos
23. Modificación de artículos
24. Listado de artículos
25. Alta de lotes
26. Encriptación de contraseñas
27. Proporcionar FAQ
28. Realizar consultas mediante correo electrónico
29. Listado de lotes con filtro
30. Alta de pagos
31. Baja de pagos
32. Modificación de pagos
33. Listado de pagos
34. Listado de estadísticas de remates para clientes
35. Listado de proveedores con filtro
36. Listado de ventas del proveedor
37. Listado de los lotes del proveedor
38. Listado de empleado con filtro
39. Listado de acciones de los empleados
40. Listado de acciones de los empleados con filtro
41. Listado de cliente con filtro
42. Listado de pagos y comisiones
43. Listado de pagos y comisiones con filtro
44. Posibilidad de programación de horario de remate
45. Permitir acceso a información sobre remates a clientes
46. Permitir acceso a participar a los remates a clientes
47. Crear Etiqueta de administrador, empleado, comprador, vendedor y rematador
48. Realizar pagos de manera segura y confiable
49. Listado de remate con filtro

ACTORES DEL SISTEMA

Los actores de nuestro sistema son los siguientes:

• SUDOER: Puede leer y modificar todo
• EMPLEADO: Puede leer y modificar todo no sensible
• VENDEDOR: Puede leer todo público y escribir en artículos
• CLIENTE: Puede leer todo público y escribir en pujas
• ANÓNIMO: Puede leer todo público

REQUERIMIENTOS FUNCIONALES

RF01 - Requerir autenticacion

PRIORIDAD: ALTA

DESCRIPCIÓN: Se requerirá que todos los Usuarios ingresen sus credenciales para acceder al software, proporcionando de estas Cédula de Identidad (CI) y contraseña.

RF02 - Baja de lotes

PRIORIDAD: ALTA

DESCRIPCIÓN: El Sistema deberá permitir a los Administradores y Empleados eliminar los lotes ingresados en el sistema.

RF03 - Modificacion de lotes

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados modificar los lotes ingresados en el sistema.

RF04 - Listado de lotes

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Compradores, Rematadores, Administradores y Empleados listar los lotes que se encuentren ingresados en el sistema.

RF05 - Alta de empleado

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados crear nuevos usuarios de tipo Empleado en el sistema.

RF06 - Baja de empleado

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados eliminar usuarios de tipo empleado que sean existentes en el sistema.

RF07 - Modificacion de empleado

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados modificar los usuarios de tipo Empleados que sean existentes en el sistema.

RF08 - Listado de empleado

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores listar los Usuarios de tipo Empleado.

RF09 - Alta de comprador

PRIORIDAD: Alta

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados y Compradores crear nuevos usuarios de tipo Comprador.

RF10 - Baja de comprador

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados eliminar usuarios de tipo compradores que sean existentes en el sistema.

RF11 - Modificacion de comprador

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados modificar los usuarios de tipo comprador que sean existentes en el sistema.

RF12 - Listado de comprador

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores listar los Usuarios de tipo comprador.

RF13 - Alta de remate

PRIORIDAD: ALTA

DESCRIPCIÓN: Se desea desarrollar una función que permita la alta de un nuevo remate rural en el sistema. Esta función debe permitir ingresar los datos necesarios para registrar el remate. La función debe validar la información ingresada y garantizar su integridad, evitando errores o inconsistencias en los datos.

RF14 - Baja de remate

PRIORIDAD: ALTA

DESCRIPCIÓN: Se desea desarrollar una función que permita la baja de un remate rural en caso de que sea necesario.

RF15 - Modificacion de remate

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados modificar los remates ingresados en el sistema.

RF16 - Listado de remate

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a todos los usuarios listar los remates ingresados en el sistema.

RF17 - Alta de vendedor

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados crear nuevos usuarios de tipo Vendedor.

RF18 - Baja de vendedor

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administrador, empleados y vendedores eliminar usuarios de tipo vendedor existentes en el sistema.

RF19 - Modificacion de vendedor

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados y Vendedores modificar los usuarios de tipo Vendedor existentes en el sistema.

RF20 - Listado de vendedor

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados listar a los usuarios de tipo Vendedor existentes en el sistema.

RF21 - Alta de articulos

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados y Vendedores crear nuevos artículos.

RF22 - Baja de articulos

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados y Vendedores eliminar un artículo existente en el sistema.

RF23 - Modificacion de articulos

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados y Vendedores Modificar un artículo existente en el sistema.

RF24 - Listado de articulos

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados, Vendedores y Compradores listar los artículos existentes en el sistema.

RF25 - Alta de lotes

PRIORIDAD: ALTA

DESCRIPCIÓN: Se deberá permitir a los Administradores, Empleados y Vendedores crear nuevos lotes en el sistema.

RF26 - Encriptacion de contraseñas

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá de contar un método de encriptación de contraseñas para todos los usuarios ingresados en la base de datos.

RF27 - Proporciona FAQ

PRIORIDAD: BAJA

DESCRIPCIÓN: El sistema deberá de contar con una apartado de Preguntas frecuentes para que todos los usuarios puedan ver las preguntas más frecuentes realizadas sobre el software, métodos de pagos, seguridad o cualquier duda relacionada al servicio del sistema.

RF28 - Realizar consultas mediante correo electrónico

PRIORIDAD: MEDIA

DESCRIPCIÓN:

RF29 - Listado de lotes con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN: El sistema deberá permitir a todos los usuarios listar los lotes existentes en la base de datos utilizando un sistema de filtros que permitan ordenarlos por fecha de remate, tipo de producto y cantidad.

RF30 - Alta de pagos

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados crear nuevos registros de pagos.

RF31 - Baja de pagos

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados eliminar los registros de pagos existentes en el sistema.

RF32 - Modificacion de pagos

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados modificar un registro de pago existente en el sistema.

RF33 - Listado de pagos

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados, Vendedores y Compradores listar los registros de pagos existentes en el sistema si cuentan con los permisos necesarios.

RF34 - Listado de estadísticas de remates para clientes

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá de contar con un listado de estadísticas de los remates que será visible para todos los usuarios del sistema.

RF35 - Listado de proveedores con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados listar los proveedores registrados en el sistema permitiendo filtrar según sus respectivas propiedades.

RF36 - Listado de ventas del proveedor

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá contar con un listado de ventas de los proveedores y será visible para los usuarios de tipo Administrador únicamente.

RF37 - Listado de lotes del proveedor

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá contar con un listado

RF38 - Listado de empleado con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN:

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados listar los empleados registrados en el sistema permitiendo filtrar según sus respectivas propiedades.

RF39 - Listado de acciones de los empleados

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores listar las acciones de los empleados realizadas en el sistema.

RF40 - Listado de acciones de los empleados con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores listar las acciones de los empleados realizadas en el sistema permitiendo filtrar según sus respectivas propiedades.

RF41 - Listado de clientes con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados listar los usuarios registrados en el sistema permitiendo filtrar según sus respectivas propiedades.

RF42 - Listado de pagos y comisiones

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores y Empleados listar los pagos y comisiones realizados en el sistema

RF43 - Listado de pagos y comisiones con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN:

RF44 - Posibilidad de programación de horario de remate

PRIORIDAD: MEDIA

DESCRIPCIÓN: El sistema deberá contar con una opción que permita a los usuarios de tipo Administrador y Vendedor programar las hora en la que serán los remates.

RF45 - Permitir acceso a información sobre

remates a clientes

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá dar acceso a la información sobre remates a todos los usuarios del sistema.

RF46 - Permitir acceso a participar a los remates a clientes

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá permitir a los a todos los usuarios participar de los remates del sistema.

RF47 - Crear Etiqueta de administrador, empleado, comprador, vendedor y rematador

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema deberá contar con la opción de crear etiquetas de roles tales como Administrador, Empleado, Comprador, Vendedor y Rematador.

RF48 - Realizar pagos de manera segura y confiable

PRIORIDAD: ALTA

DESCRIPCIÓN: El sistema debe permitir realizar pagos de manera segura y confiable a todos los usuarios.

RF49 - Listado de remate con filtro

PRIORIDAD: BAJA

DESCRIPCIÓN: El sistema deberá permitir a los Administradores, Empleados, Vendedores y Clientes listar los remates existentes en el sistema permitiendo filtrar según sus respectivas propiedades.

MATRIZ DE TRAZABILIDAD DE OBJETIVOS Y REQUERIMIENTOS FUNCIONALES

RF/OBJ	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30
1										X
2				X
3				X
4				X	X
5						X
6						X
7						X
8						X
9											X
10											X
11											X
12											X
13																	X
14																	X
15																	X
16																	X			X		X
17																									X
18																									X
19																									X
20																									X
21																														X
22																														X
23																													X	X
24																		X												X
25				X
26			X												X
27																								X
28																								X
29				X	X													X
30			X
31			X
32			X
33			X										X
34	X															X
35																										X
36																											X
37																												X
38							X
39								X
40								X	X
41											X	X
42			X											X
43			X											X
44																			X
45	X
46		X
47										X
48			X
49																					X		X	X

Fig - 55 Matriz de trazabilidad

RNF01 - SEGURIDAD

DESCRIPCIÓN: La plataforma debe garantizar la seguridad de los datos de los usuarios y las transacciones electrónicas. Los datos deben estar encriptados para proteger la confidencialidad de la información.

RNF02 - RENDIMIENTO

DESCRIPCIÓN: La aplicación debe ser eficiente y capaz de manejar una carga significativa de usuarios concurrentes. Debe tener tiempos de respuesta razonables, especialmente durante los remates en tiempo real.

RNF03 - ESCALABILIDAD

DESCRIPCIÓN: La aplicación debe ser capaz de crecer y adaptarse a un aumento en el número de usuarios, lotes, y transacciones.

RNF04 - DISPONIBILIDAD:

DESCRIPCIÓN: La plataforma debe estar disponible y funcionando de manera continua, minimizando las interrupciones.

RNF05 - MANTENIMIENTO Y ACTUALIZACIONES

DESCRIPCIÓN: Debe ser posible realizar actualizaciones de la aplicación sin causar interrupciones significativas en el servicio.

RNF06 INTEGRIDAD DE LOS DATOS

DESCRIPCIÓN: Se deben implementar medidas para garantizar la integridad de los datos almacenados en la plataforma.

RNF07 - CUMPLIMIENTO LEGAL Y REGULATORIO

DESCRIPCIÓN: La plataforma debe cumplir con las leyes y regulaciones aplicables, especialmente en relación con las transacciones electrónicas y la privacidad de los datos.

RNF08 - USABILIDAD Y EXPERIENCIA DEL USUARIO

DESCRIPCIÓN: La interfaz de usuario debe ser intuitiva y fácil de usar para diferentes roles de usuarios. Debe ser compatible con diferentes dispositivos y navegadores.

RNF09 - RENDIMIENTO DE PAGO ELECTRÓNICO

DESCRIPCIÓN: La plataforma debe garantizar un procesamiento rápido y seguro de los pagos electrónicos, evitando retrasos en las transacciones financieras.

RNF10 - GENERACIÓN DE INFORMES Y ESTADÍSTICAS

DESCRIPCIÓN: Debe permitir la generación de informes y estadísticas de manera eficiente, de manera que los usuarios puedan acceder a información relevante de manera rápida.

RNF11 - Administración y Mantenimiento de Roles y Permisos:

DESCRIPCIÓN: Debe ser posible administrar y mantener los roles de usuario y sus permisos de manera eficiente, sin afectar el rendimiento.

RNF12- Registro Histórico y Auditoría:

DESCRIPCIÓN: Debe permitir un registro histórico de todas las operaciones y transacciones realizadas en la plataforma para fines de auditoría y seguimiento.

RNF13 - Gestión de Imágenes y Multimedia:

DESCRIPCIÓN: Debe permitir la carga y gestión eficiente de imágenes y otros medios relacionados con los lotes a rematar.

RNF14 - Programación de Remates:

DESCRIPCIÓN: Debe permitir la configuración de remates con anticipación y garantizar que los remates programados se ejecuten puntualmente.

ALCANCES Y LIMITACIONES

Alcances del Software:

1. Acceso y Participación en Subastas: El software permitirá a compradores y vendedores acceder a la plataforma, explorar información sobre las subastas y participar en ellas, ya sea de manera local
2. Gestión de Usuarios y Roles: Se implementará un sistema de gestión de usuarios y roles para controlar el acceso a la plataforma y establecer niveles de autorización.
3. Gestión de Empleados: Los administradores podrán gestionar a los empleados, registrar sus horas trabajadas, asignar tareas y administrar los pagos.
4. Registro de Clientes: Se permitirá a los usuarios registrarse en la plataforma proporcionando información básica como nombre, dirección, correo electrónico y número de teléfono.
5. Gestión de Lotes: Los vendedores podrán agregar, modificar y eliminar lotes, incluyendo detalles como precio base y descripción.
6. Pagos Electrónicos Seguros: El software permitirá pagos electrónicos seguros y llevará un registro de los pagos y comisiones a los rematadores.
7. Encriptación de Datos: Se implementará un alto nivel de seguridad con encriptación de datos para proteger la información sensible.
8. Generación de Informes: El sistema generará informes y estadísticas relacionados con las subastas y las transacciones para su análisis.
9. Subastas Personalizables: Se podrán programar subastas con opciones personalizables, como fecha, hora, duración y método de pago.
10. Registro y Seguimiento de Remates: El software registrará y realizará un seguimiento de todos los remates, incluyendo detalles de lotes, compradores y precios de venta.
11. Publicación de Detalles de Lotes: Se permitirá a los vendedores publicar información detallada de cada lote, incluyendo fotos, descripciones y más. //todo
12. Monitoreo de Ventas para Proveedores: Los proveedores podrán realizar un seguimiento de las ventas de sus lotes durante y después del remate.

Limitaciones del Software:

1. Seguridad: A pesar de las medidas de seguridad implementadas, no se puede garantizar la absoluta invulnerabilidad frente a amenazas cibernéticas.
2. Compatibilidad: La aplicación puede no ser compatible con todas las plataformas y dispositivos, lo que limita la accesibilidad para algunos usuarios.
3. Requerimientos de Hardware: Los usuarios necesitarán dispositivos y conexiones a internet adecuados para acceder y utilizar la plataforma de manera efectiva.
4. Soporte Técnico: La disponibilidad de soporte técnico puede ser limitada, lo que puede generar desafíos para los usuarios en caso de problemas técnicos.
5. Personalización Extrema: La personalización extrema de la plataforma para necesidades muy específicas puede requerir un desarrollo adicional y costoso.
6. Requisitos Legales y Regulatorios: El software debe cumplir con las regulaciones locales y globales, lo que puede limitar algunas funcionalidades en ciertas jurisdicciones.
7. Escalabilidad: El software puede tener limitaciones en términos de escalabilidad si la empresa de subastas experimenta un crecimiento significativo.

POSIBLES MEJORAS EN FUTURAS VERSIONES

• Exportar informes en PDF
• Exportar información de remates a un sistema para su posterior publicación en la web
• Automatizar generación de imágenes publicitarias con información de los remates a realizar

GESTIÓN DE RIESGOS

La gestión de riesgos es el proceso de identificación, evaluación, priorización y control de los riesgos que podrían afectar a un proyecto, una organización o un sistema. El objetivo de la gestión de riesgos es minimizar la probabilidad y el impacto de los riesgos adversos, y maximizar la probabilidad y el impacto de los riesgos favorables.

Los componentes clave de la gestión de riesgos en un proyecto incluyen:

• Identificación de riesgos: El primer paso en la gestión de riesgos es identificar los riesgos potenciales que pueden afectar el proyecto. Esto implica revisar todos los aspectos del proyecto, desde la planificación hasta la implementación, y buscar posibles amenazas o oportunidades.
• Análisis de riesgos: Después de identificar los riesgos, es necesario analizarlos para comprender mejor su naturaleza y evaluar su probabilidad e impacto. Esto ayuda a determinar cuáles riesgos son más importantes y requieren mayor atención.
• Evaluación de riesgos: En esta etapa, se evalúa el nivel de riesgo y se determina el posible impacto en el proyecto. Esto se hace utilizando herramientas como matrices de evaluación de riesgos, que permiten clasificar los riesgos según su gravedad y probabilidad.
• **Mitigación de riesgos: **Una vez evaluados los riesgos, se desarrollan estrategias para mitigarlos. Esto puede incluir acciones como la reducción de la probabilidad de ocurrencia del riesgo, la reducción del impacto en caso de ocurrencia, o la transferencia del riesgo a otro partido.
• Monitoreo y control de riesgos: Durante la ejecución del proyecto, es importante monitorear y controlar los riesgos identificados. Esto implica trackear los riesgos y actualizar las evaluaciones de riesgos regularmente, así como realizar revisiones periódicas del plan de gestión de riesgos.
• Comunicación de riesgos: La comunicación es un componente clave en la gestión de riesgos. Es importante que todas las partes interesadas estén informadas sobre los riesgos identificados y las medidas de mitigación. Esto ayuda a garantizar que todos estén preparados para manejar los riesgos y minimizar su impacto.
• Documentación de riesgos: Es importante documentar todos los riesgos identificados, sus características, evaluación y mitigación. Esto permite una trazabilidad clara y evita que se olviden o se ignoren los riesgos durante la ejecución del proyecto.

En resumen, la gestión de riesgos en un proyecto es un proceso sistemático y planificado que implica la identificación, análisis, evaluación, mitigación, monitoreo, control, comunicación y documentación de los riesgos que pueden afectar el éxito del proyecto. Los componentes clave de la gestión de riesgos incluyen la identificación de riesgos, análisis de riesgos, evaluación de riesgos, mitigación de riesgos, monitoreo y control de riesgos, comunicación de riesgos y documentación de riesgos.

PLAN DE PROYECTO

Un plan de proyecto es un documento formal que contiene todas las decisiones de la fase de planificación, el alcance del proyecto aprobado y los costos. Aparte de las cosas mencionadas, sus principales objetivos son guiar el proceso de control, facilitar la comunicación entre las partes interesadas y programar líneas base de proyecto. Un plan elaborado también simplifica la presentación de proyecto y de su progreso en cualquier etapa.

1. Introducción, razones del problema y proyecto

Desarrollamos nuestro proyecto con el fin de satisfacer a nuestro cliente, en este caso, con remates rurales. Creamos un software especializado para su gestión, acompañado de documentación detallada y exhaustiva.

• El software permite una gestión integral de los remates rurales, desde la programación de las obras hasta la facturación final. Ofrece herramientas para la gestión de inventarios, la asignación de personal y el seguimiento de los procesos de construcción. Además, cuenta con funcionalidades para la generación de informes y análisis, lo que permite a nuestros clientes tomar decisiones informadas sobre su negocio.
• La documentación que acompaña al software es detallada y fácil de entender, lo que facilita su utilización y maximizar su potencial. Incluye manuales de usuario, guías de instalación y configuración, así como tutoriales y recursos educativos para ayudar a nuestros clientes a aprovechar al máximo el software.
• Nuestro equipo de expertos trabajó arduamente para garantizar que el software cumpliera con las necesidades específicas de nuestros clientes, y que fuera fácil de usar y adaptarse a diferentes contextos. La creación de este software representa un gran logro para nuestra compañía, y esperamos que sea útil para nuestros clientes en su día a día.

1. Trabajo y plazos a realizar

Se establecen plazos fijos es la coordinación de recursos. Si un proyecto tiene múltiples miembros del equipo trabajando en diferentes áreas, puede ser difícil sincronizar sus esfuerzos para cumplir con el plazo de entrega.

DEFINICIÓN DEL PROCESO

METODOLOGÍA

Para este software decidimos utilizar la metodología RAD.

El método RAD (Rapid Application Development) es un enfoque para el desarrollo de software que se centra en la velocidad y la eficiencia. Este método se utiliza principalmente para proyectos de software con plazos ajustados y requisitos cambiantes.

En el método RAD, se utilizan herramientas automatizadas para acelerar el proceso de desarrollo, como el modelado de procesos empresariales, la automatización de la gestión de bases de datos y la automatización de la integración de sistemas. Además, se utiliza un enfoque iterativo para construir prototipos rápidos y obtener retroalimentación temprana de los usuarios para refinar y mejorar el software.

Este método se diferencia de otros métodos de desarrollo de software, como el modelo en cascada, en que se da mayor prioridad a la retroalimentación del usuario y a la flexibilidad en lugar de seguir un proceso estricto y secuencial.

Algunas de las ventajas del método RAD incluyen una reducción significativa del tiempo necesario para desarrollar un software, una mayor satisfacción del usuario debido a la retroalimentación temprana y una mayor flexibilidad para adaptarse a los cambios en los requisitos. Sin embargo, algunas de las desventajas incluyen una posible falta de control y organización, así como la necesidad de un equipo altamente capacitado y experimentado para hacer un buen uso del método.

Para el desarrollo de la documentación y planeación del proyecto utilizamos la metodología Kanban.

El método de desarrollo Kanban es una técnica ágil para la gestión de proyectos de software que se enfoca en mejorar la eficiencia y reducir los costes. Esta metodología se basa en visualizar todo el flujo de trabajo, desde las tareas hasta su finalización, utilizando tarjetas o carteles colocados en una tabla con columnas representativas de cada fase del proceso (por ejemplo: “tareas pendientes”, “en progreso” y “terminadas”). Cada tarea se asigna a un miembro del equipo y se mueve por las diferentes fases según avanza en su ejecución. El objetivo principal de este método es lograr un flujo constante de trabajo sin sobrecargar al equipo ni bloquear ninguna tarea. Además, permite priorizar las tareas más importantes y detectar posibles problemas antes de que surjan.

CICLO DE VIDA ELEGIDO

Para el desarrollo de este proyecto utilizamos el enfoque incremental.

El modelo de construcción incremental es un enfoque del desarrollo de software donde el producto software se construye pieza por pieza, con cada nueva función o cambio añadido al código base existente. Este método implica dividir el proceso de desarrollo de software en pequeños incrementos más manejables, que luego son desarrollados, probados e integrados en el sistema principal uno a la vez.

En este modelo, el software se divide en pequeños módulos o componentes que pueden ser desarrollados independientemente entre sí. Cada módulo es diseñado, implementado y probado separadamente antes de ser integrado en el sistema completo. El proceso de integración garantiza que todos los módulos individuales funcionen juntos sin problemas para formar el producto final.

DESCRIPCIÓN DE LAS HERRAMIENTAS

Para realizar diagramas se utiliza MermaidJS y Draw.io

Una herramienta de diagramación y creación de gráficos basada en JavaScript que utiliza definiciones de texto inspiradas en Markdown para crear y modificar diagramas complejos. Su finalidad principal es ayudar a la documentación a mantenerse al día con el desarrollo.

El “Doc-Rot” es un problema común en el que la documentación y los diagramas se vuelven obsoletos rápidamente, lo que consume tiempo valioso del desarrollador y afecta negativamente la productividad y el aprendizaje dentro de una organización.

Para solucionar este problema, MermaidJS permite a los usuarios crear diagramas fácilmente modificables. Además, puede ser integrado en scripts de producción y otros códigos.

Draw.io

Permite a los usuarios crear diagramas y gráficos personalizados con facilidad, mediante una interfaz de arrastre y salto. Ofrece una amplia variedad de tipos de diagramas, como diagramas de flujo, diagramas de Gantt, diagramas de red, diagramas de secuencia, diagramas de organización, mapas mentales y muchos otros. Además, cuenta con una gran cantidad de formas y elementos visuales para personalizar tus diagramas y hacerlos únicos.

Draw.io es una herramienta muy versátil y fácil de usar, ideal para diferentes ámbitos como la gestión de proyectos, la planificación estratégica, la descripción de procesos, entre otros.

También utilizaremos Pandoc para generar PDFs. Pandoc es una herramienta de conversión de formatos de archivo de texto. Permite convertir documentos entre diversos formatos, incluyendo Markdown, HTML, PDF y Word. Además, también ofrece opciones para personalizar la apariencia del documento y agregar elementos como tablas y gráficos.

PLAN SQA

I. Propósito del Plan SQA

• El propósito de este plan SQA es establecer los procesos y prácticas necesarios para garantizar la calidad del software desarrollado por nuestra empresa. Este plan describe cómo se llevará a cabo la verificación y validación del software, así como la identificación y solución de defectos durante todo el ciclo de vida del proyecto.

2. Responsabilidades

• Las responsabilidades en materia de SQA recaerá en el equipo de pruebas, liderado por el Gerente de Calidad. El equipo de pruebas será responsable de ejecutar todas las actividades de SQA descritas en este plan, mientras que el resto del equipo de desarrollo será responsable de cumplir con los estándares de calidad establecidos.

3. Actividades de SQA Las actividades de SQA incluyen:

• Análisis de requisitos: El equipo de pruebas revisará los requisitos del usuario y creará casos de prueba basados en ellos.
• Diseño de pruebas: El equipo de pruebas diseñará pruebas para cubrir todos los aspectos críticos del software, incluyendo pruebas funcionales, de rendimiento, de seguridad y de compatibilidad.
• Ejecución de pruebas: El equipo de pruebas ejecutará las pruebas diseñadas y registrará los resultados.
• Depuración de errores: El equipo de pruebas trabaja con los integrantes que desarrollan el software para identificar y resolver problemas.
• Validación del usuario final: El equipo de pruebas se coordinará con el usuario final para realizar pruebas de aceptación y validar que el software satisfaga sus necesidades.

4. Herramientas y tecnologías

• Para apoyar las actividades de SQA, se utilizarán herramientas y tecnologías adecuadas, como herramientas de automatización de pruebas, herramientas de seguimiento de errores y herramientas de gestión de proyectos.

V. Informes de SQA

• El equipo de pruebas generará informes periódicos de SQA que describen el estado de las pruebas, los defectos encontrados y su resolución, y cualquier otra información relevante para la calidad del software.

6. Mejoras continuas

• Este plan SQA será revisado y mejorado continuamente para asegurar que siga siendo eficaz y apropiado para las necesidades cambiantes de nuestro proyecto y organización.

ESTÁNDARES DEFINIDOS Y CONVENCIONES

Estándares de Codificación:

• Utilizar un estilo de codificación consistente en todo el proyecto. Por ejemplo, los nombres de las variables sean siempre iguales, concisas sin mucho detalle.
• El código tendrá que ser auto comentado, esto significa que con solo leer la variable se entiende lo que hará sin tanto entendimiento del código.

Convenciones de Nomenclatura:

• Nombrar de manera descriptiva las funciones, clases, variables y métodos para que su propósito sea claro. Por ejemplo, utilizar nombres como “crearRemate” en lugar de abreviaturas o nombres genéricos.
• Seguir una convención de nomenclatura para archivos y carpetas que refleje la estructura del proyecto y sea fácil de entender.

Estándares de Documentación:

• Documentar los requisitos funcionales y no funcionales del software de gestión de remates rurales de manera clara y completa. Al igual que tener toda la documentación con una alineación “Justificada” y el interlineado 1,5.

Convenciones de Control de Versiones:

• Utilizar un sistema de control de versiones, como Git, para el seguimiento de cambios en el código y documentos del proyecto.
• Seguir convenciones de nombres para ramas, confirmaciones (commits) y etiquetas (tags) que sean significativas y permitan una fácil identificación.

Estándares de Diseño de Interfaz de Usuario (UI/UX):

• Diseñar la interfaz de usuario de manera intuitiva, teniendo en cuenta las necesidades de los usuarios rurales.

Estándares de Seguridad:

• Implementar medidas de seguridad, como autenticación y autorización, para proteger la información de los usuarios y garantizar la integridad de los datos.
• Realizar pruebas de seguridad regulares, como análisis de vulnerabilidades y pruebas de penetración.

Convenciones de Pruebas:

• Desarrollar casos de prueba para cada funcionalidad clave del software, incluyendo la creación de remates, registro de lotes, facturación, etc.
• Realizar pruebas de unidad, pruebas de integración y pruebas de aceptación.

Convenciones de Nomenclatura de Archivos y Estructura de Carpetas:

• Organizar los archivos y carpetas del proyecto de manera lógica y coherente, como separar el código fuente de los recursos y archivos de configuración.

Estándares de Documentación de Procesos:

• Documentar los procedimientos de uso del software de gestión de remates rurales, incluyendo manuales de usuario y manual técnico.

Convenciones de Comunicación Interna y Externa:

• Establecer canales de comunicación claros dentro del equipo y con partes interesadas externas.
• Utilizar un lenguaje y formato de comunicación adecuados para el público objetivo, que en este caso pueden ser los usuarios rurales y otros miembros del equipo.

Estos estándares y convenciones proporcionan un marco para el desarrollo y la implementación del software de gestión de remates rurales, asegurando que el proyecto sea coherente, de alta calidad y cumpla con las expectativas de los usuarios. Asegúrate de compartir y revisar regularmente estos estándares con el equipo de desarrollo para garantizar su cumplimiento.

PLAN DE TESTING

Objetivo

• El objetivo principal de este plan de testing es garantizar que nuestro software cumpla con los estándares de calidad necesarios para su lanzamiento al público. Para lograr esto, se llevará a cabo una serie de pruebas exhaustivas para identificar y corregir cualquier fallo o defecto en el software.

Alcance

• Este plan de testing abarca todas las características y funcionalidades del software, desde la navegación y visualización hasta la entrada de datos y generación de informes. También se consideran las distintas plataformas y dispositivos en los que se utilizará el software.

Metodología

• Para llevar a cabo las pruebas, se seguirá una metodología estructurada basada en los principios de testing ágil. Esto significa que se realizarán pruebas regularmente en ciclos cortos, permitiendo una retroalimentación rápida y eficiente para identificar y corregir fallos en tiempo real. Además, se utiliza una variedad de herramientas automatizadas para aumentar la cobertura de testing y reducir el tiempo necesario para realizar pruebas manuales.

Casos de Prueba

• Los casos de prueba se clasifican en tres categorías principales: funcionalidad, performance y seguridad. En la sección siguiente se describen algunos ejemplos de casos de prueba para cada categoría.

Funcionalidad

• Navegación y visualización: Verifique que los usuarios puedan navegar sin problemas por todas las páginas y visualizar correctamente los gráficos y tablas.
• Entrada de datos: Compruebe que los usuarios puedan ingresar correctamente información en los campos de texto y selectores desplegables.

Performance

• Velocidad de carga: Compruebe que todas las páginas del software se carguen en menos de 5 segundos.
• Respuesta del sistema: Verifique que el sistema responde adecuadamente a las solicitudes de los usuarios en menos de 2 segundos.
• Escalabilidad: Compruebe que el software puede manejar un volumen significativo de datos y usuarios simultáneos sin perder velocidad ni estabilidad.

Seguridad

• Autenticación: Verifique que los usuarios solo pueden acceder al software después de autenticarse con un nombre de usuario y contraseña válidos.
• Protección de datos: Compruebe que los datos de los usuarios están protegidos contra accesos no autorizados y violaciones de privacidad.

Recursos

• Se proporcionarán todos los recursos necesarios para ejecutar exitosamente las pruebas, incluyendo hardware, software, herramientas de testing automático y asistencia técnica. Conclusiones
• Con la implementación de este plan de testing riguroso y meticuloso, podemos tener confianza de que nuestro software cumplirá con los más altos estándares de calidad

PLAN SCM

Conservación de las diferentes versiones que se van generando a lo largo del desarrollo del proyecto.

Nosotros utilizamos GitHub y Drive para almacenar las distintas versiones del proyecto a la vez progresando en cada una

PLAN DE CAPACITACIÓN

Para capacitar a los diferentes usuarios del software contaremos con la presencialidad de la audiencia. Primero debemos entender como opera un remate y nuestro software, cuál es el objetivo, como proceder con los pagos, cuales son las funciones del software y sus características.

• Audiencia destinada: Este plan de capacitación está destinado a usuarios y administradores del software.

• Recursos: Para este plan de capacitación contamos con la asistencia de un técnico encargado de explicar y disipar dudas de la audiencia, también contamos contaremos con una laptop y una pantalla para explicar de forma gráfica y visualizar el software.

• Conceptos básicos de cómo opera un remate: En este apartado explicaremos qué es y cómo opera un remate para entender mejor los apartados posteriores.

• Cómo funciona el software y sus características: Este apartado está por partes diferidas destinado a por un lado usuarios (Siendo esta una versión más básica de la capacitación) y a los administradores (Una versión más extensa, en la que se explica en profundidad las diferentes opciones técnicas y funciones del software).

• Tiempo designado: La capacitación para el correcto uso del software tendrá una duración total de 1 (una) hora para usuarios y 3 (tres) horas totales para administradores.

• Métodos de pagos: Todos los métodos de pagos serán mediante tarjetas de crédito o débito, proveyendo datos de estos en el software tales como, número de tarjeta, código de seguridad, nombre y apellido del propietario de la tarjeta, número de cédula y dirección.

PLAN DE IMPLEMENTACIÓN

Plan de Implementación para la Creación de un Sistema de Gestión de Remates Rurales

Resumen:

El objetivo de este plan de implementación es describir los pasos necesarios para la creación de un sistema de gestión de remates rurales. Este sistema permitirá a los agricultores y productores rurales manejar sus remates de manera más eficiente y efectiva, mejorando la producción y la comercialización de sus productos.

Objetivos:

Desarrollar un sistema de gestión de remates rurales que permita a los agricultores y productores rurales manejar sus remates de manera más eficiente y efectiva.

Mejorar la producción y la comercialización de los productos agrícolas y pecuarios.

Incrementar la competitividad de los agricultores y productores rurales en el mercado.

Fomentar la adopción de tecnologías de información y comunicación (TIC) en el sector rural.

Análisis de Requisitos:

1. Identificar las necesidades y requisitos de los agricultores y productores rurales en cuanto a la gestión de remates.
2. Analizar las funcionalidades necesarias para el sistema de gestión de remates rurales.
3. Define las características técnicas del sistema, incluyendo la plataforma, el hardware y el software necesarios.

Diseño del Sistema:

1. Diseñar el sistema de gestión de remates rurales teniendo en cuenta las necesidades y requisitos identificados.
2. Define la estructura y la organización del sistema.
3. Seleccionar las tecnologías adecuadas para el desarrollo del sistema.

Desarrollo del Sistema:

1. Desarrollar el sistema de gestión de remates rurales utilizando las tecnologías seleccionadas.
2. Crear la base de datos necesaria para almacenar la información de los remates.
3. Desarrollar las interfaces gráficas de usuario para facilitar la navegación y el uso del sistema.
4. Integrar el sistema con otras aplicaciones y sistemas existentes, si es necesario.

Pruebas y Validación:

1. Realizar pruebas exhaustivas del sistema para asegurarse de que cumple con los requisitos y funciona correctamente.
2. Validar el sistema con un grupo de usuarios piloto para obtener retroalimentación y hacer cambios necesarios.

Implementación:

1. Implementar el sistema de gestión de remates rurales en todos los municipios seleccionados.
2. Capacitar a los usuarios sobre cómo utilizar el sistema y resolver dudas técnicas.
3. Brindar apoyo técnico y mantenimiento continuo para garantizar el buen funcionamiento del sistema.

Monitoreo y Evaluación:

1. Monitorear el desempeño del sistema y evaluar su impacto en la producción y la comercialización de los productos agrícolas y pecuarios.
2. Realizar estudios de caso para medir el éxito del sistema e identificar áreas de mejora.
3. Ajustar y actualizar el sistema según sea necesario para garantizar su continua utilidad y eficacia.

PROYECTO

ANÁLISIS

Realizamos este software para implementar un programa que sirva para gestionar de forma más simple y fácil los remates rurales, nos centramos en:

• Almacenar información sobre artículos disponibles
• Pagos a vendedores y compradores que asistan al remate
• Actividades diversas
• La gestión de empleados

Planeamos que este software tenga un sistema de roles para poder dar permisos especiales a cada uno, a la vez poder organizarse de mejor manera debido al crecimiento que este ha generado.

Al brindar esta plataforma permitirá hacer crecer al sitio de remates teniendo más oportunidades de negocio y brindando más información, a la vez poder adecuarse a la competencia actual.

La participación de clientes y empleados dentro del software también es importante a la hora de interactuar con él para realizar pagos electrónicos y acceder a información sobre los remates y participar en ellos de manera:

• Local
• Remota

En el software se podrá gestionar todo lo que necesite desde artículos hasta empleados y vendedores

DISEÑO

CASOS DE USO

NOMBRE DEL CASO DE USO

DIAGRAMA DE CASO DE USO

DESCRIPCIÓN DEL CASO DE USO (CASOS DE USO EXPANDIDO)

Nombre	ID01 - Login
Actores	Administradores, Empleado, Cliente, Vendedor
Propiedad	ALTA
Estado de desarrollo	Expandido
Extiende a
Incluye a
Pr econdiciones	Estar conectado a la base de datos.Flujo principal:1. El sistema muestra la ventana “Login”.2. El usuario rellena los campos.[Flujo alternativo A5]3. El usuario presiona el botón Iniciar[Flujo alternativo A2] [Flujo alternativo A3] [Flujo alternativo A4]4. El sistema envía los datos y los verifica
Flujo alternativo (A2)	2.1. Cancelar - Cancela, fin de caso de uso
Flujo alternativo (A3)	2.2. Modo Invitado: - El usuario presiona el “Modo Invitado” y finaliza el caso de uso.
Flujo alternativo (A4)	3.1. Los datos no son correctos: El sistema muestra el mensaje: “Datos incorrectos, vuelva a intentarlo” [regresa a flujo normal 3].
Flujo alternativo (A5)	4.1. Caracteres incorrectos: El sistema muestra el mensaje “use caracteres especiales”
Postcondiciones	Inicio de sesión exitoso.
Frecuencia de ejecución	ALTA
Notas

Fig 88 - Casos de uso expandido Login

Nombre	ID21 - Alta de artículos
Actores	Administradores, Empleado, Vendedor
Prioridad	ALTA
Estado del desarrollo	Expandido
Extiende a
Incluye a	ID01-LOGIN
Precondiciones	Estar Autentificado.Flujo Normal:1. El sistema muestra la ventana de “Dialog Artículos”.2. El usuario rellena los campos y le da al botón de guardar.3. El sistema verifica los datos [Flujo alternativo A3] y los envía a la base de datos.4. El sistema muestra el mensaje “Articulo Guardado”
Flujo alternativo (A2)	2.1. Cancelar - Cancela caso de uso.
Flujo alternativo (A3)	3.1. Los datos ingresados no son inválidos: El sistema muestra el mensaje “Caracteres inválidos” y pinta de color rojo los campos que corresponden [Flujo normal 2]
Postcondiciones	Artículo Creado con éxito
Frecuencia de ejecución	ALTA
Notas	Los campos de texto son ID, Nombre, Descripción y Precio

Fig 89 - Casos de uso expandido Alta de artículos

Nombre:	ID22 - Baja de artículos
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01-LOGIN
Precondiciones:	Estar Autentificado y la existencia de un artículo.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Artículos”. 2. El usuario presiona el botón “Eliminar” [Flujo alternativo A2].3. El sistema da una baja lógica al artículo [Flujo alternativo A3]. 4. El sistema muestra el mensaje “Articulo Eliminado”. 5. El sistema cierra la ventana.
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso
Flujo alternativo (A3):	3.1. El sistema no puede eliminar el artículo: El sistema muestra el mensaje “No se puedo eliminar el artículo” y vuelve al [Flujo normal]
Postcondiciones:	El artículo se da de baja lógica exitosamente
Frecuencia de ejecución :	BAJA
Notas:

Fig 90 - Casos de uso expandido Baja artículos

Nombre:	ID23 - Modificar artículos
Actores:	Administradores, Empleado, Vendedor
Prioridad:	MEDIA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01-LOGIN
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana de “Dialog Artículos”. 2. El usuario modifica los campos y le da al botón de guardar [Flujo alternativo A2] [Flujo alternativo A3]. 3. El sistema verifica los datos [Flujo alternativo A4] y los envía a la base de datos. 4. El sistema muestra el mensaje “Articulo Guardado”
Flujo alternativo (A2):	2.1. Cancelar - Cancela caso de uso
Flujo alternativo (A3):	3.1. Los datos ingresados no son inválidos: El sistema muestra el mensaje “Caracteres inválidos” y pinta de color rojo los campos que corresponden [Flujo normal 2]
Flujo alternativo (A4):	4.1. El sistema no pudo modificar el articulo.4.2. El sistema muestra el mensaje “No se pudo modificar el artículo”.
Postcondiciones:	Artículo modificado con éxito.
Frecuencia de ejecución:	MEDIA
Notas:	Los campos de texto son ID, Nombre, Descripción y Precio

Fig 91 - Casos de uso expandido Modificar artículos

Nombre:	ID24 - Listado artículos
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	null
Flujo Normal:	1. El sistema muestra la ventana de “Artículos”. 2. El sistema carga los artículos [Flujo alternativo A2] [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. El sistema no pudo cargar los artículos.
Flujo alternativo (A3):	3.1. Ningún artículo encontrado
Postcondiciones:	Artículo modificado con éxito
Frecuencia de ejecución :	ALTA
Notas:	Los campos de texto son ID, Nombre, Descripción y Precio

Fig 92 - Casos de uso expandido Listado artículos

Nombre:	ID25 - Alta de lotes
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Lotes”. 2. El usuario selecciona mediante el botón “Seleccionar” los artículos que quiere agregar al lote 3. El usuario presiona el botón “Crear lote” [Flujo alternativo A2].4. El sistema crea el lote y lo envía a la base de datos [Flujo alternativo A3]. 4. El sistema muestra el mensaje “Lote creado”. 5. El sistema cierra la ventana.
Flujo alternativo (A2):	2. Cancelar - Cancela el caso de uso
Flujo alternativo (A3):	3. El sistema no puede crear el lote: El sistema muestra el mensaje “No se pudo crear el Lote” y vuelve al [Flujo normal]
Postcondiciones:	El lote se crea exitosamente
Frecuencia de ejecución :	ALTA
Notas:

Fig 93 - Casos de uso expandido Alta de lotes

Nombre:	ID02 - Baja de Lotes
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado y la existencia de un lote.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Lotes”. 2. El usuario presiona el botón “Eliminar” [Flujo alternativo A2]. 3. El sistema da una baja lógica al lote [Flujo alternativo A3]. 4.El sistema muestra el mensaje “Lote eliminado”. 5. El sistema cierra la ventana.
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso
Flujo alternativo (A3):	3.1. El sistema no puede eliminar el lote: El sistema muestra el mensaje “No se pudo eliminar el lote” y vuelve al [Flujo normal]
Postcondiciones:	El lote se da de baja lógica exitosamente
Frecuencia de ejecución :	BAJA
Notas:

Fig 94 - Casos de uso expandido Baja de lotes

Nombre:	ID02 - Modificar Lotes
Actores:	Administradores, Empleado, Vendedor
Prioridad:	MEDIA
Estado del desarrollo:	Expandido
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado y la existencia de un artículo.
Flujo Normal:	1. El sistema muestra la ventana de “Dialog Lotes”. 2. El usuario modifica los campos y le da al botón de guardar [Flujo alternativo A2] [Flujo alternativo A3]. 3. El sistema verifica los datos [Flujo alternativo A4] y los envía a la base de datos. 4. El sistema muestra el mensaje “Articulo Guardado”
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana de “Dialog Artículos”. 2. El usuario modifica los campos y le da al botón de guardar [Flujo alternativo A2] [Flujo alternativo A3]. 3. El sistema verifica los datos [Flujo alternativo A4] y los envía a la base de datos. 4. El sistema muestra el mensaje “Articulo Guardado”
Flujo alternativo (A2):	2.1. Cancelar - Cancela caso de uso
Flujo alternativo (A3):	3.1. Los datos ingresados no son inválidos: El sistema muestra el mensaje “Caracteres inválidos” y pinta de color rojo los campos que corresponden
Flujo alternativo (A4):	4.1. El sistema no pudo modificar el articulo.4.2. El sistema muestra el mensaje “No se pudo modificar el artículo”.
Postcondiciones:	Artículo modificado con éxito
Frecuencia de ejecución :	MEDIA
Notas:	Los campos de texto son ID, Nombre, Descripción y Precio

Fig 95 - Casos de uso expandido Modificar lotes

Nombre:	ID04 - Listado Lotes
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	null
Incluye a:	ID01 - Login
Precondiciones:	null
Flujo Normal:	1. El sistema muestra la ventana de “Lotes”. 2. El sistema carga los Lotes [Flujo alternativo A2] [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. El sistema no pudo cargar los Lotes.
Flujo alternativo (A3):	3.1. Ningún Lotes encontrado
Postcondiciones:	Lotes modificado con éxito
Frecuencia de ejecución :	ALTA
Notas:

Fig 96 - Casos de uso expandido Listado de lotes

Nombre:	ID29 - Listado Lotes con filtro
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	ID10 - Listado Lotes
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El usuario selecciona un filtro 2. El sistema carga los Lotes correspondientes. [Flujo alternativo A4]
Flujo alternativo (A2):	2.1. Limpiar filtros - Carga los artículos de nuevo
Flujo alternativo (A3):	3.1. El sistema no pudo cargar los Lotes. 3.2. El sistema muestra el mensaje “Error de conexión, vuelva a intentarlo”
Flujo alternativo (A4):	4.1. No se encontraron Lotes para el filtro seleccionado: El sistema muestra “Error: 404”
Postcondiciones:	Artículo modificado con éxito
Frecuencia de ejecución :	ALTA
Notas:

Fig 97 - Casos de uso expandido Listado de lotes con filtro

Nombre:	ID05 - Alta de Empleado
Actores:	Administradores
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Empleados”. 2. El usuario rellena los campos. 3. El usuario presiona el botón “crear empleado”. [Flujo alternativo A2]4. El sistema crea el empleado y lo envía a la base de datos. [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	3.1. El sistema no puede crear el empleado: El sistema muestra el mensaje “No se pudo crear el Empleado” y vuelve al [Flujo normal 2]
Postcondiciones:	El lote se crea exitosamente
Frecuencia de ejecución :	ALTA
Notas:

Fig 98 - Casos de uso expandido Alta de empleado

Nombre:	ID06 - Baja de Empleado
Actores:	Administradores
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Empleados”. 2. El usuario presiona el botón “Eliminar”. 3. El sistema da de baja lógica al empleado. [Flujo alternativo A3] 4. El sistema muestra el mensaje “Empleado eliminado con éxito”. 5. El sistema cierra la ventana.
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	3.1. El sistema no puede dar de baja el empleado: El sistema muestra el mensaje “No se pudo eliminar el Empleado” y vuelve al [Flujo normal 2]
Postcondiciones:	El lote se crea exitosamente
Frecuencia de ejecución :	BAJA
Notas:

Fig 99 - Casos de uso expandido Baja de empleado

Nombre:	ID07 - Modificar Empleados
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado y la existencia de un Empleado.
Flujo Normal:	1. El sistema muestra la ventana de “Dialog Empleados”. 2. El usuario modifica los campos y le da al botón de guardar [Flujo alternativo A2] [Flujo alternativo A3]. 3. El sistema verifica los datos [Flujo alternativo A4] y los envía a la base de datos. 4. El sistema muestra el mensaje “Articulo Guardado”
Flujo alternativo (A2):	2.1. Cancelar - Cancela caso de uso
Flujo alternativo (A3):	3.1. Los datos ingresados no son inválidos: El sistema muestra el mensaje “Caracteres inválidos” y pinta de color rojo los campos que corresponden
Flujo alternativo (A4):	4.1. El sistema no pudo modificar el Empleado.4.2. El sistema muestra el mensaje “No se pudo modificar el Empleado”.
Postcondiciones:	Empleado modificado con éxito
Frecuencia de ejecución :	MEDIA
Notas:	Los campos de texto son ID, Nombre, Descripción y Precio

Fig 100 - Casos de uso expandido Modificar empleados

Nombre:	ID08 - Listado Empleado
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	null
Incluye a:	ID01 - Login
Precondiciones:	null
Flujo Normal:	1. El sistema muestra la ventana de “Empleados”. 2. El sistema carga los Lotes [Flujo alternativo A2] [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. El sistema no pudo cargar los Lotes.
Flujo alternativo (A3):	3.1. Ningún Lotes encontrado
Postcondiciones:	Lotes modificado con éxito
Frecuencia de ejecución :	Alta
Notas:

Fig 101 - Casos de uso expandido Listado empleado

Nombre:	ID13 - Alta de Remate
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	Null
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “dialog Remate” 2. EL Usuario presiona el botón “Crear Remate”. 3. El Usuario rellena los campos. 4. El usuario le da al botón “Guardar”. [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	3.1. El sistema no pudo crear el Remate: El sistema muestra el mensaje “No se pudo crear el remate”. [Flujo normal]
Postcondiciones:	Remate creado con éxito.
Frecuencia de ejecución :	Alta
Notas:

Fig 102 - Casos de uso expandido Alta de remate

Nombre:	ID14 - Baja de Remate
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	Null
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. EL sistema muestra la ventana “dialog Remate” 2. El Usuario presiona el botón “Eliminar Remate”. 3. El sistema muestra el mensaje “Quiere eliminar el Remate? Si - No”. [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	3.1. El sistema no pudo eliminar el Remate: El sistema muestra el mensaje “No se pudo eliminar el remate”. [Flujo normal]
Postcondiciones:	Remate eliminado con éxito.
Frecuencia de ejecución :	Alta
Notas:

Fig 103 - Casos de uso expandido Baja de remate

Nombre:	ID15 - Modificación de Remate
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	Null
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. EL sistema muestra la ventana “dialog Remate”2. El usuario cambia el contenido de los campos. 3. El usuario presiona el botón Guardar. [Flujo alternativo A3]
Flujo alternativo (A2):	2.1. Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	3.1. El sistema no pudo modificar el Remate: El sistema muestra el mensaje “No se pudo modificar el remate”. [Flujo normal]
Postcondiciones:	Remate eliminado con éxito.
Frecuencia de ejecución:	Media
Notas:

Fig 104 - Casos de uso expandido Modificación de remate

Nombre:	ID16 - Listado de Remate
Actores:	Administradores, Empleado, Vendedor
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:	Null
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Remate”. [Flujo alternativo A2]
Flujo alternativo (A2):	3.1. El sistema no pudo cargar el contenido: El sistema muestra el mensaje “No se pudo cargar el contenido”. [Flujo normal]
Postcondiciones:	Remate listado con éxito.
Frecuencia de ejecución:	Alta
Notas:

Fig 105 - Casos de uso expandido Listado de remate

Nombre:	ID17 - Alta de Vendedor
Actores:	Administrador, Empleado
Prioridad	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones	Estar autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Vendedor”. 2. El usuario rellena los campos. 3. El usuario presiona el botón “Guardar”. [Flujo alternativo A2] [Flujo alternativo A3]
Flujo alternativo (A2):	Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	El sistema no pudo crear al vendedor: El sistema muestra el mensaje “No se pudo crear al vendedor.”
Postcondiciones:	Vendedor creado con éxito.
Frecuencia de ejecución :	Alta
Notas:

Fig 106 - Casos de uso expandido Alta de vendedor

Nombre:	ID18 - Baja de Vendedor
Actores:	Administrador, Empleado
Prioridad	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones	Estar autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Vendedor”. 2. El usuario presiona el botón “Eliminar”. [Flujo alternativo A2] [Flujo alternativo A3]
Flujo alternativo (A2):	Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	El sistema no pudo eliminar al vendedor: El sistema muestra el mensaje “No se pudo eliminar al vendedor.”
Postcondiciones:	Vendedor eliminado con éxito.
Frecuencia de ejecución :	Media
Notas:

Fig 107 - Casos de uso expandido Baja de vendedor

Nombre:	ID19 - Modificar de Vendedor
Actores:	Administrador, Empleado
Prioridad	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones	Estar autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Vendedor”. 2. El usuario presiona el botón “Eliminar”. [Flujo alternativo A2] [Flujo alternativo A3]
Flujo alternativo (A2):	Cancelar - Cancela el caso de uso.
Flujo alternativo (A3):	El sistema no pudo eliminar al vendedor: El sistema muestra el mensaje “No se pudo eliminar al vendedor.”
Postcondiciones:	Vendedor eliminado con éxito.
Frecuencia de ejecución :	Media
Notas:

Fig 108 - Casos de uso expandido Modificar vendedor

Nombre:	ID20 - Listado de Vendedor
Actores:	Administrador, Empleado
Prioridad	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones	Estar autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Vendedor”.[Flujo alternativo A2]
Flujo alternativo (A2):	EL sistema no puede cargar los vendedores: El sistema muestra el mensaje “No se pudo cargar los vendedores.”
Postcondiciones:	Vendedor listado con éxito.
Frecuencia de ejecución :	Alta
Notas:

Fig 109 - Casos de uso expandido Listado de vendedor

Nombre:	ID09 - Alta de Comprador
Actores:	Administradores, Empleado
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Clientes”. 2. El usuario presiona el botón “crear cliente”. 3. El usuario rellena los campos. 4. El usuario presiona el switch “Vendedor”. 5. El usuario presiona el botón usuarios “Guardar” y el sistema cierra la ventana.
Flujo alternativo (A2):	2. Cancelar - Cancela el caso de uso
Flujo alternativo (A3):	3. El sistema no puede crear el Cliente: El sistema muestra el mensaje “No se pudo crear el Cliente” y vuelve al [Flujo normal]
Postcondiciones:	El cliente se crea exitosamente
Frecuencia de ejecución :	Media
Notas:

Fig 110 - Casos de uso expandido Alta de comprador

Nombre:	ID10 - Baja de Comprador
Actores:	Administradores, Empleado
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Clientes”. 2. El usuario presiona el botón “Eliminar cliente”. 3. El sistema muestra un mensaje: “Está seguro? Si - No”. [Flujo alternativo A2]
Flujo alternativo (A2):	2. Cancelar - Cancela el caso de uso
Flujo alternativo (A3):	3. El sistema no puede Eliminar el Cliente: El sistema muestra el mensaje “No se pudo Eliminar el Cliente” y vuelve al [Flujo normal]
Postcondiciones:	El cliente se crea exitosamente
Frecuencia de ejecución :	Media
Notas:

Fig 111 - Casos de uso expandido Baja de comprador

Nombre:	ID09 - Alta de Compradores
Actores:	Administradores, Empleado
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Dialog Clientes”. 2. El usuario presiona el botón “Eliminar cliente”. 3. El sistema muestra un mensaje: “¿Está seguro? Si - No”
Flujo alternativo (A2):	2. Cancelar - Cancela el caso de uso
Flujo alternativo (A3):	3. El sistema no puede Eliminar el Cliente: El sistema muestra el mensaje “No se pudo Eliminar el Cliente” y vuelve al [Flujo normal]
Postcondiciones:	El cliente se crea exitosamente
Frecuencia de ejecución :	Media
Notas:

Fig 112 - Casos de uso expandido Alta de compradores

Nombre:	ID29 - Listado de Cliente
Actores:	Administradores, Empleado
Prioridad:	ALTA
Estado del desarrollo:	Expandido
Extiende a:
Incluye a:	ID01 - Login
Precondiciones:	Estar Autentificado.
Flujo Normal:	1. El sistema muestra la ventana “Clientes”.
Flujo alternativo (A2):	2. Cancelar - Cancela el caso de uso
Postcondiciones:	Listado exitoso
Frecuencia de ejecución :	Media
Notas:

Fig 113 - Casos de uso expandido Listado de cliente

DIAGRAMA DE SECUENCIA

BASE DE DATOS

MODELO ENTIDAD RELACIÓN - MER

MODELO RELACIONAL - TABLAS

usuario(id, hash_pwd, permisos, nombre, apellido, email, telefono, departamento, localidad, calle, puerta)

empleado(ci)

tarea(id, ci_empleado, descripcion)

cliente(ci)

articulo(id, nombre, descripcion)

departamento(id, nombre)

localidad(id, id_departamento, nombre)

pago(id, ci, monto)

lote(id, nombre, precio_base, comision)

remate(id, inicio, duracion, tipo, metodos_pago)

imagenes(id_imagen, id_articulo, imagen)

integra(id_lote, id_remate, fecha)

pertenece(id_articulo, id_lote)

puja(ci_cliente, id_lote_remate, monto, momento)

vende(ci_cliente, id_articulo, monto, fecha)

propiedades(nombre)

otro(id_articulo)

animales(id_articulo, tipo, raza, nacimiento)

maquinaria(id_articulo, marca, modelo, año)

tiene(id_ otro, nombre_propiedad, valor)

atesora(id_animal, nombre_propiedad, valor)

posee(id_maquinaria, nombre_propiedad, valor)

3.2.4.3. DICCIONARIO DE DATOS

usuario
nombre	tipo	tamaño	descripción
id	INTEGER
hash_pwd	VARCHAR	256
permisos	INTEGER
nombre	VARCHAR	64
apellido	VARCHAR	64
email	VARCHAR	256
telefono	INTEGER
departamento	INTEGER
localidad	VARCHAR	64
calle	VARCHAR	64
puerta	INTEGER

Fig 120 - Diccionario de datos Usuario

empleado
nombre	tipo	tamaño	descripción
ci	INTEGER

Fig 121 - Diccionario de datos empleado

tarea
nombre	tipo	tamaño	descripción
id	INTEGER
ci_empleado	INTEGER
descripcion	VARCHAR	256

Fig 122 - Diccionario de datos tarea

cliente
nombre	tipo	tamaño	descripción
ci	INTEGER

Fig 123 - Diccionario de datos cliente

articulo
nombre	tipo	tamaño	descripción
id	INTEGER
nombre	VARCHAR	64
descripcion	VARCHAR	1024

Fig 124 - Diccionario de datos artículo

departamento
nombre	tipo	tamaño	descripción
id	INTEGER
nombre	VARCHAR	16

Fig 125 - Diccionario de datos departamento

pago
nombre	tipo	tamaño	descripción
id	INTEGER
ci	INTEGER
monto	INTEGER

Fig 126 - Diccionario de datos pago

lote
nombre	tipo	tamaño	descripción
id	INTEGER
nombre	VARCHAR	64
precio_base	INTEGER
comision	INTEGER

Fig 127 - Diccionario de datos lote

remate
nombre	tipo	tamaño	descripción
id	INTEGER
inicio	INTEGER
duracion	INTEGER
tipo	INTEGER
metodos_pago	INTEGER

Fig 128 - Diccionario de datos remate

imágenes
nombre	tipo	tamaño	descripción
id_imagen	INTEGER
id_articulo	INTEGER
imagen	BLOB

Fig 129 - Diccionario de datos imágenes

integra
nombre	tipo	tamaño	descripción
id_lote	INTEGER
id_remate	INTEGER
fecha	INTEGER

Fig 130 - Diccionario de datos Integra

pertenece
nombre	tipo	tamaño	descripción
id_articulo	INTEGER
id_lote	INTEGER

Fig 131 - Diccionario de datos Pertenece

puja
nombre	tipo	tamaño	descripción
ci_cliente	INTEGER
id_lote_remate	INTEGER
monto	INTEGER
momento	INTEGER

Fig 132 - Diccionario de datos Puja

vende
nombre	tipo	tamaño	descripción
ci_cliente	INTEGER
id_articulo	INTEGER
monto	INTEGER
fecha	INTEGER

Fig 133 - Diccionario de datos Vende

propiedades
nombre	tipo	tamaño	descripción
nombre	VARCHAR	16

Fig 134 - Diccionario de datos Propiedades

otro
nombre	tipo	tamaño	descripción
id_articulo	INTEGER

Fig 135 - Diccionario de datos Otro

animales
nombre	tipo	tamaño	descripción
id_articulo	INTEGER
tipo	VARCHAR	16
raza	VARCHAR	16
nacimiento	INTEGER

*Fig 136 - Diccionario de datos Animales *

maquinaria
nombre	tipo	tamaño	descripción
id_articulo	INTEGER
marca	VARCHAR	16
modelo	VARCHAR	16
año	INTEGER

Fig 137 - Diccionario de datos Maquinaria

tiene
nombre	tipo	tamaño	descripción
id_otro	INTEGER
nombre_propiedad	VARCHAR	16
valor	VARCHAR	64

Fig 138 - Diccionario de datos Tiene

atesora
nombre	tipo	tamaño	descripción
id_animal	INTEGER
nombre_propiedad	VARCHAR	16
valor	VARCHAR	64

Fig 139 - Diccionario de datos Atesora

posee
nombre	tipo	tamaño	descripción
id_posee	INTEGER
nombre_propiedad	VARCHAR	16
valor	VARCHAR	64

Fig 140 - Diccionario de datos Posee

LENGUAJE SQL

DDL - DATA DEFINITION LANGUAGE

DROP TABLE IF EXISTS departamento;
CREATE TABLE departamento (
    id INTEGER,
    nombre VARCHAR,
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS usuario;
CREATE TABLE usuario (
    id INTEGER,
    hash_pwd VARCHAR,
    permisos INTEGER,
    nombre VARCHAR,
    email VARCHAR,
    telefono INTEGER,
    departamento INTEGER,
    localidad INTEGER,
    calle VARCHAR,
    puerta INTEGER,
    FOREIGN KEY (departamento) REFERENCES departamento(id),
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS empleado;
CREATE TABLE empleado (
    ci INTEGER,
    FOREIGN KEY (ci) REFERENCES usuario(ci) ON DELETE CASCADE,
    PRIMARY KEY (ci)
);

DROP TABLE IF EXISTS tarea;
CREATE TABLE tarea (
    id INTEGER,
    ci_empleado INTEGER,
    descripcion VARCHAR,
    FOREIGN KEY (ci_empleado) REFERENCES empleado(ci) ON DELETE CASCADE,
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS cliente
CREATE TABLE cliente (
    ci INTEGER,
    FOREIGN KEY (ci) REFERENCES usuario(ci) ON DELETE CASCADE,
    PRIMARY KEY (ci)
);

DROP TABLE IF EXISTS articulo;
CREATE TABLE articulo (
    id INTEGER,
    nombre VARCHAR,
    descripcion VARCHAR,
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS pago;
CREATE TABLE pago (
    id INTEGER,
    ci INTEGER,
    monto INTEGER,
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS lote;
CREATE TABLE lote (
    id INTEGER,
    nombre VARCHAR,
    precio_base INTEGER,
    comision INTEGER,
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS remate;
CREATE TABLE remate (
    id INTEGER,
    inicio INTEGER,
    duracion INTEGER,
    tipo INTEGER,
    metodos_pago INTEGER,
    PRIMARY KEY (id)
);

DROP TABLE IF EXISTS imagenes;
CREATE TABLE imagenes (
    id_imagen INTEGER,
    id_articulo INTEGER,
    imagen VARCHAR,
    FOREIGN KEY (id_articulo) REFERENCES articulo(id),
    PRIMARY KEY (id_imagen)
);

DROP TABLE IF EXISTS integra;
CREATE TABLE integra (
    id_lote INTEGER,
    id_remate INTEGER,
    fecha INTEGER,
    FOREIGN KEY (id_lote) REFERENCES lote(id) ON DELETE CASCADE,
    FOREIGN KEY (id_remate) REFERENCES remate(id) ON DELETE CASCADE,
    PRIMARY KEY (id_lote, id_remate)
);

DROP TABLE IF EXISTS pertenece;
CREATE TABLE pertenece (
    id_articulo INTEGER,
    id_lote INTEGER,
    FOREIGN KEY (id_articulo) REFERENCES articulo(id) ON DELETE CASCADE,
    FOREIGN KEY (id_lote) REFERENCES lote(id) ON DELETE CASCADE,
    PRIMARY KEY (id_articulo, id_lote)
);

DROP TABLE IF EXISTS puja;
CREATE TABLE puja (
    ci_cliente INTEGER,
    id_lote_remate INTEGER,
    monto INTEGER,
    momento INTEGER,
    FOREIGN KEY (ci_cliente) REFERENCES cliente(ci),
    FOREIGN KEY (id_lote_remate) REFERENCES lote_remate(id),
    PRIMARY KEY (ci_cliente, id_lote_remate)
);

DROP TABLE IF EXISTS vende;
CREATE TABLE vende (
    ci_cliente INTEGER,
    id_articulo INTEGER,
    monto INTEGER,
    fecha INTEGER,
    FOREIGN KEY (ci_cliente) REFERENCES cliente(ci) ON DELETE CASCADE,
    FOREIGN KEY (id_articulo) REFERENCES articulo(id) ON DELETE CASCADE,
    PRIMARY KEY (fecha)
);

DROP TABLE IF EXISTS propiedades;
CREATE TABLE propiedades (
    nombre VARCHAR,
    PRIMARY KEY (nombre)
);

DROP TABLE IF EXISTS otro;
CREATE TABLE otro (
    id_articulo INTEGER,
    FOREIGN KEY (id_articulo) REFERENCES articulo(id) ON DELETE CASCADE,
    PRIMARY KEY (id_articulo)
);

DROP TABLE IF EXISTS animal;
CREATE TABLE animal (
    id_articulo INTEGER,
    tipo VARCHAR,
    raza VARCHAR,
    nacimiento INTEGER,
    FOREIGN KEY (id_articulo) REFERENCES articulo(id) ON DELETE CASCADE,
    PRIMARY KEY (id_articulo)
);

DROP TABLE IF EXISTS maquinaria;
CREATE TABLE maquinaria (
    id_articulo INTEGER,
    marca VARCHAR,
    modelo VARCHAR,
    año INTEGER,
    FOREIGN KEY (id_articulo) REFERENCES articulo(id) ON DELETE CASCADE,
    PRIMARY KEY (id_articulo)
);

DROP TABLE IF EXISTS tiene;
CREATE TABLE tiene (
    id_otro INTEGER,
    nombre_propiedad VARCHAR,
    valor VARCHAR,
    FOREIGN KEY (id_otro) REFERENCES otro(id_articulo) ON DELETE CASCADE,
    FOREIGN KEY (nombre_propiedad) REFERENCES propiedad(nombre) ON DELETE CASCADE,
    PRIMARY KEY (id_otro, nombre_propiedad)
);

DROP TABLE IF EXISTS atesora;
CREATE TABLE atesora (
    id_animal INTEGER,
    nombre_propiedad VARCHAR,
    valor VARCHAR,
    FOREIGN KEY (id_animal) REFERENCES animal(id_articulo) ON DELETE
CASCADE,
    FOREIGN KEY (nombre_propiedad) REFERENCES propiedad(nombre) ON DELETE CASCADE,
    PRIMARY KEY (id_animal, nombre_propiedad)
);

DROP TABLE IF EXISTS posee;
CREATE TABLE posee (
    id_maquinaria INTEGER,
    nombre_propiedad VARCHAR,
    valor VARCHAR,
    FOREIGN KEY (id_maquinaria) REFERENCES maquinaria(id_articulo) ON DELETE CASCADE,
    FOREIGN KEY (nombre_propiedad) REFERENCES propiedad(nombre) ON DELETE CASCADE,
    PRIMARY KEY (id_maquinaria, nombre_propiedad)
);

DML - DATA MANIPULATION LANGUAGE

Al inicializar la base de datos se debe ejecutar el siguiente comando SQL para poblar las tablas con los datos iniciales.

INSERT INTO departamento (id, nombre) VALUES
(1,'Treinta y tres'), (2,'Tacuarembó'),
(3,'Soriano'), (4,'San José'), (5,'Rocha'),
(6,'Rivera'), (7,'Rio Negro'), (8,'Paysandu'),
(9,'Montevideo'), (10,'Maldonado'),
(11,'Lavalleja'), (12,'Florida'), (13,'Flores'),
(14,'Durazno'), (15,'Colonia'),
(16,'Cerro Largo'), (17,'Canelones'),
(18,'Artigas'), (19,'Salto');

INSERT INTO usuario (id, hash_pwd, permisos, nombre, email, telefono,
departamento, localidad, calle, puerta) values (
00000000,'9A81DCCDD5D90056089C29830CE0C0EC1A7F822AA79ED024AA1F
ACB2945BD3C1:EF659DEE4993767D641D709E13232339:100000:
SHA256', 4,'SUPERADMIN','nomail\@nomail.nodomain', 092000000,
18,'Topador','De los rieles', 83);

Los datos de prueba son los siguientes:

INSERT INTO usuario(id, hash_pwd, permisos, nombre, email, telefono,
departamento, localidad, calle, puerta) VALUES
(45629664,
'9A81DCCDD5D90056089C29830CE0C0EC1A7F822AA79ED024AA1FACB2945BD3C1:EF659DEE4993767D641D709E13232339:100000:SHA256',
4,'Charlie Davis','charliedavis\@example.com', 092111111, 19,
'SALTO','Calle Los Sauces', 222),
(35769357,
'9A81DCCDD5D90056089C29830CE0C0EC1A7F822AA79ED024AA1FACB2945BD3C1:EF659DEE4993767D641D709E13232339:100000:SHA256',
3,'John Doe','johndoe\@example.com', 092123456, 18,'ARTIGAS',
'18 de Julio', 123),
(26437530,
'9A81DCCDD5D90056089C29830CE0C0EC1A7F822AA79ED024AA1FACB2945BD3C1:EF659DEE4993767D641D709E13232339:100000:SHA256',
2,'Jane Smith','janesmith\@example.com', 987654321, 18,'JAVIER
DE VIANA','Calle del Sol', 456),
(18563964,
'9A81DCCDD5D90056089C29830CE0C0EC1A7F822AA79ED024AA1FACB2945BD3C1:EF659DEE4993767D641D709E13232339:100000:SHA256',
1,'Bob Johnson','bobjohnson\@example.com', 555555555, 18,'BELLA UNION','Calle de los Rosales', 789);

INSERT INTO articulo (id, nombre, descripcion)
VALUES
(0,'Cosas','Descripcion inspiradora'),
(1,'Vacas','Descripcion inspiradora'),
(2,'Cosechadora','Lorem ipsum dolor sit amet, consectetur
adipiscing elit. Vestibulum sapien massa, convallis a, lacinia a,
aliquam id, risus. Cras ultricies ligula sed magna dictum porta. Cum
sociis natoque penatibus et magnis dis parturient montes, nascetur
ridiculus mus. Donec quis luctus tortor, vestibulum at, dignissim ac,
adipiscing nec, diam. Sed lectus. In est risus, auctor et, tristique in, tempus et, pede.');

INSERT INTO otro (id_articulo)
VALUES (0);

INSERT INTO animal (id_articulo, tipo, raza, nacimiento)
VALUES (1,'Vacas','Hereford', 1699376275763);

INSERT INTO maquinaria (id_articulo, marca, modelo, año)
VALUES (2,'John Deere','2266 Extra', 2010);

-- Cliente Table --

INSERT INTO cliente (ci)
VALUES (26437530), (18563964);

-- Empleado Table --

INSERT INTO empleado (ci)
VALUES (45629664), (35769357);

-- Tarea Table --

INSERT INTO tarea (id, ci_empleado, descripcion)
VALUES
(1, 45629664, 'Crear una nueva tabla en la base de datos'),
(2, 45629664, 'Actualizar el código fuente para que funcione con
la nueva tabla'),
(3, 45629664,'Probar las nuevas características implementadas');

-- Pago Table --

INSERT INTO pago (id, ci, monto)
VALUES
(1, 45629664, 10000), (2, 45629664, 5000), (3, 45629664, 7500);

-- Lote Table --

INSERT INTO lote (id, nombre, precio_base, comision)
VALUES
(0, 'Variedad', 599, 100),
(1, 'Más Variedad', 699, 50),
(2, 'Variedad ultra', 799, 6);

-- Remate Table --

INSERT INTO remate (id, inicio, duracion, tipo, metodos_pago)
VALUES
(0, 1000000, 10, 0, 1),
(1, 2000000, 15, 0, 2),
(2, 3000000, 20, 0, 3);

-- Imagenes Table --

INSERT INTO imagenes (id_articulo, id_imagen, imagen)
VALUES
(0, 1, '/path/to/image01.jpg'),
(0, 2, '/path/to/image02.png'),
(0, 3, '/path/to/image03.jpeg'),
(1, 4, '/path/to/image11.jpg'),
(1, 5, '/path/to/image12.png'),
(1, 6, '/path/to/image13.jpeg');

-- Lote_Remate Table --

INSERT INTO integra (id_lote, id_remate, fecha)
VALUES (1, 0, 1000000), (2, 1, 2000000), (3, 2, 3000000);

-- Articulo_Lote Table --

INSERT INTO pertenece (id_articulo, id_lote)
VALUES (0, 1), (0, 2), (0, 3);

-- Cliente_Puja Table --

INSERT INTO puja (ci_cliente, id_lote_remate, monto, momento)
VALUES (26437530, 2, 1500, 200000), (18563964, 3, 2000, 300000);

-- Cliente_Articulo Table --

INSERT INTO vende (ci_cliente, id_articulo, monto, fecha)
VALUES (26437530, 0, 750, 200000), (26437530, 1, 1000, 300000);

IMPLEMENTACIÓN

PORTE DEL PRODUCTO

Para calcular el tamaño de la base de datos debemos tener en cuenta los siguientes hechos. Cada usuario ingresado ocupa entre 46 y 814 bytes, además se deberá realizar un ingreso en la tabla empleado o cliente, registros los cuales ocupan 8 bytes cada uno, dándonos un total de entre 54 y 822 bytes. Cuando se ingresa una nueva tarea al sistema, dicha entrada emplea entre 46 y 273 bytes. Un artículo conlleva entre 10 y 1098 bytes. Cada departamento requiere entre 9 y 25 bytes, pero al ser definidos de antemano en tamaño de la tabla es constante. Cuando se registre un nuevo pago se ocuparan 24 bytes. Si se ingresa un lote entre 25 y 89 bytes serán ocupados. Ingresar un remate ocupará 38 bytes. Asignar una imagen a un lote ocupará entre 10 y 65552 bytes, dependiendo del tamaño de la imagen en cuestión. Al registrarse un nuevo animal entre 18 y 50 bytes son reservados además de lo que conlleva registrar un artículo, la misma situación ocurre con las maquinarias.

La misma información se presenta en la siguiente lista:

• Usuario: max(814) bytes min(46) bytes
• Empleado: 8 bytes
• Tarea: max(273) bytes min(17) bytes
• Cliente: 8 bytes
• Tarea: max(1098) bytes min(10) bytes
• Departamento: max(25) bytes min(9) bytes
• Pago: 24 bytes
• Lote: max(89) bytes min(25) bytes
• Remate: 38 bytes
• Imagenes: max(65552) bytes min(17) bytes
• Integra: 24 bytes
• Pertenece: 16 bytes
• Puja: 30 bytes
• Vende: 32 bytes
• Propiedades: max(17) bytes min(1) bytes
• Otro: 8 bytes
• Animales: max(50) bytes min(18) bytes
• Maquinaria: max(50) bytes min(18) bytes
• Tiene: max(90) bytes min(10) bytes
• Atesora: max(90) bytes min(10) bytes
• Posee: max(90) bytes min(10) bytes

GESTIÓN DEL PROYECTO

CONTROL DE AVANCES DE ITERACIÓN 1

ESTADO DE SITUACIÓN

Comienzo con el programa de avances en todas las materias en general

En primer lugar, es importante mencionar que el comienzo de cualquier programa de avances en todas las materias en general implica establecer claramente los objetivos y metas a alcanzar. Esto permite enfocar los esfuerzos y recursos en áreas específicas para garantizar el éxito en la implementación del programa.

• Uno de los primeros pasos que realizamos para comenzar un programa de avances en todas las materias es identificar las áreas clave que se desean mejorar. Esto incluye el aumento de la productividad y eficiencia en el trabajo.
• Una vez que se han identificado las áreas prioritarias, es necesario diseñar estrategias y planes de acción para abordarlas. Esto puede incluir la creación de programas de capacitación y desarrollo profesional, la implantación de nuevas tecnologías y herramientas, así como la promoción de la colaboración y el trabajo en equipo.
• Además, resulta fundamental tener en cuenta la importancia de la evaluación constante del progreso. Esto permitirá identificar áreas que requieren mayor atención y ajustar los planes de acción según sea necesario.

CONCLUSIONES

Llevamos un progreso básico en la documentación y programa pero con una idea buena y sólida para desarrollar mediante vamos avanzando.

RIESGOS OCURRIDOS

Ninguno.

CONTROL DE AVANCES DE ITERACIÓN 2

ESTADO DE SITUACIÓN

Desde el inicio del proyecto en agosto, se ha trabajado en la planificación y preparación de recursos para el desarrollo de tu proyecto. Esto incluye la creación de una tabla de presupuestos y la configuración de Github Actions para la conversión automática de documentos. También se ha trabajado en la actualización del logo y la migración de documentos.

• En septiembre, se ha avanzado en el desarrollo del software, con un enfoque en la programación, diseño de clases, diagramas de casos de uso y la redacción de secciones importantes del proyecto, como la misión, visión, fundamentación y más.
• Se han realizado actividades relacionadas con la gestión del proyecto, como la investigación y redacción de la gestión de riesgos, el plan de proyecto, el cronograma de trabajo y la planificación de calidad de software (SQA).
• Se ha trabajado en aspectos técnicos como el código de Arduino, el diseño de interfaz, sentencias SQL, diagramas de base de datos y el ESRE (Especificación de Requisitos de Software Externo).
• Se han realizado actividades relacionadas con la infraestructura, como el replanteo de planos del recinto ferial, la toma de fotos del local físico y el cableado estructurado.
• También se han realizado avances en el desarrollo del software, como la ventana de Categorías y el diseño de interfaces.
• En octubre, se ha continuado trabajando en el diseño de interfaces y en aspectos técnicos, como el diseño de interfaces, sentencias SQL y el ESRE.

CONCLUSIONES

En general, se ha realizado un progreso significativo en varios aspectos del proyecto, incluyendo el desarrollo de software, la gestión del proyecto y la infraestructura. Es importante seguir manteniendo un buen ritmo de trabajo y asegurarse de que todas las tareas se completen a tiempo para lograr los objetivos del proyecto.

RIESGOS OCURRIDOS

Durante el transcurso del proyecto se incurrieron en principalmente dos riesgos. Uno de ellos fue migrar la documentación a un sistema de control de versiones y utilizar Markdown y Pandoc para generar las entregas pertinentes. El segundo riesgo fue migrar a un mes de la entrega final de plataforma objetivo de Windows a Linux además de cambiar de programador principal para acelerar el desarrollo y consecuentemente descartando parte del trabajo efectuado con anterioridad. Sin embargo este último riesgo nos permitió en teoría soportar ambas plataformas con una sola librería gráfica, sin embargo no hemos realizado todavía todas las pruebas necesarias para asegurarnos que no se incurran en errores en alguna de las plataformas.