Documentacion MEDUSA

REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD RAFAEL BELLOSO CHACÍN
FACULTAD DE INGENIERIA
ESCUELA DE COMPUTACIÓN
CÁTEDRA: BASES DE DATOS
SECCIÓN: C-1013
MANUAL DEL ANALISTA.
SOFTWARE FARMACÉUTICA MEDUSA
PRESENTADO POR:
Matos, Josthin C.I: 28.137.208
Meza, Idalwis C.I: 28.171.830
Salaberry, Walter C.I: 27.434.321
Maracaibo, Noviembre del 2020

ESQUEMA
1. CRONOGRAMA DE ACTIVIDADES
2. REQUISITOS Y ACTIVIDADES
3. DICCIONARIO DE DATOS
4. DIAGRAMA DE CASOS DE USO
5. CUADROS DE CASOS DE USO
6. DIAGRAMAS DE ACTIVIDADES
7. DIAGRAMAS DE FLUJO DE DATOS
8. DIAGRRAMA DE CLASES
9. MODELO CONCEPTUAL DE LA BASE DE DATOS
10. MODELO FÍSICO DE LA BASE DE DATOS
11. INTERFACES DE USUARIO

1. CRONOGRAMA DE ACTIVIDADES
2. REQUISITOS Y ACTIVIDADES
Requisitos Variable Fases Actividades Tiempo
Determinar el
balance
administrativo
de ambas
sedes.
Labores
administrativas
II. Definición
de
requerimientos
IV. Desarrollo
del Sistema
VI.
Implantación y
evaluación.
Comprobar la nómina
para conocer el monto
total que se paga a los
trabajadores, así como
gastos operativos, etc.
Realizar un inventario
para conocer cuántos
insumos se han
vendido o
4
semanas

exportado/importado,
en cuál sede y a qué
institución.
Entrelazar los
datos de ambas
sedes de forma
independiente y
también de
forma conjunta.
III. Diseño del
sistema
VI.
Implantación y
evaluación.
Evaluar diversos
métodos de
comunicación
disponibles para
establecer dicho canal
de información.
Implementar una red
de comunicaciones
que permita compartir
datos entre ambas
sedes.
1
semana
Controlar el
proceso de
distribución de
mercancía a
nivel nacional e
internacional
I. Investigación
preliminar
II. Definición
de
requerimientos
III. Diseño del
sistema
IV. Desarrollo
del Sistema
Determinar la cantidad
de insumos, precios, y
costos de distribución y
operativos asociados.
Visualizar el mapa de
distribución a
instituciones, a través
de un itinerario de
entregas.
3
semanas
Analizar y
determinar que
parte del
personal tendrá
acceso a esas
cifras.
Aplicación web I. Investigación
preliminar
II. Definición
de
requerimientos
Establecer niveles
jerárquicos dentro de
cada sede para
determinar la parte del
personal que tendrá
acceso a estos datos.
1
semana
Aplicar políticas
que promuevan
la seguridad e
integridad de los
datos.
III. Diseño del
sistema
IV. Desarrollo
del Sistema
Restringir el acceso
únicamente a los
administradores
autorizados de la base
de datos.
Comprobar la
ejecución de
protocolos de cifrado y
protección de datos,
así como depuración
de factores no
deseados en el
sistema de gestión de
la base de datos
(redundancia,
incompletitud).
2
semanas
Verificar la
completa
funcionalidad de
V. Prueba del
sistema
Verificar el correcto
funcionamiento de
cada interfaz a través
2
semanas

la aplicación
web
contemplando
así sus distintas
páginas, el
funcionamiento
de la base de
datos y demás
funcionalidades.
VI.
Implantación y
evaluación.
de pruebas unitarias y
globales.
Realizar la depuración
y corrección de código
necesaria para
suprimir cualquier error
o bug en el sistema.
3. DICCIONARIO DE DATOS
PerteneceARelación NombreColumna TipoDatos
USUARIO Nombre Carácter (60)
USUARIO Clave Carácter (60)
USUARIO ClaveEspecial Entero (6)
USUARIO País Carácter (10)
MERCANCÍA ID Entero (6)
MERCANCÍA Nombre Carácter (60)
MERCANCÍA UnidadesTotales Entero (8)
MERCANCÍA UnidadesDisponibles Entero (8)
MERCANCÍA UnidadesPedidas Entero (8)
MERCANCÍA Precio Decimal (5,2)
MERCANCÍA País Carácter (10)

CLIENTES ID Entero (6)
CLIENTES Nombre Carácter (60)
CLIENTES RegistroLegal Carácter (60)
CLIENTES Tipo Carácter (20)
CLIENTES País Carácter (10)
CLIENTES Dirección Carácter (100)
ENVÍO ID Entero (6)
ENVÍO País Carácter (10)
ENVÍO NombreMercancía Carácter (60)
ENVÍO UnidadesPedidas Entero (8)
ENVÍO NombreInstitución Carácter (60)
ENVÍO Dirección Carácter (100)
ENVÍO Fecha DateTime
ENVIO Valor Decimal (12,2)
ENVIO Tipo Carácter (25)

4. DIAGRAMA DE CASOS DE USO
5. CUADROS DE CASOS DE USO
Nombre
Caso de Uso:
Registrar Usuario
Id Caso de
Uso:
MedUSA-1
Actores: Administrador del software.
Descripción:
El administrador del software utiliza este caso de uso para incluir un nuevo
usuario en la base de datos del sistema, o modificar datos existentes.

Caso de Uso
Relacionados:
Comprobar usuario
Entradas:
Datos del usuario a
registrar, clave de acceso
Salidas:
Registro de usuarios
actualizado
Curso Típico
Acción del Actor Respuesta del Sistema
El administrador ingresa la clave de acceso a la base
de datos del sistema
El sistema verifica que la clave introducida sea
correcta
El administrador ingresa los datos de la persona a
registrar, o los datos a modificar.
El sistema confirma que los datos introducidos son
correctos
El sistema actualiza la BD de usuarios
Curso Alternativo #1: La clave suministrada es incorrecta
El sistema comprueba que la clave de acceso es
incorrecta
El sistema niega el acceso a la BD
El caso continúa en el paso 1
Precondiciones: En el paso 1 del flujo típico, el administrador introduce una clave de acceso

Curso Alternativo #2: El administrador no confirma los datos introducidos
El administrador no confirma que los datos sean
correctos
El sistema solicita la corrección de los datos
El administrador ingresa los datos corregidos del
usuario
Precondiciones: En el paso 4 del flujo típico, el sistema solicita la confirmación de los datos
Nombre
Caso de Uso:
Eliminar usuario
Id Caso de
Uso:
MedUSA-2
Actores: Administrador del software
Descripción: Permite al administrador del sistema eliminar a un usuario
Caso de Uso
Relacionados:
Comprobar usuario
Entradas:
Nombre del usuario a
eliminar
Salidas:
Registro de usuarios
actualizado
Curso Típico

El administrador accede a lista de usuarios existentes
El administrador selecciona la cuenta que desea
eliminar
El sistema solicita confirmación de eliminación del
usuario
El administrador confirma que desea eliminar el
usuario
El sistema actualiza la BD de usuarios
Curso Alternativo: El administrador no confirma la eliminación del usuario
El administrador no confirma que desea eliminar al
usuario
Precondiciones:
En el paso 3 del flujo típico, el sistema solicita la confirmación de la cuenta a
eliminar
Nombre
Caso de Uso:
Iniciar sesión
Id Caso de
Uso:
MedUSA-3
Actores: Todos los usuarios.
Descripción:
Permite a todos los usuarios abrir su sesión en el sistema para acceder a las
diferentes funcionalidades de la web según el tipo de usuario.

Caso de Uso
Relacionados:
Comprobar usuario
Entradas:
Datos de ingreso del
usuario
Salidas: Permisos de sesión
Curso Típico
El usuario accede al “log in” de la página web
El usuario ingresa sus credenciales de ingreso
El sistema comprueba que el usuario exista en la BD
El sistema comprueba que las credenciales de
acceso sean correctas
El sistema muestra el mensaje “Inicio de sesión
exitoso”
El sistema redirecciona al usuario a la página
principal con su respectiva sesión iniciada
Curso Alternativo: El usuario no existe
El sistema comprueba que el usuario no está
registrado en la BD
El sistema muestra el mensaje “Usuario no
registrado”

Precondiciones: En el paso 2 el usuario ingresa credenciales de ingreso inexistentes
Curso Alternativo: Credenciales de usuario incorrectas
El sistema comprueba que las credenciales de
ingreso del usuario no concuerdan
El sistema muestra el mensaje “Clave incorrecta”
Precondiciones: En el paso 2 del flujo típico, el usuario ingresa clave de usuario incorrecta
Nombre
Caso de Uso:
Consultar Balance
económico
Id Caso de
Uso:
MedUSA-4
Actores: Usuarios.
Descripción:
Permite a los usuarios consultar el balance económico de la sede a la cual tiene
acceso
Caso de Uso
Relacionados:
Registrar Pedidos
Entradas: Salidas: Balance económico
Curso Típico

1- El usuario inicia sesión introduciendo sus datos
2- El sistema verifica los datos introducidos
3-El usuario pulsa “Balance económico”
4- El sistema verifica a cuál de las sedes se tiene
acceso por parte del usuario
5- El sistema muestra un resumen del flujo de
efectivo de la sede en cuestión
Curso Alternativo #1: El usuario no existe o es inválido
El sistema comprueba que el usuario no existe o es
inválido con los datos en la BD.
El sistema muestra un mensaje, “El usuario no existe
o es inválido”.
El caso continúa en el paso 1.
Precondiciones: En el paso 1 del flujo típico, el usuario datos no registrados en la BD
Nombre
Caso de Uso:
Consultar Pedidos
Id Caso de
Uso:
MedUSA-5
Actores: Usuarios.

Descripción:
Permite a los usuarios consultar los pedidos realizados de la sede a la cual tiene
acceso
Caso de Uso
Relacionados:
Realizar Pedidos
Entradas: Permiso de sesión Salidas:
Pedidos realizados,
Inventario
Curso Típico
3-El usuario pulsa “Pedidos”
5- El sistema muestra un resumen de los pedidos de
la sede en cuestión
6- El sistema muestra un resumen del inventario de
la sede en cuestión
o es inválido”.

Nombre
Caso de Uso:
Realizar Pedidos
Id Caso de
Uso:
MedUSA-6
Actores: Usuarios.
Descripción: Permite a los usuarios realizar pedidos para la sede a la cual tiene acceso
Caso de Uso
Relacionados:
Consultar Pedidos
Entradas: Datos para pedido Salidas:
Actualización de registro
de Pedidos
Curso Típico
3-El usuario pulsa “Realizar Pedido”
5- El sistema verifica los campos de datos
disponibles para realizar el pedido

6- El usuario ingresa los datos para la realización del
pedido
7- El pedido se guarda en la BD del sistema
o es inválido”.
Nombre
Caso de Uso:
Consultar Clientes
Id Caso de
Uso:
MedUSA-7
Actores: Usuarios.
Descripción:
Permite a los usuarios consultar la lista de clientes registrados de la sede a la cual
tiene acceso
Caso de Uso
Relacionados:
Registrar Clientes
Entradas: Permiso de sesión Salidas: Lista de Clientes
Curso Típico

3-El usuario pulsa “Clientes”
5- El sistema muestra una lista de los clientes de la
sede en cuestión
o es inválido”.
Nombre
Caso de Uso:
Registrar Clientes
Id Caso de
Uso:
MedUSA-8
Actores: Usuarios.

Descripción: Permite a los usuarios ingresar clientes para la sede a la cual tiene acceso
Caso de Uso
Relacionados:
Consultar Clientes
Entradas: Datos del cliente Salidas:
Actualización de registro
de Clientes
Curso Típico
3-El usuario pulsa “Registrar Cliente”
5- El usuario ingresa los datos del cliente
6- El sistema verifica los campos de datos
disponibles para realizar el registro del cliente
7- El cliente se guarda en la BD del sistema

o es inválido”.
Precondiciones: En el paso 1 del flujo típico, el usuario ingresa datos no registrados en la BD
Curso Alternativo #2: El usuario ingresa datos erróneos.
El sistema comprueba que los datos ingresados se
correspondan con el formato establecido por la BD.
El sistema muestra un mensaje, “Los datos del
cliente son inválidos”
Precondiciones: En el paso 5 del flujo típico, el usuario ingresa datos de cliente erróneos.

7. DIAGRAMAS DE FLUJO DE DATOS

9. MODELO CONCEPTUAL DE LA BASE DE DATOS

10. MODELO FÍSICO DE LA BASE DE DATOS

Estructura de la Tabla Cliente
Estructura de la Tabla Envío

Estructura de la Tabla Mercancía
Estructura de la Tabla Usuario

11. INTERFACES DE USUARIO
Pantalla de Inicio

Pantalla del Menú
Pantalla de Pedidos

Pantalla del Balance económico

REPUBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD PRIVADA DR. RAFAEL BELLOSO CHACIN
ESCUELA DE COMPUTACION
ASIGNATURA: Ingeniería del Software 2.
Sección: C-1013
Plan de Pruebas de Software realizado a
MedUSA
REALIZADO POR:
Maracaibo; de Noviembre del 2020.

Esquema
1.- Resultados de pruebas del sistema.
1.1.- Versión Verificador.
1.1.1.- Requerimientos Funcionales.
1.1.1.1.- Caso De Uso 1.
1.1.1.1.1.- Escenario-Condición 1.
1.1.1.2.- Caso De Uso 2.
1.1.1.3.- Caso De Uso 3.
1.1.1.4.- Caso De Uso 4.
1.1.1.5.- Caso De Uso 5.
1.1.1.6.- Caso De Uso 6.
1.1.1.7.- Caso De Uso 7.
1.1.1.8.- Caso De Uso 8.
1.1.1.2.- Planilla Resumen De Casos Uso.
1.1.2.- Requerimientos No Funcionales.
1.1.2.1.- Requerimiento No Funcional 1 (Facilidad de Uso).
1.1.2.2.- Requerimiento No Funcional 2 (Seguridad).

1.1.2.2.- Requerimiento No Funcional 3 (Capacidad de uso en diferentes puntos
geográficos).
1.1.3.- Planilla Resumen Requerimiento No Funcionales.
1.1.4.- Interacción De La Integración.
1.1.5.- Evaluación.

Desarrollo
1.- Resultados de Prueba del Sistema.
Los resultados encontrados muestran que la app web de MedUSA cumple con los
requerimientos funcionales y no funcionales planteados para satisfacer las
necesidades de la organización, con una alta tolerancia a errores y diseño simple.
1.1. Versión Verificada.
La versión verificada fue la primera versión de la aplicación Web de MEDUSA la
cual está disponible en internet. Su funcionalidad consiste en visualizar un resumen
del estado financiero y administrativo de la empresa a través de la consulta de:
distribución de insumos médicos, cantidad de clientes y/o instituciones a los cuales
se les distribuye insumos, revisar el estado financiero de la empresa en cuanto a
pagos recibidos, otorgados, costos operativos, entre otros; así como registrar
nuevos clientes y pedidos que afectarán de forma directa lo visualizado en el resto
de la aplicación.
1.1.1.- Requerimientos Funcionales.
 La aplicación necesita que el usuario tenga una cuenta para poder
visualizar cualquier tipo de contenido relacionado con MEDUSA.
 Se podrá visualizar pedidos, la disponibilidad de mercancía, los
pagos, la lista de clientes, el balance económico de la compañía.
 Para realizar un nuevo pedido por parte de un cliente será
necesario insertar datos tales como RIF, dirección, correo
electrónico, entre otros.
 Para el caso de los usuarios ellos se registrarán previamente por
parte de los administradores de la base de datos de la empresa,

a fin de mantener altos estándares de seguridad en el control de
acceso.
 El sistema debe de contar con una pantalla de verificación de
credenciales. Una vez verificado esto, un menú principal donde se
visualice:
o Botones consultar Balance Económico.
o Botón Consultar Pedidos.
o Botón Registrar Pedidos.
o Botón Consultar Clientes.
o Botón Registrar Clientes.
1.1.1.1.- Caso de Uso 1:
1.1.1.1.1.- Escenario-Condicion1:
El Escenario-Condicion1 contempla el momento en el que un usuario desea
registrarse
Entrada: Datos del usuario a registrar (nombre de usuario, clave de acceso, clave
especial, país).
Resultado Esperado: Lo que se prevé que pueda registrarse al cliente y queden
asentados sus datos en la base de datos.
Resultado Obtenido: El sistema registra correctamente al usuario de forma óptima
y rápida.
Errores Encontrados: Ninguno.
1.1.1.2.- Caso de Uso 2:
Eliminación de usuario
El Escenario-Condicion1 contempla el momento en el que se desea eliminar un
usuario.

Entrada: Nombre del usuario a eliminar.
Resultado Esperado: Que se muestre una interfaz, a la cual solo tienen acceso los
administradores (DBMS) en la cual se muestre un mensaje en el cual diga “Esta
seguro de querer eliminar este usuario”, en espera de confirmación.
Resultado Obtenido: Se muestran los datos del usuario a eliminar y al presionar el
botón eliminar se muestra el mensaje indicado previamente.
En el Escenario-Condicion2 el administrador no confirma la eliminación del
usuario.
Entrada: Nombre del usuario a eliminar.
Resultado Esperado: Que se muestre una interfaz en la cual se muestran los datos
del usuario que se desea eliminar, en espera de confirmación.
Resultado Obtenido: El sistema espera a que el administrador pulse el botón
eliminar para mostrar el mensaje “Esta seguro de querer eliminar este usuario.
1.1.1.3.- Caso de Uso 3:
Ingresar al sistema (Inicio de sesión)
1.1.1.3.1.- Escenario-Condición 1:
ingresar al sistema con datos correctos.
Entrada: Datos de acceso del usuario estos son: Usuario, clave de acceso, clave
especial.
Resultado Esperado: Se espera que al conseguir en la base de datos un cliente al
cual corresponda ese nombre de usuario y esas contraseñas, se permita el ingreso.

Resultado Obtenido: El sistema no permite ingresar y muestra el mensaje para
que el usuario vuelva a intentar entrar a la aplicación.
1.1.1.3.2.- Escenario-Condición 2:
ingresar al sistema y alguno de los datos introducidos no corresponden con lo
registrado en la base de datos.
Entrada: Datos de acceso del usuario estos son: Usuario, clave de acceso, clave
especial.
Resultado Esperado: Se niega el ingreso y se muestra un mensaje “Usuario o
contraseña incorrecto”.
Resultado Obtenido: El sistema no permite ingresar y muestra el mensaje para
que el usuario vuelva a intentar entrar a la aplicación.
1.1.1.4.- Caso de Uso 4:
Se contempla la operación de consultar Balance económico.
Entrada: Datos de registro (Nombre de Usuario, clave y clave especial)
Resultado Esperado: Se prevé que el sistema muestre un conjunto de datos de
ingresos y egresos de la sede de MedUSA correspondiente.
Resultado Obtenido: Se muestran los datos del balance económico.
1.1.1.5.- Caso de Uso 5:
Este caso de uso habla de la operación consultar pedidos.

Resultado Esperado: Se prevé que el sistema muestre una tabla resumen de los
pedidos realizados por la sede de MedUSA correspondiente.
Resultado Obtenido: Se muestra la sección de consultar pedidos.
1.1.1.6.- Caso de Uso 6:
Este caso de uso habla de la operación realizar pedidos.
Entrada: Datos de pedido (Nombre Mercancía, Cantidad mercancía, Cliente, País)
Resultado Esperado: Se prevé que el sistema muestre la interfaz de realizar
pedidos donde el usuario deberá llenar un formato para poder realizar el pedido, el
cual quedará asentado en la base de datos para su visualización en otros módulos
de la aplicación.
Resultado Obtenido: Se mostró la sección realizar pedidos y al llenar los datos, se
registra correctamente.
1.1.1.7.- Caso de Uso 7:
Este caso de uso habla de la operación consultar clientes.
Resultado Esperado: Se prevé que el sistema muestre la interfaz donde se pueda
buscar y visualizar a los clientes de la sede de MedUSA correspondiente.
Resultado Obtenido: Se mostró la interfaz de visualización de clientes.

1.1.1.8.- Caso de Uso 8:
Este caso de uso habla de la operación registrar clientes.
Entrada: Datos de cliente (Nombre, Registro Legal, Dirección, Contacto, País)
Resultado Esperado: Se prevé que el sistema muestre la interfaz de registrar
clientes donde el usuario deberá llenar un formato para poder realizar el registro, el
cual quedará asentado en la base de datos para su visualización en otros módulos
de la aplicación.
Resultado Obtenido: Se mostró la sección registrar cliente y al llenar los datos, se
registra correctamente.
1.1.1.2 Planilla Resumen Casos de Uso:
Caso 1 2 2 3 3
Entradas Datos del
usuario a
registrar
(nombre de
usuario, clave
de acceso,
clave especial,
país).
Nombre del
usuario a
eliminar.
Nombre del
usuario a
eliminar.
Datos de
acceso del
usuario
estos son:
Usuario,
clave de
acceso,
clave
especial.
Datos de
acceso del
usuario
estos son:
Usuario,
clave de
acceso,
clave
especial.
Resultados
esperados
Lo que se
prevé que
pueda
registrarse al
cliente y
queden
asentados sus
datos en la
base de datos.
Que se muestre
una interfaz, a
la cual solo
tienen acceso
los
administradores
(DBMS) en la
cual se muestre
un mensaje en
el cual diga
“Esta seguro de
querer eliminar
este usuario”,
en espera de
confirmación.
Que se
muestre una
interfaz en la
cual se
muestran los
datos del
usuario que
se desea
eliminar, en
espera de
confirmación.
Se espera
que al
conseguir
en la base
de datos un
cliente al
cual
corresponda
ese nombre
de usuario y
esas
contraseñas,
se permita el
ingreso.
Se niega el
ingreso y
se muestra
un mensaje
“Usuario o
contraseña
incorrecto”.

Resultados
obtenidos
El sistema
registra
correctamente
al usuario de
forma óptima y
rápida.
Se muestran los
datos del
usuario a
eliminar y al
presionar el
botón eliminar
se muestra el
mensaje
indicado
previamente.
El sistema
espera a que
el
administrador
pulse el
botón
eliminar para
mostrar el
mensaje
“¿Está
seguro de
querer
eliminar este
usuario?”.
El sistema
no permite
ingresar y
muestra el
mensaje
para que el
usuario
vuelva a
intentar
entrar a la
aplicación.
El sistema
no permite
ingresar y
muestra el
mensaje
para que el
usuario
vuelva a
intentar
entrar a la
aplicación.
Error(S/N) No se encontró
ningún error
durante el
proceso.
No se encontró
ningún error
durante el
proceso.
No se
encontró
ningún error
durante el
proceso.
No se
encontró
ningún error
durante el
proceso.
No se
encontró
ningún
error
durante el
proceso.
Observaciones -- -- -- -- --
Escenarios-
Condiciones
1 1 2 1 2
Caso 4 5 6 7 8
Entradas Datos de
registro
(Nombre de
Usuario, clave
y clave
especial)
Datos de
registro
(Nombre de
Usuario, clave y
clave especial)
Datos de
pedido
(Nombre
Mercancía,
Cantidad
mercancía,
Cliente, País)
Datos de
registro
(Nombre de
Usuario, clave y
clave especial)
Datos de
cliente
(Nombre,
Registro
Legal,
Dirección,
Contacto,
País)
Resultados
esperados
Se prevé que
el sistema
muestre un
conjunto de
datos de
ingresos y
egresos de la
sede de
MedUSA
correspondie
nte.
Se prevé que el
sistema
muestre una
tabla resumen
de los pedidos
realizados por
la sede de
MedUSA
correspondient
e.
Se prevé que
el sistema
muestre la
interfaz de
realizar
pedidos
donde el
usuario
deberá llenar
un formato
para poder
realizar el
pedido, el
cual quedará
asentado en
la base de
datos para su
visualización
en otros
módulos de la
aplicación.
Se prevé que el
sistema
muestre la
interfaz donde
se pueda
buscar y
visualizar a los
clientes de la
sede de
MedUSA
correspondient
e.
Se prevé que
el sistema
muestre la
interfaz de
registrar
clientes
donde el
usuario
deberá llenar
un formato
para poder
realizar el
registro, el
cual quedará
asentado en
la base de
datos para su
visualización
en otros
módulos de la
aplicación.
Resultados
obtenidos
Se muestran
los datos del
balance
económico.
Se muestra la
sección de
consultar
pedidos.
Se mostró la
sección
realizar
pedidos y al
llenar los
datos, se
registra
correctament
e.
Se mostró la
interfaz de
visualización de
clientes.
Se mostró la
sección
registrar
cliente y al
llenar los
datos, se
registra
correctament
e.

Error(S/N) No se
encontró
ningún error
durante el
proceso.
No se encontró
ningún error
durante el
proceso.
No se
encontró
ningún error
durante el
proceso.
No se encontró
ningún error
durante el
proceso.
No se
encontró
ningún error
durante el
proceso.
Observaciones -- -- -- -- --
Escenarios-
Condiciones
1 1 1 1 1
1.1.2.- Requerimientos No Funcionales.
1.1.2.1.- Requerimiento No Funcional 1:
Fácil usabilidad: El sistema y sus interfaces tienen que ser de fácil comprensión y
proporcionar una experiencia de usuario de calidad, para ello se establecen como
prioridades la claridad de las interfaces de usuario y la representación jerárquica de
los elementos en las interfaces, es decir, secciones de la interfaz dedicadas a solo
una cosa en específico.
Condiciones:
Claridad de las interfaces de usuario y la representación jerárquica de los elementos
en las interfaces; fácil comprensión.
Resultado esperado:
La interfaz de usuario resulta simple para para sus operaciones como para el
manejo por parte el usuario
Resultado obtenido:
La interfaz cumple con la facilidad de uso y modularización de actividades.
Errores encontrados:
Ninguno.

1.1.2.2.- Requerimiento No Funcional 2:
Seguridad: A la información relativa al sistema deberá quedar encriptada, tanto en
la base de datos como en los envíos de información a la misma. De esta forma, se
impide que, al tener acceso a la base de datos, las contraseñas o cualquier tipo de
información sensible queden visibles, añadiendo una capa extra de seguridad.
También se verificará la entrada de datos en los formularios, evitando posibles
ataques DDoS.
Condiciones:
Se debe proteger la información de cualquier amenaza externa.
Resultado esperado:
Se impiden y previenen todo tipo de ataques maliciosos que tenga como objetivo la
desestabilización o robo de datos del sistema
Resultado obtenido:
Se logran implementar ciertas medidas para la protección de los datos.
Ninguno. Se recomienda profundizar en métodos más robustos y complejos para
salvaguardar la data.
1.1.2.3.- Requerimiento No Funcional 3 (Capacidad de uso en
diferentes puntos geográficos).
Este requerimiento podría definirse en términos de Portabilidad, ya que se requiere
que el software tenga la capacidad para llevar a cabo las mismas funciones en otros
entornos geográficos y plataformas. En este sentido, se adoptará el enfoque de
desarrollo Web, para que el sistema esté siempre disponible en el lugar desde el
que se quiera acceder, cuando se quiera acceder al mismo.

Condiciones:
El sistema debe ser capaz se ser usado en diferentes puntos geográficos.
Resultado esperado:
Se permite el acceso al sistema desde cualquier locación, siempre y cuando se
proporcionen los datos de registro correctos.
Resultado obtenido:
Se emplea un servicio de hosting con el fin de que se pueda ingresar al sistema
desde cualquier lugar.
Ninguno. Se recomienda adquirir equipos y servicios para la permanencia de la
página. Con el hosting empleado, el sistema está fuera de servicio una hora al día.
1.1.3.- Planilla Resumen Requerimiento No Funcionales.
Requerimiento
No Funcional
Condiciones Resultado
esperado
Resultado
Obtenido
1 (Usabilidad) Condición A La interfaz de
usuario resulta
simple para para
sus operaciones
como para el
manejo por parte
el usuario
La interfaz
cumple con la
facilidad de
uso y
modularización
de actividades.

2 (Seguridad) Condición A Se impiden y
previenen todo
tipo de ataques
maliciosos que
tenga como
objetivo la
desestabilización
o robo de datos
del sistema
Se logran
implementar
ciertas
medidas para
la protección
de los datos.
3 (Uso en
diversos puntos
geográficos)
Condición A Se permite el
acceso al
sistema desde
cualquier
locación,
siempre y
cuando se
proporcionen los
datos de registro
correctos.
Se emplea un
servicio de
hosting con el
fin de que se
pueda ingresar
al sistema
desde
cualquier lugar.
1.1.4.- Interacción De La Integración.
Al realizar cualquier registro en el sistema (sean clientes o pedidos), se deben
registrar correctamente en la base de datos MySQL del sistema, para su
visualización en los otros módulos del mismo. Igualmente, al realizarse una consulta
deben extraerse los datos pertinentes para que el usuario pueda conocer la
situación administrativa y financiera de la empresa.
Resultado esperado:
La lectura/escritura de información en la base de datos se hace correctamente.
Resultado obtenido:
Los datos registrados son almacenados siguiendo las restricciones impuestas por
los programadores, y estos son leídos de acuerdo a lo que se quiera visualizar.

Ninguno.
1.1.5.- Evaluación.
Los resultados encontrados muestran que la WebApp de MedUSA cumple con los
requerimientos funcionales y no funcionales planteados para satisfacer las
necesidades de la organización, con una alta tolerancia a errores y diseño simple.

REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD RAFAEL BELLOSO CHACÍN
ESCUELA DE COMPUTACIÓN
CÁTEDRA: BASES DE DATOS
SECCIÓN: C-1013
MANUAL DE USUARIO DE LA APLICACIÓN
WEB DE MEDUSA
PRESENTADO POR:
Maracaibo, Noviembre del 2020

SOFTWARE MEDUSA
En este documento se describen los objetivos e información precisa y concisa
de cómo utilizar la Aplicación Web de MEDUSA y su funcionamiento.
La compañía MEDUSA realiza sus operaciones en dos países diferentes
siendo estos: Estados Unidos y Venezuela. Realizando en Estados Unidos los
procesos de importación de todos los insumos médicos, y exportándolos hacia
Venezuela para que allí sean distribuidos a los distintos centros de salud de acuerdo
a los encargos de los mismos de acuerdo a sus necesidades. Además, también se
suministran insumos a distintos centros de salud en los Estados Unidos.
En ambas sedes se realizan múltiples labores administrativas, de
distribución, se realizan pedidos y pagos, todo esto ahora puede conocerse y
realizarse por medio de la Aplicación Web de MEDUSA sin importan el lugar donde
se encuentre la persona que realice la consulta en cuestión.

OBJETIVO DE ESTE MANUAL DE USUARIO
El objetivo primordial de este Manual es ayudar y guiar al usuario a utilizar la
Aplicación Web de MEDUSA, entender cada una de las funcionalidades de las
distintas pestañas, así como conocer a que datos tendrán acceso los usuarios. Los
objetivos específicos para llegar a conseguir este objetivo principal son:
 Guía para acceder e ingresar a la Aplicación Web.
 Conocer cómo utilizar el sistema mediante una descripción detallada e
ilustrativa.
 Conocer las distintas pestañas y las funcionalidades de cada uno, así como
los diferentes datos que muestra cada una.
Este manual va dirigido a los distintos usuarios de MEDUSA ya sean
empleados o usuarios que deseen conocer algún dato en específico de la compañía.
CONOCIMIENTOS BÁSICOS PARA EL MANEJO DE LA APLICACIÓN WEB
Los conocimientos mínimos que deben tener los distintos usuarios que
deseen operar en esta aplicación son:
 Conocimientos básicos de Navegación Web.
 Conocimientos básicos en manejo de páginas web para poder ingresar y
llegar hasta la pestaña que desean visualizar.

BENEFICIOS DE LA APLICACIÓN WEB
El beneficio principal de esta app es simplificar y poder visualizar todo lo que
normalmente se maneja dentro de una compañía en papeles, la desventaja de esto
es que lo más común es que los registros, cuentas y otros datos de una sede solo
puedan conocerse en esa misma sede porque es allí donde se manejan esos datos
por tanto es necesario enviar los datos por fax o por otro medio para poder visualizar
algún dato en la otra sede.
Por tanto, el beneficio principal que ofrece esta aplicación es poder tener
acceso a todos los datos de ambas sedes en tiempo real a medida que se generan
estos datos en una misma aplicación con solo tener acceso a internet desde
cualquier dispositivo de preferencia como una Tablet, teléfono inteligente, o
computadora desde el lugar en donde se encuentre el usuario.
ESPECIFICACIONES TÉCNICAS.
Para la visualización de la Aplicación Web de MEDUSA requerimos lo
siguiente:
Hardware: No se requiere una especificación en específico de hardware,
todo el hardware de los distintos equipos es compatibles para interactuar con
esta Aplicación. Se requiere conexión a internet.
Navegador Requerido: En caso de querer ingresar desde un dispositivo
móvil ya sea una tabled, ipad o un teléfono es necesario descargar o tener en el
equipo un navegador ya sea el predeterminado que traen los equipos o el de
preferencia del usuario pudiendo ser Safari (para Iphones y Ipads), Google
Chrome, Opera, entre otros.
En caso de ingresar desde una pc ya sea de escritorio o laptop es necesario
tener instalado un navegador ya sea Mozilla Firefox, Google Chrome, Microsoft
Edge o cualquier otro de su preferencia.

INTERFACES DE LA APLICACIÓN WEB DE MEDUSA
Ingresar: En la pantalla de ingreso se visualizará un formulario que es
necesario llenar para tener acceso a la información de MEDUSA, datos como
nombre de usuario, clave y clave especial de seguridad. Si se llena el formulario
el usuario será redireccionado al menú.
Menú: Esta pantalla es a la que se redirige luego de iniciar sesión, en ella se
visualizaran distintas opciones en forma de lista las cuales se encargan de
redirigir al usuario según la opción sobre la cual haga click ya sea pedido,
mercancía, clientes o balance económico.
Pedidos: Se muestra una interfaz en la cual se puede hacer click para
realizar un nuevo pedido, en caso de hacer click se muestra un formulario que
es necesario llenar para realizar el pedido en el cual deben especificarse datos
de la institución como Id, nombre, dirección, entre otros sumado a la cantidad de
productos y nombre de los mismos.
Mercancía: La interfaz muestra la información registrada de manera
organizada correspondiente a los tipos y cantidades de productos disponibles.
Allí se especifica si estas cantidades corresponden a una importación o
exportación, el país y cantidad total, en caso de querer ingresar un nuevo
producto será necesario hacer click en dicha opción, luego de esto se desplegará
un formulario que será necesario llenar en el cual será necesario indicar el
nombre del producto, Id, tipo, costo y cantidad disponible o cantidad total.
Balance Económico: Se observan los distintos datos correspondientes a la
compañía MEDUSA siendo estos: Los pagos realizados al personal en ambas
sedes, gastos administrativos, entre otros.
Nota: Es necesario hacer click una sola vez para poder acceder a la interfaz
de su preferencia.

IMÁGENES ILUSTRATIVAS DE LA PÁGINA:
1.-Ingresar: En la pantalla de ingreso se visualizará un formulario que es
necesario llenar para tener acceso a la información de MEDUSA, datos como
nombre de usuario, clave y clave especial de seguridad. Si se llena el formulario el
usuario será redireccionado al menú.
2.-Menu: Esta pantalla es a la que se redirige luego de iniciar sesión, en ella
se visualizaran distintas opciones en forma de lista las cuales se encargan de
redirigir al usuario según la opción sobre la cual haga click ya sea pedido,
mercancía, clientes o balance económico.

3.-Pedidos: En esta sección se visualizan los pedidos realizados y también
existe la opción para realizar nuevos pedidos, al pulsar en nuevo pedido se mostrará
un formulario para ingresar los datos del mismo.

4.-Mercancia: En esta sección se muestran los insumos médicos disponibles
en inventario (medicamentos, implementos, entre otros productos) y también existe
la opción de ingresar nuevos artículos, al pulsar en nuevo producto se mostrará un
formulario para ingresar los datos del mismo.
.
5.-Clientes: En esta sección se muestran los clientes de MedUsa y es posible
añadir un nuevo cliente si el usuario lo desea llenando una serie de campos dentro
de un formulario.

6.-Balance económico: En esta pestaña se aprecian los distintos ingresos
y egresos de la compañía MedUsa en base a los distintos gastos operativos de la
misma mostrados a detalle en una tabla y que varían en función de los pedidos.

ERRORES COMUNES
El usuario no existe: Esto se muestra en caso de que el usuario no corresponde
con un usuario de MedUsa. Se recomienda verificar los datos mientras están siendo
ingresados antes de dar click a entrar.
Contraseña incorrecta: Se muestra en caso de que el usuario haya ingresado un
usuario registrado en MedUsa pero la contraseña del mismo no corresponde con su
usuario.
Completa este campo: Esto se muestra en caso de no ingresar algún dato
correspondiente en uno de los formularios ya sea el de pedido, clientes u otro. Es
fundamental llenar todos los datos en cada formulario debido a que todos los datos
allí contemplados son muy importantes.

Documentacion MEDUSA

Recomendados

Recomendados

Más contenido relacionado

Similar a Documentacion MEDUSA

Similar a Documentacion MEDUSA (20)

Último

Último (20)

Documentacion MEDUSA