Proyecto SI

“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
NVO CHIMBOTE
- 2018 -
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
INFORMACIÓN
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
INFORMACIÓN
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
INFORMACIÓN
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
5
INFORMACIÓN
3.2.6. Referencias......................................................................................................................... 27
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
6
INFORMACIÓN
4.3. Análisis y Diseño....................................................................................................................... 41

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............................................................................................................................ 84
CAPITULO V................................................................................................................................................... 85
5.1. Diseño de interfaces de prototipo........................................................................................... 85
CAPITULO VI................................................................................................................................................. 90
6.1. Estudio de Viabilidad.................................................................................................................... 90
6.1.1. Viabilidad Tecnológica......................................................................................................... 90
6.1.2. Viabilidad Operacional......................................................................................................... 90
6.1.3. Viabilidad Económica........................................................................................................... 90
6.2. Estudio de costo y beneficiación.............................................................................................. 91
6.2.1. Costos para la implementación........................................................................................ 91
6.2.2. Beneficios de la Implementación..................................................................................... 95
CONCLUSIONES.......................................................................................................................................... 96
RECOMENDACIONES................................................................................................................................. 96
BIBLIOGRAFIA............................................................................................................................................... 97
GLOSARIO...................................................................................................................................................... 98
ANEXOS.......................................................................................................................................................... 99
7
INFORMACIÓN
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
INFORMACIÓN
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
INFORMACIÓN
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
INFORMACIÓN
CAPITULO I
Marco Teórico Conceptual

1.1. Datos Generales de la Empresa
1.1.A. 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
INFORMACIÓN
1.1.B. 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.C. Á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
INFORMACIÓN
Á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.D. 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.E. 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.F. 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
INFORMACIÓN
1.1.G. Organigrama
JEFE DE FARMACIA
ADMINISTRACION
DRECTOR TECNICO
PERSONAL DE
FARMACIA
Imagen 3. Organigrama de la Farmacia San Pedro
14
INFORMACIÓN
1.1.H. Análisis FODA
► No tener Software.
► No manejar bien las
► Atención personalizada. utilidades.
► Calidad en Productos. ► No contar con un medio
► Buen servicio al cliente. de publicidad.
► Desarrollar nuevos
► Competencia cercana de
negocios.
otras farmacias.
► Promocionar ofertas.
► Publicidad agresiva de la
► Crecimiento Poblacional
competencia.
de Chimbote.
Imagen 4. Análisis FODA de la Farmacia San Pedro
15
INFORMACIÓN
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. [ CITATION CCM17 \l
10250 ]
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.
16
INFORMACIÓN
 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.
 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). [ CITATION Wei07 \l 10250 ].
Este modelo conforma los siguientes procedimientos:
Requerimient
os
Análisis
Diseño
Programación
Prueba
Implementaci
ón
Mantenimient
o
17
INFORMACIÓN
Imagen 5. Procedimiento del Modelo Cascada
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
INFORMACIÓN
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
19
INFORMACIÓN
 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 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
INFORMACIÓN
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
INFORMACIÓN
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
22
INFORMACIÓN
 Requisitos no Funcionales
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
INFORMACIÓN
24
INFORMACIÓN
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
25
INFORMACIÓN
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.
26
INFORMACIÓN
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
27
INFORMACIÓN
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.
28
INFORMACIÓN
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
29
INFORMACIÓN
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.
30
INFORMACIÓN
 La interfaz del módulo de inventario necesita como entrada los

datos del producto a integrar o modificar en el sistema.
 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.
31
INFORMACIÓN
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.
Para el ingreso al sistema se requerirá obligatoriamente de los
Descripción del
siguientes datos: Nickname y Contraseña, para acceder al
requerimiento:
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
32
INFORMACIÓN
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
requerimiento: modificación permitirá Agregar, Modificar y Eliminar los datos.
« RNF1
« RNF8
Alta
Identificación RF5
33
INFORMACIÓN
del
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
« 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
« RNF1
« RNF8
Alta
Identificación
del RF7
requerimiento:
Nombre del
Generar Reportes
Requerimiento:
34
INFORMACIÓN
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
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
35
INFORMACIÓN

Identificación del
RNF2
requerimiento:
Nombre del
Desempeño en varios sistemas operativos
Requerimiento:
El sistema podrá utilizarse en diferentes S.O (“Linux, Windows,
Características:
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

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
requerimiento: también al denegar el acceso al personal no autorizado para
la realización de modificaciones.
Alta
36
INFORMACIÓN

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

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
37
INFORMACIÓN
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
38
INFORMACIÓN
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)
39
INFORMACIÓN
El MODELO en espiral, propuesto originalmente por BOEHM en 1976,

es un modelo de proceso de software evolutivo donde se conjuga la
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. [ CITATION Gru09 \l 10250 ]
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:
40
INFORMACIÓN
 Industrialización del desarrollo de software: Muchas empresas

utilizan componentes desarrollados por otras empresas e incluso
algunas venden sus propios componentes.
« 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. [ CITATION Góm151 \l 10250 ]
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,
41
INFORMACIÓN
puesto que sería un desperdicio almacenar el mismo procedimiento

varias veces y ello va contra el principio de reutilización de código.
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).
42
INFORMACIÓN
43
INFORMACIÓN
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 7. Busca en la B.D. el número de
Cliente. 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).
44
INFORMACIÓN
45
INFORMACIÓN
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.
46
INFORMACIÓN
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.
47
INFORMACIÓN
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)
48
INFORMACIÓN
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.
modificaciones como, editar y eliminar.
Eventos
USUARIO SISTEMA
(editar y eliminar)
guardar.

correctos.
la BD.
Alternos
Elementos
49
INFORMACIÓN
Caso 07
Caso de Uso: Gestión de Proveedores

Actores: U - S
Propósito: Realizar modificaciones en el sistema de los proveedores
disponibles.
modificaciones como agregar, modificar y eliminar.
Eventos
USUARIO SISTEMA
(agregar, modificar y eliminar)
guardar.

correctos.
la BD.
Alternos
Elementos
50
INFORMACIÓN
Caso 08
Alternos
Elementos
51
INFORMACIÓN
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
52
INFORMACIÓN
Caso 02.- Realizar Ventas
Caso 03.- Registrar Nuevo Cliente
53
INFORMACIÓN
Caso 04.- Búsqueda de Clientes
Caso 05.- Gestión de Usuarios
54
INFORMACIÓN
Caso 06.- Gestión de Ventas Realizadas
Caso 07.- Gestión de Proveedores
55
INFORMACIÓN
Caso 08.- Gestión de Medicamentos
Caso 09.- Generar Reportes
56
INFORMACIÓN
DIAGRAMA DE CASOS DE USO DEL SISTEMA DE VENTAS
4.3.3. Diagrama de Secuencia
1. Ingreso al sistema
57
INFORMACIÓN
2. Realizar Venta
3. Registrar Nuevo Cliente
4. Búsqueda del Clientes
58
INFORMACIÓN
5. Gestión de usuario
5.1. Agregar nuevo usuario
5.2. Modificar usuario
5.3. Eliminar usuario
59
INFORMACIÓN
6. Gestión de Ventas Realizadas

6.1. Modificar Venta
6.2. Eliminar Venta
7. Gestión de Proveedores
7.1. Agregar Proveedor
60
INFORMACIÓN
7.2. Modificar Proveedor
7.3. Eliminar Proveedor
8. Gestión de medicamentos
8.1. Agregar Medicamento
61
INFORMACIÓN
8.2. Modificar Medicamento
8.3. Eliminar Medicamento
9. Generar reporte
62
INFORMACIÓN
4.3.4. Diagrama de Colaboración
2. Realizar Venta
63
INFORMACIÓN
3. Registrar Cliente
4. Búsqueda de Clientes
5. Gestión de usuario
5.1. Agregar usuario
64
INFORMACIÓN
65
INFORMACIÓN
6. Gestión de venta
6.1. Modificar venta
6.2. Eliminar venta
7. Gestión de proveedores
7.1. Agregar proveedor
66
INFORMACIÓN
7.2. Modificar proveedor
7.3. Eliminar proveedor
8.1. Agregar medicamento
67
INFORMACIÓN
8.2. Modificar medicamento
8.3. Eliminar medicamento
68
INFORMACIÓN
9. Generar reporte
69
INFORMACIÓN
4.3.5. Diagrama de Clases
4.3.6. Diagrama de Actividades
70
INFORMACIÓN
2. Realizar Venta
3. Registrar Nuevo Cliente
71
INFORMACIÓN
4. Búsqueda de Clientes
5. Gestión Usuario
5.1. Agregar Usuario
72
INFORMACIÓN
73
INFORMACIÓN
6. Gestión venta
6.1. Modificar venta
6.2. Eliminar venta
74
INFORMACIÓN
7. Gestión de proveedores
7.1. Agregar de proveedor
7.2. Modificar proveedor
75
INFORMACIÓN
7.3. Eliminar proveedor
8.1. Agregar medicamento
76
INFORMACIÓN
8.2. Modificar medicamento
8.3. Eliminar medicamento
77
INFORMACIÓN
9. Generar reportes
78
INFORMACIÓN
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
79
INFORMACIÓN
 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
Tipo de Longitu
Cliente Regla
Dato d
Id_Cliente Numérico 9 Números
Nombre_C Letras
Caracteres 50
li Mayúsculas
Tipo de Longitu
Vendedor Regla
Dato d
Id_Vendedo
Numérico 9 Números
r
Nombres_Ve Letras
Caracteres 50
n Mayúsculas
Apellidos_V Letras
Caracteres 50
en Mayúsculas
Teléfono_Ve Tipo de Longitu
Proveedor Numérico 9 Números
Regla
n Dato d
Dirección_V Letras y
Id_Proveedo Caracteres 30
en Numérico 11 Números
Números
r
RazSocial_Pr Letras
Caracteres 50
ov Mayúsculas
Teléfono_Pro
Numérico 9 Números
v
Dirección_Pr Letras y
Caracteres 30
ov Números
80
INFORMACIÓN
Tipo de Longitu
Producto Regla
Dato d
Letras y
Id_Prod Caracteres 10
Números
Letras
Nombre_Prod Caracteres 50
Mayúsculas
Precio_Prod Numérico 10 Números
Stock_Prod Numérico 3 Números
Fecha_Vcto Fecha 10 Fecha
Letras y
Concentrado Caracteres 10
Números
Letras
Forma_Farma Caracteres 30
Mayúsculas
Forma_Farma_Si Letras
Caracteres 15
mp Mayúsculas
Fracciones Numérico 2 Números
Num_RS_Prod Numérico 5 Números
Letras
Laboratorio Caracteres 20
Mayúsculas
Tipo de Longitu
Venta Regla
Dato d
Num_Vent Número
Numérico 6
a s
Fecha_Ven
Fecha 10 Fecha
ta
Monto_Tot Número
Decimal 6
al s
Tipo de Longitu
Pedido Regla
Dato d
Id_Pedid Número
Numérico 6
o Tipo de Longitu s
Login Regla
Fecha_Pe Dato d
Fecha 10 Fecha
Id_Logind Numérico 9 Números
81
Letras y
Usuario Caracteres 15
Números
Contrase Letras y
Caracteres 15
ña Números
INFORMACIÓN
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
DNI_Client     VENDEDOR 1 2 3 4
e Id_Vendedor    
Nombre_Cli   X X Nombres_Ven   X X
Apellidos_Ven   X X
Teléfono_Ven  X  X
PROVEEDOR 1 2 3 4 Dirección_Ven   X X
Id_Proveedor    
RazSocial_Prov   X X
Teléfono_Prov  X  X
Dirección_Prov   X X
PRODUCTO 1 2 3 4
Id_Prod    
Nombre_Prod   X X
Precio_Prod   X 
VENTA 1 2 3 4
Stock_Prod   X 
Num_Venta    
Fecha_Vcto    X
Fecha_Venta  X  X
Concentrado   X X
Monto_Total  X X 
Forma_Farm   X X
Forma_Farm_Simp   X X
Fracciones   X 
Num_RS_Prod    X
Laboratorio   X X
PEDIDO 1 2 3 4
Id_Pedido    
Fecha_Ped    X
LOGIN 1 2 3 4
Id_Login    
Usuario   X X
Contraseña   X X
82
f) Dibujar el Modelo Entidad – Relación (MER).
83
E.A.P. SISTEMAS E INFORMÁTICA SISTEMAS DE INFORMACIÓN
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, precio_prod, stock, fecha_vcto,
concentrado, forma_farma, 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)
84
Pedido (id_pedido, fecha_pedido, id_proveedor, nom_proveedor, teléfono_proveedor, ciudad_proveedor, distrito_proveedor,

dirección_proveedor)
 Atomizando atributos:
Venta (numero_venta, fecha_venta, monto_total, DNI_vendedor, 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, precio_prod, stock, fecha_vcto, concentrado, forma_farma,
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)
85
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.
Venta (numero_venta, fecha_venta, monto_total, DNI_vendedor, id_cliente)

Vendedor (DNI_vendedor, 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)
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

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.
86
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.
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)
87

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)
88
89
4.4.2.2. Modelo Relacional
90
91
4.4.3. Diseño Físico
92
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.
93
94
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.
95
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.
96
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.
97
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.
98
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.
99
100
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.
101
102
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.
103
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).
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
104
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
3 PF 4 PF 6 PF
(EI)
Salidas Externas
4 PF 5 PF 7 PF
(EO)
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)
105
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
Tipo de Tipo de
Elemento Elementos de Datos Elementos de Datos Elementos de Datos
Archivo Archivo
de Riesgo
1-19 20-50 51+ 1-5 6-19 20+ 1-4 5-15 16+
Medi
1 Bajo Bajo Medio 0o1 Bajo Bajo 0o1 Bajo Bajo Medio
o
Medi Medi
2-5 Bajo Alto 2-3 Bajo Medio Alto 2-3 Bajo Alto
o o
Medi
6+ Medio Alto Alto 4+ Medio Alto Alto 3+ Alto Alto
o
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)
106
Consultas
3 * 3 PF 4 PF 6 PF 9
Externas (EQ)
Archivos Lógicos
7 PF 6 * 10 PF 15 PF 60
Internos (ILF)
Archivos de
Interfaz Externos 5 PF 7 PF 10 PF 0
(EIF)
Total 107
Entonces: PFSA = 107
Calculando el Factor de Ajuste:
Factor de Ajuste Puntaje

Comunicación de Datos 0
107
Procesamiento
0
distribuido
Objetivos de Rendimiento 1
Configuración del
2
equipamiento
Tasa de transacciones 1
Entrada de datos en línea 0 Puntaje Descripción
Interface con el usuario 3 0 Sin influencia
Actualización en línea 0 1 Incidental
Procesamiento complejo 0 2 Moderado
Reusabilidad del código 3 3 Medio
Facilidad de 4 Significativo
2 5 Esencial
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
108
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 W j (PREC, FLEX, RESL, TEAM y MAT)
5
B=1.01+0.01∗∑ W j
i=1
B=1.01+0.01∗( 3.72+ 3.04+ 4.24+3.29+ 4.68 )

B=1.1997 ≅1.20
Factor de
Muy Bajo Bajo Normal Alto Muy Alto Extra
Escala W j
Precedenci Ampliamen
Completamen Algún
a te sin Generalmen Ampliament Completamen
te sin Precedente
Precedente te Familiar e Familiar te Familiar
PREC Precedentes s
s
Flexibilida Alguna
d en el Relajación Conformida
Relajación Alguna Metas
desarrollo Rigurosa d en
Ocasional Conformidad Generales
General
FLEX
109
Arquitectu
ra
Generalmen Principalmen
Resolució Alguna Siempre Completo
Poca (20%) te te
n de (40%) (60%)
Riesgo 100%)
(75%) (9%)
RESL
Interaccion
Cohesión Interaccion es Ampliament
de equipo Interacciones es con básicament e Altamente Interacciones
Difíciles alguna e cooperativa cooperativas sin Fisuras
TEAM Dificultad cooperativ s
as
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
110
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
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.
111
« 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.
112
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.
113
114
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.
115
GLOSARIO
« Base de Datos: Una base de datos es un conjunto de datos sus comportamientos específicos, ya que éstos corresponden a los
pertenecientes a un mismo contexto y almacenados requisitos funcionales.
sistemáticamente para su posterior uso.
« Requisitos Software: Los requisitos software son la descripción de
« SQL (Structured Query Language): es un lenguaje específico del las características y las funcionalidades del sistema
dominio utilizado en programación; y diseñado para administrar
« Modelo Entidad Relación: Un modelo entidad-relación o
sistemas de gestión de bases de datos relacionales.
diagrama entidad-relación es una herramienta para el modelado
« Requerimiento Funcional: Un requisito funcional define una de datos que permite representar las entidades relevantes de un
función del sistema de software o sus componentes. Una función es sistema de información así como sus interrelaciones y propiedades.
descrita como un conjunto de entradas, comportamientos y salidas. « Usuario: Es aquella persona que usa o usará el sistema.
Los requisitos funcionales pueden ser: cálculos, detalles técnicos,
manipulación de datos y otras funcionalidades específicas que se « Casos de Uso: Un caso de uso es una descripción de los pasos o
supone, un sistema debe cumplir. las actividades que deberán realizarse para llevar a cabo algún
proceso. Los personajes o entidades que participarán en un caso de
« Requerimientos no Funcionales: Un requisito no funcional o uso se denominan actores.
atributo de calidad es, en la ingeniería de sistemas y la ingeniería
de software, un requisito que sabe bien y especifica criterios que « Diagramas de Interacción: Los diagramas de interacción son
pueden usarse para juzgar la operación de un sistema en lugar de modelos que describen como grupos de objetos colaboran para
conseguir algún fin.
116
ANEXOS
Anexo A. Hoja de Encuesta para el Jefe de Farmacia
117
118
119
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.
120
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?

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.
121
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.
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?
122
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.
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.
123
124
Anexo C. Encuesta al Jefe de Farmacia
Anexo D. Encuesta
125
126

Proyecto SI

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto SI

Cargado por

Copyright:

Formatos disponibles

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

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

4.3. Análisis y Diseño....................................................................................................................... 41

Nombre Del Proyecto:

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

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

 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.A. 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.B. 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

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

1.1.C. Á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.D. 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

La farmacia San Pedro a diferencia del resto de farmacia de

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.H. Análisis FODA

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

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

 Definición de objetivos: define la finalidad del proyecto y

 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

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

 Prueba de unidad: prueba individual de cada subconjunto

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

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

 Documentación: sirve para documentar información

 Mantenimiento: comprende todos los procedimientos

Para este proyecto el modelo de ciclo de vida del SW a

Este modelo conforma los siguientes procedimientos:

Imagen 5. Procedimiento del Modelo Cascada

2.2. Recopilación de la Información

2.2.1. Entrevista para obtener requerimientos

Para la entrevista abierta se consideraron las siguientes

a) ¿Cómo es el funcionamiento de su empresa?