CAPITULO I
1. INTRODUCCIÓN Cualquier empresa a medida que va creciendo aumenta su volumen de información de manera proporcional, lo cual hace necesario disponer de una tecnología informática que pueda almacenar y gestionar toda la información generada por la actividad de dicha empresa. La idea principal de este proyecto surge surge como respuesta a este conflicto. El presente proyecto, ha ha sido elaborado con la visión de mostrar el plan de desarrollo del sistema a realizar, de acuerdo al proyecto de práctica de la asignatura de Sistemas de Información I de la E.F.P de Ingeniería de Sistemas de la Universidad Nacional de san Cristóbal de Huamanga. El cual nos brindara detalladamente cada fase de desarrollo del proyecto. El proyecto proyecto está basado en la metodología metodología RUP (Rational Unified Process), en la que únicamente se procederá a cumplir con las fases estipuladas por dicha metodología. Este proyecto se basa fundamentalmente en el desarrollo y la posterior implementación de una aplicación que consiste en un sistema de ventas de “accesorios de computadoras” . El objetivo principal del proyecto es cubrir todas todas las necesidades básicas de de esta aplicación de gestión. Este sistema de información generalmente tiene como funciones principales: almacenar, gestionar y organizar toda la información generada por los procesos de ventas de la empresa. Esta información está compuesta por los datos de la gestión de clave, administrador, forma de pagos, stock, almacén, clientes, facturas de cliente, cobros y pagos de facturas y contabilidad. Esta aplicación le proporciona a la empresa dos objetivos muy importantes: la competitividad y la eficacia. La mayoría de las pequeñas y medianas empresas de nuestra población, Huamanga, carecen de un tipo de software o sistema informático que les permita controlar el volumen de información que genera su su empresa, y alrededor alrededor del 20% de las que lo tienen, han optado por un software genérico de gestión que, o bien no tiene las opciones que desearían, o bien su manejo es demasiado complejo. Esto repercute directamente en los clientes de la empresa que optan por comprar en un un establecimiento donde se les proporcione rapidez en sus compras y exactitud en sus cuentas, porque las cuentas hechas a mano son poco fiables respecto a las proporcionadas por un sistema informático. Al final esto conlleva un mayor beneficio para la empresa y unos clientes más contentos. El objetivo final de esta aplicación es el desarrollo real de un Sistema de Información para una empresa de venta de “accesorios de computadoras”. Con la realización de esta aplicación se pretende explorar todas las etapas de desarrollo del ciclo de vida del software: las entrevistas
1. INTRODUCCIÓN Cualquier empresa a medida que va creciendo aumenta su volumen de información de manera proporcional, lo cual hace necesario disponer de una tecnología informática que pueda almacenar y gestionar toda la información generada por la actividad de dicha empresa. La idea principal de este proyecto surge surge como respuesta a este conflicto. El presente proyecto, ha ha sido elaborado con la visión de mostrar el plan de desarrollo del sistema a realizar, de acuerdo al proyecto de práctica de la asignatura de Sistemas de Información I de la E.F.P de Ingeniería de Sistemas de la Universidad Nacional de san Cristóbal de Huamanga. El cual nos brindara detalladamente cada fase de desarrollo del proyecto. El proyecto proyecto está basado en la metodología metodología RUP (Rational Unified Process), en la que únicamente se procederá a cumplir con las fases estipuladas por dicha metodología. Este proyecto se basa fundamentalmente en el desarrollo y la posterior implementación de una aplicación que consiste en un sistema de ventas de “accesorios de computadoras” . El objetivo principal del proyecto es cubrir todas todas las necesidades básicas de de esta aplicación de gestión. Este sistema de información generalmente tiene como funciones principales: almacenar, gestionar y organizar toda la información generada por los procesos de ventas de la empresa. Esta información está compuesta por los datos de la gestión de clave, administrador, forma de pagos, stock, almacén, clientes, facturas de cliente, cobros y pagos de facturas y contabilidad. Esta aplicación le proporciona a la empresa dos objetivos muy importantes: la competitividad y la eficacia. La mayoría de las pequeñas y medianas empresas de nuestra población, Huamanga, carecen de un tipo de software o sistema informático que les permita controlar el volumen de información que genera su su empresa, y alrededor alrededor del 20% de las que lo tienen, han optado por un software genérico de gestión que, o bien no tiene las opciones que desearían, o bien su manejo es demasiado complejo. Esto repercute directamente en los clientes de la empresa que optan por comprar en un un establecimiento donde se les proporcione rapidez en sus compras y exactitud en sus cuentas, porque las cuentas hechas a mano son poco fiables respecto a las proporcionadas por un sistema informático. Al final esto conlleva un mayor beneficio para la empresa y unos clientes más contentos. El objetivo final de esta aplicación es el desarrollo real de un Sistema de Información para una empresa de venta de “accesorios de computadoras”. Con la realización de esta aplicación se pretende explorar todas las etapas de desarrollo del ciclo de vida del software: las entrevistas
con los usuarios para la recogida de requisitos que debe cumplir el sistema, el análisis y desarrollo del sistema que vamos a modelar, la implementación mediante un lenguaje Java de la aplicación, y su posterior implantación y aceptación del sistema. La realización de esta aplicación permite una importante base conocimientos y una apertura del mundo laboral en el desarrollo de aplicaciones informáticas.
1.1. ANTECEDENTES DE LA EMPRESA “kbv<
sus consumidores la más alta calidad en sus productos y buen trato al cliente, lo confirma el creciente número de sus consumidores y la l a selecta calidad de sus proveedores. Enfrenta diversos desafíos día a día y no todo lo negativo proviene del exterior. Hay un fuerte componente de la nueva realidad: alta competencia, impacto del mercado, las nuevas conductas del cliente, el informalismo; que no se puede enfrentar con las mismas armas de antaño. Por ello hay un conjunto de acciones que son responsabilidad de la empresa de ventas de “accesorios de computadoras” puertas adentro.
Código de ética “ jgscIq” a adoptado un código d e ética que le permite promover y mantener una conducta
correcta en cada una de sus actividades con el cliente y con su personal productivo. Sembrando en el personal valores como: Honradez, Disciplina, Respeto, Servicio, Responsabilidad y Cordialidad. Éste código también les ha permitido congregar a los diferentes proveedores de productos y materias primas; equipos y tecnología, quienes han logrado intercambiar experiencias y participar juntos en la búsqueda de la optimización de todos los l os niveles de gestión y el éxito en el mercado en general.
1.2. ANALISIS DE LA PROBLEMÁTICA 1.2.1. IDENTIFICACION DEL PROBLEMA: Actualmente la empresa “ KGDAKHD ”, no cuenta con un sistema automatizado, más
bien tiene un sistema manualmente, la empresa de ventas de “accesorios de computadoras” se dedica a la atención al público y toda su información los anota en un
cuaderno, llevando así el control (de las ventas, el stock, el producto, etc.) hecho por el administrador; por ello el proceso de la venta es muy lenta ya que la generación de boleta es manual, llegando en un al colapso (concurrencia masiva de la gente) y perdiendo así clientela.
1.2.2. DESCRIPCIÓN DEL PROBLEMA
Control de ventas en forma manual
El sistema de ventas se realiza en forma manual, con el uso de boletas que son guardados por el administrador en ficheros.
Control de inventarios en forma manual. No hay un control efectivo diario de la rutinas de trabajo (ventas) que ocurren cotidianamente en la Empresa.
Tenemos problemas de “papelería”, es decir, falta optimizar
Empresa “DGUgd” Sistema “VENTAS” n o se puede responder con rapidez a
preguntas tales como:
¿Cuál es el monto de las ventas del Día?
¿Qué producto se vendió más?
¿Cuál es el stock en Inventario?
Actualmente para responder estas preguntas en promedio se toma de 1 a 2 días ocasionando problemas para consultas, reportes y sobre todo para la toma de decisiones.
1.2.3.
UBICACIÓN DEL PROBLEMA En la empresa en estudio hemos reconocido el problema en el área de ventas de acuerdo al análisis realizado en las entrevistas al administrador y al vendedor.
1.3. OBJETIVOS: 1.3.1. OBJETIVO DE LA EMPRESA La alta competencia nos permite fortalecer nuestro entusiasmo por perfeccionar al máximo la calidad de servicios de venta, en base a criterios y tecnología de información adecuados a las necesidades de la empresa.
1.3.2. OBJETIVOS DEL SISTEMA Luego de un análisis exhaustivo hemos llegado a la conclusión de que la empresa de ventas de accesorios de computadoras “ JABVFIL” no cuenta con procesos automatizados
incipientes, los cuales optimizaremos, desarrollando un nuevo software que brinden un mejor servicio a la empresa “
1.3.3. OBJETIVOS ESPECÍFICOS DEL SISTEMA
Automatizar, simplificar y controlar el registro de venta, registro de producto y generar reporte de venta.
Contar lo más rápido posible con la toda información.
Evitar la redundancia de información.
1.4. JUSTIFICACION Con el conocimiento adquirido en la carrera, y con el objetivo de colaborar con la empresa “ jhvsefjkav”, se resalta la importancia del presente documento, en el cual, se propone la
construcción de un sistema de control de ventas, que permitirá tener un control más preciso y actualizado de toda la información que circula en la empresa, siendo este proyecto de vital apoyo en la toma de decisión, planificación y la administración de la empresa.
1.5. METODOLOGIAS Y TECNICAS En método a utilizar será el proceso unificado rational (Rational Unified Process RUP) para el proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, que constituye la metodología estándar para el análisis, implementación y documentación de sistemas. Las herramientas para el desarrollo del sistema será el lenguaje de programación JAVA con base de datos PostgreSQL.
CAPITULO II
2. MARCO TEORICO 2.1. SISTEMA Llamamos sistema a la «suma total de partes que funcionan independientemente pero conjuntamente para lograr productos o resultados requeridos, basándose en las necesidades». (Kaufman).
2.2. SISTEMAS DE INFORMACION Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración dedatos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes categorías:
Personas
Datos
Actividades o técnicas de trabajo.
Recursos materiales en general (generalmente recursos informáticos y de comunicación, aunque no necesariamente).
Todos estos elementos interactúan para procesar los datos (incluidos los procesos manuales y automáticos) y dan lugar a información más elaborada, que se distribuye de la manera más adecuada posible en una determinada organización, en función de sus objetivos.
Figura 1: sistema de información 2.3. PROGRAMACION ORIENTADA A OBJETOS La programación orientada a objetos consiste en ordenar datos en conjuntos modulares de elementos de información del mundo real (denominado un dominio). Estos elementos de datos se llaman objetos. Estos datos se agrupan de acuerdo a las características principales del mundo real de estos elementos (tamaño, color, etc.).
El enfoque de objetos es una idea que se ha probado con creces. Simula fue el primer lenguaje de programación en implementar el concepto de clases en 1967. En 1976, Smalltalk implementó los conceptos de encapsulación, agrupación y herencia (los conceptos principales de la programación orientada a objetos). Por otra parte, se han implementado varios lenguajes de programación orientada a objetos a escala global.
2.3.1. CLASE En la programación orientada a objetos, una clase es una construcción que se utiliza como un modelo (o plantilla) para crear objetos de ese tipo. El modelo describe el estado y contiene el comportamiento que todos los objetos creados a partir de esa clase tendrán. Un objeto creado a partir de una determinada clase se denomina una instancia de esa clase. Una clase por lo general representa un sustantivo, como una persona, lugar o cosa. Es el modelo de un concepto dentro de un programa de computadora. Fundamentalmente, delimita los posibles estados y define el comportamiento del concepto que representa. Encapsula el estado a través de espacios de almacenaje de datos llamados atributos, y encapsula el comportamiento a través de secciones de código reutilizables llamadas métodos.
Figura 2: Clase 2.3.2. HERENCIA La herencia es uno de los mecanismos de los lenguajes de programación orientada a objetos basados en clases, por medio del cual una clase se deriva de otra de manera que extiende su funcionalidad. La clase de la que se hereda se suele denominar clase base, clase padre, superclase, clase ancestro (el vocabulario que se utiliza suele depender en gran medida del lenguaje de programación).
Figura 3: Herencia 2.3.3. OBJETO Los objetos son la clave para entender la tecnología orientada a objetos. Si mira a su alrededor ahora mismo se encontrará con muchos ejemplos de objetos del mundo real: su perro, su escritorio, su televisor, su bicicleta.
2.4. PROCESO UNIFICADO DE DESARROLLO (RUP) Es una metodología de desarrollo de software que está basado en componentes e interfaces bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Es un proceso que puede especializarse para una gran variedad de sistemas de software, en diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto. RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Es el resultado de varios años de desarrollo y uso práctico en el que se han unificado técnicas de desarrollo, a través del UML, y trabajo de muchas metodologías utilizadas por los clientes. La versión que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este proceso de desarrollo.
2.4.1. LAS CARACTERÍSTICAS PRINCIPALES DE RUP
GUIADO/MANEJADO POR CASOS DE USO La razón de ser de un sistema software es servir a usuarios ya sean humanos u otros sistemas; un caso de uso es una facilidad que el software debe proveer a sus usuarios.
Los casos de uso reemplazan la antigua especificación funcional tradicional y constituyen la guía fundamental establecida para las actividades a realizar durante todo el proceso de desarrollo incluyendo el diseño, la implementación y las pruebas del sistema.
CENTRADO EN ARQUITECTURA La arquitectura involucra los elementos más significativos del sistema y está influenciada entre otros por plataformas software, sistemas operativos, manejadores de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados y requerimientos no funcionales. Es como una radiografía del sistema que estamos desarrollando, lo suficientemente completa como para que todos los implicados en el desarrollo tengan una idea clara de qué es lo que están construyendo, pero lo suficientemente simple como para que si quitamos algo una parte importante del sistema quede sin especificar. Se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de lo demás. Todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura, recibe este nombre porque lo forman las vistas lógica, de implementación, proceso y despliegue, más la de casos de uso que es la que da cohesión a todas.
ITERATIVO E INCREMENTAL
Para hacer más manejable un proyecto se recomienda dividirlo en ciclos. Para cada ciclo se establecen fases de referencia, cada una de las cuales debe ser considerada como un mini proyecto cuyo núcleo fundamental está constituido por una o más iteraciones de las actividades principales básicas de cualquier proceso de desarrollo. En concreto RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades. En la anterior figura tenemos un ejemplo de la distribución del trabajo.
DESARROLLO BASADO EN COMPONENTES
La creación de sistemas intensivos en software requiere dividir el sistema en componentes con interfaces bien definidas, que posteriormente serán ensamblados para generar el sistema. Esta característica en un proceso de desarrollo permiten que el
sistema se vaya creando a medida que se obtienen o que se desarrollan y maduran sus componentes.
UTILIZACIÓN DE UN ÚNICO LENGUAJE DE MODELADO
UML es adoptado como único lenguaje de modelado para el desarrollo de todos los modelos.
PROCESO INTEGRADO
Se establece una estructura que abarque los ciclos, fases, flujos de trabajo, mitigación de riesgos, control de calidad, gestión del proyecto y control de configuración; el proceso unificado establece una estructura que integra todas estas facetas. Además esta estructura cubre a los vendedores y desarrolladores de herramientas para soportar la automatización del proceso, soportar flujos individuales de trabajo, para construir los diferentes modelos e integrar el trabajo a través del ciclo de vida y a través de todos los modelos. La estructura estática del proceso unificado se define en base a cuatro elementos, que son: los roles antes denominados workers, que responde a la pregunta ¿quién?, las actividades llamadas activities, que responden a la pregunta ¿cómo?, los productos llamados artifacts, que responden a la pregunta ¿qué?, y los flujos de trabajo denominados workflows, que responden a la pregunta ¿cuándo?. La definición de estos términos que se nos hace en es:
ROLES
Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el „dueño‟ de un conjunto de artefactos.
ACTIVIDADES
Una actividad de un trabajador en concreto es una unidad de trabajo que una persona que desempeñe ese rol puede ser solicitado a que realice. Las actividades tienen un
objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto.
PRODUCTOS
Un producto o artefacto es un trozo de información que es producido, modificado o usado por un proceso. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final.
FLUJOS DE TRABAJO
La mera enumeración de roles, actividades y artefactos no define un proceso, necesitamos definir la secuencia de actividades realizadas por los diferentes roles, así como la relación entre los mismos, que nos producen unos resultados observables. El RUP define varios flujos de trabajo distintos, entre los que distingue entre dos grupos, los de proceso, y los de apoyo. Las distintas iteraciones a realizar consistirá en la ejecución de estos flujos de trabajo con una mayor o menos intensidad dependiendo de la fase e iteración en la que nos encontremos.
2.4.2. FASES DE LA METODOLOGÍA RUP El RUP se divide en cuatro fases, las cuales pasaremos a ver con más detalle. En la siguiente tabla encontramos un resumen de los principales productos de RUP y en qué momento deben iniciarse y terminarse. La tabla resumen proporciona una buena visión de conjunto de lo que hay que hacer en RUP. a) Inicio: Antes de iniciar un proyecto es conveniente plantearse algunas cuestiones: ¿Cuál es el objetivo? ¿Es factible? ¿Lo construimos o lo compramos? ¿Cuánto va a costar? La fase de inicio trata de responder a estas preguntas y a otras más. Sin embargo no pretendemos una estimación precisa o la captura de todos los requisitos. Más bien se trata de explorar el problema lo justo para decidir si vamos a continuar o a dejarlo. Generalmente no debe durar mucho más de una semana. b) Elaboración: El propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. Cuando termina esta fase se llega al punto de no retorno del proyecto: a partir de ese momento pasamos de las relativamente ligeras y de poco riesgo dos primeras fases, a
afrontar la fase de construcción, costosa y arriesgada. Es por esto que la fase de elaboración es de gran importancia. En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los casos de uso críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves, bien con este prototipo, bien con otros de usar y tirar. c) Construcción: La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todas los componentes, características y requisitos, que no lo hayan sido hechos hasta ahora, han de ser implementados, integrados y testeados, obteniéndose una versión del producto que se pueda poner en manos de los usuarios (una versión beta). El énfasis en esta fase se pone en controlar las operaciones realizadas, administrando los recursos eficientemente, de tal forma que se optimicen los costes, los calendarios y la calidad. d) Transición: La finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo que típicamente se requerirá desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y usabilidad del producto. Algunas de las cosas que puede incluir esta fase son:
Testeo de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios.
Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto.
Conversión de las bases de datos operacionales.
Entrenamiento de los usuarios y técnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribución y venta.
2.5. LENGUAJE UNIFICADO DE MODELADO Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés,Unified Modeling Language) es el lenguaje de modelado de sistemas de softwaremás conocido y utilizado en la actualidad; está respaldado por el OMG(Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.
Elementos lógicos:
Clase: Descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Representación de una clase
Figura 4: Clase
Interfaz: Describe el comportamiento parcial o completo visible externamente de un elemento por medio de una colección de operaciones. Representación de una interfaz
Figura 5: Interfaz
Colaboración: Es una sociedad de roles y otros elementos que cooperan para dar un comportamiento mayor que la suma de los comportamientos de sus elementos. Representación de una colaboración
Figura 6: Colaboración
Caso de uso: Conjunto de secuencia de acciones que producen un resultado observable o de interés para un actor.
Representación de un caso de uso
Figura 7: Caso de uso
Los siguientes elementos son similares a las clases dado que describen un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Clase activa: Cuyos objetos tienen uno o más procesos o hilos en ejecución. Representación de una clase activa
Figura 8: Clase activa
Componente: Oculta todo su comportamiento tras un conjunto de interfaces externas. Representación de un componente
Figura 9: Componente Elementos físicos:
Artefacto: Es una parte reemplazable del sistema del sistema, pueden ser archivos de código fuente, ejecutables o scripts. Representación de un artefacto
Figura 10: Artefactos
Nodo: elemento que existe en tiempo de ejecución y representan un recurso computacional que generalmente tienen unidad de procesamiento. Representación de un nodo
Figura 11: Nodos
CAPITULO III
3. MARCO APLICATIVO 3.1. FASE DE CONCEPCION 3.1.1. Modelo del dominio Diagrama de clases Registrar producto Registrar venta Generar reporte de ventas
3.1.2. MODELADO DEL NEGOCIO
Requerimientos del usuario
Información oportuna y en tiempo real sobre las ventas y otras transacciones realizadas.
Informes que contengan toda la información necesaria y organizada de las ventas realizadas y de los inventarios 18periódicos que se realizan.
Remitir informes de manera precisa y exacta.
Manejo de información de forma ágil y eficiente.
Información actualizada para la realización de inventarios.
Información actualizada para la evaluación de ventas mensuales y anuales
Actores del negocio
Vendedor: es la persona encargada de realizar las diferentes ventas y reporta todo tipo de transacciones realizadas al administrador.
Cliente: Es la persona que adquiere el producto de la empresa ya sea de forma de pedido.
Administración: es el encargado de administrar el negocio, y es el administrador quien registra el producto en el sistema para luego verificar el reporte de ventas.
Casos de uso del negocio
Registrar producto: consiste en el registro de productos. El administrador se encarga de registrar los productos cada vez que le llega productos nuevos.
Registrar venta: Consiste en registrar todas las transacciones que se realizan, en el sistema para luego generar el reporte para su verificación.
Generar reporte de ventas: al final de un cierto periodo no especificado se emite reporte de ventas bajo una lista, para su posterior verificación
Modelado de casos de uso
uc Modelo de casos de u...
Solicitar producto
Verifica stock del producto
Vendedor (from Use Case Mode l)
Cliente (from Use Case Mode l) Listar productos
Registrar pedidos
Emite boleta de venta
Generar reporte
Administrador (from Use Case Mode l)
Funciones del sistema
Realizar el control de ventas e inventarios de cada producto.
Implementar una base de datos para los productos, además de un software que cumpla con los requerimientos de la empresa.
Establecer la arquitectura de información.
Emisión de reportes de ventas.
Registrar los productos nuevos que ingresa a la empresa Estas funciones de registros de productos se ven desglosadas a continuación en los siguientes módulos que son:
Módulo de registro de productos
Módulo de registro de transacción.
Módulo de registro de pedidos
Módulo de generar reportes
Diagrama de actividades Diagrama de actividades el caso de uso de registrar productos act REGISTRAR PRODUCTO
Administrador
sistema
inicio
Evalua c ampo del
Ingreso del producto
producto
Rectfica campos de
NO
si Es valido
producto
Registra producto
Fin regi strar producto
Diagrama de actividades para el caso de uso registrar venta
act DIAGRAMA DE ACTIVIDADES
Cliente
Vendedor
Registrar_Ventas
Inicial
verifica el sistema solicita producto
Ingreso del dato del producto
Selecci ona datos del producto
Clic en registrar
Si
No No esta en el stcok
Clic en registrar
final de la venta Registrar Producto
Desea otro producto? Si
No
d
Guardar el producto
Registrar otro producto
Guardar Producto
Entrega Boleta
Impresion de la boleta
Recibe Producto
Fin de la venta
Entrega el Producto
DIAGRAMA DE ACTIVIDADES PARA EL CASO DE USO GENERAR REPORTE DE LAS VENTAS act GENERAR REPORTE
Vendedor
Administrador
Inicio del reporte
contabilizar el total de la Reporte de la venta
venta
No
Rechaza
Si
Acepta Verifica el sistema
FIN DEL REPORTE
DIAGRAMAS DE ESTADOS DIAGRAMA DE ESTADO PARA ES CASO DE USO REGISTRAR PRODUCTO sd DE_Registrar_Prooducto
Inicio
Adm in istrador reci be p roducto s
Ingresando
Se valida datos del producto
P ro du ct o a ce pt ad o
Aceptado
Valida
d at os d e p ro du ct o re ch az ad o
Rechazado
FIN
DIAGRAMA DE ESTADO PARA ES CASO DE USO REGISTRAR VENTA sd DE_Registrar_v enta
Inicio
el cliente solicita el producto que requiere
Requerido
el vendedor evalua solicitud
Evaluando
si el producto esta en stock
Encontrado
comprueba si hay cantidad necesaria de producto Si el producto esta agotado
Agotado
Comprobacion
Cliente paga lo solicitado
Cancelado
Fin no hay producto
FinVenta
DIAGRAMA DE ESTADOS PARA EL CASO DE USO GENERAR REPORTE VENTA sd DE_Generar_Reporte_Venta
Inicio
conteo de boleta y di nero Contabilizando
boletas y dinero contado Contabilizado
Cuadre con las ventas OK Aceptado
Fin
DIAGRAMA DE SECUENCIA DIAGRAMA DE SECUENCIA PARA EL CASO DE USO REGISTRAR PRODUCTO
DIAGRAMA DE SECUENCIA PARA EL CASO DE USO REGISTRAR VENTA
DIAGRAMA DE CLASES class Class Mo...
Venta
Cliente
Vendedor -
cod_vendedor: int nombre_vendedor: int
Realiza 1..*
1
1
-
fecha_venta: int id_venta: int
+ +
Eli minarProdcuto() : void Generar_boleta() : void
-
1
Genera
apellido: int cod_cliente: int nombre: int
1
Emite
1..*
1
Reporte -
Realiza
canidad: int descrpcion: byte Monto_total: int
1..*
Lista_producto -
cantidad: int id_producto: int id_venta: int
1..*
Producto Tiene 1
1..* +
denominacion: varchar id_producto: int precio_unitario: int 1..* stock: in t Adicionar() : void
Pedido Tiene
* -
cantidad: int cod_pedido: int fecha_pedido: int
Modelo de objetos del negocio
3.2. CAPTURARAR
LOS REQUISITOS FUNCIONALES
Información oportuna y en tiempo real sobre las ventas realizadas.
Informes que contenga toda la información necesaria y organizada de las ventas realizadas y de los inventarios periódicos que se realizan.
Remitir informes de manera precisa y exacta.
Manejo de información de forma ágil y eficiente.
Información actualizada para la realización de inventarios.
A. Actores del negocio Secretaria.- es la persona encargada de realizar las ventas y reportar todo tipo de transacciones realizadas.
Cliente: es la persona que adquiere el producto de la empresa ya sea en forma de pedido o al contado.
Almacenero: es el encargado de corroborar la contabilidad del producto tanto en forma física, nota de pedido y reporte de almacén.
B. Casos de uso del negocio Ventas: la venta se realiza mediante la solicitud del producto que lo hace el cliente por medio de la secretaria quien emite la boleta o factura correspondiente, para que luego el almacenero entregue el producto al cliente.
Actualizar stock: una vez distribuidos los productos el encargado del almacén actualiza el inventario.
Registro de transacción: En este caso de uso se realiza el registro de ventas de los productos a través de pedidos realizados por los clientes.
Registro de pedidos: En este caso de uso se hace el registro de los pedidos realizados por los clientes para posteriormente ser remitidos al jefe de producción.
Control de acceso de usuario: El usuario ingresa su código y paswword, luego es verificado y se le asigna las actividades.
(((( LUIS SALCEDO)
realizar las Relaciones y Generalización para nuestros caso de uso osea caso de uso de ventas y actualizar stock
Funciones del sistema
Realizar el control de ventas e inventarios de cada producto.
Implementar una base de datos para los productos y clientes software que cumpla con los requerimientos de la empresa.
Establecer una arquitectura de información
Establecer la seguridad necesaria para el sistema
además de un
