Proyecto de Niurka

1.
1 Universidad Centroccidental
1.2 “Lisandro Alvarado”
Decanato de Ciencias y Tecnología
Barquisimeto – Edo. Lara
PRECA
Modelado de Negocio (Sistema de Venta al Contado)
Modelado de Negocio (Sistema de Venta al Contado) Versión: <1.0>
Sistemas II. Equipo N°: 6 Fecha: <27/10/08>
Identificación del Equipo de Desarrollo
Apellidos Nombres Cédula Observación

Villegas Guédez Isabel Cristina 17813023
Gómez Colmenarez Niurka Johanna 17782996
Oliveros Romero Glendy Milagro 17813216
Cirella Vargas Mary Emilia 15868931
Confidencial PRECA, 2019 Página 2

INDICE
Contenido Pag.
Introducción………………………………………………………………………………….. 4
Capitulo I. Dominio del Problema
1.1 Descripción general de la empresa…………………………………………….. 5
1.2 Organigramas…………………………………………………………………….. 7
1.3 Cadena de Valor………………………………………………………………….. 8
1.4 TIC que soporta los procesos de la organización…………………………….. 9
1.5 Modelado del proceso de Ventas (BPMN)…………………………………….. 10
1.6 Reglas de Negocio……………………………………………………………….. 12
1.7 Modelo Entidad Relación 1. (MER)……………………………………………... 13
1.8 Estudio de Competitividad……………………………………………………….. 15
Capitulo II. Dominio de la Solución
2.1 Propuestas de Mejora…………………………………………………………… 17
2.2 Requisitos Funcionales y No Funcionales……………………………………... 17
2.3 Plantillas de Requisitos…………………………………………………………... 19
2.4 Diagramas de Casos de Uso…………………………………………………… 25
2.5 Diagramas de Secuencia………………………………………………………… 50
2.6 Diagramas de Clases…………………………………………………………….. 64
2.7 Modelo Entidad Relación 2. (MER)……………………………………………... 69
2.8 Diagramas de Estado…………………………………………………………….. 71
2.9 Diagramas de Componentes…………………………………………………… 73
3.1 Descripción de la Interfaz………………………………………………………... 75
Conclusión………………………………………………………………………………….. 77

INTRODUCCIÓN
A través del modelado de negocio se pretende llegar a un mejor entendimiento de la

organización donde se va a implantar el sistema de software. Los principales motivos para
ejecutar este modelado son: asegurarse de que el producto será algo útil y no un obstáculo;
conseguir que se ajuste de la mejor forma posible en la organización donde se va a implantar; y
tener un marco común para el equipo de proyecto, los clientes y los usuarios finales.
La finalidad de este proyecto es mostrar un ejemplo de desarrollo de software, para la gestión

de ventas de la empresa PRECA del sector de ventas de productos para la construcción a
clientes generales. Esto por medio del modelado de negocio el cual describe como desarrollar
una visión de la organización, basado en esta visión se definen procesos, roles y
responsabilidades de la organización por medio de modelo de Casos de Uso del Negocio y los
diferentes diagramas (secuencia, clase, estados, componentes). Los artefactos del modelo de
negocio sirven como entrada y referencia para la definición de los requerimientos del sistema.

CAPÍTULO I
DOMINIO DEL PROBLEMA
1.1 Descripción General de la empresa
Preca
Es la Red de tiendas más grande y con mayor experiencia en el país, que ofrece soluciones
constructivas en materiales para la construcción y complementos (siderúrgicos, ferretería,
acabados y maderas).
Autopista vía Quibor, Kilometro 5. Barquisimeto Edo. Lara.
Visión
Ser reconocidos como la red de tiendas líder del mercado de retail de materiales para la
construcción y sus complementos en Venezuela, ofreciendo soluciones constructivas a
nuestros clientes, trabajadores y proveedores.
Misión
Clientes
Ofrecer una amplia variedad de productos de materiales para la construcción y sus
complementos, reconociendo y satisfaciendo las necesidades de cada segmento de clientes,
con la mejor relación precio = calidad en las ubicaciones geográficas que se requiera,
sintiéndonos orgullosos de brindar la mejor atención y servicio.
Trabajadores
Ofrecer oportunidades de desarrollo profesional mediante la capacitación y formación continua
en un ambiente de trabajo agradable, que propicie el sentido de pertenencia a la organización,
teniendo como directrices fundamentales la comunicación, el compañerismo, la mejora
continua y la excelencia en atención y servicio al cliente en todo el ámbito de la organización.
Proveedores
Considerarlos nuestros socios comerciales, en un ambiente de cooperación, ofreciendo
oportunidades de negocios mediante la presencia de sus productos en nuestra red de tiendas y
el cumplimiento de compromisos.

Objetivo
 Ser la empresa con las tiendas más grande y con mayor preferencia en el país, que
ofrece soluciones constructivas en materiales para la construcción y complementos
(siderúrgico, ferretería, acabados y maderas).
Planes Estratégicos
 Conseguir una meta de 5.000.000 BsF. Mensuales.

 Asistir a los principales congresos en la rama de materiales para la construcción y
complementos, para mejorar la formación y capacitación de los ejecutivos.
 Lanzar una campaña de publicidad en TV y periódicos para promocionar nuevos
productos.
 Implementar un equipo de analistas expertos en el área de la economía encargado del
estudio de los precios de los productos para ser llevados al mercado, tomando en
consideración el precio de dichos productos de la competencia, la situación económica
del país y porcentajes favorables de ganancia para la empresa.
 Ofrecer a la clientela la mejor gama de productos en cuanto a calidad y las mejores
marcas del mercado.

1.2 Organigramas
Organigrama por Departamentos
Organigrama por Cargos

1.3 Cadena de Valor
Actividades Primarias
Recepción y Distribución de los Exhibición de los Publicidad para Garantía y devolución
almacenamiento productos productos promocionar nuevos de los productos
de los productos productos
Contabilidad, Administración.
Capacitación del personal.
Soporte técnico.
Ordenes de compra.
Actividades de Soporte
Descripción General de la Cadena de Valor
 Recepción y almacenamiento de los productos: en este proceso se reciben los

productos que la empresa compra a los proveedores, y estos son almacenados
ordenadamente en el depósito de la tienda.
 Distribución de los productos: los productos que llegan a la tienda son distribuidos
según el tipo de material (hierro, madera, pintura, entre otros).
 Exhibición de productos: los productos son colocados en los mostradores de la tienda
para que estos sean visualizados por los clientes.
 Publicidad para promocionar nuevos productos: realizar campañas de publicidad a
través de los diferentes medios de comunicación (prensa, vallas, TV) para promocionar
los nuevos productos ofrecidos por la empresa.
 Garantías y devoluciones: la empresa ofrece a sus clientes garantías desde el
momento de la compra y/o entrega de los productos.

1.4 TIC que soporta los procesos de la organización
 El uso de INTRANET que permite comunicar la información de la compañía a los

empleados con efectividad, consiguiendo que estos estén permanentemente informados
con las últimas novedades y datos de la organización.
 SOFTWARE creado por la empresa PRECA, S.A. para llevar a cabo las actividades y
operaciones que se realizan en ésta.
 Uso de línea telefónica con extensiones para comunicarse con los distintos
departamentos que componen la empresa.
 Lectores ópticos que facilitan la realización de facturas minimizando el tiempo del
proceso de venta.

1.5 Modelado de los Procesos de Ventas

PLANTILLA PARA DESCRIBIR PROCESOS DE NEGOCIO

Nro.: 01 Nombre del Proceso: Ventas Actual: X
Mejorado:
Objetivo: Modelar el proceso de ventas al contado de la empresa.
Descripción: El modelo especifica los pasos que se llevan a cabo para realizar una venta,
contiene los actores que intervienen en dicho proceso así como las acciones que realizan los
mismos.
Indicadores: Responsable: Gerente de Ventas
Subprocesos: Procesos Relacionados:
Roles: Vendedor, cliente, despachador, caja, Nivel del Proceso: Medular

verificador.
Entradas: Salidas:
- Pedido de productos por parte del cliente. - Productos solicitados.
- Pago de la factura. - Factura sellada y firmada.
Actividades (Detalladas):
1.- El cliente realiza el pedido de los productos de su interés.
2.- El vendedor recibe el pedido realizado por el cliente.
3.- El vendedor verifica la existencia de los productos solicitados.
- Si la existencia del producto es cero, no se realiza la venta.
- Si la existencia del producto es parcial.
3.1.- El vendedor notifica al cliente acerca de la cantidad de producto disponible.
- Si el cliente no accede a la compra de la cantidad de producto disponible, se cancela la
venta.
- Si la existencia es mayor a la cantidad requerida del producto, o el cliente accede a la
compra cuando la existencia es parcial.
3.2.- El vendedor realiza la factura del pedido requerido por el cliente.
4.- La factura es enviada a caja por el vendedor.
5.- La caja recibe la factura que se le ha sido enviada.
6.- La caja solicita al cliente el pago del total de la venta.
7.- El cliente entrega a caja el pago de la factura.
8.- El pago es recibido por la caja.
9.- La factura es sellada por la caja, como garantía de haber sido pagada.
10.- La caja entrega al cliente la factura sellada.
11.- El cliente obtiene la factura sellada.
12.- La factura sellada es proporcionada por el cliente al despachador.
13.- El despachador busca los productos especificados en la factura sellada.
14.- La factura sellada es firmada por el despachados, garantía de la entrega de los productos.
15.- Tanto la factura sellada y firmada así como los productos son entregados por el
despachador al cliente.
16.- El cliente recoge los productos y la factura firmada y sellada.
17.- Los productos y la factura firmada y sellada son facilitados al verificador.
18.- El verificador toma los productos, la factura firmada y sellada.
19.- Los productos son verificados con los datos contenidos en la factura firmada y sellada.
20.- El verificador perfora la factura sellada en conformidad con la verificación.
21.- La factura sellada, firmada y perforada es entregada al cliente junto con los productos.
22.- El cliente acepta los productos así como la factura firmada, sellada y perforada.

Modelado del Proceso con BPMN: Ver pagina anterior

1.6 Reglas de Negocio
 Un cliente que factura de 5000 a 150000 BsF. constantemente durante el año

se le asigna un código como cliente exclusivo.
 A los clientes exclusivos se les aplica un descuento del 20% en sus compras.
 Para el proceso de devolución de algún material o equipo por parte del cliente,
el mismo debe consignar la factura en buen estado, el material a devolver no
debe haber sido usado y solo se hace el cambio por otro material ya que no se
devuelve el dinero.
 Los clientes que cancelan su compra con Cheque no se les entrega los
productos hasta que el cheque sea conformable.
 La materia prima que llega a la empresa es administrada y distribuida de
manera tal que todos los clientes puedan obtener el producto, evitando así la
compra masiva del material por parte de un solo cliente.
 El cliente recibe al momento de la cancelación de su compra solo una factura,
pero el mismo puede poseer varias facturas de compras pasadas.
Objeto de negocio:
 Cliente: Es la persona interesada en adquirir algún producto o material
ofrecido por la empresa.
 Factura: Es el documento impreso que certifica la compra por parte del cliente.
 Producto: Es el articulo de interés que el cliente solicita.
 Empleado: Son las personas encargadas de tomar el pedido y realizar la
factura.
 Caja: Sitio donde el cliente cancela la factura.

1.7 Modelo Entidad Relación 1. (M.E.R)

Base de Datos
Empleado Cliente Factura
 NomEmpl  NomCli  NumFact (*)
 CedEmpl  CedCli (*)  FechEmisión
 CodEmpl (*)  TipoCliente  TotalIVA
 Cargo  DireCli  Montotal
 DirecEmpl  CodCiu  CodCaja
 CodCiu  FechaI  CodEmpl
 Estatus  CedCli
 Estatus
Tlf/Empleado Tlf/Cliente TipoCliente
 CodEmpl (*)  CedCli (*)  NombTipo
 TlfEmpl (*)  TlfCli (*)  CodTipo (*)
Ciudades Caja Producto
 NomCiu (*)  CodCaja  Descripción
 CodCiu  VentotalDia  CodProd (*)
 CodArea  CodEmpl  CodTipo
 Estatus  Existencia
 UltCosto
 CostoPro
 Stop mínimo
 Stop máximo
 Status
 CodIva
 PVP1
 PVP2
ProdFact TipoProducto IVA
 NumFact (*)  NomProd  CodIVA (*)
 Descripción
 CodProc (*)  CodTipo (*)
 Porcentaje
 CantXProd (*)
(*) = Clave primaria.
1.8 Estudio de Competitividad

Salidas No deseadas o Necesidades de Información no satisfechas:

 Necesidad de respaldo de documentos de devoluciones (facturas) a través de la
digitalización de las mismas.
Causas potenciales las salidas no deseadas o necesidades de información no

satisfechas:
 El departamento encargado de crear el software manejado por la empresa no
consideró la digitalización para el respaldo de los documentos de devoluciones.
Oportunidades de mejoras:
 Modificación y actualización en el sistema implementado por PRECA el cual
permita respaldar los documentos de devolución a través de la digitalización.
Competidores:
Los competidores de la empresa PRECA son aquellas empresas que basan su

actividad económica en la venta de productos y materiales para la construcción, entre
ellas se pueden nombrar: EPA, MIGO, IMECA, entre otros.
Oportunidades que se encuentran en el entorno:
 Desarrollo de mercado en el territorio nacional.

 Promoción y venta de nuevos productos.
 Participación en asociaciones gremiales para desarrollar practica cooperativas.
 Participación en diversas conferencias, congresos y demás actividades que
fortalezcan la capacitación del personal de la empresa con énfasis en tecnología.
Amenazas que se encuentran en el entorno:
 Escasez de recurso humano.

 No establecer acuerdos, convenios con los distintos proveedores.
 Los empleados encargados de la asistencia técnica se encuentran establecidos en
la central (Casa Matriz).

Fortalezas que tiene la organización:
 Productos diferenciados, ya que la empresa solo ofrece a la venta productos

exclusivos para la construcción.
 Los productos que la organización brinda son de buena calidad y de
reconocimiento nacional e internacional.
 La empresa ofrece una excelente atención al cliente con la finalidad de satisfacer
sus necesidades y otorgar la mayor información posible acerca de los productos
que vende la empresa.
 Clasificación de los empleados en las distintas áreas de la empresa dependiendo
de las capacidades que este posea.
 Posee un sistema propio diseñado por el departamento de informática de la
empresa con la finalidad satisfacer sus necesidades.
Debilidades que tiene la organización:
 Las facturas de las devoluciones que se realizan en la empresa son archivadas de

manera manual, generando riesgo en la perdida y/o daño de estos documentos.
TIC que pueda soportar los procesos dentro de la organización:
Digitalización de toda la información asociada a los documentos de devolución.
Propuesta de Solución
Debido a que no se encontró divergencia entre los objetivos, los planes estratégicos
de la organización y la realidad de la empresa se concluye que en la misma, no
existen problemas relevantes en cuanto al sistema que esta posee y maneja para las
distintas operaciones que se llevan a cabo.
El sistema actual no cuenta con la opción de modificación de las facturas de aquellas

devoluciones de mercancía que se realizan en la empresa; es por esto, que se
propone la modificación del sistema en cuanto a esta necesidad insatisfecha al incluir
en el mismo esta opción y otras necesarias para el manejo y consulta de dicha
información.

CAPÍTULO II
DOMINIO DE LA SOLUCIÓN
2.1 Propuesta de Mejoras
Se propone el agregar al sistema la opción de gestionar las facturas devueltas, al

introducir el código de la factura a devolver el sistema carga los datos de la misma
activando campos opcionales que permitan seleccionar los productos que van a ser
devueltos de dicha factura; automáticamente el código de estos productos se cargan
en una tabla (ProdDevuelto) la cual contendrá el número de la devolución y la cantidad
devuelta; la fecha de devolución, el número de factura y el número de la devolución se
almacenaran en otra tabla llamada (FactDevuelta). Estos datos se almacenarán para
posteriores consultas (estadísticas, reportes, entre otros).
2.2 Requisitos funcionales y no funcionales.
 Funcionales:
1. El sistema deberá registrar, modificar y consultar la información de los clientes.

2. El sistema deberá registrar, eliminar, modificar y consultar la información del
empleado.
3. El sistema deberá registrar, eliminar y consultar a cada caja.
4. El sistema deberá emitir un reporte de las ventas diarias de cada caja.
5. El sistema deberá permitir registrar, eliminar, modificar y consultar cada producto.
6. El sistema deberá registrar las facturas de cada Venta realizada.
7. Emitir original y copia de las facturas.
8. El sistema deberá permitir gestionar las facturas devueltas.
9. El sistema deberá permitir consulta reportes de las facturas de devolución.
10. El sistema deberá validar sus usuarios.

Requisitos No funcionales:
1. El sistema deberá tener un tiempo de respuesta no mayor a 5 segundos.

2. El computador deberá tener instalado una impresora multifuncional (copia,
escáner, impresión).
3. El sistema deberá ser realizado bajo lenguaje de programación Visual Basic 6.0,
en sistema operativo Windows.
4. El sistema deberá trabajar en un servidor con una capacidad mínima de memoria
RAM 128Mb, Disco Duro 40 Gb.
5. El sistema debe permitir la conexión por intranet entre los distintos computadores
que se encuentran en la empresa.
6. El sistema deberá ser de fácil manejo y entendimiento para los usuarios.
7. El sistema deberá proporcionar una aplicación de soporte técnico, el cual sirva de
ayuda al usuario al momento de presentarse una falla.

PLANTILLA PARA ESPECIFICAR REQUISITOS

Nro.: 01 Nombre del Requisito: Gestión de clientes Tipo: Cliente
Descripción:
El sistema deberá permitir el registrar, consultar la información de los clientes: nombre, dirección,
fecha de ingreso, teléfono y tipo de cliente; así como deberá permitir el modificar dirección, teléfono
del cliente y tipo de cliente.
Detalles y Restricciones:
El sistema deberá permitir la modificación del tipo de cliente ya que se dividen en clientes comunes y
clientes exclusivos. A los clientes exclusivos se les hace un descuento del 20% del total de la venta.
Quién lo solicitó: Gerente de venta
Estado: Aprobado
Obligatorio: X Opcional: Versión de Entrega:

Nro.:02 Nombre del Requisito: Gestión de Empleados Tipo: Empleado
Descripción:
El sistema deberá realizar el registro, consulta, eliminación de los datos de los empleados: nombre,
código, dirección, teléfono, clave de usuario, cargo, estatus. Deberá permitir la modificación de la
dirección, teléfono, cargo, estatus.

Para poder eliminar un empleado el sistema debe verificar que el usuario sea el gerente.

Estado: Aprobado


Nro.: 03 Nombre del Requisito: Gestión Caja Tipo: Caja
Descripción:
El sistema deberá registrar y consultar la información de las cajas: código de la caja y empleado a
cargo. Así como modificar solo la información del empleado a cargo. El sistema deberá emitir un
reporte diario de las ventas totales del día.

Al momento de la consulta el sistema deberá mostrar el resumen del total cancelado en esa caja en
un determinado momento. Se podrá modificar la información del empleado solo si ha culminado el
tiempo estipulado de trabajo diario (8 horas). Para poder eliminar el sistema deberá verificar el usuario
que va a hacer uso de esa aplicación ya que la persona autorizada para dicha acción es el Gerente.
Estado: Aprobado

Nro.: 04 Nombre del Requisito: Reporte de Caja. Tipo: Caja
Descripción:
El sistema deberá generar un reporte, permitir consultar e imprimir la información de dicho reporte: código de la
caja, empleado a cargo, total cancelado en esa caja. Deberá permitir eliminar cada reporte generado de cada caja.

Estos reportes se emiten diariamente al terminar la jornada de trabajo. Al momento de la eliminación en lote de los
reporte, deberá tomar en cuenta el periodo estimado acordado por el Gerente (1 año).
Estado: Aprobado

Nro.: 05 Nombre del Requisito: Gestión de Productos Tipo: Productos
Descripción:
El sistema deberá permitir registrar, eliminar, consultar la información referente a los productos, como la
descripción, código, existencia, costo, status, tipo de producto, último costo, código del IVA, stock
mínimo, stock máximo, PVP1, PVP2. Debe permitir la actualización de la existencia, stock mínimo, stock
máximo, costo, último costo, el PVP de los productos y el IVA.

Los productos no se pueden eliminar si la existencia es distinta de cero. Los productos están
organizados por dos tipos, los productos siderúrgicos y los de ferretería.

Estado: Aprobado


Nro.: 06 Nombre del Requisito: Gestión de Facturas de Ventas Tipo: Caja
Descripción:
El sistema deberá registrar, consultar y modificar los datos de cada venta en un formato (Factura) y
almacenar los mismo en una tabla (Facturas); los datos son: fecha de la venta, código de los productos
vendido, cantidad de cada producto, precio, total IVA, total así como la cedula, el nombre, dirección y
teléfono del cliente a quien se le realizo la venta y código del empleado que realizo dicha venta.
Las ventas serán anuladas si el cliente después de haber terminado el registro de la misma decide no
llevar a cabo dicha venta, al haber algún error en la venta ya facturada, se modificará solo el estatus de la
factura siempre y cuando el usuario sea valido.

Estado: Aprobado

Nro.: 07 Nombre del Requisito: Emisión de Facturas Tipo: Caja
Descripción:
El sistema deberá realizar la emisión de la factura que evidencia la venta realizada.

La emisión de la factura se debe hacer en original y copia; ya que el original es dado al cliente y la
copia es archivada por la empresa para llevar así un control de las ventas.
Estado: Aprobado


Nro.: 08 Nombre del Requisito: Gestión de Facturas de Devolución Tipo: Caja
Descripción:
El sistema deberá permitir registrar los productos y facturas devueltas así como también consultar y
eliminar dichas facturas.

Al realizar la devolución el sistema deberá cargar automáticamente los datos de la factura y activar
campos opcionales que permitan seleccionar los productos que van a ser devueltos de dicha factura;
automáticamente el código de estos productos se cargan en una tabla (ProdDevueltos) la cual
contendrá el número de la devolución y la cantidad devuelta; la fecha de devolución, el número de
factura y el número de la devolución se almacenaran en otra tabla llamada (FactDevuelta).
Al momento de eliminar los reportes el sistema debe verificar que el usuario que vaya a realizar esta
acción sea el Gerente. La eliminación de estos reportes se realiza periódicamente en lapsos de 1 año.
Estado: Aprobado



Nro.: 09 Nombre del Requisito: Reporte de Facturas de devolución Tipo: Caja
Descripción:
El sistema deberá permitir la consulta de reportes de las facturas de aquellas ventas que han sido
devueltas mostrando el número de la devolución, código de la factura, fecha de la devolución y el cliente
al que pertenece la factura.

Los productos deben aparecer por orden de fechas de devolución.

Estado: Aprobado
2.4 Diagrama de Casos de Uso
Actores:
Nro.: 10 Nombre del Requisito: Validación de claves de usuario Tipo: Usuario
Descripción:
El sistema debe autentificar las claves de los usuarios con la finalidad de proporcionarles la información y
aplicaciones de las que pueden hacer uso.

El empleado no puede tener la misma accesibilidad que el gerente.

Estado: Aprobado
 Empleado
 Gerente de Ventas
 Cliente
Casos de Uso
 Gestión de Cliente
 Gestión de validación de usuarios
 Gestión de Empleados
 Gestión de Caja
 Reporte de Caja
 Gestión de Productos
 Gestión de facturas de ventas
 Emisión de Facturas
 Gestión de Facturas de Devolución
Diagrama de Paquetes

Nombre Validar clave de usuario
Descripción El sistema valida la clave del usuario.
Actor(es) Usuario
Tipo
Curso Normal Acción del Actor: Acción del Sistema:

2. Busca la clave introducida
Esta Use case se inicia cuando: en la tabla Empleados en la
1. Introduce la clave. base de datos.
3. Si la encuentra, permite el
acceso al sistema.
4. Fin de la Use Case.
Curso Alterno 3. Si no la encuentra, muestra

un mensaje “Usuario no
valido”, retorna al paso nº 4.
Pre-condición Usuario Valido
Post-condición Usuario validado
Nombre Registrar Cliente
Descripción El empleado registra los datos del cliente.

Actor(es) Empleado.
Tipo

Esta Use case se inicia: 2.- Busca la cédula en la tabla
clientes de la base de datos.
1.- El empleado tipea la cédula del 3.- Si la cédula no se encuentra,
cliente. muestra la planilla de registro.
4.- El empleado introduce los datos 5.- Almacena la planilla en la
del cliente en la planilla. base de datos.
6.- Fin de la Use Case.
Curso Alterno 3.- Si la cédula se encuentra,

se muestra la información del
cliente, y retorna al paso n° 6.
Pre-condición Usuario Válido.
Post-condición Cliente registrado.

Nombre Consultar Cliente
Descripción El empleado podrá consultar los datos de los clientes registrados.
Actor(es) Empleado
Tipo
Esta Use case se inicia cuando: 2. Busca la cédula introducida en la tabla

1. El empleado introduce la cédula Clientes en la base de datos.
del cliente. 3. Si la cédula es encontrada, se muestran
los datos correspondientes a ese cliente.
Curso Alterno 3. Si la cédula no se encuentra en la tabla

de Clientes, se envía un mensaje (cliente
no existe), y retorna al paso n° 4.
Post-condición Cliente consultado

Nombre Modificar cliente
Descripción El empleado modifica información acerca del cliente.
Actor(es) Empleado
Tipo
Curso Acción del Actor: Acción del Sistema:

Normal
Esta Use Case se inicia cuando: 1. Activa los campos que se pueden modificar.
2. El empleado introduce los datos 3. Cambia la información de los datos del
en los campos de la información del cliente en la Tabla Clientes de la base de datos.
cliente que desea modificar. 4. Almacena los datos introducidos por el
empleado en la Tabla Clientes en la base de
datos.
5. Envía un mensaje de “Modificación exitosa”
Curso
Alterno
Pre- Usuario valido.

condición
Post- Dato(s) de cliente modificados.

condición
Nombre Registrar empleado

Descripción El gerente registra los datos del empleado
Actor(es) Gerente
Tipo
Esta Use Case inicia cuando: 2. Busca el código introducido en

1. El gerente tipea el código del la tabla de Empleados en la base
empleado. de datos.
4. El gerente Introduce los datos del 3. Si no la encuentra, muestra la
empleado. planilla de registro.
5. Almacena los datos en la tabla
de Empleados.
6. Muestra mensaje de “Registro
realizado”.
7. Fin de Use Case.
Curso Alterno 3. Si la cedula se encuentra, se

muestra la información del empleado,
retorna al paso n° 7.
Post-condición Empleado Registrado
Nombre Consultar Empleado
Descripción El gerente podrá consultar los datos del empleado.
Actor(es) Gerente
Tipo
Esta use Case se inicia cuando: 2. Busca el código introducido en la

tabla de Empleados en la base de
1. El gerente introduce el código del datos.
empleado que desea consultar. 3. Si el código se encuentra, se
muestran los datos correspondientes
al empleado.
4. Fin de Use Case.
Curso Alterno 3. Si el código no se encuentra en la

tabla de Empleado, se envía un
mensaje “El Empleado no existe”,
Post-condición Empleado consultado

Nombre Eliminar Empleado
Descripción El gerente podrá cambiar estatus del empleado.
Actor(es) Gerente
Tipo
Esta Use case se inicia cuando: 2. Verifica el campo de estatus en la

1. El gerente teclea al botón de tabla Empleados de la base de
eliminar datos.
4. El gerente escoge la opción 3. Si el estatus es activo, muestra
deseada. mensaje de confirmación para
eliminar.
5. Si la opción escogida es
afirmativa, cambia el estatus de
activo a inactivo en la Tabla
Empleados de la base de datos.
6. Almacena el cambio realizado en
la Tabla de Empleados.
7. Muestra un mensaje “Empleado
Eliminado”
8. Fin de Use Case.
Curso Alterno 5. Si la opción escogida es negativa,

no hace ningún cambio, y se retorna
la paso n° 8.
Post-condición Empleado eliminado

Nombre Modificar Empleado
Descripción El gerente podrá hacer modificaciones en los datos del empleado.
Actor(es) Gerente
Tipo
Esta Use case se inicia cuando: 1. Activa los campos que se pueden
2. El gerente introduce los datos que modificar.
desea modificar. 3. Cambia los datos introducidos por
el gerente en los campos de la Tabla
Empleados de la base de datos.
4. Almacena los datos del empleado
en la tabla de Empleados de la base
de datos.
5. Muestra un mensaje “Modificación
exitosa”.
6. Fin de Use Case.
Curso Alterno
Post-condición Empleado modificado
Nombre Registrar Caja
Descripción El gerente podrá registrar los datos de la caja.
Actor(es) El gerente
Tipo
Esta Use Case se inicia cuando: 2. Busca el código introducido en la

1. El gerente tipea el código de la tabla de Cajas de la base de datos.
caja. 3. Si el código no es encontrado,
4. El gerente introduce los datos de muestra la planilla de registro de
la caja. caja.
5. Almacena los datos introducidos
en la Tabla Cajas de la base de
datos.
6. Muestra mensaje “Se registro con
éxito”.
7. Fin de Use Case.
Curso Alterno 3. Si el código de caja es

encontrado, muestra un mensaje
“Caja ya registrada”, se retorna al

paso n°7.
Pre-condición Usuario Valido.
Post-condición Caja registrada.
Nombre Consultar Caja
Descripción El gerente podrá consultar los datos de la caja.
Actor(es) Gerente
Tipo

tabla Cajas de la base de datos.
1. El gerente introduce el código de la 3. Si el código se encuentra, se
caja a consultar. muestran los datos de la caja.
4. Fin de Use Case.

base de datos, se muestra un
mensaje “Caja no registrada”, se
Post-condición Caja consultada.

Nombre Eliminar Caja
Descripción El gerente podrá cambiar el estatus de la caja.
Actor(es) Gerente
Tipo

1. El gerente pulsa la opción de tabla Cajas.
eliminar 3. Si el estatus es habilitada, muestra
4. El gerente escoge la opción mensaje de confirmación para
deseada eliminar.
5. Si la opción es afirmativa, cambia
el estatus de habilitada a
deshabilitada.
6. Almacena el cambio realizado.
7. Muestra mensaje “Caja eliminada”
8. Fin de Use Case.
Curso Alterno 5. Si la opción es negativa, no hace

ningún cambio, retorna al paso n° 8.
Post-condición Caja eliminada.

Nombre Modificar Caja
Descripción El gerente podrá hacer modificaciones en los datos de la caja.
Actor(es) Gerente
Tipo
desea modificar. 3. Cambia los datos introducidos en
los campos en la Tabla Cajas de la
base de datos.
4. Almacena los datos de la caja en
la tabla Cajas de la base de datos.
5. Muestra mensaje “Caja
Modificada”
6. Fin de Use Case.
Curso Alterno
Post-condición Caja modificada

Nombre Consultar Reportes
Descripción El gerente podrá consultar los reportes emitidos por el sistema.
Actor(es) Gerente.
Tipo

Esta Use case se inicia:
2. Busca los datos del reporte que el
1. El gerente solicita la emisión del gerente solicitó.
reporte tipeando la fecha y código de 3. Si lo consigue, muestra los datos
la caja que desea consultar. de dicho reporte.
4. Fin de Use Case.
Curso Alterno 3. Si los datos tipeados no se

consiguen, el sistema mostrará un
mensaje de error y se retornará al paso
n° 4.
Post-condición Cliente registrado.

Nombre Eliminar Reportes
Descripción El gerente podrá eliminar los reportes emitidos por el sistema.
Actor(es) Gerente.
Tipo

Esta Use case se inicia:
2. Verifica si el período ya ha
1. El gerente elige la opción de culminado.
eliminar los reportes. 3. Si ha culminado, muestra un
4. Elije la opción deseada. mensaje de confirmación.
5. Si la opción es afirmativa elimina
del sistema el conjunto de reportes del
período.
6. Muestra un mensaje de
confirmación.
7. Fin de Use Case.
Curso Alterno 3. Si no ha culminado el período,

muestra mensaje “Período no ha
culminado”, retorna al paso n° 7.
5. Si la opción es negativa, se cancela
la operación y retorna al paso n° 7.
Post-condición Factura eliminada.
Nombre Registrar Producto

Descripción El gerente registra los datos del producto
Actor(es) Gerente
Tipo
Esta Use Case inicia cuando: 2. Busca el código introducido en

1. El gerente tipea el código del la tabla Productos en la base de
producto. datos.
4. El gerente Introduce los datos del 3. Si no la encuentra, muestra la
producto. planilla de registro.
5. Almacena los datos en la tabla
Productos.
6. Muestra mensaje “Producto
registrado con éxito”.
7. Fin de Use Case.
Curso Alterno 3. Si el código se encuentra, se

muestra la información del producto,
y retorna al paso n° 7.
Post-condición Producto Registrado
Nombre Eliminar Producto
Descripción El gerente podrá cambiar estatus del producto.
Actor(es) Gerente
Tipo

1. El gerente pulsa la opción de tabla Productos.
eliminar 3. Si el estatus es activo, muestra
4. El gerente escoge deseada. mensaje de confirmación para
eliminar.
5. Si el mensaje es afirmativo,
cambia el estatus de habilitado a
deshabilitado.
6. Almacena el cambio realizado.
7. Fin de Use Case.
Curso Alterno 4. El gerente niega la orden de 5. Si el mensaje es negativo, no hace

eliminar. ningún cambio, retorna al paso n° 7.

Post-condición Producto eliminado.

Nombre Consultar Producto
Descripción El gerente podrá consultar los datos del producto.
Actor(es) Gerente
Tipo

tabla Productos en la base de datos.
1. El gerente introduce el código del 3. Si el código se encuentra, se
producto a consultar. muestran los datos del producto.
4. Fin de Use Case.

base de datos, se envía un mensaje
“Producto no registrado”, se retorna
al paso n° 4.
Post-condición Producto consultado

Nombre Actualizar Producto
Descripción El gerente podrá hacer modificaciones en los datos del producto.
Actor(es) Gerente
Tipo
desea actualizar. 3. Cambia los datos introducidos en
los campos la Tabla Productos de la
base de datos.
4. Almacena los datos del producto
en la tabla Productos de la base de
datos.
5. Muestra mensaje “Producto
actualizado con éxito”.
6. Fin de Use Case.
Curso Alterno
Post-condición Producto actualizado.

Nombre Consultar factura
Descripción El empleado podrá consultar la información contenida en cada factura.
Actor(es) Empleado
Tipo
Esta Use case se inicia cuando: 2. Lee el código introducido.

1. Introduce el código de la factura que 3. Busca el código en la tabla de
desea consultar. facturas.
4. Si encuentra el código, muestra la
información de la factura.
5. Fin de la Use Case
Curso Alterno 4. Si no consigue el código, muestra

un mensaje “La factura no existe”.
Y retorna al paso N° 5.
Post-condición Factura Consultada

Nombre Registrar Factura

Descripción El empleado realiza el registro de la factura.
Actor(es) Empleado
Tipo
Esta Use case se inicia 1. Muestra la planilla de la factura.

cuando: 3. Lee la cédula del cliente introducida por el
2. Tipea la cédula del empleado.
cliente 4. Busca la cédula en la Tabla Clientes de la base
6. Lee mediante el lector de datos
óptico el código del 5. Si la encuentra la cédula, carga los datos del
producto cliente en la planilla.
9. Tipea cantidad del 7. Busca en la tabla Productos de la base de
producto. datos el código leído.
17. Selecciona opción. 8. Carga en planilla el nombre y precio del
20. Ordena al sistema producto.
almacenar e imprimir 10. Lee cantidad de producto deseado.
factura. 11. Verifica existencia del producto en la Tabla
Productos de la base de datos.
12. Si la existencia es mayor o igual a la cantidad
introducida por el empleado, calcula monto a
pagar por el producto.
13. Activa el siguiente campo de código de
producto.
14. Realiza el paso 6 hasta el paso 13 esto hasta
que el empleado teclee la opción de
“Totalizar”.
15. Calcula el monto total a pagar por la venta.
16. Envía mensaje de confirmación de venta.
18. Lee la opción seleccionada.
19. Si la opción es ok, envía la factura a caja
21. Almacena factura llena en la tabla Facturas.
22. Imprime la factura.
23. Fin de Use Case.
Curso Alterno 5. Si la cédula no se encuentra, muestra mensaje

“Cliente no existe”, se retorna al paso N° 23.
12. Si la existencia es cero o menor de la cantidad
introducida por el empleado, muestra existencia
del producto.
- Si el cliente acepta la cantidad de producto
disponible, se retorna al paso N° 9.
- Si el cliente no acepta la cantidad de producto
disponible, se retorna al paso N° 23.
19. Si la opción es negativa se anula la factura,
retorna al paso N° 23.
Post-condición Factura Registrada


Nombre Eliminar
Descripción El empleado podrá hacer la modificación del estatus de la factura.
Actor(es) Empleado
Tipo
Esta Use case se inicia cuando: 2. Lee el número de la factura.

1. Introduce el número de la factura a 3. Busca el número de la factura en
eliminar. la tabla Facturas.
5. Selecciona la opción deseada. 4. Si la consigue, muestra un
mensaje de confirmación de
eliminación.
6. Lee la opción seleccionada.
7. Si la opción es Ok, cambia el
estatus de la factura.
8. Almacena el cambio en la tabla
Facturas de la base de datos.
9. Muestra mensaje “Caja
Eliminada”
Curso Alterno 4. Si no consigue el numero de la

factura el la tabla de facturas, envía
mensaje “La factura no existe”.
Retorna al paso N° 10.
7. Si la opción es negativa. Retorna
al paso N° 10.
Post-condición Factura eliminada

Nombre Generar Devolución
Descripción El gerente podrá generar las facturas devueltas
Actor(es) Gerente
Tipo
Esta Use case se inicia cuando: 5. Muestra la plantilla de devolución

1. Selecciona la opción de devolución. 4. Lee el código de la factura.
3. Introduce el código de la factura 5. Busca el código en la tabla de
que desea devolver. facturas.
7. Selecciona los productos que 6. Si lo encuentra, carga los datos
desea devolver y la cantidad. en la planilla y activa los campos de
9. Selecciona la opción guardar los productos.
devolución. 8. Muestra los productos
seleccionados.
10. Almacena los datos de los
productos devueltos en la tabla
ProdDevueltos y los datos de la
factura en la tabla de
factdevueltas.
11. Muestra un mensaje “Devolución
satisfecha”
Curso Alterno 6. Si no lo encuentra, muestra un

mensaje “Factura no registrada”,
retorna al paso N° 12.
Post-condición Factura devuelta registrada.
Nombre Eliminar Facturas Devueltas
Descripción El gerente podrá eliminar las facturas devueltas

Actor(es) Gerente
Tipo
Esta Use case se inicia cuando: 6. Verifica la última fecha de

1. Pulsa la opción de eliminar eliminación.
facturas. 7. Si ha transcurrido el período de
4. Elige la opción deseada. un año, muestra mensaje de
confirmación “Realmente desea
eliminar facturas”.
5. Si la opción elegida es afirmativa,
elimina el lote de facturas de la
base de datos.
6. Muestra mensaje “Facturas
eliminadas”.
7. Fin de Use Case.
Curso Alterno 3. Si no ha transcurrido el tiempo de

un año desde la última
eliminación, se muestra un
mensaje “No se puede eliminar”,
se retorna al paso n° 7.
5. Si la opción es negativa no se
realiza ninguna acción, retorna al
paso nº 7.
Post-condición Facturas devueltas eliminadas.
Nombre Consulta de reportes de Facturas Devueltas
Descripción El gerente podrá consultar los reportes de las facturas o de los productos que
han sido devueltos.
Actor(es) Gerente.
Tipo

Esta Use case se inicia cuando: 2. Lee el tipo de reporte a consultar.

1. Selecciona la opción de reportes. 3. Si la opción es reporte de factura
5. El gerente tendrá la opción de de devolución, busca en la tabla
imprimir el reporte si lo desea. FactDevueltas todas las facturas.
4. Muestra todas las facturas
devueltas y los datos de las
mismas.
6. Lee la opción introducida por el
usuario.
7. Si es imprimir, imprime el reporte.
8. Fin de Use Case.
Curso Alterno 3. Si la opción es reporte de

productos devueltos, busca en la tabla
ProdDevueltas.
4. Muestra la información de los
mismos. Retorna al paso N° 5.
6. Si la opción no es imprimir, cancela
la operación de consulta. Retorna al
paso N° 7.
Post-condición Reportes de Facturas devueltas consultados.

2.5 Diagramas de Secuencias

Gestión de Cliente:

Gestión Empleado:



Gestión de Caja:


Gestión de Productos:


Gestión de facturas de ventas:



Gestión facturas de devolución:

2.6 Diagrama de Clases



Descripción del Diagrama de Clase
Cliente
Datos correspondientes a un cliente.
Atributos Descripción Método Descripción
NomCliente Nombre del Cliente  Registrar  Registra los datos
CedCliente Cédula del Cliente  Consultar del cliente
DirecCliente Dirección del Cliente  Modificar  Consulta los datos
del cliente
TlfCliente Teléfono del Cliente
 Modifica los datos
CodCiudad Código de la ciudad del cliente
donde vive
CodTipo Código del tipo del
cliente
FechaI Fecha en la que el
cliente es registrado
Factura
Documento que valida la realización de una venta
Numfact Número de factura  Registrar  Registra los datos de
FechEmisión Fecha de emisión  Consultar una factura
 Modificar  Consulta los datos
Montotal Monto total de factura
 Eliminar de una factura
TotalIVA Monto de la venta con IVA  Modifica los datos de
Estatus Estado de la factura una factura
 Elimina los datos de
una factura
Empleado
Datos correspondientes a un empleado.
CodEmpleado Código del empleado  Registrar  Registrar los datos
NomEmpleado Nombre del  Consultar de un empleado
empleado  Modificar  Consulta los datos
TlfEmpleado Teléfono del  Eliminar de un empleado
empleado  Modifica los datos
Cargo Cargo del empleado de un empleado
DirecEmpleado Dirección del  Elimina los datos de
empleado un empleado
Estatus Estatus del
empleado

Producto
Datos de los artículos que ofrece la empresa para la venta.
Descripción Nombre del producto  Registrar  Registra los datos
Codprod Código del producto  Consultar de un producto
Estatus Estado del producto  Modificar  Consulta los datos
CodIVA Código del tipo de  Eliminar de un producto
IVA  Modifica los datos
PVP1 Precio del producto de un producto
con IVA tipo 1.  Elimina los datos de
PVP2 Precio del producto un producto
con IVA tipo 2.
UltCosto Ultimo costo del
producto
CostoProd Costo del producto
StockMin Cantidad mínima del
producto en
existencia
StockMax Cantidad máxima del
producto en
existencia
Existencia Existencia del
producto
CodTipo Tipo de producto
Prod/Factura
Datos de un producto perteneciente a una factura de una determinada venta.
Cantproductos Cantidad de  Consultar  Consulta de los
productos datos un producto
Totalventa Total de venta por factura
Caja
Datos correspondientes a una caja.
Codcaja Código de la caja  Registrar  Registra los datos de una
Ventatotaldia Venta total del día  Consultar caja
Estatus Estado de la caja  Modificar  Consulta los datos de una
 Eliminar caja
 Emitir reporte  Elimina los datos de una
caja
 Deshabilita una caja
 Emite reportes de una caja

FactDevueltas
NroDev Numero de la  Generar Devolución  Registra la nueva factura
devolución.  Consultar Reportes de devolución.
Fecha Fecha en que se  Eliminar  Eliminación de facturas
realizó la devolución. devueltas en lotes.
 Permite la consulta de
reportes de las facturas
devueltas e impresión de
las mismas
ProdDevueltas
NroDev Numero de la  Generar Devolución  Registra los productos que
devolución.  Consultar Reportes han sido devueltos.
Cant Cantidad de  Permite la consulta de
productos devueltos. reportes de los productos
que han sido devueltos y
la impresión de los
mismos.

2.7 Modelo Entidad Relación 2. (MER)

Base de datos
Empleado Cliente Factura
 NomEmpl  NomCli  NumFact (*)
 CedEmpl  CedCli (*)  FechEmisión
 CodEmpl (*)  TipoCliente  TotalIVA
 Cargo  DireCli  Montotal
 DirecEmpl  CodCiu  CodCaja
 CodCiu  FechaI  CodEmpl
 Estatus  CedCli
 Estatus
Tlf/Empleado Tlf/Cliente TipoCliente
 CodEmpl (*)  CedCli (*)  NombTipo
 TlfEmpl (*)  TlfCli (*)  CodTipo (*)
Ciudades Caja Producto
 NomCiu (*)  CodCaja  Descripción
 CodCiu  VentotalDia  CodProd (*)
 CodArea  CodEmpl  CodTipo
 Estatus  Existencia
 UltCosto
 CostoPro
 Stop mínimo
 Stop máximo
 Status
 CodIva
 PVP1
 PVP2
ProdFact TipoProducto IVA
 NumFact (*)  NomProd  CodIVA (*)
 Descripción
 CodProc (*)  CodTipo (*)
 Porcentaje
 CantXProd (*)
FactDevueltas ProdDevueltos
 NumFact  CodProd
 Fecha  Cant
 NroDev  NroDev
2.8 Diagramas de Estado

1. Objeto Candidato:
Factura.
 Estados:
 En proceso
 Terminada
 Pagada
 Eliminada
 Devuelta
Cliente.
 Estados:
 Registrado
 Activo
 Inactivo
Producto.

 Estados:
 Registrado
 Eliminado
 Escaso
 Dañado
 Devuelto
 Vendido
Empleado
 Estados:
 Registrado
 Eliminado
2.9 Diagramas de Componentes


3.1 Descripción de la Interfaz
Teniendo en cuenta que la interfaz es la parte de un programa que permite el flujo de información entre
un usuario y la aplicación, esta debe ser realizada con ciertas características que sean amigables y
manejables por el usuario.
La aplicación de este proyecto se desarrolló bajo el lenguaje de programación Visual Basic 6.0, teniendo
que soportar acceso a una base de Access. Cabe citar que el equipo de desarrollo estaba limitado a
unos conocimientos medios del lenguaje de programación, por lo que las soluciones adoptadas pueden
no ser completamente eficientes.
Establecimiento de estándares
Estándar de las pantallas

Cada pantalla esta realizada con fondo de color blanco, contiene botones con iconos para que el usuario
relacione el botón con la acción que éste realiza. La solicitud de datos viene agrupada por objeto,
indicando por bloque los datos del objeto que se requieren. La aplicación cuenta con un menú principal el
cual da acceso a las distintas pantallas que contiene la misma, también cuenta con botones de las
pantallas más importantes así como una opción de ayuda que sirva de soporte para el usuario.
La letra utilizada en las etiquetas de las pantallas es Arial, de color negro, las palabras de las etiquetas
llevan la primera letra en mayúscula el resto en minúsculas. La entrada de información es con letra
mayúscula. En la aplicación se hace uso de mensajes de éxito de operación así como de confirmación.
Las pantallas tienen un tamaño medio. La fecha es tomada del sistema la cual se muestra en formato
dd/mm/aaaa. Las cajas de textos viene en un tamaño de acuerdo a la longitud de los datos que se van a
tipear en ellos.
Estándar de los reportes

Los reportes de esta aplicación llevan en la cabecera de la hoja en la parte izquierda el logo de PRECA,
y el nombre de la empresa. El titulo del documento es el nombre del reporte el cual se situa en el centro
de la hoja. En la parte derecha esta la fecha del día de la consulta del reporte en formato dd/mm/aaaa.
Los reportes contienen la opción de imprimir y de exportar
La letra utilizada es de tipo Arial, el titulo viene en letra Century Gothic de color verde. Los datos del

reporte vienen agrupados según el dato de interés, cada bloque se encierra en un rectángulo. El papel es
tamaño carta, de base 20.
En la parte inferior de la hoja como pie de página, en la parte izquierda se encuentra el día y la fecha de
la consulta del reporte (ej. Sábado, 25 de Octubre de 2.008), luego muestra el numero de la página. En la
parte derecha muestra el total de los datos que se encuentran en el reporte.
Estándar de los procesos

En los procesos de registro y modificación se activan los campos en los cuales se requiere ser
proporcionados por el usuario, los demás campos son proporcionados por la aplicación, se activa
mensaje de confirmación para el almacenamiento de los datos registrados o modificados.
En el proceso de búsqueda de datos se muestra una pantalla donde el usuario selecciona el registro de
interés, luego estos datos son mostrados en la pantalla que el usuario está utilizando.

CONCLUSIÓN
La necesidad de modelar un negocio surge ante el hecho de que muchos de los productos
software que se desarrollan automatizan algunos o todos los procesos existentes en un
negocio, y es necesario estudiar las implicaciones de los cambios producidos por la adopción
de estos productos. Hay que entender como funciona el negocio que se desea automatizar
para tener garantías de que el software desarrollado va a cumplir su propósito, y por esto, se
hace un estudio en el dominio del negocio además del dominio del software.
La empresa PRECA, C.A. cuenta con un sistema de ventas el cual no proporciona aplicaciones
para la gestión de las devoluciones de los productos; es por esto, que el proyecto se ha basado
en la incorporación de dichas aplicaciones en el sistema. Esto a través de la información
recopilada y análisis de la misma a través de los diagramas contenidos en el modelado de
negocio.

Proyecto de Niurka

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Proyecto de Niurka

Încărcat de

Drepturi de autor:

Formate disponibile

1.

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Identificación del Equipo de Desarrollo

Apellidos Nombres Cédula Observación

Confidencial PRECA, 2019 Página 2

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Confidencial PRECA, 2019 Página 3

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

A través del modelado de negocio se pretende llegar a un mejor entendimiento de la

La finalidad de este proyecto es mostrar un ejemplo de desarrollo de software, para la gestión

Confidencial PRECA, 2019 Página 4

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Confidencial PRECA, 2019 Página 5

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

 Conseguir una meta de 5.000.000 BsF. Mensuales.

Confidencial PRECA, 2019 Página 6

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Organigrama por Departamentos

Organigrama por Cargos

Confidencial PRECA, 2019 Página 7

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

1.3 Cadena de Valor

Capacitación del personal.

Descripción General de la Cadena de Valor

 Recepción y almacenamiento de los productos: en este proceso se reciben los

Confidencial PRECA, 2019 Página 8

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

1.4 TIC que soporta los procesos de la organización

 El uso de INTRANET que permite comunicar la información de la compañía a los

Confidencial PRECA, 2019 Página 9

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

1.5 Modelado de los Procesos de Ventas

Confidencial PRECA, 2019 Página 10

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

PLANTILLA PARA DESCRIBIR PROCESOS DE NEGOCIO

Indicadores: Responsable: Gerente de Ventas

Subprocesos: Procesos Relacionados:

Roles: Vendedor, cliente, despachador, caja, Nivel del Proceso: Medular

Confidencial PRECA, 2019 Página 11

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Modelado del Proceso con BPMN: Ver pagina anterior

Confidencial PRECA, 2019 Página 12

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

1.6 Reglas de Negocio

 Un cliente que factura de 5000 a 150000 BsF. constantemente durante el año

Confidencial PRECA, 2019 Página 13

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

1.7 Modelo Entidad Relación 1. (M.E.R)

Confidencial PRECA, 2019 Página 14

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

1.8 Estudio de Competitividad

Confidencial PRECA, 2019 Página 15

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Salidas No deseadas o Necesidades de Información no satisfechas:

Causas potenciales las salidas no deseadas o necesidades de información no

Los competidores de la empresa PRECA son aquellas empresas que basan su

Oportunidades que se encuentran en el entorno:

 Desarrollo de mercado en el territorio nacional.

Amenazas que se encuentran en el entorno:

 Escasez de recurso humano.

Confidencial PRECA, 2019 Página 16

Sistemas II. Equipo N°: 6 Fecha: <27/10/08>

Fortalezas que tiene la organización: