Proyecto Completo

“Año del Diálogo y la reconciliación Nacional”
Escuela Profesional de Ingeniería de

Sistemas e Informática
PROYECTO:
“Análisis y Diseño de un Sistema de Ventas para la Farmacia San
Pedro usando la Metodología Orientada a Objetos en la Ciudad de
Chimbote del Año 2018”
INTEGRANTES:
Burgos Ramírez Erwin
Cervera Quiroz Noemí
Laiza Rodríguez Ángel
Medina Quilcat Diego
DOCENTE:
Ing. Carlos Mendoza Corpus
CURSO:
Sistemas de Información I
E.A.P. SISTEMAS E INFORMÁTICA SISTEMAS DE INFORMACIÓN
INTRODUCCION
Con el pasar de los años, los sistemas de información han evolucionado a gran
escala, adaptándose a la tecnología de esta época y de la misma forma su esencia
de organizar y salvaguardar la información se ha tornado más compleja.
El término Sistemas de información se emplea en múltiples campos y/o

disciplinas, y en cada cual se le ha establecido un significado, tomándose como
significado general al conjunto ordenado de elementos (no necesariamente
computacionales) que permiten manipular toda aquella información necesaria
para implementar aspectos específicos que contribuyan a la toma de decisiones.
Los SI son herramientas muy importantes en los negocios ya que pueden

automatizar tareas, lo que traería consigo el aprovechamiento para un mejor uso
del tiempo que con anterioridad se desperdiciaba por la excesiva cantidad de
información con la que una organización trabaja. Se debe tener en cuenta que el
recurso humano es un factor importante ya que será este quien interactúe con el
sistema.
En el siguiente proyecto se va analizar y diseñar un sistema de información para

la empresa San Pedro, la cual está centrada en la venta de productos
farmacéuticos.
2
RESUMEN
La presente investigación se fundamenta en seis capítulos.
El primer capítulo, describe el marco teórico conceptual, esto incluye los datos
generales de la empresa, tales como su ubicación, misión, visión, organigrama y
misión FODA.
El segundo capítulo, detalla el funcionamiento del sistema actual de la empresa,
el proceso de recopilación de información seguido de la formulación del
problema.
El tercer capítulo, especifica los requisitos de software, siguiendo el estándar
ANSI/IEEE 830. Aquí se definen los requisitos funcionales y no funcionales del
futuro sistema.
El cuarto capítulo, describe el análisis y diseño del sistema, esto incluye los
diferentes tipos de diagrama UML, tales como Diagrama de Secuencia, Diagrama
de Colaboración, Diagrama de Clases y Diagrama de Actividades.
El quinto capítulo, refleja un prototipo del futuro sistema a implementar, este
abarca los diferentes módulos disponibles para el usuario.
Por último, el sexto capítulo, evalúa económicamente el proyecto, así como el
estudio de viabilidad, de costos y beneficios del mismo.
Palabras Clave: Sistema, Modelo en Cascada, Ciclo de Vida del Software,
Requisitos Funcionales, Requisitos No Funcionales, Casos de Uso, Diagramas
UML.
3
ABSTRACT
This research is based on six chapters.
The first chapter, describes the conceptual theoretical framework, this includes
the general data of the company, such as its location, mission, vision, organization
chart and mission SWOT.
The second chapter details the operation of the company's current system, the
process of collecting information followed by the formulation of the problem.
The third chapter specifies the software requirements, following the ANSI/IEEE
830 standard. The functional and non-functional requirements of the future
system are defined here.
The fourth chapter describes the analysis and design of the system, this includes
the different types of UML diagrams, such as sequence diagram, collaboration
diagram, class diagram and activity diagram.
The fifth chapter, reflects a prototype of the future system to be implemented,

this covers the different modules available to the user.
Finally, the sixth chapter, evaluates economically the project, as well as the
feasibility study, of costs and benefits thereof.
Key words: System, Cascade model, Software Lifecycle, functional requirements,
non-functional requirements, use cases, UML diagrams.
4
CONTENIDO
INTRODUCCION............................................................................................................................................ 2
RESUMEN ......................................................................................................................................................... 3
ABSTRACT ........................................................................................................................................................ 4
Nombre Del Proyecto: .............................................................................................................................. 10
Objetivo General: ........................................................................................................................................ 10
Objetivos Específicos:................................................................................................................................ 10
CAPITULO I .................................................................................................................................................. 11
1.1. Datos Generales de la Empresa .......................................................................................... 11
1.1.1. Ubicación Geográfica .................................................................................................... 11
1.1.2. Base Legal .......................................................................................................................... 12
1.1.3. Áreas que corresponde ................................................................................................. 12
1.1.4. Reseña Histórica y Operacional ................................................................................. 13
1.1.5. Visión ................................................................................................................................... 13
1.1.6. Misión .................................................................................................................................. 13
1.1.7. Organigrama ..................................................................................................................... 14
1.1.8. Análisis FODA ................................................................................................................... 15
CAPITULO II ................................................................................................................................................. 16
2.1. Acciones Preliminares............................................................................................................. 16
2.1.1. Ciclo de Vida de desarrollo de SW ........................................................................... 16
2.2. Recopilación de la Información .......................................................................................... 18
2.2.1. Entrevista para obtener requerimientos................................................................. 18
2.2.2. Hardware Disponible ..................................................................................................... 19
2.2.3. Distribución de Equipo ................................................................................................. 20
2.3. Formulación del Problema ................................................................................................... 21
2.4. Análisis de Tiempo................................................................................................................... 21
2.5. Análisis del Proceso ................................................................................................................. 24
CAPITULO III ............................................................................................................................................... 25
3.1. Ficha del Documento .............................................................................................................. 25
3.2. Contenido.................................................................................................................................... 25
3.2.1. Introducción ...................................................................................................................... 25
3.2.2. Propósito ............................................................................................................................ 25
3.2.3. Alcance ................................................................................................................................ 26
3.2.4. Personal Involucrado ..................................................................................................... 26
3.2.5. Definiciones, Acrónimos y Abreviaturas ................................................................. 27
3.2.6. Referencias ........................................................................................................................ 27
5
3.2.7. Resumen ............................................................................................................................. 27

3.3. Descripción General ................................................................................................................ 28
3.3.1. Perspectiva del Producto ............................................................................................. 28
3.3.2. Funcionalidad del Producto ........................................................................................ 28
3.3.3. Características de los Usuarios................................................................................... 28
3.3.4. Restricciones ..................................................................................................................... 29
3.3.5. Suposiciones y Dependencias .................................................................................... 29
3.3.6. Evolución previsible del sistema ............................................................................... 29
3.4. Requisitos Específicos............................................................................................................. 29
3.4.1. Requisitos comunes de las interfaces ..................................................................... 29
3.4.2. Interfaces de Usuario ..................................................................................................... 30
3.4.3. Interfaces de Hardware ................................................................................................. 30
3.4.4. Interfaces de Software................................................................................................... 30
3.4.5. Interfaces de Comunicación........................................................................................ 30
3.5. Requisitos Funcionales ........................................................................................................... 31
3.1.1. Requisito Funcional 1 .................................................................................................... 31
3.6. Requerimientos No Funcionales ........................................................................................ 35
3.2.1. Requerimientos No Funcionales 1............................................................................ 35
3.2.6. Requerimiento No Funcional 6 .................................................................................. 36
CAPITULO IV ................................................................................................................................................. 38
4.1. Descripción de las metodologías más usadas .............................................................. 38
4.2. Fundamentación de la metodología seleccionada ..................................................... 40
4.3. Análisis y Diseño ....................................................................................................................... 41
6
4.3.1. Documento de Casos de Uso ..................................................................................... 41

4.3.2. Diagrama de Caso de Uso ........................................................................................... 49
4.3.3. Diagrama de Secuencia ....................................................................................................... 54
4.3.4. Diagrama de Colaboración ................................................................................................ 60
4.3.5. Diagrama de Clases .............................................................................................................. 66
4.3.6. Diagrama de Actividades .................................................................................................... 66
4.4. Implementación de la Base de Datos ............................................................................... 75
4.4.1. Diseño Conceptual ................................................................................................................ 75
4.4.2. Diseño Lógico.......................................................................................................................... 79
4.4.3. Diseño Físico ............................................................................................................................ 83
CAPITULO V .................................................................................................................................................. 84
5.1. Diseño de interfaces de prototipo .......................................................................................... 84
CAPITULO VI ................................................................................................................................................. 89
6.1. Estudio de Viabilidad ................................................................................................................... 89
6.1.1. Viabilidad Tecnológica ........................................................................................................ 89
6.1.2. Viabilidad Operacional ........................................................................................................ 89
6.1.3. Viabilidad Económica ........................................................................................................... 89
6.2. Estudio de costo y beneficiación ............................................................................................. 90
6.2.1. Costos para la implementación........................................................................................ 90
6.2.2. Beneficios de la Implementación..................................................................................... 94
CONCLUSIONES .......................................................................................................................................... 95
RECOMENDACIONES ................................................................................................................................ 95
BIBLIOGRAFIA............................................................................................................................................... 96
GLOSARIO...................................................................................................................................................... 97
ANEXOS .......................................................................................................................................................... 98
7
INDICE DE IMAGENES
Imagen 1. Farmacia San Pedro .............................................................................................................. 11

Imagen 2. Ubicación de la Farmacia San Pedro.............................................................................. 11
Imagen 3. Organigrama de la Farmacia San Pedro ....................................................................... 14
Imagen 4. Análisis FODA de la Farmacia San Pedro ..................................................................... 15
Imagen 5. Procedimiento del Modelo Cascada .............................................................................. 17
Imagen 6. Análisis Total del Tiempo ................................................................................................... 21
Imagen 7. Análisis del Tiempo de: Apertura y Requerimientos de la Investigación ......... 22
Imagen 8. Análisis del Tiempo: Requerimientos del Software .................................................. 23
Imagen 9. Análisis del Tiempo: Análisis del diseño y sistema, Interfaces y Evaluación
Económica del Proyecto........................................................................................................................... 23
Imagen 10. Diagrama de Procesos en el SW Bizagi ...................................................................... 24
Imagen 11. Funcionalidad del Producto ............................................................................................ 28
Imagen 12. Modelo de Desarrollo Evolutivo (ESPIRAL) ............................................................... 39
8
INDICE DE TABLAS
Tabla 1. Personal Involucrado ................................................................................................................ 26

Tabla 2. Definiciones y Acrónimos utilizados. ................................................................................. 27
Tabla 3. Referencias Utilizadas .............................................................................................................. 27
Tabla 4. Características de los Usuarios ............................................................................................. 28
9
Nombre Del Proyecto:
“Análisis y Diseño de un Sistema de Ventas para la Farmacia San Pedro usando la

Metodología Orientada a Objetos en la Ciudad de Chimbote del Año 2018”
Objetivo General:
Realizar el análisis y diseño del sistema de ventas para la farmacia San Pedro
usando la metodología orientada a objetos.
Objetivos Específicos:
 Recabar información del sistema con el que opera actualmente la farmacia.
 Identificar y definir la problemática de la empresa.
 Reconocer los modelos de negocio.
 Determinar los requisitos funcionales y no funcionales que se pretenda

para el futuro sistema.
 Establecer los casos de usos necesarios para el funcionamiento del

sistema.
10
CAPITULO I
Marco Teórico Conceptual

1.1. Datos Generales de la Empresa
1.1.1. Ubicación Geográfica
La Farmacia San Pedro se encuentra ubicada en la Av. José Olaya

#567, Chimbote.
Imagen 1. Farmacia San Pedro
Imagen 2. Ubicación de la Farmacia San Pedro
11
1.1.2. Base Legal
Criterios Éticos para la Promoción de Medicamentos de la Comunidad

Andina, de la Red Parf y la OMS, entre tanto se aprueba los Criterios de
la ANS de Perú.
 Ley Nº 27657 - Ley del Ministerio de Salud.
 Ley Nº 27444- Ley del Procedimiento Administrativo General, y

su modificatoria aprobada por Decreto Legislativo Nº 1029.
 Ley N° 29459- 2009 Ley de los Productos Farmacéuticos,

Dispositivos Médicos y Productos Sanitarios. Capítulo X de la
Promoción y Publicidad.
 Decreto Legislativo Nº 1044 -2008 Ley de Represión de la

Competencia Desleal.
 Decreto Supremo N° 013-2002-SA Reglamento de la Ley del

Ministerio de Salud.
 Decreto Supremo N° 023-2005 Reglamento de Organización y

Funciones del Ministerio de Salud. Artículo 55°.
 Decreto Supremo N° 016-2011-SA-Reglamento para el Registro

Control y vigilancia sanitaria de productos farmacéuticos,
dispositivos médicos y productos sanitarios, y su Modificatoria
D.S. Nº 001-2012-SA.
 Decreto Supremo N° 014-2011-SA-Reglamento de

Establecimientos Farmacéuticos, y su modificatoria DS Nº 002-
2012-SA
1.1.3. Áreas que corresponde
Inventario:
En el área de almacén, se desarrollan los siguientes procesos:
 Se controla las reservas de los medicamentos y la información de

estos productos (fecha de vencimiento, cantidad, entrada y salida
de productos).
12
Área de venta:
En el área de venta, de desarrollan los siguientes procesos:
 Se registra los datos de los clientes (Nombre, DNI, Dirección)

 Se registra la salida de productos.
1.1.4. Reseña Histórica y Operacional
Es una empresa familiar que se originó en el año 1960, ubicada,

primero en la novena cuadra de Olaya y después en la quinta cuadra
de Olaya. La actual representante legal es la señora María Julia
Plasencia
A principios del 2018 falleció el padre de la señora María Julia Plasencia

entonces su hermano Pedro Delfín Plasencia Quiñones quedó a cargo
de la parte administrativa.
La farmacia San Pedro a diferencia del resto de farmacia de Chimbote,

tiene un recetario magistral, que es un pequeño laboratorio donde se
prepara los medicamentos de las distintas formas farmacéuticas pero
que no sean estériles, tienen la zona de dispensación que es lo que se
conoce como farmacia tradicional más un laboratorio que es el
recetario magistral donde se atienden la recetas.
1.1.5. Visión
Ser una institución líder, reconocida y distinguida en el mundo

farmacéutico de todo Chimbote, por proveer grandes facilidades y por
el compromiso de nuestro personal para la satisfacción de nuestros
clientes, logrando una mejor posición del mercado y poder enfrentar
mercados nacionales e internacionales.
1.1.6. Misión
Contribuir al bienestar de los ciudadanos de la ciudad de Chimbote,

creando felicidades y ofreciendo el mejor servicio farmacéutico con la
más alta calidad para el cuidado de la salud de nuestros clientes,
contando con productos de alta calidad y con la amabilidad de nuestro
personal.
13
1.1.7. Organigrama
JEFE DE FARMACIA
ADMINISTRACION
DRECTOR TECNICO
PERSONAL DE
FARMACIA
Imagen 3. Organigrama de la Farmacia San Pedro
14
1.1.8. Análisis FODA
► Atención personalizada. ► No tener Software.
► Calidad en Productos. ► No manejar bien las

utilidades.
► Buen servicio al cliente.
► No contar con un medio
de publicidad.
► Desarrollar nuevos ► Competencia cercana de

negocios. otras farmacias.
► Promocionar ofertas. ► Publicidad agresiva de
► Crecimiento Poblacional la competencia.
de Chimbote.
Imagen 4. Análisis FODA de la Farmacia San Pedro
15
CAPITULO II
Análisis del Sistema Actual
2.1. Acciones Preliminares
2.1.1. Ciclo de Vida de desarrollo de SW
El ciclo de vida del software describe el desarrollo de software,

desde la fase inicial hasta la fase final, cuyo propósito es definir las
distintas fases intermedias que se requieren para validar el
desarrollo de la aplicación, es decir, para garantizar que
el software cumpla los requisitos para la aplicación
y verificación de los procedimientos de desarrollo, asegurando
que los métodos utilizados son apropiados. (CCM, 2017)
El ciclo de vida permite que los errores se detecten lo antes posible

y por lo tanto, permite el desarrollo en la calidad del software, en
los plazos de implementación y en los costos asociados.
El ciclo de vida básico de un software consta de los siguientes

procedimientos:
 Definición de objetivos: define la finalidad del proyecto y su
papel en la estrategia global.
 Análisis de los requisitos y su viabilidad: recopila, examina

y formula los requisitos del cliente y examina cualquier
restricción que se pueda aplicar.
 Diseño general: requisitos generales de la arquitectura de la

aplicación.
 Diseño en detalle: definición precisa de cada subconjunto de

la aplicación.
 Programación: implementación de un lenguaje de

programación para crear las funciones definidas durante la
etapa de diseño.
 Prueba de unidad: prueba individual de cada subconjunto de

la aplicación para garantizar que se implementaron de
acuerdo con las especificaciones.
 Integración: garantiza que los diferentes módulos se integren

con la aplicación. Este es el propósito de la prueba de
integración que está cuidadosamente documentada.
16
 Prueba beta (o validación): garantiza que el software cumple

con las especificaciones originales.
 Documentación: sirve para documentar información

necesaria para los usuarios del software y para desarrollos
futuros.
 Implementación
 Mantenimiento: comprende todos los procedimientos

correctivos (mantenimiento correctivo) y las actualizaciones
secundarias del software (mantenimiento continuo).
Para este proyecto el modelo de ciclo de vida del SW a

emplearse será el Modelo en Cascada, el cual es una
secuencia de actividades, donde la estrategia principal es
seguir el progreso del desarrollo de software hacia puntos
de revisión bien definidos (en inglés, milestones o
checkpoints) mediante entregas programadas con fechas
precisas (en inglés, schedule). (Weitzenfeld Ridel & Guardati
Buemo, 2007).
Este modelo conforma los siguientes procedimientos:
Requerimientos
Análisis
Diseño
Programación
Prueba
Implementación
Mantenimiento
Imagen 5. Procedimiento del Modelo Cascada
17
2.2. Recopilación de la Información
2.2.1. Entrevista para obtener requerimientos

Para la obtención de los requerimientos se hizo uso de dos tipos
de entrevista, tanto la entrevista abierta como la entrevista
cerrada.
Para la entrevista abierta se consideraron las siguientes preguntas:
a) ¿Cómo es el funcionamiento de su empresa?
b) ¿Cómo está estructurada la empresa?
c) ¿Cuál es la visión que usted tiene para su negocio?
d) ¿Cómo usted trabaja con los clientes?
e) Usted ¿Cómo trabaja con los proveedores?
f) ¿Cuántos empleados o personal tienen la empresa?
g) ¿Cuál es el proceso para contratar a un personal?
h) ¿Usted tiene otras sucursales?
i) ¿La compra de productos de sus proveedores es diario o

maneja un inventario?
j) ¿Cuántos clientes aproximadamente tiene al día?
k) ¿Cuánto tiempo le toma contabilizar sus cuentas?
l) ¿Usted requiere de reportes?
m) ¿Está familiarizado con el uso de computadoras?
n) ¿Utiliza algún software o programa que almacene información

sobre sus ventas?
o) Actualmente en sus computadoras que tiene para los agentes

¿Qué sistema operativo utiliza?
p) ¿Tiene conocimiento sobre los sistemas de información?
q) ¿Actualmente la empresa tiene problemas?
r) ¿Usted cree que un sistema de información pueda solucionar

su problema?
18
Estas preguntas fueron consultadas al dueño de la Farmacia San

Pedro, la señora María Julia Plasencia, en el propio plantel. Esto se
tomó en cuenta para una mejor comodidad del entrevistado y que
así garantizara la veracidad de las respuestas.
La entrevista cerrada se usó para conocer a detalle el sistema que

se maneja actualmente en la farmacia. Las preguntas
consideradas fueron las siguientes:
a) ¿Ha manejado algún software alguna vez (Office u otro en

particular)?
b) ¿Cada cuánto tiempo realiza un reporte?
c) ¿Guarda información sobre sus clientes (Nombre, DNI,

Dirección, etc.)?
d) ¿Controla la asistencia de su personal de trabajo?
e) ¿Qué tipo de información tiene acerca de su personal?
f) ¿Cómo maneja el inventario?
g) ¿Considera que guardar la información de sus clientes es

importante?
h) ¿Guarda información sobre los productos vendidos?
i) ¿Las ganancias obtenidas concuerdan con el reporte?
j) ¿Alguna vez pensó en utilizar un sistema para sus ventas?
k) ¿Cree que el sistema administrativo actual es efectivo?
Estas preguntas fueron desarrolladas a modo de encuesta y

consultadas al dueño de la Farmacia San Pedro, la señora María
Julia Plasencia, a las afueras del plantel.
2.2.2. Hardware Disponible
 Ordenador Portátil
Especificaciones Técnicas
 Marca DELL
 SO Windows 10
 Memoria RAM 4 GB
 Disco Duro 500 GB
 Uso en la Empresa: Esta herramienta es usada para un
control básico de los medicamentos, a través del SW
19
Microsoft Excel y también para la redacción de

documentos, a través del SW Microsoft Word.
 Impresora
 Marca CANON
 Modelo PIXMA MP 280
 Funcionalidades: Impresión, Copia y Escaneo
 Uso en la empresa: Esta herramienta es usada para
imprimir, fotocopiar o escanear documentos y/o
boletas de compra de medicamentos de sus
proveedores.
 Mouse
 Marca LOGITECH
 Modelo M125 óptico
 Uso en la empresa: Esta herramienta es usada para
una mayor manejabilidad del ordenador.
 Router
 Marca MITRASTAR
 Modelo DSL-2401HN-T1C
 Internet de la Compañía MOVISTAR.
 Uso en la empresa: Esta herramienta es usada para el
envío de solicitudes de productos a los proveedores.
2.2.3. Distribución de Equipo
El equipo es usado para registrar y almacenar las características de

los productos farmacéuticos, esto a través de Microsoft Excel.
20
2.3. Formulación del Problema
Hoy en día el mundo global exige estar a la par con los avances
tecnológicos. Son diversos aspectos y herramientas que involucran el
proceso para lograr la estabilidad y el éxito de una empresa. Es por ello
que hoy en día la Farmacia San Pedro tiene dificultades como lo son, la
falta de administración adecuada de los medicamentos, lo que incluye las
fechas de vencimiento y el stock, la falta de control en el reporte de ventas
y el control manual del personal.
2.4. Análisis de Tiempo
Fecha de Inicio: 23/04/2018
Fecha de Término: 14/07/2018
Actividades Integradas:
 APERTURA DE LA INVESTIGACION
 REQUERIMIENTOS DE LA INVESTIGACION
 REQUERIMIENTOS DEL SOFTWARE
 ANALISIS DEL DISEÑO Y SISTEMA
 INTERFACES
 EVALUACION ECONOMICA DEL PROYECTO
Imagen 6. Análisis Total del Tiempo
21
Actividad: APERTURA DE LA INVESTIGACION
 Firma de inicio del proyecto
Actividad: REQUERIMIENTOS DE LA INVESTIGACION
 Formulación de la Entrevista
 Formulación de la Encuesta
 Entrevista con el Cliente
 Encuesta con el Cliente
 Formulación de la Problemática
 Solicitud de Información
 Revisión de Información
Imagen 7. Análisis del Tiempo de: Apertura y Requerimientos de la Investigación
Actividad: REQUERIMIENTOS DEL SOFTWARE
 Perspectiva del Proyecto

 Funcionabilidad del Proyecto
 Restricciones
 Requisitos de Interfaz
 Requisitos Funcionales
 Requisitos no Funcionales
22
Imagen 8. Análisis del Tiempo: Requerimientos del Software
Actividad: ANALISIS DEL DISEÑO Y SISTEMA
 Diseño de la Base de Datos

 Implementación de la Base de Datos
Actividad: INTERFACES
 Diseño de la Interfaz
Actividad: EVALUACION ECONOMICA DEL PROYECTO
 Estudio de Viabilidad
 Análisis e Costo
Imagen 9. Análisis del Tiempo: Análisis del diseño y sistema, Interfaces y Evaluación Económica
del Proyecto
23
2.5. Análisis del Proceso

Proceso de venta de los medicamentos y proceso de pedidos al proveedor,
desarrollado en el software Bizagi Modeler.
Imagen 10. Diagrama de Procesos en el SW Bizagi
24
CAPITULO III
Especificación de Requisitos de Software
3.1. Ficha del Documento
Verificado Dep.
Fecha Revisión Autor
Calidad
Burgos Ramírez Erwin
Cervera Quiroz Noemí
18/05/2018
Laiza Rodríguez Ángel
Medina Quilcat Diego
Documento validado por las partes en fecha:
Por la comunidad Por la universidad
Farmacia “San Pedro” Universidad Nacional del Santa
3.2. Contenido
3.2.1. Introducción
El presente documento, es una Especificación de Requisitos de

Software (ERS), para el sistema de información para la gestión de
ventas y control de inventarios de la farmacia San Pedro. Esta
especificación se ha estructurado de acuerdo al formato de
Especificación de Requisitos de Software (ERS), según la última
versión del estándar ANSI/IEEE 830 - 1998.
3.2.2. Propósito
Este documento tiene como propósito analizar y documentar los

requerimientos funcionales y no funcionales, los cuales deberán ser
soportados por el sistema a desarrollar. Dicho sistema permitirá la
gestión de las ventas y el control del inventario. Además, será
utilizado por los empleados y el jefe de farmacia.
25
3.2.3. Alcance
Esta especificación de requisitos está dirigida al usuario del sistema,

para continuar con el desarrollo de aplicaciones dirigidas a ventas de
productos farmacéuticos sobre la Farmacia “San Pedro” y para
profundizar en la automatización de ésta, la cual tiene por objetivo
principal el gestionar los distintos procesos de ventas y clientes
(registro de ventas, registro de compras, historial de clientes).
3.2.4. Personal Involucrado
Nombre Erwin Burgos Ramírez

Rol Analista, diseñador y programador
Categoría Profesional TSU-Informática
Análisis de información, diseño y programación del
Responsabilidad
SIS-I
Información de
erbura_007_@hotmail.com
contacto
Nombre Noemí Cervera Quiroz

Responsabilidad
SIS-I
Información de
cielito1940@hotmail.com
contacto
Nombre Luis Laiza Rodríguez

Responsabilidad
SIS-I
Información de
luis_laiza@hotmail.com
contacto
Nombre Diego Medina Quilcat

Responsabilidad
SIS-I
Información de
diego_mq@hotmail.com
contacto
Tabla 1. Personal Involucrado
26
3.2.5. Definiciones, Acrónimos y Abreviaturas
Nombre Descripción
Persona con acceso limitado que usará el sistema para
Empleado
gestionar procesos, empleados de la empresa.
Gerente Persona que administrará la información del sistema.
Sistema de Información para la Gestión de los
SIS-I
Procesos de Venta
ERS Especificación de Requisitos Software
TSU Técnico Superior Universitario
ISO Organización Internacional de Normalización
Requisitos y evaluación de calidad del sistema y del
SQuaRE
software
BD Base de Datos
RF Requerimiento Funcional
RNF Requerimiento No Funcional
FTP Protocolo de Transferencia de Archivos
Tabla 2. Definiciones y Acrónimos utilizados.
3.2.6. Referencias
Título del Documento Referencia

Standard IEEE 830 - 1998 IEEE
ISO 25000 - SQuaRE ISO 25000
Tabla 3. Referencias Utilizadas
3.2.7. Resumen
Este documento lo conforman tres secciones. En la primera sección

se realiza una introducción al mismo y se proporciona una visión
general de la especificación de recursos del sistema.
En la segunda sección del documento se realiza una descripción

general del sistema, con el fin de conocer las principales funciones
que éste debe realizar, los datos asociados y los factores,
restricciones, supuestos y dependencias que afectan al desarrollo, sin
entrar en excesivos detalles.
Por último, la tercera sección del documento es aquella en la que se

definen detalladamente los requisitos con los que debe de cumplir
el sistema.
27
3.3. Descripción General
3.3.1. Perspectiva del Producto
El sistema estará interrelacionado con otro producto software, el cual

se desarrollará junto con el sistema. Este producto será la Base de
Datos. El tipo de BS a emplear será la Base de Datos Relacional y el
mecanismo de Comunicación con la misma será Open Database
Connectivity (ODBC).
3.3.2. Funcionalidad del Producto
Imagen 11. Funcionalidad del Producto
3.3.3. Características de los Usuarios
Tipo de usuario Dueño(a)

Formación Administrador
Actividades Gestiona y controla el sistema en de la Farmacia
Tipo de usuario Personal de ventas

Formación Vendedor
Actividades Realiza el proceso de ventas
Tipo de usuario Clientes

Formación NA
Actividades Realiza la compra de los productos
Tabla 4. Características de los Usuarios
28
3.3.4. Restricciones
 Lenguajes y tecnologías en uso: SQL, JAVA.
 El sistema deberá ser capaz de verificar la cantidad y fecha de

vencimiento de los productos, constantemente.
 Plataforma del sistema para ser usada sin internet.
 El sistema deberá tener un diseño de acuerdo al modelo

cliente/servidor.
 El sistema será capaz de emitir boletas de pago.
 El sistema deberá tener un diseño e implementación sencilla,

independiente de la plataforma o del lenguaje de programación.
3.3.5. Suposiciones y Dependencias
Se asume que los requisitos aquí descritos son estables.

Los equipos en los que se vaya a ejecutar el sistema deben cumplir
con los requisitos antes indicados para garantizar una ejecución
correcta de la misma.
3.3.6. Evolución previsible del sistema
Si en un futuro, la farmacia cuenta con una o más sucursales, el

sistema se modificará para convertirlo en un sistema distribuido.
Si en un futuro, el gerente de la farmacia deseara vender sus

productos en internet, las compras se podrán realizar en línea.
3.4. Requisitos Específicos
3.4.1. Requisitos comunes de las interfaces
 La interfaz principal requerirá como entrada un usuario y

contraseña válidos para poder dar acceso a las demás interfaces
disponibles.
 La interfaz del módulo de ventas necesita como entrada el

identificador de cada producto que será vendido. Como salida
arrojará la información completa de la compra.
 La interfaz del módulo de inventario necesita como entrada los

datos del producto a integrar o modificar en el sistema.
29
 La interfaz del módulo de clientes necesita como entrada los

datos del cliente para ser almacenados junto con los datos de la
compra realizada.
 La interfaz del módulo de proveedores necesita como entrada

los datos del proveedor a integrar o modificar en el sistema.
3.4.2. Interfaces de Usuario
 La interfaz mostrará a los usuarios (empleados) información

necesaria para que este realice alguna operación (registrar nueva
venta y búsquedas).
 La interfaz mostrará al gerente sólo la información necesaria para

realizar las modificaciones que se requieran.
3.4.3. Interfaces de Hardware
 El monitor mostrará las interfaces disponibles, además tendrá

una resolución de 1024 x 768 píxeles.
 El mouse ayudará a que el usuario pueda realizar selecciones y

oprimir botones.
 El sistema permitirá la lectura de datos a través del teclado.
3.4.4. Interfaces de Software
 Sistema Operativo: Windows 7 (Disponible en la empresa)
3.4.5. Interfaces de Comunicación
 El sistema se comunica con la base de datos a través del SGBD

SQLServer.
30
3.5. Requisitos Funcionales
3.1.1. Requisito Funcional 1
Identificación
del RF1
requerimiento:
Nombre del
Ingreso al Sistema
Requerimiento:
El ingreso al sistema se realizará luego de la identificación del
Características:
usuario.
Descripción del Para el ingreso al sistema se requerirá obligatoriamente de los
requerimiento: siguientes datos: Nickname y Contraseña, para acceder al sistema.
 RNF1
Requerimiento
 RNF4
NO funcional:
 RNF6
Prioridad del requerimiento:
Alta
Identificación
del RF2
requerimiento:
Nombre del
Registrar Ventas
Requerimiento:
Características: El empleado registra las ventas del día.
Descripción del Mostrar los campos correspondientes para el llenado de datos de
Requerimiento: la nueva venta.
 RNF1
Requerimiento  RNF3
NO funcional:  RNF5
 RNF6
Alta
31
Identificación
del RF3
requerimiento:
Nombre del
Gestión de Usuarios
Requerimiento:
Características: Actualizar los datos de la tabla usuario
Modificar la información de las tablas de empleados (usuarios).
Descripción del
Dicha modificación permitirá Agregar, Modificar y Eliminar los
requerimiento:
datos.
 RNF1
 RNF8
Alta
Identificación
del RF4
requerimiento:
Nombre del
Gestión de Ventas
Requerimiento:
Características: Actualizar los datos de la tabla de ventas
Descripción del Modificar la información de la tabla de ventas. Dicha modificación
requerimiento: permitirá Agregar, Modificar y Eliminar los datos.
 RNF1
 RNF8
Alta
32
Identificación
del RF5
requerimiento:
Nombre del
Gestión de Proveedores
Requerimiento:
Características: Actualizar los datos de la tabla de proveedores.
Descripción del Modificar la información de la tabla de proveedores. Dicha
requerimiento: modificación permitirá Agregar, Modificar y Eliminar los datos.
 RNF1
 RNF8
Alta
Identificación
del RF6
requerimiento:
Nombre del
Gestión de Medicamentos
Requerimiento:
Características: Actualizar los datos de la tabla de medicamentos.
Descripción del Modificar la información de la tabla de medicamentos. Dicha
requerimiento: modificación permitirá Agregar, Modificar y Eliminar los datos.
 RNF1
 RNF8
Alta
33
Identificación
del RF7
requerimiento:
Nombre del
Generar Reportes
Requerimiento:
Características: Imprimir reportes de proveedores, productos y ventas.
Descripción del Permitir al gerente, únicamente, imprimir los siguientes reportes:
requerimiento: de ventas, productos del inventario y ganancias.
Alta
Identificación
del RF8
requerimiento:
Nombre del
Almacenar Información de los clientes.
Requerimiento:
Guardar en la Base de Datos la información brindada por el
Características:
cliente.
Los datos del cliente ingresados por el usuario, se almacenarán
Descripción del
en la BD para las consideraciones correspondientes en las
requerimiento:
próximas ventas.
 RNF3
Requerimiento
 RNF5
NO funcional:
 RNF7
Alta
34
3.6. Requerimientos No Funcionales
3.2.1. Requerimientos No Funcionales 1
Identificación del
RNF1
requerimiento:
Nombre del
Facilidad de uso del Software
Requerimiento:
Características: Uso sencillo e intuitivo.
Descripción del Interfaz y vocabulario sencillos que permitan a los usuarios el
requerimiento: fácil manejo del software.
Alta
Identificación del
RNF2
requerimiento:
Nombre del
Desempeño en varios sistemas operativos
Requerimiento:
El sistema podrá utilizarse en diferentes S.O (“Linux,
Características:
Windows, Mac, etc.).
Descripción del La ejecución del sistema se llevará a cabo en cualquier

requerimiento: operativo, que el usuario tenga disponible.

Alta
Identificación del
RNF3
requerimiento:
Nombre del
Eficacia del sistema
Requerimiento:
Características: Realizar los procesos requeridos en un tiempo breve.
Descripción del
Ejecutar las búsquedas y demás acciones de manera rápida.
requerimiento:
Alta
35
Identificación del
RNF4
requerimiento:
Nombre del
Protección de Información
Requerimiento:
Proporcionar una mayor seguridad al momento de hacer
Características:
modificaciones de los datos.
La seguridad del sistema se verá reflejada a través de la
Descripción del autentificación del usuario para el ingreso al sistema y también
requerimiento: al denegar el acceso al personal no autorizado para la
realización de modificaciones.
Alta
Identificación del
RNF5
requerimiento:
Nombre del
Copia de Seguridad
Requerimiento:
Características: Almacenamiento automático.
Realizar copias de seguridad de la Base de Datos por si se
Descripción del
presenta algún fallo, dicha copia se realizará por semana de
requerimiento:
manera automática.
Alta
3.2.6. Requerimiento No Funcional 6
Identificación del
RNF6
requerimiento:
Nombre del
Ayuda al Usuario
Requerimiento:
Tener disponible la opción de ayuda para facilitar el manejo
Características:
del software.
a) El menú de ayuda mostrará las diferentes opciones
disponibles (submenús), para que el usuario elija la
alternativa que mejor se adecúe a sus necesidades.
Descripción del
b) Los cuadros de ingreso de texto, contendrán un mensaje de
requerimiento:
indicación de lo que correspondería escribir allí.
c) Contará con un manual físico para el uso adecuado del
Sistema.
Media
36
Identificación del
RNF8
requerimiento:
Nombre del
Recuperación de fallos
Requerimiento:
Garantiza al usuario una recuperación de errores que
Características:
contenga el sistema al momento de su ejecución.
Descripción del El sistema podrá corregir los errores detectados al momento
requerimiento: de ejecutar el sistema.
Alta
Identificación del
RNF8
requerimiento:
Nombre del
Acerca de
Requerimiento:
Tener disponible la opción de Acerca de para informar al
Características:
usuario acerca del Software.
Descripción del El menú de ayuda mostrará información necesaria acerca del
requerimiento: software como la versión, los creadores, entre otros.
Baja
37
CAPITULO IV
Análisis y Diseño del Sistema
4.1. Descripción de las metodologías más usadas
El Modelo en Cascada
Según Royce (1970), el modelo de cascada se derivó de procesos de

sistemas más generales. Sus principales etapas se transforman en
actividades fundamentales del desarrollo:
a. Análisis y definición de requerimientos. Los servicios restricciones y

metas del sistema se definen a partir de las consultas con los
usuarios. Entonces, se definen en detalle y sirven de manera
específica al sistema.
b. Diseño del sistema y del software. El proceso de diseño del sistema

divide los requerimientos en sistemas ya sea hardware Soto.
Establece una arquitectura completa del sistema, el diseño del
software identifique describe los elementos abstractos que son
fundamentales para el software y sus relaciones.
c. Implementaciones prueba de unidades. Durante esta etapa el

diseño del software se lleva a cabo como un conjunto de unidades
de programas, la prueba de unidades implica verificar que cada una
cumpla con su función específica.
d. Integración y prueba del sistema. Los programas o las unidades

individuales de programas se integran y se prueban como un
sistema completo para así asegurar que se cumplan los
requerimientos del software, después se entrega al cliente.
e. Funcionamiento y mantenimiento. En esta fase el sistema se instala

y se pone en funcionamiento práctico el mantenimiento implica
corregir errores no descubiertos en las etapas anteriores del ciclo
de vida, mejorar la implementación de las unidades del sistema y
resaltar los servicios del sistema una vez que se descubren en
nuevos requerimientos.
El Modelo de Desarrollo Evolutivo (Espiral)
El MODELO en espiral, propuesto originalmente por BOEHM en 1976,

es un modelo de proceso de software evolutivo donde se conjuga la
38
naturaleza de construcción de prototipos con los aspectos controlados

y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el
potencial para el desarrollo rápido de versiones incrementales del
software que no se basa en fases claramente definidas y separadas
para crear un sistema.
En el modelo espiral, el software se desarrolla en una serie de versiones

incrementales. Durante las primeras iteraciones la versión incremental
podría ser un modelo en papel o un prototipo, durante las últimas
iteraciones se producen versiones cada vez más completas del sistema
diseñado.
EL modelo en espiral se divide en un número de actividades de marco

de trabajo, también llamadas REGIONES DE TAREAS , Cada una de las
regiones están compuestas por un conjunto de tareas del trabajo
llamado CONJUNTO DE TAREAS que se adaptan a las características
del proyecto que va a emprenderse en todos los casos se aplican
actividades de protección. (Grupo espiral PHP, 2009)
Imagen 12. Modelo de Desarrollo Evolutivo (ESPIRAL)
Modelo de Desarrollo basado en Componentes
El desarrollo basado en componentes consiste en construir

aplicaciones mediante ensamblado de módulos software reutilizables,
que han sido diseñados previamente independientemente de las
aplicaciones en las que van a ser utilizados. Es decir, los componentes
puede ser que los desarrolle otro equipo u otras personas distintas a
las que los ensamblan. Incluso suelen utilizarse componentes
desarrollados por otras empresas o componentes genéricos (el mismo
componente lo utilizan varios sistemas). Este tipo de desarrollo tiene
las siguientes implicaciones:
 Industrialización del desarrollo de software: Muchas empresas

utilizan componentes desarrollados por otras empresas e incluso
algunas venden sus propios componentes.
39
 Cambio en el papel de los diseñadores de aplicaciones: Los

programadores han pasado de programar aplicaciones desde cero
a ensamblar módulos.
Finalmente decir que este tipo de desarrollo está favoreciendo

la construcción más rápida de software además de
que permite gestionar más fácilmente la creciente
complejidad del software. (Gómez, 2015)
4.2. Fundamentación de la metodología seleccionada
Los método son creados para definir el comportamiento de un objeto,

estos tienen una apariencia y un comportamiento igual al de las funciones
en otros lenguajes de programación, los lenguajes estructurados, pero se
definen dentro de una clase.
Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del

objeto.
Se llama encapsulamiento, al empaquetamiento de las variables de un

objeto con la protección de sus métodos. Típicamente, el encapsulamiento
es utilizado para esconder detalles de la puesta en práctica no importantes
de otros objetos.
Modularidad, esto es, el código fuente de un objeto puede ser escrito, así
como darle mantenimiento, independientemente del código fuente de
otros objetos. Así mismo, un objeto puede ser transferido alrededor del
sistema sin alterar su estado y conducta.
Ocultamiento de la información, es decir, un objeto tiene una "interfaz

publica" que otros objetos pueden utilizar para comunicarse con él. Pero
el objeto puede mantener información y métodos privados que pueden
ser cambiados en cualquier tiempo sin afectar a los otros objetos que
dependan de ello.
Los atributos son variables comunes en cada objeto de una clase y cada
uno de ellos puede tener un valor asociado, para cada variable, diferente
al que tienen para esa misma variable los demás objetos. Los métodos,
por su parte, pertenecen a la clase y no se almacenan en cada objeto,
puesto que sería un desperdicio almacenar el mismo procedimiento varias
veces y ello va contra el principio de reutilización de código.
40
4.3. Análisis y Diseño
4.3.1. Documento de Casos de Uso
Caso 01
Caso de Uso: Ingreso al sistema
Actores: U – S
Propósito: El usuario tendrá acceso al sistema
Resumen: El usuario debe de estar registrado. Accede con su nickname y

contraseña.
Eventos
USUARIO SISTEMA
1. Muestra el entorno de trabajo.
2. Llena la información solicitada
(nickname y contraseña).
3. Clic en el botón Aceptar
4. Busca el nickname y contraseña en la
BD.
5. Devuelve la información encontrada.
6. Permite el ingreso al sistema.
Alternos
4.1. Mostrar un mensaje indicando si los datos son incorrectos.

4.2. Mostrar un mensaje de la inexistencia del usuario en la BD y redireccionar a
la ventana para el llenado de los datos del nuevo usuario.
Elementos
La interfaz contara con 2 cajas de texto y 2 botones (ingresar y limpiar).
41
Caso 02
Caso de Uso: Realizar Venta a Cliente Concurrente

Actores: U – S
Propósito: El usuario registra las ventas realizadas
Resumen: El usuario debe ingresar al sistema. Se registran los datos de las ventas.
Eventos
USUARIO SISTEMA
1. Muestra el entorno de trabajo.

2. Ingresa el nombre del medicamento.
3. Realiza la búsqueda del medicamento
en la BD.
4. Ingresa la cantidad a vender.

5. Ingresa el DNI del cliente.
6. Presiona el Botón Buscar Cliente.
7. Busca en la B.D. el número de DNI.
8. Muestra los datos obtenidos del cliente
(Nombre y Apellidos).
9. Activa el botón para generar la boleta.
10. Presiona el botón Generar la

9. Genera la boleta de venta.
Boleta.
Alternos
3.1. Mostrar un mensaje indicando la cantidad disponible de dicho medicamento.

7.1. Mostrar un mensaje indicando la inexistencia del cliente en la Base de Datos
y solicitando el ingreso de los datos del nuevo cliente (Caso de Uso: Registro
de Nuevo Cliente).
Elementos
La interfaz contara con 1 lista despegable, 3 cajas de texto y 3 botones (Registrar

venta, Cancelar venta, Limpiar).
42
Caso 03
Caso de Uso: Registrar de Nuevo Cliente

Actores: U – S
Propósito: Guardar los datos de los clientes en la B.D.
Resumen: El usuario debe ingresar y guardar la información obtenida de nuevo
cliente en la B.D.
Eventos
USUARIO SISTEMA
1. Muestra el entorno de trabajo,
solicitando el nombre y los apellidos
del nuevo cliente.
2. Ingresar el nombre y los apellidos
del cliente.
4. Verifica que los datos ingresados sean
los correctos.
5. Activa el botón para guardar los datos.
6. Presiona el botón de Guardar.
7. Guarda la información del nuevo
cliente en la B.D.
Alternos
4.1 Mostrar un mensaje si algún campo está vacío.
4.2. Mostrar un mensaje de error si el tipo de escritura no es el correcto.
Elementos
La interfaz contara con 1 un botón de guardar.
43
Caso 04
Caso de Uso: Búsqueda de Clientes

Actores: U – S
Propósito: Buscar y obtener información de un determinado cliente.
Resumen: El usuario debe ingresar el DNI, Nombre, o Apellido del cliente, para
realizar la búsqueda y así obtener toda la información disponible de
dicho cliente.
Eventos
USUARIO SISTEMA
1. Muestra el entorno de trabajo, listando
los clientes almacenados en la B.D.
2. Ingresar uno de los datos del
cliente (DNI, Nombre o Apellido).
3. Verifica el llenado del campo.
4. Activa el botón de búsqueda.
5. Presiona el botón de buscar.
6. Realiza la búsqueda del dato ingresado
en la B.D. de los clientes.
7. Muestra toda la información existente
en la B.D. del cliente (Información
Personal y Ventas Realizadas).
Alternos
3.1. Mostrar un mensaje si el campo está vacío.
3.2. Mostrar un mensaje de error si el tipo de escritura no es el correcto.
6.1. Mostrar un mensaje indicando la inexistencia del cliente.
Elementos
La interfaz contara con 1 un botón de guardar.
44
Caso 05
Caso de Uso: Gestión De Usuario

Actores: U - S
Propósito: Realizar modificaciones en el sistema.
Resumen: El gerente debe ingresar al sistema. Se realizarán modificaciones como

agregar, modificar y eliminar.
Eventos
USUARIO SISTEMA
1. Muestra el entorno de trabajo

2.Selecciona la opción deseada
(agregar, modificar y eliminar)
3. Para la opción agregar se ingresan
los nuevos datos. Para opción
eliminar se selecciona la fila de datos
y para opción modificar se corrigen
los datos.
4. El usuario presiona el botón de
guardar.
5. Verifica que los datos estén correctos.

6. Guarda los cambios realizados en la BD.
Alternos
3.1. Mostrar un mensaje que los campos no estén vacíos.
5.1. Mostrar un mensaje de los cambios han correctamente realizados
Elementos
La interfaz contara con 1 lista desplegable, 4 cajas de texto y 4 botones (Agregar,

Eliminar, Modificar y Guardar Cambios)
45
Caso 06
Caso de Uso: Gestión de Ventas Realizadas

Actores: U - S
Propósito: Realizar modificaciones en el sistema de las ventas realizadas del día.
Resumen: El gerente debe ingresar al sistema. Se realizarán modificaciones como,

editar y eliminar.
Eventos
USUARIO SISTEMA

2.Selecciona la opción deseada (editar
y eliminar)
los datos.
guardar.

Alternos
Elementos

46
Caso 07
Caso de Uso: Gestión de Proveedores

Actores: U - S
Propósito: Realizar modificaciones en el sistema de los proveedores disponibles.

agregar, modificar y eliminar.
Eventos
USUARIO SISTEMA

los datos.
guardar.

Alternos

Elementos

47
Caso 08
Caso de Uso: Gestión de Medicamentos

Actores: U - S
Propósito: Realizar modificaciones en el sistema de los Medicamentos

disponibles.

agregar, modificar y eliminar el / los medicamentos deseados.
Eventos
USUARIO SISTEMA

los nuevos datos, fecha de
caducidad y cantidad. Para opción
los datos.
guardar.
Alternos

Elementos

48
Caso 09
Caso de Uso: Generar Reportes

Actores: U – S
Propósito: Realizar reportes en el sistema.
Resumen: El gerente deberá imprimir los reportes. Se realizaran reportes de

ventas, productos y ganancias.
Eventos
USUARIO SISTEMA

2. El gerente selecciona los reportes
que desea visualizar tales como
(ventas, productos y ganancias).
3. Muestra los reportes solicitados.
Elementos
La interfaz contara con 1 botón (Mostrar Reporte)
4.3.2. Diagrama de Caso de Uso
Caso 01.- Ingreso al Sistema
49
Caso 02.- Realizar Ventas
Caso 03.- Registrar Nuevo Cliente
50
Caso 04.- Búsqueda de Clientes
Caso 05.- Gestión de Usuarios
51
Caso 06.- Gestión de Ventas Realizadas
Caso 07.- Gestión de Proveedores
52
Caso 08.- Gestión de Medicamentos
Caso 09.- Generar Reportes
53
DIAGRAMA DE CASOS DE USO DEL SISTEMA DE VENTAS
4.3.3. Diagrama de Secuencia
1. Ingreso al sistema
54
2. Realizar Venta
3. Registrar Nuevo Cliente
4. Búsqueda del Clientes
55
5. Gestión de usuario
5.1. Agregar nuevo usuario
5.2. Modificar usuario
5.3. Eliminar usuario
56
6. Gestión de Ventas Realizadas

6.1. Modificar Venta
6.2. Eliminar Venta
7. Gestión de Proveedores
7.1. Agregar Proveedor
57
7.2. Modificar Proveedor
7.3. Eliminar Proveedor
8. Gestión de medicamentos
8.1. Agregar Medicamento
58
8.2. Modificar Medicamento
8.3. Eliminar Medicamento
9. Generar reporte
59
4.3.4. Diagrama de Colaboración
2. Realizar Venta
60
3. Registrar Cliente
4. Búsqueda de Clientes
5. Gestión de usuario
5.1. Agregar usuario
61
6. Gestión de venta
6.1. Modificar venta
62
6.2. Eliminar venta
7. Gestión de proveedores
7.1. Agregar proveedor
7.2. Modificar proveedor
63
7.3. Eliminar proveedor
8.1. Agregar medicamento
8.2. Modificar medicamento
64
8.3. Eliminar medicamento
9. Generar reporte
65
4.3.5. Diagrama de Clases
4.3.6. Diagrama de Actividades
66
2. Realizar Venta
3. Registrar Nuevo Cliente
67
4. Búsqueda de Clientes
5. Gestión Usuario
5.1. Agregar Usuario
68
69
6. Gestión venta
6.1. Modificar venta
6.2. Eliminar venta
70
7. Gestión de proveedores
7.1. Agregar de proveedor
7.2. Modificar proveedor
71
7.3. Eliminar proveedor
8.1. Agregar medicamento
72
8.2. Modificar medicamento
8.3. Eliminar medicamento
73
9. Generar reportes
74
4.4. Implementación de la Base de Datos
4.4.1. Diseño Conceptual
a) Identificar las Entidades

 Cliente
 Vendedor
 Proveedor
 Producto
 Venta
 Pedido
 Login
b) Identificar las Relaciones
 Un proveedor suministra uno o muchos pedidos.
 Un pedido puede ser suministrado por un solo proveedor.
 Un pedido contiene uno o muchos productos.
 Un producto está contenido en un solo pedido.
 Un vendedor realiza una o más ventas.
 Una venta es realizada por un solo vendedor.
 Un cliente compra una o más ventas.
 Una venta es comprada por uno sólo cliente.
 En una venta se detallan uno o más productos.
 Un producto se detalla en una sola venta.
 Un vendedor tiene un solo login.
 Un login lo pueden tener muchos vendedores.
c) Identificar los atributos y asociarlos a entidades y relaciones
 Cliente: Id_Cliente (PK), Nombre_Cli
 Vendedor: Id_Vendedor (PK), Nombres_Ven, Apellidos_Ven,
Teléfono_Ven, Dirección_Ven
 Proveedor: Id_Proveedor (PK), RazSocial_Prov, Teléfono_Prov,
Dirección_Prov
 Producto: Id_Prod (PK), Nombre_Prod, Precio_Prod,
Stock_Prod, Fecha_Vcto, Concentrado_Prod, Form_Farm,
Forma_Farm_Simp, Fracciones_Prod, NumRS_Prod,
Laboratorio_Prod
75
 Venta: Num_Venta (PK), Id_Cliente (FK), Fecha_Venta,

Id_Vendedor (FK), Monto_Total
 Pedido: Id_Pedido (PK), Fecha_Ped, Id_Proveedor (FK),
Id_Producto (FK)
 Login: Id_Login (PK), Id_Vendedor (FK), Usuario, Contraseña
d) Determinar los dominios de los atributos
Cliente Tipo de Dato Longitud Regla

Id_Cliente Numérico 9 Números
Nombre_Cli Caracteres 50 Letras Mayúsculas
Vendedor Tipo de Dato Longitud Regla

Id_Vendedor Numérico 9 Números
Nombres_Ven Caracteres 50 Letras Mayúsculas
Apellidos_Ven Caracteres 50 Letras Mayúsculas
Teléfono_Ven Numérico 9 Números
Dirección_Ven Caracteres 30 Letras y Números
Proveedor Tipo de Dato Longitud Regla

Id_Proveedor Numérico 11 Números
RazSocial_Prov Caracteres 50 Letras Mayúsculas
Teléfono_Prov Numérico 9 Números
Dirección_Prov Caracteres 30 Letras y Números
Producto Tipo de Dato Longitud Regla

Id_Prod Caracteres 10 Letras y Números
Nombre_Prod Caracteres 50 Letras Mayúsculas
Precio_Prod Numérico 10 Números
Stock_Prod Numérico 3 Números
Fecha_Vcto Fecha 10 Fecha
Concentrado Caracteres 10 Letras y Números
Forma_Farma Caracteres 30 Letras Mayúsculas
Forma_Farma_Simp Caracteres 15 Letras Mayúsculas
Fracciones Numérico 2 Números
Num_RS_Prod Numérico 5 Números
Laboratorio Caracteres 20 Letras Mayúsculas
Venta Tipo de Dato Longitud Regla

Num_Venta Numérico 6 Números
Fecha_Venta Fecha 10 Fecha
Monto_Total Decimal 6 Números
76
Pedido Tipo de Dato Longitud Regla

Id_Pedido Numérico 6 Números
Fecha_Ped Fecha 10 Fecha
Login Tipo de Dato Longitud Regla

Id_Login Numérico 9 Números
Usuario Caracteres 15 Letras y Números
Contraseña Caracteres 15 Letras y Números
e) Determinar los identificadores

1= El campo pertenece a la tabla.
2= Los valores del campo son diferentes.
3= El dato del campo tenga la misma longitud.
4= El campo es administrado por la empresa o la institución.
CLIENTE 1 2 3 4 VENDEDOR 1 2 3 4
DNI_Cliente     Id_Vendedor    
Nombre_Cli   X X Nombres_Ven   X X
Apellidos_Ven   X X
PROVEEDOR 1 2 3 4 Teléfono_Ven  X  X
Id_Proveedor     Dirección_Ven   X X
RazSocial_Prov   X X
Teléfono_Prov  X  X
Dirección_Prov   X X
PRODUCTO 1 2 3 4
Id_Prod    
VENTA 1 2 3 4
Nombre_Prod   X X
Num_Venta    
Precio_Prod   X 
Fecha_Venta  X  X
Stock_Prod   X 
Monto_Total  X X 
Fecha_Vcto    X
PEDIDO 1 2 3 4 Concentrado   X X
Id_Pedido     Forma_Farm   X X
Fecha_Ped    X Forma_Farm_Simp   X X
Fracciones   X 
LOGIN 1 2 3 4 Num_RS_Prod    X
Id_Login     Laboratorio   X X
Usuario   X X
Contraseña   X X
77
f) Dibujar el Modelo Entidad – Relación (MER).
78
4.4.2. Diseño Lógico
4.4.2.1. Normalización del Esquema Conceptual

 Tablas iniciales no normalizadas:
Las siguientes tablas contienen toda la información que maneja la librería
en dos aspectos: Compra de productos a los proveedores y Venta de
productos al público en general.
Venta (numero_venta, fecha_venta, monto_total, id_producto, nom_prod,
precio_prod, stock, fecha_vcto, concentrado, forma_farma,
forma_farma_simplif, presentación, fracciones, num_regsan, laboratorio,
precio_venta, cantidad, DNI_vendedor, nombre_vendedor,
teléfono_vendedor, distrito_vendedor, dirección_vendedor, id_login,
usuario, contraseña, id_cliente, DNI_pnatural, nombre_pnatural,
RUC_pjurídica, razon_social_pjurídica)
Compra (id_pedido, fecha_pedido, cantidad_pedido, precio_compra,
id_proveedor, nom_proveedor, teléfono_proveedor, ciudad_proveedor,
distrito_proveedor,dirección_proveedor, id_producto, nom_prod,
forma_farma_simplif, presentación, fracciones, num_regsan, laboratorio)
a) Primera Forma Normal

 Resolviendo los grupos repetitivos:
Detalle_Venta (numero_venta, id_producto, nom_prod, precio_prod,

stock, fecha_vcto, concentrado, forma_farma, forma_farma_simplif,
presentación, fracciones, num_regsan, laboratorio, precio_venta,
cantidad)
Venta (numero_venta, fecha_venta, monto_total, DNI_vendedor,
nombre_vendedor, teléfono_vendedor, distrito_vendedor,
direccion_vendedor, id_login, usuario, contraseña, id_cliente,
DNI_pnatural, nombre_pnatural, RUC_pjurídica, razon_social_pjurídica)
Compra (id_pedido, id_producto, nom_prod, precio_prod, stock,
fecha_vcto, concentrado, forma_farma, forma_farma_simplif,
presentación, fracciones, num_regsan, laboratorio, cantidad_pedido,
precio_compra)
Pedido (id_pedido, fecha_pedido, id_proveedor, nom_proveedor,
teléfono_proveedor, ciudad_proveedor, distrito_proveedor,
dirección_proveedor)
79
 Atomizando atributos:

p_nombre_vendedor, s_nombre_vendedor, apellido_p_vendedor,
apellido_m_vendedor, teléfono_vendedor, distrito_vendedor,
dirección_vendedor, id_login, usuario, contraseña, id_cliente,
DNI_pnatural, p_nombre_pnatural, s_nombre_pnatural,
apellido_p_pnatural, apellido_m_pnatural, RUC_pjurídica,
razon_social_pjurídica)
b) Segunda Forma Normal

 Determinando dependencias funcionales:
En las tablas Compra y Detalle_venta los atributos: nom_prod,

forma_farma_simplif, presentación, fracciones, num_regsan, laboratorio
dependen únicamente de id_producto.
Compra (id_pedido, id_producto, cantidad_pedido, precio_compra)
Detalle_venta (numero_venta, id_producto, precio_venta, cantidad)
Producto (id_producto, nom_prod, precio_prod, stock, fecha_vcto,
concentrado, forma_farma, forma_farma_simplif, presentación, fracciones,
num_regsan, laboratorio)
c) Tercera Forma Normal

 Determinando dependencias funcionales transitivas:
 En la tabla Venta, los atributos: p_nombre_vendedor, s_nombre_vendedor,

apellido_p_vendedor, apellido_m_vendedor, teléfono_vendedor,
distrito_vendedor y dirección_vendedor, id_login, usuario, contraseña
dependen funcionalmente de DNI_vendedor, el cual a su vez depende de
la clave primaria numero_venta. Además, los atributos: DNI_pnatural,
p_nombre_pnatural, s_nombre_pnatural, apellido_p_pnatural,
apellido_m_pnatural, RUC_pjurídica y razon_social_pjurídica dependen
funcionalmente de id_cliente, el cual a su vez depende de la clave primaria
numero_venta.

id_cliente)
Vendedor (DNI_vendedor, p_nombre_vendedor,
s_nombre_vendedor, apellido_p_vendedor, apellido_m_vendedor,
80
teléfono_vendedor, distrito_vendedor, dirección_vendedor,

id_login, usuario, contraseña)
Cliente (id cliente, DNI_pnatural, p_nombre_pnatural,
s_nombre_pnatural, apellido_p_pnatural, apellido_m_pnatural,
RUC_pjurídica, razon_social_pjurídica)
 En la tabla Vendedor, los atributos: id_login, usuario, contraseña
dependen funcionalmente de id_login, el cual a su vez depende de la
clave primaria DNI_vendedor
Vendedor (DNI_vendedor, p_nombre_vendedor,

s_nombre_vendedor, apellido_p_vendedor, apellido_m_vendedor,
teléfono_vendedor, distrito_vendedor, dirección_vendedor)
Login (id_login, usuario, contraseña, DNI_vendedor)
 En la tabla Cliente, los atributos: p_nombre_pnatural, s_nombre_pnatural,

apellido_p_pnatural y apellido_m_pnatural dependen funcionalmente de
DNI_pnatural, el cual a su vez depende de la clave primaria id_cliente.
Además, el atributo razon_social_pjurídica depende funcionalmente de
RUC_pjurídica, el cual depende de la clave primaria id_cliente.
Cliente (id_cliente, DNI_pnatural, RUC_pjurídica)

Persona_Natural (DNI_pnatural, p_nombre_pnatural,
s_nombre_pnatural, apellido_p_pnatural, apellido_m_pnatural)
Persona_Jurídica (RUC_pjurídica, razon_social_pjurídica)
 En la tabla Pedido, los atributos: nom_proveedor, teléfono_proveedor,
ciudad_vendedor, distrito_vendedor y dirección_proveedor dependen
funcionalmente de id_proveedor, el cual a su vez depende de la clave
primaria id_pedido.
Pedido (id_pedido, fecha_pedido, id_proveedor)

Proveedor (id_proveedor, nom_proveedor, teléfono_proveedor,
ciudad_vendedor, distrito_vendedor, dirección_proveedor)
d) Forma Normal Boyce-Codd
Todas las tablas se encuentran en esta forma normal ya que no existe

solapamiento entre claves candidatas compuestas.
81
Resumen
Persona_Natural (DNI_pnatural, p_nombre_pnatural, s_nombre_pnatural,

apellido_p_pnatural, apellido_m_pnatural)
Persona_Jurídica (RUC_pjurídica, razon_social_pjurídica)
Cliente (id_cliente, DNI_pnatural, RUC_pjurídica)
Producto (id_producto, nom_prod, precio_prod, stock, fecha_vcto, concentrado,

forma_farma, forma_farma_simplif, presentación, fracciones, num_regsan,
laboratorio)
Vendedor (DNI_vendedor, p_nombre_vendedor, s_nombre_vendedor,

apellido_p_vendedor, apellido_m_vendedor, teléfono_vendedor,
distrito_vendedor, dirección_vendedor)
Login (id_login, usuario, contraseña, DNI_vendedor)
Venta (numero_venta, fecha_venta, monto_total, DNI_vendedor, id_cliente)
Proveedor (id_proveedor, nom_proveedor, teléfono_proveedor,

ciudad_proveedor, distrito_proveedor, dirección_proveedor)
Pedido (id_pedido, fecha_pedido, id_proveedor)
Compra (id_pedido, id_producto, cantidad_pedido, precio_compra)
Detalle_de_venta (numero_venta, id_producto, precio_venta, cantidad)
82
4.4.3. Diseño Físico
83
CAPITULO V
Interfaces
5.1. Diseño de interfaces de prototipo
El prototipo del sistema de ventas de la Farmacia San Pedro contiene las

siguientes ventanas:
La ventana de Inicio de Sesión, en esta, los usuarios tendrán que iniciar sesión
para tener acceso al sistema, deberán de ingresar su nombre de usuario y su
contraseña, previamente creados. También tendrán la posibilidad de registrarse
en el caso de no haberlo hecho.
84
La ventana de Opciones, en esta, el usuario administrador tendrá acceso a las

modificaciones disponibles para los datos de los productos, los proveedores, los
empleados, los clientes y las ventas. Estas modificaciones incluyen la creación,
edición y eliminación, de los datos. También tendrá el acceso a la opción de
reportes.
La ventana Mantenimiento de Productos, en esta, se presenta las opciones para

realizar las modificaciones deseadas a los datos de los productos, así también
agregar y/o eliminar un producto, estas opciones sólo las podrá hacer el usuario
administrador.
85
La ventana Mantenimiento de Proveedores, en esta, se podrá agregar a un nuevo

proveedor, así también modificar los datos de uno ya existente o eliminar al que
ya no trabaje con la empresa. Estos cambios sólo los puede realizar el usuario
administrador.
La ventana Mantenimientos del Personal, en esta, el usuario administrador, podrá

registrar a los nuevos empleados, para que estos puedan tener acceso al sistema.
También podrá modificar los datos personales de los mismos.
86
La ventana Nueva Venta, en esta, el usuario (empleado) podrá realizar las ventas
del día, así también registrar a un cliente en el caso de que no lo esté. Permitirá
generar una boleta y/o factura dependiendo el tipo de cliente que realice la
compra.
La ventana de Mantenimiento de Clientes, en esta, se detalla los datos de los

clientes tanto naturales como jurídicos que hayan sido registrados al momento
de realizar una compra. La ventana Nueva Venta, llama a este formulario para el
correcto registro de un nuevo cliente.
87
La ventana Reportes de Venta, en esta, se detallan las ventas realizadas durante

un periodo de tiempo determinado, así también muestra el cálculo de los
impuestos a pagar.
88
CAPITULO VI
Evaluación económica del proyecto
6.1. Estudio de Viabilidad
El análisis de la viabilidad es el estudio que dispone el éxito o fracaso de un

proyecto a partir de una serie de datos base de naturaleza empírica: medio
ambiente del proyecto, rentabilidad, necesidades de mercado, factibilidad
política, aceptación cultural, legislación aplicable, medio físico, flujo de caja de la
operación, haciendo un énfasis en viabilidad financiera y de mercado. Es por lo
tanto un estudio dirigido a realizar una proyección del éxito o fracaso de un
proyecto.
6.1.1. Viabilidad Tecnológica
Durante el análisis técnico se estudió y evaluó que la farmacia cuenta

con la tecnología de información adecuada de tal forma que el
rendimiento del sistema se llevará a cabo con normalidad.
Existe una buena posibilidad de seguir adelante con realización e
implementación del sistema.
Actualmente la institución cuenta con el equipo adecuado, facilitando
así la instalación futura del software:
6.1.2. Viabilidad Operacional
El presente proyecto cuenta con el apoyo por parte de la dueña de la

farmacia para brindarnos toda la información más relevante, así como
también el apoyo de la parte operativa.
Aunque actualmente los métodos usados por la dueña no son tan

eficaces, por lo que es de gran interés por mejorar dichos procesos
mediante un aplicativo.
6.1.3. Viabilidad Económica
El costo de llevar a cabo la investigación completa de sistemas no es

muy costoso debido que será realizado por nosotros mismos.
El costo del hardware y software para la aplicación no es muy costoso

dado a que ya se cuenta con el equipo necesario.
El costo de la implementación del sistema, en el caso que se apruebe,

tendrá un valor que se detalla en el siguiente capítulo (6.2.1. Costos
para la implementación).
89
En el caso de que el proyecto no se llevara a cabo, esto no significaría

ningún costo ni para la empresa ni para quienes llevamos a cabo el
análisis
6.2. Estudio de costo y beneficiación
6.2.1. Costos para la implementación
1. Datos del Sistema
Registro de Vendedores
Registro de Clientes
Entradas Externas (EI) Registro de Proveedores
Registro de Productos
Registro de Ventas
Reporte de Ventas
Salidas Externas (EO)
Reporte de Inventarios
Buscar por Nombre

Consultas Externas (EQ) Buscar por Código
Buscar por Descripción
Archivos Lógicos Internos (ILF) 6 Tablas
Archivos de Interfaz Externos (EIF) NO
2. Puntos de Función No Ajustados (PFSA)
Tipo /Complejidad Baja Media Alta
Entradas Externas (EI) 3 PF 4 PF 6 PF
Salidas Externas (EO) 4 PF 5 PF 7 PF
Consultas Externas
3 PF 4 PF 6 PF
(EQ)
Archivos Lógicos
7 PF 10 PF 15 PF
Internos (ILF)
Archivos de Interfaz
5 PF 7 PF 10 PF
Externos (EIF)
90
Puntos Función - Determinación de la Complejidad (Boehm)
Para archivos lógicos y archivos Para salidas y consultas

Para Entradas Externas
externos de datos externas
Elemento Elementos de Datos Tipo de Elementos de Datos Tipo de Elementos de Datos

de Riesgo 1-19 20-50 51+ Archivo 1-5 6-19 20+ Archivo 1-4 5-15 16+
1 Bajo Bajo Medio 0 o 1 Bajo Bajo Medio 0 o 1 Bajo Bajo Medio
2-5 Bajo Medio Alto 2-3 Bajo Medio Alto 2-3 Bajo Medio Alto
6+ Medio Alto Alto 4+ Medio Alto Alto 3+ Medio Alto Alto
Calculando los Puntos de Función sin Ajustar:
Tipo
Baja Media Alta
/Complejidad
Entradas Externas
3 PF 4 PF 5 * 6 PF 30
(EI)
Salidas Externas
2 * 4 PF 5 PF 7 PF 8
(EO)
Consultas Externas
3 * 3 PF 4 PF 6 PF 9
(EQ)
Archivos Lógicos
7 PF 6 * 10 PF 15 PF 60
Internos (ILF)
Archivos de Interfaz
5 PF 7 PF 10 PF 0
Externos (EIF)
Total 107
Entonces: PFSA = 107
91
Calculando el Factor de Ajuste:
Factor de Ajuste Puntaje

Comunicación de Datos 0
Procesamiento
0
distribuido
Objetivos de Rendimiento 1
Puntaje Descripción
Configuración del
2 0 Sin influencia
equipamiento
1 Incidental
Tasa de transacciones 1 2 Moderado
Entrada de datos en línea 0 3 Medio
Interface con el usuario 3 4 Significativo
Actualización en línea 0 5 Esencial
Procesamiento complejo 0
Reusabilidad del código 3
Facilidad de
2
implementación
Facilidad de operación 0
Instalaciones Múltiples 0
Facilidad de cambios 2
Factor de Ajuste 14
3. Puntos de Función Ajustados (PFA)
PFA = PFSA* [0.65 + (0.01 * Factor de Ajuste)]

PFA = 107 * [0.65 + (0.01 * 14)]
PFA = 84.53
PFA = 85
4. SLOC
SLOC = PFSA * Puntos del Lenguaje
SLOC = 107 * 53 (Java)
SLOC = 5671
5. PM Nominal
Calculando el Factor Exponencial de Escala (B), considerando los 5
factores Wj (PREC, FLEX, RESL, TEAM y MAT)
92
𝐵 = 1.01 + 0.01 ∗ ∑ 𝑊𝑗
𝑖=1
𝐵 = 1.01 + 0.01 ∗ (3.72 + 3.04 + 4.24 + 3.29 + 4.68)

𝐵 = 1.1997 ≅ 1.20
Factor de
Muy Bajo Bajo Normal Alto Muy Alto Extra
Escala Wj
Precedencia Ampliamente
Completamente Algún Generalmente Ampliamente Completamente
sin
PREC sin Precedentes Precedentes Familiar Familiar Familiar
Precedentes
Flexibilidad Alguna
en el Relajación Relajación Conformidad Alguna Metas
desarrollo Rigurosa
Ocasional en General Conformidad Generales
FLEX
Arquitectura
Resolución Siempre Generalmente Principalmente Completo
de Riesgo Poca (20%) Alguna (40%)
(60%) (75%) (9%) 100%)
RESL
Cohesión Interacciones Interacciones

de equipo Interacciones Ampliamente Altamente Interacciones
con alguna básicamente
Difíciles cooperativas cooperativas sin Fisuras
TEAM Dificultad cooperativas
Madurez del
proceso Desarrollado más adelante
PMAT
PM nominal= 2.4 (5.671) ^ 1.05

PM nominal =14.84
6. Productividad Nominal
Productividad nominal= SLOC/PM nominal =5671/25.67=382.14

7. Tiempo para el proyecto en ejecución
TDEV= Meses del programador para realizar el proyecto

TDEV=2,5 * (PM) ^ 0,32
TDEV=2,5 * (14.84) ^ 0,32
TDEV=5.92 MESES
93
8. Costo del diseño (CD).
SP= Sueldo del programador

SP=700
CD=PM*SP
CD=14.84*700
CD=S/.10388 Soles.
6.2.2. Beneficios de la Implementación
 Mejora en el proceso de toma de decisiones para que la información

esté disponible de manera favorable para la toma de decisiones.
 Manejar la información disponible para realizar una anticipación de

los escenarios futuros.
 Minimizar las duplicidades. En las empresas que no cuentan con un

sistema ERP, es común encontrar que sus departamentos actúan
con cierta independencia unos de los otros, por lo que terminan
generando registros o informes duplicados.
 Los sistemas ERP están formados por módulos. Las funcionalidades

de un sistema ERP se extienden progresivamente conforme lo
módulos de este se van implementando. Si la empresa crece, el
sistema es capaz de adaptarse incorporando nuevos módulos.
94
CONCLUSIONES
 Se logró realizar el análisis y diseño del sistema de ventas para la farmacia
San Pedro usando la metodología orientada a objetos.
 Se recolectó toda la información necesaria acerca del sistema con el que
opera la farmacia, hasta hoy en día.
 Se logró identificar a precisión la problemática que presenta la empresa.
 Se reconocieron los modelos de negocio.
 Se logró determinar los requisitos funcionales y no funcionales para el

sistema a implementar.
 Se consiguió establecer los casos de usos necesarios para el

funcionamiento del correcto sistema.
 Se planteó que una de las ventajas de mayor relevancia que traería consigo
el sistema de ventas a implementar sería que habría un mejor manejo de
los datos, ya sea de los medicamentos, los clientes, los proveedores, los
empleados y principalmente de las ventas realizadas. Y además que
soportará la generación de reportes de un periodo determinado, así
mismo, la facilidad de uso que ofrece, evitará el mal manejo de los
empleados y con ello las posibles fallas.
RECOMENDACIONES
 Es necesario que el software de la farmacia sea manipulado por
personal idóneo (Dueña cambiar), que tenga conocimientos previos
para llevar tener una manera más eficaz en las ventas de la farmacia.
 Si se hizo cambios y/o modificaciones en los campos de la BD, se

recomienda actualizar el sistema de modo que se evite posibles errores
de compilación y guardado de los datos.
95
BIBLIOGRAFIA
CCM. (8 de Marzo de 2017). Ciclo de vida del 'software'. Obtenido de
https://es.ccm.net/contents/223-ciclo-de-vida-del-software
Gómez, V. (2 de Julio de 2015). Desarrollo Software Basado en Componentes. Obtenido

de Instinto Binario: https://instintobinario.com/890/
Grupo espiral PHP. (8 de Agosto de 2009). Modelo Espiral. Obtenido de

http://modeloespiral.blogspot.com/
Weitzenfeld Ridel, A., & Guardati Buemo, S. (2007). Capítulo 12 Ingeniería de software:
el proceso para el desarrollo de software. En J. J. Marciniak, Encyclopedia of
software engineering (págs. 355-396). Editor en Jefe.
96
GLOSARIO
 Base de Datos: Una base de datos es éstos corresponden a los requisitos
un conjunto de datos pertenecientes a funcionales.
un mismo contexto y almacenados
 Requisitos Software: Los requisitos
sistemáticamente para su posterior uso.
software son la descripción de las
 SQL (Structured Query Language): es características y las funcionalidades del
un lenguaje específico del dominio sistema
utilizado en programación; y diseñado
 Modelo Entidad Relación: Un modelo
para administrar sistemas de gestión de
entidad-relación o diagrama entidad-
bases de datos relacionales.
relación es una herramienta para el
 Requerimiento Funcional: Un modelado de datos que permite
requisito funcional define una función representar las entidades relevantes de
del sistema de software o sus un sistema de información así como sus
componentes. Una función es descrita interrelaciones y propiedades.
como un conjunto de entradas,  Usuario: Es aquella persona que usa o
comportamientos y salidas. Los usará el sistema.
requisitos funcionales pueden ser:
 Casos de Uso: Un caso de uso es una
cálculos, detalles técnicos,
descripción de los pasos o las
manipulación de datos y otras
actividades que deberán realizarse para
funcionalidades específicas que se
llevar a cabo algún proceso. Los
supone, un sistema debe cumplir.
personajes o entidades que
 Requerimientos no Funcionales: Un participarán en un caso de uso se
requisito no funcional o atributo de denominan actores.
calidad es, en la ingeniería de sistemas
 Diagramas de Interacción: Los
y la ingeniería de software, un requisito
diagramas de interacción son modelos
que sabe bien y especifica criterios que
que describen como grupos de objetos
pueden usarse para juzgar la operación
colaboran para conseguir algún fin.
de un sistema en lugar de sus
comportamientos específicos, ya que
97
ANEXOS
Anexo A. Hoja de Encuesta para el Jefe de Farmacia
98
Anexo B. Entrevista al Jefe de Farmacia
1. ¿Cómo es el funcionamiento de su empresa?

Es una empresa familiar, que está pegada tributariamente al rorúrico
simplificado y partió en el año 1960, todo ese tiempo a estado trabajado,
primero en la novena cuadra de Olaya y después ya en la quinta cuadra de
Olalla.
2. ¿Cómo está estructurada la empresa?

Como es una empresa familiar hay una organización interna que en caso de
nosotros, el representante legal soy yo, María Julia Plasencia y como socio
por el fallecimiento de mi padre figura mi hermano que es Pedro Delfín
Plasencia Quiñones, eso de la parte administrativa, pero la farmacia tiene un
director técnico y después tiene los auxiliares de farmacia que son los
dispensadores. La farmacia San Pedro a diferencia del resto de farmacia de
Chimbote, es que tiene un recetario magistral, que es un pequeño laboratorio
donde se prepara los medicamentos de las distintas formas farmacéuticas
pero que no sean estériles, nosotros tenemos la zona de dispensación que
es lo que conocemos como farmacia tradicional mente más un laboratorio
que es el recetario magistral donde atendemos la recetas.
3. ¿Cuál es la visión que usted tiene para su negocio?

La visión, quiero ser una farmacia referente en la preparación de
medicamentos.
4. ¿Cómo usted trabaja con los clientes?

Nosotros atendemos directamente las recetas, hay en estos momentos dos
farmacéuticos atendemos las recetas.
Con respecto a la atención, porque tenemos un agente BCP que funciona acá
que también se lo atiende, entonces nuestra fortaleza es la atención al cliente.
5. Usted ¿Cómo trabaja con los proveedores?
99
Trabajamos de dos formas, ya sea compras al contado o compras al crédito

y para comprar a los proveedores tenemos que estar habilitados por la
DIGEMID con resolución para que ellos nos puedan vender los
medicamentos.
6. ¿Cuántos empleados o personal tienen la empresa?

Tenemos dos jóvenes part-time y dos farmacéuticos.
7. ¿Cuál es el proceso para contratar a un personal?

Bueno a nosotros nos interesa el perfil digamos el proceso, el perfil por
ejemplo nos interesa, personas jóvenes que proyecten honestidad y
seguridad al cliente, por que como hay muchas transacciones nosotros
necesitamos que esta personas que atiendan lo hagan minuciosamente,
tranquilo, porque como hay dinero entre medio, la persona que viene acá
tiene que tener la confianza de que se le va a dar su dinero, uno que no haiga
billetes falso ni moneda falsa y dos que su vuelto se exacto, entonces a
nosotros nos interesa eso, esa credibilidades esa confianza del público no, y
para seleccionarlo ,en base a ese perfil que necesitamos, es que buscamos
los jóvenes, que os guiamos de Rotaract.
8. ¿Usted tiene otras sucursales?

No, este es el único.
9. ¿La compra de productos de sus proveedores es diario o maneja un

inventario?
Nosotros manejamos un pequeño inventario, y hacemos las compras 2 veces
al mes.
10. ¿Cuántos clientes aproximadamente tiene al día?

Por ejemplo, en lo que es farmacia, tengo alrededor de 50 clientes y lo que
es agente, son más de 200 transacciones.
100
11. ¿Cuánto tiempo le toma contabilizar sus cuentas?

Nosotros lo hacemos un cierre diario, y eso nos lleva más menos una media
hora.
12. ¿Usted requiere de reportes?

Si, allí he tenido mala experiencia en el sentido de que, nosotros contratamos
los servicios de alguien que nos haga un programa y, ese como se llama el
que identifica Firefox? porque es un lobito, entonces, la persona que ha
estado trabajando en programa, ya lleva casi 3 años y no ha podido avanzar,
no sé, toma trabaja de un lado otro lado pero, necesitamos concluir ese
trabajo.
13. ¿Está familiarizado con el uso de computadoras?

Si, en la farmacia manejamos 3 computadoras por el tema de los agentes.
14. ¿Utiliza algún software o programa que almacene información sobre sus
ventas?
En este momento no, pero lo necesito como te digo el programa esta cojo.
15. Actualmente en sus computadoras que tiene para los agentes ¿Qué
sistema operativo utiliza?
No sabría decir, pero yo sé que tengo que tener red pero no cada máquina
ya viene como preinstalado, y la información que tengo para la
administración de la farmacia lo estoy haciendo en un Excel común y
corriente pa poder tener algo de que agarrarse.
16. ¿Tiene conocimiento sobre los sistemas de información?

¿Los sistemas son distintos a los programas, verdad?; ¿Cuándo hablamos de
sistemas es Windows? Conozco sistema de venta por la experiencia laboral
pero yo no tengo.
101
17. ¿Actualmente la empresa tiene problemas?

Si pos con el tema de administración estamos a la época de la tortuga, si
todo es manual no y a la experiencia,
18. ¿Usted cree que un sistema de información pueda solucionar su

problema?
Si, por que me ayudaría a manejar a administra mejor el tema de pedido

inventario control de inventario, y el vencimiento de los medicamentos tiene
vencimiento, entonces así yo puedo y saber cuál son los que está por
vencerse y el manejo de las faltas.
102
Anexo C. Encuesta al Jefe de Farmacia
Anexo D. Encuesta
103

Proyecto Completo

Încărcat de

Informații document

Descriere originală:

Titlu 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 Completo

Încărcat de

Drepturi de autor:

Formate disponibile

“Año del Diálogo y la reconciliación Nacional”

Escuela Profesional de Ingeniería de

El término Sistemas de información se emplea en múltiples campos y/o

Los SI son herramientas muy importantes en los negocios ya que pueden

En el siguiente proyecto se va analizar y diseñar un sistema de información para

The fifth chapter, reflects a prototype of the future system to be implemented,

3.2.7. Resumen ............................................................................................................................. 27

4.3.1. Documento de Casos de Uso ..................................................................................... 41

Imagen 1. Farmacia San Pedro .............................................................................................................. 11

Tabla 1. Personal Involucrado ................................................................................................................ 26

Nombre Del Proyecto:

“Análisis y Diseño de un Sistema de Ventas para la Farmacia San Pedro usando la

 Recabar información del sistema con el que opera actualmente la farmacia.

 Identificar y definir la problemática de la empresa.

 Reconocer los modelos de negocio.

 Determinar los requisitos funcionales y no funcionales que se pretenda

 Establecer los casos de usos necesarios para el funcionamiento del

Marco Teórico Conceptual

1.1.1. Ubicación Geográfica

La Farmacia San Pedro se encuentra ubicada en la Av. José Olaya

Imagen 1. Farmacia San Pedro

Imagen 2. Ubicación de la Farmacia San Pedro

1.1.2. Base Legal

Criterios Éticos para la Promoción de Medicamentos de la Comunidad

 Ley Nº 27657 - Ley del Ministerio de Salud.

 Ley Nº 27444- Ley del Procedimiento Administrativo General, y

 Ley N° 29459- 2009 Ley de los Productos Farmacéuticos,

 Decreto Legislativo Nº 1044 -2008 Ley de Represión de la

 Decreto Supremo N° 013-2002-SA Reglamento de la Ley del

 Decreto Supremo N° 023-2005 Reglamento de Organización y

 Decreto Supremo N° 016-2011-SA-Reglamento para el Registro

 Decreto Supremo N° 014-2011-SA-Reglamento de

1.1.3. Áreas que corresponde

En el área de almacén, se desarrollan los siguientes procesos:

 Se controla las reservas de los medicamentos y la información de

En el área de venta, de desarrollan los siguientes procesos:

 Se registra los datos de los clientes (Nombre, DNI, Dirección)

1.1.4. Reseña Histórica y Operacional

Es una empresa familiar que se originó en el año 1960, ubicada,

A principios del 2018 falleció el padre de la señora María Julia Plasencia

La farmacia San Pedro a diferencia del resto de farmacia de Chimbote,

Ser una institución líder, reconocida y distinguida en el mundo

Contribuir al bienestar de los ciudadanos de la ciudad de Chimbote,

Imagen 3. Organigrama de la Farmacia San Pedro

1.1.8. Análisis FODA

► Atención personalizada. ► No tener Software.

► Calidad en Productos. ► No manejar bien las

► Desarrollar nuevos ► Competencia cercana de

Imagen 4. Análisis FODA de la Farmacia San Pedro

2.1. Acciones Preliminares

2.1.1. Ciclo de Vida de desarrollo de SW

El ciclo de vida del software describe el desarrollo de software,

El ciclo de vida permite que los errores se detecten lo antes posible

El ciclo de vida básico de un software consta de los siguientes

 Análisis de los requisitos y su viabilidad: recopila, examina

 Diseño general: requisitos generales de la arquitectura de la

 Diseño en detalle: definición precisa de cada subconjunto de

 Programación: implementación de un lenguaje de

 Prueba de unidad: prueba individual de cada subconjunto de

 Integración: garantiza que los diferentes módulos se integren

 Prueba beta (o validación): garantiza que el software cumple

 Documentación: sirve para documentar información