Esta es nuestra presentación del manual del analista de nuestro software, que se encarga de un sistema de compra de medicamentos.

1. MANUAL DEL ANALISTA
Software para la gestión de envíos de la empresa Farmaservicios
Verificadores:
 Fernández, José
 Urriola, Orlando

2. PLAN DE PRUEBAS
Resultados de Prueba del Sistema.
Los resultados obtenidos muestran que la aplicación web de Farmaservicios cumple con los requerimientos
funcionales y no funcionales estipulados para satisfacer las necesidades de la organización, con un diseño simple que
cualquiera usuario puede manejar.
1. Versión Verificador.
La versión verificada fue la primera versión de la aplicación Web de Farmaservicios la cual está disponible en
internet. Su funcionalidad consiste en el control de la materia prima de la cual dispone la empresa, un listado de ventas
realizadas; y además un listado de proveedores e clientes. La página es manejada principalmente por usuarios de 3 roles:
Administrador, Supervisor y Vendedor.
El administrador controla cada aspecto de la página, puede realizar envíos, agregar proveedores e clientes nuevos
a la página y además se encarga directamente de registrar en ella los productos que envían los distintos proveedores. Éste
también puede registrar otros usuarios a la página y asignarle a ellos uno de los 3 roles, a su vez éste puede visualizar el
listado(registro) de cada una de las cosas mencionadas.

3. Un usuario con rol de Vendedor posee la capacidad de hacer ventas en la página, puede acceder al inventario
de productos y verificar disponibilidad de los mismo, sin embargo no puede agregar más de ellos al inventario. Éste es
libre de añadir mas clientes a la lista y también puede editarlos de haber algún dato erróneo o eliminarlos de ser
necesario. Sólo los vendedores y administradores pueden realizar envíos.
Un usuario con rol de Supervisor puede revisar los listados y registros en la página, pero únicamente
visualizarlos. No tiene permitido modificar o agregar algo a la página.
2.- Requerimientos Funcionales
 La aplicación necesita que el usuario tenga una cuenta para poder visualizar cualquier tipo de contenido relacionado con
Farmaservicios.
 Los usuarios no podrán visualizar o utilizar funciones en la pagina fuera de las que dispone su rol.
 Se podrá visualizar envíos, la disponibilidad de mercancía, los pagos, la lista de clientes y la lista de proveedores.
 Para realizar un envío se necesita la información del cliente, éste se busca por DNI. Los administradores y vendedores
son los que registran dichos clientes
 Para agregar un producto al inventario es necesario especificar de qué proveedor viene dicho producto. Sólo los
administradores pueden hacer esto.
 La página debe crear una factura al haberse realizado una venta.

4. 2.1.-Caso de uso 1:
Este caso de uso hace referencia al momento de ingresar al sistema
Entrada: Datos del usuario
Resultado esperado: Permitir el acceso del usuario y avisar si el usuario no existe o tiene un dato erróneo.
Resultado obtenido: Los tres usuarios pueden ingresar y un usuario no registrados no tiene acceso.
Errores encontrados: - - -
2.2.-Caso de uso 2:
Este caso hace referencia a la interfaz del sistema en el index, donde se despliegan las funciones de la app web
Entrada: Elegir una opción dentro de la pagina entre: “Clientes”, “Ventas”, “Usuarios”, “Productos”, “Proveedores” “Envios”,
Resultado esperado: El administrador puede acceder a todas. El supervisor a todos los listados y el vendedor solamente a
ventas, productos y clientes.
Resultado obtenido: Los tres usuarios pueden ingresar a sus respectivas áreas dependiendo de su rol. No se despliegan en
la interface las opciones a las que el usuario no puede acceder
Errores encontrados: - - -

5. 2.3.-Caso de uso 3:
Este caso de uso hace referencia al momento de registrar un nuevo usuario.
Entrada: Datos del usuario nuevo. Ingresado por el administrador
Resultado esperado: El nuevo usuario se registra en la base de datos y puede iniciar sesión en el sistema.
Resultado obtenido: El nuevo usuario puede acceder al sistema con su rol correspondiente.
Errores encontrados: - - -
2.4.-Caso de uso 4:
Este caso de uso hace referencia al momento de registrar un nuevo cliente.
Entrada: Datos del cliente nuevo. Ingresado por el administrador y el vendedor
Resultado esperado: El nuevo cliente se registra en la base de datos y está disponible en la opción de envío de
productos.
Resultado obtenido: El cliente se registra exitosamente y queda agregado al listado de clientes.
Errores encontrados: - - -

6. 2.5.-Caso de uso 5:
Este caso de uso hace referencia al momento de registrar un nuevo proveedor.
Entrada: Datos del proveedor nuevo. Ingresado por el administrador
Resultado esperado: El nuevo proveedor se registra en la base de datos y los productos del sistema ahora tienen
como procedencia dicho proveedor al momento de agregarse.
Resultado obtenido: El proveedor se registra exitosamente y su información puede verse en el listado de proveedores,
y a su vez, al momento de registrar un nuevo producto éste puede tener procedencia de dicho proveedor
Errores encontrados: - - -
2.6.-Caso de uso 6:
Este caso de uso hace referencia al momento de registrar un nuevo producto.
Entrada: Datos del producto nuevo. Ingresado por el administrador
Resultado esperado: El producto nuevo es registrado en la base de datos.
Resultado obtenido: El producto nuevo se registra sin problemas, se puede observar en el listado
Errores encontrados: - - -

7. 2.7.-Caso de uso 7:
Este caso de uso hace referencia al momento de editar algún dato en la página. Dato como la información de un
producto, proveedor, usuario o cliente.
Entrada: listado de productos -> Editar ; Listado de clientes -> Editar ; Listado de proveedores -> Editar ; Listado de
usuarios -> Editar.
Resultado esperado: La modificación se realiza tanto en la página como en la base de datos. Los supervisores no pueden
acceder a esta opción y los vendedores solo pueden editar clientes.
Resultado obtenido: Efectivamente la modificación se realizo con éxito en todos los campos mencionados.
Errores encontrados: - - -
2.8.-Caso de uso 8:
Este caso de uso hace referencia al momento de realizar un envío
Entrada: Nuevo envío -> información del cliente, selección de productos.
Resultado esperado: No se le puede enviar productos a un cliente no registrado en la base de datos. Y de igual forma no
se pueden enviar productos inexistentes. Al presionar enviar se genera una factura en formato pdf.
Resultado obtenido: No es posible hacer el envío sin la información correcta del cliente ni tampoco se pueden enviar
productos inexistentes o no disponibles por stock. La factura se crea al presionar el botón “Generar venta”, al mismo tiempo
el envío queda registrado en “factura de envíos”. Con fecha y monto total.
Errores encontrados: - - -

8. Casos 1 2 3 4 5
Entradas Datos del usuario
en el login
Elegir una opción
dentro de la pagina
entre: “Clientes”,
“Ventas”, “Usuarios”,
“Productos”,
“Proveedores”
“Envíos”,
Datos del usuario
nuevo. Ingresado
por el
administrador
Datos del cliente
nuevo. Ingresado
por el
administrador y el
vendedor
Datos del proveedor
nuevo. Ingresado por el
administrador
Resultados
esperados
Permitir el
acceso del
usuario y avisar
si el usuario no
existe o tiene un
dato erróneo.
El administrador
puede acceder a
todas. El supervisor a
todos los listados y el
vendedor solamente a
ventas, productos y
clientes.
El nuevo usuario
se registra en la
base de datos y
puede iniciar
sesión en el
sistema.
El nuevo cliente se
registra en la base
de datos y está
disponible en la
opción de envío de
productos.
El nuevo proveedor se
registra en la base de
datos y los productos del
sistema ahora tienen
como procedencia dicho
proveedor al momento
de agregarse.
Resultados
obtenidos
Los tres usuarios
pueden ingresar
y un usuario no
registrados no
tiene acceso.
Los tres usuarios
pueden ingresar a sus
respectivas áreas
dependiendo de su
rol.
El nuevo usuario
puede acceder al
sistema con su rol
correspondiente.
El cliente se registra
exitosamente y queda
agregado al listado de
clientes.
El proveedor se registra
exitosamente y su
información puede verse en
el listado de proveedores, al
momento de registrar un
nuevo producto éste puede
tener procedencia de dicho
proveedor
Errores No No No No No
Observaciones - - - - - - - - - - - - - - -
2.9.-
Planilla
Resumen
Casos
de
Uso:

9. Casos 6 7 8
Entradas Datos del producto
nuevo. Ingresado por
el administrador
listado de productos -> Editar ;
Listado de clientes -> Editar ;
Listado de proveedores -> Editar
; Listado de usuarios -> Editar.
Nuevo envío ->
información del cliente,
selección de productos.
Resultados
esperados
El producto nuevo es
registrado en la base
de datos
La modificación se realiza tanto
en la página como en la base de
datos. Los supervisores no
pueden acceder a esta opción y
los vendedores solo pueden
editar clientes.
No se le puede enviar
productos a un cliente no
registrado en la base de datos.
Y de igual forma no se pueden
enviar productos inexistentes.
Al presionar enviar se genera
una factura en formato pdf.
Resultados
obtenidos
El producto nuevo
se registra sin
problemas, se
puede observar en
el listado
Efectivamente la modificación
se realizo con éxito en todos los
campos mencionados.
No es posible hacer el envío sin la
información correcta del cliente ni
tampoco se pueden enviar
productos inexistentes o no
disponibles por stock. La factura se
crea al presionar el botón “Generar
venta”, al mismo tiempo el envío
queda registrado en “factura de
envíos”. Con fecha y monto total.
Errores No No No
Observaciones - - - - - - - - -

10. 3.- Requerimientos no funcionales:
Los requerimientos no funcionales estarán basados netamente en desempeño y funcionabilidad, para así
exponer el menor de los potenciales errores en el software.
3.2.- Requerimiento No Funcional 2: Fácil uso de la aplicación
Condiciones: 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 cuales funciones puede
hacer cada rol
Resultado esperado: La interfaz de usuario resulta simple para para sus operaciones como para el manejo por parte el
usuario
Resultado obtenido: La interfaz muestra las funciones que puede realizar cada usuario. En la ocurrencia de seleccionar
una función que el usuario no pueda usar por restricción de rol la página no permite el acceso.
Errores encontrados: - - -
3.1.- Requerimiento No Funcional 1: Seguridad en la aplicación
Condiciones: Toda la información sensible debe ser encriptada tanto en la base de datos como en los envíos de
información a la misma. De igual manera al cambiar la contraseña desde la página ésta queda protegida y se permite el
acceso de inmediato con la nueva contraseña. También se verificará la entrada de datos en los formularios, evitando
posibles ataques DDoS. Y se prohíbe el acceso a páginas fuera del rol correspondiente para evitar cambios.
Resultado esperado: Toda la información se registra encriptada, aún cuando ésta es modificada. El rol prohíbe el acceso
de funciones en la página
Resultado obtenido: La encriptación se realiza en la base de datos y el acceso a la pagina funciona perfectamente. El rol
sigue prohibiendo las funciones.
Errores encontrados: - - -

11. Casos 1 2
Condiciones Toda la información sensible
debe ser encriptada tanto en la
base de datos como en los
envíos de información a la
misma.
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 cuales funciones puede hacer
cada rol
Resultados
esperados
Toda la información se registra
encriptada, aún cuando ésta es
modificada. El rol prohíbe el
acceso de funciones en la página
La interfaz de usuario resulta
simple para para sus
operaciones como para el
manejo por parte el usuario
Resultados
obtenidos
La encriptación se realiza en la
base de datos y el acceso a la
pagina funciona perfectamente.
El rol sigue prohibiendo las
funciones.
La interfaz muestra las
funciones que puede realizar
cada usuario. En la ocurrencia
de seleccionar una función que
el usuario no pueda usar por
restricción de rol la página no
permite el acceso.
Errores No No
Observaciones - - - - - -
3.3.-
Planilla
Resumen
Casos
de
Uso:

12. 4.- Interacción De La Integración.
Los datos ingresados tanto en la base de datos como en la página deben funcionar en cada apartado de la misma,
especialmente el inventario debe actualizarse con respeto a los productos obtenidos por los proveedores y los enviados a los
clientes.
Resultado esperado: La lectura/escritura de información en la base de datos se hace correctamente y se muestra en la
página.
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. Sin embargo, el hosting gratuito no permite algunas de las
funciones de éste proyecto.
Errores encontrados: Un error que se presenta en la etapa final del proyecto es al momento de subir nuestra base de
datos a un hosting gratuito. Ocurre que la base de datos que se creó para el desarrollo de las actividades en el sistema se le
agregaron unos "Procedimientos" que son códigos que se ejecutan en la base de datos como funciones que se llaman
dentro del código php por medio de un "Query". Por tener dichos "procedimientos" en la base de datos, al momento de
subirla al Hosting gratuito ocurrió que los procedimientos, que hacían funciones indispensables para el software, no pudieron
importarse ya que para usarlos se es necesario pagar una suscripción al servicio de hosting, ya que estas “tareas” causan
un tráfico mayor y por ello las cuentas gratis no pueden hacer uso de ellas. El error se les mostrara a continuación:

13. 5.- Evaluación.
Los resultados encontrados muestran que la aplicación web de farmaservicios cumple con los
requerimientos funcionales y no funcionales planteados para satisfacer las necesidades de la organización, con un
diseño simple y una interfaz fácil de usar. Ésta no puede hacer uso de un hosting gratuito, pero es perfectamente
funcional de manera local o en un hosting de pago.

14. 6.- Base de datos – Modelo conceptual
Modelo Físico
DIAGRAMA E-R

15. BASE DE DATOS – MODELO CONCEPTUAL
DIAGRAMA E-R

18. DICCIONARIO DE DATOS

22. PRESENTACIÓN DE DIAGRAMAS

23. 7.- Cronograma de actividades
Diagrama GANTT

24. Actividad Fases
Inicio Final
Tiempo
Estudiar
Estruturar el
diseño logico de la
Aplicación Web y
generar el codigo
17-ene
18-ene
19-ene
20-ene
Discutir
Estudiar y discutir
los requisitos del
software
Enero
21-ene
22-ene
11-ene
12-ene
13-ene
14-ene
15-ene
16-ene
29-ene
30-ene
31-ene
23-ene
24-ene
25-ene
26-ene
27-ene
28-ene
1-feb
2-feb
3-feb
4-feb
5-feb
6-feb
13-feb
14-feb
15-feb
16-feb
7-feb
8-feb
9-feb
10-feb
11-feb
12-feb
febrero
20-ene
11-ene
21-ene 25-ene
Pruebas de
rendimiento
Correccion
de errores
23-mar 7-abr
8-abr 15-abr
Estructurar
Generar
codigo
26-ene 26-feb
27-feb 22-mar
Realizar pruebas
de rendimiento
intensivas para
correccion de
errores
Entrega 16-abr 16-abr

25. 8.- Diagrama de Actividades

30. 9.-DIAGRAMA DE FLUJO DE DATOS
NIVEL 0 Y 1

33. 10.-DIAGRAMA DE CASOS DE USO