2. 5.1. INTRODUCCION
En este capítulo denominaremos, definiremos y daremos a conocer la definición del
sistema informático, criterios de desempeño y calidad del sistema, el modelo del negocio,
caso de uso, los requerimientos funcionales y no funcionales, escenario de registrar
ventas.
5.2. DENOMINACION DEL SISTEMA
Sistema Informático de ventas “SW. BOTICABIOSANA”
5.3. DEFINICION DEL SISTEMA
El sistema SW. BOTICABIOSANA es desarrollado para la botica “Biosana” tendrá como
objetivo llevar un control de todas las ventas q se realiza al diariamente. Este sistema
tiene acceso para 3 usuarios (1 administrados y 2 vendedores), registrará los datos del
producto e imprimir la boleta respectiva.
5.4. BENEFICIOS DE LA PROPUESTA DEL SISTEMA INFORMATICO
Información actualizada y detallada de las ventas generadas
El cobro de los productos es más eficiente y rápido, brindando todos los detalles
requeridos en el control de flujo de caja.
Se muestran la cantidad de stock de los productos de manera exacta permitiendo
un ahorro de tiempo para hacer los pedidos.
5.5. RESTRICCIONES DEL SISTEMA INFORMATICO
A excepción del Administrador nadie tendrá acceso a los reportes de la venta de
los productos, debido a que los clientes esperarían un largo tiempo para ser
atendidos.
Solo los desarrolladores del software tendrán acceso a la codificación de esta
aplicación informática.
Todas las ventas serán registradas para evitar la pérdida de productos.
3. 5.6. CRITERIOS DE DESEMPEÑO Y DE CALIDAD DEL SISTEMA INFORMATICO
Los datos serán exactos, no habrá registros duplicados si no solo los que sean
generado por el sistema.
El sistema llevara a cabo las funciones requeridas por el usuario de llevar un mejor
control de las ventas en su botica.
El sistema será de fácil manejo para los usuarios especialmente para aquellos q
no tengas mucha familiaridad con los sistemas informáticos.
5.7. MODELO DEL NEGOCIO
5.7.1 Descripción de los Stakeholders y los usuarios del Sistema
Administrador: Tendrá acceso a todas las ventas realizadas (diarias y
mensuales).
Vendedor: Usara el sistema para generar la venta de los productos.
Cliente: Compra los productos de la botica los cuales son registrados en el
sistema.
Proveedor: Abastecer a la botica de productos farmacéuticos.
7. 5.9. REQUERIMIENTOS ESPECIFICOS DE LA SOLUCION
5.9.1 REQUERIMIENTOS FUNCIONALES
El sistema debe validar los usuarios (código, nombre de usuario,
contraseña).
El sistema debe permitir almacenar datos del cliente (código, nombre).
El sistema debe registrar los datos del producto (código, código de barra,
nombre, presentación, proveedor, categoría, precio unitario, precio de
compra, precio de venta, stock y tipo de producto).
El sistema tiene que hacer búsqueda del producto por nombre o
presentación.
El sistema debe permitir editar, agregar, eliminar los productos.
El sistema debe generar la venta mediante un documento.
El sistema debe registrar los datos de las ventas realizadas (fecha, precio
unitario, cantidad, importe).
5.9.2 REQUERIMIENTOS NO FUNCIONALES
La aplicación debe de visualizarse y funcionar correctamente en cualquier
sistema
La aplicación no debe tardar más de 10 segundos en mostrar los resultados.
El sistema permitirá el ingreso de 3 usuarios
.
8. 5.10. ESCENARIO REGISTRAR CLIENTE
5.10.1. Documentación del Caso de Uso: “Registrar cliente”
CASO DE USO: REGISTRAR CLIENTE
BREVE DESCRIPCIÓN:
El caso de uso es iniciado por el cliente cuando desea comprar un producto.
PRECONDICIONES:
Acceso al vendedor para el registro del cliente.
FLUJO BÁSICO:
El sistema genera el código del cliente.
El vendedor ingresa los datos: nombres apellidos, dirección, celular, DNI y tipo.
Se muestran las opciones Guardar y Cancelar.
Si se selecciona Guardar, se guardan los datos ingresados.
Si se selecciona Cancelar, se cancela el proceso.
SUB-FLUJOS:
A1. Solo se puede seleccionar un tipo de cliente.
A2. Se limpian las variables para ingresar otro cliente.
FLUJOS DE EXCEPCIÓN:
E1. Si se selecciona NO, no se sale del formulario.
9. 5.10.2. DIAGRAMA DE SECUENCIA: REGISTRAR CLIENTE
: Vendedor
: Vendedor
: Sistema Informático
: Sistema Informático
: Cliente
: Cliente
Selecciona Menu:Proceso
Lee Datos
Carga Datos
Muestra Formulario
Elige Botón Nuevo
Ingresa nombres
Ingresa apellidos
Ingresa celular
ingresa DNI
Ingresa tipo cliente
Elige Botón Guardar
Guarda Datos
OK
Actualiza Formulario
Genera Codigo
12. 5.11. ESCENARIO: REGISTRAR PRODUCTO
5.11.1. Documentación del Caso de Uso: “Registrar producto”
CASO DE USO: REGISTRAR PRODUCTO
BREVE DESCRIPCIÓN:
Este caso de uso registrará los datos de los productos vendidos.
PRECONDICIONES:
Acceso al vendedor para el registro de producto.
FLUJO BÁSICO:
El vendedor selecciona el tipo de presentación. (A1)
El vendedor selecciona el laboratorio.
El vendedor ingresa los datos código del producto, código de barra, Nombre,
Presentación, Proveedor, Categoría, Precio Unitario, Precio de compra, Precio de Venta,
Stock y Tipo de Producto.
Se muestran las opciones Guardar y Cancelar
Si se selecciona Guardar, se guardan los datos ingresados.
Si se selecciona Cancelar, se cancela el proceso.
SUB-FLUJOS:
A1. Se puede seleccionar solo un tipo de presentación.
A2. Se puede seleccionar solo un proveedor.
A3 Se limpian las variables para ingresar otro producto.
FLUJOS DE EXCEPCIÓN:
E1. Si se selecciona NO, no se sale del formulario.
13. 5.11.2. DIAGRAMA DE SECUENCIA: REGISTRAR PRODUCTO
: Vendedor
: Vendedor : Sistema Informático
: Sistema Informático : Producto
: Producto
Selecciona Menu:Proceso
Lee Datos
Carga Datos
Muestra Formulario
Selecciona Botón Nuevo
Ingresa Codigo de Barra
Ingresa Nombre
Ingresa Presentacion
Ingresa Proveedor
Ingresa Categoria
Ingresa Precio Unitario
Ingresa Precio de Compra
Elige Botón Guardar
Guarda Datos
OK
Actualiza Formulario
Genera codigo de Producto
Ingresa Precio de Venta
Ingresa Stock
Ingresa Tipo de Producto
17. 6.1. INTRODUCCION
En este capítulo se dará el planteamiento del problema, diseño de la base de datos
que será diseño conceptual, diseño lógico, diseño físico y el diccionario de datos y por
último el diseño de la arquitectura del sistema.
6.2. PLANTEAMIENTO DEL CASO
En el proceso de Ventas se pudo identificar que el cliente compra los productos que
desea, se registran cada venta anotando el código del producto, su nombre,
descripción, precio de venta, etc. Además, las ventas deben registrarse para generar
reportes por día y mes.
6.3. DISEÑO DE LA BASE DE DATOS
6.3.1. Diseño Conceptual
El modelo entidad-relación es el modelo conceptual más utilizado para el
diseño conceptual de bases de datos. Fue introducido por Peter Chen en
1976. El modelo entidad-relación está formado por un conjunto de
conceptos que permiten
describir la realidad mediante un conjunto de representaciones gráficas y
lingüísticas.
Originalmente, el modelo entidad-relación sólo incluía los conceptos de
entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como
los atributos compuestos y las jerarquías de generalización, en lo que se
ha denominado modelo entidad-relación extendido.
18. 1. Dibujar el Diagrama Entidad / Relación
Figura 1.2 Diagrama entidad-relación elaborado en Microsoft Visio
CLIENTE
PRODUCTO
compra
Direccion_Clie
Dni
Stock
Proveedor
Nombre
fecha
precio_uni
cantidad
total
(1,N)
(1,N)
N:N
Categoria
Codigo_Barra
id_Producto
Celular_Clie
Nombre_Clie
id_Venta
nro_documento
EMPLEADO
Email
Cargo
Celular
Estado
Sesion
PROVEEDOR
Registra
Direccion
Provincia
Direccion
id_Cliente
Apellidos_Clie
Tipo_Cliente
Precio_Venta
Precio_Compra
Precio_Unit
Presentacion
Apellidos
Dni
FechaContratacion
Nombres id_Empleado
1:N
Tipo_Producto
Password
Nivel
id_Proveedor
Razon_Social
Email
Responsable_Zona
Celular_Responsable
Tipo_Producto
Telefono
19. 2. Revisar el esquema conceptual local con el usuario
Se revisó el diagrama y se validó según el siguiente cuadro:
Requerimientos Nº Requerimientos del usuario Revisión
Req. Funcionales
1
Registrar a los clientes por código o
nombre
ok
2 Registrar los datos de los productos
3
Registrar las ventas efectuadas
diarias
y mensuales
Informes
5 Informe de las ventas diarias ok
5 Informe de las ventas mensuales ok
6.3.2. Diseño Lógico
Fase 1:
Paso1: Convertir los esquemas conceptuales locales en esquemas lógicos locales.
a. Eliminar Relaciones de muchos a muchos
b. Eliminar las relaciones entre tres o más entidades
No se aplica
c. Eliminar las relaciones recursivas
No se aplica
d. Eliminar las relaciones con atributos
CLIENTE
PRODUCTO
compra
Direccion_Clie
Dni
Stock
Proveedor
Nombre
fecha
precio_uni
cantidad
total
(1,N)
(1,N)
N:N
Categoria
Codigo_Barra
id_Producto
Celular_Clie
Nombre_Clie
id_Venta
nro_documento
EMPLEADO
Email
Cargo
Celular
Estado
Sesion
PROVEEDOR
Registra
Direccion
Provincia
Direccion
id_Cliente
Apellidos_Clie
Tipo_Cliente
Precio_Venta
Precio_Compra
Precio_Unit
Presentacion
Apellidos
Dni
FechaContratacion
Nombres id_Empleado
1:N
Tipo_Producto
Password
Nivel
id_Proveedor
Razon_Social
Email
Responsable_Zona
Celular_Responsable
Tipo_Producto
Telefono
20. No se aplica
e. Eliminar los atributos multievaluados
No se aplica
f. Revisar las relaciones de uno a uno
Se revisaron las relaciones de uno a uno y no es necesario eliminar alguna de ellas
porque no presenta repetición. Las demás relaciones deben existir.
g. Eliminar las relaciones redundantes.
No se aplica
Paso2: Derivar un conjunto de relaciones para cada esquema lógico local.
CLIENTE (id_cliente, nombre_clie, apellidos_clie, nombres, dirección_clie, celular_clie,
Dni, Tipo_Cliente,)
VENTA (id_venta, Fecha_Venta*, id_cliente*)
DETALLE_VENTA (id_detalle_venta*, id_venta*, id_Producto, Cantidad, Precio_venta,
subtotal_Venta)
PRODUCTO (id_Producto, Codigo_Barra, Nombre, Presentación, Proveedor, Categoria,
Precio_unit, Precio_Compra, Precio_Venta, stock, Tipo_Producto)
EMPLEADO (id_Empleado, Nombres, Apellidos, Dni, Cargo, FechaContratacion,
Direccion, Celular, Email, Estado, Sesion, Password, Nivel)
Paso3: Validar cada esquema mediante la normalización.
Primera Forma Normal “No hay grupos repetitivos”
Relación: VENTA
Cod_venta Cod_cliente cod_vendedor fecha cod_pr
oducto
cantidad Precio_
uni
total serie
V001 C002 VE0001 14/07/19 P003 2 20 40 001
V002 C004 VE 0002 15/07/19 P005
P041
P901
5
1
8
5
12
3
61 002
Como se puede observar en la figura, esta tabla presenta grupos repetitivos en los atributos
cod_producto, cantidad y precio_uni. Debido a esto, se los colocará en una tabla aparte.
Relación: DETALLE_VENTA
cod_venta (FK) cod_producto (FK) cantidad Precio_uni
V001 P003 2 20
V002 P005 5 5
21. V002 P041 1 12
V002 P901 8 3
Entonces la relación VENTA quedaría de la siguiente manera:
cod_venta cod_cliente
(FK)
cod_vendedor
(FK)
Fecha_venta serie Nro_doc total
V001 C002 VE0001 14/07/19 001 00002 40
V002 C004 VE0002 15/07/19 002 00004 61
Segunda Forma Normal “No dependencias parciales”
Las relaciones están en segunda formal normal debido a que las dependencias
funcionales son completas.
Tercera Forma Normal “No dependencias transitivas”
Las relaciones se encuentran en tercera forma normal debido a que no hay dependencias
transitivas.
Paso 4: Validar cada esquema frente a las transacciones del usuario.
REQUERIMIENTOS FUNCIONALES DEL SISTEMA VALIDACION
El sistema debe validar los usuarios (código, nombre de usuario,
contraseña).
SI
El sistema debe permitir almacenar datos del cliente (código, nombre). SI
El sistema debe registrar los datos del producto (código, descripción,
stock, fecha de vencimiento, lote).
SI
El sistema tiene que hacer búsqueda del producto por código o nombre. SI
El sistema debe permitir editar, agregar, eliminar los productos. SI
El sistema debe generar la venta mediante un documento. SI
El sistema debe registrar los datos de las ventas realizadas (fecha, precio
unitario, cantidad, importe).
SI
Paso 5. Dibujar el diagrama relacional
22. Paso 6. Definir las restricciones de integridad
a) Datos requeridos
Ver en Anexos Diccionario de Datos, en los Atributos se aprecia que no aceptan nulos.
b) Restricciones de dominios
Ver en Anexos Diccionario de Dato, en los atributos, todos los valores del dominio.
c) Integridad de dominios
Ver en Anexos Diccionario de Datos que todas las claves primarias de las relaciones
no aceptan valores nulos, estando en cumplimiento con la Integridad de las Entidades.
d) Integridad referencial
-Las claves ajenas no admiten nulos (Ver en Diccionario de Datos) ya que sus claves
primarias tampoco lo aceptan.
-Cuando se quiere borrar una ocurrencia, la opción será la de restringir debido a que
no está permitido.
-Cuando se quiere modificar la clave primaria, se propagará a los atributos
referenciados.
23. e) Reglas de negocio
1. El producto debe tener únicamente un código
2. Para todos los productos se debe registrar su fecha de vencimiento
3. El administrador tendrá acceso a todo el sistema
4. La cantidad de venta no debe superar el stock de productos
Paso 7. Revisar cada esquema lógico local con el usuario correspondiente
Se revisó el diagrama y se validó según el siguiente cuadro:
Nº Requerimientos del Sistema Revisión
1
El sistema debe validar los usuarios (código, nombre de usuario,
contraseña).
ok
2
El sistema debe permitir almacenar datos del cliente (código,
nombre).
ok
3
El sistema tiene que hacer búsqueda del producto por código o
nombre ok
4
El sistema debe registrar los datos de las ventas realizadas (fecha,
precio unitario, cantidad, importe). ok
6.3.3. Diseño Físico
24.
25. IMPLEMENTACIÓN DE LA BASE DE DATOS EN SQL SERVER 2014
6.3.4. Diccionario de Datos
Ver Anexos
26. 6.4 DISEÑO DE LA ARQUITECTURA DEL SISTEMA
6.4.1 Diseño modular
SISTEMA DE
VENTAS PARA LA
BOTICA "BIOSANA"
REGISTRO
Vendedor
Cliente
Producto
MOVIMIENTO
Registrar cliente
Registrar producto
Registra venta
REPORTES
Diario
Mensual
AYUDA
Índice
Acerca del Sistema
SALIR
28. 7.1. INTRODUCIÓN
En este último capítulo veremos la construcción del sistema, código de acceso al sistema
y del sistema, diseño de interfaz gráficos de acceso al sistema, presentación del sistema,
pantalla principal y sus respectivos mantenimientos ya sea de usuario, clientes y productos.
7.2. CONSTRUCCION DE PROGRAMAS DEL SISTEMA
Para para desarrollar este sistema software estamos utilizando:
Microsoft Visual Studio 2015
Lenguaje Visual Basic.NET
Código de acceso al sistema
29. Public Class LoginForm1
Private Sub OK_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles OK.Click
'Declaracion de la variable contador
Static Vcont As Integer
'Inicio la estructura de control de decision If Then anidada
If UsernameTextBox.Text = "admin" Then
If PasswordTextBox.Text = "12345" Then
'Muestro el formulario Form1
SplashScreen1.Show()
'Descargo el formulario activo
Me.Hide()
Me.DialogResult = DialogResult.OK
Else
If Vcont = 2 Then
'Funcion de mensaje
MsgBox("Perdío último intento, saldrá de la aplicación")
End
Else
'Funcion de mensaje
MsgBox("Clave errónea. Perdío " & Str(Vcont + 1) &
"intentos")
'Limpio la caja de texto
PasswordTextBox.Text = ""
'Ubico el cursor en la caja de texto
PasswordTextBox.Focus()
'Aumento el contador en 1
Vcont = Vcont + 1
Me.DialogResult = DialogResult.Cancel
End If
End If
Else
MsgBox("Usuario no considerado en la lista")
UsernameTextBox.Text = ""
UsernameTextBox.Focus()
End If
End Sub
Private Sub Cancel_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Cancel.Click
Me.Close()
End Sub
End Class
30. Código de presentación del sistema
Public NotInheritable Class SplashScreen1
Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
'Título de la aplicación
If My.Application.Info.Title <> "" Then
ApplicationTitle.Text = My.Application.Info.Title
Else
'Si falta el título de la aplicación, utilice el nombre de la aplicación
sin la extensión
ApplicationTitle.Text =
System.IO.Path.GetFileNameWithoutExtension(My.Application.Info.AssemblyName)
End If
Version.Text = System.String.Format(Version.Text,
My.Application.Info.Version.Major, My.Application.Info.Version.Minor)
'Información de Copyright
Copyright.Text = My.Application.Info.Copyright
End Sub
Private Sub Timer1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Timer1.Tick
Me.ProgressBar1.Value = ProgressBar1.Value + 1
Me.IblPorcentaje.Text = Me.ProgressBar1.Value.ToString + "%"
If Me.ProgressBar1.Value = 100 Then
My.Forms.FrmPrincipal.Show()
Me.Close()
End If
End Sub
End Class
31. Código de pantalla principal del sistema
Public Class FrmPrincipal
Private Sub FrmPrincipal_Load(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles MyBase.Load
Me.IblUsuario.Text = "admin"
Me.IblFecha.Text = Now()
End Sub
Private Sub FrmPrincipal_FormClosing(ByVal sender As Object, ByVal e As
System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
Dim r As Integer
r = MsgBox("Desea cerrar la Aplicación?", MsgBoxStyle.OkCancel, "Aviso del
Sistema")
If r = 1 Then
My.Forms.LoginForm1.Close()
Else
e.Cancel = True
End If
End Sub
Private Sub TsbREALIZARVENTA_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles TsbREALIZARVENTA.Click
FrmREALIZARVENTA.Show()
FrmREALIZARVENTA.Focus()
End Sub
Private Sub REGISTARCLIENTEToolStripMenuItem_Click(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles REGISTRARCLIENTEToolStripMenuItem.Click
FrmREGISTRARCLIENTE.Show()
FrmREGISTRARCLIENTE.Focus()
End Sub
Private Sub TsbREGISTRARCLIENTE_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs)
FrmREGISTRARCLIENTE.Show()
FrmREGISTRARCLIENTE.Focus()
End Sub
Private Sub REGISTARPRODUCTOToolStripMenuItem_Click(ByVal sender As System.Object,
ByVal e As System.EventArgs) Handles REGISTRARPRODUCTOToolStripMenuItem.Click
FrmREGISTRARPRODUCTO.Show()
FrmREGISTRARPRODUCTO.Focus()
End Sub
Private Sub TsbLISTADODECLIENTES_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles TsbLISTADODECLIENTES.Click
FrmLISTADODECLIENTES.Show()
FrmLISTADODECLIENTES.Focus()
End Sub
Private Sub TsbLISTADOPRODUCTOS_Click(sender As Object, e As EventArgs) Handles
TsbLISTADOPRODUCTOS.Click
FrmLISTADODEPRODUCTOS.Show()
FrmLISTADODEPRODUCTOS.Focus()
End Sub
End Sub
End Class
32. 7.3. DISEÑO DE INTERFACES GRAFICAS DE USUARIO
7.3.1. Diseño de pantalla de acceso al sistema
7.3.2. Diseño de pantalla de presentación del sistema
33. 7.3.3. Diseño de pantalla principal del sistema
7.3.4. Diseño de pantalla del módulo: Mantenimientos
7.3.4.1 Mantenimiento: Clientes
35. CONCLUSIONES
El objetivo de este proyecto técnico es poner en práctica algunos aspectos teóricos
que se han adquirido a lo largo de la carrera sea en el aspecto de gestión de
proyectos en cuanto a gestión y análisis de riegos, seguimiento y planificación de
tareas como en métodos, procesos y metodologías.
Este sistema, ocupa un papel de suma importancia dentro del funcionamiento
general de la botica, debido a la gran cantidad de artículos manejados en inventario
es imposible dar igual atención a cada uno de estos productos por ello este sistema
ayudara a que sea más eficientes en cuanto a sus ventas.
La implementación de un sistema de ventas permitirá a la empresa reducir la
ocurrencia en faltantes de medicamentos que en ocasiones pueden ser vitales para
la salud de los clientes al mismo tiempo que se organiza la gran cantidad de artículos.
Los procedimientos estandarizados presentados en la investigación, permiten
reducir los errores de registro en el inventario.
36. RECOMENDACIONES
Se recomienda que los encargados de la empresa estén informados sobre las leyes
para poder resolver problemas que se puedan dar en la empresa.
También se recomienda que todos y cada uno de los formularios en el sistema sean
llenados correctamente para su buen funcionamiento.
Se sugiere que al momento de introducir un funcionario nuevo que interactúe con el
sistema sea guiado y entrenado en forma acuciosa, con lo cual permitiría un mayor
grado de seguridad en los datos ingresados.
se recomienda implementar dentro del sistema la impresión de documentos, tales
como boletas o guías.
Se recomienda hacer un seguimiento anual de los datos ingresados al sistema, para
verificar que los usuarios ingresen la totalidad de las ventas.
37. REFERENCIAS BIBLIOGRÁFICAS
BlogIngeniería. (27 de Noviembre de 2012). Fases del modelo RUP. Obtenido de
http://metodologiadesoftware.blogspot.com/2012/11/fases-del-modelo-rup_27.html
Hernandez, A. (21 de Mayo de 2009). RUP. Obtenido de
https://es.slideshare.net/AlexHernandez99/rup-1471691
LOZANO, Letvin, Diagramación y Programación. Tercera Edición. Editorial: McGraw- Hill.
Madrid, España. 18, 19 págs.
Pressman, Roger S. 6ta edición. Ingeniería del Software: Un Enfoque Práctico.
McGraw-Hill.
SANDERS, Donald. Informática Presente y Futuro. Editorial: McGRAW- Hill. Madrid,
España. 704 páginas.
Sommerville, Ian. 2005. Ingeniería de Software. 7ma ed. Person Addison
Wesley.
Erwin. (2019). Erwin Data Modeler (DM). Obtenido de http://go.erwin.com/erwin-data-
modeler-free-trial
IBM. (2019). Descarga de prueba: IBM Rational. Obtenido de
https://www.ibm.com/developerworks/ssa/downloads/r/rtcp/index.html
Microsoft. (2019). SQL Evaluaciones. Obtenido de https://www.microsoft.com/es-
es/evalcenter/evaluate-sql-server-2014-sp3
38. ANEXOS
GUIA DE ENTREVISTA
Aplicado a: Gerente
Realizado por: Angulo García Rony Aldair
Ramírez Calderón Leonardo Alexis
Objetivo: Conocer el tipo de procesos que le hace falta a la botica
Fecha: 13/09/2020
Preguntas:
1. ¿Considera que la Botica cubre las necesidades de los clientes?
2. ¿Le satisface los servicios que presenta la Botica?
3. ¿Puede sugerirnos fallas para mejorar el servicio de la Botica?
4. ¿Con un sistema informático cree que mejorarían los procesos?
GRACIAS
39. Guía de Revisión Documentaria
Documento: FICHA RUC: 10466059108
Proporcionado por: SUNAT
Realizado por: Angulo Garcia Rony Aldair
Ramírez Calderón Leonardo Alexis
Fecha: 18/04/19
Objetivo: Conocer el giro del negocio.
Información e n c o n t r a d a : La Botica Biosana se encuentra registrada en
la SUNAT y se dedica a la venta de productos farmacéuticos y artículos de
tocador.
Evidencia:
40. GUIA DE OBSERVACION
Nombre de la Empresa: Botica “BIOSANA”
Investigado por: Angulo Garcia Rony Aldair
Ramírez Calderón Leonardo Alexis
Grupo: “02”
Fecha: 13/09/2020
Objetivo: Conocer el proceso de ventas de la Botica “BIOSANA”
INSTRUCCIONES: Observar si los procesos de venta son rápidos y así
con una “X” marca en el recuadro de la columna correspondiente si lo son
y si tiene observaciones puede colocarlas en la columna asignada.
41. DICCIONARIO DE DATOS
TABLA DE RELACIONES (TABLAS)
Nº NOMBRES DESCRIPCIÓN TIPO ALIAS Nº OCURRENCIAS Observaciones
1 CLIENTE Es la persona que compra los productos Fuerte/Tangible Comprador Indefinido
El mismo cliente puede
hacer varias compras
2 VENTA Es el registro de los productos vendidos Intangible Egreso Indefinido
Todas las ventas son
registradas
3 DETALLE_VENTA Es un registro más detallado de lo que se vendió Fuerte/Intangible Registro Indefinido
Permite que no exista
grupos repetitivos
4 PRODUCTO Es el insumo que se ofrece al cliente Fuerte/Tangible Artículo Indefinido
Cada producto tiene un
código
42. 2. TABLA DE RELACIONES
N° NOMBRE DESCRIPCIÓN ENTIDADES PARTICIPANTES CARDINALIDAD MÍNIMA CARDINALIDAD MÁXIMA GRADO
1 Tiene
Reperesenta la compra
realizada por cada
cliente
CLIENTE/VENTA (1,1) (1,N) Relación Binaria
2 Corresponde
Representa la
correspondencia de los
productos en su
respectiva registro de
venta
VENTA/PRODUCTO (1,1) (1,N) Relación Binaria
43.
44.
45.
46.
47.
48.
49. VERSIONES DE PRUEBA
(Ver en Referencias Bibliográficas)
Versión de prueba de Erwin Data Modeler
Versión de prueba de SQL 2014
Versión de prueba de IBM Rational Rose