Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 3 vistas

    Elaboración de Los Diagramas Del Modelo de Dominio Del Proyecto.

    Cargado por

    Datro Cc

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd

    Elaboración de Los Diagramas Del Modelo de Dominio Del Proyecto.

    Cargado por

    Datro Cc
    3 vistas16 páginas

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    DOCX, PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
    Descargar como docx, pdf o txt
    3 vistas16 páginas

    Elaboración de Los Diagramas Del Modelo de Dominio Del Proyecto.

    Cargado por

    Datro Cc

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
    Descargar como docx, pdf o txt
    de 16

    Evidencia GA2-220501093-AA2-EV01:

    elaboración de los diagramas del


    modelo de dominio del proyecto.

    Presentado por:
    Jhon Javier Cerda Castro

    ANALISIS Y DESARROLLO DE
    SOFTWARE. (2739448)
    Categoría del curso
    Formación Titulada Virtual y a
    Distancia
    Introducción
    En el dinámico mundo del desarrollo de software, la comprensión profunda y precisa de los
    requisitos del proyecto constituye el pilar fundamental para el éxito de cualquier iniciativa. Este
    documento se proyecta como un análisis exhaustivo del diagrama de clase proporcionados, que es
    una valiosa herramienta para delinear los requerimientos esenciales de un sistema destinado a la
    gestión de Inventario en la empresa Fabricación ABC. El objetivo principal de este sistema es
    abordar los problemas de gestión de inventario que la empresa ha experimentado, incluyendo
    exceso de inventario, falta de productos y falta de visibilidad en tiempo real de las existencias.

    Objetivos
    Con el fin de profundizar en el entendimiento de los requisitos del sistema y sentar las bases
    sólidas para su diseño y desarrollo, se plantean los siguientes objetivos: Establecer un marco de
    referencia claro y coherente que sirva como guía para el equipo de desarrollo a lo largo de todas
    las etapas del ciclo de vida del proyecto.

    Requisitos Funcionales
    Registro de Productos:
    1. El sistema debe proporcionar un formulario para el registro de productos que incluya
    campos para el nombre del producto, código SKU, descripción, precio, cantidad inicial,
    categoría, proveedor y fecha de ingreso.
    2. Debe validar la información ingresada para asegurar que todos los campos requeridos
    estén completos y que los datos sean del tipo correcto.
    3. El sistema debe asignar automáticamente un identificador único a cada producto
    registrado.

    Almacenamiento de Información:
    1. El sistema debe almacenar la información del producto en una base de datos segura y
    estructurada.
    2. Debe permitir la actualización de la información del producto por parte de usuarios
    autorizados.
    3. Debe mantener un historial de cambios en la información del producto para rastrear
    modificaciones y auditorías.

    Autenticación de Usuarios:
    1. El sistema debe requerir un nombre de usuario y contraseña para el inicio de sesión.
    2. Debe implementar medidas de seguridad como bloqueo de cuenta después de intentos
    fallidos y encriptación de contraseñas.
    3. Debe permitir la recuperación de contraseña y cambio de contraseña por parte del
    usuario.

    Generación de Informes:
    1. El sistema debe ofrecer una variedad de plantillas de informes predefinidas, como
    inventario actual, ventas diarias y productos más vendidos.
    2. Debe permitir a los usuarios personalizar informes y guardar configuraciones para uso
    futuro.
    3. Debe permitir la exportación de informes en varios formatos, como PDF y Excel.

    Generación de Alertas:
    1. El sistema debe monitorear los niveles de stock y generar alertas cuando un producto
    alcance el nivel mínimo establecido.
    2. Debe notificar a los usuarios sobre productos próximos a vencer con una anticipación
    configurada por el usuario.
    3. Debe permitir la configuración de alertas personalizadas basadas en criterios específicos
    definidos por el usuario.

    Control de Stock:
    1. El sistema debe actualizar automáticamente el inventario después de cada transacción de
    venta o devolución.
    2. Debe proporcionar una función de conteo de inventario físico para verificar la precisión del
    stock registrado.
    3. Debe integrar análisis de tendencias de ventas para sugerir ajustes en los niveles de stock.

    Tipos de diagramas que se pueden utilizar


    para modelar las funcionalidades del
    software.
    Diagrama de Casos de Uso:
    Este diagrama se utiliza para representar las interacciones entre los actores y el sistema,
    mostrando los diferentes casos de uso y cómo se relacionan entre sí. Es útil para comprender las
    funcionalidades del sistema desde la perspectiva del usuario.

    Diagrama de Secuencia:
    Este diagrama se utiliza para modelar la secuencia de interacciones entre los objetos del sistema a
    lo largo del tiempo, mostrando cómo se comunican entre sí para lograr un objetivo específico.

    Diagrama de Actividad:
    Este diagrama se utiliza para modelar el flujo de actividades o procesos dentro del sistema,
    mostrando las acciones que se realizan y las decisiones que se toman en cada etapa.

    Diagrama de Clases:
    Este diagrama se utiliza para modelar la estructura estática del sistema, mostrando las clases del
    sistema, sus atributos y métodos, y las relaciones entre ellas.

    Diagrama de Estado:

    Este diagrama se utiliza para modelar el comportamiento de un objeto a lo largo del tiempo,
    mostrando los diferentes estados que puede tener y las transiciones entre ellos.

    Diagrama de Flujo de Datos (DFD):

    Este diagrama se utiliza para modelar cómo fluye la información a través del sistema, mostrando
    los procesos que transforman los datos, los flujos de datos entre ellos y las entidades externas que
    interactúan con el sistema.

    Diagramas de Clases del sistema de


    gestión de inventario
    Diagramas de casos de usos del sistema de
    gestión de inventario

    Diagrama de casos de usos: Registro de Productos.


    Historia de usuario: Registro de Productos.
    Nombre de caso de uso Registro de productos

    Código CU01

    Actor Empleado

    propósito Permitir a los empleados registrar nuevos productos en el sistema.

    Precondición El empleado debe estar autenticado en el sistema.

    Postcondición El producto queda registrado para su seguimiento y gestión.

    Flujo de evento:

    1. El empleado accede a la interfaz de registro de productos.


    2. Introduce la información del producto (nombre, descripción, categoría, precio, stock).
    3. El sistema valida la información.
    4. El sistema asigna un ID único al producto.
    Flujo Alternativo: Datos del producto inválidos

    1. Datos del producto inválidos


    2. El empleado intenta registrar un producto con información incompleta o incorrecta.
    3. El sistema valida los datos y detecta el error.
    4. Se muestra un mensaje de error al empleado indicando qué información es incorrecta
    o falta.
    5. El empleado corrige los datos y vuelve a intentar el registro.

    Diagrama de actividades: Registro de Productos.


    Diagrama de casos de usos: Almacenamiento de Información

    Historia de usuario: Almacenamiento de Información


    Nombre de caso de uso Almacenar información

    Código CU03

    Actor Base de datos

    Propósito Mantener una base de datos organizada y segura con la


    información del inventario.

    Precondición Los datos deben ser validados antes de su almacenamiento.

    Postcondición Los datos quedan almacenados de manera segura y accesible.

    Flujo de evento:

    1. El sistema recibe datos para almacenar.


    2. El sistema organiza los datos en la estructura de la base de datos.
    3. El sistema asegura la integridad y seguridad de los datos.

    Flujo Alternativo: Falla en la conexión con la base de datos

    1. El sistema intenta almacenar la información en la base de datos, pero hay una falla de
    conexión.
    2. Se muestra un mensaje de error indicando que no se puede acceder a la base de datos.
    3. El sistema puede intentar reconectar automáticamente o pedir al empleado que intente de
    nuevo más tarde.

    Diagrama de actividades: Almacenamiento de Información


    Diagrama de casos de usos: Generación de Informes
    Historia de usuario: Generación de Informes
    Nombre de caso de uso Genera informe

    Código CU02

    Actor Empleado

    Propósito Crear informes detallados sobre el estado del inventario y las


    ventas.

    Precondición El empleado debe tener permisos para generar informes.

    Postcondición Se dispone de un informe para la toma de decisiones.

    Flujo de evento:

    1. El empleado solicita la generación de un informe.


    2. El sistema recopila y procesa los datos requeridos.
    3. El sistema genera el informe.
    4. El informe se pone a disposición del empleado.
    Flujo Alternativo: No hay datos suficientes para generar el informe

    1. El empleado solicita un informe para un período en el que no hay ventas o movimientos de


    inventario.
    2. El sistema intenta recopilar los datos, pero no encuentra suficiente información.
    3. Se informa al empleado que no es posible generar el informe debido a la falta de datos.
    4. El empleado puede seleccionar otro rango de fechas o revisar los criterios del informe.

    Diagrama de actividades: Generación de Informes


    Diagrama de casos de usos: Generación de Alertas:

    Historia de usuario: Generación de Alertas:


    Nombre de caso de uso Generar Alerta

    Código CU04

    Actor Sistema

    propósito Notificar a los usuarios sobre eventos críticos relacionados con el


    inventario.

    Precondición Debe existir una configuración de alertas.

    Postcondición Los usuarios están informados y pueden actuar en consecuencia.


    Flujo de evento:

    1. Se detecta un evento que requiere alerta.


    2. El sistema genera la alerta correspondiente.
    3. La alerta se envía al usuario o se muestra en el sistema.

    Flujo Alternativo: Configuración de alertas no establecida

    1. Se produce un evento que normalmente generaría una alerta, pero no se ha configurado


    ninguna alerta para ese tipo de evento.
    2. El sistema no genera ninguna alerta debido a la falta de configuración.
    3. Se notifica al administrador del sistema para que revise y configure las alertas
    adecuadamente.

    Diagrama de actividades: Generación de Alertas:

    Diagrama de casos de usos: Control de Stock:


    Historia de usuario: Control de Stock:
    Nombre de caso de uso Control de stock

    Código CU05

    Actor Sistema

    propósito Mantener un nivel óptimo de inventario y evitar desabastecimiento


    o excesos.

    Precondición Debe haber un sistema de seguimiento de inventario en tiempo


    real.

    Postcondición El inventario se mantiene dentro de los niveles deseados.

    Flujo de evento:

    1. El sistema actualiza el stock según las ventas, compras o devoluciones.


    2. El sistema utiliza análisis de tendencias para sugerir ajustes en el stock.
    Flujo Alternativo: Inconsistencia en el inventario

    1. El sistema detecta que la cantidad de stock de un producto es inconsistente con los registros
    de ventas y compras.
    2. No se puede aplicar el control de stock debido a la discrepancia.
    3. Se notifica al empleado o al administrador del sistema para que realice una auditoría o
    corrección del inventario.

    Diagrama de actividades: Control de Stock:

    También podría gustarte